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 9 weeks. The project is broken down into weekly milestones:

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

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.


Each week, you will build on your work so far. Your TA will give you feedback. 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.

Weekly status reports

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


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, though you can write a paragraph instead. paragraph or organized as bullet points.


All weekly status reports must be committed to a git repository, which should contain a top-level directory named reports/. A good filename is YYYYMMDD.md, using the date of the report. For convenience, you may include your reports in your project repository, in which case you should (in your repo documentation and every other respect) pretend that these reports do 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.



We require that you use a public GitHub repository for version control, issue tracking, and continuous integration. This means that you will use Git for distributed version control.

You have used Git in simple ways to submit assignments in previous classes. You will 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:


We require that you submit status reports and repository documentation as (GitHub-flavored) Markdown files.

A Markdown file is a text file, in which certain characters are interpreted as indicating formatting. Markdown files combine two important properties: they look good to read (because of the formatting), and they interact well with version control systems (because they are plain text files).

This document is itself written as a Markdown file 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 Markdown, your user-facing documentation can be written in any way you like.

Team org, artifacts, and communication policies

We require that you create and maintain a file that includes: