Sembra difficile da credersi, ma la documentazione, è altrettanto fondamentale almeno quanto lo è l'analisi, nella realizzazione di un progetto, scrivere non vuol solo dire "mettere i commenti", o mandare una mail indicando quello che si è fatto.
Nella realizzazione di un progetto ci possono essere svariati tipi di documenti e naturalmente ogniuno di loro può avere il suo scopo specifico.
Sicuramente ci devevono essere:
- Richiesta
- Studio di Fattibilità
- Analisi Funzionale
- Analisi Tecnica
- Stato Progetto
- Manuale Utente
- Casi di Test
- Rilascio
Lo Studio di Fattibilità, è un documento scritto tipicamente da un analista funzionale con la collaborazione,
qualora non vi fosse la conoscenza delle strutture di implementazione, di un analista tecnico.
Questo documento ha lo scopo all'interno del progetto di individuare se i mezzi, le possibilità di realizzare la
soluzione sia o meno fattibile. Saranno evidenziate possibili criticità che dovreanno essere discusse con
chi a formulato la richiesta.
E' possibile che questo documento si arricchisca più volte grazie al contributo del cliente e di chi sta seguendo
il progetto stesso.
Individuare e verificare gli obbietti è lo scopo principale di questo documento.
L'Analisi Funzionale, è la base del progetto stesso. Raccoglie quanto presente nella richiesta e nello studio di
fattibilità e crea la traccia da seguire per l'implementazione.
In questo documento vengono individuati gli attori del progetto, eventuali fasi di ralscio, e naturalmente
vengono elencate le funzionalità
vengono descritte le funzionalità
vengono date le specifiche di funzionamento
vengono elencate e descritte le strutture
viene esposto il gantt e l'effort per ogni risorsa
E' chiaro che tanto più è ricco questo documento tanto sarà più semplice redigere l'analisi tecnica.
Tipicamente questo documento ha una circolazione interna a chi svolge il progetto, anche se può essere esposto
in fase di elaborazione al Richiedente.
Documentare e condividere gli obbiettivi del progetto è lo scopo principe di questo documento.
L'Analisi Tecnica, è lo stadio precedente alla programmazione, senza di questo documento potrebbe essere impossibile procedere con la stesura del codice.
In molte realtà è possibile che questo documento sia a corredo dell'analisi funzionale, rischiando tuttavia di creare un testo ibrido che non riesca a esprimere ne i concetti tipicamente o dell'uno o dell'altro documento.
Tuttavia in questo testo vengono rappresentate le strutture (fonti dati) con le loro relative specifiche fin nel più semplice dettaglio. La logica di ogni singola funzionalità, con una descrizione del comportamento atteso, e inatteso.
E naturalmente come i dati e la logica saranno reppresentati.
Ancora una volta si parla di MVC, perchè appunto è questo che deve essere descritto, all'interno di questo documento.
Inutile a dirsi, che tanto più dettagliato sarà questo documento tanto più semplice sarà la realizzazione del codice.
Finalizzare il codice per raggiungere gli obbiettivi è la traccia di questo documento.
Lo Stato del progetto è il resoconto (giorno per giorno / fase per fase / step by step) di quanto è stato fatto e di quanto c'e' ancora da fare.
Potrebbe essere interpretato come una perdita di tempo, ma non lo è. Anzi l'importanza di questo documento, è sia per chi sviluppa, sia per chi si occupa di project management.
E' necessario sapere a che punto si è arrivati o quanto manca, in modo da stabilire se i tempi sono corretti, o per individuare eventuali problematiche.
Generalmente questo documento ritrae a scadenza, l'elenco delle funzionalità e la percentuale di completamento, con
eventuali note.
Il manuale utente ultimamente sembra essere demodè... ma è il nostro parafulmine... quanto meno un'ancora di salvezza. Potrebbe non essere utile scrivere che se si stacca la patch di rete mentre stiamo facendo un operazione transazionale su 5000 elementi non andrà a buon fine... perchè solo un idiota potrebbe verificarlo.
Ma gli utenti sono fatti così. Sono pieni di fantasia, di prove da fare inconsistenti...ed è per questo che nelle loro teste non c'e' spazio per le cose sensate.
Quindi se un applicativo non può fare una determinata cosa, questa va documentata nel manuale utente.
I casi di test vengono da se se abbiamo redatto un buon manuale utente.
Tipicamente sono l'elenco delle funzionalità e il loro comportamento, raccolti per quanto ci si aspetta dall'applicativo in base ad un input dato dall'utente.
Tipicamente "chi tocca i fili muore" .. e chi li tocca, li sfioro... l'abbiamo fatto tutti. Questo è un caso di test che deve essere raccolto fra le possibili funzionalità del prodotto.
Ogni Rilascio deve essere documentato in modo che il richiedente sappia che cosa gli è stato consegnato.
Ad ogni rilascio è necessario inoltre fornire il manuale utente su quanto è stato rilasciato, e il test case, in modo da poter consentire al richiedente di effettuare le verifiche sul progetto.
Chiaramente ci possono essere molti altri documenti, ma questi sono e rimangono i fondamentali, un progetto senza
tutto questo perde di consistenza, e probabilmente anche di efficenza.
Il che potrebbe allontanarci dai nostri obbiettivi.
Nessun commento:
Posta un commento