<-Prev Next->

I suggest that you start with the first page of Chapter 1 to see why I think that every software professional and most engineers should read this book. Then come back here to find out how.


This book has the goal of most efficiently teaching you what software reliability engineering (SRE) is and how to apply it in developing, testing, or acquiring software-based systems. The book focuses on practice, presenting methods that have been successfully used in many applications, and avoiding ideas that have not yet been sufficiently proved in actual use. As you will see, I focus on helping you with your immediate problems but also take a very broad perspective so you understand and can better function in the total environment. Flexibility and depth in your capabilities adds greatly to your personal competitive strength in these days of globalization and outsourcing. For example, I encourage testers to participate on the system engineering team and directly interface with users of the software-based product. Also, I envision that many “pure” software development personnel will be involved with testing and must therefore have a broad understanding of it.
Thus, you will see particular emphasis on simplifying the material and organizing it for rapid and easy learning. The organization and presentation of the material evolved through 15 years of experience teaching this subject to and consulting with several thousand practitioners in many different organizations and a wide variety of software applications, and guiding them in learning it. I pay special attention to describing the software reliability engineering process step by step. For this reason, the process is organized hierarchically in activities and subactivities. The Table of Contents reinforces this hierarchy and makes it easy to find the detail for any step. Finally, I devoted special effort to preparing an index with multiple terms for recalling a topic.


Each book chapter is divided into six sections: core material, exercises, workshop, special situations, background, and frequently asked questions. You can readily identify the sections by the number immediately after the chapter number and its decimal point. For example, for Chapter 1: 1.1 is core material, 1.2 is exercises, 1.3 is workshop, 1.4 is special situations, 1.5 is background, and 1.6 is frequently asked questions.
If you are a manager, a software professional, or an engineer, start by reading Sections 1.1.1 and 1.1.2 to get an overview. Then proceed to the core sections, Sections 1.1 through 7.1. If you want to reinforce the material you just read, do the exercises in Sections 1.2 through 7.2. You can reinforce the material further by applying it to your project with the aid of the workshops in Sections 1.3 through 7.3. You will probably find it most efficient to complete the three sections for each chapter before you proceed to the next, but this is not an absolute requirement. Some people also read through the frequently asked questions in Sections 1.6 through 7.6 if they want real depth. In effect, you will be sitting in on hundreds of classes and hearing the best questions asked by thousands of participants, and then answered. Some simply use the frequently asked questions as a resource that they access through the index.
If your primary role is to acquire software or software-based systems, I suggest that you primarily read Sections 1.1, 2.1, 3.1, and 6.1.


You may want to skim the special situations Sections 1.4 through 7.4 to see what is there when and if you need this material. Sections 1.5 through 7.5 provide background and support for what is presented in the other sections; I would suggest that you look at them whenever a topic in one of the other sections motivates you to learn more about it.
The core material consists of the material that you need to know for the common situations you will encounter in practice. I present principles that are generic to most software-based systems, so you will have a firm knowledge base that should be useful in the future. The material presentation proceeds step by step, in the same order you will apply it to your project.
The exercises are provided to help fix the core material in your mind; they are developed for everyone but are intended to be particularly useful for university students.


The objective of the series of workshops is to help you apply software reliability engineering to your project or a similar one you select for learning purposes. It should further fix the core material in your mind as you “learn by doing.” It should also help you learn how to adapt and customize the principles as you integrate the software reliability engineering process into your overall software development process. I do not give you a canned project, because it would defeat the purpose of the workshops. However, I do clarify the workshop instructions by showing how you would apply them to Fone Follower, an example used throughout the book. Students need not feel left out here; the practice of giving you experience with actually developing some software is widespread through universities, and such a project will fit in nicely with this set of workshops.
This workshops are particularly effective in a class, where you divide into teams of participants organized on project lines. I have provided templates for the workshops. I encourage you fill them in, because you will then have in one place all the material presented in the book and your application of it to a specific project. This will help guide you in the future.
The special situations sections present techniques that are usually needed only for certain projects and systems.
The background section contains supplementary information that can enrich your understanding of the chapter but is not essential to exercising the practice. For example, it may present theory or explanation that justifies or supports various activities of the practice.


The sections of frequently asked questions provide more than 700 of the best questions (and answers) that have been posed to me in my experience teaching several thousand practitioners and consulting for various organizations. They represent the backgrounds, ways of learning, and perspectives of different people working on different projects. You may find that some of them correspond with yours. Thus they may help you better understand the topics. They are grouped by topic in a structure that parallels that of the core material. Thus, you can delve deeply and broadly into any topic in the core material by following it with the corresponding frequently asked questions section. . Every question is indexed, making it easy to find the answer to a very specialized question. Professors should find many of the frequently asked questions useful to assign as exercises, in addition to the exercises provided at the end of each chapter.


Both the frequently asked questions and the background sections may cover topics already treated in other sections. However, they do so from different perspectives or greater depth. I considered the possibility of integrating this material with the corresponding material in the core sections but deliberately decided not to do so. Most practitioners told me that the core sections should be as simple and short as possible, so that they could learn the essential basics quickly, and that all supplementary material should be separated from them. You may find a few questions that cover similar material, but look at it from slightly different viewpoints. I included both questions in these cases, so that you can profit from the different approaches.


Chapter 1 presents some introductory material concerning how software reliability engineering can help you individually and benefit your project. It then outlines the software reliability engineering process used in practice, which consists of six principal activities. The chapter structure of the book reflects the process. Each of the Chapters 1 through 6 covers one of the principal activities. A unified simple example, Fone Follower, illustrates the process throughout the book. This example is adapted from a real project, but with proprietary data deleted and the material simplified for learning. Chapter 7 discusses how to deploy software reliability engineering in your organization. I strongly recommend that you develop an initial plan for application of software reliability engineering to your project in the Chapter 7 workshop and start using software reliability engineering while your newly acquired knowledge is fresh.


The book does not deal with the details of how to implement software reliability strategies (for example, requirements, design and code reviews); they are well covered elsewhere.


Appendix A provides a step-by-step outline of the software reliability engineering process; I recommend you keep it by your desk as a guide and checkoff list the first time you use software reliability engineering. Appendix B contains a glossary of terms used in this book and Appendix C a summary of the few formulas you may need. Appendix D describes how to use CASRE, the Computer-Aided Software Reliability Estimation tool (Nikora 1994). Although not the only software reliability estimation tool, I chose it because of its convenient graphical user interface and its wide free availability through the internet. I have provided the answers to exercises in Appendix E. Some of the exercises do not have answers that we can provide; many of these relate to the projects of the reader. Appendix F is an extensive sampling of references to papers and articles published by users of software reliability engineering. These papers may be useful to you as models of applications, particularly when the application is similar to yours.


If you are looking for the answer to a specific question, please note that the book has been thoroughly indexed. The Index follows the “most significant word” or “highest information content” principle. Look for the word or words that best differentiate your area of interest from other areas in the general field.


Terms used in the book are carefully defined; they are either from applicable standards or are in wide use. Companies and organizations within companies may have different definitions. Be aware of this to avoid misunderstandings that may cause confusion. I explain most terms “just in time” for use, but sometimes I describe a group of interrelating concepts in the first part of the section where I use them. Numbers can vary widely because of the wide variations in nature of projects and their software-based products. Hence, you should not assume that any numbers used in illustrations in this book are typical of your application.


I personally maintain a regularly updated Software Reliability Engineering website (http://members.aol.com/JohnDMusa/). This has been a stable center for software reliability engineering information since 1996. The site includes a general short overview article that you can send to managers and other persons to tell them about software reliability engineering. It has a list of published articles by those who have applied the practice, a Question of the Month (with answer), information on CASRE and links to a site from which you can download it, links to conferences and other sites, and other resources. Rather than list the links to software reliability engineering information described here that may be transitory, I suggest you access this site.
The site provides information on a course I teach, “More Reliable Software Faster and Cheaper,” that was prepared in coordination with this book. In the course, you apply software reliability engineering to your own job and receive guidance and feedback. There are both classroom and distance learning versions.


This book is the second edition of a book [Musa (1999)] that is directed both to the practitioner and the student practitioner. It has increased in size by about 50 percent and has been thoroughly updated and improved, while paying careful attention to retaining all the qualities that made it so popular in the first place. Thousands of practitioners have helped polish the concepts and processes in the course. I have used these inputs to refine this book.



s