Corso di Ingegneria del Software. Modelli di produzione del software

Transcript

1 Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca

2 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali 2.3 Modelli evolutivi 2.4 Comparazione dei modelli Bibliografia

3 Le assunzioni I requisiti del cliente evolvono continuamente durante un progetto e quindi il processo da seguire non è completamente prevedibile e non può essere completamente predefinito. I fondamenti È inutile svolgere una onerosa attività di analisi e progettazione prima della codifica, in quanto gran parte di questo lavoro sarebbe sprecato. Meglio mantenere una documentazione essenziale, ovvero lo stesso codice, scritto in modo standard. È più facile e rapido modificare il codice quando il cliente lo chiede (ovvero spesso!).

4 I fondamenti Le metodologie Agili sono centrate sulla facilità di modificare il software. Agile Alliance Attorno ai principi delle metodologie AGILI è nata un alleanza di sviluppatori (Agile Alliance), che ha pubblicato un manifesto.

5 Il manifesto per lo sviluppo agile

6 - I Principi sottostanti al Manifesto Agile 1. La nostra massima priorità è soddisfare il cliente per mezzo di tempestivi e continui rilasci di software di valore. 2. Siano benvenuti i cambiamenti nelle specifiche, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente. 3. Rilascia software funzionante frequentemente, da un paio di settimane a un paio di mesi, con preferenza per i periodi brevi. 4. Manager e sviluppatori devono lavorare insieme quotidianamente lungo il progetto. 5. Basa i progetti su individui motivati. Dai loro l ambiente e il supporto di cui necessitano e confida nella loro capacità di portare il lavoro a termine. 6. Il metodo più efficiente ed efficace di trasmettere informazione verso e all interno di un team di sviluppo è la conversazione faccia a faccia. 7. Il software funzionante è la misura primaria di progresso. 8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante indefinitamente. 9. L attenzione continua per l eccellenza tecnica e il buon design esaltano l agilità. 10. La semplicità - l arte di massimizzare l ammontare di lavoro non svolto - è essenziale. 11. Le migliori architetture, specifiche e design emergono da team auto-organizzati. 12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché mette a punto e aggiusta il suo comportamento di conseguenza.

7 Caratteristiche dello sviluppo Agile Adattabilità alle modifiche Il software va progettato per consentirne la facile modificabilità durante il corso del progetto (ma anche dopo il rilascio in uso al cliente). Iteratività, incrementalità e semplicità Le fasi di pianificazione, codifica e test sono compresse in tempi molto più ridotti rispetto a quelli previsti nelle metodologie tradizionali. Ci si deve concentrare su pochi problemi alla volta, di limitate dimensioni e ben definiti. Rilasci frequenti I team devono sviluppare versioni dei semilavorati in tempi ridotti. Testing Il test va svolto continuamente, durante tutte le fasi del progetto e su tutti i semilavorati prodotti. Documentazione Conversazione faccia a faccia Team di lavoro Auto-organizzazione

8 Lesson learnt dai metodi agili il pair programming Migliora la comunicazione nel team e porta ad un elevato numero di ispezioni del software. il focus sulla produzione di programmi I metodi agili hanno inoltre riportato l attenzione sul codice, piuttosto che sulla documentazione accessoria, che spesso assorbe gran parte del tempo degli sviluppatori. la partecipazione attiva del committente e dell utente Clima meno formale e più collaborativo Più proficuo di un atteggiamento burocratico che vede il cliente solamente in funzione di un contratto. La partecipazione degli utenti finali contribuisce a rendere il software più efficace, in quanto la costruzione viene fatta attorno a chi userà il software. E. Capra Sviluppo del software: metodi agili o metodi tradizionali?

9 Criticità dei metodi agili - 1/2 La minimizzazione della documentazione (non standardizzata) (la conoscenza del prodotto è degli sviluppatori) problemi di comprensione dell organizzazione del sistema quando il progetto è di grande dimensioni (la comunicazione interna con più di 20 persone diventa difficile) difficoltà nel caso di rotazione e cambiamenti delle risorse del team la realizzazione delle interfacce è rallentata dall assenza di documentazione standard e condivisa. L attenzione posta al ruolo delle persone stimola la creatività e la produttività personale ma rende particolarmente critiche la qualità e le skill dei programmatori. E. Capra Sviluppo del software: metodi agili o metodi tradizionali?

10 Criticità dei metodi agili - 2/2 La definizione delle specifiche attraverso i test I test descrivono un campione finito di possibili comportamenti, lasciando indefiniti aspetti e comportamenti che potrebbero presentarsi. I metodi agili si rivelano poco efficaci nello sviluppo di applicazioni safetycritical, che richiedono una certificazione del prodotto. La validazione dei requisiti solamente attraverso l esecuzione di versioni parziali dell applicazione rischia inoltre di degenerare in processi di code&fix senza fine, rendendo critica l evoluzione del prodotto. La semplificazione volta a snellire il processo, riduce la possibilità di esplorare soluzioni alternative. E. Capra Sviluppo del software: metodi agili o metodi tradizionali?

11 extreme Programming (XP) - I fondamenti Il metodo dell extreme Programming è stato proposto da Kent Beck nel I fondamenti del metodo XP: evitare la produzione di semilavorati non strettamente necessari alla realizzazione dell applicazione Gli sviluppatori sono invitati a concentrarsi sul codice, la produzione di documentazione di supporto è considerata come una perdita di tempo. non è possibile analizzare e pianificre la produzione di un applicazione a priori La produzione di un applicazione è paragonata da Beck alla guida di un automobile: la condotta complessiva è il risultato di un gran numero di minimi cambiamenti di rotta che il pilota decide in base alla sua istantanea percezione di curve e ostacoli. il processo è il risultato di un gran numero di cambiamenti da decidere di volta in volta

12 extreme Programming (XP) - Perchè estrema? L XP porta i principi e le pratiche derivate dal buon senso a livello estremo. (Beck -, pag. 10) Pratiche corrette: extreme Programming (XP) - Perchè estrema? revisione del codice test del codice progettazione semplicità architettura verifiche di integrazione iterazioni brevi

13 extreme Programming (XP) - Perchè estrema? Pratiche estremizzate: programmazione a coppie (revisione del codice) test unitari e test funzionali (test del codice) refactoring (progettazione) semplicità metafora (architettura) integrazione continua (verifiche di integrazione) Planning Game (iterazioni brevi)

14 extreme Programming (XP) - Attività fondamentali Il lavoro del team di sviluppo è organizzato in quattro attività fondamentali (reiterate durante il progetto dopo i feedback dei committenti): listening osservazione dell ambiente (desideri e bisogni del committente + opportunità tecnologiche e del mercato) design progetto e integrazione dell applicazione coding scrittura del codice dell applicazione testing verifica delle funzionalità

15 extreme Programming (XP) - Planning Game Obiettivo del Planning Game: permettere a clienti, manager e sviluppatori di confrontarsi attorno alle date e ai contenuti dei rilasci di software, usando come metrica di confronto 5 variabili: Portata del progetto (funzionalità da realizzare) Qualità attesa Priorità Composizione dei rilasci parziali. Tempo (date dei rilasci). Costo del progetto.

16 extreme Programming (XP) - Planning Game Le variabili definite da clienti e manager sono: Portata del progetto (funzionalità da realizzare) Qualità attesa Priorità ñ Composizione dei rilasci parziali. Tempo (date dei rilasci).

17 extreme Programming (XP) - Planning Game Le variabili definite dagli sviluppatori sono: Tempo necessario a sviluppare una funzionalità. Costo di realizzazione delle funzioni.

18 extreme Programming (XP) - Planning Game Nella fase di pianificazione clienti/managers e sviluppatori contrattano sui valori da assegnare alle variabili (e.g. se i primi definiscono i tempi, gli sviluppatori scelgono quali storie realizzare per quella data e il loro costo. (GAME)

19 extreme Programming (XP) - Planning Game LA STRATEGIA Investire il meno possibile per mettere in produzione il più presto possibile le funzionalità più importanti, riducendo il rischio. I COMPONENTI I componenti del Planning Game sono le schede contenenti le storie di funzionamento del sistema. I GIOCATORI sviluppatori (responsabili della implementazione) e management (persone che decidono cosa deve fare il sistema). LE FASI E LE MOSSE Esplorazione: scoprire cosa il sistema potrebbe fare. Impegno: decidere quale sottoinsieme di tutti i possibili requisiti realizzare nella fase successiva. Gestione: dirigere lo sviluppo in base a come la realtà influenza il piano. Le mosse di ciascuna fase avvengono di solito nella fase stessa.

20 extreme Programming (XP) - Planning Game Il Planning Game prevede 3 fasi, da eseguire in sequenza, e da iterare più volte. Esplorazione: scoprire le cose che il sistema software potrebbe fare per il cliente. Impegno: definire quali impegni prendere nel breve periodo, ovvero quali funzioni realizzare nel prossimo intervallo di tempo (pianificare i rilasci). Gestione: gestire in corso díopera le attività realizzative in funzione della realtà operativa del progetto (ritardi disponibilità risorse variazione requisiti etc ) (aggiornamento del piano di lavoro)

21 extreme Programming (XP) - Planning Game Le mosse della fase di esplorazione: 1. Scrittura di una storia il management scrive una storia che descrive una funzionalità del sistema. 2. Stima della durata di una storia gli sviluppatori stimano il tempo necessario per implementare la storia. 3. Suddivisione di una storia

22 extreme Programming (XP) - User story Le user stories rappresentano in modo discorsivo le caratteristiche e le funzioni che gli utenti si aspettano dal software. Le user stories vengono scritte su delle schede di limitate dimensioni (per limitarne la lunghezza). Il cliente assegna ad ogni storia un valore (che dipende dalĺıimportanza della user story per il suo business).

23 extreme Programming (XP) - User story

24 extreme Programming (XP) - User story Le User Story sono scenari di funzionamento del sistema software da realizzare, descritti in modo sintetico e discorsivo (eventualmente con use case UML) che devono: avere un valore economico per il cliente, essere comprensibili per il programmatore, essere stimabili come tempo di realizzazione/costo, essere semplici

25 extreme Programming (XP) - Planning Game Le mosse della fase di impegno: 1. Ordinamento per importanza (a cura del mnagement) storie indispensabili, storie importanti (economicamente), storie comode, accessorie 2. Ordinamento per rischio (a cura degli sviluppatori) stimabili con precisione, con ragionevole sicurezza, non stimabili 3. Stabilire la velocità (a cura degli sviluppatori) 4. Scelta delle funzionalità (a cura del management) scelta delle storie da implementare per il prossimo rilascio.

26 extreme Programming (XP) - Planning Game Le mosse della fase di gestione: 1. Iterazione (a cura del management) scelta delle storie da implementare nell iterazione. L implemetazione è un sistema funzionante. 2. Recupero (a cura del management) scelta delle storie da mantenere nel rilascio in corso se ci sono problema di sovrastima della velocità di implemtazione. 3. Nuova storia (a cura del management e degli sviluppatori) Il management può introdurre una nuova storia (e cancellarne altre). Gli sviluppatori stimano la nuova storia. 4. Nuove stime (a cura degli sviluppatori) gli sviluppatori possono fare una nuova stima delle storie rimanenti se capiscono che la stima non è più realistica.

27 extreme Programming (XP) - Planning Game short release I rilasci frequenti (2-4 settimane) mirano a tenere conto di cambi di prospettiva, nuovi requisiti o imprecisioni nelle fasi precedenti.

28 extreme Programming (XP) - Progettazione In XP la documentazione della fase di progettazione consiste nella produzione di schede CRC (Classe, Responsabilità, Collaborazione). Si individuano i componenti che costituiranno ĺıarchitettura funzionale del sistema software, le classi e per ogni classe si scrive una scheda che individua: le responsabilità che ha nell ambito dell architettura (cosa fa nel sistema) le azioni / compiti che esegue (utile fare riferimento ai verbi usati dal cliente per descrivere i requisiti) ( metodi ) le altre classi che devono collaborare con questa per soddisfare le responsabilità, definendo le gerarchie di ereditarietà.

29 extreme Programming (XP) - Progrettazione project metaphor La progettazione in XP è guidata da metafore: Ad es. il sistema software deve realizzare le funzioni di una scrivania virtuale o di un foglio di lavoro elettronico scrivania virtuale foglio etc.). Il sistema software da costruire deve essere descritto attraverso metafore semplici e comprensibili a tutte le persone coinvolte nel progetto, in modo da poter condividere lo stesso vocabolario e la stessa percezione di quanto si sta per realizzare. In XP le metafore sostituiscono le architetture logiche.

30 extreme Programming (XP) - Progettazione simple design La struttura dell applicazione deve essere il più possibile semplice, in quanto l architettura del sistema deve essere facilmente comprensibile da tutte le persone coinvolte nel progetto. Viene sviluppato solo quanto è strettamente necessario a soddisfare lo scenario in esame, eventuali evoluzioni future non vengono considerate.

31 extreme Programming (XP) - Codifica In XP la codifica è l attività principale. XP prevede diverse pratiche a supporto di questa attività: Programmazione a coppie. Proprietà collettiva. Intregrazione continua. Standard di codifica. Refactoring

32 extreme Programming (XP) - Codifica pair programming La programmazione avviene a coppie, con lo scopo di favorire il controllo reciproco del codice prodotto e di stimolare la generazione di soluzioni innovative tramite il confronto tra persone diverse. Le coppie vengono riassortite molto frequentemente, cercando di affiancare persone con esperienze diverse, in modo da incentivare un apprendimento continuo. Le statistiche raccolte dimostrano che la tecnica del pair programming, pur dilatando i tempi di realizzazione del codice dal 20% al 50% permette di produrre rispetto alle software di migliore qualità, programmi meno voluminosi (dal 10 al 25% in meno della media), un numero di difetti inferiore nel codice (meno 10-20%)

33 extreme Programming (XP) - Codifica collective ownership Collettivizzazione del codice: il codice dell applicazione deve essere accessibile e manipolabile da tutti gli sviluppatori. Per rendere possibile ciò è necessario che esistano semplici regole condivise da tutte. La collettivizzazione contribuisce in maniera indiretta a semplificare il codice, in quanto le parti più oscure, incomprensibili a tutti fuorché agli autori, hanno un alta probabilità di essere eliminate. standard di codifica coding standards) L assenza della documentazione di supporto tipica dei metodi tradizionali rende necessari degli standard di codifica (coding standards), condivisi e validi solo all interno del team, che permettano di scrivere il codice in modo omogeneo e uniforme.

34 extreme Programming (XP) - Codifica refactoring L applicazione necessita di continue riprogettazioni per adattare il sistema alle nuove esigenze ed integrare fra loro le parti relative alle varie storie. Il refactoring è la ristrutturazione continua del codice al fine di renderlo sempre più chiaro, semplice, facilmente modificabile, eliminare parti superflue, senza modificare la sua funzione. integrazione continua (continuous integration) Non sono previste sessioni particolari per l integrazione, che è continua nel tempo (continuous integration).

35 extreme Programming (XP) - Testing La fase di testing è molto accurata, sia a livello di sistema che di singola unità. I test di sistema sono costruiti sulla base delle storie concordate con il committente, i test di unità solitamente sono supportati da strumenti automatici che rendono la verifica molto efficiente. Il metodo XP addirittura prescrive che i test vadano scritti prima della codifica. La validazione del software è ridotta alla verifica che esso superi tutti i test che sono stati ideati: Beck ha una concezione di stampo popperiano, secondo la quale un applicazione è funzionante finché non viene trovato un test che dimostra il contrario.

36 extreme Programming (XP) - Prassi organizzative ambiente di lavoro L ambiente di lavoro deve essere gradevole e informale, con zone adibite al relax e allo scambio di opinioni fra i membri del team rinuncia al lavoro straordinario Si tende ad evitare evitare il lavoro straordinario. partecipazione del committente (insite customer) Forte partecipazione del committente (insite customer). Il committente è infatti l unica fondamentale fonte di convalida del sistema, deve perciò partecipare non solo alla definizione delle storie, ma anche alla definizione dei test e alle fasi di verifica. Inoltre è la principale fonte di informazioni sul dominio di applicazione, per cui la sua presenza full-time con il team è ritenuta essenziale. Il committente è un collaboratore, non un entità verso cui si hanno solo obblighi contrattuali.

37 extreme Programming (XP) - I ruoli delle persone Importanza dei ruoli: la metafora della squadra. Dualismo cliente-programmatore della programmazione estrema: Il programmatore sa come programmare. Il cliente sa che cosa programmare. Il programmatore Il cliente Il collaudatore (tecnico dei test) Il tracker Il coach Il consulente Il grande capo Beck -. pag. 148

38 XP - I ruoli delle persone: il programmatore Il programmatore è il cuore dell XP. Il valore principale è la comunicazione con le altre persone. Attività del programmatore XP: scrivere test che mostrano aspetti vitali del software dividere il programma in parti più piccole, o assemblare parti troppo piccole in componenti più grandi e più coerenti. trovare un sistema di nomi significativi. sviluppare il software di maggior valore per il cliente, e di non sviluppare niente che non sia di valore.

39 XP - I ruoli delle persone: il programmatore Abilità del programmatore XP: programmare a coppie (pair programming) La progrmmazione a coppie implica comunicare e coordinarsi da vicino con gli altri programmatori per avere successo. semplicità Implica selezionare le richieste NECESSARIE. scrivere codice semplice e comprensibile facilmente tecnica Implica capacità di riorganizzare il codice (refactoring). di scrivere test unitari per il codice

40 XP - I ruoli delle persone: il programmatore Abilità del programmatore XP: mettere da parte la propensione alla proprietà individuale di una parte del codice in favore della proprietà condivisa dell intero sistema. coraggio essere pronti a riconoscere le proprie paure di sembrare stupido essere ritenuto inutile diventare superato non essere abbastanza bravo per far parte di un gruppo che si diverte a scrivere ottimo software.

41 Il cliente XP deve: XP - I ruoli delle persone: il cliente influenzare un progetto senza essere in grado di controllarlo prendere delle decisioni Importanza delle storie e loro sufficienza a descrivere il problema. Eliminazione delle storie non importanti. deve imparare a scrivere le storie deve imparare a scrivere test funzionali creare i dati per un test con l obiettivo di stabilire condizioni sufficienti per il funzionamento. deve anche dimostrare coraggio

42 XP - I ruoli delle persone: il tester Il collaudatore (tecnico dei test) è focalizzato sul cliente. Il tester ha il compito di aiutare il cliente a scegliere e a scrivere i test funzionali (responsabilità) dell esecuzione a intervalli regolari dei test funzionali e dell affissione dei risultati in un posto visibile a tutti di assicurarsi che gli strumenti di collaudo funzionino bene.

43 XP - I ruoli delle persone: il tracker Il lavoro del tracker è quello di chiudere il ciclo di feedback. Il tracker fa le stime Le dipendono dalla esperienza e dal feedback. Il tracker deve fare un gran numero di stime, per poi vedere come la realtà si concilia con esse. contribuisce al miglioramento delle stime fatte del gruppo è responsabile di osservare il quadro generale A metà di un iterazione il tracker deve essere capace di dire al gruppo se ce la farà o se si debba cambiare qualcosa. Dopo un paio d iterazioni nel piano degli impegni, il tracker dovrebbe essere in grado di stabilire se il gruppo riuscirà a portare a termine il prossimo rilascio senza grandi cambiamenti.

44 XP - I ruoli delle persone: il tracker Il lavoro del racker è quello di chiudere il ciclo di feedback. Il tracker è lo storico del gruppo Conserva un diario ufficiale dei punteggi dei test funzionali. un diario ufficiale contente i difetti riportati, i nomi di chi ha accettato la responsabilità per ciascuno di essi, e quali test sono stati aggiunti in relazione a ciascun difetto. ha l abilità di raccogliere le informazioni senza disturbare più del necessario l intero processo

45 XP - I ruoli delle persone: il coach è responsabile dell intero processo. Si accorge quando le persone deviano dal regolare funzionamento del gruppo, e richiama l attenzione di tutti sul problema. Il ruolo del coach diminuisce man mano che il gruppo matura. Concordemente ai principi del controllo distribuito e dell accettazione delle responsabilità, il processo dovrebbe essere responsabilità di tutti. All inizio del passaggio all XP, questo è troppo da chiedere a ogni programmatore. (Beck -, cap 22)

46 XP - I ruoli delle persone: il consulente Pair programming, semplicità generano gruppi estremamente flessibile, ma poco specialistici. Di qui la necessità di consulenti esterni L obiettivo dei membri del gruppo è di far sï che il consulente gli insegni come risolvere i loro problemi.

47 XP - I ruoli delle persone: il grande capo Comunicazione onesta con il gruppo: il gruppo deve volere che il capo sappia prima possibile quando le cose si stanno discostando dal piano, in modo che possa avere il maggior tempo possibile per reagire. il gruppo spiega le conseguenze dei cambiamenti nella situazione attuale. il gruppo può invitare il capo a ridurre la portata del progetto. il capo insiste affinché il gruppo faccia ciò che ha dichiarato di fare.

48 XP - Risoluzione dei rischi XP affronta i principali rischi dei progetti di sviluppo software con queste modalità: Ritardi nelle consegne: XP prevede cicli di sviluppo brevi, con iterazioni di durata limitata (3-4 settimane al massimo). Degrado della qualità: XP prevede che vengano eseguiti di continuo test sui semilavorati, sia pensati dai programmatori che dagli utenti stessi (per le funzioni). Fraintendimento requisiti: in XP il cliente è parte integrante del gruppo di lavoro. Le specifiche di progetto vengono continuamente riviste insieme al cliente durante il progetto, procedendo per raffinamenti successivi. I cicli di lavorazione sono rapidi, con frequenti feedback da parte del cliente, che effettua anche direttamente i test funzionali.

49 XP - Risoluzione dei rischi Variabilità dei requisiti: XP accorcia i tempi dei rilasci e prevede di procedere per incrementi graduali nello sviluppo in modo da gestire nuove richieste dei clienti e sviluppo, le modifiche ai requisiti senza che impattino su porzioni troppo ampie di software già sviluppato. Turn over delle risorse: XP dà responsabilità ai programmatori (si pianificano essi stessi il lavoro da svolgere e coprono l intero ciclo di lavorazione, dalla progettazione alla codifica e testing). Definisce pratiche innovative di lavoro, che danno fiducia e motivazione al personale e creano spirito di gruppo (planning game, lavoro di coppia)

50 Bibliografia 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali 2.3 Modelli evolutivi 2.4 Comparazione dei modelli Bibliografia

51 Bibliografia Bibliografia Riferimenti bibliografici - Generali 1. R. Pressman Ingegneria del software Mc Graw Hill Italia, 5a edizione, 2007, capitolo P. Jalote A Concise Introduction to Software Engineering Springer, 2008, capitolo 2.

52 Bibliografia Bibliografia Riferimenti bibliografici - Specifici 1. K. Beck, Addison-Wesley, 2000, (capitolo 22). 2. E. Capra Sviluppo del software: metodi agili o metodi tradizionali? ( 3. C. Ghezzi, M. Monga, extreme Programming: Programmazione estrema o revisionismo estremista?, Mondo Digitale n. 4, 2002.

53 Bibliografia Bibliografia Riferimenti bibliografici - Siti utili http: //