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
