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=1.1 required=5.0 tests=BAYES_40,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!cbatt!ucbvax!MITRE-BEDFORD.ARPA!munck From: munck@MITRE-BEDFORD.ARPA.UUCP Newsgroups: comp.lang.ada Subject: Re: DoD and Reusability - The Movie Message-ID: <12261.544291270@mbunix> Date: Wed, 1-Apr-87 11:01:10 EST Article-I.D.: mbunix.12261.544291270 Posted: Wed Apr 1 11:01:10 1987 Date-Received: Sat, 4-Apr-87 05:58:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet List-Id: It makes me crazy to see proposals for DoD reuse of software that use terms like "standards and policies," "reusability plan," or "encourage." It is the case that program officers are MOTIVATED to keep the project on schedule and within budget during their tour of duty. Other things, like the quality of the product and future costs to maintain it are secondary. (Note, I'm talking about the motivation of these people by the system, not necessarily their own predilections; I've seen many of them fight the system to be allowed to make the product better, at some cost to their own careers.) If quality and life-cycle costs are secondary, the possibility of reuse of the software on some later project is far down in the noise. The results of a program office's doing a good job on reusability on one project doesn't show up until the next project is nearly finished. Given current development times, that's a half-dozen years or so; no way are those original people, long re-assigned, promoted, or retired, going to be rewarded. Please don't tell me that they would have been rewarded at the time; that runs counter to the DoD's general policy of "don't make waves" and institutional inability to make judgments about quality. They know that they can get the same result by just going through the motions, publishing the policies and having the reviews on schedule. It's my opinion that the DoD will be unable to take advantage of software reuse without significant institutional changes in the way it acquires software. An idea like reuse has to be "owned" by someone, has to be some person or group's major mission and goal. Moreover, that someone has to have direct responsibility for acquiring the systems AND have the money necessary. We can't continue to "tack on" reusability the way we impose minority hiring on highway construction, attempting to do two jobs with the same bucks and doing neither well. My proposal is that software acquisition should be done on an application-area basis instead of the current project basis. For example, "avionics" might be a suitable application area. There would be an Avionics Software Office set up with the responsibility of acquiring the basic avionics software for all services for the next fifty years. They would analyze the field of avionics, isolate functions that are basic to it and the parameterization needed to make packages tailorable to fit most circumstances, and procure the packages. They would then supply software to particular projects, customizing their standard packages where necessary by expanding the parameter- ization to include the particular circumstances. A project might get software from several Software Offices and fit it together like an Erector Set. The software office personnel would be motivated to save money and shorten schedules on projects by doing a good job of software reuse. It's a big change from the current way of doing business; I'm not sure the bureaucracy is capable of such change. -- Bob Munck