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

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

First, to the DoD:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

1. 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.

2. Require that software reusability be an integral part of any technical and managerial training. This should be especially true for Ada-related training.

3. 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.

4. Encourage the use of methodologies and tools which have been demonstrated to enhance the reuse of software.

5. 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.

6. Management must let it be known that it actively encourages the reuse of software.

7. Recognize that more than just "modules" can be reused. Tools, test data, designs, plans, environments, and other software items can be reused.

8. 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.