Chapter 4:

 Software Engineering

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1
 Prescriptive Models
 Prescriptive process models advocate an
orderly approach to software engineering
That leads to a few questions …
 If prescriptive process models strive for
structure and order, are they inappropriate for
a software world that thrives on change?
 Yet, if we reject traditional process models
(and the order they imply) and replace them
with something less structured, do we make
it impossible to achieve coordination and
coherence in software work?

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 2
Prescriptive Process models
what do they do

 They provide stability, control, and organization to a

process that if not managed can easily get out of
control
 They provide order to the chaos of software
development
 They provide reasonable guidelines to software
team
 But not provide an answer to problem of change in
software development.

3
 The Waterfall
Model
Co m m u nic a t io n
p ro je c t in it ia t io n Planning
re q uire m e n t g a t h e rin g estimating Mo de ling
scheduling
a na lys is Co ns t ru c t io n
tracking
des ign De plo y m e n t
c ode
t es t d e liv e ry
s u pp o rt
f e e d ba c k

 It is the oldest paradigm for software

engineering
 It is regarded as linear/sequential approach
to software development (little iterations)
 But it is good when requirements are well
understood
 Although it is applicable to a new
development it is mostly applicable if we
want to adapt or enhance an existing system
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 4
The Waterfall Model
problems encountered

 Changes cause confusion

 It requires that customers state all requirements
explicitly at the beginning , although it has difficulty
in accommodating uncertainty that may exist.
 Late release of the working version (customer must
be patient)

5
 The V-Model

Provides a way
of visualising
how V&V are
applied

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 6
Incremental Model
 Combines the elements of waterfall model in an
iterative fashion
 It delivers software in small but usable increments.
 The process is repeated following the delivery of
each increment, until the complete product is
delivered.
 Basic requirements are addressed at the first
increment. p44

7
 The Incremental
Model
incre m e nt # n
Co m m u n i c a t i o n
Pla n n in g

Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n
code De p l o y m e n t
t est d e l i v e ry
fe e d b a c k

d e liv e ry o f
n t h in cre me n t
incre m e nt # 2

Co m m u n i c a t i o n
Pla n n in g

Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t

Co m m u n i c a t i o n
Pla n n in g
Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode
t est
De p l o y m e n t
d e l i v e ry d e liv e ry o f
fe e d b a c k

1 st in cre me n t

project calendar t ime

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 8
Evolutionary process model
examples

 We need a model that grows with

changes
 Prototyping model
 Ideal if the customer is clueless about the
details, but can define the general objectives
of the software
 It assists the software engineers and
customers to better understand what is to be
built.
 It essentially serves as a mechanism for
identifying software requirements.
 Prototyping model is designed to be thrown
away – it barely usable
 Disadvantages
• the customer sees what appears to be a 9
 Evolutionary Models:
Prototyping
Quick
Qu ic k p la n

Co m m u n ic at io n plan
communication

Modeling
Mo d e l i n g
Qu ic k d e s ig n
Quick design

De plo ym e n t
Deployment Construction
De liv e ry
delivery of prototype
& Fe e d b a&
ck Co n s t ru c t io n
feedback Construction
of
ofp ro
prototype
t o t yp e

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 10
The Spiral model
 It combines the iterative nature of prototyping and
the controlled aspects of the waterfall model.
 Software is developed in a series of evolutionary
releases, the initial release might be a paper model
or prototype and a more complete version at a later
stage.
 The first circuit around the spiral might result in the
development of a product specification, subsequent
passes might be used to develop a prototype and
more sophisticated versions progressively.

11
 Evolutionary Models: The
Spiral planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 12
 Evolutionary Models:
Concurrent
none

Mode ling a ct ivit y

rep res ents the s tate

 With this model all Under
de velopm ent
o f a s o ftware eng ineering
activity o r tas k

activities exist concurrently

but resides in different Await ing

states cha nge s

 Events on each activity will Under review

trigger transitions from one Under

state to another.
revis ion

Ba s e line d

Done

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 13
 Still Other Process
Models
 Component based development—the
process to apply when reuse is a
development objective
 Formal methods—emphasizes the
mathematical specification of
requirements
 AOSD—provides a process and
methodological approach for defining,
specifying, designing, and constructing
aspects

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 14
The unified process

 It attempts to draw on the best features of

traditional software process models and
implements many features of agile software
development.
 It is “use-case” driven (methods for describing the
customer's view of the system)
 It suggest a process flow that is iterative and
incremental
 It is a framework for object-oriented SE using UML.

15
Unified Process Phases
 Inception – it includes both the customer
communication and planning activities – where
requirements are described through the use of
preliminary use-cases
 Elaboration – it refines and expands the
preliminary use-cases that were developed as part
of the inception phase – elaboration will create an
executable architectural baseline that represent
the first cut executable system
 Construction – develops/acquire the software
components that will make each use-case
operational
 Transition – software is now given to the end-user
for beta testing, and user feedback reports 16
defects (manual and guides -developed)
 The Unified Process (UP)
elaboration
Ela b o ra t io n

Inc e p t io n
inception

c o ns t ruc t io n
Releas e
t ra ns it io n
s oft wa re inc rem e nt

p ro d uc t io n

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 17
Personal Software Process
(PSP)

 Every developer uses some process to build a

software
 Recommends five framework activities:
 Planning (size and resource estimates are developed
based on requirements. Defects estimates and project
schedule are also created)
 High-level design (Specifications and prototypes are
developed and all issues are recorded)
 High-level design review (formal verification methods
used to uncover design errors, and metrics are
maintained for important tasks)
 Development (component level design is refined, code is
generated, reviewed, compiled, and tested, metric
maintained for important tasks and work results)
 Postmortem (effectiveness of processes is determined
using measures and metrics collected, results of analysis
should provide guidance for modifying the process to
improve its effectiveness)
 stresses the need for each software engineer to
identify errors early and as important, to understand 18
Team Software Process
(TSP)

 The goal of TSP is to build a self directed

project team that organizes itself to
produce high quality software.
 Objectives
 Build self-directed teams that plan and track
their work, establish goals, and own their
processes and plans
 Show managers how to coach and motivate
their teams and maintain peak performance
 Accelerate software process improvement by
making CMM Level 5 behavior normal and
expected
 Provide improvement guidance to high-maturity
organizations
 A self directed team has a consistent 19