The Software Development Life Cycle (SDLC) is a terminology used to explain how software is delivered to a customer in a series if steps. These steps take software from the ideation phase to delivery.
We’ve broken down everything you need understand the SDLC from a high level, including:
- History of the SDLC
- What is the SDLC, and why did it evolve?
- How does the SDLC work?
- Benefits of the SDLC
- The seven phases of the SDLC
- Seven phases of the SDLC infographic
- Popular SDLC models
- SDLC best practices
- SDLC management systems
The profession of “software developer” has existed since the first computers, and their operators, as far back as the days of ENIAC and vacuum tubes. Practices and methods for developing software have evolved over the decades since the invention of the computer.
Those methods have adapted to the state of the art in computer hardware, development tools, and modern thinking about the organizational management of software development teams. With this progress, new methods of software development have grown out of private and public software development efforts around the world.
These methods vary widely in approach, yet they share a common goal: to develop software as cheaply, efficiently, and effectively as possible.
Software is a complex product that is developed and delivered through a series of steps. That is the one thing all the various methods have in common: one way or another, software, like all products, starts as an idea. The idea then becomes a document, or perhaps a prototype, depending on the method in use.
Whether a document, diagram, or working software, the artifact created in one step becomes the input to the next step. Eventually, the software is delivered to the customer. The sequence of steps used by these methods is commonly referred to as the Software Development Lifecycle (SDLC.)
The process of software development is a never-ending cycle. The first release of a software application is rarely “finished.” There are almost always additional features and bug fixes waiting to be designed, developed, and deployed.
Reports from error monitoring software about usability and bugs feed back into the process of software development, and become new feature requests and improvements to existing features. This is why the Software Development Life Cycle is the most general term for software development methods. The steps of the process and their order vary by method. Regardless of method, they typically run in cycles, starting over with each iteration.
“If you fail to plan, you are planning to fail” - Benjamin Franklin
It’s very difficult to carry out a complex, team effort such as software development without some kind of plan. Each software development methodology (several will be detailed below) is a plan framework for how to develop software. There is much debate about which method is best overall, which is best suited to a particular type of software, and how to measure success in software development. One thing, however, is certain: any plan is better than no plan.
Without some kind of structured plan, software development teams tend to devolve into a “herd of cats.” Developers don’t know what they’re supposed to create. Project managers have no idea how much progress is made towards completion of a project. Without a plan, the business doesn’t even have a way to decide whether the final product meets their requirements.
A formally defined method for software development in the form of the SDLC achieves a number of benefits:
- A common vocabulary for each step
- Defined communication channels between development teams and stakeholders
- Clear roles and responsibilities among developers, designers, business analysts, and project managers
- Clearly-defined inputs and outputs from one step to the next
- A deterministic “definition of done” that can be used to confirm whether a step is truly complete
These steps are (very) roughly the same from one methodology to another. They tend to occur in this order, though they can also be mixed together, such that several steps occur in parallel.
As we’ll discuss later, Agile methods tend to “wind together” all of these steps into a tight, rapidly-repeating cycle. Waterfall methods tend to take each of these steps in turn. Outputs from one become inputs to the following step.
The planning phase involves aspects of project and product management. This may include:
- Resource allocation (both human and materials)
- Capacity planning
- Project scheduling
- Cost estimation
The outputs of the planning phase include: project plans, schedules, cost estimations, and procurement requirements. Ideally, Project Managers and Development staff collaborate with Operations and Security teams to ensure all perspectives are represented.
The business must communicate with IT teams to convey their requirements for new development and enhancement. The requirements phase gathers these requirements from business stakeholders and Subject Matter Experts (SMEs.)
Architects, Development teams, and Product Managers work with the SMEs to document the business processes that need to be automated through software. The output of this phase in a Waterfall project is usually a document that lists these requirements. Agile methods, by contrast, may produce a backlog of tasks to be performed.
3. Design and prototyping
Once the requirements are understood, software architects and developers can begin to design the software. The design process uses established patterns for application architecture and software development. Architects may use an architecture framework such as TOGAF to compose an application from existing components, promoting reuse and standardization.
Developers use proven Design Patterns to solve algorithmic problems in a consistent way. This phase may also include some rapid prototyping, also known as a spike, to compare solutions to find the best fit. The output of this phase includes:
- Design documents that list the patterns and components selected for the project
- Code produced by spikes, used as a starting point for development
4. Software development
This phase produces the software under development. Depending on the methodology, this phase may be conducted in time-boxed “sprints,” (Agile) or may proceed as a single block of effort (Waterfall.) Regardless of methodology, development teams should produce working software as quickly as possible. Business stakeholders should be engaged regularly, to ensure that their expectations are being met. The output of this phase is testable, functional software.
The testing phase of the SDLC is arguably one of the most important. It is impossible to deliver quality software without testing. There is a wide variety of testing necessary to measure quality:
- Code quality
- Unit testing (functional tests)
- Integration testing
- Performance testing
- Security testing
The best way to ensure that tests are run regularly, and never skipped for expediency, is to automate them. Tests can be automated using Continuous Integration tools, like Codeship, for example. The output of the testing phase is functional software, ready for deployment to a production environment.
The deployment phase is, ideally, a highly automated phase. In high-maturity enterprises, this phase is almost invisible; software is deployed the instant it is ready. Enterprises with lower maturity, or in some highly regulated industries, the process involves some manual approvals. However, even in those cases it is best for the deployment itself to be fully automated in a continuous deployment model. Application Release Automation (ARA) tools are used in medium and large-size enterprises to automate the deployment of applications to Production environments. ARA systems are usually integrated with Continuous Integration tools. The output of this phase is the release to Production of working software.
7. Operations and maintenance
The operations and maintenance phase is the “end of the beginning,” so to speak. The Software Development Life Cycle doesn’t end here. Software must be monitored constantly to ensure proper operation. Bugs and defects discovered in Production must be reported and responded to, which often feeds work back into the process. Bug fixes may not flow through the entire cycle, however, at least an abbreviated process is necessary to ensure that the fix does not introduce other problems (known as a regression.)Use this infograhic on your blog post
The two best-known methodologies within the SDLC are Waterfall and Agile. Below is a brief explanation and how they relate to the SDLC.
The Waterfall method of software development follows a rigid, predetermined path through a set of phases. This method was adapted from traditional engineering. Ironically, the paper credited as the origin of the Waterfall method, describes it as being fundamentally flawed. The method that is known today as “Waterfall” was mistakenly derived from a misunderstanding of this original work. Despite that fact, Waterfall became a very common, even standard methodology for large projects around the world.
Waterfall methodology begins with long planning and design phases. Once developed, the software then goes through phases of testing, and is finally deployed for use. Waterfall is considered by many to be too rigid to adapt to changing requirements. It does not support feedback throughout the process, leading to the implementation of requirements that may have changed during the development effort. This weakness in Waterfall led to the development of more flexible methodologies, such as Agile.
The Manifesto for Agile Software Development was drafted and signed by a group of software developers in 2001. Reading the manifesto, you can see clearly the contrast between Waterfall, then the de-facto standard for development methods, and Agile, the newer method.
The Manifesto addresses key problems with Waterfall that led to challenges in software delivery. Where Waterfall tends to be a “one-way road,” Agile is a more flexible framework that allows for uncertainty. Agile emphasizes teamwork, prototyping, and feedback loops that can change the direction of the development effort in response to changing requirements.
Several variants of Agile have emerged since the signing of the Manifesto. Scrum defines specific roles and events, known as ceremonies, as part of its practice. Kanban is simpler, with fewer prescriptions and more flexibility. Agile teams often combine these together to adapt a bespoke process that fits them best.
Waterfall is still used by many companies around the world, however, Agile is rapidly gaining ground. Regardless of the method used, there are practices that reduce risk and increase the chances of success.
The importance of a central source control repository cannot be overstated. Development teams that do not use source control are taking risks, both with the code, and their process. Using source control reduces risk by ensuring that work (code) is gathered together in a single place, on a regular basis. If a developer workstation or file server fails, the central repository saves the day. Modern Source control systems also support Continuous Integration.
The purpose of Continuous Integration (CI) is to keep the software in a functional state. Prior to the common use of CI, development teams would write thousands of lines of code, then attempt to integrate them. This integrating that much work all at once is tedious, painful, and prone to error. CI is an automation that builds software every time the code changes. If there is a problem, the CI system alerts the developers. Following proper CI practices, no further work is done until the build is successful. This prevents errors and defects from progressing into software that should be as bug-free as possible.
Large, complex software development efforts can be unwieldy and difficult to track. An entire class of software systems has grown around this problem: Application Life Cycle Management. The larger the effort, the more indispensable these systems become. They offer features in work management, bug tracking, and analytics to assist in decision making.
All software begins as a concept, and flows through a series of phases until a release is developed and deployed. The Software Development Life Cycle of an application or system continues, with updates and new features, until the day it is decommissioned or replaced. Several methods for software development have evolved over the decades.
Waterfall methods are still common, though Agile is rapidly overtaking it in companies large and small. Whichever method you choose, use the right tools for the job. Software is difficult to delivery reliably without them. There is no perfect method, but it’s far better to use some method than none.