Assessment

“Good grades for honest effort.” – Anonymous

Your grade is determined by both personal and team components. To get a good grade in the course, you need to actively participate and contribute at every step; the final deliverable only counts for part of your grade.

Personal Components (15%)

Starting in the second week, there will be weekly quizzes on Learn. These must be done individually.

Item Calculated %
Participation in team meetings 5% - 1% for each missed meeting 5%
Weekly quizzes (weeks 3-13, exclude reading week) 10 quizzes x 1% each 10%

Participation

You are expected to show up to class, and work with your team on your project.

  • Your team is expected to write meeting minutes every class. This will include tracking attendance.
  • Failure to show up to team meetings results in a 1% deduction per incident (max 5%).

Weekly Quizzes

We will have short (15 mins) weekly quizzes in Learn. The format will be multiple-choice and short-answer style questions.

  • You may write them anytime in the week when they are posted, and you have until that Friday 11:59 PM to submit them. Failure to submit results in a zero for that quiz.
  • Quizzes can include any video lecture content, up to and including the week when the quiz is posted.
  • Quizzes are open-book, meaning that you can use course notes when answering questions. You may not communicate with anyone else or disclose information about the quizzes to anyone else in the course. You agree to not record or disclose quiz contents to any third-party (including but not limited to Chegg.com and similar sites).

Team Components (85%)

In this course, you are assessed on the quality of your project, but also on your ability to work together as a team to reach milestones. Everyone on the team is expected to contribute to each project deliverable, and will receive the same grade for each component.

Item Calculated %
Design Review Requirements; architecture diagrams; prototype 15%
Sprint 1 Demo Application walkthrough; features 20%
Sprint 2 Demo Application walkthrough; features 20%
Sprint 3 Demo Service walkthrough; features 20%
Final Submission Final submission including source code, installers 10%

Design Review

This is a short presentation where your team presents their preliminary work. The templates section contains design review guidelines and the design review checklist that we use in grading.

In general, you should address:

  • Background of the problem (what it is, who uses it, comparable products)
  • Users (who they are, how they are likely going to use the product)
  • Requirements (description of the key features that you are prioritizing)
  • Application architecture (diagram showing the physical and logical structure, high level)
  • Project plan (Gantt chart, resources identified)

Sprint Demos

Every sprint concludes with a demo to the course staff of what you’ve accomplished during that sprint. You will be expected to show what you intended to achieve, what you accomplished and demo the result to course staff (where we take on the roles of instructors and customers). The templates section contains sprint demo guidelines and the sprint demo checklist that we use when grading.

You will be assessed based on:

  • your ability to prioritize and schedule features appropriately.
  • completing what you intended to complete.
  • writing unit tests and ensuring code quality.
  • delivering working, well-designed functionality.

Final Submission

You will need to produce a project summary, produced in in the Wiki of your GitLab project. Your wiki should contain the following at a minimum:

  • A readme.md file that either contains the landing page for the wiki, or redirects the user to the top-level of the wiki.
  • Your team number and names of team members clearly displayed.
  • A screenshot of your application.
  • Instructions on how to use your application e.g. keyboard shortcuts for features.
  • Pages for each of the major project stages: Requirements, Analysis & Design, Implementation and Testing. These should explain your strategy, and very high-level approach taken for each stage. As noted in the template, these sections should br relatively short (e.g. 3-4 paragraphs for each, maybe a diagram).
  • Sprint release pages, where you list the goal of each sprint, and the major features completed. Ideally, you would have release notes and installers for each sprint. Minimally, you need an installer and release notes for the final sprint.
  • Ackowledgement of any third-party libraries or code that you have used.
  • A clear statement of how your source code is licensed. Either include a separate license file, or have a link to the actual license online from your readme.
  • Anything else that you think would make your project stand out!

Look at GitHub for inspiration - there’s lots of great examples, like this one.

For a more tailored example, see the CS 346 Template repository. It demonstrates how you could structure your documentation for this course, and the low-level pages contain questions and suggestions on what to include.

Also, you can review the CS 398 Final Submission checklist that we’ll use for grading.

Grade Guidelines

As a very rough guideline, you might expect project grades to be awarded based on how well you complete the objectives:

Work completed Grade assigned
Most demos incomplete; core features missing or no working product was produced. F
Some demos were incomplete; some core features are done, but many features are missing. Very buggy, probably crashes. Deep in your soul, you would be forever disappointed. D
Demos were all completed and the listed requirements are mostly complete. No additional features were identified, designed or developed. Maybe you ran out of time, or didn’t meet as often as you should have. You will show this to your friends, and they will make non-commital statments about how “interesting” it was. Maybe you’ll finish it one day. Maybe. C
Demos complete. Listed requirements complete; some additional non-trivial features identified and completed! You would be proud to show this to your parents, or put it on your resume. Your team jelled and you did a solid job! Way to go! B
Demos complete. Listed requirements complete; many non-trivial features completed, or exceptionally complex features implemented. This is a commercial-quality application! You could sell this on the Google Play store, if your team can ever agree on how to split the royalties. Show this to get a fast-pass to Cali and your dream job! A

Things that will help you get an “A”:

  • Deliver exceptional features, comparable to a commercial product.
  • Deliver successfully on multiple platforms (e.g. desktop + mobile) or multiple application styles (e.g. console + graphical).
  • Spend considerable time on design, and impress both the TAs and the instructor.
  • Publish to an App Store. Convince someone to buy a license1.
  • Win an Apple Design Award.

  1. Your parents and/or partner and/or teammates don’t count. Convince me to buy a license and get an A+. ↩︎