Does the DoD Really Want Reusable Software?
(Part 2)

By Edward V. Berard (The Object Agency, Inc.)

Introduction

Brief Technical Analogy

Unlike their software counterparts, electronics engineers do not have to verify, for example, that every "op-code" supported by a particular CPU is executed in a specific application. Nor do they have to demonstrate that every last byte of RAM is utilized. While the reasons for this should be obvious, it would be helpful to point out a few of them:

1. Once a CPU chip is created and verified, a known (and typically very high) level of reliability can be established for the chip. When this chip is reused in another application, its known reliability can be factored into a determination of the overall reliability of the new system. [While a great deal is currently known about software reliability, much more is known about hardware reliability.]

2. If a change is introduced into the software which is running on a particular CPU chip, specifically a change which now requires that a previously unused "op-code" come into use, there is little need to replace (or alter) the CPU chip. [Think of an Ada package as a chip, and the operations in its interface as "op-codes." ] A similar argument could be made for the amount of random access memory incorporated in a computer system.

3. As new engineers are assigned to a project, it is likely that they may have experience with standard, reusable chips. Even if they do not have experience with the specific chips being used, there are certain fundamental concepts which are common to particular classes of chips, and the new engineers are likely to be aware of these concepts.

4. With the demand for computer hardware (everything from embedded systems to stand-alone computers) at an ever increasing high level, the cost and time required to custom-design chips so that they are optimized for a specific application is prohibitive. [Notice that since few organizations track real software costs, that it is often difficult to make a similar justification for not overly-customizing software.]

How does one apply the above analogy to reusable software? Consider the design of a reusable software component. To be truly reusable, a software component must be usable in some place other than its current specific application (or part of an application). To increase the chances of this happening, the software engineer must make the component more general. In fact, there are well-known ways of increasing the generality of a software component to a very high level.

Of course, there are trade-offs. Increasing the generality may decrease the efficiency, or even increase the complexity. These, and other considerations, must be balanced against such factors as the potential increased reliability resulting from using a known verified component, and the cost and times savings resulting from software reuse.

A Description of the Specific Problem

This points out one of the interesting human aspects of new technology. Since introduction of new technology requires change, and human beings are, by nature, conservative, it almost always takes a certain minimal amount of time before new technology can actually be introduced into the workplace. So we go about our "dance." We have meeting after meeting on the topic, and everyone seems to be in general agreement (software reusability sounds like a nice idea). However, nothing gets done until someone actually demonstrates the validity of the concept on a "real" project.

At my company, we have both discovered (probably re-discovered) and demonstrated some of the fundamental concepts of software reusability. Further, since we often find ourselves in a teaching role, we try to communicate these concepts to our clients during the normal course of our classroom instruction. Almost always, our students have "real projects" to which they must immediately apply the technology covered in our classes. As you are probably aware, teaching in industry must be very pragmatic, and real world oriented.

Recently, one of us was describing how to increase the reusability of software components during a class at the previously mentioned large aerospace firm. He was informed that while the techniques he was describing might indeed increase the reusability of Ada software, there were forbidden by specific DoD policy. I asked the instructor to have the students document the problem. What follows is that documentation:

1. MIL-HDBK-272 requires that there be no "extraneous code" in a program that is involved in the Nuclear Safety community. The "extra" functions which might make a software component more general, and hence more reusable, are forbidden. [Notice that this (unknowingly) trades off one kind of software reliability (i.e., the increased reliability resulting from less code in the software product) against another (i.e., the potential increase in software reliability resulting from the use of a known, verified component.]

2. C/SCSC - AFPRO/DCAA (Cost/Schedule Control System Criteria - AFPRO/Defense Contract Audit Agency). There are audits to insure that the contractor is only doing what the contract states. [This is part of a classic "Catch 22" phenomenon. Specifically, it may be permissible for a contractor to reuse software (although given the current hostile climate for " extraneous code," this may be difficult), however no new reusable software may be generated on a project if it requires any generality outside of the scope of the immediate problem.]

3. The original contract had no requirement for reusable software. If any resources are expended on increasing the reusability of any of the software components, the contractor will not be compensated for these expenditures. [Another axiom of reusability is that the original design, implementation, and verification of a reusable component are more costly than similar processes carried out without reusability in mind. However, the more reusable the component, the quicker the payback and the greater the future savings.]

4. A particular danger, according to the contractor, (one that DCAA/AFPRO will look for) is that if the contractor creates reusable software on a cost-plus-fixed-fee contract, he may not reuse the software on a fixed-price contract and charge the government (again) for the software. [This is an interesting paradox. The government would rather pay the much larger cost of a completely original piece of software, than be charged twice for the same reusable software components -- even if the reuse of software components results in a great reduction in the cost of a new product.]

5. The cost of documenting and distributing the reusable software would not be an allowable cost on any contract. [Here, I have no sympathy for the contractor. This is merely a cost of doing business, and further, such costs can be factored into the contractors fee.]

Summary

Software reusability, unlike a great deal of software engineering technology, can show a payback in a relatively short period of time. I hope that both the government, and the software community as a whole expend the time and effort required.