Kristian Sandahl, IDA
krisa@ida.liu.se
Processes suitable for many projects
Kristian Sandahl, IDA
krisa@ida.liu.se
Detailed processes for teams and individuals
document
whiteboard
Processes adapted to a certain project or
product
Atomic
Worldly
The SLC is made up by:
Software life-cycle model
Activities
Kristian Sandahl, IDA
krisa@ida.liu.se
= time for concept -> time for “unavailability”
feed-back
out
side-effects
Universal:
in
resources
analysis design implementation
The software life-cycle
Feed-back
Resource consumption
Output
Input
decide
T
write SRS
X
M
V
Inspect
Entry
Task
Verify
Exit
Measure
SRS
# defects
Iterative model: “RUP”
Win-win spiral model
Spiral model
Incremental model
Waterfall model
Software life-cycle models
E
plan
Example:
itself
A process that exits
under certain criteria
Result: software items
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
ETVXM-architecture:
A process that verifies
Sequence of steps
Process levels
Kristian Sandahl
krs@ida.liu.se
Software processes
The effector process
Software process
1
resources
analysis &
planning
decision point
design &
implementation
Kristian Sandahl, IDA
krisa@ida.liu.se
calender time
One dynamic problem with the
waterfall model
Kristian Sandahl, IDA
krisa@ida.liu.se
Replacement
de Facto reference model
Requirements
forward engineering
Design
manageable
fixed documents
Implementation
frequent checks by SQA
Test
people
easy to understand good for
Installation
beginners
Operation
good for short projects < 12
weeks
Maintenance
Concept
exploration
Waterfall model
k
ac
-b
ed
e
f
Coding
Unit and
integration
testing
Implementation
Implementation
Implementation
Design
Design
Requirements
Design
Concept
exploration
Test
Test
Test
The release
planning
problem
Incremental model
Installation
Installation
Installation
Acceptance
testing
System
testing
Quality and process management
Program
design
System
design
Requirements
analysis
V-model
Kristian Sandahl, IDA
krisa@ida.liu.se
Rn
R2
R1
Kristian Sandahl, IDA
krisa@ida.liu.se
Downstream
activities
R8
dependsOn
legend
R11
R1
R3
R5
R2
R7
R4
R12
R10
R9
R13
R6
R14
Requirement dependencies
Does not mirror the reality
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Little room for problem solving and creativity
Late changes are practically not feasible
Many changes ⇒ large overhead costs
to become involved
Requires much experience from the customer
One-step delivery
Static problems with the waterfall
model
2
Concept
Test
(Rapid Application
exploration
Development)
Focus on feed-back
Design
Negative:
too early commitment Implementation
hard to obtain quality?
Sometimes called RAD
Prototypig
http://www.sei.cmu.edu/
cbs/spiral2000/
See:
Original goal: handle
risks
Involves early phases
in increments ⇒
the process is iterative
Design
Requirements
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Test
Implementation
The original spiral model
The MS way
Regression testing
Smoke tests
Usage-based verification
Dedicated use of ETVXM
Daily Build
Committed to formal specification
Frequent increment installation and test
Incremental method
Cleanroom process model
Incremental method
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
OpenUP/Basic
Idea: to always be prepared to deliver
Synchronise and Stabilise
See: http://www306.ibm.com/software/awdtools/rup/
RUP – Rational Unified Process
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
3
SCRUM
Source: www.methodsandtools.com/archive/scrum1.gif
See: http://www.extremeprogramming.org/
eXtreme Programming
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
available
Incremental
design
Stories
Code and Tests
Shared code
Root-cause
analysis
Shrinking teams
Team
continuity
Pay-per-use
Negotiated
scope contract
Daily
deployment
Single code
base
Kristian Sandahl, IDA
krisa@ida.liu.se
Kristian Sandahl, IDA
krisa@ida.liu.se
Output: calendar time for analysis & planning
implementation
Input: calendar time for design &
different numbers
Animate, simulate or just make a table of
the code
All results are free to use
Success #1: Linux
”Software culture”
Play with the dynamics of the waterfall model
An interested community voluntarily evolves
Kristian Sandahl, IDA
krisa@ida.liu.se
The code is published
From: Roginski & Zmuda: LiTH-IDA-Ex-06/014-SE
Weekly cycle
Continuous
integration
Test-first
programming
Energized work
Pair
programming
Ten-minute
build
Informative
workspace
Slack
Whole team
Incremental
deployment
Secondary praxis
Real customer
involvment
Quarterly cycle
Primary praxis
Sit together
Home assignment
Kristian Sandahl, IDA
krisa@ida.liu.se
tests before it can be
released
Acceptance tests are run
often and the score is
published.
Refactor whenever and
wherever possible
Leave optimisation till last
No overtime
All code must pass all unit
programmed
Code the unit test first
All production code is pair
The customer is always
XP 2005
Open source
Values:
Communication
Simplicity
Feed-back
Courage
Respect
User stories are written
Make frequent small
releases
Move people around
Choose a system metaphor
Create spike solutions to
reduce risk
Some XP-rules
4