Project

Project

The goal of CS 3110 is to help students become excellent programmers who can design and implement software that is elegant, efficient, and correct, and whose code can be maintained and reused. Toward that end, a significant part of the second half of the course will be devoted to a team programming project. You will form a team, choose a system you want to build, design it, review your design with a member of the course staff, implement the system, and submit it along with additional documentation. The constraints are few and the space is large. You'll need to make decisions and solve problems along the way. We hope you find it highly rewarding.

Quick links to project milestones:

Overview

You will choose one of the following systems to build. Each system (except the last) has a short description. Each could be refined into an acceptable project, and you should feel free to do so. Or, if you prefer, you may opt for the last choice and invent your own system. Your system may not involve extending an assignment from this course or another course; it should be a fresh implementation effort.

Non-requirements: A graphical user interface is not required. Text-based interfaces will suffice. Similarly, a client–server architecture is not required. A standalone program that runs on the local machine will suffice.

Be warned that networking and GUIs can be difficult, and that most of the course staff will not have experience with those (at least not in OCaml) to help you. So if you want to go for such a project, start building a prototype of that functionality early. And have a backup plan in case it becomes too hard to get done in time.

Further inspiration: The winners of last fall's Staff Choice awards built a keyboard music player and two games. You, too, have the opportunity to be immortalized on the 3110 Tournament Page! To be eligible for the Staff Choice award, your system must be easily deployable on the course VM following the install instructions you include with your final submission.

Team

Why a team project? Because...

Team formation: You are responsible for forming your own team. You can use the team formation features of Piazza to help with this.

Team size: Your team may have three or four members, at your choice. Two member teams are not permitted: we want you to experience programming in a larger group, in which communication challenges arise. Five member or larger teams also are not permitted, as the scope of the project does not warrant that many human resources.

Personnel changes: You are permitted to change teams between milestones, although we discourage doing so unless it becomes necessary for reasons of interpersonal conflict.

Objectives

Technologies

You must use OCaml to implement your system. You may use any packages available through OPAM that work on the 3110 VM. If you have questions about whether you can use other third-party code or tools, then ask, rather than assuming one way or the other.

You are required to use Git (or another version control system) throughout the implementation phase of your project. As always, you must use a private repo. After the project is over (i.e., when the semester ends and you have received your grades), you are welcome to open source your software and make it public.

Grading

Your grade will be influenced by the quality and non-artificiality of your project.

Of the total percentage dedicated in the syllabus to the final project, we expect the breakdown between milestones to be as follows:

Projects that are exceptional in scope and quality might, at the professor's discretion, receive a bonus of up to 10% on the final milestone. The primary way to achieve this bonus is to build a system that is new and exciting. New means that your system should have some aspect that is novel, rather than just replicating some existing system. Exciting means that your system should have some aspect that provokes a response of "hey, that's cool!" In the ideal case, the exciting aspect of your software is also new. In that case, you might become rich and famous. :)

Milestone 0: Charter

Deadline: Thursday, 03/15/18, 11:59 pm, no late submissions allowed—submit what you have by the deadline

Your task in this milestone is to form a team and decide what you want to build.

What to submit: A 1-page document named charter.pdf containing the following information:

Milestone 1: Design

Deadline: Thursday, 03/29/18, 11:59 pm, no late submissions allowed—submit what you have by the deadline

Your task in this milestone is to think carefully through the design of your system before you write any code.

What to submit: Prepare a design document named design.pdf containing the following information:

Your design document should be about 1000 words, excluding the system description, diagrams, and .mli files. Keep the formatting simple and easily skimmable: a reader should be able to look at the document quickly and get the basic idea, and quickly identify where to go for details. In practice, this means:

Assessment: Your design document and interfaces (i.e., .mli files) will account for about 80% of your MS1 grade. You will be assessed on whether your design document includes all the information that is requested in sufficient detail for the grader to understand it. You will also be assessed on the level of detail in your interfaces (i.e., .mli files), including the completeness of your design and the specifications found for the modules and functions in them. The design document and interfaces will be weighted about equally.

Design review meeting

Occurs during: Monday, 04/09/18 through Friday, 04/13/18

After design documents are due, you will have a design review meeting with a member of the course staff.

You will choose a staff member using the CMS scheduling feature. Contact that staff member to schedule a 30 min appointment outside of regular consulting hours before the deadline (given above). Contact them ASAP after the schedule is made available; it is not their responsibility to accomodate you at the last minute if you fail to schedule an appointment well in advance.

The only new thing you need to bring to your meeting is an implementation plan: a schedule of what you plan to implement by when.

Here's the agenda for your design review meeting:

Assessment: Your performance at and preparation for this meeting will account for about 20% of your grade for MS1. All team members are expected to be familiar with the team's project effort, and the team as a whole will be held accountable for that. Of course, it makes sense for certain team members to be subject matter experts on pieces of the design (e.g., front-end vs. back-end, or AI vs. game logic). All your team members are required to attend. Any absent team member will incur a 10% penalty for themselves (not the rest of the team) on their MS1 grade.

Milestone 2: Prototype

Deadline: Tuesday, 05/01/18, 11:59 pm, no late submissions allowed—submit what you have by the deadline

Your task in this milestone is to produce a preliminary prototype that demonstrates some of the functionality of your final system. A good way to demonstrate functionality is using tests that exercise the code in some of the components of your system. (It's totally fine if you do not yet have any end-to-end tests running by Milestone 2.)

What to submit: Prepare a document named status.pdf containing the following information:

Your document should be about 1000 words, excluding any supporting diagrams and any other files. Keep the formatting simple and easily skimmable: a reader should be able to look at the document quickly and get the basic idea, and quickly identify where to go for details. In practice, this means:

Assessment: Your prototype document and tests (i.e., .ml files) will account for about 80% of your MS1 grade. You will be assessed on whether your design document includes all the information that is requested in sufficient detail for the grader to understand it. You will also be assessed on the level of completeness and sophistication for your tests (i.e., .ml files). The design document and tests will be weighted about equally.

Prototype review meeting

Occurs during: Wednesday, 05/02/18 through Tuesday, 05/08/18

After design documents are due, you will have a prototype review meeting with a member of the course staff.

You should contact the staff member who did your design review meeting to schedule a 30 min appointment outside of regular consulting hours before the deadline (given above). Contact them early; it is not their responsibility to accomodate you at the last minute if you fail to schedule an appointment well in advance.

Here's the agenda for your prototype review meeting:

Assessment: Your performance at and preparation for this meeting will account for about 20% of your grade for MS2. All team members are expected to be familiar with the team's project effort, and the team as a whole will be held accountable for that. All your team members are required to attend. Any absent team member will incur a 10% penalty for themselves (not the rest of the team) on their MS2 grade.

Milestone 3: Implementation

Deadline: Tuesday, 05/15/18, 4:30 pm, no late submissions allowed—submit what you have by the deadline

Your task in this milestone is to implement your system.

What to submit:

Grading issues:

Assessment: The files you submit will account for about 75% of your grade on MS3. You will be assessed on the scope of your system (about 50%), the quality of your code (about 12.5%), and your testing methodology (about 12.5%). The latter two will be assessed much as they have been on assignments all semester. For scope, we will be assessing the difficulty and extensiveness of the system you implemented. Systems that are comparable in difficulty and size to the sample systems above will usually receive grades in the B range. Systems that are significantly more impressive (perhaps because of interfaces, networking, feature set, algorithmic difficulty, or master of new libraries) will receive grades in the A range. Systems that are comparable in difficulty or size to early course projects, like A1 and A2, will receive grades in the C range. "Difficulty" here means the difficulty that they posed at that time, before you had learned functional programming or (e.g.) Yojson—not how difficult they would be to resolve now.

Demo

Occurs during: Monday, 05/14/18 through Friday, 05/18/18

After the final implementation is due, you will have a demo session with a member of the course staff.

You will meet with the same staff member who held your design review meeting. Contact that staff member to schedule a 30 min appointment outside of regular consulting hours before the deadline (given above). Contact them ASAP; it is not their responsibility to accomodate you at the last minute if you fail to schedule an appointment well in advance.

Here's the agenda for your demo:

Assessment. Your demo will account for about 25% of your grade on MS2. Your demo will be assessed on the perceived quality of your system. Excellent demos will have no errors or crashes, an intuitive user interface, will get started immediately without any difficulties of launching or configuring the system, and all features will be working as expected. All your team members are required to attend. Any absent team member will incur a 10% penalty for themselves (not the rest of the team) on their MS2 grade. Each day after 12/11 that your team is late in having its demo will incur a cumulative 25% penalty on your team's MS2 grade.

Hints

Here is some sarcastic (and hopefully humorous) advice on how to lose in a group project. Although it was written for CS 2112, it's applicable to CS 3110 as well.

Appendix: Teamwork

At your first team meeting, we strongly encourage you to write a short set of ground rules for your team.

Here are two sample sets of ground rules that you might use as a starting point for discussion:

(Source: University of Minnesota Office of Human Resources)

(Source: University of Waterloo Centre for Teaching Excellence, citing Levin and Kent (2001).)