Build The software development life cycle SDLC

122 Chapter 6 n Software development While these estimates of values and costs are subjective, they do provide you with a relative measure of the importance and effort required for adding certain aspects of functionality to your system. By dividing the value of the increment by its estimated cost the value to cost ratio you can determine the added value that increment will pro- vide to your system and draw up a priority list – identifying the order in which the in- crements should be tackled. Note that estimated costs and values do not remain static as the project progresses and after each increment is released it is worth revisiting your cost and value estimates to determine if any changes need to be made. For example, having developed part of the system in one release your understanding of the coding in- volved may have improved and you might wish to revise down some other develop- ments costs particularly if you can reuse some code. Conversely, having completed an increment, you might realise that your cost estimates were too low and revise up the re- maining estimates accordingly. Having provided the user with another release they might have new ideas or change their mind on what aspects of the system are important to them. This may result in you having to readjust your value estimates and change your prioritise accordingly. The second example below provides an outline of how value to cost ratios might work in practice. Example 1 – Two increments Suppose you were developing a system for a user that logged and statistically analysed calls to a help desk. You might release this system to the user in two increments during the course of your project. The first release would provide the overall structure for the system and would allow the user to log calls to the help desk. The second release would provide the added functionality of the statistical analysis of the logged calls for example, identifying peak periods, common problems, regular callers, etc.. Thus, by providing the user with a partially working system early, it allows them to become familiar with the system’s operation before the added complexities of the analysis component are brought online. The first release would also enable them to start gathering data into the system earlier – data that would otherwise have been lost had they waited for a fully working system later on. This also means that you can check that the right information is being gathered by the system for subsequent analysis by the second release. Example 2 – Multiple increments Table 6.1 provides an example of a valuecost table for a student project that aimed to develop a simple web site to support a local, amateur football club. The club wanted to keep members and potential members informed of various aspects of the club including: match fixtures; results; important dates presentation evenings, etc.; duty rotas who was responsible for cutting the grass, assisting the referee on match days, etc.; contact details for the club committee and other officials; photograph 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