Sei sulla pagina 1di 36

DISTRETTO REGIONALE DELL’INFORMATICA

Distretto Regionale dell’Informatica


Proposta di Progetto

SMART
Strategies, Metodologies and
technologies for Agile Review and
Tranformation

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


1
DISTRETTO REGIONALE DELL’INFORMATICA

2009 DISTRETTO REGIONALE DELL'INFORMATICA


Tutti i diritti riservati
Stampato in Italia

Le informazioni contenute in questo documento sono proprietarie e riservate a tutti gli enti, Aziende,
Università, pubbliche e private, Centri di Ricerca, Organizzazioni Sindacali, facenti parte del
DISTRETTO REGIONALE DELL'INFORMATICA.

Nessuna parte del presente documento può essere riprodotta o trasmessa in qualsiasi forma o con
qualsiasi mezzo, elettronico o meccanico, incluse le fotocopie e la registrazione, per qualsiasi scopo,
senza l'espressa autorizzazione scritta del DISTRETTO REGIONALE DELL'INFORMATICA.

Questo documento è soggetto a modifiche senza preavviso, e gli enti non garantiscono che il materiale
contenuto in questo documento sia privo di errori.

Se avete dei problemi con questo documento, si prega di riferire per iscritto alla SEGRETERIA del
DISTRETTO REGIONALE DELL'INFORMATICA.

I marchi degli enti sopra citati costituiscono marchi commerciali dei rispettivi proprietari.

Le dichiarazioni circa ipotesi e scenari futuri sono forniti a solo scopo informativo e il DISTRETTO
REGIONALE DELL'INFORMATICA non assume impegni espliciti o impliciti in merito ai possibili
significati.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


2
DISTRETTO REGIONALE DELL’INFORMATICA

Indice

1. Sintesi della proposta di progetto ............................................................................... 4


1.1 Contesto ............................................................................................................... 4
1.2 Obiettivi ............................................................................................................... 6
1.3 Approccio ............................................................................................................. 8
1.4 Risultati attesi....................................................................................................... 9
2. Obiettivi ..................................................................................................................... 9
2.1 Obiettivi quantitativi e qualitativi ........................................................................ 9
2.2 Obiettivi scientifici e tecnologici ....................................................................... 11
2.2 Obiettivi a lungo termine ................................................................................... 11
3. Aspetti innovativi ..................................................................................................... 12
3.1 Stato dell’arte industriale ................................................................................... 12
3.2 Tecnologie e soluzioni già consolidate nel settore di riferimento ..................... 13
3.3 Progetti esistenti ................................................................................................. 15
3.4 Aspetti innovativi specifici del progetto ............................................................ 17
3.5 Rischi e strategie di gestione del rischio ............................................................ 17
4. Piano di progetto ...................................................................................................... 19
4.1 Struttura generale ............................................................................................... 19
4.2 Workpackages, deliverable e milestone ............................................................. 20
4.3 Tempistica e costi .............................................................................................. 34
4.4. Disseminazione e sfruttamento dei risultati ...................................................... 34
4.5 Obiettivi economici e finanziari......................................................................... 35

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


3
DISTRETTO REGIONALE DELL’INFORMATICA

1. Sintesi della proposta di progetto

1.1 Contesto

Il concetto di sviluppo agile del software, e quindi di metodologie agili, nacque nella
metà degli anni novanta in contrapposizione alle “metodologie pesanti” come può
essere ritenuto il modello a cascata tipico dell'Ingegneria del Software.
Il modello a cascata, infatti, gestisce il ciclo di vita del software con rigidi e corposi
processi di studi di fattibilità, di analisi dei requisiti, di progettazione, di codifica o
sviluppo, di testing e di manutenzione. Durante tutto il ciclo di vita del software,
inoltre, viene creata un'elevata quantità di documentazione. L'immediata conseguenza
di tutto questo è l'incapacità a rispondere velocemente ai cambiamenti.

Gli ecosistemi agili sono un insieme di metodologie tecnologie e risorse, basati su


principi similari. Inizialmente le “metodologie agili” venivano chiamate “metodologie
leggere”. Quello che queste metodologie tentavano di fare, era di snellire e
velocizzare il ciclo di vita del software. Quello che hanno in comune, è una serie di
principi condivisi alle quali affiancano una serie di pratiche per attuare i principi.
Queste metodologie fanno uso di una rapida progettazione del software riducendo la
documentazione all'essenziale o eliminandola del tutto, ponendosi nettamente in
contrasto con il “modello a cascata”. Il codice viene strutturato per adattarsi
facilmente e velocemente alle modifiche in corso d'opera richieste da utenti e dal
management, che vengono incoraggiati a proporle affinché il software sia allineato
alle aspettative dei clienti e ai bisogni aziendali. Il codice viene molto spesso
“ristrutturato” attraverso il refactoring per eliminare le duplicazioni, semplificarlo e
migliorarne la struttura e l'efficienza. Il codice scritto viene testato di continuo con
test automatici per renderlo sicuro e affidabile.

La moderna definizione di “metodologie agili” nasce nel 2001 quando diciassette


esponenti di queste metodologie si riuniscono nell'Agile Alliance, un'organizzazione
no-profit che ha come scopo la diffusione dello sviluppo agile. In seguito, crearono e
sottoscrissero l'Agile Manifesto che racchiudeva i “valori” e i “principi” che ne erano
alla base.

Definiti i “valori” e i “principi” dello sviluppo agile nascono le principali metodologie


che meglio definiscono una serie di “pratiche” da seguire per raggiungere gli obiettivi
adattandosi ai diversi contesti e ambiti nei quali andranno a lavorare. Le principali
sono Scrum (1986), Crystal Clear, Extreme Programming (1996), Adaptive
Software Development, Feature Driven Development e Dynamic Systems
Development Method (DSDM) (1995).

Al giorno d'oggi, le metodologie agili sono adottate da diverse realtà, sia a livello di
sviluppo di software che di management in generale. Tra le tante, possiamo citare
delle grosse realtà come Google, Microsoft, Toyota, Oracle, Ferrari, Nokia e Siemens.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


4
DISTRETTO REGIONALE DELL’INFORMATICA

PRINCIPALI METODOLOGIE AGILI

Extreme Programming (XP)


Extreme Programming è una metodologia agile formulata da Kent Beck, Ward
Cunningham e Ron Jeffries. L' XP si basa su valori, principi e pratiche. Uno degli
obiettivi è quello di rendere il costo delle modifiche da esponenziale a logaritmica in
modo da poter rispondere velocemente e in modo efficace a tutte le richieste di
cambiamenti dei clienti e del mercato.
Le richieste di modifica, infatti, devono essere ben accette cambiando prospettiva e
guardandole come una possibilità e non come un problema.

Alla base troviamo i quattro valori che sono i criteri astratti e generali da seguire per
produrre soluzioni di successo secondo l'XP. I valori sono importanti perché senza di
essi, l'uomo naturalmente, ha la tendenza a ritornare agli interessi di breve termine che
sono in contrasto con l'XP. I valori sono:
 Comunicazione (forte comunicazione tra sviluppatori, management e cliente)
 Semplicità (Concentrarsi su aspetti piccoli spezzettando il problema ed
evitando di guardare agli aspetti futuri)
 Feedback (il sistema viene continuamente verificato per garantirne la
consistenza. Il controllo viene effettuato con test di unità e funzionali
automatici)
 Coraggio (quando ci si rende conto che occorre fare un cambiamento anche
importante bisogna farlo se è utile.)

I valori vengono applicati in ogni aspetto dello sviluppo. Stabiliti i valori astratti
occorre stabilire dei principi concreti che ci permettono di decidere quale strada
seguire tra le varie alternative possibili. I principi incorporano i vari valori
eliminandone la vaghezza degli stessi.

Test Driven Development


È una tecnica iterativa di sviluppo software e il suo vero obiettivo è il design e non la
validazione. Il TDD è un pratica agile al contrario del XP che è una metodologia e
dalla quale è stata estratta. Le pratiche fondamentali del TDD prese dal XP sono:
 Scrivere i test prima del codice
 Refactoring (ovvero, riscrivere il codice per migliorarlo e renderlo più
efficiente)

Il TDD è il cuore del XP che può essere applicato in modo isolato senza
necessariamente usare le altre pratiche. I Test di unità nel TDD:
 Sono rilasciati con il codice di produzione.
 Nel TDD una funzionalità è rilasciata soltanto se vi è associata almeno uno
Unit Test.
 Consentono di effettuare il refactoring di una funzionalità senza “paura”.
 Meno debugging

Scrum
Lo Scrum fu ideato e sviluppato da Ken Schwaber e Mike Beedle e viene distribuito
attualmente da Advanced Development Methods.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


5
DISTRETTO REGIONALE DELL’INFORMATICA

Ha un approccio iterativo-incrementale ed è stato studiato appositamente per sistemi


dove i requisiti cambiano molto velocemente. I tre punti base sono: Sprint (blocchi
rapidi di lavoro con cicli di 30 giorni ed iterazioni di 24 ore), Backlog (piano di lavoro
immediato) e Scrum Meeting (riunioni giornaliere). Il termine Scrum è preso dal
Rugby che indica il pacchetto di mischia, metafora del team di lavoro che deve
lavorare compatto e spingere nella medesima direzione.

Feature Driven Development


È una metodologia agile, ideata da Jeff De Luca e Peter Coad, che propone una
robusta fase di analisi e progettazione integrata con un modello di sviluppo agile. Il
cliente viene continuamente utilizzato durante tutte le fasi. FDD non obbliga a creare
documentazione, ma obbliga a produrre diagrammi UML per avere una solida base
sulla quale lavorare. Il team è suddiviso in gruppi di 3-5 membri con un capo
programmatore che coordina il lavoro. Viene usato uno stile comune e vengono scritti
test di unità per la verifica seguendo le indicazioni del capo-programmatore. Il
refactoring viene scoraggiato, ma viene incentivata la condivisione del codice. Il pair
programming (programmazione a due persone) viene superato con team piccoli e
revisioni più ampie grazie alla condivisione del codice.

Dynamic System Development Method


Il DSDM più che una metodologia è un framework come viene definito dallo stesso
consorzio che lo promuove. È studiato in modo da integrarsi con le altre metodologie.
Basato anche questo su sviluppo iterativo e incrementale, ma prevede fasi preliminari
di studio di fattibilità e funzionali eseguiti in modo seriale. La parte agile si avrà dalle
fasi di analisi funzionale. Alla base dell'azione vi è il principio 80-20, cioè che 80%
delle cose buone viene fatta nel 20% del tempo dell'intero progetto. Quindi si
preferisce rilasciare una versione il più velocemente possibile per poi migliorarla e
correggerla secondo le indicazioni dell'utente. Ogni modifica deve essere interamente
reversibile. La fase di test è integrata nello sviluppo. Viene stabilita una numerosa
serie di ruoli e una persona può ricoprirne più di uno.

1.2 Obiettivi

Le metodologie agili stanno rivoluzionando profondamente i classici processi di


sviluppo del software, puntando su leve strategiche come la comunicazione estrema
tra i membri nei gruppi di sviluppo, il coinvolgimento continuo ed empatico del
cliente, la flessibilità ad ogni costo, e così via.

Negli ultimi anni c’è stata una forte sperimentazione dei singoli metodi, oggi sempre
più supportati da tools dedicati già annegati nei framework di sviluppo. I progetti
pilota hanno riguardato prevalentemente sviluppo di software al tempo 0, ovvero,
grossi o piccoli pacchetti, affrontati sin dall’inizio con metodi e strumenti per
l’Extreme Programming, SCRUM o simili. Nella maggior parte dei casi si è potuto
osservare l’effettiva efficacia dei metodi con riduzioni di tempi di sviluppo
ragguardevoli, insieme a forti riduzioni di costi di manutenzione ed upgrade dei
software stessi.

La presente proposta progettuale parte dall’osservazione che, se da un lato ogni


metodo agile descrive precisamente le fasi da affrontare quando si parte da zero;

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


6
DISTRETTO REGIONALE DELL’INFORMATICA

nessuno fornisce indicazioni su come comportarsi di fronte ad applicativi i cui


processi di analisi, progettazione, sviluppo, testing e manutenzione/upgrade sono già
avviati con le classiche metodiche dell’ingegneria del software. Ovvero non esiste una
metodologia ne tantomeno uno strumento tecnologico che sia in grado di guidare un
gruppo di lavoro a trasformare un progetto non chiuso e condotto su basi
deterministiche in un progetto sviluppato con metodologie agili basate su
approcci adattivi.

Intuitivamente si possono comprendere le potenzialità che una metodologia di


gestione del cambiamento in itinere da ciclo classico a ciclo agile, potrebbe avere nel
mondo dello sviluppo del software. La maggior parte degli operatori e delle imprese
produttrici, hanno difficoltà ad affacciarsi ai nuovi metodi agili in quanto visti come
“nuovo” in contrapposizione al vecchio ma consolidato. La prova di ciò risiede nel
fatto che l’approccio iniziale alle metodologie agili è cautelativo e si basa spesso sulla
prova duale, ovvero lo stesso progetto viene condotto in entrambi i modi per poi
valutare i risultati, con ovvie conseguenze sui costi (vedi esperienza Microsoft con
sqlServer 2005). In altri approcci, come il caso Toyota con il proprio ERP, si incide
fortemente sulla variabile tempo, decidendo di buttare via tutto ciò che si è fatto per
ricominciare da zero!

Condurre una ricerca sulla possibilità di individuare un metodo scientifico di


migrazione, con la minore perdita possibile di dati, documenti e codice, è il principale
obiettivo della presente proposta progettuale, che conseguentemente, apre temi di
indagine complessi ed interessanti:
 l’individuazione di metodi e tecnologie per trasferire dati ed informazioni
presenti su documentazione tipicamente non strutturata in dati gestiti da un
metodo agile (es. passaggio da diagrammi UML a linee di codice di
programma e di test in Xp);
 metodi per assistere la migrazione da stato attuale del ciclo classico a stato
attuale corrispondente del ciclo agile;
 problematiche relative all’organizzazione del gruppo di lavoro ed il modo in
cui lo stesso è abituato a lavorare (sono problematiche legate anche alla
formazione);
 metodi per la misura delle reali performance raggiungibili grazie ad un
approccio agile rispetto al modello waterfall.

Se in qualche modo si vuole gestire il cambiamento, in un certo senso è necessario


delineare linee di ricerca volte a rimuovere aspetti ancora non affrontati nel mondo
delle metodologie agili, che risultano però consolidati nei processi classici. Le
principali problematiche sono:
 carenza delle metodologie agili per gli aspetti di Project Management;
 le metodologie agili sono poco efficaci in caso di cooperazione
geograficamente distribuita (fuso orario, abitutidi differenti, etc..);
 meccanismi di Formazione anch’essa agile. Necessità di team con una
conoscenza medio/alta delle tecniche di programmazione e dell’ambiente di
lavoro;
 limitato numero di persone in un team;
 performance meno efficaci su progetti medio/grandi e/o molto complessi.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


7
DISTRETTO REGIONALE DELL’INFORMATICA

Tutti questi aspetti sono assolutamente presidiati da un Project Manager con strumenti
robusti se pur poco flessibili ed adattivi. Una WBS ben fatta, fa sicuramente dormire
più tranquillo un PM, poiché oltre a strumento di pianificazione (parola non
pronunciabile nel mondo agile!) rappresenta anche un cruscotto di controllo.
Il passaggio classico vs agile dovrebbe in un certo senso garantire che alcuni punti
fermi di riferimento continuino a fornire i propri servizi, in una modalità più leggera e
flessibile. Negli ultimi anni si sta cercando di ovviare al problema utilizzando più
approcci agili contemporaneamente (es. SCRUM per gli aspetti di Project Managemt
ed Xp per la stesura del codice). Nella presente proposta si cercherà di affrontare il
problema cercando di delineare una soluzione metodologica, il più possibile
svincolata dalle caratteristiche dei singoli approcci.

1.3 Approccio

Al fine di favorire l’introduzione di pratiche di project management e development


efficaci e riproducibili tra le aziende del Distretto Produttivo dell’Informatica pugliese
è necessario avere un riferimento concettuale comune così da conferire sistematicità
all’approccio di progetto. Poiché, in estrema sintesi, SMART intende introdurre in
modo controllato i benefici che possono derivare da una “agile software factory”, un
modello condiviso di “software factory” costituisce necessariamente il punto di
riferimento.

Figura 1: modello concettuale di software factory

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


8
DISTRETTO REGIONALE DELL’INFORMATICA

La Figura 1 propone il modello di software factory elaborato da Jack Greenfield,


Keith Short, Steve Cook e Stuart Kent in “Software Factories: Assembling
Applications with Patterns, Models, Frameworks, and Tools”, pietra miliare del
settore e che è utile assumere come riferimento concettuale per meglio in quadrare e
scomporre il problema. Nella visione di Greenfield, Short, Cook e Kent una software
factory.

1.4 Risultati attesi

 Metodologia per il change management nell’introduzione di approcci agili in


progetti già avviati
 Tecnologie che supportano l’introduzione delle metodologia nei processi di
business delle imprese del distretto dell’informatica Pugliese

2. Obiettivi

2.1 Obiettivi quantitativi e qualitativi

Gli obiettivi quantitativi:


 ridurre il time-to-market;
 ridurre i costi di progettazione, sviluppo e manutenzione;
 ridurre i costi marginali di upgrade;
 riduzione delle risorse umane necessarie per la realizzazione e la
manutenzione dei progetti;
 riduzione del numero degli errori, che comporta un minor numero di
interventi di manutenzione e quindi una riduzione dei relativi costi;
 migliorare le prestazioni dei gruppi di lavoro (produttività e qualità di lavoro);
 individuare strumenti e pratiche più efficienti/efficaci a supporto della
misurazione degli indicatori di prestazione dei gruppi di lavoro;
 individuare e applicare indicatori di prestazione utili nel controllo e nella
gestione dei progetti (aspetti economici, temporali, di impiego delle risorse)
con i metodi agili;
 realizzare uno stato dell’arte completo ed aggiornato sulle metodologie agili;
 definire gli aspetti concettuali di una metodologia di transizione controllata da
processo waterfall a processo agile;
 progettare un dimostratore di tool automatico di gestione di processo agile a
partire anche da componenti di mercato;
 scrivere pubblicazioni scientifiche (per la comunità della software
engineering) e pubblicazioni divulgative sugli aspetti metodologici e i risultati
pratici del progetto SAMART;
 grazie al nuovo processo di gestione del progetto software e agli strumenti
innovativi introdotti ridurre la “defect density” del 10-20%;
 grazie al nuovo processo di gestione del progetto software e agli strumenti
innovativi introdotti portare la percentuale di “rework” tra 10-20% del total
effort ad ogni iterazione.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


9
DISTRETTO REGIONALE DELL’INFORMATICA

Gli obiettivi qualitativi:

relativamente ai processi di ingegneria partecipata e rete:


 contribuire alla definizione di un modello di “software factory agile” per il
Distretto Produttivo dell’Informatica;
 definire di standard, accettati almeno a livello almeno regionale, che
consentano il formarsi di “culture” e “linguaggi” condivisi almeno fra le
aziende del distretto;
 aumentare la standardizzazione del codice grazie all’uso di design patterns;
 migliorare i rapporti con il cliente grazie alla predisposizione di strumenti
finalizzati ad un maggior coinvolgimento dello stesso;
 migliorare il livello di collaborazione nel/i gruppo/i di lavoro;
 ridurre il team size;
 migliorare il livello di integrazione tra le varie sedi geograficamente
distribuite sul territorio;
 acquisire una conoscenza strutturata sulle modalità di controllo e gestione dei
progetti che utilizzino metodologie agili;
 supportare un modello di software facory distribuita, che preveda parte del
processo produttivo presso i clienti e attività near shore presso uno o più
laboratori distribuiti; le attività presso i clienti devono poter variare in
dipendenza delle esigenze degli stessi e delle capabilities disponibili nei
laboratori distribuiti;
 definire punti di transizione formali fra attività presso i clienti e attività near
shore;
 contribuire alla diffusione delle metodologie agili ed alla cultura “del
cambiamento” nell’ambito della Regione Puglia, anche tramite corsi di
formazione permanente.

relativamente alla nuova conoscenza acquisibile:


 approfondire la conoscenza delle pratiche e degli strumenti a supporto delle
metodologie agili nello sviluppo di nuovo software così come nell’upgrading o
manutenzione di quello esistente;
 essere in linea con le innovazioni presenti sul mercato;
 migliorare la prospettiva culturale dei team di sviluppo aziendali affinché
possano considerare i cambiamenti richiesti dal mercato/clienti come
opportunità e non come “rogne” da gestire;
 disporre delle conoscenze, metodologie e tecnologie per capire ed
eventualmente misurare, gli effetti (positivi e/o negativi) della introduzione di
metodi agili nel processo di sviluppo del software;
 aumentare l’adattività del software per tutto il suo ciclo di vita;
 rendere intercambiabili gli sviluppatori attraverso un arricchimento e
allargamento dei compiti e nello stesso tempo rendere agile l’ integrazione di
nuove risorse nell’ambito dei progetti aziendali;
 acquisire la capacità di ristrutturare dei team di progetto per consentire il
passaggio alle metodologie agili e di riorganizzare i processi per consentire il
controllo e la misura delle performance dei team di lavoro.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


10
DISTRETTO REGIONALE DELL’INFORMATICA

relativamente alla qualità dei prodotti e dei servizi:


 migliorare la qualità del software avendo determinato le condizioni, i
prerequisiti e le tipologie di miglioramento che ciascuna metodologia
individuata può apportare;
 ridurre il software size a parità di funzioni;
 ridurre la complessità del codice realizzato;
 aumentare flessibilità, robustezza e manutenibilità del prodotto finale;
 migliorare la documentazione dei processi;
 rendere facilmente ripetibili i processi in caso di riuso, manutenzione, etc.

relativamente all’incremento di competitività sul mercato:


 migliorare la rispondenza alle richieste del mercato grazie ad una più rapida
capacità di reazione ai sempre più veloci mutamenti delle esigenze provenienti
dallo stesso;
 incrementare la produttività avendo determinato le condizioni, i prerequisiti e
le tipologie di incremento che ciascuna metodologia individuata può
apportare;
 ridurre il rischio tecnico e di budget dei progetti software;
 aumentare la precisione nella valutazione dei tempi di realizzazione dei
progetti;
 acquisire la capacità di attuare e supportare i propri clienti nell’attuare un
processo di migrazione verso metodologie agili.

2.2 Obiettivi scientifici e tecnologici

 Costruire una metodologia generale per il passaggio graduale da metodi di


sviluppo del software in modalità waterfall a metodi agili anche in casi di
progetti complessi già avviati;
 definire processi e regole per la misura di qualità;
 studiare delle dinamiche di gruppo e gestione del cambiamento;
 realizzare metodi e tecnologie per la gestione del cambiamento in caso di
ingegneria partecipata e distribuita;
 sperimentare metodologie in diversi settori di sviluppo del software.

2.2 Obiettivi a lungo termine

Investendo sul progetto SMART tutto il comparto della produzione del software del
Distretto dell’Informatica Pugliese potrà sicuramente crescere in intermini di
competitività sul mercato (non solo locale) puntando su leve come qualità e
flessibilità. Sul lungo periodo gli effetti del progetto su potranno sicuramente
apprezzare su diversi punti:
 rafforzare il comparto dell’informatica pugliese grazie a metodi e tecnologie
nuove con le quali è necessario confrontarsi per affrontare il mercato;
 migliorare la collaborazione tra imprese, enti pubblici ed università grazie
anche all’introduzione di pratiche che alimentano il dialogo e la
comunicazione;

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


11
DISTRETTO REGIONALE DELL’INFORMATICA

 perseguire la qualità non soltanto come caratteristica propria del prodotto


finale ma come fenomeno relativo all’intero ciclo produttivo da integrare in
ogni aspetto della gestione aziendale e nei processi di cooperazione con
partner, committenti e utilizzatori;
 favorire internazionalizzazione delle imprese afferenti al distretto;
 innovare le metodologie di sviluppo, restando concorrenziali con l’evoluzione
attuale del mercato;
 elevare la qualità delle risorse umane che operano nel settore dell’informatica
in Puglia.

3. Aspetti innovativi

3.1 Stato dell’arte industriale

Sul piano industriale i metodi agili sono utilizzati sia per gli aspetti di project
management, in cui la parte agile è più centrata sulle dinamiche di gruppo e sul
controllo e coordinamento, che per il metodo di sviluppo delle righe di codice. Casi di
successo ve ne sono veramente tanti, e di seguito si riportano quelli più significativi:
Software Development Project Management
Bank of America Ferrari Funambol GM Google Microsoft
Technologies
SA
Google Microsoft Nokia Omicron Oracle Quinary
Technologies
Srl
Siemens Sourcesense XP Labs Ericsson Altran Herzum Software
Irlanda
exoftware Boost New Seiryoku Zenyo, Inc Agile Partner Reaktor Borland Software
Media S.A Innovations

Laatukonsultointi Muzicall Knowledge Link AgileNorth Aspenware Klocwork


P. Kantelinen Oy Incorporated Internet
(Quality Solutions
Consultancy P.
Kantelinen)

Project Labs Ltd Skills Matter TCG The Mountain SOFT- 280 Group LLC
Consulting Guild Goat LUTIONS
AG Software
RMIC Object Mentor Graphics Epopeia Entreprise- Jaybis Konsult
Mentor Corporation Agile.com AB

Avenir AS Skyline Kring Development XoJom ProjectCards, Agilier Ltd


Technologies Corporation by ProjeNova
enrg.

E tanti altri (
http://www.agilealliance.org/corp_members,http://scrumalliance.pbwiki.com/Firms+
Using+Scrum). Un tale interesse verso questi metodi dimostra che le imprese
mondiali (grandi e piccole) stanno partecipando al cambiamento, e si intravede nel

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


12
DISTRETTO REGIONALE DELL’INFORMATICA

prossimo futuro un radicale ripensamento dei processi di sviluppo e manutenzione dei


software.

3.2 Tecnologie e soluzioni già consolidate nel settore di


riferimento

Le tecnologie che, nel corso degli anni, si sono sviluppate a supporto della produzione
del sosfware, hanno portato al consolidamento di attività incluse nel processo standard
di sviluppo. Tra queste, vale la pena ricordare JUnit (http://www.junit.org/) che ha
offerto un framework flessibile per la creazione e la verifica delle classi di test
necessarie alla convalida del software, ANT (Another Neat Tool,
http://ant.apache.org/) che ha consentito di formalizzare una sintassi attraverso la
quale eseguire le più fasi comuni (build, test, deploy, ecc.) relative alla progettazione
e sviluppo del software, Maven (http://maven.apache.org/) che ha standardizzato, e
quindi velocizzato, le attività relative al processo di produzione del software, SVN
(http://subversion.tigris.org/) e CVS (http://www.march-hare.com/cvspro/) che hanno
consentito una gestione appropriata e cooperativa delle risorse impiegate
contemporaneamente allo sviluppo del software.

Le tecnologie prima menzionate si sono affermate e consolidate diventando, di fatto,


strumenti indispensabili nello sviluppo del software a prescindere dalla metodologia
usata per governare le attività di produzione. Quindi si sono rilevate particolarmente
utili non solo nel modello a cascata, ma anche nell’applicazione delle metodologie
agili. Negli ultimi anni, inoltre, si sono affermate altre tecnologie nate dall’esigenza
da parte del mercato di offrire un ventaglio crescente di servizi con la medesima
applicazione, attraverso un alto grado di riusabilità e di integrazione con servizi a
grana grossa.

Un esempio di tale tendenza è il proliferare delle RIA (Rich Internet Application) in


grado di offrire applicazioni interattive ad elevata complessità e usabili attraverso il
web, senza alcun impatto sulle prestazione delle singole macchine client. Proprio in
quest’ottica, si sta diffondendo la tendenza a sviluppare applicazione orientate al
Cloud Computing (http://it.wikipedia.org/wiki/Cloud_computing) il cui obiettivo è di
offrire applicazioni attraverso tecnologie che permettono l'utilizzo di risorse hardware
o software distribuite in remoto. Molto spesso tali tecnologie sono basate su
architetture flessibili e che incoraggiano e agevolano la condivisione, quali
l’architettura REST (Representational state transfer,
http://it.wikipedia.org/wiki/Representational_State_Transfer). Ad esempio, Ruby on
Rail (http://it.wikipedia.org/wiki/Ruby_on_Rails) è un framework flessibile per la
generazione rapida ed efficiente di web application che incontrano i requisiti
menzionati. Queste ultime tendenze fanno percepire come il mercato richieda una
capacità di gestione dello sviluppo del software che sia sempre più snella, efficace e
condivisibile. In questo contesto, le metodologie agili offrono le linee guida e le
direttive più adatte ad andare incontro a tali esigenze.

D’altro canto, la crescente attenzione verso le metodologie agili ha dato origine a una
serie di tecnologie/soluzioni pensate ad-hoc per agevolare sia le fasi di sviluppo e test
dei prodotti, sia la loro commercializzazione. Ad esempio:

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


13
DISTRETTO REGIONALE DELL’INFORMATICA

 Pyjamas (http://pyjs.org/) è un compilatore stand-alone python to javascript


oltre che un framework Ajax ed un raccoglitore di API per i Widget.
 Phusion Passenger
(http://www.softdevtools.com/modules/weblinks/singlelink.php) è uno
strumento open source che agevola gli sviluppatori nella fase di deploy di
applicazioni Ruby on Rails usando una strategia di tipo “upload-and-go”.
Phusion Passenger aiuta a gestire in automatico i server Rails garantendo
stabilità e robustezza.
 .NetSpec (http://boss.bekk.no/display/BOSS/.NetSpec) è una estensione per
Visual Studio Testing Framework che consente agli utenti di scrivere i test
usando una sintassi RSpec in linea con il Behaviour Driven Development
rendendo i test semplici da comprendere
 Build Bot (http://buildbot.net/trac) è un sistema che automatizza il ciclo di
compilazione e test utile a validare i cambiamenti nel software. Build Bot
compila e test in maniera automatica il codice per ogni cambiamento nello
stesso. Consente di tracciare alcuni parametri quali compile time, image size
ed altri.

Particolare attenzione è stata posta non solo dai manager, ma anche da analisti e
sviluppatori verso l’esistenza di soluzioni complete di gestione e monitoraggio di
sviluppo di software basati su metodologie agili. Tali soluzioni sono reperibili sia
in ambito commerciale che in ambito open source e queste ultime possono essere
facilmente personalizzate in funzione delle specifiche esigenze nell’ambito del
progetto in cui la metodologia viene impiegata. Ad esempio:
 Tinypm (www.tinypm.com) è una soluzione orientata a supportare i team
mediante l’introduzione di user stories, story points, task board tipiche delle
metodologie agili. La soluzione prevede l’installazione on site ed il supporto a
progetti multipli oltre che la possibilità di creare dei progetti personalizzati e
di definire delle regole di utilizzo specifiche. Il tool offre sia soluzioni gratuite
(ma con un numero di utenti limitato) sia soluzioni a pagamento.
 Agile On Demand (http://www.serena.com/geo/it/products/agile-software/) è
una soluzione realizzata dagli inventori di Scrum John Scumniotales e Jeff
McKenna. La soluzione supporta progetti e team multipli e consente di
realizzare una semplice pianificazione di tutti gli sprint per drag and drop delle
storie su uno story board virtuale e di tenere traccia dell’andamento del
progetto. La soluzione fornisce anche strumenti collaborativi tipici del web 2.0
quali wiki, IM, feed RSS allo scopo di facilitare la comunicazione tra i diversi
partecipanti al progetto.
 Microsoft Solutions Framework (MSF) è un insieme di strumenti, best
practice, metodi che Microsoft ha raccolto nel corso degli anni e che servono a
guidare e aiutare nella realizzazione di sistemi software. E’ composto da
un’ampia documentazione, una raccolta di white paper e può essere adottato
con Team Foundation Server, Team Explorer, Windows Sharepoint Services,
Reporting Services, Microsoft Project e Microsoft Excel, che danno accesso
alle funzionalità di pianificazione, gestione della documentazione e del codice
sorgente, tracciamento di attività, bug, rischi, ecc. Microsoft all’interno di
Team Foundation Server fornisce due differenti versioni: “Microsoft Solutions
Framework for Agile Software Development” indicata per team di dimensioni
ridotte e fortemente agili; “Microsoft Solutions Framework for CMMI Process
Improvement” indicata per team medio-grandi, o comunque per quei team che

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


14
DISTRETTO REGIONALE DELL’INFORMATICA

necessitano di avere una maggiore tracciabilità e richiedono pratiche più


prescrittive, ad esempio per conformità a certificazioni di qualità ISO o simili.
 JIRA (http://www.atlassian.com/software/jira/solutions/agile-development.jsp)
si integra con uno strumento (FishEye) che consente ai membri del team di
condividere sul web il codice sorgente prodotto in modo da garantire a
ciascuno di lavorare e/o referenziare le varie parti di codice. Fornisce anche
supporto al pair programming e per tale motivo si integra con Cricible uno
strumento che offre agli sviluppatori la possibilità di tracciare direttamente il
codice su una interfaccia web.
 Rally (http://www.rallydev.com/agile_products/lifecycle_management/) è un
tool rivolto al project management agile. Supporta test management e defect
management. Può essere usato da membri del gruppo distribuiti
geograficamente sul territorio.
 Version One (http://www.versionone.com/) supporta la pianificazione,
tracciamento, scaling secondo i dettami delle più popolari metodologie di
sviluppo agili (Scrum, XP, DSDM, Agile Up). Consente di utilizzare
metodologie agili ibride.

3.3 Progetti esistenti

Di seguito alcuni progetti esistenti che riguardano tematiche relative all’adozione di


metodologie agili nello sviluppo di un progetto.

Metodologie agili per la produzione del software: validazione, modellistica,


impatto organizzativo e loro utilizzo per lo sviluppo distribuito e open source.
MAPS (Agile Methodologies for Software Production) è un progetto di ricerca con tre
obiettivi scientifici principali:
 creare un centro di competenze e di una comunità sulle metodologie agili per
diffonderle tra le aziende;
 definire misurazioni empiriche per assicurare l'efficacia dei processi di
sviluppo del software e la qualità del software prodotto utilizzando le
metodologie agili, rispetto alle misurazioni tradizionali;
 studiare le condizioni per l'utilizzo delle metodologie agili nei sistemi
software distribuiti, in particolare in applicazioni Open Source.

Il progetto MAPS è condotto da cinque unità di ricerca: l'Università di Cagliari


(coordinatrice), il Centre for Advanced Studies, Research and Development in
Sardinia (CRS4), l'Università Libera di Bolzano, l'Università di Genova e l'Università
di Milano.

Customising agile methods to software practices at Intel Shannon


Società: Intel Shannon.
Nazione: Irlanda.
Autori: Brian Fitzgerald: University of Limerick, Castletroy, Limerick, Ireland.
Gerard Hartnett: Intel Communications Europe, Shannon Industrial Estate, Shannon,
Co.Clare, Ireland.Kieran Conboy; Department of Accountancy and Finance, NUI
Galway, Galway, Ireland.

Il progetto parte dall’osservazione che l’adattamento di metodologie è comune nella

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


15
DISTRETTO REGIONALE DELL’INFORMATICA

maggioranza dei progetti di sviluppo software. Tuttavia non c’è sufficiente conoscenza
ed esperienza riguardo l’adattamento e l’ingegnerizzazione di metodologie agili, o
come questi metodi possono essere utilizzati congiuntamente per potersi completare a
vicenda. Questo progetto vuole studiare l’adattamento dei metodi eXtreme
Programming (XP) e Scrum nella società Intel Shannon, coinvolgendo ingegneri del
software con elevata esperienza che continuamente analizzano e interpretano i risultati
ottenuti su un arco di tempo di 3 anni. Lo studio mostra che i metodi agili presi
singolarmente possono essere incompleti nel supportare l’intero processo di gestione e
sviluppo di un progetto, ma XP e Scrum si completano a vicenda, il primo fornendo
pratiche di ordine tecnico e il secondo fornendo supporto alla pianificazione delle
attività e al controllo dell’andamento del progetto. I principi di XP e Scrum sono stati
scelti accuratamente (ad esempio solo 6 dei 12 punti chiave di XP sono stati adottati) e
adattati per ai bisogni dell’ambiente di sviluppo di Intel Shannon. Quindi lo studio
supera l’indivisibilità dei metodi agili e mostra come si ottengono i maggiori benefici
attraverso una combinazione sinergica delle singole pratiche.

AGILE
Ente: ITEA 2
Nazioni: Belgio, Bulgaria, Finlandia, Irlanda, Italia, Olanda, Slovenia, Spagna.
L’obiettivo del progetto è stato quello di accelerare lo sviluppo dei sistemi software in
modo da ridurne i costi ed i tempi, applicando i principi propri delle metodologie agili
(metodi, pratiche, tool) nel dominio dei sistemi embedded. Gli obiettivi generali del
progetto sono:
 sviluppare un sistema con i modelli software agili per il dominio specifico dei
sistemi embedded. Questo sistema richiede l’uso dei principali processi di
sviluppo software agili, di processi di supporto, di tool e di architetture per
sistemi embedded. Particolare attenzione è posta allo sviluppo software agile
negli approcci specifici selezionati: linee di prodotto software, sviluppo basato
sull’open source e component factories;
 conformarsi agli standard esistenti (ISO9000, CMMItm, DO178b, ecc.);
 sviluppare un modello di deployment in grado di utilizzare il nuovo sistema
di sviluppo software con le metodologie agili. Il modello di deployment
include processi, analisi pronte per l’uso e linee guida. Il modello è supportato
da un insieme di strumenti e da report sull’esperienza industriale;
 dimostrare l’efficacia operativa del sistema sviluppato, dei tool e del modello
di deployment in un numero di progetti software embedded operanti in diversi
settori industriali;
 dimostrare l’efficacia dell’approccio agile con la misurazione dei dati
ottenuti.

Il progetto AGILE, coniuga quindi, due tematiche di ricerca di notevole attualità quali i
sistemi embedded e le metodologie agili. Il soggetto proponente, vede nell’utilizzo
delle metodologie agili, un ottimo metodo per diminuire i costi dei propri processi
produttivi, con un inserimento graduale di tali metodologie all’interno dei propri
laboratori di produzione.

In quest’ottica, il progetto AGILE sottoposto a valutazione nell’ambito del programma


europeo ITEA da un consorzio di aziende e centri di ricerca coinvolti nell’area dello
sviluppo software di sistemi embedded, costituisce uno stimolo efficace per acquisire
know-how sulle metodologie agili.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


16
DISTRETTO REGIONALE DELL’INFORMATICA

I partner del progetto hanno ottenuto vari risultati:


 riduzione dei tempi fino al 70%;
 riduzione dei costi totali di sviluppo fino al 70%;
 produttività aumentata di 8 volte rispetto alla media delle aziende del settore;
 miglioramento della qualità di 3-5 volte rispetto alla media delle aziende e del
99% rispetto ai dati storici del settore;
 soddisfazione del cliente di 4,9 su una scala di 5;
 soddisfazione nel 70% degli sviluppatori che applicano la metodologia agile.

3.4 Aspetti innovativi specifici del progetto

Gli aspetti innovativi specifici del progetto possono essere così sintetizzati:
 personalizzare e profilare le metodologie agili per le aziende del distretto
producendo template di metodologia per dimensione di azienda, prassi
organizzativa, skill manageriale, skill tecnica;
 produrre metodologie agili ibride per meglio adattarsi al distretto pugliese;
 rafforzare le prassi di migrazione da metodologie waterfall e prescrittive
verso metodologie agili e trovare un modo standard e a sua volta agile di
divulgazione delle medesime;
 ideare meta modelli e modelli di migrazione da waterfall a agile
 mettere a punto strumenti di migrazione da waterfall a agile, anche per
configurazione di componenti esistenti.

3.5 Rischi e strategie di gestione del rischio

La gestione del rischio riguarda una serie di attività che riguardano l’accertamento, la
minimizzazione e il monitoraggio dei rischi associati allo sviluppo di un sistema
software. La gestione del rischio nei progetti che utilizzano la metodologia agile non
differisce sostanzialmente dai progetti che utilizzano metodologie tradizionali.
Tuttavia, le procedure utilizzate dai metodi agili inglobano implicitamente dei
processi che possono essere equiparati ad attività di gestione del rischio.
Un project manager che si trova a fronteggiare problematiche inerenti alla gestione
del rischio spesso deve affrontare le seguenti domande:
 rientreremo nel budget stabilito?
 manterremo la fiducia conquistata da un partner strategico?
 cosa accadrà se il progetto subirà ritardi?

È noto che la soddisfazione del cliente deriva dal rispetto dei tempi e delle specifiche
nella realizzazione di un progetto. Spesso non è così semplice stabilire se un progetto
sarà realizzato nei tempi stabiliti e se le funzionalità realizzate soddisferanno le reali
necessità del cliente. L’unico modo per controllare i rischi è quello di rilasciare
rapidamente il prodotto.

Le metodologie agili portano disciplina, misurabilità e riducono il rischio nello


sviluppo di applicazioni software. L’approccio su cui si basano le metodologie agili è
di produrre ogni due settimane ciò che è considerato come un set minimo di

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


17
DISTRETTO REGIONALE DELL’INFORMATICA

funzionalità che soddisfano le esigenze del mercato o del cliente. Anziché far fronte a
un problema di business complesso, questo viene approcciato in maniera più
granulare e progressiva, producendo e consolidando man mano un sottoinsieme delle
funzionalità che compongono l’intero sistema.
In ambienti tradizionali, l’identificazione dei potenziali rischi è eseguita in meeting
con un sottoinsieme dei membri del team. Nei progetti in cui si utilizzano
metodologie agili tutti sono coinvolti in questo processo, product owner, project
manager, designer, sviluppatori e tester in maniera iterativa ad ogni incontro di
pianificazione per l’iterazione successiva.
Il beneficio di questo approccio è che il cliente è in grado di fornire feedback continui
e tempestivi, decidendo ad ogni iterazione quante e quali funzionalità si aspetta, senza
attendere che l’intero sistema sia stato completato. In questo modo può anche
decidere, avendo esaminato le funzionalità prodotte nelle iterazioni precedenti, quali
sono le funzionalità che possono essere escluse dalle successive iterazioni, perché non
più necessarie al business oppure per dare precedenza ad altre componenti che si
ritengono prioritarie.
Inoltre, al termine di ogni iterazione viene analizzato ciò che è stato fatto insieme al
cliente. Questa è una buona occasione per rivedere la lista dei potenziali rischi e
valutare se ciò che è stato prodotto ha rispettato tale lista. Analizzando le funzionalità
ad ogni iterazione è possibile rivedere la lista dei rischi e modificarla in base all’uso
concreto del software prodotto.

I metodi agili coinvolgono lo sviluppo di test di unità e gli sviluppatori condividono il


codice piuttosto che lavorare singolarmente alle varie parti del codice. Una metrica
dello sviluppo agile chiamata “velocity” è diventata una misura essenziale nella
gestione dei progetti per tutte le società che impiegano questa metodologia. Essa stima
l’ammontare relativo di lavoro necessario a produrre funzionalità strategiche in base
alle priorità del mercato. È quindi una misura che aiuta il cliente a comprendere il
rapporto costi/benefici di una serie di funzionalità.

Tuttavia i metodi agili non risolvono tutti i problemi riguardanti la gestione del rischio
in un progetto di sviluppo software.
Uno dei principi chiave dei metodi agili è la partecipazione attiva di tutti gli
stakeholders, in particolare del cliente. Spesso però non è possibile avere a
disposizione il cliente in maniera proattiva e costante e molte pratiche dello sviluppo
agile sono rese più difficili in quanto non è possibile dare le giuste priorità ai task,
stabilire in maniera chiara i requisiti e gli obiettivi di una iterazione, comunicare
tempestivamente problemi e anticipare i rischi. Di conseguenza non si riesce a
rilasciare a fine iterazione il prodotto o il sottoinsieme di funzioni previste
nell’iteration planning.

Per le caratteristiche di collaborazione tra gli elementi del team e i vari stakeholders è
necessario che ogni componente abbia capacità di lavorare in gruppo, di relazionarsi
con i colleghi in modo costruttivo e senza creare attriti, sia in grado di comunicare con
trasparenza evidenziando i problemi eventuali in modo che insieme al team possano
essere superati. Tuttavia, non sempre gli sviluppatori sono in grado o hanno la voglia
di collaborare in maniera così stretta con gli altri. Si prenda, ad esempio, la pratica del
pair programming che richiede un grado di collaborazione e affinità molto elevato in
quanto si lavora affiancati per l’intera giornata. Anche la formazione del team non è
semplice, dato che deve contenere persone con tutti gli skill necessari per poter

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


18
DISTRETTO REGIONALE DELL’INFORMATICA

completare il progetto, pur restando in un numero ristretto di componenti. Un team


che adotta metodologie agili non deve superare i 5/7 elementi e tutti devono dedicarsi
al progetto sin dall’inizio ed essersi liberati da tutti i precedenti impegni. Non sempre
questi requisiti possono essere soddisfatti e la mancata presenza di tutti i componenti
del team ai vari incontri influenza negativamente i benefici che i metodi agili possono
apportare al progetto.

Altri problemi possono aversi se i componenti del team non sono tutti nello stesso
luogo, ma sono geograficamente distribuiti su più sedi. Diventa difficile in team
distribuiti mantenere un rapporto di comunicazione e collaborazione continuo. E’
meno immediato far circolare le idee e le esperienze all’interno del team e, quindi,
acquisire sempre maggiori informazioni riguardo sia alle pratiche metodologiche che
tecnologiche inerenti il progetto. Si è osservato su team che non hanno molta
esperienza nei metodi agili e che si trovano per la prima volta a doverli adottare, che
non sono colti subito tutti i benefici sperati. I primi progetti che un team agile
dovrebbe eseguire è bene che non siano né critici né impegnativi. Il team dovrebbe
trovarsi in contesti a basso rischio per poter affinare le pratiche della metodologia in
modo da comprenderne i problemi e le potenzialità, applicandole poi con successo a
progetti via via più complessi.

4. Piano di progetto

4.1 Struttura generale

WP1 (RI)
Scouting sugli ecosistemi agili e relative tecnologie: punti di
forza, lacune, opportunità, open source

WP3 (RI)
WP2 (RI) Change
WP4 (RI)
Change management
Change
management in Project
management e
in refactoring e Management e
ingegneria
Test Driven gestione del
partecipata
Development gruppo di
lavoro

WP5 (RI) : Metodologia generale a supporto dei processi di


migrazione da “waterfall” vs agile

WP6 (RI) : Metodologie per la misura di qualità negli


ecosistemi agili, tecniche di benchmarking rispetto ai metodi
classici

WP7 (SS+TT) : Sperimentazione e validazione del metodo


su casi concreti

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


19
DISTRETTO REGIONALE DELL’INFORMATICA

Il WP1 ha il compito di fare il punto della situazione e dello stato dell’arte. Le attività
dovranno presidiare i punti di forza ed i deficit delle varie metodologie soprattutto dal
punto di vista delle potenzialità di essere adottate in itenere, ovvero quando un
progetto è già stato avviato e va gestito il cambiamento.

I seguenti WP2, 3 e 4 prenderanno in considerazione tre specifiche tematiche che in


caso di migrazione vanno sicuramente considerate. Le tecniche di refactoring e
stesura dei test, vanno analizzate guardandole dal punto di vista delle potenzialità di
introduzione in codice già scritto o applicativi già consegnati all’utente finale e che
attendono di essere upgradati e/o mantenuti. Analogo discorso vale per i processi
presidiati dal Project Manager, dal team leader, e dai membri del gruppo di lavoro
(wp3). Importanti sono anche gli aspetti collaborativi, di comunicazione (tra membri
del gruppo di lavoro e con il cliente) nonché le problematiche che potrebbero nascere
in caso di migration in presenza di un gruppo di lavoro che sia anarchico e
geograficamente distribuito (es. progetto open source).
Una volta analizzati separatamente gli ambiti da presidiare nei processi di migrazione,
estrapolandone le linee generali, si procederà alla definizione di una metodologia del
cambiamento che ha il compito di acquisire le linee guida ottenute nei wp precedenti
ed orchestrarle in un modello unico. Il WP5 è stato introdotto allo scopo, e fornirà
anche le indicazioni di dettaglio per applicare il metodo a casi reali.

Il WP6 è dedicato alla misura delle performance ed alla verifica di qualità del metodo
individuato. In questo wp vanno individuati i parametri da misurare che siano in grado
di veicolare dati quantitativi del tipo: “cosa ho guadagnato in termini di
tempi/costi/risorse nel passaggio da approccio waterfall ad approccio agile??”.
Nell’ultimo WP saranno individuati dei casi di studio in cui si procederà a
sperimentare il metodo. Ovviamente come risultato ci si aspetta anche indicazioni su
come migliorare la metodologia individuata, oltre che spunti per ricerche future.

4.2 Workpackages, deliverable e milestone

WP1 : Scouting sugli ecosistemi agili e relative tecnologie: punti di forza, lacune,
opportunità, open source (RI)
Le attività del WP1 illustreranno lo stato dell’arte delle metodologie agile finora
elaborate che, applicando i principi espressi nel Manifesto Agile (Manifesto for Agile
Software Development - http://agilemanifesto.org/ ) rivoluzionano le metodologie
classiche di sviluppo software, basate su una raccolta delle specifiche e una
strutturazione sequenziale dello sviluppo software.
L’obiettivo del workpackage è di analizzare le caratteristiche delle diverse
metodologie agili, dei tools, dei programmi o piattaforme software, anche di tipo open
source, che ne consentono l’applicazione sui progetti
Per ogni tipologia ( metodi, tools, programmi open source) si evidenzieranno in
particolar modo i fattori che le rendano più idonee o meno ad essere adottate nei
progetti, con particolare riferimento a quelli già avviati secondo le metodologie
classiche, o per quelli che prevedono uno sviluppo cooperativo distribuito.

1.1 Scouting sui metodi

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


20
DISTRETTO REGIONALE DELL’INFORMATICA

Verranno analizzate le diverse metodologie agili finora elaborate ( SCRUM, FDD,


estreme Programming, ecc) che applicano i principi del Manifesto Agile,
evidenziandone per ognuna le caratteristiche, punti di forza e debolezza, oltre alle
condizioni per poterle utilizzare efficacemente nei progetti.
L’ attività avrà in output un report tecnico-scientifico, contenente l’ analisi delle
metodologie individuate in letteratura, con particolare riferimento al loro possibile
utilizzo nei progetti già in corso, per i quali è necessario gestire il cambiamento sia
per ciò che concerne lo sviluppo software che il project management.

1.2 Scouting sui tools e sulle tecnologie


Esiste un’ampia disponibilità di tool e tecnologie in grado di supportare le
metodologie e le pratiche agili che si intende adottare. Copiosa è anche la letteratura
sull’argomento: ad es. il sito di Agile Alliance ha un knowledge repository con
un’ampia libreria di articoli riguardanti le pratiche agili di sviluppo ed i relativi tools;
la rivista on line Methods And Tools (www.methodsandtools.com) è ricca di articoli
che affrontano ed approfondiscono le strategie di scelta dei diversi tools per progetti
agili, etc. Partendo dalla considerazione che: “There is nothing right or wrong with
agile approaches. Each project has its own context: developments teams, customer
requirements and organisational environment. You have to adopt the process that
gives your project the most chances to succeed under the current circumstances,
taking valuable tools from every approach” (Methods & Tools - Summer 2007),
particolarmente valida nel caso di applicazione di metodologie agili a progetti in
itinere o già conclusi, l’attività di scouting (che inizierà con la ricerca di quanto
eventualmente prodotto da parte delle università e/o imprese pugliesi appartenenti al
distretto) sui tools e sulle tecnologie, produrrà una panoramica dei principali tools
disponibili, con indicazione su quelli ritenuti più idonei all’utilizzo (sia così come
sono, sia previa eventuale realizzazione di opportune implementazioni / adattamenti)
in diverse casistiche di progetti già in itinere o già conclusi, basata su valutazioni
comparative dei diversi fattori di scelta. Successivamente, sulla base dei risultati della
sperimentazione e dell’applicazione ai casi concreti, potrebbero essere sviluppate
delle apposite strategie di scelta dei tools, valide per l’applicazione ai progetti in
itinere o già sviluppati.

1.3 Programmi Open Source


In questa attività sarà condotto uno scouting dettagliato sui progetti opensource che
riguardano i metodi agili.

WP2 : Change management in refactoring e Test Driven Development (RI)


È noto che nel modello a cascata di sviluppo del software i costi maggiori incidono
nella fase di test dell’applicazione essendo la stessa collocata soltanto alla fine del
processo di sviluppo. Per consentire un controllo della qualità del prodotto lungo
l’intero arco del suo processo di sviluppo e non solo a valle dello stesso, con i
maggiori costi che questo comporta, il modello agile, essendo di tipo iterativo
piuttosto che sequenziale, propone un approccio diametralmente opposto a quello
tradizionale. Ad esempio, con pratiche quali il Test Driven Development il cliente
espone il requisito che il software deve avere, viene scritto il test necessario a
raggiungere tale requisito ed infine si passa allo sviluppo, che non termina fino al
superamento del relativo test. Quando un requisito è soddisfatto si passa alla fase di
riprogettazione, che mira a migliorare il design ed aumentare la qualità del codice,
scrivendo un altro test per garantire che il requisito sia rispettato. In pratica, si

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


21
DISTRETTO REGIONALE DELL’INFORMATICA

stabilisce un insieme di test che vengono fatti girare prima sulla soluzione originale e
poi su quella riprogettata. Secondo tale approccio la progettazione appare quindi un
elemento transitorio da modificare costantemente durante l’intero corso del progetto.
A questo scopo, nell’ambito delle metodologie di sviluppo agile, viene solitamente
introdotto il Refactoring come tecnica idonea per gestire l’evoluzione rapida del
design. Tale tecnica prevede regole precise per effettuare le modifiche progettuali
riducendo in tal modo il rischio di introdurre errori. Naturalmente entrambe queste
tecniche presentano anche dei limiti che vanno attentamente analizzati e superati con
un utilizzo critico delle stesse in funzione delle caratteristiche del progetto:
dimensioni dell’applicazione, budget e tempi a disposizione, scopi di utilizzo del
prodotto, ecc. Il presente work-package, dunque, si propone di analizzare e definire
metodologie, strumenti e procedure per l’adozione mirata, controllata e riflessiva delle
tecniche di Test Driven Development e Refactoring per lo sviluppo di applicazioni
software di classe enterprise, con particolare riferimento a progetti già avviati e gestiti
secondo la metodologia classica. Al fine di consentire un utilizzo di tali tecniche nella
prospettiva indicata, si procederà:
 alla individuazione delle tipologie di applicazioni software di classe enterprise
rispetto alle quali valutare l’adottabilità delle tecniche in esame;
 alla identificazione delle proprietà interne ed esterne del prodotto e del suo
processo di sviluppo da monitorare mediante opportune metriche di qualità del
software;
 alla determinazione dei criteri in base ai quali operare il continuo
miglioramento delle modalità di utilizzo delle tecniche in esame.

Il WP2 è costituito dal seguente piano di lavoro:

2.1 Analisi dello stato dell’arte


L’azione si svilupperà attraverso un’indagine conoscitiva delle pratiche di TDD e
Refactoring così come sono utilizzate nell’ambito delle diverse metodologie agili.
L’indagine sarà finalizzata a selezionare le tecniche più efficaci ed efficienti nella
prospettiva di un utilizzo bilanciato del paradigma agile e in aderenza alle effettive
esigenze dei progetti di sviluppo di applicazioni di classe enterprise. Al termine delle
attività di indagine è prevista la produzione di un documento di scenario relativo alle
tecniche esaminate e alla loro applicabilità nello sviluppo di applicazioni di classe
enterprise.

2.2 Definizione del piano di misure


Questa attività ha lo scopo di definire un piano di misure, e relative procedure di
gestione, per il monitoraggio degli obiettivi di adozione critica delle pratiche TDD e
Refactoring. L’attività consisterà nelle seguenti sotto attività:
 definizione, attraverso la produzione di un opportuno documento, degli
obiettivi del piano di misure, tracciati rispetto agli obiettivi di adottabilità
stabiliti nel documento di scenario;
 definizione delle metriche e relative procedure di raccolta e misura per
ciascuno degli obiettivi elementari definiti nell’albero degli obiettivi;
 elaborazione delle misure e documentazione dei risultati, in cui vengono
stabiliti tempi e procedure di elaborazione dei dati di misura raccolti nel corso
del progetto e la struttura di documentazione dei risultati.

2.3 Qualificazione e selezione di strumenti per l’automazione delle pratiche di

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


22
DISTRETTO REGIONALE DELL’INFORMATICA

TDD e Refactoring
L’azione si svilupperà attraverso un’indagine conoscitiva dei tool a supporto delle
pratiche di TDD e Refactoring, con particolare riferimento alle tecniche individuate
nel documento di scenario. Ciascuno strumento esaminato sarà oggetto di studio allo
scopo di una sua integrazione nel contesto tecnologico di progetto. Al termine delle
attività di indagine è previsto il rilascio di un documento descrittivo delle modalità di
configurazione e integrazione dei tool individuati nel contesto tecnologico dato.

2.4 Training e linee-guida per l’applicazione delle best practice


Scopo dell’azione è acquisire il know-how necessario relativo alle tecniche esaminate
e, allo stesso tempo, fornire le linee-guida per l’adozione delle medesime tecniche
nell’ambito di progetti di sviluppo di applicazioni software di classe enterprise, con
particolare riferimento alle problematiche relative alla migrazione da una gestione
tradizionale a quella agile. Il know-how relativo alle best practice sarà acquisito
mediante attività mirate di training. Al termine delle attività è previsto il rilascio di un
documento di linee-guida per l’applicazione delle best practice.

WP3 : Change management in Project Management e gestione del gruppo di


lavoro (RI)
Il WP3 ha un importanza cruciale per la diffusione ed il successo delle metodologie
agili. E’ proprio per porre rimedio all'ingestibilità del “Project Management” su
progetti molto dinamici che queste metodologie sono più frequentemente adottate.
Di fatto, taluni progetti si prestano poco ad una pianificazione top down molto
formalizzata delle attività e pongono problemi di controllo manageriale. L'approccio
agile, apparentemente meno formalizzato e più “caotico”, è invece l'unico che
consente di mantenere un accettabile determinismo nell'entropia di alcuni contesti di
sviluppo. Questo rende i metodi agili uno strumento prezioso nelle mani del PM,
purché accetti di modificare le logiche con cui ha sempre gestito la sua attività.

Le attività incluse nel WP hanno l’obiettivo di definire le migliori pratiche per


facilitare il passaggio ad un nuovo approccio:
 nella gestione delle risorse umane del gruppo, con una loro maggiore
responsabilizzazione rispetto al management, senza però che quest'ultimo
venga percepito come assente – anzi, il management in un team agile è ben più
presente che in un processo waterfall-, e con l’obiettivo di definire e gestire un
processo di formazione del team di progetto capace di rinforzare
significativamente le capacità e l’efficacia dell’interaziione con il proprio
management e con il Committente;
 nella gestione della pianificazione delle attività, e soprattutto dei momenti di
verifica del risultato delle attività stesse, che dovranno essere improntate a
maggiore pragmaticità e frequenza.

Per questi argomenti sarà opportuno fare più riferimento a paradigmi di PM come
SCRUM rispetto ad altri paradigmi agili, in quanto più orientato al Project
Mangement rispetto alle altre metodologie. Questa maggiore attenzione non va però
intesa come una obbligatorietà di adozione di questa particolare metodologia ma solo
di un suo suggerimento nei casi in cui l'aspetto di PM risulterà preponderante su
quello di ingegnerizzazione del codice.

3.1 Formazione del gruppo di lavoro al nuovo modo i lavorare: aspetti

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


23
DISTRETTO REGIONALE DELL’INFORMATICA

psicoattitudinali e cognitivi
Le metodologie agili sono spesso introdotte con un approccio “dogmatico” o di
“evangelizzazione”, e questo può produrre delle resistenze nei team, soprattutto nel
caso in cui ci si trovi di fronte a tecnici con anzianità di servizio elevata, i quali in
genere sono più resistenti al cambiamento. Questa attività ha l’obiettivo di definire il
migliore approccio per l'attività di addestramento alla nuova metodologia, capace di
facilitare la comprensione dei vantaggi che la sua adozione comporta per tutto il team.
Aspetti su cui far leva, per aumentare l'interiorizzazione della metodologia è
l'introduzione di una metodologia di training permanente, anch'esso tipico di
SCRUM, incetrata sulla necessità per tutti, incluso il Team Leader o Scrum Master, di
“partire da zero” e di mettersi in gioco in modo positivo, con l'opportunità di
migliorare insieme la qualità del lavoro ma anche la qualità della interazione con i
colleghi ed il committente.

3.2 Dinamiche di gruppo: efficacia ed efficienza


Essendo l'elemento umano la chiave di volta di ogni approccio definito agile, questa
attività è critica da ogni punto di vista. Un team agile funziona solo se il “fattore
umano” al suo interno è in condizione ottimale o viene mantenuto tale. L’obiettivo di
questa attività è la definizione di metodi attraverso i quali ottenere questo risultato,
come ad esempio:
 eliminare e/o attutire tutti gli attriti ed i problemi comunicativi interni al team;
 facilitare la comprensione del fatto che le metodologie da adottare si basano
su un approccio fortemente collaborativo fra tutti gli attori del processo,
compreso il committente;
 reimpostare, ovvero eliminare, le gerarchie interne al team in modo tale da
adattarle il più possibile all'approccio role-less dei team agili. Facendo
attenzione a che nessuno percepisca ciò come una diminuzione delle proprie
mansioni;
 verificare le varie pratiche agili che si desidera adottare insieme al team e
adattarle al contesto umano del progetto. E' possibile per esempio che si voglia
adottare il Pair Programming, ma uno o più sviluppatori non si adattino a
questo approccio, con il risultato di un calo di efficienza dove ci si attende un
incremento. In questo caso può essere utile abbandonare l'ipotesi del Pair e
sostituirlo con altre pratiche per l'aumento della produttività.

3.3 Processi di project management, pianificazione e controllo


Si tratta di un altro punto critico su cui si possono incontrare resistenze. Questa
attività ha i seguenti scopi operativi:
 definire un modello di pianificazione per team distribuiti;
 definire criteri, basati sulla tipologia del domino applicativo, sulla
composizione del team e sulle caratteristiche strutturali del progetto per
customizzare il processo di sviluppo. Tali criteri devono essere capaci di fare
percepire al team che la responsabilità del Project Management è, nelle
metodologie agili, condivisa da tutti i membri del team in ragione del loro
livello di esperienza e integrazione nel processo;
 supportare un modello di gestione del progetto che passa da un modello
classico di tipo “Command and Control” ad un modello in cui il PM è uno
Stakeholder (sia che si tratti di un PM interno che di un PM designato in seno
alla struttura del Cliente), che necessita della collaborazione del team;

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


24
DISTRETTO REGIONALE DELL’INFORMATICA

 definire la durata degli intervalli di pianificazione delle attività, che dai


periodi lunghi del modello waterfall si articolano negli Sprint di SCRUM (o
analoghi intervalli brevi);
 definire le modalità di valutazione standard dell'output finale di una fase di
lavorazione, da valutazione formale di documentazione ponderosa a test
operativo, con il committente sempre coinvolto su un deliverable che può
essere messo in produzione.

WP4 : Change management e ingegneria partecipata (RI)


I metodi di sviluppo del software basati su approcci agili hanno mostrato il loro
tallone di Achille nei progetti complessi, ed in tutte le situazioni in cui il gruppo di
lavoro è distribuito. C'è oggi un enorme interesse scientifico e industriale nello
sviluppo cooperativo del software da parte di gruppi, e singoli programmatori, che
comunicano tramite Internet. Questa realtà si sta diffondendo sempre di più, avendo
solide basi economiche (sviluppo in nazioni ove il costo del lavoro è più basso,
telelavoro in ambiente domestico, riduzione dei costi di trasferte, ecc). Una notevole
percentuale del software open source ad esempio è prodotto in questo modo.
Se a ciò si aggiunge che i progetti, sebbene sempre più brevi nella loro durata
temporale, sono generalmente più complessi, si può ben capire come i project
manager si trovino ad operare ormai in ambienti altamente "caotici" e sempre più
distribuiti. In tale contesto diviene estremamente importante saper gestire gli aspetti
collaborativi e di comunicazione tra membri di team di lavoro distanti
geograficamente, e saper garantire quegli aspetti di Project Management, che nella
metodologia classica presiedono alla pianificazione e al controllo delle attività di
progetto.

Le attività del WP4 saranno quindi incentrate sul tema del Change Management con
particolare riferimento ai progetti di sviluppo software cooperativo geograficamente
distribuito.

4.1 Metodologie agili a supporto dello sviluppo software distribuito e concorrente


Gli ambienti caotici e distribuiti in cui spesso ci si trova ad operare, mettono in
discussione i principi teorici base del management "tradizionale", specialmente quelli
legati alla stabilità dei requisiti o dei presupposti iniziali di progetto.Inoltre, viste le
difficoltà che la delocalizzazione del processo di sviluppo porta con sé, il quesito da
affrontare è come le pratiche delle metodologie agili possono essere d’aiuto ad un
processo di sviluppo distribuito e concorrente. Le attuali metodologie agili ad esempio
prescrivono pratiche non compatibili con lo sviluppo distribuito concorrente, come il
pair programming, il lavorare tutti nello stesso spazio, con il cliente sul posto. Scopo
dell’attività è di verificare quali siano le condizioni per poter utilizzare efficacemente
le metodologie agili in tale contesto e come le stesse debbano adattarsi. Risultato
dell’attività sarà un report tecnico scientifico contenente, per ogni metodologia agile
individuata nel WP1, le caratteristiche che meglio si prestano al contesto
dell’ingegneria partecipata e un confronto tra le stesse pratiche, al fine di individuare,
anche combinandole tra loro, l’approccio migliore da adottare nel contesto suddetto.

4.2 Strumenti a supporto dello sviluppo software distribuito e concorrente


Sicuramente la gestione di un progetto di ingegneria partecipata richiede elevate
competenze di project management per creare e gestire processi adatti agli scopi

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


25
DISTRETTO REGIONALE DELL’INFORMATICA

prefissati: sono infatti diversi i fattori che possono rallentare od ostacolare il corretto
sviluppo del progetto.La possibilità di miscommunication e/o misunderstanding in un
progetto distribuito è maggiore (distanza, fuso orario, cultura, lingua).
Conseguentemente, da un lato, il project management dev’essere anche più rigoroso
di quanto avviene nei progetti onsite, dall’altro, divengono fondamentali gli strumenti
a supporto dello sviluppo software e dell’ interazione fra le risorse impiegate..La
presente attività avrà in output un report tecnico-scientifico con un’ analisi delle
caratteristiche degli strumenti a supporto dello sviluppo software distribuito (
redazione, revisione collaborativa del codice,ecc) e dei tools di supporto alla gestione
e collaborazione delle risorse impegnate ( WMS-workflow Management System,tools
di comunicazione, messaggistica,ecc ), per l’utilizzo delle metodologie agili in un
contesto distribuito.

4.3 Pair programming distribuito


Il pair programming è la pratica diffusa in diverse metodologie di sviluppo agile, che
richiede a due programmatori di lavorare seduti uno accanto all’altro su una stessa
macchina, e che sta emergendo sulle altre proprio per l’efficacia che ne deriva.
Per sua stessa natura, tuttavia, il pari programming mal si presta ad una applicazione
in un contesto distribuito. Esso infatti richiede non solo la co-locazione della coppia di
programmatori, ma anche frequenti cambiamenti delle coppie stesse, al fine di evitare
dipendenze. Tale pratica deve quindi essere “adattata” per un suo utilizzo in contesti
di sviluppo distribuito, allo scopo di abbattere il problema della co-locazione
mantenendo tutti i benefici che sono stati osservati. Risultato dell’attività sarà un
report tecnico- scientifico, in cui ci si focalizzerà sulle metodologie e strumenti di
sviluppo che possono essere utilizzati per affrontare le problematiche descritte e
“adattare” così il pair programming al contesto distribuito, nonché le buone pratiche
per la gestione del cambiamento in progetti già in corso, dove le risorse per il pair
programming sono delocalizzate.

WP5 Metodologia generale a supporto dei processi di migrazione da“waterfall”


vs agile (RI)
Le attività del WP5 saranno focalizzate alla individuazione di una metodologia
generale a supporto della migrazione della modalità di gestione dei progetti software
basata su fasi sequenziali (waterfall) e “up front design” a modalità iterativa e agile.
La metodologia individuata sulla base di quanto le migliori innovazione
dell’ingegneria del software stanno proponendo a livello internazionale, ma calata
sulle specificità del Distretto Produttivo dell’Informatica pugliese, sarà descritta in
modo formale. In particolare, saranno specificati: (a) un tipico modello waterfall [base
di partenza della migrazione], (b) un modello generale che rappresenti i concetti
salienti delle metodologie agili [punto di arrivo della migrazione], (c) le regole
formali e informali di mapping tra (a) e (b). Al fine di dominare la complessità di
individuazione e specifica della metodologia di migrazione, il processo di sviluppo
del software sarà scomposto nelle sue quattro componenti strutturali: (1)
Requirements/Analysis, (2) Design, (3) Code, (4) Test/Evolve. Ad ognuna delle
precedenti componenti sarà applicata la tecnica di migrazione tramite mapping
formale prima descritta. Parallela e comparativa scomposizione potrà essere operata
utilizzando le quattro fasi del Rational Unified Process (RUP): (1) Inception, (2)
Elaboration, (3) Construction, (4) Transition. Per raggiungere l’obiettivo descritto, il
WP5 sarà organizzato nelle seguenti attività.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


26
DISTRETTO REGIONALE DELL’INFORMATICA

5.1 Definizione dei principi basilari del metodo


Verranno definiti tutti gli aspetti formali che consentono di modellare il punto di
partenza (modello waterfall), il punto di arrivo (modello agile) le regole di mapping
(migrazione da waterfall a agile). Si farà uso della tecnica delle ontologie per la
modellazione e specifica del metodo.

5.2 Definizione delle pratiche a supporto del metodo


Poiché la metodologia di migrazione da waterfall a agile dovrà essere di ampia ed
immediata adozione da parte delle aziende del Distretto Produttivo, gli aspetti formali
output dell’attività 5.1 saranno ricondotti a pratiche ingegneristiche di supporto e
applicazione della metodologia stessa. Si farà riferimento alle migliori pratiche
riconosciute dalla comunità tecnico/scientifica internazionale dell’ingegneria del
software.

5.3 Definizione degli strumenti di project management e development a supporto


del metodo
Al fine di rendere più semplice l’applicazione delle pratiche ingegneristiche output
dell’attività 5.2 e di favorire la sistematicità d’adozione, saranno progettati strumenti
specifici di project management, anche a partire da componenti di mercato. Agli
strumenti di project management saranno affiancati strumenti di
sviluppo/testing/integration/deployment, selezionati tra le varie comunità di pratica
dell’ingegneria del software (Open Source, .NET ecc.).

5.4 Definizione dei casi di inapplicabilità o applicabilità parziale del metodo


Benché si cercherà di mettere a punto una metodologia di migrazione da waterfall a
agile sufficientemente generale, si possono prevedere casi di difficile applicazione o
criticità che potranno emergere dall’adozione in particolari segmenti tecnologici o
mercati. Di tali casi si darà descrizione nell’attività 5.4.

WP6 : Metodologie per la misura di qualità negli ecosistemi agili, tecniche di


benchmarking (RI)
Poiché il progetto SMART cerca di sfruttare appieno, l’addove lo si reputerà
profittevole, le potenzialità di un nuovo approccio alla produzione del software,
diventa critico fornire una risposta concreta sulla misura del grado di efficienza del
metodo anche in rapporto agli approcci classici basati sui metodi a cascata. In termini
di misura di qualità del software esistono ormai normative ISO consolidate, come le
ISO 9000, ISO 9002, ISO 9003, ISO 9126 (quest’ultima più specifica).
In questo WP si cercheranno gli indici misurabili in grado di fornire un valore di
qualità negli approcci agili che consentiranno di effettuare benchmark congruenti
rispetto ai metodi più classici. Così come detta la normativa si guarderà il ciclo di vita
del software rispetto ai seguenti aspetti.

Funzionalità:
 appropriatezza: ovvero coerenza rispetto alle esigenze dell’utente o del
committente;
 accuratezza: correttezza e precisione dei risultati prodotti;
 interoperabilità: capacità di interagire con altri sistemi;
 ottemperanza: conformità a norme, convenzioni e regolamenti;
 sicurezza: capacità di prevenire accessi non autorizzati alle informazioni e
funzioni del prodotto o servizio;

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


27
DISTRETTO REGIONALE DELL’INFORMATICA

Affidabilità:
 maturità: distribuzione dei malfunzionamenti in funzione degli errori presenti
nel sw;
 tolleranza agli errori: capacità di mantenere livelli predeterminati di
prestazioni anche in presenza di malfunzionamenti o usi scorretti;
 ricuperabilità: capacità di ripristino in seguito a malfunzionamenti.

Usabilità:
 comprensibilità: facilità di comprensione dei concetti del prodotto;
 apprendibilità: facilità di apprendimento;
 operabilità: facilità d’uso operativo.

Efficienza:
 rispetto al tempo: tempi di risposta;
 rispetto alle risorse: uso delle risorse del sistema.

Manutenibilità:
 analizzabilità: facilità con la quale è possibile localizzare un errore nel codice;
 modificabilità: facilità con la quale è possibile cambiare il codice;
 stabilità: livello di rischio di effetti indesiderati attraverso la modifica del
codice;
 collaudabilità: sforzo necessario per il collaudo.

Portabilità:
 adattabilità: capacità di adattamento ad ambienti operativi diversi;
 installabilità: facilità di installazione;
 conformità: conformità a standard e specifiche relative alla portabilità;
 sostituibilità: facilità di uso al posto di un altro componente.

Un capitolo importante che verrà trattato in questo WP è quello del dimensionamento


economico. E’ noto ormai che per progetto complessi, gli approcci agili, se applicati
toutcur tendono a far divergere i costi, per via della flessibilità richiesta al gruppo di
lavoro.

6.1 Determinazione del cocktail di indici qualitativi e quantitativi significativi


Questa attività si occuperà di determinare sia gli indici più appropriati ad una corretta
valutazione dell’intero ecosistema agile risultante dal WP5, che quelli necessari ad un
benchmarking tra il processo waterfall precedentemente applicato ed il processo agile
in seguito adottato. Gli indici saranno determinati in base agli aspetti del ciclo di vita
di un software presi in considerazione tra le norme ISO attinenti alla
standardizzazione della qualità in ambito di produzione di software ed altri eventuali
parametri che verranno presi in considerazione in base alle attività svolte nei
precedenti WP. Tali indici saranno alla base delle successive attività di questo WP e
dovranno così rispondere alle richieste di misura di qualità, di valutazione tra processi
differenti e di calcolo dei costi.

6.2 Definizione delle linee guida per la progettazione di un sistema di misura di


qualità nei processi agili

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


28
DISTRETTO REGIONALE DELL’INFORMATICA

Si partirà dagli indici risultanti dall’attività 6.1 per studiare un processo appropriato
alla misura della qualità dei differenti ecosistemi agili studiati per il passaggio da
waterfall ad agile, in modo da poter definire una serie di processi di calcolo applicabili
sia in diversi contesti applicativi che su differenti approcci agili.
Le linee guida risultanti da questa attività, unite agli indici di valutazione
precedentemente identificati, saranno la base per lo studio e la produzione delle
metodologie di misurazione della qualità e di benchmarking tra approcci differenti
previste in questo WP.

6.3 Analisi e disegno del processo per la misura di qualità


In questa attività si definirà la metodologia di misura della qualità per poter valutare
l’efficienza di ogni tipo di approccio agile preso in considerazione durante i WP
precedenti. Tale metodologia sarà applicata come valutazione di un qualsiasi progetto
svolto secondo il processo waterfall e poi trasportato nel mondo agile ma sarà
applicabile anche ad ogni progetto svolto interamente secondo le metodologie agili
evidenziate nei WP precedenti. La procedura individuata dovrà avere la caratteristica
di non dipendere dal contesto applicativo che il progetto sw andrà a gestire.

6.4 Analisi e disegno del processo di benchmark rispetto agli approcci waterfall
Date le diversità di metodologia tra gli approcci a cascata ed agili, si deve studiare un
processo di benchmarking appropriato e che, tramite gli indici studiati nell’attività
6.1, riesca a fornire dei parametri di confronto consoni alla valutazione dell’efficienza
di ogni metodologia di processo rispetto alle altre. Lo scopo di questa attività è di
trovare un processo (parametrizzabile in base agli indici precedentemente identificati
ma comunque generico) per poter valutare i risultati previsti (ed eventualmente
parzialmente prodotti) da un processo waterfall rispetto ai risultati prodotti dopo la
sua conversione a processo agile.

6.5 Metodi per la determinazione dei costi


Scopo di questa attività è definire un metodo per il monitoraggio delle variazioni di
costo lungo l’intero ciclo produttivo di progetti di sviluppo gestiti secondo il
paradigma agile. La metrica misurerà gli scostamenti tra i valori di pianificazione e
quelli a consuntivo. A causa della caratteristica iterativo-incrementale del processo
software adottato, gli indicatori saranno riferiti a ciascuna iterazione di processo, in
modo da monitorarne il trend nel corso dell’intero progetto. Le misure si riferiranno al
costo pianificato e sostenuto per le attività di sviluppo alla conclusione di ciascuna
iterazione di processo. L’andamento dei costi sarà misurato considerando opportuni
indicatori, quali ad es. l’indicatore di variazione di costo (Costo sostenuto ─ Costo
previsto), che saranno individuati nel corso dell’attività di indagine. Il risultato
relativo all’andamento dei costi di progetti basati sul paradigma agile - già di per se
significativi rispetto ad una valutazione dell’andamento dei costi non limitato al solo
prodotto finale ma all’intero ciclo di vita del software - sarà opportunamente
confrontato con i costi sostenuti nell’ambito di progetti di sviluppo gestiti secondo il
paradigma a cascata.

WP7 : Sperimentazione e validazione del metodo su casi concreti (SS+TT)


Il WP7 sarà caratterizzato soprattutto da attività di Sviluppo Sperimentale e
Trasferimento tecnologico. Le prime hanno l’obiettivo di sperimentare i metodi agili
in vari settori mentre le seconde sono rivolte al trasferimento dei risultati verso tutti
gli attori del settore che vogliano impiegarli nei propri processi di produzione. Inoltre,

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


29
DISTRETTO REGIONALE DELL’INFORMATICA

poiché i metodi agili eliminano o sostituiscono alcuni elementi di tracciabilità di


informazioni relative al ciclo di vita del software, inevitabilmente si dovranno
affrontare anche le implicazioni giuridiche di tale aspetto. Se da un lato si tende ad
eliminare la carta inutile e dall’altro confrontarsi continuamente con l’utente o cliente
acquisendo frequenti approvazioni informali, è necessario capire ed interpretare le
esigenze probatorie in sede di contenzioso ed accertamento delle responsabilità.
La fase di validazione del metodo sarà condotta dai diversi partner industriali del
progetto, ognuno nel proprio settore. Gli approcci alla sperimentazione possono essere
molteplici, uno di essi potrebbe essere basato sulla conduzione di un progetto sia in
modalità waterfall che agile per poi effettuare i benchmark sugli indici di qualità
individuati nel WP ad essi dedicato. Il punto di forza di tale metodo è quello di
misurare bene sin dall’inizio gli indici sul modello classico per un confronto
oggettivo. Un secondo metodo vede invece coinvolto un progetto già chiuso che viene
affrontato nuovamente introducendo del tutto o in parte la metodologia agile. Un terzo
approccio, orientato alla riduzione dei costi di sperimentazione e validazione, è quello
in cui il metodo agile viene applicato in itinere, o solo in fase di manutenzione e/o
upgrade. Un specifica attività, la 7.1 avrà pertanto come obiettivo quello di definire la
migliore strategia possibile, tenendo conto delle esigenze specifiche dei partner di
progetto o addirittura delle esigenze dell’intero distretto.

7.1 Definizione delle modalità e strategie di sperimentazione


L’attività 7.1 mira a definire le strategie di validazione e sperimentazione della
metodologia definita nei WP precedenti. I casi di sperimentazione saranno condotti su
settori presidiati dai partner industriali del progetto. Gli ambiti di intervento possono
essere così sintetizzati:
 Progetti e/o commesse nuove: si tratta di progetti a complessità media da
affrontare da zero. In questo caso le strategie di sperimentazione dovrebbero
vedere l’avvio del progetto in modalità classica, per poi decidere di migrare
verso i metodi agili in itinere. Importante in questo caso misurare alcuni indici
di qualità in entrambe le fasi
 Progetti già avviati: si tratta di individuare alcuni pj da migrare su metodologie
agili partendo dal punto in cui si trovano. In questo caso sarebbe bene
scegliere quei progetti tenuti già sotto controllo sui parametri di qualità, tempi
e costi.
 Progetti da avviare con gruppi paralleli. Come nel primo caso in cui al fine di
garantire il risultato del cliente, si decide ad un certo istante di avviare un
secondo gruppo con metodologie agili. Pertanto il risultato sarà garantito da un
gruppo che continuerà a lavorare in modo classico e nello stesso tempo si
procederà alla sperimentazione del metodo agile, e dei relativi processi di
migrazione.

7.2 Sviluppo di tools specifici


L’obiettivo di questa attività è la definizione e lo sviluppo di una suite di tools open
source a supporto di alcune fasi del ciclo di sviluppo e gestione agile definito. La
suite di tools, web based, dovrà permettere di gestire progetti full-agile, o anche
progetti che utilizzano le metodologie agili customizzate (in alcune fasi oppure in
alcuni metodi). Funazionalità chiave della suite saranno:
 tools di supporto alla pianificazione (Scrum, Custom);
 tool di time tracking;
 tools di produttività e di collaborazione (toDo list, dashboard);

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


30
DISTRETTO REGIONALE DELL’INFORMATICA

 tools di gestione versioni;


 tools di pianificazione ed esecuzione test;
 tools di supporto, bug tracking e di help desk;
 tools di reportistica e metriche.

L’approccio che verrà seguito prevede l’analisi di tools open source esistenti, la loro
selezione, la loro specializzazione e integrazione e l’implementazione di strumenti
originali a supporto dell’intero ciclo metodologico definito.

7.3 Sperimentazione e validazione in ambito Manifatturiero


Di seguito alcune applicazioni della Libet, già sviluppate, da utilizzare come casi
concreti di progetti di upgrading funzionale, attuato anche in futura ottica SaaS, su cui
effettuare la sperimentazione e la validazione delle metodologie di sviluppo agile del
software:

1. Gestione della Qualità – Modulo “Valutazione Fornitori”


Nell’ambito di un applicativo sviluppato per la gestione delle attività inerenti la
qualità aziendale in imprese manifatturiere, esiste uno specifico modulo per la
valutazione periodica dei propri fornitori; tale modulo software tuttavia è
caratterizzato da un’estrema variabilità degli algoritmi di calcolo adottati dalle
diverse realtà aziendali. Ciò richiede una pesante revisione del software ogni
qualvolta si voglia rispondere efficacemente alle esigenze di un nuovo cliente.
Sarebbe pertanto auspicabile rendere il suddetto modulo meglio manutenibile (o
addirittura parametrico, personalizzabile dall’utente finale) proprio nell’ottica di
voler implementare nuovi metodi di valutazione dei fornitori, sulla base delle
specifiche esigenze del singolo cliente.

2. DAC (Data Automation Converter)


Trattasi di un modulo software, già sviluppato, avente il compito di elaborare i
dati di produzione acquisiti da un sistema di automazione industriale, al fine di
trasferirli ad altri sistemi gestionali di archiviazione e consuntivazione. Ogni
qualvolta si voglia inserire la gestione di un nuovo dato acquisito dal sistema di
automazione o si voglia attivare l’interfacciamento con un sistema di
automazione industriale di diversa impostazione, questa è impresa alquanto
ardua e certamente onerosa in termini di risorse richieste. Sarebbe pertanto
auspicabile:
a. parametrizzare il trattamento di nuovi dati acquisiti dallo specifico
sistema di automazione industriale;
b. rendere, l’elaborazione effettuata, indipendente dallo specifico
sistema di automazione industriale.

7.4 Sperimentazione in ambito gestione e controllo territoriale


Le attività da svolgere riguardano l’individuazione di un progetto, tra quelli in corso,
iniziato secondo la metodologia waterfall e applicargli le procedure sviluppate
all’interno di questo progetto. Il progetto scelto sarà di tipo WebGIS, ossia produrrà
un’applicazione web utile alla consultazione on-line di mappe dinamiche. Gli
elementi a maggiore criticità di tali sistemi sono la complessità (elevato numero di
sottosistemi) e la richiesta di prestazioni elevate (archivi di mappe che possono anche
arrivare a terabyte di dati composti da singole mappe di centinaia di Gigabyte che
devono essere consultate on-line). Per questo motivo verrà valutato come, le

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


31
DISTRETTO REGIONALE DELL’INFORMATICA

procedure definite, si applicano alla fase di sviluppo del sistema, a quella di


produzione dell’informazione (generazione delle mappe tematiche o di sfondo) e a
quella operativa (messa in linea delle informazioni, monitoraggio del sistema, ecc.).
Gli output previsti per l’attività sono:
- il sistema funzionante del progetto scelto o di un suo sottosistema
- nota tecnica sulla terminazione del progetto scelto, che comprenderà le
seguenti informazioni:
 adeguatezza delle metodologie sviluppate al contesto WebGIS, in
principal modo rispetto ai requisiti operazionali (performance);
 complessità del cambio di strategia nella conduzione del progetto;
 feedback da parte dello staff sugli impatti del cambio in termini sia
operativi che formativi;
 feedback del cliente.

Il sistema GIS sarà poi applicato in un caso reale di Business Intelligence Territoriale,
dove la vastità dei dati e delle analisi possibili è fonte di stress per le metodologie più
tradizionali. Infatti la BIT risente della scarsa comprensione che le Pubbliche
Amministrazioni, principale mercato di riferimento cui si rivolge, hanno delle proprie
potenzialità e della loro cronica incapacità di esprimere l’analisi funzionale delle
procedure desiderate, in un linguaggio chiaro e formalizzabile. L’obbiettivo è quello
di applicare le metodologie agili per beneficiare di un processo di sviluppo non più
basato sul paradigma monolitico, ma di sviluppare un modello agile che dia la
possibilità al cliente PA di emettere le specifiche di analisi durante l’intero ciclo di
vita dello sviluppo software. Per ottenere questi risultati ci si propone di analizzare di
nuovo l’intero ciclo di vita del software, stressando principalmente il concetto di
“problem solving” e modificando la struttura dei team di sviluppo, che dovranno
essere formati appositamente per migliorare la comunicazione, la gestione dei
feedback, la semplicità e l’indipendenza operativa in ogni fase dello sviluppo. Gli
output previsti per l’attività sono:
- Il sistema funzionante del progetto scelto o di un suo sottosistema
- nota tecnica sulla terminazione del progetto scelto, che comprenderà le
seguenti informazioni:
 adeguatezza delle metodologie sviluppate e loro impatto nella
realizzazione del progetto e del Team di sviluppo.
 complessità del cambio di strategia nella conduzione del progetto
 feedback da parte del Team di sviluppo sugli impatti del cambio in
termini sia operativi che formativi
 feedback del cliente

7.5 Sperimentazione in ambito sistemi informativi e gestionali


La sperimentazione in ambito dei sistemi informativi gestionali, sarà condotta sia su
web application e procedure batch, che su procedure di collaborazione applicativa, in
precedenza sviluppate con metodi classici. Sarà necessario scegliere un sottosistema
di cui si conoscono in dettaglio i tempi e le performance per la realizzazione e per gli
interventi di manutenzione. Dopo il periodo di formazione delle necessarie risorse, si
procederà alla migrazione del sottosistema preso in esame, dei dati e della relativa
documentazione verso l’ambito del sistema SMART. Dal precedente WP6 si
rileveranno gli indici di misurazione delle performance (costi, tempi, ecc.) raggiunte
dall’approccio agile, confrontandoli con le analoghe performance realizzate con i

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


32
DISTRETTO REGIONALE DELL’INFORMATICA

metodi tradizionali. Il raffronto sarà necessario per indicare la convenienza e la


completezza dell’applicazione dello SMART ai sistemi con tipologia gestionale.

7.6 Sperimentazione in ambito visualizzazione avanzata


Verrà selezionato un progetto in corso d’opera che presenta problematiche inerenti la
visualizzazione avanzata. Successivamente si procederà con l’applicazione della
metodologia del cambiamento da waterfall ad agile. Potrà essere così verificato
l’impatto di una metodologia agile su questo genere di progetti sia riguardo ai
canonici parametri di valutazione (tempi e costi) che ai seguenti aspetti critici, tipici
dei progetti di visualizzazione avanzata:
 integrazione di differenti framework (data processing, 3D engine, audio
engine, physic engine, tracker engine, real time render engine, ecc…);
 manutenzione e modifiche del codice precedentemente prodotto;
 carenza di documentazione di alcune tra le librerie utilizzate;
 performance;
 integrazione di hardware dedicato (dispositivi per la visualizzazione e
fruizione stereoscopica, dispositivi di tracciamento, dispositivi aptici,
architetture cluster, ecc…).

7.7 Feedback migliorativi sulla metodologia


La fase di sperimentazione e validazione produce dati utili a rafforzare ed ottimizzare
il metodo, facendo emergere i suoi punti di forza e debolezza. In questa attività viene
riaffrontata la fase di costruzione metodologica, attraverso un riciclo volto alla
soluzione di problemi evidenziati dai fatti empirici in fase di sperimentazione.
Si prevedono di elaborare due tipologie di feedback migliorativi della metodologia di
migrazione da waterfall a agile:
1. feedback derivanti da analisi quantitative su Key Performance Indicator
definiti sulla metodologia stessa, in modo da rilevarne punti di forza, punti di
debolezza e, quindi, margini di miglioramento;
2. feedback derivanti da analisi qualitative, ad esempio ottenute per mezzo di
sessioni di “user observation”, così da evidenziare e descrivere comportamenti
(corretti o meno) di applicazione della metodologia.

Si porrà attenzione all’usabilità della metodologia stessa, cioè alla sua efficacia e
facilità di adozione nell’ambito industriale.

7.8 Verifica delle performance e della qualità


Tramite i criteri di valutazione studiati e la sperimentazione prevista sui progetti nei
loro diversi ambiti, si potrà valutare l’efficacia della metodologia del cambiamento
proposta. In questa attività convoglieranno tutti i risultati delle attività di
sperimentazione. Nello stesso tempo si utilizzerà il processo di misura della qualità
definito nel wp 6, al fine di valutare il metodo sui casi reali. Grazie ai risultati della
sperimentazione sarà poi possibile eseguire un raffinamento della metodologia del
cambiamento. Gli ambiti di intervento dell’attività riguarderanno più
specificatamente:
 analisi delle performances e della qualità della migrazione da waterfall ad
agile nei vari progetti coinvolti nella sperimentazione;
 eventuale fine-tuning della metodologia del cambiamento in base ai risultati
ottenuti nei diversi ambiti..

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


33
DISTRETTO REGIONALE DELL’INFORMATICA

7.9 Implicazioni giuridiche dell’impiego di metodi agili nel ciclo di vita di sviluppo
del sw
In questa attività sarà affrontato il tema delle implicazioni giuridiche nell’utilizzo di
metodologie agili, le quali come noto prediligono l’informalità e la collaborazione e
comunicazione continua in luogo della produzione di carta, verbali, etc.. Nel caso di
contenzioso è necessario capire come reperire gli elementi probatori, al fine di
dimostrare determinati fatti ed avvenimenti. Tale linea di ricerca risolta del tutto
inedita pone le basi per determinare l’effettiva applicabiltàd ei metodi agili nel mondo
reale in cui alcune dinamiche (come quelle legate agli aspetti legali) non possono
essere eluse.

7.10 Trasferimento Tecnologico


Le azioni di trasferimento tecnologico saranno supportate da una piattaforma in grado
di assistere a diverse fasi grazie all’erogazione di servizi quali:
 azioni di auditing settoriale;
 formazione ed informazione;
 raccogliere conoscenza costruita nel progetto e trasferire l'innovazione, di cui
essa è portatrice, nei processi di business indipendentemente dagli autori della
stessa;
 generare comunità di interesse che facciano circolare al loro interno i risultati,
le metodologie, le competenze e le tecnologie;
 assistenza nella specializzazione dei risultati per l'uso de gli stessi in un
particolare progetto;
 mediazione per la vendita di competenze, tecnologie e servizi.

Nella seguente tabella si riporta la suddivisione delle attività sui partner del progetto

4.3 Tempistica e costi

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19 M20 M21 M22 M23 M24
WP1
WP2
WP3
WP4
WP5
WP6
WP7

Ricerca Sviluppo Trasferimento


Industriale Sperimentale Tecnologico Totale
2.700.000 1.200.000 500.000 4.400.000

4.4. Disseminazione e sfruttamento dei risultati

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


34
DISTRETTO REGIONALE DELL’INFORMATICA

4.5 Obiettivi economici e finanziari

Lo sfruttamento economico dei risultati del progetto sarà correlato al numero ed alla
tipologia di fasi di sviluppo prodotto in cui il metodo di trasformazione waterfall vs
agile si rivelerà realmente efficace. Le variabili che entrano in gioco nel delineare un
probabile incremento delle leve di competitività sono veramente molteplici, ed
ognuna influenza per certi aspetti i processi di sfruttamento dei risultati:
 l’introduzione di standard produttivi, culture e linguaggi condivisi tra le
aziende del distretto, partner nazionali ed esteri;
 il maggior coinvolgimento del cliente;
 l’aumento della capacità di adattarsi alle dinamiche del mercato;
 l’aumento della cultura del lavoro di gruppo e del lavoro distribuito;
 il miglioramento della qualità del software;
 l’aumento del grado di flessibilità delle funzionalità applicative;
 l’incremento del il tasso di riuso interno del software;
 la riduzione del time-to-market;
 la capitalizzazione del lavoro svolto mediante l'incremento e l’oggettivazione
del know-how acquisito;
 l’incremento della penetrazione di mercato dei prodotti e dei servizi dei
partner;
 l’incremento della produttività attraverso la progressiva riduzione dello sforzo
necessario per lo sviluppo di nuove funzionalità e la manutenzione dei prodotti
preesistenti;
 la fidelizzazione delle aziende clienti mediante la protezione e valorizzazione
degli investimenti già fatti.

Ovviamente a fronte leve positive, sussistono rischi ormai ben focalizzati dei quali è
necessario tener conto nel corso del progetto ed in fase di sfruttamento dei risultati. La
minimizzazione della documentazione, per di più non standardizzata, fa sì che tutta la
conoscenza del prodotto che si sta sviluppando sia racchiusa nelle persone che ci
lavorano. Questo origina seri problemi di comprensione dell’organizzazione del
sistema quando il progetto è di grande dimensioni, in quanto la comunicazione interna
con più di 20 persone diventa difficile. Si hanno inoltre difficoltà nel caso di rotazione
e cambiamenti delle risorse del team, in quanto i nuovi arrivati fanno molta fatica ad
apprendere la conoscenza che è “disseminata” nelle persone. Problemi ancora più seri
nascono quando il proprio applicativo si deve interfacciare con altri, magari progettati
da gruppi di lavoro diversi, in quanto la realizzazione delle interfacce è rallentata
dall’assenza di documentazione standard e condivisa.

L’attenzione posta al ruolo delle persone, che in un certo senso suppliscono alla
mancanza di procedure e metodi codificati, se da un lato è da considerarsi positiva in
quanto stimola la creatività e la produttività personale, all’altro rende particolarmente
critiche la qualità e le skill dei programmatori, che devono in ogni caso possedere una
“mentalità agile”. Sul fronte dei test e re factoring, la validazione dei requisiti
solamente attraverso l’esecuzione di versioni parziali dell’applicazione rischia inoltre
di degenerare in processi di code & fix senza fine, rendendo critica l’evoluzione del
prodotto. L’estrema semplificazione, volta a snellire il processo, riduce fortemente la
possibilità di esplorare soluzioni alternative e, se portata all’eccesso, può rivelarsi una
strategia miope. Infine l’incertezza nella determinazione dei costi reali durante tutto il

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


35
DISTRETTO REGIONALE DELL’INFORMATICA

ciclo di vita del progetto ne limita fortemente l’applicabilità reale in determinati


contesti.

In linea di massima non esiste un metodo per decidere se impiegare la strada waterfall
o agile, SMART si propone come metodo bilanciato, volto alla scomposizione del
problema in sottoproblemi meno complessi sui quali si decide poi se agire in modalità
agile (e con quale metodo) o in modalità classica. Uno indicazione su come procedere
la forniscono Boehm e Turner (Boehm, B. e Turner, R. Balancing Agility and
Discipline: a guide for the perplexed. Addison-Wesley, 2002.) propongono cinque
dimensioni secondo cui analizzare il contesto in cui ci si trova a dover sviluppare
l’applicazione:
 criticità;
 dimensione;
 cultura;
 dinamicità;
 qualità del personale.

Ad ognuna di queste dimensioni viene associate una metrica di riferimento, in modo


che l’ambiente in cui l’applicazione deve essere sviluppata possa essere misurato
secondo esse.

DISTRETTO INFORMATICA - Progetto ML3.1 - SMART.doc


36