OEMs are accustomed to operating to standards in hardware. While software standards are less common, they might be even more useful for improving product quality.
If your company builds equipment for either aviation or industrial use, then you're already aware of two of the most significant software standards. DO-178B is the standard for software used in avionics. OEMs working to build equipment for the manufacturing sector are more likely to be familiar with IEC 61508, the most significant standard for assuring operational safety in industrial control applications. This standard has, in fact, been used as the model on which standards for specific industries like the automotive, medical, railway, nuclear, and process industries have been based. All of these are based on a stacking model that can be useful whether you're required to conform to one of these standards or not.
Safety Integrity Levels define, in their most basic forms, what happens if something goes wrong with the software. Think of the ISO/OSI network stack for consequences and you have a picture of SILs. A typical list of SILs might look like this:
- Level 1: Catastrophic -- If the software doesn't work, life as we know it will end.
- Level 2: Hazardous -- If the software doesn't work, it will make the national news.
- Level 3: Major -- If the software doesn't work, you'll hear about it from your CEO.
- Level 4: Minor -- If the software doesn't work, you'll hear about it from your boss.
- Level 5: No effect -- If your software doesn't work, it will be a dark secret that nags at your professional sensibilities.
The reason you establish these levels is that they help guide the effort that goes into debugging and quality testing the software in question. Obviously, the testing for Level 1 software should be far more rigorous than that for Level 5, and the organization's tolerance for errors much lower. The difficult first step is to accurately assess which pieces of software, which subroutines, and which library components fall onto which levels. Once that is done, a formal process of development, debugging, and quality control can be applied.
Safety Integrity Levels are a good example of concepts from one vertical market that can be applied to many others. The same principle could easily apply to financial services software, security applications, or courseware. Defining risk, defining response, and following through are steps that can be taken in essentially any development practice.
Are you using a discipline like this in your software development? Could you? We'd like to hear what you think about taking this OEM lesson and applying it to your enterprise. Let us know in the comments, below.