You are expected to understand this. CS 111 Operating Systems Principles, Fall 2007
You are here: CS111: [[2007fall: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 is to have a working implementation of the feature, considerable emphasis will be placed on 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

In addition to an implementation strategy and design document, students will also be required to give a 5-10 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 paper and code due: about 2-3 weeks after lab is assigned
  • Design problem presentation: in section about 2-3 weeks after the lab is assigned
Lab Team tells TA which design problem Normal lab due Paper and code due Presentation in section
Lab 1 October 12 October 19 October 26 October 26
Lab 2 October 26 November 5 November 12 November 9
Lab 3 November 13 November 21 November 28 November 30
Lab 4 November 28 December 12 December 12 December 7

Note that Lab 4 paper and code are due at the same time as the normal lab. All due dates are on Friday except for some of the dates when you need to inform the TA of your design problem choice.

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 10 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-2 slides)
  • Your specification of feature behavior. (3-4 slides, with at least 1 slide of the most interesting details)
  • Implementation plan. (1 slide)
  • Implementation 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-10 minute presentation and check some of these great links to giving technical talks from Paul Eggert.

 
2007fall/design.txt · Last modified: 2007/11/19 12:50 (external edit)
 
Recent changes RSS feed Driven by DokuWiki