Project Grading Policy for CS170, Fall 1999

Delays and extensions: We will use flexible slip dates for the projects. Every group is given an automatic extension of four calendar days, which you can use on any project during the quarter, in any increment, as long as the total amount of lateness does not add to more than 4 days. For instance, you can hand in one project 4 days late or four projects one day late. This should let you schedule due dates around the due dates for other courses. Once you have used up your slip time, any project handed in late will be marked off 10% per day. We believe that this is a fairly flexible policy. There will no extensions granted beyond this.

Demos: you are expected to demonstrate a detailed, working understanding of the code. As part of the demos, we will ask you to find and explain the specific parts of code that implement given functionality. We expect you to find these pieces of code quickly without having to shuffle through or read large parts of your code. In addition, we expect you to explain the general approach you took without referring to the code itself. You must demonstrate good working knowledge of the code to get credit. Please note that any partner can be asked about any part of the code. The point of having two-person groups is that two people can often figure out things and write code faster than one. But, if each partner understands and learns from only half the project, the point of giving the entire project is lost. There is a reason why each part of the project have been included. To summarize, you may hack only half the project but you are expected to understand all of it.

Each demo should be scheduled within one week of the project due date -- usually in the office hours of one of the TAs. It is your responsibility to schedule a demo.

Grading: projects will be graded as follows: 20% basic concepts, 20% structure and 60% correctness. We have structured the grading this way to encourage you to understand the basic concepts and to think through your solution before you start coding. Part of being a good engineer is coming up with simple designs and easy to understand code. Particularly for large software systems, like operating systems, which often live for a long long time. Some details:

Basic concepts: can you explain the basic data structures and how they work with each other? Does the code reflect an understanding of the basic concepts even if it may contain bugs?
Structure: is the code reasonably well-structured and documented? Is it easy to follow what is happening? Does the README file clearly explain the design and implementation?
Correctness: does the code work for a suite of test programs? Are there any obvious bugs?

We expect anyone who has made a reasonable effort on the project to do well on the code knowledge part of the evaluation. We expect anyone with correct code to do well on the basic concepts section. After all, it is rather difficult to write working code if you do not understand the basic concepts. A question you may be asking: could we place less emphasis on delivering a fully debugged version of the program? We believe that being able to apply the concepts you learn is crucial in this course, and we intend the grading standards to reflect this belief. For this courses, being able to apply concepts means being able to deliver working code. We recognize, however, that developing Nachos code may be difficult, and we will try to give reasonable partial credit for demonstrating an understanding of the concepts and an ability to write code that reflects that understanding even if the code is not completely correct. To do well in the class, however, your code must work and be free of conceptual bugs.