Why do I need to worry about Software Safety? What does it mean? What will it get me in the long run?
The Department of Defense has many System Safety standards written to support embedded systems software development. Shouldn't the regulations be good enough? I recently tackled these issues in a study involving a DoD contract.
MIL-STD-882 has multiple versions released and is referred to when working with software safety. Other guidelines are listed in the references.
Having to refer to standards when developing a software system takes extra time and money. It would be so much easier to not have to refer to guidelines to make sure software followed the same guidelines from beginning to the end of a project or from one project to another. It also costs so much more to have to do this.
There have been multiple occasions that prove that if there was a systematic approach to developing system software, mistakes could be detected before, for instance, the pilot found out too late that there was not a fail safe setup for the engine that failed, or there were too many final checks for a fighter pilot to release a missile and it was too late. These type of examples show that if time and money was spent at Day 1 for a good safety software program, money and lives would be saved at the end of the project. It is important to take a long term view from the beginning. There must be some type of tracking system. The end user should have an active voice in the decisions. All players including the system engineer, the hardware engineer and the software engineer should be involved from the beginning throughout the life time of the project. It is unrealistic to expect a software engineer to walk in after a project has been in the works for years and ask them to figure out what the problem is with the code. This a very costly way of doing business. The software engineer must do, essentially years of research to discover what was previously done, in a few months and then give an educated guess as to what the problem might be.
THE STUDY
It was the goal of this study to develop a basic checklist that could be used by software safety engineers to use from the beginning, throughout the life cycle, and throughout deployment of a project.
A good Safety Program must be in place on Day 1. This includes doing requirements and design before starting to code. It is important to take a long term view from the beginning. There must be some type of tracking system.
The checklists have been developed mainly from MIL-STD-882D. They are set up to be used individually or in a combination. The checklists should be selected according to the type of work being done. A list of the checklists follows. Select the corresponding the lists and follow the guidelines for each to make sure each item has been included in each particular project.
| GENERAL SECTION 100 | PROGRAM MANAGEMENT AND CONTROL |
| Task 101 | SYSTEM SAFETY PROGRAM |
| Task 102, DI-SAFT-80100A | SYSTEM SAFETY PROGRAM PLAN |
| Task 103 | INTEGRATION/MANAGEMENT OF ASSOCIATE CONTRACTORS, SUBCONTRACTORS, AND ARCHITECT AND ENGINEERING FIRMS |
| Task 104 | SYSTEM SAFETY PROGRAM REVIEWS/AUDITS |
| Task 105 | SYSTEM SAFETY GROUP/SYSTEM SAFETY WORKING GROUP SUPPORT |
| Task 106 | HAZARD TRACKING AND RISK RESOLUTION |
| DI-SAFT-80105A | SYSTEM SAFETY PROGRAM REPORT (SSPPR) (refer to Task 106 or Task 107) |
| Task 107 | SYSTEM SAFETY PROGRESS SUMMARY |
| Task 108 | LAUNCH SAFETY PROGRAM REQUIREMENTS |
| GENERAL SECTION 200 | DESIGN AND INTEGRATION |
| Task 201 | PRELIMINARY HAZARD LIST |
| Task 202 | PRELIMINARY HAZARD ANALYSIS |
| DI-SAFT-80101A | System Safety Hazard Analysis Report (SSHA) (Refer to Task 201, 203, 204, 205 or 206) |
| Task 203 | SAFETY REQUIREMENTS/CRITERIA ANALYSIS |
| Task 204 | SUBSYSTEM HAZARD ANALYSIS |
| Task 205 | SYSTEM HAZARD ANALYSIS |
| Task 206 | OPERATING AND SUPPORT HAZARD ANALYSIS |
| Task 207 | HEALTH HAZARD ASSESSMENT |
| DI-SAFT-80106A | HEALTH HAZARD ASSESSMENT Report (HHAR), (refer to Task 207) |
| GENERAL SECTION 300 | DESIGN EVALUATION |
| Task 301 | SAFETY ASSESSMENT |
| Task 302 | TEST AND EVALUATION SAFETY |
| Task 303 | SAFETY REVIEW OF ENGINEERING CHANGE PROPOSALS, SPECIFICATION CHANGE NOTICES, SOFTWARE PROBLEM REPORTS, AND REQUESTS FOR DEVIATION/WAIVER |
| DI-SAFT-80103A | ENGINEERING CHANGE PROPOSAL SYSTEM SAFETY REPORT (ECPSSR) (refer to Task 303) |
| DI-SAFT-80104A | WAIVER OR DEVIATION SYSTEM SAFETY REPORT (WDSSR) (refer to Task 303) |
| GENERAL SECTION 400 | COMPLIANCE AND VERIFICATION |
| Task 401 | SAFETY VERIFICATION |
| Task 402 | SAFETY COMPLIANCE ASSESSMENT |
| Task 403 | EXPLOSIVE HAZARD CLASSIFICATION AND CHARACTERISTICS DATA |
| Task 404 | EXPLOSIVE ORDNANCE DISPOSAL SOURCE DATA |
| DI-SAFT-80102A | SAFETY ASSESSMENT REPORT (SAR) (refer to Task 301, 401 or 402) |
SUMMARY and CONCLUSIONS
This checklist should provide a better understanding of the safety process. It will provide the ability to determine where in the life-cycle an error occurred. Using a tracking system, previous projects can provide information for new safety projects and intelligent decisions can be made from past experiences.
References:
U.S. Department of Defense (DoD),Standard Practice for System Safety Program Requirements, MIL-STD-882D, 19 Jan 96
DoD, System Safety Program Plan, DI-SAFT-80100A, 19 Jan 93
DoD, System Safety Hazard Analysis Report, DI-SAFT-80101A, 19 Jan 93
DoD, Safety Assessment Report, DI-SAFT-80102A, 19 Jan 93
DoD, Engineering Change Proposal System Safety Report, DI-SAFT-80103A, 19 Jan 93
DoD, Waiver or Deviation System Safety Report, DI-SAFT-80104A, 19 Jan 93
DoD, System Safety Program Progress Report, DI-SAFT-80105A, 19 Jan 93
DoD, Health Hazard Assessment Report, DI-SAFT-80106A, 19 Jan 93
Computer & Concepts, "Software Program Managers' Network" Seminar, 17-18 Oct 93
Author's Biography
Connie Clayton has been in the software engineering arena for over 18 years. She is currently a senior engineer with Science Applications International Corporation. Her work includes support a large software effort for the Army. Work includes software engineering, reuse, reengineering, CASE tools, metrics and cost analysis, and post deployment software support. She has multiple degrees including a Master of Science in Computer Science and a Doctorate in Engineering Management.
Last modified on Thursday, July 16, 1998 | Society for Software Quality | http://www.ssq.org/ |