Contents:
The course web site is http://www.cs.washington.edu/education/courses/331/CurrentQtr/.
Important All students must run student-setup by 8pm on Monday, March 29 (the day of the first lecture), or they will not be able to take the class.
| Lecturer | Michael Ernst | Office: CSE 562 | 206-221-0965 | mernst@cs.washington.edu |
| TAs | Todd Schiller | tws@cs.washington.edu | ||
| Rob Knuth | jrknuth@cs.washington.edu | |||
| Jon McCord | tiddles@cs.washington.edu |
Mail sent to cse331-staff@cs.washington.edu will reach the course staff.
Please visit your TA (or another TA, if necessary) during their office hours if you have anything you'd like to discuss about the course or course materials.
TAs may schedule TA hours in instructional computer labs such as CSE 006. Please feel free to work in the lab so you can talk to them in person when you have questions about Java or other technical details. Time permitting, they also monitor the forum while on duty, but they give priority to students who visit them in person.
The lecturers are available by appointment but do not have fixed office hours. (The lecturer will set up regular office hours if there is sufficient demand.) To schedule an appointment, see Michael Ernst's calendar.
Here are some examples of questions appropriate for the forum and staff members. Naturally, you shouldn't ask a question unless you have first tried to find the answer yourself. When asking a question, be sure to say what you have already tried to do to solve the problem; that way the staff won't waste its time and yours repeating something you already know.
We encourage all members of the class to help one another on the forums. If someone asks a question to which you know the answer, then share that answer. Class participation is an explicit component of your grade. Your participation in answering question will be considered as part of that, since it convinces the course staff that you understand the material. (It is not, however, a requirement that you answer any questions on the forum, if you demonstrate your understanding and participation in other ways.)
If you ask a question by email or in the forum but later discover the answer, follow up to tell everyone that. Otherwise, the staff, or another student, may waste time answering the question, when they could have been doing more productive work.
Please complete any assigned readings before the assigned date. The lecture or section will assume that you have read the material. If you have questions, appraise the lecturer ahead of time, or ask in class.
You are responsible for all handouts on the website. If something does not seem relevant to you yet, then at least skim it and make a note to come back to it later.
Three books are required:
Some other excellent books you should consider for your reference library on software engineering are:
CSE 331 has lectures Monday, Wednesday, and Friday from 10:30-11:20 in room EEB 045, and sections on Thursday at 8:30 and 9:30 in room MGH 254. Please attend the section that the registrar has assigned you, to keep the sections balanced.
We will distribute copies of the lecture slides. The slides augment but cannot replace your own notetaking during lecture and your reading of the textbooks.
While CSE 331 is a lab class, lab work will be performed on your own time either on IWS or using your own personal machine. Since both lectures and sections in CSE 331 tend to focus on conceptual material pertaining to software engineering rather than particulars of how to use the Java language, this term we are offering optional laboratory exercises. These sessions are optional and ungraded, but they will help you to understand and use the Java language and tools more effectively.
Lab sessions will involve a one-hour exercise that introduces you to some tool (such as editing environments, compilers, debuggers, and profilers) or to some aspect of the Java language (such as inheritance and the Swing library). TAs will be on hand to help you during their lab hours. You can work in pairs or groups on the labs to help you learn from each other: your styles, little tricks about programming, using the environment, etc. You can also get to know other students; we encourage you to work with many different people.
There will be two one-hour exams (that is: a midterm and a final exam); see the class schedule.
The TAs will run optional exam review sessions. At these sessions, they will not present material or give a review of the entire quarter so far. Rather, they will answer questions that students ask. Therefore, you should study before the exam review and use it to clarify points where your understanding is weak.
| Individual Work |
TA discretion (including section participation) |
5% | 70% |
| Problem set 0 | 1% | ||
| Problem set 1 | 6% | ||
| Problem set 2 | 6% | ||
| Problem set 3 | 6% | ||
| Problem set 4 | 6% | ||
| Problem set 5 | 6% | ||
| Problem set 6 | 10% | ||
| Exam 1 | 12% | ||
| Exam 2 | 12% | ||
| Group Work | Final Project | 30% | 30% |
We will make every effort to standardize TA grading policies, but we reserve the right to normalize grades across graders to account for remaining disparities.
CSE 331 will not be graded on a curve in the sense that (say) the top 20% of students get an A and the bottom 10% of students get a D, so students are competing against one another for a limited number of high grades. Your grade depends on you, and it does not depend on other students. If everyone does well enough, everyone can get an A. If no one does well, everyone can get a B or below.
CSE 331 will be graded on a curve in the sense that there is no pre-determined absolute percentage score (e.g., 90%) that earns an "A", a different absolute percentage score (e.g., 80%) that earns a "B", etc. Rather, the staff will set the cutoff points after the quarter is over, in a marathon meeting at which we will 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 cutoffs, using resources such as the English descriptions in the Sample UW Grading Guidelines. This will help us translate 331 scores into a UW GPA.
Slack days. We will allow you to hand in one problem sets of your choosing one day late. You must turn the problem set in no more than 24 hours after the original due date. You must notify your TA, by the original due date, that you are using your slack credit.
As an an example, suppose that you have a problem set that is due on Thursday at 5:00pm, but you need extra time. You tell your TA by 5:00pm on Thursday, and you can turn in that problem set on Friday at 5:00pm. You cannot use slack time for PS0, the final project, or returnins. Also, slack days are atomic; you cannot split up a slack day and submit each of three problem sets 8 hours late.
Integrity is crucial to a working engineer. Mathematics, physics, and computing are unforgiving of cutting corners. If you cut corners in your work or are unprepared for it, then people could die, or other real-world consequences may arise. We expect you to show high ethical standards in CSE 331, and in the rest of your career.
It is our intention that each student gains the full benefit of CSE 331 and achieves a full understanding of the course material. However, we recognize that some students benefit from discussions with other students. Therefore, we permit limited collaboration on CSE 331 assignments.
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 a member of the course staff for clarification. Violating the collaboration policy may result in failing the class and/or other penalties. The baseline penalty would be 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.
For the individual problem sets in the first half of term, you must write up all solutions on your own. However, you are permitted to discuss CSE 331 assignments with other people. No materials you bring to or take away from such meetings may be turned in as (part of) your solution. Your solution must list all other people with whom you discussed solving the assignment.
For example, it is permissible to discuss testing strategies with another student, but you may not view another student's testing code. As another example, you and other students can sketch out an algorithm or design together, but you must destroy any written materials from your meeting and work from your understanding (that is, from your memory).
No other CSE 331 student may view or use your solutions; this includes your writing, code, tests, documentation, etc. It is a violation of the collaboration policy to send more than 5 lines of code to the forum, or any other location accessible to other students. (When you have a specific code question, you are better off talking to a TA in person anyway.) It is a violation of the collaboration policy to permit anyone besides the CSE 331 staff and yourself read-access to your ~/cse331 directory or any other location where you keep CSE 331 code, in source or binary form. (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.)
Similar problems may be asked in other courses or terms. You may not view anyone else's solutions from this term or previous terms, at UW or any other institution. You may not refer to code or specifications in materials from previous offerings of any course, nor to material on the Internet that solves the problems. You may not transcribe a solution from any other source. (For instance, no one may dictate code to you, nor send you snippets of code for your use, nor create a solution for you to memorize and later type in.)
As an exception to the prohibition against viewing another student's problem set, 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. Each student is expected to debug the problem set code individually, however.
Your solutions may use code from the standard Java libraries and from libraries offered for your use by the CSE 331 staff. All other code in your submitted work for the individual assignments must be of your own creation.
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. If you use any material from an external source, you must credit it clearly in your documentation.
For the final project, you are encouraged to collaborate with your teammates on all aspects of the work, although every member of the team is expected to contribute a roughly equal share to the design and implementation. Your design and the bulk of your implementation must be unique to your group. However, you may reuse code from your work earlier in the quarter or from other sources. (For instance, you might use a specialized image library to create a graphical effect.) Code from external sources may not implement core functionality of the project. Any code you submit must be properly attributed and must be coded, documented, and tested to CSE 331 standards.
Handouts will be distributed on the class web site. Announcements will be posted as Messages of the Day on the class website and will be emailed to all students.
Students in CSE 331 are required to submit the implementation part of the problem sets electronically, as the problem sets will specify. See the Problem Set Submission document for details about the procedure for turning in a problem set.
All code you turn in must compile. It must also run when called in the manner specified by the problem set, or it will not receive credit for correctness. TAs 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, in order to 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.
For many of the problem sets we will 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. This means 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 as your program will be subjected to automated testing. 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 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 any code you submit for problem sets 1-4 has been graded, you will 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 the assignment, so failure to resubmit your program will mean you can't get more than 75/100, even if everything else was perfect.
For example, suppose that student Tortoise received 60/75 points on the first problem set submission, then later submitted a correct program, and further suppose that student Hare received 70/75 points on the first problem set, but did not bother to fix the problems in the submission. Then after adding the returnin points, Tortoise's final grade would be 85/100, while Hare's would be 70/100.
The automated returnin results are not intended to replace, or even to supplement, your own test cases. They merely help the staff evaluate the correctness of your solution. You only get to see the first failure because we want to find out how many errors remained in your program when you believed it was completely correct. It only runs periodically because you shouldn't need or expect an instantaneous result (the staff does not encourage last-minute work). These mechanisms, plus having only 3 free tries, encourage you to get your program test suite right. If you are having a lot of trouble with a piece of code, consider throwing it out and starting from scratch; that might be a more effective way to get correct, functional code than a long debugging cycle.
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 endeavor 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: