Midterm Project

The next three programming assignments will be devoted to a midterm project. The project is open ended: you get to pick what system you want to build, subject to the requirements stated below. Think of this project as an activity that takes place instead of a second prelim—and that requires correspondingly great intensity.

FYI: This midterm project is significantly different from the old final project that CS 3110 used in the last few years. Please do not make any assumptions based on the old final project.

What you’ll do: There will be three phases to the project: Alpha, Beta, and Final, corresponding to A6, A7, and A8. In each phase you will do essentially the same thing: build out and demo to your discussion section some part of your system, write a brief report on your progress toward your final goal, and submit your code for evaluation.

Table of contents:

• Project Requirements
• Sprints
• Demos
• Progress Reports
• Assessment
• Submission

Project Requirements

The primary educational objective of this project is for you to build a system from scratch with a team. It’s entirely up to your team what that system does. The kind of system you should have in mind is the kind that you built in A2+A3 or A4+A5: an application that achieves some well-defined purpose and has value to a user. Pick something that you are excited about!

(If you’re stuck for an idea, consider building a turn-based game that is fun to play in a text interface. Playing chess or poker against an AI would be good examples. But please don’t feel constrained by those suggestions.)

“Building from scratch” means that you may not build off of your previous assignments in this class, or current or old assignments in other classes. The work that you do for 3110 needs to be specifically for this course and not another.

“Building from scratch” also means all the implementation effort needs to be your own, rather relying on the functionality that third-party libraries provide. So, you are welcome as always to use the core and standard libraries, as well as any libraries we have used in A0-A2 and A4-A5 (OUnit, Yojson, ANSITerminal, Unix, Str, QCheck, Bisect). But other libraries (such as networking, graphics, multithreading/Async, etc.) are not permitted for use.

FYI: No doubt that prohibition will disappoint some teams, and we regret that. We hope you can nonetheless enjoy focusing on writing your own code, rather than spending time researching and plumbing together third-party libraries. The latter is a useful skill, but not an objective of this course.

The system you build needs to be a unified, cohesive application that requires all members of the team to work together. It may not be a few similar applications, implemented independently by team members, that are loosely held together. For example, a “casino” in which the user can choose to play three different games is not permitted: it leads to a team building three separate systems that are loosely glued together, instead of collaborating on a single system.

There is no starter code, obviously, since you are building your own system. Likewise there is no make check system, because there is no autograder.

Sprints

The project is organized as a sequence of 1-week phases or sprints, during each of which you build some “shippable” increment of your system. That means implementing some functionality that can be demoed to your section and TAs. It’s your choice what that functionality is.

What doesn’t matter: How much code you write, or how hard or complicated that code was to write, or how much time you spent on it.

What does matter: The functionality you implement offers clear value to users of the system—value that can be seen through a running demo of the system, rather than code that isn’t yet runnable or integrated into the system, or whose value can be seen only through unit tests.

Using A2+A3 as an example, a successful sprint would involve building out some new player commands and being able to demo that they work in the interface. An unsuccessful sprint might involve adding JSON fields to the adventure file and adding parsing code for them, but not being able to see the effect of that as a player.

At the beginning of a sprint, you should therefore spend time planning as a team what functionality you want to implement. Identify small enough pieces of functionality that you could implement several of them in the sprint. Prioritize, so that the functionality that offers more value to users is completed first. Have stretch goals for each sprint, in case some functionality turns out to be easier than you expected. In other words, practice risk mitigation. There is always some risk that you have mis-estimated how much work it will take to implement functionality; be prepared for that eventuality.

Demos

During the Wednesday or Thursday discussion section at the end of each sprint, you will spend the section demoing your completed functionality to the other teams in your section. Bring laptops with your system pre-installed and running, so that everyone can see the result of your hard work!

We encourage you to give constructive feedback to the other teams as you try out their systems, and to receive such feedback yourself. Perhaps other users will expose faults in your system, or have ideas about how to improve the interface, or thoughts about enhancements you could make in future sprints.

If no one from your team is present to demo your system, you will automatically receive a grade of Unsatisfactory for that sprint.

Note that you may demo whatever you have completed at the time of the demo, regardless of what you have or have not submitted to CMS. Your grade will be primarily be based on the report that you submit (described next), and that report will be due at the same time for everyone.

Progress Reports

With every team building a different system, it’s impossible for your work to be assessed in exactly the same way as the previous programming assignments have been. After all, the course staff can’t build its own test suite for each of the nearly 100 projects.

Instead, you will do a self-evaluation of your progress at the end of each sprint by writing a progress report. Your report will be due the day after your source code, to give you time to reflect on your progress and plan your next sprint.

Your report should be approximately two to three pages long. It should contain the following information:

• Vision: In one paragraph, what is your current vision for the system you are building? How has it evolved from previous sprints?

• Summary of progress: Write a one or two paragraph description of what your team accomplished during the previous sprint. What functionality did you work on? What did you show off in your demo? Is there additional functionality you completed in the day after the demo that you want to include in the report?

• Activity breakdown: For each team member, give a bulleted list of the responsibilities that team member had and the activities in which they participated during the sprint.

• Productivity analysis: As an entire team, how productive were you? Did you accomplish what you planned? Were your estimates of what you could do accurate, or far off? Write a paragraph addressing those questions.

• Coding standards grades: Evaluate your own source code on the standards of Documentation, Testing, Comprehensibility, and Formatting. Give yourself a grade of Exceeds Expectations, Meets Expectations, or Needs Improvement in each category. Write a paragraph or two providing a justification for those grades.

• Scope grade: Give your team a scope grade for this sprint—Satisfactory, Good, or Excellent. No plusses or minuses, please. Write a paragraph or two providing a detailed justification of why you gave yourself that grade. Recall, from above, what does matter (user value) and what does not matter (raw code) in a sprint. On the Beta and Final sprints, a grade of X should be equivalent to having successfully implemented and demoed functionality that is comparable to the scope of X on assignments A3 through A5 (individually, not combined). On the Alpha sprint, we will expect less progress.

• Goals for next sprint: Set three goals for your next sprint, corresponding to what you believe would constitute Satisfactory, Good, and Excellent scope for that sprint. (You may omit this section in your final report.)

Acknowledgement: this progress report format is based on Prof. Walker White’s CS 4152 (Advanced Games) progress report.

Assessment

The graders will briefly examine your source code to be sure that what they saw in the demo was legitimate and really implemented in your code, rather than being some kind of mock-up.

Primarily, though, the graders will compare the experience of your system that they got from the demo against the progress report you have written, and evaluate whether the justifications you provide for your grades in your report seem to be correct and compelling.

As context, the graders will look at the grades the other teams in your section gave themselves. A team that grades itself as Excellent in scope, for example, but demos functionality that is clearly inferior to many other teams, is probably deluding itself.

The graders will then give you a single overall grade on the assignment of Excellent, Good, Satisfactory, or Unsatisfactory. We are deliberately grading on a coarse scale, because fine-grained comparisons are infeasible to make given the open-ended nature of the project.

We acknowledge that there is some unavoidable subjectivity in this grading, just as there is in grading any kind of creative work—be it a proof in an upper-level CS class, a performance in a music class, or an essay in an English class. The course staff will be careful to cross-check between sections to keep the grading as consistent as possible.

If subjectivity is discomforting, it’s worth considering that the only reason we could have mostly objective grading on the previous assignments was that they were the kind of programming assignment you get in a college classroom, rather than in the real world. This midterm project is meant to bridge the gap into the real world of software development. We hope you find that exciting, as we do.

Submission

Source code. Make sure that your source code contains the usual Authors compilation unit, with your team’s NetIDs in authors.mli, and the hours_worked variable at the end of authors.ml. Construct a zipfile containing all the source code for your system. Make sure that you do not include the _build directory, which would artificially inflate the size of your zipfile. Submit your zipfile on CMS. Double-check before the deadline that you have submitted the intended version of your file.

Progress report. Submit your progress report on CMS before the deadline. The progress report should not be an afterthought: it is a critical component of this project. Don’t blow it off or forget about it.

Late days. To keep teams on track, the use of late days will be a little more limited for the midterm project assignments. You will be able to use at most one late day on each sprint for submitting your source code. Your progress reports may not be submitted late and will always be due on Thursday, regardless of whether you use a late day for the source code.

Failure to submit. If you do not submit either your source code or progress report, you will receive a grade of either Satisfactory or Unsatisfactory for that sprint, depending on how your demo went. As usual, submissions will not be accepted through email. You must upload to CMS by the deadline.