IN4315 - Software Architecture

Your contribution should aim to identify and possibly solve some technical debt in the system. It can take many forms:

• identifying technical debt: how’s the overall quality of the code? To that aim, you can run code quality tools (if available for your language), and/or perform a manual analysis on the system’s source code. While technical debt can take many forms, you might want to have a look at the SOLID violations.
• identifying testing debt: is your system tested well? You can measure code coverage, discuss well- and less tested modules, and even describe their testing procedures. Can you also identify what actions should be taken if the testing should be improved? Adding more tests is an obvious one, but are there any factors impeding the simple addition of (effective) tests?
• discussions about technical debt: do developers discuss about technical debt in GitHub issues? Or are there TODO’s and FIXME’s in the source code?
• evolution of technical debt: investigate how the system evolved in terms of technical debt.

Paying a technical debt can also be a nice pull request to the system. Make clear that you did your best to get your pull request merged. Some hints to make this happen more easily:

• Use the same source code style as the rest of the project (do they use automated static analysis tools, e.g., Checkstyle, to enforce this?)
• Make sure that you have tests that show that your solution is an improvement without bugs
• Perhaps most importantly, describe the improvement: how does it improve the system, what does it enable, what does it prevent, … In short: describe how your efforts are useful to the project (in the long term).

Grading criteria

Grading criteria includes:

• A single, well structured document evaluating the technical debt of the system
• Well written document (including spelling and English grammar)
• Comprehensive context overview that describes the instance(s) of technical debt: why is it technical debt, under which circumstances does it become worrisome, perhaps even relate to the historical perspective
• A clear description of the actions that you have taken. Describe in detail what you did and why you think this improves the software.
• If possible, present a clear before/after analysis, this can be in the form of a metrics overview, a design or architectural view, or if the aforementioned options do not capture your solution enough, a detailed textual description.

Report size

This part should contain at most 1000 words.