Perché non si può sviluppare un software allo stesso modo di come si costruisce un ponte

1. Software ed ingegneria civile
´ `
Perche non si puo sviluppare un software allo stesso modo di
come si costruisce un ponte
Pierfranco Ferronato
icordo in un grosso progetto in una azien- anche il nuovo sistema e poi mi dilungo nella spiega-
R da di telefonia mobile in cui si stava pas-
sando da una tecnologia fat-client a due
livelli: rich client da una parte e connes-
sione diretta al database dall’altro, ad una distribuita
a tre livelli (rich-client, application server e database)
zione delle architetture distribuite dicendo che essendo
un’architettura a tre livelli, la funzionalit` viene ripar-
a
tita in tre possibili tier: va considerato il riuso e l’ef-
ficienza, c’` pi` di un modo di intervenire”, al che mi
viene detto
e u
usando un linguaggio ad oggetti. La migrazione era `
– Allora se e cos` complicato abbiamo sbagliato a
ı
necessaria perch´ con quasi 2000 utenti concorrenti il
e scegliere questa tecnologia.
sistema era seduto, tempi di risposta da parte del DB Chi vuole realizzare un software ed avere bene-
inaccettabili per servizi telefonici offerti dal customer fici di efficienza, economia, riusabilit` , scalabilit`
a a
care. (funzionale e tecnologica) e tutta un serie di altre
L’analisi era un fattore chiave in un progetto tanto “. . . abilities” applica metodi che vengono chiamati
complesso e per essere certi di poter realizzare gli software engineering.
stringenti requisiti di performance. Il primo rilascio in
------------------------------------
produzione di una primo set di use-case era andato be-
ne, ma il responsabile del progetto lato cliente, che era `
Non e plausibile realizzare un
stato lo sviluppatore del precedente sistema, mi chiese: software senza un progetto
– Avete gestito il customer tipo VIP? ------------------------------------
– No – dico io – non era stato contemplato perch´ none
ci era stato detto `
E dal 1994 che applico metodi di ingegneria del soft-
– Cambialo ware, prima che tutta una serie di acronimi come UML
– Serve considerare l’analisi ed il disegno, non e ` o RUP fossero coniati e ne sono uno strenuo difensore
immediato dove e come intervenire e per questo odiato ed amato. Sono fortemente convin-
Forse mi ero espresso male fattost` che mi viene
a to che la realizzazione del software debba passare per
risposto dei metodi formali che non solo definiscano regole di
`
– Ma dai! E solo un SQL, con la vecchia applicazione implementazione, disegno ed architetturali ma anche
era un attimo! e sopratutto che disciplinino i processi della software
Rispondo che se la vecchia applicazione veniva rim- factory.
piazzata, un motivo ci doveva pur essere, se applichia- `
Non e plausibile realizzare un software senza un piano,
mo modifiche senza criterio rischiamo di far tracollare senza un progetto, senza gestire, mappare e tracciare
Computer Programming vol. XVII n. 2 [Maggio-Giugno 2009] 25

2. CODE WORLD
ad esempio i requisiti e gli obiettivi. E’ fondamentale e realizza un grattacielo. Ma perch´ sono cos` drastico
e ı
`
seminare il riuso per poter raccoglierlo poi, non e un ed un certo modo anche pessimista? Perch´ i metodi di
e
risultato che viene a gratis. costruzione di artefatti complessi come edifici e ponti
tanto rodati ed efficaci non possono essere adottati per
Ma non voglio fare un articolo sui vantaggi del soft- realizzare complessi sistemi software?
ware engineering, quanto tuttavia fare un’autocritica ------------------------------------
perch´ mi sono troppo spesso chiesto come mai sia ol-
e
In informatica il costo di modificare
tremodo difficile applicarli; dov’` l’anomalia? Si trat-
e
ta di una nostra incapacit` di professionisti di renderla
a `
un artefatto software e una
concreta nel campo o si tratta forse dei metodi stes- frazione del costo di realizzalo
si che non sono adeguati? Mi rendo conto che c’` un e ------------------------------------
malessere in questo modo di intendere i metodi detti
“ingegneristici” nello sviluppo software. Seguiamo un ragionamento.
Ritengo che troppo spesso si tende a farsi ispirare dai
`
Nell’ingegnerie civile il costo di spostare un pilastro e
metodi di ingegneria civile. In molte conferenze sono
all’incirca il 270% del costo di costruirlo.
descritti come un faro a cui tenere per inquadrare in
un’ottica di metodo e qualit` lo sviluppo del software.
a Da millenni l’uomo prima di costruire una struttura o
A volte vedo i relatori fare della facile ironia afferman- un edificio lo ha prima accuratamente progettato, dalle
do che i professionisti del software, tutto il settore del- piramidi, ai ponti e gli acquedotti romani, alla Basilica
lo sviluppo software, sia malato perch´ non riescono
e di San Pietro. L’istinto che abbiamo con queste costru-
ad applicare i processi che tanto bene funzionano nel- `
zione e: prima progetto e poi costruisco. Se dobbiamo
l’ingegneria civile. Alcuni in modo ilare fanno ridere costruire un’artefatto come un tavolo o una cassapanca
la platea parlando di “Ossimoro” tra ingegneria e soft- tutti noi prima di tutto facciamo un piano, un disegno,
ware (cio` una contraddizione in termini), ammetten-
e uno schema e magari pure un prototipo in scala ridotta
do una intrinseca incapacit` di poter adottare i metodi
a prima della sua costruzione.
proprio dell’ingegneria civile e ci si ride sopra salvo I processi di ingegneria hanno millenni di esperienza
poi raccontare che c’` un meraviglioso strumento di
e e si sono adattati al fatto che i requisiti di un ponte o
sviluppo che risolve il problema. di un edificio sono statici come la struttura che deve
`
L’obiettivo a cui ci si vuole ispirare e di essere in grado essere realizzata, c’` molto poco spazio per gestire i
e
di aver un progetto per un software (un blueprint) dello cambiamenti. Spesso se i requisiti cambiamo, un ponte
stesso valore di quello per un ponte: una volta che l’in- non basta pi` , si butta gi` o lo si abbandona per farne
u u
`
gegnere lo ha scritto, e costruibile. Questo “progetto” un altro.
diventa asset, patrimonio di valore, riusabile senza pi` u Questo perch´ nelle costruzione edili si ha l’istinto per
e
l’ingegnere e la costruzione pu` partire.
o `
esperienza che una modifica in corso d’opera e estre-
------------------------------------ mamente costosa, buttiamo via materiale e tempo, c’` e
` a
poco spazio per riusare quello che e gi` stato fatto.
Nell’ingegnerie civile il costo di In informatica abbiamo una anomalia particolarissi-
`
spostare un pilastro e all’incirca il `
ma: il costo di modificare un artefatto software e una
270% del costo di costruirlo. frazione del costo di realizzalo e l’istinto che si ha e `
------------------------------------ di “fare” e non di “pensare”. Non ci sono materiali
da gettare, pesi e volumi da spostare, o materiale da
`
Questa aspettativa e secondo me una chimera e pure un ri-acquistare in sostituzione a quello originale, un co-
rischio se viene applicata in modo talebano perch´ non
e pia/incolla spesso risolve un problema o una richiesta.
`
si e capito che le due cose come fondamentalmente Copiare o incollare una riga di codice io un’intera clas-
diverse ed un incompatibili: non si pu` progettare e
o `
se costa esattamente lo stesso: il solo fattore di costo e
realizzare un software con i metodi con cui si progetta il “tempo”.
26 Computer Programming vol. XVII n. 2 [Maggio-Giugno 2009]

3. CODE WORLD
erso le 10 del mattino del 7 novembre 1940 inizi` la torsione del tratto centrale del ponte, che
o
V collass` un’ora e dieci minuti dopo, senza provocare vittime. Le immagini del disastro furono
o
riprese da un docente di ingegneria che stava studiando i movimenti della struttura. Le cause del
crollo sono da ricercarsi nelle oscillazioni torsionali indotte dal distacco periodico di vortici di
von Karman (fenomeno di instabilit` aeroelastica detto anche flutter o stall-flutter). Infatti, sotto l’azione di un
a
vento costante di circa 30 nodi la scia dei vortici di von Karman trasmetteva alla struttura delle coppie torcenti
pulsanti alla stessa frequenza torsionale del ponte, innescando un fenomeno di risonanza con ampiezze via
via crescenti e non compensate da un adeguato smorzamento. L’ingegnere italiano Giulio Krall calcol` o
teoricamente, a posteriori, la velocit` critica del vento sulla struttura in 57 Km/h, praticamente coincidente
a
con la effettiva velocit` del vento che caus` il disastro.
a o
Il ponte venne poi ricostruito nel 1950 facendo tesoro della drammatica esperienza (pi` largo, u
pi` rigido torsionalmente e con maggiore capacit` di smorzamento) esteticamente molto simile ma
u a
con una struttura molto pi` stabile nei confronti degli effetti del vento.[testo liberamente tratto da
u
http://it.wikipedia.org/wiki/Ponte di Tacoma]
------------------------------------
Ma le cose che deve poter fare un prodotto software
Bisogna ingegnerizzare lo sviluppo sono diverse da quelle di un artefatto dell’ingegneria
software ma non per gestirne la classica. Ad un ingegnere civile non si chiede di al-
lungare un ponte, o di spostarlo o tanto meno di co-
realizzazione, ma per ottenerne
struire un piano in pi` mentre sotto il traffico conti-
u
` `
scalabilita e manutenibilita nel nua a scorrere in modo “interattivo ed incrementale”.
lungo termine In informatica non ci meravigliamo di queste richie-
------------------------------------ ste, sono una conseguenza della sua natura effimera ed
altamente dinamica.
Tutti noi all’inizio delle nostre esperienze informatiche Consideriamo per un attimo anche il ruolo che giocano
abbiamo vissuto l’esperienza di essere portati a scrive- gli strumenti di sviluppo, quanto essi mal influenzano
re codice subito e modificare dopo, perch´ “si fa pri-
e il modo di affrontare lo sviluppo. Per fare una casa ad
ma”, perch´ “tanto modifico dopo”. Ho visto aziende
e esempio servono degli strumenti costosi e complessi
mature e di successo con la stessa mentalit` , partire a
a come delle gru, scavatrici e betoniere solo per dirne
sviluppare senza piano o progetto o disegno perch´ “a e alcuni. Nessuno di noi pensa che per farsi una casa in
modificare ci penso dopo”, “intanto mi porto avanti e un terreno di nostra propriet` basti comprare una gru o
a
scrivo cos` vado in produzione prima”. Questa e una
ı ` seguire un corso per “scavatrice” o “ruspa”.
anomalia in cui molti ancora cascano, e debbo dire che
in fondo li capisco, sono simpatetico con loro. Sappiamo che lo strumento non basta, ma sappiamo
anche che non serve neppure essere un bravo operato-
Una variabile si valorizza al volo, una classe o una li- re di una macchina a movimento terra per poter fare
breria si duplica, si reinstalla, il valore in una tabella una casa. Ci sono processi, altri strumenti, tecnologie,
si cambia in un attimo. L’istinto di modellare, pro- scienza e know-how. Questi strumenti sono innanzi
gettare, disegnare prima ed in anticipo non c’` ed il
e tutto costosi da ottenere, voluminosi ed una volta otte-
`
motivo e che –apparentemente– modificare costa me- `
nuti non siamo in grado di usarli. Il nostro istinto e di
no che fare! Poi aggiungiamo la fretta e l’agitazione `
andare dai professionisti! Il nostro istinto e quello di
di fare presto che permea l’informatico ed abbiamo un andare da un geometra o da un architetto che poi in-
bel quadro completo: ho visto “analisti” in piedi dietro vocano un ingegnere per la fattibilit` che poi chiama
a
un programmatore a dirgli cosa fare! Tutto questo e ` un’impresa edile: ogniuno sa cosa fare ed ha un ruolo
diabolico. ben specifico.
Computer Programming vol. XVII n. 2 [Maggio-Giugno 2009] 27

4. CODE WORLD
Ah, ma in informatica i tool si possono scaricare da che finiscono sottostimati e sono la causa principale
Internet, e sono spesso free e professionali: databa- del fallimento dei progetti IT.
se, IDE, UML editor, application server, GUI fra- Comunque, non mi si fraintenda, ed arrivo verso
mework, linguaggi, VM, middleware. . . tutto free, la conclusione: in informatica quando si realizza
`
tutto scaricabile, e tutto l`.
ı del software c’` ovviamente bisogno di progettare e
e
------------------------------------ molto!
Serve “pensare”, pianificare e progettare prima di ini-
`
Il costo dedicato alle attivita di ziare a programmare, ma non per gestirne la comples-
manutenzione ed evoluzione di un sit` della realizzazione, ma per ottenerne la scalabilit`
a a
`
software e di oltre il 90% del costo e la manutenibilit` , per poterlo gestire nel suo ciclo di
a
totale; `
vita: e questo e meno istintivo. Infatti fare un software
------------------------------------ `
e facile, ammettiamolo una volta per tutte, ci sono stru-
menti di sviluppo e piattaforme di esecuzione potenti a
Al peggio ci chiedono di registrarci e pure ci d` fasti-
a costo zero, l’hardware costa poco come i contratti per
dio. Tutti ci sentiamo in grado di metterci ad usarli, si `
l’hosting su Internet: e facile soddisfare dei requisiti in
ha un diabolico senso di onnipotenza, di poter creare, poco tempo. Quello che viene sottostimato, sia da chi
di poter realizzare un software solo perch´ si hanno gli
e sviluppa senza metodi di ingegneria del software, sia
strumenti a portata di un click! Vedo nelle librerie libri ` `
da chi li applica e che il software e in continuo dive-
con titoli come “XML in 24 ore”, “Impare EJB in 2 nire, il suo “total cost of ownership” viene dalla ma-
giorni”,Diventa un webmaster”, e li vediamo e magari nutenzione, dal sapersi adattare ai cambiamento degli
ci facciamo pure il pensierino di prenderli che qualcosa `
aspetti funzionali. Solo una frazione del TCO e dovuto
magari insegnano pure. al alla realizzazione.
Fate un salto nella sezione “Medicina” e cercate “Di- Secondo una statistica (Software Maintenance Costs,
venta un chirurgo del cervello in 24 ore”, “Fai fa te: il Jussi Koskinen, Information Technology Research
trapianto di fegato in 24 ore”, “Chirurgia vascolare in Institute, ELTIS-project, University of Jyv¨ skyl¨ ,
a a
48 ore”. 2003-2006, http://users.jyu.fi/ koskinen/oyp0-ELTIS-
Se vi fa ridere allora dovete trovare il modo di ridere collection.pdf) nel 2000 il costo dedicato alle attivit` a
anche per quei titoli informatici. di manutenzione ed evoluzione del software era di ol-
tre il 90% del costo totale; in altre parole realizzar-
Questa manna di tool free e potenti a disposizione non
lo costa meno del 10%. Interessante notare come nel
fanno bene all’informatica secondo me, avremmo con-
`
tempo questa percentuale, secondo lo studio, e passata
trastato questa mania di onnipotenza: poter realizzare
dal 67% al 90% in vent’anni.
qualunque cosa solo perch´ abbiamo accesso agli stru-
e
menti. Pensate a quanti disastri avremmo fatto se pos- Il lettore attento avr` notato una contraddizione appa-
a
sedere una ruspa o una scavatrice in casa fosse facile rente: com’` possibile che il costo di un software sia
e
e economico come scaricare MySQL: il concetto che per il 90% nella manutenzione mentre si era detto che
`
passa e che sono gli strumenti a fare la differenza pi` u cosa poco modificare?
che il know-how. Il tutto si gioca sul fatto che le modifiche sono innu-
Mettiamo assieme le due cose: merevoli e si accumulano una sull’altra. La prima e `
economica, ma la seconda un poco meno perch´ in- e
• (apparentemente) costa meno modificare che fare fluenzata da un primo intervento non progettato a do-
vere e ne mal influenza la realizzazione. Alla fine ogni
• gli strumenti sono accessibili a tutti modifica accumula entropia nel codice, ho l’immagi-
ne di un trattore che cerca di tirare un mezzo frenato
e vediamo che viene rivoluzionata una buona fetta di sulla sabbia, pi` si avanza pi` la forza da applicare au-
u u
quegli elementi propri dell’ingegneria civile, quello menta con il quadrato della distanza. Il supporto alla
`
che resta e il know-how ed i processi per lo sviluppo certa necessit` di essere modificato deve essere stato
a
28 Computer Programming vol. XVII n. 2 [Maggio-Giugno 2009]

5. CODE WORLD
“ingegnerizzato”, va supportato proprio quest’aspetto facciano leva proprio sulla flessibilit` ; soggetto di un
a
di continua evoluzione; va progettato per scalare, fun- altro articolo.
`
zionalmente e tecnologicamente. Il software e sepre Ma qualcosa possiamo imparare degli ingegneri, so-
pi` dinamico perch´ sempre pi` legato ad un business
u e u prattuto l’analisi post-mortem di un progetti mal
a volte schizofrenico. Anche il peso del codice legacy riuscito.
da portarsi dietro influenza i costi di manutenzione. `
Il Tacoma bridge e un famosissimo caso di catti-
`
Il software e come un essere biologico, in continuo di- va progettazione, su youtube si trova il noto filmato
`
venire non e immutabile. Per fare un bimbo bastano del suo collasso [http://www.youtube.com/watch?v=j-
`
10 minuti, anche piacevoli, ma e il resto della sua vita zczJXSxnw].
che implica costi, investimento e rischi. `
Chi e un architetto o un ingegnere lo conosce. Si trat-
------------------------------------ `
ta di un ponte sospeso che e stato costruito sul Taco-
ma Narrows (Washington, USA) per la prima volta nel
`
Il software e come un essere 1940. I lavori iniziarono il 23 novembre del 1938 e la
biologico, in continuo divenire non struttura fu poi aperta al traffico il 1 luglio del 1940,
`
e immutabile. prima di crollare il 7 novembre dello stesso anno. Pre-
------------------------------------ sentava una lunghezza complessiva di 1524 metri per
circa 12 metri di larghezza, era il terzo ponte a campata
Troppo spesso si pensa che un software sia una foto- unica pi` lungo del mondo.
u
grafia, un momento che consiste in requisiti soddisfatti E` stato studiato a fondo per evitare che si ripetano erro-
fissati in maniera statica. A volte ci si rende conto che ri simili, il filmato del tracollo e le motivazioni fisiche
poi seguir` una seconda fotografia che sar` una modi-
a a `
sono state studiate in dettaglio ed e un caso universi-
fica della prima, ma non basta. Si tratta di un filmato tario di studio. In informatica pare non si faccia lo
non di una sequenza di istantanee. `
stesso, un’analisi post-mortem di un progetto e sempre
Modificare e manutenere un codice sono cose fonda- da assegnare ad un capro espiatorio, spesso erronea-
`
mentalmente diverse: manutenere e fissare un altra im- mente assegnato alla tecnologia X, alla strumento Y o
`
magine, modificare e supportare lo sviluppo nel tem- al team.
po di un filmato. Si tratta di un aspetto non intuitivo `
E troppo spesso il fallimento di un progetto e tratta-
che il cliente per primo non chiede a meno che non sia to con troppa semplicit` e bollato come ineluttabile;
a
un illuminato (dice –dopo– che si aspettava che avreb- mi piacerebbe che ci facessero degli studi come anti-
be dovuto scalare sulla tecnologia ’x’ o supportare la pattern a livello di progetto e realizzazione per impa-
`
funzionalit` ’y’ che “tanto e poco diversa dalla ’z’ ini-
a rare, ma pare che in informatica si faccia troppa fatica
ziale”). Non c’` mai un software tanto piccolo da non
e ad imparare dagli errori.
aver bisogno di un progetto, di una modellazione, di
una forma di pianificazione. Tutto questo lo percepi-
sce solamente l’informatico o l’architetto che ne ha vi-
ste tante e che ha assistito a diversi e continui cicli di
`
vita di progetti software: “Ma e solo un SQL!”
Nell’ingegneria civile le modifiche sono praticamente XKCD
assenti; si parla tuttalpi` di manutenzione straordina-
u
rie. I costi di manutenzione sono una esigua frazio-
ne del costo di realizzazione perch´ debbo gestire solo
e
l’operativit` come le pulizie, sostituire le lampadine
a
od essere ridipinto. Questo a maggior ragione eviden-
zia come nell’IT possa esere pericoloso fissarsi come
obiettivo i metodi dell’ingegneria civile e come debba
essere affrontato con metodologie diverse che magari
Computer Programming vol. XVII n. 2 [Maggio-Giugno 2009] 29