EBERARD@ADA20.ISI.EDU.UUCP (03/06/87)
1.0 Introduction
Earlier, I posted a message about the roadblocks that the U.S.
Department of Defense (DoD) is placing in the path of software
reusability. This message describes a specific example of how an
attempt to encourage the reuse of Ada software on an actual DoD
project is being thwarted. Neither the contractor (a very large,
well-known west coast aerospace firm) nor the contracting branch of
the service (the Navy) has said that software reusability is a bad
thing. Both, however, are prevented by well-established DoD
regulations from both creating and reusing "reusable software."
2.0 Brief Technical Analogy
In the computer hardware industry, reuse is the norm. For example,
there are standard CPU chips (e.g., M68020, Intel's 8088, and various
versions of the 1750a). There are also standard RAM, mathematical
co-processor, and ROM chips. These, and other, chips are used in a
wide variety of applications. A long time ago, electronics engineers
discovered that one of the most important axioms of reusability was
generality.
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.
3.0 A Description of the Specific Problem
In the past year there has been no shortage of "software reusability"
presentations. Those of us on the "Software Reusability Circuit" seem
to take our show to an every widening audience. If you have attended
any software reusability presentations, or if you have read any of the
increasing numbers of articles on the subject, you have probably
noticed a pattern. Typically, the presenter or author describes a
"research project," or describes what sounds like a good idea, but
"hasn't yet been put into practice."
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 (no, unfortunately, I don't know what these
acronyms stand for, however they refer to an auditing 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 greatly reduced 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.]
4.0 Summary
Both the DoD and the contractors which provide software to the DoD
will have to change the way they do business if they wish to realize
the promised benefits of reusable software. Much more thinking will be
required on both sides. In the end, governmental software policies
will have to change, or their interpretations will have to become more
liberal. The contractors have as much to change (if not more) than the
government.
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.
-- Ed Berard
(301) 695 - 6960
-------