Is ISO 9001 relevant to software?

Today, software customers are clearly going global
and are demanding quality.  Given the stakes involved, it is important
for software organizations to understand all the rules for self-improvement
and for doing business in the international marketplace.  The ISO
9001 standard has become a basic part of these rules.

How does ISO 9001 apply to software?

ISO 9001 is an international “quality management system” standard–a standard
used to assess an organization’s management approach regarding quality.

ISO 9001’s focus is directed internally at an organization’s processes
and methods and externally at managing (controlling, assuring,…) the
quality of products and services delivered.

When viewing the key factors affecting the outcome of software development
(shown below in figure 1), ISO 9001’s focus is on all factors except “technology”.



Figure 1: Delivering Quality
Software – macro process (click figure for expanded view)

Scope of ISO 9001:

ISO 9001 is a generic international standard, adopted on a country-by-country
basis, and written for use by the widest possible audience.  As a
result, the standard provides requirements (what needs to be done)
and does not issue specific prescriptive solutions (how to do it).

Being so broadly focused, the ISO 9001 standard does not offer details
about its application to specific domains of expertise.  To assist
in the application of the standard for specific domains, a series of guidelines
are available; e.g., ISO 9000-3 is a guideline for the software development
industry.

Relevance of ISO 9000-3

ISO 9000-3 provides “guidance” on implementing an ISO 9001 compliant set
of processes (collectively referred as a “quality system” or as a “quality
management system”).



ISO 9000-3 is an international guideline.  Guidance is for software
development, supply and maintenance environments.  The guideline is
primarily written for “custom” (contract driven) software markets.
It can easily be adapted for other market needs such as commercial-off-the-shelf
(COTS), internal software development, etc..

ISO 9000-3 virtually mirrors the provision of ISO 9001–it does not
add to, or otherwise change, the requirements of ISO 9001.

ISO 9000-3 is not intended to be used as an internal/external audit
tool.  Its intent is to guide software organizations with their
ISO 9001 implementation and process change efforts: in short, software
organizations are audited against ISO 9001 (not ISO 9000-3).

An example of the type of guidance provided by ISO 9000-3 is shown in
the following table.
Read more here

Software development control

Quality in software development projects doesn’t happen on its own. It also doesn’t occur after a small group of heroes rides in on white horses and waves its shiny swords to vanquish the problems. Quality happens only when careful planning is done, when the entire project team maintains a quality-conscious approach every step of the way, and when problems don’t escape from the phase in which they were introduced. A quality product is a team effort. It’s planned and predictable. It’s without heroes, and it’s faster and cheaper than a low-quality effort.

How can this be? Let’s look at some sample projects. The first is a normal, low-quality, late project. We’ll call it project “Hurry Up” (HU for short).

Project HU got a bit of a late start due to the ongoing maintenance issues of its predecessor project “Just Ship It” (JSI). JSI was handled by a project manager (PM) who felt it was more important to ship on time than to ship a high-quality product. So he did. This PM was rewarded for his ability to “pull it together,” “get it out the door” and “meet the schedule.” The JSI PM was given a bonus for meeting his schedule and is now vacationing in Tahiti while the team deals with the fallout of the numerous bugs and unhappy customers.

Lesson #1: Don’t reward for shipping on schedule. Anyone can ship garbage. Base rewards on quality metrics.

During the last month of the project, the JSI developers worked 80-hour weeks. One heroic fellow was recognized for working 120 hours in one week, stopping only for brief rests. He heroically repaired multiple interfaces between applications. Those interfaces had not been properly specified (there were no design documents), no integration testing was done (no time to do it), and the QA team fought quality issues throughout system test.

Read more here