A Discipline for Software Engineering

by Watts S. Humphrey

These days, almost everyone in the software field is aware of the Software Engineering Institute's capability maturity model (CMM); and though that model is the joint effort of a team of many talented people at the SEI, many of us view Watts Humphrey as the "father" of that model and the spokesman for many of its principles. This is not only because of the pioneering work that Humphrey has done in the field and the leadership that he exerted within the SEI, but also because of his ground-breaking book, Managing the Software Process, which described the SEI model in detail.

But that book was published in 1989, and time marches on: the SEI published an updated, revision to the model (known as Version 1.1) in 1993, and has recently begun focusing on the "peopleware" component of software processes. And the introduction of the SEI model has sparked considerable controversy in the industry, as evidenced by the debate between Bill Curtis and James Bach in the September 1994 issue of American Programmer. In addition to the controversy about the relevance of the SEI model for any form of software development, much of the discussion in the field has focused on the question of where the SEI's recommendations for a formalized software process is practical only for large organizations and military agencies, or whether it can be used for small organizations, too.

Indeed, the latter complaint arose almost as soon as Humphrey's book was published in 1989, and by 1990, Humphrey was already researching the applicability of the SEI model to groups as small as one — thus leading to the concept of a "personal" software process. This has culminated in an important new book, A Discipline for Software Engineering. As Humphrey described the effort in a recent article (in the December 1994 issue of American Programmer),

Many viewed the CMM as designed for large organizations and did not see how it could be applied to individual work or to small project teams. ... The SEI thus started a process research project to examine ways individual software engineers could apply level-5 process principles. After several years of research, means were devised to adapt 12 of the 18 CMM key process areas to the work of individual software engineers.

To reach the "repeatable" level on the CMM, for example, an organization needs to implement such key processes as software configuration management, oftware quality assurance, software subcontract management, and requirements management. In many software projects, these activities are beyond the ability and the "charter" of the individual software professional: they only exist, and are only carried out in a repeatable fashion, if the organization defines the processes, and assigns people and resources to carry them out. But some of the other CMM level-2 key process areas — e.g., software project planning and software project tracking/oversight — are areas where personal processes are meaningful for the one-person project, or for the activities of an individual within a larger project. Equally important, within the framework of Humphrey's PSP, they can be measured and monitored from a mathematical, statistical perspective. Similarly, peer reviews, which are one of the CMM level-3 key process areas, can be arranged and organized with an individual's peers, on his or her own initiative. Obviously, software engineerings have to decide for themselves that this is useful and worthwhile, but once they've made this decision, they can probably proceed without the approval or knowledge of the organization.

In the same fashion, quality management, and quantitative process management are key process areas at CMM level-4 — and while they have traditionally been associated with organizational efforts, Humphrey's new PSP emphasizes that documenting, measuring, and keeping track of one's own "cost of quality" (COQ) can be a significant basis for improvement of the individual software process. Humphrey argues that COQ has three components: failure costs (the costs of diagnosing a failure, making necessary repairs, recompiling, re-testing the software, and getting back into operation), appraisal costs (the costs of evaluating the product to determine its quality level, including design/code reviews and inspections), and prevention costs (the costs associated with identifying the causes of the defects and the actions taken to prevent them in the future).

As with the organizational-level CMM activities, there is a level of formalism and discipline to all of this that will probably not appeal to the "cowboy culture" of software develoment. But even those who are prepared to be open-minded about Humprehy's PSP will naturally ask: "What's the payoff for all of this extra work?" Humphrey's experiments, summarized in his December 1994 American Programmer article, have reported productivity iprovements averaging 75 percent, and defect reductions averaging 59 percent. The signiicant point here is that these are improvements experienced by individuals, not by the organization as a whole. Perhaps that's why the reaction from some of the software engineers who have gone through Humphrey's training and put the ideas into practice is, "I'm doing this for me, not for the organization."

I should warn you in advance that A Discipline for Software Engineering is no lightweight piece of reading: it's 789 pages long, with a list of mathematical terms and equations on the inside cover. Most software engineers are be overwhelmed initially with the level of mathematical effort Humphrey recommends for estimating program sizes, project schdules, defect densities, etc. But if you're an educator, it's also worth noting that additional support materials are available. A support diskette is available for the modest price of $14.95; it contains copies of the forms illustrated in the book, plus data analysis spreadsheets for the exercises. An instructor's guide and instructor's diskette is also available, with notes, lecture slides, and spreadsheets to review and analyze student data.

Having seen Humphrey's material first as a manuscript, and more recently in published form, I am convinced that it will be even more influential than his last book. My only criticism is the title; in my opinion, it should have been called PSP: A Personal Software Process, because that's what everyone in the industry will be calling it. But that's a minor complaint; the main point is that if you believe software development is something more serious than extemporaneous coding in Visual Basic or PowerBuilder, then Humphrey's new book is one that you need to understand, and whose advice and guidance you need to follow.