Comprehend basic process development concepts and procedures for defining them. Understand where to use the PSP; comprehend the costs and benefits of using a PSP and issues you may face using it in a software organization.
Read chapters 13 and 14 of the textbook
Chapter 13 of the text is devoted to defining processes-- a significant bit of information, and one I wish I'd encountered earlier (since during the course of the PSP we've been asked to define (or at least modify) a number of processes. Humphrey goes through basic definitions, the parts of a process (scripts, tools, standards, improvement provisions, etc.). I'm particularly fond of the section on "process formats"-- how a process should be stored and represented. The principles used (chunking relevant information together, labeling each chunk clearly, being consistent, use hierarchical grouping) are very handy, and apply to much more than software processes. Any process used by humans can benefit from these principles.
The next several sections delineate how a process should be designed based on objectives, goals, and criteria, and launched from a solid understanding of where the current process lies. Humphrey discusses some clever elements for prioritizing process elements (such as priorities of product attributes and their coupling relationships between product attributes and process elements). This is good stuff, which makes me wonder if it's possible to get this data for the PSP itself (is there any data which shows strong correlations between PSP elements like design reviews and design yield? Where's the guidance on how to tune the PSP?)
It's too bad that this chapter doesn't have a more defined exercise than writing R4-- in fact, I'd say this chapter should be placed earlier in the courseware, and used in other settings. I can think of few jobs which could not benefit from a solid knowledge of how to structure, analyze, and adjust processes.
Chapter 14 addresses using the PSP in actual work conditions-- how to make and defend plans based on your PSP data, how to handle pressure from above when it will (initially) appear that PSP time is wasted when it could be spent on immediate development, etc. Humphrey also addresses (somewhat) the difficulties of being a solo PSP performer in an organization of naysayers. Happily, he also devotes some time to the benefits of the PSP.
He discusses somewhat the idea of a PSP "coach", noting that "We have not yet developed a coaching ethic in software development" [Humphrey95]. This is a lament which I've heard elsewhere, and discussed most recently in Kent Beck's book on Extreme Programming [Beck00]. This is an extremely intriguing idea, and one which I'd really like to see employed by software development organizations. Unfortunately, I fear that most organizations will feel that a "coach", being necessarily an expert, will be better off acting instead of coaching, a point of view which is unfortunate.
Humphrey goes on to press the issue of the responsible software professional and the future of the practicioner. I sympathize with Humphrey; as a group, software professionals do not always act with the responsibility that their profession demands, and the industry could possibly benefit by increasing usage of engineering-style methods, a point made recently by Steve McConnell in After the Gold Rush [McConnell99]; indeed, I feel that the tools and skills learned by practicing the PSP, even in this short study, have benefited me tremendously.