The independent assessment is performed by the Center's S&MA organization's software assurance personnel. This assessment is independent of the classification performed by the project.
The project and software assurance each document their own initial analyses, reasons and assessments and document it within their own systems and records. The final consensus software classification between the project and the independent Center S&MA personnel is recorded in the project documentation.
For the preliminary assessment, which is based on high-level project goals and systems functions, the role software will have is based on the expected roles and responsibilities of the software to aid in performing the system functions. At best, the preliminary software classifications will be based on the overall functions and the consensus software classifications are recorded in a document, such as a preliminary Systems Requirements document.
As system requirements evolve into software requirements and the Software Development/Management Plan takes shape, both the Software Development/Management Plan and the Software Assurance Plan (if separate) contain the consensus software classification.
Once there is more specificity about a sub-system and the possible computer software configuration item (CSCI), typically known by the Preliminary Design Review (PDR), both the project software engineering and the Center S&MA assurance personnel need to assess and reach consensus on the classification of each CSCI. Again, each organization performs and documents their own assessments and the consensus classifications get documented and signed off in the project documents; at this point, the design documents may be used to capture the consensus classifications for the CSCIs or the Software Development/Management Plan(s) can be updated. The intent is to document the agreed-upon software classification based on where it is most useful to the project in order to properly plan and execute the necessary processes and requirements that apply to the CSCIs. In fact, if there is not a lot of volatility, the classification and safety criticality could be documented in both places, though this has the obvious issue of maintenance consistency.
The level of CSCIs a project decides on determines the level and number of software classification assessments that need to be performed. At a minimum, there is an assessment for each system and sub-system containing software.
SMA software assurance personnel and the software engineers might need to work together to understand and work out the software classifications for new and novel software or approaches to software development, including, but not limited to:
- Development approaches new to NASA.
- Approaches new to the software industry, such as new software design approaches.
- Innovative software, such as software that employs new ways of dividing up functionality, perhaps to support an experiment.
NASA-STD-8739.8, NASA Software Assurance Standard, contains more details on the software assurance approach to software classification and how it is used to determine the level of effort for software assurance on a project. A software assessment sheet used to capture the software classification can be found in Appendix A of the Standard.
Additional guidance related to classifying software may be found in the following related requirement in this Handbook: