Sei sulla pagina 1di 38

Ingegneria del Software

Introduzione

Lingegneria del software tratta la realizzazione di sistemi software (sw) di


dimensioni e complessit talmente elevate da richiedere uno o pi team di persone
per la loro costruzione.
La nascita e lo sviluppo del settore una conseguenza diretta dellaumento di complessit
dei programmi.
1940

I programmi sono sviluppati e utilizzati da una sola persona

1950

Nasce la figura del programmatore


Sono realizzati i primi grandi sistemi commerciali (OS 360 IBM)

1960

La complessit dei sistemi tale da richiedere figure e metodologie che


vedono il prodotto software come il risultato di una vera e propria
opera ingegneristica

1980

Il tempo dedicato alla progettazione supera il tempo dedicato alla programmazione

1990

Nasce la certificazione del software (ISO-9000)

2000

ISO-9000 si trasforma in Vision 2000


2

Definizioni
Lingegneria del software lapproccio sistematico allo sviluppo,
alloperativit, alla manutenzione e al ritiro del software.
S Lingegneria del software la disciplina tecnologica e manageriale
che riguarda la produzione sistematica e la manutenzione dei
prodotti software che vengono sviluppati e modificati entro i tempi e
i costi preventivati.
S Lingegneria del software un corpus di teorie,metodi e strumenti,
sia di tipo tecnologico che organizzativo, che consentono di
produrre applicazioni con le desiderate caratteristiche di qualit.
S

La qualit del software


Le qualit su cui si basa la valutazione di un sw possono essere classificate
in:
Interne:
Interne riguardano le caratteristiche legate allo sviluppo del sw; non sono
visibili agli utenti

Esterne:
Esterne riguardano le funzionalit fornite dal prodotto; sono visibili agli
utenti

Le due categorie sono ovviamente strettamente legate: non possibile ottenere le


qualit esterne se il sw non gode delle propriet interne

Relative al prodotto:
prodotto riguardano le caratteristiche stesse del sw e sono
sempre valutabili

Relative al processo:
processo riguardano i metodi utilizzati durante lo sviluppo del PC
sw.
4

La qualit del software (2)


E P
E P
E P
PC

Correttezza:
Correttezza un sw corretto se rispetta le specifiche di progetto
Affidabilit: un sw affidabile se lutente pu dipendere da esso
Robustezza:
Robustezza un sw robusto se si comporta in modo ragionevole anche in
circostanze non previste dalle specifiche di progetto (es. input incorretti, rotture di
dischi)
N.B. La valutazione della correttezza e dellaffidabilit basata sulle specifiche di progetto, mentre la
robustezza riguarda tutti i casi non trattati.

E P
E P

Efficienza:
Efficienza un sw efficiente se usa intelligentemente le risorse di calcolo

I P

Verificabilit: un sw verificabile se le sue caratteristiche (correttezza, performance,


ecc.) sono facilmente valutabili

PC

Facilit duso:
uso un sw facile da usare se linterfaccia che presenta allutente gli
permette di esprimersi in modo naturale

I P

Riusabilit: un sw riusabile se pu essere usato, in tutto o in parte, per costruire


nuovi sistemi

E P

Portabilit: un sw portabile se pu funzionare su pi piattaforme (es. Java)


5

La qualit del software (3)


I P

Facilit di manutenzione:
manutenzione un sw facile da manutenere non solo se strutturato in
modo tale da facilitare la ricerca degli errori (modifiche correttive) ma anche se la sua
struttura permette di aggiungere nuove funzionalit al sistema (modifiche perfettive) o
di adattarlo ai cambiamenti del dominio applicativo (modifiche adattative).
Costo del Software

30%
m. perfettive

E P
PC
PC
PC

15%

15%

m. adattative m. correttive

40%
altri costi

Interoperabilit: fa riferimento allabilit di un sistema di coesistere e cooperare con


altri sistemi (es. un word processor in cui possono essere creati grafici)
Produttivit: misura lefficienza del processo di produzione del software in termini di
velocit di consegna del sw.
Tempestivit: misura la capacit del processo di produzione del software di valutare
e rispettare i tempi di consegna del prodotto.
Trasparenza:
Trasparenza un processo di produzione del software si dice trasparente se
permette di capire il suo stato attuale e tutti i suoi passi

Software design: principi di base


Tutte le fasi della progettazione sono ispirate a un insieme di principi su cui si
basano le tecniche e i metodi utilizzati nelle fasi operative.
Formalit : lutilizzo di formalismi e di metodologie standardizzate nelle fasi di
progettazione, implementazione e documentazione del sistema permette di ridurre
fortemente gli errori di progetto (es. incompletezza, inconsistenza, ambiguit).
Anticipazione dei cambiamenti: la capacit di prevedere i cambiamenti a cui il
software sar sottoposto durante il suo ciclo di vita determina la sua semplicit di
manutenzione

Software design: principi di base (2)


Separazione degli argomenti:
argomenti indica la necessit di individuare i diversi aspetti
di un problema complesso e di trattarli separatamente al fine di semplificare la
soluzione. La suddivisione pu essere fatta sulla base del:
Tempo
Livello di qualit del software
Es. dapprima si progetta il software in modo corretto quindi lo si ristruttura
parzialmente al fine di aumentarne lefficienza
Argomento:
Argomento viste
Es. nella fase di analisi dei requisiti pu essere conveniente analizzare
distintamente i flussi di dati tra le diverse attivit e il flusso di controllo che le
governa
Dimensione:
Dimensione modularizzazione
Livello di astrazione

Software design
Con il termine software design si intende il processo che trasforma, attraverso numerosi
passi intermedi, le specifiche dellutente in un insieme di specifiche direttamente utilizzabili
dai programmatori. Il risultato del processo di design larchitettura del software,
software ossia
linsieme dei moduli che compongono il sistema, la descrizione della loro funzione, e delle
relazioni esistenti tra di essi.

Modularizzazione
Con il termine modulo si indica il componente di base di un sistema software. Un modulo
raccoglie un insieme di funzionalit tra loro strettamente legate e deve essere definito in
due fasi:
Design architetturale:
architetturale specifica il comportamento di un modulo in relazione allinterazione
con altri moduli.
Design di dettaglio:
dettaglio definisce le funzionalit di ogni singolo modulo, indicando quali
funzioni debbano essere realizzate e come debbano essere realizzate. Prevede la
definizione della sua interfaccia.
Un modulo si dice completamente specificato quando il livello di dettaglio delle specifiche
tale da permetterne uninterpretazione non ambigua da parte dellimplementatore.
9

Design architetturale
La suddivisione di un sistema in moduli rende necessario tener traccia delle
interazioni tra gli stessi. Le relazioni che devono essere descritte sono:

Di utilizzo (USES): indica quali moduli vengono utilizzati per completare i servizi forniti da un
particolare modulo.
Di composizione (IS_COMPONENT_OF): descrive la struttura del sistema a diversi livelli di
astrazione permettendo ai progettisti di realizzare una documentazione pi chiara e completa
(al termine della fase progettuale gli unici moduli che compongono il sistema sono quelli al
massimo livello di dettaglio).
Temporale:
Temporale descrive la sequenza con cui devono essere realizzati i diversi moduli.

Un valido strumento per la rappresentazioni di queste relazioni il grafo


M1

M2

M7

M3

M8

M4

M9

M5

M6

M2

M3

M5

M4
M6

USES

M1

IS_COMPONENT_OF
10

Design architetturale (2)


La strategia da utilizzare nella definizione dei moduli un elemento cruciale della fase di
progettazione. Sebbene lapproccio umano alla soluzione di un problema sia di tipo topdown, lapproccio bottom-up presenta caratteristiche interessanti:
TOP-DOWN

BOTTOM-UP

Decompone progressivamente i servizi in unit pi


piccole a partire da una visione globale ed astratta del
sistema

Aggrega le routine di base in moduli che descrivono il


sistema ad un livello di astrazione via via crescente

Garantisce che la progettazione sia fatta partendo da


una visione globale del sistema
Permette di realizzare una documentazione di pi
facile comprensione

Permette di analizzare in dettaglio le strutture dati


utilizzate dalle procedure
Facilita le operazioni di information hiding e di riutilizzo
del codice
Non comporta un prematuro irrigidimento della
struttura del sistema

Nella realt i progettisti non operano mai seguendo strettamente una sola strategia, ma
procedono in parte bottom-up e in parte top-down a seconda della fase del progetto e del tipo
di applicazione.
11

Design di dettaglio

Il design di dettaglio specifica le caratteristiche proprie di un modulo e indica al


programmatore quali servizi esso debba fornire.

Nella suddivisione delle funzionalit del sistema in moduli il progettista deve


considerare che:

Ogni modulo dovrebbe essere realizzato in modo indipendente da ogni altro


I programmatori devono essere in grado di operare su un modulo avendo una
conoscenza minima del contenuto degli altri
Tutti i servizi strettamente connessi devono appartenere allo stesso modulo

Particolarmente importante la definizione dellinterfaccia del modulo,


modulo ossia la
descrizione dei servizi fruibili da parte degli utilizzatori.

La definizione dellinterfaccia deve rispettare il concetto di information hiding:


hiding
linterfaccia deve cio contenere tutte le informazioni necessarie ad un corretto
utilizzo del modulo evitando di mostrarne i dettagli implementativi. Questo principio
permette ai progettisti di modificare limplementazione del modulo senza che ci
incida sulle altre componenti del sistema.
12

Design di dettaglio (2)


Linterfaccia di un modulo deve contenere tutte le informazioni necessarie al
corretto utilizzo del modulo stesso:
Funzionalit a disposizione: deve essere ben chiaro quali servizi sono realizzati dal
modulo
Modalit di fruizione di un servizio: per ogni servizio necessario indicare la
sequenza di routine da chiamare
Definizione dei parametri di input: il tipo, il numero e la semantica dei parametri di
input devono essere specificati in modo chiaro
Descrizione delloutput: semantica e tipologia dei valori restituiti dalle routine devono
essere completamente specificati. In particolare, per ogni routine deve essere presente
una tabella dei codici di errore che riporti, oltre al tipo dellerrore verificatosi, i motivi che
lo hanno provocato.

13

Anticipazione dei cambiamenti


La progettazione di un sistema informatico non deve mirare a soddisfare solo le specifiche
attuali ma deve prevedere anche quelle future. Tali cambiamenti possono essere:
Noti a priori: ogni software segue un cammino evolutivo rispetto alla sua prima release. Anche i
servizi che non vengono inizialmente implementati devono comunque essere presi in
considerazione durante la fase progettuale.
Non noti a priori: al fine di poter affrontare anche modifiche non prevedibili durante la fase di
design, la progettazione deve cercare di rendere il progetto facilmente modificabile (es. information
hiding).

I cambiamenti riguardano:
Periferiche e hardware
Dominio di applicazione
Algoritmi e Strutture dati: questi due elementi incidono fortemente sulle prestazioni del software.
Accade spesso che nelle prime versioni del software si utilizzino algoritmi e strutture dati semplici al
fine di velocizzare il completamento del sistema e di rendere pi facile il debugging

14

Progettazione a oggetti
La progettazione a oggetti la tecnica che, grazie al concetto di ereditariet e ad un
massiccio utilizzo di tecniche di astrazione dei dati, meglio si presta allimpiego in un
corretto processo di ingegnerizzazione.
Separazione degli argomenti:
argomenti lereditariet permette di concentrarsi
caratteristiche comuni a pi classi e sulle peculiarit delle singole.

separatamente sulle

Modularit
Modularit: il principio della modularizzazione intrinseco al concetto di classe e di interfaccia. La
possibilit di limitare la visione di algoritmi (metodi) e strutture dati allinterno della classe realizza
appieno il principio dellinformation hiding.
Astrazione:
Astrazione concetti a diversi livelli di astrazione e dettaglio possono essere definiti tramite
lereditariet.
Anticipazione dei cambiamenti:
cambiamenti facilitata dalla possibilit di derivare nuovi concetti a partire da
quelli gi esistenti.
Generalit
Generalit: tramite lereditariet possibile definire una classe con caratteristiche molto specialistiche
a partire da una (o pi) classi generali.
15

Specifica dei requisiti


La specifica dei requisiti un accordo tra il produttore di un servizio e il suo
consumatore.
Nelle diverse fasi della progettazione le specifiche devono essere fornite ad un
diverso livello di dettaglio:
Requirement specification: con cui lutente finale e il progettista si accordano sulle
funzionalit messe a disposizione dal software. La difficolt per questo tipo di specifica
data dalla diversit dei linguaggi usata dalle due parti.
Design Specification: con cui il progettista e i programmatori si accordano sulle
caratteristiche strutturali dei moduli da implementare e sui servizi da mettere a
disposizione.
Module Specification: con cui i programmatori che implementano un particolare
modulo e i programmatori che lo utilizzano decidono le modalit di fruizione dei servizi
(interfacce).

16

Qualit per le specifiche dei requisiti


Chiarezza:
Chiarezza ogni specifica deve indicare quanto pi chiaramente possibile le operazioni e i soggetti del
processo che descrive.
La selezione il processo che permette di determinare larea del documento su cui si vuole operare. La maggior
parte delle operazioni di editing richiedono due fasi: nella prima si seleziona loggetto su cui si vuole operare; nella
seconda si avvia lazione appropriata.
Cosa si intende per area su cui si vuole operare ?

Non ambiguit
ambiguit : il processo descritto dalla specifica deve essere definito in modo completo e
dettagliato
Il messaggio deve essere triplicato. Le tre copie devono essere inviate su tre diversi canali ad uno stesso soggetto
ricevente che accetter il messaggio utilizzando una politica del tipo 2 di 3.
Il ricevente deve aspettare il ricevimento di tutti i messaggi prima di applicare la politica di decisione ?

Consistenza:
Consistenza le specifiche non devono contenere punti contraddittori
Il testo deve essere formattato in linee di uguale lunghezza (specificata dallutente). A meno che lutente non lo
specifichi esplicitamente, una parola non pu essere interrotta da un commando di carriage return.
Cosa accade se una parola pi
pi lunga del limite definito dall
dallutente ?

17

Linguaggi per la specifica dei requisiti


La diversit degli obiettivi posti dalla specifica dei requisiti implica lutilizzo di notazioni
diverse per la rappresentazione delle informazioni.
Formalismi operazionali:
operazionali definiscono il sistema descrivendone il comportamento
(normalmente mediante un modello).
E il percorso che si ottiene muovendosi in modo che la somma delle distanze tra due punti fissi p1 e
p2 rimanga invariata

Formalismi dichiarativi:
dichiarativi definiscono il sistema dichiarando le propriet che esso deve
avere.
ax2+by2+c=0
Lapproccio operazionale fornisce una rappresentazione pi semplice poich pi simile al modo di
ragionare della mente umana:
Facilit di acquisizione
Facilit di verifica della correttezza
Facilit di comprensione da parte dei programmatori
Lapproccio dichiarativo fornisce una rappresentazione che non si presta ad ambiguit
18

Linguaggi per la specifica dei requisiti (2)


Linguaggio Z:
Z formalismo dichiarativo utilizzato a livello di specifica dei requisiti. Permette di definire
gli stati del sistema e le operazioni possibili (cosa non come)
Diagrammi di flusso:
flusso formalismo operazionale che descrive le funzionalit di un sistema visto come
una collezione di dati manipolati da funzioni

c
d

(a+b)(c+ad)

+
Automi a stati finiti:
finiti formalismo operazionale
che descrive il flusso di controllo di un sistema

Push
Interruttore

On

Off
Push

Reti di Petri:
Petri formalismo operazionale che
descrive il flusso di controllo di un sistema
e permette di modellare sistemi concorrenti
e sistemi non deterministici.
19

Verifica del software

La fase di verifica del software ha lo scopo di controllare se il sistema realizzato


risponde alle specifiche di progetto.
Le tecniche di verifica del sw possono essere classificate come:
Dinamiche o di testing: il corretto funzionamento del sistema viene controllato sulla
base di prove sperimentali che ne verifichino il comportamento in un insieme
rappresentativo di situazioni.
Statiche o di analisi: il corretto funzionamento del sistema viene verificato analizzando
direttamente la struttura dei moduli e il codice che li realizza.

20

Testing
Le operazioni di testing possono individuare la presenza di errori nel software ma
non possono dimostrarne la correttezza (Dijkstra 1972)
Scopo del testing quello di verificare il comportamento del sistema in un insieme
di casi sufficientemente ampio da rendere plausibile che il suo comportamento sia
analogo anche nelle restanti situazioni.
Vista limpossibilit pratica di verificare un sistema in tutte le possibili circostanze
(testing esaustivo) necessario individuare dei criteri per la selezione dei casi
significativi.
Le operazioni di testing si suddividono in:
Testing in the small:
small riguardano moduli singoli e porzioni specifiche del codice che
rivestono una particolare importanza o che hanno una particolare complessit
Testing in the large:
large riguardano il sistema nella sua globalit
21

Testing in the small


Valuta il corretto funzionamento di una porzione del codice analizzando in modo
approfondito il suo comportamento in relazione allinput.

Grafi di controllo
x>0

x0

x>0
x=3

Assegnamento

x>0

x0

x0

if then

if then else

while

22

Testing in the small


Criterio di copertura dei programmi (statement test)
Selezionare un insieme di test T tali che, a seguito dellesecuzione del programma P su
tutti i casi di T, ogni istruzione elementare di P venga eseguita almeno una volta

Si basa sullosservazione che un errore non pu essere scoperto se la parte di


codice che lo contiene non viene eseguita almeno una volta
Pu essere eseguito solo conoscendo la struttura interna della porzione di
codice (white-box testing)
testing
read(x);
read(y);
if x!=0 then x:=x+10;
y:=y/x;
.......

test={(x=20, y=30)}

23

Testing in the small (2)


Criterio di copertura delle decisioni ( branch test)
Selezionare un insieme di test T tali che, a seguito dellesecuzione del programma P su
tutti i casi di T, ogni arco del grafo di controllo di P sia attraversato almeno una volta

Il criterio richiede che per ogni condizione presente nel codice sia utilizzato un
test che produca il risultato TRUE e FALSE
Si basa sul flusso di controllo e non sullinsieme di istruzioni
Pu essere eseguito solo conoscendo la struttura interna della porzione di
codice (white-box testing)
read(x);
read(y);
if (x=0 or y>0)
then y:=y/x;
else x:=y+2/x;
.......

test={(x=5, y=5), (x=5, y=-5)}

24

Testing in the small (3)


Criterio di copertura delle decisioni e delle condizioni
Selezionare un insieme di test T tali che, a seguito dellesecuzione del programma P su
tutti i casi di T, ogni arco del grafo di controllo di P sia attraversato e tutti i possibili valori
delle condizioni composte siano valutati almeno una volta

Il criterio richiede che, per ogni porzione di condizione composta presente nel
codice, sia utilizzato un test che produca il risultato TRUE e FALSE.
Il criterio produce unanalisi pi approfondita rispetto al criterio di copertura delle
decisioni
Pu essere eseguito solo conoscendo la struttura interna della porzione di
codice (white-box testing)

25

Testing in the small (4)


1.
2.
3.
4.
5.
6.
7.
8.

read(x);
read(y);
if (y=0)
then x:=x+1;
y:=y/x;
if (x>0)
then print(x);
else print(y);

read(x)

read(y)

y=0
x:=x+1

y0

y=y/x

test1={(x=2, y=10), (x=-2, y=0)}

x>0
print(x)

5
x0

test2={(x=2, y=10), (x=-1, y=0)}

print(y)

end

Entrambi i test set soddisfano il criterio di copertura delle decisioni e delle condizioni,
ma solo test2 permette di individuare lerrore.

26

Testing in the large


Lesplosione combinatoria delle possibili situazioni che si hanno quando si esaminano
sistemi di grandi dimensioni rende impossibile lutilizzo di tecniche white-box.
Si rende quindi necessario valutare il funzionamento del sistema sulla base delle
corrispondenze input-output. Il sistema considerato una scatola nera (black-box
testing).
testing
Linsieme di test da utilizzare viene selezionato sulla base delle specifiche di progetto che
permettono di definire i diversi valori di input e i corrispondenti valori in output.
Il programma riceve come input una fattura di cui nota la struttura dettagliata. La fattura deve essere inserita in
un archivio ordinato per data. Se esistono altre fatture con la stessa data fa fede lordine di arrivo. inoltre
necessario verificare che: 1) il cliente sia gi stato inserito in archivio, vi sia corrispondenza tra la data di
inserimento del cliente e quella della fattura, ....

Test Set
1) Fattura con data odierna
2) Fattura con data passata e per la quale esistono altre fatture
3) Fattura con data passata e per la quale non esistono altre fatture
4) Fattura il cui cliente non stato inserito.
....
27

Testing in the large (2)


Test di modulo:
modulo verifica se un modulo stato implementato correttamente in
base al suo comportamento esterno.
Test dintegrazione:
integrazione verifica il comportamento di sottoparti del sistema sulla
base del loro comportamento esterno. Viene solitamente svolto simulando il
comportamento dei moduli che producono linput del sottosistema in analisi.
Test di sistema:
sistema verifica il comportamento dellintero sistema sulla base del suo
comportamento esterno.
Il test dintegrazione permette di:
1) Anticipare la scoperta di eventuali errori alla fase di sviluppo
2) Semplificare la ricerca degli errori poich questi risultano circoscritti alla
sottoporzione in esame
3) Permettere il rilascio di sottoparti autonome del sistema

28

Analisi del software


Analizzare un software significa ispezionarne il codice per capirne le
caratteristiche e le funzionalit.
Pu essere effettuata sul codice oppure su pseudocodice.
Permette la verifica di un insieme di esecuzioni mentre il testing verifica
singoli casi
soggetta agli errori di colui che la effettua
Si basa su un modello della realt e non su dati reali
I due principali approcci allanalisi del software sono Code walk-through e
Code inspection

29

Code walk-through
un tipo di analisi informale eseguita da un team di persone che dopo aver
selezionato opportune porzioni del codice e opportuni valori di input ne simulano
su carta il comportamento.
Il numero di persone coinvolte deve essere ridotto (3~5)
Il progettista deve fornire in anticipo la documentazione scritta relativa al
codice
Lanalisi non deve durare pi di alcune ore
Lanalisi deve essere indirizzata solamente alla ricerca dei problemi e non
alla loro soluzione
Al fine di aumentare il clima di cooperazione allanalisi non devono
partecipare i manager

30

Code inspection
Lanalisi, eseguita da un team di persone e organizzata come nel caso del code
walk-through, mira a ricercare classi specifiche di errori. Il codice viene
esaminato controllando soltanto la presenza di una particolare categoria di
errore, piuttosto che simulando una generica esecuzione.
Le classi di errori che vengono solitamente ricercate con questa tecnica sono:

Uso di variabili non inizializzate


Loop infiniti
Letture di dati non allocati
Deallocazioni improprie di memoria

31

Verifica dellaffidabilit
Limpossibilit di garantire la totale assenza di errori nel sistema rende
necessario valutare e verificare laffidabilit del sw.
Laffidabilit di un sistema viene valutata in termini probabilistici:
AF(t):
AF(t)
FI(t):
FI(t)
MTTF(t):
MTTF(t)

numero totale di errori verificatisi fino al momento t. Il valore pu essere


mediato sui dati ottenuti in diverse installazioni del medesimo sistema.
numero di errori per unit di tempo verificatisi sino al momento t.
tempo medio tra due errori: 1/FI(t).

Il concetto di tempo preso in considerazione dipende dallo scopo della misura:


Tempo di esecuzione:
esecuzione indica la quantit di tempo per cui il software stato eseguito
Tempo di calendario:
calendario include anche gli intervalli di tempo durante i quali il sistema non in
funzione
Tempo di clock
clock:
considera solo il tempo di CPU dedicato al processo(i) relativi al sistema

32

Verifica dellaffidabilit (2)


Determinare la distribuzione con cui si verificano gli errori in un sistema informatico un
problema estremamente complesso. Si assume quindi che gli errori di programmazione e
i loro effetti siano distribuiti uniformemente.
Modello di base:
base

assume che il decremento dei fallimenti del sistema sia costante. Questo
modello si basa sullipotesi che la diminuzione degli errori sia diretta
conseguenza delle correzioni apportate al codice a fronte del verificarsi di
una anomalia. Tale ipotesi ottimistica poich assume che la difficolt di
individuare ed eliminare gli errori non cresca nel tempo.
Modello logaritmico:
logaritmico considera crescente (in modo esponenziale rispetto al tempo) la difficolt di
correzione degli errori

FI

AF

Modello logaritmico

Modello di base
AF()

FI(0)
Modello logaritmico

Modello di base
FI()

t
33

Il processo di produzione del software

Il processo di produzione la sequenza di operazioni che viene seguita per


costruire, consegnare e modificare un prodotto.
Il ciclo di vita di un software linsieme di stadi in cui il sistema viene a trovarsi
La complessit dei sistemi informatici e lelevata instabilit del processo di
costruzione dovuta alla volubilit del mercato rendono necessaria ladozione di
modelli potenti e flessibili:

Modello a cascata

Modello evolutivo

34

Il modello a cascata
Introdotto nel 1970 rappresenta lo
standard per la produzione di
sistemi informatici. Loutput di ogni
fase rappresenta linput della
successiva.

Studio di
fattibilit
Analisi dei
requisiti
Progettazione
Implementazione
e test dei moduli
Integrazione
e test del sistema
Consegna
Manutenzione

35

Il modello a cascata (2)


Studio di fattibilit: scopo di questa fase la produzione di un documento che valuti i
costi e i benefici dellapplicazione proposta. Tale documento deve contenere:
La definizione del problema
Le possibili soluzioni e le relative motivazioni
Per ognuna delle soluzioni proposte la stima dei benefici, dei costi, delle risorse richieste e dei
tempi di consegna.

Analisi dei requisiti:


requisiti ha lo scopo di determinare le funzionalit richieste dal cliente e le
propriet del software in termini di performance, facilit duso, portabilit, facilit di
manutenzione, ecc.
Al fine di lasciare la massima libert al progettista necessario specificare cosa deve
essere fatto e non come. Il risultato di questa fase un documento che:
Permette al cliente di verificare le caratteristiche specificate
Rappresenta linput per la fase di progettazione

Strettamente legata alla specifica dei requisiti la definizione delle modalit di test del
sistema.
36

Il modello a cascata (3)


Progettazione:
Progettazione scopo di questa fase la produzione di un documento
contenente una descrizione dellarchitettura del software sia a livello
architetturale sia al livello dei singoli moduli.
Imlementazione e test dei moduli:
moduli la fase in cui i programmi vengono
effettivamente realizzati dai programmatori i quali si occupano di effettuare i test
sulle funzionalit inerenti i singoli moduli.
Integrazione e test del sistema:
sistema questa fase ha lo scopo di assemblare il
codice prodotto dai diversi gruppi di programmatori e verificarne leffettiva
compatibilit risolvendo eventuali errori derivanti dallinterazione di due o pi
moduli. Non sempre questa fase viene considerata concettualmente distinta
dalla fase di implementazione.

37

Il modello a cascata (4)


Consegna:
Consegna in questa fase il sistema viene distribuito agli utenti che ne verificano
sul campo il funzionamento, individuando eventuali malfunzionamenti o
dissimilarit rispetto alle specifiche di progetto. La consegna avviene in due fasi:
Beta testing: il sistema viene distribuito ad un selezionato insieme di utenti allo scopo
di effettuare test in casi reali. Gli errori riscontrati dovrebbero essere corretti prima della
distribuzione effettiva del prodotto.
Distribution: il sw viene definitivamente rilasciato agli utenti. Gli errori che vengono
riscontrati dopo tale rilascio vengono solitamente corretti nelle versioni successive o
tramite lutilizzo di appositi software correttivi (patch).

N.B: Il costo di eliminazione di un errore tanto pi alto quanto pi tardi lerrore


viene determinato

38

Il modello a cascata (5)


ATTENZIONE
nelle situazioni reali il modello a cascata potr essere riprodotto solo
approssimativamente.
Il modello a cascata un modello ideale e deve servire solo come riferimento per
disciplinare il comportamento dei membri del progetto.
1) difficile per lutente fornire delle specifiche dettagliate prima di cominciare a utilizzare il
sistema.
2) difficile stimare accuratamente le risorse necessarie quando disponibile un numero limitato di
informazioni.
3) Il modello non permette di modificare i risultati delle fasi precedenti alla luce di errori riscontrati a
posteriori.

Si evidenzia quindi la necessit di una maggiore flessibilit che in prima istanza pu


essere ottenuta semplicemente permettendo di muoversi allindietro lungo le fasi del
modello a cascata (modello a fontana),
fontana oppure adottando principi di progettazione pi
innovativi.
39

Il modello evolutivo
La necessit di rendere pi flessibile il processo di ingegnerizzazione del software ha
portato allo sviluppo del modello evolutivo basato sul principio Do it twice
La progettazione avviene in due fasi, di cui la prima d vita ad un prototipo che ha lo
scopo di fornire il feedback necessario a individuare con esattezza tutte le caratteristiche
del sistema e tutti gli errori di progettazioni effettuati.
1) Ingegnerizzazione del prototipo
2) Valutazione del comportamento del sistema
3) Ingegnerizzazione/miglioramento del sistema

Ovviamente, perch ladozione di questo modello non comporti costi troppo elevati
necessario che i progettisti siano coscienti della funzione del prototipo e che tutte le fasi
del processo siano basate su un criterio di massima riusabilit delle componenti
sviluppate:
1) Massimizzare la modularizzazione
2) Ingegnerizzare le sole componenti critiche nel prototipo
40

Gestione dellingegnerizzazione
La complessit del processo di ingegnerizzazione richiede una figura specifica per
gestirne la progettazione e il controllo. Si definisce management
la creazione e il controllo di un ambiente interno allazienda in cui pi individui, lavorando
in gruppo, realizzano gli obiettivi prefissatisi in modo efficiente.
I principali compiti attribuibili a tale figura sono:
Pianificazione:
Pianificazione il manager deve indicare e documentare gli obiettivi da raggiungere, le risorse e le
professionalit necessarie, nonch la sequenza di operazioni da eseguire.
Organizzazione:
Organizzazione riguarda la necessit di definire le relazioni di autorit e responsabilit allinterno
del gruppo di lavoro, nonch le possibili forme di collaborazione instaurabili tra i diversi sotto-gruppi.
Acquisizione del personale:
personale limportanza della risorsa umana nel processo di ingegnerizzazione
del sw richiede al manager una particolare attenzione nel reclutare e addestrare il personale da
inserire nel gruppo di lavoro.
Direzione e controllo:
controllo durante tutto lo svolgimento del processo, il manager deve monitorare
landamento del progetto al fine di individuare e correggere le azioni dello staff qualora
conducessero a deviazioni dagli scopi del progetto.
41

4
S

Stima dei costi


Fonti di costo
Costo delle risorse per lo sviluppo del sw (costo diretto):

costo del personale tecnico


costo del personale di supporto
costo delle risorse informatiche
materiali di consumo
costi generali della struttura

Costo per lindisponibilit di unapplicazione (costo indiretto)


S

Fattori di costo

Numero di istruzioni da codificare (benefici del riuso)


Capacit, motivazione e coordinamento degli addetti allo sviluppo
Complessit del programma
Stabilit dei requisiti
Caratteristiche dellambiente di sviluppo
42

Le dimensioni del software


S

Metriche dimensionali
si basano sul numero di istruzioni del programma
LOC (Lines Of Code) o DSI (Delivered Source Instructions)
M = mesi uomo tot., E = numero tot. errori, $ = costo tot., PD = pagine doc.
Produttivit:
P = LOC/M
Qualit:
Q = E/LOC
Indici di qualit
Costo unitario:
C = $/LOC
Documentazione: D = PD/LOC

Metriche funzionali
si basano sulle caratteristiche funzionali del programma
Metodo dei Punti Funzione (Function Points)

43

Metodo Function Points


Permette di stimare la complessit di un sistema sw. La complessit, riassunta in un
unico valore, viene calcolata come somma pesata dei fattori appartenenti alle seguenti
categorie:

Elemento
Input
Output
Domande
File
Interfacce

Peso

Peso

Peso

(semplice)

(medio)

(complesso)

3
4
3
7
5

4
5
4
10
7

6
7
6
15
10

VPi

Input:
Input Numero di gruppi di input che lutente fornisce al sistema
Output:
Output Numero di gruppi di output che il sistema restituisce
Domande:
Domande Numero distinto di domande formulate interattivamente dal sistema durante
lesecuzione dei task
File:
File Numero di file che contengono informazioni necessarie per il funzionamento del sistema
Interfacce:
Interfacce Numero di collegamenti ad altri sistemi
44

Metodo Function Points (2)


5

FP = VPi
i= 1

14

0.65 + 0.001 Fi

i= 1

dove gli Fi sono 14 parametri di aggiustamento calcolati in base a


un questionario sulle prestazioni richieste, le modalit di
trasmissione dati, gli obiettivi di riusabilit,ecc.

45

Il numero ciclomatico
Modello di metrica del software proposto da McCabe nel 1976
S Il numero ciclomatico una definizione operativa di complessit del
flusso di controllo di un programma, ed legato allidentificazione di
tutti i cammini che permettono di raggiungere una copertura
accettabile del programma
S

Misura della sola complessit del software intesa in riferimento alla sua
produzione, comprensione e modifica
Viene preso in considerazione il solo flusso di controllo, senza alcun
riferimento alla complessit dei dati (grafo del flusso di controllo)
Metrica svincolata dalle particolarit di un linguaggio

46

Il numero ciclomatico (2)


S

Cammini di base: cammini completi (a partire dal nodo iniziale


raggiungono il nodo terminale del grafo del flusso di controllo) le cui
combinazioni lineari esauriscono lo spazio di tutti i cammini
completi di un programma
ESEMPIO: numero dei cammini di base = 2

In un grafo fortemente connesso il numero dei


cammini linearmente indipendenti si calcola come:
e-n+1
dove e il numero degli archi ed n il numero
dei nodi
47

Il numero ciclomatico (3)


S

Il grafo del flusso di controllo di programma non risulta fortemente


connesso
Se il programma ben formato esiste sempre almeno un cammino che
permette di collegare il nodo iniziale con uno qualunque degli altri nodi
ed esiste sempre almeno un cammino che permette di collegare uno
qualunque dei nodi con il nodo terminale
Si rende fortemente connesso il grafo del flusso di controllo di un
programma aggiungendo un arco orientato che va dal nodo terminale
al nodo iniziale (+ 1 arco)

Il numero ciclomatico, assunto come misura della complessit del


flusso di controllo del programma, il numero dei cammini
linearmente indipendenti del grafo G modificato, v(G):
v(G) = e - n + 2
48

Il numero ciclomatico (4)


v(G)=1

v(G)=2

ESEMPI:

v(G)=2

v(G)=2
49

Il numero ciclomatico (5)


S

Teorema di Mills:
v(G) = d + 1
dove d il numero dei punti di decisione del programma
(assumendo che un punto di decisione a k uscite contribuisca come
k-1 punti di decisione a 2 uscite)

Se il programma ha procedure al suo interno, il numero ciclomatico


dell'intero grafo dato dalla somma dei numeri ciclomatici dei
singoli grafi indipendenti:
v(G) = e - n + 2p
dove e ed n sono rispettivamente archi e nodi del grafo nel suo
insieme, p il numero di grafi (procedure) indipendenti
50

Il numero ciclomatico (6)


Il numero ciclomatico cattura almeno in parte ci che intuitivamente
la complessit del flusso di controllo
S Esistono conferme sperimentali che indicano che si ha un buon
grado di correlazione tra il numero ciclomatico e grandezze
sicuramente influenzate notevolmente dalla complessit del flusso
di controllo, come ad esempio il numero degli errori riscontrati
S Raccomandazione: la complessit ciclomatica di un modulo non
deve superare il valore 10
S

51

Stima dei costi di sviluppo:


COnstructive COst MOdel
Si calcola una stima iniziale in base alla dimensione del software da produrre, poi
la si migliora sulla base di un insieme di parametri
Ciclo di vita di riferimento:

Pianificazione e analisi dei requisiti


Progetto
Sviluppo
Integrazione e test

Modello intermedio
1) Stima della dimensione del software:
software calcolata come numero di linee di codice
scritte (KDSI), pu essere fatta sulla base dellesperienza del manager oppure
utilizzando una tecnica analitica basata, ad esempio, sul metodo FP:
FP
1000
1000
1000
1000

CLang
20 (Cobol)
32 (Pascal)
40 (C++)
88 (Assembler)

#Linee
20000
32000
40000
88000
52

COnstructive COst Model (2)


2) Determinazione della classe del software:
software i sw sono suddivisi in tre categorie con
caratteristiche di difficolt crescente. Per ogni categoria stata sviluppata una diversa
formula per il calcolo del costo, espresso in mesi uomo:
Organic
MNom=3.2KDSI 1.05
Semi-detached
MNom=3.0KDSI 1.12
Embedded
MNom=2.8KDSI 1.2
Lappartenenza ad uno dei tre profili viene determinata sulla base dei seguenti parametri:
Organic
Conoscenza richiesta nel settore applicativo
Esperienza del team nello sviluppo di software dello
dello stesso
stesso tipo
tipo
Necessit
esterni
Necessit di comunicare con sistemi esterni
Presenza di vincoli di progetto
Necessit
Necessit di sviluppare apparecchiature hardware
Necessit
Necessit di sviluppare strutture dati e algoritmi innovativi
Esistono premi per la consegna anticipata
Dimensione del prodotto

Semi-det.

Embedded

Limitata
Normale
Completa
Estesa Considerevole Moderata
Limitata Considerevole Elevata
Limitata Considerevole Elevata
Limitata
Normale
Elevata
Limitata
Normale
Elevata
Bassi
Normali
Elevati
<50 KDSI
<300 KDSI
>300 KDSI

53

COnstructive COst Model (3)


3) Applicazione degli stimatori di costo:
costo

15

M = M Nom ci
i= 1

Molto Bassa

Bassa

Normale

Alta

Molto Alta

Extra

0.75
0.70

0.88
0.94
0.85

1.00
1.00
1.00

1.15
1.08
1.15

1.40
1.16
1.30

1.65

1.11
1.06
1.00
1.07

1.30
1.21
1.15
1.15

1.66
1.56
1.30

0.87

1.00
1.00
0.87
1.00

1.46
1.29
1.42
1.14
1.21

1.19
1.13
1.17
1.07
1.10

1.00
1.00
1.00
1.00
1.00

0.86
0.91
0.86
0.95
0.90

0.71
0.82
0.70

1.24
1.24
1.23

1.10
1.10
1.08

1.00
1.00
1.00

0.91
0.91
1.04

0.82
0.83
1.10

Propriet
Propriet del prodotto
- Affidabilit del software richiesto
- Complessit della base di dati
- Complessit del prodotto

Caratteristiche dell hardware


- Vincoli di efficienza
- Vincoli di memoria
- Variabilit dellambiente di sviluppo
- Tempi di risposta

Caratteristiche del team


- Capacit degli analisti
- Esperienza nella classe di applicazioni
- Capacit dei programmatori
- Esperienza nel linguaggio di programmazione
- Esperienza nellambiente di sviluppo

Caratteristiche del progetto


progetto
- Modernit del processo di sviluppo
- Utilizzo di tool di sviluppo
- Presenza di un piano temporale di sviluppo

54

Organizzazione delle risorse umane


Limportanza rivestita dalle risorse umane nellingegnerizzazione del software rende
lorganizzazione dei gruppi di lavoro un momento critico del processo.
Quale la durata del progetto ?
Un progetto di lunga durata richiede al manager di porre particolare attenzione alla soddisfazione
delle persone che vi partecipano al fine di mantenere elevata la produttivit e di evitare labbandono
dei membri del gruppo.
Quale la natura del sistema ?
Lingegnerizzazione di un sistema complesso richiede una struttura che permetta unelevata
possibilit di comunicazione ed interazione tra i membri, mentre nel caso le problematiche del
sistema siano ben note necessario ridurre al minimo i rallentamenti dovuti a interazioni superflue.
Quale la natura dei task da realizzare ?
La natura e la complessit dei task da realizzare deve essere determinata al fine di determinare la
corretta cardinalit del gruppo di lavoro (tra 3 e 8).

55

Organizzazione delle risorse umane (2)


Gruppi di lavoro a controllo centralizzato
Si basano su una struttura gerarchica in cui pi persone sono controllate da un supervisore che
responsabile per il loro operato.
Sono adatti a progetti brevi e in cui la ridotta difficolt del progetto non richiede elevate
comunicazioni tra gli sviluppatori.
Nel caso in cui un supervisore non svolga correttamente la sua funzione, il lavoro di tutte le
persone di cui responsabile pu risultare compromesso.

Gruppi di lavoro a controllo distribuito


Le decisioni vengono prese sulla base del consenso degli appartenenti al gruppo.
Loperato dei singoli viene verificato dagli altri appartenenti al team.
Porta ad un elevato livello di comunicazione, utile quando la complessit del problema tale da
richiedere uno sforzo comune per individuare la soluzione.
Non adatto nel caso di gruppi numerosi in cui leccesso di comunicazione potrebbe comportare
una diminuzione della produttivit.

Controllo Distribuito

Controllo Semi-Distribuito
Semi-Distribuito
56

La normativa ISO 9000

La Comunit Europea basa il sistema di controllo della qualit nei diversi settori della
produzione su due distinte classi di regole:
Regole tecniche: sono emesse dalla pubblica amministrazione e dagli organi dello Stato
(leggi, decreti e regolamenti) nel rispetto delle regole comunitarie (direttive); la loro
osservanza ha carattere obbligatorio.
Norme tecniche consensuali: sono elaborate e pubblicate dagli organismi di
normazione riconosciuti con la collaborazione anche di rappresentanti governativi e
possono avere validit nazionale (UNI e CEI), europea (EN), internazionale (ISO e IEC).
La loro applicazione non obbligatoria, ma pu essere imposta da opportune direttive,
leggi o regolamenti.
Le norme tecniche consensuali rappresentano una razionalizzazione dei molti approcci
utilizzati tra clienti e fornitori per garantire la qualit del prodotto o del servizio.

La famiglia di norme ISO 9000 ricade tra le norme tecniche consensuali.


consensuali.
57

La normativa ISO 9000 (2)


Gli obiettivi primari delle norme della famiglia ISO 9000 sono due:
Gestione per la qualit: offrono una guida alle aziende che desiderano progettare e
attuare un efficace sistema qualit nella loro organizzazione o migliorare il sistema di
qualit esistente. Uno degli obiettivi principali della gestione per la qualit il
miglioramento delle attivit e dei processi. Le norme interessate in tale ambito sono la
ISO 9000-1 e ISO 9004-X.
Assicurazione della qualit: definiscono i requisiti generali a fronte dei quali un cliente
valuta ladeguatezza del sistema qualit del fornitore, nonch la sua capacit di
soddisfare i requisiti stabiliti. Le norme che definiscono i requisiti dellassicurazione della
qualit sono la ISO 9001 9002 9003. I tre modelli descritti da queste norme sono
progettati per guidare le aziende con diverse esigenze di assicurazione della qualit
esterna in tutte le attivit, dalla progettazione allassistenza post-vendita. I tre modelli
proposti non rappresentano diversi livelli di competitivit, bens la piattaforma della
conformit.

58

La normativa ISO 9000 (3)


Gestione per la qualit

Assicurazione della qualit esterna

Ha come obiettivo il raggiungimento dei risultati


di qualit pianificati.

Ha come obiettivo la dimostrazione della


soddisfazione dei requisiti della qualit e la
dimostrazione
del
raggiungimento
e
mantenimento dei livelli qualitativi richiesti.
Stimolata dalle parti interessate esterne
allorganizzazione.
Gli obiettivi sono orientati alla soddisfazione del
cliente.
Garantire la confidenza del risultato atteso ai
prodotti dellorganizzazione (efficacia).
Dimostrare che tutte le attivit che hanno
diretto impatto sui risultati dei processi e dei
prodotti sono sotto controllo.

Stimolata dalla direzione e dalle parti


interessate interne allorganizzazione.
Gli obiettivi sono orientati alla soddisfazione di
tutte le parti interessate.
Prestazioni di livello superiore (orientata verso
lefficacia e lefficienza).
Lo scopo quello di coprire tutte le attivit che
hanno impatto su tutti i risultati del business
dellazienda.

59

La normativa ISO 9000 (4)


La famiglia ISO 9000 comprende tutte le norme elaborate dal comitato tecnico ISO/TC
176, in particolare:
le norme da ISO 9000 a ISO 9004
le norme da ISO 10001 a ISO 10020
la norma ISO 8402 e ISO 9126

ISO9001
9001
ISO
Sistema
Qualit
Sistema Qualit

Progettazione, Sviluppo,
Progettazione, Sviluppo,
Fabbricazione
Fabbricazione
Installazione,
Assistenza
Installazione, Assistenza

ISO9000-3
9000-3
ISO
Guida
per
software
Guida per ililsoftware

ISO9000
9000
ISO
Qualit
Qualit
ConcettieeGuida
Guida
Concetti

ISO9002
9002
ISO
Sistema
Qualit
Sistema Qualit

Fabbricazione
Fabbricazione
Installazione, Assistenza
Installazione, Assistenza

ISO9126
9126
ISO
Specifiche
perlala
Specifiche per
qualitdel
delsoftware
software
qualit

ISO8402
8402
ISO
Qualit
Qualit
Terminieedefinizioni
definizioni
Termini

ISO9003
9003
ISO
Sistema
Qualit
Sistema Qualit
Prove, Controlli
Prove, Controlli
e Collaudi Finali
e Collaudi Finali

ISO9004-1
9004-1
ISO
Sistema
Qualit
Sistema Qualit
Guida generale
Guida generale

ISO9004-2
9004-2
ISO

Guidaper
peri iservizi
servizi
Guida

60

La normativa ISO 9000 (5)


Allinterno della famiglia ISO 9000, le norme applicabili ai sistemi qualit nel settore
dellInformation Tecnology sono:

la norma ISO 9001 per lassicurazione della qualit


la norma guida ISO 9000-3 per linterpretazione dei requisiti dettati dalla ISO 9001
la norma ISO 9004-1 per la gestione per la qualit
la norma guida ISO 9004-2 per linterpretazione dei requisiti dettati dalla ISO 9004-1

La norma ISO 9001 nata dallesperienza acquisita soprattutto dal settore manifatturiero
e quindi lapplicazione di questa norma alle aziende di informatica risulta difficile.
Lo sviluppo della guida ISO 9000-3 mira a semplificare linterpretazione della norma ISO
9001 in ambito informatico.
Con lemissione della normativa ISO 9000-3 sono stati risolti i problemi di interpretazione
da parte delle aziende, ma non quelli legati ai valutatori (auditor) delle aziende di
informatica. Infatti, le indicazioni definite nella norma ISO 10011 trovano difficile
applicazione nel settore informatico e specialmente nello sviluppo di software. Per questo
motivo la Comunit Europea ha rilasciato nel 1992 la European Information Technology
Quality System Auditor Guide (ITQSAG).
61

La certificazione ISO 9000


Con il termine certificazione si intende latto mediante il quale un organismo di
certificazione accreditato a livello nazionale o internazionale dichiara che, con
un livello confidenziale attendibile, un determinato prodotto, processo, servizio o
sistema qualit aziendale conforme a una specifica norma o documento
normativo a essa applicabile.
Laccreditamento definito dalla norma EN 45020 come il riconoscimento
formale di idoneit di un laboratorio a effettuare specifiche prove o determinati
tipi di prova. Luso del termine ora esteso al processo di riconoscimento delle
competenze degli organismi di certificazione in base alla norma EN 45012.

62

La certificazione ISO 9000 (2)


In Italia gli organismi di certificazione dei sistemi di qualit hanno seguito la via della
certificazione settoriale (CSQ in ambito informatico). I diversi organismi si sono poi riuniti
in una federazione denominata Certificazione Italiana Sistemi di Qualit (CISQ).
CISQ
A livello europeo lorganismo di riferimento lEuropean Organization for Testing and
Certification (EOTC)
EOTC che dispone di un comitato settoriale in ambito informatico:
European Committee for Information Tecnology Testing and Verfication (ECITC).
ECITC
ECITC nel 1992 ha definito uno standard (Information Technology Quality System ITQS)
ITQS
che permette il mutuo riconoscimento a livello europeo delle aziende di certificazione
nazionali che rispondono ai suoi requisiti.
Nella scelta dellente di certificazione lazienda deve considerare:

Le preferenze dei clienti o del mercato


La scelta della concorrenza
La credibilit e la validit della certificazione
Il riconoscimento della certificazione da parte di enti
internazionali
La stabilit finanziaria dellorganismo
Le referenze e il numero di certificati emessi dallente
La tipologia di aziende che l ente ha certificato

I costi delliter di certificazione


I tempi di attesa dalla presentazione della domanda
La durata della verifica ispettiva
La scadenza del certificato
La frequenza delle visite ispettive
La politica di gestione dei reclami
Le condizioni di sospensione e ritiro della certificazione

63

La certificazione ISO 9000 (3)


Liter di valutazione dellazienda da parte degli
enti di certificazione deve seguire le
prescrizioni stabilite dalla norma ISO 10011.

Predisposizionedella
della
Predisposizione
documentazione
documentazione ee
realizzazionedel
delS.Q.
S.Q.
realizzazione

Inviodel
delmanuale
manuale
Invio
qualit
qualit

Esame di conformit
Esame di conformit
del manuale qualit
del manuale qualit

Azioni
Azioni
Correttive
Correttive

No

Conforme??
Conforme
S

Attuazione azioni
Attuazione azioni
correttive
correttive

Verificaispettiva
ispettiva
Verifica

Rifiuto
Rifiuto
Motivato
Motivato

Azioni
Azioni
Correttive
Correttive

Azienda

Certificato
ISO 9000

No

Conforme??
Conforme

Ente certificatore

Concessione
Concessione
certificazione
certificazione

Visitedidisorveglianza
sorveglianza
Visite

64

La certificazione ISO 9000 (4)


La certificazione ISO 9000 pu essere rilasciata anche su sotto-porzioni dellazienda oggetto di
valutazione. La definizione dellestensione dellanalisi e quindi la scelta degli elementi e dei processi
oggetto di verifica sono un problema controverso e motivo di discussione tra le parti. compito
dellorganismo di certificazione, in collaborazione con lazienda da certificare, definire i confini e
lestensione della certificazione.
Il manuale qualit
qualit comprende la specifica di tutti i processi su cui applicato il sistema qualit.
Esso comprende inoltre la descrizione di tutta la documentazione che viene redatta a supporto di
tale sistema.
La verifica ispettiva la fase fondamentale della certificazione. Durante la visita ispettiva i
valutatori interpellano, secondo un piano concordato in base alle caratteristiche dellazienda e al
risultato dellanalisi del manuale qualit, vari responsabili aziendali le cui funzioni hanno impatto sulla
qualit (direzione generale, ufficio acquisti, direzione tecnica, responsabili laboratori, ecc.). Vengono
quindi visitati i reparti in cui si svolgono le attivit ed effettuate le verifiche relative alla corretta
applicazione delle procedure aziendali.
A certificazione avvenuta lorganismo di certificazione effettua visite di mantenimento della
certificazione (visite di sorveglianza). La frequenza delle visite di sorveglianza non uguale per
tutti gli organismi e pu variare da 1 a 4 allanno.
65

La certificazione ISO 9000 (5)


Non conformit
conformit secondo la norma il non soddisfacimento di requisiti specificati. La definizione
riguarda lo scostamento o lassenza di una o pi caratteristiche di qualit o di elementi del sistema
qualit rispetto ai requisiti specificati.
Le non conformit che vengono riscontrate durante le verifiche di certificazione possono essere di
vario tipo:
Non conformit
conformit rispetto ai requisiti della norma:
norma qualora uno o pi requisiti della norma non
vengano rispettati;
Non conformit
conformit sulla documentazione:
documentazione attivit non procedurate o formalizzate in documenti,
oppure attivit che non seguano le prescrizioni delle procedure;
Non conformit
conformit sull
sullattuazione delle procedure:
procedure qualora le prescrizioni delle procedure non
vengano attuate in modo efficace.
25
20
15

%
10
5
0

Principali non conformit


conformit per le software house
house
Non c evidenza sul ciclo di sviluppo
Parte della manualistica che descrive la metodologia di
sviluppo non conforme
Le procedure di controllo della sub-fornitura dello sviluppo
del software non sono conformi
La politica per la qualit non risulta compresa e attuata
appieno
66

La qualit nel software per ISO 9000


SQ

La struttura del sistema qualit di


unazienda che sviluppa e mantiene
software definita nella norma ISO
9000-3

Organizzazione
- Responsabilit della direzione

Processi

Processi del ciclo di vita

Processi di supporto

- Riesame del contratto


- Specifica requisiti
- Pianificazione dello sviluppo
- Progettazione e realizzazione
- Verifica e validazione
- Accettazione
- Duplicazione, consegna e installazione
- Manutenzione

- Gestione configurazione
- Controllo documentazione
- Doc. registrazione qualit
- Misure
- Regole, pratiche e convenzioni
- Strutture e tecniche
- Approvvigionamenti
- Prodotti inclusi
- Addestramento
67

La qualit nel software per ISO 9000 (2)


La norma ISO 9000 definisce il sistema qualit come la struttura organizzativa, le
procedure, i processi e le risorse necessarie ad attuare la gestione per la qualit.
Lazienda viene rappresentata come un insieme di processi collegati fra loro e con
lambiente esterno. Il conseguimento di un sufficiente livello di qualit del software
ottenibile tramite il controllo dei processi direttamente coinvolti nella sua produzione.

Processi del ciclo di vita:


vita costituiscono le fasi salienti della produzione del software.
ISO 9000-3 non detta regole o criteri specifici per la loro gestione. Le tecniche di software
engineering descritte in precedenza rispondono ampiamente ai requisiti.
Processi di supporto:
supporto non sono collegati a nessuna fase in particolare ma sono
distribuiti lungo tutto il ciclo di sviluppo.

68

Il profilo di qualit
La normativa ISO 9000 definisce in modo accurato il profilo di qualit per un prodotto
software (ISO 9126 recepita dalla IMQ 60).
Il profilo di qualit codifica la qualit di un prodotto software facendo uso di un insieme di
caratteristiche e di sotto-caratteristiche in cui le prime vengono scomposte per facilitarne
la verificabilit.
Il raggiungimento dei valori di qualit attesi viene verificato mediante test e riesami
durante tutte le fasi del ciclo di vita.
La determinazione del valore delle caratteristiche viene effettuata facendo uso di
questionari e tabelle di riferimento. La compilazione del questionario dovrebbe essere
effettuata con la collaborazione del cliente. Per ogni sotto-caratteristica devono essere
stabiliti:
Lobiettivo
Gli elementi di verifica
Gli indicatori
69

Il profilo di qualit: esempio


Obiettivo
Rilasciare la documentazione del progetto con 0 errori di massima gravit e X errori di gravit
minore ogni 10 pagine.
Rilasciare il codice con 0 errori di massima gravit e Y errori/KDSI.

Elementi di verifica

Determinare una curva di abbattimento degli errori nei diversi test.


Effettuare test per la comparazione con le curve di abbattimento.
Effettuare test sonda per la verifica della copertura dei test.
Utilizzare la documentazione nei test.

Indicatori
Quantit di errori trovati, confronto con il modello di abbattimento e stima del livello di qualit
finale.
Quantit di errori per pagina di documentazione trovati nei riesami e nelle ispezioni e loro
gravit.
Valutazione quantitativa di completezza funzionale per area funzionale data dai revisori durante i
riesami e le ispezioni sui documenti durante i test di validazione.
Quantit di errori (e loro gravit) trovati durante i test di verifica e validazione della stima del
livello di qualit.
70

Il profilo di rischio
Il rischio di prodotto definito come leventualit che lutilizzo del prodotto possa arrecare danni di
varia natura e gravit. Si distinguono diverse classi di rischio (bassa, media, alta, ecc.) sulla base
delle conseguenze che si possono avere in seguito a eventuali malfunzionamenti nelluso del
prodotto.
Il rischio di prodotto influenza il livello di confidenza che si richiede al prodotto finale e di conseguenza ha impatto
sui criteri di arresto delle prove di verifica e validazione, sul grado di copertura dei test, nonch sui criteri di rilascio
del sistema.

Classedi
dirischio
rischio
Classe

Tecnichedidiverifica
verifica
Tecniche

Prodottida
daverificare
verificare
Prodotti

Cosa
Cosa
verificare
verificare

Come
Come
verificare
verificare

Grado di copertura
Grado di copertura
(Checklist)
(Checklist)

Criteri di arresto
Criteri di arresto

Conche
che
Con
ampiezza
ampiezza

Criterididirilascio
rilascio
Criteri

Quando
Quando
fermarsi
fermarsi

Consegnare
Consegnare
no
oono

La natura dei danni da considerare ai fini della determinazione del rischio di prodotto dipende dallambiente e dal
sistema (gestionale, telecomunicazioni, difesa, ecc.) in cui esso destinato ad operare. Esistono degli standard
(es. European Space Agency, ESA) che classificano il rischio in funzione dei danni arrecati alluomo, allambiente,
alla propriet pubblica privata e alla missione.
71

I documenti del progetto


La gestione della qualit si realizza tramite la standardizzazione di tutte le
operazioni che riguardano il processo. Elemento primario a tale fine linsieme
dei documenti che costituiscono larchivio del progetto. La concessione della
certificazione ISO 9000 si basa in gran parte sulla correttezza di tale
documentazione.
I documenti del progetto si dividono in:
Documenti tecnici
Documenti di pianificazione
Piano della
qualit

Piano del
progetto

Piano gestione
configurazione

Documenti
tecnici

ARCHIVIO DEL PROGETTO


72

I documenti del progetto (2)


Un prodotto software per poter essere mantenuto e per poter evolvere deve essere
descritto mediante i seguenti documenti tecnici:
tecnici
Specifiche
- Requisiti del software
- Disegno di architettura
- Disegno di dettaglio
Manuali
- Di installazione
- Dellutente
Programmi software
Registrazione dei risultati
- Di installazione
- Rapporti di riesame
- Rapporti di validazione
- Risultati delle misure
- Documentazione delle modifiche
- Gestione delle anomalie
73

I documenti del progetto (3)


Il ruolo del piano del progetto quello di definire il processo e la metodologia per
trasformare la specifica dei requisiti del committente in un prodotto software. Deve
descrivere:
Obiettivi
Struttura organizzativa
- Responsabilit
- Le interfacce organizzative con i clienti e i fornitori
- Le interfacce organizzative tra i vari gruppi
Fasi della progettazione e sviluppo
- Input e output di ogni fase
- Analisi dei tempi
- Analisi dei rischi
Relazioni con gli altri documenti del progetto

Il piano del progetto va verificato e approvato prima dellinizio del progetto; esso inoltre
dovrebbe essere aggiornato man mano che il progetto procede.
74

I documenti del progetto (4)


Il ruolo del piano della qualit quello di gestire la qualit del progetto e quindi
del prodotto sulla base della valutazione della classe di rischio e del profilo di
qualit del prodotto. Deve descrivere:
Il livello di qualit desiderato
Le misure e le metriche utilizzate per le verifiche
Le tecniche di analisi e verifica
Il piano temporale per lesecuzione dei test
I modi e i tempi per la valutazione della qualit dei sub-fornitori

Il piano di qualit dovrebbe essere concordato, verificato e approvato da tutte le


parti interessate e coinvolte nel progetto.

75

I documenti del progetto (5)


Il ruolo del piano della gestione della configurazione quello di definire le
modalit di controllo degli elementi di un sistema in ogni momento della sua vita.
Deve permettere di determinare le modifiche intervenute e gli effetti sui restanti
documenti del progetto.
Il ruolo del piano dei test quello di definire in modo dettagliato la tipologia e i
livelli delle prove da eseguire. Esso deve definire:
Quali test eseguire a livello di modulo, di integrazione e di sistema.
sistema.
I casi di prova e gli obiettivi per ciascuno di essi
I dati di prova e i risultati attesi
I criteri per la valutazione del superamento dei test

76