UNIT III

Process Models

Prescriptive process models/paradigm were introduced to control the

disorder that existed in the early days of software development. At that time,
projects often failed because there was no clear structure. Developers would start
coding without properly understanding requirements, planning, or testing. This
created confusion, delays, cost overruns, and poor-quality software. To solve this
problem, structured models like the Waterfall model were proposed. These models
clearly defined phases such as requirements analysis, design, coding, testing, and
maintenance. The idea was to bring discipline, planning, and documentation into
software development.

Over time, these traditional models proved useful. They gave software
teams a roadmap to follow. Instead of working randomly, teams had a clear
sequence of activities. Managers could track progress, assign responsibilities, and
control quality more effectively. This structure reduced risk and improved
communication within the team.

However, even with structured models, software engineering still operates

on what is often called “the edge of chaos.” This means that software projects are
naturally complex and constantly changing. Requirements may change, technologies
evolve, customer expectations shift, and unexpected technical problems arise.
Unlike manufacturing, software development deals with intangible products and
human creativity, which makes it harder to predict and control completely.

So, while prescriptive models bring order and discipline, they cannot
eliminate uncertainty and complexity. Software development always involves
change, innovation, and problem-solving. That is why modern approaches combine
structured processes with flexibility, allowing teams to adapt while still maintaining
control.

In simple terms, prescriptive models reduce chaos, but they cannot remove
it entirely. Software engineering remains a dynamic and evolving activity that
requires both discipline and adaptability.

All software process models can accommodate the generic framework

activities, but each applies a different emphasis to these activities and defines a

Process Model Page 1

process flow that invokes each framework activity (as well as software engineering
actions and tasks) in a different manner.

The Waterfall Model

The Waterfall Model is one of the earliest and most traditional software
development models. It is called “waterfall” because the development process flows
downward step-by-step, just like water flowing from the top of a waterfall to the
bottom.
It is a linear and sequential approach, which means each phase must be
completed before the next phase begins. Once a phase is finished, the team usually
does not go back to make changes.

The waterfall model, sometimes called the classic life cycle, suggests a
systematic, sequential approach to software development that begins with
customer specification of requirements and progresses through planning, modeling,
construction, and deployment, culminating in ongoing support of the completed
software (Figure 2.3).

Phases of the Waterfall Model

1. Communication /Requirement gathering & analysis: In this phase, all the

requirements of the software are collected from the customer. The
system’s features, functions, and constraints are clearly documented.
2. Planning: As per the required gathered and analyzed now it is time to plan
accordingly. Planning simply focuses on software cost and resources

Process Model Page 2

 estimation, and defining the chronological time (months/years) required to
for developing the software and its tracking as per the defined plans.
3. Modeling /System Design: After requirements are finalized; the system
architecture and design are prepared. This includes database design, system
structure, and interface design.
4. Construction /Implementation of Coding and testing: Developers write the
actual program code based on the design documents. The completed
software is tested to find and fix errors. It ensures that the software
meets the specified requirements.
5. Deployment: The software is delivered and installed at the customer’s site.
After delivery, any bugs, updates, or improvements are handled in this
phase.

The waterfall model is the oldest paradigm for software engineering. However,
over the past three decades, supporters to question its efficacy [Han95]. Among
the problems that are sometimes encountered when the waterfall model is applied
are:

1. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly. As a
result, changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not
be available until late in the project time span. A major blunder, if undetected
until the working program is reviewed, can be disastrous.
In an interesting analysis of actual projects, it was found that the linear nature
of the classic life cycle leads to “blocking states” in which some project team
members must wait for other members of the team to complete dependent tasks.
In fact, the time spent waiting can exceed the time spent on productive work! The
blocking states tend to be more prevalent at the beginning and end of a linear
sequential process.

Process Model Page 3

Specialized Process Models.

In Software Engineering, Specialized Process Models are software development

models designed to address specific types of projects, technologies, or application
domains. Unlike generic models (like Waterfall or Incremental), these models are
applied when particular project characteristics demand a tailored approach.
specialized process models are evolved to meet modern development needs such as
reuse, formal verification, and web-based systems.

Below are the important specialized process models:

1. Component-Based Development (CBD) Model

The Component-Based Development (CBD) Model is a specialized software

process model that emphasizes the construction of software systems through the
integration of pre-existing, reusable software components rather than developing
every part of the system from the beginning. This approach evolved as software
systems became larger and more complex, making it inefficient and costly to
repeatedly design and code similar functionalities for different projects.
In this model, the development process begins with a thorough analysis of
system requirements. Once the requirements are understood, the development
team searches for already available components that can satisfy these needs
either fully or partially. These components may exist in internal repositories,
third-party libraries, commercial off-the-shelf (COTS) products, or open-source
platforms. Instead of writing new code for standard features such as
authentication, database connectivity, payment processing, or reporting systems,
developers integrate trusted components that have already been tested and
validated.
A key characteristic of the CBD model is its strong emphasis on reusability.
Reusing components not only reduces development time but also improves reliability
because the reused components are often previously tested in other applications.
However, simply selecting a component is not sufficient. Each component must
undergo a qualification process to ensure that it meets functional and non-
functional requirements such as performance, security, compatibility, and
scalability. After qualification, the component is adapted if necessary and then
integrated into the overall system architecture.
Integration is a critical phase in CBD. Since components may be developed by
different vendors using different technologies, careful attention must be given to
interface compatibility and communication between components. Middleware, APIs,

Process Model Page 4

and adapters are often used to ensure smooth interaction among components.
Proper architectural planning is essential to ensure that independently developed
components work together as a unified system.

The CBD model significantly reduces overall development cost and delivery time
because large portions of functionality are reused rather than redeveloped. It is
especially suitable in environments where reliable and well-documented reusable
components are readily available. However, challenges such as component mismatch,
dependency management, and version control must be carefully handled to achieve
successful implementation.

2. The Formal Method Model

The Formal Methods Model is a specialized software development approach that
applies rigorous mathematical techniques to specify, design, and verify software
systems. Instead of describing requirements and system behavior in natural
language, which may be ambiguous or incomplete, this model uses precise
mathematical notations and formal logic to define system functionality. Because
mathematics does not allow ambiguity, the resulting specifications are clear,
consistent, and exact.
In this model, the development process begins with the creation of a formal
specification. The system requirements are expressed using mathematical models
such as set theory, predicate logic, algebraic specifications, or state machines.
These formal descriptions define what the system must do without describing how
it will be implemented. After the specification phase, developers systematically
transform the formal specification into a design and then into executable code. At
each stage, mathematical reasoning is applied to ensure that the implementation
correctly reflects the original specification.
One of the most important advantages of the Formal Methods Model is that
it enables verification through mathematical proofs. Developers can prove that the
software satisfies certain properties, such as safety, security, or correctness,
before the system is deployed. This reduces the possibility of critical errors and
increases confidence in system reliability. Because of this high level of assurance,
formal methods are particularly suitable for safety-critical and mission-critical
systems, such as those used in aviation control systems, railway signaling, nuclear
power plants, and medical equipment, where a small software failure could lead to
catastrophic consequences.
However, despite its strengths, the Formal Methods Model has certain
limitations. The use of mathematical specifications requires highly skilled

Process Model Page 5

professionals who have expertise in formal logic and advanced mathematical
concepts.

3. Aspect-Oriented Software Development (AOSD)

Aspect-Oriented Software Development (AOSD) is a specialized process

approach designed to address problems that cannot be cleanly separated using
traditional programming techniques. In many software systems, certain concerns
such as security, logging, transaction management, and error handling affect
multiple modules at the same time. These are known as cross-cutting concerns
because they cut across different parts of the system. In object-oriented
development, such concerns often become scattered and tangled within multiple
classes, making the system harder to understand and maintain.
AOSD introduces the concept of separating these cross-cutting concerns
into independent units called aspects. Instead of embedding security checks or
logging code within every module, these concerns are defined separately and then
systematically integrated into the main program. This separation ensures that the
core business logic of the application remains clean and focused only on its primary
functionality, while additional system-wide services are handled independently.
By isolating cross-cutting concerns, AOSD significantly improves modularity.
Each aspect can be developed, tested, and modified without directly affecting the
core components of the system. This structured separation reduces code
duplication and enhances clarity. When updates are required—for example,
changing the security mechanism or modifying the logging format—the changes can
be made in one place rather than across many different modules. As a result,
maintenance becomes easier and less error-prone.
Aspect-Oriented Software Development builds upon and extends the
principles of object-oriented programming. While object-oriented methods
organize software around objects and classes, AOSD complements this by
organizing system-wide concerns into aspects. Together, they provide a more
powerful way to manage complexity in large-scale software systems.

Evolutionary Process Model

Software, like all complex systems, evolves over a period of time. Business and
product requirements often change as development proceeds, making a straight
line path to an end product unrealistic; tight market deadlines make completion of
a comprehensive software product impossible, but a limited version must be
introduced to meet competitive or business pressure; a set of core product or

Process Model Page 6

 system requirements is well understood, but the details of product or system
extensions have yet to be defined. In these and similar situations, you need a
process model that has been explicitly designed to accommodate a product that
evolves over time. Evolutionary models are iterative. They are characterized in a
manner that enables you to develop increasingly more complete versions of the
software. Following section describe two examples of evolutionary model

1. Prototyping Model

Often, a customer defines a set of general objectives for software, but

does not identify detailed requirements for functions and features. In other cases,
the developer may be unsure of the efficiency of an algorithm, the adaptability of
an operating system, or the form that human-machine interaction should take. In
these, and many other situations, a prototyping paradigm may offer the best
approach. Although prototyping can be used as a stand-alone process model, it is
more commonly used as a technique that can be implemented within the context of
any one of the process models noted in this chapter. Regardless of the manner in
which it is applied, the prototyping paradigm assists you and other stakeholders to
better understand what is to be built when requirements are fuzzy. The
prototyping paradigm (Figure 2.6) begins with communication. You meet with other
stakeholders to define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory.
Prototyping iteration is planned quickly, and modeling (in the form of a “quick
design”) occurs. A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface layout or output
display formats). The quick design leads to the construction of a prototype. The
prototype is deployed and evaluated by stakeholders, who provide feedback that is
used to further refine requirements. Iteration occurs as the prototype is tuned to
satisfy the needs of various stakeholders, while at the same time enabling you to
better understand what needs to be done. Ideally, the prototype serves as a
mechanism for identifying software requirements. If a working prototype is to be
built, you can make use of existing program fragments or apply tools (e.g., report
generators and window managers) that enable working programs to be generated
quickly.
But what do you do with the prototype when it has served the purpose
described earlier? Brooks [Bro95] provides one answer:
The prototype can serve as “the first system.” The one that Brooks recommends
you throw away. But this may be an idealized view. Although some prototypes are

Process Model Page 7

built as “throwaways,” others are evolutionary in the sense that the prototype
slowly evolves into the actual system.
Both stakeholders and software engineers like the prototyping paradigm.
Users get a feel for the actual system, and developers get to build something
immediately. Yet, prototyping can be problematic for the following reasons:

1. Stakeholders see what appears to be a working version of the software, unaware

that the prototype is held together haphazardly, unaware that in the rush to get it
working you hasn’t considered overall software quality or long-term maintainability.
When informed that the product must be rebuilt so that high levels of quality can
be maintained, stakeholders cry foul and demand that “a few fixes” be applied to
make the prototype a working product. Too often, software development
management relents.
2. As a software engineer, you often make implementation compromises in order to
get a prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability. After a time, you
may become comfortable with these choices and forget all the reasons why they
were inappropriate. The less-than-ideal choice has now become an integral part of
the system.

Process Model Page 8

2. Spiral Model

The Spiral Model is an advanced software development process that

combines the structured nature of the Waterfall approach with the flexibility of
prototyping. It was proposed by Barry Boehm in 1986. The main objective of this
model is to manage risk effectively while developing complex software systems.

The model is called “spiral” because its process diagram looks like a spiral
with many loops. Each loop of the spiral represents one development phase. As the
project progresses, the spiral expand outward, showing the growth of the system
and increasing cost and effort.

Unlike linear models, the Spiral Model does not move strictly from one phase
to another only once. Instead, it goes through repeated cycles (iterations). Each
cycle results in a more complete version of the software.

The most important feature of this model is risk analysis. Before

proceeding to the next step, possible risks are identified and solutions are planned
to reduce or eliminate those risks.

Each of the framework activities represent one segment of the spiral path
illustrated in Figure 2.7. As this evolutionary process begins, the software team
performs activities that are implied by a circuit around the spiral in a clockwise
direction, beginning at the center Risk is considered as each revolution is made.

Process Model Page 9

Planning (objective setting).
In this phase:
 Project objectives are defined.
 Requirements for that iteration are identified.
 Different approaches (alternatives) are considered.
 Constraints such as cost, time, and resources are analyzed.

This stage answers the question: What should we do next?

Risk Analysis:
This is the most important phase of the Spiral Model.
 All possible risks are identified (technical risks, cost risks, schedule risks).
 Risk evaluation is performed.
 Prototypes may be developed to reduce uncertainty.
 Alternative solutions are compared.

Examples of risks:

 New technology may not work properly.

 Budget may exceed estimation.
 Performance requirements may not be met.

If risks are too high, the project may be stopped.

Engineering (Development and Testing)

In this phase:
 System design is created.
 Coding is done.
 Testing is performed.
 A working version of the software is produced.
This phase is similar to development phases in other models.

Customer Evaluation
 The customer reviews the developed version.
 Feedback is collected.
 Suggestions for improvements are given.
 Decisions are made for the next cycle.
After this, the next spiral loop begins with updated requirements.

Process Model Page 10

Characteristics of Spiral Model
 It is risk-driven rather than document-driven.
 It supports incremental releases.
 It allows continuous customer involvement.
 It is suitable for long-term projects.
 Cost and time increase as the spiral expands.

Advantages of the spiral model are Early identification and reduction of risks
Flexible and adaptable to changes, Continuous customer feedback, Suitable for
complex and mission-critical systems and finally Better quality control.
With advantages spiral model has certain limitations like high cost due to
repeated risk analysis, complex management requires experienced risk analysts and
not suitable for small or low-budget projects.

Important Question (Assignment III)

Q. 1: Explain waterfall/classic life cycle model in detail.

Q.2: What is specialized Process Model? Explain its different types.

Q.3: What is Evolutionary Process model? Explain prototyping model in detail.

Q.4: Explain spiral model.

Process Model Page 11