Attachment_03.docx

Attachment 3 - Design Reviews and Documentation of Data

3.0 Physical Configuration Audit (PCA)

3.1 Contractor participation and responsibilities. The Contractor shall provide the following support during PCA:

1.

2.

3.

3.1.

3.1.1. Provide a complete set of non-reproducible engineering drawings at the most current revision level.

3.1.2. Make available company manufacturing plans and procedures, specifications, and inspection/acceptance procedures

3.1.3. Provide copies of any approved engineering changes that have not been incorporated into the engineering drawings. These must be incorporated prior to final acceptance of drawings.

3.1.4. Provide copies of any approved deviations and waivers.

3.1.5. Arrange for observation of production processes and access to assembly, inspection, and quality assurance areas. In process hardware, required for viewing items difficult to disassemble or view, may also be required.

3.1.6. The Contractor shall perform all required disassembly, assembly, and required hardware retest and inspection. Any disassembly will be kept to a minimum. The intent of the PCA is to confirm the drawings are sufficient to support the test stands after final delivery.

3.1.7. Provide tools or measurement devices required during the course of the PCA

3.2. PCA discrepancy records. Completed discrepancy sheets will be submitted to the Contractor for review at the end of each day. The Contractor is responsible for the correction of all discrepancies noted during PCA prior to PAT Report acceptance.

3.3. Failure Reporting. In the event of a failure during the performance of any testing specified herein, the Contractor shall prepare a written report noting the failure and corrective action to be taken. The initial notification shall be required within one working day via email to the FRCE contracting officer. A written report shall be submitted within fifteen (15) calendar days of the occurrence of any failure of the equipment.

3.4. Software Development Documentation. The contractor shall provide the following details items for all new software developed as a part of this project:

3.5. Detail Design Specification. The contractor shall include a Detail Design Specification (DDS).

3.5.1. The DDS shall contain the data called for by IEEE 1016-1987, Recommended Practice for Software Design Descriptions and IEEE 12207.0, paragraph 5.3.6. The DDS shall include a detailed description of Interfaces in accordance with IEEE 12207.0, paragraph 5.3.10. The DDS shall be documented in accordance with IEEE 12207.1 paragraph 6.16.

3.5.2. The Detail Design Specification shall include decomposition, dependency, interface, and detail descriptions.

3.5.3. The Detail Design Specification shall use hierarchical diagrams, structure charts, data flow diagrams, interface files, parameter tables and flowcharts for example representations.

3.6. Database Design Description. The contractor shall develop, maintain, and update a Database Design Description up to the approval of the DD250. The word database used in this section is a generic term. It includes text files, Excel files, and other data storage units.

3.6.1. Purpose. Describe the design of a database, that is, a collection of related data stored in one or more computerized files in a manner that can be accessed by users or computer programs via a database management system (DBMS). May also describe the software units used to access or manipulate the data. Used as the basis for implementing the database and related software units.

3.6.2. Content. The database design description should include:

3.6.2.1. Generic description information. This should include:

3.6.2.1.1. Date of issue and status

3.6.2.1.2. Scope

3.6.2.1.3. Issuing organization

3.6.2.1.4. References

3.6.2.1.5. Context

3.6.2.1.6. Notation for description

3.6.2.1.7. Body

3.6.2.1.8. Summary

3.6.2.1.9. Glossary

3.6.2.1.10. Change history

3.6.2.2. Database overview and identification;

3.6.2.3. Design of the database, including descriptions of applicable design levels (e.g., conceptual, internal, logical, physical).

3.6.2.4. Reference to design description of software used for database access or manipulation;

3.6.2.5. Rationale for database design.

3.6.3. Characteristics: The database design description should define types of errors that are not specified in the software requirements and the handling of those errors.

3.7. Software Design Description. The contractor shall develop, maintain, and update a Software Design Description up to the approval of the DD250.

3.7.1. Purpose: Describe the design of a software item. (The software design description and the software architecture provide the detailed design needed to implement the software.) May be supplemented by software item interface design and database design.

3.7.2. Content: The software item design description should include:

3.7.2.1. Generic description information. Describe a planned or actual function, design, performance, or process. A description should include:

3.7.2.1.1. Date of issue and status;

3.7.2.1.2. Scope;

3.7.2.1.3. Issuing organization;

3.7.2.1.4. References;

3.7.2.1.5. Context;

3.7.2.1.6. Notation for description;

3.7.2.1.7. Body;

3.7.2.1.8. Summary;

3.7.2.1.9. Glossary;

3.7.2.1.10. Change history.

3.7.2.2. Description of how the software item satisfies the software requirements, including algorithms and data structures;

3.7.2.3. Software item input/output description;

3.7.2.4. Static relationships of software units;

3.7.2.5. Concept of execution, including data flow and control flow;

3.7.2.6. Requirements traceability:

3.7.2.6.1. Software component-level requirements traceability;

3.7.2.6.2. Software unit-level requirements traceability.

3.7.2.7. Rationale for software item design;

3.7.2.8. Reuse element identification.

3.7.3. Characteristics: The software item design description should define types of errors that are not specified in the software requirements and the handling of those errors.

3.7.4. Interface Design Description. The contractor shall develop, maintain, and update a Software Interface Design Description up to the approval of the DD250.

3.7.4.1. Describe the interface characteristics of one or more system, subsystem, hardware item, software item, manual operation, or other system component. May describe any number of interfaces.

3.7.5. Content: The software item interface design description should include:

3.7.5.1. Generic description information. Describe a planned or actual function, design, performance, or process. A description should include:

3.7.5.1.1. Date of issue and status;

3.7.5.1.2. Scope;

3.7.5.1.3. Issuing organization;

3.7.5.1.4. References;

3.7.5.1.5. Context;

3.7.5.1.6. Notation for description;

3.7.5.1.7. Body;

3.7.5.1.8. Summary;

3.7.5.1.9. Glossary;

3.7.5.1.10. Change history.

3.7.5.2. External interface identification.

3.7.5.3. Software component identification.

3.7.5.4. Software unit identification.

3.7.5.5. External-software item interface definition (e.g., source language, diagrams);

3.7.5.6. Software item-software item interface definition (e.g., source language, diagrams);

3.7.5.7. Software component-software component interface definition (e.g., source language, diagrams).

3.7.6. Characteristics: The software item interface design description should define types of errors that are not specified in the software requirements and the handling of those errors.

3.8. System Requirements Specification. The contractor shall develop, maintain, and update a System Requirements Specification up to the approval of the DD250.

3.8.1. Purpose: Specify the requirements for a system or subsystem and the methods to be used to ensure that each requirement has been met. Used as the basis for design and qualification testing of a system or subsystem.

3.8.2. The system requirements specification should include:

3.8.2.1. Generic description information. Describe a planned or actual function, design, performance, or process. A description should include:

3.8.2.1.1. Date of issue and status;

3.8.2.1.2. Scope;

3.8.2.1.3. Issuing organization;

3.8.2.1.4. References;

3.8.2.1.5. Context;

3.8.2.1.6. Notation for description;

3.8.2.1.7. Body;

3.8.2.1.8. Summary;

3.8.2.1.9. Glossary;

3.8.2.1.10. Change history.

3.8.2.2. System identification and overview;

3.8.2.3. Required states and modes;

3.8.2.4. Requirements for the functions and performance of the system;

3.8.2.5. Business, organizational, and user requirements;

3.8.2.6. Safety, security, and privacy protection requirements;

3.8.2.7. Human-factors engineering (ergonomics) requirements;

3.8.2.8. Operations and maintenance requirements;

3.8.2.9. System external interface requirements;

3.8.2.10. System environmental requirements;

3.8.2.11. Design constraints and qualification requirements;

3.8.2.12. Computer resource requirements:

3.8.2.13. Computer hardware requirements;

3.8.2.14. Computer hardware resource requirements, including utilization requirements;

3.8.2.15. Computer software requirements;

3.8.2.16. Computer communications requirements.

3.8.2.17. System quality characteristics;

3.8.2.18. Internal data requirements;

3.8.2.19. Installation-dependent data requirements;

3.8.2.20. Physical requirements;

3.8.2.21. Personnel, training, and logistics requirements

3.8.2.22. Packaging requirements;

3.8.2.23. Precedence and criticality of requirements;

3.8.3. Rationale. For software that the contractor has developed previously, the system requirements specification shall include:

3.8.3.1. The contractor shall provide a copy of the procedures used during the software’s development if such procedures exist.

3.8.3.2. The contractor shall provide the documentation required by those procedures.