Il processo di produzione del SW
Sezione I: Introduzione, ciclo di vita del SW
PRIMA PARTE
Il processo di produzione del software
I.
II.
III.
IV.
Introduzione, ciclo di vita del SW
Qualità, standard
Test del SW
Project Management
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
I.1. – COS’È L’INGEGNERIA DEL
SOFTWARE
• Possibili definizioni
• Breve storia
• “Crisi” del SW
4
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
una o più 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 610.12-1990]
Æ applicazione dell’ingegneria al SW
5
Breve storia dell’Ing. Del SW
• Albori dell’informatica (~1945-55):
– problemi ben compresi e conosciuti (ad es., soluzione
equazioni differenziali);
– spesso, programmatore = utente
• Diffusione dei computer (~1955-65):
– 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
“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
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
Un problema temporaneo?
• Ipotesi:
– I ritardi nella consegna e gli sforamenti del budget
possono essere risolti con migliori:
• strumenti (di analisi, sviluppo, …)
• tecniche di management
• Realtà:
– “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
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
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
I.2. -- IL PRODOTTO
• Definizioni
• Concetti generali
• Cenni storici
• I problemi dello sviluppo del software
12
Definizioni
• Software:
– Creazione dell’intelletto che include programmi, strutture dati,
documentazione. L’esecuzione dei programmi realizza
(sperabilmente) le funzionalità previste.
• Prodotto Software:
– Insieme completo di programmi, procedure e relativa
documentazione, rilasciato ad un utente.
• Componente Software:
– Ogni parte identificabile di un prodotto software, sia in uno
stadio intermedio del processo di sviluppo, che al termine di
esso.
13
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
Classificazione delle applicazioni SW (2)
Rispetto alla natura degli elementi:
• Realizzazione di funzioni
• Gestione di dati (sistemi informativi)
• Controllo (sincronizzazione e cooperazione)
15
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
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
Prodotto industriale e prodotto
software
Prodotto Industriale
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.
•
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.
18
Prodotto industriale e prodotto
software (2)
Prodotto Industriale
Prodotto Software
Sono possibili:
• economie di scala
• processi di produzione e
distribuzione diversificati
in
funzione
delle
dimensioni del mercato a
cui il prodotto si rivolge.
• 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
Processo di sviluppo del software:
Insieme di:
• persone,
• 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
Prospettiva storica della produzione
del software
• 1950 - 1965: prima era
– batch, distribuzione limitata,
software customizzato
• 1964-1974: seconda era
– multiuser, Real-Time,
Database, software prodotto
• 1973-1987: terza era
– sistemi distribuiti, hardware
low-cost, mercato di massa
• 1985-1995: quarta era
– OO technologies, sistemi user
friendly, Powerful PC
• 1995-oggi: quinta era
– internet, distributed
computing, CORBA-DCOM,
component-ware, J2EE
21
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
Prospettiva storica del costo sw / hw
costo sw / costo hw
100
80
60
40
20
0
1950
2000
23
Prospettiva storica del costo del
software
costo sw / costo hw
100
80
60
sviluppo
40
20
1955
manutenzione
1965
1975
1985
ANDAMENTO DELLA LA SPESA PER IL SOFTWARE
24
Ripartizione del costo del software
15%
manutenzione e
modifiche
80%
manutenzione
46%
sviluppo
20%
verifica e
validazione
9%
dis.
e analisi
codifica
documentazione
10%
20%
% 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
Deterioramento e “guasti” hw e sw
% guasti
sw
(teoria)
% guasti
hw
tempo
tempo
% guasti sw
(comportamento osservato)
Cambiamenti
sw
tempo
26
Problemi nello sviluppo del SW
• IBM survey, 1994
– 55% 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
Alcuni famosi incidenti causati dal
Errore di
software
programmazione
• Therac-25: macchina per la radioterapia (1985-87).
Gestione SW della mutua esclusione errata.
http://sunnyday.mit.edu/therac-25.html
Errore di analisi
• Ariane 6: missile ESA (1996).
Eccezione lanciata (ADA) a causa di violazione di
assunzioni non documentate.
http://www.esa.int/export/esaCP/Pr_33_1996_p_EN.html
Errore di
• London Ambulance Service (1992).
management
Perdita di chiamate, duplicazione di dispatching.
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las.html
28
“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
I.3. -- IL PROCESSO
• Il processo di produzione del sw
• Fasi essenziali
30
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
Fasi essenziali del processo di
produzione sw
• Progetto
• Sviluppo
• 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
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
Elementi del processo di
produzione del sw
•
•
•
•
•
•
•
•
Insiemi di attività
Scadenze
Prodotti intermedi
Controlli qualità
Attività trasversali
Gestione del progetto
Metriche
ecc.
34
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
I.4. – MODELLI PER IL CICLO DI
VITA DEL SW
• Presentazione dei vari modelli
• Confronto
36
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
Visione caotica del processo
Definizione
del problema
Soluzione
tecnica
Stato
corrente
Integrazione
38
Visione caotica del processo (2)
Stato
corrente
Sfida: gestire in maniera ragionevole questi stadi coesistenti
39
Processo a cascata (waterfall, Royce 1970)
ANALISI
DESIGN
CODIFICA
TEST
MANUTENZIONE
Ispirazione dall’industria manufatturiera, reazione al “code and fix”
40
Fasi e prodotti del modello a cascata
• codifica
• analisi
– descrizione di cosa si
vuole realizzare
– definizione dei
requisiti
– realizzazione in un
linguaggio di
programmazione
– sorgenti
• test
• design
– progettazione del
sistema (come si vuole
realizzarlo)
– architettura e moduli
– verifica di aderenza, test
di modulo e di
integrazione
– documenti di test
• manutenzione
–gestione cambiamenti
41
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
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
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
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
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
Modello RAD (2)
Le cinque fasi:
1. Analisi dell’azienda:
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
Modello incrementale
analisi
progetto
codifica
test
versione 1
. . .
analisi
progetto
codifica
test
Simile al prototipale ma:
versione n
Prodotti
Funzionanti
• i prodotti intermedi sono funzionanti
• permette una più accurata progettazione e
programmazione dell’uso delle risorse
48
Modello incrementale (2)
Esempio (editore di testi):
1. Gestione file, editing, stampa documenti (core)
2. Correzioni ortografiche
3. Formattazione pagina
49
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
Primo prototipo
5)
Realizzazione e
rilascio
50
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
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
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
Realizzazione dei
componenti non
disponibili
Inserimento dei nuovi
componenti in libreria
Ispezione dei
componenti di libreria
Estrazione dei
componenti disponibili
Realizzazione dell’n-esima
iterazione del sistema
53
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
Ciclo di vita: modello XP
http://www.extremeprogramming.org/
55
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
Il mondo open source: alcuni link
• Eric S. Raymond's Home Page
• http://www.catb.org/~esr/
• Articolo “The Cathedral and the Bazaar”
– http://www.catb.org/~esr/writings/cathedral-bazaar/
– In italiano: http://www.apogeonline.com/openpress/doc/cathedral.html
– 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
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
Un esempio Open Source: ArgoUML
http://argouml.tigris.org/
59
Tecniche e linguaggi di quarta
generazione (2)
• Potenziali svantaggi:
– Strumenti difficili da usare (difficoltà paragonabile ai
linguaggi di programmazione convenzionali)
– Il codice generato potrebbe essere inefficiente
– La manutenzione è difficile
• L’approccio sembra essere indicato per
applicazioni di piccole dimensioni
• Non si risparmia tempo nell’analisi, progetto e test
60
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
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
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
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
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
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
}
66
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
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
Qualità del Prodotto Software
69
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
Fattori di qualità del SW
QUALITÀ ESTERNE
QUALITÀ INTERNE
Correttezza
Affidabilità
Robustezza
Sicurezza
Innocuità
Usabilità
Estendibilità
Riusabilità
Interoperabilità
Efficienza
Strutturazione
Modularità
Comprensibilità
Verificabilità
Manutenibilità
Portabilità
71
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
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
Usabilità
•
•
•
•
•
•
Enfasi sull’utente
Psicologia cognitiva
Fattori fisici/ergonomici
Mentalità dell’utente
Interfacce grafiche/visuali
Viene, spesso, totalmente ignorata
74
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
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
Interoperabilità
• Facilità di interazione con altri moduli al fine di
svolgere un compito più complesso
• Problemi tecnologici e semantici
• Favorisce la riusabilità
77
Nota sulle qualità esterne
• Correttezza
• Estendibilità
• Riusabilità
sono qualità chiave, fortemente favorite da un
approccio orientato agli oggetti
78
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
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
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
– il riuso
81
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
Manutenibilità/portabilità
• Manutenibilità: Facilità nell’effettuare modifiche
• Portabilità: Possibilità di riusare codice sorgente
– linguaggi compilabili su più piattaforme
– macchine virtuali (html/java)
83
Nota sulle qualità interne
• Strutturazione
• Modularità
sono caratteristiche di estremo interesse, favorite
dall’approccio orientato agli oggetti
84
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
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
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
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
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
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
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