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