Dall analisi dei requisiti alla specifica della soluzione

Transcript

1 Dall analisi dei requisiti alla specifica della soluzione G.Raiss - 4 maggio 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 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

2 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 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 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

3 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 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 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

4 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 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 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

5 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 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 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

6 Modelli del CVS G.Raiss - 4 maggio Modelli del ciclo di vita A cascata (sequenziale) Prototipale Rapid Application Development (RAD) Incrementale Spirale A componenti G.Raiss - 4 maggio Modello a cascata Sequenza del modello a cascata (Waterfall) ANALISI DISEGNO CODIFICA TEST MAC/MEV G.Raiss - 4 maggio

7 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 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 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

8 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 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 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

9 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 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 Design Code Bad fixes Total Efficienza rimozione difetti 85% 85% 80% Difetti residui per FP 0,72 0,66 1,02 G.Raiss - 4 maggio 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

10 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 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 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

11 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 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 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

12 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 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 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

13 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 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 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 Modello di Boehem Evoluzione

14 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 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 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

15 .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 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 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

16 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 ( Microsoft/COM (Component Object Model) ( In genere questi standard definiscono regole per le interfacce e lo scambio di informazioni tra interfacce G.Raiss - 4 maggio 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 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

17 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 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