Project: Final Deliverable Due 12 December 2023 11:59pm AoE

The final project deliverable is the implementation (in GitHub) and the documentation turned in to Canvas. It also includes your final demo.

Project Implementation and Documentation

Your final team deliverable will be a “release” of your new feature on GitHub (with tests), and will be accompanied by a demo. Optionally, you may also open a pull request to merge your feature into our main repository (submitting a pull request, or the pull request being merged into our codebase is independent of the grade you receive, but provides a platform for more visibility of your project).

Contents

Your final team deliverable will include:

• The implementation of your new feature
• Automated tests for your new feature
• A report that describes how to use your new feature

Accompanying the final team deliverable will be an individual reflection, which every student must submit on their own which will include your reflections on:

• The evolution of your project concept: How does the project that you delivered compare to what you originally planned to deliver? What caused these deviations?
• The software engineering processes that you feel could have been improved in your project: were there any processes that in hindsight, you wish that you followed, or wish that you followed better?
• Your team dynamic: Provide a frank (and ideally, blameless) postmortem of your and your teammates collaborative performance and participation. If you had to do this same project over with the same teammates, what would you have done differently (or not) to improve your team’s overall performance?

Submission Instructions

Code and documentation

After you have pushed all of your code (and documentation) to your team’s GitHub repository, create a release on GitHub, and apply the tag version final-submission. After your release is created, you’ll find that there is now a .zip that can be downloaded from GitHub that contains a snapshot of your entire repository. Download this zip file, unpack it, and follow the instructions that you provided in your README to double-check that the course staff will be able to run your project locally (this step is handy to make sure that you didn’t forget to include some key files in git). If needed, you can delete the release, make some changes, and re-release up until the deadline. Submit this zip file to Canvas under the assignment “Project: Code Submission”. Submit your report separately to Canvas, under the assignment “Project: Report”.

Project Demo

We will have live (in-person) demos at the project showcase during the last day of class. You are required to attend on the last day of class, barring exceptional circumstances. Make sure that at least one member of your team has a laptop that can access your deployed covey.town instance with them on the last day of class.

Individual Reflection

Create a PDF of your reflection, and submit it to Canvas, under the assignment “Project: Individual Reflection”.

Grading

Each project will be graded by the team’s assigned mentor and one other member of the course staff (including at least one instructor). We do not expect all teams to deliver all of the features that were initially proposed - in the (relatively short!) implementation period, there are sure to be some teams that encounter unexpected technical hurdles. As described in greater detail in the rubrics below, teams that have regular communication with their mentor regarding their project status may be permitted variances to their project scope. For most of the submission components below, we provide two benchmark rubrics: one for a submission that is satisfactory (full marks), and one that would be meeting our minimum expectations (a pass). In practice, when grading projects we will usually assign numeric grades and provide partial credit, using these rubrics as guidelines for those two extremes.

In cases where team members do not equally contribute to the project, we may assign different grades to different individuals, up to an extreme of deducting 50% of the marks from a student. We will evaluate each individual’s contribution on the basis of a variety of factors, including progress reports at meetings with your mentor, through inspecting version control history, through each student’s self-reflection, and through each team’s (or student’s) peer evaluations during and/or at the end of the project. We will make regular efforts to collect and distribute this feedback throughout the project. Our ultimate goal is for all students to participate and receive full marks.

Summary of grading

• Planning Documents
  • 7.5% Preliminary Project Plan (already graded)
  • 10% Revised Project Plan (already graded)
• Activities During the Project
  • 5% Meetings with Mentor and Team Surveys
  • 10% Ongoing development progress, including code reviews
• Final Deliverables
  • Code
    • 20% Final implementation of your feature
    • 10% Final test suite of your feature
  • Report
    • 5% Feature Overview
    • 7.5% Technical Overview
    • 7.5% Process Overview
  • Demonstrations
    • 2.5% Wizard-of-Oz demo (already graded)
    • 5% Preliminary Demo (already graded)
    • 10% Final demo

This adds up to 100%; this sum is worth 45% of the course grade.

Here are the detailed rubrics for the final deliverables:

20% Delivered Features

We will grade each delivered project holistically using the following two rubrics:

Satisfactory:

• Implemented feature satisfies the conditions of satisfaction as proposed by the team and as agreed to by the course staff. If technical difficulties resulted in features being dropped, the project may still earn full marks on “delivered features,” but these difficulties must have been documented with the course staff as you encountered them during development.
• Implemented feature can be deployed locally following the instructions provided with the code submission in its README without any debugging by the course staff.
• Implemented feature contains no ESLint warnings or errors; does not include any eslint-disable or ts-ignore flags

Meets minimum requirements:

• Implemented feature largely satisfies acceptance criteria as proposed by the team, but may not meet the course staff’s interpretation of those criteria.
• Implemented feature can be deployed locally following the instructions provided with the code submission in its README, with minor debugging by the course staff (e.g., one or two minor missing steps).
• The implementation may have some obvious flaws, but largely works without crashing.
• Implemented feature does not include any eslint-disable or ts-ignore flag

10% Testing

The project must include evidence of testing. Ideally, all new features will be accompanied by fully automated tests, but in some circumstances (particularly when engaging with Phaser, the game library, or Tiled, the map editor), this may not be feasible. If automated tests are not possible, include a discussion of your manual testing strategy, including a script that a future developer could use to manually test the feature.

Satisfactory:

• Any new or modified backend features include tests that validate that the feature works as intended. These tests cover the changed code, and also contain well-written assertions that thoroughly check the expected behaviors.
• Tests contains no ESLint warnings or errors; does not include any eslint-disable or ts-ignore flags

Meets minimum requirements:

• Any new or modified backend features include at least one test, which may or may not be an effective test.
• Tests may contain ESlint warnings (but no errors); does not include any eslint-disable or ts-ignore flags

Activities During the Project

5% Weekly Meetings with Mentor and Team Surveys

Throughout the semester, each team will be meeting with their mentor and with the instructor to discuss their project progress. Attendance at these meetings and demonstrations of progress will, cumulatively, account for 5% of the project grade. You will also be asked to complete Team Surveys and/or Peer evaluations to help track the progress. Note that being present for meetings (both literally and intellectually) with your mentor also factors into your individual Participation and Professionalism grade, so though this is a small part of the project grade, its weight in your final grade is larger.

10% Ongoing development progress, including code reviews

Each team is expected to use their GitHub repository, regularly committing changes while developing their project. You will also be expected to use pull-requests and code reviews.

Satisfactory:

• There is a clear development history visible from the git repository: features were delivered incrementally, and not in a single (or several) commits at the end of the project
• There is evidence of code review - for example, pull requests that have comments on them
• There is a correspondence between commit messages and the technical tasks that they are associated with; there are few (if any) commits with meaningless commits messages like . or Add files via upload.
• Each team member has made at least 4 commits over the lifespan of the project

Meets minimum requirements:

• There is a clear development history visible from the git repository: features were delivered incrementally, and not in a single (or several) commits at the end of the project
• Each team member has made at least 2 commits over the lifespan of the project

Final Report

The final report should consist of three sections:

5% Report – Feature Overview

Satisfactory:

• The Feature section contains sufficient documentation for a user to interact with your updated version of Covey.Town.
• The documentation covers all steps that the user would need to take to exercise all of your user stories.
• Screenshots are included that capture the key interactions between a user and your new feature.
• Course staff were able to follow these instructions to successfully interact with your project implementation.
• The section is at most 4 pages (roughly 2,000 words maximum), NOT including figures. Fewer pages are absolutely acceptable, consider this a rough limit

Meets minimum requirements:

• The Feature contains documentation for a user to interact with your updated version of Covey.Town, but perhaps does not fully describe how.
• The documentation includes at least one or two screenshots, but screenshots do not capture interactions with all of the user stories.
• The course staff were able to figure out how to use it through trial and error.
• The section is at most 4 pages, NOT including figures. Fewer pages are absolutely acceptable, consider this a rough limit

7.5% Report - Technical Overview

Satisfactory:

• Technical Overview contains a description of any substantive changes to the existing Covey.Town codebase, and of the architecture of your new code.
• It uses UML diagrams, CRC cards, state diagrams or any of the other techniques that help describe the structure.
• It provides a well-reasoned rationale for why this is the “right” design.
• The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit)

  Meets minimum requirements:

• Technical Overview includes a description of all major changes to the code compared to our existing Covey.Town codebase.
• The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit)

7.5% Process Overview

Satisfactory:

• Process overview contains a detailed description of the manner in which agile project management processes were used during the project (i.e., sprints, sprint reviews, retrospectives and blameless reviews).
• It provides a summary of what was planned to happen in each sprint vs what actually happened, with a discussion of what was revised as a result.
• The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit)

Meets minimum requirements:

• It provides a summary of what was planned to happen in each sprint vs what actually happened, with a discussion of what was revised as a result.
• The document is at most 2 pages (fewer pages are absolutely acceptable, consider this a rough limit)

10% Final Demonstration

Each team will be required to demonstrate their feature to their classmates and to the instructor(s) and TA(s) on the last day of class.

Select projects may be hosted in a project showcase. Here are the projects from Spring 2022 project showcase.

Satisfactory:

• Demo is functional on the final day of class and is consistent with the project as described in the rest of your final submission

Meets minimum requirements:

• Demo is functional on the final day of class and is mostly consistent with the project as described in the rest of your final submission

Resubmission After the Final Demo

Sometimes, project teams can’t quite finish everything they’ve promised by the time of the final demonstration on the last day of class. It’s better to deliver a feature late than never deliver it, so if you find yourself in this situation, you’re permitted to continue working on your project and resubmit your project materials and do another demo for the instructor and your project mentor.

If your team is in this situation, you must:

• On the same day as the final demo (i.e., the last day of class), send an email to the instructor, your project mentor TA, and your teammates declaring that you intend to resubmit. Each of your teammates must respond by this deadline indicating that they agree that a resubmission is appropriate.
• In writing (email is fine), declare exactly which feature(s) or user stor(ies) you will complete by the resubmission deadline. This email must be received by the instructor and TAs no later than 72 hours after the deadline for your initial email declaring your intention to resubmit (i.e., it must be received no more than 3 days later, AoE, than the last day of class).
• You must schedule a meeting with your project mentor and the instructor before the class’ final exam (note: day of the final exam is not acceptable) to re-demonstrate your feature. The deadline for scheduling this demo is the same as the deadline for providing the scope of work email (see previous bullet point): no more than 3 days after the last day of class. Note that the instructor generally does not check email on the weekend.

The consequences of choosing to resubmit are:

• you will not receive your final grades on your project materials until after your resubmission demo.
• you must resubmit all project deliverables before your rescheduled demo.
• you will be held to a higher standard on all project materials, since your team will have extra time to polish them.
• your final grades on all materials will be evenly split between the grade you would have received on your original submission and the grade you receive on your resubmission. Additionally, a 5% late penalty is automatically applied to your resubmission. A further 5% penalty is applied if, in the view of the instructor, your resubmission does not substantially improve on your original submission. Do not resubmit unless your work was substantially incomplete at the regular deadline: these policies mean that resubmitting is only a good idea if your project would otherwise be graded poorly.

Individual Reflection

Accompanying the final team deliverable will be an individual reflection, which every student must submit on their own. Satisfactory completion of all parts of this reflection is required to receive an “A” grade in the course, and may be used to calibrate project scores across multiple team members. The individual reflection also provides an opportunity for students to provide confidential feedback on the performance of their teammates.

Project Concept

Reflect on the evolution of your project concept: How does the project that you delivered compare to what you originally planned to deliver? What caused these deviations?

Satisfactory:

• Is at least 2 paragraphs long;
• Includes at least 1 paragraph describing all variances from original project concept;
• Includes at least 1 paragraph of personal reflection on the cause of any variances from the project concept.

Project Process

Reflect on the evolution of your development process: How did the process by which you designed and implemented evolve from your original project plan? Were there any processes that in hindsight, you wish that you followed, or wish that you followed better?

Satisfactory:

• Is at least 2 paragraphs long;
• Includes at least 1 paragraph describing all variances from the software development processes envisioned in your original project plan;
• Includes at least 1 paragraph describing software processes (described in class or not) that you wish you had followed, or wish you had followed better, supported by evidence from your personal experience working on the project.

Project Team

Reflect on your team dynamic: Provide a frank (and ideally, blameless) postmortem of your and your teammates collaborative performance and participation. If you had to do this same project over with the same teammates, what would you have done differently (or not) to improve your team’s overall performance? Do you think that each of your teammates are deserving of the same grade as you?

Satisfactory:

• Is at least 2 paragraphs long;
• Includes at least 1 paragraph reflecting on your own performance as a team member on this project, including what you would have done differently, given what you know now;
• Includes at least 1 paragraph reflecting on your overall team dynamic, including strengths and weaknesses. Reflect on how you might have organized your team differently given what you know now.