Given that the question is about reporting progress I would propose adapting one of the agile development methodologies to your case.
- Start dividing the bulk of research work in User Stories, each of them for the different parts of the basecode you have to cover. You don't need to know all the parts in advance, just capture the ones that according to your current understanding are the main ones.
- For every User Story create the tasks that you think you will need to perform to gain understanding of the source code. For instance, a task could be Understand Class X, another Document how Instances of Class Y are created, or Determine the main responsibilities of Class Z, etc.
Use your preferred ticket system to register your User Stories and their Tasks.
Now you could use, say, TDD to approach the analysis. Take one task and write down the evidence you would consider sufficient to conclude that the task has been accomplished. One way to do this would be to design a form whose fields correspond to pieces of information the task is intended to find out. You could write Unit Tests that check that each of the information fields has been completed. You don't need anything fancy, a very simple parser on the content of a text file named after the task will suffice. Something on the lines of
As you progress with this methodology you will discover new User Stories and new Tasks. You will also be able to create more unit tests that the fruits of your research should make them pass. The tests will give you a very clear visualization of progress. The records containing the information in the fields you will test will capture in a structured way the understanding you have developed so far.
One important thing that is not always recognized as valuable is the visualization of progress towards the horizon of knowledge you are trying to reach. So, let me explain this better.
It consists on a single plot that is very easy to draw and provides a lot of insights: Use the X axis to represent the time elapsed since day 1. Use the Y axis to represent the cumulative number of tasks identified so far. Since the Y axis is a cumulative quantity the curve will not decrease. In day 1 and 2 the plot would show the initial number of tasks you could identify. As the time elapses the number of tasks will increase. At certain point in time you will notice that you are still adding tasks, but now at a lower pace. This will give you an idea of convergence, meaning that you will see the horizontal asymptote that you should ideally reach.
The addition of tasks is not a smooth curve because you add tasks one day, and then work on them for say, a week or so. This is represented by the green curve. The black curve is a smooth fit. The top horizontal line (blue) is your current best guess of the asymptote. The distance between the actual curve and the asymptote is a measure of your unknown unknowns, the tasks you haven't identified yet, but eventually will.
Note that this graph doesn't include the (cumulative) number of tasks closed so far. You can add them and get many more insights. My point, however, is that even without this information you will be able to report progress in your understanding. The tasks closed so far will measure your known knowns. The difference between the total number of tasks and the number of closed ones will be a measure of your known unknowns.
And of course, if you want to be really rigorous you should use these graphs to provide probabilistic estimations of the time required to achieve intermediate milestones.