National Research Council: Ada & Beyond
[Contents] [Part 1] [Part 2] [Part 3] [Part 4] [Part 5] [Part 6]
Implementation of Recommended Strategy for Investment in Ada
This chapter describes the committee's recommended $15 million annual investment strategy for Ada in the context of the focus on use of Ada for DOD's warfighting software. The components of the strategy are maintaining and enhancing the Ada 95 language; ensuring support for Ada's compilers, tools, and application programming interfaces (APIs) for warfighting systems; stimulating Ada education and curriculum development; and providing support for a centralized source of Ada information and expertise within DOD. The chapter concludes by providing a detailed plan and funding breakdown for the recommended investments in Ada.
GOALS OF THE INVESTMENT STRATEGY
It is important to state explicitly what the goals of the proposed investment and procurement strategy for Ada are, and what they are not. Using Ada benefits DOD mainly because of the language's orientation toward reliability. Ada's features are designed to maximize the chance that a coding error will be detected at compile time, and failing that, at run time. As illustrated in "Technical Evaluation of Ada 95 and Other Third-Generation Programming Languages" in Chapter 2, Ada is ahead of languages such as C and C++ in that it provides strong support for compile-time and run-time consistency checking. Although other languages may approach Ada in their ability to check reliability and consistency, no other third-generation programming language (3GL) has achieved comparably widespread use for critical (high-assurance, and often real-time) systems.
The first goal is to ensure that Ada tools for critical warfighting software development are superior to those in other languages. This is at the heart of the strategy to keep Ada competitively superior for the development of warfighting software systems. It involves a proactive strategy of seeking out and expediting (via complementary funding) development of such tools for the commercial marketplace.
The second goal is to ensure that robust Ada compilers and associated tools for host and target computers used in DOD's warfighting systems remain available and reasonable in cost. It is not a goal
|Implementation of Recommended Strategy for Investment in Ada||63|
to make Ada compilers as inexpensive or ubiquitous as C compilers. The strategy recognizes that a compiler for a reliability-oriented language like Ada, with large numbers of compile-time and run-time consistency checks, will inevitably be larger and more expensive to develop and maintain than other 3GL compilers. A reasonable target would be for a production-quality Ada compiler to be available at a price comparable to the cost of a production quality C compiler, plus additional production quality third-party compile-time and run-time checking tools for C (for example, a "lint"-like tool and a "purify"-like tool). The strategy also recognizes that any compiler for an embedded system with associated robust cross- "debugging" support and integration with an appropriate real-time executive will be more expensive than a personal computer (PC) native compiler. It is not expected that Ada cross-compilers will ever match the price of off-the-shelf PC native compilers.
For similar reasons, it is not a goal that Ada become the predominant programming language for commercial programming. For critical systems programming, Ada already has a significant market share. Nevertheless, this is a relatively small marketplace, and DOD is a major player, meaning that it will have to continue to invest in the market for tools that support the development of critical systems.
The third goal is to ensure that an Ada-compatible interface is readily available for all off-the-shelf software components used in DOD's warfighting Systems. Such systems include relevant database management systems, operating systems, real-time executives, and networking packages. It is not a goal that such components necessarily be written in Ada.
The fourth goal is that more educational institutions provide exposure to Ada concepts in the context of a software engineering curriculum, particularly in courses covering critical systems development. It is not a goal that Ada become the predominant teaching language (though Ada has advantages for teaching because of its readability and consistency checking). Rather, the goal is to increase the exposure to and use of Ada in the educational environment, thereby increasing the pool of programmers familiar with Ada and reducing the ultimate training costs for DOD's contractor community.
A related goal is to increase the use of Ada in software engineering research, which will enhance the Ada technology base for warfighting systems, as well as increase exposure to and understanding of Ada in the academic and research communities. It is not suggested that all DOD-sponsored research use Ada or that all DOD research prototypes be written in Ada. Rather, it is recommended that criticalsystems software research emphasize Ada's use, that more research programs include Ada in the set of languages they consider, and that an increased number of advanced technology tools support Ada in addition to other languages that are supported.
The final goal relates to centralized support and infrastructure for DOD's use of Ada. DOD can continue to benefit from using Ada for its criticalsystems, but the benefits will be offset by other cost increases if each project needs to maintain its own support infrastructure for Ada. By continuing to support a centralized organization like the Ada Joint Program Office, even if its mission is redirected toward ongoing support rather than product development, DOD can achieve economies of scale. It is not suggested that such an organization directly support the development of new Ada compilers. Rather, it is emphasized that a centralized organization is necessary to provide expertise, resource directories (such as the World Wide Web site supported by the Ada Joint Program Office), technology management, and technology transition.
ADA INVESTMENT STRATEGY
DOD can benefit from providing ongoing support for Ada technology by building on its significant investment in Ada 83, and the Ada 95 revision. In addition, DOD should use its leverage as a large customer for commercial hardware and software products to expand the availability of commercial tools and components that support Ada, which would help the Ada market become more self-sustaining.
|64||Ada and Beyond: Software Policies for the Department of Defense|
Continued investment by DOD is required in the following areas:
Each area is discussed in more detail below.
Language Maintenance and Enhancement
The Ada 95 standard requires ongoing support. Parts of the standard require interpretation, implying the need for a group of experts to meet periodically to resolve these issues. Any large software system will develop unanticipated requirements for improvement as its use becomes widespread, and Ada 95 is no exception. In addition, advanced areas such as security, distribution, or persistence require ongoing development of "secondary" standards and accompanying validation test suites to systematize the best way to use Ada in these areas. For Ada, there is an International Organization for Standardization working group (ISO WG9), which has a number of "rapporteur" groups that coordinate these maintenance and secondary standardization tasks. Funding of these groups is essential to make their activities effective and timely, and DOD must provide some of the critical funding to keep these groups active. Even in the area of compiler validation, where the Commerce Department's National Institute of Standards and Technology is now providing a nominal level of support, DOD may find it necessary to provide funding to ensure that its high-priority needs are met in a timely manner.
Support for Ada Compilers, Tools, and Application Programming Interfaces
Ada 95 is a technically successful revision of Ada 83. Like all standards, however, it needs "champions" for its adoption, since there are always costs involved in adopting a standard or revision. Now that the Ada 95 revision is complete, the user and supplier communities must be given incentives to adopt the standard. Although DOD is no longer a dominant player in the software market, it is still a large customer, and arguably the primary customer for critical systems. Any major customer can establish incentives to motivate its suppliers to support a preferred standard; in order for DOD to play this role for its critical warfighting systems, it must emphasize the importance of providing support for Ada compilers and tools, and for Ada APIs for warfighting software applications. DOD should similarly use its market power to make it possible to tailor a warfighting system to operate efficiently in Ada, even if the original system was built largely using COTS components or non-Ada technologies. This means that DOD should require that all components included in DOD warfighting software have a demonstrable, full-function, Ada-callable interface. For example, all operating systems used in DOD warfighting systems should include an Ada-callable interface, sufficient for exercising all capabilities of the operating system necessary for warfighting systems. The Ada-callable interface must be kept up to date by the operating system supplier; in order for a capability to be considered acceptable for delivery, it
|Implementation of Recommended Strategy for Investment in Ada||65|
must be accessible via Ada. Similarly, a hardware device that is controlled by software should be delivered with a demonstrable Ada-callable interface before it is accepted for a DOD warfighting system.
Another incentive to encourage use of Ada is to ensure that all computers used for developing DOD warfighting software include an Ada compiler at a price and quality comparable to those of other compilers. The criteria for choosing a computer for hosting software development should include the availability, price, and quality of the Ada compiler. This will help to ensure that hardware vendors wishing to sell in the DOD warfighting-systems marketplace make certain that there is a high-quality, reasonably priced Ada compiler on their platform. Warfighting systems procurements should stipulate that Ada compilers be available at the same time the equipment is available, rather than months or years later. This approach will ensure that Ada development remains viable on hardware platforms relevant to DOD.
For Ada to be a viable option for a given system, appropriate Ada compilers and associated tools must be available for the relevant host and target hardware. In the mid 1980s, most hardware vendors made an effort to ensure that an Ada compiler and associated tools existed for their hardware. Recently, however, the burden seems to have shifted from the hardware vendors to the individual systemdevelopment contractors. The linkage between purchasing hardware and compiler availability seems to have been lost.
In addition to robust support for compilers, Ada-compatible APIs to relevant COTS software components are also important to make the use of Ada cost-effective. As in the hardware area, the linkage between selling software components to DOD and providing appropriate Ada support seems to have been lost. For example, rather than requiring that database management systems for warfighting software systems come with an Ada-compatible interface, the burden seems to have shifted to individual contractors to acquire or develop such interfaces. Because COTS software products are being continually enhanced, this approach is even less satisfactory than in the hardware area.
Providing multilingual interfaces to COTS software products is now done as a matter of course. As with hardware, software vendors who wish to compete for DOD warfighting systems business should recognize that including Ada among the languages supported is a normal cost of doing business. The cost of including an Ada-compatible interface is relatively small. With the advent of multilingual interface standards such as CORBA IDL,1 this proposed requirement becomes even more practical. On the other hand, when the burden of providing an Ada-compatible interface is left to individual contractors, the cost is greater, particularly given the need to keep up with ongoing enhancements.
DOD should re-create this linkage between robust Ada compiler and tool support and the choice of hardware. Hardware vendors who wish to compete for DOD warfighting systems procurements should see the provision of appropriate Ada support as a requirement, in the same way that hardware vendors have recognized the need to provide a POSIX-compliant2 operating system to satisfy DOD's open systems requirements.
As defined in Chapter 2, "warfighting systems" are the high-assurance, performance-critical portions of systems for weapon control, electronic warfare, wideband real-time surveillance, real-time battle management, and special battlefield communications. The Ada support requirements recommended above apply only to hardware and software vendors choosing to support such systems. Examples of Ada tools that support critical warfighting software engineering include Ada-oriented tools for real-time and fault-tolerant software; tools for software reliability, availability, survivability, security, and safety assurance; tools to facilitate effective use of Ada 95's new, object-oriented, real-time, and distributed-system capabilities for warfighting systems; and Ada-oriented tools for special warfighting applications domains (e.g.; real-time distributed avionics systems test, debugging, and performance tuning).
|66||Ada and Beyond: Software Policies for the Department of Defense|
For the past several years, the Ada Joint Program Office has provided support for the development of Ada-based curriculums at a number of U.S. colleges and universities. This has contributed to the growing number of colleges and universities that include Ada and software engineering in their computer science programs. As discussed in Chapter 1, the number of courses in Ada and in software engineering has increased recently, but there are still many colleges and universities that provide little or no exposure to the kinds of software challenges faced in the development of complex critical systems. One of the frequent concerns of defense contractors has been the availability of well-trained software engineers. Since DOD's investments in Ada curriculum development seem to have assisted in such training, the grants for this purpose should continue. An effort to distribute the grants geographically is advisable, to ensure that Ada instruction is available in areas where DOD warfighting systems are developed.
In addition to supporting Ada-related curriculum development, DOD should ensure that some portion of its software research budget is focused on enhancing the Ada technology base. A growing number of tools and techniques are being investigated in the research community for enhancing the productivity and quality of software development. Whether these tools are actually written in Ada is not particularly relevant to DOD. What is relevant, however, is whether these tools can be used to support systems with components written in Ada. With the availability of the GNAT compiler in source code (for details, see Chapter 1), there are fewer obstacles to the use of Ada as a vehicle for research in programming languages and programming support tools.
In keeping with the competitive strategy recommended in earlier chapters, this investment package should place a high priority on Ada-based research and curriculum development for software needs in warfighting application domains (e.g., for real-time, high-assurance software).
Centralized Support Organization
In testimony provided to the committee, the importance of a centralized organization to support Ada and related software engineering technologies was repeatedly stressed. The Ada Joint Program Office has served this function over the past decade. While it is not the role of this committee to recommend the disposition of this function, it may be appropriate to consider transferring executive responsibility to a higher-level organization with cognizance over warfighting software, such as the Office of the Assistant Secretary of Defense (C3I) or the Undersecretary of Defense (Acquisition and Technology). With regard to choosing a support organization, it is worth noting that Ada is one of several software technologies important to defense systems. Thus, combining support for Ada with support for other important software technologies might save resources and provide better service overall.
DETAILED PLAN FOR INVESTMENTS IN ADA TECHNOLOGY AND SUPPORT
Chapter 3 presented the argument that if Ada 95 is well supported, it could create a significant warfighting competitive advantage for DOD. The committee recommends the following investment strategy to help bring this about. The overall $15 million annual budget needed for ongoing enhancement of Ada-related technology, and ongoing support for the effective use of Ada within the DOD community, can be divided into two major areas. The first is for funding contracts with organizations outside DOD. The second area is for funding the ongoing activities of a centralized support organization within DOD oriented toward programming languages.
|Implementation of Recommended Strategy for Investment in Ada||67|
$1.5 million, based on approximately 20 awards at $75,000 each;
$1.0 million, based on approximately 5 awards at $200,000 each;
$0.6 million, based on approximately 15 part-time experts at $40,000 each;
$0.4 million, based on approximately 2 awards at $200,000 each; and
$8.0 million, based on approximately 15 fully funded academic/research-oriented awards averaging $200,000 each, and 20 co-funded industry/development-oriented awards averaging $250,000 in DOD funds each.
$1.0 million; and
As stated above, it is important to emphasize that these are not one-time investments, but rather continuing investments to maintain and enhance the effectiveness of Ada for DOD. It is also important to recognize that this $15 million annual DOD investment is designed to expedite desired capabilities by leveraging the existing $200 million annual Ada market. It does not represent the entire investment required for Ada support.
If DOD continues to specify Ada as the preferred programming languagefor any application domainsit is essential that it make investments such as those outlined in this chapter. The only other sources of Ada support are individual projects, and burdening them would be inefficient, duplicative, and a major disincentive for projects to use Ada. From a vendor's standpoint, it would put Ada into the same narrow niche as Jovial, which has very little support for compilers, tools, bindings, and run-time applications.
Furthermore, failure to make the relatively modest level of investment described above would imperil the existing body of Ada code for DOD's weapon systems. Independent of the question of future systems development, the legacy of developed Ada code requires a robust development community. The
|68||Ada and Beyond: Software Policies for the Department of Defense|
economic analysis presented in Chapter 3 shows that the cost savings from maintaining this legacy code alone are sufficient to justify the recommended $15 million annual investment in Ada. But even further, as discussed in the business-case analysis, the investment provides DOD with a key competitive advantage in warfighting software to more completely achieve its objective of military information dominance.
Aerospace Industries Association (AIA). 1996. "AIA Position Statement on Ada." Unpublished manuscript. AIA, Washington, D.C., July 12.
Aley, James. 1996. "Give It Away and Get Rich." Fortune, June 10, p.98.
AT&T. 1993. "Best Current Practices: Software Architecture Validation." AT&T, Murray Hill, N.J.
Boehm, Barry. 1981. Software Engineering Economics. Prentice-Hall, Englewood Cliffs, N.J.
Boehm, Barry, and W.E. Royce. 1988. "TRW IOC Ada COCOMO Definition and Refinements." Proceedings of the 4th COCOMO Users Group, Pittsburgh, Pa., November.
Boehm, Barry. 1996. "Anchoring the Software Process." IEEE Software, Vol.13, No.4, July, pp.73-82.
Boehm, Barry, et al. 1996. "The COCOMO 2.0 Software Cost Estimation Model: A Status Report." American Programmer, Vol.9, No.7, July, pp.2-17.
Booch, Grady. 1987. Software Engineering with Ada, Third Edition, Chapter 3: "The History of Ada's Development." Benjamin/Cummings, Menlo Park, Calif.
Brooks, Jr., Frederick P. 1986. "No Silver BulletEssence and Accidents of Software Engineering." lnformation Processing 86, pp.1069-1076. (Reprinted in IEEE Computer Magazine, April 1987.)
Brown, Norm. 1996. "Industrial Strength Management Strategies." IEEE Software, Vol.13, No.4, July, pp. 94-103.
Carleton, Anita D., et al. 1992. "Defining and Using Software Measures." Software Engineering Institute Technical Reports, CMU-SEI-TR-11, 19-23 (CMU-SEI-TR-11, -19, -20, -21, -22). Software Engineering Institute, Pittsburgh, Pa.
Computer Science and Telecommunications Board (CSTB). 1989. Scaling Up: A Research Agenda for Software Engineering. National Academy Press, Washington, D.C.
CTA. 1991. "Survey and Analysis of Productivity and Cost Data on Ada and C++ Software Development Programs." CTA Incorporated, Burlington, Mass., June 26.
Department of Defense (DOD). 1976. Directive 5000.29, "Management of Computer Resources in Major Defense Systems." April 26.
Department of Defense (DOD). 1987a. Directive 3405.1, "Computer Programming Language Policy." April 2.
Department of Defense (DOD). 1987b. "Military Software." Defense Science Board Task Force on Military Software (Frederick P. Brooks, Jr., Chair), Office of the Under Secretary of Defense for Acquisition, DOD, Washington, D.C., September.
Department of Defense (DOD). 1991. "Draft DOD Software Technology Strategy." Director of Defense Research and Engineering, DOD, Washington, D.C., December.
|70||Ada and Beyond: Software Policies for the Department of Defense|
Department of Defense (DOD). 1992. "Delegations of Authority and Clarifying Guidance on Waivers from the Use of the Ada Programming Language." April 17.
Department of Defense (DOD). 1994a. "Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially." (see also) DOD, Washington, D.C., June.
Department of Defense (DOD). 1994b. "Specifications and Standards: A New Way of Doing Business." June 29.
Department of Defense (DOD). 1995a. "New World Vistas: Air and Space Power for the 21st Century. Information Technology Volume." (Summary Volume) Air Force Scientific Advisory Board, Washington D.C.
Department of Defense (DOD). 1995b. "Dual Use Technology: A Defense Strategy for Affordable, Leading-Edge Technology." Under Secretary of Defense for Acquisition and Technology, DOD, Washington, D.C., February.
Department of Defense (DOD). 1995c. "ARPA Software Review PanelFinal Report." DOD, Washington, D.C., October.
Department of Defense (DOD). 1996a. "Practical Software Measurement Version 2.1." Joint Logistics Commanders, Joint Group on Systems Engineering, DOD, Washington, D.C., March 27.
Department of Defense (DOD). 1996b. Directive 5000.1, "Defense Acquisition." February 21.
Department of Defense (DOD). 1996c. Regulation 5000.2-R, "Mandatory Procedures for Major Defense Acquisition Programs (MDAPs) and Major Automated Information System (MAIS) Acquisition Programs." March 15.
Department of Defense (DOD). 1996d. "Joint Warfighting Science and Technology Plan." Office of the Secretary of Defense, DOD, Washington, D.C., May.
Druffel, Larry. 1993. "Ada Position Paper." Unpublished manuscript, December 1.
Emery, James C., and Martin J. McCaffrey. 1991. "Ada and Management Information Systems: Policy Issues Concerning Programming Language Options for the Department of Defense." Naval Postgraduate School, Monterey, Calif., June.
Emery, James C., and Dani Zweig. 1993. "The Use of Ada for the Implementation of Automated Information Systems Within the Department of Defense." Naval Postgraduate School, Monterey, Calif., December 28.
Feigenbaum, Edward. 1996. "The Ada Mandate." Unpublished manuscript, Chief Scientist, U.S. Air Force.
Feldman, Michael B. 1996. "Ada as a Foundation Programming Language." Available on-line at http://www.seas.gwu.edu/faculty/mfeldman/CS1-2.html#2.
Fisher, D.A. 1976. "A Common Programming Language for the Department of DefenseBackground and Technical Requirements." Report P-1991. Institute for Defense Analyses, p.6. (Cited by G. Booch in Software Engineering with Ada, Third Edition, 1987, p.9.)
Fisher, David. 1974. "Automatic Data Processing Costs in the Defense Department." IDA Paper P-1046. Institute for Defense Analyses, Alexandria, Va., October.
Frazier, Thomas P., and John W. Bailey. 1996. "The Costs and Benefits of Domain-Oriented Software Reuse: Evidence from the STARS Demonstration Projects." IDA Paper P-3191. Institute for Defense Analyses, Alexandria, Va., June.
General Accounting Office. 1989. "Programming Language: Status, Costs, and Issues Associated with Defenses Implementation of Ada." GAO/IMTEC-89-9. General Accounting Office, Washington, D.C., March.
General Accounting Office. 1991. "Programming Language: Defense Policies and Plans for Implementing Ada." GAO/IMTEC-91-7OBR. General Accounting Office, Washington, D.C., September.
General Accounting Office. 1993. "Software Reuse: Major Issues Need to Be Resolved Before Benefits Can Be Achieved." GAO/IMTEC-93-16. General Accounting Office, Washington, D.C., January.
Giallombardo, Robert J. 1992. "Effort and Schedule Estimating Models for Ada Software Development." MTR 11303. MITRE Corporation, Bedford, Mass., May.
Hook, Audrey A., et al. 1991. "Availability of Ada and C++ Compilers, Tools, Education and Training." IDA Paper P-2601. Institute for Defense Analyses, Alexandria, Va., June 12.
Hook, Audrey A., et al. 1995. "A Survey of Computer Programming Languages Currently Used in the Department of Defense." IDA Paper P-3054. Institute for Defense Analyses, Alexandria, Va., January.
Horowitz, Barry. 1991. "The Importance of Architecture in DOD Software." M91-35. MITRE Corporation, Bedford, Mass., July.
IBM Federal Systems Division. 1985. "Language Selection Analysis Report." FAA-85-S-0874. Prepared for the Federal Aviation Administration, Gaithersburg, Md., May.
IIT Research Institute (IITRI). 1996. "Catalog of Resources for Education in Ada and Software Engineering, Version 8.0." Prepared for the Ada Joint Program Office, Arlington, Va., January.
Jensen, L.W., and S. Lucas. 1983. "Sensitivity Analysis of the Jensen Software Model." Hughes Aircraft Co., Los Angeles, Calif.
Jones, Capers. 1994. "The Economics of Object Oriented Software." American Programmer, Vol.7, No.10, October, pp.28-35.
Jones, Capers. 1995. "Backfiring: Converting Lines of Code to Function Points." Computer, Vol.28, No.11, November, pp.87-88.
Jones, Capers. 1996a. "Estimating and Measuring ObjectOriented Software." Unpublished manuscript, February 1.
Jones, Capers. 1996b. "The Economic Impact of the Year 2000 Software Problem in the United States-Version 2." Software Productivity Research Inc., Burlington, Mass., February 22.
Jones, Capers. 1996c. "Programming Languages Table, Version 8.2." Software Productivity Research Inc., available on-line at http://www.spr.com/library/langtbl.html.
Jones, Capers. 1996d. "Using Function Points to Evaluate CASE Tools, Version 4." Software Productivity Research Inc., Burlington, Mass., August 6.
Landry, Huet C. 1996. "Comments on Ada Mandate." Unpublished manuscript, Defense Information Systems Agency/JEBEB, Software Engineering Standards.
Lawlis, Patricia K. 1996. "Guidelines for Choosing a Computer Language: Support for the Visionary Organization." C.J. Kemp Systems Inc., March.
Lubashevsky. 1996. "'Backfire' Will BACKFIRE." Measure Up. Software Productivity Solutions Inc., Indiatlantic, Fla., January, pp.1-6.
Maranzano, Joe. 1995. "System Architecture Validation Review Findings." AT&T Software Technology Center, April.
Masters, Michael W. 1996. "Programming Languages and Life-Cycle Cost." Naval Surface Weapons Center, Dahlgren, Va., March 18.
McGarry, Frank, et al., 1994. "Software Process Improvement in the NASA Software Engineering Laboratory." CMU SEI-94-TR-22. Software Engineering Institute, Pittsburgh, Pa., December.
Mosemann, Lloyd K. 1991. "Ada and C++: A Business Case Analysis." (Summary) Deputy Assistant Secretary of the Air Force, Washington, D.C., July 9.
National Academy of Engineering. 1996. Defense Software Research, Development and Demonstration: Capitalizing on Continued Growth in Private-Sector Investment. National Academy Press, Washington, D.C., March.
National Research Council. 1995. Research-Doctorate Programs in the United States: Continuity and Change. National Academy Press, Washington, D.C.
Paulk, Mark C., et al. 1993. "Capability Maturity Model for Software, Version 1.1." CMU/SEI-93-TR-24. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., February.
Perry, William. 1996a. "National Academy of Engineering, Bueche Prize Acceptance Address." Transcript. National Academy of Engineering, Washington, D.C., October 2.
Perry, William. 1996b. "Defense in an Age of Hope." Foreign Affairs, November-December, pp.64-79.
Porter, Michael E. 1990. The Competitive Advantage of Nations. The Free Press, New York.
Powell, Colin. 1992. "C4I for the Warrior." DOD Joint Chiefs of Staff, Washington, D.C., June 12.
Quade, E.S., ed. 1964. Analysis for Military Decisions. Rand McNally, Chicago.
Quade, E.S., and Boucher, W.I., eds. 1968. Systems Analysis and Policy Planning: Applications in Defense. American Elsevier, New York.
Reifer, Donald J. 1996. "Quantifying the Debate: Ada Versus C++." Crosstalk: The Journal of Defense Software Engineering. Hill AFB, Utah, July.
Riehle, Richard. 1996. "Ada: An Update." Object Magazine, June, pp.50-52.
Royce, Walker. 1990. "TRW's Ada Process Model for Incremental Development of Large Software Systems." Proceedings ICSE 12, IEEE/ACM, March, pp.2-11.
Shaw, Mary, and David Garlan. 1996. Software Architecture: Perspectives on an Emerging Discipline. Prentice-Hall, Englewood Cliffs, N.J.
Telos Corporation. 1994. "Ada Marketing Communications Study Precampaign Survey." Telos Corporation, May. Tokar, Joyce. 1996. "Ada 95: The Language for the '90s and Beyond." Object Magazine, June, pp.53-56.
|72||Ada and Beyond: Software Policies for the Department of Defense|
TRW. 1991. "Ada and C++: A Lifecycle Cost Analysis." TRW Inc., Redondo Beach, Calif., June 1.
TRW. 1991. "Case Study: Ada and C++ Cost Comparison for CCPDS-R." TRW Inc., Redondo Beach, Calif., June 1.
U.S. Army. 1992. "Implementation of the Ada Programming Language." HQDA LTR25-92-1. September 18.
U.S. Army. 1994. "Change to HQDA Letter 25-92-1, Implementation of the Ada Programming Language." HQDA LTR25-94-1. July 17.
U.S. Army. 1995. "Change to HQDA Letter 25-94-1, Implementation of the Ada Programming Language." HQDA LTR25-95-1. July 17.
U.S. Navy. 1994. "Ada Programming Language Policy," SECNAVINST 5234.2A. April 28.
U.S. Navy. 1994. "Ada Implementation Guide," 2 Vol. (Volume I and Volume II) Naval Information Systems Management Center, April.
Vyssotsky, Victor. 1996. "Whither Ada?" Unpublished manuscript, May 12.
Waligora, Sharon, John Baily, and Mike Stark. 1995. "Impact of Ada and Object-Oriented Design in the Flight Dynamics Division at Goddard Space Flight Center." NASA-SEL Report, SEL-95-OO1 (see also Synopsis). Goddard Space Flight Center, March.
Weiderman, Nelson. 1991. "A Comparison of Ada 83 and C++." SEI-91-SR-4. Software Engineering Institute, Pittsburgh, Pa., June.
Zeigler, Stephen F. 1995. "Comparing Development Costs of C and Ada." Rational Software Corporation, Santa Clara, Calif., March 30.
National Research Council: Ada & Beyond
[Contents] [Part 1] [Part 2] [Part 3] [Part 4] [Part 5] [Part 6]