Dato che la domanda riguarda il reporting dei progressi, suggerirei di adattare una delle metodologie di sviluppo agili al tuo caso.
Più precisamente:
- Inizia a dividere la maggior parte del lavoro di ricerca in User Story, ciascuno per le diverse parti del codice base che devi coprire. Non è necessario conoscere tutte le parti in anticipo, basta catturare quelle che secondo la comprensione corrente sono le principali.
- Per ogni User Story, crea le attività che pensi di dover eseguire per comprendere il codice sorgente. Ad esempio, un'attività potrebbe essere Capire Classe X , un altro Documento su come vengono create le Istanze di Classe Y o Determinare le principali responsabilità della Classe Z , ecc.
Utilizza il tuo sistema di biglietteria preferito per registrare le tue User Story e le loro attività.
Ora potresti usare, per esempio, TDD per avvicinarti all'analisi. Prendi un compito e scrivi le prove che considereresti sufficienti per concludere che il compito è stato compiuto. Un modo per farlo sarebbe progettare un modulo i cui campi corrispondono a pezzi di informazioni che il compito è destinato a scoprire. È possibile scrivere Test unitari per verificare che tutti i campi di informazione siano stati completati. Non hai bisogno di niente di fantasia, un parser molto semplice sul contenuto di un file di testo chiamato dopo l'attività sarà sufficiente. Qualcosa sulla falsariga di
Class name:
Responsibilities:
Weaknesses:
Collaborations:
Dependencies:
...
Mentre avanzi con questa metodologia scoprirai nuove User Story e nuove attività. Sarai anche in grado di creare più unit test che i frutti della tua ricerca dovrebbero farli passare. I test ti forniranno una visualizzazione molto chiara dei progressi. I record contenenti le informazioni nei campi che testerai cattureranno in modo strutturato la comprensione che hai sviluppato fino ad ora.
Una cosa importante che non è sempre riconosciuta come preziosa è la visualizzazione del progresso verso l'orizzonte della conoscenza che stai cercando di raggiungere. Quindi, lascia che ti spieghi meglio.
Consiste in un singolo grafico che è molto facile da disegnare e fornisce molte informazioni: Usa l'asse X per rappresentare il tempo trascorso dal giorno 1. Usa l'asse Y per rappresentare il numero cumulativo di compiti identificati finora. Poiché l'asse Y è una quantità cumulativa, la curva non diminuirà. Nei giorni 1 e 2 la trama mostrerebbe il numero iniziale di attività che è possibile identificare. Con il passare del tempo il numero di compiti aumenterà. Ad un certo punto nel tempo noterai che stai ancora aggiungendo attività, ma ora ad un ritmo inferiore. Questo ti darà un'idea di convergenza, nel senso che vedrai l'asintoto orizzontale che dovresti idealmente raggiungere.
L'aggiunta di attività non è una curva fluida perché un giorno si aggiungono attività, quindi si lavora su di esse per dire, una settimana circa. Questo è rappresentato dalla curva verde. La curva nera è perfetta. La linea orizzontale superiore (blu) è la tua attuale ipotesi migliore dell'asintoto. La distanza tra la curva attuale e l'asintoto è una misura delle tue incognite sconosciute, le attività che non hai ancora identificato, ma alla fine lo faranno.
Si noti che questo grafico non include il numero (cumulativo) di attività chiuse finora. Puoi aggiungerli e ottenere molte più informazioni. Il mio punto, tuttavia, è che anche senza queste informazioni sarete in grado di segnalare i progressi nella vostra comprensione. I compiti chiusi finora misureranno le tue conoscenze conosciute. La differenza tra il numero totale di compiti e il numero di quelli chiusi sarà una misura delle tue sconosciute conosciute.
E, naturalmente, se vuoi essere davvero rigoroso dovresti usare questi grafici per fornire stime probabilistiche del tempo necessario per raggiungere traguardi intermedi.