The software development life cycle, often shortened to the acronym SDLC, consists of standardised phases a software development team works through when developing a new product. The character and number of phases in a software development life cycle can vary depending on the software development methodology and framework a team is working to.
However, the most common SDLC structures are variations on the following phases:
SDLC can also stand for ‘system development life cycle’ when used more holistically to ensure security controls and requirements are designed rather than retrofitted into the software development process. When the ‘S’ of SDLC stands for ‘system’, it covers people, processes, software components, infrastructure, and change management.
It’s the more ‘general’ project management term while ‘software development life cycle’ has a targeted focus on just the software components.
Can We Help You With Your Next Custom Software Development Project?
Flexible models to fit your needs!
Defining and following the phases of a software development life cycle results in improved quality of resulting software product while simultaneously reducing the time needed to build and deploy it and reducing overall costs.
Following an SDLC achieves those gains for the software development process by:
In a word, no. Not every software development life cycle is the same. Different software development methodologies and frameworks have their own variations on the SDLC phases.
Some, for example Crystal, even leave flexibility for the team working on a software development project to set their own SDLC phases as they decide is most appropriate to the particular piece of software being developed.
For example, the Agile framework Extreme Programming (XP) follows a 5-stage software development life cycle:
The Feature Driven Development (FDD) Agile framework also defines five phases, but they are defined differently:
The Adaptive Software Development (ASD) Agile framework only defines three phases of the software development life cycle:
The Dynamic Systems Development Model (DSDM) approach to Agile has four:
Exactly how different software development approaches define their software development life cycle phases is, as can be seen, fluid.
When one framework defines seven or eight phases and another three, it doesn’t mean there are more or less overall steps involved. For example, because Adaptive Software Development has three defined life cycle phases and none is titled ‘testing’ or ‘QA’, it doesn’t mean software developed to the framework is not tested. Testing is simply seen as a step within the broad ‘collaboration’ phase, rather than its own phase.
K&C - Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?
Drop us a line to discuss your needs or next project
Despite the fact there is no single, definitive list of phases within a software development life cycle, there is still value in outlining those most commonly part of different methodologies and frameworks. Even if a particular software development methodology or approach doesn’t include a life cycle phase of the same, or similar, name, these 7 will be built into those that are named.
Planning and analysis processes are often conflated into a single software development life cycle phase. But they are just as often split out into two separate phases.
During this first phase, the business case for developing a piece of software is analysed. Among the questions that would typically be asked at this stage are:
Presumptions contained in the answers to these questions should be verified, preferably through methods like user focus groups, other market research tools, developing a technical prototype etc.
The project’s scope, or initial estimate of scope in an Agile approach, would be discussed here based on initial feature requirements or assumptions. As would planning of the resources needed to realise the project and then putting them in place, including the software development team.
Goals and limitations are set.
The software development team roles most typically involved in the planning and analysis phase of the software development life cycle (this varies from team to team and is influenced by the chosen methodology/framework) are:
Once the need for the software has been verified and its initial scope and requirements and resources expected to be needed are established during the analysis and planning phase, the design phase kicks in.
This is where software architects and developers make decisions on the high-level design of the software system. A tech stack will be chosen, like what languages, frameworks and libraries will be used on the front end and back end and other details like the choice of database technology and other third party services.
Decisions will also be made on infrastructure, like if the software will be cloud-hosted and if that will involve a public cloud, private cloud or hybrid approach and providers. Security requirements are an important part of the design phase and will inform many of the decisions taken.
Throughout the design phase, stakeholders should be consulted on tech stack choices, risks, resources required in the context of design decisions taken, time, budget, regulatory and other project constraints.
The scope and features of the MVP to be released first should also be decided upon here as it will inform the next phase – development.
Team roles central to the design phase of the SDLC include:
The development phase of the software development life cycle is where the product is coded and put together by developers. In an Agile approach, which most significant software development projects take, the first development phase of an iterative SDLF, will build the MVP.
In a Waterfall approach, what is seen as the finished product is documented in technical detail from beginning to end during the design phase and then build from beginning to end during the development phase.
The team roles most involved in the development phase are:
Software testing usually involves both manual testing of user journeys and experience as well as automated testing based on tools and scripts. If bugs or other defects are found, testers must document the issue and inform the development team who will create a new version of the software in which the issues have been resolved. That version of the software will then be tested again in case updates have had unintended consequences and created new bugs or defects.
In a DevOps approach to the software development life cycle, the development and testing phases are tightly integrated with testing a continuous process during development and could even be described as a single, unified phase.
The team roles most involved in the testing phase are:
The deployment phase sees a software application moved from its development and testing environments into a live environment where it is available to users. Deployment can be a relatively simple process or an extremely complex one, depending on the nature of the software. For example, if a new software product involves a database other systems will use, integrating them all could represent a significant undertaking.
A crucial step in the deployment phase is also making sure, which means testing, that the software works exactly the same way in the live environment as it does in the development and testing environments. In a DevOps CI/CD software development pipeline pre-deployment and live environments should be identical, minimising the risk of discrepancies between how the software runs. DevOps tightly integrates the development and deployment phases.
The most prominent team roles in the deployment phase of the SDLC are:
The maintenance phase involves making sure the software application continues to run as it is intended to in terms of functionalities, performance and availability. Users and ongoing testing may uncover bugs and other defects, or security issues, not found during the testing phase, which should be fixed. These may be minor or necessitate the launch of a new development phase.
The main roles in the maintenance phase are most ofter:
Unless a software development product is being built to the Waterfall methodology, the SDLC will be a looping, ongoing process and will restart after each iteration has been deployed, with work immediately beginning on the next iteration.
Once the software has reached a certain level of maturity, new iterations are likely to evolve smaller updates and become less frequent. Throughout an iterative software development life cycle, adjustments are likely to be made to the software development team to account for that.
The software development life cycle can and is adapted by software development teams based on the philosophy, methodology and framework they adopt when building a given software product, or between organisations.
Little, if anything, is written in stone, nor should it be. The SDLC is a tool in the project management box and should fit the needs of a particular project, the team working on it and other key stakeholders involved in the process. Phase names, their order, or if they are distinct or conflated into each other change.
But every software development project has a life cycle and you should now have a good understanding of its role in project management and as a tool used to improve outcomes.
When does IT Outsourcing work?
(And when doesn’t it?)