Ci si è posti una meta molto ambiziosa, forse troppo, ma si è effettuato uno sforzo cospicuo per cercare di completare un quadro di riferimento per la produzione industriale di software gestionale utilizzando tutti gli strumenti metodologici a disposizione, da quelli fondamentali già citati ad altri più specifici, per non lasciare spazi vuoti che possano generare il disorientamento dovuto alla mancanza di strumenti o, peggio, l’ambiguità nelle scelte.

L’approccio è meramente ingegneristico: interiorizzare il meglio che esiste e utilizzare quanto di più ragionevole e funzionale sia disponibile come tasselli per completare una metodologia industriale.

Sintetizzando e anticipando il contenuto del capitolo, la fiducia nell’approccio metodologico proposto si fonda su una solida e matura integrazione tra le metodologie universalmente accettate di Batini e Atzeni e due approcci più industriali e, per certi versi innovativi, l’utilizzo del modello del prototyping e di momenti rigorosi di verifica periodica (le review), che devono essere presenti ed evidenti in tutte le fasi della produzione del software gestionale. Non si ritiene necessario soffermarsi sugli standard.

Due considerazioni di fondo hanno guidato il lavoro e meritano una riflessione.

La validità di una metodologia risiede nell’ideare un orientamento che si pone come compromesso tra due esigenze contrastanti, la prima di disciplinare le tipologie di lavoro secondo schemi prefissati, la seconda di consentire agli attori, senza pregiudicare il processo produttivo, di concentrarsi sulle funzionalità e di sviluppare le singole capacità ingegneristiche.

La mole di informazioni che costituisce il sistema nervoso e spesso nevralgico di una organizzazione di grandi dimensioni e la complessità delle operazioni che vengono svolte ai vari livelli sono tali da rendere inefficace la realizzazione di un qualsivoglia progetto che prescinda da una attenta partizione in fasi omogenee che consenta di suddividere le attività su diversi gruppi di lavoro.

Si ritiene utile premettere alcune riflessioni sugli strumenti che verranno utilizzati nel seguito, anche a costo di prolissità e con il rischio di errori piccoli e grandi.

La rappresentazione della realtà di interesse si costruisce scegliendo un modello e applicando un insieme di regole di descrizione e costruzione. Il processo è schematizzato in Figura 5.1.1.

Per essere efficace, un modello deve essere semplice, naturale e intuitivo. Per essere efficienti le regole devono essere chiare, precise e applicabili.

Molte sono le classificazioni e le definizioni delle fasi della produzione del software gestionale, solitamente incluse nel ciclo di vita dei sistemi informativi e informatici.

Un approccio possibile è quello di esaminare più schemi e utilizzare di ciascuno il contributo utile, con la consapevolezza delle limitazioni di ognuno.

Il primo schema utilizzato è lo schema sequenziale, la cui utilità risiede nell’evidenziazione di fasi descrivibili separatamente e attribuibili a diversi attori. In Figura 5.2.1 sono riportati anche i prodotti finali, per una prima visione d’insieme e per anticipare una asserzione forte: il software non è il codice, e nemmeno il codice testato, ma l’insieme di tutti i prodotti.

Nel seguito verranno sottolineati più volte i cicli interni, tanto numerosi e indispensabili da far affermare a taluni che non è possibile riconoscere fasi.

Lo schema riportato in Figura 5.2.2, tratto da Booch, asserisce che la produzione del software in realtà è un’attività di progettazione, quindi ci si deve concentrare sullo studio del problema anziché sulla realizzazione del progetto che diventa sempre meno complessa, grazie a strumenti informatici molto semplificati.

Inoltre, dallo schema di Booch si possono trarre altre importanti riflessioni:

• sulla necessità di integrazione e armonizzazione,
• sulla opportunità di attivare strumenti di valutazione interna,
• sull’importanza di una regia unica.

Lo schema fase/attore è uno strumento molto utile non solo per descrivere in modo rapido il "chi fa che cosa" a livello di responsabilità operative, ma anche per mostrare come le diverse attività siano correlate tra loro nel momento in cui si esplicita il ruolo dei diversi attori nelle fasi che precedono e seguono.

Si dà per disponibile lo studio di fattibilità, la cui metodologia è già esaurientemente descritta dall’AIPA.

La prima fase della produzione di software gestionale è caratterizzata dall’intervento dell’analista che attraverso una rilevazione dei bisogni, supporta l’utente nella definizione dei requisiti. In questo modo non solo l’analista acquista la padronanza del dominio del problema ma individua le funzionalità da soddisfare.

La realizzazione di un prodotto di qualità non può prescindere in alcun modo dalla partecipazione in un ruolo attivo dell’utente nelle fasi che mirano a definire le funzionalità richieste all’applicativo (il cosa deve fare). Si vuole sottolineare ciò all’interno del diagramma attribuendo all’utente una funzione primaria nelle prime due fasi della produzione del software gestionale.

L’unicità della conoscenza dei propri bisogni unitamente al grado di alfabetizzazione informatica crescente, rende auspicabile inoltre l’idea che l’Utente un giorno diventi completamente responsabile della fase di Analisi e Definizione dei Requisiti. La funzione dell’Analista rimarrebbe quindi solo quella di rendere formale la descrizione di tali richieste, nella fase di Analisi concettuale. E’ interessante sottolineare un aspetto importante: le prime due fasi sono attività che si muovono su due piani di astrazione differenti e possono essere intraprese da persone (o gruppi) differenti. Attualmente è l’analista che ha il doppio compito di porsi sui diversi piani di astrazione, "filtrare" le richieste e rielaborarle in modo da eliminare ogni incongruenza ed ambiguità.

Il progettista è il responsabile della comunicazione tra la fase di analisi e quella di implementazione e si comprende come egli sia parte attiva anche delle fasi che precedono e seguono la progettazione. Infatti da un lato il progetto risultante deve essere ad un livello di astrazione tale da poter essere agevolmente confrontato con le specifiche da cui viene derivato, dall'altro lo stesso progetto deve essere sufficientemente dettagliato in modo tale che la codifica possa avvenire senza ulteriori necessità di chiarire le operazioni che devono essere realizzate.

Si noti che seppure le attività dell’analista e del progettista siano ugualmente ingegneristiche , all’analista spesso si vogliono associare capacità maieutiche.

La formalizzazione grafica di un approccio metodologico per la rappresentazione di una realtà di interesse può essere affrontata secondo due coordinate: una coordinata organizzazione dell'impresa ed una coordinata organizzazione dei concetti, secondo la proposta di Batini (Figura 5.4.1). Attraverso l'uso di queste coordinate è possibile definire diagrammi che descrivono un percorso metodologico.

I livelli organizzativi aziendali significativi nel progetto di un sistema informatico dipendono, oltre che dagli elementi che compongono il sistema informativo, dalle dimensioni e dalla natura della realtà cui si fa riferimento. In linea di massima si possono individuare quattro livelli organizzativi: sistema, sottosistema di I° livello (modulo), al sottosistema di livello i-esimo e alla singola responsabilità (funzione o funzionalità).

Per sistema si intende la realtà di interesse del progetto che si vuole realizzare. Per sottosistema si intende un'area organizzativa caratterizzata da un'omogeneità di funzioni o da una omogeneità dei prodotti forniti dal settore; i due criteri di caratterizzazione possono essere alternativi o coesistere, in dipendenza della natura e dei compiti del settore nell'ambito dell’intero sistema da rappresentare. Occorre distinguere tra la definizione di sottosistema di I° livello e quella di sottosistema di livello i-esimo: la prima è frutto dell’individuazione delle modalità operative del sistema; i sottosistemi di livello successivo rappresentano parti del sistema caratterizzate da una omogeneità dei dati rappresentati e delle funzioni che li manipolano. Per questi ultimi si procede per derivazioni successive fino definire le singole responsabilità del sistema. Non esiste una corrispondenza totale tra i sottosistemi di I° livello e quelli di livello successivo: i sottosistemi di I° livello definiscono una partizione del sistema diversa rispetto quelli di livello i-esimo. Le responsabilità rappresentano le operazioni che creano una corrispondenza tra la realtà di interesse e il sistema informatico.

La coordinata organizzazione dei concetti può essere percorsa con attività di astrazione oppure di raffinamento. Per astrazione si intende un percorso che si muove dal particolare al generale, mentre per raffinamento si intende un percorso inverso, dal generale al particolare, che procede definendo, a partire da concetti astratti, informazioni via via più dettagliate.

I movimenti tra i vari livelli della coordinata di organizzazione d’impresa possono avvenire sia in direzione bottom-up (integrazione) che top-down (derivazione). Nel primo caso partendo da livelli organizzativi inferiori, si genera un prodotto relativo ad un livello organizzativo superiore. Nel secondo caso partendo da un livello superiore si generano uno o più prodotti relativi ad un livello organizzativo inferiore.

Per ogni fase della produzione del software gestionale descritte nel capitolo successivo verrà definito lo specifico percorso metodologico da seguire. I diversi percorsi metodologici verranno alla fine integrati in un unico schema.

La principale innovazione proposta rispetto alle metodologie di riferimento è il tentativo di collocare la concettualizzazione della realtà percepita ad un livello alto di astrazione, suggerendo all’analista di diagrammare gli oggetti percepiti non appena egli ne avverta l’esigenza, mediante l’E-R o il DFD, a seconda di quale dei due strumenti risulta più potente per la comunicazione con l’utente.

Il riutilizzo degli strumenti concettuali a diversi livelli di astrazione permette per alcune attività una visione alta non supportata da un formalismo rigoroso (vedi E-R e DFD) e per altre il raggiungimento di un livello di raffinamento fino al dettaglio. Ad esempio il diagramma E-R è un prodotto finale nella fase di Analisi, ma compare ad un livello di astrazione maggiore e come strumento informale, nella fase di Analisi e Definizione dei Requisiti, e ad un livello dettagliato, come E-R ristrutturato, nella Progettazione Logica. I DFD sono rigorosi e formali sia nell’Analisi che nella Progettazione, ma la loro descrizione riguarda attività che hanno un livello di dettaglio più o meno spinto.

Kenneth E. Lantz presenta il prototipo da un interessante punto di vista:

La tecnica del prototyping si sta affermando grazie al fatto che permette di mostrare in modo iterativo all’utente ciò che il progetto vuole realizzare.

In effetti, le basi culturali e la visione del mondo del committente e degli utenti di software gestionale, molto diverse da quelle dei tecnici, spesso rendono difficile la comunicazione e la comprensione, tanto da consigliare l’utilizzazione di tutti gli strumenti disponibili per diminuire le ambiguità che poi portano alla realizzazione di prodotti diversi da quelli pensati, e quindi attesi, dal committente. Può quindi essere utile sperimentare approcci meno formali e verificare la loro potenza in termini di risultati e di economie.

Batini inserisce il prototyping nel ciclo di vita dei sistemi informatici, come mostrato nella Figura 5.6.1 e così lo definisce:

Batini introduce dunque un altro aspetto essenziale. Gli strumenti oggi a disposizione consentono di realizzare un prototipo con le seguenti caratteristiche:

• veloce da realizzare;
• poco costoso;
• chiaro, cioè di comune comprensione, sia da parte dell’analista che dell’utente;
• completo, cioè descrive tutte le responsabilità (funzioni) da realizzare.

Si ritiene pertanto utile adottare e sperimentare il modello del prototyping.

Non si tratta di una semplice tecnica, in quanto è molto più potente, forte del fatto che se ne può dare una definizione formale ed elegante al di là di ogni implementazione tecnologica attraverso cui il modello si va poi a concretizzare. Esso soddisfa sicuramente le proprietà che una metodologia (di cui esso fa parte) deve garantire: generalità rispetto alle applicazioni in gioco, qualità del prodotto (completo ed efficiente), facilità d'uso.

Non è opportuno dare indicazioni su come realizzare il prototipo, ma si vuole evidenziare la sua rilevanza metodologica e quali sono gli obiettivi perseguibili attraverso il suo utilizzo.

Deve però essere chiaro che il prototipo non deve mai evolversi nel prodotto finito e a tale scopo è preferibile che sia realizzato con strumenti diversi da quelli che si utilizzeranno in fase di realizzazione. La sua funzione è solo quella di mostrare agli utenti ai vari livelli il comportamento del sistema, al fine di ottenere da essi il maggior numero di informazioni possibili per ampliare la conoscenza del dominio del problema.

Nelle fasi di analisi, il prototipo ha l’obiettivo di portare la conoscenza della realtà d’interesse a livello di dettaglio completo; in particolare serve ad individuare contemporaneamente le caratteristiche statiche (attributi delle entità) e dinamiche (flusso logico funzionale) di ciascuna responsabilità individuata nell’analisi e definizione dei requisiti Il prototipo quindi rappresenta un modello empirico utilizzato per la realizzazione e la formalizzazione dei modelli concettuali, ed è lo strumento che aiuta a raffinare i diagrammi E-R e DFD.

Il prototipo è creato nel rispetto delle funzionalità di primo livello individuate, a partire dai requisiti formalizzati. La realizzazione del prototipo avviene attraverso successivi raffinamenti, fino ad ottenere uno schema concettuale esauriente, sul quale elaborare le modalità di realizzazione del sistema durante la fase di progettazione. Alla fine dell’attività di analisi deve essere disponibile un prototipo di livello n, derivante da n raffinamenti, dipendentemente dalla complessità del dominio del problema, che descrive completamente l’interfaccia utente. L’analista ha così la possibilità di presentare all’utente il prodotto, nelle sue prime fasi di realizzazione, e l’utente di valutare se tale prodotto corrisponde alle sue esigenze.

In effetti, il prototipo è una risorsa estremamente utile in ogni fase in quanto le sue peculiarità lo rendono flessibile ad essere utilizzato, oltre che per il dialogo utente-analista, anche come interfaccia progettista-implementatore. Il suo obiettivo è meramente quello di contribuire a chiarire all'implementatore come devono essere sviluppate le specifiche definite nei documenti di Analisi.

Il prototipo di progetto trascura l'effettivo svolgimento delle operazioni che sono comandate attraverso le maschere, ma per ciascun pulsante o casella o strumento tipico degli ambienti visuali sarà specificato mediante linguaggio naturale l'aspetto tecnico vero e proprio che supporta il processo.

Riflettendo sugli schemi della produzione del software gestionale emerge prepotente la necessità di armonizzare e monitorare tutte le attività per aumentare le probabilità di raggiungere gli obiettivi.

Lo strumento metodologico da utilizzare è la review periodica, a cui afferiscono oltre ai responsabili ed ai partecipanti della fase in oggetto e di quelle collegate, anche eventuali esperti esterni al progetto, con conoscenze specifiche del dominio del problema o conoscenze tecniche.

La Review è di tale importanza e produttività per ciascuna fase della produzione del software gestionale che risulta opportuna ogni qualvolta l’applicazione del nostro piano metodologica porta al raggiungimento di un obiettivo previsto.

La filosofia dello svolgimento della Review è strettamente collegata ai vantaggi che si ottengono dal lavoro di gruppo e dal confronto delle impressioni di ciascun partecipante. Inoltre le ipotesi di soluzione proposte da più individui rendono più oggettive le scelte, aumentando la qualità del prodotto e riducendo il tempo totale di svolgimento.

Lo strumento Review è un cardine della nostra metodologia che conta sulla sua efficacia tanto da considerare non produttiva una riunione che non mette in evidenza errori rispetto agli obiettivi; esso ad esempio dovrebbe evitare che gli errori concettuali giungano al livello progettazione, dove la loro eliminazione avrebbe un costo maggiore.