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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC 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!pyrnj!mirror!cca!creedy From: creedy@cca.UUCP Newsgroups: comp.lang.ada Subject: Re: DoD and Reusability - Part 4 Message-ID: <14295@cca.CCA.COM> Date: Wed, 25-Mar-87 14:23:26 EST Article-I.D.: cca.14295 Posted: Wed Mar 25 14:23:26 1987 Date-Received: Fri, 27-Mar-87 06:04:32 EST References: <8703241137.AA03138@ucbvax.Berkeley.EDU> Reply-To: creedy@CCA.UUCP (Christopher Reedy) Distribution: world Organization: Computer Corp. of America, Cambridge, MA List-Id: 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.