Unit 5

PROJECT CONTROL AND PROCESS

INSTRUMENTATION
• Introductory Remarks
• 13.1 The Seven Core Metrics
• 13.2 Management Indicators
13.2.1 Work & Progress
13.2.2 Budgeted Cost & Expenditure
13.2.3 Staffing & Team dynamics
• 13.3 Quality Indicators
• 13.3.1 Change Traffic & Stability
13.3.2 Breakage & Modularity
13.3..3 Rework & Adaptability
13.3.4 MTBF & Maturity
• 13.4 Life-Cycle Expectations
• 13.5 Pragmatic Software Metrics
• 13.6 Metrics Automation
 Introductory Remarks
• The progress toward project goals & the quality
of the software products must be measurable
throughout the software development cycle

• Metrics Values provide important perspective

for managing the process

• The most useful metrics are extracted directly

from the evolving artifacts

• Objective analysis & automated data collection

are crucial to the success of any metrics
The Primary theme of a modern software Development
process tackle the central management issues of complex
software

• Getting the design right by focusing on the architecture

first
• Managing risk through iterative development
• Reducing the complexity with component techniques
• Making software progress & quality tangible through
instrumented change Management
• Automating the overhead & bookkeeping activities
through
the use of round-trip engineering & integrated
environment
The goals of software metrics are to provide the
development team & the management team with
following

• An accurate assessment of the progress date

• Insight into the quality of the evolving software
products
• A basis for estimating the cost & schedule for
completing the product with increasing accuracy over
time
 The Seven Core Metrics
The core metrics are classified into two groups
• Management Indicators
Work & Progress ( Work performed over time )
Budgeted Cost & Expenditures ( Cost Incurred over time )
Staffing & Team dynamics ( Personnel changes over time )
• Quality Indicators
Change traffic & Stability ( Change traffic over time )
Breakage & Modularity ( Average breakage per change over time )
Rework & Adaptability (Average rework per change over time )
Mean time between failures & maturity (Defect rate over time )
 Management Indicators
I Work & Progress
Various activities of an iterative development project can be
measured by defining a planned estimate of the work in an
objective measure then tracking progress against that plan
Each major organization team should have at least one
primary progress perspective that it is measured against. The
default perspective of the metrics would be as follows
• Software Architecture team : Use case demonstrated
• Software development team : SLOC under baseline change
management, SCO s closed
• Software Assessment team : SCO s opened, test hours executed,
evaluation criteria met
• Software management team : Milestones completed
II Budgeted Cost & Expenditures
Modern software processes are amenable to financial performance
measurement through an earned value approach which provides highly
detailed cost & schedule insight. The basic parameters of an earned
value system are

• Expenditure Plan
Planned spending profile for a project over its planned schedule ( this
profile tracks the staffing )
• Actual Progress
The technical accomplishment relative to the planned progress underlying
the spending profile
• Actual Cost
The actual spending profile for the project over its actual schedule
• Earned Values
The value that represents the planned cost of the
actual progress
Cost Variance
The difference between the actual cost & the earned
values
+ values : Over budget situations
- values : Under budget situation
Schedule Variance
The difference between the planned cost
& the earned values
+ values : Behind schedule situations
- values : ahead-of schedule situation
III Staffing & Team dynamics
An iterative development should start with a small team
until the risks in the requirements & architecture have
been suitably resolved.
Depending on the overlap of the iterations & other
project-specific circumstances staff can be varied

Generally in certain projects maintenance team will

be smaller than development team
For commercial product development the size of
maintenance & development teams may be the same
 Quality Indicators
The four quality indicators are based primarily on the
management of software change across evolving baselines
of engineering data
Change traffic & stability is a indicator of progress &
quality where as remaining three metrics focus more on
quality of the product

I Change Traffic & stability

Change traffic is defined as the number of software
change orders ( SCO ) opened & closed over the life cycle

Stability is defined as the relationship between opened

versus closed SCO’s
II Breakage & Modularity

Breakage is defined as the average extent of

change which is the amount of software baseline that
needs rework

Modularity is the average breakage trend over time.

This indicator provides insight into the benign or

malignant character of the software change
III MTBF & Maturity

MTBF is the average usage time between

software faults.
i.e MTBF is computed by dividing the test hours by
the number of type 0 & type 1 SCOs
Maturity is defined as the MTBF trend over time.
Early insight into maturity requires that an effective
test infrastructure be established.
 Life-cycle Expectations
There are no mathematical or formal derivation for using the seven
core metrics however there are specific reasons for selecting them
• The quality indicators are derived from the evolving product than
from the artifacts.
• They provide insight into the waste generated by the process. Scrap
& rework metrics are a standard measurement perspective of most
manufacturing processes
• They recognize the inherently dynamic nature of an iterative
development process.
• The combination of insight from the current value & the current
trend provides tangible indicators for management action.
 Pragmatic Software Metrics
The Basic characteristics of a good metrics are as follows

• It is considered meaningful by the customer, manager

& performer
• It demonstrates quantifiable correlation between
process perturbations & business performance
• It is objective & unambiguously defined
• It display trends
• It is a natural by-product of the process
• It is supported by automation
 Metrics Automation
There are many ways to automate the project control activities of software
projects.
A Software project control panel (SPCP) that maintains on-line
version of the status of evolving artifacts provides a key advantage for
managing against plan.
The idea is to provide a display panel that integrates data from
multiple sources to show the current status of some aspects of the
project.
Example
• The software manager want to see a display with overall project value
• A test manager may want to see a display focused on metrics specific to
on upcoming beta release.
• A development managers may be interested only in data concerning the
subsystems & components for which they are responsible
The Software project control Panel (SPCP) can support
standard features such as
• Warning lights
• Thresholds
• Variable scales
• Digital formats
• Analog formats
to present an overview of the current situation.
This automation support can
• Improve management insight into progress & quality trends
• Improve the acceptance of metrics by the engineering team
To implement a complete SPCP it is necessary to define & develop the
following

• Metrics primitives :indicators, trends, comparisons & progressions

• A graphical user interface (GUI) : GUI support for software project
manager role & flexibility to support other roles
• Metrics collection agents : Data extraction from environment tools
that maintain the engineering notation for the various artifacts sets
• Metrics data management server :Data management support for
populating the metrics display of the GUI & storing data extracted
from agents
• Metrics definition :Actual metrics representation for all activities
• Actors : The monitor & the Administrator
Specific monitors ( called roles ) include
• Project managers
• Software development team leads
• Software Architects
• Customers
for each role there is specific panel configuration & scope of
data presented. Each role performs the same general use cases, but
with a different focus

Monitor
• Defines panel layouts from existing mechanisms
• Graphical objects
• Linkage to project data
• Queries data to be displayed at different level of abstraction
Administrator
• Installs the system
• Defines new mechanisms
• Graphical objects
• Linkages
• Handling archiving functions
• Defines composition & decomposition structures for displaying
multiple levels of abstraction

The whole display is called panel. Within a panel are graphical

objects which are types of layouts( such as dials & bar charts ) for
information. Each graphical object display METRIC
A Panel typically contains a number of graphical objects
positioned in a particular geometric layout.
A metric shown in a graphical object is labeled with the
metric type, summary level & the instance name.

• Metrics can be displayed in two modes : Value & Graph

• Metrics can be displayed with or without control values
A Control value is an existing expectation that is used
for comparison with dynamically changing metric
• Metrics may display data in the formats that are binary,
digital & enumerated type
• Metrics also provides a mechanisms that can be used to
summarize a condition associated with another metrics or
relation between metrics & other associated control values
 TAILORING THE PROCESS
• 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

 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
 PROCESS DISCRIMINANTS
In tailoring the management process to a
specific domain or project there are two
dimensions of discrimination factors

• Technical Complexity
• Management complexity
• 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
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
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
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
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
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
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
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.