Process Models

Pressman R S, Bruce R.Maxim, “Software engineering - A

Practitioner’s Approach”, Eighth Edition, Tata McGraw-Hill, 2014
Chapter 4: 4.1, 4.3
1
 Recap
Topic
Generic Process Model
Defining a framework activity
Identifying a task set
Process Patterns
Process assessment and improvement
Personal and Team process models
Process Technology
Product and Process

2
 Recap
• A generic process model for software engineering
encompasses a set of framework and umbrella activities,
actions, and work tasks
• Each of a variety of process models can be described by
a different process flow
– a description of how the framework activities, actions, and tasks
are organized sequentially and chronologically
• Process patterns can be used to solve common problems
that are encountered as part of the software process
3
 Recap
• 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
• Process technology tools allow a software organization to build
an automated model of the process framework, task sets, and
umbrella activities
• The duality of product and process is one important element in
keeping creative people engaged as software engineering
continues to evolve
4
 Topics Covered
Topic Text Book Reference
Prescriptive Process Models 4.1

The Unified Process 4.3

5
 Process Models
• Process models were originally proposed to bring order to
the chaos of software development
• History has indicated that these models have brought a
certain amount of useful structure to software engineering
work and have provided a reasonably effective road map
for software teams
• However, software engineering work and the products
that are produced remain on “the edge of chaos”

6
 “the edge of chaos”
• The edge of chaos is defined as “a natural state between order
and chaos, a grand compromise between structure and
surprise.”
• The edge of chaos can be visualized as an unstable, partially
structured state . . .
• It is unstable because it is constantly attracted to chaos or to
absolute order
Each process model described in this presentation tries to strike a
balance between the need to impart order in a chaotic world and the
need to be adaptable when things change constantly
7
 Prescriptive Process Models

Chapter 4.1

8
 Overview
• A prescriptive process model strives for structure and
order in software development
• Activities and tasks occur sequentially with defined
guidelines for progress
• In prescriptive process approach in which order and
project consistency are dominant issues

9
 Overview
• We call them “prescriptive” because 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 (also
called a work flow )—that is, the manner in which the
process elements are interrelated to one another

10
The Waterfall Model
 Waterfall Model
• There are times when the requirements for a problem are well
understood—
• When work flows from communication through deployment in a
reasonably linear fashion
• This situation is sometimes encountered when well-defined
adaptations or enhancements to an existing system must be made
– E.g. An adaptation to billing software that has been mandated because of
introducing GST
• It may also occur in a limited number of new development efforts,
but only when requirements are well defined and reasonably stable
12
 V-model
• Once code has been
generated, the team
moves up the right side
of the V, essentially
performing a series of
tests (quality assurance
actions) that validate
each of the models
created as the team
moves down the left side
13
 V-model
• In reality, there is no
fundamental difference
between the classic life
cycle and the V-model
• The V-model provides a
way of visualizing how
verification and
validation actions are
applied to earlier
engineering work
14
 Problems with Waterfall Model

Real projects rarely follow the sequential flow that the

model proposes
• Although the linear model can accommodate iteration, it does so
indirectly
• As a result, changes can cause confusion as the project team
proceeds
It is often difficult for the customer to state all
requirements explicitly
• The waterfall model requires this and has difficulty accommodating
the natural uncertainty that exists at the beginning of many projects
15
 Problems with Waterfall Model
The customer must have patience
• A working version of the program(s) will not be available until late in the
project time span
• A major blunder, if undetected until the working program is reviewed,
can be disastrous
Leads to blocking states
• Some project team members must wait for other members of the team
to complete dependent tasks
• In fact, the time spent waiting can exceed the time spent on productive
work! The blocking state tends to be more prevalent at the beginning
and end of a linear sequential process
16
 Discussion

Provide three examples of software projects that would

be amenable to the waterfall model. Be specific.

17
 Incremental Process Models
• There are many situations in which initial software requirements
are reasonably well defined, but the overall scope of the
development effort precludes a purely linear process
• In addition, there may be 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
• In such cases, you can choose a process model that is
designed to produce the software in increments

18
Incremental Process Models

19
 Incremental Process Models
• The incremental model
combines the elements of
linear and parallel process
flows discussed earlier
• The incremental model
applies linear sequences in a
staggered fashion as
calendar time progresses
• Each linear sequence
produces deliverable
“increments” of the software

20
 Example

Basic file management, editing, and document production

functions 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

It should be noted that the process flow for any increment can incorporate
the prototyping paradigm discussed in the next subsection 21
 Incremental Process Models
• When an incremental model is used, the first increment is often a core product
• That is, basic requirements are addressed but many supplementary features
(some known, others unknown) remain undelivered
• The core product is used by the customer (or undergoes detailed evaluation)
• 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
• This process is repeated following the delivery of each increment, until the
complete product is produced

22
 Discussion

Provide three examples of software projects that would

be amenable to the incremental model. Be specific.

23
 Summary
• 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.
• Sequential process models, such as the waterfall and V-models, are the oldest
software engineering paradigms.
– They suggest a linear process flow that is often inconsistent with modern realities (e.g.,
continuous change, evolving systems, tight time lines) in the software world
– They do, however, have applicability in situations where requirements are well defined
and stable.
• Incremental process models are iterative in nature and produce working
versions of software quite rapidly
24
 Evolutionary Process Models
• Software, like all complex systems, evolves over a period of time
• Business and product requirements often change as development proceeds, making
a straight line path to an end product unrealistic
• Tight market deadlines make completion of a comprehensive software product
impossible, but a limited version must be introduced to meet competitive or business
pressure
– A set of core product or system requirements is well understood, but the details of product or
system extensions have yet to be defined
• In these and similar situations, you need a process model that has been explicitly
designed to accommodate a product that grows and changes
• Evolutionary models are iterative
– They are characterized in a manner that enables you to develop increasingly more complete
versions of the software
25
Two common evolutionary models

Prototyping Spiral
26
 Prototyping
• 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 that human-machine interaction
should take
• In these, and many other situations, a prototyping
paradigm may offer the best approach
27
 Prototyping
• 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 process models noted earlier
• Regardless of the manner in which it is applied, the
prototyping paradigm assists you and other stakeholders
to better understand what is to be built when
requirements are fuzzy

28
 Prototyping
• The prototyping paradigm begins with
communication
• You meet with other stakeholders to define the
overall objectives for the software, identify whatever
requirements are known, and outline areas where
further definition is mandatory
• A prototyping iteration is planned quickly, and
modeling (in the form of a “quick design”) occurs
• A quick design focuses on a representation of those
aspects of the software that will be visible to end
users (e.g., human interface layout or output display
formats).

29
 Prototyping
• The quick design leads to the construction
of a prototype
• The prototype is deployed and evaluated
by stakeholders, who provide feedback
that is used to further refine requirements
• Iteration occurs as the prototype is tuned
to satisfy the needs of various
stakeholders, while at the same time
enabling you to better understand what
needs to be done.
30
 Prototyping
• Ideally, the prototype serves as a mechanism for identifying
software requirements
• If a working prototype is to be built, you can make use of
existing program fragments or apply tools that enable working
programs to be generated quickly
• Both stakeholders and software engineers like the prototyping
paradigm
• Users get a feel for the actual system, and developers get to
build something immediately.
31
 Prototyping – Issues
Stakeholders see what appears to be a working version of the software,
unaware that the prototype is held together haphazardly, unaware that in
the rush to get it working you haven't considered overall software quality or
long-term maintainability

As a software engineer, you often make implementation compromises in

order to get a prototype working quickly. An inappropriate operating system
or programming language may be used simply because it is available and
known; an inefficient algorithm may be implemented simply to demonstrate
capability

32
 Discussion

Provide three examples of software projects that would

be amenable to the prototyping model. Be specific.

33
 The Spiral Model
• The first circuit around the spiral might result in the development of a product
specification
• Subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software
• Each pass through the planning region results in adjustments to the project
plan
• Cost and schedule are adjusted based on feedback derived from the
customer after delivery
• In addition, the project manager adjusts the planned number of iterations
required to complete the software

34
 The 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
• The spiral model 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 but
incorporates it into an iterative framework that more realistically reflects the real world
• The spiral model demands a direct consideration of technical risks at all stages of the
project and, if properly applied, should reduce risks before they become problematic

35
 Discussion

As you move outward along the spiral process flow, what

can you say about the software that is being developed or
maintained?

36
 Concurrent Models
• The concurrent development model, sometimes
called concurrent engineering, allows a software
team to represent iterative and concurrent elements
of any of the process models described earlier
• For example, early in a project the communication
activity (not shown in the figure) has completed its
first iteration and exists in the awaiting changes
state
• The modeling activity (which existed in the none
state while initial communication was completed) now
makes a transition into the under development state
• If, however, the customer indicates that changes in
requirements must be made, the modeling activity
moves from the under development state into the
awaiting changes state

37
 Concurrent Models
• Concurrent modeling 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 (a major software engineering
action that occurs during the modeling
activity), an inconsistency in the
requirements model is uncovered
• This generates the event analysis model
correction, which will trigger the
requirements analysis action from the
done state into the awaiting changes
state 38
 Concurrent Models
• Concurrent modeling 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
simultaneously with other activities, actions, or tasks
• Events generated at one point in the process network trigger
transitions among the states associated with each activity
39
 Discussion

The concurrent process model defines a set of “states.” Describe

what these states represent in your own words, and then indicate
how they come into play within the concurrent process model

40
 Summary
• 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 adopted to apply across all software
engineering activities—from concept development to long-term system
maintenance
• The concurrent process model allows a software team to represent
iterative and concurrent elements of any process model.
41
The Unified Process

42
 The Unified Process
• An attempt to draw on the best features and characteristics of traditional
software process models, but characterize them in a way that
implements many of the best principles of agile software development
• The Unified Process recognizes the importance of customer
communication and streamlined methods for describing the customer’s
view of a system (the use case)
• It emphasizes the important role of software architecture and “helps the
architect focus on the right goals, such as understandability, reliance to
future changes, and reuse”
• It suggests a process flow that is iterative and incremental, providing the
evolutionary feel that is essential in modern software development
43
 Phases of the Unified Process (UP)
• This figure depicts
the “phases” of the
UP and relates
them to the
generic activities
that have been
discussed earlier

44
 Inception Phase
• The inception phase of the UP encompasses both customer communication
and planning activities
• By collaborating with stakeholders, business requirements for the software
are identified; a rough architecture for the system is proposed; and a plan
for the iterative, incremental nature of the ensuing project is developed
• Fundamental business requirements are described through a set of
preliminary use cases that describe which features and functions each
major class of users desires
• Architecture at this point is nothing more than a tentative outline of major
subsystems and the functions and features that populate them
• Later, the architecture will be refined and expanded into a set of models that
will represent different views of the system. Planning identifies resources,
assesses major risks, defines a schedule, and establishes a basis for the
45
phases that are to be applied as the software increment is developed
 The Elaboration Phase
• The elaboration phase encompasses the communication and modeling activities of
the generic process model
• Elaboration refines and expands the preliminary use cases that were developed as
part of the inception phase and expands the architectural representation to include
five different views of the software—the use case model, the analysis model, the
design model, the implementation model, and the deployment model
• In some cases, elaboration creates an “executable architectural baseline” that
represents a “first cut” executable system
• The architectural baseline demonstrates the viability of the architecture but does not
provide all features and functions required to use the system
• In addition, the plan is carefully reviewed at the culmination of the elaboration phase
to ensure that scope, risks, and delivery dates remain reasonable
• Modifications to the plan are often made at this time
46
 The Construction Phase
• The construction phase of the UP is identical to the construction activity defined for
the generic software process
• Using the architectural model as input, the construction phase develops or acquires
the software components that will make each use case operational for end users
• To accomplish this, analysis and design models that were started during the
elaboration phase are completed to reflect the final version of the software increment
• All necessary and required features and functions for the software increment (i.e., the
release) are then implemented in source code
• As components are being implemented, unit tests are designed and executed for each
• In addition, integration activities (component assembly and integration testing) are
conducted
• Use cases are used to derive a suite of acceptance tests that are executed prior to the
initiation of the next UP phase
47
 The Transition Phase
• The transition phase of the UP encompasses the latter stages of
the generic construction activity and the first part of the generic
deployment (delivery and feedback) activity
• Software is given to end users for beta testing, and user feedback
reports both defects and necessary changes
• In addition, the software team creates the necessary support
information (e.g., user manuals, troubleshooting guides, installation
procedures) that is required for the release
• At the conclusion of the transition phase, the software increment
becomes a usable software release
48
 The Production Phase
• The production phase of the UP coincides with the
deployment activity of the generic process
• During this phase, the ongoing use of the software is
monitored, support for the operating environment
(infrastructure) is provided, and defect reports and
requests for changes are submitted and evaluated

49
 UP – Some notes
• It is likely that at the same time the construction, transition, and production phases are
being conducted, work may have already begun on the next software increment
• This means that the five UP phases do not occur in a sequence, but rather with
staggered concurrency
• A software engineering workflow is distributed across all UP phases
• In the context of UP, a workflow is analogous to a task set
• That is, a workflow identifies the tasks required to accomplish an important software
engineering action and the work products that are produced as a consequence of
successfully completing the tasks
• It should be noted that not every task identified for a UP workflow is conducted for
every software project
• The team adapts the process (actions, tasks, subtasks, and work products) to meet its
needs
50
 Discussion

Is it possible to combine process models?

If so, provide an example

51
 Discussion

What are the advantages and disadvantages of developing

software in which quality is “good enough”? That is, what happens
when we emphasize development speed over product quality?

52
 Summary
• The Unified Process is a “use case driven, architecture-
centric, iterative and incremental” software process
designed as a framework for UML methods and tools

53