Per completare la metodologia si riporta in Figura 6.5.1 il percorso metodologico complessivo, che chiarisce l’integrazione delle fasi di produzione del software gestionale e prevede le necessarie interazioni tra le fasi. Non è quindi la semplice unione dei percorsi metodologici già visti.

Nella fase di Analisi e definizione dei requisiti il documento dei requisiti si integra dal livello di sottosistema 1 a livello di sistema, per poi derivare nuovamente a livello di sottosistema 1 nella successiva fase di Analisi concettuale. Nel percorso metodologico complessivo quest’ultima attività non viene riportata in quanto per la transitività delle attività dovute all’integrazione dei piani, il documento in esame è già disponibile a livello di sottosistema 1 dalla precedente fase di Analisi e definizione dei requisiti. Inoltre, nel risolvere l’incongruenza relativa alle interrelazioni tra DFD e E-R a livello di sottosistema i-esimo, si è preferito porre particolare attenzione sulla fase di Analisi concettuale, tralasciando l’informazione che nella fase di Progettazione il DFD, allo stesso livello, risulta essere un prodotto finale.

La diversa notazione grafica usata per indicare la doppia freccia tra il DFD e l’E-R sta ad indicare il procedimento di analisi integrata di Batini. L’attività svolta allo stesso livello di astrazione è un continuo raffinamento reciproco. In questo modo il modello concettuale dei dati e quello delle funzioni si supportano e si integrano vicendevolmente.

Ovviamente nel percorso metodologico complessivo compaiono nuove frecce, che indicano attività non contemplate nei singoli percorsi, ma che a livello generale portano nuove informazioni per la comprensione dell’integrazione delle fasi della produzione del software gestionale. Una freccia indica che il documento di analisi è una fonte da cui trarre informazioni per la stesura del manuale utente.

Se durante la stesura del documento di analisi, la realizzazione dell’E-R e del DFD vengono individuate nuove responsabilità ci deve essere un ritorno al documento di analisi e definizione dei requisiti, per integrarlo e riallinearlo secondo le nuove responsabilità individuate. Questo procedimento risulta essere in linea con l’importanza della fase di analisi concettuale, volta ad analizzare nel dettaglio ogni responsabilità e ad evidenziarne di nuove non riscontrate nella fase precedente.

L’integrazione deve dunque essere compiuta rispettando sia la metodologia che la dinamicità, nel senso che ci deve essere cooperazione tra le fasi e, naturalmente, tra gli attori in modo da spingere il raffinamento fino alla realizzazione di un prodotto industriale valido e fino alla soddisfazione completa del committente.

In estrema sintesi:

• il procedimento metodologico è stato organizzato in fasi per esigenze didattiche e metodologiche e per definire con precisione i prodotti finiti che costituiscono parte integrante del software;
• la produzione di software gestionale è un’unica grande attività di progettazione che parte dallo studio del dominio del problema e arriva fino all’implementazione attraverso un’attività continua di progettazione che procede per approssimazioni e raffinamenti successivi.

Ciò vale in particolare all’attuale livello dell’informatizzazione della Pubblica Amministrazione, che non è zero e che quindi tratta la modellazione di sistemi esistenti.

Per questi motivi sono stati proposti strumenti che pervadono tutte le fasi della produzione del software gestionale e che si ritengono essenziali e imprescindibili:

• la conoscenza del dominio del problema,
• l’astrazione,
• il prototyping,
• la review.

Dopo gli strumenti metodologici sono stati accuratamente definiti i prodotti finiti per ciascuna fase, che consentono di impostare vincoli temporali e porre fiducia nella conclusione dell’intero processo.

Il procedimento metodologico risultante è quindi iterativo e incrementale con la tempificazione dei prodotti finiti.