The main purpose of a prototype is to allow the end users of the software to evaluate the proposals for the design of the software by actually trying them out, rather than having to interpret and evaluate the design based on descriptions.

Prototyping can take place at different stages of the development life cycle, but the use of this methodology must be planned to ensure maximum feedback is obtained from the end users of the system.

This methodology is popular because it can be used to verify that what the designer has conceptualised is what the end user requires, thereby fully meeting the needs. End users can often find it difficult to define their exact requirements. This may be because they do not exactly know or find it difficult to imagine how, for example, the user interface will need to look when the solution has been completed.

Prototyping can also be used by end users to describe requirements that the designer may not have considered, so controlling the prototype can be a key factor in the relationship between the designer and the end users.

By creating a prototype, concepts can be demonstrated, design options can be tried out and problems with possible solutions can be investigated. For example, a prototype of a screen design for a user interface could be developed to test the appropriateness of the layout. It would not be necessary, in this case, to develop the data files that are queried or written to using the screens. However, when the screen design has been agreed, then the data files can be developed as a prototype to ensure that the end users are happy with the way they interact.

There are two main ways of prototyping:

• Evolutionary; when an initial prototype of the system is developed and evaluated by the end users. Using the feedback from this a second prototype is developed and then evaluated. This process continues with each prototype and evaluation making the system closer to what the end users require. Finally, on the last evaluation, the system meets all the requirements.
• Throw-away; when a working model of various parts of the system is developed after a short investigation. The prototype is developed and evaluated by the end user, but this prototype is not used in the final solution. This enables the end users to give, and receive, quick feedback. This means that any refinements can be done early in the development. Making changes early in the development life cycle is cost effective because there is nothing to redo. If a project is changed after considerable work has been done, then small changes could require large efforts to implement since software systems have  many dependencies.

This problem could be solved by using a different software development methodology.

Excessive development time of the prototype: the main aim of prototyping is that it is supposed to be done quickly. It is very tempting to develop a prototype that is too complex, leading to the development time being extended. This would also lead to an increase in the cost of the resources needed.

It would not be appropriate to use this methodology where user requirements are well established or the system is a standard one used by the organisation.

Improved and increased user involvement: prototyping requires the involvement of users. This enables them to see and interact with a prototype providing better and more complete feedback and specifications. Misunderstandings that can occur when each side believes the other understands what they said are fewer. The end users know the problem better than the designer, so increased user involvement can result in a better and more appropriate final product that is likely to satisfy the end users' needs in terms of look, feel and performance.

Feedback: the designer can obtain feedback from the end users early in the project. This will, hopefully, ensure that the software made matches the software specification. This can also check that the deadlines proposed can be successfully met.

One of the main aims of RAD is to produce a software solution within a relatively short duration. The typical duration of a RAD system is less than 6 months. This duration is generally considered to be the longest period over which user requirements will stay static.

The short duration, along with increased opportunities for user involvement, are the two main benefits of RAD. These will, hopefully, ensure that no changes to the end user requirements will appear towards the end of the development process. During the RAD process, there are a number of tools that can be used by the developers to build the graphical user interface (GUI) that can be seen and evaluated by the end user. The use of these tools will assist end users to visualise the GUI and to provide helpful feedback to the development team before the system is implemented.

RAD has two main features. The first is the use of joint development application (JAD) workshops. There are requirement gathering workshops which aim to develop a set of requirements that, hopefully, will not change before the system is implemented.

The second feature of RAD is timeboxing. This means that the requirements of the system are defined in small 'chunks', each of which is considered using a JAD. Each 'chunk' is allocated a specified timescale which must not be exceeded. At the start of each timebox the objectives are defined and, at the end of the timebox, these are evaluated. If requirements are not successfully completed, then they may be added to another timebox or dropped. The requirements that are not implemented are those with the lowest priority because they have been prioritised.

If the requirements of several consecutive timeboxes cannot be completed, then the overall system may need to reviewed. This should ensure that the incomplete requirements do not pile up and cause excessive delays to the overall product.

RAD attempts to maintain overall control over the development process, but also provides continual feedback on the progress of a project. This means that if there is any slippage in the defined time schedule, then plans can be adjusted.

RAD is also helpful to the end users of the system being developed. They are party to the evaluations, which means they are continually involved. This involvement should ensure that the system, once developed and implemented, fully meets their defined requirements.