Documentare i requisiti software: catalogo dei criteri e analisi del valore d’uso

Perché i requisiti documentati decidono su costi, tempi e rischi

La qualità del software agisce su quattro dimensioni: costi, tempi, rischi e sostenibilità futura. Una scarsa qualità si manifesta in elevati oneri di manutenzione e riparazione. Per il 2022, il Consortium for Information & Software Quality ha stimato i costi della scarsa qualità del software negli Stati Uniti a oltre 2,41 trilioni di dollari USA.

Decisivo è il momento in cui viene rilevato un errore. Gli errori individuati e corretti nelle fasi iniziali del processo di sviluppo comportano oneri nettamente inferiori rispetto a quelli che emergono solo durante l’esercizio produttivo. Ogni punto dei requisiti considerato già nella fase di pianificazione di un progetto software tutela dimostrabilmente il budget software. Ciò evita grandi dispendi di tempo dovuti ad adeguamenti costosi e complessi.

I requisiti documentati incidono su grandezze che diventano visibili solo durante l’esercizio. Tra queste vi sono una maggiore affidabilità delle applicazioni e, di conseguenza, minori tempi di indisponibilità, costi più bassi lungo l’intero ciclo di vita nonché rischi finanziari e di sicurezza ridotti, fino alla protezione contro gli attacchi informatici e le violazioni dei dati. Migliora anche la manutenibilità: adeguamenti ed estensioni diventano più efficienti, sostenendo l’agilità dei progetti.

Si aggiungono un time-to-market più rapido e la possibilità di sviluppare ulteriormente il software senza dover rivedere l’intera architettura. Chi precisa i requisiti solo al momento dell’accettazione paga questi effetti in seguito attraverso rilavorazioni, oneri di test e slittamenti delle scadenze.

ISO/IEC 25010 come catalogo dei criteri: otto caratteristiche di qualità come linguaggio comune

La norma internazionale ISO/IEC 25010 definisce un modello di qualità completo per sistemi e software. Offre un approccio standardizzato con cui le aziende possono valutare e migliorare in modo efficiente e coerente la qualità dei propri prodotti software. La verifica avviene sulla base del modello di qualità del prodotto con otto punti: idoneità funzionale, sicurezza, manutenibilità, prestazioni, compatibilità, flessibilità, usabilità e affidabilità.

La norma è un quadro di riferimento e non un catalogo dei requisiti. Mette a disposizione la terminologia con cui sviluppatori, tester, manager e altri portatori di interesse definiscono e valutano sistematicamente i requisiti di qualità del software. Un linguaggio comune e una comprensione condivisa rendono la qualità del software effettivamente valutabile in modo sistematico.

Non è la norma a stabilire quale declinazione di una caratteristica sia vincolante per un prodotto concreto, ma il progetto. L’utilità del modello risiede nel fatto che tutti i partecipanti intendono la stessa cosa quando parlano di «manutenibilità» o «prestazioni».

Per la pratica vale la pena considerare la versione: la SQS basa le sue verifiche sulla ISO/IEC 25010:2023. Panoramiche precedenti della norma citano talvolta denominazioni diverse come funzionalità, affidabilità, user-friendliness, efficienza, manutenibilità e portabilità. Per il catalogo dei criteri e la certificazione fa fede l’attuale strutturazione del modello di qualità del prodotto.

Confronto delle caratteristiche di qualità della ISO/IEC 25010:2023 con le loro declinazioni nella pratica

Dalla caratteristica al requisito verificabile

Una caratteristica diventa un requisito solo quando è formulata in modo misurabile. In un workshop, esperti di sieber&partners hanno mostrato, sulla base di due codebase interne, come la qualità possa essere misurata oggettivamente. Hanno trasmesso conoscenze pratiche sugli standard ISO e sugli strumenti che trasformano impressioni soggettive in metriche misurabili – metriche che devono essere interpretate in modo competente.

Per la documentazione ciò significa: per ogni caratteristica si definisce cosa viene misurato, con quale metodo viene rilevato e quale valore si considera raggiunto.

Gli indicatori chiave non sono un fine in sé. Servono a valutare uno stato e al successivo miglioramento, non a dimostrare che si è lavorato. Chi include una metrica nel catalogo dovrebbe documentare anche quale decisione dipende da essa: se una release viene approvata, se è necessaria una revisione architetturale o se un fornitore soddisfa il requisito. I valori di misura privi di questo collegamento generano oneri, ma nessun effetto di governo; diventano obsoleti non appena il prodotto cambia.

Analisi del valore d’uso: ponderare i requisiti e rendere confrontabili le varianti

L’analisi del valore d’uso traduce il catalogo dei criteri in una valutazione e rende confrontabili le varianti di soluzione. Innanzitutto si fissano i criteri – di regola le otto caratteristiche di qualità oppure i requisiti specifici del progetto da esse derivati. Poi si assegnano pesi che esprimono, in relazione reciproca, quanto conta una caratteristica per il progetto.

Ogni variante viene valutata per ciascun criterio su una scala definita in anticipo e applicata uniformemente per tutti. I valori ponderati di ogni variante vengono sommati e se ne ricava una classifica.

La classifica è uno strumento argomentativo, non un automatismo decisionale. Una differenza di punti che deriva esclusivamente da una ponderazione impostata deve essere motivata e verificata nella sua sensibilità: la sequenza cambia se un peso viene aumentato o diminuito?

Risultato e ipotesi vanno inseriti insieme nella documentazione, affinché resti comprensibile in seguito perché è stata scelta una determinata variante. Quali pesi siano sensati dipende dal prodotto: nei sistemi critici per la sicurezza come quelli medici, sicurezza e affidabilità hanno un peso maggiore rispetto alla flessibilità; in un’applicazione di mercato con cicli brevi può essere il contrario. In questo modo la valutazione si collega direttamente alle otto caratteristiche di qualità – esse costituiscono l’elenco dei criteri da cui provengono i pesi.

Classifica delle caratteristiche di qualità per tipo di progetto

Documentazione utilizzata effettivamente da sviluppo, test e management

La documentazione dei requisiti ha tre gruppi di lettori con domande diverse. Lo sviluppo vuole sapere cosa costruire; il test vuole sapere come dimostrare il soddisfacimento; il management vuole valutare oneri, rischi e idoneità all’accettazione.

Un requisito serve tutti e tre se contiene un’identificazione univoca, la sua origine ovvero il committente, una condizione di accettazione verificabile e il riferimento alla caratteristica di qualità. Test e verbali di accettazione rimandano alla stessa identificazione, così che sia visibile a colpo d’occhio quale requisito è stato verificato con cosa.

I requisiti cambiano durante il progetto. Una voce di modifica con data, motivazione e impatto su oneri, scadenze e casi di test mantiene aggiornato il catalogo e rende spiegabili le deviazioni successive. Il versioning e un unico stato valido impediscono che sviluppo e test partano da presupposti diversi. In questo modo la documentazione resta utilizzabile anche oltre l’accettazione – come base per lo sviluppo ulteriore, l’analisi degli errori e la prossima valutazione.

Elementi di una documentazione dei requisiti utilizzabile

Verifica esterna e certificazione in Svizzera

Una valutazione indipendente segue un procedimento fisso: analisi, ossia la valutazione del software basata sui criteri della ISO/IEC 25010:2023; raccomandazioni di ottimizzazione con identificazione e risoluzione di punti deboli in funzionalità, sicurezza, manutenibilità, prestazioni, compatibilità, flessibilità, usabilità e affidabilità; e infine il rilascio del certificato dopo il superamento positivo della verifica.

Il certificato viene assegnato nei livelli Bronzo, Argento o Oro ed è valido due anni. Grazie a una ricertificazione continua, i progetti agili possono essere mantenuti al livello di qualità richiesto.

Il certificato viene rilasciato dall’Associazione svizzera per i sistemi di qualità e di gestione (SQS). Dal 1983 certifica sistemi di gestione e, secondo le proprie indicazioni, conta circa 7000 clienti tra i destinatari dei suoi servizi. La SQS offre verifiche e certificazioni sulla base della ISO/IEC 25010 in collaborazione con la Dr. Pascal Sieber & Partners AG; il gruppo target sono le imprese di sviluppo software.

Come effetto indica la costruzione di fiducia attraverso la dimostrazione di un elevato standard di qualità, un vantaggio competitivo grazie alla qualità del software verificata, un aumento dell’efficienza mediante la minimizzazione degli errori e degli oneri di manutenzione, la sensibilizzazione del team e la sicurezza futura. Dopo la verifica, dai risultati si possono derivare sistematicamente passi per il futuro rispetto degli standard e, puntualmente, per l’aumento della qualità del software.

Procedura di una certificazione esterna secondo ISO/IEC 25010:2023 in Svizzera

Conclusione: i requisiti di qualità come compito dirigenziale

Un catalogo dei criteri curato e un’analisi del valore d’uso corretta agiscono simultaneamente su più fronti: la qualità del software verificata costruisce fiducia nei confronti dei clienti e crea un vantaggio competitivo; la gestione strutturata della qualità riduce gli oneri per errori e manutenzione; le competenze acquisite confluiscono nei progetti futuri. Un software facilmente manutenibile può essere sviluppato ulteriormente senza dover rivedere l’intera struttura, e la ricertificazione biennale mantiene questo livello anche nei progetti agili.

Diventa un compito dirigenziale perché pesi, condizioni di accettazione e gestione delle deviazioni non possono essere decisi unicamente nello sviluppo: essi governano oneri, scadenze e rischi dell’intero progetto. Chi guida il catalogo, documenta la valutazione ed esegue periodicamente la verifica esterna può motivare le decisioni invece di doverle difendere.