Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Panel Discussion on the Strategic Defense Initiative at the 8th
International Conference on Software Engineering
One of the more interesting sessions at the 8th International
Conference on Software Engineering was a discussion of software for
the Strategic Defense Initiative (SDI). The moderator was Manny
Lehman and the panelists were Fred Brooks, David Parnas, and Alan
Perlis. The discussion was originally intended to be a debate, but
Fred Brooks was not willing to participate in a debate because he had
not yet reached a resolution of the issues. (I understand that
volunteers for the position of opposing Parnas in a debate on SDI
were hard to find. Dr. Brooks deserves credit for being willing to
engage in a public exploration of touchy issues about which he feels
unsettled in concert with a strongly opinionated colleague in an
effort for both audience and panel to learn more.)
The discussion started with a presentation by Parnas of the technical
reasons why reliable SDI software cannot be built. (Readers of this
newsletter will be familiar with many of the arguments put forth by
Parnas. A complete discussion in hard-copy is available from him at
the University of Victoria, Department of Computer Science, P.O. Box
1700, Victoria, B.C., Canada.)
Brooks responded with reasons why he thought we could build such a
system. His major point was that we have built similar systems in
the past. He identified the Apollo missions software as an example,
suggesting that we start with such a system and incrementally build
from it towards an SDI system, using what's learned along the way.
Perlis then added a few comments, explaining why SDI software would
be more complex than existing software and why it is of the hardest
type of software to build. His argument was that the SDI system
represents a moving target in terms of requirements and design.
Following some further discussion among the panelists the floor was
opened to technical questions from the audience.
The major place in which Parnas and Brooks seemed to disagree was
whether or not similar systems have been built. Brooks tried to use
the Apollo and Space Shuttle as examples. Parnas's point was that in
those systems everything can be predicted in advance. In an
anti-missile system, the number, shape, and trajectories of launched
missiles can't be predicted. In addition, the system must
distinguish decoys from real warheads. Finally, the defense system
itself will be under attack. As a result, realistic tests and
simulations of operating conditions for such a system could not be
conducted.
All the discussants seemed to agree that an SDI system could not be
built error-free, and that it would not be completely reliable.
Nonetheless, there were advocates of building it on such grounds as
that it would only be needed for a short time, and could be turned
off the rest of the time, or that we now place our trust in systems
that are also untested and probably unreliable.
In summary, there were no good responses to any of the questions that
Dave Parnas raised. Nonetheless, there were arguments put forth for
the construction of an SDI system on the grounds that it need not be
completely reliable.
David Weiss
Wang Institute of Graduate Studies
RISKS-1.15 was ready to go out Wednesday night. Murphy hit in spades. The SRI MICOM switch for dial-up access was unavailable for two days, and is still down. An alternative route might have been available through the only system that receives dial-ups directly from a split-speed modem, but that system went down for five hours. Several other more circuitous alternative routes all ran into broken gateway, which resulted from a power failure Tuesday night. It would not have helped to drive back to SRI, because the SRI-CSLA (which kept running through all this) was out of net contact as a result of a gateway problem. All of the gurus were invisible. If you ever get this issue, you will know that things have improved. Peter
Please report problems with the web pages to the maintainer