Understanding the Phases of the Software Development Life Cycle
While the technologies, methods, and perspectives about building high-performance and scalable software services have changed, the responsibilities and actions have not. The Software Development Life Cycle (SDLC) is a series of important phases defined for teams producing and delivering high-quality software. This blog post will discuss the SDLC and its stages in greater detail.
What is the Software Development Life Cycle?
The Software Development Life Cycle refers to the phases of work involved in producing software applications. Each phase corresponds to a role or responsibility that contributors to the software must understand, manage, and optimize to deliver their software services with speed and performance. These stages of work include:
- Requirements Gathering,
- Software Design,
- Software Development,
- Test and Integration,
- Deployment,
- Operationalization and Maintenance.
Let’s discuss each stage of work in greater detail.
The Phases of the SDLC
Requirements Gathering
In this stage of work, the team identifies, gathers, and defines current problems, requirements, requests, and customer expectations related to the software application or service.
Some activities related to the requirements gathering phase can involve creating software specifications, creating a detailed plan, documentation, issue tracking, and project or product planning, including allocating the correct resources.
Defining software or product requirements gives teams the foresight and context needed to deliver and produce their software solutions.
Software Design
In this design phase of work, the team makes software design decisions regarding the architecture and make of the software solution. This can involve creating design documents, coding guidelines, and discussing the tools, practices, runtimes, or frameworks that will help the team meet the software requirement specification and goals defined in the requirements gathering phase.
Software Development
In this stage of work, teams build the software solutions based on the design decisions made. Here, teams meet the goals and outcomes set during the software requirements gathering phase by implementing the solution.
The development process may involve teams of people, new technologies, and unexpected challenges; however, the development teams typically work with tech leads and product or project managers to unblock the process, make decisions, or provide support. This stage of work ends once teams have packaged and built their code.
Test and Integration
In this phase of work, a software implementation is packaged and tested to assure quality. Testing or quality assurance ensures the solutions implemented pass the standard for quality and performance. This can involve unit testing, performing integration and end-to-end tests, verification/validation, and reporting or identifying bugs or defects in the software solution.
Deployment
In this stage of work, the software is deployed into a production environment. The work gathered, designed, developed, and tested is shared with the consumers and users of the software service. This process involves provisioning infrastructure within an on-premise or cloud provider and defining a software deployment strategy for delivering the changes to a customer.
If you want to learn more, we break down deployment strategies and discuss when and why to use each type.
Operationalization and Maintenance
In this stage of work, the software is operationalized to ensure there are no issues or incidents related to the deployment. This stage of work can involve reviewing, understanding, and monitoring network settings, infrastructure configurations, and performance of application services in production. This process can involve incident resolution or management in the course of any issues or changes made to impact a customer or user base.
Why Does the SDLC Matter for Software Delivery?
Now that we know more about the work associated with each part of the SDLC, we can discuss why it matters and how it applies to how we deliver software today. For many organizations, a challenge is delivering better software faster. Understanding the SDLC allows teams to understand what it takes to deliver features or code changes to customers.
The reality for many developers is the need to wait months or years to see code changes make it out to users, coupled with a lack of visibility, communication, and collaboration during the process. Organizations and teams that have the capability to deploy on-demand and in a self-service fashion empower their teams to continue doing their best work.
Our Continuous Delivery 2020 Insights report found that engineering teams spend on average $109,000 annually to deploy and deliver their software applications. Production deployment efforts result, on average, to 25 hours of engineering effort.
The SDLC offers perspective into the distinct work phases needed to produce software. Understanding this work allows teams to avoid the delivery issues by creating and owning checks and balances early on in our development and delivery life cycle.
This is also about incorporating feedback and insights during the software development process to continuously deliver value in a repeatable, quick, and sustained fashion.
Understanding the SDLC allows teams to also improve their DevOps performance, which can be measured through DORA metrics.
Examples of a Software Development Life Cycle Model
Computer scientists, software development practitioners, and leaders have always aimed to deliver better software faster. Over time, several models (such as waterfall, spiral, Agile) emerged to describe and represent the SDLC processes and manage the level of development complexity as demand, tools, processes, and mindsets changed.
Waterfall Model
Perhaps one of the earliest models used to represent the process for delivering software is the waterfall model, developed in 1956. In this model, a chain of linear sequential phases represents the activities for delivering software.
Each phase depends on the delivery and execution of the previous phase, where each phase contained a set of tasks. This model originated from the manufacturing and construction industries and was adopted for knowledge or project-based creative work.
The drawback of this model is its dependencies. Since progress flows in one direction, there was little room to adjust to newly-discovered constraints, requirements, and problems once design decisions were made and implementation began.
Delivering all the software would also lead to increased costs as changes in requirements would lead to major redesigns, redevelopment, and retesting. These drawbacks lead to modified waterfall models, such as the Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction.
Iterative and Incremental Model
In response to the perceived problems with the waterfall model, organizations such as the United States Department of Defense released statements, such as the MIL-STD-498, encouraging “Iterative and Incremental Development.” This led to the term that would combine both iterative design and incremental development patterns.
In this model, the software is developed and delivered through repeated cycles of smaller portions of work. This model allows for software teams to take advantage of learnings and insights made earlier on in the process from developing and using the software system. Teams at each iteration of work make the necessary design modifications and additional functional capabilities.
NASA’s 1960s Project Mercury is an example of the early usage of the Iterative and Incremental Development model. The success of the project later led to further adoption as Project Mercury’s engineers took to other teams and projects.
Although the origins of the iterative model stem from the software industry, many hardware and embedded software development efforts are now using iterative and incremental techniques (for example, companies such as SpaceX and Rocket Lab).
The Evolution of Process Models
Following the success of Iterative and Incremental software development methods, other software development methods emerged to leverage more project management principles and development practices.
The spiral model is one risk-driven development model that encourages project teams to deliver based on unique project risks, leveraging one or many elements of other delivery methodologies. In the 1990s, the Agile manifesto led to the adoption and popularity of the Agile model and subsequent Agile methodologies.
Today, we have the DevOps Life Cycle, representing the SDLC and our goals to continuously deliver software value as a cross-functional team.
How you develop or deliver is up to you. What’s important is knowing what is involved in the process. This blog post discussed the software development lifecycle and the SDLC models that emerged to allow us to build and share our software services today. Good luck to everyone who manages or is a part of a project life cycle!
Expand Your Knowledge of SDLC Tools
Domain experts, architects, systems developers, engineers, and leaders all have a stake in delivering great software. If you’d like to learn more about delivering software value, we recommend getting more in tune with the state of the Kubernetes ecosystem.
We have created an in-depth eBook that you can download for free, which you will learn about Kubernetes architecture, options for running Kubernetes across a host of environments, key open source projects in the Kubernetes ecosystem, adoption patterns of cloud-native infrastructure and tools, and more.
Download your free copy of Kubernetes eBook now.