Cicli di Vita del Software. Porfirio Tramontana 2009 Ingegneria del Software Cicli di Vita del Software

Transcript

1 Cicli di Vita del Software

2 Riferimenti Ian Sommerville, Ingegneria del Software, 8a ed. Capitolo 4 (processi software) Capitolo 17 (sviluppo rapido del software) Capitolo 19 (CBSE cenni)

3 Studio di fattibilita Modello a cascata Analisi e specifica dei requisiti Progettazione Codifica Testing Messa in esercizio Manutenzione

4 Limitazioni del Waterfall model Svantaggi Difficoltà di gestire eventuali necessità di modifiche durante l esecuzione del processo. Ciascuna fase deve infatti essere completata e i suoi output fissati, prima di passare alla fase successiva. il modello assume che i requisiti possano essere congelati alla fine della fase di specifica, ma ciò è impensabile per un sistema i cui requisiti non siano ben chiari neanche al committente in alcuni casi è auspicabile sviluppare prima una parte del sistema e poi completarlo (utente finale= mercato) in alcuni casi lo sviluppo di tutta la documentazione richiesta è non necessaria (uso di ambienti di sviluppo visuali)

5 Problemi del Waterfall model La suddivisione inflessibile del progetto in fasi distinte rende difficile rispondere alle richieste di cambiamento dei requisiti da parte del cliente. Di conseguenza questo modello è adatto solo se I requisiti sono ben chiari fin dall inizio ed è difficile che cambino durante lo sviluppo. In realtà pochi sistemi presentano requisiti stabili. Il modello a cascata si usa per lo più quando fa parte di un progetto più vasto di ingegneria dei sistemi.

6 Sviluppo evolutivo Basato sull idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraverso varie versioni. Due modelli fondamentali: Sviluppo Esplorativo L obiettivo è di lavorare col cliente per esaminare i requisiti iniziali e farli evolvere fino al sistema finale. Dovrebbe partire da pochi requisiti ben compresi e aggiungere nuove caratteristiche proposte dal cliente. Prototipo Usa e Getta L obiettivo è di comprendere i requisiti del sistema. Si parte da requisiti poco chiari e si realizzano prototipi per esplorare i requisiti e chiarirli.

7 Sviluppo evolutivo

8 Sviluppo evolutivo Problemi Mancanza di visibilità del processo (è anti-economico documentare ogni versione del sistema); I sistemi diventano spesso mal strutturati (per i continui cambiamenti); Richiedono particolari skills (es. uso di linguaggi di prototipazione rapida) Applicabilità A sistemi interattivi di piccole e medie dimensioni (< LOC); Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l interfaccia utente); Per sistemi destinati a vita breve. Per grandi sistemi è consigliabile un approccio misto.

9 Ingegneria del software basata su componenti (CBSE) Sviluppo basato sul riuso sistematico, integrando componenti esistenti o interi sistemi COTS (Commercial-off-the-shelf) Fasi del Processo Specifica dei requisiti; Analisi dei componenti; Modifica dei Requisiti (specificando i componenti disponibili); Progettazione con riuso; Sviluppo e Integrazione. Questo approccio viene sempre più usato grazie all affermarsi di appositi standard per la specifica di componenti.

10 Sviluppo basato su Componenti

11 Processi di sviluppo Iterativi I requisiti di un sistema cambiano SEMPRE nel corso di un progetto, e sono pertanto inevitabili nuovi cicli di processo in cui si ritorna sulle fasi già condotte, soprattutto per grandi sistemi. I cicli di processo possono essere applicati ad ogni generico modello di processo. Due possibili approcci: Sviluppo e Consegna Incrementale; Sviluppo a Spirale.

12 Sviluppo e Consegna Incrementale Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la consegna sono eseguiti per incrementi,dove ogni incremento rilascia parte delle funzionalità richieste. Ai requisiti utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con I primi incrementi. Una volta partito lo sviluppo di un incremento, i relativi requisiti devono essere congelati, mentre i requisiti coinvolti in incrementi successivi possono continuare ad evolvere. I servizi comuni possono essere implementati all inizio del processo, o quando una funzione è richiesta da un dato incremento.

13 Sviluppo e Consegna Incrementale

14 Vantaggi dello sviluppo incrementale I clienti non devono aspettare il sistema completo per la consegna, ma possono disporre al più presto dei requisiti più critici, attraverso I primi incrementi. I primi incrementi possono essere usati come prototipo per aiutare a definire I requisiti degli incrementi successivi. Si riduce il rischio di un fallimento totale del progetto. I servizi a più alta priorità saranno anche testati più intensamente degli altri.

15 Alcuni problemi Gli incrementi devono essere relativamente piccoli (<= LOC) ma può essere difficile predisporre i requisiti in incrementi della dimensione giusta. Le funzionalità comuni (richieste da più requisiti) potrebbero non essere identificate abbastanza presto, giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti.

16 Sviluppo a Spirale (di Boehm) Il processo è rappresentato come una spirale, piuttosto che una sequenza di attività con retro-azioni. Ogni giro nella spirale rappresenta una fase del processo. Non prevede fasi prefissate a priori (come la specifica o il design) ma i cicli sono definiti in base al caso specifico. C è una esplicita gestione dei rischi che vengono valutati e risolti durante tutto il processo.

17 Modello di sviluppo a spirale Determinazione di obiettivi, alternative e vincoli Valutazione di alternative, identificazione e risoluzione dei rischi Pianificazione della fase successiva Sviluppo e Verifica del prodotto successivo

18 Settori del modello a spirale Determinazione degli obiettivi Definizione di obiettivi, vincoli e piano di gestione della fase. Valutazione e riduzione del rischio Si analizzano i rischi della fase e si scelgono le attività necessarie a gestire I rischi. Sviluppo e Convalida Si sceglie un modello di sviluppo per il sistema tra i modelli generici. Pianificazione Il progetto viene revisionato e si decide se continuare con un nuovo giro della spirale. Si pianifica tale giro.

19 Rational Unified Process Un moderno modello di processo software derivato da UML e dal relativo processo. Prevede 6 pratiche fondamentali: Sviluppare il software ciclicamente Gestire i requisiti Usare architetture basate sui componenti Creare modelli visivi del software Verificare la qualità del software Controllare le modifiche al software

20 Le fasi del RUP Avvio Elaborazione Costruzione Transizione

21 Le fasi del RUP Avvio Stabilire gli obiettivi di business (e relativi limiti, fattibilità e giustificazioni economiche) per il sistema; organizzare le risorse necessarie alla sua soluzione. Elaborazione Ottenere una comprensione del dominio del problema (e specificare i requisiti), stabilire una struttura architetturale ed il piano di progetto. Costruzione Progettare, programmare e testare il sistema incrementalmente. Transizione Trasferire il sistema nel suo ambiente operativo.

22 Metodi Agili L insoddisfazione per l eccessivo overhead richiesto dai sistemi di progettazione ha portato negli anni 90 alla proposta dei metodi agili. Tali metodi: Si concentrano sul codice, piuttosto che la progettazione; Sono basati su un approccio iterativo allo sviluppo software; Sono pensati per rilasciare software funzionante rapidamente, e per farlo evolvere rapidamente per soddisfare nuove esigenze. Propongono di coinvolgere il cliente il più possibile nel processo di sviluppo I metodi agili sono più adatti per sistemi aziendali di piccole/medie dimensioni o a prodotti per PC.

23 Alcuni Metodi Agili Extreme Programming (Ken Beck 1999) SCRUM Crystal DSDM (Dynamic System Development Method) Alcuni di questi metodi sono stati recepiti nel RUP Ogni metodo propone un diverso processo, ma tutti condividono gli stessi principi

24 Principi dei metodi agili Principle Customer involvement Incremental delivery People not process Embrace change Maintain simplicity Description The customer should be closely involved throughout the development process. Their role is provide and prioritise new system requirements and to evaluate the iterations of the system. The software is developed in increments with the customer specifying the requirements to be included in each increment. The skills of the development team should be recognised and exploited. The team should be left to develop their own ways of working without prescriptive processes. Expect the system requirements to change and design the system so that it can acc ommodate these changes. Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.

25 Problemi dei metodi agili Non sempre i clienti possono partecipare a tempo pieno al processo di sviluppo. I membri del team non sono sempre adatti al coinvolgimento intensivo con altri membri che caratterizza I metodi agili. Dare la priorità alle modifiche può essere difficile dove esistono vari stakeholders,ognuno con suoi interessi. Mantenere la semplicità del sistema può richiedere lavoro extra (e tempo extra, non sempre disponibile). Il contratto può non essere facilmente definito, come accade in altri approcci allo sviluppo iterativo.

26 Extreme programming Forse è il metodo agile più noto ed usato. Extreme Programming (XP) adotta un approccio estremo allo sviluppo software. L approccio si basa su requisiti espressi come scenari (storie utente) che sono implementati direttamente; Nuove versioni possono esser prodotte più volte al giorno; Gli incrementi sono rilasciati al cliente frequentemente, in genere ogni 2-4 settimane; Ogni nuova versione viene completamente testata, e viene accettata solo se supera tutti i test.

27 Il processo XP

28 Pratiche dell Extreme Programming 1. The Planning Process (o Planning Game). La pianificazione del processo in XP consiste nella definizione del business value di ogni caratteristica desiderata e nella stima dei costi per decidere in che ordine le caratteristiche debbano essere realizzate. Si tratta quindi di una strategia estremamente duttile, che può essere ripensata durante lo svolgimento del progetto. 2. Small Releases. La vita e lo sviluppo dell applicazione sono scanditi dai rilasci di versioni del prodotto funzionanti. Ogni rilascio rappresenta il punto conclusivo di un iterazione di sviluppo e l inizio di una nuova pianificazione. Per poter tener conto di cambi di prospettiva, errori di valutazione, nuovi requisiti, restrizioni di bilancio, ogni iterazione dovrebbe durare non più di qualche settimana (in genere, da due a quattro). 3. Metaphor. I team di lavoro XP condividono un sistema dei nomi, nel quale siano compresi I concetti fondamentali relativi al software sotto sviluppo (in pratica il dominio dei dati)

29 Pratiche dell Extreme Programming 4. Simple Design. Un programma costruito con XP dovrebbe essere il programma più semplice in grado di soddisfare i requisiti. Non si cercano soluzioni che possano portare benefici in un prossimo futuro. La qualità del progetto é comunque tenuta alta, grazie anche alle attività di refactoring 5. Testing. Il testing é un elemento fondamentale dell XP. I programmatori devono scrivere i test contemporaneamente alla scrittura del programma stesso (strumenti come XUnit sono particolarmente utili). Il testing di accettazione invece é demandato al cliente finale 6. Refactoring. Durante le fasi di integrazione del codice appena prodotto con il resto del sistema, bisogna operare in maniera da tenere alta la qualità della progettazione, evitando ridondanze dei dati e duplicazioni del codice. Fondamentale rimane ancora la comunicazione tra i vari gruppi

30 Pratiche dell Extreme Programming 7. Pair Programming. I programmatori XP lavorano in coppia: due programmatori sulla stessa macchina. Uno dei programmatori é addetto alla scrittura fisica del codice, mentre l altro ne controlla la correttezza, salvo scambiarsi I ruoli di tanto in tanto. Esperimenti dimostrano come la produttività sia superiore rispetto a quella di due programmatori separati. 8. Collective Ownership. Ogni programmatore deve essere in grado di avere un idea generale del progetto e di poter toccare qualunque punto del codice, anche di quello che non ha scritto lui personalmente. Questìobiettivo può essere raggiunto seguendo il principio di Simple Design 9. Continuous Integration. Il processo di integrazione del sofware con i nuovi moduli avviene più volte al giorno. Ciò aiuta I programmatori ad essere sempre aggiornati sullo stato del progetto e riduce la maggior parte dei gravi problemi di integrazione che si verificano quando questa fase non é eseguita così spesso.

31 Pratiche dell Extreme Programming hour Week. I programmatori stanchi commettono più errori. Essi non dovrebbero fare troppo straordinario, in modo da essere freschi, in salute e produttivi 11. On-site Customer. Il committente deve essere coinvolto nello sviluppo perché è l unica fondamentale fonte di convalida del sistema. Partecipa perciò alla stesura dei test di sistema e verifica, periodicamente, che il sistema realizzato corrisponda effettivamente alle proprie esigenze.inoltre, è la principale fonte di informazione per la conoscenza sul dominio di applicazione. 12. Coding Standard. I programmatori dovrebbero condividere uno stesso stile di scrittura del codice, in modo da rendere più semplice la comunicazione

32 XP e i principi agili Lo sviluppo incrementale è realizzato attraverso release piccole e frequenti. Il coinvolgimento del cliente nel processo di sviluppo deve essere a tempo pieno. Si da attenzione alle persone (e non al processo) attraverso la programmazione a coppie, il possesso collettivo del codice e con tempi di lavoro non eccessivo. Le modifiche sono supportate da release costanti del sistema. Il mantenimento della semplicità è raggiunto attraverso pratiche continue di refactoring.