Officials, such as the FDA quoted here, stress that "... guidance documents, including this guidance, do not establish legally enforceable responsibilities. Instead, guidances describe the Agency's current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in Agency guidances means that something is suggested or recommended, but not required."
The problem with not considering "guidance documents" as requirements, rather than recommendations can be seen in this scenario:
Scene: Courtroom. You are on the witness stand, a defendant in a product liability case.
Prosecutor: "Did you follow the 'Best Practice Guidelines' as recommended by [Fill in your favorite acronym]?"
{There are two possible realities that can be created from this point:}
Reality One: "No. The law did not require us to do so, so we saved time and money by not following those. We saw it as a unfunded goverment mandated paper work burden."
Reality Two: "Yes we followed the Guidelines, as well as several other Industries Best Practices. We wish to submit our documentation as evidence that we did the best possible job that could be done by anyone. We found that our costs where lower and the quality of our software is higher by following the recommended guidelines."
When you think of what the Judge and/or Jury might decide, which reality would you like to continue? Did you really save time and money?
How To Write Unmaintainable Code
shows what NOT to do.
I once inherited code of a complex multi-processor industrial control system that looked like these where the guide lines used to develop the system.It is down right scary to think that there is code out there in embedded systems that has been written like this. That is one of my motivations in creating this site. I want to point out the techniques that should be use to develop mission critical code.
Some thing else you do not want to do is the:
Big Ball of Mud
by
Brian Foote and Joseph Yoder
Abstract
"While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.
A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?"
The International Obfuscated C Code Contest shows just how bad code can get. Keep in mind that you can write bad code in any language, C just makes it easy to do it.
Added Jan/27/2007:
Joint Strike Fighter Air Vehicle C++ Coding Standards.
Added July/09/2005:
SOFTWARE 2015: A National Software Strategy to Ensure U.S. Security and Competitiveness http://www.cnsoftware.org/nss2report/NSS2FinalReport04-29-05PDF.pdf.
Added APR/30/2005:
SHIP - Assessment of the Safety of Hazardous Industrial Processes in the Presence of Design Faults.
The overall objective of SHIP was to devise a means of assessing, ideally numerically, the achieved reliability or safety of a system in the presence of design faults.
Workshop on Assurance Cases: Best Practices, Possible Obstacles, and Future Opportunities.
Military Standard on System Safety MIL-STD-882D.
Added Feb/25/2006:
Those working on medical device software should be very interested in a new standard currently undergoing approval, ISO 62304: Medical Device Software Software Life Cycle Processes. This standard was developed in a cooperative effort between FDA and industry, coordinated through the Association for the Advancement of Medical Instrumentation (AAMI) Software Standards Committee.
Added Nov/21/2004:
Department of the Army Pamphlet 73-7 "Test and Evaluation Software Test and
Evaluation Guidelines" 1997.
Appendix Q of
DA PAM 73-1 has updated, 2003, information.
Added Sep/11/2004:
do not follow human factors principles.
By Michael J. Darnell
Added Sep/11/2004:
Software Safety Standards
Software Engineering Process Technology has posted the twenty most popular software safety standards.
Added Aug/01/2004:
European Commission accepts proposal to develop reliable systems By Colin Holland, Embedded.com.
DECOS, a joint initiative to generate a proposal for an integrated project within the EU's Framework Programme 6, has been accepted by the European Commission. Its aim is to identify and alleviate the barriers that hinder the development of highly reliable embedded systems.
DECOS : Dependable Embedded Components and Systems, was among the most successful project proposals that were submitted to the EC in the field of embedded systems. Its industrial and academic partners will jointly develop a set of generic hardware and software components within the framework of the Time-Triggered Architecture (TTA).
TTA's dependable approach for high-reliability systems has seen it attract attention in a range of industries, including aerospace, automotive, special vehicles, railway, and industrial control.
Navy Handbook for the Computer Security Certification of Trusted Systems is part of the web for the Center for High Assurance Computing Systems.
DOE-STD-1172-2003; Safety Software Quality Assurance Functional Area Qualification Standard; DOE Defense Nuclear Facilities Technical Personnel documents what it takes to get DOE Software Quality Assurance position.
Industry and Federal Standards and Guides.
Regulatory Guide 1.173 - Developing Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants.
US Army Software System Safety Requirements. Other Army Software Web Sites.
Previous additions:
NASA C Programming Style Guide - From Goddard
Space Flight Center.
- Process Documents:
-
-
- Recommended Approach: This document presents guidelines for an organized, disciplined approach to software development that is based on studies conducted by the SEL between 1976 and 1991. [PDF, 1MB]
-
- Manager's Handbook for Software Development: This document presents methods and aids for the management of software development projects. [PDF, 632KB]
-
- Software Measurement Guidebook: Presents information on the purpose and importance of measurement. It discusses the specific procedures and activities of a measurement program and the roles of the people involved. [PDF, 880KB]
-
- Software Process Improvement Guidebook: Provides experience-based guidance for implementing a software process improvement program in any NASA software development or maintenance community. It describes the program's concepts and basic organizational components and provides details on how to define, operate, and implement a working software process improvement program. [PDF, 481KB]
-
NASA Software Requirements Specification (SRS); DI-IPSC-81433
The Software Requirements Specification (SRS) specifies the requirements for a Computer Software Configuration Item (CSCI) and the methods to be used to ensure that each requirement has been met. Requirements pertaining to the CSCI's external interfaces may be presented in the SRS or in one or more Interface Requirements Specifications (IRSs) (DI-IPSC-81434) referenced from the SRS.
Software Safety NASA Technical Standard.
This standard provides a methodology for software safety in NASA programs. It describes the activities necess ary to ensure that safety is designed into software that is acquired or developed by NASA. All Program/Project M anagers are to assess the inherent safety risk of the software in their individual programs and are encouraged t o tailor their software safety activity accordingly within the framework of this standard.
The Software Working Group (SWG) is an Agency-wide software advocate and coordinating body that is responsible for addressing software related issues throughout NASA.
The SWG site contains many of the NASA Guidebooks and Standards related to software development.
MISRA Mission Statement
To provide assistance to the automotive industry in the application and creation
within vehicle systems of safe and reliable software.
|
Guidelines for the Use of the C Language in
Vehicle Based Software The Motor
Industry Software Reliability Association (MISRA)
has developed a set of guidelines for C programming
of safety-related embedded automotive
systems. |
 |
The MISRA software guidelines, "Development Guidelines for Vehicle Based Software", published in 1994 and now widely used within the industry, recommend the use of a restricted subset of a high-level language for programming safety-related systems. The C programming language is being increasingly used for automotive applications, due largely to the inherent language flexibility, the extent of support and its potential for portability across a wide range of hardware. However the nature of the C language is such that there are many areas of concern which potentially jeopardize the high level of integrity required from the final executable code.
Having carried out extensive consultation within the automotive industry, the MISRA consortium has now completed the development of guidelines specifically aimed at the use of the C language. These guidelines primarily identify those aspects of the C language which should be avoided in safety-related systems, along with other recommendations on how other features of the language should be used. It is anticipated that the guidelines will be adopted for embedded C programming throughout the automotive industry.A recently launched website, http://www.misra-c.com/, dedicated to MISRA C. This website includes details of the new version of MISRA C, MISRA-C:2004, and answers to common questions. There is a web discussion forum on this site which has replaced the existing email discussion list. If you have any questions about interpretation of MISRA C rules, then here is the place to ask. Official responses to questions will be published as appropriate at this forum by the MISRA C team.
How do the MISRA Guidelines relate to IEC 61508?: IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems is a generic standard. At the time of writing Development Guidelines for Vehicle Based Software IEC 61508 had not been published, although the authors did consider earlier drafts of the standard. Many of the principles of the standard are embodied in the Guidelines with an automotive focus where appropriate. It is planned to address the "mapping" between IEC 61508 and the MISRA Guidelines more formally in the future.
You can find a list of the MISRA rules here, as part of Abraxas Software's, CodeCheck package. Gimpel's Lint offers simular MISRA functionality.
It is still necessary to buy the MISRA guide lines to learn the rational behind each rule.
Functional Safety in High-Volatile Applications: With IEC 61508, manufacturers can ensure the functional safety of all aspects of a product's life cycle, by Kristina L. Balobeck, explains the "reset mentality".
Let's get it right the first time before the lawyers and politicians get involved and tell us how to do our jobs...
[Alas it is to late. It is now illegal to be a "Software Engineer" in the state of Texas, without passing a state licensing exam. There is a fine of $3,000 per day. - Dr. Dobb's Journal, June 2003 page 8. Last I knew, no one knew how to write the required exam. See also To be an engineer by Jack Ganssle.]
