Ingegneria economica del software. Autore: Habib Sedehi

Transcript

1 Ingegneria economica del software Autore: Habib Sedehi Copyright per l edizione italiana 1997 APOGEO Viale Papiniano Milano (Italy) Telefono: (5 linee r.a) Telefax: apogeo@urra.it U.R.L.: ISBN Progetto di copertina: OZdesign, Milano Tutti i diritti sono riservati a norma di legge e a norma delle convenzioni internazionali. Nessuna parte di questo libro può essere riprodotta con sistemi elettronici, meccanici o altri, senza l autorizzazione scritta dell Editore.

2 Sommario P Prefazione XIII P Premessa XVII I Introduzione XXI 1 Ingegneria del software Ciclo di vita del software Fattibilità del progetto Requisiti e specifiche Disegno del sistema Disegno di dettaglio Codifica e test di modulo Integrazione e test globale Installazione e avviamento Modelli alternativi del ciclo di vita del software Waterfall incrementale Prototipazione rapida e successiva Prototipazione evolutiva Produzione automatica di software Tecniche di verifica e validazione Analisi della qualità del software 9

3 VI Ingegneria economica del software ISO 9000, certificazione di qualità I processi di miglioramento nello sviluppo del software Standard per il ciclo di vita del software Processo di acquisizione Processo di fornitura Processo di sviluppo Processo delle operazioni sul sistema Processo di manutenzione Processi di supporto e di organizzazione 23 2 Economia del software Costi e benefici di un progetto software Valutazione dell hardware, del software di base e dei pacchetti specifici Valutazione dello sforzo di sviluppo del software applicativo Valutazione delle risorse per la formazione, l assistenza e l avviamento del processo di informatizzazione Problemi legati al processo di stima 31 3 Metriche del software Importanza delle metriche Costruzione di un sistema per la misurazione del software Stima del valore del sistema per la gestione della misurazione del SW Valutazione del costo del sistema per la gestione della misurazione del SW Creazione del profilo del personale per la gestione del sistema finalizzato alla misurazione del SW Posizionamento e modifica dell organizzazione nell inserimento del sistema per la misurazione del SW Ipotesi di un piano operativo per la gestione del sistema di misurazione del SW 40

4 Sommario VII 3.3 Metriche e qualità Metriche per la qualità del software Caratteristiche standard per la qualità del software Applicazione delle metriche di qualità del software Metriche per la stima dei costi del software Metriche di input Metriche di elaborazione Metriche di output 55 4 Stima del costo del software Comprensione e controllo del processo di SCS Importanza della SCS Sinergia tra SCS e gestione del SW Produttività di sviluppo e ciclo di vita del SW Stime non accurate: conseguenze Conseguenze economiche Conseguenze tecniche Conseguenze manageriali Difficoltà inerenti alla SCS Approcci alla SCS Giudizio di esperti Stima per analogia Modelli algoritmici Criteri di valutazione e confronto Errore relativo medio (RE) Errore relativo assoluto medio Coefficiente di multipla determinazione (R 2 ) Predizione a livello r (PRED(r)) Valore medio relativo della deviazione standard (RMS) Modelli di stima del costo del software Modelli statistici Modelli storico-empirici Modelli teorici Modelli composti 82

5 VIII Ingegneria economica del software 5 Metodologie e modelli consolidati Modello COCOMO di Barry Boehm Fattori correttivi (cost driver) di COCOMO Modello COCOMO base Modello COCOMO intermedio Modello COCOMO dettagliato Punti funzione di Allen Albrecht La metodologia Punti funzione e linee di codice PF e il livello di un linguaggio di programmazione Limiti dei PF Modello ESTIMACS di Howard Rubin Feature Point di Capers Jones Nuove metodologie Dinamica dei sistemi (System Dynamics) Software Project Dynamics di Abdel- Hamid Sviluppo di sistemi esperti Realizzazione di un SE Metodologie di sviluppo Strumenti di sviluppo Categorie di strumenti L hardware Scelta del tool Campi di applicazione ed esempi di SE Interpretazione Diagnostica Monitoraggio Previsione Pianificazione Progettazione Sistemi esperti e stima dei costi del software L euristica Incertezza e carenza dell informazione 129

6 Sommario IX Incongruenza e inconsistenza Esigenza di comprensibilità Accuratezza, oggettività e sensibilità Flessibilità espansibilità Un sistema esperto per la SCS Conoscenza e sua rappresentazione nel processo di SCS Conoscenza ed esperienza di SCS Rappresentazione della conoscenza di SCS Fase di elicitazione Obiettivi dell elicitazione Metodologia dell elicitazione ESSE Filosofia di ESSE Indipendenza dalla completezza dell informazione Specifiche tecnico-architetturali e funzionali Ambiente software di sviluppo Ambiente hardware di sviluppo Interfaccia utente (IU) Base di conoscenza (BC) Modulo di spiegazione (MS) Modulo di What-if-Analysis (WA) Modulo di gestione dei risultati (GR) Base di dati (BD) Il processo di stima in ESSE Interazione con ESSE Informazioni generali Struttura dell applicazione Parametri dimensionali Parametri correttivi Considerazioni sulla gestione dei parametri correttivi Costi del personale e ripartizione delle figure professionali, fase di sviluppo Presentazione dei risultati Dati numerici e grafici Spiegazione della stima 159

7 X Ingegneria economica del software 7.5 Altre funzionalità di ESSE Gestione delle sessioni da conservare Gestione diretta dei FP e KLOCS Gestione dei risultati delle stime Esperienze con ESSE ESSE in una grande azienda assicurativa ESSE in un istituto di credito 161 A Il pacchetto ESSE 165 B Bibliografia 181 I Indice analitico 187

8 P

9 Prefazione La progressiva costruzione di una ingegneria del software si è sviluppata nel corso di circa trent anni, spinta da un industria del software che ha sempre più la necessità di sviluppare i propri prodotti rispettando stringenti (e predicibili) vincoli di tempi e costi e con una qualità che risponda alla domanda sempre più precisa e pressante avanzata dai committenti e dai consumatori finali. Certamente la situazione è oggi assai diversa da quando, nell ormai storica cornice della Conferenza NATO del 1968, venne per la prima volta coniato il termine software engineering, inteso come l obiettivo da raggiungere perché potesse effettivamente nascere e affermarsi un industria del software, capace di creare un mercato per un tipo di prodotti che allora erano del tutto nuovi e in larga misura addirittura difficili da concepire. Era l epoca in cui il software era prevalentemente di tipo custom, e in cui gli sviluppi avvenivano in maniera artigianale, in assenza di metodologie di sviluppo, di strumenti automatici di supporto, di tecniche di previsione e controllo del processo. Oggi la situazione è cambiata profondamente. Il software negli USA è diventato il terzo settore industriale, dopo quello dell automobile e dell elettronica. Un industria come Microsoft è diventata nell immaginario collettivo l emblema dell industria tecnologicamente avanzata e Bill Gates si presenta come l Henry Ford della fine del secolo: l uomo capace di portare l innovazione tecnologica alla portata della gente comune, facendo diventare il software merce di consumo di massa. Per di più, il software controlla, con un affidabilità solitamente adeguata, processi e impianti critici, grazie ai metodi e agli strumenti che sono stati messi a punto nel corso degli ultimi decenni. Concetti chiave della progettazione del software, come la modularità, l incapsulamento e l isolamento delle informazioni, la separazione tra specifica e implementazione sono diventati un patrimonio diffuso tra i progettisti, grazie all affermarsi dei metodi e dei linguaggi object oriented. E la scrittura di software si è progressivamente semplificata grazie all af-

10 XIV Ingegneria economica del software fermarsi dei linguaggi visuali e delle librerie di componenti, sempre più ricche e versatili. Tutto ciò è solo un esempio di quanto progresso si sia compiuto nella direzione della costruzione di una ingegneria del software. Il cammino, peraltro, non è terminato e, anzi, non se ne intravede la fine. Da un lato, infatti, bisogna riconoscere che numerose sono ancora le realtà produttive arretrate, che non si sono poste in maniera seria il problema del miglioramento della qualità dei propri prodotti e dei propri processi produttivi. Si tratta di realtà produttive che difficilmente potranno crescere e affermarsi e che avranno sempre più una vita precaria. Dall altro, occorre osservare che la stessa evoluzione tecnologica obbliga a rivedere continuamente i processi e i prodotti dell industria del software, e quindi a ripensare e rivedere le basi e gli strumenti tipici dell ingegneria del software. Basti pensare a quanto sta accadendo sotto i nostri occhi oggi, con il connubio sempre più stretto tra l informatica e le telecomunicazioni. L affermarsi delle reti, come strumento di connettività e cooperazione all interno delle organizzazioni (Intranet) e tra le diverse organizzazioni (Internet) sta cambiando non solo la classica piattaforma su cui creare applicazioni (non più il singolo elaboratore, ma un sistema distribuito), ma il modo stesso con cui le applicazioni vengono concepite. Per di più, tutto ciò sta facendo nascere tipologie di applicazioni e di servizi del tutto nuove, inconcepibili fino a pochi anni fa, e in larga misura tutte da inventare. Basti pensare a settori come il commercio elettronico, la teleformazione e il telelavoro. Il compito dell ingegneria è proprio quello di collocarsi in una zona critica e vitale delle conoscenze, a cavallo tra due fronti in parte conflittuali: da un lato il consolidamento delle conoscenze, il loro assestamento in un insieme di principi e metodi standard usabili nella pratica industriale e trasferibili ad altri come patrimonio culturale comune e, dall altro, la capacità di creare innovazione nei prodotti e nei processi e di spostare quindi su un terreno sempre nuovo e più avanzato l esigenza del consolidamento. Questo libro vuole offrire un contributo all ingegneria del software. Anzi, come dice l autore, all ingegneria economica del software, intendendo con ciò enfatizzare il fattore costo che nell ingegneria costituisce un attributo essenziale dei prodotti e dei processi. I prodotti software che vengono sviluppati non solo devono raggiungere il loro prescritto livello di qualità, ma devono essere sviluppati entro limiti di costo che consentano un loro successo sul mercato. Il costo deve essere predicibile e i fattori di costo devono essere conosciuti da chi gestisce i progetti software affinché questi possano essere continuamente tenuti sotto controllo. Accanto a una trattazione generale dell ingegneria del software e dei suoi fattori economici, questo libro offre un contributo personale dell autore nella descrizione di un metodo previsionale che deriva dalla sua esperienza pratica di tipo applicativo.

11 Prefazione XV Un indice dell affermarsi dell ingegneria è anche la nascita di figure di ingegneri che si pongono l obiettivo di svolgere un ruolo di testimonial all interno della categoria. Se si osserva la realtà americana, si può rilevare che il numero di testi di informatica pubblicati da parte di testimonial è continuamente crescente. Accanto a testi che hanno un prevalente contenuto scientifico o a testi che hanno un prevalente orientamento didattico, sempre più vengono pubblicati testi che si pongono l obiettivo di offrire il punto di vista di un operatore del settore sui temi di grande rilevanza per il settore stesso. Gli autori di libri che provengono dal settore dei practitioner possono avere un ruolo fondamentale nel promuovere conoscenze e competenze innovative, in quanto spesso sanno parlare un linguaggio che altri loro pari sanno meglio capire, anche perché queste derivano da esperienze pratiche vissute in prima persona. Forse un sintomo della maggiore arretratezza della situazione italiana rispetto a quella internazionale nell ambito del software sta anche nella limitatissima offerta di questo tipo di letteratura tecnico-scientifica. Mi auguro che questo libro, nel porsi accanto ai pochi esempi che lo precedono di contributi da parte di practitioner che vogliono offrire una visione applicativa dei problemi dell ingegneria del software, stia finalmente a significare una inversione di tendenza. Carlo Ghezzi

12 P

13 Premessa Alle mie donne Iran, Vera e Sara Ero tentato di intitolare questo libro Economia dell ingegneria del software piuttosto che Ingegneria economica del software. In effetti il primo titolo è molto meno oscuro, specialmente se viene letto con la dicitura anglosassone Economia del software engineering o come Organizzazione del software engineering, oppure Pianificazione del software engineering, e così via. Alla fine ho optato per il secondo titolo, vuoi per la mia cultura ingegneristica (l Ingegneria non può essere subordinata alla scienza economica!), ma principalmente per sottolineare il vantaggio che l approccio ingegneristico può apportare al mondo informatico, con la maggiore capacità razionale nella gestione delle problematiche di valutazione economica (costi e benefici) della produzione del software. In ogni caso, un titolo o l altro, scopo di questo libro è di descrivere e riportare esperienze maturate attraverso metodologie offerte nel campo dell Ingegneria del software, al fine di meglio valutare lo sforzo necessario per lo sviluppo di un progetto software. L intenzione è pertanto quella di dare un modesto contributo al mondo informatico, rammentando agli addetti ai lavori e non, che oggi vi sono a disposizione strumenti che permettono di valutare preventivamente, con una precisione accettabile, la convenienza economica di informatizzare o meno un processo aziendale. Il libro ha quindi l obiettivo di approfondire i concetti e le metodologie di base, nonché i modelli per la stima dei costi del software. Ringraziamenti La stesura di questo libro è stata possibile grazie all aiuto e alla franca e cortese collaborazione di alcune persone che desidero ringraziare.

14 XVIII Ingegneria economica del software Innanzitutto il professore Ugo Biader Ceipidor che, oltre a incoraggiarmi a portare a termine questa fatica è stato un eccellente compagno di viaggio per percorrere l esperienza nel campo della stima dei costi del software. Senza il suo prezioso supporto la mia conoscenza dell argomento non sarebbe stata tale da poter essere riversata in un libro. Un grazie di cuore anche a tutti i dipendenti della società HELP S.p.A., della quale ho l onore di far parte, che, in modi e momenti diversi, hanno dato il loro contributo affinché questa esperienza fosse anche uno specchio della realtà lavorativa. Ai professori Giorgio Levi e Carlo Montagnero che mi hanno dato l opportunità di assegnare tesi di laurea sull argomento, a due ottimi studenti; Antonio Chojwa e Marco Boraso (corso di Laurea in Scienze dell Informazione presso la Facoltà di Scienze Matematiche, Fisiche e Naturali dell Università degli Studi di Pisa). Va la mia sincera riconoscenza particolare a Marco la cuio tesi è stata fonte di approfondimento teorico delle diverse metodologie esistenti sull argomento di stima e per l aiuto preziosissimo nella preparazione del software demo dell ESSE, parte integrante di questo volume. In particolar modo sono grato al professor Carlo Ghezzi per avermi aiutato con i suoi suggerimenti e per aver cortesemente scritto la prefazione del libro. Infine rivolgo un affettuoso e riconoscente pensiero a mia moglie Vera, senza la cui pazienza questo lavoro non sarebbe mai terminato.

15 I

16 Introduzione È ormai noto che l automazione e la produzione del software stanno diventando i due più grandi fenomeni industriali della storia dell umanità. In uno spazio di 30 anni l evoluzione dei calcolatori e lo sviluppo del software, congiuntamente con i progressi tecnologici nel settore delle telecomunicazioni, hanno raggiunto un livello tale da modificare sostanzialmente il modo di vivere e lavorare dell uomo. Ormai è fuor di dubbio che, dall inizio del nuovo secolo, i computer saranno un elettrodomestico standard di casa e che imparare a programmare diventerà materia di studio nella scuola elementare, come il leggere e lo scrivere. Perché un altro libro sul software? Da un indagine pubblica è risultato che nel 1985 la stima della spesa mondiale nello sviluppo e manutenzione del software è stata di miliardi di lire. È forse ancora più impressionante sapere che, per il 2000, è prevista una spesa superiore a un milione di miliardi di lire. La crescita dello sviluppo industriale del software non è stata comunque indolore. Esistono infatti indicatori ben precisi che rappresentano tali disagi; eccone alcuni: costi aggiuntivi non stimati; ritardi nelle consegne; insoddisfazione dell utente; scarsa qualità del risultato. Per esperienza personale (e siamo certi che chi ha preso in mano questo libro ne conviene) possiamo affermare che nonostante i passi da gigante fatti, tali disagi persistono ancora. La disciplina che principalmente si occupa di gestire le sopracitate difficoltà è l Ingegneria del software. Queste cifre e considerazioni inducono, ancora una volta, a sottolineare che dopo più di cinquant anni dalla nascita del software, ben poco si conosce del suo pro-

17 XXII Introduzione cesso di sviluppo. Pertanto l obiettivo di eliminare i disagi legati alla gestione del ciclo di vita del software è senz altro un processo lungo e difficile. Lo scopo di questa pubblicazione è dunque quello di dare un modesto contributo alla conoscenza del processo di sviluppo del software, affinché si possa provare a gestire male ciò che sarebbe stato gestito comunque peggio!! I capitoli iniziali analizzeranno in breve il processo globale dello sviluppo del software, sia dal punto di vista delle metodologie di analisi e di programmazione, sia da quello delle tecniche di controllo qualità e affidabilità. In seguito verranno illustrate più dettagliatamente le problematiche relative all economia del processo del software e cioè la gestione dei costi e benefici stimati dall introduzione di un sistema informativo automatizzato in una organizzazione. Nei capitoli centrali verrà affrontato l argomento della metrica del software con particolare riguardo al processo della stima dei costi del software allo sviluppo di metodologie e tecniche attualmente in uso. Si evidenzia poi, il problema della stima con la descrizione delle difficoltà e dei limiti di ciascuna tecnica e delle conseguenze di una cattiva stima. Verranno inoltre presentati, in dettaglio i modelli per la stima dei costi del software più conosciuti e consolidati a livello internazionale. I capitoli finali si occuperanno dell applicazione della tecnologia di sistemi esperti nel campo della stima dei costi del software. Infatti, dopo una descrizione delle tecnologie di sistemi basati sulla conoscenza e del rapporto fra sistemi esperti e il processo di stima dei costi del software, verrà descritta la filosofia, l architettura e l operatività del sistema ESSE, un sistema per la stima dei costi del software sviluppato interamente in Italia utilizzando la tecnologia dei sistemi esperti.

18 1 1.1 Ciclo di vita del software, Modelli alternativi del ciclo di vita del software, Tecniche di verifica e validazione, Analisi della qualità del software, Standard per il ciclo di vita del software, 17

19 Ingegneria del software L Ingegneria del software è la scienza che, usufruendo delle conoscenze della Matematica e dell Economia, studia come rendere utili all uomo le potenzialità dei computer per mezzo di programmi, procedure operative e documentazioni loro associate. L Ingegneria del software è una disciplina tecnologica e manageriale che riguarda la produzione sistematica e la manutenzione dei prodotti software che vengono sviluppati e modificati entro i tempi e i costi preventivati. A tali definizioni, tratte dal libro di Boehm [9] e di Ghezzi [34], vorremmo aggiungere un ulteriore valore affermando che, oltre alla Matematica, all Economia e al Managament, si deve tenere conto in modo particolare dell organizzazione, affinché la scienza e/o disciplina dell Ingegneria del software possa mettere in evidenza tutta la potenzialità del computer e porla al servizio dell uomo. Va da sé che l Ingegneria del software include ben più della sola arte della programmazione. Infatti, dato un processo da automatizzare, essa ha il compito di guidare tutte le attività legate al ciclo di vita dell automazione informatica. 1.1 Ciclo di vita del software La difficoltà di gestione del processo di sviluppo del software (SW) emerge principalmente dalla complessità dell applicazione, dall abilità delle risorse coinvolte e dalle caratteristiche del sistema (hardware HW e SW di base) sul quale viene installato il SW applicativo. È sempre più difficile controllare la complessità del processo; la gestione diventa più ardua con l evoluzione rapida della tecnologia che influenza continuamente le prestazioni del sistema. Diventa perciò sempre più importante capire e quindi gestire tutte le fasi di sviluppo del software. In teoria si tende a considerare il ciclo del processo di sviluppo software attraverso delle fasi. Ogni fase viene identificata con un punto di partenza (input) e uno di arrivo (output).

20 2 Ingegneria del software Ci preme sottolineare subito che tale definizione teorica viene spesso contraddetta dalla realtà operativa che mette in evidenza la sovrapposizione continua delle fasi. Per poter definire le metriche dipendenti da ciascuna fase è necessario descrivere più precisamente tutte le attività appartenenti a ciascuna fase del ciclo. Il modello del ciclo maggiormente accettato è quello denominato a cascata (Waterfall) [9]. Le fasi principali di tale modello sono riportate qui di seguito Fattibilità del progetto Lo studio di fattibilità cerca di verificare tutte le potenzialità, i limiti e i vincoli del progetto che si vuole realizzare, mettendo in evidenza una stima di massima di costi e benefici, spesso dal punto di vista strettamente economico. Anche se il risultato dello studio è generalmente una prima analisi tecnica del progetto, la quale in un certo senso anticipa la successiva fase dei requisiti, crediamo che si debba modificare un po questa tendenza, orientando tale studio nella direzione della verifica oggettiva di fattibilità (lo dice la parola stessa!), riuscendo quindi a esaminare l opportunità o meno di realizzazione del progetto in esame dando una valutazione più ampia dei costi e benefici Requisiti e specifiche La fase successiva allo studio di fattibilità comprende l analisi funzionale dei requisiti e delle caratteristiche delle prestazioni del progetto. L obiettivo è una stima delle esigenze delle risorse necessarie, nonché del budget economico del progetto. L input necessario a questa fase è dato dal risultato delle interviste agli utenti e ai gestori del sistema. Le attività precipue, in questa fase, sono la piena comprensione dei requisiti, la definizione dello scopo del sistema, la determinazione dell ambiente operativo in cui il sistema si inserirà e le eventuali interfacce con i sistemi esterni. L output di questa fase è composto generalmente da due documenti; i requisiti utente (User Requirements) e i requisiti del sistema (System Requirements). Entrambi i documenti sono critici per tutte le fasi del progetto in quanto forniscono la piattaforma di accettazione a fronte della quale il sistema verrà valutato Disegno del sistema Nella fase di disegno del sistema vengono specificate l architettura e la configurazione globale del sistema. Viene inoltre definita la struttura dei sottosistemi e gli eventuali moduli di ciascun sottosistema del progetto e le loro interfacce, e specificato il/i linguaggio/i di programmazione e di sviluppo, nonché le strutture di controllo e un piano di test generale.

21 Ingegneria del software 3 Il sistema viene ripartito in maniera congruente in moduli da sviluppare in aree funzionali omogenee, quindi vengono individuati i gruppi di lavoro responsabili dello sviluppo della rispettiva area. L input della fase è essenzialmente il documento requisiti utente, mentre l output è normalmente rappresentato dal documento progetto dell architettura (Architectural Design) oppure dalla descrizione del prodotto, se si tratta di sviluppo di un prodotto programma (Package) Disegno di dettaglio La fase del disegno di dettaglio prevede: l analisi dettagliata di ciascun modulo da sviluppare; la descrizione delle strutture per la comunicazione fra i moduli; la definizione del processo elaborativo dei moduli; l identificazione della struttura dei dati di interfaccia e i controlli interni; la descrizione di un piano di test specificato per ciascun modulo e degli eventuali vincoli di prestazioni (per esempio, il tempo di esecuzione, lo spazio di occupazione della memoria ecc.). L input della fase è rappresentato dal documento della fase precedente, l output è un ulteriore documento, normalmente chiamato progetto di dettaglio (Detailed Design) Codifica e test di modulo In questa fase viene sviluppato il codice relativo a tutti i moduli analizzati precedentemente nel linguaggio o linguaggi prescelti. Sulla base di un piano vengono eseguiti tutti i test dei moduli, generalmente in una sequenza predefinita (catena di test). Tale sequenza dovrà essere eseguita ogni qualvolta viene modificato uno qualsiasi dei moduli della catena. La produzione del codice sorgente può iniziare al termine del disegno dettagliato di un singolo modulo previa revisione e approvazione. Generalmente lo sviluppo del codice viene condotto in parallelo da più sviluppatori software e pertanto è di primaria importanza che le interfacce fra i vari moduli e le corrispondenti funzioni siano ben definite prima dell inizio della fase. L attività di codifica dei moduli è fortemente basata sul documento del dettaglio prodotto nella fase precedente. Gli output di questa fase sono il listato del codice sorgente (Source Code) e il manuale utente.

22 4 Ingegneria del software Integrazione e test globale Questa fase, che idealmente dovrà essere svolta da un gruppo di persone indipendenti dal gruppo originale del progetto, ha l obiettivo di integrare tutti i moduli sviluppati e testati separatamente nella fase precedente. Il suo compito è quindi quello di verificare la completa funzionalità del sistema attraverso una serie di test globali (predefiniti in parte nelle fasi precedenti), atti ad accertare tutti i requisiti funzionali del progetto. I documenti di input della fase sono: requisiti utente, requisiti del sistema, progetto dell architettura e progetto di dettaglio. Il documento di output è sostanzialmente un verbale sugli esiti del test globale effettuato e l insieme delle schede di anomalie riscontrate che dovranno essere chiuse (risolta e verificata la loro correttezza all interno del sistema) Installazione e avviamento La fase prevede il rilascio, l installazione e l avviamento del sistema presso l utente finale, nonché la verifica della funzionalità operativa dei requisiti del sistema HW-SW nell ambiente di esercizio. Essa comprende la conclusione e consegna della documentazione tecnico-operativa del progetto, nonché l eventuale formazione e messa in esercizio del sistema. L input a questa fase viene rappresentato dal manuale utente che dovrà comprendere anche tutto ciò che è necessario per l installazione, l avviamento e la gestione del sistema. L output è il documento conclusivo del rilascio del sistema e viene spesso rappresentato da un verbale di accettazione. 1.2 Modelli alternativi del ciclo di vita del software Il classico modello Waterfall (a cascata), citato precedentemente, è stato descritto per la prima volta da Royce [70] nei primi anni 70 e, successivamente rifinito da Boehm [9] (Figura 1.1) nel 1976, per permettere di affrontare, con maggior supporto, la complessità dei progetti software. I vantaggi offerti dall utilizzo del modello Waterfall possono essere sintetizzati nei seguenti punti: caldeggia la specificazione degli obiettivi del sistema (definizione dei requisiti), prima di definire l architettura dello stesso (disegno); invita a pianificare in anticipo le modalità di interazione fra i componenti del sistema (disegno), prima della costruzione dei componenti stessi (codifica); supporta il capo progetto nella gestione dello sviluppo e permette di scoprire in anticipo gli scostamenti dal piano operativo;

23 Ingegneria del software 5 sollecita la produzione della documentazione nel processo di sviluppo che potrà essere utilizzata nella fase di test e manutenzione del sistema; riduce globalmente i costi di sviluppo e di manutenzione del sistema; impone all organizzazione del gruppo di lavoro una struttura operativamente più gestibile. L utilizzo dell approccio di sviluppo con il modello a cascata è condiviso da molti nel campo del Software Engineering e viene spesso corredato da una serie di nozioni che permettono al Project Manager di gestire e controllare i progetti con maggiore consapevolezza. La scelta del modello del ciclo di vita e quindi la distribuzione delle risorse da impegnare nelle varie fasi di sviluppo gioca un importante ruolo nel supportare il Project Manager nella stima dell allocazione delle risorse necessarie nello sviluppo del SW. Kustanowitz [56] sostiene che la dimensione di un progetto influenza Studio di fattibilità Verifica e validazione di studio di fattibilità Analisi e specifica dei requisiti Verifica e validazione di analisi e specifiche dei requisiti Disegno di prodotto Verifica e validazione di disegno di prodotto Disegno di dettaglio Verifica e validazione di disegno di dettaglio Codifica di moduli Test unitari di codifica di moduli Integrazione Verifica e test globale Installazione e manutenzione Verifica e validazione del sistema Manutenzione Verifica e validazione Figura 1.1 Schema di modello a cascata.

24 6 Ingegneria del software notevolmente la distribuzione delle risorse nelle varie fasi di sviluppo (Figura 1.2). Ancora oggi la maggior parte delle grandi organizzazioni pubbliche e private segue il modello a cascata, spesso denominando le varie attività e i documenti prodotti con diciture diversificate e abbinando più fasi in un unica soluzione. Infatti, la fase dei requisiti e specifiche viene frequentemente denominata analisi delle esigenze dell utente o analisi del sistema, il disegno del prodotto viene spesso chiamato disegno preliminare, disegno ad alto livello oppure definizione dell architettura del software, mentre il disegno dettagliato viene indicato con disegno del programma, disegno a basso livello. Negli ultimi vent anni sono state sviluppate metodologie alternative al modello Waterfal: Waterfall incrementale; prototipazione rapida e successiva; prototipazione evolutiva; produzione automatica di software sintetico; altre metodologie. Tutte queste metodologie hanno in comune il concetto di ricorsività che permette di affrontare il problema del ciclo di vita del software utilizzando la caratteristica dell approccio incrementale. Percentuale del progetto totale 100 Piccola Media Grande Test 10-20% Test 20-30% Test 30-45% 50 Coding 60-80% Coding 40-60% Coding 10-40% Disegno 10-20% Disegno 20-30% Disegno 30-45% 0 Dimensione del progetto Figura 1.2 Percentuale del progetto totale.

25 Ingegneria del software Waterfall incrementale L obiettivo principale di questa metodologia è quello di utilizzare il modello Waterfall iterativamente, attraverso un approccio incrementale per permettere l aumento progressivo delle capacità funzionali del sistema software in esame. La Figura 1.3 [9] rappresenta chiaramente le modifiche apportate all approccio Waterfall classico. L evidente vantaggio operativo che ne consegue è dato dalla distribuzione più equilibrata delle risorse (non più a campana!), nelle varie fasi di sviluppo. Studio di fattibilità Validazione e verifica dello studio di fattibilità Analisi e specifiche dei requisiti Validazione e verifica dell analisi e specifiche dei requisiti Disegno del progetto Incremento 1 Disegno di dettaglio Verifica e validazione Codifica di moduli Test unitari Verifica e validazione Installazione Verifica e test globale Incremento 2 Disegno di dettaglio Integrazione Verifica e validazione del sistema Incremento 3 Disegno di dettaglio Codifica di moduli Integrazione Manutenzione Verifica e validazione Codifica di moduli Installazione Figura 1.3

26 8 Ingegneria del software Prototipazione rapida e successiva Nel caso della prototipazione rapida e successiva ci si propone l obiettivo di assicurare che il prodotto sviluppato incontri il più possibile le esigenze dell utente [21], [36]. L approccio ha lo scopo di costruire un implementazione veloce e sporca! del sistema durante la fase dei requisiti. L utente virtuale utilizza il prototipo per un certo periodo e rileva le potenzialità e i limiti da lui percepiti. Questo feedback, che viene riportato più volte, è utilizzato per modificare progressivamente i requisiti e renderli sempre più rispondenti alle esigenze dell utente. Conseguentemente vengono intraprese le successive fasi di disegno e di implementazione del sistema reale, con la consapevolezza di stare sviluppando il software giusto (specialmente laddove le esigenze dell utente si modificano durante l utilizzo del sistema). Un evoluzione di questo approccio prevede una serie di prototipi implementa, verifica e getta via! [12] che porta successivamente allo sviluppo definitivo del sistema Prototipazione evolutiva Lo sviluppatore implementa tutti i requisiti conosciuti. Il prototipo viene dato all utente per verificare ciò che è stato realizzato, ma anche per meglio definire ulteriori requisiti. Rispetto alla precedente prototipazione (in cui la metodologia imponeva di implementare comunque tutti i requisiti conosciuti con l obiettivo di incrementare e correggere le funzionalità dei requisiti), questo approccio suppone che l utente non conosca realmente tutte le esigenze e che quindi debba operativamente interagire con il sistema per identificarle. L applicazione di tale metodica è evidentemente più adatta a quei processi i cui requisiti non siano tutti ben noti e che abbiano quindi bisogno di essere sperimentati per essere conosciuti (differentemente dalla metodologia precedente dove i requisiti sono sufficientemente conosciuti e si decide di svilupparli in progressione) [61] Produzione automatica di software Con questo termine si intende la trasformazione dei requisiti o meglio il disegno ad alto livello del sistema in codice operativo. Il processo di decodifica può essere effettuato attraverso tecniche algoritmiche [65] oppure approcci basati sulla conoscenza [6]. È evidente che questo tipo di procedimento permette di ricodificare i moduli a ogni variazione e/o integrazione dei requisiti, incrementando con passi successivi le funzionalità del sistema finale [64].

27 Ingegneria del software Tecniche di verifica e validazione L obiettivo globale di un software è sia quello di raggiungere i requisiti prestabiliti sia di fare in modo che il codice sviluppato risolva le esigenze di partenza. Le tecniche di verifica sono orientate a stabilire la congruenza fra le specifiche del software, identificate nella fase iniziale del ciclo di vita, e il prodotto realizzato al termine. Le tecniche di validazione invece prendono in esame l adeguatezza del prodotto risultante, rispetto alle reali esigenze operative. Boehm [9] esplicita i problemi di verifica e di validazione attraverso le seguenti domande: Si sta costruendo il prodotto in modo corretto? Verifica; Si sta costruendo il prodotto corretto? Validazione. Come si può intuire, le attività di verifica e di validazione devono essere presenti in tutte le fasi di sviluppo: dalla validazione dei requisiti e verifica dei tool di disegno e sviluppo, alla verifica delle prestazioni e delle validazioni dei test operativi. Quindi il volume e la complessità dei progetti software attuali impongono che le metodologie di verifica e di validazione vengano applicate su tutto il ciclo di vita del software, prima che inizi la fase specifica del testing. Questa attività di pretesting comprende: requisiti di verifica; progettazione e disegno di ispezioni (Walkthrough); progettazione e disegno di misure di qualità; definizione di interfacce di controllo; programmi (codice) di ispezione; progettazione e disegno di revisioni formali. Tutto ciò è giustificato dal fatto che la correzione degli errori scoperti in anticipo costa sempre meno. Nella Figura 1.4, tratta da Deutsch [25], vengono riportate le attività di verifica e validazione che dovranno essere prese in considerazione durante tutte le fasi del ciclo di vita del software. 1.4 Analisi della qualità del software L analisi e la valutazione della qualità del software rivestono un importanza sempre maggiore non solo per il produttore ma anche per il consumatore del software. Gli utilizzatori dell informatica esigono più che mai di potersi fidare totalmente del software acquistato.

28 10 Ingegneria del software Definizione dei requisiti Sviluppo Manutenzione Specifiche Definizioni Disegno Produzione Test Integrazioni Verifica dei requisiti del sistema Verifica dei requisiti del disegno Verifica del disegno preliminare Verifica del disegno dettagliato Auditing della configurazione fisico/funzionale Auditing della configurazione fisico/funzionale Auditing della configurazione fisico/funzionale Ingegneria del sistema Conduzione della verifica dei requisiti del sistema Conduzione della verifica del disegno di sistema Conduzione della verifica del disegno preliminare Conduzione della verifica del disegno dettagliato Verifica delle modifiche proposte Valutazione dei risultati del test Valutazione dei risultati del test Coordinamento dei problemi sul disegno/ interfaccia di sistema Simulazione delle performance del sistema Definizione delle metriche degli standard di qualità SW Definizione dei criteri del test di accettazione Verifica delle proposte di modifica Coordinamento dei problemi sul disegno/ interfaccia di sistema Verifica delle proposte di modifica Coordinamento dei problemi sullo svolgimento del test Preparazione del diagramma della verifica del sistema Preparazione del diagramma della validazione del sistema per ciascuna CPCI (Computer Program Configuration Item) Verifica delle proposte di modifica Coordinamento dei problemi sul disegno/ interfaccia di sistema Coordinamento dei problemi sul disegno/ interfaccia di sistema Coordinamento dei problemi sul disegno/ interfaccia di sistema Coordinamento dei problemi sullo svolgimento del test Coordinamento dei problemi sul disegno/ interfaccia di sistema Installazione dei tool di sviluppo di sistema Sviluppo software Verifica della documentazione dei requisiti Verifica della documentazione dei requisiti Conduzione del disegno informale dei walkthrough Conduzione del disegno informale dei walkthrough Conduzione dei test informali sul codice Provvedere supporto ai test formali di qualità per i CPCI Provvedere supporto per i test di integrazione Conduzione dei test informali sui codici relativi ai CPCI Misurazione della qualità del disegno Misurazione della qualità del disegno Conduzione della preparazione dei test unitari Conduzione degli audit Partecipazione nella verifica del disegno preliminare Preparazione dei piani dei CPCI Partecipazione nella verifica del disegno dettagliato Preparazione dei piani di test globali Coordinamento dei problemi nello svolgimento dei test Conduzione degli audit Figura 1.4

29 Ingegneria del software 11 Fino alla metà degli anni 70, la misura per valutare la qualità di un software, era data dal numero di volte che il prodotto veniva effettivamente utilizzato. Altre modalità di valutazione della qualità sono state successivamente proposte da più parti, creando confusioni sia per il consumatore sia per il produttore del software. Per queste ragioni alla fine degli anni 70, all interno dell organismo ISO (International Organization for Standardization), è stato creato un gruppo di lavoro operativo per definire delle norme, su base mondiale, nell ambito della qualità del software. Oggi tali norme sono un punto di riferimento sicuro, specialmente per i produttori di software, per quanto riguarda gli standard di qualità. Per i consumatori del software invece, esistono più modi per accertare la bontà e quindi l affidabilità del prodotto che vanno a utilizzare. L approccio più frequente è quello di verificare la qualità del prodotto attraverso delle misure e calcolo degli indici. Per tradizione, la qualità del software viene misurata attraverso due parametri principali: il numero e la tipologia dei test pianificati ed effettuati nonché i relativi risultati; il numero e la tipologia di errori (bachi) riscontrati nella fase dei test. Anche le caratteristiche principali di un approccio innovativo nell affrontare il problema della misurazione della qualità del SW possono essere raggruppate in due punti: misurare la qualità del SW non solo nella fase di test, ma in ciascuna fase di sviluppo; definire un insieme di indici della qualità di codice sorgente. Per quanto riguarda il primo punto, in realtà, più che una caratteristica esso è un atteggiamento metodologico, mentre il secondo punto impone una serie di misurazioni che permettono di quantificare oggettivamente la qualità del prodotto SW. Di seguito riportiamo due categorie consolidate di indici della qualità del SW: Indici basati sulla metrica, proposti da McCabe [60]: numero di istruzioni condizionanti (IF, WHILE, CASE ecc); numero di livelli di instradamento delle procedure; numero di istruzioni di puntamento con salto (GO TO). Indici basati sulla metrica di Halstead [37]: numero di operatori usati nelle procedure; numero di operanti usati nelle procedure.

30 12 Ingegneria del software Un sistema che tiene conto delle due categorie di indici sopra menzionate è ESQUT (Evaluation of Software Quality from User s viewpoint), sviluppato nei laboratori di System & Software Engineering della Toshiba [41]. Questo sistema integra le due metriche di McCabe e Halstead con altre misure e permette di valutare globalmente la qualità del software attraverso una verifica formale di tutte le fasi del ciclo di sviluppo, tenendo presente la complessità, la funzionalità e la comprensibilità del sistema. La Tabella 1.1 rappresenta la correlazione esistente fra gli indici misurabili nella fase di coding e le caratteristiche del modello di qualità (complessità, funzionalità e comprensibilità). ESQUT permette di definire, nella fase del disegno, una serie di indici di qualità attraverso anche delle misure che vengono effettuate con le stesse caratteristiche identificate nella fase di coding: complessità del disegno per ciascun modulo; funzionalità (volume delle funzioni) di ciascun modulo; comprensibilità, ovvero leggibilità e unicità di interpretazione del modulo disegnato. Le metriche principali prese in considerazione e non dipendenti dalla metodologia adottata sono: numero di procedure disegnate; numero di rami condizionali per definire le procedure all interno di un modulo; numero di livelli di innestamenti all interno di ciascun modulo; numero di procedure ripetute all interno di ciascun modulo. Tabella 1.1 Complessità Funzionalità Comprensibilità N. di istruzioni GO TO X X N. moduli X N. di istruzioni condizionanti X X N. di blocchi procedurali X N. di livelli di innestamento X N. di operazioni X X X N. di istruzioni X X X N. di dati X

31 Ingegneria del software 13 Anche per la fase di disegno del software è possibile quindi, identificare una serie di indici, correlati attraverso dei coefficienti standard, calcolati sperimentalmente in relazione alle caratteristiche del software. La valutazione della qualità del software, nella fase di disegno, avviene verificando la deviazione dei coefficienti di correlazione calcolati rispetto a quelli standard ISO 9000, certificazione di qualità Dopo un inizio in sordina le norme ISO serie 9000 hanno effettivamente suscitato interesse e avuto seguito nelle realtà progettuali e produttive dell industria e della Pubblica Amministrazione a livello mondiale. In Europa si contano ormai oltre aziende che, nei vari settori merceologici, hanno ottenuto la certificazione ISO Tale interesse dipende principalmente dal fatto che gli standard sono accentrati sulla qualità e che le norme contengono i requisiti minimi di un sistema qualità. Come riportato nella Figura 1.5 la serie ISO 9000 comprende un insieme di direttive guida e tre tipi di norme: 1. ISO 9001 UNI EN [43] Norme per l assicurazione della qualità nella progettazione, sviluppo, fabbricazione, installazione e assistenza; 2. ISO 9002 UNI EN [44] Norme per l assicurazione della qualità nella fabbricazione, installazione e assistenza; ISO 9000 serie di norme ISO linee guida per la scelta e l utilizzazione ISO 9001 progettazione sviluppo fabbricazione installazione assistenza ISO 9002 fabbricazione installazione assistenza ISO 9003 ispezione test ISO linee guida per la gestione di qualità ISO linee guida per il software ISO linee guida per assistenza Figura 1.5

32 14 Ingegneria del software 3. ISO UNI EN [45] Norme per l assicurazione della qualità nel l ispezione e test. Tuttavia da sole tali norme sono poco adatte alla realtà del software. Quella che trova maggiore applicazione nel campo del software è ISO 9001 accoppiata alla direttiva guida ISO [42] che è stata redatta appositamente per interpretare lo standard ISO 9001 finalizzato allo sviluppo e la manutenzione del software. La struttura della guida ISO per la qualità del software è riportata nella Figura 1.6 e delinea lo spirito con il quale le norme ISO affrontano il problema di certificazione del processo di sviluppo del software. Sistema qualità Struttura Attività Responsabilità della direzione Sistema di qualità Verifiche ispettive Azioni correttive Attività del ciclo di vita Attività del supporto Riesame del contratto Specifica requisiti committente Pianificazione dello sviluppo Pianificazione della qualità Progettazione e realizzazione Verifica e validazione Accettazione Duplicazione, consegna, installazione Manutenzione Gestione configurazione Controllo documentazione Documentazione regole qualità Misure Regole, pratiche e convenzioni Strumenti e tecniche Approvvigionamenti Prodotti inclusi Addestramento Figura 1.6

33 Ingegneria del software I processi di miglioramento nello sviluppo del software Per un organizzazione che sviluppa e fa manutenzione di prodotti software, la certificazione ISO 9001 offre non pochi suggerimenti circa la maturità e la capacità del processo. Il miglioramento del processo di produzione software non è un azione indolore poiché è necessario riorganizzare le varie attività di sviluppo e manutenzione per rendere la produzione più adeguata e conforme alle esigenze del mercato. I processi di miglioramento riguardano sia la capacità sia l efficienza dell organizzazione, perché da una parte, rendono il processo più prevedibile e controllabile, e dall altra, (insieme al miglioramento dell efficienza) contribuiscono al miglioramento della qualità dei prodotti software [77]. Il principio del miglioramento continuo si basa su un progresso che avviene lentamente, in modo stabile, supportato da piccole vittorie quotidiane e incorporando innovazioni. Questo può avvenire attraverso la valutazione della qualità (Quality Assessment) e l uso di una metodologia per raggiungere tali obiettivi. Il metodo consiste in ripetute applicazioni del processo Plan, Do, Check, Act (PDCA) e cioè pianifica-fai-verifica-comportati, fino al raggiungimento di un obiettivo. Le quattro fasi del Plan, Do, Check, Act rappresentano l iter mentale che deve essere continuamente applicato per agire con successo. Il metodo può inoltre includere una fase iniziale (Initiate) che crea la base necessaria per una efficace applicazione delle iterazioni. Le fasi Initiate, Plan e Check possono includere le attività di valutazione. La valutazione del processo di sviluppo software (Software Process Assessment) costituisce oggi un prerequisito per impostare un valido piano di miglioramento. Essa determina lo stato corrente del processo di produzione nonché le difficoltà che ne impediscono l evoluzione; può essere infatti applicata durante il ciclo o anche dopo l applicazione delle attività di miglioramento, allo scopo di confermare i progressi ottenuti. La metodologia è generalmente caratterizzata dai seguenti passi: 1. valutazione dello stato corrente di maturità del processo; 2. analisi dei risultati della valutazione allo scopo di definire le priorità di intervento; 3. definizione del piano di miglioramento; 4. attuazione delle attività di miglioramento; 5. misurazione e definizione quantitativa dei progressi. Per classificare la maturità del processo di sviluppo software il modello più conosciuto è Capability Maturity Model (CMM). Tale modello, sviluppato dal SEI