SYSTEM DEVELOPMENT METHODOLOGIES

Classical 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:


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.
 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.
 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).
 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.
 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.
 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.
 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 :
1.
 α-testing: α-testing is the system testing performed by the development
team.
 β-testing: β-testing is the system testing performed by a friendly set of
customers.
 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.
2. 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 :
 Corrective Maintenance: This type of maintenance is carried out to
correct errors that were not discovered during the product development
phase.
 Perfective Maintenance: This type of maintenance is carried out to
enhance the functionalities of the system based on the customer’s
request.
 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 undestood 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.

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.

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 Low-Level 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 Challange: 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 High-Level 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 V-Model
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.
Spiral Model
Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling. In its diagrammatic representation, it
looks like a spiral with many loops. The exact number of loops of the spiral is
unknown and can vary from project to 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
spiral model.
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.
Below diagram shows the different phases of the Spiral Model:

Each phase of 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
2. are gathered from the customers and the objectives are identified, elaborated
and analyzed at the start of every phase. Then alternative solutions possible for
the phase are proposed in this quadrant.
 3. 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 is identified and the risks are resolved using the
best possible strategy. At the end of this quadrant, Prototype is built for the best
possible solution.
4. 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.
5. Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for
the next phase is started.
Risk Handling in Spiral Model
A risk is any adverse situation that might affect the successful completion of a
software project. The most important feature of the spiral model is handling these
unknown risks after the project has started. Such risk resolutions are easier done by
developing a prototype. The spiral model supports coping up with risks by providing
the scope to build a prototype at every phase of the software development.
Prototyping Model also support risk handling, but the risks must be identified
completely before the start of the development work of the project. But in real life
project risk may occur after the development work starts, in that case, we cannot use
Prototyping Model. In each phase of the Spiral Model, the features of the product
dated and analyzed and the risks at that point of time are identified and are resolved
through prototyping. Thus, this model is much more flexible compared to other SDLC
models.
Why Spiral Model is called Meta Model ?
The Spiral model is called as a Meta Model because it subsumes all the other SDLC
models. For example, a single loop spiral actually represents the Iterative Waterfall
Model. The spiral model incorporates the stepwise approach of the Classical
Waterfall Model. The spiral model uses the approach of Prototyping Model by
building a prototype at the start of each phase as a risk handling technique. Also, the
spiral model can be considered as supporting the evolutionary model – the iterations
along the spiral can be considered as evolutionary levels through which the complete
system is built.
Advantages of Spiral Model: Below are some of the advantages of the Spiral
Model.
 Risk Handling: The projects with many unknown risks that occur as the
 development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.
 Good for large projects: It is recommended to use the Spiral Model in large
and complex projects.
 Flexibility in Requirements: Change requests in the Requirements at later
phase can be incorporated accurately by using this model.
 Customer Satisfaction: Customer can see the development of the product at
the early phase of the software development and thus, they habituated with the
system by using it before completion of the total product.
Disadvantages of Spiral Model:
 Complex: The Spiral Model is much more complex than other SDLC models.
 Expensive: Spiral Model is not suitable for small projects as it is expensive.
 Too much dependable on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly
experienced expertise, it is going to be a failure to develop a project using this
model.
 Difficulty in time management: As the number of phases is unknown at the
start of the project, so time estimation is very difficult.