Improving the Productivity

of Software Development
Essential Steps & Problems
Topics
Introduction
Organizational impact
Four steps an improvement effort should include
Measurement of initial productivity
Identification and measurement of relevant productivity
drivers
Analysis and adjustments to identified productivity drivers
Reevaluation and comparison of overall process productivity
Introduction
One study found that a 20 percent improvement in
software productivity would be worth 90 billion dollars
world wide during the last decade of the twentieth
century
From 1990 to 1995, the software industry had a 10
percent drop in productive
Many blame the increasing size and complexity of
applications
Others counter with the development of new tools such
as CASE
Regardless, Productivity is an important issue
Introduction
Common output measure
SLOC
Useful in overall productivity assessment
Relatively useless in improvement efforts (not
adjustable)
Racecar example
Top speed similar to SLOC (one measure of total output/performance)
Other output/performance measures should be used
Acceleration
Grip
Any performance improvement requires adjustment to performance driving
characteristics of the car (Compression ratio, fuel to air mixture, timing, etc.)
Similarly in software development
Composite input/output metrics should be used
Measure and adjust adjustable drivers of productivity
Organizational Impact
Software Engineering Laboratory (SEL) - A software improvement
activity at NASA Goddard Space Flight Center, aided by the
University of Maryland and Computer Sciences Corporation
Goal - Improve productivity software projects at NASA
Existed for 25 years
A review of the 25 years of SEL identified 13 lessons learned
SEL found that a rigorous process and professional staff must be
used for collection and analysis of production data
Part-time undergrads were insufficient
Organizations will also need full-time software improvement staff
SEL found a 10% overhead allocation is necessary.
Step 1: Measurement of Current
Productivity
You cant improve what you cant measure.
Two fundamental measures any productivity
measurement
Input
Output

Productivity = Total software process output / Total
software process input

Measurement of Current Productivity
This simple equation carries significant implications
Comparability of productivity values when identical metrics and
instrumentation are used in the collection of data
Productivity of X is half as productive as 2X
Importance of accuracy
Do the metrics used actually reflect productivity
Example - Two software improvement efforts measuring the same process,
but using different metrics might give diametric results
Productivity values will result in organizational change
Organizational change based on inaccurate data is not a good
idea
Measurement of Current Productivity

Common input measures
Person-hours
Money

Common output measures
SLOC
Function Point Analysis
Measurement of Current Productivity
Revenue/Investment

Problems
Inflation
Only one value for input
and output
A software development
effort has relatively little
relation to revenue
generation
Revenue is more dependent
on market factors

Measurement of Current Productivity
SLOC should reflect the current
development effort
Not all code delivered to the
customer is developed under the
current effort
Not all code produced under the
current effort is delivered to
customers
Still, additional metrics of output
are needed.

Measurement of Current Productivity
Additional output
application-domain knowledge gained
Software development experience gained
documentation and other artifacts
complexity of the product
quality of the product
Example
TeamA
Extensive application-domain knowledge
Extensive software development experience
TeamB
Little application-domain knowledge
Little software development experience
Both teams produce functionally equivalent products using 20,000 SLOC
Effort from TeamA is 500 person-months
Effort from TeamB is 1000 person-months
TeamA is twice as productive as TeamB?
TeamB produced additional output
Application-domain knowledge gained
Software development experience gained
Size alone doesnt capture total output of a software development effort

Measurement of Current Productivity
Solution
Use composite input/output values
Problems for managers
What are the constituent values of the composite input/output
values
What weights to assign them
How to aggregate them into one value
Ensure productivity is accurately represented
Total input and output are captured in the productivity equation
Step 2: Identification and
measurement of productivity
drivers
Product, process, and production setting characteristics
individually and collectively affect the overall productivity
of the software process
Productivity drivers
Identification and measurement
of productivity drivers
Product-related drivers
Intrinsically related to product
Typically not adjustable
Examples
Computing resource constraints
Complexity
Size
Based on customer requests
Organizations must deliver
While not directly adjustable, product-related drivers are still
important determinants of productivity

Identification and measurement
of productivity drivers
Production setting-related drivers
Moderately controllable
Can differ within departments of the same organization
Examples
Programming language used
Differences between host (development) and target (end-user) system
Extent of client participation
Restricted by organizations practices and standards

Identification and measurement
of productivity drivers
Process-related drivers
Most Controllable
Present real opportunities for improvement
Examples
Frequency and distribution of changes in operational system requirements
Effort applied to detailed software unit design
Effort applied to architectural design
Many process-related drivers are essentially the levels of effort
applied to activities of the software development process
(requirements analysis, design, integration, testing, etc . . .)
Step 3: Analysis and adjustment
of productivity drivers
Problem for managers
Identify relationships between levels of output and productivity
drivers
What adjustments need to be made
Buggy product code might imply lack of effort applied to
software requirements specifications or requirements
tracing.
Clearly deeper analysis is required
Analysis and adjustment of
productivity drivers
Diminishing returns is an economic law stating, if one
production factor is increased while other are held
constant, eventually productivity will start to fall.
This implies specific levels of effort applied to process-
related drivers which should maximize productivity
However effort is applied thorough variable humans (not
like machines)
Difficult to find the maximal level of effort

Analysis and adjustment of
productivity drivers
Relationships between productivity drivers and levels of output are
hard to comprehend and expensive to identify (10%)
Confounded by interrelations of productivity drivers
Especially the human factor
Solution . . .
Theoretical knowledge based system that models software production
Set up to mirror current situation
Product characteristics
Process characteristics
Production setting characteristics
query the model and conduct what if analysis on the current situation
. . . Immediate answers
Successful implementation of such a model would eliminate 80 to 90%
of software improvement costs.

Analysis and adjustment of
productivity drivers
Management should formulate an organizational change
plan based on analysis of data collected with the aid of
the data collection and analyzation team.
Commitment is important
2/3 of all change efforts fail due to lack of commitment across
all levels of the organizations
Lesson 11 at SEL involved having upper managements support
for continued improvement in productivity
Analysis and adjustment of
productivity drivers
Resistance to change is natural
Technology Acceptance Model (TAM) and the Theory of
Planned Behavior (TPB) both study such adoption issues
and predict intention to use and actual usage of
workplace technology
Certain aspects of these models used to overcome initial
resistance of the improvement plan and assimilate
change in the workplace
Step 4: Reevaluation and
comparison of overall process
productivity
Reevaluate productivity
Use identical metrics
Use identical instrumentation
Ensures comparability and accuracy of the comparison
Establish the degree of success or failure of the
improvement attempt
What went wrong
What went right
Continuous iteration of these steps means continuous
improvement in productivity in spite of the ever
increasing size and complexity of products.
Conclusion
Following these four basic steps, and with a knowledge of
problems that will be encountered, managers will be
able to improve productivity of their software
development efforts.

Development of the theoretical software simulation model
will significantly reduce the cost and complexity of this
process.