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...