Da eXtreme Programming a XPTracking: la concretizzazione di valori e pratiche in una applicazione software

zionalita` (chiamata, in XP, user story), le linee di codice, il rapporto
metodi/classe ecc...
• permettere lo steering dei progetti in corso, ovvero modifiche al pia-
no di lavoro inizialmente concordato anche sulla base delle metriche
raccolte.
L’esposizione degli argomenti della tesi suddivisi nei vari capitoli puo` essere
espressa dalla seguente metafora: in un galleria d’arte un visitatore osserva
un quadro.
La guida della galleria, per far comprendere appieno il valore e la storia
del quadro, usa questa strategia: invita in un primo momento il visitatore
a osservare la cornice, a sentirsi a suo agio nell’ambiente circostante, ad
abituarsi alla luce e ad assumere la posizione piu` consona (capitolo 2). Suc-
cessivamente la guida si pone tra il visitatore e il quadro, ostruendogliene la
vista.
In tale posizione gli racconta le diverse metodologie di pittura usate nello
stesso periodo artistico dell’opera, indicando le caratteristiche comuni e le
differenze (capitolo 3); infine, si zittisce e si sposta; il quadro e` ora total-
mente visibile.
Il visitatore lo osserva e lo studia incuriosito (capitolo 4). Dopo qualche
tempo la guida racconta la vita dell’autore, spiega gli stati d’animo espressi
nell’opera, svela il significato dei simboli, illustra gli strumenti e le tecniche
usati.
Solo al termine di questa spiegazione il visitatore e` soddisfatto e si stupisce di
come la conoscenza dei dettagli gli ha fatto maggiormente apprezzare l’arte-
fatto, il quale e` diventato vivo strumento di esplorazione e di arricchimento
personale (capitolo 5).
8
Capitolo 2
Ingegneria del software e
metodologie storiche
2.1 Ingegneria del software - definizione
La definizione ufficiale della IEEE Standard Computer Dictionary [1] afferma
che l’ingegneria del software e`: “The application of a systematic, disciplined,
quantifiable approach to development, operation, and maintenance of soft-
ware; that is, the application of engineering to software”.
Tale definizione da` importanza al processo di sviluppo del software che deve
avere particolari caratteristiche. Tuttavia esistono diverse interpretazioni, e
vari autori si discostano, chi piu` chi meno, dalla definizione ufficiale.
• “Designing and developing high-quality software. Application of com-
puter science techniques to a variety of problems. We are problem-
solvers rather that theoreticians.” [2]
L’affermazione finale indica l’estrema praticita`chee` intrinseca nell’-
ingegneria del software.
• “The establishment and use of sound engineering principles in order
to obtain economically software that is reliable and works efficiently
on real machines.” [3]
Bauer identifica l’ingegneria del software come mezzo per ottenere un
software che risponda a certe caratteristiche di qualita`.
• “Software engineering is programming under at last one of the follow-
ing two conditions:
1. More than one person is involved in the construction and/or use
of the programs
2. More than one version of the program will be produced” [4]
9
Parnas, in linea con molti altri autori, afferma che l’ingegneria del
software e` la pratica della programmazione sotto certe condizioni.
Nonostante le differenze, tutti sono d’accordo nel ritenere che il fine di ogni
processo di produzione di software e` quello di ottenere un prodotto di qualita`
consegnato entro un periodo di tempo concordato e in conformita`aun
budget. Probabilmente per identificare correttamente il mezzo tramite il
qualesivuolgiungereatalefine,e` necessario partire dalle radici storiche
della nascita del termine ‘ingegneria del software’.
2.2 La crisi del software anni ’60 - ’70
Verso il 1960 divenne chiaro che i costi delle aziende legati all’hardware con-
tinuavano a decrescere, mentre i costi del software aumentavano. Inoltre
alcuni episodi chiave –uno per tutti l’incidente della sonda Mariner I Venus
nel 1962– suggerivano l’esigenza di introdurre vincoli di sicurezza durante lo
sviluppo del software e non in una fase successiva al suo rilascio.
Nel corso della prima conferenza dell’ingegneria del software tenuta a Gar-
misch, in Germania, nel 1968, comparve, in modo provocatorio, il termine
‘ingegneria del software’ [5].
Si avvertiva l’esigenza di applicare il rigore dell’approccio ingegneristico al
processo di produzione del software tramite la definizione di leggi e/o ap-
procci pratici e sistematici, invece di basarsi sulla capacita` del singolo svilup-
patore.
Il computer iniziava a perdere la connotazione di strumento prettamente
scientifico, usato principalmente da scienziati per risolvere problemi il piu`
delle volte matematici; di conseguenza la figura dell’utente finale cominciava
a distinguersi da quella del programmatore.
Data la mancanza di esperienze precedenti e di metodologie di supporto alla
produzione del software, molti progetti fallivano (figura 2.1) o comunque
non riuscivano a rispettare ne´ i tempi prestabiliti ne´ il budget assegnato.
2.3 Ingegneria applicata al software
In tale contesto nacque l’idea di definire e delimitare in chiare fasi i passi
necessari per creare software di qualita`. Le soluzioni trovate non dovevano
essere ad hoc ma, una volta provata la loro bonta`, venire formalizzate al fine
di diventare ripetibili e migliorabili.
Nel dizionario Garzanti l’ingegneria “tradizionale” e` definita come una “qua-
lunque disciplina scientifico-tecnologica che su basi matematiche analizza
problemi, progetta soluzioni e organizza risorse in uno specifico campo del
sapere”.
10
Figura 2.1: Alcuni dati sul fallimento dei progetti
Si possono studiare le differenze e le analogie tra l’ingegneria applicata al
software e quella applicata in altri campi (vedi tabella 2.1).
L’esigenza principale era quella di superare la fase detta di ‘code&fix’ in
favore di metodi piu`efficienti.
Per ‘code&fix’ si intende l’impegno, da parte di un singolo programmatore,
di raggiungere l’obiettivo prefissato il piu` rapidamente possibile, alternando
una fase di scrittura immediata del codice con una di correzione dei malfun-
zionamenti riscontrati.
Nonostante tale approccio sembri intuitivamente il piu` veloce, evidenze spe-
rimentali hanno mostrato che e` altamente inefficiente poiche´ non forza la
persona a riflettere su ‘cosa’ deve fare in un certo momento e su ‘come’ farlo
nel modo piu` corretto possibile.
2.4 Waterfall
Un modello storico, nato dall’esigenza di gestire in modo chiaro e struttura-
to lo sviluppo di un prodotto software, e` il Waterfall.
Introdotto da Royce [9] negli anni ’70, si basa sul concetto che il software
deve essere realizzato grazie a passi successivi che si susseguono sequenzial-
mente.
Waterfall trova sostegno sull’osservazione empirica svolta da Boehm [29] in
cui si afferma che il costo del cambiamento cresce in modo esponenziale di
fase in fase (figura 2.2).
La conclusione immediata e`chee` necessario prendere decisioni importanti
11
Campo Ingegneria del soft-
ware
Ingegneria
tradizionale
Radici Basata sulla computer
science e sulla matemati-
ca
Basata sul calcolo, la
fisica e la chimica
Costo Attualmente l’hardware
necessario per lavorare su
un progetto (computer,
compilatori, framework) e`
economico. I costi legati
allo sviluppo invece sono
predominanti. Sforamen-
ti del budget previsto
dovuto a scelte di svilup-
po possono modificare
significativamente il costo
totale del progetto
I costi di costruzione e di
gestione sono alti e l’in-
gegneria tradizionale in-
fluenza solo una picco-
la parte del costo totale.
Sforamenti nel campo del-
l’ingegneria non sono par-
ticolarmente dannosi nel-
l’ economia globale di un
progetto
Replicazione In generale, molto lavoro
e` mirato all’aggiunta di
nuove funzionalita` oppure
alla modifica di quelle gia`
esistenti.
Quasi tutto il lavoro si
basa sulla ripetizione di
design da tempo usati e
provati
Durata I progetti software tipica-
mente hanno una vita di
alcuni anni
L’ingegneria tradizionale
mira a risolvere problemi
a lungo termine (un clas-
sico esempio e` rappresen-
tato dalla costruzione dei
ponti) che possono durare
per secoli
Management Pochi ingegneri del soft-
ware gestiscono del per-
sonale; di conseguenza
sono difficilmente visti
come manager
Gli ingegneri tradizionali
spesso assolvono compiti
tipici di un manager
Eta` L’ingegneria del software
ha una storia recentissi-
ma: circa 50 anni
L’ingegneria civile ha una
storia millenaria
Innovazione Spesso vengono applicati
nuovi elementi poco testa-
ti
Si applicano in genere
principi ben testati e con
una lunga storia di succes-
si, limitando l’innovazione
Tabella 2.1: Confronto tra ingegneria del software e ingegneria tradizionale
12
all’inizio poiche´ ogni cambiamento e` costoso.
Tuttavia il progresso nei linguaggi, nei database e nelle pratiche di sviluppo
hanno contribuito a rendere l’affermazione meno valida, anche se viene con-
siderata ancora piuttosto veritiera.
Figura 2.2: La curva esponenziale del costo del cambiamento
La metafora della cascata serve ad indicare che l’acqua scorre in un’unica
direzione. Nel tempo sono state create numerose varianti di questa metodo-
logia che cercano di rilassare questo vincolo; tuttavia esse perdono anche i
punti di forza che il modello originario reca in se`.
Tutti i passi servono a delineare e delimitare operazioni specifiche e indis-
pensabili (figura 2.3).
Figura 2.3: Passi sequenziali della metodologia “Waterfall”
13
1. Studio di fattibilita`
L’obiettivo fondamentale dello studio di fattibilita`e` quello di fornire
l’insieme delle informazioni necessarie alla decisione per l’effettivo avvio
della realizzazione di un progetto e per l’investimento necessario.
Le informazioni chiave per la decisione sulla effettuazione del progetto
riguardano la fattibilita` tecnica e organizzativa, i benefici, i costi, i
rischi, le scadenze temporali.
Per rispondere a questo obiettivo lo studio di fattibilita`deve:
• Rendere esplicite le condizioni che rendono conveniente l’effet-
tuazione del progetto.
In particolare e` fondamentale chiarire i benefici attesi dal proget-
to e la rispondenza agli obiettivi di miglioramento individuati,
stimare i costi di impianto e di esercizio, individuare e valutare i
rischi del progetto e correlare tutti questi elementi.
• Verificare l’esistenza di una adeguata soluzione tecnico-organiz-
zativa situata all’interno dei vincoli economici e temporali dati,
anche attraverso il confronto tra soluzioni diverse e la scelta tra
di esse sulla base di criteri esplicitati e predefiniti.
Poiche´ per raggiungere gli obiettivi citati e` necessario disporre di un
primo livello di descrizione del progetto previsto, lo studio di fat-
tibilita` deve necessariamente comprendere una descrizione di massima
del progetto.
2. Analisi dei requisiti
Il requisito e` una caratteristica del sistema, richiesta al progettista dal
committente, necessaria per raggiungere un obiettivo.
Formulando i requisiti, il committente esprime una serie di vincoli,
chiarendo il modo in cui gli obiettivi dovranno essere soddisfatti dal
sistema. A sua volta il progettista, dopo aver analizzato i requisiti
ricevuti, puo`formulareunaopi`u ipotesi di soluzione, tra loro diverse
per caratteristiche, costi e tempi di realizzazione, ma comunque in gra-
do di rispondere, in tutto o in parte, ai requisiti espressi.
Tra le soluzioni proposte, il committente scegliera` quella migliore (dal
suo punto di vista) in termini di rapporto tra costi e benefici, e stipu-
lera` un contratto con i progettisti affinche´ la realizzino.
Una volta realizzato il sistema, la conformita` ai requisiti concordati
costituisce il criterio per l’accettazione del prodotto da parte del com-
mittente.
Nel caso ideale, i requisiti vengono stabiliti nella fase iniziale del proget-
14
to, permettono di definire un accordo, dopodiche´ non vengono piu`
cambiati; in tal caso si parla di “congelamento delle specifiche”.
3. Design
Il design, cos`ı come inteso dalla metodologia Waterfall, e`lafaseincui
si definisce come il sistema deve essere strutturato per soddisfare le
richieste concordate nella fase precedente.
In particolare:
• Si definisce l’architettura generale (hardware e software) del si-
stema
• Si descrivono le funzioni che il sistema deve svolgere, ciascuna
delle quali verra` trasformata in uno o piu` programmi eseguibili
• Si definiscono i moduli
1
dell’architettura software e le loro re-
lazioni. Il processo di scomposizione in moduli procede in maniera
iterativa fino ad un livello di dettaglio sufficiente ad eliminare
ogni ambiguita` riguardo alla struttura del codice che dovra` essere
realizzato
Il risultato dell’attivita` di progettazione e` un documento di specifiche
di progetto nel quale la definizione dell’architettura software puo` anche
essere data in maniera rigorosa, o addirittura formale, usando oppor-
tuni linguaggi di specifica.
Ad oggi, il concetto di design di un software e` abbastanza cambiato,
poiche` i sistemi da modellare non sono totalmente definibili a prio-
ri. Ad esempio elementi quali il riuso del software, l’attenzione alla
flessibilita`, il giusto equilibrio tra complessita` e potenza sono diventati
fondamentali per la definizione di un buon design.
4. Codifica
In questa fase si scrive il codice in un particolare linguaggio di pro-
grammazione che implementa i modelli studiati nella fase di design.
Moduli ben definiti rispecchiano le seguenti caratteristiche, a pre-
scindere dalla metodologia o metodi usati:
• Coesione
Un modulo e` coeso se implementa una e una sola funzionalita`; in
tal modo ha una sola responsabilita`.
Il vantaggio di avere moduli coesi si ha nelle fasi di manutenzione,
1
Il concetto di modulo e` qui considerato nel suo significato piu` generico, svincolato
da ogni linguaggio di programmazione. Per modulo si intende un insieme significativo di
funzionalita`.
15
adattamento e verifica del software in quanto e` facilmente possi-
bile agire solo su una specifica porzione di codice.
Un modulo ben coeso inoltre favorisce il riuso del codice.
• Disaccoppiamento
Grazie ad un elevato grado di disaccoppiamento, le modifiche alla
struttura interna di un modulo non si ripercuotono all’interno
degli altri.
Questi possono dipendere dal modulo solo dalle interfacce fornite
e non dal modo in cui esse sono realizzate.
Solitamente ogni ente definisce uno standard di codifica che i program-
matori sono invitati a rispettare [11].
Tali convenzioni hanno lo scopo di migliorare la comprensibilita`del
codice e quindi di velocizzare tutte le operazioni di modifica o svilup-
po. Inoltre poiche´pu`o esserci cambiamento del personale, lo sforzo
necessario per comprendere il codice scritto da altre persone puo` esse-
re significativamente inferiore.
La programmazione e` un’attivita` nuova nella storia dell’uomo; come
tale non si basa su modelli preimpostati e tecniche sperimentate a
lungo. Si puo` affermare che programmare e` una attivita` creativa, che
richiede allo sviluppatore una buona capacita` di pensare attraverso
diversi livelli di astrazione oltre a confrontare le sue conoscenze e ca-
pacita` con la comunita` scientifica.
Richard Gabriel, un ingegnere della Sun Microsystems, afferma, in una
intervista [12], che: “scrivere del codice e scrivere poesia sono [attivi-
ta`] simili”. Inoltre: “Siamo portati a credere che la programmazione
e` ausiliaria, mentre e` un’attivita` veramente centrale, difficile, umana
e sociologica”.
Le finalita`diunbuoncodicenonsonoper`o estetiche, ma necessaria-
mente, in un contesto di ingegneria del software, riguardano trade off
tra costi e benefici.
Spesso si e` cercato di sostituire la figura del programmatore con tool
automatici che, partendo da una definizione formale composta da dia-
grammi, costruissero il software.
Tali progetti non sono mai riusciti nel loro scopo, in quanto, come
affermato da Rich e Waters [13], non e` possibile creare strumenti che
raggiungano tutti e tre i seguenti obiettivi:
• Lo strumento dev’essere completamente automatizzato
• Dev’essere general-purpose
• Puo`, una volta completo, interpretare specifiche scritte in lin-
guaggio naturale come input
5. Test
Prima di entrare in questa fase, ogni modulo e` testato singolarmente
16
attraverso unit test. Il waterfall struttura la fase di test in vari passi
(figura 2.4).
Figura 2.4: Dettaglio della fase di test
(a) Analisi dei requisiti
Quando si analizzano i requisiti, gli obiettivi del team di test-
ing e del team di sviluppo sono differenti.
Entrambi richiedono specifiche dei requisiti chiare e non ambigue
come input del loro lavoro.
Il team di test ne ha bisogno per scrivere un piano di test, svi-
luppare casi di test ed eseguire i test di accettazione.
Il team di sviluppo invece li usa per fare design e codifica del
software. Quindi il documento prodotto dalla fase di analisi dei
requisiti dovrebbe poter essere utilizzato per il duplice scopo di
cui sopra.
(b) Pianificazione della fase di test
Per evitare la situazione in cui errori di qualsiasi tipo si mani-
festino nella fase di test – il che implica rivedere tutto il processo
e quindi facilmente uscire dai termini temporali e/o finanziari
17
previsti – e` necessario investire in questa fase.
Le attivita` da pianificare hanno lo scopo di predisporre tutto il
necessario per i test di sistema e di accettazione che sono vicini
alla fine del processo di sviluppo, tra cui:
• La definizione di cosa dovrebbe essere testato e l’approccio
da usare
• Categorizzare i test, in modo che ogni requisito abbia asso-
ciato un opportuno insieme di test
• Stime del tempo da allocare alle varie tipologie di test da
eseguire
• Possibilmente, una analisi dei rischi legati ai test e un piano
per limitarli
(c) Design e implementazione dei test
Test di tipo dinamico eseguono un insieme di operazioni e con-
frontano il risultato di output con quello atteso.
Tutti i casi di test devono essere definiti in modo rigoroso e privo
di bachi.
(d) Test di sistema
Esistono due tipologie principali di test:
• Test funzionali: il loro scopo e` quello di determinare se il
sistema soddisfa i requisiti specificati.
• Test di prestazioni: questi test cercano di verificare il grado
di affidabilita` e di robustezza del prodotto.
Altre tipologie di test sono: test di sicurezza, di compatibilita`, di
usabilita` ecc...
(e) Test di accettazione
Il cliente puo` installare il prodotto e, attraverso l’uso, verificarne
la bonta`. Altrimenti puo` scrivere test particolari per acquisire
fiducia sul comportamento del sistema.
6. Installazione
In questa fase, come in ogni installazione, si prevedono i seguenti task:
• Installare il prodotto presso il cliente
• Fornire, se richiesto, un training agli utenti finali
• Supportare il cliente per un certo periodo di tempo concordato
18
Pregi
• La fase di testing coinvolge ogni fase precedente nel modello
• Il waterfall impone un approccio disciplinato nello sviluppare il soft-
ware
•
`
E un approccio guidato e supportato dalla documentazione.
Ogni passo comunica al successivo grazie a documenti specifici e rigo-
rosi.
• Storicamente, il contributo dato dal modello waterfall non e`datrascu-
rare.
Lo sforzo principale e` rivolto a far precedere l’azione di scrivere codice
da una esplorazione del dominio del problema da risolvere.
• Infine, la gestione manageriale di un progetto che e`compostodapassi
sequenziali e` molto chiara e controllata.
La schedulazione delle fasi puo` essere tracciata a priori e aggiustata nel
tempo permettendo di consegnare il prodotto, almeno teoricamente,
nei limiti previsti.
Difetti
• Il cambiamento, in qualsiasi punto sia richiesto (nuovi requisiti, pro-
poste di design migliori, problemi di qualsiasi tipo), non e`previsto.
• Spesso un cliente ha inizialmente solo una vaga idea di cosa esatta-
mente il prodotto software deve risolvere.
`
E normale attendersi una
naturale incertezza nella definizione del problema iniziale.
• Il cliente ha visione solo del prodotto finale; cio` implica che ogni pro-
blema non identificato durante lo sviluppo porta a gravi conseguenze.
• Tutti i dettagli devono essere definiti all’inizio. Non c’e`spazioper
erroriocorrezionidopocheildocumentodispecifichee` stilato. Inoltre
non c’e` feedback circa la complessita` intrinseca di ogni requisito, che
spesso non puo` essere prevista a priori.
• I team che lavorano nelle diverse fasi possono essere distinti e comu-
nicano solo tramite documentazione. Spesso e` difficile scrivere una
documentazione che sia al contempo chiara, completa ed efficace.
19
2.5 Rational Unified Process
Per superare i limiti del Waterfall si sono definiti nuovi processi nel tempo.
Il Rational Unified Process (RUP) e` un buon esempio di come l’esperienza
accumulata negli anni e` stata formalizzata e integrata nella metodologia.
RUP si puo` definire in modi diversi [14]:
1.
`
E un processo dell’ingegneria del software. Il suo obiettivo e`predis-
porre un approccio disciplinato che regoli lo sviluppo.
2.
`
Eunframeworkchepu`o modellare il processo stesso grazie a perso-
nalizzazioni. Cerca di evolversi collezionando le migliori pratiche dello
sviluppo del software che si imparano con l’esperienza.
Il RUP nasce da trent’anni di esperienza:
1967: Jacobson sviluppa un sistema component-based
1976: Nasce linguaggio di modellizzazione SDL
1987: Objectory: definiti gli use case, primi diagrammi
1995: Rational Objectory Process: UML, fasi, architettura
1997: Rational Unified Process: aggiunge attivita` di business modelling
2000: RUP con soluzioni per e-business
Come illustrato nella figura 2.5, il processo si sviluppa su due dimensioni:
Figura 2.5: Rational Unified Process: una visione d’insieme
l’asse orizzontale rappresenta il tempo e mostra gli aspetti del ciclo di vita
del software.
`
E l’aspetto dinamico del processo e si esprime in termini di
cicli, fasi, iterazioni.
L’asse verticale rappresenta le fasi del processo che raggruppano le attivita`
20
correlate. Sono quindi modellati gli aspetti statici del processo.
Le buone pratiche di programmazione di cui RUP e` caratterizzato sono:
Sviluppo iterativo:
`
E previsto e consentito il cambiamento dei requisiti.
L’integrazione non e` eseguita una sola volta al termine del ciclo di vita,
ma gli elementi sono integrati progressivamente.
Gli errori vengono scoperti nelle prime iterazioni, quando il prodotto
passa dalla fase di ‘inception’ a quella di ‘elaboration’. Si cerca quindi
di evitare la situazione in cui si ha una sola grossa fase di test verso
la fine del ciclo di vita. Gli sviluppatori possono apprendere nuove
conoscenze e gli specialisti sono coinvolti, con diverse intensita`, durante
tutto il ciclo di vita.
In un processo non iterativo, ad esempio, le persone addette al test
durante la fase di design non sono particolarmente produttive.
Gestione dei requisiti: I requisiti devono poter essere rivisti e chiariti.
Basandosi infatti sul concetto che la modifica di un requisito implica
un alto costo se si manifesta tardivamente nel processo di sviluppo, si
tende a non fissare i requisiti, ma a riconsiderarli di continuo.
Un’architettura basata sui componenti: Un componente puo` essere con-
siderato come un pezzo di software, ad esempio un package o un sot-
tosistema, che fornisce una funzionalita`benprecisaepu`o integrarsi
all’interno dell’architettura.
Un componente e` quindi la realizzazione fisica dell’astrazione definita
durante il design.
Gli Use Case guidano RUP in tutto il ciclo di vita; ogni use case
rappresenta un piccolo compito che il sistema attua a fronte di un
evento. Nelle prime iterazioni del processo l’obiettivo e`quellodipro-
durre e convalidare una architettura software che nasce come prototipo
e gradualmente evolve nel sistema finale.
RUP mette a disposizione un sistema di viste (view) che mostrano
diversi aspetti dell’architettura da definire.
Modellazione visiva del software: RUP usa intensivamente Unified Mo-
deling Language (UML). UML e` un linguaggio grafico usato per vi-
sualizzare, specificare, definire e documentare i costrutti di un sistema
software [16]. Si puo` pensare ad UML come ad un vocabolario, il quale
pero`nond`a le istruzioni necessarie, ad esempio, per scrivere un libro.
RUP cerca invece di rispondere a questa esigenza.
Verifica continua della qualita`: RUP afferma che assicurare la qualita`
del prodotto e del processo e` responsabilita` di tutte le persone, e non
di un gruppo specifico.
Il soddisfacimento delle qualita`pu`o essere raggiunto grazie alla crea-
zione e alla esecuzione di diverse tipologie di test. L’attivita`ditest
21