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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!igor!rutabaga!jls From: jls@rutabaga.Rational.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: ada-c++ productivity Message-ID: Date: 26 Mar 91 02:32:56 GMT References: <668465900@ <13570@helios.TAMU.EDU> <6514@oasys.dt.navy.mil> Sender: news@Rational.COM List-Id: >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. I agree that this is the theory, but, sadly, much of the 2167/A documentation I've been subjected to over the past several years has been essentially worthless for understanding the documented system. When this happens, the extensive documentation just makes a very expensive doorstop. -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."