Architecture-centric approaches bring new credibility to software reuse as companies and government agencies grapple with reconciling technology and business issues
By John H. Mayer
Military and aerospace systems developers searching for ways to drive down costs need look no further than their system software. While hardware costs for weapons and other military systems have remained fairly stable through the 1990s, software costs have skyrocketed. Over the first five years of this decade, DOD officials estimate that software expenditures jumped from about $30 billion in 1990 to more than $42 billion in 1995. As systems continue to escalate in size and complexity, the prospects for those costs leveling off, let alone declining, seem highly unlikely.
One of the most promising solutions for holding down the cost of software development has been reusing code across more than one system. In this way software reuse offers the best of all worlds - the opportunity to increase engineering productivity and systems quality while simultaneously reducing the cost of building large, software-intensive systems.
Top DOD officials clearly recognize the potential benefits that reuse strategies offer. In 1991 they launched the Software Reuse Initiative (SRI) to establish a single department-wide software reuse approach. SRI aims at moving software reuse technology into the DOD mainstream and making this approach easy and inexpensive to use. The program is under the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence, in coordination with the Director of Defense Research and Engineering, and the Defense Advanced Research Projects Agency (DARPA).
SRI could act as an umbrella for the three primary reuse programs at DOD - DARPA`s Software Technology for Adaptable, Reliable Systems (STARS) program, the Air Force Central Archive for Reusable Defense Software (CARDS), and the Defense Information Systems Agency (DISA) Software Reuse program (SRP).
But despite these and complementary efforts in industry and academia, efforts to implement software reuse strategies on a broad basis have not succeeded.
"There have been a number of attempts over the years to try to solve the reuse problem and all of them have failed for one reason or another to deliver on their promise," notes Paul Bassett, author of "Framing Software Reuse: Lessons from the Real World" (Prentice Hall) and senior vice president of research of software tool supplier Netron Inc. of Toronto.
New approaches to software reuse are beginning to alter that perspective, however, and give fresh indications that software reuse can deliver on its potential. One new approach enables development teams to create reusable software assets by building a domain-oriented architecture and use common software across a product line
"Independent auditors are finding that these techniques are delivering fantastic reductions in time-to-market and development costs," Bassett says, noting that some analysts believe organizations can compress their development schedules by as much as 70 percent and reduce their software development costs by as much as 84 percent.
STARS efforts
Many of the services` successful efforts in software reuse in the early 1990s were products of the Software Technology for Adaptable Reliable Systems (STARS) program, which ended last year. STARS was to increase software productivity, reliability, and quality by folding modern software-development processes and reuse concepts into automated software engineering tools. The program was to force a fundamental change in the way DOD officials develop and buy software through three demonstration projects - one from each military service.
U.S. Navy officials, with help from DARPA, sponsored one of the earliest efforts, which attempted to measure how software reuse could lower costs, accelerate development, and improve the quality of an instrument simulator for the Navy`s primary aviation training aircraft, the T-34C. Its goal was to demonstrate the benefits of a product-line approach to software development from Boeing Defense & Space Group, one of three DARPA STARS prime contractors. The demonstration was closely aligned with a program to modernize the T-34C instrument simulator.
Early on the project faced its fair share of critics. "We set out to prove a large array of radically new concepts, practices, and technologies by applying them to an actual systems development," notes John Freeman with the Naval Air Warfare Center Training Systems Division in Orlando, Fla., in a report on the project. "Along the route, we encountered a veritable wall of skeptics, detractors, competing practices, technology surfers, and apathy."
The effort divided into three stages: a trial usage of the process, a pilot project on a small cross-section of one subdomain of the entire project, and finally six iterations of full-scale developments. Each stage was designed to produce successively larger and more complex portions of the trainer`s real-time software; the trainer was to be a member of a family of aircraft trainers.
Key to the project`s success was a two-lifecycle development approach based on the Reuse-driven Software Process from the Software Productivity Consortium in Herndon, Va. The first cycle calls for planning and engineering at the generic "family systems" level, while the second stage directs development of a specific application. "In applying this process, we found that identifying and representing requirements variables for the product line were significantly easier [and more repeatable] than designing a single adaptable solution that would satisfy the full range of variability," Freeman says.
The development team initially chose to focus broadly on navigation and communications, but refocused their efforts more specifically after several attempts to try to understand the process. They settled on the self-test switch of a Tactical Air Navigation (TACAN) radio navigation aid.
Developing a process to generate the code for a TACAN self-test switch was more expensive and time consuming than team members could ever hope to recover on future development of the self-test feature. Still, it proved valuable as a learning tool. Once the focus of the development effort changed to flight dynamics - more suitable the software product line approach - the program became cost-effective as well, Freeman says.
The results were persuasive. The team produced flight dynamics software for the T-34C instrument trainer as well as for all other flight trainers with similar characteristics. Measurements indicated the quality of the code was significantly better than industry averages. And while the product line approach in its first iteration cost two to three times more than normal, the project proved that ensuing code development for a follow-on T-44 trainer would cost as little as one-fourth of a conventional software development approach.
The Army STARS demonstration, cosponsored by the STARS program and the Software Engineering Directorate of the Army Communications-Electronics Command (CECOM) at Fort Monmouth, N.J., focused on software for the Intelligence- Electronic Warfare (IEW) program. Developers designed reusable software for the Emitter Location Processing and Analysis (ELPA) subsystem in the IEW. The project was comprised of 112,000 source-lines of code.
Developers projected a 4-to-1 return-on-investment, or a 40 percent reduction in support costs, if Army officials would adopt the architecture across a subset of IEW systems that used ELPA.
"The project has shown that the Department of Defense must and can embark on the paradigm shift needed to move the entire department from `stovepipe` systems to an architecture-based product-line approach for developing and maintaining software, noted Paul Kaminski, undersecretary of defense for acquisition and technology in a memo endorsing the project`s nomination for a Federal Technology Leadership award. "The promise of faster, better, cheaper software is achievable and the Army STARS demonstration project is showing the way."
Dramatic savings
U.S. Air Force experts drew even more dramatic results from a reuse project at the Space and Warning Systems Center (SWSC) at Cheyenne Mountain, Colo. With the help of DARPA and the STARS program, Air Force personnel developed the Automated Tracking and Monitoring Systems (ATAMS) in record time and at unexpected low cost. ATAMS receives, processes, and display a myriad of status data from various systems and subsystems in the ITA/AA network. It is designed to enable operators to recognize, analyze, and solve problems.
The project grew out of an need to manage the entire Integrated Tactical Warning/Attack Assessment network. To coordinate with the Cheyenne Mountain Upgrade program, the system had to be in place less than a year after development began. Further complicating the effort, Air Force officials required the system to be geographically distributed between Cheyenne Mountain and Offut Air Force Base, Neb., with each site retaining redundant servers connected to existing communications resources.
Initial contractor estimates in early 1995 indicated that system development costs would run to $10 million and would take two years to build. Faced with the possibility of a major delay to a vitally important program, SWSC managers turned to the reuse-based approach of the Air Force STARS team. Eleven months later the system was delivered for about $2 million - or one-fifth the estimated cost of conventional development. This despite the fact that the original two-message, four-display systems grew to a 57-message, 35-display system as the project progressed.
Critical to the project`s success was a product-line-specific architecture, a library of Ada components, and a complementary toolset. "When you mention reuse many people think classically about writing pieces of code and then using those pieces in various places," says Richard Randall, technology advocate for the STARS program with prime contractor Lockheed Martin Federal Systems in Gaithersburg, Md., and now employed by Kaman Sciences Corp. in Bloomfield, Conn. "What we tried to do was not only reuse pieces of code, but tools that are based on the architecture, so the code is generated automatically for you," he says. "That`s a different form of reuse."
Building on the experience of early pilot projects, team members enhanced the process with new technologies such as object-oriented analysis and design, cleanroom software engineering, and the iterative Ada Process Model. To make the most of tool interoperability, Lockheed Martin team leaders opted for an open-systems software engineering environment based on Ada, an architectural infrastructure toolset, and Lockheed Martin supporting tools for object-oriented modeling, documentation, workgroup communication, and coordination.
"There`s a lot of commonality among the ways these systems work," Randall says. Developers determined aspects common to components of the Integrated Tactical Warning/Attack Assessment network and built an underlying architecture that would handle all that commonality, he says. The next step was building a toolset around that commonality. "Anything to do with displays, for example, was done with a program called display builder that could take advantage of knowledge that`s common about the way displays are implemented in this case," Randall says.
Barriers to success
While DOD officials have begun to tackle the technical challenge of software reuse, business issues remain a formidable hurdle. Organizations are still grappling with issues such as who owns reused software, what strategies are most effective with contractors, and what happens as product lines mature.
"The real world is replete with examples of excellent technical solutions whose adoption has been hampered by insufficiently addressed business issues," notes John Willison, chief of the CECOM Software Solutions Lab. Officials of CECOM and other organizations have sponsored roundtables and discussions designed to tackle these issues, but a solution remains as yet undefined.
Cultural issues pose additional challenges. Traditional software acquisition encourages managers to build software systems from the ground up, even when many systems share a large set of common components. And there remains a strong bias against system components not invented, or written, in-house.
Still, the success of reuse efforts in the DOD to date and the payback they`ve delivered are promising. If any lesson has been learned, it is that software reuse can shorten the development cycle and reduce costs - when it is defined not as simply the reuse of software components, but of architectural elements, processes, tools, and engineering skills.
The T-34C training aircraft was the inspiration for one of the earliest STARS software reuse efforts-an attempt to measure how software reuse could lower costs, accelerate development, and improve the quality of an instrument simulator for the aircraft.
Ada, incentives drive commercial reuse
Commercial avionics designers historically have seen limited utility for software reuse. But a major breakthrough came in the early 1990s when engineering leaders at Boeing Commercial Airplane Group in Seattle required Ada in the new 777 airliner.
The new jumbo twinjet, with its projected 2.5 million lines of new code - six times that of any previous Boeing commercial airplane - and 79 different subsystems presented Boeing designers with an unprecedented software challenge.
Boeing officials acknowledged that using Ada would facilitate sound software engineering practices and build on the lessons learned in the development of defense systems. Pentagon leaders have mandated Ada for new real-time mission-critical systems since 1983. While Boeing designers later allowed the use of other languages such as C or assembly in certain situations, more than 70 percent of the 777`s was written in Ada.
Initially major subsystem developers such as Rockwell International Collins Air Transport Division in Cedar Rapids, Iowa, Honeywell Air Transport Systems in Phoenix, and Sundstrand Aerospace of Rockford, Ill., were reportedly less than enthusiastic about using any standardized language at all, let alone one that seemed as complex and immature as Ada. Sundstrand designers, for instance, were already six months into development of the 777`s main, backup, and external electrical power systems when Boeing engineers mandated the use of Ada.
But Ada enabled Sundstrand engineers to pull out certain chunks of the software and put them into new projects, says Dwayne Teske, program manager for the 777`s main electrical-generating system. On two more-recent projects, the Gulfstream V business jet and the U.S. Army Boeing/Sikorsky RAH-66 Comanche helicopter, Sundstrand engineers were able to integrate a library of common generic packages written in Ada for the 777.
Honeywell`s role on the 777 was to develop the largest computer on the airliner - the Airplane Information Management System (AIMS). Built around the 29050 processor from AMD Inc. of Sunnyvale, Calif., the multiprocessor rack-mount AIMS systems replaced many of the line-replaceable units on previous Boeing planes and reduced hardware and software redundancy.
Running more than 613,000 lines of code, the AIMS project occupied more than 550 engineers. To shorten development time and make the most of portability, Honeywell project leaders divided the effort up into seven major functions, each with 60 to 100 engineers. A loosely coupled architecture would also make it easy for Honeywell engineers to reuse the code on other projects.
When Motorola executives launched a reuse pilot program at their Israel facility a few years ago, they supported the program with cash-incentive awards. To encourage software engineers to share software components, company officials offered $100 for each item added to a database of reusable software. Each time another engineer retrieved a software component from the database for reuse, he split an additional award with the original developer. - J.M.
Workshop focuses on solutions
Interested in exploring the impact and benefits of reuse on the business enterprise? The "Reuse 97" workshop will examine "The Business of Reuse" by reviewing the technical and non-technical practices necessary for an organization to move to a reuse-based software development model.
The workshop will be at the Lakeview Resort in Morgantown, W.Va., July 21 to 24. More information is available on the World Wide Web http://access.mountain.net/reuseworkshop. - J.M.
