1

DR. (MRS) T-S.M.A. ADJAIDOO

z
02
Software
COE 356: Introduction to Software Engineering

Process Models
2

z
Today’s Lesson

A Generic
Prescriptive
Process
Model Models
COE 356: Introduction to Software Engineering
3

z
Process Model Recap

§ A process was defined as a collection of work activities, actions,

and tasks that are performed when some work product is to be
created.

§ Each of these activities, actions, and tasks reside within a

COE 356: Introduction to Software Engineering

framework or model that defines their relationship with the

process and with one another.
4

z
Process Model Recap

Five framework activities Some umbrella activities

§ Communication § Project tracking and control
§ Planning § Risk management
§ Modelling § Quality assurance

Construction Configuration management

COE 356: Introduction to Software Engineering

§ §

§ Deployment § Technical reviews

5

A Generic Process
Model
Each framework activity is populated by a set
of software engineering actions.
Each software engineering action is defined by
a task set that identifies:
• The work tasks that are to be completed
The work products that will be produced
COE 356: Introduction to Software Engineering

• The quality assurance points that will be

required
• The milestones that will be used to indicate
progress
6

z
The Process Flow

§ The process flow describes how the framework activities and the
actions and tasks that occur within each framework activity are
organized with respect to sequence and time
§ Linear process flow

§ Iterative process flow

COE 356: Introduction to Software Engineering

§ Evolutionary process flow

§ Parallel process flow

 The Process Flow
z
7
COE 356: Introduction to Software Engineering
 The Process Flow
z
8
COE 356: Introduction to Software Engineering
9

z
Defining a Framework Activity

§ What actions are appropriate for a framework activity, given the

nature of the problem to be solved, the characteristics of the
people doing the work, and the stakeholders who are sponsoring
the project?
COE 356: Introduction to Software Engineering
10

z
Defining a Framework Activity

For a small software project requested by one person with

simple requirements:

Activity Communication
Action Phone Call
• Make contact with stakeholder via telephone
COE 356: Introduction to Software Engineering

• Discuss requirements and take notes

Tasks • Organize notes into a brief written statement of
requirements
• E-mail to stakeholder for review and approval.
11

z
Defining a Framework Activity

§ If the project was considerably more complex with many

stakeholders, each with a different set of requirements, the
communication activity might have six distinct actions:
§ inception, elicitation, elaboration, negotiation, specification, and
validation.
COE 356: Introduction to Software Engineering

§ Each of these actions would have many work tasks and a

number of distinct work products.
12

z
Identifying a Task Set

§ Each software engineering action can be represented by a

number of different task sets – each a collection of work tasks,
related work products, quality assurance points, and project
milestones.
§ A task set that best accommodates the needs of the project and
the characteristics of the team should be chosen.
COE 356: Introduction to Software Engineering

§ This implies that a software engineering action can be adapted

to the specific needs of the software project and the
characteristics of the project team.
13

z
Prescriptive Process Models

§ Prescriptive process models were originally proposed to bring

order to the chaos of software development.

§ They prescribe a set of process elements—framework activities,

software engineering actions, tasks, work products, quality
assurance, and change control mechanisms for each project.
§ Each process model also prescribes a process flow - that is, the
COE 356: Introduction to Software Engineering

manner in which the process elements are interrelated to one

another
§ They are sometimes referred to as “traditional” process models
14

z
Prescriptive Process Models

§ Waterfall model
§ V-model

§ Incremental model

§ Prototyping model
COE 356: Introduction to Software Engineering

§ Spiral Model

§ Concurrent Developmental Model

15

z
Waterfall Model

§ The waterfall model, sometimes called the classic life cycle,

suggests a systematic, sequential approach to software
development
COE 356: Introduction to Software Engineering

§ What can be some of the downfalls with this model?

16

z
Waterfall Model

§ There are times when the requirements for a problem are well
understood and work flows in a reasonably linear fashion.

§ Usually, when well-defined adaptations or enhancements to an

existing system must be made
§ It may also occur in a limited number of new development
COE 356: Introduction to Software Engineering

efforts, but only when requirements are well defined and

reasonably stable.
17

V - Model
§ It is a variation of the waterfall
model

§ Depicts the relationship of quality

assurance actions to the actions
associated with communication,
COE 356: Introduction to Software Engineering

modelling, and early construction

activities
18

z
V - Model

§ Software team starts by moving down

the left side of the V
§ Once code has been generated, the
team moves up the right side of the V.
§ Series of tests that validate each of the
models created are validated
COE 356: Introduction to Software Engineering

§ The V-model provides a way of

visualizing how verification and
validation actions are applied to earlier
engineering work.
19

z
Incremental Model

§ This model applies

linear sequences in
a staggered fashion
as calendar time
progresses.

§ Each linear
COE 356: Introduction to Software Engineering

sequence produces
deliverable
“increments” of the
software
20

z
Incremental Model

§ When an incremental model is used, the first increment is often

a core product.

§ That is, basic requirements are addressed but many

supplementary features remain undelivered.
§ As a result of use and/or evaluation, a plan is developed for the
COE 356: Introduction to Software Engineering

next increment
§ This process is repeated following the delivery of each
increment, until the complete product is produced.
21

z
Incremental Model

§ There may be well defined initial software requirements, but also

a 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.
§ Incremental development is particularly useful when staffing is
COE 356: Introduction to Software Engineering

unavailable for a complete implementation by the business

deadline that has been established for the project.
22

z
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
COE 356: Introduction to Software Engineering

that human-machine interaction should take.

§ In these, and many other situations, a prototyping paradigm may
offer the best approach.
23

Prototyping
Model
Iteration occurs as the
prototype is tuned to
satisfy the needs of
various stakeholders,
while at the same time
COE 356: Introduction to Software Engineering

enabling you to better

understand what needs
to be done.
24

z
Prototyping Model

§ 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 other process
models.
§ Regardless of the manner in which it is applied, the prototyping
COE 356: Introduction to Software Engineering

paradigm assists you and other stakeholders to better

understand what is to be built when requirements are fuzzy.

§ What problems can occur with the prototyping model?

25

z
Spiral Model

§ It provides the potential for rapid development of increasingly

more complete versions of the software

§ Software is developed in a series of evolutionary releases.

§ During early iterations, the release might be a model or

prototype.
COE 356: Introduction to Software Engineering

§ During later iterations, increasingly more complete versions of

the engineered system are produced
26

Spiral Model
§ 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
then progressively more
COE 356: Introduction to Software Engineering

sophisticated versions of the

software.

§ Each pass through the planning

region results in adjustments to
the project plan.
27

Spiral Model
§ Cost and schedule are
adjusted based on feedback
derived from the customer
after delivery.

§ The project manager adjusts

the planned number of
COE 356: Introduction to Software Engineering

iterations required to complete

the software.
28

z
Spiral Model

§ The spiral model is a realistic approach to the development of large-scale

systems and software because software evolves as the process progresses, the
developer and customer better understand and react to risks at each
evolutionary level.

§ It uses prototyping as a risk reduction mechanism but, more important, enables

you to apply the prototyping approach at any stage in the evolution of the
product.

§ It maintains the systematic stepwise approach suggested by the classic life cycle
COE 356: Introduction to Software Engineering

but incorporates it into an iterative framework that more realistically reflects the
real world.
§ It demands a direct consideration of technical risks at all stages of the project
and, if properly applied, should reduce risks before they become problematic.
29

z
Concurrent
Developmental
Model
The concurrent development
model allows a software team to
represent iterative and concurrent
elements of any of the process
COE 356: Introduction to Software Engineering

models already described

30

z
Concurrent
Developmental
Model
§ A schematic representation of the
modelling activity using a concurrent
modelling approach.
§ The activity may be in any one of the
states noted at any given time.
COE 356: Introduction to Software Engineering

§ Similarly, other activities, actions, or

tasks can be represented in an
analogous manner.
§ All software engineering activities
exist concurrently but reside in
different states.
31

z
Concurrent Developmental Model

§ For example, early in a project the communication activity has

completed its first iteration and exists in the awaiting changes
state.

§ The modelling activity which existed in the inactive state while

initial communication was completed, now makes a transition
into the under development state.
COE 356: Introduction to Software Engineering

§ If, however, the customer indicates that changes in requirements

must be made, the modelling activity moves from the under
development state into the awaiting changes state.
32

z
Concurrent Developmental Model

§ Concurrent modelling defines a series of events that will trigger

transitions from state to state for each of the software
engineering activities, actions, or tasks.

§ For example, during early stages of design an inconsistency in

the requirements model is uncovered.
COE 356: Introduction to Software Engineering

§ This generates the event analysis model correction, which will

trigger the requirements analysis action from the done state into
the awaiting changes state.
33

z
Concurrent Developmental Model

§ Concurrent modelling is applicable to all types of software

development and provides an accurate picture of the current
state of a project.

§ Rather than confining software engineering activities, actions,

and tasks to a sequence of events, it defines a process network.
§ Each activity, action, or task on the network exists
COE 356: Introduction to Software Engineering

simultaneously with other activities, actions, or tasks.

§ Events generated at one point in the process network trigger

transitions among the states.
34

z
Exercise

§ Try to develop a set of actions for the communication activity.

Select one action and define a task set for it.

§ Provide three examples of software projects that would be

amenable to the each of the process models discussed. Be
specific
COE 356: Introduction to Software Engineering
35

Any Questions?
z
The End
Contact: [email protected]

Office: Caesar Building, Room 413

COE 356: Introduction to Software Engineering