National Research Council: Ada & Beyond
[Contents] [Part 1] [Part 2] [Part 3] [Part 4] [Part 5] [Part 6]
1. Review DOD's original (mid-1970s) goals and strategy for the Ada program; 2. Compare and contrast the past and present environments for DOD software development; and 3. Consider alternatives and propose a refined set of goals, objectives, and approaches better suited to meeting DOD's software needs in the face of ongoing technological change.Although the committee focused on programming language issues, it also considered them in the context of software architectures, components, and life-cycle processes, consistent with the realization that successful software engineering strategy involves several elements that are at least as important as the programming language component. Throughout its deliberations, the committee was sensitive to the fact that the issues surrounding Ada and DOD programming language policy have been the source of vigorous debate among DOD
|viii||Ada and Beyond: Software Policies for the Department of Defense|
|1 THE CHANGING CONTEXT FOR DOD SOFTWARE DEVELOPMENT|| 7|
|Growth in the Commercial Software Industry, 8|
Obstacles to Broad Adoption of Ada, 8
|DOD Programming Language Policy, 12|
|DOD Investment Strategy, 16|
Summary of Ada Trends, 16
Critical Questions, 17
|2 SOFTWARE ENGINEERING AND THE ROLE OF ADA IN DOD SYSTEMS||19|
|Software Engineering Process and Architecture, 19|
|x||Ada and Beyond: Software Policies for the Department of Defense|
|Technical Evaluation of Ada 95 and Other Third-Generation Programming Languages, 24|
Available Comparisons of Ada 83 and Other Third-Generation Programming Languages, 26
The Need to Institute Collection of Data for Software Metrics, 30|
|3 DOD SOFTWARE POLICY: ANALYSIS AND RECOMMENDATIONS|| 34|
Policy Objectives and Criteria Relevant to Meeting Them, 35|
|Ada Business-Case Analysis, 37|
|Findings and Recommendations, 42|
|Assessment of Policy Alternatives, 44|
|Economic Analysis of Investment in Ada Infrastructure, 50|
|4 IMPLEMENTATION OF RECOMMENDED DOD SOFTWARE POLICY|| 53|
Recommended Policy for Choice of Programming Language, 53|
|Software Engineering Plan Review Process, 56|
|5 IMPLEMENTATION OF RECOMMENDED STRATEGY FOR INVESTMENT IN ADA||62|
Goals of the Investment Strategy, 62|
Ada Investment Strategy, 63
|Detailed Plan for Investments in Ada Technology and Support, 66|
A DOD Draft Software Management Policy Directive with Further Modifications Suggested by the Committee, 75|
B Technical Descriptions of Ada and Other Third-Generation Programming Languages, 80
C Glossary, 88
D Detailed Comparisons of Ada and Other Third-Generation Programming Languages, 92
E Briefings and Position Papers Received by the Committee, 101
Ada was developed in the 1970s by the Department of Defense (DOD) and adopted in some DOD programs until its use was required for new software development in 1987. It has been employed as a tool for developing quality software and as a DOD policy lever to encourage DOD organizations and programs to adopt modern software engineering principles. Changes within DOD, the software engineering community, and the commercial software industry have led DOD to reassess its programming language policy.
The Committee on the Past and Present Contexts for the Use of Ada in the Department of Defense was created by the National Research Council's Computer Science and Telecommunications Board to review DOD's programming language policy and the question of Ada's role in it. This study presents findings and recommendations developed by the Committee for DOD's consideration in efforts to revise its current policy.
The Committee concluded that a vigorous Ada program would enhance the reliability and performance of DOD warfighting systems, and it recommends that DOD continue the use and promotion of Ada in such systems. However, the committee found significant problems with the two primary components of DOD's current strategy for Ada. First, there are problems in the scope, design, and implementation of the current programming language policy, which requires the use of Ada for all software to be maintained by DOD; the committee recommends several modifications. Second, DOD's plan to discontinue investments in Ada technology and user-community support by the end of 1997 will weaken the Ada infrastructure and work against any requirement for DOD systems to use Ada in the future; given the large installed base of Ada code in warfighting systems, targeted investments in Ada are justified.
In the course of this study, the committee also concluded that the currently available data on effects of programming language on project outcomes are insufficient, on their own, to serve as a basis for strong determinations of the impact of programming language choice on the outcome of DOD
|2||Ada and Beyond: Software Policies for the Department of Defense|
programs. Briefings received by the committee also highlighted the difficulty that DOD managers have in gaining access to data that can support informed decisions. The committee did find that trends in the data, anecdotal evidence, and expert judgment provided a basis for its finding that Ada provides benefits in warfighting systems. However, based on its experience with the limitations of currently available data, the committee makes an additional recommendation that DOD institute a corporate data collection effort and develop metrics as a sound basis for evaluating software so as to guide future policy and management decisions.
CONTEXT AND TRENDS
DOD's policy preference for Ada had some merit a decade ago. Most software at the time was entirely custom, and Ada had a good track record in delivering custom software with higher quality and lower life-cycle costs. However, a custom Ada solution is no longer the best approach in many application areas, due to the following major trends:
COTS as a source of information infrastructure for applications. Software solutions increasingly depend on commercial off-the-shelf (COTS) software, which provides much of an application's information infrastructure: operating system, database management, networking, user interface, and distributed processing functions. Much of this software is written in programming languages other than Ada that often do not have readily available interfaces to programs written in Ada. Developing these interfaces is not a major technical problem, but, particularly in the area of commercial Internet applications, COTS software is evolving rapidly, making it hard for Ada solutions to keep current.
Product-line solutions and production factors. Software for many application areas is achieving economies of scale through the development of product-line architectures, enabling software assets to be reused across families of applications. These product-line solutions are driven by strongly coupled "production factors," including software components, processes and methods, human resources, and expertise in particular domains. In warfighting application areas such as weapon control and electronic warfare, there is little commercial development, and DOD has established a strong community of warfighting software developers whose production factors are oriented to Ada. However, for the numerous DOD applications in which the market is dominated by commercial solutions, such as finance and logistics, production factors have been built around programming languages other than Ada, putting Ada solutions at a disadvantage.
Additional conditions that strongly influenced the committee's findings and recommendations include the following:
DOD emphasis on achieving information dominance. According to Secretary of Defense William Perry,". . . our warfighting strategy sustains and builds on . . . the application of information technology to gain great military leverage to continue to give us [an] unfair competitive advantage" (Perry, 1996a). This assertion highlights the importance of a capability for enhancing military competitive advantage as a criterion for the choice of programming language.
Large and increasing inventory of DOD Ada software. DOD now has over 50 million lines of operational Ada weapon systems software, with a great deal more under development. Most of this software is in critical warfighting application areas, and there are no quick and cheap ways to translate it into other languages. DOD policies and investment strategies that weaken Ada support for this software are very risky because of the role warfighting software plays in maintaining national security.
Proliferation of programming languages has decreased, but polylingualism is here to stay. One goal of developing Ada was to reduce the proliferation of programming languages used in DOD systems, estimated to be approximately 450 in the 1970s. The number of languages used throughout DOD has indeed decreased: the use of machine and assembly languages has diminished, and the number of third-generation languages in use has been reduced. However, there has been a rapid increase in development of fourth-generation languages by the commercial sector (there are now more than 100 different such languages), and use of these languages by DOD is increasing. Thus, DOD cannot expect to avoid polylingual software solutions. However, support for multilanguage applications has improved significantly.
Programming language choice is one of several key software engineering decisions. The requirement to use Ada and the process for obtaining a waiver isolate programming language decisions from other key software engineering decisions (e.g., choices of computer and software architectures, decisions about use of COTS components, and milestone schedules). These decisions are also currently made at the system level, rather than at the component or subsystem level. This arrangement creates an incentive for DOD programs to make decisions that are not optimal for DOD as an organization. Future programming language decisions need to be made as part of an integrated software engineering process.
FINDINGS AND RECOMMENDATIONS
The committee developed the following set of findings and recommendations for future DOD software policy and strategy. The recommendations address the use of Ada in warfighting software, the application in which the committee finds Ada to have demonstrated benefit; the proper scope and implementation of software policy; investment in Ada; and collection of data as a basis for assessing the effectiveness of software and software policy.
Ada Competitive Advantage
Finding. Ada gives DOD a competitive advantage in warfighting software applications, including weapon control, electronic warfare, performance-critical surveillance, and battle management.
Recommendation. Continue vigorous promotion of Ada in warfighting application areas.
Rationale. Available project data and analyses of programming language features indicate that, compared with other programming languages, Ada provides DOD with higher-quality warfighting software at a lower life-cycle cost. DOD can increase its advantage by strengthening its Ada-based production factors (involving software tools, technology, and personnel) for warfighting software (see Chapters 2 and 3).
Applicability of Policy to DOD Domains
Finding. DOD's current requirement for use of Ada is overly broad in its application to all DOD-maintained software.
Recommendation. Focus the Ada requirement on warfighting applications, particularly critical, real-time applications, in which Ada has demonstrated success. For commercially dominated applications, such as office and management support, routine operations support, asset monitoring, logistics, and medicine, the option of using Ada should be analyzed but should not be assumed to be preferable.
|4||Ada and Beyond: Software Policies for the Department of Defense|
Rationale. For warfighting software, supporting Ada-based production factors (involving software tools, technology, and personnel) gives DOD a competitive advantage. In this domain, eliminating the use of Ada would both compromise this advantage and diminish the capabilities for maintaining DOD's existing 50 million lines of Ada. In commercially dominated areas, pushing applications toward Ada would create a disadvantage for DOD (see Chapters 2 and 3).
Scope of Policy
Finding. DOD's current requirement for use of Ada overemphasizes programming language considerations.
Recommendation. Broaden the current policy to integrate the choice of programming language with other key software engineering concerns, such as software requirements, architecture, process, and quality factors.
Rationale. The current policy isolates the Ada requirement and the waiver process from other software engineering decisions, causing programs to make premature or non-optimal decisions (see Chapter 1). DOD has already taken steps to broaden the policy focus in its draft revision of its programming language policy, DOD Directive 3405.1; this report recommends modifications to that draft policy (Appendix A).
Finding. DOD's current Ada requirement and the related waiver process have been weakly implemented. Many programs have simply ignored the waiver process. Other programs make programming language decisions at the system level, but often a mix of Ada and non-Ada subsystems is more appropriate (see Chapter 1).
Recommendation. Integrate the Ada decision process with an overall Software Engineering Plan Review (SEPR) process. Passing such a review should be a requirement for entering the system acquisition Milestone I and II reviews covered by DOD Instruction 5000.2. It should also be required for systems not covered in 5000.2, and recommended by DOD for DOD-directed software development and maintenance of all kinds.
Rationale. The SEPR concept is based on the highly successful commercial architecture review board practice. The SEPR process involves peer reviewing not only the software and system development plans, but also the software and system architecture (building plan) and its ability to satisfy mission requirements, operational concepts, conformance with architectural frameworks, and budget and schedule constraints; the process also involves reviewing other key decisions such as choice of programming language (see Chapter 4).
Investment in Ada
Finding. For Ada to remain the strongest programming language for warfighting software, DOD must provide technology and infrastructure support.
Recommendation. Invest in a significant level of support for Ada, or drop the Ada requirement. The strategy developed by the committee recommends an investment level of approximately $15 million per year.
Rationale. With investment, DOD can create a significant Ada-based complex of production factors (involving software tools, technology, and personnel) for warfighting application domains.
Without such support, Ada will become a second-tier, niche language such as Jovial or CMS-2 (see Chapter 5).
Software Metrics Data
Finding. DOD's incomplete and incommensurable base of software metrics data weakens its ability to make effective software policy, management, and technical decisions.
Recommendation. Establish a sustained commitment to collect and analyze consistent software metrics data.
Rationale. The five sets of findings and recommendations above are based on a mix of incomplete and incommensurable data, anecdotal evidence, and expert judgment. For this study, the patterns of consistency in these sources of evidence provide reasonable support for the results-but not as much as could be provided by quantitative analysis based on solid data. A few organizations within DOD have benefited significantly from efforts to provide a sound basis for software metrics; a DOD-wide data collection effort would magnify the net benefits (see Chapter 2).
WHAT THE DEPARTMENT OF DEFENSE SHOULD DO ABOUT ADA
In summary, the committee concluded the following regarding DOD and Ada:
The rationale for the above statements is as follows:
|6||Ada and Beyond: Software Policies for the Department of Defense|
ORGANIZATION OF THIS REPORT
Chapter 1 describes the past and present contexts for Ada and DOD software development and programming language policy and points out problems with the current approach. Chapter 2 relates issues in decisions about programming language to other software engineering decision issues and evaluates Ada's support for software engineering processes. It also summarizes the results of comparing the relative cost-effectiveness of Ada and other programming languages, based on analyses of language features and empirical data from software projects.
Chapter 3 presents a business-case analysis for the use of Ada within DOD, gives the committee's findings and recommendations, and analyzes them along with alternatives.
The software policy recommended by the committee for DOD is elaborated in Chapter 4, which also provides additional details on programming language selection criteria and explains the basic elements of the Software Engineering Plan Review process recommended by the committee. Chapter 5 discusses the committee's recommended strategy for investment in infrastructure for Ada.
Appendix A reproduces a draft revision of DOD Directive 3405.1 on programming language policy (DOD, 1987a), a document to which the committee has added further suggested modifications that reflect its recommendations in this report. Appendix B presents detailed descriptions of Ada and other programming languages; a glossary of terms used in the report is contained in Appendix C; Appendix D compares Ada's features with those of other third-generation programming languages; and Appendix E lists briefings and position papers received by the committee during the course of its study.
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 diminishednot 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.
|8||Ada and Beyond: Software Policies for the Department of Defense|
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
|The Changing Context for DOD Software Development||9|
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
|10||Ada and Beyond: Software Policies for the Department of Defense|
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 Changing Context for DOD Software Development||11|
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
|12||Ada and Beyond: Software Policies for the Department of Defense|
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 visibile 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
|The Changing Context for DOD Software Development||13|
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/l, 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.
|14||Ada and Beyond: Software Policies for the Department of Defense|
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.
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 levelthe offices of the Assistant Secretary (C3I) or the Service Acquisition Executivesand 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:
|The Changing Context for DOD Software Development||15|
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
|16||Ada and Beyond: Software Policies for the Department of Defense|
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.
|The Changing Context for DOD Software Development||17|
|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|
|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.
|18||Ada and Beyond: Software Policies for the Department of Defense|
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.
National Research Council: Ada & Beyond
[Contents] [Part 1] [Part 2] [Part 3] [Part 4] [Part 5] [Part 6]