From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,CTE_8BIT_MISMATCH, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: ff6c8,c56c718953c02406,start X-Google-Attributes: gidff6c8,public X-Google-Thread: 1108a1,c56c718953c02406,start X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,c56c718953c02406,start X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,c56c718953c02406,start X-Google-Attributes: gid10db24,public X-Google-Thread: f43e6,c56c718953c02406,start X-Google-Attributes: gidf43e6,public From: seic@sw-eng.falls-church.va.us (Software Engineering News) Subject: NRC CSTB Ada Public Briefing Summary Date: 1996/11/01 Message-ID: <55dmq5$ch1@ns1.sw-eng.falls-church.va.us> X-Deja-AN: 193758218 content-type: Text/Plain; charset=ISO-8859-1 organization: SEIC mime-version: 1.0 newsgroups: comp.lang.ada,comp.object,comp.software-eng,comp.edu,comp.sw.components Date: 1996-11-01T00:00:00+00:00 List-Id: Computer Science and Telecommunications Board National Research Council 210 Constitution Avenue, N.W., Washington, D.C. 20418 Phone: (202)334-2318 Fax: (202)334-2318 Internet: CTSB@NAS.EDU World Wide Web: WWW2.NAS.EDU/CTSBWEB Office Location Milton Harris BLDG.RM 560 2001 Wisconsin Avenue, NW Washington, D.C. 20007 (Off Whitehaven Street) Committee on the Past and Present Contexts for the Use of Ada in the Department of Defense Barry Boehm, Chair University of Southern California Theodore Baker Florida State University Wesley Embry Silicon Graphics, Inc. Joseph Fox Template Software Paul Hilfinger University of California at Berkeley Maretta Holden Boeing Defense and Space Group J. Elliot B. Moss University of Massachusetts at Amherst Walker Royce Rational Software Corporation William Scherlis Carnegie Mellon University S. Tucker Taft Intermetrics, Inc. Rayford Vaughn Electronic Data Systems Corporation Anthony Wasserman Interactive Development Environments, Inc. Barbara Liskov, Special Advisor Massachusetts Institute of Technology Staff Paul Semenza Study Director, CSTB Ada and Beyond: Software Policies for the Department of Defense What should the Department of Defense do about the Ada programming language? Despite the language�s technical capabilities, it has not been widely used outside of military and other safety-critical applications, as was hoped when the language was developed in the 1970s. The Defense Department�s policy on programming languages, which requires the use of Ada for all new software development, has resulted in many conflicts and has not been implemented evenly. Meanwhile, commercial software applications have grown rapidly, and do not generally use Ada. 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 the current policy, and to examine the role of Ada in software development. The study was requested by the Office of the Assistant secretary of Defense for Command, Control, Communications, and Intelligence. Released today, Ada and Beyond: Software Policies for the Department of Defense presents the committee�s findings and recommendations. The committee concluded the vigorous support of Ada would benefit warfighting systems, and recommends that the Department of Defense should continue to use and promote Ada in such systems. However, the committee found significant problems with the two primary components of the Defense Department�s current strategy for Ada. First, the current programming language policy requires the use of Ada for all new defense software, which the committee finds to be overly broad in scope. Second, the Defense Department�s plan to discontinue investments in both Ada technology and user- community support will weaken the Ada infrastructure, and will work against any requirement to use Ada in the future. In summary, Ada and Beyond: Software Policies for the Department of Defense concludes that the Defense Department should take the following steps regarding Ada: 1. Continue to require Ada for its warfighting software and drop the Ada requirement for its other software. In commercially dominated areas, using Ada is generally less cost-effective than using other languages. Requiring the use of Ada in these areas would place the Defense Department at a competitive disadvantage. In warfighting application areas, however, Ada�s technical capabilities for real-time, high assurance custom software are generally superior to those of other languages. The Defense Department�s investments in Ada to date have created a set of Ada-based production factors that give its system advantages in these areas. 2. Provide roughly $15 million per year for Ada infrastructure support, or drop the requirement to use Ada entirely. The commercial marketplace will not sustain a robust Ada infrastructure. However, a relatively modest ($15 million per year) investment at the margin by the Defense Department would be sufficient to sustain a robust Ada infrastructure for warfighting applications. The Defense Department�s inventory of more than 50 million lines of warfighting software must either be maintained in Ada or converted to another programming language. The recommended investment is modest with this maintenance burden. 3. Make programming language decisions in the context of a Software Engineering Plan Review process. The choice of programming language is one component of the software- engineering process, and should be considered in the broader context of decisions regarding architecture, software reuse, and software process management. In the course of this study, the committee also concluded that the currently available data are insufficient, on their own, to accurately determine the impact of programming language choice on the outcome of defense programs. Committee briefings also highlighted the difficulty that program managers have in finding data on which they can make informed decisions. Based on the limitations of availability data, the committee has made an additional recommendation that the Defense Department institute a corporate effort to collect software metrics to guide future policy and management decisions. The committee developed its recommendations, presented in detail in Ada and Beyond: Software Policies for the Department of Defense, in light of changes in the environment for military software development. A decade ago, the policy preference for Ada had some merit. Most software was custom made, and Ada had a good track record in delivering custom software with higher quality and lower life-cycle costs. However, custom Ada solutions are no longer competitive in many application areas, due to several trends. First, software solutions increasingly depend on commercial-off-the-shelf, or COTS, software, which provides much of an application�s information infrastructure, including 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. Second, software for many application areas is increasingly developed in so-called "product-line" architectures, which enable 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 applications areas such as weapon control and electronic warfare, there is little commercial development, and the Defense Department has established a strong community of warfighting software developers whose production factors are oriented to Ada. However, for the numerous defense 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 solutions at a disadvantage. Several other factors have strongly influenced the committee�s findings and recommendations. One is the Defense Department�s increasing emphasis on information dominance. According to Secretary of Defense William Perry, the Defense Department�s 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." A second factor is that the Defense Department now has more than 50 million lines of operational weapon systems software written in Ada, with a great deal more under development. Most of this software is in critical warfighting applications areas. There are no quick and cheap ways to translate this software into other languages. Polices and investment strategies that weaken Ada support for this software are very risky. A third factor is that, while language proliferation has decreased, "polylingualism" is here to stay. One goal of developing Ada was to reduce the proliferation of programming languages used in defense systems, estimated to be approximately 450 in the 1970s. The number of languages used in defense systems 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, and increased use of these languages by defense programs. A final factor is that choosing a programming language is one of several key software engineering decisions. The requirement to use Ada and the waiver process both isolate programming language decisions from other key software engineering decisions. Modern software engineering considerations include the choices of computer and software architectures, COTS components, and milestone schedules. This arrangement creates and incentive for defense programs to make decisions that are not optimal for the Defense Department as an organization. Future programming language decisions need to be part of an integrated software engineering process. This report will be available electronically on the World Wide Web in mid-November at . Paper copies will be made available in December. ******************************************************* The Defense Information Systems Agency (DISA) Software Engineering Information Center (SEIC) "Software Engineering News Brief" is a compilation of summaries from software engineering-related articles in trade magazines, newsletters and press releases. The DISA SEIC welcomes suggestions for, and pointers to, software engineering-related articles. Contact the DISA SEIC at: info@sw-eng.falls-church.va.us To subscribe to the "Software Engineering News Brief" electronic mailing list, send a message to: listproc@sw-eng.falls-church.va.us In the body of the message, write: subscribe newslist To unsubscribe, write: unsubscribe newslist No signatures please.