a phased approach to the evaluation and selection of case tools

Information and Software Technology 1994 36 (5) 267-273

A phased approach to the evaluation and selection of CASE tools

Louis A Le Blanc Department of Management, College of Business Administration, University of Arkansas at Little Rock, 2801 South University, Little Rock, AR 72204-1099, USA

Willard M Korn Department of Management Information Systems, School of Business, University of Wisconsin, Eau Claire, WI 54702-4004, USA

This paper illustrates an evaluation and selection approach for CASE software or CASE tools. The approach incorporates three phases: (1) CASE software screening; (2) CASE tool evaluation; and (3) confirmation of the final CASE software selection. Initially, developing a short list through screening of commercial CASE products determines whether appropriate tools exist and narrows the field of available CASE software products for detailed consideration. The second phase determines which of the remaining products (the finalists) best meets the needs of the organization, from both functional and technical perspectives. The final phase compares user requirements with the features of the selected CASE software by defining how these requirements will be satisfied by building applications with the selected product. The approach also considers the possibility that, in any phase of the process, no single CASE product is suitable and that a combination of products must be utilized.

Keywords: software evaluation and selection, CASE, computer aided systems engineering, computer aided software engineering, productivity, application development

Overview of C A S E

Computer Aided Systems Engineering (CASE) has occu- pied a position of prominence and has generated much debate over the past several years. In the midst of all the 'hype' and attention, CASE seems to be one of those ill- defined and often misunderstood information system acronyms. CASE technology, with its wide variety of tools and techniques produced by many different vendors, seems to have obscured the underlying concepts attendant with the adoption of any form of CASE software.

The primary reason(s) for the adoption of CASE should be built around the need for: (a) increased integration of cross-functional systems; (b) improved quality of systems; and (c) integration of business goals, objectives, and functions with the systems developed. The adoption of CASE technology not only introduces technological change but more importantly introduces a change in the basic philosophy of systems development. In some instances the organization will experience a 'culture shock' when embarking upon the implementation of the CASE environment.

CASE is a tool that, among other things, is used to capture information regarding business strategies, goals and objectives. CASE itself does not set these goals and objectives, nor does it align information systems with the business strategies. CASE helps capture and catalogue such information.

The adoption of CASE technology usually demands an in-depth evaluation of the organization's current systems development methodology. Methodologies such as METHOD/l, NAVIGATOR, STRADIS, IEF, and IEM, are all characterized by the introduction of 'rigour' into the systems' development process. All the aforementioned methodologies have very detailed and specific procedures for systems development. These methodologies may be integrated very closely with a specific CASE product, or they may be supported by a variety of such products. In either instance, there should be an accepted, specific, rigorous systems development methodology for the CASE tool to support.

All the tools and techniques that support the systems development methodology (often termed Systems Develop- ment Life Cycle) and all its phases are considered within

0950-5849/94/050267-07 © 1994 Butterworth-Heinemann Ltd 267

The evaluation and selection o f CASE tools: L A Le Blanc and W M Korn

the realm of CASE software. Most methodologies will have the following major phases: (a) analysis; (b) design; (c) construction; (d) implementation; and (e) maintenance.

CASE def'mition

There are several definitions of CASE. Some believe it means Computer Aided Software Engineering: the key term being 'software' because the tool is used to develop software. There are those who believe that the acronym should be Computer Aided Systems Engineering: the word 'systems' is used to imply a broader meaning than software. The purpose of this paper is not to debate this issue, but to suggest a general approach for selecting CASE software. Whether the term used is 'systems' or 'software', the list of products available appears to be substantially the same.

The software products that support the analysis and design portion of a systems development methodology are commonly termed 'front end' or 'upper' CASE tools. Those software products that support the construction and implementation parts of the methodology are usually known as 'back end' or 'lower' CASE tools.

The CASE software selection problem

Prior publications by Mach ~ and Sharon 2 have typically not addressed the issue of evaluating and selecting CASE software, except to identify potentially important criteria. These authors do not suggest how to incorporate multiple user criteria, as well as technical attributes, into a complete and thorough evaluation and selection process. There is some evidence in the systems literature 3-5 which suggests that inadequate examination of prospective software packages leads to serious difficulties if not failures when implementing computerized information systems.

Although a number of approaches to selecting application software for transaction processing systems (TPS) and management information systems (MIS) have been proposed, some very critical factors were omitted 6-s. These factors include assuring that the selected software package is superior to a custom alternative, or that a screening process is provided to reduce the number of packages subjected to detailed evaluation.

To advance the importance of the evaluation and selection of CASE software (as compared to that of TPS and MIS), it should be noted that CASE tools are used to develop multiple applications. For example, MIS software is employed only for a single application, such as a general ledger system. CASE software is used to develop many other software applications.

Selecting the best CASE software helps ensure the following: improved end-user satisfaction, increased systems quality, reduced application development time, as well as decreased maintenance costs. (A different set of benefits accrue from selecting the best application package, and these benefits are specific to the particular application, whether financial or manufacturing, etc.) To deliver the aforementioned benefits from efficiently developing applications using CASE technology, the appropriate CASE tool(s) need be available.

Selecting CASE software has unique functional requirements for developing multiple custom applications, such as automation of the complete system development life-cycle or ensuring consistency throughout the system development life-cycle. The critical software evaluation and selection process for CASE software takes place before any custom application development (i.e., before systems analysis, design, etc.), whereas selecting packaged software for a business application (i.e., selecting general ledger software) is an integral part of systems analysis.

Structure of the paper

This paper illustrates an approach to select the most appropriate CASE software where multiple criteria exist not only from functional requirements but also from technical perspectives. As an essential part of the approach, the initial phase determines whether any CASE software product is even suitable to support a particular system development methodology or whether a combination of CASE tools should be employed.

The proposed selection process also ensures that, in each successive phase, the CASE tool will be applicable to the organization's system development methodology. It con- tinually reduces the number of CASE software products under consideration until a final selection or a decision about the readiness of the organization for the adoption of CASE technology is made.

The paper is primarily addressed to information system professionals interested in software selection methodologies as well as practitioners faced with CASE-related problems. The second section of the paper suggests a multiple criteria approach for CASE software/tool selection, including a phase to assure that the CASE software selected is indeed the best available. CASE tools and CASE software are used throughout as interchangeable terms. The third section con- cludes the paper with some final comments and observations.

A phased approach for CASE software selection

There are three principal phases in the proposed CASE software evaluation and selection approach:

(1) Screening of prospective candidates and development of a short list of CASE software.

(2) Selecting a CASE tool which best suits the systems development requirements.

(3) Confirmation of the match between user requirements and the features of the selected CASE tool and describing how these requirements will be satisfied.

The detailed procedures involved in each phase of the selection process are described in the following sections. The complete approach provides a project outline for the evaluation and selection of CASE software. At the end of each phase the approach produces a deliverable -- a well- defined output or result (i.e., the short list of software packages at the conclusion of the initial phase). Given the structured nature of this CASE software evaluation approach, scheduling (i.e., determination of start and finish dates) for each phase, as well as the entire project, is

268 Information and Software Technology 1994 Volume 36 Number 5

The evaluation and selection of CASE tools: L A Le Blanc and W M Korn

Table 1. Representative CASE products

Product Vendor

IEF Texas Instruments PacBase CGI Systems Foundation Arthur Andersen ADW/IEW KnowledgWare System Architect Popkin Software & Systems Synon2/E Synon Natural Software AG ProKit*Analyst McDonnell Douglas ProKit*Workbench McDonnell Douglas Excelcrator InterSolv POSE Computer Systems Advisors Telon Computer Associates Teamwork CADRE

S o f t w a r e Organization

possible. (A Gantt chart or other similar device can be used for this purpose.) Staffing requirements can also be deter- mined, including both the number of staff members and their required skills. To evaluate and select CASE software, a project team should be assembled with representatives from a cross-section of information systems professionals in the enterprise.

C A S E s o f t w a r e s c r e e n i n g

During this first phase of the evaluation and selection approach, three key issues must be addressed: (1) What CASE software is available?; (2) Which CASE software packages should be seriously considered and evaluated in detail?; and (3) Is there a single CASE tool that can be used or should a combination of tools be utilized? Examples of some of the available CASE products are given in Table 1. For more examples, see ComputerworM 9:°.

The purpose of developing a short list of CASE products is to narrow the field of available CASE software for consideration. A short list of candidate CASE tools (two or three) eliminates any unnecessary effort or confusion that might result because too many CASE alternatives are being considered and evaluated.

Identify candidate CASE software

The project team must first identify the current systems development methodology. Then the team must identify available CASE products that support that methodology. This will include an identification of whether or not products will operate within the enterprise's specific hardware and software configuration. An enterprise may have dedi- cated hardware for running other applications. This may be a technical constraint for CASE products under consideration. To initially identify appropriate CASE software, there are several publishers (e.g., Datapro and ICP) who provide profiles of software vendors and the products they offer.

Screening criteria

The list of screening criteria for CASE tools will contain relatively few items and should concentrate on functional requirements not commonly provided and which are very specific to the systems development methodology of the organization evaluating CASE software. Most commercial

Figure 1 Matching of CASE screening criteria

CASE software packages share many standard functions and capabilities. At the same time, organizations have many identical requirements for software. However, CASE software packages may have unique capabilities and features which can readily distinguish one tool from another.

The screening process matches the unique capabilities of commercial CASE packages with the unique requirements of the organization. Figure 1 illustrates the overlap between unique capabilities of software with the unique requirements of an organization. The CASE tools with the greatest overlap of unique capabilities with unique organizational requirements would be retained for more detailed scrutiny in the next phase of this CASE software evaluation and selection approach (i.e., CASE Software Evaluation).

At this point in the process, the concern is not how well the respective commercial CASE packages meet the screening criteria, but only if the screening criteria (i.e. unique capabilities) are offered by the CASE software. In the next phase of the approach, all criteria (including both standard and unique capabilities) are evaluated as to how well they are performed by each respective CASE tool on the short list.

The CASE tool screening criteria can be categorized into four major types:

(1) Technical requirements. (2) Functional requirements. (3) Documentation and training. (4) Vendor information.

Technical requirements. An organization's hardware and software strategy will likely dictate the screening criteria in the technical area. To be considered, a CASE product must be compatible with the installed hardware and system software. The operating system is clearly a strict technical consideration. Others could include programming languages, peripherals, memory needs, or data communication capabilities.

Functional requirements. To be further considered, a CASE tool must fit the framework of the existing or proposed systems development methodology of the firm. Functional requirements of CASE software include: (a) support for the

Information and Software Technology 1994 Volume 36 Number 5 269

The evaluation and selection of CASE tools: L ALe Blanc and W M Korn

Table 2. Potential screening criteria of CASE software

• Support for entire systems development life-cycle • Full integration of tools • Common repository • Standard common user interface • Hardware/software portability • Fully supported on network

phases of the system development life-cycle (SDLC); CO) integrated features; (c) full repository; (d) network support; and (e) standard user interface. (The user interface component of a CASE tool provides the dialogue structure through which the user can access the various CASE components.) These types of functional requirements readily distinguish CASE software evaluation and selection from other software appraisal efforts.

Functional screening criteria represent software capabilities that the CASE software tool must absolutely offer for the systems developer (i.e., process modelling, data modelling, decomposition capabilities, prompted- menu display, etc.). Table 2 lists several examples of functional criteria to conduct the first-cut screening.

In many instances, one CASE tool may not adequately serve the needs of an organization. Thus, it is possible to have more than one CASE tool, or integrated CASE (I- CASE). For example, an enterprise may consider a combination of EXCELERATOR as the upper CASE tool and SYNON2 as the lower CASE tool.

Documentation and training. CASE software packages normally include the documentation required to install and support the software. It should be detailed, complete, and easy to understand. The availability of vendor-developed training sessions and materials may be very important, especially when the organization's personnel are inexperi- enced in the systems development methodology and supporting CASE tools.

Vendor information. A vendor's ability to support its CASE tool through training, consultation, installation and maintenance assistance is an important consideration in evaluating any CASE software package. The vendor should also be able to refer an evaluation team to a user who is willing to talk to them about the CASE software and the accompanying support.

The financial stability of a vendor can also be an important consideration. Financially successful vendors that have been in existence for more than a few years are more likely to support their CASE software adequately initially and in the future because such vendors attract and retain competent personnel. But financial success alone does not ensure adequate and continued support. Vendor image, tool reputation, the unit price, and the number of installations are also important considerations. Either the vendors themselves or the users to whom they directed the prospective buyer should be able to provide the needed information in these areas.

Pick finalists

The matching of the screening criteria against the list of

CASE software and their capabilities will cause the elimination of many (but hopefully not all) alternatives. The following are typical reasons to eliminate potential CASE tools: (a) a vendor has only a few employees and has been in business less than a year; CO) operating systems software and hardware is not supported by a CASE vendor, and (c) CASE software documentation is inadequate.

By reducing the number of CASE software packages under consideration from as many as 10 or 15 to two or three, a project team can more effectively devote its attention to the critical details that can make the difference between selecting an adequate CASE product and selecting a superior one. Moreover, by determining which CASE software packages are available, the screening process also determines whether a CASE tool can be used or if other tools and techniques should be utilized.

CASE software evaluation

The second phase focuses on the two or three CASE products that were identified in the initial screening. The objective is to evaluate in detail the CASE finalists and select the one tool (or combination of tools) that best meets the needs of the organization. The primary tasks of CASE software evaluation are: (a) to define the detailed evaluation criteria; Co) obtain more detailed CASE product information; and (c) evaluate the finalists and pick one CASE tool (or combination of tools) as the best alternative.

Expand evaluation criteria

The screening criteria are expanded in more detail and fall into the same four categories: (1) technical requirements; (2) functional requirements; (3) documentation and training; and (4) vendor information. Although all categories are expanded during this evaluation, the functional requirements receive the most attention. The purpose of this task is to develop a rather comprehensive functional view of the proposed application development platform and to summarize the requirements that must be satisfied by the CASE product. As the project team defines the functional criteria, they should also document the levels of importance and need to the organization's SDLC methodology. Table 3 exhibits an expansion of the previously noted functional CASE requirements.

Obtain package information

Once the application development requirements have been established and the criteria reviewed, the capability of each CASE product to satisfy the requirements must be measured. Several techniques may be used to gather enough information to determine how well each package meets the requirements.

In many cases, the project team can meet directly with the vendor sales and support personnel and discuss each requirement. But if CASE requirements are so comprehensive and detailed that a more formal procedure should be followed, a request for proposal (RFP) can be submitted to vendors. It should be noted that preparing an RFP can be time-consuming and costly. In situations where the requirements are not so detailed and complex, it can be

270 Information and Software Technology 1994 Volume 36 Number 5


T a b l e 3 . D e t a i l e d f u n c t i o n a l c r i t e r i a f o r C A S E s o f t w a r e

• Full S D L C s u p p o r t - - Planning, analysis, and design features -- Lower case features--code generation

• Fully integrated - - Do all tools operate together as one integrated package? -- Ability to work with other vendors' non-integrated products if

not fully integrated

• C o n u n o n r e p o s i t o r y - - Data - - Documentation -- All objects produced in the SDLC process

• S t a n d a r d / c o m m o n u s e r i n t e r f a c e -- Is the look and feel the same from one phase to another? -- If not fully integrated, is look and feel the same?

• H a r d w a r e / s o f t w a r e p o r t a b i l i t y - - Multiple hardware platforms - - M u l t i p l e software platforms

• N e t w o r k s u p p o r t -- Types of LAN support -- Specific multi-user capabilities -- Quick response time

replaced by a less formal and more direct procedure such as a basic letter of request.

Evaluate specific CASE products

Once the vendors' responses to requirements have been received, the actual CASE software evaluation process can commence. The review is very detailed at this point, because the project team is looking for specific strengths and weaknesses of each CASE package. The project team is searching for deciding factors--not only what the CASE software packages have and how well they provide it, but also what they don't have. Detailed information is desired on the functions of the CASE software and its related processing, including if and how functions that are not included could be implemented. Once the necessary product information is obtained about the evaluation criteria for the CASE tools, then a choice model is used to rank the short list of CASE software alternatives.

Shoval and Lugasi N compared three models for evaluating and selecting a computer system from four alternatives in an actual case study. The three choice models were: (1) the additive weight model; (2) the eigen- vector model; and (3) the multi-attribute utility model. The authors reported that these models provided identical rankings of combinations of computer hardware, software availability and system support.

Given a short list of CASE software alternatives, any scoring model will likely yield identical rankings. Generating the short list is more critical than the method of ranking the software packages. Criticism levied against weighting schemes for software selection decisions can be minimized, if not eliminated altogether, through the screening process and development of a short list t2. For example, Naumann and Palvia 13 successfully applied weighting and scoring measures to select a systems d e v e l o p m e n t tool from a relatively short list (four) of candidate techniques.

By weighting criteria for only two or three packages rather than for a dozen (in which case the aforementioned

criticism is probably valid), the proposed evaluation process allows for a very detailed and focused inspection of just the few best alternative CASE software products. The screening process does not require a great deal of information about each CASE tool. However, much information is required about every CASE tool for the detailed analysis to be conducted in the second phase of this evaluation process. It takes much time and effort to gather this detailed information, which increases the cost of the selection process and delays the implementation of CASE technology. Also, evaluating more than three CASE products in the second phase of this approach can be very confusing, given the abundance of detailed information required, and cause much unnecessary effort.

Additional selection requirements

The ranking scores generated by a choice model are not necessarily the determining factor for selecting a particular CASE product. They should be used as a decision tool--a means for organizing and summarizing the significant quantity of information that the project team has collected. The highest score may not always indicate the best CASE product. The scores may not accurately reflect certain intangible factors, such as the cosmetic appearance of screens, or how easy it will be to use the CASE software.

Tailoring. The scores may not indicate how much time or what level of technical expertise is needed to implement the CASE tool. Tailoring can be either costly, if it is relatively extensive, or difficult if the internal structure of the CASE software is complex. The importance of the technical architecture will depend on how much tailoring is anticipated. Furthermore, the architecture of the CASE software also determines how much modification is even possible.

Tailoring is vital because many CASE products are so complete that determining which components of the CASE software to implement becomes a major question. For example, a small project may not require much formality and rigour when compared to a larger and multifaceted project. CASE vendors may term this 'tailoring' as road maps, customized system development life-cycles, or flexibility. In most instances, it is the tailoring of the CASE software to the corporate system development methodology that is necessary.

Documentation A decision to use a particular CASE tool should not be made on the basis of functional requirements alone. The CASE software's documentation is a very important non-functional factor. Its accuracy and level of detail can affect the time it will take to evaluate and implement the CASE tool.

Comparing documentation is sometimes very diffcult at this phase of the CASE tool evaluation process because of differences in format, style, etc. Nevertheless, it is important to review the vendors' documentation and to confirm that the information collected on maintenance and support, for instance, is accurate and correct.

In this phase, the vendor should be able to refer the project team to current users of its CASE software. The



comments of these customers should prove invaluable. Site visits and demonstrations of the CASE tool in operation may be helpful.

CASE software confirmation

Assuming that the CASE software, which is expected to provide satisfactory performance, has been selected, the project team is ready to confirm the selection of the CASE tool by developing some specific applications based on the chosen product. The primary reasons for this phase are to ensure that the CASE software can be used effectively and to provide one last chance to reconsider the CASE decision.

It is often difficult to determine the degree of user satisfaction until the actual development of specific applications utilizing the selected CASE software. Therefore, this phase involves the development of demonstration applications or portions of systems built from the CASE tool. Such prototype applications can provide significant benefits before finalizing the selection decision ~4"j5.

Alter functional requirements

Based on the capabilities of the selected CASE tool as experienced in the aforementioned application development exercise, the definition of CASE user requirements might be altered to include tool features not previously considered, or to change or eliminate others. The modified requirements should be reviewed with the firm's system builders. The effect of CASE software deficiencies can perhaps be minimized by altering system development procedures.

CASE software modifications and supporting programs

Typically, the specific applications being developed require certain functions and/or interfaces not provided by the CASE software. If a CASE tool does not meet all the functional requirements of a system development methodology, the following alternatives should be considered: (a) persuade the vendor to include additional CASE features; (b) develop supplemental CASE software; and (c) modify the vendor's software. The chosen alternative will depend on the extent of the CASE software's deficiencies, the potential costs and benefits of altering the CASE software, and the size and technical skills of the programming staff.

Vendor-supplied enhancements. If possible, the vendor should be persuaded to do the modification for the purchaser. This is often the best alternative, as the vendor will usually update and maintain the CASE software on a routine basis.

Supporting programs. Developing software to supplement the vendor's CASE package is often the most practical alternative. The vendor will normally continue to service the CASE tool; but if this alternative is selected, the supplemental CASE software should conform to the standards used by the vendor in developing the CASE tool.

Alter code. Modifying CASE software is usually not recommended. If the software is modified, the vendor may

be reluctant or may even refuse to service the package. Updates to the CASE software may not be compatible with the modifications effected. In some cases, this may not even be an option, since the purchaser of the CASE software does not have (or cannot get at any price) a copy of the source code. In this instance, all that the purchaser can do is to build a front-end or back-end to the CASE software package.

Finalize CASE software selection

It is not unheard of for an organization to complete the last phase of the evaluation and selection process for CASE software only to realize that the selected tool is not the best choice. Perhaps too many compromises have been made and users are no longer satisfied. Therefore, a final commitment to using a particular CASE tool should be avoided until the design of specific applications using the potential CASE software package has progressed to the point where satisfaction is ensured.

Summary and conclusion

Using CASE tools for application development can reduce personnel requirements and system development costs. Despite the promises offered by CASE software, the performance of some CASE tools is much less than expected. Weak or non-existent selection procedures for CASE software may explain much of this poor record. The approach proposed in this paper will hopefully reduce the risks associated with CASE software and facilitate success in developing specific applications with CASE tools.

The most critical phases of the approach are the first (the development of a short list) and the third (confirmation of the match between user requirements and the capabilities of the chosen CASE tool through the development of specific applications with the selected CASE software). Initially, the screening process reduces the number of CASE software packages to be evaluated in detail. Finally, the development of specific applications with the selected CASE tool ensures that the CASE software can be used effectively.

To verify the use of CASE technology and its corres- pondence to specific system development methodologies by actual business firms, approximately 30 MIS directors and project managers from companies in Minnesota and Wisconsin were personally interviewed for this paper. Firms in the sample included large banks, insurance companies, manufacturers, trucking and distribution enterprises, as well as several relatively small retail operations. The procedures outlined in this paper for selecting CASE software represent a composite of the best practices in this regard exhibited by the aforementioned sample firms as well as original contributions by the authors.

Every firm is different because of the variance in existing hardware and system software platforms. As a result, a standard or 'cookbook' approach for selecting CASE software and applicable to all firms is very diffcult to specify in much detail. For example, the development of a short list of CASE tools for an AS/400 platform would be

2"12 Information and Software Technology 1994 Volume 36 Number 5

The evaluation and selection of CASE tools: L AL e Blanc and W M Korn

quite different from that of an IBM 3090 platform. The purpose of this paper is to provide a general approach for CASE software selection and not specifics for each possible situation.

As stated in the first section, while previous publications provide partial guidelines for CASE software evaluation and selection, no unified and comprehensive approach (as presented herein) has been suggested. It is the authors' belief that this approach is quite easy-to-use and will effciently and effectively guide a project team in choosing a CASE tool that meets application development requirements and which will rapidly create high quality production systems at minimum cost.

References

1 Mach, R 'Information engineers wanted to build enterprise models' Software Magazine, Vol 10 No 11 (September 1990)

2 Sharon, D 'Look beyond the 'I-Case' Label' ComputerworM (22 April 1991) pp 61-64

3 Lynch, R K 'Implementing packaged application software: hidden

costs and new challenges' Systems, Objectives, Solutions Vol 4 (1984) pp 227-234

4 Lynch, R K 'Nine pitfalls in implementing packaged application Software' J. Information Systems Management Vol 2 (1985) pp 88-92

5 Meador, G L and Mezger, R A 'Selecting an end user programming language for DSS development' MIS Quarterly Vol 8 (1984) top 29--44

6 Breslin, J Selecting and installing software packages Quorum Books, Westport, Connecticut (1986)

7 Curry, J W and Bonner, D M How to find and buy good software: a guide for business and professional people Prentice-Hall (1983)

8 Martin, J alKI McClure, C 'Buying software off the rack' Harvard Business Review Vol 61 (November-December 1983) pp 32-47

9 'Product spotlight' Computerworld (22 April 1991) pp 61---64,68,72 10 'Analysis/design/code-generation tools' Computerworld (22 April

1991) pp 76-77 11 Shoval, P and Lugasi, Y 'Models for computer system evaluation and

selection' Information & Management Vol 12 (1987) pp 117-129 12 Klein, G and Beck, P O 'A decision aid for selecting among infor-

mation system alternatives', MIS Quarterly Vol 11 (1987) pp 177-185 13 Naumann, J D and Palvia, S 'A selection model for systems

development tools' MIS Quarterly Vol 6 (1982) pp 39-48 14 Alavi, M 'An assessment of the prototyping approach to information

systems development' Communications of the ACM Vol 27 (1984) pp 556-563

15 Janson, M 'Applying a pilot system and prototyping approach to systems development and implementation' Information & Management Vol 10 (1986) pp 209-216


a phased approach to the evaluation and selection of case tools

Documents