Course Prerequisites: CS 61A, CS 61B, CS 61C, and Math 55.
This
means, in particular, that you know C, Java, and data structures (at
the level
covered in CS 61B/61C), have done some MIPS assembly language
programming,
and that you know about series and products, logarithms, advanced
algebra,
some calculus, and basic probability (means, standard deviations,
etc.). The
TAs will spend a small amount of time reviewing some of the material
you
are less likely to remember. We will assume that you either know the
material
that is supposed to be covered in those courses, or that you are
willing
to learn the material as necessary. We will not spend time in lecture
covering
any of this material. If you are not proficient at Java programming, we
recommend that you take CS
9G, the self-paced Java course "JAVA for Programmers".
Enrollment: All decisions concerning appeals for enrolling in the course are made by a CS departmental committee; the course staff have no say in the matter. There is an appeal form that you can fill out and return to the CS office in 387 Soda.
Grading: Grades will be determined roughly as follows: (Note that the final grade components may change!)
The course will be graded on a curve, with a mean grade of roughly a B, and a median of roughly a B+. Graduate students and reentry students are not included in establishing the curve (to be fairer to undergraduates), but they will receive grades based on where they would fall on the curve. This is EECS department policy for undergradute courses.
We grade on a curve rather than on an absolute scale because it protects students from stressing out if we happen to give an overly hard exam. The downside of grading on a curve is that it tends to lead students to think they are competing against each other; in practice, this is mistaken belief in a class this large. We're told told that in past years, the absolute difference between each half-step grade (between a B+ and an A-, for example), has been roughly 5%, while the largest impact any individual student's performance is likely to have on your grade is less than 0.1%... in other words, well into the noise.
Students often stress about whether they will be penalized because their project may not be as elaborate as that of some other group in the class; again, this is a myth. The project is hard enough without worrying about competing with other project groups. By and large, most students do quite well on the project. The consequence is that the project has less effect than you might think on the curve; only groups that do poorly on the projects will see their grades significantly affected by their project scores.
Any requests for grade changes or regrading must be made within two weeks of when the exam was returned or when the grade for the assignment was first posted.
Exams: There will be two midterm exams and one comprehensive final exam. If you have a conflict, let us know, and we will schedule a makeup for the day before the exam is given to the rest of the class. All exams will be closed book, and will cover material from lecture, sections, the readings, and the project. In particular, you are likely to do poorly on the exams and in the course if you do not do your share of the work on the project.
Project and Sections: The project in this course is to build an operating system for a simulated MIPS-style workstation. The project is the core of this course, and most of what you learn will be from doing the project.
If you plan to do software or hardware development after graduation, you will almost certainly need to know how to work in a large group. Recent CS grads almost all say that the ability to work in large groups was the single most important thing they wished they had learned at Berkeley. Hence, for this project, you will need to form into groups of 4 to 5 people; the assignments will be the same no matter what size group you have. We will not permit anyone to do the project in a group smaller than 4. In order to ensure everyone in the group does their fair share of the work, we will ask each of you to turn in assessments of the relative contributions of your project partners. Many employers do this, by the way, in determining salaries and bonuses.
Enrollment for sections will not be handled through Telebears. Current Telebears enrollment is temporary. Sections will be assigned after you have chosen your groups. Take a look at the Group/Section Registration page for more info. Your entire group must be enrolled (and attend!) the same discussion section; you are not permitted to attend sections in which you are not enrolled. The idea is to provide continuity within each section: to break an anonymous large class into more interactive smaller sub-classes. If you have questions about the lectures or the project, you should try to go to your TA first before asking the other TAs.
The TA for your section will grade all phases of your project. The TAs have been instructed to grade in part on design and implementation style and to be increasingly strict about this as the semester proceeds. In other words, it is not enough to get a working solution; you must implement the solution in a clean way that would simplify making further enhancements. (Several employers in the area have said that many of our graduates don't know how to program well -- it will really benefit you in the long run to work on your software engineering skills.) Although we will attempt to ensure that the grading criteria are applied uniformly, there may be slight variations between sections. However, we believe that any decrease in fairness will be outweighed by the benefit of continuity in the sections in teaching the course material.
For each project phase, you will turn in an initial design document and your TA will meet with your group for an oral presentation of your design at a design review. These reviews serve several purposes:
Late policy: We will use flexible slip dates for the programming assignments. Each student is given an automatic extension of 5 calendar days. You can use the extension on any assignment during the semester (in increments that are rounded up to the nearest integer). For instance, you can hand in one assignment 5 days late, or each of five assignments 1 day late. For project assignments, the slip time will be deducted from each team member's remaining slip time. This should let you schedule due dates around the due dates for other courses.
After you have used up your slip time, any assignment handed in late will be marked off 10% per day. Extensions will not be granted.
Computing Facilities: All students enrolled in the class will be given an instructional account, cs162-??@cory. Account forms will be handed out at the end of the first lecture (if you did not receive an account form, see your TA). Most of the Unix systems should have cross-mounted file systems, so you should actually be able to work on most of the EECS Unix systems. Your final run for each assignment must be done under that account, and must run on x86 Solaris machines.
Cheating: It's OK to ask someone about the concepts, algorithms, or approaches needed to do the project assignments, I encourage you to do so; both giving and taking advice will help you to learn. However, what you turn in must be your own, or for projects, your group's own work; copying other people's code, solution sets, or from any other sources is strictly prohibited. The project assignments must be the work of the students turning them in. We will punish transgressors severely.
The fine print: