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