Introduction to the Personal Software Process; basics of software processes; PSP0
Read chapters 1 and 2 of the textbook
Write and document program 1A from the textbook using PSP0 processes
Chapter 1 of [Humphrey95] establishes the basis for the PSP, motivation for its use, and the basis of what a personal software process is.
Humphreys' thesis is that the current practice of software engineering is "… nearer a craft than an engineering discipline", and that one road toward real progress in software engineering is the establishment of disciplined frameworks of practices which can form a sort of standardization of the software development process, adding predictability where there is currently individualized chaos. He reflects a common complaint against organized process that I've seen both from individual software developers to any workers in any organization attempting to establish practices: that the work involved is (or can be) highly creative, and that standard practices will reduce the creativity and fun involved, thus damaging productivity instead of enhancing it. Since "work itself" is a significant motivator of software developers [McConnell96], this is a worry I share as well; on the other hand, having worked in process improvement before, I do feel it has something to offer the individual developer (in fact, a motivated individual developer might be able to realize greater benefits than an organization). Humphrey brings up some excellent points-- particularly that "It is not fun to make the same mistake over and over or to produce a poor-quality result [Humphrey95]." In other words, established practices may form the core of a reliable process which can enhance the creative side of software development rather than detracting from it.
I'm somewhat skeptical, although the idea of separating the repetitive, "standard" parts of software development from the creative, dynamic parts appeals to my sense of organization. As Humphrey puts it,
That key parts of the software design task are creative is no reason for treating them all that way... The key is to treat the creative and the routine differently. Once the creative tasks have been identified and bounded, the routine work often can be made more accurate and efficient... when [routine] tasks are supported by forms, procedures, and historical data, their quality can be improved and made more efficient. Engineers then can spend more time on the truly creative parts of their jobs.
|--Watts Humphrey, in [Humphrey95]|
As one might expect, the PSP borrows heavily from the SEI's Capability Maturity Model (CMM), an industrial-strength set of recommendations. Many aspects of the PSP, such as size estimation and task planning, mesh well with key process areas of the CMM, such as software project planning.
While this bodes well for integration into a process-oriented organization, it raises a few minor concerns, mostly centered around the idea that the PSP is organized toward one particular style of development. My concern there was intensified by the focus later in the chapter on "design, code, and test" -- as if those steps must be performed according to the traditional "waterfall" method of software development. This concern was somewhat alleviated by Humphreys insistence that the PSP is intended to be used cyclically, particularly on large systems; if this is the case, then it will adapt well to many different software lifecycles.
Chapter 2 goes on to describe the "meat and potatoes" of a personal software process: the basic cycle involved, measurement frameworks, process elements, etc. Central to the PSP is the extensive use of forms, a fact readily admitted by Humphrey ("The PSP uses a lot of forms"). Happily, the forms involved are downloadable in many different forms, including postscript; it would be an interesting exercise (although beyond the scope of this study) to create SGML or XML document type definitions for many of the forms involved, which would move the PSP one step closer to automation.
The basic process involved is similar to the famous "Shewhart Cycle" of plan-do-check-act: "First, in the planning step, you produce a plan to do the work. Next, you do the software development. At the end, in the postmortem step, you compare your actual performance with your plan, record the process data, and produce a summary report." For the relatively small problems involved in the PSP exercises, this does seem like a lot of extra work, but I agree with Humphrey that the process is what is important, not the programs themselves; while many of my current projects involve a fair amount of design, not many of them involve planning... and while I currently do some postmortem analyses of projects, I rarely record the results in any sort of structured form.
The result-- even for the "entry level" process, PSP0-- is a fairly elaborate script; I include the tabular summaries of the steps here to illustrate the detail involved to those readers without a copy of the textbook:
Table 1-1. PSP0 Process Script
|Phase Number||Purpose||To guide you in developing module-level programs|
|3||Postmortem||Complete the Project Plan Summary Form with actual time, defect, and size data|
Table 1-2. PSP0 Planning Script
|Phase Number||Purpose||To Guide the PSP planning process|
Table 1-3. PSP0 Development Script
|Phase Number||Purpose||To guide the development of small programs|
Table 1-4. PSP0 Postmortem Script
|Phase Number||Purpose||To guide the PSP postmortem process|
Needless to say, this is a great deal more structure than I'm used to in general software development, particularly the by-the-minute time log and the "every time you make a program change" defect log. At the same time, having worked with gathered information in the past, I understand the need for fine granularity; while I'm not looking forward to the meticulous record-keeping involved, I'm terribly curious to see the results. The forms (and instructions) are quite complex-- you can view my results for program 1A later in this chapter, but I will refrain from including in this document all the instructions for the forms' completion.
From here, it's time to move on; program 1A awaits, and with it my first experiences with a detailed software development process.