Negli ultimi anni si è chiarito sempre di più, anche grazie a modelli quali ITIL o CMMI-SVC e norme come la famiglia ISO 20000, che un servizio non è un prodotto, ma che lo contiene e lo ingloba, dato che esprime un ‘mezzo per erogare valore’, cioè un vantaggio verso i suoi utilizzatori finali (users). Il valore, altra definizione cardine nel Service Management (SM) è dato dalla somma di cosa rilascia un servizio (i requisiti funzionali utente – FUR) e del come/quanto questo servizio sia ‘usabile’ dal punto di vista degli utenti (NFR – requisiti non-funzionali), rispettivamente denominati utilità e garanzia (figura 1). Vediamo quindi come misurare un asset software.
Cosa e come misurare un asset software?
Tutto è misurabile, basta avere l’attenzione e la capacità di analizzare, come indicato nella tassonomia EAM, tre elementi: cosa si misura (entità), in particolare quale aspetto (attributo/caratteristica) e come, determinando la corretta unità di misura. Ad esempio, i chili (misura) possono esprimere per una persona (entità) il peso (attributo), mentre per un prodotto software (entità) la complessità (attributo) può essere misurata con diverse unità di misura, tra cui il v(G), il c.d. indicatore di complessità ciclomatica di Tom McCabe. Anche gli aspetti soggettivi possono essere misurati (‘soft data’) usando scale nominali od ordinali, ad esempio tramite dei survey.
Ma se non si misura qualcosa, anche se con le dovute approssimazioni, non è possibile rendere oggettivo quel qualcosa. La catena degli elementi che compongono una stima può essere tradotta in tre semplici passaggi:
(UR) –> Q –> T –> C
È necessario pertanto partire da un requisito utente (UR – User Requirement) per determinare la quantità (Q) di lavoro da stimare secondo la/e corretta/e unità di misura per poi capire quale sia il tempo (T) di lavoro necessario, sia in termini assoluti (giorni/persona) che di pianificazione (giorni/calendario) ed infine, a seconda di chi realizza l’attività e con quali mezzi (asset), determinare i relativi Costi (e corrispettivi, nel caso di vendita).
Non misurare le quantità per gli ‘ingredienti’ di un progetto pone in evidenza alcuni punti da esaminare con attenzione:
- Senza una ‘quantità’, ma stimando sempre in modo esperienziale il solo tempo di lavoro non è possibile conoscere quanto siamo produttivi. Q/T è la formula generale da applicare, ma se mancasse il valore per popolare il numeratore della formula, non si può sfruttare la storicizzazione di tale dato per rafforzare le stime future, semplicemente invertendo le variabili della formula in T*=Q/p. E la mancanza di dati storici rischia solo di non permettere il conseguimento di minori sprechi (wastes) di ingredienti, ovverosia di ‘asset’ da impiegare.
- Non conoscendo con esattezza di quanti ingredienti un progetto debba poter disporre, non sarebbe possibile determinarne né la ‘capacità’ ideale da soddisfare per erogare un servizio secondo i livelli richiesti da un cliente/utente né se una organizzazione già ne disponga in proprio o debba ottenerli dall’esterno (outsourcing/procurement). Insomma, non sarebbe possibile avere un sistema di gestione dei propri asset (asset management) che rappresenta uno dei pilastri per la sostenibilità e la buona gestione di una qualsivoglia organizzazione, sia pubblica che privata.
Quali asset sono valutabili?
Nel mondo ICT pertanto di asset ce ne sono di vario genere da poter censire: hardware, software, persone, logistica e via dicendo. Contabilmente parlando, un asset rilascia pertanto un ‘valore’ per più esercizi/anni e ciò va misurato e rappresentato in due documenti-base della contabilità aziendale: il Conto Economico (il vecchio ‘Profitti & Perdite’) e il Bilancio di Esercizio (‘Stato Patrimoniale’), rispettivamente espressione economica e finanziaria di un’organizzazione. I costi/ricavi si riferiscono a un singolo esercizio/periodo, ma quando rilasciano un valore per più periodi vanno ‘ammortizzati’, partendo da una determinazione quantitativa da porre nel Bilancio, lato Attività.
Ovviamente i criteri e unità di misura vanno considerate per inserire un asset nell’attivo di un bilancio variano in funzione del tipo di ‘bene’, ma ci si riferisce sempre alla ‘A’ della tassonomia EAM. Analizzando le caratteristiche misurabili, sia legate agli aspetti funzionali che non-funzionali, è possibile determinare – partendo dalla quantificazione di quel dato asset – anche un suo valore economico. Si pensi alla valutazione del cartellino di uno sportivo o di un immobile o del c.d. ‘capitale umano’ nel caso di cessione di ramo d’azienda. A pensarci bene, non sono così strettamente oggettivi ma comportano l’inclusione anche di elementi intanbigili, di percezione, che possono in ogni caso trovare nella determinazione quantitativa che rende il ‘valore’ di un’organizzazione più alto ed appetibili, rappresentando un elemento di proprietà, insomma…un asset!
Quando si tratta di valutare un software non cambia nulla: è un prodotto che rappresenta un elemento di un ‘service offering’ e che deve essere valutato secondo criteri che siano espressione sia dei FUR che dei NFR. Per il primo gruppo, i Function Points (esistono 5 metodologie riconosciute tra quali standard dall’ISO, tra le quali IFPUG e COSMIC) sono da 40 anni delle unità di misura di riferimento. Non esiste un costo/corrispettivo ‘standard’, ma va contestualizzato e determinato in base al tipo di software (‘dominio funzionale’, come descritto nello standard ISO/IEC 14143-5:2004) e al contesto d’uso (un pacchetto software non può avere la stessa valutazione di un progetto sviluppato ad-hoc). Per la seconda parte, quella dei NFR, ci sono molti aspetti da considerare e le due soluzioni più mature, suggerite anche da AGID in un recente documento del 2018 sono la tecnica IFPUG SNAP (Software Non-functional Assessment Process) e il set di misure contenute nello standard ISO/IEC 25023, relative al modello di qualità dei prodotti software definito nello standard ISO/IEC 25010:2011, già inclusa in molti bandi e capitolati.
Lo schema ABC per determinare un corretto ‘scope’ progettuale
Come indicato con lo schema ABC, le parti di un progetto dimensionabili sono tre: requisiti di prodotto funzionali (parte A, quotabili in FP) e non funzionali (B, quotabili con gli SP o le misure ISO 25023), più i requisiti per le attività di progetto (parte C, per le quali non esiste ancora una unità di misura standard) (figura 2).
Negli anni si parla di ‘baseline’ in FP per indicare la quantificazione e dimensionamento funzionale di un asset software (prodotto) che può quindi essere inserito per il suo valore economico complessivo nell’attivo patrimoniale, ed ammortizzato per un congruo numero di esercizi, in linea con i principi contabili.
Ma un software non è solo funzionalità…non dimensionare (almeno) i NFR corrisponde a sotto-valutare il valore patrimoniale di quell’asset software. Il tempo/costo relativo ai NFR di un software è e rimarrebbe solo un costo d’esercizio nel conto economico di un’organizzazione, mentre dovrebbe correttamente rappresentare il lato ‘B’ anche a livello di bilancio d’esercizio.
Non quotare i NFR rappresenta altresì un ulteriore punto negativo, come quando prima del 1979 non si parlava di FP. Come stimare meglio una manutenzione correttiva o perfettiva, ovverosia progetti senza movimentazione di FUR, e quindi a ‘zero FP’ se se si continuasse a non voler misurare i NFR con la/e opportuna/e unità di misura?
Per concludere, “il tempo è denaro” ma se non conoscessimo ‘quanto’ produrre in quanto tempo da almeno due prospettive (funzionale e non-funzionale) come potremo conoscere il ‘vero’ valore di un asset software?
GUFPI-ISMA ha ridefinito nel 2016 le proprie Linee Guida con un primo volume relativo ai GUFPI-ISMA (PABCP) con i principali aspetti da poter osservare anche per auto-valutazioni dei propri contratti a cui seguirà a breve un secondo volume con indicazioni operative sui singoli lemmi discussi. Interessati a saperne di più? Seguite i nostri prossimi contributi su ZeroUnoWeb e visitate il nostro sito web di GUFPI-ISMA per ulteriori spunti ed approfondimenti!
