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: tsadjaidoo@[Link]
Office: Caesar Building, Room 413
COE 356: Introduction to Software Engineering
