Deliverables

This page is transitioning from the previous semester and some details haven't been updated yet or are still in flux#

Note: all deliverable deadlines are in Canberra time using a 24-hour clock.

All assignment deliverables must be submitted with a completed originality statement (see details below). Any deliverable that does not include a completed originality statement will not be marked. For assignment 2, you must adhere to the structural requirements for your Git repository.

The following schedule of deliverables is still preliminary. Precise due dates and time will be filled in during the first two weeks of the semester, and will also be announced on the course forum.

D1A: Assignment 1 (5 Marks, Individual)#

Assignment 1 will be made available in week 2, and due in week 4.

Please remember that tutors and lecturers will not be available to answer questions on weekends and holidays.

You must edit, commit, and push the following to your GitLab repository before the deadline:

D1A checklist#

Please check that you have done the following before you submit.

• Read and understand the statement on academic integrity.
• Read and understand the statement on deadlines.
• 24 hours before the deadline, do an upstream pull of the assignment.
• 24 hours before the deadline, confirm that your assignment includes a complete and truthful originality statement.
• Push all code to GitLab and confirm that CI tests pass for the tasks you have completed. You will be marked according to the results of the CI tests.
• After you commit and push your final changes confirm that you’ve followed the statement on academic integrity, that you have correctly completed the originality statement, that you have pushed all your work to GitLab, and that the CI result for your last push is what you expect. If things go badly wrong and you end up breaking things right at the deadline, there will be no extension. However, if you made good use of Git and you have a previous commit that works (even if not fully), you may send a private ed post to your tutor and me, asking for your assignment to be marked using that commit.

Evaluation for Assignment 1#

TODO

DXC: Basic Competency Hurdle Assessment#

Assessed in your scheduled lab, Week 5.

In your lab you will be assessed to determine whether you have achieved a level of basic competency in the course. You will need to be able to demonstrate to your tutor that you can write a basic program (covering material roughly corresponding to units J1-J7). Because this is a hurdle assessment, failure of this assessment will automatically mean failure of the course.

If you achieve a mark of 50% or better in the lab test, you are automatically exempt from this hurdle assessment.

D2C: Assignment 2, Stage C (6 Marks, Group)#

Stage C of Assignment 2 will be due in week 6 or 7 (TBD).

At this point, we will evaluate part of your project implementation.

Required Files for Stage C#

All relevant java files and assets must be pushed to GitLab.

You must edit each of the files, ensuring that they are filled in correctly, before committing and pushing the changes.

Evaluation for Stage C#

The marking criteria will be similar to those that will be applied in the final deliverable (stage F).

D2D: Assignment 2, Stage D (2 Marks)#

There are two elements to this deliverable, a group component and an individual component.

Both components should be completed before your scheduled lab in Week 8 and will be assessed by your tutor in the lab.

The purpose of this deliverable is to ensure that each group is making plans for how to test all important parts of their project.

D2D Unit Test (1 Mark, Individual)#

You must show your tutor working JUnit tests that you have created. Your test should be for components (class, methods) that are part of your assignment design. It can be code that you have developed yourself, or code developed by other members of the team.

Evaluation for Stage D - Individual#

TODO

D2D Test Plan (1 Mark, Group)#

The purpose of test planning is for the group to identify which components of your game should be unit-tested. The test plan is a simple document, which should:

• List the classes in your implemented design that should have some unit testing.
• Within each class, list methods that can be tested in isolation.
• For each class, if there are conditions on the class’ behaviour that cannot be tested by calling one method in isolation, give at least one example of a test for such a condition. A very simple example could be something like “After calling add(...), the number returned by size() has increased by 1.”

You do not have to implement the tests at this point. However, implementation of appropriate unit tests is one of the critera that will be evaluated in the your final code submission (D2F).

Required Files for Stage D - Group#

The group must edit, commit, and push the following to the group repository before their scheduled lab.

Evaluation for Stage D - Group#

If your implemented design does not have any classes or methods that can be tested, other than the predefined ones, then it is not a good design, and your group will not be eligible for the marks associated with this deliverable.

D2E: Assignment 2, Stage E (2 Marks)#

At this point, you will have to demonstrate that you can build and run your project. This does not mean that all aspects of the game must work, just that you can compile it, and make it run.

More specific instructions will follow.

D2F: Assignment 2, Stage F (21 Marks, Group)#

This is the major deliverable. Aside from the demo and presentation, all elements of the assignment will be assessed.

A snapshot of your group’s Git repository will be taken at the deadline. It is essential that you strictly follow the instructions on the structure of your Git repository and the list of required files below. Files that are misnamed or are not included in the stipulated location may not be marked.

It is your responsibility to check that the version of your system in Git at the deadline is working correctly.

D2G: Assignment 2, Stage G (2 Marks, Group)#

Presented in your scheduled lab, Week 12.

Required Structure For Your Git Repository for Assignment 2#

For the most part, the details of how you manage your repository are up to you. However, you must observe the following requirements strictly:

• You must have a folder called admin in your base directory (not “Admin” or any other variation). This folder should have been in your repository since the beginning.
• Your admin folder must contain each of the files listed in the deliverables above, using exactly the file names specified. These should have been in your repository since the beginning (although you must fill in the details).
• Your admin folder should not have any sub-folders in it.
• In the above, when the file name says something like best-<uid>.yml, if your UID was u2345678, then your file should be called best-u2345678.yml.
• You must have a build artifact setup to create a working out/artifacts/game/game.jar file automatically when your project is built (see D2E instructions).
• All of your source code must be in the repository (IntelliJ will put it in a folder called src).