To really foul things up LO5076

Eric Opp (eopp@mrj.com)
Tue, 23 Jan 1996 11:12:33 -0500 (EST)

Replying to LO5045 --

On Tue, 23 Jan 1996, Gray Southon wrote:

> I am fascinated by your analogy between software development and car
> manufacturing. I was wondering what sort of software house you had in mind
> (e.g. no. of staff, size of project, no. of projects per year, type of
> program (e.g. embedded, commercial, standard or customised application,
> in-house corporate development or independent producer, for industrial
> control, office automation, games, artifical intelligence etc.)) Do your
> comments apply to all situations, or are you considering only particular
> conditions?

In fact, the Capability Maturity Model can be reduced to a quality
improvement process or framework for the individual programmer. Watts
Humphrey, who wrote the book, "Managing the Software Process," which
describes the Capability Maturity Model in detail, recently published a
book called "A Discipline for Software Engineering." This book describes
how a subset of the frameworks of the Capability Maturity Model applies to
the individual programmer. The rough learning process can be outlined as
follows:

Step 1: During the execution of several projects record your
own personal productivity and accuracy - lines of
code per day, number of defects & type of defects

Step 2: Use data gathered in Step 1 as a basis metric for
your own personal productivity. This gives the individual
programmer a firm basis for making cost, size and time
estimates, which put overall project planning on a firmer
basis.

Step 3: Once you can accurately plan & schedule your own work,
you can begin to review your designs and your actual
code for defects with the long term view of eliminating
common classes of defects from your designs and from
your code.

Step 4: Having eliminated some of the more common classes of
defects from your personal software design & coding
process, you can begin to optimize your own personal
software process - i.e. significantly reduce some of
those incessant but subtle bugs that you regularly
introduce.

The Personal Software Process must be reinitiated for each different
class of application. That is you might be able to accurately predict your
performance on operating systems programming, but you will need to repeat
the steps when you begin developing financial applications. As with any
discipline, the second time you traverse the path, it goes much faster.

To answer the question of size, you would use this on all sizes of
projects. The process calibration (understanding your own productivity) is
done through some relatively small projects (for the professional
programmer).

If you take the analogy to a Learning Organization, this is the path of
"Personal Mastery" with a little of "Mental Models" thrown in. The rest of
the Capability Maturity Model deals with how a group of programmers
interact, which involves all "Five Disciplines."

--
    Eric N. Opp
    MRJ Inc.
    eopp@mrj.com