caso di studio ingegneria del software ii

Caso di studio Ingegneria del Software IIAnno accademico: 2000/2001

Contenuto della documentazione

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

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




Appendice A – Processo di sviluppo software pag. 324Riferimenti Bibliografici pag. 349Scheda 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


Work Flow Diagrams

Contesto


MISURARE IL SISTEMA

1

CARATTERIZZARE IL SISTEMA

2

INDIVIDUARE FATTORI DI VARIAZIONE E IPOTESI DI

MIGLIORAMENTO3

ESEGUIRE IL PROCESSO DI MIGLIORAMENTO

4

RICHIESTE DI MIGLIORAMENTO CONOSCENZA

SISTEMA SOFTWARE DA

MIGLIORARE

PUNTI DI DEBOLEZZA

IPOTESI DI MIGLIORAMENTO DEL SISTEMA SOFTWARE

FORMALIZZAZIONE DEL PROCESSO DI SVILUPPO SOFTWARE

IPOTESI DI VARIAZIONE DEI FOGLI METRICI

FOGLI METRICI

MISURE

SISTEMA SOFTWARE MODIFICATO

SISTEMA SOFTWARE

SISTEMA SOFTWARE

MIGLIORATO

MIGLIORAMENTO DEL PROCESSO DI SVILUPPO SOFTWARE

PIANO GQM

DISTANZE DAGLI OBIETTIVI

1. Misurare il sistema


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 I FOGLI METRICI

1.4

PRODURRE IL PIANO DI MISURAZIONI

1.5

RILEVARE LE MISURE

1.6

RICHIESTE DI MIGLIORAMENTO

CONOSCENZA

OBIETTIVI DI MISURAZIONE E MODELLI DI QUALITÀ

PIANO GQM DA VERIFICARE

PIANO GQM

PIANO DI MISURAZIONI

FOGLI METRICIMISURE

IPOTESI DI VARIAZIONE DEI

FOGLI METRICI

SISTEMA SOFTWARE

2. Caratterizzare il sistema


INTERPRETARE LE MISURE

2.1

INDIVIDUARE I PUNTI DI DEBOLEZZA

2.2

MISURE

FOGLI METRICI

IPOTESI DI VARIAZIONE DEI FOGLI METRICI

SISTEMA SOFTWARE MIGLIORATO

PUNTI DI DEBOLEZZA

PIANO GQM

SISTEMA SOFTWARE


3. Individuare fattori di variazione e ipotesi di miglioramento


INDIVIDUARE I FATTORI DI

VARIAZIONE3.1

INDIVIDUARE LE IPOTESI DI

MIGLIORAMENTO3.2

PUNTI DI DEBOLEZZA

FOGLI METRICI


FATTORI DI VARIAZIONE

4. Eseguire il processo di miglioramento


INDIVIDUARE GLI INTERVENTI DA EFFETTUARE

4.1

SPECIFICARE LE MODIFICHE ALLE

COMPONENTI4.2


SISTEMA SOFTWARE


FORMALIZZAZIONE DEL PROCESSO DI SVILUPPO SOFTWARE

SPECIFICHE DELLE MODIFICHE

SCHEDA DESCRIZIONE DEGLI INTERVENTI

MODIFICARE IL SISTEMA SOFTWARE

4.3

SISTEMA SOFTWARE MODIFICATO

MIGLIORAMENTO DEL PROCESSO DI SVILUPPO SOFTWARE

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 miglioramento1.1 Identificare l'obiettivo di misurazione che è espresso informalmente nella richiesta

2. Per ogni obiettivo di misurazione individuato2.1 Specificare l'oggetto da misurare2.2 Specificare lo scopo della misurazione2.3 Specificare l'obiettivo di qualità della misurazione2.4 Specificare il punto di vista dell'obiettivo della misurazione2.5 Specificare il contesto in cui avverrà la misurazione2.6 Usando la conoscenza, individuare i fattori di qualità che l'oggetto da misurare deve avere per soddisfare l'obiettivo2.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.


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

Procedura:

1. Per ogni obiettivo di misurazione, usando la conoscenza1.1 Riportare l'obiettivo di misurazione (Goal) ed etichettarlo come Gi, dove i è il numero dell'obiettivo preso in considerazione1.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.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


1.3 Verificare il piano GQM

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


Input: Piano GQM da verificare

Procedura:

(correttezza sintattica)1. Verificare che tutte le domande siano strutturate secondo lo schema della loro classe di appartenenza2. Verificare che tutte le domande siano classificate per sotto obiettivi3. 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 dettagliano5. Verificare la plausibilità delle relazioni tra domande ed obiettivi6. Verificare che tutte le metriche abbiano, nel loro dominio di definizione, tutti i valori necessari per rispondere esaurientemente alle rispettive domande7. Verificare che tutte le metriche siano operative8. Verificare che tutti gli schemi di interpretazione siano plausibili9. Verificare che le modalità di rappresentazione e sintesi delle metriche favoriscano la leggibilità

Output: Piano GQM


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 GQM1.1 Riportare nell'intestazione l'etichetta e la specifica dell'obiettivo1.2 Riportare nel I Quadrante i fattori di qualità (espressi nelle question del piano GQM) e tutte le

metriche ad essi relative1.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 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


Input: Piano GQM, Conoscenza

Procedura:

1. Individuare nel piano GQM le metriche che richiedono misure dirette2. Per ogni metrica diretta individuata, in base alla conoscenza

2.1 Definire tutti i controlli da effettuare sul valore della misura2.2 Definire chi deve raccogliere la misura2.3 Definire quando raccogliere la misura2.4 Definire come e con quali strumenti deve essere raccolta la misura

Output: Piano di misurazioni


1.6 Rilevare le misure

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


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 misurati2. Calcolare tutti i valori delle metriche indirette contenute nel piano GQM sulla base dei valori raccolti al passo 13. 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



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


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 hypothesis1.2 Valutare la distanza tra la misura e l'ipotesi1.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


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


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 metrici1.1.1.2 Designare il sistema software ad una nuova misurazione, anche se migliorato

Altrimenti1.1.1.3 Designare il sistema software ad essere consegnato all'utente

Altrimenti1.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 metrici1.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


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à


Input: Punti di debolezza, Fogli metrici

Procedura:

1. Per ogni fattore di qualità indicato come punto di debolezza1.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 carenti1.2 Indicare anche il foglio metrico di appartenenza

Output: Fattori di variazione


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à)


Input: Fattori di variazione, Fogli metrici

Procedura:

1. Per ogni fattore di qualità riportato1.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



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


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 intervenire2. 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


4.2 Specificare le modifiche alla componenti

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


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 intervento2.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


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.


Input: Specifiche delle modifiche, Sistema software

Procedura:

1. Per ogni piano esecutivo indicato nelle specifiche delle modifiche1.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



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:


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

Allo scopo discopo della misurazione (migliorare, valutare, predire, caratterizzare, ecc…)

Rispetto aobiettivo di qualità della misurazione (costo, affidabilità, manutenibilità, ecc…)

Dal punto di vista dipunto di vista dell'obiettivo della misurazione (utente, sviluppatore, management, ecc…)

Nel contesto dicontesto in cui avverrà la misurazione (nome del 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.


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.


Piano esecutivo esecuzione numero 1

del processo di miglioramento



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 I FOGLI METRICI

1.4

PRODURRE IL PIANO DI MISURAZIONI

1.5

RILEVARE LE MISURE

1.6

START


2.1


2.2

…


INDIVIDUARE I FATTORI DI VARIAZIONE

3.1

INDIVIDUARE LE IPOTESI DI MIGLIORAMENTO

3.2

…


4.1


COMPONENTI4.2


4.3

STOP

Manufatti dell'esecuzione numero 1



Indice dei manufatti usati e/o prodotti:

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


ConoscenzaPer 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]


Obiettivi di misurazione e modelli di qualità

Obiettivo di misurazione 1

Analizzare: sistema software GEFIN D.F.Allo scopo di: migliorarlo

Rispetto a: information hidingDal 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.


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.


G1Analizzare: sistema software GEFIN D.F.

Allo scopo di: migliorarloRispetto a: information hiding

Dal punto di vista di: ingegnere del softwareNel 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 chartNMOD numero di moduli presenti nella structure chart

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

S lista dei segreti nascosti nel sistemaMxS 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 sistemaSDxM per ogni struttura dato, il o i moduli che la conoscono (tabella cross-reference)

TAV lista delle tavole presenti nel database usato dal sistemaMxTAV 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 moduloDO per ogni modulo, il numero di parametri-dato di output del moduloCI per ogni modulo, il numero di parametri di controllo di input al moduloCO per ogni modulo, il numero di parametri di controllo di output del moduloGD per ogni modulo, il numero di variabili globali utilizzate come dati nel moduloGC per ogni modulo, il numero di variabili globali utilizzate per controllo dal moduloFANIN per ogni modulo, il numero di moduli che richiamano il moduloFANOUT per ogni modulo, il numero di moduli richiamati dal moduloACC = 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


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 databaseNT numero di tavole presenti nel databasePT5NF = 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à ?


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


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 nuovoNMMOD numero di moduli del vecchio sistema riusati nel nuovoPERMMOD = NMMOD / NMODPERMRIUS = 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


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.


G1Analizzare: sistema software GEFIN D.F.

Allo scopo di: migliorarloRispetto a: information hiding

Dal punto di vista di: ingegnere del softwareNel contesto di: corso di Ingegneria del Software II














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


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.






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.




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.


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.



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.



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






Piano di misurazioni

INDICE DELLE METRICHE:

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


M

Chi deve misurare ingegnere del softwareQuando misurare all'inizio dell'attività di raccolta delle misure (attività 1.6)

Come misurare considerare la structure chart del sistema (o anche la call graph) presente nei

documenti di progetto raccogliere e riportare i nomi di tutti i moduli distinti presenti in essa.

Controlli da effettuare nessuno

NMOD



documenti di progetto contare il numero di moduli distinti presenti in essa


S



documenti di progetto individuare e riportare i segreti (dettagli) distribuiti tra i moduli presenti in essa


MxS

Chi deve misurare ingegnere del software

Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per le metriche M ed S

Come misurare

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 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


Come misurare

considerare la structure chart del sistema (o anche la call graph) presente nei documenti di progetto

individuare e riportare le tipologie di moduli presenti nella structure chart (moduli efferenti, afferenti, di controllo, ecc…)



MxT


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per le metriche M e T

Come misurare

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 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

Controlli da effettuare ogni modulo nella tabella deve appartenere ad almeno una tipologia ogni tipologia nella tabella deve contenere almeno un modulo

SD


Come misurare considerare il dizionario dei dati presente nei documenti di progetto raccogliere e riportare le strutture di dati distinte presenti in esso


SDxM


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per le metriche M ed SD

Come misurare

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

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


Come misurare considerare lo schema della base di dati presente nei documenti di progetto raccogliere e riportare le tavole presenti in esso


MxTAV


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per le metriche M e TAV

Come misurare

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 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)


DI



Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per la metrica M

Come misurare

considerare i valori rilevati con la metrica M e le specifiche dei moduli presenti nei documenti di progetto

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"


DO



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"


CI



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"


CO



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"


GD



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)


GC

Chi deve misurare ingegnere del softwareQuando misurare durante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per


la metrica M

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)


FANIN



Come misurare

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

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

Controlli da effettuare il valore di FANIN deve essere maggiore o uguale a 1, tranne per il modulo di

livello 1 della structure chart

FANOUT



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


TM


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per la metrica MxT

Come misurare per ogni modulo elencato nella tabella MxT, contare il numero di caselle, ad esso

relative, contrassegnate con una "x"Controlli da effettuare il valore di TM deve essere maggiore o uguale a 1

MNS


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per la metrica MxS

Come misurare per ogni segreto elencato nella tabella MxS, contare il numero di caselle, ad esso

relative, contrassegnate con una "x"Controlli da effettuare il valore di MNS deve essere maggiore o uguale a 1

MDS



la metrica SDxM

Come misurare per ogni struttura dati elencata nella tabella SDxM, contare il numero di caselle,

ad essa relative, contrassegnate con una "x"Controlli da effettuare il valore di MDS deve essere maggiore o uguale a 1

MTS


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per la metrica MxTAV

Come misurare per ogni tavola elencata nella tabella MxTAV, contare il numero di caselle, ad

essa relative, contrassegnate con una "x"Controlli da effettuare nessuno

SN



Come misurare per ogni modulo elencato nella tabella MxS, contare il numero di caselle, ad esso

relative, contrassegnate con una "x"Controlli da effettuare nessuno

NT5NF

Chi deve misurare ingegnere del softwareQuando misurare durante l'attività di raccolta delle misure (attività 1.6)

Come misurare considerare lo schema della base di dati presente nei documenti di progetto contare il numero di tabelle in quinta forma normale contenute nello schema della

base di dati Controlli da effettuare nessuno

NT


Quando misuraredurante l'attività di raccolta delle misure (attività 1.6), dopo aver raccolto le misure per la metrica TAV

Come misurare contare il numero di tabelle elencate in TAV


MxMMODRIUS

Chi deve misurare ingegnere del softwareQuando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)


Come misurare

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)

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


NMRIUS


Quando misurareal termine della fase di esecuzione del processo di miglioramento (fase 4), dopo aver raccolto le misure per la metrica MxMMODRIUS

Come misurare contare il numero di "x" corrispondenti al tipo di modulo "riusato"


NMMOD



Come misurare contare il numero di "x" corrispondenti al tipo di modulo "modificato"



Fogli metrici

Indice dei fogli metrici

Goal G1 pag. 44


G1

OGGETTO

sistema software GEFIN D.F.SCOPO

migliorareOBIETTIVO DI QUALITÀ

information hidingPUNTO DI VISTA

ingegnere del softwareCONTESTO

corso di Ingegneria del Software II

QUALITY FOCUS FATTORI DI VARIAZIONE

- Modularità:

ACC = 1 – 1 / (DI+2CI+DO+2CO+GD+2GC+FANIN+FANOUT) accoppiamento di un modulo

DI numero di parametri-dato di input al moduloDO numero di parametri-dato di output del moduloCI numero di parametri di controllo di input al moduloCO numero di parametri di controllo di output del moduloGD numero di variabili globali utilizzate come dati nel moduloGC numero di variabili globali utilizzate per controllo dal moduloFANIN numero di moduli che richiamano il moduloFANOUT 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 datiNT5NF: numero di tavole in 5NF presenti nel databaseNT: numero di tavole presenti nel database

- Riusabilità:


FANIN: numero di moduli che usano un modulo

esperienza del team di progetto nella progettazione della struttura del sistemaMetriche influenzate: TM, MTS, SN, MNS, FANIN, ACC, CO, CI, GC

esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti del sistemaMetriche influenzate: MDS, ACC, GD, GC

esperienza del team di progetto nella progettazione delle basi di datiMetriche influenzate: PT5NF


BASELINE HYPOTHESIS IMPATTO SULLE BASELINE HYPOTHESIS

- Modularità:

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;

CI: massimo 1 per il 5% dei moduli del sistema pari a 0 per il restante 95%; CO: pari a 0 per tutti i moduli del sistema;GD: pari a 0 per tutti i moduli del sistema;GC: pari a 0 per tutti i moduli del sistema;

TM: pari a 1 per tutti i moduli del sistema;

MNS: massimo 4 per tutti i segreti;

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

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

SN: massimo 1 per tutti i moduli del sistema;

PT5NF: pari a 1;

- Riusabilità:

SN: pari a 1 per tutti i moduli del sistema;

FANIN: maggiore del 30% dei moduli del sistema per i moduli riusabili esternamente; compreso tra il 5% e il 30% dei moduli del sistema per i moduli riusabili internamente; minore del 5% dei moduli del sistema per i moduli generici

esperienza del team di progetto nella progettazione della struttura del sistema

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 si riduce al minimo il numero di moduli che conoscono le singole componenti della base di dati (MTS)

la maggiore esperienza nel nascondere i dettagli del sistema in componenti separate 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)

la maggiore esperienza nel progettare moduli che implementano una singola funzione 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)

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)

esperienza del team di progetto nella progettazione delle interfacce tra le singole componenti del sistema

la maggiore esperienza nel limitare le interazioni tra i moduli al semplice passaggio di 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 moduli che conoscono una struttura dati (MDS) in quanto localizzata a pochi moduli

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 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)


Misure


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

INDICE DELLE METRICHE DEL MODELLO DI CONFERMA:

MxMMODRIUS pag. 76NMMOD pag. 77NMRIUS pag. 78PERMMOD pag. 79PERMRIUS 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.


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

GOAL: G1

QUESTION: Q1,1

METRICA: MVALORE RILEVATO:

CODICE MODULOM1 Aggiornare Disponibilità Finanziaria e Disponibilità di CassaM2 Calcolare Disponibilità di Cassa Non ImpegnataM3 Calcolare Prenotazione Non ImpegnataM4 Calcolare Situazione Eco./Fin.M5 Consolidare AutomaticamenteM6 Consolidare EntrateM7 Consolidare Manualmente FinanziamentoM8 Consolidare Manualmente PrenotazioneM9 Controllare Consistenza Cancellazione EntrataM10 Controllare Consistenza Cancellazione FinanziamentoM11 Controllare Consistenza Cancellazione ImpegnoM12 Controllare Consistenza Cancellazione PrenotazioneM13 Controllare Consistenza Creazione EntrataM14 Controllare Consistenza Creazione FinanziamentoM15 Controllare Consistenza Creazione ImpegnoM16 Controllare Consistenza Creazione PrenotazioneM17 Controllare Consistenza Modifica EntrataM18 Controllare Consistenza Modifica FinanziamentoM19 Controllare Consistenza Modifica ImpegnoM20 Controllare Consistenza Modifica PrenotazioneM21 Controllare Consistenza Creazione PagamentoM22 Inserire Pagamento MaggioreM23 Controllare ScadenzeM24 Convertire ValutaM25 Data BankerM26 Data Banker CreateM27 Data Banker DeleteM28 Data Banker ReadM29 Data Banker UpdateM30 Gestire SchermateM31 Inserire EntrataM32 Inserire FinanziamentoM33 Inserire ImpegnoM34 Inserire PagamentoM35 Inserire Pagamento Prenotazione EsauritaM36 Inserire PrenotazioneM37 Leggere MetadatiM38 MainM39 Modificare/Cancellare EntrataM40 Modificare/Cancellare FinanziamentoM41 Modificare/Cancellare ImpegnoM42 Modificare/Cancellare PrenotazioneM43 Navigare EntrateM44 Navigare FinanziamentiM45 Navigare ImpegniM46 Navigare PagamentiM47 Navigare PrenotazioniM48 Selezionare Finanziamento da ConsolidareM49 Selezionare Prenotazione da ConsolidareM50 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



GOAL: G1

QUESTION: Q1,1

METRICA: NMODVALORE RILEVATO: 50



GOAL: G1

QUESTION: Q1,3

METRICA: TVALORE RILEVATO:

TIPOLOGIAControllo

Afferente

Efferente

Trasformazione

Data Banker



GOAL: G1

QUESTION: Q1,4

METRICA: TAVVALORE RILEVATO:

TAVOLAFinanziamentiEntratePrenotazioniImpegniPagamentiFinanziamenti EntrateFinanziamenti PrenotazioniPrenotazioni ImpegniImpegni Pagamenti



GOAL: G1

QUESTION: Q1,4

METRICA: SDVALORE RILEVATO:

STRUTTURA DATIdb_requestdb_resultJoinTabINS_RICMetadatiMOD_CANC_RICRICTipoValuta



GOAL: G1

QUESTION: Q1,2

METRICA: SVALORE RILEVATO:

CODICE SEGRETOS1 algoritmo di conversione valuta (Euro-Lire)S2 algoritmo per la generazione automatica della chiave di un recordS3 D.B.M.S. usatoS4 gestione della situazione di un aumento di un impegno e della prenotazione che non riesce a coprirloS5 gestione dell'interfaccia graficaS6 gestione messaggistica di erroreS7 metodo per il calcolo della disponibilità di cassa non impegnataS8 metodo per il calcolo della parte di prenotazione non impegnataS9 metodo per il calcolo della situazione economica e finanziariaS10 metodo per il consolidamento automatico di un finanziamentoS11 metodo per il consolidamento automatico di una entrataS12 metodo per il consolidamento automatico di una prenotazioneS13 metodo per il consolidamento manuale di un finanziamentoS14 metodo per il consolidamento manuale di una prenotazioneS15 metodo per la cancellazione di un finanziamentoS16 metodo per la cancellazione di un impegnoS17 metodo per la cancellazione di una entrataS18 metodo per la cancellazione di una prenotazioneS19 metodo per la modifica di un finanziamentoS20 metodo per la modifica di un impegnoS21 metodo per la modifica di una entrataS22 metodo per la modifica di una prenotazioneS23 metodo per l'aggiornamento della situazione economica e finanziariaS24 metodo per l'individuazione delle scadenzeS25 metodo per l'inserimento di un nuovo finanziamentoS26 metodo per l'inserimento di un nuovo impegnoS27 metodo per l'inserimento di un nuovo pagamento quando l'importo è uguale all'impegnoS28 metodo per l'inserimento di un nuovo pagamento quando l'importo è maggiore dell'impegnoS29 metodo per l'inserimento di un nuovo pagamento quando l'importo è minore dell'impegnoS30 metodo per l'inserimento di una nuova entrataS31 metodo per l'inserimento di una nuova prenotazioneS32 modalità di presentazione dati richiesti per la navigazione degli impegniS33 modalità di presentazione dati richiesti per la navigazione dei finanziamentiS34 modalità di presentazione dati richiesti per la navigazione dei pagamentiS35 modalità di presentazione dati richiesti per la navigazione delle entrateS36 modalità di presentazione dati richiesti per la navigazione delle prenotazioniS37 modalità di presentazione dati richiesti per la variazione degli impegniS38 modalità di presentazione dati richiesti per la variazione dei finanziamentiS39 modalità di presentazione dati richiesti per la variazione delle entrateS40 modalità di presentazione dati richiesti per la variazione delle prenotazioniS41 modalità di presentazione dati richiesti per l'inserimento degli impegniS42 modalità di presentazione dati richiesti per l'inserimento dei finanziamentiS43 modalità di presentazione dati richiesti per l'inserimento dei pagamentiS44 modalità di presentazione dati richiesti per l'inserimento delle entrateS45 modalità di presentazione dati richiesti per l'inserimento delle prenotazioniS46 modalità di presentazione finanziamenti consolidabili manualmenteS47 modalità di presentazione prenotazioni consolidabili manualmenteS48 operazioni da eseguire al lancio del sistemaS49 ricerca entrate e modalità di presentazione risultatiS50 ricerca finanziamenti e modalità di presentazione risultatiS51 ricerca impegni e modalità di presentazione risultatiS52 ricerca pagamenti e modalità di presentazione risultatiS53 ricerca prenotazioni e modalità di presentazione risultatiS54 accesso ai metadatiS55 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



GOAL: G1

QUESTION: Q1,2

METRICA: MxSVALORE RILEVATO: (le righe contengono i segreti, le colonne i moduli)

M1

M2

M3

M4

M5

M6

M7

M8

M9

M10

M11

M12

M13

M14

M15

M16

M17

M18

M19

M20

M21

M22

M23

M24

S1 xS2S3S4S5S6S7 xS8 xS9 xS10 xS11 xS12 xS13 xS14 xS15 xS16 xS17 xS18 xS19 xS20 xS21 xS22 xS23 xS24 xS25 xS26 xS27 xS28 xS29 xS30 xS31 xS32S33S34S35S36S37S38S39S40S41S42S43S44S45S46S47S48S49S50S51S52S53S54S55


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

S1S2 x xS3 x x x xS4 xS5 xS6 xS7S8S9S10S11S12S13S14S15S16S17S18S19S20S21S22S23S24S25S26S27S28S29S30S31S32 xS33 xS34 xS35 xS36 xS37 xS38 xS39 xS40 xS41 xS42 xS43 xS44 xS45 xS46 xS47 xS48 xS49 xS50 xS51 xS52 xS53 xS54 xS55 x



GOAL: G1

QUESTION: Q1,3

METRICA: MxTVALORE RILEVATO: (le righe contengono i moduli, le colonne le tipologie)

Controllo Afferente Efferente Trasformazione Data Banker

M1 xM2 xM3 xM4 xM5 xM6 xM7 xM8 xM9 xM10 xM11 xM12 xM13 xM14 xM15 xM16 xM17 xM18 xM19 xM20 xM21 xM22 xM23 xM24 xM25 xM26 xM27 xM28 xM29 xM30 xM31 xM32 xM33 xM34 xM35 xM36 xM37 xM38 xM39 xM40 xM41 xM42 xM43 x xM44 x xM45 x xM46 x xM47 x xM48 xM49 xM50 x



GOAL: G1

QUESTION: Q1,4

METRICA: SDxMVALORE RILEVATO: (le righe contengono i moduli, le colonne le strutture dati)

db_request

db_result

JoinTab

INS

_RIC

Metadati

MO

D_C

AN

C_R

IC

RIC

TipoV

aluta

M1 xM2 xM3 xM4 xM5 xM6 xM7 xM8 xM9 xM10 xM11 xM12 xM13 xM14 xM15 xM16 xM17 xM18 xM19 xM20 xM21 xM22 xM23 xM24 xM25 xM26 x xM27 xM28 x xM29 x xM30 x xM31 xM32 xM33 xM34 xM35 xM36 xM37M38 xM39 xM40 xM41 xM42 xM43 xM44 xM45 xM46 xM47 xM48 xM49 xM50



GOAL: G1

QUESTION: Q1,4

METRICA: MxTAVVALORE RILEVATO: (le righe contengono i moduli, le colonne le tavole)

Finanziam

enti

Entrate

Prenotazioni

Impegni

Pagam

enti

Finanziam

enti E

ntrate

Finanziam

enti P

renotazioni

Prenotazioni Im

pegni

Impegni

Pagam

enti

M1M2M3M4M5M6M7M8M9M10M11M12M13M14M15M16M17M18M19M20M21M22M23M24M25M26M27M28M29M30M31M32M33M34M35M36M37M38M39M40M41M42M43M44M45M46M47M48M49M50

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.



GOAL: G1

QUESTION: Q1,5

METRICA: DIVALORE RILEVATO:

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



GOAL: G1

QUESTION: Q1,5

METRICA: DOVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: CIVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: COVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: GDVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: GCVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5, Q1,6

METRICA: FANINVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: FANOUTVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: ACCVALORE RILEVATO:

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



GOAL: G1

QUESTION: Q1,5

METRICA: TMVALORE RILEVATO:




GOAL: G1


METRICA: SNVALORE RILEVATO:




GOAL: G1

QUESTION: Q1,5

METRICA: MNSVALORE RILEVATO:

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



GOAL: G1

QUESTION: Q1,5

METRICA: MDSVALORE RILEVATO:

db_request 1db_result 40JoinTab 3INS_RIC 1Metadati 4MOD_CANC_RIC 1RIC 1TipoValuta 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.



GOAL: G1

QUESTION: Q1,5

METRICA: MTSVALORE RILEVATO:

Finanziamenti 0Entrate 0Prenotazioni 0Impegni 0Pagamenti 0Finanziamenti Entrate 0Finanziamenti Prenotazioni 0Prenotazioni Impegni 0Impegni 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.



GOAL: G1

QUESTION: Q1,5

METRICA: NT5NFVALORE RILEVATO: 9



GOAL: G1

QUESTION: Q1,5

METRICA: NTVALORE RILEVATO: 9



GOAL: G1

QUESTION: Q1,5

METRICA: PT5NFVALORE RILEVATO: 1



GOAL: G1

QUESTION: Q1,7

METRICA: MxMMODRIUSVALORE RILEVATO:

CODICE MODULO MODIFICATO RIUSATOM1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa xM2 Calcolare Disponibilità di Cassa Non Impegnata xM3 Calcolare Prenotazione Non Impegnata xM4 Calcolare Situazione Eco./Fin. xM5 Consolidare Automaticamente xM6 Consolidare Entrate xM7 Consolidare Manualmente Finanziamento xM8 Consolidare Manualmente Prenotazione xM9 Controllare Consistenza Cancellazione Entrata xM10 Controllare Consistenza Cancellazione Finanziamento xM11 Controllare Consistenza Cancellazione Impegno xM12 Controllare Consistenza Cancellazione Prenotazione xM13 Controllare Consistenza Creazione Entrata xM14 Controllare Consistenza Creazione Finanziamento xM15 Controllare Consistenza Creazione Impegno x xM16 Controllare Consistenza Creazione Prenotazione xM17 Controllare Consistenza Modifica Entrata xM18 Controllare Consistenza Modifica Finanziamento xM19 Controllare Consistenza Modifica Impegno xM20 Controllare Consistenza Modifica Prenotazione xM21 Controllare Consistenza Creazione Pagamento x xM22 Inserire Pagamento Maggiore x xM23 Controllare Scadenze xM24 Convertire Valuta xM25 Data Banker xM26 Data Banker Create x xM27 Data Banker Delete xM28 Data Banker Read xM29 Data Banker Update x xM30 Gestire Schermate x xM31 Inserire Entrata xM32 Inserire Finanziamento xM33 Inserire Impegno xM34 Inserire Pagamento xM35 Inserire Pagamento Prenotazione Esaurita xM36 Inserire Prenotazione xM37 Leggere Metadati xM38 Main x xM39 Modificare/Cancellare Entrata xM40 Modificare/Cancellare Finanziamento xM41 Modificare/Cancellare Impegno xM42 Modificare/Cancellare Prenotazione xM43 Navigare Entrate x xM44 Navigare Finanziamenti x xM45 Navigare Impegni x xM46 Navigare Pagamenti x xM47 Navigare Prenotazioni x xM48 Selezionare Finanziamento da Consolidare xM49 Selezionare Prenotazione da Consolidare xM50 Trattare Errore x



GOAL: G1

QUESTION: Q1,7

METRICA: NMMODVALORE RILEVATO: 13



GOAL: G1

QUESTION: Q1,7

METRICA: NMRIUSVALORE RILEVATO: 49



GOAL: G1

QUESTION: Q1,7

METRICA: PERMMODVALORE RILEVATO: 0.26



GOAL: G1

QUESTION: Q1,7

METRICA: PERMRIUSVALORE RILEVATO: 0.98


Distanze dagli obiettivi


ACC pag. 87CI pag. 82CO pag. 83FANIN pag. 86GC pag. 85GD pag. 84MDS pag. 91MNS pag. 90MTS pag. 92PT5NF pag. 93SN pag. 89TM 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


METRICA: CI

DISTANZA DALLA BASELINE HYPHOTESIS:

VALORE RILEVATO

DISTANZA

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


METRICA: CO


VALORE RILEVATO

DISTANZA

M1 0 nessunaM2 0 nessunaM3 0 nessunaM4 0 nessunaM5 0 nessunaM6 0 nessunaM7 0 nessunaM8 0 nessunaM9 0 nessunaM10 0 nessunaM11 0 nessunaM12 0 nessunaM13 0 nessunaM14 0 nessunaM15 0 nessunaM16 0 nessunaM17 0 nessunaM18 0 nessunaM19 0 nessunaM20 0 nessunaM21 0 nessunaM22 0 nessunaM23 0 nessunaM24 0 nessunaM25 0 nessunaM26 0 nessunaM27 0 nessunaM28 0 nessunaM29 0 nessunaM30 0 nessunaM31 0 nessunaM32 0 nessunaM33 0 nessunaM34 0 nessunaM35 0 nessunaM36 0 nessunaM37 0 nessunaM38 0 nessunaM39 0 nessunaM40 0 nessunaM41 0 nessunaM42 0 nessunaM43 0 nessunaM44 0 nessunaM45 0 nessunaM46 0 nessunaM47 0 nessunaM48 0 nessunaM49 0 nessunaM50 0 nessuna


METRICA: GD


VALORE RILEVATO

DISTANZA



METRICA: GC


VALORE RILEVATO

DISTANZA



METRICA: FANIN


VALORE RILEVATO

DISTANZA

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


METRICA: ACC


VALORE RILEVATO

DISTANZA

M1 0.909 eccezione (FANIN alto)M2 0.800 rientraM3 0.857 rientraM4 0.666 rientraM5 0.833 rientraM6 0.750 rientraM7 0.800 rientraM8 0.833 rientraM9 0.800 rientraM10 0.750 rientraM11 0.800 rientraM12 0.750 rientraM13 0.833 rientraM14 0.750 rientraM15 0.909 0.049M16 0.833 rientraM17 0.857 rientraM18 0.800 rientraM19 0.857 rientraM20 0.833 rientraM21 0.875 0.050M22 0.857 rientraM23 0.500 rientraM24 0.947 eccezione (FANIN alto)M25 0.978 eccezione (FANIN alto)M26 0.833 rientraM27 0.800 rientraM28 0.800 rientraM29 0.857 rientraM30 0.947 eccezione (modulo di controllo)M31 0.800 rientraM32 0.750 rientraM33 0.800 rientraM34 0.800 rientraM35 0.800 rientraM36 0.800 rientraM37 0.833 rientraM38 0.944 eccezione (modulo di controllo)M39 0.750 rientraM40 0.750 rientraM41 0.750 rientraM42 0.750 rientraM43 0.666 rientraM44 0.666 rientraM45 0.666 rientraM46 0.666 rientraM47 0.666 rientraM48 0.666 rientraM49 0.666 rientraM50 0.500 rientra


METRICA: TM


VALORE RILEVATO

DISTANZA

M1 1 nessunaM2 1 nessunaM3 1 nessunaM4 1 nessunaM5 1 nessunaM6 1 nessunaM7 1 nessunaM8 1 nessunaM9 1 nessunaM10 1 nessunaM11 1 nessunaM12 1 nessunaM13 1 nessunaM14 1 nessunaM15 1 nessunaM16 1 nessunaM17 1 nessunaM18 1 nessunaM19 1 nessunaM20 1 nessunaM21 1 nessunaM22 1 nessunaM23 1 nessunaM24 1 nessunaM25 1 nessunaM26 1 nessunaM27 1 nessunaM28 1 nessunaM29 1 nessunaM30 1 nessunaM31 1 nessunaM32 1 nessunaM33 1 nessunaM34 1 nessunaM35 1 nessunaM36 1 nessunaM37 1 nessunaM38 1 nessunaM39 1 nessunaM40 1 nessunaM41 1 nessunaM42 1 nessunaM43 2 1M44 2 1M45 2 1M46 2 1M47 2 1M48 1 nessunaM49 1 nessunaM50 1 nessuna


METRICA: SN


VALORE RILEVATO

DISTANZA

M1 1 nessunaM2 1 nessunaM3 1 nessunaM4 1 nessunaM5 2 1M6 1 nessunaM7 1 nessunaM8 1 nessunaM9 1 nessunaM10 1 nessunaM11 1 nessunaM12 1 nessunaM13 1 nessunaM14 1 nessunaM15 1 nessunaM16 1 nessunaM17 1 nessunaM18 1 nessunaM19 1 nessunaM20 1 nessunaM21 2 1M22 1 nessunaM23 1 nessunaM24 1 nessunaM25 1 nessunaM26 2 1M27 1 nessunaM28 1 nessunaM29 2 1M30 1 nessunaM31 1 nessunaM32 1 nessunaM33 1 nessunaM34 1 nessunaM35 1 nessunaM36 1 nessunaM37 1 nessunaM38 1 nessunaM39 1 nessunaM40 1 nessunaM41 1 nessunaM42 1 nessunaM43 2 1M44 2 1M45 2 1M46 2 1M47 2 1M48 1 nessunaM49 1 nessunaM50 1 nessuna


METRICA: MNS


VALORE RILEVATO Distanza

S1 1 nessunaS2 2 nessunaS3 4 nessunaS4 1 nessunaS5 1 nessunaS6 1 nessunaS7 1 nessunaS8 1 nessunaS9 1 nessunaS10 1 nessunaS11 1 nessunaS12 1 nessunaS13 1 nessunaS14 1 nessunaS15 1 nessunaS16 1 nessunaS17 1 nessunaS18 1 nessunaS19 1 nessunaS20 1 nessunaS21 1 nessunaS22 1 nessunaS23 1 nessunaS24 1 nessunaS25 1 nessunaS26 1 nessunaS27 1 nessunaS28 1 nessunaS29 1 nessunaS30 1 nessunaS31 1 nessunaS32 1 nessunaS33 1 nessunaS34 1 nessunaS35 1 nessunaS36 1 nessunaS37 1 nessunaS38 1 nessunaS39 1 nessunaS40 1 nessunaS41 1 nessunaS42 1 nessunaS43 1 nessunaS44 1 nessunaS45 1 nessunaS46 1 nessunaS47 1 nessunaS48 1 nessunaS49 1 nessunaS50 1 nessunaS51 1 nessunaS52 1 nessunaS53 1 nessunaS54 1 nessunaS55 1 nessuna


METRICA: MDS


VALORE RILEVATO

Distanzadb_request 1 rientradb_result 40 eccezione (vedere note)JoinTab 3 rientraINS_RIC 1 rientraMetadati 4 rientraMOD_CANC_RIC 1 rientraRIC 1 rientraTipoValuta 1 rientra



METRICA: MTS


VALORE RILEVATO

DISTANZA

Finanziamenti 0 rientraEntrate 0 rientraPrenotazioni 0 rientraImpegni 0 rientraPagamenti 0 rientraFinanziamenti Entrate 0 rientraFinanziamenti Prenotazioni 0 rientraPrenotazioni Impegni 0 rientraImpegni Pagamenti 0 rientra

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


METRICA: PT5NF

VALORE RILEVATO: 1DISTANZA DALLA BASELINE HYPHOTESIS: nessuna


Punti di debolezza

FOGLIO METRICO PUNTO DI DEBOLEZZA METRICHE CARENTI

G1 Modularità ACCTMSN


Fattori di variazione

FOGLIO METRICOPUNTO DI DEBOLEZZA

METRICHE CARENTI FATTORI DI VARIAZIONE

G1 Modularità

ACCTMSN


ACC esperienza del team di progetto nella

progettazione delle interfacce tra le singole componenti


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.


Scheda descrizione degli interventi

COMPONENTE DEL SISTEMA TIPOLOGIA DI INTERVENTO

Modulo Controllare Consistenza Creazione Impegno

revisione struttura interna del modulo

Modulo Consolidare Automaticamente

esplosione del modulo

Modulo Controllare 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 Finanziamenti


Modulo Navigare Impegni esplosione del modulo

Modulo Navigare Pagamenti esplosione del modulo

Modulo Navigare 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 RExDS

aggiornamento e integrazione delle possibili nuove componenti nella 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


Specifiche delle modifiche

INDICE DEI PIANI ESECUTIVI:

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

NOTE:

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


Piano esecutivo 1

TIPOLOGIE DI INTERVENTI COPERTI:

T1 - revisione struttura interna del moduloT2 - revisione dell'interfaccia del moduloT3 - esplosione del moduloT4 - 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 RExDST7 - 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:

Caso di studio Ingegneria del Software II

RIFINIRE LA STRUCTURE CHART E LE SPECIFICHE

DEI MODULI2.5

COSTRUIRE LA CROSS REFERENCE REXDS

2.8

DEFINIRE LE STRUTTURE DEI FILE ESTERNI E DEI

DATI GLOBALI2.6

STOP

START

99

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 dati2. Migliorare la Structure Chart utilizzando le euristiche2a. 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 Hiding3a. 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 aggiunto4.1 Definire la specifica semantica e la specifica sintattica4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo4.3 Descrivere i dati referenziati4.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


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

Procedura:

1. Individuare l'insieme di file di dati esterni2. Per ciascun file esterno individuato

2.1 Definire la struttura logica2.2 Descrivere i record logici2.3 Definire la modalità di accesso

3. Individuare l'insieme dei dati globali fornendo per ciascuno di essi la struttura4. 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 realizzati2.8 Costruire la Cross Reference RExDS


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


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


Piano esecutivo 2


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


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

WORK FLOW DIAGRAM:


2.7 Definire il dizionario dei dati (progetto)


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)



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


DEFINIRE IL DIZIONARIO DEI DATI (PROGETTO)

2.7

START

STOP

102

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

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


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


Piano esecutivo 3


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


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

WORK FLOW DIAGRAM:


3.1 Implementare il progetto


Input: Documenti di progetto

Procedura:

1. Realizzare il codice2. Realizzare la base di dati

Output: Codice sorgente



IMPLEMENTARE IL PROGETTO

3.1

COMPILARE IL PROGRAMMA

3.2

START

STOP

104

3.2 Compilare il programma


Input: Codice sorgente

Procedura:

1. Compilare il programma2. Se esistono errori sintattici

2.1 Correggere gli errori2.2 Ripetere dal passo 1

Output: Codice sorgente corretto, Codice oggetto



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




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



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



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


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:




Procedura:


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.


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 modificato4.1 Definire la specifica semantica e la specifica sintattica4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo4.3 Descrivere i dati referenziati4.4 Definire gli altri moduli che esso utilizza





RILEVARE LE MISURE

1.6

START


2.1


2.2


3.1


3.2


4.1


COMPONENTI4.2


4.3

STOP

109


Distanze dagli obiettivi pag. 161Fattori di variazione pag. 179Fogli metrici pag. 123, 175Ipotesi di miglioramento dei fogli metrici pag. 174Ipotesi di miglioramento del sistema software pag. 180Miglioramento del processo di sviluppo software pag. 191Misure pag. 126Piano di misurazioni pag. 116Piano GQM pag. 112Punti di debolezza pag. 178Scheda descrizione degli interventi pag. 181Specifiche 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


Piano GQM

INDICE DEI GOAL:

Goal G1 pag. 113


G1





























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.









Modello di conferma






M





NMOD





S





MxS



Come misurare





T


Come misurare





MxT



Come misurare





SD




SDxM



Come misurare





TAV




MxTAV



Come misurare





DI




Come misurare




DO



Come misurare




CI



Come misurare




CO



Come misurare




GD



Come misurare




GC




Come misurare




FANIN



Come misurare





FANOUT



Come misurare




TM





MNS





MDS



la metrica SDxM



MTS





SN





NT5NF




NT





MxMMODRIUS

Chi deve misurare ingegnere del softwareQuando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)

Come misurare riportare in una tabella cross-reference i moduli elencati nella metrica M e i due tipi "modificato" e "riusato"






NMRIUS





NMMOD






Fogli metrici


Goal G1 pag. 124


G1

OGGETTO







- Modularità:









- Riusabilità:








- Modularità:








PT5NF: pari a 1;

- Riusabilità:














Misure



INDICE DELLE METRICHE DEL MODELLO DI CONFERMA:

MxMMODRIUS pag. 156NMMOD pag. 157NMRIUS pag. 158PERMMOD pag. 159PERMRIUS 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.



GOAL: G1

QUESTION: Q1,1


CODICE MODULOM1 Aggiornare Disponibilità Finanziaria e Disponibilità di CassaM2 Calcolare Disponibilità di Cassa Non ImpegnataM3 Calcolare Prenotazione Non ImpegnataM4 Calcolare Situazione Eco./Fin.M5 Consolidare Automaticamente PrenotazioneM6 Consolidare EntrateM7 Consolidare Manualmente FinanziamentoM8 Consolidare Manualmente PrenotazioneM9 Controllare Consistenza Cancellazione EntrataM10 Controllare Consistenza Cancellazione FinanziamentoM11 Controllare Consistenza Cancellazione ImpegnoM12 Controllare Consistenza Cancellazione PrenotazioneM13 Controllare Consistenza Creazione EntrataM14 Controllare Consistenza Creazione FinanziamentoM15 Controllare Consistenza Creazione ImpegnoM16 Controllare Consistenza Creazione PrenotazioneM17 Controllare Consistenza Modifica EntrataM18 Controllare Consistenza Modifica FinanziamentoM19 Controllare Consistenza Modifica ImpegnoM20 Controllare Consistenza Modifica PrenotazioneM21 Controllare Consistenza Creazione PagamentoM22 Inserire Pagamento MaggioreM23 Controllare ScadenzeM24 Convertire ValutaM25 Data BankerM26 Data Banker CreateM27 Data Banker DeleteM28 Data Banker ReadM29 Data Banker UpdateM30 Gestire SchermateM31 Inserire EntrataM32 Inserire FinanziamentoM33 Inserire ImpegnoM34 Inserire PagamentoM35 Inserire Pagamento Prenotazione EsauritaM36 Inserire PrenotazioneM37 Leggere MetadatiM38 MainM39 Modificare/Cancellare EntrataM40 Modificare/Cancellare FinanziamentoM41 Modificare/Cancellare ImpegnoM42 Modificare/Cancellare PrenotazioneM43 Navigare EntrateM44 Navigare FinanziamentiM45 Navigare ImpegniM46 Navigare PagamentiM47 Navigare PrenotazioniM48 Selezionare Finanziamento da ConsolidareM49 Selezionare Prenotazione da ConsolidareM50 Trattare ErroriM51 Acquisire Parametri Navigazione FinanziamentiM52 Acquisire Parametri Navigazione EntrateM53 Acquisire Parametri Navigazione PrenotazioniM54 Acquisire Parametri Navigazione ImpegniM55 Acquisire Parametri Navigazione PagamentiM56 Inserire Pagamento MinoreM57 Inserire Pagamento UgualeM58 Generare Chiave AutomaticamenteM59 Consolidare Automaticamente FinanziamentoM60 Controllare Consistenza Creazione Impegno Senza Prenotazione



127


GOAL: G1

QUESTION: Q1,1




GOAL: G1

QUESTION: Q1,3


TIPOLOGIAControllo

Afferente

Efferente

Trasformazione

Data Banker



GOAL: G1

QUESTION: Q1,4





GOAL: G1

QUESTION: Q1,4


STRUTTURA DATIdb_requestdb_resultJoinTabINS_RICMetadatiMOD_CANC_RICRICTipoValuta



GOAL: G1

QUESTION: Q1,2






GOAL: G1

QUESTION: Q1,2


M1

M2

M3

M4

M5

M6

M7

M8

M9

M10

M11

M12

M13

M14

M15

M16

M17

M18

M19

M20

M21

M22

M23

M24

S1 xS2S3S4S5S6S7 xS8 xS9 xS10S11 xS12 xS13 xS14 xS15 xS16 xS17 xS18 xS19 xS20 xS21 xS22 xS23 xS24 xS25 xS26 xS27S28 xS29S30 xS31 xS32S33S34S35S36S37S38S39S40S41S42S43S44S45S46S47S48S49S50S51S52S53S54S55


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

S1S2S3 x x x xS4 xS5 xS6 xS7S8S9S10S11S12S13S14S15S16S17S18S19S20S21S22S23S24S25S26S27S28S29S30S31S32S33S34S35S36S37 xS38 xS39 xS40 xS41 xS42 xS43 xS44 xS45 xS46 xS47 xS48 xS49 xS50 xS51 xS52 xS53 xS54 xS55 x


M51

M52

M53

M54

M55

M56

M57

M58

M59

M60

S1S2 xS3S4S5S6S7S8S9S10 xS11S12S13S14S15S16S17S18S19S20S21S22S23S24S25S26 xS27 xS28S29 xS30S31S32 xS33 xS34 xS35 xS36 xS37S38S39S40S41S42S43S44S45S46S47S48S49S50S51S52S53S54S55



GOAL: G1

QUESTION: Q1,3



M1 xM2 xM3 xM4 xM5 xM6 xM7 xM8 xM9 xM10 xM11 xM12 xM13 xM14 xM15 xM16 xM17 xM18 xM19 xM20 xM21 xM22 xM23 xM24 xM25 xM26 xM27 xM28 xM29 xM30 xM31 xM32 xM33 xM34 xM35 xM36 xM37 xM38 xM39 xM40 xM41 xM42 xM43 xM44 xM45 xM46 xM47 xM48 xM49 xM50 xM51 xM52 xM53 xM54 xM55 xM56 xM57 xM58 xM59 xM60 x



GOAL: G1

QUESTION: Q1,4


db_request

db_result

JoinTab

INS

_RIC

Metadati

MO

D_

CA

NC

_R

IC

RIC

Tipo

Valuta

M1 xM2 xM3 xM4 xM5 xM6 xM7 xM8 xM9 xM10 xM11 xM12 xM13 xM14 xM15 xM16 xM17 xM18 xM19 xM20 xM21M22 xM23 xM24 xM25 xM26 x xM27 xM28 x xM29 x xM30 x xM31 xM32 xM33 xM34 xM35 xM36 xM37M38 xM39 xM40 xM41 xM42 xM43 xM44 xM45 xM46 xM47 xM48 xM49 xM50M51 xM52 xM53 xM54 xM55 xM56 xM57 xM58M59 xM60 x



GOAL: G1

QUESTION: Q1,4


Finanzia

menti

Entrate

Prenota

zioni

Impegni

Pagam

enti F

inanziam

enti E

ntrate

Finanzia

menti

Prenota

zioni

Prenota

zioni Im

pegni

Impegni

Pagam

enti

M1M2M3M4M5M6M7M8M9M10M11M12M13M14M15M16M17M18M19M20M21M22M23M24M25M26M27M28M29M30M31M32M33M34M35M36M37M38M39M40M41M42M43M44M45M46M47M48M49M50M51M52M53M54M55M56M57M58M59M60



139


GOAL: G1

QUESTION: Q1,5


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



GOAL: G1

QUESTION: Q1,5





GOAL: G1






GOAL: G1

QUESTION: Q1,5





GOAL: G1

QUESTION: Q1,5


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



GOAL: G1

QUESTION: Q1,5





GOAL: G1






GOAL: G1

QUESTION: Q1,5





GOAL: G1

QUESTION: Q1,5


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




GOAL: G1

QUESTION: Q1,5






GOAL: G1

QUESTION: Q1,7

METRICA: MxMMODRIUSVALORE RILEVATO:

CODICE MODULO MODIFICATO RIUSATOM1 Aggiornare Disponibilità Finanziaria e Disponibilità di Cassa xM2 Calcolare Disponibilità di Cassa Non Impegnata xM3 Calcolare Prenotazione Non Impegnata xM4 Calcolare Situazione Eco./Fin. xM5 Consolidare Automaticamente Prenotazione xM6 Consolidare Entrate xM7 Consolidare Manualmente Finanziamento xM8 Consolidare Manualmente Prenotazione xM9 Controllare Consistenza Cancellazione Entrata xM10 Controllare Consistenza Cancellazione Finanziamento xM11 Controllare Consistenza Cancellazione Impegno xM12 Controllare Consistenza Cancellazione Prenotazione xM13 Controllare Consistenza Creazione Entrata xM14 Controllare Consistenza Creazione Finanziamento xM15 Controllare Consistenza Creazione Impegno x xM16 Controllare Consistenza Creazione Prenotazione xM17 Controllare Consistenza Modifica Entrata xM18 Controllare Consistenza Modifica Finanziamento xM19 Controllare Consistenza Modifica Impegno xM20 Controllare Consistenza Modifica Prenotazione xM21 Controllare Consistenza Creazione Pagamento xM22 Inserire Pagamento Maggiore xM23 Controllare Scadenze xM24 Convertire Valuta xM25 Data Banker x xM26 Data Banker Create xM27 Data Banker Delete xM28 Data Banker Read xM29 Data Banker Update x xM30 Gestire Schermate xM31 Inserire Entrata xM32 Inserire Finanziamento xM33 Inserire Impegno xM34 Inserire Pagamento xM35 Inserire Pagamento Prenotazione Esaurita xM36 Inserire Prenotazione xM37 Leggere Metadati xM38 Main x xM39 Modificare/Cancellare Entrata xM40 Modificare/Cancellare Finanziamento xM41 Modificare/Cancellare Impegno xM42 Modificare/Cancellare Prenotazione xM43 Navigare Entrate xM44 Navigare Finanziamenti xM45 Navigare Impegni xM46 Navigare Pagamenti xM47 Navigare Prenotazioni xM48 Selezionare Finanziamento da Consolidare xM49 Selezionare Prenotazione da Consolidare xM50 Trattare Errore xM51 Acquisire Parametri Navigazione Finanziamenti xM52 Acquisire Parametri Navigazione Entrate xM53 Acquisire Parametri Navigazione Prenotazioni xM54 Acquisire Parametri Navigazione Impegni xM55 Acquisire Parametri Navigazione Pagamenti xM56 Inserire Pagamento Minore xM57 Inserire Pagamento Uguale xM58 Generare Chiave Automaticamente xM59 Consolidare Automaticamente Finanziamento xM60 Controllare Consistenza Inserimento Impegno Senza Prenotazione x x



GOAL: G1

QUESTION: Q1,7

METRICA: NMMODVALORE 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)..



GOAL: G1

QUESTION: Q1,7

METRICA: NMRIUSVALORE RILEVATO: 60



GOAL: G1

QUESTION: Q1,7

METRICA: PERMMODVALORE RILEVATO: 0.08



GOAL: G1

QUESTION: Q1,7

METRICA: PERMRIUSVALORE RILEVATO: 1




CI pag. 162CO pag. 163FANIN pag. 166ACC pag. 167GC pag. 165GD pag. 164MDS pag. 171MNS pag. 170MTS pag. 172PT5NF pag. 173SN pag. 169TM pag. 168

NOTE:







METRICA: CI


VALORE RILEVATO

DISTANZA

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



METRICA: CO


VALORE RILEVATO

DISTANZA

M1 0 nessunaM2 0 nessunaM3 0 nessunaM4 0 nessunaM5 0 nessunaM6 0 nessunaM7 0 nessunaM8 0 nessunaM9 0 nessunaM10 0 nessunaM11 0 nessunaM12 0 nessunaM13 0 nessunaM14 0 nessunaM15 0 nessunaM16 0 nessunaM17 0 nessunaM18 0 nessunaM19 0 nessunaM20 0 nessunaM21 0 nessunaM22 0 nessunaM23 0 nessunaM24 0 nessunaM25 0 nessunaM26 0 nessunaM27 0 nessunaM28 0 nessunaM29 0 nessunaM30 0 nessunaM31 0 nessunaM32 0 nessunaM33 0 nessunaM34 0 nessunaM35 0 nessunaM36 0 nessunaM37 0 nessunaM38 0 nessunaM39 0 nessunaM40 0 nessunaM41 0 nessunaM42 0 nessunaM43 0 nessunaM44 0 nessunaM45 0 nessunaM46 0 nessunaM47 0 nessunaM48 0 nessunaM49 0 nessunaM50 0 nessunaM51 0 nessunaM52 0 nessunaM53 0 nessunaM54 0 nessunaM55 0 nessunaM56 0 nessunaM57 0 nessunaM58 0 nessunaM59 0 nessunaM60 0 nessuna


METRICA: GD


VALORE RILEVATO

DISTANZA



METRICA: GC


VALORE RILEVATO

DISTANZA



METRICA: FANIN


VALORE RILEVATO

DISTANZA

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.)



METRICA: ACC


VALORE RILEVATO

DISTANZA

M1 0.928 eccezione (FANIN alto)M2 0.857 rientraM3 0.857 rientraM4 0.666 rientraM5 0.875 eccezione (FANIN alto)M6 0.750 rientraM7 0.800 rientraM8 0.833 rientraM9 0.800 rientraM10 0.750 rientraM11 0.800 rientraM12 0.750 rientraM13 0.833 rientraM14 0.750 rientraM15 0.875 0.015M16 0.833 rientraM17 0.857 rientraM18 0.800 rientraM19 0.857 rientraM20 0.833 rientraM21 0.857 rientraM22 0.888 0.028M23 0.500 rientraM24 0.958 eccezione (FANIN alto)M25 0.981 eccezione (FANIN alto)M26 0.857 rientraM27 0.800 rientraM28 0.800 rientraM29 0.875 0.015M30 0.947 eccezione (modulo di controllo)M31 0.800 rientraM32 0.750 rientraM33 0.800 rientraM34 0.800 rientraM35 0.800 rientraM36 0.800 rientraM37 0.833 rientraM38 0.958 eccezione (modulo di controllo)M39 0.750 rientraM40 0.750 rientraM41 0.750 rientraM42 0.750 rientraM43 0.750 rientraM44 0.750 rientraM45 0.750 rientraM46 0.750 rientraM47 0.750 rientraM48 0.666 rientraM49 0.666 rientraM50 0.500 rientraM51 0.750 rientraM52 0.750 rientraM53 0.750 rientraM54 0.750 rientraM55 0.750 rientraM56 0.857 rientraM57 0.857 rientraM58 0.800 rientraM59 0.800 rientraM60 0.875 0.015


METRICA: TM


VALORE RILEVATO

DISTANZA



METRICA: SN


VALORE RILEVATO

DISTANZA

M1 1 nessunaM2 1 nessunaM3 1 nessunaM4 1 nessunaM5 1 nessunaM6 1 nessunaM7 1 nessunaM8 1 nessunaM9 1 nessunaM10 1 nessunaM11 1 nessunaM12 1 nessunaM13 1 nessunaM14 1 nessunaM15 1 nessunaM16 1 nessunaM17 1 nessunaM18 1 nessunaM19 1 nessunaM20 1 nessunaM21 0 rientraM22 1 nessunaM23 1 nessunaM24 1 nessunaM25 1 nessunaM26 1 nessunaM27 1 nessunaM28 1 nessunaM29 1 nessunaM30 1 nessunaM31 1 nessunaM32 1 nessunaM33 1 nessunaM34 1 nessunaM35 1 nessunaM36 1 nessunaM37 1 nessunaM38 1 nessunaM39 1 nessunaM40 1 nessunaM41 1 nessunaM42 1 nessunaM43 1 nessunaM44 1 nessunaM45 1 nessunaM46 1 nessunaM47 1 nessunaM48 1 nessunaM49 1 nessunaM50 1 nessunaM51 1 nessunaM52 1 nessunaM53 1 nessunaM54 1 nessunaM55 1 nessunaM56 1 nessunaM57 1 nessunaM58 1 nessunaM59 1 nessunaM60 1 nessuna


METRICA: MNS





METRICA: MDS


VALORE RILEVATO

Distanzadb_request 1 rientradb_result 48 eccezione (vedere note)JoinTab 3 rientraINS_RIC 1 rientraMetadati 4 rientraMOD_CANC_RIC 1 rientraRIC 1 rientraTipoValuta 1 rientra



METRICA: MTS


VALORE RILEVATO

DISTANZA

Finanziamenti 0 rientraEntrate 0 rientraPrenotazioni 0 rientraImpegni 0 rientraPagamenti 0 rientraFinanziamenti Entrate 0 rientraFinanziamenti Prenotazioni 0 rientraPrenotazioni Impegni 0 rientraImpegni Pagamenti 0 rientra



METRICA: PT5NF



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:


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


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)


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


G1

OGGETTO







- Modularità:









- Riusabilità:






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



- Modularità:








PT5NF: pari a 1;

- Riusabilità:
















Punti di debolezza

FOGLIO METRICO PUNTO DI DEBOLEZZA METRICHE CARENTI

G1 Modularità ACC


Fattori di variazione

FOGLIO METRICOPUNTO DI DEBOLEZZA

METRICHE CARENTI FATTORI DI VARIAZIONE

G1 Modularità


progettazione della struttura del sistema


progettazione delle interfacce tra le singole componenti


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.


Scheda descrizione degli interventi

COMPONENTE DEL SISTEMA TIPOLOGIA DI INTERVENTO

Modulo Controllare Consistenza Creazione Impegno



Modulo Inserire Pagamento Maggiore



Modulo Data Banker Update revisione dell'interfaccia del modulo

Modulo Controllare Consistenza Creazione Impegno Senza Prenotazione



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 RExDS

aggiornamento e integrazione delle possibili nuove componenti nella 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


Specifiche delle modifiche

INDICE DEI PIANI ESECUTIVI:

Piano esecutivo 1 pag. 183Piano esecutivo 2 pag. 186Piano 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.


Piano esecutivo 1


T1 - revisione struttura interna del moduloT2 - revisione dell'interfaccia del moduloT4 - 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 RExDST7 - aggiornamento di tutta la documentazione di progetto al fine di allinearla e renderla tracciabile con le

modifiche effettuate


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:



DEI MODULI2.5

COSTRUIRE LA CROSS REFERENCE REXDS

2.8


DATI GLOBALI2.6

STOP

START

184





Procedura:


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.


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 aggiunto4.1 Definire la specifica semantica e la specifica sintattica4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo4.3 Descrivere i dati referenziati4.4 Definire gli altri moduli che esso utilizza4.5 Rieseguire i passi 2a.1, 2a.2, 3a.1 e 3a.2






Procedura:



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



2.8 Costruire la Cross Reference RExDS



Procedura:









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





Piano esecutivo 2


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


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

WORK FLOW DIAGRAM:


2.7 Definire il dizionario dei dati (progetto)



Procedura:








DEFINIRE IL DIZIONARIO DEI DATI (PROGETTO)

2.7

START

STOP

187

Piano esecutivo 3


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


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

WORK FLOW DIAGRAM:





Procedura:






3.1


3.2

START

STOP

189




Procedura:



















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:




Procedura:


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.


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 aggiunto4.1 Definire la specifica semantica e la specifica sintattica4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo4.3 Descrivere i dati referenziati4.4 Definire gli altri moduli che esso utilizza4.5 Rieseguire i passi 2a.1, 2a.2, 3a.1 e 3a.2





RILEVARE LE MISURE

1.6

START


2.1


2.2


3.1


3.2


4.1


COMPONENTI4.2


4.3

STOP

194


Distanze dagli obiettivi pag. 242Fogli metrici pag. 209, 257Ipotesi di miglioramento dei fogli metrici pag. 255Misure pag. 212Piano di misurazioni pag. 200Piano 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


Piano GQM

INDICE DEI GOAL:

Goal G1 pag. 197


G1





















Modello di conferma






M





NMOD





S





MxS



Come misurare





T


Come misurare





MxT



Come misurare





SD




SDxM



Come misurare





TAV




MxTAV



Come misurare





DI




Come misurare




DO



Come misurare




CI



Come misurare




CO



Come misurare




GD



Come misurare




GC




Come misurare




FANIN



Come misurare





FANOUT



Come misurare




TM





MNS





MDS



la metrica SDxM



MTS





SN





NT5NF




NT





MxMMODRIUS



Quando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)

Come misurare






NMRIUS





NMMOD






Fogli metrici


Goal G1 pag. 210


G1

OGGETTO







- Modularità:









- Riusabilità:









- Modularità:








PT5NF: pari a 1;

- Riusabilità:














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)


Misure





GOAL: G1

QUESTION: Q1,1





214


GOAL: G1

QUESTION: Q1,1




GOAL: G1

QUESTION: Q1,3


TIPOLOGIAControllo

Afferente

Efferente

Trasformazione

Data Banker



GOAL: G1

QUESTION: Q1,4





GOAL: G1

QUESTION: Q1,4


STRUTTURA DATICREATE_IMPdb_requestdb_resultJoinTabINS_RICMetadatiMOD_CANC_RICRICTipoValuta



GOAL: G1

QUESTION: Q1,2






GOAL: G1

QUESTION: Q1,2


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



M51

M52

M53

M54

M55

M56

M57

M58

M59

M60




GOAL: G1

QUESTION: Q1,3






GOAL: G1

QUESTION: Q1,4


CR

EA

TE

_IMP

db_request

db_result

JoinTab

INS

_RIC

Metadati

MO

D_

CA

NC

_RIC

RIC

TipoV

aluta

M1 xM2 xM3 xM4 xM5 xM6 xM7 xM8 xM9 xM10 xM11 xM12 xM13 xM14 xM15 x xM16 xM17 xM18 xM19 xM20 xM21M22 xM23 xM24 xM25 xM26 x xM27 xM28 x xM29 x xM30 x xM31 xM32 xM33 xM34 xM35 xM36 xM37M38 xM39 xM40 xM41 xM42 xM43 xM44 xM45 xM46 xM47 xM48 xM49 xM50M51 xM52 xM53 xM54 xM55 xM56 xM57 xM58M59 xM60 x x



GOAL: G1

QUESTION: Q1,4


Finanzia

menti

Entrate

Prenota

zioni

Impegni

Pagam

enti F

inanziam

enti E

ntrate

Finanzia

menti

Prenotazi

Prenota

zioni Im

pegni

Impegni

Pagam

enti




226


GOAL: G1

QUESTION: Q1,5





GOAL: G1






GOAL: G1

QUESTION: Q1,5





GOAL: G1






GOAL: G1

QUESTION: Q1,5





GOAL: G1

QUESTION: Q1,5


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




GOAL: G1

QUESTION: Q1,5








NOTE:







METRICA: CI


VALORE RILEVATO

DISTANZA




METRICA: CO


VALORE RILEVATO

DISTANZA



METRICA: GD


VALORE RILEVATO

DISTANZA



METRICA: GC


VALORE RILEVATO

DISTANZA



METRICA: FANIN


VALORE RILEVATO

DISTANZA




METRICA: ACC


VALORE RILEVATO

DISTANZA

M1 0.928 eccezione (FANIN alto)M2 0.857 rientraM3 0.857 rientraM4 0.666 rientraM5 0.875 eccezione (FANIN alto)M6 0.750 rientraM7 0.800 rientraM8 0.833 rientraM9 0.800 rientraM10 0.750 rientraM11 0.800 rientraM12 0.750 rientraM13 0.833 rientraM14 0.750 rientraM15 0.857 rientraM16 0.833 rientraM17 0.857 rientraM18 0.800 rientraM19 0.857 rientraM20 0.833 rientraM21 0.857 rientraM22 0.888 0.028M23 0.500 rientraM24 0.958 eccezione (FANIN alto)M25 0.981 eccezione (FANIN alto)M26 0.857 rientraM27 0.800 rientraM28 0.800 rientraM29 0.800 rientraM30 0.947 eccezione (modulo di controllo)M31 0.800 rientraM32 0.750 rientraM33 0.800 rientraM34 0.800 rientraM35 0.800 rientraM36 0.800 rientraM37 0.833 rientraM38 0.958 eccezione (modulo di controllo)M39 0.750 rientraM40 0.750 rientraM41 0.750 rientraM42 0.750 rientraM43 0.750 rientraM44 0.750 rientraM45 0.750 rientraM46 0.750 rientraM47 0.750 rientraM48 0.666 rientraM49 0.666 rientraM50 0.500 rientraM51 0.750 rientraM52 0.750 rientraM53 0.750 rientraM54 0.750 rientraM55 0.750 rientraM56 0.857 rientraM57 0.857 rientraM58 0.800 rientraM59 0.800 rientraM60 0.857 rientra


METRICA: TM


VALORE RILEVATO

DISTANZA



METRICA: SN


VALORE RILEVATO

DISTANZA



METRICA: MNS





METRICA: MDS


VALORE RILEVATO

DistanzaCREATE_IMP 2 rientradb_request 1 rientradb_result 48 eccezione (vedere note)JoinTab 3 rientraINS_RIC 1 rientraMetadati 4 rientraMOD_CANC_RIC 1 rientraRIC 1 rientraTipoValuta 1 rientra



METRICA: MTS


VALORE RILEVATO

DISTANZA

Finanziamenti 0 nessunaEntrate 0 nessunaPrenotazioni 0 nessunaImpegni 0 nessunaPagamenti 0 nessunaFinanziamenti Entrate 0 nessunaFinanziamenti Prenotazioni 0 nessunaPrenotazioni Impegni 0 nessunaImpegni Pagamenti 0 nessuna



METRICA: PT5NF



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)


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


G1

OGGETTO







- Modularità:









- Riusabilità:









- Modularità:








PT5NF: pari a 1;

- Riusabilità:

















RILEVARE LE MISURE

1.6

START


2.1


2.2


3.1

STOP

263

Indice

Distanze dagli obiettivi pag. 311Fogli metrici pag. 277Misure pag. 281Piano di misurazioni pag. 268Piano 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


Piano GQM

INDICE DEI GOAL:

Goal G1 pag. 265


G1





















Modello di conferma






M





NMOD





S





MxS



Come misurare





T


Come misurare





MxT



Come misurare





SD




SDxM



Come misurare





TAV




MxTAV



Come misurare





DI




Come misurare




DO



Come misurare




CI



Come misurare




CO



Come misurare




GD



Come misurare




GC




Come misurare




FANIN



Come misurare





FANOUT



Come misurare




TM





MNS





MDS



la metrica SDxM



MTS





SN





NT5NF




NT





MxMMODRIUS



Quando misurare al termine della fase di esecuzione del processo di miglioramento (fase 4)

Come misurare






NMRIUS





NMMOD






Fogli metrici


Goal G1 pag. 278


G1

OGGETTO







- Modularità:









- Riusabilità:









- Modularità:








PT5NF: pari a 1;

- Riusabilità:
















Misure





GOAL: G1

QUESTION: Q1,1





284


GOAL: G1

QUESTION: Q1,1




GOAL: G1

QUESTION: Q1,3


TIPOLOGIAControllo

Afferente

Efferente

Trasformazione

Data Banker



GOAL: G1

QUESTION: Q1,4





GOAL: G1

QUESTION: Q1,4


STRUTTURA DATICREATE_IMPdb_requestdb_resultJoinTabINS_RICMetadatiMOD_CANC_RICRICTipoValuta



GOAL: G1

QUESTION: Q1,2






GOAL: G1

QUESTION: Q1,2


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



M51

M52

M53

M54

M55

M56

M57

M58

M59

M60




GOAL: G1

QUESTION: Q1,3






GOAL: G1

QUESTION: Q1,4


CR

EA

TE

_IMP

db_request

db_result

JoinTab

INS

_RIC

Metadati

MO

D_

CA

NC

_RIC

RIC

TipoV

aluta

M1 xM2 xM3 xM4 xM5 xM6 xM7 xM8 xM9 xM10 xM11 xM12 xM13 xM14 xM15 x xM16 xM17 xM18 xM19 xM20 xM21M22 xM23 xM24 xM25 xM26 x xM27 xM28 x xM29 x xM30 x xM31 xM32 xM33 xM34 xM35 xM36 xM37M38 xM39 xM40 xM41 xM42 xM43 xM44 xM45 xM46 xM47 xM48 xM49 xM50M51 xM52 xM53 xM54 xM55 xM56 xM57 xM58M59 xM60 x x



GOAL: G1

QUESTION: Q1,4


Finanzia

menti

Entrate

Prenotazi

oni

Impegni

Pagam

enti F

inanziam

enti E

ntrate

Finanzia

menti

Prenotazi

oni

Prenotazi

oni Im

pegni

Impegni

Pagam

enti




296


GOAL: G1

QUESTION: Q1,5





GOAL: G1






GOAL: G1

QUESTION: Q1,5





GOAL: G1






GOAL: G1

QUESTION: Q1,5





GOAL: G1

QUESTION: Q1,5


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




GOAL: G1

QUESTION: Q1,5








NOTE:







METRICA: CI


VALORE RILEVATO

DISTANZA




METRICA: CO


VALORE RILEVATO

DISTANZA



METRICA: GD


VALORE RILEVATO

DISTANZA



METRICA: GC


VALORE RILEVATO

DISTANZA



METRICA: FANIN


VALORE RILEVATO

DISTANZA




METRICA: ACC


VALORE RILEVATO

DISTANZA

M1 0.928 eccezione (FANIN alto)M2 0.857 rientraM3 0.857 rientraM4 0.666 rientraM5 0.875 eccezione (FANIN alto)M6 0.750 rientraM7 0.800 rientraM8 0.833 rientraM9 0.800 rientraM10 0.750 rientraM11 0.800 rientraM12 0.750 rientraM13 0.833 rientraM14 0.750 rientraM15 0.857 rientraM16 0.833 rientraM17 0.857 rientraM18 0.800 rientraM19 0.857 rientraM20 0.833 rientraM21 0.857 rientraM22 0.888 rientra nel 2%M23 0.500 rientraM24 0.958 eccezione (FANIN alto)M25 0.981 eccezione (FANIN alto)M26 0.857 rientraM27 0.800 rientraM28 0.800 rientraM29 0.800 rientraM30 0.947 eccezione (modulo di controllo)M31 0.800 rientraM32 0.750 rientraM33 0.800 rientraM34 0.800 rientraM35 0.800 rientraM36 0.800 rientraM37 0.833 rientraM38 0.958 eccezione (modulo di controllo)M39 0.750 rientraM40 0.750 rientraM41 0.750 rientraM42 0.750 rientraM43 0.750 rientraM44 0.750 rientraM45 0.750 rientraM46 0.750 rientraM47 0.750 rientraM48 0.666 rientraM49 0.666 rientraM50 0.500 rientraM51 0.750 rientraM52 0.750 rientraM53 0.750 rientraM54 0.750 rientraM55 0.750 rientraM56 0.857 rientraM57 0.857 rientraM58 0.800 rientraM59 0.800 rientraM60 0.857 rientra


METRICA: TM


VALORE RILEVATO

DISTANZA



METRICA: SN


VALORE RILEVATO

DISTANZA



METRICA: MNS





METRICA: MDS


VALORE RILEVATO

DistanzaCREATE_IMP 2 rientradb_request 1 rientradb_result 48 eccezione (vedere note)JoinTab 3 rientraINS_RIC 1 rientraMetadati 4 rientraMOD_CANC_RIC 1 rientraRIC 1 rientraTipoValuta 1 rientra



METRICA: MTS


VALORE RILEVATO

DISTANZA

Finanziamenti 0 nessunaEntrate 0 nessunaPrenotazioni 0 nessunaImpegni 0 nessunaPagamenti 0 nessunaFinanziamenti Entrate 0 nessunaFinanziamenti Prenotazioni 0 nessunaPrenotazioni Impegni 0 nessunaImpegni Pagamenti 0 nessuna



METRICA: PT5NF



Appendice A

Processo di sviluppo Software

INDICE:

Work Flow Diagrams pag. 325Scenari Procedurali pag. 331Descrizione 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.


Work Flow Diagrams

Contesto


PROBLEMA

0

ANALISI

1

PROGETTO

2

CODIFICA

3

TESTING

4

FONTI DEI REQUISITI

PIANO METRICO

DESCRIZIONE DEL PROBLEMA

PIANO DI SVILUPPO SOFTWARE

DOCUMENTI ANALISI DEI REQUISITI

DIFETTI E MISURE (ANALISI)

PIANO DI TEST DI SISTEMA

OBIETTIVI

STANDARD

PIANO METRICO

REQUISITI UTENTE

REQUISITI INFORMATICI

PIANO METRICO

STANDARD

DOCUMENTI DI PROGETTO

DIFETTI E MISURE

PIANO DI TEST DI INTEGRAZIONE


STANDARD

PIANO METRICO

CODICE

PIANO DI TEST

PIANO DI TEST DI UNITÀ

DIFETTI E MISURE (CODIFICA)

CODICE

DOCUMENTI DEL TESTING

COMPONENTI CONFIGURATE

DOCUMENTI DI SVILUPPO

328

0 Problema


DESCRIVERE IL PROBLEMA

0.1

DEFINIRE GLI OBIETTIVI DI

BUSINESS E DI QUALITÀ

0.2

SCEGLIERE IL PIANO DI

SVILUPPO DEL SOFTWARE

0.3

DEFINIRE IL PIANO METRICO

0.4

OBIETTIVI

FONTI DEI REQUISITI

PIANO METRICOPIANO DI SVILUPPO SOFTWARE

DESCRIZIONE DEL PROBLEMA

329

1 Analisi


COSTRUIRE IL MODELLO E-R

1.1

Costruire i DFD

1.4

SPECIFICARE LE ENTITÀ

1.2

SPECIFICARE LE RELAZIONI

1.3

SPECIFICARE LE FUNZIONI

ELEMENTARI1.5

SPECIFICARE I FLUSSI DEI DATA

FLOW1.6

RILEVARE LE MISURE DI QUALITÀ

1.7

VERIFICARE

1.9

VALIDARE

1.10

DEFINIRE I REQUISITI NON

FUNZIONALI1.8

DEFINIRE IL PIANO DI TEST DI SISTEMA

1.11

DOCUMENTI ANALISI DEI REQUISITISTANDARDPIANO METRICO OBIETTIVI

REQUISITI NON FUNZIONALI

PIANO DI TEST DI SISTEMA

DIFETTI E MISURE (ANALISI)

DIFETTI (ANALISI)MISURE (ANALISI)

DFDS

REQUISITI UTENTE

DIZIONARIO DEI DATI (ANALISI)

SPECIFICHE DELLE FUNZIONI ELEMENTARI

DIFETTI DA VALIDAZIONE (ANALISI)

DIFETTI DA VERIFICA (ANALISI)

MODELLO E-R

ATTRIBUTI E FUNZIONALITÀ DI CIASCUNA RELAZIONE

ATTRIBUTI DI CIASCUNA ENTITÀ

330

2 Progetto


REQUISITI INFORMATICI

FONDERE LE FUNZIONI

2.1

DEFINIRE IL DIAGRAMMA

DELLE DIPENDENZE E DELLE TABELLE NORMALIZZATE

2.4

COSTRUIRE LA STRUCTURE

CHART2.2

DEFINIRE LE SPECIFICHE DEI

MODULI2.3


DEI MODULI2.5

COSTRUIRE LA CROSS REFERENCE

REXDS2.8


DATI GLOBALI2.6

DFD FUSO

STRUCTURE CHART

SPECIFICHE DEI MODULI

STRUCTURE CHART AGGIORNATA

MATRICE CROSS-REFERENCE REXDS

SPECIFICHE DELLE FUNZIONI ELEMENTARI

DFDS

TAVOLE E PERCORSI DI NAVIGAZIONE

SPECIFICHE DEI MODULI AGGIORNATE

DEFINIRE IL DIZIONARIO DEI

DATI (PROGETTO)2.7

PIANIFICARE LA REALIZZAZIONE DEI REQUISITI UTENTE

2.10

VALIDARE

2.12

VERIFICARE

2.11

RILEVARE LE MISURE DI QUALITÀ

2.9

DOCUMENTI INTERNI DI PROGETTO STANDARD

PIANO METRICO


MISURE E DIFETTI (PROGETTO)

DIFETTI (PROGETTO)

MISURE (PROGETTO)

DIFETTI DA VERIFICA (PROGETTO)

DIFETTI DA VALIDAZIONE (PROGETTO)

DEFINIRE IL PIANO DI TEST DI SISTEMA

2.13 DOCUMENTI DI PROGETTO

VINCOLI DI PROGRAMMAZIONE

REQUISITI A RISCHIO

DIAGRAMMA DELLE DIPENDENZE

DIZIONARIO DEI DATI (PROGETTO)

REQUISITI UTENTE

MODELLO E-R

DIZIONARIO DEI DATI (ANALISI)

DEFINIZIONE DELLE STRUTTURE DEI FILE ESTERNI E DEI DATI

GLOBALI

331

3 Codifica


VERIFICARE IL RISPETTO DEI

VINCOLI3.4

VALIDARE

3.6

VERIFICARE

3.5

RILEVARE MISURE DI QUALITÀ

3.3


VINCOLI DI PROGRAMMAZIONE

CODICE SORGENTE CORRETTO


3.1


3.2

CODICE OGGETTO

DEFINIRE IL PIANO DI TEST DI UNITÀ

3.7

CODICE SORGENTE

CODICE

STANDARDPIANO METRICO

VINCOLI DI PROGRAMMAZIONE A RISCHIO


MISURE (CODIFICA)

DIFETTI E MISURE (CODIFICA)

DIFETTI (CODIFICA)

DIFETTI DA VERIFICA (CODIFICA)

DIFETTI DA VALIDAZIONE (CODIFICA)

332

4 Testing


ESEGUIRE IL TEST DI UNITÀ

4.1

ESEGUIRE IL TEST DI INTEGRAZIONE

4.2

ESEGUIRE IL TEST DI SISTEMA

4.3

ESEGUIRE IL TEST DI ACCETTAZIONE

4.4

PIANO DI TEST



PIANO DI TEST DI ACCETTAZIONE

DOCUMENTI DEL TESTING

CODICE PIANO DI TEST DI SISTEMA

333

Scenari Procedurali

0 Problema

0.1 Descrivere il problema


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


0.2 Definire gli obiettivi di business e di qualità


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


0.3 Scegliere il piano di sviluppo del software


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


0.4 Definire il piano metrico



Input: Obiettivi

Procedura:

1. Descrivere il piano metrico dettagliando gli obiettivi

Output: Piano metrico



1 Analisi

1.1 Costruire il modello E-R


Input: Requisiti utente

Procedura:

1. Individuare le entità del sistema2. Fornire una definizione operativa per ciascuna entità3. Ricercare le relazioni utili al sistema4. Per ciascuna relazione individuata

4.1 Fornire una definizione operativa4.2 Specificare la cardinalità e le entità che essa coinvolge4.3 Definire il ruolo delle entità che essa coinvolge4.4 Fornire le obbligatorietà

Output: Modello E-R


1.2 Specificare le entità


Input: Requisiti utente, Modello E-R

Procedura:

1. Per ciascuna entità1.1 Fornire gli attributi1.2 Indicare gli attributi chiave

Output: Attributi di ciascuna entità


1.3 Specificare le relazioni


Input: Requisiti utente, Modello E-R

Procedura:

1. Per ciascuna relazione1.1 Specificare gli eventuali attributi1.2 Specificare la funzionalità

Output: Attributi e funzionalità di ciascuna relazione



1.4 Costruire i DFD


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 esso2. 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 primari3. Al livello i (i=0,1,…) individuare le funzioni non elementari candidate ad essere esplose al livello successivo con i relativi flussi di dati4. 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 informazioni5. Eseguire iterativamente i passi 3 e 4 fino ad ottenere solo funzioni elementari

Output: DFDs


1.5 Specificare le funzioni elementari


Input: Requisiti utente, DFDs

Procedura:

1. Per ciascuna funzione elementare individuata1.1 Definire una descrizione informale testuale1.2 Definire una descrizione algoritmica

Output: Specifiche delle funzioni elementari


1.6 Specificare i flussi dei Data Flow


Input: Requisiti utente, DFDs

Procedura:

1. Per ciascun flusso di informazione, data store o entità esterna1.1 Specificare il nome primario ed eventuali altri nomi utilizzati per individuarlo1.2 Fornire una descrizione testuale 1.3 Elencare i processi che lo referenziano indicando in quale modo1.4 Descrivere formalmente il contenuto utilizzando gli operatori di sequenza, selezione,

opzionalità e ripetizione


Output: Dizionario dei dati (analisi)

I.E.C.: Prodotti di output realizzati1.7 Rilevare le misure di qualità


Input: Documenti analisi dei requisiti, Piano metrico

Procedura:

1. Rilevare le misure di qualità secondo il piano metrico

Output: Misure (analisi)


1.8 Definire i requisiti non funzionali


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 opzionali3. Esprimere il rango in termini di valore che i requisiti obbligatori hanno per il committente

Output: Requisiti non funzionali


1.9 Verificare


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)


1.10 Validare



Input: Documenti analisi dei requisiti

Procedura:

1. Validare con il committente che quanto specificato corrisponda ai suoi requisiti

Output: Difetti da validazione (analisi)


1.11 Definire il piano di test di sistema


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



2 Progetto

2.1 Fondere le funzioni


Input: DFDs

Procedura:

1. Fondere tutti i DFD che contengono funzioni elementari2. Dividere il DFD fuso in unità di progetto

Output: DFD fuso


2.2 Costruire la Structure Chart


Input: DFD fuso, Specifiche delle funzioni elementari

Procedura:

1. Derivare la struttura del programma2. Trasformare il DFD fuso nella prima versione della Structure Chart3. Dettagliare la Structure Chart utilizzando le specifiche delle funzioni elementari4. Aggiungere i moduli gestione dell'interfaccia di I/O5. Aggiungere i moduli di gestione dei report6. Migliorare la Structure Chart utilizzando le euristiche7. Migliorare la Structure Chart secondo i principi dell'Information Hiding

Output: Structure Chart


2.3 Definire le specifiche dei moduli


Input: Structure Chart

Procedura:

1. Per ciascun modulo individuato1.1 Definire la specifica semantica e la specifica sintattica1.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo1.3 Descrivere i dati referenziati1.4 Definire gli altri moduli che esso utilizza

Output: Specifiche dei moduli



2.4 Definire il diagramma delle dipendenze e le tabelle normalizzate


Input: Modello E-R, Specifiche delle funzioni elementari

Procedura:

1. Elaborare la lista delle dipendenze2. Elaborare il diagramma delle dipendenze3. Costruire le tabelle normalizzate e i percorsi di navigazione

Output: Tavole e percorsi di navigazione, Diagramma delle dipendenze





Procedura:

1. Aggiungere i moduli per la gestione dei dati2. Migliorare la Structure Chart utilizzando le euristiche3. Migliorare la Structure Chart secondo i principi dell'Information Hiding4. Per ciascun modulo aggiunto o modificato

4.1 Definire la specifica semantica e la specifica sintattica4.2 Fornire l'algoritmo utilizzato per l'implementazione di ciascun modulo4.3 Descrivere i dati referenziati4.4 Definire gli altri moduli che esso utilizza






Procedura:



3. Individuare l'insieme dei dati globali fornendo per ciascuno di essi la struttura4. Costruire una matrice Cross Reference che associa ciascun dato globale/file esterno al modulo che

lo implementa



I.E.C.: Prodotti di output realizzati2.7 Definire il dizionario dei dati (progetto)



Procedura:




2.8 Costruire la Cross Reference RExDS



Procedura:




2.9 Rilevare le misure di qualità


Input: Documenti interni di progetto, Piano metrico

Procedura:


Output: Misure (progetto)


2.10 Pianificare le realizzazioni dei requisiti utente


Input: Documenti interni di progetto, Requisiti utente

Procedura:


1. Verificare quali requisiti non funzionali sono stati realizzati2. Se esistono altri requisiti che si possono soddisfare con il progetto

2.1 Modificare il progetto2.2 Riprendere l'esecuzione dalla attività 2.8 della fase di progetto

3. Trasformare gli altri requisiti in vincoli di programmazione4. Se esistono altri accorgimenti che il progettista vuole dettare al programmatore

4.1 Formulare altri vincoli

Output: Vincoli di programmazione, Requisiti a rischio


2.11 Verificare


Input: Documenti interni di progetto, Standard

Procedura:


Output: Difetti da verifica (progetto)


2.12 Validare


Input: Documenti interni di progetto

Procedura:

1. Validare con l'analista che quanto specificato corrisponda ai suoi requisiti

Output: Difetti da validazione (progetto)


2.13 Definire il piano di test di integrazione


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


3 Codifica




Procedura:







Procedura:





3.3 Rilevare le misure di qualità


Input: Codice, Piano metrico

Procedura:


Output: Misure (codifica)


3.4 Verificare il rispetto dei vincoli



Input: Codice, Vincoli di programmazione

Procedura:

1. Verificare che i vincoli di programmazione siano stati rispettati2. Se esistono vincoli non rispettati

2.1 Modificare il programma2.2 Ripetere dall'attività 3.2 della fase di codifica

Output: Vincoli di programmazione a rischio


3.5 Verificare


Input: Codice, Standard

Procedura:


Output: Difetti da verifica (codifica)


3.6 Validare


Input: Codice

Procedura:

1. Validare con il progettista che quanto specificato corrisponda ai suoi vincoli

Output: Difetti da validazione (codifica)


3.7 Definire il piano di test di unità


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à



4 Testing

4.1 Eseguire il test di unità


Input: Codice, Piano di test di unità

Procedura:

1. Realizzare i casi di test2. Eseguire i casi di test3. Rilevare gli eventuali difetti, classificarli e registrarli

Output: Documenti del testing


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:




4.3 Eseguire il test di sistema


Input: Codice, Piano di test di sistema

Procedura:




4.4 Eseguire il test di accettazione



Input: Codice, Piano di test di accettazione

Procedura:





Descrizione Manufatti








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


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



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) + 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)






Documenti del testing: documentazione ottenuta come risultato dell'esecuzione della fase di testing incluso il data base necessario alla riesecuzione del testing



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) + 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



Fonti dei requisiti: idee del committente, letteratura del dominio applicativo e applicazioni simili o concorrenti già sul mercato


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


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

Requisiti a rischio: requisiti che possono pregiudicare la conformità dell'applicazione software ai requisiti di qualità




Requisiti non funzionali: requisiti dell'applicazione software che non sono esprimibili attraverso le specifiche funzionali e informazionali





Standard: modello di qualità adottato dall'impresa





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à


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


Scheda rilevazione attività

ATTIVITÀDATA

RILEVAZIONEORARIO INIZIO ORARIO FINE ANNOTAZIONI

- 06/12/2000 16:00 19:00Formalizzazione processo

di miglioramento


di miglioramento


di miglioramento


sviluppo software


di miglioramento


di miglioramento


sviluppo software


di 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


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

1.6 08/01/2001 19:30 20:00Misurazione metriche del

modello di conferma


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

1.6 13/01/2001 20:30 21:00Misurazione metriche del

modello di conferma


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


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



- 20/01/2001 14:00 19:00Revisione e correzione

documenti

- 22/01/2001 10:00 13:00Preparazione materiale

consegna


caso di studio ingegneria del software ii

Documents