A Project Report

On

Study of ISO 9001:2000 Quality Management

System

By
Ketan J. Chaudhari (M.B.A.
(M.B.A. II – Systems
Systems & Marketing)

1
Executive Summary
Gone are the days when the customers had to rely only upon few software solution
providers to make their business digital. They have to accept theses solutions without
considering the quality factor. Today, the ever-growing software industry, increasing global
competition and expanding market has reversed the situation. Now the customers are the kings
and they have a lot of options to choose from. Considering this fact, today any software
company not considering the ‘Quality’ factor in it’s product realization process would definitely
find it difficult to survive.
Not surprisingly, the ‘Software Quality’ buzzword is being ruling over the industry since
last two decades. Everyone in the industry is trying to make their profile heavy with various
quality certificates. Look for a software company, and you will find a small tag, ‘An XYZ
certified Company’. And the stunt is not only to attract the costumers, but ensuring quality
products and services in the long run.
Any quality consideration should start from understanding the fundamentals. This report
presents a thorough study of Software Quality concepts in the ISO 9001:2000 context. ISO
9001:2000 is the most acquired standard today. In fact, the quality movement in any company
starts with this certification.
The report starts with the company profile of National Informatics Center, which is
implementing ISO 9001:2000 compliance practices, followed by the basics of quality in
software context. Then it explains the ISO standards and the ISO 9000 family. The quality
management principles, on which each of quality certification process is based on, are cited in
the report. The report focuses on ISO 9001:2000 standards, its structure and specially the fourth
clause, Quality Management System. The actual summer project work in NIC, Pune is a
practical case in this context, including various ISO 9001:2000 QMS compliance assignments
on their current project, RojgarMitra. Report gives the details of the project and related work
done during the period. Due to the organization’s security issues, actual documents couldn’t be
revealed in the report. But all the structures of the documentation are explained. The report ends
with findings and conclusion.
The Annexure gives important relevant information like the popular quality models other
than ISO, the actual structure and contents of ISO 9001:2000 standard (fourth clause in detail)
and finally ISO 9001:2000 certified software firms in India.

2
3
Quality Concepts
In his book, Quality is Free, Philip Crosby explains this common misconception by
stating, “The first erroneous assumption is that quality means goodness or luxury or shininess or
weight.”
When we ask for something and say it should be of ‘good quality’, we expect that the
other person interprets the word ‘quality’ the same way as us. If we do not understand what
would be considered as good quality, we cannot aim for it or insure that we produce it. Any
organization that wants to deliver quality products and services therefore needs to understand
what would be considered as quality by its customers.
So what is quality? Quality essentially lies ‘in the eyes of he beholder’. What may be
high quality for one customer may not be high quality for another. A customer will consider a
product or service as ‘high quality ‘ if it meets (or exceeds) what she wants from the product or
service.
Standard definitions quality recognize the customer’s perspective very clearly. IEEE
defines quality in its IEEE Std 610.12-1990 as:
• The degree to which a system, component or process meets specified requirements,
• The degree to which a system, component or process meets customer or user needs or
expectations.

Another formal definition of quality is found in ISO 9000:2000. this standard defines
quality as the ‘degree to which a set of inherent characteristics fulfils requirements.’
It should be noted that regardless of how sophisticated the features of a product, if the
product does not meet the requirements of customers, they would not consider it good quality.
Customers who consider our product and services as being of ‘good quality’ will be
satisfied customers – they would buy from us, maybe make repeated purchases and also speak
well of us and thus encourage other customers to buy from us. They may even be willing to pay
more for our products and services. Good quality thus leads to increase in business.
Software professionals who want to create product and services that are of good quality,
therefore have to understand customer requirements and try to conform to them.

4
Quality of Design
Design is done to meet the customer’s needs and expectations and the implementation of
the design should be achievable within required framework of cost and schedule. Design has to
capture the requirements, and is therefore always within the context of customer requirements.
Quality of Design (QoD) is concerned with how good the design is. It is the value
inherent in the design. QoD is an area that is addressed early in the life cycle of a product. Work
subsequent to design aims at realizing the design. It refers to the level of excellence the product
is intended to posses.
Juran, the quality guru, saw quality of design as a component of overall quality, which he
defined as “ fitness for use’. QoD includes market research to understand what features are
indeed. It includes the product concept and the design specifications.

Quality of Conformance
Quality of Conformance (QoC) is a term used to express how well the product built
conforms to the design specifications. A good design is pointless if the product does not
conform to the design specifications. QoC has to be insured all though the process that builds the
product. Essentially, QoC is about meeting the promise made in the design specifications.
In his book, Software Engineering, a Practitioner’s Guide, Pressman says that “quality
of design refers to the characteristics that designers specify for an item” while “quality of
conformance is the degree to which the design specifications are followed during
manufacturing”.
For example, a software product’s design quality is seen in terms like simplicity and
structure of the architecture, its consistency and understandability. The same requirements can
probably catered to by multiple designs. However, design quality impacts aspects like
maintainability, testability, flexibility, portability, reusability and interoperability. So, to build a
good product, we need a good design and then we need a process that builds the product that
conforms to the design.
Besides insuring that the design is of good quality, we need to ensure that the product
conforms to the specifications. A good design can result in a good product only if it is followed
by “quality of conformance” while building the product. Just focusing on quality of design is not
sufficient to produce products of good quality.

5
Quality Control
Producers capture customer requirements in the form of specifications. Products meeting
these specifications provide customers what they need. How can we know whether the product
meets specifications? We can check this – that is check the product against specifications and
see whether there are any defects. If defects are detected they will have to be rectified before the
product is shipped to customers.
Such checks on products are called ‘quality control’. It involves:
• Checking the product against the specifications to detect defects and
• Rectifying detected defects (and maybe checking again) before shipping the product.

IEEE Std 610.12-1990 provides alternate definitions for quality control as:
• Set of activities designed to evaluate the quality of developed or manufactured products
and
• The process of verifying one’s own work or that of a co-worker

Essentially, the focus of quality control is checking that the product that reaches the
customer has no defects, by detecting and rectifying defects in the product. The word invokes an
image of an inspector at a gate checking whether the product can be passed on to the customer or
not.

Quality Assurance
It’s a more compressive approach to quality. Here the thrust includes preventing defects.
Right from the initial stage, the focus is on building the product right.
While quality control checks the product towards the end before shipment, quality
assurance encompasses the entire process used to create the product. The idea is to use a process
that prevents defects, not just to detect and correct defects.
A formal definition of quality assurance from IEEE Std 610.12-1990 is:
• A planned and systematic pattern of all actions necessary to provide adequate confidence
that an item or product conforms to established technical requirements and
• A set of activities designed to evaluate the process by which products are developed and
manufactured.

6
 Quality assurance includes planning to incorporate quality, and using a process geared to
produce quality.
Defects are present in the products because:
• They are introduced while creating the products and
• Some defects pass undetected through the production process and reach the customer.

While quality control addresses the second point, quality assurance addresses both. In
that sense, quality assurance includes quality control mechanisms as one of the means of
assuring quality. More importantly, it tries to prevent defects from entering the product in the
first place.

Cost of Quality
Often both operational staff and management think of quality as an ‘overhead’. They see
any type of quality control or quality assurance activity as something that increases costs, and
are therefore reluctant to include these in their production process.
In a very powerful statement that refutes this, Philip Crosby points out that ‘quality is
free’ in a book of the same name. he says that there is a cost of poor quality – “ the cost of
quality is the expense of doing things wrong”. Crosby explains how creating products of high
quality is less expensive than creating products of poor quality.

When quality is poor possible failure costs are:

• Internal failure – costs of failures that are detected before the product is shipped
• External failures – costs of failures that occur or may occur after the product is shipped

Failure implies that work will need to be done to repair the product. The later the defect is
detected, the higher the cost to fix it. What may be a small detect to rectify if detected on the
drawing board may require major scrapping and rework if detected after construction.

External failures occur after the product reaches customers. Costs related to external
failures include handling customer complaints. Irate customers need prompt service. Help lines
are needed. Product warranties may be involved. Product need to be returned, corrected and
shipped again. They may even need to be withdrawn from customers who have not yet had a
complaint if a defect found implies that there is a risk to other customers.

7
 External failures are also very costly because they are visible to the existing and potential
customers and result in poor publicity, loss of goodwill and reputation. Customers may have
suffered losses because of the failure and may even demand or sue for compensation.
To improve quality, the costs that are incurred are:
• Prevention costs (related to quality assurance activities) and
• Appraisal costs (related to quality control activities).

We can prevent defects by putting in place processes that reduce the probability of
defects getting into the product. Quality planning, proper training of persons, setting up
appropriate processes, standards, templates, using suitable tools, having design reviews – all
these help to prevent defects. These are also called costs related to quality assurance activities.
Essentially, if we invest in trying to reduce the defects introduced (through quality
assurance activities) and in catching them early when they are cheaper to fix (through various
quality control activities), we can save on failure costs later.

Quality Movement
After World War II, industry in Japan faced major problems since their products were of
poor quality. Japan recognized the need to improve quality and to introduce statistical quality
control concepts. William Edwards Deming was a statistician who had been teaching statistical
quality control in America. Deming was a statistician who has been teaching statistical quality
control in America. Deming was invited to Japan to teach statistical quality control and his
teachings were appreciated and adopted by the Japanese industry. Deming is one of the gurus
credited with the turnaround of industry in Japan. Japan, which started with a reputation for
shoddy quality, was transformed into a country synonymous with good quality to the extent that
American industry fell behind it and started losing market share.

Quality Gurus

• William Edwards Deming

Deming summarized his philosophy in what he called the ‘System of Profound Knowledge’.
This consists of four parts:

o Appreciation of a system

8
 o Knowledge about variation
o Theory of knowledge and
o psychology

1. Organization use systems to perform their work. These systems have multiple components
that interface with each other to work as a whole. For systems to be effective, they (including the
interactions between the components) have to be understood well. All involved parties –
managers, workers, customers and other stakeholders – have to understand the system.
According to Deming, it is the management’s job to optimize the systems and apply solutions
that look at the system as a whole rather than look at it in parts.

2. Knowledge about variation is the second part of the system of profound knowledge and is
concerned with an understanding of statistical theory as it applies to variation. Any operation
involves a multiple of factors and complex interactions between them. Variations occur due to
individual components. The combined variation can be statistically predicted. There are two
causes of variations:

o Common causes of variation that are due to natural factors present in the process
o Special causes of variation that occur due to assignable causes.

Assignable causes result in unnatural variations that are quite different from the random
variations caused by common causes of variations. Such assignable causes are easier to detect
and economical to remove. On the other hand, natural variations are inherent in any stable
system and can only be reduced by changing the technology of the process.
Understanding that variation is inherent, and that there is a need to seek variation due to
special cauases and remove them, is necessary for proper improvement. Control charts are used
for identification of special cause variations.

3. The third part of the philosophy is the theory of knowledge, which is an understanding of
cause-and-effect relationships that can be used for prediction. Managers need to learn and apply
this theory. Theory of knowledge explains things and encourages questions and testing of the
theory.

9
4. Psychology, that is, understanding behavior of people is the fourth part of the system of
profound knowledge. People are different and leaders need to understand these differences to be
able to optimally use the abilities of the various people involved. People cannot be treated as
interchangeable parts. Concepts of dignity and understanding the need for self-esteem and
respect are essential for proper leadership of people.

• Joseph Juran
For achieving quality, Juran focused on three aspects, which he termed as the ‘Quality
Trilogy’. Quality Trilogy is a registered trademark of his institute, the Juran Institute. The three
aspects are:
o Quality planning – this sets up the quality goals,
o Quality control – the process used to meet quality goals during operations and
o Quality improvement – the quality improvement process includes various quality
improvement projects, each starting from an improvement need and then changing
things to improve and to control the improvement.

Juran found that most companies pay too much importance to quality control and are
weaker in quality planning and quality improvement. He felt that quality planning and quality
improvement should be considered important. Quality needs to be pursued at all levels. The
organization’s mission should be overall product quality. Individual departments should also try
to achieve high quality. Quality programs need to be supported by accounting of quality costs so
that there is focus on quality problems. All functions should work together to achieve quality
and there is need for company-wide quality management.

• Philip Crosby
Crosby saw ‘zero defect’ as a performance standard that focused on preventing defects
Rather than finding and fixing them. He listed the basic elements of improvements as top
management determination about achieving quality, education of everyone to understand the
absolutes of quality, and implementation of quality by everyone.
The major quality movements like Total Quality Management (TQM) and Six Sigma are
based on similar underlying principles.
While developing software systems, the life cycle phases are supported by a set of life
cycle support activities that span the entire life cycle. Following diagram shows the place of
software quality assurance in the SDLC.

10
 REQT. DESIGN CONSTRUCTION TESTING DEVELOPMENT OPERATION &
ANALYSIS MAINTENANCE

PROJECT PLANNING & MONITORING

SOFTWARE CONFIGURATION MANAGEMENT

REVIEWS, VERIFICATION & VALIDATION

SOFTWARE QUALITY ASSURANCE

SOFTWARE MEASUREMENT & MTRICES

Fig. 1: Life Cycle Phases and Support Activities

Assuring Quality in Software Organization

Following guidelines can be suggested for assuring quality in any software organization:

• A Process Approach is Necessary

Watts Humphrey (considered as the father of the Capability Maturity Model) suggested a
process-centric approach for software in his seminal book titled Managing the Software Process.
In this book, he mentions the myth of super-programmers as one of the reason why the
importance of an effectively managed software process was not recognized. In the earlier days,
there was a belief that a bunch of talented programmers working together to build software
ensured success. Many software professional believed that a very few, first class programmers

working on a project is better than having a ‘typical’ software team. These ‘super-programmers’
shall intuitively turn out better software. In real life, very few persons seem to have the caliber
apparently required of such super-programmers. But wishful management often ignored the need
to improve their software processes and hoped that recruiting top-of-the-class software engineers
from hotshot campuses would do the trick.
It became obvious that the only way to tackle the problems being faced by the industry
was to make the ‘process’ of software development more robust. This would reduce the

11
dependence on super programmers and guarantee success of the project and the software
product, independent of the individuals developing the software. Humphrey insists that “the
quality of a software system is governed by the quality of the process used to develop and
evolve it”.

• Software Project Management Should Provide Direction and Visibility

To build quality into a software product, we need to use a suitable process. We also need
To plan and monitor quality all through the process. This is especially important in software
since software products are essentially ‘invisible’ and therefore need checking. Planning and
monitoring is done as part of software project management.
In their book, Software Project Management, Hughes and Cotterell state, “One way of
perceiving software project management is as the process of making visible that which is
invisible.” They further explains the characteristics of a software project as:
o Invisibility – progress is not immediately visible in a software project,
o Complexity – software products contain more complexity than other engineered
artifacts and
o Flexibility – because of the perceived ease of changing software, it is expected that
software will changed to accommodate other components. So, software systems are
likely to be subjected to high degree of change.
All these need to be handled by defining the processes the project will follow and
management of the software project.
Since project management is the function that manages both time and resources to
achieve results, it is the function that can ‘make or break’ quality. An approach for quality has to
therefore ensure that project management incorporates whatever is needed for building quality
and checking for quality. Quality assurance has to be an integral part of software project and this
is ensured through project management activities.

• Process Capability and Maturity must be Understood

There needs to be some ways of assessing how good a process is. In this context,
Carnegie Mellon University’s (CMU) Software Capability Maturity Model explains two
relevant concepts – process capability and maturity levels. Further information on SW-CMM is
included in given in Annexure.

12
• Process Improvement should be Continual
Processes are used to produce software. To improve quality we need to improve the
processes that create the products. Process improvement is one of the three focus areas of
Juran’s Quality Trilogy and also recommended as a continuous thrust area by Deming.
Process improvement steps are best explained by the simple but popular model from
Shewhart, known as Shewhart Cycle, shown in the figure. This cycle is also called Deming
Cycle by its Japanese users, named after Deming who took it to Japan.

Act Plan

Check Do

Fig. 2: Shewhart’s Cycle

The Shewhart Cycle consists of four cyclic steps:

o Plan
o Do
o Check (or Study) and
o Act
It is also called the PDCA Cycle. Essentially it is a feedback loop. First, an improvement
is identified and a plan is made to achieve it. Work is then done according to this plan. The
effect of work done is checked (studied) using various measurements/observations. These tell us
whether the improvement has been achieved. Action is taken based on the checking done and
whatever has been learnt.
Process improvement is continuous. Typically, a number of small but successful
improvements are preferred to one large cycle. Small successful improvement projects
encourage the persons and convince them about making improvements. There is a less chance
for failure and the resulting loss of motivation.

13
Quality and Process Models
Quality models help organization put their software development and management
processes in place. They provide a framework for organizations for their quality journey. Quality
models are process based – they assume that quality can be assured by establishing and
implementing good processes. Models specify what the policies and processes of an
organization should achieve. Certification and assessment schemes compare the processes of an
organization against the requirements of these models. These models are being increasingly
adopted by organizations that now believe in a ‘process-centric’ approach to execute successful
projects and build usable software products. The assumption is that by having better processes
and ensuring they are used, quality of a process output can be assured. These models aim to
improve process capability so that organizations move to higher maturity levels.
Quality models provide guidance to organizations for process improvement by giving:
o Process areas to address,
o Objectives for various process areas and
o Indication of the possible sequence/priority
Assessments/certification to defined quality models are means of obtaining the current
status of an organization with respect to quality model. Trained and authorized persons carry out
assessment using defined methodologies. Assessment results are input for deciding how an
organization can further improve processes. They also help cuctomers and other external persons
in making decision such as whether the organization should be used as a supplier or whether it is
worth investing in.

There are many standards available for a software organization to adopt. Some of them
are given below. This report presents ISO standard in depth. Other standards are also explained
in the Annexure.

o ISO 9001:2000
o Software Capability Maturity Model from CMU
o People Capability Maturity Model from CMU
o Capability Maturity Model Integrated (CMMI) from CMU
o ISO/IEC TR 15504 (and the SPICE project)
o BOOTSTRAP and
o TRILLIUM

14
15
ISO 9000 Family of Standards

The ISO 9000:2000 family of standards are owned and published by International
Organization for Standardization (ISO), based in GENEVA. ISO is a worldwide federation of
the national standards bodies of about 140 countries. The short name of ISO is not an acronym
of International Organization of Standards – it is derived from the Greek word ‘isos’ which
means ‘equal’. This short name of the organization is the same in all countries, and avoids
having different acronyms in different countries.
The organization (ISO) was created when delegates of over 25 countries met after the
World War and decided that there was need for a new international organization to facilitate
international coordination and unification of industrial standards. ISO, a non-governmental
organization, created as a result and began functioning in 1947. ISO published its first standard
in 1951. since then, ISO has been developing voluntary technical standards for almost all sectors
of business, industry and technology. Most of the standards developed by ISO are discipline-
specific and technical.

Standards from ISO:

ISO standards represent international agreement. They take into account the views of all
interests such as government, professional bodies, researchers, manufacturers, academics,
vendors, users and consumer groups, based on their voluntary participation. The resulting
standards are international standards that are market-driven.
A defined process is used for developing the standards. This process ensures adequate
representation and participation. The high level steps of the process are given below to show
how ISO insures that the standards it publishes are global solutions and useful to industries
across countries.
• An industry sector that feels the need for a standard communicates it to a national
standards body, and this national body proposes it to ISO. If this need is recognized and
formally agreed to, the technical scope of the future standard is defined by working
groups comprising technical experts from interested countries.
• When agreement is reached on the technical scope defined, the second of work starts.
ISO calls this the ‘consensus-building phase’.

16
 • The final phase involves formal approval of the standard as per defined acceptance
criteria. After receiving formal acceptance, ISO publishes the agreed text as an ISO
International Standard.

ISO also has a general rule that all standards it publishes need to be reviewed ( and
revised if necessary) at intervals of not more than five years (revisions may be necessary earlier).
Periodic revisions ensure that standards are not rendered out-of-date because of factors like
technological advances, new requirements of safety and quality and new methods and materials
that may now be available. Feedback on a standard gets incorporated to create an improved and
up-to-date standard.
ISO published over 12000 international standards, mainly in the technical field. These
standards represent international agreements and facilitate international exchange of goods and
services. They are principally of concern to engineers and technical specialists.
In 1987, ISO published its first version of the ISO 9000 family of standards. This
differed from other ISO standards since it was a generic standard for quality and was of interest
to the business community. Today, this family of standards is the best known and most used of
al the standards published by ISO. It has been implemented in several thousand businesses as it
provides a framework for quality management and quality assurance.

What are the ISO standards?

The concern of ISO 9000 is “management of quality”. The concern is about how an
organization should do its work, and not on the specifications of the product. The standards are
process-centric – not a product standard. They are concerned with how the organization defines
and manages its processes. The basis of the standard is the recognition that processes affect
quality and managing processes can assure quality.
ISO 9000 is a generic standard. The standard can be applied to any organization
regardless of its size or the industry it belongs to. It applies to small and large organizations. The
organization could be producing any product or service and could be part of the public or
government or private sector.
The purpose of the standards is not to prescribe what the organization should do or how
it should be done, it is to specify the requirements from the organisation’s quality management
system. Organizations are free to define their processes in the way best suited to their business
and operational environments. To conform to the ISO 9000 standards, the organization’s quality
management system has to have the essential features specified in the standard.

17
The ISO 9000 Family of Standards
The ISO 9000 family of standards as published in 2000 consists of four standards in
9000 series. These are:

ISO 9000:2000 Quality Management systems – Fundamentals and Vocabulary

ISO 9001:2000 Quality Management Systems – Requirements

Quality Management Systems – Guidelines for performance

ISO 9004:2000
improvement
Guidelines on Quality and/or Environmental Management Systems
ISO 19011
Auditing

Table1 : ISO 9000 Family of Standards Published in 2000

1. ISO 9000:2000 defines the fundamental terms and definitions and enables users to
understand ISO 9001:2000 and ISO 9004:2000. The definitions are arranged by category and
their inter-relationships have been explained. ISO 9000:2000 is a starting point and ensures
that there is no misunderstanding in the use of ISO 9001:2000 and ISO 9004:2000.
2. ISO 9001:2000 is the standard to which organizations can be assessed and certified. This
standard can be used by organizations to assess their ability to meet customer requirements
and to therefore achieve customer satisfaction. It is the standard that is used by third party
assessors for certification. In the year 2000 release, this is the only standard to which
certification is possible.
3. ISO 9004:2000 is a guideline for organizations that want to derive greater benefits from
quality. ISO 9004:2000 provides guidance for continual improvement of the quality
management system, aimed at sustained customer satisfaction and providing benefit to all
parties.
4. ISO 19011, currently under development and available as a draft standard, provides guidance
on the principles of auditing, the management of audit programs, the conduct of audits and
the competence of auditors. It addresses both quality management system audits and
environmental management audits.

18
 The other documents of the ISO 9000 series are tabulated below:

ISO 10005:1995 Quality Management – Guidelines for quality plans

ISO 10006:1997 Quality Management – Guidelines for quality in project management

ISO 10007:1995 Quality Management – Guidelines for configuration management

Quality assurance requirements for measuring equipment – Part

ISO/DIS 10012
1:Metrological confirmation system for measuring equipment
Quality assurance for measuring equipment – Part 2: Guidelines for
ISO 10012-2:1997
control of measurement of processes

ISO 10013:1995 Guidelines for developing quality manuals

ISO/TR 10014:1998 Guidelines for managing the economics of quality

ISO 10015:1999 Quality management – guidelines for training

Quality systems – Automotive suppliers – Particular requirements for
ISO/TS 16949:1999
the application of ISO 9001:1994
Table 2: Documents of ISO 9000 Series

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).

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

ISO 9001:1994 says: 4.2.3 Quality planning

The supplier shall define and document how the

requirements for quality will be met. Quality planning
shall be consistent with all other requirements of a
supplier's quality system and shall be documented in a
format to suit the supplier's method of operation. The
supplier shall give consideration to...

Related Quality planning should address the following items, as

ISO 9000-3:1997 appropriate:
guidance includes: a) quality requirements, expressed in measurable terms,
where appropriate;

b) the life cycle model to be used for software

development;

c) defined criteria for starting and ending each project

phase;

d) identification of types of reviews, tests and other

verification and validation activities to be carried out;

e) identification of configuration management

procedures to be carried out;
.
.
.

Table 3: ISO 9000 - 3

20
21
Quality Management Principles

There are eight quality management principles that form the foundation of ISO
9001:2000 and ISO 9004:2000. These principles can be used by the top management of any
organization that wants to improve performance. While these principles are not part of the
‘requirements’ of the standard (they do not have to be explicitly conformed to), they are the
basis for the ISO 9001 standard.
The eight quality management principles are:
• Customer focus
• Leadership
• Involvement of people
• Process approach
• System approach to management
• Continual improvement
• Factual approach to decision making
• Mutually beneficial supplier relationships

1. Customer Focus
Essentially, the organization tries to meet its business goals related to revenue,
profit, market share and brand image. For this, the organization typically provides
products and services to its customers. For successfully doing so, the customer has to be
the organization’s focus. Customer focus has been recognized as core to quality
movements such as TQM and Six Sigma.
In software projects, programmers are often concerned with using the latest
features in tools and learning a new technology, without considering whether the latest
feature or technology will help the customers in the long term. Designers are often
concerned about creating an elegant design, rather than looking at usability of the
product. All the work within in any organization should focus on customer.
The organization’s objectives should be linked to customer needs and
expectations. Also, the awareness of customer needs and expectations should be spread
throughout the organization, even to those functions and individuals that do not directly
deal with the customers. Some of the ways to focus on customers are:
• Measurement of customer satisfaction.

22
 • Customer Relationship Management
• Ensuring that the whole staff has the knowledge and skills needed to satisfy
customers. E.g. there may be need for special communication and human
relations skills for persons directly interacting with customers (like customer
relationship officers, Marketing managers). Programmers and designers may
need to undergo training in usability.

2. Leadership
Leadership is what drives the organization. It requires organizational leadership
to establish an environment where all the people within the organization feel involved
and work together to achieve the organization’s objectives.
Philip Crosby gives The Absolutes of Leadership in his book as
i) a clear agenda
ii) a personal philosophy
iii) enduring relationships
iv) worldliness
People are the most important resources in software organizations. Leadership
should establish trust and eliminate fear so that they can work to their full potential and
can share ideas that could help the organization to improve. An open environment
encourages fearless participation and creative thinking and makes people feel more
involved. Problems and conflicts can be resolved faster and grievance can be sorted out.

3. Involvement of People
Narayan Murthy, the head of Infosys, Banglore, is one of the leaders of the
software industry in India. He expresses his understanding of the worth of people in a
crisp statement: “My assets walk out of the door every evening.” With top management
approach of this type, it is not surprising that Infosys has become an industry leader.
People who feel involved in work bring more commitment and energy to work.
They come up with suggestions for improvements in processes and products, and provide
leadership with information that can help formulate better strategies.
Quality approaches typically have various mechanisms for increasing people
involvement in process improvement. Quality Circles, Suggestion System, Cross-
functional teams and small group activities are examples of such mechanisms.

23
4. Process Approach
Watts Humphrey, considered the pioneer of the software process movement, has
Said, “ The quality of a software system is highly influenced by the quality of the process
used to develop and maintain it.” Process approach is the most important aspect of any
modern business. As shown in figure, a process is the glue that ties people, procedures,
tools and equipment together.

High quality software

on time, within budget
Measurements &
feedback for process
improvement

Process

Procedures

People

Tools and Technology

Figure 3 : The Process Perspective

All quality models focus on the process approach since this is necessary to assure
quality as the products are being built.

5. System Approach to Management

Process approach is necessary, but the processes should not be isolated processes
– they should work together as a system. Their interfaces and interdependencies should
be understood and the structure of the processes should follow a ‘system’ approach. To
design the organizational processes, we should start top-down from the organization’s
objectives and design a set of integrated processes that are harmonized. There should be

24
 consistency in the roles and responsibilities. Organizational capabilities and resource
constraints should be taken into account.
Any system approach is based on the understanding that the whole can be more
than the sum of its parts. Conversely, if processes are designed independent of each
other, they could have overlaps and inconsistencies leading to gaps. We may have some
functions and covered by any process, while some may be covered in different ways in
more than one process. Quality models therefore describe the quality management
system as a system of processes.

6. Continual Improvement
Organizations never operate in static environments. There is competition for
customers, changes in suppliers, changes in the work environment, shifts in technology
and changes in the skills and aspirations of employees. Expectations of customers also
increase with improved products and services. Organizations need to keep coming with
better products and services and use resources more efficiently to be able to grow, and
sometimes to just survive. Organizational capabilities can be improved if the
organization follows the principle of continual improvement.
Often organizations have numerous smaller goals on the path to improvement.
The Japanese philosophy of Kaizen, which is oriented towards progressing in small
steps, is an important concept in process improvement. Here, small group activities and
suggestion systems are used for initiating improvements that result in small increments
in quality. Over time, a steady change towards better quality can be seen.
Another important concept in process improvement is process maturity. SW-
CMM can be used to check process maturity at a very broad level for a software
organization. Moving from a maturity level to higher is a measure of process
improvement.

7. Factual Approach to Decision Making

Any decisions such as policy and strategy or setting goals and targets needs a
basis – an understanding of what current status is, and what can be expected in the
future. By measurements and analysis of data we have the factual basis needed to decide.
Take a simple case of deciding how much to quote for a software development
contract. To quote a feasible price we need a realistic estimate of what the development
will cost. This can be done using the data:

25
 - how much did similar projects cost in the past
- what is the amount of work to be done
- what is the productivity that cab be achieved
- number of employees those may involve
- their salaries etc.
As opposed to this, a quotation based solely on partial knowledge of the
marketing person could put the organization at risk of losses. Various methods are
available for collection and analysis of data:
i) In software projects, an important type of data is defect data. Analysis of this
provides insights on why problems occur and how they can be removed.
Decisions on the types of changes to be made in the process are based on this
analysis. Defect data on subsequent projects can be used to check whether the
changes are effective.
ii) Basili’s Goal-Question-Metric approach is useful for measurement program
because it identifies measures relevant to the goal. It looks at each goal, and then
further identifies which questions need to be answered to check for achieving the
goal. It then identifies the metrics needed to answer the questions. This top-down
approach helps organizations to arrive at a set of relevant measurements.
iii) Statistical process control using control charts is one technique used to check
whether a process is operating within the desired range. It is very powerful
technique and is recognized as the main factor in the progress Japan made in
quality.
iv) Data analysis can be done can be done by Root Cause Analysis such as
brainstorming and fish-bone analysis.

8. Mutually Beneficial Supplier relationship

Organizations and their suppliers share a interdependent relationship. This
principle recognizes that organizations and suppliers can work together in spirit of trust
and cooperation to create a ‘win-win’ situation.
If the suppliers are in sync with the organization, and a very good relationship has
been established, costs and resources are optimized for both the suppliers and the
organization and there is more flexibility in responding to market.
The use of subcontractor is often considered in software organizations to handle
situations where the existing manpower is insufficient or lacks the required skills.

26
Subcontracting is tricky in software because of the problems of judjing the quality of the
subcontracted work and the problems of communicating the work to be done. With an
open relationship with the subcontractor, the chances of producing quality software
improve. In addition to establishing sufficient processes and checkpoints for monitoring
work, a relationship that is based on openness and a perception of sharing the work can
reduce the defects substantially. The subcontractor can feel free to seek clarifications in
the requirements, joint reviews are possible and the subcontractor can also share
problems being faced. Resources from both sides can jointly try to ensure that the work
goes smoothly and that problems are resolved.

27
Structure of ISo 9001:2000

The ISO 9001 approach

The ISO 9001:2000 standard is based on eight quality management principles described
in the last section. It identifies the supply chain as
Supplier Organization Customer
1. Basically we assume that ‘organization’ refers to the organization that is attempting to
improve quality through application of standard and its underlying principles, while
using input from ‘suppliers’. The products and services we make are for the ‘customer’.
2. The ‘customer’ could be a consumer, client, end-user, retailer, beneficiary or purchaser.
3. ISO 9001:2000 uses the term ‘product’ to encompass both product and services.

28
 4. The term ‘organization’ includes the people, the facilities available to them and the
organizational structure within which they work – that is, the responsibilities, authorities
and relationships between them.
5. ‘Suppliers’ are entities that supply products to the organization. E.g. suppliers of a
software organization include hardware and software vendors, service providers for
communication services, and subcontractors being used for outsourced development
work like testing or even design and coding.
6. All three – supplier, organization, and customer are parties interested in the performance
of the organization. They are ‘stakeholders’ and affected by the performance. In addition,
there are other entities that have an interest in the performance- such as owners and
shareholders, employees, financial institutions that have loaned funds, the society within
which the organization functions and environmental bodies. ISO 9001:2000 refers to
these other stakeholders as ‘interested parties’.
7. ISO 9001:2000 recognizes ‘value adding activities’ as the chain that starts from
receiving customer requirements to delivery of the products to the customer. This
conversion of the requirements to the products is rendered by ‘product realization’.

Structure of ISO 9001:2000

ISO 9001:2000 is the year 2000 version of the ISO 9001 standard and has five main
clauses against which conformance is checked. These specify the requirements for a quality
management system of an organization ( as shown in figure). The five clauses are:
• Quality Management System specifies that there needs to be a quality management
system. It specifies the requirements for establishing the quality management system and
the documentation requirements, including the way documents will be controlled,
• Management Responsibility covers aspects like management commitment, customer
focus, quality policy, planning, responsibility, authority and communication and
management review. Essentially, through this clause, the standard ensures that
management is committed to and drives quality by establishing policy and objectives, by
focusing on quality and by planning for quality.

Customer Measurement Customer

Analysis and
Improvement

29

Product Realization
 Fig. 4: Structure of the ISO 9001:2000 Standard

• Resource management specifies that the organization has to determine and provide the
resources needed for implementing the quality management system effectively and
achieving customer satisfaction.
• Product realization the process that converts input requirements into products and
services and achieve customer satisfaction. In a software organization, this would include
processes for software development and project management, tools, methodologies etc.
• Measurement, analysis and improvement cover measurement, analysis and improvement.
Measurement and analysis are required to check product conformity and conformity to
the quality management system. They also enable continuous improvement of the
effectiveness of the quality management system.
Following diagram represents the process linkage that covers the clauses.

30
 Fig. 5

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 ), ISO 9001's focus is on all factors except "technology".

31
Figure 6 : Delivering Quality Software - macro process

32
33
Quality Management System

Introduction
The ISO 9000 standards of the year 2000 can be used by organizations to design and
implement a quality management system that helps to achieve quality. ISO 9001:2000 also
specifies the requirements that a quality management system should meet to be able to achieve
quality effectively and to continually improve quality.
QMS requirements in ISO 9001:2000 are given in Annexure.

Approach to the QMS

1. Establishing the quality policy

The needs and expectations of customers and other stakeholders are determined. This
data helps the top management establish the quality policy of the organization, enabling it to
be clear about its intentions and direction with respect to quality. The aspect of establishing a
quality policy is dealt with in more detail in the next chapter.

2. Setting the quality objective

The quality objectives are set for various functions and levels. The documented Quality
policy and quality objectives form part of the QMS.

3. Determining the system of processes required to fulfill the quality objectives

The processes and responsibilities required to achieve these objectives have to be
identified and defined. The relationships between the processes are identified. Resources are
required for achieving the quality objectives are identified and provided. Measures that can
be used to measure effectiveness of processes are determined.
The QMS includes the identified processes and their interrelationships. It also includes
the definition of the processes in sufficient detail to implement them. The process definitions
supported by procedures, work instructions, forms, templates, guidelines, records, etc. we
discuss this aspect later in more detail.

4. Implementing the QMS and continually improving it

Checking it for effectiveness and improving the processes is the last step. We therefore
need a process for establishing, maintaining and improving the QMS itself. This process is,
along with other processes, a part of the QMS.

34
Why document the QMS?

The ISO 9001:2000 standard requires a documented QMS. According to the standard,
the QMS should be established, documented, implemented and maintained, and its effectiveness
must be continually improved. The QMS documentation requirements have been specified in the
standard as a separate sub-clause.
The standard’s requirement that the QMS should be documented is often viewed
negatively, the general impression being that the standard’s approach is bureaucratic and
documentation centric. However, this is not so and the revised standard has in fact simplified its
documentation requirements further, providing organizations a non-prescriptive way of defining
a QMS suited to their particular situation.
Let us examine why there is need for documenting the QMS.
If an organization consists of a single person, she can have knowledge of all the
procedures required. As the number of persons in the organization increase, there is need to
communicate with each other on what is to be done and how, so as to establish a common way
of performing all required work and reducing confusion and duplication of work.
Communication is also required to share the organization’s vision, policy and objectives. If there
is gap in communication, the work and hence the organization suffers. This could be because of
something not being communicated, or because there was some misunderstanding. Also, if a
person leaves, the knowledge held by that person in lost.
Documentation is a way of converting tacit knowledge to explicit knowledge so that
people can share the knowledge and work together effectively. If a procedure is not documented,
only persons who know it can perform it. A new person will need to be trained fully for it. If
there is only one person knowing the procedure and she is not available, the procedure cannot be
performed.
For an organization keen to build quality product, it makes sense to ensure that everyone
understands all processes (that are required to deliver quality products) unambiguously and
uniformly. This makes the processes repeatable. This can be achieved by having QMS
documentation.
QMS documentation should aim at providing a system that assures quality. The
components of such a documented QMS required by ISO 9001:2000 are:
• The quality policy and objectives,
• A quality Manual that specifies the QMS,
• All documented procedures that are required explicitly by ISO 9001:2000,

35
 • All documents required for effective planning, operation and control of processes and
• All records required by ISO 9001:2000.
We can see that the existence and implementation of a documented QMS as above is
helpful in many ways:
• It forms a clear and unambiguous way of communicating the policies, objectives and
processes to the entire organization,
• By ensuring that all persons follow documented procedures, we can have a uniform
implementation of the procedures. Consistency can be ensured. By using a documented
QMS, we ensure that the process are repeatable,
• Process documentation enables understanding what is being done and how and this can
be reviewed and kept up-to-date,
• Process documentation can be used to audit whether work is indeed being done the way
it should be, and to detect gaps and rectify them,
• By knowing what is being done and measuring how effective it is, we can identify how
to make improvements in the process,
• It makes the organization less dependent on persons as everyone Cn share the defined
and documented processes and
• Records, a part of the documentation required in a QMS, form objective evidence of the
QMS implementation.

The standard, while discussing the value of documentation, says, “Documentation

enables communication of intent and consistency of action”.
We emphasize that a documented QMS is not a formality to meet the requirements of
ISO 9001:2000 (or any other standard) – it is a part of implementing and continually
improving a QMS. The documented QMS is not a tome to be locked away in some obscure
corner of the organization’s library. Instead, it is a representation of the behavior the
organization has established to achieve quality.
Also note that ‘document’ does not mean printed document. It could reside on some
other media or a combination of media such as magnetic, electronic or optical computer disc,
photographs, etc. Software organizations often prefer using electronic media and keep their
QMS as files accessible over their intranet for ease of the persons who may refer to it.

36
Contents and Structure of the QMS
The term ‘Quality Manual’ is used for the document that contains the description of the
QMS. The idea of the quality manual is to provide a perspective to the entire QMS. For anyone
trying to understand the QMS and starting point is the Quality manual. From this, the person
should be able to reach any other documentation that is required, such as some detailed process
document, some procedure or work instruction or some checklist.
The components of the QMS documentation are often explained as a ‘hierarchy’ or a
documentation pyramid. This is shown in Figure. The components of the QMS typically include
a Quality Manual, processes, procedures, forms, checklists, standards, guidelines, templates and
records.

Quality
Manual

Processes
&
Procedures

Forms, Checklists, Standards,

Templates, Guidelines

Records

Figure 7: QMS Structure

The typical contents of the Quality Manual of a software organization are:

• The scope of the QMS
• The quality policy and quality objectives,
• The process architecture that includes a high level process description and the
interaction between the processes of the QMS,
• Reference to the procedures that constitute the QMS and
• A table depicting how the various requirements of ISO 9001:2000 are met.

37
Item Description Example
Process Activities required for transforming input The process used for performing a peer
to output. The activities typically have review
interrelations and interactions.
Procedure The sequence of steps to be performed for The sequence of steps for each part of a
an activity/process review – pre-review meeting, during the
review, post-review follow-up
Form A blank document such as a blank table, The review findings form that needs to be
that is to be filled in one or more steps filled in during the review meeting.
while performing some process.
Checklist A list of items that is used while The checklist used during review meeting
performing an activity to ensure that all for reviewing a particular type of artifact
items have been considered. (e.g. code review checklist).
Standard A mandatory set of requirements that has Coding standard that the programmers are
to be conformed to while performing an expected to use while coding and
activity, or by a product being built. reviewers check for conformance while
reviewing code.
Guidelines A set of suggestions to be used to perform Suggested conduct during review
a process better. It is not mandatory. meetings ( e.g. do not make personal
remarks, focus on the product, do not
discuss solutions.
Templates A blank format, possibly with some A project planning format that is used for
embedded guidelines for understanding creating the project plan ( see the
the format to be used while preparing a Annexure )
document.
Record An artifact created as a result of some A review record created during a review
activities that provide evidence that the record created during a review, which
activity was performed, and may contain provides evidence that the review was
data that can be analyzed for more performed. An audit report is another
information later. A record could be a example of a record.
form that is filled up while performing
some activity

Table 4: Components of a QMS

While defining their QMS, organizations should choose a structure that is suitable. E.g.
• A small organization with simple operations may have a small QMS and may choose to
pull all of it in a single document,
• A geographically dispersed organization may have separate manuals for each location,
each such manual set containing location specific QMS information,
• A large organization may choose to have one top level Quality Manual which points to
detailed process definitions that are placed in separate manuals. There may be separate
process manuals for each department (e.g. purchase, administration, software
development). Alternatively, there could be separate manuals for each type of business
(banking customers, retail sales customers etc.)

38
QMS Processes of a Software Organization
The central activities in software organizations are ‘product realization’ activities – the
technical software engineering activities required to build the project and the management
activities that support these. These are:
1. Life cycle processes such as analysis, design, coding, testing and maintenance – the
phases and activities within the phases depend on a life cycle model selected and
2. Project support processes such as project planning, monitoring and control, software
configuration management, reviews and audits, risk management and software
subcontract management.

These various processes are all interrelated and all interdependencies have to be
recognized in any documentation. Here are some examples:
• The output of any requirements analysis process is the signed-off requirements
specifications and this forms the input for the design process,
• The SCM process is used in each life cycle process for controlling the configuration. The
requirements analysis phase uses the check-in activity of SCM to check in the signed-off
requirements specification and establish a configuration baseline and
• The software planning process includes an activity of selecting a suitable life cycle
model for a project and this determines other processes in the project and any tailoring
within these processes.

Besides the product realization processes, the organization needs processes that ensure
that the management is actively participating in quality related activities, and processes to ensure
that there are enough measurements and analysis of measurements so that the effectiveness of
processes can be checked and they can be continually improved. There may also be some other
support activities that are very important for assuring product quality. Here are some examples:
• A process that ensures that the management sets appropriate quality objectives for
projects in terms of defect density, reliability, etc,
• Processes to collect and analyze data that can help in estimating software size and effort
better,
• Processes to ensure that purchased hardware and software meet specifications,
• Processes to ensure that the system administration provides support at the required level
in upkeep of the network and
• Process to define and manage the QMS

39
 Figure gives a list of processes for a typical software development and maintenance
Organization.
Process Area Associated Procedures
QMS Management Periodic QMS review
Defining and maintaining the QMS
Measuring process performance
Measuring customer satisfaction
Control of records
Corrective and preventive actions
Management reviews
Quality Assurance Periodic internal audits
Project Software quality assurance
Requirements/Contract Management Setting up the contract
Contract review
Handling amendments to contract
Project Management Estimation
Project planning
Project tracking
Milestone Review
Project closure
Defect prevention
Software Configuration Management SCM Planning
Creating SCM infrastructure
Creating baselines
Changing baseline items
Performing releases
Life Cycle Activities Requirements Analysis
High Level Design
Detailed Design
Construction
Integrated testing
System testing
Acceptance testing
Maintenance

40
Work Product Review Plan for reviews
Conduct review
Track defect to closure
Purchasing Purchase requisition
Purchase evaluation
Placing the purchase order
Receipt and inspection of purchased goods
Sub-Contracting Identifying the need for sub-contracted items
Sub-contractor evaluation
Sub-contractor monitoring
Acceptance testing of sub-contracted items
Training Identifying training needs
Preparing training plan and calendar
Conducting training
Evaluating effectiveness of training

Table 5 : A Sample List of Processes and Procedures of a Software Organization

Following figure shows a process template that can be used for process definition.
Heading Description

Process Name The process name

A tabulation of the release made for the process definition and the
Revision history
changes incorporated in each release
A brief statement of why the process is required, and what it applies to
Purpose & Scope
(e.g. which type of project)
Responsibility The role with the overall responsibility for performing the process
Brief description A brief description of what the process does
List of procedures The procedures that constitute the process
Procedure-1 Detail
Name The name of procedure-1
Entry Criteria The criteria that trigger the procedure
Input The documents required for performing the procedure
The steps that will be followed in the procedure, along with the
Steps
responsibility for the step. The other processes, templates, checklists,

41
 etc. which the step requires will be referred from the step.
Outputs The output documents generated by the procedure
The criteria used to decide whether the procedure can be considered as
Exit Criteria
complete
Procedure-2 Detail
Procedure-3 Detail
……………..
Records & The records generated during the process, the retention period and the
Retention person responsible for the retention

Table 6 : A Process Definition Template

Process definitions typically need to contain or refer to other documents that are required
for implementing the process – procedures, forms, checklists, templates, guidelines and
standards.
The process (and procedure) definition is not just a set of text pages. Use of process
maps, organizational charts, flowcharts, decision trees and tables and lists can make the
document easier to understand and use. Flowcharts are particularly useful for documenting some
types of procedures. Persons performing the documentation should strive to make the document
readable and interesting.
The ISO 9001:2000 standard explicitly requires documented procedures to cover the
following:
• Control of documents
• Control of records
• Internal audit
• Control of non-conformity
• Corrective action and
• Prevention action

42
Defining and Maintaining the QMS
The overall responsibility for establishing and maintaining the QMS typically lies with
the person heading the quality initiative in the organization. This person should have the relevant
authority and follow the management mandate to be able to perform/coordinate all required
activities. She should report directly to the top management and not be under any operational
pressure. This person is usually the ‘management representative’ – a role described in the
standard.
In many software organizations, the Head of Quality is management representative and is
responsible for the QMS of the organization. The quality group in these organizations typically
consists of two sub-groups:
1. The Process Engineering Group (or Software Engineering Process Group or SEPG) that
is responsible for defining and modifying processes and
2. The Quality Assurance Group (SQAG) that is responsible for supporting the
implementation and verifying the compliance to the defined processes through audits and
process reviews.

The typical process to define and modify the QMS is depicted in Fig. and is described below.

Structure of QMS (Process Architecture)

Identify
Review the Processes to
QMS Define/Modify
Understand
Impact on Other
Processes

Prioritize the
Accept Change Definition/
requests to Modification
Define/Modify the
QMS
Processes

Perform Pilot
Implementation Roll-out the new
(If required) Processes

Figure 8: key elements of Process Definition and Modification

43
 Software organizations are increasing using intranet for making the QMS available
within the organization. The QMS documents may be created as a set of hyper-linked
documents. Users should be able to understand the structure of the QMS documentation and
reach the relevant sections easily.
When the QMS is implemented for the first time, an organization-wide orientation and
training is required.
Any change to the documentation must be controlled. Control needs to ensure:
• The person modifying the QMS document uses the correct version as the starting point,
• An impact analysis is done before making any change to any QMS document,
• The changes are made and reviewed,
• If necessary, the changed processes are piloted,
• Any required approval is sought and
• The changed document is then deemed to be the latest version which will be available to
anyone asking the document.

Control of Records
A special type of document that ISO 9001:2000 requires is a ‘record’. The standard
defines record as “document stating results achieved or providing evidenceof activities
performed”.
Records are particularly important because:
• They represent evidence that an activity was performed,
• They tell us how the activity was performed,
• The data in the records are used to track actions,
• The data in the records are used for analysis and provide input for continual
improvement through preventive and corrective action and
• This can be used for future decisions.
For example, the results of the unit test are documented in a record called ‘unit test
results’. The results:
• Provide an evidence that the unit testing was done,
• Give us the information on who did the testing, how long it took, how many defects were
found and when it was done,
• Contain the list of defects that need to be fixed and maybe re-tested for and

44
 • Data from multiple unit test results can be analyzed to see patterns of various types of
defects – this can be used to identify preventive action.
Figure contains the typical list of records relevant for a software organization.
Area
QMS Documentation
Management Review
Education, Skills,
Training
Internal Audits
Requirements/Contracting
Project Planning
Project Monitoring
Change
Management/SCM
Life Cycle Activities
Typical Records
• QMS Change Requests
• QMS Review and Approvals
• QMS Release Notes
• Agenda
• Reports and Presentations made during Management
review
• Minutes of Meeting
• Competence/skills database
• Training Needs
• Training Nomination
• Training Calendar
• Training Attendance
• Training Feedback
• Training Effectiveness Evaluation
• Audit Schedule
• Audit Interview Notes
• Audit Checklists Used
• Audit Non-Compliance & Observations
• Audit Report
• Review of contract/requirements
• Estimation
• Estimation
• Project Initiation Note
• Project Allocation Note
• Review and Approval of Project Plan
• Approval of Process Deviations
• Project Status Report
• Project Milestone review Reports
• Project review Minutes of Meeting
• Time sheets/Time logs
• Change request
• CCB minutes of meeting
• Check-in/Check-out details
• Back up records
• Release notes
• Configuration Item Lists
• Review of Requirements Specification Document
• Review of Design document
• Review of Detailed Design
• Review of Test Plans
45
 • Review of Code
• Test records
• Defect Logs
• Maintenance requests

Purchasing • Vendor database

• Purchase requisition
• Purchase evaluation/ subcontractor evaluation
• Purchase order/subcontract agreement
• Delivery Note
• Acceptance Note
• Audit Result on Supplier Processes
Others • Process performance measurements
• Customer Satisfaction survey
• Customer complaints
• List of customer supplied items
• Defect analysis
• Results of pilot projects for processes
• Preventive and corrective action
• Internal system admin calls
• General admin calls

46
47
48
Findings and Conclusion

Before a decade or two, the ultimate goal of any organization was to maximize profit.
But now, in this age of cut-throat competition, every businessman has understood the
importance of customer satisfaction. As it is obvious that a customer won’t be satisfied till his
expectations from the product are completely satisfied. Here comes the concept of quality. From
the in depth study of Software Quality and the ISO 9001:2000 Quality management system, we
come to know that an organization can not manufacture Quality Products exclusively. Because
from every customer’s point of view, quality is different. So the ISO 9001 says that if you want
to satisfy your customer, you have to incorporate the quality policy throughout the organization,
applying it to the processes those are carried out to develop the product.
In the last two decades, customers of the software industry have become more
demanding and no longer accept delayed projects, products with glitches or cost overruns. While
awarding software projects to software organizations, one of the questions that customers ask
themselves is ‘will this supplier deliver the software that meets the requirements with minimal
defects, on time and without cost overruns?’ The customer therefore needs some kind of
‘assurance’ that the system used by the supplier is capable of executing software projects
successfully. Many customers look for suppliers with ISO 9001 certification to give themselves
this assurance.
There is a lot of apprehension among software organizations and professionals that ISO
9001 is bureaucratic and documentation heavy. Often, while implementing ISO 9001, the
documentation of the QMS becomes a major project in its own right and seems an isolated and
useless exercise. Also the documented QMS is large, ponderous and detailed, and is impractical
and scarcely used. One of the aims of the year 2000 revision of the standard was to make the
amount and detail of the documentation more relevant to the result of the organization’s process
activities. The revision aims at simplification of documentation to a level relevant for addressing
the needs of each organization (depending on their size, business, etc) and is less prescriptive.
We can see these changes and the ease of documentation in the QMS designed by NIC.
The whole focus of this project work was on Software Quality and the Documentation
which is mostly ignored in many organizations. Probably that is why ISO 9001 has become a
must a ‘must have’ certification standard in the industry, especially in the software industry,
with more than 200 Indian software organizations being already certified to 1994 version of the

49
ISO 9001 standard and they are now moving to the revised ISO 9001:2000. Further, many
software giants are going for other quality models like Six Sigma, CMM, P-CMM, CMMI etc.
Whatever model you select, the basic rule is same for all,
“ To become market leader, you have to provide quality product and for that you have to
discipline your business processes.”

50
Annexure A : Other Quality Models

1. SW-CMM
Software Capability Maturity Model from Software Engineering Institute, Carnegie
Mellon University is a detailed model for software organizations. SW-CMM is based on the
concept of process maturity and levels of maturity. It is a staged model, that is it uses defined
capability maturity levels to assess the current standings of an organization. The model defines
level of progressively more mature process capabilities.
Figure depicts the five maturity levels and table shows the Key Process Areas for each of
the levels. The SW-CMM defines the requirements of each KPA in a way suitable to software
organization. So it is a useful reference while implementing ISO 9001.

Optimizing (5)
Focus on process
improvement

Managed (4)
Process Measured
and controlled

Defined (3)
Process characterized,
fairly well understood

Repeatable (2)
Can repeat previously
mastered tasks

Initial (1)
Unpredictable and
poorly controlled

Figure : The Software CMM Model

51
Level Key Process Areas
1 – Initial
2 – Repeatable Requirements management
Software project planning
Software project tracking and oversight
Software subcontract management
Software quality assurance
Software configuration management
3 – Defined Organization process focus
Organization process definition
Training program
Integrated software management
Software product engineering
Intergroup coordination
Peer reviews
4 – Managed Software quality management
Quantitative process management
5 – Optimizing Defect prevention
Technology change management
Process change management

Figure: The KPA across various maturity level of the SW-CMM

2. The People CMM

People Capability Maturity Model from CMU, is aimed at providing the management
and development of human assets of an organization through work-force practices. Following
table shows the maturity levels and KPAs.

Level Key Process Areas

1 - Initial
2 – Managed Staffing
Communication & Coordination
Work Environment
Performance Management
Training and development
Compensation
3 – Defined Competency Analysis
Workforce planning
Competency Development
Career Development
Competency-Based practices
Workgroup management
Participatory culture

52
4 – Predictable Competency integration
Empowered workgroups
Competency-based assets
Quantitative performance management
Organizational capability management
Mentoring
5 – Optimizing Continuous capability improvement
Organizational performance alignment
Continuous workforce innovation

53
Annexure B

ISO 9001
Third edition
2000-12-15
Quality management systems — Requirements

1 Scope
1.1 General
1.2 Application

2 Normative reference

3 Terms and definitions

4 Quality Management System

4.1 General requirements

The organization shall establish, document, implement and maintain a quality
management system and continually improve its effectiveness in accordance with the
requirements of this International Standard. The organization shall
a) identify the processes needed for the quality management system and their application
throughout the organization (see 1.2),
b) determine the sequence and interaction of these processes,
c) determine criteria and methods needed to ensure that both the operation and control of these
processes are effective,
d) ensure the availability of resources and information necessary to support the operation and
monitoring of these processes,
e) monitor, measure and analyze these processes, and
f) implement actions necessary to achieve planned results and continual improvement of these
processes.
These processes shall be managed by the organization in accordance with the
requirements of this International Standard. Where an organization chooses to outsource any
process that affects product conformity with requirements, the organization shall ensure control
over such processes. Control of such outsourced processes shall be identified within the quality
management system.

NOTE Processes needed for the quality management system referred to above should
include processes for management activities, provision of resources, product realization and
measurement.

4.2 Documentation requirements

4.2.1 General
The quality management system documentation shall include
a) documented statements of a quality policy and quality objectives,
b) a quality manual,
c) documented procedures required by this International Standard,

54
d) documents needed by the organization to ensure the effective planning, operation and control
of its processes, and
e) records required by this International Standard (see 4.2.4).
NOTE 1 Where the term “documented procedure” appears within this International
Standard, this means that the procedure is established, documented, implemented and
maintained.
NOTE 2 The extent of the quality management system documentation can differ from
one organization to another due to
a) the size of organization and type of activities,
b) the complexity of processes and their interactions, and
c) the competence of personnel.
NOTE 3 The documentation can be in any form or type of medium.

4.2.2 Quality manual

The organization shall establish and maintain a quality manual that includes
a) the scope of the quality management system, including details of and justification for any
exclusions (see 1.2),
b) the documented procedures established for the quality management system, or reference to
them, and
c) a description of the interaction between the processes of the quality management system.

4.2.3 Control of documents

Documents required by the quality management system shall be controlled. Records are
a special type of document and shall be controlled according to the requirements given in 4.2.4.
A documented procedure shall be established to define the controls needed
a) to approve documents for adequacy prior to issue,
b) to review and update as necessary and re-approve documents,
c) to ensure that changes and the current revision status of documents are identified,
d) to ensure that relevant versions of applicable documents are available at points of use,
e) to ensure that documents remain legible and readily identifiable,
f) to ensure that documents of external origin are identified and their distribution controlled, and
g) to prevent the unintended use of obsolete documents, and to apply suitable identification to
them if they are retained for any purpose.

4.2.4 Control of records

Records shall be established and maintained to provide evidence of conformity to
requirements and of the effective operation of the quality management system. Records shall
remain legible, readily identifiable and retrievable. A documented procedure shall be established
to define the controls needed for the identification, storage, protection, retrieval, retention time
and disposition of records.

5 Management responsibility

5.1 Management commitment

Top management shall provide evidence of its commitment to the development and
implementation of the quality management system and continually improving its effectiveness
by
a) communicating to the organization the importance of meeting customer as well as statutory
and regulatory requirements,
b) establishing the quality policy,
c) ensuring that quality objectives are established,

55
d) conducting management reviews, and
e) ensuring the availability of resources.

5.2 Customer focus

Top management shall ensure that customer requirements are determined and are met
with the aim of enhancing customer satisfaction (see 7.2.1 and 8.2.1).

5.3 Quality policy

Top management shall ensure that the quality policy
a) is appropriate to the purpose of the organization,
b) includes a commitment to comply with requirements and continually improve the
effectiveness of the quality management system,
c) provides a framework for establishing and reviewing quality objectives,
d) is communicated and understood within the organization, and
e) is reviewed for continuing suitability.

5.4 Planning
5.4.1 Quality objectives
Top management shall ensure that quality objectives, including those needed to meet
requirements for product [see 7.1 a)], are established at relevant functions and levels within the
organization. The quality objectives shall be measurable and consistent with the quality policy.

5.4.2 Quality management system planning

Top management shall ensure that a) the planning of the quality management system is
carried out in order to meet the requirements given in 4.1, as well as the quality objectives, and
b) the integrity of the quality management system is maintained when changes to the quality
management system are planned and implemented.

5.5 Responsibility, authority and communication

5.5.1 Responsibility and authority
Top management shall ensure that responsibilities and authorities are defined and
communicated within the organization.
5.5.2 Management representative
Top management shall appoint a member of management who, irrespective of other
responsibilities, shall have responsibility and authority that includes
a) ensuring that processes needed for the quality management system are established,
implemented and maintained,
b) reporting to top management on the performance of the quality management system and any
need for improvement, and
c) ensuring the promotion of awareness of customer requirements throughout the organization.
NOTE The responsibility of a management representative can include liaison with
external parties on matters relating to the quality management system.

5.5.3 Internal communication

Top management shall ensure that appropriate communication processes are established
within the organization and that communication takes place regarding the effectiveness of the
quality management system.

5.6 Management review

5.6.1 General
Top management shall review the organization's quality management system, at planned
intervals, to ensure its continuing suitability, adequacy and effectiveness. This review shall

56
include assessing opportunities for improvement and the need for changes to the quality
management system, including the quality policy and quality objectives. Records from
management reviews shall be maintained (see 4.2.4).

5.6.2 Review input

The input to management review shall include information on
a) results of audits,
b) customer feedback,
c) process performance and product conformity,
d) status of preventive and corrective actions,
e) follow-up actions from previous management reviews,
f) changes that could affect the quality management system, and
g) recommendations for improvement.

5.6.3 Review output

The output from the management review shall include any decisions and actions related to
a) improvement of the effectiveness of the quality management system and its processes,
b) improvement of product related to customer requirements, and
c) resource needs.

6 Resource management

6.1 Provision of resources

6.2 Human resources
6.2.1 General
6.2.2 Competence, awareness and training
6.3 Infrastructure
6.4 Work environment

7 Product realization

7.1 Planning of product realization

7.2 Customer-related processes
7.2.1 Determination of requirements related to the product
7.2.2 Review of requirements related to the product
7.2.3 Customer communication
7.3 Design and development
7.3.1 Design and development planning
7.3.2 Design and development inputs
7.3.3 Design and development outputs
7.3.4 Design and development review
7.3.5 Design and development verification
7.3.6 Design and development validation
7.3.7 Control of design and development changes
7.4 Purchasing
7.4.1 Purchasing process
7.4.2 Purchasing information
7.4.3 Verification of purchased product
7.5 Production and service provision
7.5.1 Control of production and service provision
7.5.2 Validation of processes for production and service provision

57
 7.5.3 Identification and traceability
7.5.4 Customer property
7.5.5 Preservation of product
7.6 Control of monitoring and measuring devices

8 Measurement, analysis and improvement

8.1 General
8.2 Monitoring and measurement
8.2.1 Customer satisfaction
8.2.2 Internal audit
8.2.3 Monitoring and measurement of processes
8.2.4 Monitoring and measurement of product
8.3 Control of nonconforming product
8.4 Analysis of data
8.5 Improvement
8.5.1 Continual improvement
8.5.2 Corrective action
8.5.3 Preventive action

58
Annexure C :
ISO 9001 Certified Software Companies in India
Aditi Technologies Pvt Ltd
Aptech Ltd
Aspire Systems (India) Pvt. Ltd.
Bells Softech Limited
Bharti Telesoft Ltd.
Birlasoft Limited
Blue Star Infotech Ltd
BPL Telecom Ltd.
Cognizant Technology Solutions India Pvt. Ltd. Pentamedia Graphics Ltd
Convergys India Services Pvt Ltd
Datamatics Ltd.
Datamatics Technologies Ltd
Eclipse Systems Pvt. Ltd.
EDS - Electronic Data Systems (India) Pvt Ltd
GE Capital Services India
Geometric Software Solutions Company Ltd
HCL Technologies Ltd
Hexaware Technologies Limited
Honeywell Technology Solutions Lab Pvt Ltd
IBM Global Services India Pvt Ltd
iGATE Global Solutions Ltd
Information Technology Park Ltd
ITC Infotech India Ltd
Kanbay Software (India) Pvt Ltd
KPIT Cummins Infosystems Ltd
LG Soft India Pvt. Ltd.
Mahindra - British Telecom Ltd
Mphasis BFL Ltd.
Neilsoft Limited
NIIT Technologies Ltd
Patni Computer Systems Ltd
Philips Software Centre Pvt. Ltd
Polaris Software Lab Ltd
PSI Data Systems Ltd.
Rolta India Ltd.
Samsung Electronics India Software
Operations (SISO)
SAP India Pvt. Ltd.
Satyam Computer Services Ltd
Tasaa Netcom Private Limited
Tata Consultancy Services Ltd
Tata Technologies Limited
Wipro Technologies (Wipro Ltd)
Zenith Software Limited
Zensar Technologies Limited
59
Bibliography

Books References

• Software Engineering A Practitioner’s Approach, by Roger S. Pressman, McGraw-Hill

International Edition

• ISO 9001:2000 for Software Organization, By Swapna Kisore and Rajesh Naik, Tata
McGraw-Hill Publishing Company Limited

• ISO 9001 Interpreted for Software Organizations, By R. A. Radice, Paradoxicon

Publishing

Web References

• http://www.iso.org
• www.swquality.com
• www.nasscom.org
• http://www.mah.nic.in
• www.isixsigma.com
• http://www.sei.cmu.edu

60