Process Models

Text Book Reference:

Roger S. Pressman, Software Engineering
Mc Graw-Hill International Edition, 2020.
A Software Process Model is a structured framework used to
plan, develop, test, and maintain software systems. It provides a
systematic way to manage and control the software development
process. Different models are designed to address specific types
of projects and team dynamics
Software process model
Process models prescribe a distinct set of activities, actions,
tasks, milestones, and work products required to engineer
high quality software.
Process models are not perfect, but provide roadmap for
software engineering work.
Software models provide stability, control, and organization
to a process that if not managed can easily get out of control
Software process models are adapted to meet the needs of
software engineers and managers for a specific project.
 Difference between software
process and software
product:
Aspect Software Process Software Product
A framework or set of activities for
Definition The final result of the development process.
creating software.
Focus On the methodology and steps of creation. On the end software delivered to users.

Tangible/Intangible Intangible (a plan or set of activities). Tangible (a usable application or system).

Waterfall Model, Agile Model, Testing
Examples Web apps, desktop apps, mobile apps, etc.
Processes.
To ensure the development process is
Purpose To meet user needs or solve a problem.
efficient and consistent.
Efficient development of high-quality
Outcome Usable software that fulfills requirements.
software.
Build and Fix Model

The earlier approach

Product is constructed without specification or any attempt
at design.
developers simply build a product that is reworked as many
times as necessary to satisfy the client.
model may work for small projects but is totally
unsatisfactory for products of any reasonable size.
Build and Fix Model
Steps in the Build and Fix Model:
[Link] the First Version: The initial version of the software is developed.
[Link] Until Client is Satisfied: Continuous modifications are made based on
feedback until the client approves the product.
[Link] Phase: After the product is delivered, it enters the maintenance
phase for updates and fixes.
[Link]: The software is retired when it is no longer needed or feasible to
maintain.

Advantages:
Simple and easy to implement.
No need for complex planning.
Disadvantages:
Lack of structure and documentation.
Difficult to scale or maintain.
Unsuitable for large, complex
projects. impossible to predict and
manage
Software Development Life Cycle /
Process model /
Software Development Life Cycle : -
Software Development Life Cycle (SDLC) is a process used by software
industry to design, develop and test high quality software. The SDLC aims to
produce high-quality software that meets or exceeds customer expectations,
reaches completion within times and cost estimates.

SDLC for short, is a well-defined, structured sequence of stages in software

engineering to develop the intended software product.
it is a team of engineers must incorporate a development strategy that
encompasses the process, method and tools layers. Each phase has various
activities to develop the software product. It also specifies the order in which
each phase must be executed.
A software life cycle model is either a descriptive or prescriptive
characterization of how software is or should be developed.
A descriptive model describes the history of how a particular software system
was developed.
Prescriptive Process Models
Prescriptive process models advocate an orderly approach to software
engineering
Organize framework activities in a certain order
Process framework activity with set of software engineering actions.
Each action in terms of a task set that identifies the work to be accomplished
to meet the goals.
The resultant process model should be adapted to accommodate the nature
of the specific project, people doing the work, and the work environment.
Software engineer choose process framework that includes activities like;
Communication
Planning
Modeling
Construction
Deployment
The Waterfall Model/
Classical Model/
Linear Model
Sometimes called the classic life cycle or the waterfall model, the linear (
sequential) model suggests a systematic, sequential approach to software
development that begins at the system level and progresses through analysis,
design, coding, testing, and maintenance.
Each phase must be completed before moving to the next.
It is one of the earliest models used in software engineering and is called
"Waterfall" because the development phases flow downward, like a waterfall,
from one to the next.
Waterfall Model or Classic Life Cycle
1. Requirements Analysis
analyzed, and documented in a detailed requirements specification document.
2. Design phase translates these requirements into a system architecture and detailed
design. High-level design (HLD) focuses on system architecture, while low-level design
(LLD) provides detailed specifications for individual modules and components.
3. Once the design is finalized, the project moves to the Coding phase, where developers
write the actual code to implement the design.
4. The completed software then enters the Testing phase, during which it is rigorously
tested to identify and fix any defects, ensuring it meets the requirements and performs
as expected.
5. Finally, the project transitions to the Maintenance phase, where the deployed
software is monitored, bugs are fixed, and updates or enhancements are made based
on user feedback.
Waterfall Model (contd.)

Requirement Analysis and Definition: systems services,

constraints and goals are defined by customers with system
users.
Scheduling tracking:
Assessing progress against the project plan.
Require action to maintain schedule.

System and Software Design: establishes and overall

system architecture. Software design involves
fundamental system abstractions and their relationships.
Waterfall Model (contd.)

Integration and system testing: The individual program unit

or programs are integrated and tested as a complete
system to ensure that the software requirements have
been met. After testing, the software system is delivered to
the customer.

Operation and Maintenance: Normally this is the longest

phase of the software life cycle. The system is installed and
put into practical use. Maintenance involves correcting
errors which were not discovered in earlier stages of the
life-cycle.
Waterfall Model - Examples
In the olden days, Waterfall model was used to develop
enterprise applications like Customer Relationship
Management (CRM) systems, Human Resource
Management Systems (HRMS), Supply Chain Management
Systems, Inventory Management Systems, Point of Sales
(POS) systems for Retail chains etc.

Waterfall is still widely used in traditional organizational

environments and processes. Research shows that 51% of
organizations still use Waterfall, based on a 2017 report
from the Project Management Institute.
 When to Use the Waterfall Model
Requirements are well-documented, clear, and fixed.
The project is small and straightforward.
Resources are limited, and a structured process is necessary.
The client prefers a formal approval process at each stage.

When Not to Use the Waterfall Model

Requirements are likely to change.
The project is complex or high-risk.
There is a need for continuous user feedback.
Quick delivery of working software is required.

NOTE : Waterfall Model is best suited for projects where requirements are
stable and well-understood. However, its lack of flexibility and iterative
feedback makes it less ideal for modern, dynamic projects.
Advantages of Waterfall model

Advantages of Waterfall model

All phases are clearly defined
One of the most systemic methods for software
development
Being oldest, this is one of the time tested models
It is simple and easy to use
Drawbacks of waterfall model

Drawbacks of waterfall model

Difficult to define the all the requirements at the
beginning of the project
Model is not suitable for accommodating any
change
A working version of the system is not seen until
late in the life
It does not scale up well to large projects
Real projects are rarely sequential
The V-Model
V-Model, also known as the Verification and Validation Model
It is an extension of the Waterfall Model that emphasizes the importance of
testing at each development stage.
It is shaped like the letter "V" to represent the relationship between the
development phases on the left side and their corresponding testing phases
on the right side.
Each development phase has a directly associated testing phase to ensure
quality and correctness.

Verification: Are we building the product right?

Verification is Static Testing (without executing the
code) Reviewing requirements, design documents,
conducting inspections, peer reviews, using analysis
techniques to ensure correctness.
Validation: Are we building the right product?
Validation is the Dynamic Testing (executing the code).
Performing various types of testing, such as unit
testing, integration testing, system testing, and
acceptance testing
Key Differences

Aspect Verification Validation

Are we building the product Are we building the right
Question
right? product?

Focus Process-oriented Product-oriented

Testing Type Static Testing Dynamic Testing

Ensure correctness of the

Goal Ensure user needs are met
process

When During development phases After implementation

Functional testing, acceptance

Examples Reviews, inspections, analysis
testing
 Phases of the V-Model
[Link] Modeling:
1. Focus: Gathering and analyzing user requirements.
2. Corresponding Test Phase: Acceptance Testing ensures the final product meets
user requirements.
[Link] Design:
1. Focus: Defining the high-level system structure and components.
2. Corresponding Test Phase: System Testing validates the system's overall
functionality.
[Link] Design:
1. Focus: Designing the details of individual components or modules.
2. Corresponding Test Phase: Integration Testing ensures that components work
together correctly.
[Link] Generation:
1. Focus: Writing the actual code for the components.
2. Corresponding Test Phase: Unit Testing verifies the functionality of individual
components.
 Key Features of the V-Model
Verification: Activities on the left side of the "V" focus on planning,
designing, and building the product.
Validation: Activities on the right side of the "V" ensure the product
meets requirements through rigorous testing.
Parallel Testing: Each phase has a corresponding test phase that
begins as soon as the development phase is completed.

Advantages of the V-Model Disadvantages of the V-Model

[Link] Testing: Testing begins at the [Link]: Similar to the Waterfall
requirements stage, reducing the risk of Model, changes in requirements are difficult
defects in later stages. to accommodate once the process has
[Link] Structure: The model is easy to begun.
understand and implement, with clearly [Link]: Extensive testing at every stage
defined stages. increases project costs.
[Link] Assurance: Each development phase [Link] Suitable for Complex or Agile
is validated through its corresponding testing Projects: It is less effective for projects with
phase, ensuring high-quality outcomes. evolving requirements or dynamic needs.
Applications of the V-Model
The V-Model is ideal for projects where quality is critical, such as in healthcare, aviation, and
defense systems. It is also suitable for smaller projects with well-defined and stable
requirements.
Incremental Process Model
Incremental Process Model is a software development approach that
combines the iterative nature of development with a step-by-step
delivery of the final product.
Instead of delivering the software as a whole, it is divided into smaller,
more manageable increments. Each increment adds functionality to the
previously delivered software, building on the work already done.

C- Communication
P - Planning
M Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds on

pieces already delivered
The Incremental Model
Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering part of
the required functionality.
First Increment is often core product
Includes basic requirement
Many supplementary features (known & unknown) remain undelivered
A plan of next increment is prepared
Modifications of the first increment
Additional features of the first increment
It is particularly useful when enough staffing is not available for the whole
project
Increment can be planned to manage technical risks.
Incremental model focus more on delivery of operation product with each
increment.
The Incremental Model
User requirements are prioritised, and the highest priority requirements
are included in early increments.
Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to evolve.
Customer value can be delivered with each increment, so system
functionality is available earlier.
Early increments act as a prototype to help elicit requirements for later
increments.
Lower risk of overall project failure.
The highest priority system services tend to receive the most testing.
How the Model Works
1. The development begins with a small, basic set of functionality that is delivered as
the first increment.
2. Subsequent increments add new features and enhance the existing system based
on feedback and updated requirements.
3. Over time, the system evolves into a full-featured product, with functionality
improving incrementally.

When to Use the Incremental Model

Projects where requirements are well-defined but are expected to evolve over time.
Scenarios where early delivery of a basic version is crucial.
Projects that need regular feedback from clients or users.
Advantages
Rigid nature of sequential approach.
This method is great help when organization having low staff.
Generate working software quickly and early during the
software life cycle.
More flexible less costly to change scope and requirements.
Easier to test and debug during a small iteration.
Easier to manage risk because risky pierces are identified and
handled during its iteration.
Each increment is an easily managed milestone.
Disadvantages
Changes in early increments can affect subsequent
ones, leading to rework. (Dependency)
Planning and designing for future increments can
increase initial overhead.
If initial requirements are not clear, the model might
lead to inefficient iterations.
This model could be time consuming.
Each phase of an increment is rigid and do not overlap
each other.
Problems may arise in system architecture, all the
requirements are not gathered up entire software life
cycle.
Rapid Application Development
(RAD) Model
RAD Model, a type of software development model that emphasizes rapid
prototyping and iterative delivery.
In RAD model, the functional modules are developed in parallel as prototypes
and are integrated to make the complete product for faster product delivery.
 The RAD model is a - adaptation of the linear
sequential model in which rapid development is achieved by
using component-based construction.
If requirements are well understood and project scope is
constrained, the RAD process enables a development team to
create a functional within very short time periods
(e.g., 60 to 90 days).
This approach is ideal for projects where rapid delivery is
essential, and requirements are not fully defined upfront but
can evolve during the development process.

Key Characteristics of the RAD Model

Parallel Development: Different teams work on separate modules simultaneously,
reducing development time.
Iterative Process: Continuous feedback and iterations ensure the software meets user
expectations.
Short Timeframe: The development cycle typically spans 60-90 days, as depicted in the
diagram.
 The RAD model is structured around developing components or modules in parallel,
where each module is developed by a dedicated team and progresses through the
following stages:
[Link] Modeling:
1. Focuses on understanding the flow of information within the business.
2. Involves gathering requirements related to business objectives and processes.
[Link] Modeling:
1. Translates the gathered business information into data models.
2. Identifies the entities, their attributes, and the relationships among them.
[Link] Modeling:
1. Defines the business processes that manipulate the data objects.
2. Ensures the defined processes align with the business goals.
[Link] Generation:
1. Automated tools are used to convert the models into executable software.
2. Generates prototypes quickly, allowing for iterative refinement.
[Link] and Turnover:
1. Testing is conducted for individual components and their integration.
2. Feedback is used for continuous improvement, leading to the final product.
 Advantages of the RAD Model
Faster development and delivery of software.
Encourages user involvement throughout the development process.
Flexible to changing requirements.

Disadvantages of the RAD Model

Requires highly skilled developers and designers.
May not be suitable for large-scale or complex projects.
Heavy reliance on automated tools and user feedback.
Total cost is higher than waterfall model
Time foundation create the problem to complete the project

When to Use the RAD Model

The RAD model is ideal for:
Projects with tight deadlines.
Systems that can be modularized for incremental delivery.
Projects with active user involvement.
Applications where requirements are evolving and not fully defined at the start.
Evolutionary Process Model
The Evolutionary Process Model is a software development methodology that
emphasizes iterative refinement of a system through multiple versions.
It allows for incremental delivery of a product by building initial versions of the
software and refining them based on user feedback and evolving requirements.
This model is particularly useful when the requirements are not fully understood at
the beginning of the project or are expected to change over time.
It offers a structured yet flexible approach to software development, ensuring that
the final product aligns closely with user needs while accommodating changes
during the development process.
Evolutionary Models are iterative, produce an increasingly more complete version
of the software with each iteration.
Evolutionary models are:
Prototyping
Spiral Model
Concurrent Development Model
Incremental vs. Iterative

Iterative
Develop through repeated cycles
Start simple, expecting to change
Used to find the right solution
Used to improve candidate solution

Incremental
Develop some portions at a time
Gradually build up functionality
Allows value to be delivered early
Evolutionary Models:
Prototyping Model
The Prototyping Model is an evolutionary process model used in software development
where a prototype (an early, simplified version of the final product) is developed, tested,
and refined based on user feedback.
This model is particularly beneficial when requirements are unclear, incomplete, or not
well-defined at the start of the project.
By iteratively improving the prototype, the final system is gradually developed.

Quick
plan
communication
Modeling
Quick design

Construction
of prototype
Deployment
delivery & Construction
feedback of prototype
Phases of the Prototyping Model
[Link] Gathering and Analysis:
1. Basic requirements are gathered, focusing on identifying the features that need to be
demonstrated in the prototype.
[Link] Design:
1. A preliminary design of the system is created, focusing on user interfaces and critical
functionalities.
[Link] Building:
1. The initial prototype is developed based on the quick design. This prototype is often
incomplete but demonstrates the main functionalities.
[Link] Evaluation:
1. The prototype is presented to the users for feedback. Users interact with the prototype
to understand its features and suggest improvements.
[Link]:
1. Based on user feedback, the prototype is refined by adding, modifying, or removing
functionalities. This cycle continues until the user is satisfied.
[Link] System Development:
1. Once the prototype meets user expectations, it is converted into the final system with
complete functionality, and the prototype is discarded.
[Link] and Maintenance:
1. The final system is deployed, and ongoing maintenance ensures the system continues
to meet user needs.
Prototyping Model
Best approach when:
Objectives defines by customer are general but does not have details like input,
processing, or output requirement.
Developer may be unsure of the efficiency of an algorithm, O.S., or the form that
human machine interaction should take.
It can be used as standalone process model.
Model assist software engineer and customer to better understand what is to be built
when requirement are fuzzy.
Prototyping start with communication, between a customer and software engineer to
define overall objective, identify requirements and make a boundary.
Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
Quick design leads to prototype construction.
Prototype is deployed and evaluated by the customer/user.
Feedback from customer/end user will refine requirement and that is how iteration
occurs during prototype to satisfy the needs of the customer.
 Prototyping (cont..)

Both customers and developers like the prototyping

paradigm.
Customer/End user gets a feel for the actual system
Developer get to build something immediately.

Problem Areas:
Developer often makes implementation in order to get a
prototype working quickly without considering other factors
in mind like OS, Programming language, etc.

applied to make the prototype a working product, due to

that software quality suffers as a result.
Customer and developer both must be agree that the prototype
is built to serve as a mechanism for defining requirement.
 When to Use the Prototyping Model

Unclear Requirements
well understood at the beginning.
Complex Systems: When developing systems with complex user
interfaces or high interaction.
User-Driven Development: When user feedback is critical for
success.
Short Development Cycles: When rapid development and early
user interaction are essential.
 Types of Prototyping

[Link]/Rapid Prototyping:
The prototype is built quickly to gather user feedback and then discarded.
[Link] Prototyping:
The prototype is incrementally refined into the final system.
[Link] Prototyping:
Multiple prototypes of different parts of the system are developed and integrated later.
[Link] Prototyping:
Common in web development; involves three phases: creating a basic prototype, adding
functionality, and integrating with backend services.
Advantages of the Prototyping Model
[Link] Requirement Understanding:
It helps clarify and refine requirements
through iterative feedback. Disadvantages of the Prototyping Model
[Link] User Involvement: [Link] or Inaccurate Prototype:
Frequent interactions with users lead to a Users may misunderstand the prototype
product that meets user expectations. as the final product, leading to unrealistic
[Link] Risk of Failure: expectations.
Early detection of design flaws or [Link] Costs:
requirement gaps ensures fewer issues in Repeated iterations can lead to higher
the final product. development costs and time.
[Link] Feedback: [Link] on Short-Term Solutions:
Users can experience the system early in Developers may focus on building a quick
the development cycle. prototype rather than a scalable design.
[Link]: [Link] of Documentation:
Accommodates changes in requirements Frequent changes may result in
during development. insufficient documentation.
[Link] Creep:
Frequent changes in user requirements
can lead to uncontrolled scope expansion.
Evolutionary Models: The Spiral
Spiral Model
Couples iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model
It provide potential for rapid development of increasingly more
complete version of the software.
Using spiral, software developed in as series of evolutionary release.
Early iteration, release might be on paper or prototype.
Later iteration, more complete version of software.
Divided into framework activities (C,P,M,C,D). Each activity represent
one segment.
Evolutionary process begins in a clockwise direction, beginning at
the center risk.
First circuit around the spiral might result in development of a
product specification. Subsequently, develop a prototype and then
progressively more sophisticated version of software.
Unlike other process models that end when software is delivered.
It can be adapted to apply throughout the life of software.
Spiral Model

Advantages:
It is realistic approach for development for large scale
system
High amount of risk analysis
Good for large and mission-critical projects
Software is produced early in the software life cycle
Spiral Model
Disadvantages
It is not widely used.
Can be a costly to use
Risk analysis requires highly specific expertise.

analysis phase.

It demands considerable risk assessment expertise and

relies on this expertise for success.
It may be difficult to convince customers that the
evolutionary approach is controllable.
When to use Spiral model:

For medium to high-risk projects.

Long-term project commitment unwise because of potential changes to
economic priorities.
Users are unsure of their needs.
Requirements are complex.
New product line.
Significant changes are expected (research and exploration).
Waterfall vs Spiral Model
 Evolutionary : Concurrent Models
concurrent model of software engineering, where various
activities or tasks can occur simultaneously in different states.
Below is a description of the components in this model:
Key States:
[Link]: The initial state, where no activity has been started yet.
[Link] Development: The task or activity is actively being
worked on.
[Link] Review: The activity is being reviewed for quality,
correctness, or improvements.
[Link] Changes: Feedback from the review process requires
changes to be made.
[Link] Revision: Modifications based on feedback are being
implemented.
[Link]: The activity has reached a stable state and can be
used as a reference for future work.
[Link]: The activity or task has been completed successfully.
 Concurrent Development Model

It represented schematically as series of major technical activities, tasks, and their

associated states.
It is often more appropriate for system engineering projects where different
engineering teams are involved.
The activity-modeling may be in any one of the states for a given time.
All activities exist concurrently but reside in different states.
E.g.
The analysis activity (existed in the none state while initial customer
communication was completed) now makes a transition into the under
development state.
Analysis activity moves from the under development state into the awaiting
changes state only if customer indicates changes in requirements.
Series of event will trigger transition from state to state.
E.g. During initial stage there was inconsistency in design which was uncovered. This
will triggers the analysis action from the Done state into Awaiting Changes state.
Issues on Evolutionary Processes model
[Link] poses a problem to project planning:
In the Evolutionary Process Model, prototyping is integral, but it can complicate project
planning. The difficulty arises because prototypes often evolve into the final system,
making it hard to predict resources, timelines, and exact requirements upfront.
[Link] of maximum speed for evolution:
Evolutionary Processes do not define or enforce an optimal speed for software evolution.
This can lead to inefficiencies, as the model relies on continuous iterations, which may
delay final delivery.
[Link] on flexibility and extendibility over high quality:
The primary goal of the Evolutionary Process Model is to be adaptable and extensible.
However, this flexibility can sometimes come at the cost of quality if not managed
properly. Teams may prioritize quick iterations over thorough testing or refinement.
Implications:
These issues highlight that while the Evolutionary Process Model is beneficial for projects
requiring adaptability, it may not be suitable for projects with strict timelines, rigid
requirements, or a strong focus on high-quality deliverables.