Does the DoD Really Want Reusable Software?
By Edward V. Berard (The Object Agency, Inc.)
Those of us who pose problems to others should also pose possible solutions to
those problems. In my previous three messages, I observed that the U.S.
Department of Defense (DoD) had (hopefully unwittingly) placed a number of
roadblocks in the path of software reusability. I also observed that those
contractors who provide software services to the DoD need to make some changes
to fully exploit the concept of software reusability. The purpose of this
message is to offer a few suggestions to both the DoD and their contractors on
that same subject.
First, to the DoD:
- Current and future software standards and policies should be explicitly
examined for their impact on software reusability. This is a
technical problem. Merely placing such words as "software
reusability" in a standard or policy will not guarantee sound reuse of
software. Concepts such as software development methodologies, software quality
assurance, and efficiency have a direct impact on software reuse. The DoD
should avoid supporting software reuse in one part of a standard or policy
while discouraging it in another part of that same standard or policy.
- A "Software Reusability Plan" (SRP) should be a required part of any
contractor's software proposal. This plan should include descriptions of the
tools and libraries the contractor plans to use to exploit software reuse, the
level of software reuse training for both the software engineers and their
management, estimates of the level of software reuse for the particular
project, and a statement on the impact of software reuse (positive and
negative) for this project.
- Software contractors should also be required to produce a short
post-project assessment of the impact of software reuse on their project.
These assessments should be placed in the public domain whenever possible.
- With all due respect to the good work that Rick Conn has done with the Ada
Software Repository (ASR), the mandate of the ASR should be re-examined. One of
the original goals of the ASR was to provide a number of examples and tools to
those just getting started in Ada technology. There were few, if any,
restrictions placed on the software which was placed in the ASR. We need to
recognize that the repository might be made more useful by subjecting (at least
some) of the Ada software to some kind of quality assurance.
- The DoD should either establish, encourage the establishment, or recognize
the equivalent of an "Underwriters Laboratory" for reusable software. This
entity would be charged with indicating the quality of potentially reusable
software. This is no small task.
Second, for the contractors:
- Establish an internal software reuse plan. Regardless of whether the DoD
ever requires it of its contractors, such a plan can help an organization
control both the quality and costs associated with software.
- Require that software reusability be an integral part of any technical and
managerial training. This should be especially true for Ada-related training.
- In accordance with your in-house software reusability plan, acquire the
tools and libraries you feel will most positively contribute to the reuse of
software within your organization.
- Encourage the use of methodologies and tools which have been demonstrated
to enhance the reuse of software.
- Track and measure both the reuse of software and the impact of software
reuse. Policy decisions should be made on "hard data," not on guesswork.
- Management must let it be known that it actively encourages the reuse of
- Recognize that more than just "modules" can be reused. Tools, test data,
designs, plans, environments, and other software items can be reused.
- Above all, recognize that software reuse is not "business as usual." A
commitment to software reuse will require some changes. These changes should be
introduced in an effective manner. Remember that the concept of software reuse
is alien to most technical and managerial personnel.
The above suggestions are not the only ones that need to be considered. I view
them as a "starting point" for future discussions. Finally, to those of you who
would rather see this mailing list used as a forum solely for the discussion of
the syntax and semantics of the Ada language: thank you for your indulgence.