Analisi

Studio del problema

Varie metodologie

Lo scopo della fase di analisi è studiare il problema.

Questa affermazione, nella sua semplicità, nasconde una delle sfide più grosse di ogni progetto software: conciliare i due mondi del committente e del programmatore.

L’analista è un tramite tra questi due mondi, deve scoprire tutte le convenzioni, i modelli, la conoscenza che ogni cliente ha sviluppato in anni di attività, sia nella vita di ogni giorno che nell’affrontare i grandi progetti, e tradurre tutto questo bagaglio in un modello esplicativo, complesso quanto si vuole, ma costituito da parti informatizzabili, oggetti abbastanza semplici da trovare una rappresentazione all’interno di un calcolatore.

Al termine del lavoro l’analista produce un documento, le specifiche dei requisiti, che ha due scopi fondamentali: è il punto di partenza per il lavoro del programmatore ed è la base per i test di accettazione finali del prodotto.

Qualunque descrizione che non rispetti questi due punti non è una buona analisi!

L’utente DEVE, nel senso che ha il diritto, sapere cosa sta chiedendo, capire le specifiche che firma.

Il programmatore ha il DIRITTO di ricevere delle specifiche valide per un progetto software, e non dei segni e dei simboli senza alcuna possibilità di traduzione in algoritmi.

Nel tempo sono stati proposti moltissimi metodi per rappresentare il problema, dalle descrizione stile "romanzo vittoriano", ai Data Flow Diagrams e ai modelli Entity - Relationship, ma vi è una singolare costante: la nascita di nuove tecniche di analisi segue di qualche tempo lo sviluppo di nuove tecniche di programmazione.

La prima programmazione, completamente non strutturata, vedeva come metodologie di analisi semplicemente delle definizioni non organizzate del problema studiato, raccolte attraverso delle descrizioni testuali lunghe e complesse.

Certamente descrivere a parole il problema, e quindi il sistema che verrà realizzato, è un modo di comunicare l’oggetto di tutti gli studi.

Ma non è un modo preciso e sintetico; facendo un parallelo è come se un architetto, nel presentare il progetto di una casa, consegnasse un testo del tipo "il soggiorno è di m. 4 x 5, con pavimento in legno, due finestre sul lato sud con una porta finestra che da su un poggiolo tra queste ..."

Un analista che presenta solo una descrizione testuale corre il rischio di non essere capito, di dare delle descrizioni troppo vaghe e poco precise, per cui non sono rispettati i criteri guida che abbiamo esposto per la creazione di una buona analisi.

All’epoca vi era un altro modo di presentare il problema: i flow-chart. Un flow-chart però è una rappresentazione di dettagli fisici e di implementazione, non una descrizione astratta del problema, è più uno strumento di progettazione che di analisi.

Con l’evolversi della programmazione strutturata, sono state inventate delle metodologie di analisi basate sugli stessi principi: forte strutturazione e netta separazione tra le procedure ed i dati.

Gli strumenti sono i Data Flow Diagrams, i dizionari dei dati, le "mini specs" e il modello E-R. Ognuno di questi porta a dei diagrammi, che spiegano in modo visuale e riassuntivo l’aspetto del problema trattato.

Purtroppo anche questi strumenti non sono la panacea ad ogni male, nel senso che se sono usati bene e se sono ben coordinati tra loro, rispettano i criteri guida di una buona analisi, ma se sono usati in modo non corretto è possibile inserire parti non realizzabili o essere non capiti dal committente; ed è proprio la netta separazione tra dati e processi che spesso crea questo tipo di difficoltà.

Oggi stanno nascendo nuove metodologie, ispirate alla programmazione ad oggetti: metodologie di analisi orientate agli oggetti che promettono di essere migliori di quelle che le hanno precedute. Probabilmente, tra qualche anno, anche queste saranno viste come uno strumento obsoleto, superato da chissà quali novità.