La difficile professione

dellingegnere del software

di: Paolo De Nictolis
pubblicato il: 18/06/2006

Introduzione
Questo articolo nasce dalla lettura del testo Principi di ingegneria del software quarta edizione di Roger
S. Pressman, edito in Italia da McGraw-Hill
(http://www.programmazione.it/index.php?entity=eitem&idItem=33643). Dopo aver finito di studiarlo, m i
sono reso conto che la mole di considerazioni ed appunti che avevo raccolto non poteva esaurirsi nello
spazio di una, per forza di cose sintetica, recensione; ed cos nato questo lavoro. Troverete in esso
continui riferimenti al testo stesso, che ritengo una lettura obbligata per chiunque sia coinvolto, a qualsiasi
titolo, in un progetto software.
Nellattivit professionale il termine ingegnere del software ha sostituito il termine programmatore: una
delle prime frasi della quarta edizione italiana (traduzione della sesta edizione inglese) del Pressman ma,
purtroppo, unaffermazione cui si potrebbero trovare molti controesempi nelle piccole realt del software
nostrano, alle quali gioverebbe molto la lettura di unottima (ed in molti capitoli semplice) panoramica
introduttiva come questa.

Il processo di sviluppo software

Il Pressman ricco di citazioni, che illuminano la lettura. Dal canto mio, non posso che ricordare la mie
preferite, quelle di Brooks: Aggiungere persone a un progetto software in ritardo lo rallenta ulteriormente;
Einstein sosteneva che deve esistere una spiegazione semplice della natura, perch Dio non n
capriccioso n arbitrario. Purtroppo lingegnere software non pu essere sostenuto da questa fede: molte
delle complessit che si trova a gestire sono di tipo arbitrario. In quelle giornate un p cos (per lingegnere
del software, una su tre), ci viene in soccorso Steve Wozniak: Mai fidarsi di un computer che non puoi
lanciare fuori da una finestra.
Leggendo il testo, sarebbe il caso di soffermarsi sul paragrafo 1.5, I miti del software: fra management,
committente e programmatore, non si salva davvero nessuno. Ognuno reciti il proprio mea culpa (mi sono
riconosciuto, agli inizi della mia carriera, in ogni mito del programmatore: il lavoro finito una volta rilasciato
il programma, che lunico frutto del lavoro svolto, mentre la documentazione serve a dare lavoro agli
incapaci, ecc.), ma quando leggo i miti sui volumi di standard e procedure che gi abbiamo, sullorda
mongola, sulloutsourcing totale e, soprattutto, sui mutamenti che si gestiscono agevolmente grazie alla
flessibilit del software (cui aggiungerei la citazione di Paulk: molto spesso i dirigenti ritengono che sia
meglio avere qualcosa di sbagliato piuttosto che in ritardo, poich si pu sempre correggere il software in un
secondo tempo), mi tornano in mente, con un ghigno sarcastico e doloroso, tante scenette del mio lungo
film di architetto (Se ti chiedessimo di cambiare le fondamenta ad un palazzo di cui hai gi fatto dieci piani
lo voglio capire che un lavoro che ti richiede tempo, ma mi spieghi perch ci vogliono tre mesi per rifare la
reportistica? Credi che abbia lanello al naso? Lo sanno tutti che con i moderni IDE generate il codice
premendo un bottone!!!). Nelle prime pagine del secondo capitolo trovo unaltra frase che mi piace molto, il
processo che si adotta dipende dal software che si sta realizzando.
Che per progettare la cuccia del cane serve un metro flessibile e per progettare un grattacielo serve uno
studio di architettura lo sanno pi o meno tutti, mentre molte figure dirigenziali, quando escono i modelli
ciclici, il RUP, le metodologie agili e la programmazione Aspect-Oriented, devono appiccicare un bollino alla
quarta revisione del gestionale ed al primo sito Web trionfalmente varato dalle quattro stanze prese in affitto
. ehm, dalla software house. Tornando al testo, nella panoramica iniziale sul processo di sviluppo
software non pu non trovare posto il meta-modello CMMI (http://www.sei.cmu.edu/cmmi/), nel suo duplice

1 di 16
aspetto di modello continuo ed a fasi. Non si pu sbrigare il CMMI in qualche pagina, ma al di l del
diventare esperti del meta-modello, occorrerebbe appiccicare da qualche parte sul muro il contenuto del box
Il CMMI: che cosa fare e che cosa evitare. Certo, una volta adottato un processo, bisognerebbe adottare
anche un approccio di valutazione del medesimo come quelli descritti nel paragrafo 2.5, possibilmente
tentando di non ridurre per esempio la ISO 9001:2000 alla cosa che ci serve per partecipare alle gare, o di
far credere in giro che abbiamo il marchio ISO 9001:2000, la ISO 9126 la facciamo automaticamente. Per
le software house nostrane esistono addirittura i processi personali e di team, pi o meno tutti riconducibili a
tal Humphrey, tenendo presente che il miglior processo di sviluppo software quello pi adatto alle persone
che svolgeranno il lavoro: in fondo su questa base che sono state sviluppate le metodologie agili.
Prima per di arrivarvi, non dovremmo mai dimenticare i classici modelli a processo prescrittivo: a cascata,
incrementale, evolutivo, con una puntatina sul RUP (Rational Unified Process), del quale viene detto che
rappresenta un tentativo di sfruttare le migliori funzionalit e caratteristiche dei modelli convenzionali di
sviluppo software, ma caratterizzandoli in modo da implementare molti dei migliori principi dello sviluppo
agile. Un breve paragrafo anche dedicato allAspect-Oriented Programming: sostanzialmente, oltre al
rimando al classico sito http://www.aosd.net, la bibliografia fa riferimento soprattutto al prodotto AspectJ
(http://www.parc.com/research/projects/aspectj/default.html). Il RUP, grazie allimportanza dei casi duso
scritti dallutente, opera in un certo senso una rivoluzione copernicana nei processi di sviluppo, portata poi
alle estreme conseguenze dalle metodologie agili: lanalisi dei requisiti diventa una responsabilit condivisa
con il committente, piuttosto che un processo maieutico guidato dallanalista. Al di l della descrizione delle
cinque fasi, delle 4 viste + 1 e degli artefatti del processo, importante sottolineare, ancora una volta, che il
team di sviluppo adatta il processo sulla base delle proprie esigenze. Lo sviluppo agile, o ingegneria del
software leggera, la cui nascita si fa risalire al manifesto di Kent Beck e compagni del 2001
(http://www.agilemanifesto.com, anche se per esempio leXtreme Programming risale sicuramente al 1999,
secondo alcuni alla fine degli anni 80, il DSDM al 1997, e Scrum addirittura al 1996), oggetto del quarto
capitolo.
Molto si detto pro e contro questo tipo di ingegneria, che pone laccento sulla costituzione di piccoli gruppi
di progetto, sulla soddisfazione del cliente e sul rilascio incrementale di software funzionante a scapito, a
detta dei suoi detrattori, dellanalisi, della progettazione e della documentazione: in sostanza, della
soddisfazione stessa del cliente, nel lungo termine. In effetti lo stesso Cockburn, un esperto di metodologie
agili, le loda per la loro capacit di tenere conto del fattore umano nellingegneria del software (anche se a
volte si stenta a crederlo, gli sviluppatori sono esseri umani con le loro fragilit e debolezze), ma ammette al
contempo che proprio per questo possono rivelarsi meno produttive dei processi prescrittivi.
Potrei aprire qui un delicato discorso sullequilibrio domanda/offerta di lavoro nel campo dellinformatica che
determina richieste di produttivit pi o meno vicine agli standard umani, ma meglio attenersi alla
recensione del testo. Certo, mi piacerebbe conoscere il parere di Cockburn sul fatto che in Italia un
ingegnere del software o programmatore che sia di solito un laureato che segue un costante ed
impegnativo percorso di aggiornamento professionale (di solito a proprie spese dopo le dodici.... pardon,
otto ore di lavoro quotidiano), impegnato in un lavoro creativo e ad altissimo valore aggiunto, flessibile fino
allestremo ed orientato al risultato, che riceve lo stipendio di un metalmeccanico non specializzato alla
catena di montaggio.
Salomonicamente, Pressman non pu che ricordare che, come tutte le metodologie, quella agile non pu
essere applicata a tutti i progetti (lingegneria dovrebbe essere, nella sua forma migliore, il campo in cui
muoiono una volta per sempre i massimi sistemi e trovano posto i compromessi progettuali) e non
antitetica ad una solida pratica di ingegneria del software. Inoltre, afferma sempre Pressman, nessuno
contrario ai principi dellagilit (soddisfazione del cliente, risposta rapida ai cambiamenti, ecc.), ma vi
tremenda discordanza e le solite guerre di religione sul modo di applicarla: in effetti, nello stesso ambito
della scuola [i]agile[/i], sono stati proposti molti modelli a processo (Extreme Programming,
http://www.xprogramming.com; Adaptive Software Development, http://www.adaptivesd.com; Dynamic
Systems Development Method, http://www.dsdm.org; Scrum, http://www.controlchaos.com; Crystal,
http://www.crystalmethodologies.org; Feature Driven Development, http://www.thecoadletter.com; Agile
Modeling, http://www.agilemodeling.com, tutti presentati nel Paragrafo 4.3), e molti concetti della
metodologia agile non sono altro che adattamenti dei migliori concetti di ingegneria del software. Laver
posto il capitolo sulle metodologie agili praticamente allinizio del testo, ed i continui richiami in avanti ed
allindietro, testimoniano limportanza che Pressman attribuisce loro.
Personalmente, per, sebbene non metta in discussione (non lo fa nessuno) la validit di una seria e
puntuale applicazione delle metodologie agili, sono molto dubbioso in merito ai fraintendimenti ed alle
misinterpretazioni che possono ingenerare in ambienti immaturi (dal punto di vista dellingegneria del
software, of course....), sia dalla parte degli sviluppatori che (soprattutto) da quella dei clienti. Capisco che
uno dei fondamenti delle metodologie agili sia proprio quello di eliminare ogni atteggiamento di tipo noi e
loro, ma anche vero che la realt una brutta bestia quando si tratta di negarla. A mio avviso, le

2 di 16
metodologie agili forniscono straordinarie opportunit quando si verifichi una (miracolosa) congiunzione
astrale di elevate competenze fra gli stakeholder; negli altri casi, per quanto sia una prassi pedagogica poco
alla moda oggid, ritengo che i bambini hanno bisogno di disciplina. Personalmente, per esempio, ho una
grande ammirazione per il principio alla base del DSDM: quanti di noi spendono il 20% del loro tempo per
sviluppare le funzionalit effettive di un prodotto software, e l80% per renderlo usabile da un cliente che ....
beh, siccome gli eufemismi vanno di moda, diciamo non sempre un esperto di tecnologie informatiche?
Unaltra affermazione di Pressman su cui voglio richiamare lattenzione, se non altro perch nascosta in un
box, la seguente: poich lo sviluppo agile di moda, la maggior parte dei produttori di strumenti software
sostiene di fornire prodotti che supportano un approccio agile. Mutatis mutandis, una frase che ci
accompagner durante tutta la nostra (spero lunga) vita di informatici.

La pratica dellingegneria del software

Una panoramica sugli aspetti pratici dellingegneria del software non pu che essere incentrata sui due tipi di
modelli utilizzati: quelli analitici, con la loro rappresentazione del software nei tre domini delle informazioni,
funzionale e comportamentale, e quelli progettuali. Sempre con riferimento al Pressman, i capitoli della
seconda parte si occupano, in sostanza, di presentare (senza, ahim, alcuna pretesa di completezza) i
metodi e le notazioni tecniche che consentono agli ingegneri software di creare i modelli analitici e
progettuali. Il primo passo una visione ingegneristica non del solo software che si andr a sviluppare, ma
dellintero sistema (hardware, software, database, procedure, persone...) in cui andr ad inserirsi. Tutti gli
ingegneri del software (me compreso) sono degli entusiasti tecnologi, pronti ad attaccarsi allIDE ed a
produrre codice, ma se ci si precipita a realizzare gli elementi tecnologici prima di comprendere il sistema, si
commetteranno indubbiamente degli errori che faranno irritare il cliente. E senza cliente, ahim, di software
se ne sviluppa (soprattutto in Italia) davvero poco.
Naturalmente, occorre affrontare il duplice aspetto dellingegneria di processo e di prodotto. Il Capitolo 7
affronta lingegneria dei requisiti, sostanzialmente lincubo di ogni ingegnere del software. Inutile raccontarsi
per lennesima volta le barzellette sul cliente che non ha idea dei tempi e dei costi, che ha una visione
miracolistica dellingegneria del software (siete cos bravini, voi col compiuter lerrore intenzionale
fate tutto in cinque minuti) e che in conclusione il cliente della vignetta di Dilbert: Prima di cominciare a
sviluppare, dovremo fare dei lunghi incontri sul cosa sviluppare. In primo luogo: qual il tuo obiettivo? Il
mio obiettivo farti cominciare a scrivere il software. Innanzitutto, il cliente peggiore laltro tipo di cliente.
Non avete mai incontrato laltro? E il cliente che ha la Patente Europea del Computer, o un qualsiasi
attestato di formazione su Windows/Office, ed in forza di questa preziosa certificazione, di informatica ne
capisce molto pi di voi. Ma al di l del nemico cliente, vero purtroppo anche il contrario, ovvero che troppo
spesso lingegnere del software non un esperto del dominio del problema che dovrebbe risolvere. Sono pi
di quanti si pensi i casi in cui non lo nemmeno il cliente, sed transeat.
A questo si aggiungono due simpatici problemi, uno per parte. In primo luogo, la mutevolezza dei requisiti. Si
pu discutere a lungo se i requisiti che cambiano ad ogni minuto siano dovuti alla turbolenza del mercato o
alla semplicioneria del cliente, ma la continua variazione dei requisiti un dato di fatto: a volte, non si fa
nemmeno in tempo a buttare gi un documento riassuntivo, che sono gi cambiati. Questo porta al secondo
problema, stavolta dalla parte degli sviluppatori: visto che questi cambiano idea ogni momento, a che serve
perdere tempo a fare lingegneria dei requisiti?. Lingegnere del software un subdolo smanettone;
paradossalmente, il miglior amico del cliente delle barzellette, il complice entusiasta del come
pretendete che vi dica s o no sulla base delle vostre pile di carte? Datemi in mano un prodotto finito, ed io vi
dico come rifarlo daccapo. Delle sette funzioni dellingegneria dei requisiti, va a finire che la pi importante
la terza, la negoziazione. Oltre ai problemi evidenziati, non infrequente il caso di utenti differenti che
pongano requisiti in conflitto, accompagnandoli con la magica frase fondamentale per le nostre necessit.
Inutile anche chiedere al cliente la prioritizzazione dei task: sono tutti indispensabili, andavano tutti fatti
entro ieri e sono tutti troppo costosi.
Lingegneria del software lultimo residuo della schiavit nel mondo occidentale, il mondo in cui il cliente
ti mette in mano mille vecchie lire e pretende la tua incondizionata disponibilit ventiquattrore su
ventiquattro, e quella dellingegnere del software una battaglia persa in partenza. Come ogni bravo
professionista, lo sviluppatore vorrebbe essere uno specialista, vorrebbe diventare lesperto di driver in C++
per lindustria elettromeccanica piuttosto che di interfacce Web con tecnologie Java. Gli viene invece
richiesto di essere uno sviluppatore-sistemista-DBA universale, esperto riconvertibile di tutti i linguaggi e di
tutte le tecnologie, figura fungibile in tutte le fasi del ciclo di vita, consulente di tutti i possibili clienti in tutti i
possibili domini applicativi che siano mai stati inventati, oltre che team leader, commerciale ed ingegnere dei
processi di business, della qualit e di tutto ci che va di moda in giacca e cravatta. Con una particolare
propensione a fare il commerciale, ovvio, ed il tutto ad un milione-e-ottocentomila vecchie lire al mese,
come ricordato.

3 di 16
Insomma, per non divagare troppo, lingegneria dei requisiti la fase del ciclo di vita del software che ha ben
poco di informatico, e molto di umano. Il primo compito dellingegnere dei requisiti quello di individuare gli
stakeholder del progetto (possono arrivare a diverse decine) e di farli collaborare in una metaforica stanza:
non parliamo nemmeno delle metodologie agili, che si fanno un punto donore del rendere il cliente un
membro del team di sviluppo. Per frenare i conflitti uno dei metodi pi utilizzati quello dei punti di priorit: a
tutte le figure coinvolte nello sviluppo viene fornito un certo numero di punti, che possono essere spesi per i
vari requisiti. E un metodo straordinariamente semplice, e nel contempo si rivelato straordinariamente
efficace nel combattere la sindrome del tutto importantissimo, tutto va fatto subito. Ovviamente il numero
di punti da distribuire pu essere deciso in maniera arbitraria; il mio consiglio (non riportato nel libro) : date
meno punti a disposizione, di quanti siano i requisiti, e obbligate ad attribuire un numero intero di punti. Alla
fine fate una matrice requisiti-votanti, e riempite solo gli incroci che hanno ottenuto punti. Ancor prima di
esaminare i valori numerici, questa matrice vi aiuter ad individuare non solo, com ovvio, i requisiti
veramente importanti e quelli da spostare in fondo alla lista, ma anche e soprattutto le figure che hanno
visioni contrastanti del progetto, nonch quelle il cui sguardo concentrato solo su alcuni aspetti.
Dopo la fase di avvio, vi sono solo tecniche dettate dallesperienza, ma sorprendente notare come questi
insiemi di regole, dettate solo dal buon senso, siano sistematicamente ignorate da tutti gli attori coinvolti.
Lattenzione del testo si concentra sulla tecnica del QFD (Quality Function Deployment, http://www.qfdi.org),
che pone laccento nella suddivisione di requisiti in classi che generano un diverso grado di soddisfazione
del cliente. Inutile dire, infine, che una particolare enfasi posta sul modello dei casi duso. La
modellazione analitica, trattata nel Capitolo 8 ma gi introdotta nel settimo, rappresenta un ponte fra la
descrizione del sistema ed il modello progettuale; in realt talvolta difficile definire una distinzione netta fra
progettazione ed analisi, anche perch tutti gli elementi del modello analitico rimandano direttamente alle
parti del modello progettuale. La modellazione dei dati una delle attivit irrinunciabili della modellazione
analitica, quella che di solito precede tutte le altre (primo o poi dovr decidermi a recensire lultima versione
dello storico ERWin, http://www3.ca.com/solutions/Product.aspx?ID=260). La modellazione analitica con i
diagrammi UML prosegue con la creazione degli scenari, sotto forma di casi duso, diagrammi delle
attivit (Activity Diagram) e diagrammi Swimlane. Questultimo fondamentalmente un diagramma delle
attivit UML in cui viene indicato quale attore ha la responsabilit per ogni azione, suddividendo il
diagramma in una serie di segmenti paralleli verticali, come le corsie di una piscina (da cui il nome).
Ancora, la modellazione orientata al flusso di dati, tipica dellanalisi strutturata, tramite i diagrammi DFD
(Data Flow Diagram), continua ad essere una delle notazioni pi utilizzate, anche in affiancamento ai
diagrammi UML, caratteristici invece dellanalisi orientata agli oggetti. Poich esiste unampia gamma di
applicazioni pilotate da eventi anzich da dati, opportuno per essere affiancare la modellazione del flusso
di controllo a quella dei dati, tramite i consueti strumenti della specifica del controllo (CSPEC), attuata
solitamente tramite il noto diagramma stati-transizioni, della specifica procedurale (PSPEC), ed altri. La
metodologia che riscuote pi successo oggid sicuramente la modellazione basata su classi, cui viene
dedicato il resto del capitolo. E oramai invalso luso di determinare un primo elenco delle classi da una
semplice analisi grammaticale dei casi duso1, distinguendole fra classi necessarie per implementare la
soluzione (spazio della soluzione) e classi utili solo per descrivere una soluzione (spazio del problema).
In questa fase, un semplice esame dei nomi aiuta ad individuare le classi analitiche, mentre un nome
procedurale imperativo (come installa-sensore) definir un metodo di una classe, pi che una classe
stessa. Occorre poi raffinare le classi individuate introducendo attributi e metodi. Per attribuire un grado di
rilevanza alle classi individuate e scartare quelle superflue, molti team usano la modellazione CRC (Class-
Responsibility-Collaborator). Per ogni classe viene costruita una scheda con il nome della classe, le sue
responsabilit (gli attributi e le operazioni rilevanti per la classe) e le sue collaborazioni (che identificano le
relazioni fra le classi). Come afferma giustamente il testo, E molto pi economico gettare via un mazzo di
schede che dover riorganizzare una mole ingente di codice sorgente. E oggi in auge la prassi di
suddividere le responsabilit fra le classi, in modo da non concentrare lintelligenza del software, ma da
avere componenti che svolgono poche, ben specifiche funzioni, in modo ottimizzato e riusabile: prassi,
naturalmente, alla base dello sviluppo per componenti. Le collaborazioni aiutano invece ad identificare quelle
classi che devono essere organizzate in sottosistemi.
Fino a questo punto, sono stati affrontati gli elementi statici del modello analitico. Un modello
comportamentale indica invece come il software risponde agli eventi, ed al passare del tempo. Tipici
prodotti della modellazione comportamentale sono i diagrammi stati-transizioni per ogni classe ed i
sequence diagram (che sono, in pratica, delle versioni abbreviate dei casi duso). La progettazione ,
invece, quel creativo lavoro che praticamente ogni ingegnere desidera fare, e che raramente riesce a fare. A
differenza del modello analitico, il modello progettuale fornisce dettagli relativi alle strutture di dati,

1
Lanalisi di un linguaggio naturale , naturalmente, soggetta ad errori ed ambiguit. E il problema alla base della nascita dei
metodi formali, come quelli che usano le estensioni OCL o il linguaggio Z.

4 di 16
allarchitettura, alle interfacce ed ai componenti del software che sono necessari per implementare il
sistema. Generalmente si progettano cinque viste, tra loro interrelate e piramidali:
1. i dati;
2. larchitettura;
3. le interfacce;
4. i componenti;
5. il deployment.
E tuttavia opinione comune, non solo dellAutore, che ad oggi la maggior parte delle metodologie di
progettazione del software non ha le doti di profondit, flessibilit e natura quantitativa che normalmente
vengono associate alle discipline pi classiche di ingegneria della progettazione. Ci che abbiamo sono
metodi per la progettazione, criteri per la qualit del progetto e notazioni per la progettazione. Tuttavia,
ogni sforzo umanamente possibile deve essere posto nella bont del progetto, sulla base del principio di
minor costo di reingegnerizzazione cos efficacemente espresso dalla citazione dellarchitetto Frank Lloyd
Wright: Sul tavolo da disegno si usa la gomma, mentre sul cantiere si deve utilizzare la mazza. La
progettazione indipendente dal modello di processo software utilizzato, e costituisce il ponte fra
modellazione e costruzione. Linput della progettazione il modello analitico, espresso nella forma di
elementi basati su scenari, basati su classi, orientati al flusso e comportamentali. La progettazione dei dati e
delle classi avviene naturalmente per raffinamento delle classi e relativi attributi prodotte nella modellazione
analitica, ed in particolare la progettazione dei dati assume maggiore dettaglio, in maniera iterativa, man
mano che vengono progettati i componenti software.
Uninteressante domanda, naturalmente, quante sono le software house che sviluppano [b]realmente[/b]
per componenti. Come afferma un bel lavoro del CBDI Forum (http://www.cbdiforum.org), la progettazione
per componenti non solo costa, ma non ha nemmeno un ROI nellimmediato. Ma avremo occasione di
riparlarne. E quasi inutile sottolineare quanto una buona progettazione influenzi la qualit del progetto
software. Qualit intesa nel senso di manutenibilit e possibilit di collaudare il prodotto e valutarlo molto
prima delle ultime fasi del processo, quando le scadenze incombono minacciose e le ultime briciole del
budget vengono spese per lo spuntino di mezzanotte del team in concorde straordinario permanente. Un
accenno fatto alle revisioni tecniche formali, oggetto di un paragrafo nel capitolo sulla qualit. Unutile
pagina richiama gli attributi di qualit FURPS (funzionalit, usabilit, affidabilit-reliability, prestazioni e
sopportabilit) definiti da Hewlett Packard. Indipendentemente dagli attributi sui quali concentrare
lattenzione (un progetto porr laccento sulla sicurezza, un altro sulle prestazioni, un altro ancora
sullusabilit, cos via) occorrerebbe sempre ricordare che la qualit si applica durante, non dopo il
processo di ingegneria del software. Il capitolo del Pressman prosegue con un paragrafo dedicato ai principi
di progettazione, nellordine:
1. Astrazione
2. Architettura
3. Modelli
4. Modularit
5. Incapsulamento delle informazioni
6. Indipendenza funzionale (entrambe tecniche di riduzione della propagazione degli errori)
7. Raffinamento
8. Refactoring (cos in auge nelle metodologie agili)
9. Classi progettuali.
Il modello progettuale pu essere considerato in due dimensioni: il livello di astrazione (salendo di dettaglio
dal modello analitico a quello progettuale) e gli elementi di processo, che comprendono larchitettura,
linterfaccia, i componenti ed il deployment. Normalmente, lo sviluppo degli elementi dellinterfaccia e dei
componenti viene parallelizzato dopo la progettazione preliminare dellarchitettura (che comprende la
progettazione dei dati), mentre il modello di deployment viene ritardato al termine del progetto. Il capitolo si
chiude con linteressante (e quantomai poco nota) progettazione del software basata su modelli. Un
costruttore di televisioni abituato a lavorare con un corposo catalogo di componenti da assemblare come i
pezzi delle costruzioni Lego, mentre lattivit preferita dellingegnere del software medio sembra essere la
reinvenzione della ruota.
Per quanto riguarda la progettazione dellarchitettura, il testo enfatizza il ruolo dei componenti in ogni
rappresentazione. Pi precisamente, vengono considerati due livelli: la progettazione dei dati e la
progettazione dellarchitettura (rappresentazione della struttura dei componenti software e delle loro
propriet ed interazioni). Un breve paragrafo iniziale riservato alla progettazione dei dati, con qualche
accenno allabusato argomento dei data warehouse. Il capitolo procede con una panoramica sugli stili e

5 di 16
modelli architetturali, da quelli basati sui dati alle pi recenti architetture a livelli ed object-oriented. La
progettazione dellarchitettura comincia con un diagramma di contesto, che definisce le entit esterne (altri
sistemi, dispositivi, persone) con cui il software dovr interagire e la natura dellinterazione. Prosegue con la
definizione degli archetipi, ovvero quelle classi o modelli che rappresentano unastrazione fondamentale e
critica per progettare unarchitettura per il sistema obiettivo, generalmente derivati a partire dalle classi del
modello analitico, cos come i componenti che costituiscono la struttura del sistema. Il procedimento termina
(in senso iterativo) con una istanziazione dellarchitettura, ovvero la sua applicazione ad un determinato
problema con lo scopo di dimostrare che la struttura ed i componenti sono appropriati.
Il successivo paragrafo dedicato alla valutazione dei progetti di architettura alternativi cos prodotti. Viene
presentato il metodo iterativo ATAM (Architectural Tradeoff Analysis Method,
http://www.sei.cmu.edu/ata/ata_method.html) prodotto nel 1998 dal SEI (Software Engineering Institute)
della Carnegie Mellon University, sostanzialmente basato sulla valutazione comparativa di una serie di
attributi di qualit e sui punti di sensibilit, ovvero sugli attributi che vengono influenzati in modo significativo
da variazioni anche piccole dellarchitettura. La complessit dellarchitettura viene valutata con riferimento
alle dipendenze esistenti fra i vari componenti, un procedimento in cui pu essere di aiuto il prodotto Lattix
LDM (http://www.programmazione.it/index.php?entity=eitem&idItem=33266), ed approfondito in parte nel
Capitolo 15 dedicato alle metriche di prodotto per il software. Sin troppo breve il sottoparagrafo 10.5.3,
dedicato allimportante argomento degli ADL (Architectural Description Language): troviamo solo un utile
elenco di progetti di ricerca, e lavvertenza che UML non un linguaggio ADL completo. Lultimo paragrafo
del capitolo dedicato alla progettazione strutturata introdotta da Yourdon e Constantine (prima del
successo dei linguaggi object-oriented), una tecnica orientata al flusso dei dati in cui rivestono notevole
importanza i DFD (Data Flow Diagrams). Il testo sottolinea come la tecnica abbia ancora una sua ragion
dessere, ma sia inadatta per sistemi che richiedono sostanziali modifiche nel tempo o in cui lelaborazione
dei dati non sequenziale.
La progettazione a livello di componenti un importante argomento, in parte ripreso dal Capitolo 25 dedicato
proprio alla CBSE (Component-Based Software Engineering). Il capitolo comincia con una definizione di
componente, dal punto di vista dellobject-orientation, dellingegneria del software classica e di quella basata
sui processi. Al di l dei distinguo, tutti gli approcci concordano nel definire un componente come un insieme
di logiche di elaborazione, strutture dati interne ed interfacce. Il capitolo prosegue con la progettazione dei
componenti basati su classi, introducendo i fondamentali principi di coesione ed accoppiamento e con una
particolare attenzione verso il principio OCP (Open-Closed Principle), ovvero Un modulo (o componente)
deve essere aperto alle estensioni ma chiuso alle modifiche, che si traduce concretamente nella creazione
di astrazioni (solitamente interfacce) che fungono da buffer tra la funzionalit che deve essere estesa e la
classe progettuale. Ai diagrammi grafici UML spesso opportuno affiancare dei vincoli espressi in un
linguaggio formale: un paragrafo introduce brevemente, rimandando al capitolo metodi formali negli
argomenti avanzati, il linguaggio OCL (Object Constraint Language), formalizzato da OMG
(http://www.omg.org). Questo linguaggio, per il quale esistono vari strumenti quali Dresden OCL toolkit
(http://dresdenocl.sourceforge.net) o lOCL parser (http://www-
3.ibm.com/software/ad/library/standards/ocldownload.html) di IBM, rivela la propria utilit anche nella
specifica di pre- e postcondizioni per il completamento di unazione specificata dal progetto.
Per quanto il modello a componenti faccia spesso pensare ai linguaggi O-O, esiste una solida letteratura, il
cui precursore Edsgar Dijkstra, sulla progettazione di componenti cosiddetti convenzionali per linguaggi
procedurali, che prendono in tal caso solitamente il nome di moduli, procedure o subroutine.
Naturalmente, il Pressman presenta i principi della programmazione strutturata ed i tre costrutti
fondamentali di sequenza, condizione e ripetizione, e viene illustrato luso dei flowchart o diagrammi di
flusso. Un paragrafo apposito dedicato alla descrizione del comportamento di un componente in
pseudocodice attraverso il PDL (Program Design Language). Il volume non presenta invece le reti di
Petri; per unintroduzione allargomento, si veda http://etd.adm.unipi.it/theses/available/etd-06282004-
120407/unrestricted/capitolo2.pdf. Il capitolo 12 tratta la progettazione dellinterfaccia utente. Inutile
negarcelo: possiamo mugugnare quanto vogliamo sulle scarse conoscenze dellutente finale, ma linterfaccia
utente come la giacca-e-cravatta al colloquio di assunzione. Indipendentemente da quanto impegno venga
profuso nello scrivere bene il codice, uninterfaccia utente mal realizzata porta a ritenere che il software sia
scadente. Lo stesso Pressman non trova meglio che cominciare col riepilogare le tre regole doro espresse
da Mandel in un testo del 1997:

lasciare che il controllo sia nelle mani dellutente

limitare il ricorso alla memoria da parte dellutente
usare uninterfaccia uniforme.

6 di 16
In poche parole: non sottovalutate mai quanto stupido puo essere un utente. Inevitabile il riferimento al sito
UseIt (http://www.useit.com) di Jakob Nielsen. La progettazione dellinterfaccia parte dalla considerazione
di chi saranno gli utenti finali del sistema: al solito, un ovvio consiglio della nonna troppo spesso trascurato.
Una volta conosciuti gli utenti, le operazioni che effettueranno e lambiente in cui opereranno le fasi di
progettazione, costruzione e convalida dellinterfaccia costituiscono un modello iterativo ed a spirale.
Linterfaccia utente il regno dei prototipi: inutile aspettarsi di poter effettuare una verifica su carta del
comportamento di una variabile imprevedibile quanto un utente finale. Lanalisi e la progettazione delle
interfacce, oggetto dei successivi due paragrafi, sono state inserite entrambe in questo capitolo in quanto
opinione dellAutore che, nel caso specifico delle interfacce utente, il confine fra le due sia troppo vago per
non trattarle insieme. Si presti attenzione a non sopravvalutare il confronto (scontro?) con lutente finale:
unopinione forte non necessariamente condivisa dalla maggior parte degli utenti. Ancora, un input
assolutamente da non sottovalutare quello del supporto tecnico. Il testo non discute, se non in un breve
box riepilogativo, alcun modello di interfaccia utente, per i quali si viene rimandati ai numerosi testi in
Bibliografia.
Quattro comuni problemi, solitamente affrontati solo quando disponibile un prototipo operativo, sono:
i tempi di risposta del sistema
i sistemi di help
la gestione degli errori
la denominazione dei comandi.
Per quanto riguarda il tempo di risposta, pi che alla sua lunghezza si dovrebbe guardare alla sua variabilit:
lutente molto pi disposto ad adeguare i suoi ritmi di lavoro ad un tempo di risposta standard, anche
abbastanza lungo, di quanto non lo sia ad adeguarsi ad una macchina che non si sa se sputer fuori il
risultato fra due secondi o due ore; peggio ancora, nel caso di un tempo di risposta indeterminato,
esperienza comune che lutente non sappia mai decidere se il sistema sta lavorando o bloccato in errore.
Per quanto riguarda i messaggi derrore, si finisce sempre col ripetersi le stesse barzellette su Il modulo
xxxyyyzzz ha determinato un errore oh123aaa9239203 nel modulo di sistema aaabbbcc. Un discorso a
parte, naturalmente, quello sullaccessibilit, che oltre ad essere un imperativo morale e commerciale
diventato, anche in Italia con la Legge Stanca (L. 4/2004, http://www.camera.it/parlam/leggi/04004l.htm), un
obbligo di legge. Ancora, prassi comune sottovalutare i problemi di utilizzo di un software da parte di utenti
che utilizzano una lingua diversa da quella dello sviluppatore; e pensare che esiste addirittura una Guida
allinternazionalizzazione del software (http://oss.software.ibm.com/icu/userguide/i18n.html) redatta da IBM.
La valutazione delle interfacce utente anchessa un argomento sostanzialmente rimandato alla Bibliografia.
Le strategie e le tecniche di testing del software, e le metriche di prodotto, sono oggetto degli ultimi tre
capitoli della seconda parte; strettamente collegati alla qualit del software, sono pertanto ripresi nei
successivi capitoli. Si tratta di argomenti che per me hanno sempre rivestito un fascino particolare; a chi non
condividesse il mio entusiasmo, voglio ricordare la citazione di Yourdon (scritta, il caso di ricordarlo, molti
anni prima dellanaloga battuta di Brad Pitt in Vi presento Joe Black): Come la morte e le tasse, il collaudo
sia spiacevole che inevitabile. Il collaudo deve mirare a massacrare il programma per individuarne il
maggior numero possibile di errori, con un impiego di risorse ragionevole: su questo siamo tutti daccordo. E
anche oramai affermato nella teoria (ma quanto mai poco utilizzato nella prassi) che qualunque strategia di
collaudo deve incorporare:
1. la pianificazione,
2. la progettazione dei casi di prova,
3. la loro esecuzione e
4. la raccolta e valutazione dei risultati.
Il motivo per cui si conducono, di solito, pessimi test un errore metodologico di base: il collaudo viene visto
come la fase in cui si inietta la qualit nel sistema, come se la qualit fosse unappendice e non una parte
integrante di tutto il processo di sviluppo. Ancora, si soliti rimandare il test a quando tutto il codice gi
stato scritto, per poi scoprire a poche ore della consegna che ne rimane da scrivere il doppio (esperienza,
ahim, di vita: senza il controllo degli errori, scriverei molto meno codice. Senza utenti, ne scriverei poco e di
molto creativo, ma pur vero che probabilmente non ne scriverei proprio). E invece abbastanza affermato il
principio di collaudo dal piccolo al grande, procedendo per aggregazione di gruppi di componenti, salvo che
nei figli del COBOL e negli studenti di Informatica, due gruppi di sviluppatori accomunati dalla passione
nella scrittura di lunghissimi listati che immancabilmente non vengono compilati.
Il testo interviene salomonicamente nella lunga discussione che ha per oggetto se il collaudo debba essere
affidato allo stesso sviluppatore o ad un gruppo esterno, affermando che i test di unit ed integrazione sono
a carico del gruppo di sviluppo, mentre nelle fasi di validazione entra in gioco lITG (Independent Test
Group) che collabora con gli sviluppatori. Vengono presentate le strategie di collaudo per il software

7 di 16
convenzionale e ad oggetti; sostanzialmente, per entrambi vengono adottate le medesime quattro fasi di
test:
1. di unit (singolo modulo o classe),
2. di integrazione,
3. di convalida (ovvero rispetto dei requisiti) e
4. di sistema.
Il testing di software ad oggetti differisce significativamente da quello di software convenzionale nella fase di
integrazione, perch naturalmente il software O-O non una struttura di controllo gerarchica ovvia, che
consenta di scegliere una strategia top-down, bottom-up o intermedia. In tal caso vengono usate due diverse
strategie: il collaudo thread-based integra linsieme di classi necessarie per rispondere ad un input o ad un
evento del sistema, lavvove quello use-based inizia collaudando le classi indipendenti, per poi aggiungere
gradualmente le classi dipendenti. Viene poi trattata la convalida, distinguendo in particolare i collaudi alfa
(effettuati dallutente in presenza dello sviluppatore) da quelli beta (in cui lo sviluppatore assente); quasi
inevitabile la citazione da La cattedrale ed il bazar (http://www.catb.org/~esr/writings/cathedral-bazaar/). Il
collaudo di sistema accenna brevemente alle prove di recovery, di sicurezza, di stress e di prestazioni,
mentre il paragrafo finale dedicato al debugging. La conclusione quella che mi aspettavo: sebbene il
debugging possa e debba essere un processo disciplinato, rimane a tutti gli effetti unarte, addirittura una
dote innata secondo alcuni studi. Al di l della presenza di strumenti semiautomatici di debugging, rimane
sempre valido il vecchio consiglio quando sbatti la testa da tre ore su un bug, fai vedere il codice ad un
collega (e dunque la pratica agile del pair programming).
Nella pratica, si suole distinguere fra testing che tiene conto della struttura interna del programma, o white-
box, e testing realizzato sulla base dei requisiti funzionali, a volte senza nemmeno conoscere il
programma, o black-box. I due approcci, sorprendentemente, non sono contrapposti, ma complementari:
davvero utile provare a risolvere lesercizio finale, che chiede di fornire tre esempi in cui il collaudo black-box
non rileva problemi mentre quello white-box scopre un errore, e viceversa. Ad ogni buon conto, per motivi
legati pi che altro alla complessit computazionale, prassi usare il collaudo white-box nei test di livello
inferiore, ovvero di unit e di integrazione, e quello black-box nei test di convalida e di sistema. Lelenco dei
metodi white-box parte con un mio vecchio amore, che ha segnato gli inizi della mia carriera, ovvero il
collaudo per cammini di base elaborato da McCabe. Sostanzialmente, questo metodo si basa sullintuitiva
idea che pi un programma complesso, pi elevata la probabilit che contenga errori; la nozione
intuitiva di complessit viene misurata tramite un indice metrico, la complessit ciclomatica, che tiene conto
fondamentalmente dei costrutti decisionali e viene solitamente calcolata a partire dal grafo di flusso del
programma. E bene sottolineare che, naturalmente, tale indice consente solo una scrematura su base
statistica delle parti pi soggette ad errori: un modulo di programma potrebbe avere un indice ciclomatico
bassissimo, ed essere tuttavia pieno di bug.
La complessit ciclomatica pone un limite superiore al numero di collaudi che devono essere condotti per
garantire che tutte le istruzioni vengano verificate almeno una volta; la parte interessante del metodo
McCabe che la costruzione del grafo di flusso ed il calcolo di una base di cammini linearmente
indipendenti (fondamentalmente, percorsi di test che tocchino tutte le istruzioni) sono attivit
automatizzabili con lausilio di una matrice di grafo di flusso. Altri metodi di testing white-box, che
completano lanalisi McCabe, sono il collaudo per condizioni, per flusso dei dati e per cicli. I test di tipo black-
box sono invece comportamentali, basati come detto sui requisiti funzionali, e pongono laccesso sulluso di
grafi che descrivano le chiamate di un programma, sulla suddivisione dei possibili dati dingresso in classi di
equivalenza per ridurre il numero di test significativi, sullanalisi dei valori limite (fortunatamente, oltre ad
essere una delle pi importanti, anche una delle pi utilizzate; la maggior parte dei programmatori sa
perfettamente che una funzione che accetta in ingresso valori da 1 a 100 va testata almeno per -1, 0, 1, 2,
99, 100 e 101), o su metodi volti a ridurre il numero di valori di input come il collaudo ad array ortogonale.
Il collaudo di software object-oriented da un lato facilitato dal fatto che pu iniziare gi dai modelli, senza
aspettare la scrittura del codice, dallaltro reso pi complicato dai problemi legati allereditariet. Per quanto
riguarda i test delle singole classi, si suole utilizzare un collaudo casuale, che invoca una serie plausibile di
metodi della classe, ed uno a partizionamento, fondamentalmente lanalogo O-O della suddivisione in classi
di equivalenza. Vi sono infine metodi di collaudo speciali per le interfacce grafiche, le architetture
client/server, la documentazione ed i sistemi real-time (che introducono lulteriore variabile tempo), mentre il
testo rimanda ai classici in Bibliografia per lanalisi dei modelli di collaudo. La definizione di metriche per il
software da sempre un obiettivo di tipo ingegneristico (non vi ingegneria dove non vi misura) volto a
stabilire la qualit del software realizzato; i primi fattori di qualit storicamente elaborati, ovvero i fattori duso,
di revisione e di transizione del prodotto di McCall ed i sei attributi dello standard ISO 9126, sono per di tipo
qualitativo. In effetti, ad oggi, tutte le metriche definite sono solo misure indirette della qualit: non
misuriamo cio direttamente la qualit del software, ma alcune sue manifestazioni. Largomento ancora in
divenire, tanto che si rende necessario un paragrafo che introduca il quadro di riferimento: la differenza fra

8 di 16
misure, metriche ed indicatori, i principi della misurazione, il paradigma GQM (Goal/Question/Metric) per la
misurazione orientata allobiettivo, ed un panorama delle metriche di prodotto.
Le metriche per il modello concettuale partono dallassunto, simile allequazione complessit = numero di
errori alla base del metodo McCabe, che sia ragionevole pensare che la taglia e la complessit del modello
progettuale siano direttamente correlate. La prima, importante metrica che viene esaminata quella dei
punti funzione o Function Points (FP). Il metodo stato proposto inizialmente da tal [b]Albrecht[/b] della
IBM Research nel 1979 e gode di un crescente consenso nella comunit, tanto che stato adottato come
criterio di stima e valutazione dei progetti software dal CNIPA (Centro Nazionale per lInformatica nella
Pubblica Amministrazione, http://www.cnipa.gov.it). Il conteggio dei punti funzione standardizzato in un
manuale revisionato periodicamente dallIFPUG (International Function Point Users Group,
http://www.ifpug.org), il cui capitolo italiano il DPO (http://www.dpo.it).
In sostanza, i punti funzione vengono derivati utilizzando una relazione empirica che si basa su misure
calcolabili (dirette) nel dominio delle informazioni del software e valutandone la complessit; un database
storico di progetti aiuta poi il project manager nellassociare la complessit di unapplicazione in punti
funzione allimpegno in mesi-uomo necessari, stabilito il linguaggio di programmazione, ed a valutare il
numero di errori che ci si aspetta di trovare nellimplementazione. E necessario in primo luogo valutare un
insieme di valori nel dominio delle informazioni:
numero di input esterni (EI),
numero di output esterni (EO),
numero di richieste esterne (EQ),
numero di file logici interni (IFL) e
numero di file dellinterfaccia esterna (EIF).
La somma di questi valori, pesata con un fattore che valuta il grado di complessit (semplice, medio o
complesso), costituisce il numero di function point unadjusted, cui viene applicato un fattore di correzione e
sommati dei fattori di aggiustamento (VAF) determinati dalla risposta ad una serie di domande (reperibili
allURL http://www.ifpug.com/fpafund.htm), espressa come voto da 0 a 5. Si tratta, naturalmente, di un
metodo soggettivo, che segue per dei criteri standard internazionalmente riconosciuti, applicati da esperti
certificati. I Function Point sono un importante argomento che viene ripreso nel capitolo 17, ove si cerca di
metterli in relazione con una metrica di processo quale le LOC (numero di linee di codice).
Le metriche per la qualit delle specifiche proposte da Davis e colleghi assegnano invece un indice di
coerenza, fondato sullaccordo fra le interpretazioni date dai revisori a ciascun requisito, ad una serie di
caratteristiche di tipo qualitativo. Le metriche di progettazione comprendono un insieme di indici suddivisi in
metriche di alto livello, orientate agli oggetti, orientate alle classi, a livello di componenti, orientate alle
operazioni e per la progettazione di interfacce. Sulle metriche per il codice sorgente viene fatto un accenno
al controverso lavoro di Halstead, basato sul numero di operatori ed operandi presenti nel codice e
sottoposto a numerose verifiche sperimentali dal 1977 ad oggi. Per quel che riguarda il testing, la
maggioranza delle metriche proposte rivolta al processo di collaudo, non alle caratteristiche tecniche delle
prove in s. Per il software procedurale si usano metriche derivate dalle misure di Halstead, ed ugualmente
per il software ad oggetti le metriche di progettazione hanno uninfluenza diretta sulla collaudabilit di un
sistema O-O, e vengono considerati gli aspetti relativi allincapsulamento ed allereditariet.
Per quanto riguarda infine la manutenzione, lIEEE ha proposto uno specifico standard, SMI (Software
Maturity Index) che riassume il grado di stabilit di un prodotto software sulla base delle modifiche
apportate alle nuove versioni del prodotto. Calcolato a partire dal numero di moduli finali, modificati, aggiunti
ed eliminati, si suppone che al tendere di SMI ad 1 il prodotto tende a stabilizzarsi, e che il tempo medio
necessario per produrre una nuova versione del prodotto correlato ad SMI, per cui si possono sviluppare
modelli empirici di previsione dellimpegno di manutenzione. Dal punto di vista dei tool software disponibili,
solitamente il calcolo di alcune metriche implementato come funzionalit aggiuntiva di pi vasti strumenti di
analisi e progettazione, programmazione o collaudo.

Gestione dei progetti software

Linteressante argomento del Project Management non pu prescindere da una necessaria panoramica sulle
quattro P (persone, prodotto, processo e progetto); lordine delle quattro P non casuale, e per le persone il
solito Software Engineering Institute ha elaborato addirittura un modello di maturit della capacit di gestione
delle persone, People-CMM (http://www.sei.cmu.edu/cmm-p). Un approccio straordinariamente semplice,
dettato dal solo buon senso (e pertanto pochissimo utilizzato) il principio W5HH di Boehm, che consiste
semplicemente nel rispondere a sette domande, le cui iniziali danno il nome al metodo, il cui immenso
vantaggio quello di essere applicabile indipendentemente dalle dimensioni o dalla complessit del progetto

9 di 16
software. Sul fronte degli strumenti, pu essere utile il Project Control Panel
(http://www.spmn.com/products_software.html) realizzato in Excel. Il discorso pu proseguire con un
approfondimento sulle metriche per il software, dal punto di vista delle metriche di processo e di progetto.
Per quanto molte metriche siano utilizzabili in entrambi i casi, le due famiglie sono complementari: le
misurazioni di processo portano a miglioramenti a lungo termine, laddove ovviamente quelle di progetto
servono a guidare i lavori in corso. Lefficacia di un processo di sviluppo software si misura indirettamente: a
partire da informazioni derivate dal processo si ricava una famiglia di metriche. E opportuno che le metriche
di processo rimangano private, ovvero non attribuite ai singoli individui del team ma raccolte su base
statistica, per evitare inutili rimpalli di responsabilit; viene suggerito addirittura un galateo nella raccolta
delle metriche.
Le metriche dimensionali sono quelle storicamente usate per prime e per le quali esiste il pi vasto corpus di
studi, si basano fondamentalmente sulle LOC (linee di codice) prodotte, e sono naturalmente le pi
controverse: i principali argomenti contro luso delle linee di codice sono che:
le misure in LOC dipendono dal linguaggio di programmazione,
penalizzano i programmi ben architettati ma brevi, e
non si adattano facilmente ai linguaggi non procedurali.
Io aggiungerei che riducono lattivit creativa dello sviluppatore ad un lavoro a cottimo simile a quello dello
scaricatore di porto, e che concettualmente sono alla base del noto se vediamo che siamo in ritardo,
aggiungeremo altre persone al team, ovvero uno dei modi pi sicuri per devastare un progetto gi votato al
fallimento. Anche le pi recenti metriche basate sulle funzioni, la pi utilizzata delle quali il metodo basato
sui Function Points, hanno per i loro detrattori: sono in molti a far notare che lelemento di soggettivit
alto (due esperti del metodo dei punti funzione possono arrivare a risultati diversi per lo stesso prodotto) e
che i punti funzione non hanno alcun significato fisico diretto. Sono stati condotti peraltro vari studi per
riconciliare i risultati ottenuti con le metriche LOC ed FP, anche dallo stesso Albrecht, e tenendo conto che la
relazione fra le due metriche dipende dal linguaggio di programmazione utilizzato. Se guardiamo alla tabella
riportata nel testo, comunque, scopriremo che, quale che sia il linguaggio di programmazione scelto, la
varianza fra LOC per punto funzione minime e massime rilevate arriva tranquillamente a fattori 10 ed oltre.
Ancora, che si scelga di utilizzare le LOC o i FP, per avere una stima dellimpegno richiesto dal progetto
necessaria una nutrita serie storica.
Metriche diverse sono state proposte per i linguaggi O-O, considerando che n LOC n FP forniscono una
granularit sufficiente per valutare correttamente le iterazioni svolte tramite processi evolutivi o incrementali.
Unimportante metrica di qualit del software invece la DRE (Defect Removal Efficiency, o efficienza di
rimozione dei difetti), ovvero una misura della capacit di rimuovere gli errori (non-conformit ai requisiti
scoperti prima del rilascio alla fase successiva) prima che divengano difetti (non-conformit ereditate dalla
fase del ciclo di vita precedente). Lintegrazione delle metriche nel processo software, con una particolare
attenzione per le piccole aziende (con meno di 20 sviluppatori), e la definizione di un programma di
valutazione metrica del software, con i dovuti riferimenti al Guidebook for Goal-Driven Software
Measurement (http://www.sei.cmu.edu/pub/documents/96.reports/pdf/hb002.96.pdf), chiudono il capitolo. I
successivi capitoli della terza parte coprono le cinque attivit della conduzione di un progetto software:
la stima,
la pianificazione,
lanalisi dei rischi,
la gestione della qualit e
quella delle modifiche.
Ultimamente abbastanza comune trovare in letteratura tecnica il cosiddetto paradosso della stima: la stima
estremamente imprecisa nelle fasi iniziali del processo, quando serve, e raggiunge la perfezione una volta
che il processo completato, quando non serve pi. Tuttavia, il grado di incertezza pu essere ridotto
adottando almeno due metodi di stima, e riconciliando i risultati ottenuti. Un processo di stima comincia
definendo la portata e la fattibilit (tecnica, finanziaria, temporale ed in termini di risorse) del software. La
stima delle risorse comprende persone, componenti software riutilizzabili ed ambiente di sviluppo (strumenti
hardware e software). Per avere stime affidabili, ci si serve di tecniche di scomposizione e di modelli empirici
di stima. Lesempio adottato per le tecniche di scomposizione vi dar modo di farvi una sana risata: si parla
di un costo del lavoro pari a 8000 Euro mensili (sic). I modelli empirici legano tutti la variabile utilizzata
(LOC o FP) a delle costanti derivate empiricamente per stimare limpegno in mesi/uomo; ognuno dei modelli
proposti in letteratura produce un risultato diverso per lo stesso valore di LOC o FP, per cui i modelli di stima
devono essere adattati alle esigenze locali. Il modello di stima probabilmente pi noto al mondo il
COCOMO II (http://sunset.usc.edu/cse/pub/research/COCOMOII/cocomo_main.html) originariamente
proposto da Boehm nel suo classico testo Software Engineering Economics

10 di 16
(http://www.amazon.com/gp/product/0138221227/002-6561127-5158441?v=glance&n=283155), ma ne
esistono anche altri, quali lequazione del software di Putnam e Myers (basato su una serie storica di 4000
progetti).
Particolari accorgimenti vanno adottati per la stima dei progetti O-O e per i progetti di breve durata, con
particolare riferimento allo sviluppo agile. Un importante paragrafo finale tratta le scelte cosiddette make-or-
buy, ovvero la difficile alternativa fra sviluppare in proprio ed acquistare o affidare lo sviluppo allesterno. La
pianificazione del progetto comincia con limportante argomento dellallocazione delle risorse umane. Il mito
Se siamo in ritardo, possiamo aggiungere altri programmatori e recuperare viene sfatato, oltre che dal
buon senso, anche dalla matematica, presentando la curva di Putnam-Norden-Rayleigh (PNR,
https://www.esi-intl.com/public/publications/horizonspdfs/horizons1201.pdf). La curva, sostanzialmente, ci
dice che:
non ha senso comprimere i tempi di progetto pi del 75% di quelli ottimali
lungo lasse temporale si raggiunge un punto in cui il lavoro non pu pi essere completato in tempo,
indipendentemente dal numero di persone che lo svolgeranno,
a parit di obiettivi, si ottengono benefici dallimpiegare un numero inferiore di persone per un periodo
pi lungo.
Fondamentale importanza assume il paragrafo dedicato alla distribuzione del carico di lavoro tra le varie fasi:
solitamente si raccomanda la regola del 40-20-40, ovvero assegnare il 40% dellimpegno allanalisi ed alla
progettazione, la stessa percentuale ai collaudi ed al debugging, e solo il 20% alla stesura del codice.
Una regola che va davvero contro il senso comune dei principianti della programmazione J La suddivisione
in un insieme di compiti, collettivamente denominati anche WBS (Work Breakdown Structure), e la
pianificazione temporale passano, ovviamente, per le note tecniche PERT (Program Evaluation and Review
Technique) e CPM (Critical Path Method). Al di l delle differenze, entrambe le tecniche forniscono strumenti
quantitativi che consentono al pianificatore di determinare il cammino critico, ossia la catena di compiti che
determina la durata di un progetto, stabilire le stime dei tempi pi probabili e definire le finestre temporali
entro cui ciascun compito deve essere iniziato e terminato. Nessun approfondimento dedicato a
PERT/CPM, mentre un breve paragrafo illustra luso dei diagrammi di Gantt. Un paragrafo finale dedicato
ad una nota tecnica quantitativa, dovuta ad Humphrey, per stabilire i progressi compiuti durante lo
svolgimento del progetto: lanalisi del valore aggiunto o EVA (Earned Value Analysis,
http://www.acq.osd.mil/pm/).
Il capitolo sullanalisi dei rischi presenta argomenti molto noti ai cultori della disciplina, naturalmente adattati
al panorama dello sviluppo software, che in molti casi, come al solito, si riassumono in una serie di pratiche
di buon senso. Lapproccio quello classico del prodotto probabilit x conseguenze dei singoli fattori di
rischio, corredato naturalmente da unanalisi costi/benefici (nessuno compra mai una cassaforte da
centomila euro per custodirvi lo stipendio mensile di un ingegnere del software). La gestione dei rischi pu
essere strutturata in un piano di riduzione, monitoraggio e gestione (RMMM, ovvero Risk Mitigation,
Monitoring and Management); in alternativa, ogni rischio pu essere documentato singolarmente utilizzando
un foglio informativo RIS (Risk Information Sheet), che riassume in una forma simile ad un caso duso tutti i
parametri quantitativi individuati (probabilit/conseguenze, raffinamento e contesto, riduzione e
monitoraggio, esposizione al rischio RE, ovvero prodotto della probabilit per il costo del rischio qualora si
verifichi, stato, ecc.).
Venendo al capitolo sulla qualit, lanalogia di Philip Crosby fra la qualit ed il sesso meriterebbe da sola il
prezzo di copertina, ma al di l delle battute, e delle giuste precisazioni sulle attivit e metriche per la
garanzia della qualit, mi ha molto colpito unaffermazione: Chiunque sia coinvolto nel processo di
ingegnerizzazione del software anche responsabile della sua qualit. Pensare ad un Reparto Qualit che
assicura la magica Certificazione ISO 9001:2000 mentre lo sviluppatore continua ad operare in pura
anarchia, o magari dopo che stato prodotto il codice, viene sempre pi riconosciuta come unamenit. Alla
base di ogni processo di qualit vi il controllo delle variazioni: non forse, del resto, la ripetibilit uno dei
fondamenti del metodo scientifico? Naturalmente, tale tipo di controllo presuppone una misurabilit del
software, gi oggetto del Capitolo 15. Il fondamento su cui misurare la qualit sono i requisiti: la mancanza di
conformit ai requisiti una mancanza di qualit. Se dei requisiti espliciti del cliente si gi discusso, esiste
una serie di requisiti impliciti (ad es. la facilit di manutenzione) la cui mancata soddisfazione un sicuro
indice di scarsa professionalit.
La revisione tecnica formale un argomento citato ad ogni pi sospinto nel testo: finalmente ne troviamo
in questo capitolo la trattazione organica. Una caratteristica importante delle revisioni tecniche formali (FTR)
quella di essere condotte da tecnici per tecnici, poich mirano a scoprire gli errori durante il processo di
sviluppo: molti si stupirebbero nel sapere che durante le attivit di progettazione si introducono fra il 50 ed il
65% di tutti gli errori; alcuni studi affermano che le tecniche di revisione formale possono scoprire fino al
75% degli errori di progettazione. Per aiutarci contro il management che ci parla dei costi della qualit, ci

11 di 16
viene stavolta in aiuto uno studio della stessa IBM: se la correzione di un errore rilevato durante la
progettazione costa 1 unit, il costo prima dei collaudi sale a 6,5 unit, durante i collaudi a 15 unit, dopo la
consegna ad un valore compreso fra 60 e 100 unit; non considerando il danno di immagine in questultimo
caso, ovviamente. Non male come argomento da usare contro il caporale che ci minaccia: non stai
lavorando, stai scrivendo carte!. Desta raccapriccio anche esaminare i modelli di propagazione dellerrore,
sempre prodotti da IBM; al manager che ne capisce solo di vile denaro, si pu far notare che i modelli
conducono ad un costo totale triplo, in assenza di revisioni.
Il problema, come sempre, un altro. La gestione della qualit ci consente di scegliere se pagare ora, o
pagare molto di pi in seguito: un argomento che ha ben poca presa per molte PMI italiane, che giorno
dopo giorno non sanno se ci sar un seguito (ma molto spesso non hanno mai lavorato perch ci fosse).
UnAzienda che ha una ragionevole certezza di rimanere sul mercato per tre anni non ha, invece, alcuna
scusa: il management di una tale Azienda che non adotti prassi formali di ingegneria del software dimostra,
volendo usare un eufemismo, mancanza di professionalit e di visione strategica. Tra parentesi, nessuno ha
mai pensato che una FTR unottima palestra per un neoassunto, permettendogli di osservare diversi
approcci allanalisi, progettazione e implementazione del software?
Come per i team di sviluppo, cos per le riunioni di revisione condivido lidea del gruppo limitato (da tre a
cinque persone): del resto, la Storia stata fatta dai piccoli gruppi ben organizzati, non dagli eserciti.
Ricordatelo al manager che organizza per i propri fini la classica riunione del personale spacciandola per
FTR. Un altro consiglio che mi sento di sottoscrivere quello classico del pair programming: fate esaminare
il prodotto da qualcuno che non lha realizzato. Per le revisioni valgono alcune prassi da adottare in tutti i tipi
di riunione:
una revisione incontrollata spesso peggio che il non farne del tutto;
quello che viene sottoposto ad esame il codice, non lo sviluppatore;
occorrerebbe dedicare due ore a preparare ogni riunione, la quale a sua volta non dovrebbe superare
le due ore;
occorre individuare i problemi ed andare avanti, per quanto lumana tentazione sia quella di risolverli
sul posto: una revisione non una sessione di lavoro dedicata alla soluzione dei problemi;
devono essere stabiliti i tempi di rilascio delle modifiche, che sono il risultato di una FTR: la riunione
che si conclude senza aver prodotto altro che il verbale sar quasi sicuramente lultima riunione che
riuscirete ad organizzare.
Per quanto riguarda la preparazione della riunione, insistete fino alla morte perch i partecipanti si
presentino con una serie di commenti scritti sul materiale esaminato. Tutti sono convinti di aver capito alla
perfezione un argomento, finch non provano a metterlo su carta. Da parte vostra (non c scritto sul libro,
un mio consiglio), seguite la regola del galateo giapponese sui biglietti da visita: invece di mettere la pila di
appunti che leggerete dopo la riunione in un angolo del tavolo o nella borsa, scorreteli rapidamente,
sottolineando le frasi che ritenete pi significative, ed avendo cura di leggerle ad alta voce. Vi assicuro che
avrete ottime probabilit di ritrovarvi con una documentazione di prodotto che presenti correttamente
evidenziati i concetti chiave. Visto che nel mondo reale dei progetti software, le risorse sono limitate ed il
tempo manca, opportuno raffinare le tecniche di campionamento dei prodotti dellingegneria del software
da sottoporre ad FTR; il riferimento obbligato in questo caso la metodologia Six Sigma
(http://www.isixsigma.com) portata al successo da Motorola negli anni 80.
Un argomento affascinante, ripreso nei capitoli avanzati della quarta parte, quello dei metodi formali per
lassicurazione della qualit. Ribadisco comunque il problema espresso precedentemente: tutti i metodi
quantitativi ad oggi conosciuti si basano sullesame di dati storici, per cui dovremmo pensare ad unAzienda,
che comincia a fare qualit sul serio (nel concreto, a salire livelli del CMMI) non meno di quattro-cinque anni
dopo aver cominciato a raccogliere metriche sul software, esigenza che, come ho gi ricordato, viene in
mente (quando viene in mente) quando si ha una ragionevole certezza di rimanere sul mercato per tre anni
ancora. Unaltra lezione non riportata sul testo, parte dellesperienza che voglio trasmettervi, la seguente:
la documentazione relativamente semplice da produrre; la vera difficolt sta nel mantenerla in linea con il
codice, giorno dopo giorno, anche quando le scadenze incombono. Un piano di ingegneria del software
dovrebbe sempre individuare, dinamicamente nel corso dellevolversi del progetto, quellinsieme di attivit
volte allassicurazione della qualit che lo sviluppatore deve eseguire anche quando il fuoco ha raggiunto la
scrivania, i terroristi hanno fatto irruzione nellufficio o mancano cinque minuti allinizio della finale dei
Mondiali di calcio. Inutile tenerle nel cassetto, anche se il rischio che il team finisca per fare solo quelle
molto alto: in unattivit come lo sviluppo di software, la chiave del successo non sta nellimposizione, ma
nella condivisione degli obiettivi.
Lanalisi di affidabilit del software, inizialmente condotta cercando di applicare mutatis mutandis i metodi
matematici della teoria dellaffidabilit dellhardware (particolarmente consolidati), ha finito per scontrarsi con
uninsanabile difformit di scenario: tutti i guasti di un prodotto software risalgono a problemi di progettazione

12 di 16
o di implementazione, mentre lusura non esiste; esattamente il contrario, insomma, degli assunti di base per
lhardware. Rimane comunque valido lapproccio basato sul tempo medio fra i guasti (MTBF, Mean Time
Between Failure) e sulla disponibilit, fortemente legata al tempo medio di riparazione. Un breve paragrafo,
quasi dobbligo, sullo standard ISO 9001:2000 chiude il capitolo, che purtroppo non sfiora nemmeno
strumenti classici di gestione della qualit come gli schemi di controllo, i diagrammi a dispersione, quelli di
affinit e quelli a matrice.
Se non controllate i cambiamenti, saranno i cambiamenti a controllarvi: cos comincia lultimo capitolo della
terza parte, dedicato alla gestione delle configurazioni software, argomento su cui in Programmazione.it
presente una mia recensione di un testo di Brian A. White sullargomento, focalizzato sulluso dellallora
Rational ClearCase (http://www.programmazione.it/index.php?entity=eitem&idItem=32149). Parte del
materiale del capitolo stata tratta dai numerosi lavori di Susan Dart, della Carnegie Mellon University, sul
tema (http://www.sei.cmu.edu/legaci/scm/tech_rep/TR11_90/TOC_TR11_90.html). Ho qualche perplessit
sulla lapidaria affermazione del testo la maggior parte delle modifiche giustificata, ma la necessit di
dotarsi di meccanismi e strumenti per gestire il cambiamento fuori di dubbio. Posso anche assicurarvi che,
nonostante il sempre maggiore successo delle architetture distribuite, una primaria necessit, condivisa
anche dal testo, che larchivio del progetto si trovi in un luogo centralizzato e controllato. Un elemento da
porre sotto configurazione cui pochi pensano allinizio sono gli stessi strumenti software, ovvero editor,
compilatori e strumenti CASE: eppure, chiunque lavori da qualche anno nel campo dello sviluppo pu
assicurarvi che due versioni successive di un compilatore cui venga passato lo stesso codice sorgente non
danno mai lo stesso risultato.
E quasi superfluo sottolineare che ad giorno doggi tutti gli strumenti per lSCM (Software Configuration
Management) si avvantaggiano di un archivio implementato come DBMS, ma pensate a quanto sono ancora
diffusi gli archivi umani, ovvero gli sviluppatori o responsabili nella cui testa o nei cui cassetti si annida
lintera conoscenza di un progetto (molto spesso, solo perch rimasto lunico motivo della loro esistenza
aziendale). Soffermate la vostra attenzione sulla Figura 22.3; possibilmente, fatene una fotocopia in grande
formato ed appendetela al muro. Descrive il contenuto di un archivio di SCM; se nel vostro progetto manca
qualcuno di questi elementi, fermatevi cinque minuti a riflettere se perch il vostro progetto abbastanza
semplice da non richiederlo, o perch avete commesso un errore. La gestione delle versioni
naturalmente la prima caratteristica di un prodotto di SCM, ma altrettanto importanti sono il monitoraggio
delle dipendenze e dei requisiti, la gestione delle release, la reportistica e laudit (chi ha fatto cosa, e
quando).
Posso assicurarvi che per quanto riguarda laudit rischiate facilmente di trovarvi in ufficio le barricate e gente
con lelmetto ed il fucile. Ricordate sempre la massima di Bennet: ogni cambiamento, anche se un
miglioramento, sempre accompagnato da inconvenienti e disagi. Una funzionalit essenziale di un
sistema di SCM deve essere la possibilit di raccogliere, in maniera automatica o almeno semiautomatica,
tutti gli oggetti di configurazione rilevanti e costruire una specifica versione del software. Tutti sanno, per
esempio, che il notissimo CVS (http://www.cvshome.org) non un sistema di compilazione, ma che
possibile usarlo per costruire una specifica versione del software integrando in essi altri strumenti, per
esempio Makefile. Un limite ineliminabile di questo strumento, peraltro meritoriamente assai diffuso, invece
il fatto che non implementa un processo di controllo delle modifiche (per esempio richieste di modifica, report
delle modifiche, monitoraggio di bug). Infine, lavorate per una breve settimana in un team (ovvero almeno
con unaltra persona), ed imparerete a benedire ogni mattina le funzionalit di check-in e check-out.
Il paragrafo sul controllo dei cambiamenti semplicemente meraviglioso; peccato che mi abbia fatto venire
alla mente mille telefonate (di due minuti luna) del cliente, che si sono trasformate in una catena gerarchica
di n-mila telefonate (di un minuto luna) culminate nello squillo del telefono sul tavolo dello sviluppatore.
Considerate i lavori di Shannon sul deterioramento dellinformazione nel passaggio in una catena di
elaborazioni, ed il gioco fatto. Chi vuole avere qualche speranza di evitare i week-end in ufficio dovrebbe
invece imparare a memoria una delle note finali: probabile che un controllo un po eccessivo sia quello
pi appropriato. Il momento immediatamente successivo allapprovazione della modifica simile a quello in
cui il paracadutista ha appena staccato il piede dallaereo: chi garantir che la modifica sia stata
correttamente effettuata?
La risposta, in cui perseverare con la dovuta disciplina, una revisione tecnica formale per tutte le
modifiche, tranne le pi banali (ed in un progetto software complesso, scoprirete a vostre spese che di
banale c ben poco. Siete davvero sicuri che semplicemente modificando la lunghezza di un messaggio
derrore nulla cambier? Provare per credere). A proposito: siete sicuri di sapere chi sono, per ogni
modifica, tutte le persone che debbono venirne a conoscenza? Per finire: avreste mai creduto che in materia
di SCM esiste una nutrita serie di standard IEEE, ISO, EIA e militari? Il testo non accenna nemmeno al
problema del numbering delle versioni. In proposito, posso dirvi che nel management diffusa lidea che il
numbering non debba nemmeno esistere, ovvero: tutti i prodotti devono portare come numero di versione
1.0, 2.0 e cos via, per far credere che ognuno di essi un prodotto innovativo e perfetto. Una favoletta alla

13 di 16
quale non crede nessuno, ed un ennesimo marchio di fabbrica facilmente riconoscibile delle software house
ospitate in un sottoscala.

Argomenti avanzati dellingegneria del software

La quarta parte, dedicata agli argomenti avanzati, occupa opportunamente un posto a s, ma non dovrebbe
esserne trascurata, pur con qualche oggettiva difficolt per chi non padroneggia gli strumenti matematici
necessari, la lettura. In particolare modo, non vi sono scuse per non studiare il Capitolo 25 sullingegneria
del software a componenti, che sempre pi potrebbe essere lunica strada per uscire dallimpasse dei
progetti sempre pi complessi con tempi e budget sempre pi ristretti. Si comincia con il capitolo sui metodi
formali, culminante naturalmente nellintroduzione ad OCL (Object Constraint Language) e Z. La chiave
dei metodi formali sta in una specifica non ambigua dei prerequisiti, utilizzando la teoria degli insiemi e la
notazione logica. Il campo di applicazione pi naturale di questi metodi il software mission-critical, ed in
effetti troviamo riferimenti al lavoro di Warmer e Kleppe, pubblicato in versione aggiornata nel 1999 dalla
Addison-Wesley, nelle specifiche militari DoDAF (DoD Architecture Framework 1.0,
http://www.software.org/pub/architecture/dodaf.asp).
La realt dei fatti che non vi nessun argomento reale contro i metodi formali: essi vengono solo definiti
troppo difficili, in un Paese in cui quasi mai un ingegnere pu fare il suo lavoro. I metodi formali riescono a
conseguire la mancanza di ambiguit e la coerenza delle specifiche, mentre al momento assai pi difficile
raggiungere la completezza. Le basi matematiche per lapplicazione dei metodi formali richiedono solo la
conoscenza di alcune nozioni di teoria degli insiemi davvero banali per chi ha seguito un corso di studi
universitari scientifico (ma quanti, fra i key decisors aziendali, lhanno seguito?). Veniamo, finalmente, ai due
linguaggi formali presentati nel capitolo. OCL , in effetti, non un vero e proprio linguaggio formale, ma un
linguaggio di modellazione, pur con tutti gli attributi di un linguaggio formale; esso infatti costituisce una
parte delle specifiche UML standardizzate da OMG, poich stato pensato come unestensione formale
per consentire agli utilizzatori di UML di impiegare una maggiore precisione nelle loro specifiche.
Per facilitarne ladozione e renderlo pi facilmente elaborabile dai calcolatori, i progettisti hanno sostituito la
notazione matematica convenzionale con caratteri ASCII, rendendolo per al contempo pi prolisso. OCL
aggiunge un insieme di condizioni o vincoli ad un diagramma UML (tipicamente delle classi, degli stati o
delle attivit), ed un linguaggio object-oriented, che utilizza anche i classici operatori O-O come quello di
referenziazione o la dot notation. Lesempio duso di OCL, un gestore di blocchi per file system, introduce
tutti i concetti alla base di un metodo formale, ovvero invarianti, pre- e post-condizioni. Z invece,
probabilmente, il linguaggio per specifiche formali oggi pi utilizzato, vantando ormai ventanni di storia. Si
basa sulla logica dei predicati di primo ordine per costruire degli schemi, ovvero lequivalente nel campo
delle specifiche formali di una subroutine o procedura in un linguaggio di programmazione. Uno schema in Z
descrive i dati memorizzati che un sistema consulta e modifica, ovvero ci che in Z si chiama stato. Si tratta
di un linguaggio notevolmente pi formale di OCL, ma chi ha dimestichezza con la logica degli insiemi ne
trarr notevoli vantaggi. Nel campo degli strumenti, purtroppo, troviamo solo progetti di ricerca: focalizzando
lattenzione su OCL, per esempio, nessuno dei produttori di tool UML riconosciuti da OMG
(http://www.uml.org/#Links-UML2Tools) ha implementato funzionalit per applicare questo metodo formale.
Nonostante i vantaggi che si possono ottenere, la decisione di adottare un metodo formale non va presa alla
leggera ma, come al solito, pesando una serie di fattori: i principali sono la valutazione dei costi dadozione,
piuttosto alti nelle fasi iniziali, e la scelta dei componenti cui applicarli. E importante notare, per, che i
metodi formali possono essere in concreto lunica strada per creare librerie di componenti riutilizzabili. Un
esempio di processo in grado di incorporare i metodi formali nellingegneria del software tradizionale la
produzione di software in camera sterile (cleanroom), proposta per la prima volta da Mills, Dyer e Ginger nel
1987 ed oggetto del successivo capitolo. La cleanroom software engineering si propone di eliminare i costi
della rimozione degli errori scrivendo porzioni di software corrette per principio e verificandone la correttezza
prima del collaudo; il modello di processo corrispondente incorpora la certificazione statistica di qualit delle
porzioni di codice a mano a mano che vengono prodotte.
Lingegneria in camera sterile esattamente lopposto del metodo preferito dai clienti e dai manager meno
illuminati, il portami una cosa funzionante che ti dico come correggerla ripetuto n volte (con n molto alto)
che causa tanta frustrazione negli ingegneri, figure preparate per essere progettisti e controllori che vengono
ridotte a meri esecutori. Se pensate di valere qualcosa, lottate fino alla morte per i metodi formali e lo
sviluppo a componenti: sono il modo pi sicuro per tagliare fuori le mezze calzette dal mercato. Per quanto
un lavoro proposto nel 1994 sullIBM Systems Journal
(http://domino.research.ibm.com/tchjr/journalindex.nsf/e90fc5d047e64ebf85256bc80066919c/ad8310e10e47
aa4185256bfa00685cc5?OpenDocument) sottolineasse i successi dei primi tentativi, lingegneria del
software in camera sterile , manco a dirlo, poco diffusa: un articolo di Henderson del 1995 suggerisce i

14 di 16
motivi plausibili; io li riassumerei con un vecchio proverbio delle mie parti: il raglio di cento asini riesce a
coprire perfino lululato di un lupo.
In termini pi pragmatici, perch dare ad un preparato ingegnere diecimila euro al mese, quando sul mercato
ci sono dieci mezze calzette che si accontentano di novecento euro (e se per caso ad unAzienda capita
sottomano un preparato ingegnere, il mercato livellato e sempre novecento euro sono)? La soluzione a
camera sterile adotta una versione specializzata del modello incrementale; la caratteristica distintiva quella
di spostare i collaudi dal singolo sviluppatore ad un team indipendente. Il raffinamento si basa sul concetto di
scatola, ovvero una rappresentazione del sistema (o di un aspetto del sistema) ad un certo livello di
dettaglio. Un analista ripartisce gerarchicamente il sistema tramite tre tipi di scatole: nere, che definiscono la
reazione di una parte del sistema ad una serie di stimoli, di stato, che racchiudono i dati ed i servizi
necessari per implementare il comportamento definito dalle scatole nere, e chiare, in cui sono specificati i
dettagli procedurali. Ad ogni passo di raffinamento si svolge la verifica di correttezza. Il collaudo su basi
statistiche chiude questo interessante capitolo, seguito a ruota da quello sullingegneria del software a
componenti.
Questa prevede due attivit di ingegnerizzazione parallele: lingegnerizzazione del dominio, che esplora il
dominio di unapplicazione con lo scopo di individuare i componenti (funzioni, comportamenti e dati) che
possono essere candidati per il riutilizzo, e lo sviluppo per componenti. E importante soffermarsi un attimo a
riflettere cosa ha significato la nascita dellingegneria a componenti: limplementazione ha lasciato il posto
allintegrazione, uno dei mercati attualmente pi fiorenti dellindustria del software. Lanalisi del dominio
(http://www.sei.cmu.edu/str/descriptions/deda.html), in particolare, secondo alcuni potrebbe ben presto
diventare importante quasi quanto lingegneria del software, non fossaltro in quanto applicabile a
qualsiasi paradigma di ingegneria ed a qualsiasi tipo di sviluppo, convenzionale o ad oggetti. Vengono
brevemente presentati, naturalmente, i tre standard industriali pi affermati, ovvero CORBA, Microsoft COM
(mentre la sua evoluzione COM+ viene rimandata alla bibliografia di capitolo) e Sun JavaBean, ed il
comune modello ORB (Object Request Broker) che tutti e tre implementano.
La disponibilit di una vasta libreria di componenti riutilizzabili comporta, in maniera abbastanza ovvia, la
necessit di uno schema di classificazione che consenta di effettuare facilmente ricerche; sono stati proposti
vari schemi (http://research.microsoft.com/users/cszypers/events/WCOP2001/Lucena.pdf), tutti basati sul
modello 3C (Concetto, Contenuto e Contesto). Soprendentemente, la maggior parte del lavoro svolto finora
suggerisce limpiego dei tradizionali metodi bibliotecari, in luogo dei sistemi di intelligenza artificiale ed
ipertestuali. Lo sviluppo per componenti ha un significativo (e benefico) impatto sulla qualit del software: ad
ogni riutilizzo i difetti non rilevati nelluso precedente vengono individuati ed eliminati, convergendo verso un
componente virtualmente esente da difetti. Un interessante effetto collaterale dellingegneria per componenti
la possibilit di utilizzare come metrica di costo, invece dei LOC o dei Function Points, i punti struttura,
ovvero costrutti allinterno di un modello strutturale, che a sua volta un approccio ingegneristico sul
dominio basato su schemi ricorrenti nelle applicazioni. Nella pratica, i punti struttura coincidono con i
componenti o i package riutilizzabili; naturalmente, ad essi associato un costo in termini di validazione,
adattamento, integrazione e manutenzione. Manco a dirlo, unanalisi di tali costi facilitata dallesistenza di
una serie storica dei casi di utilizzo.
Lultimo capitolo tecnico del testo dedicato alla reingegnerizzazione. Nutro un particolare affetto per
largomento, come per tutte le cose che risalgono agli inizi della mia carriera, ma in generale il problema del
software reengineering non dovrebbe essere sottovalutato: vi capiter pi spesso di quanto pensiate dover
manutenere codice del quale si persa ogni traccia della documentazione (se mai esistita) ed ogni
riferimento al team di sviluppo, nonch i sorgenti nei casi peggiori. Il capitolo comincia per non con la
reingegnerizzazione del codice, ma con la ben nota BPR (Business Process Reengineering): non ho
naturalmente nulla in contrario ad una disciplina nata sotto i crismi della Harvard School, nonch alla
naturale evoluzione dei processi aziendali stessi alla radice di tanti progetti software (quasi la totalit se
consideriamo il caso italiano), ma credo che ognuno di noi abbia esperienza dei consulenti in giacca e
cravatta che vendono costosa aria fritta in salsa linguistica anglosassone.
Nei casi non patologici, invece, il BPR segue le buone prassi dellingegneria, a cominciare dal modello
iterativo ed incrementale; convinzione comune, almeno nel panorama scientifico, che una
reingegnerizzazione delle funzioni aziendali debba concentrarsi su processi o sottoprocessi individuali,
piuttosto che avventurarsi in una rischiosa rimodellazione dellintera gerarchia. Venendo al discorso della
reingegnerizzazione del software, non dovremmo mai dimenticare che lingegneria del software nata
proprio come risposta al problema delliceberg della manutenzione, ovvero di quelle applicazioni, evolutesi
selvaggiamente nel corso degli anni, per le quali ogni modifica si trasformava in una serie di effetti imprevisti
e gravi. La situazione oggi a dir poco preoccupante: la manutenzione di software esistente assorbe pi del
60% del lavoro in unazienda di produzione, e la percentuale in crescita.
A parte lobsolescenza (o la semplice non applicazione) delle tecniche di ingegneria in auge dieci o quindici
anni fa, il problema principe delle applicazioni legacy la mobilit del personale di sviluppo; vi qui un

15 di 16
infinito problema delluovo e della gallina fra Aziende che non investono in formazione e non valorizzano le
competenze, e programmatori sulla breccia da troppi anni, che si rifiutano ostinatamente di aderire alle
prassi di documentazione e standardizzazione perch temono di perdere lultima ragione della loro esistenza
aziendale. La reingegnerizzazione richiede tempo, ha costi rilevanti e assorbe risorse; un progetto di
reengineering destinato a durare parecchi anni. Il reverse engineering per il software consiste
nellanalizzare un programma al fine di produrne una rappresentazione ad un livello di astrazione superiore a
quello del codice sorgente; si tratta cio di recuperare un modello progettuale. Lattivit di
reingegnerizzazione pi comune la ristrutturazione del codice: se larchitettura di programma
relativamente solida ma il codice dei singoli moduli presenta problemi, lo si pu sottoporre ad analisi,
rilevando le violazioni dei principi di programmazione strutturata e modificando di conseguenza i sorgenti: le
prassi in materia sono cos consolidate, che spesso esistono strumenti in grado di effettuare
automaticamente la ristrutturazione.
Viceversa, un programma con architettura dei dati debole difficile da adattare e migliorare; a differenza di
quella del codice, la ristrutturazione dei dati unattivit di reingegnerizzazione a pieno titolo, che comporta
un alto livello di astrazione. E da tenere presente che ogni modifica ai dati si riflette in modifiche
allarchitettura o sul piano del codice. Un discorso a parte merita il forward engineering, che non solo estrae
informazioni di ordine progettuale da software esistente, ma utilizza queste informazioni per alterare o
ricostruire il sistema cos da migliorarne la qualit. Il capitolo esamina, naturalmente, tutte e tre le tecniche
citate.

Conclusioni
Il testo si chiude con uno sguardo sul futuro, ben consapevole dei limiti di ogni previsione: ma del resto, in
che altro modo si pu chiudere un testo storico nel suo campo? Comunque andranno le cose, facile
prevedere che lingegneria del software del ventunesimo secolo si occuper sempre di pi dellelaborazione
dellinformazione, cercando di estrarre conoscenza dalla sterminata mole di dati accumulata grazie
allinformatica negli ultimi sessantanni. E facile anche prevedere laffermazione delle architetture orientate
alla collaborazione. Vada come vada, il futuro spetta al software. E costruire il futuro spetter, ancora una
volta, agli ingegneri.

16 di 16