The development process can be broken into seven distinct phases that transform high-level plans into production-ready software. Learn how to approach each phase of the SDLC.
Modern approaches to software development involve a distinct set of processes. Understanding those processes is a critical first step in getting started with software development. They provide detailed, repeatable guidelines for bringing a software project to fruition and maintaining it once deployed.
To understand the seven stages of the SDLC, developers should have a firm grasp on what each stage involves, why it's important and criteria for moving onto the next stage.
The 7 stages of the SDLC
There is a bit of variation in the number of stages. Some contend that there are just five or six main steps in the SDLC, for example. There's also varying terminology regarding what each stage is called.
However, the general consensus is that there are seven basic stages in the SDLC.
Stage 1. Planning
The first stage of the SDLC is planning. The purpose of this stage is to develop a basic plan about what an application needs to do based on business requirements.
Development teams formulate high-level plans during this stage. They don't lay out exactly how to implement certain features or functionality or which programming languages are involved.
Instead, teams set basic goals for application features and outline business challenges the features address during this stage. Planning is also a time to identify any unrealistic goals that should be set aside. For instance, consider an application that can't address a business need because of insufficient resources. Development teams should communicate that during this stage, rather than wasting time at a later stage trying to implement a feature they ultimately abandon.
Since aligning technical goals with business priorities is a key focus of the planning stage, the ability for developers to communicate effectively with business stakeholders is essential during planning.
Once development teams have a clear understanding of what the application's purpose is and which features are needed to serve that purpose, the planning stage is complete.
Stage 2. Analysis
The analysis stage of the SDLC is where development teams translate high-level plans and goals into actionable ideas. To do this, teams perform a technical analysis of the plans they developed in the previous stage and determine how best to implement them.
For example, if a team's goal is to prioritize application security, they use the analysis stage to decide which application architecture and programming language best meet that goal. Teams might also examine the features they're planning to implement and decide based on that analysis whether to implement each feature as its own microservice or use a monolithic architecture.
The end goal of the analysis step is to have a technical plan that teams can begin putting into action. Line-by-line detail about how to implement code isn't necessary, but teams should know exactly which tools and processes they'll use as they build the app.
Stage 3. Design
The design stage focuses on deciding how the application behaves and what it looks like from the user's perspective. For example, if the application has a GUI, teams should sketch what that interface looks like in this stage. Teams should also consider whether users need to register accounts to use the app and, if so, whether there are different types of accounts, such as admin and nonprivileged accounts, for different users.
The design stage draws on technical specifications for the app that teams established during the analysis stage. In fact, some descriptions of the stages of the SDLC treat analysis and design as a single phase. However, because analysis focuses more on technical requirements, while design focuses on UX, developers should separate these processes into two stages.
The design phase is complete when teams have a clear understanding of how users interact with the app.
Stage 4. Implementation
The implementation stage -- also sometimes referred to as the development or coding stage -- is where teams write the actual code. This can be the lengthiest stage of the SDLC if there is a lot of complicated code to write. But it can also be relatively short, especially if teams accelerate code implementation using methodologies such as low-code/no-code or AI-assisted development.
Either way, it's important to establish clear processes for managing code as developers write it during implementation, especially if there are multiple developers working at once. Teams often use a CI server, which merges newly written code into a shared codebase and helps ensure that the code implemented by one developer doesn't cause conflicts with code written by others.
In addition, teams should set clear expectations about coding style and conventions to ensure that all the code is consistent. This also improves developers' ability to maintain or update code that they did not write themselves, which is an important consideration if teams plan to use the application for a period of years during which the original developers may depart the organization.
Implementation is complete once teams have written all the code required to achieve the application's planned functionality. Note, however, that teams may need to come back and adjust some code later, based on the outcomes of the tests performed in the next stage.
To test efficiently at scale … teams should automate as many tests as possible using test automation frameworks, such as Selenium and Cucumber.
Stage 5. Testing
After teams have written code, they're ready to test it. Software tests assess how well an application meets goals in areas such as the following:
Performance, which means how responsive the application is.
Load, which refers to the app's ability to perform as demand fluctuates.
Security, which involves detecting security vulnerabilities that may exist in the app.
Usability, which ensures that the application provides acceptable UX.
Teams should design tests that align with the goals established during the first three stages of the SDLC. After they design the tests, teams should run the tests and identify results that don't meet expectations. If an application doesn't pass all tests, teams may need to update some of the code from the previous stage to fix the issue and then run the tests again.
Teams can test software manually. For example, teams can perform manual performance tests by checking how fast an application responds to a given request. To test efficiently at scale, however, teams should automate as many tests as possible using test automation frameworks, such as Selenium and Cucumber.
Once the application has successfully passed all tests, the testing phase is complete.
Stage 6. Deployment
Deployment is the stage where the application moves into a production environment, where it is accessible to end users.
If the app is hosted using a SaaS model, teams deploy the app into a production hosting environment and then configure network firewalls or load balancers so that all requests for the app are directed at that environment.
If the app runs locally on users' devices, deployment entails packaging it and distributing the packages to users through channels, such as an app store, where they can search for and download applications.
To mitigate the risk of pushing buggy apps into production, teams should consider methods such as blue/green deployment, which helps to switch over to a new version of an application in a gradual, systematic way, and canary releases, which push out new versions of an application to some users before others, in order to identify bugs before they impact the entire user base.
Containerized applications can also help reduce deployment risks. Containers provide nearly identical hosting environments, no matter where they are deployed. If an application ran in a container successfully during the testing stage, teams can expect it to operate correctly during deployment as well.
Once teams release the application to all target end users, deployment is complete.
Stage 7. Maintenance
The final stage of the SDLC is maintenance. The main goal of maintenance is to monitor the application on a continuous basis to identify issues that arise once it is in production. For example, if a certain type of request triggers an error, development teams should note that so they can fix the issue.
In addition, the feedback teams collect during the maintenance stage can help guide future updates to the application. Teams may find that a certain feature performs suboptimally, for example, and conclude that they should overhaul the feature in the next application update. In this sense, maintenance helps turn the SDLC into an iterative process, where each application release drives a new set of application updates, each of which passes through its own iteration of the SDLC.
The SDLC is a process used by developers to create secure and high-quality software.
Unlike the other stages of the SDLC, maintenance doesn't always have a clear end. It goes on indefinitely until people stop using the application or until a new version of the app replaces the old one -- in which case, teams transition to maintaining the newer version of the app.
Development models for the SDLC
Teams can implement the seven stages of the SDLC using a variety of different software development models – meaning design strategies that guide implementation and organize each set of changes to the application.
In the past, the most popular development model was the Waterfall model, which entailed pushing out changes to applications in large, infrequent iterations. Today, Waterfall has largely given way to Agile software development, which encourages teams to break application updates into small chunks of work and manage them using short sprints. Agile is often more efficient for developers because it lets them set small, manageable targets. It can also benefit users, who receive updates on a more regular basis and do not have to contend with huge application overhauls that hit them all at once.
There are other methods that combine some elements of Waterfall and Agile. For example, incremental development is similar to Agile in that it breaks application development goals into discrete units, but like Waterfall, this model doesn't necessarily emphasize frequent changes to applications.
There are also more extreme takes on Agile and Waterfall. For instance, rapid application development, or RAD, breaks development work into small projects. It's similar to Agile but more aggressive and generally works best for small teams.
The best development model for a given project depends on factors such as how fast teams want to implement changes and how many developers are working on a team. Waterfall may work well for developing new features for a legacy app where fast innovation is not a priority, for example, while Agile may help large teams work together more efficiently by breaking work into relatively small, easily manageable sets of tasks.
Chris Tozzi is a freelance writer, research advisor, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.
