Up

An ISO 9000 Approach to Building Quality Software
by

Östen Oskarsson

 

This text is the updated first part of the book with the same title by Östen Oskarsson and Robert L. Glass, published by Prentice Hall in 1995. The text is also available for download in MS Word format as a zip file (113 kB).

The English and German versions of the book are out of print, but a Swedish version is still available from the publisher Studentlitteratur. The English text will be available reprinted as a booklet.

Contents

Preface
1. Background on ISO 9000
2. The use of ISO 9000 with software development
3. Interpreting the requirements in ISO 9001 for software developmentand maintenance
4. Some specific issues
5. Comparisons with other schemes
6. Building a quality system for software

Preface

For many years I have taken part in software development projects, some of which have been successful, and some of which have failed to meet deadlines or functional requirements. I love ISO 9000. Let me tell you why.

In 1987, two major companies, one in Sweden and one in Norway, were jointly purchasing a complex communication system from a well-known European supplier. According to the agreement, the supplier was to deliver the first installation one year after contract. When about half that time had gone, 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 situation actually 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 ended relatively happily. The supplier reorganized and restarted the project and came up with a credible time plan whitch 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 I 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 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 has lots 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.

I hope that this text will help software engineers and managers to improve their performance. Ideally, it should give understanding about quality systems in general and ISO 9000 more specifically..

I have included a number of personal experiences in my text to illustrate my points. Also, reading about other's problems and mistakes tend 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 the reading.

 

December 1999

Östen Oskarsson

Next