From: EBERARD@ADA20.ISI.EDU.UUCP
Subject: DoD and Reusability - Part 4
Date: Tue, 24-Mar-87 05:33:02 EST [thread overview]
Date: Tue Mar 24 05:33:02 1987
Message-ID: <8703241137.AA03138@ucbvax.Berkeley.EDU> (raw)
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)
-------
next reply other threads:[~1987-03-24 10:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1987-03-24 10:33 EBERARD [this message]
1987-03-25 19:23 ` DoD and Reusability - Part 4 creedy
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox