These are the guidelines used to evaluate submissions in SWEA.
Please report to Henrik any issues you may find!
The basic focus of any course is for students to learn something. But what?
For each mandatory exercise, I will make explicit what the learning focus is in the form of a couple of learning goals. For each learning goal, I will shortly outline what I expect you to deliver.
Example:
TDD Process: Code is written 'test-first'; TDD Rhythm is followed (and referred to in screencast); TDD Principles are applied (and referred to); TDD values are used (and referred to); code is cleaned up (and referred to).
Here, the learning goal is for you to use the TDD process in your development. The TA's will be looking for aspects in your screencast and your code that clearly demonstrate that you have done so, like that your screencast shows you have code is written 'test-first'; that you follow the TDD rhythm; etc.
The teaching assistens will for each learning goal make an assessment of your submission, give a grade, and provide a short argument for their findings.
For each learning goal, your submission will be evaluated on coverage of the learning goal and proficiency at the learning goal. This is completely similar to the way the normal Danish grade scale shall be used.
Coverage: How much of the learning goals are covered by your work? Example: If you do a TDD iteration and only mention and use the "Isolated Test" principle and there is obvious other TDD principles that would be beneficial to use, you score low on coverage.
Proficiency: How well do you apply the learning goals? This boils down to how many and how severe errors you make. Example: If your test code contains complex language structures (while loops, nested ifs, recursive calls, ...) or your 'expected values' are all magic constants with no explanation, you are not proficient in using 'Evident Test' and 'Evident Data'.
The grade scale is a downsized version of our normal Danish 7-level grade scale.
Late hand-ins are automatically graded with 0 points unless you have been given permission to hand-in late by your TA!
You do not learn much by just being whacked over the head. Also, you cannot focus your learning if you get 67 points in the code that must be fixed to get your submission approved.
Therefore I will ask TAs to make an overall assessment of your submission, and prioritize the 2-3 most areas that needs to addressed and worked upon to improved in the next iteration (or in the re-handin.)
Focus on these key improvement areas!
To make things easier and more consistent for TAs and you, I have designed an assessment sheet that we will try out. It is basically just an excel spreadsheet.
Here is a hypothetical example:
First, the submission guidelines have been kept (notably that 'gradle test jacocoTestReport' passes all tests!) so that is just OK.
Next, for each learning goal mentioned on the mandatory exercise evaluation criteria an assessment has been made (unacceptable, adequate, good, excellent) and a short argumentation provided. Finally three prioritized areas of improvement are outlined.
The sheet automatically calculates a score which will also appear as the score in Brighspace.