You've worked iteratively (formative) on your job story and finish with an oral test (summative). You'll show the research (wiki) and feature you've created for project-tech based on your code in your repository, documentation in the wiki and live version. A teacher will try out your feature and look at the code.
You will show you can create a quality project in which you apply the subject matter of this course and that you understand it. You will answer questions in such a way as to demonstrate sufficient knowledge of our goals.
This is an individual assessment, so tests will be conducted between one teacher and one student.
This is an assessment, not another moment for feedback. So you will be graded. There isn't much time for additional feedback or troubleshooting technical issues.
Since we have limited time make sure you come to the assessment prepared:
- Bring your computer and make sure it's charged and connected to Wifi.
- Have the live version of your feature ready in your browser.
- Have the latest version of your code and wiki ready on GitHub.
- Have the latest version of your code ready in your editor.
Make sure your repository stays online after the assessment is finished, we might want to check the code handed in on GitHub after the assessment. We also want to download and archive your project when it’s done.
Use the peer review document as a checklist (AVV) for your assessments to check if everything in your repository and application is in order.
| Conditions |
|---|
| Source code is publicly available on GitHub in a repository |
The project is documented in the wiki and has a readme.md |
Cites the sources used; APA style in readme.md |
| Live version of the application is deployed |
| 1-2 | 3-4 | 5-6 | 7-8 | 9-10 | |
|---|---|---|---|---|---|
| Concept | There is no concept and idea on what to build | You've written a job story and there is a concept but it's vague and lacks specificity, you didn't research other matching application features | You've written a good job story, there is a clear concept and there are wireframes, wireflows and a requirements list | You've designed your interface and there is a clear direction for the look & feel of your application | You've extensively designed your interface and thought of edge cases and different states, user experience is optimal and the flow of the application feels natural |
| Research | There is no technical research in the wiki | There is some technical research in the wiki but not every topic covered in class is thoroughly covered, there is no argumentation on why specific technology was picked | You researched technical terms and concepts related to your matching application that are covered in class and documented them clearly in you wiki, there is argumentation on why specific technology is chosen. | You described more advanced technical research in the wiki, you clearly explain choices you made and can offer alternatives for chosen technology. | The documentation reads like a great books and a nerdy conversation can be held about the technology used in the project. |
| Application | The feature doesn't work technically | The feature partially works but is not complete. The project gives errors and warnings, the flow is incomplete from a user point of view. | The feature technically completely works and is usable from a user experience point of view. Core functionality works and the application has a solid flow trough screens. The interface is designed. | The feature is technically advanced and complex. The interface is well designed and has additional interactions and feedback. | The user experience is fantastic and the feature is complex. You took special care of your interface and your user. You've basically created multiple features. |
| Quality | The project and process isn't on GitHub and undocumented | The project and process are partially documented, the repo contains unneccessary files and isn't structured | Code adheres to standards by using linters and formatters, docs (readme.md and wiki) cover the process and what the project is and does | Code quality is consistent and enforced; docs are more than useful and professional. The project is set-up in a modular way. | Code and docs both read like great books and the project is structured logically. |
Note:
You'll need a > 5.5 for each row to pass: you can't compensate between rows.
Each of this rubric’s rows is cumulative: for example, to get a 5-6 on concept, you also need to have a 1-2 and 3-4.
- A teacher can refuse to take the assessment when you show up late regardless of the reason. That means you go straight to the re-sits and will be graded with a
1.0. Usually teachers give you a small window of time after the assessment(~5 minutes) to show up. - We don’t like plagiarism and report it to our assessment committee (examencommissie in Dutch).
- Grades will be published and communicated trough MS Teams and Brightspace. We also publish grade lists on Brightspace based on student numbers.