In this guide, we’ll provide a brief overview of the software development life cycle (SDLC) and its seven distinct phases. We’ll also compare the different models used to describe the workflow of engineers.
Table of contents
What is the software development lifecycle (SDLC)?
Every software development team needs a guiding framework. This might come from a lightweight framework such as scrum or a traditional heavyweight framework such as the software development lifecycle (SDLC).
The SDLC is a methodology that involves multiple steps (also called stages) that enable software development teams to produce low-cost and high-quality software products.
The development team often owns the SDLC. They use the SDLC alongside the engineering manager to organize their workflow. However, the SDLC is also a part of the holistic product development framework.
The product manager is typically involved in the SDLC in the same way as any other framework. Product managers:
- Ensure with the engineering manager and the development team that the SDLC is aligned with the business objectives
- Guard the team against any organizational obstacles
- Define the product vision and strategy and scope the features related to them in an unambiguous manner to avoid issues during the implementation
- Ensure that the product built during the SDLC aligns with the scope, schedule, and budget
- Remain actively involved during the testing stage to make sure the product produced adheres to the expected quality
What are the 7 phases of the SDLC?
Corporations use the SDLC to define, build, and maintain software products. It is a detailed process that creates a comprehensive outline for the engineers’ workflow.
The SDLC comprises seven phases (stages or steps) whose names and numbers differ from company to company and book to book. However, they all serve the same purpose.
The following phases are the most common within the SDLC model:
- Planning
- Defining requirements
- Prototyping
- Implementation
- Integration and testing
- Deployment
- Operations and maintenance
Planning
The work plan is constructed. The team members are assigned and the activities needed to build the software are defined (e.g., gather requirements, interview clients, conduct smoke tests, etc.).
Defining requirements
A detailed requirements document is prepared (e.g., product requirement document, product specifications document, etc.).
In traditional SDLC, the requirements should be supported by different product architecture diagrams such as use case diagrams, activity diagrams, sequence diagrams, component diagrams, composite structure diagrams, and interaction overviews.
Prototyping
The designers pass the requirements to create a very detailed prototype that covers every aspect of the user journey. The prototype should cover all possible cases, including error messages, status, and interactions.
Implementation
The engineers receive the requirements and the design from the other team members and the actual implementation work starts.
Integration and testing
The backend work integrates with the front-end work and the testers start executing their test cases to identify bugs or any potential issues.
Deployment
After successfully building the software, the team coordinates with the product manager to deploy the software to production.
Operations and maintenance
The team continuously identifies technical and functional enhancements to improve the product. This includes refactoring and bug bashing.
SDLC origins
The SDLC was initially introduced in a book called Global Business Information by Feoffrey Elliott. After it was proven successful by large organizations that develop business systems, countless software development companies started adopting it, and different variations of the SDLC model evolved over time.
SDLC models
The SDLC phases or stages can be used in various ways with multiple sequences. Organizing and reorganizing the steps of the SDLC will produce so-called models or methodologies.
Each model has its own advantages and disadvantages. SDLC methodologies are divided into traditional models and contemporary models:
- Traditional models — Frameworks or models that are distinguished by their linear nature, meaning that SDLC phases are carried out consecutively
- Contemporary models — Frameworks or models that are based on the iterative nature throughout SDLC phases to provide more adaptability during the production flow of the software. Those models have evolved into agile models down the road
Examples of traditional SDLC models
The SDLC has more than 10 traditional models, however the most popular models are the waterfall model and the spiral development model.
Waterfall model
The Waterfall model is one of the oldest SDLC models, known for its basic and classical structure. The stages of this model are fixed. Each phase must be completed before moving onto the next, which prohibits overlapping. The output of each stage is an input for the next stage.
Phases of the waterfall model
The six phases of the waterfall model are as follows:
Requirements
This phase concentrates on communicating with the users/end users to gather the requirements and to capture information regarding a user’s needs. The product manager, at this stage, defines and documents the scope of the project in a document called a business case.
Design
A business analyst evaluates the business case and starts the logical design of the software by using the requirements and information collected by the product manager. Based on the high-level design created by the business analyst, a system analyst translates the high-level design to a detailed low-level design that considers software and hardware technology.
A full user interface design with the system architecture is defined at this stage. A couple of documents are also produced to help the engineers understand the end-to-end expected output.
Subscribe to our product management newsletter
Get articles like this to your inbox
Implementation
Here, the actual code of the software system is written. Software developers create the system according to the instruction and requirements recorded, written, and prepared in the design and requirement phases. The output of this phase is the actual product.
Testing
This stage gets the input from the implementation stage. Software testers draft test plans based on the functional specification documented in the low-level design document (LLDD). On the other hand, software developers prepare testing plans in the form of a checklist to examine if every function is executable as expected.
Finally, quality assurance engineers gather all documents written in all phases and conduct an overall deep test on every specific aspect of the system.
Deployment
After passing all processes of the testing phase, the product is ready to release. The software system is either released for users to install on their own machine or deployed to production servers.
Maintenance
This phase focuses on enhancements, delivering changes, or fixing any defects and issues that may arise.
Application for the waterfall model
The waterfall model is most suitable for:
- Small and simple projects
- Projects with a limited number of unconfirmed and ambiguous requirements
- A software system that requires well-documented artifacts (e.g., issuance software)
Advantages of the waterfall model
The waterfall model helps to:
- Provide the team with the ability to detect errors early in the process
- Define the specific starting and ending point of the project. It ensures that the project deadline is in control
- Provide well-written and structured documents that make it easier to revise the code for future enhancements and scaling work
Disadvantages of the waterfall model
The waterfall model is limited by:
- The biggest disadvantage of this model is that there’s no way to go back to a specific phase. Once a phase is completed, it’s locked
- In some cases, estimating the required time to finish a phase is tough. An incorrect assumption may result in a failure to meet the deadline
- If changes are proposed during the execution of the project, the project has to stop and start all over again
Spiral development model
The spiral model is a risk-driven hybrid model that features some of the traits of the waterfall model and Iterative model. Based on the identified patterns of risk, the team can adopt specific activities of different processes.
Phases of the spiral model
Planning
Requirements are collected and the overall objective is identified during this phase. A business analyst collects and generally documents those system and business requirements.
Risk analysis
This phase is meant to identify any potential risk by planning the risk mitigation strategy. The project manager, team members, and end user collaborate to identify potential risks that may impact the project.
Engineering/implementation
The system is developed along with quality assurance checks and testing processes at this stage.
Evaluation
The product manager/end user in this phase is responsible for evaluating the system software, which is the output of the previous phases. The evaluation is done before the project proceeds to the next planned spiral cycle.
Application of the spiral development model
The spiral development model is suitable for projects that:
- Have a large or medium scope
- Come with high risk
- Are complex or unclear in requirements
Advantages of the spiral development model
- Flexible and easy to manage
- The process of monitoring the process effectiveness is easy
- Coping with the late proposed changes is easy for the product manager
- It eliminates the errors early during the project
Disadvantages of the spiral development model
- Not easy to implement. Needs high expertise
- Requires risk analysts paired with the development team continuously
- High in cost
- Meeting the scheduling and budgetary constraints is challenging with this model
Waterfall vs. spiral development
| Model | Waterfall | Spiral |
| Cost | Low | High |
| Flexibility | Rigged | Flexible |
| Cost control | Yes | Yes |
| Process simplicity | Simple | Intermediate |
| User involvement | Only at the initiation of the project | High and during different phases |
| Risk analysis | Only at the beginning | Throughout different phases |
| Adjusting the scope | Can kill the project | Costly but possible |
Final thoughts
The SDLC is a framework that was invented around 50 years ago. Since then, it has contributed to building tons of successful software products. Many companies later adopted it and started tweaking it to develop an effective process tailored to their needs. The SDLC, by its nature, was invented to save costs, build quality and complex software, and satisfy the end-user.
Currently, the SDLC is not as popular as before, especially with the rise of agile models and mindsets. However, having information about all those frameworks will allow product managers and product teams to build better processes that generate better results.
Source link
