Which development approach should I use?

6.11 Top-down and bottom-up development 135 In order to test your system as you proceed with a top-down approach, you would have to develop a number of stubs in order to replicate the behaviour of lower level components of the program before they are actually written. According to Knott and Dawson 1999: 162, a stub can be: n a dummy routine that simply returns, doing nothing; n a routine that simulates the behaviour of a module by returning constant values; or n a routine that simulates a module by asking the user to input suitable return values. The advantages of using a top-down approach are that a working version of the system is produced quickly, enabling the user to get an idea of the overall look-and-feel of the system. In addition, by providing a working system early the user can spot any serious omissions in the top level design of the system. However, there are some drawbacks to this approach. First, some of the ‘difficult’ components of the system will probably be at the lower levels. Leaving these until later may prove costly if they lead to problems that are difficult to overcome. Second, as lower levels are often concerned with data input and output it may not be possible to get a feel of how the system is working until these components are written and the system is able to handle appropriate data.

6.11.3 Bottom-up development

The bottom-up approach is the opposite of the top-down approach in that you begin by coding the lowest levels first before bringing these components together to produce the fully working system. For example, in the case of Figure 6.7, you might begin by working on the Long-Term Analysis component of the system first. This may involve the develop- ment and implementation of a complex algorithm so you might want to ensure that you can get this working sooner rather than later in your project. You will probably under- stand that the higher level components for example, the Main Menu will be easy to complete, so it would make sense to tackle the harder parts of the system first rather than leave these until the end. Applying a bottom-up development approach to the program in Figure 6.7 results in coding the modules in the order shown in Table 6.3. As you continue to build the lower-level components of your system, you need to consider how you will bring these together in the final system. This should be done incrementally, where the components are added to the system as they are completed and the system ‘grows’ over time. However, before a module is added to the system it should be tested in isolation to ensure that it behaves in the way it is intended. Quite often, developers will produce test harnesses – structures of code that enable lower level modules to be tested in isolation. However, these structures take time to write and you may be better coding higher levels of the system to act as harnesses to save time. While the bottom-up approach enables you to test out the lower levels of detail in your program sooner, it does have a number of disadvantages. For example, there is no visible system until the end of the development when the higher levels are developed. This can mean that progress appears slow and may mean that any major design omis- sions are not spotted until near the end of the project when it is too late. In theory, you could swap the implementation of some modules around and still be pursuing a particular top-down or bottom-up development approach. For example, there would be no harm in swapping over the implementation of Long-Term Analysis and 136 Chapter 6 n Software development Short-Term Analysis. In this case, the Short-Term Analysis function may be more difficult to implement, so you might want to tackle this sooner in order to get it working. You will probably want to complete Data Entry before Data Analysis although in theory they could be swapped in any approach as you will want to have ‘read in’ some data to work with before you can implement and test the Data Analysis and its sub-functions. In practice you should mix and match the approach to the development you are undertaking. It may be appropriate, for example, to code some components from the bottom-up to test out a difficult algorithm or routine and then tackle the remainder of the system top-down to provide the user with a tangible view of the system overall. Once again, whatever you decide to do, you should be able to justify this to your supervisor and examiners, and you may have to include some discussion on your chosen approach in your final report. •

6.12 Verification, validation and testing

6.12.1 Introduction

There are three ways that you can deal with errors in your program:

1. Prevent or avoid introducing them in the first place. You achieve this through

practice and experience, and following a development process such as those out- lined earlier.

2. You can detect and remove the errors. You should hope to do this as early as possible

as the longer errors remain in your code the greater the impact they will have and the greater effort will be required to remove them later when the code has grown even more. Verification, validation and testing VVT are concerned with this issue.

3. You can tolerate them. There may be a certain level of quality that your client, user,

supervisor and examiner are willing to accept or tolerate. You will know from your dealings with them what is acceptable and what is not. If a high level of quality is required it may be better to reduce the scope of your system in order to minimise the number of errors within it. However, if your user is demanding a high level of functionality, they may be willing to compromise a little on quality to get what they want. It is probably better to have an 80 functional system working 100 correctly than a 100 functional system working 80 correctly – the former appearing much more professional and robust. In addition, in the former case, the remaining 20 of functionality you have left out could always be identified as further work in your report and the 20 of problems in the latter case may take a long time to sort out if the code is badly written. Discuss these alternatives with your supervisor and client so that an appropriate balance can be reached. Of these three options, this section is concerned primarily with VVT.

6.12.2 Verification

Verification is the process of checking that we are performing our development correctly. In other words, are we sticking to our project plan and are we performing the stages of the development process properly? For example, looking at the conventional waterfall model, verification involves checking that we are performing each of the stages correctly – by