ASQR 07.5
Control of Software - Checklist
# / Par # / Requirement / S / CAR / N/A / CommentNon-deliverable Software
1 / 4.1 / Does the supplier have a defined, documented and implemented non-deliverable software control procedure(s)? Does it define the minimum types of software, as outlined in the “Non–Deliverable Software Definition”?2 / 4.1.1 / Does the procedure define the organizational responsibility and authority including product and process integrity?
3 / 4.1.2 / Does the procedure define the software “identification requirements”.
- Defining the purpose or function of the software.
- Defining the requirements and how the software requirements are initiated, documented and approved.
4 / 4.1.3 / Does the procedure define the software “coding standards”:
- Naming conventions, including developmental version production file names.
- Software Version
- Header information
- Comments
5 / 4.1.4 / Does the procedure define the “verification & validation” of the software:
- Defining the Verification and Validation process.
- Including the test procedure or test description and that results shall be documented, reviewed and retained.
- Provide objective evidence that the software performs its required function.
- Trace software to requirements.
- Require that someone acting in an acknowledged product integrity role must perform the inspection review and approval of software. That software used to verify quantitative values (e.g., CMM, etc.) requires an independent method of validation (i.e., layout inspection, fixture check or comparison with another CMM program previously verified by an independent method) and correlation of the two sets of results.
- Acceptable correlation requires the difference to be within 10% of the tolerance for each characteristic. Differences greater than 10% but not exceeding 25% may be acceptable with documented justification.
Differences greater than 25% are not acceptable.
6 / 4.1.5 / Does the procedure define the “target environment” and:
- Identify interfaces to other software and to target computer hardware.
- Identify the target computer hardware and software environment.
7 / 4.1.6 / Does the procedure define “version control” and:
- Uniquely identify each version of the software.
- Identify each item that makes up a software product.
8 / 4.1.7 / Does the procedure define “change control” and define the software change process. This includes, but is not limited to:
- Identifying problems.
- Analysis for problem cause.
- Implementation and verification of corrective action
- Re–verification and re–validation of software shall be employed to ensure that the modified software meets the changed requirements.
9 / 4.1.8 / Does the procedure define “access control” and ensure:
- Limited access control shall be defined and implemented.
Examples of such controls include:
a)Read and write access of the master and copies.
b)Edit Key restrictions (e.g. NC, CNC Machine, etc.).
10 / 4.1.9 / Does the procedure define “archiving, backup & recovery” and:
- Define the process used to prevent the use of obsolete software programs.
Software that is no longer required for production shall be restricted and/or removed from all systems so it is no longer available for use.
- Master copies, duplicates, and user copies shall be restricted and/or removed from all areas except the archive.
- Obsolete software in the archive shall have restricted access to prevent unauthorized use.
- Master copies shall be stored in a secure location.
- Software programs shall be archived in a manner that allows retrieval of all released versions of software programs for traceability purposes.
11 / 4.1.10 / Does the procedure define “identification, storage, handling & release” and:
Define the method for identification, storage, handling and release of software to the user. The end user shall only access the latest software program version.
12 / 4.1.11 / Does the procedure define “training & maintenance requirements”?
13 / 4.1.12 / Does the procedure define “documentation” and:
- Define required documentation for software development.
- Define approval requirements for software being released to production.
14 / 4.1.13 / Does the procedure define the process of supplier oversight? (i.e., audit & product acceptance)
15 / 4.1.14 / Does the procedure define the process used to accept Purchased or Vendor Supplied software prior to initial use?
16 / 4.1.15 / Does the procedure define the analysis of risks & criticality, as applicable?
17 / 4.1.16 / Does the procedure define the “software support tool development process” and:
- Define the software requirements and document them in the program folder or equivalent.
- Design and code the software and document the activity in the program folder or equivalent.
- Execute a functional test of the software and document the activity in the program folder or equivalent.
- Control the Software and documentation using internal configuration management procedures.
18 / 4.1.17 / Does the procedure define the internal audit or review processes for software to ensure compliance to established software development, procurement and control procedures?
Deliverable Software
19 / 4.2 / Does the supplier have a defined, documented and implemented deliverable software control procedure(s)? Does it meet or exceed the following requirements or as specified by the contract or purchase order?20 / 4.2.1 / Does the procedure define the requirement that all deliverable software plans shall be submitted to P&WC for review and approval prior to the start of the software development process. Also that all subsequent revisions/changes shall also be submitted for review and approval?
21 / 4.2.2 / Does the procedure define that RTCA/DO-178 shall be the preferred approach for all software development and shall meet the requirements of ASQR-07.5?
To be used in conjunction with Appendix 1
22 / 4.2.2 / Does the procedure require that the supplier shall complete and maintain a checklist that defines the RTCA/DO-178 requirements, when submitted to P&WC?
To be used in conjunction with Appendix 1
23 / 4.2.3 / Does the procedure define that the Software Quality Assurance Plan (S/W QA) shall include the following:
- A description of the S/W QA environment, including the scope, organizational responsibilities and interfaces, standards, procedures, tools and methods.
- A statement of the S/W QA authority, responsibility and independence, including the approval authority for software products.
- The S/W QA activities that are to be performed for each software life cycle process and throughout the product development including:
- S/W QA methods, (e.g., reviews, audits, reporting, inspections, and monitoring of the software life cycle processes, etc.)
- Activities related to the problem reporting, tracking and corrective action system.
- A description of the method used to ensure disposition and retention of any remaining S/W QA open action items, change requests, and completion of all software development tasks at the conclusion of the program.
24 / 4.2.4 / Does the procedure define that the Software Development Plan (SDP) shall include the following:
- Identification of software being developed.
- Resources (e.g., requirement, design code and verification environment etc.).
- Organizational structure and responsibilities.
- Software Development process (e.g., including prototype and flight test software etc.).
- Software Development schedule and milestones.
- Quality and project records.
- Integrated Product Teams.
- Formal reviews.
- Computer resource utilization.
- Corrective action process.
- Risk management.
- Control and development of software tools.
- Software metrics.
- Subcontractor management.
- Security and safety requirements.
- Data Management/Software Development libraries including documents to be produced.
- Program language(s).
- Standards (e.g., requirements, Design code etc.).
Appendix 1
RTCA/DO-178B AUDIT CHECKLIST & REPORT
CHECKLIST DATE: Feb 25, 2008SUPPLIER NAME: / VENDOR No. : / AUDIT PURPOSE: DO-178B Objective Compliance
SUPPLIER CONTACT: TBD
SUPPLIER ADDRESS:
AUDIT DATE: / AUDITOR:
R E Q U I R E M E N T S / COMPLIANCE & ASSESSMENT
Section 4.0 Software Planning Process / SUPPLIER COMPLIANCE / P&WC ASSESSMENT
YES / NO / N/A / REFERENCES AND REMARKS / YES / NO / N/A / REFERENCES AND REMARKS
No specific requirements.
4.1 S/w Planning Process Objectives
No specific requirements.
4.2 Software Planning Process Activities
R4.1 Is there a procedure that requires s/w plans be developed at a time in the life cycle to provide appropriate direction to personnel?
R4.2 Is there a procedure that requires s/w standards used for the project be defined or selected?
R4.3 Is there a procedure that requires methods and tools be chosen to provide error prevention in development process?
R4.4 Is there a procedure that requires the s/w planning process provide coordination between the s/w development and integral processes to provide consistency among strategies in the s/w plans?
R4.5 Is there a procedure that requires a means to update the s/w plans be defined?
R4.6 Is there a procedure that requires when multiple version dissimilar s/w is used in a system, the s/w planning process chooses the methods and tools to achieve the error avoidance or detection necessary to satisfy the system safety objectives?
R4.7 Is there a procedure that requires s/w plans and s/w development standards be under change control, and reviews of them be completed?
R4.8Is there a procedure that requires the planning process define how deactivated code will be defined, verified and handled?
R4.9 Is there a procedure that requires the process, tools, environment and data items associated with user modifiable code development be defined in the plans and standards
R4.3 Software Plans
R4.10 Is there a procedure that requires s/w plans comply with DO/178B.
R4.11 Is there a procedure that requires definition of the transition between s/w life cycles be specified by inputs to the process, any integral process activities to act on the inputs and availability of tools, methods, plans and procedures?
R4.12 Is there a procedure that requires s/w change procedure be defined prior to the use of the change on a certified engine /aircraft
4.4 Software Life Cycle Environment Planning
No specific requirements
4.4.1 Software Development Environment (SDE)
R4.20 Is there a procedure that requires SDE be chosen to minimise potential risk to s/w product?
R4.21 Is there a procedure that requires the necessary confidence level in the use of tools be such that errors introduced by one part be detected by another?
R4.22 Is there a procedure that requires s/w development and verification activities and standards be defined to minimise potential SDE related errors?
R4.23 Is there a procedure that requires when certification credit is sought for tool use that the sequence of use is defined?
R4.24 Is there a procedure that requires when optional features of a tool are chosen that the effects of the option are defined?
4.4.2 Language and Compiler Considerations
R4.25 Is there a procedure that requires the effect on structural coverage of compiler optimisers be defined?
R4.26 Is there a procedure that requires the means to detect and verify coverage of object code that is not traceable to source be defined?
R4.27 Is there a procedure that requires when compiler, linker, loader or compiler options are changed re-verification is defined?
4.4.3 Software Test Environment
R4.28 Is there a procedure that requires an emulator or simulator may need to be qualified?
R4.29 Is there a procedure that requires the functional and error detection differences between the target and the emulator/simulator be analysed?
4.5 Software Development Standards
R4.30 Is there a procedure that requires software standards comply with DO/178B?
R4.31 Is there a procedure that requires components are uniformly designed and implemented?
R4.32 Is there a procedure that requires standards disallow use of constructs or methods that produce output that cannot be verified or incompatible with safety requirements?
4.6 Review and Assurance of the Software Planning Process
R4.33 Is there a procedure that requires the software quality system must enable DO/178B objectives be met?
R4.34 Is there a procedure that requires the software life cycle processes be consistently appied?
R4.35 Is there a procedure that requires each process produces evidence that outputs are traceable to the activity and inputs?
R4.36 Is there a procedure that requires the software planning outputs be consistent and comply with DO/178B?
R E Q U I R E M E N T S / COMPLIANCE & ASSESSMENT
Section 5.0 Software Development Processes / SUPPLIER COMPLIANCE / P&WC ASSESSMENT
YES / NO / N/A / REFERENCES AND REMARKS / YES / NO / N/A / REFERENCES AND REMARKS
5.1 Software Requirements Process
No specific requirements.
5.1.1 Software Requirements Process Objectives
No specific requirements.
5.1.2 Software Requirements Process Activities
R5.1 Are the process inputs to the requirements process defined?
R5.2 Has the system requirement allocated to software been analyzed for ambiguities, inconsistencies and undefined conditions?
R5.3 Have inadequate or incorrect inputs been reported for corrective action? See R5.2
R5.4 Is the system requirement allocated to software traceable to a high-level software requirement?
R5.5 Is the high level requirement defined that covers software allocation for prevention of system hazards?
R5.6 Does the high level requirement conform to the Software Requirements Standards and is it verifiable and consistent?
R5.7 Is the high level requirement stated in quantitative terms with tolerances where applicable?
R5.8 Does the high level requirement not describe design or verification detail other than specified and justified design constraints?
R5.9 Is the system requirement allocated to software traceable to one or more software high level requirements?
R5.10 Is the high level requirement, If not a derived requirement, traceable to one or more system level requirements?
R5.11 Is there a procedure that requires derived high level requirements be considered in the system safety assessment?
5.2 Software Design Process
No specific requirements.
5.2.1 Software Design Process Objectives
No specific requirements.
5.2.2 Software Design Process Activities
R5.12 Are the process inputs to the software design process defined?
R5.13 Do the low level requirements and software architecture conform to Software Design Standards and are they traceable, verifiable and consistent?
R5.14 Are the derived requirements defined and analysed to ensure that the high level requirements are not compromised?
R5.15 Is the software architecture defined as a derived requirement and included in the safety assessment process?
R5.16 Are the control and data flow monitored when safety related requirements dictate?
R5.17 Are the responses to failure conditions consistent with safety related requirements?
R5.18 Have any inadequate or incorrect inputs been reported for corrective action?
5.2.3 Designing for User-Modifiable Software
R5.19 Is there protection of non-modifiable code from changes made to modifiable component?
R5.20 Is the designed means for modification the only means to change the modifiable component?
5.3 Software Coding Process
No specific requirements.
5.3.1 Software Coding Process Objectives
No specific requirements.
5.3.2 Software Coding Process Activities
R5.21 Are the process inputs to the software coding process defined?
R5.22 Does the source code implement the low-level requirement and conform to the software architecture?
R5.23 Does the source code conform to the Software Code Standards?
R5.24 Is the source code traceable to the design description?
R5.25 Have inadequate or incorrect inputs been reported for corrective action?
5.4 Integration Process
No specific requirements.
5.4.1 Integration Process Objectives
No specific requirements.
5.4.2 Integration Process Activities
R5.26 Are the process inputs to the Integration Process defined?
R5.27 Has the executable object code been generated from the source code and linking/loading data?
R5.28 Is the executable object code loaded into the target computer for h/w-s/w integration?
R5.29 Have inadequate or incorrect inputs been reported for corrective action?
5.4.3 Integration Considerations
Is there any deactivated code? If not go to R5.32
R5.30 Has any deactivated code been disabled for the environments where its use is not intended?
R5.31 Do the methods for handling deactivated code comply with software plans?
Are there any patches in the code? If not go to R5.36.
R5.32 Are patches used in software submitted for use in a certified engine to implement changes in requirements or architecture, or changes necessary as a result of software verification activities?
R5.33 Does the software configuration management system track the patch?
R5.34 Has a regression analysis provided evidence that the patch satisfies all objectives of the software developed by normal methods?
R5.35 Is there justification for the use of the patch in the Software Accomplishment Summary?
5.5 Traceability
R5.36 Is there traceability between system requirements and software requirements?
R5.37 Is there traceability between low-level and high level requirements?
R5.38 Is there traceability between source code and low-level requirements?
R5.39 Is there traceability between requirements and test cases
R5.40 Is the traceability bi-directional
R5.41 Are standards established for providing traceability
R5.42 Are there tools for traceability
REMARKS / RECOMMENDATIONS / SUGGESTIONS:
NOTE:
R E Q U I R E M E N T S / COMPLIANCE & ASSESSMENTSection 6.0 Software Verification Processes / SUPPLIER COMPLIANCE / P&WC ASSESSMENT
YES / NO / N/A / REFERENCES AND REMARKS / YES / NO / N/A / REFERENCES AND REMARKS
No specific requirements.
6.1 Software Verification Process Objectives
No specific requirements
6.2 Software Verification Process Activities
R6.1 Are the inputs to the software verification process defined?
R6.2 Have the high level requirements (HLR) and the traceability to them from system level (SLR) and low-level requirements (LLR) been verified?
R6.3 Do the traceability, requirements-based and structural coverage based analyses show that each software requirement is traceable to the code that implements it and to the activities that verify it?
R6.4 Have the differences between the code tested and the airborne software been specified and justified?
R6.5 For any software requirements that cannot be verified using a realistic test environment, have other means been provided and specified and justified in the Software Verification Plan?
R6.6 Have any deficiencies or errors discovered during the software verification process been reported for corrective action?
6.3 Software Reviews and Analyses.
No specific requirements.
6.3.1 Reviews and Analyses of the High Level Requirements
R6.7 Is the target HLR compliant with a system requirement been confirmed?
R6.8 Has the HLR accuracy and consistency been confirmed?
R6.9 Has compatibility of the HLR with the target computer been confirmed?
R6.10 Is there confirmation that the target HLR is verifiable?
R6.11 Has HLR conformance to the Software Requirements Standards been confirmed?
R6.12 Has the HLR traceability to the SLR been confirmed?
R6.13Has the HLR algorithm accuracy and behaviour be confirmed?
6.3.2 Reviews and Analyses of the Low Level Requirements
R6.14 Is the target LLR compliant with the software high level requirement?
R6.15 Has the LLR accuracy and consistency been confirmed?
R6.16 Has compatibility of the HLR with the target computer been confirmed?
R6.17 Is there confirmation that the target LLR is verifiable?
R6.18 Has LLR conformance to the Software Design Standards been confirmed?
R6.19 Has the LLR traceability to the HLR been confirmed?
R6.20 Has the LLR algorithm accuracy and behaviour been confirmed?
6.3.3 Reviews and Analyses of the Software Architecture
R6.21 Has compliance with the HLR been confirmed?