SWE 313

Software Process and Modeling

Chapter 9
Software Process
Dr. Mohammed F. Alhamid • SWE 313 • Spring 2017

This is the instructor’s notes. Students has to read the required textbook to understand the covered concepts.

1
 Outline

• What is Software Process Model?

• Examples of Process Models

 Outline

• What is Software Process Model?

• Examples of Process Models

 Process

A process defines Who is doing

What, When, and How, in order to
reach a certain goal.

New or changed Software Engineering New or changed

requirements Process system
Software Process Models

A software process model is a

standardised format for
• planning
• organising, and
• running
a development project.

5
6

Software Process Models

Process models
• Approaches for organizing a project into activities

• Help the project manager and team decide:

– What work should be done;
– In what sequence to perform the work.

• Aids to thinking, NOT rigid prescriptions of the way to

do things

• Each project has its own unique plan

6
Project Visibility

Unlike other engineers (e.g. civil, electronic,

chemical,..etc) software engineers do not produce
anything physical.

It is inherently difficult to monitor an SE

project due to lack of visibility

7
8
Project Visibility

This means that SE projects must produce

additional deliverables (artifacts)

which are visible, such as:

• Design documents/ prototypes
• Reports
• Project/status meetings
• Client surveys (e.g. satisfaction level)

8
9
What is a Software Process Model?

Definition

A (software/system) process model is a

description of the sequence of activities
carried out in an SE project, and the
relative order of these activities.

9
10
What is a Software Process Model?

• It provides a fixed generic framework that can be

tailored to a specific project.
• Project specific parameters will include:
– Size, (person-years)
– Budget,
– Duration

project plan =
process model + project parameters

10
Hundreds of different models exist and are
used, but many are minor variations on a
small number of basic models.

In this section we:

• survey the important basic models, and

• consider how to choose between them.

11
12

There are hundreds of different process models

to choose from, e.g:
• waterfall,
• code-and-fix,
• spiral,
• rapid prototyping,
• agile methods, extreme programming (XP)
• unified process (UP),
• COTS,..etc

12
13
Choosing a Software Process Model

It depends on the project circumstances and

parameters. By changing the process model, we
can improve and/or tradeoff:

• Development speed (time to market)

• Product quality
• Project visibility
• Administrative overhead
• Risk exposure
• Customer relations,..etc.

13
14
Software Process Model Duration

Normally, a process model covers the entire

lifetime of a product.

From birth of a commercial idea

to final de-installation of last release
i.e. the three main phases:
• design,
• build,
• maintain. (50% of IT activity goes here!)

14
 Outline

• What is Software Process Model?

• Examples of Process Models

16

The opportunistic approach

Organizations that don’t follow good software

engineering practices often end-up following an
opportunistic approach,
developers keep on modifying the software until
they or their users are satisfied.

Poor model!
16
17

The Waterfall Model

17
The Waterfall Model

• The classic process model

widely known, understood and used.

• The common sense approach

R.W. Royce, Managing the Development of Large
Software Systems: Concepts and Techniques, Proc. IEEE
Westcon, IEEE Press, 1970.

18
19

The Waterfall Model

• The model suggests that software engineers should

work in a series of stages (linear/sequential)
– Figure out requirements before doing design
– Do design before implementation

• Projects tend to fail because you don’t realize the

requirements have weaknesses until too late to
make easy changes

19
20
The Waterfall Workflow

User Requirements User Requirements

phase output Document

Software Requirements Software Requirements

Document

Architecture Design Architectural Design

Document

Detailed design & Coding

”Swimming Detailed Design
upstream” & Code
Testing

Delivery
20

Time
21
Advantages

1. Easy to understand and implement

2. Widely used and known (in theory!)
3. Fits other engineering process models:
civil, mechanical,..etc.
4. Reinforces good habits:
define-before-design, design-before-code
5. Identifies deliverables and milestones
6. Document-driven: people leave, documents don’t.
Published documentation standards: SRD,
URD,..etc.
7. Works well on large/mature products and weak
teams
21
22
Disadvantages

1. Doesn’t reflect iterative nature of exploratory

development.
2. Sometimes unrealistic to expect accurate
requirements early in a project
3. Software is delivered late, delays discovery of
serious errors.
4. No inherent risk management
5. Difficult and expensive to change decisions,
”swimming upstream”.
6. Significant administrative overhead, costly for
small teams and projects.
22
23
Code-and-Fix

This model starts with:

an informal general product idea
and just develops code until,
a product is ”ready”
(or money or time runs out)

• Work is in random order

• Corresponds with no plan! (Hacking)

23
24
Advantages

1. No administrative overhead
2. Signs of progress (code) early
3. Low expertise, anyone can use it!
4. Useful for small “proof-of-concept” projects,
e.g. as part of risk reduction.

24
25
Disadvantages

1. Dangerous!
• No visibility/control
• No resource planning
• No deadlines
• Mistakes hard to detect/correct
2. Impossible for large projects,
communication breakdown, chaos.

25
26
Evolutionary Development Types

Type 1: Exploratory Development: customer

assisted development that evolves a product
from ignorance to insight, starting from core, well
understood components (e.g. GUI?)

Type 2: Throwaway Prototyping: customer

assisted development that evolves
requirements from ignorance to insight by
means of lightweight disposable prototypes.

26
27
Type 1 (Exploratory Development):
The spiral model

• It explicitly embraces prototyping and an

iterative approach to software development.
– Start by developing a small prototype.
– In each iteration, perform further requirements,
design, implementation and review.
– The first thing to do before embarking on each
new iteration is risk analysis.
– Maintenance/evolution is on-going iterations
around the spiral

27
28

In 1988 Boehm developed the spiral model as

an iterative model which includes:
risk analysis and risk management.

Key idea: on each iteration identify and solve

the sub-problems with the highest risk.

28
29

The spiral model

29
30
Advantages

1. Realism:
it accurately reflects the iterative nature of software
development on projects with unclear requirements
2. Flexible:
incoporates the advantages of the waterfall and
evolutionary methods
3. Comprehensive model that decreases risk
4. Good project visibility

30
31
Disadvantages

1. Needs technical expertise in risk analysis and risk

management to work well.
2. Model is poorly understood by non-technical
management, hence not so widely used
3. High administrative overhead. Complicated
model, needs competent professional
management.

31
32 Type 2 (Throwaway Prototyping):
Rapid Prototyping

Key idea: Customers are non-technical and

usually don’t know what they want.

Rapid prototyping emphasises requirements

analysis and validation, also called:
• customer oriented development,
• evolutionary prototyping

32
The Rapid Prototype Workflow

Requirements Capture

Iterate
Quick Design

Build Prototype

Customer Evaluation
of Prototype

Engineer Final
Product
33
34
Advantages

1. Reduces risk of incorrect user requirements

2. Good where requirements are
changing/uncommitted
3. Regular visible progress aids management
4. Supports early product marketing

34
35
Disadvantages I

1. An unstable/badly implemented prototype

often becomes the final product. (Migration to
a type 1 process!)
2. Requires extensive customer collaboration
– Costs customers time/money
– Needs committed customers
– Difficult to finish if customer withdraws
– May be too customer specific, no broad
market

35
36
Disadvantages II

3. Difficult to know how long project will last

4. Easy to fall back into code-and-fix without
proper requirements analysis, design,
customer evaluation and feedback.

36
37 Type 1 (Exploratory Development):
Agile Software Processes

• Need for an adaptive process model suited to

changes in:
• User requirements
• Customer business models
• Technology
• In-house environment
• De-emphasis documentation, esp. URD!
• Emphasis change management,
e.g. reverse engineering design

37
38
Agile Principles

• Incremental delivery of software

• Continuous collaboration with customer
• Embrace change
• Value participants and their interaction
• Simplicity in code

38
Agile

39
Agile Manifesto

40
41

Agile Approaches

Encourage the development of particularly

small iterations
• Well suited for small projects that involve uncertain,
changing requirements and other high risk
• Can be used on all project except perhaps those
with high levels of safety concerns (where complex
designs must be validated)

Popular Agile approaches:

SCRUM, KANBAN, and Extreme Programming

41
42

eXtreme Programming (XP)

The most famous agile technique is

eXtreme Programming (XP)
• All stakeholders work closely together (on-site
customer)
• User stories are written instead of requirement
document
• There must be a series of small and frequent
releases (1 to 3 weeks)
• Continuous integration

42
43

eXtreme Programming (XP)

• Incremental planning. The project variables are:

scope, resources and time (and quality)
• Sustainable pace (No overtime!)
• Test-driven development. Test cases are written
before the software is developed
• Simple design. A large amount of refactoring is
encouraged
• Pair-programming is recommended. Collective
ownership: code, metaphors, standards,..etc
• Focuses heavily on ensuring the quality of
delivered software
43
44
XP - Release Cycle

Select Breakdown
release stories to Plan release
stories tasks

Evaluate Develop/
Release
system Integrate/
code
Test code

44
Agile Modeling
Content is more important than representation.
A UML class diagram
sketch on Microsoft Visio
paper Diagram

The sketch is sufficient for its purpose - took one-third the time of drawing it
using a sophisticated tool. Making it prettier using a tool and documenting it
comprehensively does not add anything to further this goal.
45
Agile Modeling

Lean modeling. You model to understand. You model to

communicate.
• Post-it notes or sketches on white boards

Source: http://www.erikgfesser.com/ Source: http://www.agile-ux.com/

46
Trello - An Agile Project Tool

Cards
(User Stories)

Boards to
communicate
status, progress,
and issues.

47
48
Advantages

1. Lightweight methods suit small-medium size

projects
2. Produces good team cohesion
3. Emphasises final product
4. Iterative
5. Test-based approach to requirements and quality
assurance

48
49
Disadvantages

1. Difficult to scale-up to large projects where

documentation is essential
2. Needs experience and skill if not to degenerate
into code-and-fix
3. Programming pairs are costly (but see productivity
literature)
4. Test-case construction is a difficult and
considered a specialised skill

49
50
COTS

COTS; Commercial Off-the-Shelf software

• Integrate a solution from existing commercial

software components using minimal software
plumbing
• All projects seek some
software reuse –
Holy Grail of SE
(See also Sommerville Chapter 19)

50
51
Possible Approaches

• Third-party vendors: component libraries, Java

Beans,..etc
• Integration solutions: CORBA, MS COM+,
Enterprise Java Beans, software frameworks,..etc
• Good software engineering: application generators
(Yacc, Lex…Sommerville 18.3), generic
programming (types, polymorphism,..etc)
• Commercial finished packages: databases,
spread-sheets, word processors, web browsers,..etc.
• Design to open-source interfaces: e.g. XML, ISO
standards,..etc.
51
52
Advantages

1. Fast delivery; reduces the amount of software to

be developed
2. Reduces cost and risk
3. Explore solutions with existing products
(c.f. your project work!)
4. May give all the basic functionality
5. Well defined integrated project, easy to run
6. Open to out-sourcing (c.f. Point 4)
7. Build strategic supplier partnerships

52
53
Disadvantages

1. Limited functionality or requirements compromised

2. Component identification can be tricky – mistakes
occur!
3. Licensing problems: freeware, shareware,..etc
4. Customer lock-in:
license fees, maintenance fees, upgrades,..etc
5. Compatibility issues/loss of control:
• Between components (doesn’t start!)
• During maintenance (suddenly stops!)
6. Control lost over the evolution of part of the system

53
54

The Concurrent Engineering Model

It explicitly accounts for the

divide-and-conquer principle

• Each team works on its own component, typically

following a spiral or evolutionary approach
• There has to be some initial planning, and
periodic integration
• Can be blended with the Spiral model

54
55

The Concurrent Engineering Model

Single
Iteration

55
56
Rational Unified Process (RUP)

Hybrid model inspired by:

• UML,
• and Unified Software Development Process
A generic component-based process?

Three views on the process:

• Dynamic view: RUP phases
• Static view: RUP activities
• Practise view: RUP best-practise

56
57

Rational Unified Process (RUP)

A widely known methodology

• Iterative
• Embraces UML
• Suggests a process framework
• Designed to be adaptable
• Adapts to the project needs
• Use-case-driven development
• Architecture-centric process

57
58
Details

• Envisions the lifetime of a software product as

cycles:
Birth, childhood, adulthood, old-age, death.
• Identify product maturity stages
• Each project iteration cycle is a phase,
culminating in a new release (c.f. Spiral model)

58
59
UP Process – RUP Phase Workflow

Inception Elaboration

Transition Construction

Drawn as a UML State Chart!

59
60
RUP Phases

Inception Elaboration Construction Transition

time
Phases are goal directed, and yield deliverables:
• Inception
– Establish the business case
– Identify external entities (actors - systems)
– Estimate ROI
• Elaboration
– Understand problem domain
– Establish architecture, and consider design tradeoffs
– Identify project risks
– Estimate and schedule project
– Decide on build vs. buy

60
61
RUP Phases

Inception Elaboration Construction Transition

time
• Construction
– Design, program and test
– Components are bought and integrated

• Transition
– release a mature version and deploy in real
world

61
 The Iterative Approach

In an iteration,
you walk
through all
disciplines.

Disciplines
group
activities
logically.
RUP Workflows
Business
Modeling
Workflow

Requirements
Workflow
64
RUP Workflows

• RUP separates what and when into two orthogonal

process views.
• When modeled by phases
• What modeled by workflows
(c.f. Sommerville Figure 4.13)
• Any workflow can be active in any phase
• Anything that instantiates the following diagram is an
instance of RUP
• An agile instantiation exists (Larman 2002)

64
65
Unified Process:
Project Product
SoftwareProcess
Management

Environment * * releases
Workflow Cycle

Requirements Inception
4
Analysis/ Phase Elaboration
Design

Implementation * Construction

Iteration
Testin
Transition
g *
Business
Deployment Artifact
Modeling
65
66
RUP Practise View

1. Develop software iteratively

2. Manage requirements
3. Use component-based architectures
4. Visually model software
5. Verify software quality
6. Control software changes

66
67

Use Case Model

specified by
UML class
diagram!
Analysis Model realised by

Design Model implemented by

Implementation Model deployed by

verified by

Deployment Model

4. Visually model software =

Test Model
UML Model-based Development
67
68
Advantages / Disadvantages

• Difficult to judge without knowing the actual chosen

instantiation of the RUP

• Unique use of the UML philosophy of SE.

• Can be as good/better than any other process

• Also, as bad/worse than any other process

68
69
Combining/Evolving Process Models

Combinations of processes models are used

sometimes to get the benefits of more than one
model, e.g.:
• Waterfall inside Evolutionary
e.g. onboard shuttle software
• Evolutionary inside Waterfall
e.g. GUI prototyping

We can also evolve the process model together

with the product to account for product maturity,
e.g. rapid prototyping → waterfall
69
70

Re-engineering

Periodically, project managers should set aside some

time to re-engineer part or all of the system

The extent of this work can vary:

• Cleaning-up the code to make it more readable
• Completely replacing a layer
• Re-factoring part of the design

Key objective: increase maintainability

70
References

• Object‑oriented Software Engineering: Practical

Software Development, by Robert Laganière and
Timothy C. Lethbridge.
• Agile Modeling- Effective Practices for eXtreme
Programming and the Unified Process, by Scott
Ambler

71