Designing and Developing
A Computerized Decision Aid - A Case Study

D. J. Power
College of Business Administration
University of Northern Iowa


This is a case study of the design and development of a process oriented decision aiding program. The case covers the period 1975-1984.

This is a working paper so please request permission prior to quoting from it.


DECision AID, or the shortened form DECAID, is a collection of heuristic programs that helps people direct a systematic decision process, categorize a decision situation, select procedures, apply procedures, evaluate goals and alternatives, and collect information about a specific decision situation. Applications for the system are in teaching managerial decision making and in helping organization executives make important decisions. Other applications may be found later through ongoing research to improve the system. The name DECAID is no longer used for the software as part of an agreement in 1984 with Digital Equipment Company.

Decisions made regarding the content and structure of the DECision AID program and the programming and evaluation of the different versions is the focus of this case study.  Much of the material that follows on Versions 1 and 2 of DECision AID was originally included in Power (1977, chapter 3).

Three major objectives of my computerized decision aids research program were stated more than 20 years ago (Power, 1977):

1) to develop a decision support system (DSS) for use in actual strategic decision situations in organizations;

2) to develop an experiential instructional system that will help people improve their decision making and inference behavior in strategic decision situations; and

3) to conduct research that may explain how individuals and groups make decisions and how decisions should be made.

Design and development of a program called "DECAID" began in the fall of 1975 as a project for a course entitled Human Information Processing and Decision Making Behavior. Initially, the objectives of the project were very limited. The extensive design and development activities that have since occurred were not planned or considered at that time.

Version 1

What motivated the initial design of DECision AID? Marketing and management courses sometimes require students to write a case analysis. This task is often difficult because students have little experience in case analysis and decision making. Also, it was clear that people have problems making decisions. Decision makers seem to place most of their emphasis on the "right" answer rather than on the decision-making process. Computerized support for analyzing cases seemed to be both feasible and desirable. A software system could not only help students learn about decision making, but might also reduce some frustrations as well as the time spent on case analysis. Davis's (1974) ideas supported this notion.

Against this background, the suggestion that students could work on an optional project as partial fulfillment of the requirements for the Human Information Processing and Decision Making course, was the stimulus which led to the DECision AID project. The course instructor, Gerald Rose, approved a project to program materials which might help people make nonprogrammable (Simon, 1960) decisions. At an initial meeting with him, many of the concepts which had the most influence on the early versions of "DECAID" were discussed. They included Churchman's (1971) ideas about inquiring systems, Mitroff's (1974) ideas on errors of the third type, and Janis's (1973) work on premature closure. Also during that conference Rose discussed his efforts to develop computer assisted instruction materials in some of these topic areas.

What about programming the DECision AID? During the summer of 1975, Rose had been developing instructional materials,using the Instructional Dialogue Facility (IDF) on the Hewlett-Packard 2000/F Computer System. And in the fall of 1975 when the DECision AID project began, IDF appeared to be an ideal vehicle for developing programs. The advantages of programming with the author facility of IDF (Hewlett-Packard, 1975) included the following: 1) no programming knowledge was required; 2) BASIC programs could be incorporated in the author's course; 3) editing capabilities of several different kinds were provided so that the author could continually revise and improve materials; 4) searches of two different types (for a specific word and for words in context) could be specified by the author for answer processing; 5) alphabetic characters or numerical answers were acceptable user responses; 6) user performance statistics and responses could be saved for later analysis; 7) users leaving the computer terminal in the middle of a session could restart the program later at the point at which they left off; and 8) users could request hints if the author had provided them.

What about the original design? "The DECAID idea was that questions could be used to build models of the decision making processes. These questions could then be programmed using an interactive programming language to aid people in making decisions " (Power, 1977, p. 28). The first program was designed 1) to help people categorize their decision situation, as programmable or non-programmable; and 2) to help people define a decision question and avoid the "error of the third type" (defining the wrong problem).

In that first version, the "key-word search" feature of IDF was intriguing and so an attempt was made to write a program to help a person develop a decision question. Then based on a search through a large number of key words, users would receive recommendations about their decision question. But, a question evaluator was much more difficult to program than anticipated and this idea has not been used in recent versions of DECision AID.

After considerable research and thought, a flow-chart was drawn and the original "DECAID" was programmed. During that initial programming effort, a major problem was encountered. It was difficult to change the content of the model and its branching structure because the editing features of IDF were complex and time consuming to use. At that time the cause of the problem was attributed to a lack of planning, a failure to have more detailed flow-charts, and a vague conceptualization of the DECision AID.

The first model contained four questions in a branching structure intended to help people determine whether their decision question was programmable or non-programmable. And it contained information on a dichotomy in decision situations between problems and opportunities. A question asked users to make that distinction. This program demonstrated that it was possible to build an interactive decision aid. Also, that first program led to the conclusion that the computer could serve as a memory aid; it could store many verbal models and it could help people to retrieve them and apply them in decision situations.

Version 2. Release 1

In January 1976, much thought and further research about the decisionmaking process suggested that the decision aid model should encompass the entire decision-making process. And it was decided to try to help people avoid errors of the third-type and premature closure (stopping search before a "best" definition or alternative is found), despite uncertainty about whether that was possible.

Version 2 of DECision AID was designed largely from scratch; the original program was divided into three pieces. Also, a broader model of the decisionmaking process (Harrison, 1975; Easton, 1973) served as the conceptual starting point. In this version, the first model designed and programmed was a module intended to give users information about the program. It had an entrance routine that contained questions which controlled branching to other programs and an exit routine which provided a structured end to a DECision AID session. This original control system was not sophisticated, but it served immediate needs.

The next section programmed was called QUEST, the question definition phase. This program emphasized reducing the third-type error. The initial design and programming efforts in QUEST concerned the logical and rhetorical characteristics of a decision question (Martin and Ohmann, 1964). It seemed plausible that if people were careful about the structure of their decision question, they might avoid the third-type error. This focus on the logic and rhetoric of the decision question was coupled with instructional materials about the third-type error.

After development of QUEST, the planned first phase in a prescribed decision process, design and programming efforts centered on a goal-definition model. This program, called GOALS, had users list and evaluate goals relevant to their decision situation. A model called ALTGEN was then developed which was intended to help people define and create alternative courses of action. A later model called ALTEVA, an alternative evaluation phase, was not completely programmed in release 1. Two programs were planned in January 1976: CHOICE, a pro and con comparison of alternatives; and AUDIT, a decision audit. By the end of January 1976, most of the control system and QUEST had been programmed.

Research and design proceeded on the rest of the program, but it was not until early in June 1976 that the program was functioning in its entirety.

During the programming of QUEST, it became obvious that IDF could not store user inputs, like a decision question, except in BASIC programs. Programming with IDF became increasingly frustrating. Therefore, while the author learned BASIC, much attention was directed toward instructional design and educational objectives for DECAID. After the author learned BASIC and began a job in the computer lab in the College of Business (at the University of Iowa), programming of DECAID moved at a faster pace and many BASIC programs were added to the original IDF program structure.

In June of 1976, instructional materials, including a management case; a student manual; a performance measure; and an attitude questionnaire, were developed for a developmental testing project. Later that summer the first developmental testing cycle of DECAID was conducted, using student volunteers.

Students came to the computer lab and a proctor helped them with problems they encountered while using DECAID. Notes were made about the problems. In addition, students were encouraged to make suggestions about the programs. The results were encouraging, and are reported in more detail in Power and Rose (1977 and Power (1977). Although it was not possible to keep a record of the questions and responses of users, i.e., protocols, some information was collected using the response files and the statistical files of IDF. At the end of July and in early August 1976, the results of the developmental testing were reviewed for possible changes in DECAID. The response files maintained by IDF were somewhat useful, but the statistical data collected were not helpful for modifying DECAID. IDF maintained for each question in DECAID the number of attempts and the time required by each student to get the "correct" answer. Because the notion of a "correct" answer had no meaning in the context of DECAID and because most students required only one attempt to make a recognizable response, summary data on the average amount of time taken by a student to make a correct response and the percentage of eventual successes provided little useful information.

Summary Description of Version 2

 A description of version 2 in November 1976 (Power and Rose, 1976) summarized the major phases. Version 2 contained text, yes-no questions, short-answer questions, and response-dependent comments. These elements were linked by conditional branches. This branching structure created a hierarchy of question sequences. These sequences were joined to form six phases of a decision process. In addition, DECAID included a control system. The six DECAID phases were sequenced to follow normative decision-process concepts. The first four phases, QUEST; INFO; GOALS; and ALTGEN, required creative-divergent efforts from users. The final two phases, ALTEVA and CHOICE, required convergent efforts. These convergent components have received most of the emphasis in the decision-making literature. The divergent components are the main focus of DECAID and its main contribution.

The question definition phase, QUEST, was designed to help users 1) minimize the probability of defining an inappropriate decision question (e.g., committing an error of the third-type; 2) view their decision situation creatively; and 3) define a simple, direct, and unambiguous decision question.

The text sections stated the objectives of this divergent phase and explained the importance of avoiding an error of the third-type. The first sequence asked the student to identify and characterize the decision situation. A sequence of open-ended thought-provoking questions in a subroutine, IDEAS, could then be used to stimulate different perspectives on the decision situation (e.g., the question put in another way could be likened to...). After completing IDEAS, the student stored the decision question, which was then redisplayed during the logical and structural analysis section of QUEST. When a student's response indicated that he or she could improve or restate the decision question, DECAID asked the student to enter the new decision question. The question definition phase ended when the student's responses to the analysis questions indicated that he or she had defined a "best" decision question. This final decision question was redisplayed by DECAID at appropriate points in remaining phases. An information and decision question evaluation phase, INFO, was next in a standard DECAID sequence. This phase sought to evaluate 1) the need for additional information; and 2) the appropriateness of using mathematical programming, simulations, and similar techniques for finding an optimal solution. When DECAID was used with critical incidents, this section helped students realize that one cannot always obtain additional information. The sequence of questions designed to meet the second objective of this section relied on models that distinguished programmable from nonprogrammable decision questions.

Goals, objectives, and ideals were recognized in DECAID as essential to the decision-making process. GOALS, the goal evaluation phase, assumed that goals and objectives had been defined by the organization. GOALS then helped the student rank, clarify, and evaluate these goals in terms of the decision question specified in QUEST. This sequence also explained the importance of stating goals and objectives. The student then entered appropriate goals. These goals were displayed as the student answered the goal-analysis questions. These questions asked about goal priorities, about the ability to quantify the goal, and about the relationships among relevant goals.

Generating alternative courses of action is also fundamental in decision making. ALTGEN, the alternative generation phase, did this in version 2. First, it used text sections to emphasize the importance of identifying alternatives. Then, it attempted to avoid premature closure by stimulating futuristic ("What if ...?") and lateral ("Why not try ...?") thinking about alternatives. DECAID also used a Hegelian inquirer to ask "What if you did just the opposite?" or "What if you did nothing at all?"

Alternative evaluation, ALTEVA, a convergent component of DECAID, occurred next in sequence. This phase helped the student specify and compare the consequences of various actions. A student entered the alternatives in memory so that DECAID could display the possible actions during its iterative evaluation routine. Students considered both general questions and more specific organizational behavior questions for each alternative. When a course of action was impractical, unworkable, or disadvantageous, DECAID often pointed this out. Finally, this section had a routine which helped the student specify guidelines to use in making a final choice.

CHOICE, the choice phase, paired arguments for and against what the student had determined to be the two best alternatives. DECAID stored the pro and con arguments and displayed them in a format that helped the student compare and contrast the strengths of the arguments. DECAID then asked the student which alternative had more support or less opposition when the arguments were weighed subjectively. Finally, CHOICE had a subroutine, AUDIT, which helped students evaluate the quality of their decision process.

DECAID's control system had informational materials for new users. It had a short-question sequence which checked to make certain that the student had identified an organizational decision situation. It also had a sequence that distinguished organizational problems from opportunities and then specified a separate methodology for each situation type. Finally, it had a sign-off routine that allowed experienced users to specify that when they returned to DECAID they would enter at the DECAID controller. The controller asked users to specify what phase or subroutine they would enter. Sign off provided a smooth end for DECAID users no matter what path led them to that point.

DECAID was designed to permit

1) users to stop at any point and begin at the same point when they sign on again;

2) experienced users to enter DECAID at any point in the sequence through the use of the phase option or through the use of GOTO statements in the body of the system (This was not implemented in version 2).

3) expansion into programmable decision making, decision tool evaluation, and decision-making tutorials.

Version 2. Release 2

During the last week of August 1976, some of the problems discovered in DECAID were corrected: The branching structure was improved, fewer branches were made to the exit routine, wording of questions was improved, and abruptness in branching and feedback was somewhat corrected. But no major changes were made in the overall structure of the program.

At some point in the fall of 1976, it became obvious that DECAID was not conceptually complete. The prescriptive model included in DECAID was one plausible approach for making strategic decisions, but it did not contain alternative strategies for use in each phase such as, a pro-con comparison model, a weighted choice model, and a cost-effectiveness choice model. It did contain some models which had minimal branching structure. And the DECAID programs did not utilize all of the material collected in BASIC program components to make conditional branches to questions and between models. Minor changes were made in the program, but because of time constraints, it was not possible to alter the fundamental DECAID structure. The control system was changed in an attempt to help users find the causes of a problem. Also, a question was included to identify the importance of a decision situation. The information evaluation materials were modified and a BASIC routine was added which displayed the decision question at various points in later phases of the decision process.

In late October, the exercise instruction sheet was modified and another developmental testing cycle began. In an introductory management course, students wrote a management report. Using DECAID to aid in case analysis was made optiona1. Many students volunteered to use the program on their own, but only 12 actually returned paper protocols with their management report and completed the attitude questionnaire. No objective performance measure was used in the fall testing, but the management report provided performance information.

Instructional Dialogue Facility statistics and response files were not maintained. Rather in the fall testing,students returned print outs or protocols which contained extensive information about their behavior while using DECAID. Because students decided when they wanted to use DECAID, and went to the computer lab without supervision, it was thought, this approach would provide a better view of how well the program was working. Also, it would help to evaluate the robustness (Keen, 1975) of the input controls. After the testing was completed, the protocols were analyzed for problems. Notes based on verbal feedback from student users were also analyzed. Frequent use of the programs by the author also helped identify possible changes in the DECAID programs.

The management reports did not indicate major differences between students who used the DECAID program and those who did not. But using DECAID influenced the way some students structured their reports, i.e., they used DECAID headings and questions in their reports.

Version 2. Release 3

Early in January 1977, additional changes and programs were planned in general making DECAID more complex. A model developed by Vroom and Yetton (1973) was programmed for DECAID. That model was included in version 2. release 3. In addition, changes were made in the control system and the alternative evaluation sections of DECAID. During this period, behavioral objectives were developed for the DECAID system.

Summary of Research Results for Version 2

 Based on test performance, users of version 2, significantly improved their knowledge about decision making. User attitudes toward decision making and DECAID were mixed, particularly with respect to the comparative advantage of DECAID relative to conventional instructional methods. Analysis of protocols demonstrated high student involvement, but suggested that several questions and question sequences needed modification. There were also editing, storage, and file structure difficulties with the IDF program. Also, research with release 3 suggested that results would have been more favorable had students been able to stop, then return to DECAID. Since DECAID version 2 was a hybrid of BASIC and IDF, none of the available control, editing, and similar IDF capabilities could work in BASIC components. Nor could other desirable features in the BASIC programs be added to the IDF components. In general, the results suggested that continued research was needed and could potentially result in a useful program. The results with version 2 also suggested that DECAID should be redesigned and reprogrammed in a high-level programming language.

Version 3

During the fall of 1977, a new version of DECAID was designed. Materials from the old system were divided into logically separate program modules. Also, a standard input control system was designed for use in each module. All of the modules were linked through a control program called DECAID. Branching to and between programs was done through the control program. Version 3 had no IDF components and none of the key-word search capabilities of IDF. It was written in BASIC on an HP-2000/Access system. By late January of 1978, when the author moved from Iowa City, Iowa, and the University of Iowa to Madison, Wisc., and the University of Wisconsin, the control system, QUEST, GOALS, and ALTGEN were programmed.

In version 3, a major design change involved the addition of a command called PRESCRIBE and provision for user access to each module in DECAID. In version 2,users could not easily access individual DECAID programs in any order they desired. Rather, they had to follow a rigidly prescribed sequence from one phase to another. In the design for version 3, users could access individual modules or phases in the decision process or they could use the utility PRESCRIBE to direct their decision process.

 Most of the design and development work in version 3 involved creating BASIC programs to provide capabilities like those in IDF and those specifically required for a decision aid system. A number of additional capabilities were envisioned but never implemented, including a report generator, storage of decision information in a file for later use, and NEWKOMMANDS that would have allowed users to run programs that they had written to use with the DECAID system.

DECAID version 3 had a complex system of user controls at both the system level and the program level. System commands allowed users to select specific substantive programs like ALTGEN and to select various utility programs (like PRESCRIBE). Both system commands and four program commands gave users great flexibility in the use of DECAID.

Using the enter routine in DECAID version 3, users could select system level utility programs. PROMPT determined the instructional level of DECAID version 3. New users began at PROMPT level 3, where detailed instructional materials and questions were presented. They could then advance to level 2, where no instructional material was presented, only substantive and procedural questions, or level 1 where short and often cryptic substantive and procedural questions were presented. Users could list system commands by typing KOMMANDS and obtain short explanations of each command by using EXPLAIN. Users could give feedback via COMMENT at either the system or program level. Program entry and exit were controlled by the DECAID and STOP programs, respectively. DECAID recorded user data (e.g., name, date, and time of sign-on, etc.). provided introductory materials for new users, and permitted users to control branching to substantive and utility programs. STOP provided a smooth exit from DECAID. it was both a system and a program command. STOP also provided diagnostic information about problems encountered by users.

Four program-level commands were available in DECAID version 3 programs. They were, HINT, RESTATE, COMMENT, and STOP. When managers desired an explanation of a DECAID question, they could type HINT and the computer program responded with relevant definitional and informational comments. Also, because of problems which can occur due to word choice, the RESTATE command resulted in the display of a question similar in intent to the original, but with altered phrasing. COMMENT and STOP performed the same functions at the program and system level.

Version 4, Release 1

Development of DECAID stagnated for almost two years, from January 1978 to January 1980. During that period, an attempt was made to convert the DECAID programs from the HP 2000/ACCESS system to the DEC PDP 11/70 at the Universitv of Wisconsin, but the task was difficult and the new version of DECAID would not have been easy to transport to other sites.

In January 1980, design specifications were completed for version 4 (Power, 1980). A hierarchy of design objectives was specified. The following nine major characteristics for the system were stated:

1. simple to use. Communicating with DECAID should be easy for both beginners and experienced users. English-like commands should be used. Synonyms from other systems should be recognized. Experienced users should be able to use abbreviated commands, receive shortened prompts, etc.

2. friendly and supportive. DECAID responses should create positive feelings for beginners and experienced users.

3. helpful and informative. DECAID should anticipate problems and try to help users avoid them by providing hints, reminders, directions, etc.

4. reliable and robust. The system should detect obvious response errors. It should have recovery procedures for files and no abrupt terminations should occur in programs.

5. controllable by users. Experienced users should have maximum flexibility to adapt the system to their needs (does not imply ability to permanently modify the system).

6. well-documented. DECAID should be well-documented, e.g., explain what is being done, how it is being done, and why it is being done.

7. standardized. Programming standards and conventions should be specified and adhered to. Standards should emphasize transportability and modifiability criteria.

8. modular. Both new hardware and software capabilities should be anticipated in the design, e.g., graphics, new search algorithms.

9. expandable. It should be easy to change and add programs.

Also, in the design specification,input, processing and output capabilities were discussed. A system for naming the programs in DECAID was developed (see Table 1).

During the spring of 1980, various computer systems were investigated for the development of version 4. Both time sharing and mini computers were considered, but the author felt he would have the greatest control and flexibility in development if a microcomputer were purchased. After an extensive search, an Apple II Plus computer (see Figure 1) with 64k of RAM was purchased in early July 1980. As the author learned Applesoft BASIC, flow charts of the DECision AID programs were prepared. Programming began in late October 1980. Between November 1980 and April 1981, a new version of DECision AID was programmed. Then in May, ten students used the system and provided developmental feedback.

Figure 1. Apple II Plus Computer

Many new models were also designed for version 4. A program called RECOGNITION was designed and programmed to help users evaluate and categorize their strategic decision environment. DIAGNOSIS was developed to help users evaluate the causes of a problem. The phase INFO was expanded and developed as a new program called SEARCH. A utility to enter the competitive strengths and weaknesses of a manager's company and major competitors was also developed. Also, a model similar to those of Vroom and Yetton (1973) and Stumpf, Zand and Freedman (1979) was programmed. These advanced programs greatly expanded the amount of time required for a decision aid session and they have not been tested with users or refined. Many other advanced capabilities are also part of the decision aid.


DECision Aid Program Categories

Application Programs (AXXX)* Each program helps a decision maker apply a specific
decision-related procedure or method, e.g., individual
brainstorming, pro-con choice comparison.
Categorization Programs (CXXX) Each program helps a decision maker categorize and define
decision-related situational components, e.g., the relevant
environment of the organization, the type of decision situation.
Directional Programs (DXXX) Each program tries to guide and direct a decision maker
through the decision process or through a particular phase
of the process.
Evaluation Programs (EXXX) Each program presents a list of necessary conditions for a
particular evaluative judgment, e.g., evaluating
implementation plans, evaluating and auditing a tentative decision.
Selection Programs (SXXX) Each program helps a decision maker choose an
appropriate method, process, or procedure for a
particular situation, e.g., selecting an appropriate creativity-enhancing technique(s).
Utility Programs (UXXX) Each program serves a specific purpose intended to help
people store information relevant to decision making or
control of DECAID, e.g., entering decision question, stopping the DECAID system, entering comments.

* Four-letter commands for programs in a category all begin with the same first letter.

DECAID version 4. release 1 had an elaborate control program. All of the major phases of previous versions were included in the foundation programs. The pro-con comparison in the choice phase was supplemented with a multi-attribute utility model program called AMAU.

The content of the other phases were very similar to version 2. The wording of some questions was improved. The branching structure and the number of questions in AUDIT were revised and expanded. Also, more capabilities for editing alternatives or goals entered by users were provided.

PRESCRIBE was implemented in this version. In this program, users were asked if they were in an organizational or a personal decision situation. If the user was in an organizational decision situation, he or she was asked if his or her role was that of actor or recommender. Based on the user's response to these questions, one of three stored sequences of commands was executed by DECAID. The personal sequence was GOALS, QUEST, UEDA (utility to enter decision alternatives), ALTEVA. The organizational actor sequence was QUEST, GOALS, ALTGEN, APCC (apply pro-con choice model), AUDIT. The organizational recommender sequence was QUEST, ALTGEN, GOALS, AMAU (apply multi-attribute utility model).

In summary, version 4, release 1 had the following foundation programs: PRESCRIBE, QUEST, GOALS, ALTGEN, ALTEVA, CHOICE, and AUDIT.

PRESCRIBE directed the decision process and helped DECAID users follow a rigorous decision-making process. Three processes were available in that program: PERSONAL, ORGANIZATIONAL ACTOR, and ORGANIZATIONAL RECOMMENDER. QUEST, the question definition and evaluation phase, consisted of programs to enter the user's decision question, to generate ideas about the main issue in the decision situation, to evaluate the characteristics of the decision question, and to categorize the type of decision question. GOALS, a goal-setting and evaluation phase of the decision process, helped the user enter and evaluate goals relevant to a decision question.

ALTGEN, the alternative generation phase of the decision process, assisted the user in identifying or generating alternatives and in evaluating the set of alternatives to ensure that it was complete and of high quality. ALTEVA, the alternative evaluation phase, helped reduce the set of alternatives. Users considered if an alternative met goals entered in the GOALS phase and other criteria. CHOICE, the choice phase of DECAID, helped users apply qualitative (APCC) and quantitative (AMAU) approaches to making a final selection among alternatives. Finally AUDIT, the review of a tentative decision, asked users about the feasibility and risks associated with the tentative decision.

The program commands, STOP, COMMENT, and RESTATE, mentioned in the discussion of version 3, were kept in version 4. COMMENT now serves as an electronic scratchpad for the user. The user can enter remarks, reflections, or ideas as they go through the decision process and retrieve them later. HINT was dropped as a program command, and two new program commands, PROMPT and DISPLAY, were added. In version 3, PROMPT was available only as a system command. In version 4, users can type PROMPT as a response to any question asked by DECAID. The system then asks what prompt level the user wants. Three (3) remains the instructional level; (2) the regular level; and (1) the expert level. DISPLAY is a new program command that allows the user to list currently entered decision information, e.g., decision question, goals, and alternatives. GOTO is a program command that permits users to move to questions within a phase of the decision process.

Version 4. Release 2 In June and early July 1981, the programming efforts were directed toward the foundation programs. Many minor changes in questions and text were made. Problems with displays and formats were corrected. And the input controller was improved. During July 15 students used DECAID with management cases. The first two users encountered unexpected problems (that were subsequently corrected) but the remaining users satisfactorily completed the DECAID sequence.

Version 4. Release 3

REPORT formats a summary of the user's decision question, goals, alternatives, rating from the multi-attribute utility model (if AMAU is used), pro and con arguments (if APCC is used) and the user's tentative decision. This summary can be sent to a printer.

SAVE is a command to store decision-related information in a file. The UPDATE command restores the DECAID system to the state determined by data in a designated file. SAVE is both a program command and a system command.

The command UETD (utility to enter a tentative decision) is a simple program that permits users to designate one of their alternatives as the tentative decision or to enter a new alternative as the tentative decision. The new alternative may be a combination of alternatives considered by the user.

Extensive testing occurred with version 4. release 3. In late October 1981, 10 groups with three persons in each group used DECAID. This was the first attempt to use DECAID to aid groups in decision making. The DECAID system served as the "group leader", structuring and directing the decision process. One of the group members typed in responses to DECAID questions. Some problems occurred with REPORT, but the response was generally favorable. All of the users were taking a course in decision support systems so each group prepared a report critiquing the system.

During a two-week period in November, 95 students from an undergraduate and an MBA course in managerial decision making used the system as an individual decision-making aid. The students responded based on a management case in answering DECAID questions. The students completed as attitude questionnaire and an evaluation of their decision and wrote case analyses. The results were generally encouraging and are reported in Power and Aldag (1982). In January 1982, the author moved to the University of Maryland in College Park. In April of 1982, DECAID was used in a seminar on managerial decision making. Nine students, in three groups (one student worked alone) used the system. No major problems were encountered, but it was obvious that these students would have benefitted from using the advanced programs.


Development and programming of the DECAID System continued until 1984. Version 4. release 4 was not completed. This version had more sophisticated editing capabilities, an expanded REPORT program that permited users to specify page depth and width for printed output. Also, some problems encountered in release 3 were corrected. The advanced programs were not available with this release.

Release 4 was used in field trials of the system in a few companies and in selected courses at some universities.


1. Alter, S., "Why is Man-Computer Interaction Important for Decision Support Systems?," Interfaces, 7, 2, 1977, pps. 109-115.

2. Churchman, C. The design of inquiring systems. New York: Basic Books, 1971.

3. Davis, G. B. Management information systems: conceptual foundations, structure, and development. New York: McGraw-Hill Book Company, 1974.

4. Donovan, J., Gutentag, L., Madnick, S. and Smith, G., "An Application of a Generalized Management Information System to Energy Policy and Decision Making - The User's View," American Federation of Information Processing Societies, Inc., Conference Proceedings, National Computer Conference, 44, 1975, pps. 681-685.

5. Easton, A. Complex managerial decisions involving multiple objectives. New York: John Wiley & Sons, Inc., 1973.

6. HP 2000 Access instructional dialogue facility author's manual. Cupertino: Hewlett Packard, 1975.

7. Harrison, E. The managerial decision-making process. Boston: Houghton Mifflin Company, 1975.

8. Janis, I.L. Victims of groupthink. Boston: Houghton-Mifflin, 1973.

9. Johnson, P., Severance, D., Feltovich, P., "Design of Decision Support Systems in Medicine: Rationale and Principles from the Analysis of Physician Expertise,'' unpublished working paper, 1979.

10.Joyner, R., and Tunstall, K., "Computer Augmented Organizational Problem Solving," Management Science, 17, 1970, pps. B212-225.

11. Keen, P. G., "Computer-based decision aids: the evaluation problem," Sloan Management Review, 1975, 16, pps. 140-166.

12. Keen, P. and Morton, M., Decision Support Systems: An Organizational Perspective, Reading, Mass.: Addison-Wesley, 1978.

13.Martin, C., & Ohmann, R. M. The logic and rhetoric of exposition. New York: Holt, Rinehart and Winston, Inc., 1964.

14. Mitroff, I.I., & Featheringham, T.,"On systematic problem solving and the error of the third kind," Behavioral Science, November 1974, 19. pps. 383-393.

15. Morton, M. Management Decision Systems: Computer Based Support for Decision Making, Cambridge, Mass.: Division of Research,.Harvard, 1971.

16. Pauker, S., Gorry, G., Kassirer, J. and Schwartz, W., "Towards the Simulation of Clinical Cognition: Taking a Present Illness by Computer,'' The American Journal of Medicine. 60, 1976, pps. 981-996.

17. Power, D., Design and Development of DECAID: A CAL Decision Formulation Program, unpublished Masters Thesis, University of Iowa, Iowa City, Ia, 1977.

18. Power, D. J. "Design Specifications for DECAID," unpublished working paper,1980.

19. Power, D. J. and Aldag, R. J., "Examination of the Nature and Determinants of the impact of DECAID on Problem Solving," unpublished working paper, 1982.

20. Power, D., & Rose, G., "Improving decision making behavior using the Hewlett-Packard 2000-Access system," American Institute for Decision Sciences Proceedings, 1976, 8, pps. 47-49.

21. Power, D., & Rose, G.,"An evaluation of DECAID, a decision formulation CAL program." American Institute for Decision Sciences Proceedings, 1977, 9, pps. 118-119. 22. Said, K., "A MIS for Problem Detection, Diagnosis, and Evaluation," Managerial Planning, 26, 5, 1978, pps. 4-8.

23. Simon, H. A. The new science of management decision. New York: Harper & Row, 1960.

24. Stumpf, S. A. Zand, D. E., & Freedman, R. D.,"Designing Groups for Judgmental Decisions," Academy of Management Review, 4 (4), 1979, pps. 589-600.

25. Vroom, V. H., & Yetton, P. W. Leadership and decision-making. Pittsburgh: University of Pittsburgh Press, 1973.

26. Young, L., "Another Look at Man-Computer Interaction," Interfaces. 8, 2, 1978, pps. 67-69.


1. As a teaching assistant, I could not require students to use DECAID.
2. William Valliere did the programming for the Vroom-Yetton model.
3. For more information, see Power (1977, chapter 4).
4. William Valliere helped with the design and programming of version 3 especially the input control system.
5. Version 3 was never completed because the author found it very difficult to convert the programs to run on a DEC PDP 11/70 system, available at the University of Wisconsin.
6. Prescribe was not implemented in version 3; users requested individual programs.
7. William Cats-Baril helped with programming version 4, release 1, especially AMAU, RECOGNITION and ALTEVA.
8. Maureen Sullivan and Scott Conrad did some of programming on version 4.
9. The need to complete the author's dissertation made it impossible to work on DECAID. The advanced programs were not completed.

Author Notes

Daniel J. Power (mail to: is Professor of Information Systems and Management at the College of Business Administration, University of Northern Iowa, and editor of DSS Research Resources at URL

This is version 2.0. Version 1.0 was written in 1983. It was last updated April 14, 1998.

Copyright (c) 1998 Daniel J. Power

How to cite this paper.

This page should be cited as:

Power, D.J. Designing and Developing A Computerized Decision Aid - A Case Study. World Wide Web,, version 2.0, April 14, 1998.

DSSResources.COM is maintained and all its pages are copyrighted (c) 1995-2000 by D. J. Power (see biographical sketch), Professor of Information Systems, Cedar Falls, IA. Please send your email to This page was last updated 12/29/1999 by D. J. Power, see disclaimer.