What does the SDLC acronym stand for in software development?
SDLC stands for Software Development Life Cycle and is the process used by the software industry to analyze, develop and test any piece of developed software. The goal of SDLC is to organize the core processes of the software development process, so that the final result is of the highest quality in the given situation (a combination of, available budget, the business cases for the software, development time limitations, plus the professional level of the software architects and engineers involved into the process).
To illustrate this, here is a graphical representation – a simplified SDLC process stage diagram:
Business prerequisites are acknowledged in this phase.
Meetings with supervisors, partners and customers are held to decide the prerequisites like:
These are general inquiries that get replied during the prerequisites acknowledgment stage.
A Requirement Specification document is then created to serve the purpose of guideline for the next phase of the cycle. It usually consists of the following:
The stage of requirements analysis is the most important in SDLC. It is usually performed by the senior members of the software development team along with 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 case and the potential positioning of the software being developed against the products of competitors, (assuming they exist in the market).
The outcome of this stage, usually, is the SRS document, which stands for Software Requirements Specification.
At this stage, the identification of the development risks as well as the quality assurance methodology baseline is decided upon.
The outcome of the analysis stage is to define the technical solutions which will lead to the success of the project with minimum risk.
In our simplified model, we assume that after Stage 1, the requirements analysis, the leader of the project writes down the decisions that were taken and develops the so-called Software Requirement Specification (SRS) document. The SRS is the reference guide for the software architects to deliver the best possible result for the given software.
The outcome of the work of the software architect(s) is the System Design Specification (SDS). This document sometimes is also called the Design Document Specification (DDS). The best scenario is that the SDS is reviewed by the important stakeholders of the project from different outlooks, 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 outlines the architectural modules of the product as well as data flow and communication diagrams within the product itself, in addition, it specifies any third-party integration that is relevant to the product.
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 within a very short timescale, then this can adversely affect the quality of the final software. Quality also depends heavily on the analysis capabilities of each individual taking part in the coding process, as does having a properly prepared SRS and SDS.
The more experience and brain-power the analysts, architects and developers have, the less time and documentation is needed in the design phase.
Although this stage is called testing, in real life, the situation is that faults found in the software in the testing phase, lead back to the development phase and then back to the testing phase in circles, until the software finally reaches the necessary quality. The testing phase normally consists of two internal phases:
Ignoring the technical side of this phase, this is when the software is released to the alpha/beta or stable state and feedback starts to come in. Analysis of the feedback can then lead to second third or fourth iterations of the SDLC which means, the process is continued again with phases 1, 2, 3, 4 and 5, gradually eliminating any 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 a 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.
There are quite a few software development life-cycle models out there that you can follow and use. Each model follows a series of unique steps, with the ultimate aim of ensuring the success of the software development.
Here are some of the most popular SDLC models in industry:
Since the origin of information technology, many approaches to software development have been used. But all approaches fall into two major categories.
“Traditional” methodologies (e.g. waterfall) are sometimes called software development life cycle (SDLC) methodologies because they have distinct phases. However, this term can be used in a general sense for any methodology.
There is also a distinction between a “life cycle” approach and an agile approach, which define a process of iteration, but where design, construction, and deployment of different pieces can occur simultaneously. In any case, it is up to a management or development team to decide which approach (or combination of approaches) they will use.
The idea is not to follow a specific model from the list and master it to its tiniest details. “One 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 detail) fail badly, perhaps because they apply the same approach to each and every product they develop. Faults in the Requirements analysis and Design stages could have the possible effect of throwing them back by one year of development in any given enterprise project. If an agile or prototyping approach was chosen back then, this wouldn’t have happened.
We believe that the true art of this domain is when you are able to combine models or even apply something very specific to each project, based on conditions, requirements and expectations.
So, In conclusion, the correct choice of SDLC in any specific project can only be made by analyzing the project and also the SDLC itself! In other words, when we start a new project, we also decided what SDLC to use for that project in order to make it successful.