Inroads to Software Quality: How to Guide and Toolkit

Features

• Cover Type: Paperback with 432 pages
• Published by: Prentice Hall PTR; Har/Dsk edition April 13, 1997
• Written in: English
• ISBN 10 Number: 0132384035
• ISBN 13 Number: 978-0132384032
• Book Dimensions: 9.1 x 7.2 x 1 inches
• Weighs: 1.4 pounds

The publisher, Prentice-Hall ECS Professional
A revolutionary new paradigm for software quality and process improvement. This book will help software organizations build in quality cost-effectively, starting before products are developed. It is a highly-readable, non-theoretical guide to software quality improvement. It includes 18 "filters" that software development managers can use to instill quality throughout the development process. It presents techniques that can lead to a dramatic reduction in expensive, time-consuming functional testing. Readers can also review all the leading process improvement tools. For managers responsible for quality processes, directors of R&D, development engineers, software testers and QA managers, process improvement engineers, business and engineering faculty, corporate trainers and ISO 9000 implementors.

From the Inside Flap
Welcome to Inroads to software Quality.


As we compiled this book, we recognized that there are several traditions associated with software quality.


The old-fashioned methods of building software, with various attempts to "fix things up" after the fact.


The new quality-oriented methods, as characterized by total quality management, ISO 9000, SEI CMM levels, and the Malcolm Baldrige National Quality Awards, among others.


A new shift of paradigm which radically changes how software is built and delivered, which eliminates the need to perform traditional functional testing, in terms of unit testing, integration- and system-level functional testing, and regression testing. This is based on a well-defined, disciplined quality process. As you might expect, it is a controversial approach. It allows more time for performing behavioral testing. Normally, testing experts refer to functional testing as being the same thing as black box testing, and often, these are referred to as behavioral testing. We will use behavioral testing to relate to how a software system performs, rather than what it does.
The product delivery process which implements this paradigm is based on market-driven product development, using filters to build quality into deliverables, and designing quality into software products at the outset. The process is based on constant feedback and continuous process improvement.

Most companies are attempting to move from the first approach to the second. Almost all quality initiatives are based on the second approach, so we will present that approach as the basic method for improving the quality of products. In addition, we will present a preliminary view of the new paradigm and show why it works and what a awesome positive impact it can have on software quality-and on cost and schedule. Although software development and testing concepts can quickly become very complex, we attempt to keep this book as an easy-to-follow training guide that offers traditional quality assurance activities and core elements of testing required to improve the quality of the products.


In addition, we will provide new definitions of software quality and show techniques for achieving a higher level of quality than has been previously possible for most companies. In order to keep these techniques simple, some of them may appear dated; others may have different names and definitions from the standard. We will try to state the pro's and con's of each of these and provide ref- erences to sources of the various approaches.


A lot of what we present will be in the spirit of the quality concepts of W. Edwards Deming as described by Hahn (1995). You may be surprised to find that when these concepts are actually laid alongside the traditional software quality practices, they become very controversial. They have a major impact on the con- cepts of inspections, application of statistical quality control, inferential statis- tics as opposed to analytical statistics (case studies), software development strategies, life cycle models, software delivery systems, and testing.


There is a temptation to take each of the traditional and new testing tech- niques and critique them in terms of our new paradigm, but that would go beyond the purpose of this book. This book is mainly about quality and quality processes and not about testing. Many of the testing concepts summarized in this book are considered to be dated. Newer concepts, such as those found in Beizer (1991, 1995), come from the current refereed literature. Unfortunately, they are also based on the fact that the code must be taken as it has been programmed and tested in that state.


Our approach shows that much of what the new test techniques test for can be designed out. Many of the new techniques do not test against interface stan- dards such as Microsoft® Windows®, etc. Nor do they test for problems related to event-driven environments. With good design, it is possible to make an entire software system deterministic rather than stochastic. This makes it possible to predict and create whatever condition you want to examine.


Because of the extreme importance of management commitment and disci- pline within the framework of the new paradigm, the book will outline the importance of managing software development and provide a strategy for doing so. Apart from this, there will be no general discussions of personnel manage- ment, statistical quality control, or the concepts of code complexity or estimation. We will present a software development strategy which provides the basis for the new software development paradigm.


The book will present information in layers. Rather than trying to cover all aspects of a topic in one place, the book presents information in small, nonintim- idating chapters. In addition, there is a chapter on the relationship among total quality management and our concepts of software quality, managing risks, and the use of the new paradigm to increase quality. The most important aspect of this book is that each chapter contains detailed instructions on how to conduct some of the activities discussed and each chapter can be read independently. This calls for some duplication of terms and ideas throughout the book.


An introductory chapter on the techniques for process assurance is followed by a chapter on product assurance, techniques for product assurance, and plan- ning and organization. Chapters 3 through 6 cover software quality assurance, software quality standards, an overview of test cycles, and test planning. Chap- ter 6 gives details on how to develop a test plan and test cases. Samples, outlines, and templates for a test plan and a test case are included. The two chapters that follow discuss software quality assurance reviews and basic concepts of software measurement. Chapter 7 outlines objectives, techniques, and guidelines for con- ducting successful quality assurance reviews. Chapter 8 focuses on how to start a measurement program, important issues, and some of the most commonly used engineering measures in the software. Chapter 9 presents a seven-step process improvement road map, with details on activities to be performed and other con- siderations. Chapter ten discusses standards and evaluation of the software development process in the context of ISO 9000-3 and SEI maturity model. The final chapter addresses the process of achieving total quality management and how to minimize the risks involved in developing quality products.


The Appendix provides various checklists that can be used in their present format or customized, depending on your requirements and the size of your project. If these checklists are enhanced by defining the "quality" and "accuracy" required for each item, then these checklists become filters. The Appendix also includes a description of some front-end filters and an example of the Configuration Control Board Impact Assessment document, which can be extremely useful in helping manage change.


The accompanying DOS-format diskette duplicates the content of the Appendix for use on your Mac or PC in three word-processing programs: WordPerfect® 5.1 for Windows, Microsoft Word® 5.1 for Macintosh®, and Microsoft Word 2.0 for Windows. The files are separated in two portions: "Templates/Checklists" and "Descriptions of Front-End Filters for Product Deliv- ery Process." The WordPerfect files have the extension .wp, the Microsoft Word for Windows files have the extension .msw, and the Word for Mac files have the extension .mac.


Inroads to software Quality is based on our experience over many years and the input of a large number of individuals and organizations. We therefore have not attempted to tie all the concepts back to a particular human being or refer- ence. Where we think you might benefit from additional reading, we have pro- vided references.


In summary, this book is intended to appeal to a broad range of readers, including:


individuals with little computer background wanting to begin a quality assurance program


those with testing backgrounds who want advice as to how to implement an effective testing program


testing personnel who wish a quick overview of the testing field


programmers who want to improve the quality of their code


software developers and architects who want to improve the quality of their software architectures and designs


software managers who wish to install a measurement program to help them evaluate their quality processes


high-level managers, middle-level managers, and software managers who wish to implement an effective quality program wherein quality is defined from a marketability point of view and is designed in at the start


There should be no need for prerequisites to be able to read this book. But the reader should have an orientation or context based on

Reader Reviews
This book originally attracted me for the checklists that are contained in the appendix and for its promise of a new paradigm in software quality assurance. However while reading this book - and I tend to be thorough - I became thoroughly dismayed. First, this book has all the appearances of not having been reviewed. Basic author craftmanship is not evident. Instances of bad style are common. In many places it becomes somewhat incoherent - sometimes to the point that I could not understand what was intended to be conveyed. With the exception of the checklists the book's contents fail to live up to expectations. Sometimes I got the impression, that chapters had been written to make up the page numbers. And I was left wondering whether the author really understood what they were writing. Take for instance the following quote, which is part of a critique on OO technologies: "Inheritance always causes dependencies! These can be eliminated through fancy footwork, but the question is: 'Why Bother?'" (You might also ask, what a critique of OO technologies has to do with a book on SW quality, but the authors display a tendency to editorialize). In other areas the book simply does not deliver at all. Here are some examples: For instance in the chapter "Techniques For Process Assurance" under the heading "Project Team"(?) the authors provide 7 lines on how important good team selection is but fail to provide any references on how to create them (such as Lister and DeMarco's Peopleware). A project team has nothing to do with techniques and the authors would have done better to remove the topic rather than try to cover such a complex area in 7 lines. Likewise the chapter "Software Quality Assurance Reviews" sounds like a copy of the IEEE standards. But no information is given how to make these reviews actually work. The entries in the bibliographic reference section give the impression of not having been carefully selected. The above mentioned area on reviews and inspections fails to mention Gilb's book on inspections and only refers to a publication by Fagan on this topic. In two of the appendices, several pages of text are repeated word for word. The proof reader must have fallen asleep. The authors proclaim their product delivery process is a 'new paradigm.' After having read the book I cannot see a new paradigm (apart from the misuse of the term). What is new in checklists? - many companies have them because they are very effective. What is new in market oriented reviews? My overall impression is that the authors have a good collection of checklists, that they wanted to turn into a book. It appears to me that they then added, seemingly at random, more information to it to make up the volumne. The result backfires badly, because it turned a decent nucleus into a book that I find not worth buying. In fact, this is the first time in my life I have returned a book to the vendor.