| 5.4-3-1 Ensure the software design is correct and complete |
Phase B |
Phase C |
|
Ensure the software design includes design of the software interfaces, and addresses all categories of software, including legacy, reuse, open source, COTS, GOTS, or other NDI software products. Ensure the software design is consistent with the software architecture and is an extension of the software architecture. Ensure the software design has been defined to the standards and level of detail and completeness as specified in the Software Development Plan. Ensure the methods used to validate the design included normal and stressing loads as well as nominal and off-nominal scenarios. Ensure the results or products of the trades or engineering analyses, together with the system and software design and selected computer resources, demonstrate that the software design will meet key performance parameters and driving requirements. Ensure software technology called for by the software design is sufficiently mature (i.e. must be at TRL level 6 by the end of Phase B). Ensure Human-Computer interface design is correct, complete, and usable by the operators (users) (i.e. meets operability and usability requirements and meets user's needs). Ensure the correctness and completeness of the I/F design. Ensure the suitability of computer hardware selection to software design.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-2 Ensure the software design documentation is correct and complete |
Phase A |
Phase B |
Phase C |
|
Ensure the software design documentation complies with the contracted requirements. Ensure the documentation follows the standards/guidelines set forth for the project (e.g. use UML to document design if project calls for using UML). Ensure the documentation identifies all the software items and constituent parts of software items (e.g. classes, Computer Software Components, etc.). Ensure all required documentation is included (e.g. SAD, SDD, IDD, DBDD, etc.). In Phase A, top level draft design documentation should be available. In Phase B, the draft design documentation should be available. In Phase C, the detailed design documentation should be finalized.
|
NA
|
Design Review Data Package
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-3 Ensure the bidirectional traceability from the software requirements to the software design and from the software design to the source code is correct and complete |
Phase B |
Phase C |
Phase D1 |
|
Ensure each software requirement is correctly traced to one or more software design elements and that each software design element is correctly traced to one or more software requirements (or is derived with adequate justification). Ensure each software design element is correctly traced to one or more code element(s) and that each code element is correctly traced to one or more design elements. Ensure all software requirements are mapped to software design elements, including software interface requirements and both functional and non-functional requirements. Non-functional requirements include reliability, maintainability, and availability; performance (e.g. timing, accuracies), capacity (e.g. number of concurrent users, number of satellites, number of target types, and number of concurrent tracks), and computer resource margins. In Phase C, the bidirectional traceability between the software requirements and the software detailed design elements is complete. Also in Phase C, each software design element is traced to one or more code units. In Phase D1, each code unit is traced to one or more software design elements; and the bidirectional traceability between the requirements and the design is updated for any changes that occurred since Phase C.
|
NA
|
System/Segment Specification (SSS); Segment Design Specification; Configuration Item (Hardware, Software and Firmware) Requirements Specifications; Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-4 Ensure the software design has robust fault management design, including fault identification, data capture, fault containment, and recovery mechanisms |
Phase B |
Phase C |
Phase D1 |
|
Ensure the software design includes fault identification and recovery. Ensure the software design includes a mechanism to capture data when a fault occurs. Ensure the fault management CONOPS and analysis includes protection against cascading failures. Ensure the fault management architecture is consistent with the software architecture. Ensure the detection/recovery durations meet the operational availability requirements. Ensure the fault containment boundaries are explicitly and unambiguously defined. Ensure the correctness of the analysis used to determine the possible failures. Ensure these failures cannot be spoofed. Review the analysis of any legacy, reuse, open source, COTS, GOTS, or other NDI software products for fault management considerations. Ensure the fault management includes any legacy, reuse, open source, COTS, GOTS, or other NDI software products being used.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment; SMC-S-013, Reliability Program for Space Systems, 13 June 2008 (also published as TOR-2007(8583)-6889 under same title) or equivalent
|
| 5.4-3-5 Ensure the software design is resistant to cyber attacks |
Phase B |
Phase C |
Phase D1 |
|
Ensure the use of legacy, reuse, open source, COTS, GOTS, or other NDI software products are evaluated for cyber vulnerabilities and the risks and risk mitigations are documented. Ensure the software design supports attack detection and attack recovery. Ensure the software design fully supports the system design information assurance strategies and policies including DoD Net-Centric and IA strategies. Ensure the software design is in compliance with the security level of the system design. Ensure the software design supports the system level cyber/information assurance/security requirements. The software should be designed to the same security level as the system security level; if the system is at the mandatory protection criteria level then the software needs to be at the mandatory protection criteria level. Ensure the pedigree of any legacy, reuse, open source, COTS, GOTS, or other NDI software products used in the software design. Ensure the software supports any system level anti-tamper and anti-spoof requirements.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment; DoD Directive 8500.2, Information Assurance (IA) Implementation, February 6, 2003; DCID 6/3, Protecting Sensitive Compartmented Information within Information Systems, June 5, 1999; TOR-2007(8583)-6702, Information Assurance Handbook for DOD Space Systems: Guidance on Application of 8500.1/8500.2 IA Controls; DISA Application Security and Development Security Technical Implementation Guide October 28, 2011
|
| 5.4-3-6 Ensure the software design processes, methods, and tools are defined, documented, effective, followed, and enforced |
Phase B |
Phase C |
Phase D1 |
|
Ensure the software design process follows the software development process as described in the Software Development Plan. Ensure the tools are consistent with the software design methodology (structured design requires use of structured design tools; object-oriented design requires the use of object-oriented tools). Ensure the correctness and completeness of the software design peer reviews and software design peer review process. All peer review discrepancies should be tracked to resolution. All fixes for discrepancies should be reviewed. Ensure the correctness and completeness of the software problem reporting and tracking system used during the software design phase. Ensure software technology called for by the software processes, methods and tools is sufficiently mature (i.e. must be at TRL level 6 by the end of Phase B).
|
NA
|
NA
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-7 Ensure the software design is validated by independent modeling, simulation, prototypes, and other analyses to demonstrate the design will work, meet requirements, especially performance requirements, and satisfy operational needs |
Phase A |
Phase B |
Phase C |
Phase D1 |
|
Ensure the independent modeling, simulation, prototypes, and other analyses includes normal and stressing loads as well as nominal and off-nominal scenarios. Review mission-critical software performance to determine risk involved in meeting mission performance requirements. Compare and document results against contractor's results. Ensure software technologies are mature via an independent software technology assessment. Ensure software design meets dependability requirements via independent reliability/maintainability/availability modeling and analysis. Ensure complete analysis and prototyping supports the choice of the software development tools. Ensure the software design will satisfy operability/usability requirements and meet the user's needs, especially the Human-Computer interface (i.e. the design needs to support the user's CONOPS). Ensure analysis and prototyping supports the software design for the low level areas of the software design (drivers, OS, etc.). If the development computer system is different from the target, then prototypes should be run on the actual target to make sure design will work on the target.
|
NA
|
NA
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-8 Ensure the software design satisfies the software safety requirements and operational needs |
Phase B |
Phase C |
Phase D1 |
|
Ensure the software design satisfies the software safety requirements. Ensure software is appropriately incorporated into the system safety analyses. Ensure the software design meets the system level safety levels. Software design should be to the same level as the system design safety level; e.g. if the system is to be FAA certifiable then the software needs to be FAA DO-178B certifiable. Ensure the software design meets safety requirements via an independent safety analysis (e.g. fault tree analysis, failure modes, and effects analysis). Ensure the software design is in compliance with the safety level. In Phase B, the safety analysis is performed on the software design. For iterative life-cycle models, the software design can continue through Phases C and D1 and, in that case, the software safety analysis is performed in Phases C and D1.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-9 Ensure the system design includes software and the software design is consistent with the system design |
Phase B |
Phase C |
Phase D1 |
|
Ensure the software design is consistent with the system design. Ensure the completeness of the contractor's software participation in Ground Segment SDR, PDR, CDR, and other high level design reviews. Ensure the interfaces in the system design include software. Ensure Human-Computer interface design is consistent with the system operational concepts. In Phase A, Ensure the system design includes the software. In Phases B, C, and D1, ensure the software detailed design is consistent with the system design and with the software architecture.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-10 Ensure use of legacy, reuse, open source, COTS, GOTS, or other NDI software products is justified for technical reasons |
Phase B |
Phase C |
Phase D1 |
|
Ensure the justification for the use of any legacy/reuse/COTS/GOTS/open source/other NDI software products in the software design is documented, complete, kept up to date, and contains sufficient detail. Ensure the legacy, reuse, open source, COTS, GOTS, or other NDI software products have a track record for dependability.
|
NA
|
Cost / Design Trades and Analyses; Design Review Data Package
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment; SMC-S-013, Reliability Program for Space Systems, 13 June 2008 (also published as TOR-2007(8583)-6889 under same title) or equivalent; AFOTEC pamphlet 99-102, Volume 6. "Software Maturity Evaluation Guide," HQ Air Force Operational Test and Evaluation Center, 1 March 1996 or equivalent.
|
| 5.4-3-11 Ensure the database design is correct and complete |
Phase B |
Phase C |
Phase D1 |
|
Ensure the database design description is documented and describes a complete and feasible design. Ensure the database design supports the software architecture and software design. Ensure the database design is defined to the standards and level of completeness called for in the Software Development Plan. Ensure the database design includes database-level access control policies that support the information assurance and security requirements. Ensure the database design protects and sanitizes database inputs to prevent unintended consequences. Allowing certain SQL strings can erase whole tables or the whole database.
|
NA
|
Database Design Description (DBDD)
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment
|
| 5.4-3-12 Ensure the software design satisfies the software dependability requirements |
Phase B |
Phase C |
Phase D1 |
|
Ensure detailed design conforms to top level design features and to requirements for failure detection and recovery. Ensure software integrated into subsystems conforms to expected failure and recovery behavior. Ensure requirements for failure rates, failure detection, and recovery are derived as lower level design details are defined. Ensure fault containment boundaries are explicitly and unambiguously defined, and the failure containment mechanisms at these boundaries are dependable. Ensure protocols for processor health messages, heartbeats, and network traffic account for steady state and failure conditions are defined. Ensure telemetry available for vehicle state of health reporting is defined. Ensure commands for vehicle control, recovery, and reconfiguration are defined. Ensure design standards exist to enforce architectural provisions for failure containment, failure detection, and recovery (including interfaces, data types, exception handling, input and output validation). In Phase 0, the system dependability analyses are evaluated for applicability to the software. In Phase A, the analysis is performed on any existing software products (legacy, reuse, open source, COTS, GOTS, or other NDI software) that are being considered as part of the software design. In Phase B, the analysis is performed on the software design. For iterative life-cycle models, the software design can continue through Phases C and D1 and, in that case, the software dependability analysis is performed in Phases C and D1; and in Phases D2 and D3, is redone for areas that have changed since D1.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Requirements Specifications; Configuration Item (Hardware, Software and Firmware) Design Specifications
|
TOR-2004(3909)-3537B,Software Development Standard for Space Systems; TOR-2006(8506)-5749, Mission Assurance Tasks for Software; Mission Assurance Guide, TOR-2007(8546)-6018, Rev B, Software Mission Assurance Chapter; TOR-2011(8591)-20, Space Segment Software Readiness Assessment; SMC-S-013, Reliability Program for Space Systems, 13 June 2008 (also published as TOR-2007(8583)-6889 under same title) or equivalent
|
| 5.4-3-13 Ensure algorithms specified by contractor systems engineers or algorithm developers are clearly and completely specified, contain all information needed to be implemented in software, and are documented and controlled |
Phase B |
Phase C |
Phase D1 |
|
Ensure the algorithms specified by systems engineers and algorithm developers for implementation in software are: a) clearly and completely specified, b) documented in an algorithm design document (or similar), and c) controlled by configuration management. Ensure the algorithms address both nominal and off-nominal conditions, reflect a thorough understanding of the required functionality, and are consistent with the system behavior and performance requirements. Ensure the algorithm documentation contains all information needed in order to be implemented in software. Ensure the algorithm documentation includes criteria for determining the correctness of the software implementation (e.g., truth values for specific scenarios with acceptable limits on deviation from truth). Document any deficiencies found throughout the life cycle.
|
NA
|
Algorithm Requirements/Design Documentation
|
TOR-2004(3909)-3537 SW Development Standard for Space Systems; TOR-2011(8591)-20 Space Segment SW Readiness Assessment; CMMI for Development, Version 1.3. Technical Report CMU/SEI-2010-TR-033, Pittsburgh: Carnegie Mellon University, 2010.
|
| 5.4-3-14 Ensure correctness and completeness of the software design and implementation of the algorithms specified by systems engineers and algorithm developers |
Phase B |
Phase C |
Phase D1 |
|
Ensure the software design documentation reflects a thorough understanding of the algorithm design document. Ensure the software as implemented meets the requirements of the algorithms without being overly complicated. Ensure the software unit and integration testing results show that the software implementation of the algorithms obtains the correct results for nominal and off-nominal conditions and meet timing and accuracy requirements. Also, Ensure for the scenarios specified in the algorithm documentation, the software test results are within the allowed deviation from the documented truth value. During Phases A and B, critical algorithms and algorithms involving immature technology should be prototyped in a target hardware-like environment. Document any deficiencies found throughout the life cycle.
|
NA
|
Algorithm Requirements/Design Documentation
|
TOR-2004(3909)-3537 SW Development Standard for Space Systems; TOR-2011(8591)-20 Space Segment SW Readiness Assessment; CMMI for Development, Version 1.3. Technical Report CMU/SEI-2010-TR-033, Pittsburgh: Carnegie Mellon University, 2010.
|
| 5.4-3-15 Ensure correctness and completeness of the software design and implementation of software algorithms specified by the software engineers |
Phase B |
Phase C |
Phase D1 |
|
Ensure the software algorithms specified by the software engineers are correctly designed and implemented in code. Ensure the software unit and integration testing results show that the software implementation of the algorithms obtain the correct results for nominal and off-nominal conditions and meet timing and accuracy requirements. During Phases A and B, critical algorithms and algorithms involving immature technology should be prototyped in a target hardware-like environment. Document any deficiencies found throughout the life cycle.
|
NA
|
Algorithm Requirements/Design Documentation
|
TOR-2004(3909)-3537 SW Development Standard for Space Systems; TOR-2011(8591)-20 Space Segment SW Readiness Assessment; CMMI for Development, Version 1.3. Technical Report CMU/SEI-2010-TR-033, Pittsburgh: Carnegie Mellon University, 2010.
|
| 5.4-3-16 Ensure an independent assessment of the algorithm design and implementation is performed as needed |
Phase B |
Phase C |
Phase D1 |
|
Ensure an independent assessment involves assessing the design and code, performing modeling or simulation of the algorithms, independent testing of the algorithm code, or similar analyses. The independent assessment should focus on critical algorithms, algorithms involving immature technology, and algorithms essential to mission success. Document any deficiencies found throughout the life cycle.
|
NA
|
Algorithm Requirements/Design Documentation
|
TOR-2004(3909)-3537 SW Development Standard for Space Systems; TOR-2011(8591)-20 Space Segment SW Readiness Assessment; CMMI for Development, Version 1.3. Technical Report CMU/SEI-2010-TR-033, Pittsburgh: Carnegie Mellon University, 2010.
|