Quality Management in Software Projects

There is a high visibility and aural version of this page
(to listen, you will require an aural browser or screen reader).

Software and Quality

The Quality software company is a good place to work. Quality Management can make the difference between the success and failure of a project; it can bring managed innovation in place of chaos; and it can make for a happy workplace instead of a dead-end.

To achieve this, we need to find a way of applying Quality Management to software. Much Quality Management practice came from areas such as manufacturing. It does not always carry over well to the software industry. But the principles still apply; they just need re-interpreting.

The key is to understand both Software and Quality Management, and how they relate to one another. Books, such as those listed in the Bibliography, and training courses may be useful. Or a consultant can provide training to suit your needs.

Quality for Software Professionals

Developing a Quality System from Scratch

If you are a software person, you may at first find Quality Management strange.

Example: Quality Management documents often stress the importance of calibration of test equipment. What has this to do with software quality?

To answer questions like this, you need to know the concepts and motives that underlie Quality Management, so you can translate them into software terms. (In this case, the software analogue might be control of test programs and data.)

Adapting a Pragmatic Quality System

If you are already using a system that works well for you, you may want to be able to show that it complies with good Quality Management practice.

Example: Your company wants to get into the defence systems market and so needs ISO 9001.

You will not want to clutter this good system with irrelevant jargon. If it does what you need, you can almost certainly justify it in terms of ISO 9001.

The advice that you may receive, to add a lot of boiler-plate on things like purchasing, document control and records, is most likely wrong. The only case where you might want to do this, is if you have a contract that demands a traditional style of Quality System documentation.

Software for Quality Professionals

Extending the Quality System to Software

If software is just a part of your business, you may already have a company-wide Quality System and wish to bring the software within its scope.

Example 1: You supply electronic systems that have a software component.

Example 2: Your in-house I.T. services group supports CAD software for the design department.

If you do not have a background in software, the way in which the software department operates may seem strange and perhaps a little undisciplined. But the differences are not really so great.

Software is Different - But Not Very

The first problem will be that the software people speak a different language.

Example: What Quality people speak of as design, a software engineer will call development. Design means something different to them.

Apart from language, there are some real differences. Software is:

  • intangible - you cannot tell whether it is good or bad by looking at it;
  • quick and deceptively easy to change - so ill-considered changes sometimes cause havoc;
  • complex - the software part of your Quality System may turn out bigger than the rest of it put together;
  • not usually subject to manufacturing faults or to wear and tear, but only to design faults; and
  • most important, a design product. Software development is a design process - so every project is a one-off.

Because of these differences, you will need to gain an understanding of how software projects work. There is no need to become a programmer, but you do need to know the language, the process and the management approach.

Return to Home Page

Links to other pages