Il modello RAD 1. Rapid Application Development punta a un ciclo di sviluppo molto breve

Transcript

1 Il modello RAD 1 Rapid Application Development punta a un ciclo di sviluppo molto breve adattamento del modello a cascata in cui l obiettivo di uno sviluppo rapido è raggiunto grazie a strategie costruttive fondate sull uso di componenti Se i requisiti sono precisi possono bastare giorni

2 Il modello RAD 2 Team # n M o d e lin g business m odeling data m odeling process m odeling Communicat ion Team # 2 Mo d eling bu siness m odel ing da t a m o deling process m odeling Co n st ru ct io n com ponent reuse automatic code generation testing Planning Team # 1 Mode ling business modeling dat a modeling process modeling Co nst ruct io n com ponen t reuse aut omat ic code g enerat ion t est ing De ployme nt int egrat ion deliv ery feedback Const ruct ion component reuse aut omat ic code generat ion t est ing days

3 Il modello RAD 3 Svantaggi: Se non ci si accorda sulla rapidità necessaria per completare il sistema, i progetti RAD non riescono Se un sistema non può essere modularizzato correttamente, la costruzione dei componenti sarà problematica

4 Modelli a processo evolutivo I requisiti spesso cambiano durante lo sviluppo Le scadenze rigide rendono impossibile il completamento di un prodotto software di dimensioni non banali A volte i dettagli delle sessioni del prodotto o del sistema devono ancora essere definiti In queste situazioni gli ingegneri software devono utilizzare un modello di processo realizzato per considerare un prodotto che evolve nel tempo

5 I prototipi Quando non si è sicuri dei requisiti e/o degli strumenti....l approccio migliore può essere la costruzione di un prototipo

6 I prototipi 2 Communicat ion Qu ick p lan Mo d e lin g Qu ick d e sig n Deployment De live ry & Fe e dback Const ruct ion of prot ot ype

7 I prototipi 3 Teoricamente il prototipo serve da meccanismo per individuare i requisiti software. Cosa deve essere fatto dei prototipi? Spesso devono essere buttati via

8 I prototipi 4 Problemi 1. Il cliente crede di avere una versione funzionante del sistema (spesso si opporrà alla sua eliminazione 2. Si può cedere alla tentazione di raffinare il prototipo (il che può portare a software non di qualità) Soluzione Bisogna accordarsi prima

9 Il modello a spirale 1 Abbina la natura iterativa della prototipazione agli aspetti controllati e sistematici del modello a cascata Generatore di modelli di processo controllati dal rischio Approccio ciclico: cresce incrementalmente il grado di definizione e implementazione del sistema riducendo i rischi Fornisce risultati e prodotti intermedi per garantire che le soluzioni del sistema siano fattibili ed efficienti

10 Il modello a spirale 2 communication planning estimation scheduling risk analysis start modeling analysis design deployment delivery feedback construction code test

11 Il modello a spirale 3 Problemi Budget fisso Alte competenze per tenere a bada il rischio

12 Modelli di processo personali e in team Il miglior processo di sviluppo software è quello più adatto alle persone che svolgeranno il lavoro Se un modello del processo di sviluppo software è stato sviluppato a livello aziendale o di organizzazione, può essere efficace solo se può essere adattato ai bisogni del team che sta effettuando il lavoro Ogni ingegnere software dovrebbe creare un processo il più possibile adatto alle proprie esigenze e contemporaneamente rispondere ai bisogni generali del team e dell organizzazione Parliamo di Processo di sviluppo software personale e di Processo di sviluppo software di team

13 Personal Software Process 1 Humphrey (1997) Pone l accento su una valutazione personale del prodotto realizzato e della sua qualità Rende il soggetto responsabile della pianificazione del progetto (per esempio stima e programmazione) Lo incarica di controllare la qualità di tutti i prodotti software che vengono sviluppati

14 Personal Software Process 2 Pianificazione Progettazione ad alto livello Revisione del progetto ad alto livello Sviluppo Post-mortem

15 Team Software Process 1 Humphrey estende le nozioni apprese con PSP proponendo un processo di sviluppo di team Realizzare team auto-diretti che pianificano e monitorizzano il proprio lavoro, stabiliscono obiettivi e hanno i propri processi e piani Spiegare ai manager come formare e motivare i propri team e come aiutarli a sostenere le prestazioni di picco Accelerare il miglioramento del processo di sviluppo software adottando il livello 5 di CMM Fornire assistenza al miglioramento per le organizzazioni a elevata maturità Facilitare l addestramento universitario di capacità tecniche di team a livello industriale

16 Team Software Process 2 Migliora la qualità e la produttività dei team di ingegneria e li aiuta a soddisfare i vincoli di costo e di programma Team da 2 a 20 membri Multi-team più grandi di circa 150 membri

17 Team Software Process 3 Teradyne: prima di TSP i livelli di difetto nei test di integrazione, nei test di sistema, nel testing e uso del cliente erano circa 20 difetti per KLOC. Dopo, solo 1 per KLOC Poiché localizzare e rimuovere il difetto richiedeva a Teradyne 12 ore, sono state risparmiate 228 ore per ogni KLOC di programma sviluppato

18 Team Software Process 4 Il primo progetto TSP presso la Hill Air Force Base ha determinato una produttività del team migliorata del 123% e il tempo dei test ridotto dal 22% al 2.7% del programma del progetto

19 Ingegnerizzazione del lavoro di team I team sono richiesti per molti progetti software Sebbene piccoli prodotti possono essere sviluppati da programmatori singoli la dimensione e complessità dei sistemi moderni è tale, e la richiesta di tempi di consegna brevi tanta, che non è pratico per una persona sola fare tutto il lavoro

20 Vari tipi di team Pallacanestro Pallavolo Wrestling

21 Condizioni per il lavoro in team Un team è un gruppo di persone che condivide un goal comune ed ha un contesto lavorativo comune Almeno due persone I membri lavorano verso un goal comune Ogni persona ha un ruolo assegnato Il completamento della missione richiede una qualche forma di dipendenza fra i membri del gruppo

22 Team efficienti I membri hanno i giusti skill Il goal del team è importante, definito, visibile, e realistico I membri sono motivati e impegnati nel raggiungimento del goal del team I membri cooperano e si supportano vicendevolmente I membri sono disciplinati nel loro lavoro

23 Costruire Team efficienti I membri del team stabiliscono goal comuni e ruoli definiti Il team sviluppa una strategia all unanimità I membri del team definiscono un processo comune per il loro lavoro Tutti i membri del team partecipano nel produrre il piano, e ogni membro sa il suo ruolo personale in quel piano Il team negozia il piano con la gestione La gestione revisiona e accetta il piano negoziato I membri del team fanno il lavoro nel modo in cui lo avevano pianificato I membri del team comunicano spesso e liberamente Il team forma un gruppo coeso: i membri cooperano, e sono tutti impegnati nel raggiungere l obiettivo Gli ingegneri ottengono feedback sul loro lavoro e la leadership sostiene la loro motivazione

24 Processo TSP Prima che i membri possano partecipare al team vengono allenati nel PSP: Pianificazione personale Metodi di pianificazione Valore guadagnato Dati del processo Misure di qualità Processi

25 Processo TSP Il lavoro di costruzione del team è un processo di pianificazione di 4 giorni che viene detto lancio del team Poiché il processo TSP segue una strategia di sviluppo iterativa ed evolvente, sono necessari rilanci periodici cosicchè ogni fase o ciclo può essere programmata in base alla conoscenza acquisita nella fase precedente

26 Processo TSP Assicurarsi che tutti i membri del team seguono il piano Condurre il team Disciplina nel processo Seguire la riuscita Comunicazione Report di gestione Mantenere il piano Dare una stima sul completamento del progetto Riequilibrare il carico di lavoro nel team Rilanciare il progetto Gestione della qualità TSP

27 Condurre il team Il leader è responsabile di guidare e motivare il team E di mantenere la disciplina al progetto Non cedere alla tentazione di smettere di seguire il proprio piano a causa della pressione dovuta a un pesante scheduling

28 Comunicazione I membri del team devono conoscere lo stato del progetto Settimanalmente ogni membro del team fa un report sul suo lavoro, sullo stato dei rischi Tenere la gestione informati sullo stato e progresso del team

29 Mantenere il piano Il piano guida il lavoro permettendo di misurare il progresso Valore Guadagnato: ad ogni task viene assegnato un valore basato sulla percentuale del bilancio totale del progetto richiesto per quel task. Progetto 1000 ore, un task di 32 ore ha un valore guadagnato 3.2 (100 * 32/1000 = 3.2%)

30 Mantenere il piano Task hours Task hours to date Earned value Earned value to date

31 Gestione di qualità TSP Durante il lancio del team viene fatto un piano qualità Basato sulla dimensione stimata del prodotto e dati storici sull ammontare dell inserimento e della rimozione dei difetti Viene generato il piano qualità Il team esamina il piano qualità per vedere se i parametri di qualità sono ragionevoli e se soddisfano gli obiettivi di qualità del team