| The Personal Software Process: an Independent Study | ||
|---|---|---|
| Prev | Chapter 2. Lesson 2: Planning and Measurement | Next |
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]:)
Job sizing: How big is this job, and how long do you expect it to take?
Job structure: How are you going to do the work? What will you do first, second, and so on?
Job status: How do you know where you are? Are you going to finish on time and are the costs under control?
Assessment: How good was your plan? Did you make any obvious errors, what mistakes should you avoid in the future, and how can you do a better job next time?
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).