Codifying Software Safety Practices at the Architectural Level (abstract)

Points:

• Substantial practice exists in both process and products for software safety. Examples include DO-178b (commercial avionics), Mil-Std 882d (weapon system safety), Nuclear Regulatory Commission, Food and Drug Administration, British MoD 00-55, etc.
• There's a clear pattern in these documents. They start "hazard analysis", a statement of what can go wrong and the consequences thereof. They also support a 'multi-level' approach, where some hazards are much more 'nasty' than others, and deserve more attention.
• Hazards derive from system requirements, from the environment/context of the system and from design decisions of the system itself. Many such design decisions can have substantial architectural impact. For example, a rollercoaster can be designed to stop immediately if it detects an unsafe condition. This is not a good design approach for an aircraft, however :-)
• In 1471 terms:
  Stakeholders include: End users (who get killed if the system fails :-), acquisition people (cost of safety certification MAJOR ISSUE), hw/sw/system designers, testers (part of the problem with most safety statements is that you have to show/prove that the system does NOT do something, which is a lot harder...)
  Concerns include: Hazards and hazard levels, cost of meeting given hazard at given criticality level, ability to use/reuse COTS, processes for accounting for an verifying that a given hazard has been mitigated.
  Viewpoint would include:
  • Safety framework (what approach is being used, what levels are there, etc?)
  • Hazard analysis: Lists of hazards and associated hazard level
  • Hazard mitigations: How to mitigate a each hazard at its stated level
  • Test and other Process activities used for each level
  • probably other good stuff that I haven't thought of yet :-)