At 11:29 AM 6/9/1999 -0400, Roger Racine wrote:

>I have an interesting anti-Ada argument that I am having difficulty
>refuting.  Any help?

>At Project A's design review, the customer sees a major problem in the
>basic design.  There were interpretation problems with the requirements.
>The customer says they need the problem fixed.  The developer says: "That
>will cost $10M.  We have to update thousands of pages of documentation, go
>through all those walkthroughs again, etc."

    The other alternative is that the developer says he'll put his people
right on it and have an estimate after lunch.  When later that day he is
asked for the estimate, he asks if they would like to see a demo of the
modified system.

    I've been through both.  In the worst case of your scenario, the
customer decided just before formal testing that they wanted to two systems
to use the same algorithms (for one relatively small part of the system,
scheduled for Phase II) as used by another system, and wanted to get the
same answers.  Of course, the contract for the other system had just been
awarded, they were committed to use VAXes, and were using VAX specific
floating-point formats for their calculations.  (The customer also decided
not to deploy the system without this capability.)

    The reasons for wanting the same results werevery valid, and the
algorithms were significantly faster and more accurate on the VAX using the
non-IEEE format.  So from one point of view, the decision made sense.
However, having postphoned those requirements to phase II was a very
expensive decision in terms of schedule time, hardware investment, and, oh
yes, the cost of porting the software to VAXen.

    As for the second scenario, the change was that when the customer tried
out the final (menu-driven) system, they realized that it would
considerably speed things up if every screen had a return to top button as
well as an "up" button that returned to the previous screen.  Since the
design of screens used inheritance, the global change was just that, and
the biggest effort required was retaking (electronically) several dozen
screen shots for the documentation.
But the documentation process was a part the software design and was highly
automated--a wonderful experiment, and I wish more projects would do it.
As I said the biggest effert was redoing the screen shots as that process
was not automated.  The effort to integrate the documentation with the
software design probably paid for itself during development, but the reason
for doing it was so that the documentation could be reissued with new every
release at low cost.  Of course, you all know what happened--since the
system was WELL written and in Ada, as I remember it there was only one
further release, when one of the external interfaces changed.

     To get back to the original topic, I have seen the second type of
situation much more often than the first when the system is built in Ada.
But actually, the scenario I have seen most is that the developers ask some
very difficult to answer questions during system design:

     "How likely is it that a future version of this system will be
required to support the XXXXX interface?"

     "Will future versions just be Unix-based, or will you want it to run
on Windows boxes?"

     "If this improbable situation occurs, what do you want the system to do?"

     And so on.  In fact I've gotten to the point where I see the lack of
such questions as a red flag.  But if the questions are asked and answered,
most potential major software changes have been anticipated by the design
and will not affect the overall system architecture.

                                        Robert I. Eachus

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