Stima delle linee di codice (LOC)

1. Stima delle linee di codice (LOC) • Di cosa: dipende in quale momento la stima deve essere fatta • Fattibilità: stima di funzioni (esempio ad un DFD molto generico) o scenari • Documento dei requisiti – modello analitico: stima di funzioni o scenari dettagliati • Architettura: stima delle dimensione di un insieme di moduli • Come: in generale per decomposizione e per analogia con software simili già sviluppati in precedenza • Tutte le tecniche di modellazione viste ammettono una decomposizione top-down; si tende quindi a decomporre per poter stimare più correttamente le LOC di funzioni, scenari, moduli semplici, per poi aggregare sommando le varie LOC ottenute • Ma: valori diversi di LOC, necessaria conoscenza pregressa --- necessari metodi standard per LOC oppure non usare le LOC

2. Reviewing the Lines of Code • Rather imprecise (what is really a line of code?) • Probably, dependent on the language to be used (how many lines of code of a language are required for implementing an algorithm?) • Difficult to be estimated • Not really related to the software to be developed • What do we really want to measure? various variations: KDSI (thousand delivered source instructions), NCSS (non commented source statements)

3. Function Points • To define a standardised evaluation of software dimension to be developed • Based on a conceptual definition of the software to be developed (should be an intermediate conceptual definition between the analysis model and the design model) • To allow to evaluate the LOC (backfiring) anyway

4. www.ifpug.org Brevissima Storia dei FPs

5. Uso dei Function Points per stimare le LOC in COCOMO

6. Cost Models based on FPs exponent effort = const+tuning coefficient * size empirically usually derived derived as person-months of effort required Instead of using LOC, there is the Number of function points FPs either a constant or a number derived based on complexity of project

7. Modello di riferimento per il calcolo dei FPs

8. DFD+ER+CLASSI+….. di una sorta di modello analitico Meglio…. Ma non così semplice!

9. Function Point • Basati su una rappresentazione di un “qualunque” tipo di software in due tipologie di funzione: • Transazione, distinta nelle tre categorie: • EI, external input • EO, external output • EQ, external query • Dati • ILF, internal logical file • EIF, external logical file • Per ogni elemento identificato nelle diverse categorie si conta un certo numero detto di function points a seconda della complessità di tale elemento • ILF e EIF non hanno NULLA a che vedere con il concetto di file quale struttura dati!

10. ILF e EIF

11. Regole EIF, ILF

12. Complessità dei EIF e ILF: RET e DET

13. Matrice di Complessità Matrice Calcolo Function Points per ILF e EIF

14. Esempio: Gestione Personale Descrizione Qualifica Persona salario base Un ILF Due ILF E’ possibile provare l’esempio anche con un software di supporto all’identificazione: www.totalmetrics.com/cms/servlet/main2?Subject=List&ID=38 Utente può considerare singolarmente una Persona e la descrizione della sua Qualifica (e vice-versa) Utente parla sempre di una Persona e della sua Qualifica (e vice-versa) Erogazione stipendi, Gestione carriere Cioè un ILF può essere un’aggregazione in una Entità (Classe) Erogazione stipendi, Applicazione contratti di lavoro, Gestione carriere

15. Esempio: Gestione del Personale gg mm aa Persona Tre DET Un DET Utente riconosce separatamente anno, giorno e mese d’assunzione Utente riconosce il campo data di assunzione Erogazione Stipendi, Gestione Carriere Statistiche annuali e mensili sulle assunzioni, pensionamenti etc. Aggregazione di più attributi

16. Esempio: Gestione Personale Ore straordinario (0,1) Persona Due RET Un RET Utente considera sempre anche le ore dello straordinario Utente considera separatamente chi può avere le ore dello straordinario e chi no Erogazione Stipendi, Gestione Carriere Erogazione Stipendi distinta per qualifica Gli attributi sono considerati tutti, sempre

17. Riassunto EIF, ILF • Identificare gli EIF e ILF e, successivamente, DET e RET non è semplice • Necessitano di regole per l’identificazione in modo da avere una certa garanzia sulla standardizzazione del conteggio • Per creare regole dettagliate, si possono seguire i modelli/diagrammi, in particolare i diagrammi delle classi o ER o DFD (relativamente a data store e data flow) contenuti in un documento dei requisiti – o costituenti un modello analitico – o, approssimativamente, già in una fattibilità

18. Regole: EI, EO, EQ Permette di mantenere aggiornato un ILF o non fa qualcosa fatto da altri EI Crea dati derivati o esegue un calcolo, o mantiene un ILF o non fa qualcosa fatto da altri EO, manda dati verso l’esterno Non crea dati derivati e non mantiene ILFs, manda dati verso l’esterno

19. DET per ogni EI e Function Points FTR (File Type Referenced) sta per ILF e EIF (in prima approssimazione)

20. DET per ogni EO/EQ e Function Points

21. C: calcola E: elabora M: modifica A: aggiunge P: presenta processi elementari DFD ed EI, EO, EQ EO EI U U a=…. a=…. C,M, A,E A, M,E ILFs DET ILFs U: utente EQ U a=…. P

22. (UFP) Tabella per il calcolo dei FPs totali

23. Calcolo dei Function Points totali • Calcolo dei Unadjusted Function Points, UFP • Pari alla somma dei Function Points ottenuti per ogni ILF, EIF, EI, EQ, EO identificati:

24. Calcolo del Fattore di Aggiustamento • E’ necessario tener presente altri tipi di complessità del software da sviluppare. • Il Value Factor Adjustment (VFA) valutato attraverso la somma delle valutazioni di 14Caratteristiche Generali di Sistema (TDI): • VAF=(0,65+TDI*0,01) ove • TDIè il Total Degree of Influence compreso tra 0 e 70 (per avere un +/- 35% di UFP) • Esistono varie categorie di calcolo a seconda che si tratta un progetto di manutenzione o nuova applicazione e sviluppo • Nel caso dello sviluppo di un’applicazione: • FP=VAF*(UFP+CFP) ove CFP sono i Function Points generati da funzioni di trasformazione di dati preesistenti

25. Caratteristiche Generali di Sistema In Pressman – pag 480 – le caratteristiche generali sono espressi ed ordinati in modo diverso

26. Esempio per la Valutazione TDI

27. BackFiring: da FP a LOC (mai vice-versa!) Uso della tabella: uso Java, per software con 1000 FPs, allora il backfiring suggerisce 1000 * 30 = 30000 LOC Questa tabella riporta solo la media di LOC; è possibile considerare un max, min e medio numero di LOC (come nel Pressman)

28. Vantaggi dei Function Points • Legati alla complessità concettuale del software da sviluppare non alla quantità di codice prevista • Possibilità di confrontare diversi software relativi ad uno stesso dominio applicativo (es. Gestione del Personale) • Possibilità di essere trasformati in LOC (backfiring); quindi possono essere applicati i modelli di costo basati su LOC • Gruppo Internazionale Utenti dei Function Points che fornisce anche un certificato di valutatore di FPs • Usati effettivamente nelle gare d’appalto

29. Vantaggi dei Function Points • Possibile ridefinire alcune grandezze per le stime in funzione di FPs • Produttività L in termini di FPs e non i termini di LOC: L=FPs/E • Costo per singolo FPs e non per LOC (CostperLoc e CostperFP)

30. Svantaggi dei FPs • Il calcolo non è semplice e deve essere fatto da esperti e con strumenti adeguati • Principalmente applicati in software di tipo gestionale ove la parte dati e funzioni è sufficiente per descrive i requisiti del software e il software; esiste poca esperienza con software ove il parallelismo e i vincoli temporali sono importanti

31. Esempi di altri usi dei FPs • Stabilità dei requisiti • Modifiche per Totale di FPs • Completezza del software sviluppato • Numero di FPs dai requisiti e numero di FPs del software sviluppato • Completezza della documentazione • Pagine di documenti per numero di FPs del software sviluppato • Patrimonio di un’organizzazione • Numero di FPs totali (soprattutto per l’outsourcing) • Previsione di difetti • Difetti per FPs

32. Sintesi dei Punti Chiave Vincolo: ad un certo punto più persone non produrranno più linee di codice! Milestone:Conteggio FPs,Stime ETRC, Piani di Progetto Controllo continuo del cammino critico Progetto di Sviluppo seguendo un Processo Requisiti Progettazione Codifica Test Milestone:Stime ETRC necessari per completare il progetto, Eventuale Ri-Pianificazione e Ri-programmazione del progetto Stime ETRC Piani Preliminari Milestones: Valutazione dei FPs realizzati, Eventuale Ri-Pianificazione e Ri-programmazione del progetto Stime ETRC Piani Strategici Preliminari

33. Sintesi dei Punti Chiave • Le stime che sono state viste non possono essere usate per stimare la durata, sforzo, personale e costo per tutti i tasks, poiché si tratta di stime globali ovvero suddivise per attività predefinite (es.COCOMO) • Tuttavia, è possibile usare stime globali per vincolare (al di sotto e al di sopra) le durate associate ai task di dettaglio

34. Sintesi dei Punti Chiave Stima ottenuta con COCOMO:100 PM & 30 Mesi Se i Tasks associati ai tre moduli sono svolti in parallelo, il massimo tempo di progettazione, codifica e test di uno dei modulo non può eccedere 30 Mesi

35. Punto Mancante • Quanto “durano”/”costano” i requisiti? • A parte casi particolari, si ottengono dei vincoli per differenza, cui si aggiunge un piano preliminare per valutare la compatibilità con tali vincoli: • CostoTotale=CostoReq+CostProg cioè • CostReq=CostTotale-CostoProg e • TempoReq=TempoTotale-TempoProg

36. Conclusione • Manutenzione • Deployment (Installazione, configurazione etc. nel e dell’ambiente del committente) • Gestione della configurazione • Gestione del rischio • Gestione della qualità – compresa la verifica e la validazione - • Gestione del processo (process improvement) • Gestione del riuso e COTS • Trattamento dei Legacy Systems • ……