The Case for CASE |-------------------------------------| | Paper presented at CAUSE92 | | December 1-4, 1992, Dallas, Texas | |-------------------------------------| ---The Case for CASE--- Joni Weber John Rome John Wasileski Arizona State University Tempe, Arizona ABSTRACT Faced with the dilemma of aging systems and declining budgets, Arizona State University has begun exploring CASE technology to assist in solving the problems of maintaining old systems while developing new ones. The facts we have discovered about CASE tools and the cultural adjustments required are presented within the context of five pilot projects we have completed using CASE. ---The Case for CASE--- INTRODUCTION The Administrative Information Technology (AIT or IT) office of Arizona State University (ASU) is caught on the horns of a complex dilemma. Budgets are shrinking and, as a unit with a large budget outside the immediate academic mission of the university, IT is likely to experience larger budget reductions than other areas. Add to this the fact that other offices with diminishing resources are expecting IT to provide technological relief from the service reductions they are facing. Thus, one horn of the dilemma is that we are being asked to do new things without reducing current services and without new resources. Another horn began to grow ten to fifteen years ago when our current legacy systems were installed. The design technology of the time did not anticipate the enormous maintenance burden we would inherit nor did it anticipate the ways in which "business changes" would stress the systems. For example, when the Student Information System was built, ASU was a single campus. It has now grown to two campuses with discussions about a third. Two years have been spent working out a way to implement a campus identifier. We are in a situation where keeping the current systems operating takes the lion's share of diminishing resources while we agonize over the fact that the systems do not meet the needs of the University anyway. A Management Perspective +++ There is no money and the budget reductions will continue for at least another two years +++ Demand for technological support for other areas with diminished resources will continue to grow. +++ Maintaining old systems takes too high a percentage of available IT time. +++ The systems being maintained do not meet the needs of the University but cannot be abandoned during replacement. +++ The code has been maintained heavily for so many years that it is becoming unmaintainable. +++ New systems take too long to build and packages require extensive modifications to meet business needs. +++ Data is very difficult to retrieve even for trained programmers at a time when clients are demanding easier access to more data . +++ Clients are pressing for a "distributed" computing environment which they hope will solve the problems. A steady diet of such stress breeds a climate of civilized antagonism. Customers begin to think that IT personnel simply do not know how to solve problems. IT people feel unappreciated for they work they do and frustrated by being unable to make real headway in providing solutions the clients will like. Managing in a climate like this is "challenging" to say the least but, there is hope that technology itself may provide some help. Like the "shoemaker's children", AIT folks have had little help from their own business. Recently, however, tools which can help automate the automation process have been maturing and can now support (1) the systems development process (CASE) and (2) reverse engineering which may make old systems easier to maintain through automated documentation and redesign. When contemplating the introduction of new tools, management is concerned by three major questions. Management's Major Questions About CASE +++ What will the new tools actually do? ++ How much would productivity increase? ++ How much faster would systems be developed? ++ How much better quality would new systems have? +++ What environmental changes will be required? ++ What kind of training would be needed? ++ Would new methodologies be required? ++ How does one provide a "data orientation"? ++ What new management principles might be required? +++ How much does it cost? The CASE Environment and Experience at ASU CASE tools have been finding their way into IT at ASU for several years but their presence had not been loudly announced. Computer Information Systems (CIS) had purchased an early version of IEF from Texas Instruments but had not employed it in any official projects. Later the KNOWLEDGEWARE ADW Toolset was purchased and CIS conducted a pilot project which delivered a working Cashiering System. Database Administration, frustrated over the difficulties encountered with each database modification, had arranged for the BACHMAN tools to be explored. The BACHMAN tools promise a path to gaining a better understanding of the current database structure as well re-engineering possibilities. A newly formed office, Data Administration, having almost no resources, purchased DEFT as a tool to help with enterprise modeling. All of these initiatives were made without an overall plan and this has caused some confusion about which is the most likely tool, whether more than one CASE tool can be accommodated in our environment, etc. It does show that there was a groundswell of perceived need for CASE or CASE-like tools within IT. Figure 1 gives a synopsis of how ASU has courted CASE. Figure 1 [FIGURE MISSING FROM TEXT FILE] In March of 1990, a feasibility study on the replacement of ASU's Cashiering system (which was based on IBM 4700 technology) was made. The study recommended the system be replaced with a DB2/CICS application and approval was given in September, 1990. It was also decided to use this as a pilot project for KNOWLEDGEWARE and so a 12-person project team consisting of 3 IT staff and 9 client staff members was formed. The team, using KNOWLEDGEWARE and the Information Engineering methodology, completed their work in time to implement the system in March, 1992. The system delivered is a 26-entity, 115-attribute model with 116 associated action diagrams and 100 data flows. There are 6 relational databases, 28 tables, 26 files, and 347 data structures in its physical implementation. System functions are provided through 35 on-line programs and 28 batch programs with 35 screens and 13 reports. The project expended 5,942 man-hours which is nearly 3 person-years. Although this project was successful, ADW was clearly weak in the construction phase of the project. There was much more time spent in coding than was originally projected. The "specifications" looked strangely similar to COBOL. At the time the ADW project was winding down, Texas Instruments, which advertises 100% code generation, announced the ability to generate to many client-server platforms. Since the overall direction of ASU is to "down-size" or "right-size" its applications, arrangements were made to conduct a proof of concept project. A five-day marathon session to test the IEF was conducted at the Texas Instruments headquarters in Dallas. TI employees worked with five ASU staff to create an Affiliate Information Management System. By the end of the fourth day, six relational tables and five on-line screens had been generated and tested in the mainframe environment. On the fifth day, GUI windows were painted, and without modifying any procedural specifications, the system was successfully re-generated for the OS/2 environment. Data Administration began a Data Dictionary project for student information in July of 1991. Both BACHMAN and DEFT were used as tools. The BACHMAN tool supplied a diagram of the current physical Student Information System. DEFT served as the basic modeling tool and as a communication device among the 20-person dictionary task force. The project expended 1,140 person hours and delivered a Student Information Dictionary of 1,000 elements (each with 21 metadata elements) in December, 1991. A second application of DEFT was made in the Summer of 1992 when Data Administration lead a 10-person project team in the design and construction of a Data Warehouse. This project delivered 110 relational tables (using Sybase) in an easily accessed (Data Prism and others) client/server (SUN 630 with 5+ gigabits of disk) environment. It also produced high quality E/R diagrams which are helpful in navigating the Warehouse and in training customers. The team took 116 days to design and implement the warehouse. This portion of the Warehouse contains ten years of student information. We plan to add Human Resource and Financial information by June, 1993 thereby providing ASU with an integrated management information source as well as access tools which can be used to build an Executive Information System. The Viasoft project was initiated to address maintenance issues. It was sponsored by IBM and Viasoft to train five IT staff members to use the tools by re-engineering two nearly unmaintainable programs. The first was a batch program which was very inefficient. When returned to production it saved significant CPU time. The second program was an on- line program and its re-engineering resulted in the extraction of the business rules which now saves ASU 75% in maintenance time. The entire CIS staff is now being trained in its use. What we Learned About the Tools and Their Use The first lesson we learned was the extent to which each tool supports the life cycle of an application. Figure 2 shows where we see the strength of each tool with respect to this. The ViaSoft products are included in this analysis because they are tools which can help address the current maintenance problems. Note that both KNOWLEDGEWARE and Texas Instruments provide a relatively full spectrum of support for the life cycle of applications and are the only tools which we examined that generate extensive code. IEF generates 100% of the code for all items contained in the diagrams they support. BACHMAN is largely an analysis and design tool but it is the only tool we examined which was capable of re-engineering (pulling an old database into a diagram then forward engineering it to a new environment). DEFT is quite useful as an analysis and design tool and does a creditable job in creating relational tables in several "popular" relational environments. ViaSoft is a good set of tools for making maintenance less troublesome. Figure 2 [FIGURE MISSING FROM TEXT FILE] Another area of major interest to ASU was the minimum platform configuration requirements in which these tools would work. Figure 3 shows a basic comparison of what each tool needs to perform an adequate job. _____________________________________________________________________ Figure 3 CASE Tool Platform Configuration Requirements Product Platform Memory Storage Oper. System Other TI IBM PS2 386 8Mb 115Mb OS/2 EE DBM/MFC KNOWLEDGEWARE IBM PS2 386 12Mb 115Mb OS/2 EE BACHMAN IBM PS2 386 12Mb 115Mb OS/2 EE DEFT MAC 8Mb 40Mb System 6 (7 pref.) ViaSoft MF:ISPF n/a n/a n/a _____________________________________________________________________ The projects with which these tools were tested were different but we have used our experiences to obtained some benchmark information comparing CASE development with third and fourth generation languages. In figure 4, please note that hours devoted to project management and training have not been included. We should also point out that the numbers are quite accurate and can be used to gain insight into CASE- supported activities. For example, one conclusion that can be immediately made is that CASE is not a panacea for a "no coding" requirement. Our own conclusions were that we should have spent more time in analysis. We believe this would have saved us substantial coding time. _____________________________________________________________________ Figure 4 Person-Hour Comparisons Comparable Project Basis Life-cycle Phase 3GL 4GL CASE Analysis 955 190 931 Design 1,260 1,125 1,302 Code/Test 3,789 3,739 2,445 Document 365 242 0 ***Total*** 6,359 5,296 4,678 _____________________________________________________________________ Figure 5 is a comparison of the strengths, weaknesses, and costs of these CASE products. Each tool provided good support within the project(s) for which it was used but none of the tools were as mature as we would have liked. The assessment of strengths and weaknesses are those made by ASU and reflect how the tools met our needs. Costs are rounded retail figures and are included to give some idea of the financial commitment associated with a decision to use tools such as these. _____________________________________________________________________ Figure 5 [1] Comparative Strengths, Weaknesses CASE Tool Strengths Weaknesses BACHMAN Provides a warehouse Latest IDMS not supported. of IDMS & DB2 databases. Weak IDMS-DB2 tool Performance & design integration. tips provided. DEFT Attributes on E/R Produces generic DDL. diagram. Supports many Slow to support RDBMS RDBMS DDL. changes. KNOWLEDGEWARE Integrated repository. Code generation is weak. Reusable objects. No testing facility. Documentation automatic. Weak maintenance link. Simple to use. Texas Instruments Integrated repository. Proprietary. Automated methodology. Some difficulty in use. 100% code generation. Weak print facilities. Multiple environments. Costs for these tools depend upon specific installation decisions but as a general idea they range from $10,000 to $500,000 for a basic system. _____________________________________________________________________ [1] Extracted from Joni Weber, "CASE Evaluation", Arizona State University internal report, May 1992. When all cost factors are taken into account, CASE technology is seen to be quite expensive. Not only are the tools themselves costly, but the hardware, training commitments, and consulting expenses are substantial. These costs and related issues create the third horn on our complex dilemma, it seems that we must do what we cannot afford to do. In addition to the conclusions outlined above, we also noted many cultural adjustments which would have to be made in our environment if CASE were to be successfully implemented. These observations and conclusions are summarized in the next table. Cultural Changes and Management Adjustments Required to Make CASE Successful at ASU +++ Systems Analysts must also become business analysts . This implies training of a different nature and possibly working for a time in offices to really understand the daily routines and what the applications are being expected to support. This would include time spent with management to develop an understanding of their true informational needs. +++ Use of these tools demands a data orientation to application development. Programmers and clients alike must be taught different behaviors in their use of data if CASE is to be successful. Data modeling must be initiated to ensure integration and minimize the duplication of data in our systems. +++ There are three groups into which staff will divide themselves relative to the use of CASE. The Innovators want to be first and are anxious for change while the Cautious wait to see what will happen. The small percentage of Hold-outs are simply those who will never adapt to the change. This mandates a staff development program be planned with staff input and acceptance. Use of the tool(s) must begin immediately on smaller projects. Encourage experimentation and alternative perspectives. +++ Everyone in the organization must begin to take a more holistic view of their functions and systems which support them. This is the only way to end the "stove pipe" syndrome from which our currents systems suffer. In particular, clients must become accepted members of the design groups and systems folks need to work hard to get them intimately involved. +++ We must plan for training in both theory and tools. This means training in: ++ Data Modeling ++ Process Modeling ++ Relational Model Theory ++ Methodology - specifics ++ RDBMS/SQL - specifics and ++ the tools which will be used in all of these +++ Most tools have a dictionary/repository but it is specific to the tool and not extensible. In a data administrated environment, this implies the use of a (possible distinct) single dictionary which is more flexible and the formation of work habits which will keep the dictionary updated. +++ CASE is expensive and it takes more than money. It takes equipment, staff time and commitment ... especially from management. Conclusion CASE technology has matured to the point of enabling substantial improvements in applications development. Even with purchased packages, there are tools which can provide modeling capabilities robust enough to help make a better match between an organization's needs and what the package will supply. We conjecture that vendors will soon begin supplying models with their packages to more easily enable customization and maintenance. The greatest cautions which we have identified have been cultural and managerial rather than technological. Careful planning is required if CASE is to provide the benefits of which it is capable. It is vital that anyone contemplating CASE tools carefully identify where they wish CASE to take them and along which path. As is to be expected, this technology is expensive but the promise of better, faster, more flexible systems is very alluring and, when properly applied, CASE can help fulfill this promise.