SESSION 1- LIFE CYCLE MODEL

What is SDLC?
It is a process for planning, creating, testing and deploying an information system.

Types of Software developing life cycles (SDLC)

• Waterfall Model
• V-Shaped Model
• Evolutionary Prototyping Model
• Spiral Method (SDM)
• Iterative and Incremental Method
• Agile development
• Big bank Model

Waterfall model:

Classical waterfall model is the basic software development life cycle model. It is very simple
but idealistic. 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 the classical
waterfall model. Classical waterfall model divides the life cycle into a set of phases. This model
considers that one phase can be started after completion of the previous phase. That is the output
of one phase will be the input to the next phase. Thus the development process can be considered
as a sequential flow in the waterfall. Here the phases do not overlap with each other. The
different sequential phases of the classical waterfall model are shown in the below figure:
Let us now learn about each of these phases in brief details:

1. Feasibility Study: The main goal 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 determine the various possible strategies to solve the
problem. These different identified solutions are analyzed based on their benefits and
drawbacks, The best solution is chosen and all the other phases are carried out as per this
solution strategy.
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.
o Requirement gathering and analysis: Firstly all the requirements regarding the
software are gathered from the customer and then the gathered requirements are
analyzed. The goal of the analysis part is to remove incompleteness (an incomplete
requirement is one in which some parts of the actual requirements have been
omitted) and inconsistencies (inconsistent requirement is one in which some part
of the requirement contradicts with some other part).
o Requirement specification: These analyzed requirements are documented in a
software requirement specification (SRS) document. SRS document serves as a
contract between development team and customers. Any future dispute between the
customers and the developers can be settled by examining the SRS document.
3. Design: The aim of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some programming
language.
4. Coding and Unit testing: In coding phase software design is translated into source code
using any suitable programming language. Thus each designed module is coded. The aim
of the unit testing phase is to check whether each module is working properly or not.
 5. Integration and System testing: Integration of different modules are undertaken soon
after they have been coded and unit tested. 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 three different kinds of testing activities as described below :

o Alpha testing: Alpha testing is the system testing performed by the development
team.
o Beta testing: Beta testing is the system testing performed by a friendly set of
customers.
o Acceptance testing: After the software has been delivered, the customer performed
the acceptance testing to determine whether to accept the delivered software or to
reject it.
6. Maintainence: Maintenance is the most important phase of a software life cycle. The effort
spent on maintenance is the 60% of the total effort spent to develop a full software. There
are basically three types of maintenance :
o Corrective Maintenance: This type of maintenance is carried out to correct errors
that were not discovered during the product development phase.
o Perfective Maintenance: This type of maintenance is carried out to enhance the
functionalities of the system based on the customer’s request.
o Adaptive Maintenance: Adaptive maintenance is usually required for porting the
software to work in a new environment such as work on a new computer platform
or with a new operating system.

Advantages of Classical Waterfall Model

Classical waterfall model is an idealistic model for software development. It is very simple, so it
can be considered as the basis for other software development life cycle models. Below are some
of the major advantages of this SDLC model
 This model is very simple and is easy to understand.
 Phases in this model are processed one at a time.
 Each stage in the model is clearly defined.
 This model has very clear and well understood milestones.
 Process, actions and results are very well documented.
 Reinforces good habits: define-before-design,design-before-code.
 This model works well for smaller projects and projects where requirements are well
understood.

Drawbacks of Classical Waterfall Model

Classical waterfall model suffers from various shortcomings, basically we can’t use it in real
projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model:

• No feedback path: In classical waterfall model evolution of a software from one phase to
another phase is like a waterfall. It assumes that no error is ever committed by developers
during any phases. Therefore, it does not incorporate any mechanism for error correction.
• Difficult to accommodate change requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customers’ requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.
• No overlapping of phases: This model recommends that new phase can start only after
the completion of the previous phase. But in real projects, this can’t be maintained. To
increase the efficiency and reduce the cost, phases may overlap.

Software Engineering | Iterative Waterfall Model

In a practical software development project, the classical waterfall model is hard to use. So,
Iterative waterfall model can be thought of as incorporating the necessary changes to the
classical waterfall model to make it usable in practical software development projects. It is
almost same as the classical waterfall model except some changes are made to increase the
efficiency of the software development.

The iterative waterfall model provides feedback paths from every phase to its preceding
phases, which is the main difference from the classical waterfall model.
Feedback paths introduced by the iterative waterfall model are shown in the figure below.
When errors are detected at some later phase, these feedback paths allow correcting errors
committed by programmers during some phase. The feedback paths allow the phase to be
reworked in which errors are committed and these changes are reflected in the later phases. But,
there is no feedback path to the stage – feasibility study, because once a project has been taken,
does not give up the project easily.

It is good to detect errors in the same phase in which they are committed. It reduces the effort
and time required to correct the errors.

Phase Containment of Errors: The principle of detecting errors as close to their points of
commitment as possible is known as Phase containment of errors.

Advantages of Iterative Waterfall Model

• Feedback Path: In the classical waterfall model, there are no feedback paths, so there is
no mechanism for error correction. But in iterative waterfall model feedback path from one
phase to its preceding phase allows correcting the errors that are committed and these
changes are reflected in the later phases.
• Simple: Iterative waterfall model is very simple to understand and use. That’s why it is
one of the most widely used software development models.

Drawbacks of Iterative Waterfall Model

Difficult to incorporate change requests: The major drawback of the iterative waterfall
model is that all the requirements must be clearly stated before starting of the
development phase. Customer may change requirements after some time but the iterative
waterfall model does not leave any scope to incorporate change requests that are made
after development phase starts.
• Incremental delivery not supported: In the iterative waterfall model, the full software is
completely developed and tested before delivery to the customer. There is no scope for any
intermediate delivery. So, customers have to wait long for getting the software.
• Overlapping of phases not supported: Iterative waterfall model assumes that one phase
can start after completion of the previous phase, But in real projects, phases may overlap
to reduce the effort and time needed to complete the project.
• Risk handling not supported: Projects may suffer from various types of risks. But,
Iterative waterfall model has no mechanism for risk handling.
• Limited customer interactions: Customer interaction occurs at the start of the project at
the time of requirement gathering and at project completion at the time of software delivery.
These fewer interactions with the customers may lead to many problems as the finally
developed software may differ from the customers’ actual requirements.

SESSION 2- LIFE CYCLE MODEL

 SLO 1- V Model
SLO 2 – Spiral Model
SDLC V-Model

The V-model is a type of SDLC model where process executes in a sequential manner in V-
shape. It is also known as Verification and Validation model. It is based on the association of a
testing phase for each corresponding development stage. Development of each step directly
associated with the testing phase. The next phase starts only after completion of the previous
phase i.e. for each development activity, there is a testing activity corresponding to it.

Verification: It involves static analysis technique (review) done without executing code. It is the
process of evaluation of the product development phase to find whether specified requirements
meet.

Validation: It involves dynamic analysis technique (functional, non-functional), testing done by

executing code. Validation is the process to evaluate the software after the completion of the
development phase to determine whether software meets the customer expectations and
requirements.

So V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation phases are joined by coding phase in V-shape. Thus it is called V-
Model.

Design Phase:
 • Requirement Analysis: This phase contains detailed communication with the customer to
understand their requirements and expectations. This stage is known as Requirement
Gathering.
• System Design: This phase contains the system design and the complete hardware and
communication setup for developing product.
• Architectural Design: System design is broken down further into modules taking up
different functionalities. The data transfer and communication between the internal
modules and with the outside world (other systems) is clearly understood.
Module Design: In this phase the system breaks dowm into small modules. The detailed
design of modules is specified, also known as LowLevel Design (LLD).

Testing Phases:

• Unit Testing: Unit Test Plans are developed during module design phase. These Unit Test
Plans are executed to eliminate bugs at code or unit level.
• Integration testing: After completion of unit testing Integration testing is performed. In
integration testing, the modules are integrated and the system is tested. Integration testing
is performed on the Architecture design phase. This test verifies the communication of
modules among themselves.
• System Testing: System testing test the complete application with its functionality, inter
dependency, and communication.It tests the functional and non-functional requirements of
the developed application.
• User Acceptance Testing (UAT): UAT is performed in a user environment that resembles
the production environment. UAT verifies that the delivered system meets user’s
requirement and system is ready for use in real world.

Industrial Challenge: As the industry has evolved, the technologies have become more
complex, increasingly faster, and forever changing, however, there remains a set of basic
principles and concepts that are as applicable today as when IT was in its infancy.

• Accurately define and refine user requirements.

• Design and build an application according to the authorized user requirements.
• Validate that the application they had built adhered to the authorized business requirements.

Principles of V-Model:

• Large to Small: In V-Model, testing is done in a hierarchical perspective, For example,

requirements identified by the project team, create HighLevel Design, and Detailed Design
phases of the project. As each of these phases is completed the requirements, they are
defining become more and more refined and detailed.
• Data/Process Integrity: This principle states that the successful design of any project
requires the incorporation and cohesion of both data and processes. Process elements must
be identified at each and every requirements.
 • Scalability: This principle states that the V-Model concept has the flexibility to
accommodate any IT project irrespective of its size, complexity or duration.
• Cross Referencing: Direct correlation between requirements and corresponding testing
activity is known as cross-referencing.
• Tangible Documentation: This principle states that every project needs to create a
document. This documentation is required and applied by both the project development
team and the support team. Documentation is used to maintaining the application once it is
available in a production environment.

Why preferred?

• It is easy to manage due to the rigidity of the model. Each phase of VModel has specific
deliverables and a review process.
• Proactive defect tracking – that is defects are found at early stage.

When to use?

• Where requirements are clearly defined and fixed.

• The V-Model is used when ample technical resources are available with technical expertise.

Advantages:

• This is a highly disciplined model and Phases are completed one at a time.
• V-Model is used for small projects where project requirements are clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the life cycle thereby
enhancing the probability of building an error-free and good quality product.
• It enables project management to track progress accurately.

Disadvantages:

• High risk and uncertainty.

• It is not a good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and contains high risk of
changing.
• This model does not support iteration of phases.
It does not easily handle concurrent events.