1

PROCESS MODELS
Lecture 3
2 Content

Introduction
Process Models
 Linear
 Iterative
 Parallel
 Prototypes
 Continuous delivery
Integrating agile practices into processes
3 References
 Software Architecture Metrics, Ciceri, Christian,
Farley, Dave, Ford, Neal, et al. Eoin, & Safari,
2022. (1st edition.). O’Reilly Media, Inc.
 SOFTWARE PRODUCT MANAGEMENT Course
Specialization, Coursera, University of Alberta
 [Link]
 The DevOps Handbook: How to Create World-
Class Agility, Reliability, and Security in
Technology Organizations by Gene
Kim , Patrick Debois, John Willis, Jez Humble,
October 6, 2016
 Learning DevOps: Continuously Deliver Better
Software, Joakim Verona,Michael Duffy,Paul
Swartout, 2016
4 Why a process?
Projects are unique
No prescribed formula to get the final
product done
Need continuous evaluation and decision
making
Need some form of work organization

Process organizes the work into distinct

phases
Structured software development
5
6 How much covers a process?
Life cycle process = starts from the product’s
initial conception -> eventual retirement
Includes sub-processes
Contains phases (i.e. Specification, Design,
Implementation, Verification and Validation)
7 Process decomposition
Process contains
Phases that contain
Activities that contain
Tasks
Phase
 Ex.
 Verification and Validation
Activity
 Execute tests
 Write test framework code
 Design tests Tasks

 Write tests
 Run tests
8 Task
 The most basic unit of work
 Assigned to persons ROLES
 Produces a work product
 Can use work products (dependencies)
 Consumes resources (i.e. time, people,
technology, knowledge, money)
9 Process models
Linear: phases happen sequentially
Iterative: phases are repeated in cycles
Parallel: activities occur concurrently

[Link]
10 Process/Methodology
WHAT HOW

 Process = Methodology ?
 NOT!
 Methodology = set of practices
 Practice = strategy to execute a (sub) process
Ex.
 Management practices for scheduling and
organizing tasks, minimizing resource waste, and
tracking completed work
 Development practices for preparing effective
tests, maintaining simplicity, and conducting
technical reviews
11 Process/Practices
 Practice
 Specific to a phase (i.e. Specification
phase: elicit requirements, express
requirements, etc.)
 Specific to the whole process (i.e.
Management practices: daily meetings,
monitoring productivity etc.)

 Processes and practices are flexible and

customizable!
 Combine aspects of processes and practices
for your needs!
12 Process Phases
13 Project management activities
 Creating a process  Allocating resources
 Setting standards  Making measurements
 Managing risks  Improving the process
 Performing estimations
14 Linear Process Models - Waterfall
“Get things right the first time and avoid rework”
 Benefits
 easy to understand;
 clearly defines deliverables and milestones;
 emphasizes the importance of analysis before design, and design before
implementation;
 can be adopted within teams using more sophisticated processes, for
well-specified parts of the product that can be outsourced
 Drawbacks
 not adaptable to change
15 Linear Process Models – V Model
 Benefits
 easy to understand;
 clearly defines deliverables and milestones;
 emphasizes the importance of analysis before design, and design before
implementation;
 allows the development team to verify the product at multiple levels in
explicit phases

 Drawbacks
 not very adaptable to change
16 Linear Process Models - Sawtooth
 Benefits
 easy to understand;
 clearly defines deliverables and milestones;
 the client is involved to review intermediate prototypes of the product
during the process
 Drawbacks
 not very adaptable to change
17
Iterative Models
“Work is done in iterations that allow for revisions of the product”
 Benefits
 ability to loop and revisit previous phases ;
 allow for client feedback to be incorporated within the process;
 Drawbacks
 estimating work can be more difficult
 requires much analytical expertise to assess risks
18 Parallel Models
“Work is done in iterations however, parallel processes allow for more
concurrency ”
 Benefits
 allows for tasks done in one phase to also occur in another ;
 once the product is released, the process can begin another cycle to
refine and improve the product ;
 well suited to large projects where iterations can allow the product to
grow naturally beyond the original inception for the product

 Drawbacks
 estimating work can be
difficult
19 Prototypes

Applied in both Spiral and UP models

Types:
 Illustrative
 Exploratory
 Throw-away
 Incremental
 Evolutionary
20 Illustrative prototype

 Most basic
 The purpose is to define the basic idea
 May involve storyboarding, wireframes, even
drawings on paper or slideshows
21 Exploratory prototype

Involves working code

The purpose is to explore what is feasible
Expensive in terms of consumed resources
=> Important to evaluate the cost of
exploratory prototyping vs. cost of finding out
later that the product is not realizable
22 Throw-away Prototype
 The first version of a product (usually having various
problems) => opportunity to learn from past mistakes
 First version with patches and fixes vs. robust second
version
 Have working software for each successive
prototype, any of which could be released as a
version of your software product

 A common feature of illustrated, exploratory, and

throw-away prototypes is that none of the effort to
build the prototypes will end up in the final version of
the product.
 Lessons learned
 Development resources lost
23 Incremental Prototype

Product is built and released in increments

Triage system: components are built
iteratively in increments starting with the most
important to the least important
Priorities:
 must do (in Complete first-version
prototype)
 should do (added in second version)
 could do (added in third version)
24 Evolutionary Prototype
The first-generation prototype has all the
features of the product, even though some
features may need to “evolve” or be refined
Integrating prototypes with Spiral/UP models
 First iteration – creation of illustrative
prototype
 Next iterations – incremental/evolutionary
prototype approach

IMPORTANT! Core idea is to gain feedback

on versions of the product => make decisions
on future versions!
25
What can we learn from a
prototype?
 Conceptual model
 Do users understand it?
 Functionality
 Does it do what’s needed? Missing features?
 Navigation & task flow
 Can users find their way around?
 Are information preconditions met?
 Terminology
 Do users understand labels?
 Screen contents
 What needs to go on the screen?
26
What can we learn from a
prototype?
 Screen layout
 Is it clear, overwhelming, distracting,
complicated?
 Can users find important elements?
 Colors, fonts, icons, other elements
 Well-chosen?
 Interactive feedback
 Do users notice & respond to status bar
messages, cursor changes, other feedback
 Efficiency issues
 Controls big enough? Too close together?
Scrolling list is too long?
27 Prototype evaluation
 Google HEART framework
([Link]
n//pubs/archive/[Link])
 Happiness — Measure of user attitudes (via surveys or interviews).
 Ex: satisfaction, perceived ease of use, and net promoter score.

 Engagement — Measures the level of user involvement (via behavioral

proxies such as frequency, intensity, or depth of interaction over some
time period).
 Ex: # of visits/user/week or # of photos uploaded/user/day.

Taken from: [Link]

28 Prototype evaluation
 Adoption — New users of a product, feature or a
service.
 Ex: # of accounts created in the last seven days,
# of people dropping off during the onboarding
experience.
 Retention — The rate at which existing users are
returning.
 Ex: # of active users from a given time period
that are still present in some later time period, or
churn (failure to retain)
 Task success —traditional behavioral metrics with
respect to user experience, such as efficiency (e.g.
time to complete a task), effectiveness (e.g.
percent of tasks completed), and error rate.
29 HEART + Goals-Signals-Metrics

From [Link]
30 Prototyping tools
 Storyboarding Tools
 Photoshop
 Balsamiq Mockup
 Mockingbird
 Form Builders
 Mac Interface Builder
 Qt Designer
 FlexBuilder
 Silverlight
 Visual Basic

[Link]
prototyping/#reading_8_prototyping
31 Continuous Delivery
Continuous Delivery applies automation so
that intermediate releases of working
software can be more disciplined and
frequent.
The aim is to have working software that is
tested, ready to run, and releasable to
others.
Releases are placed in channels
 Developer
 Test
 Stable
Fits well with iterative process models (i.e. UP)
32 Daily Build
 each “iteration” of the construction phase is
laid out in a day
 at the end of every day, incompatibilities are
detected (sooner rather than later)
 uses a system of continuous integration
(automated testing at integration)
 A successful build allows overnight testing to
proceed, with test results reported in the
morning.

 Combining approaches: UP/Agile + Prototyping

+ Continuous delivery => more robust process
33
Can we integrate agile
practices into processes?
34 Can ANY process model be agile?

 Waterfall, V-model
 do not allow for early and continuous
delivery
 rely heavily on documentation and
approving it when moving between phases
 culture of contracts and sign-offs
 Sawtooth
 Provides earlier prototypes to clients
 Other principles are not respected
=> Linear process models do not work well with
agile practices
35
Iterative models
 Spiral and UP
 Allow frequent and continuous releases to
gather feedback
 Consistent with the Agile practices
36 Agile in context

Wider principles&practices
 Lean
 DevOps
Agile development methodologies
 Scrum
 Extreme programming
…
Management practice
 Kanban
37 Lean Software Design
 Inspired by the Toyota manufacturing industry
aimed to reduce waste in the production process
and increase the quality of their vehicles

 7 principles
1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver at fast as possible
5. Empower the team
6. Build quality in
7. See the whole
38 Applying lean principles to
software development
 Eliminate waste
 Unclear requirements, process bottlenecks,
product defects, and unnecessary meetings =>
waste of time and effort
 “busy” is NOT “productive”
 A busy team is not focused on developing code
 Additional features can interfere with code
functionality
 Code is useless if it is not planned to be released
=> Anything that does not add value to the product is
considered waste and should be identified and
eliminated
39 Amplify Learning

Explore all ideas sufficiently before

proceeding with actions
Do not settle on the first idea, generate as
diverse alternatives as possible
Run tests after each build, use failures as
opportunities to learn

⇒ Decide as late as possible

⇒ Eliminate waste
⇒ Deliver as fast as possible
40 Empower the team

“The best executive is one who has sense

enough to pick good people to do what he
wants done, and self-restraint enough to keep
from meddling with them while they do it”.
— Theodore Roosevelt

Managers listen to the developers

Developers decide how to make the
product
41 Related principles
 Build quality in (from the beginning)
 conduct reviews of the work products,
 prepare and run automated tests,
 refactor the code to simplify its design,
 provide useful documentation,
 give meaningful code comments.
⇒ Reduced time to fix defects => eliminated waste

 Needs focus on the end-user experience (See the

Whole)
 A quality product is cohesive and well
designed as a whole
42 Additional principles
 Use the Scientific Method
 Initiate experiments to collect data and test ideas
 Encourage Leadership
 Enable individual developers to be courageous,
innovative, inspirational, and collaborative.
 Warranty
 "Lean principles are warranted to be tried and proven in
many disciplines, and when properly applied, they are
warranted to work for software development.”
 Proper application:
 all of the lean principles are employed
 thinking tools are used to translate them into agile
practices appropriate for the environment.
 Mistakes:
 practices are transferred directly from other disciplines
or domains without adaptation
43 DevOps
 Term emerging from the collision of two major
related trends
 Agile/Lean
 Operations and Development engineers
working together in the entire service
lifecycle
 Devs
 Developers, QA, etc.
 Ops
 systems engineers, system admins,
operations staff, release engineers, DBAs,
network engineers, security professionals..
44 DevOps continued
 DevOps Practices
 continuous integration and continuous
deployment
 using configuration management, metrics and
monitoring schemes
 virtualization and cloud computing
 and more…
 DevOps tools
 release (Jenkins, Travis, Teamcity),
 configuration management (Puppet, Chef,
Ansible, Cfengine),
 orchestration (Zookeeper, Noah, Mesos),
 monitoring, virtualization and containerization
(AWS, OpenStack, Vagrant, Docker)
45 Primary practices
Infrastructure Automation – create your
systems, OS configurations, and app
deployments as code.

Continuous Delivery – build, test, deploy

your apps in a fast and automated manner.

Site Reliability Engineering – operate your

systems; monitoring and orchestration, but
also designing for operability in the first
place.
46 What is DevOps NOT

It’s Not NoOps

It’s Not (Just) Tools
It’s Not (Just) Culture
It’s Not (Just) Devs and Ops
It’s Not (Just) A Job Title
It’s Not Everything
47 DevOps and Continuous Delivery
48 How good is our software
delivery process?
DevOps Research and Assessment
(DORA) metrics
Development
Deployment frequency throughput

Lead time for changes

Change failure rate Service stability

Time to restore services

The power is in combining them!

49 DORA metrics

Deployment frequency
Number of individual changes deployed
over time
Lead time for changes
The time it takes to deploy completed
changes
Change failure rate
Proportion of deployed changes that
cause a failure on the running service
Time to restore services
The time it takes to fix a failure
experienced by a service
50 Define scope

 Looking at all the changes in the

organization or just those in your
program of work?
 Including infrastructure changes or
just those for software and
services?

The scope must be the same for all 4

metrics!
51 Process as a pipeline

zz
52 Process as a pipeline

zz
53 Where are your instrumentation
points?
Commit timestamp
Complexities: branching by
feature? Doing pull requests?
Proxy trigger = the merge to main
Deployment timestamp
when the pipeline doing the final
deployment to production
completes
Does it include smoke test or not?
54 Complexities
Where did the change-deployment
#264 originated?
What if a deployment aggregates a
number of changes?
55 Monitoring for service failures

Service failures
Too slow
Service down
Monitoring of service failures
Start time = opening a change
failure ticket
End time = closing the ticket
Number of tickets
56 Capturing and calculating the
4 metrics
Deployment frequency
Sum of deployments (on all
pipelines) over a time period (1 day)
Mean over 1 month
Lead time for changes
Mean per day of the lead times for
each change
Mean per month of the daily means
57 Capturing and calculating the
4 metrics
Change failure rate
the proportion of change failure
tickets resolved as a fraction of the
total number of deployments over
the same period
Ex. in a day you have 36
deployments and 2 change failures
resolved => 2/36
Look at this rate over 31 days
58 Capturing and calculating the
4 metrics
Change failure rate assumptions:
Failures are distinct
A single failure is caused by a single
deployment
Open failures are not included !
(because they are excluded from the
time to restore service, too!)
59 Capturing and calculating the
4 metrics
Time to restore service
Time for a change failure ticket from
open to closed
Mean or median time to restore?
Usually on longer time periods (ex.
120 days)
60 Minimum Viable Dashboard

The current calculated values of each of

the four key metrics
The definitions of each metric
The time periods across which we
calculate them
The historical values of the data
61 Deployment frequency
62 Lead time for changes
63 Change failure rate
64 Time to restore service
65 DORA performance levels

[Link]
66 Agile in name only (AINO)

Agile camouflage
 Meet briefly each morning for a stand-
up
 Refer to requirements as user stories,
although they look the same
 Divide the Gantt chart into 2-week
chunks and call them sprints
 At the end of each sprint, gather to
discuss what you have done, and what
you hope to do better
[Link]
67 Hand-offs between sub-teams

 Agile  Camouflage
 Teams operate as a unit  Teams operate as a
 Members are experts in collection of discrete sub-
one/more specialties but teams
have other abilities too  Architects design,
(T-shape) developers code, testers
 Swarm on work test, operators implement
(Musketeer approach) ⇒ Capacity is discrete
⇒ Capacity is fluid ⇒ Reduced efficiency
⇒ Accelerated learning ⇒ Iterations become
waterfall
⇒ Every person’s ownership
is temporary and
incomplete
68
Clairvoyant on future iteration
planning
 Agile  Camouflage
 About humility:  Slot user stories and
recognize that the specific milestones
future is hard to see for iterations
 Detailed agile occurring far into
planning happens the future
one iteration at a
time  Does not consider
 Detailed iteration the assumptions of
backlogs tend to discovery and
give way to general adaptation upon
features and high- which agile methods
level themes are built
69 Testimonials instead of demos
 Agile  Camouflage
 require that the  technical tasks
product owner masquerading as
accept user stories user stories.
before these are  decompose work in
considered fully terms of software
finished (after seeing configuration items,
a working demo) rather than user
 user stories represent capabilities
delivered business  At the end of the
value, not mere iteration it might be
technical activity nothing to be shown!
=> No feedback from
the product owner
70 Too big stories
 Agile  Camouflage
 employ a  take on stories that are
comprehensive too large to fit into a single
definition of done sprint
(including production  Break work into discrete
caliber testing) phases (development
⇒ Do not take credit for and testing), a story for
finishing a story that is each
partially done  Schedule the stories
⇒ Measure true velocity across multiple iterations
⇒ Avoid context switching ⇒ No fully qualified software
(going back to finish at the end of the iteration
undone body of work) ⇒ Disruptive rework on
development if testing
reveals problems
71
Retrospectives do not lead to
change

 Agile  Camouflage
 aim at the evolution of  hold retrospectives
processes and practices because, like stand-ups,
in response to observed retrospectives are one of
outcomes the obligatory
 Constructive reflection ceremonies
and follow-through on  end up discussing the
identified deficiencies same problem in the
 Retrospective catalyze same way across
actions multiple retrospectives,
because they aren't
doing anything about it
 Retrospectives are
therapeutic
72 Wrap-up

Discussed different classes of Process Models

 Linear
 Iterative
 Parallel
 Prototypes
 Continuous delivery
Agile practices can be integrated into
processes in different ways and applying
different management techniques
73 Quiz time

Please switch over to Moodle