IT Project Management Lezione 4 Software Sizing Estimation Federica Spiga A.A. 2009-2010 1 Stima del software Concezione Analisi & Design Implementazione Test Rilascio Prima Stima Raffinamento della Stima Raffinamento della Stima e conteggio della parte già sviluppata Conteggio Analisi post mortem Incertezza 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
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
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 sizedel software 6 3
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: Vantaggi: Linee di Codice (LOC) Numero di Programmi Altre (numero report, numero strutture dati, ecc) 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
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
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) Users External Interface File (EIF) Input Output Inquiry Funzioni tipo Transazione: External Input (EI) Logical Files Input Output Logical Files External Output (EO) Measured Application Inquiry External Application External Inquiry (EQ) Interface 12 12 6
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 manutenzione ordinaria 14 14 7
Processo di conteggio Count Data Function: ILF and EIF Determine the Unadjusted FP count 1. Determinare il tipo di conteggio Determine the type of count Identify the counting scope and application boundary Count transactional functions: EI, EO and EQ Determine the adjusted FP count 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
Identificare il confine dell applicazione Il Confine dell applicazionedelimita 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
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
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 mantenutoall 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
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 unrecord 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 solavolta le informazioni: Presenti più volte per ragione tecniche-realizzative Denormalizzate per ragioni di efficienza elaborative 24 24 12
Complessità ILF Record Element Types (RET) Data Elements 1 to 19 20-50 51 or More 1 RET Low Low Average 2 to 5 RET Low Average High 6 or More RET 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 1 RET Low Low Average 2 to 5 RET Low Average High 6 or More RET Average High High Complexity Unadjusted FP Low 5 Average 7 High 10 26 26 13
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
Regole identificazione EI Si definisce un External Input(EI) un processo logico elementare dell applicazione, il cui intento primarioe 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 SOLODET 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
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 primarioe 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
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
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
Regole identificazione EQ Si definisce un External Output(EQ) un processo logico elementare dell applicazione, il cui intento primarioe 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
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 applicazioneed 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
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
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 Cognome Data Nascita Specializzazione Disponibilità Marco Bianchi 10/10/1970 Civilista Lun - Ven 44 44 22
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 Appuntamenti 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 = 32 UFP 5 EO N.A. 2 2 Low 4 6 EO N.A. 3 2 Low 4 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
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 Appuntamenti ILF 7.4 Avvocati EIF 5.5 1 EI 4.3 2 EI 4.3 3 Ei 4.3 4 EQ 3.8 = 40,4 UFP 5 EO 5.4 6 EO 5.4 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
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
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 numerodifp Pesati (AFP Adjusted Function Point), dipendedaltipodi conteggio Progetti di nuovo sviluppo AFP = UAF * VAF Interventi di manutenzione evolutiva AFP = (UFP[funzioniaggiunte]+UFP[funzioni modificate]) * VAF[postmodifiche]+UFP[funzioni modificate] *VAF[antemodifiche] Applicazioni in esercizio AFP = UAF * VAF 52 52 26