Review By: Howard S. Epstein
09/16/2004"Software Engineering for Small Projects: A RUP-Centric Approach," was written by a small project team and is about a tool its members developed to support the Personal Software Process (PSP). During development, they follow the primary tenets of the Rational Unified Process, or RUP. This slim publication covers quite a bit of ground, and the reader will learn a lot about different topics in software development.

The book is written in a conversational tone and guides the reader through the four phases of RUP – from the beginning of the project (known in RUP as the inception phase) through the architecture design (elaboration phase), construction, and delivery (transition phase). The real focus is on the overall experience of developing a PSP tool that tracks and reports a developer's activities. The authors focus on the interactions between team members –what went well and what did not go so well during the project. The authors also provide tips that can aid other project efforts.

The book starts with a guide that explains how to apply the authors' process to other small projects. They advise the reader not to stick religiously to the principles any process provides. Instead, be smart, use common sense, and use the components of a process that apply to your project. For example, do not create any artifact (project deliverable) just because the process indicates it should be created.

Pollice et al. also detail the history of the project. The authors advise non-technical readers that skipping the technical solutions in the book is acceptable. Conversely, they feel providing design details and code constructs used to overcome challenges faced by team members is important to the reader's development.

The book ends with a post-mortem of the project from each author's perspective of what went well and what could have gone better if the project had to be redone. The book closes with three appendices: one provides an overview of RUP, one describes Watt Humphrey's PSP, and one outlines the basic "rules" of Extreme Programming.

The book's style is more interesting and engaging than the usual run-of-the-mill book on programming or process. At 250 pages, the book packs in advice on managing smaller projects effectively, using RUP for minor efforts, and how people issues can drag down a project even when the team consists of four or five people.

I recommend this book for its lessons, but I wish the authors would have gone deeper into the various problems they faced and how/why the team arrived at the solutions it did (or how they would have done things differently given a second chance). Too many pages are dedicated to the innards of the technology and how the code is written. A non-technical reader will most likely get lost in these chapters. On the other hand, a technical reader will find these discussions too elementary and will probably consult other programming guides for more information. Therefore, these chapters add little value to the book.

I recommend this book for small-project managers facing the following hurdles: a team learning to use a new process or deal with a new technology, a team that co-located during the course of the project, and a team with competing priorities that could hinder a project's success.