| 5.4-2-1 Ensure the software architecture is correct and complete |
Phase A |
Phase B |
Phase C |
|
Ensure the software architecture defines the communication mechanism between software items and constituent parts of software items (e.g. classes, Computer Software Components, etc.). If the architecture defines any interfaces to legacy, reuse, COTS, GOTS, Open Source or other NDI software items, Ensure those software items support the expected interfaces. Ensure contractor's software architecture will meet the software requirements as allocated to the software architecture components, including functional and non-functional (e.g. specialty engineering, computer resource margins, performance, etc.) requirements. Ensure the software architecture is suitable for the computer hardware selected. Ensure software architecture views are correct and consistent and fully represent the software architecture. Ensure the software architecture addresses all topics covered by the Software Architecture Description (SAD) content template. Ensure software architecture experts participate in software architecture peer reviews and software architecture meetings and reviews (e.g. SAR, the software architecture and requirements review, build-level software architecture reviews). In Phase A, the top level software architecture is examined to the SDR level of detail. In Phase B, the whole software architecture is examined. In Phase C a review of the software architecture changes since the Phase B is performed.
|
NA
|
Software Architecture Description (SAD)
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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; TOR-2007(8583)-6414, Technical Reviews and Audits for Systems, Equipment, and Computer Software Volume 1; TOR-2007(8583)-6414, Technical Reviews and Audits for Systems, Equipment, and Computer Software Volume 2
|
| 5.4-2-2 Ensure the bidirectional traceability from the software requirements to the software architecture elements is correct and complete |
Phase A |
Phase B |
Phase C |
|
Ensure each software architecture element maps to one or more software requirements (or is derived with adequate justification) . Ensure the correctness and completeness of the traceability among software requirements, architecture components, and design units. Ensure the correctness and completeness of traceability between software architecture elements and requirements. In Phase A, the top level software architecture bidirectional traceability is performed to the SDR level of detail. In Phase B, the whole software architecture bidirectional traceability is performed. In Phase C, review the bidirectional traceability for the software architecture changes since the Phase B.
|
NA
|
Configuration Item (Hardware, Software and Firmware) Requirements Specifications; Software Architecture Description (SAD)
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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-2-3 Ensure the ground enterprise software architecture is correct and complete |
Phase A |
Phase B |
Phase C |
|
Ensure the software system architecture defines the overall ground enterprise software architecture across the ground segment elements. Ensure the software architecture is consistent with the ground enterprise software architecture. In Phase A, ensure the software architecture is consistent with the ground enterprise system architecture. In subsequent Phases, ensure the ground enterprise software architecture flows into the individual software architectures for each ground segment element or subsystem, and that element architectures are consistent with enterprise software architecture in those areas that have changed.
|
NA
|
Software Architecture Description (SAD)
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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-2-4 Ensure the contractor's software architecture studies, modeling, simulation, prototypes, analyses, and trade studies used to make software architecture decisions and to validate the software architecture are correct and complete |
Phase A |
Phase B |
Phase C |
|
Ensure software architecture studies, modeling, simulations, prototypes, analyses, and trade studies are documented in enough detail to enable reproduction. Ensure results and data support the architecture decisions made. Ensure contractor architecture decisions are based on data from identified studies. In Phase A, the software architecture studies, et al are conducted to determine the best possible software architecture decision. In subsequent Phases, additional software architecture studies et al are conducted for any areas that have changed since Phase A.
|
NA
|
Cost / Design Trades and Analyses
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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-2-5 Ensure the software architecture development processes, methods, and tools are effective for the software under development, and ensure the contractor is following the processes |
Phase A |
Phase B |
Phase C |
|
Ensure the software architecture development processes is consistent with the system development process. Ensure the software architecture development processes, methods, and tools are defined, documented, effective, followed, and enforced. Ensure the software master build plan includes all updates to the software architecture. Ensure the correctness and completeness of the peer reviews of the software architecture. Ensure participation in contractor architecture peer reviews and other contractor reviews of software architecture. In Phase A, the proposed software architecture development processes, methods, and tools are reviewed for effectiveness and adherence to project standards. Also in Phase A, the effectiveness of the actual processes, methods, tools are examined and updated/improved as needed; and the development artifacts are reviewed for compliance with the processes. In Phase B, the processes, methods, and tools are evaluated for effectiveness and for continuous process improvement; the development artifacts are examined to ensure compliance with the processes. In Phase C, the software architecture change processes are reviewed for effectiveness, and the development artifacts are examined for compliance to the changed process.
|
NA
|
NA
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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-2-6 Ensure the software architecture integrates and is consistent with the system architecture |
Phase A |
Phase B |
Phase C |
|
Ensure the correctness and completeness of the traceability from the system architecture to the software architecture(s). Ensure the correctness and completeness of the software architecture elements in the Ground Segment architecture. Ensure the suitability of computer hardware selection to software architecture. Ensure the consistency of the change control process flowed down from the system architecture. Ensure the software architecture emphasizes same architecture attributes that are emphasized in the System Architecture (e.g. Architecture attributes are affordability, adaptability, resilience, scalability, etc. Ensure software personnel participate in system-level meetings and reviews where the system architecture is presented (e.g. SRR, SDR, System PDR, System CDR) to assess the correctness of the relationship of the software architecture to the system architecture.
|
NA
|
System/Segment Architecture Description; Software Architecture Description (SAD)
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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; TOR-2007(8583)-6414, Technical Reviews and Audits for Systems, Equipment, and Computer Software, Volume 1; TOR-2007(8583)-6414, Technical Reviews and Audits for Systems, Equipment, and Computer Software, Volume 2
|
| 5.4-2-7 Ensure the software architecture supports information assurance and cyber security principles |
Phase A |
Phase B |
Phase C |
|
Ensure the software architecture supports attack detection and attack recovery. Ensure the software architecture appropriately groups the software items and the constituent parts of the software items (e.g. classes, Computer Software Components, etc.) with consideration for the security aspects of the system. Ensure the software architecture is in compliance with all required DISA Application Security and Development Security Technical Implementation Guide (STIG) checklists for the program. Ensure the software architecture is in full compliance with all required DoD Information Assurance (IA) controls including DoD 8500.2 or DCID 6/3. Ensure the software architecture has a high assurance security design for cryptographic key management in the system. Ensure the software architecture supports clean separation of security functionality from application business functionality. Ensure trusted security components are easily identified and called out in the software architecture and all security Policy Decision Points (PDP) and Policy Enforcement Points (PEP) are clearly articulated in the architecture. Ensure the software architecture clearly delineates the areas that are 3rd party software code. Ensure IA/Cyber experts perform this analysis.
|
NA
|
Software Architecture Description (SAD)
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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-2-8 Ensure the software architecture supports the dependability requirements of the system |
Phase A |
Phase B |
Phase C |
|
Ensure the software architecture supports safety requirements. Ensure the software architecture supports reliability, maintainability, and availability (RMA) requirements. Ensure the software architecture provides redundancy for critical software elements. In Phase A, Ensure the software architecture addresses the safety and RMA requirements. In Phase B, Ensure the software architecture incorporates the entities that satisfy safety and RMA requirements. In Phase C, ensure the software architecture still satisfies the safety and RMA requirements especially in those areas that have changed since Phase B. In Phase D1, ensure the software architecture satisfies the safety and RMA requirements for those areas that have changed that occurred since Phase C. Ensure the existence of identifiable architecture components to manage failures in the systems. Verify that detection and recovery for all identified failure modes is addressed in the architecture. Ensure that failure rates, recovery times, and recovery probabilities have been allocated to the software components that will exist at runtime. Ensure that mechanisms for maintaining consistency of replicated state data are defined. Ensure that generic purchased software components (e.g., operating systems, computer communications) conform to architectural dependability allocations.
|
NA
|
Software Architecture Description (SAD)
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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; MIL-STD-1629A, "Procedures for Performing a Failure Mode, Effects and Criticality Analysis"; TOR-2008(1590)-7515, "Guideline for Conducting Failure Modes and Effects Analysis (FMEA) of Software Intensive Systems"
|
| 5.4-2-9 Ensure independent software architecture studies, modeling, simulation, analyses are performed to validate the contractor's software architecture will work, meet the requirements, and satisfy operational needs |
Phase A |
Phase B |
Phase C |
|
In Phase A, ensure the independent software architecture studies, modeling, simulation, and analyses are conducted to validate the contractor's top level software architecture decisions. In Phase B, additional independent software architecture studies, modeling, simulation, and analyses are conducted to validate the full software architecture. In Phase C, additional independent software architecture studies, modeling, simulation, and analyses are conducted for any areas that have changed since Phase B.
|
NA
|
NA
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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-2-10 Ensure an independent software architecture evaluation is performed |
Phase A |
Phase B |
Phase C |
|
Ensure an independent evaluation of the software system architecture that addresses the overall software system across ground segments or subsystems is performed. Tailor the criteria in the framework according to the objectives of the evaluation, the phase of the program, and the level of required mission assurance. Brief the results to the customer and the contractor. In Phase A, a top level independent software architecture evaluation is performed at the SDR level of detail. In Phase B, the independent architecture evaluation is performed. In Phase C, the independent architecture evaluation is performed on those areas that have changed since the Phase B independent software architecture evaluation. In Phase D1 the independent architecture evaluation is performed on those areas that have changed since the Phase C independent software architecture evaluation.
|
NA
|
NA
|
ATM-2012(9010-61)-2, Evaluating Software Architectures in Space and Ground Systems Revision 3; 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
|