<![CDATA[
<body bgcolor=#ffffff>
<a name="866207">
<center>
<img src="ajpoinel.anc.gif">
</center><p>
</a><a name="866222">
<p>
</a><a name="866233">
<p>
</a><a name="867570">
<h1>Introduction<br>-- (or, Why Should You Read This?)</h1>
</a>
<hr><p><a name="866251">
Today's business and government environments are in a constant state of change. All occupations -- managers, decision makers, technical experts, executives, support staff, administrative personnel, financial planners -- are being constantly bombarded with new technologies, different methods, and new ways of running organizations. Regardless of your occupation or type of business/organization, you have one thing in common with everyone else: competition. Every organization and business is under intense pressure to become more efficient, more cost effective, and more competitive.<p>
</a><a name="866252">
Without exception, computers are part and parcel of every competitive organization in the modern world. There is no major industry in the world that can survive, much less prosper, without a heavy reliance on computers. Unfortunately, computer users and developers of computer systems are also being subjected to constant change and a constant bombardment of new technologies, methods, etc. As computer hardware continues to improve in raw power and performance, competitive organizations are beginning to rely more heavily than ever on computerized systems -- systems which in turn are totally dependent on the most difficult and costly component in a computerized application: the software.<p>
</a><a name="866253">
This monograph is about software; more particularly about the aspects of software which enable an organization to stay competitive and to survive. Regardless of whether you are in the commercial market or part of a government organization, the information and insights contained in this monograph are valuable, and will help you and your organization to be better at what you do.<p>
</a><a name="866254">
If you are a senior executive, this monograph can help you make better decisions and formulate better strategies for your organization or business. If you are a technical manager, the information in this document will enable you to make well-informed decisions about the development and management of computer systems. If you are a technical expert, this monograph will help you communicate more effectively with your management team, to help you garner appropriate resources for performing your tasks. If you are a procurement specialist or financial expert, this monograph will guide you in making better decisions and investments in software and computer technology, for the benefit of your organization and its customers.<p>
</a><a name="866255">
The information presented in this monograph is based on actual field experience, not theory. Topics of critical interest, such as software reuse, object-oriented technologies, the use of software standards such as GKS, Unix, and Ada, and the importance of applying software engineering methods in the development of critical software applications, are all addressed in this document.<p>
</a><a name="866256">
The answer to the question, "Why should you read this?" is quite simple. It will help you and your organization to be more competitive in an increasingly competitive and complex world.<p>
</a><a name="866532">
<h1>Executive Summary</h1>
</a>
<hr><p><a name="866258">
As modern software systems become increasingly complex and critical, executives, managers, and technical team leaders are faced with ever more difficult choices. Regardless of your position in a government organization or a commercial business operation, the insights contained in this monograph can be of benefit, and can help you achieve and keep a competitive advantage.<p>
</a><a name="866259">
Decisions regarding the disposition of existing legacy software systems can have an enormous effect on the operations -- even survival -- of government and commercial organizations. Many organizations are grappling with trade-offs of retiring older software systems and moving into more modern and efficient architectures, while trying to find ways to leverage some remaining capabilities of legacy systems to reduce cost and risk of software modernization.<p>
</a><a name="866260">
The United States Air Force (USAF) is facing these difficult decisions. In a cooperative effort with the United States Department of Energy's (DOE) Idaho National Engineering Laboratory (INEL), the Air Force successfully addressed many of the hard issues facing commercial executives and managers today. The lessons learned by USAF/INEL provide valuable insights and models for action for both government and commercial decision makers.<p>
</a><a name="866261">
Although the project involved the reengineering of a military software system, the applicability of the experience is appropriate across many commercial domains. The critical necessity for migrating from older legacy software systems to modern software architectures crosses boundaries of virtually every application domain in the internationally competitive software marketplace.<p>
</a><a name="866262">
<h4> Reengineering Legacy Systems</h4>
</a><a name="866263">
The Air Force was faced with maintaining a legacy system which provided important capabilities to its users. While the users were satisfied with the system, the Air Force was finding it increasingly expensive and difficult to maintain software written for a proprietary, "non-open" hardware platform. As maintainability of the code decreased, support costs increased, and reliability of the system deteriorated.<p>
</a><a name="866264">
The Air Force initially directed the INEL to re-host the application, and move it to an open systems architecture. Basically, this effort involved translating the existing code from FORTRAN into C. Although the resulting code functioned properly, and the application was moved to an open systems architecture, the code itself was even less maintainable than the original FORTRAN software. As more functionality was added to the original application, maintainability of the software continued to decrease.<p>
</a><a name="866265">
INEL was then asked to conduct a study of the application, to include an analysis, evaluation, and recommendations to the Air Force as to future directions for the program. The recommendations for the future were to ensure the continuing satisfaction of the Air Force user community. The study showed the system needed to be reengineered to provide for future user needs, and INEL recommended a blend of technologies and methods, including a layered, object-oriented software architecture, implemented in the Ada programming language. The resulting reengineered system produced a threefold improvement in maintainability of software. Additionally, the reengineered system has enabled new functionality to be added in a fraction of the time required with the original and re- hosted versions.<p>
</a><a name="866266">
<h4> Maintainability Index and Metrics</h4>
</a><a name="866267">
The decision to reengineer a legacy software system is difficult to justify without appropriate metrics. As part of the USAF/INEL justification, specific metrics were collected and analyzed to provide indicators of system maintainability and complexity. These metrics, in combination with independently developed polynomial equations, have been used by some organizations to calculate a "maintainability index" which provides an indication of the maintainability of a software system. Based on independent studies and separate work performed by the University of Idaho and verified in the field by Hewlett-Packard, the maintainability index confirmed INEL's recommendation to reengineer the application.<p>
</a><a name="866268">
This experience with the maintainability index, and the subsequent verification of its applicability, offer powerful insights for decision makers who are contemplating reengineering of legacy systems. As the USAF/INEL project has shown, a maintainability index can help in providing sound economic justifications for the reengineering of legacy software.<p>
</a><a name="866269">
<h4> The Role of Software Architecture</h4>
</a><a name="866270">
Many legacy software systems have been developed using a functional decomposition methodology (if any formal methodology was used at all). Early generations of software systems typically make extensive use of proprietary platform features, operating system calls, and language- specific constructs which severely hamper maintenance, reuse, and portability. These fundamental differences in the underlying software architecture contribute significantly to the lack of benefits to be derived from re-hosting or translating efforts, as the Air Force learned on this project.<p>
</a><a name="866271">
INEL used an object-oriented layered software architecture to achieve many of the benefits of their reengineering activity. By using layers for the application, interface, graphics, operating system, and hardware, the development team was able to deliver superb benefits to the Air Force. The layered architecture also enabled the use of a hybrid of technologies, language, and methods, in a well-engineered development effort.<p>
</a><a name="866272">
<h4> COTS (Commercial Off-the-Shelf) Software and Ada</h4>
</a><a name="866273">
For government software developers and decision makers, particularly those in the U.S. Department of Defense (DoD), current policy requires the use of COTS software products wherever those commercial products can satisfy DoD needs. In those cases where there are no adequate COTS products, new software must be developed in Ada, unless a waiver is obtained to use another programming language.<p>
</a><a name="866274">
On the surface, the DoD policy on COTS and Ada seems to be fairly straightforward, but as the Air Force and INEL discovered, a superficial implementation of the policy can be extremely costly -- in terms of support and funding. INEL's experience in evaluating the "real" costs and facets of using COTS software can provide government decision makers with substantial savings in choosing between COTS and new Ada code.<p>
</a><a name="866275">
Decision makers and software managers are deluged with new software product offerings which claim to offer powerful capabilities and benefits. Filtering through the claims and discerning the real benefits, then comparing those benefits with the cost/benefit of a "from scratch" application is a daunting task -- regardless of your application domain.<p>
</a><a name="866276">
<h4> Dual-Use Opportunities</h4>
</a><a name="866277">
As DoD and other government budgets continue to shrink, it is becoming more important for all government agencies to work together to exploit technologies and programs of common interest. It is also critical for government agencies to exploit technologies which have applicability in major commercial markets -- what is known as "dual-use" technologies.<p>
</a><a name="866278">
The USAF/INEL effort is a superb example of interagency cooperation, with benefits accruing to the users, the agencies, the government, and the taxpayer. Much of the code is available as "public domain," government-funded software, with excellent applicability in major commercial domains. The combination of object-oriented methods, COTS software, and Ada makes this project an ideal candidate for technology transfer to the private sector.<p>
</a><a name="866279">
<h4> Summary</h4>
</a><a name="866280">
This monograph is designed to be a valuable information resource for decision-makers, software developers, and users. Most of the issues addressed are generic in nature, and span a broad cross-section of software domains.<p>
</a><a name="866281">
This document is part of an ongoing series of monographs which will investigate the major software challenges and solutions required for viable modern complex software systems.<p>
</a><a name="867709">
<h1></h1>
</a>
<hr><p><a name="866553">
<h1>Electronic Combat Model Reengineering</h1>
</a>
<hr><p><a name="866591">
<center>
<img src="ajpoinel.anc1.gif">
</center><p>
</a><a name="866627">
<center><h3>Figure 1 EC Analysis</h3></center>
</a><a name="866282">
<h4> Project Background</h4>
</a><a name="866283">
The Idaho National Engineering Laboratory (INEL) is a Department of Energy (DOE) National Laboratory, located in Idaho Falls, Idaho. INEL is engaged in a wide variety of projects, ranging from computer and software systems development, to environmental programs, to energy generation technologies, and national and international technology transfer projects. The organization has a track record for delivering complex software solutions for a broad range of applications, in both government and commercial environments.<p>
</a><a name="866284">
This project, the Electronic Combat System Integration (ECSI), was initiated by the INEL in support of the U.S. Air Force Information Warfare Center (AFIWC) at Kelly Air Force Base, in San Antonio, Texas. AFIWC's mission includes detailed electronic combat modeling support for a variety of Air Force organizations. One of the models developed by AFIWC is the IMOM (Improved Many-On-Many) electronic combat model.<p>
</a><a name="866285">
IMOM is an electronic combat modeling system, which supports air operations combat mission planning. Basically, the system helps combat pilots plan their missions in an environment of hostile electronic combat systems. For example, pilots planning combat missions would be very interested in knowing the range at which a hostile radar system would detect their aircraft, so that they could avoid detection during the mission. Furthermore, using IMOM, pilots can run different "scenarios" showing the difference in detection ranges that would occur if they changed the altitude of the mission profile (i.e., flying in at 500 feet instead of 1,000 feet of altitude can make a huge difference in detection ranges).<p>
</a><a name="866286">
IMOM has also been incorporated into the Air Force CTAPS (Contingency Theater Automated Planning System). CTAPS is a command and control system developed by a joint Air Force/INEL team for managing complex air/land battle operations anywhere in the world.<p>
</a><a name="866287">
Various models of different detection devices and technologies can be depicted in the IMOM system, showing the range and capabilities of a variety of radars. Also, the effect of height above the ground of the sensor, and the effect of electronic counter-measures (ECM) can be determined. In this modern era of increasingly sophisticated detection systems and antiaircraft technologies, the success and survival of U.S. military pilots are heavily dependent on an accurate depiction of the expected coverage of electronic combat systems.<p>
</a><a name="866288">
The benefits that IMOM provides to pilots of modern military aircraft were proven during the Persian Gulf War, where the system was used extensively by U.S. pilots, under the auspices of the Air Force Sentinel Byte program. Sentinel Byte disseminates and displays intelligence and key early warning data for use by Air Force combat mission planners and pilots. At the time of the Persian Gulf War, IMOM was a Sentinel Byte application, having been moved from the AFIWC and CTAPS programs into the Sentinel Byte environment.<p>
</a><a name="866289">
The fact that IMOM could be moved from one major functional environment (CTAPS) to another (Sentinel Byte) is significant. Basically, IMOM delivered critically important capabilities to Sentinel Byte, virtually immediately, without additional development time and resources being required. Substantial additional functionality was then added to the core IMOM application, enhancing the value of the system to allied pilots in the Persion Gulf War.<p>
</a><a name="866290">
This ability to move critical capabilities from one major functional environment to another has tremendous applicability in non-Air Force organizations. Similar benefits can be achieved by large government and commercial operations that are able to share and leverage common operational requirements and solutions.<p>
</a><a name="867749">
The IMOM system was originally an AFIWC in-house program used in response to tasking and requests from other Air Force components. Due to its excellent performance and capabilities, IMOM became very popular with Air Force users from other commands. As a result of this superb performance and popularity, IMOM was distributed to a broad range of Air Force users, including pilots and mission planning personnel. As shown in <a href="ajpoinel.html#866627">Figure 1</a> and <a href="ajpoinel.html#867777">Figure 2</a>, the graphical representation of the various IMOM family of models allows users to take advantage of the capabilities of the system in a familiar context and manner -- just as they would if they were working with a manual system of maps, charts, and markers. The color graphical interface enhances the fundamental capabilities of IMOM, with corresponding benefits to its users.<p>
</a><a name="867775">
<center>
<img src="ajpoinel.anc2.gif">
</center><p>
</a><a name="867777">
<center><h3>Figure 2 EC Models</h3></center>
</a><a name="867757">
<h4> Project Evolution -- Translating from FORTRAN to C</h4>
</a><a name="866293">
The original IMOM capability was developed in 1984. Written in FORTRAN, the original version was hosted on a proprietary VAX/VMS platform, and used Tektronix PLOT-10/STI graphics. The software was designed using a top-down functional decomposition approach, with a high degree of machine dependency in the code. The IMOM system was a success from the perspective of the users, and the system established a track record of successful usage.<p>
</a><a name="866294">
Due to the long-term successful track record, IMOM users requested numerous enhancements to the IMOM model(s). As electronic combat threats and technologies evolved, IMOM users required additional functionality in the software. As a result of user needs and advances in electronic combat technologies, the original IMOM expanded quite rapidly, with substantial additions to the initial software system.<p>
</a><a name="866295">
In terms of current open systems architectures, the original IMOM was most definitely a "closed" system. As the Air Force and the Department of Defense migrated toward open systems technologies in the late 1980s, it became clear that the proprietary IMOM architecture needed to be modified. In 1989, the Air Force tasked the INEL with modifying the IMOM system to enable it to operate in a Unix/X-Windows environment, using standard GKS graphics.<p>
</a><a name="866296">
To accomplish the required modifications, INEL translated the original IMOM FORTRAN code to C, and moved the software to a Digital Equipment Corporation (DEC) workstation. In keeping with the Air Force's tasking, the original software architecture was retained, and the majority of the translation from FORTRAN to C was accomplished using an automated translation tool.<p>
</a><a name="866297">
The end result of this re-hosting task was an open systems implementation of IMOM which ran on Unix, incorporated GKS (Graphical Kernel System) graphics, and used a "point and click" user interface. As was the case with the FORTRAN version of IMOM, the new C implementation was well-received by users of the system. Some additional functional enhancements were made to the C version of IMOM through 1991.<p>
</a><a name="866298">
As shown in the left half of <a href="ajpoinel.html#867900">Figure 3</a>, the original FORTRAN IMOM evolved as a baseline for the additional capabilities. In 1990, INEL added the functional capabilities required by the Air Force's Sentinel Byte program, eventually evolving the FORTRAN IMOM baseline through version 5.0 (as shown in <a href="ajpoinel.html#867900">Figure 3</a>). In addition to the FORTRAN enhancements, the C version of the IMOM baseline was upgraded to include the Sentinel Byte requirements.<p>
</a><a name="867898">
<center>
<img src="ajpoinel.anc3.gif">
</center><p>
</a><a name="867900">
<center><h3>Figure 3 Historical Overview</h3></center>
</a><a name="866299">
The additional models shown in <a href="ajpoinel.html#867900">Figure 3</a> are different from IMOM, and have their own community of users, as well as a separate Air Force office. Those models, the COMJAM (communications jamming), PASSIVE DETECTION, and RECCE (reconnaissance) models, were all originally implemented in FORTRAN. Unlike the original FORTRAN versions of IMOM, the other models were not translated into C. The Ada versions were a result of the reengineering effort conducted by INEL.<p>
</a><a name="866300">
Although the various IMOM implementations were quite successful from the users' perspective, the different language and platform implementations suffered from configuration management (CM) problems. In addition to the CM challenges, the software was becoming more difficult to maintain and modify. In 1991, the Air Force realized that the existing implementations of IMOM would not be adequate to support user needs into the future. The cost of maintaining and modifying the software was becoming unacceptable, and enhancements were exacerbating the complexity of the system. As a result of these concerns, and in anticipation of expected user requirements in the future, the Air Force tasked INEL with conducting a research study to ascertain the future directions of IMOM.<p>
</a><a name="866301">
<h4> Research Study -- The Future of IMOM</h4>
</a><a name="866302">
INEL's research study included four primary objectives:<p>
</a><ul>
<a name="866303">
<li>Determine the objectives and future goals for IMOM.
</a><BR><a name="866304">
<li>Identify current industry and DoD standards which could apply to IMOM.
</a><BR><a name="866305">
<li>Analyze the current IMOM implementations from a software engineering perspective.
</a><BR><a name="866306">
<li>Offer recommendations to the Air Force as to how to achieve the IMOM objectives.
</a><BR></ul>
<a name="866307">
Among the objectives and future goals identified for IMOM was the need to provide software which would be more maintainable and modifiable than the existing FORTRAN and C code. More easily maintainable code would allow the Air Force to minimize support costs without sacrificing functionality and reliability. More easily modifiable software would enable the AFIWC to keep pace with changing user needs as well as new and emerging technologies. The ability to migrate the software to more powerful computer platforms was also a sound objective for IMOM.<p>
</a><a name="866308">
The current industry trends and standards which could apply to IMOM included a wide variety of technologies and tools. Clearly, the need for an open systems architecture was an ongoing requirement for the future. In addition, the use of modern software development methods, such as object-oriented techniques, offered substantial promise for long-term IMOM usage and support. Other DoD and industry standards, such as the Ada programming language, were included in the INEL research study.<p>
</a><a name="866309">
As the study progressed, it became clear that there were two major factors which had a direct impact on the design and structure of the IMOM software: the software architecture; and the programming language used for the implementation. The deficiencies of the original software architecture, with its reliance on hardware-specific features and operating system calls, were perpetuated in the translated C version of the code. INEL concluded that a continuation of the original software architecture would effectively preclude any major improvements in the quality and maintainability of the IMOM software.<p>
</a><a name="866310">
Since INEL's study was conducted from a software engineering perspective, the role of programming language selection in support of a well-engineered software implementation was included in their evaluation of IMOM. In this context, INEL compared FORTRAN and C with Ada. As INEL applied and evaluated various software engineering principles (i.e., abstraction, information hiding, encapsulation, modularity, etc.), it became clear that the Ada programming language offered superior support for a reengineered version of IMOM.<p>
</a><a name="866311">
Ada also offered benefits in the application of an object-oriented design for IMOM. As part of their evaluation of object-oriented technologies and techniques, INEL noted the importance of applying object-oriented methods in a disciplined software engineering context, as opposed to focusing on overrated and highly abused object-oriented programming features, such as inheritance and polymorphism. The evolution of the various versions of IMOM proved the importance of a sound, flexible design as a key factor in obtaining the benefits sought by the Air Force in the areas of maintainability and modifiability. From a design perspective, as well as a software engineering perspective, Ada was a superior choice for the future of the IMOM application.<p>
</a><a name="866312">
INEL's bottom line recommendations to the Air Force were as follows:<p>
</a><ul>
<a name="866313">
<li>Reengineer and redesign the system
</a><BR><a name="866314">
<li>Use object-oriented technologies
</a><BR><a name="866315">
<li>Use the Ada programming language
</a><BR></ul>
<a name="866316">
<h4> Reengineering IMOM</h4>
</a><a name="866317">
INEL produced a Software Development Plan which set forth and documented the process by which IMOM would be reengineered. The Plan emphasized the use of sound software standards, such as Ada, as well as the disciplined application of software engineering principles. The development team followed an iterative lifecycle approach, to ensure flexibility and fast response to changing user requirements.<p>
</a><a name="866318">
The redesign of the software used object-oriented (OO) analysis and design techniques with an implementation in Ada. A hybrid OO methodology was used for the analysis and design, drawing from a variety of well-known OO methodologies offered by Rumbaugh, Booch, and Coad/Yourdon. Basically, the INEL development team used the best features of these various methodologies and combined and adapted them to fit the requirements of the IMOM software redesign.<p>
</a><a name="866319">
The result of the object-oriented redesign of IMOM was a reusable layered software architecture, as shown in <a href="ajpoinel.html#866782">Figure 5</a>. The layered nature of the new software architecture enabled INEL to clearly define the interfaces between the layers, and implement the various pieces and subsystems of the application in a highly modular manner. The clear delineation between layers and between modules within layers was an explicit design goal to enable ease of maintenance and modifiability of the IMOM code.<p>
</a><a name="866320">
One of the major benefits of the layered reusable software architecture was the mitigation of the risk of using a mix of software technologies and methods. While INEL had recommended the use of solid technologies, such as Ada, object-oriented design, Unix, GKS, and Motif, those technologies and methods had typically not been combined together all in the same system. The underlying software architecture allowed the use of a hybrid solution consisting of a mix of language, architecture, methodology, and technology.<p>
</a><a name="866321">
Because of INEL's focus on a well-engineered layered software architecture, they were able to apply a wide variety of powerful technologies and methods in a disciplined and cost-effective manner. The variety of techniques, methods, and technologies depicted in <a href="ajpoinel.html#867933">Figure 4</a> were applied in a controlled and well-engineered process to produce the layered software architecture shown in <a href="ajpoinel.html#866782">Figure 5</a>.<p>
</a><a name="867931">
<center>
<img src="ajpoinel.anc4.gif">
</center><p>
</a><a name="867933">
<center><h3>Figure 4 Techniques and Methods</h3></center>
</a><a name="866322">
Due to the solid success of the IMOM reengineering effort, the Air Force directed the INEL to proceed with the reengineering of the other electronic combat models. As shown in the right half of <a href="ajpoinel.html#867900">Figure 3</a>, these other programs included Ada versions of the COMJAM, PASSIVE DETECTION, and RECCE electronic combat models. All of these models were successfully reengineered during the 1991-1993 time period, using the same layered, object-oriented architecture and Ada.<p>
</a><a name="866781">
<center>
<img src="ajpoinel.anc5.gif">
</center><p>
</a><a name="866782">
<center><h3>Figure 5 Reusable Layered Architecture</h3></center>
</a><a name="866323">
<h4> Measures of Success -- Speed of Development</h4>
</a><a name="866324">
Once the reengineering effort was completed, and all of the IMOM "family" of models had been implemented in well-engineered Ada code, an analysis was conducted to measure the success of the program. Although IMOM users were quite satisfied, the Air Force needed to ascertain whether the fundamental IMOM goals of improved maintainability and modifiability of the software had been achieved.<p>
</a><a name="866325">
Over time, software systems which have been developed using top-down, functional decomposition approaches have experienced significant deterioration in terms of maintainability. This is due, in part, to the effects of adding additional capabilities and functionality, which result in substantial increases in the complexity of legacy systems. In software systems which have not been well engineered, new levels of complexity are introduced as defects are corrected, leading to further deterioration of code maintainability.<p>
</a><a name="866326">
The introduction of new complexity, combined with the demand for new functionality far beyond the scope of the original design, has an extremely detrimental impact on the ease with which the code can be modified. The Air Force recognized that the limitations of the original IMOM software architecture precluded the implementation of well- engineered, modular upgrades to the software. Although IMOM was meeting the current needs of its user community, the Air Force was anticipating problems which would limit responsiveness to future user requirements.<p>
</a><a name="866327">
As indicated in <a href="ajpoinel.html#866880">Figure 6</a>, the translation of the baseline IMOM system from FORTRAN to C required 54 man months of effort. While most of the translation was accomplished using an automated translation tool, the final C implementation required a significant amount of "clean up" by the development team.<p>
</a><a name="866328">
By comparison (as shown in <a href="ajpoinel.html#866880">Figure 6</a>), the reengineering effort of the baseline IMOM capability from FORTRAN and C to Ada required 72 man months of effort. Both phases of the project (translation and reengineering) used a 4-person staff of developers.<p>
</a><a name="866329">
The reengineering of the additional derivative models in Ada required a total of 20 man months for all three models. These models included the COMJAM, PASSIVE DETECTION, and RECCE models cited earlier.<p>
</a><a name="866330">
At first glance, the Ada IMOM reengineering effort appears to have required an additional 18 man months of effort to deliver the same basic capability as the FORTRAN and C IMOM implementations. This is definitely not the case. The reengineering project involved the design of an entirely new software architecture, as well as the development of highly modular, reusable Ada code. Basically, the reengineering effort was an investment in the future, with an expectation of leveraging off that investment to accommodate user needs in a more cost-effective and reliable manner.<p>
</a><a name="866331">
As evidence of the value and validity of that investment, the real payoff for the Air Force and INEL began to accrue with the implementation of the Ada versions of the additional models. The graphs in <a href="ajpoinel.html#866880">Figure 6</a> show the actual time required to implement each of the models in Ada (on the order of 5-6 man months per model). By comparison, if each model was reengineered from scratch, they each would have required a level of effort comparable to the baseline IMOM system - - on the order of 70+ man months per model. This is a clear validation of the payoffs to be achieved with a well-engineered software development effort, with a deliberate commitment to design for maximum reuse. Although no specific metrics were collected for reengineering the additional models in any language other than Ada, INEL believes that it would have required significantly more time to implement them using FORTRAN or C. The end result is that, without the application of sound software engineering methods, including a layered, object-oriented software architecture and Ada, each of the additional models would likely have required the same number of man months as the original reengineered IMOM implementation.<p>
</a><a name="866332">
From a user perspective, the reduction in man months for each new model has important ramifications: The "time to market" or fielding of these critical capabilities can make an enormous difference in terms of lives and equipment or combat pilots and military mission planners. This factor is critical for most organizations, in both military/government and commercial markets.<p>
</a><a name="866333">
Actual tracking of IMOM project files showed that an interim release of the reengineered Ada implementation contained 20% fewer defects than the C baselines. Members of the development team attributed the use of an object-oriented design and Ada as major factors in the reduced number of defects. The reduced defect rate was achieved even with the shorter development time for the Ada implementations.<p>
</a><a name="866879">
<center>
<img src="ajpoinel.anc6.gif">
</center><p>
</a><a name="866880">
<center><h3>Figure 6 Translation and Reengineering</h3></center>
</a><a name="866334">
<h4> Measures of Success -- The Maintainability Index</h4>
</a><a name="866335">
INEL's research study indicated that the use of well-engineered software architectures, combined with object-oriented analysis and design, and an implementation written in Ada, would result in software that was more maintainable than code which was developed using top-down methods written in other languages. INEL set out to verify that the expected results and benefits had been obtained.<p>
</a><a name="866336">
One of the most impressive and critical effects of the Ada reengineering effort was the impact on the measured maintainability of the code. As shown in the chart and graph contained in <a href="ajpoinel.html#866909">Figure 7</a>, the maintainability index of the IMOM Ada code was more than three times greater than the index for the equivalent functions written in FORTRAN or C. The information contained in <a href="ajpoinel.html#866909">Figure 7</a> is based on several software metrics which were collected and analyzed by the INEL development team, leading to the calculation of a "maintainability index" for the fielded software.<p>
</a><a name="866337">
INEL conducted a static analysis of the source code of the various FORTRAN, C, and Ada implementations. Using PC-Metric, a source code analysis program, the development team calculated the value of two widely known software metrics: Halstead's effort/module; and McCabe's cyclomatic complexity/module. These metrics were just two factors which INEL used to assess the maintainability of the IMOM family of software.<p>
</a><a name="866338">
Using the values from the Halstead and McCabe metrics, INEL then applied a set of field-proven polynomial metrics to calculate maintainability indices for each of the IMOM baselines. The polynomial metrics were developed at the University of Idaho and have been validated in the field by Hewlett-Packard (see notes in <a href="ajpoinel.html#866909">Figure 7</a>).<p>
</a><a name="866339">
Hewlett-Packard has set a "maintainability cutoff" of 65 on the maintainability index (the "HP Cutoff" shown on the chart in <a href="ajpoinel.html#866909">Figure 7</a>). Based on HP's experience with software in the field, a software package with a maintainability index of less than 65 is considered to be "difficult to maintain." HP's separate evaluation and independent use of the maintainability index verified that it was applicable for HP's software systems. INEL applied the maintainability index to the IMOM family of software systems to provide a comparison and perspective as to the maintainability of the Ada, FORTRAN, and C versions of the IMOM baseline. The FORTRAN and C versions showed an accelerated decline on the maintainability index, while the Ada implementations stayed constant. As the graphic clearly indicates, the FORTRAN and C versions of the IMOM software were becoming "more unmaintainable" as additional functionality was added. In contrast, the Ada versions of IMOM exceeded the HP cutoff value, and stayed virtually constant, even with additional functionality being added.<p>
</a><a name="866901">
<center>
<img src="ajpoinel.anc7.gif">
</center><p>
</a><a name="866909">
<center><h3>Figure 7 Maintainability Index History</h3></center>
</a><a name="866340">
<h4> Measures of Success -- Software Complexity</h4>
</a><a name="866341">
Tracking the trends indicated by the metrics, INEL documented a dramatic increase in the complexity of the FORTRAN-based models of IMOM. The trends in the FORTRAN models showed a nonlinear increase in software complexity as IMOM evolved from version 4.0 to 5.0, with a corresponding projection for continually worsening maintainability over the life of the application.<p>
</a><a name="866342">
For the C versions of the IMOM baseline, the complexity was roughly the same as the FORTRAN implementations. This rough equivalency is due in part to the fact that the C code was derived from the FORTRAN software, using the same basic software architecture. The vertical lines on the graph in <a href="ajpoinel.html#866909">Figure 7</a> indicate functional equivalency between the various language implementations of IMOM. For example, the FORTRAN version 4.0 is functionally equivalent to the C version 1.0, and the Ada version 1.0.<p>
</a><a name="866343">
The average cyclomatic complexity (a measure of the number of paths through source code) for the Ada IMOM baseline is slightly larger than 3, while it is more than 9 for the FORTRAN implementation. For the C version, the complexity metric is greater than 13. The several-fold increase in complexity for the FORTRAN and C versions in comparison to the functionally equivalent Ada code has a direct effect on the maintainability of the respective language implementations. As the graph in <a href="ajpoinel.html#866909">Figure 7</a> clearly shows, the maintainability of the FORTRAN and C code markedly decreases over time, while the maintainability of the Ada code stays virtually constant.<p>
</a><a name="866344">
The consistency of the maintainability of the Ada code indicates a significant reduction in the complexity of each individual module. Each IMOM baseline module written in Ada is smaller, simpler, and easier to read and understand than the equivalent programs written in FORTRAN and C. The bottom line benefit for personnel engaged in software maintenance and modifications is that less effort is required to understand the function and execution of each subprogram.<p>
</a><a name="866345">
The Ada IMOM version 2.0 has many more functional capabilities than version 1.0. Contrary to the trends of the FORTRAN and C implementations, the increased functionality in the enhanced Ada code has not increased the complexity of the code. The cyclomatic complexity of the Ada IMOM version 2.0 has the same relative magnitude as the Ada version 1.0, indicating that the modifications and maintenance of the code have had little impact on the complexity of the Ada software.<p>
</a><a name="866346">
The number of unique operators and operands in the Ada versions of IMOM greatly increased in comparison to the FORTRAN implementations. The number of unique operators were 1.8 times higher in the Ada IMOM version 1.0 than in the FORTRAN version 4.0, and there were 2.5 times as many unique operands in the same Ada version. The total number of operators and operands also nearly doubled.<p>
</a><a name="866347">
One of the primary reasons for the increase in unique operators and operands in the Ada code is that the Ada software has many more local variables, less globally accessible data, and passes many more formal parameters between modules. These facets, in turn, are "by-products" of the object-oriented design, and the layered reusable software architecture, where well-defined interfaces between objects, layers, and components are required. Basically, these characteristics of the Ada code reflect the application of the proven software engineering principles of modularity and information hiding.<p>
</a><a name="866348">
Even with the additional volume of code in the Ada version of the IMOM baseline, the Halstead estimated effort, as a complexity indicator, was 53% less for the Ada code than it was for the equivalent FORTRAN implementation. This is in spite of the fact that the Ada version has 63% more executable statements that the FORTRAN version, and more than four times as many subroutines. The fact that Ada source code, unlike many languages, is not terse, cryptic, or obscure, contributed significantly to the expanded number of statements and subroutines.<p>
</a><a name="866349">
The size of the Ada modules is much smaller than the modules written in FORTRAN and C. The FORTRAN IMOM baseline was comprised of about 334,000 lines of code, with the typical use of global data access and FORTRAN subroutines that is common with functionally decomposed software designs. By comparison, the Ada implementation was comprised of 213,000 lines of code, which means that the Ada modules, although more numerous, were also much smaller than the equivalent FORTRAN components. The reasons for the reduced lines of code in the overall systems include the following:<p>
</a><ul>
<a name="866350">
<li>A significant amount of code was shared between modules
</a><BR><a name="866351">
<li>More streamlined implementation of required functions
</a><BR><a name="866352">
<li>Changes in the functionality of the models
</a><BR></ul>
<a name="866353">
The smaller code modules in Ada offer additional benefits to the Air Force in terms of maintainability and modifiability. Smaller, easier to understand modules enable the use and exploitation of the reusable layered software architecture, with explicit support for the object- oriented design employed by the INEL development team. The Ada modules are easier to work with, test, and modify, thus facilitating the iterative software lifecycle approach chosen by the INEL team. The discrete and well-defined interfaces between modules prevents major surprises when the software is integrated and tested -- an area that is historically a major source of delays and problems and cost increases.<p>
</a><a name="866354">
Code modules of low complexity and size also have an impact on the effectiveness of all support personnel. Additionally, the number of people required to provide support, as well as the skill and experience of the support staff, are directly affected by the low complexity and size of the IMOM baselines. With small and easy-to-understand modules, new maintenance personnel can be brought up to speed very quickly, with minimal impact on the quality and responsiveness of support. Furthermore, with easy-to-understand code packages, highly skilled senior software engineers who are expensive and in short supply, can be much more productive and efficient. Less senior personnel can be used to conduct routine support, error fixes, and modifications to the code, freeing the senior staff to address more complex support requirements. Finally, fewer people are required to provide ongoing maintenance and support, with a corresponding reduction in resource allocation and funding.<p>
</a><a name="866355">
By comparison, the FORTRAN and C versions of IMOM, due to a significant degree to their much greater levels of complexity, are very challenging and difficult to maintain and modify. Safe and reliable maintenance and modification of the FORTRAN and C code requires the allocation of very experienced, very costly, and very scarce software engineering talent. Even senior and experienced personnel will require much more time to assimilate and understand the intricacies and complexity of the non-Ada implementations of IMOM.<p>
</a><a name="866356">
For both government/military and commercial organizations, the ability to allocate top software talent to areas with a higher return on investment (i.e., the design of new systems) can have a profound effect on the efficiency of operations. In military commands, where deployment of systems like IMOM to remote areas of the globe is common, the capability to maintain and modify critical software systems is often measured in terms of lives and equipment. Making software easier to maintain and modify with fewer people and with people who are less experienced provides an enormous return on investment.<p>
</a><a name="866357">
From an operational perspective, the combination of the layered software architecture, object-oriented design, and Ada has shown conclusively the effect of software as a "force multiplier" for the U.S. military. Without that working combination of technologies and methods, the benefits of the USAF/INEL reengineering effort would have been substantially reduced.<p>
</a><a name="866358">
INEL also studied the three additional electronic combat models which were implemented (RECCE, PASSIVE DETECTION, and COMJAM), to compare results on those derivative models. The trends discovered in the IMOM baseline also showed up in all three of the other models, including the following:<p>
</a><ul>
<a name="866359">
<li>The Ada version contained many more modules than the FORTRAN implementation. This is, to a significant degree, the result of a completely different software architecture being used for the well-engineered Ada versions of the models.
</a><BR><a name="866360">
<li>The Ada code modules were smaller in size than the FORTRAN versions. The smaller modules greatly facilitate the understanding and maintainability of the software. The modules are easier to comprehend, modify, and reuse.
</a><BR><a name="866361">
<li>Each of the Ada modules is much simpler than the FORTRAN modules, as measured by the cyclomatic complexity values.
</a><BR></ul>
<a name="866362">
<h4> Measures of Success -- Module Maintainability</h4>
</a><a name="866363">
To provide a more detailed examination of the complexity and relative maintainability of the various systems, INEL conducted another analysis using the same polynomial model cited earlier. For this analysis, however, instead of evaluating an entire model (i.e., all of the IMOM baseline), INEL calculated the maintainability index for each subroutine of each software baseline. In other words, each subroutine in the FORTRAN, C, and Ada IMOM baselines was evaluated, and a maintainability index calculated.<p>
</a><a name="866364">
Once each subroutine in each of the various IMOM baselines was evaluated and a maintainability index calculated, the modules were then categorized according to their respective maintainability values. Modules with a maintainability index of less than 65 (deemed unmaintainable by Hewlett-Packard) were categorized as "low." Modules with a maintainability index between 65 and 85 were ranked as "medium." Modules with a maintainability index higher than 85 were rated as "high."<p>
</a><a name="866365">
The numerical results of this analysis are shown in the table in <a href="ajpoinel.html#868062">Figure 8</a>, and are graphically depicted in <a href="ajpoinel.html#867241">Figure 9</a>. As the figures clearly show, the Ada modules in the implementations of the various IMOM models are substantially more maintainable than the modules written in either FORTRAN or C. Generally, nearly two-thirds of all of the Ada modules rank in the "high maintainability" category. Conversely, around half of all of the modules written in FORTRAN and C are rated as "low maintainability."<p>
</a><a name="868060">
<center>
<img src="ajpoinel.anc8.gif">
</center><p>
</a><a name="868062">
<center><h3>Figure 8 IMOM Family Software Subprogram Index Count</h3></center>
</a><a name="866366">
The information depicted in <a href="ajpoinel.html#868062">Figure 8</a> and <a href="ajpoinel.html#867241">Figure 9</a> also demonstrate the downward trend in maintainability as the FORTRAN and C versions were modified and additional functionality was added. In both the FORTRAN and C implementations, the number of modules which fell into the "low maintainability" category increased over time. Conversely, the number of Ada modules which were rated for high maintainability remained relatively constant over time and with additional functionality. The INEL development team attributed the benefits of the Ada versions of IMOM to the emphasis on sound software engineering, the use of the layered software architecture, the application of object-oriented design, and the stability, clarity, and software engineering support of Ada.<p>
</a><a name="867240">
<center>
<img src="ajpoinel.anc9.gif">
</center><p>
</a><a name="867241">
<center><h3>Figure 9 Module Maintainability Percentages</h3></center>
</a><a name="866367">
<h4> Software Reuse</h4>
</a><a name="866368">
Software reuse does not enjoy a commonly accepted definition. Basically, "reuse" means many different things to different people, depending on their area of expertise, technical background, etc. The premise and promise of software reuse has been analogous to a technical "holy grail" for many years. The DoD and other government agencies, as well as major commercial enterprises, have pursued high degrees of software reuse as a means of lowering software costs, increasing productivity, improving reliability, and leveraging investments in software. Unfortunately, the promise of software reuse has not been widely attained, due to a variety of factors and impediments.<p>
</a><a name="866369">
The INEL development team was able to amply demonstrate that software reuse is not a myth, and that significant levels of reuse can be obtained, with corresponding benefits to both developers and users. As a foundation for obtaining substantive reuse, the underlying software architecture and software design is critical. The INEL team designed the Ada IMOM baseline with reuse in mind, with the expectation of reusing significant amounts of code as new models were added to the IMOM family.<p>
</a><a name="866370">
The layered software architecture in <a href="ajpoinel.html#866782">Figure 5</a> was a key element in the attainment of high degrees of reuse in the reengineered Ada implementations of the IMOM family of models. The INEL development team, knowing that additional models and functionality would be required beyond the initial IMOM baseline, planned their software architecture accordingly. They structured the layers to enable high levels of reuse within the domain-specific portions of the IMOM applications, and used the layered "application frameworks" to leverage their investment in common interfaces.<p>
</a><a name="866371">
For example, by planning for and designing the system for reuse, INEL was able to develop common user interfaces (man-machine interfaces, or MMI) which could be reused for all of the IMOM models. Because of the structured, object-oriented layers of their design, the development team was able to simply concentrate on the engineering algorithms of each new model or function (RECCE, PASSIVE DETECTION, AND COMJAM), without concern for the underlying software architecture and MMI.<p>
</a><a name="866372">
The layers depicted in <a href="ajpoinel.html#866782">Figure 5</a> also provide insight into the "type" of reuse attained. Basically, reuse can be separated into two general categories: domain specific and general purpose. Using the "Application Layer" in <a href="ajpoinel.html#866782">Figure 5</a> as an example, there was significant reuse across that layer (in other words, horizontally on the chart) which was domain specific to the IMOM models. INEL achieved high levels of reuse in both the domain specific and general purpose layers of the ECSI effort.<p>
</a><a name="866373">
The middle layers shown in <a href="ajpoinel.html#866782">Figure 5</a> were analogous to "application generators" and were reused throughout every layer (or vertically on the chart). For example, the "Interface Layer" on the chart provided reusable code which could be applied throughout the vertical range of layers. These generic reuse capabilities can provide powerful advantages for users and development teams, for requirements such as mapping tools. By reusing the common constructs for maps (i.e., bearing, heading, coordinates, etc.) the INEL team has established a generic mapping tool with a general applicability for a wide variety of domains By using this tool, a developer would be able to quickly produce a capability equivalent to a software program of 50,000 to 100,000 lines of code. The tool has the additional advantage of being comprised of code which has already been tested and fielded.<p>
</a><a name="866374">
Generally, INEL realized a "reuse rate" of 65%, which means that 65% of the Ada code modules were reused in one or more applications. The savings which resulted were impressive: without that level of reuse, each of the three IMOM models (other than the baseline) would have required at least another 100,000 lines of new code. Stated another way, a less structured and disciplined approach would have necessitated a minimum of 300,000 lines of additional new code development.<p>
</a><a name="866375">
The impact on productivity and "time to market" is the most obvious benefit of the reuse rates achieved by the development team. There was also a substantial benefit which accrued due to the reduction in testing and integration, since the reused modules had already been through that process. The reduction in risk, due to the virtual elimination of the new errors that would have occurred with the development of new code, was also noteworthy.<p>
</a><a name="866376">
The bottom line for the reuse of Ada code in the various IMOM models can be summed up with this observation by a representative of the INEL development team:<p>
</a><a name="866377">
"Due to the insight and foresight of the Air Force, we were encouraged to apply sound software engineering rigor and discipline. We were allowed to apply the appropriate methods in the up-front engineering of the system, to ensure a payoff to users in the future. If we had not been able to design for reuse, and actually take advantage of reused Ada code on this project, each of the derivative models would have taken significantly more time to develop. The results achieved on ECSI are a validation of the benefits and return on investment which can be realized by applying a soundly engineered mix of technologies and methods."<p>
</a><a name="866378">
If a poor process had been employed for ECSI, and sound software engineering had not been used, each of the three additional models (COMJAM, RECCE, and PASSIVE DETECTION) would have required 72 man months of development time, for a total of 216 man months. By taking advantage of Ada code reuse (in support of the engineering process used by INEL), all three of those models were implemented in a total of 20 man months - - less than one-tenth of the time required without reuse.<p>
</a><a name="866379">
As most software engineers and managers know, reuse can be achieved with software designs, as well as actual code. One of the highest payoffs can be achieved by reusing software designs, including object-oriented designs. INEL recognized during the analysis phase of their effort that each of the four IMOM models had a wide variety of components which could be shared among the models. Each of the applications contained common or similar user interfaces, modeling algorithms, graphics, and electronic components.<p>
</a><a name="866380">
During the design phase, the development team focused on determining the appropriate abstraction for each object class and its respective role within each IMOM model. The level of reuse for each object was directly linked to its role within the various models. Some object classes had the potential for reuse outside the electronic combat application domain, others could be shared by two or more of the IMOM models, and others were highly specialized and specific to a particular role within a single model.<p>
</a><a name="866381">
By evaluating the specificity of the various object classes, the INEL development team was able to make decisions as to when to design for broad reuse (i.e., outside the electronic combat domain) and when to limit the design to a specific IMOM model. The development team discovered that most object classes in the IMOM domain were conceptually the same, although their characteristics and roles within each of the models were different. When those differences were relatively minor, an object class was designed which would meet the multiple requirements. Even with the broader requirements, this approach added little additional complexity to the object classes.<p>
</a><a name="866382">
The results of this approach were impressive. Interim releases of the four IMOM models indicate the benefits to be derived -- the four models in those releases had approximately 112 object classes, of which 73 were shared between two or more software systems. Each class had an average of 1,200 lines of commented source code. There were 11 algorithmic or interface libraries which are shared between the models.<p>
</a><a name="866383">
INEL discovered that reuse is not the general panacea which is often touted as a goal for software development. For certain types of problems, and within specific application domains, reuse can improve the quality of software and enhance the development process. The greatest reuse is possible when sharing objects within the same specific application domain by a single software development team. Beyond those parameters, object reuse is still quite difficult to achieve.<p>
</a><a name="866384">
<h4> The Benefits of Ada</h4>
</a><a name="866385">
Throughout this monograph, the benefits of Ada in terms of its explicit support for software engineering discipline and object-oriented design have been cited as major factors in the success of the USAF/INEL project. The Ada language features provided excellent support for the implementation of the layered software architecture, as well as the attainment of significant levels of code reuse. Furthermore, Ada's strong typing, parameter checking in subroutine calls, and array constraints contributed to the benefits achieved in the ECSI program.<p>
</a><a name="866386">
In addition to these powerful attributes and benefits, the clarity of Ada source code and the benefits of that characteristic must be specifically cited. The names of variables used in the Ada IMOM baseline are more descriptive of the actual items or phenomena being represented than comparable representations in the FORTRAN version. The FORTRAN baseline used primarily six-character identifiers for variables and subroutine names, a limitation which was carried over to the C-based translation.<p>
</a><a name="866387">
The descriptors in the Ada version allowed the "real world" to be more accurately represented in the actual source code. The C version of the IMOM baseline was just as terse as the FORTRAN version, due to the fact that the C code was translated from the FORTRAN and retained the same brevity for variable names. C has earned a reputation for being more terse than other programming languages, so it can reasonably be expected that a new version of IMOM written in C would still include terse names for variables.<p>
</a><a name="866388">
The additional clarity of the Ada source code pays substantial dividends in the areas of maintenance and modification of the software. Maintenance personnel are able to relate or "tie" Ada source code to design documents and change requests more effectively and efficiently than with comparable FORTRAN and C implementations. The clear and descriptive nature of variable names in Ada help significantly in reducing error rates and the introduction of new defects during code maintenance and modification operations.<p>
</a><a name="866389">
Ada's package construct also supports the use of layered, object- oriented, flexible software architectures. The Ada package basically consists of two parts: the package specification and the package body. The specification part of the package enables a sound engineering implementation of the software requirement, through its support of encapsulation, information hiding, abstraction, etc. Interfaces between packages are specified and verified before the package body is written. The inputs, outputs, and assumptions for each package are clearly delineated and established.<p>
</a><a name="866390">
The package specification provides a great deal of information to maintenance personnel, akin to a high-level summary of the characteristics of the package. In addition to defining module interfaces, package specifications also offer essential insights to the humans who must be able to understand the inner workings of the software modules to be able to maintain and modify the code in a reliable, cost- effective manner. Neither FORTRAN nor C provide any comparable capabilities to the Ada package specification.<p>
</a><a name="866391">
The clarity of Ada source code (Ada code is written in English, as opposed to obscure symbols and other representations, and resembles a structured English outline), combined with the structured nature of its package specifications, has a profound effect on documentation and software reuse. By minimizing the complexity and size of Ada code modules, Ada software implementations become virtually "self documenting" due to the explicit representation of the function and interfaces of the respective modules. The extensive information included as part of the package specification enables developers to ascertain the potential for the reuse of existing modules in other applications, without having to delve into the source code of the package body itself. The improvements in efficiency, accuracy, and productivity are substantial.<p>
</a><a name="866392">
The INEL development team discovered that the learning curve for Ada is far less than is generally perceived. The team was able to assimilate and apply fundamental Ada constructs within a minimal period of time. Furthermore, the team was able to use and apply engineering discipline and methods using specific features of the Ada language. As the INEL team noted, "You do not have to use all of the features of Ada to make effective use of the language."<p>
</a><a name="866393">
<h4> Ada and COTS</h4>
</a><a name="866394">
As mentioned in the Executive Summery policy requires the use of commercial off-the-shelf (COTS) software whenever they will satisfy requirements. For those applications where COTS is inadequate to meet DoD needs, new software must be developed in Ada. The USAF/INEL reengineering project had some valuable experiences in effectively applying that policy.<p>
</a><a name="866395">
Many of the "COTS or Ada" decisions for the IMOM models were obvious. For example, INEL did not want to write its own operating system, or its own version of Unix or Motif/X. Similarly, existing software interfaces or drivers to peripheral devices did not warrant the development of new Ada code. The flexibility of the layered object-oriented software architecture enabled the development team to mix and match the appropriate technologies and tools without sacrificing maintainability and the ability to add new functionality.<p>
</a><a name="866396">
To meet the requirements of IMOM users, the INEL team had to develop two "spin-off" products: the Data Stream Analyzer and FormBuilder. The Data Stream Analyzer was basically a generic parser which translated data from one format to another. This is a valuable and essential capability for IMOM users, since different sources provide data in different formats. The Data Stream Analyzer takes care of converting differing formats into one which can be accepted by the various IMOM models.<p>
</a><a name="866397">
In the case of the FormBuilder, the Air Force and INEL both knew that there were several COTS products on the market which provided the capability which was needed. The basic requirement was for an application programmers interface for developing Motif-based graphical user interfaces (GUIs). At first glance, it appeared that simply buying a COTS form-building tool would be the best choice for the Air Force, and in keeping with DoD policy. Fortunately for the Air Force (and the taxpayer), INEL went beyond a "first glance" evaluation.<p>
</a><a name="866398">
The INEL team used GKS (Graphical Kernel System) for a significant length of time on the ECSI project. Although GKS is a standard, the implementations of the standard by commercial vendors are not consistent. By using commercial product implementations of GKS, INEL and the Air Force were dependent on product changes and support from vendors, who were subject to commercial market influences and different business goals. This risk was realized by the development team when the vendor of the GKS product being used for the ECSI project suddenly decided to discontinue marketing and supporting their implementation. INEL also did not want the Air Force to be subjected to the additional cost of GKS runtime licenses, so the development team built their own graphics package, called FBGraphics.<p>
</a><a name="866399">
For the Motif-specific requirement, INEL discovered that many COTS form- building tools worked effectively, and provided the capability to develop GUIs for applications. However, the tools all generated substantial amounts of code which was Motif-specific. This Motif- specific code, while performing the GUI tasks required for an application, was not itself readable or maintainable. INEL was thus able to justify the development of a FormBuilder written in Ada, which did not have the overhead of licensing fees and the generation of unmaintainable code. The development team required only two months to develop the Ada-based capability.<p>
</a><a name="866400">
While the policy of "COTS first, Ada second" makes sense for many applications, there are significant "hidden" costs and other factors which need to be considered. For example, configuration management (CM) of an application can become a nightmare for program managers and maintenance personnel, if multiple COTS products are incorporated into a system like IMOM. As COTS vendors make changes and offer new releases, the impact of those changes can have serious and unforeseen effects on the rest of the system. If a fielded system uses several COTS products, the CM problems can be rapidly compounded over time.<p>
</a><a name="866401">
When evaluating a choice between COTS capabilities and new Ada software, decision makers must take into account much more than just the perceived "up front" costs. In the case of the IMOM effort, INEL only required two months to produce a capability which could have been superficially satisfied by a COTS product, but the COTS solution would have been a serious detriment to the maintainability and modifiability of the IMOM models over time.<p>
</a><a name="866402">
The IMOM family of models also required a database management system (DBMS) capability to meet user needs. In keeping with DoD's "COTS first" policy, it has become popular and common for program managers to pursue the use of commercial database management products, especially relational DBMS capabilities. For the ECSI effort, the INEL team evaluated the efficacy of using a COTS DBMS versus writing the appropriate capability from scratch. Their solution for DBMS for ECSI was straightforward and easy to maintain, and consisted of ASCII flat files. This solution met user needs, and saved the Air Force substantial time and development resources.<p>
</a><a name="866403">
<h4> Dual-Use Potential</h4>
</a><a name="866404">
Since the software developed for the IMOM models has been paid for by the U.S. Government, some of it is "in the public domain" and available for use by other government agencies and private enterprises. Some of the code has obvious commercial applicability and reuse potential, while other pieces of the IMOM applications are limited to specific domains. Clearly, the Data Stream Analyzer and FormBuilder tools are ideally suited for commercialization and exploitation by private companies. Similarly, other government organizations can derive substantial benefits from the use of these "free" tools.<p>
</a><a name="866405">
The user interfaces and graphical capabilities of the IMOM implementations have widespread generic applicability. The point and click nature of the user interface, along with the color capabilities of the various representations, are common features in most modern commercial systems.<p>
</a><a name="866406">
As an example of possible dual-use applicability, the generic mapping "application generator" cited earlier could be used by some commercial developers. Commercial developers who require basic mapping functions, as well as state and local governments engaged in economic development programs, are examples of organizations who could benefit from mapping software which is well engineered and implemented in an international standard programming language. Other industries, such as aviation, marine, oil exploration, and land management/industrial planning operations could also make use of this generic capability.<p>
</a><a name="866407">
By virtue of the partnership between the Air Force and the Department of Energy's INEL, the process of dual use has already begun. The INEL has, as part of its mission, the transfer of technology to the commercial sector. The significant software capabilities embodied in the IMOM models offer valuable features and benefits for commercial exploitation and use.<p>
</a><a name="866408">
<h4> Summary</h4>
</a><a name="866409">
The IMOM reengineering project provides valuable lessons for both government and commercial software developers and decision makers. As modern systems continue to grow in size and complexity, the critical nature of well-engineered software in the success and survival of virtually all organizations is becoming more pronounced. The intelligent selection and application of sound methods and technologies are essential facets for progress.<p>
</a><a name="866410">
Key decisions related to the migration from legacy systems to more powerful distributed client/server architectures require sound justifications. The cost of maintaining and modifying legacy software is a critical factor in justifying a reengineering effort. The "hidden" costs of providing adequate capabilities to the user base are often substantially higher than the explicitly measured costs of support.<p>
</a><a name="866411">
The IMOM reengineering project provided conclusive lessons as to the importance of software architecture in achieving significant software- related benefits. The program also showed that the application of object-oriented methods, in the context of a disciplined software engineering process, can deliver major gains in reuse, productivity, and maintainability.<p>
</a><a name="866412">
Finally, the IMOM reengineering effort showed the value of Ada in obtaining maximum payoffs from an investment in software engineering practices. The benefits achieved in applying sound software engineering principles were multiplied by the explicit support that Ada provides for that disciplined approach. Simply stated, the magnitude of the benefits obtained would have been substantially lower if another programming language had been used.<p>
</a><a name="866413">
The IMOM formula for success was: Good people, with knowledgeable managers, applying sound software engineering methods, implementing in Ada, with the needs of the user as the objective. That formula works for all segments of the global software community.<p>
</a><a name="866414">
<h4> Bibliography</h4>
</a><a name="866415">
[Colman92]. D. Coleman, "Assessing Maintainability," 1992 Software Engineering Productivity Conference Proceedings, Hewlett-Packard, 1992, pp. 525-532.<p>
</a><a name="866416">
[INEL91]. Idaho National Engineering Laboratory, "Improved Many-On-Many (IMOM) Model Research Study," EGG-EE-9555, Rev. 0, May 1991.<p>
</a><a name="866417">
[Oman92b]. P. Oman and J. Hagemeister, "Construction and Validation of Polynomials for Predicting Software Maintainability," Software Engineering Test Lab, Report #92-06 TR, University of Idaho, July 1992.<p>
</a><a name="866418">
[Welker93]. K. Welker, M. Snyder, and J. Goetsch, "Ada Electronic Combat Modeling Experience Report," Presented at OOPSLA `93.<p>
</a><a name="866419">
[Welker94a]. K. Welker, "Application of Software Metrics to Object- Based, Reengineered Code Implemented in Ada," Masters Thesis, University of Idaho, April 1994.<p>
</a><a name="866420">
[Welker94b]. K. Welker and M. Snyder, "Electronic Combat Model Reengineering," ECSI Project Briefing Slides, 1994.<p>
</a><a name="866425">
<h1></h1>
</a>
<hr><p><a name="867733">
For additional copies of this monograph, please contact the Ada Information Clearinghouse:<p>
</a><a name="867536">
The views, opinions, and findings contained in this report are those of the author(s) and should not be construed as an official Agency position, policy, or decision, unless so designated by other official documentation.<p>
</a><pre><a name="866431">The AdaIC is sponsored by the Ada Joint Program Office and operated by IIT
Research Institute.
</a></pre>
<hr>
<hr>
<BR>
Ada Information Clearinghouse (AdaIC)<BR>
P.O. Box 1866<BR>
Falls Church, VA 22204<BR>
Phone 1-800-AdaIC-11 (232-4211) or (703)681-2466<BR>
FAX (703)681-2869<BR>
WWW http://sw-eng.falls-church.va.us<BR>
Email <a href="mailto:adainfo@sw-eng.falls-church.va.us">adainfo@sw-eng.falls-church.va.us</a><BR>
<BR>
Mr. Michael W. Snyder<BR>
Idaho National Engineering Laboratory (INEL)<BR>
P.O. Box 1625, Mailstop 3818<BR>
Idaho Falls, ID 83415-3818<BR>
Phone (208)526-2624<BR>
Email <a href="mailto:swm@inel.gov">swm@inel.gov</a><BR>
<BR>
<!-- This file was created with Quadralay WebWorks Publisher 3.0.8 -->
<!-- -->
<!-- For more information on how this document, and how the rest of -->
<!-- this server was created, email adainfo@sw-eng.falls-church.va.us -->
<!-- -->
<!-- Last updated: 10/14/96 13:22:07 -->
</body>
</html>
]]>