Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnews!military From: budden@manta.nosc.mil (Rex A. Buddenberg) Newsgroups: sci.military Subject: Re: The 2167 development spec Message-ID: <11367@cbnews.ATT.COM> Date: 13 Nov 89 16:11:22 GMT Sender: news@cbnews.ATT.COM Organization: Naval Ocean Systems Center, San Diego Lines: 83 Approved: military@att.att.com 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