At 02:31 PM 6/10/1999 -0400, Roger Racine wrote:
>>And your work product really gives you a lot of information about the
>>design approach it embodies.  I find that significant design problems
>>-- the kind of thing that can make you start over -- surface a lot
>>earlier in Ada.  And, you aren't as tempted to "paper over" a problem
>>with a kludge that will grow as the system grows.
>
>Why?  This would be an excellent argument (if true :-) )!  Note that I am
>not accusing you of telling a lie, just that it would be easier to convice
>others if there were constructs of the language that could be pointed to
>that A) did not take any longer to use; and B) found design problems
>quickly.  Note also that (as others have pointed out) a small sample of
>experience does not make a good argument.

   I'll just address this one point.  Way back in 1984, at officially the
first SIGAda meeting on Cape Cod, everyone, including Jean Sammet who had
been one of the most vocal opponents, decided "The best PDL for Ada is
Ada."  Not just that, but that the PDL should be compiled with an Ada
compiler. (Note that this doesn't say that you shouldn't use notation
embedded in comments, like Anna or Byron.)

   Why? Because by then we all had enough experience with Ada to know that
the major design flaws and oversights showed up when you wrote the package
specifications.  So people who know what they are doing with Ada have the
main program (one or two pages plus block comments) and all major package
specifications needed for the first build complete and compilable.  One of
the advantages of Ada 95, is that it makes the mapping to PDR and CDR easy:

        PDR ==> Main program and all root library units.
        CDR ==> Remaining (child) package specs plus key algorithms.

   Some people still insist on misreading 2167A to say that you shouldn't
write any compilable code before PDR.  The right answer to such misguided
individuals  is to say that you are using the appropriate design language
for Ada.  (Or point them to someone who understands 2167A and MIL-STD-SDS.)

   If you do that, you end up without bushels of unnecessary documentation
at PDR (no "C" specs, and if you tailor right, "B" specs for software only
at CDR, if ever).  What you do end up with is a clear exposition of the
design at PDR.  If the customer doesn't understand this design, which
should be accompanied by comments mapping timing and other requirements to
units, often to packages, then the serious development problems are outside
the control of the developer.
If the customer does comprehend the design, then you put the specs under
version control, with an easy way for the project engineer to sign off on
(and report) changes to the specs, then there is no way to have the type of
major miscommunication that you mention.  (The real problem, of course, is
that you have to get--in government procurement terms--these "software
deliveries" spelled out in the RFP.  What we have found best--if you can
get it in the RFP and contract--is to have read access to the CM files.)

    Oh, and one last thing.  You can still get ambushed by additional
requirements.  If the design planned for them, all well and good.  If they
weren't planned for, the cost doesn't depend on how much time and effort
was before PDR, it just depends on how much was spent before the
requirement was identified.  Our experience has been that with Ada such
requirements become visible earlier in time, if they are surfaced by the
design process.  But if they are only dependent on the calendar, you will
have spent more of the project money before they show up, so you have to be
very proactive in identifying them.  (What I am talking about are
additional requirements generated from lessons learned such as in the Gulf
War, or in the Balkans.  I expect new requirements on, for example, Air
Tasking Order systems, as a result of the intelligence problems recently.
Some of these requirements will be unanticipated and have nothing to do
with the timing of development reviews.)

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...