From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.ada:2738 comp.sw.components:310 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ucsd!helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird!jcardow From: jcardow@blackbird.afit.af.mil (James E. Cardow) Newsgroups: comp.lang.ada,comp.sw.components Subject: Re: Ada 9X objectives Message-ID: <1381@blackbird.afit.af.mil> Date: 10 Oct 89 03:26:12 GMT References: <1373@blackbird.afit.af.mil> <16176@vail.ICO.ISC.COM> Organization: Air Force Institute of Technology; WPAFB, OH List-Id: rcd@ico.ISC.COM (Dick Dunn) writes: >> ...Consider the ten to twenty year development cycle for large projects... >If you have a ten-year development cycle for a software project, you're >going to be producing obsolete software! You can't help it. Ten years is >just too long for anything tied to computers--the technology moves too >fast. >You've got to get software up and working, and performing at least some of >the needed functions *soon*. You also need it to be adaptable, so that it >can evolve as needs and technology change. I must admit that my comments were made with only my own experience in mine, that being large DOD sponsored projects that had developments spanning two to three computer generations. However, that is the primary Ada environment. In the military software support world we are for the most part just entering the support for JOVIAL systems. Having been responsible for "selling" Ada to the people attempting to prepare for "new" software, I'm convinced that injecting new technology especially evolving technology may very well be a cure more painful than the disease. Consider the problem in a real context. System software in the +100,000 lines of code, with supporting software at a 4:1 ratio. Add to that simulator software that must function exactly like the real thing. Now add unique hardware, especially processors. If the system were stagnant and the budget available the conversion to a new language would be simple (simpler?). But reality says the money for change is small, and the user demand for improvements is large. The changes come in modification of 10 percent of a unit here, 5 percent there. The only real opportunity is when major systems are effected, but that is rare. >What I'm getting at is that I think we're trying to address the wrong >problem. Rather than trying to solve "How do we deal with long development >cycles?" we should be solving "How do we shorten the development cycles?" >-- In the years I have spent chasing DoD software I have always worried about how to get it delivered closer to the expected date, the idea of shorter never occured to me. But, I'm changing roles now to teach software engineering and would greatly love to discuss ways to shorten the development cycle, or ways to inject new technology into old systems. If you have ideas on the subject within the context of large, complex systems or know of any work in these areas let me know. As a side note, Ada can be added to older systems. It takes convincing people that the benefits over the long run are worth the effort.