SOFTWARE

PROCESS MODELS
Sarah Mazhar 1
 Process Models

Sequential Incremental Evolutionary Specialized Unified process Agile process

process model process models process models models model models

Component Extreme
Waterfall Incremental Prototyping Rapid Unified
based programming
Model Model model Process (RUP)
development (XP)

Rapid
Formal methods
Application Spiral model model
Development

Aspect oriented
Win-win spiral
software
model
development

Concurrent
development model

2
PRESCRIPTIVE PROCESS
MODELS
Prescriptive process models have been applied for many years in
an effort to
bring order and structure to software development.
Each of these models suggests a somewhat different process flow,
but all perform the same set of generic framework activities:
communication, planning, modeling, construction, and deployment.

3
Sequential process models, such as the waterfall and V-
models, are the oldest
software engineering paradigms.
The Linear Sequential model and waterfall model are considered
classical in nature and suggest a linear process flow that is often
inconsistent with modern realities (e.g., continuous change,
evolving systems, tight timelines) in the software world.

The Iterative Waterfall model and V model are used however, have
applicability in situations where requirements are well-defined and
stable.
4
WATERFALL MODEL

5
6
The waterfall model maps in to generic framework activities.

Waterfall
Model
Communicat Construc Deploym
Planning Modeling
ion tion ent
Analysis
Code
of
Generati Delivery
Requirem
on
ents
Design Testing Feedback

7
PROBLEMS
Real projects rarely follow the sequential flow that the model proposes.
As a result change can cause problems as the project proceeds.
Customer must have patience. A working version of program will not be
available until late in the project time-span.
It leads to blocking state: in which some project team members must
wait for other members of the team to complete dependent task.

8
 V MODEL

It means verification and validation .

• Just like WATER FALL model, The life
cycle of the V model is a sequential
path of the execution of the process.
• Each phase must be completed before
the next phase begins.
• The testing of the product is planned
in parallel with corresponding phase of
development.

9
 It should be used for small to
medium size projects where
WHEN TO USE V-

requirements are clearly defined.

It should be chosen when simple

MODEL?

technical resources are available

with needed technical expertise.

10
 PHASES OF V-
MODEL

Requirement
s
High-Level
Design
(HLD)
Low-Level
Design (LLD)
Implementat
ion
Coding
11
Requiremen In this model the requirements are gathered before its development and a
system test plan is created. The plan test focuses on meeting the
ts functionality specified in the requirements gathering.

High-Level It focuses on system architecture and design. It provide overview of the

solution, platform system, product and services/process. An integrated test
Design plan is created here as well as in order to test the pieces of the software
system ability to work together.

Low-Level Here the actual software components of software are design . It defines the
actual logic for each and every component of the system. Component test
Design are created in this phase as well.

Coding It is that phase where all the coding take place. Once coding is complete,
the path of execution up the right side of the V where the test plans
developed earlier are now put to use.

Implementat This is at the bottom of the V-model. Module design is converted into code
by developer.
ion
12
 • Simple and easy to use.
Testing activities like planning,
test design happens well before
coding.
Advanta • This saves a lot of time.
ges • Avoids the down word flow of
the defects.
• Works well for small projects
• Veryrequirements
where rigid and costare easily
flexible.
understood.
Software is developed during
the
implementation phase, so no
Disadvanta early prototypes of the
ges software are produced.
•If any changes happen, only
the test
requirement documents is
updated.
13
Incremental process models are iterative in nature and produce
working versions
of software quite rapidly.

14
 INCREMENTAL MODEL
First increment is often a core product
The core product is used by the customer (or undergoes detailed review).
As a result of use and/or evaluation, a plan is developed for the next increment. The plan
addresses the modification of the core product to better meet the needs of the customer and
the delivery of additional features and functionality.
Subsequent elements offer expanded functionality
This process is repeated following the delivery of each increment, until the product is
produced.

15
INCREMENTAL MODEL
The incremental model delivers software in small but usable pieces, called “increments.”
The incremental model combines the elements of the waterfall model (communication,
planning, modeling, construction, and deployment) in the iterative manner.
The incremental model delivers a series of releases, called increments, that provides
progressively more functionality for the customer as each increment in delivered.
In general, each increment builds on those that have already been delivered.

16
17
18
EXAMPLE
Word-processing software developed using the incremental paradigm might deliver
Basic file management, editing, and document production functional in the first
increment;
More sophisticated editing and document production capabilities in the second
increment;
Spelling and grammar checking in the third increment;
Advanced page layout capability in the fourth increment.

19
ADVANTAGES
Incremental development is particularly useful when staffing is unavailable for a complete.
Early increments can be implemented with fewer people.
If the core product is well received, then additional staff (if required) can be added to
implement the next increment.
In addition, increments can be planned to manage technical risks.
For example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of this hardware, thereby enabling partial functionality
to be delivered to end-users without inordinate delay.

20
RAPID APPLICATION
DEVELOPMENT (RAD)
The RAD model is a “high-speed” adaptation of the linear sequential model inn
which rapid development is achieved by using component-based construction.
Emphasizes short development cycle(60-90 days)
High speed adaptation of waterfall model.
Rapid development is achieved by using component based construction approach.
If requirements are well understood and project scope is constrained, it may allow
rapid creation of s/w systems.

21
 Like other process model, the RAD approach maps in to generic
framework activities.

Communication Planning Modeling Construction Deployment

Business Component
Integration
modeling Reuse

Automatic
Data
code Delivery
modeling
generation

Process
Testing Feedback
modeling

22
MODELING
• The information flow among business functions is modeled in a way that answers
the following questions:
• What information drives the business process?
• What information is generated?
Business Modeling • Who generates it?
• Where does the information go?
• Who processes it?
• And so on…..

• The information flow defined as part of the business modeling phase is

refined into a set of data objects (entities) that are needed to support the
Data Modeling business.
• The characteristics (called attributes) of each object are identified and the
relationship between these objects is defined.

23
 • The data objects defined in
the data modeling phase are
transformed to achieve the
Process information flow necessary
to implement a business
Modeli function.
ng • Processing descriptions are
created for adding,
modifying, deleting, or
retrieving a data object.

24
CONSTRUCTION
• RAD assumes the use of fourth generation techniques.
• Rather than creating software using conventional third
Component Reuse generation programming languages the RAD process
works to reuse existing program components (when
possible) or create reusable components (when necessary).
Automatic Code • Automated tools are used to facilitate construction of the
Generation software.
• Since the RAD process emphasizes reuse, many of the
program components have already been tested. This
Testing reduces overall testing time.
• However, new components must be tested and all
interfaces must be fully exercised.

25
 PROBLEMS WITH RAD
For large projects may require vast human resource (for many RAD teams).
Developers and customers must be able to cope with fast action.
For systems that are not highly modularized the rad approach may not work.
Rad may not be appropriate with technical risks high (e.g. New technology).

26
EVOLUTIONARY MODELS
Evolutionary process models recognize the iterative,
incremental nature of most software engineering projects and are
designed to accommodate change.
Evolutionary models, such as prototyping and the spiral model,
produce incremental work products (or working versions of the
software) quickly.
These models can be adapted to apply across all software
engineering
activities—from concept development to long-term system
maintenance.

27
 EVOLUTIONARY PROCESS
MODELS
Prototyping Model
Spiral Model
Win-win Spiral Model
V-Model

28
 PROTOTYPING MODEL
Prototyping Model assists the software engineer and the customer
to better understand what is to be built when requirements are
fuzzy.
Often customer defines a set of general objectives for software,
but does not identify detailed input, processing or output
requirements. In these situations a prototyping paradigm may
offer the best approach.

29
WHERE IS PROTOTYPE MODEL
USED?

Prototype model should be used when

the desired system needs to have a
lot of interaction with the end users.
Typically, online systems, web interfaces
have a very high amount of interaction
with end users, are best suited for
Prototype model.
30
 • Software engineer meet and define the overall objective
Communication of the software
• Identify what requirements are known, and outline area
where further definition is mandatory.

Quick Planning • Prototyping iteration is planned quickly.

• The quick design focuses on a representation of the

Modeling And customer/user (e.g, input approaches and output
Quick Design formats).
• The prototype is the model of the software
• It could be working model or nonworking model.
Construction Or • The prototype shows the functionality of the software.
Prototyping • The Prototype serve as the “First System”
• Ideally, the prototype serves as a mechanism for identifying
software requirements.
• The prototype is deployed and evaluated by the
customer/user.
• Feedback is used to refine requirements for the software to
be developed.
Deployment • Prototyping iteration occurs as the prototype is tuned to
satisfy the needs of the customer,, while at the same time
enabling the developer to better understand what needs to 31
 • A prototype can be developed when the
final properties are not entirely clear. The
direct contact between customer and
Advantages developer reduces misunderstandings.
Inconsistent requirements are discovered
• There is an
earlier, inherent
either risk
by the that sideor
developer effects
by theare
not sufficiently
customer who evaluates the prototype.
considered, especially nonfunctional
requirements such as reliability or safety.
Another risk is that the customer (or the
developer) considers the prototype as the first
version of the system, and that the system will
be evolved from the prototype, potentially
Challenges leading to poorly documented, badly
architected systems.
• The prototyping phase of a project may also
induce higher costs compared to a non
prototyped approach.
A prototype is a great way to clarify
ambiguous or unknown requirements;
however, don’t ever confuse it with the first 32
version of the actual system!
 SPIRAL MODEL
Combines iterative prototyping with systematic aspects of
the Waterfall model.
The spiral Model, is an evolutionary software process
model that couples the iterative nature of prototyping with
the controlled and systematic aspects of the linear
sequential model.
It provides the potential for rapid development of
incremental versions of the software.
Using the spiral model, software is developed in a series of
incremental releases.
During early iterations, the incremental releases might be
a paper model or prototype.
During later iterations, increasingly more complete
versions of the engineered system are produced.
33
A spiral model is divided into a number of framework activities also called task
Regions.
 •Spiral
Tasks model that
required to contains
• Taskssix task regions.
required to • Tasks • Tasks required
established define resources, required to to build one or
effective timelines, and assess both more
communication other project technical and representation
between related s of the
developer and information. management
risks. application.
Customer
customer. Risk Engineering
communicat Planning:
analysis: :
ion:

• Tasks required to • Tasks required to obtain

construct, test, customer feedback based
install, and on evaluation of the
provide user software representations
support (e.g. created during the
documentation engineering stager and
and training). implemented during the
Constructio installation stage.
Customer
n and
evaluation:
release:
34
Each of the regions is populated by a set of
work tasks, called a task set, that are adapted
to the characteristics of the project to be
undertaken.
For small projects, the number of work tasks
and their formality is low.

For larger, more critical projects, each task

region contains more work tasks that are
defined to achieve a higher level of formality.

35
 • Realistic to the development of
large-scale systems
Advantage • Iteratively reduces risk
s • Allows repeated use of the
• prototyping
Customers may approach
not like it, fearing
lack of control
• Demands risk assessment
expertise and relies on this
Problems expertise for success.
• If a major risk is not uncovered
and managed, problems will
undoubtedly occur.
• It is very lengthy process.
36
 WIN WIN SPIRAL MODEL
The objective of this model is to elicit
project requirements from the
customer.
The best negotiations strive for a “win-
win” result.
That is, the customer wins by getting
the system or product that satisfies the
majority of the customer’s needs and
the developer wins by working to
realistic and achievable budgets and
deadlines.
37
The concurrent process model allows a software team to
represent iterative
and concurrent elements of any process model.
Specialized models include the component-based model that
emphasizes component reuse and assembly; the formal methods
model that encourages a mathematically based approach to
software development and verification; and the aspect-oriented
model that accommodates crosscutting concerns spanning the
entire system architecture

38
The Unified Process is a “use case driven, architecture-centric,
iterative and incremental” software process designed as a
framework for UML methods and tools.
Personal and team models for the software process have been
proposed. Both
emphasize measurement, planning, and self-direction as key
ingredients for a
successful software process.

39
 Process Models

Sequential Incremental Evolutionary Specialized Unified process Agile process

process model process models process models models model models

Component Extreme
Waterfall Incremental Prototyping Rapid Unified
based programming
Model Model model Process (RUP)
development (XP)

Rapid
Formal methods
Application Spiral model model
Development

Aspect oriented
Win-win spiral
software
model
development

Concurrent
development model

40