Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!brutus.cs.uiuc.edu!psuvax1!rutgers!att!cbnews!military
From: aws@itivax.iti.org (Allen W. Sherzer)
Newsgroups: sci.military
Subject: Re: The 2167 development spec
Message-ID: <11430@cbnews.ATT.COM>
Date: 14 Nov 89 23:26:59 GMT
References: <11367@cbnews.ATT.COM>
Sender: military@cbnews.ATT.COM
Organization: Evil Geniuses for a Better Tomorrow
Lines: 50
Approved: military@att.att.com



From: aws@itivax.iti.org (Allen W. Sherzer)

In article <11367@cbnews.ATT.COM> budden@manta.nosc.mil (Rex A. Buddenberg) writes:

  [Good analysis of 2167A deleted]

Although I agree with everything said, I would like to add a few points
from my own experience.

First of all, 

>The second major reason driving 2167A is that it is written for BIG 
>projects -- the million and up lines of source code.  Software increases
>in size linearly and in complexity geometrically.  The truth is well
>known, controlling the effects is not easy, but for modern C3I and weapons
>systems is required.

This is indeed true. A major problem is deciding at what scope to document
the project. The first military software project I ever worked on was a 
small communication computer used to take load off a main computer for a
Navy fire control system. I was given a spec from the systems engineer and
told to go at it. Having never seed a DID and knowing nothing about required
documentation I spent the afternoon writing pseudo-code of the system. It
took me about 3 hours to do. I figured the whole thing would be ~ 200 lines
of code and would take four weeks to get working (including documentation). 
Then I was informed about the documents which needed to be written according
to mil standards. I was given the formats and started to work. The project
went from four weeks to two years in length. For every line of code there
was around three pages of documentation. The project was never finisted.

MORAL: Make sure the scope of your documents if appropriate.

Secondly, if you are working on a project where you want to use 
unconventional approaches in your software engineering (like rapid
prototypeing), don't use 2167. It doesn't work very well.

Finally, you can sometimes use something called 'Contractor Format'. This
will allow you to write the documents any way you want if you can also
provide a cross reference showing a one to one correspondance between
your document and the 2167 DID. That may make your job easier if your
group already has a document standard.

  Allen

----------------------------------------------------------------------------
| Allen W. Sherzer                    |  Is the local cluster the result   |
|  aws@iti.org                        |  of gerrymandering?                |
----------------------------------------------------------------------------