Chapter 14- tailoring the process

1
Chapter 14- tailoring the process
2
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

3
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
Process Discriminants

• In tailoring the management process to a
  specific domain or project there are two
  dimensions of discrimination factors
• Technical Complexity
• Management complexity

5

• 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
• Large scale
• Contractual
• Many stakeholders
• Projects

• Lower management Complexity
• Smaller scale
• Informal
• Few stakeholders
• 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
6

• Higher technical Complexity
• More domain experience required
• Longer inception elaboration phase
• More iterations for risk management
• Less predictable costs schedules

• Higher management Complexity
• More emphasis on risk management
• More process formality
• More emphasis on teamwork
• Longer Inception elaboration phases

• Lower management Complexity
• Less emphasis on risk management
• Less process formality
• More emphasis on individual skills
• 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
7
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

8
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

9
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

10
Process Primitive Smaller Team Larger Team
Life cycle phases Weak boundaries between
Well-defined phases transitions to
phases 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 Manageme
nt 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 Checkpoints
Many informal events for A few formal
events maintaining technical Synchronization
among teams consistency which can take
days 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 project control change control
11
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

12
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 assessme
nt stakeholder concurrence Checkpoints Many
informal events 3 or 4 formal events Many
informal technical walkthroughs
Synchronization among stakeholder
teams Management Informal planning,project Forma
l planning, project control, discipline control,
organization organization Automation (
insignificant ) on-line stakeholder environment
discipline necessary
13
Process Discriminants

• III Process flexibility or rigor
• The degree of rigor formality change freedom
  inherent in a specific projects contract will
  have a substantial impact on the implementation
  of the projects 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
• 
  
  
  

14
Process Primitive Flexible
Process Inflexible process
Life cycle phases Tolerant of cavalier phase More
credible basis required for communications ince
ption 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
15
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

16
Process Primitive Mature level 3 or 4 Level
1 Organization
Life cycle phases Well-establish criteria for (
insignificant) phase transition Artifacts We
ll-establish format, Free-form content
production methods Work effort Well-establish
basis No basis allocations Checkpoints Well-de
fined combination ( insignificant) of formal
informal events Management Predictable
planning Informal planning project discipline O
bjective status control Automation Requires
high levels of discipline automation for
round-trip Little automation or disconnect
engineering, change islands of
automation management process instrumentati
on
Process discriminators that result from
differences in process maturity
17
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 projects 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

18
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
19
Process Discriminants

• VI. Domain Experience
• The development organizations domain
  experience governs its ability to converge on an
  acceptable architecture in a minimum number of
  iterations.
• Generally a skilled software organization
  building its first radar application may require
  4 or 5 prototype releases before converging on an
  adequate baseline.

20
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
21
Small scale Vs large-scale project
Engineering Production Domain
Inception Elaboration
Construction Transition
Small 10 20 50 20 Commercial Project Larg
e,Complex 15 30 40 15 project
22
Small scale Vs large-scale project

• Differences in workflow priorities between small
  large projects
• Rank Small commercial project Large, complex
  project
• Design Management
• Implementation Design
• Deployment Requirements
• Requirements Assessment
• Assessment Environment
• Management Implementation
• Environment Deployment

23
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 Architect
ure 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
Transition plan
sales rollout kit 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