pt-course-18-19
Oral Test - Team
You鈥檝e worked iteratively (formative) on your product and finish with an oral test (summative) where you present your final project with your team. First you鈥檒l present the whole project as a team, then you鈥檒l show how you contributed to the project and explain if you reached your own goals you鈥檝e set at the beginning of the project. 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.
Preperation
Presenting your work is a skill all by itself, make sure you prepare yourself properly. The best way is to treat it as public speaking and there are many books on public speaking available.
- Bring your own computer and a charger.
- Have the latest version of your code ready in your editor.
- Open up your docs inside of your GitHub repository.
- Have a live version up and running.
Make sure your repository stays online after the oral test is finished, we might want to check the code handed in on GitHub after the test. We also want to download and archive your project when it鈥檚 done.
Rubic
Rubic assessment group part
| 1-2 | 3-4 | 5-6 | 7-8 | 9-10 | |
|---|---|---|---|---|---|
| Review | The student lacks clarity in coding skills and does not show relevant decision making in the code. The code needs a big update or a complete makeover. | The student does reflect on the quality of the (group product) code with help of others. The student identifies some coding-conflicts and explains the reviewing process in a general way. The student can not specify what his/her coding-contribution to the teamwork has been. The student can explain his/her own quality in coding with help of others. Keep on going! | The student reflects on the quality of the (group product) code in an independent way. The quality of the code is explained in a basic manner. The student can specify a couple of conflicts that have been resolved during the teamwork. The student grasps his/her coding contribution to the teamwork and explains his/her own quality in coding in basic terms. Good job! | The student reflects on the quality of the (group product) code and independently explains the quality of that code in a thorough manner. The student specifies multiple complex conflicts that he/she resolved during the teamwork and explains the most important steps during this reviewing process. The student explains his/her own quality in coding in a refined manner and shows talent for coding. Decent coding skills! |
馃槺 The student is self-taught and shows talent for coding and easily runs through the group product, taking all aspects of code reviewing and user/system testing to the next level in a clear and consistent way. Going for Pro! |
| Collaboration | The student identifies unrelated practices to explain his/her collaborative skills, and can not show an active contribution to the coding-community. User/system testing has been executed by the team and the student draws unsupported conclusions. The Github workflow is explained inconsistently. Let鈥檚 sit down and talk! | The student shows practices (coding issues, conflict) and explain his/her collaborative skills with help of others. The student needs to be stimulated to seek for support for reviewing code by the coder-community. User/system testing has been executed by the team and the student draws simple conclusions. The Github workflow is explained in a inconsistent manner. There are not right or wrong questions: ask for help! | The student explains his collaborative skills by showing practices (coding issues, conflict) that exemplify that role. The student can actively explain how support and reviewing best can be done and how he/she is part of the coder-community. The student has executed user/system testing with team members and relates the results to the product鈥檚 performance. The Github workflow is explained in a basic manner. Keep up the good works! | The student shows leadership in the team and specifies a complex coding conflict that he/she resolved by activating the team and the coding-community. The Github reviewing workflow is explained thoroughly and pitfalls are made clear. The student can actively explain how he/she is part of the coder-community. The student has prepared user/system testing with team members and explains its necessity in a clear way. A coding climber! |
馃殌 Collaborative skills come naturally to the student and the team is leaded to groundbreaking results in coding, community and user/system testing. A natural born leader! (or lots of experience already) |
Note:
you鈥檒l need a > 5.5 for each row to pass: you can鈥檛 compensate between rows
each of this rubric鈥檚 rows is cumulative: for example, to get a 5-6 on review, you also need to have a 1-2 and 3-4.
| Checklist |
|---|
| Source code is available on GitHub |
Project is documented and has a readme.md |
| Cites the sources used; either in code comments or APA style in readme |
| Live version of the application is deployed |
| Seperation of concerns (HTML, CSS & JS) |
| Code validates and semantic HTML is used |
Publishing
Grades will be published and communicated trough Email, Moodle and/or Slack based on student numbers.
- Final grades will be published one week after test date.
- Final grades will be put in SIS two weeks after test date.
After the oral test you can request viewing time for additional feedback, this can be useful for a resit. Feel free to contact your lecturer if you want to do so.
Plagiarism
馃拋 We don鈥檛 like plagiarism and report it to our assessment committee (examencommissie in Dutch). See 露 6.1.2 of Teaching and Examination Regulations (TER) 2017-2018 (in Dutch: Onderwijs- en examenregeling, OER) for a full definition, but here are a few cases that count as plagiarism:
a. using or copying someone else鈥檚 texts, data or ideas without a full and correct acknowledgement of sources; b. presenting the structure or central ideas developed by someone else as your own work or ideas, even when a reference to other authors has been included;
[鈥
e. copying (parts of) media files or other sources, software source codes, models and other diagrams of other people without acknowledgement and allowing it to be held as your own work;
[鈥
g. copying the work of fellow-students and allowing it to be held as your own work;
[鈥
Copyright
You are not allowed to simply use portions of someone else鈥檚 work in your project. The copyright is owned by the creator of the work. You must cite the sources used. Quoting or using material without a source citation is plagiarism and is punishable.
More information on the Student Copyright Information Point
The manner in which you cite your sources depends. The most widely used style at the AUAS is APA of the American Psychological Association. Make sure you cite your sources in the repository or documentation of your project on GitHub.