- Email: [email protected]
Organization and management of systems prototyping
Organizationand managementof systems prototyping P J Mayhew and P A Dearnley
The paper attempts to dispel the all too popular myth that prototyping is simply a matter of choosing, and subsequently using, a suitable high-productivity system building tool. Successful prototyping requires careful preparation, detailed organization, and effective control. A number of issues that need consideration be[ore beginning prototyping are presented. Of particular importance are those dealing with the objectives of prototyping, the education of all involved parties, and the control of the prototyping process. The intention is to provide assistance to those organizations with little, if any, actual experience of prototyping, so that they may feel more confident in adopting this type of approach to systems development. systems development, prototyping, management, organization
Prototyping is currently widely discussed as an approach to the development of computer-based systems. This increase in awareness has been reflected by the fact that most newly introduced software tools find it necessary to advertise themselves as being ideal for building prototype systems. The implication is that prototyping is simply a matter of choosing, and subsequently using, a suitable high-productivity system building tool. It is undoubtedly true that many of these tools enable both the speedy construction and the speedy modification of software prototypes. There is little advantage, however, in developing a useless prototype, no matter how quickly it is built. Better to consider at the outset how best to maximize the chances of successful prototyping, while at the same time avoiding the possible pitfalls. An appreciation of precisely what is meant by 'successful prototyping' can be gained by considering one definition of systems prototyping. Prototyping is defined as: 'the process of constructing and evaluating working models of a system in order to L E A R N about certain aspects of the required system and/or its potential solution.' The crucial component of this definition is encompassed in the word 'learn'. If nothing has been learned during the prototyping process it has been a waste of time and effort. For prototyping to be classified as useful, there-
School of Information Systems, University of East Anglia, Norwich NR4 7TJ, UK
vol 32 no 4 may 1990
fore, it must have enabled a better understanding of some aspect(s) of the proposed system. There are many issues that can be clarified by the use of system prototyping; there is much that can be 'learned'. Some of these include: • • • • •
discovering/clarifying system requirements experimenting with alternative designs assessing the likely effect on the organization evaluating the available hardware estimating performance levels
Any one prototype may be constructed and used to learn about one or more of those aspects noted above. What is important, however, is that these intentions have been carefully planned and recorded. Successful prototyping can, therefore, be defined as: 'prototyping which enables L E A R N I N G about those aspects of the required system that were identified as crucial at the outset.' In fact, prototyping often enables those involved to learn far more than just those aspects initially declared. Having decided the reasons for prototyping in a particular situation, the prototype itself still remains to be constructed. Unfortunately, a widespread impression exists that both building and using prototypes are trivial tasks. Tool vendors are partially responsible for this, as described above. A further reason can be discovered in the literature on prototyping. The notion of a 'stereotype prototyping session' abounds ~. This involves one user and one developer sitting at one terminal making immediate changes to a simple problem system. Some prototyping may be as Straightforward as this, but most is not. A prototype must be developed just like any other piece of software. Its production involves all the investigation, analysis, design, implementation, and evaluation activities of more conventional software development approaches. Prototyping is far from being a trivial task. Successful prototyping requires careful preparation, detailed organization, and effective control. These are discussed further in the remainder of this paper.
COMPONENT ACTIVITIES OF PROTOTYPING One all too prevalent view of the way in which prototyping progresses is illustrated in Figure 1. Prototype con-
0950-5849/90/040245~)8 © 1990 Butterworth-Heinemann Ltd
245
YES PROID'I'YI~
D~.mERATION
FINISH PROTOTYPING
ACTUALPROTOTYPING
CDMPI.ETION
9!
~TIME (during the development of some system)
Figure 1. Prevalent view of prototyping
•
YES PROTOTYPE
BEGIN PROTOTYPING
FINISH PROTOTYPING
COMPLETION
I~TIOW ORGANISATION
?!
?!
?!
~TIME (duringh~ development of some system)
Figure 2. Principal components of prototyping struction begins as soon as the decision to adopt this approach has been taken. This frequently precedes detailed consideration of what it is that this particular prototyping activity is meant to discover. A thorough understanding of the way in which the prototype is to be used and evaluated may also be lacking at this point. While prototyping in this haphazard fashion may well reveal details difficult to establish using a more conventional paper-based approach, it is unlikely to be the most efficient method of prototyping. Little attention, if any, has been paid to maximizing the chances of successful prototyping. Figure 2 shows a more complete view of the principal components of prototyping. It clearly emphasizes the activities concerned with preparation and organization. Prototyping is portrayed as having four main states separated by three decision points (This is clearly a gross simplification of a process that originates from the ability and willingness to learn through iteration. The intention, however, is to identify the many important issues that need to be resolved before actual prototyping taking place). The four main stages of prototyping illustrated in Figure 2 are as follows.
246
Deliberation This is the period during which those people involved in the system development decide whether prototyping is applicable. This involves an examination of the proposed system as well as an understanding of the current development situation and an appreciation of the target environment. The situations that have potential for the greatest benefit from prototyping are those in which there is much to be learned, i.e., those situations where a high level of uncertainty exists. In these situations (classified as other than type'S' problems2), it may be impossible to obtain a complete and correct system description. Many factors influence the prevailing level of uncertainty during systems development3-5, for example, the level of understanding about what is required and the number, proficiency, and previous experience of both users and developers.
Preparation/organization Having decided to prototype, a clear idea must be established of how the prototyping is to be conducted. This includes preparatory tasks, such as educating relevant
information and software technology
interested parties in such topics as the philosophy and practice of prototyping, and the use of suitable, hitherto unfamiliar tools and techniques. Careful consideration must be given to the organization of the prototyping itself. Issues such as the objective and the functionality of prototypes must be resolved. Questions about who is to participate in the prototyping, and how and when it is to be scheduled and controlled, must be answered. Once this planning stage is complete, prototyping may begin within this newly established support environment.
Actual prototyping This is clearly the heart of the process. Working models are constructed, used, and evaluated to the standards established previously. There may be many iterations during this stage, by using either additional isolated prototypes or enhancements to existing ones. At some point it has to be decided to halt this particular prototyping exercise and to continue developing the system or not as the case may be. For evolutionary prototyping, this continuation may involve little if any additional work. Exploratory prototyping, on the other hand, may precede a detailed design effort and possibly a further period of prototyping, this time of an experimental nature perhaps, to clarify possible solutions.
Completion When prototyping has finished, providing it has been successful, developers and users should better understand certain aspects of their system. They will also possess at least a partial working model (or specification) of the system, and, depending on the prototyping tool in use, there may be hardcopy documentation to describe further the prototype system. All these prototyping products can be used during development of the target system. The way in which development proceeds from prototype to production system depends on both the class of prototype and its level of sophistication. The pre-prototyping planning activity should have already considered how this translation is to take place. Possible options are: • to use the prototype as a production system • to throw the prototype away and perform a rewrite in a more suitable language • to redevelop the prototype in some way The way in which development of the production system proceeds varies according to the particular environment and is controlled by the plans established before prototyping started. Of the four principal components of prototyping outlined above, the preparation and organization stage has received least attention. Little has been published in this area and there appear to be few guidelines as to how prototyping should be organized. This may be partially
vol 32 no 4 may 1990
• • • • • • • • • • •
objectives of prototyping functionality of prototype(s) prototype(s) sophistication prototyping tool(s) prototyping participants education of interested parties location of prototyping schedule for prototyping organization of prototyping sessions controlling prototyping process recording prototyping
Figure 3. Organizing prototyping: issues for consideration responsible for the apparent reluctance of some management to introduce prototyping into their organizations. The remainder of this paper concentrates on a number of the many issues that need to be resolved before actually beginning prototyping. CAREFUL PREPARATION AND DETAILED ORGANIZATION The decision to adopt a prototyping approach to systems development must be followed by careful planning as to how this is to be accomplished. These preparations involve both the overall and detailed organization for prototyping. Figure 3 lists the issues to be resolved, each of which are described below.
Objectives of prototyping This involves determining what information is required from the prototyping of this particular system. This can be thought of as providing an answer to the question, 'What do we hope to learn from prototyping?' This could include learning about many system aspects, such as requirements, designs, hardware, performance, and organizational implications6. The objectives for prototyping must be defined at the outset as clearly as possible. This is necessary to assess the eventual success or otherwise of the prototyping process. It may also help to avoid any tendency to prolonged iteration.
Functionality of prototype(s) Having decided on the objectives of prototyping, the next decision to be taken concerns the prototype functionality necessary to meet these objectives. This can be thought of as providing an answer to the question 'Which functions are to be included in the prototype?' Functional selection refers to the choice of functions that are to be exhibited in the prototype. The range of features offered by any prototype is likely to be deficient compared to the final product, except in those cases in which the prototype is actually accepted into production. The differences between the functionality of the prototype and the target system fall into two categories (or a combination of these)7.8:
247
• Many functions are implemented, but not in detail, or in the way required, and are used purely for demonstration purposes. This may involve simulating some features and omitting others. This has been referred to as 'horizontal prototyping'. • Selected functions are offered in their intended final form, referred to as 'vertical prototyping'. However, the decisions about prototype functionality must be based on the objectives set for each prototype.
Prototype(s) sophistication The intended level of sophistication of each prototype must be established. It is particularly important to decide at the outset whether the prototype is eventually to evolve into the target system. If this is the case, then it must be engineered to production standards. Likewise for any parts of the prototype that are intended to be incorporated with minimum modification into the proposed system. For those prototypes, or parts of prototypes, that are constructed in the knowledge that they will be thrown away after use, a decision must be taken as to how realistically they need to be built. In general those prototypes constructed predominantly for the users' evaluation, e.g., exploratory and organizational prototypes, should be as realistic as is feasible in the circumstances. It may well be possible to create less sophisticated prototypes if they are not intended for review by the users, e.g., experimental and performance prototypes. It can be concluded, therefore, that the decision about prototype sophistication depends on both its stated objectives and its associated functionality.
Prototyping tool(s) In practice the selection of a suitable prototyping tool is likely to be carried out in association with consideration of both the functionality and the sophistication of the intended prototype, as these issues are clearly interdependent, e.g., select a package with strong report-generation facilities if reports are the main area of interest. However, this decision is obviously influenced by many other considerations, including the availability and cost of suitable tools. The existing development environment clearly restricts the choice of tools. It may not be feasible to acquire a new set of tools for the occasion, hence the existing software/hardware combination must suffice. A further constraint is imposed by the available personnel, e.g., there is no point in choosing APL if no experts are available. Tool selection may also be affected by political factors. While the choice of prototyping tool is undoubtedly important, experience indicates that aspects of a target system can be explored no matter which underlying prototyping tool is used. This suggests that it is possessing a willingness to follow a prototyping philosophy that is crucial, no matter which tools are selected.
248
Prototyping participants This involves selecting the number and make-up of both developers and user representatives who are to participate in the prototyping. Perhaps the most crucial decision at this point is concerned with who is to play the role of the prototyper. Those who have been involved in the logical design are in a position of knowing a great deal about the system, as well as already having been involved with the users. A logical designer appears to be the obvious choice for the prototyper's position. However, these people may have expended considerable time and effort in preparing the logical design and consequently may have considerable 'ego-involvement'. It would be difficult for one of them to act as an impartial prototyper. There is a danger that the users could be persuaded that the logical design is as it should be. Those developers who will be responsible for the physical design must also have a complete understanding of the system. However, it might be difficult for these people to act impartially as they may well be preoccupied with the implementation of the system. The danger here is that the users could be steered towards a particular conclusion because this was the simplest to implement. Another possibility is to employ the person who is the most proficient with the chosen construction tool as the prototyper, in which case suggested alterations could be easily incorporated. The main concern in this case is that this person may be a programmer who might lack the valuable experience of dealing with the user population. The personal qualities of the prototyper are also important. Ideally, this person must possess the qualities traditionally required by a systems analyst, including patience, diplomacy, perception, acceptability, and objectivity. Perhaps the most important attribute is that the prototyper must not be regarded as intimidating by the participating users. Should this be the case they may be dissuaded from making suggestions and criticisms, thus adversely affecting the feedback so crucial for productive prototyping. It may also be advisable to involve additional developers to provide support for the prototyper. A logical designer could be made available to provide clarification at the request of either the prototyper or the users. A physical designer could be made available for consultation to advise the prototyper of the feasibility of proposed changes. Care must be taken, however, that these developers do not defend or propose solutions so enthusiastically that it is to the detriment of the prototyping process. A further developer may be required to attend the prototyping sessions. This person would be responsible for keeping a written account of the session for control purposes, in particular to record all incorporated changes and suggested alterations. This should allow the prototyper to give full attention to the user participants. The person performing this secretarial role need not necessarily be the same for every prototyping session.
information and software technology
The use of video could negate the need for this additional developer participant. The selection of user participants for prototyping is basically concerned with choosing between the management, those people who will be responsible for the system under construction, or choosing the end-users, those people who will operate it, or in fact choosing any intermediate level of employee. It is possible, of course, to choose participants from more than one group of employees. However, if this is the case, and the intention is that they should all attend the same prototyping session, this may lead to a loss of objectivity among those involved. Selection of individual user participants is usually the responsibility of user management and depends on such criteria as status, experience, attitudes, and enthusiasm. The number of participating users must also be established. The usual assumption is that prototyping takes place with one developer and one user; however, this may have disadvantages, as follows: • • • •
It does not enable user debate. It does not encourage general system ownership. It could be intimidating for the one user. It relies on the knowledge and abilities of an individual.
Conversely, the more users that participate in the prototyping sessions, the greater the practical problems, e.g., many people attempting to view the same VDU. It has also been suggested that having multiple user participants slows down each prototyping activity. One view is that it is preferable to develop a prototype with one typical user and then to use it as a pilot or initial prototype with all other users 9. Another consideration is whether the same user participants should attend all the prototyping sessions or whether different people should be involved. One set of user representatives throughout prototyping has the obvious advantage of continuity, thus reducing the familiarization effort for each session and enabling users to become quite adept at their prototyping role. Introduction of a number of different users has the advantage of involving more people with the project development and so providing a greater wealth of knowledge, experience, and ideas. This also provides the opportunity for a wider understanding and appreciation of the system and consequently a wider sense of involvement, responsibility, and ownership.
Education of interested parties Once an informed decision has been taken to use prototyping in systems development, everybody connected with the project must be provided with an understanding of the consequences of this decision. What is meant by prototyping, the ideas behind it, and the way in which it differs from traditional pre-specification-based development must all be carefully explained. Following a prototyping approach may require those
vol 32 no 4 may 1990
people involved to adopt a substantially different attitude towards development. Users must be encouraged to participate actively in the system development, while, at the same time, they must remember that they are evaluating a prototype and not the live system. Developers must be willing not only to accept criticism but actively to seek it. It is important that participating users are prepared for their greatly increased role in systems development. They will be actively involved during the use and evaluate prototype activities. This will almost certainly mean that they will have to commit far more time than when they played a more conventional passive role. A more active role is associated with an increased user responsibility for both the progress of the development and the quality of the final product. How prototyping is to be organized and executed needs to be well publicised to foster an atmosphere of openness and cooperation. All those users and developers scheduled to participate in the prototyping process should be fully aware of the role that they are expected to fulfil. The importance of the users to the ultimate success of prototyping must be appreciated by all involved parties.
Location of prototyping This issue is concerned with organizing the situation for each prototyping session. In some circumstances there may be no choice in the matter, e.g., the equipment is only available at one site, in which case the main concern becomes ensuring that this place is made as suitable as possible. In other cases the first decision is whether prototyping should be taken to the users' own working environment, or whether it should be carried out on a separate site. The choice of site depends on the type of information that prototyping is designed to yield. If the intention is to improve understanding of the organizational aspects about the new system, clearly this can best (and perhaps can only) be achieved by prototyping in the target environment. For other classes of prototyping, a separate site may be preferred. Prototyping sessions in the user's own workplace may be simpler to arrange as they require less of the user participants' hard-pressed time. It may be difficult to avoid interruptions, however, and hence difficult to create a relaxing situation in which the user can give full attention to the prototype under discussion. Conversely, prototyping on a separate site will inevitably take up more of the users' time. A relaxed informal environment, free from interruptions, however, increases the opportunity for successful prototyping. Once it has been decided where the prototyping sessions are to be held, it is important to attempt to provide an atmosphere conducive to constructive participation. The aim must be to create a level of informality that will put the participants at their ease, e.g., avoid positioning chairs in rows facing the prototyper. In addition to equipment needed for demonstrating the prototype, faci-
249
lities to assist in explanation, e.g., flip boards and pens, need to be readily available.
Schedule for prototyping A further issue to be resolved is whether prototyping should be condensed into a short period, e.g., several sessions over three days, or whether it should be spread thinly over a longer period, e.g., once a week. The solution for a particular situation depends on where the sessions are scheduled to take place, the likelihood of users obtaining the time off normal duties, complexity of the prototype (and its underlying tool), and the speed at which it can be evaluated and altered. The overriding concern is to maintain user interest and enthusiasm; thus long intervals between prototyping sessions must be avoided. A variety of maximum times have been suggested, ranging from two days to a few weeks 1°-m2. It if takes too long to modify the prototype then it may well be better to scale down the changes and present it for evaluation. An enormous amount of information can be learned from using even simple prototypes. An additional consideration is that a certain amount of time is required so that both users and developers may consolidate the material covered to date. Users need to be able to digest, assess, and discuss the prototyping progress with their colleagues. Developers need time to consolidate the prototype with suggested alterations and to prepare for future sessions. The eventual schedule for prototyping sessions is likely to have an effect on those participating. In particular, the grouping of sessions reinforces the feeling of working as part of a team, which in turn can have a positive effect on the entire prototyping process.
Organization of prototyping sessions This involves deciding on such issues as the way in which sessions are to be conducted, scheduling o f sessions, and duration of each session. Consideration must be given to the order in which functions are to be prototyped. Should the crucial ones be dealt with first or should the participants be given the opportunity to practice on the relatively straightforward ones? In addition, it may prove useful to make a preliminary allocation of functions to be covered in each session. Rather than the developers imposing some arbitrary sequence, e.g., input functions precede output functions, it may be more appropriate to allow the users to decide on the sequence. It must be recognised that prototyping demands a high level of concentration from its participants, hence prolonged sessions need to be avoided. The users' powers of discrimination are likely to diminish towards the end of long sessions, as is also the case at certain times of the day, e.g., the period just before and after lunch. These points need to be taken into account during the allocation of functions as described above. While it may be useful (and necessary) to propose a
250
sensible duration for the prototyping sessions, the actual length of each individual session will depend on its circumstances. If the participants appear to be 'wilting' the prototyper should call a halt, have a break and, hopefully, restart refreshed. In contrast, it would be inappropriate to halt prototyping at precisely the allotted time if the participants were involved in an enthusiastic and detailed evaluation. If all the scheduled functions are evaluated before the allotted finish time, ending the session at this point allows the users to feel satisfied with their level o f productivity. In summary, the prototyper must be flexible in the amount of time spent on each session, with the intention of encouraging productive prototyping. The actual use and evaluation of the prototype depends on its characteristics. Prototypes that are of an exploratory nature will be demonstrated to, if not actually operated by, the users, so that they may be assessed against the users' real requirements. Thought must be given to the optimum level of explanation to be provided by the prototyper during the demonstration. Care must be taken that the users are not given so little information that they are unable to comment, and conversely, that they are not given too much and perhaps pushed towards a particular conclusion. Decisions as to whether to provide the users with available hardcopy also need to be considered at this point. Evaluation must be considered a crucial prototyping activity as it alone provides the feedback so important for further development. Evaluation involves assessing the prototype against the real needs of the users, by allowing them to experience it. Early prototype reviews may concentrate on major issues, e.g., does it look familiar? are there any gross oversights?, while later ones may consider the fine tuning, e.g., user-interface modifications. Before evaluation begins it is necessary to prepare a set of 'evaluation criteria', which depend largely on the prototype functionality and its objectives. The prototype's behaviour must be assessed against these criteria, by devising a series of trials, observations, or experiments. These tests must be well prepared and the following must be clear: • that they are carried out systematically • which aspects of the system are not addressed by this prototype • who is to carry them out • what information is to be recorded and how • who is to assess the results Analysis of a prototype is not easy. Each screen, function, error message, and so on needs to be reviewed for acceptability. To waste the opportunity to validate at this point risks jeopardizing potential prototyping benefits.
Control of prototyping process Procedures must be established that enable project managers to monitor and hence control the progress o f
information and software technology
the prototyping. Adoption of a prototyping approach is liable to introduce a greater degree of iteration and flexibility into the systems development process. Project managers need to be able to maintain control over these iterations. One method of achieving this, the 'change classification approach '~3, is based on: • classifying possible changes • deciding on how each class of change will be handled • classifying the changes that arise during prototyping Alternative suggestions for the control o f prototyping depend on deciding at this stage the point at which prototyping will be deemed to have finished, e.g., the specific number of prototypes have been built and evaluated; the total time allocated for prototyping the system has expired; th.e total budget allocation for prototyping has been exhausted ~¢~6. This may well be appealing for management but does not take into account the evolutionary nature of development through prototyping. A further suggestion involves regular negotiation efforts during the development process ~7. Each negotiation should result in a contract that contains details of the next prototype. It is clear that project management for prototyping must itself be more dynamic; a fixed period progress review is no longer applicable. This is undoubtedly an area that requires further research. For the time being, until suitable metrics are established, it is advisable to maintain a close observation of all aspects of the prototyping process.
Recording prototyping To gather valuable information on the use of prototyping in a particular organization, it is useful to keep a thorough record of the entire development. This should include documentation such as: • information on the project as a whole, e.g., user request, logical and physical designs • details of the planning and organization for prototyping, i.e., what was decided before prototyping • information covering the progress of prototyping, i.e., what actually happened • feedback from those people involved, e.g., criticisms, suggested improvements • problems, conclusions, and recommendations The above documentation serves to increase understanding of prototyping as a whole, as well as in particular within this organization. A better knowledge of prototyping assists in the future planning, estimation, adoption, and use of prototyping during systems development.
SUMMARY A widely held belief exists that prototyping is a simple task, involving little more than the selection and use of a
vol 32 no 4 may 1990
suitable high-productivity tool. This is far from being the truth. Careful consideration needs to be given to the planning of the prototyping to maximize its chances of being productive. Successful prototyping requires careful preparation, detailed organization, and effective control. It is time that more attention be directed towards these areas. This article has concentrated on the preparation and organization of prototyping. A wide range of issues that merit careful consideration before beginning prototyping has been suggested. Of particular importance are those concerning the objectives of prototyping, the education of interested parties, and controlling the prototyping process. It is not unusual for an organization to have development personnel who are interested, perhaps even enthusiastic, about prototyping, but who are understandably reluctant to adopt a new approach that lacks comprehensive instructions as to how to put it into practice. As yet there are no such comprehensive instructions, however, the third section above highlights a number of important areas that need to be addressed when adopting a prototyping approach to systems development. Hence it is hoped that this article will offer support to those organizations that find themselves in this uncertain situation.
REFERENCES 1 Boar, B H Application prototyping: a requirements definition strategy for the 80's John Wiley, Chichester, UK (1984) 2 Land, F 'Critical assessment of software engineering' in Ince, D (ed) Software engineering: the decade of change Peter Peregrinus, Stevenage, UK (1986) 3 Ginzberg, M J 'Redesign of managerial tasks: a requisite for successful decision support systems' MIS Q. Vol 2 No 7 (March 1978) 4 Davis, G B 'Strategies for information requirements determination' MISRC- WP-82-02 5 Naumann, J D, Davis, G B and McKeen, J D 'Determining information requirements: a contingency method for selection of requirements assurance strategy' J. Syst. Soft. Vol 1 (1980) 6 Mayhew, P J and Dearnley, P A 'An alternative prototyping classification' Cornput. J. Vol 30 No 6 (1987) 7 Mayr, H C, Bever, M and Lockemann, P C 'Prototyping interactive applications systems' in Bndde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG (1984) 8 Floyd, C "A systematic look at prototyping' in Budde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG
(1984) 9 Jenkins, A M "Prototyping: a methodology for the design and development of application systems' Discussion paper 227 Graduate School of Business, Indiana University, USA (1983) 10 MeCraken, D D 'A maverick approach to systems analysis and design' in Systerns analysis and design: a foundation for the 1980's Elsevier-North Holland, Amsterdam, The Netherlands (1981) 11 Riddle, W E 'Advancing the state of the art in software systems prototyping' in Badde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG (1984) 12 Donovan, J J and Madniek, S E 'Institutional and ad-hoc
251
DSS and their effective use' Database Vol 8 No 3 (Winter 1977) 13 Mayhew, P J, Worsley, C J and Dearnley, P A 'Control of software prototyping process: change classification approach' Inf. Soft. Technol. Vol 31 No 2 (March 1989) pp 59-66 14 Law, D Prototyping: a state of the art report NCC, Manchester, UK (1985) 15 Hekmatpour, S and Ince, D C 'Rapid software prototyping'
252
Technical report 86/4 Open University, Milton Keynes, UK (1986) 16 Kraashaar, J M and Shidanfl, L E 'A prototyping method for applications development by end users and information systems specialists' MIS Q. (September 1985) 17 Mathiassen, L 'Summary of the working group: systems development and prototyping' in Budde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG (1984)
information and software technology
The paper attempts to dispel the all too popular myth that prototyping is simply a matter of choosing, and subsequently using, a suitable high-productivity system building tool. Successful prototyping requires careful preparation, detailed organization, and effective control. A number of issues that need consideration be[ore beginning prototyping are presented. Of particular importance are those dealing with the objectives of prototyping, the education of all involved parties, and the control of the prototyping process. The intention is to provide assistance to those organizations with little, if any, actual experience of prototyping, so that they may feel more confident in adopting this type of approach to systems development. systems development, prototyping, management, organization
Prototyping is currently widely discussed as an approach to the development of computer-based systems. This increase in awareness has been reflected by the fact that most newly introduced software tools find it necessary to advertise themselves as being ideal for building prototype systems. The implication is that prototyping is simply a matter of choosing, and subsequently using, a suitable high-productivity system building tool. It is undoubtedly true that many of these tools enable both the speedy construction and the speedy modification of software prototypes. There is little advantage, however, in developing a useless prototype, no matter how quickly it is built. Better to consider at the outset how best to maximize the chances of successful prototyping, while at the same time avoiding the possible pitfalls. An appreciation of precisely what is meant by 'successful prototyping' can be gained by considering one definition of systems prototyping. Prototyping is defined as: 'the process of constructing and evaluating working models of a system in order to L E A R N about certain aspects of the required system and/or its potential solution.' The crucial component of this definition is encompassed in the word 'learn'. If nothing has been learned during the prototyping process it has been a waste of time and effort. For prototyping to be classified as useful, there-
School of Information Systems, University of East Anglia, Norwich NR4 7TJ, UK
vol 32 no 4 may 1990
fore, it must have enabled a better understanding of some aspect(s) of the proposed system. There are many issues that can be clarified by the use of system prototyping; there is much that can be 'learned'. Some of these include: • • • • •
discovering/clarifying system requirements experimenting with alternative designs assessing the likely effect on the organization evaluating the available hardware estimating performance levels
Any one prototype may be constructed and used to learn about one or more of those aspects noted above. What is important, however, is that these intentions have been carefully planned and recorded. Successful prototyping can, therefore, be defined as: 'prototyping which enables L E A R N I N G about those aspects of the required system that were identified as crucial at the outset.' In fact, prototyping often enables those involved to learn far more than just those aspects initially declared. Having decided the reasons for prototyping in a particular situation, the prototype itself still remains to be constructed. Unfortunately, a widespread impression exists that both building and using prototypes are trivial tasks. Tool vendors are partially responsible for this, as described above. A further reason can be discovered in the literature on prototyping. The notion of a 'stereotype prototyping session' abounds ~. This involves one user and one developer sitting at one terminal making immediate changes to a simple problem system. Some prototyping may be as Straightforward as this, but most is not. A prototype must be developed just like any other piece of software. Its production involves all the investigation, analysis, design, implementation, and evaluation activities of more conventional software development approaches. Prototyping is far from being a trivial task. Successful prototyping requires careful preparation, detailed organization, and effective control. These are discussed further in the remainder of this paper.
COMPONENT ACTIVITIES OF PROTOTYPING One all too prevalent view of the way in which prototyping progresses is illustrated in Figure 1. Prototype con-
0950-5849/90/040245~)8 © 1990 Butterworth-Heinemann Ltd
245
YES PROID'I'YI~
D~.mERATION
FINISH PROTOTYPING
ACTUALPROTOTYPING
CDMPI.ETION
9!
~TIME (during the development of some system)
Figure 1. Prevalent view of prototyping
•
YES PROTOTYPE
BEGIN PROTOTYPING
FINISH PROTOTYPING
COMPLETION
I~TIOW ORGANISATION
?!
?!
?!
~TIME (duringh~ development of some system)
Figure 2. Principal components of prototyping struction begins as soon as the decision to adopt this approach has been taken. This frequently precedes detailed consideration of what it is that this particular prototyping activity is meant to discover. A thorough understanding of the way in which the prototype is to be used and evaluated may also be lacking at this point. While prototyping in this haphazard fashion may well reveal details difficult to establish using a more conventional paper-based approach, it is unlikely to be the most efficient method of prototyping. Little attention, if any, has been paid to maximizing the chances of successful prototyping. Figure 2 shows a more complete view of the principal components of prototyping. It clearly emphasizes the activities concerned with preparation and organization. Prototyping is portrayed as having four main states separated by three decision points (This is clearly a gross simplification of a process that originates from the ability and willingness to learn through iteration. The intention, however, is to identify the many important issues that need to be resolved before actual prototyping taking place). The four main stages of prototyping illustrated in Figure 2 are as follows.
246
Deliberation This is the period during which those people involved in the system development decide whether prototyping is applicable. This involves an examination of the proposed system as well as an understanding of the current development situation and an appreciation of the target environment. The situations that have potential for the greatest benefit from prototyping are those in which there is much to be learned, i.e., those situations where a high level of uncertainty exists. In these situations (classified as other than type'S' problems2), it may be impossible to obtain a complete and correct system description. Many factors influence the prevailing level of uncertainty during systems development3-5, for example, the level of understanding about what is required and the number, proficiency, and previous experience of both users and developers.
Preparation/organization Having decided to prototype, a clear idea must be established of how the prototyping is to be conducted. This includes preparatory tasks, such as educating relevant
information and software technology
interested parties in such topics as the philosophy and practice of prototyping, and the use of suitable, hitherto unfamiliar tools and techniques. Careful consideration must be given to the organization of the prototyping itself. Issues such as the objective and the functionality of prototypes must be resolved. Questions about who is to participate in the prototyping, and how and when it is to be scheduled and controlled, must be answered. Once this planning stage is complete, prototyping may begin within this newly established support environment.
Actual prototyping This is clearly the heart of the process. Working models are constructed, used, and evaluated to the standards established previously. There may be many iterations during this stage, by using either additional isolated prototypes or enhancements to existing ones. At some point it has to be decided to halt this particular prototyping exercise and to continue developing the system or not as the case may be. For evolutionary prototyping, this continuation may involve little if any additional work. Exploratory prototyping, on the other hand, may precede a detailed design effort and possibly a further period of prototyping, this time of an experimental nature perhaps, to clarify possible solutions.
Completion When prototyping has finished, providing it has been successful, developers and users should better understand certain aspects of their system. They will also possess at least a partial working model (or specification) of the system, and, depending on the prototyping tool in use, there may be hardcopy documentation to describe further the prototype system. All these prototyping products can be used during development of the target system. The way in which development proceeds from prototype to production system depends on both the class of prototype and its level of sophistication. The pre-prototyping planning activity should have already considered how this translation is to take place. Possible options are: • to use the prototype as a production system • to throw the prototype away and perform a rewrite in a more suitable language • to redevelop the prototype in some way The way in which development of the production system proceeds varies according to the particular environment and is controlled by the plans established before prototyping started. Of the four principal components of prototyping outlined above, the preparation and organization stage has received least attention. Little has been published in this area and there appear to be few guidelines as to how prototyping should be organized. This may be partially
vol 32 no 4 may 1990
• • • • • • • • • • •
objectives of prototyping functionality of prototype(s) prototype(s) sophistication prototyping tool(s) prototyping participants education of interested parties location of prototyping schedule for prototyping organization of prototyping sessions controlling prototyping process recording prototyping
Figure 3. Organizing prototyping: issues for consideration responsible for the apparent reluctance of some management to introduce prototyping into their organizations. The remainder of this paper concentrates on a number of the many issues that need to be resolved before actually beginning prototyping. CAREFUL PREPARATION AND DETAILED ORGANIZATION The decision to adopt a prototyping approach to systems development must be followed by careful planning as to how this is to be accomplished. These preparations involve both the overall and detailed organization for prototyping. Figure 3 lists the issues to be resolved, each of which are described below.
Objectives of prototyping This involves determining what information is required from the prototyping of this particular system. This can be thought of as providing an answer to the question, 'What do we hope to learn from prototyping?' This could include learning about many system aspects, such as requirements, designs, hardware, performance, and organizational implications6. The objectives for prototyping must be defined at the outset as clearly as possible. This is necessary to assess the eventual success or otherwise of the prototyping process. It may also help to avoid any tendency to prolonged iteration.
Functionality of prototype(s) Having decided on the objectives of prototyping, the next decision to be taken concerns the prototype functionality necessary to meet these objectives. This can be thought of as providing an answer to the question 'Which functions are to be included in the prototype?' Functional selection refers to the choice of functions that are to be exhibited in the prototype. The range of features offered by any prototype is likely to be deficient compared to the final product, except in those cases in which the prototype is actually accepted into production. The differences between the functionality of the prototype and the target system fall into two categories (or a combination of these)7.8:
247
• Many functions are implemented, but not in detail, or in the way required, and are used purely for demonstration purposes. This may involve simulating some features and omitting others. This has been referred to as 'horizontal prototyping'. • Selected functions are offered in their intended final form, referred to as 'vertical prototyping'. However, the decisions about prototype functionality must be based on the objectives set for each prototype.
Prototype(s) sophistication The intended level of sophistication of each prototype must be established. It is particularly important to decide at the outset whether the prototype is eventually to evolve into the target system. If this is the case, then it must be engineered to production standards. Likewise for any parts of the prototype that are intended to be incorporated with minimum modification into the proposed system. For those prototypes, or parts of prototypes, that are constructed in the knowledge that they will be thrown away after use, a decision must be taken as to how realistically they need to be built. In general those prototypes constructed predominantly for the users' evaluation, e.g., exploratory and organizational prototypes, should be as realistic as is feasible in the circumstances. It may well be possible to create less sophisticated prototypes if they are not intended for review by the users, e.g., experimental and performance prototypes. It can be concluded, therefore, that the decision about prototype sophistication depends on both its stated objectives and its associated functionality.
Prototyping tool(s) In practice the selection of a suitable prototyping tool is likely to be carried out in association with consideration of both the functionality and the sophistication of the intended prototype, as these issues are clearly interdependent, e.g., select a package with strong report-generation facilities if reports are the main area of interest. However, this decision is obviously influenced by many other considerations, including the availability and cost of suitable tools. The existing development environment clearly restricts the choice of tools. It may not be feasible to acquire a new set of tools for the occasion, hence the existing software/hardware combination must suffice. A further constraint is imposed by the available personnel, e.g., there is no point in choosing APL if no experts are available. Tool selection may also be affected by political factors. While the choice of prototyping tool is undoubtedly important, experience indicates that aspects of a target system can be explored no matter which underlying prototyping tool is used. This suggests that it is possessing a willingness to follow a prototyping philosophy that is crucial, no matter which tools are selected.
248
Prototyping participants This involves selecting the number and make-up of both developers and user representatives who are to participate in the prototyping. Perhaps the most crucial decision at this point is concerned with who is to play the role of the prototyper. Those who have been involved in the logical design are in a position of knowing a great deal about the system, as well as already having been involved with the users. A logical designer appears to be the obvious choice for the prototyper's position. However, these people may have expended considerable time and effort in preparing the logical design and consequently may have considerable 'ego-involvement'. It would be difficult for one of them to act as an impartial prototyper. There is a danger that the users could be persuaded that the logical design is as it should be. Those developers who will be responsible for the physical design must also have a complete understanding of the system. However, it might be difficult for these people to act impartially as they may well be preoccupied with the implementation of the system. The danger here is that the users could be steered towards a particular conclusion because this was the simplest to implement. Another possibility is to employ the person who is the most proficient with the chosen construction tool as the prototyper, in which case suggested alterations could be easily incorporated. The main concern in this case is that this person may be a programmer who might lack the valuable experience of dealing with the user population. The personal qualities of the prototyper are also important. Ideally, this person must possess the qualities traditionally required by a systems analyst, including patience, diplomacy, perception, acceptability, and objectivity. Perhaps the most important attribute is that the prototyper must not be regarded as intimidating by the participating users. Should this be the case they may be dissuaded from making suggestions and criticisms, thus adversely affecting the feedback so crucial for productive prototyping. It may also be advisable to involve additional developers to provide support for the prototyper. A logical designer could be made available to provide clarification at the request of either the prototyper or the users. A physical designer could be made available for consultation to advise the prototyper of the feasibility of proposed changes. Care must be taken, however, that these developers do not defend or propose solutions so enthusiastically that it is to the detriment of the prototyping process. A further developer may be required to attend the prototyping sessions. This person would be responsible for keeping a written account of the session for control purposes, in particular to record all incorporated changes and suggested alterations. This should allow the prototyper to give full attention to the user participants. The person performing this secretarial role need not necessarily be the same for every prototyping session.
information and software technology
The use of video could negate the need for this additional developer participant. The selection of user participants for prototyping is basically concerned with choosing between the management, those people who will be responsible for the system under construction, or choosing the end-users, those people who will operate it, or in fact choosing any intermediate level of employee. It is possible, of course, to choose participants from more than one group of employees. However, if this is the case, and the intention is that they should all attend the same prototyping session, this may lead to a loss of objectivity among those involved. Selection of individual user participants is usually the responsibility of user management and depends on such criteria as status, experience, attitudes, and enthusiasm. The number of participating users must also be established. The usual assumption is that prototyping takes place with one developer and one user; however, this may have disadvantages, as follows: • • • •
It does not enable user debate. It does not encourage general system ownership. It could be intimidating for the one user. It relies on the knowledge and abilities of an individual.
Conversely, the more users that participate in the prototyping sessions, the greater the practical problems, e.g., many people attempting to view the same VDU. It has also been suggested that having multiple user participants slows down each prototyping activity. One view is that it is preferable to develop a prototype with one typical user and then to use it as a pilot or initial prototype with all other users 9. Another consideration is whether the same user participants should attend all the prototyping sessions or whether different people should be involved. One set of user representatives throughout prototyping has the obvious advantage of continuity, thus reducing the familiarization effort for each session and enabling users to become quite adept at their prototyping role. Introduction of a number of different users has the advantage of involving more people with the project development and so providing a greater wealth of knowledge, experience, and ideas. This also provides the opportunity for a wider understanding and appreciation of the system and consequently a wider sense of involvement, responsibility, and ownership.
Education of interested parties Once an informed decision has been taken to use prototyping in systems development, everybody connected with the project must be provided with an understanding of the consequences of this decision. What is meant by prototyping, the ideas behind it, and the way in which it differs from traditional pre-specification-based development must all be carefully explained. Following a prototyping approach may require those
vol 32 no 4 may 1990
people involved to adopt a substantially different attitude towards development. Users must be encouraged to participate actively in the system development, while, at the same time, they must remember that they are evaluating a prototype and not the live system. Developers must be willing not only to accept criticism but actively to seek it. It is important that participating users are prepared for their greatly increased role in systems development. They will be actively involved during the use and evaluate prototype activities. This will almost certainly mean that they will have to commit far more time than when they played a more conventional passive role. A more active role is associated with an increased user responsibility for both the progress of the development and the quality of the final product. How prototyping is to be organized and executed needs to be well publicised to foster an atmosphere of openness and cooperation. All those users and developers scheduled to participate in the prototyping process should be fully aware of the role that they are expected to fulfil. The importance of the users to the ultimate success of prototyping must be appreciated by all involved parties.
Location of prototyping This issue is concerned with organizing the situation for each prototyping session. In some circumstances there may be no choice in the matter, e.g., the equipment is only available at one site, in which case the main concern becomes ensuring that this place is made as suitable as possible. In other cases the first decision is whether prototyping should be taken to the users' own working environment, or whether it should be carried out on a separate site. The choice of site depends on the type of information that prototyping is designed to yield. If the intention is to improve understanding of the organizational aspects about the new system, clearly this can best (and perhaps can only) be achieved by prototyping in the target environment. For other classes of prototyping, a separate site may be preferred. Prototyping sessions in the user's own workplace may be simpler to arrange as they require less of the user participants' hard-pressed time. It may be difficult to avoid interruptions, however, and hence difficult to create a relaxing situation in which the user can give full attention to the prototype under discussion. Conversely, prototyping on a separate site will inevitably take up more of the users' time. A relaxed informal environment, free from interruptions, however, increases the opportunity for successful prototyping. Once it has been decided where the prototyping sessions are to be held, it is important to attempt to provide an atmosphere conducive to constructive participation. The aim must be to create a level of informality that will put the participants at their ease, e.g., avoid positioning chairs in rows facing the prototyper. In addition to equipment needed for demonstrating the prototype, faci-
249
lities to assist in explanation, e.g., flip boards and pens, need to be readily available.
Schedule for prototyping A further issue to be resolved is whether prototyping should be condensed into a short period, e.g., several sessions over three days, or whether it should be spread thinly over a longer period, e.g., once a week. The solution for a particular situation depends on where the sessions are scheduled to take place, the likelihood of users obtaining the time off normal duties, complexity of the prototype (and its underlying tool), and the speed at which it can be evaluated and altered. The overriding concern is to maintain user interest and enthusiasm; thus long intervals between prototyping sessions must be avoided. A variety of maximum times have been suggested, ranging from two days to a few weeks 1°-m2. It if takes too long to modify the prototype then it may well be better to scale down the changes and present it for evaluation. An enormous amount of information can be learned from using even simple prototypes. An additional consideration is that a certain amount of time is required so that both users and developers may consolidate the material covered to date. Users need to be able to digest, assess, and discuss the prototyping progress with their colleagues. Developers need time to consolidate the prototype with suggested alterations and to prepare for future sessions. The eventual schedule for prototyping sessions is likely to have an effect on those participating. In particular, the grouping of sessions reinforces the feeling of working as part of a team, which in turn can have a positive effect on the entire prototyping process.
Organization of prototyping sessions This involves deciding on such issues as the way in which sessions are to be conducted, scheduling o f sessions, and duration of each session. Consideration must be given to the order in which functions are to be prototyped. Should the crucial ones be dealt with first or should the participants be given the opportunity to practice on the relatively straightforward ones? In addition, it may prove useful to make a preliminary allocation of functions to be covered in each session. Rather than the developers imposing some arbitrary sequence, e.g., input functions precede output functions, it may be more appropriate to allow the users to decide on the sequence. It must be recognised that prototyping demands a high level of concentration from its participants, hence prolonged sessions need to be avoided. The users' powers of discrimination are likely to diminish towards the end of long sessions, as is also the case at certain times of the day, e.g., the period just before and after lunch. These points need to be taken into account during the allocation of functions as described above. While it may be useful (and necessary) to propose a
250
sensible duration for the prototyping sessions, the actual length of each individual session will depend on its circumstances. If the participants appear to be 'wilting' the prototyper should call a halt, have a break and, hopefully, restart refreshed. In contrast, it would be inappropriate to halt prototyping at precisely the allotted time if the participants were involved in an enthusiastic and detailed evaluation. If all the scheduled functions are evaluated before the allotted finish time, ending the session at this point allows the users to feel satisfied with their level o f productivity. In summary, the prototyper must be flexible in the amount of time spent on each session, with the intention of encouraging productive prototyping. The actual use and evaluation of the prototype depends on its characteristics. Prototypes that are of an exploratory nature will be demonstrated to, if not actually operated by, the users, so that they may be assessed against the users' real requirements. Thought must be given to the optimum level of explanation to be provided by the prototyper during the demonstration. Care must be taken that the users are not given so little information that they are unable to comment, and conversely, that they are not given too much and perhaps pushed towards a particular conclusion. Decisions as to whether to provide the users with available hardcopy also need to be considered at this point. Evaluation must be considered a crucial prototyping activity as it alone provides the feedback so important for further development. Evaluation involves assessing the prototype against the real needs of the users, by allowing them to experience it. Early prototype reviews may concentrate on major issues, e.g., does it look familiar? are there any gross oversights?, while later ones may consider the fine tuning, e.g., user-interface modifications. Before evaluation begins it is necessary to prepare a set of 'evaluation criteria', which depend largely on the prototype functionality and its objectives. The prototype's behaviour must be assessed against these criteria, by devising a series of trials, observations, or experiments. These tests must be well prepared and the following must be clear: • that they are carried out systematically • which aspects of the system are not addressed by this prototype • who is to carry them out • what information is to be recorded and how • who is to assess the results Analysis of a prototype is not easy. Each screen, function, error message, and so on needs to be reviewed for acceptability. To waste the opportunity to validate at this point risks jeopardizing potential prototyping benefits.
Control of prototyping process Procedures must be established that enable project managers to monitor and hence control the progress o f
information and software technology
the prototyping. Adoption of a prototyping approach is liable to introduce a greater degree of iteration and flexibility into the systems development process. Project managers need to be able to maintain control over these iterations. One method of achieving this, the 'change classification approach '~3, is based on: • classifying possible changes • deciding on how each class of change will be handled • classifying the changes that arise during prototyping Alternative suggestions for the control o f prototyping depend on deciding at this stage the point at which prototyping will be deemed to have finished, e.g., the specific number of prototypes have been built and evaluated; the total time allocated for prototyping the system has expired; th.e total budget allocation for prototyping has been exhausted ~¢~6. This may well be appealing for management but does not take into account the evolutionary nature of development through prototyping. A further suggestion involves regular negotiation efforts during the development process ~7. Each negotiation should result in a contract that contains details of the next prototype. It is clear that project management for prototyping must itself be more dynamic; a fixed period progress review is no longer applicable. This is undoubtedly an area that requires further research. For the time being, until suitable metrics are established, it is advisable to maintain a close observation of all aspects of the prototyping process.
Recording prototyping To gather valuable information on the use of prototyping in a particular organization, it is useful to keep a thorough record of the entire development. This should include documentation such as: • information on the project as a whole, e.g., user request, logical and physical designs • details of the planning and organization for prototyping, i.e., what was decided before prototyping • information covering the progress of prototyping, i.e., what actually happened • feedback from those people involved, e.g., criticisms, suggested improvements • problems, conclusions, and recommendations The above documentation serves to increase understanding of prototyping as a whole, as well as in particular within this organization. A better knowledge of prototyping assists in the future planning, estimation, adoption, and use of prototyping during systems development.
SUMMARY A widely held belief exists that prototyping is a simple task, involving little more than the selection and use of a
vol 32 no 4 may 1990
suitable high-productivity tool. This is far from being the truth. Careful consideration needs to be given to the planning of the prototyping to maximize its chances of being productive. Successful prototyping requires careful preparation, detailed organization, and effective control. It is time that more attention be directed towards these areas. This article has concentrated on the preparation and organization of prototyping. A wide range of issues that merit careful consideration before beginning prototyping has been suggested. Of particular importance are those concerning the objectives of prototyping, the education of interested parties, and controlling the prototyping process. It is not unusual for an organization to have development personnel who are interested, perhaps even enthusiastic, about prototyping, but who are understandably reluctant to adopt a new approach that lacks comprehensive instructions as to how to put it into practice. As yet there are no such comprehensive instructions, however, the third section above highlights a number of important areas that need to be addressed when adopting a prototyping approach to systems development. Hence it is hoped that this article will offer support to those organizations that find themselves in this uncertain situation.
REFERENCES 1 Boar, B H Application prototyping: a requirements definition strategy for the 80's John Wiley, Chichester, UK (1984) 2 Land, F 'Critical assessment of software engineering' in Ince, D (ed) Software engineering: the decade of change Peter Peregrinus, Stevenage, UK (1986) 3 Ginzberg, M J 'Redesign of managerial tasks: a requisite for successful decision support systems' MIS Q. Vol 2 No 7 (March 1978) 4 Davis, G B 'Strategies for information requirements determination' MISRC- WP-82-02 5 Naumann, J D, Davis, G B and McKeen, J D 'Determining information requirements: a contingency method for selection of requirements assurance strategy' J. Syst. Soft. Vol 1 (1980) 6 Mayhew, P J and Dearnley, P A 'An alternative prototyping classification' Cornput. J. Vol 30 No 6 (1987) 7 Mayr, H C, Bever, M and Lockemann, P C 'Prototyping interactive applications systems' in Bndde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG (1984) 8 Floyd, C "A systematic look at prototyping' in Budde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG
(1984) 9 Jenkins, A M "Prototyping: a methodology for the design and development of application systems' Discussion paper 227 Graduate School of Business, Indiana University, USA (1983) 10 MeCraken, D D 'A maverick approach to systems analysis and design' in Systerns analysis and design: a foundation for the 1980's Elsevier-North Holland, Amsterdam, The Netherlands (1981) 11 Riddle, W E 'Advancing the state of the art in software systems prototyping' in Badde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG (1984) 12 Donovan, J J and Madniek, S E 'Institutional and ad-hoc
251
DSS and their effective use' Database Vol 8 No 3 (Winter 1977) 13 Mayhew, P J, Worsley, C J and Dearnley, P A 'Control of software prototyping process: change classification approach' Inf. Soft. Technol. Vol 31 No 2 (March 1989) pp 59-66 14 Law, D Prototyping: a state of the art report NCC, Manchester, UK (1985) 15 Hekmatpour, S and Ince, D C 'Rapid software prototyping'
252
Technical report 86/4 Open University, Milton Keynes, UK (1986) 16 Kraashaar, J M and Shidanfl, L E 'A prototyping method for applications development by end users and information systems specialists' MIS Q. (September 1985) 17 Mathiassen, L 'Summary of the working group: systems development and prototyping' in Budde, R, Kuhlenkamp, K K, Mathiassen, L and Zullighoven, H (eds) Approaches to prototyping Springer-Verlag, Berlin, FRG (1984)
information and software technology