The Personal Software Process: an Independent Study
Prev		Next

Chapter 1. Lesson 1: Introduction to the Personal Software Process

Table of Contents
The Readings
Program 1A
Summary

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

The Readings

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
	Entry Criteria	Problem Description PSP0 Project Plan Summary Form Time and Defect Recording Logs Defect Type Standard Stop watch (optional)
1	Planning	Produce or obtain a requirements statement. Estimate the required development time. Enter the plan data in the Project Plan Summary Form. Complete the Time Recording Log.
2	Development	Design the program. Implement the design. Compile the program and fix and log all defects found Test the program and fix and log all defects found. Complete the Time Recording Log.
3	Postmortem	Complete the Project Plan Summary Form with actual time, defect, and size data
	Exit Criteria	A thoroughly tested program Completed Project Plan Summary form with estimated and actual data Completed Defect and Time Recording Logs

Table 1-2. PSP0 Planning Script

Phase Number	Purpose	To Guide the PSP planning process
	Entry Criteria	Problem Description Project Plan Summary Form Time Recording Log
1	Program Requirements	Produce or obtain a requirements statement for the program. Ensure the requirements statement is clear and unambiguous. Resolve any questions.
2	Estimate Resources	Make your best estimate of the time required to develop this program
	Exit Criteria	A documented requirements statement. A completed Project Plan Summary with estimated development time data Completed Time Recording Log

Table 1-3. PSP0 Development Script

Phase Number	Purpose	To guide the development of small programs
	Entry Criteria	Requirements Statement Project Plan Summary with planned development time Time and Defect Recording Logs Defect Type Standard
1	Design	REview the requirements and produce a design to meet them. Record time in Time Recording Log.
2	Code	Implement the design. Record in the Defect Recording Log any requirements or design defects found Record time in the Time Recording Log
3	Compile	Compile the program until error free. Fix all defects found. Record defects in Defect Recording Log. Record time in Time Recording Log.
4	Test	Test until all tests run without error. Fix all defects found. Record defects in Defect Recording Log. Record time in Time Recording Log.
	Exit Criteria	A thoroughly tested program Completed Defect Recording Log Completed Time Recording Log

Table 1-4. PSP0 Postmortem Script

Phase Number	Purpose	To guide the PSP postmortem process
	Entry Criteria	Problem description and requirements statement Project Plan Summary with planned development time Completed Time Recording Log Completed Defect Recording Log A tested and running program
1	Defects Injected	Determine from the Defect Recording Log the number of defects injected in each PSP0 phase. Enter this number under Defects Injected-- Actual on the Project Plan Summary.
2	Defects Removed	Determine from the Defect REcording Log the number of defects removed in each PSP0 phase. Enter this number under Defects Removed-- Actual on the Project Plan Summary
3	Time	Review the completed Time Recording Log Enter the total time spent in each PSP0 phase under Actual on the Project Plan Summary Form
	Exit Criteria	A fully tested program Completed Project Plan Summary form Completed Defect and Time Recording logs

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.