CS435: Introduction to Software Engineering

Dr. M. Zhu

 Process Models
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

Software Engineering 9/e

By Ian Sommerville

Chapter 2 1

These slides are designed and adapted from slides provided by Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011 by Ian Sommerville
 Definition of Software
Process
• A framework for the activities, actions, and tasks that
are required to build high-quality software.

• SP defines the approach that is taken as software is

engineered.

• Is not equal to software engineering, which also

encompasses technologies that populate the process–
technical methods and automated tools.
2
A Generic Process Model 3
 As we discussed before, a generic process framework for
software engineering defines five framework activities-
communication, planning, modeling, construction, and
deployment.
 In addition, a set of umbrella activities- project tracking
and control, risk management, quality assurance,
configuration management, technical reviews, and others
are applied throughout the process.
 Next question is: how the framework activities and the
actions and tasks that occur within each activity are
organized with respect to sequence and time? See the
process flow for answer.

A Generic Process Model 4

Process Flow

5
 Linear process flow executes each of the five
activities in sequence.
 An iterative process flow repeats one or more of the
activities before proceeding to the next.
 An evolutionary process flow executes the activities
in a circular manner. Each circuit leads to a more
complete version of the software.
 A parallel process flow executes one or more
activities in parallel with other activities ( modeling
for one aspect of the software in parallel with
construction of another aspect of the software.

Process Flow 6
 Before you can proceed with the process model, a key
question: what actions are appropriate for a
framework activity given the nature of the problem,
the characteristics of the people and the stakeholders?
 A task set defines the actual work to be done to
accomplish the objectives of a software engineering
action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be applied

Identifying a Task Set 7

 For example, a small software project requested by
one person with simple requirements, the
communication activity might encompass little more
than a phone all with the stakeholder. Therefore, the
only necessary action is phone conversation, the work
tasks of this action are:
 1. Make contact with stakeholder via telephone.
 2. Discuss requirements and take notes.
 3. Organize notes into a brief written statement of
requirements.
 4. E-mail to stakeholder for review and approval.

Identifying a Task Set 8

 The task sets for Requirements gathering action for a
simple project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and
functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.

Example of a Task Set

for Elicitation 9
 The task sets for Requirements gathering action for a big project
may include:
1. Make a list of stakeholders for the project.
2. Interview each stakeholders separately to determine overall wants and needs.
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system.

 Both do the same work with different depth and formality. Choose the
task sets that achieve the goal and still maintain quality and agility.
10

Example of a Task Set for Elicitation

 Prescriptive Models
• Originally proposed to bring order to chaos.
• Prescriptive process models advocate an orderly approach to software
engineering. However, will some extent of chaos (less rigid) be beneficial to
bring some creativity?

That leads to a few questions …

• If prescriptive process models strive for structure and order (prescribe a set
of process elements and process flow), 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?
11
 The Waterfall
Model

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)

The classic life cycle suggests a systematic, sequential approach

12
to software development.
 Advantages:
 Organized approach, provides robust separation of phases
 Reflects common engineering practice
 Disadvantages:
 Doesn’t cope well with changes required by the client
 Development teams might wait for each other
 A working version of the product is available only late
 Applicability:
 When requirements are well known and few changes are
likely to be needed
 Can be used also for parts of larger software systems

The Waterfall Model

These slides are designed to accompany Software Engineering:
13
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
 A variation of waterfall model

The V-Model
depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.

14
The Incremental
Model

15
 The Incremental Model
• When initial requirements are reasonably well
defined, but the overall scope of the development
effort precludes (prevent from happening) a purely
linear process. A compelling need to expand a limited
set of new functions to a later system release.
• It combines elements of linear and parallel process
flows. Each linear sequence produces deliverable
increments of the software.
• The first increment is often a core product with
many supplementary features. Users use it and
evaluate it with more modifications to better meet the
needs. 16
• Main characteristics:
• Hybrid model that combines elements of the waterfall and
evolutionary paradigms
• The specification, design, and implementation phases are broken in
smaller increments
• Advantages:
• Provides better support for process iteration
• Reduces rework in the software construction process
• Some decisions on requirements may be delayed
• Allows early delivery of parts of the system
• Supports easier integration of sub-systems
• Lower risk of project failure
• Delivery priorities can be more easily set

The Incremental Model 17

 Evolutionary Models
• Software system evolves over time as requirements often change
as development proceeds. Thus, a straight line to a complete end
product is not possible. However, a limited version must be
delivered to meet competitive pressure.
• Usually a set of core product or system requirements is well
understood, but the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more
complete version of the software.
• Two types are introduced, namely Prototyping and Spiral models.18
 Evolutionary Models: Prototyping
• When to use:
• Customer defines a set of general objectives
but does not identify detailed requirements for
functions and features.
• Or Developer may be unsure of the efficiency
of an algorithm, the form that human computer
interaction should take.
19
Evolutionary Models: Prototyping

Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

20
 Evolutionary Models: Prototyping
• What step:
• Begins with communication by meeting with stakeholders to
define the objective, identify whatever requirements are known,
outline areas where further definition is mandatory.
• A quick plan for prototyping and modeling (quick design)
occur. Quick design focuses on a representation of those
aspects the software that will be visible to end users. ( interface
and output).
• Design leads to the construction of a prototype which will be
deployed and evaluated. Stakeholder’s comments will be used to
refine requirements. 21
 Evolutionary Models: Prototyping

• Both stakeholders and software engineers like the

prototyping paradigm. Users get a feel for the
actual system, and developers get to build
something immediately. However, engineers may
make compromises in order to get a prototype
working quickly. The less-than-ideal choice may
be adopted forever after you get used to it.
22
 Evolutionary Models: The Spiral
• It couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model and
is a risk-driven process model generator that is used to guide
multi-stakeholder concurrent engineering of software
intensive systems.
• Two main distinguishing features: one is cyclic approach
for incrementally growing a system’s degree of definition
and implementation while decreasing its degree of risk. The
other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually
satisfactory system solutions. 23
Evolutionary Models: The Spiral

24
 Evolutionary Models: The Spiral
•A series of evolutionary releases are delivered. During the early
iterations, the release might be a model or prototype. During later
iterations, increasingly more complete version of the engineered
system are produced.
•The first circuit in the clockwise direction might result in the
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 results in
adjustments to the project plan. Cost and schedule are adjusted
based on feedback. Also, the number of iterations will be adjusted
25
by project manager.
 Evolutionary Models: The Spiral

•Good to develop large-scale system as software

evolves as the process progresses and risk should
be understood and properly reacted to. Prototyping
is used to reduce risk.
•However, it may be difficult to convince
customers that it is controllable as it demands
considerable risk assessment expertise. 26
 Concurrent Model

• Allow a software team to represent iterative and

concurrent elements of any of the process
models. For example, the modeling activity
defined for the spiral model is accomplished by
invoking one or more of the following actions:
prototyping, analysis and design.
27
Concurrent Model

28
 Three Concerns on Evolutionary
Processes
• First concern is that prototyping poses a problem to project planning because of
the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the development
over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product when the opportunity niche has
disappeared.
29
 Concurrent Model
• The Figure shows modeling may be in any one of
the states at any given time. For example,
communication activity has completed its first
iteration and in the awaiting changes state. The
modeling activity was in inactive state, now
makes a transition into the under development
state. If customer indicates changes in
requirements, the modeling activity moves from
the under development state into the awaiting
30
changes state.
 Concurrent Model
• 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 trigger transitions among the states.
31
 Still Other Process
Models
• Component based development—the process to apply when
reuse is a development objective ( like spiral model)
• Formal methods—emphasizes the mathematical specification
of requirements ( easy to discover and eliminate ambiguity,
incompleteness and inconsistency)
• Aspect Oriented software development (AOSD)—provides a
process and methodological approach for defining, specifying,
designing, and constructing aspects
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned
with the Unified Modeling Language (UML) to model and
32
develop object-oriented system iteratively and incrementally.
The Unified Process (UP)
elaboration

inception

33
• Attempt to draws 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.
• It recognizes the importance of customer communication
and methods for describing the customer’s view of a
system.
• It also emphasizes the important role of software
architecture.
• The Unified Process is a framework for object-oriented
software engineering.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
34
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Inception phase:
• 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 ensuing project is
developed.
• Fundamental business requirements are described
through preliminary use cases that describe which
features and functions each major classes of user desires.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
35
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Inception phase:
• Architecture at this point is tentative outline of major
subsystems and the functions and features that populate
them. Later, the architecture will be refined and
expanded.
• Planning identifies resources, assesses major risks,
defines a schedule, and establishes a basis for the phases
that are to be applied as the software increment is
developed.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
36
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Elaboration phase:
• Encompasses the communication and modeling activities
of the generic process model.
• It refines and expands the preliminary use cases that were
developed as part of the inception phase.
• It expands the architectural representation to include five
different views of the software – the use case, the
requirement model, the design model, the implementation
model and the deployment model.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
37
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Elaboration phase:
• In some cases elaboration creates first executable system
to demonstrates the viability of the architecture.
• The plan is reviewed and if needed modified at the last
stage of Elaboration phase to ensure that scope, risks and
delivery dates remain reasonable.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
38
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Construction phase:
• Identical to the construction phase of the generic software
process
• Using architectural model as input, the construction
phase develops or acquires the software components that
will make each use case operational for the end users.
• Requirement and design models that were started during
the elaboration phase are completed to reflect the final
version of the software increment and then implemented
in source code.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
39
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Construction phase:
• Unit test are designed and executed for each components.
• 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 nex phase.

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
40
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Production phase:
• Coincides with the deployment activity of the generic
process
• The ongoing use of the software is monitored, support for
the operating environment (infrastructure) is provided
and defect reports and request are submitted and
evaluated

The Unified Process (UP)

These slides are designed to accompany Software Engineering:
41
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Transition phase:
• Software is given to end users for beta testing and user
feedback reports both defects and necessary changes.
• The Software team creates the necessary support
information such as user manuals, troubleshooting
guides, installation procedures etch
• Towards the end of transition phase the software
increment becomes a usable software release.

The Unified Process (UP)

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

43
UP Work Products

44
 Personal Software Process (PSP)
• Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule is
created.
• High-level design. External specifications for each component to be constructed
are developed and a component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are applied
to uncover errors in the design. Metrics are maintained for all important tasks
and work results.
• Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all
important tasks and work results.
• Postmortem. Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness of the
process is determined. Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.
45
 Team Software Process (TSP)
 Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans. These can
be pure software teams or integrated product teams (IPT) of
three to about 20 engineers.
 Show managers how to coach and motivate their teams and
how to help them sustain peak performance.
 Accelerate software process improvement by making CMM
Level 5 behavior.
 The Capability Maturity Model (CMM), a measure of the effectiveness of
a software process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity
organizations.
 Facilitate university teaching of industrial-grade team skills.
46
• A process pattern
• describes a process-related problem that is encountered
during software engineering work,
• identifies the environment in which the problem has been
encountered, and
• suggests one or more proven solutions to the problem.
• Stated in more general terms, a process pattern provides you
with a template [Amb98]—a consistent method for describing
problem solutions within the context of the software process.
( defined at different levels of abstraction)
1. Problems and solutions associated with a complete process
model (e.g. prototyping).
2. Problems and solutions associated with a framework activity
(e.g. planning) or
3. an action with a framework activity (e.g. project estimating).

Process Patterns 47
• Stage patterns—defines a problem associated with a
framework activity for the process. It includes multiple
task patterns as well. For example,
EstablishingCommunication would incorporate the task
pattern RequirementsGathering and others.
• Task patterns—defines a problem associated with a
software engineering action or work task and relevant to
successful software engineering practice
• Phase patterns—define the sequence of framework
activities that occur with the process, even when the
overall flow of activities is iterative in nature. Example
includes SprialModel or Prototyping.

Process Pattern Types 48

 An Example of Process Pattern

• Describes an approach that may be applicable when stakeholders have

a general idea of what must be done but are unsure of specific software
requirements.
• Pattern name. RequiremetnsUnclear
• Intent. This pattern describes an approach for building a model that
can be assessed iteratively by stakeholders in an effort to identify or
solidify software requirements.
• Type. Phase pattern
• Initial context. Conditions must be met (1) stakeholders have been
identified; (2) a mode of communication between stakeholders and
the software team has been established; (3) the overriding software
problem to be solved has been identified by stakeholders ; (4) an
initial understanding of project scope, basic business requirements
and project constraints has been developed.
49
 An Example of Process Pattern

•Problem. Requirements are hazy or nonexistent. stakeholders are

unsure of what they want.
•Solution. A description of the prototyping process would be
presented here.
•Resulting context. A software prototype that identifies basic
requirements. (e.g. modes of interaction, computational features,
processing functions) is approved by stakeholders. Following this, 1.
This prototype may evolve through a series of increments to become
the production software or 2. the prototype may be discarded.
•Related patterns. CustomerCommunication, IterativeDesign,
IterativeDevelopment, CustomerAssessment, RequirementExtraction.

50
 Process Assessment and Improvement
SP cannot guarantee that software will be delivered on time, meet the needs, or has the desired
technical characteristics. However, the process can be assessed to ensure that it meets a set of
basic process criteria that have been shown to be essential for a successful software engineering.

•Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides a five
step process assessment model that incorporates five phases: initiating, diagnosing, establishing,
acting and learning.
•CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a
diagnostic technique for assessing the relative maturity of a software organization; uses the
SEI CMM as the basis for the assessment [Dun01]
•SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for software
process assessment. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process. [ISO08]

•ISO 9001:2000 for Software—a generic standard that applies to any organization that
wants to improve the overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and companies.
[Ant06]
51
• The Software Engineering Institute (SEI) has developed
model to measure organization different level of process
capability and maturity known as Capability Maturity
Model (CMM) as a complete Software Process
Improvement (SPI) framework in 1990.
• Today, it has evolved into the Capability Maturity Model
Integration (CMMI) – a comprehensive process meta-
model that is predicated on a set of system and software
engineering capabilities that should be present as
organizations reach different levels of process capability
and maturity.

Capability Maturity 52
Model (CMM)
• The CMM defines each process area in terms of “specific
goals” and the “specific practices” required to achieve
these goals.
• Specific goals establish the characteristics that must exist
if the activities implied by a process area are to be
effective.
• Specific practices refine a goal into a set of process-
related activities.
• CMM specifies an increasing series of levels that a
software development organization can be at. The higher
the level, the better the software development process is.

Capability Maturity 53
Model (CMM)
The term "maturity" relates to the degree of formality and optimization
of processes, from ad hoc practices, to formally defined steps, to
managed result metrics, to active optimization of the processes.
Level 0 (Incomplete) –
• Process are not perform or not achieve all the goals and objectives defined
by the CMMI for Level I capability.
Level 1 (Performed / Initial) – Ad hoc and chaotic, few processes
defined and individual efforts made.
Level 2 (Managed / Repeatable) –
• All level 1 criteria have been satisfied
• In addition to Level I;
• People doing work have access to adequate resources to get job done,
• Stakeholders are actively involved,
• Work tasks and products are monitored, controlled, reviewed, and evaluated for
conformance to process description.

Capability Maturity 54
Model (CMM)
Level 3 (Defined) –
• All level 2 criteria have been achieved.
• In addition;
• The process is standardized, documented and followed. All the projects
use documented and approved version of software process which is
useful in developing and supporting software.
Level 4 (Quantitatively Managed) -
• All level 3 criteria have been satisfied.
• Software process and products are quantitatively understood
• Controlled using detailed measures and assessment.
Level 5 (Optimized) –
• Continuous process improvement is enabled by quantitative
feedback from the process and testing innovative ideas.

Capability Maturity 55
Model (CMM)
Capability Maturity 56
Model (CMM)