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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5b321a2e2f342353
X-Google-Attributes: gid103376,public
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: Ada 95 & MIL-STD 498
Date: 1997/01/27
Message-ID: <5civhj$o9t@top.mitre.org>#1/1
X-Deja-AN: 212661528
references: <32EA8546.6AED@ix.netcom.com>
organization: The MITRE Corporation, Bedford Mass.
newsgroups: comp.lang.ada
Date: 1997-01-27T00:00:00+00:00
List-Id: <comp.lang.ada>


Responding to the question how to document under Mil Std 498:

If the contract really demands 498 documentation, then try tailoring 498
(498 shows you how) to eliminate most of the documents, and only
write the documents needed to maintain the system. Do not produce
incorrect documents. Instead of traceability matrices and cross
references, deliver a tool that produces these automatically from the
spec and the code. Instead of elaborate test plans, deliver an automated
test for each unit and for each spec requirement. Instead of design
documents give the entire data flow (including all aliasing), the
preconditions and postconditions of all units, the invariants for all
loops, the timings and sizings for all parallel structures (tasks,
etc.). The most important documentation for software is the full source
code including all library and run-time code used. The most important
advice above is not to produce incorrect documents. Never deliver
paper copies of these documents, only on-line documents in simple
text format or hyperlinked text. Do not pretty them up with word
processors, but a little html is acceptible (only to put in the links). 
Use a consistent format for paragraph numbers and page numbers so
other programs can parse the text of your documents. Finally,
subcontract out the documentation to someone else.