ASD-STAN PREN 9115-2010 Quality Management Systems Requirements for Aviation Space and Defense Organizations Deliverable Software (Supplement to EN 9100) (Edition P 1)《质量管理体系 适用于航空.pdf

《ASD-STAN PREN 9115-2010 Quality Management Systems Requirements for Aviation Space and Defense Organizations Deliverable Software (Supplement to EN 9100) (Edition P 1)《质量管理体系 适用于航空.pdf》由会员分享，可在线阅读，更多相关《ASD-STAN PREN 9115-2010 Quality Management Systems Requirements for Aviation Space and Defense Organizations Deliverable Software (Supplement to EN 9100) (Edition P 1)《质量管理体系 适用于航空.pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、ASD STANDARD NORME ASD ASD NORM prEN 9115 Edition P 1 April 2010 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATIONAvenue de Tervuren, 270 - B-1150 Brussels - Tel. 32 2 775 8126 - Fax. 32 2 775 8131 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSION Quality Ma

2、nagement Systems Requirements for Aviation, Space and Defense Organizations Deliverable Software (Supplement to EN 9100) Systmes de management de la Qualit Exigences des Organisations pour lAviation, lEspace et la Dfense Logiciel livrable (Supplment lEN 9100) Qualittsmanagementsysteme Anforderungen

3、an Organisationen der Luftfahrt, Raumfahrt und Verteidigung Lieferbare Software (Ergnzung zu EN 9100) This “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The AeroSpace and Defence Industries Association of Europe - Standardization). It is published for the nee

4、ds of the European Aerospace Industry. It has been technically approved by the experts of the concerned Domain following member comments. Subsequent to the publication of this Prestandard, the technical content shall not be changed to an extent that interchangeability is affected, physically or func

5、tionally, without re-identification of the standard. After examination and review by users and formal agreement of ASD-STAN, it will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standardization) for formal vote and transformation to full European Standard (EN). The

6、 CEN national members have then to implement the EN at national level by giving the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication 1 April 2010 Comments should be sent within six months after the date of public

7、ation to ASD-STAN Quality Domain Copyright 2009 by ASD-STAN prEN 9115:2010 (E) 2 Contents Page Foreword4 0 Introduction5 0.1 General5 0.2 Process approach5 QUALITY MANAGEMENT SYSTEMS REQUIREMENTS5 1 Scope 5 1.1 General5 1.2 Application .5 2 Normative references 6 3 Terms and definitions .6 4 Quality

8、 management system9 4.1 General requirements9 4.2 Documentation requirements.9 4.2.1 General9 4.2.2 Quality manual .9 4.2.3 Control of documents 10 4.2.4 Control of records. 10 5 Management responsibility . 10 5.1 Management commitment . 10 5.2 Customer focus. 10 5.3 Quality policy 10 5.4 Planning.

9、10 5.4.1 Quality objectives . 10 5.4.2 Quality management system planning. 10 5.5 Responsibility, authority and communication. 10 5.5.1 Responsibility and authority . 10 5.5.2 Management representative 10 5.5.3 Internal communication . 10 5.6 Management review 11 5.6.1 General. 11 5.6.2 Review input

10、 11 5.6.3 Review output . 11 6 Resource management 11 6.1 Provision of resources. 11 6.2 Human resources 11 6.2.1 General. 11 6.2.2 Competence, training and awareness 11 6.3 Infrastructure. 11 6.4 Work environment 12 7 Product realization 12 7.1 Planning of product realization. 12 7.1.1 Project mana

11、gement 12 7.1.2 Risk management . 13 7.1.3 Configuration management. 13 7.1.3.1 Configuration management planning.13 7.1.3.2 Configuration identification. 14 7.1.3.3 Change control 14 prEN 9115:2010 (E) 3 7.1.3.4 Configuration status accounting .14 7.1.3.5 Configuration audit .15 7.1.4 Control of wo

12、rk transfers15 7.2 Customer-related processes15 7.2.1 Determination of requirements related to the product15 7.2.2 Review of requirements related to the product15 7.2.3 Customer communication 16 7.3 Design and development16 7.3.1 Design and development planning16 7.3.2 Design and development inputs

13、16 7.3.3 Design and development outputs16 7.3.4 Design and development review16 7.3.5 Design and development verification16 7.3.6 Design and development validation17 7.3.6.1 Design and development verification and validation testing .17 7.3.6.2 Design and development verification and validation docu

14、mentation .17 7.3.7 Control of design and development changes 17 7.4 Purchasing .18 7.4.1 Purchasing process 18 7.4.2 Purchasing information 18 7.4.3 Verification of purchased product.18 7.5 Production and service provision .18 7.5.1 Control of production and service provision .18 7.5.1.1 Production

15、 process verification 18 7.5.1.2 Control of production process changes.19 7.5.1.3 Control of production equipment, tools and software programs.19 7.5.1.4 Post-delivery support19 7.5.2 Validation of processes for production and service provision 19 7.5.3 Identification and traceability.19 7.5.4 Custo

16、mer property 19 7.5.5 Preservation of product19 7.6 Control of monitoring and measuring equipment .20 8 Measurement, analysis and improvement20 8.1 General .20 8.2 Monitoring and measurement 20 8.2.1 Customer satisfaction.20 8.2.2 Internal audit 20 8.2.3 Monitoring and measurement of processes.20 8.

17、2.4 Monitoring and measurement of product .20 8.3 Control of nonconforming product .20 8.4 Analysis of data.21 8.5 Improvement 21 8.5.1 Continual improvement 21 8.5.2 Corrective action .21 8.5.3 Preventive action.21 Bibliography22 prEN 9115:2010 (E) 4 Foreword This standard was reviewed by the Domai

18、n Technical Coordinator of ASD-STANs Quality Domain. After inquiries and votes carried out in accordance with the rules of ASD-STAN defined in ASD-STANs General Process Manual, this standard has received approval for Publication. This document standardizes, to the greatest extent possible, the softw

19、are quality management system requirements for the aviation, space, and defense industry. This was accomplished through the harmonization of quality management system requirements from international aviation, space, and defense software standards and other applicable documents. The establishment of

20、common requirements for use at all levels of the supply-chain by organizations around the world should result in improved quality, schedule, and cost performance by the reduction or elimination of organization unique requirements and wider application of good practice. SUMMARY/RATIONALE The 9115 doc

21、ument supersedes AS9006, “Deliverable Aerospace Software Supplement for AS9100A, Quality Management Systems Aerospace Requirements for Software”, published in March 2003. The AS9006 standard was published as an Americas Aerospace Quality Group (AAQG) sector specific document. This is the initial rel

22、ease of 9115, which is an international supplement to 9100 providing clarification of the corresponding 9100 requirements, as necessary, for deliverable software. In some cases, where clarification is needed, it was necessary due to the complexity of software to decompose “shall” statements in 9100

23、into more granular requirements. Where no software clarification is required of the 9100 requirements, the following phrase will be presented: “The requirements of 9100 apply. No clarification required for software.” NOTE This document must be used in conjunction with EN 9100; references throughout

24、the text to EN 9100 are understood to mean EN 9100:2009. prEN 9115:2010 (E) 5 0 Introduction 0.1 General The requirements of EN 9100 apply. No clarification required for software. 0.2 Process approach The requirements of EN 9100 apply. No clarification required for software. QUALITY MANAGEMENT SYSTE

25、MS REQUIREMENTS 1 Scope 1.1 General The requirements of EN 9100 apply with the following clarification for software. This document supplements the EN 9100 standard requirements for deliverable software and contains quality management system requirements for organizations that design, develop, and/or

26、 produce deliverable software for the aviation, space, and defense industry. This includes, as required, support software that is used in the development and maintenance of deliverable software. The deliverable software may be stand-alone, embedded, or loadable into a target computer. Where the use

27、of Hardware Description Language (HDL) or high order language is utilized as the design source of electronic hardware e.g., Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), the organization and customer shall agree on the extent of applicability of this supplement. NO

28、TE 1 For airborne electronic hardware guidance, see RTCA/DO-254 or EUROCAE ED-80; and for product realization requirements, see EN 9100. Where Commercial-off-the-Shelf (COTS) or non-developmental software is integrated into a deliverable product, the organization and customer shall agree on the exte

29、nt of applicability of this supplement. For the purposes of this document, the terms “product” and “software product” are considered synonymous. NOTE 2 This document is independent of the life cycle models (e.g., waterfall, spiral, evolutionary, incremental) or methodology (e.g., objected oriented d

30、esign, unified modeling language, agile). 1.2 Application The requirements of EN 9100 apply with the following clarification for software. Exclusions to requirements in clause 7 should only be considered after analysis of software attributes (e.g., size, safety, security, complexity, criticality, ri

31、sk). prEN 9115:2010 (E) 6 2 Normative references The requirements of EN 9100 apply with the following clarification for software. The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, t

32、he latest edition of the referenced document (including any amendments) applies. EN 9100:2009, Quality Management Systems Requirements for Aviation, Space and Defense Organizations NOTE Documents referenced in this document, other than the normative references (i.e., 9100, ISO 9000) are listed in th

33、e Bibliography. For undated references, the latest edition of the referenced document (including any amendments) applies. The referenced documents are “informative” references; the requirements of these referenced documents do not add any additional requirements to this standard. 3 Terms and definit

34、ions For the purposes of this document, the terms and definitions given in EN 9100 and ISO 9000 apply. The following terms and definitions are included to support the understanding of this document. 3.1 baseline the approved, recorded configuration of one or more configuration items, that thereafter

35、 serves as the basis for further development, and that is changed only through change control procedures RTCA/DO-178, EUROCAE ED-12. 3.2 commercial-off-the-Shelf (COTS) software commercially available applications sold by vendors through public catalog listings. COTS software is not intended to be c

36、ustomized or enhanced. Contract-negotiated software developed for a specific application is not COTS software RTCA/DO-178, EUROCAE ED-12. NOTE COTS software is a type of non-developmental software. 3.3 configuration item One or more hardware/software entities treated as a unit for configuration mana

37、gement purposes or software life cycle data treated as a unit for configuration management purposes based on RTCA/DO-178, EUROCAE ED-12. 3.4 critical items the definition in EN 9100, clause 3.3, applies with the following clarification for software. critical items in software are those characteristi

38、cs, requirements, or attributes that have been determined to be most important to achieve product realization (e.g., safety, maintainability, testability, usability, performance). Critical items should be adequately managed and appropriate action taken to ensure visibility throughout the product lif

39、e cycle. For example, in a flight control system software response time can be elevated to a critical item to ensure performance characteristics are met. Furthermore, if the project has specific testability requirements, cyclomatic complexity may become a critical item. prEN 9115:2010 (E) 7 3.5 cycl

40、ic redundancy check (CRC) a type of function that takes as input a data stream of any length and produces as output a value of a certain space, commonly a 32-bit integer. A CRC can be used to detect alteration of data during transmission or storage. 3.6 digital signature a type of asymmetric cryptog

41、raphy used to express compliance with the security properties of a handwritten signature on paper, also referred to as a digital signature scheme 3.7 key characteristic The definition in EN 9100, clause 3.4, applies with the following clarification for software key characteristics in software are th

42、ose measurable attributes where variability can be measured by the project and can, if left unchecked, adversely impact the project or product in areas (e.g., schedule, cost, maintainability, testability, reliability, portability). Examples of key characteristics include defect severity, complexity

43、factors, nested menus, memory, timing, response time, and throughput targets. 3.8 Monitoring the act of witnessing or inspecting selected instances of test, inspections, or other activities, or records of those activities, to assure that the activity is under control and that the reported results ar

44、e representative of the expected results monitoring is usually associated with activities done over an extended period of time where 100 % witnessing is considered impractical or unnecessary. Monitoring permits authentication that the claimed activity was performed as planned. RTCA/DO-178, EUROCAE E

45、D-12. 3.9 non-developmental software deliverable software that is not developed under the contract, but is provided by the organization, customer, or a third party (e.g., reused software, customer furnished software, COTS software, open source software) 3.10 phase a collection of processes, activiti

46、es, tasks, and outcomes within the software life cycle 3.11 release a particular version of a configuration item that is made available for a specific purpose (e.g., test release) ISO/IEC 12207. 3.12 reliability the probability of failure-free operation of a computer program in a specified environme

47、nt for a specified time based on IEEE-STD-982.1. NOTE Software reliability requirements should consider the level and manner of fault and failure detection, isolation, fault tolerance, and recovery expected to be fulfilled by the software. 3.13 risk the definition in EN 9100 (see 3.1) applies. No cl

48、arification required for software prEN 9115:2010 (E) 8 3.14 robustness the extent to which software can continue to operate correctly despite invalid inputs RTCA/DO-178, EUROCAE ED-12. NOTE Robustness, in the software context, means that the organization has utilized techniques (e.g., exception hand

49、ling, redundancy, related verification techniques). 3.15 secure hash algorithm cryptographic functions that compute a fixed-length digital representation, known as a message digest, of an input data sequence of any length. 3.16 software computer programs, associated documentation, and data pertaining to the operation of a computer system based on RTCA/DO-178, EUROCAE ED-12. NOTE 1 The executable programs and data that are embedded in hardware devices are considered to