Software Development Lifecycle

The Software Development Lifecycle (SDLC) is the set of steps taken in the conception, planning, design, delivery and maintenance of a software project.

It is introduced here as a concept since awareness of it is important in understanding tools like version control and the operation of cloud development platforms like Gitlab, covered in later sections.

Lifecycle Stages

The stages and stakeholders in the SDLC are sketched in Fig. 15.

Fig. 15 The typical stages in the software development lifecycle

The lifecycle, which in iterative or Agile managed projects is regarded as a loop, can begin with User Stories which are some set of needs or requirements from project stakeholders. Stakeholders can include people who use the software directly in their own project, or scientific outputs delivered by the software. They can also include funding bodies, colleagues at ICHEC or other ICHEC external stakeholders.

User Stories are collected and studied in the Analysis stage to decide on the features a software project should add, given other contraints such as time, available staff and funding and long term maintenance needs. At this stage it might be decided that further requirements or clarifications are needed through closer engagement with stakeholders.

Following the Analysis stage there is a Design stage where the software architecture, flows and planned technologies are decided. The design stage can produce outputs in multiple levels of detail - right down to a set of automated tests that must pass as the feature is developed.

The Development stage follows next, where software is written - including automated tests. This is followed by a Testing stage - which can be a mix of automated (preferred) or manual test to make sure the software is working as expected. If testing is successful the software is Deployed, meaning a version is marked as ready for use by project stakeholders and is usually made available for download from some repository or launched as a web service at some known location.

Following deployment there is a Monitoring stage, which includes both manual and automated elements. In this stage telemetry and logs from the running software are monitoring for errors, to make sure the rate and severity of errors is within previously designed ranges. At this point defects discovered by stakeholders using the software will also be collected, and new User Stories as end-users find ways that they would like the software to improve.

In Waterfall style development these steps are undertaken only once - for a single ‘piece of software’, while in Agile development the loop is iterated many times as small elements or ‘features’ of the software are graudally delivered.

The Agile version of this SDLC ‘loop’ is based on the Continuous Improvement cycle shown in Fig. 10 and introduced in the Project Management chapter. An important part of Agile development is to iterate on this cycle as efficiently as possible, using tooling, templates and automation.

Fig. 16 The continuous improvement cycle that the Agile version of the SDLC is based on.

Upstream, Downstream and Versioning

The software you create in your project does not live in isolation. It will depend on other software, such as Python packages or compilers and system libraries. The outputs, stability and security of your software depends on these attributes in your upstream dependencies. As sketched in Fig. 17 the upstream software will itself be following some form of SDLC, thus you will need to be aware of how that software is released and how secure and reliable their release process is.

Fig. 17 The SDLC for one project does not live in isolation, it has upstream dependencies and downstream dependants.

One important way to keep track of these upstream dependencies is by monitoring their version. A software version typically takes the form of an alphanumeric tag, corresponding to a a snapshot of its source code. A version typically corresponds to a ‘release’ or deployment, which might include binary assets. Two typical schemes are semantic versioning (semver) and date based versioning. In the former, a scheme such as ‘major.minor.patch’ (e.g. 12.3.456) is used where patch changes are small bug fixes. Minor changes can include new features and extensions and major changes involve breaking of APIs or changing or existing behaviours. There are several other conventions, such as 0. major versions and alpha, beta or dev suffixes which indicate a degree of software stability. Date based versioning follows a pattern like ‘yyyy.mm.patch’ - which gives less information on stability, but can be easier to see how recent a release has been at a glance.

As per Fig. 17 when developing software it is also important to consider downstream consumers. Consumers need a way to reference a particular version of your software that they can rely on for stability and security. Providing a versioned release is a good way to allow for this. However, particularly for web based applications, it is necessary to also include the possibility for rapid roll-out of patches or reverts for any issues that may be encountered downstream.

As shown in Fig. 18, managing the SDLC while accounting for upstream and downstream stakeholders can quickly get complicated as there can be many stakeholders involved and you can end up building on top of a moving target. For this reason automated tooling is extremely important in modern software development. Of these tools, version control is one of the most important - and will be covered in the next section.

Fig. 18 The SDLC can get complicated when accounting for the many stakeholders involved. Modern software development relies heavily on automated tooling for this reason.