I have heard about Musa’s work on software reliability engineering for most of my professional career. To be honest, I have been a bit turned off by it, because, first, it seemed somehow unrealistic in a software world where quantitative approaches feel more unrealistic than qualitative ones, and, second, the math involved in most initial presentations of the material seemed daunting, even to this once-upon-a-time math major.

So, I leapt at the chance to review this second edition of Musa’s book (first published in 1999 [1]), albeit with considerable misgivings. The arrival of the book did little to diminish those misgivings. But, upon cracking open the book’s cover, I found myself pleasantly surprised. The book is eminently readable. It minimizes its math content. It is chock full of exercises, workshops, “special situation” discussions, background supplements, and many frequently asked questions and their articulate responses.

What is software reliability engineering (SRE), and what is it good for? The author opens the book by saying (as his subtitle says) that the approach is about a “better way to develop software,” a way that is “quantitatively based.” The essence of SRE is its focus on “operational profiles, random process, software reliability models, statistical estimation, and sequential sampling theory.” Its usage involves six primary activities: defining the project, implementing operational profiles, engineering the “just right” reliability, preparing for testing, executing the test, and guiding the test (there is a major chapter devoted to each of those activities). The audience for the book is “software testers, systems engineers, system architects, acquirers of software, quality assurance engineers, reliability engineers, development managers, and students.”

That brings us to the subject of what SRE is good for. Quite a bit of the book is devoted to that topic (the book is part user manual, part sales brochure, and part tutorial, but those three parts are integrated in such a way that you hardly notice them). Musa provides lots of cheerleading data: he notes that “SRE is low in cost, and its implementation has virtually no schedule impact,” and he cites benefits at AT&T, where it has been a “Best Current Practice” since 1991. The author names 24 leading companies that have used SRE, including Microsoft and IBM, and notes that it is a standard at both the Institute of Electrical and Electronics Engineers (IEEE) and the American Institute of Aeronautics and Astronautics (AIAA). SRE has been around, the author says, since its early beginning in 1973. It is intended to focus on user-oriented, rather than developer-oriented, notions of reliability (the author says it is more about operation than about softw!are design).

The book has its quirks. It includes “rapid delivery” and “low cost” as quality attributes. It says that the method is appropriate for maintenance, but its heart seems to be largely in development. It spends little time on ways to choose test cases, in spite of the fact that its chapter on preparing for testing is quite long (there is much more on choosing an appropriate number of test cases, reinforcing my early feeling that the book was quantitative when qualitative might be more appropriate). In spite of its heavy use of the term “just right” with respect to reliability, a definition or explanation of that term was not apparent in the chapter with that term in the title, and the term was present in neither the glossary nor the index.

Given the claims for the approach, and its apparent broad standardization and usage, getting to know this book could be quite important to software project people. I recommend it, as both an exposure to the notions of SRE, for the purpose of making a decision about its use, and as a user manual and tutorial if you decide to proceed with its implementation.