Collegamento: http://metriche-per-il-software-pa.readthedocs.io/it/latest/documento-in-consultazione/applicazioni-operative-ed-esempi.html
Contenuto:
6 Applicazioni operative ed esempi
6.1 Considerazioni generali
6.2 Assessment di parchi applicativi già esistenti
6.3 Sviluppo di nuove applicazioni
6.4 Evoluzione di applicazioni esistenti
6.5 Manutenzione
il punto 6.2 non riporta, differentemente con quanto scritto al 4.2, il vantaggio dell’applicazione del metodo SiFP nel caso di misurazioni patrimoniali e non cita le tecniche di misura approssimata che sono ormai affermate anche nell’uso delle P.A. e previste espressamente in molti contratti. suggerimento di sostituzione testo:
"Come seconda soluzione, applicabile a casi ove la documentazione sia di livello sufficiente alle necessità di un conteggio formale secondo una delle metodiche di misura indicate precedentemente, si potrebbe misurare in PF la dimensione funzionale delle applicazioni che costituiscono il portafoglio e integrare tale conteggio con SNAP (metodo che, come detto, tiene conto di alcune delle caratteristiche non funzionali di un’applicazione). In questo caso la dimensione complessiva del portafoglio applicativo si ricondurrebbe a due numeri, rispettivamente:
la somma dei PF delle singole applicazioni costituenti il portafoglio;
la somma degli SP (SNAP Point) delle singole applicazioni costituenti il portafoglio.
Il metodo SNAP consente infatti di sommare tra loro i punti ottenuti sui diversi elementi previsti dal metodo, correlati alle caratteristiche non funzionali. Ciò può costituire un vantaggio ove obiettivo dell’assessment sia appunto ottenere una valutazione unica e complessiva del portafoglio applicativo. Viceversa, se l’amministrazione ritiene rilevanti solo alcune delle caratteristiche non funzionali (ad esempio la sola sicurezza, oppure la sicurezza e la manutenibilità), si potrebbe pensare a un uso parziale del metodo, conteggiando solo alcune categorie o sotto-categorie previste da SNAP.
Come scritto al par. 4.2 il metodo di misura Simple Function Point costituisce un buon compromesso tra semplicità di computazione e precisione per valutazioni patrimoniali necessitando dell’individuazione delle sole transazioni e archivi logici dell’applicazione.
+
+Qualora la documentazione di livello logico necessaria ad applicare un metodo di misura funzionale standard non sia disponibile, è possibile adottare una tecnica di misura approssimata che fornisce risposte appropriate quando la precisione del risultato è meno importante della tempestività ma si desidera successivamente iniziare un percorso di mantenimento delle misure dal punto di vista logico e con coperture crescenti mano a mano che gli interventi di evoluzione del patrimonio si succedono. Il vantaggio è di derivare una rappresentazione, pur grossolana, dell’applicazione da un punto di vista “business” e non “guidato” dalla implementazione tecnica.
+
+Anche questa soluzione, tuttavia, risente delle medesime incertezze della precedente riguardo alla monetizzazione finale della misura per la parte non funzionale, in quanto non sono a oggi disponibili riferimenti condivisi su un “valore di mercato” dello SNAP Point.
Nel paragrafo 4.2 “Misure funzionali” sarebbe opportuno precisare con maggiore incisività quali metriche usare per la stima di progetti a valle di fasi inziali, come lo Studio di Fattibilità o Requisiti utente.
In tali casi è impossibile utilizzare IFPUG a meno di non spingersi a livelli elevati di dettaglio (cosa impossibile)
Il metodo IFPUG è validamente applicabile anche per stime in fasi alte del ciclo di vita di un progetto di sviluppo e/o di manutenzione evolutiva, utilizzando - come normale - assunzioni sulle fasce di DET/RET/FTR in esame, recuperate dall’ultima baseline di ciascun sistema in esame (pertanto dalla storia del sistema).
Le più recenti indicazioni dalla comunità IFPUG indicano che la complessità dei processi elementari (EP) è alta/medio-alta, non medio-bassa, dovendo considerare quasi sempre un numero di FTR maggiore di 3 per sistemi profilati (“sicurezza funzionale”).
Indicazioni di un sistema/valori di pesi diversi porta ad un sotto-dimensionamento dell’applicazione, con valori di produttività nominale più bassi (e quindi un numero maggiore di gg/p) di quanto sarebbe ragionevole pensare per la pianificazione delle attività.
Altresì è fondamentale continuare a mantenere la distinzione tra tipologie di processi elementari (EI, EO, EQ) e non massificarli al fine di poter determinare un c.d. “profilo funzionale” (cfr. https://goo.gl/DaLkq4), in modo da poter classificare tipologie di progetti con caratteristiche analoghe (es: progetti con prevalenza di EO/EQ e EIF rappresentano sistemi di presentazione delle info, invece una prevalenza di EI/ILF individua sistemi di tipo gestionali e via dicendo…).
E’ quello che nella norma ISO/IEC 14143-5:2004 è stato definito un “dominio funzionale” (attualmente nei capitolati CONSIP sono di norma presenti solo tre tipologie, che però potrebbero essere estese, osservando i criteri contenuti nella tecnica CHAR, in appendice A della norma citata). Non avrebbe alcun valore comparare un sistema DWH con uno di tipo web solo perché potrebbero avere una dimensione funzionale simile…e tali analisi possono facilmente emergere dai dati raccolti negli anni a costo però di mantenere il dettaglio del tipo di EP/LF sin dal conteggio, non semplificandone il censimento. Una volta perso il dettaglio, ogni analisi diventerebbe pressoché impossibile nel tempo.
Non serve pertanto a nostro avviso alcuna altra tecnica se non lo standard IFPUG FPA stesso, senza alcuna variante, ma con un diverso e più attento uso (approssimazione nelle fasi alte, conteggio al momento della definizione di maggior dettaglio dei FUR), come anche indicato nei “Principi, Assunzioni e Best Practice Contrattuali” GUFPI-ISMA.