Food for Thought-An e-Newsletter Published by Software Quality Consulting, Inc.
November 2008, Vol. 5 No. 7
Are More Software Catastrophes Inevitable?

What topics would you like to see in this newsletter?  Each month, this
newsletter tries to provide you with useful information.  This is a two-way
street and your feedback is important.  Please send your thoughts and comments
to [email protected].

--------------------------------------------------------------------------------

Welcome to Food for Thought(TM), an e-newsletter from Software Quality
Consulting (http://www.swqual.com/index.html?Intro). I've created free
subscriptions for my valued business contacts. If you find this newsletter
informative, I encourage you to continue reading. Feel free to pass this
newsletter along to colleagues by clicking the Forward Email link at the bottom
of this newsletter. If you�ve received this newsletter from a colleague and
would like to subscribe, please click this Enter New Subscription link
(http://www.swqual.com/newsletter/Subscribe.htm?Newsletter). If you don't wish
to receive this newsletter, click the SafeUnSubscribe(TM) link at the bottom of
this newsletter, and you won�t be bothered again.

Your continued feedback on this newsletter is most welcome. Please send 
your comments and suggestions to [email protected].

--------------------------------------------------------------------------------

*** In This Issue ***

In This Months� Topic, I discuss the increasing dependence on software 
and the risks associated with this dependence... 

Regular features to look for each month are:

- Monthly Morsels
  Hints, tips, techniques and reference info related to this month�s topic 

- Calendar
  Conferences, workshops, and meetings of interest to software engineers, 
  QA engineers and anyone interested in software development 

--------------------------------------------------------------------------------

*** This Month�s Topic ***

ARE MORE SOFTWARE CATASTROPHES INEVITABLE?
THE CHALLENGE OF CREATING DEPENDABLE SOFTWARE

We have come to depend on software for many aspects of daily life. Every 
day we rely on millions of lines of code often without realizing it...

  Your programmed digital alarm clock rings and switches to soothing 
  nature sounds that gently wake you from a night�s sleep. As you hit the 
  shower, the programmable thermostat has already raised the temperature 
  setting so that the kitchen will be nice and warm when you come down for 
  breakfast. The programmable coffee maker starts brewing your favorite 
  caffeinated beverage at just the right time. After breakfast, you head 
  out to work. Your car�s on-board computer monitors everything, including 
  your anti-lock brakes, engine, emissions, airbags, seat belts, tire 
  pressure, audio system, and of course, where you are. On the way to 
  work, you stop at an ATM kiosk for some cash. You get a call on your 
  cell phone and respond by sending a text message. Back on the highway, 
  you pay tolls using a transponder that bills your credit card. Your GPS 
  navigation system receives updates on traffic conditions and recommends 
  alternate routes so you arrive at your office in the shortest possible 
  time...

By the time you have arrived for work in the morning, you relied on 
millions of lines of code without ever giving it a second thought. Every 
day people all over the world depend on software to work correctly and 
safely - even though we know that all software is defective
(http://www.swqual.com/newsletter/vol2/no11/vol2no11.html). The reality 
is that:

  �We rely on software and sometimes it fails us.� [1]

Consider some areas where software is currently being used:

  - Nuclear Power Plants 
  - Chemical/Petro-chemical Processing Plants 
  - Railway Signaling Systems 
  - Controlling National Electricity Grid 
  - Medical Devices 
  - Avionics and Air Traffic Management 

While many system failures are harmless, there have been dozens of cases 
where software has led to severe economic loss as well as loss of life. 
For examples of software failures, see [1], [2], and [3] 

Software is routinely used in many highly complex, interconnected systems. 
With each new use, there are new risks. Risk assessments used to identify 
and mitigate safety risks are commonly required in industries such as 
medical devices, avionics, nuclear power, etc. However, a risk assessment 
does not guarantee that software will not harm people - at best, it merely 
lowers risk to an �acceptable level�. 

If we are to continue to depend on software, some critical issues must be 
addressed:

- Can software-based systems be made dependable in a cost-effective 
  manner? 

- Can we provide assurance that a quantifiable level of dependability has 
  been achieved? 

As software-based systems continue to increase in complexity and risk, the 
onus is on system developers to ensure these systems are dependable and 
most importantly, safe. 

As a society, we entrust trained and licensed professional engineers to 
design buildings and bridges that are not likely to collapse. Even with 
the best engineers, the best inspections, the best materials, and the best 
construction techniques, buildings (http://en.wikipedia.org/wiki/
Hyatt_Regency_walkway_collapse) and bridges (http://www.dot.state.mn.us/
i35wbridge/index.html) do fail on occasion. If we compare how software-based
systems are designed and developed to how buildings and bridges are designed and
developed, we find that:

[Visit the online version to see this table]

SOME TERMS AND CONCEPTS 

Before we continue this discussion, we need to define some terms and 
concepts: 

  Dependable

  A system is dependable when it can be depended on to produce the 
  consequences for which it was designed with no adverse affects.

  Dependability

  Dependability as applied to a computer system is defined by the IFIP 
  10.4 Working Group on Dependable Computing and Fault Tolerance
  (http://www.dependability.org/) as: " [..] the trustworthiness of a computing  
  system which allows reliance to be justifiably placed on the service it 
  delivers [..]" 

  Risk

  Risk is often expressed as the combination of the likelihood of 
  occurrence of harm and severity of that harm should it occur. As such, 
  risk is something that needs to be actively managed.
   
  This picture (from IEC Standard 60601-1-4) illustrates that risk is the 
  combination of likelihood and severity. The location of line defining 
  the Intolerable Region is often determined on a case-by-case basis.

  Learn more...Risk Management Training for Medical Device Manufacturers
  (http://www.swqual.com/training/fda/risk1.html)

Now that we have some context, let�s look at this problem in a bit more 
detail.

HOW BIG IS THIS PROBLEM?

We know that the best, most highly skilled software developers inject on 
average one defect for every 8 lines of code they write. [3] We also have 
anecdotal information suggesting that through peer reviews and testing, we 
typically find about 95% of the injected defects. The result is on 
average, released software has a defect density in the range of 5-6 
defects per thousand lines of code (KLOC).

So if we look at a typically software-based system that has 
one million lines of code (MLOC), here�s what we�d expect:

  Defects injected using 1 defect /8 lines of code = ~120,000 defects 

  Defect removed assuming 95% found = 114,000 defects 

  Defects remaining (defects injected - defects removed) = 6,000 defects

To put this in perspective, your average late model car has about 10 MLOC. 
Given the above, there could be as many as 60,000 defects that remain in 
the software that controls your car. One of those defects led to a 
significant recall (http://dso.com/indepth/showArticle.jhtml?
articleID=175007283).

WHAT ARE THE ISSUES?

Recently, a prestigious group of researchers from the National Research Council
(http://sites.nationalacademies.org/nrc/index.htm) published a book on the
issues related to developing software for dependable systems. Their sobering
assessment of the situation:

  �Society is increasingly dependent on software. Software failures can 
  cause or contribute to serious accidents that result in death, injury, 
  significant environmental damage, or major financial loss. Such 
  accidents have already occurred and without intervention, the 
  increasingly pervasive use of software - especially in arenas such as 
  transportation, heath care, and the broader infrastructure - may make 
  them more frequent and more serious.� [2]

The problem is exacerbated by a pervasive lack of evidence about both the 
incidence and severity of software failures. This lack of evidence has led 
the researchers to the following conclusions: [2]

- Better evidence is needed, so that approaches aimed at improving the 
  dependability of software can be objectively assessed. 

- For now, the pursuit of dependability in software systems should focus 
  on the construction and evaluation of evidence. 

What we must recognize is that software development best practices are 
necessary but not sufficient to ensure that software systems are 
dependable and safe. We need to adopt and incorporate software safety 
practices, such as risk assessment, hazard analysis, threat models, safe 
states, use of static analysis tools, etc., to improve software 
dependability.

CERTIFIABLY DEPENDABLE SOFTWARE

The researchers found that software may not be declared �dependable� based 
solely on the software development process used to build it. There needs 
to be a notion of �certifiably dependable� that is - dependability claims 
must be supported by evidence.

A variety of certification schemes exist today. However, none are robust enough
to be recommended as examples to follow. Current certification schemes are
focused on specific industries - such as the scheme used by the US Federal
Aviation Administration (FAA) to certify software-based systems used in avionics
and air traffic management. Software security is another area where a
certification scheme is used - the National Information Assurance Partnership
(NIAP - http://www.niap-ccevs.org/) licenses 3 rd party labs to certify security
software products based on the Common Criteria (http://www.niap-ccevs.org/cc-
scheme/) for software security as defined in ISO/IEC Standard 15408
(http://www.niap-ccevs.org/cc-scheme/cc_docs/).

WHAT CAN BE DONE?

The researchers� proposed approach for improving software dependability is 
based on:

- Explicit Claims 

  �No system can be �dependable� in all aspects and under all conditions. 
  So to be useful, a claim of dependability must be explicit. It must 
  articulate precisely the properties the system is expected to exhibit 
  and the assumptions about the system�s environment upon which the claim 
  is contingent. The claim should also indicate explicitly the level of 
  dependability claimed, preferably in quantitative terms.� [2]

- Evidence 

  �For a system to be regarded as dependable, concrete evidence must be 
  presented that substantiates the dependability claim. Because testing 
  alone is insufficient to establish properties, the [dependability] case 
  will typically combine evidence from testing with evidence from 
  analysis.� [2]
- Expertise 

  �Expertise - in software development, in the domain under consideration, 
  and in the broader systems context, among other things - is necessary to 
  achieve dependable systems.� [2]

The researchers then identified the following recommendations: [2]

- Make the most of effective software development technologies and formal 
  methods. 

- Follow proven principles of software development - take a systems 
  perspective and exploit simplicity. 

- Make a dependability case for a given system and context: evidence, 
  explicitness, and expertise. 

- Demand more transparency, so that customers and users can make informed 
  judgments about dependability. 

- Make use of but do not rely solely on process and testing. 
  Base certification on inspection and analysis of the dependability claim 
  and the evidence offered in its support. 

Current software development practices are not sufficient to develop 
software that is both dependable and safe. We need to integrate new 
methods and new techniques into the software development process that are 
focused on reducing risk and improving dependability. The IEEE Software 
Engineering Standards Committee (SESC) has already begun taking steps in 
this direction.

The IEEE Software Engineering Standards (http://74.125.45.104/search?q=cache:
7eiWeod2UXIJ:standards.computer.org/sesc/s2esc_excom/minutes/2008-07/Schultz-
Moore-Zaman-mtg159.ppt+IEEE+Standard+12207-2008&hl=en&ct=clnk&cd=7&gl=us) are
being revised to incorporate a systems perspective into software development. In
addition, IEEE Standard 12207:2008 Systems and Software Engineering � Software
Life Cycle Processes [4] now includes requirements for risk and risk assessment.
The forthcoming revision of IEEE Standard 1012 Software Verification and
Validation will likely also addresses the issue of risk by requiring that 
software components be assessed based on risk.

SUMMARY

One of the key findings of the National Research Council�s book on 
software dependability is:

  �Avoidable software failures have already been responsible for loss of 
  life and for large economic losses. The quality of software produced by 
  the industry is extremely variable, and there is inadequate oversight in 
  some critical areas. Unless improvements are made, more pervasive 
  deployment of software in the civic infrastructure may lead to 
  catastrophic failures. Software has the potential to bring benefits to 
  society, but it will not be possible to realize these benefits - 
  especially in critical applications - unless software becomes more 
  dependable.� [2]

�Til next time...

--------------------------------------------------------------------------------

*** Monthly Morsels ***

Every month in this space, you�ll find additional information related to 
this month�s topic.

- References 

  1 Wiener, L., Digital Woes - Why We Should Not Depend on Software, 
    Addison-Wesley, 1993. 

  2 Jackson, D., et. al., Software for Dependable Systems - Sufficient 
    Evidence?, National Research Council, National Academies Press, 2007.

  3 Leveson, N., Safeware � System Safety and Computers, Addison-Wesley, 
    1995.

  4 ISO/IEC/IEEE Std 12207:2008 System and Software Engineering - Software 
    Life Cycle Processes, IEEE, Piscataway, NJ.

- Additional Resources 

  1 IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance.
    (http://www.dependability.org/)

  2 Software Safety System Handbook � A Technical and Managerial Team 
    Approach, DoD Joint Services Computer Resources Management Group, 1999 
    included in DACS Software Reliability Sourcebook.
    (https://store.thedacs.com/)   

  3 Humphrey, W., �The Quality Attitude�, news@sei newsletter, Number 3, 
    2004.
    (http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/
    watts-new-2004-3.pdf)

  4 Humphrey, W., �Defective Software Works�, news@sei newsletter, Number 
    1, 2004. 
    (http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/1/watts-new-2004-
    1.htm)

--------------------------------------------------------------------------------

*** Calendar ***

Every month you�ll find news here about local and national events that 
are of interest to the software community...

- Software Quality Calendar 

  There are many organizations that sponsor monthly meetings, workshops, 
  and conferences of interest to software professionals. Find out what�s 
  happening...
  (http://www.swqual.com/links/upcoming.html)

- Workshops Offered by Software Quality Consulting 

  Software Quality Consulting offers workshops in many topics related to 
  software process improvement. Get more info...
  (http://www.swqual.com/seminars/courses.html)

--------------------------------------------------------------------------------

*** About SQC ***

Software Quality Consulting provides consulting, training, and auditing 
services tailored to meet the specific needs of clients. We help clients 
fine-tune their software development processes and improve the quality of 
their software products. The overall goal is to help clients achieve 
Predictable Software Development(TM) � so that organizations can consistently 
deliver quality software with promised features in the promised timeframe. 

To learn more about how we can help your organization, visit our web site
(http://www.swqual.com/index.html?AboutSQC) or send us an email
([email protected]).

--------------------------------------------------------------------------------

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback... ([email protected])

Thanks,

Steve Rakitin
[email protected]

Food for Thought, Predictable Software Development, Act Like a Customer,
and ALAC are trademarks of Software Quality Consulting, Inc.
Copyright 2008. Software Quality Consulting, Inc. All rights reserved.
Graphic design by Sage Studio