INF5180: Software Product- and

Process Improvement in Systems

Development
Part 07:
Processes and Process
Modeling
Dr. Dietmar Pfahl

email: dietmarp@[Link]

Spring 2008

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

What is a (Software Development) Process?

A Process …
• defines Who is doing What, When and How to reach a certain
goal.
– In software engineering the goal is to build a software product or to
enhance an existing one

An Effective Process …
• provides guidelines for efficient development of quality software
• reduces risk and increases predictability
• promotes common vision and culture

Page 2 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Impact
(source: Rombach)

Process Performance ≈ f (Process, Goals, Context)

can be determined by Product Availability and

-empirical study (measurement) and Quality of Resources
Project
can be estimated by related Familiarity with
- simulation Process and
Application
Domain

Page 3 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

A Process Taxonomy Software Processes

[Rombach & Verlage, 1995] Engineering Processes Non-Engineering Processes

Product-Engineering Process-Engineering Business Social

Processes Processes Processes Processes

Technical Managerial Improvement

Processes Processes Processes

Development Development Modeling and

Processes Processes (Re-)Planning Processes

Life-Cycles Measurement
Processes

Reuse
Processes

Page 4 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

What is a (Software) Process Model?

• “Software Process Model: An abstract software
process description. It can be more or less formal.”
[Lonchamp 93]
• Key elements:

Page 5 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

The Role Concept

• Role
– A role is in charge of one or more activities defined in
one or more processes
– A role has defined responsibilities
– Possible relationships between agents and roles
1:1
1:m
n:1
n:m
Page 6 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Role Responsibilities RASCI

Matrix
R = Responsible

Moderator
developer
Roles

assurer
Module

Quality
A = Approve

Tester
Activities S = Support
Module C = Consult
development
R
Module I = Inform
R
coding
Module
review S, R S A
Module
R I
testing

Page 7 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Characterization of Process Models

A Process Model defines:
[Link] Test (Host)
Customer Data
• an identifiable activity or a group of
Tools
activities
APS TSPA (from P3)

Test
Specification
Protocol
[Link] Data Upgrade
/ Tool-Upgrade
• a hierarchy of activities
Customer Data
• the control flow between activities
[Link] Test (Target) Data Delta

• the input/output products of activities

Conformance
Test Cases Regression
Test Cases
• the product flow
• the relations between activities and
techniques, methods, tools, and roles
Page 8 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

What are the Goals of Process Modeling?

• To enable effective understanding and • To support project management
communication – Transparency, tracking, ...
– At one development site (developers, teams,
...)
• To guide the developers
– Incorporating new employees
– Between development sites (distributed
development, outsourcing, contractor-supplier • To support reuse of process
relations, ...) knowledge
• To improve software development activities • To support automatic process
– Improving real processes requires enactment
measurement and measurement requires
– Workflow support
defined processes
– CASE tools
– Evolving processes

Page 9 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Descriptive vs. Prescriptive Process Models

[Link] Test (Host)
Customer Data
How is it done? Tools

APS TSPA(fromP3)
[Link] DataUpgrade
Test
Protocol / Tool-Upgrade
Specification

Customer Data

[Link] Test (Target) Data Delta

How should it be done?
Conformance
Test Cases Regression
Test Cases

Page 10 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Prescriptive vs. Descriptive Process Models

• Prescriptive Models (theoretical) • Descriptive Models (empirical)
– “Ideal” Process – Accurate elicitation of actual,
– (Assumed) best practice real processes
– Often requires instantiation and – Basis for the revision of existing
detailing (prescriptive) process models
– Deviations from real processes based on observation and
are likely experience
– Examples: waterfall, V-model,
spiral model, incremental,
iterative, evolutionary, agile
process models
Page 11 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Relationship between Descriptive & Prescriptive

Process Modeling
Process
enactment
Real world

Model world
Descriptive Prescriptive
process modeling process modeling

Description of the Process Description of

observed process analysis constraints and
guidelines for
the process enactment

Page 12 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Descriptive Process Modeling

Page 13 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Goals of Descriptive Process Modeling

• Understand the process • Support measurement
– Explicit documentation – Describe, who can measure
– Analyses (consistency, what and when
completeness, complexity) – Collect quantitative information
about processes, products and
• Communicate (about) the resources
process • Manage the process (and
– Find agreement in case of
conflicting opinions products)
– Propagation of ‘Best Practices’ – Define goals (target values) and
control the adherence to these
goals.
Page 14 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Steps of Descriptive Process Modeling

1. Formulate goals and scope of the task
2. Choose a conceptual schema (meta-model)
3. Choose a process modeling language / notation
4. Select or adapt tools
5. “Elicitation”
6. Create process model
7. Analyze process model
8. Analyze process

Page 15 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Elicitation • Structured interview, 1-2 Hours

Role 1 Role n • 2 interviewers

• Separated by roles
– no large groups
– clear focus
– manageable process models
– no mutual interaction
(horizontal and vertical
hierarchic relations)
Information Information • Perform interviews one after
another, however not more than
3 interviews per day

Process Page 16 Copyright 2008 © Dietmar Pfahl

model
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Example Form for Structured Interview

Scope
Project
Project, process name, role
Activity Name
Integration-Test (Target)
Responsibility
PL

Input Products Entry Criteria

- TSPA
- Customer Data (by Customer Data Delta)
- Possibly Integration Test (Host)
- Input complete
Input products and
- APS - Hardware available
- Conformance Test Cases
- Regression Test Cases
- APS and Customer Data loaded
- Test time available
entry conditions
Activity Description

- Conduct Integration Test on target according to TSPA

Case A: Old Features (upgrade):
- Regression Test (Tool: A8619 (PORIS) for SSW / USR for ASW)
- Possibly, update of TSPA Test Cases
Case B: New Features:
- Manually conducted TSPA Test Cases
- Recorded with A8619 (Poris) for SSW / USR for ASW
Description of the process/activity
- Conduct Conformance Test according to Standards with test tool K1197
- Defect correction

Output Products Exit Criteria

- Test Protocol (Part of TSPA) - Feature runs correctly on host
- Regression Test Cases (updated) - No more test time available (Rem. by QM: this
criterium is not permitted!!)
Output products
and exit conditions
Resources Page 17 Copyright 2008 © Dietmar Pfahl
- Developers
- Support team of TK Systems etc.
- A8619 (PORIS)
- USR für ASW
- K1197
- TK Systems
- CSTA Test tool
- CSTA-Spy
Resources

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Rules for Process Elicitation (1/3)

• Obtain information about
– the organization
– the software domain
• Analyze existing documents and products
• Observe the relation between developers and quality assurance
• Ask whether an ongoing or upcoming organizational restructuring
impacts the process
• Make sure that the interview partner is selected according to your
instructions / guidelines
• Begin the interviews with a quality manager or project manager

Page 18 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Rules for Process Elicitation (2/3)

• Opening of Interview • Main part of Interview
– Summary – Behave neutral
– Explain goal and purpose – At first ask about the products
– Stress confidentiality – Then ask about processes
– General questions about the – What are typical (known)
process, and existence of deviations from the prescribed
variants processes?
– Which other roles participate in
the processes? (Cross-Check)
– Always be precise
– Try to identify process variants

Page 19 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Rules for Process Elicitation (3/3)

• Closing of Interview • Ask questions even when a noticed
ambiguity seems to be small, often
– Explain future steps big problems are hidden behind it
– Agree on time for the review
• Don't try to solve all ambiguities and
– Thank your interview partner
conflicts (during the interview) – but
follow-up on observed
inconsistencies afterwards
• After the interview: give a quick
feedback to the interview-partner
about what you did with his/her
information

Page 20 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Analysis
• The number of products is higher
(approx. twice as high) than the
number of processes.
• The complexity of product flow
interfaces of processes is relatively
high (most of the processes access
more then a dozen of products).
• Most of processes are undertaken by
several roles (partly over five roles).
• Most of roles are involved in
execution of more then a third of the
whole process.
30 Processes
Page 21 Copyright 2008 © Dietmar Pfahl
66 Products
42 Resources process

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Modeling Tools

• Commercial tools not dedicated to process
modeling
– E.g. ABC Flowcharter, Microsoft Visio,
Statemate
• Workflow Management Systems
– E.g. ARIS Toolset (event-process chains)
• Research prototypes
– E.g., Spearmint

Page 22 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Example SPM Tool SpearmintTM

• SPEARMINTTM – Software Process Elicitation,
Analysis, Review, and Management in an
inTegrated Environment
• Assists a process engineer in creating and
maintaining complex process models.
• Allows for efficient modeling of different views of the
process model
• Generates EPG (Electronic Process Guide)
Page 23 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Views
view
view
view

Spearmint supports efficient

modeling by supporting different
views view

Entire process
view
model

• A view is a part of the process model

– Spearmint describes not the whole process, but only parts of it in pre-defined and
user-defined views.

• A view highlights certain aspects

– Working with views reduces the complexity of the process model.
– Only those aspects of a model are contained, which are relevant for specific tasks.

• SPEARMINT checks consistency of all views

– Process elements in a certain view always reference to the whole process model.

Page 24 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Views Properties and Attributes views

Artifacts view

Activities view

Page 25 Copyright 2008 © Dietmar Pfahl

Process view

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Product-Flow View

Refinement

Page 26 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Control-Flow View
Join/Split symbols:
AND (x), OR (+), XOR(⊕)
nil (empty).

Page 27 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process View

Page 28 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Attributes View

Page 29 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Generation of Hypertext View (EPG)

Process-engineer

(e.g. developer)
Process-user

Feedback, e.g. via

annotations
Page 30 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Hypertext-View (EPG)

Page 31 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Consistency Checking
• Process models should be complete and
correct representations of reality.
• Consistency checking has been partly
automated in SPEARMINT.
• Methodological prerequisites:
– Process meta-model
– Consistency rules

Page 32 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Prescriptive Process Modeling

Page 33 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Overview: Pre-defined process

models like Scrum, EVO,
Process models exist on
3 levels:
Prescriptive
RUP, XP, Cleanroom...
family/standard level,
organizational level,
Process Models Inspires
and project level
Generic Process
model

Project (type) 1 Project (type) n

process model Project (type) 2 process model
process model

Page 34 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

An Example Process: The Waterfall Model

Require- Analyse
• The most basic sequence of activities
ments
Design
needed to develop sizable software
Implement

Integrate

System test
Product

– Well tried, well documented model

– Well suited to successive breakdown
– Is simple to manage
– Requires stability
– Requires careful analysis and planning
– Results in ”big-bang integration”

Page 35 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Early Waterfall Model (1956)

(Ref: Boehm, ICSE 2006 keynote)
OPERATIONAL PLAN

MACHINE SPECIFICATIONS OPERATIONAL SPECIFICATIONS

PROGRAM SPECIFICATIONS

CODING SPECIFICATIONS
The SAGE
Software CODING

Development PARAMETER TESTING (SPECIFICATIONS)

Process
(Benington, 1956) ASSEMBLY TESTING (SPECIFICATIONS)

SHAKEDOWN

Page 36 Copyright 2008 © Dietmar Pfahl

SYSTEM EVALUATION
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Waterfall: Royce Model (1970) Prerequisites:

Familiarity with
SYSTEM
application domains,
REQUIREMENTS methods, techniques,
Idea: tools, engineering
SOFTWARE
Sequential creation of REQUIREMENTS processes
products on different Good understanding of
PRELIMINARY
levels of abstraction (e.g., PROGRAM the requirements
DESIGN
precede code by design, Stable requirements
precede design by ANALYSIS
High capabilities for
requirements) and effort estimation
integration in reverse PROGRAM
DESIGN
direction
PRELIMINARY
Strictly sequential control DESIGN
CODING
flow can be weakened by ANALYSIS

controlled iterations PROGRAM

DESIGN TESTING

CODING

Page 37 Copyright 2008 © Dietmar Pfahl

TESTING OPERATIONS

USAGE

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

The Waterfall Isn’t Dead Yet!

• It is still a good approach for projects
with
– Well defined requirements
– Possibly inexperienced developers
– Known development environment
– Small project size

• It is often used for small maintenance

tasks, for example
Page 38 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Often Waterfall is Bad

• For many projects, the waterfall – Adversarial stakeholder
model is a poor choice relationships
• written definitions of requirements
– Late risk resolution often lead to extended (and
• can’t tell requirements or design heated) discussion of their
risks exist until late in the life cycle interpretation
– Requirements drive functional – Focus on documents and reviews
decomposition • fulfilling the letter of a contract can
• exhaustive requirements make it lead to the appearance of
hard to tell if the design is viable; progress, but without real
• hard to identify critical communication
requirements – Inflexible!

Page 39 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Code and Fix – An Evolutionary Model

• Provides maximum flexibility
• Has low complexity
• Good model for prototyping
But:
• Yields low quality
• Yields bad maintainability

Code Test Deliver

Page 40 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Exercise: • Alternative model to “Code & Fix”

Code
Requirements Deliver

Test

• What are the advantages compared to

”code and fix” on previous slide?
• Disadvantages?

Page 41 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Fixing the Waterfall Model

„ Customer Involvement Æ
Prototypes
„ Iterations Æ Risk Focus
„ Increments Æ Staged Delivery
„ Tailoring

Page 42 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

From Waterfall to V-Model

Acceptance
Requirements
Engineering

System
Requirements
Testing
Analysis

Integration
System Design Testing

Unit
Object Testing
Design
Implemen-
tation

adapted from [Royce 1970] Unit

Testing

Page 43 Integration Copyright 2008 © Dietmar Pfahl

Testing

System
Testing

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

System
Requirements
Is validated by Operation
Analysis

precedes
Software
Requirements Client
Elicitation Acceptance

System
Requirements Integration
Analysis & Test

Component
Preliminary Integration
Design & Test

Problem with the V-Model:

Detailed Unit
Assumption that
Design Test
Developer Perception =
Page 44 User Perception
Copyright 2008 © Dietmar Pfahl

Implementation
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Sawtooth Model
Client

Requirements Prototype Prototype Client

Elicitation Demonstration 1 Demonstration 2 Acceptance

Developer
System
Integration
& Test

Requirements
Analysis Integration
& Test

System
Design

Object Unit Test

Design
Page 45 Copyright 2008 © Dietmar Pfahl

Implementation

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Sharktooth Model
Client

System Prototype Prototype

Requirements Client
Elicitation Demo 1 Demo 2 Acceptance

Manager
Design System
Review Integration
& Test

Developer
Requirements
Analysis Component
Integration
& Test

System
Design

Unit
Object Test
Design

Page 46 Copyright 2008 © Dietmar Pfahl

Implementation
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Prototyping: Overview
• Idea:
– Concentration on the development of an executable version of the system that
fulfills a limited number of requirements
– User interfaces are often simplified or performance requirements are reduced
– A primary goal is to collect experiences from first prototypes (e.g., regarding unclear
requirements, difficult design aspects)
– Getting first versions of the final product is usually not a goal
– Prototyping follows other process models

• Prerequisites:
– High level of experience with the used development techniques
– Technical infrastructure for prototype creation must be available

Page 47 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Prototyping
Advantages Disadvantages
• Can be applied without having yet a clear idea of (all) • Risk that “side effects“ are
the properties of the final product not sufficiently considered
– especially non-functional
• Misunderstandings between developer and customer requirements such as
can be detected early (and thus mitigated) reliability or safety
• Inconsistent requirements are (somewhat) earlier to • Risk that customer considers
detect prototype as first version of
• Comprehensive version & configuration management is the system that will be
not necessary (Æ prototype should be thrown away) evolved
– prototype should NOT be
• Risk of project failure is reduced (e.g., developing a seen as a first version of
product that does not satisfy the customer expectations) the system
• In some cases, prototypes are suitable for evaluating
business models

Page 48 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Problems with V Model

• The V model and its
variants do not
distinguish temporal and
logical dependencies
between requirements
• In particular, the V
model does not
accommodate
incremental
development and
iteration
Page 49 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Spiral Model Æ Highly Iterative

• The spiral model proposed by Boehm (1988) is an iterative model with
focus on risk resolution:
– Determine objectives and constraints
– Evaluate Alternatives
– Identify risks
– Resolve risks after assigning priorities to risks
– Develop a series of prototypes for the identified risks starting with the
highest risk
– Use a waterfall model for each prototype development (“cycle”)
– If a risk has successfully been resolved, evaluate the results of the “cycle”
and plan the next round
– If a certain risk cannot be resolved, terminate the project immediately
Page 50 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Boehm’s Spiral Model

Project
Project
Start
Start

Page 51 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Activities & Cycles in Boehm’s Spiral Model

• Concept of Operation • For each cycle go through these activities
• Software Requirements – Quadrant IV: Define objectives, alternatives,
constraints
• Software Product Design – Quadrant I: Evaluate alternatives, identify and
resolve risks
• Detailed Design
– Quadrant II: Develop, verify prototype
• Code – Quadrant III: Plan next “cycle”
• Unit Test
• Integration and Test • The first 3 cycles are shown in a polar coordinate
system.
• Acceptance Test – The polar coordinates r = (l, a) of a point indicate the
resource spent in the project and the type of activity
• Implementation

Page 52 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Types of Prototypes used in the Spiral Model

• Illustrative Prototype
– Develop the user interface with a set of storyboards
– Implement them on a napkin or with a user interface builder (Visual C++, ....)
– Good for first dialog with client
• Functional Prototype
– Implement and deliver an operational system with minimum functionality
– Then add more functionality
– Order identified by risk
• Exploratory Prototype ("Hacking")
– Implement part of the system to learn more about the requirements.
– Good for situations in which paradigm discontinuities occur
Page 53 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Limitations of the Waterfall and Spiral Models

• Neither of these model deals well with frequent
change
– The Waterfall model assume that once you are done
with a phase, all issues covered in that phase are closed
and cannot be reopened
– The Spiral model can deal with change between
phases, but once inside a phase, no change is allowed

• What do you do if change is happening more

frequently? (“The only constant is the change”)

Page 54 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Iterative Enhancement: Overview

• Origin: Basili und Turner, 1975
• Idea:
– Develop each increment (i.e., a product part that fulfills a subset of
requirements) in a Waterfall style; integrate increment by increment into the
product until delivery
– The focus of the development of an increment might be completion of
functionality or structure, but it can also be refinement and improvement
– Strictly sequential control flow can be weakened by controlled iterations
• Prerequisites:
– Structure of the problem permits incremental development

Page 55 Copyright 2008 © Dietmar Pfahl

Problem Used
description
INF5180 – Spring 2008 system
Part 07: Processes and Process Modeling

Customer Usable
requirements system

Developer Ausführbares
Executable
requirements System
system

System
design

Unit Executable
requirements units

Unit
design

Unit
Page 56 Copyright 2008 © Dietmar Pfahl

code

Iterative Enhancement Model (Ref: Rombach)

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Iterative Enhancement (or Incremental Development)

Advantages: Disadvantages:
• Efficient learning during the project; thus, • Risk that, by ignoring specific
experience level can be low requirements, the product will be
• Early availability of a product, with the essential designed in such a way that
properties of the final product. fulfilling future requirements
becomes difficult/expensive
• Allows for early customer involvement and
feedback – particularly problematic are non-
functional requirements
• Applicable when parts of requirements are
unclear or unstable • Comprehensive version and
configuration management is
• Supports integration testing
necessary
• Good applicability in case of fixed delivery dates
(Æ prioritize requirements with the customer)
Page 57 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Unified Process
• Family: Iterative Enhancement • Characteristics:
– use case driven
• Origin:
– architecture-centric
– Ivar Jacobson, James
Rumbaugh, Grady Booch, 1998 • Provides only rudimentary
instructions
• Defines process framework
• Refined version:
that is adaptable to
– Rational Unified Process (Ph.
– various application domains Kruchten)
– different organizations
– different competence levels
– different project sizes

Page 58 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Rational Unified Process

Process Workflows Phases
Inception Elaboration Construction Transition

Business modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Change & Configuration Mgmt
Project Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
Page 59 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

MSF (Microsoft Solution Framework)

Process View

Page 60 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

MSF-Inspired Process Model

Page 61 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Iterative Process Models Properties

Sequential (waterfall) process model

Level of influence
Cost of changes

Customer
involvement
Management
involvement

Plan /Analyse Phase_1 Phase_2 ..... Phase_n Delivery

Page 62 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Iterative Process Models Properties

Highly iterative process model

Level of influence
Cost of changes

Customer
involvement
Management
involvement

Plan /Analyse Iteration_1 Iteration_2 ..... Iteration_n Delivery

Page 63 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Process Standards

Page 64 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

DOD Standard 2167A

• Required by the Department of Defense for all software
contractors in the 1980-90s
• Waterfall-based model with the software development
activities
– System Requirements Analysis/Design
– Software Requirements Analysis
– Preliminary Design and Detailed Design
– Coding and CSU testing (CSU = Computer Software Unit)
– CSC Integration and Testing (CSC = Computer Software
Component, can be decomposed into CSC's and CSU's)
– CSCI Testing (CSCI = Computer Software Configuration Item)
– System integration and Testing
Page 65 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

ISO 12207: Standard for Information Technology-

Software Life Cycle Processes
• This standard officially replaced MIL-STD-498 for the development of DoD
software systems in August 1998.
• This standard defines a comprehensive set of processes that cover the entire life-
cycle of a software system — from the time a concept is made to the retirement
of the software.
• The standard defines a set of processes, which are in turn defined in terms of
activities. The activities are broken down into a set of tasks.
• The processes are defined in three broad categories — Primary Life Cycle
Processes, Supporting Life Cycle Processes and Organisational Life Cycle
Processes.
Page 66 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

ISO 12207 Processes

• Primary life cycle • Supporting life cycle • Organisational
processes: processes: processes:
– Acquisition process – Audit process – Management process
– Supply process – Configuration – Infrastructure process
– Development Management – Improvement process
process – Joint review process – Training process
– Operation process – Documentation process
– Maintenance – Quality assurance process
process – Problem solving process
– Verification process
– Validation process
Page 67 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Modell® XT (XT = Extreme Tailoring)

• Published in January 2005
• Predecessor: V-Model (1997) for military authorities in Germany
• Structured in a modular way
• Mandatory for IT projects in public and military domains in Germany
• Goals:
– Enhance support for adaptability, scaleability, changeability, and
expandability of V-Model 97
– Consider state of the art and adapt to current regulations and standards
– Expand application range considering the complete system lifecycle of
development projects
– Introduce a process of organizational process improvement

Page 68 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model XT – Purpose and Scope

• The V-Model XT is a guideline for the Planning and Management of
IT Development Projects.
• Scope of the V-Model are:
– Improvement of Planning and Tracking of IT Development Projects,
– Minimization of Project Risks,
– Improvement and Quality Assurance,
– Improvement of Communication between Project Stakeholders,
– Containment of Total Costs over the Project and System Life Cycle.
• The V-Model supports different Project Execution Strategies and the
Concept of Decision Points.
• The V-Model can be tailored according to the specific conditions and
needs of an ICT Project
• The V-Model addresses the Customer and the Contractor.
Page 69 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Customer vs. Contractor View

Customer Decision Points
1 2 3 4 5 6 8
Project Project Requirements Project Project Tested for Project
approved defined established put out to tender contracted Acceptance closed

Change Plan
established
7

12
Change Plan
established
1 2 3 4 11 13
Project Offer Project Project Acceptance Project
approved tendered contracted defined declared closed
System Delivery
5 specified performed 10
Auftragnehmer
Contractor
System System
6 70
Page drafted integrated 9 Copyright 2008 © Dietmar Pfahl

Detailed Design Systemelements

7 completed realised 8
 INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model: The Big Picture

The V-Model compises
four sub-models:
System Development (SD)
Quality Assurance (QA)
Configuration Management (CM)
Project Management (PM)

Page 71 Copyright 2008 © Dietmar Pfahl

Kapitel 4.2

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model:
Project
Management (PM)
Sub-Model
Activity Types:
• Management-related
– Initialization/Finalization
– Periodically Required
• Placement/Procurement-related
• Planning-related
• Resource-related
Page 72 Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model: “Handling”
Project (Refinement)
Management (PM)
Sub-Model

PM1:
Project
Initialization

Page 73 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model:
System
Development (SD)
Sub-Model

Page 74 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model:
System
Development (SD)
Sub-Model

SD2:
System
Design

Page 75 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

V-Model:
System
Development (SD)
Sub-Model

SD2:
System
Design
“Handling”
Page 76 (Refinement)
Copyright 2008 © Dietmar Pfahl
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

IEEE Std 1074

• Institutional standard (‘least common
denominator’) published in 1997
• Process description comparable with V-
Modell® XT (on a high level), but no
statements about products, roles
• Offers only little guidance for developers

Page 77 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

IEEE Std 1074: Standard for Software Lifecycle

Page 78 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

”Light-Weight” Processes
(Evolutionary Development)

Page 79 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Requirements and Customers

Page 80 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

The Agile Manifesto

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
[Link]

Page 81 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme Programming
• Origin: Kent Beck, Ward Cunningham, Ron Jeffries (end of 1990s)
• Idea: “light weight” process model, agile process
• Characteristic:
– “Minimum” of accompanying measures (documentation, modeling , …)
– Team orientation (e.g., common responsibility for all development artifacts)
– Small teams (12-14 persons)
– Involvement of user/client at an early stage
– Social orientation
• Scope: Prototype projects, small projects, low criticality of the results

Page 82 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme Planning
Programming:
Overview
1. User stories (something like use cases) are
written by the customer.
2. Complex stories are broken down into Iterative Phase
simpler ones (like a WBS).
3. Stories are used to estimate the required
amount of work.
4. Stories are used to create acceptance
tests.
5. A release plan is devised that determines
which stories will be available in which
release.
6. Don’t hesitate to
change what doesn’t work. [Link]

Page 83 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme
Programming:
Planning
1. Each release is preceded by
a release planning
meeting.
2. Each day begins with a
stand-up meeting to share
problems and concerns.
3. CRC cards are used for
design. [XP and CRC were
created by the same person,
Kent Beck.]
4. Spike solutions are done to
assess risks.
5. The customer is always
available.

Page 84 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme
Programming:
Iterative Phase
1. All code must pass unit tests,
which are coded before the
code being tested (test-driven
design).
2. Refactoring is done
constantly.
3. Integration is done by one
pair.
4. Integration is done frequently.
5. Optimization is done last.

6. Acceptance tests are run

often.
Page 85 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Extreme Programming – Evolutionary Process Model

Page 86 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Mobile-D
Defined by VTT for the
mobile phone industry in
Finland

Page 87 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Scrum

Page 88 Copyright 2008 © Dietmar Pfahl

[Link]
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Scrum Iterations and Sprints

Page 89 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Scrum Sprint Backlog - Example

Page 90 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Scrum Burndown Chart - Example

Core Sprint 16 Burndow n
Est imat ed Ho ur s R emaining

400

350

300

250 Estimates
Linear
200
Support Time

150 Max Support Time

100

50

25.09.2006 26.09.2006 27.09.2006 28.09.2006 29.09.2006 02.10.2006 03.10.2006 04.10.2006 05.10.2006 06.10.2006

Page 91 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Choosing the Right Process Model

Page 92 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Difficult to Choose Process Model

• What you should first decide is whether you actually need
a prescriptive process model. Wholeheartedly!
• To make the choice it is important to know your
organization/project.
– What characteristics are we going to look for?
– What is it that means most for choice of process model?
Main process model categories: – Can we use the same model everywhere, or do we need
variants (a repertoire of different models)?
Waterfall Incremental Iterative/evolutionary
(sequences) (dividing) (repeating)

Page 93 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

How Much Structure?

Hohmann: Process discipline
Low High
Formalism on the product
LITTLE STRUCTURE

MUCH STRUCTURE

Low Strict
Communication
Informal Formal
Number of check points
Few Many
Experience
Much Little

Page 94 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

How Much Structure? Size (organization)

Hohmann: Small Big
Size (product)

MUCH STRUCTURE
LITTLE STRUCTURE
Small Big
Age (team)
High Low
Problem complexity
Little Big
Demand for precision
Little Big
Project length
Short Long
Page 95 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Alistair Cockburn
• One of the initiators behind The Agile Alliance
• Known for the books Writing effective Use-cases and Agile Software
Development
• Has published a series of articles about Object orientation, Use-cases and
”human-oriented methods”.
• Started the company Humans and Technology where he now works as
consultant.
• Quotation from article in Crosstalk, October 2002*:
– Being agile is a declaration of prioritizing for project maneuverability with
respect to shifting requirements, shifting technology, and a shifting
understanding of the situation. Other priorities that might override agility include
predictability, cost, schedule, process-accreditation, or use of specific tools.

Page 96 Copyright 2008 © Dietmar Pfahl

*) [Link]
INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Alistair Cockburn - tradeoffs

• Different projects need different methodology trade-offs.
• A light methodology does a lot of good; after all, weight is costly.
• Larger teams need more communication elements.
• Projects with greater potential damage risk need more validation elements.
• Formality, process, and documentation are not substitutes for discipline, skill, and
understanding.
• Interactive, face-to-face communication is the cheapest and fastest channel for exchanging
information.
• Increased communication and feedback reduce the need for intermediate work products.
• Concurrent and serial development exchange development cost for speed and flexibility.
• Efficiency is expendable in non-bottleneck activities.
• Sweet spots speed up development.

Page 97 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

AC – Localising ”sweet-spot”
Planning is ”bad” and should be minimized

Too little Too much

planning planning

Page 98 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

AC – Project categorizing
“Any one
methodology is likely
to be appropriate for
only one of the boxes it y
gil
on one of the planes. ofA
e
Thus, at least 150 or gre
De
so methodologies
are needed!”

Page 99 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

Adjustments Based on ”skills”

”Formalism, Process and

Documentation can not
replace discipline,
competency and
understanding”

Page 100 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

How much Agility is Recommended?

• Source: Boehm, B.; Turner, R.; Observations on balancing discipline and agility,
Proceedings of the Agile Development Conference, 2003. ADC 2003. Page(s):32 - 39

Page 101 Copyright 2008 © Dietmar Pfahl

INF5180 – Spring 2008 Part 07: Processes and Process Modeling

What is Coming Next?

• The selection of (more or less) well-defined process
models is a big issue!
• The most important parameters influencing the process
choice are project size and criticality, but also the other
factors mentioned by Cockburn and Boehm are worth
taking into consideration.
• The desire to introduce new, modern process models is
increasing in industry; the believe that the ”Silver Bullet”
has finally been found is spreading (once again).
• Question: What happened to the wish for stability? Isn’t it
possible to be too change-willing? Change results in
restructuring (”rework”), doesn't it?
Page 102 Copyright 2008 © Dietmar Pfahl

See Iterative and Incremental Development: A Brief History by

Craig Larman and Vic. Basili (IEEE Computer June 2003)