SDLC Models

SDLC Models

Overview:
There are several SDLC models to streamline the Software Development Process. Each model has its own advantages and disadvantages; and it depends on the organization to adopt the most appropriate one for the project. Sometimes a combination of models may be more suitable.
 of developing software from its inception to its final release and maintenance is known as Software Development Life Cycle (SDLC).

1.0    Classification of SDLC models

SDLC models can be broadly classified as below.

i.    Sequential models

a.    Waterfall model
b.    V-Model

ii.    Incremental/Iterative models

a.    Prototype model
b.    Spiral Model
c.    Agile Model

1.1    Sequential Models


In these models, Software development process is sequential and the development progresses through a number of well defined phases.
 

1.1.1 Waterfall Model

Overview

Waterfall model was launched in 1970’s and it was the first process model to be introduced and followed widely in Software development process. In this model, after each phase is finished, it proceeds with the next one. Thus the phases are strictly time sequenced and reviews may occur before moving to the next phase which allows for the possibility of changes.
Waterfall model has the following phases.



a.    Requirements Gathering

This is the first and most important phase. During this phase, requirements are gathered from the end-user by consultation; these requirements are analyzed and documented in an understandable form. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model.
These are the overall Business Requirements and it becomes input to prepare Software Requirements in next phase.

b.    System requirements

In this phase, business requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be developed is also studied. The requirements are documented which is called as System Requirements Specification (SRS) document and this becomes input to the Design Phase.

c.    Design

During the Design phase, High level and Low level designs are created based on SRS document. This helps in defining overall system architecture and detailed implementation of each component. These design specifications serve as input for the next phase of the model.

d.    Coding

During this phase, based on the design documents, the work is divided into modules/units and actual coding is started. Developers create programs for each module which are integrated into a complete system to check if all modules/units coordinate between each other and the system as a whole behaves as per the specifications. The output of this phase is software built according to a pre-defined coding standard and unit tested to satisfy the system architecture requirements.

e.    Testing

In this phase, Testers test the developed software to ensure that the system meets/satisfies the requirements. If there is any mismatch or deviation, testers report defects. These defects are analyzed and fixed by the developers. Testers validate the defect fixes and close them by performing confirmation testing (Regression Testing). After completion of the testing, the software is released to production/customers.

f.    Release and Maintenance
Release team installs software in customer environment and ensures correct and complete installation of the system.
Maintenance team processes customer issues based on service agreements. Also, the maintenance phase is never ending phase or very long phase. Generally, problems (which are not found during the development life cycle) with the system come up once the users start using it. Not all the problems come in picture directly but they arise time to time and needs to be solved. These are addressed by the Maintenance team.

Advantages of waterfall model

i.    The main strength of the waterfall model is its simplicity.
ii.    Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
iii.    Phases are processed and completed one at a time.
iv.    Works well for smaller projects where requirements are very well understood.

Disadvantages of waterfall model

i.    Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
ii.    No working software is produced until late during the life cycle.
iii.    The sequential nature of communication among the phases can introduce inordinate delays in resolving the problems.
iv.    High amounts of risk and uncertainty.
v.    Poor model for long and ongoing projects.
vi.    Not suitable for the projects where requirements are at a moderate to high risk of changing.

When to use waterfall model

i.    Requirements are very well known, clear and fixed.
ii.    Product definition is stable.
iii.    Technology is understood.
iv.    There are no ambiguous requirements
v.    Ample resources with required expertise are available freely
vi.    The project is short.


1.1.2    V-Model

Overview

V-model means Verification and Validation model. V-model may be considered as extension of Waterfall model, because just like Waterfall model it is a well structured     model in which the different phases progress in a sequential or linear way.
In the Waterfall model, testing is considered as a post-development (after coding) activity. Each phase must be completed before the next phase begins and different types of testing apply at corresponding phase of development. Thus from testing perspective, the type of tests at each phase of development vary significantly.


The various phases of the V-model are as follows:

a. Business Requirements and Acceptance testing

At this level, overall business requirements are collected by analyzing the needs of the customer(s). This phase is concerned about establishing what the ideal system has to perform and however, it does not determine how the software will be built. The requirements cover hardware, software, and operational requirements. These requirements are documented in Business requirement specification document which the Business analysts use to communicate their understanding of the system back to the users. This serves the guideline for System Requirement specification.
For overall business requirements, eventually whatever software is developed should fit into and work as per these requirements and should be accepted by the customers, in their environment. This testing is called Acceptance testing for which the tests are designed based on the business requirements.

b.  Software Requirements and System testing

Based on the BRS document, Software Requirements are created and documented in SRS document. These requirements are created by Technical managers/Senior Developers and figure out the possibilities and techniques using which the business requirements can be implemented. If any of the requirements is not feasible, it is informed to the customers and the BRS document is modified accordingly once the resolution is found.
At this level, Testers create test cases based on SRS document in order to perform System testing. Entire System is tested before the software is deployed in customer’s environment. This is to ensure that all the software requirements are satisfied by the system that is developed. This testing of the entire software system can be called as System Testing.

c. High Level Design and Integration testing

System Architect/Senior Developer creates high level design based on the SRS document. High level design document typically consists of the overall architecture of the system, list of modules/subsystems, brief functionality of each module and their interface relationships, dependencies etc.
As per the high-level design, the system is being made up of interoperating and integrated modules/subsystems and these individual modules should be integrated and tested together before full system testing is done. This level of testing is called Integration Testing.

d. Low Level Design and Component testing
 

High Level design gets translated to a more detailed or low-level design. The low level design document will contain detailed information like algorithm choices, table layouts, database elements, processing logic, exception conditions, and so on. This result in the identification of number of components and each component is developed in appropriate programming language.
The components that are the outputs of the low-level design have to be tested independently before being integrated. Thus the testing at this level is known as component testing.

Advantages of V-model

i.    Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model.
ii.    Supports wide range of Development methodologies such as structured and object oriented systems development.
iii.    Proactive defect tracking that is defects are found at early stage.
iv.    Avoids the downward flow of the defects.
v.    Works well for small projects where requirements are easily understood.

Disadvantages of V-model

i.    Very rigid and least flexible.
ii.    It is an expensive model compared to waterfall model as it needs lot of resources, budget and time.
iii.    Software is developed during the implementation phase, so no early prototypes of the software are produced.
iv.    If any changes happen in midway, then the test documents along with requirement documents has to be updated.
v.    Adoption of changes in requirements and adding new requirements at the middle of the process is difficult.

When to use V-model
i.    The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed.
ii.    The V-Shaped model should be chosen when ample technical resources are available with needed technical expertise.

0 comments:

Post a Comment