You've worked iteratively (formative) on your product and finish with an oral test (summative). You'll show the feature you've created for back-end based on your code in your repository 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.
- Make sure your webcam, microphone and screen sharing works in MS Teams
- Have the latest version of your feature ready in your browser.
- Have the latest version of your code 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鈥檚 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.
Download a .pdf version of the Rubric
| 1-2 | 3-4 | 5-6 | 7-8 | 9-10 | |
|---|---|---|---|---|---|
| Application | Node, Npm, Express, templating are used; the web server runs without errors | Data is read from, removed from, and created on the server; users can input and retrieve data | Data stored in MongoDB is changed (find and update) in the database through the web app | Special care was taken to create a performant or secure web app and database; the web app is deployed | The way the student applies npm, databases, and Node is more advanced than what they were taught in class |
| Understanding | There is substantial own code; the student can explain the code that exists | The student can explain some parts of their code, how some parts works together, and tech stack | The student can explain every part of their code, how everything works together | The project is complex but still understandable; the student carefully chose every part of their stack | A nerdy conversation can be held; the student can make live changes, explain why software is used instead of alternatives |
| Quality | The project is handed in documented, on time, working without technical problems, and on GitHub | The code is readable, consistent and the code, project, and process are partially documented | Code adheres to standards; docs cover the process and what the project is and does | Code quality is good and enforced; docs are more than useful and professional | 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鈥檚 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鈥檛 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.