military@cbnews.ATT.COM (William B. Thacker) (11/11/89)
From: uunet!sagpd1!jharkins (Jim Harkins) You've all been having fun talking about the interesting stuff like planes, ships, guns, etc. How about some of the real-life military stuff for a while. Like, say, the 2167 software development spec. Are there any books out there that will help develop software under this spec? Even better would be a book that explains techniques for developing the 29.3 pounds of paper that goes with each page of source code. I'm reading the spec itself trying to figure out what exactly they want, but I'm not sure my interpretation matches what they are trying to say. Can't ask for help here cause this is the company's first project under 2167 so we're all in the same boat. Those of you with experience with 2167, do you think it helps create better software? From what I see so far its purpose is more CYA as opposed to software quality. jim jharkins@sagpd1 "This subparagraph shall be numbered 3.3.W.2.X.2 (beginning with 3.3.1.2.1.2). When not provided in a separate DBDD, this subparagraph shall identify and state the purpose of the data that originate in LLCSC X and are not used by any other architectural elements of the CSCI."
budden@manta.nosc.mil (Rex A. Buddenberg) (11/14/89)
From: budden@manta.nosc.mil (Rex A. Buddenberg) Bcc: DoD-Std-2167A -- software development. While I'm not intimately familiar with 2167A (the A is the current version, don't use the original -- major changes), I've bumped up against it a few times. While one of the purposes is CYA (who in military procurement can afford not to these days?), the primary purpose (bastardizations aside) is to make sure you get software that is documented and maintainable. I've had responsibility for software that has been out there in operational use for 15 [!!] years, and we've learned a lot about software production and costs of ownership in the interim. With the faults of 2167A, the alternatives are definitely not very attractive when looking at the software from the far end of the support/logistics pipe. Once you strip off the turgid bureaucratics (a procedure now thankfully automatable by CASE tools), the basics of 2167A software production are the same as you will find in a modern software engineering textbook (careful use of the term 'modern' -- software engineering is a discipline no more than a couple decades old at most -- it's pretty volatile). Essentially, top-down design by the numbers, with full documentation at each stage of the development. Take a look at Barry Boehm's waterfall model -- it maps to 2167A in excruciating detail. So what does 2167A get you? A proper answer to that must look at some very expensive hardware/software productions prior to software engineering standards. One of the legendary ones is the A-6 flight control computer. 8 bit machine with a few k of core, if memory serves me right. Doing critical flight control and weapons stores functions -- clinical real-time application. Over time, the application program (there was no operating system per se) accrued a lot of patches and undocumented changes -- such that producing a new run-time version required going back to an early base and reapplying all the patches, in the correct order. Required weeks in the support lab. Because core was at a premium, folks were using instructions as data and other tricks that allow a blivet fit but obviate any real maintenance. One of the bigger relishes of DoD software maintainers was to hook one of the academics into agreeing to reverse engineer the A-6 program so it could be engineered right. Talk about cost and schedule overruns... One of the reasons for the excruciating documentation is that one must assume (usually indeed true) that the software maintainer will not have been around during the initial production, so he has to come up to speed on somebody else's code. Try it sometime -- I've a hard enough time reading my own code, somebody else's hash is a real zoo. 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. Thirdly, you are dealing with systems where the costs of error are very high. Software drives things like the Phalanx gun -- how'd you like to be a friendly approaching a cruiser and have the software in his close-in weapon hiccup? Closer to home, We've four embedded computers in the Loran control system which is what the guy up fron is going to be using to fly the airplane. How'd you feel if the software produced an undetected nav system error while pilot is making an approach? 2167A won't knock errors out by itself, but it is designed to allow straightforward testing and quick tracking down of bugs. On training. I've seen a few courses advertised that purport to teach 2167A techniques. Check the military labs -- I've seen training blurbs from those sources on occasion although can't recall ans specifics at the moment. Also, anybody who's serious about 2167A had better also be serious about CASE -- there are tools that do a lot of the gut work for you. Finally, 2167A by the book is a lot of work, and expense. The standard is supposed to be tailorable, depending on the application that you are contracting for. Rex Buddenberg
aws@itivax.iti.org (Allen W. Sherzer) (11/15/89)
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? | ----------------------------------------------------------------------------
henry@zoo.toronto.edu (Henry Spencer) (11/17/89)
From: henry@zoo.toronto.edu (Henry Spencer) >From: budden@manta.nosc.mil (Rex A. Buddenberg) >...the basics of 2167A software production >are the same as you will find in a modern software engineering >textbook... Essentially, top-down design by the numbers, >with full documentation at each stage of the development... In other words, a model of software development that is increasingly felt to be obsolete: the notion that you can pre-plan the software in such detail that it will automatically work and be optimal. There is a large and growing faction that considers this concept unworkable self-deception. Mistakes and redesign are inevitable, and recognition of this leads to vastly superior results. But if you've got to rework 500 pages of documentation first, well, maybe the original code is "good enough for government work" after all. Documentation by the ton does not guarantee good software. (Especially when the documentation is probably written hastily after the fact, like flowcharts always were.) What it guarantees is software that is too rigid to change... and change is inevitable. Henry Spencer at U of Toronto Zoology uunet!attcan!utzoo!henry henry@zoo.toronto.edu