Scrittori italiani contemporanei

Armando Salle - Giuseppe Bono

Ha pubblicato il libro   Armando Salle - Giuseppe Bono, Software sotto controllo, editrice Montedit, 1998, pp. 64, Lit. 12.500, ISBN 88-86957-11-4     Parte I Stato dell'arte della produzione di software   Capitolo 1   Stato attuale dei sistemi informativi   • I sistemi esistenti   La maggior parte dei sistemi informativi, specialmente nelle grosse aziende, hanno avuto origine tanti anni fa, e da allora hanno avuto una continua evoluzione. Sono un insieme di programmi fatti con un misto di strumenti e di tecnologie diverse, per la maggior parte fatta in linguaggio COBOL. Inizialmente (e non sempre) il codice dei programmi era allineato con la documentazione dell'analisi. Poi, con i diversi cicli di manutenzione, il codice è stato modificato, ma la documentazione dell'analisi raramente è stata aggiornata correttamente. Come risultato, la maggior parte dei sistemi informativi oggi non dispongono di una documentazione utile. Tipicamente, con il passare degli anni, il team che ha sviluppato il sistema informativo viene disgregato. I motivi sono tanti: qualcuno cambia azienda, qualcuno ottiene un incarico di maggior responsabilità, qualcuno va in pensione, e così via. Quindi, non solo l'azienda non ha la documentazione, ma non dispone più nemmeno delle persone che conoscono il codice. Non è difficile rendersi conto che una volta arrivato a questo punto, la manutenzione del sistema diventa molto difficile. Quando viene scoperto un mal funzionamento, ci vuole molto tempo per studiare attentamente il codice fino a trovare il punto giusto dove intervenire. Se invece si desidera modificare una funzionalità, l'impresa diventa ancora più difficile, se non, in certi casi, impossibile. Nel frattempo, nel mondo dell'informatica, c'è stata una vera rivoluzione. Da una parte, i sistemi aperti, basati su sistemi Unix, hanno una enorme evoluzione sul mercato. Dall'altra, la crescita continua di potenza dei personal computer fa si che il vecchio terminale presente su ogni scrivania venga sostituito da un computer di buona capacità di elaborazione. Nascono le reti locali, inizialmente per permettere ai personal computer l'accesso a un disco o stampante condivisi. Così, ogni PC fa la sua elaborazione, ma i dati sono accentrati sul server della rete. Anni dopo nascono i sistemi client-server, dove il server della rete non ha più un ruolo passivo di condivisione di hardware, ma aggiunge certe funzionalità che va dalla possibilità minima di gestire il motore di database, alla massima di gestire una parte considerevole della applicazione. Le applicazioni che girano sui personal computer hanno un fascino completamente diverso da quelle che girano sui terminale. Hanno interfaccia grafica, sono di facile utilizzo (guidato da aiuto in linea), sfruttano la multimedialitá e permettono l'interscambio di dati con programmi di reportistica, e spread sheets. Ma nei sistemi informativi accentrati sul mainframe, tutto questo si sfrutta poco. In qualche caso, è stata rifatta l'interfaccia utente con tecniche di 'face lifting'. In altri si è permesso a programmi su PC il lancio nascosto di transazioni su host attraverso un messaggio. Ma sostanzialmente, il sistema continua a essere quello di prima. Quindi, ricapitolando quello detto finora, le aziende si trovano con un sistema informativo molto difficile da manutenere e tecnologicamente obsoleto.     • La nascita del nuovo progetto   Per i motivi descritti nella sezione precedente, sono tante le aziende che negli ultimi anni hanno cominciato il rifacimento di una parte o di tutto il sistema informativo. Purtroppo, in questi progetti si registra una elevata percentuale di fallimenti. Ed è questo il punto centrale dell'analisi che faremo di seguito. Vediamo allora quali sono i problemi che si presentano nel cominciare il rifacimento del sistema informativo.     - Sottovalutazione di tempi e costi   Il vecchio sistema è stato sviluppato nel corso di 10 o 20 anni, ma normalmente si pensa che la 'reingenierizzazione' può essere fatta in tempi brevi. Purtroppo non è così. Conducono a questo errore di valutazione due fattori fondamentali: la pubblicità degli strumenti di sviluppo e lo studio non accurato del ciclo di vita.   La pubblicità degli strumenti: Ogni anno con l'avvicinarsi dell'estate molti cominciano a pensare ai chili di troppo che dovrebbero perdere. Ogni giorno riviste, giornali e TV propongono tutta una serie di soluzioni magiche che con poco sforzo faranno ritrovare la linea perduta, andar via la cellulite, ecc.. Chiunque pensi seriamente a queste offerte si rende conto che sono quasi truffe, ma comunque tutti gli anni si fatturano parecchi miliardi in prodotti di questo tipo. Purtroppo, nel mondo del software le cose non sono molto diverse. Ogni nuovo strumento promette di fare risparmiare tutti gli sforzi, di produrre in modo spettacolare, di poter essere facile da imparare quasi istantaneamente, e così via. Per fare un esempio, possiamo ricordare lo slogan dell'IBM con il suo sistema operativo OS/2: 'Dopo 5 minuti, al lavoro!'. Lo studio del ciclo di vita: Il ciclo di vita del software ha quattro fasi: analisi, disegno, sviluppo e test. Queste quattro fasi si ripetono ogni volta che si devono fare modifiche. In un processo di reingenierizzazione, a volte si pensa che basti partire dallo sviluppo, prendendo per buona la documentazione esistente sulle due prime fasi. Ma un programma moderno funziona in modo molto diverso da come funzionava un vecchio programma su mainframe, e quindi la fase di disegno deve sicuramente essere rifatta. Anche sulla fase di analisi ci sono, molto probabilmente, modifiche da fare. Oggi, praticamente ogni sistema informativo viene fatto su un modello dati relazionale. Se il modello dati originale non lo è (situazione più normale), allora anche la fase di analisi viene rivista. E su questa fase si aggiungono altri fattori. Tante volte, durante gli ultimi anni di vita del vecchio sistema si erano desiderati delle variazioni, ma non si trovava mai il tempo per farle: sicuramente la reingenierizzazione viene vista come l'opportunità per introdurle. Se a tutto questo si aggiunge, come abbiamo detto prima, il fatto che la documentazione dell'analisi non è stata aggiornata durante i cicli di manutenzione, si ottiene come conseguenza che il lavoro da fare sull'analisi è moltissimo. In pratica, sarebbe meno costoso rifarlo completamente, ma tante volte questo non è possibile giacché quando viene rifatta solo una parte del sistema informativo, i dati del nuovo sistema devono essere 'compatibili' con quelli del vecchio sistema.     - Metodologia   I problemi fin qua descritti, comunque, non sono i più rischiosi. Qualcuno li identifica prima della partenza, e quindi fa una previsione maggiore di budget e tempi. C'è invece chi si rende conto dopo aver iniziato, ma comunque non molto dopo, e quindi si è ancora in tempo per cambiare previsioni o cancellare subito il progetto. Ma fin qua, i danni economici sono ancora contenuti. Il problema veramente pericoloso è invece, quando si prevedono i budget e i tempi giusti, ma si parte con la metodologia sbagliata. E questo è veramente pericoloso perché il problema non si avverte subito, e quando viene avvertito può essere già troppo tardi per cambiare strada, con danni economici devastanti. Tentiamo di spiegare brevemente il problema, per approfondirlo più tardi. Abbiamo già visto come il vecchio sistema informativo, con il passare degli anni è diventato difficile o impossibile da manutenere. Si può dire che con il passare del tempo, il sistema ha aumentato il suo disordine fino a diventare un sistema difficilmente controllabile. Il problema fondamentale è che nel nuovo progetto ci sono diversi fattori che lo possono portare a questo livello di disordine in modo prematuro, arrivando quindi a un sistema fuori controllo ancora prima di averlo finito. I fattori che portano al caos, come vedremo, si possono riassumere in un errore fondamentale: pensare che fare un grosso sistema informativo è uguale a fare tante piccole applicazioni, cioè, che ci vogliono tante risorse o tanto tempo, ma che si possono utilizzare le metodologie e gli strumenti che vanno bene per i piccoli progetti. Perché i progetti grossi hanno bisogno di strumenti e metodologie diverse? In un progetto piccolo, tutta la logica applicativa fino al dettaglio può essere conosciuta da un singolo individuo. Quindi, finchè tutti i problemi di logica possono essere risolti da una sola testa, non c'è un forte bisogno di trasmettere e condividere queste conoscenze con altre persone del team di lavoro. Quindi, la documentazione gioca un ruolo secondario. In un grosso progetto, invece, non c'è nessuno che conosca tutta la logica applicativa. Questa viene elaborata, invece, da un gruppo di persone. Quindi, i requisiti metodologici cambiano completamente. Diciamo brevemente che ogni persona del team dovrà rendere disponibile l'informazione che lei stessa gestisce. La documentazione di questa informazione dovrà essere sempre perfettamente allineata con il codice sorgente. Inoltre, c'è bisogno di una metodologia che permetta di documentare in modo che una persona che non l'abbia scritta, possa 'navigarla' a diversi livelli di dettaglio, così che sia possibile cominciare la ricerca del punto d'interesse navigando ad alto livello, per scendere a livelli più dettagliati man mano che ce ne sia bisogno. Come dicevamo prima, questo problema non viene avvertito subito. Il motivo è che all'inizio, un progetto grosso assomiglia ad uno piccolo: ognuno porta avanti una parte in modo abbastanza indipendente del resto, le persone non cambiano, tutti si ricordano di quello che hanno fatto, la complessità del sistema è ancora bassa, perché mancano le interazioni fra i diversi sottosistemi. Quando ci sono modifiche sull'analisi, il software da modificare è ancora poco e ben conosciuto, ma dopo il primo anno di progetto, le cose cominciano a cambiare. Per dare una idea racconteremo una breve storia capitata durante il secondo anno di un grosso progetto di software bancario. C'era la necessità di conoscere l'algoritmo con il quale venivano generati i numeri degli assegni. La persona che aveva fatto l'analisi della Cassa già non partecipava più al progetto. Quindi ci si rivolse a chi aveva fatto il disegno (l'analista tecnico), il quale, dopo un po' di riflessioni, consigliò di parlare con chi aveva scritto il codice. Si andò quindi a parlare con questa ragazza, una laureata in informatica che collaborava nel progetto dall'inizio. Lei decise di guardare il codice, ma non si ricordava neanche dove cominciare a cercare. Dopo circa un'ora, arrivò finalmente al punto. Lo lesse uno, due... tre volte, con espressione di confusione. Finalmente disse "Mah... la verità è che non riesco a capire. Se veramente serve questa informazione, dovrei lanciare il programma con il debugger per vedere come si comporta." Pensate quale possa essere diventata la situazione quando questa persona lasciò il progetto sei mesi dopo.

Home page di Arnando Salle - Giuseppe Bono Se desideri acquistare il libro e non lo trovi nella tua libreria puoi ordinarlo direttamente alla casa editrice. Versa l'importo del prezzo di copertina sul Conto Corrente postale 22218200 intestato a Montedit, cas. post 68 - 20077 Melegnano (Mi). Indica nome dell'autore e titolo del libro nella "causale del versamento". Oppure spedisci assegno non trasferibile allo stesso indirizzo, indicando sempre la causale di versamento. Si raccomanda di scrivere chiaramente in stampatello nome e indirizzo. L'importo del prezzo di copertina comprende le spese di spedizione. Per spedizione contrassegno aggravio di Lit. 7.000 per spese postali. Per ordini superiori alle 50.000 lire sconto del 20%.   PER COMUNICARE CON L'AUTORE speditegli una lettera presso «Il Club degli autori, cas.post. 68, 20077 MELEGNANO (Mi)». Allegate Lit. 3.000 in francobolli per contributo spese postali e di segreteria provvederemo a inoltrargliela. Non chiedeteci indirizzi dei soci: per disposizione di legge non possiamo darli. ©1996 Il club degli autori , Arnando Salle - Giuseppe Bono. Per comunicare con il Club degli autori: info<clubaut@club.it> Se hai un inedito da pubblicare rivolgiti con fiducia a Montedit Rivista Il Club degli autori Home page Club dei poeti |Antologia dei Poeti Concorsi letterari Arts club (Pittori) TUTTI I SITI CLUB Consigli editoriali per chi vuole pubblicare un libro Se ti iscrivi al Club avrai un sito tutto tuo! inserito il 16/05/1998