Contents:
Note: The CSE 331 staff provides a lot of information on the website. Please don't be overwhelmed. This is intended to help you, and to save you time. The material is organized by type, is cross-referenced, and is linked from the calendar when you first need it. You can also search it; for example, add site:http://courses.cs.washington.edu/courses/cse331/13sp/ to the search terms of a Google search. Finally, you can always ask the course staff for help; we welcome your questions!
Important: All students must run student-setup early in the quarter (details are forthcoming). This sets up your directory so that the staff can distribute assignments to you. If you do not do this on time, then you may be delayed in receiving your assignments.
If you wish to take the course but are not registered (you are on the overload list or wait list for the course), then please contact the lecturer on the first day of the quarter. If you delay, you may not be able to add the class (and even if it's possible, late adds create extra work for the staff). Thanks!
Readings are listed on the calendar.
Please complete any assigned reading before the date on which it
is listed.
The lecture or section will assume that you have read the material. If
you have questions, ask the staff or forum ahead of time, or ask in class.
A reading quiz is generally due at 2am that day. Some people find
it convenient to read ahead and do a week's worth of reading quizzes over
the weekend, and others prefer to do the reading the day before the
lecture. It may be less confusing to access the reading quizzes from the
calendar rather than directly from Catalyst.
You are responsible for all handouts on the website, including ones that are not listed on any specific date. 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, but they are not required.
Three books are required:
Some other excellent books you should consider for your reference library on software engineering are:
Aren't books obsolete in the days of the Internet and widely-available programming advice? No. A good book is a well-written, clear, coherent, and comprehensive introduction to the subject material. The reason to pay for a book is for its writing and editing.
The Internet, by comparison, can be extremely useful in helping you understand a specific error message or programming problem, and I encourage you to use it for that. The right Internet site can also give you a high-level idea of a particular concept you are unfamiliar with. But, in the main, freely-available material gives only a fractured and partial view of the conceptual material — and the concepts are much more important than low-level programming details.
Everyone has been burned by overpaying for a bad book. I don't think that's the case for the required books. I own two copies of each the required books (except Horstmann), so I can keep it on my bookshelf both at home and at work. I refer to them often. I think it's well worth your while to have them on your bookshelf: you will learn much from them and will find them useful far into the future.
Compared to the value you will get from them — and to the cost of tuition and the value of your time — the books are not all that expensive. The textbooks are available on reserve at Odegaard library.
We will distribute electronic copies of the lecture slides. The slides augment but cannot replace your own notetaking during lecture and your reading of the textbooks.
Please attend the section that the registrar has assigned you, to keep the sections balanced.
There will be two one-hour exams (that is: a midterm and a final exam); see the class schedule. We provide old exams, which you may find helpful when reviewing, but remember that material covered varies from quarter to quarter.
During the optional exam review sessions, the staff will not present material or give a review of the course so far. Rather, they will answer questions that students ask. Therefore, you should study before the exam review and use it to clarify anything you're unsure of.
When grading, the staff will use a common rubric to ensure consistency. We reserve the right to normalize grades across graders to account for remaining disparities.
CSE 331 grades each student in the class independently: we do not, for example, limit the number of students who can get a 4.0 or a 2.0. Your grade depends on you, and it does not depend on other students. If a student drops, the rest of the students' grades are not affected.
At the same time, there is no pre-determined score (e.g., 90% of all possible points) that earns a 4.0 or a 3.5 or a 2.0 or any other grade. Rather, at the end of the quarter the staff discusses each student individually. To determine the final grade, the staff relies on the English descriptions in the Sample UW Grading Guidelines, and the staff asks itself questions like “Did this student master the material?” and “If I were founding a startup, would I hire this student?” Because there is no fixed mapping between percentage scores and GPA, the staff will periodically give you an estimate of your grade to date.
The absolute number of points that you earn should not discourage you. Getting a grade of less than 90% does not mean you won't get an A, and getting a grade of 90% does not mean you will get an A. In particular, the average score on an exam is generally around 65%, but this score often translates to a B+. This low average score is by design, so that the standard deviation of student grades is large. If the standard deviation is small, then any one mistake is significant because a loss of a few points could change your grade from an A to a B or a B to a C. If the standard deviation is large, then no one little mistake has a significant impact on your grade, and your grade is a fairer measure of your understanding. Thus, having a large standard deviation (and a low average percentage) on each assignment or exam is the fairest approach for students.
Late days. We will allow you four late days during the quarter. You can use no more than two late days per assignment. A “day” means 24 hours from the original due date/time. Before the due date/time, you must send mail to cse331-lateday@cs.washington.edu that you are using a late day, and include your CSE net ID in your email. (Notification of a second late day needs to be received before the new (extended) due date/time.)
As an an example, suppose that you have an assignment that is due on Thursday at 5:00pm, but you need extra time. You tell the staff by 5:00pm on Thursday, and you can turn in that assignment by Friday at 5:00pm.
You cannot use late time for HW0. Also, late days are atomic; you cannot split up a late day and submit each of three assignments 8 hours late.
To successfully build a large software system requires collaboration among people who have strong individual skills. CSE 331 focuses more on your individual skills. Courses such as CSE 403 focus on the collaboration and give you experience with group work.
CSE 331 does permit collaboration. The principles of the collaboration policy are:
More details follow.
You may have discussions with anyone you like, including other CSE 331 students.
No materials you bring to or take away from such meetings may be turned in as (part of) your solution. In particular, you may not bring any of your code or solutions to the meeting.
You may only bring away information in your long-term memory. You must destroy any materials that you and others create during the meeting. Then, you must spend 30 minutes without thinking about CSE 331. (Watching a mindless TV show is a canonical example; this is commonly called the Gilligan's Island rule.) After that, you can use whatever you still remember.
You may not allow anyone except the course staff access to your ~/cse331 directory or any other location where you keep CSE 331 code. (If you need to copy code to your home computer, use Subversion. If anyone else has access to that computer, learn how to use your operating system's access control mechanism.) Don't post large amounts of your code (more than about 5 lines) to the forum.
As an exception to the prohibition against viewing another student's work, 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, each student is expected to write and debug the assignment code individually. Debugging your code is not a tool-related problem.
You may not view and/or use 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.
Here are 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. You and other students can sketch out an algorithm or design together, but you must destroy any written materials from your meeting, let 30 minutes pass without thinking about CSE 331, and then work from your understanding (that is, from your memory).
Our 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. It is your responsibility to satisfy both the letter and the spirit of the rules. If any part of this policy is not clear, or if you have any questions or concerns, ask for clarification.
Violating the collaboration policy may result in failing the class and/or other penalties. A baseline penalty is receiving a 0 on the assignment on which you cheated, a 1.0 (letter grade) deduction on your overall CSE 331 grade, and a letter in your University file. The lecturer has sole discretion to impose greater or lesser penalties than the baseline.
We will use technological and other means to detect cheating.
You will submit the implementation part of your assignments electronically, as described in the Assignment Submission document.
To receive credit for correctness, all code you turn in must compile and run when called as specified in the assignment. The staff 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.
Your documentation must clearly indicate 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.
Most assignments provide you with a detailed specification for the behavior of the code that you will write. It is imperative that the program you write conform precisely to these specifications. For example, your program should not write anything to either standard out or standard error other than precisely what is specified. To avoid failing the automated tests, you should verify that the spelling, phrasing, or punctuation conforms to the specification. The output of your program should furthermore 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 sometimes 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.
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, and to derive the most benefit, we recommend that you:
Nothing yet.