PROTOTYPING: THE 055 DEVELOPMENT METHODOLOGY

6.5 PROTOTYPING: THE 055 DEVELOPMENT METHODOLOGY

Because of the semistructured or unstructured nature of problems addressed by decision support systems, it is quite unlikely that managers and DSS developers have a complete understanding of the decision-making problem. They may not understand the scope of the problem, the types of appropriate models or technologies to apply, and/or the information needs. So most DSS are developed through the proto typing process. Proto typing is also known as iterative design or evolntionary development. (Other names are middle-out process, adaptive design, and incremental design.)

The proto typing development methodology aims at building a DSS in a series of short steps with immediate feedback from users to ensure that development is proceeding correctly. Therefore, DSS tools must be flexible to permit changes quickly and easily.

We show the details of the prototyping methodology in Figure 6.3. Prototyping is a process of building a "quick and dirty" version of a system. The evolutionary approach starts with overall DSS planning and some analysis. Users and managers, as well as an executive sponsor, must be involved. Other factors, critical for success or leading to failure are mentioned in the Opening Vignette and several of the DSS in Action and DSS in Focus boxes.

Next, the analysis, design, and prototype implementation phases are iteratively performed until a small prototype is sufficiently developed (decided on jointly by the developers, managers, and users). Then the final implementation of this part of the system takes place. Simultaneously, further iterations occur in the loop of analysis-design- implementation-system prototype as other subsystems or capabilities are added to the deployed system until a fairly stable, comprehensive system evolves. This is how the systems in the Opening Vignette and in Case Application 6.1 were developed.

The first major decision involves which subproblem to build first. The user and the developer jointly identify a subproblem for which the initial DSS prototype is to be implemented. This early joint effort sets up initial working relationships between the participants and opens the lines of communication. The subproblem should be small enough that the nature of the problem, the need for computer-based support, and the nature of this support are clear or quickly established. It should be of high interest value to the decision-maker. In the Opening Vignette, it was the employee benefits subsystem that provided intense visibility for the system because everyone used it. For Case Application

6.1, it was the small calcine plant and mocked up versions of several reports (See DSS in Action 6.2). This approach helps to excite managers and users about the potential of the system they want.

A prototype is ideally a small but usable system for the decision-maker. No major

PART II DECISION SUPPORT SYSTEMS

through all the steps of the system-development process quickly, though on a small scale. The system should, of necessity, be simple. As the system evolves, it must be evaluated continuously. At the end of each cycle it is evaluated by both the user and the

developer.

The interaction of user, developer, and technology is extremely important in this process. There is a balance of effort and cooperation between user and developer: The user takes the lead in the use and evaluation activities, and the developer is stronger in the design and implementation phases. The user plays an active role, in contrast to the situation in conventional system development, where the user often operates in a reactive or passive role. Note that the specification of needed data or information evolves as the prototype evolves along with user and developer experience.

As was described in Chapter 2, decision-makers must share a common frame in order to make intelligent decisions. McCarthy and McCarthy (2002) advocate that managinga technology development group requires setting such a shared vision of a project and setting the rules for how team members are to work together. Malhotra et al. (2001) describe how

a flexible group support system was continuously modified to support an engineering product design team. The GSS development team was eventually required to attend the technical sessions of the product design group so that its members could gain first-hand knowledge of how the system was being used, and how the design group wanted it to be modified--that is, to share the vision with the users. System development teams are often scattered around the globe, sometimes working for other companies. The need for enhanced collaboration and teamwork is paramount. The vision is not only to build better teams by leveraging the best minds and common tools, but also to potentially bring customers into development. Project management engagements are moving to a higher level of interactivity, requiring collaboration management (see Johnson, 2001). GSS can assist software developers. New

. CASE tools include collaborative software; for example, CollabNet Source Cast (Web- based), VA Software, and Quovix. These Web-based systems track software versions, provide online collaboration, and a repository (see Fry, 2002).

Evaluation is an integral part of the development process and is the control mechanism for the entire iterative design process. The evaluation mechanism is what keeps the cost and effort of developing a DSS consistent with its value. At the end of the evolution, a decision is made on whether to further refine the DSS or to stop.

H the prototype is OK, we move to formal implementation of the DSS, which could include all the user training, and so on. Subsequent cycles expand and improve the original version of the DSS. All the analysis, design, construction, implementation, "and evaluation steps are repeated in each successive refinement.

Years ago, under the traditional SDLC, the analyst obtained information requirements and other data from the user and went away for a long period of time to develop a system. Over time, the business environment, the organization, the users' needs, and even the users might change. When the system was delivered, it might not meet anyone's needs, or the champion may have left the organization (for an excellent example of this situation, see Vedder, Van Dyke, and Prybutok, 2002). In prototyping, looping back to early stages implies that the initial analysis was incomplete, as is expected.

The iterative design approach produces a specific DSS application. The process is fairly straightforward for a DSS designed for personal support. The process becomes more complicated, although not invalid, for a DSS that provides group support or organizational support. Specifically, there is a greater need for mechanisms to support communication among users and developers. There is also a need for mechanisms to accommodate

CHAPTER 6 DECISION SUPPORT SYSTEM DEVELOPMENT

Most DSS and Web sites are developed with the prototyping methodology. One reason is that prototyping allows the developers to get a usable (perhaps partial) system up and running relatively fast. And if one views DSS and Web sites as never complete, but always in a state of evolution, prototyping is an ideal methodology (see DSS in Focus 6.18). Some prototyping of non-DSS is performed with the same software packages with which the DSS is developed, including DSS generators and DSS tools like report generators, GUI generators, and spreadsheets. An application generator is often nothing more than a collection of prototyping tools that enables a full range of system development activities and is very similar to a DSS generator.

Specifically, DSS development is done through proto typing for the following reasons:

 Users and managers are involved in every phase and iteration. The iterative nature allows users to be involved in system design, which is important for DSS. This approach stems from a need for user expertise in the design and recognizes that successful implementation is more easily achieved with active involvement.

. Sometimes this involvement is called the joint application development (JAD) method.  Learning is explicitly integrated into the design process. Since the users are involved

in system design, both users and system developers learn about the decision-making, the ill-structured, complex problem, and the technologies that can potentially be applied to it.

 Prototyping essentially bypasses the formal life-cycle substep 7-information requirement definition (see Table 6.1). Requirements evolve as experience is gained. This strategy assumes that the requirements are only partially known at the beginning of system development, and it attempts to clarify users' needs by actively involving them in a low-cost, fast-feedback development process.

 A key criterion associated with prototyping is the short interval between iterations. The feedback must be fast. This criterion results from the required learning process: Accurate and timely feedback is a prerequisite to effective learning.

 The initial prototype must be low-cost. It must fall below the minimum threshold of capital outlays requiring formal justification. The development of a prototype may be

a risky decision, particularly for a DSS. However, because the benefits of a DSS are often intangible, relating to such issues as improved decision-making or better understanding, a high initial investment may result in a decision not to proceed (see DSS in Focus 6.14).