A partire dal 1968, anno nel quale si tenne la conferenza NATO a Garmisch durante la quale si coniò il termine “Software Engineering”, si sono specializzate via via le varie discipline legate alle diverse fasi del ciclo di vita del software, tra cui l’Analisi & Progettazione (Analysis & Design), il Project Management e altre ancora, tra cui la Misurazione, come recepito più recentemente nel progetto SWEBOK (Software Engineering Body of Knowledge), oggi standard ISO/IEC 19759:2015.
Se tali ‘specializzazioni’ da un lato hanno generato la nascita di molte associazioni di settore approfondendo le rispettive conoscenze, dall’altro non sempre hanno favorito la creazione di ‘ponti’ tra associazioni, lasciando molti domini di conoscenza ‘paralleli’. Ripercorrendo invece in ottica ‘waterfall’ le fasi di un ciclo di vita di un qualsivoglia progetto (non necessariamente software), le fasi di Analisi & Progettazione e Misurazione/Stima hanno molti punti di contatto. Vediamo quali…
GUFPI-ISMA: chi siamo e la collaborazione con IIBA-Italy
Il GUFPI (il Gruppo Utenti Function Point Italia) nasce a Roma nel 1990 per introdurre la Function Point Analysis (FPA) in Italia e diffondere la cultura della misurazione del software organizzando eventi, webinar e white paper originali. Nel 2001 amplia il proprio ambito di intervento alla misurazione del software tout court (non solo FPA…) diventando GUFPI-ISMA (Gruppo Utenti Function Point Italia – Italian Software Metrics Association) e iniziando il proprio posizionamento e collaborazione anche fuori dai confini nazionali con le principali associazioni di misurazione del software (IFPUG, COSMIC, NESMA, FISMA, UKSMA…) e benchmarking (ISBSG).
Nel 2013 inizia poi una serie di collaborazioni con una serie di associazioni Italiane tra cui IIBA-Italy, PMI Italy Chapters, AICQ, itSMF Italia ed altre ancora. Da 10 anni le nostre associazioni si promuovono a vicenda, ospitano speaker di un’associazione agli eventi dell’altra (come anche nell’ultimo BAWI 2022) e possono creare nuovi contenuti di comune interesse. Il terreno di collaborazione è quindi rendere misurabili i requisiti utente e migliorare i processi relativi alla Business Analysis. Questo blog è un ulteriore strumento di collaborazione, dove esperienza dal mondo del Software Measurement e riflessioni sulla Business Analysis trovano un spazio comune d’espressione.
L’iceberg dei requisiti e il ‘cono dell’incertezza’
Come diceva Tom Demarco, ‘You cannot control what you cannot measure’, ma facendo un passo indietro è vero che ‘you cannot measure what you cannot define’ e con un ultimo passo indietro infine si può affermare che ‘you cannot define what you don’t know’…Quindi il problema (e la relativa soluzione) per gestire un buon processo di stima in un progetto risiede in una corretta elicitazione e definizione dei requisiti utente partendo dalla definizione degli attori (stakeholder) in gioco ed evitando di incagliarsi nell’iceberg dei requisiti, come indicato in Figura 1 e che comporta un RE (relative error) sempre più ridotto al ridursi dei requisiti ambigui/non granulari ed impliciti, con una riduzione di pari passo del c.d. ‘cono dell’incertezza’.
Come classificare requisiti?
Lo “schema ABC”
Una tassonomia per classificare i requisiti, creata nel 2012, è il c.d. ‘schema ABC’ che, come indicato in figura, prevede di distinguere i requisiti in tre tipologie: A (requisiti funzionali di prodotto – FUR: Functional User Requirements), B (requisiti non-funzionali di prodotto – NFR: Non-Functional Requirements), C (requisiti e vincoli organizzativi/di progetto).
Ciascuno dei tre stream usa unità di misura appropriate per determinare le quantità (Q) che permettono – attraverso i rispettivi livelli di produttività (p) – di determinare/affinare le stime relative ai tempi di lavoro (T) – declinabili in Effort (E) e Duration (D) – e che a loro volto permettono di determinare i costi e corrispettivi economici (C).
I Function Point (FP) sono l’unità di misura generalmente utilizzata nei progetti software per i requisiti di tipo A (FUR di prodotto), mentre ci sono diversi possibili metodi e standard da poter considerare per le unità di misura non-funzionali (IFPUG SNAP e ISO/IEC 25010 per la qualità del prodotto software, ISO/IEC 25012 per la qualità dei dati, …) per quantificare i requisiti di tipo B (NFR di prodotto).
Infine per i requisiti di tipo C non esiste al momento una unità di misura ‘standard’, ma si procede in genere ad una stima diretta ad effort (gg/p). Pertanto, lo scope di un progetto deve considerare tutti e tre gli ambiti e la somma degli effort e costi/corrispettivi. Semplice e logico come dire… ABC!
La tassonomia del BABOK v3 e il mapping con lo schema ABC
Il BABOK v3 propone nella sezione 2.3 un differente schema di classificazione dei requisiti e la Figura 3 prova a creare un mapping tra i due modelli:
Iniziare a verificare queste corrispondenze in modo bi-fronte può aiutare entrambe le comunità con degli spunti di miglioramento partendo da una prospettiva diversa da quella di origine…insomma, l’unione fa la forza, come si suole dire!
Un’applicazione legata al Testing può essere ad esempio quella indicata in Figura 4, laddove la seconda matrice di tracciabilità (Specifiche vs Test Cases – TC) può beneficiare dalla classificazione dei requisiti (in questo caso quella ‘ABC’) per verificare i livelli di copertura in un piano dei test per un miglioramento continuativo partendo da eventuali scoperture tematiche:
Lo “schema 123”: un prodotto non è un servizio (e viceversa…)
La classificazione dei requisiti, preziosa nel Measurement quanto nella Business Analysis, però non deve essere fine a sé stessa, ma calata nel contesto delle tre principali macro-fasi di un progetto di servizio (non esclusivamente di sviluppo di un prodotto).
Lo “schema 123”, come indicato in Figura 5, evidenzia infatti (1) lo sviluppo; (2) l’esercizio; (3) la manutenzione del servizio (anche tramite i suoi prodotti/outcome). Nella figura sono anche inserite le tre tipologie di requisiti ABC al fine di indicare in ogni momento quali siano presenti i requisiti coinvolti (e le relative figure professionali) al fine di effettuare le opportune stime.
Come si può notare, i Function Point (FP) – derivati da requisiti funzionali utente (FUR), ovverosia quelli di tipo A – non sono presenti né nella fase di erogazione/esercizio, né in quella di manutenzione correttiva, poiché non c’è alcun cambio di FUR in quei momenti temporali, diversamente dai requisiti di tipo B/C.
Ciò permette ad un team di modulare in modo opportuno i carichi di lavoro e le stime di tempi/costi in ogni macro-fase temporale di un progetto, non ragionando necessariamente sempre e solo su ipotesi di valori ‘medi’ di produttività, costi e marginalità.
Ruoli vs Skills: UNI 11621-2 e 11621-6, punti di contatto, uniti verso eCF!
‘Last but not least’, il tema delle competenze diventa sempre più importante perché il paradigma Agile/DevOps chiede figure professionali possibilmente a forma di “T”, ovverosia “T-shaped”, come indicato in Figura 6, o di una delle sue varianti.
Nell’ambito delle c.d. ‘professioni non regolamentate’, dopo l’emissione della norma UNI 11621-2 (che include i Business Analyst), recentemente GUFPI-ISMA ha contribuito alla creazione dello standard UNI 11621-6 relativo alle competenze di uno ‘specialista di misurazione’.
Questa norma sottolinea la necessità di collassare le competenze e conoscenze tipiche di un analista/misuratore/statistico in una sola figura professionale, evidenziando quanto le nostre due associazioni possano fare insieme nei prossimi anni. Nasce la figura di Business Analysis & Measurement specialist.
In particolare si potrà contribuire insieme alle future evoluzioni di eCF (European Competence Framework) e all’inclusione di profili compositi nei capitolati e nei bandi di gara, pubblici e privati, a vantaggio di tutti gli stakeholder coinvolti.
Alcune conclusioni…
La Business Analysis (BA) e la Misurazione (Measurement) sono aree di conoscenza ed expertise complementari. Un misuratore deve dimensionare un requisito, ma la gestione di un requisito – senza una dimensione – ha difficoltà a contribuire al processo di stima di tempi e costi verso un PM/PMO e la classificazione dei requisiti è importante per produrre pianificazioni e stime sempre più corrette.
Il BABOK e lo schema ABC propongono classificazioni diverse ma entrambe valide ed integrabili: l’obiettivo è quello di ricercare una sempre migliore copertura dell’ambito (scope) del progetto, evitando pertanto fin dall’inizio il c.d. «scope creep».
eCF richiede nuove e-competence per i prossimi anni e le norme UNI 11621-x a livello italiano rappresentano il giusto punto di partenza per perseguire tale obiettivo per i contratti pubblici e privati.
E la collaborazione tra IIBA-Italia (Business Analysis) e GUFPI-ISMA (Measurement), potrà essere foriera di ottimi contributi.