Rubric

Exam Assessment Rubric

This rubric is based on the project brief in _index.md.

The exam hand-in is one GitHub repository containing:

the Java backend application
the portfolio/documentation of the development process

The assessment should focus on the repository as a whole: product quality, development process, reflection, and professionalism.

Suggested assessment scale

Use the institutional grading scale as required. The descriptors below can be mapped to local grades.

Excellent: Strong, consistent, and well-justified work with only minor weaknesses
Good: Solid work that meets expectations with some weaknesses or missing depth
Adequate: Meets minimum expectations but with clear gaps, inconsistencies, or limited justification
Insufficient: Does not meet minimum expectations in one or more core areas

Assessment criteria

Criterion	Weight	Excellent	Good	Adequate	Insufficient
Technical quality of backend application	35%	The backend is functional, coherent, and well-structured. Core Java technologies are used correctly. Architecture is sensible. API design, persistence, validation, error handling, security, configuration, testing, and deployment considerations are implemented to a high standard relative to the project scope.	The backend works well overall and shows correct use of the main technologies. Structure and architecture are mostly sound. Several expected backend concerns are implemented, though some areas are uneven or underdeveloped.	The backend demonstrates partial functionality and some correct technical choices, but important elements are fragile, incomplete, or inconsistently applied. Structure may work, but design quality is limited.	The backend is incomplete, unreliable, or shows major misunderstandings of key technologies. Structure is weak, and core expected backend concerns are missing or incorrectly implemented.
Progress and development over time	20%	The repository shows clear, steady development across the semester. Git history documents meaningful progress, iterative improvement, and integration of new topics into the same application.	Development over time is visible and mostly consistent. Git history shows progress and extension of the application, though some periods may be thin or less clearly documented.	Some progress is visible, but development appears uneven, rushed, or weakly documented in Git history. Integration of semester topics may feel superficial.	There is little evidence of sustained progression. Git history is sparse, unclear, or suggests last-minute work rather than iterative development.
Reflection and technical understanding	25%	Portfolio entries are regular, honest, and technically meaningful. The student clearly explains what was built, why choices were made, what was learned, what was difficult, and what could be improved. Reflections demonstrate strong understanding and awareness of trade-offs.	Portfolio entries explain the work and show understanding of most major decisions. Reflection is present and useful, though sometimes descriptive rather than analytical.	Reflection exists but is brief, inconsistent, or largely descriptive. Explanations of decisions, challenges, and trade-offs are limited or vague.	Reflection is missing, minimal, or superficial. The repository gives little evidence that the student understands or can explain the work beyond surface description.
Professionalism and repository quality	20%	The repository is easy to navigate and presents the project clearly. Code is readable, commits are meaningful, documentation is clear, and the project tells a coherent story from idea to current state. The hand-in appears careful and professional.	The repository is generally readable and understandable. Documentation and commit quality are acceptable, though some parts are unclear, inconsistent, or missing polish.	The repository can be followed, but code readability, commit quality, or documentation are inconsistent. The overall presentation feels underprepared.	The repository is difficult to read or evaluate because of poor structure, weak documentation, unclear commits, or lack of professional care.

Minimum expectations for passing

To pass, the repository should demonstrate all of the following:

a working Java backend application with a clear purpose
evidence that the same application was developed over time
portfolio posts or equivalent documentation showing regular reflection
understandable code structure and readable repository organization
enough technical depth to show engagement with the semester’s backend topics

Serious weakness in any one of these areas may justify a failing assessment, even if other areas are stronger.

Guidance for examiners

When applying the rubric, prioritize:

whether the student can build and evolve one coherent backend system
whether technical choices are reasonable for the chosen scope
whether the Git history and portfolio show genuine progression
whether the student demonstrates understanding, not just completed features

The project does not need to be large or perfect. A smaller, finished, well-reasoned backend with clear reflection should be rated higher than an ambitious but incomplete system.

Optional holistic judgment prompts

These prompts can help support the final overall judgment:

Is the application technically coherent and credible as a backend project?
Does the repository show continuous learning and incremental development?
Can the student explain choices, difficulties, and trade-offs in a convincing way?
Does the submission appear professional enough to show to an examiner or employer?