1. ISO

2. The ISO 9000 standards as applied to the design and development of software. In such instances, these standards have to be appropriately interpreted because of the more complex nature of the software design, development, distribution and installation process. In 1987, the ISO guidelines were published by the ISO Technical Committee 17 (TC 176) to address these needs of the IT community.

3. Introduction of ISO
ISO 9001 is generic and many IT people find it difficult to interpret and apply
ISO is a set of guidelines that helps interpret and apply ISO for software development
Since it is NOT a standard, companies are still assessed against ISO 9001

4. Assumptions of ISO
Each development project is associated with a life cycle with phases
The software product produced is the result of a contractual agreement between a purchaser and a supplier
Bullet Point (1)
It assumes no particular life cycle, but it does assume the existence of some life cycle with phases.
Bullet Point (2)
ISO also presumes that the software product produced is the result of a contractual agreement between a purchaser and a supplier, where the supplier is the company or organization whose quality system is under review (i. e. ISO 9001 conforming). It emphasizes cooperation and joint efforts between the purchaser and the supplier, and there are clauses in ISO that specifically address the purchaser's responsibility in the contractual arrangement.

5. Overview of ISO
It consists of 22 clauses that do not correspond directly with the 20 clauses of ISO 9001
These 22 clauses are grouped into three major sections:
Section 4: Quality system – Framework
Section 5: Quality system – Life cycle activities
Section 6: Quality system – Supporting activities
Bullet Point (2)
Section 4 deals with activities which are neither phase nor project related but persist across projects.
Section 5 deals with activities that are related to particular phases of the development process and are project related.
Section 6 deals with activities that are not related to any particular phase but apply throughout the process.

6. Cross-reference ISO9000-3 to ISO9001
Clause in ISO
Clause in ISO 9001
4. 1 Management responsibility
4. 1
4. 2 Quality system
4. 2
4. 3 Internal quality system audits
4. 17
4. 4 Corrective action
4. 14
In the right column with the heading "Clause in ISO 9001", the clauses 4. 1 and 4. 2 correspond to the first (Management Responsibility) and second (Quality System) quality elements outlined in slide 21. Other clauses in this column are interpreted in a similar way.

7. Cross-reference ISO9000-3 to ISO9001 (cont’d)
Clause in ISO
Clause in ISO 9001
5. 2 Contract review
4. 3
5. 3 Purchaser’s requirements specification
4. 3, 4. 4
5. 4 Development planning
4. 4
5. 5 Quality planning
4. 2, 4. 4
5. 6 Design and implementation
4. 4, 4. 9, 4. 13
5. 7 Testing and validation
4. 4, 4. 10, 4. 11, 4. 13
5. 8 Acceptance
4. 10, 4. 15
5. 9 Replication, delivery, and installation
4. 10, 4. 13, 4. 15
5. 10 Maintenance
4. 13, 4. 19

8. Cross-reference ISO9000-3 to ISO9001 (cont’d)
Clause in ISO
Clause in ISO 9001
6. 1 Configuration management
4. 4, 4. 5, 4. 8, 4. 12, 4. 13
6. 2 Document control
4. 5
6. 3 Quality records
4. 16
6. 4 Measurement
4. 20
6. 5 Rules, practices, and conventions
4. 9, 4. 11
6. 6 Tools and techniques
6. 7 Purchasing
4. 6
6. 8 Included software product
4. 7
6. 9 Training
4. 18

9. Why Comply with ISO 9001?
Provide a foundation for a quality system which is needed for quality software
Increase productivity and reduce costs because development is done right the first time under control
Ensure consistency of software quality
Stay competitive by keeping up with market standards
Fulfil software contractual requirements
Improve corporate image

10. Potential Problems of ISO 9001
Creating rules and formality to fulfill ISO 9001:
Too many rules result in bureaucracy
Too few rules result in insufficient control over quality
Formality, paperwork
Quality productivity
Creating rules and formality in order to fulfill ISO 9001 is rather like balancing on an edge. On one side is the dangerous swamp "Bureaucracy", which can clog your activities forever, and on the other side is the slippery hillside where you don't know what will happen.
The figure in this slide is an attempt to illustrate this phenomenon. The Y axis represents quality and productivity. The X axis represents formality and paperwork. Too little formality and paperwork leads to low quality and productivity, since the developers make errors and repeat work done in other projects (e. g. on development methods). Too much of it also leads to low quality and productivity, since the most effort goes into following rules and doing paperwork. It is essential for a software development organization to find the RIGHT level of formality and paperwork (i. e. the balance point), which will give high quality and productivity.

11. Thanks