karl@grebyn.com (Karl Nyberg) (03/16/89)
Subject: STARS Breakthrough Conference
Date: Tue, 14 Mar 89 14:34:23 EST
From: Greg Siegert <haven!ajpo.sei.cmu.edu!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.