Processes and LifeCycles
Kristian Sandahl
Maintenance
Validate Requirements, Verify Specification
Acceptance Test
Requirements
(Release testing)
Verify System Design
System Design
System Testing
(Architecture,
High-level Design)
(Integration testing of modules)
Module Design
(Program Design,
Detailed Design)
Verify Module Design
Module Testing
(Integration testing of units)
Verify Implementation
Implementation
of Units (classes, procedures,
functions)
Unit testing
Project Management, Software Quality Assurance (SQA), Supporting Tools, Education
2
Project Managment/Kristian Sandahl
SEPTEMBER 17, 2015
Remember the necessary parts of a project?
3
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
Processes are reoccurring
• Ordered set of activities
• May contain sub-processes
• Goal of each activity
• Each activity has entry/exit criteria and input/output
• Constraints
4
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
Remember our life-cycle model?...
Abstraction
Carol
the customer
Diana
the developer
Time
5
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
Maintenance
… also known as the V-model
Validate Requirements, Verify Specification
Requirements
6
Acceptance Test
(Release testing)
Verify System Design
System Design
(Architecture,
High-level Design)
System Testing
(Integration testing of modules)
Module Design
Verify Module Design
Module Testing
(Program Design,
Detailed Design)
(Integration testing of units)
Verify Implementation
Implementation
of Units (classes, procedures,
functions)
Time
Unit testing
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
7
Maintenance
Now, remove the abstraction level …
Validate Requirements, Verify Specification
Requirements
Acceptance Test
(Release testing)
Verify System Design
System Design
(Architecture,
High-level Design)
System Testing
(Integration testing of modules)
Module Design
Verify Module Design
Module Testing
(Program Design,
Detailed Design)
(Integration testing of units)
Verify Implementation
Implementation
of Units (classes, procedures,
functions)
Time
Unit testing
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
… and we got the waterfall model!
 One of the first lifecycle models
(Royce, 1970)
 The waterfall
development model
originates in the
manufacturing and
construction
industries
 Very common, very
criticized
8
The classical waterfall model
Requirements
Finish each phase before continue to next.
System Design
Module Design
Implementation
Unit
Testing
Module Testing
Milestone and deliverable at each
step. (Artifacts such as Design
document, Req. Specification. etc.).
Time
System Testing
Acceptance Test
Maintenance
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
Problems with the waterfall model
• Software requirements change, hard to sign-off on a SRS.
• Early commitment. Changes at the end, large impact.
• Feedback is needed to understand a phase. E.g.
implementation is needed to understand some design.
• Difficult to estimate time and cost for the phases.
• Handling risks is not an explicit part of the model. Pushes
the risks forward.
• Software "is not" developed in such a way. It evolves when
problems are more understood. Little room for problem
solving.
10
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
Advantages with the waterfall model
• Simple, manageable and easy to understand
• Fits to common project management practices
(milestones, deliverables etc.)
• Can be suitable for short projects (some weeks)
• Can be used at a large system level (several years)
• Can be suitable for "stable" projects, where requirements
do not change
• Focus on documents, saves knowledge which can be
reused by other people.
• Can be suitable for fixed-price contracts
11
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
12
Do it twice (Royce, 1970)
Requirements
System Design
Second round, do it
right.
Program Design
Implementation
First round, a
prototype
Unit
Testing
Module Testing
System Testing
Input to the
phases in the
second round
Acceptance Test
Maintenance
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
Iterative
and
methods
Incremental
13
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
14
Iterative development
When should the releases take place?
What should be included in the
release?
Prioritized functionality - Do the most
important parts first.
Time-boxing - The time period is fixed
for each iteration.
Customer Feedback
Customer Feedback
R1
R2
design
implementation
Iteration 1
Time
Iteration 2
3
test Iteration
deployment
Final Release!
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
Dependent project parameters revisited
Calendar time and
resources are
fixed
Calendar
Time
Resources
Project
Features
Select the most
important
functions
Select quality.
E.g. how general
should we
be?
Quality
15
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
Prioritization of requirements
Customer
Value
High
Sweet Spot
Low
Avoid
Low
High
Development Effort
16
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
17
Problems with iterative development

Problem with current business contracts, especially
fixed-price contracts.

With short iterations it can be hard to map customer
requirements to iterations.

Overhead added

Requirements selection problem
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
Advantages with iterative development
• Misunderstandings and inconsistency are made clear
early (e.g. between requirement, design, and
implementation)
• Encourage to use feedback -> elicit the real requirements
• Forced to focus on the most critical issues
• Continuous testing offers project assessment
• Workload is spread out over time (especially test)
• The team can get "lesson learned" and continuously
improve the process
• Stakeholders get concrete evidence of progress
18
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
19
Processes, models, methodologies…
Process Models
Waterfall
model
"what" at a high level
of abstaction
Prototype model
V- model
Spiral model
Which is the "best" approach?
agile
Extreme Programming (XP)
Rational Unified
Process (RUP)
Scrum
Methodologies
and defined
Processes
Kanban
"what" and to a certain
level "how"
Processes/Kristian Sandahl
SEPTEMBER 17, 2015
The Rational Unified Process (RUP)
• The Rational Unified Process (RUP) is an iterative
software development process framework
• Defined in 1997 by Grady Booch, Ivar Jacobson and
James Rumbaugh
• Recognized to be particularly applicable to large
projects with large teams
• Open/UP is a downsized method with agile
components
20
SEPTEMBER 17, 2015
Processes/Kristian Sandahl
RUP – Disciplines and Phases
Inception
Business Modeling
Core
Technical
Disciplines
Requirements
Analysis and Design
Implementation
Test
Deployment
Change & Config. Mgm.
Core
Supporting
Project Mgm.
Disciplines
Environment.
Elaboration Construction
Transition
21
www.liu.se