Una delle principali tentazioni per chi lavora o si occupa di progetti ICT è di automatizzare quanto più possibile e, sarebbe il caso di dirlo, “costi quel che costi!”. Il rischio è pertanto che da ‘strumento’ l’automazione diventi ‘obiettivo’, perdendo di fatto il proprio valore di ‘ingrediente’ (asset) in una buona ricetta (progetto). Come indicato dal buon senso comune (prima) e da alcune best practice quali ITIL e approcci quali DevOps (poi), un tool va attentamente selezionato dopo aver ottimizzato i flussi di processo che intende supportare, non scelto a prescindere dall’uso reale che se ne farebbe, partendo dalle sue potenzialità. È il processo a dover usare un tool e non il contrario. Ma la realtà nel settore ICT racconta spesso un’altra storia, ovverosia di disporre di prodotti ERP fortemente personalizzati (con alti costi di realizzazione) in luogo di prodotti/soluzioni ad-hoc, magari con un minore impegno economico ed un maggiore ‘fit for purpose’. Normalmente il rapporto benefici/costi dovrebbe essere positivo, analizzando pertanto condizioni d’uso che suggeriscano o sconsiglino l’adozione spinta di tecnologia. Basti pensare ai magazzini di Amazon: i robot fanno il lavoro ‘sporco’ (movimentazione dei carichi nel magazzino), ma poi l’impacchettamento è lasciato ad esperte mani umane, così come nelle fabbriche automobilistiche le parti più delicate dell’assemblaggio di componenti è deputato ad operatori umani. Insomma…tecnologia si, ma ‘q.b. (quanto basta)’, come la normale logica vorrebbe. Lo stesso vale per la software quality.
Indice degli argomenti
Possibili criteri per una buona applicazione dell’automazione
Quando si parla però di progetti software, la regola sembra spesso diventare eccezione, sebbene anche DevOps proponga l’automazione quale uno dei cinque valori CALMS (Culture, Automation, Lean, Measurement, Sharing), ma non necessariamente il principale, dovendosi trovare un buon bilanciamento dei cinque elementi (figura 1).
Una valida ‘toolchain’, prevede ad esempio una corretta integrazione dei tool utilizzabili nelle diverse fasi di un ciclo di vita. E qui sta uno dei possibili criteri di valutazione: usare un tool adeguato, utile e che generi valore per il progetto in un dato momento, non in assoluto.
Strumenti per la gestione e memorizzazione dei requisiti utente dovrebbero poter avere punti di aggancio con quelli per il testing (ad esempio condividendo matrici di copertura che permettano di valutare la completezza di un piano di test e collaudo), ma non diventare ‘coltellini svizzeri’ multi-uso, essendo proposti come soluzioni di ALM (Application Lifecycle Management).
Un buono strumento dovrebbe essere specializzato nel fare qualcosa bene, rapidamente, con poca fatica ma con un buon livello di accuratezza e precisione, comparato con l’esecuzione umana. Pertanto è possibile individuare aree e fasi del ciclo di vita nelle quali l’automazione risulta sicuramente più utile e performante ed altre nelel quali la combinazione di costi, rischi e valore propende per l’attività manuale.
Automatizzare la misurazione della software quality?
Passando dalle considerazioni generali a quelle specifiche sulla misurazione della software quality, l’automazione può portare beneficio laddove il contenuto è stabile e già acquisito (es: code quality analysis, esecuzione automatica di test case, …) ma non dove al contrario è variabile (es: analisi dei requisiti, …), mentre è da valutarsi neutro quando il tool è un mero collettore e organizzatore di contenuti.
Veniamo al punto: un requisito per valutare un automatizzare la misurazione della software quality può essere – come nella figura 2 seguente, rappresentante un iceberg – ben espresso, ambiguo/non granulare o addirittura dato per scontato, implicito. Sono molti i tentativi di utilizzo di meta-linguaggi per la codifica di uno user requirement (UR), ma ancora non soddisfacenti, sempre applicando i criteri summenzionati (costo, rischio, valore/beneficio).
Alcuni esempi: trasformare un UR in una forma UML (Unified Modeling Language) è sicuramente utile per chiarire ed uniformare lo stile di scrittura tra gli attori ma ha un costo (il tempo di traduzione nel meta-linguaggio partendo da un requisito ‘umano’ e gli eventuali costi di licenza del software), un rischio (ogni diagramma UML ha un obiettivo d’uso specifico, quindi potrebbe servirne uno in più, non inizialmente previsto…ad esempio per diagrammare un requisito non-funzionale, NFR (Non-Functional Requirements) e un valore (come in ITIL, l’insieme dei requisiti funzionali e non-funzionali…quale diagramma UML usereste per rappresentare gli aspetti proposti nella norma ISO/IEC 25010 o 25012 sulla qualità dei dati?).
Ancora, tool per la stima dell’effort usando metodi parametrici quali CO.CO.MO. Si partirebbe dall’inserire un numero di LOC (Lines of Code) che in fase di stima ancora non si conosce per poi selezionare un livello atteso (alto, medio, basso, …) per una serie di parametri (cost-drivers) i cui valori sono impostati a partire da una base dati di progetti non noti e quindi possibilmente non simili al progetto che staremmo valutando con una logica di tipo ‘black box’, determinando in pochi minuti il numero dei giorni di lavoro attesi, la data di consegna, i costi associati e una distribuzione dell’effort suddivisa per macro-fasi del ciclo di vita.
Il costo sembrerebbe ridotto (pochi minuti per inserire le informazioni ‘qualitative’ richieste), ma il rischio è sicuramente alto: come determinare quante LOC avremo a posteriori prima di averle scritte? E poi, le LOC non sono un’espressione della dimensione funzionale di un software, ma solo della lunghezza delle istruzioni (statemente) adottati per realizzare quelle funzionalità, fortemente variabili in funzinoe dello stile di programmazione adottato. Ancora, basti calcolare ex-post il ‘relative error’ tra valori stimati e consuntivati usando i giorni-persona. Il valore, conseguentemente, sarebbe non ottimale. ‘Quick & dirty’ non si associa bene ad una fase di stima di un progetto, grande o piccolo che sia, fortemente cruciale da essere ‘meccanicizzata’.
Ultimo esempio: strumenti di conteggio automatico delle funzionalità di un software. I Software vendor propongono due possibili approcci: derivare il numero di FP (di qualunque tipo siano) da eleborazioni dei requisiti (es: UML) o da un parsing del codice sorgente.
Nel primo caso, tradurre un requisito umano, di per sé ambiguo, porta a una variabilità sensibile dei valori ottenuti (es: ‘gestire’ potrebbe essere interpretato come ‘CRUD’ (Create/Read/Update/Delete) o CRUDL (L: List, aggiungendo una o più visualizzazioni o export). Forzare l’elicitazione dei requisiti per essere validi in un qualsivoglia meta-linguaggio ha un costo non banale di istruzione sia per l’analista che per gli stakeholder (tanti, diversi e variabili) da contattare. Le certificazioni individuali (es: IFPUG CFPS/CFPP, COSMIC CCFL, …) rispondono proprio a questo obiettivo.
Nel secondo caso invece uno strumento che determini un valore ex-post (e non ex-ante) riduce di molto la propria utilità e valore, dato che la quasi totalità dei conteggi FPA è nella quotidianità relativo a manutenzioni evolutive di sistemi esistenti o a nuovi sviluppi e che quindi non hanno codice da analizzare. Il conteggio c.d. di baseline è un caso importante ma ben delimitato e in ogni caso, come indicato in un recente documento AGID sulle misure software nei contratti ICT, citiamo testualmente, “IFPUG non ha validato la correttezza e validità degli algoritmi proposti da OMG”, con riferimento agli AFP (Automated Function Points).
Infine, le manutenzioni correttive non modificano alcun FUR e quindi rappresentano un ulteriore tipo di interventi ‘out of scope’ per questo genere di tool. I costi sono relativi alle eventuali licenze (nel caso di strumenti commerciali), tempo di istruzione di uno specialista di prodotto e per applicazioni limitate il rischio è di una non approvata compatibilità da parte delle associazioni internazionali che gestiscono le principali metodologie FSM (Functional Size Measurement) e in ogni caso non siano correttamente definiti i confini delle applicazioni parte di un’architettura come i file logici partendo dallo schema fisico delle tabelle dati. Il valore, conseguentemente, sembra non essere positivo, dato che la variabilità tra i conteggi automatici e quelli effettuati da un certificato umano non sono banali, né in termini assoluti che percentuali.
Quali possibili conclusioni?
Insomma, uno strumento è sempre valido ma a condizione di generare un vantaggio (ovverosia un ‘valore’). In parole povere, ci dovremmo chiedere se ‘ne valga la pena’ oppure no…E la risposta va determinata volta per volta, applicando i criteri sopra proposti. Come diceva Eliyahu Goldratt, l’ideatore della Theory of Constraints (TOC): “Automation is good, so long as you know exactly where to put the machine“.
GUFPI-ISMA ha ridefinito nel 2016 le proprie Linee Guida con un primo volume relativo ai Principi, Assunzioni e Best Practice Contrattuali (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 sito di GUFPI-ISMA per ulteriori spunti ed approfondimenti!
Partecipa alla community