The Personal Software Process (PSP) is a framework for estimating and planning software development, tracking performance against these plans, and improving the quality of the resulting programs. This book introduces those parts of PSP that can be used by individual software engineers. It covers neither statistical methods nor the management of large projects. Chapters 1 through 10 present the time management techniques PSP is based on; the remaining ten chapters discuss the application of these principles to software projects.
The first chapters describe a procedure for tracking and recording the way people spend their time and introduce some forms to support this, such as time logs and weekly activity summaries. In chapter 5, the author starts to focus on the product. In this book, the product is understood in a broad sense, as any activity that leads to a well-defined goal. (One of the author’s examples is reading his book.) Chapters 6 and 7 consider project planning using time log data; estimating product size (that is, the time needed to reach a defined goal); and making a time budget. Chapter 8 introduces personal commitments software engineers should make to themselves and emphasizes their importance for meeting a time budget. Chapters 9 and 10 show how to use schedules to track the progress of one’s work and include time estimation in project planning. This first part of the book, which is only concerned with time management, may intimidate computer science students and, even more so, practitioners. It is only at the end of the tenth chapter that the reader finds the first form related to software development, but these chapters are a prerequisite for what follows.
Chapter 11 switches over to the application of time management techniques to software development. First, the author defines the well-known phases of software development and encourages the reader to estimate the time to be spent in each phase and to compare these estimates to the actual data afterward. These data can be used to improve software quality, since they show how much time is spent repairing defects. The next three chapters address the nature of software defects. (Humphrey prefers this term because he believes the term “bug” plays down the problem.) These chapters include a thorough discussion of defect types, a summary of principal ways to find defects, and examples of code review checklists. Chapters 15 and 16 discuss ways to analyze defect data and to project the number of defects that will be injected and removed in each phase. In chapter 17, the author considers the special importance of design defects.
Chapter 18 focuses on how the software engineer’s working discipline affects the qualify of products and illustrates the relationship between the number of defects found during compiling and testing and the number left in the product. The author then gives some measures that software engineers can use to evaluate the quality of their work. The conclusion emphasizes the importance of establishing quality as the highest priority.
The author’s message is that software engineers who spend most of their time finding and fixing defects are not performing professionally. This book should help software engineers identify weaknesses in the way they solve software problems.
The book is meant to be used in conjunction with a two-semester introductory course and, as such, includes an instructor’s guide. Each chapter covers a single topic and presents forms and checklists to support the disciplined use of that material. In the second part of the book, the main form under discussion is the Project Plan Summary form, part of which is to be completed in each chapter.
Overall, I can recommend this textbook, although many students may find it difficult to fill in the forms in a disciplined way. A foreword by some students who have taken the course recommends doing so. Unfortunately, there are only a few references, and they are not collected in a bibliography.
