1 di 16

La difficile professionedell’ingegnere del software

di: Paolo De Nictolispubblicato il: 18/06/2006

IntroduzioneQuesto articolo nasce dalla lettura del testo “Principi di ingegneria del software – quarta edizione” di RogerS. Pressman, edito in Italia da McGraw-Hill(http://www.programmazione.it/index.php?entity=eitem&idItem=33643). Dopo aver finito di studiarlo, m isono reso conto che la mole di considerazioni ed appunti che avevo raccolto non poteva esaurirsi nellospazio di una, per forza di cose sintetica, recensione; ed è così nato questo lavoro. Troverete in essocontinui riferimenti al testo stesso, che ritengo una “lettura obbligata” per chiunque sia coinvolto, a qualsiasititolo, in un progetto software.“Nell’attività professionale il termine ‘ingegnere del software’ ha sostituito il termine ‘programmatore’”: è unadelle prime frasi della quarta edizione italiana (traduzione della sesta edizione inglese) del Pressman ma,purtroppo, è un’affermazione cui si potrebbero trovare molti controesempi nelle piccole realtà del softwarenostrano, alle quali gioverebbe molto la lettura di un’ottima (ed in molti capitoli semplice) panoramicaintroduttiva come questa.

Il processo di sviluppo softwareIl Pressman è ricco di citazioni, che “illuminano” la lettura. Dal canto mio, non posso che ricordare la miepreferite, 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 l’ingegnere software non può essere sostenuto da questa fede: moltedelle complessità che si trova a gestire sono di tipo arbitrario”. In quelle giornate un pò così (per l’ingegneredel software, una su tre), ci viene in soccorso Steve Wozniak: “Mai fidarsi di un computer che non puoilanciare 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 sonoriconosciuto, agli inizi della mia carriera, in ogni mito del programmatore: il lavoro è finito una volta rilasciatoil programma, che è l’unico frutto del lavoro svolto, mentre la documentazione serve a dare lavoro agliincapaci, ecc.), ma quando leggo i miti sui “volumi di standard e procedure che già abbiamo”, sull’ordamongola, sull’outsourcing totale e, soprattutto, sui “mutamenti che si gestiscono agevolmente grazie allaflessibilità del software” (cui aggiungerei la citazione di Paulk: “molto spesso i dirigenti ritengono che siameglio avere qualcosa di sbagliato piuttosto che in ritardo, poiché si può sempre correggere il software in unsecondo tempo”), mi tornano in mente, con un ghigno sarcastico e doloroso, tante scenette del mio lungofilm di architetto (“Se ti chiedessimo di cambiare le fondamenta ad un palazzo di cui hai già fatto dieci pianilo voglio capire che è un lavoro che ti richiede tempo, ma mi spieghi perché ci vogliono tre mesi per rifare lareportistica? Credi che abbia l’anello al naso? Lo sanno tutti che con i moderni IDE generate il codicepremendo un bottone!!!”). Nelle prime pagine del secondo capitolo trovo un’altra frase che mi piace molto, “ilprocesso 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 unostudio di architettura lo sanno più o meno tutti, mentre molte figure dirigenziali, quando escono i modelliciclici, il RUP, le metodologie agili e la programmazione Aspect-Oriented, devono appiccicare un bollino allaquarta 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 svilupposoftware non può non trovare posto il meta-modello CMMI (http://www.sei.cmu.edu/cmmi/), nel suo duplice

2 di 16

aspetto di modello continuo ed a fasi. Non si può sbrigare il CMMI in qualche pagina, ma al di là deldiventare 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 adottareanche un approccio di valutazione del medesimo come quelli descritti nel paragrafo 2.5, possibilmentetentando di non ridurre per esempio la ISO 9001:2000 alla “cosa che ci serve per partecipare alle gare”, o difar credere in giro che “abbiamo il marchio ISO 9001:2000, la ISO 9126 la facciamo automaticamente”. Perle software house nostrane esistono addirittura i processi personali e di team, più o meno tutti riconducibili atal Humphrey, tenendo presente che “il miglior processo di sviluppo software è quello più adatto alle personeche 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 disviluppo software, ma caratterizzandoli in modo da implementare molti dei migliori principi dello sviluppoagile”. Un breve paragrafo è anche dedicato all’Aspect-Oriented Programming: sostanzialmente, oltre alrimando 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 all’importanza dei casi d’usoscritti dall’utente, opera in un certo senso una rivoluzione copernicana nei processi di sviluppo, portata poialle estreme conseguenze dalle metodologie agili: l’analisi dei requisiti diventa una responsabilità condivisacon il committente, piuttosto che un “processo maieutico” guidato dall’analista. Al di là della descrizione dellecinque fasi, delle “4 viste + 1” e degli artefatti del processo, è importante sottolineare, ancora una volta, che ilteam di sviluppo adatta il processo sulla base delle proprie esigenze. Lo sviluppo agile, o ingegneria delsoftware leggera, la cui nascita si fa risalire al manifesto di Kent Beck e compagni del 2001(http://www.agilemanifesto.com, anche se per esempio l’eXtreme Programming risale sicuramente al 1999,secondo alcuni alla fine degli anni ’80, il DSDM al 1997, e Scrum addirittura al 1996), è oggetto del quartocapitolo.Molto si è detto pro e contro questo tipo di ingegneria, che pone l’accento sulla costituzione di piccoli gruppidi progetto, sulla soddisfazione del cliente e sul rilascio incrementale di software funzionante a scapito, adetta dei suoi detrattori, dell’analisi, della progettazione e della documentazione: in sostanza, dellasoddisfazione stessa del cliente, nel lungo termine. In effetti lo stesso Cockburn, un esperto di metodologieagili, le loda per la loro capacità di tenere conto del fattore umano nell’ingegneria del software (anche se avolte si stenta a crederlo, gli sviluppatori sono esseri umani con le loro fragilità e debolezze), ma ammette alcontempo che proprio per questo possono rivelarsi meno produttive dei processi prescrittivi.Potrei aprire qui un delicato discorso sull’equilibrio domanda/offerta di lavoro nel campo dell’informatica chedetermina richieste di produttività più o meno vicine agli standard umani, ma è meglio attenersi allarecensione 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 edimpegnativo 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 finoall’estremo ed orientato al risultato, che riceve lo stipendio di un metalmeccanico non specializzato allacatena di montaggio.Salomonicamente, Pressman non può che ricordare che, come tutte le metodologie, quella agile non puòessere applicata a tutti i progetti (l’ingegneria dovrebbe essere, nella sua forma migliore, il campo in cuimuoiono 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 dell’agilità (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 ambitodella scuola [i]agile[/i], sono stati proposti molti modelli a processo (Extreme Programming,http://www.xprogramming.com; Adaptive Software Development, http://www.adaptivesd.com; DynamicSystems Development Method, http://www.dsdm.org; Scrum, http://www.controlchaos.com; Crystal,http://www.crystalmethodologies.org; Feature Driven Development, http://www.thecoadletter.com; AgileModeling, http://www.agilemodeling.com, tutti presentati nel Paragrafo 4.3), e molti concetti dellametodologia agile non sono altro che adattamenti dei migliori concetti di ingegneria del software. L’averposto il capitolo sulle metodologie agili praticamente all’inizio del testo, ed i continui richiami “in avanti” ed“all’indietro”, testimoniano l’importanza che Pressman attribuisce loro.Personalmente, però, sebbene non metta in discussione (non lo fa nessuno) la validità di una seria epuntuale applicazione delle metodologie agili, sono molto dubbioso in merito ai fraintendimenti ed allemisinterpretazioni che possono ingenerare in ambienti immaturi (dal punto di vista dell’ingegneria delsoftware, of course....), sia dalla parte degli sviluppatori che (soprattutto) da quella dei clienti. Capisco cheuno dei fondamenti delle metodologie agili sia proprio quello di “eliminare ogni atteggiamento di tipo ‘noi eloro’”, ma è anche vero che la realtà è una brutta bestia quando si tratta di negarla. A mio avviso, le

3 di 16

metodologie agili forniscono straordinarie opportunità quando si verifichi una (miracolosa) “congiunzioneastrale” di elevate competenze fra gli stakeholder; negli altri casi, per quanto sia una prassi pedagogica pocoalla moda oggidì, ritengo che i bambini hanno bisogno di disciplina. Personalmente, per esempio, ho unagrande ammirazione per il principio alla base del DSDM: quanti di noi spendono il 20% del loro tempo persviluppare le funzionalità effettive di un prodotto software, e l’80% per renderlo usabile da un cliente che è....beh, siccome gli eufemismi vanno di moda, diciamo “non sempre un esperto di tecnologie informatiche”?Un’altra affermazione di Pressman su cui voglio richiamare l’attenzione, se non altro perchè è nascosta in unbox, è la seguente: “poichè lo sviluppo agile è di moda, la maggior parte dei produttori di strumenti softwaresostiene di fornire prodotti che supportano un approccio agile”. Mutatis mutandis, è una frase che ciaccompagnerà durante tutta la nostra (spero lunga) vita di informatici.

La pratica dell’ingegneria del softwareUna panoramica sugli aspetti pratici dell’ingegneria del software non può che essere incentrata sui due tipi dimodelli 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 dellaseconda parte si occupano, in sostanza, di presentare (senza, ahimè, alcuna pretesa di completezza) imetodi e le notazioni tecniche che consentono agli ingegneri software di creare i modelli analitici eprogettuali. Il primo passo è una visione ingegneristica non del solo software che si andrà a sviluppare, madell’intero sistema (hardware, software, database, procedure, persone...) in cui andrà ad inserirsi. Tutti gliingegneri del software (me compreso) sono degli entusiasti tecnologi, pronti ad attaccarsi all’IDE ed aprodurre codice, ma se ci si precipita a realizzare gli elementi tecnologici prima di comprendere il sistema, sicommetteranno indubbiamente degli errori che faranno irritare il cliente. E senza cliente, ahimè, di softwarese ne sviluppa (soprattutto in Italia) davvero poco.Naturalmente, occorre affrontare il duplice aspetto dell’ingegneria di processo e di prodotto. Il Capitolo 7affronta l’ingegneria dei requisiti, sostanzialmente l’incubo di ogni ingegnere del software. Inutile raccontarsiper l’ennesima volta le barzellette sul cliente che non ha idea dei tempi e dei costi, che ha una visionemiracolistica dell’ingegneria del software (“siete così bravini, voi col compiuter” – l’errore è intenzionale –“fate tutto in cinque minuti”) e che in conclusione è il cliente della vignetta di Dilbert: “Prima di cominciare asviluppare, dovremo fare dei lunghi incontri sul cosa sviluppare. In primo luogo: qual è il tuo obiettivo?” “Ilmio obiettivo è farti cominciare a scrivere il software”. Innanzitutto, il cliente peggiore è l’altro tipo di cliente.Non avete mai incontrato l’altro? E’ il cliente che ha la Patente Europea del Computer, o un qualsiasiattestato di formazione su Windows/Office, ed in forza di questa preziosa certificazione, di informatica necapisce molto più di voi. Ma al di là del nemico cliente, è vero purtroppo anche il contrario, ovvero che troppospesso l’ingegnere 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. Sipuò discutere a lungo se i requisiti che cambiano ad ogni minuto siano dovuti alla turbolenza del mercato oalla semplicioneria del cliente, ma la continua variazione dei requisiti è un dato di fatto: a volte, non si fanemmeno in tempo a buttare giù un documento riassuntivo, che sono già cambiati. Questo porta al secondoproblema, stavolta dalla parte degli sviluppatori: “visto che questi cambiano idea ogni momento, a che serveperdere tempo a fare l’ingegneria dei requisiti?”. L’ingegnere del software è un subdolo smanettone;paradossalmente, è il miglior amico del cliente delle barzellette, è il complice entusiasta del “comepretendete che vi dica sì o no sulla base delle vostre pile di carte? Datemi in mano un prodotto finito, ed io vidico come rifarlo daccapo”. Delle sette funzioni dell’ingegneria dei requisiti, va a finire che la più importante èla terza, la negoziazione. Oltre ai problemi evidenziati, non è infrequente il caso di utenti differenti chepongano 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 fattientro ieri e sono tutti troppo costosi.L’ingegneria del software è l’ultimo residuo della schiavitù nel mondo occidentale, è il mondo in cui il clienteti mette in mano mille vecchie lire e pretende la tua incondizionata disponibilità ventiquattr’ore suventiquattro, e quella dell’ingegnere del software è una battaglia persa in partenza. Come ogni bravoprofessionista, lo sviluppatore vorrebbe essere uno specialista, vorrebbe diventare l’esperto di driver in C++per l’industria elettromeccanica piuttosto che di interfacce Web con tecnologie Java. Gli viene invecerichiesto di essere uno sviluppatore-sistemista-DBA universale, esperto riconvertibile di tutti i linguaggi e ditutte le tecnologie, figura fungibile in tutte le fasi del ciclo di vita, consulente di tutti i possibili clienti in tutti ipossibili domini applicativi che siano mai stati inventati, oltre che team leader, commerciale ed ingegnere deiprocessi di business, della qualità e di tutto ciò che va di moda in giacca e cravatta. Con una particolarepropensione a fare il commerciale, è ovvio, ed il tutto ad un milione-e-ottocentomila vecchie lire al mese,come ricordato.

4 di 16

Insomma, per non divagare troppo, l’ingegneria dei requisiti è la fase del ciclo di vita del software che ha benpoco di informatico, e molto di umano. Il primo compito dell’ingegnere dei requisiti è quello di individuare glistakeholder 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 d’onore del rendere il cliente unmembro del team di sviluppo. Per frenare i conflitti uno dei metodi più utilizzati è quello dei punti di priorità: atutte le figure coinvolte nello sviluppo viene fornito un certo numero di punti, che possono essere spesi per ivari requisiti. E’ un metodo straordinariamente semplice, e nel contempo si è rivelato straordinariamenteefficace nel combattere la sindrome del “tutto è importantissimo, tutto va fatto subito”. Ovviamente il numerodi punti da distribuire può essere deciso in maniera arbitraria; il mio consiglio (non riportato nel libro) è: datemeno punti a disposizione, di quanti siano i requisiti, e obbligate ad attribuire un numero intero di punti. Allafine fate una matrice requisiti-votanti, e riempite solo gli incroci che hanno ottenuto punti. Ancor prima diesaminare i valori numerici, questa matrice vi aiuterà ad individuare non solo, com’è ovvio, i requisitiveramente importanti e quelli da spostare in fondo alla lista, ma anche e soprattutto le figure che hannovisioni contrastanti del progetto, nonché quelle il cui sguardo è concentrato solo su alcuni aspetti.Dopo la fase di avvio, vi sono solo tecniche dettate dall’esperienza, ma è sorprendente notare come questiinsiemi di regole, dettate solo dal buon senso, siano sistematicamente ignorate da tutti gli attori coinvolti.L’attenzione del testo si concentra sulla tecnica del QFD (Quality Function Deployment, http://www.qfdi.org),che pone l’accento nella suddivisione di requisiti in classi che generano un diverso grado di soddisfazionedel cliente. Inutile dire, infine, che una particolare enfasi è posta sul modello dei casi d’uso. Lamodellazione analitica, trattata nel Capitolo 8 ma già introdotta nel settimo, rappresenta un ponte fra ladescrizione del sistema ed il modello progettuale; in realtà è talvolta difficile definire una distinzione netta fraprogettazione ed analisi, anche perché tutti gli elementi del modello analitico rimandano direttamente alleparti del modello progettuale. La modellazione dei dati è una delle attività irrinunciabili della modellazioneanalitica, quella che di solito precede tutte le altre (primo o poi dovrò decidermi a recensire l’ultima versionedello storico ERWin, http://www3.ca.com/solutions/Product.aspx?ID=260). La modellazione analitica con idiagrammi UML prosegue con la creazione degli scenari, sotto forma di casi d’uso, diagrammi delleattività (Activity Diagram) e diagrammi Swimlane. Quest’ultimo è fondamentalmente un diagramma delleattività UML in cui viene indicato quale attore ha la responsabilità per ogni azione, suddividendo ildiagramma 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 dell’analisi strutturata, tramite i diagrammi DFD(Data Flow Diagram), continua ad essere una delle notazioni più utilizzate, anche in affiancamento aidiagrammi UML, caratteristici invece dell’analisi orientata agli oggetti. Poiché esiste un’ampia gamma diapplicazioni pilotate da eventi anziché da dati, è opportuno per essere affiancare la modellazione del flussodi controllo a quella dei dati, tramite i consueti strumenti della specifica del controllo (CSPEC), attuatasolitamente tramite il noto diagramma stati-transizioni, della specifica procedurale (PSPEC), ed altri. Lametodologia che riscuote più successo oggidì è sicuramente la modellazione basata su classi, cui vienededicato il resto del capitolo. E’ oramai invalso l’uso di determinare un primo elenco delle classi da unasemplice analisi grammaticale dei casi d’uso1, distinguendole fra classi necessarie per implementare lasoluzione (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 ‘nomeprocedurale imperativo’ (come “installa-sensore”) definirà un metodo di una classe, più che una classestessa. Occorre poi raffinare le classi individuate introducendo attributi e metodi. Per attribuire un grado dirilevanza 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 sueresponsabilità (gli attributi e le operazioni rilevanti per la classe) e le sue collaborazioni (che identificano lerelazioni fra le classi). Come afferma giustamente il testo, “E’ molto più economico gettare via un mazzo dischede che dover riorganizzare una mole ingente di codice sorgente”. E’ oggi in auge la prassi disuddividere le responsabilità fra le classi, in modo da non “concentrare l’intelligenza” del software, ma daavere 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 quelleclassi che devono essere organizzate in sottosistemi.Fino a questo punto, sono stati affrontati gli elementi statici del modello analitico. Un modellocomportamentale indica invece come il software risponde agli eventi, ed al passare del tempo. Tipiciprodotti della modellazione comportamentale sono i diagrammi stati-transizioni per ogni classe ed isequence diagram (che sono, in pratica, delle versioni abbreviate dei casi d’uso). La progettazione è,invece, quel creativo lavoro che praticamente ogni ingegnere desidera fare, e che raramente riesce a fare. Adifferenza del modello analitico, il modello progettuale fornisce dettagli relativi alle strutture di dati,

1 L’analisi di un linguaggio naturale è, naturalmente, soggetta ad errori ed ambiguità. E’ il problema alla base della nascita deimetodi formali, come quelli che usano le estensioni OCL o il linguaggio Z.

5 di 16

all’architettura, alle interfacce ed ai componenti del software che sono necessari per implementare ilsistema. Generalmente si progettano cinque viste, tra loro interrelate e piramidali:

1. i dati;2. l’architettura;3. le interfacce;4. i componenti;5. il deployment.

E’ tuttavia opinione comune, non solo dell’Autore, che “ad oggi la maggior parte delle metodologie diprogettazione del software non ha le doti di profondità, flessibilità e natura quantitativa che normalmentevengono associate alle discipline più classiche di ingegneria della progettazione”. Ciò che abbiamo sonometodi 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 diminor costo di reingegnerizzazione così efficacemente espresso dalla citazione dell’architetto Frank LloydWright: “Sul tavolo da disegno si usa la gomma, mentre sul cantiere si deve utilizzare la mazza”. Laprogettazione è indipendente dal modello di processo software utilizzato, e costituisce il ponte framodellazione e costruzione. L’input della progettazione è il modello analitico, espresso nella forma dielementi basati su scenari, basati su classi, orientati al flusso e comportamentali. La progettazione dei dati edelle classi avviene naturalmente per raffinamento delle classi e relativi attributi prodotte nella modellazioneanalitica, ed in particolare la progettazione dei dati assume maggiore dettaglio, in maniera iterativa, manmano che vengono progettati i componenti software.Un’interessante 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 progettazioneper componenti non solo costa, ma non ha nemmeno un ROI nell’immediato. Ma avremo occasione diriparlarne. E’ quasi inutile sottolineare quanto una buona progettazione influenzi la qualità del progettosoftware. Qualità intesa nel senso di manutenibilità e possibilità di collaudare il prodotto e valutarlo moltoprima delle ultime fasi del processo, quando le scadenze incombono minacciose e le ultime briciole delbudget vengono spese per lo spuntino di mezzanotte del team in concorde straordinario permanente. Unaccenno è fatto alle revisioni tecniche formali, oggetto di un paragrafo nel capitolo sulla qualità. Un’utilepagina richiama gli attributi di qualità FURPS (funzionalità, usabilità, affidabilità-reliability, prestazioni esopportabilità) definiti da Hewlett – Packard. Indipendentemente dagli attributi sui quali concentrarel’attenzione (un progetto porrà l’accento sulla sicurezza, un altro sulle prestazioni, un altro ancorasull’usabilità, è così via) occorrerebbe sempre ricordare che la qualità si applica durante, non dopo ilprocesso di ingegneria del software. Il capitolo del Pressman prosegue con un paragrafo dedicato ai principidi progettazione, nell’ordine:

1. Astrazione2. Architettura3. Modelli4. Modularità5. Incapsulamento delle informazioni6. Indipendenza funzionale (entrambe tecniche di riduzione della propagazione degli errori)7. Raffinamento8. 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 dettagliodal modello analitico a quello progettuale) e gli elementi di processo, che comprendono l’architettura,l’interfaccia, i componenti ed il deployment. Normalmente, lo sviluppo degli elementi dell’interfaccia e deicomponenti viene parallelizzato dopo la progettazione preliminare dell’architettura (che comprende laprogettazione dei dati), mentre il modello di deployment viene ritardato al termine del progetto. Il capitolo sichiude con l’interessante (e quantomai poco nota) progettazione del software basata su modelli. Uncostruttore di televisioni è abituato a lavorare con un corposo catalogo di componenti da assemblare come ipezzi delle costruzioni Lego, mentre l’attività preferita dell’ingegnere del software medio sembra essere lareinvenzione della ruota.Per quanto riguarda la progettazione dell’architettura, il testo enfatizza il ruolo dei componenti in ognirappresentazione. Più precisamente, vengono considerati due livelli: la progettazione dei dati e laprogettazione dell’architettura (rappresentazione della struttura dei componenti software e delle loroproprietà ed interazioni). Un breve paragrafo iniziale è riservato alla progettazione dei dati, con qualcheaccenno all’abusato argomento dei data warehouse. Il capitolo procede con una panoramica sugli stili e

6 di 16

modelli architetturali, da quelli basati sui dati alle più recenti architetture a livelli ed object-oriented. Laprogettazione dell’architettura comincia con un diagramma di contesto, che definisce le entità esterne (altrisistemi, dispositivi, persone) con cui il software dovrà interagire e la natura dell’interazione. Prosegue con ladefinizione degli archetipi, ovvero quelle classi o modelli che rappresentano un’astrazione fondamentale ecritica per progettare un’architettura per il sistema obiettivo, generalmente derivati a partire dalle classi delmodello analitico, così come i componenti che costituiscono la struttura del sistema. Il procedimento termina(in senso iterativo) con una istanziazione dell’architettura, ovvero la sua applicazione ad un determinatoproblema 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. Vienepresentato 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 diattributi di qualità e sui punti di sensibilità, ovvero sugli attributi che vengono influenzati in modo significativoda variazioni anche piccole dell’architettura. La complessità dell’architettura viene valutata con riferimentoalle dipendenze esistenti fra i vari componenti, un procedimento in cui può essere di aiuto il prodotto LattixLDM (http://www.programmazione.it/index.php?entity=eitem&idItem=33266), ed approfondito in parte nelCapitolo 15 dedicato alle metriche di prodotto per il software. Sin troppo breve il sottoparagrafo 10.5.3,dedicato all’importante argomento degli ADL (Architectural Description Language): troviamo solo un utileelenco di progetti di ricerca, e l’avvertenza che UML non è un linguaggio ADL completo. L’ultimo paragrafodel capitolo è dedicato alla progettazione strutturata introdotta da Yourdon e Constantine (prima delsuccesso dei linguaggi object-oriented), una tecnica orientata al flusso dei dati in cui rivestono notevoleimportanza i DFD (Data Flow Diagrams). Il testo sottolinea come la tecnica abbia ancora una sua ragiond’essere, ma sia inadatta per sistemi che richiedono sostanziali modifiche nel tempo o in cui l’elaborazionedei dati non è sequenziale.La progettazione a livello di componenti è un importante argomento, in parte ripreso dal Capitolo 25 dedicatoproprio alla CBSE (Component-Based Software Engineering). Il capitolo comincia con una definizione dicomponente, dal punto di vista dell’object-orientation, dell’ingegneria del software classica e di quella basatasui processi. Al di là dei distinguo, tutti gli approcci concordano nel definire un componente come un insiemedi logiche di elaborazione, strutture dati interne ed interfacce. Il capitolo prosegue con la progettazione deicomponenti basati su classi, introducendo i fondamentali principi di coesione ed accoppiamento e con unaparticolare 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 creazionedi astrazioni (solitamente interfacce) che fungono da buffer tra la funzionalità che deve essere estesa e laclasse progettuale. Ai diagrammi grafici UML è spesso opportuno affiancare dei vincoli espressi in unlinguaggio 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 l’OCL parser (http://www-3.ibm.com/software/ad/library/standards/ocldownload.html) di IBM, rivela la propria utilità anche nellaspecifica di pre- e postcondizioni per il completamento di un’azione specificata dal progetto.Per quanto il modello a componenti faccia spesso pensare ai linguaggi O-O, esiste una solida letteratura, ilcui precursore è Edsgar Dijkstra, sulla progettazione di componenti cosiddetti ‘convenzionali’ per linguaggiprocedurali, 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 costruttifondamentali di sequenza, condizione e ripetizione, e viene illustrato l’uso dei flowchart o diagrammi diflusso. Un paragrafo apposito è dedicato alla descrizione del comportamento di un componente inpseudocodice attraverso il PDL (Program Design Language). Il volume non presenta invece le reti diPetri; per un’introduzione all’argomento, si veda http://etd.adm.unipi.it/theses/available/etd-06282004-120407/unrestricted/capitolo2.pdf. Il capitolo 12 tratta la progettazione dell’interfaccia utente. Inutilenegarcelo: possiamo mugugnare quanto vogliamo sulle scarse conoscenze dell’utente finale, ma l’interfacciautente è come la giacca-e-cravatta al colloquio di assunzione. Indipendentemente da quanto impegno vengaprofuso nello scrivere ‘bene’ il codice, un’interfaccia utente mal realizzata porta a ritenere che il software sia‘scadente’. Lo stesso Pressman non trova meglio che cominciare col riepilogare le tre regole d’oro espresseda Mandel in un testo del 1997:

• lasciare che il controllo sia nelle mani dell’utente• limitare il ricorso alla memoria da parte dell’utente• usare un’interfaccia uniforme.

7 di 16

In poche parole: “non sottovalutate mai quanto stupido puo’ essere un utente”. Inevitabile il riferimento al sitoUseIt (http://www.useit.com) di Jakob Nielsen. La progettazione dell’interfaccia parte dalla considerazionedi 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 l’ambiente in cui opereranno le fasi diprogettazione, costruzione e convalida dell’interfaccia costituiscono un modello iterativo ed a spirale.L’interfaccia utente è il regno dei prototipi: è inutile aspettarsi di poter effettuare una verifica su carta delcomportamento di una variabile imprevedibile quanto un utente finale. L’analisi e la progettazione delleinterfacce, oggetto dei successivi due paragrafi, sono state inserite entrambe in questo capitolo in quantoopinione dell’Autore che, nel caso specifico delle interfacce utente, il confine fra le due sia troppo vago pernon trattarle insieme. Si presti attenzione a non sopravvalutare il confronto (scontro?) con l’utente finale:un’opinione forte non è necessariamente condivisa dalla maggior parte degli utenti. Ancora, un inputassolutamente da non sottovalutare è quello del supporto tecnico. Il testo non discute, se non in un brevebox riepilogativo, alcun modello di interfaccia utente, per i quali si viene rimandati ai numerosi testi inBibliografia.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à:l’utente è molto più disposto ad adeguare i suoi ritmi di lavoro ad un tempo di risposta standard, ancheabbastanza lungo, di quanto non lo sia ad adeguarsi ad “una macchina che non si sa se sputerà fuori ilrisultato fra due secondi o due ore”; peggio ancora, nel caso di un tempo di risposta indeterminato, èesperienza comune che l’utente non sappia mai decidere se il sistema sta lavorando o è bloccato in errore.Per quanto riguarda i messaggi d’errore, si finisce sempre col ripetersi le stesse barzellette su “Il moduloxxxyyyzzz ha determinato un errore oh123aaa9239203 nel modulo di sistema aaabbbcc”. Un discorso aparte, naturalmente, è quello sull’accessibilità, 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), unobbligo di legge. Ancora, è prassi comune sottovalutare i problemi di utilizzo di un software da parte di utentiche utilizzano una lingua diversa da quella dello sviluppatore; e pensare che esiste addirittura una Guidaall’internazionalizzazione del software (http://oss.software.ibm.com/icu/userguide/i18n.html) redatta da IBM.La valutazione delle interfacce utente è anch’essa un argomento sostanzialmente rimandato alla Bibliografia.Le strategie e le tecniche di testing del software, e le metriche di prodotto, sono oggetto degli ultimi trecapitoli della seconda parte; strettamente collegati alla qualità del software, sono pertanto ripresi neisuccessivi capitoli. Si tratta di argomenti che per me hanno sempre rivestito un fascino particolare; a chi noncondividesse il mio entusiasmo, voglio ricordare la citazione di Yourdon (scritta, è il caso di ricordarlo, moltianni prima dell’analoga 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 ilmaggior numero possibile di errori, con un impiego di risorse ragionevole: su questo siamo tutti d’accordo. E’anche oramai affermato nella teoria (ma quanto mai poco utilizzato nella prassi) che qualunque strategia dicollaudo deve incorporare:

1. la pianificazione,2. la progettazione dei casi di prova,3. la loro esecuzione e4. la raccolta e valutazione dei risultati.

Il motivo per cui si conducono, di solito, pessimi test è un errore metodologico di base: il collaudo viene vistocome la fase in cui si “inietta” la qualità nel sistema, come se la qualità fosse un’’appendice’ e non una parteintegrante 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 dimolto creativo, ma è pur vero che probabilmente non ne scriverei proprio). E’ invece abbastanza affermato ilprincipio di collaudo ‘dal piccolo al grande’, procedendo per aggregazione di gruppi di componenti, salvo chenei ‘figli del COBOL’ e negli studenti di Informatica, due gruppi di sviluppatori accomunati dalla passionenella scrittura di lunghissimi listati che immancabilmente non vengono compilati.Il testo interviene salomonicamente nella lunga discussione che ha per oggetto se il collaudo debba essereaffidato allo stesso sviluppatore o ad un gruppo esterno, affermando che i test di unità ed integrazione sonoa carico del gruppo di sviluppo, mentre nelle fasi di validazione entra in gioco l’ITG (Independent TestGroup) che collabora con gli sviluppatori. Vengono presentate le strategie di collaudo per il software

8 di 16

convenzionale e ad oggetti; sostanzialmente, per entrambi vengono adottate le medesime quattro fasi ditest:

1. di unità (singolo modulo o classe),2. di integrazione,3. di convalida (ovvero rispetto dei requisiti) e4. di sistema.

Il testing di software ad oggetti differisce significativamente da quello di software convenzionale nella fase diintegrazione, perché naturalmente il software O-O non una struttura di controllo gerarchica ovvia, checonsenta di scegliere una strategia top-down, bottom-up o intermedia. In tal caso vengono usate due diversestrategie: il collaudo thread-based integra l’insieme di classi necessarie per rispondere ad un input o ad unevento del sistema, lavvove quello use-based inizia collaudando le classi indipendenti, per poi aggiungeregradualmente le classi dipendenti. Viene poi trattata la convalida, distinguendo in particolare i collaudi alfa(effettuati dall’utente in presenza dello sviluppatore) da quelli beta (in cui lo sviluppatore è assente); è quasiinevitabile la citazione da “La cattedrale ed il bazar” (http://www.catb.org/~esr/writings/cathedral-bazaar/). Ilcollaudo 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 ildebugging possa e debba essere un processo disciplinato, rimane a tutti gli effetti un’arte, addirittura una‘dote innata’ secondo alcuni studi. Al di là della presenza di strumenti semiautomatici di debugging, rimanesempre valido il vecchio consiglio “quando sbatti la testa da tre ore su un bug, fai vedere il codice ad uncollega” (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 ilprogramma, o black-box. I due approcci, sorprendentemente, non sono contrapposti, ma complementari: èdavvero utile provare a risolvere l’esercizio finale, che chiede di fornire tre esempi in cui il collaudo black-boxnon rileva problemi mentre quello white-box scopre un errore, e viceversa. Ad ogni buon conto, per motivilegati più che altro alla complessità computazionale, è prassi usare il collaudo white-box nei test di livelloinferiore, ovvero di unità e di integrazione, e quello black-box nei test di convalida e di sistema. L’elenco deimetodi white-box parte con un mio vecchio amore, che ha segnato gli inizi della mia carriera, ovvero ilcollaudo per cammini di base elaborato da McCabe. Sostanzialmente, questo metodo si basa sull’intuitivaidea che più un programma è ‘complesso’, più elevata è la probabilità che contenga errori; la nozioneintuitiva di complessità viene misurata tramite un indice metrico, la complessità ciclomatica, che tiene contofondamentalmente dei costrutti decisionali e viene solitamente calcolata a partire dal grafo di flusso delprogramma. E’ bene sottolineare che, naturalmente, tale indice consente solo una “scrematura” su basestatistica delle parti più soggette ad errori: un modulo di programma potrebbe avere un indice ciclomaticobassissimo, ed essere tuttavia pieno di bug.La complessità ciclomatica pone un limite superiore al numero di collaudi che devono essere condotti pergarantire che tutte le istruzioni vengano verificate almeno una volta; la parte interessante del metodoMcCabe è che la costruzione del grafo di flusso ed il calcolo di una base di cammini linearmenteindipendenti (fondamentalmente, percorsi di test che ‘tocchino’ tutte le istruzioni) sono attivitàautomatizzabili con l’ausilio di una matrice di grafo di flusso. Altri metodi di testing white-box, checompletano l’analisi 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 l’accesso sull’uso digrafi che descrivano le chiamate di un programma, sulla suddivisione dei possibili dati d’ingresso in classi diequivalenza per ridurre il numero di test significativi, sull’analisi dei valori limite (fortunatamente, oltre adessere una delle più importanti, è anche una delle più utilizzate; la maggior parte dei programmatori saperfettamente 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, senzaaspettare la scrittura del codice, dall’altro reso più complicato dai problemi legati all’ereditarietà. Per quantoriguarda i test delle singole classi, si suole utilizzare un collaudo casuale, che invoca una serie ‘plausibile’ dimetodi della classe, ed uno a partizionamento, fondamentalmente l’analogo O-O della suddivisione in classidi equivalenza. Vi sono infine metodi di collaudo speciali per le interfacce grafiche, le architettureclient/server, la documentazione ed i sistemi real-time (che introducono l’ulteriore variabile tempo), mentre iltesto rimanda ai classici in Bibliografia per l’analisi dei modelli di collaudo. La definizione di metriche per ilsoftware è da sempre un obiettivo di tipo ingegneristico (non vi è ingegneria dove non vi è misura) volto astabilire la qualità del software realizzato; i primi fattori di qualità storicamente elaborati, ovvero i fattori d’uso,di revisione e di transizione del prodotto di McCall ed i sei attributi dello standard ISO 9126, sono però di tipoqualitativo. In effetti, ad oggi, tutte le metriche definite sono solo misure indirette della qualità: nonmisuriamo cioè direttamente la qualità del software, ma alcune sue manifestazioni. L’argomento è ancora indivenire, tanto che si rende necessario un paragrafo che introduca il quadro di riferimento: la differenza fra

9 di 16

misure, metriche ed indicatori, i principi della misurazione, il paradigma GQM (Goal/Question/Metric) per lamisurazione orientata all’obiettivo, ed un panorama delle metriche di prodotto.Le metriche per il modello concettuale partono dall’assunto, simile all’equazione ‘complessità = numero dierrori’ alla base del metodo McCabe, che sia ragionevole pensare che la taglia e la complessità del modelloprogettuale siano direttamente correlate. La prima, importante metrica che viene esaminata è quella deipunti funzione o Function Points (FP). Il metodo è stato proposto inizialmente da tal [b]Albrecht[/b] dellaIBM Research nel 1979 e gode di un crescente consenso nella comunità, tanto che è stato adottato comecriterio di stima e valutazione dei progetti software dal CNIPA (Centro Nazionale per l’Informatica nellaPubblica Amministrazione, http://www.cnipa.gov.it). Il conteggio dei punti funzione è standardizzato in unmanuale revisionato periodicamente dall’IFPUG (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 misurecalcolabili (dirette) nel dominio delle informazioni del software e valutandone la complessità; un databasestorico di progetti aiuta poi il project manager nell’associare la complessità di un’applicazione in puntifunzione all’impegno in mesi-uomo necessari, stabilito il linguaggio di programmazione, ed a valutare ilnumero di errori che ci si aspetta di trovare nell’implementazione. E’ necessario in primo luogo valutare uninsieme 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 dell’interfaccia 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 esommati dei fattori di aggiustamento (VAF) determinati dalla risposta ad una serie di domande (reperibiliall’URL http://www.ifpug.com/fpafund.htm), espressa come ‘voto’ da 0 a 5. Si tratta, naturalmente, di unmetodo soggettivo, che segue però dei criteri standard internazionalmente riconosciuti, applicati da esperticertificati. I Function Point sono un importante argomento che viene ripreso nel capitolo 17, ove si cerca dimetterli 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 dicoerenza, fondato sull’accordo fra le interpretazioni date dai revisori a ciascun requisito, ad una serie dicaratteristiche di tipo qualitativo. Le metriche di progettazione comprendono un insieme di indici suddivisi inmetriche di alto livello, orientate agli oggetti, orientate alle classi, a livello di componenti, orientate alleoperazioni e per la progettazione di interfacce. Sulle metriche per il codice sorgente viene fatto un accennoal controverso lavoro di Halstead, basato sul numero di operatori ed operandi presenti nel codice esottoposto a numerose verifiche sperimentali dal 1977 ad oggi. Per quel che riguarda il testing, lamaggioranza delle metriche proposte è rivolta al processo di collaudo, non alle caratteristiche tecniche delleprove in sé. Per il software procedurale si usano metriche derivate dalle misure di Halstead, ed ugualmenteper il software ad oggetti le metriche di progettazione hanno un’influenza diretta sulla collaudabilità di unsistema O-O, e vengono considerati gli aspetti relativi all’incapsulamento ed all’ereditarietà.Per quanto riguarda infine la manutenzione, l’IEEE ha proposto uno specifico standard, SMI (SoftwareMaturity Index) che riassume il grado di stabilità di un prodotto software sulla base delle modificheapportate alle nuove versioni del prodotto. Calcolato a partire dal numero di moduli finali, modificati, aggiuntied eliminati, si suppone che al tendere di SMI ad 1 il prodotto tende a stabilizzarsi, e che il tempo medionecessario per produrre una nuova versione del prodotto è correlato ad SMI, per cui si possono svilupparemodelli empirici di previsione dell’impegno di manutenzione. Dal punto di vista dei tool software disponibili,solitamente il calcolo di alcune metriche è implementato come funzionalità aggiuntiva di più vasti strumenti dianalisi e progettazione, programmazione o collaudo.

Gestione dei progetti softwareL’interessante argomento del Project Management non può prescindere da una necessaria panoramica sullequattro P (persone, prodotto, processo e progetto); l’ordine delle quattro P non è casuale, e per le persone ilsolito Software Engineering Institute ha elaborato addirittura un modello di maturità della capacità di gestionedelle 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 consistesemplicemente nel rispondere a sette domande, le cui iniziali danno il nome al metodo, il cui immensovantaggio è quello di essere applicabile indipendentemente dalle dimensioni o dalla complessità del progetto

10 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 unapprofondimento 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: lemisurazioni di processo portano a miglioramenti a lungo termine, laddove ovviamente quelle di progettoservono a guidare i lavori in corso. L’efficacia di un processo di sviluppo software si misura indirettamente: apartire da informazioni derivate dal processo si ricava una famiglia di metriche. E’ opportuno che le metrichedi processo rimangano private, ovvero non attribuite ai singoli individui del team ma raccolte su basestatistica, per evitare inutili rimpalli di responsabilità; viene suggerito addirittura un “galateo” nella raccoltadelle metriche.Le metriche dimensionali sono quelle storicamente usate per prime e per le quali esiste il più vasto corpus distudi, si basano fondamentalmente sulle LOC (linee di codice) prodotte, e sono naturalmente le piùcontroverse: i principali argomenti contro l’uso 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 l’attività creativa dello sviluppatore ad un lavoro ‘a cottimo’ simile a quello delloscaricatore 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 alfallimento. Anche le più recenti metriche basate sulle funzioni, la più utilizzata delle quali è il metodo basatosui Function Points, hanno però i loro detrattori: sono in molti a far notare che l’elemento di soggettività èalto (due esperti del metodo dei punti funzione possono arrivare a risultati diversi per lo stesso prodotto) eche i punti funzione non hanno alcun significato fisico diretto. Sono stati condotti peraltro vari studi perriconciliare i risultati ottenuti con le metriche LOC ed FP, anche dallo stesso Albrecht, e tenendo conto che larelazione fra le due metriche dipende dal linguaggio di programmazione utilizzato. Se guardiamo alla tabellariportata nel testo, comunque, scopriremo che, quale che sia il linguaggio di programmazione scelto, lavarianza 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 dell’impegno 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 unagranularità sufficiente per valutare correttamente le iterazioni svolte tramite processi evolutivi o incrementali.Un’importante metrica di qualità del software è invece la DRE (Defect Removal Efficiency, o efficienza dirimozione dei difetti), ovvero una misura della capacità di rimuovere gli errori (non-conformità ai requisitiscoperti prima del rilascio alla fase successiva) prima che divengano difetti (non-conformità ereditate dallafase del ciclo di vita precedente). L’integrazione delle metriche nel processo software, con una particolareattenzione per le piccole aziende (con meno di 20 sviluppatori), e la definizione di un programma divalutazione metrica del software, con i dovuti riferimenti al Guidebook for Goal-Driven SoftwareMeasurement (http://www.sei.cmu.edu/pub/documents/96.reports/pdf/hb002.96.pdf), chiudono il capitolo. Isuccessivi capitoli della terza parte coprono le cinque attività della conduzione di un progetto software:

• la stima,• la pianificazione,• l’analisi 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 voltache il processo è completato, quando non serve più. Tuttavia, il grado di incertezza può essere ridottoadottando almeno due metodi di stima, e riconciliando i risultati ottenuti. Un processo di stima cominciadefinendo la portata e la fattibilità (tecnica, finanziaria, temporale ed in termini di risorse) del software. Lastima delle risorse comprende persone, componenti software riutilizzabili ed ambiente di sviluppo (strumentihardware e software). Per avere stime affidabili, ci si serve di tecniche di scomposizione e di modelli empiricidi stima. L’esempio adottato per le tecniche di scomposizione vi darà modo di farvi una sana risata: si parladi “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 l’impegno in mesi/uomo; ognuno dei modelliproposti in letteratura produce un risultato diverso per lo stesso valore di LOC o FP, per cui i modelli di stimadevono essere adattati alle esigenze locali. Il modello di stima probabilmente più noto al mondo è ilCOCOMO II (http://sunset.usc.edu/cse/pub/research/COCOMOII/cocomo_main.html) originariamenteproposto da Boehm nel suo classico testo “Software Engineering Economics”

11 di 16

(http://www.amazon.com/gp/product/0138221227/002-6561127-5158441?v=glance&n=283155), ma neesistono anche altri, quali l’equazione del software di Putnam e Myers (basato su una serie storica di 4000progetti).Particolari accorgimenti vanno adottati per la stima dei progetti O-O e per i progetti di breve durata, conparticolare 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 all’esterno. Lapianificazione del progetto comincia con l’importante argomento dell’allocazione delle risorse umane. Il mito“Se siamo in ritardo, possiamo aggiungere altri programmatori e recuperare” viene sfatato, oltre che dalbuon 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, cidice che:

• non ha senso comprimere i tempi di progetto più del 75% di quelli ottimali• lungo l’asse 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 dall’impiegare 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% dell’impegno all’analisi ed allaprogettazione, 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 suddivisionein un insieme di compiti, collettivamente denominati anche WBS (Work Breakdown Structure), e lapianificazione temporale passano, ovviamente, per le note tecniche PERT (Program Evaluation and ReviewTechnique) e CPM (Critical Path Method). Al di là delle differenze, entrambe le tecniche forniscono strumentiquantitativi che consentono al pianificatore di determinare il cammino critico, ossia la catena di compiti chedetermina la durata di un progetto, stabilire le stime dei tempi più probabili e definire le finestre temporalientro cui ciascun compito deve essere iniziato e terminato. Nessun approfondimento è dedicato aPERT/CPM, mentre un breve paragrafo illustra l’uso dei diagrammi di Gantt. Un paragrafo finale è dedicatoad una nota tecnica quantitativa, dovuta ad Humphrey, per stabilire i progressi compiuti durante losvolgimento del progetto: l’analisi del valore aggiunto o EVA (Earned Value Analysis,http://www.acq.osd.mil/pm/).Il capitolo sull’analisi dei rischi presenta argomenti molto noti ai cultori della disciplina, naturalmente adattatial panorama dello sviluppo software, che in molti casi, come al solito, si riassumono in una serie di pratichedi buon senso. L’approccio è quello classico del prodotto probabilità x conseguenze dei singoli fattori dirischio, corredato naturalmente da un’analisi costi/benefici (nessuno compra mai una cassaforte dacentomila 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 utilizzandoun foglio informativo RIS (Risk Information Sheet), che riassume in una forma simile ad un caso d’uso tutti iparametri quantitativi individuati (probabilità/conseguenze, raffinamento e contesto, riduzione emonitoraggio, esposizione al rischio RE, ovvero prodotto della probabilità per il costo del rischio qualora siverifichi, stato, ecc.).Venendo al capitolo sulla qualità, l’analogia di Philip Crosby fra la qualità ed il sesso meriterebbe da sola ilprezzo di copertina, ma al di là delle battute, e delle giuste precisazioni sulle attività e metriche per lagaranzia della qualità, mi ha molto colpito un’affermazione: “Chiunque sia coinvolto nel processo diingegnerizzazione del software è anche responsabile della sua qualità”. Pensare ad un Reparto Qualità cheassicura la magica ‘Certificazione ISO 9001:2000’ mentre lo sviluppatore continua ad operare in puraanarchia, o magari dopo che è stato prodotto il codice, viene sempre più riconosciuta come un’amenità. Allabase di ogni processo di qualità vi è il controllo delle variazioni: non è forse, del resto, la ripetibilità uno deifondamenti del metodo scientifico? Naturalmente, tale tipo di controllo presuppone una misurabilità delsoftware, già oggetto del Capitolo 15. Il fondamento su cui misurare la qualità sono i requisiti: la mancanza diconformità ai requisiti è una mancanza di qualità. Se dei requisiti espliciti del cliente si è già discusso, esisteuna serie di requisiti impliciti (ad es. la facilità di manutenzione) la cui mancata soddisfazione è un sicuroindice di scarsa professionalità.La revisione tecnica formale è un argomento citato ad ogni piè sospinto nel testo: finalmente ne troviamoin 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 disviluppo: molti si stupirebbero nel sapere che durante le attività di progettazione si introducono fra il 50 ed il65% di tutti gli errori; alcuni studi affermano che le tecniche di revisione formale possono scoprire fino al75% degli errori di progettazione. Per aiutarci contro il management che ci parla dei ‘costi della qualità’, ci

12 di 16

viene stavolta in aiuto uno studio della stessa IBM: se la correzione di un errore rilevato durante laprogettazione costa 1 unità, il costo prima dei collaudi sale a 6,5 unità, durante i collaudi a 15 unità, dopo laconsegna ad un valore compreso fra 60 e 100 unità; non considerando il danno di immagine in quest’ultimocaso, ovviamente. Non male come argomento da usare contro il caporale che ci minaccia: “non stailavorando, stai scrivendo carte!”. Desta raccapriccio anche esaminare i modelli di propagazione dell’errore,sempre prodotti da IBM; al manager che ne capisce solo di vile denaro, si può far notare che i modelliconducono 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, opagare molto di più in seguito”: un argomento che ha ben poca presa per molte PMI italiane, che giornodopo giorno non sanno se ci sarà un ‘seguito’ (ma molto spesso non hanno mai lavorato perché ci fosse).Un’Azienda che ha una ragionevole certezza di rimanere sul mercato per tre anni non ha, invece, alcunascusa: 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 hamai pensato che una FTR è un’ottima palestra per un neoassunto, permettendogli di osservare diversiapprocci all’analisi, progettazione e implementazione del software?Come per i team di sviluppo, così per le riunioni di revisione condivido l’idea del gruppo limitato (da tre acinque 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 perFTR. Un altro consiglio che mi sento di sottoscrivere è quello classico del pair programming: fate esaminareil prodotto da qualcuno che non l’ha realizzato. Per le revisioni valgono alcune prassi da adottare in tutti i tipidi 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 l’umana 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 l’ultima riunione cheriuscirete ad organizzare.

Per quanto riguarda la preparazione della riunione, insistete fino alla morte perché i partecipanti sipresentino con una serie di commenti scritti sul materiale esaminato. Tutti sono convinti di aver capito allaperfezione 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 diappunti “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 cheavrete ottime probabilità di ritrovarvi con una documentazione di prodotto che presenti correttamenteevidenziati i concetti – chiave. Visto che “nel mondo reale dei progetti software, le risorse sono limitate ed iltempo manca, è opportuno raffinare le tecniche di campionamento dei prodotti dell’ingegneria del softwareda 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 perl’assicurazione della qualità. Ribadisco comunque il problema espresso precedentemente: tutti i metodiquantitativi ad oggi conosciuti si basano sull’esame di dati storici, per cui dovremmo pensare ad un’Azienda,che comincia a ‘fare qualità sul serio’ (nel concreto, a salire livelli del CMMI) non meno di quattro-cinque annidopo aver cominciato a raccogliere metriche sul software, esigenza che, come ho già ricordato, viene inmente (quando viene in mente) quando si ha una ragionevole certezza di rimanere sul mercato per tre anniancora. Un’altra lezione non riportata sul testo, parte dell’esperienza che voglio trasmettervi, è la seguente:la documentazione è relativamente semplice da produrre; la vera difficoltà sta nel mantenerla in linea con ilcodice, giorno dopo giorno, anche quando le scadenze incombono. Un piano di ingegneria del softwaredovrebbe sempre individuare, dinamicamente nel corso dell’evolversi del progetto, quell’insieme di attivitàvolte all’assicurazione della qualità che lo sviluppatore deve eseguire anche quando il fuoco ha raggiunto lascrivania, i terroristi hanno fatto irruzione nell’ufficio o mancano cinque minuti all’inizio della finale deiMondiali di calcio. Inutile tenerle ‘nel cassetto’, anche se il rischio che il team finisca per fare solo quelle èmolto alto: in un’attività come lo sviluppo di software, la chiave del successo non sta nell’imposizione, manella condivisione degli obiettivi.L’analisi di affidabilità del software, inizialmente condotta cercando di applicare mutatis mutandis i metodimatematici della teoria dell’affidabilità dell’hardware (particolarmente consolidati), ha finito per scontrarsi conun’insanabile difformità di scenario: tutti i guasti di un prodotto software risalgono a problemi di progettazione

13 di 16

o di implementazione, mentre l’usura non esiste; esattamente il contrario, insomma, degli assunti di base perl’hardware. Rimane comunque valido l’approccio basato sul tempo medio fra i guasti (MTBF, Mean TimeBetween Failure) e sulla disponibilità, fortemente legata al tempo medio di riparazione. Un breve paragrafo,quasi d’obbligo, sullo standard ISO 9001:2000 chiude il capitolo, che purtroppo non sfiora nemmenostrumenti classici di gestione della qualità come gli schemi di controllo, i diagrammi a dispersione, quelli diaffinità e quelli a matrice.“Se non controllate i cambiamenti, saranno i cambiamenti a controllarvi”: così comincia l’ultimo capitolo dellaterza parte, dedicato alla gestione delle configurazioni software, argomento su cui in Programmazione.it èpresente una mia recensione di un testo di Brian A. White sull’argomento, focalizzato sull’uso dell’alloraRational ClearCase (http://www.programmazione.it/index.php?entity=eitem&idItem=32149). Parte delmateriale del capitolo è stata tratta dai numerosi lavori di Susan Dart, della Carnegie Mellon University, sultema (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à didotarsi 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à, condivisaanche dal testo, è che l’archivio del progetto si trovi in un luogo centralizzato e controllato. Un elemento daporre sotto configurazione cui pochi pensano all’inizio 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 nondanno mai lo stesso risultato.E’ quasi superfluo sottolineare che ad giorno d’oggi tutti gli strumenti per l’SCM (Software ConfigurationManagement) si avvantaggiano di un archivio implementato come DBMS, ma pensate a quanto sono ancoradiffusi gli “archivi umani”, ovvero gli sviluppatori o responsabili nella cui testa o nei cui cassetti si annidal’intera conoscenza di un progetto (molto spesso, solo perché è rimasto l’unico motivo della loro esistenzaaziendale). Soffermate la vostra attenzione sulla Figura 22.3; possibilmente, fatene una fotocopia in grandeformato ed appendetela al muro. Descrive il contenuto di un archivio di SCM; se nel vostro progetto mancaqualcuno di questi elementi, fermatevi cinque minuti a riflettere se è perché il vostro progetto è abbastanzasemplice 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 monitoraggiodelle dipendenze e dei requisiti, la gestione delle release, la reportistica e l’audit (chi ha fatto cosa, equando).Posso assicurarvi che per quanto riguarda l’audit rischiate facilmente di trovarvi in ufficio le barricate e gentecon l’elmetto ed il fucile. Ricordate sempre la massima di Bennet: “ogni cambiamento, anche se è unmiglioramento, è sempre accompagnato da inconvenienti e disagi”. Una funzionalità essenziale di unsistema 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, peresempio, 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, peresempio Makefile. Un limite ineliminabile di questo strumento, peraltro meritoriamente assai diffuso, è inveceil fatto che non implementa un processo di controllo delle modifiche (per esempio richieste di modifica, reportdelle modifiche, monitoraggio di bug). Infine, lavorate per una breve settimana in un team (ovvero almenocon un’altra 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 venirealla mente mille telefonate (di due minuti l’una) del cliente, che si sono trasformate in una catena gerarchicadi n-mila telefonate (di un minuto l’una) culminate nello squillo del telefono sul tavolo dello sviluppatore.Considerate i lavori di Shannon sul deterioramento dell’informazione nel passaggio in una catena dielaborazioni, ed il gioco è fatto. Chi vuole avere qualche speranza di evitare i week-end in ufficio dovrebbeinvece imparare a memoria una delle note finali: “è probabile che un controllo ‘un po’ eccessivo’ sia quellopiù appropriato”. Il momento immediatamente successivo all’approvazione della modifica è simile a quello incui il paracadutista ha appena staccato il piede dall’aereo: chi garantirà che la modifica sia statacorrettamente effettuata?La risposta, in cui perseverare con la dovuta disciplina, è una revisione tecnica formale per tutte lemodifiche, tranne le più banali (ed in un progetto software complesso, scoprirete a vostre spese che dibanale c’è ben poco. Siete davvero sicuri che semplicemente modificando la lunghezza di un messaggiod’errore nulla cambierà? Provare per credere…). A proposito: siete sicuri di sapere chi sono, per ognimodifica, tutte le persone che debbono venirne a conoscenza? Per finire: avreste mai creduto che in materiadi SCM esiste una nutrita serie di standard IEEE, ISO, EIA e militari? Il testo non accenna nemmeno alproblema del numbering delle versioni. In proposito, posso dirvi che nel management è diffusa l’idea che ilnumbering non debba nemmeno esistere, ovvero: tutti i prodotti devono portare come numero di versione1.0, 2.0 e così via, per far credere che ognuno di essi è un prodotto innovativo e perfetto. Una favoletta alla

14 di 16

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

Argomenti avanzati dell’ingegneria del softwareLa quarta parte, dedicata agli ‘argomenti avanzati’, occupa opportunamente un posto a sé, ma non dovrebbeesserne trascurata, pur con qualche oggettiva difficoltà per chi non padroneggia gli strumenti matematicinecessari, la lettura. In particolare modo, non vi sono scuse per non studiare il Capitolo 25 sull’ingegneriadel software a componenti, che sempre più potrebbe essere l’unica strada per uscire dall’impasse deiprogetti sempre più complessi con tempi e budget sempre più ristretti. Si comincia con il capitolo sui metodiformali, culminante naturalmente nell’introduzione ad OCL (Object Constraint Language) e Z. La chiavedei metodi formali sta in una specifica non ambigua dei prerequisiti, utilizzando la teoria degli insiemi e lanotazione logica. Il campo di applicazione più naturale di questi metodi è il software mission-critical, ed ineffetti troviamo riferimenti al lavoro di Warmer e Kleppe, pubblicato in versione aggiornata nel 1999 dallaAddison-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 aconseguire la mancanza di ambiguità e la coerenza delle specifiche, mentre al momento è assai più difficileraggiungere la completezza. Le basi matematiche per l’applicazione dei metodi formali richiedono solo laconoscenza di alcune nozioni di teoria degli insiemi davvero banali per chi ha seguito un corso di studiuniversitari scientifico (ma quanti, fra i key decisors aziendali, l’hanno seguito?). Veniamo, finalmente, ai duelinguaggi formali presentati nel capitolo. OCL è, in effetti, non un vero e proprio linguaggio formale, ma unlinguaggio di modellazione, pur con tutti gli attributi di un linguaggio formale; esso infatti costituisce unaparte delle specifiche UML standardizzate da OMG, poiché è stato pensato come un’’estensione’ formaleper consentire agli utilizzatori di UML di impiegare una maggiore precisione nelle loro specifiche.Per facilitarne l’adozione e renderlo più facilmente elaborabile dai calcolatori, i progettisti hanno sostituito lanotazione matematica convenzionale con caratteri ASCII, rendendolo però al contempo più prolisso. OCLaggiunge un insieme di condizioni o vincoli ad un diagramma UML (tipicamente delle classi, degli stati odelle attività), ed è un linguaggio object-oriented, che utilizza anche i classici operatori O-O come quello direferenziazione o la dot notation. L’esempio d’uso di OCL, un gestore di blocchi per file system, introducetutti 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 vent’anni di storia. Sibasa sulla logica dei predicati di primo ordine per costruire degli schemi, ovvero l’equivalente nel campodelle specifiche formali di una subroutine o procedura in un linguaggio di programmazione. Uno schema in Zdescrive i dati memorizzati che un sistema consulta e modifica, ovvero ciò che in Z si chiama stato. Si trattadi un linguaggio notevolmente più formale di OCL, ma chi ha dimestichezza con la logica degli insiemi netrarrà notevoli vantaggi. Nel campo degli strumenti, purtroppo, troviamo solo progetti di ricerca: focalizzandol’attenzione 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 allaleggera ma, come al solito, pesando una serie di fattori: i principali sono la valutazione dei costi d’adozione,piuttosto alti nelle fasi iniziali, e la scelta dei componenti cui applicarli. E’ importante notare, però, che imetodi formali possono essere in concreto l’unica strada per creare librerie di componenti riutilizzabili. Unesempio di processo in grado di incorporare i metodi formali nell’ingegneria del software tradizionale è laproduzione di software in camera sterile (cleanroom), proposta per la prima volta da Mills, Dyer e Ginger nel1987 ed oggetto del successivo capitolo. La cleanroom software engineering si propone di eliminare i costidella rimozione degli errori scrivendo porzioni di software corrette per principio e verificandone la correttezzaprima del collaudo; il modello di processo corrispondente incorpora la certificazione statistica di qualità delleporzioni di codice a mano a mano che vengono prodotte.L’ingegneria in camera sterile è esattamente l’opposto 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 vengonoridotte a meri esecutori. Se pensate di valere qualcosa, lottate fino alla morte per i metodi formali e losviluppo a componenti: sono il modo più sicuro per tagliare fuori le mezze calzette dal mercato. Per quantoun lavoro proposto nel 1994 sull’IBM Systems Journal(http://domino.research.ibm.com/tchjr/journalindex.nsf/e90fc5d047e64ebf85256bc80066919c/ad8310e10e47aa4185256bfa00685cc5?OpenDocument) sottolineasse i successi dei primi tentativi, l’ingegneria delsoftware in camera sterile è, manco a dirlo, poco diffusa: un articolo di Henderson del 1995 suggerisce i

15 di 16

motivi plausibili; io li riassumerei con un vecchio proverbio delle mie parti: il raglio di cento asini riesce acoprire perfino l’ululato di un lupo.In termini più pragmatici, perché dare ad un preparato ingegnere diecimila euro al mese, quando sul mercatoci sono dieci mezze calzette che si accontentano di novecento euro (e se per caso ad un’Azienda capitasottomano un preparato ingegnere, il mercato è livellato e sempre novecento euro sono)? La soluzione acamera sterile adotta una versione specializzata del modello incrementale; la caratteristica distintiva è quelladi spostare i collaudi dal singolo sviluppatore ad un team indipendente. Il raffinamento si basa sul concetto discatola, ovvero una rappresentazione del sistema (o di un aspetto del sistema) ad un certo livello didettaglio. Un analista ripartisce gerarchicamente il sistema tramite tre tipi di scatole: nere, che definiscono “lareazione di una parte del sistema ad una serie di stimoli”, di stato, che racchiudono i dati ed i servizinecessari per implementare il comportamento definito dalle scatole nere, e chiare, in cui sono specificati idettagli procedurali. Ad ogni passo di raffinamento si svolge la verifica di correttezza. Il collaudo su basistatistiche chiude questo interessante capitolo, seguito a ruota da quello sull’ingegneria del software acomponenti.Questa prevede due attività di ingegnerizzazione parallele: l’ingegnerizzazione del dominio, che esplora ildominio di un’applicazione con lo scopo di individuare i componenti (funzioni, comportamenti e dati) chepossono essere candidati per il riutilizzo, e lo sviluppo per componenti. E’ importante soffermarsi un attimo ariflettere cosa ha significato la nascita dell’ingegneria a componenti: l’implementazione ha lasciato il postoall’integrazione, uno dei mercati attualmente più fiorenti dell’industria del software. L’analisi del dominio(http://www.sei.cmu.edu/str/descriptions/deda.html), in particolare, secondo alcuni potrebbe ben prestodiventare importante “quasi quanto l’ingegneria del software”, non foss’altro in quanto è applicabile aqualsiasi paradigma di ingegneria ed a qualsiasi tipo di sviluppo, convenzionale o ad oggetti. Vengonobrevemente 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 ilcomune modello ORB (Object Request Broker) che tutti e tre implementano.La disponibilità di una vasta libreria di componenti riutilizzabili comporta, in maniera abbastanza ovvia, lanecessità di uno schema di classificazione che consenta di effettuare facilmente ricerche; sono stati propostivari schemi (http://research.microsoft.com/users/cszypers/events/WCOP2001/Lucena.pdf), tutti basati sulmodello 3C (Concetto, Contenuto e Contesto). Soprendentemente, la maggior parte del lavoro svolto finorasuggerisce l’impiego dei tradizionali metodi bibliotecari, in luogo dei sistemi di intelligenza artificiale edipertestuali. Lo sviluppo per componenti ha un significativo (e benefico) impatto sulla qualità del software: adogni riutilizzo i difetti non rilevati nell’uso precedente vengono individuati ed eliminati, convergendo verso uncomponente virtualmente esente da difetti. Un interessante effetto collaterale dell’ingegneria per componentiè la possibilità di utilizzare come metrica di costo, invece dei LOC o dei Function Points, i punti struttura,ovvero costrutti all’interno di un modello strutturale, che a sua volta è un approccio ingegneristico suldominio basato su schemi ricorrenti nelle applicazioni. Nella pratica, i punti struttura coincidono con icomponenti o i package riutilizzabili; naturalmente, ad essi è associato un costo in termini di validazione,adattamento, integrazione e manutenzione. Manco a dirlo, un’analisi di tali costi è facilitata dall’esistenza diuna serie storica dei casi di utilizzo.L’ultimo capitolo ‘tecnico’ del testo è dedicato alla reingegnerizzazione. Nutro un particolare affetto perl’argomento, come per tutte le cose che risalgono agli inizi della mia carriera, ma in generale il problema delsoftware reengineering non dovrebbe essere sottovalutato: vi capiterà più spesso di quanto pensiate dovermanutenere codice del quale si è persa ogni traccia della documentazione (se mai esistita) ed ogniriferimento al team di sviluppo, nonché i sorgenti nei casi peggiori. Il capitolo comincia però non con lareingegnerizzazione del codice, ma con la ben nota BPR (Business Process Reengineering): non honaturalmente nulla in contrario ad una disciplina nata sotto i crismi della Harvard School, nonché allanaturale evoluzione dei processi aziendali stessi alla radice di tanti progetti software (quasi la totalità seconsideriamo il caso italiano), ma credo che ognuno di noi abbia esperienza dei consulenti in giacca ecravatta che vendono costosa aria fritta in salsa linguistica anglosassone.Nei casi non patologici, invece, il BPR segue le buone prassi dell’ingegneria, a cominciare dal modelloiterativo ed incrementale; è convinzione comune, almeno nel panorama scientifico, che unareingegnerizzazione delle funzioni aziendali debba concentrarsi su processi o sottoprocessi individuali,piuttosto che avventurarsi in una rischiosa rimodellazione dell’intera gerarchia. Venendo al discorso dellareingegnerizzazione del software, non dovremmo mai dimenticare che l’ingegneria del software è nataproprio come risposta al problema dell’iceberg della manutenzione, ovvero di quelle applicazioni, evolutesiselvaggiamente nel corso degli anni, per le quali ogni modifica si trasformava in una serie di effetti imprevistie gravi. La situazione è oggi a dir poco preoccupante: la manutenzione di software esistente assorbe più del60% del lavoro in un’azienda di produzione, e la percentuale è in crescita.A parte l’obsolescenza (o la semplice non applicazione) delle tecniche di ingegneria in auge dieci o quindicianni fa, il problema – principe delle applicazioni legacy è la mobilità del personale di sviluppo; vi è qui un

16 di 16

infinito problema dell’uovo e della gallina fra Aziende che non investono in formazione e non valorizzano lecompetenze, e ‘programmatori’ sulla breccia da troppi anni, che si rifiutano ostinatamente di aderire alleprassi di documentazione e standardizzazione perché temono di perdere l’ultima ragione della loro esistenzaaziendale. La reingegnerizzazione richiede tempo, ha costi rilevanti e assorbe risorse; un progetto direengineering è destinato a durare parecchi anni. Il reverse engineering per il software consistenell’analizzare un programma al fine di produrne una rappresentazione ad un livello di astrazione superiore aquello del codice sorgente; si tratta cioè di recuperare un modello progettuale. L’attività direingegnerizzazione più comune è la ristrutturazione del codice: se l’architettura 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: leprassi in materia sono così consolidate, che spesso esistono strumenti in grado di effettuareautomaticamente la ristrutturazione.Viceversa, un programma con architettura dei dati debole è difficile da adattare e migliorare; a differenza diquella del codice, la ristrutturazione dei dati è un’attività di reingegnerizzazione a pieno titolo, che comportaun alto livello di astrazione. E’ da tenere presente che ogni modifica ai dati si riflette in modificheall’architettura o sul piano del codice. Un discorso a parte merita il forward engineering, che non solo estraeinformazioni di ordine progettuale da software esistente, ma utilizza queste informazioni per alterare oricostruire il sistema così da migliorarne la qualità. Il capitolo esamina, naturalmente, tutte e tre le tecnichecitate.

ConclusioniIl testo si chiude con uno sguardo sul futuro, ben consapevole dei limiti di ogni previsione: ma del resto, inche altro modo si può chiudere un testo storico nel suo campo? Comunque andranno le cose, è facileprevedere che l’ingegneria del software del ventunesimo secolo si occuperà sempre di più dell’elaborazionedell’informazione, cercando di estrarre conoscenza dalla sterminata mole di dati accumulata grazieall’informatica negli ultimi sessant’anni. E’ facile anche prevedere l’affermazione delle architetture orientatealla collaborazione. Vada come vada, il futuro spetta al software. E costruire il futuro spetterà, ancora unavolta, agli ingegneri.