28 Chapter 2 ■ The tasks of software development 2.1 Discussion question on validation and verification: What do the following mean, what is the difference between them, and which is better? ■ a program that works (but doesn’t meet the specification) ■ a program that meets the specification (but doesn’t work). 2.2 Discussion question on validation and verification: What do the following terms mean and how do they relate to one another (if at all): ■ correctness ■ working properly Summary We have identified a list of tasks that are part of software development. All of them must be carried out somehow during development. A process model is a strategic plan for the complete process. Different process mod- els offer alternative suggestions as to exactly how and when tasks are carried out. As we shall see, in some process models all of the stages are visible, while in other process models some of the stages vanish or become part of some other stage. A methodology is a complete (often proprietary) package of methods, tools and notations. Hacking is an approach to development that is highly skilled but ill-disciplined. Exercises • There is one notorious approach to software development, called hacking. There are actually two types of hacker: ■ the malicious hacker who breaks into computer systems, often using the internet, to commit fraud, to cause damage or simply for fun ■ the programmer hacker, who uses supreme skills, but no obvious method, to develop software. It is the second of these meanings that we will use in this book. Hacking is often dis- paraged in software development circles because it appears to be out of control. However, the display of skill also earns hackers praise. Hackers also obviously enjoy what they do and relish their skills. We will return to the subject of hacking in the chap- ter on open source development. 2.5 ● Hacking BELL_C02.QXD 1/30/05 4:14 PM Page 28 Answer to self-test question 29 ■ error free ■ fault ■ tested ■ reliable ■ meet the requirements. Answer to self-test question 2.1 Architectural design, unit testing, project management, configuration man- agement and version control. BELL_C02.QXD 1/30/05 4:14 PM Page 29 Every software project begins with a judgment as to whether the project is worthwhile or not. This is called a feasibility study. Sometimes this assessment is carried out in a detailed and systematic fashion; and sometimes it is carried out in a hurried and ad hoc fashion; and sometimes it is not carried out at all. In this chapter we outline a frame- work for assessing whether a software system is worthwhile. There are two types of computer system: ■ a system that replaces an existing computer-based system ■ a brand new system that replaces or enhances work that is not currently computer- assisted. Another categorization is: ■ a general purpose system, such as a word processor or a game. This is written and then sold in the market place ■ a tailor-made one-off system for a specific application. Remember also that there is often the choice between writing the software and buy- ing it off the shelf. 3.1 ● Introduction CHAPTER 3 The feasibility study This chapter: ■ explains the role of a feasibility study ■ suggests how to go about conducting a feasibility study. BELL_C03.QXD 1/30/05 4:14 PM Page 30 3.3 Cost-benefit analysis 31 Before beginning a project, there is a crucial decision that must be made: Is the pro- posal 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. 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 infor- mation 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 investiga- tion 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 technol- ogy 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 con- sideration 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 3.3 ● Cost-benefit analysis 3.2 ● Technical feasibility BELL_C03.QXD 1/30/05 4:14 PM Page 31 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. 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 pro- gramming 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 costing- based 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? 3.4 ● Other criteria SELF-TEST QUESTION 3.1 Suggest another system for which cost-benefit analysis is probably not appropriate. 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 com- plete 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. 3.5 ● Case study BELL_C03.QXD 1/30/05 4:14 PM Page 32 3.5 Case study 33 The hardware cost includes the processor, the card reader, the display, the screen, the key pad, the printer, a cash dispenser and a modem. We presume that these can be bought off the shelf rather than specially designed and made. We could estimate the cost of the hardware for each ATM at $10,000. In addition there is the cost of installing the machines in a secure fashion. There will probably be a need for extra serv- er capacity at the bank in order to handle the requests from ATMs. An estimate for the total hardware costs is $20,000 per ATM. Running costs include the telephone line charge, replacing printer paper, stocking the ATM with cash. Now we attempt to estimate the software cost. The software is relatively complex because it uses a number of special devices. There is software in each ATM, plus the software at the bank to handle requests from ATMs. The ATM software must be robust and reliable because it is used by members of the public. We could adopt such tech- niques as those explained in Chapter 30 to predict the software cost, but these tech- niques are poor, and anyway, as we shall see, we only need a ball park figure. Suppose we guess two person years for the software. Suppose that this equates to $100,000. But this cost must be shared across the 200 machines, which is $500 per machine. This is about 2–5% of the cost of each ATM – an insignificant component. This is typical of software costs in embedded systems, where the software is simply one component among many others. What about the benefits of providing ATMs? No doubt ATMs are convenient, available 24/7 hours in stations, stores and public buildings. But most banks are not philanthropists – their mission is not to serve the public, but to make a profit. The provision of ATMs might attract customers to the bank and this benefit could be costed. This would probably be only a temporary advantage, until other banks caught up. However, most banks in the industrialized world have reduced jobs by computerization and this is probably the significant cost benefit. We might estimate that a single 24-hour ATM would replace two full-time cashiers. This is a saving of, say, $40,000 each per year. (This is not simply salaries, but includes other costs, such as office space.) So, in summary, over a five-year period for each ATM: Costs Benefits cost of hardware $20,000 staff costs $400,000 cost of software $500 cost of maintenance $4,500 total $25,000 total $400,000 Should the ATMs be developed? The conclusion speaks for itself. Now, all these figures are indicative, but the point is to see how to go about cost- benefit analysis. We can see that assessing the costs and the benefits of a system is com- plicated and time-consuming. It is not an exact science and some guesses usually have to be made. BELL_C03.QXD 1/30/05 4:14 PM Page 33 34 Chapter 3 ■ The feasibility study It is notoriously difficult to predict the cost of a system and therefore it is very difficult to carry out a feasibility study. This may explain why it is common to ignore it. There is, however, another common reason for avoiding a feasibility study: once an idea for a sys- tem has been suggested, the project generates its own momentum, people become committed to it and it cannot be stopped. Instead people talk about a business case for the system, which tends to emphasize the positive aspects while minimizing the negative. Bear in mind that sometimes the feasibility study plays a large part in deciding that the project should be abandoned. 3.6 ● Discussion SELF-TEST QUESTION 3.2 If the software cost were doubled, would the decision be the same? Summary A feasibility study is an investigation to check that a development is worthwhile. It is carried out at the start of a project. It assesses technical feasibility and costs. Cost-benefit analysis compares the cost of developing the system with the money saved by using it. The costs include development, additional hardware, maintenance and training. Exercises • 3.1 Suggest how a feasibility study would be conducted for each of the systems outlined in Appendix A. 3.2 Discuss the validity of using cost-benefit analysis, especially in socially useful appli- cations. BELL_C03.QXD 1/30/05 4:14 PM Page 34 Further reading 35 Further reading • A collection of papers that looks at the topic from a variety of perspectives is the fol- lowing title. Some non-computer case studies are presented. Richard Layard and Stephen Glaister (eds), Cost-Benefit Analysis, Cambridge University Press, 1994. Answers to self-test questions 3.1 There are a number of possible systems. For example, aids for disabled people. 3.2 Yes. The software cost is only a small part of the cost. The benefits over- whelm the costs. BELL_C03.QXD 1/30/05 4:14 PM Page 35 Logically the first stage of software development is to establish precisely what the users of the system want. The dominant part of this stage is communication between the users and the software developer or engineer. When the engineers are dealing with requirements, they are normally referred to as systems analysts or, simply, “analysts”. This is the term we shall use. As far as the users are concerned, they are sometimes known as clients or customers. We will use the term “user”. The story begins when a user has an idea for a new (or enhanced) system. He or she summons the analyst and thereafter they collaborate on drawing up the requirements specification. The user’s initial idea may be very vague and ill-defined, but sometimes clear and well-defined. Arguably, establishing the requirements is the single most important activity in soft- ware development. It typically consumes 33% of the project development effort. If we cannot accurately specify what is needed, it is futile to implement it. Conversely, we could implement the most beautiful software in the world, but if it is not what is need- ed, we have failed. In the real world of software development there are strong indica- tions that many systems do not meet their users’ needs precisely because the needs were not accurately specified in the first place. 4.1 ● Introduction CHAPTER 4 Requirements engineering This chapter: ■ explains what happens during requirements engineering ■ explains the nature of a requirements specification ■ explains how to employ use cases in specifying requirements ■ explains how to draw use case diagrams ■ suggests guidelines and checklists for writing good specifications. BELL_C04.QXD 1/30/05 4:15 PM Page 36 4.2 The concept of a requirement 37 Establishing the requirements for a software system is the first step in trying to ensure that a system does what its prospective users want. This endeavor continues throughout the software development and is called validation. The requirements specification has a second vital role. It is the yardstick for assess- ing whether the software works correctly – that it is free from bugs. The job of striving to ensure that software is free from errors is a time-consuming and difficult process that takes place throughout development. It is called verification. Errors in specification can contribute hugely to testing and maintenance costs. The cost of fixing an error during testing can be 200 times the cost of fixing it dur- ing specification. It is estimated that something like 50% of bugs arise from poor specification. The remedy of course is to detect (or prevent) bugs early, that is, dur- ing specification. It is easy to write poor requirements specifications for software; it is difficult to write good specifications. In this chapter we will examine guidelines for writing specifications. Remember that specifications are not usually written once and then frozen. More typically, requirements change during the software development as the users’ require- ments are clarified and modified. The task of analyzing and defining the requirements for a system is not new or peculiar to software. For generations, engineers have been carrying out these activities. For example, the following is part of the requirements specification for a railway locomotive: On a dry track, the locomotive must be able to start a train of up to 100 tonnes on an incline of up to 30% with an acceleration of at least 30 km/h/h. This statement serves to emphasize that a requirement tells us what the user (in this case the railway company) wants. It says nothing about how the locomotive should be built. Thus, it does not state whether the locomotive is diesel, coal or nuclear powered. It says nothing about the shape or the wheel arrangements. One of the great controversies in computing is whether it is desirable (or even possible) to specify what a system should do without considering how the system will do it. This is the relationship between specification and implementation. We will now look at both sides of this argument. On the one hand, there are several reasons why the requirements specification should avoid implementation issues. The prime reason is that the user cannot reason- ably be expected to understand the technical issues of implementation and cannot therefore be expected to agree such elements of the specification. To emphasize the point, how many users of a word processor really understand how software works? A second reason for minimizing implementation considerations is to avoid unduly con- straining the implementation. It is best if the developer has a free reign to use whatever tools and techniques he or she chooses – so long as the requirements are met. 4.2 ● The concept of a requirement BELL_C04.QXD 1/30/05 4:15 PM Page 37 . Suggest another system for which cost-benefit analysis is probably not appropriate. We will examine carrying out a feasibility study of the software for an ATM, outlined in Appendix A. An ATM is part. 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? 3.4 ● Other criteria SELF-TEST. 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 costing- based approach. How can