Sei sulla pagina 1di 356

Caso di studio Ingegneria del Software II

Anno accademico: 2000/2001

Contenuto della documentazione


Processo di miglioramento
Work Flow Diagrams pag. 4
Scenari Procedurali pag. 9
Descrizione Manufatti pag. 17

Piano esecutivo esecuzione numero 1 pag. 20


Manufatti dell'esecuzione numero 1 del processo di miglioramento pag. 23

Piano esecutivo esecuzione numero 2 pag. 108


Manufatti dell'esecuzione numero 2 del processo di miglioramento pag. 110

Piano esecutivo esecuzione numero 3 pag. 192


Manufatti dell'esecuzione numero 3 del processo di miglioramento pag. 194

Piano esecutivo esecuzione numero 4 pag. 260


Manufatti dell'esecuzione numero 4 del processo di miglioramento pag. 262

Appendice A – Processo di sviluppo software pag. 324


Riferimenti Bibliografici pag. 349
Scheda rilevazione attività pag. 350

Structure Chart del sistema Allegato

Autore caso di studio: de Felice Damiano Diego (337323 J)


Tipologia caso di studio: information hiding

Sistema Software: GEFIN D.F.


Autori originali del sistema software: Cafagna C. - de Felice D. D. – Pappagallo G.
Caso di studio Ingegneria del Software II 2
Processo di miglioramento

Caso di studio Ingegneria del Software II 3


Work Flow Diagrams
Contesto
RICHIESTE DI MIGLIORAMENTO CONOSCENZA

FOGLI METRICI

Misurare il sistema

IPOTESI DI
MISURE
VARIAZIONE DEI PIANO GQM
FOGLI METRICI

SISTEMA
SOFTWARE Caratterizzare il sistema

SISTEMA 2
SOFTWARE DA
MIGLIORARE
SISTEMA
SOFTWARE
MIGLIORATO
PUNTI DI DEBOLEZZA

DISTANZE DAGLI
OBIETTIVI

Individuare fattori di variazione e


ipotesi di miglioramento
3

IPOTESI DI MIGLIORAMENTO DEL


SISTEMA SOFTWARE

Eseguire il processo di
miglioramento
4
FORMALIZZAZIONE DEL PROCESSO DI
SVILUPPO SOFTWARE

SISTEMA SOFTWARE MODIFICATO

MIGLIORAMENTO DEL PROCESSO DI SVILUPPO


SOFTWARE

Caso di studio Ingegneria del Software II 4


1. Misurare il sistema
RICHIESTE DI MIGLIORAMENTO

Definire gli obiettivi di


misurazione e i modelli di
qualità
1.1

OBIETTIVI DI MISURAZIONE E
MODELLI DI QUALITÀ

CONOSCENZA
Definire il piano GQM

1.2
PIANO GQM DA VERIFICARE

Verificare il piano GQM

IPOTESI DI 1.3
VARIAZIONE DEI
FOGLI METRICI PIANO GQM

Produrre i fogli metrici Produrre il piano di


misurazioni
1.4 1.5

PIANO DI MISURAZIONI

Rilevare le misure

1.6
SISTEMA SOFTWARE

FOGLI METRICI
MISURE

Caso di studio Ingegneria del Software II 5


2. Caratterizzare il sistema

MISURE

Interpretare le misure

2.1

DISTANZE DAGLI OBIETTIVI


FOGLI METRICI

IPOTESI DI VARIAZIONE DEI FOGLI


METRICI
PIANO GQM
Individuare i punti di
debolezza
2.2
SISTEMA SOFTWARE SISTEMA SOFTWARE MIGLIORATO

PUNTI DI DEBOLEZZA

Caso di studio Ingegneria del Software II 6


3. Individuare fattori di variazione e ipotesi di miglioramento

PUNTI DI DEBOLEZZA

Individuare i fattori di
variazione
3.1

FATTORI DI VARIAZIONE
FOGLI METRICI

Individuare le ipotesi di
miglioramento
3.2

IPOTESI DI MIGLIORAMENTO DEL SISTEMA


SOFTWARE

Caso di studio Ingegneria del Software II 7


4. Eseguire il processo di miglioramento

IPOTESI DI MIGLIORAMENTO DEL SISTEMA


DISTANZE DAGLI OBIETTIVI SOFTWARE

Individuare gli interventi


da effettuare
4.1

SCHEDA DESCRIZIONE
DEGLI INTERVENTI

Specificare le modifiche
SISTEMA SOFTWARE
alle componenti
4.2
FORMALIZZAZIONE DEL PROCESSO DI SVILUPPO
SOFTWARE

SPECIFICHE DELLE
MODIFICHE

MIGLIORAMENTO DEL PROCESSO DI SVILUPPO


SOFTWARE

Modificare il sistema
software
4.3

SISTEMA SOFTWARE
MODIFICATO

Caso di studio Ingegneria del Software II 8


Scenari Procedurali

1 Misurare il sistema
1.1 Definire gli obiettivi di misurazione e i modelli di qualità
Obiettivo: Individuare e definire formalmente gli obiettivi della misurazione e i relativi modelli di qualità.

I.S.C.: Disponibili tutti i prodotti di input

Input: Richieste di miglioramento, Conoscenza

Procedura:

1. Per ogni richiesta di miglioramento


1.1 Identificare l'obiettivo di misurazione che è espresso informalmente nella richiesta
2. Per ogni obiettivo di misurazione individuato
2.1 Specificare l'oggetto da misurare
2.2 Specificare lo scopo della misurazione
2.3 Specificare l'obiettivo di qualità della misurazione
2.4 Specificare il punto di vista dell'obiettivo della misurazione
2.5 Specificare il contesto in cui avverrà la misurazione
2.6 Usando la conoscenza, individuare i fattori di qualità che l'oggetto da misurare deve avere per
soddisfare l'obiettivo
2.7 Per ogni fattore di qualità individuato, usando la conoscenza
2.7.1 Dare una definizione del fattore di qualità
2.7.2 Identificare le possibili metriche utili a misurare il fattore di qualità

Output: Obiettivi di misurazione e modelli di qualità

I.E.C.: Realizzati tutti i prodotti di output

1.2 Definire il piano GQM


Obiettivo: Utilizzando il metodo GQM e sulla base della conoscenza e dell'esperienza, rifinire gli obiettivi della
misurazione in domande e definire le metriche che forniscono le informazioni per rispondere a queste domande.

I.S.C.: Disponibili tutti i prodotti di input

Input: Obiettivi di misurazione e modelli di qualità, Conoscenza

Procedura:

1. Per ogni obiettivo di misurazione, usando la conoscenza


1.1 Riportare l'obiettivo di misurazione (Goal) ed etichettarlo come Gi, dove i è il numero
dell'obiettivo preso in considerazione
1.2 Sulla base dei fattori di qualità, definire un insieme di quesiti operativi (Question) dividendoli
secondo l'area di appartenenza (Caratterizzazione del prodotto, Modello primario di qualità,
Modello di conferma, Modello di validità) ed etichettarli come Qi,j, dove i è il numero del Goal cui
si riferiscono e j è un intero che indica la loro posizione lessicale
1.3 Per ogni Question individuata
1.3.1 A partire dalle metriche indicate nel modello di qualità, definire un insieme di metriche
(Metric), utilizzate per dare risposte quantitative alla question relativa scegliendole in
modo da favorire il riuso di quelle considerate per altre domande, per le quali si ha già
esperienza di utilizzo e la cui misurazione sia economica da effettuare (preferibilmente
usando tool automatici). Etichettare ogni metrica con un codice mnemonico o come
Mj,k dove j è il numero della question relativa e k è un intero che indica la posizione
lessicale della metrica.
Caso di studio Ingegneria del Software II 9
1.3.2 Se il significato del valore delle misure corrispondenti alle metriche individuate, non è
banale, dare una interpretazione di tali valori (schema di interpretazione)

Output: Piano GQM da verificare

I.E.C.: Realizzati tutti i prodotti di output

1.3 Verificare il piano GQM


Obiettivo: Verificare la correttezza e la completezza del piano GQM ed eventualmente apportare le relative correzioni.

I.S.C.: Disponibili tutti i prodotti di input

Input: Piano GQM da verificare

Procedura:

(correttezza sintattica)
1. Verificare che tutte le domande siano strutturate secondo lo schema della loro classe di appartenenza
2. Verificare che tutte le domande siano classificate per sotto obiettivi
3. Verificare che tutte le domande siano completate con le rispettive metriche

(correttezza semantica)
4. Verificare che tutte le domande siano rilevanti per gli obiettivi che dettagliano
5. Verificare la plausibilità delle relazioni tra domande ed obiettivi
6. Verificare che tutte le metriche abbiano, nel loro dominio di definizione, tutti i valori necessari per
rispondere esaurientemente alle rispettive domande
7. Verificare che tutte le metriche siano operative
8. Verificare che tutti gli schemi di interpretazione siano plausibili
9. Verificare che le modalità di rappresentazione e sintesi delle metriche favoriscano la leggibilità

Output: Piano GQM

I.E.C.: Realizzati tutti i prodotti di output

1.4 Produrre i fogli metrici


Obiettivo: Produrre, dal piano GQM e sulla base di eventuali ipotesi di variazione dei fogli metrici, i fogli metrici che
verranno poi usati per l'analisi e l'interpretazione delle misure

I.S.C.: Disponibile Piano GQM oppure disponibili Piano GQM e Ipotesi di variazione dei fogli metrici

Input: Piano GQM, Ipotesi di variazione dei fogli metrici, Conoscenza

Procedura:

1. Per ogni obiettivo di misurazione (Goal) presente nel piano GQM


1.1 Riportare nell'intestazione l'etichetta e la specifica dell'obiettivo
1.2 Riportare nel I Quadrante i fattori di qualità (espressi nelle question del piano GQM) e tutte le
metriche ad essi relative
1.3 Sulla base della conoscenza attuale dell'oggetto da misurare, specificare nel II Quadrante quali
sono gli obiettivi minimi da raggiungere (baseline hypothesis) per le metriche riportate nel I
Quadrante, utilizzando gli eventuali valori suggeriti negli schemi di interpretazione, come valori a
cui tendere per ottenere un miglior livello di qualità. Se sono disponibili le ipotesi di variazione
dei fogli metrici e al loro interno ci sono nuovi valori per le baseline hypothesis, usare questi
ultimi.
1.4 Sulla base della conoscenza, specificare nel III Quadrante i fattori che si ritiene influenzino il
modello di qualità (per ogni fattore specificare quali metriche del I Quadrante influenzano). Se
sono disponibili le ipotesi di variazione dei fogli metrici e al loro interno ci sono suggerimenti per
Caso di studio Ingegneria del Software II 10
la modifica (aggiornamento, integrazione o sostituzione) dei fattori di variazione, usare questi
suggerimenti.
1.5 Sulla base della conoscenza, descrivere nel IV Quadrante le dipendenze conosciute ed attese tra i
fattori di variazione e le metriche dei fattori di qualità. Se sono disponibili le ipotesi di variazione
dei fogli metrici e al loro interno ci sono suggerimenti per la modifica delle dipendenze tra fattori
di variazione e metriche, usare questi suggerimenti.

Output: Fogli metrici

I.E.C: Realizzati tutti i prodotti di output

1.5 Produrre il piano di misurazioni


Obiettivo: Produrre un piano di misurazioni completo per poter eseguire in seguito le misurazioni

I.S.C.: Disponibili tutti i prodotti di input

Input: Piano GQM, Conoscenza

Procedura:

1. Individuare nel piano GQM le metriche che richiedono misure dirette


2. Per ogni metrica diretta individuata, in base alla conoscenza
2.1 Definire tutti i controlli da effettuare sul valore della misura
2.2 Definire chi deve raccogliere la misura
2.3 Definire quando raccogliere la misura
2.4 Definire come e con quali strumenti deve essere raccolta la misura

Output: Piano di misurazioni

I.E.C.: Realizzati tutti i prodotti di output

1.6 Rilevare le misure


Obiettivo: Eseguire le misurazioni seguendo quanto indicato nel piano di misurazioni e calcolare le misure indirette

I.S.C.: Disponibili tutti i prodotti di input

Input: Sistema software, Piano di misurazioni, Piano GQM

Procedura:

1. Raccogliere dal sistema software tutti i valori delle metriche dirette elencate nel piano di misurazioni,
effettuando gli eventuali controlli sui valori misurati
2. Calcolare tutti i valori delle metriche indirette contenute nel piano GQM sulla base dei valori raccolti al
passo 1
3. Organizzare tutti i valori, derivati nei passi precedenti, in un report di misure, fornendo eventualmente anche
una rappresentazione grafica che aiuti a rendere più facilmente leggibili le metriche che possono avere
molti valori di misure

Output: Misure

I.E.C.: Realizzati tutti i prodotti di output

Caso di studio Ingegneria del Software II 11


2 Caratterizzare il sistema
2.1 Interpretare le misure
Obiettivo: Sottoporre ad analisi le misure rilevate al fine di interpretare la loro distanza dalle baseline hypothesis

I.S.C.: Disponibili tutti i prodotti di input

Input: Misure, Fogli metrici

Procedura:
1. Per ogni misura rilevata
1.1 Ricercare nel II Quadrante, del foglio metrico del relativo Goal, la corrispondente baseline
hypothesis
1.2 Valutare la distanza tra la misura e l'ipotesi
1.3 Indicare nelle distanze dagli obiettivi la metrica, il valore rilevato nella misura e di quanto questo
valore sia distante dalla baseline hypothesis

Output: Distanze dagli obiettivi

I.E.C.: Realizzati tutti i prodotti di output

2.2 Individuare i punti di debolezza


Obiettivo: Analizzare le distanze dagli obiettivi al fine o di individuare quali sono i punti di debolezza del sistema e/o le
ipotesi di variazione dei fogli metrici, oppure di asserire che il sistema software ha raggiunto gli obiettivi di qualità e/o
di suggerire le ipotesi di variazione dei fogli metrici

I.S.C.: Disponibili tutti i prodotti di input

Input: Distanze dagli obiettivi, Sistema software, Piano GQM, Fogli metrici

Procedura:
1. Per ogni foglio metrico
1.1 Se le distanze dagli obiettivi indicano il raggiungimento di tutti gli obiettivi delle baseline
hypothesis o di migliori e se rispondendo alle question si ritiene di aver raggiunto il goal
1.1.1 Se si ritiene che alcune baseline hypothesis possano essere avvicinate ai valori riportati
negli schemi di interpretazione del piano GQM
1.1.1.1 Suggerire tali variazioni come ipotesi di variazione dei fogli metrici in
modo da usare questi suggerimenti nella preparazione dei fogli metrici
1.1.1.2 Designare il sistema software ad una nuova misurazione, anche se migliorato
Altrimenti
1.1.1.3 Designare il sistema software ad essere consegnato all'utente
Altrimenti
1.1.2 Se per alcune metriche le distanze dagli obiettivi indicano il raggiungimento delle
baseline hypothesis o di migliori e si ritiene che tali baseline hypothesis possano essere
avvicinate ai valori riportati negli schemi di interpretazione del piano GQM o che il
raggiungimento delle baseline hypothesis non sia attualmente realizzabile e/o che i
fattori di variazione indicati non influiscono sulla qualità del prodotto e/o che l'impatto
dei fattori di variazione non è significativo
1.1.3.1 Suggerire tali variazioni come ipotesi di variazione dei fogli metrici in
modo da usare questi suggerimenti nella successiva preparazione dei fogli
metrici
1.1.4 Indicare e riportare come punti di debolezza, quei fattori di qualità (presenti nel I
Quadrante del foglio metrico considerato) che hanno almeno una metrica relativa che
ha, come valore misurato, un valore peggiore di quello indicato nelle baseline
hypothesis. Riportare anche le metriche carenti relative a ogni fattore di qualità
individuato e il riferimento al foglio metrico
1.2 Se sono state prodotte ipotesi di variazione dei fogli metrici
Caso di studio Ingegneria del Software II 12
1.2.1 Rieseguire l'attività 1.4 (Produrre i fogli metrici) che produrrà come output una nuova
versione dei fogli metrici da usare nel seguito dell'esecuzione del processo

Output: Punti di debolezza, Sistema software migliorato, Ipotesi di variazione dei fogli metrici

I.E.C.: Realizzato il prodotto Punti di debolezza, oppure realizzato il prodotto Sistema software migliorato, oppure
realizzati i prodotti Sistema software migliorato e Ipotesi di variazione dei fogli metrici, oppure realizzati i prodotti
Punti di debolezza e Ipotesi di variazione dei fogli metrici

Caso di studio Ingegneria del Software II 13


3 Individuare fattori di variazione e ipotesi di miglioramento
3.1 Individuare i fattori di variazione
Obiettivo: Con l'ausilio dei fogli metrici, individuare i fattori che hanno causato il non raggiungimento delle baseline
hypothesis da parte delle metriche dei fattori di qualità

I.S.C.: Disponibili tutti i prodotti di input

Input: Punti di debolezza, Fogli metrici

Procedura:

1. Per ogni fattore di qualità indicato come punto di debolezza


1.1 Ricercare nel III Quadrante del relativo foglio metrico, i fattori di variazione che influenzano le
metriche carenti del fattore di qualità considerato e riportarli insieme al fattore di qualità e le
metriche carenti
1.2 Indicare anche il foglio metrico di appartenenza

Output: Fattori di variazione

I.E.C.: Realizzati tutti i prodotti di output

3.2 Individuare le ipotesi di miglioramento


Obiettivo: Con l'ausilio dei fogli metrici, individuare le ipotesi per migliorare il sistema software (tramite il
miglioramento del processo usato per svilupparlo) in modo da avvicinarsi alle baseline hypothesis (ovvero migliorare la
sua qualità)

I.S.C.: Disponibili tutti i prodotti di input

Input: Fattori di variazione, Fogli metrici

Procedura:

1. Per ogni fattore di qualità riportato


1.1 Analizzando il IV Quadrante del relativo foglio metrico, sulla base delle dipendenze tra fattori di
variazione e metrica relativa al fattore di qualità, identificare e riportare in modo informale, come
ipotesi di miglioramento del sistema software, i miglioramenti del processo di sviluppo del
software e quindi del sistema

Output: Ipotesi di miglioramento del sistema software

I.E.C.: Realizzati tutti i prodotti di output

Caso di studio Ingegneria del Software II 14


4 Eseguire il processo di miglioramento

4.1 Individuare gli interventi da effettuare


Obiettivo: In base alle ipotesi di miglioramento, individuare le componenti sulle quali intervenire e la tipologia degli
interventi da effettuare

I.S.C.: Disponibili tutti i prodotti di input

Input: Distanze dagli obiettivi, Ipotesi di miglioramento del sistema software, Sistema software

Procedura:

1. Con l'ausilio delle distanze dagli obiettivi, individuare le componenti del sistema software sulle quali
intervenire
2. Per ogni componente individuata
2.1 In base alle ipotesi di miglioramento, specificare le tipologie degli interventi da eseguire sulla
componente

Output: Scheda descrizione degli interventi

I.E.C.: Realizzati tutti i prodotti di output

4.2 Specificare le modifiche alla componenti


Obiettivo: Descrivere le modifiche da effettuare mediante i piani esecutivi e le componenti interessate dalle modifiche

I.S.C.: Disponibili tutti i prodotti di input

Input: Formalizzazione del processo di sviluppo software, Scheda descrizione degli interventi, Ipotesi di miglioramento
del sistema software

Procedura:

1. Raggruppare le componenti, elencate nella scheda descrizione degli interventi, per tipologia di intervento da
effettuare
2. Per ciascuna tipologia di intervento
2.1 Individuare nella formalizzazione del processo di sviluppo software, quali sono le attività da
eseguire
2.2 Se nelle ipotesi di miglioramento sono presenti attività di base o attività elementari diverse e/o
nuove rispetto a quelle precedentemente individuate nel punto 2.1
2.2.1 Integrare le attività della formalizzazione del processo di sviluppo software con quelle
presenti nelle ipotesi di miglioramento
2.2.2 Riportare nel miglioramento del processo di sviluppo software le attività modificate al
punto 2.2.1 e le indicazioni per integrarle nella formalizzazione del processo di
sviluppo software.
2.3 Produrre un piano esecutivo accompagnato dagli scenari procedurali delle attività, dalla
descrizione dei manufatti utilizzati e dall'elenco delle componenti su cui eseguire le attività
(specifiche delle modifiche).
3. Raggruppare tutte le tipologie di interventi che sono coperte dallo stesso piano esecutivo

Output: Specifiche delle modifiche, Miglioramento del processo di sviluppo software

I.E.C.: Realizzato il prodotto specifiche delle modifiche oppure realizzati i prodotti specifiche delle modifiche e
miglioramento del processo di sviluppo software

Caso di studio Ingegneria del Software II 15


4.3 Modificare il sistema software
Obiettivo: Eseguire le modifiche sul sistema software al fine di produrre una nuova versione del sistema da sottoporre
nuovamente alle attività di rilevazione e interpretazione delle misure.

I.S.C.: Disponibili tutti i prodotti di input

Input: Specifiche delle modifiche, Sistema software

Procedura:

1. Per ogni piano esecutivo indicato nelle specifiche delle modifiche


1.1 Eseguire il piano esecutivo sulle componenti interessate come se si trattasse della realizzazione di
un nuovo sistema software partendo dal riuso del vecchio sistema software, producendo così
nuove componenti
2. Aggiornare il sistema software con le nuove componenti, producendo così il sistema software modificato

Output: Sistema software modificato

I.E.C.: Realizzati tutti i prodotti di output

Caso di studio Ingegneria del Software II 16


Descrizione dei manufatti
• Conoscenza: idee, letteratura, esperienza maturata durante la partecipazione ad altri progetti o da una esecuzione
precedente dello stesso processo qui formalizzato o derivante da una fabbrica di esperienza. Fanno parte della
conoscenza anche i piani GQM e i fogli metrici prodotti durante le precedenti esecuzioni del processo qui
formalizzato.

• Distanze dagli obiettivi: documento che contiene una lista di tutte le metriche presenti nel II Quadrante dei fogli
metrici, per ogni metrica, la misura rilevata e di quanto questa sia distante dalla baseline hypothesis (può essere
indicato un valore numerico o un commento che in ogni caso quantifichi la distanza).

• Fattori di variazione: documento che contiene la lista dei fattori di qualità carenti, le relative metriche che lo
rendono tale, tutti i fattori di variazione che hanno impatto sulle metriche riportate e il riferimento al foglio metrico
di appartenenza.

• Fogli metrici: insieme di documenti di supporto alla successiva analisi e interpretazione delle misure al fine di
individuare possibili ipotesi di miglioramento dell'oggetto sotto misurazione o del modello di qualità stesso. Un
foglio metrico è presentato possibilmente su un'unica pagina e ha la seguente struttura:

Intestazione

I Quadrante III Quadrante

II Quadrante IV Quadrante

Intestazione: contiene l'etichetta e la specifica dell'obiettivo della misurazione nei suoi 5 aspetti: Oggetto, Scopo,
Obiettivo di qualità, Punto di vista, Contesto (vedere Obiettivi di misurazione e modelli di qualità);

I Quadrante: contiene il modello di qualità, ovvero i fattori di qualità con le relative metriche utili ad eseguire la
misurazione (specificate per fattore di qualità di appartenenza);

II Quadrante: contiene gli obiettivi minimi da raggiungere per le metriche del I Quadrante (baseline hypothesis);

III Quadrante: contiene i fattori che si ritiene influenzino il modello di qualità (specificando le metriche che
influenzano);

IV Quadrante: contiene le dipendenze tra i fattori di variazione del III Quadrante e i fattori di qualità del I
Quadrante.

• Formalizzazione del processo di sviluppo software: processo di sviluppo software formalizzato usando il
linguaggio di modellazione Formal Structured Planning (FSP).

• Ipotesi di variazione dei fogli metrici: documento in cui sono riportati, in modo informale, le possibili variazioni
da apportare ai fogli metrici in termini di nuovi valori delle baseline hypothesis, modifiche dei fattori di variazione
e del loro impatto sulle baseline hypothesis (vedere Fogli metrici).

• Ipotesi di miglioramento del sistema software: documento in cui sono riportati, in modo informale, quali
possono essere gli interventi da effettuare sul sistema software al fine di migliorarlo, specificati in termini di
miglioramenti al processo di sviluppo utilizzato per produrre il sistema e al sistema.

• Miglioramento del processo di sviluppo software: documento in cui sono elencate le modifiche da riportare alla
formalizzazione del processo di sviluppo software

• Misure: insieme di schede in cui sono riportati i risultati della rilevazione delle misure. Oltre alla data di consegna
e il nome di chi ha effettuato le rilevazioni, su tali schede è presente:

Caso di studio Ingegneria del Software II 17


 l'identificatore del Goal/Question della metrica;
 il codice della metrica del piano GQM;
 il valore della metrica;
 eventuali commenti e giustificazioni del valore riportato.

Inoltre tali schede possono essere accompagnate da una rappresentazione grafica di quelle metriche che possono
avere molti valori di misure, in modo da renderle più facilmente leggibili.

• Obiettivi di misurazione e modelli di qualità: documento contenente la lista degli obiettivi della misurazione,
specificati secondo il template proposto in [BAS94] e di seguito riportato:

Analizzare prodotto o processo da misurare


scopo della misurazione (migliorare, valutare, predire,
Allo scopo di
caratterizzare, ecc…)
obiettivo di qualità della misurazione (costo,
Rispetto a
affidabilità, manutenibilità, ecc…)
punto di vista dell'obiettivo della misurazione (utente,
Dal punto di vista di
sviluppatore, management, ecc…)
contesto in cui avverrà la misurazione (nome del
Nel contesto di progetto, ecc…)

Per ogni obiettivo è anche indicato il modello di qualità, ovvero i fattori di qualità che l'oggetto da misurare deve
avere per soddisfare l'obiettivo e, per ogni fattore di qualità, le possibili metriche per misurarlo.

• Piano di misurazioni: definizione concisa del processo di raccolta delle misure. Per ogni metrica viene specificato
chi, quando, come e con quali mezzi effettuare le misure, e tutti i controlli da effettuare sui valori delle misure.

• Piano GQM: documento che descrive formalmente il raffinamento degli obiettivi della misurazione (Goal) in
domande operative (Question) e successivamente delle domande in metriche (Metric). Il piano GQM contiene
anche la descrizione di tutte le metriche dirette che devono essere raccolte per poter calcolare ogni metrica
indiretta. Dovendo servire anche come linea guida per la successiva fase di interpretazione delle misure, il piano
GQM contiene anche gli schemi per l'interpretazione del significato dei valori delle misure corrispondenti alle
metriche, quando questa operazione di interpretazione non è banale.

• Piano GQM da verificare: piano GQM (vedere definizione di Piano GQM) da sottoporre all'attività di verifica di
correttezza e completezza.

• Punti di debolezza: documento che contiene la lista di quei fattori di qualità con le relative metriche (entrambi
indicati nel I Quadrante dei fogli metrici) le cui baseline hypothesis (indicate nel II Quadrante dei fogli metrici)
differiscono dalle misure rilevate. Per ogni fattore di qualità è indicato anche il foglio metrico di appartenenza.

• Richieste di miglioramento: descrizione in qualunque forma di quello che si vuole migliorare del sistema software

• Scheda descrizione degli interventi: documento contenente una lista delle componenti del sistema software sulle
quali intervenire e tutte le tipologie di interventi da effettuare su ognuna di esse.

• Sistema software: l'insieme completo dei programmi, delle procedure e dell'associata documentazione e dei dati,
designato ad essere usato nelle attività del processo che lo richiedono come input.

Composizione: Sistema software migliorato | Sistema software modificato

• Sistema software migliorato: l'insieme completo dei programmi, delle procedure e dell'associata documentazione
e dei dati, designato ad essere consegnato all'utente in quanto si ritiene che abbia raggiunto gli obiettivi di qualità
prefissati.

• Sistema software modificato: l'insieme completo dei programmi, delle procedure e dell'associata documentazione
e dei dati, risultato dell'esecuzione del processo di miglioramento e designato ad essere nuovamente sottoposto a
misurazione.

Caso di studio Ingegneria del Software II 18


• Specifiche delle modifiche: documento contenente i piani esecutivi da utilizzare per eseguire le modifiche e, per
ognuno di essi, tutte le componenti sulle quali eseguirlo. Un piano esecutivo è rappresentato mediante diagrammi
PERT ed è accompagnato dagli scenari procedurali che descrivono le attività e dalla descrizione dei manufatti.

Caso di studio Ingegneria del Software II 19


Piano esecutivo esecuzione numero 1
del processo di miglioramento

Caso di studio Ingegneria del Software II 20


START

Definire gli obiettivi di


misurazione e i modelli di qualità
1.1

Definire il piano GQM

1.2

Verificare il piano GQM

1.3

Produrre il piano di misurazioni


1.5

Produrre i fogli metrici

1.4

Rilevare le misure

1.6

Interpretare le misure

2.1

Individuare i punti di
debolezza
2.2


Caso di studio Ingegneria del Software II 21

Individuare i fattori di
variazione
3.1

Individuare le ipotesi di
miglioramento
3.2

Individuare gli interventi da


effettuare
4.1

Specificare le modifiche alle


componenti
4.2

Modificare il sistema software


4.3

STOP

Caso di studio Ingegneria del Software II 22


Manufatti dell'esecuzione numero 1
del processo di miglioramento

Caso di studio Ingegneria del Software II 23


Indice dei manufatti usati e/o prodotti:

Conoscenza pag. 25
Distanze dagli obiettivi pag. 81
Fattori di variazione pag. 95
Fogli metrici pag. 43
Ipotesi di miglioramento del sistema software pag. 96
Miglioramento del processo di sviluppo software pag. 107
Misure pag. 47
Obiettivi di misurazione e modelli di qualità pag. 26
Piano di misurazioni pag. 35
Piano GQM pag. 31
Piano GQM da verificare pag. 27
Punti di debolezza pag. 94
Scheda descrizione degli interventi pag. 97
Specifiche delle modifiche pag. 98

NOTE:

Il manufatto Richieste di miglioramento corrisponde alla traccia d'esame.

I manufatti Sistema software e Sistema software modificato sono presenti in formato elettronico nel CD-ROM allegato.
Il Sistema software nella directory GEFIN-Originale, il Sistema software modificato nella directory GEFIN-1

Caso di studio Ingegneria del Software II 24


Conoscenza
Per l'esecuzione del processo di miglioramento del sistema software GEFIN D.F. sono disponibili:

• esperienza derivante dalla partecipazione alla produzione del sistema software stesso

• partecipazione al corso di Ingegneria del Software II, A.A. 2000/2001

• dispense, articoli e testi: [VIS99], [VIS00], [PAR83], [PAR72], [PRESM], [BAS94], [FRAN96], [VSB99]

Caso di studio Ingegneria del Software II 25


Obiettivi di misurazione e modelli di qualità
Obiettivo di misurazione 1
Analizzare: sistema software GEFIN D.F.
Allo scopo di: migliorarlo
Rispetto a: information hiding
Dal punto di vista di: ingegnere del software
Nel contesto di: corso di Ingegneria del Software II

Definizione di information hiding


Obiettivo dell'information hiding è rendere possibile il cambiamento di una componente senza dover conoscere
l'implementazione di altre componenti e senza influenzare il loro comportamento. Le strategie per raggiungere tale
obiettivo sono: nascondere in componenti specifiche i dettagli instabili, nascondere in componenti separate i dettagli
indipendenti tra loro, rendere stabili le interfacce tra le componenti. I vantaggi derivanti dall'applicazione dei principi
dell'information hiding nella progettazione di un sistema software, sono: migliore manutenibilità del sistema, maggiori
possibilità di riuso di componenti del sistema in altri progetti o nello stesso progetto, minore complessità del sistema in
termini di comprensibilità e semplicità delle componenti.

Fattori di qualità

• Modularità: indipendenza funzionale delle componenti di un sistema software. L'indipendenza funzionale si


raggiunge sviluppando moduli dedicati a una singola funzione ed evitando eccessive interazioni tra i moduli. In
altri termini, si deve progettare il software in modo che ciascun modulo si riferisca a una specifica sottofunzione
dei requisiti e che abbia un'interfaccia semplice di fronte alle altre porzioni della struttura del programma. I
vantaggi dell'indipendenza funzionale sono la maggiore facilità nello sviluppo, nella manutenzione e nel collaudo
(gli effetti secondari prodotti dalle modifiche al progetto o al codice sono limitate e la propagazione degli errori è
ridotta).

La modularità quindi può essere misurata attraverso le seguenti metriche:

ACC – Accoppiamento dei moduli del sistema, dove, per ogni modulo, il valore di ACC è calcolato come
ACC = 1 – 1 / ( DI + 2CI + DO + 2CO + GD + 2GC + FANIN + FANOUT ) e DI è il numero di parametri-
dato di input al modulo, DO è il numero di parametri-dato di output del modulo, CI è il numero di parametri di
controllo di input al modulo, CO è il numero di parametri di controllo di output del modulo, GD è il numero di
variabili globali utilizzate come dati nel modulo, GC è il numero di variabili globali utilizzate per controllo dal
modulo, FANIN è il numero di moduli che richiamano il modulo e FANOUT è il numero di moduli richiamati
dal modulo;
TM – Distribuzione della tipologia dei moduli tra i moduli del sistema;
MNS – Numero di moduli che nascondono un segreto;
MDS – Numero di moduli che conoscono la struttura di un dato;
MTS – Numero di moduli che conoscono la struttura di una tavola della base di dati;
SN – Numero di segreti nascosti per modulo;
PT5NF – Normalizzazione della base di dati, dove PT5NF = NT5NF / NT e NT5NF è il numero di tavole in
quinta forma normale presenti nel database, NT è il numero di tavole presenti nel database

• Riusabilità: il grado in cui un sistema, o alcune sue parti, può essere utilizzato nuovamente in altri sistemi
(riusabilità esterna) e il grado in cui alcune parti del sistema possono essere utilizzate più volte all'interno del
sistema stesso (riusabilità interna). La riusabilità è correlata al modo in cui il sistema è strutturato e alla portata
delle funzioni svolte dal sistema: infatti moduli che nascondono un solo segreto e che svolgono un'unica funzione
hanno alta probabilità di poter essere riusati in altri sistemi o, nello stesso sistema, da tutti quei moduli che hanno
bisogno di utilizzare la funzione suddetta.

La riusabilità quindi può essere misurata attraverso le seguenti metriche:

SN – Numero di segreti nascosti per modulo;


FANIN – Numero di moduli che usano un modulo.

Caso di studio Ingegneria del Software II 26


Piano GQM da verificare

INDICE DEI GOAL:


Goal G1 pag. 28

NOTE:

Il piano GQM qui di seguito riportato NON è la versione definitiva, ma una versione da sottoporre all'attività di verifica
(attività 1.3). Per la versione definitiva usata nel seguito del processo vedere il documento Piano GQM a pagina 31.

Caso di studio Ingegneria del Software II 27


G1
Analizzare: sistema software GEFIN D.F.
Allo scopo di: migliorarlo
Rispetto a: information hiding
Dal punto di vista di: ingegnere del software
Nel contesto di: corso di Ingegneria del Software II

Caratterizzazione del prodotto


Q1,1 Qual è la morfologia della structure chart ?

M lista dei moduli presenti nella structure chart


NMOD numero di moduli presenti nella structure chart

Q1,2 Come sono distribuiti i segreti nella structure chart ?

S lista dei segreti nascosti nel sistema


MxS per ogni modulo, il o i segreti che nasconde (tabella cross-reference)

Q1,3 Come è ripartita la structure chart ?

T lista delle tipologie (funzioni principali del sistema) dei moduli


MxT per ogni modulo, a quale o a quali tipologie appartiene (tabella cross-reference)

Q1,4 Come è distribuita la conoscenza dei dati nella structure chart ?

SD lista delle strutture dati usate dal sistema


SDxM per ogni struttura dato, il o i moduli che la conoscono (tabella cross-reference)

TAV lista delle tavole presenti nel database usato dal sistema
MxTAV per ogni modulo, la o le tavole di cui il modulo conosce la struttura (tabella cross-reference)

Modello primario di qualità


Q1,5 Il sistema presenta un'effettiva modularità ?

DI per ogni modulo, il numero di parametri-dato di input al modulo


DO per ogni modulo, il numero di parametri-dato di output del modulo
CI per ogni modulo, il numero di parametri di controllo di input al modulo
CO per ogni modulo, il numero di parametri di controllo di output del modulo
GD per ogni modulo, il numero di variabili globali utilizzate come dati nel modulo
GC per ogni modulo, il numero di variabili globali utilizzate per controllo dal modulo
FANIN per ogni modulo, il numero di moduli che richiamano il modulo
FANOUT per ogni modulo, il numero di moduli richiamati dal modulo
ACC = 1 – 1 / (DI + 2CI + DO + 2CO + GD + 2GC + FANIN + FANOUT) (per ogni modulo)

Interpretazione: il valore di ACC è compreso tra 0 e 1. Il valore 0 corrisponde a basso accoppiamento, mentre il
valore 1 corrisponde ad alto accoppiamento. Per ogni modulo, il valore ACC deve essere il più vicino possibile a
0 e comunque non deve salire al di sopra di 0.860. Valori vicini a 0 indicano un alto grado di indipendenza del
modulo dagli altri e quindi che l'impatto di una modifica sul modulo sia localizzata e interessi un numero molto
basso, se non nullo, di moduli. Il valore di GD e GC deve essere pari a 0 per tutti i moduli, in caso contrario
l'impatto di una modifica su un modulo che usa una variabile globale potrebbe estendersi agli altri moduli che
usano la stessa variabile globale. Il valore di CO deve essere 0 per tutti i moduli per evitare che decisioni prese in
un modulo interessino moduli che non appartengono alla sua portata del controllo. Il valore di CI deve essere il
più vicino possibile a 0 in quanto la non perfetta conoscenza del suo significato può rendere ogni intervento di

Caso di studio Ingegneria del Software II 28


manutenzione difficile da eseguire e incline all'introduzione di difetti; comunque la circolazione dei dati di
controllo deve limitarsi a un solo livello della structure chart per limitare la portata dell'effetto di una decisione.

TM per ogni modulo, il numero di tipologie a cui appartiene

Interpretazione: il valore di TM deve essere pari a 1 per ogni modulo. Un valore maggiore di 1 indica che il
modulo svolge più funzioni principali del sistema e questo implica difficoltà nel collaudo, manutenzione ed
estensione del sistema, oltre che una difficoltà nel capire la responsabilità del modulo e le funzioni da esso svolte.

MNS per ogni segreto, il numero di moduli che conoscono questo segreto

Interpretazione: per ogni segreto, il valore di MNS non deve superare il valore 5 e comunque deve essere un
valore vicino a 3. In caso contrario l'impatto della modifica di un dettaglio (segreto) si estenderebbe a tutti i
moduli che conoscono lo stesso dettaglio (segreto). Valori bassi di MNS indicano quindi una maggiore
localizzazione degli interventi di manutenzione.

MDS per ogni struttura dati, il numero di moduli che conoscono questa struttura

Interpretazione: per ogni struttura dati, il valore di MDS non deve superare il valore 4 e comunque deve essere il
più vicino possibile a 3.

MTS per ogni tavola del database, il numero di moduli che conoscono la sua struttura

Interpretazione: per ogni tavola, il valore di MTS deve essere non superiore a 1. In caso contrario una modifica
alla struttura della tavola avrebbe impatto su tutti i moduli che la conoscono.

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore ad 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

NT5NF numero di tavole in quinta forma normale (5NF) presenti nel database
NT numero di tavole presenti nel database
PT5NF = NT5NF / NT

Interpretazione: il valore di PT5NF deve essere uguale a 1, in caso contrario è possibile che più moduli che
svolgono funzioni diverse accedano alla stessa tavola e quindi questa tavola aumenti l'accoppiamento dei moduli
suddetti, oppure che un modulo effettui più funzioni diverse sulla stessa tavola, diminuendo così l'indipendenza
funzionale.

Q1,6 I moduli hanno una buona riusabilità ?

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore ad 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

FANIN per ogni modulo, il numero di moduli che lo richiamano

Interpretazione: il valore di FANIN indica il grado di riusabilità interna al sistema del modulo: a un valore alto di
FANIN corrisponde un modulo che svolge una precisa funzione richiesta da altri moduli, quindi si tratta di un

Caso di studio Ingegneria del Software II 29


modulo di servizio. Inoltre moduli con alto FANIN presenti a un livello inferiore della structure chart, con molta
probabilità presentano anche riusabilità esterna.

Modello di conferma
Q1,7 Qual è l'impatto delle modifiche ?

MxMMODRIUS scheda dei moduli del vecchio sistema, modificati e riusati per il nuovo sistema
(tabella cross-reference)
NMRIUS numero di moduli del vecchio sistema modificati per il nuovo
NMMOD numero di moduli del vecchio sistema riusati nel nuovo
PERMMOD = NMMOD / NMOD
PERMRIUS = NMRIUS / NMOD

Interpretazione: i valori di PERMMOD e PERMRIUS sono compresi tra 0 e 1. Il valore di PERMMOD deve
essere il più vicino possibile a 0, non deve superare il valore 0.05 per garantire una struttura che localizza le
informazioni. Il valore di PERMRIUS deve essere il più vicino possibile a 1, non deve essere inferiore al valore
0.95 per garantire che il sistema sia stato modificato riusando la maggior parte delle componenti della versione
precedente

Caso di studio Ingegneria del Software II 30


Piano GQM

INDICE DEI GOAL:


Goal G1 pag. 32

CORREZIONI APPORTATE:

• riveduta l'interpretazione della metrica PT5NF

• completata l'interpretazione della metrica MDS

• completata l'interpretazione della metrica ACC

NOTE:

Il piano GQM qui di seguito riportato è la versione definitiva usata nel seguito del processo.

Caso di studio Ingegneria del Software II 31


G1
Analizzare: sistema software GEFIN D.F.
Allo scopo di: migliorarlo
Rispetto a: information hiding
Dal punto di vista di: ingegnere del software
Nel contesto di: corso di Ingegneria del Software II

Caratterizzazione del prodotto


Q1,1 Qual è la morfologia della structure chart ?

M lista dei moduli presenti nella structure chart


NMOD numero di moduli presenti nella structure chart

Q1,2 Come sono distribuiti i segreti nella structure chart ?

S lista dei segreti nascosti nel sistema


MxS per ogni modulo, il o i segreti che nasconde (tabella cross-reference)

Q1,3 Come è ripartita la structure chart ?

T lista delle tipologie (funzioni principali del sistema) dei moduli


MxT per ogni modulo, a quale o a quali tipologie appartiene (tabella cross-reference)

Q1,4 Come è distribuita la conoscenza dei dati nella structure chart ?

SD lista delle strutture dati usate dal sistema


SDxM per ogni struttura dato, il o i moduli che la conoscono (tabella cross-reference)

TAV lista delle tavole presenti nel database usato dal sistema
MxTAV per ogni modulo, la o le tavole di cui il modulo conosce la struttura (tabella cross-reference)

Modello primario di qualità


Q1,5 Il sistema presenta un'effettiva modularità ?

DI per ogni modulo, il numero di parametri-dato di input al modulo


DO per ogni modulo, il numero di parametri-dato di output del modulo
CI per ogni modulo, il numero di parametri di controllo di input al modulo
CO per ogni modulo, il numero di parametri di controllo di output del modulo
GD per ogni modulo, il numero di variabili globali utilizzate come dati nel modulo
GC per ogni modulo, il numero di variabili globali utilizzate per controllo dal modulo
FANIN per ogni modulo, il numero di moduli che richiamano il modulo
FANOUT per ogni modulo, il numero di moduli richiamati dal modulo
ACC = 1 – 1 / (DI + 2CI + DO + 2CO + GD + 2GC + FANIN + FANOUT) (per ogni modulo)

Interpretazione: il valore di ACC è compreso tra 0 e 1. Il valore 0 corrisponde a basso accoppiamento, mentre il
valore 1 corrisponde ad alto accoppiamento. Per ogni modulo, il valore ACC deve essere il più vicino possibile a
0 e comunque non deve salire al di sopra di 0.860 (fanno eccezione i moduli di servizio per i quali FANIN
elevato aumenta ACC ma non è indice di cattiva modularità, e i moduli di controllo per i quali è normale un
valore elevato di FANOUT). Valori vicini a 0 indicano un alto grado di indipendenza del modulo dagli altri e
quindi che l'impatto di una modifica sul modulo sia localizzata e interessi un numero molto basso, se non nullo,
di moduli. Il valore di GD e GC deve essere pari a 0 per tutti i moduli, in caso contrario l'impatto di una modifica
su un modulo che usa una variabile globale potrebbe estendersi agli altri moduli che usano la stessa variabile
globale. Il valore di CO deve essere 0 per tutti i moduli per evitare che decisioni prese in un modulo interessino
moduli che non appartengono alla sua portata del controllo. Il valore di CI deve essere il più vicino possibile a 0

Caso di studio Ingegneria del Software II 32


in quanto la non perfetta conoscenza del suo significato può rendere ogni intervento di manutenzione difficile da
eseguire e incline all'introduzione di difetti; comunque la circolazione dei dati di controllo deve limitarsi a un
solo livello della structure chart per limitare la portata dell'effetto di una decisione.

TM per ogni modulo, il numero di tipologie a cui appartiene

Interpretazione: il valore di TM deve essere pari a 1 per ogni modulo. Un valore maggiore di 1 indica che il
modulo svolge più funzioni principali del sistema e questo implica difficoltà nel collaudo, manutenzione ed
estensione del sistema, oltre che una difficoltà nel capire la responsabilità del modulo e le funzioni da esso svolte.

MNS per ogni segreto, il numero di moduli che conoscono questo segreto

Interpretazione: per ogni segreto, il valore di MNS non deve superare il valore 5 e comunque deve essere un
valore vicino a 3. In caso contrario l'impatto della modifica di un dettaglio (segreto) si estenderebbe a tutti i
moduli che conoscono lo stesso dettaglio (segreto). Valori bassi di MNS indicano quindi una maggiore
localizzazione degli interventi di manutenzione.

MDS per ogni struttura dati, il numero di moduli che conoscono questa struttura

Interpretazione: per ogni struttura dati, il valore di MDS non deve superare il valore 4 e comunque deve essere il
più vicino possibile a 3. Per moduli che conoscono una struttura dati, si intendono quei moduli che usano dati
contenuti in essa per eseguire una elaborazione (non vanno considerati i moduli che scrivono dati nella struttura);
quindi un alto valore di MDS implica che una modifica alla struttura dati si estenderebbe a tutti i moduli che
usano i dati in essa contenuta per eseguire un'elaborazione.

MTS per ogni tavola del database, il numero di moduli che conoscono la sua struttura

Interpretazione: per ogni tavola, il valore di MTS deve essere non superiore a 1. In caso contrario una modifica
alla struttura della tavola avrebbe impatto su tutti i moduli che la conoscono.

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere pari ad 1 per tutti i moduli. Un valore maggiore di 1 indica una bassa
indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la manutenibilità
del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

NT5NF numero di tavole in quinta forma normale (5NF) presenti nel database
NT numero di tavole presenti nel database
PT5NF = NT5NF / NT

Interpretazione: il valore di PT5NF è compreso tra 0 e 1. Il valore di PT5NF deve essere uguale a 1, in caso
contrario è possibile che più moduli che svolgono funzioni diverse accedano alla stessa tavola e quindi questa
tavola aumenti l'accoppiamento dei moduli suddetti, oppure che un modulo effettui più funzioni diverse sulla
stessa tavola, diminuendo così l'indipendenza funzionale.

Q1,6 I moduli hanno una buona riusabilità ?

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere pari ad 1 per tutti i moduli. Un valore maggiore di 1 indica una bassa
indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la manutenibilità
del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

Caso di studio Ingegneria del Software II 33


FANIN per ogni modulo, il numero di moduli che lo richiamano

Interpretazione: il valore di FANIN indica il grado di riusabilità interna al sistema del modulo: a un valore alto di
FANIN corrisponde un modulo che svolge una precisa funzione richiesta da altri moduli, quindi si tratta di un
modulo di servizio. Inoltre moduli con alto FANIN presenti a un livello inferiore della structure chart, con molta
probabilità presentano anche riusabilità esterna.

Modello di conferma
Q1,7 Qual è l'impatto delle modifiche ?

MxMMODRIUS scheda dei moduli del vecchio sistema, modificati e riusati per il nuovo sistema
(tabella cross-reference)
NMRIUS numero di moduli del vecchio sistema modificati per il nuovo
NMMOD numero di moduli del vecchio sistema riusati nel nuovo
PERMMOD = NMMOD / NMOD
PERMRIUS = NMRIUS / NMOD

Interpretazione: i valori di PERMMOD e PERMRIUS sono compresi tra 0 e 1. Il valore di PERMMOD deve
essere il più vicino possibile a 0, non deve superare il valore 0.05 per garantire una struttura che localizza le
informazioni. Il valore di PERMRIUS deve essere il più vicino possibile a 1, non deve essere inferiore al valore
0.95 per garantire che il sistema sia stato modificato riusando la maggior parte delle componenti della versione
precedente

Caso di studio Ingegneria del Software II 34


Piano di misurazioni

INDICE DELLE METRICHE:


CI pag. 38
CO pag. 38
DI pag. 38
DO pag. 38
FANIN pag. 39
FANOUT pag. 39
GC pag. 39
GD pag. 38
M pag. 36
MDS pag. 40
MNS pag. 39
MTS pag. 40
MxMMODRIUS pag. 41
MxS pag. 36
MxT pag. 37
MxTAV pag. 37
NMMOD pag. 41
NMOD pag. 36
NMRIUS pag. 41
NT pag. 40
NT5NF pag. 40
S pag. 36
SD pag. 37
SDxM pag. 37
SN pag. 40
T pag. 36
TAV pag. 37
TM pag. 39

Caso di studio Ingegneria del Software II 35


M
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• raccogliere e riportare i nomi di tutti i moduli distinti presenti in essa.
Controlli da effettuare nessuno

NMOD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• contare il numero di moduli distinti presenti in essa
Controlli da effettuare nessuno

S
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• individuare e riportare i segreti (dettagli) distribuiti tra i moduli presenti in essa
Controlli da effettuare nessuno

MxS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed S
• considerare i valori rilevati con le metriche M ed S e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e i segreti elencati in
Come misurare
S
• usando la structure chart, per ogni modulo nella tabella, contrassegnare con una
"x" le caselle in corrispondenza dei segreti che nasconde
Controlli da effettuare  ogni segreto nella tabella deve essere nascosto in almeno un modulo

T
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
documenti di progetto
Come misurare
• individuare e riportare le tipologie di moduli presenti nella structure chart (moduli
efferenti, afferenti, di controllo, ecc…)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 36


MxT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e T
• considerare i valori rilevati con le metriche M e T e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tipologie
Come misurare
elencate in T
• usando la structure chart, per ogni modulo nella tabella contrassegnare con una "x"
le caselle in corrispondenza alla tipologia a cui appartiene
 ogni modulo nella tabella deve appartenere ad almeno una tipologia
Controlli da effettuare
 ogni tipologia nella tabella deve contenere almeno un modulo

SD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare il dizionario dei dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le strutture di dati distinte presenti in esso
Controlli da effettuare nessuno

SDxM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed SD
• considerare i valori rilevati con le metriche M ed SD e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le strutture dati
elencate in SD
Come misurare
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle strutture dati di cui conosce la struttura (per individuarle,
usare la specifica del modulo e verificare se il modulo usa dati in essa contenuti
per eseguire un'elaborazione)
Controlli da effettuare  ogni struttura dati nella tabella deve essere usata in almeno un modulo

TAV
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le tavole presenti in esso
Controlli da effettuare nessuno

MxTAV
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e TAV
• considerare i valori rilevati con le metriche M e TAV e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tavole elencate
Come misurare in TAV
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle tavole di cui conosce la struttura (per individuarle, usare la
specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 37


DI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato da elaborare"
Controlli da effettuare nessuno

DO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato da elaborare"
Controlli da effettuare nessuno

CI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato di controllo"
Controlli da effettuare nessuno

CO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato di controllo"
Controlli da effettuare nessuno

GD
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato da elaborare (usare la specifica del modulo)
Controlli da effettuare nessuno
GC

Caso di studio Ingegneria del Software II 38


Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato di controllo (usare la specifica del modulo)
Controlli da effettuare nessuno

FANIN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nelle specifiche dei moduli) che richiamano il modulo suddetto
 il valore di FANIN deve essere maggiore o uguale a 1, tranne per il modulo di
Controlli da effettuare
livello 1 della structure chart

FANOUT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nella specifica del modulo) richiamati dal modulo suddetto
Controlli da effettuare nessuno

TM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxT
• per ogni modulo elencato nella tabella MxT, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di TM deve essere maggiore o uguale a 1

MNS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni segreto elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MNS deve essere maggiore o uguale a 1

Caso di studio Ingegneria del Software II 39


MDS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica SDxM
• per ogni struttura dati elencata nella tabella SDxM, contare il numero di caselle, ad
Come misurare
essa relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MDS deve essere maggiore o uguale a 1

MTS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxTAV
• per ogni tavola elencata nella tabella MxTAV, contare il numero di caselle, ad essa
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

SN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni modulo elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

NT5NF
Chi deve misurare ingegnere del software
Quando misurare durante l'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare • contare il numero di tabelle in quinta forma normale contenute nello schema della
base di dati
Controlli da effettuare nessuno

NT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica TAV
Come misurare • contare il numero di tabelle elencate in TAV
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 40


MxMMODRIUS
Chi deve misurare ingegnere del software
Quando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)
• riportare in una tabella cross-reference i moduli elencati nella metrica M e i due
tipi "modificato" e "riusato"
• considerare i valori rilevati con la metrica M e la scheda descrizione degli
interventi prodotta nell'attività di specifica delle modifiche alle componenti
(attività 4.2)
Come misurare • per ogni modulo nella tabella, considerare la scheda degli interventi e
contrassegnare con una "x" la casella corrispondente a "modificato" se il modulo è
stato sottoposto a modifiche (anche eliminato, diviso o fuso con altri moduli)
• per ogni modulo della tabella, considerare la structure chart (o anche la call graph)
della nuova versione del sistema e contrassegnare con una "x" la casella
corrispondente a "riusato" se il modulo è presente nella structure chart
Controlli da effettuare nessuno

NMRIUS
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "riusato"
Controlli da effettuare nessuno

NMMOD
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "modificato"
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 41


Caso di studio Ingegneria del Software II 42
Fogli metrici

Indice dei fogli metrici


Goal G1 pag. 44

Caso di studio Ingegneria del Software II 43


OGGETTO SCOPO OBIETTIVO DI QUALITÀ PUNTO DI VISTA CONTESTO
G1 sistema software GEFIN D.F. migliorare information hiding ingegnere del software corso di Ingegneria del
Software II
QUALITY FOCUS FATTORI DI VARIAZIONE
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) Metriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC
accoppiamento di un modulo
DI numero di parametri-dato di input al modulo • esperienza del team di progetto nella progettazione delle interfacce tra le singole
DO numero di parametri-dato di output del modulo componenti del sistema
CI numero di parametri di controllo di input al modulo Metriche influenzate: MDS, ACC, GD, GC
CO numero di parametri di controllo di output del modulo
GD numero di variabili globali utilizzate come dati nel modulo • esperienza del team di progetto nella progettazione delle basi di dati
GC numero di variabili globali utilizzate per controllo dal modulo Metriche influenzate: PT5NF
FANIN numero di moduli che richiamano il modulo
FANOUT numero di moduli richiamati dal modulo

TM: distribuzione della tipologia dei moduli tra i moduli del sistema

MNS: numero di moduli che nascondono un segreto

MDS: numero di moduli che conoscono la struttura di un dato

MTS: numero di moduli che conoscono la struttura di una tavola

SN: numero di segreti nascosti per modulo

PT5NF = NT5NF / NT : normalizzazione della base di dati


NT5NF: numero di tavole in 5NF presenti nel database
NT: numero di tavole presenti nel database

- Riusabilità:

SN: numero di segreti nascosti per modulo

FANIN: numero di moduli che usano un modulo

Caso di studio Ingegneria del Software II 44


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di
controllo per i quali valori vicini a 1 sono accettabili;  la maggiore esperienza nel ripartire la struttura del sistema secondo le funzioni
principali svolte, comporta una migliore distribuzione della tipologia dei moduli (basso
valore di TM); in particolare, delegando l'accesso ai dati a una sola tipologia di moduli
CI: massimo 1 per il 5% dei moduli del sistema
si riduce al minimo il numero di moduli che conoscono le singole componenti della
pari a 0 per il restante 95%; base di dati (MTS)
CO: pari a 0 per tutti i moduli del sistema;
GD: pari a 0 per tutti i moduli del sistema;  la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate
GC: pari a 0 per tutti i moduli del sistema; comporta un basso numero di segreti nascosti dallo stesso modulo (SN) oltre che
l'abbassamento del numero di moduli che conoscono lo stesso segreto (MNS)
TM: pari a 1 per tutti i moduli del sistema;
 la maggiore esperienza nel progettare moduli che implementano una singola funzione
MNS: massimo 4 per tutti i segreti; comporta la diminuzione dell'interconnessione tra i moduli, e quindi
dell'accoppiamento (ACC), in particolare diminuisce la necessità dell'uso di dati di
controllo (CO, CI e GC)
MDS: massimo 5 per tutte le strutture dati escluse quelle che fanno parte
dell'interfaccia delle componenti riusabili del sistema;
 la maggiore esperienza nell'identificare nei moduli del sistema funzioni ricorrenti più
volte, nell'estrarre queste funzioni e nell'inserire ognuna di esse in singoli moduli,
MTS: pari a 1 per tutte le tavole del sistema; comporta l'aumento del fan-in di questi moduli (FANIN)

SN: massimo 1 per tutti i moduli del sistema; • esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti
del sistema
PT5NF: pari a 1;
 la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di
- Riusabilità: controllo (mediante chiamata/sincronizzazione) o allo scambio (in input/output) dei soli
dati necessari, comporta la diminuzione dell'accoppiamento dei moduli (ACC). Inoltre
SN: pari a 1 per tutti i moduli del sistema; se i dati scambiati sono dati elementari e non strutture dati, si ottiene la diminuzione del
numero di moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi
moduli
FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili
esternamente; compreso tra il 5% e il 30% dei moduli del sistema  la maggiore esperienza nel limitare la possibilità di scambio di dati tra i moduli al solo
per i moduli riusabili internamente; minore del 5% dei moduli del uso della loro interfaccia, comporta la diminuzione della necessità di usare variabili
sistema per i moduli generici globali (GD e GC) e quindi la diminuzione dell'accoppiamento dei moduli (ACC)

• esperienza del team di progetto nella progettazione delle basi di dati

 la maggiore esperienza nel metodo della decomposizione senza perdita o nell'uso del
data modelling comporta una migliore normalizzazione della base di dati (PT5NF)

Caso di studio Ingegneria del Software II 45


Misure

INDICE DELLE METRICHE:


ACC pag. 67
CI pag. 61
CO pag. 62
DI pag. 59
DO pag. 60
FANIN pag. 65
FANOUT pag. 66
GC pag. 64
GD pag. 63
M pag. 48
MDS pag. 71
MNS pag. 70
MTS pag. 72
MxS pag. 54
MxT pag. 56
MxTAV pag. 58
NMOD pag. 49
NT pag. 74
NT5NF pag. 73
PT5NF pag. 75
S pag. 53
SD pag. 52
SDxM pag. 57
SN pag. 69
T pag. 50
TAV pag. 51
TM pag. 68

INDICE DELLE METRICHE DEL MODELLO DI CONFERMA:

MxMMODRIUS pag. 76
NMMOD pag. 77
NMRIUS pag. 78
PERMMOD pag. 79
PERMRIUS pag. 80

NOTE:
Le rilevazioni delle misure per le metriche relative al modello di conferma del piano GQM sono state rilevate al termine
dell'esecuzione degli interventi sul sistema (come si può notare dalle date di consegna delle schede).

CONSIDERAZIONI SUL MODELLO DI CONFERMA:

Dall'analisi dei valori di PERMMOD e PERMRIUS si possono trarre le seguenti conclusioni:

• il valore di PERMRIUS pari a 0.98 e quindi molto vicino a 1 e comunque superiore a 0.95 dimostra che il fattore di
qualità riusabilità non sia un punto di debolezza per il sistema;

• il valore di PERMMOD pari a 0.26 e quindi superiore a 0.05 dimostra che il fattore di qualità modularità sia un
punto di debolezza per il sistema. Il valore elevato comunque è giustificato in parte dal fatto che sul sistema sono
stati apportati molti interventi di manutenzione.

Caso di studio Ingegneria del Software II 46


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: M
VALORE RILEVATO:

CODICE MODULO
M1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa
M2 Calcolare Disponibilità di Cassa Non Impegnata
M3 Calcolare Prenotazione Non Impegnata
M4 Calcolare Situazione Eco./Fin.
M5 Consolidare Automaticamente
M6 Consolidare Entrate
M7 Consolidare Manualmente Finanziamento
M8 Consolidare Manualmente Prenotazione
M9 Controllare Consistenza Cancellazione Entrata
M10 Controllare Consistenza Cancellazione Finanziamento
M11 Controllare Consistenza Cancellazione Impegno
M12 Controllare Consistenza Cancellazione Prenotazione
M13 Controllare Consistenza Creazione Entrata
M14 Controllare Consistenza Creazione Finanziamento
M15 Controllare Consistenza Creazione Impegno
M16 Controllare Consistenza Creazione Prenotazione
M17 Controllare Consistenza Modifica Entrata
M18 Controllare Consistenza Modifica Finanziamento
M19 Controllare Consistenza Modifica Impegno
M20 Controllare Consistenza Modifica Prenotazione
M21 Controllare Consistenza Creazione Pagamento
M22 Inserire Pagamento Maggiore
M23 Controllare Scadenze
M24 Convertire Valuta
M25 Data Banker
M26 Data Banker Create
M27 Data Banker Delete
M28 Data Banker Read
M29 Data Banker Update
M30 Gestire Schermate
M31 Inserire Entrata
M32 Inserire Finanziamento
M33 Inserire Impegno
M34 Inserire Pagamento
M35 Inserire Pagamento Prenotazione Esaurita
M36 Inserire Prenotazione
M37 Leggere Metadati
M38 Main
M39 Modificare/Cancellare Entrata
M40 Modificare/Cancellare Finanziamento
M41 Modificare/Cancellare Impegno
M42 Modificare/Cancellare Prenotazione
M43 Navigare Entrate
M44 Navigare Finanziamenti
M45 Navigare Impegni
M46 Navigare Pagamenti
M47 Navigare Prenotazioni
M48 Selezionare Finanziamento da Consolidare
M49 Selezionare Prenotazione da Consolidare
M50 Trattare Errore

NOTE: viene indicato anche il codice in modo da rendere più leggibili le tabelle delle successive metriche, nelle quali
verrà usato il codice al posto del nome del modulo

Caso di studio Ingegneria del Software II 47


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: NMOD
VALORE RILEVATO: 50

Caso di studio Ingegneria del Software II 48


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: T
VALORE RILEVATO:

TIPOLOGIA
Controllo
Afferente
Efferente
Trasformazione
Data Banker

Caso di studio Ingegneria del Software II 49


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: TAV
VALORE RILEVATO:

TAVOLA
Finanziamenti
Entrate
Prenotazioni
Impegni
Pagamenti
Finanziamenti Entrate
Finanziamenti Prenotazioni
Prenotazioni Impegni
Impegni Pagamenti

Caso di studio Ingegneria del Software II 50


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SD
VALORE RILEVATO:

STRUTTURA DATI
db_request
db_result
JoinTab
INS_RIC
Metadati
MOD_CANC_RIC
RIC
TipoValuta

Caso di studio Ingegneria del Software II 51


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: S
VALORE RILEVATO:

CODICE SEGRETO
S1 algoritmo di conversione valuta (Euro-Lire)
S2 algoritmo per la generazione automatica della chiave di un record
S3 D.B.M.S. usato
S4 gestione della situazione di un aumento di un impegno e della prenotazione che non riesce a coprirlo
S5 gestione dell'interfaccia grafica
S6 gestione messaggistica di errore
S7 metodo per il calcolo della disponibilità di cassa non impegnata
S8 metodo per il calcolo della parte di prenotazione non impegnata
S9 metodo per il calcolo della situazione economica e finanziaria
S10 metodo per il consolidamento automatico di un finanziamento
S11 metodo per il consolidamento automatico di una entrata
S12 metodo per il consolidamento automatico di una prenotazione
S13 metodo per il consolidamento manuale di un finanziamento
S14 metodo per il consolidamento manuale di una prenotazione
S15 metodo per la cancellazione di un finanziamento
S16 metodo per la cancellazione di un impegno
S17 metodo per la cancellazione di una entrata
S18 metodo per la cancellazione di una prenotazione
S19 metodo per la modifica di un finanziamento
S20 metodo per la modifica di un impegno
S21 metodo per la modifica di una entrata
S22 metodo per la modifica di una prenotazione
S23 metodo per l'aggiornamento della situazione economica e finanziaria
S24 metodo per l'individuazione delle scadenze
S25 metodo per l'inserimento di un nuovo finanziamento
S26 metodo per l'inserimento di un nuovo impegno
S27 metodo per l'inserimento di un nuovo pagamento quando l'importo è uguale all'impegno
S28 metodo per l'inserimento di un nuovo pagamento quando l'importo è maggiore dell'impegno
S29 metodo per l'inserimento di un nuovo pagamento quando l'importo è minore dell'impegno
S30 metodo per l'inserimento di una nuova entrata
S31 metodo per l'inserimento di una nuova prenotazione
S32 modalità di presentazione dati richiesti per la navigazione degli impegni
S33 modalità di presentazione dati richiesti per la navigazione dei finanziamenti
S34 modalità di presentazione dati richiesti per la navigazione dei pagamenti
S35 modalità di presentazione dati richiesti per la navigazione delle entrate
S36 modalità di presentazione dati richiesti per la navigazione delle prenotazioni
S37 modalità di presentazione dati richiesti per la variazione degli impegni
S38 modalità di presentazione dati richiesti per la variazione dei finanziamenti
S39 modalità di presentazione dati richiesti per la variazione delle entrate
S40 modalità di presentazione dati richiesti per la variazione delle prenotazioni
S41 modalità di presentazione dati richiesti per l'inserimento degli impegni
S42 modalità di presentazione dati richiesti per l'inserimento dei finanziamenti
S43 modalità di presentazione dati richiesti per l'inserimento dei pagamenti
S44 modalità di presentazione dati richiesti per l'inserimento delle entrate
S45 modalità di presentazione dati richiesti per l'inserimento delle prenotazioni
S46 modalità di presentazione finanziamenti consolidabili manualmente
S47 modalità di presentazione prenotazioni consolidabili manualmente
S48 operazioni da eseguire al lancio del sistema
S49 ricerca entrate e modalità di presentazione risultati
S50 ricerca finanziamenti e modalità di presentazione risultati
S51 ricerca impegni e modalità di presentazione risultati
S52 ricerca pagamenti e modalità di presentazione risultati
S53 ricerca prenotazioni e modalità di presentazione risultati
S54 accesso ai metadati
S55 accesso ai servizi offerti dal data banker

NOTE: viene indicato anche il codice in modo da rendere più leggibili le tabelle delle successive metriche, nelle quali
verrà usato il codice al posto del nome del segreto

Caso di studio Ingegneria del Software II 52


DATA DI CONSEGNA: 03/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: MxS
VALORE RILEVATO: (le righe contengono i segreti, le colonne i moduli)

M10

M12

M13

M14

M15

M16

M17

M18

M19

M20

M21

M22

M23

M24
M11
M1

M2

M3

M4

M5

M6

M7

M8

M9
S1 x
S2
S3
S4
S5
S6
S7 x
S8 x
S9 x
S10 x
S11 x
S12 x
S13 x
S14 x
S15 x
S16 x
S17 x
S18 x
S19 x
S20 x
S21 x
S22 x
S23 x
S24 x
S25 x
S26 x
S27 x
S28 x
S29 x
S30 x
S31 x
S32
S33
S34
S35
S36
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 53


M37
M25

M26

M27

M28

M29

M30

M31

M32

M33

M34

M35

M36

M38

M39

M40

M41

M42

M43

M44

M45

M46

M47

M48

M49

M50
S1
S2 x x
S3 x x x x
S4 x
S5 x
S6 x
S7
S8
S9
S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26
S27
S28
S29
S30
S31
S32 x
S33 x
S34 x
S35 x
S36 x
S37 x
S38 x
S39 x
S40 x
S41 x
S42 x
S43 x
S44 x
S45 x
S46 x
S47 x
S48 x
S49 x
S50 x
S51 x
S52 x
S53 x
S54 x
S55 x

Caso di studio Ingegneria del Software II 54


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: MxT
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tipologie)

Controllo Afferente Efferente Trasformazione Data Banker


M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x
M16 x
M17 x
M18 x
M19 x
M20 x
M21 x
M22 x
M23 x
M24 x
M25 x
M26 x
M27 x
M28 x
M29 x
M30 x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37 x
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x x
M44 x x
M45 x x
M46 x x
M47 x x
M48 x
M49 x
M50 x

Caso di studio Ingegneria del Software II 55


DATA DI CONSEGNA: 03/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SDxM
VALORE RILEVATO: (le righe contengono i moduli, le colonne le strutture dati)

MOD_CANC_RIC

TipoValuta
db_request

INS_RIC
db_result

Metadati
JoinTab

RIC
M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x
M16 x
M17 x
M18 x
M19 x
M20 x
M21 x
M22 x
M23 x
M24 x
M25 x
M26 x x
M27 x
M28 x x
M29 x x
M30 x x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50

Caso di studio Ingegneria del Software II 56


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: MxTAV
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tavole)
Finanziamenti

Finanziamenti

Finanziamenti
Prenotazioni

Prenotazioni

Prenotazioni
Pagamenti

Pagamenti
Impegni

Impegni

Impegni
Entrate

Entrate
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
M11
M12
M13
M14
M15
M16
M17
M18
M19
M20
M21
M22
M23
M24
M25
M26
M27
M28
M29
M30
M31
M32
M33
M34
M35
M36
M37
M38
M39
M40
M41
M42
M43
M44
M45
M46
M47
M48
M49
M50

NOTE: l'assenza di corrispondenze è dovuta all'uso del data banker per l'accesso ai dati nel sistema: infatti, il data banker
è implementato in modo da costruire automaticamente, sulla base dei metadati, le richieste per l'accesso al database.

Caso di studio Ingegneria del Software II 57


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DI
VALORE RILEVATO:

M1 3
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 2
M14 1
M15 2
M16 2
M17 3
M18 2
M19 3
M20 3
M21 2
M22 2
M23 0
M24 1
M25 1
M26 3
M27 2
M28 2
M29 4
M30 0
M31 0
M32 0
M33 0
M34 0
M35 2
M36 0
M37 1
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 1

Caso di studio Ingegneria del Software II 58


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DO
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 0
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 2
M32 2
M33 2
M34 2
M35 1
M36 2
M37 1
M38 0
M39 1
M40 1
M41 1
M42 1
M43 0
M44 0
M45 0
M46 0
M47 0
M48 1
M49 1
M50 0

Caso di studio Ingegneria del Software II 59


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CI
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 1
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 1
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0

Caso di studio Ingegneria del Software II 60


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CO
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0

Caso di studio Ingegneria del Software II 61


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GD
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0

Caso di studio Ingegneria del Software II 62


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GC
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0

Caso di studio Ingegneria del Software II 63


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: FANIN
VALORE RILEVATO:

M1 6
M2 2
M3 4
M4 1
M5 1
M6 1
M7 1
M8 2
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 2
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 15
M25 40
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 4
M38 0
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1

Caso di studio Ingegneria del Software II 64


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: FANOUT
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 2
M5 3
M6 1
M7 2
M8 2
M9 2
M10 1
M11 2
M12 1
M13 2
M14 1
M15 5
M16 1
M17 2
M18 1
M19 2
M20 1
M21 4
M22 3
M23 1
M24 0
M25 4
M26 1
M27 1
M28 1
M29 1
M30 17
M31 2
M32 1
M33 2
M34 2
M35 1
M36 2
M37 0
M38 18
M39 2
M40 2
M41 2
M42 2
M43 2
M44 2
M45 2
M46 2
M47 2
M48 1
M49 1
M50 0

Caso di studio Ingegneria del Software II 65


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: ACC
VALORE RILEVATO:

M1 0.909
M2 0.800
M3 0.857
M4 0.666
M5 0.833
M6 0.750
M7 0.800
M8 0.833
M9 0.800
M10 0.750
M11 0.800
M12 0.750
M13 0.833
M14 0.750
M15 0.909
M16 0.833
M17 0.857
M18 0.800
M19 0.857
M20 0.833
M21 0.875
M22 0.857
M23 0.500
M24 0.947
M25 0.978
M26 0.833
M27 0.800
M28 0.800
M29 0.857
M30 0.947
M31 0.800
M32 0.750
M33 0.800
M34 0.800
M35 0.800
M36 0.800
M37 0.833
M38 0.944
M39 0.750
M40 0.750
M41 0.750
M42 0.750
M43 0.666
M44 0.666
M45 0.666
M46 0.666
M47 0.666
M48 0.666
M49 0.666
M50 0.500

Caso di studio Ingegneria del Software II 66


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: TM
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 2
M44 2
M45 2
M46 2
M47 2
M48 1
M49 1
M50 1

Caso di studio Ingegneria del Software II 67


DATA DI CONSEGNA: 03/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: SN
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 2
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 2
M22 1
M23 1
M24 1
M25 1
M26 2
M27 1
M28 1
M29 2
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 2
M44 2
M45 2
M46 2
M47 2
M48 1
M49 1
M50 1

Caso di studio Ingegneria del Software II 68


DATA DI CONSEGNA: 03/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MNS
VALORE RILEVATO:

S1 1
S2 2
S3 4
S4 1
S5 1
S6 1
S7 1
S8 1
S9 1
S10 1
S11 1
S12 1
S13 1
S14 1
S15 1
S16 1
S17 1
S18 1
S19 1
S20 1
S21 1
S22 1
S23 1
S24 1
S25 1
S26 1
S27 1
S28 1
S29 1
S30 1
S31 1
S32 1
S33 1
S34 1
S35 1
S36 1
S37 1
S38 1
S39 1
S40 1
S41 1
S42 1
S43 1
S44 1
S45 1
S46 1
S47 1
S48 1
S49 1
S50 1
S51 1
S52 1
S53 1
S54 1
S55 1

Caso di studio Ingegneria del Software II 69


DATA DI CONSEGNA: 03/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MDS
VALORE RILEVATO:

db_request 1
db_result 40
JoinTab 3
INS_RIC 1
Metadati 4
MOD_CANC_RIC 1
RIC 1
TipoValuta 1

NOTE: il valore 40 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 70


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MTS
VALORE RILEVATO:

Finanziamenti 0
Entrate 0
Prenotazioni 0
Impegni 0
Pagamenti 0
Finanziamenti Entrate 0
Finanziamenti Prenotazioni 0
Prenotazioni Impegni 0
Impegni Pagamenti 0

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema: infatti, il data banker
è implementato in modo da costruire automaticamente, sulla base dei metadati, le richieste per l'accesso al database.

Caso di studio Ingegneria del Software II 71


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT5NF
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 72


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 73


DATA DI CONSEGNA: 02/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: PT5NF
VALORE RILEVATO: 1

Caso di studio Ingegneria del Software II 74


DATA DI CONSEGNA: 08/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: MxMMODRIUS
VALORE RILEVATO:

CODICE MODULO MODIFICATO RIUSATO


M1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa x
M2 Calcolare Disponibilità di Cassa Non Impegnata x
M3 Calcolare Prenotazione Non Impegnata x
M4 Calcolare Situazione Eco./Fin. x
M5 Consolidare Automaticamente x
M6 Consolidare Entrate x
M7 Consolidare Manualmente Finanziamento x
M8 Consolidare Manualmente Prenotazione x
M9 Controllare Consistenza Cancellazione Entrata x
M10 Controllare Consistenza Cancellazione Finanziamento x
M11 Controllare Consistenza Cancellazione Impegno x
M12 Controllare Consistenza Cancellazione Prenotazione x
M13 Controllare Consistenza Creazione Entrata x
M14 Controllare Consistenza Creazione Finanziamento x
M15 Controllare Consistenza Creazione Impegno x x
M16 Controllare Consistenza Creazione Prenotazione x
M17 Controllare Consistenza Modifica Entrata x
M18 Controllare Consistenza Modifica Finanziamento x
M19 Controllare Consistenza Modifica Impegno x
M20 Controllare Consistenza Modifica Prenotazione x
M21 Controllare Consistenza Creazione Pagamento x x
M22 Inserire Pagamento Maggiore x x
M23 Controllare Scadenze x
M24 Convertire Valuta x
M25 Data Banker x
M26 Data Banker Create x x
M27 Data Banker Delete x
M28 Data Banker Read x
M29 Data Banker Update x x
M30 Gestire Schermate x x
M31 Inserire Entrata x
M32 Inserire Finanziamento x
M33 Inserire Impegno x
M34 Inserire Pagamento x
M35 Inserire Pagamento Prenotazione Esaurita x
M36 Inserire Prenotazione x
M37 Leggere Metadati x
M38 Main x x
M39 Modificare/Cancellare Entrata x
M40 Modificare/Cancellare Finanziamento x
M41 Modificare/Cancellare Impegno x
M42 Modificare/Cancellare Prenotazione x
M43 Navigare Entrate x x
M44 Navigare Finanziamenti x x
M45 Navigare Impegni x x
M46 Navigare Pagamenti x x
M47 Navigare Prenotazioni x x
M48 Selezionare Finanziamento da Consolidare x
M49 Selezionare Prenotazione da Consolidare x
M50 Trattare Errore x

Caso di studio Ingegneria del Software II 75


DATA DI CONSEGNA: 08/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: NMMOD
VALORE RILEVATO: 13

Caso di studio Ingegneria del Software II 76


DATA DI CONSEGNA: 08/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: NMRIUS
VALORE RILEVATO: 49

Caso di studio Ingegneria del Software II 77


DATA DI CONSEGNA: 08/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: PERMMOD
VALORE RILEVATO: 0.26

Caso di studio Ingegneria del Software II 78


DATA DI CONSEGNA: 08/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: PERMRIUS
VALORE RILEVATO: 0.98

Caso di studio Ingegneria del Software II 79


Distanze dagli obiettivi
INDICE DELLE METRICHE:
ACC pag. 87
CI pag. 82
CO pag. 83
FANIN pag. 86
GC pag. 85
GD pag. 84
MDS pag. 91
MNS pag. 90
MTS pag. 92
PT5NF pag. 93
SN pag. 89
TM pag. 88

NOTE:

• una distanza pari a 0 indica il raggiungimento della baseline hypothesis; un valore diverso invece quantifica la
distanza tra il valore rilevato e la baseline hypothesis

• una distanza pari a nessuna indica il raggiungimento della baseline hypothesis

• una distanza pari a rientra indica che il valore rilevato è migliore di quello indicato nella baseline hypothesis

• le distanze segnate in grassetto indicano le metriche che non hanno raggiunto le baseline hypothesis (cioè il valore
rilevato è peggiore)

• per alcune metriche è indicato eccezione, ovvero il valore rilevato è peggiore della baseline hypothesis ma si ritiene
che la metrica abbia dato risultati positivi per i motivi spiegati nelle note o tra le distanze stesse

Caso di studio Ingegneria del Software II 80


METRICA: CI
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 0
M2 0 0
M3 0 0
M4 0 0
M5 0 0
M6 0 0
M7 0 0
M8 0 0
M9 0 0
M10 0 0
M11 0 0
M12 0 0
M13 0 0
M14 0 0
M15 1 1
M16 0 0
M17 0 0
M18 0 0
M19 0 0
M20 0 0
M21 0 0
M22 0 0
M23 0 0
M24 1 1
M25 0 0
M26 0 0
M27 0 0
M28 0 0
M29 0 0
M30 0 0
M31 0 0
M32 0 0
M33 0 0
M34 0 0
M35 0 0
M36 0 0
M37 0 0
M38 0 0
M39 0 0
M40 0 0
M41 0 0
M42 0 0
M43 0 0
M44 0 0
M45 0 0
M46 0 0
M47 0 0
M48 0 0
M49 0 0
M50 0 0

NOTE: il numero di moduli con CI pari a 1 è uguale a 2, quindi essendo al di sotto del 5% dei moduli del sistema, la
baseline hypothesis è stata raggiunta.

Caso di studio Ingegneria del Software II 81


METRICA: CO
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna

Caso di studio Ingegneria del Software II 82


METRICA: GD
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna

Caso di studio Ingegneria del Software II 83


METRICA: GC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna

Caso di studio Ingegneria del Software II 84


METRICA: FANIN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 6 nessuna (r.i.)
M2 2 nessuna (g.)
M3 4 nessuna (r.i.)
M4 1 nessuna (g.)
M5 1 nessuna (g.)
M6 1 nessuna (g.)
M7 1 nessuna (g.)
M8 2 nessuna (g.)
M9 1 nessuna (g.)
M10 1 nessuna (g.)
M11 1 nessuna (g.)
M12 1 nessuna (g.)
M13 1 nessuna (g.)
M14 1 nessuna (g.)
M15 1 nessuna (g.)
M16 2 nessuna (g.)
M17 1 nessuna (g.)
M18 1 nessuna (g.)
M19 1 nessuna (g.)
M20 1 nessuna (g.)
M21 1 nessuna (g.)
M22 1 nessuna (g.)
M23 1 nessuna (g.)
M24 15 nessuna (r.e.)
M25 40 nessuna (r.e.)
M26 1 nessuna (g.)
M27 1 nessuna (g.)
M28 1 nessuna (g.)
M29 1 nessuna (g.)
M30 1 nessuna (g.)
M31 1 nessuna (g.)
M32 1 nessuna (g.)
M33 1 nessuna (g.)
M34 1 nessuna (g.)
M35 1 nessuna (g.)
M36 1 nessuna (g.)
M37 4 nessuna (r.i.)
M38 0 nessuna (g.)
M39 1 nessuna (g.)
M40 1 nessuna (g.)
M41 1 nessuna (g.)
M42 1 nessuna (g.)
M43 1 nessuna (g.)
M44 1 nessuna (g.)
M45 1 nessuna (g.)
M46 1 nessuna (g.)
M47 1 nessuna (g.)
M48 1 nessuna (g.)
M49 1 nessuna (g.)
M50 1 nessuna (g.)

NOTE: Le sigle r.i., r.e. e g. sono le abbreviazioni di riusabile internamente, riusabile esternamente e generico

Caso di studio Ingegneria del Software II 85


METRICA: ACC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0.909 eccezione (FANIN alto)
M2 0.800 rientra
M3 0.857 rientra
M4 0.666 rientra
M5 0.833 rientra
M6 0.750 rientra
M7 0.800 rientra
M8 0.833 rientra
M9 0.800 rientra
M10 0.750 rientra
M11 0.800 rientra
M12 0.750 rientra
M13 0.833 rientra
M14 0.750 rientra
M15 0.909 0.049
M16 0.833 rientra
M17 0.857 rientra
M18 0.800 rientra
M19 0.857 rientra
M20 0.833 rientra
M21 0.875 0.050
M22 0.857 rientra
M23 0.500 rientra
M24 0.947 eccezione (FANIN alto)
M25 0.978 eccezione (FANIN alto)
M26 0.833 rientra
M27 0.800 rientra
M28 0.800 rientra
M29 0.857 rientra
M30 0.947 eccezione (modulo di controllo)
M31 0.800 rientra
M32 0.750 rientra
M33 0.800 rientra
M34 0.800 rientra
M35 0.800 rientra
M36 0.800 rientra
M37 0.833 rientra
M38 0.944 eccezione (modulo di controllo)
M39 0.750 rientra
M40 0.750 rientra
M41 0.750 rientra
M42 0.750 rientra
M43 0.666 rientra
M44 0.666 rientra
M45 0.666 rientra
M46 0.666 rientra
M47 0.666 rientra
M48 0.666 rientra
M49 0.666 rientra
M50 0.500 rientra

Caso di studio Ingegneria del Software II 86


METRICA: TM
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 1 nessuna
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 2 1
M44 2 1
M45 2 1
M46 2 1
M47 2 1
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna

Caso di studio Ingegneria del Software II 87


METRICA: SN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 2 1
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 2 1
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 2 1
M27 1 nessuna
M28 1 nessuna
M29 2 1
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 2 1
M44 2 1
M45 2 1
M46 2 1
M47 2 1
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna

Caso di studio Ingegneria del Software II 88


METRICA: MNS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
S1 1 nessuna
S2 2 nessuna
S3 4 nessuna
S4 1 nessuna
S5 1 nessuna
S6 1 nessuna
S7 1 nessuna
S8 1 nessuna
S9 1 nessuna
S10 1 nessuna
S11 1 nessuna
S12 1 nessuna
S13 1 nessuna
S14 1 nessuna
S15 1 nessuna
S16 1 nessuna
S17 1 nessuna
S18 1 nessuna
S19 1 nessuna
S20 1 nessuna
S21 1 nessuna
S22 1 nessuna
S23 1 nessuna
S24 1 nessuna
S25 1 nessuna
S26 1 nessuna
S27 1 nessuna
S28 1 nessuna
S29 1 nessuna
S30 1 nessuna
S31 1 nessuna
S32 1 nessuna
S33 1 nessuna
S34 1 nessuna
S35 1 nessuna
S36 1 nessuna
S37 1 nessuna
S38 1 nessuna
S39 1 nessuna
S40 1 nessuna
S41 1 nessuna
S42 1 nessuna
S43 1 nessuna
S44 1 nessuna
S45 1 nessuna
S46 1 nessuna
S47 1 nessuna
S48 1 nessuna
S49 1 nessuna
S50 1 nessuna
S51 1 nessuna
S52 1 nessuna
S53 1 nessuna
S54 1 nessuna
S55 1 nessuna

Caso di studio Ingegneria del Software II 89


METRICA: MDS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
db_request 1 rientra
db_result 40 eccezione (vedere note)
JoinTab 3 rientra
INS_RIC 1 rientra
Metadati 4 rientra
MOD_CANC_RIC 1 rientra
RIC 1 rientra
TipoValuta 1 rientra

NOTE: il valore 40 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 90


METRICA: MTS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
Finanziamenti 0 rientra
Entrate 0 rientra
Prenotazioni 0 rientra
Impegni 0 rientra
Pagamenti 0 rientra
Finanziamenti Entrate 0 rientra
Finanziamenti Prenotazioni 0 rientra
Prenotazioni Impegni 0 rientra
Impegni Pagamenti 0 rientra

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema.

Caso di studio Ingegneria del Software II 91


METRICA: PT5NF
VALORE RILEVATO: 1
DISTANZA DALLA BASELINE HYPHOTESIS: nessuna

Caso di studio Ingegneria del Software II 92


Punti di debolezza

FOGLIO METRICO PUNTO DI DEBOLEZZA METRICHE CARENTI


G1 Modularità ACC
TM
SN

Caso di studio Ingegneria del Software II 93


Fattori di variazione

FOGLIO METRICO PUNTO DI DEBOLEZZA METRICHE CARENTI FATTORI DI VARIAZIONE

• esperienza del team di progetto nella


ACC
progettazione della struttura del
TM
sistema
SN
G1 Modularità
• esperienza del team di progetto nella
ACC progettazione delle interfacce tra le
singole componenti

Caso di studio Ingegneria del Software II 94


Ipotesi di miglioramento del sistema software

Il sistema GEFIN D.F. presenta come punto di debolezza la modularità. Al fine di migliorare la qualità del sistema, i
possibili interventi da effettuare su di esso sono i seguenti:

 al fine di ridurre l'accoppiamento dei moduli del sistema, è necessario intervenire sui singoli moduli ad alto
accoppiamento (superiore al valore 0.860) ed eventualmente su tutti i moduli interconnessi. Per ridurre
l'accoppiamento di un modulo sono possibili due tipi di interventi: ristrutturazione dell'interfaccia tra i moduli e
ristrutturazione interna del modulo stesso. Per il primo intervento è necessario verificare la necessità di tutti i dati
passati al modulo come parametri e la necessità di tutti i dati restituiti dal modulo. Se il numero di dati passati è
elevato e questi dati sono "collegati" tra loro, è possibile sostituirli con una struttura. Per il secondo intervento è
necessario verificare che il modulo svolga un'unica funzione. In caso contrario è necessario dividere il modulo in
moduli dedicati ad un'unica funzione. In questo modo è anche possibile che il gran numero di dati passati al/dal
modulo originario sia distribuito ai moduli derivanti dalla sua divisione.

 al fine di ridurre il numero di tipologie di appartenenza dei singoli moduli, è necessario rivedere la struttura del
sistema intervenendo sui moduli che appartengono a più di una tipologia. Per questi moduli sono necessari
interventi che tendano a ridurre a una le funzioni principali svolte da ogni singolo modulo. Tale scopo può essere
raggiunto mediante l'esplosione dei moduli: ognuno dei moduli derivanti sarà progettato in modo che appartenga
ad una ed una sola tipologia, e quindi in modo che all'interno del sistema svolga una sola funzione principale. Si
evince che i moduli risultanti dall'esplosione di un singolo modulo dovranno essere posti in aree differenti della
struttura del sistema, perciò è possibile che in queste aree vadano eseguiti degli interventi al fine di integrare i
nuovi moduli.

 al fine di ridurre a uno il numero di segreti nascosti nei singoli moduli, è necessario intervenire sui moduli che
nascondono più di un segreto riprogettandoli al fine di separare i singoli segreti in moduli distinti. Tale scopo può
essere raggiunto mediante l'esplosione dei moduli: in ognuno dei moduli derivanti da tale operazione sarà nascosto
uno ed uno solo dei segreti nascosti nel modulo originario.

Caso di studio Ingegneria del Software II 95


Scheda descrizione degli interventi
COMPONENTE DEL SISTEMA TIPOLOGIA DI INTERVENTO
Modulo Controllare • revisione struttura interna del modulo
Consistenza Creazione
Impegno
Modulo Consolidare • esplosione del modulo
Automaticamente
Modulo Controllare • esplosione del modulo
Consistenza Creazione
Pagamento • revisione dell'interfaccia del modulo
Modulo Data Banker Create • esplosione del modulo

Modulo Data Banker Update • esplosione del modulo

Modulo Navigare Entrate • esplosione del modulo

Modulo Navigare • esplosione del modulo


Finanziamenti

Modulo Navigare Impegni • esplosione del modulo

Modulo Navigare Pagamenti • esplosione del modulo

Modulo Navigare • esplosione del modulo


Prenotazioni

Structure Chart • revisione della struttura del sistema (structure chart e call graph)

• aggiornamento e integrazione dei possibili nuovi moduli (structure


chart e call graph)
Dizionario dei dati (progetto) • aggiornamento e integrazione delle possibili nuove strutture dati

Matrice Cross Reference • aggiornamento e integrazione delle possibili nuove componenti nella
RExDS matrice cross reference RExDS

Documenti di progetto • aggiornamento di tutta la documentazione di progetto al fine di


allinearla e renderla tracciabile con le modifiche effettuate

Codice sorgente • modifiche ai moduli del codice sogente interessati dalle modifiche al
progetto

• implementazione dei moduli e delle strutture dati eventualmente


aggiunti al progetto
Codice oggetto • ricompilazione del programma

Caso di studio Ingegneria del Software II 96


Specifiche delle modifiche

INDICE DEI PIANI ESECUTIVI:


Piano esecutivo 1 pag. 99
Piano esecutivo 2 pag. 102
Piano esecutivo 3 pag. 104

NOTE:
La descrizione completa del processo di sviluppo software è presente nell'Appendice A a pagina 324.

Caso di studio Ingegneria del Software II 97


Piano esecutivo 1

TIPOLOGIE DI INTERVENTI COPERTI:


T1 - revisione struttura interna del modulo
T2 - revisione dell'interfaccia del modulo
T3 - esplosione del modulo
T4 - revisione della struttura del sistema (structure chart e call graph)
T5 - aggiornamento e integrazione dei possibili nuovi moduli (structure chart e call graph)
T6 - aggiornamento e integrazione delle possibili nuove componenti nella matrice cross reference RExDS
T7 - aggiornamento di tutta la documentazione di progetto al fine di allinearla e renderla tracciabile con le
modifiche effettuate

COMPONENTI DEL SISTEMA INTERESSATE DALL'INTERVENTO:


Modulo Controllare Consistenza Creazione Impegno (T1)
Modulo Consolidare Automaticamente (T3)
Modulo Controllare Consistenza Creazione Pagamento (T2, T3)
Modulo Data Banker Create (T3)
Modulo Data Banker Update (T3)
Modulo Navigare Entrate (T3)
Modulo Navigare Finanziamenti (T3)
Modulo Navigare Impegni (T3)
Modulo Navigare Pagamenti (T3)
Modulo Navigare Prenotazioni (T3)
Structure Chart (T4, T5)
Matrice Cross Reference RexDS (T6)
Documenti di progetto (T7)

WORK FLOW DIAGRAM:

START

Rifinire la structure chart e le


specifiche dei moduli
2.5

Definire le strutture dei file


esterni e dei dati globali
2.6

Costruire la cross reference


RExDS
2.8

STOP

Caso di studio Ingegneria del Software II 98


SCENARI PROCEDURALI:

2.5 Rifinire la Structure Chart e le specifiche dei moduli


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli, Structure Chart, Tavole e percorsi di navigazione

Procedura:

1. Aggiungere i moduli per la gestione dei dati


2. Migliorare la Structure Chart utilizzando le euristiche
2a. Per ogni modulo del sistema
2a.1. Verificare la necessità di tutti i dati passati al modulo come parametri e la necessità di tutti i dati
restituiti dal modulo. Se il numero di dati passati è elevato e questi dati sono "collegati" tra loro,
è possibile sostituirli con una struttura.
2a.2. Verificare che il modulo svolga un'unica funzione. In caso contrario è necessario dividere il
modulo in moduli dedicati ad un'unica funzione. In questo modo è anche possibile che il gran
numero di dati passati al/dal modulo originario sia distribuito ai moduli derivanti dalla sua
divisione.
3. Migliorare la Structure Chart secondo i principi dell'Information Hiding
3a. Per ogni modulo del sistema
3a.1. Se il numero di funzioni principali svolte dal modulo è maggiore di uno, esplodere il modulo in
modo che all'interno del sistema svolga una sola funzione principale. Spostare i moduli risultanti
dall'esplosione in aree differenti della struttura del sistema, eseguendo quindi gli interventi
necessari ad integrarli con i moduli presenti in quelle nuove aree
3a.2. Se il numero di segreti nascosti dal modulo è maggiore di uno, esplodere il modulo in modo che
in ognuno dei moduli derivanti sia nascosto uno ed uno solo dei segreti nascosti nel modulo
originario
4. Per ciascun modulo aggiunto
4.1 Definire la specifica semantica e la specifica sintattica
4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo
4.3 Descrivere i dati referenziati
4.4 Definire gli altri moduli che esso utilizza

Output: Structure Chart aggiornata, Specifiche dei moduli aggiornate

I.E.C.: Prodotti di output realizzati

2.6 Definire le strutture dei file esterni e dei dati globali


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli aggiornate, Tavole e percorsi di navigazione, Dizionario dei dati (analisi)

Procedura:

1. Individuare l'insieme di file di dati esterni


2. Per ciascun file esterno individuato
2.1 Definire la struttura logica
2.2 Descrivere i record logici
2.3 Definire la modalità di accesso
3. Individuare l'insieme dei dati globali fornendo per ciascuno di essi la struttura
4. Costruire una matrice Cross Reference che associa ciascun dato globale/file esterno al modulo che
lo implementa

Output: Definizione delle strutture dei file esterni e dei dati globali

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 99


2.8 Costruire la Cross Reference RExDS
I.S.C.: Prodotti di input disponibili

Input: Structure Chart aggiornata, Requisiti utente

Procedura:

1. Costruire la matrice Cross Reference per stabilire in quale parte del progetto è implementato
ciascun requisito

Output: Matrice Cross Reference RExDS

I.E.C.: Prodotti di output realizzati

DESCRIZIONE DEI MANUFATTI:

• Definizione delle strutture dei file esterni e dei dati globali: struttura logica, record logici e modalità di accesso
per ogni file esterno; struttura di ciascun dato globale; matrice Cross Reference file esterno/dato globale x modulo
che li usa

• Matrice Cross Reference RexDS: matrice usata per stabilire in quale parte del progetto è implementato ciascun
requisito

• Requisiti utente: descrizione in qualunque forma di quello che l'utente intende ottenere dal prodotto software

• Specifiche dei moduli: definizione dettagliata delle operazioni che ciascun modulo software deve eseguire

• Specifiche dei moduli aggiornate: rifinitura delle specifiche dei moduli necessaria all'allineamento con la
Structure Chart aggiornata

• Structure Chart: espressione gerarchica delle relazioni fra i moduli e delle interfacce fra ogni coppia di essi

• Structure Chart aggiornata: rifinitura della Structure Chart utilizzando le euristiche e i principi dell'Information
Hiding

• Tavole e percorsi di navigazione: struttura dell'organizzazione della base di dati e insieme di percorsi logici per
navigarla

Caso di studio Ingegneria del Software II 100


Piano esecutivo 2

TIPOLOGIE DI INTERVENTI COPERTI:


T7 - aggiornamento di tutta la documentazione di progetto al fine di allinearla e renderla tracciabile con le
modifiche effettuate
T8 - aggiornamento e integrazione delle possibili nuove strutture dati

COMPONENTI DEL SISTEMA INTERESSATE DALL'INTERVENTO:


Dizionario dei dati (progetto) (T8)
Documenti di progetto (T7)

WORK FLOW DIAGRAM:

START

Definire il dizionario dei dati


(progetto)
2.7

STOP

SCENARI PROCEDURALI:

2.7 Definire il dizionario dei dati (progetto)


I.S.C.: Prodotti di input disponibili

Input: Dizionario dei dati (analisi), Diagramma delle dipendenze, Requisiti informatici

Procedura:

1. Per ciascuna struttura dati, indicare le componenti e il relativo tipo di dato

Output: Dizionario dei dati (progetto)

I.E.C.: Prodotti di output realizzati

DESCRIZIONE DEI MANUFATTI:

• Attributi di ciascuna entità: descrizione delle caratteristiche di ciascuna entità del modello E-R

• Attributi e funzionalità di ciascuna relazione: descrizione dei legami logici tra le diverse entità del modello E-R
e delle eventuali caratteristiche dei suddetti legami

• DFDs: descrizione dei requisiti funzionali dell'applicazione software. Ogni funzione deve essere identificata; le
funzioni possono essere articolate per livelli di dettaglio successivi. Le funzioni di livello più basso sono quelle
elementari

Caso di studio Ingegneria del Software II 101


• Diagramma delle dipendenze: diagramma in cui sono indicati, per ciascun dato della base di dati, le dipendenze
rispetto agli altri dati

• Dizionario dei dati (analisi): descrizione testuale dei flussi dei DFD, dei depositi e delle entità esterne

• Dizionario dei dati (progetto): descrizione delle strutture e dei dati usati nelle specifiche dei moduli

• Documenti analisi dei requisiti: documentazione ottenuta come risultato dell'analisi dei requisiti del software e
del sistema

Composizione: DFDs +
Dizionario dei dati (analisi) +
Specifica delle funzioni elementari +
Modello E-R +
Attributi di ciascuna entità +
Attributi e funzionalità di ciascuna relazione

• Modello E-R: descrizione dei requisiti informativi dell'applicazione software: diagramma entità (E) – relazioni
(R). Esprime il contenuto informativo dell'applicazione dal punto di vista dell'utilizzatore finale

• Requisiti informatici: descrizione dei requisiti per il sistema software

Composizione: Requisiti utente +


Documenti analisi dei requisiti

• Requisiti utente: descrizione in qualunque forma di quello che l'utente intende ottenere dal prodotto software

• Specifiche delle funzioni elementari: descrizione dettagliata delle operazioni di ciascuna funzione elementare dei
DFD

Caso di studio Ingegneria del Software II 102


Piano esecutivo 3

TIPOLOGIE DI INTERVENTI COPERTI:


T9 - modifiche ai moduli del codice interessati dalle modifiche al progetto
T10 - implementazione dei moduli e delle strutture dati eventualmente aggiunti al progetto
T11 - ricompilazione del programma

COMPONENTI DEL SISTEMA INTERESSATE DALL'INTERVENTO:


Codice sorgente (T9, T10)
Codice oggetto (T11)

WORK FLOW DIAGRAM:

START

Implementare il progetto

3.1

Compilare il programma

3.2

STOP

SCENARI PROCEDURALI:

3.1 Implementare il progetto


I.S.C.: Prodotti di input disponibili

Input: Documenti di progetto

Procedura:

1. Realizzare il codice
2. Realizzare la base di dati

Output: Codice sorgente

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 103


3.2 Compilare il programma
I.S.C.: Prodotti di input disponibili

Input: Codice sorgente

Procedura:

1. Compilare il programma
2. Se esistono errori sintattici
2.1 Correggere gli errori
2.2 Ripetere dal passo 1

Output: Codice sorgente corretto, Codice oggetto

I.E.C.: Prodotti di output realizzati

DESCRIZIONE DEI MANUFATTI:

• Codice: risultato della compilazione del programma

Composizione: Codice sorgente corretto +


Codice oggetto

• Codice oggetto: risultato della compilazione del codice sorgente

• Codice sorgente: codice delle componenti software

• Codice sorgente corretto: codice sorgete rielaborato in modo da eliminare gli errori sintattici

• Definizione delle strutture dei file esterni e dei dati globali: struttura logica, record logici e modalità di accesso
per ogni file esterno; struttura di ciascun dato globale; matrice Cross Reference file esterno/dato globale x modulo
che li usa

• Diagramma delle dipendenze: diagramma in cui sono indicati, per ciascun dato della base di dati, le dipendenze
rispetto agli altri dati

• Dizionario dei dati (progetto): descrizione delle strutture e dei dati usati nelle specifiche dei moduli

• Documenti di progetto: documenti prodotti durante la fase di progetto

Composizione: Documenti interni di progetto +


Vincoli di programmazione

• Documenti interni di progetto: documenti prodotti durante la fase di progetto, ad uso interno

Composizione: Structure Chart aggiornata +


Specifica dei moduli aggiornata +
Tavole e percorsi di navigazione +
Diagramma delle dipendenze +
Dizionario dei dati (progetto) +
Definizione delle strutture e dei file esterni e dei dati globali +
Matrice Cross Reference RexDS

• Matrice Cross Reference RexDS: matrice usata per stabilire in quale parte del progetto è implementato ciascun
requisito

Caso di studio Ingegneria del Software II 104


• Specifiche dei moduli aggiornata: rifinitura delle specifiche dei moduli necessaria all'allineamento con la
Structure Chart aggiornata

• Structure Chart aggiornata: rifinitura della Structure Chart utilizzando le euristiche e i principi dell'Information
Hiding

• Tavole e percorsi di navigazione: struttura dell'organizzazione della base di dati e insieme di percorsi logici per
navigarla

• Vincoli di programmazione: accorgimenti che il progettista detta al programmatore.

Caso di studio Ingegneria del Software II 105


Miglioramento del processo di sviluppo software

• Negli scenari procedurali del processo di sviluppo software, sostituire la specifica dell'attività 2.5 (Rifinire la
Structure Chart e le specifiche dei moduli) con la seguente:

2.5 Rifinire la Structure Chart e le specifiche dei moduli


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli, Structure Chart, Tavole e percorsi di navigazione

Procedura:

1. Aggiungere i moduli per la gestione dei dati


2. Migliorare la Structure Chart utilizzando le euristiche
2a. Per ogni modulo del sistema
2a.1. Verificare la necessità di tutti i dati passati al modulo come parametri e la necessità di tutti i dati
restituiti dal modulo. Se il numero di dati passati è elevato e questi dati sono "collegati" tra loro,
è possibile sostituirli con una struttura.
2a.2. Verificare che il modulo svolga un'unica funzione. In caso contrario è necessario dividere il
modulo in moduli dedicati ad un'unica funzione. In questo modo è anche possibile che il gran
numero di dati passati al/dal modulo originario sia distribuito ai moduli derivanti dalla sua
divisione.
3. Migliorare la Structure Chart secondo i principi dell'Information Hiding
3a. Per ogni modulo del sistema
3a.1. Se il numero di funzioni principali svolte dal modulo è maggiore di uno, esplodere il modulo in
modo che all'interno del sistema svolga una sola funzione principale. Spostare i moduli risultanti
dall'esplosione in aree differenti della struttura del sistema, eseguendo quindi gli interventi
necessari ad integrarli con i moduli presenti in quelle nuove aree
3a.2. Se il numero di segreti nascosti dal modulo è maggiore di uno, esplodere il modulo in modo che
in ognuno dei moduli derivanti sia nascosto uno ed uno solo dei segreti nascosti nel modulo
originario
4. Per ciascun modulo aggiunto o modificato
4.1 Definire la specifica semantica e la specifica sintattica
4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo
4.3 Descrivere i dati referenziati
4.4 Definire gli altri moduli che esso utilizza

Output: Structure Chart aggiornata, Specifiche dei moduli aggiornate

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 106


Piano esecutivo esecuzione numero 2
del processo di miglioramento

Caso di studio Ingegneria del Software II 107


START

Rilevare le misure

1.6

Interpretare le misure

2.1

Individuare i punti di
debolezza
2.2

Individuare i fattori di
variazione
3.1

Individuare le ipotesi di
miglioramento
3.2

Individuare gli interventi da


effettuare
4.1

Specificare le modifiche alle


componenti
4.2

Modificare il sistema software


4.3

STOP

Caso di studio Ingegneria del Software II 108


Manufatti dell'esecuzione numero 2
del processo di miglioramento

Caso di studio Ingegneria del Software II 109


Indice dei manufatti usati e/o prodotti:

Distanze dagli obiettivi pag. 161


Fattori di variazione pag. 179
Fogli metrici pag. 123, 175
Ipotesi di miglioramento dei fogli metrici pag. 174
Ipotesi di miglioramento del sistema software pag. 180
Miglioramento del processo di sviluppo software pag. 191
Misure pag. 126
Piano di misurazioni pag. 116
Piano GQM pag. 112
Punti di debolezza pag. 178
Scheda descrizione degli interventi pag. 181
Specifiche delle modifiche pag. 182

NOTE:

I manufatti Sistema software e Sistema software modificato sono presenti in formato elettronico nel CD-ROM allegato.
Il Sistema software nella directory GEFIN-1, il Sistema software modificato nella directory GEFIN-2

Caso di studio Ingegneria del Software II 110


Piano GQM

INDICE DEI GOAL:


Goal G1 pag. 113

Caso di studio Ingegneria del Software II 111


G1
Analizzare: sistema software GEFIN D.F.
Allo scopo di: migliorarlo
Rispetto a: information hiding
Dal punto di vista di: ingegnere del software
Nel contesto di: corso di Ingegneria del Software II

Caratterizzazione del prodotto


Q1,1 Qual è la morfologia della structure chart ?

M lista dei moduli presenti nella structure chart


NMOD numero di moduli presenti nella structure chart

Q1,2 Come sono distribuiti i segreti nella structure chart ?

S lista dei segreti nascosti nel sistema


MxS per ogni modulo, il o i segreti che nasconde (tabella cross-reference)

Q1,3 Come è ripartita la structure chart ?

T lista delle tipologie (funzioni principali del sistema) dei moduli


MxT per ogni modulo, a quale o a quali tipologie appartiene (tabella cross-reference)

Q1,4 Come è distribuita la conoscenza dei dati nella structure chart ?

SD lista delle strutture dati usate dal sistema


SDxM per ogni struttura dato, il o i moduli che la conoscono (tabella cross-reference)

TAV lista delle tavole presenti nel database usato dal sistema
MxTAV per ogni modulo, la o le tavole di cui il modulo conosce la struttura (tabella cross-reference)

Modello primario di qualità


Q1,5 Il sistema presenta un'effettiva modularità ?

DI per ogni modulo, il numero di parametri-dato di input al modulo


DO per ogni modulo, il numero di parametri-dato di output del modulo
CI per ogni modulo, il numero di parametri di controllo di input al modulo
CO per ogni modulo, il numero di parametri di controllo di output del modulo
GD per ogni modulo, il numero di variabili globali utilizzate come dati nel modulo
GC per ogni modulo, il numero di variabili globali utilizzate per controllo dal modulo
FANIN per ogni modulo, il numero di moduli che richiamano il modulo
FANOUT per ogni modulo, il numero di moduli richiamati dal modulo
ACC = 1 – 1 / (DI + 2CI + DO + 2CO + GD + 2GC + FANIN + FANOUT) (per ogni modulo)

Interpretazione: il valore di ACC è compreso tra 0 e 1. Il valore 0 corrisponde a basso accoppiamento, mentre il
valore 1 corrisponde ad alto accoppiamento. Per ogni modulo, il valore ACC deve essere il più vicino possibile a
0 e comunque non deve salire al di sopra di 0.850 (fanno eccezione i moduli di servizio per i quali FANIN
elevato aumenta ACC ma non è indice di cattiva modularità, e i moduli di controllo per i quali è normale un
valore elevato di FANOUT). Valori vicini a 0 indicano un alto grado di indipendenza del modulo dagli altri e
quindi che l'impatto di una modifica sul modulo sia localizzata e interessi un numero molto basso, se non nullo,
di moduli. Il valore di GD e GC deve essere pari a 0 per tutti i moduli, in caso contrario l'impatto di una modifica
su un modulo che usa una variabile globale potrebbe estendersi agli altri moduli che usano la stessa variabile
globale. Il valore di CO deve essere 0 per tutti i moduli per evitare che decisioni prese in un modulo interessino
moduli che non appartengono alla sua portata del controllo. Il valore di CI deve essere il più vicino possibile a 0

Caso di studio Ingegneria del Software II 112


in quanto la non perfetta conoscenza del suo significato può rendere ogni intervento di manutenzione difficile da
eseguire e incline all'introduzione di difetti; comunque la circolazione dei dati di controllo deve limitarsi a un
solo livello della structure chart per limitare la portata dell'effetto di una decisione.

TM per ogni modulo, il numero di tipologie a cui appartiene

Interpretazione: il valore di TM deve essere pari a 1 per ogni modulo. Un valore maggiore di 1 indica che il
modulo svolge più funzioni principali del sistema e questo implica difficoltà nel collaudo, manutenzione ed
estensione del sistema, oltre che una difficoltà nel capire la responsabilità del modulo e le funzioni da esso svolte.

MNS per ogni segreto, il numero di moduli che conoscono questo segreto

Interpretazione: per ogni segreto, il valore di MNS non deve superare il valore 5 e comunque deve essere un
valore vicino a 3. In caso contrario l'impatto della modifica di un dettaglio (segreto) si estenderebbe a tutti i
moduli che conoscono lo stesso dettaglio (segreto). Valori bassi di MNS indicano quindi una maggiore
localizzazione degli interventi di manutenzione.

MDS per ogni struttura dati, il numero di moduli che conoscono questa struttura

Interpretazione: per ogni struttura dati, il valore di MDS non deve superare il valore 4 e comunque deve essere il
più vicino possibile a 3. Per moduli che conoscono una struttura dati, si intendono quei moduli che usano dati
contenuti in essa per eseguire una elaborazione (non vanno considerati i moduli che scrivono dati nella struttura);
quindi un alto valore di MDS implica che una modifica alla struttura dati si estenderebbe a tutti i moduli che
usano i dati in essa contenuta per eseguire un'elaborazione.

MTS per ogni tavola del database, il numero di moduli che conoscono la sua struttura

Interpretazione: per ogni tavola, il valore di MTS deve essere non superiore a 1. In caso contrario una modifica
alla struttura della tavola avrebbe impatto su tutti i moduli che la conoscono.

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore a 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

NT5NF numero di tavole in quinta forma normale (5NF) presenti nel database
NT numero di tavole presenti nel database
PT5NF = NT5NF / NT

Interpretazione: il valore di PT5NF è compreso tra 0 e 1. Il valore di PT5NF deve essere uguale a 1, in caso
contrario è possibile che più moduli che svolgono funzioni diverse accedano alla stessa tavola e quindi questa
tavola aumenti l'accoppiamento dei moduli suddetti, oppure che un modulo effettui più funzioni diverse sulla
stessa tavola, diminuendo così l'indipendenza funzionale.

Q1,6 I moduli hanno una buona riusabilità ?

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore a 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

Caso di studio Ingegneria del Software II 113


FANIN per ogni modulo, il numero di moduli che lo richiamano

Interpretazione: il valore di FANIN indica il grado di riusabilità interna al sistema del modulo: a un valore alto di
FANIN corrisponde un modulo che svolge una precisa funzione richiesta da altri moduli, quindi si tratta di un
modulo di servizio. Inoltre moduli con alto FANIN presenti a un livello inferiore della structure chart, con molta
probabilità presentano anche riusabilità esterna.

Modello di conferma
Q1,7 Qual è l'impatto delle modifiche ?

MxMMODRIUS scheda dei moduli del vecchio sistema, modificati e riusati per il nuovo sistema
(tabella cross-reference)
NMRIUS numero di moduli del vecchio sistema modificati per il nuovo
NMMOD numero di moduli del vecchio sistema riusati nel nuovo
PERMMOD = NMMOD / NMOD
PERMRIUS = NMRIUS / NMOD

Interpretazione: i valori di PERMMOD e PERMRIUS sono compresi tra 0 e 1. Il valore di PERMMOD deve
essere il più vicino possibile a 0, non deve superare il valore 0.05 per garantire una struttura che localizza le
informazioni. Il valore di PERMRIUS deve essere il più vicino possibile a 1, non deve essere inferiore al valore
0.95 per garantire che il sistema sia stato modificato riusando la maggior parte delle componenti della versione
precedente

Caso di studio Ingegneria del Software II 114


Piano di misurazioni

INDICE DELLE METRICHE:


CI pag. 119
CO pag. 119
DI pag. 119
DO pag. 119
FANIN pag. 120
FANOUT pag. 120
GC pag. 120
GD pag. 119
M pag. 117
MDS pag. 121
MNS pag. 120
MTS pag. 121
MxMMODRIUS pag. 122
MxS pag. 117
MxT pag. 118
MxTAV pag. 118
NMMOD pag. 122
NMOD pag. 117
NMRIUS pag. 122
NT pag. 121
NT5NF pag. 121
S pag. 117
SD pag. 118
SDxM pag. 118
SN pag. 121
T pag. 117
TAV pag. 118
TM pag. 120

Caso di studio Ingegneria del Software II 115


M
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• raccogliere e riportare i nomi di tutti i moduli distinti presenti in essa.
Controlli da effettuare nessuno

NMOD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• contare il numero di moduli distinti presenti in essa
Controlli da effettuare nessuno

S
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• individuare e riportare i segreti (dettagli) distribuiti tra i moduli presenti in essa
Controlli da effettuare nessuno

MxS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed S
• considerare i valori rilevati con le metriche M ed S e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e i segreti elencati in
Come misurare
S
• usando la structure chart, per ogni modulo nella tabella, contrassegnare con una
"x" le caselle in corrispondenza dei segreti che nasconde
Controlli da effettuare  ogni segreto nella tabella deve essere nascosto in almeno un modulo

T
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
documenti di progetto
Come misurare
• individuare e riportare le tipologie di moduli presenti nella structure chart (moduli
efferenti, afferenti, di controllo, ecc…)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 116


MxT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e T
• considerare i valori rilevati con le metriche M e T e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tipologie
Come misurare
elencate in T
• usando la structure chart, per ogni modulo nella tabella contrassegnare con una "x"
le caselle in corrispondenza alla tipologia a cui appartiene
 ogni modulo nella tabella deve appartenere ad almeno una tipologia
Controlli da effettuare
 ogni tipologia nella tabella deve contenere almeno un modulo

SD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare il dizionario dei dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le strutture di dati distinte presenti in esso
Controlli da effettuare nessuno

SDxM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed SD
• considerare i valori rilevati con le metriche M ed SD e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le strutture dati
elencate in SD
Come misurare
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle strutture dati di cui conosce la struttura (per individuarle,
usare la specifica del modulo e verificare se il modulo usa dati in essa contenuti
per eseguire un'elaborazione)
Controlli da effettuare  ogni struttura dati nella tabella deve essere usata in almeno un modulo

TAV
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le tavole presenti in esso
Controlli da effettuare nessuno

MxTAV
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e TAV
• considerare i valori rilevati con le metriche M e TAV e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tavole elencate
Come misurare in TAV
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle tavole di cui conosce la struttura (per individuarle, usare la
specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 117


DI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato da elaborare"
Controlli da effettuare nessuno

DO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato da elaborare"
Controlli da effettuare nessuno

CI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato di controllo"
Controlli da effettuare nessuno

CO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato di controllo"
Controlli da effettuare nessuno

GD
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato da elaborare (usare la specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 118


GC
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato di controllo (usare la specifica del modulo)
Controlli da effettuare nessuno

FANIN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nelle specifiche dei moduli) che richiamano il modulo suddetto
 il valore di FANIN deve essere maggiore o uguale a 1, tranne per il modulo di
Controlli da effettuare
livello 1 della structure chart

FANOUT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nella specifica del modulo) richiamati dal modulo suddetto
Controlli da effettuare nessuno

TM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxT
• per ogni modulo elencato nella tabella MxT, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di TM deve essere maggiore o uguale a 1

MNS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni segreto elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MNS deve essere maggiore o uguale a 1

Caso di studio Ingegneria del Software II 119


MDS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica SDxM
• per ogni struttura dati elencata nella tabella SDxM, contare il numero di caselle, ad
Come misurare
essa relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MDS deve essere maggiore o uguale a 1

MTS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxTAV
• per ogni tavola elencata nella tabella MxTAV, contare il numero di caselle, ad essa
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

SN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni modulo elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

NT5NF
Chi deve misurare ingegnere del software
Quando misurare durante l'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare • contare il numero di tabelle in quinta forma normale contenute nello schema della
base di dati
Controlli da effettuare nessuno

NT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica TAV
Come misurare • contare il numero di tabelle elencate in TAV
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 120


MxMMODRIUS
Chi deve misurare ingegnere del software
Quando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)
• riportare in una tabella cross-reference i moduli elencati nella metrica M e i due
tipi "modificato" e "riusato"
• considerare i valori rilevati con la metrica M e la scheda descrizione degli
interventi prodotta nell'attività di specifica delle modifiche alle componenti
(attività 4.2)
Come misurare • per ogni modulo nella tabella, considerare la scheda degli interventi e
contrassegnare con una "x" la casella corrispondente a "modificato" se il modulo è
stato sottoposto a modifiche (anche eliminato, diviso o fuso con altri moduli)
• per ogni modulo della tabella, considerare la structure chart (o anche la call graph)
della nuova versione del sistema e contrassegnare con una "x" la casella
corrispondente a "riusato" se il modulo è presente nella structure chart
Controlli da effettuare nessuno

NMRIUS
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "riusato"
Controlli da effettuare nessuno

NMMOD
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "modificato"
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 121


Fogli metrici

Indice dei fogli metrici


Goal G1 pag. 124

Caso di studio Ingegneria del Software II 122


OGGETTO SCOPO OBIETTIVO DI QUALITÀ PUNTO DI VISTA CONTESTO
G1 sistema software GEFIN D.F. migliorare information hiding ingegnere del software corso di Ingegneria del
Software II
QUALITY FOCUS FATTORI DI VARIAZIONE
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) Metriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC
accoppiamento di un modulo
DI numero di parametri-dato di input al modulo • esperienza del team di progetto nella progettazione delle interfacce tra le singole
DO numero di parametri-dato di output del modulo componenti del sistema
CI numero di parametri di controllo di input al modulo Metriche influenzate: MDS, ACC, GD, GC
CO numero di parametri di controllo di output del modulo
GD numero di variabili globali utilizzate come dati nel modulo • esperienza del team di progetto nella progettazione delle basi di dati
GC numero di variabili globali utilizzate per controllo dal modulo Metriche influenzate: PT5NF
FANIN numero di moduli che richiamano il modulo
FANOUT numero di moduli richiamati dal modulo

TM: distribuzione della tipologia dei moduli tra i moduli del sistema

MNS: numero di moduli che nascondono un segreto

MDS: numero di moduli che conoscono la struttura di un dato

MTS: numero di moduli che conoscono la struttura di una tavola

SN: numero di segreti nascosti per modulo

PT5NF = NT5NF / NT : normalizzazione della base di dati


NT5NF: numero di tavole in 5NF presenti nel database
NT: numero di tavole presenti nel database

- Riusabilità:

SN: numero di segreti nascosti per modulo

FANIN: numero di moduli che usano un modulo

Caso di studio Ingegneria del Software II 123


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di
controllo per i quali valori vicini a 1 sono accettabili;  la maggiore esperienza nel ripartire la struttura del sistema secondo le funzioni
principali svolte, comporta una migliore distribuzione della tipologia dei moduli (basso
valore di TM); in particolare, delegando l'accesso ai dati a una sola tipologia di moduli
CI: massimo 1 per il 5% dei moduli del sistema
si riduce al minimo il numero di moduli che conoscono le singole componenti della
pari a 0 per il restante 95%; base di dati (MTS)
CO: pari a 0 per tutti i moduli del sistema;
GD: pari a 0 per tutti i moduli del sistema;  la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate
GC: pari a 0 per tutti i moduli del sistema; comporta un basso numero di segreti nascosti dallo stesso modulo (SN) oltre che
l'abbassamento del numero di moduli che conoscono lo stesso segreto (MNS)
TM: pari a 1 per tutti i moduli del sistema;
 la maggiore esperienza nel progettare moduli che implementano una singola funzione
MNS: massimo 4 per tutti i segreti; comporta la diminuzione dell'interconnessione tra i moduli, e quindi
dell'accoppiamento (ACC), in particolare diminuisce la necessità dell'uso di dati di
controllo (CO, CI e GC)
MDS: massimo 5 per tutte le strutture dati escluse quelle che fanno parte
dell'interfaccia delle componenti riusabili del sistema;
 la maggiore esperienza nell'identificare nei moduli del sistema funzioni ricorrenti più
volte, nell'estrarre queste funzioni e nell'inserire ognuna di esse in singoli moduli,
MTS: pari a 1 per tutte le tavole del sistema; comporta l'aumento del fan-in di questi moduli (FANIN)

SN: massimo 1 per tutti i moduli del sistema; • esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti
del sistema
PT5NF: pari a 1;
 la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di
- Riusabilità: controllo (mediante chiamata/sincronizzazione) o allo scambio (in input/output) dei soli
dati necessari, comporta la diminuzione dell'accoppiamento dei moduli (ACC). Inoltre
SN: pari a 1 per tutti i moduli del sistema; se i dati scambiati sono dati elementari e non strutture dati, si ottiene la diminuzione del
numero di moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi
moduli
FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili
esternamente; compreso tra il 5% e il 30% dei moduli del sistema  la maggiore esperienza nel limitare la possibilità di scambio di dati tra i moduli al solo
per i moduli riusabili internamente; minore del 5% dei moduli del uso della loro interfaccia, comporta la diminuzione della necessità di usare variabili
sistema per i moduli generici globali (GD e GC) e quindi la diminuzione dell'accoppiamento dei moduli (ACC)

• esperienza del team di progetto nella progettazione delle basi di dati

 la maggiore esperienza nel metodo della decomposizione senza perdita o nell'uso del
data modelling comporta una migliore normalizzazione della base di dati (PT5NF)

Caso di studio Ingegneria del Software II 124


Misure
INDICE DELLE METRICHE:
ACC pag. 147
CI pag. 141
CO pag. 142
DI pag. 139
DO pag. 140
FANIN pag. 145
FANOUT pag. 146
GC pag. 144
GD pag. 143
M pag. 127
MDS pag. 151
MNS pag. 150
MTS pag. 152
MxS pag. 133
MxT pag. 136
MxTAV pag. 138
NMOD pag. 128
NT pag. 154
NT5NF pag. 153
PT5NF pag. 155
S pag. 132
SD pag. 131
SDxM pag. 137
SN pag. 149
T pag. 129
TAV pag. 130
TM pag. 148

INDICE DELLE METRICHE DEL MODELLO DI CONFERMA:

MxMMODRIUS pag. 156


NMMOD pag. 157
NMRIUS pag. 158
PERMMOD pag. 159
PERMRIUS pag. 160

NOTE:
Le rilevazioni delle misure per le metriche relative al modello di conferma del piano GQM sono state rilevate al termine
dell'esecuzione degli interventi sul sistema (come si può notare dalle date di consegna delle schede).

CONSIDERAZIONI SUL MODELLO DI CONFERMA:

Dall'analisi dei valori di PERMMOD e PERMRIUS si possono trarre le seguenti conclusioni:

• il valore di PERMRIUS pari a 1 dimostra che il fattore di qualità riusabilità non sia un punto di debolezza per il
sistema;

• il valore di PERMMOD pari a 0.08 e quindi superiore a 0.05 dimostra che il fattore di qualità modularità sia un
punto di debolezza per il sistema. Il valore comunque non è di molto superiore a 0.05 ed è inoltre inferiore a quello
rilevato durante la prima esecuzione del processo (0.26) a dimostrazione del miglioramento della qualità del
sistema.

Caso di studio Ingegneria del Software II 125


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: M
VALORE RILEVATO:

CODICE MODULO
M1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa
M2 Calcolare Disponibilità di Cassa Non Impegnata
M3 Calcolare Prenotazione Non Impegnata
M4 Calcolare Situazione Eco./Fin.
M5 Consolidare Automaticamente Prenotazione
M6 Consolidare Entrate
M7 Consolidare Manualmente Finanziamento
M8 Consolidare Manualmente Prenotazione
M9 Controllare Consistenza Cancellazione Entrata
M10 Controllare Consistenza Cancellazione Finanziamento
M11 Controllare Consistenza Cancellazione Impegno
M12 Controllare Consistenza Cancellazione Prenotazione
M13 Controllare Consistenza Creazione Entrata
M14 Controllare Consistenza Creazione Finanziamento
M15 Controllare Consistenza Creazione Impegno
M16 Controllare Consistenza Creazione Prenotazione
M17 Controllare Consistenza Modifica Entrata
M18 Controllare Consistenza Modifica Finanziamento
M19 Controllare Consistenza Modifica Impegno
M20 Controllare Consistenza Modifica Prenotazione
M21 Controllare Consistenza Creazione Pagamento
M22 Inserire Pagamento Maggiore
M23 Controllare Scadenze
M24 Convertire Valuta
M25 Data Banker
M26 Data Banker Create
M27 Data Banker Delete
M28 Data Banker Read
M29 Data Banker Update
M30 Gestire Schermate
M31 Inserire Entrata
M32 Inserire Finanziamento
M33 Inserire Impegno
M34 Inserire Pagamento
M35 Inserire Pagamento Prenotazione Esaurita
M36 Inserire Prenotazione
M37 Leggere Metadati
M38 Main
M39 Modificare/Cancellare Entrata
M40 Modificare/Cancellare Finanziamento
M41 Modificare/Cancellare Impegno
M42 Modificare/Cancellare Prenotazione
M43 Navigare Entrate
M44 Navigare Finanziamenti
M45 Navigare Impegni
M46 Navigare Pagamenti
M47 Navigare Prenotazioni
M48 Selezionare Finanziamento da Consolidare
M49 Selezionare Prenotazione da Consolidare
M50 Trattare Errori
M51 Acquisire Parametri Navigazione Finanziamenti
M52 Acquisire Parametri Navigazione Entrate
M53 Acquisire Parametri Navigazione Prenotazioni
M54 Acquisire Parametri Navigazione Impegni NOTE: viene indicato anche il
M55 Acquisire Parametri Navigazione Pagamenti codice in modo da rendere più
M56 Inserire Pagamento Minore leggibili le tabelle delle
M57 Inserire Pagamento Uguale successive metriche, nelle quali
M58 Generare Chiave Automaticamente
M59 Consolidare Automaticamente Finanziamento verrà usato il codice al posto del
M60 Controllare Consistenza Creazione Impegno Senza Prenotazione nome del modulo

Caso di studio Ingegneria del Software II 126


Caso di studio Ingegneria del Software II 127
DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: NMOD
VALORE RILEVATO: 60

Caso di studio Ingegneria del Software II 128


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: T
VALORE RILEVATO:

TIPOLOGIA
Controllo
Afferente
Efferente
Trasformazione
Data Banker

Caso di studio Ingegneria del Software II 129


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: TAV
VALORE RILEVATO:

TAVOLA
Finanziamenti
Entrate
Prenotazioni
Impegni
Pagamenti
Finanziamenti Entrate
Finanziamenti Prenotazioni
Prenotazioni Impegni
Impegni Pagamenti

Caso di studio Ingegneria del Software II 130


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SD
VALORE RILEVATO:

STRUTTURA DATI
db_request
db_result
JoinTab
INS_RIC
Metadati
MOD_CANC_RIC
RIC
TipoValuta

Caso di studio Ingegneria del Software II 131


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: S
VALORE RILEVATO:

CODICE SEGRETO
S1 algoritmo di conversione valuta (Euro-Lire)
S2 algoritmo per la generazione automatica della chiave di un record
S3 D.B.M.S. usato
S4 gestione della situazione di un aumento di un impegno e della prenotazione che non riesce a coprirlo
S5 gestione dell'interfaccia grafica
S6 gestione messaggistica di errore
S7 metodo per il calcolo della disponibilità di cassa non impegnata
S8 metodo per il calcolo della parte di prenotazione non impegnata
S9 metodo per il calcolo della situazione economica e finanziaria
S10 metodo per il consolidamento automatico di un finanziamento
S11 metodo per il consolidamento automatico di una entrata
S12 metodo per il consolidamento automatico di una prenotazione
S13 metodo per il consolidamento manuale di un finanziamento
S14 metodo per il consolidamento manuale di una prenotazione
S15 metodo per la cancellazione di un finanziamento
S16 metodo per la cancellazione di un impegno
S17 metodo per la cancellazione di una entrata
S18 metodo per la cancellazione di una prenotazione
S19 metodo per la modifica di un finanziamento
S20 metodo per la modifica di un impegno
S21 metodo per la modifica di una entrata
S22 metodo per la modifica di una prenotazione
S23 metodo per l'aggiornamento della situazione economica e finanziaria
S24 metodo per l'individuazione delle scadenze
S25 metodo per l'inserimento di un nuovo finanziamento
S26 metodo per l'inserimento di un nuovo impegno
S27 metodo per l'inserimento di un nuovo pagamento quando l'importo è uguale all'impegno
S28 metodo per l'inserimento di un nuovo pagamento quando l'importo è maggiore dell'impegno
S29 metodo per l'inserimento di un nuovo pagamento quando l'importo è minore dell'impegno
S30 metodo per l'inserimento di una nuova entrata
S31 metodo per l'inserimento di una nuova prenotazione
S32 modalità di presentazione dati richiesti per la navigazione degli impegni
S33 modalità di presentazione dati richiesti per la navigazione dei finanziamenti
S34 modalità di presentazione dati richiesti per la navigazione dei pagamenti
S35 modalità di presentazione dati richiesti per la navigazione delle entrate
S36 modalità di presentazione dati richiesti per la navigazione delle prenotazioni
S37 modalità di presentazione dati richiesti per la variazione degli impegni
S38 modalità di presentazione dati richiesti per la variazione dei finanziamenti
S39 modalità di presentazione dati richiesti per la variazione delle entrate
S40 modalità di presentazione dati richiesti per la variazione delle prenotazioni
S41 modalità di presentazione dati richiesti per l'inserimento degli impegni
S42 modalità di presentazione dati richiesti per l'inserimento dei finanziamenti
S43 modalità di presentazione dati richiesti per l'inserimento dei pagamenti
S44 modalità di presentazione dati richiesti per l'inserimento delle entrate
S45 modalità di presentazione dati richiesti per l'inserimento delle prenotazioni
S46 modalità di presentazione finanziamenti consolidabili manualmente
S47 modalità di presentazione prenotazioni consolidabili manualmente
S48 operazioni da eseguire al lancio del sistema
S49 ricerca entrate e modalità di presentazione risultati
S50 ricerca finanziamenti e modalità di presentazione risultati
S51 ricerca impegni e modalità di presentazione risultati
S52 ricerca pagamenti e modalità di presentazione risultati
S53 ricerca prenotazioni e modalità di presentazione risultati
S54 accesso ai metadati
S55 accesso ai servizi offerti dal data banker

NOTE: viene indicato anche il codice in modo da rendere più leggibili le tabelle delle successive metriche, nelle quali
verrà usato il codice al posto del nome del segreto

Caso di studio Ingegneria del Software II 132


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: MxS
VALORE RILEVATO: (le righe contengono i segreti, le colonne i moduli)

M10

M12

M13

M14

M15

M16

M17

M18

M19

M20

M21

M22

M23

M24
M11
M1

M2

M3

M4

M5

M6

M7

M8

M9
S1 x
S2
S3
S4
S5
S6
S7 x
S8 x
S9 x
S10
S11 x
S12 x
S13 x
S14 x
S15 x
S16 x
S17 x
S18 x
S19 x
S20 x
S21 x
S22 x
S23 x
S24 x
S25 x
S26 x
S27
S28 x
S29
S30 x
S31 x
S32
S33
S34
S35
S36
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 133


M37
M25

M26

M27

M28

M29

M30

M31

M32

M33

M34

M35

M36

M38

M39

M40

M41

M42

M43

M44

M45

M46

M47

M48

M49

M50
S1
S2
S3 x x x x
S4 x
S5 x
S6 x
S7
S8
S9
S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26
S27
S28
S29
S30
S31
S32
S33
S34
S35
S36
S37 x
S38 x
S39 x
S40 x
S41 x
S42 x
S43 x
S44 x
S45 x
S46 x
S47 x
S48 x
S49 x
S50 x
S51 x
S52 x
S53 x
S54 x
S55 x

Caso di studio Ingegneria del Software II 134


M51

M52

M53

M54

M55

M56

M57

M58

M59

M60
S1
S2 x
S3
S4
S5
S6
S7
S8
S9
S10 x
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26 x
S27 x
S28
S29 x
S30
S31
S32 x
S33 x
S34 x
S35 x
S36 x
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 135


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: MxT
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tipologie)
Controllo Afferente Efferente Trasformazione Data Banker
M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x
M16 x
M17 x
M18 x
M19 x
M20 x
M21 x
M22 x
M23 x
M24 x
M25 x
M26 x
M27 x
M28 x
M29 x
M30 x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37 x
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50 x
M51 x
M52 x
M53 x
M54 x
M55 x
M56 x
M57 x
M58 x
M59 x
M60 x

Caso di studio Ingegneria del Software II 136


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SDxM
VALORE RILEVATO: (le righe contengono i moduli, le colonne le strutture dati)

INS_RIC
db_result

Metadati

CANC_
JoinTab
request

MOD_

Valuta
Tipo
RIC

RIC
db_

M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x
M16 x
M17 x
M18 x
M19 x
M20 x
M21
M22 x
M23 x
M24 x
M25 x
M26 x x
M27 x
M28 x x
M29 x x
M30 x x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50
M51 x
M52 x
M53 x
M54 x
M55 x
M56 x
M57 x
M58
M59 x

Caso di studio Ingegneria del Software II 137


M60 x

DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: MxTAV
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tavole)
menti
Finanzia

Entrate

zioni
Prenota

Impegni

ti
Pagamen

Entrate
menti
Finanzia
zioni
Prenota
menti
Finanzia

Impegni
zioni
Prenota

ti
Pagamen
Impegni
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
M11
M12
M13
M14
M15
M16
M17
M18
M19
M20
M21
M22
M23
M24
M25
M26
M27
M28
M29
M30
M31
M32
M33
M34
M35
M36
M37
M38
M39
M40
M41
M42
M43 NOTE: l'assenza di
M44 corrispondenze è dovuta
M45 all'uso del data banker
M46 per l'accesso ai dati nel
M47
M48 sistema: infatti, il data
M49 banker è implementato
M50 in modo da costruire
M51 automaticamente, sulla
M52 base dei metadati, le
M53
M54
richieste per l'accesso al
M55 database.
M56
M57
M58
M59

Caso di studio Ingegneria del Software II 138


M60

DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DI
VALORE RILEVATO:

M1 3
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 2
M14 1
M15 2
M16 2
M17 3
M18 2
M19 3
M20 3
M21 2
M22 2
M23 0
M24 1
M25 1
M26 3
M27 2
M28 2
M29 4
M30 0
M31 0
M32 0
M33 0
M34 0
M35 2
M36 0
M37 1
M38 0
M39 0
M40 0
M41 0
M42 0
M43 1
M44 1
M45 1
M46 1
M47 1
M48 0
M49 0
M50 1
M51 0
M52 0
M53 0
M54 0
M55 0
M56 2
M57 2
M58 2
M59 1
M60 2

Caso di studio Ingegneria del Software II 139


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DO
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 0
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 2
M32 2
M33 2
M34 2
M35 1
M36 2
M37 1
M38 0
M39 1
M40 1
M41 1
M42 1
M43 0
M44 0
M45 0
M46 0
M47 0
M48 1
M49 1
M50 0
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 140


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CI
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 1
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 141


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CO
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 142


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GD
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 143


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GC
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 144


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: FANIN
VALORE RILEVATO:

M1 9
M2 3
M3 4
M4 1
M5 3
M6 1
M7 1
M8 2
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 2
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 20
M25 48
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 4
M38 0
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 2
M59 1
M60 1

Caso di studio Ingegneria del Software II 145


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: FANOUT
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 2
M5 3
M6 1
M7 2
M8 2
M9 2
M10 1
M11 2
M12 1
M13 2
M14 1
M15 4
M16 1
M17 2
M18 1
M19 2
M20 1
M21 3
M22 5
M23 1
M24 0
M25 4
M26 2
M27 1
M28 1
M29 2
M30 17
M31 2
M32 1
M33 2
M34 2
M35 1
M36 2
M37 0
M38 24
M39 2
M40 2
M41 2
M42 2
M43 2
M44 2
M45 2
M46 2
M47 2
M48 1
M49 1
M50 0
M51 2
M52 2
M53 2
M54 2
M55 2
M56 3
M57 3
M58 0
M59 2
M60 4

Caso di studio Ingegneria del Software II 146


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: ACC
VALORE RILEVATO:

M1 0.928
M2 0.833
M3 0.857
M4 0.666
M5 0.875
M6 0.750
M7 0.800
M8 0.833
M9 0.800
M10 0.750
M11 0.800
M12 0.750
M13 0.833
M14 0.750
M15 0.875
M16 0.833
M17 0.857
M18 0.800
M19 0.857
M20 0.833
M21 0.857
M22 0.888
M23 0.500
M24 0.958
M25 0.981
M26 0.857
M27 0.800
M28 0.800
M29 0.875
M30 0.947
M31 0.800
M32 0.750
M33 0.800
M34 0.800
M35 0.800
M36 0.800
M37 0.833
M38 0.956
M39 0.750
M40 0.750
M41 0.750
M42 0.750
M43 0.750
M44 0.750
M45 0.750
M46 0.750
M47 0.750
M48 0.666
M49 0.666
M50 0.500
M51 0.750
M52 0.750
M53 0.750
M54 0.750
M55 0.750
M56 0.857
M57 0.857
M58 0.800
M59 0.800
M60 0.875

Caso di studio Ingegneria del Software II 147


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: TM
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 148


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: SN
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 0
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 149


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MNS
VALORE RILEVATO:

S1 1
S2 1
S3 4
S4 1
S5 1
S6 1
S7 1
S8 1
S9 1
S10 1
S11 1
S12 1
S13 1
S14 1
S15 1
S16 1
S17 1
S18 1
S19 1
S20 1
S21 1
S22 1
S23 1
S24 1
S25 1
S26 2
S27 1
S28 1
S29 1
S30 1
S31 1
S32 1
S33 1
S34 1
S35 1
S36 1
S37 1
S38 1
S39 1
S40 1
S41 1
S42 1
S43 1
S44 1
S45 1
S46 1
S47 1
S48 1
S49 1
S50 1
S51 1
S52 1
S53 1
S54 1
S55 1

Caso di studio Ingegneria del Software II 150


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MDS
VALORE RILEVATO:

db_request 1
db_result 48
JoinTab 3
INS_RIC 1
Metadati 4
MOD_CANC_RIC 1
RIC 1
TipoValuta 1

NOTE: il valore 48 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 151


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MTS
VALORE RILEVATO:

Finanziamenti 0
Entrate 0
Prenotazioni 0
Impegni 0
Pagamenti 0
Finanziamenti Entrate 0
Finanziamenti Prenotazioni 0
Prenotazioni Impegni 0
Impegni Pagamenti 0

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema: infatti, il data banker
è implementato in modo da costruire automaticamente, sulla base dei metadati, le richieste per l'accesso al database.

Caso di studio Ingegneria del Software II 152


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT5NF
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 153


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 154


DATA DI CONSEGNA: 09/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: PT5NF
VALORE RILEVATO: 1

Caso di studio Ingegneria del Software II 155


DATA DI CONSEGNA: 13/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: MxMMODRIUS
VALORE RILEVATO:

CODICE MODULO MODIFICATO RIUSATO


M1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa x
M2 Calcolare Disponibilità di Cassa Non Impegnata x
M3 Calcolare Prenotazione Non Impegnata x
M4 Calcolare Situazione Eco./Fin. x
M5 Consolidare Automaticamente Prenotazione x
M6 Consolidare Entrate x
M7 Consolidare Manualmente Finanziamento x
M8 Consolidare Manualmente Prenotazione x
M9 Controllare Consistenza Cancellazione Entrata x
M10 Controllare Consistenza Cancellazione Finanziamento x
M11 Controllare Consistenza Cancellazione Impegno x
M12 Controllare Consistenza Cancellazione Prenotazione x
M13 Controllare Consistenza Creazione Entrata x
M14 Controllare Consistenza Creazione Finanziamento x
M15 Controllare Consistenza Creazione Impegno x x
M16 Controllare Consistenza Creazione Prenotazione x
M17 Controllare Consistenza Modifica Entrata x
M18 Controllare Consistenza Modifica Finanziamento x
M19 Controllare Consistenza Modifica Impegno x
M20 Controllare Consistenza Modifica Prenotazione x
M21 Controllare Consistenza Creazione Pagamento x
M22 Inserire Pagamento Maggiore x
M23 Controllare Scadenze x
M24 Convertire Valuta x
M25 Data Banker x x
M26 Data Banker Create x
M27 Data Banker Delete x
M28 Data Banker Read x
M29 Data Banker Update x x
M30 Gestire Schermate x
M31 Inserire Entrata x
M32 Inserire Finanziamento x
M33 Inserire Impegno x
M34 Inserire Pagamento x
M35 Inserire Pagamento Prenotazione Esaurita x
M36 Inserire Prenotazione x
M37 Leggere Metadati x
M38 Main x x
M39 Modificare/Cancellare Entrata x
M40 Modificare/Cancellare Finanziamento x
M41 Modificare/Cancellare Impegno x
M42 Modificare/Cancellare Prenotazione x
M43 Navigare Entrate x
M44 Navigare Finanziamenti x
M45 Navigare Impegni x
M46 Navigare Pagamenti x
M47 Navigare Prenotazioni x
M48 Selezionare Finanziamento da Consolidare x
M49 Selezionare Prenotazione da Consolidare x
M50 Trattare Errore x
M51 Acquisire Parametri Navigazione Finanziamenti x
M52 Acquisire Parametri Navigazione Entrate x
M53 Acquisire Parametri Navigazione Prenotazioni x
M54 Acquisire Parametri Navigazione Impegni x
M55 Acquisire Parametri Navigazione Pagamenti x
M56 Inserire Pagamento Minore x
M57 Inserire Pagamento Uguale x
M58 Generare Chiave Automaticamente x
M59 Consolidare Automaticamente Finanziamento x
M60 Controllare Consistenza Inserimento Impegno Senza Prenotazione x x

Caso di studio Ingegneria del Software II 156


DATA DI CONSEGNA: 13/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: NMMOD
VALORE RILEVATO: 5

NOTE: Il modulo Inserire Pagamento Maggiore, nonostante sia indicato nella Scheda descrizione degli interventi
(pagina 181), non è stato sottoposto a modifiche (come si nota nella misurazione della metrica MxMMODRIUS a
pagina 156), in quanto si è ritenuto che modifiche tese a diminuire l'accoppiamento avrebbero comportato il
peggioramento della coesione del modulo stesso sia dei possibili moduli derivanti da un'esplosione del modulo,
andando quindi contro quanto indicato nel processo di sviluppo software migliorato (pagina 191)..

Caso di studio Ingegneria del Software II 157


DATA DI CONSEGNA: 13/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: NMRIUS
VALORE RILEVATO: 60

Caso di studio Ingegneria del Software II 158


DATA DI CONSEGNA: 13/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: PERMMOD
VALORE RILEVATO: 0.08

Caso di studio Ingegneria del Software II 159


DATA DI CONSEGNA: 13/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,7
METRICA: PERMRIUS
VALORE RILEVATO: 1

Caso di studio Ingegneria del Software II 160


Distanze dagli obiettivi
INDICE DELLE METRICHE:
CI pag. 162
CO pag. 163
FANIN pag. 166
ACC pag. 167
GC pag. 165
GD pag. 164
MDS pag. 171
MNS pag. 170
MTS pag. 172
PT5NF pag. 173
SN pag. 169
TM pag. 168

NOTE:

• una distanza pari a 0 indica il raggiungimento della baseline hypothesis; un valore diverso invece quantifica la
distanza tra il valore rilevato e la baseline hypothesis

• una distanza pari a nessuna indica il raggiungimento della baseline hypothesis

• una distanza pari a rientra indica che il valore rilevato è migliore di quello indicato nella baseline hypothesis

• le distanze segnate in grassetto indicano le metriche che non hanno raggiunto le baseline hypothesis (cioè il valore
rilevato è peggiore)

• per alcune metriche è indicato eccezione, ovvero il valore rilevato è peggiore della baseline hypothesis ma si ritiene
che la metrica abbia dato risultati positivi per i motivi spiegati nelle note o tra le distanze stesse

Caso di studio Ingegneria del Software II 161


METRICA: CI
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 0
M2 0 0
M3 0 0
M4 0 0
M5 0 0
M6 0 0
M7 0 0
M8 0 0
M9 0 0
M10 0 0
M11 0 0
M12 0 0
M13 0 0
M14 0 0
M15 0 0
M16 0 0
M17 0 0
M18 0 0
M19 0 0
M20 0 0
M21 0 0
M22 0 0
M23 0 0
M24 1 1
M25 0 0
M26 0 0
M27 0 0
M28 0 0
M29 0 0
M30 0 0
M31 0 0
M32 0 0
M33 0 0
M34 0 0
M35 0 0
M36 0 0
M37 0 0
M38 0 0
M39 0 0
M40 0 0
M41 0 0
M42 0 0
M43 0 0
M44 0 0
M45 0 0
M46 0 0
M47 0 0
M48 0 0
M49 0 0
M50 0 0
M51 0 0
M52 0 0
M53 0 0
M54 0 0
M55 0 0
M56 0 0
M57 0 0
M58 0 0
M59 0 0
M60 0 0

NOTE: il numero di moduli con CI pari a 1 è uguale a 1, quindi essendo al di sotto del 5% dei moduli del sistema, la
baseline hypothesis è stata raggiunta.

Caso di studio Ingegneria del Software II 162


METRICA: CO
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 163


METRICA: GD
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 164


METRICA: GC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 165


METRICA: FANIN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 9 nessuna (r.i.)
M2 3 nessuna (r.i.)
M3 4 nessuna (r.i.)
M4 1 nessuna (g.)
M5 3 nessuna (r.i.)
M6 1 nessuna (g.)
M7 1 nessuna (g.)
M8 2 nessuna (g.)
M9 1 nessuna (g.)
M10 1 nessuna (g.)
M11 1 nessuna (g.)
M12 1 nessuna (g.)
M13 1 nessuna (g.)
M14 1 nessuna (g.)
M15 1 nessuna (g.)
M16 2 nessuna (g.)
M17 1 nessuna (g.)
M18 1 nessuna (g.)
M19 1 nessuna (g.)
M20 1 nessuna (g.)
M21 1 nessuna (g.)
M22 1 nessuna (g.)
M23 1 nessuna (g.)
M24 20 nessuna (r.e.)
M25 48 nessuna (r.e.)
M26 1 nessuna (g.)
M27 1 nessuna (g.)
M28 1 nessuna (g.)
M29 1 nessuna (g.)
M30 1 nessuna (g.)
M31 1 nessuna (g.)
M32 1 nessuna (g.)
M33 1 nessuna (g.)
M34 1 nessuna (g.)
M35 1 nessuna (g.)
M36 1 nessuna (g.)
M37 4 nessuna (r.i.)
M38 0 nessuna (g.)
M39 1 nessuna (g.)
M40 1 nessuna (g.)
M41 1 nessuna (g.)
M42 1 nessuna (g.)
M43 1 nessuna (g.)
M44 1 nessuna (g.)
M45 1 nessuna (g.)
M46 1 nessuna (g.)
M47 1 nessuna (g.)
M48 1 nessuna (g.)
M49 1 nessuna (g.)
M50 1 nessuna (g.)
M51 1 nessuna (g.)
M52 1 nessuna (g.)
M53 1 nessuna (g.)
M54 1 nessuna (g.)
M55 1 nessuna (g.)
M56 1 nessuna (g.)
M57 1 nessuna (g.)
M58 2 nessuna (g.)
M59 1 nessuna (g.)
M60 1 nessuna (g.)

NOTE: Le sigle r.i., r.e. e g. sono le abbreviazioni di riusabile internamente, riusabile esternamente e generico

Caso di studio Ingegneria del Software II 166


METRICA: ACC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0.928 eccezione (FANIN alto)
M2 0.857 rientra
M3 0.857 rientra
M4 0.666 rientra
M5 0.875 eccezione (FANIN alto)
M6 0.750 rientra
M7 0.800 rientra
M8 0.833 rientra
M9 0.800 rientra
M10 0.750 rientra
M11 0.800 rientra
M12 0.750 rientra
M13 0.833 rientra
M14 0.750 rientra
M15 0.875 0.015
M16 0.833 rientra
M17 0.857 rientra
M18 0.800 rientra
M19 0.857 rientra
M20 0.833 rientra
M21 0.857 rientra
M22 0.888 0.028
M23 0.500 rientra
M24 0.958 eccezione (FANIN alto)
M25 0.981 eccezione (FANIN alto)
M26 0.857 rientra
M27 0.800 rientra
M28 0.800 rientra
M29 0.875 0.015
M30 0.947 eccezione (modulo di controllo)
M31 0.800 rientra
M32 0.750 rientra
M33 0.800 rientra
M34 0.800 rientra
M35 0.800 rientra
M36 0.800 rientra
M37 0.833 rientra
M38 0.958 eccezione (modulo di controllo)
M39 0.750 rientra
M40 0.750 rientra
M41 0.750 rientra
M42 0.750 rientra
M43 0.750 rientra
M44 0.750 rientra
M45 0.750 rientra
M46 0.750 rientra
M47 0.750 rientra
M48 0.666 rientra
M49 0.666 rientra
M50 0.500 rientra
M51 0.750 rientra
M52 0.750 rientra
M53 0.750 rientra
M54 0.750 rientra
M55 0.750 rientra
M56 0.857 rientra
M57 0.857 rientra
M58 0.800 rientra
M59 0.800 rientra
M60 0.875 0.015

Caso di studio Ingegneria del Software II 167


METRICA: TM
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 1 nessuna
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 1 nessuna
M44 1 nessuna
M45 1 nessuna
M46 1 nessuna
M47 1 nessuna
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna
M51 1 nessuna
M52 1 nessuna
M53 1 nessuna
M54 1 nessuna
M55 1 nessuna
M56 1 nessuna
M57 1 nessuna
M58 1 nessuna
M59 1 nessuna
M60 1 nessuna

Caso di studio Ingegneria del Software II 168


METRICA: SN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 0 rientra
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 1 nessuna
M44 1 nessuna
M45 1 nessuna
M46 1 nessuna
M47 1 nessuna
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna
M51 1 nessuna
M52 1 nessuna
M53 1 nessuna
M54 1 nessuna
M55 1 nessuna
M56 1 nessuna
M57 1 nessuna
M58 1 nessuna
M59 1 nessuna
M60 1 nessuna

Caso di studio Ingegneria del Software II 169


METRICA: MNS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
S1 1 nessuna
S2 1 nessuna
S3 4 nessuna
S4 1 nessuna
S5 1 nessuna
S6 1 nessuna
S7 1 nessuna
S8 1 nessuna
S9 1 nessuna
S10 1 nessuna
S11 1 nessuna
S12 1 nessuna
S13 1 nessuna
S14 1 nessuna
S15 1 nessuna
S16 1 nessuna
S17 1 nessuna
S18 1 nessuna
S19 1 nessuna
S20 1 nessuna
S21 1 nessuna
S22 1 nessuna
S23 1 nessuna
S24 1 nessuna
S25 1 nessuna
S26 2 nessuna
S27 1 nessuna
S28 1 nessuna
S29 1 nessuna
S30 1 nessuna
S31 1 nessuna
S32 1 nessuna
S33 1 nessuna
S34 1 nessuna
S35 1 nessuna
S36 1 nessuna
S37 1 nessuna
S38 1 nessuna
S39 1 nessuna
S40 1 nessuna
S41 1 nessuna
S42 1 nessuna
S43 1 nessuna
S44 1 nessuna
S45 1 nessuna
S46 1 nessuna
S47 1 nessuna
S48 1 nessuna
S49 1 nessuna
S50 1 nessuna
S51 1 nessuna
S52 1 nessuna
S53 1 nessuna
S54 1 nessuna
S55 1 nessuna

Caso di studio Ingegneria del Software II 170


METRICA: MDS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
db_request 1 rientra
db_result 48 eccezione (vedere note)
JoinTab 3 rientra
INS_RIC 1 rientra
Metadati 4 rientra
MOD_CANC_RIC 1 rientra
RIC 1 rientra
TipoValuta 1 rientra

NOTE: il valore 48 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 171


METRICA: MTS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
Finanziamenti 0 rientra
Entrate 0 rientra
Prenotazioni 0 rientra
Impegni 0 rientra
Pagamenti 0 rientra
Finanziamenti Entrate 0 rientra
Finanziamenti Prenotazioni 0 rientra
Prenotazioni Impegni 0 rientra
Impegni Pagamenti 0 rientra

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema.

Caso di studio Ingegneria del Software II 172


METRICA: PT5NF
VALORE RILEVATO: 1
DISTANZA DALLA BASELINE HYPHOTESIS: nessuna

Caso di studio Ingegneria del Software II 173


Ipotesi di variazione dei fogli metrici
Baseline Hypothesis (II Quadrante)

• Per la metrica CI, avendo rilevato valori migliori della precedente baseline hypothesis, si ritiene che la sua nuova
baseline hypothesis possa essere sostituita con:

CI: massimo 1 per il 2% dei moduli del sistema


pari a 0 per il restante 98%;

• Per la metrica MTS, avendo rilevato valori migliori della precedente baseline hypothesis, si ritiene che la sua nuova
baseline hypothesis possa essere sostituita con:

MTS: pari a 0 per tutte le tavole del sistema;

• Per la metrica MDS, avendo rilevato valori migliori della precedente baseline hypothesis, si ritiene che la sua nuova
baseline hypothesis possa essere sostituita con:

MDS: massimo 4 per tutte le strutture dati escluse quelle che fanno parte
dell'interfaccia delle componenti riusabili del sistema;

Fattori di variazione (III Quadrante)

• Aggiungere il seguente fattore di variazione

• esperienza del team di progetto nel miglioramento della qualità del sistema
Metriche influenzate: TM, SN, ACC

Impatto sulle Baseline Hypothesis (IV Quadrante)

• Aggiungere il seguente impatto:

• esperienza del team di progetto nel miglioramento della qualità del sistema

 la maggiore esperienza del team di progetto nell'applicazione delle euristiche e dei principi
dell'information hiding prestando attenzione che l'applicazione di una euristica o di un principio non
vada in conflitto con altri, comporta la riduzione del rischio che interventi tesi a migliorare una metrica
producano come effetto collaterale il peggioramento di altri (TM, SN, ACC)

Caso di studio Ingegneria del Software II 174


Fogli metrici

Indice dei fogli metrici


Goal G1 pag. 176

NOTE:

Questa versione dei fogli metrici è stata prodotta durante l'esecuzione dell'attività 1.4 (Produrre i fogli metrici) a causa
della presenza delle Ipotesi di variazione dei fogli metrici

Caso di studio Ingegneria del Software II 175


OGGETTO SCOPO OBIETTIVO DI QUALITÀ PUNTO DI VISTA CONTESTO
G1 sistema software GEFIN D.F. migliorare information hiding ingegnere del software corso di Ingegneria del
Software II
QUALITY FOCUS FATTORI DI VARIAZIONE
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) Metriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC
accoppiamento di un modulo
DI numero di parametri-dato di input al modulo • esperienza del team di progetto nella progettazione delle interfacce tra le singole
DO numero di parametri-dato di output del modulo componenti del sistema
CI numero di parametri di controllo di input al modulo Metriche influenzate: MDS, ACC, GD, GC
CO numero di parametri di controllo di output del modulo
GD numero di variabili globali utilizzate come dati nel modulo • esperienza del team di progetto nella progettazione delle basi di dati
GC numero di variabili globali utilizzate per controllo dal modulo Metriche influenzate: PT5NF
FANIN numero di moduli che richiamano il modulo
FANOUT numero di moduli richiamati dal modulo
• esperienza del team di progetto nel miglioramento della qualità del sistema
Metriche influenzate: TM, SN, ACC
TM: distribuzione della tipologia dei moduli tra i moduli del sistema

MNS: numero di moduli che nascondono un segreto

MDS: numero di moduli che conoscono la struttura di un dato

MTS: numero di moduli che conoscono la struttura di una tavola

SN: numero di segreti nascosti per modulo

PT5NF = NT5NF / NT : normalizzazione della base di dati


NT5NF: numero di tavole in 5NF presenti nel database
NT: numero di tavole presenti nel database

- Riusabilità:

SN: numero di segreti nascosti per modulo

FANIN: numero di moduli che usano un modulo

Caso di studio Ingegneria del Software II 176


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS
- Modularità: • esperienza del team di progetto nella progettazione della struttura del sistema

ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di  la maggiore esperienza nel ripartire la struttura del sistema secondo le funzioni principali
svolte, comporta una migliore distribuzione della tipologia dei moduli (basso valore di TM);
controllo per i quali valori vicini a 1 sono accettabili;
in particolare, delegando l'accesso ai dati a una sola tipologia di moduli si riduce al minimo il
numero di moduli che conoscono le singole componenti della base di dati (MTS)
CI: massimo 1 per il 2% dei moduli del sistema
pari a 0 per il restante 98%;  la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate
CO: pari a 0 per tutti i moduli del sistema; comporta un basso numero di segreti nascosti dallo stesso modulo (SN) oltre che
GD: pari a 0 per tutti i moduli del sistema; l'abbassamento del numero di moduli che conoscono lo stesso segreto (MNS)
GC: pari a 0 per tutti i moduli del sistema;
 la maggiore esperienza nel progettare moduli che implementano una singola funzione
comporta la diminuzione dell'interconnessione tra i moduli, e quindi dell'accoppiamento
TM: pari a 1 per tutti i moduli del sistema; (ACC), in particolare diminuisce la necessità dell'uso di dati di controllo (CO, CI e GC)

MNS: massimo 4 per tutti i segreti;  la maggiore esperienza nell'identificare nei moduli del sistema funzioni ricorrenti più volte,
nell'estrarre queste funzioni e nell'inserire ognuna di esse in singoli moduli, comporta
l'aumento del fan-in di questi moduli (FANIN)
MDS: massimo 4 per tutte le strutture dati escluse quelle che fanno parte
dell'interfaccia delle componenti riusabili del sistema; • esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti del
sistema
MTS: pari a 0 per tutte le tavole del sistema;
 la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di
SN: massimo 1 per tutti i moduli del sistema; controllo (mediante chiamata/sincronizzazione) o allo scambio (in input/output) dei soli dati
necessari, comporta la diminuzione dell'accoppiamento dei moduli (ACC). Inoltre se i dati
scambiati sono dati elementari e non strutture dati, si ottiene la diminuzione del numero di
PT5NF: pari a 1; moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi moduli

- Riusabilità:  la maggiore esperienza nel limitare la possibilità di scambio di dati tra i moduli al solo uso
della loro interfaccia, comporta la diminuzione della necessità di usare variabili globali (GD
SN: pari a 1 per tutti i moduli del sistema; e GC) e quindi la diminuzione dell'accoppiamento dei moduli (ACC)

• esperienza del team di progetto nella progettazione delle basi di dati


FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili
esternamente; compreso tra il 5% e il 30% dei moduli del sistema  la maggiore esperienza nel metodo della decomposizione senza perdita o nell'uso del data
per i moduli riusabili internamente; minore del 5% dei moduli del modelling comporta una migliore normalizzazione della base di dati (PT5NF)
sistema per i moduli generici
• esperienza del team di progetto nel miglioramento della qualità del sistema

 la maggiore esperienza del team di progetto nell'applicazione delle euristiche e dei


principi dell'information hiding prestando attenzione che l'applicazione di una euristica o di
un principio non vada in conflitto con altri, comporta la riduzione del rischio che interventi
tesi a migliorare una metrica producano come effetto collaterale il peggioramento di altri
(TM, SN, ACC)

Caso di studio Ingegneria del Software II 177


Punti di debolezza

FOGLIO METRICO PUNTO DI DEBOLEZZA METRICHE CARENTI


G1 Modularità ACC

Caso di studio Ingegneria del Software II 178


Fattori di variazione

FOGLIO METRICO PUNTO DI DEBOLEZZA METRICHE CARENTI FATTORI DI VARIAZIONE

• esperienza del team di progetto nella


ACC progettazione della struttura del
sistema
G1 Modularità
• esperienza del team di progetto nella
ACC progettazione delle interfacce tra le
singole componenti

Caso di studio Ingegneria del Software II 179


Ipotesi di miglioramento del sistema software

Il sistema GEFIN D.F. presenta come punto di debolezza la modularità. Al fine di migliorare la qualità del sistema, i
possibili interventi da effettuare su di esso sono i seguenti:

 al fine di ridurre l'accoppiamento dei moduli del sistema, è necessario intervenire sui singoli moduli ad alto
accoppiamento (superiore al valore 0.860) ed eventualmente su tutti i moduli interconnessi. Per ridurre
l'accoppiamento di un modulo sono possibili due tipi di interventi: ristrutturazione dell'interfaccia tra i moduli e
ristrutturazione interna del modulo stesso. Per il primo intervento è necessario verificare la necessità di tutti i dati
passati al modulo come parametri e la necessità di tutti i dati restituiti dal modulo. Se il numero di dati passati è
elevato e questi dati sono "collegati" tra loro, è possibile sostituirli con una struttura. Per il secondo intervento è
necessario verificare che il modulo svolga un'unica funzione. In caso contrario è necessario dividere il modulo in
moduli dedicati ad un'unica funzione. In questo modo è anche possibile che il gran numero di dati passati al/dal
modulo originario sia distribuito ai moduli derivanti dalla sua divisione. Controllare anche che i moduli derivanti
dall'esplosione di un modulo rispettino quanto sopra indicato e che per tutti i moduli modificati in altri tipi di
interventi venga verificato quanto sopra indicato.

Caso di studio Ingegneria del Software II 180


Scheda descrizione degli interventi
COMPONENTE DEL SISTEMA TIPOLOGIA DI INTERVENTO
Modulo Controllare • revisione struttura interna del modulo
Consistenza Creazione
Impegno • revisione dell'interfaccia del modulo
Modulo Inserire Pagamento • revisione dell'interfaccia del modulo
Maggiore
• revisione struttura interna del modulo
Modulo Data Banker Update • revisione dell'interfaccia del modulo

Modulo Controllare • revisione struttura interna del modulo


Consistenza Creazione
Impegno Senza Prenotazione • revisione struttura interna del modulo

Structure Chart • revisione della struttura del sistema (structure chart e call graph)

• aggiornamento e integrazione dei possibili nuovi moduli (structure


chart e call graph)
Dizionario dei dati (progetto) • aggiornamento e integrazione delle possibili nuove strutture dati

Matrice Cross Reference • aggiornamento e integrazione delle possibili nuove componenti nella
RExDS matrice cross reference RExDS

Documenti di progetto • aggiornamento di tutta la documentazione di progetto al fine di


allinearla e renderla tracciabile con le modifiche effettuate

Codice sorgente • modifiche ai moduli del codice sogente interessati dalle modifiche al
progetto

• implementazione dei moduli e delle strutture dati eventualmente


aggiunti al progetto
Codice oggetto • ricompilazione del programma

Caso di studio Ingegneria del Software II 181


Specifiche delle modifiche

INDICE DEI PIANI ESECUTIVI:


Piano esecutivo 1 pag. 183
Piano esecutivo 2 pag. 186
Piano esecutivo 3 pag. 189

NOTE:
La descrizione completa del processo di sviluppo software è presente nell'Appendice A a pagina 324. Inoltre si è
considerato il processo di sviluppo software aggiornato mediante i manufatti Miglioramento del processo di sviluppo
software prodotti nelle esecuzioni precedenti.

Caso di studio Ingegneria del Software II 182


Piano esecutivo 1

TIPOLOGIE DI INTERVENTI COPERTI:


T1 - revisione struttura interna del modulo
T2 - revisione dell'interfaccia del modulo
T4 - revisione della struttura del sistema (structure chart e call graph)
T5 - aggiornamento e integrazione dei possibili nuovi moduli (structure chart e call graph)
T6 - aggiornamento e integrazione delle possibili nuove componenti nella matrice cross reference RExDS
T7 - aggiornamento di tutta la documentazione di progetto al fine di allinearla e renderla tracciabile con le
modifiche effettuate

COMPONENTI DEL SISTEMA INTERESSATE DALL'INTERVENTO:


Modulo Controllare Consistenza Creazione Impegno (T1, T2)
Modulo Inserire Pagamento Maggiore (T1, T2)
Modulo Data Banker Update (T2)
Modulo Controllare Consistenza Creazione Impegno Senza Prenotazione (T1, T2)
Structure Chart (T4, T5)
Matrice Cross Reference RexDS (T6)
Documenti di progetto (T7)

WORK FLOW DIAGRAM:

START

Rifinire la structure chart e le


specifiche dei moduli
2.5

Definire le strutture dei file


esterni e dei dati globali
2.6

Costruire la cross reference


RExDS
2.8

STOP

Caso di studio Ingegneria del Software II 183


SCENARI PROCEDURALI:

2.5 Rifinire la Structure Chart e le specifiche dei moduli


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli, Structure Chart, Tavole e percorsi di navigazione

Procedura:

1. Aggiungere i moduli per la gestione dei dati


2. Migliorare la Structure Chart utilizzando le euristiche
2a. Per ogni modulo del sistema
2a.1. Verificare la necessità di tutti i dati passati al modulo come parametri e la necessità di tutti i dati
restituiti dal modulo. Se il numero di dati passati è elevato e questi dati sono "collegati" tra loro,
è possibile sostituirli con una struttura. Prestare attenzione che questo intervento non provochi
nuove carenze nel sistema o il peggioramento della qualità già raggiunta.
2a.2. Verificare che il modulo svolga un'unica funzione. In caso contrario è necessario dividere il
modulo in moduli dedicati ad un'unica funzione. In questo modo è anche possibile che il gran
numero di dati passati al/dal modulo originario sia distribuito ai moduli derivanti dalla sua
divisione. Prestare attenzione che questo intervento non provochi nuove carenze nel sistema o il
peggioramento della qualità già raggiunta.
3. Migliorare la Structure Chart secondo i principi dell'Information Hiding
3a. Per ogni modulo del sistema
3a.1. Se il numero di funzioni principali svolte dal modulo è maggiore di uno, esplodere il modulo in
modo che all'interno del sistema svolga una sola funzione principale. Spostare i moduli risultanti
dall'esplosione in aree differenti della struttura del sistema, eseguendo quindi gli interventi
necessari ad integrarli con i moduli presenti in quelle nuove aree. Prestare attenzione che questo
intervento non provochi nuove carenze nel sistema o il peggioramento della qualità già raggiunta.
3a.2. Se il numero di segreti nascosti dal modulo è maggiore di uno, esplodere il modulo in modo che
in ognuno dei moduli derivanti sia nascosto uno ed uno solo dei segreti nascosti nel modulo
originario. Prestare attenzione che questo intervento non provochi nuove carenze nel sistema o il
peggioramento della qualità già raggiunta.
4. Per ciascun modulo aggiunto
4.1 Definire la specifica semantica e la specifica sintattica
4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo
4.3 Descrivere i dati referenziati
4.4 Definire gli altri moduli che esso utilizza
4.5 Rieseguire i passi 2a.1, 2a.2, 3a.1 e 3a.2

Output: Structure Chart aggiornata, Specifiche dei moduli aggiornate

I.E.C.: Prodotti di output realizzati

2.6 Definire le strutture dei file esterni e dei dati globali


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli aggiornate, Tavole e percorsi di navigazione, Dizionario dei dati (analisi)

Procedura:

1. Individuare l'insieme di file di dati esterni


2. Per ciascun file esterno individuato
2.1 Definire la struttura logica
2.2 Descrivere i record logici
2.3 Definire la modalità di accesso
3. Individuare l'insieme dei dati globali fornendo per ciascuno di essi la struttura
4. Costruire una matrice Cross Reference che associa ciascun dato globale/file esterno al modulo che

Caso di studio Ingegneria del Software II 184


lo implementa

Output: Definizione delle strutture dei file esterni e dei dati globali

I.E.C.: Prodotti di output realizzati

2.8 Costruire la Cross Reference RExDS


I.S.C.: Prodotti di input disponibili

Input: Structure Chart aggiornata, Requisiti utente

Procedura:

1. Costruire la matrice Cross Reference per stabilire in quale parte del progetto è implementato
ciascun requisito

Output: Matrice Cross Reference RExDS

I.E.C.: Prodotti di output realizzati

DESCRIZIONE DEI MANUFATTI:

• Definizione delle strutture dei file esterni e dei dati globali: struttura logica, record logici e modalità di accesso
per ogni file esterno; struttura di ciascun dato globale; matrice Cross Reference file esterno/dato globale x modulo
che li usa

• Matrice Cross Reference RexDS: matrice usata per stabilire in quale parte del progetto è implementato ciascun
requisito

• Requisiti utente: descrizione in qualunque forma di quello che l'utente intende ottenere dal prodotto software

• Specifiche dei moduli: definizione dettagliata delle operazioni che ciascun modulo software deve eseguire

• Specifiche dei moduli aggiornate: rifinitura delle specifiche dei moduli necessaria all'allineamento con la
Structure Chart aggiornata

• Structure Chart: espressione gerarchica delle relazioni fra i moduli e delle interfacce fra ogni coppia di essi

• Structure Chart aggiornata: rifinitura della Structure Chart utilizzando le euristiche e i principi dell'Information
Hiding

• Tavole e percorsi di navigazione: struttura dell'organizzazione della base di dati e insieme di percorsi logici per
navigarla

Caso di studio Ingegneria del Software II 185


Piano esecutivo 2

TIPOLOGIE DI INTERVENTI COPERTI:


T7 - aggiornamento di tutta la documentazione di progetto al fine di allinearla e renderla tracciabile con le
modifiche effettuate
T8 - aggiornamento e integrazione delle possibili nuove strutture dati

COMPONENTI DEL SISTEMA INTERESSATE DALL'INTERVENTO:


Dizionario dei dati (progetto) (T8)
Documenti di progetto (T7)

WORK FLOW DIAGRAM:

START

Definire il dizionario dei dati


(progetto)
2.7

STOP

SCENARI PROCEDURALI:

2.7 Definire il dizionario dei dati (progetto)


I.S.C.: Prodotti di input disponibili

Input: Dizionario dei dati (analisi), Diagramma delle dipendenze, Requisiti informatici

Procedura:

1. Per ciascuna struttura dati, indicare le componenti e il relativo tipo di dato

Output: Dizionario dei dati (progetto)

I.E.C.: Prodotti di output realizzati

DESCRIZIONE DEI MANUFATTI:

• Attributi di ciascuna entità: descrizione delle caratteristiche di ciascuna entità del modello E-R

• Attributi e funzionalità di ciascuna relazione: descrizione dei legami logici tra le diverse entità del modello E-R
e delle eventuali caratteristiche dei suddetti legami

• DFDs: descrizione dei requisiti funzionali dell'applicazione software. Ogni funzione deve essere identificata; le
funzioni possono essere articolate per livelli di dettaglio successivi. Le funzioni di livello più basso sono quelle
elementari

Caso di studio Ingegneria del Software II 186


• Diagramma delle dipendenze: diagramma in cui sono indicati, per ciascun dato della base di dati, le dipendenze
rispetto agli altri dati

• Dizionario dei dati (analisi): descrizione testuale dei flussi dei DFD, dei depositi e delle entità esterne

• Dizionario dei dati (progetto): descrizione delle strutture e dei dati usati nelle specifiche dei moduli

• Documenti analisi dei requisiti: documentazione ottenuta come risultato dell'analisi dei requisiti del software e
del sistema

Composizione: DFDs +
Dizionario dei dati (analisi) +
Specifica delle funzioni elementari +
Modello E-R +
Attributi di ciascuna entità +
Attributi e funzionalità di ciascuna relazione

• Modello E-R: descrizione dei requisiti informativi dell'applicazione software: diagramma entità (E) – relazioni
(R). Esprime il contenuto informativo dell'applicazione dal punto di vista dell'utilizzatore finale

• Requisiti informatici: descrizione dei requisiti per il sistema software

Composizione: Requisiti utente +


Documenti analisi dei requisiti

• Requisiti utente: descrizione in qualunque forma di quello che l'utente intende ottenere dal prodotto software

• Specifiche delle funzioni elementari: descrizione dettagliata delle operazioni di ciascuna funzione elementare dei
DFD

Caso di studio Ingegneria del Software II 187


Piano esecutivo 3

TIPOLOGIE DI INTERVENTI COPERTI:


T9 - modifiche ai moduli del codice interessati dalle modifiche al progetto
T10 - implementazione dei moduli e delle strutture dati eventualmente aggiunti al progetto
T11 - ricompilazione del programma

COMPONENTI DEL SISTEMA INTERESSATE DALL'INTERVENTO:


Codice sorgente (T9, T10)
Codice oggetto (T11)

WORK FLOW DIAGRAM:

START

Implementare il progetto

3.1

Compilare il programma

3.2

STOP

SCENARI PROCEDURALI:

3.1 Implementare il progetto


I.S.C.: Prodotti di input disponibili

Input: Documenti di progetto

Procedura:

1. Realizzare il codice
2. Realizzare la base di dati

Output: Codice sorgente

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 188


3.2 Compilare il programma
I.S.C.: Prodotti di input disponibili

Input: Codice sorgente

Procedura:

1. Compilare il programma
2. Se esistono errori sintattici
2.1 Correggere gli errori
2.2 Ripetere dal passo 1

Output: Codice sorgente corretto, Codice oggetto

I.E.C.: Prodotti di output realizzati

DESCRIZIONE DEI MANUFATTI:

• Codice: risultato della compilazione del programma

Composizione: Codice sorgente corretto +


Codice oggetto

• Codice oggetto: risultato della compilazione del codice sorgente

• Codice sorgente: codice delle componenti software

• Codice sorgente corretto: codice sorgete rielaborato in modo da eliminare gli errori sintattici

• Definizione delle strutture dei file esterni e dei dati globali: struttura logica, record logici e modalità di accesso
per ogni file esterno; struttura di ciascun dato globale; matrice Cross Reference file esterno/dato globale x modulo
che li usa

• Diagramma delle dipendenze: diagramma in cui sono indicati, per ciascun dato della base di dati, le dipendenze
rispetto agli altri dati

• Dizionario dei dati (progetto): descrizione delle strutture e dei dati usati nelle specifiche dei moduli

• Documenti di progetto: documenti prodotti durante la fase di progetto

Composizione: Documenti interni di progetto +


Vincoli di programmazione

• Documenti interni di progetto: documenti prodotti durante la fase di progetto, ad uso interno

Composizione: Structure Chart aggiornata +


Specifica dei moduli aggiornata +
Tavole e percorsi di navigazione +
Diagramma delle dipendenze +
Dizionario dei dati (progetto) +
Definizione delle strutture e dei file esterni e dei dati globali +
Matrice Cross Reference RexDS

• Matrice Cross Reference RexDS: matrice usata per stabilire in quale parte del progetto è implementato ciascun
requisito

Caso di studio Ingegneria del Software II 189


• Specifiche dei moduli aggiornata: rifinitura delle specifiche dei moduli necessaria all'allineamento con la
Structure Chart aggiornata

• Structure Chart aggiornata: rifinitura della Structure Chart utilizzando le euristiche e i principi dell'Information
Hiding

• Tavole e percorsi di navigazione: struttura dell'organizzazione della base di dati e insieme di percorsi logici per
navigarla

• Vincoli di programmazione: accorgimenti che il progettista detta al programmatore.

Caso di studio Ingegneria del Software II 190


Miglioramento del processo di sviluppo software

• Negli scenari procedurali del processo di sviluppo software, sostituire la specifica dell'attività 2.5 (Rifinire la
Structure Chart e le specifiche dei moduli) con la seguente:

2.5 Rifinire la Structure Chart e le specifiche dei moduli


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli, Structure Chart, Tavole e percorsi di navigazione

Procedura:

1. Aggiungere i moduli per la gestione dei dati


2. Migliorare la Structure Chart utilizzando le euristiche
2a. Per ogni modulo del sistema
2a.1. Verificare la necessità di tutti i dati passati al modulo come parametri e la necessità di tutti i dati
restituiti dal modulo. Se il numero di dati passati è elevato e questi dati sono "collegati" tra loro,
è possibile sostituirli con una struttura. Prestare attenzione che questo intervento non provochi
nuove carenze nel sistema o il peggioramento della qualità già raggiunta.
2a.2. Verificare che il modulo svolga un'unica funzione. In caso contrario è necessario dividere il
modulo in moduli dedicati ad un'unica funzione. In questo modo è anche possibile che il gran
numero di dati passati al/dal modulo originario sia distribuito ai moduli derivanti dalla sua
divisione. Prestare attenzione che questo intervento non provochi nuove carenze nel sistema o il
peggioramento della qualità già raggiunta.
3. Migliorare la Structure Chart secondo i principi dell'Information Hiding
3a. Per ogni modulo del sistema
3a.1. Se il numero di funzioni principali svolte dal modulo è maggiore di uno, esplodere il modulo in
modo che all'interno del sistema svolga una sola funzione principale. Spostare i moduli risultanti
dall'esplosione in aree differenti della struttura del sistema, eseguendo quindi gli interventi
necessari ad integrarli con i moduli presenti in quelle nuove aree. Prestare attenzione che questo
intervento non provochi nuove carenze nel sistema o il peggioramento della qualità già raggiunta.
3a.2. Se il numero di segreti nascosti dal modulo è maggiore di uno, esplodere il modulo in modo che
in ognuno dei moduli derivanti sia nascosto uno ed uno solo dei segreti nascosti nel modulo
originario. Prestare attenzione che questo intervento non provochi nuove carenze nel sistema o il
peggioramento della qualità già raggiunta.
4. Per ciascun modulo aggiunto
4.1 Definire la specifica semantica e la specifica sintattica
4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo
4.3 Descrivere i dati referenziati
4.4 Definire gli altri moduli che esso utilizza
4.5 Rieseguire i passi 2a.1, 2a.2, 3a.1 e 3a.2

Output: Structure Chart aggiornata, Specifiche dei moduli aggiornate

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 191


Piano esecutivo esecuzione numero 3
del processo di miglioramento

Caso di studio Ingegneria del Software II 192


START

Rilevare le misure

1.6

Interpretare le misure

2.1

Individuare i punti di
debolezza
2.2

Individuare i fattori di
variazione
3.1

Individuare le ipotesi di
miglioramento
3.2

Individuare gli interventi da


effettuare
4.1

Specificare le modifiche alle


componenti
4.2

Modificare il sistema software


4.3

STOP

Caso di studio Ingegneria del Software II 193


Manufatti dell'esecuzione numero 3
del processo di miglioramento

Caso di studio Ingegneria del Software II 194


Indice dei manufatti usati e/o prodotti:

Distanze dagli obiettivi pag. 242


Fogli metrici pag. 209, 257
Ipotesi di miglioramento dei fogli metrici pag. 255
Misure pag. 212
Piano di misurazioni pag. 200
Piano GQM pag. 196

NOTE:

I manufatti Sistema software e Sistema software migliorato sono presenti in formato elettronico nel CD-ROM allegato.
Il Sistema software nella directory GEFIN-2, il Sistema software migliorato nella directory GEFIN-2 in quanto non è
stato sottoposto a interventi

Caso di studio Ingegneria del Software II 195


Piano GQM

INDICE DEI GOAL:


Goal G1 pag. 197

Caso di studio Ingegneria del Software II 196


G1
Analizzare: sistema software GEFIN D.F.
Allo scopo di: migliorarlo
Rispetto a: information hiding
Dal punto di vista di: ingegnere del software
Nel contesto di: corso di Ingegneria del Software II

Caratterizzazione del prodotto


Q1,1 Qual è la morfologia della structure chart ?

M lista dei moduli presenti nella structure chart


NMOD numero di moduli presenti nella structure chart

Q1,2 Come sono distribuiti i segreti nella structure chart ?

S lista dei segreti nascosti nel sistema


MxS per ogni modulo, il o i segreti che nasconde (tabella cross-reference)

Q1,3 Come è ripartita la structure chart ?

T lista delle tipologie (funzioni principali del sistema) dei moduli


MxT per ogni modulo, a quale o a quali tipologie appartiene (tabella cross-reference)

Q1,4 Come è distribuita la conoscenza dei dati nella structure chart ?

SD lista delle strutture dati usate dal sistema


SDxM per ogni struttura dato, il o i moduli che la conoscono (tabella cross-reference)

TAV lista delle tavole presenti nel database usato dal sistema
MxTAV per ogni modulo, la o le tavole di cui il modulo conosce la struttura (tabella cross-reference)

Modello primario di qualità


Q1,5 Il sistema presenta un'effettiva modularità ?

DI per ogni modulo, il numero di parametri-dato di input al modulo


DO per ogni modulo, il numero di parametri-dato di output del modulo
CI per ogni modulo, il numero di parametri di controllo di input al modulo
CO per ogni modulo, il numero di parametri di controllo di output del modulo
GD per ogni modulo, il numero di variabili globali utilizzate come dati nel modulo
GC per ogni modulo, il numero di variabili globali utilizzate per controllo dal modulo
FANIN per ogni modulo, il numero di moduli che richiamano il modulo
FANOUT per ogni modulo, il numero di moduli richiamati dal modulo
ACC = 1 – 1 / (DI + 2CI + DO + 2CO + GD + 2GC + FANIN + FANOUT) (per ogni modulo)

Interpretazione: il valore di ACC è compreso tra 0 e 1. Il valore 0 corrisponde a basso accoppiamento, mentre il
valore 1 corrisponde ad alto accoppiamento. Per ogni modulo, il valore ACC deve essere il più vicino possibile a
0 e comunque non deve salire al di sopra di 0.850 (fanno eccezione i moduli di servizio per i quali FANIN
elevato aumenta ACC ma non è indice di cattiva modularità, e i moduli di controllo per i quali è normale un
valore elevato di FANOUT). Valori vicini a 0 indicano un alto grado di indipendenza del modulo dagli altri e
quindi che l'impatto di una modifica sul modulo sia localizzata e interessi un numero molto basso, se non nullo,
di moduli. Il valore di GD e GC deve essere pari a 0 per tutti i moduli, in caso contrario l'impatto di una modifica
su un modulo che usa una variabile globale potrebbe estendersi agli altri moduli che usano la stessa variabile
globale. Il valore di CO deve essere 0 per tutti i moduli per evitare che decisioni prese in un modulo interessino
moduli che non appartengono alla sua portata del controllo. Il valore di CI deve essere il più vicino possibile a 0

Caso di studio Ingegneria del Software II 197


in quanto la non perfetta conoscenza del suo significato può rendere ogni intervento di manutenzione difficile da
eseguire e incline all'introduzione di difetti; comunque la circolazione dei dati di controllo deve limitarsi a un
solo livello della structure chart per limitare la portata dell'effetto di una decisione.

TM per ogni modulo, il numero di tipologie a cui appartiene

Interpretazione: il valore di TM deve essere pari a 1 per ogni modulo. Un valore maggiore di 1 indica che il
modulo svolge più funzioni principali del sistema e questo implica difficoltà nel collaudo, manutenzione ed
estensione del sistema, oltre che una difficoltà nel capire la responsabilità del modulo e le funzioni da esso svolte.

MNS per ogni segreto, il numero di moduli che conoscono questo segreto

Interpretazione: per ogni segreto, il valore di MNS non deve superare il valore 5 e comunque deve essere un
valore vicino a 3. In caso contrario l'impatto della modifica di un dettaglio (segreto) si estenderebbe a tutti i
moduli che conoscono lo stesso dettaglio (segreto). Valori bassi di MNS indicano quindi una maggiore
localizzazione degli interventi di manutenzione.

MDS per ogni struttura dati, il numero di moduli che conoscono questa struttura

Interpretazione: per ogni struttura dati, il valore di MDS non deve superare il valore 4 e comunque deve essere il
più vicino possibile a 3. Per moduli che conoscono una struttura dati, si intendono quei moduli che usano dati
contenuti in essa per eseguire una elaborazione (non vanno considerati i moduli che scrivono dati nella struttura);
quindi un alto valore di MDS implica che una modifica alla struttura dati si estenderebbe a tutti i moduli che
usano i dati in essa contenuta per eseguire un'elaborazione.

MTS per ogni tavola del database, il numero di moduli che conoscono la sua struttura

Interpretazione: per ogni tavola, il valore di MTS deve essere non superiore a 1. In caso contrario una modifica
alla struttura della tavola avrebbe impatto su tutti i moduli che la conoscono.

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore a 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

NT5NF numero di tavole in quinta forma normale (5NF) presenti nel database
NT numero di tavole presenti nel database
PT5NF = NT5NF / NT

Interpretazione: il valore di PT5NF è compreso tra 0 e 1. Il valore di PT5NF deve essere uguale a 1, in caso
contrario è possibile che più moduli che svolgono funzioni diverse accedano alla stessa tavola e quindi questa
tavola aumenti l'accoppiamento dei moduli suddetti, oppure che un modulo effettui più funzioni diverse sulla
stessa tavola, diminuendo così l'indipendenza funzionale.

Q1,6 I moduli hanno una buona riusabilità ?

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore a 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

Caso di studio Ingegneria del Software II 198


FANIN per ogni modulo, il numero di moduli che lo richiamano

Interpretazione: il valore di FANIN indica il grado di riusabilità interna al sistema del modulo: a un valore alto di
FANIN corrisponde un modulo che svolge una precisa funzione richiesta da altri moduli, quindi si tratta di un
modulo di servizio. Inoltre moduli con alto FANIN presenti a un livello inferiore della structure chart, con molta
probabilità presentano anche riusabilità esterna.

Modello di conferma
Q1,7 Qual è l'impatto delle modifiche ?

MxMMODRIUS scheda dei moduli del vecchio sistema, modificati e riusati per il nuovo sistema
(tabella cross-reference)
NMRIUS numero di moduli del vecchio sistema modificati per il nuovo
NMMOD numero di moduli del vecchio sistema riusati nel nuovo
PERMMOD = NMMOD / NMOD
PERMRIUS = NMRIUS / NMOD

Interpretazione: i valori di PERMMOD e PERMRIUS sono compresi tra 0 e 1. Il valore di PERMMOD deve
essere il più vicino possibile a 0, non deve superare il valore 0.05 per garantire una struttura che localizza le
informazioni. Il valore di PERMRIUS deve essere il più vicino possibile a 1, non deve essere inferiore al valore
0.95 per garantire che il sistema sia stato modificato riusando la maggior parte delle componenti della versione
precedente

Caso di studio Ingegneria del Software II 199


Piano di misurazioni

INDICE DELLE METRICHE:


CI pag. 203
CO pag. 203
DI pag. 203
DO pag. 203
FANIN pag. 204
FANOUT pag. 204
GC pag. 204
GD pag. 203
M pag. 201
MDS pag. 205
MNS pag. 204
MTS pag. 205
MxMMODRIUS pag. 206
MxS pag. 201
MxT pag. 202
MxTAV pag. 202
NMMOD pag. 206
NMOD pag. 201
NMRIUS pag. 206
NT pag. 205
NT5NF pag. 205
S pag. 201
SD pag. 202
SDxM pag. 202
SN pag. 205
T pag. 201
TAV pag. 202
TM pag. 204

Caso di studio Ingegneria del Software II 200


M
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• raccogliere e riportare i nomi di tutti i moduli distinti presenti in essa.
Controlli da effettuare nessuno

NMOD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• contare il numero di moduli distinti presenti in essa
Controlli da effettuare nessuno

S
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• individuare e riportare i segreti (dettagli) distribuiti tra i moduli presenti in essa
Controlli da effettuare nessuno

MxS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed S
• considerare i valori rilevati con le metriche M ed S e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e i segreti elencati in
Come misurare
S
• usando la structure chart, per ogni modulo nella tabella, contrassegnare con una
"x" le caselle in corrispondenza dei segreti che nasconde
Controlli da effettuare  ogni segreto nella tabella deve essere nascosto in almeno un modulo

T
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
documenti di progetto
Come misurare
• individuare e riportare le tipologie di moduli presenti nella structure chart (moduli
efferenti, afferenti, di controllo, ecc…)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 201


MxT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e T
• considerare i valori rilevati con le metriche M e T e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tipologie
Come misurare
elencate in T
• usando la structure chart, per ogni modulo nella tabella contrassegnare con una "x"
le caselle in corrispondenza alla tipologia a cui appartiene
 ogni modulo nella tabella deve appartenere ad almeno una tipologia
Controlli da effettuare
 ogni tipologia nella tabella deve contenere almeno un modulo

SD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare il dizionario dei dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le strutture di dati distinte presenti in esso
Controlli da effettuare nessuno

SDxM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed SD
• considerare i valori rilevati con le metriche M ed SD e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le strutture dati
elencate in SD
Come misurare
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle strutture dati di cui conosce la struttura (per individuarle,
usare la specifica del modulo e verificare se il modulo usa dati in essa contenuti
per eseguire un'elaborazione)
Controlli da effettuare  ogni struttura dati nella tabella deve essere usata in almeno un modulo

TAV
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le tavole presenti in esso
Controlli da effettuare nessuno

MxTAV
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e TAV
• considerare i valori rilevati con le metriche M e TAV e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tavole elencate
Come misurare in TAV
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle tavole di cui conosce la struttura (per individuarle, usare la
specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 202


DI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato da elaborare"
Controlli da effettuare nessuno

DO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato da elaborare"
Controlli da effettuare nessuno

CI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato di controllo"
Controlli da effettuare nessuno

CO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato di controllo"
Controlli da effettuare nessuno

GD
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato da elaborare (usare la specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 203


GC
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato di controllo (usare la specifica del modulo)
Controlli da effettuare nessuno

FANIN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nelle specifiche dei moduli) che richiamano il modulo suddetto
 il valore di FANIN deve essere maggiore o uguale a 1, tranne per il modulo di
Controlli da effettuare
livello 1 della structure chart

FANOUT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nella specifica del modulo) richiamati dal modulo suddetto
Controlli da effettuare nessuno

TM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxT
• per ogni modulo elencato nella tabella MxT, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di TM deve essere maggiore o uguale a 1

MNS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni segreto elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MNS deve essere maggiore o uguale a 1

Caso di studio Ingegneria del Software II 204


MDS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica SDxM
• per ogni struttura dati elencata nella tabella SDxM, contare il numero di caselle, ad
Come misurare
essa relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MDS deve essere maggiore o uguale a 1

MTS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxTAV
• per ogni tavola elencata nella tabella MxTAV, contare il numero di caselle, ad essa
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

SN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni modulo elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

NT5NF
Chi deve misurare ingegnere del software
Quando misurare durante l'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare • contare il numero di tabelle in quinta forma normale contenute nello schema della
base di dati
Controlli da effettuare nessuno

NT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica TAV
Come misurare • contare il numero di tabelle elencate in TAV
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 205


MxMMODRIUS
Chi deve misurare ingegnere del software
Quando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)
• riportare in una tabella cross-reference i moduli elencati nella metrica M e i due
tipi "modificato" e "riusato"
• considerare i valori rilevati con la metrica M e la scheda descrizione degli
interventi prodotta nell'attività di specifica delle modifiche alle componenti
(attività 4.2)
Come misurare • per ogni modulo nella tabella, considerare la scheda degli interventi e
contrassegnare con una "x" la casella corrispondente a "modificato" se il modulo è
stato sottoposto a modifiche (anche eliminato, diviso o fuso con altri moduli)
• per ogni modulo della tabella, considerare la structure chart (o anche la call graph)
della nuova versione del sistema e contrassegnare con una "x" la casella
corrispondente a "riusato" se il modulo è presente nella structure chart
Controlli da effettuare nessuno

NMRIUS
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "riusato"
Controlli da effettuare nessuno

NMMOD
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "modificato"
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 206


Caso di studio Ingegneria del Software II 207
Caso di studio Ingegneria del Software II 208
Fogli metrici

Indice dei fogli metrici


Goal G1 pag. 210

Caso di studio Ingegneria del Software II 209


OGGETTO SCOPO OBIETTIVO DI QUALITÀ PUNTO DI VISTA CONTESTO
G1 sistema software GEFIN D.F. migliorare information hiding ingegnere del software corso di Ingegneria del
Software II
QUALITY FOCUS FATTORI DI VARIAZIONE
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) Metriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC
accoppiamento di un modulo
DI numero di parametri-dato di input al modulo • esperienza del team di progetto nella progettazione delle interfacce tra le singole
DO numero di parametri-dato di output del modulo componenti del sistema
CI numero di parametri di controllo di input al modulo Metriche influenzate: MDS, ACC, GD, GC
CO numero di parametri di controllo di output del modulo
GD numero di variabili globali utilizzate come dati nel modulo • esperienza del team di progetto nella progettazione delle basi di dati
GC numero di variabili globali utilizzate per controllo dal modulo Metriche influenzate: PT5NF
FANIN numero di moduli che richiamano il modulo
FANOUT numero di moduli richiamati dal modulo
• esperienza del team di progetto nel miglioramento della qualità del sistema
Metriche influenzate: TM, SN, ACC
TM: distribuzione della tipologia dei moduli tra i moduli del sistema

MNS: numero di moduli che nascondono un segreto

MDS: numero di moduli che conoscono la struttura di un dato

MTS: numero di moduli che conoscono la struttura di una tavola

SN: numero di segreti nascosti per modulo

PT5NF = NT5NF / NT : normalizzazione della base di dati


NT5NF: numero di tavole in 5NF presenti nel database
NT: numero di tavole presenti nel database

- Riusabilità:

SN: numero di segreti nascosti per modulo

FANIN: numero di moduli che usano un modulo

Caso di studio Ingegneria del Software II 210


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS

Caso di studio Ingegneria del Software II 211


- Modularità: • esperienza del team di progetto nella progettazione della struttura del sistema

ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di  la maggiore esperienza nel ripartire la struttura del sistema secondo le funzioni principali
svolte, comporta una migliore distribuzione della tipologia dei moduli (basso valore di TM);
controllo per i quali valori vicini a 1 sono accettabili;
in particolare, delegando l'accesso ai dati a una sola tipologia di moduli si riduce al minimo il
numero di moduli che conoscono le singole componenti della base di dati (MTS)
CI: massimo 1 per il 2% dei moduli del sistema
pari a 0 per il restante 98%;  la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate
CO: pari a 0 per tutti i moduli del sistema; comporta un basso numero di segreti nascosti dallo stesso modulo (SN) oltre che
GD: pari a 0 per tutti i moduli del sistema; l'abbassamento del numero di moduli che conoscono lo stesso segreto (MNS)
GC: pari a 0 per tutti i moduli del sistema;
 la maggiore esperienza nel progettare moduli che implementano una singola funzione
comporta la diminuzione dell'interconnessione tra i moduli, e quindi dell'accoppiamento
TM: pari a 1 per tutti i moduli del sistema; (ACC), in particolare diminuisce la necessità dell'uso di dati di controllo (CO, CI e GC)

MNS: massimo 4 per tutti i segreti;  la maggiore esperienza nell'identificare nei moduli del sistema funzioni ricorrenti più volte,
nell'estrarre queste funzioni e nell'inserire ognuna di esse in singoli moduli, comporta
l'aumento del fan-in di questi moduli (FANIN)
MDS: massimo 4 per tutte le strutture dati escluse quelle che fanno parte
dell'interfaccia delle componenti riusabili del sistema; • esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti del
sistema
MTS: pari a 0 per tutte le tavole del sistema;
 la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di
SN: massimo 1 per tutti i moduli del sistema; controllo (mediante chiamata/sincronizzazione) o allo scambio (in input/output) dei soli dati
necessari, comporta la diminuzione dell'accoppiamento dei moduli (ACC). Inoltre se i dati
scambiati sono dati elementari e non strutture dati, si ottiene la diminuzione del numero di
PT5NF: pari a 1; moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi moduli

- Riusabilità:  la maggiore esperienza nel limitare la possibilità di scambio di dati tra i moduli al solo uso
della loro interfaccia, comporta la diminuzione della necessità di usare variabili globali (GD
SN: pari a 1 per tutti i moduli del sistema; e GC) e quindi la diminuzione dell'accoppiamento dei moduli (ACC)

• esperienza del team di progetto nella progettazione delle basi di dati


FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili
esternamente; compreso tra il 5% e il 30% dei moduli del sistema  la maggiore esperienza nel metodo della decomposizione senza perdita o nell'uso del data
per i moduli riusabili internamente; minore del 5% dei moduli del modelling comporta una migliore normalizzazione della base di dati (PT5NF)
sistema per i moduli generici
• esperienza del team di progetto nel miglioramento della qualità del sistema

 la maggiore esperienza del team di progetto nell'applicazione delle euristiche e dei principi
dell'information hiding prestando attenzione che l'applicazione di una euristica o di un
principio non vada in conflitto con altri, comporta la riduzione del rischio che interventi tesi
a migliorare una metrica producano come effetto collaterale il peggioramento di altri (TM,
SN, ACC)

Caso di studio Ingegneria del Software II 212


Misure

INDICE DELLE METRICHE:


ACC pag. 233
CI pag. 227
CO pag. 228
DI pag. 225
DO pag. 226
FANIN pag. 231
FANOUT pag. 232
GC pag. 230
GD pag. 229
M pag. 213
MDS pag. 237
MNS pag. 236
MTS pag. 238
MxS pag. 219
MxT pag. 222
MxTAV pag. 224
NMOD pag. 214
NT pag. 240
NT5NF pag. 239
PT5NF pag. 241
S pag. 218
SD pag. 217
SDxM pag. 223
SN pag. 235
T pag. 215
TAV pag. 216
TM pag. 234

Caso di studio Ingegneria del Software II 213


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: M
VALORE RILEVATO:

CODICE MODULO
M1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa
M2 Calcolare Disponibilità di Cassa Non Impegnata
M3 Calcolare Prenotazione Non Impegnata
M4 Calcolare Situazione Eco./Fin.
M5 Consolidare Automaticamente Prenotazione
M6 Consolidare Entrate
M7 Consolidare Manualmente Finanziamento
M8 Consolidare Manualmente Prenotazione
M9 Controllare Consistenza Cancellazione Entrata
M10 Controllare Consistenza Cancellazione Finanziamento
M11 Controllare Consistenza Cancellazione Impegno
M12 Controllare Consistenza Cancellazione Prenotazione
M13 Controllare Consistenza Creazione Entrata
M14 Controllare Consistenza Creazione Finanziamento
M15 Controllare Consistenza Creazione Impegno
M16 Controllare Consistenza Creazione Prenotazione
M17 Controllare Consistenza Modifica Entrata
M18 Controllare Consistenza Modifica Finanziamento
M19 Controllare Consistenza Modifica Impegno
M20 Controllare Consistenza Modifica Prenotazione
M21 Controllare Consistenza Creazione Pagamento
M22 Inserire Pagamento Maggiore
M23 Controllare Scadenze
M24 Convertire Valuta
M25 Data Banker
M26 Data Banker Create
M27 Data Banker Delete
M28 Data Banker Read
M29 Data Banker Update
M30 Gestire Schermate
M31 Inserire Entrata
M32 Inserire Finanziamento
M33 Inserire Impegno
M34 Inserire Pagamento
M35 Inserire Pagamento Prenotazione Esaurita
M36 Inserire Prenotazione
M37 Leggere Metadati
M38 Main
M39 Modificare/Cancellare Entrata
M40 Modificare/Cancellare Finanziamento
M41 Modificare/Cancellare Impegno
M42 Modificare/Cancellare Prenotazione
M43 Navigare Entrate
M44 Navigare Finanziamenti
M45 Navigare Impegni
M46 Navigare Pagamenti
M47 Navigare Prenotazioni
M48 Selezionare Finanziamento da Consolidare
M49 Selezionare Prenotazione da Consolidare
M50 Trattare Errori
M51 Acquisire Parametri Navigazione Finanziamenti
M52 Acquisire Parametri Navigazione Entrate
M53 Acquisire Parametri Navigazione Prenotazioni NOTE: viene indicato anche il
M54 Acquisire Parametri Navigazione Impegni codice in modo da rendere più
M55 Acquisire Parametri Navigazione Pagamenti
leggibili le tabelle delle
M56 Inserire Pagamento Minore
M57 Inserire Pagamento Uguale successive metriche, nelle quali
M58 Generare Chiave Automaticamente verrà usato il codice al posto del
M59 Consolidare Automaticamente Finanziamento nome del modulo
M60 Controllare Consistenza Creazione Impegno Senza Prenotazione

Caso di studio Ingegneria del Software II 214


Caso di studio Ingegneria del Software II 215
DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: NMOD
VALORE RILEVATO: 60

Caso di studio Ingegneria del Software II 216


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: T
VALORE RILEVATO:

TIPOLOGIA
Controllo
Afferente
Efferente
Trasformazione
Data Banker

Caso di studio Ingegneria del Software II 217


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: TAV
VALORE RILEVATO:

TAVOLA
Finanziamenti
Entrate
Prenotazioni
Impegni
Pagamenti
Finanziamenti Entrate
Finanziamenti Prenotazioni
Prenotazioni Impegni
Impegni Pagamenti

Caso di studio Ingegneria del Software II 218


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SD
VALORE RILEVATO:

STRUTTURA DATI
CREATE_IMP
db_request
db_result
JoinTab
INS_RIC
Metadati
MOD_CANC_RIC
RIC
TipoValuta

Caso di studio Ingegneria del Software II 219


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: S
VALORE RILEVATO:

CODICE SEGRETO
S1 algoritmo di conversione valuta (Euro-Lire)
S2 algoritmo per la generazione automatica della chiave di un record
S3 D.B.M.S. usato
S4 gestione della situazione di un aumento di un impegno e della prenotazione che non riesce a coprirlo
S5 gestione dell'interfaccia grafica
S6 gestione messaggistica di errore
S7 metodo per il calcolo della disponibilità di cassa non impegnata
S8 metodo per il calcolo della parte di prenotazione non impegnata
S9 metodo per il calcolo della situazione economica e finanziaria
S10 metodo per il consolidamento automatico di un finanziamento
S11 metodo per il consolidamento automatico di una entrata
S12 metodo per il consolidamento automatico di una prenotazione
S13 metodo per il consolidamento manuale di un finanziamento
S14 metodo per il consolidamento manuale di una prenotazione
S15 metodo per la cancellazione di un finanziamento
S16 metodo per la cancellazione di un impegno
S17 metodo per la cancellazione di una entrata
S18 metodo per la cancellazione di una prenotazione
S19 metodo per la modifica di un finanziamento
S20 metodo per la modifica di un impegno
S21 metodo per la modifica di una entrata
S22 metodo per la modifica di una prenotazione
S23 metodo per l'aggiornamento della situazione economica e finanziaria
S24 metodo per l'individuazione delle scadenze
S25 metodo per l'inserimento di un nuovo finanziamento
S26 metodo per l'inserimento di un nuovo impegno
S27 metodo per l'inserimento di un nuovo pagamento quando l'importo è uguale all'impegno
S28 metodo per l'inserimento di un nuovo pagamento quando l'importo è maggiore dell'impegno
S29 metodo per l'inserimento di un nuovo pagamento quando l'importo è minore dell'impegno
S30 metodo per l'inserimento di una nuova entrata
S31 metodo per l'inserimento di una nuova prenotazione
S32 modalità di presentazione dati richiesti per la navigazione degli impegni
S33 modalità di presentazione dati richiesti per la navigazione dei finanziamenti
S34 modalità di presentazione dati richiesti per la navigazione dei pagamenti
S35 modalità di presentazione dati richiesti per la navigazione delle entrate
S36 modalità di presentazione dati richiesti per la navigazione delle prenotazioni
S37 modalità di presentazione dati richiesti per la variazione degli impegni
S38 modalità di presentazione dati richiesti per la variazione dei finanziamenti
S39 modalità di presentazione dati richiesti per la variazione delle entrate
S40 modalità di presentazione dati richiesti per la variazione delle prenotazioni
S41 modalità di presentazione dati richiesti per l'inserimento degli impegni
S42 modalità di presentazione dati richiesti per l'inserimento dei finanziamenti
S43 modalità di presentazione dati richiesti per l'inserimento dei pagamenti
S44 modalità di presentazione dati richiesti per l'inserimento delle entrate
S45 modalità di presentazione dati richiesti per l'inserimento delle prenotazioni
S46 modalità di presentazione finanziamenti consolidabili manualmente
S47 modalità di presentazione prenotazioni consolidabili manualmente
S48 operazioni da eseguire al lancio del sistema
S49 ricerca entrate e modalità di presentazione risultati
S50 ricerca finanziamenti e modalità di presentazione risultati
S51 ricerca impegni e modalità di presentazione risultati
S52 ricerca pagamenti e modalità di presentazione risultati
S53 ricerca prenotazioni e modalità di presentazione risultati
S54 accesso ai metadati
S55 accesso ai servizi offerti dal data banker

NOTE: viene indicato anche il codice in modo da rendere più leggibili le tabelle delle successive metriche, nelle quali
verrà usato il codice al posto del nome del segreto

Caso di studio Ingegneria del Software II 220


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: MxS
VALORE RILEVATO: (le righe contengono i segreti, le colonne i moduli)

M10

M12

M13

M14

M15

M16

M17

M18

M19

M20

M21

M22

M23

M24
M11
M1

M2

M3

M4

M5

M6

M7

M8

M9
S1 x
S2
S3
S4
S5
S6
S7 x
S8 x
S9 x
S10
S11 x
S12 x
S13 x
S14 x
S15 x
S16 x
S17 x
S18 x
S19 x
S20 x
S21 x
S22 x
S23 x
S24 x
S25 x
S26 x
S27
S28 x
S29
S30 x
S31 x
S32
S33
S34
S35
S36
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 221


M37
M25

M26

M27

M28

M29

M30

M31

M32

M33

M34

M35

M36

M38

M39

M40

M41

M42

M43

M44

M45

M46

M47

M48

M49

M50
S1
S2
S3 x x x x
S4 x
S5 x
S6 x
S7
S8
S9
S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26
S27
S28
S29
S30
S31
S32
S33
S34
S35
S36
S37 x
S38 x
S39 x
S40 x
S41 x
S42 x
S43 x
S44 x
S45 x
S46 x
S47 x
S48 x
S49 x
S50 x
S51 x
S52 x
S53 x
S54 x
S55 x

Caso di studio Ingegneria del Software II 222


M51

M52

M53

M54

M55

M56

M57

M58

M59

M60
S1
S2 x
S3
S4
S5
S6
S7
S8
S9
S10 x
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26 x
S27 x
S28
S29 x
S30
S31
S32 x
S33 x
S34 x
S35 x
S36 x
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 223


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: MxT
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tipologie)
Controllo Afferente Efferente Trasformazione Data Banker
M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x
M16 x
M17 x
M18 x
M19 x
M20 x
M21 x
M22 x
M23 x
M24 x
M25 x
M26 x
M27 x
M28 x
M29 x
M30 x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37 x
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50 x
M51 x
M52 x
M53 x
M54 x
M55 x
M56 x
M57 x
M58 x
M59 x
M60 x

Caso di studio Ingegneria del Software II 224


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SDxM
VALORE RILEVATO: (le righe contengono i moduli, le colonne le strutture dati)

db_reques

TipoValut
CANC_R
CREATE

INS_RIC
db_result

Metadati
JoinTab

MOD_
_IMP

RIC
IC

a
t

M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x x
M16 x
M17 x
M18 x
M19 x
M20 x
M21
M22 x
M23 x
M24 x
M25 x
M26 x x
M27 x
M28 x x
M29 x x
M30 x x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50
M51 x
M52 x
M53 x
M54 x
M55 x
M56 x
M57 x
M58
M59 x

Caso di studio Ingegneria del Software II 225


M60 x x

DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: MxTAV
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tavole)
menti
Finanzia

Entrate

zioni
Prenota

Impegni

ti
Pagamen

Entrate
menti
Finanzia
Prenotazi
menti
Finanzia
Impegni
zioni
Prenota
ti
Pagamen
Impegni
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
M11
M12
M13
M14
M15
M16
M17
M18
M19
M20
M21
M22
M23
M24
M25
M26
M27
M28
M29
M30
M31
M32
M33
M34
M35
M36
M37
M38
M39
M40
M41
M42 NOTE: l'assenza di
M43 corrispondenze è dovuta
M44
all'uso del data banker
M45
M46 per l'accesso ai dati nel
M47 sistema: infatti, il data
M48 banker è implementato
M49 in modo da costruire
M50
automaticamente, sulla
M51
M52 base dei metadati, le
M53 richieste per l'accesso al
M54 database.
M55
M56
M57
M58
M59

Caso di studio Ingegneria del Software II 226


M60

DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DI
VALORE RILEVATO:

M1 3
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 2
M14 1
M15 1
M16 2
M17 3
M18 2
M19 3
M20 3
M21 2
M22 2
M23 0
M24 1
M25 1
M26 3
M27 2
M28 2
M29 1
M30 0
M31 0
M32 0
M33 0
M34 0
M35 2
M36 0
M37 1
M38 0
M39 0
M40 0
M41 0
M42 0
M43 1
M44 1
M45 1
M46 1
M47 1
M48 0
M49 0
M50 1
M51 0
M52 0
M53 0
M54 0
M55 0
M56 2
M57 2
M58 2
M59 1
M60 1

Caso di studio Ingegneria del Software II 227


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DO
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 0
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 2
M32 2
M33 2
M34 2
M35 1
M36 2
M37 1
M38 0
M39 1
M40 1
M41 1
M42 1
M43 0
M44 0
M45 0
M46 0
M47 0
M48 1
M49 1
M50 0
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 228


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CI
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 1
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 229


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CO
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 230


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GD
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 231


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GC
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 232


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: FANIN
VALORE RILEVATO:

M1 9
M2 3
M3 4
M4 1
M5 3
M6 1
M7 1
M8 2
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 2
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 20
M25 48
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 4
M38 0
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 2
M59 1
M60 1

Caso di studio Ingegneria del Software II 233


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: FANOUT
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 2
M5 3
M6 1
M7 2
M8 2
M9 2
M10 1
M11 2
M12 1
M13 2
M14 1
M15 4
M16 1
M17 2
M18 1
M19 2
M20 1
M21 3
M22 5
M23 1
M24 0
M25 4
M26 2
M27 1
M28 1
M29 2
M30 17
M31 2
M32 1
M33 2
M34 2
M35 1
M36 2
M37 0
M38 24
M39 2
M40 2
M41 2
M42 2
M43 2
M44 2
M45 2
M46 2
M47 2
M48 1
M49 1
M50 0
M51 2
M52 2
M53 2
M54 2
M55 2
M56 3
M57 3
M58 0
M59 2
M60 4

Caso di studio Ingegneria del Software II 234


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: ACC
VALORE RILEVATO:

M1 0.928
M2 0.833
M3 0.857
M4 0.666
M5 0.875
M6 0.750
M7 0.800
M8 0.833
M9 0.800
M10 0.750
M11 0.800
M12 0.750
M13 0.833
M14 0.750
M15 0.857
M16 0.833
M17 0.857
M18 0.800
M19 0.857
M20 0.833
M21 0.857
M22 0.888
M23 0.500
M24 0.958
M25 0.981
M26 0.857
M27 0.800
M28 0.800
M29 0.800
M30 0.947
M31 0.800
M32 0.750
M33 0.800
M34 0.800
M35 0.800
M36 0.800
M37 0.833
M38 0.958
M39 0.750
M40 0.750
M41 0.750
M42 0.750
M43 0.750
M44 0.750
M45 0.750
M46 0.750
M47 0.750
M48 0.666
M49 0.666
M50 0.500
M51 0.750
M52 0.750
M53 0.750
M54 0.750
M55 0.750
M56 0.857
M57 0.857
M58 0.800
M59 0.800
M60 0.857

Caso di studio Ingegneria del Software II 235


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: TM
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 236


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: SN
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 0
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 237


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MNS
VALORE RILEVATO:

S1 1
S2 1
S3 4
S4 1
S5 1
S6 1
S7 1
S8 1
S9 1
S10 1
S11 1
S12 1
S13 1
S14 1
S15 1
S16 1
S17 1
S18 1
S19 1
S20 1
S21 1
S22 1
S23 1
S24 1
S25 1
S26 2
S27 1
S28 1
S29 1
S30 1
S31 1
S32 1
S33 1
S34 1
S35 1
S36 1
S37 1
S38 1
S39 1
S40 1
S41 1
S42 1
S43 1
S44 1
S45 1
S46 1
S47 1
S48 1
S49 1
S50 1
S51 1
S52 1
S53 1
S54 1
S55 1

Caso di studio Ingegneria del Software II 238


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MDS
VALORE RILEVATO:

CREATE_IMP 2
db_request 1
db_result 48
JoinTab 3
INS_RIC 1
Metadati 4
MOD_CANC_RIC 1
RIC 1
TipoValuta 1

NOTE: il valore 48 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 239


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MTS
VALORE RILEVATO:

Finanziamenti 0
Entrate 0
Prenotazioni 0
Impegni 0
Pagamenti 0
Finanziamenti Entrate 0
Finanziamenti Prenotazioni 0
Prenotazioni Impegni 0
Impegni Pagamenti 0

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema: infatti, il data banker
è implementato in modo da costruire automaticamente, sulla base dei metadati, le richieste per l'accesso al database.

Caso di studio Ingegneria del Software II 240


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT5NF
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 241


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 242


DATA DI CONSEGNA: 15/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: PT5NF
VALORE RILEVATO: 1

Caso di studio Ingegneria del Software II 243


Distanze dagli obiettivi
INDICE DELLE METRICHE:
CI pag. 243
CO pag. 244
FANIN pag. 247
ACC pag. 248
GC pag. 246
GD pag. 245
MDS pag. 252
MNS pag. 251
MTS pag. 253
PT5NF pag. 254
SN pag. 250
TM pag. 249

NOTE:

• una distanza pari a 0 indica il raggiungimento della baseline hypothesis; un valore diverso invece quantifica la
distanza tra il valore rilevato e la baseline hypothesis

• una distanza pari a nessuna indica il raggiungimento della baseline hypothesis

• una distanza pari a rientra indica che il valore rilevato è migliore di quello indicato nella baseline hypothesis

• le distanze segnate in grassetto indicano le metriche che non hanno raggiunto le baseline hypothesis (cioè il valore
rilevato è peggiore)

• per alcune metriche è indicato eccezione, ovvero il valore rilevato è peggiore della baseline hypothesis ma si ritiene
che la metrica abbia dato risultati positivi per i motivi spiegati nelle note o tra le distanze stesse

Caso di studio Ingegneria del Software II 244


METRICA: CI
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 0
M2 0 0
M3 0 0
M4 0 0
M5 0 0
M6 0 0
M7 0 0
M8 0 0
M9 0 0
M10 0 0
M11 0 0
M12 0 0
M13 0 0
M14 0 0
M15 0 0
M16 0 0
M17 0 0
M18 0 0
M19 0 0
M20 0 0
M21 0 0
M22 0 0
M23 0 0
M24 1 1
M25 0 0
M26 0 0
M27 0 0
M28 0 0
M29 0 0
M30 0 0
M31 0 0
M32 0 0
M33 0 0
M34 0 0
M35 0 0
M36 0 0
M37 0 0
M38 0 0
M39 0 0
M40 0 0
M41 0 0
M42 0 0
M43 0 0
M44 0 0
M45 0 0
M46 0 0
M47 0 0
M48 0 0
M49 0 0
M50 0 0
M51 0 0
M52 0 0
M53 0 0
M54 0 0
M55 0 0
M56 0 0
M57 0 0
M58 0 0
M59 0 0
M60 0 0

NOTE: il numero di moduli con CI pari a 1 è uguale a 1, quindi essendo al di sotto del 2% dei moduli del sistema, la
baseline hypothesis è stata raggiunta.

Caso di studio Ingegneria del Software II 245


METRICA: CO
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 246


METRICA: GD
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 247


METRICA: GC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 248


METRICA: FANIN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 9 nessuna (r.i.)
M2 3 nessuna (r.i.)
M3 4 nessuna (r.i.)
M4 1 nessuna (g.)
M5 3 nessuna (r.i.)
M6 1 nessuna (g.)
M7 1 nessuna (g.)
M8 2 nessuna (g.)
M9 1 nessuna (g.)
M10 1 nessuna (g.)
M11 1 nessuna (g.)
M12 1 nessuna (g.)
M13 1 nessuna (g.)
M14 1 nessuna (g.)
M15 1 nessuna (g.)
M16 2 nessuna (g.)
M17 1 nessuna (g.)
M18 1 nessuna (g.)
M19 1 nessuna (g.)
M20 1 nessuna (g.)
M21 1 nessuna (g.)
M22 1 nessuna (g.)
M23 1 nessuna (g.)
M24 20 nessuna (r.e.)
M25 48 nessuna (r.e.)
M26 1 nessuna (g.)
M27 1 nessuna (g.)
M28 1 nessuna (g.)
M29 1 nessuna (g.)
M30 1 nessuna (g.)
M31 1 nessuna (g.)
M32 1 nessuna (g.)
M33 1 nessuna (g.)
M34 1 nessuna (g.)
M35 1 nessuna (g.)
M36 1 nessuna (g.)
M37 4 nessuna (r.i.)
M38 0 nessuna (g.)
M39 1 nessuna (g.)
M40 1 nessuna (g.)
M41 1 nessuna (g.)
M42 1 nessuna (g.)
M43 1 nessuna (g.)
M44 1 nessuna (g.)
M45 1 nessuna (g.)
M46 1 nessuna (g.)
M47 1 nessuna (g.)
M48 1 nessuna (g.)
M49 1 nessuna (g.)
M50 1 nessuna (g.)
M51 1 nessuna (g.)
M52 1 nessuna (g.)
M53 1 nessuna (g.)
M54 1 nessuna (g.)
M55 1 nessuna (g.)
M56 1 nessuna (g.)
M57 1 nessuna (g.)
M58 2 nessuna (g.)
M59 1 nessuna (g.)
M60 1 nessuna (g.)

NOTE: Le sigle r.i., r.e. e g. sono le abbreviazioni di riusabile internamente, riusabile esternamente e generico

Caso di studio Ingegneria del Software II 249


METRICA: ACC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0.928 eccezione (FANIN alto)
M2 0.857 rientra
M3 0.857 rientra
M4 0.666 rientra
M5 0.875 eccezione (FANIN alto)
M6 0.750 rientra
M7 0.800 rientra
M8 0.833 rientra
M9 0.800 rientra
M10 0.750 rientra
M11 0.800 rientra
M12 0.750 rientra
M13 0.833 rientra
M14 0.750 rientra
M15 0.857 rientra
M16 0.833 rientra
M17 0.857 rientra
M18 0.800 rientra
M19 0.857 rientra
M20 0.833 rientra
M21 0.857 rientra
M22 0.888 0.028
M23 0.500 rientra
M24 0.958 eccezione (FANIN alto)
M25 0.981 eccezione (FANIN alto)
M26 0.857 rientra
M27 0.800 rientra
M28 0.800 rientra
M29 0.800 rientra
M30 0.947 eccezione (modulo di controllo)
M31 0.800 rientra
M32 0.750 rientra
M33 0.800 rientra
M34 0.800 rientra
M35 0.800 rientra
M36 0.800 rientra
M37 0.833 rientra
M38 0.958 eccezione (modulo di controllo)
M39 0.750 rientra
M40 0.750 rientra
M41 0.750 rientra
M42 0.750 rientra
M43 0.750 rientra
M44 0.750 rientra
M45 0.750 rientra
M46 0.750 rientra
M47 0.750 rientra
M48 0.666 rientra
M49 0.666 rientra
M50 0.500 rientra
M51 0.750 rientra
M52 0.750 rientra
M53 0.750 rientra
M54 0.750 rientra
M55 0.750 rientra
M56 0.857 rientra
M57 0.857 rientra
M58 0.800 rientra
M59 0.800 rientra
M60 0.857 rientra

Caso di studio Ingegneria del Software II 250


METRICA: TM
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 1 nessuna
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 1 nessuna
M44 1 nessuna
M45 1 nessuna
M46 1 nessuna
M47 1 nessuna
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna
M51 1 nessuna
M52 1 nessuna
M53 1 nessuna
M54 1 nessuna
M55 1 nessuna
M56 1 nessuna
M57 1 nessuna
M58 1 nessuna
M59 1 nessuna
M60 1 nessuna

Caso di studio Ingegneria del Software II 251


METRICA: SN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 0 rientra
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 1 nessuna
M44 1 nessuna
M45 1 nessuna
M46 1 nessuna
M47 1 nessuna
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna
M51 1 nessuna
M52 1 nessuna
M53 1 nessuna
M54 1 nessuna
M55 1 nessuna
M56 1 nessuna
M57 1 nessuna
M58 1 nessuna
M59 1 nessuna
M60 1 nessuna

Caso di studio Ingegneria del Software II 252


METRICA: MNS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
S1 1 nessuna
S2 1 nessuna
S3 4 nessuna
S4 1 nessuna
S5 1 nessuna
S6 1 nessuna
S7 1 nessuna
S8 1 nessuna
S9 1 nessuna
S10 1 nessuna
S11 1 nessuna
S12 1 nessuna
S13 1 nessuna
S14 1 nessuna
S15 1 nessuna
S16 1 nessuna
S17 1 nessuna
S18 1 nessuna
S19 1 nessuna
S20 1 nessuna
S21 1 nessuna
S22 1 nessuna
S23 1 nessuna
S24 1 nessuna
S25 1 nessuna
S26 2 nessuna
S27 1 nessuna
S28 1 nessuna
S29 1 nessuna
S30 1 nessuna
S31 1 nessuna
S32 1 nessuna
S33 1 nessuna
S34 1 nessuna
S35 1 nessuna
S36 1 nessuna
S37 1 nessuna
S38 1 nessuna
S39 1 nessuna
S40 1 nessuna
S41 1 nessuna
S42 1 nessuna
S43 1 nessuna
S44 1 nessuna
S45 1 nessuna
S46 1 nessuna
S47 1 nessuna
S48 1 nessuna
S49 1 nessuna
S50 1 nessuna
S51 1 nessuna
S52 1 nessuna
S53 1 nessuna
S54 1 nessuna
S55 1 nessuna

Caso di studio Ingegneria del Software II 253


METRICA: MDS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
CREATE_IMP 2 rientra
db_request 1 rientra
db_result 48 eccezione (vedere note)
JoinTab 3 rientra
INS_RIC 1 rientra
Metadati 4 rientra
MOD_CANC_RIC 1 rientra
RIC 1 rientra
TipoValuta 1 rientra

NOTE: il valore 48 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 254


METRICA: MTS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE DISTANZA
RILEVATO
Finanziamenti 0 nessuna
Entrate 0 nessuna
Prenotazioni 0 nessuna
Impegni 0 nessuna
Pagamenti 0 nessuna
Finanziamenti Entrate 0 nessuna
Finanziamenti Prenotazioni 0 nessuna
Prenotazioni Impegni 0 nessuna
Impegni Pagamenti 0 nessuna

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema.

Caso di studio Ingegneria del Software II 255


METRICA: PT5NF
VALORE RILEVATO: 1
DISTANZA DALLA BASELINE HYPHOTESIS: nessuna

Caso di studio Ingegneria del Software II 256


Ipotesi di variazione dei fogli metrici
Baseline Hypothesis (II Quadrante)

• Per la metrica ACC, avendo rilevato nuovamente valori peggiori della precedente baseline hypothesis per un unico
modulo, si ritiene che la sua nuova baseline hypothesis possa essere sostituita con:

ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di controllo per i quali valori vicini a 1
sono accettabili; compreso strettamente tra 0.860 e 0.900 per massimo il 2% dei moduli di sistema (esclusi
i moduli prima citati)

Caso di studio Ingegneria del Software II 257


Caso di studio Ingegneria del Software II 258
Fogli metrici

Indice dei fogli metrici


Goal G1 pag. 258

NOTE:

Questa versione dei fogli metrici è stata prodotta durante l'esecuzione dell'attività 1.4 (Produrre i fogli metrici) a causa
della presenza delle Ipotesi di variazione dei fogli metrici

Caso di studio Ingegneria del Software II 259


OGGETTO SCOPO OBIETTIVO DI QUALITÀ PUNTO DI VISTA CONTESTO
G1 sistema software GEFIN D.F. migliorare information hiding ingegnere del software corso di Ingegneria del
Software II
QUALITY FOCUS FATTORI DI VARIAZIONE
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) Metriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC
accoppiamento di un modulo
DI numero di parametri-dato di input al modulo • esperienza del team di progetto nella progettazione delle interfacce tra le singole
DO numero di parametri-dato di output del modulo componenti del sistema
CI numero di parametri di controllo di input al modulo Metriche influenzate: MDS, ACC, GD, GC
CO numero di parametri di controllo di output del modulo
GD numero di variabili globali utilizzate come dati nel modulo • esperienza del team di progetto nella progettazione delle basi di dati
GC numero di variabili globali utilizzate per controllo dal modulo Metriche influenzate: PT5NF
FANIN numero di moduli che richiamano il modulo
FANOUT numero di moduli richiamati dal modulo
• esperienza del team di progetto nel miglioramento della qualità del sistema
Metriche influenzate: TM, SN, ACC
TM: distribuzione della tipologia dei moduli tra i moduli del sistema

MNS: numero di moduli che nascondono un segreto

MDS: numero di moduli che conoscono la struttura di un dato

MTS: numero di moduli che conoscono la struttura di una tavola

SN: numero di segreti nascosti per modulo

PT5NF = NT5NF / NT : normalizzazione della base di dati


NT5NF: numero di tavole in 5NF presenti nel database
NT: numero di tavole presenti nel database

- Riusabilità:

SN: numero di segreti nascosti per modulo

FANIN: numero di moduli che usano un modulo

Caso di studio Ingegneria del Software II 260


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS
- Modularità: • esperienza del team di progetto nella progettazione della struttura del sistema

ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di  la maggiore esperienza nel ripartire la struttura del sistema secondo le funzioni principali
svolte, comporta una migliore distribuzione della tipologia dei moduli (basso valore di TM);
controllo per i quali valori vicini a 1 sono accettabili; compreso
in particolare, delegando l'accesso ai dati a una sola tipologia di moduli si riduce al minimo il
strettamente tra 0.860 e 0.900 per massimo il 2% dei moduli di sistema numero di moduli che conoscono le singole componenti della base di dati (MTS)
(esclusi i moduli prima citati)
 la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate
CI: massimo 1 per il 2% dei moduli del sistema comporta un basso numero di segreti nascosti dallo stesso modulo (SN) oltre che
pari a 0 per il restante 98%; l'abbassamento del numero di moduli che conoscono lo stesso segreto (MNS)
CO: pari a 0 per tutti i moduli del sistema;
 la maggiore esperienza nel progettare moduli che implementano una singola funzione
GD: pari a 0 per tutti i moduli del sistema; comporta la diminuzione dell'interconnessione tra i moduli, e quindi dell'accoppiamento
GC: pari a 0 per tutti i moduli del sistema; (ACC), in particolare diminuisce la necessità dell'uso di dati di controllo (CO, CI e GC)

TM: pari a 1 per tutti i moduli del sistema;  la maggiore esperienza nell'identificare nei moduli del sistema funzioni ricorrenti più volte,
nell'estrarre queste funzioni e nell'inserire ognuna di esse in singoli moduli, comporta
l'aumento del fan-in di questi moduli (FANIN)
MNS: massimo 4 per tutti i segreti;
• esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti del
MDS: massimo 4 per tutte le strutture dati escluse quelle che fanno parte sistema
dell'interfaccia delle componenti riusabili del sistema;
 la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di
MTS: pari a 0 per tutte le tavole del sistema; controllo (mediante chiamata/sincronizzazione) o allo scambio (in input/output) dei soli dati
necessari, comporta la diminuzione dell'accoppiamento dei moduli (ACC). Inoltre se i dati
scambiati sono dati elementari e non strutture dati, si ottiene la diminuzione del numero di
SN: massimo 1 per tutti i moduli del sistema; moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi moduli

PT5NF: pari a 1;  la maggiore esperienza nel limitare la possibilità di scambio di dati tra i moduli al solo uso
della loro interfaccia, comporta la diminuzione della necessità di usare variabili globali (GD
- Riusabilità: e GC) e quindi la diminuzione dell'accoppiamento dei moduli (ACC)

• esperienza del team di progetto nella progettazione delle basi di dati


SN: pari a 1 per tutti i moduli del sistema;
 la maggiore esperienza nel metodo della decomposizione senza perdita o nell'uso del data
FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili modelling comporta una migliore normalizzazione della base di dati (PT5NF)
esternamente; compreso tra il 5% e il 30% dei moduli del sistema
per i moduli riusabili internamente; minore del 5% dei moduli del • esperienza del team di progetto nel miglioramento della qualità del sistema
sistema per i moduli generici
 la maggiore esperienza del team di progetto nell'applicazione delle euristiche e dei principi
dell'information hiding prestando attenzione che l'applicazione di una euristica o di un
principio non vada in conflitto con altri, comporta la riduzione del rischio che interventi tesi
a migliorare una metrica producano come effetto collaterale il peggioramento di altri (TM,
SN, ACC)

Caso di studio Ingegneria del Software II 261


Piano esecutivo esecuzione numero 4
del processo di miglioramento

Caso di studio Ingegneria del Software II 262


START

Rilevare le misure

1.6

Interpretare le misure

2.1

Individuare i punti di
debolezza
2.2

Individuare i fattori di
variazione
3.1

STOP

Caso di studio Ingegneria del Software II 263


Manufatti dell'esecuzione numero 4
del processo di miglioramento

Caso di studio Ingegneria del Software II 264


Indice

Distanze dagli obiettivi pag. 311


Fogli metrici pag. 277
Misure pag. 281
Piano di misurazioni pag. 268
Piano GQM pag. 264

NOTE:

I manufatti Sistema software e Sistema software migliorato sono presenti in formato elettronico nel CD-ROM allegato.
Il Sistema software nella directory GEFIN-2, il Sistema software migliorato nella directory GEFIN-2 in quanto non è
stato sottoposto a interventi

Caso di studio Ingegneria del Software II 265


Piano GQM

INDICE DEI GOAL:


Goal G1 pag. 265

Caso di studio Ingegneria del Software II 266


G1
Analizzare: sistema software GEFIN D.F.
Allo scopo di: migliorarlo
Rispetto a: information hiding
Dal punto di vista di: ingegnere del software
Nel contesto di: corso di Ingegneria del Software II

Caratterizzazione del prodotto


Q1,1 Qual è la morfologia della structure chart ?

M lista dei moduli presenti nella structure chart


NMOD numero di moduli presenti nella structure chart

Q1,2 Come sono distribuiti i segreti nella structure chart ?

S lista dei segreti nascosti nel sistema


MxS per ogni modulo, il o i segreti che nasconde (tabella cross-reference)

Q1,3 Come è ripartita la structure chart ?

T lista delle tipologie (funzioni principali del sistema) dei moduli


MxT per ogni modulo, a quale o a quali tipologie appartiene (tabella cross-reference)

Q1,4 Come è distribuita la conoscenza dei dati nella structure chart ?

SD lista delle strutture dati usate dal sistema


SDxM per ogni struttura dato, il o i moduli che la conoscono (tabella cross-reference)

TAV lista delle tavole presenti nel database usato dal sistema
MxTAV per ogni modulo, la o le tavole di cui il modulo conosce la struttura (tabella cross-reference)

Modello primario di qualità


Q1,5 Il sistema presenta un'effettiva modularità ?

DI per ogni modulo, il numero di parametri-dato di input al modulo


DO per ogni modulo, il numero di parametri-dato di output del modulo
CI per ogni modulo, il numero di parametri di controllo di input al modulo
CO per ogni modulo, il numero di parametri di controllo di output del modulo
GD per ogni modulo, il numero di variabili globali utilizzate come dati nel modulo
GC per ogni modulo, il numero di variabili globali utilizzate per controllo dal modulo
FANIN per ogni modulo, il numero di moduli che richiamano il modulo
FANOUT per ogni modulo, il numero di moduli richiamati dal modulo
ACC = 1 – 1 / (DI + 2CI + DO + 2CO + GD + 2GC + FANIN + FANOUT) (per ogni modulo)

Interpretazione: il valore di ACC è compreso tra 0 e 1. Il valore 0 corrisponde a basso accoppiamento, mentre il
valore 1 corrisponde ad alto accoppiamento. Per ogni modulo, il valore ACC deve essere il più vicino possibile a
0 e comunque non deve salire al di sopra di 0.850 (fanno eccezione i moduli di servizio per i quali FANIN
elevato aumenta ACC ma non è indice di cattiva modularità, e i moduli di controllo per i quali è normale un
valore elevato di FANOUT). Valori vicini a 0 indicano un alto grado di indipendenza del modulo dagli altri e
quindi che l'impatto di una modifica sul modulo sia localizzata e interessi un numero molto basso, se non nullo,
di moduli. Il valore di GD e GC deve essere pari a 0 per tutti i moduli, in caso contrario l'impatto di una modifica
su un modulo che usa una variabile globale potrebbe estendersi agli altri moduli che usano la stessa variabile
globale. Il valore di CO deve essere 0 per tutti i moduli per evitare che decisioni prese in un modulo interessino
moduli che non appartengono alla sua portata del controllo. Il valore di CI deve essere il più vicino possibile a 0

Caso di studio Ingegneria del Software II 267


in quanto la non perfetta conoscenza del suo significato può rendere ogni intervento di manutenzione difficile da
eseguire e incline all'introduzione di difetti; comunque la circolazione dei dati di controllo deve limitarsi a un
solo livello della structure chart per limitare la portata dell'effetto di una decisione.

TM per ogni modulo, il numero di tipologie a cui appartiene

Interpretazione: il valore di TM deve essere pari a 1 per ogni modulo. Un valore maggiore di 1 indica che il
modulo svolge più funzioni principali del sistema e questo implica difficoltà nel collaudo, manutenzione ed
estensione del sistema, oltre che una difficoltà nel capire la responsabilità del modulo e le funzioni da esso svolte.

MNS per ogni segreto, il numero di moduli che conoscono questo segreto

Interpretazione: per ogni segreto, il valore di MNS non deve superare il valore 5 e comunque deve essere un
valore vicino a 3. In caso contrario l'impatto della modifica di un dettaglio (segreto) si estenderebbe a tutti i
moduli che conoscono lo stesso dettaglio (segreto). Valori bassi di MNS indicano quindi una maggiore
localizzazione degli interventi di manutenzione.

MDS per ogni struttura dati, il numero di moduli che conoscono questa struttura

Interpretazione: per ogni struttura dati, il valore di MDS non deve superare il valore 4 e comunque deve essere il
più vicino possibile a 3. Per moduli che conoscono una struttura dati, si intendono quei moduli che usano dati
contenuti in essa per eseguire una elaborazione (non vanno considerati i moduli che scrivono dati nella struttura);
quindi un alto valore di MDS implica che una modifica alla struttura dati si estenderebbe a tutti i moduli che
usano i dati in essa contenuta per eseguire un'elaborazione.

MTS per ogni tavola del database, il numero di moduli che conoscono la sua struttura

Interpretazione: per ogni tavola, il valore di MTS deve essere non superiore a 1. In caso contrario una modifica
alla struttura della tavola avrebbe impatto su tutti i moduli che la conoscono.

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore a 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

NT5NF numero di tavole in quinta forma normale (5NF) presenti nel database
NT numero di tavole presenti nel database
PT5NF = NT5NF / NT

Interpretazione: il valore di PT5NF è compreso tra 0 e 1. Il valore di PT5NF deve essere uguale a 1, in caso
contrario è possibile che più moduli che svolgono funzioni diverse accedano alla stessa tavola e quindi questa
tavola aumenti l'accoppiamento dei moduli suddetti, oppure che un modulo effettui più funzioni diverse sulla
stessa tavola, diminuendo così l'indipendenza funzionale.

Q1,6 I moduli hanno una buona riusabilità ?

SN per ogni modulo, il numero di segreti che nasconde

Interpretazione: il valore di SN deve essere non superiore a 1 per tutti i moduli. Un valore maggiore di 1 indica
una bassa indipendenza funzionale del modulo, diminuisce le possibilità di riusare il modulo, diminuisce la
manutenibilità del modulo in quanto complesso da capire, difficile da estendere, rischioso da modificare.

Caso di studio Ingegneria del Software II 268


FANIN per ogni modulo, il numero di moduli che lo richiamano

Interpretazione: il valore di FANIN indica il grado di riusabilità interna al sistema del modulo: a un valore alto di
FANIN corrisponde un modulo che svolge una precisa funzione richiesta da altri moduli, quindi si tratta di un
modulo di servizio. Inoltre moduli con alto FANIN presenti a un livello inferiore della structure chart, con molta
probabilità presentano anche riusabilità esterna.

Modello di conferma
Q1,7 Qual è l'impatto delle modifiche ?

MxMMODRIUS scheda dei moduli del vecchio sistema, modificati e riusati per il nuovo sistema
(tabella cross-reference)
NMRIUS numero di moduli del vecchio sistema modificati per il nuovo
NMMOD numero di moduli del vecchio sistema riusati nel nuovo
PERMMOD = NMMOD / NMOD
PERMRIUS = NMRIUS / NMOD

Interpretazione: i valori di PERMMOD e PERMRIUS sono compresi tra 0 e 1. Il valore di PERMMOD deve
essere il più vicino possibile a 0, non deve superare il valore 0.05 per garantire una struttura che localizza le
informazioni. Il valore di PERMRIUS deve essere il più vicino possibile a 1, non deve essere inferiore al valore
0.95 per garantire che il sistema sia stato modificato riusando la maggior parte delle componenti della versione
precedente

Caso di studio Ingegneria del Software II 269


Piano di misurazioni

INDICE DELLE METRICHE:


CI pag. 271
CO pag. 271
DI pag. 271
DO pag. 271
FANIN pag. 272
FANOUT pag. 272
GC pag. 272
GD pag. 271
M pag. 269
MDS pag. 273
MNS pag. 272
MTS pag. 273
MxMMODRIUS pag. 274
MxS pag. 269
MxT pag. 270
MxTAV pag. 270
NMMOD pag. 274
NMOD pag. 269
NMRIUS pag. 274
NT pag. 273
NT5NF pag. 273
S pag. 269
SD pag. 270
SDxM pag. 270
SN pag. 273
T pag. 269
TAV pag. 270
TM pag. 272

Caso di studio Ingegneria del Software II 270


M
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• raccogliere e riportare i nomi di tutti i moduli distinti presenti in essa.
Controlli da effettuare nessuno

NMOD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• contare il numero di moduli distinti presenti in essa
Controlli da effettuare nessuno

S
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
Come misurare documenti di progetto
• individuare e riportare i segreti (dettagli) distribuiti tra i moduli presenti in essa
Controlli da effettuare nessuno

MxS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed S
• considerare i valori rilevati con le metriche M ed S e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e i segreti elencati in
Come misurare
S
• usando la structure chart, per ogni modulo nella tabella, contrassegnare con una
"x" le caselle in corrispondenza dei segreti che nasconde
Controlli da effettuare  ogni segreto nella tabella deve essere nascosto in almeno un modulo

T
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare la structure chart del sistema (o anche la call graph) presente nei
documenti di progetto
Come misurare
• individuare e riportare le tipologie di moduli presenti nella structure chart (moduli
efferenti, afferenti, di controllo, ecc…)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 271


MxT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e T
• considerare i valori rilevati con le metriche M e T e la structure chart del sistema
(o anche la call graph) presente nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tipologie
Come misurare
elencate in T
• usando la structure chart, per ogni modulo nella tabella contrassegnare con una "x"
le caselle in corrispondenza alla tipologia a cui appartiene
 ogni modulo nella tabella deve appartenere ad almeno una tipologia
Controlli da effettuare
 ogni tipologia nella tabella deve contenere almeno un modulo

SD
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare il dizionario dei dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le strutture di dati distinte presenti in esso
Controlli da effettuare nessuno

SDxM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M ed SD
• considerare i valori rilevati con le metriche M ed SD e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le strutture dati
elencate in SD
Come misurare
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle strutture dati di cui conosce la struttura (per individuarle,
usare la specifica del modulo e verificare se il modulo usa dati in essa contenuti
per eseguire un'elaborazione)
Controlli da effettuare  ogni struttura dati nella tabella deve essere usata in almeno un modulo

TAV
Chi deve misurare ingegnere del software
Quando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare
• raccogliere e riportare le tavole presenti in esso
Controlli da effettuare nessuno

MxTAV
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
le metriche M e TAV
• considerare i valori rilevati con le metriche M e TAV e le specifiche dei moduli
presenti nei documenti di progetto
• riportare in una tabella cross-reference i moduli elencati in M e le tavole elencate
Come misurare in TAV
• per ogni modulo nella tabella, contrassegnare con una "x" le caselle in
corrispondenza delle tavole di cui conosce la struttura (per individuarle, usare la
specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 272


DI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato da elaborare"
Controlli da effettuare nessuno

DO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato da elaborare"
Controlli da effettuare nessuno

CI
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in input del
tipo "dato di controllo"
Controlli da effettuare nessuno

CO
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente i parametri di interfaccia e contare il numero di parametri in output del
tipo "dato di controllo"
Controlli da effettuare nessuno

GD
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato da elaborare (usare la specifica del modulo)
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 273


GC
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti
nei documenti di progetto
Come misurare • per ogni modulo elencato in M, individuare nella sua specifica la sezione
contenente le variabili usate dal modulo e contare il numero di variabili di tipo
globale usate come dato di controllo (usare la specifica del modulo)
Controlli da effettuare nessuno

FANIN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nelle specifiche dei moduli) che richiamano il modulo suddetto
 il valore di FANIN deve essere maggiore o uguale a 1, tranne per il modulo di
Controlli da effettuare
livello 1 della structure chart

FANOUT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica M
• considerare i valori rilevati con la metrica M e la structure chart del sistema (o la
call graph o le specifiche dei moduli) presente nei documenti di progetto
Come misurare
• per ogni modulo elencato in M, contare il numero di moduli presenti nella
structure chart (o nella specifica del modulo) richiamati dal modulo suddetto
Controlli da effettuare nessuno

TM
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxT
• per ogni modulo elencato nella tabella MxT, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di TM deve essere maggiore o uguale a 1

MNS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni segreto elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MNS deve essere maggiore o uguale a 1

Caso di studio Ingegneria del Software II 274


MDS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica SDxM
• per ogni struttura dati elencata nella tabella SDxM, contare il numero di caselle, ad
Come misurare
essa relative, contrassegnate con una "x"
Controlli da effettuare  il valore di MDS deve essere maggiore o uguale a 1

MTS
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxTAV
• per ogni tavola elencata nella tabella MxTAV, contare il numero di caselle, ad essa
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

SN
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica MxS
• per ogni modulo elencato nella tabella MxS, contare il numero di caselle, ad esso
Come misurare
relative, contrassegnate con una "x"
Controlli da effettuare nessuno

NT5NF
Chi deve misurare ingegnere del software
Quando misurare durante l'attività di raccolta delle misure (attività 1.6)
• considerare lo schema della base di dati presente nei documenti di progetto
Come misurare • contare il numero di tabelle in quinta forma normale contenute nello schema della
base di dati
Controlli da effettuare nessuno

NT
Chi deve misurare ingegnere del software
durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per
Quando misurare
la metrica TAV
Come misurare • contare il numero di tabelle elencate in TAV
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 275


MxMMODRIUS
Chi deve misurare ingegnere del software
Quando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)
• riportare in una tabella cross-reference i moduli elencati nella metrica M e i due
tipi "modificato" e "riusato"
• considerare i valori rilevati con la metrica M e la scheda descrizione degli
interventi prodotta nell'attività di specifica delle modifiche alle componenti
(attività 4.2)
Come misurare • per ogni modulo nella tabella, considerare la scheda degli interventi e
contrassegnare con una "x" la casella corrispondente a "modificato" se il modulo è
stato sottoposto a modifiche (anche eliminato, diviso o fuso con altri moduli)
• per ogni modulo della tabella, considerare la structure chart (o anche la call graph)
della nuova versione del sistema e contrassegnare con una "x" la casella
corrispondente a "riusato" se il modulo è presente nella structure chart
Controlli da effettuare nessuno

NMRIUS
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "riusato"
Controlli da effettuare nessuno

NMMOD
Chi deve misurare ingegnere del software
al termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver
Quando misurare
raccolto le misure per la metrica MxMMODRIUS
Come misurare • contare il numero di "x" corrispondenti al tipo di modulo "modificato"
Controlli da effettuare nessuno

Caso di studio Ingegneria del Software II 276


Caso di studio Ingegneria del Software II 277
Caso di studio Ingegneria del Software II 278
Fogli metrici

Indice dei fogli metrici


Goal G1 pag. 278

Caso di studio Ingegneria del Software II 279


OGGETTO SCOPO OBIETTIVO DI QUALITÀ PUNTO DI VISTA CONTESTO
G1 sistema software GEFIN D.F. migliorare information hiding ingegnere del software corso di Ingegneria del
Software II
QUALITY FOCUS FATTORI DI VARIAZIONE
- Modularità:
• esperienza del team di progetto nella progettazione della struttura del sistema
ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) Metriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC
accoppiamento di un modulo
DI numero di parametri-dato di input al modulo • esperienza del team di progetto nella progettazione delle interfacce tra le singole
DO numero di parametri-dato di output del modulo componenti del sistema
CI numero di parametri di controllo di input al modulo Metriche influenzate: MDS, ACC, GD, GC
CO numero di parametri di controllo di output del modulo
GD numero di variabili globali utilizzate come dati nel modulo • esperienza del team di progetto nella progettazione delle basi di dati
GC numero di variabili globali utilizzate per controllo dal modulo Metriche influenzate: PT5NF
FANIN numero di moduli che richiamano il modulo
FANOUT numero di moduli richiamati dal modulo
• esperienza del team di progetto nel miglioramento della qualità del sistema
Metriche influenzate: TM, SN, ACC
TM: distribuzione della tipologia dei moduli tra i moduli del sistema

MNS: numero di moduli che nascondono un segreto

MDS: numero di moduli che conoscono la struttura di un dato

MTS: numero di moduli che conoscono la struttura di una tavola

SN: numero di segreti nascosti per modulo

PT5NF = NT5NF / NT : normalizzazione della base di dati


NT5NF: numero di tavole in 5NF presenti nel database
NT: numero di tavole presenti nel database

- Riusabilità:

SN: numero di segreti nascosti per modulo

FANIN: numero di moduli che usano un modulo

Caso di studio Ingegneria del Software II 280


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS

Caso di studio Ingegneria del Software II 281


- Modularità: • esperienza del team di progetto nella progettazione della struttura del sistema

ACC: massimo 0.860 per tutti i moduli esclusi i moduli di servizio e quelli di  la maggiore esperienza nel ripartire la struttura del sistema secondo le funzioni principali
svolte, comporta una migliore distribuzione della tipologia dei moduli (basso valore di TM);
controllo per i quali valori vicini a 1 sono accettabili; compreso
in particolare, delegando l'accesso ai dati a una sola tipologia di moduli si riduce al minimo il
strettamente tra 0.860 e 0.900 per massimo il 2% dei moduli di sistema numero di moduli che conoscono le singole componenti della base di dati (MTS)
(esclusi i moduli prima citati)
 la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate
CI: massimo 1 per il 2% dei moduli del sistema comporta un basso numero di segreti nascosti dallo stesso modulo (SN) oltre che
pari a 0 per il restante 99%; l'abbassamento del numero di moduli che conoscono lo stesso segreto (MNS)
CO: pari a 0 per tutti i moduli del sistema;
 la maggiore esperienza nel progettare moduli che implementano una singola funzione
GD: pari a 0 per tutti i moduli del sistema; comporta la diminuzione dell'interconnessione tra i moduli, e quindi dell'accoppiamento
GC: pari a 0 per tutti i moduli del sistema; (ACC), in particolare diminuisce la necessità dell'uso di dati di controllo (CO, CI e GC)

TM: pari a 1 per tutti i moduli del sistema;  la maggiore esperienza nell'identificare nei moduli del sistema funzioni ricorrenti più volte,
nell'estrarre queste funzioni e nell'inserire ognuna di esse in singoli moduli, comporta
l'aumento del fan-in di questi moduli (FANIN)
MNS: massimo 4 per tutti i segreti;
• esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti del
MDS: massimo 4 per tutte le strutture dati escluse quelle che fanno parte sistema
dell'interfaccia delle componenti riusabili del sistema;
 la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di
MTS: pari a 0 per tutte le tavole del sistema; controllo (mediante chiamata/sincronizzazione) o allo scambio (in input/output) dei soli dati
necessari, comporta la diminuzione dell'accoppiamento dei moduli (ACC). Inoltre se i dati
scambiati sono dati elementari e non strutture dati, si ottiene la diminuzione del numero di
SN: massimo 1 per tutti i moduli del sistema; moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi moduli

PT5NF: pari a 1;  la maggiore esperienza nel limitare la possibilità di scambio di dati tra i moduli al solo uso
della loro interfaccia, comporta la diminuzione della necessità di usare variabili globali (GD
- Riusabilità: e GC) e quindi la diminuzione dell'accoppiamento dei moduli (ACC)

• esperienza del team di progetto nella progettazione delle basi di dati


SN: pari a 1 per tutti i moduli del sistema;
 la maggiore esperienza nel metodo della decomposizione senza perdita o nell'uso del data
FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili modelling comporta una migliore normalizzazione della base di dati (PT5NF)
esternamente; compreso tra il 5% e il 30% dei moduli del sistema
per i moduli riusabili internamente; minore del 5% dei moduli del • esperienza del team di progetto nel miglioramento della qualità del sistema
sistema per i moduli generici
 la maggiore esperienza del team di progetto nell'applicazione delle euristiche e dei principi
dell'information hiding prestando attenzione che l'applicazione di una euristica o di un
principio non vada in conflitto con altri, comporta la riduzione del rischio che interventi tesi
a migliorare una metrica producano come effetto collaterale il peggioramento di altri (TM,
SN, ACC)

Caso di studio Ingegneria del Software II 282


Caso di studio Ingegneria del Software II 283
Misure

INDICE DELLE METRICHE:


ACC pag. 302
CI pag. 296
CO pag. 297
DI pag. 294
DO pag. 295
FANIN pag. 300
FANOUT pag. 301
GC pag. 299
GD pag. 298
M pag. 282
MDS pag. 306
MNS pag. 305
MTS pag. 307
MxS pag. 288
MxT pag. 291
MxTAV pag. 293
NMOD pag. 283
NT pag. 309
NT5NF pag. 308
PT5NF pag. 310
S pag. 287
SD pag. 286
SDxM pag. 292
SN pag. 304
T pag. 284
TAV pag. 285
TM pag. 303

Caso di studio Ingegneria del Software II 284


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: M
VALORE RILEVATO:

CODICE MODULO
M1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa
M2 Calcolare Disponibilità di Cassa Non Impegnata
M3 Calcolare Prenotazione Non Impegnata
M4 Calcolare Situazione Eco./Fin.
M5 Consolidare Automaticamente Prenotazione
M6 Consolidare Entrate
M7 Consolidare Manualmente Finanziamento
M8 Consolidare Manualmente Prenotazione
M9 Controllare Consistenza Cancellazione Entrata
M10 Controllare Consistenza Cancellazione Finanziamento
M11 Controllare Consistenza Cancellazione Impegno
M12 Controllare Consistenza Cancellazione Prenotazione
M13 Controllare Consistenza Creazione Entrata
M14 Controllare Consistenza Creazione Finanziamento
M15 Controllare Consistenza Creazione Impegno
M16 Controllare Consistenza Creazione Prenotazione
M17 Controllare Consistenza Modifica Entrata
M18 Controllare Consistenza Modifica Finanziamento
M19 Controllare Consistenza Modifica Impegno
M20 Controllare Consistenza Modifica Prenotazione
M21 Controllare Consistenza Creazione Pagamento
M22 Inserire Pagamento Maggiore
M23 Controllare Scadenze
M24 Convertire Valuta
M25 Data Banker
M26 Data Banker Create
M27 Data Banker Delete
M28 Data Banker Read
M29 Data Banker Update
M30 Gestire Schermate
M31 Inserire Entrata
M32 Inserire Finanziamento
M33 Inserire Impegno
M34 Inserire Pagamento
M35 Inserire Pagamento Prenotazione Esaurita
M36 Inserire Prenotazione
M37 Leggere Metadati
M38 Main
M39 Modificare/Cancellare Entrata
M40 Modificare/Cancellare Finanziamento
M41 Modificare/Cancellare Impegno
M42 Modificare/Cancellare Prenotazione
M43 Navigare Entrate
M44 Navigare Finanziamenti
M45 Navigare Impegni
M46 Navigare Pagamenti
M47 Navigare Prenotazioni
M48 Selezionare Finanziamento da Consolidare
M49 Selezionare Prenotazione da Consolidare
M50 Trattare Errori
M51 Acquisire Parametri Navigazione Finanziamenti
M52 Acquisire Parametri Navigazione Entrate
M53 Acquisire Parametri Navigazione Prenotazioni
M54 Acquisire Parametri Navigazione Impegni NOTE: viene indicato anche il
M55 Acquisire Parametri Navigazione Pagamenti codice in modo da rendere più
M56 Inserire Pagamento Minore leggibili le tabelle delle
M57 Inserire Pagamento Uguale successive metriche, nelle quali
M58 Generare Chiave Automaticamente
M59 Consolidare Automaticamente Finanziamento verrà usato il codice al posto del
M60 Controllare Consistenza Creazione Impegno Senza Prenotazione nome del modulo

Caso di studio Ingegneria del Software II 285


Caso di studio Ingegneria del Software II 286
DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,1
METRICA: NMOD
VALORE RILEVATO: 60

Caso di studio Ingegneria del Software II 287


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: T
VALORE RILEVATO:

TIPOLOGIA
Controllo
Afferente
Efferente
Trasformazione
Data Banker

Caso di studio Ingegneria del Software II 288


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: TAV
VALORE RILEVATO:

TAVOLA
Finanziamenti
Entrate
Prenotazioni
Impegni
Pagamenti
Finanziamenti Entrate
Finanziamenti Prenotazioni
Prenotazioni Impegni
Impegni Pagamenti

Caso di studio Ingegneria del Software II 289


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SD
VALORE RILEVATO:

STRUTTURA DATI
CREATE_IMP
db_request
db_result
JoinTab
INS_RIC
Metadati
MOD_CANC_RIC
RIC
TipoValuta

Caso di studio Ingegneria del Software II 290


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: S
VALORE RILEVATO:

CODICE SEGRETO
S1 algoritmo di conversione valuta (Euro-Lire)
S2 algoritmo per la generazione automatica della chiave di un record
S3 D.B.M.S. usato
S4 gestione della situazione di un aumento di un impegno e della prenotazione che non riesce a coprirlo
S5 gestione dell'interfaccia grafica
S6 gestione messaggistica di errore
S7 metodo per il calcolo della disponibilità di cassa non impegnata
S8 metodo per il calcolo della parte di prenotazione non impegnata
S9 metodo per il calcolo della situazione economica e finanziaria
S10 metodo per il consolidamento automatico di un finanziamento
S11 metodo per il consolidamento automatico di una entrata
S12 metodo per il consolidamento automatico di una prenotazione
S13 metodo per il consolidamento manuale di un finanziamento
S14 metodo per il consolidamento manuale di una prenotazione
S15 metodo per la cancellazione di un finanziamento
S16 metodo per la cancellazione di un impegno
S17 metodo per la cancellazione di una entrata
S18 metodo per la cancellazione di una prenotazione
S19 metodo per la modifica di un finanziamento
S20 metodo per la modifica di un impegno
S21 metodo per la modifica di una entrata
S22 metodo per la modifica di una prenotazione
S23 metodo per l'aggiornamento della situazione economica e finanziaria
S24 metodo per l'individuazione delle scadenze
S25 metodo per l'inserimento di un nuovo finanziamento
S26 metodo per l'inserimento di un nuovo impegno
S27 metodo per l'inserimento di un nuovo pagamento quando l'importo è uguale all'impegno
S28 metodo per l'inserimento di un nuovo pagamento quando l'importo è maggiore dell'impegno
S29 metodo per l'inserimento di un nuovo pagamento quando l'importo è minore dell'impegno
S30 metodo per l'inserimento di una nuova entrata
S31 metodo per l'inserimento di una nuova prenotazione
S32 modalità di presentazione dati richiesti per la navigazione degli impegni
S33 modalità di presentazione dati richiesti per la navigazione dei finanziamenti
S34 modalità di presentazione dati richiesti per la navigazione dei pagamenti
S35 modalità di presentazione dati richiesti per la navigazione delle entrate
S36 modalità di presentazione dati richiesti per la navigazione delle prenotazioni
S37 modalità di presentazione dati richiesti per la variazione degli impegni
S38 modalità di presentazione dati richiesti per la variazione dei finanziamenti
S39 modalità di presentazione dati richiesti per la variazione delle entrate
S40 modalità di presentazione dati richiesti per la variazione delle prenotazioni
S41 modalità di presentazione dati richiesti per l'inserimento degli impegni
S42 modalità di presentazione dati richiesti per l'inserimento dei finanziamenti
S43 modalità di presentazione dati richiesti per l'inserimento dei pagamenti
S44 modalità di presentazione dati richiesti per l'inserimento delle entrate
S45 modalità di presentazione dati richiesti per l'inserimento delle prenotazioni
S46 modalità di presentazione finanziamenti consolidabili manualmente
S47 modalità di presentazione prenotazioni consolidabili manualmente
S48 operazioni da eseguire al lancio del sistema
S49 ricerca entrate e modalità di presentazione risultati
S50 ricerca finanziamenti e modalità di presentazione risultati
S51 ricerca impegni e modalità di presentazione risultati
S52 ricerca pagamenti e modalità di presentazione risultati
S53 ricerca prenotazioni e modalità di presentazione risultati
S54 accesso ai metadati
S55 accesso ai servizi offerti dal data banker

NOTE: viene indicato anche il codice in modo da rendere più leggibili le tabelle delle successive metriche, nelle quali
verrà usato il codice al posto del nome del segreto

Caso di studio Ingegneria del Software II 291


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,2
METRICA: MxS
VALORE RILEVATO: (le righe contengono i segreti, le colonne i moduli)

M10

M12

M13

M14

M15

M16

M17

M18

M19

M20

M21

M22

M23

M24
M11
M1

M2

M3

M4

M5

M6

M7

M8

M9
S1 x
S2
S3
S4
S5
S6
S7 x
S8 x
S9 x
S10
S11 x
S12 x
S13 x
S14 x
S15 x
S16 x
S17 x
S18 x
S19 x
S20 x
S21 x
S22 x
S23 x
S24 x
S25 x
S26 x
S27
S28 x
S29
S30 x
S31 x
S32
S33
S34
S35
S36
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 292


M37
M25

M26

M27

M28

M29

M30

M31

M32

M33

M34

M35

M36

M38

M39

M40

M41

M42

M43

M44

M45

M46

M47

M48

M49

M50
S1
S2
S3 x x x x
S4 x
S5 x
S6 x
S7
S8
S9
S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26
S27
S28
S29
S30
S31
S32
S33
S34
S35
S36
S37 x
S38 x
S39 x
S40 x
S41 x
S42 x
S43 x
S44 x
S45 x
S46 x
S47 x
S48 x
S49 x
S50 x
S51 x
S52 x
S53 x
S54 x
S55 x

Caso di studio Ingegneria del Software II 293


M51

M52

M53

M54

M55

M56

M57

M58

M59

M60
S1
S2 x
S3
S4
S5
S6
S7
S8
S9
S10 x
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S22
S23
S24
S25
S26 x
S27 x
S28
S29 x
S30
S31
S32 x
S33 x
S34 x
S35 x
S36 x
S37
S38
S39
S40
S41
S42
S43
S44
S45
S46
S47
S48
S49
S50
S51
S52
S53
S54
S55

Caso di studio Ingegneria del Software II 294


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,3
METRICA: MxT
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tipologie)
Controllo Afferente Efferente Trasformazione Data Banker
M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x
M16 x
M17 x
M18 x
M19 x
M20 x
M21 x
M22 x
M23 x
M24 x
M25 x
M26 x
M27 x
M28 x
M29 x
M30 x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37 x
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50 x
M51 x
M52 x
M53 x
M54 x
M55 x
M56 x
M57 x
M58 x
M59 x
M60 x

Caso di studio Ingegneria del Software II 295


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: SDxM
VALORE RILEVATO: (le righe contengono i moduli, le colonne le strutture dati)

db_reques

TipoValut
CANC_R
CREATE

INS_RIC
db_result

Metadati
JoinTab

MOD_
_IMP

RIC
IC

a
t

M1 x
M2 x
M3 x
M4 x
M5 x
M6 x
M7 x
M8 x
M9 x
M10 x
M11 x
M12 x
M13 x
M14 x
M15 x x
M16 x
M17 x
M18 x
M19 x
M20 x
M21
M22 x
M23 x
M24 x
M25 x
M26 x x
M27 x
M28 x x
M29 x x
M30 x x
M31 x
M32 x
M33 x
M34 x
M35 x
M36 x
M37
M38 x
M39 x
M40 x
M41 x
M42 x
M43 x
M44 x
M45 x
M46 x
M47 x
M48 x
M49 x
M50
M51 x
M52 x
M53 x
M54 x
M55 x
M56 x
M57 x
M58
M59 x

Caso di studio Ingegneria del Software II 296


M60 x x

DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,4
METRICA: MxTAV
VALORE RILEVATO: (le righe contengono i moduli, le colonne le tavole)
menti
Finanzia

Entrate

oni
Prenotazi

Impegni

i
Pagament

Entrate
menti
Finanzia
oni
Prenotazi
menti
Finanzia

Impegni
oni
Prenotazi

i
Pagament
Impegni
M1
M2
M3
M4
M5
M6
M7
M8
M9
M10
M11
M12
M13
M14
M15
M16
M17
M18
M19
M20
M21
M22
M23
M24
M25
M26
M27
M28
M29
M30
M31
M32
M33
M34
M35
M36
M37
M38
M39
M40
M41
M42
M43 NOTE: l'assenza di
M44 corrispondenze è dovuta
M45 all'uso del data banker
M46 per l'accesso ai dati nel
M47
M48 sistema: infatti, il data
M49 banker è implementato
M50 in modo da costruire
M51 automaticamente, sulla
M52 base dei metadati, le
M53
M54
richieste per l'accesso al
M55 database.
M56
M57
M58
M59

Caso di studio Ingegneria del Software II 297


M60

DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DI
VALORE RILEVATO:

M1 3
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 2
M14 1
M15 1
M16 2
M17 3
M18 2
M19 3
M20 3
M21 2
M22 2
M23 0
M24 1
M25 1
M26 3
M27 2
M28 2
M29 1
M30 0
M31 0
M32 0
M33 0
M34 0
M35 2
M36 0
M37 1
M38 0
M39 0
M40 0
M41 0
M42 0
M43 1
M44 1
M45 1
M46 1
M47 1
M48 0
M49 0
M50 1
M51 0
M52 0
M53 0
M54 0
M55 0
M56 2
M57 2
M58 2
M59 1
M60 1

Caso di studio Ingegneria del Software II 298


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: DO
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 0
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 0
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 2
M32 2
M33 2
M34 2
M35 1
M36 2
M37 1
M38 0
M39 1
M40 1
M41 1
M42 1
M43 0
M44 0
M45 0
M46 0
M47 0
M48 1
M49 1
M50 0
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 299


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CI
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 1
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 300


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: CO
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 301


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GD
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 302


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: GC
VALORE RILEVATO:

M1 0
M2 0
M3 0
M4 0
M5 0
M6 0
M7 0
M8 0
M9 0
M10 0
M11 0
M12 0
M13 0
M14 0
M15 0
M16 0
M17 0
M18 0
M19 0
M20 0
M21 0
M22 0
M23 0
M24 0
M25 0
M26 0
M27 0
M28 0
M29 0
M30 0
M31 0
M32 0
M33 0
M34 0
M35 0
M36 0
M37 0
M38 0
M39 0
M40 0
M41 0
M42 0
M43 0
M44 0
M45 0
M46 0
M47 0
M48 0
M49 0
M50 0
M51 0
M52 0
M53 0
M54 0
M55 0
M56 0
M57 0
M58 0
M59 0
M60 0

Caso di studio Ingegneria del Software II 303


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: FANIN
VALORE RILEVATO:

M1 9
M2 3
M3 4
M4 1
M5 3
M6 1
M7 1
M8 2
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 2
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 20
M25 48
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 4
M38 0
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 2
M59 1
M60 1

Caso di studio Ingegneria del Software II 304


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: FANOUT
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 2
M5 3
M6 1
M7 2
M8 2
M9 2
M10 1
M11 2
M12 1
M13 2
M14 1
M15 4
M16 1
M17 2
M18 1
M19 2
M20 1
M21 3
M22 5
M23 1
M24 0
M25 4
M26 2
M27 1
M28 1
M29 2
M30 17
M31 2
M32 1
M33 2
M34 2
M35 1
M36 2
M37 0
M38 24
M39 2
M40 2
M41 2
M42 2
M43 2
M44 2
M45 2
M46 2
M47 2
M48 1
M49 1
M50 0
M51 2
M52 2
M53 2
M54 2
M55 2
M56 3
M57 3
M58 0
M59 2
M60 4

Caso di studio Ingegneria del Software II 305


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: ACC
VALORE RILEVATO:

M1 0.928
M2 0.857
M3 0.857
M4 0.666
M5 0.875
M6 0.750
M7 0.800
M8 0.833
M9 0.800
M10 0.750
M11 0.800
M12 0.750
M13 0.833
M14 0.750
M15 0.857
M16 0.833
M17 0.857
M18 0.800
M19 0.857
M20 0.833
M21 0.857
M22 0.888
M23 0.500
M24 0.958
M25 0.981
M26 0.857
M27 0.800
M28 0.800
M29 0.800
M30 0.947
M31 0.800
M32 0.750
M33 0.800
M34 0.800
M35 0.800
M36 0.800
M37 0.833
M38 0.958
M39 0.750
M40 0.750
M41 0.750
M42 0.750
M43 0.750
M44 0.750
M45 0.750
M46 0.750
M47 0.750
M48 0.666
M49 0.666
M50 0.500
M51 0.750
M52 0.750
M53 0.750
M54 0.750
M55 0.750
M56 0.857
M57 0.857
M58 0.800
M59 0.800
M60 0.857

Caso di studio Ingegneria del Software II 306


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: TM
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 1
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 307


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5, Q1,6
METRICA: SN
VALORE RILEVATO:

M1 1
M2 1
M3 1
M4 1
M5 1
M6 1
M7 1
M8 1
M9 1
M10 1
M11 1
M12 1
M13 1
M14 1
M15 1
M16 1
M17 1
M18 1
M19 1
M20 1
M21 0
M22 1
M23 1
M24 1
M25 1
M26 1
M27 1
M28 1
M29 1
M30 1
M31 1
M32 1
M33 1
M34 1
M35 1
M36 1
M37 1
M38 1
M39 1
M40 1
M41 1
M42 1
M43 1
M44 1
M45 1
M46 1
M47 1
M48 1
M49 1
M50 1
M51 1
M52 1
M53 1
M54 1
M55 1
M56 1
M57 1
M58 1
M59 1
M60 1

Caso di studio Ingegneria del Software II 308


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MNS
VALORE RILEVATO:

S1 1
S2 1
S3 4
S4 1
S5 1
S6 1
S7 1
S8 1
S9 1
S10 1
S11 1
S12 1
S13 1
S14 1
S15 1
S16 1
S17 1
S18 1
S19 1
S20 1
S21 1
S22 1
S23 1
S24 1
S25 1
S26 2
S27 1
S28 1
S29 1
S30 1
S31 1
S32 1
S33 1
S34 1
S35 1
S36 1
S37 1
S38 1
S39 1
S40 1
S41 1
S42 1
S43 1
S44 1
S45 1
S46 1
S47 1
S48 1
S49 1
S50 1
S51 1
S52 1
S53 1
S54 1
S55 1

Caso di studio Ingegneria del Software II 309


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MDS
VALORE RILEVATO:

CREATE_IMP 2
db_request 1
db_result 48
JoinTab 3
INS_RIC 1
Metadati 4
MOD_CANC_RIC 1
RIC 1
TipoValuta 1

NOTE: il valore 48 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 310


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: MTS
VALORE RILEVATO:

Finanziamenti 0
Entrate 0
Prenotazioni 0
Impegni 0
Pagamenti 0
Finanziamenti Entrate 0
Finanziamenti Prenotazioni 0
Prenotazioni Impegni 0
Impegni Pagamenti 0

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema: infatti, il data banker
è implementato in modo da costruire automaticamente, sulla base dei metadati, le richieste per l'accesso al database.

Caso di studio Ingegneria del Software II 311


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT5NF
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 312


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: NT
VALORE RILEVATO: 9

Caso di studio Ingegneria del Software II 313


DATA DI CONSEGNA: 16/01/2001 NOME DEL MISURATORE: de Felice D. Diego

GOAL: G1
QUESTION: Q1,5
METRICA: PT5NF
VALORE RILEVATO: 1

Caso di studio Ingegneria del Software II 314


Distanze dagli obiettivi
INDICE DELLE METRICHE:
CI pag. 312
CO pag. 313
FANIN pag. 316
ACC pag. 317
GC pag. 315
GD pag. 314
MDS pag. 321
MNS pag. 320
MTS pag. 322
PT5NF pag. 323
SN pag. 319
TM pag. 318

NOTE:

• una distanza pari a 0 indica il raggiungimento della baseline hypothesis; un valore diverso invece quantifica la
distanza tra il valore rilevato e la baseline hypothesis

• una distanza pari a nessuna indica il raggiungimento della baseline hypothesis

• una distanza pari a rientra indica che il valore rilevato è migliore di quello indicato nella baseline hypothesis

• le distanze segnate in grassetto indicano le metriche che non hanno raggiunto le baseline hypothesis (cioè il valore
rilevato è peggiore)

• per alcune metriche è indicato eccezione, ovvero il valore rilevato è peggiore della baseline hypothesis ma si ritiene
che la metrica abbia dato risultati positivi per i motivi spiegati nelle note o tra le distanze stesse

Caso di studio Ingegneria del Software II 315


METRICA: CI
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 0
M2 0 0
M3 0 0
M4 0 0
M5 0 0
M6 0 0
M7 0 0
M8 0 0
M9 0 0
M10 0 0
M11 0 0
M12 0 0
M13 0 0
M14 0 0
M15 0 0
M16 0 0
M17 0 0
M18 0 0
M19 0 0
M20 0 0
M21 0 0
M22 0 0
M23 0 0
M24 1 1
M25 0 0
M26 0 0
M27 0 0
M28 0 0
M29 0 0
M30 0 0
M31 0 0
M32 0 0
M33 0 0
M34 0 0
M35 0 0
M36 0 0
M37 0 0
M38 0 0
M39 0 0
M40 0 0
M41 0 0
M42 0 0
M43 0 0
M44 0 0
M45 0 0
M46 0 0
M47 0 0
M48 0 0
M49 0 0
M50 0 0
M51 0 0
M52 0 0
M53 0 0
M54 0 0
M55 0 0
M56 0 0
M57 0 0
M58 0 0
M59 0 0
M60 0 0

NOTE: il numero di moduli con CI pari a 1 è uguale a 1, quindi essendo al di sotto del 2% dei moduli del sistema, la
baseline hypothesis è stata raggiunta.

Caso di studio Ingegneria del Software II 316


METRICA: CO
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 317


METRICA: GD
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 318


METRICA: GC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0 nessuna
M2 0 nessuna
M3 0 nessuna
M4 0 nessuna
M5 0 nessuna
M6 0 nessuna
M7 0 nessuna
M8 0 nessuna
M9 0 nessuna
M10 0 nessuna
M11 0 nessuna
M12 0 nessuna
M13 0 nessuna
M14 0 nessuna
M15 0 nessuna
M16 0 nessuna
M17 0 nessuna
M18 0 nessuna
M19 0 nessuna
M20 0 nessuna
M21 0 nessuna
M22 0 nessuna
M23 0 nessuna
M24 0 nessuna
M25 0 nessuna
M26 0 nessuna
M27 0 nessuna
M28 0 nessuna
M29 0 nessuna
M30 0 nessuna
M31 0 nessuna
M32 0 nessuna
M33 0 nessuna
M34 0 nessuna
M35 0 nessuna
M36 0 nessuna
M37 0 nessuna
M38 0 nessuna
M39 0 nessuna
M40 0 nessuna
M41 0 nessuna
M42 0 nessuna
M43 0 nessuna
M44 0 nessuna
M45 0 nessuna
M46 0 nessuna
M47 0 nessuna
M48 0 nessuna
M49 0 nessuna
M50 0 nessuna
M51 0 nessuna
M52 0 nessuna
M53 0 nessuna
M54 0 nessuna
M55 0 nessuna
M56 0 nessuna
M57 0 nessuna
M58 0 nessuna
M59 0 nessuna
M60 0 nessuna

Caso di studio Ingegneria del Software II 319


METRICA: FANIN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 9 nessuna (r.i.)
M2 3 nessuna (r.i.)
M3 4 nessuna (r.i.)
M4 1 nessuna (g.)
M5 3 nessuna (r.i.)
M6 1 nessuna (g.)
M7 1 nessuna (g.)
M8 2 nessuna (g.)
M9 1 nessuna (g.)
M10 1 nessuna (g.)
M11 1 nessuna (g.)
M12 1 nessuna (g.)
M13 1 nessuna (g.)
M14 1 nessuna (g.)
M15 1 nessuna (g.)
M16 2 nessuna (g.)
M17 1 nessuna (g.)
M18 1 nessuna (g.)
M19 1 nessuna (g.)
M20 1 nessuna (g.)
M21 1 nessuna (g.)
M22 1 nessuna (g.)
M23 1 nessuna (g.)
M24 20 nessuna (r.e.)
M25 48 nessuna (r.e.)
M26 1 nessuna (g.)
M27 1 nessuna (g.)
M28 1 nessuna (g.)
M29 1 nessuna (g.)
M30 1 nessuna (g.)
M31 1 nessuna (g.)
M32 1 nessuna (g.)
M33 1 nessuna (g.)
M34 1 nessuna (g.)
M35 1 nessuna (g.)
M36 1 nessuna (g.)
M37 4 nessuna (r.i.)
M38 0 nessuna (g.)
M39 1 nessuna (g.)
M40 1 nessuna (g.)
M41 1 nessuna (g.)
M42 1 nessuna (g.)
M43 1 nessuna (g.)
M44 1 nessuna (g.)
M45 1 nessuna (g.)
M46 1 nessuna (g.)
M47 1 nessuna (g.)
M48 1 nessuna (g.)
M49 1 nessuna (g.)
M50 1 nessuna (g.)
M51 1 nessuna (g.)
M52 1 nessuna (g.)
M53 1 nessuna (g.)
M54 1 nessuna (g.)
M55 1 nessuna (g.)
M56 1 nessuna (g.)
M57 1 nessuna (g.)
M58 2 nessuna (g.)
M59 1 nessuna (g.)
M60 1 nessuna (g.)

NOTE: Le sigle r.i., r.e. e g. sono le abbreviazioni di riusabile internamente, riusabile esternamente e generico

Caso di studio Ingegneria del Software II 320


METRICA: ACC
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 0.928 eccezione (FANIN alto)
M2 0.857 rientra
M3 0.857 rientra
M4 0.666 rientra
M5 0.875 eccezione (FANIN alto)
M6 0.750 rientra
M7 0.800 rientra
M8 0.833 rientra
M9 0.800 rientra
M10 0.750 rientra
M11 0.800 rientra
M12 0.750 rientra
M13 0.833 rientra
M14 0.750 rientra
M15 0.857 rientra
M16 0.833 rientra
M17 0.857 rientra
M18 0.800 rientra
M19 0.857 rientra
M20 0.833 rientra
M21 0.857 rientra
M22 0.888 rientra nel 2%
M23 0.500 rientra
M24 0.958 eccezione (FANIN alto)
M25 0.981 eccezione (FANIN alto)
M26 0.857 rientra
M27 0.800 rientra
M28 0.800 rientra
M29 0.800 rientra
M30 0.947 eccezione (modulo di controllo)
M31 0.800 rientra
M32 0.750 rientra
M33 0.800 rientra
M34 0.800 rientra
M35 0.800 rientra
M36 0.800 rientra
M37 0.833 rientra
M38 0.958 eccezione (modulo di controllo)
M39 0.750 rientra
M40 0.750 rientra
M41 0.750 rientra
M42 0.750 rientra
M43 0.750 rientra
M44 0.750 rientra
M45 0.750 rientra
M46 0.750 rientra
M47 0.750 rientra
M48 0.666 rientra
M49 0.666 rientra
M50 0.500 rientra
M51 0.750 rientra
M52 0.750 rientra
M53 0.750 rientra
M54 0.750 rientra
M55 0.750 rientra
M56 0.857 rientra
M57 0.857 rientra
M58 0.800 rientra
M59 0.800 rientra
M60 0.857 rientra

Caso di studio Ingegneria del Software II 321


METRICA: TM
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 1 nessuna
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 1 nessuna
M44 1 nessuna
M45 1 nessuna
M46 1 nessuna
M47 1 nessuna
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna
M51 1 nessuna
M52 1 nessuna
M53 1 nessuna
M54 1 nessuna
M55 1 nessuna
M56 1 nessuna
M57 1 nessuna
M58 1 nessuna
M59 1 nessuna
M60 1 nessuna

Caso di studio Ingegneria del Software II 322


METRICA: SN
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
M1 1 nessuna
M2 1 nessuna
M3 1 nessuna
M4 1 nessuna
M5 1 nessuna
M6 1 nessuna
M7 1 nessuna
M8 1 nessuna
M9 1 nessuna
M10 1 nessuna
M11 1 nessuna
M12 1 nessuna
M13 1 nessuna
M14 1 nessuna
M15 1 nessuna
M16 1 nessuna
M17 1 nessuna
M18 1 nessuna
M19 1 nessuna
M20 1 nessuna
M21 0 rientra
M22 1 nessuna
M23 1 nessuna
M24 1 nessuna
M25 1 nessuna
M26 1 nessuna
M27 1 nessuna
M28 1 nessuna
M29 1 nessuna
M30 1 nessuna
M31 1 nessuna
M32 1 nessuna
M33 1 nessuna
M34 1 nessuna
M35 1 nessuna
M36 1 nessuna
M37 1 nessuna
M38 1 nessuna
M39 1 nessuna
M40 1 nessuna
M41 1 nessuna
M42 1 nessuna
M43 1 nessuna
M44 1 nessuna
M45 1 nessuna
M46 1 nessuna
M47 1 nessuna
M48 1 nessuna
M49 1 nessuna
M50 1 nessuna
M51 1 nessuna
M52 1 nessuna
M53 1 nessuna
M54 1 nessuna
M55 1 nessuna
M56 1 nessuna
M57 1 nessuna
M58 1 nessuna
M59 1 nessuna
M60 1 nessuna

Caso di studio Ingegneria del Software II 323


METRICA: MNS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
S1 1 nessuna
S2 1 nessuna
S3 4 nessuna
S4 1 nessuna
S5 1 nessuna
S6 1 nessuna
S7 1 nessuna
S8 1 nessuna
S9 1 nessuna
S10 1 nessuna
S11 1 nessuna
S12 1 nessuna
S13 1 nessuna
S14 1 nessuna
S15 1 nessuna
S16 1 nessuna
S17 1 nessuna
S18 1 nessuna
S19 1 nessuna
S20 1 nessuna
S21 1 nessuna
S22 1 nessuna
S23 1 nessuna
S24 1 nessuna
S25 1 nessuna
S26 2 nessuna
S27 1 nessuna
S28 1 nessuna
S29 1 nessuna
S30 1 nessuna
S31 1 nessuna
S32 1 nessuna
S33 1 nessuna
S34 1 nessuna
S35 1 nessuna
S36 1 nessuna
S37 1 nessuna
S38 1 nessuna
S39 1 nessuna
S40 1 nessuna
S41 1 nessuna
S42 1 nessuna
S43 1 nessuna
S44 1 nessuna
S45 1 nessuna
S46 1 nessuna
S47 1 nessuna
S48 1 nessuna
S49 1 nessuna
S50 1 nessuna
S51 1 nessuna
S52 1 nessuna
S53 1 nessuna
S54 1 nessuna
S55 1 nessuna

Caso di studio Ingegneria del Software II 324


METRICA: MDS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
RILEVATO Distanza
CREATE_IMP 2 rientra
db_request 1 rientra
db_result 48 eccezione (vedere note)
JoinTab 3 rientra
INS_RIC 1 rientra
Metadati 4 rientra
MOD_CANC_RIC 1 rientra
RIC 1 rientra
TipoValuta 1 rientra

NOTE: il valore 48 per la struttura dati db_result sebbene elevato, è giustificato dal fatto che questa struttura dati è usata
dal data banker per restituire i dati ai moduli che richiedono un servizio ad esso, quindi facendo parte dell'interfaccia del
data banker, la struttura di db_result deve essere necessariamente conosciuta da tutti i moduli che richiedono un servizio
al data banker.

Caso di studio Ingegneria del Software II 325


METRICA: MTS
DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE
DISTANZA
RILEVATO
Finanziamenti 0 nessuna
Entrate 0 nessuna
Prenotazioni 0 nessuna
Impegni 0 nessuna
Pagamenti 0 nessuna
Finanziamenti Entrate 0 nessuna
Finanziamenti Prenotazioni 0 nessuna
Prenotazioni Impegni 0 nessuna
Impegni Pagamenti 0 nessuna

NOTE: il valore 0 per ogni tavola è dovuto all'uso del data banker per l'accesso ai dati nel sistema.

Caso di studio Ingegneria del Software II 326


METRICA: PT5NF
VALORE RILEVATO: 1
DISTANZA DALLA BASELINE HYPHOTESIS: nessuna

Caso di studio Ingegneria del Software II 327


Appendice A
Processo di sviluppo Software

INDICE:

Work Flow Diagrams pag. 325


Scenari Procedurali pag. 331
Descrizione Manufatti pag. 345

NOTE:

Di seguito viene riportato il processo di sviluppo software originale. Per ottenere il processo di sviluppo software
migliorato è necessario seguire le indicazioni presenti nei manufatti "Miglioramento del processo di sviluppo software"
al fine di ottenere la versione definitiva.

Caso di studio Ingegneria del Software II 328


Work Flow Diagrams
Contesto

PIANO METRICO

DESCRIZIONE DEL PROBLEMA


FONTI DEI REQUISITI Problema
PIANO DI SVILUPPO SOFTWARE
0

DOCUMENTI DI
COMPONENTI CONFIGURATE REQUISITI UTENTE SVILUPPO
DOCUMENTI ANALISI DEI REQUISITI
PIANO METRICO

STANDARD
Analisi PIANO DI TEST DI SISTEMA

DIFETTI E MISURE (ANALISI)


OBIETTIVI
1

DOCUMENTI DI PROGETTO
REQUISITI INFORMATICI

PIANO METRICO
Progetto DIFETTI E MISURE (PROGETTO)

PIANO DI TEST DI INTEGRAZIONE


STANDARD
2

DOCUMENTI DI PROGETTO CODICE

STANDARD Codifica PIANO DI TEST DI UNITÀ

PIANO METRICO DIFETTI E MISURE (CODIFICA)


3

CODICE
DOCUMENTI DEL TESTING
Testing
PIANO DI TEST
4

Caso di studio Ingegneria del Software II 329


0 Problema

FONTI DEI REQUISITI

Definire gli obiettivi


Descrivere il di business e di
problema qualità
0.1 0.2

DESCRIZIONE DEL OBIETTIVI


PROBLEMA

Scegliere il piano di
sviluppo del
software
0.3 Definire il piano
metrico
0.4

PIANO DI SVILUPPO PIANO METRICO


SOFTWARE

Caso di studio Ingegneria del Software II 330


1 Analisi

REQUISITI UTENTE

Costruire il modello
e-r Costruire i DFD

1.1 1.4

MODELLO E-R DFDS

Specificare le Specificare le Specificare i flussi


Specificare le entità
relazioni funzioni elementari dei Data Flow
1.2
1.3 1.5 1.6

ATTRIBUTI DI ATTRIBUTI E SPECIFICHE DELLE


FUNZIONI ELEMENTARI
DIZIONARIO DEI DATI
CIASCUNA ENTITÀ FUNZIONALITÀ DI
(ANALISI)
CIASCUNA RELAZIONE

PIANO METRICO STANDARD DOCUMENTI ANALISI DEI REQUISITI OBIETTIVI

Rilevare le misure di Verificare Validare Definire i requisiti


qualità non funzionali
1.7 1.9 1.10 1.8
DIFETTI DA VERIFICA DIFETTI DA REQUISITI NON
(ANALISI) VALIDAZIONE (ANALISI) FUNZIONALI

MISURE (ANALISI) DIFETTI (ANALISI) Definire il piano di


test di sistema
1.11

PIANO DI TEST DI
SISTEMA

DIFETTI E MISURE
(ANALISI)

Caso di studio Ingegneria del Software II 331


2 Progetto
REQUISITI INFORMATICI

DIZIONARIO DEI DATI (ANALISI)


REQUISITI UTENTE DFDS

Fondere le funzioni SPECIFICHE DELLE MODELLO E-R


FUNZIONI ELEMENTARI
2.1

DFD FUSO

Costruire la
structure chart
2.2
STRUCTURE CHART
Definire il
diagramma delle
dipendenze e delle
tabelle normalizzate
Definire le specifiche 2.4
dei moduli
2.3 TAVOLE E PERCORSI DI DIAGRAMMA
NAVIGAZIONE DELLE
SPECIFICHE DEI MODULI DIPENDENZE

Rifinire la structure chart e


le specifiche dei moduli
2.5
STRUCTURE CHART SPECIFICHE DEI MODULI
AGGIORNATA AGGIORNATE

Costruire la cross Definire le strutture dei file Definire il dizionario


reference RExDS esterni e dei dati globali dei dati (progetto)
2.8 2.6 2.7
MATRICE CROSS- DEFINIZIONE DELLE DIZIONARIO DEI DATI
REFERENCEREXDS STRUTTURE DEI FILE (PROGETTO)
ESTERNI E DEI DATI
GLOBALI

DOCUMENTI INTERNI DI
PIANO METRICO
PROGETTO STANDARD

Pianificare la
realizzazione dei Validare Verificare Rilevare le misure di
requisiti utente qualità
2.10 2.12 2.11 2.9
REQUISITI A RISCHIO VINCOLI DI DIFETTI DA DIFETTI DA VERIFICA
PROGRAMMAZIONE
VALIDAZIONE (PROGETTO) MISURE
(PROGETTO) (PROGETTO)

Definire il piano di test DIFETTI (PROGETTO)


di sistema

2.13 DOCUMENTI DI
PROGETTO

PIANO DI TEST DI MISURE E DIFETTI


INTEGRAZIONE (PROGETTO)

Caso di studio Ingegneria del Software II 332


3 Codifica

DOCUMENTI DI PROGETTO

Implementare il
VINCOLI DI progetto
PROGRAMMAZIONE
3.1

CODICE SORGENTE

Compilare il
programma
3.2

CODICE OGGETTO CODICE SORGENTE


CORRETTO

CODICE

STANDARD
PIANO METRICO

Verificare il rispetto Validare Verificare Rilevare misure di


dei vincoli qualità
3.4 3.6 3.5 3.3

VINCOLI DI DIFETTI DA DIFETTI DA


PROGRAMMAZIONE A
VALIDAZIONE VERIFICA (CODIFICA)

RISCHIO
(CODIFICA)
MISURE
(CODIFICA)

Definire il piano di DIFETTI (CODIFICA)


test di unità
3.7

PIANO DI TEST DI
UNITÀ

DIFETTI E MISURE
(CODIFICA)

Caso di studio Ingegneria del Software II 333


4 Testing

PIANO DI TEST

PIANO DI TEST DI
UNITÀ
PIANO DI TEST DI
PIANO DI TEST DI ACCETTAZIONE
CODICE PIANO DI TEST DI
INTEGRAZIONE
SISTEMA

Eseguire il test di Eseguire il test di Eseguire il test di Eseguire il test di


unità integrazione sistema accettazione
4.1 4.2 4.3 4.4

DOCUMENTI DEL TESTING

Caso di studio Ingegneria del Software II 334


Scenari Procedurali

0 Problema

0.1 Descrivere il problema


I.S.C.: Prodotti di input disponibili

Input: Fonti dei requisiti

Procedura:

1. Descrivere il problema in testo libero dando tutti i riferimenti necessari per poter eseguire l'analisi

Output: Descrizione del problema

I.E.C.: Prodotti di output realizzati

0.2 Definire gli obiettivi di business e di qualità


I.S.C.: Prodotti di input disponibili

Input: Fonti dei requisiti

Procedura:

1. Descrivere gli obiettivi di business e quelli qualitativi dando tutti i riferimenti necessari per poter
definire il piano metrico

Output: Obiettivi

I.E.C.: Prodotti di output realizzati

0.3 Scegliere il piano di sviluppo del software


I.S.C.: Prodotti di input disponibili

Input: Descrizione del problema, Obiettivi

Procedura:

1. Sulla base delle caratteristiche del progetto, scegliere il modello di processo più adeguato (di
seguito è descritto il classico Waterfall)

Output: Piano di sviluppo software

I.E.C.: Prodotti di output realizzati

0.4 Definire il piano metrico


I.S.C.: Prodotti di input disponibili

Caso di studio Ingegneria del Software II 335


Input: Obiettivi

Procedura:

1. Descrivere il piano metrico dettagliando gli obiettivi

Output: Piano metrico

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 336


1 Analisi

1.1 Costruire il modello E-R


I.S.C.: Prodotti di input disponibili

Input: Requisiti utente

Procedura:

1. Individuare le entità del sistema


2. Fornire una definizione operativa per ciascuna entità
3. Ricercare le relazioni utili al sistema
4. Per ciascuna relazione individuata
4.1 Fornire una definizione operativa
4.2 Specificare la cardinalità e le entità che essa coinvolge
4.3 Definire il ruolo delle entità che essa coinvolge
4.4 Fornire le obbligatorietà

Output: Modello E-R

I.E.C.: Prodotti di output realizzati

1.2 Specificare le entità


I.S.C.: Prodotti di input disponibili

Input: Requisiti utente, Modello E-R

Procedura:

1. Per ciascuna entità


1.1 Fornire gli attributi
1.2 Indicare gli attributi chiave

Output: Attributi di ciascuna entità

I.E.C.: Prodotti di output realizzati

1.3 Specificare le relazioni


I.S.C.: Prodotti di input disponibili

Input: Requisiti utente, Modello E-R

Procedura:

1. Per ciascuna relazione


1.1 Specificare gli eventuali attributi
1.2 Specificare la funzionalità

Output: Attributi e funzionalità di ciascuna relazione

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 337


1.4 Costruire i DFD
I.S.C.: Prodotti di input disponibili

Input: Requisiti utente

Procedura:

1. Individuare tutti gli agenti esterni e/o depositi di dati che forniscono i dati di ingresso primari del
sistema e/o ricevono i dati di uscita primari da esso
2. Rappresentare il sistema a livello 0 attraverso un DFD composto da un'unica funzione che
trasforma i dati di ingresso primari nei corrispondenti dati di uscita primari
3. Al livello i (i=0,1,…) individuare le funzioni non elementari candidate ad essere esplose al livello
successivo con i relativi flussi di dati
4. Per ciascuna funzione non elementare individuata a livello i (i=0,1,…) costruire un DFD di livello
i+1 che descrive in maggior dettaglio il suo significato in termini di altre, più semplici funzioni, e
che preserva la continuità del flusso di informazioni
5. Eseguire iterativamente i passi 3 e 4 fino ad ottenere solo funzioni elementari

Output: DFDs

I.E.C.: Prodotti di output realizzati

1.5 Specificare le funzioni elementari


I.S.C.: Prodotti di input disponibili

Input: Requisiti utente, DFDs

Procedura:

1. Per ciascuna funzione elementare individuata


1.1 Definire una descrizione informale testuale
1.2 Definire una descrizione algoritmica

Output: Specifiche delle funzioni elementari

I.E.C.: Prodotti di output realizzati

1.6 Specificare i flussi dei Data Flow


I.S.C.: Prodotti di input disponibili

Input: Requisiti utente, DFDs

Procedura:

1. Per ciascun flusso di informazione, data store o entità esterna


1.1 Specificare il nome primario ed eventuali altri nomi utilizzati per individuarlo
1.2 Fornire una descrizione testuale
1.3 Elencare i processi che lo referenziano indicando in quale modo
1.4 Descrivere formalmente il contenuto utilizzando gli operatori di sequenza, selezione,
opzionalità e ripetizione

Output: Dizionario dei dati (analisi)

Caso di studio Ingegneria del Software II 338


I.E.C.: Prodotti di output realizzati
1.7 Rilevare le misure di qualità
I.S.C.: Prodotti di input disponibili

Input: Documenti analisi dei requisiti, Piano metrico

Procedura:

1. Rilevare le misure di qualità secondo il piano metrico

Output: Misure (analisi)

I.E.C.: Prodotti di output realizzati

1.8 Definire i requisiti non funzionali


I.S.C.: Prodotti di input disponibili

Input: Obiettivi

Procedura:

1. Definire tutti i requisiti dell'applicazione che non sono esprimibili attraverso le specifiche
funzionali ed informazionali
2. Classificare i requisiti non funzionali individuati in obbligatori ed opzionali
3. Esprimere il rango in termini di valore che i requisiti obbligatori hanno per il committente

Output: Requisiti non funzionali

I.E.C.: Prodotti di output realizzati

1.9 Verificare
I.S.C.: Prodotti di input disponibili

Input: Standard, Documenti analisi dei requisiti

Procedura:

1. Applicare le euristiche per migliorare i parametri di qualità che non sono conformi allo standard
prestabilito

Output: Difetti da verifica (analisi)

I.E.C.: Prodotti di output realizzati

1.10 Validare
I.S.C.: Prodotti di input disponibili

Input: Documenti analisi dei requisiti

Procedura:

Caso di studio Ingegneria del Software II 339


1. Validare con il committente che quanto specificato corrisponda ai suoi requisiti

Output: Difetti da validazione (analisi)

I.E.C.: Prodotti di output realizzati

1.11 Definire il piano di test di sistema


I.S.C.: Prodotti di input disponibili

Input: Documenti analisi dei requisiti, Requisiti non funzionali

Procedura:

1. Definire il piano di test di sistema tenendo conto che tutti i requisiti, funzionali e non devono essere
coperti. Il numero di casi di test per requisiti deve essere il risultato della mediazione tra costo del
test ed affidabilità richiesta al sistema software. La mediazione deve essere fatta per ogni requisito

Output: Piano di test di sistema

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 340


2 Progetto

2.1 Fondere le funzioni


I.S.C.: Prodotti di input disponibili

Input: DFDs

Procedura:

1. Fondere tutti i DFD che contengono funzioni elementari


2. Dividere il DFD fuso in unità di progetto

Output: DFD fuso

I.E.C.: Prodotti di output realizzati

2.2 Costruire la Structure Chart


I.S.C.: Prodotti di input disponibili

Input: DFD fuso, Specifiche delle funzioni elementari

Procedura:

1. Derivare la struttura del programma


2. Trasformare il DFD fuso nella prima versione della Structure Chart
3. Dettagliare la Structure Chart utilizzando le specifiche delle funzioni elementari
4. Aggiungere i moduli gestione dell'interfaccia di I/O
5. Aggiungere i moduli di gestione dei report
6. Migliorare la Structure Chart utilizzando le euristiche
7. Migliorare la Structure Chart secondo i principi dell'Information Hiding

Output: Structure Chart

I.E.C.: Prodotti di output realizzati

2.3 Definire le specifiche dei moduli


I.S.C.: Prodotti di input disponibili

Input: Structure Chart

Procedura:

1. Per ciascun modulo individuato


1.1 Definire la specifica semantica e la specifica sintattica
1.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo
1.3 Descrivere i dati referenziati
1.4 Definire gli altri moduli che esso utilizza

Output: Specifiche dei moduli

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 341


2.4 Definire il diagramma delle dipendenze e le tabelle normalizzate
I.S.C.: Prodotti di input disponibili

Input: Modello E-R, Specifiche delle funzioni elementari

Procedura:

1. Elaborare la lista delle dipendenze


2. Elaborare il diagramma delle dipendenze
3. Costruire le tabelle normalizzate e i percorsi di navigazione

Output: Tavole e percorsi di navigazione, Diagramma delle dipendenze

I.E.C.: Prodotti di output realizzati

2.5 Rifinire la Structure Chart e le specifiche dei moduli


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli, Structure Chart, Tavole e percorsi di navigazione

Procedura:

1. Aggiungere i moduli per la gestione dei dati


2. Migliorare la Structure Chart utilizzando le euristiche
3. Migliorare la Structure Chart secondo i principi dell'Information Hiding
4. Per ciascun modulo aggiunto o modificato
4.1 Definire la specifica semantica e la specifica sintattica
4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo
4.3 Descrivere i dati referenziati
4.4 Definire gli altri moduli che esso utilizza

Output: Structure Chart aggiornata, Specifiche dei moduli aggiornate

I.E.C.: Prodotti di output realizzati

2.6 Definire le strutture dei file esterni e dei dati globali


I.S.C.: Prodotti di input disponibili

Input: Specifiche dei moduli aggiornate, Tavole e percorsi di navigazione, Dizionario dei dati (analisi)

Procedura:

1. Individuare l'insieme di file di dati esterni


2. Per ciascun file esterno individuato
2.1 Definire la struttura logica
2.2 Descrivere i record logici
2.3 Definire la modalità di accesso
3. Individuare l'insieme dei dati globali fornendo per ciascuno di essi la struttura
4. Costruire una matrice Cross Reference che associa ciascun dato globale/file esterno al modulo che
lo implementa

Output: Definizione delle strutture dei file esterni e dei dati globali

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 342


2.7 Definire il dizionario dei dati (progetto)
I.S.C.: Prodotti di input disponibili

Input: Dizionario dei dati (analisi), Diagramma delle dipendenze, Requisiti informatici

Procedura:

1. Per ciascuna struttura dati, indicare le componenti e il relativo tipo di dato

Output: Dizionario dei dati (progetto)

I.E.C.: Prodotti di output realizzati

2.8 Costruire la Cross Reference RExDS


I.S.C.: Prodotti di input disponibili

Input: Structure Chart aggiornata, Requisiti utente

Procedura:

1. Costruire la matrice Cross Reference per stabilire in quale parte del progetto è implementato
ciascun requisito

Output: Matrice Cross Reference RExDS

I.E.C.: Prodotti di output realizzati

2.9 Rilevare le misure di qualità


I.S.C.: Prodotti di input disponibili

Input: Documenti interni di progetto, Piano metrico

Procedura:

1. Rilevare le misure di qualità secondo il piano metrico

Output: Misure (progetto)

I.E.C.: Prodotti di output realizzati

2.10 Pianificare le realizzazioni dei requisiti utente


I.S.C.: Prodotti di input disponibili

Input: Documenti interni di progetto, Requisiti utente

Procedura:

1. Verificare quali requisiti non funzionali sono stati realizzati


2. Se esistono altri requisiti che si possono soddisfare con il progetto
2.1 Modificare il progetto

Caso di studio Ingegneria del Software II 343


2.2 Riprendere l'esecuzione dalla attività 2.8 della fase di progetto
3. Trasformare gli altri requisiti in vincoli di programmazione
4. Se esistono altri accorgimenti che il progettista vuole dettare al programmatore
4.1 Formulare altri vincoli

Output: Vincoli di programmazione, Requisiti a rischio

I.E.C.: Prodotti di output realizzati

2.11 Verificare
I.S.C.: Prodotti di input disponibili

Input: Documenti interni di progetto, Standard

Procedura:

1. Applicare le euristiche per migliorare i parametri di qualità che non sono conformi allo standard
prestabilito

Output: Difetti da verifica (progetto)

I.E.C.: Prodotti di output realizzati

2.12 Validare
I.S.C.: Prodotti di input disponibili

Input: Documenti interni di progetto

Procedura:

1. Validare con l'analista che quanto specificato corrisponda ai suoi requisiti

Output: Difetti da validazione (progetto)

I.E.C.: Prodotti di output realizzati

2.13 Definire il piano di test di integrazione


I.S.C.: Prodotti di input disponibili

Input: Documenti interni di progetto, Requisiti utente, Requisiti a rischio

Procedura:

1. Definire il piano di test di integrazione tenendo conto che tutte le cause di rischio che i requisiti non
siano rispettati, devono essere coperte

Output: Piano di test di integrazione

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 344


3 Codifica

3.1 Implementare il progetto


I.S.C.: Prodotti di input disponibili

Input: Documenti di progetto

Procedura:

1. Realizzare il codice
2. Realizzare la base di dati

Output: Codice sorgente

I.E.C.: Prodotti di output realizzati

3.2 Compilare il programma


I.S.C.: Prodotti di input disponibili

Input: Codice sorgente

Procedura:

1. Compilare il programma
2. Se esistono errori sintattici
2.1 Correggere gli errori
2.2 Ripetere dal passo 1

Output: Codice sorgente corretto, Codice oggetto

I.E.C.: Prodotti di output realizzati

3.3 Rilevare le misure di qualità


I.S.C.: Prodotti di input disponibili

Input: Codice, Piano metrico

Procedura:

1. Rilevare le misure di qualità secondo il piano metrico

Output: Misure (codifica)

I.E.C.: Prodotti di output realizzati

3.4 Verificare il rispetto dei vincoli


I.S.C.: Prodotti di input disponibili

Caso di studio Ingegneria del Software II 345


Input: Codice, Vincoli di programmazione

Procedura:

1. Verificare che i vincoli di programmazione siano stati rispettati


2. Se esistono vincoli non rispettati
2.1 Modificare il programma
2.2 Ripetere dall'attività 3.2 della fase di codifica

Output: Vincoli di programmazione a rischio

I.E.C.: Prodotti di output realizzati

3.5 Verificare
I.S.C.: Prodotti di input disponibili

Input: Codice, Standard

Procedura:

1. Applicare le euristiche per migliorare i parametri di qualità che non sono conformi allo standard
prestabilito

Output: Difetti da verifica (codifica)

I.E.C.: Prodotti di output realizzati

3.6 Validare
I.S.C.: Prodotti di input disponibili

Input: Codice

Procedura:

1. Validare con il progettista che quanto specificato corrisponda ai suoi vincoli

Output: Difetti da validazione (codifica)

I.E.C.: Prodotti di output realizzati

3.7 Definire il piano di test di unità


I.S.C.: Prodotti di input disponibili

Input: Codice, Vincoli di programmazione, Vincoli di programmazione a rischio

Procedura:

1. Definire il piano di test di unità tenendo conto che tutte le cause di rischio che i vincoli non siano
rispettati, devono essere coperte

Output: Piano di test di unità

Caso di studio Ingegneria del Software II 346


I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 347


4 Testing

4.1 Eseguire il test di unità


I.S.C.: Prodotti di input disponibili

Input: Codice, Piano di test di unità

Procedura:

1. Realizzare i casi di test


2. Eseguire i casi di test
3. Rilevare gli eventuali difetti, classificarli e registrarli

Output: Documenti del testing

I.E.C.: Prodotti di output realizzati

4.2 Eseguire il test di integrazione


I.S.C.: Prodotti di input disponibili, eseguita l'attività 4.1 della fase di testing

Input: Codice, Piano di test di integrazione

Procedura:

1. Realizzare i casi di test


2. Eseguire i casi di test
3. Rilevare gli eventuali difetti, classificarli e registrarli

Output: Documenti del testing

I.E.C.: Prodotti di output realizzati

4.3 Eseguire il test di sistema


I.S.C.: Prodotti di input disponibili, eseguita l'attività 4.2 della fase di testing

Input: Codice, Piano di test di sistema

Procedura:

1. Realizzare i casi di test


2. Eseguire i casi di test
3. Rilevare gli eventuali difetti, classificarli e registrarli

Output: Documenti del testing

I.E.C.: Prodotti di output realizzati

4.4 Eseguire il test di accettazione

Caso di studio Ingegneria del Software II 348


I.S.C.: Prodotti di input disponibili, eseguita l'attività 4.3 della fase di testing

Input: Codice, Piano di test di accettazione

Procedura:

1. Realizzare i casi di test


2. Eseguire i casi di test
3. Rilevare gli eventuali difetti, classificarli e registrarli

Output: Documenti del testing

I.E.C.: Prodotti di output realizzati

Caso di studio Ingegneria del Software II 349


Descrizione Manufatti
• Attributi di ciascuna entità: descrizione delle caratteristiche di ciascuna entità del modello E-R

• Attributi e funzionalità di ciascuna relazione: descrizione dei legami logici tra le diverse entità del modello E-R
e delle eventuali caratteristiche dei suddetti legami

• Codice: risultato della compilazione del programma

Composizione: Codice sorgente corretto +


Codice oggetto

• Codice oggetto: risultato della compilazione del codice sorgente

• Codice sorgente: codice delle componenti software

• Codice sorgente corretto: codice sorgete rielaborato in modo da eliminare gli errori sintattici

• Componenti configurate: documentazione utilizzata durante le fasi di sviluppo del software

Composizione: Fonti dei requisiti +


Requisiti utente +
Obiettivi +
Standard +
Piano metrico +
Requisiti informatici +
Documenti di progetto +
Codice +
Piano di test

• Definizione delle strutture dei file esterni e dei dati globali: struttura logica, record logici e modalità di accesso
per ogni file esterno; struttura di ciascun dato globale; matrice Cross Reference file esterno/dato globale x modulo
che li usa

• Descrizione del problema: informazioni necessarie per poter eseguire la fase di analisi con i riferimenti alla fonte

• DFD fuso: risultato della fusione dei componenti del DFDs

• DFDs: descrizione dei requisiti funzionali dell'applicazione software. Ogni funzione deve essere identificata; le
funzioni possono essere articolate per livelli di dettaglio successivi. Le funzioni di livello più basso sono quelle
elementari

• Diagramma delle dipendenze: diagramma in cui sono indicati, per ciascun dato della base di dati, le dipendenze
rispetto agli altri dati

• Difetti (analisi): risultati delle attività di verifica e validazione dei documenti di analisi dei requisiti

Composizione: Difetti da verifica (analisi) +


Difetti da validazione (analisi)

• Difetti (codifica): risultati delle attività di verifica e validazione del codice

Composizione: Difetti da verifica (codifica) +


Difetti da validazione (codifica)

• Difetti (progetto): risultati delle attività di verifica e validazione dei documenti di progetto

Composizione: Difetti da verifica (progetto) +

Caso di studio Ingegneria del Software II 350


Difetti da validazione (progetto)

• Difetti da validazione (analisi): difformità dei documenti di analisi dei requisiti dai requisiti dell'utente

• Difetti da validazione (codifica): difformità del codice dai requisiti del progetto

• Difetti da validazione (progetto): difformità dei documenti di progetto dai requisiti dell'analisi

• Difetti da verifica (analisi): difformità dei documenti di analisi dei requisiti dallo standard prestabilito

• Difetti da verifica (codifica): difformità del codice dallo standard prestabilito

• Difetti da verifica (progetto): difformità dei documenti di progetto dallo standard prestabilito

• Difetti e misure (analisi): difetti e misure dei documenti dell'analisi dei requisiti

Composizione: Difetti (analisi) +


Misure (analisi)

• Difetti e misure (codifica): difetti e misure del codice

Composizione: Difetti (codifica) +


Misure (codifica)

• Difetti e misure (progetto): difetti e misure dei documenti di progetto

Composizione: Difetti (progetto) +


Misure (progetto)

• Dizionario dei dati (analisi): descrizione testuale dei flussi dei DFD, dei depositi e delle entità esterne

• Dizionario dei dati (progetto): descrizione delle strutture e dei dati usati nelle specifiche dei moduli

• Documenti analisi dei requisiti: documentazione ottenuta come risultato dell'analisi dei requisiti del software e
del sistema

Composizione: DFDs +
Dizionario dei dati (analisi) +
Specifica delle funzioni elementari +
Modello E-R +
Attributi di ciascuna entità +
Attributi e funzionalità di ciascuna relazione

• Documenti del testing: documentazione ottenuta come risultato dell'esecuzione della fase di testing incluso il data
base necessario alla riesecuzione del testing

• Documenti di progetto: documenti prodotti durante la fase di progetto

Composizione: Documenti interni di progetto +


Vincoli di programmazione

• Documenti di sviluppo: documentazione prodotta durante le fasi di sviluppo del software

Composizione: Descrizione del problema +


Piano metrico +
Piano di sviluppo software +
Documenti analisi dei requisiti +
Piano di test di sistema +
Difetti e misure (analisi) +

Caso di studio Ingegneria del Software II 351


Documenti di progetto +
Piano di test di integrazione +
Difetti e misure (progetto) +
Codice +
Piano di test di unità +
Difetti e misure (codice) +
Documenti del testing

• Documenti interni di progetto: documenti prodotti durante la fase di progetto, ad uso interno

Composizione: Structure Chart aggiornata +


Specifica dei moduli aggiornata +
Tavole e percorsi di navigazione +
Diagramma delle dipendenze +
Dizionario dei dati (progetto) +
Definizione delle strutture e dei file esterni e dei dati globali +
Matrice Cross Reference RexDS

• Fonti dei requisiti: idee del committente, letteratura del dominio applicativo e applicazioni simili o concorrenti già
sul mercato

• Matrice Cross Reference RexDS: matrice usata per stabilire in quale parte del progetto è implementato ciascun
requisito

• Misure (analisi): risultati dell'esecuzione del piano metrico applicato ai documenti di analisi dei requisiti

• Misure (codifica): risultati dell'esecuzione del piano metrico applicato al codice

• Misure (progetto): risultati dell'esecuzione del piano metrico applicato ai documenti di progetto

• Modello E-R: descrizione dei requisiti informativi dell'applicazione software: diagramma entità (E) – relazioni
(R). Esprime il contenuto informativo dell'applicazione dal punto di vista dell'utilizzatore finale

• Obiettivi: obiettivi di business e qualitativi con riferimenti per la loro migliore comprensione

• Piano di sviluppo del software: caratterizzazione del progetto e modello di processo di sviluppo scelto

• Piano di test: documentazione necessaria all'esecuzione del test

Composizione: Piano di test di unità |


Piano di test di integrazione |
Piano di test di sistema |
Piano di test di accettazione

• Piano di test di accettazione: specifiche dei casi di test necessari ad eseguire il test di accettazione

• Piano di test di integrazione: specifiche dei casi di test necessari ad eseguire il test di integrazione

• Piano di test di sistema: specifiche dei casi di test necessari ad eseguire il test di sistema

• Piano di test di unità: specifiche dei casi di test necessari ad eseguire il test di unità

• Piano metrico: Goal Question Metrics (GQM): insieme degli obiettivi (Goal) a cui il processo tende definendo dei
quesiti operativi (Question) che a loro volta richiedono misure quantitative e qualitative di processo e di prodotto,
definendo delle metriche (Metrics) utilizzate per dare risposte (misure) alle domande poste

Caso di studio Ingegneria del Software II 352


• Requisiti a rischio: requisiti che possono pregiudicare la conformità dell'applicazione software ai requisiti di
qualità

• Requisiti informatici: descrizione dei requisiti per il sistema software

Composizione: Requisiti utente +


Documenti analisi dei requisiti

• Requisiti non funzionali: requisiti dell'applicazione software che non sono esprimibili attraverso le specifiche
funzionali e informazionali

• Requisiti utente: descrizione in qualunque forma di quello che l'utente intende ottenere dal prodotto software

• Specifiche dei moduli: definizione dettagliata delle operazioni che ciascun modulo software deve eseguire

• Specifiche dei moduli aggiornata: rifinitura delle specifiche dei moduli necessaria all'allineamento con la
Structure Chart aggiornata

• Specifiche delle funzioni elementari: descrizione dettagliata delle operazioni di ciascuna funzione elementare dei
DFD

• Standard: modello di qualità adottato dall'impresa

• Structure Chart: espressione gerarchica delle relazioni fra i moduli e delle interfacce fra ogni coppia di essi

• Structure Chart aggiornata: rifinitura della Structure Chart utilizzando le euristiche e i principi dell'Information
Hiding

• Tavole e percorsi di navigazione: struttura dell'organizzazione della base di dati e insieme di percorsi logici per
navigarla

• Vincoli di programmazione: accorgimenti che il progettista detta al programmatore.

• Vincoli di programmazione a rischio: vincoli di programmazione il cui non soddisfacimento è un rischio per la
non conformità dell'applicazione software ai requisiti di qualità

Caso di studio Ingegneria del Software II 353


Riferimenti Bibliografici

[BAS94] Basili, V.R., C.Caldiera, H.D. Rombach, 'Goal Question Metric Paradigm', Encyclopedia of
Software Engineering (Marciniak, J.J., editor), Volume 1, John Wiley & Sons, 1994a, pp. 528-532;

[FRAN96] Fraunhofer Einrichtung Experimentelles Software Engineering, The PERFECT Handbook Volume 2
infrastructure technologies, "Goal-Oriented Measuremente Using GQM" booklet;

[PAR72] Parnas, D.L., "On Criteria To Be Used in Decomposing Systems into Modules", Communications of
the ACM 15(12) 1053-1058, 1972;

[PAR83] D.L. Parnas, P.C. Clements and D.M. Weiss, "Enhancing Reusability with Information Hiding", ITT
proceedings of the Workshop on Reusability in Programming, Newport, R.I., 1983;

[PRESM] R. S. Pressman, “Principi di Ingegneria del software”, Seconda Edizione, Mc Graw Hill;

[VIS99] G. Visaggio, dispense del corso di Ingegneria del Software I, A.A. 1999/2000;

[VIS00] G.Visaggio, dispense del corso di Ingegneria del Software II, A.A. 2000/2001;

[VSB99] Rini van Solingen, Egon Berghout, "The Goal/Question Metric Method", Mc Graw Hill, 1999

Caso di studio Ingegneria del Software II 354


Scheda rilevazione attività

ATTIVITÀ DATA RILEVAZIONE ORARIO INIZIO ORARIO FINE ANNOTAZIONI


Formalizzazione processo di
- 06/12/2000 16:00 19:00
miglioramento
Formalizzazione processo di
- 07/12/2000 16:00 20:00
miglioramento
Formalizzazione processo di
- 11/12/2000 17:00 19:00
miglioramento
Formalizzazione processo
- 12/12/2000 15:00 20:00
sviluppo software
Formalizzazione processo di
- 13/12/2000 16:00 20:00
miglioramento
Formalizzazione processo di
- 14/12/2000 17:00 21:00
miglioramento
Formalizzazione processo
- 15/12/2000 14:00 20:00
sviluppo software
Formalizzazione processo di
- 16/12/2000 16:00 20:00
miglioramento
1.1 17/12/2000 12:00 13:00 Inizio esecuzione 1
1.1 17/12/2000 16:00 22:00
1.2 18/12/2000 16:00 20:00
1.2 19/12/2000 16:00 20:00
1.2 20/12/2000 15:00 21:00
1.2 21/12/2000 16:00 19:00
1.3 22/12/2000 15:00 19:00
1.4 27/12/2000 14:00 21:00
1.4 28/12/2000 16:00 19:00
1.4 29/12/2000 15:00 20:00
1.5 30/12/2000 10:00 13:00
1.5 30/12/2000 15:00 20:00
1.6 02/01/2001 10:00 12:00
1.6 02/01/2001 16:00 20:00
1.6 03/01/2001 10:00 12:00
1.6 03/01/2001 16:00 20:00
2.1 04/01/2001 14:00 16:00
2.2 04/01/2001 16:00 16:15
3.1 04/01/2001 16:15 16:30
3.2 04/01/2001 16:30 18:00
4.1 05/01/2001 15:00 16:00
4.2 05/01/2001 16:00 19:00

Caso di studio Ingegneria del Software II 355


4.3 06/01/2001 15:30 21:00
4.3 07/01/2001 14:00 20:00
4.3 08/01/2001 15:00 19:30
Misurazione metriche del
1.6 08/01/2001 19:30 20:00
modello di conferma
1.6 09/01/2001 15:00 20:00 Inizio esecuzione 2

2.1 10/01/2001 15:00 17:00

2.2 10/01/2001 17:00 17:15

1.4 10/01/2001 17:15 17:25 Modifiche ai fogli metrici

3.1 10/01/2001 18:00 18:10

3.2 10/01/2001 18:10 18:15

4.1 10/01/2001 18:15 18:30

4.2 10/01/2001 18:30 20:00

4.3 11/01/2001 14:00 18:00

4.3 13/01/2001 16:00 20:30


Misurazione metriche del
1.6 13/01/2001 20:30 21:00
modello di conferma
1.6 15/01/2001 18:20 18:40 Inizio esecuzione 3

2.1 15/01/2001 18:40 19:00

2.2 15/01/2001 19:00 19:30

1.4 15/01/2001 19:45 20:00 Modifiche ai fogli metrici

1.6 16/01/2001 16:00 16:15 Inizio esecuzione 4

2.1 16/01/2001 16:15 16:30

2.2 16/01/2001 16:30 17:00

- 17/01/2001 15:00 20:00 Preparazione documenti

- 18/01/2001 15:00 20:00 Preparazione documenti

- 19/01/2001 16:00 20:00 Preparazione documenti


Revisione e correzione
- 20/01/2001 14:00 19:00
documenti
Preparazione materiale
- 22/01/2001 10:00 13:00
consegna

Caso di studio Ingegneria del Software II 356

Potrebbero piacerti anche