Chapter 2

Process Models

Software Engineering: A Practitioner’s Approach, 7/e

by Roger S. Pressman
Prescriptive Process Models

• Traditional process models

• Specialized process models
• Unified process

(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

 Traditional Process Models
• Defines a distinct set of activities, actions, tasks,
milestones, and work products that are required to
engineer high-quality software

• The activities can be

– linear,
– incremental,
– evolutionary
 Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
4
 Waterfall Model
(Description)
• Oldest software lifecycle model & best understood by upper
management

• Used when requirements are well understood and risk is low

• Work flow is in a linear fashion (i.e., sequential)

• Used often with well-defined adaptations or enhancements

to current software

5
 Waterfall Model
(Problems)
• Doesn't support iteration, so changes can cause
confusion

• Difficult for customers to state all requirements

explicitly and up front

• Requires customer patience because a working

version of the program doesn't occur until the final
phase

6
 Incremental Model
(Diagram)
Increment #1
Communication
Planning
Modeling
Construction
Deployment

Increment #2
Communication
Planning
Modeling
Construction
Deployment

Increment #3

Communication
Planning
Modeling
Construction
Deployment

7
 Incremental Model
(Description)
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow is in a linear (i.e., sequential) fashion within an increment
and is staggered between increments
• Iterative in nature; focuses on an operational product with each
increment
• Provides a needed set of functionality sooner while delivering optional
components later
• Useful also when staffing is too short for a full-scale development

8
 Prototyping Model
(Diagram)
Quick
Planning

Communication
Start

Modeling
Quick Design
Deployment,
Delivery,
and Feedback

Construction
Of Prototype
9
 Prototyping Model
(Description)
• Follows an evolutionary and iterative approach
• Used when requirements are not well understood
• Serves as a mechanism for identifying software requirements
• Focuses on those aspects of the software that are visible to the
customer/user
• Feedback is used to refine the prototype

10
 Prototyping Model
(Potential Problems)
• The customer sees a "working version" of the software, wants to
stop all development and then buy the prototype after a "few
fixes" are made

• Developers often make implementation compromises to get the

software running quickly
– (e.g., language choice, user interface, operating system choice, inefficient
algorithms)

11
 Spiral Model
(Diagram)
Planning

Communication

Start Modeling

Start

Deployment Construction

12
 Spiral Model
(Description)
• Follows an evolutionary approach
• Used when requirements are not well understood and risks are high
• Inner spirals focus on identifying software requirements and project
risks; may also incorporate prototyping
• Outer spirals take on a classical waterfall approach after requirements
have been defined, but permit iterative growth of the software
• Operates as a risk-driven model…a go/no-go decision occurs after each
complete spiral in order to react to risk determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software development

13
 General Weaknesses of
Evolutionary Process Models
1) Prototyping poses a problem to project planning because of the uncertain
number of iterations required to construct the product

2) Evolutionary software processes do not establish the maximum speed of

the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected

3) Software processes should focus first on flexibility and extensibility, and

second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could
result in late delivery
14
Specialized Process Models
Component-based Development Model
• Consists of the following process steps
– Available component-based products are researched and
evaluated for the application domain in question
– Component integration issues are considered
– A software architecture is designed to accommodate the
components
– Components are integrated into the architecture
– Comprehensive testing is conducted to ensure proper
functionality

• Relies on a robust component library

• Capitalizes on software reuse, which leads to documented

savings in project cost and time
16
 usman
A B C
X(g,h,I) Y() Z()
{ { {

------ ----- ----

} }
}
Changed by C E() D()
Changed by B { {
X(g,h,I)
X(g,h,i)
} ---
Y()

SOFTWARE ENGINEERING APPLICATION

17
DEVELOPMENT---- CHAPTER 2
 Formal Methods Model
(Description)
• Encompasses a set of activities that leads to formal
mathematical specification of computer software
• Enables a software engineer to specify, develop, and verify a
computer-based system by applying a rigorous, mathematical
notation
• Ambiguity, incompleteness, and inconsistency can be discovered
and corrected more easily through mathematical analysis
• Offers the promise of defect-free software
• Used often when building safety-critical systems

18
 Formal Methods Model
(Challenges)
• Development of formal methods is currently quite time-
consuming and expensive

• Because few software developers have the necessary

background to apply formal methods, extensive training is
required

• It is difficult to use the models as a communication mechanism

for technically unsophisticated customers

19
The Unified Process
 Background
• They eventually worked together on a unified method, called the Unified
Modelling Language (UML)
– UML is a robust notation for the modelling and development of object-
oriented systems
– UML became an industry standard in 1997
– However, UML does not provide the process framework, only the necessary
technology for object-oriented development

• Unified process developed which is a framework for object-oriented software

engineering using UML
– Draws on the best features and characteristics of conventional software
process models
– Emphasizes the important role of software architecture
– Consists of a process flow that is iterative and incremental, thereby
providing an evolutionary feel

21
 Background (continued)
• Consists of 5 phases:
1. inception,
2. elaboration,
3. construction,
4. transition,
5. production

22
Phases of the Unified Process
Inception Elaboration

planning

modeling
communication

construction
Construction

deployment

Production Transition
23
 (1) - Inception Phase
• Encompasses both customer communication and planning
activities of the generic process

• Business requirements for the software are identified

• A rough architecture for the system is proposed

• A plan is created for an incremental, iterative development

• Fundamental business requirements are described through

preliminary use cases
– A use case describes a sequence of actions that are performed by a user

24
 (2) - Elaboration Phase
• Encompasses both the planning and modelling activities of the generic
process
• Refines and expands the preliminary use cases
• Expands the architectural representation to include five views
– Use-case model
– Analysis model
– Design model
– Implementation model
– Deployment model
• Often results in an executable architectural baseline that represents a
first cut executable system
• The baseline demonstrates the viability of the architecture but does not
provide all features and functions required to use the system

25
 (3) - Construction Phase
• Encompasses the construction activity of the generic process

• Uses the architectural model from the elaboration phase as input

• Develops or acquires the software components that make each use-case

operational

• Analysis and design models from the previous phase are completed to reflect
the final version of the increment

• Use cases are used to derive a set of acceptance tests that are executed prior
to the next phase

26
 (4) - Transition Phase
• Encompasses the last part of the construction activity and the first
part of the deployment activity of the generic process

• Software is given to end users for beta testing and user feedback
reports on defects and necessary changes

• The software teams create necessary support documentation

(user manuals, trouble-shooting guides, installation procedures)

• At the conclusion of this phase, the software increment becomes a

usable software release
27
 (5) - Production Phase
• Encompasses the last part of the deployment activity of the
generic process

• On-going use of the software is monitored

• Support for the operating environment (infrastructure) is provided

• Defect reports and requests for changes are submitted and

evaluated

28
 Unified Process Work Products
• Work products are produced in each of the first four phases of the
unified process

• In this course, we will concentrate on the analysis model and the

design model work products

• Analysis model includes

– Scenario-based model, class-based model, and behavioural model

• Design model includes

– Component-level design, interface design, architectural design,
and data/class design

29 
SOFTWARE ENGINEERING APPLICATION
30
DEVELOPMENT---- CHAPTER 2
Agile Process Models

SOFTWARE ENGINEERING APPLICATION

31
DEVELOPMENT---- CHAPTER 2
 Agile Process Models

– The prescriptive process models stress detailed definition, identification, and application
of process activates and tasks. Intent is to improve system quality, make projects more
manageable, make delivery dates and costs more predictable, and guide teams of
software engineers as they perform the work required to build a system.
– Unfortunately, there have been times when these objectives were not achieved. If
prescriptive models are applied strictly and without adaptation, they can increase the
level of organization.

– Agile process models emphasize project “agility (alertness)” and follow a set of
principles that lead to a more informal approach to software process. It emphasizes
maneuverability and adaptability. It is particularly useful when Web applications are
engineered.

SOFTWARE ENGINEERING APPLICATION

32
DEVELOPMENT---- CHAPTER 2
 The Essence of Practice
• How does the practice of software engineering fit in the process
activities mentioned above? Namely,
– communication,
– planning,
– modeling,
– construction
– deployment.
• the essence of problem solving is outlined in 4 points:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).
SOFTWARE ENGINEERING APPLICATION
33
DEVELOPMENT---- CHAPTER 2
 Understand the Problem
• Who has a stake in the solution to the problem? That is, who are
the stakeholders?

• What are the unknowns? What data, functions, and features are
required to properly solve the problem?

• Can the problem be classified? Is it possible to represent smaller

problems that may be easier to understand?

• Can the problem be represented graphically? Can an analysis

model be created?
SOFTWARE ENGINEERING APPLICATION
34
DEVELOPMENT---- CHAPTER 2
 Plan the Solution
• Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the solution
reusable?
• Can sub-problems be defined? If so, are solutions readily apparent for
the sub-problems?
• Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?

SOFTWARE ENGINEERING APPLICATION

35
DEVELOPMENT---- CHAPTER 2
 Carry Out the Plan
• Does the solutions conform to the plan? Is source code
traceable to the design model?

• Is each component part of the solution provably correct?

Has the design and code been reviewed, or better,
have correctness proofs been applied to algorithm?

SOFTWARE ENGINEERING APPLICATION

36
DEVELOPMENT---- CHAPTER 2
 Examine the Result
• Is it possible to test each component part of the
solution? Has a reasonable testing strategy been
implemented?

• Does the solution produce results that conform to the

data, functions, and features that are required? Has
the software been validated against all
stakeholder requirements?

SOFTWARE ENGINEERING APPLICATION

37
DEVELOPMENT---- CHAPTER 2
 Software Myths Examples
• Myth 1: Once we write the program and get it to work, our job is done.
• Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to
80% of all efforts are spent after software is delivered to the customer for the first time.

• Myth 2: Until I get the program running, I have no way of assessing its quality.
• Reality: technical review are a quality filter that can be used to find certain classes of
software defects from the inception of a project.

• Myth 3: software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.
• Reality: it is not about creating documents. It is about creating a quality product. Better
quality leads to a reduced rework. Reduced work results in faster delivery times.

• Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and
methods foster poor management and technical practices, even when reality dictates a
better approach.

SOFTWARE ENGINEERING APPLICATION

38
DEVELOPMENT---- CHAPTER 2
 End
Thank you

SOFTWARE ENGINEERING APPLICATION

39
DEVELOPMENT---- CHAPTER 2