Introduction The software development life cycle SDLC

120 Chapter 6 n Software development from the stage-wise model in that it allowed some limited iteration between stages – shown as ‘splashing back’ in Figure 6.4. Figure 6.2 highlights one of the main problems with the conventional waterfall-type approaches. As we move through the stages of the process the problem we are trying to solve is not static and moves on shown by the shifting problem ovals with respect to time in Figure 6.2. Thus, by the time we complete our analysis, design and building of the software system, the program we present to our user no longer solves the problem they currently have – i.e., the software is already obsolete. Another problem is that the user’s understanding of the problem is unclear and there are ambiguities in the subse- quent requirements specification. We cannot then guarantee that the system we design and develop is matching the user’s needs at all. The conventional approach to software development is, therefore, only really appropriate for projects that are: n short say six months to one year maximum – a typical student project length so that the problem does not have time to evolve; and n understood clearly – so that the initial requirements are captured accurately and subse- quent specifications and designs are very close matches with what is actually needed. You should, therefore, only use this approach for your own project if you are confident that you fully understand the requirements of the system or they have already been provided to you in an unambiguous way by the client. In most cases we cannot guarantee to fully understand the needs of our user – in which case one of the following approaches is perhaps more suitable for you to follow. •

6.5 The incremental model

Rather than delivering your software to your client towards the end of your project in one ‘big bang’ as the conventional models do, it might be better to deliver the system to them as a series of intermediate working sub-systems over a period of time. Thus, you add more functionality to the software at each release of the system. This means that you need to get an overall software structure kernel in place as part of the first release of your system. The other parts of the system are then brought on-line and released to the user as the system is developed. Thus, each release to the user provides added functionality to the existing system. In a project lasting around six months you would not really expect to have more than three releases. Figure 6.5 adapted from Ould, 1999 illustrates the incremental model – in this case there are three incremental releases for the system. Notice that the requirements for the system are gathered in the usual way at the start of this process. You then design and prepare the first release of the system. This includes a kernel for your program and the first component of functionality that will be useful to the client. The second phase of the process involves designing the second increment of the system and developing and implementing this within the existing system. This process continues until all the increments have been completed and the system is fully working. Figure 6.5 also highlights two other aspects of the incremental approach. The first point to note is that the design stages of the later increments are not as detailed as the design stage of the first incremental release. This is because the first increment of 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.