1、AECMA Technical Report Rapport Technique AECMA AECMA Fachbericht TR 9109 Edition 1 March 2003 PUBLISHED BY THE EUROPEAN ASSOCIATION OF AEROSPACE INDUSTRIES - STANDARDIZATION klk - type 2, a Technical Committee has collected data of a different kind from that which is normally published as a European
2、 Standard. The Quality Domain decided to publish this document in the form of a Technical Report of type 1 in order to facilitate the updating of this document. Page 3 TR 9109: 03-03 Contents Page Foreword 1 1 .I 1.2 1.3 1.4 2 2.1 2.2 2.3 3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 4 4
3、.1 4.2 5 5.1 5 6 6 6 6 6 7 7 7 7 8 8 8 8 8 8 8 9 9 10 10 10 10 10 11 5.2 5.3 5.4 5.5 5.6 5.7 6 6.1 6.2 6.2.1 6.2.2 6.3 6.4 I nt roduct ion Purpose Model and structure of the document Handling of different standards Tailoring approach Scope Types of related systems covered by this guide are Types of
4、acquisition covered by this guide System aspects relating to software development and maintenance Referen ces General Informative references AECMA ECSS I EEE/EI A ISO/IEC JTCl/SC7 “Information Technology - Software Engineering” IS0 / TC 176 “Quality management and Quality assurance” NATO AU250 “Grou
5、p of National Directors for Quality Assurance” Miscellaneous Definitions and acronyms Definitions Acronyms Management responsibility Relationship between the size of the quality management group and the project organisations Integration of the quality management personnel into the project teams Diff
6、erences between manufacturing and software development organisations and their influence on the structure of the quality organisation Interfaces between the quality organisation and the configuration management and the Qualification and Certification organisations Training Risk management Software m
7、etrication RTCA SC-167 / EUROCAE WG-12 11 11 12 12 12 12 12 Resource management 13 Provision of resources 13 Human resources 13 General 13 Competence, awareness and training 13 Infrastructure 13 Work environment 14 Page 4 TR 9109: 03-03 7 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.3 7.3.1 7.3.1 8
8、 8.1 8.1 .I 8.1.2 8.2 8.2.1 8.2.2 8.3 8.3.1 8.3.2 8.3.3 8.4 8.4.1 8.4.2 8.5 9 9.1 9.2 10 10.1 10.2 10.3 11 11.1 11.2 11.3 12 12.1 12.2 12.3 12.4 12.5 Tables Product real isat ion General considerations Mapping onto IS0 12207 clauses Planning of realisation process Customer related processes Design a
9、nd development Purchasing Production and service operations Control of measuring and monitoring devices Aerospace requirements Avionics requirements Space requirements Measurement, analysis and improvement General guidance Software measurement process framework Outcomes of the process Measurement an
10、d monitoring of QMS performance Customer satisfaction Internal quality audits Measurement and monitoring of software processes Reference model for processes and process capability Performing an assessment Process improvement Measurement and monitoring of software product Software product quality mod
11、el Evaluation of software product Control of non-conformities Certification Quality system Software aspects of certification and flight approval Software life cycle data General Types of software life cycle data Characteristics of software life cycle data Additional considerations Software re-use To
12、ol qualification Alternative methods Tailoring process General Responsibility for the tailoring process Processes / activities /tasks tailoring Software life cycle data tailoring Drivers for tailoring Table 1 - Mapping between DO-178B/ED-I2B and IEEE/EIA 12207.1 Software Life Cycle Data Table 2 - Im
13、pact of the drivers for tailoring 14 14 16 16 16 17 17 17 17 17 18 18 19 19 19 20 20 20 20 20 21 21 21 21 22 22 22 23 23 23 24 24 25 25 26 27 27 27 28 28 28 28 29 29 26 30 Page 5 TR 9109: 03-03 Foreword The increasing internationalisation of aerospace companies and their activities requires the adop
14、tion of a policy which no longer relies solely on national standards. Currently a mixture of national and international standards is being used in the civil-, military- and space- sectors. World-wide acceptance and recognition can only be reached, if company certification and product qualification a
15、re based on internationally accepted standards. The adoption of a set of internationally accepted standards will be a source of major savings to the aerospace industry and customers alike. National and international committees and industrial bodies, responsible for the development and authorisation
16、and/or publication of standards, have already recognised the need to harmonise the existing standards. It is to be expected that in the not too distant future, customer requirements outside of the new harmonised international standards will become the exception rather than the rule and will be the s
17、ubject of special negotiation. However, it must be admitted that current progress is very slow. In view of the number of national and international standards currently in circulation and preparation, it is certainly justified to ask whether yet another document governing software development and mai
18、ntenance is really necessary. It is in fact, due to the plethora of documents, of which none have been conceived specifically for software quality and engineering within the European aerospace industry, that the need for a guide for software quality management was identified. When defining the softw
19、are development concept to be adopted at the start of a new project, management is confronted with a list of questions that have to be answered, including: What level of quality is required for the product? Which of the current international standards should be adopted, especially since there is a c
20、onsiderable degree of replication? Since all standards have their strengths and weaknesses, is it advisable (or even permitted) to select only parts from different standards to make up a new whole? Should the current trend towards the integration of civil and military software development requiremen
21、ts be taken into account? Can the differences between the routes to civil and military certification affect the project? How can the need for a closer integration of quality and engineering requirements be accommodated? How can the project ensure that the development of the software does not take pl
22、ace to the detriment of the overall system aims? Can the project define a software development process that is manageable, efficient and at the same time assures the delivery of a product, which meets its specification, within budget, time and to the specified quality level? With so many issues, it
23、was felt that a guide through this jungle had become necessary. It is the intention of this guide to help with the interpretation and tailoring of existing standards and point out their strengths and weaknesses. The guide will also give an indication of the currently planned updates to the standards
24、 and any new trends under discussion. Page 6 TR 9109: 03-03 1 Introduction 1 .I Purpose The purpose of this document is to provide guidance to the European aerospace industry in the interpretation, application and tailoring of existing international standards relevant to software. Software standards
25、 required by the customer (acquirer) obviously must be adhered to, but where a degree of freedom is permitted, this guide sets out to indicate possible approaches for harmonising the contractual requirements with project management interests. This document is a pure guideline and shall not be used a
26、s a prescriptive standard. 1.2 Model and structure of the document IS0 9001 :2000 has been recognised as the standard closest to the needs of European aerospace software quality management, whereas IS0 12207 specifically covers the software life-cycle aspects. Therefore the structure of this documen
27、t is based on IS0 9001:2000 but takes into account IS0 12207. Some subjects very important to aerospace software such as software quality system certification, software product certification and to flight approval are not fully covered by those two IS0 standards. Therefore references are also made i
28、n this document to DO-178B/ED-I2B. This Guideline also aims at providing an interpretation of the standards and recommendations referenced in paragraph 3 below from the standpoint of software and giving an overview of the interrelationships between individual standards. The following subjects are co
29、nsidered in this document: - Requirements and guidelines - Use of international standards - Company-wide and project-specific aspects - System and software aspects - Quality and engineering aspects - Process and product aspects 1.3 Handling of different standards The standards, discussed in this gui
30、deline, say what and not how, organisations must generate their own in- house procedures and demonstrate their fulfilment of the requirement of the standards. It is strongly recommended that in dealing with subcontractors the same approach is adopted. 1.4 Tailoring approach To satisfy currently typi
31、cal software project requirements, it is necessary to select and tailor sections from different international standards. The tailoring process plays a very important role in the definition of the processes outputs. For this reason, Section 12 of this guideline provides pointers to the application of
32、 the tailoring process. In approaching tailoring, four major areas must be considered: a) b) Both processes and data produced can, and should, be tailored. It must be clear to those performing the tailoring processes, which of the requirements selected from the standards lend themselves to tailoring
33、 and which do not. Page 7 TR 9109: 03-03 c) Tailoring is not an end in itself, there must be a logical reason behind the application of any tailoring process. The need for the adaptation of standard requirements to a particular project is generally driven by considerations such as: level of software
34、 safety criticality, requirements for maintainability, specific project constraints (multinational, fixed price, delivery intervals, national security considerations, etc.), product characteristics, etc. d) Tailoring is potentially dangerous and if not properly controlled can lead to the definition
35、of a software life-cycle process that, in the short term supports a fast and cheap project, but ultimately can lead to a product that does not fulfil the contract and cannot be sold off. Therefore it is essential, throughout the tailoring process, to always respect the integrity and safety aspects o
36、f the final product. 2 Scope This guide is intended to help in the generation of project specific software standards by interpreting and adapting existing or planned international standards. It does not attempt to replace them. For the purposes of this guide, the term Software includes software deve
37、loped or acquired by the contractor as well as software provided by the customer for integration into the system. Unless otherwise stated, this document bases its recommendations regarding: a) quality management systems: on IS0 9001 :2000; b) software life cycle processes: on IS0 12207. which are ge
38、nerally recognised by most software developing organisations as well as their customers. 2.1 - Flight and Mission (hardware and firmware, I/O drivers, BIT, data, application software, etc.) - Ground (hardware and firmware, OS drivers, BIT, operation and maintenance, application software, etc.) - Sof
39、tware engineering environment (software tools for development and maintenance, testing and evaluation, simulation, hardware and firmware, OS drivers, BIT, etc.) Types of related systems covered by this guide are 2.2 Types of acquisition covered by this guide i) i) iii) iv) v) vi) Development (contra
40、ctor internal either alone or within project consortia) Development (sub-contracted by the contractor) Commercial Off The Shelf (COTS) Re-use of existing software (with or without modification) Customer furnished software (with or without modification) Mixture of any combination of the above. 2.3 Du
41、ring the conception and definition of a software development project it is the responsibility of the quality management to ensure that the following system and project aspects System aspects relating to software development and maintenance i) Architecture (functional distribution, hardware and softw
42、are configuration items, etc.) i) Interfaces (system, sub-system, hardware, software, etc.) iii) Safety (analysis, classification, etc.) iv) Configuration management (products, environments, etc.) v) Risk management vi) Qualification and verification vi) Certification and flight approval Page 8 TR 9
43、109: 03-03 viii) Delivery ix) Additional considerations (user-modifiable software, option-selectable software, field loadable x) Planning and resource management software, etc.) are identified and planned for, that appropriate processes and procedures are defined, agreed and placed on project. Quali
44、ty management should assure the adherence to the processes and procedures through participation and the performance of planned quality actions .e. inspections, audits and reviews. Although this guide addresses software only, an integrated system approach should be considered: .e. an approach where s
45、oftware, hardware, human interfaces, infrastructure and processes are integrated into one system and where the corresponding disciplines and technologies are incorporated into the system engineering discipline. 3 References 3.1 General The following International Standards and Technical Reports are
46、referred to in this guide and contain information relevant to aerospace software. 3.2 3.2.1 AECMA prEN 91 O0 (Edition P2:2001), Aerospace series - Qualify managemenf sysfems - Requiremenfs (based on IS0 9001:2000) and Qualify sysfems - Model for qualify assurance in design, developmenf, producfion,
47、insfallafion and servicing (based on IS0 9001:1994) 1) Informative references (listed by source and by date of issue) 3.2.2 ECSS ECSS-Q-80 Issue A (1 996), ECSS-E-40 Issue A (1 999), Space producf assurance - Software Producf Assurance Space engineering - Software In Progress: ECSS-Q-80 Issue B, ECS
48、S-E-40 Issue B, Space producf assurance - Software Producf Assurance Space engineering - Software 3.2.3 IEEEIEIA IEEE/EIA 12207.0, .I RTCA is not an official agency of the United States Government and therefore, its recommendations, unless adopted by the relevant federal government organizations, ma
49、y not be regarded as statements of official government policy.” 8) “EUROCAE minimum operational performance specifications are recommendations only. EUROCAE is not an official body of the European governments; its recommendations are valid as statements of official policy only when adopted by a particular government or conference of governments.” Page 11 TR 9109: 03-03 MIL-STD NATO PSAC prEN QMS RAI ENAC RML RTCA SAS sc SEI SPICE STD TC TQM TR WTD 61 Military Standard North Atlantic Treaty Organisation Plan for Software Aspects of Certification pre-European Standard Quality Management S
