“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.
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% |
You are expected to show up to class, and work with your team on your project.
We will have short (15 mins) weekly quizzes in Learn. The format will be multiple-choice and short-answer style questions.
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% |
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:
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:
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:
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.
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”:
Your parents and/or partner and/or teammates don’t count. Convince me to buy a license and get an A+. ↩︎