Showing posts with label Software Assurance. Show all posts
Showing posts with label Software Assurance. Show all posts

Friday, August 30, 2013

NASA's first-ever Software Engineering Handbook (SWEHB) released to the public

After years in the making, NASA has now released to the public their first-ever Software Engineering Handbook (SWEHB); NASA-HDBK-2203 (2013-02-28).

YouTube video showing how a person can navigate through the NASA Software Engineering Handbook to find software engineering related information. This video is about ten minutes long and can be used as a good training or awareness tool.

Each section of the SWEHB provides six areas of information per entry: the requirement, its rationale, guidance for implementation, notes for small projects, associated resources, and related lessons learned.

The 135 software engineering requirements for NASA projects are listed in a small, blue booklet, seventy pages long, called NASA Procedural Requirement (NPR) 7150.2 AKA NASA Software Engineering Requirements; View all pages in PDF. The new handbook is "A sort of hitchhiker's guide to the NPR". The handbook does not impose additional requirements; it is meant to be an assist.

Haley Stephenson explains how the SWEHB was developed as a collaborative Wiki in The Hitchhiker's Guide to Software Engineering at NASA. Many mangers do not seem to appreciate the value of using something like Dokuwiki to collaborate and document the development of a project. Without such documentation, years later, we are left to wonder "why did we use the red widget, rather than the better blue widget?". Perhaps they are afraid of Federal Rule of Civil Procedure Rule 26; Duty to Disclose; General Provisions Governing Discovery? See also Michael Barr's Dead Code, the Law, and Unintended Consequences.

Always keep in mind that Software never works in isolation. Safe Software is useless if the system as a whole is not safe. To that end make sure that NASA Systems Engineering Handbook (in PDF here) has a place on your desk or bookcase.

Related Documents:

Sunday, January 9, 2011

What is Requirement Traceability?

Last week Simula Research Laboratory released A SysML-Based Approach to Traceability Management and Design Slicing in Support of Safety Certification: Framework, Tool Support, and Case Studies.

Abstract:

Context: "Traceability is one of the basic tenets of all software safety standards and a key prerequisite for certification of software. Despite this, the safety-critical software industry is still suffering from a chronic lack of guidelines on traceability. An acute traceability problem that we have identified through observing software safety certification processes has to do with the link between safety requirements and software design. In the current state of practice, this link often lacks sufficient detail to support the systematic inspections conducted by the certifiers of the software safety documentation. As a result, the suppliers often have to remedy the traceability gaps after the fact which can be very expensive and the outcome often is far from satisfactory. Objective: The objective of this article is developing a framework to enable systematic and efficient software design inspections during safety certification. In particular, the framework enables safety engineers and certifiers to extract design slices (model fragments) that filter out irrelevant details but keep enough context information for the slices to be easy to inspect and understand. This helps reduce cognitive load and thus makes it less likely that serious safety issues would be overlooked. Method: Our framework is grounded on SysML which is rapidly becoming the notation of choice for developing safety-critical systems. The framework includes a traceability information model, a methodology to establish traceability, and mechanisms to use traceability for extracting slices of models relevant to a particular safety requirement. The framework is implemented in a tool, named SafeSlice, that supports establishing the traceability links envisaged by the methodology, automated consistency checking of these links, and automated generation of SysML design slices. Results: We provide a formal proof that our slicing algorithm is sound for temporal safety properties, and argue about the completeness of the slices based on our practical experience. We report on the lessons learned from applying our approach to two case studies, one benchmark case and one industrial case. Both case studies indicate that our approach offers benefits by substantially reducing the amount of information that needs to be inspected in order to ensure that a given safety requirement is met by the design."

The paper gives detailed analysis of the theory of traceability, worth your time to read, to find out why you should care about traceability. The one major downfall in my view is that the automation tool they present only works on Windows. Leaving those of us that prefer to do development on Linux and other platforms out in the cold.

To prevent vendor lock-in extortion I always prefer to use Open Source software where it makes sense. Traceability is one area where there is almost no applications at all that support this problem domain. The Web PHP based project TRUC - Tracking Requirements & Use Cases, is the only one that I know. Leave a comment on the ones that you know about.

A simplistic introduction to how to do traceability can be found at eHow How to Create a Requirements Traceability Matrix. Linda Westfall offers up a in more depth introduction Bidirectional Requirements Traceability . How well do you think you will do on Lind's Certified Software Quality Engineering Quiz?

Tom and Kai Gilb explain why bad or non-existent requirements are the root of failed projects, with emphasis on traceability. They have a large number of papers related to the subject, and subjects such as software quality, available for download. The manuscript for the book Evo - Evolutionary Project Management is also available for download.

When it comes to documentation I always like to look to NASA for inspiration, for example the NASA Safety and Mission Assurance Documentation Status Tree Policy, Plans and Documents section and the NASA Software Assurance section, all part of the Office of Safety and Mission Assurance (OSMA).

One paper from the NASA sites above worth pointing out is NASA Complex Electronics Guidebook for Assurance Professionals. One of the things that it wants to accomplish is to stop organizations that were implementing software functions in FPGAs and ASICs to avoid the need to follow the software assurance/safety standards for:

  • Field Programmable Gate Arrays (FPGA)
  • Complex Programmable Logic Device (CPLD)
  • System-on-chip (SoC)
  • Blurring the hardware/software line

It is also an excellent management introduction to those topics, if you are still trying to convince your boss to starting using some modern technologies like FPGA's.