File PDF .it

Condividi facilmente i tuoi documenti PDF con i tuoi contatti, il Web e i Social network.

Inviare un file File manager Cassetta degli attrezzi Assistenza Contattaci



Ingegneria del Software 1 13 .pdf



Nome del file originale: Ingegneria_del_Software_1_13.pdf
Titolo: Ingegneria del Software 1

Questo documento in formato PDF 1.4 è stato generato da Writer / OpenOffice.org 1.1.4, ed è stato inviato su file-pdf.it il 27/10/2016 alle 16:15, dall'indirizzo IP 77.241.x.x. La pagina di download del file è stata vista 1839 volte.
Dimensione del file: 3.5 MB (173 pagine).
Privacy: file pubblico




Scarica il file PDF









Anteprima del documento


Università degli Studi di Roma La Sapienza
Facoltà di Scienze Matematiche Fisiche e Naturali
Corso di Laurea Quinquennale in Informatica

IngegnerIa del Software 1
Rielaborazione del corso tenuto dal professor Bottoni

Autore: Andrea Saporito
Vers.: 1.2

Indice
Introduzione..........................................................................................................................................5
PARTE PRIMA....................................................................................................................................7
Tecnologia ad oggetti........................................................................................................................... 9
Cos'è un oggetto?............................................................................................................................. 9
Classi ed istanze...............................................................................................................................9
Come collaborano gli oggetti?......................................................................................................... 9
Come gli oggetti si identificano tra di loro?.................................................................................. 10
Classe............................................................................................................................................. 10
Attributi..................................................................................................................................... 10
Operazioni................................................................................................................................. 11
Associazione.................................................................................................................................. 11
Classe di associazione............................................................................................................... 12
Aggregazione e Composizione...................................................................................................... 12
Generalizzazione............................................................................................................................12
Polimorfismo.............................................................................................................................13
Ereditarietà................................................................................................................................ 13
Classe astratta............................................................................................................................13
Oggetto Classe............................................................................................................................... 13
PARTE SECONDA............................................................................................................................15
Ingegneria del Software...................................................................................................................... 17
Prodotto..........................................................................................................................................17
I miti.......................................................................................................................................... 18
Miti del management............................................................................................................18
Miti della clientela................................................................................................................19
Miti del programmatore........................................................................................................19
Processo......................................................................................................................................... 20
Modelli di processo................................................................................................................... 22
Modello sequenziale lineare................................................................................................. 23
Modello del Prototyping.......................................................................................................23
Modello RAD....................................................................................................................... 24
Modello Incrementale...........................................................................................................25
Modello a spirale.................................................................................................................. 25
Modello a spirale WINWIN................................................................................................. 26
Modello ad assemblaggio di componenti............................................................................. 27
Modello dello sviluppo concorrente.....................................................................................27
Altri modelli......................................................................................................................... 28
Progetto.......................................................................................................................................... 29
Persone...................................................................................................................................... 30
Prodotto..................................................................................................................................... 33
Processo.................................................................................................................................... 34
Il principio WWWWHH........................................................................................................... 34
PARTE TERZA..................................................................................................................................35
Metriche..............................................................................................................................................37
Metriche di processo...................................................................................................................... 37
Metriche di progetto.......................................................................................................................38
Metriche dimensionali................................................................................................................... 39
Metriche basate sulle funzioni....................................................................................................... 39
Pagina 1

Feature Points............................................................................................................................41
Object Points............................................................................................................................. 41
Modello COCOMO....................................................................................................................... 42
Metriche per la qualità................................................................................................................... 45
Efficienza di rimozione dei difetti.............................................................................................46
Integrazione delle metriche nel processo software........................................................................ 47
Introdurre le metriche................................................................................................................47
Garanzia di qualità del software......................................................................................................... 49
Cos’è la qualità?.............................................................................................................................49
La garanzia di qualità del software................................................................................................ 50
Le revisioni del software................................................................................................................50
Le revisioni tecniche formali......................................................................................................... 51
Linee guida per le revisioni....................................................................................................... 52
Tecniche per la revisione...........................................................................................................53
Garanzia di qualità su base statistica............................................................................................. 54
Il Piano SQA.................................................................................................................................. 54
Gestione delle configurazioni Software............................................................................................. 57
Individuazione degli oggetti della configurazione.........................................................................58
Controllo delle versioni................................................................................................................. 59
Controllo del cambiamento............................................................................................................59
Esami della configurazione....................................................................................................... 61
Relazioni sulla situazione..........................................................................................................61
Documenti formali.................................................................................................................... 62
Software Change Request (Richiesta di cambiamento)....................................................... 62
Software Change Report (Report dei cambiamenti).............................................................63
Engineering Change Order (ECO)....................................................................................... 64
Configuration Audit Report..................................................................................................66
Configuration Status Report (resoconto sullo stato della configurazione)...........................67
PARTE QUARTA..............................................................................................................................69
Unified Process...................................................................................................................................71
Fasi ed attività................................................................................................................................ 71
Fase 1: Inception............................................................................................................................ 72
Fase 2: Elaboration........................................................................................................................ 73
Fase 3: Construction...................................................................................................................... 74
Fase 4: Transition...........................................................................................................................75
Requirements (Requisiti)............................................................................................................... 76
Diagramma dei casi d'uso..........................................................................................................78
Documentare i casi d'uso...........................................................................................................80
Attività e Stati........................................................................................................................... 82
Determinare i requisiti...............................................................................................................84
Attività di Ombrello: Stime.......................................................................................................85
La scelta tra sviluppo ed acquisto.........................................................................................87
Attività di ombrello: Analisi dei Rischi.................................................................................... 88
Tabella dei rischi.................................................................................................................. 90
Gestione del Rischio.............................................................................................................93
RMMM e RIS.......................................................................................................................94
Attività di ombrello: Pianificazione.......................................................................................... 97
Principi fondamentali........................................................................................................... 97
Pagina 2

Relazione tra personale e lavoro...........................................................................................98
Distribuzione del carico di lavoro........................................................................................ 98
Definizione dei compiti di un progetto software.................................................................. 98
Scelta dei compiti............................................................................................................... 101
Definizione di un reticolo dei compiti................................................................................101
Pianificazione temporale.................................................................................................... 102
Esempio: SurfReport.......................................................................................................... 103
Sorveglianza della tabella dei tempi...................................................................................105
Analisi del valore acquisito................................................................................................ 106
Controllo degli errori..........................................................................................................107
Piano di progetto................................................................................................................ 107
Riepilogo................................................................................................................................. 107
Riepilogo documenti prodotti................................................................................................. 107
Analisys (Analisi)........................................................................................................................ 108
Classi di Analisi...................................................................................................................... 108
Diagramma delle classi.......................................................................................................109
Analisi Architetturale.............................................................................................................. 112
Diagramma dei Package..................................................................................................... 113
Realizzazione dei casi d'uso.................................................................................................... 115
Diagrammi di sequenza...................................................................................................... 115
Diagrammi di collaborazione............................................................................................. 116
Diagrammi di sequenza o collaborazione?.........................................................................119
Trovare Classi ed Associazioni............................................................................................... 119
Trovare le classi..................................................................................................................119
Riepilogo................................................................................................................................. 122
Riepilogo dei documenti prodotti............................................................................................122
Design (Progettazione).................................................................................................................122
Classi di progetto.....................................................................................................................124
Completezza e sufficienza..................................................................................................124
Primitività...........................................................................................................................124
Alta coesione...................................................................................................................... 124
Basso accoppiamento......................................................................................................... 124
Progettazione delle associazioni.........................................................................................124
Classi collezione.................................................................................................................126
Note e vincoli..................................................................................................................... 127
OCL.................................................................................................................................... 127
Approccio BCE.................................................................................................................. 144
Generalizzazione, ereditarietà, polimorfismo e loro problemi........................................... 145
Interfacce................................................................................................................................. 146
Come usare le interfacce?...................................................................................................147
Individuare le interfacce..................................................................................................... 149
Sottosistemi............................................................................................................................. 149
Realizzazione dei casi d'uso – progetto...................................................................................150
Diagrammi degli stati......................................................................................................... 150
Riepilogo................................................................................................................................. 154
Riepilogo dei documenti prodotti............................................................................................155
Implementation (Implementazione).............................................................................................155
Piano d'integrazione................................................................................................................ 155
Componenti............................................................................................................................. 155
Pagina 3

Diagramma dei componenti............................................................................................... 156
Diagramma di Deployment..................................................................................................... 157
Il Programma (o sistema)........................................................................................................ 158
Riepilogo................................................................................................................................. 158
Riepilogo dei documenti prodotti............................................................................................158
Test...............................................................................................................................................158
Difetti dello Unified Process........................................................................................................160
APPENDICI..................................................................................................................................... 161
Refactoring....................................................................................................................................... 163
Creare entità di programma......................................................................................................... 163
Cancellare entità di programma................................................................................................... 163
Cambiare entità di programma.....................................................................................................163
Muovere variabili membro.......................................................................................................... 164
Composizioni primitive............................................................................................................... 164
Proprietà da non violare............................................................................................................... 164
Esempio di refactoring complesso............................................................................................... 164
Specifica degli effetti del refactoring...........................................................................................167
Bibliografia....................................................................................................................................... 171

Pagina 4

Introduzione

Introduzione
Questa è la rielaborazione del corso di Ingegneria del Software 1 tenuto dal professor Bottoni. Ho
pensato di realizzare questo lavoro per mettere insieme, in modo ordinato e scorrevole, tutte le informazioni presentate durante il corso. Alcuni punti sono stati approfonditi rispetto a quanto fatto a
lezione, in quanto mi sembrava doveroso approfondire tali argomenti. Esistono argomenti che non
ho approfondito o per mancanza di informazioni specifiche o perché si allontanavano troppo dagli
argomenti trattati durante il corso.
Il lavoro è idealmente diviso in quattro parti: nella prima tratto la tecnologia ad oggetti, in modo da
fissare una volta per tutte la terminologia che utilizzo, nella seconda introduco l'ingegneria del software, nella terza parlo delle attività ausiliarie, cioè di quelle attività che si svolgono parallelamente
alle attività principali nel processo di ingegneria del software (ho ritenuto opportuno anticipare questa parte perché alcuni settori dello Unified Process che andrò ad analizzare nella parte successiva,
si appoggiano sugli argomenti qui trattati), nella quarta parlo dello Unified Process cioè di un modello per l'ingegneria del software (si è scelto questo argomento perché rappresenta lo stato dell'arte
nella progettazione orientata agli oggetti, si avvale del linguaggio UML ed è una sintesi di vari modelli). All'interno dello Unified Process parlerò anche delle attività di ombrello, cioè di quelle attività che iniziano nelle primissime fasi del processo e si svolgono parallelamente a quelle principali. In
ultimo darò una breve introduzione del Refactoring.

Pagina 5

PARTE PRIMA

Pagina 7

Tecnologia ad oggetti

Tecnologia ad oggetti
Cos'è un oggetto?
Un oggetto è un qualcosa che possiede uno stato, degli attributi e dei comportamenti; usando la
similitudine con la realtà, possiamo pensare ad una tazza: essa ha uno stato (piena o vuota), degli attributi (forma e colore) ma nessun comportamento (è un oggetto passivo: viene riempito e viene
vuotato, ma non lo fa automaticamente); pensando invece ad un cane abbiamo vari comportamenti:
mangia, beve, abbaia, si muove, ecc.
Nei computer ovviamente un oggetto non è qualcosa di reale, ma, al più, una rappresentazione: così
la tazza riprodotta sullo schermo non è una tazza reale! Proprio per questo motivo la tazza sullo
schermo può avere dei comportamenti: riempi per farla riempire, svuota per farla svuotare.
Chiamo dominio degli attributi l'insieme degli attributi caratteristici di un oggetto.
Tutti gli oggetti hanno un'identità: essa rappresenta in modo univoco un oggetto; nell'esempio delle
tazze, due tazze possono essere uguali (stesso stato), ma non hanno la stessa identità: se prendo una
tazza in mano, l'altra rimane sul tavolo; sono dunque in grado di distinguere le due tazze pur essendo esse uguali. Ovviamente l’esempio è valido solo se nel dominio degli attributi delle tazze si trascura la posizione sul tavolo.
Per ovviare a questo inconveniente possiamo fare un esempio che non richiede di ignorare nel dominio degli attributi nulla: nel campo sub-atomico ogni particella può essere perfettamente uguale
ad altre e, pur non potendo conoscere la posizione di una particella, siamo in grado di bombardarla
senza toccare le altre particelle. Di conseguenza due particelle uguali sono in qualche modo distiguibili e quindi non identiche.
Nella programmazione ad oggetti gli attributi vengono anche chiamati proprietà, mentre i comportamenti sono anche chiamati metodi od operazioni.

Classi ed istanze
Un oggetto, normalmente, è un'istanza di una “cosa” e può essere una delle istanze della stessa
“cosa”. Ad esempio una tazza da caffè è un elemento dell'insieme delle possibili tazze. La descrizione della “cosa” è chiamata classe. Un oggetto è un'istanza di una classe: la classe definisce come
sono fatti gli oggetti da essa derivati, quindi l'insieme dei possibili stati, attributi e comportamenti,
l'oggetto stabilisce i valori posseduti dagli attributi. È importante notare che i comportamenti sono
uguali tra tutti gli oggetti: l'azione riempi della tazza sarà realizzata in modo identico indipendentemente dall'istanza della tazza in quel momento.

Come collaborano gli oggetti?
Normalmente è assurdo pensare che un oggetto viva da solo senza comunicare nulla agli altri (se
non interagisce non ha motivo di esistere: pensate ad un programma che vi occupi memoria, senza
fare assolutamente nulla!). La comunicazione tra due oggetti avviene per mezzo di messaggi: questi
messaggi attivano una o più operazioni dell'oggetto destinatario del messaggio. Ad esempio ad un
oggetto Spedizione viene chiesto di spedire della merce, tale oggetto manderà dunque un messaggio
all'oggetto Magazzino richiedendo di ridurre la quantità disponibile della detta merce; in altre parole
Spedizione attiva un comportamento di Magazzino: riduciMerce!

Pagina 9

Tecnologia ad oggetti

Come gli oggetti si identificano tra di loro?
Immaginiamo che Spedizione abbia a che fare con due Magazzini, uno per la merce A ed uno per la
merce B; come fa a sapere a quale oggetto inviare il messaggio?
Ad ogni oggetto viene assegnato un OID (Object Identifier o Identificatore dell'oggetto), questo
identificatore è unico per ogni oggetto e non ce ne sono mai due uguali. Un OID è per l'esattezza un
riferimento: se Spedizione ha accesso agli OID dei suoi due Magazzini, ha accesso ai due Magazzini. Quindi per poter spedire un messaggio ad un suo Magazzino, Spedizione deve conoscere il suo
OID.
L'OID viene anche detto legame o, appunto, riferimento.
Questi legami possono essere persistenti o transitori. Un legame è persistente se esso è memorizzato
da qualche parte (probabilmente un attributo) e tale parte viene salvata alla chiusura del programma
e può essere ripristinata successivamente. Un legame è transitorio se l'OID non viene salvato.
Ma se il legame è transitorio, come si fa a conoscerlo? Esso può essere: recuperato da un altro oggetto che lo contiene in maniera persistente, essere passato con un messaggio, od essere creato sul
momento. La creazione di un OID avviene quando si istanzia un oggetto di una classe (il costrutto
new del Java restituisce appunto un OID).
Una volta che Spedizione conosce l'OID dei suoi magazzini, come fa ad inviargli un messaggio?
Supponiamo che Spedizione abbia memorizzato, transitoriamente o persistentemente, gli OID in
due attributi merceA e merceB. Vuole inviare un messaggio al Magazzino contenente la merceA,
dicendogli di ridurre la disponibilità della sua merce? Userà dunque merceA.riduciMerce(). Con
questa sintassi si indica di prendere l'OID memorizzato in merceA e di inviare un messaggio all'oggetto con quell'OID dicendogli di eseguire il comportamento riduciMerce.
Questo sistema è detto più brevemente: Invocare il metodo riduciMerce dell'oggetto Magazzino riferito da merceA (od ancora più brevemente Invocare il metodo riduciMerce di merceA).

Classe
Abbiamo detto che la classe è il descrittore di un insieme di oggetti e di essi specifica i possibili stati, attributi e comportamenti. Specifichiamo un po' meglio il concetto.
Possiamo considerare una classe come uno stampo per la creazione degli oggetti. La classe indica
gli attributi che un oggetto deve possedere (dominio degli attributi) nonché il loro tipo; specifica altresì tutti i comportamenti dell'oggetto. Dato che uno stato normalmente è definito attraverso i valori
possibili degli attributi, la classe normalmente non specifica gli stati in maniera esplicita.

Attributi
Un attributo è identificato da un nome e da un tipo e può contenere un valore; le classi definiscono i
tipi, mentre gli oggetti assegnano il valore agli attributi stessi. Un tipo può essere primitivo o una
classe; nel primo caso esso viene fornito dal linguaggio ad oggetti (stringhe, numeri, booleani) mentre nel secondo significa che l'attributo dovrà contenere un OID di un oggetto utente istanziato dalla
classe definita come tipo (es.: merceA è di tipo Magazzino, significa che l'attributo merceA dovrà
contenere un OID di un oggetto che sia un'istanza di Magazzino).
Gli attributi hanno anche una visibilità cioè viene definito quali oggetti possono vedere l'attributo.
Visibilità Pubblica: l'attributo di un oggetto può essere visto e manipolato da qualsiasi altro oggetto
che abbia accesso all’oggetto che lo contiene.
Pagina 10

Tecnologia ad oggetti
Visibilità Privata: l'attributo di un oggetto può essere visto e manipolato solo da un oggetto che sia
istanza della classe che ha dichiarato l'attributo.
Visibilità Protetta: l'attributo di un oggetto può essere visto e manipolato da un oggetto che sia
istanza della classe che ha dichiarato l'attributo e da tutti gli oggetti istanze di classi “figlie” (vedi
più avanti la Generalizzazione).
Esistono anche altri tipi di visibilità, definite dai linguaggi di programmazione, come Package
(l’accesso è possibile anche a tutte le classi appartenenti allo stesso “insieme logico”) o Friend
(l’accesso è possibile anche alle classi definite come “amiche”).
A volte si parlerà di attributi derivati: essi in realtà non esistono come attributi fisici, vengono invece calcolati di volta in volta, attraverso operazioni su altri attributi; ad esempio un attributo “tempo
trascorso” può essere derivato: viene calcolato in base alla differenza tra la data/ora corrente ed una
iniziale.

Operazioni
Le operazioni specificano gli algoritmi che manipolano i dati dell'oggetto (attributi). L'operazione
può contenere una lista di parametri in ingresso (parametri formali), cui saranno assegnati valori
specifici nella chiamata (parametri attuali) e può restituire un valore all'oggetto chiamante.
Il nome dell'operazione insieme alla lista dei tipi dei parametri formali è chiamata firma (o signature, in inglese) di un'operazione. La firma deve essere unica all'interno di una classe: questo significa
che una classe può avere più operazioni con lo stesso nome, purché la lista dei tipi dei parametri formali sia sempre diversa.
La visibilità delle operazioni segue le stesse regole della visibilità degli attributi.
Prassi della programmazione ad oggetti è quella di rendere gli attributi non pubblici e permettere
agli altri di modificare o leggere gli eventuali dati necessari, attraverso appositi metodi pubblici (in
modo da poter effettuare maggiore controllo e/o aggiungere solo apposite operazioni alla lettura/variazione di un dato)

Associazione
Quando due oggetti devono comunicare tra di loro, significa che tra le due classi vi è un'associazione. L'associazione indica, dunque, il fatto che gli oggetti delle due classi devono, in qualche modo,
comunicare.
L'associazione può avere un nome e le classi che ne fanno parte un ruolo (cioè un nome), semplicemente per ricordare che tipo di associazione hanno le due classi ed il loro ruolo. Ad esempio due
classi, Ordine e Spedizione, potrebbero avere un'associazione “Spedizione dell'ordine” con i loro
ruoli di ordine e di spedizione, ad indicare che le due classi devono collaborare per spedire un ordine e che, rispettivamente, Ordine si preoccuperà di fornire gli ordini a Spedizione che provvederà a
spedirli.
L'associazione può avere una molteplicità, cioè ad ogni capo di un associazione si stabiliscono
quanti oggetti della classe possono partecipare alla collaborazione. Normalmente le molteplicità comuni sono:
0..1

al massimo un oggetto può partecipare all'associazione

0..*

quanti oggetti si vuole (compreso zero!) possono partecipare all'associazione

1..1

uno ed un solo oggetto può partecipare all'associazione (può essere indicata solo con 1)
Pagina 11

Tecnologia ad oggetti
1..*

da uno a quanti se ne vuole possono partecipare all'associazione

*

Nessun limite al numero di oggetti che possono partecipare all'associazione

Ovviamente possono esisterne anche altre.
Così l'associazione “Spedizione di un ordine” avrà da entrambi i lati * ad indicare nessun limite sul
numero di ordini che possono far parte di una spedizione e nessun limite al numero di spedizioni attraverso cui possono essere serviti gli ordini.
Le associazioni che hanno ad entrambi i capi * sono dette molti a molti, quelle dove una lato vi è 1
e dall'altro vi è * sono dette uno a molti o molti ad uno (a seconda da che “lato” si guarda l'associazione).
Le associazioni possono avere una navigabilità esplicita cioè un'indicazione che indica da che lato
è possibile percorrere l'associazione; ad esempio se abbiamo un'associazione tra Utenti (che contiene i nomi degli utente) e Password (che contiene le relative password) è assai probabile che dagli
utenti vogliamo risalire alle password, ma non viceversa; quindi l'associazione avrà una navigabilità
da Utenti a Password. Se la navigabilità non è indicata, il più delle volte, indica una navigabilità bidirezionale.

Classe di associazione
Benché normalmente non esistano in alcun linguaggio di programmazione le classi di associazioni,
esse vengono usate quando si vuole assegnare attributi e/o comportamenti ad un'associazione stessa.
Ad esempio un'associazione tra Studenti e Corsi potrebbe avere una classe di associazione (Valutazione) che mantiene i voti degli studenti rispetto ai corsi seguiti.
Nella pratica tale classe sarà poi tradotta in una classe reale che avrà due associazioni: una con Studenti ed una con Corsi.

Aggregazione e Composizione
L'aggregazione e la composizione sono due tipi di particolari di associazioni. Con questi due “costrutti” si indica che una classe è “composta” da altre classi. In altre parole un oggetto che contiene
tanti oggetti di una determinata classe viene detto contenitore, mentre gli oggetti che fanno parte
dell'oggetto contenitore sono detti aggregati o componenti (anche se quest'ultimo termine è poco
usato perché potrebbe causare ambiguità con un termine omonimo, ma dal significato completamente diverso, usato dallo Unified Process).
L'aggregazione è un costrutto che implica transitività e asimmetria: se A contiene la classe B e B
contiene la classe C, allora A contiene la classe C; A non può però contenere se stessa, B non può
contenere A (oltre a se stessa) e C non può contenere né A né B (oltre a se stessa).
La composizione aggiunge la dipendenza esistenziale: se A contiene B attraverso la composizione,
significa che se A viene distrutto, allora anche B deve esserlo e B non può essere creato se non viene creato A.

Generalizzazione
La generalizzazione è una relazione “tipo-di” tra una classe più generica (superclasse) ed una più
specifica della precedente (sottoclasse). La sottoclasse è una tipologia della superclasse. Un oggetto
della sottoclasse può essere usato ovunque sia permesso l'uso di un oggetto della superclasse.
La generalizzazione permette di non ridefinire proprietà già definite. Gli attributi e le operazioni già
Pagina 12

Tecnologia ad oggetti
introdotti nella superclasse possono essere riusati nella sottoclasse (si dice che la sottoclasse eredita
gli attributi ed i metodi della classe genitrice). Essa facilita la specifica incrementale, l'uso delle proprietà comuni tra classi ed una migliore localizzazione delle modifiche.
Anche la generalizzazione è transitiva ed asimmetrica.
Si noti che di ereditarietà si parla in relazione alle classi, non agli oggetti (si applica ai tipi non ai
valori).

Polimorfismo
Un metodo ereditato da una sottoclasse è spesso usato così com'è. Tuttavia esso può essere modificato o riscritto completamente. Quando questo avviene si parla di metodo polimorfo: quale implementazione del metodo verrà eseguita, dipenderà da qual'è l'istanza su cui quel metodo viene chiamato. Al chiamante quale sia l'implementazione non importa, proprio perché le sottoclassi possono
essere adoperate ovunque si possa adoperare una superclasse (le diverse versioni del metodo accettano gli stessi tipi e restituiscono lo stesso tipo, quindi per la classe chiamante non cambia nulla).

Ereditarietà
L'ereditarietà è alla base della generalizzazione, senza ereditarietà le classi non potrebbero usare attributi od oggetti della superclasse, né ridefinire metodi della superclasse.
A volte si parla di ereditarietà multipla; questo avviene quando una classe è sottoclasse di più superclassi. Benché in certi frangenti possa essere utile essa introduce anche problematiche legate all'ereditarietà: se due superclassi hanno due attributi o due metodi con la stessa firma, la sottoclasse quale
eredita? Come fa ad usare l'una o l'altra? Per questo motivo alcuni linguaggi (come il Java) permettono solo l'ereditarietà singola.

Classe astratta
Una classe astratta è una classe genitrice che non ha direttamente istanze: solo le sue sottoclassi possono essere istanziate. Generalmente una classe è astratta perché almeno uno dei suoi metodi è
astratto: cioè definisce la firma, ma non ha implementazione.
Le classi astratte non possono venir istanziate ma sono molto utili nella modellazione. In un certo senso,
esse definiscono un “vocabolario” di alto livello che arricchisce il linguaggio della modellazione.
Una classe astratta permette di definire alcune operazioni comuni, lasciando alle sue sottoclassi l'implementazione di operazioni specifiche. Ad esempio una classe astratta Video (per una videoteca) potrebbe
fornire i metodi generici dei supporti visivi, lasciando astratta un'operazione spesaAffitto che indica il
costo di affitto di un video. Le sue sottoclassi Videocassetta e DVD implementeranno il metodo.

Oggetto Classe
Abbiamo detto che le classi sono gli “stampi” per gli oggetti. In certi casi, però, bisogna riferirsi alla
classe come un oggetto. Ciò avviene quando vi è bisogno che alcuni attributi siano comuni a tutte le
istanze o dei metodi agiscano globalmente. In tal caso si parla di Oggetto Classe.
Un esempio di attributo comune è un contatore che conta il numero di istanze: essa non può essere parte
di un oggetto, perché l'oggetto non sarebbe a conoscenza di altre istanze.
Un esempio di metodo globale, legato al precedente, è un metodo che restituisce il numero di istanze
create fino a quel momento.

Pagina 13

PARTE SECONDA

Pagina 15

Ingegneria del Software

Ingegneria del Software
Una definizione generale dell'ingegneria del software, può essere: il processo da applicare al prodotto (il software) per portare a termine con successo, in breve tempo, a costo contenuto ed ad alta qualità, il progetto.
Una definizione esatta è data dall'IEEE, come l'unione dei seguenti due punti: “1) Applicazione di una strategia sistematica, disciplinata e misurabile allo sviluppo, esercizio e manutenzione del software. 2) Studio delle strategie di cui al
punto 1)”.

Dunque dobbiamo definire prodotto, processo e progetto.

Prodotto
Nel nostro caso il prodotto è il software che vogliamo realizzare. Andando nello specifico possiamo
dire che il software ormai ci circonda: esistono numerosi sistemi manovrati dai computer e su di
essi gira il software (basta pensare anche a quanti tipi di software esistono: di sistema, gestionali,
embedded, real time, scientifico, per database, per videogiochi, per l'elaborazione di testi, per l'intelligenza artificiale, basato sul web, multimediale, ecc.). Normalmente quando si cerca di pensare al
software (inteso come il prodotto di un certo processo), viene da paragonarlo alla produzione di un
qualche oggetto. La similitudine però ha molte pecche:
1. Il software si sviluppa e si struttura, non si fabbrica: i metodi per fabbricare oggetti reali sono
nettamente diversi dai metodi per sviluppare un software
2. Il software non si consuma: l'hardware tende a danneggiarsi nel corso del tempo, il software no.
Tuttavia anche il software può essere soggetto a difetti, ma mentre nell'hardware il difetto corretto non provoca altri problemi (non verissimo, ma corretto dal nostro punto di vista), nel software
la modifica può ripercuotersi su altre parti aggiungendo nuovi difetti. La curva di “deterioramento” può essere rappresentata dal successivo diagramma:
Dove la idealized curve è la curva ideale che accadrebbe se le correzioni e le nuove aggiunte non inserissero nuovi difetti. L'actual curve mostra la curva reale.

Pagina 17

Ingegneria del Software

3. La costruzione di materiali usa pezzi già pronti e li combina solamente, il software è spesso realizzato ad hoc. Questo in parte è dovuto al fatto che non sempre il collegamento di sistemi già
pronti porta al sistema finale; oltre a questo è decisamente più difficile sviluppare pensando al
riuso ed i tempi stretti fanno sì che spesso le soluzioni siano cercate solo nel range interessato (e
di conseguenza non riutilizzabili). L'ingegneria del software cerca di invertire la tendenza e cerca
di estendere a tutto il prodotto quello che succede adesso nelle interfacce utente (pulsanti, caselle
di testo, ecc. sono elementi standard riutilizzati).

I miti
Prima di vedere che cos'è il processo, vediamo di sfatare alcuni miti.Questi miti sono nati agli inizi
degli anni '70, ma alcuni di essei potrebbero essere ancora validi.
Miti del management

Mito: abbiamo già interi volumi di standard e procedure da seguire nello sviluppo. Non c'è forse
tutto l'indispensabile?
Realtà: Quanti di questi standard e procedure sono conosciute ed applicate? Sono seguiti in maniera
completa ed ottimizzata? Sono usati standard e procedure che riflettano i metodi moderni di sviluppo del software? La risposta a tutte queste domande è NESSUNA.
Mito: Abbiamo i più moderni strumenti di sviluppo. Dopo tutto acquistiamo sempre i computer più
recenti.
Realtà: Non è vero che al computer più potente corrisponde un miglior sviluppo del software. È
come dare una formula 1 ad uno che deve imparare a guidare... Spesso sarebbe più conveniente
Pagina 18

Ingegneria del Software
spendere i soldi in strumenti adatti allo sviluppo, piuttosto che potenziare i computer, ma costringere i programmatori a lavorare a mano (per mancanza di strumenti).
Mito: se siamo in ritardo possiamo recuperare aumentando il numero di programmatori.
Realtà: Sviluppare un software non è, come abbiamo detto, costruire un oggetto. Immettere “un'orda mongola” all'interno del processo di sviluppo rallenterà ancora di più lo sviluppo, in quanto la
nuova gente dovrà essere addestrata, dovrà capire cosa hanno fatto gli altri programmatori, ecc.
Mito: se decido di far realizzare un progetto software ad una terza parte, posso stare tranquillo perché tutto il lavoro verrà svolto esternamente.
Realtà: Le “terze parti” non hanno, spesso, idea del funzionamento interno; se non si sa gestire i
propri processi interni, è assai difficile riuscire a gestire il processo svolto da uno esterno.
Miti della clientela

Mito: un'affermazione generica degli scopi è sufficiente per cominciare a scrivere i programmi; i
dettagli si possono trattare in seguito.
Realtà: un'insufficiente descrizione preliminare è la causa principale del fallimento del progetto.
Senza un'accurata descrizione, non si riesce a definire i confini del progetto.
Mito: I requisiti di un progetto mutano di continuo, ma i mutamenti si gestiscono agevolmente grazie alla flessibilità del software.
Realtà: Il software non è flessibile, né tanto meno lo è svilupparlo. È vero, i requisiti cambiano, ma
apportare il cambiamento durante le prime fasi del progetto è più facile e meno costoso, che non
quando il software è pronto. Su questo argomento avremo modo di tornare per un approfondimento.
Miti del programmatore

Mito: Una volta scritto e messo in opera un programma, il nostro lavoro è finito.
Realtà: La maggior parte del lavoro avviene una volta che il software è stato rilasciato.
Mito: Fino a quando il programma non è in condizioni di essere eseguito, non c'è modo di valutarne
la qualità.
Realtà: Uno dei metodi più efficaci di esame della qualità del software, la revisione tecnica formale, si applica già dall'inizio di un progetto. Avremo modo di approfondire l’argomento.
Mito: il solo prodotto di un progetto concluso è il programma funzionante.
Realtà: un programma funzionante è solo una parte del software. La documentazione è il fondamento di uno sviluppo riuscito e, cosa ancora più importante, è la guida dell'attività di manutenzione.
Mito: l'ingegneria del software ci farà scrivere un'inutile e voluminosa documentazione che inevitabilmente rallenterà le cose.
Realtà: l'ingegneria del software punta sulla qualità, la migliore quantità porta ad un minor lavoro,
un minor lavoro porta a tempi di consegna più rapidi. Quello che porta via tempo è imparare l'ingegneria del software (insomma, deve essere un investimento). Quando si pensa che non vi è tempo
per svolgere un'ingegnerizzazione del software, ci si provi a chiedere: “Avremo tempo di rifarlo da
zero?”.

Pagina 19

Ingegneria del Software

Processo
Il processo software è un quadro di riferimento entro il quale si svolgono le attività necessarie alla
realizzazione di software di alta qualità.
Abbiamo definito l'ingegneria del software come processo; in realtà essa include i metodi, le tecniche e gli strumenti.
Nonostante questo, il processo rimane l'ambito chiave su cui ci si muove, infatti in esso si stabiliscono le aree chiave, il contesto in cui si applicano i metodi tecnici, si creano i prodotti intermedi
(modelli, documenti, dati, resoconti, formulari, ecc.), si stabiliscono i punti di controllo (o pietre miliari), si garantisce la qualità e si governano in modo opportuno le modifiche.
I metodi costituiscono il sapere tecnico relativo alla costruzione del software. Essi investono una vasta gamma di attività, che comprende l'analisi dei requisiti, la progettazione, la costruzione dei programmi, il collaudo ed il supporto. I metodi dell'ingegneria del software poggiano su una famiglia di
principi di base che governano ciascuna delle sue aree e comprendono le attività di modellazione ed
altre tecniche descrittive.
Gli strumenti dell'ingegneria del software forniscono al processo ed ai metodi un supporto automatizzato, in tutto od in parte.
Dando una rapida panoramica, possiamo dire che l'ingegneria del software tende a dare una risposta
a queste domande:
●

Qual'è il problema da risolvere?

●

Quali caratteristiche delle entità vengono utilizzate per risolvere il problema?

●

In che modo l'oggetto (e quindi la soluzione) sarà realizzato?

●

In che modo l'oggetto sarà costruito?

●

In che modo si condurrà la ricerca degli errori compiuti della progettazione e costruzione dell'oggetto?

●

Quale supporto si darà all'oggetto a lungo termine, quando i suoi utenti richiederanno correzioni,
adattamenti e miglioramenti?

Indipendente dall'area applicativa, dalle dimensioni del progetto e dalla sua complessità, le operazioni coinvolte nella realizzazione del software si articolano in tre fasi generali, ciascuna delle quali
è investita da una o più delle domande indicate in precedenza.
La fase di definizione si occupa del che cosa. In questa fase lo sviluppatore cerca di determinare
quali siano le informazioni da elaborare, quali siano le funzioni e prestazioni attese, quale debba essere il comportamento del sistema, quali interfacce si debbano definire, quali siano i vincoli progettuali ed i criteri di validazione in base ai quali valutare la riuscita del risultato. Si devono determinare i requisiti fondamentali del sistema e del software.
La fase di sviluppo si occupa del come. In questa fase un ingegnere del software definisce come
strutturare i dati, come implementare le funzioni entro una data architettura software, come implementare i dettagli procedurali, come strutturare le interfacce, come tradurre un progetto complessivo
in un linguaggio di programmazione e come svolgere i collaudi.

Pagina 20

Ingegneria del Software
La fase di supporto si occupa delle modifiche legate alla correzione degli errori, agli adattamenti che
si sono resi necessari per l'evoluzione dell'ambiente del software e delle modifiche tese a soddisfare
nuove esigenze della clientela. In questa fase si applicano nuovamente le attività di definizione e
sviluppo, ma nel contesto del software esistente. Si possono individuare quattro tipi di modifiche:
●

Correzioni – Anche in presenza delle migliori tecniche di controllo della qualità, è probabile che
gli utenti scoprano difetti nel prodotto software. La Manutenzione correttiva modifica il software
allo scopo di eliminare i difetti.

●

Adattamenti – Con il passare del tempo, è probabile che si evolva l'ambiente (CPU, sistema
operativo, regole aziendali, caratteristiche esterne del prodotto, ecc.) per cui il software è stato
sviluppato. La Manutenzione adattiva consiste in modifiche al software tese ad adattarlo al nuovo ambiente operativo.

●

Migliorie – Con l'utilizzazione del software, emerge l'utilità di nuove funzioni. La Manutenzione
perfettiva estende il software oltre i requisiti funzionali originari.

●

Prevenzione – Il software si deteriora a causa delle modifiche; perciò allo scopo di garantire che
il software svolga il proprio compito rispetto ai suoi utenti, si rende necessaria la Manutenzione
preventiva, detta anche software reengineering. In sostanza, la manutenzione preventiva consiste
in modifiche che rendano più semplici le correzioni, gli adattamenti e le migliorie.

Le fasi e le relative attività descritte in questa panoramica sono completate da attività ausiliarie, che
si svolgono durante tutto il processo:
●

Controllo e guida del progetto

●

Revisioni tecniche formali

●

Garanzia di qualità del software

●

Gestione delle configurazioni software

●

Preparazione e produzione di documenti

●

Gestione del riutilizzo

●

Misurazioni

●

Gestione dei rischi.

Negli ultimi anni il SEI (Software Engineering Institute) ha ideato un modello a cinque livelli che
misura l'efficacia globale dell'applicazione di tecniche di ingegneria del software da parte di un'azienda:
Livello1: Iniziale – Il processo software è definito di volta in volta ed in alcuni casi risulta confuso.
Pochi processi sono definiti e la riuscita dipende dall'impegno individuale.
Livello2: Ripetibile – Presenza di processi basilari di gestione di progetti, volti a sorvegliare costi,
tempi e funzionalità. La disciplina di processo necessaria ha lo scopo di ripetere il successo di progetti precedenti per applicazioni simili. Questo livello comprende:
●

la gestione delle configurazioni software;

●

la garanzia di qualità del software;

●

la gestione dei sottocontratti per il software;

Pagina 21

Ingegneria del Software
●

il controllo e la sorveglianza del progetto;

●

la gestione dei requisiti

Livello3: Definito – Il processo software, sia per le attività di gestione sia per quelle di realizzazione, è documentato, conforme ad uno standard ed inserito in un processo software su scala aziendale.
Ogni progetto adotta una versione documentata ed approvata del processo aziendale per lo sviluppo
e la manutenzione del software. Questo livello comprende tutte le caratteristiche definite per il Livello2. Questo livello comprende:
●

le revisioni;

●

il coordinamento dei gruppi;

●

l'ingegneria del prodotto software;

●

la gestione integrata del software;

●

i programmi di addestramento;

●

la definizione del processo aziendale;

●

l'obbiettivo primario del processo aziendale

Livello4: Gestito – Si raccolgono misure dettagliate relative al processo software ed alla qualità del
prodotto. Sia il processo software sia i prodotti sono valutati quantitativamente e controllati mediante misure dettagliate. Questo livello comprende tutte le caratteristiche definite per il Livello3. Questo livello comprende:
●

la gestione della qualità del software;

●

la gestione quantitativa del processo

Livello5: Ottimizzato – Il continuo miglioramento del processo è consentito dalla raccolta di dati
quantitativi e dal collaudo di idee e tecnologie innovative. Questo livello comprende tutte le caratteristiche definite per il Livello4. Questo livello comprende:
●

la gestione del cambiamento del processo;

●

la gestione del cambiamento tecnologico;

●

la prevenzione dei difetti

Modelli di processo
Lo sviluppo del software possiamo vederlo come un'attività divisa in quattro fasi: Status quo, Definizione del problema, Sviluppo tecnico, Integrazione della soluzione; se vediamo queste attività
come l'una il seguito dall'altra allora dall'ultima si può ritornare alla prima e ricominciare il processo. Lo status quo rappresenta lo stato delle cose presente, la definizione del problema individua lo
specifico problema da risolvere, lo sviluppo tecnico lo risolve, l'integrazione della soluzione consegna i risultati. Vedere così lo sviluppo del software è un po' semplicistico, per due motivi:
✔

Ogni fase è in realtà una macro fase, che può essere a sua volta divisa nelle stesse fasi, che a loro
volta possono essere divise, ecc.

✔

Le fasi non sono così distinte, ma è difficile separarle: infatti ogni fase ha più di un punto in comune con tutte le altre fasi.

Per questi motivi, lo sviluppo del software è considerata un'attività caotica. I modelli che qui vengono presentati cercano di porre ordine a tale caos.
Pagina 22

Ingegneria del Software

Modello sequenziale lineare

È stato il primo modello che fu costruito: esso si presenta come in figura:

In questo modello la fase di analisi precede quella di design che precede quella di scrittura del codice, che precede il collaudo. Una fase non può cominciare prima che sia finita l'altra, una volta conclusa una fase non ci si mette più mano.
I problemi si vedono subito: infatti i progetti reali seguono raramente un flusso sequenziale (i cambiamenti causano confusione), vi è difficoltà per il cliente di formulare i requisiti esplicitamente, il
cliente deve avere pazienza (e spesso non ne ha), gli sviluppatori attendono inutilmente ‘stati bloccanti’ (come abbiamo detto una fase non inizia se l’altra non è portata a termine).
Modello del Prototyping

Questo modello lo possiamo riassumere come in figura nella pagina successiva:

Pagina 23

Ingegneria del Software

Come si vede è ciclico: si parte dall’ascoltare l’utente, si prosegue costruendo un prototipo, lo si fa
testare al cliente, lo si riascolta, si modifica il prototipo, lo si fa ritestare e così via fin quando il software non è pronto.
I prototipi vengono costruiti in fretta, con scelte inadeguate, algoritmi inefficienti ed altre cose che
rendono funzionante il prototipo in tempi brevi, ma tenuto insieme “con lo scotch”. Quando si vuole
modificare, molte scelte devono essere gettate via, rielaborate, trovati algoritmi più efficienti, ecc.
I problemi che sorgono possono essere tre:
1) Il fenomeno del throw-away: si ha spesso reticenza a gettare tutto il lavoro fatto
2) Aspettative irrealistiche da parte del cliente (vedendo un prototipo, potrebbe pensare che per il
software completo manchi poco e che possa essere consegnato in tempi troppo stretti)
3) Mettendo insieme i due problemi, otteniamo spesso un prodotto il cui problema è nella manutenibilità: alla prima modifica fatta si verificano tutta una serie di side-effect che non fanno più
funzionare il programma nel modo previsto.
Modello RAD

Il Modello RAD (Rapid Application Development) è un modello che prevede di suddividere il lavoro in team paralleli, ogni team segue un processo sequenziale lineare su un periodo breve; il processo sequenziale lineare è diviso nei seguenti passi:
➢

Business modeling (quali dati guidano il processo? Chi li genera? Dove vanno? Chi li elabora?)

➢

Data modeling (attributi degli oggetti e loro relazioni)

➢

Process modeling (operazioni di aggiunta, modifica, cancellazione o recupero di oggetti)

➢

Application generation (utilizza componenti esistenti e crea componenti riutilizzabili)

Pagina 24

Ingegneria del Software
➢

Testing and turnover (collaudo dei nuovi componenti)

Il modello RAD ha i seguenti difetti:
➢

Per grandi progetti occorrono risorse sufficienti per creare le squadre

➢

Forte impegno degli sviluppatori e dei clienti

➢

Presuppone una soluzione modulare

➢

Riusabilità può implicare perdita di prestazioni

Modello Incrementale

Il modello incrementale riprende il modello sequenziale lineare e vi aggiunge la possibilità di inserire incrementi. In altre parole il prodotto non viene dato immediatamente completo di ogni funzionalità, ma, ad ogni ciclo, vengono sviluppate singole funzionalità il cui insieme corrisponderà al prodotto finale. La figura rappresenta tale modello.

Ha gli stessi difetti del modello sequenziale lineare, anche se in maniera più mitigata, grazie alla
realizzazione degli incrementi.
Modello a spirale

Il modello a spirale è rappresentato in figura

Pagina 25

Ingegneria del Software

Con questo modello si percorre una spirale dall’inizio del progetto fino alla fuoriuscita del prodotto,
ogni spira è divisa in settori: Comunicazione col cliente, Pianificazione, Analisi del Rischio, Progettazione, Costruzione e Rilascio, Valutazione da parte del cliente.
Il problema di questo modello è la difficile visualizzazione della taglia e temporizzazione di ogni
spira.
Modello a spirale WINWIN

Questo è una modifica del modello a spirale; con questo modello cambiano i settori:
✗

Identificare gli stakeholder (con questo termine si intende chiunque abbia un qualche interesse al
prodotto/processo/progetto)

✗

Identificare le condizioni di vittoria di ogni stakeholder (con questo si intende quando uno stakeholder si possa ritenere soddisfatto del prodotto/processo/progetto)

✗

Negoziazione delle condizioni di vittoria, stabilire gli obiettivi, i vincoli e le alternative

✗

Valutare il processo, le alternative e risolvere i rischi

✗

Definire il prossimo livello

✗

Validare il prodotto e la definizione di processo

✗

Commenti

Pagina 26

Ingegneria del Software
Il difetto di questo modello è che non sempre le condizioni di vittoria sono facilmente trovabili ed
ancor meno negoziabili.
Modello ad assemblaggio di componenti

Questo è una modifica al modello a spirale, introducendovi la riusabilità object oriented

I difetti sono i seguenti:
➢

Riusabilità richiede pianificazione attenta

➢

Molti programmi esistenti non sono riusabili

➢

Più adatto per domini applicativi particolari (con schemi significativi di riuso)

Modello dello sviluppo concorrente

Con questo modello si usano dei diagrammi di stato per ogni attività, ogni evento fa scattare una
transizione di stato. È un modello utile per sviluppo dell'organizzazione interna dell'azienda e quando c’è un alto grado di interdipendenza tra moduli diversi (es. applicazioni client-server)

Pagina 27

Ingegneria del Software

Altri modelli

Nel corso del tempo sono venuti a formarsi altri modelli, li presentiamo in rapida successione in
quanto o sono in corso di studio o approfondiremo più avanti:
➢

Specifiche Tecniche formali – basata sulla logica matematica

➢

Tecniche “di quarta generazione” – usando cioè linguaggi di definizione ad alto livello

➢

MDA (Model Driven Architetture) – l’idea è quella di sviluppare software indipendentemente
dalla piattaforma (PIM – Platform Indipendent Model) avendo metodi di trasformazione per portarlo sotto piattaforme specifiche (PSM – Platform Specific Model) in breve tempo e mantenendo coerenza – Tale sistema è utile per sistemi eterogenei

Pagina 28

Ingegneria del Software
➢

Agile Software Programming – basato sul concetto che grandi persone fanno grandi programmi,
per ogni pezzo di programma vi sono due responsabili (uno propositore di soluzioni, uno critico
di soluzioni, in alternanza) e che le soluzioni sono condivise da tutti i programmatori

➢

Unified Process – che vedremo approfonditamente più avanti

Progetto
Il progetto possiamo definirlo come quell'attività che, seguendo le linee guida date dal processo,
porta alla realizzazione del prodotto.
Esistono dieci punti con i quali si può capire quando un progetto è a rischio:
1. Gli sviluppatori non comprendono le esigenze dei loro clienti
2. Il campo d'azione del prodotto è mal definito
3. Le modifiche vengono gestite in modo non appropriato
4. Cambia la tecnologia scelta
5. Le operazioni devono cambiare o sono mal definite
6. Le date di consegna non sono realistiche
7. Gli utenti sono ostili
8. Perdita delle risorse finanziarie
9. Il team del progetto non contiene persone con le conoscenze appropriate
10.Il manager ed i professionisti non mettono a frutto le lezioni apprese
Come può un manager evitare i problemi appena enunciati? Si suggerisce un approccio di buon senso costituito da cinque punti:
1. Partire col piede giusto: ciò si ottiene innanzitutto lavorando duramente (molto duramente) per
comprendere il problema che deve essere risolto e poi definendo gli oggetti e le attese realistiche
per tutti coloro che saranno interessati dal progetto. Ciò deve essere ribadito realizzando il team
corretto ed assegnando al team l'autonomia, l'autorità e le tecnologie necessarie per svolgere il lavoro.
2. Mantenere alta l'attenzione: molti progetti partono bene ma poi si disintegrano lentamente. Per
mantenere alta l'attenzione, il manager del progetto deve fornire incentivi per ridurre assolutamente al minimo il ricambio di personale; il team deve concentrarsi sulla qualità in ogni operazione svolta ed il management deve fare il possibile per rispondere alle esigenze del team (burocrazia ridotta al minimo, eliminare gli incontri inutili e le richieste di aderenza dogmatica alle regole del processo, ecc.).
3. Verificare i progressi: per un progetto software, i progressi devono essere controllati a mano a
mano che viene creato un prodotto (ad esempio le specifiche, il codice sorgente, i casi di collaudo) e poi approvati (utilizzando revisioni tecniche formali) nell'ambito di un'attività di verifica
della qualità. Inoltre le misure dei processi e del progetto software possono essere raccolte ed utilizzate per stabilire i progressi rispetto alle indicazioni sviluppate dall'organizzazione di sviluppo
software.
4. Prendere decisioni intelligenti: in pratica le decisioni del project manager e del team software
devono preferire la semplicità. Quando possibile si deve decidere di utilizzare software commerciale pronto all'uso o componenti software esistenti, decidere di evitare interfacce personalizzate
Pagina 29

Ingegneria del Software
quando sono disponibili approcci standard, decidere di identificare e poi evitare i rischi più evidenti e decidere di allocare più tempo di quanto si possa pensare alle operazioni più complesse e
rischiose.
5. Condurre un'analisi post-mortem: stabilire un meccanismo generale per trarre lezioni da ogni
progetto. Valutare i tempi pianificati ed ottenuti, raccogliere ed analizzare le valutazioni metriche
del progetto software, chiedere le opinioni dei membri del team e dei clienti e trascrivere queste
informazioni.
La gestione efficace di un progetto software si fonda sulle 3P: persone, problema, processo.

Persone
Le persone sono spesso la chiave di un progetto software ed il più delle volte date un po' troppo per
scontate. Nel processo software ed in ogni progetto di sviluppo, intervengono varie persone che si
possono classificare in cinque categorie:
1. gli alti dirigenti: i quali definiscono il contesto aziendale, che spesso influenza un progetto in
modo significativo;
2. i capi progetto: incaricati di pianificare, motivare, coordinare e controllare il personale tecnico;
3. i tecnici: dotati delle competenze necessarie per la realizzazione concreta di un prodotto od
un'applicazione;
4. i clienti: che specificano i requisiti del software da realizzare ed altri punti di riferimento interni
che hanno un interesse marginale sul risultato;
5. gli utenti finali: che interagiscono col software reso operativo.
Normalmente la struttura organizzativa di un'azienda è difficile che cambi, mentre i capi progetto ed
i tecnici vengono di volta in volta assegnati a progetti diversi. È compito del capo progetto riuscire a
far divenire un gruppo di persone, quello che viene definito un “team coeso”:
✔

I membri della squadra devono fidarsi l'uno dell'altro

✔

La distribuzione delle specifiche abilità deve essere appropriata per il problema

✔

È opportuno escludere dal team gli elementi particolarmente rissosi per aumentare la coesione all'interno del team

✔

Un team coeso è un gruppo di persone unite così strettamente che l'intero è più grande della somma delle parti.

Un team che acquista coesione permette di aumentare le probabilità di successo, non occorre gestire
i suoi membri nei modi tradizionali, né motivarli. Essi hanno preso lo slancio.
Creare un team coeso, però, è più facile a dirsi che a farsi. Quello che si può provare ad evitare è un
team “tossico”:
✗

Atmosfera di lavoro frenetica in cui i membri del team perdono energie e concentrazione sugli
obbiettivi del lavoro.

✗

Un elevato livello di frustrazione causata da fattori personali, aziendali o tecnologici che provocano un attrito tra i membri.

✗

Procedure frammentate o poco coordinate od un modello di processo mal definito o mal scelto
che impedisce il raggiungimento del risultato

Pagina 30

Ingegneria del Software
✗

Una definizione non chiara dei ruoli, che provoca una mancanza di responsabilità

✗

Una continua e ripetuta serie di fallimenti che provoca pessimismo ed abbassa il morale.

Evitare un team tossico richiede di lavorare singolarmente su questi punti, evitando atmosfere frenetiche, abbassando la frustrazione, scegliendo le giuste procedure ed i modelli di processo, definendo
chiaramente ruoli e responsabilità. Per l'ultimo punto si devono stabilire tecniche specifiche per la
comunicazione e la soluzione dei problemi. Inoltre il fallimento di un membro del team deve riguardare l'intero team.
Ovviamente quando si formano i gruppi, affinché siano team, è necessario considerare anche le caratteristiche singole di ogni individuo: c'è infatti chi lavora meglio sotto stress, altri quando vi è più
tempo, altri prendono decisioni seguendo un ragionamento logico, altri l'impulso del momento, alcuni raccolgono informazioni in modo intuitivo, altri in modo più organizzato, ecc. Un capo progetto che metta insieme un team deve tener conto di tutti questi fattori.
Oltre a quanto detto bisogna stabilire il tipo di struttura del team:
➢

Democratico Decentrato (DD): Un team di questo tipo non ha un capo permanente. Di volta in
volta vengono nominati coordinatori delle attività per brevi periodi, che sono poi sostituiti da altri, incaricati di coordinare attività diverse. Le decisioni sui problemi e sulle strategie sono prese
per consenso. La comunicazione fra i membri è orizzontale. Tale struttura produce un morale ed
un grado di soddisfazione alti, si adatta meglio a sistemi con bassa modularità a causa dell'alta
quantità di comunicazioni che esige, sviluppa più difetti di altre strutture, impiega più tempo a
portare a termine un progetto, ma sono i più indicati quando si richiede un alto grado di socievolezza.

➢

Controllato Decentrato (CD): Un team di questo tipo ha un capo che coordina le attività e sottocapi responsabili delle sottoattività. Le decisioni si prendono collettivamente, ma l'implementazione delle soluzioni è distribuita fra i sottogruppi a cura del capo. La comunicazione fra sottogruppi e fra persone è orizzontale. Si ha anche una comunicazione verticale attraverso la gerarchia.Tale struttura è più adatta in caso di alta modularità e quindi relativa indipendenza fra le persone coinvolte, produce meno difetti ed in tempi più brevi rispetto ad una struttura DD, inoltre è
più adatto per progetti di grandi dimensioni.

➢

Controllato Accentrato (CA): Le decisioni ad alto livello ed il coordinamento del team sono affidati ad un capo. La comunicazione fra il capo ed i membri del team è verticale. Tale struttura è
più adatta in caso di alta modularità e quindi relativa indipendenza fra le persone coinvolte, produce meno difetti ed in tempi più brevi rispetto ad una struttura DD, inoltre è più adatto per progetti di grandi dimensioni.

Detto tutto questo, la logica conseguenza è che un buon capo progetto abbia, od acquisisca in breve
tempo, alcune caratteristiche:
✔

Motivazione: La capacità di incoraggiare (mediante spinte e controspinte) i tecnici a dare il meglio di sé

✔

Organizzazione: La capacità di plasmare i processi esistenti (o di inventarne di nuovi) così da
tradurre un'idea iniziale in un prodotto finale

✔

Idee ed innovazione: La capacità di spingere le persone a creare ed ad essere creativi anche entro i limiti stabiliti per un prodotto od un'applicazione particolare

✔

Problem Solving: Un buon capo progetto è in grado di determinare i fattori tecnici ed organizzativi più importanti, strutturare sistematicamente una soluzione, motivare opportunamente i tecniPagina 31

Ingegneria del Software
ci che devono svilupparla, applicare a nuove soluzioni le lezioni apprese nei progetti passati ed
essere abbastanza flessibile da saper mutare direzione se i primi tentativi si rivelano infruttuosi
✔

Identità manageriale: Un buon capo progetto deve assumersi la responsabilità del progetto.
Deve essere capace di tenere saldamente le redini quando è necessario e di lasciare che i tecnici
più preparati seguano il proprio istinto

✔

Incentivazione: Per accrescere la produttività di un team, il capo progetto deve ricompensare lo
spirito di iniziativa ed i risultati e deve dimostrare nei fatti di tollerare che si prendano rischi ragionevoli

✔

Influenza e spirito di gruppo: Un buon capo progetto deve “leggere” nelle persone; deve cogliere i segnali, verbali e no, e reagire alle esigenze che quei segnali suggeriscono. Deve mantenere il controllo anche in situazioni critiche.

Un altra cosa da considerare sono i metodi di comunicazione del gruppo:
●

Strategie formali, impersonali: Comprende documenti e lavorati (ad esempio codice sorgente),
note tecniche, punti di controllo del progetto, tabelle dei tempi e strumenti di controllo del progetto, richieste di cambiamenti e documenti relativi, relazioni su errori e dati d'archivio

●

Procedure formali, interpersonali: Centrata sulle attività di garanzia della qualità, applicate ai
“semilavorati” di un progetto software, fra le quali riunioni di verifica dello stato ed ispezioni del
progetto e del codice

●

Procedure informali, interpersonali: Comprende riunioni di gruppo per la diffusione di informazioni, per la risoluzione di problemi e per l'individuazione dei requisiti e la distribuzione dello
staff

●

Comunicazioni elettroniche: Comprende la posta elettronica, le banche dati elettroniche, i siti
web e, per estensione, le videoconferenze

●

Rete interpersonale: Includono discussioni informali con i membri del team e con coloro che
sono all'esterno del progetto e possono avere esperienza od un punto di vista utile per i membri
del team

Il grafico seguente mostra una ricerca fatta nel 1995 in cui fa vedere l'utilizzo delle tecniche citate
ed il loro valore percepito. Le tecniche sotto la retta sono state giudicate meno valide.

Pagina 32

Ingegneria del Software

Prodotto
Proprio all'inizio del progetto, il capo progetto si trova di fronte ad un dilemma. Egli deve definire
stime quantitative ed un piano organizzativo, ma non dispone di dati certi. Un'analisi approfondita
dei requisiti del software fornirebbe i dati necessari per le stime, ma spesso una tale analisi richiede
settimane o mesi. Peggio ancora, i requisiti sono a volte fluidi e soggetti a cambiamenti nel corso
del progetto. Tuttavia è necessario predisporre immediatamente un piano.
Di conseguenza, il prodotto ed il problema devono essere esaminati senza indugio all'inizio del progetto, determinando almeno la portata del progetto e dei suoi confini.
La portata si definisce rispondendo alle domande seguenti:


Contesto: in che modo il software in costruzione si inserirà in un sistema, prodotto o contesto
aziendale esistente e quali vincoli impone il contesto?



Obbiettivi relativi ai dati: Quali dati visibili all'utente deve produrre il software? Quali dati formano il suo input?



Funzionalità e prestazioni: Quali funzioni svolge il software per trasformare i dati di input in
quelli di output? Si devono considerare aspetti specifici legati alle prestazioni?
Pagina 33

Ingegneria del Software
La portata del software deve essere espressa con precisione ed in modo comprensibile sia a livello
manageriale sia a quello tecnico. L'enunciato della portata deve precisare dei limiti. In altre parole
devono essere indicati esplicitamente i dati quantitativi (ad esempio numero di utenti simultanei, dimensioni di una mailing list, massimo tempo di risposta accettabile); devono essere indicati i vincoli e le limitazioni (ad esempio limiti di memoria imposti dai costi); devono essere descritti i fattori
facilitanti (ad esempio il fatto che gli algoritmi necessari siano ben noti e disponibili).
Trovare tutti questi aspetti in maniera completa, richiede troppo tempo. La soluzione migliore è riuscire a scomporre il problema ed estrarre le funzioni più importanti (senza le quali il prodotto non è
quello voluto), i limiti più importanti (senza i quali il prodotto non è soddisfacente), ed i dati principali. L'obbiettivo è quello che trovato il contesto si riesca a risalire ai dati, funzionalità e prestazioni
senza le quali il prodotto non è quello aspettato. Avendo questi dati è possibile iniziare finalmente
le stime.

Processo
Formato il team e trovata la portata del progetto è giunto il momento di mettere in moto il processo
che porterà alla realizzazione del prodotto. Ma quale che sia il processo che uno voglia seguire, bisogna riuscire a pianificare le varie operazioni ed assegnare le persone.
Un utile sistema è prevedere una tabella dove nelle colonne vengono riportate le varie fasi e/o attività necessarie al processo, nelle righe le varie funzionalità del prodotto, nell'incrocio tra riga e colonna si inseriscono i vari compiti necessari. Per ogni casella sarà poi necessario assegnare le risorse,
decidere tempi di inizio e fine, ecc. Ovviamente i compiti necessari, le risorse necessarie, ecc. variano da progetto a progetto, in quanto dipendono tanto dal tipo di processo scelto, quanto dal prodotto
che si vuole realizzare.

Il principio WWWWHH
Questo principio prende il nome dalle iniziali delle 6 domande a cui un team deve saper rispondere
per vedere se il progetto è ben delineato:
✔

Perché (Who) si sviluppa il progetto? La risposta a questa domanda consente a tutte le parti di
stabilire la validità dei motivi pratici per cui il software deve funzionare. In altre parole, lo scopo
giustifica l'impegno di persone, tempo e denaro?

✔

Cosa (What) verrà eseguito ed entro quando? La risposta a queste domande aiuta il team a
stabilire i tempi del progeto identificando le operazioni principali del progetto ed i punti fermi richiesti dal cliente.

✔

Chi (Who) è il responsabile di una funzione? All'inizio si è detto che il ruolo e le
responsabilità di ciascun membro del team deve essere ben definito. La risposta a questa domanda aiuta ad ottenere ciò.

✔

Dove (Where) sono le responsabilità organizzative? Non tutti i ruoli e le responsabilità risiedono nel team software. Anche il cliente, gli utenti ed i contatti interni del cliente hanno delle responsabilità.

✔

In quale modo (How) il lavoro verrà eseguito sia tecnicamente che gestionalmente? Una volta che è stato definito il campo d'azione del prodotto, occorre definire una strategia gestionale
tecnica del progetto.

✔

In quale quantità (How much) è richiesta ogni singola risorsa? La risposta a questa domanda
deriva dalle stime di sviluppo sulla base delle risposte alle precedenti domande.

Pagina 34

PARTE TERZA

Pagina 35

Metriche

Metriche
Vi sono quattro motivi che spingono a misurare il processo ed il progetto software: caratterizzare,
valutare, prevedere, migliorare.
Si caratterizza per acquisire conoscenze sui processi, i prodotti le risorse e gli ambienti e per stabilire indicazioni di base per il confronto con i prossimi lavori.
Si valuta per determinare lo stato rispetto ai piani. Le misurazioni sono i sensori che ci fanno conoscere quando i progetti ed i processi sono fuori controllo, in modo da poter applicare misure correttive. Inoltre si valuta per stabilire il raggiungimento degli obbiettivi di qualità e per stabilire l'impatto dei miglioramenti tecnologici e di processo sui prodotti e sui processi.
Si prevede per pianificare. La misura per scopi di previsione prevede l'acquisizione di conoscenze
sulle relazioni fra processi e prodotti e la creazione di modelli per la realizzazione di tali relazioni in
modo che i valori osservati per determinati attributi possano essere utilizzati per prevederne altri. Ci
si comporta in questo modo perché si vogliono stabilire degli obbiettivi raggiungibili nell'ambito dei
costi, dei tempi e della qualità in modo da poter applicare le risorse appropriate. Le misure di previsione fungono anche da base per determinare le tendenze in modo da poter stimare i costi, i tempi e
la qualità sulla base dei valori attuali. Le proiezioni e le stime basate su dati storici aiutano anche ad
analizzare i rischi ed a seguire valutazioni sul progetto e sul costo.
Si misura per ottenere un miglioramento quando si raccolgono informazioni quantitative che aiutano ad identificare i punti critici, le inefficienze e le altre opportunità di miglioramento della qualità
del prodotto e delle prestazioni di un processo.
Anche se i termini misura, misurazione e metrica sono spesso considerati sinonimi, è importante
sottolineare le sottili differenze:
➢

Misura: fornisce una misurazione quantitativa del grado, ammontare, dimensione, capacità di un
attributo di un prodotto o di un processo. Le misure possono essere dirette (righe di codice prodotte, velocità di esecuzione, memoria occupata, difetti rilevati in un dato intervallo temporale,
ecc.) od indirette (funzionalità, qualità, complessità, efficienza, affidabilità, facilità di manutenzione, ecc.).

➢

Misurazione: l'atto di determinare la misura.

➢

Metrica: mette in relazione, secondo certi criteri, le singole misure.

➢

Indicatore: è una combinazione di metriche che mette in risalto certe caratteristiche di un processo, di un progetto o di un prodotto.

Il difetto delle metriche software è il fatto che esse non misurano qualcosa di tangibile e come tale
non c'è accordo su cosa si deve misurare, come misurarlo, quali metriche ed indicatori adottare.

Metriche di processo
Esiste un solo modo razionale di migliorare un processo: misurare gli attributi specifici, ricavarne
una famiglia di metriche significative e ricavarne degli indicatori che suggeriscano una strategia di
miglioramento. Gli indicatori di processo forniscono informazioni sull'efficacia di un processo esistente. Sulla base di tali indicatori, manager e tecnici sono in grado di stabilire che cosa funziona a
dovere e cosa no. La raccolta delle metriche di processo abbraccia tutti i progetti in un vasto arco di
tempo. Il loro obbiettivo è quello di fornire indicatori che conducano a miglioramenti a lungo termine del processo software.

Pagina 37

Metriche
L'efficacia di un processo software si misura indirettamente. A partire dalle informazioni derivate
dal processo si ricava una famiglia di metriche. Tali informazioni comprendono il numero di errori
scoperti prima della distribuzione del software, i difetti comunicati dagli utenti finali, i prodotti distribuiti, il lavoro speso, il tempo impiegato, il grado di conformità alle scadenze prefissate ed altre
misure. Le metriche di processo si ricavano anche dalla misura delle caratteristiche di specifiche
operazioni ingegneristiche. Si possono ad esempio misurare il lavoro ed il tempo spesi nelle attività
ausiliarie e nelle altre attività generiche.
Le metriche di processo possono rivelarsi significativamente benefiche per un'azienda impegnata ad
accrescere il proprio livello di maturità di processo. Tuttavia, come tutte le metriche, anche queste
sono soggette ad abusi e per questo possono creare più problemi di quanti ne risolvano. Un “galateo
delle metriche software”, utile per i manager e coloro che devono applicare le metriche di processo,
può essere il seguente:
●

Nell'interpretare le metriche utilizzare il buon senso e la sensibilità organizzativa.

●

Comunicare regolarmente i risultati agli individui ed ai team che hanno raccolto le misure e le
metriche.

●

Non servirsi delle metriche per valutare i singoli.

●

Collaborare con i tecnici ed i team per impostare obiettivi chiari e le metriche che aiutano a raggiungerli.

●

Non utilizzare mai le metriche come arma nei confronti dei singoli e dei team.

●

Non cosiderare negativi i dati che segnalano aree problematiche. Quei dati sono solo un indicatore utile a migliorare il processo.

●

Non dare troppa importanza ad una metrica specifica, a danno di altre, pure importanti.

Un indicatore di processo utile è l'analisi dei guasti, la quale si svolge nel seguente modo:
1. Gli errori ed i difetti sono classificati secondo l'origine (ad esempio nella specifica, nella logica,
nella mancanza di conformità agli standard e così via)
2. Si prende nota del costo di correzione di ogni errore o difetto.
3. Si contano errori e difetti di ogni categoria e si dispongono le categorie in ordine decrescente.
4. Si calcola il costo complessivo degli errori e dei difetti di ogni categoria.
5. Si analizzano i risultati per determinare le categorie che comportano i costi più alti.
6. Si predispone un piano di modifiche al processo tese ad eliminare la classe di errori e difetti più
costosa (od a ridurne la frequenza).
Una delle cose che può aiutare nell'analisi dei guasti è costruire un grafico che riporti la distribuzione dei difetti, dividendoli in cause ed origini.

Metriche di progetto
Le metriche di progetto si utilizzano per scopi strategici; le misure di progetto servono fini tattici. In
altre parole, le metriche di progetto e gli indicatori derivati sono sfruttati dal capo progetto e dal
team per adattare la progressione del progetto e le attività tecniche. Gli indicatori di progetto permettono al capo progetto di stimare lo stato di avanzamento di un progetto in corso, seguire i rischi
potenziali, scoprire aree problematiche prima che la situazione diventi critica, regolare il flusso del
lavoro e delle operazioni e valutare la capacità del team di controllare la qualità dei prodotti.
Pagina 38

Metriche
In genere la prima applicazione delle metriche di progetto ha luogo nella fase di stima. Le metriche
raccolte dai processi passati formano una base dalla quale ricavare stime dell'impegno e del tempo
necessari per il progetto in corso. Nel corso del progetto, le misure di impegno e tempo spesi vengono confrontati con le stime (e con la tabella dei tempi del progetto). Munito di questi dati, il capo
progetto sorveglia e pilota l'avanzamento del progetto.
Lo scopo delle metriche di progetto è duplice: anzitutto ridurre i tempi di sviluppo, suggerendo gli
aggiustamenti utili ad evitare ritardi, a mitigare problemi e rischi potenziali; in secondo luogo, stimare via via la qualità del prodotto e, se necessario, correggere l'approccio tecnico per migliorarla.

Metriche dimensionali
Le metriche dimensionali si ottengono normalizzando le misure di qualità e produttività sulla base
delle dimensioni del software prodotto. Esse si basano sul numero di linee di codice prodotto e
sono:


errori per KLOC (migliaia di linee di codice)



difetti per KLOC



costo per riga di codice



pagina di documentazione per KLOC



errori/mese-uomo



LOC per mese-uomo



costo per pagina di documentazione

Le metriche dimensionali non sono da tutti accettate in quanto esse non possono misurare:


Fattori umani (dimensione del gruppo, competenze)



Fattori problematici (complessità, cambiamento)



Fattori di processo (tecniche, strumenti)



Fattori di prodotto (affidabilità, prestazioni)



Fattori di risorse (persone, strumenti)

inoltre tutte le misure basate sulle LOC dipendono pesantemente dal linguaggio di programmazione
adottato e che il loro impiego nelle stime esige un livello di dettaglio non sempre facile da raggiungere (ad esempio, il pianificatore deve stimare il numero di LOC ben prima delle fasi di analisi e
progettazione).

Metriche basate sulle funzioni
Le metriche basate sulle funzioni adottano una misura della funzionalità fornita dall'applicazione.
Tale misura è denominata function point (o punti funzione).
Per calcolare i punti funzione si riempie la seguente tabella:

Pagina 39

Metriche

I parametri di misurazione sono i seguenti:
Numero di input utente: si conta ogni input dell'utente che fornisce al software dati applicativi distinti. Occorre distinguere gli input dalle interrogazioni, che devono essere conteggiate a parte.
Numero di output utente: si conta ogni output destinato all'utente che fornisce dati applicativi. Per
output si intendono resoconti, schermate, messaggi d'errore e così via. I singoli dati contenuti in un
resoconto non sono conteggiati separatamente.
Numero di interrogazioni utente: un'interrogazione è definita come un input in linea che suscita la
generazione di una risposta immediata del software, nella forma di output in linea. Si conta ogni interrogazione distinta.
Numero di file: Si conta ogni file logico principale (cioè un raggruppamento logico di dati che possa far parte di un database oppure un file separato).
Numero di interfacce esterne: Si contano tutte le interfacce leggibili dalla macchina (ad esempio
file di dati su supporti di memorizzazione), utilizzate per trasmettere informazioni ad un altro sistema.
Raccolti questi dati, si associa ad ogni conteggio un indice di complessità. Le aziende che si servono
dei punti funzione sviluppano criteri per determinare se una certa voce è semplice, media o complessa. In ogni caso la determinazione della complessità resta in parte soggettiva.
Per calcolare i punti funzione (FP), si usa la relazione seguente:
FP=totale×[0,650,01×∑ F i ]
“totale” è la somma delle voci ricavate dalla tabella soprastante.
Gli Fi (i=1;...;14) sono valori di aggiustamento della complessità, basati sulle risposte alle seguenti
domande:
1. Il sistema richiede salvataggi e recuperi affidabili?
2. Si richiedono comunicazioni di dati?
3. Ci sono funzioni di elaborazione distribuita?
4. Le prestazioni sono un fattore critico?
5. Il sistema funzionerà in un ambiente operativo esistente, utilizzato a fondo?
Pagina 40

Metriche
6. Il sistema richiede inserimenti di dati in linea?
7. L'inserimento di dati in linea richiede che la relativa transazione si articoli in più schermi o più
operazioni?
8. I file principali sono aggiornati in linea?
9. I dati d'ingresso o di output, i file e le interrogazioni sono complessi?
10.L'elaborazione interna è complessa?
11.Il codice è stato progettato per essere riutilizzabile?
12.La progettazione richiede anche conversione ed installazione?
13.Il sistema è stato progettato per essere installato in più organizzazioni?
14.L'applicazione è stata progettata per facilitare le modifiche e per essere di semplice uso da parte
dell'utente finale?
La risposta ad ognuna di queste domande può andare da 0 (non importante o non applicabile) a 5
(assolutamente essenziale).
Le costanti ed i pesi visti precedentemente sono determinati empiricamente.
I punti funzione così calcolati si utilizzano per delle misure di produttività e qualità:
●

errori per FP

●

difetti per FP

●

costi per FP

●

pagine di documentazione per FP

●

FP per mese-uomo

I function point permettono di confrontare lo sforzo stimato su due sistemi diversi, o per progetti nel
tempo. Tuttavia i punti funzione sono una misura astratta e relativa (non concreta o assoluta!) e
devono essere adattati per ogni organizzazione o dominio.

Feature Points
I feature points sono un adattamento dei function points, a cui viene aggiunta un altro parametro di
misurazione: gli algoritmi!
Un Algoritmo è definito come un problema computazionale delimitato, incluso per un determinato
programma per computer. L'inversione di una matrice, la decifrazione di una sequenza di bit ed il
trattamento di un interruzione sono tutti esempi di algoritmi.

Object Points
Gli object points sono una metrica basata sulle funzioni, ma, a differenza dei function points, essi si
incentrano sui tool di ausilio che permettono di creare velocemente schermate e report. I parametri
di configurazione che prende in esame sono i seguenti:
●

Schermate: Tutto ciò che deve essere visualizzato sullo schermo

●

Report: I vari report che devono essere generati

●

Componenti 3GL: Tutto ciò che deve essere costruito “a mano”
Pagina 41

Metriche
Ad ognuno di questi parametri viene associato un peso:
Object Type

Complexity-Weight
Simple Medium Difficult

Screen

1

2

3

Report

2

5

8

10
3GL Component
I valori vengono poi sommati insieme ed utilizzati per ottenere i NOP, cioè gli object points che
tengono conto anche della percentuale di oggetti riutilizzabili
NOP =OPâ‹…[

100−reuse
]
100

Dove: OP è il valore trovato dalla somma precedente, reuse è la percentuale di riutilizzo.
Trovato il NOP viene calcolato il PROD:
Developers experience and capability ICASE
Very low Low Nominal High Very high
maturity and capability
PROD
4
7
13
25
50
Attraverso il NOP ed il PROD si può calcolare lo sforzo richiesto in mesi-uomo:
sforzo=

NOP
PROD

Anche qui, come per i function points, i valori numerici sono dati attraverso dati empirici.

Modello COCOMO
Il modello COCOMO è un modello che cerca di aiutare il capo-progetto a:
a) calcolare lo sforzo in mesi-uomo previsto per un progetto, nonché la sua durata
b) seguire il progetto durante tutte le sue fasi
La formula principale è quella del calcolo per lo sforzo in mesi-uomo:
sforzo= A×size B
Dove:
âž”

A è una costante moltiplicativa usata per calcolare gli effetti moltiplicativi quando aumenta la
grandezza del progetto

âž”

size è la grandezza del progetto in migliaia di linee di codice

âž”

B è il fattore di scala che indica le economie e le diseconomie in base alla grandezza del progetto.

Size può essere calcolata anche attraverso i punti funzione tramite la seguente tabella:

Pagina 42

Metriche

Tali trasformazioni sono state realizzate attraverso diversi studi (tutt'ora in corso).
A è una costante empirica, mentre B è calcolata con la formula:
B=0,910,01×∑ W i
Dove i Wi sono dati da 5 fattori:
➢

Lavori precedenti

➢

Flessibilità di sviluppo

➢

Risoluzioni di Architettura/rischi

➢

Coesione del Team

➢

Maturità del Processo

Ognuno di questi fattori è pesato in base al loro grado di scala (Molto basso, basso, medio, alto,
molto alto, estremamente alto). Stabilire qual'è il loro grado di scala lo si fa rispondendo a delle domande, mentre a che valore corrisponde il grado di scala è un calcolo empirico.
Calcolato lo sforzo esso viene aggiustato in base ai Cost Driver che indicano quanto incidono le varie parti del progetto sullo sforzo. Questi Cost Driver sono 21 durante le fasi del progetto, ma di essi
Pagina 43

Metriche
si usano solo 7 (in realtà alcuni di questi vengono combinati) quando si ci trova all'inizio del progetto e bisogna stimare i costi.
I Cost Driver sono i seguenti:
➢

ACAP Analyst Capability

➢

AEXP Applications Experience

➢

CPLX Product Complexity

➢

DATA Database Size

➢

DOCU Documentation to match lifecycle needs

➢

FCIL Facilities

➢

LTEX Language and Tool Experience

➢

PCAP Programmer Capability

➢

PCON Personnel Continuity

➢

PDIF Platform Difficulty

➢

PERS Personnel Capability

➢

PEXP Platform Experience

➢

PREX Personnel Experience

➢

PVOL Platform Volatility

➢

RCPX Product Reliability and Complexity

➢

RELY Required Software Reliability

➢

RUSE Required Reusability

➢

SCED Required Development Schedule

➢

STOR Main Storage Constraint

➢

TIME Execution Time Constraint

➢

TOOL Use of Software Tools

La seguente tabella indica quali sono i Cost Driver usati durante le stime iniziali:

Pagina 44

Metriche

Avuti i Cost Driver, si calcola lo sforzo modificato:
sforzoModif =sforzo× ∏ EM i 
i

Dove EMi sono i Cost Driver calcolati.
Ottenuto lo sforzo così modificato, lo si può usare per calcolare il tempo:
TDEV =[3×sforzoModif

0,330,2× B−0,01

]×

SCEDPercentage
î‚Ÿ
100

Dove TDEV è il tempo, mentre SCEDPercentage è la percentuale del Cost Driver SCED.
Esistono poi delle modifiche al modello per prendere in cosiderazione anche il riuso, la conversione
e la reingegnerizzazione ed il mantenimento.

Metriche per la qualità
Lo scopo primario dell’ingegneria del software è quello di produrre sistemi, applicazioni o prodotti
di alta qualità. Per raggiungerlo, gli ingegneri del software devono applicare metodi efficaci abbinati
a strumenti moderni, nel contesto di un processo software maturo. Un buon ingegnere del software
(ed un buon manager del settore software) deve inoltre misurare se l’alta qualità sarà ottenuta.
Le misure che si possono prendere in questo frangente possono essere:
●

Correttezza: un programma che non operi correttamente è di ben poco valore per i suoi utenti.
La correttezza è il grado in cui il software svolge la funzione richiesta. La misura di correttezza
più comune è il numero di difetti per KLOC, intendendo per difetto un’accertata mancanza di
conformità ai requisiti. Quando si considera la qualità globale del prodotto software, i difetti
sono quei problemi evidenziati da un utente del programma dopo che il programma stesso è stato
rilasciato per l’utilizzo generale. Per gli scopi di definizione della qualità, i difetti vengono contati dopo un periodo di tempo standard, in genere un anno.

●

Facilità di manutenzione: la manutenzione è l’attività più costosa in termini di lavoro fra quelle
del software; è l’indice della facilità con cui un programma può essere corretto nel caso di rilevi
un errore, adattato nel caso in cui muti il suo ambiente o ritoccato nel caso in cui un utente desideri una modifica dei requisiti. Non c’è modo di misurare direttamente la facilità di manutenzione, di conseguenza si deve ricorrere a misure indirette. Una semplice metrica orientata al tempo è
il “tempo medio per la modifica” (MTTC, Mean-Time-To-Change), cioè il tempo necessario ad
Pagina 45

Metriche
analizzare la richiesta di cambiamento, progettare, implementare, collaudare e distribuire agli
utenti l’opportuna modifica. In media i programmi di facile manutenzione esibiscono un valore
inferiore di MTTC (per modifiche affini) rispetto a quelli di difficile manutenzione.
●

Integrità: questo attributo misura la capacità di un sistema di resistere ad attacchi (sia accidentali, sia intenzionali) alla sua sicurezza. Gli attacchi possono essere rivolti a tre componenti del
software: programmi, dati e documenti. Per misurare l’integrità, si devono defininire due altri attributi: la minaccia e la sicurezza. La minaccia è la probabilità (stimata o ricavata da dati empirici) che un attacco di un certo tipo avvenga in un certo dato spazio di tempo. La sicurezza è la
probabilità (parimenti stimata o ricavata da dati empirici) che l’attacco sia respinto. L’integrità di
un sistema si può allora definire così:
integrità=∑ [1−minaccia×1−sicurezza ]
dove la somma si estende a tutti i tipi di attacchi

●

Usabilità: stabilire se un prodotto è facile da usare è tra le cose più difficili da misurare; normalmente si cerca di misurare quattro caratteristiche: le competenze fische ed intellettive necessarie
per apprendere ed utilizzare il sistema; il tempo necessario ad acquisire una moderata disinvoltura nell’uso del sistema; l’incremento di produttività (rispetto alla soluzione sostituita dal
sistema), misurato quando il sistema è utilizzato in modo moderatamente efficiente; una valutazione soggettiva (talvolta ricavata da un questionario) delle reazioni degli utenti.

Efficienza di rimozione dei difetti
Una metrica della qualità utile sia a livello di processo, sia di progetto è l’efficienza di rimozione
dei difetti (DRE, Defect Removal Efficiency). In sostanza la DRE è una misura del potere filtrante
delle attività di assicurazione e controllo di qualità applicate nel corso di tutte le attività portanti del
processo.
Rispetto al processo considerato nella sua interezza, la DRE è così definita:
DRE=E/(E+D)
dove E è il numero di errori scoperti prima della consegna del software all’utente finale e D è il numero di difetti scoperti dopo la consegna.
Il valore ideale di DRE è 1, ottenuto quando il software non presenta difetti. In un caso reale il valore di D è maggiore di zero, ma quello di DRE può tendere ad 1.
All’interno del singolo progetto, la DRE può servire a valutare la capacità di scoprire errori da parte
di un team prima di passare alla successiva attività portante od al compito successivo. Per fare un
esempio, l’analisi dei requisiti produce un modello suscettibile di revisione per la ricerca e correzione degli errori. Gli errori non rilevati passano all’operazione di progettazione (nella quale possono
essere scoperti o no). In tale contesto la DRE è ridefinita come segue:
DREi = Ei / (Ei + Ei+1 )
dove Ei è il numero di errori scoperti nel corso dell’attività i, Ei+1 è il numero di errori scoperti nel
corso dell’attività i+1 riconducibili ad errori non rilevati nell’attività i
Dal punto di vista della qualità, l’obbiettivo di un team (o del singolo ingegnere del software) è
quello di avvicinarsi quanto possibile al valore 1 per DREi. In altre parole, gli errori devono essere
filtrati prima di passare all’attività successiva.

Pagina 46

Metriche

Integrazione delle metriche nel processo software
Una delle cose più difficili delle metriche è introdurle all’interno di un processo software. Come abbiamo detto ad inizio capitolo le metriche servono a caratterizzare, valutare, prevedere e migliorare.
Ma i problemi quotidiani di un progetto lasciano poco spazio a disposizione per le questioni strategiche. I capi progetto devono preoccuparsi di questioni più immediate: produrre stime significative
sul progetto, produrre sistemi di alta qualità, rispettare le scadenze.
Però, quando il progetto è completato, allo sviluppatore piacerebbe poter rispondere ad alcune domande: Quali requisiti hanno più possibilità di mutare? Quali componenti del sistema sono maggiormente soggetti ad errori? Quanti collaudi si devono pianificare per ogni modulo? Quanti errori
di ciascun tipo è ragionevole attendersi dai collaudi?
Si può dare una risposta a queste domande, a patto di aver raccolto le metriche opportune e di averle
strutturate come guida tecnica.
Occorre dunque stabilire una piattaforma per le valutazioni metriche, tenendo presente che le informazioni raccolte non devono essere necessariamente radicalmente differenti, ma le stesse valutazioni metriche possono servire per vari scopi. Inoltre affinché sia un efficace ausilio per il miglioramento dei processi e/o per la stima dei costi e degli sforzi, i dati della piattaforma devono avere i seguenti attributi: i dati devono essere ragionevolmente precisi e devono essere evitate stime vaghe sui
progetti passati; i dati devono essere raccolti per il maggior numero possibile di progetti; le misure
devono essere uniformi, ad esempio il concetto di linee di codice deve essere interpretato allo stesso
modo in tutti i progetti per i quali sono stati raccolti i dati; le applicazioni devono essere simili al lavoro che si deve stimare (ha poco senso utilizzare la piattaforma di un sistema di elaborazione batch
per stimare un’applicazione embedded in tempo reale).
I dati raccolti vengono tanto dal processo, quanto dal progetto, quanto dal prodotto; l’insieme di
questi dati ci fornisce le misure, dalle quali vengono elaborate le metriche, dalle quali vengono
estratti gli indicatori. Idealmente i dati necessari dovrebbero essere raccolti via via; purtroppo questa
situazione è rara, perciò la raccolta dei dati comporta un’indagine storica dei progetti passati e la ricostruzione dei dati rilevanti.

Introdurre le metriche
Quando si decide di iniziare le misurazioni è facile perdersi tra la mole delle cose misurabili. La regola numero uno è semplice: mantere le cose semplici. È inutile avere a che fare con moli di dati
che non si sa o non si ha tempo di elaborare. Per inserire le metriche in un processo di sviluppo, bisogna:
1) Indentificare gli obbiettivi
2) Indentificare cosa vogliamo conoscere
3) Indentificare le entità e gli attributi necessari (che cosa misurare)
4) Formalizzare gli obbiettivi delle misurazioni (come misurare)
5) Stabilire come elaborare le misure prese (cioè scegliere la metrica da seguire)
6) Stabilire gli indicatori che si vogliono prendere in considerazione
Ad esempio poniamoci un obbiettivo: ridurre il tempo di valutazione ed implementazione delle richieste di modifica. Cosa vogliamo conoscere: il tempo trascorso dalla richiesta al termine della valutazione, l’impegno per svolgere la valutazione, il tempo trascorso dalla valutazione all’assegnazione dell’ordine di modifica al personale, l’impegno necessario ad apportare la modifica, il tempo
Pagina 47



Parole chiave correlate