Merge pull request #30 from neu-se/project-deliverables

updated instructions for final delivery

Assignments/project-deliverable.md

@@ -0,0 +1,48 @@
+---
+layout: page
+title: Project Final Deliverable
+permalink: /assignments/project-deliverable
+parent: Assignments
+nav_order: 6
+---
+# Project: Final Deliverable **Due Wednesday 11/29/2023 11am ET**{: .label .label-red }
+The final project deliverable is the implementation, available in github and deployed on Netlify and Heroku or render.com, and the documentation turned in to Canvas. It also includes poster and/or demos.
+
+## 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. You will submit the link of your hosted app on Canvas.
+
+### Contents
+
+Your final team deliverable will include:
+* The implementation of your new feature, deployed to Netlify + Heroku
+* Automated tests for your new feature
+* A report that describes how to use your new feature
+* A poster and/or demo presentation
+
+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, on the software engineering processes you used, and on your team's dynamics and collaboration.
+
+
+### Submission Instructions
+
+#### Code, documentation and Link
+ All apps will be deployed on Netlify and Heroku / Render (instructions for CI/CD pipeline setup are provided under Tutorials). After you have pushed all of your code (and documentation) to your team's GitHub repository, create [a release](https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/managing-releases-in-a-repository) 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 (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" along with the link of your hosted app (in comments or a text file). Submit your report separately to Canvas, under the assignment "Project: Report".
+
+#### Project Poster & Demo
+Each team will submit a poster. Your poster will be a single-page document, that will include the following aspects:
+
+* Short description of the project (OK to reuse text from the project plan/report)
+* Link to public demo site, link to source repo (OK to make the repo public now, or OK to leave as private)
+* Short description of the technology stack and overall design decisions
+* Short description of future work that could build on your project - additional features that you think could be interesting, or ideas for refactoring the code.
+* Screenshots of the feature, visually demonstrating the main functionality that you implemented.
+
+We've created a [sample poster for the "Conversation Areas" feature]({{ site.baseurl }}{% link Examples/conversation-areas-poster.pdf %}), which you might find useful in deciding how to format your poster. It's fine to use a different aspect ratio (e.g. portrait instead of landscape), and there are no specific requirements for font size or amount of text. Please try to create a document that you feel represents your project, imagine your target audience as a recruiter for a software engineering role: your goal is to demonstrate that you have some experience working on some non-trivial software engineering project.
+
+In addition, some sections will have live (in-person) demos and others may ask you to record a demo video. Details for project demos and/presentations will be provided during class by each instructor (and may vary from section to section). **Posters and/or demo videos and/or presentations will be submitted on Canvas**, under the assignment "Project: Poster / Demo".
+
+#### Individual Reflection
+Create a PDF of your reflection, and submit it to Canvas, under the assignment "Project: Individual Reflection". 
+
+## Grading
+
+Details on grading may be found at [Project Grading]({{ site.baseurl }}{% link Assignments/project-grading.md %})

Assignments/project-grading.md

@@ -0,0 +1,170 @@
+---
+layout: page
+title: Final Project Grading
+permalink: /assignments/project-grading
+parent: Assignments
+nav_order: 7
+---
+# Grading
+Each project will be graded by the team's assigned TA mentor and the instructor. 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. Rubric for remaining components will be provided by individual instructors. 
+
+### Adjustments in project scope
+We are hopeful that all teams will deliver all essential and desired features proposed in their revised project plans. However, it is possible that there might be some minor deviations from the origional plan - in the five-week 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 TA regarding their project status may have the opportunity to request variances to their project scope. 
+
+### Individual Contributions to the project
+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. In the event that a group member does not contribute at all to the project, student might receive 0. We will evaluate each individual's contribution on the basis of a variety of factors, including progress reports at weekly meetings, 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 
+
+From [Project Overview]({{ site.baseurl }}{% link Assignments/project-overview.md %})
+
+* Planning (20%)
+  * This includes the Preliminary Project Plan and the Revised Project Plan.
+* Process (20%)
+  * This includes: use of a structured development process, including code reviews,  timely completion of sprint progress reports and individual/team surveys, and weekly meetings with TA Mentor.
+  * This also includes appropriate division of labor within the project.  For full credit, each member of the team must have at least 4 commits in the final delivered code.
+* Product (40%)
+  * 20% Successful delivery of your Minimum Viable Product as defined in your project plan
+  * 10% Additional desirable features
+  * 10% Test suite of your features.
+* Reports (20%)
+  * 10% Final Report
+  * 10% Poster and Demo
+
+This adds up to 100%; this sum is worth 40% of the course grade.
+
+## Detailed Rubrics
+Here are the detailed rubrics for the final deliverables:
+
+### Minimum Viable Product (20%) 
+### Additional Desirable Features (10%)
+We will grade each of these using the following rubric:
+
+#### 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 is deployed to a publicly-accessible URL, using Netlify and Heroku and/or Render.com for hosting (or as per deployement instructions provided).
+* 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 is deployed to a publicly-accessible URL, uusing Netlify and Heroku for hosting (or as per deployement instructions provided).
+* The implementation may have some obvious flaws, but largely works without crashing.
+* Implemented feature does not include any eslint-disable or ts-ignore flag
+
+### Testing (10%)
+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
+
+### Process (20%)
+The Process grade includes: use of a structured development process, including code reviews, timely completion of sprint progress reports/retrospectives, individual/team surveys, peer evaluations and weekly meetings with TA Mentor (for Week 6, 8, 10-14). It also includes appropriate division of labor within the project. For full credit, each member of the team must have at least 4 commits in the final delivered code. 
+* Ongoing development progress including code reviews, github commits, etc. count 10% of the grade
+* Peer evaluations, TA meeting, submission of surveys/reports counts 10% of the project grade. 
+These items will be evaluated using the rubrics below. 
+
+#### 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. Teams are expected to merge their developvemeent branches to main only after code review. 
+* 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
+* The team meets regularly with the TA mentor.  All or most members attend all meetings. Members who are absent from a TA Meeting send an excuse in advance.
+* Progress reports and other weekly reports and surveys are submitted in a timely fashion, not filled in later.
+* TA Meetings include demos or other evidence of progress.
+
+#### 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
+* Attendance at TA meetings may be irregular, but enough to give the TA a sense of the the team's progress.
+
+#### Individual grading for Process component
+Team members with unexcused absences from TA Meetings, or with fewer than 4 commits during the lifespan of the project, may receive a lowered grade for the Process component. 
+
+### Final Report (10%)
+The final report should consist of three sections:
+* Feature Overview and User Manual
+* Technical Overview
+* Process Overview
+
+The allocation of the 10% credit will be announced later.
+
+### * Feature Overview and User Manual
+
+#### Satisfactory:
+* The Feature section contains sufficient documentation for a user to build and interact with your updated version of Covey.Town.
+  * The documentation covers all the steps that a user would need to build a working version of your project.
+  * The documentation includes a link to the deployed version of your project
+* 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
+
+### * 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 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) 
+
+### * 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) 
+
+### Posters and Demo (10%)
+Each team will be required to submit a poster. In addition, some sections may have a demo (live in-person, via zoom or by recorded video). Each instructor will provide details regarding expectations for the demo and/or presentation. The schedule and manner of these demos might also vary from section to section.
+
+Select projects may be hosted in our project showcase. Here are selected projects from Fall 2022 [project showcase](https://neu-se.github.io/CS4530-Fall-2022/assignments/project-showcase).
+
+## 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.

_data/modules.yml

@@ -103,7 +103,7 @@ tp3:
 tp4:
   name: Project Final Deliverable
   type: deadline
-  page: 
+  page: /assignments/project-deliverable
 veteransday:
   name: Veteran's Day (No class)
   type: holiday