SAE ARP 9005-2005 Aerospace Guidance for Non-Deliverable Software《航空航天非交付软件指南》.pdf

《SAE ARP 9005-2005 Aerospace Guidance for Non-Deliverable Software《航空航天非交付软件指南》.pdf》由会员分享，可在线阅读，更多相关《SAE ARP 9005-2005 Aerospace Guidance for Non-Deliverable Software《航空航天非交付软件指南》.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、 AEROSPACE RECOMMENDED PRACTICE Aerospace Guidance for Non-Deliverable Software SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suita

2、bility for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions. Copyr

3、ight 2005 SAE International All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT OR

4、DER: Tel: 877-606-7323 (inside USA and Canada) Tel: 724-776-4970 (outside USA) Fax: 724-776-0790 Email: custsvcsae.org SAE WEB ADDRESS: http:/www.sae.org Issued 2005-06 ARP9005 FOREWORD Non-deliverable software is defined as software used in the design, manufacture, inspection, test, acceptance, or

5、calibration of a deliverable product, and is not generally delivered under a contract. As Industry efforts increase to improve product quality and reliability and reduce production costs, use of computer software programs for automation, control and monitoring of production processes and product tes

6、t, acceptance and calibration is also increasing. It is therefore vital to assure these software programs are controlled to ensure product conformity requirements are properly supported. The intent of this document is to provide industry recommended guidelines for non-deliverable software that are f

7、ocused on its control and ensuring validation of released software in its functioning environment, appropriate configuration control of non-deliverable software through application of unique identification, and retention of relevant records for internally developed software documenting its developme

8、nt and validation prior to application or use. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 2 - TABLE OF CONTENTS 1. SCOPE.4 2. REFERENCES.4 3. TERMS AND DEFINITIONS 5 4. NON-DELIVER

9、ABLE SW QUALITY PLANNING.7 5. REQUIREMENTS 8 6. NON-DELIVERABLE SOFTWARE REALIZATION8 6.1 Developed/Tailored Software.8 6.1.1 Development Planning.9 6.1.2 Development Inputs .9 6.1.3 Development Outputs 10 6.1.4 Development Review .10 6.2 Purchased or Vendor Supplied Software.10 6.2.1 Purchasing Pro

10、cess .10 6.2.2 Purchasing Information 11 7. VERIFICATION AND VALIDATION .11 7.1 Verification .11 7.2 Validation .11 7.3 Documentation of Verification and Validation 12 8. CONFIGURATION CONTROL.12 8.1 Identification and Traceability.12 8.2 Control of Changes 13 8.3 Nonconforming Software13 8.4 Noncon

11、forming Products14 9. PROVISIONS FOR PRODUCTION SOFTWARE14 9.1 Controls and Utilization 14 9.1.1 Release and Distribution14 9.1.2 Access Control.15 9.1.3 Obsolete Software15 9.1.4 Preservation of Product15 9.2 Production Documentation.16 10. OTHER CONSIDERATIONS .16 10.1 First Article Inspection16 1

12、0.2 Internal Audit16 10.3 Customer Communication16 ANNEX A GUIDELINES FOR IMPLEMENTATION .18 ANNEX B CROSS-REFERENCE TO AS910020 Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 3 - INTR

13、ODUCTION General This SAE Aerospace Recommended Practice (ARP) document defines recommendations for the use of non-deliverable software in the Aerospace Industry based on best practices and effective control methodology. Process Approach This document deals with the subject of non-deliverable softwa

14、re as a series, or system of processes, linked and managed to bring effective control to the varied aspects and types of software utilized in supporting and enabling production. This linked series or system of processes is referred to as the “Process Approach” and is utilized in developing the contr

15、ol methodology for non-deliverable software. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 4 - 1. SCOPE: General: This document contains recommended practices for the effective contro

16、l of non-deliverable software. It addresses practices for control during the development, production, release maintenance, and retirement of non-deliverable software, as well as for software procured from outside manufacturers and incorporated in the production, evaluation, test, acceptance or calib

17、ration of processes. For the purposes of this document, the terms software and non-deliverable software are considered synonymous. Application: The guidelines in this ARP apply to non-deliverable software that: directly relates to design, manufacture, inspection, test or calibration of a deliverable

18、 product, and directly affects the configuration, conformity or quality of a deliverable product. The following are not within scope of this ARP: deliverable software (reference AS9006), business systems or office software, information systems software for business applications, prototype software t

19、hat is not intended for delivery, and software that only enables the operations of other software or devices in the performance of required tasks that do not affect product conformity. 2. REFERENCES: The following publications form a part of this document to the extent specified herein. The latest i

20、ssue of SAE publications shall apply. The applicable issue of other publications shall be the issue in effect on the date of the purchase order. In the event of conflict between the text of this document and references cited herein, the text of the document takes precedence. Nothing in this document

21、, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 5 - 2.1 SAE Publications: Available

22、from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001. AS9100 Quality Systems - Aerospace - Model for Quality Assurance in Design, Development, Production, Installation and Servicing AS9006 Deliverable Aerospace Software Supplement for AS9100A 3. TERMS AND DEFINITIONS: The following terms are

23、important to the understanding of this recommended practice and are included here for ease of use. Acceptance Testing: Testing conducted in an operational environment to determine whether a product satisfies its acceptance criteria. Archive: The long-term storage to assure that the software, documen

24、ts, and life cycle data associated with the software product are retrievable. Business Systems/Office Software: General-purpose use software that is widely used and commercially obtainable. Contract: (Software Contract): A binding agreement between two parties, enforceable by law, for the supply of

25、software or the, development, production, operation, or maintenance of a software product. Commercial-Off-The-Shelf (COTS): Commercially available applications sold by vendors through public catalog listings. Dataset(s): Information prepared and maintained by electronic means, and provided by electr

26、onic data access, interchange, transfer, or on electronic media. Development: A software life cycle process that contains the activities and support for requirements analysis, design, coding, integration testing, installation and acceptance of software products. Developed or tailored: Software that

27、is developed, modified or customized by or for the user. This includes new development, modification, re-engineering, and maintenance activities that result in software used in product realization. EARS: Export Administration Regulation. ITAR: International Traffic in Arms Regulation. Copyright SAE

28、International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 6 - 3. (Continued): Life cycle: A framework containing the processes, activities and tasks involved in the design, development, operation and maintenan

29、ce of a software product, spanning the life of the system from the definition of its requirements to the termination of its use. Non-deliverable software: Software used in the design, manufacture, inspection, test, acceptance, or calibration of a deliverable product. Part Specific: Software that ret

30、ains approved configuration information. This may include program files, product definition datasets (Authority Models), Numerical Control (NC) programs, Coordinate Measurement Machine (CMM) programs, and dataset derivatives from Computer Aided Design (CAD) models, etc. Porting or Migrating: Modifyi

31、ng software to run on a different computer and/or operating system than those on which it has been verified and validated. Prototype Software: Software in the development stages not used in product realization. Purchased/Vendor Supplied: Software that is not modified or customized. This includes Com

32、mercial off the Shelf (COTS) software used for product realization. Software that is modified for use in production, or not used in its original off-the-shelf state, exclusive of selection of options and features, is not considered COTS. Release: An approved version of a configuration item made avai

33、lable for a specific purpose (for example, test release). Replication: A process of copying a software product from one medium to another. Software: Computer programs and, possibly, associated documentation and data pertaining to the operation of a computer system. This definition includes executabl

34、e programming logic and data that are embedded in hardware devices known as firmware. Software item: Any identifiable part of a software product. Software product: An output that results from a software process. Products can be tangible or intangible, a thing or an idea, hardware or software, inform

35、ation or knowledge, a process or procedure, a service or function. When ISO uses the term product, it also means service. Stage: A defined segment of development. NOTE: A stage does not imply the use of any specific life cycle model. Copyright SAE International Provided by IHS under license with SAE

36、Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 7 - 3. (Continued): Supplier: An organization that enters into a contract with the acquirer for the supply of a system, software product or software service under the terms of the contract. NOTE: The ter

37、m supplier is synonymous with contractor, producer, seller, or vendor. TAA: Technical Assistance Agreement. Validation: The process of determining that software complies as follows: (1) conforms to its development standards (2) requirements and or specifications are fulfilled, (3) works as intended

38、in the target environment. Validation determines that the fully integrated software functions correctly, completely, and consistently with system specifications and requirements. Verification: Processes of evaluation to assure input requirements are achieved at the end of a development stage. Verifi

39、cation can occur at various times during a software process. Verification includes review, analysis, inspection, and test. 4. NON-DELIVERABLE SW QUALITY PLANNING: A Quality Management System should be in place prior to implementing a specific system for non-deliverable software. The non-deliverable

40、software system or plan should provide a documented process that addresses, at a minimum, the following items: a. responsibility and authority within the organization, b. identification of requirements, c. analysis of risks and criticality, d. verification and validation, e. version control, f. trai

41、ning and maintenance, g. documentation, h. supplier requirements and oversight. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 8 - 5. REQUIREMENTS: The organization should determine an

42、d document the software requirements, including business, organizational, safety, and security requirements. Requirements should be complete and unambiguous. The requirements should include, as appropriate: a. performance criteria, b. acceptance criteria, c. system architecture (i.e., hardware/softw

43、are compatibility, portability), d. procedure, specification, and standard compliance e. customer specific requirements (export controls such as ITAR, TAA, EARS, third party escrow agreement, etc.). A process to decide whether to develop or purchase software should be documented. In either case, the

44、 organization should ensure acceptance testing to requirements is performed, including any customer specific software requirements. 6. NON-DELIVERABLE SOFTWARE REALIZATION: Software realization is the process of developing or purchasing software for use in the design, manufacture, inspection, test,

45、acceptance or calibration of a deliverable product. Non-deliverable software can be developed, tailored, purchased or vendor supplier. Part specific software can either be developed or procured for use in the manufacturing environment. Part Specific software retains approved configuration informatio

46、n. This may include program files, product definition datasets (Authority Models), Numerical Control (NC) programs, Coordinate Measurement Machine (CMM) programs, and dataset derivatives from Computer Aided Design (CAD) models, etc. 6.1 Developed/Tailored Software: Software that is developed, modifi

47、ed or customized by or for the user. This includes new development, modification, re-engineering, and maintenance activities that result in software used in product realization. This includes purchased or vendor supplied software that is modified or customized. Copyright SAE International Provided b

48、y IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE ARP9005 - 9 - 6.1.1 Development Planning: Development planning is the processes of establishing tasks associated with the development of non-deliverable software products. Development p

49、lanning should include the following items: a. the primary function of the software, b. identification of inputs and outputs, c. identification of software, d. traceability of software requirements throughout the lifecycle e. identification of applicable standards, conventions, tools, and techniques, f. computer hardware requirements, limitations, and constraints, g. interfaces between diff