|6.033 - Computer System Engineering||Handout 2 - February 3, 1998|
Each week you can expect to find an assignment like this one on the 6.033 home page on the Web, telling you what you should read over the course of the following week. Occasionally we will be organized enough to predict the readings a few days beyond the next Tuesday. Numbered readings, such as "reading #2," refer to materials in the packet you pick up from the EECS Instrument Room (38-501).
Each week you are expected to complete a reading report. The reading report is a short (one page) written report due at the beginning of every Tuesday recitation. The specific topic to be addressed in the report will be given on the previous week's assignment sheet. In recitation you should be preparedto talk about the whole paper, not just the particular point of the writing assignment.
Read Saltzer, Chapter 1 (reading #3), and begin reading the paper by Simon, "The Architecture of Complexity" (reading #4).
Finish reading Simon, "The Architecture of Complexity" (reading #4). Simon discusses the power of hierarchy using an astonishing variety of examples from many fields. As a personal exercise, after reading the paper, you may want to identify two examples of the use of hierarchy in Project Athena, and understand how hierarchy provided significant leverage or advantage.
In addition, read Gabriel's paper (reading #2). This is a lightweight paper, but makes a thought- provoking point. In general, we will have at most one heavy-duty technical paper per recitation, sometimes accompanied by an easy-to-read paper with up-to-date information, a thought-provoking point, an issue important to society, or high entertainment value.
This lecture is provided by the staff of the Writing Program, and is intended to help you do a better job on weekly one-page reports. In preparation for this lecture, read Gopen and Swan, "The Science of Scientific Writing" (reading #5).
Read Saltzer, Chapter 2 (reading #6).
Read the Leveson paper (reading #7) and write a one-page reading report that addresses the question on "The passing of time with critical computer systems":
The Therac incidents took place between 1985-1987. Since then many changes have taken place. For example:
- User friendly GUIs have replaced dumb terminals.
- Better debugging tools and QA strategies exist.
- Government regulations have improved.
- Well defined libraries facilitate code reuse.
Now, 10 years later, even more life critical systems are interfaced with computers. If the Therac-25 were developed today, do you think it might be possible for such a disaster to still occur? Discuss the fundamental causes that plagued the Therac-25 and are still relevant today as well as new challenges that have come about with the passing of time.
Leveson's paper on-line: http://ei.cs.vt.edu:80/~cs3604/lib/Therac_25/Therac_1.html
Check out the 1997 6.033 web pages for examples of good writing on one-page reading reports. Also, please check the 6.033 FAQ for formatting instructions.
After reading Leveson's paper you may be flabbergasted by how badly the Therac-25 systems were designed. The next reading (#8, Lampson's "Hints for computer system design") has a number of suggestions that often lead to better systems. If you have time and energy left, browse through this thoughtful paper. You might want to ask yourself which hints the designers of Therac-25 violated. Don't worry if you do not fully understand this paper yet (or if you only have time to skim it); it will be assigned again at the end of the term.
|Go to 6.033 Home Page||Questions or Comments: |