|
NASA Software Safety Risk Metrics Initiative
|
|
Point of Contact
|
Victor Basili
basili@fc-md.umd.edu
|
|
Dates
|
October 2008 - October 2011
|
|
Problem
|
Safety accidents have the potential to severely impact NASA. Unsafe systems put human lives at risk and may even cause death. Unsafe systems affect the integrity of NASA and the confidence Congress and the American public have in the space programs. The purpose of the system safety process is to identify and mitigate hazards associated with the operation and maintenance of a system under development. System safety at NASA is implemented through an approach that identifies hazards and defines actions that will mitigate those hazards and verify that the mitigations have been implemented. The residual risk is that risk remaining when a hazard can not be completely mitigated. The goal of the system safety process is to reduce this residual risk to an acceptable level as defined by the safety certifier. Cost is a consideration in determining the level of acceptable residual risk.
As software contributes an ever-increasing level of functionality and control in today?s systems, a software-specific safety process becomes crucial. Software can contribute to system safety as both a hazard source and a hazard mitigation. While software is not intrinsically hazardous, it may cause hardware to perform unsafe actions or direct an operator to perform unsafe actions or make unsafe decisions. Additionally, software can be used to mitigate hazards caused by hardware, for example.
Software safety must be built into systems during the early phases of the lifecycle. Hazard mitigations typically affect system and software requirements and design; therefore, making these decisions late in the system development lifecycle may case significant schedule and cost overruns or may not be technically feasible.
In response to this concern for software safety, NASA has developed a very sophisticated and robust software safety standard NASA-STD-8719.13B and NASA-GB-8719.13-SW Safety Guidebook. Training is currently underway to ensure key NASA software development teams are educated in the safety assurance processes. This is a large task. Even assuming the majority of computing system development, assurance, and management personnel could be trained in the near term, applying the standard is no easy task. Many of the computing system personnel across the Constellation Program come from multiple NASA Centers and different contracting organizations. As such, personnel from different locations with different cultures, backgrounds, and experiences will have varying interpretations of how to meet the software safety requirements.
Solving the problem of evaluating how to effectively implement software safety requirements is important because software safety is a major concern for NASA. As space systems rely more on software and computing systems, the potential for software-related failures increases. And, as many personnel are new to incorporating the appropriate level of software involvement in potential system failures, assessing how that work is being done and finding areas for improvement are essential.
|
|
Objective
|
Our research goals for this proposal are:
A. Tailor the software-safety measurement approach we have applied in the past for a Department of Defense complex system of systems for NASA specifically, by tailoring the activities to be performed and identifying the artifacts and other information to be measured in accordance with NASA software safety standards, project goals, and target areas of interest.
B. Specify a set of measures for NASA that provides visibility into the implementation of the NASA software safety standard and guidelines. Collect and analyze measurement data and provide relevant feedback to appropriate stakeholders, such as project management, safety assurance, systems engineering, and computing system development personnel.
C. Develop an ?Experience Base? that will support decision making, provide visibility into the software safety process for multiple stakeholders, e.g., computing system development, assurance, and management personnel, project, program, headquarters, and process improvement groups, and identify implementation practices (good and not as good) for implementing the guidelines.
|
|
Results
|
No results are available at this time. Please check back again.
|
|
Keywords
|
Software safety assurance, software safety measures, software safety standards and guides, hazard tracking tools, software safety process visibility, dashboard tools
|
|
Categories
|
Software Safety
|
|
