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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!grebyn.com!karl From: karl@grebyn.com (Karl Nyberg) Newsgroups: comp.lang.ada Subject: More on the STARS Breakthrough Conference Message-ID: <8903152211.AA11027@grebyn.com> Date: 15 Mar 89 22:11:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Grebyn Corporation List-Id: Subject: STARS Breakthrough Conference Date: Tue, 14 Mar 89 14:34:23 EST From: Greg Siegert SPECIAL NOTICE SUBJECT: STARS BREAKTHROUGH CONFERENCE -- March 20, 1989 The IBM Corporation in cooperation with the Defense Advanced Research Projects Agency and the Electronic Systems Division of Air Force Systems Command will sponsor a one-day conference at the Atlanta Airport Marriott, 4711 Best Road, Atlanta, GA 30337 starting at 9:00 am on March 20, 1989. Software Engineering Technology, Inc., an IBM subcontractor, will host the conference and will provide technical briefings that identify STARS research areas with "breakthrough" opportunities for dramatic improvement in the quality and affordability of military software. The conference is unclassified and will allow free and open discussion of the research opportunities. Those wishing to register for the conference should contact Terri Collins or Arnie Beckhardt, Software Engineering Technology, Inc., Vero Beach, FL 32960, (407) 569-6644. Room reservations should be made directly with the Marriott, (407) 766-7900. This is not a solicitation for proposals. It is anticipated that the Electronic Systems Division (AFSC), Deputy for Contracting (PKG-2), Attention: Jon R. Welton (PCO), 617 377- 6682, Hanscom Air Force Base, MA 01731-5000 will in the near future authorize the IBM Corporation to release one or more solicitations for subcontract proposals in support of the STARS FY 1989 Breakthrough Initiatives. The IBM Corporation is under contract to ESD as a STARS prime contractor and in that capacity is responsible for administering the first set of STARS breakthrough initiatives. Questions regarding anticipated future subcontracting opportunities should be addressed to W. David Ceely, Jr., STARS IBM Program Manager, IBM Bldg. 182/3H96, 18100 Fredrick Pike, Gaithersburg, MD 20879, telephone (301) 240-6968. The Breakthrough Conference will be chaired by Dr. Harlan D. Mills, Information Systems Institute, supported by a panel of leading software engineering practitioners. The conference is designed to stimulate pre-proposal thinking leading to innovative "breakthrough initiatives" from the software research community in areas such as: A. SOFTWARE FIRST LIFE CYCLE: The life cycle embraces a spectrum of issues ranging from concept strategy to working system, from procurement award to delivered product, from specification to zero-defect code. The Life Cycle models a software engineering approach that must function within the existing, evolving, business- government complex. STARS' goal is an order-of-magnitude gain in productivity with an emphasis on certifiable quality and a way of working whereby competent professionals can meet such standards. B. ADA ENVIRONMENT: The quality and interoperability of tools across Ada environments and different hardware platforms will greatly enhance portability of Ada products. The extension of these tools to a distributed development environment will promote these environments well beyond the year 2000. Efficient implementation of object management policies allows for incremental change and evolution of the resulting environment. C. SOFTWARE QUALITY AND RELIABILITY: The success of STARS depends on defining a quality-oriented process which will result in very high levels of system reliability and safety. Strategies which support a shift in thinking to zero-defect development must be incorporated. D. PROTOTYPING AND INCREMENTAL DEVELOPMENT: Paradigms for prototyping and incremental development, when fully developed and adapted, show great promise in the context of STARS. Strategies and tools must be specified which will allow full benefit of these approaches in an Ada-based environment. E. REUSE METHODS: A new discipline is needed to support pervasive reuse of requirements, design specifications, documentation and code in the development of software systems. Reuse methods must support both the production and consumption of reusable components. F. REPOSITORY OPERATIONS: The development of a STARS repository requires research in the areas of component representation, classification, and organization. Effective user interfaces for browsing, selection, retrieval and dissemination of reusable components are important. Certification techniques for assuring the quality of components are needed. TECHICAL BACKGROUND FOR THE STARS BREAKTHROUGH CONFERENCE The Software Technology for Adaptable, Reliable Systems (STARS) program is the Defense Department's advanced technology research program to achieve dramatic improvements in software quality and to mitigate runaway software costs especially for embedded and mission critical military applications. The fundamental result of the STARS efforts is the development and demonstration of a software development and maintenance technology that will improve the quality and reduce the cost of military applications software. The STARS new way of doing software engineering is based on adaptability and reliability made possible by using the concepts and philosophy of Ada. The program uses the software- first approach to software engineering and is founded on the expectation that the concepts and philosophy of Ada provide a new basis for treatment of software engineering in the large. The ability of the Department of Defense and the US industrial base to deal with such software systems will determine the capability and cost of many future defense systems. Many of the important technical capabilities desired by the STARS program are at the state of the art and require additional research and development. The achievement of "breakthroughs" involves the creation and exploitation of new concepts. No single organization, however competent, can have a monopoly on new ideas. It is necessary to pull in new ideas and methods from the widest possible community of industry and academia to propose "breakthroughs" for the STARS program, then select and subcontract those investigations which may remove technical obstacles to development. This initiative, therefore, represents a search for new ideas and their rapid exploration for the specific needs of the STARS program and should be clearly distinguished from an academic or government basic research program. STARS supports the "software-first" approach for new systems acquisition, ie., the process whereby software is developed to be machine independent, before computer hardware choices are made. The resulting software is used to determine the system architecture and hardware requirements. The computer hardware is selected and the software is applied to the operational system hardware late in the development life cycle. This approach has fundamental implications for the software technology, the life-cycle process and the contracting process. The full benefits of the "software-first" approach may not be achieved when applied to systems with existing operational hardware. In the technology area STARS will use Ada. Ada will help and is certainly the language of choice, but Ada by itself is not sufficient to achieve machine independence. The way we do software engineering must change to provide truly machine independent applications source code and the resulting cost benefits of a reusable software technology. The purpose of STARS is to invent and demonstrate a new way of doing software engineering to support such applications. STARS is pioneering the contracting practice for the "software- first" approach. There will be significant differences from normal experience. For example, STARS must invent solutions in many technical areas and in ways that are different from normal practice. To reduce the risk in large system development, the STARS process will break large problems down into smaller tasks that can be better specified and costed. STARS will foster the necessary life-cycle and contracting practice by deliberate, planned experimentation based upon the results of a continuing software engineering research leadership role for industry and academia. In day to day operations, it is not easy to remember that software engineering is only a human generation old, at which age in civil engineering the right triangle was yet to be discovered. With the heuristic methods necessary in a new subject, software products are expected to contain errors at delivery. But it is time to recognize this assumption of necessary errors in software as an aspect of immaturity in an engineering discipline only a human generation old. Unfortunately, software development is too often regarded as a mature clerical industry in detailed computer coding in which errors are necessary because of human fallibility. Such errors are indeed necessary without rigorous engineering discipline. In a recent paper, "No Silver Bullet - Essence and Accidents of Software Engineering," Information Processing 86, JH Kugler (ed)., Elsevier Science Publishers BV (North-Holland), 1986. Frederick P. Brooks explains why treatment of the software acquisition process is critical to the development of software systems-in-the-large: "The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Therefore the most important function that the software builder does for his client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. He usually does not know what questions must be answered and he almost never has thought of the problem in the detail that must be specified. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach. The secret is that software is grown, not built. Much of present-day software acquisition procedures rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. Hence they cannot be fixed without fundamental revision, one which provides for iterative development and specification of prototypes and products." In a paper,("Top-Down Programming in Large Systems," in Debugging Techniques in Large Systems, R. Ruskin, ed., Prentice- Hall, 1971) some years ago Dr. Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below. In the first paper cited above, Dr. Brooks went on to say: "I have seen the most dramatic results since I began using this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there. The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build." Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition. In the second paper cited above, Mills stated: "I would go a step further and assert that it is impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before having built and tried some versions of the product he is specifying." Therefore, one of the most promising of the current technological efforts --one which attacks the essence, not the accidents of the software problem --is the development of approaches and tools for rapid prototyping of systems as part of the iterative specification of requirements.