You are expected to understand this. CS 111 Operating Systems Principles, Winter 2011
You are here: CS111: [[design]]

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.

Design Problem Timeline

  • 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

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

Presentation Guidelines

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.

Writing Resources

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.

Presentation Resources

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.

design.txt · Last modified: 2011/03/05 15:53 by kohler
Recent changes RSS feed Driven by DokuWiki