The software development life cycle (SDLC) started to become a formalized process for software development in the 1960s. That’s pretty much when software systems started to exist. With its loosely defined development phases, the SDLC has become a software development term that gets a lot of people talking. The SDLC, however, is more of an acronym packed with meaning than a specification or framework for software development. Only when you use it within a specific software development model does the SDLC become clear and useful.
In this post, we’ll explore how the most common software development models use the SDLC. We’ll also examine how these SDLC models have aged over the years and consider some of the challenges the teams using them have faced.
To understand any term, including SDLC, we need to start with a definition so that we can be sure we’re talking about the same thing. So, let’s read the definition of SDLC from Wikipedia:
In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle (SDLC).
Over the years, the SDLC model has included the development phases planning, analysis, design, implementation, testing, deployment, and maintenance. You might find slight variations in different places, but they all amount to the same phases. These software development phases usually follow in this order, and most software people understand them as forming a flow of development from requirements all the way to working product.
Let’s take a quick look at each development phase and what tasks they contain.
Remember, the main purpose of the SDLC is to divide development effort into phases so that organizations or teams can develop larger systems. Over the years, development models have tried to incorporate technology advances, and teams have strived to complete and deploy new software versions more quickly. Thus software development has always pushed for ways to merge or shorten the SDLC phases because frequent requirement changes have themselves become a requirement.
So now, with a loose definition of the SDLC in our pockets, let’s see how this term gets applied to the most common development models.
Adapted from manufacturing and construction industries, the waterfall model’s main distinction is a sequential list of development tasks. Engineers accomplish these tasks in a specific order because each task depends on deliverables from previous tasks. This specific order of tasks makes the waterfall model more rigid. As Wikipedia puts it:
In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (“downwards” like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment, and maintenance.
Which types of projects still tend to use the waterfall model? Ones that involve building large systems that must pass complex regulation and compliance tests. However, the main challenge of the waterfall model is its limited ability to deliver smaller and independently testable software modules. Incremental software delivery has become more of a problem for a waterfall approach as the demand for fast delivery increases. Teams working on long projects often struggle with inserting new technology while developing software, but the waterfall model makes evaluating and integrating new technology even more difficult.
What do you do if your requirements change during development? The waterfall model can’t help you much because requirement definitions happen at the top of the waterfall.
When NASA was working on the Mercury mission, the requirements of the mission changed often. What did team members there do? They stayed away from the waterfall model and came up with another development model so they could deliver smaller chunks of functionality at a time. They called this the iterative approach.
Iterative software development is the development of a software system through repeated cycles (iterations), in smaller portions at a time (increments). It allows developers to learn from previous iterations and make changes to future iterations. This definition contains three key concepts that form the foundation of all modern agile software development methodologies.
Being able to deliver smaller portions allows the user to be involved in testing and acceptance during each increment and thus provide valuable feedback. Frequent feedback that can be incorporated during next iterations is invaluable during software development. Being able to incorporate feedback and apply corrections adds lots more flexibility during development.
However, the phases of the SDLC were all repeated for each iteration. You can think of the iterative SDLC model as a set of smaller waterfalls. As a result, the entire project has a lot less risk because each part is shorter and less complex.
Pressure for faster delivery cycles has pushed software development models to embrace change even more quickly. With advances in technology in the early 2000s, changing requirements became an actual requirement for software development. Delivering individually testable modules that are small and easily deployable has become the norm. As a result, the rigid requirements definition accomplished during the planning and analysis phase of the classic SDLC changed. Teams created requirements through team collaboration and frequent feedback. In addition, rapid testing of new functionality became crucial for fast delivery of software. An Agile definition looks like this:
Agile software development is various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.
All these pressures pushed developers and managers to adopt a different framework for the SDLC. There’s still a life cycle for software development, but it focuses on delivering testable software quickly. This is what the Agile model has brought to the table.
Now that we develop software in an agile way, we test and deploy a lot more often. Wouldn’t it be great if we could somehow automate these frequent tasks?
When you combine software development and software operations, you get a new word: DevOps. It’s become a strong player in the SDLC because it orchestrates all the software development activities. Through DevOps methods and tools, a development team creates and maintains an efficient infrastructure needed for all development tasks. Code change integrates into the code baseline, which builds, tests, and deploys. All of this is automatic…or as automatic as possible. DevOps ensures the infrastructure for automated testing happens every time the team delivers new code.
Now we have new buzzwords that actually mean something. Continuous integration, continuous delivery, and automated testing mean that when software changes get committed to the code repository, they are also tested automatically, integrated into the baseline, and automatically deployed for quality testing and even delivery…continuously. Modern tools such as Retrace help development organizations to automate many development tasks and gain real-time insights into the codebase.
The agile development model coupled with DevOps pushes at the boundary of the classic phases of the SDLC. Detailed requirement definition, normally performed during planning and analysis, has moved from complex diagrams to the code itself. Integration and testing have also become part of the implementation phase as they have been automated. And what about the actual delivery of software? Well, it’s been simplified. Now you can deploy working software frequently with a few steps, or even through complete automation.
The modern SDLC has evolved because the distinctions between its phases have blurred. All this evolution helps you focus on what matters: delivering quality software quickly to your customers.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
