What is Software Development Life Cycle (SDLC)
Published by Pavel Nakonechnyy on in Business Analysis.
Software Development Life Cycle (SDLC) is the cost-effective and time-efficient process that development teams use to design and build high-quality software. The SDLC aims to produce software that meets or exceeds customer expectations, reaches completion within times and cost estimates, and poses minimal risk.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.
Here are some benefits of SDLC:
-
Increased visibility of the development process for all stakeholders involved
-
Efficient estimation, planning, and scheduling
-
Improved risk management and cost estimation
-
Systematic software delivery and better customer satisfaction
SDLC process is followed for each software deliverable by the project team. The life cycle defines a methodology for improving the quality of software and the overall development process. The stages of a typical SDLC include:
-
-
Product design.
-
Development.
-
Testing. Deployment.
-
Stage 1: Planning and Requirement Analysis
Requirement analysis is the most fundamental stage in SDLC. During this stage, the team processes inputs from the customer, the sales department, market surveys, and domain experts in the industry to plan the basic project approach and to conduct a product feasibility study in the economical, operational, and technical areas.
Planning for the quality assurance requirements and identification of the risks is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.
Business Analysts play one of the most important roles in this stage of the project. During this stage, they perform sizing, classify the problem, and identify requirements, opportunities and challenges, issues, costs, and possible benefits.
Some of the documents BAs create for Planning and Requirement analysis include Business Requirement Document, Vision Document, Pareto charts, Cause-and-Effect graphs, and ROI calculation.
Business Requirement Document (BRD) contains the high-level business requirements available for the business stakeholders‘ understanding. Sometimes this document is referred to as Business Requirements Specification.
Stage 2: Defining Requirements
At this stage, Business Analysts will prepare a Functional Specification Document (FRD). FRD describes How the system is going to function. It’s a technical response to the needs set out by the BRD and business objectives created during the planning phase of the project. FRD often employs diagrams in notations like Unified Modeling Language (UML), DFD, functional, or precedents. It includes several important parts: the context of a project (current state of the system), functional requirements, user interface, models (diagrams, flowcharts, prototypes, and mockups), and glossary. Its objective is to define the function of a system, identify dependencies, estimate risk and costs, improve internal project communications, and provide a holistic view of every requirement.
Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved by the customer or the market analysts. This is done through an SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle.
Software Requirement Specification (SRS) is a complete description of the behavior of a system to be developed. It describes all the user interactions with the system in terms of use cases. It includes complete business requirements, system properties, constraints, and behaviors, detailing the system’s reliability, response time, storage requirement, etc. It is used to estimate the cost and effort required for developing that software.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually, more than one design approach for the product architecture is proposed and documented in a DDS – Design Document Specification.
DDS is reviewed by all the important stakeholders and based on various parameters such as risk assessment, product robustness, design modularity, budget, and time constraints, the best design approach is selected for the product.
A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third-party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of details in DDS.
Stage 4: Building or Developing the Product
In this stage of SDLC, the actual development starts, and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code.
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing-only stage of the product where product defects are reported, tracked, fixed, and retested until the product reaches the quality standards defined in the SRS.
Stage 6: Deployment in the Market and Maintenance
Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeted market segment. After the product is released in the market, its maintenance is done for the existing customer base.
SDLC Models
There are various software development life cycle models which are followed during the software development process. The following are the most important and popular SDLC models followed in the industry:
-
Waterfall Model
-
Iterative Model
-
Agile Model
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.
In the Iterative model, the iterative process starts with a simple implementation of a small set of software requirements and iteratively enhances the evolving versions until the complete system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which is then reviewed to identify further requirements. This process is then repeated, producing a new version of the software at the end of each iteration of the model.
The agile model is a combination of iterative and incremental process models with a focus on process adaptability and customer satisfaction by rapid delivery of working software products. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross-functional teams working simultaneously. At the end of the iteration, a working product is displayed to the customer and important stakeholders.