Browse Books

Reviewer: Robert L. Glass

I am a long-time Capability Maturity Model (CMM) skeptic. Of course, in saying that, I realize that I am out of step with most of the software engineering community, which is wholeheartedly supportive of CMM as a way of better building better software. Still, I have to admit that that was my incoming bias as I reviewed this book. I was, therefore, pleased, as I went through the book, to discover sections that had been written by a self-confessed "process agnostic,"? and another by a "doubter turned believer."? So at least I didn't feel alone and isolated in my biases! All of that may explain one of the conclusions that I came to after looking at the book. CMM and what it has evolved into, such as this book's Capability Maturity Model Integration for Development (CMMI-Dev), may be beginning to tax the intellectual ability of its technologists to embrace it. Take the following as an example. CMMI now makes a distinction between "capability levels"? (which range from 0 to 3, making four such levels) and "maturity levels"? (which range from 1 to 5). The book is fairly clear in differentiating between the two, but still, following its description of the former (0-3, remember), the book includes a section by a guest author that refers to "level 5."? It is not until several pages later that the book describes the latter of the two level approaches, thus legitimizing that reference to "level 5,"? but too late. Next, further confusing at least the skeptic in me, is another distinction between "continuous"? and "staged"? lenses for examining process achievement. What did I like about the book__?__ I liked the "perspectives"? material by 20 or so guest contributors, giving their insights into the material being covered; the newly added case studies, including the "process agnostic"? and "process doubter"? ones, which do a nice job of adding some reality to the basic CMMI discussion (one of those case studies includes a failed attempt to install CMMI, and a very good analysis of what went wrong and how the problems were, eventually, overcome); and the addition of agile methods in this third edition (sentences that begin "In agile environments..."?). The book has some quirks, which I liked less. The authors studiously avoid using the term "software"? throughout the book, apparently because the decision has been made to extend the impact of CMMI to systems, not just software. Also, the book calls itself a "document,"? often refusing to use the word "book"? when it seems appropriate; this gave me the feeling of reading a government document rather than a published book. The book (document) is written by three key Software Engineering Institute (SEI) employees who are the ranking experts in their subject area, and that is a good thing. It is also written in a somewhat stodgy manner, and with an enthusiasm for the approach that borders on bragging. So, in summary, what is the book about__?__ "CMMI-Dev consists of best practices that address development activities applied to products and services ... from conception through delivery and maintenance."? (Note, once again, the absence of the word "software."?) Furthermore, "it describes 22 process areas ... of which 16 are core."? If you are new to the whole CMM movement, and want to begin with the latest, this is probably the right place to start. If you are a CMM veteran, and want to begin with what's new, this book is less effective, although it does give directions for how to read it in those circumstances. Online Computing Reviews Service