From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!ADA20.ISI.EDU!EBERARD
From: EBERARD@ADA20.ISI.EDU.UUCP
Newsgroups: comp.lang.ada
Subject: DoD and Reusability - Part 4
Message-ID: <8703241137.AA03138@ucbvax.Berkeley.EDU>
Date: Tue, 24-Mar-87 05:33:02 EST
Article-I.D.: ucbvax.8703241137.AA03138
Posted: Tue Mar 24 05:33:02 1987
Date-Received: Thu, 26-Mar-87 01:15:16 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


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:

   1. Current and future software standards and policies should be
      explicitly examined for their impact on software reusability.
      THIS IS A *TECHNICAL* ITEM. 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.

				-- Ed Berard
				   (301) 695-6960

(r) Ada is a registered trademark of the U.S. Government (AJPO)
-------