Dall analisi dei requisiti alla specifica della soluzione G.Raiss - 4 maggio 2001 1 IL processo di produzione del sw Passando da un approccio artigianale ad uno industriale nello sviluppo del software, si è compreso che per gestire la complessità del processo di produzione lo si doveva scomporre in attività di dettaglio, più facilmente gestibili. Produzione sw Astrazione Divide et impera Progettare Codificare Testare Installare G.Raiss - 4 maggio 2001 2 Passi della scomposizione I passi della scomposizione: decomposizione in fasi, ed individuazione delle relazioni tra le fasi definizione dei prodotti in ingresso ed uscita dalle fasi (i semilavorati) scelta dei metodi da adottare per svolgere le attività scelta delle tecniche e dei modelli con cui descrivere i prodotti delle fasi G.Raiss - 4 maggio 2001 3
Il concetto di fase Le attività da svolgere per costruire un prodotto possono essere aggregate in base a criteri di coerenza logica e/o temporale Un determinato livello di aggregazione coerente di attività è una fase Ogni fase dipende dai dati in ingresso provenienti in uscita dalla fase che la precede, e produce i dati necessari a determinare la fase che la segue G.Raiss - 4 maggio 2001 4 Le fasi sono tra loro correlate I risultati conseguiti in ogni fase dipendono anche dai risultati conseguiti nella fase che la ha preceduta. Un prodotto mal progettato (ad esempio con poca attenzione alle esigenze dell utente), anche se viene poi realizzato perfettamente conforme alle specifiche date dalla progettazione, non risponderà alle aspettative dei clienti e sarà rifiutato o dovrà essere rilavorato. G.Raiss - 4 maggio 2001 5 Il ciclo di vita Il ciclo di vita del software (o di un sistema informativo) è una successione ordinata di fasi (o attività), che hanno relazioni tra loro Il CVS è lo schema secondo il quale le attività sono organizzate Riflette la filosofia di approccio al problema di produrre sw ma anche le condizioni al contorno nelle quali si opera. G.Raiss - 4 maggio 2001 6
Il ciclo dei S.I. nel D.Lgs 39/93 Il D.Lgs 39/93 ha disegnato un ciclo di vita dei S.I. della P.A. utilizzando un Plan Do Check Act approccio PDCA Definire le azioni conseguenti Act Plan Pianificare la qualità Anno n Plan Do Check Act Check Do Autovalutazione Pianificazione Miglioramento Annon+1 Consuntivare Realizzare la qualità G.Raiss - 4 maggio 2001 7 Il ciclo dei S.I. nel D.Lgs 39/93 (2) Le Amministrazioni definiscono le loro esigenze nei Piani triennali, le traducono in Studi di Fattibilità ed in progetti di adeguamento. I fornitori attuano quanto richiesto dai clienti. Al termine di ogni anno viene effettuato un Consuntivo di quanto realizzato, che rappresenta il momento di diagnosi dei problemi, cui segue la. analisi delle aree di possibile miglioramento e l avvio di una nuova fase di programmazione e pianificazione di progetti volti a superare i problemi. G.Raiss - 4 maggio 2001 8 Il ciclo dei S.I. nel D.Lgs 39/93 (5) Esigenza innovazione Analisi Piano strategico Diagnosi Requisiti Utente Consuntivazione Programmazione Budget Studio Fattibilità Requisiti Contesto Offerta tecnica Direzione Lavori / Monitoraggio Documenti di Riscontro Collaudo Schema di PARERE Contratto ex D. lgs ATTUAZIONE 39/93 Prodotti Servizi G.Raiss - 4 maggio 2001 9
Il ciclo dei S.I. nel D.Lgs 39/93 (6) Pianificazione strategica Piano strategico obiettivi e fattori critici, stato della automatazione scelte da effettuare (tecnologiche e gestionali) architettura tecnicoorganizzativa, vincoli ( normativi, temporali, spaziali, economici etc..), priorità, i progetti, stima di massima dei costi Documenti di riscontro progetto di massima e di dettaglio della soluzione tecnico- organizzativa, MdQ, PdQ, Piano di gestione della configurazione ed altri piani correlati al PdP specifiche generali e di realizzazione del S.I. (prodotti, servizi, infrastrutura. tecnologica) e dei benefici Programmazione Studio di fattibilità Gara Offerta tecnica individuazione di massima delle necessità, progetto di massima e di dettaglio della soluzione tecnicoorganizzativa, Attuazione analisi dell impatto della soluzione scelta, analisi dei costi e benefici, indicazioni di massima per il capitolato, documenti di riscontro per il monitoraggio Realizzazione Definizione Piano esecutivo delle attvità, definizioni di dettaglio dei documenti di Documenti di riscontro Manutenzione Aggiornamento Piano esecutivo delle attvità, documenti di riscontro riscontro, G.Raiss - 4 maggio 2001 10 Le fasi del processo di produzione Tutti i modelli di produzione attraversano queste fasi: Pianificazione Analisi/Specifica/Progettazione Realizzazione Installazione/Messa in esercizio Gestione/Manutenzione Dismissione Correttiva Adattativa Perfettiva Migliorativa Preventiva Evolutiva G.Raiss - 4 maggio 2001 11 Distribuzione dell impegno nelle fasi Da dati HP su 125 progetti Analisi: 18% Progettazione: 19% Codifica: 34% Test: 29% Gestione/Manutenzione: 50-70% dei costi della realizzazione G.Raiss - 4 maggio 2001 12
Costo delle fasi Incidenza di ogni fase sui costi del software (Bloor research): Analisi requisiti 3% Progettazione 8% Codifica 7% Testing 15% Manutenzione 67% G.Raiss - 4 maggio 2001 13 Livelli di descrizione del sistema Alle diverse fasi corrisponde un diverso livello di descrizione del sistema Pianificazione Rappresenta il prodotto dal punto di vista del manager, interessato al suo costo, alla sua compatibilità con il contesto, alla tempestività con cui ne disporrà Analisi livello dei requisiti utente rappresenta il prodotto dal punto di vista dell utente. Si usano schemi procedurali (sequenza attività ed informazioni elaborate) e schemi informativi (struttura e contenuto delle informazioni da elaborare). E una vista concettuale G.Raiss - 4 maggio 2001 14.livelli di descrizione. (2) Progettazione Rappresenta una vista concettuale di come il prodotto deve soddisfare i requisiti, senza entrare nel merito degli aspetti tecnologici (ambiente operativo, linguaggio etc..) Codifica livello del software rappresenta la traduzione degli algoritmi e delle procedure definite nella fase progettuale, in un linguaggio di programmazione Questi due livelli rappresentano il sistema dal punto di vista tecnico, del produttore di software, del fornitore G.Raiss - 4 maggio 2001 15
Modelli del CVS G.Raiss - 4 maggio 2001 16 Modelli del ciclo di vita A cascata (sequenziale) Prototipale Rapid Application Development (RAD) Incrementale Spirale A componenti G.Raiss - 4 maggio 2001 17 Modello a cascata Sequenza del modello a cascata (Waterfall) ANALISI DISEGNO CODIFICA TEST MAC/MEV G.Raiss - 4 maggio 2001 18
Prodotti del modello a cascata ANALISI/SPECIFICA Cosa si vuole realizzare Definizione dei requisiti DISEGNO/PROGETTAZ. Come si vuole realizzare (il progetto del sistema) Architettura (statica e dinamica) MAC/MEV Gestione modifiche Codice modificato CODIFICA Traduzione degli algoritmi logici in istruzioni di un linguaggio Sorgenti, manuali TEST Verifica di Conformità, test di modulo e di integrazione Errori, azioni correttive G.Raiss - 4 maggio 2001 19 Problemi del modello a cascata (1) Il modello a cascata intende, alla fine di una sequenza lineare di attività, consegnare il prodotto. Non sono previsti ritorni all indietro tra le fasi In realtà, i progetti reali raramente seguono il flusso sequenziale proposto dal modello, spesso è necessario iterare fasi e/o attività è difficile per il cliente dichiarare tutti i requisiti in modo esplicito. Il modello a cascata ha difficoltà a gestire la naturale incertezza che esiste all inizio di nuovi progetti G.Raiss - 4 maggio 2001 20 Problemi del modello a cascata (2) il cliente deve avere pazienza, una versione funzionante del sistema non potrà essere disponibile se non nelle ultime fasi del ciclo di vita (scoprire un errore in questa fase può avere conseguenze disastrose) Il lavoro degli sviluppatori è spesso inutilmente ritardato dall attesa del completamento della fase precedente (il tempo di attesa complessiva può superare il tempo di lavoro!!!) G.Raiss - 4 maggio 2001 21
Documentazione delle fasi Le fasi del processo waterfall sono naturalmente descritte in termini di: Attività e prodotti intermedi prodotti dalle fasi Responsabilità e ruoli riguardo le attività Scadenze Dipendenze causali e temporali tra le fasi G.Raiss - 4 maggio 2001 22 Documenti prodotti dal mod. waterfall Activity Output documents Requirements analysis Feasibility study, Outline requirements Requirements definition Requirements document System specification Functional specification, Acceptance test plan Draft user manual Architectural design Architectural specification, System test plan Interface design Interface specification, Integration test plan Detailed design Design specification, Unit test plan Coding Program code Unit testing Unit test report Module testing Module test report Integration testing Integration test report, Final user manual System testing System test report Acceptance testing Final system plus documentation G.Raiss - 4 maggio 2001 23 Modello prototipale Versione validata Start 1ma vers. prototipo OK Test con L utente Qualcosa da cambiare Nuova versione prototipo Definizione modifiche L approccio prototipale si propone di sviluppare il software attraverso successive versioni, più o meno complete, del prodotto, presentate via via all utente G.Raiss - 4 maggio 2001 24
Tipi di prototipo Disposable prototype: implementa solo alcune delle funzionalità, tipicamente le interfacce, poi si getta (Throw away) Time box prototype: è una replica abbstanza completa, ma in piccolo, del prodotto finale, e si getta Evolutionary prototype: evolve nel prodotto finale G.Raiss - 4 maggio 2001 25 Tipi di prototipo - Impegno Disposable prototype: 5-10% del volume del prodotto finito Time box prototype: 14-15% Difetti per progetto Fase Media progetti Media Dispos. prot. Media Evolut. Prot. Requirements 1.00 0.8 0.8 Design 1.25 1.15 1.4 Code 1.5 1.45 1.8 Bad fixes 0.6 0.6 0.7 Total 4.75 4.4 5.1 Efficienza rimozione difetti 85% 85% 80% Difetti residui per FP 0,72 0,66 1,02 G.Raiss - 4 maggio 2001 26 Uso tipologie di prototipo Disposable prototype: è utile quando è necessario ridurre al minimo i rischi di non completa cattura dei requisiti (sistemi critici) Evolutionary: da usare quando non è possibile separare chiaramente le fasi di specifica e sviluppo, ad es. nei sistemi di intelligenza artificiale o basati principalmente su interfacce uomomacchina G.Raiss - 4 maggio 2001 27
Vantaggi dei prototipi Coinvolgere il cliente/utente Scoprire fraintendimenti col cliente Far emergere funzionalità/servizi non considerati o chiarirli meglio Rilasciare presto una versione del sistema, magari ridotta, che dà fiducia al cliente sulla riuscita del progetto Scrivere meglio le specifiche di qualità del sistema finito G.Raiss - 4 maggio 2001 28 Rischi dei prototipi Potrebbero allungare i tempi di sviluppo e aumentare la dinamica dei requisiti Inducono nella tentazione di riutilizzare quanto più possibile del lavoro già fatto Nel caso di prototipi fatti evolvere nei prodotti finali, spesso il codice non più utilizzato non viene cancellato: aumenta il volume e la complessità strutturale del prodotto G.Raiss - 4 maggio 2001 29 Linguaggi per prototipi Alcuni linguaggi di programmazione sono orientati alla prototipazione ed offrono tools di supporto Ad es. SMALLTALK è un linguaggio adatto a prototipare sistemi interattivi ed include appositi tool di supporto per generare interfacce grafiche (disegnare l interfaccia e simularne le funzionalità) E possibile costruire prototipi incollando pezzi di sistemi già esistenti (riutilizzo) G.Raiss - 4 maggio 2001 30
RAD (Rapid Application Development) E un modello di sviluppo sequenziale lineare, che punta a concludere il progetto in tempi brevi Per abbreviare i tempi si ricorre al riuso di componenti (già collaudate) ed al lavoro di più team in parallelo Vincoli: requisiti chiari e complessità limitata del progetto (tecnologia nota ed affidabile) Il sistema deve essere scomponibile in moduli, sviluppabili anche in parallelo Si devono usare linguaggi di 4th gen., tools CASE e prototipi G.Raiss - 4 maggio 2001 31 Modello RAD Problema ANALISI DISEGNO ANALISI CODIFICA DISEGNO TEST ANALISI DISEGNO CODIFICA TEST Team 1 Team 3 CODIFICA TEST Team 2 Prodotto G.Raiss - 4 maggio 2001 32 Modello RAD con prototipi Start Stop Start Integrazio ne Raccolta e rifinitura requisiti Stop Disegno Start I ntegraz ione Rifini tura Requi siti Valutaz ione Diseg no Costru zione Stop Integrazione Raccolta e rifinitura requisiti Rifinitura prototipo Valutazion e prototipo Costruzio ne prototipo Disegno Rifinitura prototipo Costruzio ne Valutazion prototipo e prototipo G.Raiss - 4 maggio 2001 33
Problemi del modello RAD Le componenti devono essere facilmente integrabili L analista deve conoscere molto bene il dominio applicativo Il lavoro dei team deve fasarsi con precisione La collaborazione del cliente è fondamentale G.Raiss - 4 maggio 2001 34 Modello Incrementale/evolutivo Simile al prototipale, ma i prodotti intermedi sono funzionanti ANALISI DISEGNO CODIFICA TEST Vers. 1a ANALISI DISEGNO CODIFICA TEST Vers. nma L obiettivo è evolvere verso il prodotto finale a partire da specifiche di massima, iniziando da quelle parti che sono meglio specificate ed aggiungendo via via nuove funzionalità G.Raiss - 4 maggio 2001 35 Modello Incrementale/evolutivo. Vantaggi Il prodotto è scomposto in sotto prodotti ed anche il processo può essere spezzato di conseguenza Si può iniziare a lavorare sulle parti più critiche, dove serve un rapido feedback da parte del cliente Gli utenti possono incominciare a provare delle parti rilasciate, mentre le altre sono ancora in sviluppo G.Raiss - 4 maggio 2001 36
Modello a spirale Il modello a spirale (Bohem, 1988) combina la natura iterativa della prototipazione e quella sistematica e controllata del modello lineare-sequenziale Il software viene sviluppato in versione sempre più raffinate. Si può partire anche da un prototipo cartaceo Il modello prevede 4 (o 6) fasi (dette task regions), per ognuna delle quali sono definite delle attività specifiche. Le attività da svolgere variano secondo la complessità del progetto G.Raiss - 4 maggio 2001 37 Modello a spirale - Boehm Determina obiettivi alternative, vincoli Analisi del rischio Valuta alternative identifica e risolvi rischi Analisi del rischio Pianifica le fasi successive Piano dei requisiti e del ciclo Piano di sviluppo Piano di integrazione e prove Analisi del rischio Prototipo operativo Prototipo3 Prototipo1 Prototipo2 Simulazioni Modelli Benchmarks Requisiti del software Progetto di Progetto del dettaglio prodotto Convalida dei software requisiti Convalida e verifica del progetto Rilascio del prodotto Prove di accettazione Integrazione e prove Test di modulo Codifica Sviluppa e verifica il successivo livello di prodotto G.Raiss - 4 maggio 2001 38 raccolta requisiti iniziale 1) Interazione con l` utente Modello a spirale (Bohem) 2) Planning 6) valutazione da parte del cliente 3) Risk analysis 5) Realizzazione 4) Ingegnerizza zione determinazione obiettivi e vincoli pianificazione fase successiva 1 2 valutazione alternative identificazione rischi sviluppo e verifica G.Raiss - 4 maggio 2001 39 4 3 Modello di Boehem Evoluzione
Modello a spirale: il percorso Le attività vanno svolte a partire dall inizio del progetto, seguendo la spirale in senso orario Ad ogni giro corrisponde un raffinamento: al primo le specifiche, al secondo un semplice prototipo, poi prototipi sempre più completi Il modello si può applicare anche a progetti di manutenzione migliorativa-evolutiva G.Raiss - 4 maggio 2001 40 Modello a spirale - Considerazioni Rappresenta una razionalizzazione del modello prototipale Si presta alla gestione di progetti complessi Concentra l attenzione sugli obiettivi Può essere integrato con altri approcci (modello ad assemblaggio dei componenti) Alcuni CASE tool lo supportano Facilita l eliminazione degli errori G.Raiss - 4 maggio 2001 41 Sviluppo a componenti L approccio più recente allo sviluppo del software si può riassumere come comprare, non costruire Nel modello CBD (Component Based Deveopment) sono integrati i vantaggi dei modelli evolutivi ed iterativi Domande da porsi: Esistono componenti commerciali (o sviluppate in proprio) pronte all uso per soddisfare i requisiti? Le interfacce sono compatibili con l architettura del sistema? G.Raiss - 4 maggio 2001 42
.Sviluppo a componenti.. Attività del team: Qualifica dei componenti Definire le caratteristiche delle componenti riutilizzabili in base alle caratteristiche dell interfaccia, uso risorse, sicurezza, tecnologiche, requisiti di S.O. Adattare i componenti Le componenti selezionate (sono unità di funzionalità) vanno adattate alle regole di coordinamento e connessione definite nella architettura del sistema Composizione dei componenti integrare le componenti secondo le regole della architettura G.Raiss - 4 maggio 2001 43 Componente: una parte di una applicazione che svolge funzionalità chiaramente identificabili Utilizzo componenti Lo sviluppo a componenti ha 2 fasi: Ingegneria del dominio: identificare le componenti applicabili nel caso specifico Sviluppo dei componenti: definire l architettura del sistema e riempirla con le componenti, disponibili o da ingegnerizzare G.Raiss - 4 maggio 2001 44 Modello di sviluppo a componenti Analisi del dominio Sviluppo architettura Sviluppo Componenti riutilizzabili Ingegneria del dominio Modello del dominio Modello Strutturale Deposito Componenti riutilizzabili Analisi Progettazione architettura Qualifica componenti Adattamento componenti Composizione componenti Aggiornamento componenti software Sviluppo a componenti Ingegneria componenti Collaudo G.Raiss - 4 maggio 2001 45
Standardizzazione di componenti Alcuni grandi produttori o consorzi hanno proposto delle regole per standardizzare componenti di largo utilizzo: OMG/CORBA: questa architettura fornisce vari servizi che consentono ai componenti di comunicare tra loro indipendentemente dalla posizione che occupano nel sistema (www.omg.org) Microsoft/COM (Component Object Model) (www.microsoft.com/com) In genere questi standard definiscono regole per le interfacce e lo scambio di informazioni tra interfacce G.Raiss - 4 maggio 2001 46 Vantaggi sviluppo a componenti Migliore Qualità Ad ogni riutilizzo di componenti si individuano ed eliminano sempre più difetti Tasso medio di difetti nel codice riutilizzato: 0,9 per Kloc vs 4,1 nel codice di nuovo sviluppo (dati HP 1994) Riutilizzando il 68% del codice, la difettosità sale a 2 difetti per Kloc Maggiore produttività Con tassi di utilizzo del 30-50% la produttività sale del 25-40% (Pressman) G.Raiss - 4 maggio 2001 47 Re-Engineering Quando si sviluppa ex novo si parla di forward engineering E possibile sviluppare un sistema partendo da uno esistente, ma inadeguato, documentando quanto esiste (reverse engineering) e poi completandolo con le parti mancanti Reverse engineering + Forward engineering = Re-engineering G.Raiss - 4 maggio 2001 48
Comparazione dei modelli Modello a cascata Rischioso per sviluppare sistemi su cui non si hanno pregresse buone competenze sul dominio applicativo e di business Basso rischio per sviluppare sistemi su cui si hanno conoscenze pregresse sufficienti Modello incrementale/prototipale Poco rischioso per sviluppare nuovi sistemi Altamente rischioso se è richiesto un forte controllo del processo (è antieconomico documentare eccessivamente le attività svolte) G.Raiss - 4 maggio 2001 49 Comparazione utilità dei modelli Warefall Increme ntal Prototyp ing Spiral RAD Project Complexity Medium High Medium High Medium Understanding of user requirements Requirements volatility Product technology Risk management perspective Schedule constraints Problem domain Knowledge Specific Specific/v ague Vague Vague Specific Low Low High Medium Low Existing Existing/n ew new new new No No YES YES No Medium High Low/Medi um High Medium/hi gh Medium High Poor Poor High G.Raiss - 4 maggio 2001 50