Processi di sviluppo - modelli plan-based, metodi agili e Scrum

Definizione (processo software). Un processo software è un insieme strutturato di attività richieste per sviluppare un sistema software. Un modello di processo è una rappresentazione astratta di un processo, che ne descrive una parte da un punto di vista particolare.

Tutti i processi contengono le quattro attività fondamentali (Ingegneria del software - prodotto software e processo di sviluppoL'ingegneria del software (IdS) è la disciplina che copre tutti gli aspetti della produzione di software professionale, dalle prime specifiche alla manutenzione: il software sono programmi più documentazione, può essere generico (venduto sul mercato) o specifico (su misura per un cliente), e un buon prodotto ha quattro attributi (manutenibilità, affidabilità e sicurezza, efficienza, accettabilità); le attività fondamentali sono specifica, sviluppo, validazione ed evoluzione; i costi sono dominati dalla manutenzione e un difetto di requisiti scoperto dopo il rilascio costa fino a 100 volte uno scoperto subito; i tre problemi di fondo sono incertezza, irreversibilità e complessità; verifica ("costruiamo bene il prodotto?") e validazione ("costruiamo il prodotto giusto?") sono cose diverse.Ingegneria del software - prodotto software e processo di sviluppo →):

Una descrizione di processo elenca le attività (specificare un modello dei dati, costruire l'interfaccia) e il loro ordine, e può includere i prodotti (risultati delle attività), i ruoli (responsabilità delle persone) e le condizioni pre e post (che cosa è vero prima e dopo un'attività o un prodotto).

Processi plan-driven e processi agili

Nella pratica i due tipi non esistono isolati: la maggior parte dei processi ha elementi di entrambi, e non esiste un processo giusto o sbagliato, ma processi con priorità e vantaggi diversi. Tre "bestie" (incertezza, irreversibilità, complessità, vedi la nota di apertura) spiegano perché è difficile pianificare tutto in anticipo.

Modelli plan-based

Modello a cascata (waterfall)

Definizione. Un modello plan-driven con fasi separate e distinte, svolte in sequenza, ciascuna da completare prima di passare alla successiva.

Fasi: analisi e definizione dei requisiti $\to$ progetto del sistema e del software $\to$ realizzazione e unit test $\to$ integrazione e test di sistema $\to$ operazione e manutenzione.

• Problema principale: la difficoltà di accogliere i cambiamenti una volta iniziato il lavoro: il partizionamento è rigido e non si incorpora il feedback del cliente. È adatto solo se i requisiti sono ben capiti e i cambiamenti di progetto in corso d'opera saranno molto limitati.
• Si usa soprattutto in grandi progetti di ingegneria dei sistemi sviluppati in più sedi, e nei software critici per la sicurezza (safety critical): lì il difetto diventa un pregio, perché dà ai gruppi una mappa dello sviluppo affidabile e comune.

Modello a V

Il modello a V (V-model) è la cascata con i livelli di test associati: ogni fase di sviluppo a sinistra ha il livello di test corrispondente a destra, e i test si progettano insieme alla fase.

Tempo e definizione del progetto scendono a sinistra, test del progetto salgono a destra. Le frecce tratteggiate collegano ogni fase al suo test: un difetto dei requisiti emerge solo all'accettazione, per questo la validazione dei requisiti serve presto (il costo di un difetto cresce fino a 100 volte).

Sviluppo incrementale

Definizione. Specifica, sviluppo e validazione si sovrappongono: si sviluppa una versione iniziale, la si mostra al cliente e la si fa evolvere in incrementi che si costruiscono su quelli precedenti. Può essere plan-driven o agile.

• Vantaggi: il costo di accogliere i cambiamenti e la quantità di analisi e documentazione da rifare sono molto inferiori alla cascata; è più facile ottenere il feedback del cliente (che vede le dimostrazioni); consegna e messa in opera sono più rapide, e il cliente trae vantaggio dal software prima.
• Problemi: il processo non è visibile ai responsabili (non conviene produrre documenti per ogni versione, quindi mancano dati per misurare i progressi); la struttura tende a degradarsi a ogni incremento, a meno di fare refactoring a ogni modifica, e incorporare i cambiamenti diventa via via più difficile e costoso.

Integrazione e configurazione (riuso)

Il sistema è assemblato da componenti esistenti, integrati e configurati (COTS, commercial off-the-shelf): applicazioni standalone da configurare, pacchetti di oggetti per un framework a componenti (.NET, J2EE), servizi web remoti. Fasi: specifica dei requisiti, scoperta e valutazione dei componenti, raffinamento dei requisiti (adattandoli a ciò che esiste), configurazione dei sistemi, adattamento e integrazione dei componenti. Vantaggi: costi e rischi ridotti, consegna più veloce. Svantaggi: si scende a compromessi sui requisiti (il sistema può non soddisfare del tutto gli utenti) e si ha meno controllo sull'evoluzione dei componenti riusati. È l'approccio standard di molti sistemi gestionali.

Nella pratica i grandi sistemi usano un processo che include elementi di tutti questi modelli. Esempi: la cascata per il software critico, l'incrementale per la maggior parte dei prodotti commerciali, il riuso per i sistemi aziendali. Altri modelli plan-based noti: il modello a spirale (cicli ripetuti di pianificazione, analisi dei rischi, sviluppo, valutazione) e il Unified Process (processo iterativo guidato dai casi d'uso e dall'architettura, in fasi: ideazione, elaborazione, costruzione, transizione); sono citati qui per completezza, il corso non li approfondisce.

Gestire il cambiamento

Il cambiamento è inevitabile nei grandi progetti: cambia il business, nascono tecnologie, cambiano le piattaforme. I costi del cambiamento sono la rianalisi del lavoro fatto e l'implementazione della nuova funzione. Per ridurre il costo del rifacimento:

Prototipazione

Un prototipo è una versione iniziale del sistema per dimostrare concetti e provare opzioni di progetto. Si usa per i requisiti (raccolta e validazione), per il progetto (esplorare opzioni, per esempio l'interfaccia) e per il test. Benefici: usabilità migliore, aderenza ai bisogni degli utenti, progetto migliore, manutenibilità migliore, minore sforzo di sviluppo. Si basa su strumenti e linguaggi rapidi, può tralasciare funzioni, controllo degli errori e requisiti non funzionali (affidabilità, sicurezza), e si concentra sulle aree non ben capite. I prototipi vanno gettati (throw-away): non sono una buona base per un sistema di produzione perché è spesso impossibile accomodare i requisiti non funzionali, mancano di documentazione e la struttura è degradata dai cambiamenti rapidi.

Consegna incrementale

Il sistema non si consegna in una volta: sviluppo e consegna sono scomposti in incrementi, ciascuno con una parte delle funzioni; le priorità più alte sono nei primi incrementi; quando inizia lo sviluppo di un incremento i suoi requisiti si congelano, mentre quelli dei successivi possono evolvere.

Vantaggi: valore al cliente a ogni incremento; i primi incrementi fanno da prototipo; minore rischio di fallimento totale; le funzioni a più alta priorità sono più provate. Problemi: la maggior parte dei sistemi richiede risorse di base comuni a più parti, non garantibili con incrementi; i requisiti non sono definiti in dettaglio finché l'incremento non è realizzato, e questo va contro i contratti che includono la specifica completa.

Miglioramento del processo

Si capiscono i processi esistenti e li si cambia per migliorare la qualità del prodotto e ridurre costi e tempi. Due approcci: maturità del processo (migliorare processo e gestione del progetto, introducendo buone pratiche) e approccio agile (sviluppo iterativo, meno overhead, consegna rapida di funzionalità). Il ciclo di miglioramento:

1. misura di uno o più attributi del processo o del prodotto (tempo di calendario di un'attività, sforzo in giorni di lavoro, numero di difetti scoperti): forma una baseline per valutare i miglioramenti; è possibile solo se il processo è definito;
2. analisi: si individuano debolezze e colli di bottiglia (anche con mappe del processo);
3. cambiamento: si introducono i cambiamenti e il ciclo ricomincia. Le misure servono a valutare i miglioramenti, ma devono guidarli gli obiettivi.

Livelli di maturità (SEI)

Metodi agili

Manifesto

I metodi agili nascono dal bisogno di rispondere al cambiamento. Principi del manifesto agile:

• priorità massima: soddisfare il cliente con la consegna rapida e continua di software di valore;
• accogliere requisiti che cambiano, anche a sviluppo avanzato: i processi agili sfruttano il cambiamento a vantaggio del cliente;
• persone del business e sviluppatori lavorano insieme ogni giorno;
• consegnare software funzionante frequentemente, da un paio di settimane a un paio di mesi (meglio la scala più corta);
• progetti attorno a individui motivati: dare ambiente e supporto e fidarsi;
• il metodo più efficace per comunicare è la conversazione faccia a faccia;
• software funzionante è la misura principale del progresso;
• sviluppo sostenibile: ritmo costante e indefinito;
• attenzione continua all'eccellenza tecnica e al buon progetto;
• semplicità, l'arte di massimizzare il lavoro non fatto;
• le migliori architetture e requisiti emergono da gruppi che si auto-organizzano;
• a intervalli regolari il gruppo riflette su come migliorare e adegua il proprio comportamento.

Metodi: Extreme Programming (XP), DSDM, Scrum, Feature Driven Development, Crystal, Agile Modeling, Lean Software Development. Non sono cowboy coding: XP e gli altri sono difficili da fare e da gestire, perché richiedono disciplina (test, integrazione, comunicazione).

Parole d'ordine: test first, integrazione continua, programmazione a coppie, proprietà collettiva del codice, coinvolgimento quotidiano del cliente. Un modo di dire cosa sono: un modo diverso di organizzare lo sviluppo, centrato sulla massimizzazione di un flusso costante di valore per il cliente, che usa meccanismi di coordinamento delle uscite e vincoli endogeni.

Extreme Programming (XP)

Valori: semplicità, comunicazione, feedback, coraggio. Spinte: concentrarsi sul valore, flusso costante di attività, nessun difetto.

Dodici pratiche: gioco della pianificazione (planning game), rilasci brevi (small releases), metafora, progetto semplice, sviluppo guidato dai test (Software testing - progettazione dei casi di test e JUnitIl testing esegue il programma con dati artificiali per mostrare che soddisfa i requisiti (validation testing) e per scoprirne i difetti (defect testing), ma può rivelare la presenza di errori e non la loro assenza; il test di sviluppo comprende unit test (singole classi e metodi), test dei componenti (le interfacce) e test di sistema (le interazioni); i casi di test si ricavano con le classi di equivalenza (una per partizione) e i valori limite (ai bordi delle partizioni), più linee guida per sequenze e input anomali; JUnit automatizza i test con @Test, fixture @Before/@After (@BeforeClass/@AfterClass), le asserzioni (assertEquals con atteso per primo), eccezioni attese, timeout e @Ignore; nel TDD il test si scrive prima del codice (red, green, refactor) e i test automatici diventano la suite di regressione; seguono i test di rilascio (black box sui requisiti, prestazioni) e dell'utente (alpha, beta, accettazione).Software testing - progettazione dei casi di test e JUnit →), refactoring, programmazione a coppie, proprietà collettiva del codice, integrazione continua, settimana di 40 ore (sustainable pace), cliente sul posto (on-site customer), standard di codifica.

Ruoli:

Storie dell'utente (user stories): descrivono le funzioni con brevi storie (simili ai casi d'uso UML), una per scheda. Ogni storia: comprensibile a cliente e sviluppatori, in linguaggio naturale, testabile (il test lo scrive il cliente), indipendente dalle altre quanto possibile, di non più di due settimane di lavoro (altrimenti si spezza). Una scheda ha: titolo (1-3 parole), priorità (importanza per il cliente), story point (stima dello sviluppatore), test di accettazione, descrizione.

Esempio (biblioteca). Titolo: Prenotare un documento. Priorità: 2. Story point: 3. Test di accettazione: TestPrenotazione. Descrizione: un iscritto con tessera valida può prenotare un documento in prestito; quando una copia torna disponibile riceve un avviso e ha 48 ore per ritirarla; se non la ritira la prenotazione passa al successivo.

Stima: inizialmente su esperienza e intuizione, poi raffinata; per storie grandi o incerte si fa uno spike solution (esperimento di al massimo un giorno). Lo story point è l'unità, collegata a una quantità di sforzo (per esempio una giornata di una coppia); se la storia richiede più di due settimane il cliente la scompone. Test di accettazione: scritti dal cliente dopo ogni storia, almeno uno per storia; solo dopo averli superati tutti si inizia una nuova storia.

Equilibrio dei poteri: il cliente decide che cosa fare e in quale ordine (gli sviluppatori danno il parere, la parola finale è del cliente); gli sviluppatori decidono quanto lavoro serve (il cliente dà il parere, la parola finale è degli sviluppatori). Funziona solo in un clima di fiducia reciproca. La metafora è un modo convenzionale, condiviso da sviluppatori, cliente e manager, di guardare al sistema: una lingua franca.

Tradizionale, cowboy e XP a confronto

Controllo endogeno ed esogeno

Controllo nel processo contro controllo del processo; endogeno (incorporato nella struttura, per esempio una sbarra a 2,05 m che ferma i veicoli troppo alti, un sensore a infrarossi che accende la luce solo se c'è qualcuno) contro esogeno (aggiunto dall'esterno: un cartello che avvisa "veicoli oltre 2 m non possono passare", una regola scritta). Il controllo endogeno è molto più efficace, ma può essere difficile da ottenere: i metodi agili cercano un processo adattivo con il controllo incorporato (come nell'integrazione continua, che esegue i test a ogni modifica, e nel cliente sul posto) invece che aggiunto (un piano e regole scritte). È uno dei principi del lean management (controllo visivo e altro).

Scrum

Definizione. Scrum è un framework agile che organizza il lavoro in iterazioni brevi a durata fissa (gli sprint) con ruoli, eventi e artefatti precisi. Il nome viene dalla mischia del rugby: tutta la squadra spinge insieme verso lo stesso obiettivo.

Valori: coraggio (fare la cosa giusta e affrontare i problemi difficili), concentrazione (focus: sul lavoro dello sprint e sugli obiettivi del team), impegno (commitment: ciascuno si impegna personalmente per gli obiettivi), rispetto (tra persone capaci e indipendenti), apertura (openness: il team e gli stakeholder sono trasparenti su lavoro e sfide).

Ruoli

Il ciclo (modello Scrum)

1. Il Product Backlog (elenco ordinato di tutto ciò che si vuole nel prodotto: storie, difetti, miglioramenti) alimenta lo sprint.
2. Sprint planning (riunione di pianificazione): il team sceglie quali voci del product backlog realizzare nello sprint e le scompone in compiti: nasce lo Sprint Backlog.
3. Sprint: durata fissa (di solito da una a quattro settimane); il team lavora con il daily scrum: riunione brevissima in piedi (circa 15 minuti, "stand-up not sit-down"), in cui ognuno dice cosa ha fatto, cosa farà e che ostacoli ha.
4. Sprint review: alla fine si mostra l'incremento (funzioni complete, potenzialmente rilasciabili) agli stakeholder e si raccoglie il feedback, che aggiorna il product backlog.
5. Sprint retrospective: il team riflette sul processo (che cosa è andato bene, che cosa migliorare) e decide miglioramenti per lo sprint seguente.

Pratiche (dalle slide)

• Task board (task board): la lavagna con colonne (da fare, in corso, fatto) e foglietti: il progresso è visibile a tutti.
• Retrospective: gruppo che discute apertamente di ciò che non va (e lo corregge).
• Planning poker: stima di gruppo delle storie: ogni membro sceglie in segreto una carta con la sequenza (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, "?", "pausa caffè") e si scoprono insieme (c'è sempre qualcuno che mostra la carta troppo presto); se i numeri differiscono molto chi ha dato il valore più alto e più basso spiega le sue ragioni e si rivota. La scala non lineare riflette l'incertezza delle stime grandi. Più giocatori danno più punti di vista.
• Metriche: si usano per migliorare, non per controllare le persone.
• Daily scrum: riunione in piedi, breve.

Velocità e pianificazione. La velocità è la somma degli story point completati in uno sprint; la media degli sprint passati serve a prevedere quanto si potrà prendere nel prossimo, senza promesse non fondate. Esempio: in tre sprint il team ha completato 18, 22 e 20 punti, quindi la velocità media è 20; il product backlog ha storie da 5, 8, 3, 13, 5, 2 punti (totale 36); nel prossimo sprint si scelgono le più prioritarie per un massimo di circa 20 punti (per esempio 8 + 5 + 3 + 2 = 18), e il resto va agli sprint successivi (circa due sprint in totale).

Scrum e XP

Scrum e XP sono complementari. Scrum copre l'organizzazione (product backlog, sprint backlog, daily scrum, sprint planning, retrospective, review, burndown chart, ruoli di PO e Scrum Master); XP copre le pratiche tecniche (TDD, programmazione a coppie, refactoring, standard di codifica, integrazione continua, progetto semplice, metafora, rilasci piccoli, proprietà collettiva); alcune pratiche sono in comune (team, cliente sul posto, planning game simile allo sprint planning, test del cliente). Molti gruppi usano Scrum per organizzare il lavoro e le pratiche di XP per realizzarlo.

Come scegliere il processo

Una scelta pratica per un progetto d'esame (gruppo piccolo, requisiti dati, tempo breve): iterativo con consegne piccole, TDD per le parti con logica, requisiti scritti brevemente ma con identificatori per poter collegare i test ai requisiti, e retrospettiva a ogni iterazione.

Domande d'esame

1. Confrontare cascata e sviluppo incrementale: vantaggi, svantaggi e quando si usa ciascuno. Traccia. Cascata: fasi distinte in sequenza, ottimo coordinamento e mappa chiara per sistemi grandi o critici con requisiti stabili; il cambiamento è difficile e costoso e il feedback arriva tardi. Incrementale: specifica, sviluppo e validazione si sovrappongono, il cambiamento costa meno e il cliente vede e usa presto; ma il processo è poco visibile e la struttura si degrada senza refactoring.

2. Quali sono ruoli, eventi e artefatti di Scrum? Come si usa il planning poker? Traccia. Ruoli: Product Owner, Scrum Master, team. Eventi: sprint planning, daily scrum, sprint review, retrospective. Artefatti: product backlog, sprint backlog, incremento (burndown). Planning poker: ognuno sceglie in segreto una carta (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100), si scoprono insieme, chi è agli estremi spiega e si rivota fino alla convergenza.

3. Confrontare l'approccio tradizionale e XP su documentazione, integrazione e proprietà del codice. Che cosa significa controllo endogeno? Traccia. Tradizionale: documentazione completa, integrazione alla fine, codice individuale. XP: codice comprensibile e solo la documentazione necessaria, integrazione almeno giornaliera, codice di proprietà collettiva con test verdi. Endogeno: il controllo è parte della struttura del processo (integrazione continua, cliente sul posto), a differenza dell'esogeno aggiunto dall'esterno (regole scritte, piani).