Sie sind auf Seite 1von 8

COMPUTINGPRACTICES

Edgar H. Sibley Panel Editor

A two-phased research project comparing the prototyping approach with the more traditional life cycle approach finds that prototyping facilitates communication between users and designers during the design process. However, the findings also indicate that designers who used prototyping experienced difficulties in managing and controlling the design process.

AN ASSESSMENT OF THE PROTOTYPING APPROACH TO INFORMATION SYSTEMS DEVELOPMENT


MARYAM ALAVl

Recently the traditional "life cycle" approach to information systems development has been under question [1, 2, 7]. A new approach to information systems development--prototyping--is gaining popularity among practitioners and academicians in the information systems field, and the term is appearing more frequently in the literature [1, 2, 11, 13]. Although common in hardware development, prototyping for information systems development is relatively new, and practical experience and published empirical studies in this area are limited. Except for isolated case studies [4, 6, 13], the effectiveness of the prototyping approach in organizational settings has not been studied. In fact, there is no unique definition for the term information systems prototype. Here, the following definition is adopted: An information systems prototype is an early version of a system that exhibits the essential features of the later operational system [13]. Some information systems prototypes may evolve into the actual production systems whereas others are used
1984 ACM 0001-0782/84/0600-0556 75

only for experimentation and may eventually be replaced by the production system. In this investigation of the effectiveness of the prototyping approach, user and designer attitudes are explored through field interviews and a laboratory experiment. Some practical suggestions for effectively using prototyping are presented in the conclusion. PROTOTyPING APPLICATIONS: FIELD INTERVIEWS Twelve information systems development projects using the prototyping approach in six organizations were analyzed. Industries and application projects are listed in Table I. The projects are further characterized in Table II. In each organization and for each project, in-depth interviews with project managers and systems analysts were conducted--in all, 12 project managers and 10 systems analysts. In each interview, probing techniques were used to obtain a qualitative and complete understanding of the opportunities, problems, benefits, and

556

Communicationsof the ACM

June 1984 Volume 27 Number 6

Computing Practices

shortcomings of prototyping. Projects of varying size and scope were selected. The smallest in the sample was the accounts receivable system with an approximate project cost of $5000 and a project effort of 3 person-months. The chemical products costing and reporting system in the oil industry was the largest project at a cost of $630,000 and 88.9 person-months to develop. The nature of the systems studied ranged from transaction processing systems (e.g., accounts receivable, on-line calendar of events, registration, on-line telephone directory) to control systems (e.g., real estate development and management system, rail fleet management, and chemical products costing and reporting). All the projects were completed within the two years preceding the interviews and were considered to be successes by project managers and users. Two sets of questionnaires were used. One set was used only in interviews with the project managers and contained structured questions for obtaining background information on the selected projects (e.g., scope, cost, effort). Another set of questionnaires was used with both project managers and systems analysts and contained open-ended questions with regard to the nature, perceived benefits, and shortcomings of prototyping. GENERAL INTERVIEW FINDINGS

TABLE I. Industries and Applications Using Prototyping Industry


Education

Applications
Accounts receivable

On-line calendar of events Registration system Oil and gas


On-line journal processing and

validation Chemical products costing and


reporting On-line recruitment tracking Manpower utilization tracking On-line telephone directory

Rail fleet management


Crude transportation

Real estate development and management State govemment

Cash flow analysis and projection


Personnel system

TABLE II. Some Characteristics of the Projects Studied Approximate Project Cost' (dollars)
5,000 ~

Application Projects

Perceived Benefits of Prototyping


The interviews revealed the following positive considerations with respect to prototyping.
Prototyping is real.
Accounts receivable On-line calendar of

Approximate Project Project DeveEfforP Iopment (personDuration months) (months)


3 2 3 30.6 6 2 3 13

An information systems prototype provides the user with a tangible means of comprehending and evaluating the proposed system and elicits more meaningful feedback from users in terms of their needs and requirements. As one project manager observed, "The users are extremely capable of criticizing an existing system but not too good at articulating or anticipating their needs." Prototyping provides a common base line. Prototyping represents a common reference point for both users and designers by which to identify potential problems and opportunities early in the development process. It is also an effective way to draw out and clarify user requirements. Users are enthusiastic. Prototyping is a practical way to cultivate and achieve user participation and commitment to a project. According to one systems analyst, "The ability to get a working system (the prototype) up and running in such a short time made the project very visible to the users. They felt that data processing was being responsive to their needs, and they in turn were very cooperative. The prototype helped us (the data processing group) gain credibility." Another project manager stated, "At the end of the prototyping process, the users were very satisfied with the development effort and the prototype. They felt they had some real influence in the design process."

not available
10,000 ~ 216,000

events Registration system


On-line joumal

processing and validation


Chemical products costing and reporting 630,000 85,000 560,000 d 70,000 88.9 12 64 11.3 21 3 24 6

On-line recruitment tracking


Manpower utilization

tracking On-line telephone


directory

Rail fleet management


Crude transportation

295,000
88,000

41
12.5

14 10 3

Cash flow analysis and projection Personnel system

not available

0.9

50,000

Cost figurespresentthe total projectcosts (DP manpower, computer,and

indirectcosts) unlessotherwiseindicated.

b Only representsDP personneltime. Cost figure only representsDP manpowercost. The project involvedfive different sites. It was estimatedthat the total project cost would be $2.5 millionupon completionof the system for all five sites.

June 1984 Volume 27 Number 6

Communications of the ACM

557

Computing Practices Prototyping establishes better relationships. Users and data processing personnel seem to develop better communication and rapport, and a better appreciation for each other's jobs. This in turn leads to a better working relationship between the two groups. Prototypinggets it right. Prototyping helps ensure that the nucleus of a system is right (i.e., performs as expected or required) before the expenditure of resources for development of the entire system. evaluation of the perceived benefits and shortcomings due to unavailability of field data, and (2) unavailability of the users of the prototyped information systems for interviews with the researcher. To compensate, the second phase of the project consisted of a comparative evaluation of the prototyping versus the life cycle approach in a controlled laboratory environment for the purpose of obtaining data on user reactions and attitudes.

Perceived Shortcomings of Prototyping


The following drawbacks were also found. Prototypes can be oversold. Some project managers stated that by definition a prototype has limited capabilities and captures only the essential features of the operational system. Sometimes unrealistic user expectations are created by overselling the prototype, which may result in unmet user expectations and disappointment. Prototypes are difficult to manage and control. Several project managers stated that due to the "newness" and nature of prototyping, there is a lack of know-how for planning, budgeting, managing, and control. Traditional life cycle approaches have specific phases and milestones and specific deliverables that are established before project initiation and are used as guidelines for project planning and control. Planning and control of prototyping projects are more difficult because the form of the evolving system, the number of revisions to the prototype, and some of the user requirements are unknown at the outset. Lack of explicit planning and control guidelines may bring about a reduction in the discipline needed for proper management (i.e., documentation and testing activities may be bypassed or superficially performed). It is difficult to prototype large information systems. It is not clear how a large system should be divided for the purpose of prototyping or how aspects of the system to be prototyped are identified and boundaries set. In most cases, time and project resource constraints determine the boundaries and scope of the prototyping effort. However, more explicit guidelines and procedures are needed for prototyping large systems. Moreover, the internal technical arrangements of large information systems prototypes may be haphazard and inefficient and may not perform well in an operational environment with large amounts of data or large numbers of users. It is difficult to maintain user enthusiasm. In some cases, user involvement and interest waned after the working prototype was developed. After high priority user requirements were satisfied by the prototype, users were not willing to spend time and resources to complete and "clean up" what was, in the minds of the designers, only an early version of the system. Instead, users wanted the design team to move on to a new project. EXPERIMENTAL EVALUATION OF

Experimental Setting
The experiment centered around a case analysis that involved developing an information system for support of a new plant investment decision in the chemical industry. Background, production, financial, and industry information were provided as well as price structure data and a detailed description of the company facing the investment decision. Detailed data on company history, cost, financial and market structures, and production history and projections were presented. In summary, a wide array of potentially relevant data was made available to the subjects. Nine groups of 6 to 8 subjects each were formed. Half of the group members were asked to play the role of "user-managers" and decide whether or not to invest in the new plant, while the other half were instructed to assume the role of information system designer and develop a Management Information System for Investment Analysis and Planning (MISIAP) for the users. Half of the subjects playing the designer role were asked to use the prototyping approach; the other half were instructed to follow the life cycle approach.

Research Variables
The independent variable was, of course, the approach used--prototyping versus life cycle (Figure 1). Three categories of dependent variables were investigated: (1) user evaluation of and satisfaction with the information system (MISIAP), (2) user and designer perceptions and attitudes toward the design process, and (3) the extent of use of the MISIAP in analyzing the case and arriving at decisions. The first category of dependent variables was measured in terms of overall favorable evaluation, overall satisfaction, accuracy of output reports, ease of use, and helpfulness of the output reports. User and designer perceptions and attitudes toward the design process (the second category of dependent variables) were measured in terms of ease of communication between user and designer, satisfaction with the level of user participation, degree of change in the user specifications, level of perceived conflict between the user and designer, user understanding of the information system throughout the design process, user influence on the design process, ease of control and management of the design process, and level of user commitment to the project. The third category of dependent variables was measured in terms of extent of use as depicted in Figure 2. Figure 2 also provides an example of the five-point

THE PROTOTYPING APPROACH


There were two basic limitations to the prototyping field interviews: (1) lack of a comparative analysis and

558

Communications of the ACM

June 1984 Volume 27 Number 6

Computing Practices

PrototypingApproach

Life CycleApproach

Identify Initial

User Requirements

I Systems Analysis I

anOEv+u+l I
the Prototype
)

Requirements

Specification

I System Design I

+
I System opment Oeve' I
Installation
and Review

I +ntenance I
FIGURE 1. The Information Systems Development Approaches Investigated in the Study

Likert-type scales that were used as well in measuring the other two categories of dependent variables.
Subjects The subjects of this experiment were drawn from the evening graduate student population of the College of Business Administration at the University of Houston. Ninety percent of the participating students had fulltime professional positions with various organizations in the area. Two evening MBA classes were integrated for the purposes of the experiment: The subjects who played the role of users came from a course in general business and policy; those who played the role of the designers came from a graduate-level course in management information systems (MIS). The experiment was an assigned course project in both classes and

counted for 40 percent of the final course grade in each class. The selection of this subject population was considered opportune for a number of reasons. First, it was felt that graduate business students would find role playing in a business case agreeable and were knowledgeable enough to feel comfortable analyzing the experimental case and making the new plant investment decision. Furthermore, it was felt that the training and academic backgrounds of the graduate MIS students provided them the skills necessary to develop the information system and profit from the experience. Also, since the experiment was assigned as a formal course project and constituted a major portion of the final course grade, the subjects were highly motivated and no resistance to the project was observed. Sixty-three

Instructions.

Please decide to what extent the following statement is true or false.

Mark 5 if the statement is completely true. Mark 4 if the statement is somewhat true. Mark 3 if the statement is neither true nor false. Mark 2 if the statement is somewhat false. Mark 1 if the statement is completely false. I used the information system reports in analyzing the case and arriving at my decisions.
1 2 3 4

FIGURE 2. The Likert-Type Scale Used for Measuring the Extent of Use of MISIAP

June 1984 Volume 27 Number 6

Communications of the ACM

589

Computing Practices

subjects participated in the experiment: 29 in the role of systems analysts and 34 in the role of users.

Experimental Procedures
Nine user groups were formed from the graduate policy class and 9 systems analyst groups from the graduate MIS class. The user and systems analyst groups each consisted of 3 to 4 individuals. Each systems analyst group was randomly assigned to a user group, and each user/systems analyst team was randomly assigned to follow either the prototyping or life cycle approach. Initially, neither the user groups nor the systems analyst groups were aware of the research question and the experimental nature of the project. 1 The policy students representing the users were told that the purpose of the exercise was to provide them an opportunity to make policy and strategic decisions in a specific case and learn about the computer and information processing technologies available to support managerial decision making. The systems analyst groups were advised that the project objective was to expose them to information systems development in a simulated real-world situation. Case descriptions were distributed to each group. User groups were advised that their principal responsibility was to analyze the case and make the new plant decision and that they would be evaluated on the quality of their analysis and the investment decision. The principal responsibility of the systems analyst teams was to supply the information systems capabilities needed to support the users' decision and analysis.

active Financial Planning System (IFPS)2 to the students playing the role of systems analyst. Through specific examples, students used IFPS in a "hands-on" mode. Homework assignments assured that all systems analyst students had a working knowledge and good understanding of IFPS capabilities and either the life cycle or prototyping approaches. 3 The elapsed time for the preexperimental activities was three weeks.

Experimental Session
To ensure that the prototyping and life cycle procedures were closely followed by the systems analyst teams, documentation forms corresponding to specific phases and activities of the two approaches were prepared and distributed. At the completion of each phase (four phases for the prototyping approach and six phases for the life cycle approach), each systems analyst team was required to use the forms to prepare and hand in documentation corresponding to that phase. The user and systems analyst teams were encouraged to meet as often as necessary. The elapsed time for the experimental session was seven weeks.

Postexperimental and Debriefing Sessions


After both the MISIAP and case analyses were complete, postexperimental questionnaires were administered to garner information in the following areas: (1) user evaluation of and satisfaction with the information system developed, (2) user and systems analyst subjects' attitudes and perceptions of the prototyping and life cycle approaches, and (3) extent to which the information system was utilized by users in analyzing the case and arriving at the new plant investment decision. Subjects were debriefed about the experiment and their questions about the project answered in general. Systems analyst subjects who had used the prototyping approach were debriefed on the life cycle approach and vice versa. The poststudy session was concluded when the ques= IFPS is a modeling system developed and marketed by Execucom Systems Corporation in Austin, Texas. 3 Postexperimental questionnaires indicated that the students felt they had adequate knowledge of IFPS and sufficient understanding of either the life

Preexperimental Activities
The first preexperimental activity was the admi'nistration of a questionnaire to collect background and demographic information from the subjects. Next, the phases of the life cycle approach and the specific steps in each phase were reviewed in detail for the students who were asked to follow this approach. In addition, reading materials on the life cycle approach were assigned and discussed in class, and student questions regarding the approach answered. The prototyping approach was presented to the relevant students in a similar way. Another preexperimental task was to teach the Inter1 The experiment and the research question were described to the subjects in the pestexperimental session.

cycle or prototyping approaches for design of their information systems.

TABLE IlL Mean Scorese and Mann-Whitney U Test Results for the Dependent Variables Related to User Evaluation and Satisfaction with the information System DependentVariables ExperimentalGrOUl~ Overall Favorable O v e r a l l Evalua~onof Satisfaclionwith MISIAP MISIAP 4.53 3.42 0.007 b 4.40 3.21 0.01 lb 'timeliness of OutputReports 4.53 4.53 0.523 Accuracy of Output Reports 4.06 2.64 0.002 b Ease of Use of MISIAP 3.46 3.07 0.345 Helpfulness of OutputRelXxts 4.21 3.14 0.007 b

Users Exposed to Prototyping Approach Users Exposed to Life Cycle Approach Two-Tailed Probability

"Scores measured on 5-point Ukert scales (1 = low, 5 = high). a T h e difference between the means is statistically significant at p < 0.05.

560

Communications of the ACM

June 1984

Volume 27 Number 6

Computing Practices

TABLE iV. Mean Scores" and Mann-Whitney U Test Results for User Perceptions and Attitudes Toward the Design Process DependentVariables ExperimentalGroups Ease of Communication Satisfaction with Perceived User Understanding Level of User Conflict of Information Participation Between SystemsProject Usersand Designers
4.20 1.36 3.66

Users Exposed to Prototyping Approach Users Exposed to Life Cycle Approach Two-Tailed Probability

3.86

3.00

3.21

2.86

2.78

0.13

0.0014 b

0.0019 b

0.11

"Scores measured on 5-point Liked scales (1 = low, 5 = high). b The difference between the means is statistically significant at p < 0.05.

tionnaires were completed and all the subjects' questions were answered.

STATISTICAL ANALYSIS AND FINDINGS The relationship between the independent variable (the information systems development approach) and the dependent variables (user evaluation and satisfaction with the information system, user and designer attitudes toward the design process, and utilization of the information system) was investigated by the MannWhitney U Test. 4 The Mann-Whitney U Test was used because the dependent variables were measured on Likert-type scales and because the sample sizes were relatively small. 5 The mean scores and the results of the M a n n Whitney U Test for the dependent variables related to user evaluation and satisfaction with the information system are given in Table III. The statistically significant results indicate that, in general, user groups who used the prototyping approach had a more favorable evaluation of the information system and were more satisfied with it. In comparison to other user groups, they rated the system output higher in terms of accuracy and helpfulness to their analysis and decision making. No statistically significant differences between the two user groups were observed in terms of timeliness of output and ease of use. The mean scores and results of the Mann-Whitney U Test for variables related to user perceptions and attitudes toward the design process are given in Table IV. In general, these results indicate that prototyping user groups had more favorable perceptions and attitudes toward the design approach, relative to life cycle users. The statistically significant results (at p < 0.05) show that prototyping user groups were more satisfied with 4This is one of the most powerful of the nonparametric tests, and it is a most useful alternative to the parametric test w h e n the researcher wishes to avoid the t test's assumptions or w h e n the measurement in the research is weaker than interval scaling. 5 For user groups the sample sizes were 15 and 19, and for designer groups the sample sizes were 14 and 15.

their level of participation in the design process and perceived less conflict between the users and designers throughout the project. Although the results were not statistically significant, examination of the means indicates users of the prototyped system had a higher rating for ease of communication with the designers and reported a higher understanding of the design project. The Mann-Whitney U Test result for the extent of actual use of information system output in making the new plant investment decision (Table V) was not statistically significant. However, the mean scores indicate a higher utilization of the system designed by the prototyping approach. Analysis of data on designer attitudes and perceptions of the design process (Table VI) shows statistically significant differences between the prototyping and life cycle designer groups on only one item. The designers employing the prototyping approach perceived a higher degree of change in user specifications during the design process. Another interesting observation (although not statistically significant) is that prototyping designers had more difficulty managing and controlling the design process than did life cycle designers.

DISCUSSION OF FINDINGS Interpretations of the research findings have to be qualified on two counts. First, the sample sizes, both in the
TABLE V. Mean Scores" and Mann-Whitney U Test Results for Extent of Use of MISIAP ExperimentalGroups
Users Exposed to Prototyping

DependentVariable Extentof Use of MISIAP


3.66 2.92 0.11

Approach Users Exposed to Life Cycle Approach


Two-Tailed Probability

Scores measured on 5-point Likert scales (1 = low, 5 = high).

June 1984

Volume 27 Number 6

Communications of the ACM

561

Computing Practices

TABLE VI. Mean Scores" and Mann-Whitney U Test Results for Designers' Perceptions and Attitudes Toward the Design Process ExperimentalGroups
Designers Using Prototyping Approach Designers Using Life Cycle Approach Two-Tailed Probabilities
"Scores measured on 5-point Likert scales (1 = low, 5 = high). b The difference between the means is statistically significant at p < 0.05.

Ease of Managementand Controlof DesignProcess


3.00 4.00 0.103

Frequencyof Changein User Requirements


3.43 1.34 0.012b

field interviews and in the experiment, were relatively small. Second, by the nature of laboratory experiments, the alternative design approaches--prototyping and life cycle--were compared in a less than realistic setting. Business information systems to date have not met with unqualified success. Managers and users frequently complain about a low return on their large investment in computer-based information systems. Many of these systems are not fully used nor their full potential realized. Analysis of the reasons for failure indicates that basic problems are behavioral as well as technological. Users too often have a preconceived notion of what they want an information system to do and assume the designers have the same idea. In some situations, users may not be able to clearly identify their information processing problems and may not know what potential solutions exist. These conditions often set off a chain of misunderstandings both of the constraints imposed by the problems and the opportunities offered by their potential solution. As users often have a difficult time visualizing what results an information system will produce, information systems designers need to develop ways of communicating and demonstrating such results before actually implementing the information system. Furthermore, once user requirements have been developed, the designer must convey to the user the logical design decisions that will have an eventual impact on the information system functions and the user. Such interactions have typically been missing, in part due to communication obstacles such as lack of a common language and a common flame of reference. The prototyping approach seems to be effective in alleviating these behavioral problems in information systems development. Field interviews with practitioners of the prototyping approach, substantiated by the findings of the laboratory experiment, indicate positive user attitudes toward the information system and the design and development process. The experimental results suggest that prototyping increases the actual utilization of an information system by the users. Furthermore, information systems performance (as measured in terms of user satisfaction with the output and its perceived accuracy and helpfulness) was rated higher by users of prototyped systems than by users of systems developed by the life cycle approach. Field and laboratory observations suggest that prototyping makes communication between users and designers relatively easy and conflict flee.

In the laboratory experiment, the experiences of designers using the prototyping versus the life cycle approach differed significantly on only one count--the perceived change in user requirements. The experiment also suggests that the designers of the prototyped information system experienced more difficulty managing and controlling the design process. These perceptions may be attributed to a higher level of user participation in the design process and more frequent changes in user requirements in the prototyping approach. Except for these two variables, no other noticeable differences between the two designer groups in the experimental setting were found. To some extent this conflicts with the field interview findings in which designers seemed to perceive improvements in communication and relationships with users when using the prototyping approach. The lack of difference between the two experimental designer groups may be attributable to the nature of laboratory experimentation. Another explanation may be that both user groups were highly motivated to work with the designer groups to complete the project, and hence, a high degree of communication and interaction between users and designers was observed by both experimental designer groups. However, more empirical research on the impact of prototyping on systems designers is clearly needed.
IMPLICATIONS FOR PRACTITIONERS

The research findings concerning the impact of the prototyping approach on designers and users of information systems provide some insight into the effectiveness of the prototyping approach. The field interviews in particular suggest the following guidelines for applying the prototyping approach. Who should use prototyping. A prototyping effort should be undertaken by designers and users who are well informed about the prototyping approach. Prototyping philosophy and plans should be understood by both designers and users. In the laboratory experiment, designers who used prototyping reported a high level of change in user requirements compared to designers who used the life cycle approach. Frequent changes in user requirements may frustrate designers unless they are prepared to expect the change and view it positively.
Where to use prototyping.

Prototyping is a new approach to information systems development, and like any organizational innovation, it needs a supportive or-

569

Communications of the ACM

June 1984 Volume 27 Number 6

Computing Practices

g a n i z a t i o n a l c l i m a t e . P r e r e q u i s i t e s to s u c c e s s f u l p r o t o t y p i n g i n c l u d e t e c h n o l o g i c a l tools t h a t f a c i l i t a t e fast res p o n s e to u s e r r e q u e s t s a n d m o t i v a t e d a n d k n o w l e d g e able users and designers.

W h e n to u s e the p r o t o t y p i n g a p p r o a c h . Use the prot o t y p i n g a p p r o a c h in t h e face o f u n c l e a r o r a m b i g u o u s u s e r r e q u i r e m e n t s . P r o t o t y p i n g s e e m s to b e e f f e c t i v e in c o p i n g w i t h u n d e c i d e d u s e r s a n d c l a r i f y i n g " f u z z y " req u i r e m e n t s . Also, p r o t o t y p i n g s h o u l d b e c o n s i d e r e d i n s i t u a t i o n s w h e r e t h e r e is a n e e d for e x p e r i m e n t a t i o n a n d l e a r n i n g b e f o r e c o m m i t m e n t o f r e s o u r c e s to d e v e l opment of a full-scale system. A typical situation would b e o n e in w h i c h i n n o v a t i v e t e c h n i c a l tools o r a p p r o a c h e s a r e u s e d . In a n e x a m p l e g i v e n b y C a n n i n g [2], a c o m p a n y w a n t e d to i n t e g r a t e t h r e e p u r c h a s e d p a c k ages i n t o o n e s y s t e m . P r o t o t y p i n g a l l o w e d t h e m to e x periment with different configurations and select the most effective way of linking the packages. H o w to p r o t o t y p e . M a n a g e a n d c o n t r o l t h e d e v e l o p m e n t o f t h e p r o t o t y p e b y p l a n n i n g t h e effort i n a d v a n c e (i.e., set cost, effort, a n d t i m e limits). S e t a n d e n f o r c e e x p l i c i t p r o c e d u r e s for c o n t r o l a n d c o o r d i n a t i o n (e.g., d e a d l i n e s for m o d i f y i n g a n d e x p e r i m e n t i n g w i t h t h e p r o t o t y p e , r u l e s a n d c r i t e r i a for d o c u m e n t a t i o n a n d testing). F a i l u r e to e s t a b l i s h e x p l i c i t p r o c e d u r e s for m a n a g i n g a n d c o n t r o l l i n g t h e p r o t o t y p i n g effort m a y r e s u l t in d e s i g n e r f r u s t r a t i o n a n d d i s s a t i s f a c t i o n . In p r o t o t y p i n g large p r o j e c t s , e x t r a c a r e s h o u l d b e t a k e n ; asp e c t s o f t h e s y s t e m to b e p r o t o t y p e d s h o u l d b e i d e n t i fied, a n d t h e p o s s i b i l i t y o f u s i n g p r o t o t y p i n g in c o n j u n c t i o n w i t h t h e t r a d i t i o n a l life c y c l e a p p r o a c h s h o u l d b e c o n s i d e r e d , as t h e m i l e s t o n e s a n d c o n t r o l p r o c e d u r e s o f f e r e d b y t h e life c y c l e a p p r o a c h s e e m to f a c i l i t a t e p r o j e c t m a n a g e m e n t as a w h o l e .
In s u m m a r y , t h e p r o t o t y p i n g a p p r o a c h offers a n opp o r t u n i t y to a c h i e v e f a v o r a b l e u s e r a t t i t u d e s t o w a r d t h e design process and the information system. Furtherm o r e , it f a c i l i t a t e s fast r e s p o n s e to u s e r n e e d s , a l l o w s c l a r i f i c a t i o n o f u s e r r e q u i r e m e n t s , a n d offers a n o p p o r t u n i t y for e x p e r i m e n t a t i o n . A l t h o u g h t h e r e a r e p i t f a l l s a n d s h o r t c o m i n g s , n o n e s e e m t r o u b l e s o m e e n o u g h to outweigh the potential benefits.

5. Groner, C., Hopwood, M.D., Palley, N.A., and Sibley, W. Requirements analysis in clinical research information processing--A case study. Co~nputer 12, 9 (Sept. 1979}, 100-108. Contains a case study describing the use of computer system prototypes during the requirements analysis phase of clinical research information systems development. 6. Henderson, J.C., and lngraham, R.S. Prototyping for DSS: A critical appraisal. In Decision Support Systems, M.J. Ginzberg, W.R. Reitman, and E.A. Stohr. Eds. Elsevier North-Holland, New York, 1982, pp. 79-96. Reviews the prototyping strategy and examines its use in the design and implementation of a model-based decision supiaort system (DSS). Information requirements generated by prototyping approach are compared with the information requirements generated by a structured group process. 7. Keen, P.G.W. Adaptive design for decision support systems. Database 12, 1 (Fall 1980), 15-25. Argues that decision support systems should be designed through an adaptiv e process of learning, experimentation, and evolution. A framework for adaptive design is presented. A number of case studies ore summarized in an appendix. 8. Keen, P.G.W. Value analysis: ]ustifying decision support systems. Manage. hff. Syst. Q. 5, 1 (Mar. 1981), 1-16. Deals with justification of decision support systems, which by their ~ery nature make traditional cost benefit analysis of little use. An alternative approach value analyms based on prototypmg and staged cost value assessment, is proposed. 9. Mason, R.E.A., and Carey, T.T. Prototyping interactive information systems. Commun. ACM 26, 5 (May 1983}, 347-354. Presents a prototype methodology and development tool, which have been widely applied to the development of interactive informer!on systems in the commercial data processing setting. The effectiveness of the methodology and relationship to other applications is discussed. lO. McCracken, D.D. Software in the 80's: Perils and promises. Comput. World Extra (Sept. 17, 1980}, 5-10. Describes the problems in applications software development. It is argued that the root cause is that wrong application development tools are being used. A solution consisting of use of very high-level nonprocedural languages and prototyping is suggested. 11. Naumann, I.D., Davis, G.B., and McKeen, I.D. Determining information system requirements: A contingency method for selection of a requirements assurance strategy. ]. Syst. Softw. 1, 4 (Dec. 1980), 2944. Describes information requirements determination in terms of two stages: eliciting requirements and requirements assurance. The paper describes the selection of a strategy for information assurance that depends on environmental and project contingencies. 12. Naumann, I.D., and Jenkins, A.M. Prototyping: The new paradigm for systems development. Manage. Inf. Syst. Q. 6, 3 (Sept. 1982), 2944. Reviews some of the published references to prototyping and presents a discussion of the underlying design concepts. A process model for information systems prototypes is developed. A discussion of the econbmics of prototyping and several examples are presented. 13, Sprague, R.H., and Carlson, E.D. Building Effective Decision Support Systems. Prerltice-Hall, Englewood Cliffs, N.J., 1982. Covers conceptual and organizational issues related to design, development, and implementation of decision support systems. 14. Zelkowitz, M.W. A case study in rapid prototyping. Soflw. Pract. Exper. 10, 12 {Dec. 1980), 1037-1042. Presents a case study in rapid prototyping using SNOBOL4. The goals of the experiment as well as some of the results are described. 15. Zelkowitz, M.V., Ed. Workshop notes. ACM SIGSOFT Workshop on Rapid Prototyping, Columbia, Md., Apr. 19-21, 1982. A collection of 31 papers on rapid prototyping. CR Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requirements~Specifications--methodologies; D.2.9 [Software Engineering]: Management--life cycle; D.2.m [Software Engineering]: Miscellaneous-rapid prototyping General Terms: Design, Management Additional Key Words and Phrases: assessment of prototyping approach Received 8/82; revised 11/83;/iccepted 11/83 Author's Present Address: Maryam Alavi, Dept. of Systems and Strategy, College of Business Administration, University of Houston, 4800 Calhoun, Houston, TX 77004. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.

REFERENCES 1. Berrisford, T.R., and Wetherbe, J.C. Heuristic development: A redesign of systems design. Manage. In[. Syst. Q. 3, 1 (Mar. 1979}, 11-19. Proposes a major change to the life cycle approach to information systems development. An alternative approach, the heuristic development, is presented. Several case studies of heuristic development are discussed. 2. Canning, R.G. Developing systems by prototyping. EDP Anal. 19, 9, (Sept. 1981}, 1-14. Defines software prototypes and describes their uses. Discusses technical and organizational requirements of prototyping. The application of prototyping approach in three large corporations is described. 3. Dodd, W.P. Prototyping programs. Computer 13, 2 (Feb. 1980}, 81. Discusses the need for software program prototypes and describes the potential benefits of the approach. 4, Earl, M.J. Prototype systems for accounting, information, and control. Account. Organ. Soc. 3, 2 (1978}, 161-170. Argues that many "principles" of MIS design fail to accommodate the complexities of organizational environment and learning. Three case studies are described, and a prototype procedure is presented.

June 1984

Volume 27

Number 6

Communications of the ACM

~3

Das könnte Ihnen auch gefallen