1. Introduction
2. Software Engineering in the Aerospace and Defense Industry
   • Reengineering the Software-Development Process
   • Elements of an Object-Oriented Software Process
   • Relative Maturity of Aerospace and Defense Software Practices
3. The Software Acquisition Process in the Defense Industry
4. Ada and the Aerospace and Defense Industry
5. Recommendations
6. Experience and Credentials
7. Authors

Introduction

Rational Software Corporation has been intimately involved with the pragmatic successes and failures of its customers' software-engineering projects across a broad range of aerospace, defense, and commercial applications for over 12 years. This paper examines three interrelated issues that directly affect the software capability of the aerospace and defense industry, and it summarizes the current maturity of software-engineering practices from Rational's perspective. Advances in software process, improvements in acquisition policy, and a continued focus on Ada must be integrated into a complementary approach to provide breakthrough improvements in the economics of sophisticated software development.

• "Software Engineering in the Aerospace and Defense Industry" examines the state of the industry, compares it to the best commercial practice in other industries, and defines the elements of a next-generation software process

• "The Software Acquisition Process in the Defense Industry" examines the Department of Defense's (DOD) software acquisition policy and its impact on the economics of software development in the aerospace and defense industry

• "Ada and the Aerospace and Defense Industry" examines DOD policy for a continued focus on Ada and its impact on the aerospace and defense industry

• "Recommendations" presents a set of recommendations for accelerating further adoption of modern techniques in the aerospace and defense industry

• "Experience and Credentials" provides some background on Rational Software Corporation

Software Engineering in the Aerospace and Defense Industry

Reengineering the Software-Development Process

• Accommodating change--situations in which requirements are expected to change over the life of the software, in which requirements definition requires extensive user input and iteration, or in which a flexible architecture is necessary to accommodate growth and change in function, technology, or performance

• Achieving software return on investment (ROI)--situations in which economic considerations require a high degree of reuse of preexisting components and/or newly developed components in a single system or across multiple systems in a given application domain or line of business

• Value engineering--situations in which accurate, rapid, and flexible trade-offs are needed between cost, schedule, functionality, quality, and performance throughout the development process

• Technical or schedule risk--situations in which schedule pressure, based on mission requirements or time-to-market considerations, or technical uncertainty, such as in complexity, scale, or concurrent engineering, require an incremental approach with early delivery of useful versions that provide a solid foundation for further evolution into more complete products

Elements of an Object-Oriented Software Process

• Object-oriented analysis, design, and programming. These techniques replace traditional data-driven methods and functional decomposition methods (structured analysis and design) with an integrated approach to analysis, design, and implementation based on an object model.

• Rapid prototyping and iterative development. These techniques replace the conventional waterfall model. In the process of rapid prototyping and iterative development, an initial version of the system is rapidly constructed early in the development process, with an emphasis on addressing high-risk areas, stabilizing the basic architecture, and refining the requirements (with extensive user input where possible). Development then proceeds as a series of iterations building on the core architecture until the desired level of functionality, performance, and robustness is achieved. This process places emphasis on the entire system rather than on the individual parts. Risk is reduced early in the project through a process of continuous integration, and integration surprises late in the project are minimized.

• Architecture-driven development. Traditionally, the software-development process has been requirements-driven--an attempt is made to provide a precise requirements definition and then to implement exactly those requirements. This process results in a development process and software that are very sensitive even to small changes in requirements. In an architecture-driven process, the goal is to produce an architecture that is resilient in the face of changing requirements within some reasonable bounds. The iterative development process produces a series of architectural prototypes that result in a robust architecture with the required properties.

• Large-scale reuse. Object-oriented design and an architecture-driven development process implicitly support reuse. Field experience, however, demonstrates that reuse must be an explicit management and technical objective to achieve economic results. Reuse is most cost-effective when reasonably large components, such as subsystems or class categories, are reused. Thus, the analysis, design, integration, and testing of these larger components can also be reused. Reusing individual classes or modules is important and effective but has less leverage than reusing larger subsystems consisting of many preintegrated classes and prefabricated objects.

• Software-process control and improvement. The transition to an object-oriented software process introduces new challenges and opportunities for management control of concurrent activities, tangible progress, and quality assessment. Real-world project experience has shown that a highly integrated environment is necessary both to facilitate and to enforce management control of the process. An environment that provides semantic integration--in which the environment understands the detailed meaning of the development artifacts--and process automation can improve productivity and software quality and accelerate the adoption of modern techniques. For example, it is difficult to fully exploit iterative development if the turnaround time for system builds is measured in days. An environment that supports incremental compilation, automated system builds, and integrated regression testing can provide rapid turnaround for iterative development and allow development teams to iterate more freely.

• Software first focus. The onset of open-systems standards such as UNIX, TCP/IP, and others, language standards such as Ada and Ada 95 with highly portable target implementations such as VADS(R), distributed architecture middleware such as UNAS, and target-platform-independent development environments such as Rational Apex(TM) has enabled the selection of target technologies--hardware platforms, operating systems, network protocols, and topologies--to be effectively postponed until the optimal time in a project's lifecycle. This is crucial in achieving effective software-based trade-offs between function, performance, cost, and scheduling in an environment in which target technologies change dramatically over a project's lifecycle.

Relative Maturity of Aerospace and Defense Software Practices

Object-oriented techniques have received considerable visibility over the last several years, but the aerospace industry has been a proving ground for many object-oriented concepts as applied to large systems over the last decade. Some of the early successes that demonstrated the economic benefits of object technology occurred in the aerospace and defense industry, primarily with Ada as the implementation language. The 1991 IDC white paper on object technology, targeting commercial industry, cites the experience of NobelTech (now CelsiusTech) as one of the first demonstrations of the economic payoff resulting from object technology. Beginning in 1986, NobelTech used object-oriented design, Ada, and iterative development to achieve large-scale reuse and to significantly enhance its competitive position.

Similarly, TRW and the United States Air Force have extensively documented the successes of architecture-driven development on command and control systems. The Command Center Processing and Display System-Replacement (CCPDS-R) project and the Cobra Dane System Modernization (CDSM) project achieved twofold increases in productivity and quality--primarily reductions in delivered error rates and efficiency of software change--along with on-budget, on-schedule deliveries of large mission-critical systems by employing Ada and an iterative development process substantially similar to that described in the previous section. These improvements were largely due to a major reduction (less than 25 percent) in the software scrap and rework enabled by architecture-driven iterative development, open-minded acquisition practices, and the use of Ada.

Although CelsiusTech and TRW were early adopters of architecture-driven development, over the last four years momentum has shifted toward using modern techniques on most of the large aerospace systems with which Rational is involved. This shift in momentum represents a fundamental change from the 1983 to 1987 time frame when Rational first began to recommend this process to customers in the aerospace and defense industry. During that time, most programs used functional decomposition, a waterfall lifecycle model, requirements-driven development, and so on. There was widespread resistance toward moving to new techniques in many areas.

• Program control. Software managers were concerned that the iterative approach to software development would turn programmers loose to start coding without requirements or a design. This violated the standard of the traditional waterfall model--no coding before critical design review (CDR)--and may have been a valid concern at that time, because iterative development had not been well-formalized and documented. Today, Rational and others have successfully demonstrated that iterative development and software technologies for rapid prototyping have matured dramatically. It is now well accepted that the iterative approach to software development gives managers greater control over projects than traditional waterfall models.

• Military standards. Program managers were concerned that iterative development was inconsistent with DOD-STD-2167 and other military standards. Although many people argued that the military standards did not define a development methodology, the default interpretation and application of the standards created significant issues. Over time, the standards have become more consistent with modern practices, but many government program offices still interpret the standards in a way that discourages iterative development and incremental deliveries.

• Economics. Some early programs did not see the economic case for reuse. Companies with many fixed-price contracts in competitive markets and those who were interested in producing a reusable product line immediately saw the benefits and adapted. Contractors with large cost-plus contracts who felt secure from competition often saw few economic benefits. The current budgetary environment has begun to change attitudes. Program managers are often realizing that cost and schedule overruns and poor software quality are likely to result in program cancellations in the current environment rather than additional revenue opportunities. Unfortunately, some programs still exist in which the resistance to adopting new technology is based not on skepticism that the technology will provide an adequate ROI, but rather on concern that the technology will perform as promised--reducing costs and therefore reducing revenue and profits. Again, this is primarily an issue for cost-plus or level-of-effort contracts.

• Inertia. Most program managers are conservative and do not want to be early adopters of a new technology. This was certainly a reasonable position to take with respect to Ada, object-oriented design, and iterative development from 1983 through 1987. Today, there is a shift toward adopting these techniques throughout the aerospace industry.

There has been general acceptance of object technology, architectural focus, and iterative development in other market segments only in the last three years, and the usage there is predominantly in exploration rather than in full-scale production. Even in the telecommunications industry, an advanced and sophisticated market, the rate of adoption of new techniques is no faster than in the aerospace industry.

Three major factors have contributed to the adoption of modern techniques in the aerospace and defense industry.

• Leading-edge technology. Like many other technologies, such as semiconductors, materials, algorithms, and so on, aerospace and defense systems frequently push the limits of software technology because of the scale of the systems being built and the extremely demanding requirements. From distributed systems to massively parallel processing and from enormous databases to extreme real-time performance, aerospace and defense systems continually push the limits of the possible, while also requiring high reliability and affordability. These pressures demand the best possible software-engineering technology and motivated the exploration, and then the adoption, of an object-oriented software process.

• Focus on engineering rigor. Although some market segments have emphasized software development as an art and occasionally encouraged a "hacker" mentality, the aerospace and defense industry has generally viewed software development as an issue of engineering discipline. Perhaps because of the serious nature of the defense business or perhaps because of a similar focus on life-critical software, such as commercial avionics and air-traffic-control systems, the aerospace and defense industry has embraced software engineering as a top priority. This is now true of many other industries, such as medical instrumentation, telecommunications, and so on, partially because of increasing product-liability issues and the focus on total quality management and continuous process improvement. Ironically, this focus on engineering is also largely responsible for producing many of the classic methods--functional decomposition, waterfall-lifecycle model, and so on--that sometimes stand in the way of progress.

• Transition to Ada. In the late 1970s and early 1980s when Ada was being developed, the primary focus was on producing a single standard language for embedded and mission-critical systems. This language would replace more than 400 languages in use at that time, thereby reducing the tooling, training, development, and maintenance costs associated with DOD software. Although Ada indeed provided a standard language in the DOD, an even more important result has been that Ada has served as an effective catalyst for the adoption of modern software-engineering principles. Some of the early Ada projects viewed Ada as just another programming language like JOVIAL, FORTRAN, or C. For those projects, programs were designed in the same way they had been designed in previous languages and then coded in Ada. This approach reaped few of Ada's benefits and incurred many of the costs of making the transition to a new technology. Fortunately, most of the aerospace and defense industry quickly realized that there was much more to Ada and proceeded to fundamentally reevaluate all software-engineering practices. This reevaluation eventually led to the adoption of more modern techniques.

The Software Acquisition Process in the Defense Industry

• Requirements definition. The conventional waterfall model depends completely and unambiguously on specifying requirements before other development activities, treating all requirements as equally important, and keeping those requirements constant over the software-development lifecycle. These assumptions do not work in the real world. Requirements specification is both the most difficult and the most important part of the software-development process. Virtually every major software program suffers from severe difficulties in requirements specification. Moreover, the treatment of all requirements as equal has drained countless engineering hours away from the driving requirements. Effort is wasted on MIL-STD-required paperwork associated with traceability, testability, logistics support, and so on that is inevitably discarded as the driving requirements and subsequent design understanding evolve. The difficulty of correctly specifying and prioritizing requirements for complex systems has been one of the primary forces behind the move from the waterfall lifecycle model to more iterative lifecycle models. Iterative models allow the customer and the developer to work with successive prototype versions of the system. Pragmatically, requirements can, and must, be evolved along with an architecture and an evolving set of application increments so that the customer and the developer have a common understanding of the priorities and an objective understanding of the cost, schedule, and performance trade-offs associated with those requirements.

• Waterfall architecture and design. Conventional techniques tend to impose a waterfall model on the architecture and design process that inevitably results in late integration and performance showstoppers. In the conventional model, the entire system is designed on paper, implemented all at once, and then integrated. It is not possible to perform system testing to verify that the fundamental architecture (interfaces and structure) is sound until the end of the process. Iterative development produces the architecture first and allows integration to occur and design flaws to be detected and resolved earlier in the lifecycle. This approach replaces the big-bang integration at the end of a project with continuous integration throughout the project. Iterative development also enables more insight into quality, because system characteristics that are largely inherent in the architecture--performance, fault tolerance, maintainability, and so on--are tangible earlier in the process when issues are still correctable without jeopardizing target costs and schedules.

• Heterogeneous lifecycle format. Given the immature languages and technologies employed in the conventional approach to defense software, there is substantial emphasis on perfecting the software design before committing it to the target programming language, where it is then difficult to understand or change. This results in the use of multiple formats--requirements in English, preliminary design in flowcharts, detailed design in program design language (PDL), and implementations in the target language, such as FORTRAN--and error-prone, human-intensive translations between formats. The combination of Ada and iterative development allows for a much more homogeneous representation format across the software lifecycle, namely a readable, compilable, and executable library of integrated Ada components. This combination eliminates the need for error-prone translations between different, often incompatible formats in favor of evolutionary refinements in abstraction and the ever-increasing depth and breadth of tangible functionality, quality, and performance. Figure 1 illustrates the difference in focus between the intermediate products of the two lifecycle models.

• Adversarial relationships. Largely because of difficulties in requirements specification, the conventional process tends to be adversarial, with the customer and the contractor all too frequently locked in combat. Many aspects of the classic acquisition process degenerate into mutual distrust. This makes it very difficult to achieve a balance between requirements, schedule, and cost. A more iterative model--with a closer working relationship between customer, user, and contractor--allows trade-offs to be made based on a more thorough understanding on all sides. This model requires a competent and demanding program office with both application and software expertise and a focus on delivering a usable system rather than on blindly enforcing standards and contract terms. The contractor must be allowed to make a good profit with good performance and, at the same time, focus on achieving customer satisfaction and high product quality in a businesslike manner.

• Focus on documents. The conventional process focuses on producing various documents that attempt to describe the software product and pays insufficient attention to producing tangible increments of the product itself. Major milestones are defined solely in terms of specific documents. Contractors are driven to produce documents to meet milestones rather than to spend their energy on tasks that would reduce risk and produce quality software. An iterative process requires construction of a sequence of progressively more complete systems that demonstrate the architecture, enable objective requirements negotiations, validate the technical approach, and address the resolution of key risks. Ideally, both the government program office and the contractor would be focused on real milestones, with incremental deliveries of useful functionality rather than speculative paper descriptions of the final vision.

• Requirements-driven functional decomposition. A fundamental property of the conventional approach is that it has been driven by functionally specified requirements. Built into the classic defense acquisition process is the assumption that the software itself is decomposed into functional components--CSCIs, CSCs, and CSUs in 2167A terminology--and that requirements are then allocated to these components. This decomposition is often quite different than a decomposition based on object-oriented design and reuse. The functional CSCI decomposition becomes anchored in contracts and subcontracts, often precluding a more architecture-driven approach.

• NIH ("not invented here" syndrome). The conventional process discourages reuse between projects and tends to discourage the use of commercial technology. Because requirements are often dictated to the software developer, there is little opportunity to negotiate the compromises that are required to reuse an existing product or subsystem. Furthermore, effectively building reusable components or subsystems necessitates investment above and beyond what is required for the narrow scope of the project at hand. Ideally the process would encourage customers and contractors to invest in developing reusable architectures that could be applied to a variety of systems in a given domain, such as avionics, C3I, and so on. Instead, the current process and incentives prevent most investment in reuse through encouragement of specific and singular contract-selfish performance.

• Economic incentives. As part of the adversarial nature of the acquisition process, there is considerable focus on ensuring that contractor profits are within a certain acceptable range (typically 5 to 15 percent). Occasionally, excellent contractor performance, good value engineering, or significant reuse result in potential contractor profit margins in excess of their acceptable initial bid. As soon as typical government customers (or other organizations allied with the acquisition) become aware of such a trend, substantial pressure is inevitably applied to employ these excess resources on out-of-scope changes until the margin is back in the acceptable range. Consequently, the simple profit motive that underlies commercial transactions and motivates efficiency is replaced by complex contractual incentives that are usually suboptimal. Contractors see neither economic incentive to implement major cost savings nor incentive to take risks that may have a large return. On the other hand, contractors can easily consume large amounts of money, usually at a small profit margin, without producing results or answering for poor performance.

Figure 1 Conventional development products versus iterative development products

Ada and the Aerospace and Defense Industry

Ada 83's semantics can be characterized by strong support for project-management functions and by somewhat lesser support for the advanced computer-science attributes of object-oriented programming, which evolved after Ada 83 was baselined. These drawbacks, however, will be substantially corrected by Ada 95. In spite of Ada's success, the invention of new languages has continued unabated in commercial industry. C++ is one example of a relatively new language whose primary design goal was to provide support for object-oriented programming--encapsulation, abstraction, polymorphism, inheritance, and so on--without compromising the advantages of C (primarily speed and ease of programming). In contrast to Ada, C++ provides little project-management support in its selected semantics, but it is designed for stronger support of the computer-science attributes underlying object-oriented design.

The definition of the Ada language is unique in that it was designed to enable better management, design, and architectural control--the higher-leverage aspects of software engineering--while sacrificing some ease of programming. This is the essence of the Ada culture: top-down control where programmers are subordinates of the lead architects and managers. Other languages--specifically C++--focus on simplifying the programming activities while sacrificing some of the ease of control. This, of course, is the essence of the C/C++ culture where programmers lead the way. For small programs and noncritical projects, the C++ culture can work well, and the Ada culture is perhaps overkill. For large, complex, mission-critical systems, though, the Ada culture is a field-proven necessity for success. Culture is a set of trends imposed by humans. Clearly, an Ada culture can be practiced with C++ and vice versa, but the paradigm shift for an organization with cultural inertia is an emotional and extremely difficult undertaking.

Table 1 Evolution of Ada risk from 1985 to 1994

The greatest contribution of Ada was to act as a catalyst for the adoption of modern software-engineering practices. There has been substantial progress in the software technology used in this industry over the past decade. Figure 2 depicts the ongoing transition of software economics from the conventional diseconomy of scale--caused by the dominance of custom development, ad hoc processes, and ad hoc environments--to the emerging megaprogramming economy of scale--achieved by organizations that exploit reuse, integrated environments with high levels of automation, and mature iterative development techniques. Ada helped software engineering mature into a true professional engineering discipline in this community. Ada provided a standard and portable language widely available on almost all hardware platforms and with extensive support for modern software-engineering principles. Ada has also been a vehicle for introducing new lifecycle models, new tools, new design and programming practices, and more secure approaches to the development of high-reliability and safety-critical software. Considerable momentum has been established, and this momentum is accelerating with the recent emphasis in both Ada 83 and Ada 95 on the use of object-oriented analysis and design with Ada.

Recently, there has been considerable discussion of the DOD policy toward Ada, with some polarization of those who believe the current policy should be continued or strengthened and those who believe the current policy should be abandoned. It is useful to examine the key positions and assess their validity from the perspective of Rational's experience.

The arguments for continuing the Ada mandate can be summarized as follows:

• Technical advantage. Virtually every language-evaluation study we know of has concluded that Ada is the best technical language for the DOD domain. Ada has satisfied the goals of the DOD as a highly reliable and maintainable language. Its strengths include support for large-scale projects, ultrareliable software development, standardization, and real-time support--exactly the needs of the defense domain and other mission-critical domains in which complexity control and certifiability are required. Ada mandate risks have been substantially resolved, whereas the other leading alternative, C++, is faced with many of the same risks that Ada faced 10 years ago (see Table 1).

• Inertia. Ten years of DOD investment have resulted in a substantial base of Ada assets, including compilers, training, reusable components, and case studies. Furthermore, Ada is commonly preferred by DOD contractors and several domains, including global air-traffic control, NASA, nuclear power, FAA, NATO, and so on, employ Ada in the absence of any mandate.

• Standardization. The DOD's business case is very different than commercial industry's business case. The need for a standard language in the DOD is motivated by the current practice of organic maintenance with high personnel turnover rates, in which the costs of tooling and training the maintenance force for a single language have huge economic benefits. Ada was developed to address the divergence of languages, the lack of support for environments, and the lack of any ROI in personnel training from assignment to assignment. This need is just as important today as it ever was.

• Economics. A substantial number of very large applications (greater than one million source lines of code) have been successfully delivered and maintained in Ada. Although there is certainly not universal success in the financial performance of Ada projects, substantial evidence indicates that a mature software organization will perform better with Ada than with other languages. There are two important trends to note:
  • Before Ada there were close to zero large-scale projects that delivered on-budget or on-schedule. Over the last 10 years of using Ada, there have been several well-publicized successes.

  • Across all projects that have been less than successful, none has attributed its failure, in whole or in part, to Ada.

Figure 2 Progress toward improved software economics

• Lack of object-oriented support. Ada 83, though clearly not supportive of all the object-oriented programming features popular today, does support many of the techniques and processes of object-oriented software engineering as described earlier in this paper. In fact, most of the large-scale, successful Ada projects that Rational is familiar with were successful predominantly because they employed object-oriented techniques and modern processes. The main advantage of these modern techniques is in the process and architectural focus, not in the programming-language support. Furthermore, the Ada community has embraced the advantages of object-oriented programming support directly in the language, as evidenced by their inclusion in Ada 95.

• Lack of commercial support. The argument that Ada lacks support in the commercial marketplace is subtle. On one hand, anyone who walks into any bookstore's software section will find over 20 books on C++ and only a few books on Ada. On the other hand, despite their scarcity in commercial bookstores, there are more than 30 textbooks on Ada, and Ada is becoming an increasingly popular vehicle for teaching software engineering at universities. Numerous non-DOD projects employ Ada for technical and financial reasons. In general, these commercial applications are similar to DOD applications in scale and complexity, and the organizations choose Ada for the same reasons as the DOD. Perhaps there would be more acceptance of Ada in other commercial applications if the DOD had done a better job of marketing, but then again, perhaps there would not. The real issue here is whether the DOD and the commercial domain must be closely related. A large percentage of the commercial market's software is completely incongruent with DOD software, and many commercial practices are equally inappropriate to most DOD software--the glaring exception being the DOD's MIS systems that differ only in their scale from commercial MIS systems. A principal inhibitor of Ada's commercial acceptance is probably the lack of PC-based tools. The impact of PCs on training, software development, and available commercial off-the-shelf (COTS) products is profound. The huge installed base of PCs drives the software market trends, and the lack of Ada support on PCs inhibits the largest source of cheap computing cycles from being part of the Ada solution space. The GNU Ada Translator will help this problem considerably, and the emerging next-generation PC operating systems will enable today's Ada environments to more easily make the transition to PC platforms.

• Insignificant Ada market segment. This argument is closely related to the previous one, but instead of focusing on commercial projects, it addresses commercial product markets. In 1992, the Ada compiler and tool market was somewhere in the range of $200 to 300 million, while the C++ compiler and tool market was $300 to 500 million. Although the Ada market is certainly smaller, it is by no means insignificant, and there is ample demand to stimulate considerable investment by small and large companies.

• Conflict with the use of COTS products. Fewer COTS products are available for Ada than for some other languages. However, there is no real issue about integrating Ada with COTS products. Most of the globally important interfaces, such as DBMSs, graphical user interfaces (GUIs), operating systems, and network protocols, have been developed. Furthermore, there are Ada-based COTS products for development environments, such as Rational Apex and VADS, and architecture middleware, such as UNAS, that are better than their counterparts in other languages and provide proven leverage in achieving technical and financial success in large, complex software projects.

Recommendations

• Rational recommends that the DOD and other agencies such as the FAA, NASA, and so on be more demanding customers with a focus on results. The DOD, though not so dominant that it drives the entire software industry, is a large customer with significant clout. By demanding quality software at reasonable prices on reasonable schedules, the DOD can, and will, make an impact on the behavior of the industry. Demanding performance and refusing to tolerate failure will strengthen the industry and encourage the adoption of the best practices. Programs with a significant track record of poor management, severe cost and schedule overruns, and poor software quality--defined in terms of fitness for use, not just defects and compliance with narrow specifications--should be terminated promptly, regardless of fault. This attitude must be tempered with the understanding that software development contains risk, and one must not discourage appropriate risk taking. However, over the medium and long term, a more businesslike and demanding attitude on the part of the government--similar to the commercial market in which weak products and producers are eliminated rapidly on evidence of failure--will be much less expensive than continuing to subsidize poor performance. Without doubt, this is the most important recommendation.

• Rational recommends full and continued support for Ada as a centerpiece of aerospace and defense software policy (DOD, NASA, FAA). As discussed in the previous section, there are strong technical and business reasons for using Ada in defense applications.

• Rational recommends that the DOD continue to encourage the use of COTS technology. Procurement and project-management practices must consistently encourage use of commercial technology. There is insufficient incentive today to use commercial technologies, and there is absolutely no incentive to compromise often arbitrary requirements to allow the use of commercial technology. Although some may disagree, Rational views this as synergistic with the Ada initiative.

• Rational recommends continued efforts to streamline and modernize the software acquisition process. The new MIL-STD-498, replacing DOD-STD-2167A and DOD-STD-7935A, is a step in the right direction but does not go far enough with respect to the state of practice. The pace of such a global change remains excruciatingly slow, and most program offices do not understand modern software-engineering principles well enough to properly manage software acquisition with the new standard. Further promotion and adoption of iterative development processes, in which success and failure signals are more obvious and tangible earlier in the lifecycle, is also critical to achieving success in the first recommendation. The DOD and the contractor community must institute a more aggressive program of process improvement to rapidly evolve the defense software acquisition process into a quality process. The DOD must become less insular and reach out to understand the best practices and lessons learned in other software markets.

• Rational recommends stronger support for applied research in software technology in the United States. Traditionally, software-related technology efforts have been extremely underinvested by both the government and defense contractors. For example, recent awards for the Technology Reinvestment Program were quite discriminatory against funding software-related efforts despite the rapidly growing importance of such technologies. Software technology remains a core competency of American industry. Not only is advanced software technology developed in the U.S., but it is also rapidly exploited and applied. The U.S. software market remains the largest and the most competitive worldwide, and all of the participants, including the aerospace and defense industry, benefit from the dynamic nature of this market. Further investment would maintain this commercial competitiveness as well as benefit the DOD software marketplace.

• Rational recommends that the DOD institute a required training program for all DOD project offices involved in acquisitions with software content greater than some defined threshold (such as $1 to 5 million). This program should be modeled after the Air Force's BOLDSTROKE course but contain more up-to-date project case studies and focus more on software project management and acquisition. Furthermore, although the DOD has successfully applied the Software Engineering Institute's (SEI's) Software Capability Evaluations to choose contractors with software-process maturity, it has yet to apply similar discipline to its own acquisition project offices.

Experience and Credentials

Rational is a provider of software-engineering tools and services, with the mission of ensuring the success of customers developing software-intensive systems. Rational was founded in 1981 as a venture-funded startup. Today, Rational is a rapidly growing, worldwide enterprise with calendar year 1993 revenues in excess of $65 million (including all continuing operations from the merger with Verdix).

Rational began developing large commercial software products in Ada in 1981. Ada was selected as the system programming language in Rational for two fundamental reasons:

• Rational required the best possible software-engineering technology available at the time. The success of the company depended completely on the ability to rapidly develop complex software products, respond to changing customer requirements, and take advantage of new business opportunities by leveraging software as a strategic asset.

• Rational believes in using the technologies that our customers use. Therefore, it was important for Rational to have as much, if not more, experience with Ada as any of our customers.

In addition to providing Ada customers with software-engineering tools, Rational provides a complete set of related services, including object-oriented analysis and design training with Ada, training in iterative development and project management, architecture and design consulting, process consulting, code reviews, performance reviews, tool integration, and limited custom tool development. At most large customer sites, Rational personnel are involved in a project throughout its lifecycle. This approach ensures that customers using Rational's tools are successful in applying the technology. This approach has also allowed Rational to directly participate in hundreds of Ada projects undertaken by over 50 different contractors and system integrators. These projects include command and control systems (C3I), management-information systems, and real-time embedded systems (avionics, process control, weapons control, and so on). This experience has provided Rational with considerable insight into many of the technical, cultural, organizational, and economic factors involved in employing modern software-engineering practices with Ada.

Rational has also developed several large commercial products in C++ over the last four years. These products have involved the development of new code (approximately 500,000 lines of C++ source code), the use of existing commercial class libraries, and the use of code generators and GUI builders. Although C++ and the associated tools are considerably less mature than Ada, a primary motivation for using C++ for these products has been to have as much experience as possible to better serve customers using the technology. At this point, Rational has a complete understanding of the economics of C++ software development and maintenance on a number of different platforms (primarily UNIX and DOS/Windows).

As with Ada customers, Rational provides extensive services to complement products for C++ customers, including object-oriented analysis and design training with C++, training in iterative development and project management, architecture and design consulting, process consulting, and so on. This experience has allowed Rational to participate in a wide range of C++ development projects, including process control, telecommunications, information systems, and system-software projects. This experience has also provided Rational with insight into many of the technical, cultural, organizational, and economic issues associated with C++ and object technology.

The rather unique combination of Ada and aerospace experience on the one hand with commercial experience using a variety of languages (Ada, C++, Smalltalk, and so on) on the other hand provides Rational with a valuable perspective on the issues of Ada, software engineering, and the acquisition process.

Authors

Walker Royce is the director of software-engineering process for Rational Software Corporation. Before joining Rational Software Corporation, Mr. Royce spent 16 years in a variety of software-technology and software-management roles at TRW. He was the project manager of the Universal Network Architecture Services (UNAS) product line, where he defined and managed its state-of-the-art software process. He served as the software chief engineer responsible for the software process, the foundation Ada components, and the software architecture on the CCPDS-R Project, a highly successful, million-line Ada project. Mr. Royce led the development of TRW's Ada Process Model and the UNAS product, technologies that have made the transition from research into practice on numerous large projects and earned him a TRW Technical fellowship and TRW's Chairman's Award for Innovation. His pioneering work in advancing distributed software architecture and evolutionary software-process technologies has been published in numerous technical articles and guidebooks, and he is a featured lecturer at the Air Force BOLDSTROKE forum on software management. Mr. Royce received his bachelor of arts degree in physics at the University of California, Berkeley, in 1977 and his master of science in computer information and control engineering at the University of Michigan in 1978. He completed three years of further post-graduate study in computer science at UCLA.