The Changing Context for DOD Software Development
For nearly two decades, the Ada programming language has been a cornerstone of efforts by the Department of Defense (DOD) to improve its software engineering practices. DOD created Ada in the 1970s to serve as a department-wide standard that would satisfy its special requirements for embedded and mission-critical software, and would also encourage good software engineering. Both the new language and the new software engineering ideas associated with it met with some criticism, and both have evolved as a result. Today, Ada is the most commonly used language for mission-critical defense software, which includes weapon systems and performance-critical command, control, communications, and intelligence (C3I) systems. DOD's inventory contains nearly 50 million lines of Ada code in these applications (Hook et al., 1995). Given the long operational life of such systems, DOD has made a significant investment in Ada technology. Ada is the second most commonly used language (after Cobol) for DOD automated information systems, which include payroll and logistics programs. The DOD inventory contains more than 8 million lines of Ada code in these applications (Hook et al., 1995).
Hopes for broad commercial adoption of Ada have not been realized, however. Its commercial use has been eclipsed by other languages, such as C, then C++, and, most recently, Java. DOD's inclusive approach in the development of the language, as well as its promotional campaigns in support of Ada, do not appear to have been successful in fostering adoption of the language beyond defense and other mission-critical applications.
During Ada's lifetime, DOD's position in the software market has shifted. Although DOD still has an influence, its share of the market has diminished-not because DOD's need for software has decreased, but rather because the size of the commercial software market has exploded, generating a corresponding increase in investments in commercial software technology. DOD made significant investments to develop Ada (both Ada 83 and Ada 95)1 and mandated its use on certain DOD projects. The DOD requirement to use Ada appears to have been beneficial for custom software that has no commercial counterparts (e.g., weapon systems and performance-critical C3I software). On the other hand, this policy has frequently been counterproductive in application areas that have strong commercial support. In these areas, DOD's policy has inhibited DOD from taking advantage of existing commercial infrastructure written in or for other languages.
GROWTH IN THE COMMERCIAL SOFTWARE INDUSTRY
Commercial software includes a great deal of powerful infrastructure software such as development tools, operating systems, database management systems, networking software, user interfaces, and transaction processing programs. It also includes rich and growing sources of software for applications that are similar to some DOD applications, such as management information systems; geographic information systems; and logistics, medical, engineering and scientific, and office-support systems. With the exception of some aerospace, transportation, and safety-critical applications software, little of this commercial software is written in Ada.
In the 1990s, the computing field has been transformed by technological advances, particularly in networking and in low-cost personal computing with associated tools. While these advances have had relatively little impact on traditional real-time embedded systems, they have completely altered the character of commercial information systems and the processes used to develop them. Information systems are now commonly built with a two- or three-level client-server architecture, and with a graphical user interface that is logically separated from computational steps and from a relational database. Specialized tools and fourth-generation programming languages (4GLs; see glossary, Appendix C) have been developed for building this class of applications. Such tools and languages, exemplified by Visual Basic and PowerBuilder, are extremely efficient for building small and medium sized applications, particularly where the demands for reliability and availability are less stringent than those for real-time embedded systems. Similar tools are now becoming available for the deployment of information systems across organizational intranets and the World Wide Web. Because in certain domains these tools and languages operate at a higher-level than does any traditional programming language (including Ada), they are often the most appropriate way to prototype and develop information systems. Finally, growth in Internet-based software has increased the already rapid pace of product development in the commercial software industry.
OBSTACLES TO BROAD ADOPTION OF ADA
One goal of the inclusive and extensive process undertaken to develop Ada was to create a language that would be widely adopted by the software community, beyond DOD. Utilizing commercial technology has become more important to DOD in recent years, as a combination of declining financial resources for DOD and great strides in commercial developments across all areas of advanced technology has led to an increasing emphasis on leveraging commercial technology in developing defense systems (DOD, 1994b, 1995b).
Ada has taken its place among the better known and widely used third-generation programming languages (3GLs; see glossary, Appendix C); however, it has not become as popular as its proponents had hoped. One study of programming language use estimated that Ada 83 applications constitute only 2 percent of all computer applications in U.S. inventories, and slightly more than 3 percent of all function points (Jones, 1996b). Ada is used primarily within the DOD community. Beyond that community, it has been adopted by some software developers for the civilian market, especially where there is potential defense market cross-over or where there are similar requirements, such as in commercial aviation, process control, and medical instrumentation.2 However, this commercial use is a small fraction of the total commercial software market.
Another indicator of Ada's limited market penetration is the supply of and demand for Ada-trained programmers. Jones (1996b) estimates that of the 1.92 million professional programmers in the United States, 90,000, or less than 5 percent, are Ada 83 programmers.3 In an informal review of software engineering employment opportunities advertised in two major newspapers, the committee noted that of more than 1,000 references made to individual programming languages and tools,4 fewer
than 3 percent of the citations referred to Ada; in comparison, C and C++ each accounted for more than 23 percent of the references. 5 While there are many ways to look at Ada's current market share, employment opportunities and professional growth were recurring concerns expressed in many of the presentations made to the committee.
Given current conditions and probable trends, it is unlikely that the use of Ada, including the recent Ada 95 version, will grow significantly beyond the DOD-dominated and related commercial niche of high-assurance, real-time systems where it is already strong. Some of the principal reasons for this conclusion are discussed in the following sections.
Low Commercial Awareness and Limited Sponsorship
Ada has never attained the broad following associated with languages such as C++ and, most recently, Java. Market research indicates that nearly all programming language decision makers in non-defense industries are aware of Cobol, C, C++, Fortran, and Pascal, but only two-thirds are aware of Ada; only one-fifth are familiar with Ada's characteristics (Telos, 1994).6
In decisions affecting adoption of programming languages, non-technical factors often dominate specific technical features. These factors include the broad availability of inexpensive compilers and related tools for a wide variety of computing environments, as well as the availability of texts and related training materials. In addition, grass-roots advocacy by an enthusiastic group of early users, especially in educational and research institutions, often has broad influence on adoption of programming languages. These advantages were largely absent when Ada was introduced in 1980. In contrast, C++ and Java both have achieved widespread acceptance and use. The strong military orientation of the publicity generated for Ada also may have served to alienate significant portions of the academic and research communities.
Historically, DOD has been Ada's only sponsor, and Ada has been focused almost exclusively on the military niche occupied by DOD and its contractors. In the past, Ada technology was subject to export control restrictions. The development of tools and components funded by DOD was targeted to DOD organizations and defense contractors. People and institutions outside DOD who were interested in Ada found it difficult to acquire compilers and training resources.
Many technical organizations evaluated Ada and its associated tools in the mid-1980s and decided not to use it. Most of those organizations have committed significant resources to other languages and technologies; thus they are unwilling to reconsider Ada, even though Ada 95 is significantly different from Ada 83 and the tools are far more advanced. Beyond the DOD-dominated niche, some organizations are unwilling to reconsider Ada because they continue to view Ada as a language that is suitable only for military applications.
Recently, DOD's Ada Joint Program Office has begun to promote the academic use of Ada by awarding educational grants and making lower-priced compilers available. While these activities have had an impact (see the next section), by themselves they are unlikely to be enough to make Ada popular. They have not been matched by development of infrastructure to make it attractive to the research community, where advanced software development is carried out and graduate students are trained.
Limited Extent of Academic Instruction in Ada
The popularity of a programming language in the academic world and its use in industry are often linked. Schools feel pressure to teach the languages that appear to be demanded most by the labor market. At the same time, the adoption of computer languages in the classroom can lead to commercial use.7 A manager who has been exposed to a language in school is more likely to be confident about
trying it out, and even more confident if it is one that many recent graduates appear to know. University research and development groups are also influential, since the advanced software concepts they develop tend to influence the next generation of commercial products. A language that is widely taught is more likely to be widely adopted.
Ada has not been widely taught in colleges and universities, particularly compared with Pascal, C, and C++; until recently, even the military academies taught programming in languages other than Ada. A survey of more then 2,300 colleges and universities worldwide that have computer science curricula identified only 285 institutions that offer any courses in Ada; 237 of them are in the United States (IITRI, 1996), and they include many small institutions, among them community colleges and technical institutes. Few of the leading computer science programs in the United States, as ranked by the National Research Council's assessment of graduate research programs (NRC, 1995), provide instruction in Ada: only 6 of the top 53 programs (and 1 of the top 10) were identified by the 1996 survey as offering Ada courses.
However, the IIT Research Institute's 1996 survey of Ada instruction also found that in fewer than 3 years, there was a 47 percent increase in institutions offering courses in Ada and a 43 percent increase in the number of Ada courses offered (both measured worldwide). A survey of institutions adopting Ada as a foundation language found that from 1993 to 1996 the number increased from 57 to 147 (Feldman, 1996).8 Yet the total is still comparatively small, and it is unclear how long this trend might continue without the strong sponsorship provided by DOD.
Limited Availability of Ada Tools and Compilers
Historically, compilers and other language-specific tools for Ada have been significantly more costly and slower in coming to market than those for C and C++. Initially, this was a matter of technology. Since Ada embodied new technology that provided technical challenges for compiler writers, production-quality Ada compilers were not available for several years after Ada's official debut in 1980. When they became available, they were large, slow, unreliable, and expensive. This slowed DOD contractors' transition to Ada from other languages and soured some early users. Because C compilers are much easier to build and have a higher expected sales volume, they have typically been the first available compilers for new microprocessors; C++ compilers have usually followed, and Ada compilers have often been the last to be available. The problems with Ada compilers also impeded the use of Ada in education. Thus, organizations seeking to adopt Ada faced near-term costs for new tools, especially the high-priced compilers, in addition to the cost of training people in a language that was not widely taught in academic institutions.
Currently, Ada compilers are comparable in quality to those of other 3GLs, and the increased hardware resources needed to run popular software, such as Windows 95, make the requirements of Ada compilers appear more modest. In addition, the availability of the GNU NYU Ada 95 Translator (GNAT) has reduced the cost and improved the availability of Ada compilers. GNAT is a component of the GNU compiler suite, sharing code-generation facilities with the GNU C and C++ compilers. The GNU C compiler is generally recognized as a high-quality compiler. The GNU technology makes it comparatively easy to support new processors; therefore, the GNU compiler is likely to be one of the first available when a new processor appears. A non-technical but important side benefit is the association of GNAT with the Free Software Foundation, which should help GNAT to shed some of Ada's military only stereotype. The entire GNU compiler suite is distributed widely over the Internet, without charge, and is also distributed by some hardware vendors. In addition to the freely available GNAT, the main compiler vendors (see below) also offer academic compilers to students at reduced prices.
The market for Ada compilers and tools has been estimated at $200 million annually.9 The modest size of this market has resulted in significant consolidation of Ada compiler and tool vendors over the past few years.10 There are now two dominant suppliers: Rational Software Corporation (which was formed by the merger of Rational with Verdix, which had previously acquired Meridian) and Aonix (previously Thomson Software Products, which acquired Alsys and Telesoft). In addition, there are several other vendors that focus mainly on niche markets. These suppliers include the Texas Instruments unit that was previously Tartan, TLD, OC Systems, DDC-I, RR Software, Intermetrics, Green Hills, ICC, and Ada Core Technologies (which was formed to support and commercialize GNAT). Several of the vendors, including the two largest, have product-lines other than Ada. It is not clear how this consolidation will affect the availability and price of commercial Ada compilers in the long-term.
Assumption That Ada Has to Control Everything
Ada provides some services, such as input/output, multitasking, time keeping, and interrupt handling, that are traditionally in the domain of an operating system. Early Ada implementations were designed with the assumption that Ada was in complete control of the hardware, with no operating system, and that all the software on a machine was written in Ada. This approach is effective for the programming of embedded systems, in which the applications need to run without an operating system. Since Ada hides differences between operating systems, these characteristics make applications more portable.
However, these features also mean that, when compared with a language in which services are obtained by operating system calls, it is harder to write an Ada run-time system. It is also more difficult to port it to a new operating system, although this cost can be balanced by the benefit of reduced effort in writing and porting Ada application programs. In early Ada applications, when compiler vendors lacked expertise in real-time kernel building, the run-time systems were a frequent cause of complaints related to the closed nature of the interface. Developers of embedded systems applications wanted to have more direct control over the hardware resources. Developers of conventional operating system applications were hampered by the lack of access to the full operating system functionality, and by the incompatibility of libraries written in other languages with the Ada run-time system. The situation has improved in recent years; Ada vendors have adopted a more "open systems" approach in which the Ada run-time system is layered over a commercial real-time kernel or a traditional operating system, and Ada 95 supports interfaces to other languages.
Need for Ada-compatible Application Programming Interfaces
An application programming interface (API) is a set of procedure and function specifications that provides access to the capabilities of a reusable software component, such as an operating subsystem for "windows" or network communications. The vendors of most commercial off-the-shelf (COTS) software components typically provide a C language API. For the COTS component to be usable by an Ada application, an Ada-compatible API must be provided; this does not mean, however, that the COTS product itself needs to be written in Ada (a misconception that was evident in several presentations to the committee). A vendor-provided Ada API often lags the C version by months or years (a very long time in the computer industry), and often costs more. An Ada developer can create an interface to a C language API without vendor support, but doing so can require intimate knowledge of the particular COTS product and/or the Ada language implementation. The earlier implementation of non-Ada APIs, and greater vendor involvement, also have led to earlier standardization. Thus, the time delay and extra cost or effort of obtaining an Ada API, and the delay in standardization, have become disincentives for
the use of Ada. An added disincentive is the challenge of keeping Ada APIs current with the frequent changes in COTS product features.
Labor Market Forces
Software engineers are likely to be interested in enhancing skills that they expect to be most valuable in the software engineering marketplace, which is now dominated by commercial opportunities. Thus, programmers have moved quickly to learn Java and Hypertext Markup Language (HTML; used to develop pages for the World Wide Web) because they see these as the next wave, which can carry them to new career opportunities. Similarly, software engineers might avoid using Ada if they see it as limiting their careers. Given the cyclical nature of DOD spending, recent downsizing, and layoffs, defense software engineers have reasons to consider preparing for a move to the commercial sector. Even those who believe Ada is technically the best solution for a given program may face conflicting incentives in choosing a programming language.
On the other hand, the committee heard testimony that, for developing the specialized software that is most critical to the DOD mission, knowledge of the application domain is harder to obtain and more valuable than knowledge of a particular programming language, or even of software engineering itself. Thus, software engineers who have expertise in defense-oriented applications are likely to be in greater demand in that sector than in the commercial marketplace, where their domain-specific skills would be less applicable. Likewise, employers in the DOD sector are highly motivated to keep experienced engineers because of the expense of training new ones in the relevant applications, as well as the cost and delay of obtaining a security clearance for a person entering from the commercial market. These dynamics contribute to the separation of the military and commercial markets for software engineers, which is similar to the separation of those same markets for aerospace engineers.
DOD PROGRAMMING LANGUAGE POLICY
DOD's decision to design Ada as a new programming language for embedded applications was a reaction to both the "software crisis" of the late 1960s and early 1970s and the advent of software engineering concepts. It was also a response to the fact that each of the military services had developed separate programming languages that each was planning to independently standardize, upgrade, and improve. Within DOD, software problems were contributing to project cost overruns and lengthy delays in system deployment. From 1968 to 1973, the total cost of DOD's computer systems increased by 51 percent, even though hardware costs were decreasing dramatically (Fisher, 1976). While some have argued that this increase could be interpreted as the legitimate cost of obtaining new functionality, at the time it was viewed as symptomatic of software development problems.
One visible aspect of DOD's software crisis was that systems were being developed in many different programming languages for many different computers, diluting resources and increasing the cost and complexity of maintenance. Many of the systems were written in assembly language for specialized, proprietary processors, or written in programming languages unique to a particular project or contractor. There was never a thorough count of the number of languages in use, but a widely cited estimate is "at least 450 general-purpose languages and dialects" (Hook et al., 1995). The abundance of languages made it uneconomical to develop high-quality software tools and was an obstacle to using programmers and software across projects. It was also a major source of post-deployment problems in areas such as interoperability, operations, and maintenance, and it hindered effective product-line
management. Maintenance of compilers, assemblers, linkers, and other tools for all these languages was a significant burden, as were the hiring and training of programmers. In many cases, a system could be maintained only by its original developer; such vendor "lock-in" added to maintenance expenses.
For these reasons, it appeared desirable for DOD to converge on a minimal set of programming languages. Representatives of various DOD and allied defense organizations worked together to define the DOD requirements for high-order languages. An early outcome was the release of DOD Directive 5000.29 (DOD, 1976). The directive required the use of an approved high-order language, unless another choice could be shown to be more cost-effective, and it established a single point of control for each language. However, it was determined that none of the existing languages met the requirements for embedded systems, which were estimated to represent more than half of all DOD software costs in 1973 (Fisher, 1974).
DOD decided to design a new language that would serve as the single, common, high-order language. While DOD had other software problems that went deeper than those associated with programming languages, it appeared that programming language problems were amenable to a technical solution. Moreover, the conversion to a new, common, high-order programming language was viewed by some as a vehicle for DOD-wide efforts to improve software engineering. The new DOD language, which eventually became Ada, was intended to be a modern programming language that would reflect the accumulated knowledge of programming language design and provide the appropriate set of concepts and features for implementing embedded systems.
Representatives of key stakeholders, including organizations within DOD, its contractors, and many of the world's software engineering and programming language experts, were involved in the identification of requirements, the design and evaluation of the early prototype languages, and the refinement of the preliminary Ada design. The end product, eventually named Ada 83, was officially released in 1980 and became a standard in 1983. It was recognized as a powerful, modern programming language that addressed DOD's stated requirements for embedded systems. However, Ada's adoption within DOD and by its contractors did not proceed as quickly as anticipated.
In 1983, Undersecretary of Defense Richard DeLauer established a policy mandating the use of Ada for all new mission-critical applications. The policy specified a waiver process, whereby other DOD authorized languages (CMS-2M/Y, Jovial J3/J73, Fortran, Cobol, TACPOL, SPL/1, and C/ATLAS) could also be used. While the preferential treatment for Ada helped, Ada support software was not yet mature, and there were still many contract awards across the services where Ada was not selected. As a result, systems developed in Ada continued to be in the minority. That situation led to the establishment, in 1987, of the current policy, specified by DOD Directive 3405.1 (DOD, 1987a), which prescribes the use of Ada for most DOD procurements and internal developments. The original list of approved high-order languages was expanded to include Minimal BASIC and Pascal.
The proliferation of programming languages within DOD systems, one of the original reasons for mandating the use of Ada, appears to have diminished over time. Most new DOD software is written in Ada or one of a few other languages. As of 1994, 79 percent of all DOD mission-critical software was written in 3GLs; of this code, 33 percent was written in Ada, 37 percent in the other approved high-order languages, 22 percent in C, and 3 percent in C++ (Hook et al., 1995). It is difficult to tell how much of this consolidation of language use is a result of the requirement to use DOD-approved languages, given that C-the second most widely used language in DOD-has never been on DOD's list of approved languages. Certainly larger market and industry forces have also been at work. For example, growing standardization in the computer industry has resulted in fewer new computer architectures being introduced, particularly when compared with 20 years ago, resulting in fewer assembly languages in use. Similarly, the rate of growth in new 3GLs has diminished since the 1970s and has been overtaken by development of the infrastructure and culture needed to build software involving components in different programming languages.
However, the growth of 4GLs indicates a potential for a new proliferation of programming languages. For example, one study lists 115 languages (out of a total of 455 currently active languages) that meet one definition of a 4GL, i.e., that the language requires 30 or fewer statements to encode one function point (Jones, 1996c). 4GLs typically are not intended to serve as general-purpose programming languages, but they may include a lower-level sub-language that is more general and allows users to program functionality that is not built into the 4GL. Hook et al. (1995) found that 4GLs are used increasingly for DOD automated information systems applications; the committee also heard from DOD representatives that 4GLs increasingly are being used for rapid development special applications. Thus, it appears that DOD will continue to operate in a "polylingual" world.11
Ada's Place in Current DOD Programming Language Policy
DOD policy states that Ada is to be the "single, common, computer programming language for Defense computer resources used in intelligence systems, for the command and control of military forces, or as an integral part of a weapon system" (DOD, 1987a). The policy allows for the use of other, previously authorized languages in deployment and maintenance, but not for redesign or addition of more than one-third of the software. Ada is to be used "for all other applications, except when the use of another approved higher order language [HOL] is more cost-effective over the application's life-cycle." It ranks as preferences (1) off-the-shelf applications packages and advanced software technology, (2) Ada-based software and tools, and (3) approved standard HOLs. Exceptions are allowed only by the granting of a waiver, which requires that the alternative language be more cost-effective and that it be chosen from the list of DOD-approved languages. Neither Ada use nor a waiver is required for COTS or contractor-maintained software developments or for vendor-provided updates.
Implementation of Policy on Waivers
Requests for waivers to develop systems in different languages are handled at a very high management level-the offices of the Assistant Secretary (C3I) or the Service Acquisition Executives—and are reviewed independently from the requesting program's other key decision milestones (such as the Defense Acquisition Board and Major Automated Information Systems Review Council). In practice, such waivers have rarely been requested. The committee was informed that 31 waivers had been granted since 1992 across the services (3 by the Army, and 14 each by the Navy and the Air Force). Because most requests for a waiver have been granted, this relatively small number of approved waivers suggests that only a very small percentage of the many projects that did not use Ada actually submitted a waiver request.12
Based on briefings and testimony to the committee and the information discussed above, the committee concluded the following about the implementation and some of the effects of the Ada waiver policy:
- Many projects have ignored or manipulated the policy on waivers, employing languages other than Ada without the required waiver.
- Many project managers fear that requesting a waiver will reflect badly on them; this has caused some to employ Ada where it is not cost-effective.
- The DOD and services' authorities generally have the capability to grant waivers that are justified, given the small number of waiver requests.
- The granting authorities do not have the capability and expertise to evaluate the technical merits and long-term consequences of the full number of Ada waiver requests that would be made if there were full compliance with the policy.
In organizations with a high level of understanding of software, similar waiver processes can work reasonably well. Waivers are requested by developers where they make sense; waivers are granted by managers where they make sense; and the developers and managers know enough about software to reconcile differences of opinion on what makes sense. One of the recurring themes in successful DOD projects using Ada was that Ada was selected for appropriate technical and economic reasons. However, selection of Ada solely to satisfy DOD's overall policy on programming languages has not been a guarantee of project success.
Importance of Appropriate Expertise
Custodians of mandates on software use who do not possess sufficient knowledge of software tend to rely too much on narrow interpretation of the mandates, and DOD historically has not had a high level of software expertise. The Defense Science Board found in 1987 that DOD lacked adequate career paths for software professionals and had long ignored its software personnel problems (DOD, 1987b). Testimony heard by this committee indicated that although the level of software training has increased, such problems persist. For example, cutbacks in several DOD organizations in the early 1990s appear to have caused numerous software experts to leave DOD for industry. The approach that the Defense Science Board recommended was, "Do not believe DOD can solve its skilled personnel shortage; plan how best to live with it, and how to ameliorate it."
Level of Applicability
Another recurring issue and ambiguity in current DOD policy on programming languages is that it reflects a system-level view of software that does not consider subsystems independently. For example, for a project with three subsystems--(1) an operational flight program (all new software), (2) a simulator (based on an existing simulator written in C), and (3) a ground-based test capability (combining new and legacy components in multiple languages)--current DOD policy encourages project managers to either write all subsystems in Ada or apply for a waiver for all subsystems. This approach leads to a simplistic choice between two options, neither of which is optimal. A clear, more flexible policy is needed that allows project managers to optimize programming language use at the subsystem and component level, without incurring a penalty of additional administrative overhead for the division into components.
To be effective, DOD's policy requiring the use of Ada must include positive incentives for doing so, and it must be implemented closer to the project level within DOD. The current policy fails on both accounts. It has often had negative effects on DOD software engineering processes, in particular because DOD's policy on waivers for use of alternative programming languages has been implemented unevenly by DOD staff who lack the necessary technical knowledge, understanding of the relevant details of system design, or the motivation to consider long-term and service-wide objectives. Many DOD personnel testified to the committee that waivers are perceived as difficult to defend (even though
it appears that most requests are actually granted). This perception frequently has led to manipulation, bypassing, or simply ignoring of the waiver process. Narrow interpretation of the policy has led to a number of poor decisions to use Ada, even when other solutions offered significant improvements in capability. For example, certain graphical user interface development tools have frequently not been used simply because they did not generate Ada or were not written in Ada.
DOD INVESTMENT STRATEGY
DOD weapon systems programs and commercial organizations both understand that significant post-development investments are needed to keep software systems functioning effectively. For example, Citibank spends 80 percent of its software budget on sustaining and enhancing existing code.13 In the programming language area, Eric Schmidt, chief technology officer at Sun Microsystems, has stated that "several years" lie between Java and black ink (Aley, 1996). It is reasonable to assume that Ada 95 will also require ongoing investment.
DOD has assigned the responsibility for sustaining Ada to the Defense Information Systems Agency (DISA), under the Assistant Secretary of Defense (C3I). It is the committee's understanding that DISA's current plan is to shrink the originally planned budget of $10 million in annual support for Ada 95 to nearly zero by the end of 1997. The committee does not believe that Ada 95 is an exception to the general rule that software requires continuing investment to remain effective; briefings from DISA indicated that it has made an assumption to the effect that "the language exists and is mature," meaning that the commercial sector will provide support. The committee disagrees with this assessment.
The barriers to commercial adoption of Ada discussed above in this chapter are a significant concern, because without support and promotion by critical customers such as DOD and the commercial safety-critical community, there is a serious danger that the Ada tool and compiler industry will shrink to the point that it can no longer provide widespread support to warfighting systems. This will ultimately increase DOD's costs, because it will have to take over full maintenance and development for Ada tools. DOD may also have to use programming languages that will result in more costly development and maintenance for its mission-critical systems. In addition to increased cost, any decrease in quality or increase in schedule could threaten DOD's warfighting adaptability and readiness.
DOD remains the key customer for Ada technology. Although Ada 83 is being used outside DOD for the development of critical applications, the Ada tool and compiler market remains dependent on robust support from DOD. Even the perception of DOD pulling away from its support for Ada could dramatically affect Ada vendors, at a time when the industry is in the process of assimilating Ada 95. Uncertainty over DOD's programming language policy and investment strategy is already affecting the ability to find capital to invest in Ada-related development.
The most critical impact of not sustaining Ada is the consequent reduction in support for DOD's 50 million existing lines of Ada mission-critical software. Without DOD support, Ada will begin to resemble other unsupported DOD languages such as Jovial and CMS-2. Mission-critical programs relying on Ada code will be forced to choose between spending time and money to keep their Ada support current and spending even greater resources to convert their software to another language.
SUMMARY OF ADA TRENDS
Tables 1.1 and 1.2 summarize the differences between the past context (1970s and early 1980s) in which the current Ada policy was developed, and the current environment. The change in context is sufficient to warrant a restructuring of DOD's policy and strategy for Ada.
Table 1.1 Past and Present Contexts for Ada: General
Some chance for Ada to be a leading commercial language
Virtually no chance for Ada to achieve a commercial lead, except in niche areas
Some chance that Ada could drive other software practices
Virtually no chance for Ada to become a driver of other software practices
Fair chance that Ada could become the leading high-assurance, real-time (HA/RT) language
Ada generally considered the strongest (HA/RT) language in this area, but others widely used
New software mostly custom, requirements-driven
New software mostly (non-Ada) COTS-driven
Table 1.2 Past and Present Contexts for Ada: Department of Defense
DOD a dominant software player
DOD a large software player
Secondary role in DOD for software
Primary role: key to DOD goal of information dominance
No DOD Ada legacy code
50 million lines of DOD weapon systems Ada legacy code
DOD committed to major Ada development investment
DOD preparing to drop its investment in sustaining Ada
The discussion above indicates that there are serious problems with DOD's current policy regarding Ada, including the lack of guidance provided to DOD personnel and contractors for use of Ada, uneven implementation of the waiver process, and unrealistic investment strategies. In the course of responding to its charge to recommend ways for improving DOD software policies and strategies regarding Ada, the committee identified several critical questions; they are summarized below and addressed in the remainder of this report.
- What is the relationship between programming languages and software engineering practices? As embodied in DOD Directive 3405.1 (DOD, 1987a), DOD's current policy for software development is a programming language policy. However, the choice of Ada as the programming language is insufficient to ensure the development of high-quality, reliable software systems for defense missions. Chapter 2 addresses the importance of software engineering practices and their relationship to programming languages, and points out connections that DOD policy should take into account; Chapter 4 discusses implementation of a broader DOD software policy.
- Are there application areas where using Ada makes an appreciable positive difference? In application areas where powerful non-Ada commercial software support is available, Ada is unlikely to be cost-effective. However, for some DOD software applications, there are few commercial counterparts, and Ada may have advantages. These issues are discussed in Chapters 2 and 3.
- If Ada is superior in some areas, is a policy requiring its use appropriate? This issue and a number of other policy alternatives are discussed in Chapter 3.
- For whatever policy requirements are appropriate, can DOD establish a workable set of criteria and processes for recognizing exceptions? These issues are discussed in Chapter 4 and are addressed in committee-suggested modifications of a May 1996 DOD draft software management policy presented in Appendix A.
- What specific investment strategies are needed to keep Ada strong? This issue is discussed in Chapter 5.
For descriptions of non-DOD projects using Ada, particularly in aerospace, transportation, and telecommunications, see "Ada Success Stories," maintained by the Ada Information Clearinghouse, located on the World Wide Web at http://sw-eng.falls-church.va.us/AdaIC/usage.
If all programming activities are included (i.e., application-oriented programming by other professionals), the total number of programmers increases to 3.45 million, less than 3 percent of which are Ada 83 programmers.
The newspapers were the April 21, 1996, edition of the Los Angeles Times and the March 24, 1996, edition of the Washington Post.
Other significant 3GLs were Cobol (11 percent) and Java (4 percent). Significant 4GLs were Visual Basic (13 percent), PowerBuilder (10 percent), and FoxPro and Visual C++ (4 percent each).
The industry groups surveyed were automobile services, financial services, medical devices, and industrial machinery.
Exceptions to this generalization include Cobol, which was never a popular language in academia but is used widely in business and defense applications, and Pascal, which was popular for many years in universities but not in industry.
"Foundation" is defined as one of the initial computing courses taken by students majoring in the field.
Bob Mathis, executive director, Ada Resource Association, personal communication, September 8, 1996.
The committee included representatives of two firms that sell Ada products: Rational and Intermetrics.
In a position paper to the committee, Victor Vyssotsky advocated stronger encouragement for programmers to learn numerous languages (Vyssotsky, 1996).
Gerald Pasternack, Citibank, presentation to the committee, May 23, 1996, Washington, D.C.