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