Cosa è la qualità 7. La del Software Diversi enti di standardizzazione (es. ISO) hanno cercato di integrare vari approcci alla definizione della qualita, partendo dalla consapevolezza che la qualità è un attributo che varia in funzione del percettore, del contesto di percezione, dello scopo e del costo del prodotto. Ing. Alessandro Musumeci 6.-1 6.-2 Cosa è la qualità Cosa è la qualità La qualità, secondo la ISO 8402 (1994) Vocabolario della qualità, è l insieme delle proprietà e delle caratteristiche di un entità che conferiscono ad essa la capacità di soddisfare esigenze espresse e implicite. Il sistema di norme ISO si basa su questi ulteriori principi: la qualità di un sistema è la risultante della qualità delle sue componenti e delle loro relazioni (non la somma delle ) la qualità di un prodotto (o servizio) è conseguenza dell efficacia e della efficienza dei processi che li hanno generati e li supportano (ISO 9004-4) la qualità viene giudicata dall utente! La qualità deve essere valutata attraverso alcune proprietà misurabili in modo oggettivo e quantitativo possedute dalle entità. Differenti entità possono essere collocate su una scala di valori in funzione dei livelli misurati per questi attributi. 6.-3 6.-4
Supporto normativo Supporto normativo I principi fin qui illustrati hanno spinto la ISO a definire dei modelli di riferimento per la realizzazione e gestione della qualità di Processi (ISO 9001) Prodotti informatici (ISO 9126..) e per la realizzazione e gestione della Soddisfazione dell utente (ISO 9126-1) A supporto di questi modelli, la ISO ha definito il ciclo di vita di un prodotto informatico (ISO 12207) linee guida per la applicazione della ISO 9001 all ambiente IT (ISO 9000-3) linee guida per la applicazione della ISO 9001 ai servizi (ISO 9004/2) Linee guida per la valutazione della qualità di un prodotto informatico basate sul modello ISO 9126 ed applicate nel ciclo di vita ISO 12207 (ISO 14598) 6.-5 6.-6 Terminologia Terminologia Dalle norme ricaviamo queste definizioni: Processo: insieme di risorse ed attività tra loro interconnesse che trasformano delle entità in ingresso in entità in uscita. Entità in ingresso ed uscita possono essere sia prodotti, sia servizi; le risorse possono comprendere personale, facilitazioni, mezzi, apparecchiature, tecniche e metodologie (ISO 8402) Prodotto sw: insieme di programmi, procedure, e della documentazione e dei dati associati (ISO 12207: 1995) Elemento sw: parte identificabile di un prodotto sw, ad uno stadio intermedio od allo stadio finale di sviluppo 6.-7 6.-8
Terminologia Terminologia un Sistema è la struttura organizzativa, le responsabilità, le procedure, i procedimenti e le risorse messi in atto per la conduzione aziendale della qualità. Il Sistema è documentato dal Manuale della, ma anche dalle procedure e dai documenti operativi (regole, standards, formati etc ) in uso presso l organizzazione. Fornitore: Organizzazione che fornisce un prodotto od un servizio ad un cliente, in termini regolati da un contratto. (ISO 12207) Servizio: Risultati di attività svolte per soddisfare le esigenze del cliente. (ISO 9004/2) 6.-9 6.-10 Un modello per la qualita : ll Capability Maturity Model (CMM) Il Capability Model (*) è un modello di riferimento per valutare il livello di maturità del processo produttivo del software. Esprime l organizzazione di riferimento dei processi di sviluppo e manutenzione del software Descrive quali passi occorre intraprendere per passare da un processo non definito e instabile ad un processo maturo e specificato Il livello di maturità di una organizzazione consiste nell aver definito in modo ripetibile tutte le fasi del processo di sviluppo del sw (*) Il CMM è stato sviluppato dal Software Engineering Institute sotto l egida del Dipartimento della Difesa americano con l obiettivo di migliorare la manutenibilità del sw La struttura del modello 5. Optimizing 4. Managed 3. Defined 2. Repeteable 1. Initial Gestione Gestione processo Review Coordinamento tra gruppi Training program... Configuration Management QA Gestione terze parti Project management Project Planning Gestione Requisiti Gestione del cambiamento del processo e della tecnologia Prevenzione dei difetti ordinare il caos Parole chiave Gestire il cambiamento Prevenire i difetti del prodotto e del processo Ingegnerizzare il processo Gestire i progetti Gli eroi 6.-11 6.-12
La struttura del modello - interventi chiave La struttura del modello: Il passaggio dal livello 1 al 2 Livelli 5 Ottimizzato 4 Gestito 3 Definito 2 Ripetibile 1 Iniziale Focus Miglioramento Continuo di prodotto e processo Ingegnerizzazione di Processo Project Management Gli Eroi Aree chiave di intervento Process change management Technology change management Defect Prevention Software quality management Quantitative process management Peer Reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Software configuration management Software quality assurance Software subcontract management Software project tracking & oversight Software project planning Requirements management Risultati Produttività e R I S C H I O E caratterizzato dalla attivazione dei seguenti processi: Configuration Management Verifica della qualità Gestione dei rapporti con le terze parti Pianificazione progetto e stime Gestione progetto Gestione Requisiti 1. Initial 2. Repeteable Le modalità di gestione del progetto applicate sono frutto dell esperienze di successo precedenti E possibile ripetere esperienze di successo Il progetto è sotto un controllo reale ed è basato su piani realistici verificati con l esperienza L ambiente di sviluppo è instabile Significativa difficoltà di gestione del progetto, dalla qualità alla documentazione. Gli standard se esistono sono ignorati Il successo dei progetti è determinato dall abilità di alcune persone ( gli eroi ) Difficoltoso controllo delle risorse e della loro produttività. 6.-13 6.-14 La struttura del modello: Il passaggio dal livello 2 al 3 La struttura del modello: Raggiungimento livelli 4 e 5 E caratterizzato dalla attivazione di: Procedure e standard formalizzati che vengono adattati al singolo progetto Ispezioni metodiche del codice e delle specifiche Coordinamento tra gruppi standardizzato Training plan per il team 3. Defined 2. Repeteable Procedure e standard per lo sviluppo del sw e la gestione progetto sono istituzionalizzate e mantenute da un gruppo specializzato Sono definiti ruoli, responsabilità e attività in modo tale da tenere sotto controllo piani, costi, qualità e funzionalità. Analisi dei difetti e delle cause che gli hanno generati Le nuove tecnologie sono introdotte nell organizzazione senza turbare gli equilibri raggiunti Anche il miglioramento continuo è proceduralizzato Controllo della produttività su specifiche attività all interno delle fasi Controllo della qualità su specifici prodotti e processi 5. Optimizing 4. Managed 3. Defined Miglioramento continuo: processi tecnologia qualità produttività Vengono posti obiettivi di produttività e qualità Sono definiti strumenti per il controllo degli obiettivi Anche il controllo della qualità e della produttività è istituzionalizzato 6.-15 6.-16
Statistiche su aziende produttrici di SW Valutazioni svolte in USA, aggiornate al novembre 1998, su 542 organizzazioni hanno dimostrato che, : 67,2% sono al livello 1 19,8% al livello 2 11,6% al livello 3 1,0% al livello 4 0,4% al livello 5 (Reliability) Portabilità (Portability) Efficienza (Efficiency) (Testability) Comprensibilità (Understandability) Modificabilità (Modifiability) 6.-17 6.-18 Efficienza Portabilità Efficienza Fattori talvolta sopravvalutati Non sempre serve sofware multiplatform Efficienza: rapporto fra prestazioni e quantità di risorse utilizzate, in condizioni normali di funzionamento (il software usa bene le risorse disponibili); attributi: Comportamento rispetto al tempo: tempi di risposta e di elaborazione richiesti per eseguire le funzioni richieste. Uso di risorse: quantità di risorse usate e durata di tale uso per eseguire le funzioni richieste. Le macchine odierne sono molto veloci (IBM 3090/600= 100 mips!) 6.-19 6.-20
Manutenibilità Manutenibilità: impegno richiesto per modificare il software (il software segue l evoluzione dell organizzazione); attributi: Analizzabilità: impegno richiesto per diagnosticare carenze o cause di fallimento, o per identificare parti da modificare. Cambiabilità: impegno richiesto per modificare, rimuovere errore o sostituire componenti. Stabilità: rischio di comportamenti inaspettati a seguito di cambiamenti. Provabilità: impegno richiesto per validare le modifiche apportate al software. Due tipi di test: Verifica: Validazione: controllare che il softare risponda alle specifiche controllare che il software faccia correttamente ciò che ci si aspetta (né di meno, né di più) 6.-21 1995 Andersen Consulting 6.-22 Il Ciclo di gestione di impresa I Test: Successione dei test: TEST 1 Sistema Procedura/ transazione Ambiente Release 1 Release 2 Prodotto SW Aggiornamento Prodotto SW Aggiornamento TEST 2 TEST 1 TEST 3 TEST 2 TEST 1 PGM Release 3 Prodotto SW UNIT TEST (programmatori) SYSTEM TEST (programmatori, progettisti, analisti, utenti) REGRESSION TEST TEST DI PROCEDURA (programmatori e progettisti) USER TEST (utenti, analisti) Programma modificato= test nuovi più tutti i test vecchi Le modifiche non debbono compromettere le funzionalità esistenti (non regressione) 6.-23 6.-24
Copertura topologica: tutti i rami di tutti i programmi vengono testati I costi: Dati prova Costo Globale PGM Costo/ test Numero test Output Risultato atteso 1 RISOLUZIONE: ITEM/TEST Test = confronto Massima garanzia Massimi costi Massimo sforzo di preparazione dei dati Troppo test alza i costi di progetto oltre il tollerabile Non è sempre possibile creare il risultato atteso La qualità non si può otenere solo via test 6.-25 6.-26 Comprensibilità QUANDO GLI ERRORI SONO TROVATI ANTICIPATAMENTE Modificabilità Costo= 400 errori x 2 GU ERR = 800 GU Hughes Project Esperienza 400 errori ²= 4400 GU È il parametro più importante Testing con supporto di tools QUANDO GLI ERRORI SONO SCOPERTI TARDI Tasso di reperimento errori Approccio standard al testing COSTA INTEGRAZ. OPER. Costo= 200 errori GU x 2 (4) ERR 10 x 200 errori GU x 2 (9) ERR = 5200 GU 9 È il parametro più difficile da definire Oggi non esistono misure universali per l affidabilità del software t Costo 5 4 relativo per Rispetto l intero sistema e le sue componenti Provocano costi aggiuntivi in sviluppo correggere l errore 1 1 Spianano la strada in manutenzione COSTA INTEGRAZ. OPER. Per l utente: miglior sfruttamento del sistema (conversazioni più facili, parametrazioni più spinte) 6.-27 6.-28
: la sicurezza che un sistema faccia ciò che si aspetta Per l utente: non dover controllare i risultati dell elaborazione per l utente per il DP Per il DP: procedure trasparenti transazioni tranquille poche cadute per l azienda Per l azienda: budget ridotto alla voce miglioramento e consolidamento procedure 6.-29 6.-30 Tre leggi: Tre leggi: 1. Un programma viene modificato sempre più frequentemente fin quando l ennesima modifica costa più del rifacimento 2. Le modifiche al software ne aumentano sempre dimensioni e complessità PGM PGM PGM PGM1 T 0 PGM1 T n Call Call PGM2 PGM2 PGM PGMA if go to exit exit2 Call - + Manutenzione - 6.-31 + Cose - Ordine - 6.-32
Tre leggi: 3. La frequenza e la qualità delle modifiche dipendono in modo costante dalla qualità del progetto iniziale e dal tempo trascorso Cioè Esempio di criteri: per la manutenzione difetti del codice - n degli interventi di manutenzione correttiva svolti su una specifica applicazione rapportato al n tot. dei Function Point (o LOC) costituenti quella applicazione difettosità residua nel codice realizzato, con un valore soglia accettabile intorno a 0,1 FP/anno (si intende il numero degli errori applicativi sul volume del prodotto operativo, in FP, calcolati ad una certa distanza dal rilascio); Fraction of Modules Handled 1,0 0,8 0,6 0,4 0,2 I sistemi nati bene sopravvivono meglio al tempo livello di documentazione, con un valore di riferimento per singolo modulo non inferiore al 30-35% del totale delle LOC (linee di codice) ; strutturazione, con obiettivo il 100% per il codice più recente, valore medio 80%, misurato attraverso assenza di go to o istruzioni equivalenti o % di strutture 1Input 1Output livello di obsolescenza del patrimonio sw (decremento annuo dell età dei sorgenti pari ad un minimo annuo, ad es 10%); manutenibilità, ottenuto a partire da misure elementari prelevate su ciascuno dei sorgenti modificati (es. indice di Mc Cabe) 0 0 500 1000 1500 2000 2500 3000 3500 4000 Age in Days 6.-33 6.-34 Esempi di livelli di servizio: per l assistenza all utenza Disponibilità del servizio [tutti i gg. lav. dalle 9 alle 17] Conclusioni Help desk: n. medio di squilli prima di ottenere risposte -max 4 % di chiamate che vengono messe in coda dall operatore e tempo di attesa in coda -10% max per 90 sec. max % di chiamate che non vengono prese dall operatore - 2% max Ricezione chiamate al 1 livello - 95% entro 30 secondi - 10% entro un ora I sistemi evolvono in modo continuo Dal concepimento Alla morte Capacità di risoluzione dei problemi [su sw applicativo = 90% in 4 gg, 10% in 6gg ; su disallin. banche dati = 16 ore 80%, 32 ore 20% ; per rich. informative = 80% in 4 ore, 20% in 1 g; su problemi legati alla conduz.tecnica = non inf. al 95%, 10% in 1h, 40% in 4h, 35% in 2gg, 5% in 5gg, 5% da definire] (da graduare per importanza progetto) Tempestività dell assistenza [problema definito ed inserito nel processo di gestione dei problemi entro 1 ora 90% dei casi, 1 g. nel 10 %] % Richieste di intervento evase sul totale delle richieste La loro complessità aumenta in modo sempre più veloce Investire in qualità: Ritarda il degrado Diminuisce i costi di esrecizio Aumenta la vita utile 6.-35 6.-36