The purpose of the Software Development Life Cycle (SDLC) is to specify a set of steps which guide us in translating business requirements into operational IT systems.
The 7 stages of the SDLC are listed below.
| Stage | Purpose |
|---|---|
| Feasibility Study | Determine if the project is worthwhile |
| Requirements Analysis | Obtain the requirements for the system |
| Design | Design/architect the system |
| Development | Write the software to implement the design |
| Testing | Test the software to ensure it meets the requirements |
| Deployment | Deploy the software to local/cloud servers |
| Maintenance | Support the software in the live environment |
Note that in Waterfall software development, each stage must be complete before the next stage begins. In Agile software development, each (typically 2 week) sprint will include the design, testing and deployment of a subset of requirements, allowing development teams to adapt as customer/business needs change.
A feasibility study evaluates a project's potential for success.
The idea for a project can come from a number of different places.
For example modern banking apps like Monzo and Starling introduced the ability to freeze a debit card from an app. Other banks saw this and reacted to the competition by implementing this same feature for their own customers. This is an example of a SDLC being driven by business needs.
A feasibility study considers the following:
Here is an example Esports Feasibility Report which discusses the use of the Queen Elizabeth Olympic Park in London as a venue for supporting the growth in the gaming industry.
Listen up to position 2:10 of this Dragon's Den pitch video. Do you think the idea is feasible?!
Once the Feasibility Study is complete, a Business Case document is produced which details the justification for undertaking the project including costs, risks and benefits.
This stage of the SDLC is about working out exactly what needs to be built or purchased in order to deliver the business impacts and benefits defined in the feasibility stage.
We discussed Requirements Analysis in depth in Module 1 - Unit 1. You documented functional and non-functional requirements and created Personas and User Stories.
The purpose of the Design stage is to formulate a solution or software specification to realise the system's requirements. The chosen design is elaborated in sufficient detail to to allow developers to implement it.
The system designer/architect will be constrained by the non-functional requirements of the system such as:
They will also be affected by the quality of requirements and the availability of stakeholders for clarification of requirements.
In Module 1 we looked at User Interface design. Let's now turn our attention to the design of backend components. We'll start by looking at some architectures from companies using Amazon Web Services (AWS) components. Listen closely to how non-functional requirements impact how the architecture is designed.
We can use a UML Component Diagram to represent architectural components.
Here is a very simplified architecture diagram created using a UML Component Diagrams for the SoFresh system described in Module 1].
We can then drill down into more detail by modelling the classes involved in the system and representing them using a UML Class diagram and then using a UML Sequence diagram to show the interactions between them.
If we are using a SQL database, we can use an Entity-Relationship Diagram (ERD) to model relationships between database tables.
The purpose of the Development stage is to build and/or assemble (high-quality) software components to meet a design.
Coding standards help us to develop better quality code by specifying best practices.
Nowadays, default language specific coding standards are incorporated into Interactive Development Environments (IDEs). Visual notifications of non-conformance help us fix code as we go, rather than relying on manual checks at the end of the development process.
Code reviews look at the static code and detect bugs, vulnerabilities and "code smells".
One very popular automated code review tool is SonarQube. SonarQube includes thousands of automated static code analysis rules.
Manual code reviews are still really important, we often use git Pull Requests to do these.
The purpose of testing software is to ensure the quality of the system is as high as possible by removing:
We will cover the testing phase in more detail in Unit 2 of this module.
The purpose of the Deployment stage is to make a new system operational. This is achieved through the transfer of the tested software modules to the live environment, along with setting up of the data required for the new system.
We will cover the deployment phase in more detail in Unit 3 of this module.
The maintenance stage is where deployed software is supported and enhanced. We discover whether the business case that initiated the software development life cycle is realised and discover how decisions made during the design and development stages impact the longevity of the system.
Software needs to be maintained for the following reasons:
Software does go wrong! In this video we hear how NASA engineers used problem solving to return the Apollo 13 astraunants safely back to Earth after an explosion in an oxygen tank caused a loss of oxygen, water, electrical power and the loss of use of the propulsion system.
See Full Analysis to view any bugs and code smells.