Chapter 14- tailoring the

process

02/15/23 1
 Overview
 Introductory Remarks

 14.1 Process Discriminants

14.1.1 Scale
14.1.2 Stakeholder cohesion or contention
14.1.3 Process Flexibility or rigor
14.1.4 Process Maturity
14.1.5 Architectural Risk
14.1.6 Domain Experience

14.2 Example: Small Scale Vs Large Scale project

02/15/23 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

02/15/23 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

02/15/23 4
 Higher technical Complexity
• Embedded,real-time,Distributed, Fault-
Tolerant
• High-performance,Portable
• Unprecedented, architecture re-engineering
Average software Project
5 to 10 people
10 to 12 Months
3 to 5 external interfaces
Some unknown riks

Higher management Complexity

Lower management Complexity
• Large scale
• Smaller 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

02/15/23 5
 Higher technical Complexity
• More domain experience required
• Longer inception & elaboration phase
• More iterations for risk management
• Less predictable costs & schedules

Lower management Complexity Higher management Complexity

• More emphasis on risk management
• Less 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

02/15/23 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

02/15/23 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

02/15/23 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

02/15/23 9
Process Primitive Smaller Team
Life cycle phases Weak boundaries between
phases
Artifacts Focus on technical artifacts
Few discrete baselines
Very few management
artifacts required
Work effort More need for generalists,
allocations people who performs roles
in multiple workflows
Checkpoints Many informal events for
maintaining technical
consistency
No schedule description
Management Informal planning, project
discipline control, & organization
Automation Most ad-hoc environment,
discipline managed by individuals
02/15/23
Larger Team
Well-defined phases transitions to
synchronize progress among
concurrent Activities
Change management of technical
artifacts which may result in
numerous baselines
Management artifacts important
Higher percentage of specialists
More people & teams focused on
a specific workflow
A few formal events
Synchronization among teams
which can take days
Formal planning, project control,
& organization
Infrastructure to ensure consistent
Additional tool integration to support
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

02/15/23 11
Process Primitive Few Stakeholders, Multiple Stakeholders,
Cohesive Teams Adversarial Teams

Life cycle phases Weak boundaries between Well-defined phases transitions to

phases 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 necessary

02/15/23 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

02/15/23 13
Process Primitive Flexible Process Inflexible process

Life cycle phases Tolerant of cavalier phase More credible basis required for
communications inception phase commitments

Artifacts Changeable business case Carefully controlled changes

& vision to business case & vision
Work effort ( insignificant ) increased levels of management
allocations & assessment workflow

Checkpoints Many informal events for 3 or 4 formal events

maintaining technical Synchronization among stakeholder
consistency teams
Management ( insignificant) More fidelity required for planning
discipline & project control
Automation ( insignificant) ( insignificant)
discipline

Process discriminators that result from differences in process flexibility

02/15/23 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

02/15/23 15
Process Primitive Mature level 3 or 4 Level 1 Organization

Life cycle phases Well-establish criteria for ( insignificant)

phase transition

Artifacts Well-establish format, Free-form

content & production
methods
Work effort Well-establish basis No basis
allocations
Checkpoints Well-defined combination ( insignificant)
of formal & informal events
Management Predictable planning Informal planning & project
discipline Objective status control
Automation Requires high levels of
discipline automation for round-trip Little automation or disconnect
engineering, change islands of automation
management & process
instrumentation
Process discriminators that result from differences in process maturity
02/15/23 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

02/15/23 17
Process Primitive Complete Architecture No architecture
Feasibility Feasibility
demonstration demonstration

Life cycle phases More inception & elaboration Fewer early iterations
phase iteration More construction iterations
Artifacts Earlier breadth & depth ( insignificant )
across technical artifacts
Work effort Higher level of design effort Higher levels of implement-
allocations Lower levels of ation to deal with increased
implementation & assessment scrap & rework
Checkpoints More emphasis on executable More emphasis on briefings,
demonstration documents & simulation
Management ( insignificant ) ( insignificant )
discipline
Automation More environment resources Less environment demand
discipline required earlier in the life cycle early in the life cycle

Process discriminators that result from differences in architecture risk

02/15/23 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.

02/15/23 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

02/15/23 20
 Small scale Vs large-scale project

Engineering Production
Domain Inception Elaboration Construction Transition

Small 10% 20% 50% 20%

Commercial
Project

Large,Complex 15% 30% 40% 15%

project

02/15/23 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

02/15/23 22
Artifacts Small Commercial project
Work breakdown 1-page spreadsheet with 2
structure levels of WBS elements
Business case Spreadsheet & short memo
Vision statement 10-page concept paper
Development plan 10-page plan
Release specification 3 interim release
& No of release specification
Architecture 5 critical use case, 50 UML
description diagram, 20 pages of text,
other graphics
Software 50,000 lines of VB code
Release description 10-page release notes
Deployment use training course
sales rollout kit
User manual On-line help & 100-page
user manual
Status Assessment Quarterly project reviews
Difference in artifacts between small & large projects
02/15/23
Large,Complex project
Financial management system with
5 or 6 levels of WBS elements
3-volume proposal including
technical volume, cost volume,
& related experience
200-page subsystem specification
200-page development plan
8 to 10 interim release
specification
25 critical use case,200 UML
diagrams,100 pages of text,
other graphics
300,000 lines of C++ code
100-page summary
Transition plan
Installation plan
200-page user manual
Monthly project management
reviews
23