---
title: CSE 403 course project
---

The course project will provide you with hands-on software engineering
experience, involving a team of **4-6 students**.

You will design and develop your product from the ground up in one quarter. The
project is broken down into weekly milestones:

* [01 Project pitch](01_pitch.html)
* [02 Proposal, Requirements, & Team Policies](02_requirements.html)
* [03 Architecture and Design](03_design.html)
* [04 Testing and Continuous Integration](04_ci_testing.html)
* [05 Beta release](05_beta_release.html)
* [06 Implementation and Documentation](06_documentation.html)
* [07 Peer review](07_peer_review.html)
* [08 Users](08_users.html)
* [09 Final release](09_final_release.html)
* [10 Individual retrospective](10_reflection.html)

Each week you will submit artifacts required for each milestone,
write reports, and attend meetings -- just like in a real software
development project:

* submit your project milestone **every Tuesday 11:59pm**,

* submit a [weekly status report](#weekly-status-reports) **every Monday 11:59pm**,

* hold [weekly team meetings](#weekly-team-meetings) **every Tuesday during section**, and

* hold [weekly project meetings](#weekly-project-meetings) **every Thursday during section**.

## You Choose the Toolset

You will choose the toolset -- programming languages, libraries, frameworks
-- that you use to implement your project.  Regardless of your choice, your
project must follow professional standards and best practices, such as
separation of concerns, modularity, and abstraction; and use of style
checking and automatic formatting.

Your whole team should work together to survey, choose, understand, and
use your tools -- just like in the real world. You should be, or become,
comfortable with reading documentation that is sometimes incomplete or
confusing, and with installing and using new software. These are skills that
will stand you in good stead, no matter where your career takes you.

Some students report that the opportunity to learn a new toolset was a
particlarly rewarding part of CSE 403.  Doing so does come with some extra
work, though.

Your team is ultimately responsible for choosing and learning these
tools. That said, the staff wants to help you, so if you are stuck, please
ask us!  Note that we don’t know every tool or framework that you might
choose.

## Revisions

Each week, you will build on your work so far.  Your TA will give you
feedback.   Please attend to the feedback and improve your project.

If your project suffers the same defect two weeks in a row (for
example, you did not adequately address the TA feedback), then you will
lose points from both submissionts.  So, please attend to the feedback and
improve your project.

<!-- Alternative:

### Expected Revisions

Your TA may request revisions for clarity or ease of grading, without immediate
point deductions.
Common examples include changes to document structure, consolidation of content,
and addition of links to ease navigation and readability.

* _Expected Revisions_ are clearly labeled in the grading feedback.

* If an expected revision is not addressed in the submission to the next
  milestone (i.e., your project suffers the same defect two weeks in a row),
  then you will _lose points from both submissions_.

### Optional Revisions

For eligible project milestones, _Optional Revisions_ allow project groups to
recover points lost on their previous assignment. Common examples include
missing, incomplete, or vague content.

* _Recover up to 80%_ of points lost on your previous assignment by improving
  parts of the submission for which points were deducted.

* To request consideration for optional revisions, coordinate with your TA and
  agree on a format to convey the made revisions.

* If your TA approves your optional revisions, points are retroactively added to
  the previous assignment's score.

-->

## Weekly status reports

Weekly status reports help to plan and reflect on tasks.  They keep the staff and
yourselves informed about your progress.

### Format

Each status report must be a **markdown file** and must include the following
**two sections**:

1. Team report (status update for your TA, including an agenda for the project meeting).

2. Contributions of individual team members.

**Both sections** should have the following **three subsections**.  Each subsection
is best organized as bullet points.

i. Last week's goals: an exact copy of the third section from last week
     (i.e., goals from a week ago).
     It is empty for the first week.

ii. Progress and issues: what you did, what worked, what you learned, where
      you had trouble, and where you are stuck.

iii. Plans and goals for the next week: each bullet point should include a
       *measurable* task and a time estimate.

      * You may use nested bullet points for parts of a larger task.

      * If tasks from one week ago aren't yet complete, they should roll over into
      tasks for the next week, with a brief statement about struggles or
      blockers, and an updated estimate for time to completion.

      * For individual team members, no bottom-level time estimate should be
      greater than 3 days. If a task would be larger, think about a logical way
      to break it down and to have insight into progress.

      * For the team report, this subsection should be higher-level and indicate
      who is responsible for what tasks. Also, it's good to include longer-term
      goals in this list as well, to keep the bigger picture in mind and plan
      beyond just the next week.

### Submission

All **weekly status reports must be committed to your project's git repository**, within
a top-level directory named `reports/`.  Each file should be named
`YYYYMMDD.md`, using the date of the report.  In your repo
documentation and every other respect, you should pretend that this
directory does not exist.

## Weekly team meetings

Your team will meet *at least* once a week to discuss progress and issues, and/or
work together. We have reserved Tuesday sections for this purpose. It's
usually best to meet in person. **Successful teams often meet
more than once per week and collaboratively write notes and define concrete
action items.**

## Weekly project meetings

You will meet with a TA for 15-20 minutes during section on Thursday (or at
another mutually agreed time). You may schedule additional meetings or use your
TA's office hours.

The course staff serves as both customer and manager. When you have a meeting
with your TA, you are allowed to ask the TA to serve any of these roles, or even
to switch roles during the meeting. As customer, the TA can help you to
determine what a reasonable set of requirements are, and whether your documents
and prototypes are compelling. As manager, the TA can help you to resolve
conflicts or give suggestions about designs, teamwork, and tools.

It is a bad idea to try to hide information from your customer. If things are
going poorly or you are having trouble, be upfront. You may get good
suggestions, and the customer won't feel blindsided if you are unable to resolve
the problems on your own. It is a doubly bad idea to try to hide problems or
conflicts from your manager. Instead, use your manager (TA) as a resource to
help solve those issues.

## Requirements

### GitHub

We require that you use a public [GitHub](https://github.com) repository for
version control, issue tracking, and continuous integration. This means that you
will use [Git](https://git-scm.com/) for distributed version control.

You have used Git in simple ways to submit assignments in previous classes.
You may need to learn more advanced functionality to use Git in a team.
Git is extremely powerful, but it is not simple to understand or use.
You will most likely use Git in your job, so learning Git is time well spent.

Here are some resources for learning about Git:

* [Git book](https://git-scm.com/book)
* [Git tutorial](https://git-scm.com/docs/gittutorial)
* [Git reference (list of commands, etc.)](https://git-scm.com/docs)
* [Version control concepts and best practices](https://homes.cs.washington.edu/~mernst/advice/version-control.html)
* [How to create and review a GitHub pull request](https://homes.cs.washington.edu/~mernst/advice/github-pull-request.html)

### Markdown

We require that you submit status reports and repository documentation as
[(GitHub-flavored) Markdown
files](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax).

A Markdown file is a text file, in
which certain characters are interpreted as indicating formatting.
Markdown files combine three important properties:
they are readable (because of the structure and formatting),
they interact well with version control (because they are plain text files),
and they can be automatically rendered into a variety of file formats (e.g.,
html or pdf).

This document is itself written as a [Markdown file](./project.md) then
formatted as HTML for viewing on the Web, so you can look at it as an
example.  While your developer-facing documentation must be written in Markdown,
your user-facing documentation and tutorials can be written in any way you like.

### Team org, artifacts, and communication policies

We require that you create and maintain a file named `team-resources.md` that includes:

* each team member's role in the project.

* a link to each project-relevant artifact.  For example, your project may
  has one or more Git repositories (in the same Git organization/user) and Google docs.

* communication channels/tools and corresponding policies.