Software Development Lifecycle

What is it

A Software Development Lifecycle policy is a description of how to create and maintain software in a way that helps us building software products with the quality required: as securely as possible, providing fast and proficient delivery of business value that lives up to any regulatory guidelines and business needs.

Process overview

This section describes the idea behind the work process to software changes. A more detailed version can be found in the internal guidelines and instructions.

Agile

Although Agile is not a development process or strategy, we do adhere the Agile Manifesto. For ShipitSmarter this means that we develop software changes not by creating a fully defined solution document, but start with a business requirement that will be improved and adjusted during the development phase with the goal to deliver the intended business value.

Kanban

We use Kanban a board to visualise the workflow of the changes we execute. Mature initiatives for a change are registered in a backlog on a Kanban board. A change can be activated by the Product Manager or a delegate. Every Product Team has a way of working for handling changes (also called user stories or issues) that suits their development process best.

Version control

All code and documentation related to a change is subject to a version control system. The classic version control system is Azure DevOps git, but in our transformation to a cloud native product with a gitops approach, we are using github.

Changes to both code and documentation must be checked into source control at least once a day.

Triggering changes

Changes to software can only by initiated for three reasons. Depending on the type of change, a different process applies.

a. Changing business requirements

Changing business requirements can be due to new functionality needed or changes in laws or regulations.

When a change is considered a small change, meaning it is only a adjustment to existing functionality that will not influence the other functionality, a Business Analyst can define the change and introduce it to the Product Manager in the form of a work item. The work item on the Agile board contains a description of the change and an indication of the payee.

Any other business requirement induced change needs to be introduced in the Stakeholders meeting. This forum, consisting of senior Business Analysts and the Product Manager, will decide on the need and feasibility of the change. With a positive Stakeholder advise the introducing Business Analyst can create a business case, including a description of the change, and find a sponsor to finance the work and resources needed to execute the change. Creating a business case usually involves an estimation together with DevOps to estimate all resources needed to complete a change.

When the change is confirmed, executing the change can be planned. During the change creation process the Business Analyst will be responsible for the quality of the result, meaning the Business Analyst should work together with DevOps to create the change and approves the result, including documentation and (automated) test results).

b. Technical improvements

Changes can also be introduced due to technical shortcomings or new developments that could improve the whole system significantly. These changes are handled the same as changing Business Requirements with two differences:

1. the sponsor is usually the Product Manager
2. a senior developer has the role of Business Analyst

c. Bugs

Bugs are either related to a Service Level Agreement (SLA) and as such reported by our customers, or generic.

Whenever a bug is categorised as within a SLA and a Kanban work item has been created, it will be triaged at the end of each working day. Legit SLA bugs (Prio 1 to 3) will be solved before the SLA defined target date.

Bugs categorised as Prio 4 (not SLA) will be handled as business requirement induced changes.

Responsibilities

Business Analyst

As a Business Analyst, you are responsible for initiating changes, providing the information needed to execute a change and for checking if the result meets the requirements of the change. You have a very good idea of how the change both fits in the ShipitSmarter platform and support the customer process. As such you also inform your peers in a way that they are able to have a realistic view on the change.

Developer

As a Developer you are responsible to create the technical capabilities to introduce a change. It also involves having a fair, but critical approach to the change requested, all in order to maintain or improve product quality and preventing potential runtime, security or maintenance issues. Whenever applicable, you advice the Business Analyst on the feasibility of changes and of technical capabilities that could improve the solution.

Quality

Changes to software should always be executed at a certain quality level. The quality of the change, both in functional and in a technical sense, are the responsibility of all team members. A change should not lower the resilience or security of the overall system, preferably it improves.

Security

All changes should be in line with industry standards and best practices concerning security. That would at least involve the OWASP top ten. More information about security can be found at Information Security Management Policy.

Approvals

When a change has been created, the status of the related work item changes to “Requester Review”. The initiating Business Analyst is responsible for reviewing and approving a change. As soon as a change is approved, it can be made available at the next deployment. When a change is supposed to be made available to customers at a specific time, a flag or other measure should be taken to make it available at a later stage. But the code should be merged to the production code as soon as possible, to prevent the piling up of changes, because that potentially introduces merge conflicts.

Automated testing

All changes are tested with:

1. Unit test, testing specific (small) functions and methods in code.
2. Functional tests, testing functionality through application end points.
3. Integration or end-to-end test, testing the integration of functionality, usually using stubs for external services, sometimes using external test environments.
4. Manual tests, confirming User Interface related changes.

All tests, excluding the Manual tests are part of automated tests, that are triggered either at each deployment or scheduled.

Environments

In order to confirm a proper implementation of new functionality, these environments are available:

1. Developer machine - used to create new functionality
2. Test - used by DevOps and Business Analysts to test functionality
3. Acceptance - used by Business Analysts to test if the in the Test environment confirmed functionality also works in a production like infrastructure
4. Production - not used to test functionality, can be used for A/B testing

Our cloud native product solves having seperate environments a bit different. This product provides the following environments:

1. Production - not used to test functionality, can be used for A/B testing
2. Ephemeral - an environment that only exists for a specific change or purpose and will be automatically removed after its purpose is gone. Used to replace acceptance and test environments. Usually exists for no more than hours or a couple of days when labour-intesive testing is involved.

The SLA response times are only applicable to the Production environment.

Pipelines

Pipelines are used to either trigger changes in code (deploy the changes) or run specific tasks that are test, code or infrastructure related. Every change that should be deployed, will be so through a pipeline. A code change pipeline will:

1. check if the change is related to a workflow
2. check if enough peers have confirmed the change
3. the executer has sufficient rights to execute the pipeline
4. check for a positive result of the automated tests that are part of the pipeline

In order to keep the pipeline runtime acceptable (minutes), tasks like Integration- or End-to-End tests are scheduled separately.

Pull Requests and Reviews

In order to maintain an equal level of quality through all development, code changes are subject to a pull request mechanism, allowing continuation of changes only if at least two peers have observed and approved the code changes.

Also review and evaluation sessions are held. At least one every two months, but more importantly, as part of the DevOps culture, whenever a team member things it is appropriate, usually concerning one complex or multiple small changes. The improvements resulting will be documented and assigned to a DevOps member made responsible for the execution (when applicable).