IT Project Management - Lezione 4 - Stima della Size

Software Size Estimation
IT Project Management
Lezione 4 – Software Sizing Estimation
Federica Spiga
A.A. 2009-2010
1
Stima del software
Concezione
Prima Stima
Analisi & Design
Raffinamento
della Stima
Test
Implementazione
Raffinamento della
Conteggio
Stima e conteggio della
parte già sviluppata
Incertezza
Rilascio
Analisi post
mortem
Incertezza
E’ necessario stimare l’effort in più momenti:
• Durante la fase di Concezione del progetto per dare un prezzo al cliente => E’
il momento più critico perchè si deve fissare un prezzo quando i requirement
non sono del tutto chiariti
•Durante il progetto per raffinare la stima
•Alla fine per progetto per verificare lo scostamento tra “planned” e “actual”
2
1
Software Size Estimation
Incertezza della stima
3
Richiami sui metodi di stima
Non esiste un metodo semplice per effettuare una stima precisa dell’effort necessario per
sviluppare un sistema software
• Le stime iniziali si basano su informazioni inadeguate (ad esempio, la definizione dei
requisiti utente)
•Le persone che lavorano al progetto possono essere non note a priori
•Le stime dei costi del progetto possono essere auto-verificate
• La stima definisce il budget e il prodotto viene modificato per rispettare il budget
•Ogni metodo ha punti di forza e debolezze
•La stima dovrebbe basarsi su molti metodi
•Se i metodi non restituiscono approssimativamente lo stesso risultato, si hanno
informazioni insufficienti per poter effettuare una stima
•Si cerca di ottenere ulteriori informazioni e quindi eseguire stime più precise
4
2
Software Size Estimation
Tecniche di stima
Giudizio dell’esperto: Si consulta un esperto del dominio e delle tecniche di sviluppo
che fornisce le stime dell’effort in base alla propria esperienza
Il giudizio di esperti (Metodo Delphi):. Il metodo Delphi consiste in un processo di
stima collettiva che avviene in modo strutturato e progressivo. Viene formato un
gruppo di stimatori. Ogni stimatore riceve le medesime informazioni di partenza sul
progetto e stima l'effort, indipendentemente e in modo anonimo. Un coordinatore
raccoglie le stime, elabora dati di sintesi (medie, minimi, massimi, …) e le presenta per
confronto agli stimatori. Viene effettuata un'analisi congiunta, che porta
tendenzialmente allo scarto dei valori estremi, e favorisce l'approfondimento dei fattori
critici. Il giro di stima successivo conduce generalmente ad una convergenza delle stime.
Stima per analogia: si stima la size o l’effort sfruttando le analogie con progetti
precedenti o utilizzando database pubblici che contengono dati storici (ISBSG)
Modello algoritmico: utilizza algoritmi matematici per calcolare l’effort a partire dalle
dimensioni del software, es COCOMO
5
Tecniche di stima – alcuni commenti
il PMBOK ordina le tecniche per la stima della durata delle attività di un
progetto per preferenza e maggiore utilizzo
1. expert judgement (singolo o Delphi)
2. stima per analogia (analogous estimating)
3. Criterio quantitativo (quantitatively based durations), dato dalla
moltiplicazione di una qualsivoglia unità di conteggio tecnica per il livello
medio di produttività.
Però negli ultimi 25 anni la comunità dell’Ingegneria del Software ha indirizzato
notevoli sforzi al tema della stima. La diffusione ed applicazione di modelli
basati sull’analisi di regressione quali COCOMO per esempio utilizza una
relazione tra effort e size :
Effort= f(size)
Quindi un punto di partenza per il calcolo dell’effort è la size del software
6
3
Software Size Estimation
Metriche per il dimensionamento del software
•Esistono vari tipi di metriche per il dimensionamento del software
•Metriche dimensionali
•Metriche funzionali
•Metriche Object Oriented
7
7
Metriche dimensionali
•Forniscono una misurazione “diretta” del software. Definiscono le dimensioni del prodotto software in
funzione del numero di occorrenze di un determinato oggetto generato nel processo di sviluppo. Le più
usate sono:
•Linee di Codice (LOC)
•Numero di Programmi
•Altre (numero report, numero strutture dati, ecc)
Vantaggi:
•Facilità nel calcolo
Svantaggi
•Non si possono usare nelle fasi alte del progetto di sviluppo
•Le misure ottenute sono poco significative per valutare l’efficienza del processo di sviluppo, in quanto sono condizionate
da fattori:
•Soggettivi (es. stile del programmatore)
•Tecnologici (es. linguaggio usato)
•Architetturali
8
8
4
Software Size Estimation
Metriche funzionali
Forniscono una misurazione “indiretta” del software. Definiscono le dimensioni di un
prodotto software in termini di funzionalità fornite all’utente. Si basano su formule
empiriche, stabilite su base statistica, tre requisiti informativi del prodotto e
complessità del software.
Le metriche più conosciute sono:
Function Point
Feature Point
Full Function Point
9
9
Function Point
• E’ la prima metrica funzionale, proposta nel 1979 da A.J.Albrecht in IBM
• Presidiata dall’ International Function Point User Group (IFPUG), che è
l’organismo responsabile dell’emanazione e dell’aggiornamento delle
regole standard di conteggio (standard attuale è descritto nel Counting
Pratice Manual Versione 4.2)
Vantaggi
•Conta le funzionalità sviluppate, indipendentemente dal linguaggio
• Non misura il software ma i requisiti da cui lo si deriva
Svantaggi
•Considera solo l’I/O e tiene in poco conto la complessità algoritmica
•E’ soggettivo. Persone diverse possono arrivare a stime/conteggi differenti
10
10
5
Software Size Estimation
Function Point Analysis–Obiettivi
La Function Point Analysis è una metrica standard per la misurazione delle applicazioni
software viste dal punto di vista dell’utente. L’approccio è guidato dai seguenti obiettivi:
•
Misurare le funzionalità che il cliente richiede e riceve
•
Misurare lo sviluppo e la manutenzione del software indipendentemente dalla
tecnologia usata per l’implementazione.
Inoltre:
•
Può essere utilizzata nelle fasi alte del processo ed essere poco onerosa
nell’applicazione
•
Ottiene misurazioni consistenti nell’ambito di progetti e organizzazioni diversi
(anche se mantiene una certa soggettività)
11
11
Elementi Base
Il metodo dei Function Point consiste nell’identificare e contare le funzionalità
che l’applicazione deve fornire:
• Funzioni tipo Dati:
•
Internal Logical File (ILF)
•
External Interface File (EIF)
Users
Input
Output
Inquiry
• Funzioni tipo Transazione:
Input
•
External Input (EI)
•
External Output (EO)
•
External Inquiry (EQ)
Logical Files
Measured Application
Output
Inquiry
Logical Files
External Application
Interface
12
12
6
Software Size Estimation
Definizioni Generali
Utente: E’ il soggetto che fornisce i requirement funzionali del sistema e che interagisce con il sistema
Vista Utente:Descrizione delle necessità informative dell’utente del sistema espresse nel linguaggio
dell’utente. I progettisti software traducono queste necessità in soluzioni tecnologiche
Identificativo per l’utente:Requirement, relativo alle informazioni trattate o ai processi di trattamento
logico di tali informazioni, compreso e riconosciuto sia dagli utenti finali che dai progettisti software
Ambito del conteggio:Definisce la porzione di software che deve essere misurato.E’ determinato dallo
scopo del conteggio, identifica quali funzioni devono essere incluse nel processo di conteggio. Puo’
includere più di una applicazione
Processo elementare:E’ la più piccola unità di lavoro significativa per l’utente. E’ autonomo e lascia
l’applicazione in uno stato di consistenza funzionale.
Informazione di controllo:E’ il dato che influenza il processo elementare. Specifica cosa, come e
quando il dato deve essere processato
13
13
Tipologia di conteggio
La metrica dei Function point si può applicare:
Progetti di sviluppo nuova applicazione
Determina la dimensione funzionale per la stima di impegno e costo complessivo del progetto
Misura le funzionalità richieste dall’utente
Previste più fasi di revisione del conteggio nei momenti differenti del processo di sviluppo
Progetti di manutenzione evolutiva
Determina l’entità dell’intervento di mnautenzione evolutiva al fine di stimare impegno e costo di
realizzazione
Misura la dimensione delle variazioni funzionali da apportare all’applicazione
Fornisce gli elementi per aggiornare la dimensione in FP dell’applicazione in modo che rifletta i cambiamenti
apportati con l’intervento di manutenzione
Applicazioni già esistenti
Determina la dimensione funzionale di una applicazione software esistente
Misura le funzionalità in esercizio
Utile per monitorare la crescita del patrimonio software e stimare impegni e costi necessari per la
14
manutenzione ordinaria
14
7
Software Size Estimation
Processo di conteggio
Count Data
Function:
ILF and EIF
Determine the
Unadjusted FP
count
Identify the
counting scope
and application
boundary
Determine
the type of
count
Determine the
adjusted FP count
Count transactional
functions:
EI, EO and EQ
1. Determinare il tipo di conteggio
2. Determinare i confini dell’applicazione
Determine the
Value of Adjustment
Factor (VAF)
3. Identificare le funzioni di tipo dato
4. Identificare le funzioni di tipo transazione
5. Determinare il numero dei FP non pesati
6. Determinare il fattore di aggiustamento
(VAF)
7. Determinare il numero dei FP pesati
15
15
Identificare l’ambito del conteggio
L’Ambito del conteggio individua il dominio funzionale preso in considerazione,
in relazione allo scopo e alle finalità del conteggio:
• Nuova applicazione: comprenderà tutte le funzionalità che dovranno essere
rilasciate
• Manutenzione evolutiva: comprenderà solo le funzionalità da aggiungere,
modificare o cancellare
• Applicazione esistente: conprenderà tutte le funzionalità che rientrano nella
finalità del conteggio (tutte le funzionalità / solo le funzionalità utilizzate)
16
16
8
Software Size Estimation
Identificare il confine dell’applicazione
Il Confine dell’applicazione delimita il sistema oggetto della misurazione, tracciando una
linea di demarcazione tra il sistema stesso e l’utente o gli altri sistemi software
• È l’interfaccia concettuale tra l’applicazione e il mondo esterno
• E’ la “membrana” attraverso la quale passano i dati di input e di output dell’applicazione
• Racchiude i file logici mantenuti dall’applicazione e consente di identificare i file logici
referenziati ma non mantenuti dall’applicazione
Regole per identificare il confine dell’applicazione:
• Il confine dell’applicazione deve rispettare la visione che l’utente ha del sistema
• La separazione delle funzionalità in applicazioni distinte deve essere fatta in base a criteri
funzionali e non tecnologici
• Deve essere stabilito in modo indipendente dall’ambito del conteggio
17
17
Conteggio delle Funzioni di tipo Dati
Le funzioni di Tipo Dati rappresentano le funzionalità fornite all’utente per soddisfare i
requisiti informativi da lui espressi.
• ILF: Internal Logical File
•
Gruppo di dati logicamente collegati o di informazioni di controllo, riconoscibili
dall’utente , mantenuti all’interno dell’applicazione
• EIF: External Interface File
•
Gruppo di dati logicamente collegati o di informazioni di controllo, riconoscibili
dall’utente, referenziati dall’applicazione ma mantenuti all’interno del confine di
applicazione di un’altra applicazione
18
18
9
Software Size Estimation
Regole identificazione ILF
Si definisce un File Interno Logico (ILF) un gruppo di dati o informazioni di controllo per il
quale devono essere soddisfatte contemporaneamente le seguenti condizioni
• Logico, significativo per l’utente, rispondente ai requisiti funzionali
• Mantenuto all’interno del confine dell’applicazione attraverso un processo elementare
dell’applicazione stessa
19
19
Esempi di ILF
• ILF corretti
•
•
•
•
•
Dati di dominio dell’applicazione
Dati relativi alla sicurezza dell’applicazione
Informazioni di Help gestite con funzioni della propria applicazione
Tabelle di decodifica dei messaggi di errore, gestite da funzioni della applicazione
Tabelle di parametri gestite da funzioni della propria applicazione
• ILF scorretti
•
•
•
•
Work files
File temporanei
File legati alla tecnologia usata
Strutture dati usate per implementare legami logici esistenti tra le entita’ (a meno che non
abbiano attributi propri)
• File di edit, Help, decodifica errori che non siano mantenuti dall’applicazione.
20
20
10
Software Size Estimation
Regole identificazione EIF
Si definisce un File Esterno di Interfaccia (EIF) un gruppo di dati o informazioni di
controllo per il quale devono essere soddisfatte contemporaneamente le seguenti
condizioni
• Logico, significativo per l’utente, rispondente ai requisiti funzionali
• Esterno al confine dell’applicazione e da essa referenziato
• Non mantenuto all’interno del confine dell’applicazione
• Considerato ILF da almeno un’altra applicazione
21
21
Esempi di EIF
• EIF corretti
• Dati di dominio di altre applicazioni, referenziati all’interno dell’applicazione
• Dati relativi alla sicurezza dell’applicazione gestiti da funzioni di utility esterne
all’applicazione
• Informazioni di Help gestite con funzioni esterne alla propria applicazione
• Tabelle di decodifica dei messaggi di errore, gestite con funzioni esterne alla
propria applicazione
• EIF scorretti
• Dati provenienti dall’esterno dell’applicazione utilizzati per aggiornare uno o piu’
ILF dell’applicazione
• Dati dell’applicazione formattati ed inviati ad altre applicazioni
• File legati alla tecnologia usata
22
22
11
Software Size Estimation
Regole Complessità ILF-EIF
Per valutare la complessità degli ILF-EIF bisogna considerare due caratteristiche
•
Record Element Type (RET): sottogruppo logico di dati all’interno
dell’ILF-EIF, riconoscibile dall’utente.
•
Data Element Type (DET):informazioni logiche distinte e significative
per l’utente presenti nell’ILF-EIF
23
23
Contare i RET e DET
Per ogni ILF-EIF contare un Record Element Type (RET) per ciascun sottogruppo logico di informazioni:
•Obbligatorio: Insieme di attributi che l’utente deve necessariamente utilizzare per
descrivere totalmente le proprietà di una entità
•Opzionale: Insieme di attributi che l’utente potrebbe utilizzare per descrivere le proprietà
di una entità
Se l’ ILF-EIF possiede un solo sottogruppo di informazioni si deve considerare un solo RET
Per ogni ILF-EIF contare un solo Data Element Type (DET) per ogni informazione:
• Significativa per l’utente, non ricorsiva
•Mantenuta o referenziata attraverso un processo elementare dell’applicazione
•Necessaria per mantenere una relazione logica con un altro ILF-EIF
Devono essere conteggiate una sola volta le informazioni:
• Presenti più volte per ragione tecniche-realizzative
• Denormalizzate per ragioni di efficienza elaborative
24
24
12
Software Size Estimation
Complessità ILF
Record Element Types
(RET)
1 RET
2 to 5 RET
6 or More RET
Data Elements
1 to 19
20 - 50
51 or More
Low
Low
Average
Low
Average
High
Average
High
High
Complexity
Unadjusted
FP
Low
7
Average
10
High
15
25
25
Complessità EIF
Record Element Types
(RET)
Data Elements
1 to 19
20 - 50
51 or More
Average
1 RET
Low
Low
2 to 5 RET
Low
Average
High
Average
High
High
6 or More RET
Complexity
Unadjusted
FP
Low
5
Average
7
High
10
26
26
13
Software Size Estimation
Conteggio delle Funzioni di tipo Transazione
Le funzioni di Tipo Dati rappresentano le funzionalità fornite all’utente per il trattamento dei dati
dell’applicazione. Gli elementi di conteggio sono identificati come:
EI: External Input
•
Processo elementare che elabora i dati o le informazioni di controllo provenienti dall’esterno del
confine dell’applicazione
EO: External Output
•
Processo elementare che genera dati o informazioni di controllo che vengono inviati all’esterno del
confine dell’applicazione attraverso una logica elaborativa piu’ complessa di un semplice
reperimento dati
EQ: External Inquiry
•
Processo elementare che genera dati o informazioni di controllo che vengono inviati all’esterno del
confine dell’applicazione attraverso un semplice reperimento dati
27
27
Esempi di EI
EI corretti
• Transazioni sincrone e asincrone che aggiornano un ILF o forniscono informazioni
di controllo
• Input che aggiornano un ILF dell’applicazione
• Messaggi provenienti da altre applicazioni che innescano elaborazioni all’interno
dell’applicazione
• Input fisici (analogici o digitali) che attivano funzionalita’ dell’applicazione
EI scorretti
•
•
•
•
Dati provenienti dall’esterno dell’applicazione utilizzati in sola lettura
Richieste di visualizzazioni di dati
Videate che assolvono alla sola funzione di Logon, Menu’ o aiuto navigazionale
Risposte di messaggi che chiedono conferma di una operazione
28
28
14
Software Size Estimation
Regole identificazione EI
Si definisce un External Input (EI) un processo logico elementare dell’applicazione, il cui
intento primario e’ di mantenere uno o piu’ ILF dell’applicazione. Deve soddisfare tutti
i seguenti requisiti
• I dati o le informazioni di controllo che elabora sono provenienti dall’esterno
dell’applicazione
• Deve aggiornare i dati di almeno un ILF dell’applicazione
• E’ univoco nell’ambito dell’applicazione:
•
Per il tipo di trattamento logico dei dati
•
Per il tipo di ILF o EIF trattati
•
Per il tipo di dati elementari trattati
29
29
Regole Complessità EI (1)
Per ciascun EI identificato deve essere conteggiato un File Type Referenced (FTR) per:
•
Ogni ILF aggiornato nel corso dell’elaborazione
•
Ciascun ILF, EIF letto nel corso dell’elaborazione
Per ciascun EI identificato deve essere conteggiato un Data Element Type (DET) per ogni informazione :
•
Significativa per l’utente, non ricorsiva (duplicata)
•
Che attraversa il confine dell’applicazione ed e’ necessaria a completare il processo logico
Deve essere contato come UN SOLO DET
•
L’insieme dei messaggi di errore e di conferma emessi nel corso dell’elaborazione
•
L’insieme degli input con i quali viene attivato il processo o specificata una azione da
intraprendere (tasto del mouse, tastiera, ecc)
Non devono essere conteggiati come DET
•
Le informazioni generate nell’ambito del processo e memorizzate in un ILF se queste non
attraversano il confine dell’applicazione
30
30
15
Software Size Estimation
Regole Complessità EI (2)
Files Type Referenced
(FTR)
Data Elements
1-4
5-15
Greater than
15
Less than 2
Low
Low
Average
2
Low
Average
High
Greater than 2
Average
High
High
Complexity
Unadjusted FP
Low
3
Average
4
High
6
31
31
Regole identificazione EO
Si definisce un External Output (EO) un processo logico elementare dell’applicazione, il cui intento
primario e’ di presentare delle informazioni ad un utente del sistema. Deve soddisfare tutti i
seguenti requisiti
• I dati o le informazioni di controllo sono mandate all’esterno del confine dell’applicazione
• Deve aggiornare i dati di almeno un ILF dell’applicazione
• E’ univoco nell’ambito dell’applicazione:
•
Per il tipo di trattamento logico dei dati
•
Per il tipo di ILF o EIF trattati
•
Per il tipo di dati elementari trattati
L’EO deve inoltre soddisfare almeno uno dei seguenti requisiti:
• Nel trattamento dei dati deve includere almeno una formula di calcolo matematico
• Nel trattamento logico dei dati vengono creati dei dati derivati
• Nel trattamento logico dei dati viene aggiornato almeno un ILF
• Nel trattamento logico dei dati deve modificare il comportamento del sistema
32
32
16
Software Size Estimation
Esempi di EO
• EO corretti
• Report complessi (che fanno uso di algoritmi complessi o di calcolo)
• File o messaggi dell’applicazione inviati ad altre applicazioni
• Risultati di interrogazioni che contengono dati derivati o calcolati
• EO scorretti
• Report semplici (visualizzazione)
• Report ottenuti direttamente dall’utente con meccanismi di query (SQL, ..)
• File di lavoro che si scambiano client e server all’interno della stessa applicazione
33
33
Regole Complessità EO
Per ciascun EO identificato deve essere conteggiato un File Type Referenced (FTR) per:
•
Ciascun ILF, EIF letto nel corso dell’elaborazione
•
Ogni ILF aggiornato nel corso dell’elaborazione
Sono considerati UNA sola volta gli ILF sia letti che aggiornati
Per ciascun EO identificato deve essere conteggiato un Data Element Type (DET) per ogni
informazione :
•
Significativa per l’utente, non ricorsiva (duplicata)
•
Che attraversa il confine dell’applicazione ed e’ necessaria per specificare
quando, quali e/o come i dati devono essere estratti o generati nell’ambito del
processo elementare
•
In output al processo
34
34
17
Software Size Estimation
Regole Complessità EO (2)
Deve essere contato come UN SOLO DET
• Le informazioni presenti sia in input che in output
• L’insieme dei messaggi di errore e di conferma emessi nel corso dell’elaborazione
• L’insieme degli input con i quali viene attivato il processo o specificata una azione da
intraprendere (tasto del mouse, tastiera, ecc)
Non devono essere conteggiati come DET
• Le informazioni generate nell’ambito del processo e memorizzate in un ILF se queste non
attraversano il confine dell’applicazione
• I dati fissi
• Le informazioni accessorie generate dal sistema (numero pagina, data elaborazione, ecc..)
35
35
Regole Complessità EO (4)
Files Type Referenced
(FTR)
Data Elements
1-5
6-19
Greater than
19
less than 2
Low
Low
Average
2 or 3
Low
Average
High
Greater than 3
Average
High
High
Complexity
Unadjusted FP
Low
4
Average
5
High
7
36
36
18
Software Size Estimation
Regole identificazione EQ
Si definisce un External Output (EQ) un processo logico elementare dell’applicazione, il cui intento
primario e’ di presentare delle informazioni ad un utente del sistema. Deve soddisfare tutti i
seguenti requisiti
• I dati o le informazioni di controllo sono mandate all’esterno del confine dell’applicazione
• E’ univoco nell’ambito dell’applicazione:
•
Per il tipo di trattamento logico dei dati
•
Per il tipo di ILF o EIF trattati
•
Per il tipo di dati elementari trattati
L’EQ deve inoltre soddisfare almeno uno dei seguenti requisiti:
• Nel trattamento dei dati NON deve includere almeno una formula di calcolo matematico
• Nel trattamento logico dei dati NON vengono creati dei dati derivati
• Nel trattamento logico dei dati NON viene aggiornato almeno un ILF
• Nel trattamento logico dei dati NON deve modificare il comportamento del sistema
37
37
Esempi di EQ
• EQ corretti
•
•
•
•
Report semplici (visualizzazione)
Report ottenuti direttamente dall’utente con meccanismi di query (SQL, ..)
Dati ottenuti tramite funzioni di browsing
Lite e finestre di dati visualizzati allo scopo di selezione
• EQ scorretti
•
•
•
•
File di lavoro che si scambiano client e server all’interno della stessa applicazione
File o messaggi dell’applicazione inviati ad altre applicazioni
Risultati di interrogazioni che contengono dati derivati o calcolati
Report complessi (che fanno uso di algoritmi complessi o di calcolo)
38
38
19
Software Size Estimation
Regole Complessità EQ
Per ciascun EQ identificato deve essere conteggiato un File Type Referenced
(FTR) per:
Ciascun ILF, EIF letto nel corso dell’elaborazione
Per ciascun EQ identificato deve essere conteggiato un Data Element Type (DET) per ogni
informazione :
Significativa per l’utente, non ricorsiva (duplicata)
Che attraversa il confine dell’applicazione ed e’ necessaria per specificare
quando, quali e/o come i dati devono essere estratti o generati nell’ambito del
processo elementare
In output al processo
39
39
Regole Complessità EQ (2)
Per ciascun EO identificato deve essere conteggiato un Data Element Type (DET) per ogni
informazione :
Significativa per l’utente, non ricorsiva (duplicata)
Che attraversa il confine dell’applicazione ed e’ necessaria per specificare quando,
quali e/o come i dati devono essere estratti o generati nell’ambito del processo
elementare
In output al processo
40
40
20
Software Size Estimation
Regole Complessità EQ (3)
Files Type Referenced
(FTR)
Data Elements
1-5
6-19
Greater than
19
less than 2
Low
Low
Average
2 or 3
Low
Average
High
Greater than 3
Average
High
High
Complexity
Unadjusted FP
Low
3
Average
4
High
6
41
41
Determinare i FP non pesati
Individuato il tipo ed il grado di complessita’ di ogni elemento, e assegnato ad essi uno specifico
valore (riportato nelle varie tabelle con il valore in FP), si e’ in grado di calcolare il numero
totale dei FP NON PESATI.
La somma dei contributi relativi a tutte le funzioni considerate nell’ambito della FP
Analysis costituisce la dimensione in Function Point non pesati (UFP- Unadjusted
Function Point) dell’applicazione
42
42
21
Software Size Estimation
Esempio
Sistema integrato di gestione avvocati.
• A : applicazione di gestione anagrafica degli avvocati
• Informazioni: nome, cognome, data nascita, specializzazione, orario lavorativo
(disponibilità)
• Funzionalità: Aggiungi nuovo avvocato, modifica esistente, visualizza dettagli avvocato,
cancella avvocato, verifica disponibilità per giorno e ora.
• B: applicazione di gestione appuntamenti avvocati
• Informazioni: tipo di incarico, cliente, data, avvocato, costo.
• Funzionalità: Prenota nuovo appuntamento, Modifica data appuntamento, Stampa report
appuntamento, Stampa saldo ore fatturate avvocato per data, Visualizza il totale degli
appuntamenti per data.
43
43
Esempio
Poniamo il confine sull’applicazione di prenotazione appuntamenti (B):
Le informazioni di dominio possono essere tutte contenute all’interno di un ILF (File logico
Appuntamenti)
Tipo Appuntamento
Cliente
Data
Avvocato
Costo Visita
Consulenza Civile
M.Rossi
22/04/2010
P. Verdi
130 €
Le informazioni relative all’anagrafica avvocati sono anch’esse contenute in un File Logico (File
logico Avvocati). Non essendo manutenuto da B, tale file è un EIF
Nome
Marco
Cognome
Data Nascita
Specializzazione
Disponibilità
Bianchi
10/10/1970
Civilista
Lun - Ven
44
44
22
Software Size Estimation
Esempio
Funzionalità richieste dall’utente per B:
1.
Prenota nuovo appuntamento EI (inserisci tipo, cliente, data, avvocato, costo)
2.
Modifica data prenotazione appuntamento EI (modifica data)
3.
Assegna appuntamento ad un altro avvocato EI (modifica avvocato)
4.
Stampa il report dell’appuntamento EQ (Richiesta dettagli all’applicazione)
5.
Stampa saldo ore fatturate avvocato EO
6.
Visualizza il totale degli appuntamenti per data EO
type
RET
DET
FTR
Complexity
FP
ILF
1
5
N.A.
Low
7
Avvocati
EIF
1
5
N.A.
Low
5
1
EI
N.A.
6
2
Low
3
2
EI
N.A.
2
1
Low
3
3
Ei
N.A.
2
2
Low
3
4
EQ
N.A.
6
1
Low
3
5
EO
N.A.
2
2
Low
4
6
EO
N.A.
3
2
Low
4
Appuntamenti
= 32 UFP
45
Determinare i FP non pesati – Metodo ACE
•Nella pratica, soprattutto quando si stima nelle fasi iniziali non è sempre
semplice individuare tutti i RET, DET e FTR.
•Si utilizza allora la tecnica ACE: Average Complexity Estimation, che associa ai
processi elementari all’interno delle stessa categoria lo stesso peso medio
• I pesi medi sono standard e sono calcolati facendo la media tra i 7200 progetti
dell’ ISBSG
UFPACE = #ILF*7.4+#EIF*5.5+#EI*4.3+#EO*5.4+#EQ*3.8
46
46
23
Software Size Estimation
Esempio pecedente – calcolo ACE
Funzionalità richieste dall’utente per B:
1.
Prenota nuovo appuntamento EI (inserisci tipo, cliente, data, avvocato, costo)
2.
Modifica data prenotazione appuntamento EI (modifica data)
3.
Assegna appuntamento ad un altro avvocato EI (modifica avvocato)
4.
Stampa il report dell’appuntamento EQ (Richiesta dettagli all’applicazione)
5.
Stampa saldo ore fatturate avvocato EO
6.
Visualizza il totale degli appuntamenti per data EO
type
FP
ILF
7.4
Avvocati
EIF
5.5
1
EI
4.3
2
EI
4.3
3
Ei
4.3
4
EQ
3.8
5
EO
5.4
6
EO
5.4
Appuntamenti
= 40,4 UFP
47
Determinare il fattore di aggiustamento (VAF)
Al valore in FP non pesati, e’ applicato un coefficiente correttivo (VAF
– Value of Adjustement Factor), ottenuto valutando il grado di
influenza di 14 fattori specifici detti Caratteristiche Generali del
Sistema (GSC) che rappresentano i requisiti non funzionali del
sistema.
48
48
24
Software Size Estimation
Caratteristiche Generali del Sistema
GCS
Degree of influence
Data communications
0-5
Distributed data processing
0-5
Performance
0-5
Heavily used configuration
0-5
Transaction rate
0-5
On-Line data entry
0-5
End-user efficiency
0-5
On-Line update
0-5
Complex processing
0-5
Reusability
0-5
Installation ease
0-5
Operational ease
0-5
Multiple sites
0-5
Facilitate change
0-5
Total Degree of Influence (TDI)
0-70
49
49
Grado di influenza
Il Grado di influenza di ciascuna GSC puo’ assumere i seguenti valori:
0 Caratteristica non presente o ininfluente
1
Influenza limitata o secondaria
2
Influenza moderata
3
Influenza media
4
Influenza significativa
5
Influenza forte e generalizzata
50
50
25
Software Size Estimation
Calcolare il VAF
VAF = (65 + TDI)/100
Dove il TDI e’ il Total Degree of Influence
51
51
Calcolare il Numero di FP Pesati
Il numero di FP Pesati (AFP – Adjusted Function Point), dipende dal tipo di
conteggio
Progetti di nuovo sviluppo
AFP = UAF * VAF
Interventi di manutenzione evolutiva
AFP = (UFP[funzioni aggiunte]+UFP[funzioni modificate]) *
VAF[postmodifiche]+UFP[funzioni modificate] *VAF[antemodifiche]
Applicazioni in esercizio
AFP = UAF * VAF
52
52
26