Software development life-cycle (SDLC)

What does SDLC acronym stand for in software development?

SDLC stands for Software Development Life Cycle is a process used by software industry to analyse, develop and test the software. The goal of SDLC is to organize the core processes of the software development process, so that the final result gains the maximum quality it can get in the given situation (combination of the conditions, such as: available budget, knowledge-base over the business cases of the software, development time limitations, professional level of the software architects and engineers involved into the process).

Did you know?

  • SDLC is the acronym of Software Development Life Cycle.
  • It is also called as Software development process.
  • SDLC is nothing but a framework defining tasks to be performed in each software development phase
  • SRS stands for System Requirements Specification
  • SDS stands for System Design Specification
  • DDS stands for Design Document Specification

What does Software Development Life Cycle (SDLC) consist of?

The best is always to see some graphical representation, and here you go –  a simplified SDLC process stage diagram:

Software Development Life Cysle

Software Development Life Cycle

1. Requirement analysis

The stage of analysis of requirements is the most important in SDLC. It is usually performed by the senior members of the software development team, marketing and industry experts. This is the crucial part of the project where the software development team leadership must understand the essence of the software to be developed, the specifics of the business cases and the potential prevalence of the software being development over the products of competitors, assuming they exist in the market.

The outcome of this stage, usually, is SRS document, which stands for Software Requirements Specification.

At this stage also the identification of the risks takes place as well as quality assurance methodology baseline is settled down.

The outcome of the analysis stage is to define potential technical solutions which may lead to the success with minimum risk.

2. Design

In our simplified model, we assume that after the stage 1. Requirement analysis, the leadership of the project writes down the decisions that were taken and develop the so called Software Requirement Specification (SRS) document. The SRS is the reference for the software architects to deliver the best possible architecture for the given software.

The outcome of the work of software architect(s) is System Design Specification (SDS). This document sometimes is also called Design Document Specification (DDS). The best scenario is that SDS is then reviewed by the important stakeholders of the project from different facets, such as: risk assessment, product robustness, design modularity, budget and time constraints. The best design model is then discussed and selected for the product.

The design of the software clearly defines the architectural modules of the product as well as data flow and communication diagrams within the product itself, as well as between the product and 3rd party systems, it might integrate with.

3. Development

The complexity of this stage heavily depends on the outcome of the previous two stages. The better the SRS and SDS, the easier it is for the software engineers to develop the required software modules. It is no secret that if the first prototypes/versions of the software are required it a very near future, the quality of the final software also heavily depends on the analysis capabilities of each individual taking part in the coding process, as the analysts and architects then have lot less time to do their job on SRS and SDS.

The more experience and the brain-power the the analysts, architects and developers have, the less time and documentation is needed in Design phase.

4. Testing

Although, the stage is called Testing, the rel life process is that faults found in the software in Testing phase, lead to returning back to the Development phase and back to the Testing phase in circles, until the software reaches the necessary acceptance quality. The testing phase normally consists of two internal phases:

  1. automated unit/functional tests
  2. acceptance tests performed by a human

5. Deployment

Ignoring the technical side of this phase, this is when the software is released to the alpha/beta or stable state and feedbacks start to come in. Analysis of the feedbacks then can lead to second third or fourth iteration of SDLC which means, the process is continued again with phase 1, 2, 3, 4 and 5, to eliminate the issues that have been found in the released software.

The whole software development process can be also be planned over several iterations, especially, when it comes to Agile, where the main focus is to release some working product as soon as possible and implement different features later on. So, it doesn’t mean that going over several iterations always means bug-fixing or tuning. As I just mentioned – it can also be a pre-planned process.

SDLC models

There are quite many software development life-cycle models out there you can follow and use. Each model follows a series of steps unique to its type, in order to ensure success in software development.

Here are some of the most popular SDLC models in industry:

  • Waterfall
  • Agile
  • Iterative
  • Spiral
  • Rapid Application Development
  • Prototyping

The idea is not to follow some specific model from the list and master it to its tiniest details. “Ones size fits it all” is not the most efficient way of doing things.

I’ve seen large companies (which strictly followed Rational Unified Process (RUP) in all its details) shamefully failing, while trying to apply the approach to each and every project they developed. Faults in Requirements analysis and Design stages threw them back by one year of development in an enterprise project. If some agile or prototyping approach was chosen back then, it wouldn’t have happened.

We believe that true art of the domain is when you are able to combine the models or even apply something very specific to each project, based on conditions, requirements and expectations.

So, the conclusion we have come to is that correct choice of SDLC in every specific project can be made only by analyzing the project and SDLC itself! In other words, what we do when we start a new project, is we analyse what SDLC to use for that project to make it successful.