NASA Goddard Space Flight Center (GSFC) Software Assurance

Back in the blog I wrote, The Anatomy of a Race Condition: Toyota vs AVR XMega I mentioned the NASA Software Safety Guidebook. Seems that link went viral, as it popped up lots of other places the next day as people spread it around.

I was a bit surprised, but glad, to find that the Software Safety site and this Software Safety blog are listed number one and number two by SEMRush (a 'Competitor Research Service'), beating out NASA themselves at number four, for the term "Software Safety".

Will today's link to NASA's Goddard Space Flight Center's Software Assurance page go viral as well?

"The NASA Goddard Space Flight Center (GSFC) Software Assurance Website provides tools, procedures and training materials for software and safety assurance personnel, software engineers, as well as program and project managers."

Of the most practical day to day value are the numerous Checklists, for example one on Code Inspections, and the Forms and Templates. There are also examples of Procedures, Guidelines, Work Instructions, links to tools etc. The Automated Requirement Measurement (ARM) Tool has been developed as aid to "writing the requirements right," not "writing the right requirements". As of this moment Humans still create the initial requirements for any device or Embedded System, and Humans are prone to errors. Unless an other Human catches the error(s) in a requirement document early in the development life cycle, no downstream tool will clean up the mess or mitigate the cost overruns.

NASA Site for On-line Learning and Resources (SOLAR), has some on line training as well. The Defense Acquisition Guidebook also has a section on Software Safety online training; MIL-STD-882D, "DoD Standard Practice for System Safety".

While in the Software Safety area of space flight check out Software Safety and Rocket Science by Gerard J. Holzmann in ERCIM News. Issue #75 covered Safety-Critical Software.

In my last blog entry I mentioned Circuit Cellar Magazine. In the April 2011 issue George Novacek took on the DO-178B software assurance standard. George details the standard, as best as you can in the allowed couple of pages, then seemed to imply at the end, that doing all of this paper work doesn't make the system much safer. Over the years I've seen both sides. Not having good written requirements leads to nothing but never ending project changes (changes are normal, but if you don't know what your setting out to make, you never know when you are done), cost overruns, and missed deadlines. On the other side having so much paper work that you can never actually ship a product out the door puts any company selling Embedded Systems out of business.