The stage-wise and classical waterfall models conventional models

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.

6.6 Prototyping 125

1. Requirements capture

During requirements capture, a prototype is used to pin down and refine a user’s require- ments for the system. It can also be used during design to test the user interface – assessing how well the user can use and navigate around the system. According to Knott and Dawson 1999: 42, ‘Prototyping provides an effective method for generating feedback about what is good and what is bad about an idea and it is often the only really effective method for doing this’.

2. Experimental prototyping

Experimental prototyping is used when one is unsure about the technical solution to a problem. For example, if you are developing a new algorithm, working in an emerging field, working on a new hardware platform, or using a new application or programming language, it is often useful to produce an experimental prototype to assess the feasibility of your proposed solution. You might discover, for example, that you will need to re-design your proposed solution because it is inefficient and runs too slowly, or you might discover that your assumptions about the system were incorrect and an alternative strategy needs to be undertaken. Alternatively you may discover you don’t have the technical ability to use the programming language or the hardware platform or software application you are intending to employ. There are two things you can do with a prototype once you have developed it. You can throw it away and start the development of the system from scratch throw-away prototyp- ing , or you can develop evolve the prototype into the final system evolutionary prototyping . These two approaches to prototyping are discussed in the following sections.

6.6.2 Throw-away prototyping

There are a number of approaches you can use to develop a throw-away prototype, depend- ing on what you want to achieve, explore with the user or experiment with. The following are some ideas you might want to use in developing your own throw-away prototype. n The prototype need not be developed on the same hardware platform as the final system. For example, you could mock-up some sample screen designs using a word-processor or drawing package. If you were going to develop a system for a Pocket PC or a mobile tele- phone, you might develop a mock-up using an emulator on a PC first. n You might develop a prototype in a different programming language. For example, if you wanted to develop an experimental prototype to evaluate a new algorithm you might test out that algorithm by developing it quickly in C first. You might then throw this code away before re-coding the final system with a graphical user interface in Visual C++™. Alternatively, you could develop a user interface for a multimedia product using a web-page editor. Knott and Dawson 1999 discuss the following techniques for [throw-away] prototyping: n You could simplify the system by partitioning the program such that a prototype could be built for part of that system. For example, you could prototype the graphical user interface first, leaving the underlying functionality until later.