Syllabus

Course Description

Fundamentals of software engineering using a group project as the basic vehicle. Topics covered include managing complexity, requirements specification, architectural and detailed design, testing and analysis, software process, and tools and environments.

Prerequisites

Course Format

The class meets three times a week for lectures and once a week (Thursday) for section, which is usually a meeting with your TA, who is acting as your customer and mentor. The second weekly section (Tuesday) is reserved for group meetings. Classroom material is enhanced with assigned readings.

A major component of the course is teamwork on a group project. Individual work includes reading questions, assignments, and an exam.

There is one comprehensive exam in class, during the last two weeks of the quarter. It covers all material, including lectures, readings, project, etc. You can find exams from previous versions of this class (with and without solutions) here.

Textbook

There is no required textbook. The Pragmatic Programmer, by Dave Thomas and Andy Hunt, is recommended. You already own it, because you bought it when you took CSE 331.

Grading

General Grading Information

General information about grading at the University of Washington is available as part of the University of Washington Student Guide. A general description of what the grades mean is available as part of the Faculty Resource on Grading.

The class is not graded on a curve in the sense that a certain percentage of students will receive an A, a certain percentage will receive a B, etc. Doing so would be unfair, and in violation of the UW grading guidelines. I hope and experct everyone in the class to get an A. I also expect everyone to work hard to earn that A, or they will not receive it.

The class is graded on a curve in the sense that the final grade is not mechanically computed from the number of points on assignments. It is not the case that students must earn 90% of the overall possible points to receive an A. For example, on exams, earning 65% of the possible points usually translates to an A.

Weighting of Scores

The scores you receive on the various graded tasks in the class will be weighted as follows. The weighting is subject to change.

55% Project (weights per part vary)
5%Feedback to other teams and students
15%Reading questions and Assignments
15%Exam
10%Participation
100%Your Total Score for the class

All members of a group will receive the same grade on group work. Therefore, it is in your interest to choose other group members who have the same goal in the class as you do. It is also in your interest to work together and ensure that all tasks are completed effectively; for example, when a teammate is giving a presentation, give constructive feedback to improve it.

Your scores on group work may be adjusted based on your contribution.

You can view your grades by accessing the course grade book.

Late Policy

Assignments must be turned in by the due date and time in order to contribute to your grade. Assignments will not be accepted late. In case of severe circumstances such as hospitalization, contact the instructor. Individual assignments are submitted via Canvas. Group (project) assignments are generally submitted by pushing to your team's version control repository.

Regrade Policy

We will entertain questions about grades only for one week after they are posted in the course grade book. Questions about assignment grades or comments should be written and submitted to the staff via email. We may correct the errors (and regrade the entire assignment to ensure consistency) and/or meet with you.

Peer grading

For most assignments, you will review another student's or team's submission. This will show you a different way of doing things and give you a different perspective on the assigment, such as thinking about reproducibility or about comprehensibility to other people.

The staff will also grade every assignment. We will compare peer grading with our grading, for consistency.

Canvas notifications

It is your responsibility to view all comments on your assignments, including comments that are submitted after grades or initial comments are released. You should set your Canvas notifications for submission comments to "Notify me right away":

Academic Integrity and Special Accomodations

This class starts fast

The class starts out full-speed. Unlike some classes, it expects you to do work in the first week. Your work for week 1 should be within the expected 8 hours of work (+ 4 hours of class meetings). Please let us know if it isn't.

The reason for the fast start is to enable you to start on your project by week 2, around 15% the way into the quarter. In the past, we have tried a slower start. It compressed the time for projects, reduced their quality, and negatively impacted the class.

The assignments may be different than ones you have seen before. This is intentional: the goal of this class is to teach you new skills that you won't learn in any other class at UW! The skills you learn — including critical thinking and writing — will help you in your career, no matter what you end up doing.

Don't be discouraged if you get a lot of comments or a low grad on the first few assignments. The first assignments are weighted less than later assignments, so they have a small effect on your course grade. Getting feedback on them early helps you learn what the staff expects. That will improve the work you do later in the quarter (when it counts more) and when you gradate (when it counts most of all).

Other students have survived the class smiling, and we have faith that you will too! We have high expectations, and we will help you achieve them.

Advice from previous students

At the end of the quarter, we ask students what they wished they had known, to help them be successful in this class. Here are some frequent answers.

How to ask questions

The following rules hold whenever you ask a question of anyone. We repeat them here because some of you might not have learned them in a previous class. They are the same as standard rules for writing a good bug report: Oracle, Mozilla, Ximian, Tatham, Raymond.

If you are having trouble, we want to help you.

However, you need to provide sufficient information about your problem. This includes:

Also, before you ask for help, you should try to help yourself, and your question should reflect that effort. Don't ask questions that are solveable by an easy web seach. (This is a waste of everyone's time. Also, if you aren't willing to lift a finger to help yourself, that reduces the motivation of others to help you.) Explain what you have already tried and what happened.