Chapter 14- tailoring the
process
4/13/2015
1
Overview


Introductory Remarks
14.1
14.1.1
14.1.2
14.1.3
14.1.4
14.1.5
14.1.6
14.2
4/13/2015
Process Discriminants
Scale
Stakeholder cohesion or contention
Process Flexibility or rigor
Process Maturity
Architectural Risk
Domain Experience
Example: Small Scale Vs Large Scale project
2
Introductory Remarks

The process framework must be configured to the specific
characteristics of the project

The Scale of the project (Team size ) drives the process
configuration more than any other factor

Other key factors include Stakeholder relationship, Process
flexibility, Process maturity, Architectural risk & domain experience.

While specific process implementations will vary but the spirit
underlying the process is the same
4/13/2015
3
Process Discriminants
In tailoring the management process to a specific
domain or project there are two dimensions of discrimination factors


Technical Complexity
Management complexity
4/13/2015
4
Higher technical Complexity
• Embedded,real-time,Distributed, FaultTolerant
• High-performance,Portable
Average software Project
• Unprecedented, architecture re-engineering
5 to 10 people
10 to 12 Months
3 to 5 external interfaces
Some unknown riks
Lower management Complexity
• Smaller scale
Higher management Complexity
• Large scale
• Contractual
• Informal
• Many stakeholders
• Few stakeholders
• Projects
•Products
Lower technical Complexity
• Straightforward automation, Single thread
• Interactive performance, Single platform
• Many precedent system, application re-engineering
The two primary dimensions of process variability
4/13/2015
5
Higher technical Complexity
• More domain experience required
• Longer inception & elaboration phase
• More iterations for risk management
• Less predictable costs & schedules
Lower management Complexity
• Less emphasis on risk management
Higher management Complexity
• More emphasis on risk management
• More process formality
• Less process formality
• More emphasis on teamwork
• More emphasis on individual skills
• Longer Inception & elaboration phases
• Longer production & transition phases
Lower technical Complexity
• More Emphasis on existing assets
• Shorter inception & elaboration phase
• fewer iterations for risk management
• More predictable costs & schedules
Priorities for tailoring the process framework
4/13/2015
6
Process Discriminants






A Project framework is not a project-specific process
implementation with a well-defined recipe for success
Methods, techniques, culture, formality & organization must be
tailored to the specific domain to achieve a process implementation that can
be succeed.
All the six parameters that effect the process exponent should be
considered when tailoring a process framework th create a practical process
implementation.
The six parameters are
Scale
Stakeholder cohesion or contention
Process flexibility or rigor
Process maturity
Architectural risk
Domain experience
4/13/2015
7
Process Discriminants
I Scale




The single most important factor in tailoring a software process
framework to the specific needs of a project is total scale of the software
application
The scale factor can be measured by
Source lines of code( SLOC )
Number of function points
Number of use cases
Number of dollars
From a process tailoring perspective the primary measure of the scale
is the size of the team. As the headcount increases the importance of
consistent interpersonal communication becomes paramount
4/13/2015
8
Process Discriminants
I Scale





Projects are categorized into
Trivial-sized projects( 1 people )requires almost no management overhead
Small projects ( 5 people )require very little management overhead but
team leadership toward a common objective is crucial
Moderate-sized projects( 25 people )require moderate management
overhead
Large projects( 125 people ) require substantial management overhead
Huge projects( 625 people )require management overhead
4/13/2015
9
Process Primitive
Life cycle phases
Smaller Team
Weak boundaries between
phases
Larger Team
Well-defined phases transitions to
synchronize progress among
concurrent Activities
Artifacts
Focus on technical artifacts
Change management of technical
Few discrete baselines
artifacts which may result in
Very few management
numerous baselines
artifacts required
Management artifacts important
Work effort
More need for generalists,
Higher percentage of specialists
allocations
people who performs roles
More people & teams focused on
in multiple workflows
a specific workflow
Many informal events for
A few formal events
maintaining technical
Synchronization among teams
consistency
which can take days
Checkpoints
No schedule description
Management
Informal planning, project
Formal planning, project control,
discipline
control, & organization
& organization
Automation
Most ad-hoc environment,
Infrastructure to ensure consistent
discipline
managed by individuals
Additional tool integration to support
4/13/2015
project control & change control
10
Process Discriminants
II Stakeholder contention & contention
The degree of cooperation & coordination among stakeholders
can significantly drive the specifics of how a process is defined
This process parameter can range from cohesive to adversarial
Cohesive teams have common goals, complementary skills & close
communications
Adversarial teams have conflicting goals, competing of incomplete
skills & less-than-open communications
4/13/2015
11
Process Primitive
Life cycle phases
Few Stakeholders,
Cohesive Teams
Multiple Stakeholders,
Adversarial Teams
Weak boundaries between
phases
Well-defined phases transitions to
synchronize progress among
concurrent Activities
Artifacts
Fewer & less detailed
Management artifacts paramount,
management artifacts
especially the business case,
required
Vision & status assessment
Work effort
Less overhead in
High assessment overhead to ensure
allocations
assessment
stakeholder concurrence
Checkpoints
Many informal events
3 or 4 formal events
Many informal technical walkthroughs
Synchronization among stakeholder teams
Management
Informal planning,project
Formal planning, project control,
discipline
control, & organization
& organization
Automation
( insignificant )
on-line stakeholder environment
discipline
4/13/2015
necessary
12
Process Discriminants
III Process flexibility or rigor
The degree of rigor formality & change freedom inherent in a specific
project’s contract will have a substantial impact on the implementation of
the project’s process.
For a loose contracts such as building a commercial product within a
business unit of a software company, management complexity will be
minimal
On the other hand, for a very rigorous contract it could take months
to authorize a change in a release schedule
4/13/2015
13
Process Primitive
Life cycle phases
Artifacts
Work effort
Flexible Process
Tolerant of cavalier phase
More credible basis required for
communications
inception phase commitments
Changeable business case
Carefully controlled changes
& vision
to business case & vision
( insignificant )
increased levels of management
allocations
Checkpoints
Management
& assessment workflow
Many informal events for
3 or 4 formal events
maintaining technical
Synchronization among stakeholder
consistency
teams
( insignificant)
More fidelity required for planning
discipline
Automation
Inflexible process
& project control
( insignificant)
( insignificant)
discipline
Process discriminators that result from differences in process flexibility
4/13/2015
14
Process Discriminants
IV Process maturity
The process maturity level of the development organization is
another key driver of management complexity.
Managing a mature process ( level 3 or higher ) is far simpler
than managing an immature process( level1 & 2).
Organizations with a mature process typically have a high level
of precedent experience in developing software & high level existing
process collateral that enables predictable planning & execution of
the process
4/13/2015
15
Process Primitive
Life cycle phases
Mature level 3 or 4
Well-establish criteria for
Level 1 Organization
( insignificant)
phase transition
Artifacts
Well-establish format,
Free-form
content & production
methods
Work effort
Well-establish basis
No basis
Well-defined combination
( insignificant)
allocations
Checkpoints
of formal & informal events
Management
Predictable planning
Informal planning & project
discipline
Objective status
control
Automation
Requires high levels of
discipline
automation for round-trip
engineering, change
Little automation or disconnect
islands of automation
management & process
instrumentation
Process discriminators that result from differences in process maturity
4/13/2015
16
Process Discriminants
V. Architectural Risk



The degree of technical feasibility demonstrated before
commitment to full-scale-production is an important dimension of
defining a specific project’s process
There are many sources of architecture risk such as
System performance
Robustness
System reliability
The degree to which these risks can be eliminated before
construction begins can have dramatic ramifications in the process
tailoring
4/13/2015
17
Process Primitive
Life cycle phases
Artifacts
Complete Architecture
Feasibility
demonstration
No architecture
Feasibility
demonstration
More inception & elaboration
Fewer early iterations
phase iteration
More construction iterations
Earlier breadth & depth
( insignificant )
across technical artifacts
Work effort
allocations
Higher level of design effort
Lower levels of
Higher levels of implementation to deal with increased
implementation & assessment
scrap & rework
More emphasis on executable
More emphasis on briefings,
demonstration
documents & simulation
( insignificant )
( insignificant )
Automation
More environment resources
Less environment demand
discipline
required earlier in the life cycle
early in the life cycle
Checkpoints
Management
discipline
Process discriminators that result from differences in architecture risk
4/13/2015
18
Process Discriminants
VI. Domain Experience
The development organization’s domain experience governs its
ability to converge on an acceptable architecture in a minimum
number of iterations.
Generally a skilled software organization building it’s first radar
application may require 4 or 5 prototype releases before converging
on an adequate baseline.
4/13/2015
19
Process Primitive
Experienced Team
Inexperienced tean
Life cycle phases
shorter engineering stage
Longer engineering stage
Artifacts
Less scrap & rework in
More scrap & rework in
requirement & design sets
requirement & design sets
Work effort
Lower levels of requirement
Higher levels of requirement
allocations
& design
& design
Checkpoints
( insignificant )
( insignificant )
Management
Less emphasis on risk
More-frequent status assess-
discipline
management
ment required
Less frequent status
assessments needed
Automation
( insignificant )
( insignificant )
discipline
Process discriminators that result from differences in domain experience
4/13/2015
20
Small scale Vs large-scale project
Engineering
Domain
Inception
Small
Elaboration
Production
Construction
Transition
10%
20%
50%
20%
15%
30%
40%
15%
Commercial
Project
Large,Complex
project
4/13/2015
21
Small scale Vs large-scale project
Differences in workflow priorities between small & large projects
Rank
Small commercial project
Large, complex project
1
Design
Management
2
Implementation
Design
3
Deployment
Requirements
4
Requirements
Assessment
5
Assessment
Environment
6
Management
Implementation
7
Environment
Deployment
4/13/2015
22
Artifacts
Small Commercial project
Large,Complex project
Work breakdown
1-page spreadsheet with 2
Financial management system with
structure
levels of WBS elements
5 or 6 levels of WBS elements
Business case
Spreadsheet & short memo
3-volume proposal including
technical volume, cost volume,
& related experience
Vision statement
10-page concept paper
200-page subsystem specification
Development plan
10-page plan
200-page development plan
Release specification
3 interim release
8 to 10 interim release
& No of release
specification
specification
Architecture
5 critical use case, 50 UML
25 critical use case,200 UML
description
diagram, 20 pages of text,
diagrams,100 pages of text,
other graphics
other graphics
Software
50,000 lines of VB code
300,000 lines of C++ code
Release description
10-page release notes
100-page summary
Deployment
use training course
sales rollout kit
Transition plan
Installation plan
User manual
On-line help & 100-page
200-page user manual
user manual
Status Assessment
Quarterly project reviews
Monthly project management
reviews
Difference in artifacts between small & large projects
4/13/2015
23