CS184 Project Schedule and Assessment

Dates:

• Posted: 11/20/2023

Changelog:

Project Milestones

• Friday, December 8: Code Freeze (release tag on github repo). Last edits (documentation and cosmetics) possible until Tuesday December 12.
  
  
• Monday, December 11, 4-7pm: Presentation during "Final Exam Slot". Present the functionality and design process (10-minute team presentation including Q&A).
 

• Tuesday, December 12, 11:59pm: Submit final project materials and documentation:
  
  
• Complete code for your project. You can use any publicly available libraries / code / artwork / materials as long as you correctly acknowledge all sources.
  
  
• Manual for your product. Document that describes how the product is to be used. Please make use of screen shots here to document all functionality.
  
  
• "Design Document": Documentation of your programming effort and your design process. This should be a separate document, giving an overview of the different steps you went through and presenting all documentation materials you produced on the way. This may include:

• Documentation of the different stages of your design (with additional material, e.g. sketches, mockups, questionnaires, etc.)
• A section summarizing important team decisions since the start of the project, referring to meetings logged in your GitHub repo
• All external resources you used / consulted for your project.
• Any difficulties you encountered and how you addressed them.
• (Not required, but seen as a plus:) Evaluation/Testing results (qualitative, quantitative). There could be a description on when and how testing took place, and a presentation of the results. 
  

Project Assessment/Grading

Both, group and individual projects will be ranked by the teaching team using the methodology explained in class: Each teaching team member (TAs, Reader, and Professor) will group each project into quartiles (top tier, middle upper tier, middle lower tier, bottom tier) along each of these seven dimensions:

1. Idea and Idea Refinement
2. Presentation (group projects only)
3. Functionality/Quality
4. Technical Difficulty Implemented
5. Implementation
6. Design Process
7. Manual

For cross-checking only, we will also group each project into quartiles on overall impression, before we calculate the overall weighted average ranking. We will discuss and resolve any discrepencies that occur between these two ways of ranking, but the weighted average ranking is the main driver.

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

Group Project:

• 05% Idea, and Idea Refinement
• 15% Presentation
• 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 code, structure, github organization, ...
  • use the README.md to make clear the repository structure and guide through implementation effort!
• 15% Design Process
  • judged by design document (which can reference meeting logs, possibly Kanban Board, 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.

Additional Notes:

Presentation and live Q&A for all group 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.

Our overall assessment process will be a holistic review of the team’s final product, including all submitted materials, documents, and the source code.

Various factors (generic list, applicability to CS184 may vary) may include:

• Idea, and Idea Refinement
  • Novelty and uniqueness
  • Potential for impact
  • Process of agile idea refinement (pivoting)
• Presentation
• Prepared Presentation: Clarity and content of presentation
• Question and Answer session: Clarity and content of answers
• 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 a user 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/individual take on a challenging problem or a very simple one (relative to team/individual expertise/background)
  • Were there technical roadblocks that were tackled instead of avoided?
• Implementation
  • Review of Code
    • Github organization and use
    • Code structure, relative to established norms (e.g. Android Studio, IOS, Flutter, ReactNative, Unity...)
    • 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
  • Quality of Design Document itself
  • Planned, Iterated and Implemented Software Architecture
  • UI Design, Implementation, and Testing
  • For groups:
    • Documented team leadership, meetings, and interactions (Scrum)
    • Collaboration and Project Management
• 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