BACK TO CSE403 HOME

Course project: Overview

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 several milestones.

In addition to submitting artifacts required for each milestone, each week you will submit reports and attend meetings – just like in real software development projects:

submit a weekly status report every Wednesday 8pm,
hold weekly team meetings every Tuesday during section, and
hold weekly project meetings every Thursday during section.

You have a great deal of latitude in choosing your own toolset. Your team is ultimately responsible for choosing and learning these tools. That said, the staff wants to help you as much as possible, so if you are stuck, please ask us! However, be aware that we don’t know every tool or framework that you might choose. 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.

Expected and Optional Revisions

Expected Revisions

Expected Revisions represent project-specific change requests for issues that did not lead to deductions. If an expected revision is not addressed in the submission to the next milestone, points are retroactively deducted from the previous assignment’s score.

Lose up to 1pt on your previous submission for not addressing expected revisions, as requested in the grading feedback on your previous submission.
Expected revisions are clearly labeled in the grading feedback. Common examples for expected revisions include changes to document structure, consolidation of content, and addition of links.
This rubric item is part of the total points for an assignment (it is not extra credit).

Optional Revisions

Optional Revisions for eligible project milestones allows project groups to recover points lost on their previous assignment. The points are retroactively added to the previous assignment’s score.

Get up to 1pt back on your previous assignment by improving parts of the documentation for which you lost points.
To request consideration for these points, coordinate with your project manager and agree on a format to convey the made revisions. Common examples for optional revisions include missing, incomplete, or vague content.

Weekly status reports

Weekly status reports help to plan and reflect on tasks, and 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:

Team report (status update for your TA, including an agenda for the project meeting).
Contributions of individual team members.

Both sections should have the following three subsections – each about a paragraph or organized as bullet points.

The first subsection is easy. It should be an exact copy of the third section from last week (i.e., goals from a week ago). It can be empty for the first week.
The second subsection should report on progress and issues: what you did, what worked, what you learned, where you had trouble, and where you are stuck.
The third subsection should outline your plans and goals for the following week. Bullet points are fine. If tasks from one week aren’t yet complete, they should roll over into tasks for the next week, with an updated estimate for time to completion. 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 git repository, inside a top-level directory called reports.

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. You can meet via Zoom, Slack, or any other conferencing system. 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. Don’t forget or underuse either of these roles.

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 repository for version control, issue tracking, and continuous integration. This means that you will use Git for distributed version control:

Markdown

We require that you submit status reports and repository documentation as markdown files. Here is a good summary of the markdown syntax:

GitHub markdown

Team org, artifacts, and communication policies

We require that you create and maintain a file named ORG.md (at the top level of your repository) that includes:

each team member’s role in the project.
a link to each project-relevant artifact (e.g., Git repos and Google docs).
communication channels/tools and corresponding policies.

Programming languages

You may use any programming language you like. However, your project must follow professional standards and best practices, such as separation of concerns, modularity, and abstraction.