WATERFALL MODEL

Prepared by
Dr. Mita Pal
Ref: Fundamental of Software Engineering by Rajib Mall
Classical Waterfall Model

• The waterfall model is also called as 'linear-sequential model' or 'classic

life cycle model’ or ‘traditional model’. It is the oldest software
paradigm. This model suggests a systematic, sequential approach to
software development

• Diagram is just like waterfall

• No overlapping

• Sequential phases
Feasibility Study

The main focus of the feasibility study stage is to determine whether it would be
financially and technically feasible to develop the software
Requirement Analysis and Specifications

• The aim of this phase is to understand the exact requirements of the customer and to
document them properly. Both the customer and the software developer work together
so as to document all the functions, performance, and interfacing requirement of the
software. It describes the "what" of the system to be produced and not "how’. In this
phase, a large document called Software Requirement Specification (SRS) document
is created which contained a detailed description of what the system will do in the
common language.
• Functional and non-functional (other features, good performance, maintainable, robust
requirement
• Purpose: To understand customer requirements and document them properly
• Work Product: Software Requirement Specification (SRS) document is created (large
document written in natural language( no technical and it describes what the system
will do, it does not describe how the functionality implemented.
• Use: used as a contract between the developer and customer. used for validation
Design

• This phase aims to transform the requirements gathered in the SRS into a
structure suitable for implementation in some programming language .
• It defines the overall software architecture together with high level and
detailed design.
• Work Product: All this work is documented as a Software Design
Document (SDD).
• Use: useful to start coding
 Implementation and unit testing

• During this phase, design is implemented. If the SDD is complete, the

implementation or coding phase proceeds smoothly, because all the
information needed by software developers is contained in the SDD.
• During testing, the code is thoroughly examined and modified. Small
modules are tested in isolation initially. After that these modules are tested
by writing some overhead code to check the interaction between these
modules and the flow of intermediate output.
• Implementation: coding phase
• Unit testing: each module is tested independently of other modules
Integration and System Testing

• Modules combined together to form a complete s/w

• Software is a part of the system is tested
• Interfaces between the modules are tested. System testing are tested in
that environment where actually it runs after deployment
• This phase is highly crucial as the quality of the end product is determined by
the effectiveness of the testing carried out. The better output will lead to
satisfied customers, lower maintenance costs, and accurate results. Unit testing
determines the efficiency of individual modules. However, in this phase, the
modules are tested for their interactions with each other and with the system.
Operation and maintenance phase

• Maintenance is the task performed by every user once the software has
been delivered to the customer, installed, and operational.
• To preserve the value of software over time
• Operation: the software has been delivered to the customer and started
operating in the users environment
• Maintenance: After the delivery and deployment the s/w to the
customer, error correction, enhancement, remove obsolete
functionalities and so on
 Shortcomings of the classical waterfall model

• No feedback paths: In classical waterfall model, the evolution of a software

from one phase to the next is analogous to a waterfall. The classical waterfall
model is idealistic in the sense that it assumes that no error is ever committed
by the developers during any of the life cycle phases, and therefore,
incorporates no mechanism for error correction.

• Difficult to accommodate change requests: This model assumes that all

customer requirements can be completely and correctly defined at the
beginning of the project.
Shortcomings of the classical waterfall model (contd.)

• Inefficient error corrections: This model defers integration of code and

testing tasks until it is very late when the problems are harder to
resolve.

• No overlapping of phases: This model recommends that the phases be

carried out sequentially—new phase can start only after the previous
one completes.
Iterative Waterfall Model

Ref: Rajib Mall

Iterative Waterfall Model

• The main change brought about by the iterative waterfall model to the classical
waterfall model is in the form of providing feedback paths from every phase to
its preceding phases.

• The feedback paths allow for correcting errors committed by a programmer

during some phase.
 Iterative waterfall model (Error)
• Phase containment of errors: No matter how careful a programmer may be, he might
end up committing some mistake or other while carrying out a life cycle activity.
These mistakes result in errors (also called faults o r bugs ) in the work product.

• Phase overlap Even though the strict waterfall model envisages sharp transitions to
occur from one phase to the next (see Figure 2.3), in practice the activities of
different phases overlap (as shown in Figure 2.4) due to two main reasons:

a) In spite of the best effort to detect errors in the same phase in which they are
committed, some errors escape detection and are detected in a later phase.
These subsequently detected errors cause the activities of some already
completed phases to be reworked.

b) An important reason for phase overlap is that usually the work required to be carried
out in a phase is divided among the team members. Some members may complete their
part of the work earlier than other members
Ref: Rajib Mall
Problems with waterfall model

• Expects complete and accurate requirements early in s/w development

process. Not realistic
• Working s/w is not available till very late in the sw development cycle,
lead to delay in error (bug) discovery.
• Risk: No assessment of risk
• Change: not suitable for accommodating changing during development
• Sequential nature :Not realistic in today’s world AND this model is not
suitable for large projects
When to use Waterfall Model

• Follows the idea of Define before Design and Design before Code.
• When the requirements are very clearly understood and they will not
change (stable in nature) during SDLC.
• Can be used by an organization: a) that has an experience in developing
a particular kind of s/w , b) when it wants to build a new s/w based on
an existing s/w.
Shortcomings of the iterative waterfall model

• Difficult to accommodate change requests: A major problem with the

waterfall model is that the requirements need to be frozen before the
development starts.
• Incremental delivery not supported: In the iterative waterfall model, the
full software is completely developed and tested before it is delivered to
the customer. There is no provision for any intermediate deliveries to
occur.
• Phase overlap not supported: For most real life projects, i t becomes
difficult to follow the rigid phase sequence prescribed by the waterfall
model.
Shortcomings of the iterative waterfall model (contd.)

• Error correction unduly expensive: the defects that are noticed at

the time of validation incur expensive rework and result in cost
escalation and delayed delivery.
• Limited customer interactions: It is generally accepted that
software developed in isolation from the customer is the cause of
many problems.
• Heavy weight: A significant portion of the time of the developers is
spent in preparing documents, and revising them as changes
occur over the life cycle.
• No support for risk handling and code reuse: It becomes difficult
to use the waterfall model in projects that are susceptible to
various types of risks
V Model in System Engineering

What is the V Model in System Engineering?

The V-Model in System Engineering is a development methodology that outlines a
structured, sequential process for designing, building, and testing complex systems. It
derives its name from its V-shaped representation, which visually connects
development phases on the left side with corresponding testing phases on the right.

The key principles of the V-Model include:

• Verification and Validation: Ensuring that each development phase meets

predefined requirements through systematic testing.
• Sequential Progression: Following a logical sequence, from requirements
gathering to system validation.
• Traceability: Maintaining full requirements lifecycle coverage by linking design
and implementation to their testing counterparts.

Importance of the V Model in Managing System Engineering Processes

The V-Model is essential for ensuring efficiency and accuracy in system engineering
processes. It integrates requirements management, design, and testing in a way that
minimizes risks and ensures compliance with project objectives. This approach is
particularly beneficial in projects requiring high levels of reliability, such as in safety-
critical systems.

Key advantages include:

• Improved traceability between requirements and deliverables.

• Clear definition of roles and responsibilities in each phase.
• Early detection of defects, reducing costly errors in later stages.

What are the Phases of the V Model in System

Engineering?
The V-Model aligns seamlessly with the systems engineering lifecycle, providing a
roadmap from initial requirements elicitation to final system validation. The V Model
consists of distinct phases that align development activities on the left side with
corresponding testing and validation activities on the right. Each phase ensures
structured progress, emphasizing requirements management, traceability, and quality
assurance.
Development Phases (Left Side of the V)

1. Requirements Definition and Specification

o In this phase, the system’s objectives and user needs are gathered and
documented as requirements.
o Clear and detailed requirements specification is crucial for ensuring
successful design and testing later.
2. System Design
o Translating the documented requirements into a high-level architectural
framework.
o Focuses on defining system components, interfaces, and overall structure.
3. Detailed Component Design
o The system design is broken down into granular components with specific
functionalities.
o Each component is designed to meet the defined requirements and
integrate seamlessly into the overall system.

Testing and Validation Phases (Right Side of the V)

1. Unit Testing
o Individual components designed in the previous phase are tested to verify
functionality and alignment with component-level requirements.
 o This phase ensures that each unit works as intended in isolation.
2. Integration Testing
o Testing the interaction and communication between integrated
components.
o Ensures that the system’s components function together correctly
according to the system design.
3. System Testing
o Validates the entire system against the system requirements to ensure it
performs as intended.
o Includes functional and non-functional testing, such as performance and
security testing.
4. Acceptance Testing
o The final validation phase is where the complete system is tested in the
real-world environment.
o Confirms that the system meets user needs and all requirements defined
in the initial phases.

Verification and Validation (The Connecting Path)

• Each development phase is directly linked to a corresponding testing phase,

ensuring comprehensive verification and validation throughout the lifecycle.
• For example, requirements specification corresponds to acceptance testing,
ensuring that all user needs are validated in the final product.

The structured sequence of the V Model ensures seamless requirements lifecycle

coverage, making it an ideal framework for projects requiring high reliability and
traceability, such as in safety-critical or regulated industries.

Benefits of Using the V Model in Systems Engineering

The V Model provides a structured and efficient approach to managing systems
engineering processes, offering several significant advantages:

1. Enhanced Traceability
o Ensures end-to-end requirements traceability by linking development
phases to corresponding testing phases, reducing the risk of overlooked
requirements.
2. Improved Quality Assurance
o Continuous verification and validation at every stage identifies errors early,
enhancing overall system quality and reducing costly rework.
3. Risk Mitigation
o The focus on early requirements gathering and validation minimizes risks,
ensuring the delivered product meets user expectations.
4. Structured and Predictable Process
o Clear phases and milestones simplify project planning, scheduling, and
monitoring, making it easier to manage complex systems engineering
lifecycles.
 5. Ideal for Safety-Critical Systems
o Its rigorous approach makes the V Model well-suited for industries like
aerospace, automotive, and healthcare, where compliance and reliability
are crucial.

By ensuring a robust connection between development and testing, the V-Model

supports the successful execution of complex projects with high levels of reliability and
compliance.

V Model and Requirements Management

The V-Model in Systems Engineering plays a critical role in effective requirements
management by providing a structured framework that ensures every requirement is
addressed, validated, and traced throughout the system’s lifecycle. Here’s how the V
Model aligns with and enhances requirements management:

Emphasis on Requirements Definition

• The V Model begins with a detailed requirements definition phase, where user
needs and system objectives are captured and documented.
• Clear requirements specifications serve as the foundation for subsequent design,
development, and testing phases.

Requirements Traceability Across Phases

• A key strength of the V Model is its ability to ensure full requirements traceability,
linking each development phase to its corresponding validation phase.
• This bidirectional traceability ensures that every requirement is accounted for and
verified during system testing and acceptance testing.

Verification and Validation (V&V) of Requirements

• The V-Model integrates verification (ensuring the system is built right) and
validation (ensuring the right system is built) into the process.
• Unit testing, integration testing, and system validation confirm that all
requirements are met at every level of development.

Minimizing Requirements-Related Risks

• By prioritizing thorough requirements elicitation and continuous validation, the V

Model reduces risks such as scope creep, misinterpretations, and incomplete
requirements.
• Early detection and correction of inconsistencies ensure smoother project
execution.
Supporting Complex Systems Engineering

• For large-scale, safety-critical systems, managing complex requirements

lifecycles is essential.
• The V Model ensures that detailed requirements management processes are
embedded throughout the systems engineering lifecycle, enabling compliance
with stringent industry standards.

The V Model is invaluable for projects where requirements management is a priority,

ensuring comprehensive coverage, accurate testing, and alignment with stakeholder
needs. Its structured approach supports high-quality outcomes and reduces the
likelihood of overlooked or unmet requirements.

V-Model vs. Waterfall Model vs. Agile Model

The table below highlights the key differences between the V-Model, Waterfall Model,
and Agile Model in terms of their structure, flexibility, and use cases. It also provides
guidance on when to use each model.

Aspect V Model Waterfall Model Agile Model

Sequential with Linear, sequential Iterative and incremental

Structure
parallel testing phases process cycles
Rigid, changes are
Rigid with little room Highly flexible, and
costly after
Flexibility for changes once adaptive to changes during
requirements are
development starts the project
defined
Emphasizes
Focuses on completing Emphasizes continuous
verification and
Focus each phase before delivery, collaboration, and
validation (V&V) at
moving to the next flexibility
each stage
Strong focus on clear, Requirements are
Requirements Requirements evolve over
upfront requirements defined upfront and
Management time, with frequent revisits
definition followed strictly
Testing occurs only
Testing is conducted at Testing is continuous
Testing after the full
each phase, parallel to throughout the development
Approach development is
the development cycle
completed
Suited for large, Best for projects with Ideal for projects with
Project Size complex projects with well-defined, stable evolving or unclear
clear requirements requirements requirements
 Aspect V Model Waterfall Model Agile Model

Detailed Minimal documentation

Heavy documentation
Documentation documentation at each focused on user stories and
upfront
stage tasks
Early testing reduces Risks are discovered Risks are mitigated through
Risk
risks, but changes are late, as testing occurs frequent feedback loops and
Management
difficult after development iterative progress
Limited feedback Limited feedback Continuous feedback from
Feedback Loop
during development during development stakeholders and end-users
Projects requiring frequent
Safety-critical systems, Large, straightforward
iterations, flexibility, and
Use Case highly regulated projects with a clear
adaptability (e.g., software
industries scope
development)
When to Use Which Model?

Model When to Use

Use for highly regulated, safety-critical, or complex systems where requirements

V-Model
traceability and rigorous verification and validation are essential.

Best for small to medium-scale projects with well-defined and stable requirements.
Waterfall
Ideal when changes are minimal and timelines are predictable.

Ideal for dynamic, evolving projects requiring continuous feedback, frequent updates,
Agile
and rapid delivery of features. Best for projects with changing requirements.

Each model has its strengths depending on the nature of the project. For highly
regulated industries, the V-Model ensures rigorous requirements management and
testing. The Waterfall Model is best suited for projects with fixed requirements and
predictable timelines. Agile is the go-to for innovative or customer-driven projects where
frequent changes and flexibility are expected.
Software Life Cycle

Prepared by
Dr. Mita Pal
Based on this concept of a biological life cycle, the term software
life cycle has been defined.
Software development life cycle (SDLC) model

• A software development life cycle (SDLC) model (also called software life
cycle model and software development process model ) describes the
different activities that need to be carried out for the software to evolve in its
life cycle

• An SDLC is represented graphically by drawing various stages of the life cycle

and showing the transitions among the phases.

• An SDLC graphically depicts the different phases through which a software

evolves.
• The process followed in the development of the SW depends upon the
LIFE CYCLE MODE chosen for development.
• Life Cycle Model defines the major phases during and after the s/w
development process
Stages of SDLC
• Stage 1. Planning.
The first stage of the SDLC is planning. ...
The goals, costs, and teams’ structure are set up at this stage.

• Stage 2. Analysis and defining requirements.

At this phase, the developers often create a software requirements specification
document. An SRS document is a description of the software’s aim and expected performance.

• Stage 3. Design. ...

The team will be focused on the application architecture and programming, including defining
the application’s programming language/industry practices and methods of solving problems
and performing specific tasks. The team begins to create the user interface and choose the
platforms on which the software will run based on outlined application designs. And last but not
least, security. How will the software be protected? How will user passwords and data be
secured? This is the stage in which to tackle these issues.
• Stage 4. Implementation. ...
The developers’ work gets up to speed when it comes to the coding
phase. If there is more than one developer working on the project
(and that is the most common scenario) a focus on teamwork is also
needed.

• Stage 5. Testing. ...

This stage is completed before releasing the product to users or starts even
before coding

• Stage 6. Deployment. ...

The initial deployment is always challenging

• Stage 7. Maintenance.
The maintenance stage is probably the most crucial one of the SDLC
process
Process versus methodology

• process has a broader scope

• all the activities taking place
• design (e.g. design process), testing (test process), etc.
• A methodology, on the other hand, prescribes a set of steps for carrying
out a specific life cycle activity.
• A process usually describes all the activities starting from the inception
of a software to its maintenance and retirement stages, or at least a
chunk of activities in the life cycle.
• A methodology, in contrast, describes the steps to carry out only a
single or at best a few individual activities.
Software Development Life Cycle (SDLC) Phases & Models
 What is SDLC?
A software development life cycle (SDLC) model (also called software life cycle
model and software development process model ) describes the different activities
that need to be carried out for the software to evolve in its life cycle.
SDLC consists of a detailed plan which explains how to plan, build, and maintain
specific software

The process followed in the development of the SW depends upon the LIFE
CYCLE MODE chosen for development.
Life Cycle Model defines the major phases during and after the s/w development
process
What is RAD Model in Software Engineering?

The RAD model is used when the requirements are fully understood and the
component-based construction approach is adopted. Various phases in RAD
are RequirementGathering, Analysis and Planning, Design, Build or Const
ruction and finally Deployment.

The RAD model or Rapid Application Development model is a type of

software development methodology that emphasizes quick and iterative
release cycles, primarily focusing on delivering working software in shorter
timelines.

The critical feature of this model is the use of powerful development tools
and techniques.

Multiple teams work on developing the software system using the RAD
model parallelly.

The use of powerful developer tools such as JAVA, C++, Visual BASIC, XML,
etc. is also an integral part of the projects.
This model consists of 4 basic phases:

1. Requirements Planning – This involves the use of various techniques

used in requirements elicitation like brainstorming, task analysis,
form analysis, user scenarios, FAST (Facilitated Application
Development Technique), etc. It also consists of the entire
structured plan describing the critical data, methods to obtain it,
and then processing it to form a final refined model.
2. User Description – This phase consists of taking user feedback and
building the prototype using developer tools. In other words, it
includes re-examination and validation of the data collected in the
first phase. The dataset attributes are also identified and
elucidated in this phase.
3. Construction – In this phase, refinement of the prototype and
delivery takes place. It includes the actual use of powerful
automated tools to transform processes and data models into the
final working product. All the required modifications and
enhancements are to be done in this phase.
4. Cutover – All the interfaces between the independent modules
developed by separate teams have to be tested properly. The use
of powerfully automated tools and subparts makes testing easier.
This is followed by acceptance testing by the user.
The process involves building a rapid prototype, delivering it to the customer,
and taking feedback. After validation by the customer, the SRS document is
developed and the design is finalized.

When to use the RAD Model?

1. Well-understood Requirements: When project requirements are
stable and transparent, RAD is appropriate.
2. Time-sensitive Projects: Suitable for projects that need to be
developed and delivered quickly due to tight deadlines.
3. Small to Medium-Sized Projects: Better suited for smaller initiatives
requiring a controllable number of team members.
4. High User Involvement: Fits where ongoing input and interaction
from users are essential.
 5. Innovation and Creativity: Helpful for tasks requiring creative inquiry
and innovation.
6. Prototyping: It is necessary when developing and improving
prototypes is a key component of the development process.
7. Low technological Complexity: Suitable for tasks using comparatively
straightforward technological specifications.

Objectives of Rapid Application Development Model

(RAD)

1. Speedy Development
Accelerating the software development process is RAD’s main goal. RAD
prioritizes rapid prototyping and iterations to produce a working system as
soon as possible. This is especially helpful for projects when deadlines
must be met.
2. Adaptability and Flexibility
RAD places a strong emphasis on adapting quickly to changing needs. Due
to the model’s flexibility, stakeholders can modify and improve the system
in response to changing requirements and user input.
3. Stakeholder Participation
Throughout the development cycle, RAD promotes end users and
stakeholders’ active participation. Collaboration and frequent feedback
make it possible to make sure that the changing system satisfies both user
and corporate needs.
4. Improved Interaction
Development teams and stakeholders may collaborate and communicate
more effectively thanks to RAD. Frequent communication and feedback
loops guarantee that all project participants are in agreement, which lowers
the possibility of misunderstandings.
5. Improved Quality via Prototyping
Prototypes enable early system component testing and visualization in
Rapid Application Development (RAD). This aids in spotting any problems,
confirming design choices, and guaranteeing that the finished product lives
up to consumer expectations.
6. Customer Satisfaction
Delivering a system that closely satisfies user expectations and needs is the
goal of RAD. Through rapid delivery of functioning prototypes and user
involvement throughout the development process, Rapid Application
Development (RAD) enhances the probability of customer satisfaction with
the final product.

Advantages of Rapid Application Development Model

(RAD)
• The use of reusable components helps to reduce the cycle time of
the project.
• Feedback from the customer is available at the initial stages.
• Reduced costs as fewer developers are required.
• The use of powerful development tools results in better quality
products in comparatively shorter periods.
• The progress and development of the project can be measured
through the various stages.
• It is easier to accommodate changing requirements due to the short
iteration time spans.
• Productivity may be quickly boosted with a lower number of
employees.

Disadvantages of Rapid application development

model (RAD)

• The use of powerful and efficient tools requires highly skilled

professionals.
• The absence of reusable components can lead to the failure of the
project.
• The team leader must work closely with the developers and
customers to close the project on time.
 • The systems which cannot be modularized suitably cannot use this
model.
• Customer involvement is required throughout the life cycle.
• It is not meant for small-scale projects as in such cases, the cost of
using automated tools and techniques may exceed the entire
budget of the project.
• Not every application can be used with RAD.
•

Applications of Rapid Application Development Model

(RAD)

1. This model should be used for a system with known requirements

and requiring a short development time.
2. It is also suitable for projects where requirements can be
modularized and reusable components are also available for
development.
3. The model can also be used when already existing system
components can be used in developing a new system with
minimum changes.
4. This model can only be used if the teams consist of domain
experts. This is because relevant knowledge and the ability to use
powerful techniques are a necessity.
5. The model should be chosen when the budget permits the use of
automated tools and techniques required.

Drawbacks of Rapid Application Development

• It requires multiple teams or a large number of people to work on

scalable projects.
• This model requires heavily committed developers and customers.
If commitment is lacking then RAD projects will fail.
• The projects using the RAD model require heavy resources.
• If there is no appropriate modularization then RAD projects fail.
Performance can be a problem for such projects.
• The projects using the RAD model find it difficult to adopt new
technologies. This is because RAD focuses on quickly building and
refining prototypes using existing tools. Changing to new
technologies can disrupt this process, making it harder to keep up
with the fast pace of development. Even with skilled developers
and advanced tools, the rapid nature of RAD leaves little time to
learn and integrate new technologies smoothly.
Prototype Development Model

Prepared by
Dr. Mita Pal
Ref: Rajib Mall
• Prototype development starts with an initial requirements gathering
phase. A quick design is carried out and a prototype is built. The
developed prototype is submitted to the customer for evaluation. Based
on the customer feedback, the requirements are refined and the
prototype is suitably modified. This cycle of obtaining customer
feedback and modifying the prototype continues till the customer
approves the prototype.

• Once the customer approves the prototype, the actual software is

developed using the iterative waterfall approach.
Where is it use?

• It is advantageous to use the prototyping model for development of the

graphical user interface (GUI) part of an application

• The prototyping model is especially useful when the exact technical

solutions are unclear to the development team

• An important reason for developing a prototype is that it is impossible

to “get it right” the first time

• This model is the most appropriate for projects that suffer from technical
and requirements risks.
www.geeksforgeeks.org/software-engineering-prototyping-model/
 Steps of Prototyping Model

• Step 1: Requirement Gathering and Analysis: In this phase, users are asked about
what they expect or what they want from the system.
• Step 2: Quick Design: This model covers the basic design of the requirement through
which a quick overview can be easily described.
• Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.
• Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strengths
and weaknesses of the design, which was sent to the developer.
• Step 5: Refining Prototype: If any feedback is given by the user, then improving the
client’s response to feedback and suggestions, the final system is approved.
• Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here
the program is run regularly to prevent failures.
Advantages of Prototyping Model

• The customers get to see the partial product early in the life cycle. This
ensures a greater level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for
refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost,
besides enhancing the quality of the software.
• The developed prototype can be reused by the developer for more
complicated projects in the future.
• Flexibility in design.
Advantages of Prototyping Model (contd.)

• Early feedback from customers and stakeholders can help guide the
development process and ensure that the final product meets their needs and
expectations.
• Prototyping can be used to test and validate design decisions, allowing for
adjustments to be made before significant resources are invested in
development.
• Prototyping can help reduce the risk of project failure by identifying potential
issues and addressing them early in the process.
• Prototyping can facilitate communication and collaboration among team
members and stakeholders, improving overall project efficiency and
effectiveness.
• Prototyping can help bridge the gap between technical and non-technical
stakeholders by providing a tangible representation of the product.
Disadvantages of the Prototyping Model
• Costly concerning time as well as money.
• There may be too much variation in requirements each time the prototype is
evaluated by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for developers to accommodate all the changes demanded
by the customer.
• There is uncertainty in determining the number of iterations that would be
required before the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual
product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal
solutions.
• .
•
Disadvantages of the Prototyping Model (contd.)

• The customer might lose interest in the product if he/she is not satisfied with
the initial prototype.
• The prototype may not be scalable to meet the future needs of the customer.
• The prototype may not accurately represent the final product due to limited
functionality or incomplete features.
• The focus on prototype development may shift away from the final product,
leading to delays in the development process.
• The prototype may give a false sense of completion, leading to the premature
release of the product.
• The prototype may not consider technical feasibility and scalability issues that
can arise during the final product development.
• The prototype may be developed using different tools and technologies,
leading to additional training and maintenance costs.
• The prototype may not reflect the actual business requirements of the
customer, leading to dissatisfaction with the final product
Applications of Prototyping Model

• The Prototyping Model should be used when the requirements of the product
are not clearly understood or are unstable.

• The prototyping model can also be used if requirements are changing quickly.

• This model can be successfully used for developing user interfaces, high-
technology software-intensive systems, and systems with complex algorithms
and interfaces.

• The prototyping Model is also a very good choice to demonstrate the technical
feasibility of the product.
INCREMENTAL PROCESS MODEL

What is the Incremental Process Model?

First, a simple working system implementing only a few basic features is built
and then that is delivered to the customer. Then thereafter many successive
iterations/ versions are implemented and delivered to the customer until the
desired system is released. The Incremental Process Model is also known
as the Successive version model.

A, B, and C are modules of Software Products that are incrementally

developed and delivered.

Phases of incremental model

Requirements of Software are first broken down into several modules that
can be incrementally constructed and delivered.
1. Requirement analysis: In Requirement Analysis At any time, the
plan is made just for the next increment and not for any kind of long-
term plan. Therefore, it is easier to modify the version as per the
needs of the customer.

2. Design & Development: At any time, the plan is made just for the
next increment and not for any kind of long-term plan. Therefore, it
is easier to modify the version as per the needs of the customer.
The Development Team first undertakes to develop core features
(these do not need services from other features) of the
system. Once the core features are fully developed, then these are
refined to increase levels of capabilities by adding new functions in
Successive versions. Each incremental version is usually developed
using an iterative waterfall model of development.

3. Deployment and Testing: After Requirements gathering and

specification, requirements are then split into several different
versions starting with version 1, in each successive increment, the
next version is constructed and then deployed at the customer site.
in development and ‘testing’ the product is checked and tested for
the actual process of the model.
 4. Implementation: In implementation After the last version (version
n), it is now deployed at the client site

Types of Incremental Model

1. Staged Delivery Model

2. Parallel Development Model

1. Staged Delivery Model

Construction of only one part of the project at a time.

2. Parallel Development Model

Different subsystems are developed at the same time. It can decrease the
calendar time needed for the development, i.e. TTM (Time to Market) if
enough resources are available.
When to use the Incremental Process Model

1. Funding Schedule, Risk, Program Complexity, or need for early

realization of benefits.
2. When Requirements are known up-front.
3. When Projects have lengthy development schedules.
4. Projects with new Technology.
• Error Reduction (core modules are used by the customer
from the beginning of the phase and then these are tested
thoroughly).
• Uses divide and conquer for a breakdown of tasks.
• Lowers initial delivery cost.
• Incremental Resource Deployment.
5. Requires good planning and design.
6. The total cost is not lower.
7. Well-defined module interfaces are required.

Characteristics of Incremental Process Model

1. System development is divided into several smaller projects.

2. To create a final complete system, partial systems are constructed
one after the other.
 3. Priority requirements are addressed first.
4. The requirements for that increment are frozen once they are
created.

Advantages of the Incremental Process Model

1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support, because of its iterations.
5. Adjusting the criteria and scope is flexible and less costly.
6. Comparing this model to others, it is less expensive.
7. The identification of errors is simple.

Disadvantages of the Incremental Process Model

1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.
3. Issues may arise from the system design if all needs are not
gathered upfront throughout the program lifecycle.
4. Every iteration step is distinct and does not flow into the next.
5. It takes a lot of time and effort to fix an issue in one unit if it needs
to be corrected in all the units.

Prepared by
Dr. Mita Pal
Evolutionary Model – Software
Engineering

The evolutionary model is a combination of the Iterative and Incremental

models of the software development life cycle.

What is the Evolutionary Model?

The Evolutionary development model divides the development

cycle into smaller, incremental waterfall models in which users can
get access to the product at the end of each cycle.

1. Feedback is provided by the users on the product for the

planning stage of the next cycle and the development team
responds, often by changing the product, plan, or process.
2. Therefore, the software product evolves with time.
3. All the models have the disadvantage that the duration of time
from the start of the project to the delivery time of a solution is
very high.
4. The evolutionary model solves this problem with a different
approach.
5. The evolutionary model suggests breaking down work into
smaller chunks, prioritizing them, and then delivering those
chunks to the customer one by one.
6. The number of chunks is huge and is the number of deliveries
made to the customer.
7. The main advantage is that the customer’s confidence increases
as he constantly gets quantifiable goods or services from the
beginning of the project to verify and validate his requirements.
8. The model allows for changing requirements as well as all work is
broken down into maintainable work chunks.
Application of Evolutionary Model

1. It is used in large projects where you can easily find modules for
incremental implementation. Evolutionary model is commonly
used when the customer wants to start using the core features
instead of waiting for the full software.
2. Evolutionary model is also used in object oriented software
development because the system can be easily portioned into
units in terms of objects.

Necessary Conditions for Implementing this Model

1. Customer needs are clear and been explained in deep to the developer
team.
2. There might be small changes required in separate parts but not a
major change.
3. As it requires time, so there must be some time left for the market
constraints.
4. Risk is high and continuous targets to achieve and report to customer
repeatedly.
5. It is used when working on a technology is new and requires time to
learn.

Advantages Evolutionary Model

1. Adaptability to Changing Requirements: Evolutionary models
work effectively in projects when the requirements are ambiguous
or change often. They support adjustments and flexibility along the
course of development.
2. Early and Gradual Distribution: Functional components or
prototypes can be delivered early thanks to incremental
development. Faster user satisfaction and feedback may result from
this.
3. User Commentary and Involvement: Evolutionary models place a
strong emphasis on ongoing user input and participation. This
guarantees that the software offered closely matches the needs and
expectations of the user.
4. Improved Handling of Difficult Projects: Big, complex tasks can
be effectively managed with the help of evolutionary models. The
development process is made simpler by segmenting the project
into smaller, easier-to-manage portions.

Disadvantages Evolutionary Model

1. Communication Difficulties: Evolutionary models require
constant cooperation and communication. The strategy may be less
effective if there are gaps in communication or if team members are
spread out geographically.
2. Dependence on an Expert Group: A knowledgeable and
experienced group that can quickly adjust to changes is needed for
evolutionary models. Teams lacking experience may find it difficult
to handle these model’s dynamic nature.
3. Increasing Management Complexity: Complexity can be
introduced by organizing and managing several increments or
iterations, particularly in large projects. In order to guarantee
integration and synchronization, good project management is
needed.
4. Greater Initial Expenditure: As evolutionary models necessitate
continual testing, user feedback and prototyping, they may come
with a greater starting cost. This may be a problem for projects that
have limited funding.

Prepared by
Dr. Mita Pal
Build and Fix Model

Prepared by
Dr. Mita Pal
Build and Fix Model

Ref: https://ecomputernotes.com/software-engineering/build-and-fix-model
This model includes the following two phases.

•Build: In this phase, the software code is developed and passed on to the
next phase.

•Fix: In this phase, the code developed in the build phase is made error free.
Also, in addition to the corrections to the code, the code is modified
according to the user’s requirements.
• Two phase model consists of writing code fixing it.

• Product constructed without any formal requirement specifications or

design

• Directly developers starts building the product which is fixed

(changed/reworked) as many times as the customer desired.

• Error correction or addition of new functionality

• It’s a crude approach and does not follow in Industry.

Objectives of Build & fix Model

• Resolving Serious Issues:

• Reducing Unavailable Time:

• Keeping Data Safe:

• Reducing High-Impact Problems

Advantages

1.Requires less experience to execute or manage other than the ability to

program.

2.Suitable for smaller software.

3.Requires less project planning.

Disadvantages of Quick-fix Model:

• This model is not suitable for large project system and work only for
small programming exercises.

• Cost of using this process model is high as it requires rework until user’s
requirements are accomplished.

• Code becomes unfixable very soon (code quality may be degraded)

• Informal design of the software as it involves unplanned procedure.

• Maintenance is very difficult as lack of design document.

Example
• In situations where the project scope is small and the requirements are
relatively simple, the build and fix model can be a viable option.
Agile Development Models – Software
Engineering
•
In earlier days, the Iterative Waterfall Model was very popular for completing a
project. But nowadays, developers face various problems while using it to develop
software. The main difficulties included handling customer change requests
during project development and the high cost and time required to incorporate
these changes. To overcome these drawbacks of the Waterfall Model, in the mid-
1990s the Agile Software Development model was proposed.

What is Agile Model?

The Agile Model was primarily designed to help a project adapt quickly to change
requests. So, the main aim of the Agile model is to facilitate quick project
completion. To accomplish this task, agility is required. Agility is achieved by
fitting the process to the project and removing activities that may not be essential
for a specific project. Also, anything that is a waste of time and effort is
avoided. The Agile Model refers to a group of development processes. These
processes share some basic characteristics but do have certain subtle differences
among themselves.

Agile SDLC Models/Methods

Given below are some Agile SDLC Models:

• Crystal Agile methodology: The Crystal Agile Software Development

Methodology places a strong emphasis on fostering effective
communication and collaboration among team members, as well as
taking into account the human elements that are crucial for a successful
development process. This methodology is particularly beneficial for
projects with a high degree of uncertainty, where requirements tend to
change frequently.
•
• Dynamic Systems Development Method (DSDM): DSDSM
methodology is tailored for projects with moderate to high uncertainty
where requirements are prone to change frequently. Its clear-cut roles
 and responsibilities focus on delivering working software in short time
frames. Governance practices set it apart and make it an effective
approach for teams and projects.
•
• Feature-driven development (FDD): FDD approach is implemented
by utilizing a series of techniques, like creating feature lists, conducting
model evaluations, and implementing a design-by-feature method, to
meet its goal. This methodology is particularly effective in ensuring that
the end product is delivered on time and that it aligns with the
requirements of the customer.
•
• Scrum: Scrum methodology serves as a framework for tackling
complex projects and ensuring their successful completion. It is led by a
Scrum Master, who oversees the process, and a Product Owner, who
establishes the priorities. The Development Team, accountable for
delivering the software, is another key player.
•
• Extreme Programming (XP): Extreme Programming uses specific
practices like pair programming, continuous integration, and test-
driven development to achieve these goals. Extreme programming is
ideal for projects that have high levels of uncertainty and require
frequent changes, as it allows for quick adaptation to new requirements
and feedback.
•
• Lean Development: Lean Development is rooted in the principles of
lean manufacturing and aims to streamline the process by identifying
and removing unnecessary steps and activities. This is achieved
through practices such as continuous improvement, visual
management, and value stream mapping, which helps in identifying
areas of improvement and implementing changes accordingly.
• Unified Process: Unified Process is a methodology that can be tailored
to the specific needs of any given project. It combines elements of both
waterfall and Agile methodologies, allowing for an iterative and
incremental approach to development. This means that the UP is
characterized by a series of iterations, each of which results in a
working product increment, allowing for continuous improvement and
the delivery of value to the customer.
•
All Agile Software Development Methodology discussed above share the same
core values and principles, but they may differ in their implementation and
specific practices. Agile development requires a high degree of collaboration and
communication among team members, as well as a willingness to adapt to
changing requirements and feedback from customers.

In the Agile model, the requirements are decomposed into many small parts that
can be incrementally developed. The Agile model adopts Iterative development.
Each incremental part is developed over an iteration. Each iteration is intended to
be small and easily manageable and can be completed within a couple of weeks
only. At a time one iteration is planned, developed, and deployed to the customers.
Long-term plans are not made.

Steps in the Agile Model

The agile model is a combination of iterative and incremental process models. The
steps involve in agile SDLC models are:

• Requirement gathering
• Design the Requirements
• Construction / Iteration
• Testing / Quality Assurance
• Deployment
• Feedback
 Steps in Agile Model

1. Requirement Gathering: In this step, the development team must

gather the requirements, by interaction with the customer.
development team should plan the time and effort needed to build the
project.

2. Design the Requirements:- In this step, the development team will

use user-flow-diagram or high-level UML diagrams to show the
working of the new features and show how they will apply to the
existing software. Wireframing and designing user interfaces are done
in this phase.

3. Construction / Iteration: In this step, development team members

start working on their project, which aims to deploy a working product.

4. Testing / Quality Assurance:- Testing involves Unit

Testing, Integration Testing, and System Testing. A brief introduction of
these three tests is as follows:
 • Unit Testing: Unit testing is the process of checking small
pieces of code to ensure that the individual parts of a program
work properly on their own. Unit testing is used to test
individual blocks (units) of code.
•
• Integration Testing: Integration testing is used to identify
and resolve any issues that may arise when different units of
the software are combined.
•
• System Testing: Goal is to ensure that the software meets the
requirements of the users and that it works correctly in all
possible scenarios.
•
5. Deployment: In this step, the development team will deploy the
working project to end users.

6. Feedback: This is the last step of the Agile Model. In this, the team
receives feedback about the product and works on correcting bugs
based on feedback provided by the customer.

The time required to complete an iteration is known as a Time Box. Time-box

refers to the maximum amount of time needed to deliver an iteration to
customers. So, the end date for an iteration does not change. However, the
development team can decide to reduce the delivered functionality during a
Time-box if necessary to deliver it on time. The Agile model’s central principle is
delivering an increment to the customer after each Time-box.

When To Use the Agile Model?

• When frequent modifications need to be made, this method is

implemented.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with the team all the time.
• when the project needs to be delivered quickly.
• Projects with few regulatory requirements or not certain requirements.
• projects utilizing a less-than-strict current methodology
• Those undertakings where the product proprietor is easily reachable
• Flexible project schedules and budgets.
Advantages of the Agile Model
• Working through Pair programming produces well-written compact
programs which have fewer errors as compared to programmers
working alone.
• It reduces the total development time of the whole project.
• Agile development emphasizes face-to-face communication among
team members, leading to better collaboration and understanding of
project goals.
• Customer representatives get the idea of updated software products
after each iteration. So, it is easy for him to change any requirement if
needed.
• Agile development puts the customer at the center of the development
process, ensuring that the end product meets their needs.
•

Disadvantages of the Agile Model

• The lack of formal documents creates confusion and important
decisions taken during different phases can be misinterpreted at any
time by different team members.
• It is not suitable for handling complex dependencies.
• The agile model depends highly on customer interactions so if the
customer is not clear, then the development team can be driven in the
wrong direction.
• Agile development models often involve working in short sprints,
which can make it difficult to plan and forecast project timelines and
deliverables. This can lead to delays in the project and can make it
difficult to accurately estimate the costs and resources needed for the
project.
• Agile development models require a high degree of expertise from team
members, as they need to be able to adapt to changing requirements
and work in an iterative environment. This can be challenging for teams
that are not experienced in agile development practices and can lead to
delays and difficulties in the project.
• Due to the absence of proper documentation, when the project
completes and the developers are assigned to another project,
maintenance of the developed project can become a problem
•
Prepared by
Dr. MIta Pal