LightCode. Processi e Tool di Sviluppo del Software v05.00

Transcript

1 LightCode Processi e Tool di Sviluppo del Software v05.00 Pagina 1 / 21

2 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 2 / 21

3 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: 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 3 / 21

4 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 % uptime requirements, Video game development, FDA-approved, life-critical systems, Satellite-control software, Websites, Handheld software, Mobile phones, Network switching applications, ISV applications. Pagina 4 / 21

5 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 minuti tutte le mattine), per condividere l avanzamento dei lavori e per evidenziare criticità riscontrate. Pagina 5 / 21

6 L avanzamento dei Backlog item viene tracciato sugli strumenti di pianificazione in tutte le fasi di lavorazione. Pagina 6 / 21

7 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 7 / 21

8 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 8 / 21

9 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 9 / 21

10 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 workaround temporanei che introducono costi aggiuntivi al progetto. E altrettanto importante che gli impedimenti vengano risolti il prima possibile. Pagina 10 / 21

11 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 11 / 21

12 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 12 / 21

13 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 13 / 21

14 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 14 / 21

15 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 Pagina 15 / 21

16 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 16 / 21

17 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 17 / 21

18 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 18 / 21

19 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 19 / 21

20 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 20 / 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. Pagina 21 / 21