Lezione 1: Introduzione al Corso File
Transcript
Lezione 1: Introduzione al Corso File
Bibliografia e strumenti Corso di Laurea Specialistica in Ingegneria Informatica per la Gestione d’azienda Slide delle lezioni del modulo – http://info.iet.unipi.it/~vaglini/GQ/ http://www.swebok.org Gestione della Qualità-II parte La produzione del software: metodologie e standards a.a. 2009-2010 Docente: Gigliola Vaglini 1 3 Obiettivi del corso Comunicazione docente Affrontare nel modo più produttivo un progetto software – – – – – – – [email protected] Definire i requisiti Scegliere il giusto processo di sviluppo Stimare i costi del processo Pianificare il processo di sviluppo “realizzare il progetto” Testare la realizzazione del progetto Garantire la qualità/Valutare la qualità 2 4 1 2 Esame Software Progetto di una applicazione software Discussione del progetto. Orale Computer Programs, Procedures, and possibly associated Documentation and Data pertaining to the operation of a computer system “IEEE Std.610.12-90” Programmi, procedure, regole e ogni altra documentazione relativa al funzionamento di un sistema informatico. “ESA Software Engineering Standard, 1991” 5 7 All’inizio Lezione 1 I computer sono usati per “computare” – si risolvono problemi matematici – progettisti = utenti – breve tempo di vita Introduzione Il software è un prodotto “artistico” What is software engineering? – linguaggi a basso livello – limitate risorse (velocità di calcolo e memoria) Esempio: programmi di scacchi 6 8 3 4 Il software è un prodotto industriale Dall’arte all’artigianato Software per nuove esigenze Produzione organizzata – utenti ≠ progettisti – sorgono le software houses – Per produrre “in grande” (per dimensione o volume) – Per assicurare la qualità dei prodotti – Per garantire l’efficienza della produzione Nuovi linguaggi di programmazione “ad alto livello” – Dal puro calcolo alla gestione delle informazioni Primi grossi progetti e primi fallimenti: – limiti di tempo saltati, budget sforato, cooperazione umana assente (errori di gestione) – specifiche sbagliate (errori di progetto) 9 11 Dall’artigianato all’industria Rivoluzione informatica Cambiamenti radicali nel modo di lavorare Trattamento di informazioni altrimenti impossibile La nuova economia Sviluppo di metodi e standards Pianificazione e gestione Automatizzazione di buona parte delle procedure Sviluppo modulare Qualità verificabile …… – Nuove professionalità (e nuove esigenze di formazione) – Molti nuovi servizi di rete si basano su innovazioni tecnologiche software (es. aste online, ecc.) – Nuove opportunità d’impresa legate allo sviluppo tecnologico – L’industria mondiale del sw è cresciuta negli anni ’90 a tassi di almeno il 10% annuo (dal 2001 è scesa al 3%) 10 12 5 6 Acquisire il software "giusto“? Un settore in crescita Benefici indiscutibili implicano un processo inarrestabile Una nazione industrializzata quanto spende – Mld € 2.56, la P.A. italiana per il 2001 (+95% risp. 2000) – Mld € 1.02 per spese correnti (1.54 per investimenti) Dimensione dei sistemi software – – – – – – – – 1962 Mercury 1.000.000 LoC 1965 Gemini 3.000.000 LoC 1969 Apollo 11.000.000 LoC 1981 Shuttle 37.000.000 LoC 1990 Hubble 82.000.000 LoC Un telefonino contiene 5+ MLoC (fonte Nokia) Windows XP contiene 40+ MLoC (Windows 95: 11 MLoC) Windows Vista contiene 50+ MLoC Comprare un programma Affittare un programma Costruire un programma da soli Far costruire un programma a qualcun altro – Software su commessa – Pacchetti software – Componenti software – Servizi su sistemi e dati 13 15 Industria ICT Comprare il software L’industria ICT è di tipo “orizzontale”: i sistemi informatici moderni vengono costruiti scegliendo i componenti preferiti in un mercato organizzato per fasce orizzontali (grazie agli standard) – – – – – – – In Europa non è in sé brevettabile (ma protetto) Viene acquisito su licenza Servizi di rete: ISP, Web hosting, Application server, ecc. Vendita e distribuzione: negozi, superstore, dealer on-line Applicazioni: Office, Netscape, SuperMarioBros, ecc. Middleware: .NET, CORBA, XML/Web-based, ecc. Sistemi operativi: Windows, Linux, MacOS, ecc. Computer: IBM, HewlettPackard, Dell, Compaq, ecc. Processori: Intel, Motorola, ecc. – proprietaria (normale, shareware, freeware) software commerciale (Es. www.microsoft.com) software shareware (Es. www.shareware.com) software freeware (Es. Linux, www.linux.org) – software public-domain (es. www.download.com) È molto semplice comprare hardware – open source 14 16 7 8 Comprare il software: garanzie possibili Farsi costruire un software: garanzie possibili Protezione del compratore: La verifica garantisce l’aderenza ad una specifica La validazione garantisce l’accettazione da parte del cliente La certificazione garantisce l’aderenza a specifiche definite dalla legge – Nel software di consumo in teoria NON c’è alcuna protezione. Il software viene venduto “così com’è”, senza garanzie, e se ci sono difetti il fabbricante non se ne fa carico: lo dice il contratto che si visualizza quando si usa per la prima volta un’applicazione 17 19 Comprare il software: garanzie possibili Realizzare del buon software Protezione dell’autore: Realizzare del buon software significa ottimizzare ogni istruzione, in modo da ottenere il codice più compatto ed efficiente possibile Realizzare del buon software significa fornire le funzionalità richieste dal cliente nel minor tempo possibile e col minor costo possibile, indipendentemente da come si arriva al risultato. – Il software è un’opera dell’ingegno: chi lo produce è un autore che ha diritto ad un compenso – Copiare software abusivamente è illegale (anche se non lo si fa per profitto) e in Italia costituisce un reato penale – La legge italiana 248/2000 punisce col carcere da 6 mesi a 3 anni chi duplica abusivamente software 18 20 9 10 Farsi costruire un software: problemi Costi del SW I costi del software spesso sono dominanti tra i costi di produzione di un sistema. I progetti software spesso sono in ritardo – Difficoltà nelle fasi iniziali dei progetti – Cambi di piattaforma e tecnologia – Difetti nel prodotto finale – In particolare, sono spesso maggiori dei costi dell’hardware utilizzato. A volte falliscono clamorosamente Il costo di sviluppo di un programma cresce col quadrato delle sue dimensioni [Berra-Meo 2001 ] – Per obsolescenza prematura – Per incapacità di giungere alla conclusione – Per esaurimento dei fondi 21 23 Produttività dell’industria ICT La soluzione ingegneristica I successi del software generano grandi aspettative Gli insuccessi generano clamore e delusione L’industria del software ha bisogno di metodi Da un’analisi ormai periodica di progetti di costruzione di sw (Standish Report 2009) – 24% falliti (non hanno prodotto un risultato utilizzabile o sono stati cancellati); erano il 19% nel 2006 – 44% ha superato i tempi previsti e\o i costi previsti e\o non ha tutte le funzionalità previste – 32% ha avuto successo completo – From art to industry – The term “software engineering” was defined in a NATO conference in Garmisch, Oct. 1968 22 24 11 12 Azioni proprie dell’ingegneria Conseguenze Approccio sistematico Il software è un prodotto con un proprio ciclo di vita: i prodotti SW hanno bisogno di manutenzione Progetto innovativo – nuove soluzioni per problemi nuovi Progetto routinario – Perfettiva (65%): miglioramenti del prodotto – Adattiva (18%): risposta a modifiche ambientali – Correttiva (17%): correzione di errori scoperti dopo la consegna – riuso di soluzioni precedentemente trovate per problemi noti L’ingegneria del software si preoccupa di produrre software con costi “accettabili”. Le discipline ingegneristiche mature hanno la caratteristica di catturare, organizzare e condividere la conoscenza di progetto – Disciplina gestionale – Controllo della qualità: costi e risultati definiti 25 27 What is SE? Per riassumere The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. Software engineering should be based, among other things, upon computer science, but the emphasis is necessarily different between scientists and engineers, since the formers extend knowledge of the laws of nature while engineers apply those laws to build useful artifacts, under a number of constraints. SE (Software Engineering) è una disciplina metodologica, cioè studia i metodi di produzione, le teorie alla base dei metodi, e gli strumenti efficaci di sviluppo e misura della qualità di sistemi software complessi E’ tuttavia anche una disciplina empirica, cioè basata (dovrebbe almeno) sull’esperienza e sulla storia dei progetti passati 26 28 13 14 Engineering profession and normative Realizzare del buon software Trovare il miglior equilibrio fra diversi fattori: The engineering practice has strong relationship with the normative literature. A normative document prescribes what an engineer should do in a specified situation. The normative literature is validated by consensus formed among practitioners and is concentrated in standards and related documents. – soddisfazione dell’utente – facilità di estensione del programma – comprensibilità delle soluzioni adottate Adottare tecniche adeguate a gestire la crescente complessità delle applicazioni Fare in modo che l’investimento, spesso ingente, necessario per produrre un’applicazione venga utilizzato al meglio, garantendo in particolare: – il maggior tempo di vita possibile – la possibilità di riutilizzare in altri progetti parte del codice prodotto 29 31 Perché l’Ingegneria del SW è difficile? Engineering is a profession For software engineering to be fully known as a legitimate engineering discipline and a recognized profession, consensus on a core body of knowledge is imperative. The legitimization of professional authority involves three distinctive claims: A F. Brooks va il merito di aver messo fuoco la questione fondamentale: – “La complessità del software è una proprietà essenziale e non incidentale.” .. “Einstein poteva affermare che devono esserci spiegazioni semplici della natura, perchè Dio non è capriccioso o arbitrario. Una tale fede non conforta l’ingegnere del software perchè gran parte della complessità che deve gestire è complessità arbitraria.” – first, that the knowledge and competence of the professional have been validated by a community of his or her peers; – second, that this consensually validated knowledge rests on rational, scientific grounds; and – third, that the professional’s judgment and advice are oriented toward a set of substantive values, such as health. Grady Booch, uno degli “inventori” di UML, ha fatto una precisazione altrettanto importante: – “Affermare che la complessità è essenziale non vuol dire che non è gestibile, ma semplicemente che non è eliminabile” These aspects of legitimacy correspond to the kinds of attributes—collegial,cognitive, and moral—usually embodied in the term“profession”. (Starr) 30 32 15 16 Fattori di complessità Fattori di complessità Complessità del problema Barriera culturale fra utenti e sviluppatori di un sistema – Il software deve spesso modellare una realtà complessa: problemi definiti da una miriade di requisiti in competizione fra di loro, se non addirittura in contraddizione – Oltre alla difficoltà di definire le funzionalità di base dei sistemi bisogna tener conto anche di requisiti di tipo non funzionale: usabilità, prestazioni, costo, durata nel tempo, affidabilità ... – Gli utenti spesso trovano difficile esprimere i loro bisogni in una forma che gli sviluppatori possono comprendere, gli sviluppatori non comprendono i bisogni degli utenti, entrambi mancano di esperienza nel dominio degli altri. – Utenti e sviluppatori hanno prospettive diverse della natura del problema e fanno ipotesi diverse sulla natura della soluzione – Spesso i requisiti cambiano in corso d’opera perchè il processo di sviluppo altera le regole del problema: gli utenti vedendo all’opera i primi prototipi si rendono conto di aspetti del problema che non avevano mai colto prima 33 35 Fattori di complessità Fattori di complessità Complessità del prodotto Complessità del processo di sviluppo – “Il compito principale del team di sviluppo software e quello di creare l’illusione della semplicità, ..” (Grady Booch) – Una sola persona non è in grado di comprendere completamente un sistema delle dimensioni dei prodotti sw attuali. – Servono team di sviluppatori di dimensioni sempre maggiori e ciò pone nuove sfide: – Una maggiore semplicità di utilizzo per l’utente comporta uno sforzo più grande in termini di sviluppo e quindi un aumento delle dimensioni del software – Oggi si producono programmi costituiti da centinaia di migliaia o addirittura milioni di righe di codice Coordinamento e comunicazione più complessi Difficoltà nel mantenere l’unità e l’integrità del progetto 34 36 17 18 Perché l’Ingegneria del SW è difficile? Ingegneria tradizionale Il progetto è fissato e il committente ha scarsa possibilità di cambiare le specifiche Il progetto di ponti è vecchio di migliaia di anni Scarsa formazione specifica sul processo di produzione SW Innovazione tecnologica rapidissima Competizione internazionale L’ingegneria del SW è ancora praticata (e pensata) in modo non sistematico – Progetto estremamente dettagliato: c’è una vasta quantità di conoscenze con sottostanti teorie e metodi Progetti alternativi possono essere provati attraverso modelli Si seguono procedure (processi) standard Le conoscenze acquisite comprendono anche l’analisi dei fallimenti – È meno stabile e organizzata dell’ingegneria tradizionale – Non esistono standards per tutte le fasi della produzione del software – Il software è spesso trattato come qualcosa da progettare da capo piuttosto che riutilizzare cose già fatte in questo modo non si cattura ed organizza la conoscenza già acquisita 37 39 Esempio: costruzione di ponti (ingegneria tradizionale) e sviluppo sw (SE) SE Il software è una componente fondamentale di applicazioni e servizi che sono il cuore degli affari: specifiche e progetti fissati non vanno d’accordo con i cambiamenti e l’evoluzione continui che occorrono nella pratica degli affari SE è una disciplina giovane Comincia ad esserci una discreta quantità di conoscenze con sottostanti teorie e metodi Però quando si produce SW raramente vengono analizzati i fallimenti I ponti sono normalmente costruiti nei limiti di tempo previsti, secondo il costo calcolato e non cadono Il software è raramente sviluppato nel tempo previsto e, soprattutto con i costi previsti. 38 40 19 20 Progetto celebre 1 Altri progetti celebri Ariane 5 Aeroporto di Denver: sistema automatizzato di smistamento dei bagagli – Fallimento del primo lancio del vettore commerciale ESA – 35 Km di rete, 4.000 carrelli, 5.000 telecamere, 56 lettori – $ 193.000.000 di investimento Patriot – Una caserma colpita per un difetto nel sistema di guida Risultati Therac 25 – Inaugurazione dell’aeroporto ritardata di 7 mesi – $ 1.000.000 al giorno di perdita (costi + mancati guadagni) – Il software ha provocato la perdita di vite umane Mars Climate Orbiter & Mars Polar Lander – Difetti nel software hanno causato il fallimento delle missioni Diagnosi: Realizzazione difettosa 41 43 Progetto celebre 2 Produzione o progetto London ambulance service Un aspetto importante da tener presente, spesso non ben compreso, è che il termine processo di produzione applicato al software è in qualche modo improprio. Lo sviluppo del software è in effetti un processo di progettazione La produzione vera e propria è semplicissima: il programma viene copiato su CD. – Sistema automatizzato per gestire il servizio ambulanze – Unificazione di 3 servizi, ottimizzazione dei percorsi – Guida vocale degli autisti Risultati – 3 versioni, costo totale: € 11.000.000 – L’ultima versione abbandonata dopo soli 3 giorni d’uso Diagnosi: analisi errata del problema Esiste un rapporto pubblico sull’analisi del fallimento 42 44 21 22 Produzione o progetto Caratteristiche del SE Non a caso, anche nel campo della certificazione di qualità ISO 9000, al software si applicano le norme destinate ai processi di progettazione La realizzazione di un programma dovrebbe essere confrontata non con il processo seriale con cui viene costruita un’automobile bensì con il processo di progettazione dell’automobile e della linea di produzione necessaria per realizzarla. La conoscenza del dominio di applicazione gioca un ruolo fondamentale nello sviluppo del sw – Per sviluppare un sistema di controllo del volo, uno deve capire come funziona un aereo – Il software sviluppato a partire da assunzioni sbagliate sul dominio di applicazione può generare disastri Connessione con tematiche economiche e manageriali – L’ingegnere del sw lavora in gruppo, interagisce con un ambiente esterno che definisce i requisiti e progetta componenti che devono interagire con componenti definiti da altri – Il sw evolve in risposta a problemi reali – L’abilità nella programmazione non è tutto 45 47 Strategie e strumenti La definizione di metodi di analisi e progettazione dei prodotti sw per – Sistemi grandi Caratteristiche del SE Space shuttle project; 5.6 million code lines, 22k man year, 1200 Million$ CityBank teller machine; 780000 code lines,150 man year, 13.2 Million$ – Sistemi critici I fallimenti generano rischi o perdite (denaro, vite) Tecniche per la comprensione e la soluzione di un problema – Strategie top-down, bottom-up, modulari, OO – Linguaggi di specifica e progettazione Cosa serve per progettare Strumenti formali per la definizione di sistemi software – Reti di Petri, Z, UML – Ambienti di sviluppo – Strumenti per la progettazione e realizzazione 46 48 23 24 Che tipo di prodotto? Affidabilità Prodotti generici (OTS: off the shelf) Affidabilità – Sistemi prodotti da qualche produttore di pacchetti software e venduti sul mercato a qualsiasi cliente – Se si “rompe”, il sw non dovrebbe causare danni Prodotti commissionati (“customizzati”) Termini diversi: – Sistemi commissionati da un cliente specifico e sviluppati apposta da un qualche fornitore – Reliability Della spesa della PA italiana per sw nel 2002 il 65% è stato per software commissionato e il 35% per sw su licenza (fonte Min. IT) informalmente: „un utente può contare sul SW“ matematicamente può essere definita come „la probabilità di assenza di fallimenti per un certo periodo di tempo“ Attributi del prodotto software – Attributi esterni (visibili all’utente) – Robustness Costo (e tipo di licenza), Prestazioni – Attributi interni (visibili ai progettisti) il software si comporta „ragionevolmente“ anche in circostanze impreviste (ad es. fallimenti hardware) Dimensione ( size) Sforzo di produzione ( effort) 49 51 Ad esempio: le prestazioni Altri attributi Efficienza Manutenibilità – Il sw non dovrebbe sprecare le risorse di sistema ( memoria, tempo di calcolo, …) – Può essere verificata – Se i requisiti cambiano, il sw deve poter evolvere Analisi di complessità “performance evaluation” (su un modello, per mezzo di simulazione) Riusabilità – Il sw dovrebbe avere interfaccia e documentazione appropriate – Termini diversi: ergonomicità, user friendly Portabilità – La facilità di installazione è parte dell’usabilità (utente=installatore) – E’ influenzata essenzialmente dall’interfaccia utente, ad es. visuale invece che testuale – Difficile da valutare, è una cosa soggettiva Interoperabilità – di solito riferito ai componenti di un sistema Usabilità Gli utenti attesi trovano il sistema facile da usare Importante: definire gli utenti attesi – adattabilita’ ad ambienti d’uso diversi – il prodotto SW è in grado di coesistere e cooperare con altre applicazioni 50 52 25 26 Bilanciamento degli attributi Strutturazione del Processo sw L’importanza relativa degli attributi di un prodotto dipende dal tipo del prodotto e dall’ambiente in cui verrà usato Organizzazione e gestione – – – – – Nei sistemi in tempo reale con requisiti di sicurezza, gli attributi chiave sono l’affidabilità e l’efficienza – Se un attributo dev’essere particolarmente curato e “spinto”, i costi di sviluppo tenderanno a crescere esponenzialmente Metodi di composizione dei gruppi di lavoro Strumenti di pianificazione, analisi, controllo Definizione e correlazione delle attività Norme per la definizione delle attività Modelli del processo di sviluppo – Modelli ideali – Strumenti per la definizione dei processi 53 55 Il processo software Attributi di processo Lo studio del processo di sviluppo del sw Comprensibilità – Insieme strutturato di attività necessarie per creare un sistema software attraverso le fasi di – Il processo è definito e comprensibile Visibilità Specifica Progetto e sviluppo Verifica e validazione Manutenzione – Il processo progredisce in modo visibile Sostenibilità – Il processo è sostenuto da strumenti adeguati (ad es. CASE) Le attività differiscono in funzione del SW da produrre e dell’organizzazione che lo sviluppa Accettabilità – Vanno considerati gli aspetti economici dei prodotti e dei processi – Per poter gestire le attività esse vanno esplicitamente modellate – Le persone implicate nel processo manifestano il loro consenso 54 56 27 28 Attributi di processo Miti e leggende Affidabilità Per cominciare un progetto basta un’idea generica dei suoi obiettivi, ai dettagli si pensa dopo – Gli errori di processo vengono scoperti prima che diventino errori di prodotto Robustezza – La cattiva definizione della specifica è la maggior causa di fallimenti progettuali – Il processo può continuare anche in presenza di errori Mantenibilità Se il progetto ritarda, possiamo aggiungere personale e rispettare la consegna – Il processo può evolvere per adattarsi ai cambiamenti nell’organizzazione che lo usa – Legge di Brooks: “Aggiungere personale ad un progetto in ritardo lo fa ritardare ancor di più” Rapidità – Il processo influenza la velocità di produzione del prodotto 57 59 Quindi Miti e leggende Se i requisiti di un progetto cambiano, non è un problema tenerne conto perché il software è flessibile – In realtà da un costo minimo per cambiamenti nella fase di progetto, si passa a costi altissimi per cambiamenti nella fase di realizzazione Quali sono i principi di un buon processo Se il software “funziona”, la manutenzione è minima e si può gestire errore per errore, quando si verifica – In realtà da un costo a budget del 10% per la manutenzione si può passare ad un costo reale del 70% 58 60 29 30 Principi di un buon processo Rigore e Formalizzazione Applicazione di metodi e tecniche ben definite Anticipazione del cambiamento Rigore e Formalizzazione Separazione dei problemi Modularità Astrazione Generalità Incrementalità – Assicurano l’affidabilità del prodotto, permettono il controllo dei costi, aumentano la fiducia dell’utente I livelli di rigore e formalità saranno diversi per prodotti diversi, per processi diversi,per parti di sistema diverse 61 63 Anticipazione del cambiamento Separazione dei problemi Le modifiche al software sono frequenti per rimuovere errori e adeguarlo a requisiti in evoluzione Occorre considerare i probabili cambiamenti futuri come parte della progettazione Molte decisioni sono fortemente correlatened interdipendenti Conviene concentrarsi sui diversi aspetti di un problema separatamente: es. Il sistema operativo, i vincoli di ambiente esecutivo, l’interfaccia utente sono aspetti “separabili” La separazione si può fondare sul tempo, le qualità, i punti di vista, la dimensione, il livello di dettaglio, ecc. – Isolare le parti soggette a possibili cambiamenti in moduli specifici – Progettare moduli riusabili Il processo di sviluppo deve essere modificabile anch’esso 62 64 31 32 Modularità Generalità, Incrementalità Suddividere un sistema complesso in sottosistemi più semplici ( divide et impera) I componenti dovrebbero essere molto coesi e lascamente accoppiati Generalità – Le soluzioni di problemi generalizzati sono potenzialmente più riusabili – Occorre bilanciare le decisioni che favoriscono una soluzione generalizzata – Information Hiding Incrementalità – Procedere passo a passo (senza salti) – Applicato al processo di sviluppo o alla qualità del software 65 67 Astrazione Qualità del software Identificare gli aspetti importanti di un fenomeno, trascurandone i dettagli meno significativi La stessa realtà può essere descritta da diverse astrazioni, ciascuna avente scopo diverso L’astrazione guida l’intero processo La standardizzazione di processi e tecnologie utilizzati (approccio ingegneristico) è la strada per garantire (migliorare) la – Qualità del prodotto software – Un linguaggio di programmazione è un’astrazione del codice macchina – Un ambiente di ingegneria del software include astrazioni per la specifica, il progetto, la codifica 66 Il nostro scopo è sviluppare prodotti SW Il processo è il modo in cui lo facciamo Entrambi sono importanti Entrambi hanno qualità 68 33 34 Come si assicura la qualità del prodotto SW Dimensione della qualità Metodi di verifica, criteri di progettazione delle prove Processo \ prodotto – – – – – La qualità del processo influenza quella del prodotto Un processo definito si controlla meglio Può essere migliorato Permette di imparare dall’esperienza Permette di avere costi minori a parità di qualità – Controllo della qualità e valutazione del processo di sviluppo Modelli di qualità – Definizione di caratteristiche della qualità – Valutazione dei prodotti Metriche software Interna \ esterna – Unità di misura, scale di riferimento, strumenti – Indicatori di qualità – La qualità interna influenza quella esterna 69 71 Come si assicura la qualità del processo di produzione del SW Qualità =“Correttezza”? Il SW è corretto se soddisfa le specifiche Se le specifiche sono stabilite formalmente, poiché i programmi sono oggetti formali, anche la correttezza può essere definita formalmente: Organizzazione interna Diffusione interna Identificazione dei prodotti intermedi e dei punti di verifica Replicabilità dei risultati Garanzia della qualità – Può essere provata come un teorema o non provata per mezzo di controesempi (testing) Si può tentare di sviluppare SW a priori corretto – Giusto processo e giusti tool 70 72 35 36 Limiti della correttezza La correttezza è una qualità assoluta (yes/no) – non c’è nessun concetto di “livello di correttezza” – non c’è alcun concetto di gravità della deviazione dalla correttezza E se la specifica è sbagliata? (a causa di requisiti scorretti o mancata conoscenza del dominio di applicazione) Alternative? – Ad es. garantire alcuni attributi con un livello fissato 73 SE knowledge areas Software requirements Software engineering process Software engineering management Software design Software engineering tools and methods Software construction Software testing Software maintenance Software quality 74 37