Direttore:
Vicedirettori:
Redazione:
L'unica rivista italiana interamente dedicata alle Misure, alle Prove e ai Controlli Qualità
Anno:

SEGNALATO PER VOI

MISURA DEL SOFTWARE - Quanto è grande un requisito? Parte IV - Misurare i requisiti non-funzionali: IFPUG SNAP

di Luigi Buglione


Presidente di GUFPI-ISMA – Gruppo Utenti Function Point Italia – Italian Software Metrics Association e Direttore IFPUG Conference & Education - luigi.buglione@gufpi-isma.org

 

WHICH IS THE SIZE OF A REQUIREMENT? PART IV – MEASURING NON-FUNCTIONAL REQUIREMENTS: IFPUG SNAP
Quantifying NFRs (Non-Functional Requirements) is the second step to get a better estimate of effort and cost for a project. Not everything can be sized using a FSM method (“what”), but it’s needed also to take a look to the “how” to do things, that’s the NFR-side. This paper will introduce the origin for the IFPUG SNAP (Software Non-functional Assessment Process) technique, born with the aim to complement a FPA (Function Point Analysis) count, but that can be used also independently from FPs, e.g. in “zero FPs” maintenance project.

RIASSUNTO
La quantificazione dei NFR (Non-Functional Requirements) rappresenta il secondo passo per stimare sempre meglio l’impegno e i costi di un’attività progettuale. Non tutto può essere ovviamente dimensionato usando un metodo FSM (“cosa”), ma è necessario anche porre attenzione al “come” realizzare le cose, e ciò rappresenta il lato-NFR. Questo articolo introdurrà l’origine della tecnica IFPUG denominata SNAP (Software Non-functional Assessment Process), creata per complementare un conteggio FPA (Function Point Analysis), ma che è possibile usare anche in modo indipendente, in presenza di progetti di manutenzione a “zero FP”.

 

Nello scorso numero abbiamo introdotto il tema dei requisiti non-funzionali (NFR – Non-Functional Requirements) di un prodotto, relativi al “come” un prodotto (software) debba comportarsi [1], presentando il modello di qualità del software proposto dall’ISO, la norma ISO/IEC 25010:2011 [5]. Tale norma, che aggiorna il precedente standard ISO/IEC 9126-1:2001 [4], propone un modello a tre livelli con (a) caratteristiche, (b) sotto-caratteristiche, ciascuna delle quali propone un set di (c) misure.

Diversamente dal “cosa” (requisiti utente funzionali – FUR), il “come” (NFR) realizzare un prodotto o un servizio è variabile nel tempo e, nel contesto ICT, ciò è reso ancor più variabile in funzione dei cambiamenti legati alle tecnologie di riferimento in un dato periodo. Basti pensare all’introduzione delle GUI (Graphical User Interfaces) negli anni ’90 e quella relativamente recente di smartphone e tablet con touchscreen che propongono una modalità aggiuntiva (tattile) per inserire i dati rispetto alla tradizionale tastiera, o ancora al riconoscimento vocale nelle ricerche effettuate ad esempio con Google o altri motori di ricerca. Altri possibili esempi? Il cloud computing, la Virtual Reality, e via dicendo.
Tali modalità “aggiuntive” rappresentano un lavoro ulteriore per il team di sviluppo: come valutare e decidere quale sia il budget da stanziare e prevedere per il prossimo progetto?
Estendendo il quoting di Tom Demarco sulla necessità di misurare, avevamo già sottolineato la necessità prima di conoscere per definire ciò che è utile/opportuno misurare. La normativa ISO è ovviamente la “stella polare” che aiuta – tramite un consenso mondiale su un dato tema – a fornire la definizione da cui muovere, a cui si è recentemente aggiunto un glossario comune sui NFR prodotto da COSMIC (www.cosmic-sizing.org) e IFPUG (www.ifpug.org), ovverosia le due principali associazioni sulla misurazione del software, con l’obiettivo di raffinare ulteriormente le definizioni già presenti [5]. Il glossario propone tra l’altro una classificazione analoga allo schema “ABC” [5] come osservabile in Fig. 2, che conferma una tripartizione in NFR di prodotto (FUR, NFR) e altri NFR legati al “progetto” che contiene e gestisce il “prodotto”.

 

IFPUG SNAP: COSA NON MISURA UN “FUNCTION POINT”?

Concentriamoci sul secondo blocco da sinistra (Fig. 2), quello dei NFR di prodotto. La soluzione proposta dall’ISO con la famiglia 25000 (c.d. “SQuaRE” – Software product Quality Requirements and Evaluation) è quella d’individuare un set di misure per caratteristica/sotto-caratteristica, collegando ciascuna misura ai processi del modello SPICE (ISO/IEC 15504-2:2004, ora passato a una nuova numerazione, serie 33000). Muovendo da tale tassonomia, IFPUG nel 2007 ha deciso di proporre una seconda unità di misura per i NFR, organizzandola in un set di 4 categorie e 14 sotto-categorie (inizialmente 17) per ciascuna delle quali è possibile calcolare un numero di SP (SNAP Points), in modo simile a quanto visto con i FP (Function Points). Il metodo SNAP (Software Non-functional Assessment Method) ora giunto alla versione 2.3 (maggio 2015) [4] nasce come completamento della tecnica IFPUG di dimensionamento funzionale del software: quello che non è conteggiabile con i FP dovrebbe poterlo essere con gli SP. La figura seguente (Fig. 3) presenta il modello nella versione attuale.

Per ogni categoria è definita una SCU (SNAP Counting Unit), quasi sempre coincidente con i processi elementari (EP – Elementary Process) della tecnica FPA, con alcuni parametri di complessità (Bassa/Media/Alta). Applicando uno dei parametri di complessità (di norma 2 o 3 per ogni sotto-categoria) si determina il livello di complessità dell’attività e, determinando a quanti elementi applicare tale valutazione, si procede poi al calcolo del numero di SP, secondo i casi calcolato o assegnato.
Per ogni NFR è possibile applicare un numero variabile di sotto-categorie, da una a molte (in genere non oltre le 5-6). Un semplice esempio: considerando in un conteggio funzionale un processo di stampa di un biglietto aereo (conteggiato con IFPUG FPA come EO – External Output), questo sicuramente ha verifiche sui campi immessi e stampati (§1.1 – Data Entry Validation), gestione della GUI (§2.1 – User Interface), possibile help-online in termini di content, non di funzionalità (§2.2 – Help), modalità anche in touchscreen (§2.3 – Multiple Input Method), produzione del biglietto in modalità multi-canale (§2.4 – Multiple Output Method), gestione di tabelle di decodifica (§3.2 – Database Changes), e via dicendo.
Alcuni suggerimenti pratici: calcolare e gestire il numero di SP per sotto-categoria e non come totale generale (le scale di misurazione non sono proporzionali tra di loro), considerando le 14 sotto-categorie pertanto come misure indipendenti a cui sommare eventualmente la quindicesima sotto-categoria, rappresentata dalla misura funzionale con i FP.

 

PERCHÈ MISURARE LA QUALITÀ E NON FERMARSI ALLA VALUTAZIONE?

Da un punto di vista di un Asset Manager, quello che non viene misurato non rappresenta un “asset” ammortizzabile per un’organizzazione nell’attivo del proprio bilancio di esercizio. Nel mondo FPA è ormai normale parlare di “baseline” intendendo quella funzionale, ovverosia basata sul numero di FP censito nel tempo, al pari di LOC o di altre unità di misura. Finora però per gli aspetti “qualitativi” il tipico modo di gestire tali attività è stato, nella contrattualistica, di determinare gli effort (in ore o giorni-uomo) da corrispondere tra le parti, ma non di misurare per censire tali “non-funzionalità” in una seconda baseline. Tra i possibili motivi è annoverabile certamente una immaturità del settore ICT nella misurazione degli intangibili e NFR in generale, e ancora i NFR visti erroneamente come “addendum” agli aspetti funzionali e non con una propria “dignità” (p. es.: il VAF nella tecnica FPA come detto in altri articoli era un “aggiustamento” del valore funzionale, quindi subordinato alla funzionalità). Ma, come detto, sono molti i casi di progetti a “zero FP” che vale la pena esplorare ora con nuove tecniche dal lato NFR. Nei prossimi numeri della Rivista proseguiremo l’analisi del metodo IFPUG SNAP, con ulteriori esempi pratici. Al momento SNAP è l’unica tecnica che tenta di codificare una nfsu (non-functional sizing unit) per i requisiti non-funzionali di prodotto, ma può rappresentare uno stimolo per studiare e produrre nuove misure in ambito NFR.

 

“What you can count doesn't count for much. What you cannot count counts for everything." (Albert Einstein)

 

RIFERIMENTI BIBLIOGRAFICI

1. Buglione L., Quanto è grande un requisito? Parte III: Requisiti Non-Funzionali, Tutto Misure, 03/2015, Ottobre 2015, URL: http://goo.gl/TxWra5
2. ISO/IEC, IS 9126-1:2001 - Software engineering - Product quality - Part 1: Quality model
3. ISO/IEC, IS 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models
4. IFPUG, SNAP (Software Non-Functional Assessment Process) APM v2.3, May 2015, URL: www.ifpug.org
5. COSMIC/IFPUG, Glossary of terms for Non-Functional Requirements and Project Requirements used in software project performance measurement, benchmarking and estimating, v1.0, September 2015, URL: www.ifpug.org; www.cosmic-sizing.org
6. Buglione L., Boundary or not Boundary? That’s the (asset) question!, ISBSG IT Confidence 2015 Conference, Florence (Italy), Oct 19 2015, URL: https://goo.gl/U2NWrO

 

L'AUTORE

 

Luigi Buglione è il Presidente di GUFPI-ISMA (Gruppo Utenti Function Point Italia - Italian Software Metrics Association) e Direttore IFPUG Conference & Education. Attualmente lavora in qualità di Process Improvement and Measurement Specialist presso Engineering Ingegneria Informatica SpA. È Associate Professor presso l’École de Technologie Supérieure (ETS) di Montréal. Per ulteriori info: www.gufpi-isma.org

Aggiungi un commento
- I commenti saranno resi visibili a seguito dell'esame da parte della Redazione -


Il tuo nome La tua e-mail    

INDICE ALTRI NUMERI






Visita il sito di Atena Informatica

Via Principi d'Acaja 38
10138 - Torino
info@affidabilita.eu
www.affidabilita.eu
Tel. +39 011 02.66.700
Fax +39 011 02.66.711
La manifestazione
italiana dedicata
all'Innovazione
e alle Tecnologie
L'unica rivista
italiana interamente
dedicata alle
Misure, Prove,
e Controlli Qualità