Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
1.8 Reliability 15 contain a comma rather than the period character actually used. The use of the period makes the statement into assignment statement, placing a value 1.3 into the variable named DO3I. The space probe turned on the wrong course and was never seen again. Thus small errors can have massive consequences. Note that this program had been compiled successfully without errors, which illustrates how language notation can be important. Bugs can be syntactically correct but incorrect for the job they are required for. The program had also been thoroughly tested, which demonstrates the limitations of testing techniques. In March 1979, an error was found in the program that had been used to design the cooling systems of nuclear reactors in the USA. Five plants were shut down because their safety became questionable. Some years ago, the USA’s system for warning against enemy missiles reported that the USA was being attacked. It turned out to be a false alarm – the result of a computer error – but before the error was discovered, people went a long way into the procedures for retaliating using nuclear weapons. This happened not just once, but three times in a period of a year. Perhaps the most expensive consequence of a software fault was the crash, 40 seconds after blast-off, of the European Space Agency’s Ariane 5 launcher in June 1996. The loss was estimated at $500 million, luckily without loss of life. In 1999, the website for eBay, the internet auction site went down for 22 hours. As the markets began to doubt that eBay could adequately maintain its key technology, $6 billion was wiped off the share value of the company. The incidents related above are just a few in a long catalog of expensive problems caused by software errors over the years, and there is no indication that the situation is improving. How does the reliability of software compare with the reliability of hardware? Studies show that where both the hardware and software are at comparable levels of development, hardware fails three times as often as software. Although this is grounds for friendly rivalry between software and hardware designers, it can be no grounds for complacency among software people. There are particular applications of computers that demand particularly high reliability. These are known as safety-critical systems. Examples are: ■ fly-by-wire control of an aircraft ■ control of critical processes, such as a power station ■ control of medical equipment In this book, we will look at techniques that can be used in developing systems such as these. It is not always clear whether a piece of software is safety related. The example mentioned earlier of the faulty software used in designing a power plant is just one example. Another example is communications software that might play a critical role in summoning help in an emergency. The conclusion is that, generally, software has a poor reputation for reliability.
16 Chapter 1 ■ Software – problems and prospects SELF-TEST QUESTION 1.4 Identify three further examples of software systems that are safety critical and three that are not. 1.9 ● Human–computer interaction The user interface is what the human user of a software package sees when they need to use the software. There are many examples of computer systems that are not easy to use: ■ many people have difficulty programming a video cassette recorder (VCR) ■ some people find it difficult to divert a telephone call to another user within an organization In recent years, many interfaces have become graphical user interfaces (GUIs) that use windows with features like buttons and scroll bars, together with pointing devices like a mouse and cursor. Many people saw this as a massive step in improving the user interface, but it remains a challenging problem to design a user interface that is simple and easy to use. SELF-TEST QUESTION 1.5 Think of two computer-based systems that you know of that are difficult to use in some way or another. Alternatively, think of two features of a program you use that are difficult to use. 1.10 ● A software crisis? We have discussed various perceived problems with software: ■ it fails to do what users want it to do ■ it is expensive ■ it isn’t always fast enough ■ it cannot be transferred to another machine easily ■ it is expensive to maintain ■ it is unreliable ■ it is often late ■ it is not always easy to use.
- Page 1 and 2: Software Engineering for Students D
- Page 3 and 4: We work with leading authors to dev
- Page 5 and 6: Pearson Education Limited Edinburgh
- Page 7 and 8: vi Contents Part D ● Verification
- Page 9 and 10: viii Detailed contents 3 The feasib
- Page 11 and 12: x Detailed contents 9 Data flow des
- Page 13 and 14: xii Detailed contents 14.7 Repetiti
- Page 15 and 16: xiv Detailed contents 19.7 Unit tes
- Page 17 and 18: xvi Detailed contents 26 Agile meth
- Page 19 and 20: xviii Detailed contents 32.4 Softwa
- Page 21 and 22: xx Preface Software Engineering and
- Page 23 and 24: xxii Preface are engaged on a proje
- Page 26 and 27: CHAPTER 1 This chapter: ■ reviews
- Page 28 and 29: 1.3 The cost of software production
- Page 30 and 31: 100% 10% 1970 SELF-TEST QUESTION Ha
- Page 32 and 33: Analysis and design 1 /3 Coding 1 /
- Page 34 and 35: SELF-TEST QUESTION 1.7 Maintenance
- Page 36 and 37: 1.8 Reliability 13 in the first pla
- Page 40 and 41: Ease of maintenance Reliability Con
- Page 42 and 43: Exercises 19 • Exercises These ex
- Page 44 and 45: Further reading 21 Analyses of the
- Page 46 and 47: ■ documentation ■ maintenance
- Page 48 and 49: 2.2 The tasks 25 An important examp
- Page 50 and 51: 2.4 Methodology 27 reality. Like an
- Page 52 and 53: ■ error free ■ fault ■ tested
- Page 54 and 55: 3.2 ● Technical feasibility 3.3 C
- Page 56 and 57: 3.5 Case study 33 The hardware cost
- Page 58 and 59: Answers to self-test questions 3.1
- Page 60 and 61: 4.2 The concept of a requirement 37
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 64 and 65: 4.5 The requirements specification
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 78 and 79: 5.3 Styles of human-computer interf
- Page 80 and 81: 5.5 Design principles and guideline
- Page 82 and 83: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
16 Chapter 1 ■ <strong>Software</strong> – problems and prospects<br />
SELF-TEST QUESTION<br />
1.4 Identify three further examples of software systems that are safety critical<br />
and three that are not.<br />
1.9 ● Human–computer interaction<br />
The user interface is what the human user of a software package sees when they need to<br />
use the software. There are many examples of computer systems that are not easy to use:<br />
■ many people have difficulty programming a video cassette recorder (VCR)<br />
■ some people find it difficult to divert a telephone call to another user within an<br />
organization<br />
In recent years, many interfaces have become graphical user interfaces (GUIs) that<br />
use windows with features like buttons and scroll bars, together with pointing devices<br />
like a mouse and cursor. Many people saw this as a massive step in improving the user<br />
interface, but it remains a challenging problem to design a user interface that is simple<br />
and easy to use.<br />
SELF-TEST QUESTION<br />
1.5 Think of two computer-based systems that you know of that are difficult<br />
to use in some way or another. Alternatively, think of two features<br />
of a program you use that are difficult to use.<br />
1.10 ● A software crisis?<br />
We have discussed various perceived problems with software:<br />
■ it fails to do what users want it to do<br />
■ it is expensive<br />
■ it isn’t always fast enough<br />
■ it cannot be transferred to another machine easily<br />
■ it is expensive to maintain<br />
■ it is unreliable<br />
■ it is often late<br />
■ it is not always easy to use.
Change language