Software Development Life Cycle (SDLC) | SDLC Model in Software Engineering

A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the software life cycle. It describes the different activities that need to be carried out to develop a software product and the sequencing of these activities.

A life cycle model graphically represents the different phases of a life cycle and their ordering accompanied by with textual description. Additionally, it may represent the various types of the activities carried out during a phase and the documents produced. We can therefore, define a life cycle model as follows:

A software life cycle model is a descriptive and diagrammatic representation of the software life cycle.

In other words, a life cycle model maps the various activities performed on a software product from its inception to retirement. Different life cycle models may map the necessary development activities to phases in different ways. Thus, no matter which life cycle model is followed, the essential activities are included in all life cycle models though the action may be carried out in distinct orders in different life cycle models. 

Need of Life Cycle Models (Why use a Life Cycle Model?)

A well-defined life cycle model helps to produce good quality products. A good software engineer should have enough knowledge on how to choose the SDLC model based on the project context and the business requirements. It may be required to choose the right SDLC model according to the specific concerns and requirements of the project to ensure its success.

The development team must determine a suitable life cycle model for a particular plan and then observe to it. The primary benefit of using a life cycle model is that it helps to developed a software in a systematic and disciplined manner

When a team is developing a software product, there must be a clear understanding among team representative about when and what to do. Otherwise, it would point to chaos and project failure. 

SDLC models might have a different approach but the basic phases and activity remain the same for all the models. A number of different SDLC models are used today to guide professionals through their project-based work.

Classical Waterfall Model:

The classical waterfall model is the basic software development life cycle model. It is very simple model. It is also known as a linear-sequential life cycle model. Earlier this model was very popular but nowadays it is not used. But it is very important because all the other software development life cycle models are based on this model. We therefore need to first understand the classical waterfall model well, in order to be able to develop proper understanding of other life cycle models.  It is not a practical model because it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software.

The classical waterfall model divides the life cycle into a set of phases. In this model one phase can be started after the completion of the previous phase. That is the output of one phase will be the input to the next phase. Thus the development process is seen as following steadily downwards like a waterfall through several phases. Here the phases do not overlap with each other.

Phases of Classical Waterfall Model:

The different sequential phases of the classical waterfall model are shown in the figure below: 

1. Feasibility Study: The main aim of this phase is to determine whether it would be financially and technically feasible to develop the software. 
The feasibility study involves understanding the problem and then determining the various possible strategies to solve the problem. These different identified solutions are analyzed based on their benefits and drawbacks.

 

Project managers or teams, leaders examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution. Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would meet the cost of the product and whether they have sufficient technical expertise in the area of development.

 

2. Requirements analysis and specification: The aim of the requirement analysis and specification phase is to understand the exact requirements of the customer and document them properly. This phase consists of two different activities. 

a. Requirement gathering and analysis: The aim of requirements gathering is to collect all relevant information from the customer regarding the product to be developed and then the gathered requirements are analyzed.

The goal of the requirements analysis part is to remove incompleteness and inconsistencies in these requirements. Once all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements have been properly understood, the requirements specification activity can start.

b. Requirement specification: The customer requirements identified during the requirements gathering and analysis activity are organized into a software requirement specification (SRS) document. SRS document serves as a contract between the development team and customers. Any future dispute between the customers and the developers can be settled by examining the SRS document.

 

3. Design: The goal of this phase is to convert the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. There are two design approaches being used at present: traditional design approach and object-oriented design approach.

 

4. Coding and Unit testing: In the coding phase software design is translated into source code. This phase is also called the implementation phase since the design is implemented into a workable solution in this phase.  Each component of design is implemented as a program module. The end-product of this phase is a set of program modules that been individually tested. After coding is complete, each module is unit-tested to determine the correct working of all individual modules. The aim of the unit testing phase is to check whether each module is working properly or not.  

5. Integration and System testing: Once the modules have been coded and unit tested, the Integration of different modules is undertaken. Integration of various modules is carried out incrementally over a number of steps. During each integration step, previously planned modules are added to the partially integrated system and the resultant system is tested. Finally, after all the modules have been successfully integrated and tested, the full working system is obtained and system testing is carried out on this. 

System testing consists of three different kinds of testing activities as described below: 

a. Alpha testing: Alpha testing is the system testing performed by the development team.

b. Beta testing: Beta testing is the system testing performed by a friendly set of customers.

c. Acceptance testing: After the software has been delivered, the customer performed acceptance testing to determine whether to accept the delivered software or reject it.

 

6. Maintenance: Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60% of the total effort spent to develop full software. Maintenance can be referred as a process of enhancement in the software product according to the changing requirements of the user.

There are three types of maintenance: 

 

a. Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered during the product development phase.

b. Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the system based on the customer’s request.

 

c.  Adaptive Maintenance: Adaptive maintenance is usually required for modifying the system to cope with changes in the software environment.

Iterative Waterfall Model:

Iterative Waterfall Model is the extension of the Classical Waterfall model. In a practical software development work, it is not possible to strictly follow the classical waterfall model. In this context, we can view the Iterative waterfall model as making necessary changes to the classical waterfall model to make it usable in practical software development projects. This model is almost same as the classical waterfall model except some changes are made to improve the performance of the software development. 

The iterative waterfall model provides feedback paths from every phase to its previous phases, which is the main difference from the classical waterfall model. 

When errors are detected at some later phase, these feedback paths allow correcting errors committed by programmers during some phase. The feedback path allows the phase to be reworked in which errors are committed and these changes are reflected in the later phases. There is no feedback path provided for feasibility study phase, so if any change is required in this phase then iterative model doesn’t have scope for modification or making corrections.

Feedback paths introduced by the iterative waterfall model are shown in the figure below:

Prototype Model:

The Prototyping Model is one of the most popularly used Software Development Life Cycle Models (SDLC models). Prototype is a working model of software with some limited functionality. A prototype is a toy implementation of the system.

Prototype model is a software development model in which a prototype of the end product is first developed, tested, and refined until an acceptable prototype is achieved. It creates base to produce the final system or software. This model is used when the customers do not know the exact project requirements beforehand. 

It works best in scenarios where the project’s requirements are not known in detail. It is an iterative, trial and error method which takes place between developer and client.

Spiral Model:

Spiral model is one of the most important Software Development Life Cycle models, which provides support for Risk Handling. The spiral model is a combination of waterfall model and prototype models. This model is best used for large projects which involve continuous enhancements. 

 

In its diagrammatic representation, it looks like a spiral with many loops. The exact number of loops of the spiral is unknown. The number of loops varies based on each project. Each loop of the spiral is called a Phase of the software development process. The exact number of phases needed to develop the product can be varied by the project manager depending upon the project risks. As the project manager dynamically determines the number of phases, so the project manager has an important role to develop a product using the spiral model. Using the spiral model, the software is developed in a series of incremental releases.

 

The Radius of the spiral at any point represents the expenses (cost) of the project so far, and the angular dimension represents the progress made so far in the current phase. 

The below diagram shows the different phases of the Spiral Model:

 Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The functions of these four quadrants are discussed below:

1. Objectives determination and identify alternative solutions:  Requirements are gathered from the customers and the objectives are identified, elaborated, and analyzed at the start of every phase. It is important to also identify alternative solutions in case the attempted version fails to perform.

 

2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution are identified and the risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution.

 

3. Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available.

 

4. Review and plan for the next Phase: In the fourth quadrant, the customers evaluate the developed version of the software. The project is reviewed, and a choice made whether to continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the next step of the project.

Iterative Model:

The iterative model is a software development life cycle (SDLC) approach in which the initial development is started based on the initial requirements that are clearly defined and subsequent features are added to the base software product through iterations until the final system is completed. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).

Unlike the more traditional waterfall model, which focuses on a step-by-step process of development stages, the iterative model is best thought of as a cyclical process.

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. It is specifically designed to start with the bare minimum requirements and only construct a portion of the program iteratively.

In this Model, we can start with some of the software specifications and develop the first version of the software. After the first version if there is a need to change the software, then a new version of the software is created with a new iteration. It will repeat until deployment of the software.