Process models

By

Hyung Jae (Chris) Chang

Troy University

Some slides are in courtesy of Dr. Soo Dong Kim and Dr. Hyun Jung La at Soongsil
University

Process Models

Process in Software Engineering

Definition
A

methodology consists of a process, a vocabulary, and g

uidelines.
A process defines a set of activities that together accompl
ish all the goals of the methodology.
Key

Elements of a Process

Life-Cycle

Phases, Activities, Steps

For

Model

Methodolo
gy
is like a
Cookbook.

each Activity

Input, Output Artifacts, Instruction, Quality Guidelines

Software Process
Coherent

sets of activities for specifying, designing, im

plementing and testing software systems

structured set of activities required to develop a soft

ware system

software process model is an abstract representatio

n of a process. It presents a description of a process fr
om some particular perspective

The software process

Many

different software processes but all involve:

Specification

defining what the system should do;

Design and implementation defining the organization o
f the system and implementing the system;
Validation checking that it does what the customer wan
ts;
Evolution changing the system in response to changing
customer needs.

Why Software Process?

Quality of Proces
s
Quality of Product

Why is process essential in SE?

ISO/IEC 9126
Revision in 2001
ISO/IEC 9126-1 to 9126-4

Part 1
Quality Model

Part 2
External Metrics

Part 3
Internal Metrics

Part 4
Quality In Use Metrics

Why is process essential in SE? (cont.)

Quality Model: identifies 6 main quality characteristics
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

Quality Model
Functionality
Essential purpose of any product or service
The more functions, the more complicated it becomes to define i

ts functionality.
Suitability, accurateness, interoperability, compliance, security,
Reliability
Defines the capability of the system to maintain its service provisi

on under defined conditions for defined periods of time; fault tol

erance
Maturity, fault tolerance, recoverability,
Usability
Ease of use/learn for a given function
Understandability, learnability, operability,
9

Quality Model (cont.)

Efficiency
The system resources used when providing the required functional

ity; disk space, memory usage, network

Time behavior, resource usage,
Maintainability
Can be impacted by code readability or complexity as well as mod

ularization
Anything that helps with identifying the cause of a fault and then
fixing the fault is the concern of maintainability.
Analyzability, changeability, stability, testability,
Portability
How well the software can adopt to changes in its environment or

with its requirements.

Adaptability, installability, conformance, replaceability,
10

Quality Model Framework

Quality
Process

in the Lifecycle
Software Product

Effect of Software
Product

Influences
Influences
Influences
Externa
Internal
Quality
l
Process
Quality
in Use
Quality
Quality
Attribut
Attribut
Attribut
es
es
es
Depends on
Depends on
Depends on

Process
Measures

Internal
Measures

External
Measures

Contexts
of Use

Quality in Use
Measures

11

Quality Model Framework

Process

Quality

Quality

of Life-cycle Process
Process quality contributes to improving product quality.
Product

Quality

Can

be evaluated by measuring internal attributes or mea

suring external attributes.
Internal quality
is evaluated by the static measure of intermediate products.
View at Technical Level

External

quality

is evaluated by measuring the behavior of the code when executed

.

View of User/Management

Product

quality contributes to improving quality in use.

12

Quality Model Framework

Quality

In Use

Users

view of the quality of an environment containing s

oftware, and is measured from the results of using the so
ftware in the environment.

Rather than properties of the software itself.

Users

environment may be different from development e

nvironment.

13

Framework for Processes

Supporting Activities

Definition

Supporting

Development

Maintenance

Activities?

14

Framework for Processes

Supporting Activities

Definition

Supporting

Development

Maintenance

Activities

Project Management
Reviews (FTR) and Inspection
Quality Assurance
Configuration Management
Measurement
Risk Management
Others

15

Framework for Processes (cont.)

Supporting Activities

Definition

Engineering

Development

Maintenance

Activities

Definition

Requirement Engineering

Development

Analysis, Design, Implementation, Testing, Deployment

Maintenance

Post-Development Activities

Retirement

16

Engineering Activities
Preliminary
Preliminary
Design
Design

Requiremen
Requiremen
tt Definition
Definition

Analysis
Analysis

Detailed
Detailed
Design
Design

Design
Design

Implementa
Implementa
tion
tion

Development

Testing
Testing

Operation

Retirement
Retirement

Maintenanc
Maintenanc
ee

Operation
Operation

Deployment
Deployment

17

Plan-driven and agile processes

Plan-driven

processes are processes where all of the pr

ocess activities are planned in advance and progress is
measured against this plan.

In

agile processes, planning is incremental and it is easi

er to change the process to reflect changing customer
requirements.

In

practice, most practical processes include elements

of both plan-driven and agile approaches.

There

are no right or wrong software processes.

18

Representative Process Models

Waterfall

Model

Rapid

Application Development (RAD) Model

Spiral

Model

Prototyping

Model

Component-Based
Aspect-Oriented
Agile

Development (CBD) Model

Development Model

Process

eXtreme

Programming (XP)

Scrum

Formal

Method

19

Waterfall Model

20

Waterfall Model
Oldest

paradigm in Software Engineering

Sequential
When

approach to S/W development

to Choose?

When

requirements of a problem are reasonably well un

derstood.
When work flows from communication through deploym
ent in a reasonably linear fashion.
When requirements are well-defined and reasonably stab
le.

21

Waterfall Model (cont.)

Requiremen
Requiremen
tt Definition
Definition
Analysis
Analysis

Design
Design
Implementa
Implementa
tion
tion
Testing
Testing
Operation
Operation
and
and
Maintenanc
Maintenanc
ee
22

Waterfall Model (cont.)

Problems
Real

projects rarely follow the sequential flow that the m

odel proposes.
It is often difficult for the customer to state all requireme
nts explicitly.
The customer must have patience.

A working version of the program will not be available until late in t

he project time-span.

The

waterfall model is mostly used for large systems engi

neering projects where a system is developed at several si
tes.

In those circumstances, the plan-driven nature of the waterfall mod

el helps coordinate the work.
23

Incremental Development

24

Incremental development

25

Incremental development and delivery

Incremental

development

Develop

the system in increments and evaluate each incr

ement before proceeding to the development of the next
increment;
Normal approach used in agile methods;
Evaluation done by user/customer proxy.
Incremental

delivery

Deploy

an increment for use by end-users;

More realistic evaluation about practical use of software;
Difficult to implement for replacement systems as increm
ents have less functionality than the system being replace
d.
26

Incremental delivery
Rather

than deliver the system as a single delivery, the

development and delivery is broken down into increm
ents with each increment delivering part of the require
d functionality.

User

requirements are prioritized and the highest prior

ity requirements are included in early increments.

Once

the development of an increment is started, the

requirements are frozen though requirements for later
increments can continue to evolve.

27

Incremental development benefits

The

cost of accommodating changing customer requir

ements is reduced.
The

amount of analysis and documentation that has to b

e redone is much less than is required with the waterfall
model.

It

is easier to get customers feedback on the develop

ment work that has been done.
Customers

can comment on demonstrations of the softw

are and see how much has been implemented.

More

rapid delivery and deployment of useful softwar

e to the customer is possible.
Customers

are able to use and gain value from the softw28

Incremental development problems

The

process is not visible.

Managers

need regular deliverables to measure progress.

If systems are developed quickly, it is not cost-effective to
produce documents that reflect every version of the syste
m.

System

structure tends to degrade as new increments

are added.
Unless

time and money is spent on refactoring to improv

e the software, regular change tends to corrupt its struct
ure. Incorporating further software changes becomes inc
reasingly difficult and costly.
29

Incremental delivery advantages

Customer

value can be delivered with each increment

so system functionality is available earlier.

Early

increments act as a prototype to help elicit requir

ements for later increments.

Lower

risk of overall project failure.

The

highest priority system services tend to receive the

most testing.

30

Incremental delivery problems

Most

systems require a set of basic facilities that are

used by different parts of the system.
As

requirements are not defined in detail until an incre

ment is to be implemented, it can be hard to identify c
ommon facilities that are needed by all increments.

The

essence of iterative processes is that the specific

ation is developed in conjunction with the software.
However,

this conflicts with the procurement model of

many organizations, where the complete system specif
ication is part of the system development contract.

31

Spiral Model

32

Spiral Model
Adapted

to apply throughout the entire life cycle of an

application, from concept development and maintena
nce. (iterative approach)

Couples

the iterative nature of prototyping with the co

ntrolled and systematic aspects of the waterfall model.

Software

is developed in a series of incremental releas

es.
Early

Release might be a paper model prototype.

Later

iterations
iterations

More complete versions of the engineered system are produced.

33

Spiral Model (cont.)

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
delivery
feedback

construction
code
test

34

Spiral Model (cont.)

Advantages
Effectively

Gathering and Refining Requirements

Risk Reduction through Clients Feedback
Realistic Approach for Large-scaled systems
Drawbacks
Hard

to Control

Iterations and Increments

Progress Monitoring

35

Agile Process

36

Agile Process
What

is Agility?

Effective

(rapid and adaptive) response to change

Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work perf
Yielding rapid, incremental delivery of
ormed
software

Agility

and Cost of Change

37

Agile Process (cont.)

A

group of software development methods based on i

terative and incremental development, where require
ments and solutions evolve through collaboration bet
ween self-organizing, cross-functional teams [Wiki]

To promote;
Adaptive

Planning
Evolutionary development and delivery
A time-boxed iterative approach
Rapid and flexible response to change
Introduced

by Agile Manifesto in 2001

38

12 Agile Principles
Principle

1. Customer satisfaction by rapid delivery of usefu

l software
The

highest priority is to satisfy the customer through early an

d continuous delivery of valuable software.

Principle

2. Welcome changing requirements, even late in

development
Agile

processes harness change for the customers competitive

advantage.
Agile teams work to keep the software structure flexible, so re
quirement change impact is minimal.
Principle

3. Working software is delivered frequently (week

s rather than months)
From

a couple of weeks to a couple of months with a preferen

ce to the shorter time scale
39

12 Agile Principles (cont.)

Principle

4. Working software is the principal measure of progres

s
Agile

projects measure their progress by measuring the amount of w

orking software.

Principle

5. Sustainable development, able to maintain a constant

pace
Agile

Processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace i
ndefinitely.

Principle

6. Close, daily cooperation between business people an

d developers
For

agile projects, there must be significant and frequent interaction

among the

customers,
developers, and

stakeholders.

40

12 Agile Principles (cont.)

Principle

7. Face-to-face conversation is the best form of commun

ication (co-location)
In

agile projects, developers talk to each other.

The primary mode of communication is conversation.

Documents may be created, but there is no attempt to capture all project informat
ion in writing.

Principle

8. Projects are built around motivated individuals, who s

hould be trusted
Give

them the environment and support they need, and trust them to
get the job done.

Principle

9. Continuous attention to technical excellence and goo

d design
The

way to go fast is to keep the software as clean and robust as poss

ible.
Thus, all agile team-members are committed to producing only the hi
ghest quality code they can.
41

12 Agile Principles (cont.)

Principle
Agile

10. Simplicity is essential

teams take the simplest path that is consistent with their go

als.
Principle

11. Self-organizing teams

The

best architectures, requirements, and designs emerge from Se

lf-Organizing Teams.

Responsibilities are not handed to individual team members from the outside.

Responsibilities are communicated to the team as a whole, and the team dete
rmines the best way to fulfill them.

Principle

12. Regular adaptation to changing circumstances

At

regular intervals, the team reflects on how to become more eff

ective, then tunes and adjusts its behavior accordingly.
An agile team knows that its environment is continuously changin
g, and knows that they must change with that environment to re
main agile.
42

Agile method applicability

Product

development where a software company is de

veloping a small or medium-sized product for sale.

Custom

system development within an organization,

where there is a clear commitment from the customer
to become involved in the development process and w
here there are not a lot of external rules and regulatio
ns that affect the software.

Because

of their focus on small, tightly-integrated tea

ms, there are problems in scaling agile methods to larg
e systems.

43

Problems with agile methods

It

can be difficult to keep the interest of customers who are involv

ed in the process.

Team

members may be unsuited to the intense involvement that

characterizes agile methods.

Prioritizing

changes can be difficult where there are multiple stak

eholders.
Maintaining

simplicity requires extra work.

Many

organizations, especially large companies, have spent years

changing their culture so that processes are defined and followe
d. It is difficult for them to move to a working model in which pro
cesses are informal and defined by development team.

44

Agile methods and software maintenance

Most

organizations spend more on maintaining existin

g software than they do on new software developmen
t. So, if agile methods are to be successful, they have t
o support maintenance as well as original developmen
t.

Two

key issues:

Are

systems that are developed using an agile approach

maintainable, given the emphasis in the development pro
cess of minimizing formal documentation?
Can agile methods be used effectively for evolving a syste
m in response to customer change requests?
Problems

may arise if original development team cann45

Plan-driven and agile development

Plan-driven

development

plan-driven approach to software engineering is based

around separate development stages with the outputs to
be produced at each of these stages planned in advance.
Not necessarily waterfall model plan-driven, incremental
development is possible
Iteration occurs within activities.
Agile

development

Specification,

design, implementation and testing are int

er-leaved and the outputs from the development process
are decided through a process of negotiation during the
software development process.
46

Plan-driven and agile Development

47

Technical, human, organizational issues

Most

projects include elements of plan-driven and agile pro

cesses. Deciding on the balance depends on:
Is

it important to have a very detailed specification and design

before moving to implementation? If so, you probably need to
use a plan-driven approach.
Is an incremental delivery strategy, where you deliver the softw
are to customers and get rapid feedback from them, realistic? I
f so, consider using agile methods.
How large is the system that is being developed? Agile method
s are most effective when the system can be developed with a
small co-located team who can communicate informally. This
may not be possible for large systems that require larger devel
opment teams so a plan-driven approach may have to be used.
48

 What

Technical, human,
organizational issues (cont.)
type of system is being developed?

Plan-driven

approaches may be required for systems that require a lot of anal

ysis before implementation (e.g. real-time system with complex timing requir
ements).

What

is the expected system lifetime?

Long-lifetime

systems may require more design documentation to communic

ate the original intentions of the system developers to the support team.

What

technologies are available to support system development?

Agile

How

methods rely on good tools to keep track of an evolving design

is the development team organized?

If

the development team is distributed or if part of the development is being

outsourced, then you may need to develop design documents to communica
te across the development teams.

49

Technical, human,
organizational
issues
(cont.)
Are there
cultural or organizational
issues that
may affect the sy
stem development?
Traditional

engineering organizations have a culture of plan-based

development, as this is the norm in engineering.

How

good are the designers and programmers in the developm

ent team?
It

is sometimes argued that agile methods require higher skill levels

than plan-based approaches in which programmers simply translat
e a detailed design into code

Is

the system subject to external regulation?

If

a system has to be approved by an external regulator (e.g. the FA

A (Federal Aviation Admiration) approve software that is critical to
the operation of an aircraft) then you will probably be required to
produce detailed documentation as part of the system safety case.

50

Scaling agile methods

Agile

methods have proved to be successful for small a

nd medium sized projects that can be developed by a s
mall co-located team.

It

is sometimes argued that the success of these metho

ds comes because of improved communications which
is possible when everyone is working together.

Scaling

up agile methods involves changing these to c

ope with larger, longer projects where there are multi
ple development teams, perhaps working in different l
ocations.

51

le Process: Extreme Programming (X

52

Extreme Programming (XP)

The

most widely used agile process, originally prop

osed by Kent Beck

XP

Planning

Begins

with the creation of user stories

Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment project velocity is used to
help define subsequent delivery dates for other incre
ments

53

Extreme Programming (XP) (cont.)

XP

Design

Follows

the KIS (Keep It Simple) principle

For

difficult design problems, XP suggests the immediate creation of an op

erational design prototype called spike solutions

Encourages

refactoringan iterative refinement of the internal program

design

XP

Coding

Recommends

the construction of a unit test for a store before coding com

mences
Encourages

XP

pair programming

Testing

All

unit tests are executed daily

Acceptance

tests are defined by the customer and executed to assess cus

tomer visible functionality
54

Extreme Programming (XP) (cont.)

55

Agile Process: Scrum

56

Overview on Scrum
Agile

approach for developing innovative products an

d services

57

Overview on Scrum (cont.)

To begin
A

by creating a product backlog

prioritized list of the product backlog items (PBIs).

To work

on the most important or highest priority item

s first, guided by the product backlog

To perform

each work in short, time-boxed iterations

Ranging

from a week to a calendar month in length

By a self-organizing, cross-functional team

58

Overview on Scrum (cont.)

At

the start of each iteration

To

plan which high-priority subset of the product backlog

to create in the upcoming iteration

At

the end of the iteration

To

produce a potentially shippable product or increment

of the product
To review the completed features with the stakeholders t
o get their feedback
Based on the feedback, to alter both what they plan to w
ork on next and how the team plans to do the work

59

Scrum Roles
Scrum

Team

Consists

In

of one or more members.

each Scrum Team

To

make up of essential three scrum roles;

Product Owner
ScrumMaster
Development Team

Can

include other roles

60

Scrum Roles Product Owner

The

single authority responsible for deciding what feat

ures and functionalities will be developed and in what
order

To maintain

and communicate to all other participants

a clear vision of what the Scrum team is trying to achie
ve
To

actively collaborate with the ScrumMaster and develo

pment team
Must be available to answer questions soon after other p
articipants are posed
Responsible

for the overall success of the solution bein

g developed or maintained
61

Scrum Roles ScrumMaster

Responsible

for guiding the team in creating and following its

own process based on the broader Scrum framework
To

help everyone involved understand and embrace the Scrum val

ues, principles, and practices

To act

as a coach

To

help the Scrum team and the rest of the organization develop t
heir own high performance, organization-specific Scrum approach

To act

as a facilitator

To

help the team resolve issues and make improvements to its use
of Scrum
To protect the team from outside interference
To act

as a leader

To

take a leadership role in removing impediments that inhibit tea

m productivity
62

Scrum Roles
Development Team
Responsible

for determining how to deliver what the p

roduct owner has asked for

To self-organize

to determine the best way to accompl

ish the goal set out by the product owner

Typically

five to nine people in size

Its

members must collectively have all of the skills needed

to produce good quality, working software.

63

Scrum Activities and Artifacts

Vision of
the Project

Product Owner

64

Scrum Activities and Artifacts (cont.)

To perform

grooming

Done

by a product owner
To break a project vision of the product owner down into a set of fe
atures that are collected into a prioritized list (i.e. product backlog)
Artifact

A product backlog

To perform

sprint planning

Mainly

done by a development team

To determine a subset of the product backlog items it believes it can
complete
Artifact

A sprint backlog
Which describes how the team plans to design, build, integrate, and test the
selected subset of features from the product backlog during that particular s
print

65

Scrum Activities and Artifacts (cont.)

To perform

the sprint execution

Done

by the development team

To perform the tasks necessary to realize the selected feat
ures
To perform the daily scrum everyday

The team members help manage the flow of work by conducting a

synchronization, inspection, and adaptive planning activity.

Artifact

A potentially shippable product increment

Which represents some, but not all, of the product owners visio
n, at the end of sprint execution

66

Scrum Activities and Artifacts (cont.)

To perform
The

sprint review

The stakeholders and Scrum team inspect the product being built.

The

two inspect-and-adapt activities

sprint retrospective

The Scrum team inspects the Scrum process being used to create t
he product.

Artifact

Adaptations that will make their way into the product backlog or b
e included as part of the teams development process

67

Product Backlog
A

prioritized list of the project work, i.e. Product Backlog It

ems (PBIs).

PBIs

are prioritized.

Higher-value

items appear at the top of the product backlog.

Lower-value items appear toward the bottom.
Initially

generated by the product

owner
With

Can

input from the team and stakeholders

be evolved, i.e. Grooming

Items

can be added, deleted, and revised

at the end of each iteration.
Mainly due to (1) change on requirement(s)
and (2) teams growing understanding on the product.
68

Types of Product Backlog Items

Feature

Type

Represents

a functional unit to be developed.

Example) Develop Rental Component.
Change

Type

Represents

a modification work on an existing artifact,

mainly due to the change on requirement or business process.
Example) Modify the Check out car procedure.
Defect

Type

Represents

a defect removal work on an existing artifact.

Example) Fix the defect on Rental; computing the fee for a late return.
Technical

Improvement

Represents

an improvement work on an existing artifact.

Example) Upgrade the DMBS with a latest version.
Knowledge
Represents

Acquisition Type
a knowledge acquisition work needed in the project.

69

Grooming Product Backlog

The

activity of creating and refining PBIs, estimating th

em,
and prioritizing them

70

Estimating Cost of PBIs

Estimating

the size/cost of each PBIs

Used

to properly determine its priority.

Before finalizing prioritizing, ordering, or otherwise arran
ging the product backlog
Which size measures to use
Not dictated by Scrum
Relative Size Estimates
are typically used.

71

Sprints
Iterations

or cycles of up to a calendar month

Time-boxed
To

have a fixed start and end date

Generally, to have the same duration

72

Activity Sprint Planning

To determine

the most important subset of product ba

cklog items to build in the next sprint

To spend
For

about four to eight hours in sprint planning

two-week to one-month sprint

73

Activity Sprint Planning (cont.)

How

to Perform

To

agree on a sprint goal that defines what the upcoming

sprint is supposed to achieve

Done by the product owner and development team

To

review the product backlog and determine the high pr

iority items

That the team can realistically accomplish in the upcoming sprint w

hile working at a sustainable pace
Done by the development team

74

Activity Sprint Planning (cont.)

To

break down each targeted feature into a set of tasks, i

.e. sprint backlog
To provide an estimate (typically in hours) of the effort re
quired to complete each task

<Sprint Backlog>
75

Activity Sprint Execution

To perform

all of the task-level work necessary to get t

he features done
Done

by the development team

Guided by the ScrumMasters coaching

76

Activity Sprint Execution (cont.)

To define

teams task-level works by themselves

To self-organize

in any manner they feel is best for ach

ieving the sprint goal

77

Activity Daily Scrum

To hold

a time-boxed (15 minutes or less) inspect-and

adapt activity, each day of the sprint
An

inspection, synchronization, and adaptive daily planni

ng activity that helps a self-organizing team do its job bet
ter

Referred

as the daily stand-up

Everyone

stands up during the meeting to help promote

brevity.

78

Activity Daily Scrum (cont.)

79

Activity Daily Scrum (cont.)

A

Common Approach to Perform the Daily Scrum

To

have the ScrumMaster facilitating

To have each team member taking turns answering three
questions
What did I accomplish since the last daily scrum?

What do I plan to work on by the next daily scrum?

What are the obstacles or impediments that are preventing me fro

m making progress?

Benefits
Essential

for helping the development team manage the f

ast, flexible flow of work within a sprint
Useful to communicate the status of sprint backlog items
among the development team members
80

Activity Done
To produce

potentially shippable product increment

Whatever

the Scrum team agreed to do is really done acc

ording to its agreed-upon definition of done.
There isnt materially important undone work that needs t
o be completed.

81

Activity Sprint Review

To inspect

and adapt the product that is being built

82

Activity Sprint Review (cont.)

To take

place a conversation among its participants

Including

the Scrum team, stakeholders, sponsors, custo

mers, and interested members of other teams
To review the just-completed features in the context of th
e overall development effort
Objectives
To

get clear visibility into what is occurring

To have an opportunity to help guide the forthcoming de
velopment to ensure that the most business-appropriate
solution is created

83

Activity Sprint Retrospective

To inspect

and adapt the process

The

development team, ScrumMaster, and product owne

r discuss what is and is not working with Scrum and asso
ciated technical practices.

To focus

on the continuous process improvement nece

ssary to help a good Scrum team become great

84