Computer aided software engineering

For many organizations, particularly the larger, more established ones, computer-aided software engineering (CASE) was the party thrown where nobody came. Despite the hype and promises of dramatic improvements in developer productivity, these organizations haven't seen value in making a commitment to CASE.

The two main reasons I come across most often are CASE's inability to deal with the maintenance of existing systems, and its inability to accommodate software package solutions.

The information engineering approach is to generate applications with back-end code generators from business models developed in front-end analysis and design tools. For most old systems, and the majority of software packages you would want to buy, the models don't exist. If they do, they are likely not in a format that can be easily understood by your CASE tools.

Consequently, the candidates for CASE development have tended to be restricted to new, in-house development projects. For many shops, there simply aren't enough of these projects to warrant the investment in CASE.

Research conducted by Deloitte & Touche suggests a payback period for CASE of about three to five years for the majority of organizations. There's one key assumption: the entire portfolio of applications must be migrated (reverse engineered) into a format suitable for manipulation by front-end CASE tools for subsequent code generation (forward engineering). It's the combination of reverse and forward engineering that we commonly refer to as software reengineering.

In terms of reverse engineering data, there are tools available that will build data models from existing physical data structures which can then be manipulated by the CASE tools.

It's in the area of reverse engineering program code (typically Cobol) that tool vendors are currently concentrating their efforts. Today's tools will at least restructure existing program code and provide structure charts or process flow diagrams for manipulation within CASE tools. This approach merely transforms current physical processes into a more manageable format, and doesn't synthesize the process logic for the underlying business processes.

The challenge is to be able to determine the underlying business requirements that are embedded in a mass of procedural program source code and to represent them in unambiguous process logic. The matter is further complicated by the fact that often embedded within the program code are business rules which are more appropriately maintained in, and enforced by, the data model.

It's the combination of reverse engineering tools and forward engineering tools which will provide a powerful environment for maintaining mature applications and software packages, and along the way allow CASE to fulfil its promise.