Job98456


 
HomeCalendarFAQSearchRegisterMemberlistUsergroupsLog in

Share | 
 

 A Checklist for Software Safety

Go down 
AuthorMessage
raj_mmm9



Number of posts : 1850
Age : 55
Registration date : 2008-03-08

PostSubject: A Checklist for Software Safety   Fri 11 Apr - 15:11

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)
Back to top Go down
View user profile
 
A Checklist for Software Safety
Back to top 
Page 1 of 1
 Similar topics
-
» Need help with IMX Software
» CDAX software dilemma
» Scan Products gets ISO certification for Food Safety and Quality
» Colombo Crimes Division raids banking firm for software piracy
» CSE related software

Permissions in this forum:You cannot reply to topics in this forum
Job98456 :: General Software-
Jump to: