Autore: Habib Sedehi - Programmazione, web marketing ... · 1.1.3 Disegno del sistema 2 1.1.4...

Ingegneria economica del software

Autore:Habib Sedehi

Copyright per l’edizione italiana© 1997 – APOGEOViale Papiniano 38 – 20123 Milano (Italy)Telefono: 02-461920 (5 linee r.a) – Telefax: 02-4815382email: [email protected].: http://www.urra.it

ISBN 88-7303-315-6

Progetto di copertina: OZdesign, Milano

Tutti i diritti sono riservati a norma di legge e a norma delle convenzioni internazio-nali. Nessuna parte di questo libro può essere riprodotta con sistemi elettronici,meccanici o altri, senza l’autorizzazione scritta dell’Editore.

Sommario

P Prefazione XIII

P Premessa XVII

I Introduzione XXI

1 Ingegneria del software 11.1 Ciclo di vita del software 11.1.1 Fattibilità del progetto 21.1.2 Requisiti e specifiche 21.1.3 Disegno del sistema 21.1.4 Disegno di dettaglio 31.1.5 Codifica e test di modulo 31.1.6 Integrazione e test globale 41.1.7 Installazione e avviamento 4

1.2 Modelli alternativi del ciclo di vita del software 41.2.1 Waterfall incrementale 71.2.2 Prototipazione rapida e successiva 81.2.3 Prototipazione evolutiva 81.2.4 Produzione automatica di software 8

1.3 Tecniche di verifica e validazione 91.4 Analisi della qualità del software 9

VI Ingegneria economica del software

1.4.1 ISO 9000, certificazione di qualità 131.4.2 I processi di miglioramento nello sviluppo del software 15

1.5 Standard per il ciclo di vita del software 171.5.1 Processo di acquisizione 171.5.2 Processo di fornitura 191.5.3 Processo di sviluppo 191.5.4 Processo delle operazioni sul sistema 221.5.5 Processo di manutenzione 221.5.6 Processi di supporto e di organizzazione 23

2 Economia del software 27

2.1 Costi e benefici di un progetto software 272.1.1 Valutazione dell’hardware, del software di base

e dei pacchetti specifici 282.1.2 Valutazione dello sforzo di sviluppo

del software applicativo 292.1.3 Valutazione delle risorse per la formazione,

l’assistenza e l’avviamento del processodi informatizzazione 30

2.2 Problemi legati al processo di stima 31

3 Metriche del software 35

3.1 Importanza delle metriche 353.2 Costruzione di un sistema

per la misurazione del software 363.2.1 Stima del “valore” del sistema per la gestione

della misurazione del SW 373.2.2 Valutazione del “costo” del sistema per la gestione

della misurazione del SW 383.2.3 Creazione del “profilo” del personale per la gestione

del sistema finalizzato alla misurazione del SW 393.2.4 Posizionamento e modifica dell’organizzazione

nell’inserimento del sistema per la misurazione del SW 393.2.5 Ipotesi di un “piano” operativo per la gestione

del sistema di misurazione del SW 40

Sommario VII

3.3 Metriche e qualità 423.4 Metriche per la qualità del software 453.4.1 Caratteristiche standard per la qualità del software 463.4.2 Applicazione delle metriche di qualità del software 49

3.5 Metriche per la stima dei costi del software 493.5.1 Metriche di input 503.5.2 Metriche di elaborazione 543.5.3 Metriche di output 55

4 Stima del costo del software 57

4.1 Comprensione e controllo del processo di SCS 584.2 Importanza della SCS 594.3 Sinergia tra SCS e gestione del SW 594.4 Produttività di sviluppo e ciclo di vita del SW 604.5 Stime non accurate: conseguenze 614.5.1 Conseguenze economiche 614.5.2 Conseguenze tecniche 614.5.3 Conseguenze manageriali 62

4.6 Difficoltà inerenti alla SCS 624.7 Approcci alla SCS 644.7.1 Giudizio di esperti 644.7.2 Stima per analogia 654.7.3 Modelli algoritmici 65

4.8 Criteri di valutazione e confronto 664.8.1 Errore relativo medio (RE) 674.8.2 Errore relativo assoluto medio 674.8.3 Coefficiente di multipla determinazione (R2) 684.8.4 Predizione a livello r (PRED(r)) 684.8.5 Valore medio relativo della deviazione standard (RMS) 68

4.9 Modelli di stima del costo del software 694.9.1 Modelli statistici 694.9.2 Modelli storico-empirici 734.9.3 Modelli teorici 754.9.4 Modelli composti 82

VIII Ingegneria economica del software

5 Metodologie e modelli consolidati 85

5.1 Modello COCOMO di Barry Boehm 855.1.1 Fattori correttivi (cost driver) di COCOMO 875.1.2 Modello COCOMO base 895.1.3 Modello COCOMO intermedio 905.1.4 Modello COCOMO dettagliato 92

5.2 Punti funzione di Allen Albrecht 965.2.1 La metodologia 995.2.2 Punti funzione e linee di codice 1045.2.3 PF e il livello di un linguaggio di programmazione 1045.2.4 Limiti dei PF 107

5.3 Modello ESTIMACS di Howard Rubin 1085.4 Feature Point di Capers Jones 1105.5 Nuove metodologie 1135.5.1 Dinamica dei sistemi (System Dynamics) 1135.5.2 Software Project Dynamics di Abdel- Hamid 114

6 Sviluppo di sistemi esperti 119

6.1 Realizzazione di un SE 1196.1.1 Metodologie di sviluppo 1206.1.2 Strumenti di sviluppo 1216.1.3 Categorie di strumenti 121

6.2 L’hardware 1246.3 Scelta del tool 1256.4 Campi di applicazione ed esempi di SE 1256.4.1 Interpretazione 1256.4.2 Diagnostica 1266.4.3 Monitoraggio 1266.4.4 Previsione 1276.4.5 Pianificazione 1276.4.6 Progettazione 127

6.5 Sistemi esperti e stima dei costi del software 1286.5.1 L’euristica 1296.5.2 Incertezza e carenza dell’informazione 129

Sommario IX

6.5.3 Incongruenza e inconsistenza 1296.5.4 Esigenza di comprensibilità 1296.5.5 Accuratezza, oggettività e sensibilità 1306.5.5 Flessibilità espansibilità 130

6.6 Un sistema esperto per la SCS 1306.7 Conoscenza e sua rappresentazione

nel processo di SCS 1316.7.1 Conoscenza ed esperienza di SCS 1326.7.2 Rappresentazione della conoscenza di SCS 133

6.8 Fase di elicitazione 1356.8.1 Obiettivi dell’elicitazione 1356.8.2 Metodologia dell’elicitazione 137

7 ESSE 139

7.1 Filosofia di ESSE 1397.1.1 Indipendenza dalla completezza dell’informazione 140

7.2 Specifiche tecnico-architetturali e funzionali 1407.2.1 Ambiente software di sviluppo 1407.2.2 Ambiente hardware di sviluppo 1417.2.3 Interfaccia utente (IU) 1417.2.4 Base di conoscenza (BC) 1427.2.5 Modulo di spiegazione (MS) 1437.2.6 Modulo di What-if-Analysis (WA) 1437.2.7 Modulo di gestione dei risultati (GR) 1457.2.8 Base di dati (BD) 145

7.3 Il processo di stima in ESSE 1467.3.1 Interazione con ESSE 1467.3.2 Informazioni generali 1477.3.3 Struttura dell’applicazione 1487.3.4 Parametri dimensionali 1487.3.5 Parametri correttivi 1527.3.6 Considerazioni sulla gestione dei parametri correttivi 1557.3.7 Costi del personale e ripartizione delle figure

professionali, fase di sviluppo 157

7.4 Presentazione dei risultati 1587.4.1 Dati numerici e grafici 1587.4.2 Spiegazione della stima 159

X Ingegneria economica del software

7.5 Altre funzionalità di ESSE 1597.5.1 Gestione delle sessioni da conservare 1597.5.2 Gestione diretta dei FP e KLOCS 1607.5.3 Gestione dei risultati delle stime 160

7.6 Esperienze con ESSE 1607.6.1 ESSE in una grande azienda assicurativa 1607.6.2 ESSE in un istituto di credito 161

A Il pacchetto ESSE 165

B Bibliografia 181

I Indice analitico 187

Prefazione

La progressiva costruzione di una “ingegneria” del software si è sviluppata nelcorso di circa trent’anni, spinta da un’industria del software che ha sempre più lanecessità di sviluppare i propri prodotti rispettando stringenti (e predicibili) vin-coli di tempi e costi e con una qualità che risponda alla domanda sempre piùprecisa e pressante avanzata dai committenti e dai consumatori finali. Certamentela situazione è oggi assai diversa da quando, nell’ormai storica cornice della Con-ferenza NATO del 1968, venne per la prima volta coniato il termine softwareengineering, inteso come l’obiettivo da raggiungere perché potesse effettivamentenascere e affermarsi un’industria del software, capace di creare un “mercato” perun tipo di prodotti che allora erano del tutto nuovi e in larga misura addiritturadifficili da concepire. Era l’epoca in cui il software era prevalentemente di tipocustom, e in cui gli sviluppi avvenivano in maniera artigianale, in assenza dimetodologie di sviluppo, di strumenti automatici di supporto, di tecniche di pre-visione e controllo del processo.Oggi la situazione è cambiata profondamente. Il software negli USA è diventatoil terzo settore industriale, dopo quello dell’automobile e dell’elettronica. Un’in-dustria come Microsoft è diventata nell’immaginario collettivo l’emblema dell’in-dustria tecnologicamente avanzata e Bill Gates si presenta come l’Henry Forddella fine del secolo: l’uomo capace di portare l’innovazione tecnologica allaportata della gente comune, facendo diventare il software merce di consumo dimassa. 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 apunto nel corso degli ultimi decenni. Concetti chiave della progettazione delsoftware, come la modularità, l’incapsulamento e l’isolamento delle informazio-ni, la separazione tra specifica e implementazione sono diventati un patrimoniodiffuso tra i progettisti, grazie all’affermarsi dei metodi e dei linguaggi objectoriented. E la scrittura di software si è progressivamente semplificata grazie all’af-

XIV Ingegneria economica del software

fermarsi dei linguaggi visuali e delle librerie di componenti, sempre più ricche eversatili.Tutto ciò è solo un esempio di quanto progresso si sia compiuto nella direzionedella costruzione di una “ingegneria” del software. Il cammino, peraltro, non èterminato e, anzi, non se ne intravede la fine. Da un lato, infatti, bisogna ricono-scere che numerose sono ancora le realtà produttive arretrate, che non si sonoposte in maniera seria il problema del miglioramento della qualità dei propriprodotti e dei propri processi produttivi. Si tratta di realtà produttive che difficil-mente potranno crescere e affermarsi e che avranno sempre più una vita precaria.Dall’altro, occorre osservare che la stessa evoluzione tecnologica obbliga a rive-dere continuamente i processi e i prodotti dell’industria del software, e quindi aripensare e rivedere le basi e gli strumenti tipici dell’ingegneria del software. Bastipensare a quanto sta accadendo sotto i nostri occhi oggi, con il connubio semprepiù stretto tra l’informatica e le telecomunicazioni. L’affermarsi delle reti, comestrumento di connettività e cooperazione all’interno delle organizzazioni(Intranet) e tra le diverse organizzazioni (Internet) sta cambiando non solo laclassica piattaforma su cui creare applicazioni (non più il singolo elaboratore, maun sistema distribuito), ma il modo stesso con cui le applicazioni vengono conce-pite. Per di più, tutto ciò sta facendo nascere tipologie di applicazioni e di servi-zi 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 teleforma-zione e il telelavoro.Il compito dell’ingegneria è proprio quello di collocarsi in una zona critica e vi-tale delle conoscenze, a cavallo tra due fronti in parte conflittuali: da un lato il con-solidamento delle conoscenze, il loro assestamento in un insieme di principi emetodi standard usabili nella pratica industriale e trasferibili ad altri come patri-monio culturale comune e, dall’altro, la capacità di creare innovazione nei prodot-ti e nei processi e di spostare quindi su un terreno sempre nuovo e più avanzatol’esigenza del consolidamento.Questo libro vuole offrire un contributo all’ingegneria del software. Anzi, comedice l’autore, all’“ingegneria economica” del software, intendendo con ciòenfatizzare il fattore “costo” che nell’ingegneria costituisce un attributo essenzialedei prodotti e dei processi. I prodotti software che vengono sviluppati non solodevono raggiungere il loro prescritto livello di qualità, ma devono essere svilup-pati entro limiti di costo che consentano un loro successo sul mercato. Il costodeve essere predicibile e i fattori di costo devono essere conosciuti da chi gestiscei progetti software affinché questi possano essere continuamente tenuti sottocontrollo. Accanto a una trattazione generale dell’ingegneria del software e deisuoi fattori economici, questo libro offre un contributo personale dell’autore nelladescrizione di un metodo previsionale che deriva dalla sua esperienza pratica ditipo applicativo.

Prefazione XV

Un indice dell’affermarsi dell’ingegneria è anche la nascita di figure di ingegne-ri che si pongono l’obiettivo di svolgere un ruolo di testimonial all’interno dellacategoria. Se si osserva la realtà americana, si può rilevare che il numero di testidi informatica pubblicati da parte di testimonial è continuamente crescente. Ac-canto a testi che hanno un prevalente contenuto scientifico o a testi che hanno unprevalente orientamento didattico, sempre più vengono pubblicati testi che sipongono l’obiettivo di offrire il punto di vista di un operatore del settore sui temidi grande rilevanza per il settore stesso. Gli autori di libri che provengono dalsettore dei practitioner possono avere un ruolo fondamentale nel promuovereconoscenze e competenze innovative, in quanto spesso sanno parlare un linguag-gio che altri loro pari sanno meglio capire, anche perché queste derivano da espe-rienze pratiche vissute in prima persona. Forse un sintomo della maggiorearretratezza della situazione italiana rispetto a quella internazionale nell’ambitodel software sta anche nella limitatissima offerta di questo tipo di letteratura tec-nico-scientifica. Mi auguro che questo libro, nel porsi accanto ai pochi esempiche lo precedono di contributi da parte di practitioner che vogliono offrire unavisione applicativa dei problemi dell’ingegneria del software, stia finalmente asignificare una inversione di tendenza.

Carlo Ghezzi

Premessa

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 softwareengineering”, 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 principal-mente per sottolineare il vantaggio che l’approccio “ingegneristico” può appor-tare al mondo informatico, con la maggiore capacità razionale nella gestione delleproblematiche di valutazione economica (costi e benefici) della produzione delsoftware.In ogni caso, un titolo o l’altro, scopo di questo libro è di descrivere e riportareesperienze maturate attraverso metodologie offerte nel campo dell’Ingegneria delsoftware, al fine di meglio valutare lo sforzo necessario per lo sviluppo di un pro-getto software.L’intenzione è pertanto quella di dare un modesto contributo al mondoinformatico, rammentando agli addetti ai lavori e non, che oggi vi sono a dispo-sizione strumenti che permettono di valutare preventivamente, con una precisio-ne accettabile, la convenienza economica di informatizzare o meno un processoaziendale.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.

RingraziamentiLa stesura di questo libro è stata possibile grazie all’aiuto e alla franca e cortesecollaborazione di alcune persone che desidero ringraziare.

Alle mie donneIran, Vera e Sara

XVIII Ingegneria economica del software

Innanzitutto il professore Ugo Biader Ceipidor che, oltre a incoraggiarmi a por-tare a termine questa fatica è stato un eccellente compagno di viaggio per percor-rere l’esperienza nel campo della “stima dei costi del software”. Senza il suoprezioso supporto la mia conoscenza dell’argomento non sarebbe stata tale dapoter essere riversata in un libro. Un grazie di cuore anche a tutti i dipendentidella società HELP S.p.A., della quale ho l’onore di far parte, che, in modi emomenti diversi, hanno dato il loro contributo affinché questa esperienza fosseanche uno specchio della realtà lavorativa.Ai professori Giorgio Levi e Carlo Montagnero che mi hanno dato l’opportuni-tà di assegnare tesi di laurea sull’argomento, a due ottimi studenti; AntonioChojwa e Marco Boraso (corso di Laurea in Scienze dell’Informazione presso laFacoltà di Scienze Matematiche, Fisiche e Naturali dell’Università degli Studi diPisa). Va la mia sincera riconoscenza particolare a Marco la cuio tesi è stata fon-te di approfondimento teorico delle diverse metodologie esistenti sull’argomen-to di stima e per l’aiuto preziosissimo nella preparazione del software demodell’ESSE, parte integrante di questo volume.In particolar modo sono grato al professor Carlo Ghezzi per avermi aiutato coni suoi suggerimenti e per aver cortesemente scritto la prefazione del libro.Infine rivolgo un affettuoso e riconoscente pensiero a mia moglie Vera, senza lacui pazienza questo lavoro non sarebbe mai terminato.

Introduzione

È ormai noto che l’automazione e la produzione del software stanno diventan-do i due più grandi fenomeni industriali della storia dell’umanità. In uno spaziodi 30 anni l’evoluzione dei calcolatori e lo sviluppo del software, congiuntamentecon i progressi tecnologici nel settore delle telecomunicazioni, hanno raggiuntoun livello tale da modificare sostanzialmente il modo di vivere e lavorare dell’uo-mo. Ormai è fuor di dubbio che, dall’inizio del nuovo secolo, i computer saran-no un “elettrodomestico” standard di casa e che imparare a programmarediventerà 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 mondialenello sviluppo e manutenzione del software è stata di 100.000 miliardi di lire. Èforse ancora più impressionante sapere che, per il 2000, è prevista una spesasuperiore 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 neconviene) possiamo affermare che nonostante i passi da gigante fatti, tali disagipersistono ancora. La disciplina che principalmente si occupa di gestire lesopracitate difficoltà è l’Ingegneria del software.Queste cifre e considerazioni inducono, ancora una volta, a sottolineare che dopopiù di cinquant’anni dalla nascita del software, ben poco si conosce del suo pro-

XXII Introduzione

cesso di sviluppo. Pertanto l’obiettivo di eliminare i disagi legati alla gestione delciclo di vita del software è senz’altro un processo lungo e difficile.Lo scopo di questa pubblicazione è dunque quello di dare un modesto contri-buto alla conoscenza del processo di sviluppo del software, affinché si possaprovare a gestire male ciò che sarebbe stato gestito comunque peggio!!I capitoli iniziali analizzeranno in breve il processo globale dello sviluppo delsoftware, sia dal punto di vista delle metodologie di analisi e di programmazio-ne, sia da quello delle tecniche di controllo qualità e affidabilità. In seguito ver-ranno illustrate più dettagliatamente le problematiche relative all’economia delprocesso del software e cioè la gestione dei costi e benefici stimati dall’introdu-zione di un sistema informativo automatizzato in una organizzazione.Nei capitoli centrali verrà affrontato l’argomento della metrica del software conparticolare riguardo al processo della stima dei costi del software allo sviluppodi metodologie e tecniche attualmente in uso. Si evidenzia poi, il problema del-la stima con la descrizione delle difficoltà e dei limiti di ciascuna tecnica e delleconseguenze di una cattiva stima. Verranno inoltre presentati, in dettaglio imodelli per la stima dei costi del software più conosciuti e consolidati a livellointernazionale.I capitoli finali si occuperanno dell’applicazione della tecnologia di sistemi espertinel campo della stima dei costi del software. Infatti, dopo una descrizione delletecnologie di sistemi basati sulla conoscenza e del rapporto fra sistemi esperti eil processo di stima dei costi del software, verrà descritta la filosofia, l’architet-tura e l’operatività del sistema ESSE, un sistema per la stima dei costi del softwaresviluppato interamente in Italia utilizzando la tecnologia dei sistemi esperti.

11.1 Ciclo di vita del software, 1

1.2 Modelli alternativi del ciclo di vita del software, 4

1.3 Tecniche di verifica e validazione, 9

1.4 Analisi della qualità del software, 9

1.5 Standard per il ciclo di vita del software, 17

Ingegneria del software

L’Ingegneria del software è la scienza che, usufruendo delle conoscenze della Ma-tematica e dell’Economia, studia come rendere utili all’uomo le potenzialità dei com-puter per mezzo di programmi, procedure operative e documentazioni loro associate.L’Ingegneria del software è una disciplina tecnologica e manageriale che riguardala produzione sistematica e la manutenzione dei prodotti software che vengonosviluppati e modificati entro i tempi e i costi preventivati.A tali definizioni, tratte dal libro di Boehm [9] e di Ghezzi [34], vorremmo ag-giungere un ulteriore valore affermando che, oltre alla Matematica, all’Economiae al Managament, si deve tenere conto in modo particolare dell’organizzazione,affinché la scienza e/o disciplina dell’Ingegneria del software possa mettere inevidenza 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 pro-grammazione. Infatti, dato un processo da automatizzare, essa ha il compito diguidare tutte le attività legate al ciclo di vita dell’automazione informatica.

1.1 Ciclo di vita del softwareLa difficoltà di gestione del processo di sviluppo del software (SW) emerge prin-cipalmente dalla complessità dell’applicazione, dall’abilità delle risorse coinvoltee dalle caratteristiche del sistema (hardware HW e SW di base) sul quale vieneinstallato il SW applicativo.È sempre più difficile controllare la complessità del processo; la gestione diven-ta più ardua con l’evoluzione rapida della tecnologia che influenza continuamentele prestazioni del sistema. Diventa perciò sempre più importante capire e quin-di gestire tutte le fasi di sviluppo del software.In teoria si tende a considerare il ciclo del processo di sviluppo software attraver-so delle fasi. Ogni fase viene identificata con un punto di partenza (input) e unodi arrivo (output).

2 Ingegneria del software

Ci preme sottolineare subito che tale definizione teorica viene spesso contraddet-ta dalla realtà operativa che mette in evidenza la sovrapposizione continua delle fasi.Per poter definire le metriche dipendenti da ciascuna fase è necessario descriverepiù precisamente tutte le attività appartenenti a ciascuna fase del ciclo. Il modellodel ciclo maggiormente accettato è quello denominato “a cascata” (Waterfall) [9].Le fasi principali di tale modello sono riportate qui di seguito.

1.1.1 Fattibilità del progettoLo studio di fattibilità cerca di verificare tutte le potenzialità, i limiti e i vincolidel progetto che si vuole realizzare, mettendo in evidenza una stima di massimadi costi e benefici, spesso dal punto di vista strettamente economico.Anche se il risultato dello studio è generalmente una prima analisi tecnica delprogetto, la quale in un certo senso anticipa la successiva fase dei requisiti, cre-diamo che si debba modificare un po’ questa tendenza, orientando tale studionella direzione della verifica oggettiva di fattibilità (lo dice la parola stessa!), riu-scendo quindi a esaminare l’opportunità o meno di realizzazione del progetto inesame dando una valutazione più ampia dei costi e benefici.

1.1.2 Requisiti e specificheLa fase successiva allo studio di fattibilità comprende l’analisi funzionale deirequisiti e delle caratteristiche delle prestazioni del progetto. L’obiettivo è unastima delle esigenze delle risorse necessarie, nonché del budget economico delprogetto.L’input necessario a questa fase è dato dal risultato delle interviste agli utenti eai gestori del sistema.Le attività precipue, in questa fase, sono la piena comprensione dei requisiti, ladefinizione dello scopo del sistema, la determinazione dell’ambiente operativo incui il sistema si inserirà e le eventuali interfacce con i sistemi esterni.L’output di questa fase è composto generalmente da due documenti; i “requisi-ti utente” (User Requirements) e i “requisiti del sistema” (System Requirements).Entrambi i documenti sono critici per tutte le fasi del progetto in quanto for-niscono la piattaforma di accettazione a fronte della quale il sistema verrà va-lutato.

1.1.3 Disegno del sistemaNella fase di disegno del sistema vengono specificate l’architettura e la configu-razione globale del sistema. Viene inoltre definita la struttura dei sottosistemi egli eventuali moduli di ciascun sottosistema del progetto e le loro interfacce, especificato il/i linguaggio/i di programmazione e di sviluppo, nonché le struttu-re di controllo e un piano di test generale.

Ingegneria del software 3

Il sistema viene ripartito in maniera congruente in moduli da sviluppare in areefunzionali omogenee, quindi vengono individuati i gruppi di lavoro responsabilidello sviluppo della rispettiva area.L’input della fase è essenzialmente il documento “requisiti utente”, mentrel’output è normalmente rappresentato dal documento “progetto dell’architettu-ra” (Architectural Design) oppure dalla descrizione del prodotto, se si tratta disviluppo di un prodotto programma (Package).

1.1.4 Disegno di dettaglioLa 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, lospazio 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).

1.1.5 Codifica e test di moduloIn questa fase viene sviluppato il codice relativo a tutti i moduli analizzati prece-dentemente nel linguaggio o linguaggi prescelti. Sulla base di un “piano” vengonoeseguiti tutti i test dei moduli, generalmente in una sequenza predefinita (cate-na di test). Tale sequenza dovrà essere eseguita ogni qualvolta viene modificatouno qualsiasi dei moduli della “catena”.La produzione del codice sorgente può iniziare al termine del disegno dettagliatodi un singolo modulo previa revisione e approvazione. Generalmente lo svilup-po del codice viene condotto in parallelo da più sviluppatori software e pertan-to è di primaria importanza che le interfacce fra i vari moduli e le corrispondentifunzioni siano ben definite prima dell’inizio della fase.L’attività di codifica dei moduli è fortemente basata sul documento del dettaglioprodotto nella fase precedente.Gli output di questa fase sono il listato del “codice sorgente” (Source Code) e il“manuale utente”.


1.1.6 Integrazione e test globaleQuesta fase, che idealmente dovrà essere svolta da un gruppo di persone indi-pendenti dal gruppo originale del progetto, ha l’obiettivo di integrare tutti imoduli sviluppati e testati separatamente nella fase precedente. Il suo compito èquindi quello di verificare la completa funzionalità del sistema attraverso unaserie di test globali (predefiniti in parte nelle fasi precedenti), atti ad accertaretutti 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 globa-le” effettuato e l’insieme delle schede di anomalie riscontrate che dovranno es-sere “chiuse” (risolta e verificata la loro correttezza all’interno del sistema).

1.1.7 Installazione e avviamentoLa fase prevede il rilascio, l’installazione e l’avviamento del sistema presso l’utentefinale, nonché la verifica della funzionalità operativa dei requisiti del sistemaHW-SW nell’ambiente di esercizio.Essa comprende la conclusione e consegna della documentazione tecnico-ope-rativa del progetto, nonché l’eventuale formazione e messa in esercizio del siste-ma. L’input a questa fase viene rappresentato dal “manuale utente” che dovràcomprendere anche tutto ciò che è necessario per l’installazione, l’avviamento ela gestione del sistema.L’output è il documento conclusivo del rilascio del sistema e viene spesso rappre-sentato da un verbale di accettazione.

1.2 Modelli alternativi del ciclo di vita del softwareIl classico modello Waterfall (a cascata), citato precedentemente, è stato descrit-to per la prima volta da Royce [70] nei primi anni ‘70 e, successivamente rifinitoda Boehm [9] (Figura 1.1) nel 1976, per permettere di affrontare, con maggiorsupporto, la complessità dei progetti software.I vantaggi offerti dall’utilizzo del modello Waterfall possono essere sintetizzati neiseguenti punti:

• caldeggia la specificazione degli obiettivi del sistema (definizione dei re-quisiti), prima di definire l’architettura dello stesso (disegno);

• invita a pianificare in anticipo le modalità di interazione fra i componentidel sistema (disegno), prima della costruzione dei componenti stessi (co-difica);

• supporta il capo progetto nella gestione dello sviluppo e permette di sco-prire in anticipo gli scostamenti dal piano operativo;


• sollecita la produzione della documentazione nel processo di sviluppo chepotrà 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 damolti nel campo del Software Engineering e viene spesso corredato da una seriedi nozioni che permettono al Project Manager di gestire e controllare i progetticon maggiore consapevolezza.La scelta del modello del ciclo di vita e quindi la distribuzione delle risorse daimpegnare nelle varie fasi di sviluppo gioca un’importante ruolo nel supportareil Project Manager nella stima dell’allocazione delle risorse necessarie nello svilup-po del SW. Kustanowitz [56] sostiene che la dimensione di un progetto influenza

Figura 1.1 Schema di modello “a cascata”.

Studio di fattibilità

Disegno di dettaglio

Disegno di prodotto

Integrazione

Manutenzione

Codifica di moduli

Analisi e specificadei requisiti

Verifica e validazionedi studio di fattibilità

Verifica e validazionedi analisi e specifiche dei requisiti

Verifica e validazionedi disegno di prodotto

Verifica e validazionedi disegno di dettaglio

Test unitari di codificadi moduli

Verifica e validazionedel sistema

Verifica e test globale

Verifica e validazione

Installazionee manutenzione


notevolmente la distribuzione delle risorse nelle varie fasi di sviluppo (Figura 1.2).Ancora oggi la maggior parte delle grandi organizzazioni pubbliche e privatesegue il modello “a cascata”, spesso denominando le varie attività e i documen-ti prodotti con diciture diversificate e abbinando più fasi in un’unica soluzione.Infatti, la fase dei requisiti e specifiche viene frequentemente denominata “ana-lisi delle esigenze dell’utente” o “analisi del sistema”, il disegno del prodottoviene spesso chiamato disegno preliminare, disegno ad alto livello oppure defi-nizione dell’architettura del software, mentre il disegno dettagliato viene indicatocon disegno del programma, disegno a basso livello.Negli ultimi vent’anni sono state sviluppate metodologie alternative al modelloWaterfal:

• 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 permettedi affrontare il problema del ciclo di vita del software utilizzando la caratteristi-ca dell’approccio incrementale.

Figura 1.2 Percentuale del progetto totale.

Percentuale delprogetto totale

Dimensione del progetto

0

50

100Piccola GrandeMedia

Test10-20%

Test30-45%

Coding60-80%

Disegno10-20%

Disegno20-30%

Disegno30-45%

Coding40-60%

Coding10-40%

Test20-30%


1.2.1 Waterfall incrementaleL’obiettivo principale di questa metodologia è quello di utilizzare il modelloWaterfall iterativamente, attraverso un approccio incrementale per permetterel’aumento progressivo delle capacità funzionali del sistema software in esame.La Figura 1.3 [9] rappresenta chiaramente le modifiche apportate all’approccioWaterfall classico. L’evidente vantaggio operativo che ne consegue è dato dalladistribuzione più equilibrata delle risorse (non più a campana!), nelle varie fasidi sviluppo.

Figura 1.3

Incremento 3

Incremento 2

Incremento 1

Verificae validazione


Validazione e verifica dell’analisie specifiche dei requisiti

Validazione e verificadello studio di fattibilità

Verificae validazionedel sistema

Verificae test globale

Test unitari

Integrazione

Manutenzione

Integrazione

Installazione

Installazione

Disegnodi dettaglio

Codificadi moduli

Codificadi moduli

Codificadi moduli

Disegnodi dettaglio

Disegnodi dettaglio

Disegnodel progetto


Analisi e specifichedei requisiti

Studio di fattibilità

. . . . . .


1.2.2 Prototipazione rapida e successivaNel caso della prototipazione rapida e successiva ci si propone l’obiettivo diassicurare che il prodotto sviluppato incontri il più possibile le esigenze del-l’utente [21], [36].L’approccio ha lo scopo di costruire un’implementazione “veloce e sporca!” delsistema durante la fase dei requisiti. L’utente virtuale utilizza il prototipo per uncerto periodo e rileva le potenzialità e i limiti da lui percepiti. Questo feedback,che viene riportato più volte, è utilizzato per modificare progressivamente i re-quisiti e renderli sempre più rispondenti alle esigenze dell’utente.Conseguentemente vengono intraprese le successive fasi di disegno e di imple-mentazione del sistema reale, con la consapevolezza di stare sviluppando ilsoftware “giusto” (specialmente laddove le esigenze dell’utente si modificanodurante l’utilizzo del sistema). Un’evoluzione di questo approccio prevede unaserie di prototipi “implementa, verifica e getta via!” [12] che porta successiva-mente allo sviluppo definitivo del sistema.

1.2.3 Prototipazione evolutivaLo sviluppatore implementa tutti i requisiti conosciuti. Il prototipo vienedato all’utente per verificare ciò che è stato realizzato, ma anche per megliodefinire ulteriori requisiti. Rispetto alla precedente prototipazione (in cui lametodologia imponeva di implementare comunque tutti i requisiti conosciu-ti con l’obiettivo di incrementare e correggere le funzionalità dei requisiti),questo approccio suppone che l’utente non conosca realmente tutte le esi-genze e che quindi debba operativamente interagire con il sistema per iden-tificarle. L’applicazione di tale metodica è evidentemente più adatta a queiprocessi i cui requisiti non siano tutti ben noti e che abbiano quindi bisognodi essere sperimentati per essere conosciuti (differentemente dalla meto-dologia precedente dove i requisiti sono sufficientemente conosciuti e si de-cide di svilupparli in progressione) [61].

1.2.4 Produzione automatica di softwareCon questo termine si intende la trasformazione dei requisiti o meglio il di-segno ad alto livello del sistema in codice operativo. Il processo di decodifi-ca può essere effettuato attraverso tecniche algoritmiche [65] oppure ap-procci basati sulla conoscenza [6]. È evidente che questo tipo di procedi-mento permette di ricodificare i moduli a ogni variazione e/o integrazionedei requisiti, incrementando con passi successivi le funzionalità del sistemafinale [64].


1.3 Tecniche di verifica e validazioneL’obiettivo globale di un software è sia quello di raggiungere i requisiti prestabilitisia 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 delsoftware, identificate nella fase iniziale del ciclo di vita, e il prodotto realizzatoal termine. Le tecniche di validazione invece prendono in esame l’adeguatezza delprodotto risultante, rispetto alle reali esigenze operative.Boehm [9] esplicita i problemi di verifica e di validazione attraverso le seguentidomande:

• “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 presen-ti in tutte le fasi di sviluppo: dalla validazione dei requisiti e verifica dei tool didisegno e sviluppo, alla verifica delle prestazioni e delle validazioni dei test ope-rativi.Quindi il volume e la complessità dei progetti software attuali impongono che lemetodologie di verifica e di validazione vengano applicate su tutto il ciclo di vitadel software, prima che inizi la fase specifica del testing. Questa attività di pre-testing 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 antici-po costa sempre meno. Nella Figura 1.4, tratta da Deutsch [25], vengono ripor-tate le attività di verifica e validazione che dovranno essere prese in consi-derazione durante tutte le fasi del ciclo di vita del software.

1.4 Analisi della qualità del softwareL’analisi e la valutazione della qualità del software rivestono un’importanza sem-pre maggiore non solo per il produttore ma anche per il consumatore del software.Gli utilizzatori dell’informatica esigono più che mai di potersi fidare totalmentedel software acquistato.


Figura 1.4

Definizionedei requisiti

Sviluppo

Specifiche

Verificadei requisitidel sistema

Verificadei requisitidel disegno

Verificadel disegnopreliminare

Verificadel disegnodettagliato

Auditing dellaconfigurazione

fisico/funzionale


fisico/funzionale


fisico/funzionale

Definizioni Disegno Produzione Test Integrazioni

Manutenzione

Ingegneriadel sistema

Svilupposoftware

Verificadelladocumentazionedei requisiti

Verificadelladocumentazionedei requisiti

Conduzionedel disegnoinformale dei“walkthrough”

Misurazionedella qualitàdel disegno

Partecipazionenella verificadel disegnopreliminare

Preparazionedei pianidei CPCI

Conduzionedei testinformalisul codice

Conduzionedellapreparazionedei test unitari

Coordinamentodei probleminellosvolgimentodei test

Conduzionedegli “audit”

Conduzionedei testinformali suicodici relativiai CPCI

Provvederesupporto aitest formalidi qualità peri CPCI

Conduzionedegli “audit”

Provvederesupporto peri testdi integrazione

Conduzionedel disegnoinformale dei“walkthrough”

Misurazionedella qualitàdel disegno

Partecipazionenella verificadel disegnodettagliato

Preparazionedei piani di testglobali

Conduzionedella verificadei requisitidel sistema

Simulazionedelleperformancedel sistema

Preparazionedeldiagrammadella verificadel sistema

Conduzionedella verificadel disegnodi sistema

Definizionedelle metrichedegli standarddi qualità SW

Preparazionedeldiagrammadellavalidazionedel sistemaper ciascunaCPCI(ComputerProgramConfigurationItem)

Conduzionedella verificadel disegnopreliminare

Definizionedei criteridel test diaccettazione

Verificadellepropostedi modifica

Coordinamentodei problemisul disegno/interfacciadi sistema

Installazionedei tool disviluppodi sistema

Valutazionedei risultatidel test

Valutazionedei risultatidel test


Verificadellemodificheproposte


Conduzionedella verificadel disegnodettagliato



Coordinamentodei problemisullosvolgimentodel test




Coordinamentodei problemisullosvolgimentodel test


Fino alla metà degli anni ’70, la misura per valutare la qualità di un software, eradata dal numero di volte che il prodotto veniva effettivamente utilizzato. Altremodalità 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 la-voro operativo per definire delle norme, su base mondiale, nell’ambito dellaqualità del software.Oggi tali norme sono un punto di riferimento sicuro, specialmente per i produt-tori di software, per quanto riguarda gli standard di qualità.Per i consumatori del software invece, esistono più modi per accertare la “bon-tà” e quindi l’affidabilità del prodotto che vanno a utilizzare. L’approccio piùfrequente è quello di verificare la qualità del prodotto attraverso delle misure ecalcolo degli indici.Per tradizione, la qualità del software viene misurata attraverso due parametriprincipali:

• il numero e la tipologia dei test pianificati ed effettuati nonché i relativirisultati;

• il numero e la tipologia di errori (bachi) riscontrati nella fase dei test.

Anche le caratteristiche principali di un approccio “innovativo” nell’affrontareil problema della misurazione della qualità del SW possono essere raggruppatein due punti:

• misurare la qualità del SW non solo nella fase di test, ma in ciascuna fasedi sviluppo;

• definire un insieme di indici della qualità di codice sorgente.

Per quanto riguarda il primo punto, in realtà, più che una caratteristica esso è unatteggiamento metodologico, mentre il secondo punto impone una serie di misura-zioni che permettono di quantificare oggettivamente la qualità del prodotto SW. Diseguito 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.


Un sistema che tiene conto delle due categorie di indici sopra menzionate èESQUT (Evaluation of Software Quality from User’s viewpoinT), sviluppato neilaboratori di System & Software Engineering della Toshiba [41].Questo sistema integra le due metriche di McCabe e Halstead con altre misuree permette di valutare globalmente la qualità del software attraverso una verifi-ca 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 nel-la fase di coding e le caratteristiche del modello di qualità (complessità, funzio-nalità e comprensibilità).ESQUT permette di definire, nella fase del disegno, una serie di indici di quali-tà attraverso anche delle misure che vengono effettuate con le stesse caratteristi-che 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 modu-

lo disegnato.

Le metriche principali prese in considerazione e non dipendenti dalla meto-dologia 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


Anche per la fase di disegno del software è possibile quindi, identificare una seriedi indici, correlati attraverso dei coefficienti standard, calcolati sperimentalmentein relazione alle caratteristiche del software.La valutazione della qualità del software, nella fase di disegno, avviene verificandola deviazione dei coefficienti di correlazione calcolati rispetto a quelli standard.

1.4.1 ISO 9000, certificazione di qualitàDopo un inizio in “sordina” le norme ISO serie 9000 hanno effettivamente su-scitato interesse e avuto seguito nelle realtà progettuali e produttive dell’indu-stria e della Pubblica Amministrazione a livello mondiale.In Europa si contano ormai oltre 60 000 aziende che, nei vari settori merceologici,hanno ottenuto la certificazione ISO 9000.Tale interesse dipende principalmente dal fatto che gli standard sono accentra-ti sulla qualità e che le norme contengono i requisiti “minimi” di un sistemaqualità. Come riportato nella Figura 1.5 la serie ISO 9000 comprende un insie-me di “direttive guida” e tre tipi di norme:

1. ISO 9001 UNI EN 29001 [43] – Norme per l’assicurazione della qualitànella progettazione, sviluppo, fabbricazione, installazione e assistenza;

2. ISO 9002 UNI EN 29002 [44] – Norme per l’assicurazione della qualitànella fabbricazione, installazione e assistenza;

ISO 9000-1linee guidaper la scelta

e l’utilizzazione

ISO 9004-1linee guida

per lagestionedi qualità

ISO 9000serie di norme

ISO 9003ispezione

test


per il software


per assistenza

ISO 9002fabbricazioneinstallazioneassistenza

ISO 9001progettazione

sviluppofabbricazioneinstallazioneassistenza

Figura 1.5


3. ISO 9003 - UNI EN 29003 [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 chetrova maggiore applicazione nel campo del software è ISO 9001 accoppiata alla“direttiva guida” ISO 9000-3 [42] che è stata redatta appositamente per interpre-tare lo standard ISO 9001 finalizzato allo sviluppo e la manutenzione delsoftware.La struttura della guida ISO 9000-3 per la qualità del software è riportata nellaFigura 1.6 e delinea lo spirito con il quale le norme ISO affrontano il problemadi certificazione del processo di sviluppo del software.

Figura 1.6

Sistemaqualità

Attività

Attività delciclo di vita

Attività delsupporto

Responsabilità delladirezioneSistema di qualitàVerifiche ispettiveAzioni correttive

Riesame del contrattoSpecifica requisiticommittentePianificazionedello sviluppoPianificazionedella qualitàProgettazionee realizzazioneVerifica e validazioneAccettazioneDuplicazione, consegna,installazioneManutenzione

Gestione configurazioneControllo documentazioneDocumentazione regolequalitàMisureRegole, pratichee convenzioniStrumenti e tecnicheApprovvigionamentiProdotti inclusiAddestramento

Struttura


1.4.2 I processi di miglioramento nello sviluppo del softwarePer un’organizzazione che sviluppa e fa manutenzione di prodotti software, lacertificazione ISO 9001 offre non pochi suggerimenti circa la maturità e la capa-cità del processo.Il miglioramento del processo di produzione software non è un’azione indolorepoiché è necessario riorganizzare le varie attività di sviluppo e manutenzione perrendere la produzione più adeguata e conforme alle esigenze del mercato. I pro-cessi di miglioramento riguardano sia la capacità sia l’efficienza dell’organizza-zione, perché da una parte, rendono il processo più prevedibile e controllabile,e dall’altra, (insieme al miglioramento dell’efficienza) contribuiscono al miglio-ramento della qualità dei prodotti software [77].Il principio del miglioramento continuo si basa su un progresso che avviene len-tamente, in modo stabile, supportato da piccole vittorie quotidiane e incorporan-do 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 unobiettivo. Le quattro fasi del Plan, Do, Check, Act rappresentano l’iter mentaleche deve essere continuamente applicato per agire con successo. Il metodo puòinoltre includere una fase iniziale (Initiate) che crea la base necessaria per unaefficace applicazione delle iterazioni. Le fasi Initiate, Plan e Check possono inclu-dere le attività di valutazione.La valutazione del processo di sviluppo software (Software Process Assessment)costituisce oggi un prerequisito per impostare un valido piano di miglioramen-to. Essa determina lo stato corrente del processo di produzione nonché le diffi-coltà che ne impediscono l’evoluzione; può essere infatti applicata durante il cicloo anche dopo l’applicazione delle attività di miglioramento, allo scopo di confer-mare 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à diintervento;

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ù co-nosciuto è Capability Maturity Model (CMM). Tale modello, sviluppato dal SEI


Figura 1.7

Figura 1.8

Ottimizzazione

Misure del processo• processo definito• dati “qualitativi”

Definizione del processo• attribuzione di responsabilità• riuso di esperienza pregressa

Management di base• processo non controllato• strumenti non integrati nel processo• assenza di procedure formali

Controllo del processo• misure di costi/tempi/qualità

Gestito

Definito

Ripetibile

Iniziale

Livello Caratteristiche Fattori di promozione Risultato

5

Ottimizzato

Feedback—

il processo è“controreazionato”

Continua evoluzionenel miglioramento

del processo

4

Gestito

Quantitativo—

il processoè misurato

Cambiamentidi tecnologiaPrevenzionedei problemi

3

Definito

Qualitativo—

il processo è definitoin modo istituzionale

Misure di processoAnalisi di processo

Piani di qualitàquantitativi

2

Ripetibile

Intuitivo—

il processo dipendedalle persone, mac'è una gestione

Formazionerevisione e test

sistematiciStandard

1

Iniziale

A hoc—

caotico

Project managementPianificazioneControllo dellaconfigurazione

Assicurazione di qualità

Rischio

Produttività e qualità


(Software Engineering Institute), è adatto alla misura della capability del proces-so di sviluppo e identifica chiaramente (Figura 1.7) i cinque livelli di maturità delprocesso.Quando un’organizzazione raggiunge la certificazione ISO 9001, deve essenzial-mente preoccuparsi di mantenerla, cosa che richiede un notevole sforzo. Lacertificazione stabilisce soltanto che l’organizzazione debba gestire determinaticriteri. In termini CMM, questo si traduce nell’amministrare diversi processi dellivello 2 e alcuni del livello 3. Nella Figura 1.8 sono riportati i cinque livelli di ma-turità con le relative caratteristiche e i fattori di promozione.Un’altra interessante caratteristica del CMM è la possibilità di usufruire di proce-dure per l’auto valutazione (self-assessment). Tali procedure sono ben documen-tate dal SEI.Pur convenendo che non sarà né l’adattamento a norme standard né una “coc-carda” a cambiare operativamente il processo di sviluppo e/o l’attività di produ-zione, non possiamo negare che gli standard ISO 9000 abbiano comunquesensibilizzato notevolmente le imprese a considerare con maggiore serietà il pro-blema della qualità del processo aziendale.

1.5 Standard per il ciclo di vita del softwareNel 1987 l’ISO ha avviato un processo per la standardizzazione del ciclo di vitadel software. A oggi, tale processo non è ancora terminato, ma i primi risultatisono già stati pubblicati [59]. Per “dovere di cronaca” riportiamo in sintesi iprincipali risultati anticipati.Il ciclo di vita del software completo (dal momento dell’analisi dell’esigenza delcommittente fino a quello della fornitura del servizio software) è stato suddivi-so in cinque processi primari (Figura 1.9):

1. processo di acquisizione;

2. processo di fornitura;

3. processo di sviluppo;

4. processo di operazioni;

5. processo di manutenzione.

1.5.1 Processo di acquisizioneIl procedimento usato per l’acquisizione del software e dei relativi servizi è svol-to da colui (persona, azienda, organizzazione) che necessita del prodotto e/o delservizio software. È da rilevare che sia il processo d’acquisizione sia, quello difornitura fanno riferimento alla “visione contrattuale” del software.Il processo di acquisizione si basa su cinque attività:


1. Inizializzazione: identificazione delle esigenze software del committente.Questa attività consiste nella preparazione del sistema, dei requisitisoftware, della strategia d’acquisizione e dei criteri di accettazione delsistema.

2. Richiesta della proposta: identificazione dei requisiti del sistema e le relati-ve condizioni di fornitura.

3. Preparazione del contratto e suo aggiornamento: preparazione formale delcontratto nonché il suo aggiornamento durante tutto il ciclo di vita, inclu-si i cambiamenti sui task di controllo.

Esigenze

“Contratto”Processodi acquisizione

Processodi fornitura

Processodi sviluppo

Processodi operazioni

Processodi manutenzione

“Produzione”

Figura 1.9


4. Monitoraggio del fornitore: esso deve essere costante per quanto riguardasia l’aspetto tecnico sia quello organizzativo.

5. Accettazione e reclami: gestione dell’accettazione delle attività (testing,riesami, documenti...).

1.5.2 Processo di fornituraQuesto processo ha il compito di provvedere alla fornitura del prodotto softwaree/o ai servizi, costituisce l’altra parte del contratto e si compone di sette attività:

1. Inizializzazione: prendere la decisione di fare un’offerta oppure concor-dare la fornitura di un prodotto o servizio.

2. Preparazione della risposta: preparare una risposta alla richiesta di un’of-ferta o proposta.

3. Contratto: negoziare e arrivare a un accordo con il committente.

4. Pianificazione: stabilire un piano per lo sviluppo del prodotto o fornituradel servizio richiesto.

5. Esecuzione e controllo: mettere in atto i piani, controllare lo svolgimentodelle attività e monitorare continuamente il progetto.

6. Revisione e valutazione: revisionare e valutare continuamente i risultati eil prodotto finale, avvalendosi delle fasi del processo, definite nelle fun-zioni di supporto.

7. Consegna e reclami: consegna del prodotto finale oppure dei servizi e lagestione dell’assistenza post-consegna.

1.5.3 Processo di sviluppoIl fornitore dovrà gestire interamente il processo di sviluppo del software nuovoo la modifica del software esistente. Sia questo processo che quello di manuten-zione fanno riferimento alla “visione ingegneristica” del software. Il processo disviluppo, così definito dall’ISO è indipendente dal modello del ciclo di vita uti-lizzato dall’azienda e può quindi adattarsi sia allo sviluppo di un prototipo cheal prodotto finito ingegnerizzato.Il processo di sviluppo è suddiviso in tre fasi (progetto, sistema e software) e sicompone di tredici attività elencate qui di seguito e riprodotte nella Figura 1.10:

1. Implementazione: selezione del modello del ciclo di vita più adatto alprogetto in corso; scelta degli standard, delle procedure e dellemetodologie appropriate e preparazione del piano più idoneo per il pro-getto.


2. Analisi dei requisiti del sistema: è la definizione e la documentazione deirequisiti del sistema, assieme ai requisiti di qualificazione. Questa attivi-tà documenta le caratteristiche e le funzionalità del sistema. Gestisceinoltre le revisioni dei requisiti dell’utente, del testing, della fattibilitàdel disegno, dell’operatività e della manutenibilità.

3. Disegno architetturale del sistema: definizione dell’architettura del siste-ma. Questa attività definisce l’assegnazione dell’HW e del SW, opera-zioni manuali, e tiene traccia del disegno nel documento dei requisiti.

4. Analisi dei requisiti software: definizione e documentazione dei requisitisoftware basati sull’allocazione predefinita nell’attività precedente, in-clusi i requisiti di qualificazione. Questa attività documenta le caratteri-stiche e le funzionalità del software. Gestisce inoltre le revisioni dei re-quisiti dell’utente, del testing, della fattibilità del disegno, dell’operativitàe della manutenibilità.

5. Disegno architetturale del software: assegnazione dei requisiti software aicomponenti più elementari e tracciamento del disegno nel documentodei requisiti. L’attività comprende il disegno del database e delle

Progetto

Implementazionedel progetto

Installazionedel progetto

Testing equalificazionedel sistema

Testing equalificazionedel software

Integrazionedel

sistema

Integrazionedel

software

Disegnoarchitetturaledel sistema

Disegnoarchitetturaledel software

Disegnodi dettagliodi software

Coding e testdei moduli

del software

Analisidei requisitidel sistema

Analisidei requisitidel software

Accettazionedel progetto

Sistema

Software

Figura 1.10


interfacce, il manuale utente, e i requisiti dei test. Inoltre gestisce la do-cumentazione e le revisioni del disegno, affinché ne rimanga traccia, eassicura consistenza e aderenza ai criteri di performance.

6. Disegno di dettaglio del software: è richiesta una progettazione più parti-colareggiata possibile del software per permettere l’attività del coding.Questa attività comprende il disegno di dettaglio del database, delleinterfacce, dei manuali utente e dei requisiti di test; include inoltre lelinee guida per la documentazione e le revisioni, affinché rimanga unatraccia, e assicura consistenza e aderenza ai criteri di performance.

7. Codifica del software e testing: traduzione del disegno di dettaglio delsoftware nelle istruzioni del linguaggio prescelto. L’attività comprendeil testing dei moduli e assicura la loro funzionalità autonoma, oltre adocumentarne i risultati. Sono inclusi pure i task per completare i databasee aggiornare i manuali dell’utente e i piani di test per l’integrazione delsistema.

8. Integrazione del software: integrazione di ciascun modulo software nel-l’intero sistema. Lo sviluppo dei piani, l’integrazione, il testing, la docu-mentazione, le revisioni e la valutazione dei risultati sono inerenti a que-sta attività.

9. Test di accettazione del software: esecuzione dei test di accettazione comeprestabilito negli accordi. Include lo sviluppo dei piani, l’esecuzione deitest di accettazione, la documentazione, le revisioni e la valutazione deirisultati.

10. Integrazione del sistema: integrazione del software con l’hardware, conelementi di telecomunicazione e altro che compongono il sistema. Con-nessi a questa attività sono inoltre, lo sviluppo dei piani, l’esecuzioned’integrazione, il testing, incluse le interazioni umane, la documentazio-ne dei risultati, le revisioni e la valutazione dei risultati.

11. Test di accettazione del sistema: esecuzione dei test di accettazione comeprestabilito negli accordi. Sono compresi lo sviluppo dei piani, l’esecu-zione dei test di accettazione, la documentazione, le revisioni e la valuta-zione dei risultati. Alla fine di questa attività il sistema è pronto per laconsegna.

12. Installazione del software: installazione del software nell’ambiente targetcome da accordi, nonché lo sviluppo dei piani, l’installazione e la docu-mentazione dei risultati.

13. Accettazione del software: assistenza al cliente nella fase di accettazione. L’at-tività comprende la partecipazione alle revisioni del cliente, il testing delcliente, la formazione e la consegna di tutta la documentazione richiesta.


1.5.4 Processo delle operazioni sul sistemaIl processo delle operazioni effettuate sul sistema si riferisce alla “visione opera-tiva” del software. Queste attività sono eseguite dall’“operatore” del sistema.Il procedimento si basa su quattro attività:

1. Implementazione: sviluppo dei piani e delle procedure per le operazionisul sistema. L’attività comprende la preparazione delle procedure per iltesting del sistema nell’ambiente operativo, nonché l’interfacciamento conl’utente, la produzione della documentazione dei problemi riscontrati, lerichieste delle modifiche e il lancio del sistema software.

2. Testing operazionale: esecuzione dei test operazionali e lancio del sistemaper l’utilizzo.

3. Operazioni sistema: esecuzione del sistema software per i piani e le pro-cedure.

4. Supporto utente: assistenza e consulenza all’utente.

1.5.5 Processo di manutenzioneIl processo di manutenzione e modifica del software, come quello di sviluppo, fariferimento alla “visione ingegneristica” del software. Esso viene attivato quan-do il software richiede modifiche dovute a errori di correzione, adattamenti acambiamenti di contenuto oppure a migliorie del prodotto. L’obiettivo che sipropone è di operare modifiche sul sistema esistente, pur conservandone l’inte-grità.Il processo di manutenzione è composto di sei attività:

1. Implementazione: sviluppo dei piani e delle procedure per il processo dimanutenzione; sono inclusi la ricezione e il tracciamento dei problemidocumentati e le modifiche richieste.

2. Analisi dei problemi e delle modifiche: analisi dei report dei problemi ri-scontrati e delle modifiche richieste per determinare l’impatto sul sistemae sulle risorse. L’attività ha inoltre il compito di preparare alternative (op-zioni) e ottenere approvazione a procedere.

3. Implementazione delle modifiche: risoluzione del problema di effettuazio-ne delle modifiche sul software. Il processo di sviluppo, impiegato perquesta attività, prevede tutte le fasi con la verifica continua che non ci siaalcun effetto negativo sulle parti del software non modificate.


4. Revisione e accettazione della manutenzione: revisione delle modificheallo scopo di appurare l’integrità del sistema. È prevista l’approvazionedel cliente per assicurare che la modifica sia stata effettuata con il suoaccordo.

5. Migrazione: migrazione del sistema software dal vecchio al nuovo am-biente operativo. L’attività comprende lo sviluppo di tutti i piani, del-le procedure e degli strumenti di supporto, per assicurare il successodella migrazione.

6. Ritiro del software: ritiro di una versione oppure di tutto il sistema. Inquesta operazione s’intendono compresi la gestione dell’archiviazione, isupporti futuri, le osservazioni dell’utente e le operazioni parallele. Essainclude inoltre la pianificazione e le esecuzioni dei task per effettuare ilritiro operativo del software.

1.5.6 Processi di supporto e di organizzazioneOltre ai processi primari descritti qui sopra, lo standard (ISO 12207) ne preve-de otto di supporto e quattro organizzativi che permettono di completare inmaniera esaustiva tutte le attività (in totale 74) necessarie al ciclo di vita delsoftware.Gli otto processi di supporto sono:

1. documentazione;

2. gestione della configurazione;

3. assicurazione della qualità;

4. verifica;

5. validazione;

6. revisione combinata;

7. certificazione;

8. isoluzione dei problemi.

I quattro processi organizzativi sono:

1. gestione;

2. infrastrutture;

3. migliorie;

4. formazione.


Per concludere, ci uniamo alle convinzioni e ai suggerimenti del comitato ISO,certi che gli standard 12207 avranno un impatto decisivo sulla produzione emanutenzione del software, particolarmente per i sistemi complessi e critici. Siritiene che queste norme diventeranno la chiave di successo per costruire gran-di sistemi internazionali nei quali sono presenti partecipazioni multinazionali.Ribadiamo infine la nostra convinzione che gli standard, pur riducendodrasticamente i rischi associati allo sviluppo e alla produzione del software nonpossono da soli sostituire una competenza operativa supportata da un approcciodisciplinato e sistemico, che dovrebbe essere sempre presente nella gestione diun processo di Ingegneria del software.

22.1 Costi e benefici di un progetto software, 27

2.2 Problemi legati al processo di stima, 31

Economia del software

Il problema dell’economia nel processo di sviluppo e implementazione delsoftware, come d’altronde in tutti i processi in cui l’impatto non è circoscritto allasola attività di sviluppo (coding), può essere affrontato a due livelli: dimacroeconomia e di microeconomia.In generale, si parla di approccio macroeconomico quando i fattori decisionaliper lo sviluppo di progetti software (gli strumenti, le risorse finanziarie, il perso-nale, eccetera) vengono influenzati o influenzano i parametri economici a livel-lo nazionale, nonché internazionale. Tali parametri macroeconomici vannodall’inflazione nazionale alla quantità di scambio internazionale, dal problemadell’occupazione nazionale al problema del deficit pubblico, ecceteraIn questo contesto, invece, la microeconomia si occupa principalmente di para-metri decisionali più specificamente aziendali: quanto utilizzare le risorse inter-ne e/o quanto acquistare sul mercato; quando sviluppare dei progetti ad hocoppure acquisire prodotti più generalizzati; quanto tempo e risorse dedicare allaqualità del software; quanto investire nella ricerca, eccetera.Una buona politica aziendale nella valutazione dell’“economia del software”, in-dipendentemente dalla dimensione dell’organizzazione, è quella di selezionare everificare l’influenza di un insieme di fattori macroeconomici e di parametri piùspecificamente aziendali, affinché la stima dei costi e benefici della decisione siaad ampio raggio.

2.1 Costi e benefici di un progetto softwareLa valutazione dei costi e benefici di realizzazione di un sistema informativoautomatizzato deve essere effettuata tenendo conto di almeno tre voci, ognunadelle quali raggruppa, a sua volta, un’insieme di elementi:

28 Economia del software

• valutazione dell’hardware, del software di base e dei pacchetti specifici;• valutazione dello sforzo di sviluppo del software applicativo;• valutazione delle risorse (umane e altro) per la formazione, l’assistenza e

l’av-viamento del processo di informatizzazione.

Per un’analisi più ampia di valutazione di redditività di un’operazione diinformatizzazione, esistono altri componenti, di ben più difficile stima:

• valutazione dell’impatto sull’organizzazione aziendale;• valutazione dell’impatto sociale e sul territorio;• valutazione dell’impatto culturale e nazionale.

Mentre la prima categoria di valutazioni ha, in prevalenza, carattere quantitativoe un impatto circoscritto, nella seconda, prevale la natura qualitativa, con un’in-fluenza molto più ampia; due caratteristiche di difficile misurazione.L’esame del problema non deve comunque scoraggiarci, bensì indurci a valuta-re la possibilità di creare “metriche locali” in grado di fornire valutazioniquantitative con caratteristiche prevalentemente qualitative.Anche senza specifiche metodologie è comunque opportuno tenere presente l’im-patto positivo e quello negativo dei processi qualitativi ogni qualvolta si proce-de alla stima dei costi e benefici nell’introduzione di un sistema automatizzato inuna realtà operativa.

2.1.1 Valutazione dell’hardware, del software di basee dei pacchetti specifici

Anche se varie case costruttrici di calcolatori (IBM, Digital, HP ecc.) hanno svi-luppato specifici sistemi software per configurare un’architettura HW sulla basedi requisiti e di determinati vincoli, non esiste a oggi una particolare metodologiascientifica consolidata nella valutazione generale dell’architettura dell’hardware.Ciò è dovuto a varie ragioni oggettive:

• la variabilità non controllabile delle architetture hardware proponibili perun progetto sulla base dei soli requisiti iniziali;

• la continua dinamica innovativa dei sistemi HW;• l’evoluzione della dinamica di scala;• l’utilizzo dell’HW in più sistemi e, di conseguenza, difficile attribuzione dei

costi e benefici relativi a un solo progetto.

Peraltro il problema della stima dei costi hardware risente di alcuni fattori che lorendono più semplice rispetto a quello relativo al software e ai suoi servizi (for-mazione, assistenza e avviamento). I principali motivi sono i seguenti:

Economia del software 29

• la presenza di un bagaglio di esperienza decennale di situazioni analoghenel campo della stima dell’hardware;

• il progressivo consolidamento delle architetture di base e dei processi distandardizzazione che riducono i gradi di libertà nella scelta dei prodottiHW e nella definizione delle relative architetture;

• la presenza di misuratori di capacità quali i MIPS (Mega Instructions PerSecond), le transazioni al secondo, eccetera;

• il ricorso a prove pratiche, quali i benchmark (prove sperimentate di para-gone), che permettono il confronto fra capacità di prodotti hardware, disoftware di base e di pacchetti specifici, nella configurazione operativadesiderata. Tali benchmark sono ancor più utili quando le prove vengonoeffettuate nell’ambiente operativo e alla presenza del software applicativo;

• la tendenza dei prodotti HW a diventare sempre più affidabili e menocostosi.

2.1.2 Valutazione dello sforzo di sviluppodel software applicativo

L’argomento riguardante la valutazione dello sforzo di sviluppo verrà trattatoampiamente nei prossimi capitoli. Si vogliono qui evidenziare le caratteristichegenerali e le relative problematiche del processo di stima.La stima dei costi di sviluppo del software è un’attività critica dell’intero progettodi automazione. Innanzitutto è un processo complesso che comporta un grannumero di variabili con molte interazioni fra di loro. Bisogna quindi considera-re che le interazioni fra le variabili che lo compongono sono spesso di tipo nonlineare:

• integrazione dei moduli sviluppati separatamente;• coordinamento delle interazioni tra i diversi gruppi di lavoro;• integrazione delle fasi più “scure” del ciclo di vita del SW (project mana-

gement, documentazione, sviluppo di SW di supporto);• vincoli specifici della stima (minimizzare i costi, rispettare le scadenze,

eccetera).

Paradossalmente, gli effetti più catastrofici osservati nella valutazione dello sforzodi sviluppo del software applicativo, derivano spesso da stime per difetto, piut-tosto che da stime per eccesso.Una ricerca recente condotta negli Stati Uniti, ha osservato che il 70% dei pro-getti si conclude con un costo da 2 a 3 volte superiore a quello preventivato. Maciò non basta: dallo stesso studio risulta che l’aumento dei costi rispetto alla “cat-tiva” stima iniziale determina una bassa qualità del prodotto, incidendo pre-valentemente su documentazione, ergonomia e addestramento del sistema.


Esso provoca inoltre un allungamento dei tempi con conseguente perdita dicompe- titività del prodotto o del servizio per il quale era stata avviata l’automa-zione. Addirittura il 15% dei progetti non arriva a completamento proprio perlo sfondamento del budget economico o dei vincoli temporali.Questi elementi, uniti alla progressiva crescita dei costi del software che hannoabbondantemente superato quelli dell’hardware, rendono sempre più importantee critica l’ingegneria nonché l’economia del software.In quest’area, al contrario che per la valutazione dell’hardware e la stima dellerisorse per i servizi, si può ben affermare che “la scienza teorica è venuta in aiu-to all’esperienza pratica”. Infatti esistono delle metodologie consolidate, qualchevolta supportate anche da modelli matematici, che permettono di implementa-re, in situazioni diverse, equazioni con parametri adeguati.È bene comunque sottolineare da subito che tali metodologie e i rispettivi mo-delli non sono altro che frutto di valutazioni sperimentali e che, se utilizzati inmaniera errata, forniscono dei risultati non affidabili. Anzi, le conseguenze sonospesso peggiori di quelle puramente frutto dell’esperienza (rules of thumb), poi-ché in questo caso l’estimatore è comunque “cosciente” ed è generalmente “cri-tico” al riguardo del risultato.

2.1.3 Valutazione delle risorse per la formazione,l’assistenza e l’avviamento del processodi informatizzazione

Per provvedere alla formazione, all’assistenza e all’avviamento del processo diinformatizzazione, sia nel caso in cui si ricorra in tutto o in parte a risorse ester-ne, oppure si utilizzino le sole risorse interne, è necessario effettuare un’attentavalutazione dei costi relativi in quanto essi costituiscono sempre di più una fet-ta rilevante del costo totale di realizzazione dei progetti.Al riguardo bisogna precisare che, mentre la stima delle risorse umane necessa-rie allo sviluppo di un sistema è molto delicata, la valutazione dei costi unitari èmeno critica. Infatti, nella fornitura di prestazioni (assistenza, avviamento) e diservizi (formazione), i costi orari, giornalieri oppure mensili delle varie figureprofessionali coinvolte, sono generalmente noti.Il problema spesso nasce dal fatto che le risorse per l’istruzione del personale,come anche quelle per l’avviamento, sono atipiche, e quindi difficili da imputa-re a un singolo progetto. Infatti esse appartengono alla categoria della qualifica-zione e devono essere inquadrate di volta in volta in un’ottica a due lenti, perquanto riguarda i benefici attesi:

1. contributo al funzionamento del prodotto risultante dal progetto di auto-mazione;

Economia del software 31

2. allineamento con un piano di evoluzione culturale che deve essere formu-lato a livello aziendale.

Chi deve fare la stima delle risorse di formazione e di avviamento deve tenere benpresente sia il livello di preparazione del personale sia, ancora più importante, ilsuo livello di “motivazione”, sia un’eventuale ipotesi di ricorso alla mobilità.Analogamente, le risorse di assistenza risentono profondamente dell’ambiente inquanto esse dipendono strettamente dal livello culturale generale, dalla possibi-lità di motivare il personale a convertirsi al processo di automazione (cioè a ren-dersi autonomo) e dalla rispondenza dei prodotti informatici alle aspettativedell’utenza.Come si può notare, anche in questo caso come in quello relativo alla valutazio-ne dell’hardware, non esiste una metodologia o un modello di valutazione; mol-to è lasciato alla conoscenza dell’ambiente e delle sue problematiche eall’esperienza derivata da situazioni analoghe.

2.2 Problemi legati al processo di stimaUn’indagine effettuata presso gli “esperti” ha confermato la loro “incapacità” aeseguire delle stime affidabili relative ai progetti software. Anche se un’afferma-zione del genere può risultare difficile da accettare, la riteniamo assolutamenterealistica, pur lasciando al lettore l’interpretazione delle parole “virgolettate”!Tale affermazione diventa ancora più forte se si pensa al continuo aumento deicosti associato allo sviluppo.Tutto questo ha portato, negli ultimi anni, ad accelerare la ricerca dei metodi perla stima dei costi di sviluppo software, per capire meglio il processo di stima equindi consolidare le metodologie già sperimentate sul campo.DeMarco [24] conferma sostanzialmente l’incapacità degli estimatori delsoftware fornendo le seguenti motivazioni:

• non vengono preparati “esperti” nella stima dei costi del software;• non vengono adottati provvedimenti per compensare le conseguenze dei

preconcetti sul processo di stima;• non è sempre ben chiaro lo scopo reale di una stima;• non vengono adeguatamente considerati i problemi “politici” che ostaco-

lano il processo di stima;• le stime non hanno sufficienti riferimenti alle prestazioni del passato.

DeMarco afferma inoltre che esistono quattro motivi per i quali una stima puònon essere esatta.


Il primo si basa sul fatto che essa, essendo oggettivamente un processo comples-so, necessita di uno sforzo non indifferente, anche perché diversi fattori esterniintervengono normalmente nel processo e non ne agevolano sicuramente ilcontrollo:

• la stima viene affrontata quasi sempre in tempi ristrettissimi e nessun ap-prezzamento, per lo sforzo compiuto nel definirla, viene espresso dal ma-nagement;

• spesso essa viene richiesta senza che i requisiti del sistema siano chiari;• chi fa la stima normalmente non ha partecipato alla stesura del progetto del

sistema da sviluppare e meno che mai ai primi contatti con coloro che han-no, almeno in minima parte, definito i requisiti.

Il secondo motivo per cui una stima può risultare errata risiede nella personastessa alla quale si chiede una stima. Egli (in genere un capo progetto), non haabitualmente esperienza nello sviluppo di stime, in particolare per grossi progetti.Poche strutture possiedono un archivio organizzato di dati relativi a progetti giàsviluppati che possono essere di aiuto nella stima di nuovi progetti, quindi i capiprogetto tentano di fare stime senza alcun supporto, tranne quello di esperien-ze personali limitate che vengono spesso mal utilizzate.La terza e la quarta causa di difficoltà sono legate a due fattori che, assieme pro-ducono un effetto amplificato:

• il pregiudizio, spesso legato al fattore umano, verso la stima “plausibile”(sottostima);

• il desiderio del management che, spesso, più che richiesta di una stima di-venta imposizione di un obiettivo.

Il calcolo della stima viene perciò effettuato attraverso un’estrapolazione consi-derando una sola porzione del sistema, per cui gli aspetti non lineari del processovengono trascurati.Un altro elemento che può portare a un calcolo sottostimato è costituito dal fattoche il nostro “estimatore” calcola la quantità dello sforzo facendo riferimento allesue capacità, senza tenere presente che molte parti del sistema dovranno esseresviluppate da personale che ha meno esperienza e conoscenza della problematica.Tutto ciò, combinato con i desideri del management che tende sempre a minimiz-zare le stime e massimizzare la produttività, porta a ridurre ulteriormente unastima già bassa in origine.Nel Capitolo 4 verranno descritte in dettaglio le problematiche connesse allastima dei costi del software, mentre nel Capitolo 5 verranno illustrati gli approcciche, a oggi, sono considerati consolidati metodi di stima del costo nella produ-zione del software.

33.1 Importanza delle metriche, 35

3.2 Costruzione di un sistema per la misurazione del software, 36

3.3 Metriche e qualità, 42

3.4 Metriche per la qualità del software, 45

3.5 Metriche per la stima dei costi del software, 49

Metriche del software

Il termine metriche per il software (MS), viene usato per definire tutto ciò cheriguarda le misure in qualche modo correlate ai prodotti SW (per esempio, di-mensione, complessità, affidabilità) e alle attività legate al loro sviluppo e manu-tenzione (per esempio, raccolta requisiti, codifica, testing) [38].I “prodotti SW” includono tutti i prodotti intermedi del processo di sviluppo emanutenzione, quali i documenti di progetto, le specifiche, i listati del codicesorgente, i test-report.Dalla fine degli anni ‘70, periodo in cui vennero pubblicati i primi studi sull’ar-gomento, la famiglia delle metriche studiate si è arricchita a tal punto da copri-re virtualmente ogni dimensione quantificabile nello sviluppo di un sistema SW.Infatti, benché la maggior parte degli studi (circa il 50% delle pubblicazioni sullemetriche del SW) si sia concentrata principalmente sulle metriche per il codice(numero di linee di codice, complessità, strutturazione in quanto rappresentanograndezze facilmente misurabili da strumenti automatici), i ricercatori hannoparallelamente sviluppato metriche per le altre fasi del ciclo di vita del SW: dal-la consistenza dei requisiti alla produttività funzionale, dalla strutturazione deldesign alla documentazione, dal livello di “espressività” del linguaggio alla com-pletezza dei test.

3.1 Importanza delle metricheL’uso sistematico delle MS permette di:

a) Migliorare la qualità del controllo del SW management (e quindi del SW),quantificando, oggettivamente le “grandezze” che intervengono nella pro-duzione di un sistema SW, per determinare i fattori che influenzano la pro-duttività nelle varie fasi di sviluppo e studiarne poi il comportamento.

36 Metriche del software

Le misurazioni vengono così a far parte delle normali attività di controllodi un progetto. Si tratta essenzialmente di misurare:

• le risorse dedicate alla produzione del SW (per esempio, tempo-perso-na, tempo-macchina);

• le caratteristiche del SW stesso (per esempio, dimensione, complessi-tà, affidabilità, performance);

• le caratteristiche dell’ambiente di sviluppo (per esempio, esperienza delpersonale, tecnologie impiegate).

Le stime di queste quantità sono come parte integrante della pianificazione delprogetto, mentre le misurazioni sul campo servono a monitorare i progressi com-piuti rispetto a quanto pianificato [26].

b) Determinare modelli di stima teorico-empirici per la valutazione a prioridel tempo (per esempio, mesi) e dello sforzo (per esempio, mesi/persona)necessari alla produzione di nuovi sistemi, oltreché per predirne le carat-teristiche operative, quali la performance, l’efficienza o l’affidabilità.Le due assunzioni implicite sono:

• l’esistenza di relazioni tra le quantità misurabili o ricavabili nelle primefasi del ciclo di vita del SW (per esempio, requisiti, specifichefunzionali, caratteristiche dell’ambiente di sviluppo) e di relazioni legateinvece alle attività intermedie (per esempio, dimensione del codice) ofinali (costi a consuntivo) di un progetto;

• le relazioni identificate possono essere espresse tramite formule o mo-delli matematici.

3.2 Costruzione di un sistemaper la misurazione del software

Indipendentemente dalle metodologie con le quali si può affrontare l’argomen-to della metrica, in un’organizzazione dove la produzione del software ha un certopeso, è ormai indispensabile che vi sia una struttura operativa con il compito dicreare un sistema per la misurazione sia della quantità di SW prodotto (numerodi funzionalità, numero di istruzioni e così via), sia del tempo e delle risorse im-pegnate per tale produzione (mesi o giorni di calendario, mesi/persona, nume-ro di risorse, eccetera).Nell’affrontare la creazione di un sistema per la misurazione del SW vanno tenutipresenti i seguenti argomenti:

Metriche del software 37

• la stima del “valore” della struttura per la gestione del sistema;• la valutazione del “costo” della struttura per la gestione del sistema;• la creazione del “profilo” del personale adatto a far parte della struttura;• il posizionamento e la modifica dell’“organizzazione” per l’inserimento

della struttura;• l’ipotesi di un “piano” operativo per la gestione del sistema di misurazione.

3.2.1 Stima del “valore” del sistemaper la gestione della misurazione del SW

Non è per niente semplice valorizzare i benefici di un sistema per la misurazio-ne del software. Ciò premesso, l’unico approccio valido è quello di confrontarei benefici di aziende che possiedono un sistema con altre che ne sono privi.I fattori principali che rappresentano indirettamente tali benefici sono:

• l’acquisto di quota di mercato;• l’aumento del livello di soddisfazione del cliente;• l’aumento del profitto dell’azienda.

Capers Jones [50] ha verificato il “valore” di un sistema di misurazione analiz-zandone l’impatto in una grossa organizzazione: l’IBM.Jones ritiene che una delle ragioni principali dello strapotere dell’IBM nell’uni-verso delle industrie dei calcolatori (almeno fino a qualche anno fa!) consiste nelfatto che il suo fondatore Thomas Watson, Sr., ha sempre avuto una particolareattenzione al livello di qualità dei prodotti, nonché al massimo grado di soddisfa-zione dell’utente, e ha introdotto sistemi di misurazione di qualità dei prodottisin dall’inizio della storia della società. Tale atteggiamento è continuato con tuttii successivi manager.La registrazione dei dati relativi alla misura della qualità dei prodotti IBM con-tiene, sin dalle fasi iniziali, le informazioni riguardanti i requisiti dell’utente,nonché le notizie sulle fasi di installazione e per quanto possibile di manutenzio-ne. Inoltre vengono continuamente monitorate e memorizzate le anomalie riscon-trate dagli utenti.L’IBM è la prima società a convincersi del rapporto diretto esistente fra laqualità e la produttività del software e a rilevare che i prodotti con il minornumero di difetti, scoperti dai clienti, sono sempre quelli che hanno avuto lamassima produttività. Questi fenomeni, evidenziati nei primi anni ‘70 e pub-blicati nel maggio 1975, non sono stati evidentemente convincenti poiché,ancora oggi, diverse aziende di produzione di software (anche di grosse di-mensioni) non sono convinte che qualità e produttività siano due obiettividirettamente correlati.


L’IBM possiede un database relativo ai difetti dei prodotti installati molto det-tagliato che permette di conoscere, l’origine e la severità dei difetti per ciascunprodotto, per ogni mese dell’anno, per paese e per ogni città principale.I manager dell’IBM ricevono un bollettino mensile di qualità relativo ai dati pro-gressivi per ciascun prodotto, laboratorio e divisione, oltre a quello relativo allivello globale della società.Una delle osservazioni, apparentemente ovvie, fatte sui dati relativi al databasedei difetti è la seguente:

“un progetto con un basso numero di difetti rilevati corrisponde semprea un alto livello di soddisfazione dell’utilizzatore, come per contro un altonumero di difetti rilevati corrisponde a un basso livello di soddisfazionedell’utilizzatore”.

Questa conclusione è stata pubblicata, con dati alla mano, nei primi anni ‘70.I dati relativi alle misure di produttività dei progetti software dell’IBM sono statielaborati e pubblicati nel 1977 [48]. La pubblicazione ha consentito inoltre diosservare che tali misure permettono facilmente di estrapolare i fattori essenzialiche influenzano la produttività del software.La conclusione più importante a cui sono arrivati gli autori della pubblicazioneè la seguente:

“non è facilmente ipotizzabile il livello della produttività sulla base delnumero di errori osservati nelle linee di codice di un prodotto software”.

Questa osservazione, apparentemente poco importante, ha dato però la spintadecisiva a un ricercatore dell’IBM per inventare qualche altra unità che potesserappresentare la misura della produttività meglio delle linee di codice.Allen J. Albrecht propose e pubblicò per la prima volta nell’ottobre del 1979 iconcetti della metrica dei punti funzione (Function Points) [3].Le proprietà e le correlazioni basate sulla metrica di punti funzione hanno per-messo all’IBM di migliorare sempre di più le metodologie e gli strumenti per losviluppo del software.

3.2.2 Valutazione del “costo” del sistemaper la gestione della misurazione del SW

La gestione della misurazione corretta e completa del software è un processo nona basso costo. Sulla base di dati empirici si può affermare che l’ordine di gran-dezza dei costi si avvicina a quelli per la gestione completa della contabilità glo-bale.


In un’azienda già in possesso di programmi per misurare il software, il costoannuale di tale gestione è valutato intorno al 5% del costo totale di sviluppo delsoftware con circa il 2% riferito alla misurazione della produttività e circa il 3%alla misurazione della qualità del software e alla soddisfazione dell’utente.Per orientare meglio il lettore possiamo confermare che alcune grandi organiz-zazioni come IBM, Hewlett Packard (HP) e AT&T impegnano mediamente unadozzina di persone a tempo pieno alla misurazione del software al livello centrale,e circa 5/6 persone per ciascuna direzione periferica. In queste organizzazioni,inoltre, il numero dei manager che in un modo o nell’altro durante l’anno si in-teressa alle misure di software si aggira sul centinaio.

3.2.3 Creazione del “profilo” del personale per la gestionedel sistema finalizzato alla misurazione del SW

Purtroppo non esistono ancora, a livello universitario, corsi specifici relativi allamisurazione di qualità e produttività del software, e meno che mai alla misura-zione della soddisfazione dell’utente. Di conseguenza, non è facile inserire inorganizzazioni, personale con un background accademico specifico.Anche i corsi post universitari e specialistici sono carenti in questo campo, quindile aziende affermate dovranno creare figure con conoscenze specifiche attraversoaddestramenti interni ed esperienze sul campo.In linea teorica possiamo disegnare il “profilo” del personale ideale che devepossedere la conoscenza dei seguenti argomenti:

• Software Engineering e progettazione;• metodi di stima e pianificazione;• metodologie di controllo di qualità, ispezione, walkthroughs, testing;• analisi statistiche e multivarianti;• principi base della metrica;• principi base di contabilità.

3.2.4 Posizionamento e modifica dell’organizzazionenell’inserimento del sistema per la misurazione del SW

Misurazione della produttività, qualità e soddisfazione dell’utente possono esseremeglio gestite all’interno di un’organizzazione se viene creato un gruppo di lavorospecifico, esattamente come avviene in un ufficio destinato alla contabilità di altriprocessi aziendali.A livello organizzativo si possono avere i risultati migliori se tale gruppo vieneposto sotto la diretta responsabilità della direzione della società e comunque allostesso livello dello staff di direzione.


Deve quindi esistere un “gruppo di misura” a livello direzionale con l’incarico dicoordinare tutti i gruppi di misura divisionali e con la responsabilità del rapportoannuale sulla produttività aziendale.

3.2.5 Ipotesi di un “piano” operativo per la gestionedel sistema di misurazione del SW

L’esperienza suggerisce che è opportuno organizzare il sistema di misurazione inun insieme di attività ed eseguire in modo sequenziale i task identificati.Un ciclo completo del sistema di misurazione è composto di nove attività:

1) Misure operazionali: sono sicuramente quelle più familiari e rappresentanole misure chiave nella valutazione dell’utilizzo dei sistemi di elaborazione(calcolatori):

• tempo effettivo di funzionamento del calcolatore;• tempo effettivo di non funzionalità operativa del calcolatore;• tempi di risposta;• eccetera.

Le misure operazionali vengono effettuate fin dal lontano 1950.

2) Misure progettuali: si riferiscono allo scostamento dei costi previsti dei pro-getti rispetto ai consuntivi. Queste misure dovranno essere rigidamentepianificate ed effettuate mensilmente. Trascurare il formalismo in questotipo di attività spesso induce i responsabili, specialmente all’inizio, a pre-sentare comunque positivamente l’andamento del progetto evitando ditrasmettere notizie contrastanti.Anche questa tipologia di misurazione è in uso da oltre 30 anni.

3) Misure dei costi arretrati: misure relative all’investimento del software. È lamisurazione dei costi del software in esame relativo ai costi globali. Sonoqueste le misure normalmente effettuate da consulenti esterni.

4) Misure di soddisfazione dell’utente: è una misurazione di estrema rilevanzaperché può rappresentare bene l’andamento dell’azienda sul mercato. Talemisura costituisce inoltre un indicatore molto importante per la gestioneinterna dei gruppi di lavoro.Essa richiede un lavoro meticoloso di interviste all’utente, utilizzando mo-duli e questionari ad hoc. Questo tipo di misura ha avuto inizio nei primianni ‘60.

5) Misure consuntive dei progetti: vengono utilizzate diverse metriche (FP, li-nee codice, mesi e così via) e riguardano i costi dei progetti completati.


Pur essenziali per una conoscenza nelle stime future, le misure a consun-tivo non contribuiscono direttamente al successo o fallimento di un pro-getto software.Mentre aziende come l’IBM hanno iniziato sin dagli anni ‘60 a misurare ilconsuntivo completo dei loro progetti, nella maggior parte delle altre so-cietà tale misurazione è entrata a far parte delle attività di controllo SW soloagli inizi degli anni ‘80.

6) Misure dei fattori “soft”: le cui conoscenze sono indispensabili perché in-fluenzano il ciclo di sviluppo dei progetti. Tipici fattori “soft” per la gestio-ne di progetto software sono;

• le metodologie adottate,• i tool utilizzati,• gli skill del personale,• l’organizzazione.

La misura e quindi la conoscenza dello stato dei fattori “soft” permet-tono di eliminare le debolezze e aumentare le caratteristiche positivedell’azienda.L’analisi e le misure dei fattori “soft” sono entrate nella reale vita aziendalesolo nella metà degli anni ‘80.

7) Misure dei difetti: solo poche aziende misurano fin dalla nascita il pesodei difetti (bugs) riscontrati. Questo è principalmente dovuto all’altocosto relativo alla identificazione e alla correzione dei “bug” delsoftware prodotto.L’uso sistematico della misura dei difetti è entrato massicciamente, nell’in-sieme delle attività di controllo del SW, soltanto da pochi anni.

8) Misure demografiche aziendali: sono realmente poche le aziende consape-voli dell’importanza che riveste la conoscenza dello stato ( età, tipo di espe-rienza, competenza...) di tutti dipendenti. L’assegnazione “ottimale” delpersonale più adatto ai progetti è uno dei parametri principali del succes-so del progetto. Diventa quindi essenziale il tempestivo aggiornamentodello stato dei dipendenti affinché la direzione aziendale sia a conoscenzadelle caratteristiche delle figure professionali presenti e quindi in grado diassegnare il personale più adatto al progetto in esame.Anche questo tipo di misura comincia a entrare nelle attività di controllosoltanto dall’inizio degli anni ‘90.

9) Misura dell’opinione: l’ultimo ma non meno importante tipo di misurazio-ne, che si dovrebbe effettuare con una frequenza annuale è un rapporto checontenga la misura dell’opinione di tutti i dipendenti su varie attività e in


particolare sugli obiettivi aziendali percepiti. Il rapporto dovrebbe da unaparte misurare lo stato “motivazionale” dei dipendenti e dall’altro cattu-rare eventuali malesseri operativi.La misura delle opinioni, pur costituendo un fattore di notevole importan-za, non rientra ancora, purtroppo nelle attività programmate eoperativamente eseguite dalla maggior parte di aziende – non solo produt-tori di software.

3.3 Metriche e qualitàIl problema della qualità del SW è strettamente connesso ai successi nel campodelle MS. DeMarco asserisce infatti che “non è possibile controllare ciò che nonsi riesce a misurare” [24]. Inoltre il Quality Assurance Institute (l’Istituto inter-nazionale per l’assicurazione della qualità) pone le MS in una posizione privile-giata nel proprio programma di ricerca.Molti osservatori concordano sul fatto che già oggi, ma ancor di più nel prossi-mo decennio, la qualità e il controllo della qualità sono fra i più importanti fattorieconomici internazionali.Nei trattati scritti dagli specialisti del Software Engineering esiste una gran varietàdi concetti riguardanti la qualità del SW.Barry Boehm, pensa alla qualità come al “conseguimento di un alto grado disoddisfazione da parte dell’utente, portabilità, manutenibilità, robustezza e sem-plicità d’uso”; W. Humphrey, del Software Engineering Institute, si riferisce allaqualità come: “raggiungimento di un livello eccellente di semplicità d’uso, con-formità ai requisiti, affidabilità e manutenibilità”. James Martin asserisce chequalità del SW significa “rispettare i tempi, il budget e soddisfare le necessitàdell’utente”; Capers Jones definisce la qualità del SW come “l’assenza di difettiche potrebbero causare l’arresto del sistema, o produrre risultati inaccettabili. Idifetti possono essere ricercati nei requisiti, nel disegno, nel codice, nella docu-mentazione o nell’individuazione errata di difetti precedenti”. Per Tom McCabe,lo specialista della complessità, essa rappresenta “alto grado di soddisfazione daparte dell’utente e basso grado di difetti, spesso associati con una bassa comples-sità”. Per ultimo John Musa, dei Bell Laboratories, creatore dei modelli diaffidabilità, sostiene che la qualità è un cocktail di “difetti di basso livello, ade-sione del SW alle necessità dell’utente e alta affidabilità” [50].Per poter valutare i principali fattori che definiscono la qualità di un software sipossono individuare due criteri:

1. la qualità deve essere “misurabile”, quando occorre;2. la qualità deve essere “predicibile”, prima che occorra.


Nella Tabella 3.1 (risultato di un’indagine riportata da Jones [50]) sono elenca-ti i fattori di qualità con l’indicazione del soddisfacimento o meno dei criteri pre-cedentemente definiti.Come si nota dalla tabella, tra i fattori di qualità sono presenti il costo (budget)e il tempo di realizzazione (durata). Quindi, perché un prodotto SW sia va-lido esso deve soddisfare le esigenze tecniche, ma soprattutto quelle econo-miche. Esiste infatti un legame reciproco tra costo e qualità: il costo è unfattore della qualità, e viceversa, la qualità è un fattore che incide notevolmen-te sul costo.Tutto ciò porta a un’affermazione di Capers Jones [50], della quale siamo asso-lutamente convinti:

“... la qualità è il principale elemento trainante per i prodotti ad alta tec-nologia. Le aziende che hanno realmente recepito questo concetto sonoproiettate per ottenere successo nel XXI secolo; le organizzazioni che nonhanno ancora assimilato questa opinione almeno come approccioaziendale, sono candidate a scomparire prima di vedere il XXI secolo!”

Tabella 3.1

Fattori di qualità Predicibile MisurabileLivello dei difetti Sì SìOrigine dei difetti Sì SìGravità dei difetti Sì SìEfficienza delle tecnichedi rimozione dei difetti Sì SìComplessità del SW Sì SìAffidabilità del SW No SìMantenibilità del SW Sì SìDurata del progetto Sì SìBudget del progetto Sì SìPortabilità del SW Sì SìConformità ai requisiti No SìSoddisfazione dell’utente No SìSemplicità d’uso No SìRobustezza del SW No NoRiusabilità del SW No SìLivello della documentazione No Sì


Ritornando al problema della misurazione, è evidente che le MS utilizzabili tan-to per il controllo dei progetti quanto per la stima sono di particolare importanzaper il SW manager. Il tipico approccio all’uso delle MS nell’attività di controllo,valido per tutte le fasi del ciclo di vita del SW, prevede di:

1. stabilire degli obiettivi (target) di requisiti o di standard, quantificabili conmetriche opportune, per tutte le attività e gli output associati a ogni fasedi sviluppo;

2. misurare i valori effettivamente riscontrati (actual), non appena questi di-ventano disponibili, e confrontarli con le stime;

3. formulare un piano per correggere le deviazioni eventualmente riscontratetra i target e gli actual.

In sintesi, i target rappresentano i vincoli entro i quali il project manager deveoperare, mentre le misurazioni effettive consentono di verificare quantita-tivamente l’evoluzione del progetto rispetto agli obiettivi.La metrica, pur essendo un approccio efficacemente utilizzato nelle più diverserealtà industriali, quando viene applicata al caso della produzione di SW, fa in-sorgere almeno tre problemi fondamentali:

1. possono esistere più cause responsabili di una deviazione e per ognuna diqueste possono essere intraprese diverse azioni correttive. Il project mana-ger deve quindi potere disporre di procedure addizionali per diagnosticarecorrettamente le cause e decidere la “cura” da adottare;

2. gli stessi target possono essere non significativi se sono basati su stime pocoaccurate. Questo complica ulteriormente la comprensione delle ragioni chehanno determinato uno scostamento dagli obiettivi, in quanto si deve an-che potere distinguere tra comportamenti effettivamente anomali e quel-li dovuti invece ad aspettative irrealistiche;

3. le MS non dispongono di scale di interpretazione oggettive. Non c’è mododi valutare cosa rappresentino “in assoluto”, per esempio, 100 linee dicodice, come invece si può fare nel caso di 100 gradi centigradi. Di conse-guenza le MS vanno interpretate relativamente e, purtroppo, soggettiva-mente, in base cioè alle proprie esperienze e convinzioni.

Per quanto riguarda il primo punto (non univocità delle cause), la letteraturaviene in aiuto con gli studi di Kitchenham [52] e Doerflinger-Basili [26], in cui ven-gono proposti e analizzati i diversi scenari di anomalie e suggerite le possibili cause.Per limitare i danni provocati da stime approssimative si consiglia [53] di utiliz-zare gli stessi actual per ricalcolare una stima di target. Questo perché spesso


accade che i valori impiegati per effettuare le stime degli obiettivi siano a lorovolta delle quantità stimate. Per esempio, se per ottenere una previsione sui tempidi sviluppo si rende necessaria una valutazione a priori della dimensione delcodice, si può rielaborare quella stessa stima utilizzando però l’effettiva dimen-sione del programma sorgente (ovviamente solo alla fine della fase di codifica),in modo da poter decidere, con maggior obiettività, se il tempo speso è statoappropriato o meno. Tra l’altro questa forma di feedback fornisce un notevolecontributo sia per l’identificazione degli obiettivi nei progetti futuri che per lacalibrazione dei modelli di stima.Infine, se si vuole ridurre il grado di soggettività quando si rileva uno scostamentotra le misurazioni effettive e i valori attesi, una buona politica è quella di nonbasare il proprio giudizio solamente sulle analogie e differenze riscontrate inprogetti simili, realizzati nel passato, ma anche di considerare l’andamento gene-rale del progetto in esame. In pratica si tratta di individuare anomalie rispetto aglistandard “locali” (per esempio, “il modulo x del sottosistema y ha richiesto piùtempo per la stesura delle specifiche rispetto alla media del resto del sistema”),piuttosto che considerare universalmente validi i valori ricavati da analisi statisti-che o da requisiti troppo stringenti.In sostanza, l’uso sistematico e scientifico delle metriche per il software è sicu-ramente un elemento essenziale e di sicuro successo nella gestione dei progettiSW, in quanto permette di caratterizzarne quantitativamente gli aspetti essenziali,e cioè poter classificare, confrontare e analizzare e quindi proiettare i risultatiottenuti nelle successive applicazioni [20].

3.4 Metriche per la qualità del softwareOltre ai fattori specifici di qualità, riportati nella Tabella 3.1 (con le relative in-dicazioni di misurabilità e predicibilità), si può affermare in generale che le me-triche da applicare a un prodotto software sono formate da un metodo e da unascala di valori, usati per determinare il livello delle caratteristiche possedute dalSW analizzato.Quindi per determinare il livello di una caratteristica si deve predefinire la sca-la dei valori e decidere in quali intervalli rientra la specifica caratteristica delsoftware.Una possibile range di valori per classificare le caratteristiche, che più avantidescriveremo, può essere:

••••• insufficiente: la maggioranza parte degli attributi della caratteristica non ri-sponde ai requisiti definiti dall’utente;

••••• sufficiente: esiste un numero sufficiente di attributi della caratteristica taleda coprire mediamente i requisiti richiesti;


••••• buono: la copertura degli attributi della caratteristica rispetto ai requisitirichiesti è praticamente totale;

••••• ottimo: oltre ad avere una corrispondenza uno a uno di tutti gli attributidella caratteristica rispetto ai requisiti definiti dall’utente, esistono dei con-tributi particolari che danno un’ulteriore evidenziazione della qualità perla caratteristica in esame.

3.4.1 Caratteristiche standard per la qualità del softwareLe caratteristiche fondamentali, individuate dallo standard ISO 9126, per valu-tare la qualità di un prodotto software sono sei:

1. Funzionalità;

2. Affidabilità;

3. Usabilità;

4. Efficienza;

5. Manutenibilità;

6. Portabilità.

FunzionalitàÈ la caratteristica fondamentale di un qualsiasi prodotto software.

“La funzionalità è un insieme di attributi che definiscono l’esistenza, nelprodotto software, di un gruppo di funzioni con relative e determinate pro-prietà.”

Le funzioni sono la realizzazione dei requisiti del software costruiti per soddisfarele esigenze richieste. Il valore da assegnare a questa caratteristica deve rappresen-tare quanto l’insieme di attributi soddisfa i requisiti predefiniti. In questa valu-tazione non devono essere prese in considerazione né la durata né la modalità conle quali sono stati raggiunti.La valutazione della caratteristica di funzionalità risulta tra le più difficili dadefinire, dimostrare e verificare. La funzionalità determina se un programmaesegue esattamente il compito per il quale è stato costruito. È evidente la diffi-coltà di tali verifiche per software di elevata complessità, come ad esempio quellidove sono in gioco vite umane, o che comportano grossi rischi economici.

Affidabilità

Con questo termine si intende:


“l’insieme di attributi che descrivono la capacità del software di mantenereun livello di performance prefissato, in precise condizioni per un periodo ditempo stabilito.”

Per affidabilità s’intende anche:

“la capacità di un requisito di soddisfare una funzione richiesta...”.

Poiché l’usura e l’invecchiamento sono fenomeni assenti nei prodotti software,la scarsa affidabilità di un programma deriva da difetti nei requisiti, nella proget-tazione o nell’implementazione. Problemi dovuti a difetti insorgono con grandis-sima frequenza nella realizzazione di prodotti in tempi di lavoro ristretti, quandoi programmatori sono costretti a lavorare sotto stress.Una scelta manageriale può essere quella di realizzare le funzionalità generali diun prodotto software piuttosto che implementare costosi requisiti specifici chesi verificano con basse probabilità.

UsabilitàQuesto concetto viene definito nella normativa ISO come:

“l’insieme di attributi che descrivono la semplicità d’uso come valutazioneindividuale sull’uso di un requisito da parte di un insieme di utenti.”

Il termine “utenti” si riferisce alle persone che interagiscono direttamente con ilsoftware cioè gli operatori, gli utilizzatori finali e gli utilizzatori indiretti.Se prendiamo un elettrodomestico qualsiasi, per esempio una lavastoviglie, esenza leggere le istruzioni riusciamo a usare tutte le sue funzioni, allora possia-mo affermare che l’oggetto è facile da usare, ovvero che la sua usabilità è alta.La caratteristica di usabilità include la preparazione all’uso e la valutazione deirisultati ottenuti. Il suo valore è accresciuto notevolmente negli ultimi anni,specialmente dove l’avvicinamento all’informatica, da parte di persone nonesperte, è notevole. Le operazioni da eseguire devono essere semplici ed ele-mentari. A questo scopo sono nate le interfacce grafiche, i computer parlanti,i sistemi operativi a icone. Le innovazioni descritte scaturiscono dall’analisidella caratteristica di usabilità.

Efficienza

L’efficienza, descritta in altri standard come sotto caratteristica dell’usabilità, èstata “elevata” dalla normativa ISO 9126 a caratteristica vera e propria. L’effi-cienza è:


“un insieme di attributi che descrive la relazione tra il livello di performan-ce del software e l’ammontare delle risorse usate, sotto determinante condi-zioni.”

Le risorse devono includere, oltre al prodotto software, le attrezzature hardware,i materiali (stampe, carta, dischetti), i servizi di installazione, la manutenzione el’assistenza utente.

ManutenibilitàI programmi usa e getta, realizzati per operazioni ben specifiche, usati per sod-disfare un’unica esigenza e distrutti alla fine dello specifico utilizzo, stanno scom-parendo. Il software è sempre più adattabile. La stessa procedura è usata in piùprogrammi e su varie piattaforme. Il fattore economico incentiva questa trasfor-mazione. Si trovano ora in commercio molti strumenti atti a produrre softwaremodulari e adattabili con piccoli sforzi.La manutenibilità è:

“l’insieme di attributi che descrivono lo sforzo necessario per fare specifichevariazioni a un prodotto software.”

Il termine “variazioni” comprende le correzioni, le migliorie e gli adattamenti cheil software subisce per cambiamenti d’ambiente, di requisiti o di specifichefunzionali. Un software di elevata qualità deve essere manutenibile perché lasemplicità di variazione copre una vasta area di vendita sul mercato senza gros-si costi.

PortabilitàL’ultima caratteristica, ma non per importanza, indicata dall’ISO è la portabilità,formalmente definita come:

“un insieme di attributi che descrivono la facilità di trasferire un prodottosoftware da un ambiente in un altro.”

dove per “ambiente” si intende l’organizzazione, l’ambiente hardware o software.Fino a qualche tempo fa la portabilità era una prerogativa riservata ai grandiprogetti software. Oggi esistono prodotti veramente portabili anche in “piccoli”ambienti come quelli dei personal computer. La differenza da macchina a mac-china, da sistema operativo a sistema operativo, impedisce di fatto una portabilitàtotale di un prodotto software. La tecnologia hardware e software viene indiriz-zata dal mercato verso standard universali e non specifici.


Il concetto di portabilità non si limita al prodotto software, in particolare, mol-te volte sono l’hardware e il software di base che garantiscono la portabilità delsoftware applicativo.Essa può essere una conseguenza indiretta e non presente esplicitamente in unprodotto software e dipende dall’hardware e dal software di sistema. Un’appli-cazione non portabile può diventare portabile se i progettisti di sistemi operati-vi hanno preventivamente preso in considerazione questa possibilità.

3.4.2 Applicazione delle metriche di qualità del softwarePer definire la qualità dei requisiti SW e valutare (misurare, classificare e verifi-care) i relativi prodotti sviluppati, ci si può avvalere della seguente procedura:

• definire i requisiti di qualità di un prodotto software;• valutare se le specifiche software soddisfano i requisiti di qualità durante

tutta la fase di sviluppo;• descrivere caratteristiche e attributi del software implementato (per esem-

pio i manuali utente);• valutare il software prodotto prima della vendita;• valutare il software prima dell’acquisto.

Sia la scala di valori descritta nel capitolo precedente, sia le sei caratteristichestandard sopra enunciate sono possibili criteri di valutazione della qualità delsoftware. Ciò che invece si deve rigidamente tenere presente è che le metriche,le scale di valori e i criteri applicati per la valutazione della qualità del softwaredevono essere stabiliti prima che i risultati delle valutazioni siano disponibili.L’importanza di ogni singola caratteristica di qualità varia a seconda della cate-goria di appartenenza del software stesso. Per esempio, l’affidabilità è moltoimportante per i sistemi software dove un errore può causare dei danni (fisici e/o economici), l’efficienza per i sistemi software in tempo reale, l’usabilità per unsoftware interattivo che interagisce con utenti diversi. Vi sono quindi caratteri-stiche che in un progetto risultano essere molto importanti e in un altro secon-darie se non addirittura inutili. L’importanza di ognuna di esse varia a secondadel punto di vista considerato e quindi influisce sulla qualità e anche sul costo delsoftware.

3.5 Metriche per la stima dei costi del softwareUna prima classificazione per le MS adottate dai modelli di stima dei costi delsoftware (SCS) prevede la suddivisione in:


• metriche di input;• metriche di output.

Questa suddivisione fa riferimento alle metriche usate per rappresentare o deri-vare i dati numerici delle equazioni di stima (metriche di input) e di quelle chemisurano i risultati che queste ultime forniscono (metriche di output).Accenneremo anche alle “metriche di elaborazione” le quali, anche se a oggi nonhanno avuto la dovuta “attenzione” nel mondo accademico, sono “degne” diessere oggetto di studi e verifiche future.Le metriche di input vengono a loro volta suddivise in:

• basiche;• calcolate.

Le prime costituiscono semplici “conteggi” di quantità, osservabili empi-ricamente (per esempio, numero di linee di codice), mentre le seconde derivanodal calcolo di una formula matematica, applicato ai dati forniti dalle metrichebasiche. Esempi di metriche calcolate sono le Software Science Metrics [37], e iFunction Point [4].

3.5.1 Metriche di inputUn qualsiasi modello di stima, per poter essere utile nella pratica, deve forniredelle valutazioni “precoci” siano accompagnate da una precisione “accettabile”.Di conseguenza i dati di input ai modelli di SCS devono essere disponibili all’ini-zio, cioè in quelle fasi in cui si possiede una discreta conoscenza del progetto darealizzare, in modo da raggiungere il miglior compromesso fra precisione eprecocità.Con l’unica eccezione delle “linee di codice”, la maggior parte delle metrichedipendono dalla disponibilità di informazioni che si ottengono nelle prime fasidel ciclo di sviluppo del SW: analisi dei requisiti, disegno ad alto livello e/o det-tagliato dell’architettura.

Linee di codice sorgente, SLOC (Source Lines Of Code)

L’origine di questa metrica risale agli albori dell’informatica stessa, quando iprogrammi venivano scritti in linguaggio Assembler e ogni istruzione, compostada un codice operativo oltre agli indirizzi degli operandi e da un eventuale com-mento, risiedeva su una singola scheda perforata, logicamente e anche fisicamenteseparata dalle altre.Con l’evolversi dei linguaggi di programmazione il concetto di linee di codice haperso progressivamente la sua primitiva identità per diventare un’entità alquantoastratta [49]:


“... esiste una correlazione tra un livello o potenza (espressività) di un linguag-gio (cioè il numero medio di istruzioni macchina coinvolte nell’esecuzione diuna singola istruzione sorgente) e la sua “ambiguità” in termini di difficoltànel conteggio obiettivo delle righe di codice”.

Addirittura il termine “linea di codice” perde completamente il suo significatoquando è applicato alla misurazione di programmi scritti con i formalismi dellaquarta e quinta generazione (spreadsheet, query-languages e simili), per i qualidevono venire studiate e applicate metriche alternative (per esempio i FunctionPoint).Comunque, fino ai linguaggi della terza generazione è ancora possibile effettuaremisurazioni sufficientemente accurate e consistenti a patto che vengano stabilite re-gole di conteggio univoche. Per esempio, Capers Jones [49] ha individuato nella de-finizione di SLOC (Source Lines Of Code) tre gruppi ortogonali di convenzioni:

a) metodo di conteggio a livello di linea:

• contare le linee come linee fisiche sullo schermo• contare le linee come linee logiche, cioè delimitate da caratteri partico-

lari (per esempio, “;”);

b) metodo di conteggio a livello di programma;

• contare solo le linee eseguibili• contare le linee eseguibili e le linee di definizioni dei dati• contare le linee eseguibili, le linee di definizioni dei dati e le linee dei

commenti• contare le linee eseguibili, le linee di definizioni dei dati, le linee dei

commenti e le linee di JCL (Job Control Language);

c) metodo di conteggio a livello di progetto:

• contare solo le linee nuove• contare le linee nuove e le linee modificate• contare le linee nuove, le linee modificate e quelle riusate• contare tutte le linee consegnate e quelle del codice temporaneo even-

tualmente utilizzato nello sviluppo• contare le linee consegnate, quelle temporanee e quelle del codice di

supporto.

Dalla Tabella 3.2 tratta da [49] è possibile rendersi conto delle considerevoli va-riazioni (in media 1 a 5) che si possono verificare adottando convenzioni diver-se nel conteggio delle SLOC di uno stesso programma. Questa constatazioneporta ad affermare che sui dati riportati nella letteratura relativi alla produttivi-


tà del software, ci potrebbe essere un’incertezza sui risultati di circa il 500%attribuibile esclusivamente al metodo di conteggio delle linee di codice.

Relazione fra SLOC e SCSUno dei metodi più “rozzi”, e tuttora usati, per stimare lo sforzo (S) del SW èquello di valutare il numero I di istruzioni in SLOC necessari all’implementazionedi un progetto e, disponendo di un fattore di produttività (P) che esprima ilnumero di istruzioni codificabili in, per esempio, mesi-persona di lavoro, ricavarecon una semplice divisione lo sforzo necessario allo sviluppo:

S = I/P

(vedi Tabella 3.1)Perché questo metodo possa dare risultati significativi è necessario, oltre a sta-bilire uno standard di conteggio (P viene calcolato sulla base di dati raccolti perprogetti già sviluppati), tenere presente le seguenti considerazioni:

a) la misura di produttività P (P in mesi-persona) è inversamente proporzio-nale al livello del linguaggio utilizzato, cioè quanto più è potente il linguag-gio con cui viene realizzato uno stesso progetto SW, tanto più bassa saràla percentuale di SLOC prodotte per mesi-persona di lavoro, se misuratasull’intero ciclo di sviluppo (e non sulla sola fase di codifica).

Per capire meglio questo “paradosso” consideriamo l’esempio illustratonella Tabella 3.3 dove tre programmi, scritti con linguaggi diversi(Assembler, PL/I e APL), implementano le medesime funzionalità.Se ci spostiamo dal linguaggio di più basso livello verso quello più poten-te notiamo che, mentre lo sforzo di sviluppo diminuisce (da 200 a 80 mesi-persona), la produttività, che ci si aspetta debba crescere, subisce invece

Tabella 3.2

Linee Solo linee Linee eseguibili Totale Totale lineedi codice eseguibili + linee per linee codicecontate definizione dati consegnate temporaneoCodice nuovo 500 1000 2000 5000

Codice riusabile 3000 6000 8000 8000

Codice base 5000 9000 10 000 10 000

Misura apparente 8500 16 000 20 000 23 000

Duratadel progetto 3 mesi 3 mesi 3 mesi 3 mesi

Linee per mese 2833 5333 6666 7666


anch’essa una riduzione (da 500 a 125 SLOC/mesi-persona). Il motivo diquesto comportamento apparentemente anomalo è dovuto al fatto che Pnon misura la vera produttività economica, cioè la quantità di servizi o beniprodotti per unità di tempo, poiché “una linea di codice non rappresentaun bene o un servizio”. Una metrica che misurasse invece le “funzionali-tà” prodotte per l’utente e contenute nei programmi sarebbe sicuramen-te più adeguata e farebbe “muovere” P nella direzione giusta.

b) la correlazione tra il livello del linguaggio e la produttività economica di svi-luppo non è lineare. Sempre nella Tabella 3.3 si può notare che passandodal linguaggio Assembler a PL/I, le SLOC calano di un fattore quattro(pari al rapporto tra le “espressività” dei due linguaggi), mentre lo sforzodiminuisce di un fattore due (da 200 a 100 mesi-persona). Programman-do invece in APL, a dispetto di una riduzione di un fattore 10 (da 100 000a 10 000 SLOC) della dimensione del codice, lo sforzo di sviluppo si ab-bassa di appena due volte e mezzo (da 200 a 80 mesi-persona).

Questo si spiega in realtà con il fatto che il processo di produzione di SW si ar-ticola anche in attività aventi poco o niente a che fare con il codice scritto (peresempio, l’analisi dei requisiti). Esistono quindi dei costi che si possono conside-rare fissi o solo parzialmente sensibili ai “progressi” nella programmazione per-ché dipendono esclusivamente (o quasi) dalle funzionalità implementate nelcodice e non da come questo viene scritto.Nell’esempio precedente vediamo infatti che passando dal linguaggio Assembleral linguaggio APL, mentre il tempo di codifica diminuisce effettivamente di unfattore 10 (proprio il rapporto di potenza tra i due linguaggi), le fasi di analisi deirequisiti, di design e di documentazione mantengono costanti i propri costi, e lafase di testing viene influenzata solo parzialmente (–60%). Di conseguenza risultache, a parità di funzionalità da implementare e di aumento della potenza del lin-guaggio, il peso delle non-coding tasks (inteso come percentuale di sforzo di svi-luppo devoluto in attività indipendenti dal livello del linguaggio), cresce adiscapito delle fasi language-dependent; e quindi l’influenza del formalismo dicodifica sui costi del livello si fa progressivamente meno marcata.L’uso delle SLOC come misura delle dimensioni del SW può essere fonte diambiguità se applicato direttamente e intuitivamente alla stima dei costi. Il se-guente sillogismo ne è un esempio: “se la nostra percentuale di produttività è di200 SLOC/mesi-persona, con il COBOL (livello 3), il passaggio al linguaggio C(livello 4,5) ci permetterà di arrivare a una produttività di 300 SLOC/mesi-per-sona.” In realtà in base a quanto osservato in precedenza, la produttività effetti-va futura sarà di circa 150 SLOC/mesi-persona e l’incauto valutatore dovràprepararsi a fronteggiare sfondamenti del 100% nei propri budget.


Tabella 3.3

Assembler PL/I APLLinee di codice sorgente 100 000 25 000 10 000Attività (mesi/persona) Analisi dei requisiti 10 10 10 Disegno 30 30 30 Codifica 115 25 10 Documentazione 20 20 20 Integrazione e test 25 15 10Totale mesi/persona 200 100 80Totale costi $ 1 000 000 $ 500 000 $ 400 000Linee di codice sorgente

(mese/persona) 500 250 125Costo per linea di codice $ 10 $ 20 $ 40

È importante notare che la stragrande maggioranza dei modelli di SCS richiede,come input, una valutazione delle dimensioni del SW espressa in SLOCunitamente alle regole per il conteggio. Naturalmente a questo punto si pone ilproblema di come stimare il numero di SLOC di cui sarà composto un progetto,a partire da informazioni disponibili nelle fasi iniziali dello sviluppo (analisi deirequisiti e disegno ad alto livello). La metrica basata sul concetto di FunctionPoint, introdotto da Albrecht [3] e descritto nel Capitolo 5, rappresenta unelemento fondamentale nel campo della stima del dimensionamento delsoftware (Sw Size Estimation-SSE ).

3.5.2 Metriche di elaborazioneIl concetto della metrica riferita all’elaborazione, non avendo attualmente unabase teorica consolidata, può fondarsi solamente sull’intuizione.Si possono definire almeno tre categorie di metriche di processing o di elabora-zione:

• metriche di elaborazione basate sul numero di algoritmi classificati in di-verse classi di complessità;

• metriche di elaborazione basate sul numero di tipologie di cicli (loops) pre-senti nel programma;

• combinazione “pesata” dei due punti precedenti.

Attualmente, a nostra conoscenza, non esistono studi in grado di classificaremetriche di elaborazione tali da permettere una misura di complessità del SW e


che possano fornire un contributo alla misurazione dello sforzo necessario allosviluppo.

3.5.3 Metriche di outputLe metriche di output classiche, nel campo della SCS, sono le seguenti:

• lo sforzo (S) complessivo di sviluppo (E-Effort), espresso in mesi-personadi lavoro (MM-Man Month);

• il tempo o la durata di sviluppo (T-calendar Time), cioè il tempo, normal-mente quantificato in mesi (M), che intercorre tra la data di inizio e quel-la di fine lavoro;

• la quantità media di personale (P) addetto al progetto (FSP-Full time SWPersonnel), cioè il numero di persone impiegato al 100% nello sviluppo dellavoro.

Le grandezze (S, M e P) sopra elencate si illustrano da sole, in quanto rappresen-tano le quantità osservabili oggettivamente al completamento di ogni progettoSW e responsabili dei costi di sviluppo. Nel caso in cui il project manager desi-deri avere una stima di S, M e P, suddivisa per le varie fasi che caratterizzano ilciclo di vita del SW, queste grandezze perdono la loro connotazione astratta ediventano parametri quantitativi di supporto. La curva di Rayleigh [9] per esem-pio, se usata propriamente, fornisce una buona approssimazione delle “curve dilavoro” (che descrivono il numero di persone impiegate – P – in funzione deltempo) per molti tipi di progetti SW.Una prima conclusione di quanto esposto è che la “condizione necessaria affin-ché una tecnologia possa essere valutata è che questa sia misurabile” [49]. Se con-sideriamo il fatto che la produzione di sistemi SW è sicuramente una delleattività umane più difficili da gestire e inquadrare in tecnologie applicative, nonci si deve stupire se i manager dei progetti sono particolarmente interessati aiprogressi nel campo delle MS proprio per le potenzialità che queste offrono neldescrivere e predire le caratteristiche complessive di un sistema SW (prodotti,strumenti e metodologie).Fortunatamente il settore delle MS è in grande fermento, come dimostrano ilnotevole numero di nuove metriche proposte dai ricercatori e la crescente quan-tità di pubblicazioni dedicate alle MS, nel corso degli ultimi anni [18].Tutto questo unitamente a quanto Barry Boehm afferma [9] è sicuramente inco-raggiante:

“Il campo della SCS non può sperare di avere i suoi Newton e i suoi Keplerosenza prima avere la sua armata di Tycho Brahe che fornisca i dati tratti daattente osservazioni e accurate misurazioni, dalle quali una serie diintrospezioni scientifiche più profonde possano poi essere derivate”.

44.1 Comprensione e controllo del processo di SCS, 57

4.2 Importanza della SCS, 57

4.3 Sinergia tra SCS e gestione del SW, 58

4.4 Produttività di sviluppo e ciclo di vita del SW, 59

4.5 Stime non accurate: conseguenze, 60

4.6 Difficoltà inerenti alla SCS, 61

4.7 Approcci alla SCS, 63

4.8 Criteri di valutazione e confronto, 65

4.9 Modelli di stima del costo del software, 68

Stima del costo del software

I primi passi nel campo della stima dei costi del software (SCS) fanno riferi-mento alla misurazione della produttività del personale. Essa veniva calcolatacome il numero di istruzioni del linguaggio sorgente prodotto in un datoperiodo di tempo. Nel corso degli anni la stima della dimensione di un pro-getto, del tempo di sviluppo e del suo costo si è basato sull’intuizione, sul-l’esperienza e sulle norme industriali vigenti. Questo approccio, se qualchevolta ha dato risultati abbastanza soddisfacenti, specialmente per progettipiccoli e relativamente semplici, ha portato spesso a risultati totalmente fuor-vianti nel caso di sistemi grandi e complessi.La crescita vertiginosa della domanda del SW e le sfide tecnologiche ed econo-miche che l’hanno accompagnata sono state tali che attualmente la “disciplina”della Software Cost Estimation (SCE) gode di una particolare attenzione da partedei ricercatori del settore universitario e industriale. L’obiettivo di questo ramodella Software Engineering è quello di raggiungere una migliore comprensionedelle dinamiche interne al processo di sviluppo, ancor prima dell’inizio dellaproduzione, per comprendere i parametri che ne influenzano il costo, e arriva-re alla realizzazione di strumenti affidabili e automatici per la stima del costo delSW.La determinazione della stima “accurata” dei costi relativi allo sviluppo di unsistema informativo è un processo critico sia per chi lo deve presentare che peril manager che deve utilizzarlo allo scopo di prendere una decisione.Una sottostima dei costi può far prendere la decisione di autorizzare dei progettiche potrebbero portare a uno spreco delle limitate risorse a disposizione, nonchéal fallimento delle aspettative, al discredito dell’estimatore e degli sviluppatori delprogetto.D’altra parte una sovrastima dei costi di un progetto può condizionare la decisio-ne di intraprenderne lo sviluppo e quindi precludere i potenziali benefici che siavrebbero con la realizzazione del sistema.

58 Stima del costo del software

Va da sé che il processo di SCS diventa ogni giorno più importante proprio invirtù della crescente necessita di utilizzare l’informatica nei vari settori delle or-ganizzazioni pubbliche e private.Per poter affrontare il processo di stima con un approccio corretto è necessarioprima di tutto capirne la natura e quindi poterne controllare l’evoluzione.

4.1 Comprensione e controllo del processo di SCSCerchiamo di analizzare i motivi per cui si deve prima di tutto capire e quindicontrollare la SCS.

• I costi del software sono elevati e continuano ad aumentare, può esserepertanto rilevante ogni percentuale di risparmio.

• Molti prodotti software vengono pensati ma non sviluppati, una migliorecomprensione dei costi di sviluppo e un più corretto controllo permetto-no di operare più efficacemente.

• Comprendere e controllare il processo di sviluppo del software permettedi disporre di software di qualità (maggiore funzionalità, affidabilità...).Questa considerazione acquista un’importanza fondamentale visto che lanostra vita dipende ogni giorno di più dall’informatica.

Possiamo considerare due tipi di approccio per capire meglio il contenuto deicosti del software:

1. l’approccio della “scatola nera” che elabora analisi comparative sui costiglobali di un certo numero di progetti software, e propone i pesi relativi diciascun fattore caratterizzante del processo di sviluppo (vincoli HW, tooldi supporto, esperienza e capacità del personale...) in riferimento al costototale;

2. l’approccio della “scatola trasparente” che analizza uno o più progetti etenta di caratterizzare la distribuzione dei costi interni fra le diverse risorse.Con ciò si intendono i costi diretti piuttosto che quelli indiretti, i costi dicoding e quelli di documentazione, i costi di sviluppo e quelli di manuten-zione; oppure altre distribuzioni dei costi fra le fasi e le attività del ciclo divita del SW.

Ciascuno di questi approcci è complementare all’altro ed entrambi sono indi-spensabili per raggiungere una comprensione completa del processo dei costi delsoftware.

Stima del costo del software 59

4.2 Importanza della SCSLa ragione per cui viene enfatizzata l’importanza della stima del costo delsoftware è che essa costituisce un legame vitale tra i concetti generali, le tecnichedell’analisi economica e il mondo dell’Ingegneria del software. Infatti non esistealcun modo soddisfacente di eseguire un’analisi costi-benefici, breakeven, omake-or-by del software, senza il supporto di un metodo per stimare i costi delsoftware e la loro sensibilità a vari fattori ambientali, di progetto o di prodotto.Si può inoltre affermare che l’importanza delle tecniche di stima del softwareconsiste nel fornire una parte essenziale dei fondamenti per una buona gestionedel software. Senza una capacità ragionevolmente accurata della stima dei costii progetti software vengono caratterizzati dai seguenti problemi [9], [10], [17]:

a) il personale del progetto software non possiede dati concreti per dimostra-re a un manager, cliente o addetto alle vendite, che i loro budget e le sca-denze proposte non sono realistiche. Ciò, come vedremo in seguito, portaa fare previsioni eccessivamente ottimistiche riguardo allo sviluppo inter-no del software, alle offerte al ribasso nelle gare d’appalto di contratti, e aitempi di consegna;

b) i manager del progetto non hanno sufficienti elementi per determinarequanto tempo e quanto sforzo richiederà ogni fase e ogni attività. Questopriva il responsabile del progetto della possibilità di determinare se lo svi-luppo del software sta procedendo o no secondo i piani stabiliti; vale a direche la parte di sviluppo del progetto è, fin dall’inizio, fuori dal controllo.

4.3 Sinergia tra SCS e gestione del SWQuanto affermato nel paragrafo precedente vuole sottolineare il fatto che il cam-po della SCS ha già aperto prospettive (e problemi) interessanti per i ricercatoriche intendano confrontarsi con le valutazioni sinergiche inerenti l’attivitàdell’estimator e quelle del project manager.Le sinergie evidenti fra ciò che viene stimato e il controllo di un progetto softwarepossono essere sintetizzate nei seguenti punti [9]:

a) un’efficiente capacità di pianificazione e controllo fornisce dati sulla distri-buzione del tempo, dello sforzo e del costo dei progetti, e ciò aiuta aricalcolare il modello di stima del costo e dinamicamente adattarlo allesuccessive evoluzioni del progetto. La necessità di calibrare un modello diSCS utilizzando i dati di progetti attuali viene ribadito da più parti [17],[24], [51], [53];

b) un’affidabile capacità di stima del costo del software promette una miglioregestione del progetto. Infatti, specificando auspicabili risorse per svolge-


re bene il lavoro e offrendo indicazioni sensate del costo stimato per ognifase e attività di progetto, si costituisce una base per la pianificazione e ilcontrollo.

Come conseguenza pratica e molto interessante, legata agli altri effetti sinergiciche si ottengono combinando affidabili metodologie SCS con efficienti tecnichedi project-management, si può osservare che [17]:

“... se una stima del costo di sviluppo del software non si scosta più del20% dalla prima stima ‘ideale’ (e cioè quella reale) del costo del lavoro, unbuon manager può trasformarla in una ‘profezia’ che si compie da sola”.

Lo scostamento “ragionevole” del 20% è facilmente giustificabile sottolineandoi componenti normali di inattività della tipica settimana di lavoro di una perso-na addetta al software (addestramento, attività personali, attività professionaligenerali). Tali attività consumano in media circa il 30% del tempo di lavoro diuna persona addetta al software e costituiscono il “serbatoio” di ore-lavoro cuisi può attingere nel caso in cui si rendesse necessario stringere i tempi.Il manager del progetto potrebbe stimolare i membri del gruppo di lavoro a di-stribuire appropriatamente il loro tempo di inattività stabilendo dei momentidecisionali – milestone (pietre miliari) – intermedi al progetto, cui siano associatibudget e programmi di lavoro basati a loro volta sulle stime di costo, e programmidi lavoro finalizzati al raggiungimento degli obiettivi di questi milestone.Quindi, con un insieme appropriato di milestone1 e un buon insieme di tecnichedi pianificazione e controllo, un abile manager può concludere un progetto ra-gionevolmente ben stimato, in tempo e nel budget prefissato.

4.4 Produttività di sviluppo e ciclo di vita del SWUn’importante prospettiva sulla produttività del software – fornita dalla tecno-logia di stima del costo del software – è rappresentata dalla distinzione traproduttività di sviluppo e la produttività del ciclo di vita dello stesso. I compro-messi tra costi di sviluppo più bassi e costi di ciclo di vita più bassi sono caratte-rizzati da pratiche di programmazione moderne e richiedono relazioni di stimadi costi affidabili per lo sviluppo e per la manutenzione.L’utilizzo delle moderne tecnologie di programmazione enfatizza particolarmentela riduzione dei costi di manutenzione grazie a un software:

1 I milestone sono delle attività particolariche non hanno vita ma che esistono per indicare momenticritici, punti di controllo o passaggi fondamentali dei progetti.


• meglio strutturato e documentato;• contenente procedure di librerie di uso comune;• sviluppato con metodologie e procedure orientate all’affidabilità.

Anche se alcuni di questi supporti possono aumentare i costi di sviluppo, essisaranno compensati da costi di manutenzione ridotti, particolarmente per pro-dotti software con ‘vita’ molto lunga [9].

4.5 Stime non accurate: conseguenzeOggigiorno è praticamente impossibile trovare un SW manager in grado di affer-mare di potere valutare a priori e con precisione i costi associati alla produzionedi nuovi sistemi informaticiSecondo Capers Jones (un’autorità mondiale nel campo della SCS e della SWEngineering) la maggior parte degli esperti tende a sottostimare il valore dei progetti,specie se di grandi dimensioni, di una percentuale che oscilla tra il 100 e il 200%!Le conseguenze principali legate all’impossibilità di fornire stime accurate possonoessere raggruppate in tre categorie principali che vengono analizzate qui di seguito.

4.5.1 Conseguenze economicheNel caso di sistemi sviluppati all’interno di una organizzazione, scoprire con ri-tardo di non poter completare un lavoro entro i tempi e i costi previsti, comportageneralmente la cancellazione del progetto con tutte le conseguenze del caso. Dauno studio elaborato da Rubin [72] si rileva che circa il 15% dei progetti di grandidimensioni non arriva mai a compimento, principalmente a causa di un’errataanalisi iniziale delle risorse (tempo e personale) necessarie alla loro realizzazione.Se il progetto è invece sviluppato per conto terzi, una sottostima dei costi costrin-ge il manager a chiedere al cliente, in fase già avanzata di sviluppo nuovi fondi,oppure, se il contratto è basato su importi fissi, dovrà rimetterci personalmentee impiegare le risorse aggiuntive necessarie per rientrare nei tempi previsti. Tuttociò è oltremodo controproducente sia per la sua immagine, sia per il morale delgruppo di lavoro.

4.5.2 Conseguenze tecnicheSe all’avvicinarsi della scadenza rimane ancora troppo lavoro da completare, latendenza comune è quella di alleggerire il peso delle attività conclusive del ciclodi sviluppo del SW, per guadagnare tempo. Sfortunatamente queste attività sono,di norma, il testing, la documentazione, l’integrazione dei moduli e il training del-l’utente cosicché si rischia spesso di consegnare al cliente sistemi poco affidabili,mal documentati e poco capiti da chi questi sistemi deve poi utilizzarli. Ancorauna volta la sottostima iniziale dei costi contribuisce in larga misura al verificar-


si di situazioni come quella sopra descritta, con l’effetto di danneggiare la credi-bilità e l’immagine dell’azienda produttrice di SW.

4.5.3 Conseguenze managerialiNella gestione di un progetto in difficoltà di tempi di consegna, il manager puòdecidere di aumentare lo staff (il gruppo di lavoro) assegnato nella speranza diaccelerare i tempi di sviluppo.Paradossalmente questa soluzione può rivelarsi (ed in genere effettivamente lo è)catastrofica: perché, per salvare il progetto in difficoltà, si deve procedere allariassegnazione degli incarichi del personale (spesso sospendendolo da altre atti-vità), si deve gestire in modo improvvisato, e quindi poco efficiente, l’aumentonon pianificato di queste risorse e si devono ridisegnare i piani di sviluppo. Si hadi conseguenza (legge di Brook) un ulteriore ritardo invece del previsto recuperosui tempi di consegna, senza considerare lo sconforto dei dipendenti, fonte di calidi produttività e di frequenti turn-over.Un buon modello di stima del costo del software offre quindi notevoli beneficiperché, oltre a definire un universo di dissertazioni chiare e consistenti e unatecnologia (quella della stima del costo), in grado di fornire un insieme di capa-cità di osservazione su come un’organizzazione di produzione di SW possa mi-gliorare la propria produttività, esso costituisce anche un fondamento asso-lutamente essenziale per la pianificazione e il controllo di un progetto SW. In unbuon modello di stima del costo, non è possibile ridurre il costo del softwarestimato senza modificare alcune proprietà oggettivamente verificabili del proget-to stesso.

4.6 Difficoltà inerenti alla SCSDate le pesanti conseguenze economiche legate alla sottostima dello sforzo pro-duttivo necessario allo sviluppo del SW, è comprensibile che la categoria dei SWcost estimator prema con insistenza per ovviare a questo problema, la cui soluzio-ne si trova analizzando la causa di questa tendenza.Dagli studi effettuati da DeMarco [24], Boehm [9] e Jones [49], cinque sono leragioni responsabili degli errori nelle stime.

1) Effettuare una stima è già di per sé un processo complesso che richiede uncerto dispendio di risorse per ottenere risultati apprezzabili. Lo stessoBoehm suggerisce di considerare la stima dei costi come un mini-proget-to da pianificare accuratamente, con l’intento di costringere il SW mana-ger a capire più in profondità gli obiettivi di una stima e cioè “perché” lastima si effettua, “che cosa” si vuole stimare per “quando”, “come” si in-tende procedere, “quante” risorse (tempo, dati, personale) si prevede di


impiegare per la stima, “quale” accuratezza di previsioni si può garantirecon le assunzioni fatte. Sfortunatamente lo scenario tipico in cui viene ef-fettuata una stima è ben lontano da ciò che si vorrebbe e si finisce con ilprodurre valutazioni affrettate, basate su specifiche vaghe e nebulose, delsistema da sviluppare.

2) Gli addetti alla stima mancano spesso dell’esperienza necessaria per effet-tuarla. Inoltre, considerando che le persone tendono ad avere un “recuperoincompleto delle passate esperienze” e che poche organizzazioni decido-no di mantenere un database completo dei dati di progetti sviluppati perpoter effettuare analisi statistiche e confronti, l’estimator inesperto potràdifficilmente migliorare le proprie prestazioni nel tempo.

3) La naturale tendenza a sottostimare i costi viene giustificata in diversi modi.DeMarco per esempio osserva che, specie nei progetti di grandi dimensio-ni, le stime vengono ottenute estrapolando la conoscenza acquisita dallesingole parti del sistema e ignorando gli aspetti non-lineari tipici del pro-cesso di sviluppo del SW (ma non solo di questo): integrazione delle fun-zionalità dei moduli realizzati separatamente e overhead associato allacoordinazione delle interazioni dei diversi gruppi di lavoro coinvolti nel-le diverse attività (analisi requisiti, design, coding ...). Boehm e Jones ag-giungono che spesso i manager sottovalutano (quando non dimenticano!),il peso delle fasi più “oscure” del ciclo di vita del SW, quali la documen-tazione, la manualistica, il testing, il project management o lo sviluppo diSW di supporto, oltre che sottostimare le dimensioni del SW stesso, tra-scurando funzionalità quali la gestione di interfacce e file, che costituisconoquasi sempre più del 50% del codice totale.È importante sottolineare che chi effettua la stima è generalmente il mem-bro più esperto di un team; egli deve pertanto tener presente che il lavo-ro verrà poi effettivamente svolto anche da personale meno capace e quindimeno produttivo.

4) Non di rado succede che il manager preposto alla valutazione sia più inte-ressato a cercare di soddisfare un ben preciso obiettivo (come “minimiz-zare i costi” o “rispettare una scadenza prefissata”) piuttosto che a ottenereuna stima obiettiva dello sforzo necessario. Le ragioni di questo compor-tamento sono ovvie:

“... presentando dati allettanti, anche se irrealistici, si ottiene l’effetto di benfigurare con i propri superiori, oltre al vantaggio di potere presentare of-ferte competitive per vincere una gara o convincere un potenziale clientea commissionare un lavoro”.


Per quanto riguarda i problemi “politici”, sempre secondo DeMarco [24],troppo spesso si chiede allo stimatore di “stabilire gli obiettivi di perfor-mance” o, ancor peggio di “accettare obiettivi preventivamente stabiliti”.Quando le stime devono servire da incentivo, esse non saranno maibuone; spesso, pur di rispettare le stime ottimistiche iniziali, vengonoeffettuate operazioni perverse di spostamento dei costi dallo sviluppoalla manutenzione. Il software viene così sviluppato velocemente e eco-nomicamente, ma non sarà affidabile, per cui quando si dovrà effettua-re la manutenzione, si perderà tutto ciò che si era guadagnato inizialmentea causa di operazioni complicate, lunghe e costose. Per poter sanare que-sta manchevolezza, si rende necessaria una ristrutturazione del processodi sviluppo.

5) Infine, pur nell’ipotesi di:

• riuscire a preparare un piano di stima completo;• essere esperti;• potere fare affidamento su statistiche e archivi storici di progetti;• riuscire a controllare la propria naturale tendenza alla sottostima;• riuscire a non farsi influenzare da considerazioni opportunistiche,

rimane sempre il fatto che l’estimator è un “uomo”, sensibile quindi aicambiamenti di umore e incline ad ancorarsi alle proprie convinzioni. Que-sto significa rinunciare all’idea di potere ottenere sempre stime univochee consistenti;

“ ...possibile che per uno stesso progetto due persone diverse, o la stessapersona, ma in momenti diversi, possano dare due valutazioni essenzial-mente diverse, pur partendo dagli stessi dati” [17].

4.7 Approcci alla SCSEsistono tre categorie metodologiche principali per affrontare il problema del-la SCS:

1. il ricorso al “giudizio di esperti”;

2. la stima per “analogia”;

3. l’utilizzo di “modelli algoritmici”.

4.7.1 Giudizio di espertiQuesto metodo richiede di consultare uno o più esperti in materia di SCS e diottenere una valutazione finale per mezzo di tecniche dette Expert Consensus,come la Delphi Technique [9].


Il punto debole di questo metodo è dato proprio dall’eccessiva dipendenza dal-la stima, dalla padronanza che gli esperti hanno realmente di tutti gli aspettichiave del progetto in esame e dalla loro obiettività (troppo ottimisti, o pessimi-sti). Inoltre non sempre l’esperto è reperibile nel momento in cui è necessario,senza considerare poi i costi da sostenere per la consulenza specializzata.

4.7.2 Stima per analogiaIl procedimento richiede di ragionare per analogia con uno o più progetti giàcompletati per correlare i loro costi con quelli di un nuovo progetto dalle carat-teristiche simili.I punti deboli di questo metodo sono:

• non è ben chiaro quanto i progetti passati siano effettivamente rappresen-tativi delle condizioni ambientali, funzionali e operative del nuovo sistemada stimare;

• l’applicabilità di questa tecnica è limitata al caso, non proprio frequente,di progetti per i quali esiste già un database significativo di riferimento,dato che sarebbe estremamente azzardato estrapolare delle conclusioni daprogetti con caratteristiche diverse.

4.7.3 Modelli algoritmiciQuesto approccio prevede l’uso di una o più tecniche procedurali capaci di pro-durre una stima del costo come funzione di un determinato numero di variabi-li, dette cost-driver, che vengono considerate strettamente correlate al costo di unprogetto SW.Ipotizzando di disporre di modelli di per sé validi, la metodologia presenta ingenerale alcune lacune. Innanzitutto non riesce a compensare l’immissione divalori errati o poco precisi dei cost-driver, che rimangono comunque quantitàsoggette in buona misura ai limiti individuali di interpretazione dell’utente delmodello; in secondo luogo, trattandosi di modelli matematici basati sull’analisidi un gran numero di osservazioni e su statistiche, essi non sono in grado di pre-vedere le conseguenze di situazioni che costituiscono eccezioni alla norma, cosache invece un esperto umano saprebbe fare.I modelli algoritmici possono vantare, rispetto alle categorie concorrenti, il me-rito di essere effettivamente obiettivi nelle proprie stime, in quanto non sonoinfluenzati dai fattori di disturbo tipicamente umani (per esempio il desiderio divincere o di soddisfare, stati d’animo particolari), oppure da avversioni o simpatieper questa o quella applicazione. Essi forniscono quindi stime ripetibili e con-sistenti in un qualunque istante e in una qualsiasi condizione ambientale. Sono inol-tre estremamente efficienti in quanto facilmente implementabili su computer.


Tutte queste caratteristiche, unitamente alla loro capacità “sensitiva”, cioè al loroessere sensibili anche a piccole variazioni negli input, rendono i modelli algo-ritmici particolarmente adatti a supportare diverse sessioni di stima corredate dal-le analisi comparative dei risultati. Questo permette anche una loro calibrazionead hoc. Infatti, per uno stesso ambiente di sviluppo, dopo aver raccolto una quan-tità di stime sufficiente a giustificare osservazioni statistiche, si potranno“calibrare” gli algoritmi attraverso indicazioni relative a determinati parametri deimodelli.Non è un caso quindi che, pur con le limitazioni di cui si è scritto, la categoria deimodelli algoritmici sia quella che ha goduto della maggiore attenzione da partedi ricercatori del mondo accademico e industriale, già a partire dagli anni ‘70,proponendosi essenzialmente come strumento di supporto alle decisioni del-l’esperto umano.

4.8 Criteri di valutazione e confrontoPer poter valutare le caratteristiche di ciascuna categoria dei modelli sopra de-scritti è opportuno prima di tutto definire dei criteri univoci. Tali criteri posso-no essere di natura “soggettiva” oppure “oggettiva”.Innanzitutto vediamo di definire dei criteri “soggettivi” attraverso le seguentidomande:

• Validità: il modello fornisce stime “ragionevoli”, cioè lievi sco-stamenti dai dati del database di progetti con cui è sta-to “messo a punto”?

• Oggettività: le stime sono basate su misure e dati ottenibilialgoritmi- camente? Le stime dipendono da fattori sog-gettivi che possono variare significativamente in base achi effettua la stima?

• Facilità d’uso: i dati di input necessari sono facili da reperire? Sono innumero elevato? Le informazioni necessarie sono di-sponibili nelle fasi iniziali del ciclo di vita del SW?

• Robustezza: una piccola modifica nei parametri di input causa gros-se variazioni nella stima?

• Trasportabilità: il modello dipende così strettamente dai dati “locali”(specifici) da non poter essere utilizzato in altri ambienti?

Descriviamo ora brevemente i quattro criteri “oggettivi” maggiormente utilizzatinella letteratura:

1. errore relativo medio;

2. errore relativo assoluto medio;


3. coefficiente di multipla determinazione;

4. predizione al livello (r);

5. valore medio relativo della deviazione standard.

4.8.1 Errore relativo medio ( )REL’errore relativo (Relative Error) è definito come

RE = $Y Y

Y−

(4.1)

dove $Y è la stima di Y.Mentre l’errore relativo medio (Mean Relative Error) è descritto come

REn

REi

i

n

==∑1

1(4.2)

dove REi è l’errore relativo del i-esimo progetto e n è il numero di progetti per iquali sono noti Y e $ .Y

4.8.2 Errore relativo assoluto medioPer quanto concerne l’errore relativo assoluto (Magnitude Relative Error),abbiamo:

MRE REY Y

Y= = −$

(4.3)

L’errore relativo assoluto medio (Mean Magnitude Relative Error) viene invecedefinito come segue:

MREn

MREi

i

n

==∑1

1(4.4)

dove MREi è l’errore relativo assoluto del i-esimo progetto e n è il numero di

progetti per i quali sono noti Y e $ .Y

Quindi, se MRE assume un valore percentuale piccolo, allora il modello pro-duce, in media, una buona stima. La soglia suggerita da Conte e altri [17], al disotto della quale si può affermare che un modello fornisce prestazioni più che ac-cettabili, è:

MRE ≤ 25% (4.5)


4.8.3 Coefficiente di multipla determinazione (R2)Il coefficiente di multipla determinazione (coefficient of multiple determination)è una delle misure più utilizzate e apprezzate per determinare la correlazionelineare fra Y e per la bontà della stima in assoluto.Per n coppie di valori di Yi e R2 è espresso con la seguente formula:

R

Y Y

Y Y

i i

i

n

i

i

n2

2

1

2

1

1= −

−

−

=

=

∑

∑

( $ )

( )(4.6)

Un valore alto di R2 (più vicino a 1) suggerisce che nel modello in esame è pre-sente un’alta percentuale di varianza oppure che il modello non può miglioraresensibilmente le sue prestazioni con l’aggiunta di variabili indipendenti.

4.8.4 Predizione a livello r (PRED(r))Se poniamo k come il numero di progetti appartenenti a un insieme n per i qua-li MRE ≤ r, allora definiamo predizione a livello r, come segue:

PRED rkn

( ) = (4.7)

Per esempio, se PRED(25%) ha il valore di 85%, ciò significa che l’85% dellestime presentano al più un errore del 25%.Un modello è considerato accettabile dal punto di vista prestazionale se fornisceun PRED(25%) ≥ 75%.

4.8.5 Valore medio relativo della deviazione standard ( )RMS

Dato un insieme di n progetti, si definisce lo scarto quadratico medio SE comesegue:

SEn

Y Yi i

i

n

= −=∑1 2

1

( $ ) (4.8)

Questa misura è significativa solo per modelli costruiti con l’analisi di regressione.Definito si può calcolare la sua radice quadrata media – deviazione standard(RMS):


∑ −== 22/1 )ˆ(1

)( ii YYn

SERMS (4.9)

e quindi il suo valore medio relativo ( )RMS è definito come:

RMSRMS

nYi

i

n=

=∑1

1

(4.10)

Si considerano le performance di un modello accettabili quando RMS ≤ 0,25.

4.9 Modelli di stima del costo del softwareNella letteratura sono riportate diverse classificazioni di modelli di stima del costodel SW. Il suggerimento di Conte e altri [17] (che pienamente condividiamo) èdi raggruppare i modelli in categorie, in relazione al metodo usato per derivarli:

• modelli statistici;• modelli storico-empirici;• modelli teorici;• modelli composti.

4.9.1 Modelli statisticiUn qualsiasi modello matematico, per essere “degno” di questo nome, in unmodo o nell’altro si basa su (oppure viene “messo a punto” attraverso) dati sta-tistici. Nel campo di SCS, i modelli statistici vengono solitamente descritti attra-verso un’analisi di regressione per determinare le tendenze base nelle relazioni frale variabili.Per maggior chiarezza consideriamo S (lo “sforzo” in mesi-persona) la variabiledipendente e xi (i = 1, 2, ... n) le variabili indipendenti che supponiamo influen-zino S. L’obiettivo del modello statistico è quello di trovare una relazione nellaforma:

S = F(x1, ..., xn; a1, a2, ..., am) (4.11)

con i coefficienti a1, a2, ..., am che dovranno essere scelti in modo da minimizza-re la funzione seguente:

Er(a1, a2, ..., am) = i

n

=∑

1[Si, – F(x1, ..., xn; a1, a2, ..., am)]2 (4.12)


Nell’Equazione (4.12) la somma è estesa su un insieme di N punti di dati di os-servazione.Sono ormai consolidati gli algoritmi (analisi regressive) in grado di identificarela funzione F che, attraverso il vettore dei coefficienti rende minima { },a j l’Equa-zione (4.12).

Modelli statistici lineariL’equazione seguente rappresenta un modello lineare in forma generalizzata:

S a a xi ii

n= +

=∑01

(4.13)

dove:S è il numero di unità dello sforzo (in mesi-persona),xi sono attributi (tecnici o non-tecnici) del SW o comunque fattori che si presu-

me influenzino lo sforzo per lo sviluppo del SW,ai sono i coefficienti (pesi) di questi ultimi.

Nella letteratura gli xi sono spesso chiamati cost driver.I fattori che in un modo o nell’altro influenzano la “produttività” e quindi con-tribuiscono a valutare lo sforzo, sono numerosi (secondo Jones [49] circa 400).Comunque, molti di questi cost driver sono poco significativi (hanno ilcoefficiente ai quasi zero), altri sono fortemente correlati e quindi possono esserecombinati in un unico fattore, riducendo così il numero di attributi significativi.Uno dei primi studi sui modelli lineari è stato condotto nei primi anni 60 alla SDC(System Development Corporation) [63]. In questo studio sono stati inizialmen-te identificati 104 attributi e, dall’esame di un database di 169 progetti, sono staticalcolati i coefficienti con la tecnica della regressione lineare.Sono state analizzate diverse combinazioni di fattori dalle quali è scaturito unmodello basato su 14 attributi, avente la seguente equazione:

$ , , ,73 , , , , ,S x x x x x x x= − + + + + + + − +3363 915 10 0 51 0 46 0 40 7 28 21 451 2 3 4 5 6 7

+ + + + +13 5 12 35 58 82 30 618 9 10 11, , , ,x x x x 29 55 0 54 25 2012 13 14. . .x x x+ − (4.14)

dove $S è lo Sforzo stimato in mesi-persona. Gli attributi e i relativi range di va-lori sono riportati nella Tabella 4.1.Il modello SDC ha diversi difetti, il più grave si rileva nella sua applicazione aldatabase con cui è stato validato poiché si ottengono errori medi relativi moltoalti. Inoltre alcuni fattori essenziali, come la dimensione del progetto, non ven-gono trattati esplicitamente.


Un altro modello lineare basato su dati statistici è quello di Farr e Zagorski [29]:

654321 1017333,286,2188ˆ xxxxxxS ++−+++−= (4.15)

La Tabella 4.2 riporta il significato e i possibili valori degli attributi del modello.In esso il valore negativo della costante (–188) è tale da far risultare stime ad-dirittura negative per i progetti di piccola e media dimensione. Inoltre il pesonegativo dell’attributo x4 (–17) contribuisce certamente a sottostimare i pro-getti cui partecipano programmatori con esperienza anche decennale.È evidente che queste sono le conseguenze naturali di un’analisi di regressione“alla cieca”! Comunque, per essere positivi, si può affermare che [17]:

“questi risultati sono ottimi esempi per dimostrare che il modello deveessere visto nella sua globalità, non è quindi sufficiente un’analisi indivi-duale su ciascun termine”.

Fino a oggi, i modelli lineari basati su dati statistici riferiti alla stima dei costi delSW, mediamente, non hanno dimostrato la loro piena efficienza. La spiegazio-ne più logica che si può fornire per questo fallimento è che lo sforzo risulta es-sere una funzione assolutamente non-lineare di un grande numero di variabili, edi conseguenza non può essere descritta adeguatamente da un modello lineare.

Tabella 4.1

Attributi Range/valori

x1 Povertà di requisiti 0 – 2

x2 Stabilità del progetto 0 – 3

x3 Percentuale di istruzioni matematiche percentuale

x4 Percentuale di istruzioni di I/O percentuale

x5 Numero di sottoprogrammi numero

x6 Linguaggio di programmazione 0 – 1

x7 Applicazione gestionale 0 – 1

x8 Applicazione stand-alone 0 – 1

x9 Primo programma nel computer 0 – 1

x10 Sviluppo concorrente di hardware 0 – 1

x11 Utilizzo di dispositivi ad accesso casuale 0 – 1

x12 Differenza tra hardware host e hardware target 0 – 1

x13 Numero di viaggi del personale numero

x14 Sviluppo per organizzazioni militari 0 – 1


Tabella 4.2

Attributi Unità/valorix1 Numero di istruzioni in migliaiax2 Numero di chilometri viaggiati in migliaiax3 Numero di tipi di documenti consegnati numerox4 Esperienza media dei programmatori annix5 Numero dei terminali numerox6 Percentuale di nuove istruzioni percentuale

Modelli statistici non lineariLa maggior parte dei modelli non lineari, basati su dati statistici elaborati, pos-sono essere espressi nella forma:

$ ( ) ( )S a b I m Xc= + ⋅ (4.16)

dove:I rappresenta la dimensione del progetto misurata in migliaia di linee di

codice sorgente,a, b, c sono costanti calcolate generalmente tramite l’analisi di regressione,m(X) è un fattore di aggiustamento che dipende da uno o più cost driver, rap-

presentati dal vettore X.

In alcuni casi a, b e c possono a loro volta dipendere dai cost driver.Dal momento che m(X) può essere anch’esso una complessa funzione non-line-are di diverse variabili, l’Equazione 4.16 non può essere sviluppata facilmente conle tecniche standard di regressione. È molto più semplice derivare un’equazionenominale di stima della forma:

S a b I cnom = + ⋅ (4.17)

e correggere successivamente lo sforzo nominale con il fattore m(X).Di seguito riportiamo alcune equazioni che rappresentano lo sforzo nominale, informa non lineare:

Snom = 5,2 I0,91 (Walston-Felix [81])Snom = 3,5 + 0,73 I1,16 (Bailey-Basili [5])Snom = 3,2 I1,05 (Boehm – modello base [9])Snom = 3,0 I1,12 (Boehm – modello intermedio [9])Snom = 2,8 I1,20 (Boehm – modello dettagliato [9])Snom = 5,288 I1,047 (per I ≥ 10) (Doty [27], [40])


Come si può osservare, il fattore principale che influisce sulla stima dello sforzoè assunto essere la dimensione del progetto (numero di istruzioni – I), tradizio-nalmente misurata in KSLOC (Kilo Source Lines Of Code). A causa della incom-patibilità delle convenzioni per il conteggio di KSLOC, è necessario prestaremolta attenzione al suo significato, ogni qualvolta si confrontano i modelli. Infattinel modello di Boehm [9] non vengono considerati i commenti; nel modelloWalston & Felix [81] essi invece sono considerati solo se costituiscono più del50% delle linee di codice; Bailey & Basili [5] definiscono “I” come la somma trail codice nuovo e il 20% del codice vecchio, commenti inclusi.

4.9.2 Modelli storico-empiriciLa maggior parte dei modelli di stima oggi operativamente presenti appartienealla categoria dei modelli sperimentali.Utilizzando tali modelli, che derivano generalmente dall’esperienza specifica diuno o più esperti, si corre il rischio di sopravvalutare i moduli complessi, parti-colarmente analizzati dall’“esperto”. Inoltre lo stesso “esperto” è portato a con-centrare poco sforzo nell’organizzazione locale (artigianale) del progetto. Con-seguentemente i modelli non sempre sono adeguati a progetti con obiettivi piùgeneralizzati.I modelli empirici, basati principalmente sulle analogie, offrono risultati apprez-zabili se applicati a livello globale del sistema o anche al livello del componentespecifico. Comunque possono costituire un buon test di prova alternativo almodello che viene adoperato normalmente.Tra i modelli che rientrano nella categoria storico-empirico, quello di Wol-verton [86] è probabilmente il più conosciuto. Esso deduce il costo di svilup-po del sistema da una matrice di costo software. Un esempio è riportato nellaTabella 4.3.

Tabella 4.3

Difficoltà OE OM OH NE NM NHTipo 1 2 3 4 5 6

1 Controllo 21 27 30 33 40 49

2 I/O 17 24 27 28 35 43

3 Pre/post processamento 16 23 26 28 34 42

4 Algoritmo 15 20 22 25 30 35

5 Gestione dati 24 31 35 37 46 57

6 Criticità delle prestazioni 75 75 75 75 75 75


Gli elementi della matrice della Tabella 4.3, che chiamiamo Cij, sono i costi delSW (in dollari) che dipendono dalla categoria della problematica (tipo i) e dallarelativa complessità (difficoltà j).I passi da seguire nell’utilizzo del modello Wolverton sono:

1) Identificare i moduli del sistema da stimare e assegnare a ciascuno di essiil “tipo” (categorie di funzionalità) che maggiormente rappresenta, sce-gliendo fra le seguenti sei classi:

1. Controllo2. Input/output3. Pre/post processamento4. Algoritmo5. Gestione dati6. Criticità delle prestazioni

2) Per ciascun modulo identificato con uno dei “tipi” sopracitati, definire lasua complessità o difficoltà su una scala a sei valori:

1. Vecchio e semplice OE (Old & Easy )2. Vecchio e medio OM (Old & Medium)3. Vecchio e difficile OH (Old & Hard)4. Nuovo e facile NE (New & Easy)5. Nuovo e medio NM (New & Medium)6. Nuovo e difficile NH (New & Hard)

3) Stimare la dimensione (linee di codice) di ciascun modulo e calcolare il co-sto utilizzando la Tabella 4.3;

C k I k Ci k j k( ) $( ) ( ), ( )= (4.18)

dove k è uno degli n moduli che compongono il sistema da stimare classi-

ficato con il tipo i(k) e con la complessità/difficoltà j(k), n e $( )I k è la sti-ma della sue dimensione in linee di codice;

4) Stimare il costo totale del sistema sommando il costo di ciascun modulo;

Costo del sistema = C kk

n

( )=∑

1(4.19)

Mentre questo approccio introduce effettivamente una misura “obiettiva” delcosto del SW, rimane un elevato grado di “soggettività” nell’intero processo.


Inoltre la matrice dei costi (Tabella 4.3), essendo in dollari, deve essere continua-mente aggiornata per riflettere i costi correnti. L’influenza di numerosi altri fat-tori sul costo non è adeguatamente presa in considerazione. L’esperienza e lacapacità del personale, l’uso di moderne pratiche e strumenti di programmazionenon sembrano influire sulle stime dei costi prodotte da questo modello. Per ov-viare a queste carenze si potrebbe aumentare la dimensione della matrice C in-cludendo contributi addizionali che influenzino il costo, ma ciò renderebbeproblematica la taratura degli elementi della matrice.

4.9.3 Modelli teoriciI modelli teorici di SCS si basano sulle ipotesi di come la mente umana operadurante il processo di sviluppo e/o sulle leggi matematiche che si presume ilprocesso di sviluppo del SW segua [17].Riportiamo di seguito i modelli più rappresentativi di questa categoria:

a) modello di Halstead (Software Science Effort Model);b) modello di Putnam (Resource Allocation Model);c) modello di Jensen.

Modello di Halstead (Software Science Effort Model)Il modello è costruito sulla metodologia che l’autore ha per primo introdotto nel1972 e che va sotto il nome di “scienza del software” (Software Science) [37] [38].L’ipotesi formulata è veramente affascinante:

“il numero di operatori (espressioni verbali) e operandi (nomi o espressionidi dati) contenuti in un programma sono correlati al numero di errori (bugs)”.

In base a questa ipotesi un qualsiasi programma è interamente formato da dueentità elementari:

• operatori: statement funzionali aritmetici (+/-), comandi di gestione deidati (lettura, scrittura, spostamenti) e simboli di punteggiatura associati chene delimitano la fine;

• operandi: costanti e variabili usati dal programma come dati.

Quattro metriche di base ne rappresentano le misure fondamentali di input:

1. il numero di operatori (verbi) unici usati (n1),

2. il numero di operandi (nomi) unici usati (n2),

3. il numero totale di occorrenze di operatori (N1),

4. il numero totale di occorrenze di operandi (N2).


Per fare un paragone con il linguaggio naturale, è come se le quattro metricheesprimessero il numero totale di nomi e verbi contenuti in un racconto e la lorofrequenza di utilizzo.Dalle quattro metriche di base la Software Science deriva una serie di misuresupplementari:

a) Vocabolario:

n = n1 + n2 (4.20)

approssima quella che è la definizione “classica” di un insieme di termini uniciusati da uno scrittore od oratore.

b) Lunghezza:

N = N1 + N2 (4.21)

anche qui la lunghezza richiama il significato “naturale” di dimensione di unracconto o discorso in termini di numero di parole utilizzate.

c) Volume:

V = N ⋅ log2(n) (4.22)

essenzialmente il volume di un programma vuole rappresentare il numero deicaratteri necessari alla sua codifica.Una volta definito l’input, la metodologia propone una lista di sei metriche dioutput che caratterizzano gli attributi di un programma, basandosi su quella cheHalstead definisce “metafisica intuitiva” [49]:

1) Livello di astrazione: l’inverso della difficoltà della fase di codifica,

Ln

nN

= ⋅21

22

(4.23)

2) Contenuto di intelligenza di un programma: misura indipendentedall’imple-mentazione delle funzionalità di un programma,

I = L ⋅ V (4.24)

3) Livello del linguaggio: misura relativa al linguaggio di implementazione in-dipendente dal programma,

l = L2 V (4.25)

4) Sforzo mentale: misura del numero di “discriminazioni mentali elementa-ri”, necessari per codificare il programma,


SVL

= (4.26)

5) Tempo di sviluppo: il tempo necessario per codificare il programma,

TS=β (4.27)

con β (Stround number) che può variare da 5 a 20

6) Errori (Bugs) consegnati in un programma: il numero di errori rimasti nelprogramma alla fine della fase del processo di sviluppo,

3000

VE = (4.28)

Il modello di stima che si può dedurre dalla metodologia descritta, si basa prin-cipalmente sulla stima a priori della dimensione del SW.Dalla combinazione delle metriche di output si può dedurre lo sforzo (S):

nNn

NnS 2log

2

2

2

1 ⋅= (4.29)

Ponendo il caso in cui il numero di operatori e di operandi sia uguale e che an-che le loro occorrenze siano identiche, abbiamo:

n1 = n2 = n2

(4.30)

ma anche:

N1 = N2 = N2

(4.31)

allora l’Equazione (4.29) con queste semplificazioni, diventa:

S N n= ⋅ ⋅14

22log (4.32)

Inoltre, poiché esiste una relazione lineare fra il numero totale di occorrenze dioperandi e di operatori (N) e il numero di istruzioni del programma (I) attraversouna costante (k) che varia solo a seconda di linguaggio [76]:

N = k ⋅ I (4.33)

L’equazione dello sforzo si può calcolare in funzione della dimensione del pro-getto attraverso un processo iterativo:


28,228,2

4

1IkS ⋅⋅= (4.34)

Due sono le pecche maggiori del metodo di Halstead. La prima, tipica degliapprocci teorici, è quella di mettere insieme le analisi di “correlazione” (esistenzadi una relazione), con le analisi di “regressione” (natura della relazione); il rischioè di arrivare a conclusioni non sempre esatte. La seconda, di tipo pratico, non èsempre facile stimare a priori la dimensione (numero di istruzioni oppure deioperatori + operandi).

Modello di Putnam (Resource Allocation Model)Il modello di Putnam [66] si basa sull’ipotesi che il processo di allocazione del-le persone (lo sforzo in mesi/persona), durante il ciclo produttivo del software se-gua un andamento ben preciso, noto come la curva di Rayleigh (Figura 4.1).L’equazione della curva di Rayleigh è riportata di seguito;

&y kate at= −2 2 (4.35)

dove:rappresenta il grado di utilizzo del personale,

t è il tempo intercorso dall’inizio del progetto,a è un parametro,k è l’area al disotto della curva, nell’intervallo [0, ∞].

Tempo

Persone

T

Figura 4.1


Integrando l’equazione precedente nell’intervallo [0, t] si ottiene:

( )2

1)( atekty −−= (4.36)

dove y(t) rappresenta lo sforzo impiegato dall’inizio del progetto fino al tempo t.Se si pone il parametro

a = 1

2 2T(4.37)

allora T è il punto in cui assume il valore massimo, quindi T corrisponde, ap-prossimativamente alla durata del processo di sviluppo del progetto.Sostituendo T, nell’Equazione (4.36), si ottiene una stima dello sforzo

S = y(T) = 0,3945 k (4.38)

Putnam stabilisce inoltre una metrica per misurare la difficoltà (D)

D = k

T 2 (4.39)

Dopo aver analizzato circa 50 progetti sviluppati in ambito militare, Putnamosservò che per i sistemi relativamente semplici, D tendeva a essere piccolo,mentre per i sistemi relativamente difficili da sviluppare D tendeva a essere gran-de. Queste osservazioni lo portarono a ipotizzare che ci fosse una relazione traD e la produttività,

P = c Db (4.40)

La produttività è per definizione il rapporto fra la dimensione del progetto,espresso in linee di Istruzioni I (DSI (Delivered Source Instruction), SLOC oppureKLOC), e lo sforzo S:

P = IS

(4.41)

Usando la tecnica di regressione non lineare, applicata ai progetti di cui sopra,Putnam ha ricavato la seguente equazione:

P = c D−2 3/ (4.42)

dove c è una costante.Sostituendo la (4.42) nella (4.41) si ottiene la Software Equation di Putnam;

I = P S = c D–2/3 0,3945 k = C ⋅k

Tk

2

2 3

⋅− /

(4.43)


cioè;

I = C ⋅ k1 3/ ⋅ T4 3/ (4.44)

Putnam attribuisce alla costante C il significato di fattore tecnologico che riflet-te gli effetti dell’influenza di numerosi fattori quali i vincoli hardware, la comples-sità del processo, l’esperienza del personale e l’ambiente di programmazione.Risolvendo l’Equazione (4.44) per k si ottiene:

k = I

C T TIC

3

3 4 4

31=

(4.45)

e, sostituendo infine k nell’Equazione (4.38), otteniamo l’equazione dellosforzo;

S = K IT

3

4 (4.46)

dove, ricapitolando:S rappresenta lo sforzo in mesi-persona,I rappresenta la dimensione (istruzioni) in migliaia di linee di codice,T rappresenta il tempo solare di sviluppo in mesi,K è la costante tecnologica.

Putnam, sulla base delle equazioni sopra descritte, ha anche sviluppato un pro-dotto software denominato SLIM (Software LIfe cycle Methodology) che si ponel’obiettivo di calcolare la stima dei costi del SW.La considerazione più importante da rilevare è che il modello di Putnam nonsegue affatto la famosa “legge di Brook” [13], e cioè che

“... poiché il processo di sviluppo del software è complesso, aggiungerepersonale allo staff oltre un certo numero fa aumentare, anziché diminu-ire, la durata del progetto”.

Tale legge asserisce che, quando i task sono partizionati tra varie persone, deveessere preso in considerazione lo sforzo necessario per il loro coordinamento.Questo sforzo aggiuntivo comprende le attività di addestramento necessarie perpermettere ai “nuovi” di entrare a far parte del gruppo già esistente, nonché iltempo necessario di “affiatamento” tra i membri del team.Nella Figura 4.2 sono riportate due curve che mostrano l’influenza della forzalavoro sulla durata del progetto [17].La curva inferiore corrisponde al caso in cui esista un perfetto partizionamentodei task che non richiedono alcuna interazione tra i membri dello staff.


La curva superiore corrisponde al caso in cui le interrelazioni tra i membri del-lo staff siano molto complesse.Qui di seguito elenchiamo altre critiche al modello di Putnam, rilevate nell’usopratico del modello:

• il modello sovrastima eccessivamente progetti SW di piccole e medie di-mensioni e comunque manifesta un comportamento che necessita ditaratura;

• le conseguenze di una modifica del tempo di sviluppo sul “costo” del pro-getto sono eccessive, lo sforzo (S) è inversamente proporzionale alla quartapotenza di T;

• le stime di S sono troppo sensibili alle variazioni del fattore di tecnologia(K); scegliere un valore piuttosto che un altro, anche vicino, può facilmenteportare a differenze sensibili (100%) nella stima;

• è necessaria una conoscenza teorica non indifferente del modello per usareadeguatamente l’approccio Putnam.

Modello di JensenNel panorama dei modelli di stima basati sulla teoria, quello più recente è ilmodello di Jensen [47]. Jensen ha elaborato un’equazione simile al modello

Durata

PersoneFigura 4.2


Putnam ma ha cercato principalmente di attenuare l’effetto di compressionepianificata dello sforzo. L’equazione della stima delle linee di istruzioni (4.44)proposta da Putnam viene così modificata da Jensen:

I =⋅ Cte k1 2/ ⋅ T (4.47)

in cui Cte è definita dall’autore “costante tecnologica effettiva” (EffectiveTecnological Constant), ottenibile dalla formula:

∏=

=15

1btte

iifCC (4.48)

dove Ctb è la costante di base (Basic Tecnology Constant) e fi è la misura dell’i-esi-mo fattore correttivo (Cost Driver).Anche in questo caso, come per il modello Putnam, si può ricavare l’equazionedi stima dello sforzo. Infatti, prima si calcola dall’Equazione (4.47) il valore di k;

k = I

C T

2

2 2te

(4.49)

k rappresenta, nel modello Jensen, lo sforzo del ciclo di vita. Si calcola quindi losforzo di sviluppo:

S = c IT

2

2 (4.50)

Anche nella (4.50) come nella (4.46) la costante c ingloba sia l’influenza dei fat-tori tecnologici che la modifica del fattore di scala.Per quanto riguarda le prestazioni offerte dal modello Jensen, sulla base di diversesperimentazioni possiamo dire che esso si comporta meglio del modello Putnam,anche se comunque i risultati non sono eccellenti [17].

4.9.4 Modelli compostiI modelli composti incorporano una combinazione di equazioni teoriche, diparametri statistici (di natura lineare e non) e di expert judgment (giudizio esper-to); quest’ultimo nella forma di parametri e intuizioni, trasformabili in regolericavate dall’esperienza “storica”.Un esempio di modello composto, presente anche commercialmente, è il modelloPRICE-S [33] che stima la dimensione del SW e propone un piano di sviluppodelle fasi del suo ciclo di vita. Esso necessita di una serie di informazioni inizialiche possono essere sintetizzate nelle seguenti voci:


• funzionalità: permette di stabilire la dimensione del programma;• produttività: riflette l’efficienza dell’organizzazione;• complessità: definisce la difficoltà del SW da sviluppare;• piattaforma: caratterizza i requisiti operazionali e di affidabilità;• applicabilità: evidenzia le difficoltà di coding.

In assoluto il modello più rappresentativo della categoria dei modelli compostiè COCOMO (COnstructive COst MOdel) di Barry Boehm [9], [10] che essen-do il più conosciuto e completo tra tutti i modelli SCS, verrà dettagliatamenteillustrato nel prossimo capitolo assieme ad altre metodologie consolidate.In generale la categoria che va sotto il nome di “modelli composti” comprendetutte quelle metodologie ibride che, non trovando soddisfacenti, singolarmente,i modelli esistenti, per esigenze organizzative specifiche incorporano le “migliori”caratteristiche di quelli più “adatti”.Anche il modello proprietario ESSE (Expert System for Software cost Estimation)[75], che verrà ampiamente descritto nel Capitolo 7 e che si avvale dellametodologia di sistemi esperti, rientra perfettamente in questa categoria. ESSEè stato sviluppato allo scopo di integrare le caratteristiche dei modelli e dellemetodologie che, sia dal punto di vista teorico che da quello operativo, hannofornito i migliori risultati, incorporando inoltre una serie di “regole del pollice”(rules of thumb) che permettono di affinare la stima del costo del software inambienti e organizzazioni specifiche.

55.1 Modello COCOMO di Barry Boehm, 85

5.2 Punti funzione di Allen Albrecht, 96

5.3 Modello ESTIMACS di Howard Rubin, 108

5.4 Feature Point di Capers Jones, 110

5.5 Nuove metodologie, 113

Metodologie e modelli consolidati

L’abilità nel definire strategie per predire costi, stimare le risorse necessarie perlo sviluppo di un progetto e stabilire tabelle di tempi ragionevoli per il rilascio diun software è fondamentale per determinarne il successo.Mentre nel passato (e purtroppo spesso ancora oggi!) ci si è affidati all’intuizio-ne e all’esperienza per soddisfare queste esigenze, le realtà economiche del pre-sente richiedono un approccio “ingegneristico” e meno soggettivo fondato cioèsu basi più solide.Nel rispetto di questa necessità, numerosi ricercatori hanno sviluppato modelliquantitativi per descrivere matematicamente la relazione tra le diverse dimensionie i parametri del software legato a un processo di sviluppo.

5.1 Modello COCOMO di Barry BoehmIl modello più conosciuto e consolidato di sistemi per la stima dei costi delsoftware è senza dubbio COCOMO (COnstructive COst MOdel). InoltreCOCOMO è in assoluto il modello più dettagliatamente illustrato e documen-tato sia nella sua componente matematica che in quella filosofico-empirica [9].La filosofia di base di COCOMO è quella di calcolare lo sforzo (S) di sviluppo(mesi/persona) in funzione del numero di istruzioni (I) consegnate del prodot-to software. Il calcolo dello sforzo può essere perfezionato attraverso un set diparametri correttivi chiamati cost driver. Inoltre il modello prevede anche il cal-colo di tempo solare coerente (schedule) necessario per coprire lo sforzo stima-to.La forma dell’equazione base del modello COCOMO per il calcolo dello sforzodi sviluppo è del tipo esponenziale;

S a I Cbi

i

= ⋅ ⋅∏ (5.1)

86 Metodologie e modelli consolidati

dove:S è lo sforzo necessario in mesi/persona;I rappresenta le migliaia di istruzioni del codice sorgente consegnabile (KDSI

– Kilo Delivered Source Instructions);a, b sono le costanti che variano in funzione del tipo del modello e in base alla

scelta della “modalità di sviluppo”;Ci è (Cost driver) i-esimo fattore correttivo.

Il modello, sulla base dello sforzo calcolato, fornisce anche una stima “ottimale”del tempo solare di realizzazione del progetto software;

(5.2)

dove:T è il tempo solare in mesi necessario per lo sviluppo;c, d sono le costanti che variano in funzione del tipo di modello e in base alla

scelta della “modalità di sviluppo”.

Per poter utilizzare il modello COCOMO in modo preciso è opportuno sottoli-neare i seguenti punti:

• KDSI include tutte le istruzioni sorgente consegnabili all’utente, escluden-do eventuali istruzioni create appositamente per fare testing, debugging oaltro di supporto allo sviluppo;

• KDSI esclude tutte le linee di commento mentre include le istruzioni re-lative al JCL (Job Control Language), alla definizione e alla struttura (for-mati) dei dati;

• lo sforzo e il tempo solare di sviluppo calcolati dal modello COCOMO copro-no il periodo intercorrente dall’inizio dell’analisi del progetto (fine definizionedei requisiti utente) fino alla fase di integrazione dei moduli e di test globale delsistema;

• i valori calcolati dal modello comprendono le attività di managementdel progetto e la stesura della documentazione, ma escludono i tempidi addestramento dell’utente e i tempi di installazione ed eventuale ma-nutenzione;

• la stima calcolata copre tutti i “costi diretti”, per esempio i costi dovuti aprogrammi di libreria necessari per lo sviluppo e a strumenti di supportoalla gestione del progetto. Sono esclusi invece i “costi indiretti”, per esem-pio i costi del centro di calcolo, della segreteria e del “top management”;

• il mese/persona del modello COCOMO corrisponde a 152 ore lavorativeper 12 mesi, togliendo circa 35 giorni all’anno per le ferie e le malattie del per-sonale;

Metodologie e modelli consolidati 87

• il modello COCOMO presume che i requisiti iniziali del software da sti-mare non vengano modificati sostanzialmente durante lo sviluppo.

5.1.1 Fattori correttivi (cost driver) di COCOMOÈ indubbio che nello stimare lo sforzo necessario per lo sviluppo di un proget-to software esista un numero considerevole di parametri che possono, in positi-vo o in negativo, influenzare il calcolo.I pionieri in questo campo specifico sono stati Nelson [63] e Weinwurm [84],avendo essi identificato un centinaio di fattori plausibili che, in un modo o in unaltro, influenzavano il costo dello sviluppo. Successivamente Walston e Felix [81]hanno aggiunto alla lista ulteriori fattori – questa volta più tecnici – dovuti ancheall’evoluzione degli strumenti di supporto allo sviluppo, nonché ai vincoli diqualità e di sicurezza.Con l’obiettivo di ridurre questo gran numero di parametri e creare dei fattori cheavessero la caratteristica di maggiore contenuto tecnico-gestionale e di facilità dimanipolazione e utilizzo pratico, Boehm li ha analizzati basandosi principalmentesu due concetti:

• i fattori devono avere un significato generalizzato. Ciò ha permesso di eli-minare tutti quei parametri che avevano un significato e quindi un peso insituazioni relativamente specifiche;

• i fattori devono essere il più possibile indipendenti. Questo assioma, invece,ha drasticamente ridotto i fattori che avevano forti correlazioni; essi sonostati inglobati in un unico fattore che ha potuto racchiudere in modo piùgeneralizzato l’influenza di più parametri.

Il modello originale di Boehm prevede quindi 15 fattori correttivi, riportati nel-la Tabella 5.1.COCOMO prevede l’utilizzo di tre tipi di modelli a seconda del livello di detta-glio di informazioni che si ha a disposizione e quindi di dettagliata debba esserela stima del progetto in esame:

1. Modello base (Basic COCOMO Model)2. Modello intermedio (Intermediate COCOMO Model)3. Modello dettagliato (Detailed COCOMO Model)

Inoltre COCOMO diversifica i coefficienti delle equazioni per ciascun tipo dimodello a seconda della “modalità di sviluppo” (COCOMO Mode). Tale moda-lità viene identificata principalmente attraverso i seguenti parametri:


• la dimensione del progetto;• l’organizzazione operativa del gruppo di lavoro;• la tipologia dell’esperienza del gruppo di lavoro.

Tabella 5.1

1 RELY: required software RELiabilitY Affidabilità richiesta

2 DATA: DATA base size Dimensione dell’archivioorganizzato

3 CPLX: product ComPLXity Complessità del prodotto

4 TIME: execution TIME constraint Vincoli nel tempo di esecuzione

5 STOR: main STORage Vincoli della memoria centrale

6 VIRT: VIRTual machine volatility Instabilità della macchinavirtuale

7 TURN: computer TURNaround time Tempo medio complessivodi risposta della macchina

8 ACAP: Analyst CAPability Capacità degli analisti

9 AEXP: Application EXPerience Esperienza del gruppodi lavoro sull’applicazione

10 PCAP: Programmer CAPability Capacità dei programmatori

11 VEXP: Virtual machine EXPerience Esperienza del gruppo dilavoro sulla macchina virtuale

12 LEXP: programming Language Esperienza sul linguaggioEXPerience di programmazione

13 MODP: MODern Programming Utilizzo di tecniche modernepractices di programmazione

14 TOOL: use of software TOOLs Utilizzo di strumenti softwaredi supporto nello sviluppo)

15 SCED: required development Vincoli di tempificazione nelloSChEDule sviluppo

Le tre modalità di sviluppo sono:

a) modalità poco strutturata (Organic Mode);Questa modalità viene applicata a progetti aventi le seguenti caratteristiche:

• progetti di piccola-media dimensione;• piccolo gruppo di lavoro;


• sviluppo delle fasi prevalentemente sequenziale;• approccio artigianale;• ambiente tecnico-operativo molto stabile;• esperienza del personale di sviluppo specifica e di livello medio-alto.

b) modalità mediamente strutturata (Semidetached Mode);Questa modalità viene applicata a progetti aventi le seguenti caratteristiche:

• progetti di media dimensione;• gruppo di lavoro medio;• sviluppo delle fasi mediamente sequenziale;• approccio mediamente industriale;• ambiente tecnico-operativo mediamente stabile;• esperienza del personale di sviluppo generica e di livello medio.

c) modalità fortemente strutturata (Embedded Mode);Questa modalità viene applicata a progetti con le seguenti caratteristiche;

• progetti di media-grande dimensione;• grande gruppo di lavoro;• sviluppo delle fasi prevalentemente in parallelo;• approccio prevalentemente industriale;• ambiente tecnico-operativo evolutivo e complesso;• esperienza del personale diversificata e di livello medio.

Per quanto riguarda i fattori correttivi, Boehm ha definito una griglia (range) di4-5 livelli e quindi, sulla base delle statistiche a disposizione, ha assegnato unvalore “zero” per il modello base, “diverso da zero ma costante per tutte le fasidi sviluppo” qualora si usi il modello intermedio, “diverso da zero e variabile” peril modello dettagliato.

5.1.2 Modello COCOMO baseIl modello base, che non tiene direttamente conto dei parametri correttivi (costdriver), può essere molto utile per una primissima stima qualora fossero pocochiare le caratteristiche delle risorse umane, ambientali, operative e tecniche delprogetto in esame.In effetti, il modello base tiene conto di tutte le caratteristiche funzionali e am-bientali del progetto, concentrando i fattori correttivi nei coefficienti moltiplica-tivi ed esponenziali, con effetti “mediati” in conformità con la “modalità” disviluppo prescelta.


Di seguito vengono riportate le tre equazioni del modello base per il calcolo dellosforzo e le relative equazioni per il calcolo del tempo solare necessario per coprireal meglio lo sforzo, specificato a seconda della modalità di sviluppo:

a) modalità dello sviluppo poco strutturato;

S = 2,4* (I)1,05 (5.3)

T = 2,5* (S)0,38 (5.4)

b) modalità dello sviluppo mediamente strutturato;

S = 3,0* (I)1,12 (5.5)

T = 2,5* (S)0,35 (5.6)

c) modalità dello sviluppo fortemente strutturato;

S = 3,6* (I)1,20 (5.7)

T = 2,5* (S)0,32 (5.8)

5.1.3 Modello COCOMO intermedioIl modello intermedio di COCOMO è sicuramente quello più utilizzato poichétiene conto di tutti i fattori correttivi senza che si debba necessariamente avereinformazioni di dettaglio su come questi pesino nelle varie fasi di sviluppo delsoftware da stimare.Come per il modello base, vengono riportate qui di seguito le tre equazioni delmodello intermedio del COCOMO, per il calcolo dello sforzo, nonché le relati-ve equazioni per il calcolo del tempo solare necessario per coprire al meglio losforzo specificato a seconda della modalità di sviluppo:


S = 3,2* (I)1,05 Ci

i =∏

1

15

(5.9)

T = 2,5* (S)0,38 (5.10)


S = 3,0* (I)1,12 Ci

i=∏

1

15

(5.11)


T = 2,5* (S)0,35 (5.12)


S = 2,8* (I)1,20 Ci

i=∏

1

15

(5.13)

T = 2,5* (S)0,32 (5.14)

dove, come è stato accennato in precedenza, i valori dei 15 fattori correttivi Cisono diversi da zero ma costanti per tutte le fasi di sviluppo.La Tabella 5.2 contiene, per ciascun fattore correttivo, il peso dell’influenzache il parametro può avere nello sviluppo del sistema in esame. Come si puònotare, il range dei valori non è sempre lo stesso. Ciò è dovuto all’analisi sta-tistica effettuata da Boehm. La mancanza di qualche peso per alcuni parame-tri nei valori inferiori (molto basso, basso) e in quelli superiori (molto alto,altissimo) alla media (nominale), indica che ai relativi parametri dovrannoessere assegnati i valori appena successivi e/o appena precedenti al peso diinfluenza stimato.

Tabella 5.2

Cost driver Molto basso Basso Nominale Alto Molto alto AltissimoRely 0,75 0,88 1,00 1,15 1,40

Data 0,94 1,00 1,06 1,16

Cplx 0,70 0,85 1,00 1,15 1,30 1,65

Time 1,00 1,11 1,30 1,66

Stor 1,00 1,06 1,21 1,56

Virt 0,87 1,00 1,15 1,30

Turn 0,87 1,00 1,07 1,15

Acap 1,46 1,19 1,00 0,86 0,71

Aexp 1,29 1,13 1,00 0,91 0,82

Pcap 1,42 1,17 1,00 0,86 0,70

Vexp 1,21 1,10 1,00 0,90

Lexp 1,14 1,07 1,00 0,95

Modp 1,24 1,10 1,00 0,91 0,82

Tool 1,24 1,10 1,00 0,91 0,83

Sced 1,23 1,08 1,00 1,04 1,10


5.1.4 Modello COCOMO dettagliatoIl modello dettagliato di COCOMO si diversifica da quello intermedio peril fatto che, fornendo una tabella di coefficienti per i fattori di correzione (costdriver) diversificati per le varie fasi di sviluppo (analisi, disegno, coding eintegrazione e test), permette di calcolare una stima a livello di ciascunafase.Il modello dettagliato, inoltre, può essere particolarmente utile per la stimadi grossi sistemi in cui il progetto necessita di una strutturazione in più com-ponenti. Esso fornisce infatti i valori dei pesi d’influenza dei cost driver distin-guendo i coefficienti in base al livello gerarchico del componente software dasviluppare:

• livello sistema/sottosistema;• livello modulo.

Mentre a livello sistema/sottosistema per tutti i 15 fattori correttivi vengonodeterminati i pesi specifici per ciascuna fase di sviluppo, a livello modulo ciò vienedistinto solo per quattro cost driver (CPLX, PCAP, VEXP, LEXP). Questo per-ché Boehm ha ritenuto poco significativo valorizzare tali pesi per i restanti undicifattori a livello modulo.Di seguito vengono riportate le tre equazioni del modello dettagliato delCOCOMO che, tranne per quanto riguarda il valore dei coefficienti dei costdriver, coincidono esattamente con quelli del modello intermedio:


S = 3,2* (I)1,05 Ci

i =∏

1

15

(5.15)

T = 2,5* (S)0,38 (5.16)


S = 3,0* (I)1,12 Ci

i =∏

1

15

(5.17)

T = 2,5* (S)0,35 (5.18)



S = 2,8* (I)1,20 Ci

i =∏

1

15

(5.19)

T = 2,5* (S)0,32 (5.20)

La Tabella 5.3 riporta, per ciascuna fase di sviluppo, i pesi di influenza dei costdriver assegnabili al livello componente modulo del software [9].Le Tabelle 5.4a e 5.4b riportano, per ciascuna fase, i pesi di influenza dei cost driverassegnabili a livello componente sottosistema oppure direttamente sistema [9].

Tabella 5.3

Cost driver Peso Fase Fase Fase Fase integr.fattore analisi di segno coding e test

CPLX molto basso 0,70 0,70 0,70 0,70

basso 0,85 0,85 0,85 0,85

nominale 1,00 1,00 1,00 1,00

alto 1,15 1,15 1,15 1,15

molto alto 1,30 1,30 1,30 1,30

altissimo 1,65 1,65 1,65 1,65

PCAP molto basso 1,00 1,50 1,50 1,50

basso 1,00 1,20 1,20 1,20

nominale 1,00 1,00 1,00 1,00

alto 1,00 0,83 0,83 0,83

molto alto 1,00 0,65 0,65 0,65

VEXP molto basso 1,10 1,10 1,30 1,30

basso 1,05 1,05 1,15 1,15

nominale 1,00 1,00 1,00 1,00

alto 0,90 0,90 0,90 0,90

LEXP molto basso 1,02 1,10 1,20 1,20

basso 1,00 1,05 1,10 1,10

nominale 1,00 1,00 1,00 1,00

alto 1,00 0,98 0,92 0,92


Tabella 5.4a

Peso Fase Fase Fase Fase integr.fattore analisi di segno coding e test

RELY molto basso 0,80 0,80 0,80 0,80basso 0,90 0,90 0,90 0,80

nominale 1,00 1,00 1,00 1,00alto 1,10 1,10 1,10 1,30

molto alto 1,30 1,30 1,30 1,70DATA basso 0,95 0,95 0,95 0,90

nominale 1,00 1,00 1,00 1,00alto 1,10 1,05 1,05 1,15

molto alto 1,20 1,10 1,10 1,30TIME nominale 1,00 1,00 1,00 1,00

alto 1,10 1,10 1,10 1,15molto alto 1,30 1,25 1,25 1,40altissimo 1,65 1,55 1,55 1,95

Tabella 5.4b


STOR nominale 1,00 1,00 1,00 1,00alto 1,05 1,05 1,05 1,10

molto alto 1,20 1,15 1,15 1,35altissimo 1,55 1,45 1,45 1,85

VIRT basso 0,95 0,90 0,85 0,80nominale 1,00 1,00 1,00 1,00

alto 1,10 1,12 1,15 1,20molto alto 1,20 1,25 1,30 1,40

TURN basso 0,98 0,95 0,70 0,90nominale 1,00 1,00 1,00 1,00

alto 1,00 1,00 1,10 1,15molto alto 1,02 1,05 1,20 1,30

ACAP molto basso 1,80 1,35 1,35 1,50basso 1,35 1,15 1,15 1,20

nominale 1,00 1,00 1,00 1,00alto 0,75 0,90 0,90 0,85

molto alto 0,55 0,75 0,75 0,70


Tabella 5.4b Segue


AEXP molto basso 1,40 1,30 1,25 1,25

basso 1,20 1,15 1,10 1,10

nominale 1,00 1,00 1,00 1,00

alto 0,87 0,90 0,92 0,92

molto alto 0,75 0,80 0,85 0,85

MODP molto basso 1,05 1,10 1,25 1,50

basso 1,00 1,05 1,10 1,20

nominale 1,00 1,00 1,00 1,00

alto 1,00 0,95 0,90 0,83

molto alto 1,00 0,90 0,80 0,65

TOOL molto basso 1,02 1,05 1,35 1,45

basso 1,00 1,02 1,15 1,20

nominale 1,00 1,00 1,00 1,00

alto 0,98 0,95 0,90 0,85

molto alto 0,95 0,90 0,80 0,70

SCED molto basso 1,10 1,25 1,25 1,25

basso 1,00 1,15 1,15 1,10

nominale 1,00 1,00 1,00 1,00

alto 1,10 1,10 1,00 1,00

molto alto 1,15 1,15 1,05 1,05

Per poter definire i valori riportati nelle tabelle precedenti, Boehm si è basatoprincipalmente sull’esame dei 63 progetti inizialmente da lui analizzati [9]. Lasintesi di tale analisi è riportata nella Tabella 5.5 e rappresenta la distribuzio-ne in percentuale di ciascuna fase di sviluppo (analisi, disegno, coding, inte-grazione e test), classificata per modalità di sviluppo (poco strutturata,mediamente strutturata, fortemente strutturata), e suddivisa per categorie diprogetto dal punto di vista dimensionale (piccola, intermedia, media, gran-de, molto grande).Si può chiudere questo “escursus” sul modello COCOMO ricapitolando ipassi che devono essere compiuti per poter ottenere una stima dello sforzo inmesi/persona e una stima del tempo solare, in mesi, necessari per effettuarelo sforzo:


Tabella 5.5

Modalità Fase di Piccola Intermedia Dimensione Grande Moltodi sviluppo sviluppo media grande

2 KLOC 8 KLOC 32 KLOC 128 KLOC 512 KLOCAnalisi 16 16 16 16

Poco Disegno 26 25 24 23

strutturata Coding 42 40 38 36

Int. e test 16 19 22 25

Analisi 17 17 17 17 17

Mediamente Disegno 27 26 25 24 23

strutturata Coding 37 35 33 31 29

Int. e test 19 22 25 28 31

Analisi 18 18 18 18 18

Fortemente Disegno 28 27 26 25 24

strutturata Coding 32 30 28 26 24

Int. e test 22 25 28 31 34

1. Stimare sulla base di indicazioni teoriche e/o empiriche e/o statistiche, ladimensione del progetto in KDSI (Kilo Delivered Source Instructions);

2. Scegliere la “modalità” con la quale si pensa di sviluppare il progetto (pocostrutturata, mediamente strutturata, fortemente strutturata);

3. Scegliere il modello di stima più adeguato (base, intermedio, dettagliato),sulla base delle conoscenze che si hanno del progetto;

4. Calcolare lo sforzo, in mesi/persona, necessario per lo sviluppo del progetto,utilizzando l’equazione appropriata sulla base delle scelte fatte nei punti 2 e 3;

5. Elaborare la durata ,in mesi, del processo di sviluppo, utilizzando la rela-tiva equazione e lo sforzo calcolato al punto 4.

5.2 Punti funzione di Allen AlbrechtAllan J. Albrecht ha introdotto per la prima volta il concetto di Function Points– Punti Funzione (PF) – nel 1975 [1] per misurare la dimensione del SW in ter-mini di quantità di funzioni consegnabili all’utente.Punto funzione è una metrica sintetica che comprende l’influenza di cinque en-tità funzionali:


1. File logici interni

2. File di interfaccia

3. Input esterni

4. Inquiry esterne

5. Output esterni

Una volta calcolato il valore totale dei PF dell’applicazione da stimare, la metri-ca può essere utilizzata per diversi obiettivi economici:

a) Stima della produzione del software:• punti funzione per mese/ persona;• ore lavorative per punto funzione;• costo di sviluppo per punto funzione;• costo di manutenzione per punto funzione.

b) Valutazione dei consuntivi:• costo/prezzo di ogni punto funzione per azienda;• analisi costo-benefici del progetto;• supporto decisionale per sviluppo interno o esterno.

c) Valutazione della qualità:• numero di test necessari per punto funzione;• numero di difetti/errori per punto funzione.

Dopo essere stati utilizzati internamente all’IBM per diversi anni, i PF sono sta-ti discussi pubblicamente per la prima volta nell’ottobre 1979, in una conferen-za GUIDE/IBM a Monterey in California.Già allora i maggiori esperti nella valutazione della produttività del softwareconcordavano sul fatto che tecnicamente non era possibile misurare il livello dellaproduzione del SW scritto in linguaggi diversi attraverso il numero di istruzio-ni. Inoltre erano ben note tutte le problematiche relative alla misurazione delnumero di istruzioni. Albrecht ha cercato quindi di scavalcare questi problemie soluzioni tradizionali sviluppando una tecnica in grado di utilizzare la vera“economia” della produzione del software.Finalmente, nel 1981, l’articolo di Albrecht presentato alla conferenza GUIDE,venne pubblicato su IEEE [4] e la tecnica dei PF ebbe così una risonanza moltopiù ampia.I PF possono essere calcolati dalle specifiche, dal design, dal listato del sorgen-te o anche osservando l’esecuzione di un programma. L’approccio di Albrechtè stato quello di:


“....elencare e contare il numero di input, output e inquiry esterne, oltreche i file logici e di interfaccia”, in quanto questi fattori rappresentano “lamanifestazione esterna di ogni applicazione, cioè ne coprono ogni funzio-nalità”.

Lo scopo primario di questa tecnica è quello di aiutare il manager a eseguire ri-levamenti di produttività (PF/mesi-persona), ed è stata studiata per rispettare trerequisiti fondamentali [3]:

1. I PF devono essere indipendenti dalla tecnologia: la misura dà lo stesso nu-mero di funzioni applicative equivalenti basandosi sui documenti di designe indipendentemente dai linguaggi di programmazione o dalle particolaritecnologie e strumenti di sviluppo utilizzati per realizzare il SW.

2. I PF devono misurare tutte le funzioni consegnate all’utente: la misura dàlo stesso numero di funzioni applicative equivalenti anche nel caso incui nello sviluppo del SW che sia stato fatto uso di tecniche di rispar-mio dello sforzo.

3. I PF devono misurare solo le funzioni consegnate all’utente: la misura dà lostesso numero di funzioni applicative equivalenti senza prendere in con-siderazione ostacoli alla produttività, quali ambienti di sviluppo inadeguati,programmatori inesperti, scarse interazioni utente/progettista.

La misura dei PF per una specifica applicazione, può quindi essere vista come ilcalcolo della dimensione per la sua realizzazione. Una volta calcolato l’impegno(a consuntivo) dello sforzo (mesi/persona) per lo sviluppo di un software, è pos-sibile valutare la produttività , nei termini di PF realizzati per unità di tempo(mesi). Infatti i valori di produttività misurati per applicazioni “simili” possonoessere analizzati e confrontati onde determinare quali linguaggi, tecnologie etecniche di sviluppo abbiano avuto il miglior impatto sulla produttività. Natural-mente questo uso dei PF assume significato solamente qualora esista una qual-che relazione tra PF e ore di lavoro. Numerosi studi supportano questaassunzione ([16], [24], [69], [74]).L’utilizzo “a posteriori” dei PF sembra essere il punto di partenza principaledell’applicazione di questa metodologia nel project management. Una volta sta-bilita la relazione tra PF (l’output) e le ore (o i giorni oppure i mesi) – lavorative(l’input) per una certa organizzazione, si procede alla stima della dimensione delprogetto, esprimendola in PF, e quindi all’uso della relazione predeterminata peravere una valutazione anticipata dello sforzo produttivo. Tutto questo è resopossibile dal fatto che i PF possono essere facilmente calcolati a partire dalle


specifiche logiche, funzionali o architetturali disponibili già nelle fasi alte del ciclodi vita del SW.

5.2.1 La metodologiaI passi da seguire per arrivare al calcolo dei PF sono essenzialmente due:

1. calcolare i punti funzione non aggiustati – UFP (Unadjusted FunctionPoints);

2. calcolare i punti funzione finali - FP (Function Points)

Calcolo degli UFPIl calcolo degli UFP consiste nella classificazione e conteggio delle cinque cate-gorie di funzioni utente (user function-types) potenzialmente consegnabili dalprogetto di sviluppo. Queste sono [4]:

1) File logici interniUn file logico interno è un gruppo logicamente correlato di dati o di infor-mazioni di controllo, identificabili dall’utente, generati, mantenuti e utiliz-zati all’interno dell’applicazione.Con “gruppo logicamente correlato di dati identificabili dall’utente” si fariferimento a quei dati che soddisfano un requisito specifico dell’applica-zione. Il livello di analisi dei dati equivalente a questo livello logico di astra-zione è paragonabile al raggruppamento di dati univocamente identificabilidall’utente in un diagramma data-flow dell’applicazione.Con il termine “informazione di controllo” ci si riferisce ai dati usati nel-l’applicazione per assicurare che questa risponda ai requisiti delle businessfunction specificate dall’utente.

EsempiI seguenti dati possono costituire uno o più file logici interni, secondo il puntodi vista dell’utente:

• dati specifici dell’applicazione: archivio del personale, archivio deifornitori , eccetera;

• dati relativi alla sicurezza dell’applicazione: tabelle di abilitazioni;• file di messaggi di errore: tabella di corrispondenza di codici d’errore

e le relative descrizioni;• file di help.


2) File di interfacciaUn file di interfaccia è un gruppo logicamente correlato di dati o di infor-mazioni di controllo identificabile dall’utente, utilizzato all’interno dell’ap-plicazione, ma creato e mantenuto da altre applicazioni.

EsempiI seguenti dati possono costituire uno o più file di interfaccia, secondo il puntodi vista dell’utente:

• archivi di dati di riferimento: archivio comune, archivio statistiche, ec-cetera (gestiti da applicazioni esterne);

• tabella dei messaggi di errore (gestita da un’applicazione esterna).

3) Input esterniUn input esterno processa dati e/o informazioni di controllo che fanno par-te dell’applicazione e causa aggiunte, modifiche o cancellazione dei dati neifile logici interni. Un input viene considerato unico se ha un unico “forma-to” o una “logica di processamento” differente da input con lo stesso for-mato.Per “formato” si intende un unico elemento dato o un suo unico ordina-mento o arrangiamento.Con “logica di processamento” ci si riferisce a un’unica operazione di edit,calcolo e/o ordinamento, richiesta espressamente dall’utente.

EsempiLe seguenti operazioni sono considerate come funzionalità di input esterni:

• dati transazionali che aggiornano (inseriscono, modificano, cancellano) idati dei file logici interni;

• schermate di input e/o di help;• input dell’utente per il controllo dell’applicazione;• eventuali input batch.

4) Inquiry esterneUna Inquiry esterna è un’unica combinazione di input/output dove uninput provoca un output immediato e non si verifica alcuna modifica neifile logici interni.Una Inquiry si considera unica se ha un “formato” unico (nella sua partedi input/output) rispetto alle altre Inquiry, oppure se il disegno logico diprocessamento richiede un criterio diverso dalle altre Inquiry.


EsempiLe seguenti operazioni sono considerate come Inquiry esterne:

• schermate con interrogazione esplicita;• schermate di interrogazione del file help, messaggi di errore, codici vari,

eccetera.

5) Output esterniUn output esterno processa dati o informazioni di controllo che esconodall’applicazione. Un output viene considerato unico se ha un unico for-mato o una logica di processamento differente da un output con lo stessoformato.

EsempiLe seguenti operazioni sono conteggiate come output esterni:

• schermate di output (uscita a video di dati);• report prodotto;• dati di transazione verso altre applicazioni;• messaggi di errore.

I conteggi per ogni singolo user function type, sono classificati in accordo con lacomplessità “percepita” (semplice, media, complessa) e quindi pesati con fatto-ri finalizzati a “riflettere il valore funzionale per l’utente”. Per esempio un inputesterno “semplice” pesa la metà di un input giudicato “complesso”. I pesi sonostati determinati da Albrecht attraverso una serie di dibattiti con gli esperti “bydebate and trial”. I valori pesati vanno quindi sommati per fornire ciò cheAlbrecht chiama UFP (Unadjusted Function Points).La Tabella 5.6 riporta, per ciascuna entità funzionale, i pesi relativi in base algrado di complessità [58] che dovranno essere moltiplicati (×) per il numero diuser function type identificati nell’applicazione. La somma del totale di ogni rigarappresenterà l’UFP del sistema.

Calcolo dei PF finaliIl calcolo dei punti funzione finali consiste nel correggere gli UFP allo scopo ditenere conto delle peculiarietà dell’applicazione e dell’ambiente operativo. Lacorrezione viene effettuata attraverso la valorizzazione delle “CaratteristicheGenerali del Sistema” (CGS), in due passi:


Tabella 5.6

Function-type Semplice Media Complessa TotaleFile logici interni × 7 × 10 × 15 ∑∑∑∑∑File di interfaccia × 5 × 7 × 10 ∑∑∑∑∑Input esterni × 3 × 4 × 6 ∑∑∑∑∑Inquiry esterni × 3 × 4 × 6 ∑∑∑∑∑Output esterni × 4 × 5 × 7 ∑∑∑∑∑

Unadjusted Function Points (UFP) ∑∑∑∑∑

a) Stimare il grado di influenza delle 14 CGS che sono:

1. Comunicazione dati (Data communication)2. Elaborazione dati, distribuita (Distribution data process)3. Prestazioni (Performance)4. Carico sul sistema HW target (Heavily used configuration)5. Volume di transazioni (Transaction rate)6. Immissione dati on-line (On-line data entry)7. Facilità d’uso dell’applicazione (End-user efficiency)8. Facilità di modifiche on-line (On-line update)9. Complessità di elaborazione (Complex processing)10. Riusabilità (Reusability)11. Semplicità di installazione (Installation ease)12. Semplicità di gestione operativa (Operational ease)13. Installazioni plurime (Multiple sites)14. Semplicità di modifica (Facilitate change)

Il grado di influenza per ognuno di questi fattori è rappresentato da un nu-mero intero compreso nell’intervallo da 0 a 5.

0 Non presente o non influente1 Influenza lieve2 Influenza moderata3 Influenza media4 Influenza significativa5 Influenza forte

b) I valori assegnati per i 14 gradi di influenza vengono sommati e il loro to-tale (N) viene usato per ottenere il Valore del Fattore di Correzione (VFC).


VFC = (0,01*N) + 0,65 (5.21)

Il valore finale dei punti funzione (PF) si ottiene da:

PF = UFP * VFC (5.22)

Questo equivale a effettuare correzioni del ±35% sul valore iniziale (UFP) del-le funzionalità.Benché i PF costituiscano un approccio ormai consolidato per la stima della di-mensione del software, sono stati oggetto di alcune critiche. Una critica genera-le alla metodologia riguarda il fatto che essa affronta il dimensionamento deiprogetti attraverso una visione di tipo scatola nera (black box). Infatti, poichéconsidera principalmente le funzionalità di input e di output offerte all’utente,essa tende a ignorare altri aspetti del sistema in esame (per esempio la comples-sità interna di elaborazione).Un’altra critica [78] riguarda l’eccessiva semplificazione dei function type suddi-visi solo in tre livelli di complessità (bassa, media e alta).Inoltre, per quanto riguarda la dipendenza dalla tecnologia, è emerso da recen-ti studi [80] che i function type non sono adeguati a molti degli attuali sistemiinterattivi. Sono molto più efficaci altri tipi di funzionalità, quali “entità”, “rela-zioni”, “schermate”, “menu”, eccetera. Questo è giustificato dal fatto che le mo-derne tecnologie di sviluppo, quali i linguaggi della quarta generazione e glistrumenti CASE (Computer Aided Software Engineering), si muovono verso laspecifica di sistemi piuttosto che sulla codifica dettagliata.Infine, da uno studio effettuato da Kitchenham (usando un database di 40 pro-getti gestionali di 9 organizzazioni diverse) [54] sono emersi alcuni problemi ri-guardanti la consistenza interna dei PF:

• i cinque function type di Albrecht non sono così indipendenti;• non tutti i function type sono correlati con lo sforzo.

Tali risultati indicherebbero che i PF non hanno le caratteristiche di una metri-ca valida. A nostro parere, i risultati dello studio di Kitchenham possono essereinvece considerati un vantaggio, poiché significa che in qualche occasione sonosufficienti meno informazioni per la stima della dimensione.Una personale considerazione, che verrà approfondita nel Capitolo 7, riguar-do l’utilizzo isolato dei PF per la stima dello sforzo è la seguente:

“applicare, tout cours, la produttività aziendale espressa in PF/mesi perso-na, alla dimensione di un SW calcolato a sua volta in PF con l’obiettivo distimare lo Sforzo necessario per lo sviluppo, può indurre a risultati deviantie comunque non affidabili”.


5.2.2 Punti funzione e linee di codicePartendo dalla realtà applicativa attuale si può affermare che la maggioran-za dei modelli proposti per assistere i manager nella stima dello sforzo neces-sario per lo sviluppo di applicazioni SW ([9], [46], [65], [81]) abbia comeinput principale la dimensione prevista delle linee di codice (istruzioni),espressa in KSLOC, KLOC o KDSI. Ciò è dovuto, come abbiamo già avutooccasione di affermare, al fatto che i modelli sono stati sviluppati principal-mente in base a osservazioni eseguite su sistemi già funzionanti. Il problemaè che, per effettuare una stima delle Istruzioni, l’analista deve basarsi sullapropria esperienza relativa a progetti dalle caratteristiche simili, senza fareriferimento a tecniche particolari, ma questo metodo non sembra dare risultatisoddisfacenti.Per ovviare a queste insoddisfazioni, di seguito riportiamo due conclusioni trat-te dalla letteratura che sono state ampiamente confermate dall’esperienza:

1) I PF forniscono misure a priori più consistenti se paragonate a quelleottenibili mediante le metodologie basate sulle istruzioni.Da studi effettuati su dati empirici è emerso che, nella valutazione preco-ce delle dimensioni del SW(durante le fasi di analisi dei requisiti e di ste-sura delle specifiche), le stime espresse in Istruzioni subiscono variazioniin media superiori a quelle espresse in PF (75% contro 38%, circa) [46].Ciò viene attribuito al fatto che:

• i PF vengono calcolati usando un insieme formalizzato di procedure;• dal momento in cui i PF misurano le funzionalità consegnate all’utente,

essi sono particolarmente adatti a essere valutati anche nelle prime fasidello sviluppo.

2) Esiste una forte correlazione tra le linee di codice e i PF associati a un si-stema SW.Lo stesso Albrecht ha eseguito alcune misurazioni per verificare la validi-tà di una serie di formule predatrici di Istruzioni e basate su input FP-like.I risultati sono veramente incoraggianti: le correlazioni sono tutte superiorial 93%, con un errore relativo medio quasi sempre intorno al 5% [4].

5.2.3 PF e il livello di un linguaggio di programmazioneBasandosi sull’utilizzo quasi decennale dei PF e sul fatto che migliaia di applica-zioni sono state misurate con essi, è stato possibile notare che i linguaggi hannoun’influenza, a posteriori della stima di PF, non indifferente. Tale influenza haportato a classificare i linguaggi in “livelli” variabili ma caratteristici.


La parola livello va collegata con il “numero medio di statement necessari perrealizzare un punto funzione”. Il tutto si basa sulle prime analisi di Behrens [7]il quale ha notato che in media sono necessari 65 statement sorgenti in PL/I e 100in COBOL per codificare un punto funzione di Albrecht. Seguendo questa stradaè possibile arrivare alla definizione di una sorta di tavola periodica dei linguag-gi come quella mostrata nella Tabella 5.7 [49].È doveroso precisare che questa tabella è indicativa, cioè tende a dare percentualiapprossimative del numero di Istruzioni per PF (in termini di linee logiche diistruzioni eseguibili e definizioni di dati, escludendo commenti e Job ControlLanguage).Il margine di errore può essere alto in quanto la base statistica sulla quale lavo-rano i ricercatori non è ancora consolidata. Il grado di incertezza è tuttora oggettodi studio: per alcuni linguaggi, come il PL/I, gli studiosi hanno osservato unadispersione del 10% intorno ai valori medi, mentre per il COBOL si arriva an-che al 50%.I motivi di queste variazioni sono ancora ignoti, ma non bisogna dimenticare cheoggi nel mondo dell’EDP si usano circa 500 linguaggi principali (senza contarevarianti locali e versioni aggiornate), mentre la tabella completa ne contemplasolo 55. Quindi molte sono le lacune e certamente molti sono anche gli errori fattinella determinazione dei livelli. Tuttavia il principio metodologico usato è “sano”e attende solo la disponibilità di una base di campionatura più ampia (almeno 10progetti per ciascun linguaggio).Non si deve dimenticare che il “livello” non è l’unico elemento da prendere inconsiderazione nella scelta di un linguaggio. Se così fosse la scelta sarebbe estre-mamente ovvia: “programmare sempre con linguaggi di quinta generazione perridurre al minimo lo sforzo di codifica”.Esistono altri fattori da valutare. Per esempio, esiste una prova empirica che lavelocità di esecuzione (cioè le prestazioni in macchina) di un linguaggio sia inver-samente proporzionale al suo livello. Così i linguaggi sopra il livello 5 non sonoconsiderati adatti ad applicazioni real-time (come tracciamento radar e control-lo di processi industriali).I linguaggi sotto il quinto livello rappresentano circa l’85% del SW sviluppato nelmondo [49] e possono essere considerati general-purpose.Dal quinto al decimo livello troviamo linguaggi molto specializzati (LISP, Prolog,APL, Pilot, Simscript, Style e Stratagem) e quindi molto potenti ma spesso for-temente vincolati dal rispettivo campo di applicazione (simulazione, sviluppodata-base, statistica, intelligenza artificiale).Salendo nella gerarchia incontriamo la famiglia degli Object-Oriented (C++,Actor, Smalltalk). I concetti di ereditarietà e di visione a “oggetto” facilita-no la riusabilità dei moduli e consentono lo sviluppo di applicazioni comples-se a partire da insiemi relativamente limitati di costrutti primitivi.


Tabella 5.7

Linguaggio Livello Numero di istruzioni (SLOC)per punto funzione

Assembler 1 320Macro Assembler 1,5 213C 2 150FORTRAN IIBASIC Interpretato 2,5 128ALGOL 68Fortran 77ANSI COBOL 85Jovial 3 105ANSI COBOL 85PascalBASIC Compilato 3.5 91PL/IModula 2RPG 4 80Ada 4,5 71PrologLISPForthBASIC ANSI 5 64LOGO 5,5 58English-based languages 6 53Database languages 8 40Decision support languagesSTRATAGEM 9 35Statistical languagesAPL 10 32Object oriented languagesObjective CC++ 12 27SMALLTALK 15 21DB Query languages 25 13Spreadsheet 50 6Linguaggi di 5a generazioneGraphic Icon Languages 75 4


Anche i linguaggi di questo gruppo sembrano essere efficaci nel caso di ap-plicazioni real-time e si propongono quindi come alternativa per lo sviluppodi SW di elevate prestazioni.I livelli dal 16 al 20 comprendono essenzialmente i generatori di programmi e diapplicazioni. In questo caso per “linguaggio” si intende l’insieme degli statementdi generazione di input. Esempi di questi linguaggi sono Ideal, Link, Telon,Gama, Pacbase, Express e Trasform. Essi sono adatti a sistemi informativigestionali e a progetti di database orientati alle transazioni.Sopra il ventesimo livello troviamo database query languages (SQL, QBE,Q&A, Sequel), fogli elettronici (Lotus, Excel, Framework), grafica specia-lizzata e linguaggi a icone (si parla in questo caso di simboli per punto fun-zione).

5.2.4 Limiti dei PFNaturalmente anche i PF hanno alcune limitazioni. Bisogna ammettere che esi-ste ancora oggi una certa ambiguità nel conteggio dei function type, ma è anchedoveroso far presente che gli aspetti legati alla complessità strutturale e logica delSW (loop, chiamate ricorsive, branching), non vengono trattati con la dovutaattenzione o almeno non pari a quella riservata agli aspetti “esterni” percepitidall’utente.Per questo motivo il metodo standard è ritenuto valido per le applicazioni Ma-nagement Information Systems (dove Albrecht ha sviluppato il proprio modello),ma non viene utilizzato in sistemi real-time, scientifico-militari e in generale perSW dove la complessità algoritmica è elevata, mentre è bassa la complessità deidati. Questa mancanza di un metodo standard ha portato alla “ibridizzazione”della metrica di Albrecht con altre metriche.Lo studio della relazione tra PF e linee di codice nei vari linguaggi è uno deicampi nuovi nell’Ingegneria del software e la ricerca in questo campo è ancoraagli inizi. I risultati preliminari destano interesse e allo stesso tempo disorienta-no, ma il mondo EDP ha trovato nei PF un’insostituibile metodologia per l’analisiefficace e oggettiva della produttività.Il fattore di espansione dei PF sul numero di statement sorgente indica indubbia-mente una nuova strada maestra nella ricerca; questa strada potrà condurre a unanuova comprensione dei linguaggi stessi [49].Per un riferimento più dettagliato sulla definizione degli input-types e dei GeneralSystem Characteristics (GSC) si consiglia di consultare [3], [4] e il più recente“FP-handbook” [87], oltre al manuale aggiornato di conteggio dei punti fun-zione [67].


5.3 Modello ESTIMACS di Howard RubinIl modello ESTIMACS (ESTImation MAnagement and Computer Services) è statosviluppato da Howard A. Rubin all’inizio degli anni 80 ed è una metodologia“proprietaria”, per cui i dettagli tecnici, come le equazioni su cui si basa e i pesidei parametri correttivi non sono pubblicati.L’approccio filosofico di ESTIMACS al problema della stima è quello diinteragire con lo stimatore attraverso una serie di domande esplorative e quindi,per quanto possibile, identificando il progetto in esame.Rubin sostiene che per formulare una stima bisogna attraversare quattro fasidistinte [70], [71], [72].

1) Dati di input – evoluzione della stima: è la fase in cui i dati forniti al modellovariano rapidamente e, di conseguenza, vi è una continua evoluzione del-la stima. Lo stimatore è quindi cosciente della reazione causa/effetto delmodello che sta usando.

2) Conclusione della stima: vengono rappresentati tutti gli aspetti della stimacompletata.

3) Macro e micro analisi:a) macro analisi di sensibilità del risultato: si cerca di verificare il peso che

i fattori principali esercitano sulla stima globale;b) micro analisi di sensibilità, non sempre presente: tutti i dati di input

vengono analizzati in relazione alla loro variazione con la stima finale.4) Revisione della stima: il valore di qualsiasi input, isolatamente, può essere

modificato e di conseguenza la stima viene rielaborata totalmente. Lostimatore quindi ritorna al punto 1.

Le domande principali che il modello ESTIMACS rivolge allo stimatore per poterelaborare una stima dello sforzo necessario allo sviluppo del progetto sono suddivi-se in due gruppi: domande relative alla descrizione organizzativa del progetto (fatto-ri soft) e domande relative alla descrizione massima del sistema (fattori hard).Le domande relative all’organizzazione del progetto sono 8:

1. Quante unità organizzative (utente) saranno coinvolte direttamente nelprogetto?

2. Quanti siti, oltre a quello dove verrà sviluppato il progetto, sarannocoinvolti?

3. Quante persone nelle unità organizzative (utente) saranno coinvolte?4. Qual è il grado di familiarità del gruppo di sviluppo sull’applicazione?5. Qual è il livello di condivisione degli obiettivi del progetto da parte del ma-

nagement dell’utente?


6. Quale sarà il tempo dedicato ai viaggi per coinvolgere i vari siti?7. Nella stesura delle specifiche ci saranno persone che poi non parteciperan-

no al gruppo di sviluppo?8. Quante persone presumibilmente saranno assegnate a questo sforzo?

Le domande relative alla descrizione del sistema sono invece 17:

1. Quante funzioni principali saranno implementate?2. Quanti input logici dovranno essere elaborati dal sistema?3. Quanti output logici dovranno essere generati dal sistema?4. A quanti file (database logici) viene fatto accesso nel software?5. Quanti tipi principali di inquiry on line sono previsti?6. La conoscenza dell’informatica, da parte dell’utente, sarà vantaggiosa per

lo sviluppo del sistema?7. In che percentuale di funzionalità del sistema sono già svolte manual-

mente?8. In che percentuale queste funzionalità sono già automatizzate?9. Un sistema di questo tipo è già operativamente funzionante da qualche

altra parte?10. Il sistema da realizzare sarà di tipo batch, on-line o distribuito?11. Il sistema può essere considerato un’applicazione “critica”?12. È previsto lo sviluppo di un sistema di backup?13. È previsto lo sviluppo di un meccanismo speciale per il disaster-recovery?14. Le prestazioni (performance) del sistema dovranno essere considerate una

specifica critica del progetto?15. Il sistema da realizzare dovrà essere considerato prevalentemente un’ap-

plicazione di tipo batch, on-line oppure real-time?16. La logica dell’elaborazione può essere considerata semplice, di media

complessità oppure fortemente complessa?17. Le specifiche del sistema prevedono la rilevazione e la correzione auto-

matica degli errori?

Dal contenuto delle domande e in particolare dalle domande relative alla strut-tura del sistema si può dedurre che il modello di Rubin, almeno per quanto ri-guarda il dimensionamento del progetto da stimare, è principalmente basato suiconcetti di Function Points.Per quanto riguarda l’affidabilità del modello possiamo confermare i risultati diun’indagine comparativa condotta da Kemerer [81] e cioè che il modello consen-te stime che rispetto al valore dello sforzo consuntivo sfiorano un errore relati-vo assoluto dell’85% su un database composto da 12 progetti di tipo gestionale.


5.4 Feature Point di Capers JonesL’approccio dei punti funzione è nato allo scopo di trattare e risolvere i proble-mi legati alla metrica dei sistemi tradizionali del Management Information System.Ciò significa che la metodologia dei PF non necessariamente si presta a trattarein modo ottimale progetti real-time come, ad esempio, un sistema di controllo deimissili, la gestione di sistemi di commutazione telefonica, l’applicazioneingegneristica nel campo del Computer Aided Design (CAD) o le problematicheinerenti la simulazione con l’ausilio di modelli matematici.Nel 1986 Capers Jones [49] ha sviluppato una metodologia sperimentale per ap-plicare l’approccio dei PF al dominio del System Software e a tutti i sistemi incui l’elemento algoritmico ha un certo peso.Le caratteristiche principali del modello di Capers Jones sono le seguenti:

• il metodo di conteggio è molto simile a quello dei PF; per certi versi loestende permettendo all’utilizzatore di esprimere una misura dei requisi-ti del software real-time o con forte contenuto algoritmico;

• i Feature Point introducono un nuovo Function Type rispetto ai punti fun-zione, e cioè il “numero di algoritmi”. Con tale entità Jones intende l’in-sieme di regole necessarie per la soluzione dello specifico processo nelcomponente dell’applicazione in esame;

• la complessità (peso) dei Function Type è considerata sempre con un va-lore medio (Albrecht considera invece tre coefficienti diversi di comples-sità – basso, medio e alto) a eccezione della nuova entità “numero deglialgoritmi”;

• per definire il peso (complessità) dell’entità “numero degli algoritmi”, chepuò avere il valore intero nell’intervallo da 1 a 10 Jones, suggerisce di uti-lizzare la Figura 5.1;

• i fattori correttivi vengono considerati solamente attraverso due parame-tri tecnici di complessità:1 complessità del processo;2. complessità dei dati.

Il conteggio dei Feature Point viene effettuato come indicato nella Tabella 5.8 ecioè in tre passi:

1. calcolo degli UFP (Unadjusted Feature Point), sommando il risultante di cia-scun Function Type per il relativo peso;

2. calcolo dei FCC (Fattore Correttivo di Complessità), rilevando il corrispon-dente coefficiente (Tabella 5.11) della risultante somma dei due pesi rela-tivi alla complessità del processo (Tabella 5.9) e alla complessità dei dati(Tabella 5.10);


3. calcolo degli AFP (Adjusted Feature Point), moltiplicando il valore calco-lato del UFP per il valore di FCC.

Per determinare il fattore correttivo di complessità (FCC), Jones definisce ilrange, con i relativi pesi, della complessità del problema e quello della comples-sità dei dati (Tabelle 5.9 e 5.10).Inoltre, sulla base della somma dei fattori di complessità viene fornita la Tabel-la 5.11 per calcolare il valore del FCC.Riportiamo nella Tabella 5.12 [48], i rapporti medi, calcolati per categorie di pro-getti, fra Function Point e Feature Point.

Tabella 5.8

Function Type Peso TotaleNumero di input × 4Numero di output × 5Numero di inquiry × 4Numero di file logici × 7Numero di file di interfaccia × 7Numero di algoritmi × (vedi Figura 5.1)

Unadjusted Feature Point ∑Fattore correttivo di complessità

(vedi Tabelle 5.9, 5.10, 5.11) XAdjusted Feature Point =

Numerodi fattorio condizioniper regola

3

5

6

7

8

9

4

2

1

1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

Numero di regole nell’algoritmo

2

3

4

5

6

7

8

9 10

10

1

Figura 5.1


Tabella 5.9

Complessità del processo PesoTutti gli algoritmi semplici ed elaborazioni elementari 1Maggior parte degli algoritmi semplici ed elaborazioni elementari 2Algoritmi ed elaborazioni di media complessità 3Qualche elaborazione complessa 4Diversi algoritmi ed elaborazioni complesse 5

Tabella 5.10

Complessità dei dati PesoDati semplici e poche variabili di bassa complessità 1

Molte variabili con semplici correlazioni fra i dati 2

Archivi multipli contenenti campi e dati correlati 3

Struttura dati complessa con dati correlati 4

Struttura dati molto complessa e forte correlazione fra i dati 5

Tabella 5.11

Somma dei fattori della complessità Fattore correttivo di complessità2 0,6

3 0,7

4 0,8

5 0,9

6 1,0

7 1,1

8 1,2

9 1,3

10 1,4

Dal confronto dei risultati [48], si può dedurre che per quelle applicazioni in cuiil numero di algoritmi da implementare è incerto e/o in cui i fattori algoritmicisono poco significativi, l’uso dei punti funzione è sicuramente più indicato. Molteapplicazioni gestionali, infatti, appartengono a questa categoria.Mentre per le applicazioni in cui il numero di algoritmi necessari è identificabilee/o in cui i fattori algoritmici sono comunque di un certo peso il conteggio deiFeature Point può costituire un’alternativa valida. Rientrano in questa categoriadiverse applicazioni scientifiche oltre quelle sistemistiche.


Tabella 5.12

Categorie di progetti Function Point Feature PointDatabase (batch) 1 1

Database (on line) 1 1

Scientifico/matematico 1 1,05

Software di sistema 1 1,125

Telecomunicazioni 1 1,2

Controllo di processo 1 1,275

Processi real-time 1 1,35

Grafica/processamento d’immagine 1 1,425

Robotica/automazione 1 1,5

Intelligenza artificiale 1 1,575

5.5 Nuove metodologieDagli inizi degli anni Novanta, dopo un lungo periodo di stasi per quanto riguar-da lo sviluppo di metodologie e strumenti per la stima del costo del SW sia incampo accademico che in quello industriale, si è riacceso l’interesse per nuovi ap-procci integrativi [11].In particolare gli studi si sono orientati maggiormente alla “comprensione” delprocesso di sviluppo del software. Così, l’obiettivo principale è diventato quel-lo di definire dei modelli in grado di descrivere meglio la dinamica del processodi sviluppo del SW.Per descrivere la dinamica del processo di sviluppo del SW sono sicuramentenecessarie centinaia di variabili. Inoltre è fuor di dubbio che molte di questi va-riabili sono interdipendenti [1], [35], [62].Una metodologia, supportata da un approccio modellistico, con le caratteristicheidonee ad affrontare le esigenze citate è la Dinamica dei sistemi (System Dynamic)[30], [31].

5.5.1 Dinamica dei sistemi (System Dynamics)La Dinamica dei sistemi è l’applicazione dei principi e delle tecniche dei sistemiaventi controllo retroattivo (Feedback Control Systems) principalmente ai proble-mi aziendali (manageriali, organizzativi, produttivi ...) e socio-economici.La rappresentazione del sistema aziendale, come sistema dinamico, costituisceuno strumento interpretativo molto potente di una serie di fenomeni, altrimen-ti difficilmente spiegabili sulla base di semplici e intuitive relazioni di causa-ef-fetto.


La struttura fondamentale di un circuito generico di retroazione consiste in unadecisione che guida un’azione, la quale modifica lo stato del sistema che a suavolta influisce sulla decisione (Figura 5.2).Gli elementi base della Dinamica dei sistemi possono essere enunciati nei seguen-ti punti:

1. è necessaria una chiara identificazione di tutti i fenomeni emergenti daquella realtà che si vuole rappresentare come sistema;

2. ogni fenomeno preso in esame trova le sue origini e il suo sviluppo entroi confini del sistema stesso;

3. nella descrizione del sistema vanno evidenziati gli anelli di retroazione;4. Nella trasposizione da sistema a modello vanno utilizzate tutte le informa-

zioni ottenibili;5. l’intero sistema si compone di parti, per ognuna delle quali deve essere pos-

sibile una descrizione completa;6. le parti del sistema sono connesse fra loro da una rete di tipo informativo

che ne costituisce il tessuto connettivo.

Ciò che traspare nei punti enunciati è l’assunzione che la realtà, intesa comesistema da cui traggono origine i fenomeni osservati, possa essere delimitataattraverso una precisa identificazione dei fenomeni stessi. Il sistema cosìevidenziato è la sede dove si generano tutti i fenomeni percepiti e descrittidall’osservatore.

5.5.2 Software Project Dynamics di Abdel-HamidCome è stato asserito in precedenza, il processo di stima è un processo continuoe dinamico come lo stesso processo di sviluppo del software.

Decisione

Informazioni sullostato del sistema Stato del sistema

Figura 5.2


Recentemente T.K. Abdel-Hamid [1], [2] ha suggerito un modello di stima chesupporta la “continous estimation”.Tale modello è stato implementato da un gruppo di ricercatori della Naval Post-graduate School ed è composto da due moduli: un modulo che implementaCOCOMO e un modulo SD (System Dynamics simulator of Softwaredevelopment), il quale si compone di 4 sottomoduli (come rappresentato nellaFigura 5.3) interconnessi mediante una serie di cicli retroattivi (feedback). Ilmodulo SD si basa essenzialmente sull’equazione della seguente forma:

WFk = WFj + (DT) (HRjk – FRjk) (5.23)

dove:WFk (WorkForce) è la forza lavoro al tempo attuale (k),WFj forza lavoro al tempo immediatamente precedente (k – 1),DT è l’intervallo della computazione della simulazione,HRjk (Hiring Rate) è il tasso di reclutamento di personale nuovo nel progetto,

nell’intervallo jk,FRjk (Firing Rate) è il tasso di uscita del personale dal progetto, nell’intervallo jk.

Input

OuputSimulatore dinamico

Modello diinterfaccia

COCOMO

Interfaccia

Simulatoredel modello

Gestione dellerisorse umane

Attivitàcontemplate

Sviluppodel softwareproduction

Disponibilitàdel personale

Statodell’avanzamento

Personalenecessario

Sequenziatore

Controllo Pianificazione

Figura 5.3


La strategia proposta da Abdel-Hamid tiene conto della dinamicità del proces-so di sviluppo del software e suggerisce quanto segue:

1. alla fine di ogni fase di sviluppo, il manager dovrebbe ristimare la dimensio-ne, lo sforzo e la durata, e di conseguenza aggiornare il Software development/management plan tenendo conto dei cambiamenti osservati;

2. è molto importante ristimare continuamente lo sforzo e confrontare que-st’ultimo con quello effettivo a ogni milestone principale, e avere così in-dicazioni utili per la stima delle fasi successive.

L’utente può iniziare il processo di stima inserendo gli input necessari aCOCOMO (stima della dimensione e rating dei 15 cost driver) e ottenere la sti-ma dello sforzo, della durata e dell’indice di produttività del progetto (dimensio-ne stimata diviso lo sforzo stimato). In aggiunta ai cost driver di COCOMO, ilmodulo Simulatore Dinamico (SD) richiede altri due tipi di input: i parametri checaratterizzano l’organizzazione del progetto (per esempio, il tasso di avvicenda-mento del personale e i ritardi dovuti all’inserimento di nuovo personale) e lepolitiche manageriali (come per esempio le assunzioni del personale e il training).Il modello può produrre due tipi di stime:

Produttività

Avanzamento

Stima deicosti/piani

Sforzo aggiuntivoalla comunicazione

e formazione

Dimensionedello sforzo

Statoraggiunto

Intensitàdel

lavoro

Figura 5.4


• una predizione dello sforzo e della durata del progetto;• una proiezione “continua” sull’aumento di forza lavoro (staff loading) du-

rante l’avanzamento del processo di sviluppo.

Durante l’avanzamento del progetto, tutte le variabili del modello possono esseremodificate in base ai cambiamenti osservati rispetto alla sessione di stima prece-dente.Concettualmente ciò significa che lo sforzo richiesto per lo sviluppo di un pro-getto è, in parte, una funzione della stima effettuata in precedenza.Nella Figura 5.4 vengono descritte le relazioni retroattive tra lo sforzo/durata,forza lavoro e produttività, considerate nel modello.Infatti la stima dello sforzo e la durata influenzano direttamente la forza lavoro(per esempio, il numero medio di persone componenti lo staff è calcolato divi-dendo lo sforzo per la durata), e viceversa.Inoltre la stima dello sforzo e della durata può influenzare la dinamica del pro-getto nel caso in cui non siano rispettati i tempi preventivati; si può infatti cer-care di lavorare più intensamente (questo fenomeno è chiamato “deadline effect”).

66.1 Realizzazione di un SE, 119

6.2 L’hardware, 124

6.3 Scelta del tool, 125

6.4 Campi di applicazione ed esempi di SE, 125

6.5 Sistemi esperti e stima dei costi del software, 128

6.6 Un sistema esperto per la SCS, 130

6.7 Conoscenza e sua rappresentazione nel processo di SCS, 131

6.8 Fase di elicitazione, 135

Sviluppo di sistemi esperti

Lo sviluppo di un sistema esperto (SE) differisce particolarmente da quello diun’applicazione tradizionale sia per la metodologia di implementazione che pergli strumenti impiegati nella sua realizzazione. Inoltre, mentre un’applicazionetradizionale, nella sua fase di definizione coinvolge, tipicamente, da una partel’utente (colui che ha dei requisiti) e dall’altra l’analista informatico, nello svilup-po di un SE gli attori principali sono tre:

1. l’esperto del dominio;2. l’utente finale;3. l’ingegnere della conoscenza.

L’emergere della figura dell’Ingegnere della conoscenza, è ulteriore differenza fral’approccio tradizionale e quello di SE. Tale figura, nella fase iniziale dello svilup-po, ha il compito di:

• “elicitare” (estrarre) la conoscenza dall’esperto;• filtrare e razionalizzare la conoscenza estratta;• rappresentare la conoscenza attraverso delle regole e fatti.

Le sue competenze sono nella logica formale e nei metodi usati in IntelligenzaArtificiale (IA) per rappresentare al meglio le conoscenze elicitate.

6.1 Realizzazione di un SERealizzare un SE significa progettare e implementare un sistema basato sul-la conoscenza attraverso la definizione dei fatti e delle regole che corrispon-dono, da una parte alla conoscenza estratta dall’esperto del dominio, edall’altra ai requisiti stabiliti dalle specifiche funzionali esposte dall’utente

120 Sviluppo di sistemi esperti

finale. A tale scopo l’ingegnere della conoscenza, il progettista del SE, devedisporre di:

• Metodologie di sviluppo• Strumenti di sviluppo

6.1.1 Metodologie di sviluppoL’ingegnere della conoscenza ha il compito di estrarre la conoscenza dell’espertoe codificarla in termini informatici. Questo processo, detto di acquisizione del-la conoscenza (Knowledge Acquisition- KA), [83] è universalmente riconosciu-to come il più dispendioso e delicato in quanto gli esperti non strutturano lapropria esperienza secondo canoni riconosciuti. Ogni tentativo di descrizione for-male del loro modo di ragionare è fonte sempre di grandi incertezze e difficoltà.Per ottenere prestazioni ad alto livello di un prodotto complesso come un SE ènecessaria un’evoluzione controllata e graduale del sistema. Lo sviluppo incre-mentale e la prototipazione rapida sono le metodologie di sviluppo dominantinell’area dei SE, grazie soprattutto alla notevole espandibilità strutturale dellabase di regole e alla modularità dei meccanismi di rappresentazione della cono-scenza fattuale.

Prototipazione rapida e sviluppo incrementaleIn pratica, l’ingegnere della conoscenza e l’esperto lavorano assieme alla realiz-zazione di una prima versione del sistema (il prototipo). Questa prima fase ha loscopo di esaurire il processo di KA e cioè di:

• definire l’area di applicazione del problema e riconoscere gli eventuali sot-to-problemi rilevanti;

• esplicitare i concetti chiave e le relazioni tra questi.

La descrizione comprende la caratterizzazione delle diverse classi di dati, flussidelle informazioni e struttura del dominio del problema in termini di vincoli traentità e di relazioni causali, spazio-temporali e gerarchiche.Con il progredire del lavoro il team esperto acquisisce una sempre maggiorepadronanza e coscienza del problema e del prodotto. Le informazioni scaturitedurante la KA vengono via via implementate, in puro stile incrementale, in regole,fatti, schemi e strategie, senza porre particolare attenzione a problemi di efficien-za e di performance. Una volta ultimato, il prototipo viene valutato in terminiqualitativi (“il sistema è valido?”) e se giudicato positivamente passa alla secon-da fase: la realizzazione vera e propria.È possibile che l’evoluzione incrementale porti la base di conoscenza a raggiun-

Sviluppo di sistemi esperti 121

gere dimensioni spropositate, e in una struttura logica e inferenziale insufficientea gestirla efficientemente. In questo caso il progettista deve rivedere dall’inizioil proprio operato con l’obiettivo di escogitare un approccio diverso all’or-ganizzazione del sistema, in modo da individuare un’architettura più adatta agestire il corpo di conoscenza. Si tratta di:

• capire la natura e la dimensione dello spazio degli stati per poi decidere letecniche di rappresentazione, le strategie di ricerca e il regime di control-lo più opportuni;

• determinare la completezza e l’affidabilità delle informazioni e analizzarealtri vincoli riguardanti l’interpretazione logica dei dati, come la loro dipen-denza dal tempo e la consistenza delle diverse classi cui appartengono.

Un nuovo sistema risorge così dalle ceneri di quello precedente, magari realizzatocon uno strumento diverso, dando origine a un processo di rinascita destinato averificarsi anche più volte, nel ciclo di vita di un SE.

TestingTestare un SE significa valutare la sua performance alla luce degli standard dieccellenza definiti dagli esperti del settore. Naturalmente l’esperto, che ha pre-sieduto alle fasi di concettualizzazione e di identificazione, ha un compito chia-ve anche nel testing, poiché assiste il progettista nella revisione del programma.La valutazione di un SE è ben lungi dall’essere una scienza esatta, ma è chiaro chetale compito è tanto più significativo quanto più ampio è l’insieme dei dati diprova. Le più comuni classi di errori sono le omissioni di regole e la loro parzia-le o totale scorrettezza, mentre una causa frequente di comportamenti impreve-dibili è legata alla competizione non deterministica tra regole correlate e il relativomeccanismo di risoluzione dei conflitti.

6.1.2 Strumenti di sviluppoLa descrizione degli strumenti di sviluppo qui di seguito non vuole essere unadettagliata “guida al programmatore” né una trattazione teorica volta a valuta-re le prestazioni dei diversi formalismi e i tool per la realizzazione dei SE. Si vuolepiuttosto prendere atto di quella che è la situazione del mercato di questi stru-menti, evidenziando le loro caratteristiche tecniche e le principali linee di tenden-za per il futuro.

6.1.3 Categorie di strumentiLa totalità dei tool attualmente disponibili può essere classificata in quattro gran-di categorie:


1. linguaggi di programmazione IA ad alto livello;2. astrazione di SE (Shell verticali);3. Mid-Size Shell;4. ambienti di programmazione per SE (Shell orizzontali).

Linguaggi di programmazione IA ad alto livelloI linguaggi di programmazione ad alto livello progettati esplicitamente per laproduzione di sistemi IA, sono linguaggi astratti quel tanto che basta per nascon-dere certi dettagli implementativi, liberando così il programmatore da conside-razioni di efficienza di basso livello. Tra le caratteristiche considerate fonda-mentali in questi linguaggi si possono citare:

• la capacità di manipolare liste simboliche (strutture estremamente utili neiprogrammi IA);

• la possibilità di gestire strutture dinamiche e poliformi, ritardando la spe-cifica delle dimensioni delle strutture dati o del tipo degli oggetti che que-ste contengono;

• la capacità di operare per “pattern-matching”;• la facoltà di effettuare deduzioni automaticamente oltreché di immagazzi-

nare asserzioni che costituiscono la base per le deduzioni;• l’esistenza di strutture di controllo che permettano il ragionamento

backward e forward;• la possibilità di mescolare codici procedurali e componenti dichiarative.

Tra i linguaggi di questa categoria ricordiamo il LISP [85], l’IPL (uno dei primis-simi linguaggi per l’elaborazione di liste) e il Prolog [82].

Astrazione di SE (Shell verticali)Sono i tool di sviluppo per SE special purpose. L’intento è quello di capitalizzarele esperienze accumulate nella realizzazione di Sistemi di una ben determinataclasse (per esempio, diagnosi mediche). Spesso si tratta di SE veri e propri, main una versione priva della specifica base di conoscenza, in modo da poter esse-re utilizzati quale base per lo sviluppo di altri sistemi dello stesso tipo. Più ingenerale queste Shell (guscio) mettono a disposizione un formalismo di rappre-sentazione della conoscenza e un meccanismo inferenziale modellati sulle carat-teristiche del particolare dominio di applicazione cui si rivolgono. EMYCIN,KAS, e EXPERT sono i primi esempi di questi strumenti.

Mid-Size ShellConcettualmente non sono altro che versioni ridotte delle più potenti Shellgeneral purpose (vedi la categoria 4), in quanto si propongono l’obiettivo di of-


frire servizi e prestazioni simili a quelli dei “fratelli maggiori”, ma a un costocontenuto e rivolgendosi alla grande utenza non tecnica che opera su hardwarenon specializzato. E infatti le Mid-Size Shell occupano una posizione strategica nelmercato dell’IA, avendo contribuito alla rapida espansione del settore dei SEnegli ambienti non strettamente scientifici o industriali. In questa categoria tro-viamo prodotti come Nexpert, Goldworks, Personal Consultant Plus, M1 eGURU.

Ambienti di programmazione per SE (Shell orizzontali)Sono i cosiddetti tool ibridi general purpose adibiti allo sviluppo di SE in gran-de stile, a livello sofisticato. L’aggettivo “ibrido” indica che questi strumentioffrono la possibilità di integrare una varietà di paradigmi di rappresentazionedella conoscenza pre-definiti (come oggetti, frame, reti, logica dei predicati), dimeccanismi di controllo (per esempio, backward, forward, misto, meta-regole,priorità) e meccanismi deduttivi (ragionamento probabilistico, non deter-ministico, non monotono). Inoltre tali ambienti mettono a disposizione, per ogniparadigma di rappresentazione, degli editor interattivi specializzati e integrati,spesso basati su una grafica sofisticata, allo scopo di facilitare il processo di co-struzione della base di conoscenza, guidando il progettista nell’immissione del-la conoscenza nelle forme più opportune. A questi si aggiungono meccanismi peril tracciamento automatico dell’esecuzione delle regole, della loro attivazione,dell’istanziazione dei fatti, e meccanismi per la spiegazione automatica del ragio-namento. Un’attenzione particolare viene generalmente dedicata alle facility persviluppare interfacce grafiche utili all’interazione utente-sistema.In ultima analisi, vale la pena sottolineare che queste Shell tendono a mantene-re quanto più ampia possibile l’integrazione con gli ambienti EDP tradizionali,prevedendo l’accesso a database o spreadsheet, e consentendo l’invocazione diprocedure sviluppate con linguaggi di programmazione tradizionali (tipo C oLISP). Tra gli ambienti più famosi in commercio citiamo KEE, ART, S1 eKnowledge Craft.Le Shell general purpose come KEE, ART e S1, vengono solitamente classificatecol nome di Shell orizzontali, nel senso che offrendo ai loro utenti un ampiospettro di meccanismi e “primitive” predefiniti e garantendo la possibilità diestendere le caratteristiche del sistema attraverso l’uso di linguaggi (LISP, C),consentono virtualmente lo sviluppo di un qualunque SE. Ma questa enormepotenza li rende tutto sommato strumenti piuttosto “ingombranti”, destinatiall’uso esclusivo di progettisti sufficientemente esperti, in grado di individuarnele caratteristiche, di volta in volta, più appropriate, da ritagliare e adattare alleproprie esigenze.Per questo motivo la tendenza attuale delle case produttrici è quella di offri-re tool più semplici, di maggior facilità d’uso e di minor potenza, ma più


orientati ai singoli settori applicativi. E infatti, le vere novità degli ultimi annisi ritrovano nella categoria delle Mid-Size Shell, che permettono anche a unapersona relativamente inesperta di sviluppare il proprio prototipo di mediacomplessità, ma soprattutto in quella delle Shell verticali. I vantaggi di que-ste ultime sono molteplici: prima di tutto si tratta di prodotti più snelli equindi più facili da progettare e mantenere a un costo più basso; in secondoluogo, trattandosi di strumenti ad hoc, cioè specializzati in particolari aree diapplicazione (diagnostica, monitoraggio, previsione, eccetera), contengonotutto il necessario e sufficiente per la realizzazione dei SE del settore cui sonodedicati, cosicché anche il compito del programmatore viene alleggerito.

6.2 L’hardwareNegli ultimi anni ha iniziato a delinearsi un progressivo spostamento e adatta-mento degli strumenti di sviluppo su piattaforme hardware tradizionali a scapi-to delle architetture specializzate. I motivi principali di questa migrazione sonoessenzialmente tre:

1. La progressiva crescita della potenza di calcolo delle “engineering work-station” (Sun station, HP9000, Alfa-Digital ecc.) e dei personal computer(con l’ingresso dei microprocessori a 32 bit), tanto da proporsi come alter-nativa credibile e praticabile anche nel campo delle stazioni di lavoro perl’IA.

2. Lo sviluppo delle tecniche di “micronizzazione” che ha portato alla realiz-zazione su singolo chip delle LISP Machine, da utilizzarsi come co-processiIA per macchine convenzionali (per esempio, coprocessore matematicoper PC 486-Pentium, X1 per Sun).

3. La tendenza, mostrata dai produttori di tool per lo sviluppo di SE, a im-plementare i propri strumenti in linguaggi tradizionali quali il C. In que-sto modo si ottengono Shell portabili sulla maggioranza delle classi dimacchine in commercio. Inoltre una Shell realizzata in C ha sicuramentela possibilità di integrarsi meglio con il software già esistente, su personale workstation e quindi trae vantaggio da una maggiore apertura verso isettori EDP classici, stimolando l’interesse di quella parte di utenza altri-menti diffidente e prudente nella scelta di nuove soluzioni.

Il risultato è che la tecnologia dei SE ha valicato i confini delle strutture uni-versitarie e di ricerca, tanto che abbiamo assistito a un vero e proprio boomdel settore. L’intelligenza artificiale ha acquisito una valenza strategica nonsolo come settore a sé stante, ma anche come componente aggiuntiva per si-stemi già esistenti. In altri termini è sorto il problema della riconversione diprodotti e servizi tradizionali secondo un’ottica “intelligente” e, parallela-


mente, è imposta la necessità di un processo di integrazione tra le tecnologieIA e quelle classiche.

6.3 Scelta del toolNon mancano di certo le informazioni necessarie alla scelta dello strumento disviluppo più opportuno, ma per essere gestite al meglio richiederebbero anch’es-se l’utilizzo di un SE.A questo punto, infatti, le caratteristiche del problema da risolvere (dimensionedello spazio degli stati, variabilità, incertezza, inconsistenza e completezza deidati), dovrebbero aver suggerito al team esperto le linee di ragionamento (ricer-ca esaustiva, livelli di astrazione, generazione di ipotesi con verifica, interazionetra sotto-problemi, backtracking selettivo), la natura della conoscenza (mono-tonicità, determinismo, deduzioni probabilistiche, strutturazione gerarchica,object-oriented, associativa o di altro tipo), e la forma di controllo (backward,forward, misto). A ciò andrebbero aggiunte poi le particolarità funzionali che siattribuiscono al sistema e che includono il tipo di interazione che questo è chia-mato ad avere con l’utente, (per esempio la classe di domande cui rispondere el’accuratezza delle spiegazioni) e le modalità di estensione del sistema stesso(interattivamente dall’utente, off-line dal progettista, o al limite l’auto-modifica-zione nei limiti previsti dagli obiettivi decisi durante la fase di identificazione).Sulla base di tutti questi elementi l’ingegnere della conoscenza dovrà deciderequale tra gli strumenti a sua disposizione possiede la generalità necessaria e suf-ficiente per supportare le caratteristiche strutturali e funzionali del SE da svilup-pare. Tale scelta può venire influenzata, in seconda battuta, da fattori menoconcettuali ma sicuramente più pratici, quali la disponibilità di strumenti menopotenti ma meglio conosciuti, la presenza di un efficace ambiente interattivografico di sviluppo e di debugging e, naturalmente, il costo del tool.

6.4 Campi di applicazione ed esempi di SEI SE ricoprono attualmente un ampio spettro di attività professionali estrema-mente specializzate. Quella che segue è una caratterizzazione delle principaliclassi di problemi che i SE risolvono e i settori in cui vengono prevalentementeutilizzati.

6.4.1 InterpretazioneI SE aventi le funzioni interpretative sono volti alla ricerca di un significato daattribuire all’insieme dei dati che gestiscono. Le difficoltà tipiche da affronta-re nella realizzazione di questi sistemi nascono dal fatto che spesso i dati sonoerronei o “disturbati” o addirittura incompleti, cosicché l’interpretazione devebasarsi spesso su informazioni contraddittorie. Questo porta ad affrontare si-


tuazioni in cui più significati sono attribuibili a uno stesso corpo di dati; inquesto caso si rende necessaria una meticolosa analisi volta all’eliminazionedelle alternative non significative.I settori di impiego dei SE di questa classe vanno dalla sorveglianza alla compren-sione del linguaggio parlato e scritto, dall’interpretazione delle immagini e deisegnali di controllo all’analisi delle strutture chimiche.

6.4.2 DiagnosticaLa diagnosi è il processo che individua i malfunzionamenti di un dato sistema(per esempio, il corpo umano). L’esperto di diagnosi deve conoscere l’organiz-zazione del sistema (per esempio, l’anatomia) e le relazioni e interazioni tra isottosistemi che lo compongono.È necessario comunque tenere presente che:

• alcuni guasti possono essere mascherati dai sintomi di altri;• il malfunzionamento può essere intermittente;• la raccolta dei dati per la diagnosi può essere impossibile, costosa o peri-

colosa;• la comprensione del modello del sistema può essere parziale e dare origi-

ne a diverse interpretazioni.

La diagnostica è un terreno fertile per i SE e le realizzazioni in questo cam-po spaziano nel settore industriale (malfunzionamento di dispositivi mecca-nici ed elettronici) e in quello medico (riconoscimento di infezioni, tumori,morbi).

6.4.3 MonitoraggioI sistemi di monitoraggio devono affrontare le difficoltà preannunciate nei duepunti precedenti. Il loro compito consiste nell’interpretare continuamente i se-gnali provenienti dai dispositivi di controllo e nel segnalare quindi la presenza disituazioni anomale. La necessità di dovere operare con vincoli di tempo stringen-ti, evitando falsi allarmi, costituisce un tipico problema da affrontare per i siste-mi di monitoraggio. Spesso, inoltre, ciò che si presenta come condizione diallarme dipende dal contesto corrente e può variare nel tempo, costringendo ilsistema “esperto” a modificare i parametri di giudizio nel corso della com-putazione.I settori di applicazione di questo tipo di sistemi spaziano dal controllo degliimpianti nucleari alla sorveglianza dei pazienti, sottoposti a particolari terapie,dalla gestione del traffico aereo fino alle attività di management fiscale.


6.4.4 PrevisionePrevedere vuole dire predire il corso del futuro sulla base di un modello delpassato e di informazioni sul presente. Un sistema di previsione deve essere ingrado di riferire su oggetti che cambiano il loro stato nel tempo. Inoltre devedisporre di un insieme di elementi (modelli e dati) che descrivano al meglio comele varie azioni ammissibili possano modificare lo stato sul quale operano.Naturalmente la previsione deve basarsi su teorie non esatte per potersi defini-re un processo “intelligente” (infatti non richiede particolare abilità prevedere latraiettoria di un satellite artificiale). A un SE di previsione si richiede anche unacerta sensibilità (sensitivity), cioè la facoltà di suggerire le conseguenze che azionieseguite a un dato istante possono avere nell’evoluzione futura.Le previsioni demografiche, i preventivi degli investimenti e più in generale lestime socio-economiche sono esempi più frequenti per quello che concerne lacasistica delle problematiche affrontate dai SE di questa classe.

6.4.5 PianificazioneIl termine pianificazione abbraccia tutte quelle attività che organizzano e pro-grammano le azioni da intraprendere per raggiungere determinati obiettivi.Il pianificatore deve conseguire questo risultato evitando gli sprechi di risorse ele violazioni dei vincoli prestabiliti, attribuendo priorità agli obiettivi in conflit-to e dimostrando flessibilità e opportunismo di fronte a situazioni mutevoli einsufficientemente definite. La pianificazione richiede una certa capacità di pre-visione, dalla quale eredita le caratteristiche concettuali, ma a queste ne aggiun-ge altre, quali la necessità di focalizzare l’attenzione sui dettagli più importanti,la coordinazione dei diversi sotto-problemi e la gestione delle loro interazioni.Un esempio di applicazione dei SE è la pianificazione sperimentale della gene-tica molecolare.

6.4.6 ProgettazioneI SE di questa classe hanno il compito di definire le specifiche progettuali per lacreazione di oggetti fisici che soddisfino particolari requisiti.I principali concetti chiave che vengono normalmente affrontati in un genericoprocesso di progettazione sono:

• esplorazione sperimentale di varie alternative;• gestione dei vincoli conflittuali che sfuggono a una trattazione teorica;• valutazione qualitativa delle relazioni spaziali in assenza di algoritmi di

ottimizzazione;• facoltà di passare dalla visione locale dei sotto-problemi al contesto globale

che li struttura.


Tra le varie realizzazioni di SE in questa categoria, troviamo i sistemi per la pro-gettazione di circuiti digitali, di planimetrie di edifici e configuratori di compo-nenti hardware di un sistema informatico.La rassegna appena conclusa, non solo offre la possibilità di sottolineare la vastitàe complessità delle attività cognitive che sottendono alla performance del-l’“esperto”, ma permette anche di segnalare le difficoltà insite nel loro processodi formalizzazione. Così, anche se i progressi dei SE non hanno avuto quell’evo-luzione e consolidamento industriale, forse troppo ottimisticamente prevista aiprimordi della loro storia, il loro apporto teorico e soprattutto il valore praticoe commerciale fanno sì che anche il pur minimo progresso nella loro compren-sione venga accolto con giustificato entusiasmo.Ponendosi in questa ottica, il MITI (il Ministero dell’Industria e del CommercioInternazionale giapponese), ha patrocinato nel 1981 la ormai famosa “ConferenzaInternazionale sui Calcolatori della Quinta Generazione” che ha gettato le basiper i progetti di ricerca e sviluppo dei sistemi di calcolo per gli anni novanta,con l’obiettivo di arrivare alla produzione di potenti macchine “intelligenti”,in grado cioè di compiere azioni considerate da sempre prerogativa esclusi-va dell’uomo.Al centro di questo progetto confluiscono le ricerche nel campo dell’integrazioneVLSI, dei processi paralleli, del pattern recognition, della programmazione logi-ca e, naturalmente, dei sistemi basati sulla conoscenza.

6.5 Sistemi esperti e stima dei costi del softwareLe caratteristiche concettuali delle attività previsionali, in generale, e il caratte-re euristica del processo di SCS in particolare, rendono la stima del costo delsoftware un dominio particolarmente adatto all’applicazione della tecnologia deiKnowledge-Based Systems.Un tool di stima che faccia uso di questa tecnologia può migliorare le proprieprestazioni secondo i criteri di valutazione stabiliti per i modelli di SCS, descrittinei capitoli precedenti.L’utilizzo della tecnologia dei sistemi esperti per affrontare i problemi del pro-cesso della SCS è oltremodo vantaggioso poiché tale tecnologia è particolarmenteadatta per gestire problematiche che contengono:

• euristicità;• incertezza e carenza dell’informazione;• incongruenza e inconsistenza;


e che richiedano:

• comprensibilità del processo;• accuratezza, oggettività e sensibilità dei risultati;• flessibilità ed espansibilità della base di conoscenza.

6.5.1 L’euristicaIl patrimonio di nozioni cui fare riferimento nel processo di stima ha sostanzial-mente una natura frammentata, cioè composta da un insieme di regole empiriche,ciascuna delle quali mette in evidenza una particolare correlazione qualitativa equantitativa tra fatti rilevanti. Questa forma di conoscenza, detta Euristica per-mette di catturare gli aspetti chiave e le implicazioni concettuali implicite inun’asserzione, molto simile a come un esperto abitualmente, nelle stesse condi-zioni, si comporta. In particolare, la conoscenza che si accompagna allatrasportabilità di un modello è prevalentemente empirica.

6.5.2 Incertezza e carenza dell’informazioneCome per ciò che concerne tutte le attività previsionali, anche in questo campo si èspesso costretti a effettuare stime senza il supporto dei dati necessari, quindi privi diuna base certa che permetta di pervenire a previsioni verosimili. In questi casi, inmancanza di teorie valide più o meno formali, le informazioni necessarie devonoessere estrapolate da regole prettamente empiriche, oppure si rende necessario il ri-corso ad assunzioni di comodo (default), da verificare in un secondo tempo. L’accessoa informazioni e inferenze di tipo probabilistico, sono aspetti che la tecnologia deisistemi esperti permette di gestire in modo elegante ed efficiente.

6.5.3 Incongruenza e inconsistenzaLa valutazione a priori di un sistema qualsiasi non è un processo deterministico, quindi puòessere affrontato attraverso una sequenza di tentativi e prove. Se in questa sequenza di passisi giunge a un risultato e si evidenzia una inconsistenza o una contraddizione dipendentida una precedente fase del processo, è necessario ritornare sui propri passi e riconsidera-re il problema a partire da una nuova informazione. I sistemi esperti danno la possibilitàdi esprimere una gamma di ragionamenti “non monotoni” per catturare, in tempo, even-tuali dipendenze logiche e contraddizione tra i fatti.

6.5.4 Esigenza di comprensibilitàLa predisposizione dei Sistemi Esperti a sottoporsi a domande del tipo “what-if”,“why”, “why-not”, o “how” facilita notevolmente lo sviluppo di sistemi “intel-ligibili”, prodotti che permettono cioè di spiegare, anche se entro certi limiti, i


propri processi deduttivi, il motivo di certe scelte o le conseguenze di altre. Inpratica uno strumento di stima del costo implementato come SE, è anche un si-stema di supporto alle decisioni per il Software Engineer e soddisfa automatica-mente il requisito di comprensibilità che si richiede a un modello di stima.

6.5.5 Accuratezza, oggettività e sensibilitàUn modello, per quanto esatto possa essere, è pur sempre un sistema del tipogarbage in – garbage out. L’accuratezza delle stime che fornisce dipende dallaprecisione con la quale i dati che riceve in elaborazione riflettono la realtà (inquesto caso l’applicazione SW) da valutare.Normalmente il processo di interpretazioni lascia trasparire un certo grado dialeatorietà in quanto la “conoscenza tecnica” è estremamente dipendente dallasoggettività delle scale di valori e dalle “sensazioni” e convinzioni personali, va-riabili anche nel tempo e non sempre per motivi tecnici. Di conseguenza a secon-da della persona che effettua la stima, o anche del particolare momento in cuiquesta viene effettuata, si possono ottenere risultati profondamente diversi, conl’effetto di esagerare, ridimensionare o, peggio, mascherare l’influenza di deter-minate scelte, progettuali e non, sui costi globali. In questo senso il SE si proponecome strumento “normalizzatore”, una interfaccia tra lo stimatore e il progettoche standardizza il processo di stima e che, tramite una interazione basata sulconfronto e la scelta, impone un certo grado di riflessone sui dati che si introdu-cono. Ciò riduce l’effetto negativo del “fattore umano” in fase di input e intro-duce un certo grado di obiettività, presupposto di accuratezza e oggettività nellestime.

6.5.6 Flessibilità espansibilitàL’ultima, ma sicuramente non meno importante, ragione per una scelta tecnolo-gica di utilizzo di SE nell’affrontare la stima dei costi del software è quella di potersfruttare al meglio la caratteristica di flessibilità ed espansibilità. La SCS è tipi-camente un processo in cui la conoscenza può gradualmente crescere, per cui leregole che lo governano devono essere riviste e/o integrate continuamente. Latecnologia dei SE è quindi in questo contesto ottimale, poiché senza dover rivo-luzionare una procedura tradizionale, è possibile aggiornare la strutturapreesistente, inserendo nuove regole e modificando eventualmente quelle giàesistenti.

6.6 Un sistema esperto per la SCSLe conoscenze nel campo della SCS, esposte nei capitoli precedenti, le riflessio-ni sulla tecnologia dei sistemi esperti, espresse in questo capitolo, e la quasi per-fetta corrispondenza tra le caratteristiche del processo di stima e le opportunità


della loro gestione tramite l’utilizzo di Sistemi Esperti hanno creato l’ambienteideale per intraprendere l’analisi, la progettazione e quindi la realizzazione di unsistema software innovativo in grado di affiancare con efficacia il project mana-ger nella valutazione delle risorse necessarie per lo sviluppo.L’iter seguito si basa sull’integrazione dell’approccio algoritmico (espressionemassima delle ricerche consolidate nella SCS) con quello euristico in un unico siste-ma in grado di compensare le debolezze dell’uno con le potenzialità dell’altro.La tecnologia dei sistemi esperti si propone come mezzo ideale per realizzarequesta integrazione.Su questa base di conoscenza è stato sviluppato un sistema esperto denominatoESSE (Expert System for Software cost Estimation), la cui componente algoritmicapresenta delle varianti originali rispetto ai modelli proposti in letteratura e delquale daremo in seguito le specifiche tecniche ad alto livello.L’ambizione ispiratrice dell’intero progetto è stata determinata dalla necessità direalizzare uno strumento che permettesse di supportare con efficacia l’analistapreposto alla stima, piuttosto che sostituirlo.Uno strumento creato nel pieno rispetto dei criteri di valutazione di modello diSCS (vedi Paragrafo 4.8) e in grado di venire incontro, alle esigenze dellostimatore nelle tre fasi chiave in cui si rende necessaria la stima del costo:

1. Fase preliminare; quando si deve decidere se intraprendere l’attività di svi-luppo di un progetto o meno – i previsti benefici, ovviamente non solo eco-nomici, non giustificano i costi. Inoltre può essere utile stimare diversesoluzioni (strategiche, organizzative e tecniche). Questa fase per diversimotivi (politici, strategici e talvolta dovuti a dimenticanza!) viene spesso(quasi sempre!) ignorata.

2. Fase progettuale; allorché gli elementi, sulla cui base si deve impostare lavalutazione, sono ancora pochi e generici, ma si ha bisogno di previsionidi massima più accurate rispetto alla fase precedente, e comunque con unavisione diversa tenendo conto che la decisione di realizzare il progetto èstata già presa.

3. Fase operativa; in cui dopo una completa specifica funzionale del sistemaoccorre una stima più accurata e dettagliata per fornire gli elementi di va-lutazione del processo di controllo e pianificazione del progetto.

6.7 Conoscenza e sua rappresentazionenel processo di SCS

La necessità e l’utilità dei modelli algoritmici nel processo di SCS è fuori discus-sione, come è innegabile il contributo di conoscenze che la ricerca su di essi haportato nel campo. Molti progressi sono stati fatti nella strada che porta verso


l’automazione del processo di stima, ma ribadiamo ancora una volta che taleobiettivo è raggiungibile solo se si arriva a racchiudere entro i confini di unmodello tutta la “conoscenza” che appartiene al dominio SCS e che governa laparte non deterministica del processo di stima.È fuor di dubbio che in ogni stima si inserisce una forte componente di expertise[19], benché non sia stata ancora articolata in un metodo formale.

6.7.1 Conoscenza ed esperienza di SCSLa conoscenza “letterale” del processo di stima del costo del software è stataampiamente descritta nei capitoli precedenti. Ciò che forse ancora manca percompletare la conoscenza ormai consolidata attraverso l’uso di modelli algorit-mici è l’identificazione dei parametri che influenzano una stima e i loro pesi spe-cifici.L’esperienza vissuta nell’acquisire (qualche volta inventare), valutare, pianifica-re, gestire, controllare, consuntivare (misurare) e infine analizzare le ragioni delladifferenza fra una stima iniziale (condizioni in cui è stato fatto la valutazione) eun valore finale (parametri che sono mutati nel corso della vita del software svi-luppato) è stata senza dubbio l’elemento principale del completamento dellaconoscenza sopracitato.Questa esperienza, vissuta in più di 20 anni nel mondo dell’informatica, è stataintegrata ampiamente con una lunga serie di verifiche, sul campo, attraversointerazioni con diverse realtà aziendali pubbliche e private.Le riflessioni personali e le verifiche esterne hanno confermato che metodi for-mali sono scarsamente diffusi tra coloro (“esperti”) che effettuano le stime. Se èindubbio che l’esperienza passata è sempre alla base della formulazione di unastima, è anche vero che è difficilmente formalizzabile.L’utilizzo dell’approccio “per analogia” è il primo passo per strutturare megliole esperienze (non solo personali) vissute. L’analogia concentra coscientementel’attenzione sulle differenze e similarità esistenti tra il progetto da stimare e altrigià trattati enfatizzando le caratteristiche di questi ultimi.Fondamentalmente il ragionamento per analogia ha carattere induttivo, mentreil ragionamento per esperienza passata, che, nel paradigma del discorso filosoficorientra pure nella forma induttiva, nel caso di stima dei costi può registrare unadimensione deduttiva.Di conseguenza nel tentativo di perfezionare le conoscenze “letterali” si è cer-cato di formulare la conoscenza dell’esperto umano utilizzando sia il ragio-namento per analogia, per le sue caratteristiche di base e per la sua specificaformale, che l’estrazione dell’insieme di euristica inglobata nelle intuizionidell’esperto.


6.7.2 Rappresentazione della conoscenza di SCSNel paragrafo precedente si è cercato di analizzare quale fosse il tipo di ragiona-mento adottato da un esperto nella stima dei costi. In particolare, si è sottoline-ato che la forma di “ragionamento per analogia” meglio concilia l’obiettivoconcettuale di mantenersi quanto più fedeli possibile al meccanismo cognitivoumano (ragionamento induttivo basato sull’esperienza) e alla necessità pratica diimplementare tale meccanismo tramite un formalismo adatto a essere rappresen-tato in un sistema basato sulla conoscenza.È convinzione ormai consolidata che la classificazione della conoscenza (cono-scenza globale, locale e tecnica) e il ragionamento per analogia (induzione sudifferenze e similarità con altri progetti) possono convivere in un unico contestodi rappresentazione della conoscenza che faccia uso di oggetti prototipali e diregole mediante le quali quantificare (in termini di input a modelli algoritmici)le differenze rispetto al caso reale in esame, ed eventualmente gestire anche casieccezionali.

Frames e prototipiIl database di riferimento, sul quale si vuole impostare il ragionamento per ana-logia, può essere costituito da “casi reali” cioè dati disponibili forniti da situazionieffettivamente sperimentate nel passato, oppure da casi “archetipali”, cioè datiche fanno riferimento a situazioni ipotetiche “tipiche” del campo.Facendo riferimento al dominio della SCS si impone, nel primo caso, la necessi-tà di un archivio storico di progetti sufficientemente vario per tipologie di appli-cazioni, requisiti tecnici, vincoli tecnologici e gestionali. Ma questa necessitàdifficilmente può essere soddisfatta perché nell’ambiente industriale rarissimisono i casi (come sottolineato in [8], [15] e [31]) in cui un’organizzazione riescea mantenere un archivio sufficientemente dettagliato, in grado di supportarecomparazioni significative.È d’obbligo di conseguenza affidarsi, almeno inizialmente, all’analogia basata suprogetti “fittizi”, e cioè una collezione di sistemi prototipali ciascuno dei qualicaratterizzato da valori e comportamenti “tipici” dei parametri di valutazione(cost-driver) per quella categoria di progetti che il prototipo rappresenta. Infattirichiamandoci alla strutturazione della conoscenza esaminata nel capitolo prece-dente notiamo che le informazioni contenute nei cost-driver derivano dalla cono-scenza locale e tecnica del prototipo in questione.

Definizione di prototipoCon il termine progetto (software) si intende un contesto generico di stima, valea dire una struttura composta da un sistema informatico da realizzare e dalle ri-sorse umane e tecnologiche a disposizione. I cost-driver hanno il compito di de-


scrivere qualitativamente queste risorse e di quantificarne l’impatto sulla produt-tività di sviluppo del progetto.Un prototipo deve allora rappresentare una categoria di progetti, e cioè un con-testo particolare di stima nel cui ambito i cost-driver abbiano pesi (influenza sul-la produttività) e comportamenti (legge di variazione del loro peso nelle diversefasi di sviluppo) “tipici” e “omogenei”.L’informazione che identifica un prototipo non è quindi un aggregato di dati“locali” e “tecnici”, ma una combinazione di elementi descrittivi, (nucleo rappre-sentativo), in grado di individuare quella particolare conoscenza globale chemeglio descrive il “comportamento” di certi dati (come vedremo nel prossimoparagrafo). Generalmente è proprio quest’ultima informazione a rendere contodi alcune differenze (non eccezioni) che escono dall’ambito teorico-empirico deimodelli algoritmici e a rendere dipendenti dalla calibrazione. È necessario quindiscegliere accuratamente il nucleo rappresentativo dei prototipi per poter isola-re gli aspetti della conoscenza “globale” visibili solo dall’esperto.Un prototipo è un contesto particolare e omogeneo di stima, individuato da unaconfigurazione univoca di elementi descrittivi e strutturato attraverso un insie-me di cost-driver significativi del contesto stesso. In particolare notiamo che unprototipo è completamente determinato quando è possibile assegnare a ognuno deisuoi cost-driver un peso “tipico” di default e una legge “tipica” di comportamento.Con i frame è possibile rappresentare la struttura logica di un prototipo. In par-ticolare, dando opportuni valori di default ai cost-driver per ogni configurazionedei parametri del nucleo, si arriva alla definizione di tutta la collezione di proto-tipi di riferimento per il confronto delle analogie.

RegoleDato un prototipo e un progetto da stimare si rende necessario sapere comequantificare le differenze e le similarità tra i due per ricavare la stima.Questo si traduce nel “trasformare”, il prototipo scelto, direttamente nel progettoin esame, operando una serie di modifiche ai cost-driver, che inizialmente vengonoposti a valori di default tipici per quella categoria di progetti.È il classico ragionamento per analogia: sulla base della conoscenza “locale” e“tecnica” l’esperto deduce le differenze tra il progetto in esame e il prototipocorrispondente. Queste differenze guidano il processo di trasformazione dei cost-driver seguendo precise leggi di comportamento tipiche del prototipo in questio-ne, che vengono comunque mantenute nella conoscenza “globale”.Il fatto che il processo dipenda dallo specifico prototipo deriva dalla definizio-ne data per quest’ultimo: un contesto di stima omogeneo, ove i parametri divalutazione seguono un comportamento (legge di variazione del peso nelle fasidi sviluppo) sufficientemente “regolare” da potere essere predetto, una volta pertutte, sulla base della conoscenza “globale” di un esperto (e quindi tale da per-


mettere una calibrazione del modello). Naturalmente eventuali eccezioni conti-nuano a essere fuori dalla portata delle “leggi di comportamento”, così definite,e devono essere riconosciute e valutate “puntualmente” (cioè una per una) tra-mite la conoscenza locale.Per rappresentare leggi ed eccezioni, dal momento che queste non vengono cat-turate in una struttura di frame, seguiremo un approccio tipicamente empirico, ri-spettando essenzialmente la natura induttiva del ragionamento per analogia: le regole.In pratica, il processo di trasformazione del prototipo sarà guidato da un corpodi regole che simulerà la conoscenza “globale” dell’esperto. La generica regolaavrà una struttura del tipo

if differenza (prototipo, progetto, cost-driver) then modifica (prototipo,cost-driver)

Notiamo che anche nel rilevare differenze ci vuole “expertise”, ma questa è piùdi tipo “tecnico” locale più facilmente disponibile presso l’utente di un model-lo SCS rispetto alla conoscenza necessaria per valutare la modifica.Anche nello sviluppo di ESSE, gli sforzi in fase di elicitazione della conoscenza si sonorivolte, inizialmente, alla raccolta di regole “globali” e “locali” di valutazione, copren-do il “buco cognitivo” più grande lasciato scoperto dai modelli algoritmici.

6.8 Fase di elicitazioneL’attività di elicitazione della conoscenza adottata nello sviluppo di ESSE, haportato alla “quantificazione” della conoscenza “globale” e “locale” richiesta dalmodello di stima e alla definizione delle regole di trasformazione che codificano,nel modello, il ragionamento per analogia. Queste forme di conoscenza si sonoottenute grazie all’interazione con gli esperti aziendali, abitualmente occupatinell’attività di stima.

6.8.1 Obiettivi dell’elicitazioneL’attività di elicitazione si è posti fin dall’inizio due obiettivi:

1. Individuare un insieme di “parametri descrittivi” sufficiente per classificarei contesti di stima (prototipi). Per raggiungere questo scopo è necessarioscegliere accuratamente gli elementi che compongono il nucleo, in quan-to è importante isolare a un livello di astrazione abbastanza alto le “isoledi omogeneità della conoscenza globale”, visibili solo dall’esperto.

2. Individuare quali informazioni “locali” e “tecniche” hanno peso (per oranon interessa quanto peso) nella determinazione della stima dei costi. Inpratica si tratta di stabilire i cost-driver di riferimento.


In questa prima fase di knowledge-acquisition è stata definita la struttura logicadi un archivio prototipale storico delle esperienze passate.In particolare si è conferita una strutturazione gerarchica alla famiglia dei frame-progetto riconoscendo un frame-padre classe-progetto, composto da un nume-ro limitato di slot nuclei, e un frame-figlio progetto-attuale che perfeziona lastruttura del padre aggiungendo gli slot cost-driver.Una volta definita la struttura logica di un prototipo si è proceduto a “instan-ziarla” (valorizzarla) per derivare tutti i casi “tipici”. Quindi, per ogni possibileconfigurazione degli slot di tipo nucleo sono stati determinati i valori di defaultda attribuire a tutti gli slot di tipo cost-driver per stabilirne la “legge di compor-tamento”.A questo scopo si è istituito una dimensione qualitativa generica, composta cioèda elementi discreti che sintetizzino un giudizio qualitativo sul peso di ciascuncost-driver. Si è adottata una scala di valori di tipo:

• nessuna influenza (complessità nulla);• influenza lieve (bassa complessità);• influenza moderata (media complessità) e così via;

ma si poteva pensare anche a un intervallo chiuso di numeri interi (complessità1, 2, 3ecc.).Il dominio di rappresentazione dei parametri di nucleo è stato comunque costi-tuito da valori descrittivi (per esempio, Tipologia applicazione = gestionale) e nonnumerici o qualitativi. Tale astrattezza deriva dalla loro definizione: devono es-sere sufficientemente generici da identificare tutte le possibili classi di progetti.L’installazione dei prototipi impone quindi all’attività di acquisizione della cono-scenza altri due obiettivi:

1. Stabilire i valori (qualitativi) tipici assunti da ogni cost-driver in funzionedi ogni configurazione del nucleo (prototipo). Ciò equivale a determina-re i valori (qualitativi) di default e, di conseguenza, l’intera collezione(qualitativa) di prototipi.

2. Per ogni prototipo, per ogni fase di sviluppo (analisi requisiti, codifica ecc.)e per ogni cost-driver è necessario far corrispondere la scala discreta dei giu-dizi su un dominio numerico che esprima quantitativamente l’evoluzione(dal “giudizio” più generale a quello più stringente) del peso del cost-driver inquella determinata fase di sviluppo e in quel determinato contesto di stima.

La dipendenza gerarchica esistente tra le definizioni date per gli slot checompongono il nucleo (identificanti un contesto omogeneo di stima) e icost-driver (dipendenti dal contesto), giustifica l’ammissibilità di queste dueoperazioni.


6.8.2 Metodologia dell’elicitazionePer raggiungere gli obiettivi descritti ci si è rivolti a quelle figure professionali chenel contesto industriale italiano rappresentano l’esperto nella stima dei costi diun progetto: analisti senior, project-manager, ingegneri del software, eccetera. Par-ticolare attenzione è stata dedicata alle aziende che avrebbero dovuto costituireil primo banco di prova (e quindi più motivate a collaborare) di ESSE.Considerando che nel processo di estrazione della conoscenza ci si trova, quasisempre, in una interazione non paritetica e quindi a senso unico (come quella chesi instaura tra un tesista e un practitioner spesso geloso delle proprie informazio-ni), dalla quale l’esperto non trae alcun vantaggio pratico se non un vago debitodi riconoscenza, e sapendo che la qualità e il dettaglio dell’informazione sonodirettamente proporzionali all’attenzione che l’esperto concede, si è ricorsi a unatecnica di elicitazone che ottimizza il tempo di questa integrazione.La metodologia usata è stata suddivisa in due fasi:

1. Si è sottoposto un primo questionario basato su assunzioni minime circail dominio SCS, e volto più che altro a sensibilizzare l’esperto nei riguardidel tema e a preparare una piattaforma sulla quale impostare l’intervista.Nessun contatto personale è stato attuato in questa fase. Il questionario èstato strutturato in modo da separare i “contenuti” delle diverse doman-de in “categorie” mutuamente esclusive, al fine di facilitare la preparazionealle interviste.

2. Le informazioni ottenute dal primo questionario sono state usate per in-dirizzare e gestire, caso per caso, le sessioni delle interviste (mai più di due)nelle quali l’intervistato è stato invitato, con l’aiuto di un ulteriore questio-nario a scendere più nel dettaglio (quantificato in cifre e livelli di confiden-za) nell’esposizione degli argomenti.

Il diverso livello di approfondimento con cui sono state affrontate le due fasi dielicitazione è risultato funzionale per l’ottimizzazione dei tempi e per la qualitàdei dati ottenuti. Con il primo questionario sono state raccolte informazioni sullospettro e sulla profondità delle conoscenze dell’esperto. In questo modo si sonoavuti a disposizione gli elementi per decidere su quali argomenti l’intervistaavrebbe dovuto concentrare le sue introspezioni (dove cioè l’esperto dimostra-va di possedere una conoscenza articolata), e quali aspetti invece il colloquioavrebbe dovuto ignorare per evitare di rilevare dati comunque poco significati-vi (in quanto l’esperienza mancava di “spessore”). Con il secondo questionario,riempito nel corso delle interviste dirette, sono state completate, per quantopossibile, le informazioni mancanti.

77.1 Filosofia di ESSE, 139

7.2 Specifiche tecnico-architetturali e funzionali, 140

7.3 Il processo di stima in ESSE, 146

7.4 Presentazione dei risultati, 158

7.5 Altre funzionalità di ESSE, 159

7.6 Esperienze con ESSE, 160

ESSE

ESSE ©, il cui nome è l’acronimo di Expert System for Software cost Estimation,è il frutto dell’esperienza maturata dalla società HELP (Hic Evehtur LargitusPeritia) sull’argomento della stima dei costi del software. ESSE è un sistemaesperto che definisce la stima dello sforzo di sviluppo di un progetto software,sotto forma di archetipi progettuali, di parametri iniziali pre-definiti e di regoledi trasformazione delle strutture dimensionali e funzionali.ESSE integra i tre approcci classici della SCS (vedi Capitolo 4) tramite l’uti-lizzo della metodologia di sistemi basati sulla conoscenza (vedi Capitolo 6),e fornisce informazioni sia sullo sforzo necessario per lo sviluppo delsoftware, misurato in mesi/persona, che sul tempo solare prevedibile suddi-viso per le fasi classiche (analisi, disegno, coding e integrazione e test) del suociclo di sviluppo.

7.1 Filosofia di ESSEESSE è uno strumento realizzato nel rispetto del “decalogo” dei criteri di valuta-zione per un modello della SCS; il suo scopo è quello di venire incontro alle esigenzedello stimatore in due momenti chiave del processo di stima del costo:

• nella fase iniziale del concepimento di un progetto, quando ancora si ècoinvolti nello studio di fattibilità, gli elementi da valutare sono pochi egenerici e si ha bisogno di previsioni di massima e di indicazioni utili;

• dopo una completa specifica funzionale del sistema, allorché le stime de-vono farsi più accurate e dettagliate per fornire gli elementi di valutazio-ne del processo di controllo e di pianificazione del progetto.

Nel primo caso, ESSE si comporta come un macro-modello di stima, cioè unmodello che non richiede informazioni troppo dettagliate sul progetto in esame,

140 ESSE

ma solo il minimo indispensabile per dare una stima indicativa del costo dell’in-tero progetto.Nel secondo caso, invece, ESSE diventa un micro-model, cioè un modello capa-ce di proporre non solo una stima più accurata, ma anche un “break-down” deicosti e dei tempi per ogni fase di sviluppo e per ciascun modulo componente delsistema. Naturalmente, in questo caso ESSE necessita di un numero di informa-zioni più consistente e preciso (il che, come si sa, dipende solamente dalla cono-scenza “locale” e “tecnica” dello stimatore).

7.1.1 Indipendenza dalla completezza dell’informazioneVale la pena di notare che ESSE è comunque sempre in grado di dare una stimadettagliata, indipendentemente dalla completezza delle informazioni che ricevein input. Questa capacità gli deriva dall’approccio “prototipale” con il quale ècresciuta la sua base di conoscenza.ESSE identifica, sin dalla prima interazione con l’utente, il contesto di stima delprogetto in esame, sulla base di informazioni che presumibilmente sono sempredisponibili anche nelle primissime fasi dello studio di fattibilità. Individuato l’ar-chetipo del progetto da stimare, ESSE assegna dei valori iniziali (default) a tuttii parametri significativi basandosi su delle statistiche teoriche. Tali valori didefault possono essere modificati per ciascuna applicazione personalizzata.A questo punto è compito dell’utente aggiornare e perfezionare sempre più lastima, valutando le analogie tra l’archetipo iniziale e il progetto reale meglio iden-tificato e comunicando i valori più verosimili dei parametri che ESSE rielaboraevidenziando le eventuali inconsistenze.In pratica, l’utente è invitato a riportare sul modello iniziale una serie di trasfor-mazioni qualitative fino a riconoscere man mano il progetto reale da stimare.Supponendo che le inferenze di ESSE siano “esatte”, la correttezza finale dellastima dipende esclusivamente dall’accuratezza delle trasformazioni riportate sulprototipo iniziale e quindi dalla qualità delle capacità di giudizio “tecnico” e“locale” dello stimatore.

7.2 Specifiche tecnico-architetturali e funzionaliDi seguito viene riportato l’ambiente SW di sviluppo di ESSE, cioè l’ExpertSystem Building Tool che lo ha generato, e la sua configurazione HW. Verrannosuccessivamente descritte le specifiche architetturali e funzionali dei moduli checompongono il sistema.

7.2.1 Ambiente software di sviluppoIl sistema ESSE è stato realizzato con ART© (Automated Reasoning Tool), il toolper la costruzione di sistemi esperti della Inference Corporation. ART è uno stru-

ESSE 141

mento di sviluppo di tipo shell “orizzontale” e cioè un tool ibrido general purpose(vedi Paragrafo 6.1.3).Tra i paradigmi di rappresentazione della conoscenza disponibili in ART, vi sonoi “frame”, la possibilità di strutturare le “regole” in insiemi e la logica dei predi-cati. Il motore inferenziale di ART supporta il “forward” e il “backward” chaining,un sistema di “truth-maintenance”, il “meta-controllo” e il meccanismo dei “view-points”. Il “pattern matching” è disponibile su variabili e sequenze e permettel’uso di “wildcards”.Per quanto riguarda lo sviluppo di prototipi, ART dispone di diversi editor inte-rattivi integrati per definire l’architettura della base di conoscenza nelle rap-presentazioni più opportune e supporta “l’inference tracing” per il tracciamentoautomatico dell’attivazione di regole, schemi o fatti l’implementazione delle re-gole stesse.ART permette inoltre l’estensione delle librerie funzionali del sistema stesso tra-mite l’invocazione a procedure scritte in linguaggi C e LISP.

7.2.2 Ambiente hardware di sviluppoESSE è stato originariamente sviluppato su Personal Computer del tipo 386 IBMcompatibile con sistema operativo MS-DOS 3.3, 4 MB di memoria RAM e ne-cessita di non più di 2 MB di memoria su hard disk. Attualmente è in via di svi-luppo la versione per Windows.

7.2.3 Interfaccia utente (IU)IU è il modulo di ESSE che gestisce dell’interazione utente-ESSE. In particola-re, è stata realizzata un’interfaccia che si colloca in una zona intermedia tra lesoluzioni “banali” dei comandi codificati e le soluzioni sofisticate che prevedo-no l’uso del linguaggio naturale.Il modulo IU ha come caratteristiche:

a) la facilità d’uso; l’interazione avviene non mediante un linguaggio di co-mandi e/o sintassi particolari, bensì tramite dialog box e menu;

b) la facilità di apprendimento; di tipo “immediato” attraverso messaggi ehelp contestuali on-line;

c) la velocità d’interazione; lo scambio di informazioni tra utente e sistemaviene ridotto al minimo evitando ridondanze.

IU ha il compito di guidare l’utente nella definizione dei dati di input neces-sari all’elaborazione di una stima, comunicandogli le eventuali incongruen-ze che ESSE è istruito a rilevare in questa fase. Gestisce inoltre le interazio-ni che avvengono anche a stima effettuata, come le analisi what-if o gli stu-

142 ESSE

di comparativi. Infine, in fase di presentazione dei risultati, ESSE fornisce unacronistoria commentata di determinate inferenze elaborate nel corso del pro-cesso di stima, utile per avere chiarimenti su determinate conclusioni.

7.2.4 Base di conoscenza (BC)La BC rappresenta il cuore di ESSE in quanto ingloba il patrimonio di cono-scenze nel campo della SCS sotto varie forme. Distinguiamo quattro sotto-ca-tegorie:

a) Contesto iniziale del progetto: è caratterizzato dalle dinamiche omoge-nee dei parametri nel processo di sviluppo, (un progetto è una strutturacomposta da un sistema informatico da realizzare e da risorse umane etecnologiche a disposizione per il suo sviluppo). Ogni progetto reale siriconosce in un solo “archetipo”, caratterizzato dai valori di default deiparametri.

b) Metodologie e modelli algoritmici consolidati: sono quegli approcci e mo-delli di stima, oggetto di lunga ricerca e validazione e ampiamente collau-dati in sede industriale, teoricamente e praticamente validi negli ambientiper i quali sono stati sviluppati.

c) Euristica sperimentale: è quell’insieme di regole “universalmente” accetta-te, che gli esperti della SCS utilizzano abitualmente perché ampiamente ve-rificate in anni di pratica. Esse possono sopperire ad alcune delle carenzeconcettuali dei modelli algoritmici.

d) Euristica applicativa: sono le regole “personalizzate” la cui validità è limi-tata a contesti ben precisi, indispensabili per rilevare quei casi ecceziona-li o realtà particolari che influiscono pesantemente nella valutazione. Inpratica si tratta di informazioni che descrivono le peculiarità di ogni sin-gola organizzazione di sviluppo software (piccole e grandi aziende, centridi calcolo, software-house ecc.), viste come se ognuna di esse rappresentas-se un micromondo governato da leggi proprie.

Le metodologie e i modelli algoritmici consolidati, insieme all’euristica sperimen-tale, forniscono le leggi di comportamento dei parametri per ogni progetto ini-ziale. In particolare l’euristica sperimentale ha il compito di calibrare queste“leggi” per adattare il framework teorico-empirico, descritto dal modelloalgoritmico, al contesto di stima in questione.L’euristica applicativa invece, esplicita la conoscenza “locale”, necessaria perrilevare le “eccezioni”. In certi casi la conoscenza “locale” estende quella“globale”, nel senso che può forzare specificatamente l’introduzione di cost-driver (con relativi valori di default e leggi di comportamento) non presentiin un certo contesto di stima. In altri casi, invece, si sovrappone, cioè masche-

ESSE 143

ra o ridefinisce completamente determinati sottoinsiemi di cost-driver che, acausa di anomalie locali, seguono leggi diverse.Senza questa componente il modello non può definirsi “trasportabile localmen-te”, in quanto la sola conoscenza “globale”, rappresentata nei modelli e nel-l’euristica sperimentale, si basa sull’induzione statistica e, di conseguenza, non ètrasparente ai casi particolari.La parte di BC, composta dalle regole euristiche, costituisce l’elemento con-cettualmente originale che distingue ESSE da un qualunque altro tool automa-tico per la valutazione del costo del SW, attualmente esistente, e lo pone di dirittonella categoria dei sistemi esperti.Le informazioni contenute nella BC euristica sono state ricavate da un processodi Knowledge Acquisition che ha coinvolto, direttamente e indirettamente, lapartecipazione di decine di esperti nel campo della SCS italiana (che è poi la realtàcui ESSE principalmente fa riferimento).La Figura 8.1 rappresenta globalmente il sistema con tutti i suoi componenti,evidenziando da una parte i contributi originali rispetto ai componenti consolida-ti, e dall’altra il flusso delle informazioni che permettono di raggiungere il calcolodi stima attraverso le quattro sopracitate categorie che compongono logicamentela base di conoscenza di ESSE.

7.2.5 Modulo di spiegazione (MS)Il MS gestisce le interrogazioni che l’utente può effettuare nel corso dell’elabo-ra-zione di una stima e in fase di presentazione dei risultati.Le spiegazioni sono solo di tipo “statico”, cioè predefinite (ma parametriche ri-spetto alle variabili in gioco) all’atto della realizzazione del sistema. In particolareESSE presenta, al termine della sessione di stima, una cronistoria commentata delleinferenze, decisamente interessante ai fini di una migliore comprensione della sti-ma stessa.Il sistema inoltre, sulla base dei risultati della stima e dei parametri principali chehanno influenzato particolarmente lo sforzo finale, descrive un rapporto “ragio-nato” giustificando il valore finale della stima.

7.2.6 Modulo di What-if-Analysis (WA)Questo modulo permette all’utente di eseguire analisi di tipo what-if sui risulta-ti di una stima per valutare gli effetti che determinate scelte di progetto possonoavere sui costi finali.In pratica, l’utente ha modo di andare a modificare uno o più valori immessi in fasedi raccolta dei dati di input (parametri) e osservare come la stima dello sforzo produt-tivo cambi a seconda delle scelte effettuate. ESSE non rimane passivo di fronte aqueste modifiche, ma è predisposto a effettuare controlli incrociati di consistenza su

144 ESSE

Inputorientatoall’utente

Con

trol

lo in

telli

gen

te d

i dat

i di i

nput

Contributooriginale

Metodologiadi “sizing”consolidato

Contributooriginale

Metodologiadi calcolodi “effort”consolidato

Contributooriginale

Calcolo distribuzionerisorse consolidato

Contributooriginale

• Dati anagrafici del progetto• Classificazione del progetto• Struttura “funzionale” del progetto

Calcolo di PF

Dimensionamentodel progetto (PF- )like

Metodologia consolidata

Calcolo delle risorsenecessarie per fasi di sviluppo

e per figure professionali +tempo di sviluppo previsto

Parametri corretivi

Euristica sperimentaleEuristica applicativa

Trasformazione normalizzatadi PF in KLOC

Calcolo dello sforzoe del tempo di sviluppo

con COCOMO

Modello consolidato

• Linguaggio di sviluppo

• Parametri correttivi• Punti funzione• COCOMO

• Caratteristiche di progetto• Tecniche• Ambientali• Organizzative

Report sinteticie dettagliatiFile predisposti

per l’export

Grafici

Spiegazionedella stima

Figura 8.1

ESSE 145

determinati insiemi di cost-driver, per riconoscere e notificare la presenza diincongruenze. È a discrezione dell’utente decidere se ignorare o meno taliincongruenze.

7.2.7 Modulo di gestione dei risultati (GR)GR è il sottosistema dedicato alla produzione di report e grafici basati sui datiricavati da stime già effettuate. L’utente ha così la possibilità di recuperare i ri-sultati di valutazioni elaborate in tempi diversi, magari sullo stesso progetto, e dianalizzarli nella forma che più desidera.GR, integrato con le funzionalità di WA e MS, consente di effettuare analisi com-parative su più sessioni di stime, di progetti simili o dello stesso progetto, inmomenti diversi. Il maggiore vantaggio che ne deriva è quello di rendere piùchiaro all’utente il significato dei risultati ottenuti, oltreché di avvicinarlo allacomprensione delle dinamiche che intercorrono tra i vari cost-driver e le risorseproduttive di cui si vuole la stima. GR costituisce comunque anche un efficacestrumento di verifica della consistenza del sistema stesso, sia in fase di svilupposia in fase operativa. Dal confronto dei risultati possono scaturire incongruenzeche fungono da campanello d’allarme per chi sta testando o utilizzando ESSE ela tipologia di queste incongruenze può fornire utili indicazioni sulla parte delsistema sospettato di malfunzionamento.

7.2.8 Base di dati (BD)La base di dati del sistema contiene tre categorie di informazioni che non trova-no posto stabile nella BC perché non costituiscono una conoscenza efficacementerappresentabile con regole e fatti, o perché conviene mantenerle separate dalblocco centrale per ragioni di modularità e flessibilità.

a) Archivio storico clienti (ASC): contiene i dati che descrivono le caratteristi-che peculiari, rilevanti al fine della SCS, di ogni singola organizzazione disviluppo SW per la quale si prevede di effettuare le stime. Sono cioè quelleinformazioni chiamate regole euristiche applicative; la scelta di mantenerlein file esterni alla BC permette di caricare nel sistema, di volta in volta, soloquelle informazioni effettivamente necessarie. Tutto questo si traduce inuna maggior flessibilità, espandibilità e modularità del sistema.

b) Archivio storico sessioni (ASS): è destinato a contenere i risultati di quellesessioni di stima che l’utente deciderà di salvare. I dati contenuti nei fileASS sono utilizzati dal modulo di gestione risultati per generare i report ei grafici richiesti per le analisi comparative o qualitative. Per il tipo di in-formazioni che fornisce (dati numerici di produttività), ASS risiede su fileesterni e di formato standard. In questo modo i dati sono resi disponibili

146 ESSE

anche per usi diversi (stampe, relazioni ecc.), senza dovere necessariamentedipendere dalle funzionalità di ESSE.

c) Archivio tabelle dei modelli (ATM): contiene i parametri e i valori statisti-ci utilizzati dai diversi modelli algoritmici per calcolare i propri output. Sitratta tipicamente di matrici e tabelle di riferimento che esprimono relazio-ni o classificazioni di grandezze correlate ai cost-driver.

7.3 Il processo di stima in ESSELe ricerche di Boehm, il cui modello COCOMO rappresenta una pietra miliaredella conoscenza “globale”, le idee di Albrecht, che con l’introduzione dei pun-ti funzione ha segnato un significativo passo evolutivo nel campo del “SoftwareSizing”, e le analisi critiche di Jones, che ha approfondito dettagliatamente lostudio dell’impatto dei cost-driver, costituiscono i punti di riferimento fondamen-tali nella definizione della componente algoritmica e metodologica della stima.ESSE, partendo dai sopraccitati riferimenti consolidati, ha integrato le principalivarianti suggerite dalla letteratura, e propone un modello originale con un valo-re aggiunto grazie al “filtro” acquisito con il patrimonio “euristico” nel campodella stima dei costi del software, estrapolato dalle interviste con gli espertiin materia.

7.3.1 Interazione con ESSEPer elaborare una stima ESSE chiede all’utente cinque categorie di informazioni:

1. informazioni generali;2. struttura dell’applicazione;3. parametri dimensionali;4. parametri correttivi;5. costi del personale e ripartizione (%) dello sforzo personale nelle fasi

di sviluppo.

Tra queste categorie comunque solo le informazioni generali e i parametri dimen-sionali sono veramente indispensabili per affrontare la stima.Con le informazioni generali ESSE individua il contesto iniziale del progetto equindi identifica il set dei valori (default) sia per i parametri correttivi, che per icosti del personale e la loro ripartizione.I parametri dimensionali, utilizzando i concetti di punti funzione assieme a unaoriginale normalizzazione per le fasi di ciclo di vita, servono invece per determi-nare una valutazione del numero di KLOC (Kilo Lines Of Code) che comporran-no il progetto, sulla base del quale verranno applicate le funzioni algoritmiche perottenere una stima dello sforzo.

ESSE 147

In questo modo ESSE, grazie alle informazioni precoci e generiche, è in grado difornire una stima indicativa dello sforzo (mesi-persona), della durata di svilup-po (mesi) e, in sottordine, della distribuzione dei costi suddivisi per fasi di svilup-po, della suddivisione dei costi per figura professionale, del numero di PuntiFunzione e di KLOC calcolati per ciascun modulo del sistema.Man mano che nuovi dati arricchiscono la conoscenza del progetto, l’utente puòperfezionare la stima operando sui parametri correttivi, a loro volta suddivisi infunzionalità e caratteristiche, e raffinare le informazioni sugli aspetti progettualilasciati scoperti rispettivamente dai parametri dimensionali e dalle informazio-ni generali.Alla fine della stima i risultati vengono dati sotto forma di tabelle, di valori nu-merici e di grafici a barre. È inoltre possibile avere una spiegazione qualitativa chesottolinei, in termini di parametri dimensionali e di parametri correttivi, gli aspetticonsiderati “interessanti” per la loro influenza nella determinazione dei costi.

7.3.2 Informazioni generaliLe informazioni generali, oltre a definire i dati anagrafici del progetto da stima-re, specificano le caratteristiche della categoria di progetti di riferimento. Anchese ESSE stabilisce per comodità dei valori di default per queste informazioni,l’utente è tenuto a specificare:

• L’obiettivo della stima:1. Nominale – assegnare i parametri di default, senza alcun vincolo parti-

colare;2. Tempo minimo – assegnare i parametri di default, per poter conclude-

re il progetto nei minimi tempi (solare);3. Costo minimo – assegnare i parametri, di default, per poter conseguire

la conclusione del progetto utilizzando al minimo il personale;4. Qualità massima – assegnare i parametri di default, per poter ottenere

il progetto con il livello di qualità massima.

• Il contesto della stima:1. Prototipo – il progetto da stimare viene affrontato con la visione

prototipale;2. Nuovo sistema – il progetto da stimare viene affrontato con la visione

classica (lo sviluppo di un sistema nuovo);3. Manutenzione – è la manutenzione di un progetto esistente.

• La tipologia dell’applicazione:1. Gestionale – il progetto da stimare è prevalentemente un sistema

gestionale;

148 ESSE

2. Telecomunicazioni – il progetto da stimare è per lo più un sistema TLC;3. Progettazione – il progetto da stimare è in maggior parte un sistema di

progettazione (per esempio, CAD);4. Controllo di processo – il progetto da stimare è prevalentemente un si-

stema di controllo di processo.

• La modalità di processing:1. On-line – il progetto da stimare è prevalentemente un sistema che ela-

bora i dati on-line;2. Batch – il progetto da stimare è prevalentemente un sistema che elabora

i dati in modalità batch.

In appendice è riportata una sessione completa di ESSE.

L’esempio fa riferimento allo sviluppo originale (nuovo sistema) di una ipoteticaapplicazione gestionale chiamata sistema dimostrativo, con elaborazione dei datidi tipo on line, da realizzare con obiettivi nominale di stima.

7.3.3 Struttura dell’applicazioneESSE prevede la possibilità di specificare l’architettura logica e funzionale diun’applicazione secondo la tipica classificazione in:

• sistema;• sottosistema;• moduli.

In questo modo è possibile costruire incrementalmente la struttura aggiungen-do, o togliendo, componenti a seconda del dettaglio di conoscenza che si hadell’intero sistema, in ogni momento e a un qualunque “livello” (sistema,sottosistema, modulo). Tale possibilità permette inoltre, una volta completatol’inserimento dati, di disporre dei risultati della stima a vari “livelli”.

Nell’esempio sistema dimostrativo vengono definiti tre sottosistemi, uno di gestio-ne di input, uno di calcolo, uno di presentazione dei risultati, e vengono specifi-cati per il secondo sottosistema due moduli separati, un modulo di elaborazione euno di controllo.

7.3.4 Parametri dimensionaliL’altra informazione indispensabile per effettuare la stima di un progetto è la suadimensione “funzionale”. L’utente ha due modi per definirla:

ESSE 149

1. quantificando il volume dell’applicazione che si deve realizzare in terminidelle sue funzionalità (Function Point);

2. fornire direttamente il numero di linee di codice sorgente (KLOC).

I parametri dimensionali di un’applicazione sono derivabili da informazionigià disponibili nella fase di analisi dei requisiti e dalle specifiche tecniche adalto livello, ricavate dalle interazioni con il cliente. Queste informazioni pro-vengono dal “punto di vista” dell’utente dell’applicazione piuttosto chedall’implementazione fisica della stessa. Come già descritto nei Capitoli 3 e 4,le dimensioni di un programma sono state storicamente definite in termini diKLOC (Kilo Lines Of Code). Nonostante le critiche mosse alle KLOC riguar-do la loro significatività concettuale nella predizione dello sforzo basata su diesse (è come dover prevedere il costo di una casa soltanto sulla base del nu-mero di metri quadri da costruire), non è stata ancora trovata una metrica at-traverso la quale poter meglio correlare lo sforzo produttivo, specialmente perquanto concerne lo sviluppo di progetti con linguaggi tradizionali.Comunque il problema principale della metrica delle KLOC rimane quello del-la difficoltà di calcolo nelle fasi iniziali dello sviluppo del SW, quando una stimapur “grossolana”, è assolutamente necessaria. Una possibile soluzione, è quelladi stimare a loro volta le KLOC con tecniche empiriche come il PERT-Sizing;queste richiedono però, una dose di experties tale per cui il problema del softwarecosting si riduce a quello del software sizing.L’altra soluzione, più pratica, consiste nel trovare una metrica “precoce” chemostri un’alta correlazione con le KLOC, in modo da permettere una loro stimaalgoritmica. Tra le diverse proposte avanzate (vedi Capitoli 4 e 5), quella deiPunti Funzione di Albrecht ha dato fino a oggi i migliori risultati.Questo metodo si è diffuso rapidamente e con successo tale da imporsi comeuno standard industriale “de facto”, come dimostrano i tanti tool basati suipunti funzione o sulle loro “varianti”. L’opinione ormai consolidata è chel’approccio al problema del SW Sizing “dovrebbe procedere con il calcolo deipunti funzione come base metodologica, possibilmente derivabili diretta-mente dalle specifiche funzionali e un algoritmo per stimare coerentementele KLOC”.Questo è stato esattamente l’approccio di ESSE: i parametri dimensionali (filelogici, interfacce, aggiornamento/interrogazioni, output) costituiscono gli inputper calcolare i punti funzioni derivabili dalle specifiche funzionali.Di seguito vengono riportate le descrizione di parametri dimensionali di ESSE,derivate, in parte, dalle definizioni più generali riportate nel Capitolo 5.

150 ESSE

File logiciPer file logico si intende:

• ogni gruppo principale di dati (assimilabili a entità);• ogni gruppo principale di informazioni di controllo.

Questi gruppi devono essere generati, usati e mantenuti dall’applicazione.Esempi di file logici sono:

• entità logiche di dati;• tabelle o archivi gestiti dal cliente;• file di dati o di controllo usati da un’applicazione batch.

Sono da escludere dal conteggio i file intermedi o di servizio (come per esempiogli indici).

Nell’esempio sistema dimostrativo sono stati definiti due file logici. Il primo, de-nominato gestione dati di input, rappresenta l’archivio che ospiterà tutti i dati diinput e il secondo, chiamato tabella di controllo servirà al modulo di controllo attoa effettuare i controlli per il sottosistema calcolo. Tutti e due questi file verrannocreati, eventualmente modificati, comunque mantenuti dal sistema in oggetto.

InterfaccePer interfaccia si intende ciascun gruppo principale di dati utente o di informa-zioni di controllo usati dall’applicazione ma mantenuti da altre applicazioni. Insostanza sono dati che attraversano, in un senso o nell’altro, la frontiera del-l’applicazione.Esempi di interfacce sono:

• file che contengono dei record provenienti da altre applicazioni;• database condivisi con altre applicazioni;• dati di controllo generati o inviati ad altre applicazioni.

I file logici interni a un’altra applicazione ma usati come transazioni, non devonoessere conteggiati tra le interfacce, bensì nel parametro dimensionale che segue.

Nell’esempio sistema dimostrativo è stato definito un solo file di interfaccia, deno-minato archivio esterno. Tale archivio rappresenta il file da cui il sistema attingedati, che eventualmente verrà aggiornato attraverso il modulo di elaborazione delsottosistema calcolo, mentre tale file non verrà né creato, né mantenuto dal nostrosistema dimostrativo.

ESSE 151

Aggiornamenti/interrogazioniPer aggiornamenti/interrogazioni si intende:

• ciascun gruppo di dati utente o di informazioni di controllo che entranonell’applicazione e causano aggiunte, modifiche o cancellazioni dei datipresenti nei file logici (aggiornamenti);

• ciascuna combinazione di input/output dove l’input genera un output im-mediato (interrogazioni).

Qui è importante anche distinguere il formato di queste informazioni e le diffe-renze di elaborazione (a livello logico) cui vanno incontro.Esempi di aggiornamenti/interrogazioni sono:

• schermate di input;• schermate multiple accomunate e “processate” in un’unica transazione;• menu di selezione con capability di salvataggio;• funzioni di aggiornamento conseguenti a una interrogazione;• gruppi di transazioni provenienti da altre applicazioni.

Il sottosistema gestione dell’input del sistema dimostrativo dovrà gestire unamaschera di input per acquisire dei dati e quindi è prevista una funzione di aggior-namento. Si prevede inoltre di poter interrogare l’archivio logico file di gestione datidi input tramite una funzione di interrogazione.

OutputPer output si intende ciascun gruppo principale di dati utente o di informazio-ni di controllo che lascia la frontiera dell’applicazione. Anche in questo caso ilformato dei dati e il tipo di elaborazione prevista per loro costituiscono un ele-mento di distinzione. Tipicamente un output consiste in:

• output di dati su video;• report di tipo batch;• formati di messaggi di errore;• stampe.

Sono esclusi dagli output i singoli messaggi di errore, file di backup o altri file dioutput di servizio, creati per motivi tecnici.

L’esempio sistema dimostrativo prevede due tipologie di stampe (dati selezionatidagli archivi), ciascuna con un formato diverso, che verranno sviluppate nelsottosistema presentazione dei risultati.

152 ESSE

7.3.5 Parametri correttiviI parametri correttivi, a loro volta suddivisi in funzionalità e caratteristiche, hannoil ruolo di raffinare le informazioni sugli aspetti progettuali, lasciati scoperti ri-spettivamente dai parametri dimensionali e dalle informazioni generali.

FunzionalitàLe funzionalità descrivono le caratteristiche funzionali del sistema/sottosistema/modulo da valutare. Mentre i parametri dimensionali rappresentano una misu-ra della dimensione dell’informazione da elaborare, le funzionalità rappresentanouna misura della dimensione della complessità tecnica associata a questa infor-mazione. In pratica, le funzionalità danno un “peso” alla dimensione osservabiledell’applicazione. Come i parametri dimensionali, anche le funzionalità sonointrinseche alla “size” del sistema, nel senso che derivano direttamente dai requi-siti del sistema da realizzare.Le funzionalità servono per determinare il fattore di complessità tecnica cheperfeziona il calcolo degli UFP (vedi Capitolo 5), e quindi la stima delle KLOCdell’applicazione. Tuttavia sono presenti alcune “originalità” rispetto al calcolocanonico dei punti funzione.Le funzionalità sono state suddivise in cinque categorie, delle quali si dà unarappresentazione schematica.

1) Funzionalità generali:• Carico sul sistema HW target• Comunicazione dati• Prestazioni del sistema

2) Particolarità on-line:• Aggiornamento degli archivi on line• Efficienza dell’interfaccia• Immissione dati on line• Volume delle transazioni

3) Elasticità e parametricità:• Installazioni plurime• Interfacciamento verso altre applicazioni• Riusabilità del software• Semplicità di conversione e installazione• Semplicità nelle modifiche per utente

4) Agevolazioni per l’utente:• Facilità di training

ESSE 153

• Livello di documentazione richiesto• Semplicità di gestione operativa• Facilità d’uso da parte di utenti occasionali

5) Specificità del progetto:• Aspetti speciali di sicurezza• Elaborazione distribuita• Definizione di HW o SW speciali

La scala “qualitativa”, cui l’utente può fare riferimento per assegnare i valori allefunzionalità è data da 7 fattori:

1. nessuna influenza;2. lieve influenza;3. moderata influenza;4. media influenza;5. significativa influenza;6. elevata influenza;7. determinante influenza.

Tali fattori esprimono il giudizio dell’utente sul peso che le problematiche rela-tive a una determinata funzionalità possono avere sul “livello” (sistema/sottosiste-ma/modulo) in esame.

Nell’esempio sistema dimostrativo sono stati assegnati i valori di default per tut-ti i parametri correttivi – funzionalità, tranne per i seguenti:Prestazioni del sistema con influenza elevata invece di media (default);Volume di transazioni con influenza significativa invece di media (default);Livello di documentazione con influenza determinante invece di media(default);Aspetti speciali di sicurezza con influenza media invece di nessuna (default).

CaratteristicheLe caratteristiche raggruppano i parametri correttivi che descrivono, primaria-mente, l’ambiente del progetto in termini di abilità ed esperienza del personale,interazioni con l’utente finale, tecnologie e metodologie impiegate nello svilup-po. In generale sono parametri che non risultano direttamente dai requisiti delsistema forniti dall’utente e non vengono quindi trattati nell’ambito dei puntifunzione.La classificazione delle caratteristiche si basa essenzialmente su quella prodottada Boehm [9] per i cost driver del COCOMO. A essa si è ritenuto doveroso ap-

154 ESSE

prontare qualche modifica prendendo in considerazione alcuni aspetti, per diver-se ragioni trascurati da Boehm, alla luce di indicazioni scaturite dalla fase dielicitazione della conoscenza dagli esperti (vedi Capitolo 6) e da altre fonti del-la letteratura [1, 17, 48].Anche le caratteristiche si dividono in cinque categorie.

1) Caratteristiche del prodotto:• Affidabilità richiesta• Complessità dell’elaborazione• Dimensioni database• Instabilità dei requisiti

2) Caratteristiche del progetto:• Linguaggio di programmazione• Moderne tecniche di programmazione• Strutturazione dello sviluppo SW• Uso di strumenti SW di supporto• Vincoli di schedulazione

3) Ambiente HW/SW:• Ambiente HW di sviluppo• Ambiente HW target• Instabilità della macchina virtuale• Vincoli sui tempi di risposta• Vincoli sull’occupazione di memoria

4) Caratteristiche del personale:• Affiatamento del gruppo di sviluppo• Capacità degli analisti• Capacità dei programmatori• Conoscenza del linguaggio di programmazione• Esperienze sulla macchina virtuale• Esperienze sulle problematiche applicative

5) Caratteristiche dell’utente:• Conoscenze di data-processing• Livello di condivisione degli obiettivi• Numero unità operative interessate• Numero utenti che definiscono le specifiche• Percentuale di funzioni già automatizzate• Percentuale di funzioni già svolte manualmente

ESSE 155

Nell’ambito delle caratteristiche sono state definite diverse scale “qualitative”, icui domini tengono conto della semantica del parametro che si vuole valutare. Peresempio, nel caso del parametro numero di unità operative il dominio è datodall’insieme dei valori (uno, due, tre o più), mentre per il parametro percentualedi funzioni già automatizzate i possibili valori sono da scegliersi nei range (30%o meno, 30-60%, 60% o più). Anche per quanto riguarda i parametri non nume-rici sono state fatte distinzioni “semantiche”, per esempio le conoscenze di data-processing dell’utente finale possono essere nulle, scarse, discrete, buone, moltobuone.Naturalmente a ogni scala viene associata una descrizione più esauriente (dispo-nibile tramite l’help on line) di ognuno dei suoi elementi. Ciò aiuta l’utente diESSE a esprimere un giudizio più obiettivo su quanto gli aspetti di un certo cost-driver possono incidere sulla struttura dell’applicazione (sistema/sottosistema/modulo) in esame.

Nell’esempio sistema dimostrativo sono stati tralasciati i valori di default pertutti i parametri correttivi – caratteristiche, tranne che per i seguenti:Affidabilità richiesta con influenza alta invece di nominale (default),Complessità dell’elaborazione con influenza elevata invece di bassa (default),Linguaggio di programmazione “C ” invece di nessun linguaggio (default),Ambiente HW di sviluppo e di target sarà minicomputer invece di mainframe(default),Capacità di analisti coinvolti sarà ottimo invece di nominale (default),Numero utenti che definiscono le specifiche sarà uno invece di due-tre(default),Percentuale di funzioni già svolte manualmente sarà maggiore di 60% inveceche fra 30% e 60% (default).

7.3.6 Considerazioni sulla gestione dei parametri correttiviQui di seguito vengono riportate alcune considerazione sulla gestione dei para-metri correttivi da parte di ESSE che permettono di capire meglio la natura“esperta” del sistema.

Ereditarietà dei parametri correttiviI parametri correttivi, siano essi funzionalità o caratteristiche, possono esserespecificati teoricamente a un qualunque livello e per un qualsiasi componentedella struttura. L’utente stabilisce questo livello in base al dettaglio di informa-zioni che possiede in un particolare istante. Del resto questa è proprio la filoso-fia di un micro-modello di stima, quale è ESSE.Inizialmente è ESSE stesso che suggerisce dei valori tipici (default); in seguito,con il progredire del progetto e il raffinarsi della struttura, l’utente può modifi-

156 ESSE

care questi valori e/o specificarli separatamente per questo o quel sottosistema omodulo. Ma se il sistema ha una struttura particolarmente complessa (con molteramificazioni), atipica (i default vanno cambiati), e contemporaneamente mostrauna natura omogenea (tutto l’albero è descritto dagli stessi valori dei cost-driver),può diventare dispendioso, almeno a livello di singoli sottosistemi (sotto-alberiomogenei), il dover specificare tutti i parametri correttivi per ogni componente.Per semplificare questo processo, ESSE, forte del meccanismo di rappresentazio-ne dei frame, impone ai componenti di un sistema l’ereditarietà dei parametricorrettivi.Il valore di un parametro correttivo, assegnato a un componente ai vari “livelli”,(sistema, sottosistema) viene assunto automaticamente da tutti i componenti“figli”, a patto che questi non abbiano già esplicitamente acquisito un valorediverso.La condizione imposta è essenziale per non vanificare eventuali precedentispecificazioni dell’utente; è però possibile forzare la loro ereditarietà esplicita-mente all’atto della modifica.

Livello di strutturaCome suggerisce Boehm [9], esiste un livello minimo della struttura, nell’indi-cazione del valore di uno specifico cost-driver, che dipende dalla natura dellostesso. Questo perché i parametri correttivi rappresentano in realtà dei “vinco-li” imposti dall’utente al sistema, e la loro salvaguardia limita la libertà di poter-li ridefinire a un qualsivoglia livello.

Facendo riferimento all’esempio sistema dimostrativo, se imponiamo una cer-ta affidabilità al sottosistema calcolo, non ha senso ridefinirla diversamente peri moduli che lo compongono.

ESSE intercetta questi casi, avendo definito, per ogni parametro correttivo nel-la sua base di conoscenza, il livello più basso al quale può essere assegnato unvalore.

Modifica controllata:“Warning”Modificare un parametro correttivo significa che l’utente trasforma gradualmentela stima preliminare per farla diventare quanto più possibile simile al progetto inesame.ESSE effettua una valutazione delle modifiche apportate a ogni parametrocorrettivo e informa tempestivamente l’utente di eventuali incongruenze riscon-trate, tramite messaggi warning. Queste valutazioni sono frutto di considerazionipratiche, espresse in regole empiriche, che assicurano consistenza ai dati intro-dotti.

ESSE 157

In seguito alla segnalazione viene posta all’utente la domanda se ignorare o menol’avviso. La filosofia di ESSE è quella di assistere l’utente nelle scelte e di nonprendere autonomamente delle decisioni senza segnalarle.

Default statici e dinamiciNella struttura di ESSE esistono due tipologie di default:

1) i default statici sono stati più volte citati a proposito del concetto di stimapreliminare e quindi rappresentano i valori tipici stabiliti in partenza dalsistema per ogni parametro correttivo.

Per esempio per un progetto come il sistema dimostrativo, ESSE assegna in-fluenza significativa al parametro efficienza dell’interfaccia.

2) i default dinamici invece sono valori che ESSE decide di assegnare dinami-camente ai parametri, durante il processo di stima, in seguito alle modifi-che apportate dall’utente. Nell’assegnazione dei valori, affinché si abbiauna stima più accurata il sistema tiene conto di una serie di regole, sugge-rite dall’esperienza.

Se l’utente, per esempio, decide di cambiare il “contesto” della stima per l’ap-plicazione sistema dimostrativo, modificando da nuovo sistema al contestoprototipale, allora l’influenza tipica per il parametro efficienza dell’interfacciacambierà conseguentemente da significativa a bassa.

Naturalmente l’utente viene avvisato di questa modifica e spetta, a lui come sem-pre, la decisione ultima sul come procedere. Bisogna notare che i default “dina-mici”, così come avveniva per i segnali di tipo “warning”, hanno il compito diavvisare l’utente di ESSE della presenza di eventuali inconsistenze sorte con lemodifiche apportate alla stima iniziale, ma, a differenza dei “warning”, suggeri-scono anche i nuovi valori da introdurre.La possibilità di gestire facilmente l’euristica sulla quale si basano i default “di-namici”, e in particolare l’espandibilità del corpo di regole che la rappresenta, èun’altra delle caratteristiche di ESSE che gli derivano dalla sua natura diKnowledge-based System.

7.3.7 Costi del personale e ripartizione delle figureprofessionali, fase di sviluppo

L’opzione “costi del personale” consente all’utente di specificare i costi, per fi-gura professionale, delle persone coinvolte nello sviluppo del progetto.

158 ESSE

ESSE permette di definire (configurare) quattro tipologie di figure professiona-li; attualmente come default sono state definite le seguenti:

1. analista sistemista (capo progetto);2. analista procedure;3. analista programmatore;4. programmatore.

L’opzione “ripartizione di figure professionali/fasi di sviluppo” offre la possibilitàdi specificare, per ogni progetto da stimare, la percentuale di lavoro svolto daciascuna figura professionale per le fase di sviluppo.La tabella seguente dimostra la ripartizione adottata nell’esempio della sessioneriportata in allegato.

Analisi Disegno Coding Integrazione/testAnalista sistemista 30 10 0 0

Analista procedure 70 40 0 0

Analista programmazione 0 50 30 30

Programmatore 0 0 70 70

7.4 Presentazione dei risultatiI risultati di una stima si dividono in due categorie: risultati quantitativi e risul-tati qualitativi. I primi sono presentati da ESSE mediante schermate riassuntivedei dati numerici stimati, oppure mediante grafici a barre basati su quegli stessidati. Nel secondo caso, invece, ESSE fornisce videate di spiegazioni sugli aspet-ti che hanno influito maggiormente nella determinazione dei costi finali dell’in-tero sistema.

7.4.1 Dati numerici e graficiI risultati “quantitativi” di ESSE possono essere richiesti sia in forma tabellare chein forma grafica a barre. Nell’uno e nell’altro caso è possibile visualizzarli a livelloglobale (sistema) oppure in dettaglio (sottosistema, modulo).Il più completo report dei risultati viene presentato nella “sintesi globale” e com-prende oltre tutti i dati principali dell’applicazione, la stima globale in mesi/per-sona, in function point e in KLOCS. In aggiunta viene riportata una stima delladurata del progetto (in mesi) ed elenco dei parametri che hanno principalmen-te contributo alla valutazione dei costi.

ESSE 159

Ulteriori report e grafici sono disponibili e rappresentano in modo sintetico odettagliato i seguenti risultati:

• lo sforzo in mesi/persona per ciascuna fase di sviluppo (analisi, disegno,coding, integrazione e test);

• lo sforzo in mesi/persona per ciascuna figura professionale;• lo sforzo in milioni di lire per ciascuna fase di sviluppo (analisi, disegno,

coding, integrazione e test);• lo sforzo in milioni di lire per ciascuna figura professionale.

Nell’esempio sistema dimostrativo vengono riportati i risultati grafici e tabellaria vari livelli di dettaglio.

7.4.2 Spiegazione della stimaLa natura “esperta” di ESSE si manifesta anche nella fase di presentazione deirisultati. Alla fine di ogni sessione di stima l’utente può richiedere per ogni com-ponente del sistema, sia a livello globale che parziale, una “diagnosi” delle cau-se che ne hanno influenzato il costo.La spiegazione che ne consegue deve condurre l’utente a riconsiderare i parame-tri che egli stesso ha introdotto nel corso della stima, e quindi a evidenziare quegliaspetti che, a giudizio di ESSE, rappresentano delle eccezioni alla norma.ESSE segnala all’utente il valore conferito a ogni parametro (secondo la scalaqualitativa appropriata), la modalità con la quale è stato assegnato il valore (im-plicito o esplicito), l’influenza che questo parametro ha in generale sullo sforzostimato e infine il “peso” (positivo o negativo) di condizionamento della stimarispetto a un ipotetico sistema nominale.

7.5 Altre funzionalità di ESSENel sistema ESSE sono presenti altre funzionalità di supporto che pur non essen-do indispensabili nella gestione della stima possono costituire un aiuto moltovalido specialmente per gli utenti esperti.

7.5.1 Gestione delle sessioni da conservarePoiché ESSE consente il salvataggio, la ricerca e il caricamento delle sessioni distima, l’utente può rivedere e modificare una sessione conservata ma anche co-struire una nuova stima ritagliando e incollando (cut & paste) progetti già stimati.Le stime vengono memorizzate non solo col nome specifico, ma anche con lechiavi relative alle loro informazioni generali.

160 ESSE

7.5.2 Gestione diretta dei FP e KLOCSIl sistema consente all’utente “esperto” di usufruire del modulo “gestione deiFunction Point” per definire direttamente i “parametri dimensionali” avvalendosidella tabella delle entità di Albrecht (vedi Capitolo 5).È consentito all’utente di introdurre per ciascun “foglio terminale” della strut-tura dell’applicazione il numero delle istruzioni in KLOC; tale funzione permetteall’utente di assegnare direttamente il numero di istruzioni (KLOC), piuttosto chefar calcolare dal sistema il valore relativo attraverso i parametri dimensionali.

7.5.3 Gestione dei risultati delle stimeOltre a permettere di stampare in qualsiasi momento tabelle e grafici relativi al-l’esito della stima, ESSE dispone di un modulo di export che consente di memo-rizzare i risultati in un formato semplice su un file. Tale file potrà essere letto daiprincipali pacchetti (Word, Excel, Lotus, ...) e rielaborato a piacere.

7.6 Esperienze con ESSEPur evidenziando alcune lacune, ESSE è stato e continua a essere utilizzato in unadecina di realtà: aziende private di produzione e di servizi, aziende pubblichestatali e regionali, strutture universitarie di ricerca e di controllo.Qui di seguito riportiamo due delle esperienze più interessanti.

7.6.1 ESSE in una grande azienda assicurativaL’applicazione forse più significativa di ESSE, che ha coinvolto il maggior nume-ro di utenti, è stata implementata nell’ambito della divisione informatica di unacompagnia di assicurazione, di rilevante importanza a livello nazionale, che ge-stisce un volume di software pari a circa 50 miliardi di lire all’anno.Inizialmente ESSE è stato introdotto nell’istituto con l’obiettivo di valutare ilpatrimonio SW esistente, benché la sua caratteristica non fosse specificamenteadeguata a tale scopo. In fase di elaborazione però ESSE ha dimostrato la vali-dità della sua metodologia non solo per quanto riguarda le stime a priori maanche per l’ottimo approccio alle valutazioni a posteriori. Considerate quindil’efficacia e la praticità dello strumento la direzione della struttura informatica havoluto che tutti i capi progetto e analisti della divisione (circa 30 persone) fosseroaddestrati alla metodologia ESSE e al suo utilizzo. Approfittando del momentodi transizione dell’azienda (l’istituto ha modificato la sua ragione sociale inquanto da una struttura a partecipazione pubblica è divenuta una compagniaprivata), la direzione ha imposto l’adozione della metodologia ESSE nel ciclodi sviluppo del software. L’operazione ha avuto tale successo che dalla strut-tura stessa è pervenuta la richiesta di utilizzare lo strumento integrandolo nella

ESSE 161

fase di pianificazione iniziale delle attività e quindi usufruendo direttamente deirisultati dello sforzo stimati da ESSE.L’ulteriore utilizzo, creato per quella specifica esperienza, ha portato allo svilup-po di un nuovo pacchetto battezzato con il nome di ESSE2PRJ (ESSE toPRoJect).ESSE2PRJ si pone l’obiettivo di definire una pianificazione delle attività princi-pali di sviluppo utilizzando lo sforzo necessario per ciascuna fase e la durata delprogetto entrambi stimabili da ESSE. Le attività principali, all’interno di ciascunafase di sviluppo, possono essere predefinite per categorie di progetti. ESSE2PRJoffre anche la possibilità di essere utilizzato autonomamente qualora si vogliaattingere ai dati dello sforzo e della durata del progetto da altre fonti. InfineESSE2PRJ si interfaccia con la maggior parte degli strumenti di pianificazionepresenti sul mercato (MS PROJECT, SUPER PROJECT ecc.) e propone il dia-gramma Gantt delle attività su cui l’utente può intervenire per eventuali corre-zioni e/o aggiornamenti.L’esperienza dell’azienda assicurativa, oltre a confermare l’applicabilità dell’ap-proccio in diversi contesti, ha dimostrato ancora una volta che l’introduzione diuna simile metodologia non è facilmente accettata a meno che non sia decisamen-te sostenuta dalla direzione. Una volta superate le perplessità iniziali però se lostrumento è valido, sarà la base a esigere l’utilizzo e gli eventuali ampliamenti.

7.6.2 ESSE in un istituto di creditoIn questo secondo caso ESSE è stato richiesto per permettere ai capi progettodella divisione informatica di valutare a priori la stima dei costi di nuovi proget-ti, cioè in linea con le caratteristiche primarie del pacchetto. La principale diffi-coltà incontrata è stata quella di recepire il più possibile le metodologie in uso giàadottate nell’istituto per l’analisi iniziale dei progetti di informatica. Ciò ha im-posto di costruire, insieme agli esperti delle metodologie dell’azienda, un manualedi utilizzo ad hoc, in modo da permettere agli addetti alle stime di utilizzare ladefinizione dell’insieme di informazioni necessarie a ESSE in armonia con glistrumenti esistenti.Pur con diverse difficoltà di natura culturale, poiché la direzione non ha volutoin questo caso modificare le metodologie aziendali di analisi, anche questa ope-razione ha conseguito risultati soddisfacenti, ma ha comunque messo in evidenzauna lacuna di ESSE: lo strumento non prevede infatti la capacità di acquisiredirettamente informazioni necessarie (almeno in parte) nel calcolo della stima deicosti del software, da una metodologia di analisi (per esempio Data Flow Diagramoppure Entity Relationship analysis).In questa esperienza è stata riscontrata inoltre l’esigenza di possedere un moduloper calibrare il “modello ESSE”, per cui è stata sviluppata una procedura che

162 ESSE

permette all’utente esperto di modificare (sotto le proprie responsabilità) il pesodei parametri che costituiscono la base di conoscenza del sistema. Il passosuccesivo è quello di integrare tale modulo in una procedura che elaborando i datidei consuntivi dei progetti stimati e sulla base delle regole e di un’analisi di sen-sibilità dei parametri che maggiormente hanno influenzato l’andamento di pro-getti simili, proponga autonomamente un set di pesi più adatti per i nuovi progettida stimare.

Il pacchetto ESSE

Istruzioni per l’installazione ed esecuzionedel pacchetto ESSE (versione dimostrativa)Il pacchetto ESSE1 è stato sviluppato in ambiente PC sotto MS-DOS, utilizzan-do uno shell di sviluppo di sistemi esperti (ART/IM-PC) della InferenceCorporation. È comunque possibile eseguire il programma partendo anche daambiente Windows (3.1 oppure ‘95), seguendo le istruzioni riportate di seguito.

1. Requisiti di sistema: l’installazione completa richiede circa 2,3 MB di spa-zio su disco, almeno 4 MB di memoria RAM, processore 386 (consigliato486) o superiore, MS-DOS 3.3 o superiore, mouse (consigliato).

2. Installazione: inserire il midisco nell’unità A e senza copiare nulla sul discofisso eseguire (run) il file:

Install.bat

Verrà creata direttamente, sotto la directory principale del disco fisso, unanuova directory essedemo (c:\essedemo). Tutti i file necessari per l’esecu-zione del programma ESSE verranno automaticamente creati e posizionatisotto la directory essedemo.

1 ESSE è un prodotto programma della HELP S.p.A.Per qualsiasi informazione su ESSE rivolgersi a:HELP S.p.A. Auditing InformaticoVia Antonio D’Achiardi, 31, 00158 RomaTelefono 06-41733359/60Fax 06-41733406

166 Il pacchetto ESSE

3. Disinstallazione: per l’eventuale rimozione è sufficiente cancellare (delete)semplicemente la directory essedemo dal disco fisso.

4. Impostazioni in ambiente DOS: prima di eseguire l’applicativo ESSE accer-tarsi che non sia attivo alcun gestore di memoria espansa, quale per esem-pio EMM386. Eventualmente, modificare opportunamente il fileCONFIG.SYS e riavviare il computer.Verificare inoltre che sia attivo il software di gestione del mouse.

5 Esecuzione in ambiente DOS: sotto la directory essedemo eseguire (run) ilfile:

demo.exe

6. Esecuzione in ambiente Windows 95: è sufficiente eseguire (run-doppioclick) l’icona (a forma di capitello) essedemo\Demo.

Il pacchetto ESSE 167

Bibliografia

1 Abdel-Hamid T., Madnik S.E., Software Project Dynamics - An IntegratedApproach. Prentice Hall Software series, Englewood Cliffs N.Y., 1991.

2 Abdel-Hamid T., Adapting, Correcting and Perfecting Software Estimates: Amaintance Metaphor. IEEE Computer, Mar. 1993.

3 Albrecht A.J., Measuring Application Development Productivity. Proc. of theIBM Applications Developments Symposium, GUIDE/SHARE, Oct. 1979.

4 Albrecht A.J., Gaffney J., Software Function, Source Lines of Code, and De-velopment Effort Prediction: a Software Science Validation. IEEE Trans, SwEng. SE-9,6 Nov. 1983.

5 Bailey J.W., Basili V.R., A Meta-model for Sw Development Resource Expendi-ture. Proceedings 5th International Conference on Sw Engineering, 1981.

6 Barstow D. R., Knowledge-Based Program Construction. North Holland,New York, 1979.

7 Behrens C.A., Measuring the productivity of computer systems developmentactivities with Function Points. IEEE Trans. Sw Eng. SE-9,6, Nov. 1983.

8 Bobrow D.G., Winograd T. S., An overview of KRL, a Knowledge Rapre-sentation Language. Cognitive science, Vol. 1, No. 1,1977.

9 Boehm B.W., Software Engineering Economics. Prentice Hall, EnglewoodCliffs N.J., 1981.

10 Boehm, B.W., Software Life Cycle Factors. Handbook of SW Engineering,1984.

11 Boehm B.W., Improving Software Productivity. Computer, Sep. 1987.12 Boehm B.W., A spiral model of software development and enhancement.

ACM SIGSOFT Software Eng. Notes, vol 11. N. 4, Aug. 1986: reprinted inComputer, vol. 21, n. 5, May 1988.

13 Brooks F. P., The Mythical Man-Month. Reading Addison-Wesley, Mass., 1975.

182 Bibliografia

14 Brownston L., Farrell R., Kant E., Martin N., Programming Expert Systemsin OPS5. Reading Addison-Wesley, Mass.

15 Cammarata Silvio, Sistemi Esperti teoria, metodi, strumenti tecnici. EtasLibri.

16 Case D., Productivity in the University-Scholarly work as information work.Proc. Amer. Soc. Inform. Sci., vol. 20, 1983.

17 Conte S., Dunsmore H., Shen V.Y., Software Engineering Matrics & Mod-els. Benjaming/Cummings, Menlo Park Calif., 1986.

18 Cote’ V., Bourque P., Oligny S., Rivard N., Software Metrics - An Overviewof Recent Results. Journal of Systems and Sw, 8, 1988.

19 Cowderoy A., Jenkins J., Levy Z., State of the art survey, Vol. - Effort and SizeEstimation Models. ESPRIT project PO246. MERMAID Feb. 1989.

20 Curtis B., Software Metrics: Guest Editor’s Introduction. IEEE Trans. SwEng. SE-9,6, Nov. 1983.

21 Davis Alan M., Senior Member, IEEE, Edward H. Bersoff, Senior Member,IEEE, and Edward R. Comer, Member, IEEE. A Strategy for Company Al-ternative Software Development Life Cycle Models. IEEE Transactions onSoftware Engineering, Vol. 14, N. 10, Oct. 1988.

22 Davis R., King J.J., An overview of Production System. Machine Intelligence,8, E.Elcock & D. Michie Editors, Horwood Chichester, England, 1977.

23 Davis R., Buchanan B.G., Shortliffe E.H., Production Rule as a Representa-tion for a Knowledge-based Consultation program. Artificial Intelligence, Vol.8, No.1, 1977.

24 DeMarco T., Controlling Software Projects. Yourdon Press, N.Y., 1982.25 Deutsch Michael S., Software Verification and Validation, Realistic Project

Approaches Prentice-Hill, Englewood Cliffs, N.J.26 Doerflinger C.W., Basili V.R., Monitoring Sw Development through Dynamic

Variables. Proc. IEEE Conference on Computer Sw and Applications(COMPSAC), 1983.

27 Doty D.L., Nelson P. J., Steward K.R., Software Cost Estimation Study:Guidelines for Improved Software Cost Estimating. Technical Report RADC-TR-77-220, Vol. II. Rome Air Development Center, Aug. 1977.

28 Fairley R.E., Recent Advances in Software Estimation Techniques -Procedings of the 14th International Conference on Software Engineering,IEEE, 1992

29 Farr L., Zagorski H.J., Quantitative analysis of programming costs factors: aprogress report. In ICC Symposium Proceedings on Economics of AutomaticData Processing, edited by A. B. Frieling, Amsterdam North-Holland, 1965.

30 Forrester J.W., Industrial Dynamics. The M.I.T. Press, Cambridge MA,1961.

31 Forrester J.W., Principles of Systems. M.I.T. Productivity Press, Cambridge

Bibliografia 183

Mass., 1971 (Traduzione italiano, Principi dei Sistemi. Etas Libri, Milano,1974).

32 Forrester J.W., System Dynamics - Future Opportunities. D-3108-1, July1979.

33 Freiman F.R., Park R.E., PRICE software model - version 3: an overview.Proceedings of the IEEE-PINY Workshop on Quantitative Software Mod-els, Oct. 1979.

34 Ghezzi C., Fuggetta A., Morasca S., Morzenti A. , Pezze M. , Ingegneria delSoftware. Progettazione, Sviluppo e Verifica Mondadori Informatica, 1991.

35 Grady R.B., Caswell D.L., Software Metrics: Establishing a Company-wideProgram. Prentice-Hall Inc., Englewood Cliffs New Jersey, 1987.

36 Gomaa H. Scott, Prototyping as a tool in the specification of user require-ments. In Proc. Eth IEEE Int. Conf. Software Eng., Mar. 1981.

37 Halstead M.H., Elements of Sw Science. Elsevier, North-Holland, 1977.38 Hamer P.G., Frewin G.D., M.H. Halstead’s Sw Science: a critical examina-

tion. Proc. 6th International Conf. on Sw Engineering, 1982.39 Help S.p.A., ESSE - User Manual, Roma, Nov. 1992.40 Herd J.R., Postak J.N., Russell W.E., Steward K.R. Software cost estimation

study - study results. Final Technical Report.RADC-TR-77-220, Doty Asso-ciates Inc., Rockvill MD June 1977.

41 Hirayama Masayuki, Sato Hiroyuki, Yamada Atushi, Tsuda Junichiro. Prac-tice of quality modeling and measurement on software life-cycle. Toshiba Cor-poration, Systems & Software Engineering Laboratory.

42 ISO 9000-3-UNI EN 29003, Norme di gestione per la qualità e diassicurazione della qualità - Guida per l’applicazione della ISO 9001 allosviluppo, alla fornitura e alla manutenzione del software.

43 ISO 9001-UNI EN 29001, Norma Italiana di Sistemi Qualità - Modello perl’assicurazione della qualità nella progettazione, sviluppo, fabbricazione,installazione e assistena.

44 ISO 9002-UNI EN 29002, Norma Italiana di Sistemi Qualità - Modello perl’assicurazione della qualità nella progettazione, sviluppo, fabbricazione,installazione e assistena.

45 ISO 9003-UNI EN 29003, Norma Italiana di Sistema Qualità - Modello perl’assicurazione della qualità nella ispezione e test.

46 Jeffery D.R., A Sw development productivity model for MIS environments.Journal of Systems and Sw, Jun. 1987.

47 Jensen R.W., A comparison of the Jensen and COCOMO schedule and costestimation models. Proceedings of International Society of ParametricAnalysis, 1984.

48 Jones C., Measuring Programming Quality and Productivity. IBM SystemsJournal, vol. 17 IBM Corporation, no. 1, Armonk, N.Y.1978.

184 Bibliografia

49 Jones C., Programming Productivity. McGraw Hill, New York, 1986.50 Jones C., Applied Software Measurement, Assuring Productivity and Qual-

ity, McGraw Hill Inc., 1991.51 Kemerer C.F., An Empirical Validation of Sw Cost Estimation Models.

Comm. of the ACM, May 1987.52 Kitchenham B., Jaggers C., State of the art survey, Vol.2: Software Metrics.

ESPRIT project P0246: MERMAID Feb. 1989.53 Kitchenham B., Walker J.G., Monitoring Sw Development. SEJ, 1989.54 Kitchenham B., Känsälä K., Inter-item Correlations among Function Points,

Proceedings of the 15th International Conference on Software EngineeringIEEE, 1993.

55 Kowalski R., Logic for Problem Solving. Amsterdam: North Holland, 1979.56 Kustanowitz A.L., System Life Cycle Estimation (Slice) - A New Approache

to Estimating Resources for Application Program Development. COMPSAC,1977.

57 Lenat D.B., Heuretics: the nature of Heuristics. Artificial Intelligence, Vol.19 No. 2, Oct. 1982.

58 Low G.C., Jeffery D.R., Function Points in the Estimation and Evaluation ofthe Sw Process. IEEE Trans. Sw Eng. SE-16,1, Jan. 1990.

59 Magee S., ISO/IEC Software Life Cycle Standard 12207. DataPro Manage-ment of Applications Software, Delran NJ, Feb. 1995.

60 McCabe T.J., A complexity Measure. IEEE Trans, Sw Eng. SE-2, Dec. 1976.61 McCracken D., M. Jackson, Life cycle concept considered harmful, ACM

SIGSOFT Software Eng. Notes vol. 7 n. 2, Apr. 1982.62 Myers G.J., Software Reliability: Principles and Practices. John Wiley & Sons

Inc., New York, 1976.63 Nelsen E.A., Management Handbook for the Estimation of Computer Pro-

gramming Costs. AD-A648750, System Development Corporation, SantaMonica Ca., Oct. 1966.

64 Parnas D.L., Can automatic programming solve the SDI software problem?,in Software aspects of strategic defense system. Amer. Sci., vol. 73, Sept.-Oct.1985.

65 Partsch H., Steinbrugg‰n R., Program transformation systems. ACMComput Surveys, vol. 15, no. 3, Sept. 1983.

66 Putnam L.H., A general empirical solution to the macro Sw sizing and esti-mating problem. IEEE Trans. Sw Eng. SE-4,4, July 1978.

67 Ragland R., International Function Points User Group (IFPUG), FunctionPoint Counting Practices Manual Release 4.0, Jan. 1994.

68 Raphael B., A Computer Program for Sematic Information Retrivial. C.Sematic Information Processing. M. Minsky editor MIT Press, CambridgeMass., 1968.

Bibliografia 185

69 Rice R.E., Bair J., Conceptual role of new communication technology in or-ganizational productivity. Proc. Amer. Soc. Inform. Sci., vol. 20, 1983.

70 Royce W.W. Managing the development of Large Sw Systems: Concepts &Techniques. Proceedings, WESCON, Aug. 1970.

71 Rubin H. A., Macro-Estimation of software development parameters: theEstimacs System, IEEE, New York, 1983.

72 Rubin H.A., The Art and Science of Software Estimation: Fifth generation Es-timators. Journal fo Parametrics. Vol.5 No2, June 1985.

73 Rubin H.A., A Comparison of cost estimation tools (a panel session), IEEE,New York, 1985.

74 Rudolph E.E., Productivity in computer application development. Dep. Man-agement Studies, Univ. Auckland Australia, 1983.

75 Sedehi H., Biader Ceipidor U., Capezzone S., An Expert System for Softwarecost Estimation: ESSE, EXPERSYS-91 Expert Systems Applications. IITT-In-ternational, 1991.

76 Smith C. P., A Software Science analysis of programming size. Proceedings ofthe ACM National Computer Conference Oct. 1980.

77 Stefik M., Planning and Meta-Planning. MOLGEN: Part 2. Artificial Intel-ligence, Vol. 16, No.2, 1981.

78 Symons C.R., Function Point Analysis: Difficulties and Improvements. IEEETrans. Sw Eng. SE-14,1 Jan. 1988.

79 Tsiouras I., La norma ISO 9001 e l’approccio della Qualità totale nel Software.Rivista Qualità, Giugno 1995.

80 Verner J., Tate G., Estimating Size and Effort in Fourth-Generation Devel-opment. IEEE Software July 1988.

81 Walston C.E., Felix C.P., A method of programming measurement and esti-mation. IBM Syst. Jan. 1977.

82 Warren D.H.D., Pereira L.M., Prolog- The Language and Its ImplementationCompared to Lisp. Symposium on Artificial Intelligence and ProgrammingLanguages. SIGPLAN Notis 12(8) and SIGART Newsletter 64, 1977.

83 Waterman D.A., A guide to Expert System. Reading Addison-Wesley, Mass.,1985.

84 Weinwurm G.F., On the Management of Computer Programming.Auerbach, New York, 1970.

85 Winston P.H., Horn K.P., Lisp. 2nd ed. Reading Addison-Wesley, Mass.,1984.

86 Wolverton R.W., The cost of developing large-scale software. IEEE Transac-tion on Software Engineering, June 1975.

87 Zwanzig K., Handbook for Estimating Using Function Points. GUIDEProject DP-1234 GUIDE Int., Nov. 1984.

Indice analitico

AAcquisizione

della conoscenza, 120, 135processo di, 17-18

Adjusted Feature Point, 111Affidabilità, 36, 46Affidabilità del software, 42-43Analisi di qualità, 9Assistenza (costo di), 30Avviamento (costo di), 30

BBackward chaining, 123, 125, 141Benefici del software, 27Brook (legge di), 62

CCalibrazione, 45, 65Caratteristiche di qualità, 46Caratteristiche Generali del Sistema (CGS), 101-102,

107Certificazione di qualità, 13, 17, 24CGS, 101-102, 107Ciclo di vita

a cascata (Waterfall), 2, 5, 7processo di acquisizione, 17-18processo di fornitura, 17, 19processo di manutenzione, 17, 22processo di operazioni, 17, 22processo di sviluppo, 17, 19produzione automatica, 6, 8prototipazione evolutiva, 6, 8prototipazione rapida, 6, 8software, 1, 17Waterfall incrementale, 6-7

CMM, 15-17

COCOMO, 82, 85, 115-116, 144Cost Driver, 65, 82, 85-87, 91, 93fortemente strutturato (Embedded), 87-90, 94istruzioni, 86, 90KDSI, 86, 96mediamente strutturato (Semidetached mode),

89-90, 92, 96modalità di sviluppo, 88modello base, 87, 89modello dettagliato, 87, 92poco strutturato, (Organic mode), 88, 90, 92,

96sforzo, 86, 90, 96tempo di sviluppo, 90

Codicedimensione, 44DSI, 79, 86eseguibile, 51JCL, 51, 86, 104KLOC, 79, 146-147, 149, 160SLOC, 50-51, 72, 79sorgente, 3

Coefficiente di multipla determinazione, 66, 67Complessità (di sistema), 1, 12Complessità di dati, 110Comprensibilità, 12Configurazione di sistema, 2Controllo (interfaccia di), 9Controllo di stima, 58Costo

assistenza, 30avviamento, 30formazione, 30hardware, 27pacchetti, 27software applicativo, 29software di base, 27sviluppo, 27

Costo del software, 27, 38Costo del software (SCS-SCE), 2, 26, 51, 54, 57, 64,

130-132, 137, 140Curva di Rayleigh, 55, 78

188 Ingegneria economica del software

DData base

difetti, 37-38misure, 37, 62, 65, 109

Difetti del software, 38, 41Dimensione del software, 44, 54Dinamica dei sistemi, 113Disegno

architetturale, 3, 20di dettaglio, 3, 5, 21sistema, 2

Documentazione, 5, 20, 24DSI, 79, 86

EEconomia del software, 27Efficienza, 46-47Elicitazione, 119, 135, 137Errore relativo assoluto medio, 66-67Errore relativo medio, 66-67Errori (tipologia), 11ESQUT, 12ESSE, 83, 131, 135, 137, 140, 144

ART, 123, 140base di conoscenza, 12base di dati, 145costi di personale, 146, 158Data Flow Diagram, 162Default statistici e dinamici, 157Entity- Relationship analysis, 162ereditarietà dei parametri, 155esperienze, 160-161ESS2PRJ, 161figure professionali, 158gestione dei risultati, 145, 158, 160informazioni generali, 146-147interfaccia utente, 141parametri correttivi, 146, 148, 152, 155parametri dimensionali (Sizing), 146, 148ripartizione dello sforzo, 146, 158sistema dimostrativo, 148spiegazione, 143, 159struttura dell’applicazione, 146, 148Warning, 156What if analysis, 143

ESTIMACS, 108Euristica, 129

FFattori di qualità, 42, 43Feature Point, 110

Adjusted Feature Point, 111Complessità di dati, 112Fattore Corretivo di Complessità, 110-112Unadjusted Feature Point, 110

File di interfaccia, 97, 99File logici interi, 97, 99Formazione (costo della), 30Fornitura (processo di), 17, 19Forward chaining, 123, 125, 141Frame, 123, 133, 156Function Points (punti funzione), 38, 96, 103-104,

109, 144, 160Caratteristiche Generali del Sistema (CGS),

101-102, 107file di interfaccia, 97, 99file logici interi, 97, 99input esterni, 97, 100inquiry esterne, 97, 100Limiti, 107output esterni, 97, 101Unadjusted Function Points (UFP), 99, 101Valore del Fattore di Correzione (VFC), 102

Funzionalità, 12, 46, 82Funzionalità di sistema, 4, 12

GGestione del software, 37, 59

HHalstead (metrica di), 11-12Halstead (modelli di stima), 75, 78Hardware (costo del), 27

IIndici di qualità, 17Ingegneria del software, 1-2, 5, 24, 39, 42, 59, 61Ingegneria della conoscenza, 119Input esterni, 97, 100Inquiry esterne, 97, 100Intelligenza artificiale, 119Interfaccia di controllo, 9ISO

12207, 239000-1, 139000-3, 149001, 13, 149002, 139003, 13, 149004-1, 139004-2, 139126, 46, 47

ISO 9000, 13, 17

Indice analitico 189

Ispezione del software, 9Istruzioni

condizionanti, 11di puntamento, 11

JJCL, 51, 86, 104Jensen (modelli di stima), 75, 81

KKDSI, 86, 96KLOC, 79, 146-147, 149, 160Knowledge base system, 128, 157

LLegge di Brook, 62Linguaggio

di programmazione, 2, 71, 104espressività, 35, 50, 105

LISP, 122-124, 141

MManutenibilità, 46, 48Manutenibilità del software, 42-43Manutenzione, 5, 22Manutenzione (di sistema), 5Manutenzione (processo di), 17, 22McCabe (metrica di), 11, 12Metodi di stima, 64Metrica

basiche, 50calcolate, 50di elaborazione, 49, 54di input, 49, 50di output, 49, 54Halstead, 11, 12importanza, 33McCabe, 11-12qualità, 42, 45, 49Software Science Metrics, 50

Misureconsuntivi dei progetti, 40costi arretrati, 40dell’opinione, 41demografiche aziendali, 41difetti, 41fattori “soft”, 41operazionali, 40produttività, 35progettuali, 40soddisfazione dell’utente, 40

Misura della qualità, 9

Modelli di stima, 69, 72composti, 69, 82curva di Rayleigh, 55, 78ESTIMACS, 108Halstead, 75, 78Jensen, 75, 81PRICE-S, 82Putnam, 75, 80, 82SLIM, 80statistici, 69-70, 72storico-empirici, 69, 72teorici, 69, 75

Modelli algoritmici di stima, 64-65Modello

ad hoc, 65algoritmico, 65calibrazione, 45, 65

Monitoraggio del software, 19Monitoraggio, 19, 126

OObiettivi (di sistema), 4Oggettività di stima, 66Operatori

di procedure, 11ESQUT, 12

Operazioni (processo di), 17, 22Output esterni, 97, 101

PPacchetti (costo dei), 27Pattern recognition, 128PDCA, 15, 16Portabilità del software, 42-43Portabilità, 46, 48Predizione a livello r, 66, 68PRICE-S, 82Procedure (operatori di), 11Processo

di acquisizione, 17, 18di fornitura, 17, 19di manutenzione, 17, 22di operazioni, 17, 22di sviluppo, 17, 19

Produttività, 38, 51, 82misure, 35, 51sviluppo, 60

Produttività (misure di), 35software, 38-40

Produttività del software, 38, 60Produzione automatica, 6, 8Programmazione (linguaggio di), 2, 71, 104Prolog, 122

190 Ingegneria economica del software

Prototipazione evolutiva, 6, 8Prototipazione rapida, 6, 8Puntamento (errori di), 11Punti funzione, vedi Function PointsPutnam (modelli di stima), 75, 80, 82

QQualità

affidabilità, 46analisi, 9assicurazione, 23caratteristiche, 46certificazione, 13certificazione, 13, 23CMM, 15-17complessità, 12, 82comprensibilità, 12del processo, 17efficienza, 46-47fattori, 42-43funzionalità, 46indici, 17ISO 9000, 13, 17manutenibilità, 46, 48misura, 9misurabile, 42PDCA, 15, 16portabilità, 46, 48predicibile, 42prodotti, 11Quality Assurance Institute, 42SEI, 15, 17standard, 11usabilità, 46-47valutazione, 15-16

Qualità del software, 11, 13-14, 45, 49Quality Assurance Institute, 42

RRappresentazione della conoscenza, 131, 133Rayleigh (curva di), 55, 78Requisiti

sistema, 2, 4, 20utente, 2-3verifica, 9

Requisiti (di sistema), 4, 20Robustezza del software, 42-43Robustezza, 66

SSEI, 15, 17Semplicità del software, 42-43Shell, 122-124

Sistemacomplessità, 1, 12comprensibilità, 12configurazione, 2disegno, 2funzionalità, 4, 12manutenzione, 5obiettivi, 4requisiti, 2, 4, 19

Sistemi esperti, 119campi di applicazione, 125regole, 134, 136strumenti di sviluppo, 120-121

SLIM, 78SLOC, 50-51, 72, 79Software

affidabilità, 42-43benefici, 27costi, 27, 38difetti, 38, 41dimensione, 44, 54economia, 27gestione, 37, 59ingegneria, 1-2, 5, 23, 37, 42, 59, 61ispezione (Walk Through), 9manutenibilità, 42-43monitoraggio, 18portabilità, 42-43produttività, 38, 60qualità, 11, 13-14, 45, 49robustezza, 42-43semplicità, 42-43sviluppo, 1, 20, 27, 29validazione, 9, 24verifica, 9-10, 24

Software (ciclo di vita), 1, 17Software (misure del), 38-40Software applicativo (costo del), 29Software di base (costo del), 27Software Project Dynamics, 114Sottostima, 29-31, 57, 61Sovrastima, 29, 57, 81Standard di qualità, 11Stima

coefficiente di multipla determinazione, 66-67conseguenze economiche, 61conseguenze manageriali, 61conseguenze tecniche, 61controllo, 58costi del software (SCS-SCE), 2, 28, 51, 54, 57,

64, 130-132, 137, 140criteri di valutazione, 66curva di Rayleigh, 55, 78del valore, 37difficoltà, 62errore relativo assoluto medio, 66-67errore relativo medio, 66-67facilità d’uso, 66

Indice analitico 191

giudizio di esperti, 64importanza, 58metodi, 64modelli algoritmici, 64-65oggettività, 66per analogia, 64, 132predizione a livello r, 66, 68problemi, 31robustezza, 66sottostima, 29-31, 57, 61sovrastima, 29, 57, 81trasportabilità, 66validità, 66valore medio relativo della deviazione standard,

66, 68Sviluppo (costo di), 27Sviluppo (processo di), 17, 19Sviluppo del software, 1, 20, 27, 29

TTest

accettazione, 22fase, 11globale, 4indici, 11modulo, 3piano, 2

Trasportabilità, 66

UUFP, 99, 101Unadjusted Feature Point, 110Unadjusted Function Points (UFP), 99, 101Usabilità, 46-47

VValidazione del software, 9, 24Validità di stima 1, 66Valore del Fattore di Correzione (VFC), 102Valore medio relativo della deviazione standard, 66,

68Verifica (requisiti di), 9Verifica del software, 9-10, 24VFC, 102

WWalk Through, 9Waterfall (ciclo di vita), 2, 5, 7Waterfall incrementale, 6-7

Autore: Habib Sedehi - Programmazione, web marketing ... · 1.1.3 Disegno del sistema 2 1.1.4...

Documents

Transcript of Autore: Habib Sedehi - Programmazione, web marketing ... · 1.1.3 Disegno del sistema 2 1.1.4...