# data[].attributes.body
The solution developed may, on the surface, meet the end user requirements but the functionality may not be acceptable. For example, if the system is tested using a small number of users then it may not fully function when many end users try to use the system concurrently.

The project manager, who is overseeing the development of the system, will need to keep very tight control over the whole development process and the team. The timescales defined must be adhered to otherwise the solution will not be developed within the 6 months deadline required by RAD.

# data[].attributes.body
The end user is involved at all stages and the system is implemented within 6 months. These should ensure that the final system fully meets the defined requirements.

End users do not have to define all the requirements of the system at the beginning of the process.

# data[].attributes.body
Another approach to shortening the project duration is rapid application development. The RAD methodology is based on a life cycle that is both iterative and evolutionary.

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.

# data[].attributes.body
Reduced time and costs: prototyping can improve the quality of requirements and specifications provided to developers. Changes cost exponentially more to implement as they are detected later in development, so early clarification of what the user really wants can result in faster development and less development costs.

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.

# data[].attributes.body
Confusion between the prototype and the finished system: end users can think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished. This can lead them to expect the prototype to accurately match the final system. Users can also become attached to features that were included in a prototype for user evaluation and then removed from the final system.

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.

# data[].attributes.body
A major problem with the traditional structures life cycle model is the duration of the activities that have to take place. There is usually a long time delay between the definition of the problem and the implementation of the solution. In some cases this may mean that the delivered system does not fully meet the current requirements of the organisation it has been designed for.

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

# data[].attributes.body
Prototypes are a first attempt at a design which are then extended and enhanced through the use of iterations. The prototyping methodology stresses the early delivery to the end users of an incomplete, but working, system which can then be changed following feedback from the client. Typically, a prototype simulates only a few aspects of the software system and may be completely different from the final solution that is implemented.

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.