Qualit del Software

Per qualit del Software sintende la misura in cui un prodotto software

soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia
alla sua struttura interna.

I fattori rispetto a cui si pu misurare la qualit del Software vengono

classificati in:
Fattori Esterni (o di prodotto) la qualit del Software percepita dagli
utenti;
Fattori Interni (o di processo) la qualit del Software percepita dagli
sviluppatori.

Fattori Esterni (5 punti)

Correttezza
Il Software corretto se soddisfa le specifiche dei requisiti
funzionali.
Affidabilit
E definita in termini statistici come la probabilit di assenza di
guasti per un certo periodo di tempo.
La correttezza assoluta mentre laffidabilit relativa.
Usabilit
Un sistema facile da usare se un essere umano lo reputa tale.
Scalabilit
Si riferisce in termini generali alla capacit di un sistema di
crescere o decrescere (aumentare o diminuire di scala) in funzione
delle necessit e delle disponibilit.
Robustezza
Il Software si comporta in modo ragionevole anche in circostanze
impreviste.

Fattori Interni (6 punti)

Efficienza
Un sistema efficiente se usa le risorse HW/SW in modo
proporzionato ai servizi che svolge.
Riparabilit
Un sistema riparabile se la correzione degli errori poco faticosa.
La riparabilit si persegue attraverso la modularizzazione.
Riusabilit
Facilit con cui possibile riusare parti di sistema per realizzare un
prodotto diverso.
Portabilit
Un sistema portabile se in grado di funzionare in ambienti
diversi.
Verificabilit
Un sistema verificabile se le sue propriet correttezza, affidabilit
sono facili da verificare.
Manutenibilit
Facilit di apportare modifiche al sistema realizzato.

Esiste poi un particolare standard per la qualit del Software: ISO/IEC 9126

Qualit interna ed esterna (6 punti)

1
 Funzionalit
E la capacit di un prodotto SW di fornire funzioni che soddisfano
esigenze stabilite.
Usabilit
E la capacit del prodotto SW di essere capito, appreso, usato e
benaccetto dallutente.
Affidabilit
E la capacit del prodotto SW di mantenere uno specificato livello
di prestazioni quando usato in date condizioni per un dato periodo.
Efficienza
E la capacit di fornire appropriate prestazioni relativamente alla
quantit di risorse usate.
Manutenibilit
E la capacit del SW di essere modificato, includendo correzioni,
miglioramenti o adattamenti.
Portabilit
E la capacit del SW di essere trasportato da un ambiente di lavoro
ad un altro.

Qualit in uso: rappresenta il punto di vista dellutente sul SW. Il livello di

qualit in uso raggiunto quando sia stato raggiunto sia il livello di qualit
esterna sia il livello di qualit interna.
Efficacia
E la capacit del SW di mettere in grado gli utenti di raggiungere
gli obiettivi specificati con accuratezza e completezza.
Produttivit
E la capacit di mettere in grado gli utenti di spendere una
quantit di risorse appropriate in relazione allefficacia ottenuta in
uno specificato contesto duso.
Sicurezza
Rappresenta la capacit del prodotto SW di raggiungere accettabili
livelli di rischio di danni a persone, al SW, ad apparecchiature o
allambiente operativo duso.
Soddisfazione
Soddisfazione dellutente, che spesso si traduce in assiduit di
utilizzo.

Ciclo di vita del Software

Nella fase di sviluppo tradizionale del ciclo di vita del software i passaggi sono:
analisi, progettazione, implementazione e test.

Un processo Software pu essere organizzato mediante luso di cicli di vita del

software;
il ciclo di vita definisce la struttura di massima di un processo SW, attraverso
lindicazione delle principali fasi secondo le quali deve articolarsi e i criteri
secondo i quali si succedono.

Standard IEEE 610.12 1990

Ciclo di vita del SW: definito come il periodo di tempo che inizia quando un
prodotto SW viene concepito e si conclude quando il prodotto
non pi disponibile per luso.
Include in genere una fase di analisi, fase dei requisiti, di
2
 progettazione, dimplementazione, di test, di installazione e
rilascio, di esercizio e manutenzione, e talvolta, fase di fuori
uso.
Ciclo di sviluppo del SW: il periodo di tempo che inizia con la decisione di
sviluppare un prodotto SW e termina quando il SW viene
fornito. Questo ciclo comprende di solito una fase requisiti,
progettazione, attuazione, test e talvolta la fase di checkout.

Possiamo definire un processo SW come un insieme di attivit il cui obiettivo

lo sviluppo o la modifica del prodotto SW. In tutti i processi SW troviamo delle
attivit generiche:
Specifiche: ci che il sistema deve fare e dei suoi vincoli di sviluppo;
Sviluppo: produzione del sistema SW;
Validazione: verifica che il SW ci che il cliente vuole;
Evoluzione: cambiare il SW in risposta alle mutevoli esigenze.

I processi SW possiamo classificarli come:

1. Processi basati sulla documentazione (basati su linguaggi semi-formali
per la specifica dei documenti) come ad esempio:
Waterfall
Evolutivo
Basato sul Riuso
Incrementale
A Spirale
RUP
2. Processi basati su Metodi Fomali (basati su linguaggi formali di specifica);
3. Approcci AGILI (uso ridotto di documentazione) come ad esempio:
Programmazione estrema
Test Driven Development

Modello a cascata
Il modello a cascata (Waterfall) caratterizzato dalle fasi ben definite tra loro e
dal fatto che il SW viene rilasciato solo a completamento di tutte le fasi di
sviluppo.
Tali fasi sono:
Studio di fattibilit: si identificano le caratteristiche generali del
problema, si analizzano le possibili strategie per la sua soluzione e si
effettua una valutazione di massima dei tempi e dei costi richiesti.
Descrizione del problema: si analizza il dominio applicativo e si
raccolgono i requisiti dellutente. Sulla base di queste informazioni
vengono prodotte le specifiche.
Progettazione della soluzione: definita larchitettura e la struttura della
soluzione SW.
Sviluppo e test di unit: si implementa larchitettura progettata nella fase
precedente. Durante lo sviluppo sono eseguiti i test per individuare gli
errori presenti nel codice e per verificare che i singoli moduli esibiscano il
comportamento desiderato.
Integrazione e test di sistema: si integrano i diversi moduli implementati
nella fase precedente.
Deployment: prevede la distribuzione e installazione del SW presso
lutente.
Manutenzione: si garantiscono le correzioni e le operazioni di
3
 manutenzione sul prodotto SW.

PRO
un modello molto rigoroso: si applica bene in qualunque contesto in cui i
requisiti siano stabili e ben definiti.
CONTRO
Impossibilit di tornare indietro e rifare unattivit nel momento in cui ci sia
necessit di correggere o modificare il lavoro svolto.
Linterazione con il cliente avviene sono allinizio e alla fine.

Sviluppo evolutivo
E un modello di sviluppo basato sullidea di produrre una versione iniziale del
SW, esporla agli utenti e perfezionarla attraverso varie versioni. I modelli
fondamentali sono:
Sviluppo Esplorativo
Prototipale (usa & getta)
Basato sul Riuso

Sviluppo esplorativo
Lobiettivo di lavorare col cliente per esaminare i requisiti iniziali e farli
evolvere fino al sistema finale (Requisiti chiari da subito).
PRO
Ha come vantaggio quello di ottenere rapidi feedback e la possibilit di
far cambiare i requisiti; pi efficace di un approccio a cascata nella
produzione di sistemi che soddisfino le immediate necessit del cliente e
le specifiche si possono sviluppare in modo incrementale.
CONTRO
Come contro molto spesso i sistemi diventano mal strutturati a causa dei
continui cambiamenti, che tendono a corrompere la struttura del SW
rendendo sempre pi costoso e difficile includere le modifiche.
La sua applicabilit ricade su sistemi di piccole dimensioni, per sviluppare
alcune parti di sistemi di grandi dimensioni o per sistemi destinati a vita
breve.

Sviluppo prototipale (requisiti non chiari)

Viene realizzata una prima implementazione (prototipo), pi o meno
incompleta da considerare come una prova, con lo scopo di:
Accertare la fattibilit del prodotto;
Validare i requisiti.
Dopo la fase di utilizzo del prototipo si passa alla produzione della
versione definitiva del sistema SW mediante un modello che, in generale,
di tipo waterfall.

Per grandi sistemi consigliabile un approccio misto che incorpori le

caratteristiche migliori del modello prototipale e di quello usa & getta.
Le parti del sistema che sono ben chiare possono essere specificate e
sviluppate utilizzando il modello a cascata mentre le parti pi difficili da
specificare preventivamente dovrebbero essere sviluppate seguendo un
approccio esplorativo.

Esistono due tipi di prototipi usa & getta:

1. Mock-ups;

4
 2. Broadboards.

Basata su componenti (Riuso)

Nella maggior parte dei progetti SW si riutilizza il SW, solitamente in
maniera informale.
Fornisce grandi vantaggi poich riduce la quantit di SW da sviluppare,
riduce i costi e i rischi e garantisce consegne pi veloci.

Le fasi del processo sono:

Specifica dei requisiti;
Analisi dei componenti gi esistenti;
Modifica dei requisiti;
Convalida;
Progettazione con riuso;
Sviluppo e integrazione dei componenti.

Ciclo di vita iterativo

Il ciclo iterativo composto da una serie di iterazioni. Le iterazioni sono mini-
progetti formati da ripetizioni di fasi. Le attivit e deliverable cambiano in
funzione dello stato di avanzamento del progetto.
Possiamo avere due possibili approcci:
1. Sviluppo e consegna incrementale, dove le specifiche, la
progettazione e limplementazione sono suddivisi in una serie di
incrementi sviluppati uno alla volta;
2. Sviluppo a spirale, dove lo sviluppo del sistema segue una spirale
verso lesterno.

Sviluppo e consegna incrementale

Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la
consegna sono eseguiti per incrementi.
Ai requisiti utente vengono associati livelli di priorit e quelli a priorit
maggiore vengono rilasciati con i primi incrementi.
PRO
I clienti non devono aspettare il sistema completo per la consegna;
I primi incrementi possono essere usati come prototipo per aiutare
a definire i requisiti degli incrementi successivi;
Si riduce il rischio di un fallimento totale del progetto;
I servizi a pi alta priorit saranno anche testati pi intensamente
degli altri.
CONTRO
Gli incrementi devono essere relativamente piccoli, ma pu essere
difficile predisporre i requisiti in incrementi della dimensione giusta;
Le funzionalit comuni a pi requisiti potrebbero non essere
identificate abbastanza presto, ma bisogna attendere che gli
incrementi siano completati per avere ben chiari tutti i requisiti.

Sviluppo a spirale
Il processo rappresentato come una spirale, e ogni giro rappresenta
una fase del processo. Non prevede fasi prefissate a priori ma i cicli sono
definiti in base al caso specifico.
Questo ciclo abbina la natura iterativa con quella controllata e
sistematica del modello a cascata e fa crescere in modo incrementale il
grado di definizione del sistema.
5
 Ogni fase inizia con un obiettivo di design, e termina con uninterazione
col cliente, che rivede il progresso ottenuto.
Il raggio rappresenta il costo accumulato mentre la dimensione angolare
il progresso nel processo.
Ogni ciclo di spirale si compone di 4 fasi:
1. Determinazione degli obiettivi
2. Valutazione e riduzione del rischio
3. Sviluppo e convalida
4. Pianificazione

Modello a spirale: variante di Boehm

Comunicazione col cliente: allinizio di ogni iterazione prevista
una fase di comunicazione col cliente in cui si discutono requisiti
desiderati dal cliente.
Pianificazione: successivamente c una fase di pianificazione
dove vengono pianificate le attivit da svolgere e le tempistiche
delle risorse da usare nelliterazione considerata.
Analisi dei rischi: vengono poi stimati e prevenuti i rischi tecnici e
di gestione.
Progettazione: questa la fase in cui si progetta e si struttura in
nuovo rilascio, alla luce di quanto emerso durante literazione
Realizzazione e rilascio: dopo aver progettato di passa alla
realizzazione, questo avviene durante questa fase. Questo settore
si occupa anche dei test.
Valutazione da parte dei clienti: infine vengono rilevate le
reazioni dei clienti.
PRO
Il modello di ciclo di vita a spirale descrive meglio il processo di
realizzazione di prodotti SW complessi e di notevoli dimensioni. Uno dei
vantaggi principali di questo metodo lintroduzione dellanalisi del
rischio a ogni livello diterazioni.
CONTRO
La presenza dellanalisi del rischio anche un punto critico: il successo
del progetto dipende in gran parte dalla corretta analisi dei rischi.

RUP (Rational Unified Process)

Il RUP un esempio di processo ibrido derivato da UML e dal relativo
processo; include tutte le caratteristiche dei modelli generici quali sviluppo
iterativo ed incrementale.
Le fasi del modello sono dinamiche e vanno pianificate mentre i workflow sono
statici e sono attivit tecniche condotte nelle varie fasi.
Definisce in modo accurato ruoli, attivit e I/O delle varie attivit.

Il Rup individua 3 prospettive e 4 fasi (ogni fase ha un certo insieme di obiettivi

e si conclude con la realizzazione di un deliverable):
Prospettive:
1. Una prospettiva dinamica che mostra le fasi del modello al fluire
del tempo. Le fasi determinano la vita e la maturit del progetto.
2. Una prospettiva statica che mostra le attivit.
3. Una prospettiva pratica che suggerisce le buone regole da seguire.

Fasi:

6
 1. Avvio
Lo scopo principale quello di delineare nel modo pi
accurato possibile il business case, ovvero comprendere il
tipo di mercato al quale il progetto afferisce e identificare gli
elementi importanti affinch esso conduca a un successo
commerciale.
Sono identificate le entit e le iterazioni attraverso le quali le
entit stesse interagiscono con il sistema: lidentificazione di
entit e interazioni supportata dalla redazione dei
diagrammi UML dei casi duso.
Al termine della fase, i risultati prodotti dalle iterazioni
saranno:
Il documento di vision;
Il documento di business case;
Eventuali prototipi.
2. Elaborazione
Definisce la struttura complessiva del sistema. In questa fase
si stabilizzano i requisiti e di conseguenza la descrizione dello
spazio del problema (analisi del dominio). Viene inoltre
stabilita una struttura architetturale, con una stima dei tempi
e costi necessari, e inoltre il piano di progetto.
3. Costruzione
Viene portato a termine il grosso degli sviluppi e viene
prodotta la prima release del sistema.
4. Transizione
Il sistema passa dallambiente dello sviluppo a quello del
cliente finale. Vengono condotte le attivit di training degli
utenti e il beta testing del sistema a scopo di verifica e
validazione.

Al termine di ognuna di queste fasi sono previste particolari milestone

altrimenti possibile reiterare ognuna di esse con risultati sviluppati in
modo incrementale, cos come lintero sistema pu essere ripetuto
ciclicamente.

Un progetto gestito usando il RUP viene suddiviso, come detto, in

iterazioni. Le attivit (workflow) individuate a ogni iterazione sono:
Modellazione processi di business;
Requisiti;
Analisi e progettazione;
Implementazione;
Test;
Rilascio.
Queste attivit sono ripetute a ogni iterazione e per ogni fase.

PRO
Separazioni di fasi e workflow; le fasi sono dinamiche e vanno pianificate
mentre i workflow sono statici e sono attivit tecniche condotte nelle
varie fasi.
CONTRO
Spesso si rinuncia ad adottare il RUP perch esso comporta un drastico
cambiamento nel modo di lavorare delle persone.

7
Processi Rapidi
La rapidit dello sviluppo e consegna oggi spesso i, requisito pi critico per i
sistemi SW. Molte aziende sono disposte a transigere sulla qualit, pur di avere
una rapida consegna delle funzionalit essenziali.
I processi di specifica, progettazione e implementazione sono concorrenti. Non
esiste una specifica dettagliata e la documentazione di progetto ridotta al
minimo.
Il sistema viene sviluppato iterativamente in una serie di incrementi. Gli utenti
valutano ciascun incremento e quindi propongono modifiche e fanno proposte
per i successivi incrementi.
PRO
Consegna rapida dei servizi ai clienti e coinvolgimento degli utenti nel sistema.
CONTRO
Problemi di gestione: gli avanzamenti del lavoro e gli eventuali problemi
possono essere valutati con difficolt, infatti non tutta la documentazione viene
prodotta;
Problemi contrattuali: difficile scrivere un contratto senza una specifica;
Problemi di validazione: dal momento che non possibile fare specifiche
precise non possibile fare una validazione formale;
Problemi di manutenzione: le modifiche continue tendono a corrompere la
struttura del SW, rendendo pi difficile le modifiche future.

Esistono diversi processi di sviluppo rapido, alcuni di questi sono:

Metodi agili
Lagile un approccio che punta lattenzione verso la capacit di
rispondere in modo veloce ed efficace ai cambiamenti che
caratterizzano il processo di sviluppo SW.
Lo sviluppo agile si focalizza sulle persone e sullinterazione, e con
la collaborazione del cliente, piuttosto che sul processo e i tool;
lenfasi sulla realizzazione del SW piuttosto che sulla redazione di
una documentazione esaustiva.
il SW che parla da se.
Le metodologie delle programmazione agile ridimensionano
limportanza e lo sforzo impiegato nelle attivit preliminari del
progetto, come ad esempio, la raccolta dei requisiti, la
progettazione della soluzione e in particolare larchitettura di base.
Ci non significa che queste attivit non siano eseguite, ma che il
tempo e lo sforzo dedicati sono minori rispetto agli altri modelli.

Programmazione estrema (XP)

un approccio allo sviluppo basato su sviluppo e consegna di
piccoli incrementi di funzionalit basandosi su un continuo
miglioramento del codice, sul coinvolgimento dellutente nel
processo di sviluppo, e sulla programmazione a coppie.

o Inizia con la creazione di varie user story (descrizione,

semplice e breve, di una particolare funzionalit richiesta
dallutente);
o A ogni user story viene assegnato un costo;
o Le varie user story sono raggruppate per determinare un
incremento da consegnare in tempi brevi;
o Si stabilisce la data di consegna;
o Dopo il primo incremento la velocit del progetto viene usata
per definire le date delle consegne successive.
8
 La XP caratterizzata da quattro valori chiave:
1. Semplicit
Basato su progettazione della soluzione pi semplice
possibile, inclusiva delle sole funzionalit che di volta in volta
il team deve rilasciare allutente.
2. Feedback
Ottenuto dal testing continuo eseguito sul codice e garantito
dai continui e frequenti rilasci allutente.
Il team, ricevendo i frequenti feedback dellutente, pu
adattare i rilasci successivi in modo flessibile anche in una
fase avanzata del progetto.
3. Comunicazione
Avviene tra lutente e una coppia di due programmatori
saggi. La comunicazione assume un ruolo fondamentale:
linterazione con lutente finale continua tanto da prevedere
la presenza dellutente stesso mentre si procede alla
realizzazione del SW.
Due programmatori saggi devono lavorare sulla stessa
macchina in modo da realizzare una sorta di controllo e
testing durante limplementazione stessa del codice (pair
wise programming).
4. Coraggio

RAD (Rapid Application Development)

Questa metodologia coinvolge modelli di sviluppo iterativi, la
costruzione di prototipi e lutilizzo di strumenti CASE.

Gli elementi essenziali del RAD sono:

o Prototipizzazione
Lo sviluppo si basa sulla costruzione di un prototipo che
serve al cliente come prova dellapplicazione e per
raffinare i requisiti. Il prototipo viene fatto evolvere
iterativamente nel sistema completo.
Si fa uso di strumenti CASE per lo sviluppo del
prototipo.
o Sviluppo iterativo
Ogni versione viene rivista col cliente per stabilire i
requisiti da sviluppare con la versione successiva. Il
processo viene ripetuto fino a quando tutte le
funzionalit sono sviluppate e la lunghezza ideale di
iterazioni tra 1 giorno e 3 settimane.
o Sviluppo Time Boxed
Ad ogni iterazione si selezionano le caratteristiche
essenziali mentre quelle inessenziali vengono
rimandate a iterazioni successive. Tutto questo al fine
di completare la versione corrente nel pi breve lasso di
tempo possibile.
o Team di lavoro
Impiego di piccoli team di lavoro con persone motivate
e capaci di svolgere ruoli diversi con la possibilit di
includere anche il cliente o utenti dellapplicazione (JAD
Join Application Development).
o Management del progetto
9
 Il management deve evitare il rischio di lunghi cicli di
lavoro, incomprensioni col cliente o mancate consegne,
attraverso unaccurata selezione del personale e
rimuovendo ostacoli politici o burocratici.

o Strumenti RAD
Uno degli obiettivi primari quello di sfruttare le pi
recenti tecnologie disponibili per velocizzare lo sviluppo.

Il processo RAD diviso in 4 fasi:

1. Pianificazione dei requisiti
Sono raccolti i requisiti utente iniziali e le
principali entit di business, definendo gli obiettivi
dellapplicazione.
2. User design (o Functional design)
Durante questa fase gli utenti interagiscono con
gli analisti di sistemi con lobiettivo di sviluppare
modelli e prototipi che rappresentano tutti i
processi di sistema, gli ingressi e le uscite (E-R
Diagram).
3. Costruzione
I suoi compiti sono la programmazione e lo
sviluppo di applicazioni, di codifica, unit di
integrazione e test di sistema. Il design team
sviluppa lapplicazione in maniera iterativa, con
iterazioni brevi (1/3 settimane), convertendo il
data model (E-R) nel database.
Il prototipo viene testato con lutente e rivisto
dagli sviluppatori.
4. Implementazione
Il sistema finale viene integrato e rilasciato
nellambiente operativo. Gli utenti finali vengono
addestrati e svolgono il test di accettazione finale.
Si raccolgono i feedback ed eventuali richieste di
miglioramenti.

I vantaggi sono:
o Velocit
un modello di processo incrementale che punta
ad un ciclo di sviluppo molto breve (60/90 giorni).
o Qualit
intesa non come assenza di difetti, ma come
capacit dellapplicazione sia di soddisfare bisogni
utente sia di presentare i bassi costi di
manutenzione.
Gli svantaggi sono:
o Scalabilit ridotta
Ogni applicazione sviluppata tramite RAD inizia
come prototipo ed evolve tramite iterazioni in
unapplicazione completa, di conseguenza al
prototipo consegnato pu mancare la scalabilit.
o Funzionalit ridotte
Ridotte funzionalit si presentano a causa
del time boxing, quando queste sono accelerate
10
 verso la nuova versione allo scopo di ultimare in
tempi brevi la release del software.

Metodi basati sul riuso di COTS (Commercial Off-the-Shelf

component)
L'espressione componente COTS si riferisce a componenti HW e SW
disponibili sul mercato per l'acquisto da parte di aziende di sviluppo
interessate a utilizzarli nei loro progetti.
Una possibile alternativa per lo sviluppo rapido consiste nel
configurare e collegare tra loro sistemi applicativi completi.
Prototipizzazione
A volte per problemi contrattuali, non pu essere usato un
approccio incrementale, ma i requisiti non sono ben chiari o altri
aspetti progettuali non ben definiti. Si pu allora sviluppare un
prototipo (usa & getta) a scopi esplorativi che pu essere usato:
Nel processo dingegnerizzazione dei requisiti per raccogliere
e validare requisiti;
Nei processi di progettazione per esplorare nuove soluzioni;
Nel processo di testing per eseguire test back-to-back.

Questi prototipi usa & getta dovrebbero essere eliminati dopo luso,
perch non sono una buona base di partenza per la produzione del
sistema:
o Potrebbe essere impossibile adattare il prototipo per soddisfare i
requisiti non funzionali;
o I prototipi non sono ben documentati;
o La struttura del prototipo si degrada a causa dei rapidi
cambiamenti.
o Il prototipo normalmente non soddisfa gli standard di qualit
dellorganizzazione.

Project Management
I manager sono i responsabili della pianificazione e della tempistica dello
sviluppo dei sistemi, supervisionano il lavoro per assicurarsi che sia eseguito
secondo gli standard richiesti, e monitorizzano i processi per controllare che lo
sviluppo stia rispettando tempi e costi.
LISW soggetta a budget aziendali e vincoli di tempo.

Nellattivit di creazione di un progetto identifichiamo personaggi e interpreti

(stakeholder):
Senior manager: definiscono il contesto aziendale;
Project manager: incaricati di pianificare, motivare, coordinare e
controllare il personale tecnico;
Tecnici: dotati delle competenze necessarie per la realizzazione di un
prodotto o una applicazione;
Clienti: specificano i requisiti del SW da realizzare;
Utenti finali: interagiscono con il SW reso operativo.

I principali compiti dei gestori di un processo SW sono:

Attivit di gestione
Si suddivide in:
o Scrittura delle proposte: consiste nel descrivere gli
obiettivi del processo e come saranno svolti; di solito
11
 comprende la stima di costi e tempi e giustifica perch
lappalto dovrebbe essere dato a una particolare
organizzazione o squadra. Tale scrittura una capacit che si
acquisisce attraverso lesperienza no linee guida.
o Pianificazione e tempistica del progetto: si occupa di
identificare le attivit, le milestone e le consegne prodotto dal
progetto.
o Costo del progetto: stimare i costi significa quantificare le
risorse necessarie per terminare il progetto.
o Monitoraggio e revisione del progetto: unattivit di
progetto continuativa e comprende sia un monitoraggio
informale (discutere con il team in maniera privata ed
appunto informale dei particolari problemi e anomalie
riscontrate nello sviluppo) sia una revisione formale ( un
riesame generale dei progressi e dello sviluppo e porta nel
suo caso peggiore alla decisione di annullare un progetto).
o Selezione e valutazione del personale: un compito del
manager che spesso devono accettare un team inadeguato
per diversi motivi:
Budget inadeguato;
Indisponibilit di personale con esperienza;
Personale specializzato gi coinvolto in altri
progetti.
Un buon manager deve rispettare i cosiddetti magnifici 4,
ovvero coerenza, rispetto, comprensione, onest.
o Gestione dei gruppi: i fattori che influenzano il lavoro di
gruppo sono:
Composizione: raggiungere il giusto equilibrio di
capacit, esperienza e personalit nel team;
Coesione: il team deve ragionare come unentit
unita e non come singole persone;
Comunicazione: i membri del team devono
comunicare tra di loro;
Organizzazione: considerare i membri del team
in maniera omogenea in modo da far sentir tutti
importanti.
Il controllo dei team pu essere di due tipologie:
1. Controllo decentralizzato: il team leader coordina il
lavoro e non centralizza su di lui la risoluzione e
limplementazione dei problemi, assegnandoli a dei
sottogruppi; la comunicazione orizzontale tra i
sottogruppi e verticale con il team leader;
2. Controllo centralizzato: il team leader decide sulle
soluzioni e sullorganizzazione; la comunicazione tra
team leader e gli altri membri verticale.

Pianificare il progetto
La pianificazione un processo ciclico, completo solo quando
completo il progetto stesso. Allinizio del processo di pianificazione
bisogna stimare i vincoli che influenzano il progetto come la data di
consegna richiesta, il personale disponibile, il budget generale, ecc.
Si definiscono poi le milestone e le consegne del progresso e,
infine, il processo entra nel ciclo.
12
 In alcune organizzazioni il piano di progetto un singolo documento
che comprende diversi tipi di piano; in altri casi si occupa
solamente del processo di sviluppo e sono inclusi solo i riferimenti
ad altri piano che rimangono separati.
La struttura del piano di progetto articolata in 7 fasi:
1. Introduzione: descrive brevemente gli obiettivi e delinea i
vincoli che influenzano la gestione del progetto.
2. Organizzazione del progetto: descrive il modo in cui il team di
sviluppo viene organizzato;
3. Analisi del rischio: descrive i possibili rischi del progetto, la
probabilit che si verifichino e propone le strategie di
riduzione;
4. Requisiti di risorse HW e SW: specifica lHW e il SW di
supporto, richiesti per eseguire lo sviluppo;
5. Divisione del lavoro: delinea la divisione del progetto in
attivit e identifica le milestone;
6. Tempistica del progetto: mostra le dipendenze tra le attivit,
il tempo stimato richiesto per raggiungere ogni milestone e
lassegnazione del personale alle attivit;
7. Meccanismi di monitoraggio e rapporto: definisce i rapporti di
gestione che dovrebbero essere prodotti, quando, e con quali
meccanismi.

Quando si pianifica un progetto necessario stabilite una serie di

milestone, ovvero punti cardine, riconoscibili nellattivit del
processo SW.
A ogni milestone dovrebbe esserci un output formale, come un
report (brevi resoconti), che possa essere presentato al
responsabile.

Le consegne (al cliente) sono in genere delle milestone, ma le

milestone non sono necessariamente delle consegne.

Tempistica del progetto

uno dei compiti pi difficili per un gestore di progetto: i
responsabili valutano:
Il tempo e le risorse richiesti;
Le valutazioni pregesse sono una base incerta (esperienze
personali pregresse);
Il grado tecnologico usato nel progetto (pi avanzato pi le
stime saranno ottimistiche);
le tempistiche del progetto sono rappresentate con un insieme di grafici
che mostrano la divisione del lavoro, le dipendenze delle attivit e
lassegnazione dello staff.

o I grafici a barre mostrano chi il responsabile e quando sono

previsti la partenza e il completamento di ogni attivit;
o Le reti mostrano le dipendenze tra le diverse attivit che formano
un progetto.

Gestione del rischio

La gestione del rischio pu essere di tipo reattiva o di tipo

13
 preventiva.
Reattiva: si trovano ed applicano le risorse solo quando il rischio
colpisce;
Preventiva: una strategia che si organizza molto prima che il
lavoro cominci; si individuano i rischi potenziali, se ne valutano la
probabilit e gli effetti e si stabilisce un ordine di importanza. Dal
momento che non tutti i rischi sono evitabili il team predispone
anche un piano di emergenza.

In linea di massima i rischi possono essere classificati come:

Dimensione del prodotto: rischi associati alla dimensione del
SW;
Effetti sul business: rischi associati ai vincoli imposti dal
mercato;
Caratteristiche del cliente: rischi associati alla sofisticazione
del cliente;
Definizione del processo: rischi associati alla precisione con
cui il processo di sviluppo definito;
Ambiente di sviluppo: rischi associati alla qualit degli
strumenti utilizzati e alla loro disponibilit;
Tecnologia: rischi associati alla complessit del sistema e alla
tecnologia su cui esso si basa;
Dimensione ed esperienza dello staff: rischi associati
allesperienza e alla competenza dello staff.

I componenti e i fattori di rischio sono i gradi di incertezza che il

progetto rispetti le aspettative:
Rischi sulle prestazioni;
Rischi sui costi;
Rischi sul supporto;
Rischi sui tempi.

La proiezione dei rischi (o stima dei rischi) ha lo scopo di

quantificare due aspetti di ogni rischio:
1. La probabilit che il rischio sia reale;
2. Le conseguenze dei problemi che nascono, se il rischio si
realizza.

Le quattro operazioni relative alla proiezione dei rischi sono:

1. Definire una scala di probabilit;
2. Definire le conseguenze;
3. Stimare gli effetti;
4. Indicare il grado di precisione della proiezione (della tabella).

Il piano RMMM
(Risk Mitigation, Monitoring and Management Plan ovvero
piano di controllo e gestione dei rischi)
Questo documento pu essere utilizzato dal Project Manager come
piano complessivo del progetto in alternativa, ogni rischio, pu
essere documentato singolarmente nel RIS (Risk Information Sheet
ovvero foglio informativo sui rischi).

Il Team Leader deve seguire delle linee guida per eseguire il suo lavoro, che
14
possono riassumersi come modello MOI:
Motivazione;
Organizzazione;
Idee o innovazione.

P-CMM (People Capability Maturity Model)

Modello che pu essere utilizzato come struttura per migliorare la gestione
delle risorse umane; comprende 5 livelli:
1. Iniziale: procedure ad hoc e informali per la gestione delle persone;
2. Ripetibile: creazione di politiche per lo sviluppo delle capacit dello staff;
3. Definite: standardizzazione dei principi fondamentali di gestione del
personale;
4. Gestione: obiettivi quantitativi per la gestione del personale;
5. Ottimizzazione: concentrazione continua sul miglioramento della
competenza individuale e della motivazione della forza lavoro.

PRO
P-CMM uno strumento pratico per migliorare la gestione del personale in
unorganizzazione, poich fornisce una struttura per la motivazione, il
riconoscimento, la standardizzazione e il miglioramento delle pratiche
professionali.
CONTRO
progettato per le grandi societ, rafforza la capacit di riconoscere
limportanza delle persone come individui e di sviluppare le loro capacit.
Lapplicazione completa di questo modello molto costosa e probabilmente
superflua nella maggior parte delle organizzazioni.

Analisi dei requisiti

Lingegneria dei requisiti tratti il processo condotto per stabilire i servizi che il
cliente richiede al sistema, quindi cosa il sistema dovrebbe fare, i vincoli
operativi e quelli per lo sviluppo. I requisiti sono descrizione di tali servizi e dei
relativi vincoli.

Comprendere i requisiti di un problema uno fra i compiti pi difficili per un

ingegnere del software. Il cliente dovrebbe sapere di preciso ci di cui ha
bisogno, ma in molti casi ci non accade. Lingegneria dei requisiti aiuta gli
ingegneri del software a capire meglio il problema che stanno cercando di
risolvere.

Lingegneria dei requisiti fornisce il meccanismo appropriato per comprendere

ci che il cliente desidera, analizzare i suoi bisogni, valutare la fattibilit,
negoziare una soluzione ragionevole, specificare la soluzione in modo non
ambiguo, validare le specifiche, gestire i requisiti mentre questi vengono
trasformati in un sistema funzionante.

Studio di fattibilit
Per tutti i nuovi sistemi il processo dingegneria dei requisiti dovrebbe iniziare
con uno studio di fattibilit. Linput dello studio un insieme di requisiti
aziendali preliminari, una descrizione generale del sistema e come si vuole che
supporti i processi aziendali; mentre il risultato dovrebbe essere un rapporto
che indica se vale la pena o meno continuare con lingegneria dei requisiti e lo
sviluppo del sistema.

15
Uno studio di fattibilit un breve studio che mira a rispondere a una serie di
domande:
Il sistema contribuir agli obiettivi generali dellorganizzazione?
Il sistema pu essere implementato usando la tecnologia attuale secondo
costi prefissati e con vincoli sulla tempistica?
Il sistema pu essere integrato con altri sistemi che sono gi stati
installati?
Il risultato dello studio di fattibilit un documento che dovrebbe contenere le
seguenti informazioni:
Definizione preliminare del problema;
Possibili scenari che illustrino eventuali diverse strategie di soluzione;
Costi, tempi e modalit di sviluppo per le diverse alternative.

Le parti dello studio di fattibilit sono cinque, e sono:

1. La situazione attuale:
Consiste nellanalisi del sistema esistente sulla base delle interviste
ai principali attori del processo di produzione e di trasformazione
delle informazioni;
2. Progetto di massima della soluzione:
Definizione delle soluzioni alternative, analisi dimpatto aziendale,
definizione della qualit attesa dal progetto;
3. Analisi del rischio;
4. Analisi costi-benefici;
5. Il progetto proposto.

Le conclusioni dello studio di fattibilit ci dicono se il progetto si pu realizzare

o no.

Analisi dei requisiti e progettazione

Lanalisi dei requisiti rappresenta lanalisi completa dei bisogni dellutente e
dominio del problema. Lobiettivo descrivere le caratteristiche di qualit che
lapplicazione deve soddisfare. Loutput il documento di specifica dei requisiti
(standard IEEE 830).

Analisi dei requisiti: un processo di valutazione delle necessit del

committente del SW, con redazione di un documento di analisi dei requisiti che
viene redatto al termine di una campagna di interviste svolta dagli analisti
presso il committente.

Specifica dei requisiti: un processo di schematizzazione dei requisiti di un

sistema, con redazione di un documento formattato rispetto a uno standard.

Tipi di requisiti
Requisiti utente (pi astratti)
Frasi in linguaggio naturale (e diagrammi) relativi ai servizi che il
sistema fornisce e i suoi vincoli operativi scritti per i clienti.
Descrivono i servizi richiesti al sistema (comportamento osservabile
dallesterno) e i vincoli operativi del sistema. Il punto di vista
quello del cliente, che li sottopone a un possibile sviluppatore per
ottenere unofferta.
Requisiti di sistema (aggiungono dettagli)
Un documento strutturato che fornisce una descrizione dettagliata
dei servizi del sistema e pu essere parte del contratto tra il cliente
16
 e lo sviluppatore. La formulazione dettagliata, strutturata dei
vincoli e dei servizi. Il punto di vista quello dello sviluppatore, che
li pu usare anche per il contratto con il cliente.
Sono versioni espanse dei requisiti utente e sono utilizzati dagli
ingegneri del SW come base di partenza per la progettazione;
aggiungono dettagli e spiegano come i requisiti utente dovrebbero
essere forniti dal sistema.
E auspicabile scrivere i requisiti di sistema utilizzando notazioni pi
dettagliate: un linguaggio naturale strutturato e stilizzato, modelli
grafici dei requisiti come gli use-case, e le specifiche matematiche
formali.
Requisiti funzionali
Descrivono i servizi, o funzioni, offerti dal sistema. Sono frasi che
descrivono ci che il sistema dovr fare, come reagir agli input e
si comporter in varie situazioni.
Due livelli di astrazione:
1. Requisiti funzionali utente: frasi ad alto livello su ci che il
sistema far;
2. Requisiti funzionali di sistema: descrizioni dettagliate dei
servizi.
Se espressi come requisiti utente, sono solitamente descritti in un
modo vagamente astratto, mentre se sono espresso come requisiti
di sistema descrivono le funzioni nel dettaglio da un punto di vista
pi tecnico del sistema.
Requisiti non-funzionali
Descrivono vincoli sui servizi offerti dal sistema, e sullo stesso
processo di sviluppo. Includono vincoli temporali, sul processo di
sviluppo e sugli standard. Solitamente si applicano al sistema
completo non a singole funzioni o servizi.

I requisiti non-funzionali si classificano in (Tassonomia di

sommerville):
Requisiti del prodotto: specificano il comportamento del
prodotto:
Prestazioni;
Usabilit;
Efficienza;
Affidabilit;
Portabilit.
Requisiti organizzativi: derivano dalle politiche e
procedure dellorganizzazione del cliente e dello sviluppatore
(es. standard di processo da usare, requisiti di consegna,
ecc.);
Requisiti esterni: derivano da fattori esterni al sistema e al
suo processo di sviluppo:
Interoperabilit (come il sistema deve interagire con i
sistemi di altre organizzazioni);
Legislativi (affinch il sistema operi legalmente);
Etici.
Requisiti di dominio
Requisiti derivati dal dominio applicativo del sistema software
piuttosto che da necessit dettate dagli utenti, quindi
rappresentano vincoli non dettati dallutente, ma imposti
17
 dallesterno.

Problemi dei requisiti:

Entropia: i requisiti utente che includono troppe informazioni sono difficili
da capire e limitano la libert degli sviluppatori del sistema di fornire
soluzioni innovative ai problemi degli utenti.
Focus: i requisiti utente dovrebbero concentrarsi semplicemente si servizi
chiave che devono essere forniti.
Motivazioni: Quando possibile, bisognerebbe provare ad associare una
motivazione ad ogni requisito utente, che dovrebbe spiegare perch il
requisito stato incluso, particolarmente utile quando si cambiano i
requisiti.

Documento di specifica dei requisiti (SRS)

una dichiarazione ufficiale di ci che gli sviluppatori dovrebbero
implementare (il cosa ma non il come). Deve includere sia i requisiti utente sia
una specifica dettagliata dei requisiti di sistema.

Un SRS costituisce il punto di convergenza di tre diversi punti di vista: cliente,

utente e sviluppatore. Un SRS fornisce un punto di riferimento per la
validazione del prodotto finale. Un SRS di qualit il prerequisito per un SW di
alta qualit: un errore nellSRS produrr errori nel sistema finale.

Standard IEEE 830 1998

Definisce una generica struttura per un documento dei requisiti che deve
essere istanziata per ogni specifico sistema.

Contiene pi capitoli:

18
19
Considerazioni sul documento dei requisiti (DdR): le informazioni incluse in un
DdR dipendono dal tipo di SW che si sta sviluppando e dalla tecnica di sviluppo
utilizzata.

Esempio:
o Tecniche evoluzionistiche
Deve lasciar fuori gran parte delle parti dettagliate e suggerite in
precedenza;
Si definiranno con attenzione i requisiti utente e quello di
sistema non funzionali di alto livello;
o Per sistemi grandi (che includono le interazioni di sistemi
HW e SW)
essenziale definire i requisiti a un alto livello di dettaglio;
Ddr molto lunghi;
Includono la maggior parte delle sezioni;
o Sviluppo agile: i requisiti cambiano cos velocemente che un
documento dei requisiti gi obsoleto quando viene scritto, quindi
si tratta per lo pi di uno spreco di energia.
o Programmazione estrema: propone una raccolta dei requisiti
passo passo e scritti su moduli.
o Sistemi aziendali: requisiti instabili.

Architettura del software

Larchitettura del software stabilisce lorganizzazione globale di un sistema

software, definendo:
La divisione del SW in sottosistemi;
La decisione di come queste parti interagiranno;
Le interfacce delle varie parti.

Larchitettura la rappresentazione che consente a un ingegnere del SW di:

1. Analizzare lefficacia del design nel rispondere ai requisiti stabiliti;

20
 2. Considerare le alternative di architettura in una fase in cui ogni
cambiamento ancora relativamente semplice;
3. Ridurre i rischi associati alla costruzione del SW.

La progettazione architetturale un processo di progettazione finalizzato ad

individuare i sottosistemi che compongono il sistema da realizzare.

La progettazione deve soddisfare tutti i requisiti espliciti contenuti nel modello

concettuale e deve accogliere i requisiti impliciti voluti dal cliente, deve essere
una guida leggibile e comprensibile per chi incaricato di stendere il codice e
per chi dovr testare il SW e provvedere alla sua manutenzione e deve dare un
quadro completo del SW.

I concetti fondamentali della progettazione architetturale sono:

Astrazione (dati, procedure, controllo)
Architettura (struttura complessiva del SW)
Pattern (presenta lessenza di una soluzione di progettazione di provata
qualit)
Modularit (incapsulamento di dati e funzioni)
Information hiding (comunicazione solo mediante interfacce)
Indipendenza funzionale (funzioni con un unico scopo e basso coupling)
Coesione: esprime il grado con cui un modulo incapsula e fornisce
un'unica funzionalit;
Accoppiamento: esprime il grado con cui un modulo connesso
ad altri moduli del sistema e ne dipende.
Raffinamento (elaborazione dei dettagli di tutte le astrazioni)
Refactoring (tecnica di ristrutturazione per semplificare la progettazione)
il processo di modifica di un sistema SW in modo tale che non
alteri il comportamento esterno del codice migliorandone per la
struttura interna.

Progettazione Top-down e Bottom-up

Top-down design: si parte col progettare la struttura di altissimo livello del
sistema; quindi si procede gradualmente con decisioni pi
dettagliate riguardanti aspetti di pi basso livello.
Bottom-up design: si parte progettando i componenti basilari di basso livello e
si decide poi come collegarli assieme per ottenere i componenti
di pi alto livello.

In genere normale usare un misto dei due approcci. La progettazione Top-

down necessaria per definire una buona struttura del sistema mentre la
bottom-up serve a progettare componenti riusabili in altri punti del sistema.

Per progettazione (o System/Object design) sintende la definizione di una

struttura opportuna per il SW. Distinzione fra:
System design: struttura modulare complessiva (componenti);
Object design: dettagli interni di ciascun componente.

System design
Gli scopi del System design sono:
Definire gli obiettivi di design del progetto;
Decomporre il sistema in sottosistemi pi piccoli che possano essere
realizzati da team individuali, eventualmente in parallelo;
21
 Selezionare le strategie per costruire il sistema.

Il System design costituito da tre macro-attivit (identificare gli obiettivi,

decomposizione, raffinare la decomposizione):
1. Identificare gli obiettivi di progettazione
il primo passo del System design e identifica le qualit su cui
deve essere focalizzato il sistema. Molti obiettivi del design possono
essere ricavati dai requisiti non funzionali o dal dominio di
applicazione, altri sono forniti dal cliente.

importante formalizzarli esplicitamente poich ogni importante

decisione di design deve essere fatta seguendo lo stesso insieme di
criteri, che sono organizzati in 5 gruppi:
1. Performance
Includono i requisiti posti sul sistema in termini di
spazio e velocit.
2. Affidabilit
La quantit di sforzo che deve essere speso per
minimizzare i crash del sistema e le loro
conseguenze.
3. Costi
Includono i costi per sviluppare il sistema,
metterlo in funzione e amministrarlo. Inoltre
necessario considerare il costo per assicurare la
compatibilit di un nuovo sistema nel caso in cui
richiesta la compatibilit con il precedente.
4. Mantenimento
Determinano quanto deve essere difficile
modificare il sistema dopo il suo rilascio.
5. Criteri End-User
Includono qualit che sono desiderabili dal punto
di vista dellutente ma che non sono state coperte
dai criteri di performance e affidabilit.

2. Progettare la decomposizione del sistema in sottosistemi

Non possibile progettare un sistema SW come un unico modulo,
conviene ridurre la complessit della soluzione decomponendo il
sistema in sottosistemi. Un sottosistema corrisponde alla parte di
lavoro che pu essere svolta autonomamente da un singolo
sviluppatore o da un team di sviluppatori. Nel caso sottosistemi
complessi applicchiamo ulteriormente questo principio.
Gli obiettivi della decomposizione sono:
1. Definire lelenco dei sottosistemi (o moduli) che
comporranno il nostro SW;
2. Definire le interfacce dei sottosistemi;
3. Definire le classi in ogni sottosistema.

Esistono dei criteri di Design generici, che valgono per qualunque

SW. La qualit del Design dipende da due fattori qualitativi
fondamentali:
Accoppiamento (obiettivo Indipendenza funzionale)
Laccoppiamento (coupling) fra moduli esiste quando ci
sono interdipendenze tra un modulo e laltro ed una
misura su quanto fortemente una classe connessa
22
 con/ha conoscenza di/si basa su altre classi.
Se ci sono interdipendenze, le modifiche in un punto
richiederanno modifiche anche altrove, pi difficile
capire come un componente lavora effettivamente, non
si pu riusare un modulo senza riusare tutti gli altri.
Per un codice di qualit dobbiamo puntare ad un basso
accoppiamento (low coupling).
Tipi di accoppiamento:
Accoppiamento sul contenuto;
Accoppiamento per dati comuni;
Accoppiamento sul controllo;
Accoppiamento sui dati;
Accoppiamento per uso di tipo;
Accoppiamento per inclusione o importazione;
Accoppiamento esterno;
Astrazione.
Coesione (obiettivo Indipendenza funzionale)
Con la coesione si in grado di stabilire quali e quanti
siano i compiti per i quali una classe (o un metodo)
stata disegnata. In generale, si pu affermare che pi
una classe ha una responsabilit ristretta ad un solo
compito pi il valore della coesione elevato.

3. Raffinare la decomposizione in sottosistemi

Basso accoppiamento e alta coesione.

Stili architetturali
Il concetto di pattern pu essere applicato alle architetture SW, si parla di
architectural patterns o stili/modelli architetturali.

Esistono tre stili architetturali complementari:

1. Organizzazione generale del sistema
I tre stili organizzativi pi utilizzati sono:
1. Stile ad archivio di dati condiviso (Repository);
2. Stile a servizi e server condivisi (Client-Server);
3. Stile stratificato dove il sistema viene organizzato come
un insieme di livelli funzionali.

1. Repository (archivio di dati condiviso)

I vari sottosistemi si devono scambiare i dati; questo scambio
realizzabile in 2 modi:
1. I dati condivisi sono conservati in un database centrale a
cui tutti i sottosistemi possono accedere;
2. Ciascun sottosistema mantiene un proprio database e passa i
dati esplicitamente agli altri sottosistemi tramite messaggi.

In genere quando devono essere scambiati grandi quantit di dati,

il modello Repository quello pi utilizzato.
PRO
Modo efficiente per condividere grandi quantit di dati.
I sottosistemi che producono dati non necessitano di sapere come
questi sono utilizzati da altri sottosistemi.
CONTRO

23
I sottosistemi devono conformarsi al modello Repository, e questo
inevitabilmente un compromesso che influenza le prestazioni.

2. Client-Server
Il modello Client-Server si basa su un insieme di server che offrono
dei servizi a un insieme di client che ne usufruiscono.
Ha tre componenti con un compito specifico:
1. Un insieme di server che offre servizi ad altri sottosistemi;
2. Un insieme di client che richiede i servizi offerti dai server;
3. Una rete che permette ai client di accedere a questi servizi.

I client dovrebbero conoscere il nome dei server disponibili e i

servizi che possono fornire;
I server non hanno bisogno di conoscere lidentit dei client o
quanti client sono presenti;
I client accedono ai servizi offerti da un server attraverso chiamate
di procedura remota usando un protocollo richiesta-risposta come
quello http per il web.
Un client effettua una richiesta a un server e attende finch non
riceve una risposta.

PRO
La distribuzione dei dati molto semplice, e fa un uso efficace dei
sistemi di rete ed il pi delle volte richiede HW economico. Inoltre
facile aggiungere nuovi server o aggiornare i server esistenti.
CONTRO
Non ci sono modelli di dati condivisi tra i server e i sottosistemi
possono organizzare i propri dati con modalit diverse.

2bis. Web-based
A differenza dellarchitettura Client/Server, le applicazioni Web-
based sono indipendenti dalle piattaforme hardware e software
utilizzate dagli utenti; gli utenti si collegano allapplicazione
utilizzando il browser che usano per la navigazione su Internet,
senza la necessit di dover installare sul proprio pc una specifica
applicazione.Lapplicazione Web si trova su un server, il che
significa che ogni modifica e aggiornamento immediatamente
disponibile a tutti gli utenti, che possono collegarsi ad essa da
qualunque parte del mondo, utilizzando Internet come
infrastruttura, anzich una rete locale.
I costi di sviluppo di una applicazione web sono solitamente
ampiamente ripagati dal vantaggio di poter modificare e aggiornare
lapplicazione senza la necessit di distribuire gli aggiornamenti a
tutti i propri utenti.

3. Stile stratificato (modello di macchina astratto)

Organizza il sistema in una serie di livelli (o macchine astratte)
ciascuno dei quali fornisce un insieme di servizi. Ogni strato pu
essere considerato una macchina astratta il cui linguaggio
definito dai servizi dai servizi forniti. Quando linterfaccia cambia
viene coinvolto solo lo strato adiacente (es. modello OSI).

Pattern Multi-Layer
In un sistema a livelli, ciascun livello comunica solo con il
24
 livello sottostante. Ogni livello, offre uninterfaccia ben
definita al livello immediatamente sovrastante, quindi il livello
pi alto vede quello pi basso come un insieme di servizi.
PRO
Supporta lo sviluppo incrementale dei sistemi.
Modificabile e portabile: finch non si modificano le sue
interfacce uno strato pu essere sostituito da un altro
equivalente. Le modifiche alle interfacce di un livello
influenzano solo lo strato adiacente.
CONTRO
Strutturare un sistema stratificato pu essere difficile. Le
prestazioni possono essere un problema a causa dei diversi
livelli di interpretazione dei comandi che sono talvolta
richiesti: se ci sono molti strati, una richiesta di servizio fatta
a uno strato superiore pu essere interpretata diverse volte in
diversi strati prima che sia elaborata.

2. Scomposizione modulare
Dopo aver scelto lorganizzazione generale del sistema, si deve
decidere lapproccio da usare per la scomposizione dei sottosistemi
in moduli.
I componenti dei moduli sono solitamente pi piccoli dei
sottosistemi.
Sottosistema: un sistema di diritto, le cui operazioni non
dipendono dai servizi forniti da altri sottosistemi; i sottosistemi
sono composti da moduli e hanno interfacce ben definite, che sono
utilizzate per la comunicazione con gli altri sottosistemi.
Modulo: solitamente un componente di un sistema che fornisce
uno o pi servizi ad altri moduli, fa uso di servizi forniti da altri
moduli, non normalmente considerato un sistema indipendente.

Ci sono 2 strategie principale da usare quando si scompone un

sottosistema in moduli:
Scomposizione orientata agli oggetti, dove si
scompone il sistema in un insieme di oggetti
comunicanti.
Struttura il sistema in un insieme di oggetti
accoppiati debolmente e con delle interfacce
ben definite: gli oggetti richiedono i servizi offerti
da altri oggetti.
Una scomposizione orientata agli oggetti si
occupa delle classi di oggetti, dei loro attributi e
delle loro operazioni.
PRO
Gli oggetti sono accoppiati debolmente:
implementazione degli oggetti pu essere
modificata senza influenzare altri oggetti.
CONTRO
I cambiamenti dellinterfaccia oggetto, possono
causare dei problemi:
per usare i servizi, gli oggetti devono riferirsi
esplicitamente al nome e allinterfaccia degli altri
oggetti, quindi se si modifca un interfaccia deve
essere valutato leffetto su tutti gli utilizzatori
25
 delloggetto modificato.

Pipelining, orientato alle funzioni, dove si scompone il

sistema in moduli funzionali che accettano dati in input
e li trasformano in output.
Il flusso di dati viene trasformato mentre passa
attraverso la sequenza. Queste trasformazioni
possono essere eseguite sequenzialmente o in
parallelo.
PRO
Supporta il riutilizzo delle trasformazioni;
intuitiva poich molte persone pensano al proprio
lavoro in termini dinput e output; il sistema pu
evolversi semplicemente aggiungendo nuove
trasformazioni.
CONTRO
Per il trasferimento dei dati deve esserci un
formato comune che venga riconosciuto da tutte
le trasformazioni.
Il modello pipelining buono per gli I/O testuali,
mentre entra in seria difficolt per le interfacce
grafiche utente.

3. Controllo
I modelli di controllo si occupano del flusso di controllo tra
sottosistemi, sono utilizzati in congiunzione con gli stili strutturali e
si suddividono in due categorie:
Controllo centralizzato (le decisioni di controllo sono
determinate dal valore da alcune variabili di stato del
sistema)
Un sottosistema designato come controllore di
sistema e ha la responsabilit di gestire
lesecuzione degli altri sottosistemi.
Abbiamo 2 classi a seconda che i sottosistemi
controllati siano eseguiti sequenzialmente o in
parallelo:
Sequenziale: il modello Call-Return
Il controllo parte dallalto della
gerarchia delle subroutine e,
attraverso le chiamate, arriva ai livelli
pi bassi dellalbero.
La natura rigida e ristretta di questo
modello ne rappresenta sia la forza
che la debolezza:
o Forza: relativamente
semplice analizzare i flussi di
controllo e capire come il
sistema risponder a particolari
input.
o Debolezza: difficile gestire le
eccezioni alle normali
operazioni.

Parallelo: il modello manager

26
 Un componente di sistema
designato come manager di sistema e
controlla la partenza, larresto e la
coordinazione degli altri processi di
sistema.

Controllo guidati da eventi (sistemi guidati da eventi

esterni)
Esistono due modelli:
Modelli broadcast (trasmissione di eventi,
informazioni o messaggi a tutti gli
ascoltatori), in cui un evento viene inviato
in broadcast a tutti i sottosistemi e ogni
sottosistema, che stato programmato per
gestire tale evento, pu rispondere.
La politica di controllo non integrata nel
gestore degli eventi e dei messaggi ma i
sottosistemi decidono di quali eventi hanno
bisogno e il gestore si assicura che siano a
loro inviati.

Modelli interrupt-driven
Un gestore individua le interruzioni esterne
che vengono poi passate a un altro
componente per lelaborazione. Ogni tipo
dinterruzione associato a una posizione
di memoria che contiene lindirizzo del suo
gestore. Quando uninterruzione di un
particolare tipo viene ricevuta un selettore
HW trasferisce immediatamente il controllo
al suo gestore che pu quindi avviare o
fermare altri processi in risposta allevento
segnalato dallinterruzione.

Architetture dei sistemi distribuiti

Tutti i grandi sistemi informatici sono virtualmente, oggi, sistemi distribuiti,
dove lelaborazione delle informazioni distribuita su diversi computer
piuttosto che su una singola macchina.

Le architetture dei sistemi distribuiti sono:

Architetture client-server
Lapplicazione viene modellata come un insieme di servizi forniti da
server e un insieme di client che li utilizza.
I client devono conoscere i server disponibili, ma solitamente non sanno
dellesistenza di altri client. Client e server sono processi separati.
Larchitettura client-server dei sistemi distribuiti pu essere cos
separata:
Architettura a strati
strutturata in tre strati:
Strato di presentazione: provvede alla
rappresentazione dei dati e a tutte le
interazioni con lutente;
Strato di elaborazione applicativa:

27
 implementa la logica dellapplicazione;
Strato di gestione dei dati: esegue tutte le
operazioni sul database.
Client-server a 2 livelli (two-tier)
o Client leggero Thin client
Dove tutte le elaborazioni applicative e la
gestione dei dati sono gestite dal server,
mentre i client si occupa soltanto di
eseguire il SW di presentazione.
Uno svantaggio che esso pone un pesante
carico di elaborazione sia sul server sia sulla
rete; questo pu generare un significativo
traffico di rete tra il client e il server.
o Client pesante Fat client
Il server si occupa solo della gestione dei
dati, mentre il SW sul client implementa la
logica applicativa e linterazione con
lutente del sistema. Gestione del sistema
pi complessa: le funzionalit
dellapplicazione sono divise su diversi
computer. Quando il SW deve essere
modificato, necessaria la reinstallazione
su ogni computer client maggiori costi se
presenti molti client.
Client-server a 3 livelli (three-tier)
e met strada tra i modelli thin e fat; la
presentazione, lelaborazione applicativa e la
gestione dei dati sono processi logicamente
separati ed eseguiti su diversi processori. Migliori
prestazioni rispetto al thin e gestione pi semplice
rispetto al fat.

Architetture a oggetti distribuiti

Nellarchitettura a oggetti distribuiti si vuole eliminare la distinzione tra
client e server. Oggetti: i componenti fondamentali del sistema,
forniscono servizi e ricevono servizi senza distinzione logica tra un client
(recettore del servizio) e un server (fornitore di servizio). Gli oggetti
possono essere distribuiti su diversi computer di una rete e comunicare
attraverso un middleware chiamato ORB (object request broker).
Vantaggi: permette ai progettisti del sistema di ritardare le decisioni su
dove e come i servizi dovrebbero essere collocati, poich gli oggetti che
forniscono servizi possono essere posti su ogni nodo della rete; per
questo motivo la distinzione tra modelli thin e fat client diventa
irrilevante, visto che non c necessit di decidere in anticipo dove
collocare gli oggetti della logica applicativa.

CORBA: Architettura e specifiche per la creazione, la

distribuzione e l'uso di oggetti software distribuiti in una
rete. Permette, a programmi in differenti locazioni e
sviluppati da programmatori diversi, di comunicare
in rete attraverso uninterfaccia.
CORBA stato sviluppato da un consorzio attraverso
l'OMG (Object Management Group) ed stato

28
 approvato dall'organizzazione internazionale per gli
standard ORB (Object Request Broker).
CORBA utilizza un apposito linguaggio
denominato Interface Description Language (IDL) per
definire le interfacce che gli oggetti presentano al
"mondo esterno".
CORBA specifica poi una mappatura da IDL a specifici
linguaggi dimplementazione come C++ o Java.

Middleware
I componenti di un sistema distribuito possono essere implementati in diversi
linguaggi di programmazione e possono essere eseguiti su differenti tipi di
processore. I modelli di dati, la rappresentazione delle informazioni e i
protocolli per la comunicazione possono essere tutti diversi. Un sistema
distribuito, dunque, necessita di un SW che gestisca queste parti diverse, e
che si assicuri che comunichino e si scambino dati: middleware.

Architetture multiprocessore
Il modello pi semplice di sistema distribuito un sistema multiprocessore,
dove il SW consiste in una serie di processi che possono essere eseguiti su
processori separati. La distribuzione ai processori pu essere predeterminata
oppure sotto il controllo di un dispatcher che decide la ripartizione dei
processi.

Calcolo distribuito inter-organizzativo

Due approcci possibili:
Peer-to-peer che si basa sullesecuzione del calcolo da
parte di nodi di rete individuali;
Orientati ai servizi che si basa sui servizi distribuiti
piuttosto che sugli oggetti distribuiti, e si affida a
standard basati su XML per lo scambio di dati.
Peer-to-peer
I Peer sono potenzialmente equivalenti tra loro e possono scambiarsi a
vicenda e in maniera dinamica i ruoli di client e server; sono sistemi
decentralizzati dove i calcoli possono essere eseguiti da ogni nodo della
rete.

Larchitettura logica della rete pu essere:

Decentralizzata
I nodi della rete non sono solo elementi funzionali, ma anche
commutatori di comunicazione che indirizzano i dati e i
segnali di controllo da un nodo allaltro.
PRO
Molto ridondante, quindi tollerante agli errori e ai nodi che si
disconnettono dalla rete.
CONTRO
Overhead nel sistema.
La stessa ricerca pu essere elaborata da diversi nodi
comunicazioni replicate tra i peer.
Semi-centralizzata
Uno o pi nodi della rete fungono da server per semplificare
la comunicazione tra i nodi. Il ruolo di un server aiutare a
stabilire il contatto tra i nodi della rete e coordinare i risultati

29
 del calcolo.

Per quanto ci siano degli sprechi nei sistemi peer-to-peer, un approccio

al calcolo distribuito inter-organizzativo molto pi efficiente dellapproccio
basato sui servizi.

Orientate ai servizi (Web Service)

Utilizzando un web service le organizzazioni che vogliono rendere
accessibili le proprie informazioni ad altri programmi possono farlo
definendo e pubblicando uninterfaccia di servizio che specifica i dati
disponibili e come accedervi.
Un web service una rappresentazione standard di risorse elaborative o
informative che pu essere utilizzata da altri programmi; la sua
erogazione indipendente dallapplicazione che sta usando il sistema.
I fornitori di servizi possono sviluppare servizi specializzati e offrirli a una
serie di utenti di diverse organizzazioni definendone le interfacce e
implementandone le funzionalit.
I servizi si basano su standard XML e i tre standard fondamentali che
permettono la comunicazione tra web service sono:
1. SOAP, che definisce unorganizzazione per lo scambio di dati
strutturati tra i webservice;
2. WDSL, che definisce come possono essere rappresentate le
interfacce dei webservice;
3. UDDI, standard di ricerca che definisce come possono essere
organizzate le informazioni di descrizione dei servizi, utilizzate dai
richiedenti dei servizi per trovarli.

Le architetture applicative dei web service sono architetture debolmente

accoppiate.

Interfacce utente
Le interfacce utente dovrebbero essere progettate per abbinare le
competenze, esperienze e le aspettative dei suoi utenti previsti. Gli utenti del
sistema spesso giudicano un sistema per la sua interfaccia piuttosto che la sua
funzionalit. Uninterfaccia mal progettata pu provocare errori da parte
dellutente. La pessima progettazione dellinterfaccia utente la ragione per
cui tanti sistemi software non vengono mai utilizzati.

Lattenta progettazione dellinterfaccia utente una parte essenziale del

processo di progettazione generale del SW. Nel progettare un interfaccia
bisogna tener in considerazione i fattori umani, quali:
Le persone hanno memoria a breve termine limitata;
Le persone possono sbagliare;
Le persone sono diverse tra loro;
Ognuno ha diverse preferenze sul modo di interagire.

Esistono dei principi nella progettazione di uninterfaccia utente:

Il principio di familiarit dellutente suggerisce che gli utenti non
dovrebbero essere forzati ad adattarsi ad uninterfaccia poich questa
conveniente da implementare.
Il principio di consistenza dellinterfaccia utente implica che i comandi
del sistema e i men dovrebbero avere lo stesso formato.

30
 La consistenza dellinterfaccia su diverse applicazioni: per quanto
possibile i comandi con significati simili in applicazioni diverse
dovrebbero essere espressi allo stesso modo.
Il principio della minima sorpresa appropriato poich le persone
possono irritarsi molto quando un sistema si comporta in maniera
inaspettata.
Il principio di diversit degli utenti riconosce che, per molti sistemi
interattivi, possono esserci diversi tipi di utente.
Il principio di ripristinabilit importante poich gli utenti
commettono errori quando utilizzano un sistema. Di conseguenza si
devono includere funzionalit dellinterfaccia che permettono agli utenti
di ripristinare la situazione precedente. Tali funzionalit possono essere
di tre tipi:
1. Conferma delle azioni distruttive
2. Funzione di annullamento
3. Checkpointing

Esistono 5 stili primari dellinterazione dellutente per linvio di comandi:

1. Manipolazione diretta: lutente interagisce direttamente con gli
oggetti sullo schermo.
2. Selezione dal men: lutente seleziona un comando da una lista
di possibilit (un men).
3. Compilazione di moduli (form): lutente riempe i campi di un
modulo.
4. Linguaggio di comando: lutente invia uno speciale comando e
relativi parametri per dire al sistema cosa fare.
5. Linguaggio naturale: lutente invia un comando in linguaggio
naturale.

Tutti i sistemi interattivi devono avere un metodo per presentare le

informazioni agli utenti.
La presentazione delle informazioni pu essere una semplice rappresentazione
diretta delle informazioni inserite o pu rappresentare informazioni
graficamente.

Il colore aggiunge una dimensione supplementare e pu aiutare lutente a

comprendere le strutture informative complesse.
1. Limitare il numero di colori impiegati;
2. Utilizzare il cambiamento dei colori per indicare una variazione dello
stato del sistema;
3. Utilizzare la codifica dei colori per aiutare gli utenti che provano ad
eseguire un task;
4. Utilizzare la codifica dei colori in modo ragionato e coerente;
5. Essere attenti allaccoppiamento dei colori.

I sistemi devono anche comunicare con gli utenti attraverso messaggi che
forniscono informazioni sugli errori e sullo stato del sistema.

La progettazione dellinterfaccia utente un processo iterativo dove gli utenti

interagiscono con i progettisti e con i prototipi dellinterfaccia per decidere le
funzioni, lorganizzazione e laspetto dellinterfaccia utente del sistema. Ci sono
3 attivit principali in tale processo:
1. Analisi dellutente;
2. Prototipizzazione del sistema;
31
 3. Valutazione dellinterfaccia.

Processo di Testing
Verifica & Convalida
La fase di verifica e validazione serve ad accertare che il SW rispetti i requisiti e
che li rispetti nella maniera dovuta.
Verifica: stiamo costruendo il prodotto nel modo giusto?
Il ruolo della verifica controllare che il SW sia conforme alle sue specifiche:
deve soddisfare i requisiti funzionali e non funzionali specificati.
Validazione (o convalida): stiamo costruendo il prodotto giusto?
La convalida un processo pi generale, che va oltre la verifica: il suo scopo
assicurarsi che il sistema SW rispetto le attese del cliente e se quindi i requisiti
modellano ci che il cliente realmente voleva.

La verifica ha due approcci, una statica e una dinamica:

Ispezioni del SW o revisioni attente
Si analizzano e controllano le rappresentazioni del sistema quali il
documento dei requisiti, i diagrammi di progettazione e il codice
sorgente del programma. Le ispezioni si possono effettuare in tutti
gli stadi del processo e possono essere integrate da unanalisi
automatica del testo sorgente di un sistema o dei documenti
associati. Le ispezioni del SW e lanalisi automatica sono tecniche
statiche poich non necessario eseguire il SW sul computer.
Test del SW
Richiede lesecuzione di unimplementazione del SW con i dati di
test. Si esaminano gli output del SW e il suo comportamento
operativo per verificare che si comporti come richiesto. Il test una
tecnica dinamica.

Tipi di testing
Esistono 2 tipi di test:
1. Test di convalida: serve per mostrare che il SW quello che il cliente
desidera, che soddisfa i suoi requisiti.
2. Test dei difetti: serve per rilevare i difetti del sistema anzich per
simulare il suo uso operativo.

Testing & debugging sono processi distinti ma intrecciati: verifica e convalida

stabiliscono la presenza di difetti nel programma mentre il debugging localizza
e corregge questi difetti e questi errori.

Strumenti di debugging interattivo servono a controllare lesecuzione del

programma istruzione per istruzione, e dopo aver eseguito ogni istruzione si
possono esaminare i valori delle variabili in modo da scoprire la posizione
dellerrore. Dopo aver scoperto un errore nel programma, lo si deve correggere
e si convalida di nuovo il sistema: questo pu richiedere una nuova ispezione
del programma o lesecuzione dei test di regressione, cio eseguire unaltra
volta i test esistenti. Questi ultimi vengono utilizzati per verificare che le
modifiche effettuate al programma non abbiano introdotto nuovi errori.

Pianificazione dei test del software

La pianificazione dei test stabilisce gli standard del processo di test. I piani di
test aiutano i manager a stanziare le risorse e a stimare le tempistiche del
testing, mentre allo staff tecnico servono ad avere una visione generale dei
32
test del sistema, per fare ci bisogna disegnare standard e procedure per
lispezione e test del SW, compilare liste di controllo per guidare le ispezioni del
programma e infine bisogna stabilire lequilibrio tra gli approcci statici e
dinamici.

Ispezione del software un processo di verifica e convalida statico in cui un

sistema SW viene revisionato per cercare errori, omissioni e anomalie. Si pu
applicare a qualunque rappresentazione dellISW:
ai requisiti, ai modelli progetto e nella configurazione e test dei dati.
PRO
Durante il test gli errori possono mascherare altri errori, una volta
scoperto un errore non si pu essere sicuri che altre anomalie delloutput
siano dovute a un nuovo errore o siano un effetto collaterale dellerrore
originario. Poich lispezione un processo statico non ci si deve
occupare delle interazione tra gli errori.
Le versioni incomplete di un sistema possono essere ispezionate senza
costi aggiuntivi.
Oltre a cercare difetti del programma, unispezione pu anche esaminare
attributi di qualit pi vasti, come la conformit agli standard, la
portabilit e la manutenibilit.

Ispezioni e test sono complementari e non in opposizione al processo di verifica

e convalida. Allinizio ci sono le ispezioni dopo i test sul sistema per controllare
le propriet emergenti e verificare che le funzionalit del sistema siano quelle
che il cliente realmente vuole.

CONTRO
Problemi pratici nel disporre le ispezioni, richiedono tempo per la loro
organizzazione e sembrano rallentare il processo di sviluppo.

Ispezione del programma

un processo formale per la revisione dei documenti il cui obiettivo
lindividuazione dei difetti e non la loro correzione. una revisione
attenta, riga per riga, del codice sorgente del programma. I difetti
possono essere errori logici, anomalie nel codice che inidicano una
condizione errata o una non conformit a uno standard organizzativo o di
progetto.

Precondizioni essenziali:
Lispezione del programma un processo eseguito da un team di
almeno 4 persone: autore, lettore, tester e moderatore.
Le specifiche devono essere disponibili, ossia ci sia una specifica
precisa del codice da ispezionare, perch impossibile ispezionare
un componente a livello di dettaglio richiesto per individuare difetti
senza una specifica completa.
I membri della squadra dispezione devono avere familiarit con gli
standard organizzativi.
Deve essere distribuita a tutti i membri del team una versione
aggiornata e compilabile del codice.

Lispezione dovrebbe essere abbastanza breve (non pi di 2 ore),

dovrebbe concentrarsi sullindividuazione dei difetti, sulla conformit agli

33
standard e sulla programmazione di scarsa qualit.
Non deve suggerire come correggere questi difetti, ne raccomandare
modifiche di altri componenti (solo individuarli).
In seguito allispezione, lautore corregge i problemi individuati ed il
moderatore decide se occorre una nuova ispezione al codice, se non
necessaria approva la release del programma.

Durante unispezione spesso utilizzata una lista di controllo degli errori

comuni di programmazione per indirizzare la discussione. Questa lista
pu basarsi su esempi di liste tratte da libri o dalla conoscenza dei difetti
comuni in un particolare dominio di applicazione. Occorrono diverse liste
di controllo per diversi linguaggi di programmazione, poich in ogni
programma ha i suoi errori caratteristici.

Analisi statica automatica

Le ispezioni sono una forma di analisi statica, poich si esamina il
programma senza eseguirlo. Per alcuni errori ed euristiche possibile
automatizzare il processo di controllo rispetto alle liste di controllo degli
errori: da questo nato lo sviluppo di analizzatori statici automatici per
diversi linguaggi di programmazione.

Gli analizzatori statici sono strumenti SW che possono scandire il codice

sorgente di un programma ed individuare possibili errori e anomalie,
interpretando il testo del programma e quindi riconoscendo i tipi di
istruzioni.

Lanalisi statica suddivisa in diverse fasi:

Analisi del flusso di controllo: questo stadio identifica ed
evidenzia i cicli con punti di uscita o dingresso multiplo;
Analisi delluso dei dati: questo stadio evidenzia come sono
utilizzate le variabili nel programma;
Analisi delle interfacce: questa fase controlla la consistenza
delle dichiarazioni delle routine e delle procedure e il loro utilizzo;
Analisi del flusso dinformazioni: questa fase identifica le
dipendenze tra le variabili dinput e output;
Analisi del percorso: questa fase dellanalisi semantica identifica
tutti i possibili percorsi attraverso il programma e le istruzioni
eseguite.

Verifica e metodi formali

I metodi formali di sviluppo del SW si basano sulla rappresentazione
matematica del SW. Si occupano principalmente:
Dellanalisi matematica delle specifiche;
Della trasformazione delle specifiche in una rappresentazione pi
dettagliata e semanticamente uguale;
e/o di verificare che una rappresentazione del sistema sia
semanticamente equivalente a un'altra.

Richiede molto tempo e alti costi.

I metodi formali possono essere utilizzati in diversi stadi del processo di
verifica e convalida.
Si pu sviluppare e analizzare matematicamente una specifica
formale del sistema per cercarne le inconsistenze; questa tecnica
34
 efficace per scoprire errori e omissioni nelle specifiche;
Si pu verificare formalmente, utilizzando dimostrazioni
matematiche, che il codice di un sistema SW conforme alle sue
specifiche;
Per supportare il processo di verifica formale si pu utilizzare un
processo cleanroom.

PRO
Impone unanalisi dettagliata delle specifiche, vengono rilevate eventuali
inconsistenze o omissioni che altrimenti non sarebbero state scoperte se
non dopo la messa in uso del SW, dimostra che il programma sviluppato
soddisfa le sue specifiche.
CONTRO
Richiede notazioni specializzate che possono non essere comprese
da esperti del dominio.
Problemi dei requisiti di sistema possono essere nascosti dalla
formalit.
Molto costoso per sviluppare una specifica e ancora pi costoso per
dimostrare che un programma soddisfa le specifiche.
Verificare non banale pu richiedere molto tempo e c bisogno di
strumenti specializzati, come verificatori di teoremi ed esperti
matematici.

Pur con i loro svantaggi, i metodi formali hanno un ruolo importante nello
sviluppo dei SW critici.

Cleanroom (metodi formali)

Il nome deriva dal processo di cleamroom ed una filosofia di
sviluppo SW che utilizza metodi formali per sopportare
rigorose ispezioni del SW.
La filosofia prevenire il difetto piuttosto che la sua
rimozione.

Questo processo di sviluppo del SW si basa su:

Specifiche formali: il SW da sviluppare viene
specificato formalmente: per esprimere le specifiche si
utilizza un modello a transizione di statiche mostra
come il sistema risponde agli stimoli;
Sviluppo incrementale: il SW viene suddiviso in
incrementi sviluppati e convalidati separatamente;
Programmazione strutturata: sono utilizzati solo un
numero limitato di costrutti di controllo e astrazione dei
dati, il processo di sviluppo del programma un
processo di graduale perfezionamento delle specifiche;
Verifica statica: il SW sviluppato verificato
staticamente utilizzando ispezioni del SW rigorose, non
c un processo di test delle unit o dei moduli per il
codice dei componenti;
Test statistico del sistema: lincremento del SW
integrato viene testato statisticamente per determinare
la sua affidabilit.

Vi sono 3 team coinvolti per lo sviluppo di grandi sistemi:

35
1. Team di specifica: responsabile dello sviluppo e del
mantenimento delle specifiche del sistema, produce
specifiche orientate al cliente (requisiti utente) e
specifiche matematiche per la verifica;
2. Team di sviluppo: ha la responsabilit dello sviluppo e
della verifica, attraverso un approccio strutturato e
formale basato sullispezione del codice, del SW;
3. Team di certificazione: responsabile dello sviluppo di
un insieme di test statistici, basati sulle specifiche
formali, per esercitare il SW dopo che stato
sviluppato.

36