Software Assurance
Software fails differently from hardware: silently, completely, and identically on every copy. This page states how software rigor is set, how safety-critical behavior is proven, and who checks the work of the people who wrote it.
Classification Drives Rigor
Not all software deserves the same process, and pretending otherwise produces either wasted effort or unmanaged risk. Software is classified by the consequence of its failure, and the required engineering and assurance activities follow the class.
- Classification performed early using NASA's software classification framework and recorded with rationale
- Safety-criticality determined separately from class, based on hazard analysis rather than on subsystem name
- Required engineering and assurance activities selected from the class, with any tailoring approved by the technical authority
- Reclassification triggered when scope, interfaces, or hazard exposure change
- Acquired, reused, open-source, and auto-generated software classified and assessed on the same basis as new development
Software Safety
Software safety is not a code review topic. It is a traceable chain from an identified hazard, through the control that mitigates it, to the test that proves the control works.
- Hazard analysis identifying software's contribution to system hazards, including failure to act
- Safety-critical requirements identified, traced, and protected from silent change
- Fault detection, isolation, and recovery behavior specified rather than emergent
- Off-nominal, boundary, and fault-injection testing planned for safety-critical paths
- Independent verification and validation supported where the program or the customer requires it
Engineering Practice
Assurance is cheapest when it is built into how software is written. The practices below are institutional defaults, applied proportionately to class.
- Coding standards defined per language, with automated static analysis in the build pipeline
- Peer review required before merge, with reviewer independence from the author
- Version control, branch policy, and build reproducibility such that any delivered binary can be rebuilt from a tagged source state
- Unit, integration, and regression test coverage tracked against a defined expectation per class
- Requirements-to-code-to-test traceability maintained rather than reconstructed at delivery
- Cybersecurity practice applied to development environments and toolchains, including dependency and supply chain scanning
Independent Assessment
The assurance judgment on software cannot belong to the people delivering it. Independence is defined by reporting line and by access, not by title.
- Software assurance personnel report outside the development organization
- Process audits verifying that the practices claimed are the practices performed
- Product assessment of requirements, design artifacts, code, and test evidence at defined milestones
- Software problem reports tracked with severity, disposition, and verification of closure
- Metrics reviewed with leadership: defect density trend, open critical defects, coverage, and requirement volatility
Configuration, Release and Sustainment
Software does not end at delivery. Release is a controlled event and sustainment is a planned obligation rather than an unfunded one.
- Software configuration items identified with version, build environment, and dependency manifest
- Change control through the configuration control board for baselined software
- Release records including test evidence, known defects, and operating constraints
- Delivered software accompanied by version description information the customer can act on
- Sustainment plan addressing defect response, dependency currency, obsolescence, and security patching
Where This Connects
Software assurance connects to data governance and AI oversight, the cybersecurity posture, AI governance, and the technical competency model, which defines the qualification behind the review signature.
Alignment Disclosure
Monarch Space Systems describes its systems engineering and mission assurance practices as aligned with the cited NASA directives, military and consensus standards, and industry specifications. Alignment is not a certification. The institution does not claim a NASA-approved systems engineering process, a CMMI appraisal result, an AS9100 registration, flight heritage, or any specific mission, article, or qualification outcome. Program-specific analyses, test data, and review products are contract-controlled and are not published.
Policy documentation, procedures, and control descriptions are available to customers and prospective teammates through the confidential engagement pathway or by request through institutional contact.