Light ode Processi e Tool di Sviluppo rev 5.pdf · Una delle più diffuse metodologie agili è...

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




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




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à.

http://www.agilemanifesto.org/

Pagina 4 / 21




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




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




L’avanzamento dei Backlog item viene tracciato sugli strumenti di pianificazione in tutte le fasi di

lavorazione.

Pagina 7 / 21




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




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




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




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




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




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




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




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




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




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




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




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




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




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




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.

Light ode Processi e Tool di Sviluppo rev 5.pdf · Una delle più diffuse metodologie agili è...

Documents

Transcript of Light ode Processi e Tool di Sviluppo rev 5.pdf · Una delle più diffuse metodologie agili è...