Just in 'case' you have been hibernating for the last several decades, system development keeps evolving, and the technological tools that enable system development are evolving as well. 'Case' in point: the use of Computer Aided Software Engineering (CASE) tools is becoming more commonplace for all phases of the System Development Life Cycle (SDLC). These include data modeling tools, analysis and design specification tools, user interface prototyping tools and code generator tools. Not meaning to get on your 'case', but if your line of work involves system development, especially large-scale system development, then the 'case' has been made for the use of CASE tools.

Just what is a CASE tool? Countless definitions exist. In general, CASE can be defined as the automation of part of, or the entire, systems development process. What began as "paper and pen" based methodologies evolved over time into CASE tools with the development of graphical workstations and personal computers. CASE tools are computer-based products that support one or more phases within the SDLC. These tools help reduce or eliminate many of the design and development problems inherent in projects produced by manual methods. There are integrated CASE tools, (I-CASE), front-end tools (Upper CASE) and back-end tools (Lower CASE). Depending on the scope and scale of the project, either one of the tools or a combination of tools may be utilized. I-CASE tools support all phases of the development life cycle and do so in an organized manner by allowing for the integration and sharing of data between tools. The nucleus of an I-CASE tool is a shared dictionary/repository and that can be accessed by the strategy and analysis tools, the design tools and the build and maintenance tools. The repository stores the knowledge from the multiple tools in an integrated manner, and is accessible to all tools throughout the entire development life cycle. Upper CASE tools are designed for the early stages of the SDLC, and are used for project planning, systems analysis and general systems design. Upper CASE tools help diagram and define the current system and the proposed system and these include requirements and design support tools. Lower CASE tools are designed for the back-end of the SDLC and are used for detailed systems design, system implementation and system support. The most common Lower CASE tools are the code generators, but others include compilers and test support tools.

There are many different variations of the System Development Life Cycle. In terms of software development alone, there are over 250 internationally recognized software engineering methodologies. Most development life cycles are cyclic in nature, though the cycle may not be continuous, with lags between phases. Some phases may overlap and run concurrently and some phases may be repeated until the output is deemed acceptable. One of the best known SDLC models is the waterfall: where the output of each stage becomes the input for the next stage. Traditionally, this particular SDLC consists of seven phases:

• Project Planning and Feasibility Study
• Systems Analysis and Requirements Definition
• Systems Design
• Implementation
• Integration and Testing
• Acceptance, Installation and Deployment
• Maintenance

The SDLC works most efficiently when different specialists are responsible for the different phases. The Analysis phase would benefit from the input of a developer experienced with systems analysis and diagramming, whereas the Implementation phase would require the expertise of a programmer. The structured methodology of a CASE tool allows the different specialists to work independently. CASE tools allow for more focus on the architecture of the system, rather than the code as CASE tools can generate code from design specifications. One of the goals of CASE is to separate design (Upper CASE) from implementation (Lower CASE). The more detached these two areas of development, the better.

Even with the widespread introduction of commercial CASE tools in the eighties, there still remains some resistance to their use. A recent study survey indicated that in the United States, CASE tool usage was at around 13%. Many mainstream programmers and analysts are hesitant to put aside traditional "paper & pen" based methodologies and use CASE tools for fear of loss of control in the design phase. Usability problems associated with CASE tools discourage not only initial use but continued use. Most tools have a substantial learning curve that takes valuable time away from the project. Cost is also a big factor, with CASE tool software costing several thousands of dollars per developer to integrated suites of tools costing tens of thousands of dollars. In addition, some of the new fourth generation languages (4GL) provide similar functionality to CASE tools but at a fraction of the cost.

A study was conducted (Richard E. Yellen, University of North Texas) to determine if system analysts using CASE tools performed higher quality work than those using traditional manual methods. This exploratory study looked at tools that made Data Flow Diagrams and data dictionary entries. Three attributes were considered in the study, 1) correctness, 2) completeness and 3) communicability. The only attribute in which the quality of the work produced by the two methods was statistically significant was correctness. The study concluded that the CASE tool used in the study was superior to the manual system in terms of correctness (the conformity to the standard rules of diagramming and construction of the data dictionary). This study was conducted a decade ago and CASE tools have evolved quite a bit in terms of functionality. The last decade has witnessed the development of MetaCASE tools that allow a developer to create a customized CASE tool to suit their specific problem, specific development needs or even their own skills.

Why should CASE tools be considered? Despite a constantly evolving industry and stories of limited success, the focus of CASE tools remains the improvement of the overall systems development process. The two main reasons for utilizing CASE tools are:

• Reduce the amount of time and money spent on projects
• Improve the quality of the system developed

However, CASE tools can also:

• Enhance the developers' productivity and satisfaction
• Make the system development task more enjoyable

The use of CASE tools can formalize the requirements gathering stage, forcing developers to consider what they are building before they build it. CASE tools enable the developing of systems that are easier to test and maintain and contain good quality documentation. In a nutshell, software developed using CASE tools has improved quality due to fewer defects.

What are the inherent benefits of CASE tools? First off, they allow the system designer(s) to focus on architecture versus worrying about coding. Designers can input the requirements of a system and the CASE tool can generate the code (Forward Engineering). CASE tools also support Reverse Engineering (RE), where existing code from legacy systems can be turned into design specifications, which in turn can be used to restructure the code and ultimately the system to meet new business needs. RE can account for one of the largest parts of software maintenance costs. The automation of previously manual tasks by CASE tools can reduce the time to perform certain tasks, such as diagramming and code generation. CASE tools can even assist in the laborious task of project estimation, and can assist with the estimation of work effort in hours through the use of project estimation tools. A big advantage of CASE tools is that the usage of CASE tools enables an organization to implement a single design philosophy for all projects, systems and people. An organization should have a standard development methodology (or methodologies) in place before considering CASE tools or the adoption of CASE tools will encounter problems. With CASE tools, developers working in different teams utilize the same procedures and methods for developing their aspect of the project, sharing information common to all the development teams. Because of this, CASE tools have the ability to synchronize the model design and implementation. The result is better analysis and design and more accurate coding due to procedures like automatic testing and debugging. This also leads to a reduction in lifetime maintenance of the product - another cost saver. CASE tools provide better documentation during each phase of development. With the advent of Object Oriented Methodologies being incorporated into CASE tools, inexperienced or even non-programmers are able to utilize CASE tools due to the simplicity of object oriented module usage.

There are potential limitations associated with the use of CASE tools. Training and education of users can take considerable time and the cost of training can be as much as one dollar for every dollar invested in the CASE tool itself. The simple evaluation process used for selecting a CASE tool will take time. Once purchased, the tool will require upgrades, ongoing usage and maintenance fees. Tool users can be consumed with "techno-lust" and become infatuated with all the bells and whistles of the tool, spending excess time making diagrams look fancy, adding unnecessary extraneous information, unnecessary features - all of this wasting valuable time. If not planned for ahead of time, inadequate integration with other tools or components of the system reduces productivity and requires time for integration work. Last, but not least, CASE tools can be expensive. Many organizations believe that the cost of CASE tools (along with associated hardware costs) can only be justified for large-scale development.

Selecting a CASE tool can be a daunting task, considering the myriad of vendors on the Internet (one Vendor list contains 500+ entries). There are many factors to consider when choosing a CASE tool. Training is a key factor and the amount and quality of training offered by the vendor should be considered. Vendor support can also be crucial, especially during initial implementation of a CASE tool. Vendor support should be via several avenues, email, direct chat and conference calls. The available level of customization may be critical, especially if an off-the-shelf product doesn't quite fit the needs of the project. Compatibility of the tool with current components and other important software (operating system software) should also be considered. The bottom line would be that the CASE tool delivers the value for the money, though to calculate the expected value of a tool, both quantitative and qualitative costs must be considered. A small-scale system may not require a full suite of CASE tools, whereas a large-scale system with millions of lines of code would require one. To evaluate CASE tools, the project team needs to have a formalized selection process in place that would assess the functionality aspects of the CASE tools that the team members are most likely to utilize. This formalized selection process should tie in with any best practice initiatives of the organization. This is especially true if the company has embarked on a journey towards best-in-class status and is utilizing a reference process architecture such as the Software Engineering Institute's Capability Maturity Model, or ISO 9000, or the Malcolm Baldrige National Quality Award. CASE tool selection has been considered one of the important components of an organization-wide best practice program.

Many CASE tool implementations result in failure. In some organizations up to 70 percent of the CASE tools were not being utilized after the first year. This could be due in part to the user's perceived complexity of the tools. Many CASE tools have a steep learning curve. Thorough training before and during the use of the tool is key to successful use. Training also should include education concerning the benefits of CASE use as research has shown that 'perceived relative advantage' of CASE as well as 'perceived productivity and quality effect' can have a positive influence on user's perceptions of the tool. In addition, if management requires compulsory use of the tools, then users are more apt to utilize the tools as opposed to situations where tool use is voluntary.

As technology evolves, the future of CASE tools development looks promising. The ideal CASE environment is a suite of fully integrated tools that enables efficient and accurate system development through all phases of the SDLC. Reducing the number of CASE tools required to develop a system is one approach software vendors are taking to increase user acceptability (and to lower cost). Another approach is the constant fine-tuning of existing CASE tools, due in part to increased demands by users for automation of the development processes (perceived speed and accuracy issues) and the evolving technology that enables this automation. Here are some other areas of current CASE tool development and research:

• To further automate the Analysis phase; the identifying of object classes, attributes and relationships; a CASE tool is needed that would be able to interpret human language as media. The development of a Natural Language Processing (NLP) based CASE tool would solve this problem. Current research in this area involves a CASE tool that takes a single software requirement document (i.e. a Word document) as input, extracts the main object classes and relationships, and outputs a list of candidate classes and relationships and a conceptual model. This initial model is in a commonly accepted format that can be refined by the analyst using existing CASE tools.
• CASE tools will also need to deal with changing methodologies. As object modeling methodologies become more prevalent, CASE tools will need to deal with Object Modeling Technique (OMT), Booch, Jacobson Use Cases, the Unified Modeling Language (UML) and Fusion. A recent development in OMT is the use of hyperlinks between all related objects. By simply clicking on an object the user can navigate to information related to the object. This allows online review of documentation versus hard copy review.
• Mixed-language development (Java, C++, Visual Basic) will also play a role in the evolution of CASE tools.
• Another area requiring further research and development is the concept of human-centric CASE tools. Many of the usability problems encountered with CASE tools are due to conceptual gaps between the user's mental model of the integrated software development environment and the way it can be used.
• As the Internet evolves, so must CASE tools. The use of Web-based applications will prompt the development of CASE tools with Web-based functionality capabilities.

CASE tools are simply that, tools that support system development. Like any tool, if not properly used, the tool may not perform the job needed. The project development team must first decide if the scale and or needs of a project justify the costs associated with CASE tools. The team must then select the proper CASE tool from the hundreds available. With proper training the development team can utilize CASE tools to automate aspects of the system development life cycle, producing a quality product that will require less maintenance.

1. Barker, Richard. CASE*METHOD Entity Relationship Modeling, Addison-Wesley Publishing Company, 1990.
2. Barker, Richard. CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company, 1990.
3. Daneva, Maya. A Best Practice Based Approach to CASE-tool Selection, Proceedings of the Fourth IEEE International Symposium and Forum on Software Engineering Standards: 100-110, 1999.
4. Finnigan, David. Kemp, Elizabeth A. Mehandjiska, Daniela. Towards an Ideal CASE Tool, International Conference on Software Method and Tools: 189-197, 2000.
5. Harmain, H.M. Gaizauskas, R. CM-Builder: An Automated NL-Based CASE Tool, Proceedings of the Fifteenth IEEE International Conference on Automated Software Engineering: 45-53, 2000.
6. Hoffer, Jeffrey A. George, Joey F. Valacich, Joseph S. Modern Systems Analysis & Design, Prentice Hall, 3rd Edition, 2002.
7. Jahnke, Jens H. Integrating Cognitive Support with CASE-tools for Design Recovery, Proceedings of the First IEEE International Conference on Cognitive Informatics: 145-154, 2002.
8. Low, Graham. Leenanuraksa, Vichai. Software Quality and CASE Tools, Software Technology and Engineering Practice Proceedings: 142-150, 1999.
9. Post, Gerald V. Kagan, Albert. Keim, Robert T. A Structural Equation Evaluation of CASE Tools and Attributes, Journal of Management Information Systems, 15(4): 215-234, Spring 1999.
10. Seffah, A. Rilling, J. Investigating the Relationship between Usability and Conceptual Gaps for Human-Centric CASE Tools, Proceedings of the IEEE Symposium on Human-Centric Computing Languages and Environments: 226-231, 2001.
11. Yellen, Richard E. Systems Analysts Performance Using CASE Versus Manual Methods, Proceedings of the Twenty-Third Annual Hawaii International Conference on System Sciences, (4): 497-501, 1990.