light ode processi e tool di sviluppo rev 5.pdf · una delle più diffuse metodologie agili è...
TRANSCRIPT
Pagina 1 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
LightCode
Processi e Tool di Sviluppo del Software v05.00
Pagina 2 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Introduzione
Questo documento presenta l’approccio di LightCode allo sviluppo dei progetti software.
Si tratta di un manifesto che descrive i principi e le pratiche che regolano i seguenti aspetti del processo di
sviluppo:
Relazione con i clienti
Elicitazione e gestione dei requisiti
Pianificazione del progetto
Definizione di architettura e progettazione del software
Realizzazione degli artefatti software e scrittura del codice
Controllo qualità
Gestione cambiamenti
L’applicazione di tali pratiche negli anni con successo su progetti reali e con soddisfazione dei clienti, la
ricerca e il continuo miglioramento, e l’investimento costante nella formazione e nelle metodologie e
tecnologie all’avanguardia sono motivi di orgoglio aziendale.
Questo documento, seppure con tratti tecnici, ha l’obbiettivo di evidenziare il valore di business che il
processo utilizzato in LightCode può generare per il cliente finale.
Tale valore si manifesta per il cliente nei seguenti aspetti:
Qualità della soluzione realizzata, in termini di robustezza, usabilità, e attinenza alle esigenze di
business con evidente soddisfazione degli utenti.
Manutenibilità del software, con abbattimento di costi e tempi di modifiche del sistema nel tempo,
e con garanzia di longevità della soluzione e protezione dell’investimento del cliente.
Focalizzazione sul business, collaborando con il cliente per “spendere” il budget e l’effort sulle
funzioni che più avvantaggiano il business, e per definire una pianificazione che prevede rilasci
incrementali al fine di poter utilizzare il prima possibile funzionalità importanti, favorendo il ritorno
di investimento.
Pagina 3 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Metodologie “Agile” nella realizzazione del Software
Introduzione alle Metodologie “Agile” Nell'ingegneria del software, per metodologie “Agile” s’intendono dei metodi particolari per lo sviluppo del software che coinvolgono quanto più possibile il committente, ottenendo in tal modo un’elevata reattività ed aderenza alle sue richieste. Le metodologie agili mirano a ridurre il rischio di criticità e di fallimento dei progetti attraverso diversi strumenti e pratiche:
Sviluppo Time-Boxed: il team procede con finestre di tempo limitate chiamate “iterazioni” che, in genere, durano poche settimane. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione, analisi dei requisiti, progettazione, implementazione, test e documentazione. Gli obiettivi a breve termine permettono di misurare in modo più efficace la produttività e di mantenere focalizzato il team, creando maggiore commitment.
Feedback frequente: Il cliente è coinvolto durante tutto il ciclo di sviluppo del software per regolari revisioni. Gli incrementi di software sono rilasciati in ambienti pilota (o di produzione quando maturano funzionalità adeguate per un utilizzo effettivo). Il feedback raccolto permette al team di correggere la direzione dei lavori in tempo utile.
Ottimizzazione del budget: Il cliente ha la possibilità, ad ogni iterazione, di rivedere insieme al team le priorità dei requisiti da realizzare. In questo modo il team sviluppa prima le funzionalità con maggiore valore per il business. Questo, unitamente al rilascio degli incrementi di software, permette al cliente di anticipare il “Return On Investment”, potendo utilizzare il software stesso il prima possibile, e potenzialmente prima del termine di rilascio stabilito.
Risposta ai cambiamenti: Sempre con il meccanismo della revisione delle priorità in corso d’opera, il cliente ha la possibilità di introdurre funzionalità a maggior valore a discapito di altre che durante lo sviluppo si sono rivelate meno importanti o obsolete.
I principali elementi teorici ed il Manifesto alla base delle metodologie “Agile”, oltre ad ulteriori informazioni di approfondimento, sono disponibili sul seguente sito: www.agilemanifesto.org
Metodologia “Scrum” Una delle più diffuse metodologie agili è “Scrum”, ideata e sviluppata da Ken Schwaber e Mike Beedle verso la fine degli anni novanta. Si basa su tre semplici punti: “Sprint”, “Backlog” e “Scrum Meeting”. La metodologia “Scrum” prevede di:
dividere il progetto in blocchi rapidi di lavoro (Sprint) con l’obiettivo di potenzialmente consegnare al cliente una funzionalità utilizzabile alla fine dello Sprint;
indicare come definire i dettagli del lavoro da espletare nell'immediato futuro (Backlog) per averne una definizione estesa;
organizzare riunioni giornaliere del team di sviluppo (Scrum Meeting) per verificare e pianificare cosa si è fatto e cosa si farà.
Pagina 4 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Il termine Scrum è mutuato dal mondo del Rugby: indica il pacchetto di mischia ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un'unica entità coordinata. Scrum è stato utilizzato in aziende di ogni dimensione, tra cui: Microsoft, Yahoo, Google, Electronic Arts, Lockheed Martin, Philips, Siemens, Nokia, IBM, Capital One, BBC, Intuit, Nielsen Media, First American Real, Estate, BMC Software, Ipswitch, John Deere, Lexis Nexis, Sabre, Salesforce.com, Time Warner, Turner Broadcasting, Oce. Scrum è stato utilizzato per le più diverse tipologie di prodotti software: Commercial software, In-house development, Contract development, Fixed-price projects, Financial applications, ISO 9001-certified applications, Embedded systems, 24x7 systems with 99.999% uptime requirements, Video game development, FDA-approved, life-critical systems, Satellite-control software, Websites, Handheld software, Mobile phones, Network switching applications, ISV applications.
Pagina 5 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Processi di “Project Management”
Le principali “Fasi” costituenti il processo di “Project Management” sono le seguenti:
Planning & Release Management
Risk & Crisis Management
Performance Management
Planning and Release Management Il ciclo di sviluppo è organizzato secondo due livelli di pianificazione:
Release: Si tratta di milestone a medio-lungo termine (tipicamente della durata di diversi mesi).
Una Release coincide con il rilascio in produzione di una versione definitiva del software con
funzionalità complete concordate in fase di pianificazione.
Sprint: Si tratta di un ciclo time-boxed a breve termine (solitamente da 2 a 4 settimane) al termine
del quale sarà disponibile un incremento valutabile e potenzialmente utilizzabile del software. Ogni
Release è composta da tanti Sprint.
Inizialmente il Backlog stimato viene prioritizzato in accordo con il cliente. Durante la pianificazione di ogni
Sprint il Backlog restante (o parte di esso) può essere ri-stimato e ri-prioritizzato.
Il team alloca ad ogni Sprint i Backlog item di priorità più alta, fino a saturare la capacità produttiva del
team per quell’iterazione, in base alla stima di effort dei Backlog.
Durante lo Sprint si pianificano brevi incontri interni del team, detti anche Daily Scrum (circa 15-20 minuti
tutte le mattine), per condividere l’avanzamento dei lavori e per evidenziare criticità riscontrate.
Pagina 6 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
L’avanzamento dei Backlog item viene tracciato sugli strumenti di pianificazione in tutte le fasi di
lavorazione.
Pagina 7 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Risk Management Al fine di gestire preventivamente i rischi ed affrontare proattivamente le situazioni di criticità legate al
progetto, vengono sistematicamente applicate una serie di “Best Practices”:
Scouting and Spikes: questo approccio consiste nell’affrontare al più presto le incognite in modo da
prendere consapevolezza il prima possibile dell’entità del rischio, e valutare l’impatto e le possibili
azioni di mitigazione. Le incognite possono essere di natura tecnologica o legate alle conoscenze di
business / constraint di progetto. Nel primo caso di pianificano, nei primissimi Sprint, brevi attività
di prototipazione (Spikes) in cui si valutano le strade percorribili e si cerca di stabilire l’effort e
l’impatto dell’utilizzo delle nuove tecnologie, o di integrazione con altri sistemi. Nel secondo caso si
individuano le persone o le fonti in grado di fornire le risposte necessarie per analizzare, stimare,
pianificare, e realizzare le funzionalità del software.
Burndown Chart: si tratta di uno strumento di reportistica predittiva utilizzata in Scrum. Basandosi
sulla consapevolezza che la percentuale di progresso rispetto alle stime iniziali non è
necessariamente allineato con la pianificazione del rilascio, l’obiettivo di questo report non è quello
di comunicare il quanto è stato completato, ma di quanto manca al realmente termine.
Pagina 8 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Reflective Improvement: al termine di ogni Sprint il team organizza un meeting di “Project
Retrospective”, in cui si analizzano gli aspetti positivi e negativi riscontrati nell’iterazione. In questo
meeting si prendono decisioni su iniziative da intraprendere per aumentare la produttività del
team, migliorare la comunicazione interna ed esterna, ridurre o rivedere le procedure inefficienti o
costose, mitigare rischi emergenti.
Impediments Tracking: durante tutto il ciclo di sviluppo vengono tracciati gli impedimenti, interni o
esterni, che inficiano il lavoro del team. Gli impedimenti possono essere di natura organizzativa,
conoscitiva, tecnologica, o imprevisti. Ogni impedimento viene assegnato ad un membro del team
che ne deve seguire l’evoluzione con il commitment alla sua chiusura nel più breve tempo possibile.
Continuous Integration: uno dei rischi più frequenti nei progetti Software è rappresentato
dall’integrazione dei componenti realizzati dal team o da terze parti. Per evitare cicli costosi e
pericolosi di integrazione al termine degli sviluppi (in corrispondenza della consegna finale), si
configurano ambienti e strumenti che effettuano l’integrazione automatica delle componenti
software già dalle prime fase di sviluppo. Si tratta di server dedicati che in modo automatico e
schedulato raccolgono le ultime versioni dei sorgenti del software, compilano tutte le componenti
realizzate, e lanciano test automatici se disponibili.
Pagina 9 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Automated Testing: una delle principali cause di sforamento di budget e dei tempi di consegna di
un progetto software è la “regressione”. Si tratta dell’effetto dei bugs introdotti involontariamente
durante lo sviluppo e ad ogni modifica del codice esistente. Questo effetto si amplifica in modo
esponenziale quando i bug non vengono scoperti in tempo utile, e l’effort della risoluzione a volte
ha un impatto non recuperabile nei margini di sicurezza pianificati, comportando lo sforamento sui
tempi di consegna. Il “testing automatico” è una metodologia che permette di abbattere
drasticamente il tempo di debug e la probabilità che si manifestino regressioni sul codice esistente.
Pagina 10 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Performance Management Al fine di monitorare e migliorare le performance del team vengono misurati alcuni indicatori fondamentali:
Velocity: è la capacità produttiva media del team per Sprint. Si tratta della misura dell’effort
stimato dei Backlog item completati ad ogni Sprint. Questa misura (in genere espresso in man-days)
converge, dopo i primi sprint, ad un valore medio abbastanza stabile che permette di determinare
in ogni momento la stima al rilascio (in altre parole il tempo necessario per completare il Backlog
residuo). Su questo indicatore si basa il report di Burndown Chart.
Tempo medio di chiusura dei bug: i bugs sono gestiti come Backlog item ad alta priorità, dal
momento che il loro costo di risoluzione sale rapidamente nel tempo. E’ importante che i bug siano
risolti nel minor tempo possibile.
Tempo medio di chiusura degli “Impediment”: gli impedimenti possono comportare lo stallo delle
attività di progetto, bloccando le pipeline di sviluppo, oppure possono rendere necessari work-
around temporanei che introducono costi aggiuntivi al progetto. E’ altrettanto importante che gli
impedimenti vengano risolti il prima possibile.
Pagina 11 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Processi di “Software Development”
Le principali “Aree” costituenti il processo di “Software Development” sono le seguenti:
User Requirements Management
Architecture & Design
Coding & Testing
Quality Management
Bug Tracking and Fixing
Change Management
User Requirements Management I requisiti vengono raccolti utilizzando template e formalismi standardizzati come Use Cases e diagrammi
UML.
I requisiti formano il “Product Backlog” che verrà utilizzato per la pianificazione delle attività del team.
Pagina 12 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Il Backlog è gestito con appositi software di gestione e pianificazione di risorse per Scrum. Ogni Backlog
Item è tracciato, assegnato, e versionato nelle seguenti fasi di lavorazione: Registrazione, Realizzazione,
Completamento, Verifica.
I documenti di analisi sono tracciati con appositi strumenti di versioning.
Durante il ciclo di sviluppo il Backlog può essere modificato per introdurre nuovi item o rimuovere item
obsoleti, a condizione che non siano già in sviluppo. Può avvenire in questo modo lo “switch” di Backlog a
parità di effort stimato.
In alternativa è possibile aggiungere Backlog item che restano “out of scope” per la Release corrente, ma
che vengono comunque registrati per future sviluppi.
Il Product Backlog può anche espandersi o comprimersi di comune accordo, considerando le condizioni
commerciali e contrattuali, ed eventualmente concordando una variazione del budget e dei termini di
consegna.
Architecture & Design Mentre i requisiti costituiscono il dominio del problema, l’architettura e la progettazione definiscono il
dominio della soluzione.
In questa fase si definisce l’architettura software / hardware della soluzione, e si inquadra il sistema
nell’ecosistema dell’infrastruttura IT del cliente. La conoscenza approfondita delle piattaforme Microsoft e
della loro integrazione con infrastrutture e sistemi server permette la definizione di un’architettura
affidabile che preveda piani di backup, fail-over e disaster recovery dell’intera soluzione. Inoltre, anni di
esperienza in sistemi Enterprise permettono la definizione di architetture multi-layer che adoperano design
pattern consolidati nell’industria dello sviluppo software, in grado di garantire flessibilità di deployment e di
integrazione con sistemi esistenti.
L’architettura definisce una “mappa di navigazione” ad alto livello dei moduli del sistema e della loro
interazione con componenti interni ed esterni.
La progettazione del software deve rispondere ai vincoli funzionali e non funzionali espressi dai requisiti, e
deve consentire l’evoluzione e la modifica del sistema per far fronte a nuove o diverse esigenze di business.
Tale progettazione deve inoltre permettere la manutenzione del software con costi sostenibili e
l’innovazione tecnologica preservando gli investimenti nel tempo.
Ad oggi la risposta più efficace alla sfida della realizzazione e manutenzione dei sistemi complessi è
“Domain Driven Design”.
Domain Driven Design è una metodologia di progettazione “Object-Oriented” che prevede la realizzazione
di un modello ad oggetti che ricalchi nel modo più fedele possibile il “dominio” del business,
comprendendone entità e regole, e che permetta al team di sviluppo di utilizzare la stessa terminologia e
gli stessi concetti usati dagli esperti del dominio e dagli utenti finali. Questa corrispondenza riduce il livello
di “traduzione” tecnologica delle “esigenze” di business che spesso è causa di un disallineamento tra le reali
necessità degli utenti e le funzionalità disponibili nel software realizzato.
Pagina 13 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Coding & Testing Il Coding è l’attività che permette di realizzare il software implementando i modelli progettati con
l’approccio “Domain Driven Design”.
Lo sviluppatore in questa fase è tutt’altro che un mero esecutore. Egli, seguendo l’architettura del sistema,
prende decisioni sul dettaglio del design del software. Il design infatti non viene definito in modo
dettagliato prima di sviluppare il codice (approccio “Up-Front”), ma è una guida flessibile che aiuta lo
sviluppatore a restare conforme alle regole di business, e viene continuamente raffinato e modificato per
restare allineato con le stesse regole nel tempo.
In questo senso si parla dell’approccio “Emergent Design”, ovvero un design che prende forma man mano
che si realizzano funzionalità incrementali del sistema ed è malleabile nella misura di accomodare elementi
decisionali e di conoscenza che emergono nel corso del progetto.
Pagina 14 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Il Testing è un’attività integrante dello sviluppo del software. Non è una fase “a posteriori”, spesso vista
come una fase “opzionale” e sacrificabile in caso di sforamento sui tempi e sui costi. Il testing è proprio la
garanzia di mentenere i tempi di sviluppo lineari al crescere della base del codice, ed evitare la sintomatica
fase di debug “infinito” prima e dopo il rilascio del software.
Vengono eseguite le seguenti tipologie di testing, con obiettivi e risultati diversi, e per ognuna si cerca di
automatizzare l’esecuzione in modo da massimizzare l’efficacia dei controlli sui risultati:
Unit Test: E’ il test effettuato dallo sviluppatore durante la scrittura del codice, ed ha l’obiettivo di
verificare il corretto funzionamento delle singole unità del codice stesso (membri delle classi
object-oriented). Questo tipo di test è in assoluto quello più integrato nel processo di Coding e per
garantire il iglior risultato viene affrontato con la metodologia Test Driven Development (vedi il
paragrafo Quality Management).
Integration / System / Stress Test: E’ il test che verifica il corretto funzionamento di più
componenti di sistema, assemblati e configurati nel modo più allineato possibile all’ambiente di
produzione finale. Lo scopo di questo test è valutare la corretta collaborazione e passaggio di
informazioni tra i componenti, e di simulare situazioni di picco di carico di lavoro. Eventuali attività
di performance tuning utilizzano il risultato di questi test per definire una baseline e misurare
successivi miglioramenti.
User Acceptance Test: E’ il test effettuato dagli utenti pilota (o da tester con opportuna conoscenza
dei requisiti di business). Lo scopo di questo test è verificare l’aderenza del software realizzato con i
requisiti funzionali e non funzionali. Nei casi in cui siano stati concordati precedentemente i “Test
Case”, questi vengono eseguiti ed i risultati dei test vengono tracciati come misura oggettiva per la
convalida della correttezza del software realizzato.
Pagina 15 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Quality Management La qualità nello sviluppo del software si manifesta sotto molteplici aspetti:
Aderenza ai requisiti funzionali e non funzionali
Usabilità dell’interfaccia e costo di apprendimento per l’utente finale
Manutenibilità della base di codice in termini di costi e tempi
Configurabilità, Personalizzazioni e gestione del Versioning
Robustezza in termini di bug presenti nella versione rilasciata in produzione
Integrabilità con altri sistemi informativi
Sicurezza e protezione dei dati
Affidabilità in termini di capacità di recupero del sistema da disastri di varia natura
Al fine di tenere in considerazione gli aspetti citati, sono applicate le seguenti metodologie di lavoro e
procedure di controllo (oltre alle metodologie già citate negli altri processi di Project Management e
Software Development):
ISO 9126: la raccolta dei requisiti è orientata alla verificabilità della qualità del software in termini
di aderenza alle caratteristiche stabilite dagli standard ISO 9126.
Pagina 16 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Test Driven Development: si tratta di una tecnica che considera la scrittura dei test automatici di
correttezza come parte integrante delle attività di sviluppo del software. Questa pratica riduce
nettamente il bug rate del software rilasciato in produzione e lo rende meno vulnerabile agli effetti
di regressione durante il suo ciclo di vita.
Code Review / Peer Review: si tratta di una pratica di revisione tra “membri senior/junior” o
“membri alla pari” del team, che permette di valutare la bontà delle soluzioni applicate e di
evidenziare le criticità da indirizzare. Inoltre questa pratica aumenta la conoscenza trasversale del
lavoro svolto, permettendo una più proficua collaborazione in comune sulle varie parti del
software.
Pagina 17 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Code Coverage: è uno strumento che analizza la copertura del codice di produzione da parte dei
test automatici. In breve, in fase di esecuzione dei test automatici, viene profilata l’esecuzione delle
porzioni del codice del software stimolate dai test stessi. La quantità del codice stimolato viene
rapportato alla totalità della base del codice, ottenendo un rapporto di copertura in percentuale.
Maggiore è la percentuale della copertura, minore è il rischio che il codice celi bug “sfuggiti” ai test
automatici.
Pagina 18 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Metriche statiche: si tratta di un’analisi statica dei sorgenti che produce una serie di metriche in
grado di valutare rapidamente la qualità del codice e del design dello stesso. Alcuni indicatori più
importanti sono “La Complessità Ciclomatica”, “La Profondità delle Istruzioni”, “La Percentuale di
Documentazione”, “Il Numero Medio delle Righe di Codice per Metodo”.
Pagina 19 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Metriche Dinamiche: si tratta di un’analisi dinamica sui componenti compilati che rivela le
interdipendenze degli stessi e la criticità (e quindi il rischio) della modifica di ogni componente.
Alcuni indicatori fondamentali sono: “Numero delle Dipendenze Afferenti”, “Numero delle
Dipendenze Efferenti”, “Distanza dalla Sequenza Principale”.
Pagina 20 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Prototyping, Wireframes, Mock-ups: si tratta di tecniche di analisi e progettazione che proiettano
l’utente finale verso un possibile risultato finale, in tempi brevi e con un effort contenuto. In questo
modo l’utente può “visualizzare” l’aspetto finale del prodotto software e immedesimarsi
nell’interazione con esso. L’analista raccoglie il feedback sull’usabilità e sulla completezza delle
funzioni / informazioni presenti, e comunica al team di sviluppo un’idea chiara e condivisa del
risultato atteso da parte del cliente.
Technical Documentation: Durante lo sviluppo vengono prodotti una serie di artefatti versionati
come documentazione tecnica e condivisi internamente ed esternamente:
o Wireframes, Mock-ups
o Requirements Backlog
o Architecture Definition
o Design Documents
o Test Cases
o Bug Reports
o Code Coverage Reports and Software Metrics
Pagina 21 / 21
LightCode s.r.l. Sede Legale: Via Sardegna n. 21, 20146 Milano (MI) - Sede Operativa: Via Locatelli n. 1, 20900 Monza (MB)
P.IVA e C.F.: 05407600963 - Reg. Imprese di Milano n. 05407600963 - R.E.A. n. 1819503 - Capitale sociale € 10.000 i.v.
Sito: www.lightcode.net Email: [email protected]
Bug Tracking and Fixing I bug trovati durante lo sviluppo e le varie fasi di test sono registrati e prioritizzati come “Defect” nel
backlog delle attività.
Come tutti i Backlog anche i Defect sono versionati in tutti i cambiamenti di stato fino alla chiusura.
A differenza dei Backlog di requisiti pianificati ad ogni Sprint, i Defect possono entrare nello Sprint corrente
come attività ad alta priorità. Considerando che il costo della risoluzione dei bug cresce all’aumentare del
tempo di risoluzione, il team può decidere che i bug ad alta priorità devono essere chiusi immediatamente.
Ogni defect è (auto)assegnato ad uno sviluppatore, che ne è responsabile per tutti gli stati fino a quando è
pronto per la verifica.
La verifica può essere effettuata da un altro membro del team oppure da un test automatico che ne
certifica la correzione.
Change Management Le “Change Request” (CR) sono registrate nel Backlog. La gestione dal punto di vista di analisi,
progettazione e realizzazione è sostanzialmente è la stessa dei requisiti, la differenza è nella pianificazione.
In base alle condizioni contrattuali e ai vincoli di tempi e costi sul progetto, le CR possono essere gestite in
due modalità differenti:
Riprioritizzazione della Release Corrente: In questa modalità il budget e la scadenza di consegna della
Release non sono strettamente vincolati e sono gestiti in modo “collaborativo” con il cliente.
Il cliente ha la possibilità di includere le CR, quelle giudicate di valore, nella Release correnteaumentandone
lo scope. Il team proietta una revisione della scadenza del rilascio e del relativo budget.
Alternativamente il cliente ha la possibilità di “sostituire” le CR con requisiti già pianificati, non ancora
realizzati, di pari stima. I requisiti sostituiti restano nel Backlog per un’eventuale pianificazione in una
Release successiva.
Manutenzione Evolutiva in Release Successive: In questa modalità i requisiti pianificati per la Release, il
budget e la scadenza sono fissati.
Le CR registrate nel Backlog formeranno la base dei requisiti per le Release successive. Al termine della
Release corrente sarò definito lo scope della prossima Release sulla base dei requisiti (e delle CR) a maggior
priorita/valore nel Backlog.