Course Assessments

Week 4 & Week 5 — Alpha (40% total)

• Code submission: Friday Week 4: 14 August, 23:59 [Individual submission]
• Presentation: Throughout Week 5 (day/time will be announced in Canvas) [Individual presentation]
  • See the Canvas announcement for the schedule and an explanation of how it works.
• Reflection after Alpha: End of Week 5 [Individual submission]

Marking details

---

Alpha Marking Details

Alpha will be marked out of 40 marks, with the following components:

1. [5 marks] Code Style:
   • This will be marked automatically by extracting your GitHub repo.
   • According to the Java Code Conventions specified for Alpha.
2. [2 marks] Git Etiquette:
   • This will be marked automatically based on your GitHub commits.
   • According to the Git Etiquette specified for Alpha.
3. [4 marks] Presentation Professionalism:
   • Turn on your camera (3 marks).
   • Introduce yourself and communicate professionally (1 mark).
4. [28 marks] Demo:
   • Functionality demonstrated (18 marks).
   • Engineering questions (5 marks).
   • Overall client impression (5 marks).
   • See the detailed rubric below.
5. [1 mark] Reflection:
   • You will use Co-Thinker for this. It will be released after everyone finishes their presentation.

Alpha Presentation Essentials

The Alpha presentation will take approximately ten minutes and will follow the same structure for every student.

See timetable

You need to complete the following preparation before your presentation:

• Ensure you have the latest version of Zoom.
• Ensure you have tested that another participant can take remote control during the Zoom call, as the client may need to run your app themselves if it crashes on their system. Refer to the official Zoom documentation and test this before your scheduled presentation. macOS users may need to complete additional permission steps.
• Make sure you have also already tested your mic and camera beforehand.
• Join the Zoom link 10–15 minutes before your scheduled presentation time. Don’t be late.
• Make sure your Zoom name is the same as your name as shown in Canvas.
• You will be moved to a breakout room to share your screen.
• Have both your application and the relevant source code ready to show. Do not use slides.

Presentation structure

1. Greeting and setup
   • Introduce yourself the client will share their screen.
2. Demonstration 1: the client plays — 2 minutes
   • The client takes control and plays oen round of the game.
   • You should remain silent while the client is playing unless the client asks you a direct question.
   • The client should be able to understand how to interact with the application without directions from you.
3. Demonstration 2: the student demonstrates — 2 minutes
   • You share the screen and demonstrate the application yourself playign another round of the game.
   • Talk while using the application and explain the relevant design decisions as they appear in the interaction.
   • Where practical, demonstrate a different intervention or outcome from the one seen in Demonstration 1.
4. Client clarification questions — 2 minutes
   • The marker remains in the role of an Insight Investigations client.
   • The client may ask you to clarify the scenario, player experience, or design decisions.
   • Answer for a non-technical client and focus on the product and its value rather than implementation details.
5. Engineering questions — 4 minutes
   • The marker will clearly switch from the client role to the lecturer/TA role.
   • Be ready to show the relevant prompts or source code while sharing your desktop. The lecturer/TA will select one or two questions from the following published bank, depending on the time available:
     1. Show where the LLM call leaves the JavaFX Application Thread by using a JavaFX Task, following the approach taught in class.
     2. Show how your Java code passes the conversation state from the earlier epoch to the later temporal version.
     3. Show the prompts you wrote for the two temporal versions and briefly describe them highlighting their differences.
     4. Show a part of your code that you are particularly proud of and briefly explain what it does.
     5. Show how your application moves from the investigation phase to the intervention-selection phase.
     6. Show one meaningful change you made to the starter code and briefly explain why it was needed for TimeMystery.

Alpha Demo Rubric — 28 marks

The two demonstrations and the follow-up questions provide evidence for the rubric below. The demonstrations do not need to expose every behaviour naturally: the student-led demonstration can be used to show required behaviour that did not occur while the client was playing.

Functionality demonstrated — 18 marks

The functionality mark assesses how completely and correctly your application implements and demonstrates all Alpha requirements explicitly written as must or must not in the project handout. The project handout is the single source of truth for these requirements.

Requirements described as recommendations, examples, or open design choices are not assessed as functionality requirements. Partial marks may be awarded where a compulsory requirement is implemented but incomplete, inconsistent, or affected by a defect.

Engineering questions — 5 marks

The lecturer/TA will select one or two questions from the published question bank. Marks are based on your ability to locate the relevant prompts or code and briefly explain what they do and why. Partial marks may be awarded for incomplete explanations or partially relevant evidence.

Overall client impression — 5 marks

This criterion concerns the client’s experience of the functioning product. Graphic polish is not required and is not assessed independently.

Marks	Descriptor
5	The application is immediately understandable and easy to use without coaching. The scenario and interactions form a highly coherent experience, and the student clearly relates thoughtful design decisions to the needs of Insight Investigations.
4	The application is easy to understand and use with only minor friction. The experience is coherent, and the student gives a clear explanation of its value.
3	The core experience is understandable and generally coherent, but there are some usability problems.
2	The intended experience can be identified, but substantial usability or coherence problems make parts of it difficult to complete or understand.
1	The application provides very limited evidence of an understandable, coherent client experience.
0	The application does not provide an understandable client experience, or the relevant evidence cannot be demonstrated.

---