ABSTRACT
The United States Environmental Protection Agency (EPA), in collaboration with other federal agencies, research institutes and universities, has developed the Environmental Monitoring and Assessment Program (EMAP). EMAP generates large quantities of distributed RDBMS data, much of which is in Geographic Information Systems (GIS) format. The EMAP Geographic Information Systems Interface (EGI), developed at the EPA's Environmental Monitoring Systems Laboratory, Las Vegas (EMSL-LV), was developed as a tool to address access, integration, and assessment by a variety of users.
Given the changing user base and technologies now available, the EPA is migrating its ArcInfo AML based GUI to an ArcView implementation. With thousands of lines of code and menus and several intricate client-server functions, this process requires careful planning. The main discussion concerns the cost/benefit decision making process of maintaining old software versus conversion to new systems and technologies. Of particular note are the maintenance cost issues, which determine whether one should re-engineer existing code or redevelop new programs and systems. Results suggest that EMAP should aggressively pursue new development using ArcView 2 software while maintaining the current EGI.
INTRODUCTION
Re-engineering of software must often proceed in two directions; the maintenance and extensions of old systems, and transition into different technologies otherwise known as redevelopment. All software must contend with changing hardware and firmware, operating system revisions, and compiler and library changes. Applications written in scripting languages for complex third party systems have an additional burden of accommodating changes in that software. Functionality demands also play an important role in the decision to redevelop software.
Over the last twenty years a number of "new" solutions to the problems of aging software and conversion have emerged. These have included new methodologies, for example structured programming, hyped programming languages such as PL1, fourth generation languages, computer-assisted software engineering (CASE tools) and so forth. None has been a panacea. Instead, millions of dollars are invested over and over again in redeveloping older systems, never quite recovering the full conversion costs. More serious thought in the economics of conversion is consequently warranted.
In the meantime, systems analysts and programmers go on about their jobs of supporting software functionality in existing forms and converting to new technologies. Long time users of Esri's GIS products have faced transitions before--from the mainframe, keypunch card AUTOMAP system of the early 1970's to the mini- computer environment of PIOS (Polygon Information and Overlay System) and GRID/TOPO in the late 1970's, and several major revisions of ArcInfo, from a simple command line mini-computer system through the addition of graphic editing and emergence of AML, and more recently the introduction of user defined GUI's and shift to UNIX workstation platforms. Users have been fortunate that Esri has been sensitive to their large investments in both data and applications, providing relatively inexpensive conversion paths.
With the exploding emergence of ArcView 2 and Avenue, developers and end-users are once again challenged with justifying conversion and planning appropriately. As an example, this paper examines the decision process of one conversion project, that of the USEPA's EMAP GIS Interface (EGI). EMAP (Environmental Monitoring and Assessment program) is the Agency's long term national monitoring program designed to periodically sample indicators of change at tens of thousands of sites. The need for tools to explore and analyze the volumes of data is obvious. In response to this need, and as a means of introducing the use of GIS technology to the numerous ecologists, biologists, and other scientists working on this project, a simple GUI for data exploration was constructed several years ago.
The EGI is a basic browse and query system. It has some limited spatial analysis functionality, specifically exploratory statistics of an attribute (standard deviation, inter-quartile range, etc.), creation of boxplots and cumulative distribution function graphs. By continually re-engineering the EGI, the Agency has:
Still, the decay in utility and economics of supporting older software requires an eventual conversion as the life cycle approaches its end. The questions of when and how to begin this process can determine a mission's success within the enterprise.
CONVERSION ISSUES
The four principal conversion issues are:
Maintenance is often a function of code complexity, personnel, and operating environment. Older, large complex systems are obviously more difficult to maintain than new, small simple programs. Personnel can be another problem. Despite intensive in-line commenting, it is not uncommon to have difficulty understanding someone else's programming logic, or even your own after several years. More often than we would like, it is sometimes pragmatic to simply rewrite a routine rather than debug or otherwise enhance existing code.
The hardware platform, operating system, and related system dependencies is usually the most formidable obstacle. Even with stable code, the problems caused by even minor upgrades to the operating systems, new peripherals to interface, etc. are the principal catalysts for re-engineering efforts. With redevelopment using new hardware and software platforms there is also a learning curve and sensitivity to new equipment and early software releases.
Costs can be measured many ways. It includes direct costs of labor, hardware, and supporting software. There are also indirect costs of time, meeting mission critical objectives, and perceived importance. In the business world costs are summarized with respect to return on investment. Other measures include productivity increases, such as depicted in Figure 1.
FIGURE 1. Productivity as a Function of Maintenance Cost.
Technological obsolescence typically involves the hardware platform, operating system, and related system dependencies. It is usually the most formidable obstacle. Even with stable code, the problems caused by new operating systems, peripheral interfaces, etc. are the principal catalysts for re-engineering efforts.
Functionality requirements, by both users and policy managers, are the driving force behind many conversion projects. The need to include new functionality in a system that cannot support it repeatedly drives the decision to convert. The timing of this decision will definitely affect the overall costs and return on not just the one software project but future related projects.
COSTS AND BENEFITS OF RE-ENGINEERING
In an article on the economics of software re-engineering, H.M. Sneed (see Arnold, 1993) suggests most projects can be categorized under three situations when assessing benefits: 1) when the existing system becomes obsolete and replacement is needed, 2) when there are severe technical problems with he existing system, and 3) when it is expedient to upgrade the system.
In the first situation the choice is between redevelopment and re-engineering. With stable functionality and only technical obsolescence, it is more cost effective to re-engineer. It is also beneficial to re-engineer when the expertise does not exist for new development. In cases where new functionality and interfaces are obsolete, redevelopment can be justified. The re- engineering benefit would be negative if the new value is high relative to cost and risks. This is a consequence of the cost and risk of re-engineering being nearly as high as for redevelopment. However, if the values are nearly the same, re- engineering is more economical. Sneed puts this in simple mathematical terms thus:
In the second situation, severe technical problems, the decision reduces to either accepting a very high maintenance cost, replacement with a new standard package, re-engineering, or redevelopment. The same equation can be used as above, with the addition of a new term, old maintenance cost minus new maintenance cost:
With other costs being equal, it is the maintenance effort that determines when to begin conversion to new systems.
In the third situation, the nuisance factor takes precedence. As long as performance is adequate and one is willing to absorb added maintenance costs nothing need be done. However, maintenance will take longer, personnel will become uncomfortable, and turnover of quality personnel will result.
The only rules of thumb based on a case study in financial software suggests that the risk factor is two to three times higher for new development and that re-engineering costs should not be greater than one fourth of what new development costs would be.
PLANNING A CONVERSION
One enterprise modeling approach used to determine which software should be converted first uses a quadrant method scored on technical quality and importance to the enterprise organization (Figure 2). One axis programs and systems are scored as being of high or low technical quality. On the other axis the programs and systems are scored as being of high or low importance to the organization. Scoring can be made using parametric measures--for example, using performance benchmarks for code quality, user satisfaction surveys for importance measures, and other systems analysis for mission critical identification. Arguments are usually made in favor of first converting high importance programs with a low technical quality. Programs and systems that have both high quality and high importance are maintained and those with high quality and low importance left alone. Programs with low quality and low importance are candidates for inclusion in other systems.
FIGURE 2. Software Conversion Decision Matrix.
ANALYSIS OF EXISTING SYSTEM AND NEW DEVELOPMENT COST
The existing EGI, EMAP GIS Interface, is composed of:
Error trapping represents a good portion of the code, and subsequently creation and maintenance costs, but is not quantified at this time. An old industry rule suggested 70-80 percent of product oriented application code is devoted to error handling. Another measure of code cost that is easy to quantify is in-line commenting of code:
lines of code comment lines (percent)
AML's 6771 2416 (36)
Menus 2683 157 (6)
Note: most menus were written before comment lines were supported.
To estimate development costs, examination of the existing system reveals the following:
It should also be noted that the application under consideration is a browse GUI, not a complex analytic application. With the exception of basic exploratory statistics and a few custom graphics such as boxplots and cumulative distribution frequency curves, ArcView 2 already has the core functionality. Other applications will have a different mix of requirements and what can be accomplished with new standard out-of-the-box software such as ArcView 2.
DISCUSSION
Given the minimal amount of development code required, it is easy to justify investment and use of ArcView 2 as the core GUI and to develop new browse functionality using this technology. Maintenance at a low level should continue with the existing system. A generational replacement strategy can be used to migrate complex functionality to single ArcView 2 point and click buttons and tools. Initially functions not currently available in ArcView 2 can be chosen from a menu list that spawns a server ArcInfo session and executes the existing modular AML or other code. As this functionality is written using Avenue, the choice is removed from the menu and included as a single button or tool.
There are also several other issues, some intangible, that are not discussed in this paper but are relevant to the overall decision when deciding on redevelopment versus re-engineering. These include:
Recent work resulting from an investigation in September 1994, of the Oracle linkage using the base EMAP scientist PC platform, suggested that EPA should aggressively pursue further testing of the ArcView 2 software while maintaining the current EGI. This permits the Agency to determine the most efficient approach for developing queries, answering questions of how data will be indexed, and determining when temporary scratch tables of query results should be prepared in Oracle for more efficient use by other applications such as GIS. Other specific topics for testing include:
These tests can then be compared to the cost of designing, engineering, and maintaining traditional AML code.
CONCLUSIONS
ArcView 2 tool has a promising future in aiding various segments of the EMAP program in providing spatial data as well as the management framework and analysis tools for the evaluation and assessment of EMAP data. It offers efficiencies and capabilities which were previously unavailable, and the tool is already being used by government agencies at all levels, individuals, private businesses and a range of organizations to deal with resource management and environmental problems ranging from site-specific problems to global issues. ArcView 2 was designed on an object- oriented foundation to allow fuller integration of desktop mapping with GIS, business graphics, and traditional database systems. The client/server strategy lets users integrate their desk-top and high-end GIS applications with a powerful new data management capability.
ACKNOWLEDGMENTS
Although the research described in this document has been funded in whole or in part by the United States Environmental Protection Agency through Contract 68-CO-0050, it has not been subjected to Agency review and therefore, does not necessarily reflect the views of the Agency and no official endorsement should be inferred.
REFERENCES
Gibbs, W. Wayt, "Software's Chronic Crisis," Scientific American, Scientific American Inc., 271(3):86-95, September 1994
Arnold, Robert S.(ed.), Software Reengineering, IEEE Computer Society Press, Los Alamitos, CA, 1993
AUTHOR INFORMATION
Robert Puterski
Lockheed Environmental Systems and Technologies Company
980 Kelly Johnson Drive
Las Vegas, Nevada 89119
phone: (702) 897-3281
fax: (702) 897-3312
email: puterski.bob@epamail.epa.gov