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:

• Standard for Software Assurance with Requirements Compliance Matrix [MS_Word] and Requirements Compliance Matrix [MS_Excel].
• Software assurance standard; NASA-STD-8739.8 (2004-07-28)
• Software Safety Standard; NASA-STD-8719.13 (2013-05-07)
• Software Formal Inspections Standard; NASA-STD-8739.9 (2013-06-17)

"What Good Are Strong Specifications?"

"I'll go up and find out what they need [this project to actually do], the rest of you stat coding it [right now]" is meant to be humorous, alas I've seen it the Real World far to often. What is our new widgets actually required to do (Validation: Have we built the correct device? Do we meet the customer's requirements)? Which brings us to the subject of this blog, writing software specifications (Verification: Have we built the device correctly? Did we find and remove all of the 'bugs'?) and User Documentation.

What Good Are Strong Specifications? [PDF] by Nadia Polikarpova, Carlo A. Furia, Yu Pei, Yi Wei and Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland.

Abstract:

Experience with lightweight formal methods suggests that programmers are willing to write specification if it brings tangible benefits to their usual development activities. This paper considers stronger specifications and studies whether they can be deployed as an incremental practice that brings additional benefits without being unacceptably expensive. We introduce a methodology that extends Design by Contract to write strong specifications of functional properties in the form of preconditions, postconditions, and invariants. The methodology aims at being palatable to developers who are not fluent in formal techniques but are comfortable with writing simple specifications. We evaluate the cost and the benefits of using strong specifications by applying the methodology to testing data structure implementations written in Eiffel and C#. In our extensive experiments, testing against strong specifications detects twice as many bugs as standard contracts, with a reasonable overhead in terms of annotation burden and runtime performance while testing. In the wide spectrum of formal techniques for software quality, testing against strong specifications lies in a "sweet spot" with a favorable benefit to effort ratio.

- {Trackback}

In a less formal, more practical implementation to the everyday Embedded System Developer, Doxygen is a popular method of generating documentation from source code. Doxygen can be extended with 'alias' to add features, and a thread over at Stack Overflow, Custom tags with Doxygen shows how to add 'Requirement' and 'Requirement Verification' aliases.

While Doxygen excels at Program Documentation, it is often pressed into service to generate User Documentation, which far to often a novel concept to software authors, that is not the domain Doxygen was intended for and often has to be beat into submission. On the other-hand AsciiDoc is written specifically to author User Documentation, and ADExtract.py can be used to extract the User Documentation from the source code files. If you truly want to keep your project on track then write the User Documentation first before any line of code is ever written. Keeping the Source Code, Program Documentation and User Documentation as a single file gives them the best hope of actually being maintained.

Something I always find extremely frustrating is the disconnect between Academia Research into Software Safety, and the Real World of "we must ship 782 Widgets by Friday to meet payroll!". Take for example Net-Centric Software & Systems Consortium's Software Safety Tutorial, that is reproduced below, which seems more like an expedition for finding more funding from industry. How do you actually apply this kind of information in the Real World? The European Network of Excellence of Embedded Systems Design is a bit more in-line with the concept that a product must having shipping it as one of its primary requiremnts...

Alas the problem is not just one of academic discussion as Dave Woll explains the issues of our aging infrastructure impending failure in The coming wave of process safety system migration: Systems changes require rigorous hazards analysis.

If you do like Slid Shows check out CPLD Course Draft International Software Safety Conference 2011: