Every formal process that leads to the development of a product has a standard guideline for the activities in the development process. Cooking has recipes, Science has the scientific method and Software Development has the Software Development Lifecycle (SDLC).
What is the Software Development Lifecycle (SDLC)?
The software development lifecycle is a standard guideline for the design, development and maintenance of software. Software development teams use the SDLC to move a product or a product feature from its ideation phase to its point of use by end users.
Why is the SDLC important?
The SDLC provides a structured framework for stakeholders in the software development process. This minimises guesswork and confusion around what is to be done, when and how it should be done. It also provides a data-driven decision-making system for stakeholders because subsequent phases of the SDLC are done based on the feedback from preceding phases.
The SDLC helps stakeholders involved in the software development process, to
- Analyse a software idea and understand its scope and its requirements
- Create a plan and estimate timelines for development
- Assign roles, expectations and responsibilities to stakeholders
- Set expectations and standards for the software
- Develop a quality assurance framework to ensure that the software meets expectations and standards
- Set up a maintenance structure for the software
What are the phases of the SDLC?
The SDLC is made up of six phases, each involving one or multiple sets of the same stakeholders. While some stakeholders may be active in only one phase, others may be present in more than one phase of the development cycle.
The six phases of the SDLC are:
- Requirements Gathering and Analysis
- System Design
- Design Implementation
- Quality Assurance or Testing
- Deployment
- Maintenance
Requirements Gathering and Analysis
This is the phase of the SDLC where stakeholders such as the product owner, the business analyst, the product manager and experienced software engineers discuss the software idea or feature. The aim of this phase is to translate the software or business idea into functional and non-functional requirements for software development.
Stakeholders in this phase attempt to gather different high-level components required to build the software. Some of these components include:
- government regulations and licences (for example GDPR)
- market research data or insights
- industry experts’ advice or opinions
- system feasibility reports
- cost estimation and budgeting
- estimated timelines
At the end of this phase, stakeholders know the business and technical components required to build the software. They produce a software requirements specification document which sets the scope and the expectations of the software to be built.,
With respect to a simple FinTech application as a case study, at the end of the requirements gathering and analysis phase, stakeholders will know that the application will allow users to
- fund their wallet from a bank account
- purchase items from a store with funds in their wallet
- transfer funds from their wallet to another user’s wallet
and also know the service charge of these services on the application.
In addition to these, they will have an estimate of what it will cost to build and maintain the software, and also an estimate of how long it will take to complete the application.
System Design
In the System Design phase, software engineers and architects analyse the software requirements specification document to determine the technical requirements, tools and architecture needed to build the software. Some of the decisions to be made include the choice of programming language, database and external service providers.
Stakeholders also document the reasons for their decisions and the trade-offs considered in making these decisions. The document becomes the software design specification. Flow charts, Entity Relationship Diagrams (ERDs), Unified Modelling Language (UML) diagrams and data flow diagrams are drawn and used to illustrate the architectural blueprint of the software and are part of the software design specification.
UI/UX designers take part in this phase if the software requires user-facing components. They study the data models and the expectations of the software and use the insights gathered to design user interfaces with tools like Figma, Adobe XD and Sketch.
Design Implementation
In this phase, front-end engineers, mobile developers and backend engineers are guided by the software design specification document to write code to build working software. They also write documentation for the code they write.
Front-end developers develop software that end users interact with directly. An example is the user interface of the website that you are currently reading. Back-end developers are involved in helping the frontend access information in a secure manner from a database or other service providers. They also write code that enforces the core business logic of the software. Full-stack developers can perform the functions of front-end developers and back-end developers.
Software engineers use a version control system like Git to manage different versions of the code and use a platform like GitHub or Gitlab to host the code and enable online collaboration. They also engage in code reviews where necessary, to make sure that the code written follows established standards.
In critical applications like biomedical software, it is required that engineers write comprehensive automated tests to ensure that new code does not introduce bugs and the software works exactly as specified. These tests are run by computer software and sometimes enhance the documentation of software.
At the end of this phase, we should have working software. Stakeholders may constantly iterate between this phase and the quality assurance phase until software works as expected.
Quality Assurance and Testing
Although automated tests are written during the design implementation phase, some of the tests do not accommodate complex user behaviour. In the quality assurance and testing phase, quality assurance personnel and software testers use the software like the target user to ensure that it meets the functional and non-functional requirements expected of it. These tests are called acceptance tests. They document their evaluation and give feedback to software engineers for fixes if necessary.
Aside from quality assurance personnel and software testers, real users can be onboarded to test the software through a program called beta-testing. These users use the software without any technical knowledge or inside information and give feedback to the stakeholders. Designers and engineers use insights from the feedback to update the software where necessary.
Other types of tests may be carried out. Some of them include pentesting for security, load testing, to ensure that the software can handle multiple users at the same time and accessibility testing, to ensure that users, regardless of their disability, can use the software.
Depending on the type of software, different testing tools can be used. For APIs, Postman, Insomnia or Bruno can be used. Selenium can be used for automated testing of web applications.
The software development process can cycle multiple times between this phase and the system design phase or design implementation phase, depending on the SDLC model. The goal of this phase is to ensure that the software to be released meets the standards and expectations set out in the requirements gathering and analysis phase.
Deployment
The purpose of the deployment phase is to get the working software to the users or to the platforms where users can access them. This phase involves software engineers and DevOps engineers setting up systems to deploy the software from the code repository on GitHub or Gitlab to hosting platforms such as the Google PlayStore, the Apple Appstore, Heroku, Railway or servers for direct download of the software in the case of desktop applications.
The framework for deployment can be set up and managed using tools such as Jenkins and GitHub Actions.
Engineering personnel in this phase engage in automating continuous integration (CI) and continuous delivery (CD) practices such as the management of configurations for A/B testing, feature flags, automated builds and tests on updates to the existing code.
At the end of this phase, it is expected that end users of the software would have access to it for use.
Maintenance
In the maintenance phase, stakeholders receive feedback from real users and make updates to the software where necessary - fixing bugs and adding new features. In addition to updates, stakeholders in the maintenance phase:
- Monitor the performance of the software and make improvements
- Update the software documentation based on updates and user feedback
- Provide technical support for users of the software
What next?
Understanding the Software Development Life Cycle (SDLC) is essential for anyone involved in building, managing, or maintaining software systems. By following a structured approach, from gathering requirements to maintenance, teams can improve quality, reduce risk, and deliver value more efficiently.
With your knowledge of the SDLC, you can try to
- Identify what SDLC model your project or team is currently using
- Talk with your team about SDLC improvements
- Document your software development processes
- Determine if your team is using the right SDLC model and make suggestions where necessary
Frequently Asked Questions
What are the SDLC models or methodologies?
While the SDLC is a concept, its application differs based on the project and the team implementing it. SDLC models refer to the different implementations of the SDLC. While one model, the waterfall model, goes through all six phases in a sequential manner, another model, the agile model, allows for iteration between any two phases.
For example, the agile model allows for incremental delivery of software. The smallest functional unit of the software, usually called the initial release or minimum viable product, is built up to the deployment phase first. Based on feedback, more modules are built or removed from the initial release. This is good for flexibility and helps the software adapt quickly to changing requirements.
The waterfall model on the other hand, is linear and sequential. Software development is done from requirements gathering to maintenance in a sequential manner. Each subsequent phase is done only after the preceding phase has been completed.
How do I determine what SDLC model is best for my project?
Here is a table to summarise the strengths and weaknesses of the various popular SDLC models and how they may fit your project’s needs:
What are some challenges to expect when implementing SDLC?
Some challenges that software development teams face when implementing SDLC include
- Lack of stakeholder involvement or poor communication between stakeholders
- Incorrect estimation of timelines and project costs
- Use of the wrong SDLC model
- Irregular and unclear changes in the project’s scope
- Insufficient quality assurance
- Lack of proper documentation
Orim Dominic Adah
Orim Dominic Adah is a web developer and a technical writer with more than four years of experience. He is focused on building functional, maintainable software that delivers business value.
Article by Gigson Expert
