Ch. 4
Designing and Developing Decision Support Systems

The systems development life cycle (SDLC) approach is based on a series of formal steps, including the following seven steps: 1) Confirm user requirements; 2) Systems analysis; 3) System design; 4) Programming; 5) Testing; 6) Implementation; and 7) Use and Evaluation. Although different versions of SDLC vary in the precise number of steps and in the detailed definitions of those steps the above steps illustrate the approach. Decision-oriented design begins to address user requirements, but in SDLC user requirements need to be defined in great detail.

This formal SDLC approach is sometimes called the Waterfall model because of the sequential flow from one step to another. Each formal step concludes with preparation of a written progress report that must be reviewed and approved. Reviewers include both prospective users of the system and developers. For example, in Step 5, prospective users verify that the documented functions and capabilities and the user interface meet their needs. Developers verify that the system's internal interfaces are consistently defined and meet all technical requirements.

When the SDLC approach was first formalized in the mid-1970s, it provided structure and discipline to system developers. It was soon adopted widely for developing large-scale transaction-processing systems. SDLC is especially common when a formal contractual relationship exists between the developers of an application system and its eventual users because it provides written evidence that can be used to arbitrate any disputes.

The development of large, shared Enterprise-Wide Decision Support System is often an undertaking of great complexity. Organizational decision processes are complex and computerizing these systems so many people can share them increases that complexity. Using a methodology like SDLC provides one way in which business organizations can systematically approach the development of an Enterprise-Wide DSS.

When the systems development life cycle approach is used, then project plans must be carefully prepared. When developing requirements, it is best to start by determining the needs of all potential users, then analysts should identify the outputs that would fulfill those needs. Technical requirements should follow logical requirements, and constraints must be identified for all of the DSS system components. These requirements must be documented carefully and reviewed by the targeted users.

Several alternatives may exist for meeting the needs identified during the requirements and design steps. Each of these should be carefully reviewed and the best one chosen. Another choice to be made concerns the make or buy decision. If in-house development is not chosen, a request-for-proposal [RFP] may be required. During the design stage, technical processes must be managed, people and procedures prepared, and an installation plan developed.

In many situations a full-scale SDLC approach is too rigid for building Decision Support Systems, especially those DSS whose requirements are changing rapidly. User requirements, agreed upon at the first stage of the process, are rigidly specified with SDLC. Any significant change restarts the entire development cycle, as subsequent requirements documents are based on the agreed upon user needs. Changes are therefore often expensive; in fact, SDLC limits change rather than accommodating it.