[an error occurred while processing this directive]

Book Contents

Ch. 4
Designing and Developing Decision Support Systems

Chapter Contents
Previous Page
Next Page

Rapid Prototyping

All of the different versions of rapid prototyping accommodate and even encourage changes in the requirements of a proposed Decision Support System. A typical prototyping methodology usually includes five steps:

  1. Identify user requirements.
  2. Develop a first iteration DSS prototype.
  3. Evolve and modify the next iteration DSS prototype.
  4. Test DSS and return to step 3 if needed.
  5. Full-scale implementation.

Prototyping evolved in response to perceived deficiencies and limitations of the SDLC approach. In a prototyping development approach, DSS analysts sit down with potential users and develop requirements. These requirements are specified in general terms and should evolve from the decision-oriented diagnosis and design. The analyst then develops a prototype of a system that appears to work. DSS analysts use tools such as Database Management Systems and DSS application generators that support rapid development. Analysts focus on capabilities rather than resolving problems. A prototype may not resolve how to access a real database, or what "help" screens are needed, and other capabilities that require extensive development time. The prototype is something that users can try out, react to, comment on, and eventually approve with a high confidence level that it meets their needs. Missing features are added later, once users are satisfied with the way the prototype works. Rapid Application Development (RAD) specifies incremental development with constant feedback from potential users. The objective of RAD is to keep projects focused on delivering value and to keep clear and open lines of communication. In most situations, oral and written communication is not adequate for specification of computer systems. RAD overcomes the limitations of language by minimizing the time between concept and actual prototype implementation.

Once approved, a prototype can be expanded in the development environment or the prototype can be used as a specification for a DSS developed in a language like Java, C or C++. When a prototype is reprogrammed, the prototype serves as a detailed specification that is turned into an operational system. The best prototype development approach is to have the actual prototype evolve directly into the finished product. In this approach the prototype is attached to a database and features are added to it, but it remains written in the high-level tools originally used for prototype development.

Compared with the SDLC approach, prototyping seems to improve user-developer communication. It introduces deliberate flexibility and responsiveness into the development process. Change is no longer something to be avoided; it is built into the process and encouraged. The system that is developed is more likely to meet user needs than is a system developed through SDLC.

Prototyping can extend the development schedule if it is improperly used. Managers and developers are often tempted to "tinker" with a DSS and make changes that do not really improve the usability of the finished product. If managers and developers want to build a useful system and meet project deadlines, then they must manage and control systems development efforts.

[an error occurred while processing this directive]