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=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!mimsy!oasys!dtoa1!depriest From: depriest@dtoa1.dt.navy.mil (Depriest) Newsgroups: comp.lang.ada Subject: Re: ada-c++ productivity Message-ID: <6514@oasys.dt.navy.mil> Date: 21 Mar 91 18:50:04 GMT References: <668465900@ <13570@helios.TAMU.EDU> Sender: news@oasys.dt.navy.mil Reply-To: depriest@dtoa1.dt.navy.mil (Mike DePriest) Organization: Naval Aviation Depot, Jacksonville, FL List-Id: In article <13570@helios.TAMU.EDU> garys@cs.tamu.edu (Gary W Smith) writes: > I do feel, however, that there is a certain amount of waste in the > process. For the most part, the defense dept./GD feel that 2167A is > a concrete rule that must be followed. What I want to know is where > has it been shown that a document-driven waterfall model is the *best* > process to follow in the design of software. The main benefit that I see in 2167-type documentation does not lie within the design/build phase but in the post-deployment software support environment. The Navy's thrust is for complete organic software maintenance capability for life of type. Software support responsibility typically transitions after first deployment, which is several _years_ after the software Critical Design Review. It's likely that the software engineers who inherit the code at transition will not be the same folks who had the review/approval authority at CDR. The extensive 2167 documentation will help close the familiarity gap. -Mike DePriest | I had to lay off my -Naval Aviation Depot Jacksonville | disclaimer after Dick -depriest@dtoa1.dt.navy.mil | Cheney cancelled A-12.