According to the agreement, the supplier was to deliver the first installation one year after contract. When about half that time had passed, the supplier announced a delay, indicating software problems. The supplier now estimated the development time to be twice what the contract said (i.e., two years). This was when I was employed as a consultant by the customers to help them find out what the actual situation was with the supplier. We visited the supplier's software development site, and spent one week interviewing managers and software engineers and reading documentation.

The conclusion was clear: The project was out of control, and the new two-year estimate was not reliable. I helped the customers put pressure on the supplier, giving a long list of what had to be done about the project. The story had a relatively happy ending. The supplier reorganized and restarted the project, and came up with a credible time plan which ended up with a total project time of three years, three times what was contracted.

At the cost of tripling the software effort, the supplier was also able to meet the three-year deadline and deliver on time. This was the first time I had really seen the software problems with the customer's eyes, and I realized that almost all the shortcomings I had noted had to do with management, not technology. After I had presented my description of the supplier's shortcomings at a meeting, one of the programmers took me aside and said, "I'm very happy that you said what you did. We programmers have argued with management about this for years, but now perhaps something will happen." I realized that the problems I had seen when working myself with software had also mainly been managerial.

This is why I love ISO 9000. Its basic requirement is simply that there be adequate management of whatever activities are involved in creating products: don't promise what you can't meet; properly plan and manage development projects; and so on. If the customers mentioned above had forced the supplier to fulfill ISO 9000, or if the supplier on his own accord had chosen to work to the standard, there may still have been problems with the project, and there may have been errors in the product, but there would have been nothing at all like the total collapse we saw. ISO 9000 is not necessarily the best way to put quality requirements on a software developing organization, and it must be used with care and intelligence when applied to software. But what is important is that it carries a lot of weight.

The standard is widely accepted and used in almost all branches of industry throughout Europe and in many other parts of the world. Thus, when a customer includes a requirement for ISO 9000 in a contract, the supplier is unlikely to question it. If he does not already comply with the standard, he will probably not argue against the requirement.

When Bob Glass proposed this book as a joint project, I immediately became interested. I saw an opportunity to expand on some of my favorite hobbyhorses and, at the same time, hopefully give useful advice to software managers seeking ways to improve the capabilities of their organizations. Of course, I had previous acquaintance with Bob's impressive production of books about computing catastrophes and other entertaining subjects, as well as his more serious approaches to software engineering. I had especially enjoyed his book Building Quality Software, which I think gives much of the practical advise so many software managers are seeking. What I especially like is that his book avoids all the current talk about a software crisis, instead taking the positive approach of pointing to ways to improve software engendering still further.

I hope that our book will help software engineers and managers to improve their performance. Ideally, my text should provide a general understanding of quality systems in general and ISO 9000 in particular. The reader should then go on to Bob's wide-ranging and sometimes provocative text where the different options and issues involved with the actual development of software are explored. I see myself as the down-to-earth advisor relying on practical experience, discussing management, control, and other dull subjects. Bob is the provocative and free-ranging researcher, sharing with you his deep insight into the fascinating area of doing software development. I have included a number of personal experiences in my text to illustrate my points.

Also, reading about other's problems and mistakes tends to be fun. Remember that we should learn from the mistakes of others; life is too short for us to make them all ourselves. I hope you enjoy reading this book.

Östen Oskarsson Spring 1995

3. PREFACE
(Robert L. Glass)

I first became aware of ISO 9000 and its impact on software in an unfortunate way. I had been brought to Helsinki to give a seminar on software quality to a Finnish audience, and in an early interaction one of the attends asked me about a "Quality System." My response was to ask the attendee the same question with a slightly different inflection; "What is a Quality System?" It slowly emerged from the ensuing discussion that the audience had come to the seminar seeking advice on how to build a Quality System as required by ISO 9000, and (because I had not yet heard of ISO 9000) my presentation was of little help to them in that regard!

There wasn't much I could do to recover from that debacle at the seminar, but I made a point of trying to get smacker about ISO 9000 shortly after I returned home. With the help of some European colleagues, including Östen Oskarsson of Sweden, I began to gather the information-and the documentation-that I needed for my learning experience. But there was still a problem. The more I read about ISO 9000, the less interested in it I became.

My interest in software quality has always been from the technical point of view. I strongly believe that the task of building a quality software product belongs to technologists and only peripherally to managers and, in fact, that management's typical role of pressuring technologists to put quality into the product is really counterproductive.

I agree with Tom DeMarco, who says that the competent software professional inherently wants to build a quality product, and management's appropriate role is to remove the barriers that prevent him or her from doing so. Yet the quality viewpoint taken by ISO 9000 is solidly in the quality management camp rather than the quality technology camp. ISO 9000 contains a lot of "thou shalts" and little technical advice on how to accomplish what it requires. Furthermore, my view of what it contained, at that early stage in my ISO 9000 knowledge-gathering, was that its "thou shalts" were pretty superficial. They might (or might not) assist the software technologist in building a quality product, but they didn't get at the essence, the technology, of quality.

Time passed, and I resisted getting any further interested in ISO 9000. But as that time passed, my European colleagues got more and more involved in the application of ISO 9000 to software, and it soon became apparent that the standard was beginning to spread across the Atlantic as well. For example, in [Yourdon 1994] the author said things like "How does [a software company] inspire confidence when it makes such claims as ... `we deliver high quality software'? ... By achieving level-5 SEI status, and by achieving ISO 9000 certification." Another writer worth reading, P. J. Plauger [Plauger 1995], said, "ISO 9000 as a selling point depends largely on your customers. Those who demand it will settle for no less..." As author of the book Building Quality Software (Prentice Hall, 1992) and a lecturer on the material it contained, I realized that I could ignore the standard no longer.

Meanwhile, Östen Oskarsson contacted me about some book projects-he had written a Swedish-language book on small software projects, and was interested in the possibility of my helping translate it into American (!)-and we renewed our discussion of ISO 9000. Östen was involved in more and more ISO 9000 consulting work, and was becoming more and more convinced of its value. Since over the years I have come to believe in Östen's beliefs-his Ph.D. thesis was an impressive case study of an early industrial object-oriented software project, for example (Sweden pioneered the application of OO approaches at the communication company Ericsson)-I was prepared to listen when Östen discussed ISO 9000.

Following Östen's interest, I took another look at the standard, discussed my reservations with him, and committed to working with him to write this book. We decided on a division of labor that relied on Östen's expertise to present and discuss the standard itself, and my background in the technology of software quality to bridge the gaps between what the standard required and what building quality software (in my view, at least) is really all about. And we made one other decision.

This book, our book, would be written as a companion to Building Quality Software (BQS). That is, for the reader who already knew what was in BQS, this new book could stand alone. But for the reader who was still struggling with how to achieve quality software, this book would present ISO-9000-related information, but refer broadly to BQS for the details and references necessary to translate ideas into implementations. In other words, if the treatment of a topic in this book is too terse, the reader is encouraged to refer to the same topic in BQS, where the treatment would be more complete. In fact, that was the reason for the title of this book. An ISO 9000 Approach to Building Quality Software has two meanings: to provide guidance to those who want to build a quality software product, of course, but also as a supplement to BQS that makes it relevant to ISO 9000.

That was the platform upon which we began to erect the structure of this book, and we have continued on that platform, largely unchanged. As I reread ISO 9000 in order to do this book, however, I began to gain a new appreciation for what it was really about. I believe there are three things about the standard that one must understand in order to appreciate it:

1. It is a tool for customers buying software more than for developers building it.

2. It is about what, not how. The standard requires that certain goals be achieved, but it says little about how to achieve them.

3. It is about things that are necessary, but by no means sufficient. The standard requires that a number of important goals be achieved, but the achievement of those goals does not ensure that a quality software product will result. The first two points above, I believe, are ones with which most ISO standards enthusiasts would agree. The third may be more problematic. There is a clear implication throughout the standard that following its dictates will ensure a quality product.

There are two problems with ISO 9000 that account for this difference of opinion, I believe:

1. The standard was defined by quality people. That is, the originators of the standard knew a lot about quality, but little about the discipline to which it is applied. This is particularly problematic with software, a discipline so unusual that its product has no weight, costs nothing to manufacture, is created by brainpower, and requires no raw materials to produce.

2. The standard was originated in the manufacturing world. In that world, "what" is more easily translated into "how," and the gap between necessary and sufficient is (by contrast) relatively small. What is complicated about manufacturing disciplines is often the process of manufacturing itself. But in software, the complication lies in analysis and design, and manufacturing is trivial. Thus, the fertile field that gave rise to ISO 9000 could not have been further from the needs of software. Even the attempts to make the standard relevant to software-ISO 9000-3 and some of the national approaches to interpreting the standard, such as England's TickIT- could not fill the gap between what and how, and between necessary and sufficient. This gap has been noted elsewhere for example, in [Avison 1994]. It was the task of filling that gap that Östen and I set out to fulfill.

In the final analysis, here is what I believe Östen and I have accomplished in this book. Östen, knowledgeable in the what and why of the standard, has done an excellent job of sharing with the reader what the standard is, how it is to be applied, where it stands in the overall world of software quality approaches, and what has happened in specific applications of the standard. I personally find his "war stories," for example, a high point - and a major contribution-of this book.

What I hope I have accomplished, on the other hand, is a narrowing of the gaps between what and how, and necessary and sufficient. Given that I believe adherence to the standard does not necessarily guarantee a quality software product, I have tried to provide the insight needed to supplement the standard and improve its chances of accomplishing what its originators wanted it to achieve.

The resulting book may represent something of an odd couple: Östen describing ISO 9000 and its benefits, and me chiding the standard and trying to offer what it does not! I hope those differences do not significantly bother the reader, because I believe that the result is a blend that will make ISO 9000 truly useful, the standard that it was intended to be all along. It all reminds me of that wonderful little book The Elements of Style by Strunk and White, a classic in the field of English and writing. In that book, Strunk is the pedantic instructor, laying out terse stylistic rule after terse stylistic rule, and White is the master stylist, exhibiting what writing with style really means.

The book moves schizophrenically from Strunk's part I to White's Part II. But the whole is a magnificant blend of what the reader needs to know to write with style. It is presumptuous to even wish that this book could be for software quality what The Elements of Style is for writing. The classic contribution of Strunk and White is too massive to be belittled by weak analogy. But you understand what I am trying to say.

Given that Östen and I bring very different things to the ISO 9000 table, I hope these things blend well in this book. In the final analysis, you are the judge. [Avison 1994] D. E. Avison, H. U. Shah, and D. N. Wilson "Software Quality Standards in Practice: The Limitations of Using ISO-9001 to Support Software Development," Software Quality Journal 3, 105-111; 1994. [Plauger 1995] P. J. Plauger, "Playing it Safer," Embedded Computer Systems, Jan. 1995. [Yourdon 1994] Ed Yourdon, Guerilla Programmer, p. 3, Sept. 1994.

Robert L. Glass Spring, 1995

4. ABOUT THE AUTHORS

Östen Oskarsson is currently running his own one-man consultancy firm in Linköping, Sweden, specializing in quality assurance of software development and maintenance. Assignments include support to software suppliers regarding methods and management; support to the customer side of software acquisitions; and ISO 9001 certification of software organizations. Mr. Oskarsson has been working in the European software industry for 15 years, first employed at the communications system supplier Ericsson and the defense system group FFV, and later as a consultant. Beginning in 1987, he has conducted about 100 software quality audits of European organizations to ISO 9001 and other standards.

Östen Oskarsson received a Ph.D. in computer science from Linkping University in 1982, and he became a registered TickIT auditor in 1993. Mr. Oskarsson is the author of two Swedish books: Software Quality Assurance (with Christer v Schantz), Industrifrlaget, 1990, and Small- Scale Software Development, Studentlitteratur, 1994.

Robert L. Glass is President of Computing Trends, publishers of The Software Practitioner. He has been active in the field of computing and software for over 40 years, largely in industry but also as an academic. In industry, he has managed projects, built and maintained software for most application domains, and engaged in research and development. In academe, he taught for five years in the software engineering graduate program at Seattle University, was a visiting professor for several summers at Linkping University in Sweden, and spent a year at the Software Engineering Institute at Carnegie-Mellon University.

He is the author of 19 books and 49 published papers on computing and software, editor of the Journal of Systems and Software, publisher and editor of The Software Practitioner, and was for 15 years a Lecturer for the Association for Computing Machinery. He received an honorary Ph.D. from Linkping University, Sweden, in 1995.

Regarding software quality, Glass has taught seminars on the subject in industry, taught a course on the subject at Seattle University, and written three previous books on the subject:

Building Quality Software, Prentice Hall, 1992 Measuring Software Design Quality, with David N. Card, Prentice Hall, 1990 Software Reliability Guidebook, Prentice Hall, 1979.