MS1: Beta

Your task in this milestone is to complete your first sprint. Build some functionality, test it, demo it to your section and TAs, submit your source code, and submit a progress report as described below. At the end of the sprint, you will do a group exercise on teamwork.

Table of Contents:

• Read the Handouts
• Build and Test
• Demos
• Progress Reports
• Submission
• Rubric
• Teamwork Exercise

Read the Handouts

Please read all of the MS1 through MS2 handouts at this time, especially the final rubric in the MS2 handout.

Build and Test

During the first of the two weeks of this sprint, you’ll be working on other assignments as well. So during that week, you’ll probably want to just do some planning on MS1. As a team, decide what functionality you want to implement in MS1. You already did some thinking about that on MS0. Now, go deeper. Identify small pieces of functionality that can be divided among team members. It is perfectly fine for each team member to be working on distinct tasks.

During the second week of the sprint, you won’t have a 3110 programming assignment due. So, it’s time to hit the ground running! Work hard to implement your planned functionality. At the same time, put all those good software engineering techniques we’ve been teaching you this semester to good use: keep the code quality high, everything documented, and the test suite growing.

Demos

On the Tuesday or Wednesday discussion section following the sprint, you will spend the section demoing your completed functionality to the other teams in your section. At least one person from your team must be present. Be prepared to share your screen, with your system pre-installed and running on your laptop, so that everyone can see the result of your hard work!

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.

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.

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 120+ 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 Thursday after your demo, to give you time to reflect on your progress and plan your next sprint.

Your report should be approximately one to two 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?

• 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.

• Scope grade: Give your team a scope grade for this sprint—Satisfactory, Good, or Excellent—based on your experience of those levels of scope in the assignments thus far in this course. Write a paragraph or two providing a detailed justification of why you gave yourself that grade. Please be honest: we want you to reflect candidly on your progress. Your sprint grade is not going to be based on what you self-assign here.

• 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.

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.

• Include a file named INSTALL.txt or INSTALL.md with instructions on how to install and build your system. This file should include any commands the grader needs to run to install OPAM packages, etc.

• 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.

Rubric

Total: 10 points.

• 2 points: demo. If at least one team member is present, the system is running, and some functionality is being demoed, you get all 2 points. If no one is present, you lose all 2 points. If there are problems with the system, you lose 1 point.

• 2 points: source code. The grader will attempt to download your submission from CMS, follow the instructions in your INSTALL file, and run your system on their own machine. If that’s successful, you get all 2 points. If some or all of your source code is missing, you lose all 2 points. If the grader can’t run your system because of errors in your code or in your install instructions, you lose 1 point. The graders will briefly interact with your system to verify that what they saw in the demo was real, rather than being some kind of hoax. The latter would potentially be an Academic Integrity case; so, just don’t do that.

• 6 points: progress report. You get 1 point for each of the 6 required sections of the report. You will get a 1/2 point deduction for any section that is not sufficiently thorough or is lacking in justification. In evaluating your justification for your self-assigned Scope grade, the grader 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.

Code quality, documentation, and testing will not be graded until MS2 (see the MS2 rubric for details), but don’t wait until then to work on them!

Teamwork Exercise

A day or two after you have submitted all the deliverables for this sprint, fill out this form together as a team. Use that as an opportunity to have a discussion about how you can become more effective as a team. You do not need to submit the form; it is for your edification, not for the course staff to read.