Process Improvement in Organizations

The Software Engineering Institute (SEI)
of Carnegie Mellon University has been set up to develop methods for building
better software. One of their initiatives has been to build a software
maturity capability model that characterizes software organizations into
one of five capability levels.

Level I is
the initial stage within which more than 85% of the organizations assessed
by the SEI were included. Level I is essentially ad hoc, chaotic development
with no reproducibility or predictability from project to project. Early
SEI studies showed very few organizations in level II and III; none in
levels IV and V. The sample size they had was small, however.

The SEI maturity model has
stimulated considerable interest in process improvement, because organizations
want to move up the scale and demonstrate their development proficiency.
However, questions immediately arose concerning the cost of embarking
on such a program, and whether it would be a sound economic investment.
Unfortunately, the SEI approach is non-quantitative and hence cannot readily
be converted into traditional economic measures of benefit such as schedule
reduction, cost reduction and reliability improvement.

Quantitative Software Management,
Inc (QSM) has been in the business of obtaining the management numbers
for software development activities since 1978. The company has developed
a comprehensive methodology to measure, estimate, and control software
development projects in terms of the basic management metrics of time,
cost, staff and reliability.

This makes it easy to turn
gains in process productivity into easily understandable benefits, so
that economic-based decisions can be made in traditional investment terms–return
on investment or ROI.

Metrics and Approach

Significant
reduction in cycle time can be achieved by effective exploitation of reusable
libraries of proven modules, or objects, in modernAda and I-CASE and other
object-oriented environments, and by making improvements to the software
development process. The benefits of reduced cycle time are realized not
only in schedule, but in effort/cost and reliability–fewer defects; longer
mean time to defect.

It is possible to quantify
the magnitude of these benefits using QSM’s software equation. The conceptual
form of this equation is–

Quantity of
Function =

Process Productivity * Effort * Schedule

This says that the product
of the time and effort, coupled with the process productivity of the development
organization, determines how much function can be delivered. Extensive
empirical study of software data has shown that very strong non-linearities
exist in software behavior. When this is taken into account in calculation
form, the software equation discloses these non-linearities and, more
importantly, how they can be exploited by management. The calculation
form of the equation is–

SLOC = PP
parameter *

(Effort/B)(1/3) * Time (4/3)

Where,

n Process
Productivity Parameter is the development process efficiency of the organization.
This is determined from the organization’s historic data.

n SLOC
is the quantity of function created in source lines of code written. Other
measures of function could also be used.

n Effort
is the person-years of effort required, including all types of labor used
on the project.

n B
is a factor which provides for specialized skills for integration, testing,
documentation and management as the size of the system increases. Essentially,
it is a complexity adjustment factor for size. In the examples used here
it will remain a constant.

Time is the
elapsed time in years from the start of detailed design until the product
is ready to enter into operational service. The elapsed time frequently
is a 95% reliability level.

A Productivity
Index (PI) is also used to linearize and represent the PP term in the
software equation. It is a simple linear number that is used to transform
the non-linear values of the PP parameter into an easy-to-interpret linear
scale. The scale ranges from 1 to 40. All software projects measured so
far fit within this range.

If we rearrange
the equation to isolate effort, and multiply it by a fully burdened labor
rate, then we obtain a software cost equation–

SW Cost =

(SLOC/PP)3 * (I/Time4) * (B * LaborRate)

This equation
has enormous economic leverage that can be exploited by management. If
you reduce the size through reuse, then you reduce cost by the cube of
the size reduction. If you increase process productivity by investment
in tools, training and discipline, then the cost goes down by the cube
of the increase in the PP parameter.

If you deliberately
use a smaller team and lengthen the schedule modestly to accommodate this,
then you reduce the cost by the fourth power of the schedule increase.
On a given development project, one, two, or sometimes all three of these
situations can be made to happen by management.

Process Improvement

The PP parameter
in the software equation increases as the organization becomes more process
efficient. This is analogous to moving up the SEI maturity scale. In fact,
QSM has established a linear correlation between the SEI scale and its
PI.

This process
productivity term is the capital investment term in software development.
It costs money and it takes time and discipline to make process improvement
happen. But the pay off is handsome for those willing to make the investment.
Here we are talking about the long-term, continuous improvement process
the Japanese describe as kaizen.

In the early
days, moving up the process improvement scale amounted to bottleneck elimination,
such as getting a dedicated development computer rather than sharing a
production machine. The measured payoff back then was very considerable.
It did happen, however.

In the future,
it will be more difficult to make process improvement happen because it
will involve changing the way the organization does its work. Perhaps
culture change will be necessary.

Doing this is slower and
more difficult, and considerable resistance can be experienced. But it
is necessary, and the pain in making it happen is well worth the suffering
in terms of financial pay

payback,
reduced cycle time, and improved quality of product delivered to the customer.
A few good companies have been doing it for years, and their results show
that it pays off with ROIs in the 70 to 100% per year range.

Those organizations
that have achieved such results have done so in a number of ways. But
they have all been the establishment of a control office and a quality
assurance team. The quality assurance team supports and fosters the use
of the process methodology. Additionally, the control office participates
in the planning and measures and controls the software projects.

To gain maximum
benefit it is essential to fully integrate the operation of the office
with the organization’s existing management procedures.

SEI Level/PI Linkage

QSM has been
able to establish a correlating linkage between their quantitative PI
and the more heuristic SEI maturity levels. Since the QSM approach is
based on a very large data base, it is fully populated across the whole
spectrum of projects–from poor to very good.

The upper
tier of performers is represented in the QSM approach. This has occurred
only very sparsely in the SEI approach, probably because of the small
sample size.

Tables exist
for other application types, such as engineering systems and real-time
systems, where the PI values are somewhat lower for the transition points
because of the higher complexity of such systems.

The QSM approach
permits reasonably accurate quantification of benefits in terms of reduced
schedule, effort, cost and defects. QSM has been doing this for more than
10 years with verifiable results. Now, because of the correlation between
the SEI maturity levels and the QSM PI, it is possible to determine the
expected benefits of moving up the SEI scale. That can be coupled with
the benefits of reducing the effective size of the function to be created,
by exploiting reusable objects.

Moving up to Level III

How fast
can organizations move up the SEI scale? QSM has been tracking rate of
improvement in terms of its PI scale for nearly 10 years. So, again, it
is possible to provide some projections of what has happened and what
is likely to happen in the near future based on that history.

By contrast,
the rate of progress of the average for business systems is considerably
slower. This tells us that if we don’t focus real management attention
and investment on process improvement, it is going to take considerable
time to get to SEI level III and higher.

Engineering
and real-time systems behave similarly, except that those application
types tend to be a bit slower in terms of improvement rate. This is because
they are more complex, and not as much investment has been made in those
application types as for business systems.

PI pays back

Great economic
leverage is possible from process improvement. Enough money can be saved
by investing in process improvement to pay back the investment during
the first set of applications built which enjoy the process improvement
benefits.

What is required
to make it happen:

• Taking
  process improvement seriously

• Making
  the necessary investments

• Getting
  full management support behind the process improvement program

• Working
  hard on continuous improvement (kaizen principle) in software development.
  If this is done, moving up the SEI scale can pay off handsomely.

By Lawrence
H Putnam

Courtesy: QAI
(India)

customer_relations@qaindia.com