In an ideal world, what do we look for in our software? There are many answers to this question, but, more than anything else, one stands out: the production of totally fault-free software. We look for that because, we reason, given such software, our systems should work exactly as planned. But will they? Unfortunately, not necessarily so, as will be shown later. When designing software, a total system view must be taken. There are too many opportunities to get designs and implementations wrong; it isn't just confined to the code-writing stage.

In this chapter, we'll first look at the root problems of such errors. Then, we'll define the qualities of software that attempt to eliminate these. You must be realistic about them, however. Given the current state of design tools, it is impossible to guarantee the delivery of fault-free systems (on a personal note, I believe that totally fault-free systems are a myth).

Therefore, if...

2.2.1 Overview

In this text, a software error is defined to be "any feature of a program that produces a system malfunction." This is a very broad definition and really quite unfair to software developers. In many instances of system misbehavior, the code is blameless; however, we still talk of "faulty software." What it does, though, is emphasize that it isn't sufficient to eliminate errors at the software design stage; other factors need to be taken into account (Figure 2.3). These are explored further in more detail.

2.2.2 System Design Errors

System design takes place right at the frontend of a project. Quite often, software engineers are excluded from this stage. Many system designers have the attitude of "well, we'll go out and buy a box to control the plant (once we've worked out how to put it together)." Mistakes made here usually show only when system trials begin (or, worse still, when the system is...

2.3.1 General

"Good" software is dependable, is delivered on time, and is done within budget. Whether we can achieve this depends on many factors. Some relate to major sections of the development process. Others affect quite specific design activities.

What, then, do we need to do to create a quality software product? As a minimum, we should:

• Develop a clear statement of requirements for the software
• Ensure that the design solution is capable of satisfying these requirements
• Organize the development so that the project is manageable
• Organize the development so that the timescales can be met
• Make sure that the design can be changed without major rewrites
• Design for testability
• Minimize risks by using tried and trusted methods
• Ensure that safety is given its correct priority
• Make sure that the project doesn't completely rely on particular individuals
• Produce a maintainable design

Mind...

It is only in the last few years that the ideas and methods described here have been put into action by the software industry. Much more still remains to be done, especially in view of the "cottage industry" mentality of many developers. It's not as if professionals don't recognize the problems of software design and development. In fact, many tools and techniques have been proposed with a fervor normally associated with evangelical rallies. Most of the early developments came from the data processing field, a trend that has continued with object-oriented (OO) technology. Unfortunately, these have little to offer for real-time work. Now, the sheer size of the software problem (time, cost, reliability, and so on) is acting as the driving force for the development of the following:

• New and better tools specifically designed for the real-time market
• Powerful, integrated development environments
• Design formality
• Defined documentation...

Having finished this chapter you should now understand the following:

• Realize why, in the real world, we can never guarantee the production of fault-free systems
• Know what is meant by correct, reliable, and safe software
• Know what is meant by dependable software and why it should be a primary design aim
• Understand that software errors arise from problems to do with system design, software design, and environmental factors
• See that developing real-time software without taking system factors into account can lead to major problems
• Appreciate some of the root causes of poor software
• Recognize what has to be done to produce a quality software product
• Be aware of the need for, and use of, codes of practice in a professional development environment
• Be able to describe the need for, and use of, defensive programming

• [AND88] The CAMP approach to software reuse, C. Anderson, Defense Computing, pp. 25-29, Sept./Oct. 1988
• [ARI96]: ARIANE 5 Flight 501 Failure Report by the Inquiry Board: http://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report, July 1996
• [CB15] Component-Based Software Engineering 2015: https://www.slideshare.net/DEVANSHI12/component-based-software-engineering-46462727
• [FRO84] System Safety in Aircraft Management, F. R. Frola and C. O. Miller, Logistics Management Institute, Washington, D.C., January 1984
• [HAM86] Zero-defect software: the elusive goal, M. H. Hamilton, IEEE Spectrum, pp. 48-53, March 1986
• [KLE83] Human problems with computer control, hazard prevention, T. Kletz, Journal of the System Safety Society, pp. 24-26, March/April 1983
• [LEV86] Software safety: why, what, and how, Nancy Leveson, ACM Computing Surveys, Vol. 18, No. 2, pp. 125-163, June 1986
• [LEV95] Safeware – System Safety...