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

Background

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 theproject 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.2: Refactoring activities at low level.

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.

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 pagesfrom 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.

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.