LA MISURA DEL SOFTWARE
s
GUFPI-ISMA Luigi Buglione
Metrologia e Contratti Parte 3: Ambiti, confini applicativi e strati/partizioni
METROLOGY AND CONTRACTS - PART 3: SCOPES, APPLICATION BOUNDARIES AND LAYERS/PARTITIONS Third paper based on the new GUFPI-ISMA guidelines on the proper use of “Principles, Assumptions and Contractual Best Practices” (vol. 1, 2016), it deals with measurement scopes, in particular of the definition of the application boundaries for a software product, analysing how layers and partitions are currently managed and how most known best practices suggest they could/should be governed. RIASSUNTO Terzo articolo basato sulle nuove linee guida GUFPI-ISMA sul corretto uso di “Principi, Assunzioni e Best Practice Contrattuali” (vol. 1, 2016), tratta il tema degli ambiti di misurazione, in particolare della definizione dei confini applicativi di un’applicazione software, analizzando come attualmente sono trattati strati e partizioni e di come le best practice suggeriscono potrebbero/dovrebbero essere gestiti. INTRODUZIONE
Terzo appuntamento con la disamina dell’applicazione di buoni principi di misurazione ai contratti (ICT e non) [2] parlando questa volta degli ambiti di misurazione e dei relativi “confini applicativi” di un software, altro capitolo delle nuove “linee guida contrattuali” GUFPI-ISMA [1]. Può apparire banale, ma la definizione dello scope rappresenta il primo passo indispensabile per misurare. Si tratta quindi di definire l’ambito di misurazione da considerare, in funzione del punto di vista di uno stakeholder, nelle tecniche FSM, dello user, che può essere sia un umano sia un sistema; es: due sistemi IT che dialogano tra di loro per inviare e ricevere dati o ancora, oggi in ambito IoT – Internet of Things – due periferiche/ elettrodomestici che scambiano informazioni per un acquisto online o un’informazione sullo stato degli asset oggetto di quel servizio IT. Se non fosse propriamente definito il “perimetro” di ciò che va stimato prima e misurato poi, come poter aver certezza che le parti discuteranno su una
corretta quantità compravenduta al termine di un progetto? Essendo un semplice passaggio logico (divide-et-impera... prima definisci il perimetro, poi misura), lo scope management è uno dei primi gruppi di processo definiti sia nel mondo del Project Management (es: nel PMBOK [3]) sia nelle guide di misurazione, come ad esempio la IFPUG FPA o COSMIC FSM, ma più in generale in tutte le guide per metodi FSM [4]. Nel mondo FSM (Functional Size Measurement), Albrecht propose la FPA nel 1979 quando ancora l’informatica era basata su mainframe, e non era ancora uscito il primo PC o il primo mini-computer: quindi le architetture IT erano alquanto “semplici” rispetto a oggi, così come le conoscenze d’ingegneria del Software e le formulazioni su come gestire un progetto e il suo ciclo di vita (SLC – Software Life Cycle). Pertanto il “progetto” software corrispondeva (quasi interamente) al “prodotto” software, essendo il principale artefatto percepibile dall’utente; gli altri work product (es: manualistica utente, patch, ...) erano visti come un “di cui” minimo rispetto al prodotto principale.
DEFINIRE GLI AMBITI E I CONFINI APPLICATIVI
La “deriva” nel mondo delle metriche funzionali è stata pertanto, negli anni ’90, quella di pensare (anche in buona fede) che un Function Point (FP) rappresentasse la misura dell’intero “progetto” software e non solo della parte funzionale del “prodotto” software, laddove il progetto ricomprende molte attività in più non parte di un requisito funzionale utente (FUR – Functional User Requirement), come ad esempio la stessa attività di misurazione, che è un’attività progettuale e non legata direttamente al prodotto. Ad esempio, misurare il prodotto non ne varia le dimensioni, ma restituisce ovviamente un’informazione utile per stime e valutazioni sull’intera attività progettuale. E da qui iniziare a “scimmiottare” le pratiche contrattuali nord-americane nelle quali gli FP “pagavano” l’intero progetto. Peccato che tuttora in altri Paesi la corresponsione di un FP sia dalle sei alle dieci volte più alta di quella riconosciuta in molti contratti italiani, con una non proporzionalità tra “quantità”, “tempi” e “corrispettivi” (va ricordato che il software non è necessariamente l’unico deliverable di un progetto). Dal nostro punto di vista di misuratori l’attenzione è chiaramente puntata al primo dei tre passaggi, la quantità, che per ciascuno degli “ingredienti” (asset) da inserire in un progetto va stimata con il minor tasso di errore possibile. E con la maggiore maturità dell’ICT nel corso degli anni, anche la definizione delle architetture si è raffinata, evoluta e dettagliata, proponendo schemi multilivello (multi-tier); oggigiorno si parla di GUFPI-ISMA - Gruppo Utenti Function Point Italia Italian Software Metrics Association luigi.buglione@gufpi-isma.org
T_M
N.
1/17 ƒ 63