Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A Marco Cadoli

Transcript

1 Ingegneria del Software (Ing.Informatica Nuovo Ord.) Canale M-Z / A.A Marco Cadoli Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica PRIMA PARTE Il processo di produzione del SW Sezione I: Introduzione, ciclo di vita del SW Versione definitiva 1

2 PRIMA PARTE Il processo di produzione del software I. Introduzione, ciclo di vita del SW II. Qualità, standard III. Test del SW IV. Project Management 2

3 I. Introduzione, ciclo di vita del SW I.1. Cos è l Ingegneria del Software I.2. Il prodotto I.3. Il processo I.4. Modelli per il ciclo di vita del software 3

4 I.1. COS È L INGEGNERIA DEL SOFTWARE Possibili definizioni Breve storia Crisi del SW 4

5 Possibili definizioni dell Ing. Del SW Creazione di software multiversione da parte di più operatori [Parnas, 1978] programmazione ing. SW Il settore dell informatica che si occupa di sistemi grandi e complessi, per la cui realizzazione servono unaopiùsquadre di ingegneri [Ghezzi, Jazayeri, Mandrioli, 2003] eliminazione difetti, potenziamento/modifica/eliminazione funzioni Applicazione di un approccio sistematico, disciplinato e quantificabile nello sviluppo, funzionamento e manutenzione del SW [IEEE Standard ] applicazione dell ingegneria al SW 5

6 Breve storia dell Ing. Del SW Albori dell informatica (~ ): problemi ben compresi e conosciuti (ad es., soluzione equazioni differenziali); spesso, programmatore = utente Diffusione dei computer (~ ): professione programmatore (programmatore utente necessità di specifiche); tipicamente, lavora da solo Grandi sistemi SW ( 1965): esempio: OS 360 (per IBM 360) difficoltà nell adattare le tecniche usate per lo sviluppo di piccoli programmi 6

7 Crisi del software La buona programmazione non basta I membri di un gruppo spendono più tempo per comunicare fra loro che per programmare Alcune persone possono abbandonare il progetto: influenza negativa sul lavoro altrui, trasferimento orale della conoscenza Cambiamento nei requisiti influenza su tutto il progetto Serviva un nuovo approccio! 7

8 Ingegneria del software Il termine nasce nel 1968 in una conferenza NATO. È la disciplina il cui scopo è dare un approccio sistemistico alla produzione, alla manutenzione ed alla evoluzione del prodotto software Si vuole usare lo stesso approccio degli altri settori dell ingegneria (civile, industriale) L ingegneria del software comprende: modelli astratti e teoria di base metriche metodi e processi di produzione e di test tecnologie e strumenti obiettivi da raggiungere (qualità del sw) sensibilità pratica 8

9 Ipotesi: Un problema temporaneo? I ritardi nella consegna e gli sforamenti del budget possono essere risolti con migliori: Realtà: strumenti (di analisi, sviluppo, ) tecniche di management No silver bullet [Brooks 1987] Problemi accidentali (risolti dagli strumenti) Problemi essenziali (non risolti dagli strumenti) Le applicazioni complesse non sono completamente comprese né dai clienti, né dagli sviluppatori Non si sa come stimare la difficoltà di un progetto e quanto tempo è necessario 9

10 Un esempio famoso Programma Guerre stellari (1985, presidenza Reagan). Si dimette Dave Parnas (uno dei massimi esperti di IS mondiali, responsabile informatica), Motivazione pubblica: le odierne conoscenze e tecnologie non sono in grado (e non lo saranno in breve tempo) in grado di affrontare problemi così complessi 10

11 Il futuro HW potente e a basso costo produzione di sistemi software sempre più complessi e difficili da gestire Spese mondiali per il SW: 1985: 140 G$ 2000: 800 G$ (PIL Italia 2000: 1074 G$) Si continuano a sviluppare strumenti metodologie 11

12 I IL PRODOTTO Definizioni Concetti generali Cenni storici I problemi dello sviluppo del software 12

13 Software: Definizioni 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. 13

14 Classificazione delle applicazioni SW (1) Rispetto al flusso di esecuzione: Sequenziali (unico flusso di controllo) Concorrenti (necessità di sincronizzazione e comunicazione) Dipendenti dal tempo (come le concorrenti + vincoli temporali sulla velocità di esecuzione) 14

15 Classificazione delle applicazioni SW (2) Rispetto alla natura degli elementi: Realizzazione di funzioni Gestione di dati (sistemi informativi) Controllo (sincronizzazione e cooperazione) 15

16 Macroclassificazione delle applicazioni sw Sistemi operativi e software di sistema sw di servizio Real time software vincoli precisi sui tempi di risposta Sistemi informativi gestione patrimonio informativo di un azienda Software scientifico calcolo numerico/simbolico Software nascosto (embedded) semafori, ascensori, lavatrici, telefoni, ecc.. PC software 16

17 Caratteristiche del software Il SW è sviluppato (attività human intensive) e non costruito come un qualsiasi prodotto industriale (ad es., un monitor) ingegneria, e non fabbricazione È possibile modificare facilmente il prodotto senza modificare il progetto è frequente l abuso della flessibilità Il SW non si consuma Il SW non è (era) realizzato utilizzando componenti preesistenti 17

18 Prodotto industriale e 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. 18

19 Prodotto industriale e prodotto software (2) Prodotto Industriale Sono possibili: economie di scala 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. 19

20 Insieme di: persone, Processo di sviluppo del software: strutture organizzative, regole, politiche, procedure/attività, componenti software, metodologie, strumenti utilizzati o creati appositamente per concepire, sviluppare, mettere in servizio e innovare/estendere un prodotto software. 20

21 Prospettiva storica della produzione del software : prima era batch, distribuzione limitata, software customizzato : seconda era multiuser, Real-Time, Database, software prodotto : terza era sistemi distribuiti, hardware low-cost, mercato di massa : quarta era OO technologies, sistemi user friendly, Powerful PC 1995-oggi: quinta era internet, distributed computing, CORBA-DCOM, component-ware, J2EE 21

22 Esercizi/riflessioni Esistono altri fattori che differenziano il software da altri prodotti industriali? Perché il prodotto software si differenzia così tanto da altri prodotti industriali? 22

23 Prospettiva storica del costo sw / hw costo sw / costo hw

24 Prospettiva storica del costo del costo sw / costo hw 100 software sviluppo manutenzione ANDAMENTO DELLA LA SPESA PER IL SOFTWARE 24

25 Ripartizione del costo del software 15% 80% manutenzione sviluppo 20% 46% verifica e manutenzione e modifiche validazione dis. eanalisi codifica documentazione 20% 9% 10% % costo totale % costo di sviluppo RIPARTIZIONE DEI COSTI TRA MANUTENZIONE E SVILUPPO RIPARTIZIONE DEI COSTI DI SVILUPPO TRA: ANALISI, DISEGNO, CODIFICA, DOCUMENTAZIONE E VERIFICA 25

26 Deterioramento e guasti hw e sw % guasti hw % guasti sw (teoria) tempo tempo % guasti sw (comportamento osservato) Cambiamenti sw tempo 26

27 Problemi nello sviluppo del SW IBM survey, % dei sistemi costa più del previsto 68% non viene completato nel tempo previsto 88% deve essere riprogettato in maniera sostanziale Bureau of labour, 1997 Ogni 6 nuovi sistemi messi in linea, 2 cancellati Per sistemi di grandi dimensioni, sale a 3 In media la sottostima del tempo di completamento è del 50% 27

28 Alcuni famosi incidenti causati dal software Errore di programmazione Therac-25: macchina per la radioterapia ( ). Gestione SW della mutua esclusione errata. Ariane 6: missile ESA (1996). Eccezione lanciata (ADA) a causa di violazione di assunzioni non documentate. London Ambulance Service (1992). Errore di analisi Errore di management Perdita di chiamate, duplicazione di dispatching. 28

29 Componenti sw e riusabilità Il concetto di componente software riusabile si va sempre più facendo strada. È strettamente collegato all analisi (ad es., in UML) e ai linguaggi (ad es., Java, C++, C#, Delphi) Object Oriented. Determina, fra l altro, un alto riuso di componenti, molto efficace in alcuni contesti (ad es., per la costruzione di interfacce grafiche -- Graphical User Interface o GUI). 29

30 I IL PROCESSO Il processo di produzione del sw Fasi essenziali 30

31 Il processo di produzione 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 o modelli con cui descrivere i prodotti delle fasi. 31

32 Progetto Sviluppo Fasi essenziali del processo di produzione sw Manutenzione (sw esistente) 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.) 32

33 Attività trasversali Controllo/gestione del progetto Revisioni tecniche del progetto Controllo di qualità Gestione della configurazione Gestione della documentazione Gestione della riusabilità Misure Gestione dei rischi 33

34 Elementi del processo di produzione del sw Insiemi di attività Scadenze Prodotti intermedi Controlli qualità Attività trasversali Gestione del progetto Metriche ecc. 34

35 Re-Engineering Lo sviluppo ex novo è solo uno degli aspetti dell Ingegneria del Software In questo caso si può parlare di forward engineering Se di un sistema esistente (mal documentato) si vuole creare una documentazione adeguata, si attua un processo di reverse engineering Per ricostruire un sistema ingegnerizzato a partire da un vecchio sistema inadeguato: Reverse Engineering + Forward Engineering = Re-Engineering 35

36 I.4. MODELLI PER IL CICLO DI VITA DEL SW Presentazione dei vari modelli Confronto 36

37 Modelli per il processo di produzione (ciclo di vita) del sw Sequenziale (cascata, classico) Prototipale Rapid Application Development (RAD) Modelli evolutivi Incrementale Spirale Sviluppo concorrente Extreme programming Tecniche e linguaggi di quarta generazione Modelli basati su metodi formali 37

38 Visione caotica del processo Definizione del problema Stato corrente Soluzione tecnica Integrazione 38

39 Visione caotica del processo (2) Stato corrente Sfida: gestire in maniera ragionevole questi stadi coesistenti 39

40 Processo a cascata (waterfall, Royce 1970) ANALISI DESIGN CODIFICA TEST MANUTENZIONE Ispirazione dall industria manufatturiera, reazione al code and fix 40

41 Fasi e prodotti del modello a cascata analisi descrizione di cosa si vuole realizzare definizione dei requisiti design 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 41

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

43 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. Inoltre, 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!!!) 43

44 Modello prototipale Interazione con l utente Realizz. modifica prototipo Test del prototipo (con l utente) La prototipazione ha come obiettivo la realizzazione del prodotto software attraverso successive realizzazioni di prototipi: paper protoype, o mock-up, o prototipo freddo, solo interfaccia completezza e disambiguazione requisiti, manuale utente working prototype: implementa solo alcune funzioni breadboard: funzionalità critiche, senza interfaccia 44

45 Modello prototipale (2) Se il prototipo è working: lo si trasforma nel programma finale, oppure lo si butta Vantaggi: molto attraente, sia per il cliente sia per lo sviluppatore coinvolge maggiormente il cliente nella definizione delle specifiche, evita/riduce le incomprensioni Potenziali 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) 45

46 Modello RAD (Rapid Application Development) Obiettivo: rapida (60-90 gg.) codifica (riuso/parallelismo) Ipotesi fondamentali (e limiti dell approccio): requisiti chiari la complessità è limitata (ad es., semplice sistema informativo), le prestazioni non sono critiche l applicazione si può decomporre in macrofunzioni realizzate da gruppi di lavoro diversi che operano in parallelo 46

47 Le cinque fasi: 1. Analisi dell azienda: Modello RAD (2) A che serve l informazione, da dove viene, dove va, a chi serve? 2. Analisi dei dati: Modellazione (ad es., con diagramma delle classi UML) 3. Analisi dei processi: Modellazione del ciclo di vita degli oggetti (come vengono creati, interrogati, modificati, cancellati) 4. Codifica: riuso, tramite componenti sw 4th generation techniques (4GT) 5. Test e messa in esercizio (alcune componenti sono già state testate) 47

48 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 e programmazione dell uso delle risorse versione n Prodotti Funzionanti 48

49 Modello incrementale (2) Esempio (editore di testi): 1. Gestione file, editing, stampa documenti (core) 2. Correzioni ortografiche 3. Formattazione pagina 49

50 Modello a spirale (Bohem, 1988) Raccolta dei requisiti iniziale 2) Planning 3) Risk analysis 1) Interazione con il cliente 4) Ingegnerizzazione 6) Valutazione da parte del cliente 5) Realizzazione e rilascio Primo prototipo 50

51 Gestione dei rischi Alcune tipologie di rischio: Personale inadeguato Scheduling sbagliato Budget non realistico Sviluppo del sistema sbagliato (validation: Are we building the right product?, vs. verification: Are we building the product right?, Bohem) Alti rischi possono provocare ritardi e costi imprevisti Meno informazione più rischi 51

52 Considerazioni sul modello a spirale Rappresenta una razionalizzazione del modello prototipale: Non termina con la consegna del prodotto Ammette che il processo sia dormiente Si presta alla gestione di progetti complessi Può essere significativo prevedere il numero delle iterazioni Può essere integrato con altri approcci (modello ad assemblaggio dei componenti) Sta acquistando sempre maggiore popolarità Alcuni CASE tool lo supportano Il cliente è spesso scettico ( converge? ) Recente evoluzione: modello ad assemblaggio di componenti 52

53 Modello ad assemblaggio di componenti Le fasi 4 e 5 del ciclo di vita a spirale vengono unificate, e comprendono la seguente sequenza di attività Identificazione dei componenti di interesse Ispezione dei componenti di libreria Realizzazione dei componenti non disponibili Estrazione dei componenti disponibili Inserimento dei nuovi componenti in libreria Realizzazione dell n-esima iterazione del sistema 53

54 Sviluppo concorrente Concurrent engineering: nasce in ambito manifatturiero per: eliminare i rischi di insuccesso che nascono dalla separazione tra le varie funzioni industriali (marketing, R&D, process engineering, manifacturing,...) ridurre i costi e le difficoltà produttive che nascono dalla logica di comunicazione formale ridurre i tempi di produzione che derivano da uno sviluppo prodotti essenzialmente sequenziale La risposta: Integrazione di metodi, tools, cultura 54

55 Concurrent Engineering Sviluppo sequenziale Base delivery Release 1 Release 2 Sviluppo concorrente Base delivery Mod1 Mod2 Release 3 Integr. Release 1... Release 2 Release 3 La differenza rispetto ai modelli di processo incrementali o a spirale è la granularità e la dimensione dei processi che vengono attivati in simultanea (fasi vs processi completi) 55

56 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, o agile methodology) Forte enfasi sul test 56

57 Ciclo di vita: modello XP 57

58 Alcune regole di XP: codifica The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often. Use collective code ownership. Leave optimization till last. No overtime. 58

59 Il mondo open source: alcuni link Eric S. Raymond's Home Page Articolo The Cathedral and the Bazaar In italiano: Table of Contents: The Cathedral and the Bazaar The Mail Must Get Through The Importance of Having Users Release Early, Release Often How Many Eyeballs Tame Complexity When Is a Rose Not a Rose? Popclient becomes Fetchmail Fetchmail Grows Up A Few More Lessons from Fetchmail Necessary Preconditions for the Bazaar Style The Social Context of Open-Source Software On Management and the Maginot Line Epilog: Netscape Embraces the Bazaar 59

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

61 Un esempio Open Source: ArgoUML 61

62 Tecniche e linguaggi di quarta Potenziali svantaggi: generazione (2) 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 62

63 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. SMV, TLA, Alloy, Z, ) Riportiamo un esempio con una sintassi inventata 63

64 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: //1. gli elementi del vettore risultante sono ordinati ( I (I > 0 I n-1 ) a[i] > a[i-1]) //2. gli elementi nel vett. risultante sono presenti nel vett. originario ( K (K 0 K n-1 ) L (L 0 L n-1 a[k] = pre(a[l]))) //3. gli elementi del vett. originario sono presenti nel vett.risultante ( R (R 0 R n-1 ) S (S 0 S n-1 pre(a[r]) = a[s])) 64

65 Metodi formali: esercizi 1. È possibile semplificare la specifica precedente? 2. Scrivere un specifica valida per il caso generale, ovvero il caso in cui non sia valida la precondizione che impone che tutti gli elementi del vettore sono distinti fra loro. 65

66 Metodi formali (2) Vantaggi: Permettono controlli formali sulle specifiche Permettono la verifica automatica di incompletezze e inconsistenze nelle specifiche Permettono la generazione automatica del codice Potenziali svantaggi: Difficili ad usarsi, richiedono personale specializzato Lenti nell utilizzo Non molto validi come forma di comunicazione con l utente 66

67 Metodi formali: sviluppi recenti Recentemente sono stati sviluppati strumenti e metodologie che risolvono, in parte, i problemi dei metodi formali, in particolare: Offrendo una migliore gestione dei processi di forward e backward engineering Garantendo un efficienza accettabile Offrendo utili metafore grafiche Un esempio è dato dal tool Alloy Analyzer (alloy.mit.edu), che fornisce, fra l altro, strumenti per l analisi di diagrammi delle classi UML 67

68 Un esempio in AlloyAnalyzer module alloyexamples/prog_sw_1/iiiappello_2005 // 1. encoding of UML class diagram // 1.a classes and associations // 1.b inverse associations // 1.c disjointness & completeness // 2. encoding of constraints // 3. verification of assertions Generato automaticamente // 1.a --EXAMPLE sig Visita { assistito: one Persona, medico: one Persona, indicazione: set Prescrizione } // 1.b --EXAMPLE fact reverseassistito { all p: Persona p.assistito.assistito = p } // 2. --EXAMPLE fact nomedicoassistito { // un medico non può mai visitare // se stesso all v: Visita v.medico!= v.assistito } 68

69 Un esempio in AlloyAnalyzer (cont.) assert noduevisitestessaprescrizione { // true assertion: // implied by cardinality constraints // due visite distinte non possono // avere prescrizioni in comune all v1, v2: Visita v1!= v2 => no v1.indicazione & v2.indicazione } check noduevisitestessaprescrizione for 2 Chiediamo la verifica di questa affermazione 69

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

71 Metodi formali: soluzioni (1) 1. Sì, in due modi alternativi: 1. Eliminando il secondo vincolo 2. Eliminando il terzo vincolo 71

72 Metodi formali: soluzioni (2) void Ordina(int a[], int n) // commento: ordina il vettore a, che ha n componenti // in maniera non decrescente pre: nessuna post: //1. gli elementi del vettore risultante sono ordinati tramite un // vettore perm, con n elementi compresi fra 0 e n-1 ( I (I > 0 I n-1 ) pre(a[perm[i]]) pre(a[perm[i-1]]) //2. fra gli elementi del vettore perm sono presenti tutti gli indici ( K (K 0 K n-1 ) L (L 0 L n-1 K = perm[l]) //3. alternativo al precedente: tutti gli elementi di perm sono distinti I J (I 0 I n-1 J 0 J n-1 I J) perm[i] perm[j] 72

73 Soluzione all esercizio 2 in OPL/ILOG int+ n =...; // # of elements of the input array int maximum = maxint; range myint [-maximum..maximum]; range indexes [0..n-1]; myint pre_a[0..n-1] =...; // input array Schema dei dati var indexes perm[indexes]; // guessed permutation Vettore perm solve { // 1. elements of the output array // (implicitly defined as pre_a[perm]) are sorted forall (i in 1..n-1) pre_a[perm[i]] >= pre_a[perm[i-1]]; // 2. all elements of perm are different // --> perm is a permutation alldifferent(perm); Vincoli }; 73