Il ciclo di vita del software. La necessita` di un modello. La mancanza di un modello. La prima proposta di soluzione

Transcript

1 Il ciclo di vita del software Progettazione e implementazione è solo una fase, per quanto importante, della produzione industriale del software Altre fasi sono importanti. Ad esempio: h Analisi dei requisiti è una fase preliminare che serve a catturare i requisiti del committente ( che( cosa deve fare l applicazione? l applicazione? ) h La verifica (testing( testing) ) del sw è fase in cui si individuano e eliminano errori nel codice Vogliamo definire il ciclo di vita del software, ossia la descrizione della produzione industriale del sw,, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione, al suo ritiro La necessita` di un modello Qualunque "industria" manifattureria ha un modello per la produzione dei beni h Es. modelli generali come catena di montaggio, produzione batch, produzione di massa, mass customization,, just in time h Modelli dettagliati per particolari industrie (il processo di assemblaggio semblaggio dei pezzi ) Un modello di produzione consente di: h pianificare le attivita` e le risorse necessarie (p.es. sapere quando servono certi parti e quante ne servono) h prevedere e controllare i costi del processo e la qualita` dei prodotti Ci interessa definire un modello del processo di produzione del software 1 2 La mancanza di un modello Senza un modello, non esiste un processo pianificato Lo sviluppo avviene in maniera spontaneistica (caotica?), e cio` causa problemi di hcontrollo dei tempi e dei costi hqualita` dei prodotti Talora si parla ironicamente di modello "code&fix" code&fix" " (vale a dire, l'assenza di modello) La prima proposta di soluzione Il ciclo di vita "a cascata" (fine anni '60 inizio anni '70) 3 4

2 Un modello a cascata ("waterfall model") Studio di fattibilita` Analisi e specifica dei requisiti Progettazione (di alto livello e di dettaglio) Implementazione e test (di unita` e di integrazione) Obiettivo del modello la produzione di software come catena di montaggio Cercare un metodo sistematico che consenta di hidentificare fasi e attivita` attraverso cui procedere hstandardizzare gli output di ciascuna fase (semilavorati "artifacts") hforzare un procedimento lineare di passaggio tra una fase e la successiva, a completamento avvenuto della fase hnessun ritorno all'indietro, considerato dannoso impedisce una buona pianificazione e controllo Messa in esercizio ("Deployment") Manutenzione 5 6 Esaminiamo le fasi Le fasi si ritroveranno anche in altri modelli di ciclo di vita Ciò che li distinguerà sarà la modalità di organizzazione del processo, ma esse dovranno comunque essere effettuate h studio di fattibilità h analisi e specifica dei requisiti h progetto di massima (architettura) di dettaglio h implementazione e test codifica test di modulo, Test di integrazione,, di sistema h installazione e messa in esercizio (deployment) h modifica e manutenzione idealmente in sequenza ma in pratica variamente alternate 7 Fase: : Studio di Fattibilità e pianificazione Analisi costi/benefici per determinare se il progetto deve essere avviato hdetermina se il progetto debba essere avviato (buy( vs make), le alternative, le risorse di massima necessarie hproduce uno studio di fattibilità: descrizione preliminare del problema Scenari che decrivono le soluzioni possibili Costi e tempi per varie alternative Pianificazione: hredarre piani come: piani di garanzia della qualità,, di gestione delle configurazioni, di manutenzione hun piano prevede come certe attività dovranno essere svolte hfase tipica per grossi progetti 8

3 Fase: Analisi e Specifica dei Requisiti Cliente vuole un servizio: occorre chiarire quale e in che modo ottenerlo ASR individua i requisiti caratteristici del software e li specifica in modo completo e rigoroso h Deriva una specifica per il software (la "macchina" da realizzare): CHE COSA deve svolgere il sw Convalida la specifica mediante tecniche di analisi e verifica. Richiede: h interazione con l utentel h comprensione del dominio applicativo (es. Banca...) Produce: documento di specifica dei requisiti h Spesso a partire dalla specifica dei requisiti vengono predisposti casi di test Fase: Progettazione ("design") Definisce la "architettura software" complessiva h Componenti h Relazioni e interazioni tra componenti Obiettivo h Supportare lo sviluppo parallelo ("concurrent engineering") h Suddividere le responsabilità Produce il "Documento di progetto Dall'architettura complessiva in termini di sottosistemi fino all'identificazione dei singoli moduli che comporranno il sistema h classi e packages in java Distinzione tradizionale: progetto di massima (high-level design) e di dettaglio (low-levellevel design) 9 10 L'idea del progetto modulare Una visione grafica intuitiva Il sistema complessivo e` suddiviso in parti hdivide et impera Ogni parte (modulo) deve realizzare una funzionalita` logica autosufficiente nel sistema complessivo Deve essere chiaro che cosa un modulo offre agli altri moduli in termini di funzionalita' hinterfaccia del modulo A B C D 11 12

4 Modulo La scomposizione in moduli deve facilitare lo sviluppo concorrente e le successive modifiche Deve essere possibile modificare (internamente) ciascun modulo senza impattare sugli altri moduli Un modulo deve "incapsulare" decisioni di progetto che si possono cambiare senza che se ne modifichi l'interfaccia Decomposizione Come effettuare una decomposizione in moduli principio di information hiding: : Un modulo è caratterizzato da ciò che può essere modificato senza che gli altri moduli ne risentano hquindi occorre nascondere agli altri moduli tutto ciò che non è necessario gli altri moduli conoscano alta coesione interna basso accoppiamento fra i moduli Obiettivo del progetto di massima hsupportare lo sviluppo parallelo delle componenti hsuddividere le responsabilità fra vari programmatori Progetto di dettaglio ogni modulo viene progettato in dettaglio h ne vengono anche determinate le modalità di verifica, e ne viene svolta un analisi Deve essere chiaro che cosa un modulo offre agli altri moduli in termini di funzionalita' hinterfaccia del modulo Le fasi "basse" del ciclo di vita a cascata 15 16

5 Fase: Codifica e test il software viene codificato mediante opportuni linguaggi di programmazione e compilato; hogni modulo viene implementato usando il linguaggio di programmazione scelto hogni modulo include la propria documentazione Sul sw vengono eseguite le prime verifiche statiche (es. compilazione, inizializzazione delle variabili) e dinamiche (test): Test di unità,, di integrazione e di sistema Fase di test suddivisa in tre parti: test di unità: h ogni modulo viene verificato e testato isolatamente, usando una varietà di tecniche di analisi h Si continua fino a quando si ritiene che i moduli siano stati testati abbastanza: Test di integrazione: h Non è conveniente riunire l intero l sistema e testarlo: se ci sono errori dovuti a cattiva comunicazione fra moduli come fare a trovarli? Si esegue allora integrazione incrementale h i moduli vengono gradualmente integrati in sottosistemi, effettuando opportune verifiche della loro corretta interazione Test di sistema: : il sistema completo e finito viene convalidato rispetto ai suoi requisiti funzionali Fase: Messa in esercizio (consegna, posa in opera,"deployment deployment ) Obiettivo: hdistribuire l'applicazione e gestire le diverse installazioni e configurazioni sui computer dei clienti il sistema viene installato e attivato, e il personale addetto al suo utilizzo viene addestrato; hspesso molte installazioni o installazione distribuita... può essere più complessa del previsto (es. sistema life-critical che deve continuare a funzionare anche quando si sostituisce software...) test di accettazione: hil sistema completo e finito viene collaudato da utente/organizzazione indipendente Fase: Manutenzione successivamente all installazione, il sistema viene modificato per correggerne difetti, per adeguarlo a modifiche intervenute nei requisiti o nell ambiente operativo, o per reingegnerizzarlo manutenzione = tutte le modiche dopo la consegna h(termine poco adatto: il software non e` soggetto a usura! se succede un malfunzionamento, la causa era presente fin dall'inizio! Spesso copre più del 50% dei costi totali!! hindagine recente per le imprese di software dell'ue: 80% del budget IT speso in manutenzione 19 20

6 Manutenzione Include diversi fattori di cambiamento hcorrezione hevoluzione (adattamento o perfezionamento) Terminologia (e fenomenologia) hmanutenzione correttiva 20% non sono rispettate le specifiche hmanutenzione adattativa 20% hmanutenzione perfettiva 50% Perché il software evolve? Mutamenti nel contesto (man. evolutiva di tipo adattativo) hintroduzione dell'euro Mutamenti nei requisiti o requisiti non noti precedentemente (man. perfettiva) hl'applicazione introdotta induce nuovi fabbisogni innovazione genera innovazione hrecente indagine a livello EU 20% dei requisiti utente sono obsoleti dopo 1 anno Specifiche errate (requisiti non colti, dominio non compreso) ( (di quale manutenzione si tratta?) Distribuzione dei costi Dati ricavati da 125 progetti di Hewlett Packard, escludendo consegna e manutenzione : h18% requisiti e specifica h19% progetto h34% codifica h29% testing variazioni tipiche del 10% I malfunzionamenti (e gli errori che li causano) osservazioni dalla pratica Ci si puo' aspettare che il software consegnato contenga un numero di errori = 10% degli errori trovati durante il test Errori introdotti presto (p. es. errata analisi) sono scoperti tardi, e più tardi vengono scoperti più costosa è la loro rimozione Numero di errori dipende dalla complessita` della struttura interna (intesa come flusso di controllo) Eliminare errori da software di grande dimensione e maturo (risultato di molti interventi manutentivi) ) costa di più (fino a volte) di quanto costi intervenire su software piccolo e nuovo La rimozione di errori causa l'introduzione di nuovi errori Sistemi di grande dimensione tendono a stabilizzare il numero di errori presenti 23 24

7 Risposte Come gestire prodotti che evolvono continuamente e rapidamente? Metodi di progetto hcercare di anticipare i cambiamenti hprogettare il software in modo da facilitare le modifiche successive in maniera economica ed affidabile isolare le parte soggette a cambiamento all'interno di moduli, nascondendole all'esterno (incapsulamento,, information hiding) p.es. funzione C di cui mi basta conoscere nome e parametri,, ma l'algoritmo e` nascosto concetto di tipo di dato astratto Processo halternative al ciclo di vita waterfall, che spesso ha grossi problemi (vediamo ora perche`) Analisi e Specifica dei Requisiti Progetto Implementazione e Test Test di Accettazione Messa in Esercizio Modifica e manutenzione Ciclo di vita a cascata Si articola in un insieme di fasi che vengono attivate in rigida sequenza senza ricicli h Nato negli 60 e 70: Sviluppo di software su grossi mainframe Pochi strumenti automatici di supporto allo sviluppo L'attività di sviluppo era demandata a pochi specialisti h Il costo di utilizzo delle macchine giustifica una approfondita fase di pianificazione per ottimizzarne l'uso h Il dominio applicativo e i requisiti sono ben compresi h Enfatizza particolarmente l'attività di design h Tiene in minore considerazione l'attività di manutenzione Ciclo a cascata: problema 1 La manutenzione, pur così importante,, e` nascosta in una fase finale che non viene disciplinata da un processo (non viene strutturata in termini di attivita` elementari) 27 28

8 Ciclo a cascata: problema 2 Il ciclo a cascata richiede comunque un adattamento del processo allo specifico progetto Ne devono esistere ere variazioni per diverse tipologie, p.es.:.: hsoftware sviluppato per uso personale hil committente appartiene alla stessa organizzazione hsoftware "su misura" ("custom custom") sviluppato da un produttore per un committente specifico happlicazione ("pacchetto") per il mercato Ciclo a cascata: problema a 3 La cascata presuppone che il dominio sia perfettamente noto, che il committente conosca esattamente ciò che vuole, che i requisiti vengano colti correttamente e che siano stabili Questo capita molto raramente!!! Non e` possibile evitare i ricicli: sono parte essenziale del nostro mondo Riassunto critiche a modello a cascata Né realistico né pratico: h Parte del lavoro può essere svolto in parallelo (alcune parti già progettabili quando per altre si fa ancora analisi dei requisiti) h Errori nei requisiti si scoprirebbero solo a prodotto completato. h Errori trovati in una fase (es. codifica) costringono a rivedere tutte fasi precedenti (specifica, progetto) h Errori sono tanto più costosi da correggere quanto più in basso nel ciclo di vita sono identificati Serve potere effettuare ricicli h Nell'attività di sviluppo sono inevitabili ricicli in quanto non è spessp possibile identificare completamente e in modo preventivo le reali necessità dell'utente (che spesso non sa cosa vuole realmente). h Utile coinvolgere maggiormente l'utente durante l'intero ciclo di vita, ( ( trova errori nei requisiti) h Un prodotto non è mai completato ma è sempre in continua evoluzione: : i cosiddetti costi di manutenzione sono in gran parte costi di evoluzione Trasparenza e flessibilita` Occorre che il processo consenta di verificare continuamente se ciò che si sta facendo corrisponde a cio` che desidera il committente Non appena possibile, correggere rotta hprima che sia troppo tardi hprima di aver speso tutte le risorse Adattarsi ai cambiamenti, in particolare nei requisiti Flessibilità attraverso incrementalità hprocessi incrementali in cui si fornisce qualcosa al committente, che cosi` può fornire un feedback 31 32

9 Rilascio incrementale ("incremental delivery") Prototipazione Si identificano fin dall'inizio subset dell'applicazione da realizzare Su questi subset si ottiene un feedback dai committenti Spesso i subset iniziali sono quelli piu` critici per il successo dell'applicazione 33 Un prototipo e` un modello approssimato dell'applicazione Viene usato per ottenere feedback Che cosa prototipare dipende da cio` che e` critico valutare (p. es., l'interfaccia per l'utente) Un prototipo puo` essere h"usa E GETTA" ("throw throw-away (comune in altri settori dell'ingegneria ma relativamente poco usato nel software) h"evolutivo Nel prototipo possono mancare parti oppure i componenti posso essere realizzati in maniera preliminare L'evoluzione e` garantita dalla modularita`: : Se i cambiamenti sono confinati all'interno di un modulo e non impattano sull'interfaccia, il cambiamento puo` avvenire in maniera facilmente controllabile 34 Analisi e Specifica dei Requisiti Progetto Implementazione e Test Test di Accettazione Messa in Esercizio Ciclo di vita a spirale Consente di iterare fra le varie attività: analisi, sviluppo,, testing Iterando aumenta la probabilità di trovare e correggere errori in alto nel ciclo di vita Più adatto ai cambiamenti,, specie nei requisiti Processi incrementali,, con feedback (anche( dall utente utente), tramite prototipi evolutivi e attività di verifica svolte a ogni livello La spirale Il processo viene visto come un ciclo nel quale si iterano le attività di analisi, progetto, realizzazione/test e valutazione per successivi cicli Ad ogni ciclo, il costo (raggio della spirale) aumenta costo Modifica e manutenzione 35 36

10 Il ciclo di vita dei prodotti innovativi Esempio: i nuovi prodotti per Internet Qui l'incrementalit incrementalità è fondamentale Incrementalità implica rapida uscita sul mercato e fidelizzazione dei clienti Non esistono, spesso, requisiti da cogliere Spesso si tratta di "creare" una domanda Si creano versioni iniziali di prova da lanciare come "versioni beta" La rete stessa è sia la "vetrina" dei prodotti che il mezzo distributivo Cicli di vita e attivita` I diversi cicli differiscono nel modo e nell'ordine in cui le diverse attivita` vengono eseguite Le diverse attivita` analisi, specifica, progettazione, implementazione, test in modi diversi e secondo fasi diverse, vanno comunque fatte!!! 37 38