Re: 4GL code in a deliverable (was: ARIANE-5 Failure)

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Robert Dewar wrote:
> 
> Ken said
> 
> "
> Would this "truth" also exist if the device used to generate the Ada code
> from the database was a human being, rather than a machine? It seems to
> me the consequence of this interpretation of Ada policy is that all requirements
> and design artifacts must be generated without the use of tools, else an
> Ada waiver is required!"
> 
> nonsense, no one is saying that! What is being said is that the critical
> point is what level the code will be maintained at. If the code is to be
> maintained at the Ada source level, then it matters not a whit how it
> was developed, by humans, clever tools, or friendly martians.
> 
> If on the other hand, the maintenance is to be done on the "original" source
> code (which may of course be in the form of a database and not a text in the
> normal sense -- that makes no difference), then indeed it is important to
> be sure that this source code is written in an appropritae language, which
> is properly supported, preferably standardized, and preferably avoids
> the danger of single sourced tools.
> 
> Ken, do you really disagree with this? If so, I am surprised, and would
> appreciate you making the source of your disagreement clear!

I do not disagree that this makes sense, and that in general (never mind the 4GL
issue), that a contracting agency should ask for both the implementation of the
software, and also the data/documentation/tools associated with that software, if
the contracting agency intends to provide post-deployment support (directly or
through a third party). Such a request should be written into the contract, and in
fact, such requirements are part of many programs.

However, you raised a much narrower issue. If a code generator is used to generate
Ada source code (specifically, a code generator whose inputs are a graphical 
representation of the algorithms and interfaces a la MatrixX), does such an approach 
violate the DoD Ada policy, and therefore require a _waiver_? My reading of DoD 
5000.2-R and DoDD 3405.1 indicates that if Ada source code is used in the process of 
creating an application, then it's an Ada application, independent of the process used 
to maintain that application. The only change introduced in 5000.2 is that, if the 
Government has _no_ interest in what maintenance process is chosen, then Ada is _not_ 
required.

If someone can quote something from 5000.2, 3405.1, or a service policy that states 
conditions under which a software application is built from "only" Ada source code as 
part of the process, but still requires an Ada waiver, I would be interested in seeing 
this analysis. You might argue that words should be added to these directives, but in 
their current form, I think they bear out my position.

As to whether they _should_ have words about requiring Ada waivers for code 
generators, I'm ambivalent. As I said before, I agree that a system maintained at a 
"4GL" level should continue to be maintained at that level. (I also think that 
requirements databases should continue to be maintained during maintenance, for that 
matter). However, requiring extra paperwork to use innovative approaches to reduce the 
cost of generating Ada source code seems counter-productive, particularly since (a) 
the maintenance site may choose to maintain the software differently from the 
developing site, and (b) even automatically-generating Ada code can still accrue many 
of the benefits of the Ada policy, such as a common implementation notation, fewer 
tools, etc.

Note that this discussion points out a well-known (at least, I _thought_ it was a 
well-known) flaw in the Ada policy as written. Just requiring software to be written 
in Ada does not, by itself, cause fundamental improvements in depot costs. Other 
issues, such as the number of different tools required, the number of documentation 
and data formats/conventions used, etc. also have large effects. Ada policy may 
indirectly improve some of these other factors, but it has to be coupled with other 
initiatives (e.g. electronic data exchange standards) to provide large-scale returns.

-- 
LMTAS - "Our Brand Means Quality"