Contents:
| Instructor | David Notkin CSE 542 (office) 206.685.3798 (office phone) notkin@cs (email) |
Office hours
|
| TAs | Matt Kay CSE 002 (office hours) mjskay@cs (email) |
Office hours
|
| Nick Brekhus CSE 002 (office hours) gu13@cs (email) |
Office hours
|
Mail sent to cse331-staff@cs.washington.edu goes to the instructor and the TAs. There are a set of Catalyst GoPost forums for the class, which should be used actively.
It's usually better to ask a question after you've tried to solve it. Sometimes you'll solve it on your own and, in any case, you can provide more information about the problem and what you've already tried.
Here are some examples of questions and good ways to go about getting answers.
All members of the class are encouraged to help one another on the forums. If someone asks a question to which you know the answer, then answer it. Helpful, genial replies are appreciated and will contribute to the class participation part of your grade. If you ask a question by email or in the forum and later discover the answer, don't forget to let everybody know; this will help make everybody more effective.
Do the reading before the date on which it is listed; this is especially important for lectures and sections, which will assume you've done this. You are responsible for material in all handouts, including unassigned ones. If something does not seem relevant to you yet, then at least skim it and make a note to come back to it later. You may find unassigned reading assignments from the books useful anyway, but they are not required.
The texts for the class are:
Some other excellent books you should consider for your reference library on software engineering are:
There will be two 50-minute exams (that is: a midterm and a final exam). The final will be held at the university assigned time: Wednesday, December 15, 2010,830-1020. The midterm will, very likely, be held on Wednesday November 10, 2010, during class, with an optional midterm review session during class on Monday November 8, during class. (Notkin will be out of town at a week-long workshop, conference, and meeting that week.) The staff will run optional exam review sessions. These sessions will focus entirely on questions that the students ask about the material. Thus it's probably better to study before the review session, so you can clarify anything you're unsure of.
We will try hard to standardize grading policies across the staff, but if needed we will make adjustments.
CSE 331 grades each student in the class independently of one another: we do not, for example, limit the number of student who can get a 4.0 or a 2.0. At the same time, there is no pre-determined absolute percentage score (e.g., 90%) that earns a 4.0 or a 3.5 or a 2.0 or anything other grade. The staff will set break points like these points after the quarter is over, when discuss each student, individually. We will ask questions like "If I were founding a startup, would I hire this student?", and "Did this student master the material?", and many others. Then, we will set the break points, using resources such as the English descriptions in the Sample UW Grading Guidelines. We will then translate the scores into your final grade for the course.
Slack days. We will allow you two slack days during the quarter. You can use these both on one assignment, or one on each of two different assignments. A "day" means 24 hours from the original due date/time. You must notify the staff, by the original due date, that you are using your slack credit. You cannot use slack time for PS0 or returnins. (And no, you cannot split up a slack day and submit each of three problem sets 8 hours late.)
If we make assignments to pairs or other small groups, we'll revisit these basics in that context.
An important exception to the prohibition against viewing another student work is that you are permitted to assist another student with tool-related problems (such as difficulty using Eclipse or SVN), even if such assistance results in incidental viewing of snippets of code. But, regardless, the work on the assignments has to be your own, of course.
I'm loathe to try to define a full list of things you cannot do; it sometimes tempts people to try to find loopholes. So, for example, consider the second point above: don't represent somebody else's work as your own. This includes things like viewing and/or using any substantive material or solutions from similar assignments this term or previous terms at UW or elsewhere, including anywhere on the Internet, transcribing solutions from any other source, etc.
My policy is intended to convey the spirit of the law, fully understanding that the letter of the law may not cover everything that someone may think of.
Here are one or two examples of what is okay. It is permissible to discuss testing strategies with another student, but you may not view another student's testing code. Or you and other students can sketch out an algorithm or design together, but you must destroy any written materials from your meeting, watch TV, and then and work from your understanding (that is, from your memory).
Collaboration does not, of course, allow you to cut corners. Computing is at the core of almost all societal systems, and its discrete nature makes it especially unforgiving. Software has been responsible for death and damage, so taking your coursework seriously is essential. We expect you to show high ethical standards in CSE 331, and in the rest of your career.
You are free to use conceptual material that you obtain from textbooks, the Internet, and other sources. For instance, Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein is an excellent resource for looking up algorithms. Again, giving credit where credit is due, if you use such material, give explicit credit clearly in your documentation.
We will use technological and other means to detect cheating.
You will submit the implementation part of your problem sets electronically, as described in the Problem Set Submission document.
To receive credit for correctness, all code you turn in must compile and run when called as specified in the assignment. We will not adjust your output formats or otherwise debug your programs to try to get them to run. You will be given example input and output files, and often full test suites as well, so you can test your own programs before submitting them.
Explicitly indicate, in your documentation, any shortcomings of your program. If your code does not compile, or if certain functionality is missing, and your documentation does not clearly and prominently indicate as such, then you will lose points for the omissions (as well as for the defect itself).
Diagrams which you turn in must be readable. We will not be grading on artistic merit. However, if it is not easy to understand, then you have not successfully conveyed the relevant information, and you will be graded accordingly.
The problem sets generally provide you with a detailed specification for the behavior of the code that you will write. Your solution should conform precisely to these specifications. This means, for example, that your program should not write anything to either standard out or standard error other than precisely what is specified. You should verify that the spelling, phrasing, or punctuation conforms to the specification; automated tests may otherwise indicate that your program is at fault. The output of your program should be deterministic: it should not vary from run to run when presented with the same input.
In addition to providing specifications for the behavior of your program, we will often provide specifications for certain classes. For such classes you are free to add private fields, methods, and constructors, but unless otherwise specified you may not add public, protected, or default-access (package) fields, methods, or constructors.
The test suites that you include with your program should run in under a minute when testing your implementation.
After problem sets 1-4 has been graded, you'll have to submit a corrected version of the code (even if you received complete correctness credit for the original submission). The resubmitted programs are graded on correctness only, and there is no partial credit. You don't have to expand documentation, fix style problems, etc. (although doing so might simplify the task of correcting your program!). The regrade is worth 1/4 of the total grade for each assignment.
The returnin system runs all of the staff tests, but the returnin report only contains the first test that fails along with a partial stack trace. On script-based tests, the returnin report will only show the difference between the expected output and the output produced by your program; it will not include the test input. The goal is to encourage you to use reasoning and testing to find errors. More restrictions on returnin are likely to be imposed. One is that we may run returnin periodically, rather than on demand; that is, you'll have to plan the work rather than expect instantaneous (and often last-minute) response. Another is that we may limit the number of times you can run returnin (say, to three), to reduce your ability to debug one test at a time.
See the Problem Set Submission document for details about the procedure for turning in (and re-turning in) a problem set.
We will return graded assignments to you within one week from when they are due. In the case of late turnins, we will try to return the graded assignment within one week from when you submit the assignment.
To complete assignments as efficiently as possible, we recommend that you: