Download applications of computer-aide d software engineering tools and more Slides Software Engineering in PDF only on Docsity!
APPLICATIONS OF COMPUTER-AIDE D
SOFTWARE ENGINEERING TOOLS :
SURVEY OF CURRENT AN D
PROSPECTIVE USER S
DONALD L. BURKHARD, PH .D ., UNIVERSITY OF VIRGINIA
PER V. JENSTER, PH .D ., IMEDE, SWITZERLAND
Computer-Aided Software Engineering (CASE) tools (^) burdened by many manual tasks. Given th e are a relatively new technology that promises to have a (^) unpredictability of task efforts, it is not uncommon to hea r significant impact on the way systems professionals (^) of organizations having as much as a two-to-five year develop and maintain information systems. This article (^) backlog of systems development projects [11]. In on e reports on a study of the experience and expectations of (^) study, the backlog was extimated to be 374% over existin g current and prospective users of CASE tools. After an (^) capacity to develop systems, and this did not include th e introductory discussion of CASE tools and their uses in an " (^) invisible" backlog [1]. In addition, only a small percen t organizational context, the article presents the findings of (^) of projects are completed on time, within budget, an d a recent study of 46 organizations. The research focused (^) according to specifications [15]. Data on the issue o f on three major areas : expectations of CASE technology, (^) successful project completion are questionable given tha t reasons for acquiring CASE, and implementation issues. (^) most project requirements are often redefined on an ongoing In conclusion, areas in need of further exploration are (^) basis with schedules altered accordingly. In addition , identified. (^) definitions of success differ. For example, some projects may be considered successful if overruns do not exceed 30 % or if the user only junks a quarter of the result [9]. Most organizations have addressed these shortfall s largely as productivity problems - How can we speed u p software development while maintaining or increasing th e quality of the final system? Productivity can be viewed a s having two competing dimensions : quantity and quality [4]. Curve A in Figure 1 depicts this trade-off. A certai n level of productivity may be achieved with a wide range o f quality and quantity combinations. If higher quality i s desired while maintaining the same level of productivity , then the quantity must suffer. Ideally, organizations woul d like to be able to shift the curve so that gains in on e dimension are not offset by losses in the other. Some previous efforts to shift the curve outwar d appear not to have been very successful. For example , efforts to increase the quality of systems led to the use of systems development methodologies (SDMs). Albert Cas e concludes that development techniques improve syste m quality but not necessarily the efficiency of the developer s [4]. Theoretically, the result was a change in th e productivity curve shape (Curve B), rather than a shiftin g of the curve. Consequently, after the introduction of a n SDM, some organizations discontinued rigid enforcemen t of the methodology's procedures, essentially reducing the m to "shelfware. " Conceptually, the various tools or components o f CASE technology are designed to shift the productivity curve as shown in Figure 1 (Curve C). One compan y reports that systems are being generated so fast that th e end-users are not able to adjust or adapt to the system s before even more new systems are provided [13]. Althoug h this is only one anecdote in which CASE has affected th e quantity side of the productivity issue, it is hoped tha t CASE address both the quantity and quality issues i n systems development.
INTRODUCTIO N
Computer-aided Software Engineering (CASE) tool s are a relatively new technology that promises to have a significant impact on the way systems professional s develop and maintain information systems withi n organizations. However, only a small number (2%) of potential users are using CASE currently [15]. How organizations take advantage of this emerging technology , and the degree of their success in doing so, is not widel y known. This article reports on a study of current an d potential users of CASE that identifies important issues i n this emerging field. The study focused on three majo r questions : user expectations of CASE technology, reasons for acquiring CASE, and issues relating to th e implementation of CASE. After an introductor y discussion of CASE tools and their uses in a n organizational context, this paper presents the findings o f the study and identifies areas in need of further inquiry.
COMPUTER-AIDED SOFTWAR E
ENGINEERIN G
The term "Computer-aided Software Engineering, " or CAS E 1 , has been used for several years to denote a wid e assortment of automated tools developed to help system s analysts and programmers do their work. In the past, a systems developer's job was labor intensive and wa s
1 The term CASE was coined by John Manley, directo r of the Software Engineering Institute at Carnegie-Mellon University.
28 DATA BASE Fa
support has been available for many years in CA D (computer-aided design) form. However, most CAS E products integrate the graphics with other tool capabilities.
PROJECT MANAGEMENT
Diagramming
Methodolog y
Suppor t
C
Z
SDM SHIF T
PRODUCTIVIT Y LEVEL
Figure 2. CASE Environment
QUALITY
Figure 1. Effects on Productivit y
ANATOMY OF CAS E
Many specific, automated tools have been available and used independently over the years to improv e development productivity (e .g ., by editors, compilers, an d debuggers). Thus, a broad definition of CASE technolog y includes all automated support for producing software [16]. A more specific portrayal of CASE technolog y identifies several kinds of tools that can be integrated to form a tool kit and/or an analyst workstation. The key , and most recent focus, is on the notion of integration , suggesting that the tools must be able to work together t o provide a total support environment. The various tool s include diagramming tools, syntax verifiers, an informatio n repository, prototyping tools, and code generators [12]. Some proponents of CASE take a broad perspective an d include project management tools in the CASE tool ki t [6], and others advocate that CASE must support a development methodology [5,14]. Figure 2 depicts th e various components that make up the CASE tool kit.
Diagramming Tools The adage, "A picture is worth a thousand words" describes the use of graphics or diagrams in systems analysis an d design [8]. For example, data flow diagrams show th e processes and the flow of data among the processes in a system. Analysts and users easily understand the diagram s and can validate the correctness of the data flow diagram. One study showed that the communication between user s and the analyst was improved through the use of data flo w diagrams [3]. Drawing data flow diagrams for years was an intensive, manual process. Changes in the system required extensive work to redraw the diagram. Diagramming tool s provide automated support for drawing data flow diagrams , structure charts, and other graphics typically used i n structured approaches to software design Diagramming
The structured approaches on which diagrammin g techniques are based have specific rules supporting th e technique or approach. Data flow diagrams require that a process have both inputs and outputs. Structure charts heuristically allow a module to have up to seven sub - modules. Most products provide a limited capability to verify proper use of the techniques. These capabilities often are referred to as error checkers, validators, syntax verifiers, or design analyzers, and performing such tasks a s consistency checks, level balancing of data flow diagrams , and other error checking procedures.
Information Repository The key to the CASE environment is the informatio n repository, or central repository. The repository is simila r to data dictionary products in that it stores data definition s and relations, but the repository is more inclusive in that i t also stores graphics (or diagram information) and othe r information related to the system being designed. I t becomes the link between the graphics, data definitions , screen and report definitions, and code generatio n capabilities.
Prototyping tools The term "prototyping" as it is used in relation to CASE generally refers to "screen" and "report painters" tha t allow one to quickly create and modify screen and repor t formats. These screen oriented layout tools provide th e capability to edit and move portions of the screen/repor t design. In addition, they use data definitions stored in th e central repository to specify the input/output fields. Prototyping tools are used to establish system interfac e specifications with the user prior to actual developmen t (programming) of the system.
Code Generators Code generators allow the analyst to generate modularized code from specifications given in a high-level language. Code generators have been available a s independent tools for many years. As part of the CAS E
DATA BASE Fall 1989 29
These new features represent a greater depth of support -- i n essence, the inclusion of " expertise. " CASE must include not only automated support for the various activitie s performed by systems professionals, but must also provid e intelligence to help guide and analyze the developmen t effort. Many CASE products provide a limited amount o f validation support for such functions as checkin g consistency and level balancing. CASE tools of the futur e will incorporate artificial intelligence that not onl y validates specifications but that also evaluates the qualit y of a system design and suggests improvements.
HARDWARE ENVIRONMENTS AN D
COST OF CAS E
The hardware environment, or platform, in whic h CASE tools are used may consist of microcomputers , workstations, minicomputers, or mainframes. In som e cases, the environment might extend across variou s platforms. Some CASE products are composed of severa l components that would reside on different platforms. Fo r example, most of the diagramming tools ar c microcomputer-based (or workstation-based), while mos t code generators are mainframe-based. CASE products vary in cost. Some of the products ar e simple tools and may cost less than $1,000. Many othe r products run between $1,000 and $10,000, and some run as much as $500,000. Generally, the more expensiv e products are mainframe-based. The less expensive product s might be separate components of a tool kit that i s microcomputer-based.
EMPIRICAL STUDY OF CURRENT AN D
PROSPECTIVE CASE USERS
Discussion to this point has been on CASE as (^) a technology. The following presents the results of a stud y of CASE users and issues relevant to CAS E implementation within an organization.
Methodolog y The methodology applied in this study should b e viewed in light of the exploratory nature of empirica l CASE research. Rather than validating existing theoretica l constructs, this inquiry was aimed at highlightin g questions for further study. This study focused on thre e major areas : user expectations of CASE technology , reasons for acquiring CASE, and issues surrounding th e implementation of CASE in the organization. Initially, several MIS directors/executives wer e interviewed to identify relevant issues. These interview s revealed several items that were then grouped into th e major areas of interest. Based on the identified issues an d the authors' experiences, a structured questionnaire wa s developed and reviewed for clarity by colleagues. Th e questionnaire was subsequently distributed to MIS
executives and project directors during a symposium o n CASE technology 3. A total of 46 completed responses were returned. Th e sample may to some extend have biased the results, a s these attendees obviously have a high degree of interest i n the application of CASE technology within their respectiv e firms. However, it is also likely that the executives had a particular knowledge, interest, and sensitivity to the issue s related to CASE implementation. The respondents/executives represented a broad range o f industries, as indicated in Exhibit 1.
Exhibit 1 : Industries Represented in the Sampl e Number o f Industry Respondents Government 1 3 Communications 6 Software Development 6 Manufacturing 7 Banking, Finance, Insurance^4 Other (^7) Not specified 3 Total 4 6
The size of the respondents' organizations ranged from less than five million dollars in sales (or budget) to in excess of five billion dollars -- the range of organizationa l size is given in Exhibit 2. The responding executives also represente d information systems departments of varying size, rangin g from less than 10 employees to over 3000. There was a fairly even distribution of department sizes which parallele d the size of the organization.
Exhibit 2 : Sales Volume of Firms Represented in Stud y 1986 Budget/Sales (^) Number o f in Dollars Respondent s < 5 Millions (^1) 50 Millions (^5) < (^100) Millions 2 < (^500) Millions 6 < (^1) Billions I < 5 Billions (^5)
5 Billions (^4) 2 4 Not specified (^). 22 50% of these indicated a Government (^) affiliation. Note : Classification (^) established for illustrative purposes.
Research Question s The focus of this research was to obtain descriptiv e data on the key issues related to CASE and it s implementation in organizations. The key researc h questions were :
- What are the expected uses of CASE?
- What are the reasons for acquiring CASE?
- Who initiated the interest in CASE and wha t commitments have been made to CASE?
- What are the key implementation issues?
3 The respondents participated in a symposium o n CASE sponsored by Digital Consulting, Inc.
DATA BASE Fall 1989 3 1
RESEARCH FINDING S
Of the 46 respondents, 26 already were using CAS E tools to some extent and 20 were considering acquirin g CASE tools. The following section summarizes th e survey results.
Expected Uses of CAS E We would expect differences between current an d prospective users in several areas. First, prospective users may have less realistic expectations of potential CAS E uses than their more experienced counterparts. That is , prospective users might expect to apply CASE through th e full development life cycle, when the tools have not ye t been fully developed to this extent. Responses related t o the expected uses of CASE technology were solicited i n two ways : through a check list of specific system s development life cycle (SDLC) phases and through a serie s of open-ended responses. With respect to the specific SDLC phases, th e respondents were asked to check the phases for which the y wanted (or were using) CASE support. A list of SDL C phases and associated activities was used (adapted fro m [17]). The phases included requirements analysis, logica l design, physical design, systems implementation, an d systems operation/maintenance. The responses, in Exhibi t 3, reveal two interesting points. First, there is a n overwhelming interest in supporting the early phases of th e SDLC. Over 85% of both current users and expected user s require support for requirement analysis and logical an d physical design, whereas 30-65% require support in th e later phases of the life cycle. Secondly, there were n o significant differences in required support between curren t and expected users.
Exhibit 3 CASE Use in the Systems Development Life Cycl e
To gain further insight into the uses of CASE, th e responses were categorized as either frontend support , backend support, full life cycle support (which include s both frontend and backend support), or split support4. As shown in Exhibit 4, 41% indicated a desire to use CAS E across the entire life cycle, whereas 43% indicated only th e frontend phases. Just 4% indicated an interest in onl y backend tools. It was interesting to find that 11% ha d indicated a desire for split support. Thus, these users ma y not be able to gain the full advantage of CASE technology.
4Split support represents those cases where early an d later phases were indicated, but imtermediate phases wer e not.
32 DATA BASE Fal
Responses to separate open-ended questions indicated a large interest in data flow diagramming (19), cod e generation (13), defining program specifications (11), an d data modeling (10). Ten respondents (10) indicated a nee d for support of the full life cycle, while documentation wa s mentioned seven (7) times. Various other activities, suc h as project management, structure charts, prototyping, an d dictionary creation, were reported by 1 to 4 respondent s each.
In summary, we did not find many content difference s between current and prospective users of CASE. Thi s suggests that the expected uses of CASE by both curren t and prospective users is fairly aligned with the presen t capabilities of CASE technology.
Reasons for Acquiring CAS E The respondents were asked to rank order the reason s for considering CASE tools. Specific reasons included 1 ) cost savings, 2) speed and timeliness of development, 3 ) improved accuracy and quality, 4) keeping up wit h technology, 5) project coordination, 6) consistency an d structuring of the development process, and 7) other. Itemized responses to "other" included reduced maintenance , traceability, methodology implementation, productivity , project estimation, artificial intelligence or Al, an d competitive advantage. Individual rankings were given values of 1 to 7, wher e 7 was assigned to the most important, 6 to the next mos t important, etc. Many of the respondents ranked only thei r top three or four specific items ; i .e ., they did not rank al l items. Values for non-ranked items were treated as missin g values in the data analysis. The results indicated that speed of development an d improved accuracy and quality were ranked as the mos t important items for the group as a whole. As shown i n Exhibit 5A, these two items were virtually identical wit h respect to the mean, the sum (the item rank summed acros s responses), and the number of first place votes for th e item. 5^ The calculated value of Kendall's coefficient o f concordance, (W), (which measures the level of agreemen t in the rankings) was 0 .4699, suggesting that the group as a whole was in reasonable agreement. The rankings were also determined for both the Curren t and Prospective users of CASE. As shown in Exhibit 5B , the order of importance of the two items, speed an d accuracy, were reversed in the two samples. Prospectiv e users ranked speed of development as the most importan t
5 The number of first place votes do not add up to th e sample size because several respondents gave equal weigh t to the items.
Have Tool s NO YE S --------------------------------------------------- -Totals^20 2 6 Requirements analysis 17 (85%) 22 (85% ) Logical Design 19 (95) 23 (89 ) Physical Design 18 (90) 22 (85 ) Program Design 13 (65) 15 (58 ) Systems Implementation^11 (55) 8 (30 ) Systems Operation/Maintenance 11 (55) 11 (42) Percentages refect group responses. Chi-Sq = 0 .68^ Not Significant
CASE Use in the Systems DevelopmentExhibit^4 Life Cycl e
Have Full Front^ Back^ Spli t tools----------------------------------------------- - LC End End^ suppor t NO 10 (22%)^ 7 (15%)^ 1 (2%)^ 2 (4% )
- YES 9 - (20) (^) ______________________________ _13 (28)^ 1 (2)^ 3 (6 ) TOTALS 19 (41)^ 20 (43)^ 2 (4)^ 5 (11 )
Finally, the rankings were categorized by size o f DP/MIS department. Shops that had less than 100 people were categorized as "small" ; shops with 101 to 500 were categorized as "medium" ; and all shops with more than 50 1 were " large. " The results are shown in Exhibit 5D. Three points of interest are that speed or development an d improved accuracy, again, are ranked as the mos t important items. Second, cost savings, did not appear t o be important for small shops. Third, both small and larg e shops were relatively consistent in their agreement, with W = 0 .53 and W = 0 .65 respectively. In addition to analyzing the rankings of the reasons fo r implementing CASE, statistical tests were used t o determine if there were significant differences among th e groups when partitioned by current versus prospectiv e users, by users or non-users of structured methodologies , and by the size in persons of the DP/MIS department. As shown in Exhibit 6, only two cases showed significan t differences : speed of development for current versus prospective users of CASE and keeping up wit h technology for the size of departments. Organizational Commitment to CAS E The interest in CASE tools comes primarily from th e MIS department. MIS executives initiated interest in 23 o f the cases, with an analyst initiating 18 cases. It i s interesting to find that in some cases (3), top managemen t initiated the interest. A commitment to CASE had been made by 1 2 organizations with a wide range of resources. The amoun t of resources committed ranged from $5000 to "millions.^ " For those indicating the amount of resources committed, a substantial commitment had been made ($100,000 o r
more).
Exhibit 6 : Differences Among Groups of Ranked Reasons^ for Using CAS E
Variable
CASE USER 4 K-S Z
METNODOLOGYN SIZE DEPTH I P K-S Z P CSI-SQ^ P Cost savings 1 .155^ 0 .139^ 1 .213^ 0 .105^ 3 .345^ 0 .187 7 Speed 1 .315^ 0 .063 k^ 0 .897^ 0 .397^2 .079^ 0 .353 6 Accuracy 0 .809 0 .529^ 0 .585^ 0 .883^4 .2256^ 0 .120 9 Keeping up 0 .707^ 0 .699^ 0 .745^ 0 .653^ 4 .8411^ 0 .0889 k Prj coord 0 .517^ 0 .952^ 0 .698^ 0 .715^ 0 .7939^ 0 .672 4 Consistency 0 .362^ 0 .999^ 0 .266^ 1 .000^ 0 .3718^ 0 .830 3 Other 0 .289^ 1 .000^ 0 .365^ 0 .999^ 0 .1579^ 0.
- Significant at the p = 0 .1^ leve l for two-tailed tes t KOLMOGOROV-SMIRNOV 2 SAMPLE TEST KRUSKAL-WALLIS 1-WAY ANOVA
Implementation Issue s Some of the primary implementation issues concerned the number of expected CASE users, the ratio of users t o workstations, identification of the expected users, type o f hardware, and whether a structured methodology is currently used. Our study revealed that the number of expected users varied from less than 10 to more than 1000. Figure 4 shows the distribution of responses categorized by th e number of users. Those indicating very large numbers o f users (500 or more) were already using CASE. As on e might expect, the number of users were highly related to organizational size. A second question involved the expected ratio of users to workstations. In the sample, 20 responses indicated a
34 DATA BASE Fa
1 :1 ratio, and 10 indicated 2 :1. The rest of the responses were 3 to 5 users per workstation, with one response of a 10 :1 ratio.
Number of User s
Figure 4. Total number of Users using CAS E
Inquiries regarding the job titles associated with CAS E use revealed that the expected users include analysts (al l respondents) and data administrators and programmer s (65%). Some indicated that end-users (11%) and projec t management (11%) would use CASE. Most of the responses indicated an interest in a microcomputer-based CASE product (50%) or a workstation product (20%). Only thirteen percent (13% ) indicated an interest in mainframe tools, although eleve n percent indicated a need for a mainframe-microcompute r linked tool. The respondents also were asked if a structure d methodology was currently being used in thei r organization. The results are shown in Exhibit 7 , categorized by current users versus non-users of CASE. This strongly suggests that the use of CASE technolog y requires the use of a structured methodology. Therefore , one might argue that organizations that are implementin g CASE and are not using a structured methodology, shoul d also adopt a methodology. The implication is tha t problems associated with implementing CASE technolog y can be compounded when concurrently adopting (^) a methodology. Further supporting evidence of thes e potential problems follows.
Exhibit 7 Use of^ Structured Methodolog y by Current and Expected User s
Current Use (^) Structured Methodology user NO-_ (^) _________ _YE S NO 14 (30%) 3 (5% ) YES 2 (4) 24 (52 ) Chi-Sqr = 15 .72 For p < 0.
In an open ended question, respondents were asked to indicate the major difficulties they foresee in implementin g CASE technology. The most often mentioned reasons are
t k k
shown in Exhibit 8. Adopting or changing^ a methodology was the second most mentioned proble m with resistance to change indicated most frequently. Al l of the issues mentioned, with the exception o f integration with existing systems, exemplify peopl e
related issues.
DISCUSSIO N
This study set out to explore the issues related to th e implementation of CASE technology. The findings focu s on three major thrusts : expectations of CASE technology , reasons for acquiring CASE, and implementation issues. Respondents expressed several types of expectations o f CASE technology, some of which are unrealistic given th e current state of the technology. One expectation was fo r coverage of all phases of the SDLC. This is not a n unmerited expectation. However, with current technology , it is unlikely that a single CASE product will provide th e desired level of coverage for all phases of the life cycle. For example, Excelerator can be used to create a variety o f diagrams, define a data dictionary, and generate dat a discription code. We know of many organizations tha t have acquired both a frontend and a backend CASE produc t and have then created their own interface between th e products. Vendors of CASE products also have made som e progress in creating interfaces between various tools and in creating products that eventually will offer full life-cycl e support. For example, Knowledgeware's Informatio n Engineering Workbench and Gamma COBOL Generato r have been linked together to provide life cycle coverage. Aside from the technical problems of integratin g various products, linking products together results i n varying user interfaces, which has significant implication s for training. Differing tool interfaces (e .g ., menu systems , drawing protocols, dictionary or central repositor y definition standards) would require the user of CASE t o learn two or more products. In addition, if the tool set i s not a fully integrated CASE product, it is unlikely tha t project management tools will be directly tied into th e CASE environment. Another interesting discovery is that many respondents wanted split life-cycle support ; i .e., analysis and desig n activities on the frontend and maintenance support on the backend, but not program coding activities. Such a n application represents a disjunction between activities tha t should be linked if the user is to take full advantage of th e technology. Ideally, the CASE environment shoul d provide support for all phases of the life cycle. However, the expectation that CASE provide full y integrated support for the entire SDLC is too high given
the current state of the technology. In addition, we feel that the respondents either totally neglected or underrate d another facet of CASE : the integration of new system s with current systems. Even though current technology i s weak in this connection, this capability is very important. Recall that a large portion of systems "development" effor t is spent on maintaining current systems. Without tool s that will re-engineer and integrate current systems with ne w systems, the full potential of CASE technology will no t be achieved. It was surprising, therefore, to see tha t relatively few respondents indicated an interest in thi s capability. The second category of findings involved the reasons for or the benefits of acquiring CASE. In all cases, spee d of development and improved accuracy were ranked as the two most important issues. When examining th e differences between prospective and current users, the orde r of importance switched from speed to accuracy respectively. There are two approaches to interpreting this change. Th e first involves a rather passive interpretation that the shif t does not represent any real difference. In one case, speed o f developement, productivity gains are achieved by increase s along the quantity axis (recall Figure 1). Whereas , improved accuracy represents increases on the quality axis. Both represent improvements in the productivity curve. A s a result, this shift may occur simply because th e technology has been used for some time. It is not unusua l that with experience, users tend to forget or no longer see the problems that they originally had [7]. A more aggressive interpretation assumes that there ar e actual differences. In this case, we offer as a possibl e explanation that prospective users, under pressure t o complete large backlogs of projects, view CASE primaril y as a way to speed up the process. Then as CASE is used , one finds that the benefits of improved accuracy over the entire course of systems development, is more beneficia l than the increased speed of development. Unfortunately , although the explanation is feasible, with the particula r metrics used in this study this claim cannot b e substantiated. Speed and timeliness of development alto present s a quandary by itself. As discussed earlier, the introductio n of automated technology actually loads the frontend of the life cycle. In many cases, not only are more resource s required in the earlier phases, but the amount of time spen t in the early phases also increases. For the manager wh o anxiously awaits the benefits of recently implemente d technology, early indications may suggest that CAS E actually has a detrimental effect on systems development. It is essential that a broader perspective of evaluation b e adopted. However, some organizations have experience d immediate gains in overall productivity through CAS E applications. In one example, a system was estimated to take 9 people 3 months to complete at a cost of $268,00 0 if previous development methods were used. Using CAS E the system was developed and completed by 2 people in 2 months at a cost of $30,000 [16]. One organization even reports that new systems are being built so fast that th e end-users cannot adapt quickly enough to the new systems , in effect actually shifting the bottleneck to the end-use r [13].
Exhibit (^8) Implementation Problems Number o f Respondent s Mentionin g Resistance to change 1 3 Adopting or changing a methodology (^) 1 2 Training users 8 Acquiring/justifying resources 7 Integration with existing (^) systems 7 Gaining management support (^3)
Issue
DATA BASE Fall 1989 35
Journal of SCS, Vol. 1, No. 4, December 1987, pp. 51-5 5
[8] DeMarco, T. Structured Analysis and System s Specification, Yourdan, Inc ., NY, 1979
[9] (^) DeMarco, T. Controlling Software Projects , Yourdan Press, NY, 198 2
[10] Guimaraes, T. "Managing Application Progra m Maintenance Expenditures " (^) Communications of th e ACM, Volume 26, Number 10, October 1983, pp. 739-
[11] Hall, R. "Seven Ways to Cut Software Maintenanc e Costs," Datatmation, Vol. 33, No. 14, July 15 , 1987, pp. 81-8 4
[12] Huling, J ., "Tools of the trade : Is CASE really a cure-all?" (^) Computer World, Vol. 21. No. 16, Apri l 20, 1987, pp. 73-8 6
[13] Hurst, R ., " CASE systems near fruition, " ComputerWorld Focus, (^) July 8, 1987, pp. 27-2 9
[14] Martin, J. The James Martin Productivity Series :
Computer-Aided Software Engineering, 198 7
[15] McClure, C. " Computer-Aided Software Engineering," in (^) Computer-Aided Software
Engineering, (^) Digital Consulting, Andover, MA , Spring 198 7
[16] Stamps, D. "CASE : Cranking Out Productivity, " Datamation, July 1, 1987, Vol. 33, No. 13, pp. 55-5 8
[17] Sprague, R .H. and McNurlin, B .C. Eds. Information Systems Management in Practice , Prentice-Hall, Englewood Cliffs, New Jersey, 1986
[18] SPSSIPC+, (^) SPSS Inc ., Chicago, Ill ., 198 6
DONALD L. BURKHARD, PH .D.
McINTIRE SCHOOL OF COMMERC E UNIVERSITY OF (^) VIRGINI A CHARLOTTESVILLE, (^) VA 2290 3 (804) 924-325 7
PER V. JENSTER, (^) PH .D. IMED E LAUSANN E SWITZERLAN D
Acknowledgement
The financial support provided by the McIntire Associates program, McIntire School of Commerce , University of Virginia is gratefully acknowledged.
Calling All Reviewers!
Computing Reviews, ACM's monthly review journal, is on the lookou t for people willing to volunteer reviews in their areas of expertise. This prestigious journal, with a circulation of over 6500, has included con- tributions by many of the best-known names in the field of computing.
CR reviews books and papers from a wide variety of sources. Reviewers have a unique opportunity to further the development of computer sci- ence and a chance to share their opinions and analysis of recently pub- lished material.
For a reviewer application, write Computing Reviews-CR Brochure 11 West 42nd Stree t New York, NY 1003 6 Please mention this newsletter.
DATA BASE Fall 1989 37
