TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
"Bruce D. Bachus" <[log in to unmask]>
Wed, 6 Nov 1996 08:14:09 -0500
Michael Feldman <[log in to unmask]>
"Bruce D. Bachus" <[log in to unmask]>
text/plain (65 lines)
Lots of good discussions.
I was fortunate in being able to attend the debrief from the distinguished
group who conducted the study.

A few quick observations (excuse the possible redundant comments from

1.  It was stated that Ada is most appropriate for warfighting software.
The problem here is the definition of warfighting software consists of
the obvious realtime s/w and embedded s/w...fine.  Unfortunately, the
domain of warfighting includes command and control, and yes, logistics.
In fact, if we look at the battlefield functional areas in the Army's
field manual (FM 100-5) we note they include maneuver, battle command,
logistics, air defense, fire support, intelligence, mobility and
survivability.  The distinction between warfighting and battlefield
functions is a bit unclear.  And yet, without the distinction, those
attempting to author the implementation guidance will have a non-trivial

2.  It was stated that Ada has an advantage for reliability.  In the
future, there will be less standalone stovepiped IT and more integration.
Somehow the key positives of Ada did not seem as obvious as the acclaimed
benefits of COTS.  Now the good news is that Ada as a language will enter
the ring and when the final bell sounds, its acclaimed advantage of cost
and lessened defects should cause it to be a winner.

3.  The mandate didn't work.  And, the waiver process didn't work.  Now we
have a new term called the Software Engineering Plan Review Process.
This, like our prior mechanisms (mandate and waiver process) look good.
However, we already have in-place review processes.  The language issue is
tough.  Even tougher is implementation.  I question the ability of the
SEPRP to solve the implementation issue as it is (like the waiver
process), a process.  The emergence of architecture review boards is a
means to implement the SEPRP.  For this to succeed, there must *first* be
definitive guidance from the top, from DoD.  If the new guidance has
loopholes as the old one did, they (the loopholes) will quickly surface.
Implementation and guidance must come from the top (DoD) and not risk
interpretation from the various "layers" of review.

4.  15M to be spent on Ada.  This was considered an "on the margin"
expenditure.  I did not hear what the 15M would provide.  It's almost as
though 15M was thrown over the wall to coddle the community.  I applaud
those who came up with this figure.  And to think that after all this,
15M could have made *any* difference in providing warfighting software in
a budget that consists of orders of magnitude more.

Thanks to all who have commented.  We, the Army, are trying to wrestle
with the verbiage in the study and trying to anticipate what DoD will do
so that we can give guidance in our existing architecture documents.

In the meantime, if I'm asked, my response will be that Mr Paige has
directed an unbiased study to evaluate Ada.  The study has been completed
and has been provided to DoD for review.  The outcome will be that DoD
will accept the recommendations or it won't.  After all, the ASDC3I is
the CIO for DoD, and not the NRC.  Mr Paige is in charge of the IT which
supports warfighting and as a prior warfighter with over 3 decades of
warfighting experience, he'll do the right thing!  Hence, one possible
alternative will be for DoD to accept *some* of the recommendations and
reject others.  Existing policy remains in effect....

Bruce Bachus
LTC, Infantry
[rest snipped]