comp2013-Coursework Part 3 - Maintaining a Legacy Software with Maintainable Quality

Background
This part of the coursework requires maintaining and/or extending a re-implementation of a classic retro
game (Frogger). It is worth 40%. This version has never been completed, but at least it runs, once it is set up
properly. More information about the original Frogger game and its history is available here. You can also pick up
some ideas for creating additional levels.
https://en.wikipedia.org/wiki/Frogger
https://en.wikipedia.org/wiki/Frogger_(series)
https://www.igdb.com/collections/frogger
To get started download the original re-implementation from the following GitHub repository.
https://projects.cs.nott.ac.uk/2024-comp2013/frogger-refactor-coursework
Task 1 – Run the application as the current format it does not work.
The project as it stands doesn’t work properly. The source files aren’t in packages and there is no build file.
Create a new IntelliJ Gradle project and move the source files there using the correct package structure.
You should show that your version of the project can be built. Fix any compile errors that prevent the
project from being built.
Task 2 – Create tests for the key features of the game.
Show evidence of utilising test-driven refactoring. This means showing an example of a failing test and a stub
method, followed by a fully implemented method and a passing test.
Sub-Task 2.1 Create a one-page PDF of the evidence and explain and justify the tests you created and the
types of tests in line with the Lecture on “Testing for Maintainability”. Explanations and justifications
should not be more than 80 words
Task 3 – Maintain the software using refactoring techniques and principles at high level
and low level
Sub-task 3.1: Refactoring at high level.
o Structured your code into meaningful packages
o Structured your code into MVC architecture (programmatically or via FXML)
o Apply any other design patterns to improve the maintainability quality of the software
o Refactor so that the software follows SOLID principles
Sub-task 3.2: Refactoring activities at low level.
o Eliminate/avoid code smell
o Follow the right coding conventions
o Refactor your tests so they do not have test smells
Sub-task 3.3: Create 1 PDF of maximum 4 pages from Sub-task 3.1 and Sub-task 3.2 with screen shots for
the refactored code and the total should not be more than 500 words of explanations and justifications.
Task 4 – Make some additions to the software
Extend the given code base by adding additional feature(s) of your choice
Sub-task 4.1: Create 1 PDF of one page with screen shots of your addition(s) to the software and related
code you had to add/amend. Explanations and justifications should not be more than 80 words
Task 5 – Correct use of tools for development. - - -
Ensure that your project can be built successfully using Gradle (i.e. that the Gradle build task
completes successfully).
Demonstrate correct use of Git including feature branching. You could include the
repository graph from Gitlab as part of this.
You should also include evidence of git messages of different branches.
Task 6 - Documentation
Create a README that should have a brief description of the project, and explains the key features
of the software, which is aimed at future developers and users of the software (how to play) and
credits. Provide Javadoc comments for the major classes and methods in your implementation,
explaining the key features of them. Ensure the README file is included in your repository.
Submission (1 pdf): Create 1 pdf consisting of maximum 5-6 pages from all the sub-tasks (2.1, 3.3, and 4.1)
submit in the Moodle submission area. The pdf should be called SurnameFirstName_part2.pdf.
Submission (git repository): We will do a pull from git repository (source code, Readme).
Deadline: Friday 10th January 3:00pm
We recommend dedicating approximately 30 total hours on the coursework. Please keep in mind that the
skill level varies quite a bit in a large class of students, and that the exact number of hours depends on your
individual skill level.
Marking Scheme
0 % (Zero) - No project in git/pdf of evidence is submitted.
0-39 % – Software cannot be built. Software is poorly refactored both at higher and low levels. Justification
and evidence of refactoring principles is sparse for the high level and low level refactoring activities.
41- 50% - Software can be built. Software is refactored at a very superficial level with important violations
of the refactoring principles. Justification and evidence of refactoring principles is done for some high level
and some low level refactoring activities. Sometimes justifications are not clear and/or no evidence is
provided. Additional features are attempted.
51 – 60% - Software can be built. Justification and evidence of refactoring principles are done for most
high level and most low level refactoring activities. Most justifications are clear and evidences are aligned.
Good use of git, Javadoc and Readme. Additional features are added with sufficient quality.
61 –69% Software can be built. Justification and evidence of refactoring principles are done
comprehensively for high level and low level refactoring activities. Most justifications are clear and
evidences are aligned. Very good use of git, Javadoc and Readme. Additional features are added with good
quality.
70 – 79% - Justification and evidence of refactoring principles are done for all the high level and some low
level refactoring activities. This is done with excellent quality. It is also evident that skills have been
developed for developing a software with good maintainable attributes.
Additional features are added with excellent quality.
80% - 89% In addition to the above, there is evidence of original thinking and restructuring of the
software for better maintainability quality. Additions to the software are original.
90 – 100% - Refactoring is done to a professional standard with reflection from other parts of the curriculum
beyond those specified in this coursework description. Additions to the software are original and with
exceptional/professional quality. There are no mistakes at all.