Chapter 3 of the text focuses on planning, a piece of the development practice which (from my meagre experience) is often overlooked. According to Humphrey, a plan


...defines the work and how it will be done. It provides a definition of each major task, an estimate of the time and resources required, and a framework for management review and control... When properly documented, it is a benchmark to compare with actual performance. This comparison permits the planners to see their estimating errors and to improve their estimating accuracy."

--Watts Humphrey, from the text 

As someone who has done little formal planning, this sounds terribly grand; after all, for program 1a, my "plan" consisted entirely of "oh, 90 minutes sounds okay..."-- not exactly a "definition of each major task", and very far from a "framework for management review and control". And for a program that small, for no particular customer, that's probably okay. In fact, Humphrey's plans as far as the PSP goes, require four general things (from [Humphrey95]:)

To help with planning, Humphrey presents a moderately elaborate planning flowchart, which I won't duplicate here. It is notable, though, that estimation of size, resources, and schedule come from "historical databases" which contain information on past projects. This obviously puts the beginning PSP practitioner at a disadvantage; I have no data (well, one program) from which to draw any conclusions.

To start building this data (and to make any sort of educated guesses), Humphrey begins with software size; chapter 4 of the text is devoted to measuring size and relating size to productivity, schedules, etc.

For this to be effective, the counting process--particularly with applications in the hundreds of thousands of lines--must be automated.

There are a number of ways for a LOC counter to work; by counting logical lines (possibly implemented as part of a compilation suite, because logical line counting is a non-trivial task which is highly dependent on the target language), counting physical lines (almost trivial to implement, but counts everything, including comments, blank lines, etc), or by counting physical lines in a document which follows a set coding standard.

The last (coding standards and a physical LOC counter) is the approach advocade by Humphrey; combined with an elaborate LOC accounting procedure, the addition of size measurement is the focus of lesson 2: I am to produce a standard of LOC counting, a coding standard, and a program which will count physical LOC, using PSP 0.1.

PSP 0.1 is not significantly different from PSP 0. It adds the Process Improvement Proposal (PIP), a form for recording problems or improvement suggestions for the process. It also adds coding standards and some changes to the planning form (mostly for LOC accounting).