Functional specification Requirements capture

6.5 The incremental model 121 Figure 6.5 The incremental model Source: Adapted from Ould 1999. the system must also include the design of the all important system kernel struc- ture. Subsequent releases just need to focus on the individual increments and hence the design stage of these increments is reduced. The second important point to no- tice is that the increments are not all the same size – some will add more functional- ity to the system than others, and some will be harder to produce than others. Consequently, the design, build, test and implement stages of each increment may not be the same size. When planning to undertake an incremental development it is important to have an outline plan in place for the entire system at the start. You cannot just plan the easiest parts of the system, develop and release these to the user, and worry about the more complex aspects of the system later. It may be that later, as you tackle the harder parts of the development, you discover a fundamental flaw with your ideas that require you to rework significant parts of your program. This would mean that earlier, easier work that you did on your project would be wasted. You must ensure that you have a good understanding of how the overall system will operate before beginning work on the intermediate releases. When deciding which increment to complete next in a development it is useful to draw up a table of value to cost ratios. Value represents, on a 1-to-10 scale, the usefulness this increment will add to your system; 10 being extremely useful if not essential, while 1 represents perhaps ‘nice to have’ features that will be good to include in the system if time allows. Cost is also measured on a 1-to-10 scale and can be measured in terms of the time it will take you to develop that feature. For example, some function- ality that you estimate will take 15 weeks to design, program and test may be assigned a cost value of 10, whereas a simple piece of functionality that may only take a day’s programming may be assigned a cost value of 1. 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