#Grading Notes

The grading schemes for project components are stored Learn under Resources > Rubrics. These notes supplement the marking scheme (and in the case of a discrepency, the rubric takes precedence).

The purpose of this component is to make sure that your GitLab repo is setup correctly. If you follow instructions carefully, you should receive full-marks.

TAs: Teams that follow instructions should receive full marks. I would hope that everyone would get this right!

If there is one key point that you need to absorb, is that software design should be purposeful. A successful application is one which solves a particular problem for a user. The better you understand your users, and their environment, the better your design will be.

This component is measuring if we think you have done that adequately. The documents (and requirements) are just your articulation of this understanding.

You should known what you want to build. Have you thought about how to structure it? Notice that each of the criteria awards marks for "clearly identifying" what you know, but also identifying what you don't know.

TAs: We award full marks for anticipating design issues (with a realized design document). Teams should only lose marks for failing to discussone of the criteria, or having a particularly poor answer. Partial answers are fine at this stage.

Software releases are your deliverables at the end of each sprint. There are a few marks for the demo, but the grade is mainly about following process and producing a quality release. Things that are in the guidelines that you should consider:

• The goal of a software release is to have a stable and well-documented release.
• You should be able to hand a software release to a customer to use.
• The number of features included in a release is secondary to quality and completeness. You are better off with a smaller number of features fully completed (as compared to a large number of half-finished features).
• Your demo should reflect what you submit! Avoid showing up with something half-done; you cannot get much feedback based on that.

TAs: Score based on this criteria. We want increemental development and improvement of course, but the release should always meet quality goals.

The final release is the culmination of everything you've done all term. Your GitLab project should be well-structured, easy to follow, and accessible.

Your TA and instructor:

• We should be able to review all project documentation easily, and know what you completed (and what you deferred). Make sure your GitLab issues are up-to-date and reflected in the documentation.
• Installation instructions should be complete! We should be able to setup, install and run your application from the instructions.
  • You should tell us which device to use for testing. If you don't specify, we'll just use whatever we have preinstalled.

Other developers:

• If you were building this for an employer, it's possible that someone else might need to work on the project.
• You might open source it, in which case you want people to be able to fork the project, and extend it.
• Could another developer understand your design, make changes to your code, build and deploy it without any additional help? Is the documentation sufficient?

Potential users:

• Would potential users with no prior experience be able to understand what your product does?
• Are the instructions sufficient? Could they install it?

TAs: Grade documentation with these questions in-mind.

Also, you need to have followed guidelines provided in-class.

• You should have a layered architecture (or a clean architecture). This should be obvious from the way that your source code is structured.
• You should have unit tests, passing.

TAs: Open the project and review the code structure. There should be modules or packages splitting code into obvious layers e.g., view - viewModel - model, or something comparable. There should also be obvious unit tests (in folders that mirror the source code structure) which can be run, are reasonable comprehensive, and pass correctly.

Finally, we have a qualitative grade. Your TA has provided you with feedback all term, on ways to improve your application's design. You get top-marks for listening, encorporating feedback and iterating to improve your design over the term.

TAs: Pretend you're a user. How impressed are you with the design, the fit-and-polish of the application? Imagine you have the choice of buying this - would you pay for it?

You need to grade the project, project artifacts (e.g., documentation), as well as the software release. As with previous deliverables, you should grade directly in the Learn Dropbox named M7 Final Release.

I'd suggest the following:

1. Review the installation instructions from the project page. Follow them to run and test the application. Test functionality at this time.
2. Review the remaining project documentation from the project wiki. Check that issues are complete and closed and that the project is properly documented.
3. Check the code. git clone the project and run gradlew build to confirm that it builds. Review code structure etc.

Most teams will have built their application against a specific AVD-device. You should be running and testing on the same device that they used. They should have included these details in the installation instructions.

When grading, please make sure to provide written feedback for each section. Grade everything first, but do not publish until we have coordinated it.