ISO 9000-3:1997
(Main)Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software
Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software
Normes pour le management de la qualité et l'assurance de la qualité — Partie 3: Lignes directrices pour l'application de l'ISO 9001:1994 au développement, à la mise à disposition, à l'installation et à la maintenance du logiciel
General Information
Relations
Frequently Asked Questions
ISO 9000-3:1997 is a standard published by the International Organization for Standardization (ISO). Its full title is "Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software". This standard covers: Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software
Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software
ISO 9000-3:1997 is classified under the following ICS (International Classification for Standards) categories: 03.100.70 - Management systems; 03.120.10 - Quality management and quality assurance; 35.080 - Software. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 9000-3:1997 has the following relationships with other standards: It is inter standard links to ISO 10340:1995, SIST ISO 9000-3:1996, ISO 9000-3:1991, ISO/IEC 90003:2004. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 9000-3:1997 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 9000-3
Second edition
1997-12-15
Quality management and quality assurance
standards —
Part 3:
Guidelines for the application of
ISO 9001:1994 to the development, supply,
installation and maintenance of computer
software
Normes pour le management de la qualité et l'assurance de la qualité —
Partie 3: Lignes directrices pour l'application de l'ISO 9001:1994 au
développement, à la mise à disposition, à l'installation et à la maintenance
de logiciel
A
Reference number
Contents Page
1 Scope. 1
2 Normative references. 1
3 Definitions. 1
4 Quality system requirements. 2
4.1 Management responsibility. 2
4.2 Quality system. 4
4.3 Contract review . 5
4.4 Design control . 7
4.5 Document and data control. 14
4.6 Purchasing. 15
4.7 Control of customer-supplied product . 16
4.8 Product identification and traceability. 17
4.9 Process control . 18
4.10 Inspection and testing . 19
4.11 Control of inspection, measuring and test equipment. 22
4.12 Inspection and test status . 23
......................................
4.13 Control of nonconforming product 24
4.14 Corrective and preventive action. 25
4.15 Handling, storage, packaging, preservation and
delivery . 25
4.16 Control of quality records. 27
4.17 Internal quality audits . 28
4.18 Training. 28
4.19 Servicing. 28
4.20 Statistical techniques. 30
Annex A Bibliography . 31
Annex B Cross-references to ISO/IEC 12207 . 32
© ISO 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 • CH-1211 Genève 20 • Switzerland
Internet central@iso.ch
X.400 c=ch; a=400net; p=iso; o=isocs; s=central
Printed in Switzerland
ii
©
ISO ISO 9000-3:1997(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide
federation of national standards bodies (ISO member bodies). The work of
preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which
a technical committee has been established has the right to be represented
on that committee. International organizations, governmental and non-
governmental, in liaison with ISO, also take part in the work. ISO
collaborates closely with the International Electrotechnical Commission
(IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting
a vote.
International Standard ISO 9000-3 was prepared by Technical Committee
ISO/TC 176, Quality management and quality assurance, Subcommittee
SC 2, Quality systems.
This second edition cancels and replaces the first edition
(ISO 9000-3:1991), which has been technically revised.
ISO 9000 consists of the following parts, under the general title Quality
management and quality assurance standards:
— Part 1: Guidelines for selection and use
— Part 2: Generic guidelines for the application of ISO 9001, ISO 9002
and ISO 9003
— Part 3: Guidelines for the application of ISO 9001:1994 to the
development, supply, installation and maintenance of computer
software
— Part 4: Guide to dependability programme management.
Annexes A and B of this part of ISO 9000 are for information only.
iii
©
Introduction
This part of ISO 9000 provides guidance in applying the requirements of
ISO 9001:1994 where computer software design, development, installation
and maintenance are an element of the business of a supplier:
a) as part of a commercial contract with an external organization;
b) as a product available for a market sector;
c) in support of the business processes of the supplier;
d) as software embedded in a hardware product.
It identifies the issues which need to be addressed and is independent of
the technology, life cycle models, development processes, sequence of
activities, or organization structure used by a supplier.
Where the scope of an organization's activities includes areas other than
computer software development, the relationship between the computer
software elements of that organization's quality system and the remaining
aspects should be clearly documented within the quality system as a
whole.
This part of ISO 9000 provides guidelines for the application of
ISO 9001:1994.
Where text has been quoted from ISO 9001:1994, that
text is enclosed in a box, for ease of identification.
Throughout this part of ISO 9000, “shall” is used to express a provision that
is binding between two or more parties; “will” to express a declaration of
purpose, or intent, of one party; “should” to express a recommendation
among possibilities; and “may” to indicate a course of action permissible
within the limits of this parts of ISO 9000.
iv
©
INTERNATIONAL STANDARD ISO ISO 9000-3:1997(E)
Quality management and quality assurance standards —
Part 3:
Guidelines for the application of ISO 9001:1994 to the development,
supply, installation and maintenance of computer software
1 Scope
This part of ISO 9000 sets out guidelines to facilitate the application of ISO 9001:1994 for organizations developing,
supplying, installing and maintaining computer software. It does not add to, or otherwise change, the requirements of
ISO 9001.
This part of ISO 9000 is not intended to be used as assessment criteria in quality system registration/certification.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of
ISO 9000. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties
to agreements based on this part of ISO 9000 are encouraged to investigate the possibility of applying the most recent
edition of the standards indicated below. Members of IEC and ISO maintain registers of currently valid International
Standards.
ISO 8402:1994, Quality management and quality assurance — Vocabulary.
ISO 9001:1994, Quality systems — Model for quality assurance in design, development, production, installation and
servicing.
3 Definitions
For the purposes of this part of ISO 9000, the definitions given in ISO 8402 and the following definitions apply.
3.1 product: Result of activities or processes.
NOTE 1 A product may include service, hardware, processed materials, software or a combination thereof.
NOTE 2 A product can be tangible (e.g. assemblies or processed materials) or intangible (e.g. knowledge or concepts), or a
combination thereof.
NOTE 3 For the purposes of this International Standard, the term “product” applies to the intended product offering only and
not to unintended “by-products” affecting the environment. This differs from the definition given in ISO 8402.
[ISO 9001]
3.2 tender: Offer made by a supplier in response to an invitation to satisfy a contract award to provide product.
[ISO 9001]
©
3.3 contract: Agreed requirements between a supplier and customer transmitted by any means.
[ISO 9001]
3.4 baseline: A formally approved version of a configuration item, regardless of media, formally designated and
fixed at a specific time during the configuration item's life cycle.
[ISO/IEC 12207]
3.5 development: Software life cycle process that comprises the activities of requirements analysis, design,
coding, integration, testing, installation and support for acceptance of software products.
3.6 life cycle model: A framework containing the processes, activities, and tasks involved in the development,
operation, and maintenance of a software product, spanning the life of the system from the definition of its
requirements to the termination of its use.
[ISO/IEC 12207]
3.7 phase: Defined segment of work.
NOTE — A phase does not imply the use of any specific life cycle model.
3.8 regression testing: Testing to determine that changes made in order to correct defects have not introduced
additional defects.
3.9 replication: Copying a software product from one medium to another.
3.10 software: See software product (3.11).
NOTE — In this part of ISO 9000, the term “software” is confined to computer software.
3.11 software product: The set of computer programs, procedures, and possibly associated documentation and
data.
[ISO/IEC 12207]
NOTE — A software product may be designated for delivery, an integral part of another product, or used in the development
process.
3.12 software item: Any identifiable part of a software product.
4 Quality system requirements
4.1 Management responsibility
4.1.1 Quality policy
The supplier's management with executive responsibility shall define and document its policy for
quality including objectives for quality and its commitment to quality. The quality policy shall be
relevant to the supplier's organizational goals and the expectations and needs of its customers. The
supplier shall ensure that this policy is understood, implemented and maintained at all levels of the
organization.
No further software-related guidance is provided.
©
ISO ISO 9000-3:1997(E)
4.1.2 Organization
4.1.2.1 Responsibility and authority
The responsibility, authority and the interrelation of personnel who manage, perform and verify work
affecting quality shall be defined and documented, particularly for personnel who need the
organizational freedom and authority to:
a) initiate action to prevent the occurrence of any nonconformities relating to product, process and
quality system;
b) identify and record any problems relating to the product, process and quality system;
c) initiate, recommend or provide solutions through designated channels;
d) verify the implementation of solutions;
e) control further processing, delivery or installation of nonconforming product until the deficiency
or unsatisfactory condition has been corrected.
No further software-related guidance is provided.
4.1.2.2 Resources
The supplier shall identify resource requirements and provide adequate resources, including the
assignment of trained personnel (see 4.18), for management, performance of work and verification
activities including internal quality audits.
No further software-related guidance is provided.
NOTE — For further information see ISO/IEC 12207:1995, subclause 7.2.
4.1.2.3 Management representative
The supplier's management with executive responsibility shall appoint a member of the supplier's
own management who, irrespective of other responsibilities, shall have defined authority for:
a) ensuring that a quality system is established, implemented and maintained in accordance with
this International Standard, and;
b) reporting on the performance of the quality system to the supplier's management for review and
as a basis for improvement of the quality system.
NOTE 5 The responsibility of a management representative may also include liaison with external parties
on matters relating to the supplier's quality system.
No further software-related guidance is provided.
NOTE — For further information, see ISO/IEC 12207:1995, subclause 6.3.1.6.
4.1.3 Management review
The supplier's management with executive responsibility shall review the quality system at defined
intervals sufficient to ensure its continuing suitability and effectiveness in satisfying the requirements
of this International Standard and the supplier's stated quality policy and objectives (see 4.1.1).
Records of such reviews shall be maintained (see 4.16).
©
No further software-related guidance is provided.
NOTE — For further information, see ISO/IEC 12207:1995, subclause 7.1.4.
4.2 Quality system
4.2.1 General
The supplier shall establish, document and maintain a quality system as a means of ensuring that
product conforms to specified requirements. The supplier shall prepare a quality manual covering
the requirements of this International Standard. The quality manual shall include or make reference
to the quality system procedures and outline the structure of the documentation used in the quality
system.
NOTE 6 Guidance on quality manuals is given in ISO 10013.
No further software-related guidance is provided.
4.2.2 Quality system procedures
The supplier shall:
a) prepare documented procedures consistent with the requirements of this International
Standard and the supplier's stated quality policy, and;
b) effectively implement the quality system and its documented procedures.
For the purpose of this International Standard, the range and detail of the procedures that form part
of the quality system shall be dependent upon the complexity of the work, the methods used, and
the skills and training needed by personnel involved in carrying out the activity.
NOTE 7 Documented procedures may make reference to work instructions that define how an activity is
performed.
No further software-related guidance is provided.
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 the following activities, as appropriate, in meeting the specified requirements for
products, projects or contracts:
a) the preparation of quality plans;
b) the identification and acquisition of any controls, processes, equipment (including inspection
and test equipment), fixtures, resources and skills that may be needed to achieve the required
quality;
c) ensuring the compatibility of the design, the production process, installation, servicing,
inspection and test procedures and the applicable documentation.
d) the updating, as necessary, of quality control, inspection and testing techniques, including the
development of new instrumentation;
e) the identification of any measurement requirement involving capability that exceeds the known
state of the art, in sufficient time for the needed capability to be developed;
©
ISO ISO 9000-3:1997(E)
f) the identification of suitable verification at appropriate stages in the realization of product;
g) the clarification of standards of acceptability for all features and requirements, including those
which contain a subjective element;
h) the identification and preparation of quality records (see 4.16).
NOTE 8 The quality plans referred to [see 4.2.3a)] may be in the form of a reference to the appropriate
documented procedures that form an integral part of the supplier's quality system.
Quality planning should address the following items, as appropriate:
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;
f) detailed planning (including schedules, procedures, resources and approval) and specific responsibilities and
authorities for:
— configuration management,
— verification and validation of developed products,
— verification and validation of purchased products,
— verification of customer-supplied products,
— control of nonconforming product and corrective action,
— assuring that activities described in the quality plan are carried out.
A quality plan provides the means for tailoring the application of the quality system to a specific project, product or
contract.
A quality plan may include or reference generic and/or project/product/contract-specific procedures, as appropriate. A
quality plan should be updated along with the progress of the development, and items concerned with each phase
should be completely defined when starting that phase.
A quality plan should be reviewed and agreed by all organizations concerned in its implementation.
The document that describes a quality plan may be an independent document (entitled quality plan), a part of another
document, or composed of several documents.
A quality plan may include, or reference, the plans for unit, integration, system and acceptance tests. Guidance on test
planning and the test environment is provided as part of inspection and testing .
NOTE — Guidance on quality plans is given in ISO 10005 and on configuration management in ISO 10007. For further
information, see ISO/IEC 12207:1995, subclauses 6.2 to 6.5.
4.3 Contract review
4.3.1 General
The supplier shall establish and maintain documented procedures for contract review and for the
coordination of these activities.
Software may be developed as part of a contract, as a product available for a market sector, as software embedded in
a hardware product, or in support of the business processes of the supplier. Contract review is applicable in all these
circumstances.
©
4.3.2 Review
Before submission of a tender, or the acceptance of a contract or order (statement of requirement),
the tender, contract or order shall be reviewed by the supplier to ensure that:
a) the requirements are adequately defined and documented; where no written statement of
requirement is available for an order received by verbal means, the supplier shall ensure that
the order requirements are agreed before their acceptance;
b) any differences between the contract or order requirements and those in the tender are
resolved;
c) the supplier has the capability to meet the contract or order requirements.
The following concerns may also be relevant during the supplier's review of software tenders, contracts, or orders.
a) Customer-related concerns:
— the terminology to be used, is agreed by the relevant parties;
— the customer has the capability and resources to meet the defined contractual obligations;
— agreed criteria for customer to accept or reject product;
— the customer's responsibilities in the provision of data and related facilities;
— the extent to which the customer is to participate in joint development or in subcontracted work;
— the arrangements for joint reviews to monitor progress of the contract;
— the agreed procedure for handling changes in customer's requirements during the development and/or
maintenance;
— life-cycle processes imposed by the customer;
— handling of problems detected after acceptance, including customer complaints and claims;
— the responsibility for removal of nonconformities after any warranty period;
— any obligations for the customer to upgrade to a subsequent version when the supplier dictates, or for the
supplier to maintain historic versions;
— deployment and associated user training.
b) Technical concerns:
— the feasibility of meeting the requirements;
— the software development standards and procedures to be used;
— facilities, tools, software items and data, to be provided by the customer, are identified and methods defined
and documented to assess their suitability for use;
— the operating system or hardware platform;
— agreement on the control of interfaces with the software product;
— replication and distribution requirements.
c) Management concerns:
— possible contingencies or risks are identified and the impact of these on subsequent activities are assessed;
— the supplier's responsibility with regard to subcontracted work;
— scheduling of progress, technical reviews and deliverables;
— installation, maintenance and support requirements;
— the timely availability of technical, human and financial resources.
d) Legal, security and confidentiality concerns:
— information handled under the contract may be subject to concerns regarding Intellectual Property Rights,
licence agreements, confidentiality and the protection of such information;
— guardianship of the master copy of the product and the rights of the customer to access or verify that master
copy;
— the level of information disclosure to the customer needs to be mutually agreed to by the parties;
— definition of warranty terms;
— liabilities/penalties associated with the contract.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.2.1, 5.2.6 and 6.4.2.1.
©
ISO ISO 9000-3:1997(E)
4.3.3 Amendment to a contract
The supplier shall identify how an amendment to a contract is made and correctly transferred to the
functions concerned within the supplier's organization.
No further software-related guidance is provided.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.1.3.5 and 5.2.3.2.
4.3.4 Records
Records of contract reviews shall be maintained (see 4.16).
NOTE 9 Channels for communication and interfaces with the customer's organization in these contract
matters should be established.
No further software-related guidance is provided.
4.4 Design control
4.4.1 General
The supplier shall establish and maintain documented procedures to control and verify the design of
the product in order to ensure that the specified requirements are met.
This subclause provides guidance on the development activities of requirements analysis, architectural design, detailed
design and coding. This subclause also contains guidance on development planning.
A software development project should be organized according to one or more life cycle models. Processes, activities
and tasks should be planned and performed according to the nature of the life cycle model used. The life cycle model
used may be adapted to suit particular project needs. This part of ISO 9000 is intended for application irrespective of
the life cycle model used and is not intended to indicate a specific life cycle model.
A life cycle model identifies a set of processes and specifies when and how the processes are invoked. The sequence
in which the processes are described in this part of ISO 9000 does not suggest in any way the sequence in which they
are performed.
The development process is that which transforms the requirements into a software product. This process should be
carried out in a disciplined manner, in order to prevent the introduction of errors. This approach reduces dependence
on the verification and validation processes as the sole methods for identifying problems. The supplier should
therefore establish and maintain documented procedures that ensure that the software products are developed in
compliance with specified requirements and in accordance with the development plan and/or quality plan.
The following aspects inherent to the design activities should be taken into account:
a) Design method: a design method should be systematically used. Consideration should be given to the suitability
of that method for the type of task, product or project and the compatibility of the application, the methods and the
tools to be used.
©
b) Use of past experiences: utilizing lessons learned from past experiences, the supplier should avoid recurrences
of the same or similar problems by applying lessons learned from previous projects, analysis of metrics and post-
project reviews.
c) Subsequent processes: to the extent practical, the software product should be designed to facilitate testing, install-
ation, maintenance and use.
d) Security and safety: special consideration should be given to the design for testability or validation. For products
where failure may cause damage to people, property or the environment, design of such software should ensure
definition of specific design requirements that specify desired immunity from, and system response to, potential
failure conditions.
For coding, rules for the use of programming languages, consistent naming conventions, coding and adequate
commentary rules should be specified and observed. Such rules should be documented and controlled.
The supplier may use tools, facilities and techniques in order to make the quality system guidelines in this part of ISO
9000 effective. These tools, facilities and techniques can be effective for management purposes as well as for product
development and/or servicing. Whether these tools and techniques are developed internally, or purchased, the
supplier should evaluate whether or not they are fit for purpose. Tools used in the implementation of the product, such
as analysis and design tools, compilers, and assemblers should be approved and placed under an appropriate level of
configuration management control, prior to use. The scope of use of such tools and techniques should be documented
and their use reviewed as appropriate, to determine whether there is a need to improve and/or upgrade them.
Personnel may need training in the use of such tools and techniques, at commencement of usage, or after any
improvements/upgrades.
4.4.2 Design and development planning
The supplier shall prepare plans for each design and development activity. The plans shall describe
or reference these activities, and define responsibility for their implementation. The design and
development activities shall be assigned to qualified personnel equipped with adequate resources.
The plans shall be updated as the design evolves.
For software products, development planning should determine the activities of requirements analysis, design, coding,
integration, testing, installation and support for acceptance of software products. Development planning should be
documented in a development plan.
A development plan should be reviewed and approved. A development plan may have other names such as “software
development plan” or “software project plan”.
A development plan may define how the project is to be managed, the progress reviews required and the type and
frequency of reports to management, the customer, and other relevant parties, taking into account any contractual
requirements.
Development planning should address the following items, as appropriate:
a) the definition of the project, including a statement of its objectives and reference to any related customer or
supplier projects;
b) the definition of input and output of the project as a whole;
c) the organization of the project resources, including the team structure, responsibilities, use of subcontractors and
material resources to be used;
d) organizational and technical interfaces between different individuals or groups, such as
— sub-project teams,
— subcontractors,
©
ISO ISO 9000-3:1997(E)
—users,
— customer representatives,
— quality assurance representative;
e) the identification of, or reference to
— development activities to be carried out,
— required inputs to each activity,
— required outputs from each activity,
— management and supporting activities to be carried out;
f) the analysis of the possible risks, assumptions, dependencies and problems associated with the development;
g) the schedule identifying
— the phases of the project,
— the work to be performed (the inputs to, outputs from and definition of each task),
— the associated resources and timing,
— the associated dependencies,
— the milestones;
h) the identification of
— standards, rules, practices and conventions,
— tools and techniques for development, including the qualification of, and configuration controls placed on,
such tools and techniques,
— configuration management practices,
— method of controlling nonconforming products,
— methods of control of nondeliverable software used to support development,
— procedures for archiving, back-up and recovery, including contingency planning,
— methods of control for virus protection;
i) the identification of related plans (including system level plans) such as
— quality plan,
— risk management plan,
— configuration management plan,
— integration plan,
— test plan,
— installation plan,
— migration plan,
— training plan,
— maintenance plan,
— re-use plan.
The development plan and any of these related plans may be an independent document, a part of another document or
composed of several documents.
NOTE — For further information, see ISO/IEC 12207:1995, subclause 5.2.4.
©
4.4.3 Organizational and technical interfaces
Organizational and technical interfaces between different groups which input into the design process
shall be defined and the necessary information documented, transmitted and regularly reviewed.
The boundaries of responsibility for each part of the software product and the way that technical information will be
transmitted between all parties should be clearly defined in the development plans of suppliers or subcontractors. The
supplier may require submission of a subcontractor's development plan, for review.
In defining interfaces, care should be taken to consider parties, other than the customer and supplier, who need input
to the design, installation, maintenance and training activities. These may include subcontractors, regulatory
authorities, associated development projects and help-desk staff. In particular, the end-users and any intermediate
operations function may need to be involved to ensure that appropriate capacity and training are available to achieve
committed service levels.
The customer may have certain responsibilities under the contract. Particular concerns include the need for the
customer to cooperate with the supplier, to provide necessary information in a timely manner, and resolve action items.
Where a customer representative is appropriate, he/she may represent the eventual user of the product, as well as
executive management, and have the authority to deal with contractual matters which include, but are not limited to, the
following:
a) defining the customer's requirements to the supplier;
b) answering questions from the supplier;
c) approving the supplier's proposals;
d) concluding agreements with the supplier;
e) ensuring that the customer's organization observes the agreements made with the supplier;
f) defining the acceptance criteria and procedures;
g) dealing with customer-supplied software items, data, facilities and tools that are found unsuitable for use;
h) defining the customer's responsibility.
Where mutually agreed, joint reviews involving the supplier and customer may be scheduled on a regular basis, or at
significant project events, to cover the following aspects, as appropriate:
a) the progress of software development work undertaken by the supplier;
b) the progress of agreed activities being undertaken by the customer;
c) conformance of the development products to the customer's agreed requirements specification;
d) the progress of activities concerning the eventual users of the system under development, such as system
conversion and training;
e) verification results;
f) acceptance test results.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.2.6.1 and 6.6.2.
4.4.4 Design input
Design input requirements relating to the product, including applicable statutory and regulatory
requirements, shall be identified, documented and their selection reviewed by the supplier for
adequacy. Incomplete, ambiguous or conflicting requirements shall be resolved with those
responsible for imposing these requirements.
Design input shall take into consideration the results of any contract review activities.
The requirements specification should be provided by the customer. However, where mutually agreed, the supplier
may provide the specification. In such a case, the supplier should, where appropriate:
©
ISO ISO 9000-3:1997(E)
a) establish documented procedures for developing the requirements specification, including
— methods for agreeing on requirements and authorizing changes, especially during iterative development,
— methods for the evaluation of prototypes or demonstrations, where used,
— recording and reviewing discussion results on both sides,
b) develop the requirements specification in close cooperation with the customer and make efforts to prevent
misunderstandings by, for example, provision of definition of terms, explanation of the background of
requirements,
c) obtain the customer's approval of the requirements specification.
Interviews, surveys, studies, prototypes, demonstrations and analysis methods may be used for developing the
requirements specification, as appropriate.
The requirements specification may be provided and agreed in the form of a system specification. In this case,
procedures should be in place to ensure the correct allocation of system requirements into hardware and software
aspects and also the appropriate interface specifications.
The requirements specification may not be fully defined at contract acceptance, and may be developed during a
project. The contract may be amended when the requirements specification changes. Changes to the requirements
specification should be controlled.
The requirements should include all aspects necessary to satisfy the customer's agreed needs. The requirements
specification may need to take the operational environment into account. The requirements may include, but not be
limited to the following characteristics: functionality; reliability; usability; efficiency; maintainability and portability (see
also ISO/IEC 9126). Sub-characteristics may be specified, for example security. Safety considerations and statutory
obligations may also be specified.
If the software product needs to interface with other software or hardware products, the interfaces between the
software product to be developed and other software or hardware products should be specified, as far as possible,
either directly or by reference, in the requirements specification.
The requirements should be expressed in terms which allow validation during product acceptance.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.3.2 to 5.3.4.
4.4.5 Design output
Design output shall be documented and expressed in terms that can be verified and validated
against design input requirements.
Design output shall:
a) meet the design input requirements;
b) contain or make reference to acceptance criteria;
c) identify those characteristics of the design that are crucial to the safe and proper functioning of
the product (e.g., operating, storage, handling, maintenance and disposal requirements).
Design output documents shall be reviewed before release.
The required output from the design activity should be defined and documented in accordance with the chosen
method. This documentation should be correct, complete and consistent with the requirements. Design outputs may
include:
— architectural design specification;
— detailed design specification;
— source code;
— user guides.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.3.5 to 5.3.7.
©
4.4.6 Design review
At appropriate stages of design, formal documented reviews of the design results shall be planned
and conducted. Participants at each design review shall include representatives of all functions
concerned with the design stage being reviewed, as well as other specialist personnel, as required.
Records of such reviews shall be maintained (see 4.16).
The supplier should plan and implement review processes for all software development projects. The degree of
formality and rigour of the activities associated with the review processes should be appropriate to the complexity of the
product and the degree of risk associated with the specified use of the software product. The supplier should establish
documented procedures for dealing with process and product deficiencies or nonconformities identified during these
activities.
During design reviews, aspects inherent to the design activities should be taken into account, for example feasibility,
security and safety, programming rules and testability.
The results of review, and any further activities required to ensure that the specified requirements are met, should be
recorded and checked when they are completed.
Most design reviews during the development are scheduled, but there may also be unscheduled design reviews.
A documented design review procedure should address the following:
a) what is to be reviewed, when, and the type of review;
b) what functional groups would be concerned in each type of review and, if there is to be a review meeting, who
would chair it;
c) what records have to be produced, for example meeting minutes, issues, problems, actions and action status.
Also the following may be addressed in the design review procedure:
a) the methods for monitoring the application of rules, practices and conventions to ensure compliance, such as peer
reviews, walkthroughs, code inspections;
b) what has to be done prior to the conduct of a review, such as establishment of objectives, meeting agenda,
documents required and roles of review personnel;
c) what has to be done during the review, including the techniques to be used and guidelines for all participants;
d) the success criteria for the review;
e) what follow-up methods are to be used to ensure that issues identified at the review are resolved.
Where specified in the contract, the supplier should conduct design review meetings in cooperation with the customer.
Both parties should agree on the results of such reviews.
It is recommended that further design activities should proceed only when the consequences of all known deficiencies
are satisfactorily resolved, or the risk of proceeding otherwise is known.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.3.4.2, 5.3.5.6, 5.3.6.7 and 6.6.3.
4.4.7 Design verification
At appropriate stages of design, design verification shall be performed to ensure that the design stage output
meets the design stage input requirements. The design verification measures shall be recorded (see 4.16).
NOTE 10 In addition to conducting design reviews (see 4.4.6), design verification may include activities such as
— performing alternative calculations,
— comparing the new design with a similar proven design, if available,
— undertaking tests and demonstrations, and
— reviewing the design stage documents before release.
©
ISO ISO 9000-3:1997(E)
Verification of design should be performed as appropriate during the development process. Design verification may
comprise reviews of design output, demonstrations including prototypes and simulations, or tests. Verification may be
conducted on the output from other development activities. These verification activities should be planned and
conducted in accordance with the quality plan or documented procedures to ensure that process outputs meet the
process input requirements.
The verification results and any further actions required to ensure that the design stage input requirements are met
should be recorded and checked when the actions are completed.
Only verified design outputs should be submitted for acceptance and subsequent use. Any findings should be
adequately addressed and resolved.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.3.4.2, 5.3.5.6, 5.3.5.7, 5.3.7.5, 5.3.9 and 6.4.
4.4.8 Design validation
Design validation shall be performed to ensure that product conforms to defined user needs and/or
requirements.
NOTES
11 Design validation follows successful design verification (see 4.4.7).
12 Validation is normally performed under defined operating conditions.
13 Validation is normally performed on the final product, but may be necessary in earlier stages prior to
product completion.
14 Multiple validations may be performed if there are different intended uses.
Before offering the product for customer acceptance, the supplier should validate the product in accordance with its
specified intended use, for example during final inspection and test.
In software development, it is important that the validation results and any further actions required to ensure that the
specified requirements are met should be recorded and checked when the actions are completed. Only validated
products should be submitted for acceptance and subsequent use.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.3.1 and 6.5.
4.4.9 Design changes
All design changes and modifications shall be identified, documented, reviewed and approved by
authorized personnel before their implementation.
The supplier should establish and maintain procedures for controlling the implementation of any design changes, which
may arise at any time during the product life cycle, in order to:
a) document and justify the change;
b) evaluate consequences of the change;
c) approve or disapprove the change;
d) implement and verify the change.
In the software development environment, control of design changes is usually addressed under the discipline of
configuration management.
NOTE — For further information, see ISO/IEC 12207:1995, subclauses 5.5.2, 5.5.3 and 6.2.3.
©
4.5 Document and data control
4.5.1 General
The supplier shall establish and maintain documented procedures to control all documents and data
that relate to the requirements of this International Standard including, to the extent applicable,
documents of external origin such as standards and customer drawings.
NOTE 15 Documents and data can be in the form of any type of media, such as hard copy or electronic
media.
Configuration management procedures may be used to implement document and data control. In establishing the
procedures to control documents and data, the supplier should identify those documents and data, including those of
external origin such as standards and customer data, which should be subject to the control procedures.
The document and data control procedures should be applied to relevant documents and data, including the following:
a) contractual documents including specification of requirements;
b) procedural documents describing the quality system to be applied in the software life cycle;
c) planning documents describing the planning and progress of activities of the supplier and the suppliers
interactions with the customer;
d) product documents and data describing or associated with a particular software product.
NOTE — For further information, see ISO/IEC 12207, clause 6.1.
4.5.2
...
NORME ISO
INTERNATIONALE 9000-3
Deuxième édition
1997-12-15
Normes pour le management de la qualité
et l'assurance de la qualité —
Partie 3:
Lignes directrices pour l'application de
l'ISO 9001:1994 au développement, à la mise
à disposition, à l'installation et à la
maintenance du logiciel
Quality management and quality assurance standards —
Part 3: Guidelines for the application of ISO 9001:1994 to the development,
supply, installation and maintenance of computer software
A
Numéro de référence
Sommaire
1 Domaine d’application .1
2 Références normatives .1
3 Définitions .1
4 Exigences en matière de système qualité.3
4.1 Responsabilité de la direction.3
4.2 Système qualité.4
4.3 Revue de contrat.6
4.4 Maîtrise de la conception.8
4.5 Maîtrise des documents et des données.16
4.6 Achats.17
4.7 Maîtrise du produit fourni par le client .19
4.8 Identification et traçabilité du produit .20
4.9 Maîtrise des processus .22
4.10 Contrôles et essais.24
4.11 Maîtrise des équipements de contrôle, de mesure et d'essai .27
4.12 État des contrôles et des essais .28
4.13 Maîtrise du produit non conforme .29
4.14 Actions correctives et préventives .30
4.15 Manutention, stockage, conditionnement, préservation et livraison.31
4.16 Maîtrise des enregistrements relatifs à la qualité.33
4.17 Audits qualité internes .34
4.18 Formation .34
© ISO 1997
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l'éditeur.
Organisation internationale de normalisation
Case postale 56 • CH-1211 Genève 20 • Suisse
Internet iso@iso.ch
Version française tirée en 1998.
Imprimé en Suisse
ii
© ISO
4.19 Prestations associées . 34
4.20 Techniques statistiques. 36
Annexe A (informative) Bibliographie . 38
Annexe B (informative) Références croisées entre l'ISO 9000-3 et l'ISO/CEI 12207. 39
iii
© ISO
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée aux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du comité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
La Norme internationale ISO 9000-3 a été élaborée par le comité technique ISO/TC 176, Management et assurance
de la qualité, sous-comité SC 2, Systèmes qualité.
Cette deuxième édition annule et remplace la première édition (ISO 9000-3:1991), dont elle constitue une révision
technique.
L’ISO 9000 comprend les parties suivantes, présentées sous le titre général Normes pour le management de la
qualité et l'assurance de la qualité:
Partie 1: Lignes directrices pour leur sélection et utilisation
Partie 2: Lignes directrices génériques pour l'application de l'ISO 9001, l'ISO 9002 et l'ISO 9003
Partie 3: Lignes directrices pour l'application de l'ISO 9001:1994 au développement, à la mise à disposition, à
l'installation et à la maintenance de logiciel
Partie 4: Guide de gestion du programme de sûreté de fonctionnement
Les annexes A et B de la présente partie de l’ISO 9000 sont données uniquement à titre d’information.
iv
© ISO
Introduction
La présente partie de l’ISO 9000 formule des lignes directrices concernant l'application des exigences de
l'ISO 9001:1994 lorsque la conception, le développement, l'installation et la maintenance du logiciel font partie
intégrante de l'activité d'un fournisseur:
a) dans le cadre d'un contrat commercial passé avec un organisme externe;
b) en vue de lancer un produit sur un marché spécifique;
c) en tant que support des processus métiers de l'entreprise du fournisseur;
d) en vue de produire un logiciel inclus dans un produit matériel.
Elle identifie les points qui doivent être abordés et s'applique indépendamment de la technologie, des modèles de
cycle de vie, des processus de développement, de la séquence des activités ou de la structure organisationnelle du
fournisseur.
Il convient de clairement documenter, au sein du système qualité de l'organisme, les relations entre les éléments
logiciels de ce système qualité et les autres aspects, lorsque le domaine d'application des activités de l'organisme
dépasse celui du développement de logiciels.
La présente partie de l'ISO 9000 formule des lignes directrices concernant l'application de l'ISO 9001:1994.
Lorsque le texte est extrait de l'ISO 9001:1994, celui-ci est encadré pour qu'il puisse être facilement
identifié.
Tout au long de la présente partie de l'ISO 9000, le verbe «devoir» est utilisé pour exprimer une obligation qui lie
une partie contractante à une ou plusieurs autres parties; le futur exprime une déclaration d'intention ou d'objectif
par une partie; l'expression «il convient que» ou «il est recommandé de» exprime une recommandation parmi
d'autres possibilités; le verbe «pouvoir» exprime une liberté d'action dans le cadre de la présente partie de
l'ISO 9000.
v
NORME INTERNATIONALE © ISO ISO 9000-3:1997(F)
Normes pour le management de la qualité et l'assurance de la
qualité —
Partie 3:
Lignes directrices pour l'application de l'ISO 9001:1994 au
développement, à la mise à disposition, à l'installation et à la
maintenance du logiciel
1 Domaine d’application
La présente partie de l’ISO 9000 établit des lignes directrices pour faciliter l'application de l’ISO 9001:1994 dans des
organismes qui développent, mettent à disposition, installent et maintiennent des logiciels. Elle ne modifie ou ne
renforce en rien les exigences de l’ISO 9001.
Elle n'est pas destinée à être utilisée en tant que critère d'évaluation pour la certification du système qualité.
2 Références normatives
Les normes suivantes contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des
dispositions valables pour la présente partie de l’ISO 9000. Au moment de la publication, les éditions indiquées
étaient en vigueur. Toute norme est sujette à révision et les parties prenantes des accords fondés sur la présente
partie de l’ISO 9000 sont invitées à rechercher la possibilité d'appliquer les éditions les plus récentes des normes
indiquées ci-après. Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur
à un moment donné.
ISO 8402:1994, Management de la qualité et assurance de la qualité — Vocabulaire.
ISO 9001:1994, Systèmes qualité — Modèle pour l'assurance de la qualité en conception, développement,
production, installation et prestations associées.
3 Définitions
Pour les besoins de la présente partie de l’ISO 9000, les définitions données dans l’ISO 8402, ainsi que les
définitions suivantes s'appliquent.
3.1
produit
résultat d'activités ou de processus
NOTE 1 Le terme «produit» peut inclure les services, les matériels, les produits issus de processus à caractère continu, les
logiciels, ou une combinaison des deux.
NOTE 2 Un «produit» peut être matériel (par exemple assemblages ou produits issus de processus à caractère continu) ou
immatériel (par exemple, connaissances ou concepts), ou une combinaison des deux.
© ISO
NOTE 3 Dans le cadre de la présente Norme internationale, le terme «produit» s'applique au produit intentionnel et ne
s'applique pas aux sous-produits non intentionnels affectant l'environnement. Ceci diffère de la définition donnée dans
l'ISO 8402.
[ISO 9001]
3.2
offre
offre faite par un fournisseur en réponse à un appel d'offre en vue de l'attribution d'un contrat de fourniture d'un
produit
[ISO 9001]
3.3
contrat
exigences ayant fait l'objet d'un accord entre un fournisseur et un client et transmises par un moyen quelconque
[ISO 9001]
3.4
référentiel de configuration
version formellement approuvée d'un élément de configuration (quel que soit le support) qui est formellement
attribuée et attachée à un instant spécifique du cycle de vie de l'élément de configuration
[ISO/CEI 12207]
3.5
développement
processus du cycle de vie du logiciel qui comprend les activités d'analyse des besoins, de conception, de codage,
d'intégration, d'essai, d'installation et d'assistance en vue de l'acceptation des logiciels
3.6
modèle de cycle de vie
scénario, contenant les processus, les activités et les tâches mis en œuvre pour le développement, l'exploitation et
la maintenance d'un logiciel, englobant la totalité de la vie du système depuis l'expression des besoins jusqu'à la fin
de son exploitation
[ISO/CEI 12207]
3.7
phase
séquence définie d'activités
NOTE Une phase n'implique pas l'utilisation d'un modèle de cycle de vie particulier.
3.8
essai de non régression
essai visant à assurer que les modifications réalisées dans le but de corriger des défauts n'ont pas introduit de
défauts supplémentaires
3.9
reproduction
copie d'un logiciel d'un support vers un autre
© ISO
3.10
logiciel
ensemble des programmes, des procédures et de la documentation et des données éventuellement associées
[ISO/CEI 12207]
NOTE Dans la présente partie de l’ISO 9000, le terme «logiciel» se limite au logiciel informatique.
3.11
produit logiciel
NOTE 1 En français, le terme «logiciel» suffit; il n'est pas nécessaire d'introduire le terme «produit logiciel».
NOTE 2 Un logiciel peut être destiné à être livré; il peut également faire partie intégrante d'un autre produit ou être utilisé au
cours du processus de développement.
3.12
composant du logiciel
toute partie identifiable du logiciel
4 Exigences en matière de système qualité
4.1 Responsabilité de la direction
4.1.1 Politique qualité
La direction du fournisseur, qui a pouvoir de décision doit définir et consigner par écrit sa politique en
matière de qualité, y compris ses objectifs et son engagement en la matière. La politique qualité doit être
pertinente par rapport aux objectifs généraux du fournisseur et aux attentes et besoins de ses clients.
Le fournisseur doit assurer que cette politique est comprise, mise en œuvre et entretenue à tous les
niveaux de l'organisme.
Il n’y a aucune recommandation particulière concernant le logiciel.
4.1.2 Organisation
4.1.2.1 Responsabilité et autorité
La responsabilité, l'autorité et les relations entre les personnes qui dirigent, exécutent et vérifient des
tâches qui ont une incidence sur la qualité doivent être définies par écrit; cela concerne en particulier les
personnes qui ont besoin de la liberté et de l'autorité sur le plan de l'organisation pour
a) déclencher des actions permettant de prévenir l'apparition de toute non-conformité relative au produit,
au processus et au système qualité;
b) identifier et enregistrer tout problème relatif au produit, au processus et au système qualité;
c) déclencher, recommander ou fournir des solutions en suivant des circuits définis;
d) vérifier la mise en œuvre des solutions;
e) maîtriser la poursuite des opérations relatives au produit non conforme, sa livraison ou son installation
jusqu'à ce que la déficience ou la situation non satisfaisante ait été corrigée.
Il n’y a aucune recommandation particulière concernant le logiciel.
© ISO
4.1.2.2 Moyens
Le fournisseur doit identifier les exigences relatives aux moyens et fournir les moyens adéquats, y compris
la désignation de personnes formées (voir 4.18), pour le management, l'exécution et la vérification des
tâches, ainsi que les audits qualité internes.
Il n’y a aucune recommandation particulière concernant le logiciel.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 7.2.
4.1.2.3 Représentant de la direction
La direction du fournisseur, qui a pouvoir de décision, doit nommer un de ses membres qui, nonobstant
d'autres responsabilités, doit avoir une autorité définie pour
a) assurer qu'un système qualité est défini, mis en œuvre et entretenu conformément à la présente
Norme internationale; et
b) rendre compte du fonctionnement du système qualité à la direction du fournisseur pour en faire la
revue et servir de base à l'amélioration du système qualité.
NOTE 5 La responsabilité du représentant de la direction peut également comprendre les relations avec des
parties extérieures en ce qui concerne les sujets relatifs au système qualité du fournisseur.
Il n’y a aucune recommandation particulière concernant le logiciel.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 6.3.1.6.
4.1.3 Revue de direction
La direction du fournisseur, qui a pouvoir de décision, doit faire une revue du système qualité à une
fréquence définie et suffisante pour assurer qu'il demeure constamment approprié et efficace afin de
satisfaire aux exigences de la présente Norme internationale ainsi qu'à la politique et aux objectifs qualité
fixés par le fournisseur (voir 4.1.1). Des enregistrements de ces revues doivent être conservés (voir 4.16).
Il n’y a aucune recommandation particulière concernant le logiciel.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 7.1.4.
4.2 Système qualité
4.2.1 Généralités
Le fournisseur doit établir, consigner par écrit et entretenir un système qualité en tant que moyen pour
assurer que le produit est conforme aux exigences spécifiées. Le fournisseur doit établir un manuel qualité
couvrant les exigences de la présente Norme internationale. Le manuel qualité doit comprendre les
procédures du système qualité ou y faire référence, et exposer la structure de la documentation utilisée
dans le cadre du système qualité.
NOTE 6 L'ISO 10013 fournit des conseils relatifs à l'élaboration des manuels qualité.
Il n’y a aucune recommandation particulière concernant le logiciel.
© ISO
4.2.2 Procédures du système qualité
Le fournisseur doit
a) établir des procédures écrites cohérentes avec les exigences de la présente Norme internationale et
avec la politique qualité qu'il a formulée, et
b) mettre réellement en œuvre le système qualité et ses procédures écrites.
Dans le cadre de la présente Norme internationale, l'étendue et le niveau de détail des procédures qui font
partie du système qualité doivent dépendre de la complexité des tâches, des méthodes utilisées, des
compétences et de la formation nécessaires au personnel impliqué dans l'exécution de ces tâches.
NOTE 7 Les procédures écrites peuvent faire référence à des instructions de travail qui définissent comment une
tâche est réalisée.
Il n’y a aucune recommandation particulière concernant le logiciel.
4.2.3 Planification de la qualité
Le fournisseur doit définir et consigner par écrit comment satisfaire les exigences pour la qualité. La
planification de la qualité doit être cohérente avec l'ensemble des exigences du système qualité du
fournisseur et doit être consignée sous une forme adaptée aux méthodes de travail du fournisseur. Ce
dernier doit porter toute son attention sur les activités suivantes, s'il y a lieu, pour satisfaire aux exigences
spécifiées pour les produits, les projets ou les contrats:
a) l'établissement de plans qualité;
b) l'identification et l'acquisition de tous moyens de maîtrise des activités, processus, équipements (y
compris les équipements de contrôle et d'essai), dispositifs, ensemble des moyens et compétences qui
peuvent être nécessaires pour obtenir la qualité requise;
c) l'assurance de la compatibilité de la conception, du processus de production, de l'installation, des
prestations associées, des procédures de contrôle et d'essai et de la documentation applicable;
d) la mise à jour, autant que nécessaire, des techniques de maîtrise de la qualité, de contrôle et d'essai, y
compris le développement d'une nouvelle instrumentation;
e) l'identification, en temps voulu, de toute exigence en matière de mesurage mettant en jeu une aptitude
qui dépasse les possibilités actuelles de l'état de l'art, afin de développer l'aptitude nécessaire;
f) l'identification des vérifications adéquates aux phases appropriées de la réalisation du produit;
g) la clarification des normes d'acceptation pour toutes les caractéristiques et exigences, y compris celles
qui contiennent un élément subjectif;
h) l'identification et la préparation d'enregistrements relatifs à la qualité (voir 4.16).
NOTE 8 Les plans qualité mentionnés [voir 4.2.3 a)] peuvent faire référence aux procédures écrites appropriées qui
font partie intégrante du système qualité du fournisseur.
Il convient que la planification de la qualité aborde les points suivants, s'il y a lieu:
a) les exigences pour la qualité, exprimées en termes mesurables, lorsque cela est nécessaire;
b) le modèle de cycle de vie à utiliser pour le développement du logiciel;
c) les critères de début et de fin de chaque phase du projet;
d) l'identification des types de revues, de tests, et d'autres activités de vérification et validation à mener;
e) l'identification des procédures de gestion de la configuration à suivre;
© ISO
f) un planning détaillé (comprenant le calendrier, les procédures, les moyens et les approbations) ainsi que les
responsabilités et autorités spécifiques en vue de:
la gestion de la configuration;
la vérification et la validation des produits développés;
la vérification et la validation des produits achetés;
la vérification des produits fournis par le client;
la maîtrise du produit non conforme et des actions correctives;
l'assurance que les activités décrites dans le plan qualité sont réalisées.
Un plan qualité permet d'ajuster l'application d'un système qualité à un projet, à un produit ou à un contrat
spécifique.
Un plan qualité peut inclure ou faire référence à des procédures génériques et/ou à des procédures qui concernent
les contrats, produits ou projets, le cas échéant. Il est recommandé que le plan qualité soit mis à jour au fur et à
mesure de l'avancement du développement et que ce qui concerne chaque phase soit entièrement défini lorsque
celle-ci commence.
Il est recommandé qu'un plan qualité soit revu et accepté par toutes les organisations concernées par sa mise en
œuvre.
Le document qui décrit un plan qualité peut être distinct (intitulé plan qualité), faire partie d'un autre document, ou
être composé de plusieurs documents.
Un plan qualité peut inclure ou faire référence aux plans de tests unitaires, de tests d'intégration, d'essais du
système et d'essais d'acceptation. Des recommandations concernant la planification des tests et essais et
l'environnement de tests sont formulées dans le cadre des contrôles et des essais.
NOTE Des lignes directrices concernant les plans qualité sont données dans l’ISO 10005, et concernant la gestion de la
configuration, dans l’ISO 10007. Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 6.2 à 6.5.
4.3 Revue de contrat
4.3.1 Généralités
Le fournisseur doit établir et tenir à jour des procédures écrites de revue de contrat et de coordination de
ces activités.
Le logiciel peut être développé dans le cadre d'un contrat, en tant que produit destiné à un marché particulier, en
tant que logiciel incorporé à du matériel, ou en tant que support des processus métiers du fournisseur. La revue de
contrat est applicable dans tous ces cas.
© ISO
4.3.2 Revue
Avant soumission d'une offre ou acceptation d'un contrat ou d'une commande (formulation des exigences),
l'offre, le contrat ou la commande doit être revu(e) par le fournisseur afin d'assurer que
a) les exigences sont définies et documentées de façon adéquate; lorsqu'il n'existe pas d'exigences
écrites pour une commande verbale, le fournisseur doit assurer que les exigences de cette commande
ont fait l'objet d'un accord avant d'être acceptées;
b) toute différence entre les exigences d'un contrat ou d'une commande et celles de l'offre a fait l'objet
d'une solution;
c) le fournisseur présente l'aptitude à satisfaire aux exigences du contrat ou de la commande.
Les points suivants peuvent également s'appliquer au cours de la revue par le fournisseur d'offres, de contrats, ou
de commandes relatifs au logiciel.
a) Points concernant le client:
la terminologie à utiliser est acceptée par les parties concernées;
le client a la capacité et les moyens de satisfaire aux obligations contractuelles qui ont été établies;
les critères d'acceptation ou de rejet du produit par le client sont approuvés;
les responsabilités du client dans la fourniture de données et des moyens associés;
la mesure dans laquelle le client s'implique dans le développement et dans la sous-traitance;
les dispositions prises pour les revues conjointes afin de superviser le déroulement du contrat;
la procédure convenue pour gérer l'évolution des exigences client lors du développement et/ou de la
maintenance;
les processus de cycle de vie imposés par le client;
le traitement des problèmes détectés après acceptation, y compris les plaintes du client et les
réclamations;
la responsabilité de la suppression des non-conformités après l'expiration de la garantie;
toute obligation pour le client de passer à une nouvelle version lorsque le fournisseur le décide, ou pour le
fournisseur de maintenir des anciennes versions;
le déploiement du logiciel et la formation correspondante des utilisateurs.
b) Points techniques:
la possibilité de répondre aux exigences;
les normes de développement du logiciel et les procédures à utiliser;
les moyens, les outils, les composants et données du logiciel, à fournir par le client, sont identifiés; les
méthodes sont définies et documentées afin d'évaluer leur pertinence;
le système d'exploitation ou la plate-forme matérielle;
l'accord sur la maîtrise des interfaces avec le logiciel;
les exigences de reproduction et de diffusion.
© ISO
c) Points concernant la direction:
les contingences ou les risques sont identifiés et leurs impacts sur les activités ultérieures sont estimés;
la responsabilité du fournisseur concernant les travaux sous-traités (voir 4.6);
l'échéancier, la planification des revues techniques et des livrables;
les exigences concernant l'installation, la maintenance et le soutien;
la disponibilité, en temps voulu, des moyens techniques, humains et financiers.
d) Points relatifs à la législation, à la sécurité et à la confidentialité:
les informations traitées dans le cadre du contrat peuvent être sujettes aux droits de la propriété
intellectuelle, à des accords de licence, à la confidentialité et à la protection;
la garde de l'original du produit et les droits du client d'y accéder ou de le vérifier;
le niveau d'accès du client aux informations doit faire l'objet d'un accord entre les deux parties;
la définition des conditions de la garantie;
les responsabilités/pénalités associées au contrat.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.2.1, 5.2.6 et 6.4.2.1.
4.3.3 Avenant au contrat
Le fournisseur doit définir comment un avenant à un contrat est traité et comment il le transmet
correctement aux fonctions concernées de son organisation.
Il n’y a aucune recommandation particulière concernant le logiciel.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.1.3.5 et 5.2.3.2.
4.3.4 Enregistrements
Des enregistrements de ces revues de contrat doivent être conservés (voir 4.16).
NOTE 9 Il convient de constituer des circuits de communication et des interfaces avec l’organisation du client en
matière de contrat.
Il n’y a aucune recommandation particulière concernant le logiciel.
4.4 Maîtrise de la conception
4.4.1 Généralités
Le fournisseur doit établir et tenir à jour des procédures écrites pour maîtriser et vérifier la conception du
produit afin d'assurer que les exigences spécifiées sont satisfaites.
Le présent paragraphe donne des lignes directrices sur les activités, incombant au développement, d'analyse des
besoins, de conception de l'architecture, de conception détaillée et de codage. Il contient également des conseils
sur la planification du développement.
Il convient qu'un projet de développement de logiciel soit organisé selon un ou plusieurs modèles de cycle de vie. Il
convient de planifier les processus, les activités et les tâches et de les réaliser en fonction du type de cycle de vie
utilisé. Le modèle de cycle de vie utilisé peut être adapté aux besoins particuliers du projet. La présente partie de
© ISO
l’ISO 9000 est destinée à être appliquée indépendamment du modèle de cycle de vie et n'a pas pour objet
d'indiquer un modèle de cycle de vie particulier.
Un modèle de cycle de vie identifie un ensemble de processus et spécifie quand et comment ces processus
interviennent. L'ordre dans lequel ces processus sont décrits dans la présente partie de l’ISO 9000 ne suggère en
aucun cas l'ordre dans lequel ils doivent être réalisés.
Le processus de développement transforme les besoins en un logiciel. Il convient que ce processus soit réalisé
selon une approche structurée, afin d'empêcher l'introduction d'erreurs. En adoptant cette approche, on évite de
dépendre uniquement des processus de vérification et de validation pour identifier les problèmes. Il convient donc
que le fournisseur établisse et tienne à jour des procédures écrites pour s'assurer que les logiciels sont développés
conformément aux exigences spécifiées et au plan de développement et/ou au plan qualité.
Il convient de prendre en compte les aspects suivants, inhérents aux activités de conception:
a) Méthode de conception: il convient d'utiliser une méthode de conception de manière systématique. Il est
recommandé de veiller à ce que la méthode soit bien adaptée au type de tâche, de produit ou de projet et à ce
que l'application, les méthodes et les outils utilisés soient compatibles.
b) Retour d'expérience: il convient que le fournisseur évite la répétition des problèmes analogues, en tirant parti
des expériences antérieures, de l'analyse des indicateurs et des revues de fin de projet.
c) Processus ultérieurs: il convient, dans la mesure du possible, de concevoir le logiciel pour faciliter les essais,
l'installation, la maintenance et l'utilisation.
d) Sûreté et sécurité: il convient de porter une attention particulière à la conception en vue de la testabilité et de la
validation. En ce qui concerne les produits dont la défaillance est susceptible de porter atteinte à l'homme, au
matériel ou à l'environnement, il convient que la conception garantisse l'élaboration d'exigences spécifiques de
conception précisant, en fonction des conditions potentielles de défaillance, la protection attendue ainsi qu'un
système de parade adaptée.
Concernant le codage, il convient de spécifier et d'observer des règles d'utilisation de langages de programmation,
des règles cohérentes de nommage, de codage et des règles de commentaires adéquats. Il convient de
documenter et de maîtriser ces règles.
Le fournisseur peut utiliser des outils, des moyens et des techniques pour rendre opérationnelles les lignes
directrices de système qualité mentionnées dans la présente partie de l’ISO 9000. Ces outils, moyens et techniques
peuvent se révéler efficaces dans une optique de management aussi bien que pour le développement de produits
et/ou de prestations associées. Lorsque ces outils et techniques sont élaborés en interne ou achetés, il convient
que le fournisseur évalue leur adéquation à l'objet auquel ils sont destinés. Il convient que les outils utilisés lors de
la mise en œuvre du produit ainsi que les outils d'analyse et de conception, les compilateurs et assembleurs, soient
approuvés et pris en charge au niveau approprié par la gestion de la configuration avant d'être utilisés. Il convient
de documenter le domaine d'utilisation de ces outils et techniques et de procéder à la revue de leur utilisation, selon
le cas, pour déterminer s'il est nécessaire de les améliorer et/ou de procéder à leur mise à jour.
Il se peut que le personnel ait besoin d'être formé à l'utilisation de ces techniques et outils, en début d'utilisation ou
après toute amélioration/mise à jour.
4.4.2 Planification de la conception et du développement
Le fournisseur doit élaborer des plans pour chaque activité de conception et de développement. Ces plans
décrivent ces activités ou y font référence, et définissent les responsabilités pour leur mise en œuvre. Les
activités de conception et de développement doivent être affectées à du personnel qualifié doté de moyens
adéquats. Les plans doivent être mis à jour au fur et à mesure de l'évolution de la conception.
Pour les logiciels, il convient que la «planification du développement» détermine les activités d'analyse des besoins,
de conception, de codage, d'intégration, de test, d'installation et d'assistance à l'acceptation des logiciels. Il convient
de documenter la planification du développement dans un plan de développement.
© ISO
Il est recommandé qu'un plan de développement soit revu et approuvé. Un plan de développement peut également
être appelé «plan de développement logiciel» ou «plan de projet logiciel».
Un plan de développement peut définir la façon dont le projet doit être géré, les revues d'avancement requises ainsi
que le type et la fréquence des comptes rendus à la direction, au client et à d'autres parties intéressées, en prenant
en compte, s'il y a lieu, les exigences contractuelles.
Il convient que la planification du développement aborde les points suivants, lorsque cela est approprié:
a) la définition du projet, avec un rappel de ses objectifs et une référence à tout projet associé du client ou du
fournisseur;
b) la définition des données d'entrée et de sortie du projet pris dans son ensemble;
c) l'organisation des ressources du projet, comprenant la structure de l'équipe, les responsabilités, les sous-
contractants et les moyens matériels;
d) les interfaces organisationnelles et techniques entre les différents individus ou groupes, telles que
les équipes de sous-projets,
les sous-contractants,
les utilisateurs,
les représentants du client,
les représentants de l'assurance de la qualité;
e) l'identification, ou la référence qui en est faite,
des activités de développement à réaliser,
des données d'entrée de chaque activité,
des données de sortie de chaque activité,
des activités de management et de soutien qui sont à réaliser;
f) l'analyse des risques, des hypothèses, des dépendances et des problèmes potentiels liés au développement;
g) le calendrier identifiant
les phases du projet,
les travaux à réaliser (les données d'entrée, de sortie et la définition de chaque tâche),
les ressources associées,
les interdépendances,
les points clés;
© ISO
h) l'identification
de normes, règles, pratiques et conventions,
d'outils et techniques nécessaires au développement, y compris la qualification et la maîtrise de la
configuration de ces outils et techniques,
de pratiques de gestion de la configuration,
de méthodes de maîtrise des produits non conformes,
de méthodes de maîtrise des logiciels non livrables utilisés comme support au développement,
de procédures d'archivage, de secours et de reprise, y compris la planification des parades,
de méthodes de maîtrise en vue de la protection contre les virus;
i) l'identification de plans associés (y compris les plans concernant le système) tels que
le plan qualité,
le plan de maîtrise des risques,
le plan de gestion de la configuration,
le plan d'intégration,
le plan de tests,
le plan d'installation,
le plan de migration,
le plan de formation,
le plan de maintenance,
le plan de réutilisation.
Le plan de développement et tout autre plan associé peuvent être des documents distincts, faire partie d'un autre
document ou être composés de plusieurs documents.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphe 5.2.4.
4.4.3 Interfaces organisationnelles et techniques
Les interfaces organisationnelles et techniques entre les différents groupes, qui contribuent au processus
de conception, doivent être définies et les informations nécessaires doivent être consignées par écrit,
transmises et revues régulièrement.
Il convient de définir clairement, dans les plans de développement des fournisseurs et des sous-contractants, la
limite des responsabilités pour chaque partie du logiciel et la manière dont les informations techniques seront
échangées entre les différents acteurs. Le fournisseur peut exiger que le sous-contractant lui remette un plan de
développement, pour revue.
Lors de la définition des interfaces, il convient de veiller à prendre en compte certaines parties intéressées, autres
que le client et le fournisseur, qui ont besoin de participer à l'installation, à la maintenance et aux activités de
formation. Il peut s'agir de sous-contractants, d'autorités réglementaires, de personnel des projets de
© ISO
développement associés et du support technique. Il se peut que les utilisateurs finaux et les exploitants aient
particulièrement besoin d'être impliqués pour assurer que les aptitudes et la formation sont adéquates et qu'elles
permettent d'atteindre les niveaux de service auxquels l'organisme s'est engagée.
Il se peut que le client se voie assigner certaines responsabilités dans le cadre du contrat. La nécessité pour le
client de coopérer avec le fournisseur, afin de fournir à temps l'ensemble des informations nécessaires et de
résoudre certains points, est un élément important. S'il convient de nommer un représentant du client, celui-ci peut
représenter l'utilisateur final du produit, tout comme la direction, et avoir l'autorité nécessaire pour traiter les
questions contractuelles qui comprennent, mais ne se limitent pas aux actions suivantes:
a) faire part au fournisseur des exigences du client;
b) répondre aux questions du fournisseur;
c) approuver les propositions du fournisseur;
d) conclure des accords avec le fournisseur;
e) s'assurer que l'organisme auquel appartient le client respecte les accords passés avec le fournisseur;
f) définir les critères et les procédures d'acceptation;
g) traiter les composants de logiciel, les données, les moyens et les outils fournis par le client, mais inaptes à
l'utilisation;
h) définir la responsabilité du client.
Les revues conjointes du fournisseur et du client, peuvent, lorsqu'elles font l'objet d'un accord réciproque, être
planifiées à intervalles réguliers ou lors d'événements clés du projet, pour traiter les aspects suivants, selon les
besoins:
a) l'avancement des travaux de développement du logiciel entrepris par le fournisseur;
b) l'avancement des activités entreprises par le client, comme convenu;
c) la conformité des produits à la spécification des besoins du client;
d) l'avancement des activités concernant les utilisateurs finals du système, telles que la migration et la formation;
e) les résultats de vérification;
f) les résultats des essais d'acceptation.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.2.6.1 et 6.6.2.
4.4.4 Données d'entrée de la conception
Les exigences concernant le produit relatives aux données d'entrée de la conception et comprenant les
exigences légales et réglementaires applicables doivent être identifiées et consignées par écrit, et leur
sélection doit être revue par le fournisseur quant à leur adéquation. Il faut apporter une solution aux
exigences incomplètes, ambiguës ou incompatibles avec ceux qui les ont imposées.
Les données d'entrée de la conception doivent prendre en compte les résultats de toutes les activités de
revue de contrat.
Il convient que la spécification des besoins provienne du client. Cependant, le fournisseur peut, en cas d'accord
réciproque, fournir ces spécifications. Dans ce cas, lorsque cela est nécessaire, il convient que le fournisseur:
© ISO
a) formalise des procédures pour l'élaboration de la spécification des besoins, incluant
des méthodes permettant de se mettre d'accord sur des exigences et d'autoriser les modifications,
essentiellement au cours du développement itératif,
des méthodes permettant d'évaluer les prototypes ou les simulations, le cas échéant,
l'enregistrement et la revue des résultats issus des discussions, pour chaque partie;
b) élabore la spécification des besoins en étroite collaboration avec le client et fasse des efforts pour éviter tout
malentendu en donnant par exemple la définition des termes et en expliquant le contexte conduisant aux
besoins;
c) obtienne l'approbation du client sur la spécification des besoins.
Entretiens, enquêtes, études, prototypes, simulations et méthodes d'analyse peuvent être utilisés, s'il y a lieu, dans
le but d'élaborer la spécification des besoins.
La spécification des besoins peut être élaborée et faire l'objet d'un accord sous forme de spécification de système.
Dans ce cas, il convient que les procédures soient mises en place pour assurer l'attribution adéquate des
exigences de système aux aspects matériels et logiciels ainsi que les spécifications appropriées des interfaces.
La spécification des besoins peut ne pas être complète au moment de l'acceptation du contrat: elle peut être
développée au cours d'un projet. Le contrat peut comprendre un avenant lorsque la spécification des besoins
évolue. Il convient alors d'en maîtriser les modifications.
Il est recommandé que les exigences comprennent tous les aspects nécessaires à la satisfaction des besoins du
client. Il se peut que la spécification des besoins doive prendre en compte l'environnement d'exploitation. Les
exigences peuvent comprendre, mais ne sont pas limitées à, la capacité fonctionnelle, la fiabilité, la facilité
d'utilisation, le rendement, la maintenabilité et la portabilité (voir l’ISO/CEI 9126). Des sous-caractéristiques peuvent
être spécifiées, par exemple en matière de sécurité. Les questions relatives à la sécurité des personnes ainsi que
les obligations réglementaires peuvent également être spécifiées.
Si le logiciel doit comporter des interfaces avec d'autres logiciels ou matériels, il convient de spécifier autant que
possible ces interfaces entre le logiciel à développer et les autres logiciels ou matériels, soit de manière directe, soit
par référence dans la spécification des besoins.
Il convient d'exprimer les besoins dans des termes qui permettent la validation au cours de l'acceptation du produit.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.2 à 5.3.4.
4.4.5 Données de sortie de la conception
Les données de sortie de la conception doivent être consignées par écrit et exprimées de façon à pouvoir
être vérifiées et validées par rapport aux données d'entrée de la conception.
Les données de sortie de la conception doivent
a) satisfaire aux exigences des données d'entrée de la conception;
b) contenir ou faire référence à des critères d'acceptation;
c) identifier les caractéristiques de conception critiques pour le fonctionnement correct et en toute
sécurité du produit (par exemple, les exigences en matière d'exploitation, stockage, manutention,
maintenance et mise hors service).
Les documents relatifs aux données de sortie de la conception doivent être revus avant leur mise en
circulation.
Il y a lieu de définir et de documenter les données de sortie requises pour chaque activité de conception,
conformément à la méthode choisie. Il est recommandé que cette documentation soit correcte, complète et
cohérente par rapport aux exigences. Les données de sortie de la conception peuvent inclure:
© ISO
la spécification de la conception de l'architecture;
la spécification de la conception détaillée;
le code source;
les manuels d’utilisation.
NOTE Pour de plus amples informations, voir l’ISO/CEI 12207:1995, paragraphes 5.3.5 à 5.3.7.
4.4.6 Revue de conception
Des revues formelles et consignées par écrit des résultats de la conception doivent être planifiées et
conduites à des phases appropriées de la conception. Les participants à chacune de ces revues doivent
comprendre des représentants de toutes les fonctions concernées par la phase de conception, objet de la
revue, ainsi que tout autre expert, comme requis. Des enregistrements de ces revues doivent être
conse
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...