For the term project, we’re giving you the ultimate freedom in a CS course: the choice of what problem you want to solve. In groups of four, you will specify, design, code, test, and demo a project that is completely your own.
You will be assigned a mentor TA to guide you throughout the semester. Think of your group as a software engineering team, and your mentor TA as the team’s manager. You will be graded on the punctuality with which you meet deadlines, the professionalism of your presentations to your TA, and the extent to which you meet your goals. Communicate well with your team, and always come prepared to your meetings.
Sometimes you will meet with a TA other than your mentor TA. Think of this new TA like your manager’s manager; they are not forgiving to road-bumps you have met throughout the semester and just want to see progress. You will have to explain everything to them in great detail, because they have not been following your work. It is important that every member of the team has results to present at these meetings.
Keep in mind, the term project is not about showing off your skills to your classmates. We prefer a well designed, well thought out, well implemented project to a flashy but ill-conceived one.
When choosing your term project, make sure to pick something you and your partners are excited to work on. Your project should either be a completely new product that does not already exist, or be a significantly better product if something similar already exists.
We explicitly disallow mobile applications because they require too great of a time investment in terms of learning and configuring frameworks, as opposed to practical software engineering.
To keep your team on track throughout the semester, we have a number of checkpoints that you will have with your mentor TA. You will schedule a meeting time with your mentor TA that is on or before the due dates, and materials for each checkpoint must be emailed to your mentor TA in advance of your meeting time. These checkpoints are a significant portion of your term project grade so make sure you are ready for them.
|Specs, Mockup and Design Documents|
|Individual Component Meeting||4/23|
Project Idea (February 19)
Submit a term project idea and peruse your peers’ ideas. Try to be specific, and sell your idea to your peers! This is to help you find a group to work on your project with. Everyone should be submitting a unique idea, even if you've already got a group and project in mind.
We'd like you to submit your project idea as a follow-up post to the “Project Ideas” Piazza post. Do not post anonymously so we can record that you've posted and interested team members can contact you.
Group Formation (February 27)
Forming groups should be based on both who you want to work with and what you want to work on. Groups will have four members. This deadline will be strongly enforced – if you miss the deadline, we will assign you to a group. We highly encourage “heterogeneous” teams with students from multiple intro sequence classes (CS15/16, CS17/18, CS19, or Other). These heterogeneous teams will get to pick term project presentation times before those teams which are homogeneous.
You cannot be in a final project group with any person you worked with on a partner project (tIMDb, Maps) so keep this in mind when figuring out who you are working with!
We will enable the “Search for Teammates!” functionality on Piazza on February 19, once the project ideas are posted, to help you find a group or extra members if you're looking for them.
Project Outline (March 2)
Your project outline document is important for matching with a mentor TA, as well as developing an idea that can become a successful term project. You will write an outline document that lists each member of your team along with their strengths and weaknesses. Furthermore, you will include a list of up to 3 project ideas, and detail their requirements.
The requirements section for each idea should describe what problems that ideas is attempting to solve and how your project will solve them. It should describe the critical features you will need to develop, why those features are being included, and what you expect will be most challenging about each feature.
By this date, you should have a GitHub Classroom repo set up for your term project group (look out for a Piazza post about this after group formation!). Commit and push your project outline document to your repo by March 2. You will find out which of your ideas have been approved, and will be assigned a mentor TA shortly after. Then you should set up a meeting to go over the document together and solidify a single project idea.
The first step in developing a project is to understand what problems you are attempting to solve and to develop a requirements document that describes those problems and how your program solves them.
Detail your project from the user’s perspective. Organize and document your requirements. Then, get input from potential users (outside of your own group) on the project. We recommend developing a survey, interview, or other method in order to understand what your users want. Each feature in your requirements should be backed up by a short explanation of why it is important from the user's perspective.
Project Specifications, Mockup, and Design
(March 13) April 6
This is a large milestone for your project. After completing these three documents - especially the project design presentation - your group will know what it will take to complete your project and how you will accomplish it. No project will be released in the week leading up to this deadline, but it's not a break from the course. Instead, meet early and often with your group to prepare for this critical checkpoint.
Specifications detail exactly how your program will meet requirements and what the user should experience in every possible situation. You should have details of exactly how a user will interact with the program and what will happen for all inputs. Specifications should also include basic diagrams that show what the user will see. The more detailed your specifications document, the better.
Your mockup is a non-working demonstration that shows the expected features, screens, and functionalities of your program. It can be done using an online tool, or on paper. Every aspect of your specifications should be included in your mockup, and vice-versa, to demonstrate what you are trying to create.
Your design presentation will detail how you plan to implement/engineer your project, and should take the most work to put together.
Your design document should cleanly break the project into independent components that can be tackled by individual team members. You would be wise to divide-and-conquer your design document by having individual members design the components for which they are responsible.
Design documents should minimally contain diagrams and/or code contracts for each package, specifications for interfaces between packages, and a descriptions of major methods and data structures.
As with all of your other projects, we expect a comprehensive testing plan. This is a sequence of tests that will exercise every aspect of your project. If you’ve thoroughly tested your own code before you try to integrate it with the rest of the program, everyone’s life will be much easier. We require automated unit testing.
You should arrange a complete draft of your design and a short series of slides to present to your TA. The slides can optionally take the following form:
- Project name, group structure, division of labor, and a project description
- A fairly detailed timeline of individual schedule, in more detail than deadlines, emphasizing internal integration deadlines
- A design snapshot; summarizes overall design
- A list of expected problems/issues
The specifications, mockup, and design presentation that you develop and get approved by your mentor TA will provide the basis on which your project will be graded. Present these documents to your mentor TA by April 6th. As your project progresses and morphs, so too will your specifications/design; you are expected to keep this document current throughout the semester.
Coding Milestone 1: Individual Component Meeting (April 23)
No materials need to be submitted for the coding milestones. Meetings with Mentor TAs must be completed by the due date.
Your first demo will be to your mentor TA. At this point, each member of the team is still likely working on separate parts of the assignment, and little to no integration work has been completed. You should prepare a concise presentation, where you describe your project and what each member has done. Additionally, each team member will individually check in with your mentor TA 1:1. It is unacceptable for some member of the team to have completed no work by the time of the first presentation. Each team member will be graded separately based on the work they have contributed. You must meet with your Mentor TA by April 23.
Coding Milestone 2: Adversary TA Meeting (April 29)
By the time of your second demonstration, which will be to an adversary TA (your manager’s manager), you should have the majority of your integration work done, and your project should be in nearly working condition. Remember, the other TA to whom you are presenting is focused on results, and wants to know that each member of the team has contributed significantly to the project. You must meet with your Mentor TA and Adversary TA on or before April 29.
We recommend that you make your adversary TA meeting as early as possible. They will give you helpful feedback and a good idea of what needs to be done before your demo. This leaves some time to bang out the kinks before final demo day.
(May 2-3) May 5-6
You will meet with your mentor TA once to do a dry-run of your project demo, since there are no redos of the demo. Your mentor TA has taken the class before and can help you perfect your presentation. During this meeting, your mentor TA will also review your codebase and ask questions about implementation.
(May 4-5) May 7-8
Demo Day is your opportunity to show what you’ve been working on. It's not about one-upping your classmates or producing the biggest 3D explosions, but giving us an idea of the challenges you encountered along the way and why things turned out the way they did. We want to know why your design turned out to be good or bad, what you had to change, and what you’ve learned from the experience.
Some topics you should cover in your presentation include:
- Division of labor: Each member describes their section.
- Goals of the project: Were they met? If so, how? If something wasn’t, what happened?
- Difficulties: What did you learn from this experience?
- Visuals: Find something to show us, if applicable.
- Guided tour/demo of the program.