Teoria Locale

La qualità intesa come l’insieme dei valori che si attendono tute le parti interessate ai sistemi software ha diversi aspetti che riguardano: i processi, i prodotti, i progetti per la produzione e la evoluzione del software.

Di seguito i problemi basilari che hanno toccato le indagini empiriche inerenti la qualità.

• La produttività dei casi di test è bassa e questo implica che nonostante i costi di progettazione ed implementazione dei piani di test rimane alta la probabilità di lasciare fault nei software consegnati che si manifesteranno come failure durante lo UAT o, peggio, durante l’esercizio.
• Le dimensioni dei piani di test normalmente progettati non sono correlati alla dimensione e/o complessità dei software e nonostante la loro dispendiosità lasciano molta regressione non scoperta nei software consegnati.
• La continua manutenzione del software fa decadere la qualità del sw nel tempo sino a renderlo difficilmente manutenibile essendo così costretti a ritirarlo. Tale decadimento produce diseconomia nel processo di manutenzione ordinaria. Inoltre lo stesso decadimento è avvertito dall’utilizzatore del software attraverso la rilevazione di un maggiore numero di failure in esercizio che, a sua volta, fa diminuire la qualità avvertita e che si traduce in caduta di reputazione con conseguenti danni economici per l’impresa.
• La carenza di qualità del codice derivata dall’uso del linguaggio di programmazione non disciplinato secondo regole di buone pratiche. Tali buone pratiche è opportuno che una impresa le raccolga in modelli di qualità che siano utilizzati nella verifica statica del codice.
• La prevedibilità dei processi è necessaria per pianificare i progetti in cui essi sono utilizzati. Spesso i processi utilizzati per consuetudine non sono prevedibili.
• Nel tempo si verificano cambiamenti del contesto, degli ambienti produttivi e delle caratteristiche dei mercati di destinazione del software ovvero i cambiamenti dei requisiti degli utilizzatori. Nonostante questi eventi la qualità dei progetti non deve decadere o addirittura deve migliorare continuamente a seguito di iniziative appositamente previste. Perciò è necessario aver un modello di qualità che consenta di monitorare continuamente l’efficacia del progetto e che aiuti ad individuare le iniziative di miglioramento della stessa efficacia.

Application Lifecycle Management. Rappresenta l’unione di attività di gestione di business con attività di ingegneria del software, resa possibile dall’utilizzo di strumenti che facilitano la gestione delle fasi di: analisi dei requisiti, progetto architetturale, sviluppo, collaudo del software, gestione delle versioni, delle modifiche e della distribuzione. Nella figura seguente sono rappresentati le categorie incluse nel concetto in questione.

BRD (Business Requirement Definition). Documento standard con cui si descrivono I requisiti che sono oggetto di implementazione del progetto.

Caso di test. L’insieme dei dati in input al software e le condizioni di stato e di funzionamento dello stesso software insieme ai dati ed allo stato atteso dall’applicazione da testare. Esso costituisce una delle prove previste per verificare l’esatto comportamento del software.

Classi di rilievi. Uno stesso tipo di rilievo è riscontrabile in più punti o istruzioni del codice, per cui ogni tipo di rilievo diventa una classe che contiene il numero di rilievi dello stesso tipi e i punti in cui tali rilievi sono stati riscontrati.

Complessità del software. È una misura che esprime il numero di condizioni che gestiscono il comportamento del software. Maggiore è il numero di condizioni, maggiori sono i comportamenti del software che devono essere provati come corretti.

Dimensione del software. È una misura che dipende dal modello di rappresentazione del software. Può essere: Il numero di funzioni di business che devono essere implementate nel software se il modello di rappresentazione è il BRD, oppure il numero di istruzioni se il modello di rappresentazione è il codice.

Economicità dei piani di test. Un piano di test si dice economico se contiene un numero di casi di test che abbia una percentuale di copertura non inferiore a quella desiderata dal contesto produttivo del software. Il numero di casi di test deve dipendere solo dalla dimensione e/o dalla complessità del software da testare.

Failure/Malfunzionamento. Incapacità di un sistema software o di un componente di eseguire le sue funzioni come è prescritto nelle specifiche dei requisiti descritti nel BRD. Durante lo sviluppo, i tester osservano solitamente i malfunzionamenti.

Fault/Difetto. Informazioni, dati, asserzioni o istruzioni incorrette in un documento o nel codice oppure un comportamento incorretto nella esecuzione di una attività, di un metodo o di una tecnica in un processo software. Un difetto viene introdotto nel software a seguito di un errore. È un’anomalia che può causare un comportamento del software prodotto non conforme alle sue specifiche.

GQM. Paradigma per la definizione dei modelli di qualità basati sugli obiettivi (Goal). Il Goal sono dettagliati con Quesiti che sono resi operativi con le Metriche.

Impegno persona per il miglioramento. Il tempo-persona che i programmatori spendono per eseguire tutte le modifiche al codice necessarie per migliorare i risultati dell’analisi statica del codice.

Iniziative di miglioramento- nell’analisi statica del codice. Suggerimenti che spiegano il perché di un tipo di rilievo generato dalla verifica statica del codice e come si possa superare lo stesso tipo di rilievo.

Iniziative di miglioramento– nel monitoraggio dei progetti. Suggerimenti per migliorare eventuali carenze rilevate dal monitoraggio dei progetti.

Interpretazione. Il significato che ha nella realtà l’insieme di misure rilevate dall’esecuzione di un modello di qualità, secondo il GQM. Ogni rilevazione raccoglie il valore di tutte le misure previste nel modello di qualità, il valore di ogni misura intercetta una condizione nel modello di analisi, secondo il GQM; l’insieme delle condizioni definiscono una regola nel modello di analisi in corrispondenza della quale esiste una interpretazione secondo il GQM.

Intervallo di rilevazione. La frequenza temporale con cui  è possibile rilevare una misura prevista nel modello di qualità secondo il GQM.

Misura. Un numero o una quantità che registra un valore o una prestazione direttamente osservabili. Tutte le misure hanno un’unità collegata ad esse: pollici, centimetri, dollari, litri, ecc.

Modello di Analisi. È una componente del modello di qualità secondo il GQM. Essa contiene una tavola di decisione che associa ad ogni regola una interpretazione ed eventualmente una o più iniziative di miglioramento. Le regole sono costituite da un set di valori di condizioni logiche che verificano i valori delle misure previste dal GQM.

Modello di processo. Tentativo di organizzare il processo di sviluppo e/o di manutenzione del software individuando le attività coinvolte, rispettivamente, nella produzione del software e nella sua evoluzione, definendo le relazioni temporale tra esse. Un modello di processo è utilizzato per specificare i processi in progetti che hanno determinate caratteristiche. Perciò in una impresa produttrice di software possono essere gestiti diversi modelli di processo, ognuno adeguato per una classe di progetti con specifiche caratteristiche.

Modello Metrico. È la sezione del modello di qualità, secondo il GQM, in cui sono espresse le relazioni tra il Goal, i Quesiti e le Misure. Ogni misura è caratterizzata da un insieme di parametri che esprimono tra l’altro: su quale entità deve essere rilevata, quando deve esser rilevata, la fonte da cui può essere rilevata e così via.

Monitoraggio del progetto. Processo attraverso il quale si osserva la qualità del progetto e nel caso sia necessario si operano le modifiche al progetto che ne migliorano la qualità.

Metodo sistematico per la progettazione dei piani di test. Un metodo descritto rigorosamente così che il piano di test prodotto dipenda solo dalle specifiche del sistema software da testare. Si dice che il metodo è sistematico perché grazie alla sua rigorosità si verifica che: Utilizzando correttamente lo stesso metodo diversi tester progetterebbero piani di test equivalenti per uno stesso software; lo steso tester utilizzando il metodo progetterebbe in tempi diversi piani di test equivalenti per uno stesso software. Due piani di test si dicono equivalenti se i casi di test contenuti in essi, anche essendo diversi, rivelerebbero gli stessi malfunzionamenti se eseguiti sullo stesso software.

Oggetto osservato. Oggetto a cui si riferisce il goal del modello di qualità, secondo il GQM. Può essere un processo, un prodotto, un progetto o una risorsa. Esso per poter essere usato nel modello di qualità deve essere descritto attraverso un set di caratteristiche.

Piani di test. L’insieme dei casi di test a cui sarà sottoposto il software di cui si vuole provare la completezza e la correttezza.

Prevedibilità dei processi. Allocazione corretta e nei tempi appropriati delle risorse umane, strumentali e finanziarie nei processi durante la loro esecuzione quando sono utilizzati nei progetti. Questa caratteristica elimina gli sprechi, risorse messe a disposizione quando non servono o per un tempo superiore a quello necessario, oppure evita che un progetto si fermi perché non sono state rese disponibili le risorse necessarie nel tempo giusto.

Processi di manutenzione. Insieme delle attività che servono per implementare modifiche correttive p evolutive del codice.

Produttività dei piani di test. Numero dei casi di test falliti durante le esecuzioni del piano di test diviso il numero di casi di test totali del piano di test. Se questo rapporto è troppo piccolo rispetto ad una soglia, normalmente definita dalla storia del contesto di sviluppo, vuol dire che il piano di test non è stato progettato bene o il software testato ha un livello di qualità più alto di quello storico, se è più alto della soglia vuol dire che il livello di qualità del software e/o del processo di riparazione dei malfunzionamenti è al di sotto della soglia accettabile.

Progettazione del GQM. Processo attraverso cui si struttura sia il Modello Metrico che il Modello di Analisi, seguendo il paradigma GQM.

Programmatore. Sviluppatore che produce il codice di un sistema software.

Qualità del codice/ dei prodotti. È l’insieme delle caratteristiche che si desiderano che il codice abbia. In particolare le qualità obiettivo sono: efficienza, manutenibilità, portabilità, affidabilità, sicurezza.

Quesito. È il mezzo attraverso cui nel GQM si dà una struttura logica al goal.

Rilievo. Una difformità del codice rispetto allo standard d’uso del linguaggio.

Sessione di analisi statica del codice. Una esecuzione dell’analisi statica del codice eseguita da uno strumento automatico specifico.

Soddisfazione dei clienti. Obiettivo di tutti i fornitori di software che si raggiunge quando la qualità del software avvertita dai clienti è quella che essi si aspettano. Il grado di soddisfazione dei clienti si rileva dalla intensità e contenuti dei reclami.

Spreco. Tutto ciò che è speso nello sviluppo o manutenzione del software che non porta valore a nessuna delle parti interessate.

Standard d’uso del linguaggio. Insieme di buone pratiche nella scrittura del codice e nell’uso di uno specifico linguaggio di programmazione. Tali pratiche sono rilevate dall’esperienza di letteratura e dell’impresa produttrice di software ed hanno l’obiettivo di realizzare più facilmente le qualità richieste al codice.

Uso del GQM. Processo in cui rilevate i valori delle misure previste nel Modello Metrico questi sono interpretati secondo il Modello di Analisi e, secondo lo stesso modello, sono suggerite le possibili iniziative di miglioramento. Quando le interpretazioni sono difformi dalle situazioni reali e/o le iniziative di miglioramento non hanno il risultato previsto vuol dire che il modello GQM deve essere migliorato. In questa guisa il modello raccoglie esperienza e diventa sempre più efficace.

Verifica/Analisi statica del codice. Verifica che le istruzioni e la struttura del codice verifichino specifiche caratteristiche che assicurano il raggiungimento di certi livelli di qualità.

Verifica e Validazione (V&V). processo standard che è eseguito al termine di ogni fase dello sviluppo software per sindacare che la documentazione prodotta sia corretta e completa.

Vincoli per disciplinare la esecuzione dei processi. Un processo determina l’ordine degli stadi coinvolti nello sviluppo e nell’evoluzione del software; per governare il corretto passaggio tra i vari stadi previsti dal processo è necessario stabilire i criteri di transizione per progredire da uno stadio al successivo. Questi includono criteri di completamento per lo stadio corrente e criteri per la scelta e l’ingresso dello stadio successivo. Tali criteri e le figure professionali implicate nei processi che possono prendere tali decisioni costituiscono i vincoli in questione.

1. L’introduzione della V&V del BRD, contrariamente alle attese, non modifica sensibilmente la produttività dei piani di test nel TS; anche se la V&V risulta efficace nella rilevazione dei fault nel BRD.
2. I piani di test di sistema prodotti con un metodo sistematico sono più produttivi e più economici nella loro realizzazione. La maggiore produttività del test progettato con il metodo sistematico assicura la diminuzione dei difetti lasciati disseminati nel software consegnato e quindi un minor numero di difetti scoperti durante l’esercizio del software. Questo fa diminuire la manutenzione ordinaria del software ed aumenta la qualità avvertita dello stesso software. L’economicità della realizzazione del piano di test è assicurata dal numero di casi di test che nei piani di test progettati sistematicamente (con metodo rigoroso) sono dipendenti dalla dimensione e complessità del sistema da testare.
3. La verifica statica del codice periodica favorisce la individuazione dei punti critici della qualità del codice, la definizione delle iniziative di miglioramento dei prodotti allo scopo di alleggerire i processi di manutenzione e migliorare la soddisfazione dei clienti, la decisione su come spendere più efficacemente l’impegno persona per il miglioramento.
4. Grazie all’analisi statica del codice periodica il programmatore si conforma sempre meglio agli standard d’uso del linguaggio definiti in Auriga. Addirittura si rileva che con il tempo il numero delle classi di rilievi diminuisce notevolmente fino a divenire di qualche unità. Questo risultato ha un rilevante riverbero sulla economicità della codifica.
5. Tutti i programmatori diminuiscono anche considerevolmente il numero dei rilievi emersi dall’analisi statica del codice dopo aver eseguito le iniziative di miglioramento. Ma lo stesso programmatore in sessioni di analisi statica del codice diverse ha performance diversa e che questa qualche volta peggiora nonostante il programmatore abbia acquisito maggiore esperienza sull’uso del linguaggio.
6. Condizione necessaria per migliorare la prevedibilità dei processi è l’adozione di un modello di processo e dei vincoli per disciplinare la esecuzione dei processi amministrata con un Application Lifecycle Management (ALM). Le conseguenze derivate sono il miglioramento della qualità dei processi che è, a sua volta, condizione necessaria per il miglioramento della qualità dei prodotti, della individuazione tempestiva degli sprechi e della maggiore prevedibilità della esecuzione dei progetti che usano tali processi.
7. Nell’uso del GQM per monitorare la qualità del progetto, maggiore è il dettaglio dell’oggetto osservato più significative saranno le interpretazioni delle misure che produrrà il modello di analisi per verificare che la qualità del progetto sia rimasta invariata o sia migliorata e, in caso contrario, più specifiche saranno le iniziative di miglioramento, collegate alle interpretazioni, che il modello di analisi suggerirà.
8. Nella progettazione del GQM si deve curare che le misure previste abbiano gli intervalli di rilevazione piccoli ed omogenei, almeno devono essere omogenei per le misure incluse in ogni quesito previsto nel modello di qualità; questo assicura che si minimizzino gli sprechi nel monitoraggio del progetto e nelle iniziative di miglioramento della qualità del progetto.
9. L’uso del GQM accumula conoscenza attraverso le interpretazioni e le iniziative di miglioramento corrispondenti alle regole che le misure rilevate attivano che è trasferita tra tutti gli sviluppatori e nel tempo così che sia sempre più efficace il monitoraggio della qualità del progetto.

1. L’introduzione della V&V del BRD, contrariamente alle attese, non modifica sensibilmente la produttività dei piani di test nel TS; anche se la V&V risulta efficace nella rilevazione dei fault nel BRD.
2. I piani di test di sistema prodotti con un metodo sistematico sono più produttivi e più economici nella loro realizzazione. La maggiore produttività del test progettato con il metodo sistematico assicura la diminuzione dei difetti lasciati disseminati nel software consegnato e quindi un minor numero di difetti scoperti durante l’esercizio del software. Questo fa diminuire la manutenzione ordinaria del software ed aumenta la qualità avvertita dello stesso software. L’economicità della realizzazione del piano di test è assicurata dal numero di casi di test che nei piani di test progettati sistematicamente (con metodo rigoroso) sono dipendenti dalla dimensione e complessità del sistema da testare.
3. La verifica statica del codice periodica favorisce la individuazione dei punti critici della qualità del codice, la definizione delle iniziative di miglioramento dei prodotti allo scopo di alleggerire i processi di manutenzione e migliorare la soddisfazione dei clienti, la decisione su come spendere più efficacemente l’impegno persona per il miglioramento.
4. Grazie all’analisi statica del codice periodica il programmatore si conforma sempre meglio agli standard d’uso del linguaggio definiti in Auriga. Addirittura si rileva che con il tempo il numero delle classi di rilievi diminuisce notevolmente fino a divenire di qualche unità. Questo risultato ha un rilevante riverbero sulla economicità della codifica.
5. Tutti i programmatori diminuiscono anche considerevolmente il numero dei rilievi emersi dall’analisi statica del codice dopo aver eseguito le iniziative di miglioramento. Ma lo stesso programmatore in sessioni di analisi statica del codice diverse ha performance diversa e che questa qualche volta peggiora nonostante il programmatore abbia acquisito maggiore esperienza sull’uso del linguaggio.
6. Condizione necessaria per migliorare la prevedibilità dei processi è l’adozione di un modello di processo e dei vincoli per disciplinare la esecuzione dei processi amministrata con un Application Lifecycle Management (ALM). Le conseguenze derivate sono il miglioramento della qualità dei processi che è, a sua volta, condizione necessaria per il miglioramento della qualità dei prodotti, della individuazione tempestiva degli sprechi e della maggiore prevedibilità della esecuzione dei progetti che usano tali processi.
7. Nell’uso del GQM per monitorare la qualità del progetto, maggiore è il dettaglio dell’oggetto osservato più significative saranno le interpretazioni delle misure che produrrà il modello di analisi per verificare che la qualità del progetto sia rimasta invariata o sia migliorata e, in caso contrario, più specifiche saranno le iniziative di miglioramento, collegate alle interpretazioni, che il modello di analisi suggerirà.
8. Nella progettazione del GQM si deve curare che le misure previste abbiano gli intervalli di rilevazione piccoli ed omogenei, almeno devono essere omogenei per le misure incluse in ogni quesito previsto nel modello di qualità; questo assicura che si minimizzino gli sprechi nel monitoraggio del progetto e nelle iniziative di miglioramento della qualità del progetto.
9. L’uso del GQM accumula conoscenza attraverso le interpretazioni e le iniziative di miglioramento corrispondenti alle regole che le misure rilevate attivano che è trasferita tra tutti gli sviluppatori e nel tempo così che sia sempre più efficace il monitoraggio della qualità del progetto.

1. La conoscenza dello standard BRD e del dominio applicativo possono creare diseconomie nella produzione del BRD. Infatti, i TAM Junior hanno prodotto DRD con il più alto numero di entrambi i tipi di rilievi (“info ambigua” ed “Omissione”). Altresì gli stessi tipi di errori sono stati rilevati con maggiore dispersione nei BRD prodotti dagli junior; quindi i difetti iniettati da questi BRD renderanno meno prevedibili gli impegni-persona che si dovranno spendere nelle fasi del processo di sviluppo a causa delle rilavorazioni che essi comporteranno. Un’altra corroborazione di questo rischio è dato dalla costatazione che l’impegno persona speso dai TAM junior per l’analisi e nettamente maggiore di quello speso dai TAM senior. Infine si verifica che anche per i TAM senior aumenta la probabilità di superare la media di impegno-persona prevista per l’analisi nel caso che il progetto tratti aspetti innovativi del dominio applicativo; ad esempio nel caso di Auriga l’introduzione del regolamento PSD2. Questo rischio può essere mitigato con: il trasferimento accurato di queste competenze ai TAM neofiti; il rafforzamento delle stesse per i TAM junior; l’aggiornamento sistematico per tutti i TAM delle innovazioni di contenuti del dominio applicativo.
2. La carenza di rigorosità dello standard BRD causa carenza di qualità nei BRD prodotti che a loro volta causano diseconomia nel resto del processo di sviluppo dei software consegnati ai clienti. Per mitigare questo rischio è opportuno che dall’analisi dei rilievi prodotti nella V&V e delle failure rilevate nei TS e negli UAT si rilevino i possibili miglioramenti da apportare allo standard BRD in termini sia di processo che di contenuti dello stesso BRD.
3. Carenza di rigorosità nella progettazione del piano di test aumentano la probabilità di disperdere la produttività e la economicità del piano di test. Per mitigare questo rischio è necessario consolidare le competenze circa il metodo rigoroso di progettazione dei piani di test e di monitorare continuamente il livello di questa competenza nel capitale umano disponibile in azienda per migliorarlo continuamente.
4. Ci sono rilievi alla qualità del codice che non sono risolvibili, significativamente, con cambiamenti del codice perché derivano da carenze nella progettazione del codice. Per mitigare questo rischio è necessaria la ristrutturazione del software che attiene alla fase di progettazione. i difetti strutturali sono i più complessi e costosi da superare e frequentemente richiedono dei piani di ristrutturazione del codice che parta dalla corrispondente progettazione del sistema. Il beneficio che porta questo notevole costo è un notevole miglioramento della qualità del sistema ed in particolare della sua manutenibilità.
5. I vincoli imposti all’ALM non siano sufficienti a garantire la conforme esecuzione dei processi. Per mitigare questo rischio è necessario continuare a sperimentare la efficacia del combinato disposto “modello di processo – vincoli sull’ALM”.
6. I due modelli, metrico e analitico, sono dipendenti tra loro quindi è alta la probabilità che la modifica di uno comporti quella dell’altro dovendo mantenere coerenti i contenuti dei due modelli. Se non si tiene conto di tale dipendenza una modifica al modello di qualità potrebbe iniettare notevoli difetti nel modello con i conseguenti danni generati dalle interpretazioni e dalle iniziative di miglioramenti incoerenti con la realtà progettuale. Per mitigare questo rischio è opportuno che ogni modifica al modello di qualità sia trattata come la reingegnerizzazione del modello con il relativo impegno-persona che richiede.
7. La significatività delle misure previste per gli aspetti che si vogliono osservare non siano chiaramente discriminanti tra le regole su cui è basata la interpretazione. Questo implicherebbe che la interpretazione non coincide con quello che sta accadendo con la realtà e quindi le iniziative di miglioramento corrispondenti risultino inefficaci, creando cosi degli sprechi. Per mitigare questo rischio è opportuno che ogni volta che il progettista vuole inserire una misura nel modello di qualità deve avere chiaro cosa esprime questa misura nella realtà progettuale e deve avere chiaro, quindi, come interpretare i suoi possibili valori.
8. La rilevazione delle misure non sia automatica e non possa essere riversata nello strumento che gestisce il GQM. Questo richiede impegno-persona per avvalorare la misura ed immetterla nel sistema gestore del GQM. Inoltre potrebbe ritardare la rilevazione della misura rispetto all’intervallo di rilevazione della stessa, quindi ritardare la frequenza di monitoraggi con le conseguenze di diseconomie: mancata minimizzazione degli sprechi nel caso che le iniziative di miglioramento falliscano e mancata massimizzazione dei vantaggi nel caso contrario. Per mitigare questo rischio il progettista del modello di qualità deve sforzarsi di utilizzare misure che siano rilevabili automaticamente o, quanto meno, che siano utilizzate nell’impresa anche per altri scopi così che l’onere di rilevazione sia suddiviso tra i diversi scopi della misura; deve tener presente che in questo secondo caso non si è fugato il rischio di diradare la frequenza di monitoraggio del progetto.

• È opportuno verificare che il miglioramento della qualità del processo di sviluppo del software nelle altre fasi del processo di sviluppo migliori i risultati anche della fase di V&V dell’analisi.
• È opportuno estendere le indagini empiriche sulla efficacia dei metodi di progettazione utilizzati nell’impresa e con essa anche la struttura dello SDS ed il processo per produrlo.
• È opportuno un monitoraggio della qualità dei processi per rintracciare gli eventuali punti di miglioramento dei relativi modelli.