I've been asked to create a report about the technical debt of an application, but I haven't receive further guidelines about its elaboration. I'll be assisted by Sonar code analysis tool.
My main doubt is: What fields would be useful to include in the report? I mean, what metrics, parameters, findings, suggestions, etc. would be the most important in such a report?
When someone asks me to do something and I have questions about what they want, I go back and ask them. That's the most direct way to get an answer.
As a manager, I would want these fields:
Note also that technical debt, as I've heard the term used, is a broader area that the set of problems a code analyzer will identify for you.
In addition to user246's suggestions, I'd also recommend looking at these areas:
I also second user246 about the importance of talking to your manager/lead to find out more about what they want to see in the report. You've got a very broad task here: your manager could want a detailed analysis, or they could be looking for a thumbnail guide to where they need to focus improvement efforts.
Regardless, I strongly suggest talking to the developers and testers - anyone who has worked with the application for any length of time will have a good idea where the problem areas are. In my experience, the problem areas in an application are the areas with the greatest technical debt.
SonarQube is one step in identifying common tech-debt, like code-smells or code-complexity, duplicate-code and lack of test-coverage.
The second step is like Kate Paulk suggested to talk the developers as they know where they took shortcuts, build quick-hacks or what the unmaintainable parts of the code are.
Log tech-debt and make it transparant:
Our team has a list of tech-debts on our wall. It contains code clean-up todo's. Going from removing sleeps from test-code, upgrading libraries, but also refactoring a class because it hard to understand. If you team does not record tech-debts I would suggest to start to create awareness as well. SonarQube alone is not enough.
The business should have a fair view on what technical issues need to be resolved in the future. Releasing features quick to make a milestone (pitch, demo, contract) is good if your business depends on it, but always take note of how this will effect in the long run. You will go slower and slower if your team goes from hack to hack to get shit done too quickly.
If you're an Agile team add the tech-debt to the backlog to make it visible and transparent. Just like with defects I would advice a zero-tech-debt policy.
Reads:
