The SDLC: phases, popular models, benefits & more

By Dave Swersky |

| 10 min.

(

1969

words)

The Software Development Life Cycle (SDLC) refers to the process we follow to deliver software to customers. It captures each step of creating software, from ideation to delivery, and eventually to maintenance.

In this post, we’ve broken down everything you need to understand the SDLC:

History of the SDLC

The profession of software developer has existed since the first computers and their operators, as far back as ENIAC and vacuum tubes. As the disclipine has matured, practices and methods for developing software have evolved.

Those methods have progressed alongside advances in hardware, development tools, and modern thinking about the organizational management of software development teams. New software development methods have grown out of private and public software projects.

These methods vary widely in approach, but share a common goal: to develop software cheaply, efficiently, and effectively.

What is the SDLC?

Software is a complex product developed and delivered through a series of steps. All development begins the same way; software, like all products, starts as an idea. The idea becomes a document and maybe a prototype and will exist in a few forms before getting into the hands of an actual user.

Whether a document, diagram or working software, the output created in one step becomes the input to the next step. Eventually, the development team delivers the software to the customer. We call this sequence the Software Development Lifecycle (SDLC.)

How does the SDLC work?

The process of software development is never-ending. The first release of a software application is rarely “finished”; there are always more features and bug fixes. After deploying your code, you continually recieve reports from users and through error monitoring and crash reporting. These issues become new features, bug fixes, and improvements to your product.

Benefits of the SDLC

“If you fail to plan, you are planning to fail” – Benjamin Franklin

You can’t conduct a complicated team project like development without a plan. Each software development practice provides a framework for developing, delivering, and maintaining software. There’s 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.

Developing software without a structured plan is herding cats. Developers don’t know what features to code. Project managers have no idea how to measure progress. And the business doesn’t have a way to decide whether the final product meets its requirements.
A formally defined method for software development achieves several 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

The Seven Phases of the SDLC

Click here to jump to the 7 Phases of the SDLC infographic.

The steps in the SDLC process are roughly the same from one methodology to another. They tend to occur in this order, though some processes combine or execute them 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.

1. Planning

The planning phase involves project and product management. This may include:

• Resource allocation (both human and materials)
• Capacity planning
• Project scheduling
• Cost estimation
• Provisioning

Ideally, Project Managers and Development staff collaborate with Operations and Security teams to ensure all perspectives are represented.

The outcomes of the planning phase includes:

• Project plans
• Schedules
• Cost estimates
• Procurement requirements

2. Requirements

The business must communicate with tech teams to convey their requirements for new development and enhancement. The requirements phase gathers these parameters 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 involves the actual coding to produce the software itself. 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, the aim is for development teams to 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.

5. Testing

The testing phase of the SDLC is 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. The output of the testing phase is improved software, ready for deployment to a production environment.

6. Deployment

The deployment phase is, ideally, highly automated. In high-maturity enterprises, this phase is almost invisible; software is deployed the instant it is ready.

For 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.)

SDLC from start to finish

Use this infographic on your blog post

Embed 7 Phases of the SDLC on Your Site: Copy and Paste the Code Below

Use this infographic on your blog post

Popular SDLC models

The two best-known methodologies within the SDLC are Waterfall and Agile. Below is a brief explanation and how they relate to the SDLC.

Waterfall

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. 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 doesn’t 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.

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.

SDLC Practices

Waterfall is still used by many development teams around the world. However, Agile is rapidly gaining ground. Within either method, certain practices can reduce risk and increase the chances of success.

Source control

The importance of a central source control repository can’t be overstated. Development teams that do not use source control are taking risks, both with their code and their process. Using source control reduces risk by ensuring that work (code) is gathered 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.

Continuous integration

The purpose of Continuous Integration (CI) is to keep the software in a functional state. Prior to the rise of CI, development teams would write thousands of lines of code, then attempt to integrate them. 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, work stops until the build is successful. This prevents errors and defects from progressing into software that should be as bug-free as possible.

SDLC Management systems

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.

Conclusion

All software begins as a concept, and progresses 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 pulling ahead. Whichever method you choose, use the right tools for the job. Software is difficult to deliver reliably without them. There is no perfect method, but it’s far better to use some method than none.

Related links:

Software intelligence

Software development tools

Solving software errors