> ... > Unfortunately some folks will read the report an say that Ada is > inappropriate for development of financial or logistical applications. > I believe this is not the intent of the report and these people > have incorrectly interpreted the recommendations. If this is indeed > the case then I think the report has done a disservice. We recommended that Ada be considered for any custom 3GL development. However, the best choice of custom development technology may depend on what commercial technology the financial or logistical application is based. Remember, for better or worse, the DoD is strongly committed to capitalizing on commercial investment in domain areas where that makes sense. The committee felt that in the high-assurance, real-time domain, Ada already leads the way, and using Ada had compelling business and techical advantages for the DoD. However in other domains, where the commercial investment outside the DoD dwarfs the DoD's own investments, we felt that the business case for using Ada was not as clear cut, and the use of Ada should not be considered a prerequisite in the choice of contractor and development approach. The point has been made that logistics, and even financial systems, can be critical to the success of a DoD mission. The committee certainly agrees with the importance of these domains. However, "importance" did not necessarily equate with "needing an Ada mandate." The committee felt that in the logistics and financial systems domain, use of commercially-based networking, database, and graphical user interface components (among others) was inevitable, and could in fact produce a higher quality product on a shorter schedule than a full custom DoD-unique solution. Given the heavy use of commercially-based components, we did not believe that using Ada just for the "glue" was always the right tradeoff. A commercial contractor with a good "glue factory" for integrating such systems might well do a higher quality, more cost-effective job if allowed to use the tools of their own choice, which might or might not be Ada. When looking at a cost/benefit analysis, it is always easiest to see the benefits of a favored solution, and the costs of a disfavored solution. However, any sort of mandate incurs costs, in addition to potential benefits. In the high-assurance/real-time area, the committee felt that the cost/benefit analysis for an Ada mandate was clearly in favor of the mandate, whereas in other domains, the cost/benefit analysis was not as clear. In particular, the committee concluded that there were not as many overriding DoD-wide benefits to enforcing a homogeneous 3GL approach in domains where solutions were in any case expected to be based on a heterogeneous set of 4GLs and COTS components (with 3GL glue). In these domains, the committee felt that it was much more important to establish some kind of Architectural Review process to make sure that consistency, reuse, and "product-line" thinking was used in designing and building such systems of systems. As of today, most DoD systems involving high-assurance and/or real-time are already written in Ada, and most DoD systems in domains such as logistics or financial systems are not written in Ada. The committee did not see any compelling arguments for pushing the Ada mandate heavily into the logistics or financial systems domain, particularly given the general DoD move toward capitalizing on commercial investments. Conversely, the committee felt that Ada has proven to be an excellent 3GL for the creation of the high-assurance, real-time systems in the DoD. Vigorously promoting the continued use of Ada in this domain makes excellent business sense, particularly if the current unsatisfactory "waiver" process is folded into a more encompassing Software Engineering/Architecture Review process, and the annual AJPO-directed investment in Ada is beefed up from its current $3Million-and-dropping to a steady $15Million per year. Ada is a general purpose language, and as such, can be used productively and effectively in any domain. However, for the purposes of mandated use, the committee felt that only in DoD-dominated domains did the DoD accrue sufficient DoD-wide benefit to justify focusing on a single 3GL. In other domains, picking the best set of COTS components and tools, and the best integration contractor, and the best product-line architecture, deserved more attention than did mandating use of a particular 3GL. > -Brian Nettleton > Thomson Software Products -Tucker Taft [log in to unmask]