EN 29000-3:1993
(Main)Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software (ISO 9000-3:1991)
Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software (ISO 9000-3:1991)
Qualitätsmanagement- und Qualitätssicherungsnormen - Teil 3: Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software (ISO 9000-3:1991)
Normes pour la gestion de la qualité et l'assurance de la qualité - Partie 3: Lignes directrices pour l'application de l'ISO 9001 au développement, à la mise à disposition et à la maintenance du logiciel (ISO 9000-3:1991)
Standardi za vodenje in zagotavljanje kakovosti - 3. del: Smernice za uporabo standarda ISO 9001 pri razvoju, nabavi in vzdrževanju programske opreme (ISO 9000-3:1991)
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Standardi za vodenje in zagotavljanje kakovosti - 3. del: Smernice za uporabo standarda ISO 9001 pri razvoju, nabavi in vzdrževanju programske opreme (ISO 9000-3:1991)Qualitätsmanagement- und Qualitätssicherungsnormen - Teil 3: Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software (ISO 9000-3:1991)Normes pour la gestion de la qualité et l'assurance de la qualité - Partie 3: Lignes directrices pour l'application de l'ISO 9001 au développement, a la mise a disposition et a la maintenance du logiciel (ISO 9000-3:1991)Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001 to the development, supply and maintenance of software (ISO 9000-3:1991)35.080Dokumentiranje razvoja programske opreme in sistemov (sistemska dokumentacija)Software development and system documentation03.120.10Vodenje in zagotavljanje kakovostiQuality management and quality assuranceICS:Ta slovenski standard je istoveten z:EN 29000-3:1993SIST EN 29000-3:1997en01-december-1997SIST EN 29000-3:1997SLOVENSKI
STANDARDSIST ISO 9000-3:19961DGRPHãþD
SIST EN 29000-3:1997
SIST EN 29000-3:1997
SIST EN 29000-3:1997
SIST EN 29000-3:1997
SIST EN 29000-3:1997
I N T ER NAT I O NA L STANDARD IS0 9000-3 First edition 1991 46-01 Corrected and reprinted 1993-05-01 Quality management and quality assurance standards - Part 3: Guidelines for the application of IS0 9001 to the development, supply and maintenance of software Normes pour la gestion de la qualité et l'assurance de la qualité - Partie 3: Lignes directrices pour l'application de I'ISO 9001 au développement, à la mise à disposition et à la maintenance du logiciel Reference number IS0 9000-3:1991 (E) SIST EN 29000-3:1997
IS0 9000-3:1991(E) . Contents Page 1 Scope . 1 2 Normative references . 1 3 Definitions . 1 4 Quality system - Framework . 2 4.1 Management responsibility . 2 4.2 Quality system . 3 4.3 Internal quality system audits . 3 4.4 Corrective action . 3 5 Quality system - Life-cycle activities . 3 5.1 General . 3 5.2 Contract review . 4 5.3 Purchaser's requirements specification . 4 5.5 Quality planning . 6 5.6 Design and implementation . 6 5.4 Development planning . 4 5.7 Testing and validation . 7 5.8 Acceptance . 7 5.9 Replication. delivery and installation . 8 5.10 Maintenance . 8 6 Quality system - Supporting activities (not phase dependent) 9 6.1 Configuration management . 9 6.2 Document control . 10 6.3 Quality records . 11 6.4 Measurement . 11 6.5 Rules. practices and conventions . 12 (O IS0 1991 All rights reserved . 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 per- mission in writing from the publisher . International Organization for Standardization Case Postale 56 CH-1211 Genève 20 Switzerland Printed in Switzerland ii SIST EN 29000-3:1997
IS0 9000-3:1991(E) 6.6 Tools and techniques . 12 6.7 Purchasing . 12 6.8 Included software product . 12 6.9 Training . 12 Annexes A Cross-reference between IS0 9000-3 and IS0 9001 . 14 B Cross-reference between IS0 9001 and IS0 9000-3 ., 15 . 111 SIST EN 29000-3:1997
IS0 9000-3:1991(E) Foreword IS0 (the International Organization for Standardization) is a worldwide federation of national standards bodies (IS0 member bodies). The work of preparing International Standards is normally carried out through IS0 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. IS0 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 IS0 9000-3 was prepared by Technical Committee ISO/TC 176, Quality management and quality assurance. IS0 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 IS0 9001, IS0 9002 and IS0 9003 - Part3: Guidelines for the application of IS0 9001 to the develop- ment, supply and maintenance of software Part 1 will be a revision of IS0 9000:1987. Part 2 is to be published. Annexes A and B of this part of IS0 9000 are for information only. IV SIST EN 29000-3:1997
IS0 9000-3:1991 (E) Introduction With the progress of information technology, the amount of software products has been increasing and the quality management of software products is essential. One of the means of establishing a quality manage- ment system is to provide guidance for software quality assurance. The requirements for a generic quality system for two-party contractual situations have already been published: IS0 9001 :I 987, Quality systems - Model for quality assurance in design/development, production, instal- lation and servicing. However, the process of development and maintenance of software is different from that of most other types of industrial products. In such a rapidly evolving technology field it is therefore necessary to provide ad- ditional guidance for quality systems where software products are in- volved, taking into account the present status of this technology. The nature of software development is such that some activities are re- lated to particular phases of the development process, while others may apply throughout the process. These guidelines have therefore been structured to reflect these differences. This document thus does not cor- respond directly in format with IS0 9001 and cross-reference indexes (annex A and annex B) are provided to give assistance when referring to that standard. Contracts between two parties for software product development may occur in many variations. In certain cases of two-party contracts, these guidelines might not be applicable even if "tailored". It is therefore im- portant to determine the adequacy of the application of this part of IS0 9000 to the contract. This part of IS0 9000 deals primarily with situations where specific soft- ware is developed as part of a contract according to purchaser's specifi- cations. However, the concepts described may be equally of value in other situations. NOTES 1 In English, use of the masculine gender in this part of IS0 9000 is not meant to exclude the feminine gender where applied to persons. Similarly, use of the singular does not exclude the plural (and vice versa) when the sense allows. 2 Throughout this part of IS0 9000 where there is no further guidance, the text of the relevant IS0 9001 clause is given and printed in italics. 3 In this part of IS0 9000 there are a number of lists; none of these is presumed to be exhaustive -they are intended as examples. SIST EN 29000-3:1997
SIST EN 29000-3:1997
INTERNATIONAL STANDARD IS0 9000-3:1991(E) Quality management and quality assurance standards - Part 3: Guidelines for the application of IS0 9001 to the deve lop m en t , s U pp I y a n d ma i n t e na n ce of sof twa re 1 Scope This part of IS0 9000 sets out guidelines to facilitate the application of IS0 9001 to organizations develop- ing, supplying and maintaining software. It is intended to provide guidance where a contract between two parties requires the demonstration of a supplier's capability to develop, supply and maintain software products. The guidelines in this part of IS0 9000 are intended to describe the suggested controls and methods for producing software which meet a purchaser's re- quirements. This is done primarily by preventing non- conformity at all stages from development through to maintenance. The guidelines in this part of IS0 9000 are applicable in contractual situations for software products when a) the contract specifically requires design effort and the product requirements are stated principally in performance terms, or they need to be estab- lished; b) confidence in the product can be attained by the adequate demonstration of a certain supplier's ca- pabilities in development, supply and mainten- ance. 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this part of IS0 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 IS0 9000 are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and IS0 maintain registers of currently valid International Standards. IS0 2382-1 : 1984, Data processing - Vocabulary - Part 01: Fundamental terms. IS0 8402: 1 986, Quality - Vocabulary. IS0 9001 :I 987, Quality systems - Model for quality assurance in design/development, production, instal- lation and servicing. IS0 1 O01 1-1 : 1 990, Guidelines for auditing quality systems - Part 1: Auditing. 3 Definitions For the purposes of this part of IS0 9000, the defi- nitions given in IS0 2382-1 and IS0 8402 apply, to- gether with the following definitions. 3.1 software: Intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a data processing system. [IS0 2382-1 :I 984, 01.04.041 NOTE 4 Software is independent of the medium on which it is recorded. 3.2 software product: Complete set of computer programs, procedures and associated documentation and data designated for delivery to a user. 1 SIST EN 29000-3:1997
IS0 9000-3:1991 (E) 3.3 software item: Any identifiable part of a soft- ware product at an intermediate step or at the final step of development. 3.4 development All activities to be carried out to create a software product. 3.5 phase: Defined segment of work. NOTE 5 A phase does not imply the use of any specific life-cycle model, nor does it imply a period of time in the development of a software product. 3.6 verification (for software): The process of evaluating the products of a given phase to ensure correctness and consistency with respect to the products and standards provided as input to that phase. 3.7 validation (for software): The process of evalu- ating software to ensure compliance with specified requirements. 4 Quality system - Framework 4.1 Management responsibility 4.1.1 Supplier's management responsibility 4.1.1.1 Quality policy The supplier's management shall define and docu- ment its policy and objectives for, and commitment to, quality. The supplier shall ensure that this policy is understood, implemented and maintained at all levels in the organization. [IS0 9001:1987, 4.1.13 4.1.1.2 Organization 4.1.1.2.1 Responsibility and authority The responsibility, authority and the interrelation of all personnel who manage, perform and verify work af- fecting quality shall be defined; particularly for per- sonnel who need the organizational freedom and authority to a) initiate action to prevent the occurrence of product nonconformity; b) identify and record any product quality problems; 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. [IS0 9001 :I 987, 4.1 -2.11 4.1.1.2.2 Verification resources and personnel The supplier shall identify in-house verification re- quirements, provide adequate resources and assign trained personnel for verification activities. Verification activities shall include inspection, test and monitoring of the design, production, installation and servicing processes and/or product; design reviews and audits of the quality system, processes and/or product shall be carried out by personnel independent of those having direct responsibility for the work being performed. [IS0 9001:1987, 4.1.2.21 C' 4.1.1.2.3 Management representative The supplier shall appoint a management represen- tative who, irrespective of other responsibilities, shall have defined authority and responsibility for ensuring that the requirements of [IS0 90011 are implemented and maintained. [IS0 9001 :I 987, 4.1.2.31 4.1.1.3 Management review The quality system adopted to satisfy the require- ments of [IS0 90011 shall be reviewed at appropriate intervals by the supplier's management to ensure its continuing suitability and effectiveness. Records of such reviews shall be maintained. NOTE - Management reviews normally include as- sessment of the results of internal quality system au-t dits, but are carried out by, or on behalf of, the supplier's management viz management personnel having direct responsibility for the system. [IS0 9001 :I 987, 4.1.33 4.1.2 Purchaser's management responsibility The purchaser should cooperate with the supplier to provide all necessary information in a timely manner and resolve pending items. The purchaser should assign a representative with the responsibility for dealing with the supplier on con- tractual matters. This representative should have the authority commensurate with the need to deal with contractual matters which include, but are not limited to, the following: a) defining the purchaser's requirements to the sup- plier; 2 SIST EN 29000-3:1997
IS0 9000-3:1991 (E) b) answering questions from the supplier; c) approving the supplier's proposals; d) concluding agreements with the supplier; e) ensuring the purchaser's organization observes the agreements made with the supplier; f) defining acceptance criteria and procedures; g) dealing with the purchaser-supplied software items that are found unsuitable for use. 4.1.3 Joint reviews Regular joint reviews involving the supplier and pur- chaser should be scheduled to cover the following aspects, as appropriate: a) conformance of the software to the purchaser's agreed requirements specification; b) verification results; c) acceptance test results; The results of such reviews should be agreed and documented. 4.2 Quality system 4.2.1 General The supplier should establish and maintain a docu- mented quality system. The quality system should be an integrated process throughout the entire life cycle, thus ensuring that quality is being built in as develop- ment progresses, rather than being discovered at the end of the process. Problem prevention should be emphasized rather than depending on correction after occurrence. The supplier should ensure the effective implemen- tation of the documented quality system. ( 4.2.2 Quality system documentation All the quality system elements, requirements and provisions should be clearly documented in a sys- tematic and orderly manner. 4.3 Internal quality system audits Internal quality audits The supplier shall carry out a comprehensive system of planned and documented internal quality [system] audits to verify whether quality activities comply with planned arrangements and to determine the effec- tiveness of the quality system. Audits shall be scheduled on the basis of the status and importance of the activity. The audits and follow-up actions shall be carried out in accordance with documented procedures. The results of the audits shall be documented and brought to the attention of the personnel having re- sponsibility in the area audited. The management personnel responsible for the area shall take timely corrective action on the deficiencies found by the au- dit. [IS0 9001:1987, 4.171 See IS0 1 O01 1-1. 4.4 Corrective action The supplier shall establish, document and maintain procedures for a) investigating the cause of nonconforming product and the corrective action needed to prevent re- currence; b) analysing all processes, work operations, conces- sions, quality records, service reports and cus- tomer complaints to detect and eliminate potential causes of nonconforming product; c) initiating preventive actions to deal with problems to a level corresponding to the risks encountered; d) applying controls to ensure that corrective actions are taken and that they are effective; e) implementing and recording changes in pro- cedures resulting from corrective action. [IS0 9001:1987, 4.141 5 Quality system - Life-cycle activities 4.2.3 Quality plan 5.1 General The supplier should prepare and document a quality plan to implement quality activities for each software development on the basis of the quality system, and ensure that it is understood and observed by the or- ganizations concerned. A software development project should be organized according to a life-cycle model. Quality-related activ- ities should be planned and implemented with respect to the nature of the life-cycle model used. 3 SIST EN 29000-3:1997
IS0 9000-3:1991 (E) This part of IS0 9000 is intended for application ir- respective of the life-cycle model used. Should any description, guidance, requirement or structure be read differently, this is unintended and should not be read as indicating that the requirement or guidance is restricted to a specific life-cycle model only. 5.2 Contract review 5.2.1 General The supplier should establish and maintain procedures for contract review and for the coordination of these activities. Each contract should be reviewed by the supplier to ensure that a) the scope of the contract and requirements are defined and documented; b) possible contingencies or risks are identified; c) proprietary information is adequately protected; d) any requirements differing from those in the tender are resolved; e) the supplier has the capability to meet contractual requirements; f) the supplier's responsibility with regard to sub- contracted work is defined; g) the terminology is agreed by both parties; h) the purchaser has the capability to meet contrac- Records of such contract reviews should be main- tained. tual obligations. 5.2.2 Contract items on quality Among others, the following items are frequently found to be relevant in the contract: a) acceptance criteria; b) handling of the changes in purchaser's require- ments during the development; c) handling of problems detected after acceptance, including quality-related claims and purchaser complaints; d) activities carried out by the purchaser, especially the purchaser's role in requirements specification, installation and acceptance; e) facilities, tools and software items to be provided by the purchaser; f) standards and procedures to be used: g) replication requirements (see 5.9). 5.3 Purchaser's requirements specification 5.3.1 General In order to proceed with software development, the supplier should have a complete, unambiguous set of functional requirements. In addition, these require- ments should include all aspects necessary to satisfy the purchaser's need. These may include, but are not limited to, the following: performance, safety, reliabil- ity, security and privacy. These requirements should be stated precisely enough so as to allow validation during product acceptance. The purchaser's requirements specification records I these requirements. In some cases, this document is provided by the purchaser. If not, the supplier should develop these requirements in close cooperation with the purchaser, and the supplier should obtain the purchaser's approval before entering the development stage. The purchaser's requirements specification should be subject to documentation control and con- figuration management as part of the development documentation. All interfaces between the software product and other software or hardware products should be fully speci- fied, either directly or by reference, in the purchaser's requirements specification. 5.3.2 Mutual cooperation During the development of the purchaser's require- ments specification, attention to the following issues is recommended: a) assignment of persons (on both sides) responsible for establishing the purchaser's requirements specification; b) methods for agreeing on requirements and ap- proving changes; c) efforts to prevent misunderstandings such as definition of terms, explanations of background of requirements: (' d) recording and reviewing discussion results on both sides. 5.4 Development planning 5.4.1 General The development plan should cover the following: 4 SIST EN 29000-3:1997
IS0 9000-3:1991(E) a) the definition of the project, including a statement of its objectives and with reference to related purchaser or supplier projects; b) the organization of the project resources, including the team structure, responsibilities, use of sub- contractors and material resources to be used; c) development phases (as defined in 5.4.2.1); d) the project schedule identifying the tasks to be performed, the resources and time required for each and any interrelationships between tasks; e) identification of related plans, such as - quality plan, - configuration management plan, I - integration plan, - test plan. The development plan should be updated as devel- opment progresses and each phase should be defined as in 5.4.2.1 before activities in that phase are started. It should be reviewed and approved before execution. 5.4.2 Development plan 5.4.2.1 Phases The development plan should define a disciplined process or methodology for transforming the pur- chaser's requirements specification into a software product. This may involve dividing the work into phases, and the identification of l a) development phases to be carried out; b) required inputs for each phase; c) required outputs from each phase; d) verification procedures to be carried out at each phase; e) analysis of the potential problems associated with the development phases and with the achievment of the specified requirements. 5.4.2.2 Management The development plan should define how the project is to be managed, including the identification of a) schedule of development, implementation and as- sociated deliveries; b) progress control; c) organizational responsibilities, resources and work assignment; d) organizational and technical interfaces between different groups. 5.4.2.3 Development methods and tools The development plan should identify methods for ensuring that all activities are carried out correctly. This may include a) rules, practices and conventions for development; b) tools and techniques for development; c) configuration management. 5.4.3 Progress control Progress reviews should be planned, held and docu- mented to ensure that outstanding resource issues are resolved and to ensure effective execution of de- velopment plans. 5.4.4 Input to development phases The required input to each development phase should be defined and documented. Each requirement should be defined so that its achievement can be verified. Incomplete, ambiguous or conflicting re- quirements should be resolved with those responsible for drawing up the requirements. 5.4.5 Output from development phases The required output from each development phase should be defined and documented. The output from each development phase should be verified and should a) meet the relevant requirements; b) contain or reference acceptance criteria for for- warding to subsequent phases; c) conform to appropriate development practices and conventions, whether or not these have been stated in the input information; d) identify those characteristics of the product that are crucial to its safe and proper functioning; e) conform to applicable regulatory requirements. 5.4.6 Verification of each phase The supplier should draw up a plan for verification of all development phase outputs at the end of each phase. SIST EN 29000-3:1997
IS0 9000-3:1991(E) Development verification should establish that devel- opment phase outputs meet the corresponding input requirements by means of development control measures such as a) holding development reviews at appropriate points in the development phases; b) comparing a new design with a proven similar de- sign, if available; c) undertaking tests and demonstrations. The verification results and any further actions re- quired to ensure that the specified requirements are met should be recorded and checked when the ac- tions are completed. Only verified development out- puts should be submitted to configuration management and accepted for subsequent use. 5.5 Quality planning 5.5.1 General As part of the development planning, the supplier should prepare a quality plan. The 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. The quality plan should be formally reviewed and agreed by all organizations concerned in its im- plementation. The document that describes the quality plan (see 5.5.2) may be an independent document (entitled quality plan) or a part of another document, or com- posed of several documents including the develop- ment plan. 5.5.2 Quality plan content The, quality plan should specify or reference the fol- lowing items: a) quality objectives, expressed in measurable terms whenever possible; b) defined input and output criteria for each develop- ment phase; c) identification of types of test, verification and vali- dation activities to be carried out; d) detailed planning of test, verification and validation activities to be carried out, including schedules, resources and approval authorities; e) specific responsibilities for quality activities such as - reviews and tests, - configuration management and change control, - defect control and corrective action. 5.6 Design and implementation 5.6.1 General The design and implementation activities are those which transform the purchaser's requirements speci- fication into a software product. Because of the com- plexity of software products, it is imperative that these activities be carried out in a disciplined manner, in order to produce a product according to specifi- cation rather than depending on the test and validation activities for assurance of quality. NOTE 6 The level of information disclosure to be pro- vided to the purchaser needs to be mutually agreed to by the parties, as design and implementation processes are frequently proprietary to the supplier. 5.6.2 Design In addition to the requirements common to all the development phases, the following aspects inherent to the design activities should be taken into account. a) Identification of design considerations: in addition to the input and output specifications, aspects such as design rules and internal interface defi- nitions should be examined. b) Design methodology: a systematic design meth- odology appropriate to the type of software prod- uct being developed should be used. c) Use of past design experiences: utilizing lessons learned from past design experiences, the supplier ( , should avoid recurrences of the same or similar problems. d) Subsequent processes: the product should be de- signed to the extent practical to facilitate testing, maintenance and use. 5.6.3 Implementation In addition to the requirements common to all the development activities, the following aspects should be considered in each implementation activity. a) Rules: rules such as programming rules, program- ming languages, consistent naming conventions, coding and adequate commentary rules should be specified and observed. b) Implementation methodologies: the supplier should use appropriate implementation methods and tools to satisfy purchaser requirements. 6 SIST EN 29000-3:1997
IS0 9000-3:1991(E) 5.6.4 Reviews The supplier should carry out reviews to ensure that the requirements are met and the above methods are correctly carried out. The design or implementation process should not proceed until the consequences of all known deficiencies are satisfactorily resolved or the risk of proceeding otherwise is known. Records of such revi
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.