Review By: Mike Carl
09/02/2003The book explores the problem space where following a generic (e.g., “off the shelf”) software development process is not sufficient, and probably will not lead to a quality process. A quality process is viewed as being independent of a software process with the purpose of ensuring the software process produces quality models and ultimately quality products. The author explains the role that UML plays in a quality software process, as well as sizing up the inherent quality of UML’s viewed representation, specification, and construction.

The book emphasizes the role of quality management in a software project and describes the formation and psychology of teams. This stems from the author noting, “In the final analysis people produce quality.” The author’s Quality Process Architecture introduces many process components available to a company for building a quality software process. After detailing the various components, the following chapter describes how to configure a software engineering process from these components.

In order to deliver quality software on schedule, project management will need to correctly scope the size of the work involved and estimate the time to complete the various tasks. The book promotes the need for good estimates and suggests using metrics such as size of software and measures of UML artifacts as avenues for improving these estimates.

The author finishes with a focus on testing activities that are key to the quality control portion of a development process.

The book comes bundled with a CDROM that provides electronic access to much of the material covered throughout the book. Some of the more noteworthy material includes an extensive template created in Microsoft Project listing all the various activities and tasks that comprise the Quality Process Architecture presented in Chapter 3 and a PowerPoint presentation that graphically depicts the major points discussed throughout the book.

The book provides a practical, common sense approach to layering a quality process on top of a UML based project. Readers lacking experience with or exposure to the CMMi Level 2 or higher will clearly gain the most from this book. A more experienced audience might find the material to be familiar ground. The text covers the complete product life cycle and delivers useful information for each member of a project team. Given how approachable I found the material to be, I would like to see this book become part of all software development / project management curriculums.

I enjoyed his application of Transactional Analysis (TA) to profiling the personalities found in software development teams. It was comforting to read about the “games” I’ve seen played out in projects that I’ve lived through. Identifying the destructive game playing is a good first step. However, additional advice on avoiding or stopping game playing would have been useful here.

The author briefly mentions CMM when discussing how to measure process maturity and its impact on quality. I would have liked to see more comparison between the process components described in Chapter 3 to the requirements of CMM level 2 or higher.

In general, I found the discussion of “Enacting the Quality Software Process” to be interesting as a checklist of what to consider when putting a process into production. The discussion of “Estimates and Metrics for Projects” even though well organized, managed to cover familiar ground. On the other hand, I found an excellent overview to measuring software size in order to gain insight into a project’s timetable. Given the extensive ground covered, I believe readers will find interesting and useful information throughout this book.