EBERARD@ADA20.ISI.EDU.UUCP (03/24/87)
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)
-------creedy@cca.UUCP (03/25/87)
In article <8703241137.AA03138@ucbvax.Berkeley.EDU> Ed Berard writes: > > . . . > > 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. . . . Absolutely!! > 2. A "Software Reusability Plan" (SRP) should be a required part of > any contractor's software proposal. . . . > > 3. Software contractors should also be required to produce a short > post-project assessment of the impact of sofware resue on their > project. These assessments should be placed in the public domain > whenever possible. I believe (for personal philosophical reasons) that software reuse is the only way that we can solve the crisis in software development. Therefore, I agree with the concept here. But ... (FLAME ON) I have seen a large number of programs out of the DoD where an almost infinite variety of plans, documents and reviews were required of the contractor. A number of these projects failed because they took too long, were too costly, or failed to adequately address the requirements. In my personal experience, the failure probability of the project could be correlated positively to the number of documents, reviews, etc. that were called for. I.e. the more documents, etc. the more likely the project was to fail. I believe that the primary cause for this phenomenon is that the DoD (and the government in general) does not take plans, documents, reviews, etc. seriously. I have rarely seen the resources committed by the government to adequately review, for example, the detailed design of the software as a part of a CDR (Critical Design Review). In many of these cases, the reviews are a "dog and pony shows" that allow the government program manager to impress his peers and supervisors with how well the program is progressing. In this environment, criticism of the program is discouraged. Further, the contractor usually knows that a real review will not be held. This allows the contractor to do work he knows to be inadequate on the basis that he needs to make his milestones (in order to get a good review from HIS supervisor) and can make up the work later. Unfortunately, coding (or whatever) comes after the review and once the government has approved the design, the contractor MUST start coding, leaving no time to return to complete the design. Finally, (and worst of all) in some cases the contractor doesn't know better and assumes that because he has checked all the boxes and passed the review, that he has in fact done an acceptable job. Those projects that I have seen that have been successful have tended to either: (a) have the government take their role as reviewers of the project seriously. This requires a willingness (and budget) on the part of the government program management to commit the resources necessary to do an adequate review, and to understand that if contractor's work is inadequate, that the program will have to be delayed and/or replanned, but that it is better to do that now than deal with the inevitable problems and delays that will arise later. Or, (b) have the government trust the contractor, save contract funds by holding minimal reviews and requiring minimal documentation and make sure that everyone understands that the contractor will be at fault if the program fails. (FLAME OFF) Which is all to say ... Before proposing yet another document that must be produced by government software contractors, I believe you should consider whether this document will be treated by the government (and therefore the contractors) as another box of paper that must be provided by the contractor and will be filed away and forgotten or whether it will be taken seriously by the government's project management offices. I offer the proposal that government procurement offices require that program management offices provide (and make use of) resources and a budget for adequately reviewing and critiquing the documents that are produced by the contractors. I personally believe that this would provide more benefits in terms of the success of software projects than all the additional ignored documentation that one might require the contractor to produce. >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. Ditto. Chris Reedy Computer Corporation of America Disclaimer: My opinions are my own and not those of my employer.