We wish to thank our faculty colleagues in the Administrative Sciences Department at the Naval Postgraduate School who contributed so heavily to this report. Despite short notice and a hurried project schedule, they were able to devote substantial time to the interviewing and research that went into the preparation of the report. Each faculty member contributed to the overall report, but also focused on an important technical aspect of the study. The faculty and their primary area of investigation are as follows:
Prof. Tarek Abdel-Hamid Cost-effectiveness issues Prof. Tung X. Bui AI/DSS and end-user computing Prof. Magdi Kamel Database management systems Prof. Kishore Sengupta STANFINS-R case study Prof. Dani Zweig Code reuse
LCDR Jeff Schweiger provided first-rate technical and administrative support for the project; he was especially helpful in compiling the bibliography that accompanies this report. Essential secretarial assistance was given by Rose Mendoza and Eva Long. Prof. David Whipple, Chairman of the Administrative Sciences Department, was a source of valuable support and encouragement. To Jan Evans, Support Staff Supervisor of the Department, fell the unenviable burden of dealing with the myriad administrative and fiscal tasks encountered during the course of the project.
We are very grateful for essential assistance given to us by numerous persons in the Office of the Secretary of Defense and other DoD services and agencies, industry representatives, and members of academic institutions. Without exception, they gave us their enthusiastic support and time. Several of them were generous enough to attend a review meeting at the Naval Postgraduate School. Whatever faults the final report may have -- for which we and our participating faculty colleagues take full responsibility, of course -- the results have been immeasurably improved by their help.
I. MANAGEMENT SUMMARY.......................................... 1
II. BACKGROUND ISSUES.......................................... 7
A. The Critical Role of Information Technology in DoD.... 7 B. Problems in Applying Information Technology........... 8 C. Trends in MIS Applications............................ 9 D. Need to Improve Management Information Systems........ 10 1. Improving information systems planning............. 11 2. Building a sound enabling infrastructure........... 11 3. Improving the software development process......... 11 4. Reducing software maintenance problems............. 12III. THE SOFTWARE IMPLEMENTATION PROCESS...................... 13
A. The Sequential Development Process................... 13 B. Improvements in the Conventional Third-Generation Process ............................................. 15 C. Fundamental Changes in the Development Process....... 16 1. Human resources.................................... 17 2. Development methodology............................ 17 3. Development tools.................................. 18 D. High-Productivity Environments....................... 19 1. The 3½GL environment............................... 19 2. The 4GL environment................................ 20IV. THE PROGRAMMING LANGUAGE ADA.............................. 25
A. Characteristics of Ada............................... 25 B. The Current Status of Ada............................ 26 1. Signs of success................................... 26 2. Lack of widespread use of Ada...................... 27 C. Impediments to Increased Use of Ada in DoD........... 30 1. DoD support for Ada education...................... 30 2. Under-funding of Ada language improvements......... 30 3. User pays the incremental costs of implementing Ada 31V. COMPLIANCE WITH THE ADA MANDATE............................ 33
A. Conventional Programming and Maintenance in Ada, Aided by CASE Tools.................................. 33 B. The 3½GL Approach.................................... 34 C. Programming and Maintenance in a 4GL, with Translation into Ada ............................................ 35 E. Programming and Maintenance in a Problem-Specific Language ............................................ 37 F. Programming and Maintenance in a 3GL other than Ada.. 40VI. CONCLUSIONS............................................... 43
A1. STANFINS-R: A CASE STUDY ON THE USE OF ADA IN DEVELOPING INFORMATION SYSTEMS................ 53 A. Background........................................... 53 B. Execution of the Project............................. 54 C. Lessons Learned from the Project..................... 55 D. Reference............................................ 57 A2. ISSUES IN INTERFACING ADA WITH DBMS................ 59 A. Ada-to-SQL Binding................................... 60 B. Other Issues in Accessing Databases.................. 62 C. Conclusions.......................................... 63 D. References........................................... 63 A3. CODE REUSE.......................................... 65 A. The Costs of Reuse................................... 66 B. The Scope and Granularity of Code Reuse.............. 67 C. Maintenance.......................................... 68 D. Industry Experience.................................. 69 E. Conclusions.......................................... 70 A4. COST-EFFECTIVENESS ISSUES.............................. 73 A. Non-Deployment Opportunity Cost...................... 74 B. Aggregate Post-Deployment Issues..................... 75 C. Development and Acquisition Cost Issues.............. 76 D. References........................................... 82 A5. PROGRAMMING LANGUAGE OPTIONS FOR THE DEVELOPMENT OF AI/DSS AND END-USER APPLICATIONS.... 83 A. Artificial Intelligence, Decision Support Systems, and End-User Computing................................... 83 B. Programming Language Options for AI Systems.......... 84 C. Programming Language Options for DSS................. 87 D. Programming Language Options for End-User Computing E. Conclusions.......................................... 89 F. References........................................... 90 A6. REVIEW OF PRESENT PROGRAMMING LANGUAGE POLICIES IN DOD ............................................ 91 A. Air Force Policy...................................... 91 B. Army Policy........................................... 93 C. Ada Waiver Policy Working Group....................... 94IX. BIBLIOGRAPHY.............................................. 97
I. MANAGEMENT SUMMARY
Management information systems (MIS) are gaining an increasingly important role in the activities of the Department of Defense (DoD). As a result, the effective implementation of these systems has become an important issue within DoD. Success in developing an MIS requires getting a lot of things right: sound information systems planning, a supporting infrastructure that facilitates the integration of an application with other parts of the system, and a powerful software development environment.
The choice of programming language for MIS applications is an important aspect of any effort aimed at improving the software development process. The programming language Ada has earned a solid record within DoD as a valuable contributor to advancing software engineering practices. Congress has now mandated the use of Ada, "where cost effective," for all new applications, including MIS. In order to administer this mandate, DoD must establish policies and guidelines for defining the circumstances under which a programming language other than Ada may be used.
This report is intended to provide objective background information for formulating Ada waiver policies. Some of the positions taken are likely to be controversial. Our conclusions and recommendations are based on our best professional judgments, made after considerable discussion with interested parties and a review of the available evidence.
Almost everyone agrees that current implementation practices for MIS do not work very well. By far the most serious barriers to progress come from software, not hardware. Many of the existing software problems -- high development and maintenance costs, delayed delivery schedules, failure to meet real user needs, and inflexibility -- stem in major part from the intrinsic limitations of the conventional implementation process. A serious attack on the growing "software crisis" must bring about basic changes in the way systems are built and maintained.
We are beginning to see some major advances in software development technology. The formulation of sound Ada policies must take account of these advances that have emerged since Ada was introduced about a decade ago. The substitution of Ada for other third-generation languages (3GLs) will not ease the software crisis very much unless accompanied by other fundamental changes.
A contemporary MIS depends heavily on a massive shared database; a productive development environment must therefore provide the means to link the MIS to a full-featured database management system. It must similarly provide productive ways to manage a communications network, build effective user interfaces, generate a variety of tailored reports, and deal with the sundry tasks commonly associated with an MIS. Ada's attractiveness for MIS applications can be significantly increased through the support of state-of-the-art computer-assisted software engineering (CASE) tools and a comprehensive set of reusable Ada packages for performing common MIS functions. DoD should therefore foster the development and deployment of such an environment.
It cannot be stressed too much that the potential gains from the development from productive tools cannot be realized without competent professionals trained in sound software engineering practices. The availability of good people using good practices dominates all other sources of improvements. Trained personnel are in short supply, due in part to DoD's lack of commitment and resources devoted to strong educational programs in software engineering. Management practices, too, must be improved to motivate and coordinate team members.
It may be possible to achieve an even greater improvement -- perhaps as much as a tenfold increase in productivity under the right conditions -- through the use of one of the integrated "fourth-generation languages" (4GLs) now appearing on the market. With proper management, the productivity gains achievable during an application's initial development can continue throughout its entire maintenance life. Relatively little experience exists to support a major commitment to and integrated 4GL, but the evidence is already favorable enough to justify a serious exploratory effort to apply 4GL technology within DoD. Delaying action until iron-clad evidence is at hand would take several years, at the cost of further compounding the software crisis.
In order to achieve dramatic productivity gains, a 4GL must enable the developer to define the complete design of an application entirely in the 4GL's own high-level specification language. The specification is then translated automatically by the 4GL into an executable program. Any change to the application, during either its initial development or maintenance phase, is made in the specification language, which then gets re-translated into a running program. For various technical reasons, 4GLs suitable for heavy-duty use generally translate the high-level specification into an intermediate procedural language. It appears that at least some of the new 4GLs will be able to generate Ada code, thus increasing the portability of the application.
A highly productive development environment goes a long way toward correcting the deficiencies in many current information systems. The advantage is not simply a matter of reducing the time and cost of developing and maintaining a system; it can also significantly enhance the effectiveness of an MIS. A productive development process makes it feasible to adapt the MIS to changing needs during the course of implementing and operating the system. It is only through such adaption and continual enhancements that an MIS can be made truly effective.
DoD policies should encourage the use of a productive software development environment. Traditional methodologies should be discouraged, whether or not the programming is done in Ada. DoD should pursue an active program for selecting and applying the best CASE tools and 4GLs. Present development and documentation standards should be examined carefully, with the view of adapting them to the power and flexibility of the new development tools. Personnel policies -- hiring, training, compensation, and career development -- should be modified to meet DoD's increased need for talented, well-trained, and motivated technical personnel.
The transition to a new development environment raises some difficult management issues. Despite its high potential payoff, the move is not without risk. The greatest danger is that the shift to new tools will not be accompanied by other necessary changes in the development methodology and the composition of development teams. Failure to make the necessary adjustments would almost certainly lead to disappointing results. Use of a variety of CASE tools and 4GLs also creates some new problems of training and long-term support. If properly managed, though, risks and complexity can be kept to manageable proportions. The potential benefits more than justify taking on some prudent risks and management challenges.
DoD must establish policies for dealing with end-user computing. Ada was designed as a powerful general-purpose procedural language, and as such it is not suitable as an end-user language with which a typical user could program his or her own application. Most end-user computing will require the use of a user-friendly language aimed at a specialized problem domain -- a spreadsheet language for simple analytical or presentation tasks, say, or a database management tool for small administrative applications developed on a micro-computer or workstation. This approach meets the Congressional mandate, because it often provides by far the most responsive and cost-effective means of satisfying the myriad small computing needs that crop up throughout DoD. When end-user computing is properly managed and supported, the risks of duplication, unverified outputs, and unmaintainable code can be controlled. Excessive constraints on such computing would effectively deny many users the benefits of supportive applications of information technology. Similar issues arise with the use of special-purpose languages for solving particular classes of problems. Decision support systems and expert systems, for example, are almost always programmed -- for good reasons -- using one of the special-purpose languages aimed at these problem domains. Ada policies should recognize the legitimacy of this form of computing.
Failure to capture the enormous productivity gains offered by modern software technology carries its own risks -- the far greater, but perhaps less obvious, risk of continuing on the same path that has led to today's software crisis. DoD cannot meet its software needs for effective MIS without making fundamental changes in the way software is developed and maintained.
With this objective in mind, we recommend DoD take the initiatives or actions given below. A more detailed discussion of these recommendations is presented in Section VII.
In the 1991 Defense Appropriations Bill, Congress mandated the use of Ada as the standard computer programming language for all new software applications developed within the Department of Defense, "where cost effective." The mandating legislation thus contemplates that a waiver from the use of Ada can be granted in some circumstances. The purpose of this study is to provide a reasoned, objective discussion of the important issues and principles connected with the formulation of DoD waiver policies for the implementation of management information systems (MIS). This section discusses important background issues that bear on setting DoD computing strategies.
A. The Critical Role of Information Technology in DoD
We are rapidly moving from an era of information scarcity to one of abundance. Until very recently, information processing was expensive, time consuming, and error prone; in comparison, it is now cheap, fast, and reliable. Because of these changes, the use of information processing often offers the most attractive means for the Department of Defense to increase its military effectiveness and reduce its use of capital resources and personnel.
The importance of information technology is widely recognized within DoD. This is manifested in the growing proliferation and power of "smart" weapons and sophisticated command and control systems that proved their worth so dramatically in Operation Desert Storm. Information technology is similarly essential for administrative applications. Any fundamental improvements in the efficiency and effectiveness of managing the military services -- in logistics, human resource management, financial control, and the like -- will almost certainly require the effective use of computer-based systems.
DoD has recently committed itself to a major cost reduction program that relies heavily on improved management through the use of management information systems.
B. Problems in Applying Information Technology
The exploitation of information technology within DoD has not been without problems. Requirements from users for additional functionality and integration have grown at a more rapid rate than can be satisfied by existing software engineering practices. As a result, software now constitutes by far the most serious bottleneck to exploiting information technology. Without major improvements in the process of developing and maintaining software, the "software crisis" can only grow worse.
This report is concerned with management information systems, or MIS. (The term automated information systems, AIS, is also used within DoD, and has essentially the same meaning as MIS). An MIS deals with administrative matters in such areas as logistics, procurement, personnel, and financial planning and control. Command, control, communications, and intelligence (C3I) systems tend to have characteristics that fall between embedded systems and MIS, and therefore many of the principles that apply to MIS also apply to C3I systems.
The GAO and others have pointed out the problems encountered in developing and maintaining MIS within the Federal government. A high proportion of development projects suffer from one or more of the following problems:
In short, existing practices have been unable to deliver the systems users want at the cost they expected to pay. The software backlog continues to swell and legitimate needs go unsatisfied.
C. Trends in MIS Applications
A number of trends in management information systems, both in the private sector and within DoD, are adding to the complexity of the task of delivering and maintaining effective systems. The following MIS trends are among the more important ones:
Most of these trends apply to embedded systems as well as MIS, but often to different degrees. For example, the management of a massive database typically plays a more prominent role for an MIS than it does for an embedded system.
D. Need to Improve Management Information Systems
It is widely recognized that major improvements are required in the process for developing management information systems. It is important to keep in perspective that the choice of a programming language is only one part of an organization's overall approach to deploying information systems (IS). Major improvements in DoD's management information systems have to come from an attack on four fronts: improve information systems planning, build a sound enabling infrastructure, improve the software development process, and reduce software maintenance problems.
1. Improving information systems planning.
IS strategic planning is concerned with establishing a broad blueprint for using information technology as a contributor to the goals and missions of an organization. The planning provides a basis for identifying information requirements and setting priorities among competing uses of resources. Without a unified strategy, there can be no assurance that the disparate parts of the information system will fit together and contribute most effectively to achieving the organization's mission.
2. Building a sound enabling infrastructure.
The IS infrastructure provides the building blocks that permit the efficient development of individual applications. Its principal components are:
3. Improving the software development process.
The ultimate payoff from good high-level planning and a sound infrastructure comes from an organization's ability to implement applications within budget, on time, and with required functional capabilities. It is here that many organizations stumble. Emerging new development methodologies promise to make a major contribution to improving the situation. These are discussed in the next section.
4. Reducing software maintenance problems.
In DoD, as in most large organizations, software maintenance typically consumes two-third or more of an organization's systems analysis and programming resources. As a result, DoD is caught in a vicious circle in which available resources are drained away in maintaining old (and often mediocre) software, leaving few resources left over to make fundamental improvements. Only a relatively small portion of this "maintenance" effort is aimed at correcting defects; most of it goes into making relatively minor enhancements stemming from changes in technology or mission needs.
Achieving more successful MIS calls for some major improvements in the software implementation process. This objective can be attacked along two lines: 1) by refining the existing process, or 2) by making fundamental changes in the process. These are not mutually exclusive approaches: there is certainly room for refining the existing methodologies while simultaneously pursuing efforts to make major improvements.
A. The Sequential Development Process
The widely practiced methodologies for developing systems have not changed much since the widespread use of 3GLs back in the Sixties. Since then, methodologies have been tuned and become more disciplined, but without altering the fundamental nature of the development process.
The key idea behind the conventional systems development life cycle (SDLC) is a sequential -- also called "waterfall" -- development process. The process proceeds from stage to stage, with each stage being completed before continuing on to the next one. The typical SDLC begins with a feasibility study, then continues through requirements analysis, gross design, detailed design, programming, test, conversion, and operations (with its accompanying maintenance). Different names may be used for the various stages, but all conventional methodologies approach the implementation task in essentially the same sequential manner.
Various schemes have been developed to manage this process. Elaborate procedures are imposed to document the output of each stage and to verify that the required work has been done. The team composition tends to change with each stage, and so the documentation serves the additional role of coordinating across stages and assigning responsibility for the correctness of the work done at each stage.
To adhere to a rigid sequential process, requirements must be established up front and frozen thereafter; the subsequent stages merely implement these fixed requirements. This may work satisfactorily for well-understood applications in which requirements are not likely to change much during the course of implementation, but overwhelming evidence suggests that few organizations are able to establish a satisfactory set of stable requirements for an MIS application. A large project may take several years to implement, and by that time the world has changed significantly. The inflexible waterfall process cannot take advantage of the learning and changes that take place during the course of the development. Furthermore, the abstract nature of requirements specification, in which users are asked to "sign off" on voluminous paper documentation, almost guarantees that any system meeting the formal specifications will not meet the real needs of users. The flexibility of the process within DoD is further limited by standards for documentation and milestone reporting that are based heavily on the sequential waterfall process.
In view of these well-recognized problems, it is not surprising that in practice the sequential model is generally violated to one degree or another. Corrections in early decisions are certainly made when critical errors or omissions are discovered downstream. Furthermore, we are now seeing increased use of other development models that recognize the need for greater flexibility than the pure sequential model allows. The "spiral" model, for example, specifically calls for the reexamination of design decisions to incorporate later learning. Prototyping is becoming more widely used as a means of experimenting with alternative designs and presenting users with a concrete and understandable representation of an application. A design arrived at through this process can then be incorporated in formal requirement specifications with the expectation that the system will more closely meet real mission needs.
Unfortunately, the adaptability of an application is often limited by the tools used in its implementation. An application consisting of a million or more lines of code in a third-generation language, for example, usually cannot be modified without considerable effort. The cost of making a correction is generally quite high, and escalates rapidly as the process moves from stage to stage. As a practical matter, all but the most important changes are discouraged in the interest of economy and stability.
The problems of coordination grow rapidly during the programming stage when the size of the team typically expands rapidly in order to cope with this labor-intensive chore. With average productivity ranging from 10 to perhaps 40 lines of code per person-day, the total effort for a million-line program can easily exceed 100 person-years. In order to deliver an application of this magnitude within an acceptable period of time, a large number of programmers must be employed in the effort. Coordination becomes almost impossible for such a project without a closely controlled and relatively stable design specification.
The difficulties of coordinating the efforts of a huge team places an upper limit on the size of an application. To keep the team at a manageable size, a tradeoff must be made between the size of an application and the time needed to deliver it. Current MIS applications seldom exceed three or four million lines of code because of the inability of the conventional development process to cope with larger applications (to say nothing of the cost). As things stand now, software development is likely to place a definite constraint on DoD's ability to meet the increasing demands placed on its MIS applications.
B. Improvements in the Conventional Third-Generation Process
Since the first extensive use of 3GLs in the early Sixties, great effort has been spent in improving software engineering practices. The improvements have come in a number of forms:
To this list of important efforts to improve software development must be added the creation of Ada. Ada was designed to incorporate language features that foster good software engineering practices. Its use within DoD is beginning to provide significant payoffs from these efforts.
Without the improvements made in software engineering, organizations could not have tackled the large development projects that have become increasingly common in the commercial and government sectors. Unfortunately, however, demands have grown faster than application developers can satisfy the needs. As a result, most organizations, including DoD, have found themselves sinking deeper into the software quagmire.
In discussing these problems, it should be noted that it is difficult to separate the intrinsic limitations of 3GL technology from the way it is applied. A highly skilled programmer can achieve excellent productivity using the best current 3GL practices. Such a programmer tends to structure an application into logical, cognitively cohesive components that permit their consistent reuse throughout the design -- in effect, creating a "language" quite specific to the application. This calls for a relatively rare ability on the part of the programmer. Actual design practices generally fall far short of this ideal.
C. Fundamental Changes in the Development Process
Knowledgeable observers in the MIS field believe that fundamental changes must be made in the software development process if organizations are to meet the growing demands placed on software. As James Martin, a widely acknowledged authority on information systems, writes, "there is widespread agreement that IS organizations cannot continue to build computer software systems using traditional development techniques."
There is an emerging consensus that a new development paradigm, or model, is needed to replace the obsolescent third-generation process. Although the exact nature of the new paradigm is by no means clear, it is quite likely that major improvement requires an attack on the three principal components of any development paradigm: human resources, development methodology, and software development tools.
1. Human resources.
A great deal of experimental and anecdotal data suggest that getting the right development people with the right training and motivation is the single most important contributor to software quality and productivity. No improvements in methodology or tools are likely to provide a big payoff unless accompanied by a capable professional staff. Management must pay much more attention than it typically does to such matters as recruitment, training, pay scales, attractive career paths, and the development of a creative and empowering working environment.
2. Development methodology.
Existing 3GL methodologies place heavy emphasis on getting up-front requirement specifications right so that expensive changes can be avoided when flaws are revealed in the later SDLC stages. A successful new development paradigm must recognize the intrinsic impossibility of fixing stable requirements early in the life of a complex development project. The organization learns a great deal from the very act of creating an application. An effective methodology must actively solicit feedback to earlier stages in order to adapt the design to take advantage of organizational learning. The process must foster continual interactions with users throughout the entire life cycle, not just during the early requirements analysis stage. In this way, managers can continually refine their administrative practices as they learn during the course of a system's development and operation.
Interaction with users is greatly facilitated if design alternatives can be presented in the form of a concrete working prototype. The development environment should permit the iterative modification of a series of prototypes that eventually converge to a "final" production version (which thereafter undergoes a continuous process of enhancement during the system's operational phase). An evolutionary methodology of this sort is only feasible if the development environment is productive enough to develop and modify software far more quickly and cheaply than is possible with traditional methodologies.
3. Development tools.
A necessary condition for making significant improvements in the implementation process is the availability of software tools that greatly leverage the efforts of the human developers. Although these tools clearly do not provided a "silver bullet" for eliminating all software problems, they do provide essential support for a talented staff and a sound development methodology.
A really significant improvement requires more than the typical CASE product that automates only a relatively small part of the development process. Instead, an integrated set of tools is needed to support the entire systems design life cycle and provide "seamless" links across stages of the process. A critical component is a repository -- also called a dictionary or encyclopedia -- that provides a complete, common, authoritative, and consistent description of the enterprise's information systems. Included in the repository are such things as the names of all data elements, the complete structure of the database, processing modules, data flows among applications, screen and report formats, and security authorizations. To be most effective, the repository must be active -- i.e., any change in the system specification is made through a change in the repository, and then the change is automatically reflected throughout all components of the system. The repository becomes all the more valuable as the central focal point of development and maintenance if the information it contains can be assessed selectively through an interactive retrieval system.
D. High-Productivity Environments
Two alternative approaches can be used to achieve high productivity in the development process. One of these might be called the "3GL" approach, and the other the 4GL approach.
1. The 3½GL environment.
The 3½GL approach takes the best of contemporary tools and puts them together in a highly productive software engineering environment. The primary language within DoD would be Ada, as the 3GL most suited for producing very large, high-quality applications. Supporting the Ada programmer would be an integrated set of software tools that support the full life cycle development process. A heavy emphasis would be placed on sound software engineering practices and the use of the best contemporary design techniques, such as object-oriented design. A comprehensive repository and powerful database management functions would both be indispensable ingredients for the MIS development environment. Sound project management would coordinate activities throughout the life of the project.
The full power of the 3½GL approach comes with the systematic reuse of Ada packages. A well-designed suite of packages can serve as a repository of powerful extensions to Ada, greatly reducing the cost of implementing standard MIS functions. With this approach, Ada statements are used primarily to invoke the execution of the standard functions. For tasks not included in the repertoire of packages, the programmer can provide an Ada procedural specification. Experience suggests that it is a reasonable goal to generate over half of the code from reusable packages.
Such benefits from reuse cannot be realized without a substantial effort to develop reusable software and an infrastructure to support its reuse (Appendix A3). Reuse outside the boundaries of a project or work group is generally difficult to achieve. Merely putting components into an Ada package repository, for example, is not likely to lead to much reuse. In order to achieve widespread sharing, a significant effort would have to go into the design, development, and support of a repository of Ada packages that provide a close fit with the common tasks encountered in MIS applications.
Putting such a repository together would be a professionally demanding task -- equivalent, in fact, to designing a high-level language for the MIS domain. It is essential that the contents of the repository be carefully catalogued and indexed, so that the effort to locate a reusable component does not exceed the potential savings. Close attention has to be paid to the maintenance and updating of reusable components. The quality and documentation required for a reusable component are, in general, more demanding than for comparable component developed for a single application at a single site.
2. The 4GL environment.
In order to achieve maximum productivity using the 4GL approach, the product's language must be capable of specifying a complete application. The specification must then be translated automatically into an equivalent object program (possibly through an intermediate procedural language such as Ada).
One of the difficulties in discussing fourth-generation languages is that there is no consensus as to what constitutes such a language, nor even the name we should attach for the emerging development tools. Products offered in the market often come under the general label of 4GL, but terms such as application generator and integrated CASE (or I-Case) tool are also used.
Many products sold as 4GLs were not designed for implementing mainline systems of the sort encountered within DoD. A number of such products are well suited to deal with common MIS tasks, such as generating flexible reports or handling ad hoc inquiries. Some of them are even user-friendly enough to be suitable for end-user programming. However, these relatively low-level 4GLs are not powerful or comprehensive enough for the professional staff to use for the development of high volume interactive systems. For such use, one of the powerful new integrated products is required.
Although we use "4GL" to label this new class of development tool, the term needs further definition. This can best be done by listing the capabilities that ideally should be provided by a 4GL of the type needed to support a powerful new development paradigm. They are:
No product currently on the market satisfies all requirements; each of them suffers from at least one of the following limitations:
The situation is improving rapidly, however. Some powerful 4GLs are already on the market and proving their worth in developing and maintaining a variety of large MIS applications. Several of them are already valid contenders for use within DoD, and new products or enhancements to existing ones are announced frequently.
Experience with existing 4GL applications suggests that tenfold productivity gains are possible under the right circumstances. Furthermore, the gains are likely to carry on throughout the maintenance phase. With the evolutionary approach to application development made feasible by a 4GL, maintenance becomes merely a continuation of the initial process. Many of the features associated with a 4GL provide valuable maintenance capabilities. For example, the availability of a central repository, when combined with interactive retrieval mechanisms, greatly simplifies the process of understanding and modifying an application. The relatively concise specification language of a 4GL also aids in understanding.
The major drawback to adopting a 4GL is that it requires substantial changes in other aspects of the development and maintenance process if it is to yield substantial payoffs. Merely introducing the new 4GL into a conventional 3GL process will give disappointing results, and in fact could even be destructive.
An effective 4GL process must be much more flexible and adaptive than the conventional sequential approach, and requires continual interaction with users through an application's life cycle. But an evolutionary approach of this sort runs the risk of inviting sloppy up-front requirements analysis. The iterative process may not converge effectively on an acceptable final design if users continue to seek an illusive "perfect" system. The required skill level of the development team is higher than is found in a typical large staff of programmers and analysts.
The risks of moving to a 4GL can be contained with the proper structuring and monitoring of a development project. Whether within the constraints and culture of DoD the necessary adjustments can be made remains an unsettled question. At the very least, the introduction of a 4GL needs to be managed with caution to recognize the risks involved.
Ada was developed in the late Seventies and early Eighties in response to the problems encountered in developing and maintaining massive computer programs within DoD. A broad group of computer scientists contributed to its specification, and the final design was settled through an international competition. It was designed to incorporate the best features of procedural languages. By focusing on a single standard language, DoD hoped to eliminate many of the monumental problems of supporting a hodgepodge of languages.
A. Characteristics of Ada
For the purposes of this report, it is possible to identify the salient features that give the Ada language its special capabilities:
Ada has been successfully taught in introductory programming courses. For example, the Computer Science Department at the Naval Postgraduate School effectively teaches Ada as the first language to a large number of students for a number of years. Everyone agrees, however, that the most difficult part of learning to use Ada lies not in the language itself, but rather in good software engineering principles needed to fully exploit Ada's advantages. As is the case for any programming language, an unskilled programmer can still write sloppy, unstructured Ada code. Ada does not guarantee, but tends to encourage, sound software engineering practices.
B. The Current Status of Ada
1. Signs of success.
Standardized in 1983, Ada is now a mature language with robust compilers available for numerous computer platforms. Translation time has been reduced significantly, although the heavy error checking performed by the compiler inevitably adds to the time (but with compensating reductions in debugging time and execution time due to the detections of errors at translation). Execution time appears to be comparable to other efficient languages. A variety of utility programs, CASE products, and training aids are now available to support Ada development.
A number of important successes have been achieved in developing large Ada systems within DoD. Many of these applications have been in the embedded system domain, where Ada has its clearest comparative advantage. A few large MIS-type applications have been delivered or are in development -- most notably, the Army's STANFINS-R system -- with apparently satisfactory results (Appendix A1). Solid evidence exists that Ada has largely achieved its goal of providing a first-rate development environment for very large systems. Ada's successes are due to an enforced standard for the language, as well as features that promote portability. In a number of cases, subsystems have been developed by separate groups and have then been integrated successfully with many fewer problems than encountered with other languages. Ada programs have been ported to different hardware platforms with little or no difficulties. Although hard comparative data are scarce, Ada's productivity appears to be competitive with other 3GLs.
There have been relatively few applications of Ada outside of DoD, but here too Ada has demonstrated its value. Most of these have been in embedded applications (control of a printer, for example) or in C3I-like applications (e.g., FAA's air traffic control system or Bofors' shipboard fire control system). There have also been notable successes in the development of MIS applications, both in the United Sates and in other countries (e.g., Wells Fargo in the U.S., Nokia Group's major banking system in Finland, and NTT's broad range of applications in Japan).
2. Lack of widespread use of Ada.
Ada's relatively sparse use in large commercial applications reduces its value in the MIS domain. A limited Ada market not only restricts investments in support software, but it also reduces the availability of Ada-related training materials, textbooks, and educational programs. This lack of interest feeds on itself, because limited training capabilities reduces the supply of skilled Ada programmers, which in turn inhibits the use of Ada.
Even within DoD, the number of MIS applications has been quite limited. Although the potential size of the DoD market is very large in absolute terms, it still constitutes a small part of the worldwide information technology market. If the use of Ada continues to be confined largely to DoD, commercial vendors of third-party software products will invest their resources in other markets presenting more attractive commercial prospects. This would put Ada at a growing disadvantage compared to more popular languages that offer a rich choice of supporting products. That would be unfortunate, both for the DoD (because it would limit the number of Ada-related products) and for industry (because it would limit the private sector's use of a genuinely valuable language for important classes of problems, such as process control applications).
It is important to understand why Ada has experienced such limited use for non-mandated MIS applications, because the reasons may have a bearing on setting DoD policies. Ada has a reputation -- deserved or not -- as a complex language aimed at time-critical applications, which for many commercial organizations is not a pressing need. The huge existing investment in COBOL and FORTRAN programs, as well as the supporting development tools and pool of trained personnel, make the cost of transition to Ada a non-trivial matter for most commercial organizations. Consequently, few of them have felt that the transition to Ada would provide an acceptable return on the required investment. The benefits of the switch are viewed by many as risky, intangible, and long-term -- serious impediments in a commercial environment that looks primarily to next quarter's reported earnings.
A more intrinsic limitation to Ada's use in MIS applications is its procedural character that requires many lines of codes to perform common functions found in an MIS application. Leading organizations increasingly recognize that it makes no sense to develop large applications through traditional labor-intensive methods. Although a well-managed Ada environment offers the prospect of a substantial improvement in productivity over conventional development methods, a move to Ada might merely delay the still more dramatic gains potentially achievable with an integrated 4GL.
Management of a database is a critical component of almost all MIS applications. Interfacing Ada programs with commercial database systems is not a difficult problem; a large number of database manufacturers have proprietary Ada interfaces to access their databases. The problem is specifying a portable Ada interface to an industry standard.
The Structured Query Language (SQL) is the ANSI and DoD standard for accessing relational databases, and most database vendors have incorporated an SQL interface to their databases. SQL is, however, incompatible with Ada. The challenge becomes one of specifying an Ada-to-SQL interface that is acceptable to both the SQL and the Ada communities. Since Ada is a third-generation procedural language, while SQL is a non-procedural data access language, several varied and complex technical issues need to be addressed in designing an Ada-to-SQL interface. Three major approaches have been proposed for binding Ada to SQL, but each has some drawbacks (Appendix A2). However, the SEI SQL Ada Module Extension (SAME) approach is emerging as the preferred one, as is currently undergoing ISO standardization.
The 1983 version of Ada lacks some features felt to be useful in the MIS world. The Ada 9X project is considering these needs, and may be able to provide a satisfactory solution for many of them. Among the additional features most relevant for MIS applications are those dealing with decimal arithmetic, an expanded character set, more flexible data access that facilitates sharing files and interfacing with existing applications, support for the use of Ada subprograms within programs written in other languages, support for object-oriented programming, and the elimination of subtle platform dependencies. These will provide useful enhancements to Ada, but the current lack of the features is a fairly minor issue and should not be used as a justification for delaying the use of Ada until the changes have been fully implemented (probably no sooner than the latter half of the decade).
C. Impediments to Increased Use of Ada in DoD
1. DoD support for Ada education.
Despite some notable successes in a few institutions, Ada has not been widely adopted in computer science curricula. According to one faculty member who has monitored Ada's use in academia, there are at most 50 educational institutions that have expanded the use of Ada beyond a mere language course, out of hundreds of computer science undergraduate programs nationwide. There are a number of reasons for the limited adoption of Ada:
DoD needs to review the role it might play in furthering the expansion of Ada. One of the most fruitful steps might be assistance in providing inexpensive compilers and tools for universities. In contrast to Ada, UNIX and C tools have been made widely available to academia, accounting in major part for their great popularity. Another useful step would be to support the development and dissemination of first-rate courses and instructional materials.
The Ada industry is still relatively young and without deep financial pockets. A few companies have offered to colleges and universities free compilers and development environments, charging only a yearly maintenance fee. Unfortunately, response from academia has not been overwhelming. At this point it appears that additional DoD support is required if we are to overcome academic barriers.
2. Under-funding of Ada language improvements.
Two major Ada language improvement efforts are constrained by a lack of funding. The Ada Technology Improvement Program (ATIP) traditionally has helped the services and agencies overcome technical hurdles in implementing Ada applications. More recently the Ada Joint Program Office (AJPO) has initiated ATIP efforts emphasizing binding of Ada to other languages and developing new software engineering educational programs using Ada. Of over 70 service and agency requests, only 14 were able to be initiated in FY-91 because of funding constraints. The AJPO has had to repeatedly seek outside funding from the services and agencies to make up for the funding shortfall. The Ada 9X program is also constrained in future years.
The FY-92 AJPO budget request was limited to $6.9 million. DoD is estimated to be spending approximately $30 billion on software each year. Thus, for every $1000 we spend on software, we are only willing to spend about 25 cents to support the further enhancement of Ada and its use. This lack of support is inconsistent with the mandated use of the language and the high expectations for the benefits it can provide.
3. User pays the incremental costs of implementing Ada.
One of the frequent reasons cited for the resistance by project managers to use Ada is their perception that their project will have to bear added costs for the transition to Ada. These incremental costs include training, learning time, and the purchase of Ada-related tools. It would be much more palatable for a project manager to use Ada if all or part of the additional costs were borne by higher command.
It is not unreasonable to establish DoD policies that allow varying degrees of dependence on Ada. Any policy must, of course, comply with the Congressional mandate, but that mandate contemplates circumstances under which other languages offer a more cost-effective approach. We will use the following categories of computing in analyzing the issues:
We will discuss briefly each of these categories, and the circumstances, if any, under which a given category might be appropriate. It should be pointed out, though, that the boundaries between the categories is sometimes quite fuzzy, and so it may be difficult in practice to judge the category into which a given project falls.
A. Conventional Programming and Maintenance in Ada, Aided by CASE Tools
Every Ada programming project should take advantage of the growing set of CASE tools now available in the market. The emphasis should be on integrated tools that provide seamless links among the various stages of development. A powerful repository should also be made available. Although the use of CASE tools offers important advantages, this approach still has some serious limitations. Since no fundamental change is made in the conventional development paradigm, the CASE tools merely automate the sequential SDLC approach, and therefore do relatively little to eliminate the disadvantages of conventional project management.
An important distinction between this category and the next is the absence of a serious management effort to develop a comprehensive set of reusable packages. A significant level of reuse is unlikely to occur unless an explicit program exists for the design, classification, indexing, retrieval, maintenance, and support of reusable packages. Without such reuse, however, development productivity will suffer (Appendix A3).
The use of a CASE tool opens up a problem that Ada was seemingly aimed at reducing. Selecting and supporting a set of CASE products is not a trivial matter. Without establishing a DoD standard for CASE tools -- unlikely, at least in the near term -- each using organization must confront the problem of supporting its selected products. As CASE tools assume a growing fraction of the burden of application development, problems of proliferating non-standard products will be magnified. The only way to avoid the problems is to standardize on the CASE tools or bar their use - and neither is an attractive solution.
B. The 3½GL Approach
The 3½GL approach is similar to the previous one, but with an important difference. Like the previous category, the 3½GL approach uses sophisticated CASE tools to increase the efficiency and effectiveness of the development process. Greater emphasis is placed, however, on reducing the extent of new Ada coding. A library of packages is designed explicitly to provide a comprehensive set of functions to support the development of MIS applications. The aim should be automatic code generation of a high proportion of an application. The 3½GL approach probably offers an attainable goal of doubling or even tripling productivity.
There are difficulties with this approach, however. The design of a comprehensive set of packages is likely to be difficult and expensive. It is also a somewhat risky undertaking, because we do not have strong evidence that widespread reuse will be achieved. The use of standard packages might ease the maintenance burden for application developers, but it then shifts the responsibility to another party who would have to deal with such challenging management issues as keeping track of multiple versions of a package. Furthermore, an application developer who finds it necessary to modify a package in order to tailor it to a user's specific needs would generally have to take on maintenance responsibility for the modified package.
The 3½GL approach also raises some difficult training problems. Developers would have to be trained in the use of the available packages as a central part of the design and implementation process. This would represent a considerable change for most experienced programmers. Training in the CASE tools used to support the 3½GL environment would also be required.
C. Programming and Maintenance in a 4GL, with Translation into Ada
Some of the new 4GL products offer the prospect of developing heavy-duty mainline applications entirely in a high-level specification language. All maintenance changes are similarly effected in the 4GL (followed by re-translation into object code). With proper management, using a well-trained development/ maintenance team and an evolutionary implementation methodology, this approach offers the prospect of a tenfold gain in productivity in the initial development and maintenance, with associated improvements in reliability and responsiveness to user needs.
This approach would be more acceptable within DoD if the 4GL translates an application specification into Ada as an intermediate language. None of the strongest 4GL contenders can currently do this, but at least one major vendor has announced its intention to provide such a capability by June 1992. Other vendors may follow, because translation into Ada does not appear to present any insuperable technical problems. This appears to satisfy the formal Ada mandate, and would offer the additional advantage of providing a standard, stable target language portable to a variety of hardware platforms.
A number of barriers to the use of 4GLs must be overcome before this approach is likely to achieve its potential benefits within DoD. A dramatic success in applying the 4GL paradigm calls for some significant changes in the mind set of managers and developers. The development environment should be considerably less rigid and disciplined than is customary in DoD, which may create concerns about risk and loss of control. A certain amount of ambiguity is inevitable with a paradigm that explicitly encourages learning and adaptation during the development process. The focus on a small, capable development team is not a common approach for software development within DoD (although the Department and its contractors have achieved very favorable results with "swat teams" and "skunk works" that rely on many of the same concepts). Considerable effort would have to be spent in educating the technical staff in the use of 4GL tools and design concepts.
Ambiguity in an application's specification can raise some difficult contractual issues. Writing a traditional development contract with a well-specified final product is impossible in an evolutionary development environment. An adaptive design could probably be handled within existing regulations (such as a time-and-materials contract for the initial prototype development, followed by a fixed-price contract for the "final" version). However, DoD should give considerable attention to its contracting regulations to accommodate a more flexible development process.
Not the least of the problems of adopting the 4GL approach is choosing the particular 4GL to use. All of the contending full-featured 4GLs are proprietary, which opens a number of contracting issues. It is conceivable that DoD could fund the development of a 4GL, but the history of noncommercial projects of this sort do not give much room for optimism. We are hopeful, though, that a 4GL could be selected in open competition in a way that satisfies the requirement for competitive procurement. Even though a product is proprietary, its vendor can publish standards that allow other vendors to interface with it (as Lotus Corporation did, for example, with Lotus 1-2-3).
Reliance on a 4GL for the development and maintenance of applications moves away from one of the Ada goals of having a single standard programming language within DoD. However, as we have seen from the earlier discussion, support of multiple development tools will be required for any productive environment. Standardizing on a single 4GL would mitigate the training problem, but Ada experience shows that getting agreement on a standard is a time-consuming process. If a single standard cannot be attained, a specified set of required features for any candidate 4GL could at least narrow the choice considerably and thus reduce selection and support problems. Furthermore, if a 4GL maps into Ada, much of Ada's advantage of stability and portability would still be preserved despite the lack of a standard 4GL.
E. Programming and Maintenance in a Problem-Specific Language
Problem-specific languages cover a very wide spectrum of applications, but each one tends to be aimed at a relatively narrow problem domain (Appendix A5). For example, spreadsheet languages are designed to perform modest-scale numeric and data manipulation tasks and generate a variety of graphical and tabular outputs. Micro-based application generators (dBase, Paradox, etc.) make it easy to give a work group flexible access to its own local database. Statistical packages focus on handling masses of numeric data and performing a variety of statistical functions. Other special-purpose languages are designed for the development of decision support systems and expert systems. The list of these language domains could go on and on.
A special case of problem-specific languages are application packages or commercial off-the-shelf (COTS) software. These can be viewed as focused languages that deal with a very narrow application domain, such as payroll, production scheduling, or computer-assisted design. Any tailoring of COTS software for a particular installation would normally be achieved merely by setting appropriate parameter values for the product; actual modifications of the code should generally be avoided. As long as DoD does not have maintenance responsibilities for such a product (as it might if code modifications were required), the use of COTS products is allowed within current or planned guidelines.
Problem-specific languages have achieved great success because they satisfy important needs. Often emphasizing ease of learning and ease of use, they put in the hands of functional specialists (as opposed to professional programmers) the means of developing their own applications to serve their own requirements. Most observers feel that "end-user computing" of this sort is likely to continue to grow as a component of a successful information system strategy.
No one argues that specialized languages do not have a place within DoD; the arguments begin when one tries to set boundaries on their use. A clear-cut case for using a specialized language can be made for a small single-user application developed by the actual end user, as is often the situation for a typical spreadsheet application. Here the advantages of productivity and responsiveness overwhelm any disadvantage of language proliferation. Under these circumstances, a prima facie case can be made in favor of the specialized language, because Ada would clearly not be a cost-effective competitor; in fact, it would never be used at all by the typical end user (Appendix A5).
As the size of the user group grows, and the need for technical support expands, the case for end-user computing becomes more controversial. Even commercial organizations thoroughly committed to end-user computing and decentralization have a difficult time formulating policies on these matters. On the one hand, freedom to use the language of one's choice offers the advantage of responsiveness, creativity, and (in most cases) high productivity. On the other hand, uncontrolled systems development by amateurs raises very serious problems of validity, integration, duplication, and maintainability of the software.
A moderate-sized work group should normally be allowed to develop its own unique application in one of the user-friendly end-user languages. DoD would pay a heavy price if Ada policies ruled out, for example, the development of a small database application to keep track of a unit's work assignments. Such an application tends to be quite idiosyncratic and self-contained, and would therefore be an unattractive prospect as a professionally-developed standard application used by many units. The application is not likely to be critical to the success of the unit's mission, and so the penalty of an error or system "crash" would probably be quite modest. A policy that bars the development of such an application would effectively deny to the group many of the advantages of computer-based systems. Here again, the case for use of the specialized language appears to be strong enough that it should not be necessary to justify a non-Ada solution; it can be assumed under these circumstances that Ada cannot meet the Congressional test of cost-effectiveness.
The use of a specialized language should not necessarily be confined to small local workgroups. Even a widely used specialized application developed and maintained by a technical staff might best be developed using a domain-specific language. Decision support and expert systems, for example, would generally fall into the class of problems for which a variety of specialized development languages offer advantages sufficient to overwhelm any possible disadvantages. Hardly any knowledgeable professional would suggest that these systems should be developed in a 3GL. Not only would the cost and development time be prohibitive in most cases, but the need for adaptation and evolutionary growth would put a 3GL at great disadvantage. Because of these considerations, DoD policies should certainly allow fairly liberal use of specialized languages designed for specific problem domains.
Unfortunately, it is not easy to formulate a clear-cut set of policies that make it easy to decide whether in a given case Ada should be used. Each case should be considered on its own merits. The decision should be based on such factors as the size and dispersion of an application's prospective user population, the duration of its use, the amount of support required to maintain it, and the risks and costs of a defect or complete failure. The use of Ada should be favored for an application that tends toward a large dispersed user population, a long expected life, complex support requirements, or critical mission dependencies. There are certainly tradeoffs between controlled professional development of an application in Ada and the risks of unfettered development by user groups, but the resolution of the issue should not always be settled in favor of standardization in Ada.
F. Programming and Maintenance in a 3GL other than Ada
Almost all existing MIS applications within DoD are developed in a 3GL (principally COBOL). Some maintenance will no doubt have to continue using the initial 3GL, but this should be kept to a minimum. The potential tenfold increase in productivity of a 4GL drastically reduces any advantage of preserving an obsolete application, because an entirely new system can then be developed in the 4GL for less than it typically costs to maintain the old one for a year. Preservation of an old program should require justification by comparing its future maintenance costs (over the next five years, say) with the cost of developing and maintaining an entirely new system using the best available environment.
Some interest exists in developing "re-engineering" software that can automatically translate a COBOL program into Ada. These tools are just emerging, however, and are unlikely to have a major impact on the issues in setting Ada policies. Furthermore, a re-engineered obsolete COBOL program is likely to become little more than an obsolete Ada program (although some cleaning up of a badly structured old program can now be done by some of the more "intelligent" re-engineering translators).
In the case of new applications, DoD policy should be quite simple: except in very exceptional cases, in which the cost-effectiveness of a non-Ada solution can be demonstrated convincingly, programming in a third-generation language other than Ada should not be allowed. The arguments still apply that gave rise to the creation Ada in the first place, and so there should be little reason to compound existing software problems by developing still more 3GL programs in non-Ada languages.
Conceivably, this situation could change if Ada continues to be largely ignored by the commercial sector. The rapid growth in the interest and use of C++, for example, raises this language as a possible future contender. If other languages widely used in the commercial sector continue to grow in power and third-party support relative to Ada, standardization on a single 3GL for MIS may have to be re-examined.
This report has examined the use of Ada in programming MIS applications. Ada will (and should) remain for the foreseeable future the DoD's sole standard third-generation language. A major share of software applications within DoD deal with large embedded programs and time-critical C3I systems, for which Ada is the best choice available. That fact alone should insure that Ada will remain the paramount programming language within DoD.
DoD can strengthen Ada's position even further by providing additional funding for the development of Ada-related educational materials, extensions of the language in the Ada 9X activity, and absorbing some of the transition costs generally incurred when a programming staff moves to Ada from one of the other 3GLs. The development of a sharable Ada repository should also receive greater attention, which might be accomplished either through direct DoD funding or by providing greater contractual incentives for the private sector to take on this task. The relatively meager support of Ada provided at the central DoD level is inconsistent with the critical role it must play in the application of information technology.
Despite Ada's undeniable strengths as a 3GL, its use as the sole language for developing large-scale management information systems is open to serious questions. Powerful 4GLs and domain-specific products on the market generally offer a more fruitful approach, because of their potential for achieving very large productivity gains in the development and maintenance of MIS applications. Although standardization must remain an important goal of DoD computing policies, it is not the only one; DoD must also consider the trade offs between standardization and the increased productivity of the new 4Gls.
The use of a domain-specific language is relatively easy to justify when its capabilities match closely the needs of an application. Many of these languages are mature, with a large user base and pool of experienced developers. For programming end-user applications, such as a modest-sized spreadsheet or local administrative system, the focus of language should be on ease of learning and ease of use. Ada was never designed to meet these requirements, and therefore can seldom compete with the specialized languages. For larger applications that call for professional development skills, a domain-specific language may still be the appropriate choice even if it is not especially user-friendly. A complex decision support system or AI application, for example, can often be developed much more efficiently with a language designed for this purpose than it can with a general-purpose 3GL like Ada. These applications rely utterly on the adaptability and productivity that a specialized language can provide.
In practice, it is often difficult to draw the appropriate boundaries within which a domain-specific language is the appropriate choice. As an application grows in size, complexity, geographic or organizational dispersion, response-time demands, required reliability, or expected longevity, there comes a point at which it should be taken over by professional developers working in a productive Ada environment. Defining precise criteria for making the judgment on these matters is probably not possible (or even desirable), but at least general principles should be established that permit relatively liberal use of the specialized languages in situations in which they offer the most cost-effective means of developing an application.
Considerable skepticism remains in the minds of many concerning the possible role of a powerful 4GL in implementing a large-scale MIS. Despite a number of demonstrated successes, 4GLs do not yet enjoy widespread use. In a few years, substantial and widespread evidence may well exist to support ambitious claims for the 4GLs, but that is not the case right now. The products are still evolving rapidly, making it difficult to choose the best one or to know when is the right time to make the move. Thus, even though the technology already looks capable and robust enough to build successful systems, it is not clear to many that the DoD should move in this direction at the present time.
Although a cautious waiting game would avoid the risks associated with using a rapidly-evolving technology, it would carry substantial risks of its own. The most serious risk -- and in our opinion a very likely outcome -- is that without fundamental changes the DoD will dig itself further into a hole, compounding the present software crisis. Conventional practices are no longer tenable now that much more attractive approaches are available. With the 4GL approach, risks can generally be managed; the same cannot be said of the conventional process, in which costs, schedules, and specifications frequently get out of control no matter how much effort management devotes to keeping things in reign.
The faults of the conventional process would undoubtedly be substantially alleviated if a wholesale switch to Ada could be made -- provided it is accompanied by other necessary changes in methodology, training, and tools. A change of this magnitude would, however, also create some risks and require considerable transition time. It appears to us that the potential for making dramatic improvements through the use of 4GLs more than compensates for a possible increase in risk compared to the Ada approach. The problems of managing MIS applications are great enough no matter what course of action is taken, so we should at least follow a path that offers a good opportunity to make a real difference.
DoD is currently undergoing substantial change in its management of MIS activities. The new leadership offers a new vision and aspiration level. The CIM initiative opens up an important mechanism for effecting change. The confluence of these favorable factors creates a great opportunity to make measurable and meaningful improvements. It is by no means out of the question for DoD to establish a leadership position in the effective management use of information technology. This opportunity will not last forever; it would be a pity not to grasp it while it is here.
A. DoD should move as rapidly as feasible to high-productivity development environments for the implementation of management information systems.
1. DoD should require the use of an integrated 4GL or state-of-the-art CASE tools for new MIS applications.
2. DoD should establish guidelines for dealing with the introduction of 4GLs, covering such matters as their required and desirable features, skill requirements to employ them, and the avoidance of an excessive number of products that have to be supported.
3. Development of human resources for the implementation of application software should be given a high priority.
4. DoD should review its software development methodologies, documentation standards, and acquisition policies in light of the emerging trend toward a more adaptive and interactive implementation process.
5. DoD should launch a project to implement a major application (perhaps under the Corporate Information Management initiative) using an integrated 4GL. In addition to developing a needed, high-priority application, the project should aim at demonstrating the technical and economic feasibility of the 4GL approach and creating procedures and standards compatible with, and supportive of, a 4GL implementation. To the extent possible, this project should be "fast tracked," using selected development personnel, ready access to users throughout the development process, and the avoidance of unessential bureaucratic constraints.
6. DoD should initiate a second project to implement a major application using an integrated 31/2GL. The project should aim at demonstrating the technical and economic feasibility of the 31/2GL approach and creating procedures and standards compatible with, and supportive of, a 31/2GL implementation. To the extent possible, this project should be "fast tracked," using selected development personnel, ready access to users throughout the development process, and the avoidance of unessential bureaucratic constraints.
B. DoD should establish policies and guidelines for the use of programming languages other than Ada for end-user computing and applications for which an established domain-specific language is available.
1. DoD should establish exemption policies for the development of applications using specialized user-friendly languages suitable for end-user computing (spreadsheet programs, micro-based application generators, etc.). In defining end-user computing, exemption policies should balance the economy and responsiveness of this approach against its added risk of erroneous outputs, service disruptions, or undue dependency on user-maintainable programs.
2. For applications not exempted as end-user computing (e.g., because of their size, longevity, criticality, or widespread use), DoD should establish policies for the use of domain-specific languages that can be expected to achieve substantially greater productivity and responsiveness than Ada. The use of Ada should normally be waived for AI, expert system, and DSS applications, but each case should be judged on its own merits based on a detailed development and maintenance plan submitted by the proposing agency. Other problem domains having a similar well-established body of knowledge and specialized languages should also normally have the Ada requirement waived.
3. Consistent exemption and waiver policies should be applied to all the services and DoD agencies.
4. Enforcement procedures should be established to insure compliance with DoD Ada policies.
5. The draft policy recommendations of the AEO/AJPO Working Group on Ada Waiver Policy should be used as a starting point for formulating specific DoD waiver policy.
C. DoD should establish continuing mechanisms for promoting the best software development practices and encouraging software reuse.
1. Comparative analyses should be performed to assess results using different approaches to software development and maintenance. The data collected should include cost, schedule performance, productivity measures, software quality, and software maintainability. The analyses should be made available to policy makers and practitioners to aid them in setting software policies.
2. Software practices and standards should be reviewed periodically, and revised when appropriate in light of actual experience and advances made in software development technology.
3. Coordinated goals for software reuse should be established. Consideration should be given to such mechanisms as DoD funding of reusable Ada components and modifying contractual terms with software contractors to provide incentives for them to develop reusable packages.
A1. STANFINS-R: A CASE STUDY ON THE USE OF ADA IN DEVELOPING INFORMATION SYSTEMS
A2. ISSUES IN INTERFACING ADA WITH DBMS
A3. CODE REUSE
A4. COST-EFFECTIVENESS ISSUES
A5. PROGRAMMING LANGUAGE OPTIONS FOR THE DEVELOPMENT OF AI/DSS AND END-USER APPLICATIONS
A6. REVIEW OF PRESENT PROGRAMMING LANGUAGE POLICIES IN DOD
The Standard Financial System (STANFINS) is a component of the US Army accounting system, and serves as a field-level system for general funds servicing posts, camps, and stations. Originally, STANFINS was a batch processing system written in COBOL. In 1985, the Army undertook a redesign project (STANFINS-R) in order to overhaul the system and make it interactive. STANFINS-R was developed in Ada and provides important glimpses on the problems and prospects for the use of Ada in developing information systems.
STANFINS-R consists of two subsystems -- Subsystems I and II -- to be developed independently. Subsystem II is designed to handle mainstream accounting applications such as the general ledger, accounts receivable, fixed assets, and cost accounting standards. It is a large system, consisting of 500 programs with approximately 2 million lines of code, and generates 147 reports. The contract for developing Subsystem II was awarded to the Computer Sciences Corporation (CSC) in the autumn of 1986.
STANFINS-R was originally conceived of as a large COBOL project. However, the contract was modified in the spring of 1988, and Ada was designated as the development language. The first pilot teams were soon formed, and the actual writing of code and Ada bindings began that fall. Software development tests were started in the summer of 1989, and software qualification tests began later that autumn. The system is currently undergoing software acceptance tests, and is expected to be operational in early August 1991.
The project was developed in an automated program support environment composed of six Rational R-1000 machines. The code was eventually ported to the target environment, an IBM mainframe running OS/MVS.
B. Execution of the Project
The project has had to overcome a series of hurdles. The system was originally intended to be written in COBOL. However, because a waiver was denied, the development language had to be switched to Ada. The available pool of developers with Ada/MIS experience was small. This required training the existing staff of COBOL programmers in Ada, thereby causing further delay.
Since STANFINS-R was the first Ada application of its kind and size for an IBM OS/MVS environment, there were few tools to support Ada. The project thus entailed the development of a set of support tools such as code generators and screen painters.
The compiler used in the project (provided by Intermetrics) presented a number of problems. It did not provide support for a CICS-based teleprocessing monitor, thus forcing the contractor to write an appropriate interface. Since the DBMS package chosen for the project, Datacom/DB, did not contain a suitable Ada interface, a hook had to be written. Porting code from the Rational environment to the actual target environment was not easily accomplished, and parts of the code such as nested generics did not work in the target environment, even though they functioned properly in the development environment. Code sharing at the executable level could not be implemented on the target, thereby causing the executable programs to grow to unmanageable proportions. Some other features, such as representation specifications, Unchecked Conversion, and Pragma Inline, were not implemented in the target compiler (Fussichen, 1990).
C. Lessons Learned from the Project
STANFINS-R constitutes in many ways a representative information system project, and provides an indication of the types of issues that can be expected to occur from an enforcement of the mandated use of Ada.
Can STANFINS-R be considered to be a success? In a technical sense, the project establishes the viability of Ada as a language for developing information systems in environments where COBOL has been the dominant development language. Programmer productivity in the project has been high -- at 594 lines of code per staff month, almost double that of typical programmer productivity in COBOL projects. The quality of the software, as evidenced by test results, appears to be high. While the implementation of STANFINS-R is a year behind schedule and over budget by $25 million, a major part of the delay and cost overrun can be attributed to administrative factors and the switch from COBOL to Ada. Preliminary evidence, therefore, argues favorably for the suitability of Ada as a language for developing management information systems.
It is too early to conclude from the STANFINS-R experience that systems developed in Ada will be more maintainable than those written in COBOL. However, preliminary evidence is very encouraging. STANFINS-R has a maintenance staff of four programmers and two technical support persons, a much smaller team than required by a system of similar size using COBOL.
The STANFINS-R experience also suggests that the potential benefits of reusability can be realized at several levels. At one level are specific packages and templates that can be used in other parts of the project or in other projects. While the same thing could, in principle, be accomplished with code written in COBOL, the use of generics and packages gives Ada a special advantage over COBOL that makes such reuse much more feasible. There was significant use of these templates in STANFINS-R.
The issue of reuse can also be thought of in terms of tools that are developed for specific projects but with suitable modifications can be used in other projects. The STANFINS-R project, for example, entailed the development of a set of tools for writing design specifications. These tools can plausibly be modified and reused in other projects. There is some demonstration of reusability at both levels at a follow-up project, the Standard Army Financial Accounting and Reporting System (STARFIARS). While the size of STARFIARS will be at least 60 percent than of STANFINS-R, the project is scheduled to be completed in half the time. The rationale for this aggressive schedule is twofold: STANFINS-R provided a useful learning curve from which STARFIARS will benefit. More importantly, the implementation of STANFINS-R has created a set of system templates and tools that can be reused to create the new system with greater productivity.
The STANFINS-R experience, however, also suggests a number of issues where caution is warranted. Developers in this project had significant problems with porting code from the development environment to the target environment. What compiled on the Rational R1000 also compiled on the IBM mainframe using OS/MVS. However, lack of compiler support for the teleprocessing monitor and interfaces to the DBMS necessitated the creation of code with low-level functionally, thereby limiting portability to other environments without significant modifications. Thus, while most of the STANFINS-R code can be ported to, say, a VAX/VMS environment, complete portability would require significant alterations. Thus, while portability in principle is assured by developing code in Ada, portability in practice can be constrained by the source and target environments.
The documentation required for STANFINS-R was inordinately large. While the exact figure is difficult to ascertain, a conservative estimate is that every line of code generated at least ten lines of documentation -- a total of five million lines. The documentation was prepared according to the requirements mandated in standard 7935-A. The voluminous nature of the documentation clearly limits its usefulness and points to the need to reexamine current documentation standards.
STANFINS-R was implemented in a target environment poorly supported in terms of compilers and support tools for Ada, especially in comparison with the repertoire of similar tools available in COBOL environments. Since a productive environment is an important prerequisite for MIS development in DoD and elsewhere, a paucity of available tools works to the disadvantage of Ada. For one thing, it serves to deter information systems developers from considering Ada as a language of choice for MIS. Second, because the prospective number of interested parties is not large, there is little incentive for vendors to offer products. A successful implementation of the mandate to use Ada will require a suitable resolution of this adverse cycle of factors. The solution lies, in part, on promoting Ada as a language suitable for general use and not just for embedded systems. An imaginative set of incentive structures, such as cost-sharing mechanisms and proprietary rights to reusable packages, may also serve to dent the problem.
A final, but by no means least important, issue surfaced by the STANFINS-R experience is the extremely limited the pool of developers skilled in Ada/MIS applications. Implementing the STANFINS-R project required the contractor to provide extensive training to COBOL programmers. While part of the problem can be overcome through training, it is important that the problem be recognized in estimating project cost, and sufficient time and funds be made available.
Fussichen, K., "An MIS Ada Practicum," Proceedings of the Eight National Conference on Ada Technology, 1990.
A major requirement for management information and C3I systems is the ability to access and manipulate large databases. The ability of Ada applications to access commercial database systems is therefore of significant importance. While interfacing Ada programs with commercial database systems is not a difficult problem, and most database manufacturers have proprietary Ada interfaces to access their databases, there remains the problem of specifying a portable Ada interface to an industry standard.
The Structured Query Language (SQL) is the ANSI and DoD standard for accessing relational databases, and most database vendors have incorporated an SQL interface to their databases. SQL is a data access language that supports the definition, manipulation, and control of data in a relational databases. The issue becomes one of specifying an Ada-to-SQL interface that is acceptable to both SQL and the Ada communities. Since Ada is third-generation procedural language while SQL is a non-procedural data access language, several complex and varied technical issues arise in the design of an Ada-to-SQL interface.
Three major approaches have been proposed for binding Ada to SQL. The ANSI approach uses a precompiler to replace SQL statements with DBMS procedure calls. The IDA Ada/SQL binding uses Ada procedure calls that look like SQL statements. Finally, the SEI SAME binding approach separates Ada and SQL modules and interfaces them using an abstract module. In the following section we describe each proposal and present its pros and cons.
1. ANSI Ada-to-SQL binding. This binding, proposed by the American National Standards Institute (ANSI), is similar to the standard interface between SQL and the programming languages COBOL, FORTRAN, Pascal, and PL/I, as described in the ANSI standard for SQL (ANSI 1989, ANSI 1986). Under this approach, application programs are written in Ada with embedded SQL statements that provide access to the database. The Ada program is then processed by an SQL precompiler, which replaces the SQL statements with procedure calls to a library of database access routines to produce a "pure" Ada program. This program is then compiled and linked in the usual manner to produce an executable module.
The main advantage of this approach is that query optimization can be accomplished at compile time. There are, however, several disadvantages. The application programmer is required to write programs in two languages that are essentially very different. Two passes are required to compile the Ada program, making the process time consuming. Ada-specific tools (editors, debuggers, etc.) cannot be used. Portability of the programs is limited, since the ANSI standard leaves many issues of the binding as implementation dependent. Null-value checking logic is implemented using indicator arrays, which leaves the burden of null-value checking logic to the programmer and results in programs that are both difficult to maintain and test. Finally, this approach does not make full use of Ada strong-typing capabilities and semantics.
2. IDA Ada/SQL binding. Developed by the Institute for Defense Analyses (IDA), this approach allows the application programmer to represent SQL statements in a "pure" Ada program by using Ada procedures and function calls that closely resemble SQL constructs (Brykczynski and Friedman, 1986). Thus, a preprocessor is not required. Because this approach does not embed SQL in Ada in the standard ANSI sense, the resulting programs are highly portable. Additionally, Ada typing and semantics are preserved. No foreign data types need to be converted to and from Ada types, and Ada tools can be used with the application programs. This approach, however, suffers from several serious drawbacks. It requires the database administrator (DBA) to code complex Ada packages that specify data definition and support data manipulation. The binding is expensive to compile and has a poor run-time performance, since query optimization is done at run-time. Similar to the ANSI approach, there is no support for null-value checking, and little support for error handling.
3. SEI SQL Ada Module Extension (SAME) method. Developed by Carnegie Mellon University's Software Engineering Institute (SEI), the SAME method extends the ANSI SQL standard (Graham, 1989). The philosophy behind the approach is that Ada and SQL are two independent languages and should be treated as equals. SQL statements appear together in a file, physically separate from the Ada application, in a module called the concrete module. Ada statements appear in an Ada compilable module. SAME provides the binding between these two modules through an interface layer, called the abstract module.
A main advantage of the SAME approach is that database applications are written in pure Ada, and thus no preprocessing is needed. Ada-sensitive editors, debuggers, tools, etc. could be used with the database application programs. Similarly, the SQL module is written in pure SQL and can therefore be processed with available SQL tools. This separation of Ada and SQL code leads to easier management and control of the application as well as reduced maintenance costs. In addition, compile time query optimization is easily supported through the SQL module language compiler. Ada typing facilities and semantics are fully supported at the application level. By using the abstract interface, application programs are isolated from the SQL conventions for null-values. Also, the abstract interface allows for a simple, uniform, yet flexible treatment of database exceptional conditions, which are implementation dependent.
The main drawback to this approach is the additional resources required to support the specialization of roles for programming the Ada, SQL, and the abstract modules. That may be justifiable for large, complex projects, however. It has been estimated that for this approach to be cost-effective, the application must have at least 20,000 lines of code. Another drawback is that coding the abstract interface often involves extensive programming. A Structured Query Language Ada Module Description Language (SAMeDL) has been defined that would greatly facilitate the construction of Ada database applications based on the SAME architecture (Chastek et al., 1990).
Other Issues in Accessing Databases
While standardizing the interface between Ada and SQL will provide enumerable benefits, several other issues need to be addressed, particularly for applications that have real-time requirements, as in C3I systems.
Commercial versus custom databases.
A commercial database management system may not satisfy response time requirements for real-time applications having to provide fast performance and quick response time. A custom database is often needed in these situations to maintain data in real memory under the control of the application programmer.
Relational versus hierarchical databases.
While relational databases have made great progress to improve their efficiency, experience has shown that the real-time requirement of fast performance with quick response time of C3I systems almost always requires the use of the more efficient pointer-based models like the hierarchical or network data models.
As part of the language, Ada has multitasking capabilities for concurrent computing. The notion of Ada tasks, however, is different from the notion of concurrent transactions in a DBMS. No DBMS is designed to support an Ada program running multiple tasks that requires multiple simultaneous transactions. Current DBMSs need to be modified to support such behavior from application programs.
The SAME approach is emerging as the preferred method for interfacing Ada programs with database management systems whose data manipulation language is SQL. SAME is the most appropriate approach for MIS because of its separation of application programming from database programming; preservation of Ada typing and semantics; safe treatment of null-values; and simple, robust, and flexible treatment of database exceptions, compile-time query optimization, and portability. The SAME approach is getting an almost unanimous support from both Ada and SQL communities and is currently undergoing ISO standardization.
It should be noted that the separation of programming tasks and database programming tasks and the requirement for interface programming make the SAME approach suitable for database applications large enough to afford this sort of specialization of effort.
For systems with critical real-time requirements, other important issues need to be addressed. These include the potential need for customized real-time databases, other than relational (pointer-based) databases for improved performance, and database management systems that support the notion of Ada tasks for increased concurrent processing.
ANSI, Database Language -- Embedded SQL, ANSI X3.168-1989, American National Standard Institute, New York, 1989.
ANSI, American National Standard for Information Systems: Database Language SQL, ANSI X3.135-1986, American National Standard Institute, New York, 1986.
Brykczynski, B. and F. Friedman, Preliminary Version: Ada/SQL: A Standard Portable Ada-DBMS Interface, Institute for Defense Analysis, Paper P-1944, Alexandria, VA, 1986.
Chastek, G., M. Graham, and G. Zelesnik, The SQL Ada Module Description Language SAMeDL, Technical Report, CMU/SEI-90-TR-26, Pittsburgh, PA, 1990.
Graham, M., Guidelines for the Use of the SAME, Software Engineering Institute, Technical Report CMU/SEI-89-TR-16, Pittsburgh, PA, 1989.
Wenjen, W. Ada/SQL Interfaces in C3I Applications, The Seventh Annual Database Colloquium Database'90, San Diego, CA, 1990.
Code reuse is considered to have great potential as a source of productivity gains in software development. It has been estimated that approximately half the code in an information system is reusable -- and the Department of Defense is currently spending over $4.5 Billion per year on administrative software.
In our discussions with many senior officials in DoD, we have concluded that there is a considerable lack of understanding of many of the issues dealing with software reuse. For instance, one senior officer from a computer-intensive domain, when asked what he envisioned as reuse, described what in essence would be a DoD repository into which all software acquired by DoD would be deposited and made available for reuse. This approach would almost certainly prove unmanageable and of little practical use. As one general officer recently commented, reusability cannot remain the abstract buzz word it has been in recent years.
Ada is often described as a language that is particularly suited to take advantage of code reuse. Its portability means that Ada code written anywhere is potentially reusable, not just code written for a specific system. Ada is, by design, well suited to the integration of system components from multiple sources. Packages from other sites can be incorporated into a system with guarantees of interface compatibility and of freedom from side effects.
Ada has features (e.g., generics and packages) that make it easier to design code for reuse. A number of Ada repositories -- libraries of code intended for reuse -- have been established. Whether they will prove useful depends on the degree to which they can overcome the obstacles that have historically hindered software reuse.
A. The Costs of Reuse
Establishing an effective repository is expensive. A repository is not merely a bin into which programmers can toss software donations for the benefit of other programmers. Industry experience has been that programmers do not find it worth the time and trouble to reuse other people's code in such cases. Rather, designing and stocking a repository is an exacting process with its own life cycle.
Domain analysis is required in order to identify packages or components suited to the target application systems, and to identify candidate system architectures.
The software, whether it is specifically written for the repository or whether it is taken from elsewhere, requires stringent testing. Programmers will not continue to use a repository that contains modules with errors -- debugging other people's code is too expensive. The repository must also be catalogued and indexed so that users can identify potentially reusable packages. The packages must be well enough documented that these users can incorporate them into their systems with confidence. If minor modifications are needed, much of the benefit of reuse may be lost. It is, however, far easier to find a close fit than a perfect one, and so it is often necessary to modify code. (Object oriented design, to which Ada is well suited, may make the reuse of isolated architectural elements more practical in the long run.)
Thorough testing, good documentation, and cohesive and reusable modules are generally good practices that can greatly reduce long-run software costs, yet we are referring to them here as extraordinary efforts. Since programmers are often penalized for taking the extra time these practices require in the short run, it is often difficult to get programmers to pay the "tax" of making software reusable. Until and unless there are fundamental changes in the short-term incentives of project managers, it may be necessary for the repository to bear these added costs. It is probable that a repository will also have to maintain and support its software.
Once a repository is established, the potential user must invest the time and effort required to locate reusable modules. At the current level of cataloguing and indexing, the search effort is still substantial. (We have been describing reuse in terms of a programmer searching for a module to perform a given function. Greater levels of reuse can be achieved if the target system has been designed to take advantage of the repository.)
B. The Scope and Granularity of Code Reuse
We have been presenting code reuse as a mechanism for saving a programmer the time it would require to write and test code that is already available. This saving, however, is not as great as it might seem. For every dollar spent developing software, about 40 cents are spent on analysis and design, before the code is written, and about 35 are spent on integration and installation after the modules have been written and tested. (Experience with modern practices suggests that early-phase expenses will continue to grow at the expense of coding.) This means that if we could construct a system entirely out of reusable code we would still only be reducing our development costs by some 25 percent (ignoring the added costs of reuse). At the more attainable level of 50 percent reuse, we would be reducing costs by one eighth. This is a respectable saving, but it is nowhere near what we might hope to achieve through reuse.
Significantly greater savings can also be realized if we can reuse the products of earlier analysis and design efforts. This would be relatively simple if variation in the architecture of ostensibly similar systems (e.g., two inventory systems) were due primarily to arbitrary design decisions. In practice, systems at different sites, even if they serve similar functions, must interact with different environments.
A related issue is the granularity level of reusable components. At the highest level, we could have an entire application intended for reuse -- which is exactly the purpose of a application package, such as a payroll package. (These are also called "commercial off-the-shelf," or COTS, applications.) At the lowest granularity level, we might have very small reusable chunks of code, as we find, for example, in the typical subroutine library of mathematical functions.
The choice of granularity involves a tradeoff. On the one hand, a large granule of code yields a very high productivity gain when it is reused, but it is generally hard to find a close fit between a user's needs and large aggregations of code. On the other hand, a library of many small granules generally provides chunks of code that match a user's needs, but the productivity gain is smaller and the problem of indexing and search is greater. (Mathematical subroutines have been used for a long time and yield tremendous benefits despite their generally fine granularity because they are relatively easy to comprehend, standardize, and index.)
Most systems inherit the data with which they must work and the other systems with which they must interact, so that adapting one architecture to another environment may not be practical on a single-project basis. Also, in administrative systems, half the development effort may be spent on the user interfaces. If these do not fit existing preferences and habits, the result will often be a high level of user dissatisfaction.
For every dollar spent developing a system, two dollars are subsequently spent maintaining it. Very little of this is spent fixing flaws; most of it goes to modifying the system to keep it useful and usable in a changing world, often over a lifespan of ten to twenty years.
Code reuse can indirectly reduce maintenance costs. The characteristics of a module that make it reusable -- good documentation, thorough testing, high cohesion, clean and minimal coupling -- are also the characteristics of good maintainable code, whatever the language used to code it. Multiple use of a module within the same system further reduces maintenance costs by reducing the number of modules that need to be modified to accommodate a given change.
The fact that a module was originally an instance of reuse will not reduce the cost of modifying it. (Savings will be realized, of course, if the same modifications must be made to multiple instances of a module, and those instances are being maintained by the same programmers.) Much of the maintenance effort will, however, involve the writing of enhancements, and this presents new reuse opportunities. If code reuse during development reduces downstream life cycle costs, it is primarily by being associated with good programming practices.
D. Industry Experience
A number of organizations (with non-Ada environments) have attempted to achieve high levels of code reuse. They have developed repositories and mandated design-for-reuse, and achieved reuse levels in the 30-50 percent range.
There are some intrinsic advantages to such single-organization repositories. There are common architectural standards, common styles, and related application domains that make it much more likely that a given module will be usable elsewhere within the one organization. The continuity of personnel makes it more likely that a reuse opportunity will be recognized or remembered from a previous project, greatly reducing the cost and frustration of searching the repository.
The advantages of familiarity and commonality appear to be crucial. One organization that established a company-wide repository found that less than 10 percent of the reuse involved reuse across application areas. It also found that, beyond a certain (and modest) repository size, the level of reuse reached a plateau, and did not increase as the repository grew. Programmers reused little software with which they were not personally familiar.
It is worth noting the most common instances of successful non-repository-based reuse: application generators and off-the-shelf systems. Application generators capture most of the benefits of reuse by restricting their domain. They succeed by identifying common functions within their domain to meet the needs of enough customers to establish a profitable market. Off-the-shelf systems tend to offer their user less flexibility than they would prefer -- but at a greatly reduced cost and risk. Such systems are often customizable, to a greater or lesser degree (generally through the specification of appropriate parameter values).
Thus we have three competing reuse paradigms. In the application generator, the line between reuse and custom-programming with a 4GL is blurred. In the off-the-shelf application, we accept an imposed design for the sake of the savings this brings. Repository-aided custom programming is effective to the extent that there is a good fit between our architecture and that supported by the repository.
In all three cases, significant savings through reuse are only realized when we take advantage of previously performed domain analysis and design. Only minor savings can be realized through the spare-parts-bin approach to code reuse.
The amount of new code that must be written may be cut in half through a program of code reuse. Even if the only benefit of reuse is the reduction of programmer effort, this can still mean a reduction of over 10 percent in development costs. In DoD, this translates to an annual saving of over $250 million in the development and enhancement of management information systems. Greater savings may be realized if reuse is extended to all phases of the software life cycle.
Ada simplifies some of the technical barriers to code reuse, and may reduce the costs of integrating reusable software into a system. (This advantage may be compromised if a developer using an integrated CASE environment attempts to reuse Ada code produced and maintained by a different integrated CASE environment.) Code reuse, however, will not simply "happen," no matter what language is used. Successful code reuse, in various languages, requires the construction of well-supported and relatively specialized repositories, with funds and backing.
Management information systems have great potential for reuse within DoD. They are well understood. There are great commonalities of function across sites. Unlike embedded systems, most of the MIS work is done in-house. The CIM initiative is aimed at capturing the great advantage of achieving high reuse while still preserving adequate flexibility.
While it is not practical to mandate a single architecture at this time -- for one thing, systems must continue to interact with the billions of lines of old code that have accumulated over the past decades -- it is possible to encourage movement in that direction:
The objective of this appendix is not to demonstrate whether Ada is or is not the most cost-effective language for all projects. We believe no one can at this point. Not only is the total number of DoD projects using Ada unknown; the costs and benefits of Ada implementation are also unknown.
Our objective, instead, is to present a framework to support (not replace) a decision maker in conducting a cost-effectiveness evaluation of Ada. Specifically, we present a set of issues that we feel need to be addressed, as well as summarize available empirical findings.
To assess the economic impacts of Ada, one must look beyond a single program's development cycle. "The major costs associated with software management encompass the total lifecycle. Accordingly, the economic and productivity aspects must encompass the post-deployment support as well as initial development and acquisition costs" (McPherson, 1991). Furthermore, the analysis should not be constrained to a "project-in-isolation" perspective. Instead, one needs to consider the economic implications on the aggregate portfolio of software programs in the DoD.
Our discussion will cover the following points:
A. Non-Deployment Opportunity Cost
One of the major challenges facing the DoD is the imbalance that exists between DoD's demand for software systems and the available supply of programming manpower. While the average productivity of individual developers is increasing over time (e.g., with training, new CASE tools, etc.), the rate of increase is rather small. Most researchers point to about a 4 percent average increase in programmers per year, with somewhere around 12 percent required to stay even (Charette, 1986). As a result, both DoD as well as the commercial sector are experiencing mounting backlogs of new applications.
The productivity of a single programmer is measured in terms of some output (say in lines of code) per person-month. The productivity of an organization, on the other hand, is measured in terms of aggregate output per unit of time, where:
Organizational Productivity = (productive members) * (average productivity)
As argued in the main body of this report, integrated 4GLs are powerful tools that can significantly enhance programming productivity in the 1990's (Emery and Gremillion, 1991). DoD's organizational productivity may be enhanced further, and perhaps more significantly, by increasing its pool of "productive members." Many organizations have successfully achieved this by promoting and facilitating end-user computing. The DoD can achieve similar gains, at least for a subset of its applications (e.g., spreadsheet applications and small administrative systems).
Experience in the commercial sector suggests that end-user computing has been facilitated, in large part, by the availability of user-friendly 4GLs and domain-specific software development tools. Such tools allow end-users to create entire applications themselves, and to create them quickly. The tools provide such capabilities as graphics, spreadsheets, modeling, and ad-hoc information retrieval. They are easy to learn and easy to use.
Ada, in comparison with successful end-user tools, is not easy to learn or use. "Ada requires more experience than other languages before personnel can become proficient. This is because of the unique features of the language (generics, tasks, overload operators, exception handlers, etc.) that are not present in other languages. It was generally agreed that it will take longer to appreciate the trade-offs in determining which feature of the language is best to implement a particular algorithm" (IIT, 1989).
We, therefore, recommend that consideration should be given to relaxing the Ada enforcement directive for those application domains amenable to end-user computing.
B. Aggregate Post-Deployment Issues
The economic and productivity aspects of Ada encompass the post-deployment support as well as initial development and acquisition costs on the aggregate portfolio of software programs in the DoD. From an aggregate long-term perspective, standardizing around Ada is a powerful incentive. Lacking empirical findings to quantify this, we can only suggest that aggregate post-deployment benefits can be significant enough to favor Ada even where building in Ada may be slightly more expensive.
The long-term gains from standardizing around Ada fall in two areas: higher maintenance productivity and higher portability and reusability.
DoD systems (especially embedded systems) have long lifespans -- typically 10 to 15 years -- and must often be quickly adapted to frequent changes in the environment. As a result, maintenance costs of DoD systems have been, and will probably continue to be, high. "The features, functions, and structure of Ada are purported to make it easier to develop software that is more readable, more modular, more understandable, and, in general, more easily maintained" (Smith, 1991). Second, respondents in the Smith (1991) study reported that portability of Ada systems was significantly greater than that of systems written in other languages:
"Ada code is more portable than other languages for two reasons. First, the DoD is enforcing Ada as a standard by requiring that all Ada compilers used for military software pass a suite of tests that verifies conformity with the language definition. This requirement insures, as much as is possible, that dialects of Ada are not used for the development of DoD software... Second, Ada has language features such a packages and representation specifications that allow software developers to isolate machine dependencies in the software" (Smith, 1991).
C. Development and Acquisition Cost Issues
We start our analysis by summarizing the available empirical data pertaining to Ada's cost-effectiveness. These empirical results should be used with caution, however. The problem, in part, is that none of the studies was designed specifically for the purpose of assessing the economic benefits of using Ada vis-a-vis other languages. Such a study is urgently needed.
1. A summary of empirical results. Four findings summarize the results of the empirical studies published to date.
In a study by Reifer (1991), "Ada projects which have their productivity numbers public are showing about a 20% decrease in costs (over time) after they have made the transition to what is called the 'Ada mindset.' The mindset involves learning and applying new software engineering principles, modern methods like OOD (Object oriented design), and advanced packaging concepts and tools, as well as the Ada programming language itself." There is a significant learning delay. A finding by RCI researchers (Reifer, 1991), suggests that it takes at least three to five Ada projects worth of Ada experience before significant productivity gains can be achieved.
Similar results were observed by the Navy Center for Cost Analysis (Gross, 1990):
FORTRAN Project 1st Ada Project 2nd Ada Project 3rd Ada Project LOC/man-day 12-30 22 26 34 % code reuse 5-20 0 15-35% 25-42 Errors/KLOC 3.5-8 2 1.5 1
The learning curve is driven by two issues: the difficulty of learning the language and the amount of time to become proficient in it.
Because Ada is a relatively new language and Ada programming support environments are still evolving, a body of trained personnel are not available to develop new Ada systems.
"Ada projects will not be able to benefit from lessons learned in previous projects which in turn will lengthen the development schedule. In addition, ... Ada requires more experience than other languages before personnel can become proficient. This is because of the unique features of the language (generics, tasks, overload operators, exception handlers) that are not present in other languages" (IIT, 1989).
The effort distribution of an Ada project may differ from projects using other languages because of the emphasis placed on the early stages (requirements and design) of the lifecycle.
A great amount of effort is devoted to the requirements and design phase of Ada software development projects when compared with traditional software development projects. This increased initial investment is offset by a corresponding decrease in later phases, such as when writing and testing the code (GAO, 1989).
One of the controversial findings is that Ada projects get cheaper as they get larger (Reifer, 1991). The general relationship relating cost and project size takes the form:
The term p is referred to as the power law. If the power law is less than one, an economy of scale exits. The analysis reported by Reifer (1991) for more than 140 Ada projects "has yielded a power of 0.95, after the transition to Ada has taken place. This finding has been substantiated independently by a recent detailed statistical analysis of AFATDS data."
2. Significant cost drivers. While the above empirical findings do provide useful insights into the economics of Ada, they certainly fall well short of providing all the answers. In fairness, it must be stated that the above studies were not designed to specifically assess the economic benefits of using Ada vis-a-vis other languages. In this section, we seek to present a complementary "tool" to tackle the cost effectiveness issue: the set of cost drivers that can exert a significant impact on Ada software development. Specifically, we will discuss the following set:
a. Effective size.
"The most significant influence on software costs is the number of source instructions one chooses to program" (Boehm, 1987). Besides the inherent size of the system being developed (a language independent driver), the effective number of instructions to be built will be affected by the level of the programming language, the degree of reuse, and the amount of rework.
Programming language level.
A 1987 SEI report compared the size of Ada programs vis-a-vis other languages. It was found, for example, that Ada could yield 50 percent more lines of code than languages such as FORTRAN. A number of explanations were presented:
"Ada is generally more specific and more complete than (FORTRAN), resulting in more lines of code. The benefit is that Ada code should be more reliable and easier to read, understand, and maintain. Ada is richly declarative and descriptive regarding data structures. These characteristics increase lines of code and also allow more errors to be caught by the compiler as compared to languages such as FORTRAN that do not possess these capabilities" (SEI, 1987).
There were no studies that directly compare Ada to 4GLs. Capers Jones' (1986) comparison of the number of source statements required to code one Albrecht function point provides one benchmark. His results indicate that 71 Ada statements were required to code one function point. On the other hand, only 16 statements were needed by 4GL query languages, and even less (6 statements) by spreadsheet languages.
Still, Ada does have several features that could potentially enhance productivity: packages, overload operators, strong typing, generics, tasks, and exception handlers. The complexity of the features to be used on a given system depends strongly on the application type of that system (avionics, business, command and control).
"For example, a business system and a command and control system would both contain exception handlers but the difference would occur in the complexity of the exception handler. In a business system, the exception handlers may be less complex because a critical error would cause only loss of data. In a command and control system, the handlers would be more complex because a critical error could cause loss of life" (IIT, 1989).
Smith (1991) found that Ada code can be easier to reuse than the code of other languages. Two factors contribute to this. First, DoD's validation of all Ada compilers to verify conformity with the language definition minimizes the dialect proliferation problem. Second, Ada has language features (packages, representation specifications) that help isolate machine dependencies.
A high level of rework on a project translates into lower productivity, as more and more resources are diverted from producing new products to reworking old faulty ones.
A great amount of effort is typically devoted to the requirements and design phase of Ada software development projects when compared with traditional software development projects. This increased initial investment often translates into a corresponding decrease in requirements and design errors (which often constitute the most expensive type of rework). Furthermore, the Smith (1991) study found that:
"... bugs in Ada code were relatively easier to find and fix during development... In part, this is due to the extra checks that Ada compilers are required to do during compilation. The structure of the language itself also appeared to contribute to the ease of locating and correcting code errors. The constructs of the Ada language facilitate the compartmentalization of the code. If used properly, these features help to localize the effect of changes to the code that must be made to correct code errors."
b. People Issues.
Because of the emphasis placed in Ada projects on the early stages (requirements and design) of the life cycle, Boehm and Royce (1987) found that analyst capability differences were more significant on Ada projects, while programmer capability differences were less significant. In addition, the richness and complexity of Ada creates wider productivity ranges. This translated into:
Organizations that are relatively advanced in the practice and processes of software engineering will thus have an easier time adopting and utilizing Ada. Smith (1991) recommends that organizations have at least one in-house Ada guru, that is -- a person that has a very deep understanding of the language and its features.
c. Development Tools.
Many vendors are now offering tools for designing, controlling, documenting, testing, and maintaining Ada software. The Ada Programming Support Environment is a set of coordinated tools for the Ada language. It contains such software tools as text editors, compilers, linkers, static analysis tools, dynamic analysis tools, terminal interface routines, file administrators, command interpreters, configuration managers, etc.
The GAO study (1989) suggests that while many of Ada's basic tools are now available, the problem is that many tools are not yet mature. Once they do mature, the cost of software development in Ada would be expected to decrease further.
Boehm, B., "Improving Software Productivity," Computer, September, 1987, pp. 43-57.
Boehm, B. and W. Royce, "Ada COCOMO: TRW IOC Version," Proceedings, Third COCOMO Users' Group Meeting, SEI, Pittsburgh, PA, Nov, 1987.
Charette, R.N., Software Engineering Environments: Concepts and Technology, Intertext Publications, Inc., 1986.
GAO, "Programming Language: Status, Costs, and Issues Associated with Defense's Implementation of Ada," United States General Accounting Office, Washington, D.C., March, 1989.
Gross, S., Presentation at the Naval Postgraduate School, Fall, 1990.
Emery, James C. and Lee. L. Gremillion, "Adopting a New Software Development Paradigm: A Strategic Imperative,", Naval Postgraduate School, April 1991.
IIT Research Institute, "Estimating the Cost of Ada Software Development," IIT Research Institute, Lanham, Maryland, April, 1989.
Jones, C., Programmer Productivity, McGraw-Hill Book Company, 1986.
McPherson, M., Personal communication.
Reifer, D., "Economics of Ada -- Guest Column," Ada Strategies, Vol. 5, No. 1, January, 1991, pp. 8-9.
SEI. "Ada Adoption Handbook: A Program Manager's Guide," Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-87-TR-9, May, 1987.
Smith, G. N. "Firms' Adoption and Use of New Information Technologies: A Theoretical Framework and an Empirical Investigation of Ada in the U.S. Defense Industry," GSIA, Carnegie Mellon University, April 18, 1991.
As DoD grows smaller in manpower and resources, and as warfare technology gets increasingly more sophisticated, it is expected that artificial intelligence (AI) and decision support systems (DSS) technology will play a prominent role in maintaining and enhancing our combat readiness. With AI/DSS technology, scarce expertise could be preserved and decision making capabilities could be enhanced. Also, end-user computing (EUC) could improve productivity of computer users. AI/DSS has been widely used for military applications (Lehner, 1989), ranging from real-time systems operating under severe time constraint and stringent performance requirements (e.g., Adaptive Tactical Navigation of Fighter Aircraft, missile-tracking systems, Navy battle management) to managerial and technical tasks (e.g., logistics planning, inventory management). The purpose of this section is to address some current issues related to the use of programming languages or tools to develop AI and DSS applications and support end-user computing.
A. Artificial Intelligence, Decision Support Systems, and End-User Computing
In a broad sense, AI encompasses automated applications that exhibit intelligent behavior. Applications of AI include natural language processors, speech recognition, robotics, computer vision and other sensory systems, intelligent computer-aided instructions, automated planning systems, and expert systems. Expert systems are computer programs that use a knowledge base and inferencing techniques to solve problem that would normally require human expertise.
Decision support systems are interactive computer-based systems that help decision makers utilize models and data to increase the efficiency and effectiveness of their decision making. A DSS provides decision makers with selected information and with the capability to perform interactive sensitivity analyses. A special kind of DSS is an Executive Information System (EIS), designed to deliver timely information support to senior managers. To quickly access to corporate data bases, an EIS filters, compresses, and tracks critical information and displays data in a flexible and user-friendly interface.
With the continued improvement of user-oriented software versus the considerable backlog of user requests for the quick implementation of computer applications, an increasing number of (non-IS) end users design and develop their own information processing systems. This end-user computing (EUC) phenomenon continues to grow due to the proliferation of powerful, inexpensive, and user-friendly microcomputers.
B. Programming Language Options for AI Systems
1. Expert systems and expert system shells. Among the categories of AI applications, expert systems are by far the most widely used. The main components of an expert system include knowledge acquisition facility, knowledge base, inference mechanisms, user interface, and explanation and tracing facilities. Expert systems have been successfully implemented in a variety of stand-alone applications. In the near future, expert systems will serve as integral components of data processing (e.g., as part of a sophisticated user-interface or an "intelligent" logistics system).
There have been a number of expert systems written in conventional languages such as Ada, C, and Pascal. However, most AI systems were built with general AI languages (i.e., Lisp, Prolog, or OPS5) and specialized AI languages (e.g., KRL, FRL, K:base). These AI languages make it easier to handle symbolic processing and recursive problem solving, which are essential features of virtually all AI applications.
There are a number of commercially available expert system shells built to enhance the development productivity. An expert system shell encompasses all of the logic required to build an expert system. A simple 300-rule expert system, for example, might take less than three months to build with a shell; the same system would typically take at least a year to develop from scratch with a conventional 3GL. Expert system shells are being integrated with existing IS tools such as DBMS and 4GLs.
With the growing power of these tools, there is little justification for not using a high-productivity shell to develop expert systems.
2. Ada as a language for AI. Ada, as a language for AI, has a number of strengths:
Although Ada does not support some desirable features of an AI programming language, many researchers and developers alike agree that Ada is a versatile programming language applicable to AI. However, Ada does not have the capabilities of intelligent interfaces nor interactive design. The interface in knowledge design is not a mere factor of user-friendliness. WYSIWYG (what you see is what you get) and WYDIWYS (what you do is what you see) are crucial features of a programming language development environment for the acquisition, synthesis, evaluation, and verification of complex domain knowledge. It is critical to have an intelligent user-interface embedded in a development environment that allows developers to perform incremental and interactive knowledge acquisition and design. The knowledge acquisition and representation tasks are the most time-consuming phases of an expert system development. Currently, there exists a number of proven expert system building tools that offer a code-transparent environment (e.g., NEXPERT/NEXTRA) to allow quick development of prototypes and run-time systems without writing code.
Ada, as a 3GL, does not provide an effective environment for incremental and interactive knowledge engineering. Ada should not be used without software engineering tools. It is important to define specifications and develop an integrated, machine-independent CASE workbench for developing AI Ada applications. Such a workbench should include at least a graphical programming environment to support knowledge acquisition, an open architecture to permit integration with data base systems and others, and a code generator. Without such a tool, Ada runs the risk of forcing developers to focus on the subtleties of programming principles and techniques rather than on the understanding of the application domain to be programmed.
3. Ada as a language for real-time systems. Real-time and time-critical AI systems must provide a good solution quickly. Military real-time systems are often embedded within existing software performing real-time conventional tasks (e.g., simulation) to provide real-time decisions. With its modularization and concurrent programming capabilities, Ada is designed to overcome the performance limitations of other AI technologies that are slow in scanning huge search spaces. The professional literature does report some success of using Ada in real-time systems.
For real-time and time-critical AI applications whose domain applications are complex and whose lifetime is significantly long, using Ada could be more cost-effective in the long run. On the other hand, for non real-time and non time-critical AI applications that require very short development time, whose domain application is narrow and specific, and whose anticipated lifetime is short, using well-proven expert system building tools appears to be considerably more cost-effective.
C. Programming Language Options for DSS
1. DSS and DSS generators. Technically speaking, any programming language could be used to develop a DSS. However, the most cost-effective and expeditious approach is to obtain a domain-specific language that is specifically designed for the problem at hand.
There exists two broad categories of domain-specific languages: 1) languages that are dedicated to a special type of decision problem within a narrow problem domain (e.g., financial planning, interactive linear/integer programming, simulation, project management, statistical analysis); and 2) languages that are developed to provide a wide range of generic applications (e.g., Lotus 1-2-3 and FOCUS for managerial decision making and reporting).
Experience reported in the DSS literature suggests that using domain-specific languages typically increases productivity by a factor of at least 10 to 1 relative to COBOL for applications that involve sophisticated information retrieval, complex analytical models, or graphical interfaces.
When no domain-specific language can be found for a specific DSS application, the next best alternative is to adopt a patchwork approach. This consists of assembling the various components of the DSS from commercially available software products (e.g., database management systems, screen painters, report generators, graphic generators, and communications packages). Although the patchwork approach is typically more expensive than the domain-specific language approach, its cost is still far cheaper than developing from scratch in a 3GL.
It is desirable to select a software development environment that is easy to use and inexpensive, and allows quick prototyping to yield immediate payoffs. The use of domain-specific products offers the possibilities of processing ad hoc requests without the user having to resort to initiating a formal project and working through a professional programmer.
2. DSS and Ada. Most DSS applications rely heavily on database management and the effective use of sophisticated user interfaces. Current Ada compilers are weak in supporting DBMS and generating graphical interfaces. As with any other 3GL, Ada is not cost-effective for DSS applications that need to be developed quickly for ad hoc problem solving, or for problem solving that is recurring but has limited generalization potential. But this is by far the most common environment for DSS.
Using a 3GL to build DSS should only be considered as the last alternative, when the off-the-shelf and patchwork approaches fail. Building the DSS in Ada is justified only when:
D. Programming Language Options for End-User Computing
The predominant factor that determines the programming language to be used for EUC is the user's programming background and experience. Ease of use, development cost and time, flexibility, portability, and independence from data processing professionals are other important considerations (Rivard and Huff, 1988).
The rationale behind EUC is to improve user productivity. If end users can choose their own software tools to develop their DSS, they may get their work done in less time than it would take merely to explain what they want to a programmer. Enforcing a standard and unique programming language for EUC would be entirely counter-productive. For example, BASIC (which is generally considered to be the easiest 3GL to learn and use) is not, in general, well-suited for DSS applications developed by end users. Ada would be even less suitable.
Recently, low-end 4GLs have shown promise in helping develop user-oriented applications. These 4GLs provide a wide range of pre-built procedures and programming facilities that can be called by interactively issuing a few descriptive commands. To generate a report with such a 4GL, only a few command lines are required. A conventional procedural language like COBOL could require 500 to 1000 lines of codes to accomplish the same task. (These are not the type of integrated 4GLs designed for the development of large-scale MIS, which are aimed at professional developers rather than end users.)
From the organizational standpoint, end-user computing may cause the organization to loose control of its computing power and uniformity of software development. An end-user application is, by definition, developed by computer amateurs to solve narrow domain-specific problems of their own. It tends to be error-prone, fragile, and undocumented -- not at all suitable for widespread use outside of the individual or workgroup that developed it. The original developers typically have little or no incentive to put in the extra effort to make their application transportable to other users.
If an end-user application proves valuable enough for more general use, it should be taken over by a professional support staff for re-writing, certification, documentation, and continued maintenance support. A solution might be to encourage the development of a few standardized 4GLs in Ada to avoid the uncontrollable proliferation of a diversity of existing 4GLs operating under a variety of computing platforms. A new generation of 4GLs in Ada not only would respond to specific user needs but would also provide uniformity. Uniformity supports portability, adaptability, and increased potential for reuse.
High-productivity domain-specific languages should be used for EUC and the development of expert systems and DSS. There is little justification for the use of Ada (much less with other 3GL) unless these specialized development tools do not meet the functional requirements of an AI/DSS application. Ada is not an effective and efficient approach to develop applications that require fast delivery time and frequent updates.
Using Ada as a standard programming language for AI applications presents two significant advantages. First, Ada is designed for real-time and time-critical applications. Second, using Ada as the only programming language may create a software discipline that enforces standards in the development, utilization, and maintenance of AI software. However, Ada needs to be more productive to challenge the effectiveness of currently available specialized languages.
Baker, Louis, Artificial Intelligence with Ada, McGraw-Hill, New York, 1989.
Hatley, Derek, J., and I.A. Pirbhai, Strategies of Realtime System Specification, New York, Dorset House Publishing, 1988
Lehner, Paul A., Artificial Intelligence and National Defense: Opportunity and Challenge, Tab Professional and Reference Book, Blue Ridge Summit, PA, 1989
Marzjarani, Morteza, "A Comparison of the computer Languages Pascal, C, LISP and Ada," Journal of Pascal, Ada, and Modula-2, February 1988.
Proceedings of the Annual Conference on Artificial Intelligence and Ada, Department of Computer Science, George Mason University and Software Productivity Consortium, 1987, 1988, 1989, 1990.
Rivard, Suzanne, and S. Huff, "Factors of Success for End-User Computing," Communications of the ACM, May 1988, Vol. 31, No. 5.
Turban, Efraim, Decision Support and Expert Systems: Management Support Systems, 2nd Edition, McMillan, New York, 1990.
Thompson, Linda, "Wired to Realtime," SunTech Journal, February 1991.
This appendix examines existing and draft policies of various DoD services for programming languages. Its purpose is to highlight the policies of the services and agencies as they presently exist. The key points of the Army and Air Force policies are discussed. These are the most recently updated, and include consideration of Ada's use in MIS applications. The Navy is in the process of reviewing its draft policy. The various agency policies, which focus primarily on embedded system applications, are being reviewed in light of the recent legislation. (Copies of the present policies of most agencies and the services are included in the bibliography document accompanying this report.)
In addition to the Air Force and Army policies, we consider the draft policy recommendations of the AEO/AJPO Working Group on Waiver Policy. This group is composed of representatives from OSD, the services, and DoD agencies. It has been meeting for over a year, since April 1990, debating at length the major issues dealing with waiver policy. A detailed draft policy statement has been proposed. We believe that this document would be an excellent starting point from which to establish DoD Ada waiver policy.
From gathering information for this topic, we conclude the following:
A. Air Force Policy
Present Air Force policy is stated in a memorandum from the Deputy Assistant Secretary (Communications, Computers & Logistics), dated August 7, 1990. It calls for an aggressive move to Ada and covers all computer software systems, including weapon systems, command and control systems, automated test equipment, and information systems. The policy lists the following three exemptions, which require no waiver request:
Air Force policy also presents other cases that do not require a waiver. Support tools for AFLC with specialized operating systems and for which no validated compiler exists do not require a waiver. Simulators and stimulators are given as examples. Also, industrial process equipment acquisition programs for which AFLC is the implementing command do not require a waiver. This includes stand-alone micro controller devices and devices in which microcomputers are used as microcontrollers.
Air Force policy also provides the following order of preference for software requirements:
This policy statement also covers several other situations. Systems that are under development using a non-Ada language that were authorized prior to August 7, 1990, are authorized to complete development and deploy the system without converting to Ada. Air Force policy requires either an exception request or a waiver request for most cases in which Ada is not being used. The exception request includes a description of the project and a rationale/justification for the exception. In addition to what the exception request requires, a life cycle analysis is submitted as part of a waiver request.
Ada is required when existing software programs are altered by more than one-third at any one time. A 4GL may be used to support rapid prototyping and evolutionary development, but requires an exception request. To use other languages mixed with Ada to provide a special function or routine in an Ada software program requires an exception request. Small projects for which Ada is not feasible or cost-effective over the system life cycle require an exception request. Specific guidelines are given for the life cycle analysis; they include:
A memorandum in March 1991 requires that any initial investment in Ada support environments, tools, training, etc. be amortized over all future anticipated Ada projects; this amount could not exceed 50 percent since the investment would be used for future projects. Software for which waivers were not required in the August 1990 memo were deemed cost-effective and did not require a life cycle analysis.
B. Army Policy
Army Ada policy is spelled out in HQDA LTR 25-90-1, dated July 16, 1990. It applies to automated information systems, intelligence systems, tactical systems, and weapon systems. The policy did not apply to systems that had already entered into full-scale development or deployment, or that had previously been granted a waiver.
Ada is mandated as the programming language for all computer resources used in the Army unless another approved language is estimated/calculated to be more cost- effective or more operationally effective over the application's life. When Army systems must interface with non-DoD agencies, Ada is preferred but not required. A software upgrade requiring modification of more than one-third of the existing code over a program's system life cycle requires a waiver if a language other thus Ada is proposed.
Army policy states that an analysis of life cycle cost and operational efficiency shall be the basis for acquiring or developing software components. Army policy provides that the following approaches should be used in software development, listed in the "preferred order":
A waiver request justification must address such issues as limitations, documentation, portability, maintainability, and usability of the proposed software language or package. A complete life cycle economic rationale for both an Ada alternative and the requested language is required. Waiver requests for all new initiatives must be approved prior to Milestone I approval. Other considerations include the long-term costs of supporting programmers, environments, and software code for diverse languages. Army waivers may only be approved by the DISC4.
C. Ada Waiver Policy Working Group
A draft version of the policy proposed by the Ada Waiver Policy Working Group requires waiver approval if software development, acquisition, and upgrades are not written in Ada. This policy also lists the details for the waiver request package to be submitted if Ada is not to be used. In addition, it provides for exceptions and exemptions from using Ada.
The following exemptions require no waiver:
A second category, named "exceptions," would require the submission of a justification for not using Ada, called a "letter of intent." The letter of intent would include a cover letter, system/project description, justification, transition plan, and statement of maintenance.
A letter of intent would be required under the following circumstances:
A waiver would be required for all DoD software not written in Ada and not covered by exemptions or exceptions. The waiver request package consists of a cover letter, executive summary, system/project summary, life cycle cost analysis, transition plan, risk analysis, and statement of maintenance.
This policy also addresses two other key topics: waiver approval authority and enforcement. It indicates that waiver authority would be delegated to an Ada official in each of the services and agencies. It states that policy violations would be subject to punitive measures that could effect funds and implementation. Adverse personnel actions are also possible. It calls for Ada implementation to be a "designated inspection item," but does not define this term.
This is a list of articles and publications that offer additional background into topics covered by the study. This list includes some, but not all, of the references used in the study. Other articles were included because they discuss topics relevant to the study.
The references are grouped into the following topics:
Overall Software and System Development
Brooks, Frederick P., Jr., "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computer, Vol. 20, No. 4, April, 1987, pp. 10-19.
Emery, James C., and Gremillion, Lee L., "Adopting a New Software Development Paradigm: A Strategic Imperative," April, 1991.
Luqi, "Software Evolution Through Rapid Prototyping," IEEE Computer, Vol. 22, No. 5, May, 1989, pp. 13-25.
Hines, Keith, "Ada Impacts On a Second Generation Project," TRI-Ada '90 Proceedings, December, 1990, pp. 488-492.
PRISM, "Research Summary," Refractions -- The New World of Systems Development, December, 1988.
Productivity and Cost Effectiveness
Rivard, Suzanne, and Huff, Sid L., "Factors of Success for End-User Computing," Communications of the ACM, Vol. 31, No. 5, May, 1988, pp. 552-561.
Reifer, Donald J., "Economics of Ada -- Guest Column," Ada Strategies, Vol. 5, No. 1, January, 1991, pp. 8-9.
Boehm, Barry W., "Improving Software Productivity," IEEE Computer, Vol. 20, No. 9, September, 1987, pp. 43-57.
Reifer, Donald J., "SoftCost-Ada: User Experiences and Lessons Learned at the Age of Three," TRI-Ada '90 Proceedings, December, 1990, pp. 472-480.
Sherman, Bruce, and Stringfellow, Stan, "Improving Programmer Productivity With Ada," Defense Computing, Vol. 3, No. 5, May-June, 1990, pp. 26-29.
Rowe, Jeffrey, "Producing With Ada -- Real-Time Solutions for Complex Problems," Defense Electronics, Vol. 22, No. 7, July, 1990, pp. 41-52.
Boyd, Stowe, "Developing Ada Capabilities in the Distributed Environment," Defense Computing, Vol. 3, No. 3, March, 1990, pp. 27-29.
Interfacing Ada and SQL
Graham, Marc H., "Down in the Details: Lessons learned in interfacing Ada and SQL," TRI-Ada '90 Proceedings, December, 1990, pp. 46-53.
Software Reuse and Software Maintenance
Krutz, William K., "Software Reuse Offers The 'Missing Link' in CAIS," Defense Electronics, Vol. 23, No. 3, March, 1991, pp. 49-55.
Wild, Frederic H., "A Comparison of Experiences with the Maintenance of Object-Oriented Systems: Ada vs. C++," TRI-Ada '90 Proceedings, December, 1990, pp. 66-73.
Syms, Trevor, and Braun, Christine L., "Software Reuse: Customer vs. Contractor Point-Counterpoint," Ada: The Choice for '92, Ada-Europe International Conference Proceedings, May, 1991, pp. 326-337.
DoD/Service/Agency Ada Policy Documentation
DoD Directive 3405.1, "Computer Programming Language Policy," 2 April 1987.
DoD Ada Waiver Policy, Draft, Undated.
Headquarters, Department of the Army Letter HQDA LTR 25-90-1, "Implementation of the Ada Programming Language," 16 July 1990.
SECNAV Instruction 5234.2, "Computer Programming Language Policy," 3 November 1988.
Deputy Assistant Secretary of the Air Force (Communications, Computers & Logistics) Memorandum, "Air Force Policy on Programming Languages -- ACTION MEMORANDUM," 7 August 1990.
Deputy Assistant Secretary of the Air Force (Communications, Computers & Logistics) Memorandum, "Interpretation of FY 1991 DOD Appropriations Act -- INFORMATION MEMORANDUM," 5 April 1991.
Defense Communications Agency Instruction (DCAI) 630-230-29, "Automatic Data Processing Computer Programming Language Policy," 21 March 1990.
Defense Logistics Agency Regulation (DLAR) 4700.4, "Computer Programming Language Policy," 10 July 1989.
Strategic Defense Initiative Organization Directive 3405, "Strategic Defense System (SDS) Software Policy," October 1989.
Ada Information Clearinghouse, "The Congressional Ada Mandate," Form G36-0391 MANDAT90.HLP, March, 1991.
Ada Joint Program Office, "Briefing Slides on AJPO Initiatives in Education, Bindings, and Technology," May 1991.
Anderson, Christine, "Draft Ada 9X Transition Plan," February, 1991.
Crafts, Ralph E., "Ada/MIS Point Paper," May,