CMPC-204: Software Engineering

 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

Lecture 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
 Social Learning
Process
• Software is embodied knowledge that is initially dispersed,
tacit and incomplete.

• In order to convert knowledge into software, dialogues are

needed between users and designers, between designers and
tools to bring knowledge into software.

• Software development is essentially an iterative social

learning process, and the outcome is “software capital”.
2
 What: Go through a series of predictable steps--- a road map that helps you
create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People adapt the
process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that can if left
uncontrolled, become quite chaotic. However, modern software engineering
approaches must be agile and demand ONLY those activities, controls and
work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that you
are building. One process might be good for aircraft avionic system, while an
entirely different process would be used for website creation.
 How to ensure right: A number of software process assessment mechanisms

What / who / why is

that enable us to determine the maturity of the software process. However, the
quality, timeliness and long-term viability of the software are the best
indicators of the efficacy of the process you use.

Process Models?
SLIDES SA rkrni ha 3
 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.
4
A Generic Process
Model 5
 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
A Generic Process
activity are organized with respect to sequence
and time? See the process flow for answer.
Model from sliseeeee 6
Process Flow

7
 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 8
 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
Identifying a Task
engineering action.
 A list of the task to be accomplished

Set
 A list of the work products to be produced
 A list of the quality assurance filters to be applied

Slisessssssssssssss
ssssssssss 9
 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.

Identifying a Task
 3. Organize notes into a brief written statement of
requirements.

SetSliesssssssssss
 4. E-mail to stakeholder for review and approval.

sssssssssssss 10
 The tasks for gathering requirements in 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

Example of a Task
and functions required.
4. Discuss requirements and build a final list.

Set for
5. Prioritize requirements.
6. Note areas of uncertainty.

Elicitationslisessss
s 11
 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.

Example of a Task Set for 12

Elicitationslidessssssssssss
• 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

Process
activity (e.g. planning) or
3. an action with a framework activity (e.g. project
estimating).

Patternsslidesssss 13
• 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.
Process Pattern
Example includes SprialModel or Prototyping.

Typesslidesssss 14
 An Example of Process Pattern
sliseesssssssssssssssssssssssssssss
ssssssssssssssssssssss
• 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.
• 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. (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.
15
• Related patterns. CustomerCommunication, IterativeDesign,
IterativeDevelopment, CustomerAssessment, RequirementExtraction.
 Process Assessment and
Improvement
SP cannot guarantee that software will be delivered on time, meet the needs, or has the desired
technical characteristics. The process can be evaluated to make sure it meets key criteria that
are proven to be important for 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]
16
 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?
17
 The
Waterfall
Model
When work flow from communication through deployment in a
reasonably linear fashion.

It is also called as classic life cycle, as it suggest a systematic

sequential approach that work in a linear fashion from customer
specification of requirements to complete software. 18
• This model is simple and easy to understand and use.
• It is easy to manage due to the rigidity of the model –
each phase has specific deliverables and a review
process.
• In this model phases are processed and completed one at
a time. Phases do not overlap.
• Waterfall model works well for smaller projects where
requirements are very well understood

Advantages of
Waterfall Model
These slides are designed to accompany Software Engineering:
19
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• The main drawback of the waterfall model is the difficulty of accommodating change after the
process is underway.
• One phase has to be complete before moving onto the next phase
• Inflexible partitioning of the project into distinct stages makes it difficult to respond to
changing customer requirements. Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly limited during the design process.
• Only few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites.

Drawbacks of
Waterfall Model
These slides are designed to accompany Software Engineering:
20
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-thought out in the concept stage.
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of

Drawbacks of
changing.

Waterfall Model
slidessssssss
These slides are designed to accompany Software Engineering:
21
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
 • This model is used only when the requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.
• Once the product is developed and if any failure occurs then the cost
of fixing such issues are very high, because we need to update
everywhere from document till the logic.

When to use Waterfall

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

23
• Left-Side of V-Model:
Basic requirement problems are refined into more detailed and technical
representations of problem and its solution.
• Right-Side of V-Model:
Performs a series of test that validate each of the models created as team move down
left side.

• In reality there is no fundamental difference between classic life cycle and V-Model
• V-Model visualize how verification and validating actions are applied to engineering
work.

•Frm slidesss
24
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
• Validation is the process of checking whether the
specification captures the customer's needs (doing the
right thing )
• While verification is the process of checking that the
software meets the specification (doing the thing right)

Verification vs
Validation
These slides are designed to accompany Software Engineering:
25
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
The
Incremental
Model

26
 The Incremental
ModelSlideee
• Incremental model combines elements of both linear and
parallel process flow.
• It is used to provide limited set of software functionality
to user quickly and than refine functionality in later
release.
• The product generated in first increment is called core
product.
• Basic requirements are addressed but many
supplementary feature (both knowns and unknowns)
remain undelivered.
• The core product is used by customer for evaluation. 27
 The Incremental Model
sliee
• The evaluation plan developed by customer is used for
next increment.
• Plan addressed refined in existing product and delivering
new features and functionalities.
• Early increments are stripped-down versions of final
product.
• Versions provide capability to serve the user and platform
for evaluation.
28
 Advantages of the
Incremental
Modelslideee
• Lack of staffing for complete implementation by
established business deadline.
• Additional staff maybe hired for next increment if
required.
• It manages the technical risks by planning e.g. hardware
maintenance.
• Generates working software quickly and early during the
software life cycle.
• This model is more flexible – less costly to change scope
and requirements.
29
 Advantages of the
Incremental Model
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified
and handled during it’d iteration.

30
 Drawbacks of the
Incremental Model
• Needs good planning and design.
• Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally.
• Total cost is higher than waterfall.

31
 When to use the
Incremental Model
• This model can be used when the requirements of the
complete system are clearly defined and understood.
• Major requirements must be defined; however, some
details can evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.
32
 Evolutionary Models slissss
• 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.33
Evolutionary Models:
Prototyping
Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

34
Evolutionary slissssModels:
Prototyping
• It is used as a stand-alone model, as it can be implemented in context of any process
model.
• It assist in better understanding fuzzy and ambiguous requirements.
• Prototyping iterations are planned quickly.
• If prototyping is to be built quickly than existing program fragments and tools can be
used.
• It serves as a first-system or throw away.
• Some prototypes are “throw away” other are “evolutionary” that prototype evolve into
actual systems.

35
Advantages of Prototyping
Modelsliii
• Users are actively involved in the development
• Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
Requirements validation, Quick implementation of, incomplete, but
functional, application.

36
Drawbacks of Prototyping
Modelsliii
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
• Incomplete application may cause application not to be used as the
full system was designed
Incomplete or inadequate problem analysis.

37
 When to use Prototyping
Model sliiiiiii
• Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model. It might take a while for a system to be built that
allows ease of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.

38
Evolutionary Models: The
Spiral RisK
Maimn point

39
 Evolutionary Models: Spiral
Model copyy
• Spiral model is an evolutionary software process model that couple the iterative nature of prototyping with
the controlled and systematic aspects of waterfall model.
• Spiral in a clockwise direction, Beginning at the center.
• Combination of work products and conditions that are attained along the path of spiral are noted for each
Evolutionary pass.
• During early iteration the release might be model or prototype.
• During later iteration more complex versions of software are produced.
• Cost and schedule are adjusted based on feedback from customer after delivery.
• Spiral Model is not a “Panacea”
• Difficult to convince customer that approach is controllable.
• It demand considerable risk assessment and expertise
40
• If major risk is not uncovered and managed problem will occur.
Advantages of Spiral Model
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

41
Drawbacks of Spiral Model
• Demand direct consideration of technical risk at each stage
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

42
When to use Spiral Model
• Large-scale systems and software's
• When costs and risk evaluation is important at each evolutionary level
• For medium to high-risk projects
• Prototyping as a risk reduction mechanism
• Long-term project commitment unwise because of potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)

43
Evolutionary Models:
Concurrent Model

44
Evolutionary Models:
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.
• 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 changes
state.
• 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 among45the
states.
Advantages of Concurrent
Model
• This model is applicable to all types of software development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a project

46
Drawbacks of Concurrent
Model
• It needs better communication between the team members, which
may not be achieved all the time.
• It requires to remember the status of the different activities

47
 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.
48
 Still Other
Process
reuse Models
• Component based development—the process to apply when
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 49
develop object-oriented system iteratively and incrementally.
The Unified Process
(UP)
elaboration

inception

50
UP
Phases

51
UP Work
Products

52
 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.

53
 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 normal and expected.
 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.
54