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 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b2116ed565f01bb0,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-28 09:29:03 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!eff!news.kei.com!world!srctran From: srctran@world.std.com (Gregory Aharonian) Subject: Paige's How To Get An Automatic Ada Waiver memo Message-ID: Organization: The World Public Access UNIX, Brookline, MA Date: Fri, 28 Oct 1994 14:22:13 GMT Date: 1994-10-28T14:22:13+00:00 List-Id: Sometime ago DoD Secretary Perry issued a policy memo encouraging the use of COTS products in defense systems (as opposed to MIL-SPEC equipment). As Ada is a MIL-SPEC, the few in the DoD who actually pay attention to the Ada Mandate questioned whether Perry's memo would undermine the Ada Mandate. To qualify this issue, Ass. Sec. Paige and Und. Sec. Longuemare issued another memo attempting to clarify this issue and try to show that Perry's memo is not in conflict with the Ada Mandate. Strangely, their joint memo of August 26 not only does not clarify the issue, but provides a perfect mechanism for getting an automatic waiver for the Ada Mandate. Their memo does reflect how out of touch senior Defense officials are with what is going on in the software world. In their memo, Paige and Longuemare write: "It is DoD policy to use commercial off the shelf (COTS) software whenever it meets our requirements. However, when COTS software is not available to satisfy requirements and the DoD must develop unique software to meet its needs, that software must be written in Ada in accordance with 3405.1 and 5000.2" This is a meaningless sentence because no where is software COTS defined, opening up a loophole wide enough to float an aircraft carrier group through. Most likely, when these guys think of COTS, they are thinking about packages like 1-2-3, Wordperfect, DBASE, etc, the very narrow definition of COTS. However, think of the average Defense application, which will have software requirements for user interfaces, graphics, database, communications, networking, signal/image processing, and real time control. For all of these requirements, there are ample numbers of COTS source code/object code libraries available in C/C++ and Visual Basic. So if one defines COTS software in a wider sense as to include COTS source code libraries, then the effect of Paige and Longuemare's memo is to encourage the use of these non-Ada COTS source code libraries as a substantial part of Defense programming project. But at least these types of COTS libraries are fairly well documented and tested. Not so if one interprets their memo in the loosest sense. There are a few CDROM publishers who scoop up tons of source code from the Internet and make it available cheaply (Prime Time Freeware for example, which sells an Ada CDROM). In a loose sense, a CDROM is COTS software, since it is commercially available off the shelf and shrinkwrapped. But even I would argue that this type of stuff doesn't belong anywhere near DoD systems. But because Paige and Longuemare don't define COTS, DoD programmers and contractors are free to choose whatever definition they want without any fear for retribution. This paragraph then does nothing to clarify Perry's memo. In fact, I could start a business where contractors could write code for whatever they want and send it to me. I would add some marginal value, shrink wrap some diskettes, put it on my shelf, and sell it back to the contractor, who could then validly argue that the software is COTS. However, all of these non-Ada COTS libraries still need "glue", which for the most part has to be newly written code that you would expect to fall under 3405.1 and 5000.2 and be in Ada. However, another part of their memo provides another loophole wide enough to push the Pentagon building through. I quote: "Use of other programming languages can be considered if proposed by a contractor as part of his best practices since waivers to the use of Ada can be granted, where cost-effective, in accordance with procedures established in the policy referenced above. However, such proposals require strong justification to prove that the overall life-cycle cost will be less than the use of Ada will provide". Again, another meaningless requirement, in this case, because of the lack of a definition for proving cost-effectiveness. Given the almost non-existent number of independently verified measures of Ada's cost-effectiveness (as opposed to scores of ancedotal reports), one could justify the waiver on the same grounds by citing ancedotal evidence supporting their language choice. But for most contractors, that is too risky of an argument. Instead, contractors can turn to the leading Ada vendor for a court-proof valid justification. Remember that contractors need this justification to get out of writing the "glue" software in Ada. However, given the large size of the COTS libraries they will be "gluing", the amount of "glue" code will not be large, usually under 100,000 lines of code, if that. But thanks to the language-schizo folks at Rational, a ready waiver justification is on hand. For if you read Rational's literature and technical reports, they repeatedly argue that with Rational's tools that you can program as cost effectively over the life cycle in C++ as you can in Ada (especially if you supplement Rational's C++ tools with Alsys/Telesoft's C++ GUI tool, Tartan's C++ signal/image processing libraries, and Intermetrics C/C++ realtime tools). Thus all you have to do is cite this collective tool set to argue for your waiver. Since the DoD would publicly have to dispute the non-Ada assertions of its leading Ada suppliers (extremely unlikely since only unkind words are said about Greg), then this waiver argument will fly through unopposed. At that point, you can then argue the equivalence of CASE tools to not use the above companies' products and use whatever tools are on hand. As a butress for this argument, you can include TRW's comment from the Ada/C++ Business yes-man study that by the mid-1990's, C++ would be as cost effective as Ada. And if that fails, call in whatever favors you have at ARPA, and ask them to explain to your contractor officer why Ada is a lousy language. Even better is that some companies like TI(IEF) and Oracle(CDE) have graphical environments where you "paint" much of the glue code, structured diagrams that their tools either execute or convert to code. One could argue in the broad sense that these "paintings" aren't source code and therefore not subject to 3405.1 and 5000.2. In summary, because Paige's and Longuemare's memo do not explicitly define "COTS" and "cost-effective", they provide loopholes that make it extremely easy to get an Ada waiver, for those who bother to worry about doing so. Mostly likely these two senior officials are unaware of much of what is happening in the software industry (especially if the only trade shows they go to are Tri-Ada), and don't realize that the lack of definitions for these two terms makes their memo a blueprint for obtaining automatic Ada waivers. So the issue of Perry's memo is still unresolved, providing no guidance to those who care about Ada, and providing yet another negotiating tools for those who don't care about Ada. As long as the DoD refuses to encourage open critical discussion about these issues, this confusion will continue to undermine Ada acceptance in the DoD. As taxpayers, we should all demand better memos from such senior officials. In a related example of senior confusion, in the October 1994 Crosstalk (where Paige and Longuemare's memo was published), there is another rah-rah Ada article from AF Dep.Ass.Sec Mosemann on how great Ada is, where he once again pledges his undying love for Ada. Unfortunately, it conflicts with his earlier memo on Air Force use of AI where he didn't mention Ada once, it conflicts with his refusal to comment on why the Air Force's KBSA project is allowed to continue being mostly non-Ada, and most ironic, in this very same issue of Crosstalk there is an article from Air Force people at Rome Lab (home of KBSA) on Rapid Prototyping in which the example used in the article, a program for space debris, is written in C. I guess the DoD has two Air Forces. Don't any of you guys talk to each other? But hey, have fun singing songs at Tri-Ada. Greg Aharonian