Prentice Hall were kind enough to send me a copy of Design for Trustworthy Computing, after it caught my eye at the SEPG conference. It looked liked it was packed with quality material that I'd never seen aggregated in to a software book - techniques including TRIZ, AHP and QFD were all mentioned. I flicked through the book on the bus in to work last week and was impressed enough to hand it off to Corey Ladas in our Process Engineering team. Here is Corey's in-depth review as today's Guest Blogger at Agile Management...

This book was inevitable. It's essentially Design for Six Sigma for Software, and as far as DFSS books go, this is a good one. The audience for this book is on the upper end of technical management, people who can see the big picture and distill practical guidance from abstract methodology. Engineering professors, professional methodologists, senior architects or program managers, or directors or vice presidents of engineering will get the most out of this book. Your typical individual engineers or line managers are probably not going to make much sense of this unless they have a particular interest in methodology (i.e. your future managers).

Historically, software engineering has invested most of its quality control effort into verifying systems against requirements. This is probably due to the inherently mathematical nature of the domain and its participants. There are powerful methods for analyzing both the syntax and semantics of software design specifications (i.e. source code) with respect to requirements. Almost as a side effect, the discipline has also produced related methods for verifying the correctness of requirements specifications themselves, at least at the level of syntax. But software engineering has severely neglected the fuzzy customer end of the relationship for many years. All the formal methods in the world are still subject to "garbage in, garbage out," and traditional software requirements analysis methods produce a great deal of garbage indeed.

Consequently, software got stuck in the "conformance to requirements" mentality of quality control for decades. Only recently has the software development world begun to consider "fitness for use" with any kind of systematic seriousness, and then often at the expense of engineering rigor. By contrast, Japanese product developers began to embrace more customer focused methods since at least the 1960's and the rest of the world has been chasing them ever since. Design for Six Sigma (and its precursor in Quality Function Deployment) represents the best of current thought into the importance of comprehensive understanding of the customer and early customer validation of requirements. DFSS also brings a much more realistic statistical understanding of product quality, in contrast to the formal/logical software paradigm.

There are two likely approaches to writing a DFSS for Software book. One is to start with a conventional software engineering model and terminology and pull DFSS ideas into it. Another is to adopt the point of view of DFSS-style product development and map it to software development. Design for Trustworthy Software is an example of the latter. The book aims to be fairly comprehensive in its scope, including both project and organizational guidance as well as detailed descriptions of DFSS practices and their application to software development. The book is organized into 5 parts, and for a book this size, a few well-placed tape flags can do wonders for navigational context. If you already know why you want to commit to a Trustworthy Software initiative, then parts 2 and 3 will be the most useful, as they contain the most practical direction on "what to to and when to do it." My only lament here is the omission of Axiomatic Design, which represents the most rigorous thinking in DFSS and is highly applicable to software development.

A few bold thinkers have been integrating the two paradigms of Product Development and Software Engineering for a while now, but this book represents one of the first truly definitive statements about a new and more comprehensive view of software product quality. Software engineering has always suffered from a sense of skepticism about its worthiness as an engineering discipline. For the first time, reconciliation with other engineering disciplines seems feasible, with the language of Design for Six Sigma as the common ground.

For the appropriate audience, this book is highly recommended.