Ingegneria del Software. MINR a.a Prof. Giuseppe Santucci. 01- Introduzione

Transcript

1 Ingegneria del Software MINR a.a Prof. Giuseppe Santucci 01- Introduzione 01Intro.1 Informazioni generali sul corso Sommario Cenni storici, problemi dello sviluppo del software, concetti generali e definizioni (prodotto / processo) Standard per la qualità Modelli per il ciclo di vita del software 01Intro.2

2 Ingegneria del Software a.a Orario - Aula 5 - Via Ariosto 25 martedì giovedì N.B. : Nel secondo semestre si svolgerà una edizione analoga del corso in inglese Il programma e le modalità d'esame dei due corsi sono IDENTICI Per entrambi i corsi è prevista una prova da 5 e da 6 crediti 01Intro.3 Appelli d'esame Date appelli: Due appelli ordinari a gennaio-febbraio Due appelli di recupero giugno-luglio Un appello di recupero a settembre N.B. I due appelli ordinari sono mutuamente esclusivi 01Intro.4

3 Testi di riferimento Roger S. Pressman : Software Engineering A Practitioner s approach 4th ed. Mc Graw Hill (European adaption ISBN ) (o analoga edizione italiana) N.B. Non è il testo del corso Lucidi e/o dispense N.B. %7E corrisponde alla tilde ~ 01Intro.5 Forme di comunicazione Ricevimento : mercoledì Via Ariosto 25 secondo piano stanza B218 santucci@dis.uniroma1.it telefono? Solo durante l orario di ricevimento MTBF: lezioni >= 2300 g ricevimento studenti >=30 g Consultare SEMPRE la sezione AVVISI Martedì 6 ottobre NON ci sarà lezione 01Intro.6

4 Modalità di esame Prova scritta Esercizi e domande a risposta multipla (NEW!) Sul sito saranno resi disponibili alcuni esempi di compiti di esame Saranno erogate e verbalizzate due prove scritte distinte: 5 crediti 6 crediti 01Intro.7 Programma di massima (5 & 6 crediti) Il processo di produzione del software Introduzione e definizioni preliminari Modelli per il ciclo di vita del software Qualità del prodotto e del processo Standard per la qualità Project management (esercizi di esame) Metodologie di test Test a scatola bianca(esercizi di esame) Test a scatola nera (esercizi di esame) Economia del software Metriche e metodologie di stima delle risorse Il metodo COCOMO II e dei punti funzione (esercizi di esame) Analisi e specifica dei requisiti Definizioni preliminari: fase di analisi ed attività di specifica Tipologie di applicazioni e tipologie di linguaggi di specifica Tipologie di modelli Richiami di UML (Unified Modeling Language) Fondamenti della teoria della misura (esercizi di esame) Solo per 6 crediti Definizioni e richiami di concetti statistici di base Qualita' di una misura ed errori sistematici ed errori casuali Statistica inferenzialeanalisi della varianza (ANOVA) Esercitazioni 01Intro.8

5 IL PRODOTTO 01Intro.9 Prospettiva storica della produzione del software prima era (Paleozoico) batch, distribuzione limitata, software ad hoc seconda era (Mesozoico) multiuser, Real-Time, Database, software prodotto terza era (Cenozoico) sistemi distribuiti, hardware low-cost (PC IBM), mercato di massa quarta era (Terziario) OO technologies, sistemi user friendly, Powerful PC quinta era (Quaternario) Internet, distributed computing CORBA-DCOM, component-ware, J2EE, web services,... 01Intro.10

6 Prospettiva storica del costo del software sviluppo manutenzione Andamento esponenziale della spesa per il SW 01Intro.11 Prospettiva storica del costo del sw costo sw / costo hw Intro.12

7 Ripartizione del costo del software 15% 80% manutenzione sviluppo 20% 46% verifica e validazione manutenzione e modifiche prog. e analisi codifica documentazione 20% 9% 10% % costo totale % costo di sviluppo Ripartizione dei costi totali tra manutenzione (dopo la consegna) e sviluppo Ripartizione dei costi di sviluppo tra: analisi, progetto, codifica, documentazione, verifica e manutenzione (interna) 01Intro.13 Software? Software: Creazione dell intelletto che include programmi, strutture dati, documentazione. L esecuzione dei programmi realizza (sperabilmente) le funzionalità previste Prodotto Software: Insieme completo di programmi, procedure e relativa documentazione rilasciato ad un utente Componente Software: Ogni parte identificabile di un prodotto software, sia in uno stadio intermedio del processo di sviluppo, che al termine di esso 01Intro.14

8 Caratteristiche del software Il SW e sviluppato e non costruito come un qualsiasi prodotto industriale (e.g., un monitor) Il SW non si consuma Il SW non è (era) realizzato utilizzando componenti preesistenti 01Intro.15 Prodotto industriale vs. prodotto software Prodotto Industriale Definito il progetto e il processo di produzione del bene si può delegare la produzione a strutture esterne senza influenzarne il risultato I parametri e le tecniche usate per descrivere un prodotto sono consolidate, affidabili ed efficaci Prodotto Software A partire da una specifica comune delegare la realizzazione a diversi soggetti porta alla realizzazione di prodotti totalmente diversi La descrizione delle caratteristiche funzionali, e di qualità del prodotto software rimane un problema aperto 01Intro.16

9 Prodotto industriale vs. prodotto software (2) Prodotto Industriale Sono possibili economie di scala e processi di produzione e distribuzione diversificati in funzione delle dimensioni del mercato a cui il prodotto si rivolge Prodotto Software Non è distinguibile la produzione su piccola scala da quella su larga scala. Esiste una attività di revisione ed aggiornamento non comparabile con quella dei prodotti tradizionali. 01Intro.17 Deterioramento e guasti hw e sw % guasti hw % guasti sw (teoria) tempo tempo % guasti sw Cambiamenti sw tempo 01Intro.18

10 Componenti sw e riusabilità Il concetto di componente software riusabile è apparso da poco all orizzonte È strettamente collegato ai linguaggi Object Oriented (OO) (Java, C++) Alto riuso di componenti per la costruzione di interfacce grafiche (Graphical User Interface o GUI) 01Intro.19 Macroclassificazione delle applicazioni sw Sistemi operativi e software di sistema sw di servizio Real time software vincoli precisi sui tempi di risposta Sistemi informativi dati, dati, dati Software scientifico numeri, numeri, numeri Software nascosto ascensori, lavatrici, telefoni, automobili, ecc.. PC software 01Intro.20

11 Crisi o affezione cronica? La disponibilità di hw potente e a basso costo spinge verso la produzione di sistemi software sempre più complessi, la cui gestione diventa sempre più difficile Nel 1985 Dave Parnas, uno dei massimi esperti di ingegneria del software mondiali, membro di una commissione istituita dal ministero della difesa degli Stati Uniti (presidenza Regan) per l analisi della parte informatica del programma noto come guerre stellari si dimette. Nella motivazione pubblica delle sue dimissioni afferma che le odierne conoscenze e tecnologie non sono in grado (e non lo saranno in breve tempo) in grado di affrontare problemi così complessi 01Intro.21 Ingegneria del software Il termine nasce nel 1968 in una conferenza NATO È la disciplina il cui scopo è dare un approccio sistematico alla produzione, alla manutenzione ed alla evoluzione del prodotto del software L ingegneria del software comprende: modelli astratti e teorie di base metriche metodi e processi di produzione e di test tecnologie e strumenti sensibilità pratica obbiettivi da raggiungere (e.g., qualità del sw, standard ISO 9126) 01Intro.22

12 IL PROCESSO 01Intro.23 Ciclo di vita del software Nel corso degli anni, nel passaggio dalla visione artigianale alla visione industriale del software, si è compreso che il processo andava formalizzato attraverso: un insieme di fasi in cui decomporlo, un insieme di prodotti delle varie fasi, un insieme di metodi da adottare nelle varie fasi, un insieme di tecniche e/o modelli con cui descrivere i prodotti delle fasi 01Intro.24

13 Attività trasversali Controllo/gestione del progetto Revisioni tecniche del progetto Controllo di qualità Gestione della configurazione Versioni, locazione dei file, iter di modifica, approvazioni... Gestione della documentazione Template, iter di approvazione, lista di distribuzione... Gestione della riusabilità Usare sw prodotto da altri Individuare sw prodotto in casa potenzialmente riutilizzabile Misure Gestione dei rischi 01Intro.25 Fasi essenziali del processo di produzione sw Progetto Sviluppo Manutenzione correttiva (20%): risoluzione di errori adattativa (20%): cambiamenti/aggiunte di specifiche perfettiva (50%) migliorativa: req. non funzionali (spazio, tempo) evolutiva: req. funzionali secondari preventiva(10%) rendere più semplice la individuazione di errori tramite miglioramenti del codice (ristrutturazione, pulizia, ecc.) 01Intro.26

14 Standardizzazione del processo CMMI origine accademica voluto dal ministero della difesa americano (Department Of Defense DOD) valuta le capacità di chi sviluppa ISO prodotto da una organizzazione internazionale razionalizza le attività coinvolte è piuttosto datato ISO 9000 pensato per un qualunque processo produttivo aggiornato nel 2000 (Vision 2000) 01Intro.27 Capability maturity model integration (CMMI) Nel 1987 il Software Engineering Institute (SEI) della Carnegie Mellon University, ha sviluppato un modello per valutare i potenziali fornitori di Sistemi Software (CMM) Revisionato nel 2001 CMMI (versione attuale 1.2, 1.3 a breve) Basato su cinque possibili valori, in grado di fornire al committente un indicatore della capacità e grado di maturità di una organizzazione Ad ogni livello successivo al primo sono associate le aree di processo chiave su cui l'organizzazione deve insistere per attestarsi su quel livello 01Intro.28

15 Livello 1 - Iniziale Il sw prodotto è caratterizzato dall'essere costruito "ad hoc", seguendo strategie occasionali e caotiche Solo alcuni processi produttivi sono ben definiti ed i successi dipendono solo da sforzi individuali Solo alcuni processi produttivi sono stabili 01Intro.29 Livello 2 - Ripetibile I processi di gestione (project management) dei progetti più importanti sono definiti in modo da: Permettere la loro pianificazione Tenere traccia dei costi (tempo e denaro) L'obbiettivo principale è poter riprodurre le stesse condizioni che hanno portato al successo in applicazioni precedenti Aree di processo chiave: Gestione dei requisiti Pianificazione dei progetti sw Tracciabilità e visibilità dei progetti Gestione dei subappalti Assicurazione della qualità del sw Gestione della configurazione del sw 01Intro.30

16 Livello 3 - Definito Il processo di produzione del SW segue standard ben precisi ed è documentato ed integrato in una visione aziendale unica Tutti i progetti utilizzano una versione approvata e documentata di processi organizzativi per lo sviluppo e la manutenzione del software Aree di processo chiave: Definizione e standardizzazione dei processi organizzativi Coordinamento intergruppo Confronti e verifiche Programmi di formazione 01Intro.31 Livello 4 - Gestito Collezione di misure dettagliate sui processi di produzione e sui prodotti Aree di processo chiave: Misure ed analisi di processo Gestione della qualità 01Intro.32

17 Livello 5 - Ottimizzante Miglioramento continuo del processo tramite: feed-back quantitativi introduzione di tecnologie innovative (sviluppo, test, documentazione, ecc.) Aree di processo chiave: Prevenzione dei difetti Innovazioni tecnologiche Gestione del processo di cambiamento 01Intro.33 CMM: Punti da ricordare + La metrica del livello di maturità è molto istruttiva: spiega come un organizzazione dovrebbe muoversi verso l alto + La metrica è riconosciuta come standard industriale e permette confronti - Il processo di valutazione (assessment) per determinare il livello di maturità misura l esistenza di certi standard e non la qualità o l efficacia di tali standard - Non è previsto un piano implementativo per ottimizzare il passaggio a livelli più alti - La qualità è definita dal SEI, non dalla componente dell organizzazione dedita allo sviluppo del sw - Il 70% delle software house è a livello 1 -- O sotto... 01Intro.34

18 CAPABILITY IMMATURITY MODEL - CIM 0. Negligent (Indifference) Failure to allow successful development process to succeed. All problems are perceived to be technical problems. Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process. Reliance on silver pellets. -1. Obstructive (Counter Productive) Counterproductive processes are imposed. Processes are rigidly defined and adherence to the form is stressed. Ritualistic ceremonies abound. Collective management precludes assigning responsibility. -2. Contemptuous (Arrogance) Disregard for good software engineering institutionalized. Complete schism between software development activities and software process improvement activities. Complete lack of a training program. -3. Undermining (Sabotage) Total neglect of own charter, conscious discrediting of peer organizations software process improvement efforts. Rewarding failure and poor performance. 01Intro.35 ISO Le idee SEI hanno influenzato lo sviluppo di alcuni standard ISO tra cui l' ISO/IEC definisce e sistematizza tutte le attività convolte nel processo di produzione sw. è basato su di un approccio funzionale ai processi produttivi: insieme di attività coordinate che trasformano un ingresso in una uscita 5 processi primari che riguardano i 5 agenti primari ovvero acquirente, fornitore, sviluppatore sw, gestore, manutentore; 8 processi di supporto agli altri processi (documentazione, configurazione, qualità, ecc.) 4 processi organizzativi, usati per stabilire e implementare una struttura costituita da processi e personale e migliorare in modo continuo sia la struttura che i processi 01Intro.36

19 5. Processi primari del ciclo di vita 5.1 Acquisizione 5.2 Fornitura I processi ISO Processi di supporto 6.1 Documentazione 6.2 Gestione della Configurazione 6.3 Assicurazione di qualità 6.4 Verifiche 5.3 Sviluppo 5.4 Esercizio 5.5 Manutenzione 6.5 Validazioni 6.6 Riesami congiunti 6.7 Ispezioni 6.8 Risoluzione dei problemi 7. Processi organizzativi del ciclo di vita 7.1 Management 7.2 Infrastrutture 7.3 Miglioramenti 7.4 Addestramento 01Intro.37 Le 13 attivita` dello sviluppo SW 5. Processi primari del ciclo di vita 5.3 Sviluppo Implementazione del processo Analisi dei requisiti del S.I. Progettazione dell architettura del S.I. Analisi dei requisiti del sw Progettazione dell architettura del sw Progettazione di dettaglio del sw Codifica e testing del sw Integrazione del sw Test sulla qualità del sw Integrazione del sistema(hw + sw) Test sulla qualità del sistema Installazione del sw Supporto per il collaudo di accettazione del sw 01Intro.38

20 Lo standard ISO 9000 (2000) 01Intro.39 Motivazioni per la stesura della normativa ISO 9000 La famiglia di norme ISO 9000 fornisce le regole manageriali/organizzative e di processo che le organizzazioni operanti nel settore manifatturiero e/o dei servizi dovrebbero seguire per rendere razionali, efficienti, efficaci ed affidabili le attività del loro ciclo produttivo La ISO 9000 è stata emessa dallo International Organization for Standardization (ISO) ( fin dalla metà degli 80 (nella sua prima versione). L ultima versione è del 2000, la precedente era del Intro.40

21 Obbiettivi principali della ISO 9000 Tecnico-organizzativo: fornire un insieme di regole (concettuali) per migliorare e razionalizzare i processi produttivi Diffondere una cultura della qualità Marketing: creare nei clienti fiducia nei confronti delle organizzazioni che dimostrano di applicare bene queste regole Quest ultimo obbiettivo si raggiunge attraverso la certificazione di conformità alle regole ISO 9000 rilasciata da terze parti abilitate a farlo 01Intro.41 Livello di astrazione della ISO 9000 I requisiti ISO 9000 sono ad un livello di astrazione piuttosto alto, in quanto pensati per essere applicabili da qualsiasi organizzazione, indipendentemente dal settore merceologico o di servizi in cui opera Perciò, la ISO 9000 non entra nel merito di come vanno svolte, dal punto di vista tecnico, le attività previste dai vari processi lavorativi, ma definisce per ogni processo preso in considerazione quegli accorgimenti di natura manageriale/organizzativa che hanno maggiore influenza sul risultato finale del processo 01Intro.42

22 Dalla ISO 9001:1994 alla Vision 2000 Il sistema attuale della famiglia ISO 9000 è stato ridefinito nel dicembre 2000, attraverso il progetto denominato Vision 2000 Obiettivi della revisione: passare dalla cultura della conformità e delle evidenze a quella del continuo miglioramento, reale e misurabile dal cliente La revisione rientra nel programma quinquennale di revisione periodica delle norme emesse che la ISO persegue come politica di gestione della normativa Procedure di valutazione strettamente collegate al marchio europeo CE 01Intro.43 Le norme di assicurazione qualità Prima della versione 2000 della ISO 9001, la norma era tripartita Requisiti del cliente Sviluppo del prodotto Produzione Ispezione e test Installazione Manutenzione Assistenza ISO 9003 ISO 9002 ISO Intro.44

23 Modello dei requisiti ISO 9001: Responsabilità della direzione 4.2 Sistema Qualità 4.3 Riesame del contratto 4.4 Controllo della progettazione 4.5 Controllo dei documenti e dei dati 4.6 Approvvigionamento 4.7 Controllo del prodotto fornito dal cliente 4.8 Identificazione e rintracciabilità del prodotto 4.9 Controllo del processo 4.10 Prove, controlli, collaudi 4.11 Controllo delle apparecchiature per prove, misurazione e collaudo 4.12 Stato delle prove, controlli e collaudi 4.13 Controllo delle prove non conforme 4.14 Azioni preventive e correttive 4.15 Movimentazione, immagazzinamento, imballaggio, conservazione e consegna 4.16 Controllo delle registrazioni della qualità 4.17 Verifiche ispettive interne della qualità 4.18 Addestramento 4.19 Assistenza 4.20 Tecniche statistiche 01Intro.45 Il sistema Vision 2000 E' composto da circa 10 documenti (erano 20 nel 1994) e le norme chiave sono: 1. ISO 9000 "Sistemi di gestione per la qualità - Fondamenti e terminologia" che descrive i concetti e i fondamenti dei sistemi di gestione per la qualità e la terminologia. Sostituisce la norma ISO 8402, il vocabolario della qualità 2. ISO 9001 "Sistemi di gestione per la qualità - Requisiti" che specifica i requisiti dei sistemi di gestione per la qualità che un'azienda/organizzazione deve soddisfare per dimostrare la sua capacità di fornire prodotti che soddisfino i requisiti del cliente e di ambiti regolamentati 3. ISO 9004 "Sistemi di gestione per la qualità - Linee guida per il miglioramento delle prestazioni" che fornisce una guida sui sistemi di gestione per la qualità, inclusi i processi per il miglioramento continuativo, ai fini della soddisfazione dei clienti dell'azienda/organizzazione e delle altre parti interessate. NON è oggetto di certificazione. Sostituisce la ISO Tutte le rimanenti norme diventano dei rapporti tecnici 01Intro.46

24 Principali elementi innovativi Vision 2000 (1) 1. Impostazione della qualità aziendale orientata ai processi 2. ritagliabilità (tailoring) ovvero la possibilità di personalizzazione dei requisiti in funzione di specifici obbiettivi aziendali, o la non applicazione se non trovano riscontro nelle attività reali dell'azienda/organizzazione (n.b., la nuova normativa dice chiaramente cosa si può e cosa NON si può escludere relativamente alle attività svolte dalla organizzazione) 3. maggiore facilità d uso del modello, in modo da estendere la possibilità di valutazione del grado di applicazione dei requisiti della norma oltre gli addetti ai lavori 01Intro.47 Principali elementi innovativi Vision 2000 (2) 4. allargamento delle linee aziendali interessate al Sistema Qualità, con particolare riferimento a chi gestisce gli aspetti finanziari, manageriali, amministrativi, commerciali, di relazione con la clientela, l impatto sull ambiente etc. 5. valutazione del Sistema Qualità legata a risultati di efficacia oltre che di efficienza 6. specifici punti del modello dedicati alla rilevazione e gestione della soddisfazione del cliente 7. orientamento ai fatti ed ai dati come fattori di pianificazione degli interventi 01Intro.48

25 Come cambia la ISO 9001 (1) 1. Riduzione dei modelli di sistemi qualità da tre (ISO 9001, ISO 9002, ISO 9003) ad uno solo 2. La struttura prevede solo quattro elementi fondamentali di sistema (punti da 5, 6, 7 ed 8) rispetto ai venti elementi di sistema di gestione (punti da 4.1 a 4.20) dell'edizione Maggiore enfasi alla gestione per processi, alle esigenze e alla soddisfazione dei clienti 4. Minore enfasi alle procedure documentate 5. Maggiori prescrizioni per il miglioramento continuativo 6. Maggiore chiarezza sul ruolo dell'alta direzione o dei vertici dell'organizzazione 01Intro.49 Come cambia la ISO 9001 (2) 7. Inserimento di considerazioni sui requisiti legislativi e regolamentari 8. È richiesta la definizione di obbiettivi misurabili 9. È previsto il monitoraggio delle informazioni sulla soddisfazione del cliente 10. Maggiori indicazioni sulla gestione delle risorse 11. Indicazioni sulla determinazione dell'efficacia dell'addestramento 12. Misurazioni estese al sistema di gestione, ai processi e al prodotto e/o servizio 01Intro.50

26 I 4 processi base 1. Responsabilità della direzione, in 6 punti, tra cui attenzione focalizzata al cliente 2. Gestione delle risorse. Tra le novità: Formazione e Qualificazione 3. Realizzazione del prodotto e/o del servizio, attenzione alla qualità dei processi 4. Misure, analisi, miglioramenti. Anche qui una novità rilevante è misura della soddisfazione utente 01Intro.51 I requisiti vanno adattati I requisiti di processo definiti nella ISO 9000 devono essere adattati e personalizzati ai diversi contesti in cui operano Questa contestualizzazione produce un insieme di requisiti di processo e di risorse propri di ogni organizzazione, che ne definiscono, nel loro insieme, il sistema di gestione per la qualità (sistema qualità) Il sistema qualità di una organizzazione definisce la politica per la qualità che essa persegue, in termini di struttura organizzativa, attività, controlli, risorse, a prescindere dalle esigenze di specifiche commesse o richieste di clienti. 01Intro.52

27 ISO 9001: certificazione e documentazione Le organizzazioni possono richiedere a organismi specializzati di rilasciare una certificazione di conformità al sistema ISO 9001 Nella visione 2000 della norma, si prevede che le verifiche debbano riguardare anche la efficacia dei processi, eventualmente a fronte di specifici obbiettivi aziendali e di settore La ISO 9000 prevede che i processi svolti vengano descritti in documenti specifici, dei quali vengono forniti indice e sommario dei contenuti, nonché guide alla loro compilazione in vari contesti Questi documenti sono: Manuale della qualità Piano della qualità 01Intro.53 Il manuale della qualità Le organizzazioni devono descrivere il proprio sistema qualità nel documento chiamato manuale della qualità Il manuale della qualità, secondo la ISO9000/ISO 8402, è il documento che enuncia la politica per la qualità e descrive il sistema qualità di una organizzazione La ISO ha emesso a supporto della stesura del manuale della qualità una guida, contenuta nella norma ISO Intro.54

28 Il piano della qualità Non sempre la qualità potenzialmente raggiungibile è quella effettivamente necessaria L adattamento della politica generale per la qualità a specifiche esigenze viene descritta, di volta in volta, in dei piani della qualità, dove vengono definiti, in termini quantitativi, gli obbiettivi da raggiungere, i controlli previsti, le risorse impiegate, le responsabilità, la pianificazione delle attività, la documentazione di riscontro che verrà prodotta ad uso del cliente Il Piano della qualità, secondo la ISO 9000/ISO 8402, è il documento che precisa le particolari modalità operative, le risorse e le sequenze delle attività relative alla qualità di un determinato prodotto, progetto o contratto 01Intro.55 Flusso della documentazione Contesto Lavorativo ISO 9000 Risorse MdQ ISO ISO PdQ Cliente Obbiettivi progetto 01Intro.56

29 MODELLI per il ciclo di vita del sw 01Intro.57 Modelli per processo di produzione del sw Sequenziale (cascata, classico) oppure (iterazione/parallelismo) Prototipale Rapid Application Development (RAD) Incrementale Spirale Sviluppo concorrente Modelli basati su metodi formali 01Intro.58

30 Processo a cascata (waterfall) ANALISI DESIGN CODIFICA TEST MANUTEN. 01Intro.59 Fasi e prodotti del modello a cascata analisi descrizione di cosa si vuole realizzare definizione dei requisiti progetto progettazione del sistema (come si vuole realizzarlo) architettura e moduli codifica realizzazione in un linguaggio di programmazione sorgenti test verifica di aderenza, test di modulo e di integrazione documenti di test manutenzione gestione cambiamenti 01Intro.60

31 Problemi del modello a cascata i progetti reali raramente seguono il flusso sequenziale proposto dal modello, spesso si verificano iterazioni è spesso difficile per il cliente dichiarare tutti i requisiti in modo esplicito. Il modello ha difficoltà a gestire la naturale incertezza che esiste all inizio di nuovi progetti 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 è inutilmente ritardato (il tempo di attesa complessiva può superare il tempo di lavoro!!!) 01Intro.61 Modello prototipale Interazione con l utente Realizz. modifica prototipo (mockup) Test del prototipo (con l utente) la prototipazione rapida ha come obiettivo la raccolta dei requisiti del prodotto software attraverso successive realizzazioni di prototipi: paper protoype o prototipo freddo working prototype: implementa solo alcune funzioni (interfaccia) 01Intro.62

32 Modello prototipale (2) se il prototipo è working lo si trasforma nel programma finale lo si butta vantaggi molto attraente, coinvolge maggiormente il cliente nella definizione delle specifiche, evita/riduce le incomprensioni svantaggi può evolvere in un sistema senza un progetto solido possibile spreco di risorse nel caso usa e getta tentazione di riutilizzare le scelte prototipali (o, addirittura il prototipo stesso) 01Intro.63 Modello RAD (Rapid Application Development) Obbiettivo: rapida codifica (riuso/parallelismo) Ipotesi fondamentale (e limite dell`approccio): requisiti chiari complessita` limitata (e.g., semplice sistema informativo) 5 fasi Analisi dell`azienda Analisi dei dati Analisi dei processi Codifica (4GT (4th generation techniques) e riuso) Test Decomposizione dell`applicazione in macrofunzioni realizzate da gruppi di lavoro diversi in parallelo 01Intro.64

33 Modello incrementale analisi progetto codifica test versione 1... analisi progetto codifica test Simile al prototipale ma: - i prodotti intermedi sono funzionanti - permette una più accurata progettazione versione n Prodotti Funzionanti 01Intro.65 raccolta dei requisiti iniziale Modello a spirale (6 regioni) 2) Planning 3) Risk analysis 1) Interazione con l`utente 4) Progetto 6) valutazione da parte del cliente 5) Realizzazione primo prototipo 01Intro.66

34 Considerazioni sul modello a spirale Rappresenta una razionalizzazione del modello prototipale Si presta alla gestione di progetti complessi Puo` essere significativo prevedere il numero delle iterazioni Sta acquistando sempre maggiore popolarita` Alcuni CASE tool lo supportano L utente e spesso scettico (converge?) 01Intro.67 Metodi formali Formalismi rigorosi (logici/algebrici) per le fasi di specifica, sviluppo e verifica Non si basano sul linguaggio naturale (inerentemente ambiguo) Affrontano i problemi di ambiguità, vaghezza, incompletezza e inconsistenza delle specifiche Esistono linguaggi formali funzionanti (ad es. `Z, Z++, ) Riportiamo un esempio con una sintassi inventata 01Intro.68

35 Metodi formali: esempio void Ordina(int a[], int n) // commento: ordina il vettore a, che ha n componenti tutte diverse tra loro, in maniera crescente pre: i J (i 0 i n-1 J 0 J n-1 i J) a[i] a[j] post: ( i (i > 0 i n-1 ) a[i] > a[i-1]) //1. gli elementi del vettore risultante sono ordinati ( K (K 0 K n-1 ) L (L 0 L n-1 a[k] = old(a[l]))) //2. gli elementi nel vettore risultante sono presenti nel vett. Originario ( R (R >= 0 && R n-1 ) S (S 0 S n-1 old(a[r]) = a[s])) //3.gli elementi del vettore originario sono presenti nel vett.risultante. 01Intro.69 Metodi formali (2) Vantaggi: Permettono controlli formali sulle specifiche Permettono la verifica automatica di ambiguità, incompletezze, inconsistenze Permettono la generazione automatica del codice Potenziali svantaggi: Difficili ad usarsi, richiedono personale estrememente specializzato Lenti nell utilizzo Non validi come forma di comunicazione con l utente 01Intro.70

36 Tecniche e linguaggi di quarta generazione (4GT/4GL) Strumenti e linguaggi caratterizzati da un elevato livello di astrazione Linguaggi dichiarativi Formalismi/linguaggi grafici Generazione automatica del codice maggiore produttività 01Intro.71 Un esempio Open Source: ArgoUML 01Intro.72

37 Tecniche e linguaggi di quarta generazione (2) Potenziali svantaggi: Strumenti difficili da usare (difficoltà paragonabile ai linguaggi di programmazione convenzionali) Il codice generato potrebbe essere inefficiente La manutenzione è difficile L approccio sembra essere indicato per applicazioni di piccole dimensioni Non si risparmia tempo nell analisi, progetto e test 01Intro.73 Extreme Programming (XP) Approccio recente (1996) Obiettivi: Maggiore coinvolgimento del cliente (customer satisfaction) Rispondere ragionevolmente ai cambiamenti nei requisiti (anche quelli tardivi) Enfasi sul lavoro di gruppo (che può coinvolgere anche il cliente) Ridurre il numero di regole e di procedure (lightweight methodology) Forte enfasi sul test 01Intro.74

38 Ciclo di vita: modello XP 01Intro.75 Alcune regole di XP: codifica L'utente è sempre disponibile Il codice è scritto usando standard concordati Progettare subito i test Si programma in coppia Si integra spesso Il codice è visibile a tutti L'ottimizzazione è lasciata alla fine Niente straordinari Riunioni in piedi 01Intro.76

39 Prodotto e processo: riassunto Il prodotto SW ed il relativo processo di produzione differiscono notevolmente da quelli di altri prodotti industriali Le tecnologie e le metodologie si evolvono rapidamente È necessaria una (auto) formazione continua, per restare aggiornati! 01Intro.77