Ingegneria del software

Per ingegneria del software si intende l’applicazione dell’ ingegneria

al software, più in preciso un ingegnere del software scriverà un
componente software che si andrà a combinare con altri, per creare
un sistema software(

Che per definizione sono appunto software o insiemi di software

molto complessi.

).

Allo scopo di limitare la presenza di problemi alla consegna del

sistema software. L’ingegneria del software dovrebbe fare in modo
che il sistema soddisfi il committente:

- il sistema deve fornire i servizi richiesti e come richiesti

- il sistema deve avere una certa qualità: mantenibilità, affidabilità,
efficienza e usabilità.

L’ingegneria del software si occupa del processo di sviluppo di un

software (specifica, progettazione, implementazione, collaudo,
manutenzione).

Modello a cascata

Nello sviluppo di un sistema software, esso subisce dei

cambiamenti. Questo processo è chiamato ciclo di vita, e si
costituisce da varie fasi:

- Analisi e Specifica dei requisiti:definizione dei requisiti

funzionali e non funzionali, e dei vincoli di sviluppo.

- Progettazione: definizione dell’architettura, del controllo, del

comportamento dei componenti, delle strutture dati, degli algoritmi,
della struttura del codice.

- Implementazione: codice

- Collaudo: si controlla se il sistema ha difetti e se il sistema

soddisfa i requisiti

- Manutenzione: modifiche del sistema dopo la consegna

il nome “a cascata” è intuibile dallo schema precedente, cioè ogni
processo porta a dei risultati che di propagano al processo
successivo, è però possibile che se si scopra un errore in un
processo antecedente, rifare un passo indietro.
Uno svantaggio di questo processo è che idealmente per iniziare il
processo k è necessario che tutti i k-1 processi siano stati eseguiti.

Personaggi chiave nel processo software:

• committente, dovrà quindi stabilire i requisiti, determinare il

costo del prodotto e garantire che il prodotto soddisfi i
requisiti.

• manager, si occupa delle attività legate alla gestione, fa da

ponte tra committenti e sviluppatori, si occupa di negoziare
tempi e costi con il committente e gestisce le risorse

• sviluppatori. Realizzano le varie fasi del progetto

Processo:

• insieme strutturato di attività

Modello: 2 significati
- Particolare organizzazione di un processo o di una architettura.

- Diagramma che descrive le caratteristiche, il comportamente o la

struttura del sistema (UML).

Strumenti CASE (Computer-Aided Software Engineering): tool

che supportano il processo software es editor UML.

Categorie di prodotti software:

- generici: creati da un’azienda software, messi sul mercate e
venduti ad un qualsiasi cliente
- customizzati: richiesti da uno specifico committente

Generici vs Customizzati
Costo:
- Customizzati: il costo è a carico del committente
- Generici: il costo è distribuito tra tanti clienti

Specifica:
- Customizzati: i requisiti sono decisi dal committente
- Generici: i requisiti sono decisi dall’azienda in base alle tendenze
del mercato.
 Specifica

Trattasi di tutte quelle attività che servono per produrre il

documento dei requisiti:

- Requisiti funzionali
• Servizi che il cliente richiede dal sistema, cioè cosa deve
fare l’applicazione.

- Requisiti non funzionali

• non descrivono i servizi del sistema, ma ne descrivono
prestazioni e scalabilità.

Requisiti funzionali: per ogni funzione si descrive:

- Cosa accade nell’interazione tra utente e sistema

- Cosa accade in seguito ad un certo input o stimolo

- Cosa accade in particolari situazioni

Il sistema è visto come un entità unica, non si descrive come

funziona internamente il sistema. Poiché le componenti interne, e le
loro architetture sono sviluppate durante la fase di progettazione.

I requisiti possono essere più dettagliati(per sviluppare il progetto) o

meno dettagliati(proposta di contratto).
Requisiti non funzionali

-Requisiti organizzativi: requisiti riguardanti le fasi del processo

software e la gestione del progetto

• Requisiti di sviluppo, metodi di sviluppo, linguaggi di

programmazione, strumenti CASE ecc…
• Requisiti gestionali, tempi, risorse e costi

-Requisiti esterni, riguardano fattori esterni al sistema

• requisiti di compatibilità con altri sistemi
• requisiti giuridici

-Requisiti di prodotto: definiscono la qualità del sistema,

chiamate anche proprità complessiva e emergente.
• Complessiva, proprietà che riguarda il sistema nel suo
complesso, non un singolo componente

• emergente, proprietà che emerge dal sistema dopo che è

stato implementato

- Mantenibilità: grado di facilità di manutenzione

- Portabilità: capacità di migrazione da un ambiente ad un altro
- Recoverability: capacità di ripristinale lo stato e i dati del
sistema dopo un crash
- Efficienza: livello di prestazione del sistema
- Affidabilità: ci sono vari tipi di affidabilità:
- Reliability: capacità di fornire i servizi come definito in
specifica
- Availability: capacità di fornire i servizi nel momento richiesto
- Safety: operare senza causare danni
- Security: protezione contro gli attacchi
Sistemi critici

Quando un sistema non corretto può causare danni si parla di

sistemi critici:

- Safety critical system, un crash può causare danni alle persone

o all’ambiente(ES: sistema di controllo del traffico aereo)

- Business critical system, un crash può determinare perdite

economiche
In questi casi l’affidabilità è la proprietà più importante, il costo del
sistema in questi casi cresce in modo esponenziale rispetto al grado
di affidabilità richiesto.

L’affidabilità è il parametro più importante, nel contesto dei sistemi

critici.

Il costo cresce in modo

esponenziale, dovuto a tecniche
di sviluppo costose(fault-
tolerance) per soddisfare i
requisiti di affidabilità.
L’importanza che si da ai requisiti di prodotto dipende dal sistema:
• Nei sistemi real-time si predilige l’efficienza, poiché devono
rispondere in termini brevi(ES sistema di gestione del mouse
del PC)
• Nei sistemi critici, si predilige l’affidabilità

Sempre in termini di efficienza e affidabilità, alcuni requisiti non

funzionali possono dominare su altri, ES: migliorare la GUI può
diminuire l’efficenza

Relazione tra costo e requisito

non funzionale.

Processo di specifica
Studio di fattibilità
Si decide se è possibile costruire il sistema (analizzando le risorse, i
costi ed i tempi),se sviluppare un sistema nuovo oppure usarne uno
di terze parti si decide se il sistema è effettivamente utile al
cliente/committente, raccogliendo informazioni. Infine si prepara un
documento, che contiene solitamente diverse soluzioni e le relative
risorse(soldi e tempo) necessario allo sviluppo di esse.

Acquisizione, analisi e specifica dei requisiti

Deduzione dei requisiti

Si compie una sorta di indagine per dedurre i requisiti, raccogliendo
informazioni da:

• Dominio Applicativo: dove il sistema viene applicato, es:

Sistema di gestione delle prenotazioni aeree
Dominio: prenotazione di biglietti aerei
Entità: compagnie, voli, clienti, prenotazioni, pagamenti, ...

-Stakeholder:
• In ambito economico, persono che può influenzare il successo
di un impresa(azionisti, finanziatori, amministratori,
dipendenti, clienti, fornitori,pubblica amministrazione,
opinione pubblica, ecc).
• In ambito del processo software, persone che possono
influenzare il processo(cliente / committente,utenti
finali,esperti del dominio
,sviluppatori che hanno lavorato su sistemi simili
,sviluppatori che hanno lavorato sui sistemi che dovranno
interagire
,con quello da sviluppare)

-Studio di sistemi già realizzati-Studio di sistemi con cui dovrà

interagire il sistema.

Analisi dei requisiti

- Classificazione e organizzazione dei requisiti correlati

- Assegnazione di priorità ai requisiti

- Negoziazione dei requisiti: si individuano i conflitti tra i requisiti

e i requisiti non realizzabili, in base alle risorse.

- Modellazione analitica dei requisiti: produzione di modelli che

rappresentano o descrivono nel dettaglio i requisiti

Inoltre bisogna quantificare i requisiti non funzionali utilizzando delle

opportune misure:
- Efficienza
- Affidabilità
- Usabilità

Struttura del documento dei requisiti: introduzione, glossario,

requisiti utente, requisiti di sistema.

Requisiti di sistema
• espansione dei requisiti utente.
• Base per la progettazione, tradurre il linguaggio naturale, che
può presentare: ambiguità(il significato di una parola può
essere ambiguo) e un eccessiva lunghezza, in linguaggio
formale(Linguaggio naturale strutturato: template, Modelli
grafici: UML, Notazioni basate su concetti matematici)

Quantificare i requisiti non funzionali

possiamo specificare i requisiti funzionali in base a misure

quantitative :

• efficienza, tempo di risposta, occupazione in memoria e

numero di transazioni al secondo
• affidabilità, probabilità di malfunzionamento, tempo medio di
malfunzionamento, probabilità di indisponibilità e tempo
medio di indisponibilità
• usabilità, capabilità del sistema da parte dello user, numero di
finestre di helpù

Documento dei requisiti

contiene:
• Risultato della deduzione dei requisiti, scritti sia ad alto livello
che a basso livello
• Ciò che si deve sviluppare
Struttura del documento:
• Introduzione
• Glossario, descrizione termini tecnici
• requisiti utente(funzionali e non funzionali)
• requisiti di sistema(funzionali e non funzionali)
◦ • Identificatore
◦ • Nome
◦ • Tipo (funzionale / non funzionale)
◦ • Priorità
◦ • Descrizione
 ◦ • Modelli (UML)

Il documento è letto da:

• Committente: verifica che i requisiti corrispondano a tutte

le sue esigenze (fase di validazione dei requisiti)
• Manager di progetto: basa sul documento le attività di
gestione (stima dei costi, dei tempi, dei rischi, assegnazione
delle risorse)
• Progettisti: i requisiti di sistema sono la base per fare la
progettazione
• Tester: devono controllare che il sistema implementato
soddisfi i requisiti (oltre a verificare la presenza di bachi)
• Manutentori: leggono il documento per capire gli scopi del
sistema (non è detto che siano le stesse persone che hanno
realizzato il sistema)

Validazione dei requisiti

Si verifica che il documento dei requisiti soddisfi certe prorietà, cosi

da evitare errori di specifica nelle fasi successive. Le prorietà da
verificare sono le seguenti:
- Completezza (soddisfa tutti i requisiti ?)
- Coerenza ( contente definizioni tra loro contraddittorie ?)
- Precisione ( le definizione sono ambigue ?)
- Realismo ( i requisiti possono essere implementati date le risorse
disponibili)
- Tracciabilità ( un requisito è tracciabile quando si riescono a
tracciare i requisiti (dipendenti), la fonte relativa al requisito ed i
componenti del sistema che realizzano il requisito)

la tracciabilità è importante in fase di modifica per verificare che

non abbiamo impatti dannosi sulle altre componenti del sistema.

Per mantenere i requisiti dipendenti,i componenti che realizzano il

requisito e la fonte si utilizza una matrice di tracciabilità.

Tecniche di validazione:
• revisione (realizzato da un gruppo), controllando il manuale di
specifica si individuano eventuali omissioni o
malfunzionamenti
• costruzione di prototipi, si costruiscono prototipi per essere
mostrati al committente e agli utenti.
 Progettazione

In questa fase vengono effettuate diversi tipo di progettazione:

architetturali (UML, data-flow), DB (ER, UML), algoritmi (flow-chart,
UML) e della GUI.
Progettazione architetturale: struttura del sistema in
componenti, metodo di condivizione dei dati, metodo di controllo e
modellazione del comportamento.

Esistono due categorie di componenti:

- Sottosistema: parte del sistema dedicata a svolgere una certa
attività (es gui)
- Modulo: parte di un sottosistema dedicata a svolgere particolari
funzioni legate all’attività del sottosistema (es login della gui).

Information hiding
Un sottositema/modulo deve avere le seguenti caratteristiche:
nascondere i propri algoritmi e dati ai sottosistemi esterni, essere
accessibile solo dalla sua interfaccia e la sua
modifica non deve impattare sul resto del
sistema.
Stili architetturali:

Condivisione dei dati: ogni

componente ha un suo archivio
oppoure i dati sono condivisi in un db
centrale (repository, efficiente per grandi quantità di dati, la
gestione dei dati e fatta solo dal db gentrale, però la strutturazione
dei dati deve essere accettata dai vari componenti e deve avere un
alto grado di affidabilità).

Controllo

Riguarda il controllo tra componenti:

Controllo centralizzato: un componente ha un il compito specifico
di controllo su tutti gli altri componenti (controllore). Il controllore
esegue dei control loop periodici per vedere se ci sono delle
operazioni da eseguire.
Basato su eventi: ogni componente si attiva in base a degli eventi
esterni, gli eventi vengono catturati da un gestore degli eventi. Il
gestore ha diverse modalità per notificare l’evento: broadcast o
broadcast selettivo.
Call return: un componente principale attiva altri componenti che
a loro volta ne attivano altri.

Comportamento: modellazione delle interazioni tra componenti

allo scopo di svolgere una certa funzione. Esistino due approcci:
data flow e ad oggetti.
Data-flow (pipe and filter):
- filter: dato un input, produce un output
- pipe: trasferisce un dato da un filter ad un altro
Il flusso dei dati può essere sequenziale o parallelo. NB: questo
modello non prevede la gestione degli errori.
Ad oggetti: un oggetto è composto da degli attributi e da
operazioni, gli oggetti comunicano tramite lo scambio di messaggi
(operazioni). Gli oggetti sono instanze delle classi. Questo modello
può essere mappato in oop.

Strutturazione
Cliente-Server: i client sanno localizzare i server (che forniscono il
servizio) tramite un collegamente (di rete), inversamente i server
non devono conoscere i client. Utilizzano il protocollo request/reply:
- request: il client richiede il servizio tramite una procedura remota,
e attende
- reply: il server invia una risposta

Stratificato: il sistema è organizzato a livelli (ogni livello fornisce

servizi ai livelli adiacenti, stile tcp)

Architettura per i sistemi distribuiti: l’elaborazione è distribuita

su diverse macchine, inoltre questi tipi di sistema hanno diverse
caratteristiche: condivisione delle risorse, apertura (uso di
componenti provenienti da altri produttori), simultaneità ( processi
simultanei su divese macchine), scalabilità (si possono aggiungere
macchine a fronte di una maggiore velocità di elaborazione) e
tolleranza agli errori (non hanno un single-point-of-fail). I sistemi
distribuiti tuttavia presentano dei problemi: sono difficili da
progettare (complessità), sono sucettibili agli attacchi esterni
(sicurezza), sono difficili da gestire dato che possono avere
componenti diversi ( gestibilità) ed infine non sono prevedibili.

NB: i sistemi distribuiti utilizzano i cosiddetti middleware, software

che permetta lo scambio di dati tra parti eterogenee del sistema
distribuito.

Client-Server:
- collegamenti dedicati: i client hanno dei collegamenti dedicati
verso i server e viceversa
- rete convidisa: i client ed i server si trovano sulla stessa rete (es
rete ad anello)
- internet: utilizzano internet per comunicare tra loro
- stratificato: può essere strutturata su 3 strati (presentazione,
elaborazione e gestione dei dati)
- 2-tiers, i tre strati dell’applicazione sono distribuiti su 2 macchine
(client e server).
- Thin client: il server si occupa dell’ elaborazione e della
gestione dati, mentre il
Client si occupa della presentazione ( determina il
carico del server e la
Capacità di calcolo del client viene sprecata).

- Fat client: il server si occupa della gestione dati ed il client

della presentazione ed
Elaborazione (meno carico sul server però
l’aggiornamento del software di elaborazione deve
essere fatto su tutti i client).
- con codice mobile, questo tipo di C&S è un compromesso tra
thin/fat client, il client scarica dal server il software di presentazione
e una parte di elaborazione (activeX e java applet)
- 3-tiers i tre strati sono eseguiti su tre macchine separate.
- n-tiers (usata per il commercio elettronico)

Architettura ad oggetti distribuiti: si elimina la distinzione tra

C&S, è un sistema composto da un insieme di oggetti che possono
fornire o richiedere servizi. NB: utilizzano un middleware chiamato
ORB (object request broker). Ogni oggetto ha un’interfaccia definita
in modo standard (l’interfaccia indica i servizi forniti dall’oggetto),
inoltre ogni oggetto ha un ID univoco.

Architettura P2P: si trae vantaggio dalla capacita di calcolo di un

insieme di macchine collegate in rete. Il P2P ha le seguenti
caratteristiche: ogni nodo ha lo stesso ruolo, la stessa app gira su
tutti i nodi, ogni nodo può accorgersi della presenta di un altro nodo
e connettersi con esso.
P2P decentralizzata: ogni nodo comunica con i nodi di cui è a
conoscenza (“vicini”), una richiesta viene inoltrata ai “vicini”, se
questi non possono soddisfarla la inoltrano ai propri “vicini”, fe cosi
via, fino a quando non si trova un nodo che può soddisfare la
richiesta, una volta trovato si esegue il percorso inverso oppure i
nodi comunicano direttamente tra di loro.
P2P semi-centralizzata: un nodo indica queli nodi forniscono un
certo dato o servizio ( discovery server), una volta stabilito il
fornitore, il nodo richiedente e quello fornitore si contatteranno
senza
Usare il discovery server.

Sistemi real-time: controllano l’ambiente attraverso componenti

hardware o software di controllo.
Questi sistemi reagiscono a degli stimoli o eventi:
- Periodico: si verifica ad intervalli regolari (prevedibile)
- Aperiodico (imprevedibile)
Dopo di che il ristema esegue un azione o una risposta in base
all’evento captato.
Al centro di questa architettura vi è un sistema di controllo
composto da:
- processi sensori
- processi attuatori
- processi di elaborazione
- interfaccia utente
- gestore dei fallimenti
- controllore

Implementazione
Implementazione dei sottosistemi: solitamente i sottosistemi
vengono implementati in parallelo (un team per ogni sottosistema).

Integrazione dei sottosistemi: vengono integrati i sottosistemi

cosi da creare un unico sistema(possono emergere problemi di
interfaccia), esistono due tipi di approcci:
- big bang: i sottosistemi sono integrati contemporaneamente
( problemi: devono essere completati con le stesse tempistiche
inoltre cosi verrà difficile localizzare un eventuale errore)
- approccio incrementale: i sottosistemi sono integrati uno per
volta (la consegna deve essere coordinata, inoltre quando si
presenta un errore è molto probabile che esso riguardi l’ultimo
sistema)

Collaudo

In questa fase sii cercano/correggono i difetti (bug).

Le attività principali sono:
1. Verifica, il prodotto implementato implementi ogni
funzione senza errori; si svolge allo scopo di trovare
errori
2. Validazione, il prodotto implementato soddisfi i requisiti,
si svolge allo scopo di verificare che il servizio rispetti le
specifiche(anomalie), e che tutte le funzioni previste
siano state implementate(Omissioni).

Per i punti (1) e (2) utilizzano 2 tecniche:

1. Tecnica statica (ispezione): lettura del

codice/documentazione, il sistema non viene eseguito.
2. Tecnica dinamica (testing): il sistema viene eseguito,
osservandone i comportamenti quando si eseguono i test-
case.

Perchè si utilizza l’ispezione?

Il testing può essere troppo costoso ( troppi test-case ed esecuzioni,

inoltre un test case può scoprire un difetto e magari la risoluzione di
quel difetto può portare ad altri difetti e così via), l’ispezione è meno
costosa, inoltre quando il sistema non è completo (non eseguibile) si
può solo ispezionarne il codice. Alcuni requisiti non funzionali si
possono analizzare solo attraverso l’ispezione (portabilità &
mantenibilità, questi requisiti dipendono da come è stato scritto il
codice e dal linguaggio utilizzato). Tuttavia non può collaudare altri
requisiti non funzionali come: efficienza,affidabilità,usabilità poiché
richiedono l’esecuzione del prodotto.
Una comune strategia è quella di eseguire prima l’ispezione, in
modo da individure il maggior numero di errori possibile così da
 poter scrivere meno test case nella fase successiva(poichè sono
costosi) e successivamente il testing.
Ispezione del sistema

Prima di iniziare l’ispezione del codice, esso deve essere supportato

da altri documenti, inoltre deve essere sintatticamente corretto,
spesso si fa uso di una check-list per i probabili difetti da analizzare.

Illustrazione 1: esempio check listg

Ruoli nel team di ispezione:

• Autore (programmatore), corregge i difetti
• Ispettore, trova i difetti
• Moderatore, gestisce il processo di ispezione

Illustrazione 2: fasi progetto di ispezione

Il processo di ispezione è suddiviso il diverse fasi:
• Pianificazione: il moderatore seleziona il team, e controlla
che il materiale sia completo
• Introduzione: il moderatore organizza una riunione
preliminare, il quale descrive il programma in generale, si
visiona il materiale e si stabilisce la checklist
• Preparazione individuale: il ispettori studiano il materiale e
cercano i difetti nel codice (utilizzando la check-list)
• Riunione di ispezione: gli ispettori indicano i difetti
• Rielaborazione: il programma viene fixato dall’autore
• Prosecuzione: il moderatore decide se è necesarrio un
ulteriore processo di ispezione

Per aiutare l’ispezione si utilizzano dei Tool di analisi

statistica,
stumenti CASE che effettuano le seguenti analisi
• analisi del flusso di controllo (loop,cicli con uscite multiple
break, salti incondizionati all’interno di un ciclo(goto),parti di
codice non eseguite(per via di goto ))
• analisi dell’uso dei dati (var non inizializzate, scritte ma
non lette, variabili non utilizzate, violazione dei limiti di un
array, condizioni che danno sempre lo stesso valore boolean)
• analisi delle interfacce (analizza procedure mai invocate,
dichiarazioni consistenti, cioè quando invoco un metodo mi
assicure di utilizzare il corretto tipo e numero di parametri,
risultati di funzioni non usati)
• analisi della gestione della memoria (puntatori non
assegnati, errori nell’aritmetica dei puntatori).

L’uso di questo tool non sostituisce comunque l’intero processo di

analisi, poiché non riesce ad individuare tutti i casi di errore.

Testing

Il sistema viene messo in esecuzione, per scoprire la presenza di

difetti.

Processo di testing:
- Preparazione dei test-case (dati di input, dati di output attesi)

- Esecuzione di un test-case, fornendo i dati di input al sistema

- Confronto dei risultati di output con quelli attesi, se il confronto è

negativo si eseguono le fasi successive
- Debugging, si scopre la posizione dell’errore eseguendo
istruzione per istruzione e controllando il valore delle variabili
- Correzione
- Test di regressione, si ripete il test case precedente fallito e tutti
i test case precedenti, per verificare che la correzione dell’errore
non abbia introdotto ulteriori test.

Il processo di testing viene iterato per ogni test-case

Approcci di testing:

I test case sono composti da dati di input e dati output attesi, i dati
di input possono essere infiniti, chiaramente noi vogliamo testare il
sistema un numero finito di volte.

Si utilizzano due approcci.

Black box(uso delle partizione di equivalenza): il sistema è
visto come una scatola, sono visibili solo i dati input e i dati di
output del sistema, non come essi vengono elaborati.

Black box poiché il sistema non è visibile.

I test case vengono fatti in base alla conoscenza di quali sono i dati
di I/O. L’insieme dei dati viene suddiviso in partizioni di
equivalenza, da ogni partizione si ricaveranno i test-case. Dato
l’insieme dei dati di input e l’insieme di output, una partizione di
equivalenza è un sottoinsieme dei dati di input per cui il sistema
produce lo stesso dato di output, oppure, il sistema produce dati di
out che appartengono sempre ad un determinato sottoinsieme.

Per individuare le partizione inizialmente si identificano i possibili

dati di output, eventualmente in sottoinsiemi, per ogni dato di
output o sottoinsieme si individuano una o più partizioni di
equivalenza tra i dati di input. Per ogni partizione si scelgono un
numero finito di test-case.

Esempi funzioni:
Per ogni dato di output si possono identificare più partizioni
di equvalenza, non per forza 1 come nella figura
precedentemente

White box (uso del flow-graph): il sistema è visto come una

scatola trasparente, cioè è visibile come i dati vengono elaborati, la
scelta dei test-case è fatta in base al codice. L’obiettivo è testare
ogni parte del codice: ogni istruzione deve essere eseguita almeno
una volta, ogni condizione deve essere testata sia nel caso sia vera,
sia nel caso sia falsa.

Per fare ciò si utilizzano i flow-graph (grafo che rappresenta i

possibili cammini nel programma).
Flow-graph:

Ogni nodo rappresenta un’istruzione (o un gruppo di istruzioni in

sequenza), gli archi il flusso del controllo. Un cammino si dice
indipendente se introduce almeno una nuova sequenza di istruzioni
o una nuova condizione, nel flow-graph, un cammino è indipendente
se attraversa almeno un arco non ancora percorso nei cammini
precedenti.

Un insieme di cammini indipendenti forma la base dei cammini, la

cardinalità di tali cammini è data dalla complessità ciclomatica.
Illustrazione 4: I cammini colorati equivalgono ai cammini indipendenti che formano
la base dei cammini
Illustrazione 3: esempio costruzione grafo

Complessità ciclomatica:
n° di cammini indipendenti equivale alla CC del flow-graph G

CC(G) = #archi - #nodi +2

CC(G) = #regioni (area delimitata da archi e nodi oppure un’area
esterna al grafo)
CC(G) = #nodi_predicato +1

CC è il numero minimo di test richiesti per eseguire almeno una

volta ogni parte di codice(generando un test per ogni path
indipendente).
Esistono strumenti CASE che supportano il white box(Dynamic
program analyzer), il quale ci dice quali parti del flow graph sono
state interessate dal test case e quali parti sono ancora da testare.

ESEMPIO DI TEST WHITE BOX (utilizziamo la funzione f vista

in precedenza)

A, B e C

rappresentano i nodi interessati

Testing con integrazione incrementale: un sistema è composta

da vari componenti, Il testing riguarda ciasciuno di essi e la loro
integrazione:
- Testing dei componenti: riguarda i singoli componenti (svolto
dall’autore), solitamente si usa il whitebox, questo test ha lo scopo
di eliminare i bachi.
- Testing di integrazione (testing dei componenti implementati
fino ad adesso): si svolge quando si integra un nuovo componente.
Lo scopo è verificare il corretto interfacciamento tra i componenti(Le
funzioni dei componenti devono essere invocate nel modo corretto e
le funzioni devono ritorare il valore atteso). Per svolgere i test di
integrazione si riapplicano i test precedenti. Riguarda
principalmente la verifica, per la validazione solo quando sono
inseriti sufficienti componenti. (testing whitebox per pochi
componenti integrati, inversamente si usa black box)

- Release testing: lo scopo è la validazione del sistema da

consegnare al committente( si usa black box), ci sono due tipi di
release testing:
- Prodotti customizzati (test di accettazione): il committente
controlla il soddisfacimento dei requisiti finché non è soddisfatto
- Prodotti generici: Alpha (gruppo ristretto ), si genera una
versione alpha del sistema che viene collaudata da utenti esperti o
sviluppatori, una volta testata e corretta si genera la beta

/ Beta (clienti) Testing da parte dei clienti

Testing con integrazione “big-bang”: i componenti sono

integrati tutti in una sola volta. Si effettuano dei test sui componenti
(prima dell’integrazione) e il release testing (dopo l’integrazione).

Stress testing: serve per verificare l’efficienza e l’affidabilità del

sistema (completamente integrato) generando carichi di lavoro
superiore al normale, se il sistema non regge, è possibile individuare
difetti non emersi dagli altri test

Back-to-back testing: si usa quando varie versioni del sistema

sono disponibili:

• Prototipi
• Versioni del sistema per sistemi operativi diversi
• Versioni del sistema per tipi di hardware diversi
• Nuove versioni con funzioni in comune con le precedenti

. Si effettuano i test su tutte le versioni e si confrontano gli output,

per vedere se sono uguali.

Manutenzione

Un sistema deve essere aggiornato nel tempo altrimenti perde

progressivamente utilità e valore economico.

Tipi di manutenzione:
- correttiva: vengono corretti dei difetti delle fasi di specifica
(costose potrebbero essere necessario riprogettare il sistema),
progettazione (costose perchè si devono modificare i componenti
del sistema) e implementazione ( meno costosi da correggere)
- adattiva ( adattamento del sistema a cambiamento di
piattaforma ) per esempio hardware nuovi o nuovo sistema
operativo(interessa solo i requisiti funzionali)
- migliorativa, miglioramento dei requisiti o realizzazione di nuovi
requisiti(interessa sia i requisiti funzionali che non funzionali)

NB: il costo della

manutenzione è
pari o superiore al
costo di sviluppo

Fattori che
influenzano
il costo di

manutenzione:
- Dipenzenza dei componenti, la manutenzione di un componente
potrebbe richiede la manutenzione, di altri componenti del sistema.
- Linguaggio di programmazione, un linguaggio ad alto livello è più
facile da mantenere.
- Struttura del codice, codice ben strutturato e documentato è più
facile da mantenere
- Collaudo (una fase di collaudo accurata riduce il numero di difetti
scoperti successivamente alla consegna)
- Qualità della documentazione.
- Stabilità dello staff ( il costo si riduce se chi ha sviluppato il
sistema è lo stesso a mantenerlo)
- Età del sistema, il costo aumenta con l’aumentare dell’età del
sistema, per esempio un sistema vecchio utilizzerà linguaggi di
programmazione superati e quindi satà più difficile da mantenere.
- Stabilità del dominio dell’applicazione ( se il dominio varia, il
sistema deve essere aggiornato)
 -Stabilità della piattaforma il cambiamento della piattaforma (hw o
sistema operativo)può richiedere la manutenzione del sw, questo
succede spesso.

Processo di manutenzione:

Illustrazione 5: tipico processo di modifica

1. Richieste di modifica(possono essere richieste di nuovi

requisiti, correzione di difetti o adattamenti ), attraveso un
documento chiamato CRF (Change Request Form) si
specifica la richiesa di modifica.
2. Analisi dell’impatto ( si valutano quali componenti vengono
influenzati dalle modifiche, i costi e i vantaggi della modica)
3. Pianificazione della release: un gruppo di persone
chiamato CCB(Change Control Board) solitamento formato da
manager, committenti e sviluppatori prendono in atto le
decisioni di modifica e decidono quali realizzare e in che
modo.

Ancora sul CRF

Trattasi di un documento formale che descrive una modifica.

Tra le informazioni troviamo:

 • Una descrizione della change da implementare e la priorità
• Componenti influenzati dalla modifica, valutazione della
proposta di modifica(benefici, costi tempi) e la modalità di
implementazione

Illustrazione 6: tipico esempio di CRF

• Approvazione o rifiuto della proposta

Il primo punto è compilato da colui che propone la change, il

secondo dallo staff e il terzo dal CCB.

Implementazione_della_modifica:si aggiorna la specifica/progettazione/codice del

sistema e si collauda il tutto
Release del sistema: viene rilasciata al committente la nuova versione

(URGENT PATCH-STILE MIKEL)

Manutenzione di emergenza: non si passa attraverso le fasi del processo di

manutenzione, si modifica direttamente il codice e si rilascia una versione aggiornata,
dopo di che si ritorna “con calma” sul problema risolvendolo in modo più adatto e si
rilascia un’ altra versione.

Solitamente si crea una urgent patch quando bisogna risolvere un problema in fretta,
per vari motivi:
1. Errori che impediscono di utilizzare il sistema
2. Malfunzionamento del sistema che causa perdite economiche
3. Introduzione di leggi che richiedono la modifica del software
4. ecc…

Essendo la urgent patch una soluzione rapida al problema,

solitamente si effettua non aggiornando i documenti di sistema, si
adotta la soluzione più breve e non si struttura bene il codice.
Ritornando poi al problema in un secondo momento

Versione: istanze del sistema che differisce per qualche aspetto

dalle altre istanze(nuovi requisiti, correzione di difetti ecc..)

Release: una particolare versione che viene distribuita al

committente/cliente, una release comprende:
• eseguibile
• file di config, indica come la release dev’essere installata
• file dati, per far funzionare il sistema
• programma di installazione, per installare il sistema su
diverse piattaforme
• documentazione, cartacea e elettronica

Illustrazione 7: le release sono quelle intermedie

Possiamo identificare le versione numericamente o tramite gli

attributi.

Attributi di una versione: committente, linguaggio, stato dello

sviluppo, piattaforma(hw e sistema operativo), data di creazione;
versioni diverse si possono distinguere per almeno un attributo.
Con l’identificazione numerica non abbiamo informazioni su di essa.

Identificazione basata su attributi:

la versione è identificata da alcuni suoi attriburi: es

2000/linux/Dbserver

Con l’identificazione tramite attributi dobbiamo fare in modo che

ogni versione sia diversa dalle altre
A volte si usa una combinazione dei 2.

Quando bisogna rilasciare una release?

Solitamente quando ci sono delle correzioni di difetti segnalati da
committenti/clienti, aggiunta di nuovi requisiti o una nuova
piattaforma.

Tuttavia per i prodotti generici, la frequenza può avere effetti sul

mercato del prodotto:
- release frequenti: i clienti potrebbero non acquistare l’ultima

- release poco frequenti: i clienti potrebbero cambiare software

Version Management System: strumento case per la gestione

delle versioni. Un repository contiene le versioni del codice e del
sistema, per lavorare sul codice si estrae una versione (check-out)
e se ne salva una copia (working copy). Quando il lavoro è
completo verrà inserita nella repository eseguendo un commit,
creando automaticamente:

• Una nuova versione del componente.

• Una nuova versione del sistema con il componente modificato.

I commit generano una nuova versione del componente lasciando

immutata la versione precedente.

Funzioni VMS(insieme di funzioni che svolgono vari compiti):

- identificazione delle versioni e della release(numerano

automaticamente le versioni )
- modifica controllata(ogni versione non sovrascrive quella
precedente, informazioni su chi ha modificato un componente)
- gestione della memorizzazione(per ridurre lo spazio occupato ogni
versione è descritta come le loro differenze rispetto a una versione
master)
- registro storico delle modifiche.
Esempio concreto di VMS: RCS

l’ultima versione dell’ applicazione è chiamata Master, quando

creiamo una nuova versione la vecchia è sostituita da un delta che
indica solo le differenze tra la versione vecchia e quella nuova

Ogni versione ha una data e un autore, si può richiedere a RCS una

versione per numero data e autore, RCS applica tutti i delta alla
versione corrente per ottenere la versione richiesta RCS usa file di
testo ASCII per il codice I delta sono specificati come comandi di
editing da
applicare alla versione master.

Costruzione del sistema:processo di composizione dei

componenti del sistema in un programma (es MAKE).

Illustrazione 8: esempio delle dipendenze che mantiene un makefile

Illustrazione 9: esempio costruzione di una versione

Configurazione software: insieme di informazioni prodotte da un

processo software:
- Documentazione: docs dei requisiti, modello di progettazione, test-
case, modifiche rrispetto alla versione precedente (CRF), info sul
committente, documento di gestione, informazioni su strumenti
case etc.
- Programma
- Strutture dati

Database delle configurazioni: contiene le varie configurazioni

software corrispondenti alle release di un sistema. Fornisce info utili
per la manutenzione inoltre può essere integrato con strumenti
CASE/VMS

Sistemi ereditati: vecchio sistema che deve essere mantenuto nel

tempo, i problemi con questi sistemi sono molteplici: sono poco
struttirati, spesso manca la documentazione, gli sviluppatori sono
difficili da reperire e sono sviluppati per vecchie piattaforme, motivo
per cui sono sistemi difficili da mantenere. Le strategie che si
possono adottare sono molteplici: dismissione del sistema,
manutenzione, software re-engineering o reimplementazione del
sistema. La scelta della strategia dipende dalla qualità e utilità
del sistema.(è difficile smantellarli perché magari
mantengono informazioni crititche)

Categorie di sistemi ereditati

Qualità bassa, Utilità bassa: alto costo di manutenzione e ritorno

economico scarso ( disimissione)
Qualità bassa, Utilità alta: alto costo di manutenzione, ma con
un buon ritorno economico (re-engineering o re implementazione)
Qualità alta, Utilità bassa: basso costo di manutenzione, poco
ritorno economico (manutenzione o dismissione)
Qualità alta, Utilità alta: basso costo di manutenzione, buon
ritorno economico (manutenzione)

Forward engineering (ingegneria diretta): si crea un nuovo prodotto

partendo dai requisiti
Re-engineering: il nuovo sistema è dato da qualche trasformazione
del vecchio, allo scopo di rinnovarlo. I requisiti funzionali rimangono
gli stessi. I vantaggi sono: rischio ridotto, costi ridotti.

Fe vs Re

Come si effettua un attività di re-enginerring ?

1. Si traduce il codice sorgente del vecchio sistema in un altro

linguaggio di programmazione, poic
2. Ristrutturazione del codice, si rende il codice più leggibile
3. Ristrutturazione dei dati, cambiamento delle strutture dati e
migrazione dei dati in un più moderno DBMS

Il costo del re-enginerring è influenzato da questi fattori:

- Qualità del software
- Qualità della documentazione
- Quantità di odice da ristrutturare
- Quantida di dati da ristrutturare
- Disponibilità di staff

Reverse engineering: può essere utile per il re-engineering,

generando la documentazione partendo dal codice.
 Gestione del progetto

Il processo dell’ingegnera è accompagnato dalle attività di

gestione(progetto=processo software + attività di gestione):

• Assegnazione di risorse umane/tecnologiche/finanziarie,

poiché esse sono limitate
• Stima del tempo, poiché ci sono date prestabilite
• Stima del costo e dei rischi, poiché il costo è stato stabilito da
contratto.

Nel caso i tre punti precedenti non siano rispettati si dice che il
progetto fallisce.

Lo scopo è quello di consegnare il sistema nei tempi previsti con un

costo non superiore a quello stabilito. In caso contrario la
produzione di un prodotto fallisce.

Personaggi chiave nel progetto:

• Committente, decide i requisiti, valuta il costo e verifica che il

prodotto soddisfi i requisiti.
• manager, si occupa della gestione del progetto(Negozia tempi
e costi del contratto con committenti, fa da ponte da
sviluppatori e committenti , pianifica e supervisiona il
progetto).
• Sviluppatore, realizza le fasi del progetto(Analista, progettista,
programmatore e tester).
Attività di gestione:

- Scrittura proposte: permette di ottenere un contratto(comprende:

obbiettivi, stima dei costi, stima dei tempi metodi ecc...)
- Stima del costo
- Pianificazione: viene scomposto il processo sw in task(milestone
e deliverables), inoltre si stabilisce una tempistica e si assegnano
le risorse umane/tecnologiche/finanziarie(hw, sw e personale).
- Gestione dei rischi
-Monitoraggio: si valutano i progressi del processo rispetto alla
pianificazione, a fronte di qualche problema si effettua una
revisione:(si rivede la pianificazione/costi o discussione con
il committente )
-Presentazione e scritture rapporti: si informa il committente
sull’avanzamento del progetto.

Difficoltà di gestione:
1. il SW è intangibile non si può vedere materialmente il
progresso di un progetto, per sopperire a questo si scrive della
buona documentazione
2. I progetti sono unici, quindi l’esperienza acquisita con i
progetti precedenti è relativamente utile.

Le scelte di gestione sono soggette a:

1. incertezza, le conseguenze delle decisioni non sono certe.
2. Irreversibilità, tempo e risorse impiegate non sono
recuperabili
3. Complessità, difficoltà di coordinare le varie attività di
sviluppo.

Processo di gestione:
Piano di progetto: documento che definisce le attività di gestione
di un progetto, viene scritto all’inizio del progetto ed aggiornato
durante il progetto:
- Introduzione: obbiettivi (ibuettuvu) e vincoli
- Organizzazione: persone/ruoli
- Analisi dei rischi: possibilità di rischi e come affrontarli
- Risorse sw e hw, stima del costo e dei tempi di consegna
- Divisione del lavoro: in task, milestone e deliverables.
- Tempistica: dipendenze tra le attività, temi stimati per raggiungere
ogni milestone, allocazione delle persone alle attività
- Rapporti: tipi di rapporto che saranno prodotti durante il progetto.

Attività di pianificazione:

• Scomposizione in task (attività all’interno del processo sw), si

identificano le dipendenze tra i vari task
◦ Un task può iniziare solo quando un insieme di altre attività
è stato ultimato
◦ Task paralleli o sequenziali

• Definizione di Milestone e Deliverable.

- Tempistica: stima dei tempi, durata di un task e durata del

progetto
Praticamente per stabilire il tempo necessario si utilizza questa
regola: si calcola il tempo come se tutto andasse bene poi si
aggiunge 30% per i problemi previsti + 20% per problemi imprevisti
- Assegnazione delle risorse ai task

Principi di pianificazione:

- Ripartizione: ripartizione del progetto in task

- Dipendenza tra task
- Assegnazione del tempo: ad ogni task si assegna un tempo(data di
inizio-data di fine)
- Responsabilità definite: ogni task deve essere affidato ad una
determinata persone o a un gruppo
- Risultati definiti: ogni task deve produrre un risultato
- Punti di controllo: bisogna stabilire dei momenti precisi in cui
verificare l’avanzamento del processo (completamento di una
milestone).

La pianificazione si basa sulle informazioni iniziali, che sono scarse

ed evolve durante il progetto(maggiori informazioni, la
pianificazione va continuamente rivista).
Per permettere alla pianificazione di valutare l’andamento del
progetto si stabiliscono Milestone e deliverable.

Milestone: terminazione di un task o di un insieme di task. La

milestone è un punto di controllo per l’avanzamento del progetto,
un rapporto sullo stato del progetto viene presentato quando si
raggiunge una milestone(questo stato viene utilizzato per verificare
l’avanzamento rispetto alla pianificazione). Milestone troppo
frequenti determinano uno spreco di tempo nella preparazione di
rapporti, inversamente, con milestone poco frequenti, (bib oernettibi
du) non permettono di valutare l’avanzamento del processo.
Deliverable(tipo particolare di milestone): milestone i cui risultati
devono essere consegnati al committente.

Illustrazione 12: CC:T1, T3, T9, T11, T12: 55 giorni

Illustrazione 11: activity network

Illustrazione 10: T2,T4 indica una dipendeza tra task

Illustrazione 14: CC: T1, M1, T3, M4, T9, M6, T11, M8, T12:55 giorni lavorativi

Illustrazione 13: activity network con milestone

Cammino critico: cammino nella activity network più lungo in
termini di tempo, il CC fornisce il tempo per finire il progetto, ritardi
nei task presenti nel CC determinano il ritardo nel intero progetto.
Mente i ritardi al di fuori del CC non determinano un ritardo finale, a
meno che non determinino un nuovo CC.

Illustrazione 15: Bar Chart

Indica il tempo previso per completare un task, e il suo ritardo

massimo(senza che diventi un nuovo CC).

Bar Chart
con
indicazione
di chi
svolge le
varie task.
Il ritardo è causato soprattutto da:
• scadenze non realistiche
• mutamenti dei requisiti che non tengono conto delle
tempistiche
• stima troppo ottimistica del lavoro
• rischi non considerati

Cosa fare in caso di ritardo ? fare una stima dell’entità del

ritardo, sviluppare entro le scadenze le funzioni fondamentali e
parlarne con il committente, per spiegare perché i tempi non sono
realistici.

Rischi
Il rischio ha due caratteristiche:
incertezza (probabilità di verificarsi) e perdita(se il rischio si
verifica influenza negativamente tempistiche e qualità). I rischi si
possono classificare in base alla loro fonte (causa) e a ciò che
colpiscono (effetto).

Gestione dei rischi, ha lo scopo di identificare i rischi, valutarne le

conseguenze e definire strategie preventive.

Attività di gestione dei rischi:

• Identificazione rischi
• Analisi dei rischi: probabilità del rischio e la sua gravità
• Pianificazione dei rischi: evitare o minimizzare i rischi,
utilizzando strategie preventive o reattive
• Monitoring dei rischi: si controlla che la probabilità o la gravità
degli effetti di un rischio siano cambiate.
Classificazione dei rischi in base alla causa

• Rischi tecnologici, hw o sw
• Rischi riguardanti il personale
• Rischi organizzativi, derivanti dall’organizzazione aziendale
• Rischi strumentali, strumenti CASE
• Rischi dei requisiti, cambiamento dei requisiti
• Rischi di stima, valutazione delle caratteristiche del sistema

Illustrazione 16: esempio stima dei rischi

Classificazione dei rischi in base all’effetto

 Illustrazione 17: esempio classificazione rischi in base all'effetto
Analisi dei rischi

Si stima la probabilità del rischio e la gravità dei suoi effetti nel caso
si verificasse. La valutazione è fatto in base alle informazioni sul
progetto, sul team, sul processo, sull’organizzazione ecc… e
l’esperienza del manager.

Illustrazione 18: esempio analisi dei rischi

Molto bassa: < 10%
Bassa: 10-15 %
Moderata: 25-50%
Alta: 50-75%
Molto Alta: >75%

Pianificazione dei rischi

Per limitare i rischi si utilizzano:

1. Strategie Preventive, ridurre la probabilità che si verifichi.

2. Strategie Reattive, ridurre gli effetti nel caso si verifichi.

Illustrazione 19: esempio pianificazione dei rischi

Monitoring dei rischi

Si verifica per ogni rischio individuato se la sua probabilità o gli

effetti dovuti al suo verificarsi, se possono aumentare o diminuire.
 Modelli di processo
Tipo di organizzazione delle fasi del processo software

Caratteristiche del processo software:

- Visibilità: il progredire del processo deve essere visibile
dall’esterno tramite la produzione di risultati in ogni fase
- Supportabilità: il processo è supportato da strumenti case
- Affidabilità: gli errori devono essere scoperti durante il processo sw
- Robustezza: il processo deve essere in grado di continuare
nonostante si presentino problemi inaspettati
- Mantenibilità: le attivita possono variare per esigenze
organizzative o per migliorare il processo
- Rapidità: durata dell’intero processo a partire dalla fase di specifica

NB: non è possibile ottimizzare tutte le fasi (rapidità e visibilità sono

in contrasto)

Modello a cascata:

Prima di passare alla

fase successiva, la fase
corrente deve essere
stata completata.
Questo modello richiede
una definizione dei
requisiti già dettagliata
all’inizio. Ogni fase
produce della documentazione che descrive i risultati ottenuti nella
fase del processo.

Il commitente può controllare il soddisfacimento dei requisiti solo

alla consegna.
Pro: buon grado di visibilità (fasi bel distinte)
Cons: difficoltà ad effettuare cambiamenti una volta che il processo
è in corso
Le fasi hanno lunga durata: riguardano tutto il sistema, anche se
nella realtà le fasi non sono cosi sequenziali. NB: non è sempre
possibile fare una specifica iniziale completa.

Prototipo “usa e getta”

Il prototipo è una versione preliminare del sistema che realizza un
sottoinsieme dei requisiti. I prototipo “usa e getta”, hanno lo scopo
di comprendere un insieme di requisiti poco chiari. Questo tipo di
prototipo è cobinato con il modello a cascata. Altri usi di questo
prototipo potrebbero essere:
- Sperimentare soluzioni sw
- Back-to-back testing
- Training degli utenti in attesa del vero sistema

Modelli iterativi
Questi modelli prevedono la ripetizione di alcune fasi del processo. Il
sistema è un prototipo evolutivo, il prototipo evolve nel sistema
finale.

Sviluppo evolutivo:
- generazione del primo prototipo: si considera un sottoinsieme
dei requisit, se ne fa la specifica, la progettazione l’implementazione
e il colaudo. In ogno fase, è possibile ritornare a quella precedente.
Infine si genera una versione delsistema che realizza i requisiti
considerati (se si ricevono dei feedback dal committente si devono
ripetere le fasi).
- generazione dei prototipi successivi: si considera un altro
sottoinsieme di requisit e si aggiorna il prototipo corrente.
- si itera il processo fino a quando tutti i requsiti sono stati
considerati

Si incomincia con i requisiti funzionali chiari e con maggiore priorità,

i requisiti non funzionali si trattano successivamente (efficienza,
affidabilità), con questo modello il committente può valutare ogni
fase del prodotto tramite dei feedback.
Pro:
- Specifica e progettazione non devono esser definite in modo
completo all’inizio del processo, perchè il processo supporta il
cambiamento dei requisiti.
- Controllo del soddisfacimento dei requisiti durante il processo.
- Disponibilità anticipata di un sistema funzionante

Contro:
- Il processo è poco visibile (la documentazione non viene sempre
aggiornata a causa dell’elevato costo).
- I prototipi devono essere generati rapidamente
- Il committente deve essere disponibile a fornire un feedback
- Modello costoso (sviluppo di varie versioni)
- Il codice potrebbe essere poco strutturato se si applicano molti
cambiamenti.

Sviluppo incrementale: cerca di combinare i vantaggi di entrambi

i modelli precedentemente descritti (a cascata / evolutivo).Viene
generato un prototipo evolutivo, però si ha un processo con
maggiore visibilità:
- Faso iniziali: specifica ad alto livello, si stabilisce quale sarà il
numero di incrementi (versioni) del sistema durante lo sviluppo. In
questa fase viene progettato il sistema.
- Fasi cicliche (iterazione per ogni incremento, in ordine di priorità):
specifica in dettaglio dei requisiti dell’incremento, viene
implementato l’incremento (codifica ed integrazione), viene
eseguito il collaudo e generata la release del sistema corrente (il
committente rilascia un feedback).

Ha gli stessi vantaggi dello sviluppo evolutivo, tuttavia è meno

soggetto all’incertezza ( come quello a cascata), rendendo cosi il
processo più visibile ( si conoscono irequisiti associati ad ogni
incremento, ed il numero di incrementi è definito a priori)

Sviluppo rapido del software: il modello a cascata è poco adatto

alla rapidità (avendo fasi lunghe), per quanto riguarda invece lo
sviluppo evolutivo/incrementale si va ad ottenere rapidità poichè vi
è una consegna anticipata del sistema al committente (prototipo
evolutivo). Nei team piccoli, ciò potrebbe generare overhead. Infatti
negli anni 90 per ovviare a questo problema svilupparono il
cosiddetto approccio “agile”:
- pronto al cambiamento: è scontato che i requisiti cambieranno
- flessibile: le persone non si adattano ad un modello di processo
“prescrittivo”, ma è il modello che si adatta alle esigenze delle
persone.
Lo scopo di questo approccio è la consegna rapida del prodotto
effettuando una migliore analisi nelle fasi di implementazione, le
altre sono eseguite solo ad alto livello (rapidamente).
eXtreme Programming (XP): la rapidità è l’obiettivo
fondamentale, i tempi di consegna sono ristretti. Ci si focalizza
sull’implementazione, le altre fasi si eseguono solo ad alto livello.
Tuttavia servono degli accorgimenti garantiscano la qualità del
prodotto. In questo modello si hanno numerose release del sistema
(dato anche dal fatto che si possano cambiare il requisiti), inoltre il
committente è particolarmente coinvolto nel processo.
Fasi:
- Specifica a (molto) alto livello: i requisiti sono definiti ad alto
livello (sottoforma di scenari non strutturati) e gli scenari sono
ordinati per priorità ( ogni scenario è suddiviso per incremento).
- Pianificazione: si stabiliscono assieme al committente quali
incrementi saranno realizzati, i tempi di consegna della prossima
release e i testa da eseguire (nella fase di collaudo)
- Progettazione semplice: si definisce o si aggiorna l’architettura
ad alto livello, i dettagli vengono definiti in corso d’opera (mentre si
implementa).
- Implementazione: i programmatori lavorano a coppie, ogni linea
viene scritta e visionata da due persione (aumentandone la
probabilità di “vedere” un difetto). Una persona scrive , l’altra può
controllarlo o fare il refactoring (ristrutturazione e pulizia del
codice). Le coppie cambieranno il proprio ruolo dinamicamente a
seconda degli incrementi (condivisione della conoscenza del
codice con altre coppie).
- Sviluppo con test iniziale: i test case sono definiti durante la
fase di pianificazione, il programmatore scrive il codice in modo che
il test venga superato
- Possesso collettivo: un programmatore può modificare
qualunque parte del codice
- Collaudo: i test sono scelti prima dell’implementazione. Ci sono
tre tipi di testing ad ogni incremento:
- Testing dell’incremento: se l’incremento supera il test viene
integrato
- Testing di integrazione: tutti i testi di unità sono ripetuti quando
si integra un incremento, si verifica se l’incremento ha generato
errori.
- Testing di accettazione: il committente controlla il
soddisfacimento dei requisiti

Il team deve esere composto da poche persone (2-10), in questi casi

il sistema da sviluppare non può avere grandi dimensioni.
Committente on-site: presenza a tempo pieno del committente
nel team di sviluppo.
La qualità del prodotto è mantenuta attraverso lo sviluppo con test
iniziale, la programmazione a coppie e le release frequenti (che
causano tanti collaudi).

Modelli a spirale: le attività sono distribuite in vari settori del

piano. Il processo avviene attraversando varie volte tali settori
secondo un processo a spirale. I modelli a spirale includono le
attività di gestione, oltre alle fasi del processo software. Esistono
due versioni del modello a spirale:
1: prevede il rilascio del sistema alla fine dell’intero processo
2: prevede lo sviluppo del sistema tramite un prototipo evolutivo.

Include le attività di
gestione (manager)
Ogni loop rappresenta un
task del processo. I loop
sono divisi in 4 settori:
- Determinazione di
obiettivi e alternative
- Valutazione delle
alternative e dei rischi
- Sviluppo e convalida
- Pianificazione

Determinazione di obiettivi e alternative: obiettivi specifici del

task corrente e possibili solozioni del task in corso.
Valutazione rischi e alternative: gestione dei rischi e costruzione
di prototipi per valutare le varie soluzioni alternative.
Sviluppo e convalida: sviluppo di modelli/simulazioni/test per
valutare i prototipi, scelta della soluzione in base alla valutazione del
prototipo e sviluppo e verifica dell’attività in base alla soluzione
scelta.
Pianificazione: il progetto viene revisionato e si passa alla
pianificazione della fase successiva.
NB: una release ad ogni loop e ogni settore di un loop è una fase del
processo.

Sviluppo basato sul riuso (Component Based Software

Engineering): CBSE si basa sul riuso di componenti esistenti (di
altri sistemi o commerciali).
Fasi:
- Specifica
- Analisi dei componenti: si valutano quali dei componenti
esistenti possono essere riutilizzati
- Adattamento dei requisiti: si modificano irequisiti in modo che
possoano essere realizzati attraverso i componenti esistenti
- Progettazione con riuso: definizione dell’architettura del
sistema composta da componenti esistenti e componenti ad-hoc da
implementare
- Implementazione: codifica dei componenti ad-hoc ed
integrazione con quelli esistenti
- Collaudo
Pro: consegne veloci, riduzione del costo e riduzione dei rischi (il
componente era già stato collaudato)
Contro: necessità di compromessi sui requisiti (i componenti
esistenti potrebbero non essere perfettamente adatti a soddisfare i
requisiti)

Caratteristiche del processo software:

- Visibilità
- Affidamento: gli errori evono essere scoperti durante il processo
sw
- Robustezza: il processo deve essere il grado di continuare
nonostante si prensentino dei problemi
- Rapidità: durate dell’intero processo, a partire dalla fase di
specifica
Visibilità Affidabilità Robustezz Rapidità
a
Cascata Alta Bassa Bassa Bassa
S. Bassa Alta Alta Alta
Evolutivo
S. Media Alta Media Alta
Increment
ale
XP Bassa Alta Alta Alta
Spirale 1 Media Media Alta Bassa
versione
Spirale 2 Media Alta Alta Alta
versione
Riuso Alta Media Bassa Media