Project Grading Policy for CS170, Spring 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. There will no extension 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 groups is that two people can often figure out things and write code faster than one. There is a reason why each of the parts of the project have been included. If each partner understands and learns from only half the project, the point of giving the entire project is lost. 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? There is more to correctness than just running the test programs that we hand out. If the code contains obvious bugs that our test programs happen not to exercise, the program is still incorrect. There will be several test files for each assignment; we will give you some of these files in advance.

We expect anyone who 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 ask is if we should place less emphasis on delivering a fully debugged version of the program. We believe that being able to apply the concepts you learn is very important, and we intend the grading standards to emphasize the ability to apply concepts. In this case applying concepts means being able to deliver working code. We recognize, however, that developing Nachos code may be difficult, and we try to give fairly generous 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 should work and be free of large conceptual bugs.