Modelli e Metodi per la Qualità del Software - PDF

Modelli e metodi per la qualità del Software Riassunto del materiale didattico Introduzione al Corso Il corso di Modelli e metodi per la qualità del Software ha come obiettivo formativo quello di costituire conoscenze ed abilità per il management dell’Ingegneria del Software dove: 1. Le conoscenze sono le tecniche e i metodi alla base del concetto di qualità del Software: a. Modelli di processo di sviluppo del Software; b. Qualità dei processi, dei prodotti e loro relazione; c. Controllo qualità; d. Qualità come strumento di impresa, dalla certiﬁcazione al ra orzamento competitivo (ISO, CMMI). 2. Le abilità sono le pratiche per applicare le conoscenze e trasformare in tecnologia i loro contenuti: a. Modellare, veriﬁcare e validare processi; b. Costruire modelli di qualità e piani metrici; c. Monitorare progetti sulla base di modelli di qualità al ﬁne di individuare iniziative di miglioramento continuo. 3. Con Management dell’Ingegneria del Software si intende il governo della qualità dei processi e dei prodotti per lo sviluppo di Software “senza sorprese” ottimizzando i costi. La qualità del software ha due componenti in interrelazione tra di loro: la qualità dei processi software e la qualità dei prodotti software. Introduzione alla qualità La qualità è un termine ambiguo con tante diverse interpretazioni. È infatti un concetto multidimensionale le cui dimensioni sono:  L’entità di interesse;  Il punto di vista che abbiamo di tale entità;  Attributi di qualità che misurano e caratterizzano tale entità. Ci sono diversi livelli di astrazione per il concetto di qualità. Può capitare, infatti, di parlare di qualità nel senso più ampio del termine e, in altri casi, ci serviamo di questo concetto per indicare un aspetto speciﬁco di un prodotto. Il concetto di qualità è ampiamente utilizzato nella nostra vita quotidiana e, di fatti, è opportuno indicare due principali prospettive:  Una prospettiva popolare, che vede la qualità come una caratteristica immateriale e intangibile sulla quale è possibile esprimere opinioni e giudizi, ma non concretamente misurabile: o Si parla spesso di buona o cattiva qualità, così come di qualità della vita. Spesso un prodotto viene deﬁnito di qualità se lussuoso, soﬁsticato, costoso o di buon gusto.  Una prospettiva professionale che, invece, deﬁnisce la qualità rispetto alla conformità di un prodotto con determinati requisiti chiaramente deﬁniti. Ciò, quindi, implica che le esigenze degli utenti e le aspettative sono note sin dall’inizio e che, la non conformità dei requisiti, rappresenta un difetto. 1 La qualità del Software Il signiﬁcato più comune di “software di qualità” è che quest’ultimo non ha difetti (bug) di carattere funzionale. Per esprimere questa deﬁnizione si adottano misure/metriche [quantitative e qualitative]: ° °  Tasso di difetti: / oppure ; °  A idabilità: ° , tempo medio tra i fallimenti;  Soddisfazione degli utenti: % di utenti soddisfatti (misurata attraverso indagini). Secondo l’ISO, con qualità del software si deﬁnisce l’insieme di proprietà e di caratteristiche desiderate per un processo, un prodotto, un servizio software allo scopo di soddisfare il committente (attraverso requisiti impliciti o espliciti), realizzare il ritorno economico degli investitori e realizzare trade-o tra qualità tecnica, costo e tempo di esecuzione del processo. La misurazione della qualità ha come scopo quello di catturare le informazioni sugli attributi delle entità. Un’entità è un oggetto o un evento del mondo reale descritto attraverso caratteristiche speciﬁche. Un attributo è un aspetto o una proprietà speciﬁca di un’entità. Qualità funzionali Qualità strutturali Grado di soddisfazione dei requisiti Grado di soddisfazione dei requisiti non funzionali, valutato tramite testing. funzionali da parte dell’architettura, valutato mediante analisi architetturali. Misurare la qualità Non puoi controllare quello che non puoi misurare! -Tom DeMarco La qualità di un prodotto software è la misura in cui il prodotto soddisfa la sua speciﬁca. La misurazione della qualità è fondamentale durante l’intero ciclo di vita del software. Le entità visibili e misurabili sono i processi (attività), le risorse impiegate e alcuni attributi dei prodotti. È possibile suddividere gli attributi di qualità in due categorie:  Attributi esterni, visibili all’utente;  Attributi interni, visibili agli sviluppatori. Introdurre la qualità Perché il software è difettoso? Gli esseri umani commettono errori inevitabilmente, soprattutto quando svolgono compiti complessi. Di seguito sono individuate le tre categorie di problemi nel software.  Failure: comportamento del software non previsto dalla sua speciﬁca;  Fault: difetto del sorgente (bug), causa di un failure;  Error: errori che causano difetti, come ad esempio un errore umano d’interpretazione della speciﬁca o nell’uso di un metodo. ERROR FAULT FAILURE 2 Assicurare la qualità del software è un processo complesso e costoso, che richiede attività speciﬁche come il testing, metodi orientati alla qualità del prodotto (es. Cleanroom) e standard di qualità (es. ISO9000). La valutazione della qualità parte dagli obiettivi di chi la e ettua, i quali devono essere tradotti in domande speciﬁche e metriche capaci di quantiﬁcare le qualità richieste. Le metriche devono essere coerenti con i goal dell’organizzazione e utili per il miglioramento continuo, considerando i punti di vista di tutte le parti coinvolte (sviluppatori, utenti, progettisti). Per pianiﬁcare un modello di qualità del software, si seguono alcuni passi fondamentali: deﬁnire gli obiettivi (goal) e le relative metriche, trasformarli in domande che li rendano quantiﬁcabili, speciﬁcare le misure adeguate, sviluppare meccanismi operativi per collezionare le misure e raccogliere i dati e analizzarli per identiﬁcare criticità e miglioramenti. Inﬁne, un'analisi post-mortem consente di valutare l’intero processo e perfezionarlo per il futuro, garantendo un miglioramento continuo della qualità del software. Veriﬁca e validazione Con veriﬁca si intende il confronto di un prodotto con la sua speciﬁca (requisiti). La validazione rappresenta l’accettazione del prodotto da parte del committente. L’attività di veriﬁca, così come quella di documentazione, non è una fase separata dal processo. È opportuno che essa sia e ettuata da persone diverse da quelle coinvolte nel design o nella codiﬁca. Ogni documento prodotto dovrebbe essere controllato (possibilmente da persone diverse dagli autori) e a sua volta documentato. Esistono due tipi di veriﬁca:  Ispezione/code review: basata sull’analisi statica;  Testing, basata sull’analisi dinamica (esecuzione). Costo della qualità (ISO) Come già accennato, produrre software di qualità non è solo complesso, ma anche costoso. I costi della qualità nel processo produttivo sono i costi che si sostengono per adeguare la qualità del prodotto alla qualità richiesta. Tra i costi della qualità deﬁniamo due categorie: il costo per fare bene le cose (conformità) e il costo per rimettere a posto le cose sbagliate (non conformità).  Costo della conformità (COC): sono i costi che hanno come obiettivo quelli di soddisfare tutte le esigenze esplicite e implicite. Si suddividono in: o Costi di prevenzione: oneri sostenuti per prevenire gli insuccessi; o Costi di accertamento: oneri per controlli e collaudi.  Costo della non conformità (CNC): sono i costi dovuti agli insuccessi, e si dividono in: o Costi per insuccessi interni: oneri connessi a un prodotto che non soddisfa i requisiti di qualità prima ancora della sua consegna; o Costi per insuccessi esterni: oneri connessi a un prodotto che non soddisfa i requisiti di qualità dopo la sua consegna (costi per la manutenzione, la riparazione, i resi, il richiamo dei prodotti…). Glossario delle attività legate alla qualità  Testing: processo di investigazione sui rischi connessi all’esecuzione di un sistema software;  Misurazione: indicatori di qualità sia mediante esecuzione che mediante ispezione;  Veriﬁca: analisi delle funzioni rispetto alla speciﬁca;  Validazione: accettazione da parte degli stakeholder;  Certiﬁcazione: analisi delle funzioni rispetto ai requisiti di legge. 3 Introduzione alla misurazione e il suo legame con la Qualità Cosa si intende per misurazione? La misurazione ci aiuta a comprendere il mondo, a interagire con l’ambiente circostante e a migliorare la nostra vita. Essa dovrebbe essere una parte naturale delle attività di sviluppo e manutenzione del software. Individuiamo le seguenti ﬁgure:  Sviluppatori software: misurano le caratteristiche del software per capire se i requisiti sono coerenti e completi, se il design è di qualità e se il codice può essere testato;  Project Manager: misurano il processo e gli attributi del prodotto per essere in grado di sapere quando avverrà la consegna, se il budget è stato superato, se il piano di progetto è stato rispettato;  Clienti: misurano gli aspetti del prodotto ﬁnale per vedere se è conforme alle aspettative di qualità e se sono soddisfatti i requisiti (se il software fa quello che deve);  Manutentori: valutano il prodotto ﬁnale per vedere cosa aggiornare e/o migliorare. Passiamo ora alla deﬁnizione di misurazione. La Misurazione è il processo attraverso cui numeri vengono assegnati a entità del mondo reale in modo tale da determinarne il valore secondo caratteristiche ben deﬁnite. La misurazione cattura informazioni sugli attributi delle entità. Un’entità è un oggetto o un evento del mondo reale, mentre un attributo rappresenta una sua proprietà o caratteristica. La misurazione descrive l’entità identiﬁcando le caratteristiche (attributi) che sono importanti per distinguere un’entità da un’altra. Quando deﬁniamo entità attraverso gli attributi, ci serviamo di numeri e simboli per rappresentare/riﬂettere le nostre percezioni del mondo reale. Potremmo quindi trarre conclusioni su una entità (oggetto) basandoci sui valori dei suoi attributi (caratteristiche di qualità). La misurazione rende i concetti più comprensibili e controllabili. Nell’ingegneria del software, gli attributi (a idabilità, usabilità, manutenibilità) vengono quantiﬁcati mediante speciﬁci indicatori/metriche che consentono di misurarli. Si individuano due tipi di quantiﬁcazioni:  Quantiﬁcazione diretta, misurazione: o Altezza, peso, dimensione di un programma software in LOC…  Quantiﬁcazione indiretta, calcolo: o Si considerano le misure e le loro combinazioni in un elemento quantiﬁcato che riﬂette l’attributo oggetto di attenzione. La valutazione è quindi una quantiﬁcazione, non una misurazione, e avviene mediante l’utilizzo di formule matematiche. Calcolo e misurazione in ingegneria del software si esprimono attraverso un punteggio complessivo basato su una serie di misure, ciascuna delle quali cattura un aspetto di ciò che si vuole misurare. L’ingegneria del software è una disciplina uomocentrica (a di erenza di altre discipline ingegneristiche che usano sistematicamente metodi basati su modelli e teorie) e descrive l’insieme delle tecniche che adottano un approccio ingegneristico per la costruzione e il supporto del software. Con “approccio ingegneristico” si intende che ogni attività è compresa e controllata al ﬁne di ridurre imprevisti durante tutte le fasi della produzione del software. Le attività di Software Engineering includono gestione, costi, pianiﬁcazione, modellazione, analisi, speciﬁca, progettazione, implementazione, veriﬁca e manutenzione. Nell’ingegneria del software, la misurazione è spesso considerata un lusso e non viene applicata in modo sistematico. Questo porta a diverse problematiche, a partire dall'incapacità di deﬁnire 4 obiettivi misurabili per i prodotti software. Spesso si promettono caratteristiche come usabilità, a idabilità e manutenibilità senza speciﬁcare chiaramente cosa signiﬁcano e come possono essere misurate. Di conseguenza, non è possibile sapere con certezza se gli obiettivi siano stati e ettivamente raggiunti. Un'altra criticità riguarda la scarsa comprensione e quantiﬁcazione dei costi di un progetto software. Spesso non si distingue tra costi di progettazione, codiﬁca e test, rendendo di icile controllare e ottimizzare le spese. Senza questa distinzione, non si può sapere se si sta spendendo troppo in una determinata fase del progetto. Allo stesso modo, la qualità dei prodotti software non viene quantiﬁcata o prevista con precisione. Non si è in grado di fornire agli utenti un'idea chiara dell'a idabilità del software in termini di probabilità di failure durante un determinato periodo di utilizzo. Un'altra problematica è l'adozione di nuove tecnologie basandosi su prove aneddotiche e materiale promozionale, senza uno studio empirico rigoroso che ne valuti l’e icacia e l’e icienza. Ciò porta a investimenti incerti, di cui non si conosce il reale valore. Inﬁne, le misurazioni, quando vengono e ettuate, risultano spesso infrequenti, incoerenti e incomplete. Questo le rende poco utili, perché senza una chiara comprensione dei metodi utilizzati, delle entità misurate e dei valori di riferimento, è impossibile applicarle correttamente o ripeterle in altri contesti. La mancanza di misurazione nell’ingegneria del software è aggravata dalla mancanza di un approccio rigoroso. Obiettivi della misurazione del software La misurazione serve per valutare lo stato dei progetti, dei prodotti, dei processi e delle risorse. È importante misurare e registrare le caratteristiche di progetti buoni e cattivi per interpretare i risultati, individuare i problemi, intraprendere azioni correttive e ottenere evidenze sui cambiamenti. I progetti vanno controllati, non solo eseguiti. Le iniziative di misurazione devono essere motivate da uno scopo o da un’esigenza speciﬁca. Un obiettivo (measurement goal) deve essere speciﬁco e legato a quello che gli stakeholder devono sapere. Gli obiettivi possono di erire in base agli stakeholder coinvolti, al livello di sviluppo e di utilizzo del software. 5 Misurazione: prospettiva del Manager Misurazione: prospettiva dell’ingegnere Interesse su aspetti di costo/produttività Interesse su aspetti legati ai prodotti Dal punto di vista di un manager, la misurazione è software sviluppati fondamentale per valutare costi, produttività e qualità Dal punto di vista dell’ingegnere, un del software. Si analizza il costo del processo di sviluppo, primo aspetto da valutare è la misurando il tempo e lo sforzo impiegati in ogni fase, dalla veriﬁcabilità dei requisiti, ovvero raccolta dei requisiti al testing, per avere una visione assicurarsi che siano espressi in modo complessiva del progetto. misurabile e ripetibile in diversi Si misura la produttività del personale, che si valuta contesti. analizzando il tempo impiegato nelle varie attività e Un altro obiettivo è l’individuazione di raccogliendo dati sulle speciﬁche, sul codice e sui test. tutti i difetti, tracciandone le cause e Questi dati permettono di stimare i costi e la durata delle valutando l’e icacia di ispezioni e test attività future. per capire se il prodotto può passare La qualità del codice viene monitorata registrando fault, alla fase successiva. Inoltre, è failure e modiﬁche, così da poter confrontare prodotti fondamentale veriﬁcare se gli obiettivi diversi, prevedere gli e etti di eventuali modiﬁche e di qualità del prodotto e del processo migliorare processi e prodotti. sono stati raggiunti, monitorando e Allo stesso modo, la soddisfazione dell’utente viene controllando costantemente i parametri valutata veriﬁcando se i requisiti sono stati implementati misurati. correttamente e analizzando fattori come usabilità, Inﬁne, la misurazione aiuta a a idabilità e tempi di risposta. pianiﬁcare i passi successivi: Inﬁne, per apportare miglioramenti, è necessario analizzando i dati storici dei prodotti e raccogliere e interpretare dati, confrontarli con obiettivi dei processi, è possibile fare previsioni e preﬁssati e utilizzare queste informazioni per ottimizzare mantenere un livello di qualità costante sia il processo di sviluppo che la qualità del prodotto. nel tempo. La misurazione del software e l’interpretazione dei dati raccolti vengono svolti essenzialmente per tre scopi: La misurazione aiuta a comprendere meglio lo sviluppo e la manutenzione del software, valutando la situazione attuale e Comprendere stabilendo valori soglia (baselines) per definire strategie future. (understand) Inoltre, rende più visibili gli aspetti critici del processo e del prodotto, permettendo di capire meglio le relazioni tra le attività e le entità che impattano. La misurazione permette di controllare l'andamento dei progetti, identificando le relazioni tra le variabili di processo. Controllare Sulla base delle baselines, degli obiettivi e della relazione tra (control) valori rilevati e valori obiettivo, è possibile fare previsioni e apportare modifiche ai processi e ai prodotti per garantire il raggiungimento degli standard di qualità. La misurazione aiuta a migliorare i processi e i prodotti analizzando i dati raccolti nel tempo e identificando tendenze. Permette di incrementare la produttività, ad esempio Migliorare (improve) valutando l’efficacia di nuovi strumenti, e di adeguare gli standard di qualità alle esigenze del mercato. Inoltre, i dati raccolti non servono solo per valutare il processo, ma anche per individuare aree critiche e definire azioni correttive mirate. 6 Sfaccettature della misurazione: una panoramica Stima di Costo ed E ort Modelli per la stima dei costi e dell’e ort sono stati proposti nell’ambito reliability del software (COCOMO, SLIM, Albrecht FP) come strumento quality utilizzato dai manager per prevedere i costi di progetto defects durante le fasi iniziali del ciclo di vita del software. Nei value modelli di stima l’e ort è espresso come funzione di una size o più variabili come la dimensione del prodotto o la quantity functionality capacità degli sviluppatori. La dimensione del prodotto può essere espressa in linee di productivity time codice o numero di function points. personnel money Modelli e misure di produttività Sono state proposte misure e modelli per valutare la hardware produttività del personale durante diversi processi cost resources software e in diversi ambienti. Per farlo, vengono software identiﬁcati fattori misurabili che inﬂuenzano la produttività environmental complessiva, considerando sia il valore prodotto sia i costi constraints complexity sostenuti. problem difficulty Raccolta dati La raccolta dei dati implica che le misure siano deﬁnite in modo inequivocabile e che la raccolta sia consistente e completa, in modo che l’integrità dei dati non sia a rischio. È importante che la raccolta dei dati di misura sia pianiﬁcata prima di essere eseguita. I dati raccolti possono essere rappresentati attraverso graﬁci per mostrare progressi ed evidenziare problemi nei processi produttivi e nei prodotti. La raccolta dei dati è essenziale per l’indagine scientiﬁca sui rapporti causali e sulle tendenze. Modelli e misure di qualità La produttività è strettamente legata alla qualità del prodotto. La velocità di produzione non è signiﬁcativa se non è legata alla valutazione di qualità del prodotto. I modelli di qualità sono strutturati in maniera gerarchica (ad albero), con i rami superiori che rappresentano fattori di qualità di alto livello, ognuno di questi suddiviso in fattori di livello più basso. Sono proposte metriche/indicatori per i criteri. 7 Management attraverso metriche La misurazione sta diventando una parte fondamentale del project management. Manager e sviluppatori si a idano a tabelle e graﬁci measurement-based per tracciare il progresso di un progetto e veriﬁcare se lo stesso rispetta la tabella di marcia (on track). Le aziende e le organizzazioni deﬁniscono standard di misura e metodi di reporting per controllare e confrontare i progetti (Work Breakdown structure charts, Gantt charts, PERT diagrams, Earned values). La Misurazione nel Software Perché misurare? Ci sono quattro motivi principali per misurare processi, prodotti o risorse software:  Caratterizzare: comprendere i processi, i prodotti, le risorse, gli ambienti e stabilire baselines (valori soglia) di confronto per le valutazioni future;  Valutare: determinare lo stato di avanzamento rispetto ai piani di progetto, stabilire il raggiungimento degli obiettivi di qualità e valutare l’impatto dei miglioramenti e delle tecnologie sui prodotti e sui processi stessi;  Fare previsioni in modo da poter pianiﬁcare opportunamente: comprendere le relazioni e le interdipendenze tra processi e prodotti consente di costruire modelli basati su questi legami, in modo da utilizzare i valori osservati di alcuni attributi per prevederne altri. Questo approccio permette di estrapolare tendenze, stimare costi, tempi e qualità, nonché di identiﬁcare i trade- o basati su dati storici;  Migliorare: raccogliere informazioni quantitative per poter identiﬁcare ine icienze e opportunità per migliorare la qualità dei prodotti e le prestazioni di processo. Misurare aiuta a pianiﬁcare e a monitorare gli sforzi di miglioramento. Gli elementi della misurazione Riprendiamo la deﬁnizione di misurazione già citata in precedenza, dettagliandola ulteriormente: La misurazione è il processo attraverso cui numeri e simboli sono assegnati agli attributi di entità del mondo reale in modo da caratterizzare gli attributi attraverso regole chiaramente speciﬁcate. Per misurare è quindi necessario identiﬁcare le entità (oggetti di interesse), gli attributi (caratteristiche) e le regole/metriche (e scale) che saranno usate per assegnare valori a ciascun attributo. Entità Attributi Elementi del mondo reale che Caratteristiche o proprietà delle entità. desideriamo misurare:  Person (entity):  Products, processes, resources… o Characterisics: height, eye color, IQ, age,  Artifacts, activities, agents… years of experience…  Organizations, environments,  Software (entity): constraints… o Characteristics: size, cost, elapsed time, Entità possono essere anche gruppi o e ort, response time, transaction rates, insiemi di altre entità: number of defects…  Subprocesses, ﬂowpaths, by- L’arte della misurazione consiste nel decidere quali products… attributi usare in modo da fornire una chiara idea delle entità considerate. 8 Ciascuna entità è legata agli attributi che la caratterizzano e alle misure che possono essere usate per quantiﬁcarli. Scale di misurazione e funzioni statistiche La scala di misurazione fornisce i valori e le unità per descrivere gli attributi. Possiamo infatti esprimere l’altezza di una persona in centimetri e il suo peso in kilogrammi. Allo stesso modo possiamo descrivere un progetto software come segue:  Software project: o Produce 30.000 LOC o Planned completion date: August 30th o Use: 11.345 sta hrs of e ort o Application type: real time command and control o […] Ovunque si e ettui una misurazione e qualunque sia la sua forma, c’è sempre bisogno di scale ben deﬁnite per rilevare e registrare i valori misurati. Possiamo distinguere diverse tipologie di scale:  Nominale: ogni valore della scala rappresenta una classe o una categoria di appartenenza: o NON c’è ordinamento tra i valori; o NON c’è signiﬁcato di grandezza. Le scale nominali pongono gli elementi in categorie di appartenenza, le quali non sono ordinate ma possono essere numerate (per scopi di identiﬁcazione) da 1 a n. Esempio: 1 if speciﬁcation fault, 2 if design fault, 3 if code fault.  Ordinale: è nominale ed esprime un ordine ascendente o discendente tra tutti i possibili valori. La distanza tra un elemento e un altro della scala non ha signiﬁcato: 9 o Le classi di appartenenza dei valori sono ordinate; o I valori esprimono solo un punteggio (rank), non è quindi possibile e ettuarvi operazioni aritmetiche. Esempio: 1 if simple; 2 if moderate; 3 if high; 4 if incomprehensible.  Intervallo: esprime sia l’ordinamento che la misura dell’intervallo che separa le classi: o Preserva l’ordine (come per una scala ordinale); o È possibile e ettuarvi operazioni di somma e sottrazione, non hanno quindi senso moltiplicazione e divisione; o Non vi è un valore di origine nella scala (zero assoluto):  Se la temperatura un giorno raggiunge i 40 gradi, mentre il giorno prima ammontava a 20, NON è possibile dire fa caldo il doppio rispetto al giorno precedente;  Allo stesso modo, una temperatura di 0 gradi non indica un’assenza di temperatura. Esempi: clock times, date di calendario, temperatura in °C o °F.  Ratio: aggiunge un’origine alla scala, ovvero un elemento zero o NULL: o Preserva l’ordinamento, la dimensione degli intervalli e il rapporto tra le entità; o Esiste un elemento zero signiﬁcativo che indica l’assenza di quell’attributo; o Il valore dell’attributo parte dallo zero e aumenta a intervalli uguali detti unità di misura; o Tutte le operazioni aritmetiche sono signiﬁcative; o Due scale ratio M e M1 sullo stesso attributo (es. dimensione) sono convertibili con la relazione M=a*M1 dove a indica una costante:  From Feet to Inches: I=12*F;  From KLOC to LOC: KLOC=1000*LOC;  M=LOC; M1=lunghezza in numero di caratteri: M1=a*M con a che rappresenta la quantità media di caratteri per LOC. Esempio: productivity, defect density, integration cost, development cost, e ort… Esempio: la dimensione di un programma è misurata in LOC secondo la scala m1; la dimensione in KLOC è un’altra scala m2 dove m2=1000*m1.  Assoluta: è un caso particolare della scala ratio dove l’unico moltiplicatore ammissibile è 1: o La misurazione è ottenuta solo e soltanto contando gli elementi di un’entità (es. numero di persone in un’aula); o L’attributo ha sempre forma del tipo “numero di occorrenze di x”; o Tutte le operazioni aritmetiche sono signiﬁcative. Esempio: number of failures observed during integration testing; number of people working on the project; number of design defects… Ha signiﬁcato applicare funzioni statistiche ad un tipo di scala se le a ermazioni dedotte dall’applicazione di tali funzioni sono invarianti rispetto alla scala utilizzata. TIPO DI SCALA FUNZIONI STATISTICHE SIGNIFICATIVE Nominale Moda Ordinale Moda, mediana Intervallo Moda, mediana, media Ratio Tutte le funzioni Data una lista di valori:  Si deﬁnisce media la somma dei valori diviso per il numero di valori nella lista;  Si deﬁnisce mediana il valore centrale della lista ordinata;  Si deﬁnisce moda il valore che si presenta più frequentemente nella lista. 10 Le scale di misurazione possono cambiare man mano che si matura esperienza. Le misurazioni possono passare da scale più basse a scale più alte quando società, organizzazioni e pratiche maturano. È importante ricercare opportunità che permettano di evolvere le pratiche di misurazione verso scale che o rono informazioni più dettagliate. Misure Soggettive e Oggettive Quando si misurano gli attributi ci sforziamo di mantenere le misurazioni il più oggettive possibili. Durante il processo di misurazione, assicuriamo che persone diverse producano le stesse misure, indipendentemente dal fatto che stanno misurando prodotti, processi o risorse. Alcune misurazioni sono più oggettive di altre.  Misure soggettive: dipendono dal misuratore, sono strettamente legate al contesto in cui sono rilevate. Possono variare al variare del misuratore e dipendere dalla sua opinione. Esempi: o Programmer experience (high. medium, low); o Quality of requirements (1-5 scale).  Misure oggettive: sono indipendenti dal misuratore e vengono rilevate oggettivamente e indipendentemente sulle entità. Il loro valore non è inﬂuenzato. Esempi: o Development time; o Number of LOC of a program/module; o Number of defects; o Productivity. Al ﬁne di contenere e limitare la soggettività delle misure soggettive, si deﬁnisce e associa un modello descrittivo alla metrica. Ogni valore della scala è quindi deﬁnito da una descrizione testuale per meglio chiarire e spiegare i range di valori e ridurre l’interpretazione soggettiva delle informazioni. Esempio: criticality of requirements (1-5 point scale) 1. not important (it does not impact on any user); 2. low importance (impacts on few users); 3. average importance (impacts on several users but does not determine consequences if it is not respected); 4. important (impacts on several users and determines consequences if it is not respected); 5. critical (if it is not respected, the system cannot be used). In caso di misure oggettive è necessario fornire un modello quantitativo (equazioni, modello di calcolo, formula) associato alla metrica. Esempio: Non conformance = (nr of violations / nr of times the techniques have been applied) * 100 Esempio: Temperature Range:  Low: in summer between 8-12 °C; in winter from -X to 11°C;  High: in summer above 13°C; in winter from 12°C and above. Misure Dirette e Indirette Una volta ottenuto il modello delle entità e degli attributi implicati è possibile deﬁnire le misure sulla base del modello stesso:  Measure height in cm;  Measure dimension of a room in m2;  Measure dimension of a program in LOC. Possiamo quindi deﬁnire misure dirette (osservate) e misure indirette (calcolate): 11  La misurazione diretta di un attributo non implica altri attributi in quanto è rilevato/osservato direttamente. Ad esempio: o Lenght of source code (in LOC); o Duration of testing phase (elapsed time in hrs); o Number of defects found during the testing process (count of defects); o Time a developer spends on a project (months worked).  La misurazione indiretta implica che un attributo sia misurato combinando misure in relazione tra loro secondo un modello di calcolo (modello quantitativo). Per esempio: o Programmer productivity: ; o Module defect density: ; o System spoilage:. La qualità è relativa Soglie dei valori Per soddisfare gli obiettivi di qualità richiesti le misure rilevate sui prodotti e sui processi devono raggiungere predeﬁnite soglie. Esse sono dipendenti dal contesto di esecuzione del processo e dal committente del prodotto. Normalmente si deﬁnisce un intervallo di successo entro i quali il processo/prodotto si considera abbia raggiunto l’obiettivo (Smin; Smax), e una soglia di insuccesso al di sotto della quale lo stesso prodotto/processo è rigettato (Sreject). Se si è raggiunti la soglia di insuccesso è indispensabile ricorrere a iniziative di miglioramento. Se ci si trova invece nell’intervallo di successo il management può decidere di migliorare il processo per far salire le soglie verso Smax, così come di stringere l’intervallo di successo per aumentare la capacità del processo. Se si sono raggiunte le soglie massime per tutte le misure, e i processi sono stabili, il management può decidere di far salire il loro valore per indurre maggiore maturità del contesto di esecuzione, spingendo per un miglioramento continuo. 12 Modelli e metodi per la qualità del Software Riassunto del materiale didattico Gestione della Qualità del Software Storia della Qualità e Qualità dei Progetti Secondo lo standard ISO 9000, la qualità è deﬁnita come l’insieme delle caratteristiche di un prodotto/servizio necessarie per soddisfare i requisiti preﬁssati. Negli ultimi vent’anni il concetto di qualità si è sempre di più focalizzato intorno alla soddisfazione dei clienti, i quali richiedono alte prestazioni dei requisiti, sviluppo rapido dei progetti, livelli di tecnologia più alti, materiali e processi spinti al limite e, per concludere, meno difetti. C'è stato un cambiamento culturale nella gestione della qualità: da un approccio reattivo, limitato agli operai e focalizzato sul contenimento dei costi, a un approccio proattivo e di uso in tutta l'organizzazione, con un'enfasi sulla prevenzione, la collaborazione e il valore per il cliente. Passato Presente  La qualità era responsabilità solo dei  La qualità è responsabilità di tutti, lavoratori operai; compresi impiegati e dirigenti;  I difetti venivano nascosti ai clienti (e  I difetti devono essere evidenziati per talvolta alla direzione); essere corretti;  I problemi di qualità portavano a colpe,  I problemi di qualità portano a soluzioni giustiﬁcazioni e scuse; cooperative;  Le correzioni dovevano essere fatte con  La documentazione è essenziale per il minimo di documentazione; evitare errori ripetuti;  Una maggiore qualità era vista come un  Una migliore qualità fa risparmiare e costo aggiuntivo; migliora il business;  La qualità era focalizzata internamente.  La qualità è focalizzata sul cliente;  Era necessaria una stretta supervisione  Le persone sono motivate a produrre per garantire la qualità; prodotti di qualità;  La qualità veniva gestita solo durante  La qualità deve essere pianiﬁcata ﬁn l'esecuzione del progetto. dall'inizio del progetto. La qualità è intesa sia come qualità di progetto che di prodotto, le quali sono strettamente legate tra di loro. Attraverso il miglioramento continuo dei processi si applicano lezioni apprese per ottenere prodotti e servizi migliori. Prima della Prima guerra mondiale la qualità era intesa fondamentalmente come ispezione, ovvero come selezione di elementi buoni rispetto ai cattivi. Dopo la guerra e sino agli anni ’50 iniziarono a emergere concetti di controllo di qualità, i quali consistevano in tecniche matematiche e statistiche, tabelle di campionamento e carte di controllo. Dagli anni ’50 agli anni ’60 il controllo qualità è diventato anche assicurazione di qualità (Quality Assurance) con maggiore enfasi sulla prevenzione piuttosto che sull’identiﬁcazione dei problemi. Oggi l’attenzione è posta sulla gestione della qualità quale fattore strategico includendo aspetti quali:  La qualità è deﬁnita dai clienti;  La qualità è legata alla redditività del mercato; 1  La qualità è parte integrante dei processi strategici di pianiﬁcazione;  La qualità richiede impegno da parte dell’intera organizzazione. Caratteristiche del Software e la loro relazione con la qualità La qualità rappresenta un concetto astratto, di erente dal resto dei prodotti di ingegneria in termini di tangibilità. I costi della qualità incidono principalmente sulle fasi di design/progettazione e non di produzione. La manutenzione è complessa, a di erenza di quanto si ritiene popolarmente (che sia facile fare modiﬁche o che il software con errori non venga rigettato). Evidenziamo due punti di vista/prospettive della qualità: Fornitore Cliente Il software sviluppato fa quello che deve  Riceviamo il prodotto adeguato agli fare; scopi e alle necessità che deve  I prodotti sviluppati svolgono adeguatamente ricoprire; le loro funzioni;  Siamo soddisfatti;  Sviluppiamo software che funziona  I prodotti soddisfano le correttamente dalla prima esecuzione; aspettative;  Costruiamo software in tempo e costi  Siamo trattati bene (integrità, previsti. cortesia, rispetto). Ciò che determina la qualità del software all’interno di un progetto sono i processi quanto le persone. Concetti di Gestione della qualità Il project manager è la ﬁgura con la maggiore responsabilità nella gestione della qualità del prodotto. Circa il 20-30% del lavoro del project o ice è attribuibile alla gestione della qualità. Ci sono sei concetti che supportano l’esecuzione di ogni progetto. 1. Politica di qualità Generalmente un documento elaborato da esperti di qualità e supportato dal top management. Esso stabilisce:  Obiettivi di qualità;  Livelli di qualità accettabili per l’organizzazione;  Le responsabilità di ciascun membro nell’applicazione delle politiche di qualità. 2. Obiettivi di qualità Consistono in obiettivi speciﬁci insieme all’intervallo di tempo entro cui svilupparli. Gli obiettivi devono essere perseguibili e fattibili in relazione con le capacità dell’organizzazione. Un buon obiettivo di qualità deve:  Essere perseguibile;  Deﬁnire a sua volta obiettivi speciﬁci;  Essere comprensibile;  Stabilire scadenze. 3. Assicurazione della qualità Con Quality Assurance ci si riferisce alle attività formali e ai processi manageriali che assicurano che i prodotti e servizi raggiungano/abbiano i livelli di qualità preﬁssati. La Quality Assurance assicura che lo scopo del progetto, i costi e i tempi siano integrati tra loro. Un buon sistema di assicurazione della qualità deve:  Identiﬁcare obiettivi e standard;  Essere orientato alla prevenzione; 2  Pianiﬁcare per collezionare e usare dati per il miglioramento continuo;  Includere veriﬁche (Audit) di qualità. 4. Controllo della qualità Con controllo della qualità si identiﬁca l’insieme di attività e tecniche che mirano a creare speciﬁche caratteristiche di qualità. Esso include il monitoraggio continuo dei processi, l’identiﬁcazione ed eliminazione delle cause dei problemi e l’uso di SPC (Statistical Process Control)* per ridurre la variabilità dei processi ed incrementarne l’e icacia. Il controllo della qualità certiﬁca che gli obiettivi di qualità dell’organizzazione si stanno raggiungendo. Un sistema di controllo della qualità deve:  Selezionare cosa controllare;  Stabilire gli standard su cui basarsi per individuare eventuali azioni di miglioramento;  Stabilire le tecniche di misurazione adottate;  Confrontare i risultati osservati con standard di qualità;  Monitorare e calibrare i dispositivi di misurazione;  Includere documentazione dettagliata per tutti i processi. Le attività di controllo della qualità non solo mirano a migliorare la qualità dal punto di vista della correzione di difetti, ma portano al considerare decisioni quali l’accettazione o meno di un prodotto/servizio, fare rielaborazioni che permettono a un prodotto/servizio scartato di essere considerato nuovamente valido (comporta costi), o la semplice modiﬁca di un processo che si sta eseguendo. Il controllo della qualità e l’assicurazione della qualità sono in forte relazione tra di loro attraverso i concetti di prevenzione e correzione: Prevenzione Correzione Assicurazione della qualità: set di azioni programmate e Controllo della qualità: insieme di sistematiche necessarie per assicurare con adeguata tecniche e di attività di carattere ﬁducia che un determinato prodotto o servizio sia in operativo utilizzati per veriﬁcare i grado di soddisfare i requisiti di qualità. requisiti di qualità di un prodotto o servizio. Assicurazione della Qualità (QA) Controllo della Qualità (QC)  Aiuta a stabilire i processi;  È legato a un determinato  Deﬁnisce un programma di misura attraverso cui prodotto o servizio; raccogliere i valori;  Identiﬁca i difetti al ﬁne di  Identiﬁca i punti di debolezza nei processi e correggerli; miglioramenti nel progetto;  È responsabilità di ciascun  È responsabilità del management; membro del team.  Valuta se il Controllo della Qualità consente di identiﬁcare debolezze nel processo (al ﬁne di non avere difetti nel prodotto);  È legato a tutti i prodotti sviluppati. 5. Veriﬁca della qualità (Audit) La veriﬁca della qualità è una valutazione indipendente, fatta da personale qualiﬁcato, che riscontra la conformità del progetto rispetto ai requisiti di qualità e veriﬁca che si stia procedendo secondo le procedure e le politiche stabilite. Una veriﬁca di qualità assicura che:  La qualità pianiﬁcata per il progetto sia raggiunta; 3  I prodotti siano adeguati all’uso;  Le leggi e le normative sono rispettate;  I sistemi di raccolta e distribuzione dei dati sono accurati e adeguati;  Si identiﬁcano opportune iniziative di miglioramento. 6. Piano di qualità Il piano di qualità dettaglia come il team di management intende svolgere la politica di qualità dell’organizzazione. Esso è parte del piano di project management e include dettagli sugli aspetti di controllo qualità, assicurazione della qualità, approcci di miglioramento continuo da mettere in atto durante il progetto. Il piano di qualità può essere formale o informale, più o meno dettagliato o pianiﬁcato, dipendentemente dalle esigenze del progetto. Dovrebbe essere revisionato all’inizio del progetto per assicurare che le decisioni siano basate su informazioni accurate. Redigere il piano di qualità ha come beneﬁci quelli di ridurre costi e project overrun in seguito a rilavorazioni. Costo della qualità Investire nella prevenzione e nel controllo della qualità può sembrare oneroso, ma aiuta a ridurre i costi più elevati derivanti da difetti e rilavorazioni. Infatti, un buon sistema di gestione della qualità minimizza i costi della non conformità. Riprendiamo le deﬁnizioni delle due categorie di costi: il costo per fare bene le cose (conformità) e il costo per rimettere a posto le cose sbagliate (non conformità).  Costo della conformità (COC): sono i costi sostenuti per garantire che il prodotto o servizio sia realizzato correttamente e privo di difetti. Si suddividono in: o Costi di prevenzione: includono la formazione del personale, documentazione dei processi, acquisto di attrezzature e il tempo necessario per eseguire il lavoro in modo corretto; o Costi di accertamento: riguardano il controllo della qualità attraverso test, ispezioni e metodi di veriﬁca, anche distruttivi, per garantire che il prodotto rispetti gli standard richiesti.  Costo della non conformità (CNC): sono i costi derivanti da errori o difetti nel prodotto. Si dividono in: o Costi per insuccessi interni: quando il difetto viene individuato prima che il prodotto arrivi al cliente, e comprendono rilavorazioni e scarti di materiale; o Costi per insuccessi esterni: quando il difetto viene scoperto dal cliente, generando costi legali e spese per riparazioni in garanzia. Strumenti per il controllo della qualità I metodi statistici hanno acquisito sempre più importanza quale strumento di supporto alle decisioni sulla base di dati quantiﬁcabili. Si distinguono strumenti per identiﬁcare ed analizzare opportunità di miglioramento, e consentono di organizzare dati numerici, facilitare la pianiﬁcazione e migliorare il processo decisionale. Tali strumenti sono illustrati a seguire. 1. Data Tables Le Data Tables forniscono una maniera sistematica per raccogliere e mostrare dati. Sono progettati principalmente per collezionare dati, soprattutto provenienti da strumenti automatici. Forniscono una modalità consistente, e icace ed economica per raccogliere dati, organizzarli e mostrarli per successive analisi. 4 2. Cause and E ect Analysis – Diagramma Causa-E etto (o lisca di pesce, o Ishikawa Diagrams) Questa analisi identiﬁca le relazioni tra un e etto e le sue potenziali cause. Consiste in sei passi: 1. Identiﬁcare il problema utilizzando vari tool di controllo statistico (istogrammi, carte di controllo, brainstorming…); 2. Selezionare il team di brainstorming con competenze nell’area del problema; 3. Speciﬁcare il Problem Box e la freccia principale; 4. Speciﬁcare le categorie che contribuiscono al problema. Le cause saranno determinate relativamente alle varie categorie; 5. Identiﬁcare le cause legate a ciascuna categoria (immagine a sinistra); 6. Identiﬁcare le azioni correttive (immagine a destra). 3. Scatter Plot Organizza i dati usando due variabili: indipendente e dipendente. Le coppie di osservazione (xi, yi) sono plottate in due dimensioni. Si tratta di una buona modalità per individuare eventuali dipendenze tra variabili. Dall’analisi di questo graﬁco emerge quanto i dati sono sparsi o concentrati e se esiste una tendenza lineare nei valori. In genere, se le variabili sono fortemente relazionate, i data point hanno una forma sistemica (una linea, una curva). 4. Istogrammi Gli istogrammi rappresentano graﬁcamente i dati in termini di frequenza della distribuzione. Fornisce un quadro dei dati rispetto ad un preﬁssato data point nel tempo. Non mostra trend o distribuzioni nel tempo. Ogni barra è un attributo/caratteristica di una situazione/problema e l’altezza è la frequenza di quella caratteristica. 5. Pareto Chart Si tratta di un particolare tipo di istogramma in cui le variabili sono ordinate per frequenza di occorrenza per aiutare a identiﬁcare quelli che contribuiscono maggiormente a problemi di qualità. L’analisi di Pareto è anche conosciuta come “regola 80- 20”: il 20% delle cause provocano l’80% dei problemi. Nell’esempio, i problemi di login all’account di sistema rappresentano il 55% dei reclami degli utenti. Questo problema, insieme al sistema di blocco account, rappresenta l’80% di tutti i reclami ricevuti. Pertanto, il 5 diagramma ci aiuta a dedurre che ridurre questi due problemi indica la necessità di cercare di ridurre notevolmente il volume dei reclami ricevuti. 6. Diagrammi di Flusso I diagrammi di ﬂusso rappresentano graﬁcamente la logica e il ﬂusso dei processi, consentendo di analizzare i problemi e decidere come possono migliorare. Contengono attività, punti di decisione e l’ordine in cui vengono eseguite le diverse attività. 7. Trend Analysis: Run Chart (o Regressione, o Minimi Quadrati) L’analisi del trend è il metodo statistico usato per determinare la migliore equazione che interpola i punti di un diagramma Scatter Plot (vedi punto 3). L’equazione individuata descrive la relazione tra la variabile dipendente (output) e quella indipendente (input). È utilizzato per prevedere gli e etti dei cambiamenti durante il processo mostrando il trend storico e il modello di variazione dell’andamento nel tempo. Il diagramma è costituito da linee che collegano i punti di osservazione (dati) tracciandoli in relazione a una scala temporale. I run chart sono utilizzati per eseguire analisi delle tendenze (Trend Analysis) per prevedere i risultati futuri sulla base di modelli storici. 8. Control Charts (Carte di Controllo – per lo *Statistical Process Control) Si tratta di una rappresentazione graﬁca di dati che mostra i risultati di un processo nel tempo e sono utilizzati principalmente per prevenire i difetti. Si di erenziano dai Run Chart in quanto incorporano controllo statistico. Questi diagrammi possono determinare se un processo è sotto controllo o fuori controllo (statisticamente parlando):  Quando un processo è sotto controllo, le variazioni nei risultati sono dovute a eventi casuali in natura. I processi sotto controllo non necessitano di modiﬁche.  Quando un processo è fuori controllo, le variazioni nei risultati sono dovute a problemi nel processo. In tal caso è necessario identiﬁcare le cause e regolare il processo per correggerli o eliminarli. Il graﬁco di controllo è costituito dai seguenti elementi di base:  Punti di valore statistico che rappresentano la misura di una caratteristica in campioni prelevati nel corso del tempo;  Viene calcolata la media di tutti i valori rappresentati e viene rappresentata mediante una linea orizzontale;  Viene calcolata la deviazione standard per determinare la variabilità del processo;  Sono tracciati i limiti (superiori o inferiori) di controllo del processo, solitamente pari alla media +/-3 volte la deviazione standard. Se il processo è controllato, il 99.73% dei punti tracciati si trovano entro i limiti di controllo. Qualsiasi punto oltre i limiti, o qualsiasi osservazione di un percorso sistematico (anche se entro certi limiti), deve essere esaminato poiché potrebbe comportare un aumento del costo della qualità. In pratica, potrebbe succedere che in media le prestazioni dl processo non coincidano con l’obiettivo preﬁssato. Ciò signiﬁca che il processo, in quanto tale, non riesce a raggiungere il livello di qualità desiderato. 6 Monitoraggio Il monitoraggio è l’attività di misurazione nel tempo delle prestazioni di un processo, espresse attraverso opportune metriche operative (tempi di esecuzione, produttività…), volta all’individuazione e segnalazione attraverso sistemi di anomalie e disservizi.  Il monitoraggio implica la necessità di deﬁnire opportune soglie utili a valutare le prestazioni osservate rispetto a quelle attese. o Problema 1: non ci sono e né possono esserci soglie universalmente valide a causa dell’eterogeneità degli ambienti operativi e del ragguardevole numero di processi monitorabili.  Il monitoraggio sottende la necessità di individuare comportamenti anomali e reagire prontamente. o Problema 2: occorre capire cos’è un comportamento anomalo e come esso può essere identiﬁcato.  Il monitoraggio deve avere una sensibilità variabile in funzione del fenomeno osservato. o Problema 3: occorre capire come adeguare la sensibilità del monitoraggio alla luce dei cambiamenti continui nelle performance di un processo. La soluzione a tutti questi problemi è proprio il *SPC – Statistical Process Control. Gestione del Rischio Il rischio in un progetto è un evento o condizione incerta che, se si dovesse veriﬁcare, avrebbe un e etto positivo o negativo su uno o più obiettivi di progetto quali ambito, schedulazione, costi e qualità. Vi sono principalmente due categorie di rischi:  Rischi noti: sono quelli che sono stati identiﬁcati ed analizzati, rendendo possibile la pianiﬁcazione delle risposte;  Rischi ignoti: sono quelli non identiﬁcabili a priori e che, come tali, non possono essere gestiti in modo proattivo (gestione della crisi). Il rischio è legato al concetto di incertezza e, quindi, alla probabilità P che esso si veriﬁchi. Tale probabilità non può essere 0 o 1 ma deve essere contenuta nell’intervallo (0, 1). Il veriﬁcarsi dell’evento produce un e etto o conseguenza che determina un impatto I sul raggiungimento di uno o più obiettivi. L’impatto I può essere positivo o negativo: si parla quindi di opportunità/beneﬁci oppure di minacce e costi/danni. I rischi sono determinati da cause e, in base a esse, è possibile classiﬁcarli. I fattori di rischio sono caratteristici del dominio del progetto e del suo contesto. Esempio: uscire di strada rappresenta un rischio. Avere le gomme lisce è identiﬁcabile come causa, mentre le lesioni o i danni all’auto sono conseguenze. È importante non confondere cause e conseguenze. Un rischio può avere una o più cause e, se si presenta, uno o più impatti. L’obiettivo della gestione dei rischi è quella di aumentare la probabilità e/o l’impatto di un evento positivo così come di diminuire probabilità e/o impatto di un evento negativo. 7 La gestione dei rischi include le attività di:  Identiﬁcazione: conoscere i rischi a cui si va incontro;  Analisi: determinare, per ciascun rischio, natura e livello di esposizione;  Pianiﬁcazione delle risposte: deﬁnire le strategie e le azioni per a rontare un rischio;  Controllo: monitorare e tracciare rischi noti. Identiﬁcare un rischio Con identiﬁcazione del rischio si intende il processo di individuazione delle fonti di rischio, delle possibili cause e degli e etti che ne conseguono. Si tratta di un processo che viene eseguito per tutta la durata del progetto: vanno prioritariamente passate in rassegna tutte le aree di conoscenza per capire se ci sono potenziali rischi. Risorse coinvolte Strumenti e tecniche utili  Project manager;  Brainstorming: un gruppo di esperti discute, sotto la  Project team members; leadership di un facilitatore, con l'obiettivo ﬁnale di  Risk management team; deﬁnire e categorizzare i rischi;  Risk management  Delphi Technique: un facilitatore utilizza un questionario experts; per raggiungere un consenso sui rischi di progetto mentre  Customers, end users, gli esperti partecipano in forma anonima (il processo può stakeholders. richiedere più iterazioni);  Interviste: vengono condotte con tutte le persone coinvolte nel progetto in grado di identiﬁcare i rischi;  Root Cause Analysis: Ishikawa Diagram (o a spina di pesce);  Risk Breakdown Structure: diagramma che elenca categorie e sottocategorie all’interno delle quali possono insorgere rischi;  Checklist di opportunità e minacce. Analisi del rischio L'analisi del rischio è il processo di valutazione, prima qualitativa e successivamente quantitativa, della probabilità di accadimento di un rischio e del suo impatto:  La valutazione qualitativa consente di attribuire una priorità ai rischi e permettere di concentrarsi su quelli che hanno la probabilità e l'impatto più alti;  La valutazione quantitativa consente di operare stime esatte circa gli e etti del rischio. Uno strumento essenziale nella gestione del rischio è il Registro dei Rischi. Pianiﬁcazione delle risposte Prevede l’identiﬁcazione e lo sviluppo di azioni e iniziative da adottare per favorire le opportunità e ridurre le minacce. I rischi vanno gestiti in base alla loro priorità prevedendo risorse dedicate nel piano di progetto. La gestione del rischio prevede diverse strategie per a rontare i rischi, stabilendo modalità di risposta in base a caratteristiche e priorità. Viene stimata la quantità di risorse necessarie e assegnato un "Risk Response Owner" per ogni rischio. Le azioni di risposta vengono integrate nel piano di progetto, inﬂuenzando durata, costi e qualità, e seguendo i criteri deﬁniti nel piano di gestione del rischio. 8 Strategie per la gestione del rischio Esistono diverse strategie per la gestione delle minacce:  Evitare la minaccia: rimuovere dal piano di progetto attività particolarmente complesse e non indispensabili;  Trasferire la minaccia: ad esempio, se una parte del progetto è molto rischiosa, può essere una soluzione subappaltarla con clausole di penalità su icienti a coprire l’eventuale perdita;  Mitigare la minaccia: portare probabilità e impatto del rischio all’interno di una soglia accettabile;  Accettare la minaccia: accettare il rischio e stanziare risorse su icienti a mitigare gli impatti (piano di contingenza). Ci sono anche strategie per la gestione delle opportunità:  Sfruttare l’opportunità: cercare di massimizzare la probabilità che il rischio si concretizzi;  Condividere l’opportunità: coinvolgere una terza parte maggiormente pronta a cogliere l’opportunità;  Potenziare il rischio: tentare, per quanto possibile, di aumentare gli impatti;  Accettare il rischio: attendere il veriﬁcarsi del rischio senza intraprendere ulteriori azioni. Il Registro dei Rischi è il documento che raccoglie tutte le informazioni sui rischi durante tutte le fasi della loro gestione e contiene, oltre all’elenco dei rischi, le potenziali strategie, le potenziali cause in grado di dare luogo agli eventi ed eventuali aggiornamenti alle categorie di rischio deﬁnite nel piano. Il piano di contingenza è necessario quando si accetta un rischio, prevedendo misure per a rontare la sua eventuale concretizzazione. Comprende:  Un piano di emergenza con azioni speciﬁche.  Una riserva di contingenza per costi e durata.  Indicatori (trigger) per attivare il piano o utilizzare la riserva. La riserva di contingenza è deﬁnita tramite analisi quantitativa e, per la schedulazione, si inserisce come bu er temporale. Le attività di monitoraggio veriﬁcano l’adeguatezza della riserva residua nel tempo. I fattori di criticità nei piani di risposta ai rischi sono elementi che possono rendere di icile la gestione e icace del rischio:  Incertezza descrittiva: di icoltà nel raccogliere informazioni accurate sul rischio e sulle sue cause;  Incertezza delle misure: problemi nel quantiﬁcare correttamente il danno o il beneﬁcio associato al rischio;  Attitudine al rischio: la propensione del project manager o degli stakeholder a prendere rischi può inﬂuenzare le decisioni;  Beneﬁcio personale (Rischio Volontario): se il project manager o il risk owner vedono un possibile vantaggio personale, potrebbero gestire il rischio in modo diverso;  Rischio non evitabile: alcuni rischi devono essere a rontati per forza, non possono essere ignorati o eliminati;  Esistenza di alternative: se ci sono soluzioni alternative, bisogna considerare il loro costo e la loro fattibilità;  Durata dell'esposizione al rischio: quanto a lungo il progetto rimane vulnerabile a un determinato rischio e in quale fase si veriﬁca. 9 Monitoraggio e controllo Durante l’esecuzione di un progetto occorre tenere traccia di tutti i rischi identiﬁcati monitorandone anche lo stato a valle di ciascuna risposta, ricercarne di nuovi e vigilare sulla corretta attuazione delle risposte pianiﬁcate. Occorre raccogliere e pacchettizzare l’esperienza al ﬁne poterla usare in progetti futuri. 10 Modelli e metodi per la qualità del Software Riassunto del materiale didattico Miglioramento continuo dei processi Per costruire software di qualità è necessario superare tutti i problemi dei processi di produzione. In quanto uomocentrico, il processo software non è né simmetrico e né conforme e deve essere continuamente monitorato. La diversità dei processi e quella dell’apprendimento delle tecnologie rende il processo software sperimentale, e il suo miglioramento graduale. Il Business è inﬂuenzato direttamente dalla qualità dei prodotti o servizi o erti ai clienti. La qualità dei prodotti/servizi è, d’altra parte, inﬂuenzata dalla qualità dei processi di sviluppo. Migliorare i processi migliora quindi il Business. Il miglioramento della qualità segue degli schemi che deﬁniscono i livelli di qualità dei processi e come essi si caratterizzano. Questi prevedono anche un modello di qualità.  ISO 9000;  ISO 12270;  Capability Maturity Model (CMM-I);  Software Process Improvement and Capability dEtermination (SPICE). I paradigmi deﬁniscono una strategia per il raggiungimento di un livello di qualità preﬁssato, e come questo si migliora. Questi richiedono un modello di qualità.  Plan Do Check Act (PDCA);  Quality Improvement Process (QIP);  Experience Factory (EF). ISO 9000 (VISION 2000) Principi di base Esso è un insieme di standard per il controllo e la guida della qualità in tutti i settori produttivi. L’organizzazione che lo adotta deve adottare un Sistema Qualità che deﬁnisce le modalità per valutare, controllare e guidare la qualità di tutti i processi di produzione. I dettagli del Sistema Qualità sono contenuti in Manuale di Qualità. Le norme per i sistemi di qualità Una norma è un documento prodotto attraverso consenso e approvato da un organismo riconosciuto. Fornisce, per usi comuni e ripetuti, le caratteristiche o le linee guida relative a determinate attività o prodotti. Ha lo scopo di assicurare ordine e uniformità in un determinato contesto. Si pone come obiettivi quelli di:  Salvaguardare gli interessi dei consumatori e della collettività;  Migliorare il sistema produttivo attraverso l’uniﬁcazione dei processi e dei prodotti;  Migliorare lo scambio di informazioni attraverso l’applicazione di standard per simboli, codici, interfacce…;  Promuovere la sicurezza dell’uomo e dell’ambiente. 1 Signiﬁcato delle norme  ISO 9000: descrive i fondamenti dei sistemi di gestione per la qualità e ne speciﬁca la terminologia.  ISO 9001: speciﬁca i requisiti dei sistemi di gestione per la qualità da utilizzare quando un’organizzazione deve dimostrare la propria capacità a fornire prodotti in grado di soddisfare i requisiti dei clienti, quelli legali e normativi e che migliorino la soddisfazione dei clienti.  ISO 9004: fornisce delle linee guida che tengono conto dell’e icacia e dell’e icienza dei sistemi di gestione per la qualità. Lo scopo della guida è il miglioramento continuo delle prestazioni dell’organizzazione, della soddisfazione di clienti e stakeholders.  ISO 19011: fornisce una guida sulle veriﬁche ispettive di sistemi di gestione per la qualità e ambientali. Norme di settore  ISO IEC 12207: deﬁnisce i processi del ciclo di vita del software;  ISO IEC 9126: riguarda la qualità del prodotto software;  ISO IEC 14598: deﬁnisce il processo per la valutazione dei prodotti;  ISO IEC 25000: deﬁnisce un quadro completo della qualità del software, incorpora le norme ISO IEC 9126 e ISO IEC 14598. 2 ISO IEC 12207: Software Lifecycle Processes La norma ISO/IEC 12207 deﬁnisce un quadro di riferimento per i processi del ciclo di vita del software, coprendo tutte le fasi dalla concezione alla dismissione. ISO/IEC 12207 è organizzata in tre categorie di processi: processi primari, processi di supporto e processi organizzativi. Processi primari Sono quelli che portano alla realizzazione della missione dell’organizzazione, determinando in generale la produzione del sistema software. Si dividono in cinque categorie: 1. Acquisizione: deﬁnisce le attività che l’acquirente deve eseguire per entrare in possesso di un determinato software. Si rivolge alle organizzazioni che acquistano un sistema, prodotto o servizio software. 2. Fornitura: deﬁnisce le attività che il fornitore deve eseguire per rendere disponibile l’acquisizione di software da parte di un committente. Si rivolge alle organizzazioni che forniscono/vendono un sistema, prodotto o servizio software. 3. Sviluppo: deﬁnisce le attività che devono essere seguite dall’organizzazione per la deﬁnizione e lo sviluppo di un prodotto software. Esempio: analisi dei requisiti del sistema e del software, progettazione architetturale del sistema e del software, progettazione di dettaglio del software, codiﬁca e test, integrazione del sistema e del software, test di qualiﬁcazione del sistema e del software… 4. Gestione operativa: deﬁnisce le attività dell’operatore, ovvero colui che utilizza un calcolatore all’interno dell’organizzazione di cui fa parte. 5. Manutenzione: deﬁnisce le attività che l’organizzazione deve seguire per la manutenzione di un prodotto software. Processi di supporto Coadiuvano l’esecuzione dei processi primari fornendovi servizi che contribuiscono al successo e alla qualità di un progetto. Si dividono in otto categorie: 1. Documentazione: attività dinamiche con alto valore aggiunto, importanti per il miglioramento della qualità. Quando le procedure sono documentate, spiegate e attuate, è possibile determinare con conﬁdenza come sono eseguiti solitamente i processi e misurarne le prestazioni. Di conseguenza, la misurazione dell’e etto di una modiﬁca è più a idabile. Inoltre, documentare le procedure correnti è essenziale per preservare i miglioramenti della qualità e garantire che le buone pratiche vengano mantenute nel tempo. 2. Gestione della conﬁgurazione: fulcro intorno al quale ruota la produzione, include le operazioni necessarie alla catalogazione, identiﬁcazione e recupero di un qualsiasi manufatto prodotto all’interno dell’organizzazione. La gestione della conﬁgurazione è necessaria per controllare tutti gli artefatti ottenuti dall’esecuzione del processo e veriﬁcarne la loro conformità agli standard imposti. La gestione della conﬁgurazione si realizza attraverso: a. Identiﬁcazione degli artefatti generati dai processi; b. Controllo delle modiﬁche e delle release del software; c. Registrazione dello stato degli artefatti e delle richieste di modiﬁca; d. Veriﬁca della completezza e coerenza degli artefatti prodotti. 3. Assicurazione della qualità: garantisce che sia il prodotto software sia il processo di sviluppo rispettino gli standard qualitativi stabiliti dall'organizzazione. Si realizza attraverso: a. Pianiﬁcazione: identiﬁcazione, programmazione e schedulazione delle attività di quality assurance, incluse le misurazioni; b. Deﬁnizione degli standard: scelta di metodi, procedure e strumenti per garantire la qualità; c. Allocazione delle risorse: identiﬁcazione delle risorse necessarie e delle responsabilità; 3 d. Esecuzione delle attività. 4. Veriﬁca: deﬁnisce le attività, a carico dell’organizzazione, da seguire per la veriﬁca del processo utilizzato. Viene e ettuata alla ﬁne di ogni fase prevista e determina se l’esecuzione del processo è conforme al modello di processo adottato, se il prodotto è conforme al prodotto atteso in termini di costi, risorse impiegate, requisiti, vincoli ecc. 5. Validazione: deﬁnisce le attività da seguire per la validazione (da parte del fornitore o del beneﬁciario) di un prodotto software, ovvero se esso soddisfa la richiesta. 6. Revisione o joint review: processo di valutazione dello stato e dei prodotti di un'attività, con lo scopo di informare il cliente sui progressi del progetto e garantire che i risultati raggiunti siano conformi alle sue esigenze/requisiti. Le attività di questo processo si compongono di diverse tipologie: revisione del contratto, revisione tecnica e revisione di accettazione. Tali veriﬁche sono e ettuate durante le fasi di sviluppo e i periodi sono deﬁniti nel contratto. 7. Audit: deﬁnisce le attività necessarie a determinare la conformità dei prodotti ai requisiti, al processo e al contratto. In alcuni casi questo processo viene assorbito dal processo di assicurazione della qualità o da quelli di veriﬁca e validazione. 8. Gestione dei problemi: deﬁnisce le attività volte all’individuazione e risoluzione di problemi di qualunque natura e in qualsiasi fase essi siano riscontrati. Comprende le seguenti fasi: a. Realizzazione del report dei problemi; b. Deﬁnizione della priorità del problema; c. Determinazione della risoluzione; d. Correzione dei difetti; e. Distribuzione del prodotto corretto. Processi organizzativi Utilizzati per deﬁnire e implementare una struttura logica di fondo da seguire, al ﬁne di migliorare la struttura stessa e i processi utilizzati all’interno dell’organizzazione. Con “struttura” si intende far riferimento alla ripartizione di compiti, competenze, responsabilità e potere decisionale all’interno dell’organizzazione (deﬁnizione dell’organigramma). I processi organizzativi si suddividono in quattro categorie: 1. Gestione del processo: deﬁnisce le attività di base per la gestione dell’organizzazione e dei processi coinvolti nel ciclo di vita di un progetto o prodotto software. 2. Gestione infrastrutture: deﬁnisce le attività da seguire per determinare e manutenere le infrastrutture (hardware, software, tools, standards…) di cui necessitano gli altri processi. 3. Miglioramento: deﬁnisce le attività necessarie per determinare, consolidare, misurare, controllare e migliorare i processi coinvolti nel ciclo di vita di un software. 4. Addestramento e formazione: deﬁnisce le attività necessarie a dare un’adeguata formazione alle risorse umane all’interno dell’organizzazione. Process models (Modelli di Processo) I modelli di processo sono molto utili per deﬁnire l'insieme dei processi da implementare, la "natura" delle capacità dei processi e un percorso per il miglioramento. Tuttavia, è importante fare attenzione: i modelli sono solo un'approssimazione sempliﬁcata della realtà, che o re una visione generale ma non può cogliere tutte le complessità del mondo reale. Ecco alcuni esempi di modelli di processo:  CMMI (Capability Maturity Model Integration): è un modello che aiuta le organizzazioni a migliorare i propri processi di sviluppo software e gestione. Si basa su una serie di livelli di maturità che guidano l'evoluzione delle capacità di processo.  SPICE (Software Process Improvement and Capability dEtermination): fornisce una struttura per la valutazione e il miglioramento dei processi di sviluppo software. SPICE si concentra sull'analisi della capacità dei processi e sulla loro evoluzione verso una maggiore e icienza. 4  SOA (Service-Oriented Architecture): descrive un approccio architetturale per lo sviluppo di software che enfatizza l'interoperabilità e la modularità. Si tratta di un paradigma che permette di strutturare i processi aziendali in modo ﬂessibile e facilmente integrabile.  COBIT (Control Objectives for Information and Related Technologies): framework per la gestione e il controllo dei processi software. Supporta le organizzazioni nella gestione dei rischi e nell'uso delle tecnologie informatiche, migliorando la governance e l'e icienza dei processi. ISO IEC 15504 (oggi ISO 33000): The SPICE Project (Software Process Improvement and Capability dEtermination) Principi base Perché adottare ISO IEC 15504? Tre principali motivi:  Comprensione dei processi software operanti nella propria organizzazione;  Determinazione delle capacità dei processi, sia della propria organizzazione che delle organizzazioni fornitrici;  Guida il miglioramento del processo attraverso le analisi delle misure e l’individuazione dei processi da migliorare. ISO/IEC 15504 è un modello di riferimento per valutare la maturità dei processi all'interno di un'organizzazione. Si basa su livelli di capacità, che sono suddivisi in attributi del processo e consistono in pratiche generiche. I valutatori raccolgono evidenze durante la valutazione per determinare la capacità dell'organizzazione di fornire prodotti (software, sistemi e servizi IT) di qualità. Categorie di processo Tutti i processi di un'organizzazione sono classiﬁcati in categorie:  Fornitore-Committente: regolano la relazione con i committenti ed impattano sulla soddisfazione di questi ultimi;  Ingegneristici: speciﬁca, progettazione, implementazione o manutenzione dei sistemi e dei prodotti software;  Progetti: deﬁnizione dei processi di produzione, controllo e guida degli stessi durante la loro esecuzione;  Supporto: supporto ai processi di produzione per assicurarne l'e icacia;  Organizzazione: deﬁnizione degli obiettivi di business e dei processi di sviluppo, prodotti, risorse disponibili che consentono di raggiungere tali obiettivi di business. 5 Livelli di capacità Il livello di capacità è un indicatore della qualità raggiunta nella gestione del processo. Si determina attraverso l’osservazione di un set di attributi di processo, associati a ciascun livello. I livelli di capacità si riferiscono al singolo processo e non all’intero set. Livello Deﬁnizione 0 Di ormità nell’esecuzione delle pratiche di base e risultati Non eseguito ﬁnali o parziali del progetto non facilmente identiﬁcabili. Incompleto 1 Le pratiche di base del processo sono generalmente eseguite, Eseguito informalmente anche se a volte non rigorosamente pianiﬁcate e monitorate. Eseguito Sono identiﬁcabili i risultati e i prodotti parziali e ﬁnali. 2 La prestazione nelle pratiche di base è pianiﬁcata e monitorata Pianiﬁcato e monitorato coerentemente con procedure predeﬁnite. I risultati e i Gestito prodotti sono conformi a speciﬁci standard. 3 Le pratiche di base sono eseguite concordemente con un Ben deﬁnito processo deﬁnito, il quale è una specializzazione di un Stabilito processo standard preventivamente approvato. Questo livello si di erenzia dal precedente in quanto il processo è deﬁnito e controllato usando un processo standard a livello di organizzazione. 4 Le misure di prestazione sono raccolte e analizzate così da Quantitativamente controllato poter capire quantitativamente il processo e stimarne a priori le Prevedibile prestazioni. La qualità dei prodotti e dei risultati sono quantitativamente rilevabili. La distinzione con il precedente livello è data dall’uso di misure quantitative. 5 Gli obiettivi di e icacia e di e icienza sono sempre deﬁniti Migliorato continuamente sulla base di obiettivi di business. Il miglioramento verso questi Ottimizzato obiettivi è eseguito in base all’analisi delle misure quantitative raccolte, le quali fanno capire le contro azioni necessarie per superare eventuali carenze. La di erenza con il precedente livello è il continuo a inamento dei processi nei confronti degli obiettivi. Il raggiungimento di un livello di capacità è determinato dal grado di presenza (achievement) nel processo di 9 attributi suddivisi sui 5 livelli. Ognuno di questi attributi è misurabile (rating) attraverso una scala di valori deﬁnita (4 valori): N – not achieved; P – partially; L – largely; F – fully. # Livello Attributo di processo Signiﬁcato 0 Incompleto 1 Eseguito PA 1.1 Esecuzione del processo Eseguito (anche se in maniera informale); produce risultati attesi. 2 Gestito PA 2.1 Gestione dell’esecuzione Esecuzione pianiﬁcata e gestita per produrre risultati previsti. PA 2.2 Gestione dei risultati Risultati documentati e gestiti. 3 Stabilito PA 3.1 Deﬁnizione del processo Esiste ed è mantenuta una deﬁnizione standard del processo. PA 3.2 Utilizzo del processo Eseguito sulla base di una personalizzazione del processo standard. 4 Prevedibile PA 4.1 Misurazione del processo La performance del processo è misurata. PA 4.2 Controllo del processo Processo controllato quantitativamente attraverso le misure. 5 Ottimizzato PA 5.1 Innovazione del processo Cambiamenti e ettuati in modo controllato. PA 5.2 Miglioramento continuo Processo soggetto a miglioramento continuo. 6 Assessment ISO IEC 15504 fornisce linee guida per eseguire il processo di valutazione (assessment) e lo segue in tutti i suoi passi (avvio -ad opera dello sponsor-, selezione del valutatore/gruppo di valutazione, pianiﬁcazione, raccolta e convalida dei dati, rating e reporting). Il valutatore raccoglie i dati relativi a un processo attraverso interviste con il personale coinvolto, raccolta di documenti e dati di qualità, raccolta di dati statistici. Il valutatore convalida i dati per assicurarsi che siano accurati e coprano completamente l’ambito della valutazione, per poi valutarli rispetto alle politiche di base di un processo e alle pratiche generiche della capacità. È importante che siano veriﬁcate qualiﬁche e competenze del valutatore. Il process rating è presentato sotto forma di risultati in forma preliminare allo sponsor per veriﬁcarne l’accuratezza. Può essere necessario attivare cicli di feedback per ulteriori valutazioni prima che si raggiunga la valutazione ﬁnale del processo. CMM – Capability Maturity Model Principi base Secondo il SEI (Software Engineering Institute) il primo passo per assestare e migliorare il processo è la sua valutazione. Sono previste tre classi di valutazione dei processi:  Software Process Capability: metodo per predire il più probabile risultato atteso nei progetti futuri;  Software Process Performance: rappresenta il risultato raggiunto eseguendo un processo software;  Software Process Maturity: esprime quanto un processo sia esplicitamente deﬁnito, gestito, misurato, controllato ed e icace. Perché usare il CMM? Tre motivi:  Riesame della propria organizzazione per identiﬁcare punti di forza e di debolezza;  Valutazione organizzazioni esterne per stimare i rischi nella selezione di un fornitore;  Guida per il miglioramento del processo attraverso le analisi delle misure e l’individuazione dei punti da migliorare. Livelli di maturità Un livello di maturità è uno stadio evolutivo ben deﬁnito in un cammino di maturazione di un’organizzazione produttrice di software. Nel CMM sono previsti cinque livelli, ognuno fondamentale per il miglioramento continuo. 7 La capacità di un processo indica i potenziali risultati attesi dall’esecuzione del singolo processo, sia ai ﬁni dell’automiglioramento che della valutazione della capacità di un fornitore. Iniziale (1) Ripetibile (2) Deﬁnito (3) Gestito (4) Ottimizzato (5) Processo non ben Sono eseguite le Il processo è Vengono raccolte Miglioramento deﬁnito: il suo attività di base per la conforme agli dettagliate misure continuo dei successo dipende gestione dei standard dei processi e dei processi sfruttando solo dall’impegno processi. Il processo dell’organizzazione e prodotti, così che analisi post-mortem degli sviluppatori è su icientemente tutte le attività sono entrambi siano ben dei progetti eseguiti e disciplinato per documentate. capiti. le opportunità di essere ripetuto. tecnologie innovative. La classiﬁcazione dei singoli processi in livelli di capacità contribuisce alla collocazione dell’intera organizzazione nel suo livello di maturità. Aree chiave di processo (Key Process Areas) Ogni area di processi chiave identiﬁca un insieme di attività che, se eseguite collettivamente, assicurano la crescita delle capacità dei processi. In altre parole, le aree chiave di processo contengono tutte quelle attività che, se perseguite, consentono al processo di salire a un livello più alto di maturità. Fattori comuni Le aree chiave di processo sono organizzate in fattori comuni, ovvero attributi che assicurano che l’esecuzione e l’istituzionalizzazione di un processo chiave è e icace, ripetibile e deﬁnitiva. Pratiche chiave Descrivono le infrastrutture e le attività che contribuiscono all’e icace implementazione del processo. 8 1993: CMM → 2000: CMM-I Il Capability Maturity Model (CMM) è stato introdotto nel 1993 dal SEI (Software Engineering Institute) ed era limitato alle discipline di software engineering, utilizzando un modello a livelli di maturità (Staged Representation). Tra il 1993 e il 2000, sono stati sviluppati diversi modelli CMM per varie discipline (sistemi, sicurezza, personale, ecc). Nel 2000, il SEI ha integrato questi modelli creando il Capability Maturity Model Integration (CMMI), un framework per il miglioramento dei processi utilizzato in vari settori e richiesto in contratti governativi, soprattutto negli USA. CMMI si divide in tre aree principali:  CMMI-DEV (development): fornisce linee guida per la gestione, misurazione e monitoraggio dei processi di sviluppo;  CMMI-SVC (services): aiuta a gestire e fornire servizi sia all'interno delle organizzazioni che verso i clienti esterni;  CMMI-ACQ (acquisition): fornisce supporto nell’acquisizione di prodotti e servizi. Vi sono 16 aree chiave di processo in tutti i modelli di CMMI. CMMI è il successore del CMM, che è stato sviluppato tra il 1987 e il 1997. Le sue versioni principali sono state: CMMI v1.1 (2002), CMMI v1.2 (2006) e CMMI v1.3 (2010). Secondo il SEI, CMMI aiuta le organizzazioni a integrare funzioni aziendali, stabilire priorità di miglioramento, garantire processi di qualità e fornire riferimenti per la valutazione dei processi. Appraisal (valutazione) Un'organizzazione non può essere "certiﬁcata" in CMMI perché il CMMI (Capability Maturity Model Integration) non è un sistema di certiﬁcazione come, ad esempio, ISO 9001. Un’organizzazione può essere invece valutata e ottenere un livello di maturità (1-5) o un proﬁlo di conseguimento del livello di capacità. Le valutazioni vengono generalmente condotte per determinare in che misura i processi dell’organizzazione soddisfano le best practice CMMI e identiﬁcare le aree in cui è possibile migliorare. Le valutazioni sono utili anche a informare clienti e fornitori del modo in cui i processi dell’organizzazione soddisfano tali best practice. Alcune organizzazioni trovano valore nel condurre una valutazione anche solo per soddisfare i requisiti contrattuali dei clienti. Il metodo per condurre le valutazioni CMMI si chiama “Standard CMMI Appraisal Method for Process Improvement (SCAMPI)”. I risultati di una valutazione SCAMPI possono essere pubblicati sul sito web CMMI del SEI. SCAMPI supporta la condotta di ISO IEC 15504 (SPICE). 9 Rappresentare i dati (CMMI e SPICE) Nel 2000 viene introdotta la Continuous Representation (ispirandosi alla ISO 15504-SPICE). Insieme alla Staged Representation, costituisce un modo per rappresentare i livelli di capacità (continuous) o maturità (staged) con evidenza delle sedici aree chiave di processo (KPA). Staged Representation Si basa sui livelli di maturità per misurare il miglioramento dei processi. I livelli fanno riferimento alla maturità complessiva dell’organizzazione. Il miglioramento è dettato dagli insiemi predeﬁniti di aree di processo (KPA). Continuous Representation Usa i livelli di capacità per misurare il miglioramento dei processi. I livelli di capacità si applicano al raggiungimento del miglioramento dei processi per ciascuna area del processo (KPA). I miglioramenti sono deﬁniti dalla singola area di processo. 10 CMMI vs SPICE Ownership  CMMI è proprietario – Software Engineering Institute (SEI);  SPICE è uno standard internazionale – ISO IEC 15504. Dominio di applicazione dei modelli di processo  CMMI è un sistema chiuso che si sviluppa in tre modelli (DEV, SVC, ACQ);  SPICE (ISO IEC 15504) è “aperto”: deﬁnisce regole per costruire modelli di processo per qualsiasi disciplina. Chiunque può costruire modelli di processo per le valutazioni SPICE, e alcuni di questi sono stati sviluppati da ISO / IEC. Staged & Continuous Representation  CMMI e SPICE le coprono entrambe;  I livelli di maturità possono essere derivati da proﬁli di capacità di entrambi i modelli;  Nell’ultima versione CMMI 1.3 i livelli di capacità sono tre (precedentemente cinque);  CMMI ha un livello di maturità vuoto (livello 1) mentre SPICE include due processi base già dal primo livello. 11 Modelli e metodi per la qualità del Software Riassunto del materiale didattico Software Product Quality: ISO 25000 Un Prodotto Software rappresenta una serie di istruzioni fornite a un computer per fargli realizzare una serie di operazioni rispettando i requisiti concordati con il cliente. Lo standard di qualità di prodotto ISO 9126 identiﬁca il prodotto software come l’insieme di programmi, procedure, regole, documenti pertinenti all’utilizzo di un sistema informatico. ISO per la qualità del software La ISO (international Organization for Standardization) ha emesso norme che deﬁniscono il modello di qualità del software in diversi contesti di utilizzo: ISO 9126: software engineering product quality. È il modello ISO 25000: Software di riferimento per deﬁnire le caratteristiche di qualità del Quality Requirements and software e le metriche per la valutazione di essa. Evaluation (SQuaRE), integra ISO 9126 e ISO ISO 14598: guida la valutazione della qualità del software 14598 per la valutazione secondo i criteri ISO 9126, secondo un processo ben della qualità del Software. deﬁnito. ISO 9126 Utilizzo La ISO 9126 può essere utilizzata da acquirenti, sviluppatori, auditors, addetti all’assicurazione qualità secondo diverse prospettive e per vari scopi, tra cui:  Deﬁnire i requisiti di qualità del software (quality goals);  Validare la completezza di un documento di speciﬁca dei requisiti e/o progettazione;  Identiﬁcare obiettivi che vanno soddisfatti dal disegno tecnico del software;  Identiﬁcare criteri di assicurazione della qualità;  Identiﬁcare criteri di accettazione, test e collaudo del software. Struttura ISO IEC 9126-1 ISO IEC 9126-2 ISO IEC 9126-3 ISO IEC 9126-4 Modello delle caratteristiche e Metriche per la Metriche per la Metriche per la sottocaratteristiche misura della qualità misura della qualità misura della qualità di qualità del esterna interna in uso Software La ISO 9126-1 deﬁnisce un modello a quattro livelli: 1. Tre punti di vista sulla qualità del software (esterna, interna, in uso) che qualsiasi progetto deve considerare e soddisfare; 2. Principali attributi (requisiti qualitativi) che qualiﬁcano un software secondo i tre punti di vista; 3. Per ogni attributo, le sottocaratteristiche (requisiti quantitativi misurabili) che dovranno essere misurate per valutare il livello di qualità e ettivamente raggiunto; 4. Le metriche per e ettuare le misure. 1 I tre punti di vist

Modelli e Metodi per la Qualità del Software - PDF

Document Details

Tags

Related

Summary

Full Transcript