project : Final Presentations

num	ready?	description	exam date
project	true	Final Presentations	Mon 12/06 04:00PM

Final Presentations

4pm to 7pm, Monday December 6th (original finals slot)

Here is the point percentage breakdown for grading that the teaching team plans to use for the “Final Product” 40% of the course grade.

• 15% Presentation
• 5% Idea, and Idea Refinement
• 25% Functionality, Quality (Reliability & Polish)
  • judged by review of demonstration, user manual, peer review, teaching team testing
• 10% Technical Difficulty Implemented
  • judged by review of code/scope taking into account team background/experience etc.
• 20% Implementation
  • judged by review of Github code, PRs, etc.
  • use the README.md to make clear the repository structure and guide through implementation effort!
• 15% Design Process
  • judged by Design Document, Kanban Board, Meeting Logs, Github TEAM information, etc. Design Document should steer through the process.
• 10% Manual

We will cross-reference against a ranking obtained from an overall quartiling judgment averaged among the evaluators.

Each group will have up to 10 minutes for a prepared presentation.

This will be followed by up-to 5 minutes of live exploration of the app by the teaching team, including questions. Each member of the group should be available for the question session.

The ten minute presentation should include a demo (functionality, similar in style to what was done in the MVP video), as well as some discussion of technical matters and design process.

Example technical matters to cover:

• Authorization and Authentication (if applicable)
• Database technologies used (if applicable)
• External APIs or libraries used (if applicable)
• Setup needed for app (configuration to get up a running instance.)
• Optional: Testing strategies (unit test, integration test, end-to-end tests). Since this wasn’t a major focus point in this course, solid testing strategies are simply a bonus this quarter.

Additional Notes:

• Presentation and live Q&A for all projects will be recorded for later re-review by the teaching team. The recording will only be viewed by course staff for purposes of evaluation.

The final presentation will be part of a holistic review of the team’s final product, including the presentation, as well as the team’s production implementation, and the code in its repo.

Various factors will include:

• Presentation
  • Prepared Presentation: Clarity and content of presentation
  • Question and Answer session: Clarity and content of answers
• Idea, and Idea Refinement
  • Novelty and uniqueness
  • Potential for impact
  • Process of agile idea refinement (pivoting)
• Functionality, Quality (Reliability & Polish)
  • Suitability for purpose: How well does the app address the user’s needs?
  • How powerful is the provided toolset (how much I can do toward the problem solution)?
  • How elegant is the provided toolset (sometimes, simplicity is a plus)?
  • User Interface:
    • Is the user interface easy to use, or challenging to figure out?
    • Is the user interface consistent? (e.g. user interface elements are nicely aligned rather than weirdly and haphazardly placed on the screen.)
    • Is the user interface pleasing to the eye?
• Technical Difficulty Implemented
  • Did the group take on a challenging problem or a very simple one (relative to team expertise/background)
  • Were there technical roadblocks that were tackled instead of avoided?
• Implementation
  • Review of Code
    • Github organization
    • Github commits, pull requests
    • Does the code have a clear structure?
    • Is the code DRY (Don’t Repeat Yourself) rather than WET (Write Everything Twice)?
    • Are names (variables,functions,components,methods,classes) clear and appropriate?
  • Testing Strategies (this wasn’t a required focus this quarter):
    • Is there a documented test strategy linked to from the README.md file?
    • Does the test strategy include unit, integration and end-to-end testing?
    • How extensive is the test coverage?
• Design Process
  • Planned, Iterated and Implemented Software Architecture
  • Documented team leadership, meetings, and interactions (Scrum)
  • Coding Process
    • Kanban Board history
    • How often do issues have clear acceptance criteria and user stories?
    • How often are PRs linked to issues and vice-versa?
    • Are the explanation in PRs clear?
    • Are the commit messages clear?
  • UI Design, Implementation, and Testing
  • Quality of Design Document itself
• Manual
  • Effectiveness (does it get the main points across, is it well structured)
  • Clarity of how to use the product
  • Attractiveness of the document itself