The earliest ’model’: build-and-fix

6.5 The incremental model 123 album players, trips, matches, etc.; information about the club joining fees, train- ing days, etc.; and a feedbackdiscussion section. After interviewing the client the student was able to prioritise each of these requirements according to their value on a 1-to-10 scale. For example, having an attractive home page was identified as the most important feature of the site and was assigned a ‘value’ value of 10. Having a photographs section was deemed least important and this was assigned as ‘value’ value of 4. The student then estimated how long each of these requirements would take to develop and produced a cost scale. In this case the student estimated that setting up a discussion forum on the web site would take the most effort needing to develop a database in the background to store comments and link threads together and consequently assigned this an effort score of 8. Conversely, setting up a page with contact details for club officials would be relatively easy and this was assigned an effort score of 4. The resulting Value-Cost table is shown in Table 6.1. Once the student calculated the value-to-cost ratios, she was able to prioritise the order of the development shown in the last column of the table. The student worked on the homemain page first, getting an overall structure in place and showing this to the client. With a few minor changes and suggestions from the client, the student then went on to design and develop the club information page and so on. By prioritising the release of the system in this way, the student ensured that only those additions valuable to the site were implemented in order. It reduces the chances of ‘gold plating’ adding features to a system that cost a lot of effort for very little reward unless time allows. If the student ran out of time on the project they would at least have added a number of useful features to the system. Any features not included may be identified as future workenhancements. Example 2 continued Functional Increment Value Cost VC Ratio Priority Homemain page 10 5 2.0 1 Match fixtures page 8 6 1.3 4 = Results page 6 6 1.0 7 Diarydates page 7 6 1.2 6 Duty rota page 8 6 1.3 4= Commentsfeedback page 5 8 0.6 8 Committee contact details 6 4 1.5 3 Photographs 4 8 0.5 8 Club information page 8 5 1.6 2 Table 6.1 A valuecost ratio table for an amateur football club web site development 124 Chapter 6 n Software development Advantages n The user gets something early so that they can get an idea of the system’s capabilities and an idea of what you are able to produce in the longer term for them. Thus, the userclient can provide early feedback if something isn’t right or improvements can be made. This is particularly useful if the system requirements were not entirely clear at the project’s outset. n By delivering something early it gives you a sense of achievement and the userclient a clear understanding that progress is being made. n It can help you plan and manage your project more effectively. By breaking the project down into a number of deliverables, you will be able to plan, reasonably accurately, how long each deliverable should take to develop. In addition, when you are controlling your project, any slippage in meeting a deliverable will provide an early warning that your project may be falling behind schedule and you will be able to do something about it. n The user does not need to learn how to use the entire system in one go. They can be introduced to the system over a period of time, becoming confident with its func- tionality before later releases add to its complexity. Disadvantages n It might be difficult to break your program down into a series of sub-systems that are worth delivering to the clientuser as separate units. For example, you don’t want to end up providing a large number of small deliverables to the user that appear to provide little improvement over earlier releases. This wastes your time and can lead the user to think that you are making little progress and wasting their time too. n Although it is advantageous to meet your userclient regularly, additional contact with them can encourage them to identify too many improvements. They may identify more changes than you have time to implement and the changes they request may take your project in a direction that is inconsistent with the requirements of your course. •

6.6 Prototyping

6.6.1 Introduction

The conventional and incremental models that have been introduced can be used in projects where the problem is well defined, the requirements can be clearly elicited and defined, and the technical feasibility of a solution is understood. However, in many projects it is often difficult to pin down exactly what is required from a software system at the start of the project andor we may not have a clear understanding of the technical issues surrounding that system. This is often the case in student projects where they are working with a supervisor or client for the first time, perhaps in a new field or in a devel- oping research area. In these cases it is useful to produce a prototype in order to:

1. explore the requirements of the system with the user – requirements capture, andor

2. explore the technical feasibility of a system – experimental prototyping.