EBERARD@ADA20.ISI.EDU.UUCP (03/05/87)
Nearly two decades after Doug McIlroy described the need for a
software components industry, software reusability is finally
receiving some attention. One of the promises that the U.S. Department
of Defense (DoD) made when it introduced the Ada programming language
and its associated technology, was that Ada would help to facilitate
software reusability. Apparently, someone within the bowels of the DoD
feels that software reusability is an important issue.
A quick study of the possible benefits of reusing software reveals
that there is much more to be gained than a simple cost savings during
the development of a software product. For example, the reuse of a
software component which is known to be reliable introduces less risk
than re-designing and re-coding the same component for each new
application. Efficiency issues can also be more effectively addressed
if one can focus attention on optimizing a set of reusable components
rather than having to continually re-optimize newly recoded versions
of previously existing modules.
However, it seems that both the DoD and their contractors are greatly
confused about just what an increased emphasis on software reusability
might mean. While they both might acknowledge that some existing
software development practices will have to change, they seem unaware
of which specific items will be different. There are a number of very
large roadblocks to software reusability on DoD projects, and it
should be useful to mention a few of them.
One of the largest roadblocks to software reuse is the
cost-plus-fixed-fee (CPFF) style of contract now commonplace among DoD
contracting styles. In effect, the more people a contractor can place
on a project, the greater the financial reward. Hence there is a great
incentive to "re-invent the wheel." While fixed-price contracts would
go a long way towards fixing this "problem," we need to examine other
alternatives.
Current and past DoD software development standards (e.g.,
DOD-STD-2167, 490, 1679A, etc.), or their interpretations, are another
set of roadblocks to software reuse. While the words "software
reusability" might be "buried in the DIDs" (Data Item Descriptions),
the standards themselves discourage software reuse on a number of
fronts, e.g.,:
1) the encouragement of software development methodologies which do
not facilitate reuse (e.g., functional decomposition), while
discouraging others that seem to encourage reuse (e.g., object
oriented approaches), and
2) requiring that every piece of code produce for a project, be
relevant specifically to that project. While this might seem to
be a perfectly reasonable demand, it violates one of the axioms of
reusability, i.e., generality.
While the DoD has standards of acceptance for reusable hardware, there
is little in the way of standards or certification mechanisms for
reusable software. For example, there is no currently existing
organization charged with certifying software for reuse. Yes
repositories of "reusable" software exist, but there is no generally
recognized (much less mandated) certification mechanism for reusable
software components (e.g., an Ada Component Verification Capability
(ACVC)).
In the past year, I have given a number of presentations on software
reusability. During the discussions which followed these
presentations, I became acutely aware that either the DoD was
actively *discouraging* the concept of software reuse or that the
contractors (and the DoD) did not know that an increased emphasis on
software reuse would involve significant changes in the state of the
practice.
Until both the DoD and their contractors come to grips with the fact
that software reusability does not mean business as usual, software
reusability will be relegated to the status of a buzzword.
-- Ed Berard
(301) 695 - 6960
(r) Ada is a registered trademark of the U.S. Government (AJPO)
-------