Il processo di produzione del SW. Sezione I: Introduzione, ciclo di vita del SW

Transcript

1 Il processo di produzione del SW Sezione I: Introduzione, ciclo di vita del SW

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

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

55 Ciclo di vita: modello XP 55

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

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

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

59 Un esempio Open Source: ArgoUML 59

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

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

62 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])) 62

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

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

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

66 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 // 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 } Generato automaticamente 66

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

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

69 Qualità del Prodotto Software 69

70 Qualità esterne ed interne Qualità esterne: Sono le qualità visibili agli utenti del sistema Percepibili anche da chi non è specialista dell informatica Non richiedono l ispezione del codice sorgente Qualità interne: Sono le qualità che riguardano gli sviluppatori Valutabili da specialisti Richiedono la conoscenza della struttura del programma A volte la distinzione fra qualità esterne ed interne non è perfettamente marcata 70

71 Fattori di qualità del SW QUALITÀ ESTERNE Correttezza Affidabilità Robustezza Sicurezza Innocuità Usabilità Estendibilità Riusabilità Interoperabilità QUALITÀ INTERNE Efficienza Strutturazione Modularità Comprensibilità Verificabilità Manutenibilità Portabilità 71

72 Esercizio 3 Considerare le seguenti proprietà di un impianto Hi-Fi e stabilire quali di esse sono esterne e quali sono interne: 1. il tempo dedicato al collaudo; 2. la fedeltà sonora; 3. la probabilità di malfunzionamenti nel primo anno di utilizzazione; 4. la dimensione del trasformatore per l alimentazione; 5. l ergonomia dei comandi; 6. la linearità della risposta in frequenza. 72

73 Correttezza, Affidabilità, Robustezza, Innocuità, Sicurezza Correttezza: (fondamentale) il SW fa ciò per cui è stato progettato Affidabilità: si può fare affidamento (in senso statistico) sulle funzionalità del SW Robustezza: il SW ha un comportamento accettabile anche nel caso di situazioni non specificate Innocuità: il sistema NON entra in certi stati (pericolosi) Sicurezza: il SW garantisce la riservatezza nell accesso ai dati 73

74 Usabilità Enfasi sull utente Psicologia cognitiva Fattori fisici/ergonomici Mentalità dell utente Interfacce grafiche/visuali Viene, spesso, totalmente ignorata 74

75 Estendibilità Facilità con cui il SW può essere adattato a modifiche delle specifiche. Importantissima in grandi programmi Due princìpi per l estendibilità: Semplicità di progetto Decentralizzazione nell architettura del SW 75

76 Riusabilità Facilità con cui il SW può essere re-impiegato in applicazioni diverse da quella originaria Evita di reinventare soluzioni Richiede alta compatibilità Uso di librerie di componenti riutilizzabili Progetto del SW più generale possibile Documentazione Maggiore affidabilità 76

77 Interoperabilità Facilità di interazione con altri moduli al fine di svolgere un compito più complesso Problemi tecnologici e semantici Favorisce la riusabilità 77

78 Nota sulle qualità esterne Correttezza Estendibilità Riusabilità sono qualità chiave, fortemente favorite da un approccio orientato agli oggetti 78

79 Efficienza Si riferisce al peso che il software ha sulle risorse del sistema tempo di esecuzione utilizzo di memoria Teoria della complessità limiti asintotici caso medio caso peggiore Simulazioni (ad es., teoria delle reti di code) Legata alle prestazioni (quest ultime percepibili dall utente, quindi qualità esterne) 79

80 Strutturazione/Modularità Strutturazione Capacità del SW di riflettere con la sua struttura le caratteristiche del problema trattato e delle soluzioni adottate Modularità Grado di organizzazione del SW in parti ben specificate ed interagenti 80

81 Comprensibilità Capacità del SW di essere compreso e verificato anche da parte di chi non ha condotto il progetto si applica sia al software sia al processo facilitata da: strutturazione modularità la comprensibilità del software facilita: l analisi della correttezza la correzione di errori ilriuso 81

82 Verificabilità La possibilità di verificare che gli obiettivi proposti siano stati raggiunti È una caratteristica sia del processo sia del prodotto Facile: il codice soddisfa gli standard di codifica? Difficile: il codice fa ciò che deve fare? (vedi correttezza) 82

83 Manutenibilità/portabilità Manutenibilità: Facilità nell effettuare modifiche Portabilità: Possibilità di riusare codice sorgente linguaggi compilabili su più piattaforme macchine virtuali (html/java) 83

84 Nota sulle qualità interne Strutturazione Modularità sono caratteristiche di estremo interesse, favorite dall approccio orientato agli oggetti 84

85 Esercizio 4 Assimilando le qualità di un programma alle proprietà delle automobili, il fatto che i motori di un certo modello possono essere montati su diversi modelli di automobile a quali qualità fa riferimento? 85

86 Misura delle qualità Ogni qualità deve essere valutata attraverso alcune proprietà, misurabili in modo oggettivo e quantitativo, possedute dalle entità. Differenti entità possono essere collocate su una scala di valori in funzione dei livelli misurati per questi attributi. 86

87 Qualità in contrasto Non tutte le qualità possono essere massimizzate Alcune sono intrinsecamente in contrasto fra loro. Ad esempio: Usabilità e sicurezza Efficienza e portabilità È necessario scegliere un adeguato bilanciamento 87

88 Esercizio 5 Le qualità dei programmi non sono necessariamente indipendenti tra loro. Ad esempio, all aumentare della modularità aumenta in genere anche la leggibilità. Considerare due qualità alla volta e valutare il loro rapporto reciproco. 88

89 Tendenze nello sviluppo di applicazioni SW + Complessità delle informazioni da gestire + Progetti di dimensioni medio-grandi + Eterogeneità degli utenti - Durata media dei sistemi + Bisogno di interventi di manutenzione - Costi di produzione e tempi di produzione + Qualità del prodotto finito 89

90 Princìpi guida nello sviluppo del software Rigore e formalità Lo sviluppo del software è una attività creativa che va accompagnata da un approccio rigoroso (o addirittura formale) Possiamo realizzare prodotti affidabili, controllarne il costo, aumentare la fiducia nel loro corretto funzionamento. Separazione degli interessi Affrontare separatamente i diversi aspetti per dominare la complessità Modularità Realizzare la separazione degli interessi in due fasi: I singoli moduli vanno trattati separatamente I dettagli interni dei singoli moduli vanno trattati separatamente dalle relazioni inter-modulari 90

91 Princìpi guida nello sviluppo del software (2) Astrazione Identificare aspetti fondamentali ed ignorare i dettagli irrilevanti Anticipazione del cambiamento Per favorire l estendibilità e il riuso Generalità Ricerca si soluzioni generali Incrementalità: raggiungere l obiettivo attraverso passi successivi per anticipare feedback dell utente per facilitare verifiche di correttezza per predisporsi alla estendibilità e al riuso 91