GUFPI-ISMA Evoluzione delle Linee Guida: l’utilizzo contrattuale dei Function Points

Roma, 10 maggio 2006 Linee guida sulla Qualità delle

Forniture ICT: evoluzione ed applicazione

GUFPI-ISMA

Evoluzione delle Linee Guida: l’utilizzo contrattuale dei Function Points

Roberto MeliCoordinatore Consiglio Direttivo GUFPI-ISMA

Roma, 10 maggio 2006 Linee guida sulla Qualità delle Forniture ICT: evoluzione ed

applicazione

2


applicazione

3

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

Perché era necessario intervenire ?


applicazione

4

• 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


applicazione

5

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


applicazione

6

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


applicazione

7

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


applicazione

8

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”


applicazione

9

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.


applicazione

10

FP: Modello di riferimento

Dominio utente (umani + sistemi)

ILF

EI

ILF

EO

EQEIF


applicazione

11

FP: Procedura per il Conteggio

Calc. FP Pesati

Determ. Tipo di

Conteggio

Identificare Ambito del Conteggio e Confine dell’ Applicazione

Contare Funzioni

tipo Transaz.

Contare Funzioni

tipoDati Determ. FP

Non Pesati

Determinare Valore Fattore Aggiustamento


applicazione

12

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”


applicazione

13

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


applicazione

14

Modelli di produzione e punti di stima/misura funzionale

iterazione

discipline principali

discipline di

supporto

disciplinediscipline

InitialOperationalCapability

milestonemaggiore

LifecycleObjectives

LifecycleArchitecture

ProductRelease

fasi

releasefinale

releasefinale

releasefinale

releasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleasereleaserelease

iterazioni

milestoneminore

I NTEGRATI ON

I NTEGRATI ON


applicazione

15

“Ambito” della fornitura

• Cos’è incluso e cosa è escluso (prodotti/processi) ?

• Quale parte della Work Breakdown Structure (Project Lifecycle Model) è stata o sarà commissionata?


applicazione

16

“Ambito” della fornitura

• Non influenza i FP• Influenza il prezzo unitario


applicazione

17

Classificazione e livello di dettaglio dei requisiti per il software

• misura funzionale (requisiti funzionali)

• misura tecnica (requisiti non funzionali/tecnici)

• misura qualità (requisiti non funzionali/qualità)

SW Application

Macro Functional

Process…

General Functional

Process

General Functional

Process

Base Functional

ProcessBase

Functional Process

Base Functional

ProcessBase

Functional Process

Typical Functional

Process

…

Logical Data Group

Multiple Logical

Data Group

Base Functional

Process

Logical Data Group

Logical Data Group

SW Application

Macro Functional

Process…

General Functional

Process

General Functional

Process

Base Functional

ProcessBase

Functional Process

Base Functional

ProcessBase

Functional Process

Typical Functional

Process

…

Logical Data Group

Multiple Logical

Data Group

Base Functional

Process

Logical Data Group

Logical Data Group


applicazione

18

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)


applicazione

19

Prezzo ridotto = FP x (Prezzo unitario FP x %fasi svolte)

Modalità di valorizzazione degli interventi

interrotti precocemente


applicazione

20

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


applicazione

21

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.


applicazione

22

Modello a misura per accordo quadro

• valorizzazione basata su classi di progetti

• valorizzazione basata su produttoria di fattori correttivi

1111,11,29SCED (Vincoli di pianificazione)

0,720,8611,121,24TOOL (uso di software tools)

Fattori relativi al progetto

1,31,1510,880,75CPLX (Complessità del prodotto)

Fattori tecnici del prodotto

1,131,0610,950,89DOCU (Accuratezza della documentazione)

1,391,1510,880,75RELY (Grado di affidabilità del software)

Fattori di qualità del prodotto

MAANBMB

1111,11,29SCED (Vincoli di pianificazione)

0,720,8611,121,24TOOL (uso di software tools)


1,31,1510,880,75CPLX (Complessità del prodotto)


1,131,0610,950,89DOCU (Accuratezza della documentazione)

1,391,1510,880,75RELY (Grado di affidabilità del software)


MAANBMB

Classe 1 X €/FP

Classe 2 Y €/FPClasse … …..Classe n Z €/FP


applicazione

23

Fattori di impatto sui costi…Alta Capacità degli analisti

Capacità dei programmatoriEsperienza sul

linguaggio/strumentoUtilizzo di strumenti avanzatiUtilizzo di componenti dedicateRiuso tecnico di software

esistente

Modifiche in corso d’opera/Volatilità dei requisiti

ComplessitàDisponibilità di utility parametrizzabili

Classe di fornitura Riuso funzionale di software esistenteReplica di software funzionalmente

identico o simile su piattaforme diverse

Qualità/affidabilità/usabilità richiesta

Media Maturità del processo di sviluppo

Metodi di analisi e progettazione

Disponibilità di utility di OS/piattaforma

Metodi di programmazioneTracciamento dei requisitiFlessibilità del processo

Disponibilità delle risorseDispersione delle risorseQuantità di sedi/utenti/interfacceArchitetturaTipologia di sistemaDocumentazione richie Vincoli di schedulazionesta

Integrazione con altri sistemiInterfacciamento con altri sistemiEsperienza sul sistema

Bassa Capacità del capo-progettoCoesione del gruppo di

progetto

Vincoli sui tempi di elaborazioneVincoli sistemi memorizzazioneCaratteristiche prestazionali

Dimensione della base dati

Bassa Media Alta

Misurabilità

Rile

vanz

a


applicazione

24

valorizzazione basata su produttoria di fattori correttivi

MB B N A MA


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


CPLX (Complessità del prodotto) 0,75 0,88 1 1,15 1,3


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


applicazione

25

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


applicazione

26

Impatti del riuso…


applicazione

27

La necessità di replicazione…

Stesse funzionalità (EI,EO,EQ, ILF,EIF)Differenti architetture


applicazione

28

La Misura Funzionale Contrattuale (MFC)

MFC = FPrilasciati - FPriusati + FPreplicati


applicazione

29

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

http://www.gufpi-isma.org/

GUFPI-ISMA Evoluzione delle Linee Guida: l’utilizzo contrattuale dei Function Points

Documents

Transcript of GUFPI-ISMA Evoluzione delle Linee Guida: l’utilizzo contrattuale dei Function Points