Ch. 4
Designing and Developing Decision Support Systems

How do we plan and implement new Decision Support System projects? What does it mean to design a DSS? How do we develop DSS? Who develops a new DSS? When do we build DSS and when do we buy DSS packages? Both managers and MIS professionals need to explore these questions. We all know that a company does not receive any advantage from a great idea for a Decision Support System until the new system is built and successfully implemented.

One group of DSS experts develop their recommendations for building Decision Support Systems in the traditional systems analysis and design literature (cf., Thierauff, 1982). A second group has prescribed and explained an iterative, prototyping, or "quick-hit" approach for designing and developing DSS (cf., Sprague and Carlson, 1982). Some authors refer to both types of approaches without explaining clearly the advantages and disadvantages or contingencies favoring a specific approach or some combination of approaches. A third approach to building DSS is to let managers develop their own personal DSS; this is called end-user development. In general the DSS prescriptive literature on design and development is based on personal experiences, case studies, the general IS development literature, and a wide variety of DSS "war stories" from developers. Very little empirical research has been conducted on design and development methodology.

Because of design and development problems some highly innovative and potentially useful Decision Support Systems have been failures. The problem, often, is that the DSS is designed and developed from the perspective of the programmer and developer rather than from that of the manager and user. Sequences of commands or icons may be obvious to the programmer, but may be totally unknown and puzzling to the DSS user. From a prescriptive standpoint, effective DSS need to be user oriented. The key issue is what design and development process and procedures can increase the likelihood that a usable and effective DSS will be created and built.

Building DSS is often very expensive. So, it is important to investigate alternative design and development approaches. We want to choose an approach that increases the chances the DSS will be used and will accomplish its purpose. We need to remember DSS are designed and developed to help people make better and more effective decisions than they could without computerized assistance. Building any type of DSS is difficult because people vary so much in terms of their personalities, knowledge and ability, preferences, the jobs they hold, and the decisions they need to make. Also, DSS must often meet a diverse set of requirements. This wide variety of differing requirements has led to the design and development of a wide variety of DSS capabilities and systems.

The following discussion separates out the diagnostic design and feasibility portion of an overall systems development process. The phrase systems development life cycle (SDLC) is the most commonly encountered term used to describe the steps in a traditional systems development methodology. SDLC is also sometimes known as the applications development life cycle approach and involves (1) initiation and diagnosis, (2) acquisition (build or buy), and (3) introduction of the new system.

As mentioned above, the two commonly prescribed alternatives to the SDLC development approach are a prototyping approach and end-user development of DSS. In both of these approaches a portion of the DSS is quickly constructed, then tested, improved, and expanded. Prototyping is similar to a related approach called rapid application development (RAD).