Given that the question is about reporting progress I would propose adapting one of the agile development methodologies to your case.

More precisely:

1. 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.
2. 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

    Class name:
    Responsibilities:
    Weaknesses:
    Collaborations:
    Dependencies:
    ...

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.

Take notes.

Think about why you have been asked to do this? Are you a new hire, tasked with becoming familiar before you do actual development? Are you a consultant? Is this a project for school?

Think about the reason you have been tasked to do this, and write down (in a Word document or similar) the information that is most relevant to the task at hand. If you are really only doing this for yourself – e.g. because you are a new hire that they want to self-train before they give you programming tasks – write down the information that you will find most useful as a reference guide when you actually do have to do development.

Things you can write down:

1. Class structure and separation of concerns – try to figure out which major pieces go where.
2. Revelant API calls for the development you need to be doing
3. Things you would improve given the change, classes that need work, methods which should be refactored, performance bottlenecks.
4. Questions you would like to ask (thanks @rwong)