Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
3.2 ● Technical feasibility 3.3 Cost-benefit analysis 31 Before beginning a project, there is a crucial decision that must be made: Is the proposal technically feasible? That is, will the technology actually work? We know, for example, that a system to predict lottery results cannot work. But a system to recognize voice commands is borderline. A system to download and play DVD-quality movies into people’s homes is also borderline. 3.3 ● Cost-benefit analysis In engineering, there has long been a tradition of assessing available technology, for example, the use of reinforced concrete in building. Similarly in computer-based information systems, a number of techniques have been used in advance of building a system in order to determine whether the system will be worthwhile. Money provides the ready-made metric for measuring value. This kind of investigation is called investment appraisal or a cost-benefit analysis. The organization expects a return on investment. In this approach two quantities are calculated: 1. the cost of providing the system 2. the money saved or created by using the system – the benefit. If the benefit is greater than the cost, the system is worthwhile; otherwise it is not. If there is some other way of accomplishing the same task, which may be manually, then it is necessary to compare the two costs. Whichever technique gives the smaller cost is the one to select, provided that the benefit is greater than the cost. Costs and benefits are usually estimated over a five year period. This means that the initial start-up costs are spread over the expected useful life of the system. Five years is the typical lifetime of a computer-based system. Beyond this time, changes in technology as well as changes in requirements make predictions uncertain. Many evaluation criteria are common to all computer systems – and indeed to all products designed for some useful purpose. Thus motor cars, buildings and televisions need to be reliable, robust, easy to maintain, easy to upgrade. The obvious, central consideration is the construction cost. With each of these criteria we can associate a cost, though for some it is less easy: ■ cost to buy equipment, principally the hardware ■ cost to develop the software ■ cost of training ■ cost of lost work during switchover
32 Chapter 3 ■ The feasibility study ■ cost to maintain the system ■ cost to repair the equipment in the event of failure ■ cost of lost work in the event of failure ■ cost to upgrade, in the event of changed requirements. The upgrade cost is part of the cost of some future system and not strictly part of the current costing, but is worth bearing in mind at the evaluation stage. While all of these costs should be estimated in advance of developing a system, it is in practice very difficult to estimate the cost of construction and of maintenance. 3.4 ● Other criteria It is easy to be drawn into judging everything on the basis of costs, but there are other approaches. Many people develop software purely for fun. Open source programmers are a prime example. Their motivations include providing useful tools, enjoying the act of programming and collaborating with others. Large military projects are sometimes funded because they are considered necessary (militarily or politically), whatever the cost. Some people, perhaps seduced by technology, take the view that a computer system is obviously better than a manual system. Some systems are, arguably, socially useful and, perhaps, outside the scope of a costingbased approach. How can we meaningfully assess the value of a system that allows a patient to book a medical appointment, or a system that provides information on bus arrival times at bus stops? SELF-TEST QUESTION 3.1 Suggest another system for which cost-benefit analysis is probably not appropriate. 3.5 ● Case study We will examine carrying out a feasibility study of the software for an ATM, outlined in Appendix A. An ATM is part hardware, part software, so we could either carry out a feasibility study for the complete system or limit ourselves to the software component. However, if we are assessing the viability on the basis of cost, we must look at the complete system. We first look at costs of construction. We expect that the ATM is not just a one-off but that a number of them will be built and deployed. Let us assume that 200 machines will be needed.
- 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 38 and 39: 1.8 Reliability 15 contain a comma
- 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 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
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 90 and 91: CHAPTER 6 Modularity This chapter e
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
32 Chapter 3 ■ The feasibility study<br />
■ cost to maintain the system<br />
■ cost to repair the equipment in the event of failure<br />
■ cost of lost work in the event of failure<br />
■ cost to upgrade, in the event of changed requirements.<br />
The upgrade cost is part of the cost of some future system and not strictly part of<br />
the current costing, but is worth bearing in mind at the evaluation stage.<br />
While all of these costs should be estimated in advance of developing a system, it is<br />
in practice very difficult to estimate the cost of construction and of maintenance.<br />
3.4 ● Other criteria<br />
It is easy to be drawn into judging everything on the basis of costs, but there are other<br />
approaches.<br />
Many people develop software purely <strong>for</strong> fun. Open source programmers are a prime<br />
example. Their motivations include providing useful tools, enjoying the act of programming<br />
and collaborating with others.<br />
Large military projects are sometimes funded because they are considered necessary<br />
(militarily or politically), whatever the cost.<br />
Some people, perhaps seduced by technology, take the view that a computer system<br />
is obviously better than a manual system.<br />
Some systems are, arguably, socially useful and, perhaps, outside the scope of a costingbased<br />
approach. How can we meaningfully assess the value of a system that allows a patient<br />
to book a medical appointment, or a system that provides in<strong>for</strong>mation on bus arrival times<br />
at bus stops?<br />
SELF-TEST QUESTION<br />
3.1 Suggest another system <strong>for</strong> which cost-benefit analysis is probably not<br />
appropriate.<br />
3.5 ● Case study<br />
We will examine carrying out a feasibility study of the software <strong>for</strong> an ATM, outlined<br />
in Appendix A. An ATM is part hardware, part software, so we could either carry out<br />
a feasibility study <strong>for</strong> the complete system or limit ourselves to the software component.<br />
However, if we are assessing the viability on the basis of cost, we must look at the complete<br />
system.<br />
We first look at costs of construction. We expect that the ATM is not just a one-off<br />
but that a number of them will be built and deployed. Let us assume that 200 machines<br />
will be needed.
Change language