Grading for CSC 2/456

Tentative plans call for five programming assignments, covering

[Skip to links at bottom of page]

In a departure from recent practice, this year's assignments will not employ a pedagogical OS; we'll mostly be writing real programs on top of Solaris.

Assignments may be done in teams of 1, 2, or 3 students. You may change teams between assignments if you like. The amount of work to be performed will not depend on the number of team members. All students on a team are expected to ``pull their weight''; all will get the same grade.

Expect the workload to be heavy. The assignments are time consuming, and will take all of the time alloted. Don't expect to succeed if you start late.

Most assignments will have two due dates. The first will be a trivial ``pre-assignment'' whose purpose is to force you to start thinking about things and register your team membership with the TA. The second will be the main due date. The pre-assignments will count for 10% of your final grade. The main assignments will be graded primarily on quality of design and secondarily on correctness.

There will also be a midterm exam and a final. As in most 200/400 level courses, extra work will be required of graduate students, in the form of extra exam questions and extra requirements for programming assignments. Several past exams (some with suggested answers) are available on-line as study aids.

Any borderline grades will be decided on the basis of class participation and extra credit. All students are expected to take part in classroom discussions.

No Late Assignments

It is my strict policy not to accept late assignments. Exceptions will be made only under the most dire of circumstances. Note, however, that I am extremely generous with partial credit, so turn in what you have.

Every semester I have students who let a due date pass. When I ask them what happened they say ``Oh, I didn't finish, so I didn't turn anything in.'' Then I have to give them a zero. If they had turned in even some reasonable preliminary thoughts on how they might have done the assignment -- without a single line of code -- they often could have received as much as 40% of the total points. This can mean the difference between letter grades at the end of the semester.

So if it looks like you aren't going to make a due date, don't keep debugging down to the wire. Stop an hour early and take the time to organize what you have and put together a write-up that presents it in the best possible light. Your transcript will love you for it.

Academic Honesty

Student conduct in CSC 2/456 is governed by the College Academic Honesty Policy and the Undergraduate Laboratory Policies of the Computer Science Department. The following are additional details specific to CSC 2/456.

Exams in CSC 2/456 must be strictly individual work.

Collaboration on homework and programs is encouraged at the level of ideas. Feel free to ask each other questions, brainstorm on algorithms, or work together at a blackboard. Be careful, however, about copying the actual code for programming assignments, or copying the wording for written assignments. This sort of collaboration at the level of artifacts is permitted if explicitly acknowledged, but unless you're on the same team, it's usually self-defeating. Specifically, you will get zero points for any portion of an artifact that your or your teammates did not transform from concept into substance by yourselves. If you neglect to label, clearly and prominently, any code or writing that isn't your own, that's academic dishonesty.

The principle behind the collaboration rule is simple: I want you to learn as much as possible. I don't care if you learn from me or from each other. The goal of artifacts (of exams and of programs and other written assignments) is simply to demonstrate what you have learned. So I'm happy to have you share ideas, but if you want your own points you have to internalize the ideas and them craft them into an artifact by yourself.

(Note that this principle puts a low premium on originality. For the purposes of this one course I don't care if you come up with an idea yourself or get it from somebody else, so long as you demonstrate that you understand it.)

It is conceivable that your team might choose to copy code from someone else, e.g. to get the satisfaction of seeing your project work when it wouldn't otherwise. Keep in mind, though, that you won't get any points for the copied portion.

For purposes of this class, academic dishonesty is defined as

I work under the assumption that students are honest. I will not go looking for exceptions. If I discover one, however, I will come down on it very hard. I helped write the College policy, and I'll enforce it aggressively.

General Guidelines for all Assignments

Prior to each main due date, the TA will post instructions in the newsgroup explaining how to turn in your code. This will be done electronically using an automated script. Before running the script, be sure to create a file named README in your assignment directory. In this file, include

  1. A listing of the output of your compiler on your test data, and on any official test data provided by the TA. You may find the script program useful for capturing the output; read the man page. Watch the newsgroup for any word of official test data.
  2. A presentation, in prose, of whatever information you think is necessary for a typical user to run your program and for a software maintainer (or grader!) to understand (and evaluate) your code. Some of this information may be included in the original assignment handout; you only have to fill in the parts we didn't provide for you already. Information for the prospective user includes details on calling conventions, input and output data formats, limitations, bugs, and special features. Explain both the negative aspects of your program (limitations, known bugs) and the positive aspects (extensions, special features). If you don't include the former, we will assume you didn't realize the limitations were there. If you don't include the latter, you may not get extra credit. For the person who has to understand the insides of your code, you may need to describe your choice of modularization (abstractions), data structures, and algorithms. Be sure to explain anything you did that is likely to be different from what other students may have done, and justify any design decisions for which the rationale isn't immediately clear.

If you don't manage to complete the assignment on time, turn in what you have. We will be very generous with partial credit. If you don't turn in anything by the due date, you will get a zero.

Your final grade for each assignment will be based primarily on quality of design, and secondarily on whether the code actually works. You should aim for code that is complete, correct, and readable. Completeness means that the code implements everything that was required in the assignment. Correctness means not only producing the right output given normal, expected inputs, but also getting some sort of reasonable response to unexpected inputs. We may occasionally provide you with some input test data (watch the newsgroup), but most of the time you will be expected to generate your own. The quality of this test data will affect the correctness portion of your grade. Try to exercise the program thoroughly. A readable implementation has characteristics such as appropriate abstractions, data structures, algorithms, and variable names; declarations for all constants; and a judicious number of helpful comments. Instead of thinking of programming as explaining to the computer what you want it to do, think of programming as explaining to the TA what you want the computer to do.

You are encouraged to share ideas with fellow students, but only one team can get credit for actual code (see the rules for academic honesty). Those of you on the csug machines should have received a copy of the laboratory policy when you got your account. Be sure to look this over and stick to the rules.

Links to Specific Assignments

Past Exams

Back to the course home page

Last Change: 1 April 2000 / Michael Scott's email address