1

Software Engineering

Noor Fatima
Noor.fatima@umt.edu.pk
 2

Chapter # 2
Software Process Models
 Linear Sequential model
3

Also known as the classic life cycle or waterfall

model, it suggests a systematic, sequential approach
to software development that begins at the system
level and progress through analysis, design,
coding, testing and support.
Linear Sequential model
4
 Linear Sequential model
5

● Used when
■ The requirements of a problem are reasonably well
understood
○ When work flows from communication through
deployment in a reasonably linear fashion.
 Disadvantages
6
● Real projects rarely follow the sequential flow
that the model proposes.
● It is often difficult for the customer to state all
requirements explicitly.
● A working version of the program will not be
available until late in the project time span.
● Linear nature leads to “blocking states”.
 V-model
7

 A variation in the representation of the waterfall

model is called V-model
 In reality there is no fundamental difference
between classical lifecycle and the V-model
 V model provides a way of visualizing how
verification and validation actions are applied to
earlier engineering work
V-model
8
 9

The incremental model

 The incremental model
10
● There are situations in which initial software requirements are
reasonably well defined
● Additionally, there may be compelling need to provide a
limited set of software functionality to users quickly and
then refine and expand on that functionality in later software
releases
● In such case you choose a process model that is designed to
produce that software in increments
 Incremental model
11

1st increment is often a core product, basic requirements are addressed

Planning for the next increment
Repeat until complete product is produced
 The incremental model
12
● The problem is broken into increments, and each increment is
tackled as a linear sequence
● Further increments can either be done after the previous ones,
or can overlap with the previous ones
● Incremental delivery focuses on the delivery of an operational
product with each increment
● Early increments are stripped-down versions of the final
product
Incremental model advantages
14
■ Early delivery is guaranteed
■ Progress of the whole project is not delayed if one
of the resources is not available for part of it
■ Particularly useful when staffing is unavailable for
a complete implementation
■ Early increments can be implemented with fewer
people
 15

Evolutionary Process Models

 Evolutionary Process Models
16
■ Business and product requirements change
(creeping requirements)
■ Above issues cannot be handled by linear
sequential model
■ Two Models
○ Prototyping Model
○ Spiral Model
 Prototyping
17
● Often, a customer defines a set of general objectives for
software, but does not identify detailed requirements for
function and features
● A quick design focuses on what the customer will see. From
this, a prototype is constructed
● The user evaluates it and improvements are made
● This continues in an iterative fashion until a satisfactory
product is achieved
● Ideally, prototype serves as a mechanism for identifying
software requirements
Prototyping
18

Quicker design focuses

on a representation of
aspects visible to end users.
e.g. human interface layout
or output display formats
 Benefits
19

● Misunderstandings between developers and

users identified
● Incomplete requirements found
● A working system is available quickly to
demonstrate feasibility
● Used as a basis for writing the specification for
production of quality software
 Problems
20
● The customer sees a working version and expects the
finished product to be available in a short time. This puts
pressure on the developer to take short cuts, at the expense
of quality and maintainability.
● The developer may make compromises for speed.
● Inappropriate tools may be used or inefficient algorithms
may be used, which then become integral parts of the
system.
● If the user isn’t focused on what they want, the system may
never be completed.
 The Spiral model
21
● Boehm’s (1988) spiral model couples the iterative nature
of prototyping with the controlled and systematic aspects
of the linear sequential model.
● Software is developed in a series of incremental releases.
● During the early releases, there may be just a paper model,
but the system becomes increasingly more complete.
● Unlike any of the other models, this model keeps revisiting
the system throughout its lifetime.
Spiral model
22
 The Spiral model
23

● The first circuit around the spiral might

result in development of a product
specification
● Subsequent passes around the spiral might
be used to develop a prototype
● When high risk involve we use this model
● The following might be progressively more
sophisticated version of the software
● Unlike other process models that end when
software is delivered, spiral can adapt to
apply throughout the life of s/w
 Differences between Spiral and
Incremental Model
24
● Both models, incremental and spiral offer partial
deliveries to the customer at different phases BUT ….
● The Incremental Model focuses on the delivery of a
fully-tested production code in a step-by-step fashion;
each step adds more functionality
● The Spiral Model focuses on the development of
prototypes at each stage which will be used only for
information gathering and then throw-away
 25

The RAD model

 Rapid Application Development
26
● Rapid Application Development is an adaptation of
linear sequential software development process
model that emphasises an extremely short
development cycle.
● A component-based construction approach is used.
● To use this approach, the project scope must be
constrained and the requirements should be well
understood.
● A task that should take no more than ninety days to
complete is modelled, generated and implemented.
● There can be several teams working on different
components during this ninety day time-box
 RAD model
27
Team # 1
Communication
Project Initiation
Requirement Modeling
Gathering Analysis
Design

Construction
Code
Test
Team # 2

Modeling
Analysis
Planning Design
Estimating
Scheduling Deployment
Tracking Construction
Delivery
Code
Support
Test
Team # n Feedback

Modeling
Analysis
Design

Construction
Code
Test

60 – 90 days
 RAD model
28
● Like other process models, the RAD approach maps
into the generic framework activities
● Communication
■ Works to understand the business problem and the
information characteristics that the software must
accommodate (requirements gathering)
● Planning
■ Describes the technical tasks to be conducted, the risks that
are likely, the resources that will be required, the work
products to be produced, and a work schedule
 Contd.
29
● Modeling
■ Establishes design representations that serve as the basis
for RAD’s construction activity(Encompasses the creation
of models that allow the developer and the customer to
better understand software requirements and the design that
will achieve those requirements)
● Construction
■ emphasizes the use of pre-existing software components
and the application of automatic code generation
(Combines code generation and the testing that is required
to uncover errors in the code)
 Contd.
30

● Deployment
■ Establishes a basis for subsequent iterations, if
required (the software as a complete entity or as a
partially completed increment is delivered to the
customer who evaluates the delivered product and
provides feedback based on the evaluation)
 Advantages of RAD
31

● Less time
● Reusability
 Problems with RAD
32

● For large, scalable projects, RAD requires

sufficient human resources to create the right
number of RAD teams
● RAD requires developers and customers who
are committed to the rapid-fire activities
necessary to complete a system in this time
frame, or failure will result.
● RAD is not suitable for many project types.