GUFPI-ISMA Evoluzione delle Linee Guida: l utilizzo contrattuale dei Function Points Roberto Meli Coordinatore Consiglio Direttivo GUFPI-ISMA
2
Perché era necessario intervenire? I contratti per il software ad hoc sono difficili da gestire Si acquistano spesso prodotti molto diversi tra loro usando, però, lo stesso parametro di costo per FP (ad es. un applicazione di 250 FP per la stampa di etichette allo stesso costo di una complessa applicazione statistica di 250 FP) Le valutazioni di congruità di un contratto sono spesso svolte in maniera limitata usando un solo o pochi parametri di confronto I meccanismi rigidi di pricing utilizzati finora hanno indotto spesso pratiche illecite come il backfiring dai costi 3
Si acquistano pagine HTML (o addirittura animazioni grafiche) utilizzando il concetto di FP equivalenti Sono usate unità di misura di prodotto software per misurare entità diverse (hardware, servizi etc.) Si confondono spesso variabili di input del processo produttivo con variabili di output (ad es. si misura il prodotto software usando le unità tempo-persona) I cambiamenti di requisiti in corso d opera sono fonte di conflittualità permanente nell esecuzione contrattuale I contratti quadro di grande rilevanza generano continui micro-contenziosi risolti (nella maggior parte dei casi) con negoziazioni extra contrattuali 4
Un dato di fatto! La disciplina e la pratica contrattualistica per il software non è così matura come in altri settori industriali. Assenza della cultura della misura per il software Esperti legali Acquisitori Software manager Commerciali Amministrativi 5
Iniziativa LGC-FP Più di 40 esperti Più di 30 organizzazioni Stretta collaborazione con CNIPA Fine2005 Inizio 2006 Obiettivi: LGC-FP GUFPI-ISMA Semilavorati per LG CNIPA 6
Ma cosa sono i Function Points? Un modo per Misurare le funzionalità che l utente richiede e riceve Misurare lo sviluppo e la manutenzione del software indipendentemente dalla tecnologia utilizzata 7
Functional Size Measurement FSM ISO/IEC/JTC1/SC7 Standard #14143 Dimensione funzionale: la dimensione del software ottenuta quantificando I requisiti utente funzionali Requisiti utente funzionali l insieme dei requisiti che rappresentano le procedure e le consuetudini dell utente che il software deve effettuare per soddisfare I bisogni dell utente stesso. Sono esclusi i requisiti di qualità e ogni requisito tecnico Utente ogni persona, dispositivo fisico, componente software, ecc. che interagisce con il software oggetto di misura 8
Requisiti Utente Requisiti Utente Funzionali Sono un insieme dei Requisiti Utente che rappresentano le procedure e le consuetudini dell utente che il software deve effettuare per soddisfare i bisogni dell utente stesso. Requisiti di Qualità Ogni requisito correlato alla qualità del software così come definito nella norma ISO 9126:1991. Requisiti Tecnici I requisiti sono correlati alla tecnologia e agli ambienti, per lo sviluppo, la manutenzione, il supporto e l esecuzione del software. 9
FP: Modello di riferimento EQ EIF ILF ILF EI EO Dominio utente (umani + sistemi) 10
FP: Procedura per il Conteggio Determ. Tipo di Conteggio Identificare Ambito del Conteggio e Confine dell Applicazione Contare Funzioni tipo Dati Contare Funzioni tipo Transaz. Determ. FP Non Pesati DeterminareValoreFattore Aggiustamento Calc. FP Pesati 11
Quali elementi considerare in un contratto SW? Classe di fornitura Modelli di produzione e punti di stima/misura funzionale Ambito della fornitura Classificazione e livello di dettaglio dei requisiti per il software Varianti in corso d opera nei requisiti per il software Modalità di valorizzazione degli interventi interrotti precocemente Fattori d impatto sul prezzo di scambio Schemi contrattuali base 12
Classi di fornitura impattate SSW Sviluppo e MEV di software ad hoc (Custom) PSW Personalizzazione e riuso di prodotti esistenti Sviluppo e personalizzazione del Software Manutenzione evolutiva funzionale Manutenzione evolutiva non funzionale (anche detta Manutenzione migliorativa) Manutenzione correttiva Manutenzione adeguativa o adattativa Si introduce il concetto di manutenzione ordinaria e straordinaria in funzione delle dimensioni stimate dell intervento 13
Modelli di produzione e punti di stima/misura funzionale INTEGRATION INTEGRATION discipline iterazione fasi milestone minore discipline principali milestone maggiore discipline di supporto Lifecycle Objectives Lifecycle Architecture Initial Operational Capability Product Release iterazioni release release release release release release release release finale 14
Ambito della fornitura Cos è incluso e cosa è escluso (prodotti/processi)? Quale parte della Work Breakdown Structure (Project Lifecycle Model) è stata o sarà commissionata? 15
Ambito della fornitura Non influenza i FP Influenza il prezzo unitario 16
Classificazione e livello di dettaglio dei requisiti per il software SW Application misura funzionale (requisiti funzionali) misura tecnica (requisiti non funzionali/tecnici) misura qualità (requisiti non funzionali/qualità) Typical Functional Typical Functional General Functional General Functional Macro Functional Base Functional Base Functional Macro Functional General Functional General Functional Base Functional Base Functional Base Functional SW Application Base Functional Multiple Logical Data Group Multiple Logical Data Group Logical Data Group Logical Data Group Logical Data Group Logical Data Group Logical Data Group Base Functional Base Functional Logical Data Group Base Functional Base Functional 17
Varianti in corso d opera nei requisiti per il software possiamo valutare in FP ogni Change Request come se fosse un intervento di manutenzione evolutiva, correggendo, però, le misurazioni con alcuni fattori di aggiustamento che tengano conto del livello di riuso applicabile e/o dello spreco di impegno dovuto ai requisiti cambiati o abbandonati. Tali fattori sono stati denominati rispettivamente come CLi (Change Level) e LCPi (Life Cycle Progress) 18
Modalità di valorizzazione degli interventi interrotti precocemente Prezzo ridotto = FP x (Prezzo unitario FP x %fasi svolte) 19
Schemi contrattuali base M1.Modello a misura con prezzo in funzione delle risorse impiegate (lavoro, strumenti, materiali) M2.Modello a misura con prezzo in funzione del prodotto rilasciato e delle sue caratteristiche M3.Modello a corpo per prodotto specificato Essendo il nostro focus incentrato sulla misura funzionale di supporto alla contrattualistica, tralasceremo di approfondire la prima categoria, legata al consumo di risorse, e ci concentreremo solo sulla seconda e terza categoria. 20
Principi per il contratto quadro La misura funzionale è il driver di costo primario Livello di riuso e necessità di replicazione impattano la misura funzionale stessa La competizione può avvenire sul costo medio per FP Durante l esecuzione del contratto la miscela di attività può cambiare rispetto alle aspettative senza che questo impatti sulla correttezza dell assegnazione avvenuta in gara. 21
Modello a misura per accordo quadro Classe 1 X /FP Classe 2 Y /FP valorizzazione basata su classi di progetti valorizzazione basata su produttoria di fattori correttivi Fattori di qualità del prodotto RELY (Grado di affidabilità del software) MB 0,75 B 0,88 Classe Classe n N A MA 1 1,15 1,39.. Z /FP DOCU (Accuratezza della documentazione) 0,89 0,95 1 1,06 1,13 Fattori tecnici del prodotto CPLX (Complessità del prodotto) 0,75 0,88 1 1,15 1,3 Fattori relativi al progetto TOOL (uso di software tools) 1,24 1,12 1 0,86 0,72 SCED (Vincoli di pianificazione) 1,29 1,1 1 1 1 22
Fattori di impatto sui costi Alta Capacità degli analisti Capacità dei programmatori Esperienza sul linguaggio/strumento Utilizzo di strumenti avanzati Utilizzo di componenti dedicate Riuso tecnico di software esistente Modifiche in corso d opera/volatilità dei requisiti Complessità Disponibilità di utility parametrizzabili Classe di fornitura Riuso funzionale di software esistente Replica di software funzionalmente identico o simile su piattaforme diverse Qualità/affidabilità/usabilità richiesta Rilevanza Media Maturità del processo di sviluppo Metodi di analisi e progettazione Disponibilità di utility di OS/piattaforma Metodi di programmazione Tracciamento dei requisiti Flessibilità del processo Disponibilità delle risorse Dispersione delle risorse Quantità di sedi/utenti/interfacce Architettura Tipologia di sistema Documentazione richie Vincoli di schedulazione sta Integrazione con altri sistemi Interfacciamento con altri sistemi Esperienza sul sistema Bassa Capacità del capo-progetto Coesione del gruppo di progetto Vincoli sui tempi di elaborazione Vincoli sistemi memorizzazione Caratteristiche prestazionali Dimensione della base dati Bassa Media Alta Misurabilità 23
valorizzazione basata su produttoria di fattori correttivi MB B N A MA Fattori di qualità del prodotto RELY (Grado di affidabilità del software) 0,75 0,88 1 1,15 1,39 DOCU (Accuratezza della documentazione) 0,89 0,95 1 1,06 1,13 Fattori tecnici del prodotto CPLX (Complessità del prodotto) 0,75 0,88 1 1,15 1,3 Fattori relativi al progetto TOOL (uso di software tools) 1,24 1,12 1 0,86 0,72 SCED (Vincoli di pianificazione) 1,29 1,1 1 1 1 24
Costi non proporzionabili ai FP Non ha alcun senso commerciale e tecnico lo spalmare i costi fissi di progetto o relativi a componenti progettuali non proporzionabili ai FP sul prezzo della componente proporzionale. Ad esempio: il costo di installazione di un applicativo non dipende da quanto è grande in FP ma da quante volte lo si deve fare e in che situazioni logistiche 25
Impatti del riuso 26
La necessità di replicazione Stesse funzionalità (EI,EO,EQ, ILF,EIF) Differenti architetture 27
La Misura Funzionale Contrattuale (MFC) MFC = FPrilasciati - FPriusati + FPreplicati 28
Conclusioni LGC-FP : un supporto al miglioramento delle transazioni commerciali per il software ad hoc Documento nel pubblico dominio: www.gufpi-isma.org Utilizzato per far evolvere le Linee Guida CNIPA Cantiere in continua evoluzione 29