Corso di Laurea in Ingegneria Informatica Corso di Ingegneria del Software Ciclo di Vita del Software 1 Sommario • • • • • • • Attività fondamentali nel ciclo di vita Modelli di Processo Software Modello a cascata e sue varianti Modello a V Modelli evolutivi Modello trasformazionale Modello a spirale Ingegneria del Software Ciclo di Vita del Software 2 Ciclo di Vita del Software (CVS, o SLC) ! Un modello del ciclo di vita del software (CVS) – o Software Life Cycle, SLC - è una caratterizzazione descrittiva o prescrittiva di come un sistema software viene o dovrebbe essere sviluppato (W. Scacchi Encyclopedia of Software Engineering Vol. II pag. 860) ! Gli obiettivi sono i) determinare l'ordine delle attività nello sviluppo e nell'evoluzione del software, e ii) stabilire criteri di transizione per progredire da uno stadio di lavorazione al successivo Ingegneria del Software Ciclo di Vita del Software 3 Code and Fix ! ! Approccio “primitivo” alla produzione del software che consiste nello 1) scrivere codice e 2) aggiustarlo per correggere errori, migliorare e/o aggiungere funzionalità Inadeguato per lo sviluppo odierno del software: • Le grandi dimensioni dei sistemi rendono difficile la gestione non strutturata della complessità • Difficile la gestione non organizzata del personale (ad es. la gestione del turn over resa difficile dalla mancanza di documentazione) • Difficile aggiustare/modificare/ristrutturare il codice • Interpretazione sbagliate dei requisiti utente • Processo non prevedibile (tempi/costi), qualità non misurabile Ingegneria del Software Ciclo di Vita del Software 4 Necessità dei modelli di processo ! Questi problemi portarono a riconoscere la necessità di processi predicibili e controllabili, dunque strutturati ! Avere un buon processo è fondamentale. La qualità del processo di sviluppo influenza: • La qualità dei prodotti finali • I tempi per portare il prodotto sul mercato • I costi • Le prestazioni su diversi progetti Ingegneria del Software Ciclo di Vita del Software 5 Processi e Modelli di Processo Software: definizioni ! Processo : • un insieme di attività concentrate nel tempo finalizzate alla realizzazione di un particolare output. ! Processo Software: • Un insieme strutturato di attività necessarie per lo sviluppo di un sistema software. ! Modello di Processo Software: • E’ una rappresentazione semplificata di un processo. Esso fornisce una descrizione del processo da una particolare prospettiva. ! Es. La prospettiva delle attività del processo, o quella dei ruoli del personale coinvolto Ingegneria del Software Ciclo di Vita del Software 6 Caratteristiche dei Processi Software ! ! ! Esistono diversi tipi di software e non c’è un processo universale valido per tutti. Tutti i processi software includono comunque le stesse attività fondamentali. Ogni processo si caratterizza per l’organizzazione delle attività che esso include, ma anche per: • I prodotti, o deliverables che le sue attività producono. • I ruoli assegnati alle persone coinvolte nel processo. • Le pre e post-condizioni di ciascuna attività Ingegneria del Software Ciclo di Vita del Software 7 Attività fondamentali di un Processo SW Studio di fattibilità: Fornisce un documento con: Definizione del problema Valutazione Costi/Benefici ! Risorse finanziarie e umane ! Soluzioni alternative ! Tempi di consegna e modalità di sviluppo Acquisizione, analisi e specifica dei requisiti: Definire cosa il sistema dovrà fare, non come Specificare le funzionalità e le qualità che deve possedere, senza vincolare la progettazione e l'implementazione Richiede la conoscenza del dominio N.B. È un'attività critica. Un errore in questa fase può costare molto Ingegneria del Software Ciclo di Vita del Software 8 Analisi e specifica dei requisiti L'ingegneria dei requisiti sviluppa metodi per raccogliere, documentare, classificare e analizzare i requisiti Sono compiti dell'analista: !Identificare i portatori di interesse (stakeholders) !Esplicitare i requisiti !Conciliare i vari punti di vista (eventualmente contraddittori) !Specificare i requisiti Il risultato è la produzione di !Documento di Specifica dei Requisiti (DSR), comprensibile, preciso, completo ,coerente, non ambiguo, modificabile. !Contiene una descrizione del dominio, dei requisiti funzionali, non-funzionali, e requisiti del processo di sviluppo-manutenzione !Piano di Test di Sistema (PTS) Ingegneria del Software Ciclo di Vita del Software 9 Progettazione Strutturazione del sistema a diversi livelli di dettaglio ! Architettura generale (hardware e software) assegna funzionalità a componenti di alto livello ! Architettura dettagliata arriva alla definizione precisa dei moduli, delle loro funzionalità e delle interfacce ! Produzione Documento di Progetto (DSP) • Descrive i componenti del sistema, le loro interfacce, le relazioni tra di loro • Registra le decisioni significative e ne spiega le motivazioni • Importante per eventuali richieste future di cambiamento • La forma del documento è determinata dagli standard adottati dall'azienda Ingegneria del Software Ciclo di Vita del Software 10 Codifica, test e rilascio ! Produzione del codice • Può essere soggetta a standard aziendali, a convenzioni ! ! ! Test di Unità Test di Integrazione e di Sistema Test di Accettazione Manutenzione ! Correttiva, Adattativa, Perfettiva ! Tutte le attività descritte contengono compiti comuni: documentazione, verifica, gestione Ingegneria del Software Ciclo di Vita del Software 11 Modello a cascata (Waterfall Model) Ingegneria del Software Ciclo di Vita del Software 12 Modello a Cascata organizzazione sequenziale delle fasi ! Ogni fase raccoglie un insieme di attività omogenee per metodi, tecnologie, skill del personale, etc. ! I semilavorati output di una fase sono input alla fase successiva ! i prodotti di una fase vengono “congelati”, ovvero non sono più modificabili se non innescando un processo formale e sistematico di modifica ! Il processo è guidato dalla produzione di documentazione Ingegneria del Software Ciclo di Vita del Software 13 Modello a cascata Ingegneria del Software Ciclo di Vita del Software 14 Modello a cascata ª La fine di ogni fase è un punto rilevante del processo (milestone) ª L'output di ogni fase è chiamato deliverable ª La definizione precisa dei deliverable è importante per misurare il progresso di un progetto Criticità del modello a cascata ª È un modello ideale, che può essere solo approssimato nella pratica ª È possibile caratterizzarlo mediante tre proprietà: linearità, rigidità, monoliticità ª Nella pratica sono necessari feedback Ingegneria del Software Ciclo di Vita del Software 15 Criticità del modello a cascata ! A causa della rigidità, si assume che i requisiti possano essere congelati nelle prime fasi, quando le conoscenze sono ancora preliminari ª Monoliticità: se si commette un errore nei requisiti, viene fuori solo alla fine, dopo il rilascio, con costi esorbitanti ª Stime dei costi difficili ª Difficile anticipare i cambiamenti. Bassa evolvibilità ª Può richiedere una quantità ingente di documenti ª La difficoltà di produrre specifiche complete causa molta attività di manutenzione (che è particolarmente costosa) Ingegneria del Software Ciclo di Vita del Software 16 Una variante del Waterfall Model: V&V e Retroazione (Feedback) • Variazione del modello a cascata con l’inserimento di retroazione: si verifica la correttezza del risultato dell’attività con la possibilità di ripetere l’attività precedente. ! ! Verifica: Stabilire la verità della corrispondenza tra un prodotto software e la sua specifica Convalida: Stabilire l'appropriatezza di un prodotto software rispetto alla sua missione operativa Ingegneria del Software Ciclo di Vita del Software 17 V&V e Retroazione (Feedback) ! Variante del modello a cascata che tenta di superarne la monoliticità ! Introduce dei feedback in ogni fase. Si possono così rilevare errori prima del rilascio • Tuttavia resta un modello che non “ anticipa ” i possibili cambiamenti • Può essere utile quando si prevede che il sistema sarà poco soggetto a cambiamenti Ingegneria del Software Ciclo di Vita del Software 18 Modello a V (V-Model) Ingegneria del Software Ciclo di Vita del Software 19 Il Modello a V Ingegneria del Software Ciclo di Vita del Software 20 Strategia del Modello a V ! Le attività del ramo di sinistra sono collegate a quelle del ramo di destra destra ! Durante le attività di sinistra, vengono progettati i test della fase a destra corrispondente (ad es., alla specifica dei requisiti corrisponde la progettazione dei test di accettazione) ! Se si trova un errore in una fase a destra (es. test di sistema) si riesegue la fase a sinistra collegata ! Si può iterare migliorando requisiti, progetto, codice Ingegneria del Software Ciclo di Vita del Software 21 Esempio: Standard per sistemi IT della repubblica federale tedesca Ingegneria del Software Ciclo di Vita del Software 22 Modello a V ! Prevede una V per lo sviluppo di sistemi HW/SW, con una doppia retroazione. • N.B. Sviluppo di sistemi, di cui il software è una parte ! ! ! Esamina dapprima i requisiti utente di sistema (sia funzionali sia non funzionali) Identificazione delle unità del sistema e assegnazione dei requisiti alle unità L'analisi dei requisiti hardware/software esamina le risorse di ogni unità, decomponendole in • CSCI (Computer Software Configuration Items) • HCI (Hardware Configuration Items) Ingegneria del Software Ciclo di Vita del Software 23 Modello a V ! Si passa poi alla progettazione software vera e propria (allocazione di un task set per ogni CSCI) ! La progettazione software dettagliata alloca risorse ai moduli software imponendo requisiti temporali e produce il progetto dettagliato di ogni CSCI ! Infine si passa all'implementazione, al test ed integrazione software, e al test ed integrazione di sistema prima dell'utilizzo ! Le varianti del modello a cascata sono adatte soprattutto quando: a) si prevede che il sistema (e/o l'ambiente) sarà poco soggetto a cambiamenti, b) vi sono requisiti chiari e completi sin da subito con poca possibilità di cambiare (ad es. sistemi non interattivi) Ingegneria del Software Ciclo di Vita del Software 24 Modelli evolutivi Ingegneria del Software Ciclo di Vita del Software 25 Sviluppo evolutivo ! Basato sull’idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraverso varie versioni. ! Noto anche come Sviluppo Prototipale. Ingegneria del Software Introduzione ai Processi Software Ciclo di Vita del Software A.R- Fasolino 26 I Prototipi nei Modelli Evolutivi ! Prototipo: Modello approssimato dell'applicazione, il cui obiettivo è di ricevere feedback per affinare i requisiti • Il modello prototipale è dunque adatto quando i requisiti non sono completi e non ambigui • Si usa il prototipo per raccogliere feedback dagli opportuni stakeholder ! Es: prototipo della GUI per chiarire i requisiti definendo come si deve presentare l'applicazione Ingegneria del Software Ciclo di Vita del Software 27 Modelli Evolutivi ! Due modelli fondamentali: ! A) Sviluppo con Prototipo Usa e Getta • L’obiettivo è di comprendere I requisiti o altri aspetti del sistema. Si parte da requisiti poco chiari e si realizzano prototipi per esplorare i requisiti e chiarirli. ! B) Sviluppo Esplorativo (Con prototipo evolutivo) • 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. Ingegneria del Software Ciclo di Vita del Software 28 (A) Sviluppo con Prototipo Usa e Getta (“Throw Away”) ! Realizzazione di una prima implementazione (prototipo), più o meno incompleta, da considerare come una ‘prova’, con lo scopo di: • accertare la Fattibilità del prodotto • validare i Requisiti ! Lo sviluppo effettivo inizia dalla seconda versione (ad es. con un approccio a cascata) ! Questo approccio (ispirato al principio “Do it twice”) consente di ridurre errori sui requisiti Ingegneria del Software Ciclo di Vita del Software 29 Modello prototipale con prototipo usa e getta ! ! Il prototipo è uno strumento di identificazione dei requisiti di utente; è incompleto, approssimativo, realizzato utilizzando parti già possedute o routines stub. Il prototipo viene gettato dopo che è servito per chiarire i requisiti Ingegneria del Software Ciclo di Vita del Software 30 Esempio di Modello Prototipale ! Uso del Prototipo usa-e-getta per la Specifica dei requisiti Ingegneria del Software 31 Ciclo di Vita del SoftwarePSSS – CVS e Processi Software Variante di Modello Prototipale ! Uso del Prototipo usa-e-getta nella fase di design Ingegneria del Software 32 Ciclo di Vita del SoftwarePSSS – CVS e Processi Software Altra variante di Modello Prototipale Ingegneria del Software Ciclo di Vita del Software 33 (B) Sviluppo con prototipo evolutivo ! Prototipo evolutivo: Le versioni intermedie del prototipo vengono iterativamente raffinate e completate. L’n-esimo prototipo viene rilasciato. Ingegneria del Software Ciclo di Vita del Software 34 (A) Sviluppo evolutivoEsplorativo Specifica requisiti Descrizione Requisiti iniziali Ingegneria del Software Versione Iniziale Sviluppo Versioni Intermedie Convalida Versione Finale Ciclo di Vita del Software 35 Sviluppo Evolutivo Esplorativo ! Un modello di processo evolutivo esplorativo è “un modello le cui fasi sviluppano versioni incrementali di un prodotto con una direzione evolutiva determinata dall'esperienza pratica” Ingegneria del Software Ciclo di Vita del Software Sviluppo Evolutivo Esplorativo ! ! ! Vantaggi: • Rapido feedback e possibilità di far cambiare I requisiti 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. linguaggi di prototipazione rapida) Applicabilità • A sistemi interattivi di piccole e medie dimensioni (<500.000 LOC); • Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l’interfaccia utente); • Per sistemi destinati a vita breve. Ingegneria del Software Ciclo di Vita del Software 37 Modello Incrementale Ingegneria del Software Ciclo di Vita del Software 38 Modello con Sviluppo e Consegna Incrementale ! ! ! ! Ingegneria del Software 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. In ogni step si usa il modello a cascata L’utente è coinvolto nella definizione dei successivi incrementi Si evita di produrre funzionalità non richieste Ciclo di Vita del Software A.R- Fasolino 39 Processo di Sviluppo e Consegna Incrementale Individuazione Preliminare requisiti Sviluppo dell’incremento Assegnazione requisiti agli incrementi Progetto architetturale Convalida dell’incremento Integrazione dell’incremento Sistema Incompleto? Convalida Rilascio Incremento Sistema Completo? Sistema Finale Ingegneria del Software Ciclo di Vita del Software 40 Sviluppo e Consegna Incrementale ! ! ! 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. Ingegneria del Software Ciclo di Vita del Software A.R- Fasolino 41 Rilascio degli incrementi design build install increment 1 evaluate first incremental delivery design build install evaluate increment 2 second incremental delivery design build install evaluate third incremental delivery Ogni componente rilasciato deve fornire qualche beneficio agli interessati (stakeholders) Ingegneria del Software Ciclo di Vita del Software increment 3 SISTEMA RILASCIATO 42 Esempio di processo incrementale Requisiti: R1, R2, R3 Architettura: M1, M2, M3, M4 Pianificazione: 3 iterations Iteration1 R1, requires M1, M2 Develop and integrate M1, M2 Deliver R1 Iteration2 R2, requires M1, M3 Develop M3, integrate M1, M2, M3 Deliver R1 + R2 Iteration3 R3, requires M3, M4 Develop M4, integrate M1, M2, M3, M4 Deliver R1 + R2 + R3 Ingegneria del Software Ciclo di Vita del Software 43 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. E’ possibile gestire esigenze di cambiamento dei requisiti. I servizi a più alta priorità saranno anche testati più intensamente degli altri. Ingegneria del Software Ciclo di Vita del Software A.R- Fasolino 44 Svantaggi dello sviluppo incrementale ! ! ! Lo sviluppo incrementale può essere problematico quando gli utenti hanno bisogno di un sistema funzionante completo che sostituisca un sistema preesistente. Può essere difficile identificare le funzionalità comuni (richieste da tutti i requisiti), giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti. Quando la specifica completa deve far parte del contratto di sviluppo del sistema, questo modello non è adeguato. Ingegneria del Software Ciclo di Vita del Software Modello trasformazionale Ingegneria del Software Ciclo di Vita del Software 46 Modello Trasformazionale Sviluppo di software come una progressione di passi Una descrizione formale viene trasformata in una descrizione meno astratta. Ingegneria del Software Ciclo di Vita del Software 47 Modello Trasformazionale Basato su due concetti Prototipazione Formalizzazione Codice eseguibile di più basso livello ! Si specificano i requisiti formalmente ! Si procede trasformando man mano la descrizione formale in una meno astratta e più dettagliata, fino a che diviene eseguibile da un processore astratto ! Le specifiche vengono convalidate prima di essere trasformate ! Le specifiche eseguibili possono essere viste come un prototipo evolutivo Ingegneria del Software Ciclo di Vita del Software 48 Modello Trasformazionale ! Le trasformazioni possono essere eseguite manualmente o supportate da appositi strumenti ! Il processo di trasformazione può avvantaggiarsi di componenti riusabili ! Il processo si avvale della storia dello sviluppo, propriamente immagazzinata, per il supporto a future richieste di cambiamenti ! Attualmente, è un paradigma praticabile soprattutto per realizzare programmi piccoli e per domini applicativi specifici, ma dovrebbe “scalare” per progetti vasti e complessi è guardato con interesse per l'approccio formale allo sviluppo del software ! Ingegneria del Software Ciclo di Vita del Software 49 Modello a spirale Ingegneria del Software Ciclo di Vita del Software 50 Obiettivi ! ! Obiettivo: fornire un quadro di riferimento per la progettazione dei processi Meta-modello ! Consentire di scegliere il modello più appropriato in funzione del livello di rischio ! Il rischio è visto come una circostanza potenzialmente avversa in grado di pregiudicare il processo di sviluppo e la qualità del prodotto ! Gestione dei rischi: “identificare, affrontare ed eliminare i rischi prima che insorgano problemi seri o causa di reimplementazioni costose” Ingegneria del Software Ciclo di Vita del Software 51 Caratteristiche (Boehm, 1998) ! ! ! ! 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. Ingegneria del Software Ciclo di Vita del Software A.R- Fasolino 52 Modello a spirale di Boehm ! ! ! Modello ciclico Il raggio del cerchio rappresenta il costo accumulato Ogni ciclo è una fase: studio fattibilità, progettazione, etc. Ingegneria del Software Ciclo di Vita del Software 53 Modello a spirale di Boehm Ingegneria del Software Ciclo di Vita del Software 54 Settori del Modello a Spirale ! Primo settore: Definizione di obiettivi, vincoli e piano di gestione della fase. ! Secondo settore : Si analizzano I rischi della fase e si scelgono le attività necessarie a gestire I rischi (ad esempio tramite simulazione o prototipazione) ! Terzo settore: Si sceglie un modello di sviluppo per il sistema tra I modelli generici Ingegneria del Software Ciclo di Vita del Software 55 Settori ! Nel terzo settore si può utilizzare: • Modello evolutivo, se i requisiti sono incerti • A cascata se i requisiti sono chiari e ben definiti • Trasformazionale se la sicurezza è un requisito più importante ! Quarto settore: revisione dei risultati e pianificazione della prossima iterazione della spirale Ingegneria del Software Ciclo di Vita del Software 56 Confronto Ingegneria del Software Ciclo di Vita del Software 57 Confronto ! Approccio “code and fix”. Non può essere considerato un modello: consiste nel seguire l'intuizione, senza alcuna pianificazione ! L'estremità opposta è costituita dal modello a cascata: rigido, pre-specificato, non adattativo, monolitico È solitamente guidato da una corposa documentazione che misura il progresso del progetto => processo guidato dalla documentazione ! ! Il modello evolutivo il progresso è misurato dagli incrementi => processo guidato dagli incrementi ! Similmente, il modello trasformazionale è guidato dalle specifiche ! Mentre il meta-modello a spirale è guidato dai rischi Ingegneria del Software Ciclo di Vita del Software 58 Confronto Modello Punti Forti Punti Deboli Code & Fix Adatto a progetti molto piccoli Non applicabile a progetti di media/alta complessità; non ripetibile; non strutturato Waterfall e sue Varianti Comprensibile, controllabile, ampia documentazione, adeguato ai contratti, chiare milestones Difficile gestione di requisiti instabili/incompleti; ritarda l'indivuazione dei problemi; eccessiva distanza tra specifica dei requisiti e la consegna; bassa tempestività Evolutivo Utilizzo di Feedback; gestione efficiente della varaibilità dei requsiti; tempestività dei prodotti Necessità di competenze e preparazione adeguata sia nello sviluppo che nella gestione (ad es. dei rischi) Agile Adatto a progetti A causa della poca strutturazione, particolarmente innovativi necessità di una grande disciplina e e con requisiti non ben motivazione; non molto adeguato ai definiti Ingegneria del Software Ciclo di Vitacontratti; del Software difficilmente comprensibile 59 dal Analisi dei rischi ! Modello a cascata • Alto rischio per sistemi nuovi con requisiti non chiari ! ! Possibili incomprensioni dei requisiti utenti e requisiti basati su assunzioni errate o parziali Requisiti che evolvono • Alto rischio di durata eccessiva dello sviluppo => bassa tempestività • Ciò ha portato a considerare modelli sempre più flessibili • Basso rischio per sistemi con specifiche e tecnologie assestate Ingegneria del Software Ciclo di Vita del Software 60 Analisi dei rischi ! Modelli evolutivi • Alto rischio per mancanza di visibilità • Basso rischio per applicazioni nuove, requisiti ambientali variabili ed alta evolvibilità ! Modello trasformazionale • Alto rischio per necessità di tecnologie avanzate ed alte competenze ! Ogni progetto è caratterizzato dai propri rischi specifici, da individuare nella fase iniziale. Il modello può essere scelto in base a tale analisi (come nella spirale di Bohem) ! Ad es. rischi legati alla gestione del personale, pianificazione budget e tempi, rischi di sviluppo funzionalità errate, interfacce inadeguate, requisiti instabili, rischi nell'acquisto di componenti esterni, … Ingegneria del Software Ciclo di Vita del Software 61