Design Problem Requirements

Design problems give CS 111 students the opportunity to create OS features "from scratch" without any skeleton code found in the directed sections of the labs. Each team will be assigned a design problem from one of the four labs assigned throughout the quarter. Once assigned, students may choose from the suggested design problems for that lab or devise their own feature with the approval of their TA.

Although the ultimate goal would be a working implementation of the feature, this project's deliverable is a 3-6 page design document in which students will:

1. establish a coherent and complete description of the feature's behavior
2. define a sensible implementation strategy

But if you do complete any implementation work, that should also be handed in.

In addition to an implementation strategy and design document, students will also be required to give a 5 minute presentation during an assigned discussion section in which they will explain their design to the class.

• Team chooses which design problem they will complete: in the week after the lab is assigned
• Design problem presentation: in section about 2-3 weeks after the lab is assigned
• Design problem paper and code (if any) due: about 2-3 weeks after lab is assigned

Lab 4 paper and code will be due at the same time as the normal lab.

• Lab 1: presentation 1/28, paper and code 1/31
• Lab 2: presentation 2/11, paper and code 2/14
• Lab 3: presentation 2/25, paper and code 2/28 (tentative)
• Lab 4: presentation 3/11, paper and code 3/11 (tentative)

The design document must clearly expain what the feature does (interface) and how it does it (implementation). At a minimum it must include:

• a complete specification of the feature's behavior

Even if you choose one of the design problems suggested in the lab (as opposed to devising your own), the feature may not be fully specified. Some aspects of the behavior will be left to you as "design decisions". You are responsible for explaining what decisions you made and your reasoning behind it. The design specification is complete if any implementation that satisfies the specification is indistinguishable to the user.

• a well-defined plan for implementation

This should act as a blueprint for a particular implementation of the design described above. Do you break the problem up into modules? What data structures will you use? What tradeoffs did you make by choosing this particular implementation strategy?

• a summary of results

Describe the successes and failures of implementing your design. Did you complete an implementation that satisifies the specification of the feature? What obstacles did you encounter? Was anything easier than expected? What did you learn?

• who did what

How did you divide the work?

It is possible to complete a satisfactory design project without implementing your design. However, at least beginning an implementation will often help clarify the design issues, and for many students it will be easier to do a good job if you begin an implementation. If you do not implement, replace the "summary of results" section with a section on "design tradeoffs and possible implementation issues": What other designs are possible? What might go wrong in an implementation? What features seem hardest to implement?

The document should adhere to the following format:

• Single-spaced, 3-6 pages (no more than 6 pages) with one inch margins
• 11 or 12-point font
• typed or word-processed, not handwritten
• Pictures and diagrams when necessary to explain the design
• Name of students and their student IDs at the top of each page

Your presentation in section is at most 5 minutes long. Other students and the TA will ask questions during and after your presentation. The goal of the presentation is to demonstrate your ability to discuss and clearly present computer science-related technical issues. It should cover, at a high level, the feature requirements; your specification of feature behavior, especially focusing on any interesting parts; your implementation plan; and any challenges you encountered during implementation. One example layout might be like this. (This assumes you use PowerPoint, which is allowed. But you may also use the blackboard, or a combination of the blackboard and a demo.)

• High-level feature definition: explain the design problem you chose, and how existing systems handle this feature. (1 slide)
• Your specification of feature behavior. (2-3 slides, with at least 1 slide of the most interesting details)
• Implementation plan and challenges. (1-2 slides)

Usually it takes about 60-90 seconds to get through a slide. Don't plan a 20-minute talk!

Some guidelines for designing effective presentations are below.

Most students find that good writing is surprisingly important to their careers, no matter what field. So take the writing seriously, as we will. Paul Eggert has collected a useful set of links to resources on writing reports; take a look.

• Angela Laflen's Writing a Report (2001) describes how to write and organize a research report.
• David A. McMurrey's Online Technical Writing: Online Textbook (2006) contains many examples and much discussion of technical writing. For example, it has a chapter on recommendation and feasibility reports that contains several sample reports.
• Simon Peyton Jones's How to write a good research paper (2004) is a brief and pleasant talk about how to write papers.
• Barbara Gross Davis's Helping Students Write Better in All Courses (1993) gives succinct advice about how to teach writing. Invert the advice, and you can learn a lot about how to write.
• Proper citations are a hallmark of any solidly written report. Citation and Style Guides (2006) refers to several style guides; pick a style suitable for your report and use it consistently. Especially see its section "How to cite sources."
• The Cabrillo Tidepool Study's Scientific Report Rubric (1997) is the sort of thing we use when evaluating your report.
• No list of resources would be complete without the classics:
  • The Elements of Style, by William Strunk, Jr. The linked version is to the original text, which was published in 1918. The version in bookstores has been updated several times by E.B. White (author of Charlotte's Web). There is also a new, really fun illustrated version (review).
  • Style: Toward Clarity and Grace, by Joseph M. Williams.
  • For academic writing in particular: A Handbook for Scholars, by Mary-Claire van Leunen. Link

Oral skills are extremely important to polish so please take the time to reherse your 5 minute presentation and check some of these great links to giving technical talks from Paul Eggert.

• Mark D. Hill's Oral Presentation Advice (1997) briefly describes how to give a good talk. It contains a summary of David Patterson's classic How to Give a Bad Talk (1983).
• Judith P. Rhodes et al.'s Scientifically Speaking: Tips for Preparing Scientific Talks and Using Visual Aids (2005) contains advice and observations on preparing and delivering a scientific talk. Its advice on poster presentations is also valuable, though you can skip it if you are not making a poster.
• Jeff Radell wrote a brief online tutorial on effective presentations (1999).
• The Science & Engineering Library has a learning center with equipment with which you can rehearse your presentation. Reserve a time slot by visiting the circulation desk in Boelter 8270.
• Caroline McCullen's Student Presentation Rubric (1997) is the sort of thing we use when evaluating your presentation.
• Simon Peyton Jones's How to give a good research talk (2004) almost makes it look easy and covers the essentials. He's brave enough to point you to a video of himself, giving the talk.