Modelli e Metodi per la Qualità del Software PDF

Modelli e Metodi per la Qualità del Software Concetti Generali ================= *Come possiamo dire che un prodotto software è di buona qualità?* La **qualità** è un termine ambiguo, con molte interpretazioni. Ciò è dovuto alle seguenti ragioni: - Non è un concetto semplice, ma multidimension...

Modelli e Metodi per la Qualità del Software Concetti Generali ================= *Come possiamo dire che un prodotto software è di buona qualità?* La **qualità** è un termine ambiguo, con molte interpretazioni. Ciò è dovuto alle seguenti ragioni: - Non è un concetto semplice, ma multidimensionale. **Le dimensioni sono**: - **L\'entità di interesse**; - **Il punto di vista che abbiamo di tale entità**; - **Attributi di qualità in grado di misurare più di tale entità**. - Per questo concetto, **ci sono diversi livelli di astrazione**: - A volte si usa il concetto di qualità nel senso più ampio del termine; - In altri, viene usato per indicare un aspetto molto specifico di un prodotto. - Si tratta di un **concetto che spesso usiamo nella nostra vita quotidiana**: - **Popolarmente**, si intende che la qualità sia una caratteristica immateriale. Si possono esprimere opinioni, commenti, giudizi, ma non è possibile misurarla concretamente. Diciamo che qualcosa è di buona qualità, cattiva qualità o si parla di qualità della vita. A volte la qualità esprime anche un senso di lusso, classe o buon gusto ed è riservata ai prodotti generalmente costosi, con funzionalità sofisticate. Prodotti semplici, che non sono costosi, raramente vengono definiti come prodotti di qualità; - **Autori rilevanti** nel campo della qualità professionale definiscono qualità rispetto a conformità con i requisiti e adeguatezza circa l'utilizzo. *Cos'è la Qualità del Software?* Il significato più comune è che **un software è di qualità** quando non ha difetti (bug) di tipo generalmente funzionali. Per esprimere questa definizione di qualità, generalmente si adottano le seguenti **metriche**: - **Tasso di difetti**; - **Affidabilità**; - **Soddisfazione degli utenti**. Lo **standard ISO** è un insieme di proprietà e di caratteristiche desiderate per un processo, un prodotto, un servizio software **allo scopo di**: - **Soddisfare il committente**, attraverso i requisiti impliciti od espliciti; - **Realizzare il ritorno economico** degli investitori; - **Realizzare trade-off** tra qualità tecnica, costo e tempo di esecuzione del processo. La **misurazione** cattura informazioni sugli attributi delle entità. Un'**entità** è un oggetto o un evento del mondo reale, invece un **attributo** è un aspetto o una proprietà specifica di un'entità. Distinguiamo **due tipi di qualità del software**: - **Qualità funzionali**: grado di soddisfazione dei requisiti funzionali, valutato mediante testing; - **Qualità strutturali**: grado di soddisfazione dei requisiti non funzionali, da parte dell'architettura, valutato mediante analisi architetturali. *Quanto è importante misurare?* Tom DeMarco affermava che non si può controllare quello che non si può misurare. In un qualsiasi **ciclo di vita del software**, le entità visibili e misurabili sono i processi (le attività), le risorse impiegate e alcuni attributi dei prodotti. La qualità di un prodotto software è la misura in cui il prodotto soddisfa la sua specifica. In un **software** possiamo riscontrare i seguenti **problemi**: - **Failure**: comportamento del software non previsto dalla sua specifica; - **Fault**: difetto del sorgente (detto anche bug), causa di un failure; - **Error**: causa di un difetto; esempio: un errore umano d'interpretazione della specifica o nell'uso di un metodo. **Purtroppo, i software sono difettosi** perché gli esseri umani commettono errori, specie quando eseguono compiti complessi. I programmatori esperti commettono in media un errore ogni 10 righe, circa il 50% degli errori di codifica vengono catturati a tempo di compilazione, altri errori vengono catturati col testing e circa il 15% degli errori sono ancora nel sistema quando viene consegnato al cliente. Assicurare la qualità di un prodotto o servizio è difficile e nel caso del software, valutarla o garantirla, è particolarmente complesso. **Qualsiasi valutazione di qualità inizia dallo scopo** (goal), che ha chi la vuole valutare e chi valuta la qualità di un'entità dovrebbe: - Avere chiari i propri obiettivi; - Legarli a domande specifiche sull'entità (prodotto o processo) oggetto di analisi; - Definire metriche capaci di analizzare e quantificare le qualità richieste ai prodotti rispetto agli obiettivi. Le **metriche** che vengono definite debbono correlarsi agli obiettivi (goals) dell'organizzazione. Perciò le misurazioni dovrebbero essere utili e costruttive, perché l'organizzazione deve imparare analizzandoli e le metriche dovrebbero riflettere il punto di vista di diverse parti interessate. **Pianificazione di un Modello di Qualità**: - **Sviluppo dei goal** e delle misure associate alla qualità; - **Generazione di domande** che definiscono i goal quantificandoli; - **Specificare le misure** da collezionare in conformità al goal; - **Sviluppare i meccanismi operativi** di collezione delle misure; - **Raccogliere i dati e analizzarli** onde sviluppare azioni correttive; - **Analizzare i dati post-mortem** per raccomandazioni sul futuro. Però **la qualità non è soltanto assenza di difetti del prodotto finale** (questo è solo una parte), spesso i requisiti sulle qualità esterne (es. efficienza, affidabilità) e quelle sulle qualità interne (es. manutenibilità, riusabilità) sono in antitesi, e vanno bilanciate. Inoltre può capitare che specifiche siano incomplete e inconsistenti, ma non possiamo aspettare che le specifiche migliorino prima di preoccuparci della qualità del prodotto finale. **Ci sono varie attività legate alla qualità**: - **Testing**: processo di investigazione sui rischi connessi all'esecuzione di un sistema software. Gli artefatti prodotti dal testing sono piani di test che includono casi di test, le suite di test che automatizzano il testing, e i rapporti di test che contengono i risultati dell'attività. Purtroppo il testing si può usare per provare la presenza di errori in un programma, ma mai per dimostrarne l'assenza; - **Misurazione**: indicatori di qualità sia mediante ispezione che mediante esecuzione; - **Verifica:** è un confronto di un prodotto con la sua specifica (ovvero, confronto di un prodotto con i suoi requisiti). L'attività di verifica, così come quella di documentazione, non è una fase separata del processo, tuttavia è opportuno che sia effettuata da persone diverse da quelle coinvolte nel design o nella codifica. Inoltre ogni documento prodotto dovrebbe essere controllato (possibilmente da persone diverse dagli autori del documento) e sistematicamente documentato. - **Validazione:** è l'accettazione del prodotto da parte del committente; - **Certificazione**: analisi delle funzioni rispetto ai requisiti di legge da certificare. Il testing ha lo scopo di verificare che il codice soddisfi i requisiti, però non sempre essi sono chiari. Inoltre molti sviluppatori non conoscono né le tecniche di testing né i relativi strumenti, perciò bisogna sempre **definire un piano di test**, che deve: - Essere completo, ma non eccessivo (usa una matrice di test e include test positivi e negativi); - Trovare i casi di test interessanti; - Eseguire ogni test almeno due volte; - Aggiornare il piano durante lo sviluppo; - Guardarsi dall'obsolescenza del prodotto e dei suoi test. I test sono attacchi al software condotti per vedere se ci sono difetti o rischi. Possiamo distinguere due **metodi di test**, che sono quelli **diretti** (automatici, di basso livello e sfruttano le specifiche) e quelli **indiretti** (manuali, di alto livello, si basano su scenari realistici). Inoltre possiamo distinguere due tipi di **testing di un modulo**: - **Black-box testing**: i casi di test sono definiti nel documento di specifica e il codice del prodotto viene ignorato durante il testing. Il black box testing si effettua senza conoscere il sorgente e consiste nell'usare la specifica del prodotto per predisporre un insieme di casi di test che massimizzi la probabilità di trovare un errore e minimizzi quella che i due test diversi trovino lo stesso errore. Dopo aver identificato nella specifica tutte le funzioni di un modulo, si definiscono i dati di test necessari per controllare ciascuna funzione separatamente; - **White-box testing**: i casi di test sono definiti sul codice sorgente. **I costi della qualità** nel processo produttivo sono i costi che si sostengono per adeguare la qualità del prodotto alla qualità richiesta e distinguiamo due costi principali: - **Costo della conformità**: per soddisfare tutte le esigenze espresse ed implicite; - **Costo della non conformità**: per rimettere a posto gli insuccessi interni ed esterni. Diversi **enti di standardizzazione** hanno cercato di integrare vari approcci alla definizione della qualità, partendo dalla consapevolezza che la qualità è un attributo che varia in funzione del: - **Percettore**; - **Del contesto di percezione**; - **Dello scopo e costo del prodotto**. Introduzione alle Misurazioni ============================= **La misurazione** ci aiuta a comprendere il mondo, ad interagire con l'ambiente circostante e migliorare la nostra vita. **Dovrebbe essere una parte naturale delle attività di sviluppo e manutenzione del software**: - **Per gli sviluppatori**, le misurazioni sono utili per capire se i requisiti sono consistenti e completi, se il design è di buona qualità e se il codice è testabile; - **Per i manager di progetto**, le misurazioni degli attributi del processo e del prodotto rendono possibile dire quando il software è pronto per il rilascio, se il budget rischia di essere superato e se la schedulazione è rispettata; - **Per gli utenti e per i committenti**, le misurazioni degli aspetti del prodotto finale sono utili per stabilire se è conforme alle aspettative di qualità e se da ciò che ci si aspetta; - **Per i manutentori,** le misurazioni permettono di esaminare il prodotto corrente per vedere cosa dovrebbe essere integrato o migliorato. **La misurazione è il processo attraverso cui i numeri vengono assegnati ad entità del mondo reale**, in modo tale da determinarne il valore secondo regole chiaramente definite. **La misurazione cattura informazione sugli attributi di entità**, dove: - L'**entità** è un oggetto oppure un evento del mondo reale che desideriamo misurare; - L'**attributo** è un aspetto o una caratteristica dell'entità; - Le **regole** (e scale) servono per assegnare valore agli attributi. Inoltre **la misurazione descrive l'entità identificando le caratteristiche** (attributi) **che sono importanti per distinguere una entità da un'altra**. Quando definiamo le entità attraverso gli attributi, questi sono definiti usando numeri e simboli. Quindi **numeri e simboli sono astrazioni che usiamo per rappresentare le nostre percezioni del mondo reale** e possiamo trarre conclusioni su una entità (oggetto) basandoci sui valori dei suoi attributi (caratteristiche di qualità). Le **scale di misurazione** sono strumenti fondamentali per descrivere e analizzare dati quantitativi e qualitativi. Ogni scala fornisce regole specifiche per rappresentare i dati e il tipo di analisi che si può eseguire. Ecco una spiegazione semplificata: 1. **Nominale** - Serve a classificare dati in **categorie** senza ordine tra di loro. - Non si possono confrontare grandezze o fare operazioni matematiche. - Esempio: Colori (rosso, blu, verde), Sesso (maschio, femmina). 2. **Ordinale** - Classifica i dati in categorie **ordinate** (in senso crescente o decrescente). - L\'ordine ha un significato, ma la **distanza tra i valori** non è interpretabile. - Esempio: Livelli di istruzione (elementare, media, superiore). 3. **Intervallo** - Aggiunge all\'ordine la possibilità di misurare la **distanza tra i valori**. - Non ha uno zero assoluto, quindi non è possibile interpretare proporzioni o rapporti. - Operazioni consentite: somma e sottrazione. - Esempio: Temperatura in Celsius o Fahrenheit (20°C non è il doppio di 10°C). 4. **Ratio** - Ha un **zero assoluto**, quindi è possibile confrontare proporzioni e rapporti. - Si possono eseguire tutte le operazioni aritmetiche (somma, sottrazione, moltiplicazione, divisione). - Esempio: Peso (4 kg è il doppio di 2 kg), altezza, tempo. 5. **Assoluta** - Caso particolare della scala **Ratio**, dove l\'unico modo per misurare è **contare**. - Non esistono unità arbitrarie o trasformazioni. - Esempio: Numero di oggetti (5 mele, 10 penne). Ha significato applicare una **funzione statistica** ad un **tipo di scala** se le affermazioni dedotte dall'applicazioni delle funzioni sono invarianti rispetto alla scala utilizzata. Immagine che contiene tavolo Descrizione generata automaticamente Al fine di limitare e contenere la soggettività delle misure, **[si definisce e associa un Modello Descrittivo]**, alla metrica. Così ogni valore della scala è definito con una descrizione testuale per meglio chiarire e spiegare i range dei valori e ridurre la interpretazione soggettiva delle informazioni. In caso di misure oggettive è necessario fornire un **Modello Quantitativo** (equazioni, modello di calcolo, formula) associato alla metrica. **La misurazione rende i concetti più visibili e dunque più comprensibili e controllabili**. Nelle scienze fisiche, mediche, economiche, ingegnerie materiali, la misurazione è una procedura radicata in tutti i processi, inoltre la misurazione di attributi quale la intelligenza umana, la qualità dell'aria, l'inflazione, possono influenzare le decisioni di tutti i giorni. **Gli attributi** (caratteristiche di qualità) **del software** sono **[l'affidabilità, l'usabilità e la manutenibilità]**, e vengono quantificati mediante specifici indicatori che consentono di misurarli. **Esistono due tipi di quantificazioni**: - **Misurazione**, che è una quantificazione diretta, ovvero è ciò che posso rilevare direttamente dall'entità, come ad esempio l'altezza di un albero, il peso di una persona, la dimensione di un software in linee di codice; - **Calcolo**, che è una quantificazione indiretta, ovvero devo utilizzare un processo per ottenere la quantificazione. In questo caso si combinano diverse misure come la media aritmetica, oppure le aliquote delle tasse. Nella software engineering il calcolo e la misurazione ci forniscono un punteggio complessivo basato su una serie di misure ciascuna delle quali cattura un aspetto di ciò che vogliamo misurare. **L'ingegneria del software è una disciplina uomo-centrica**, a differenza di altre discipline ingegneristiche che usano sistematicamente metodi basati su modelli e teorie. Inoltre **l'ingegneria del software** descrive l'insieme delle tecniche che adottano un approccio ingegneristico per la costruzione e il supporto del software. Ogni attività è compresa e controllata così da ridurre sorprese man mano che il software è specificato, progettato, sviluppato e manutenuto, inoltre le attività di software engineering includono gestione, costi, pianificazione, modellazione, analisi, specifica, progettazione, implementazione, verifica e manutenzione. Quando la **misurazione** viene **trascurata** possono verificarsi: - **Fallimenti** nello stabilire gli **obiettivi** misurabili per il prodotto software; - **Fallimenti** nella **comprensione** e **quantificazione** dei costi dei progetti software; - **Non siamo in grado di prevedere la qualità dei prodotti**; - **Ci affidiamo ad evidenze aneddotiche** per convincerci a provare nuove tecnologie di sviluppo, senza fare un attento e controllato studio per determinare se la tecnologia è più efficiente ed effettiva. La mancanza di misurazione nella ingegneria del software è aggravata dalla mancanza di un approccio rigoroso. **È importante misurare** e registrare le caratteristiche di progetti buoni e cattivi al fine di interpretare i risultati, individuare i problemi, individuare e applicare azioni correttive e ottenere evidenze sui cambiamenti. Perciò sarebbe opportuno classificare gli **scopi della misurazione**: - **Comprendere**: le misure aiutano a comprendere cosa accade durante le attività di sviluppo e manutenzione, inoltre rendono più visibili gli aspetti del processo e del prodotto; - **Controllare**: le misure aiutano a controllare cosa accade nei progetti. Sulla base delle baseline (valori soglia), degli obiettivi e della relazione tra valori rilevati e valori obiettivo, è possibile fare previsioni, e apportare cambiamenti ai processi e ai prodotti in modo da soddisfare gli obiettivi di qualità; - **Migliorare**: la misurazione ci incoraggia a migliorare processi e prodotti basati sui risultati ottenuti e sulle tendenze nel tempo. In base alle analisi, **le misure raccolte** (dati) sono utilizzate non solo per valutare il processo, ma anche quale **indicatore delle aree problematiche** da cui individuare eventuali azioni di miglioramento. Esistono **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 di processo e delle tecnologie sui prodotti e sui processi stessi; - **Fare previsioni**: comprendere le relazioni tra processi e prodotti e costruire modelli basati su tali relazioni, in modo che i valori che osserviamo per alcuni attributi possano essere utilizzati per predire gli altri; - **Migliorare**: raccogliere informazioni quantitative per identificare le inefficienze e altre opportunità per migliorare la qualità dei prodotti e le prestazioni di processo. Per **soddisfare gli obiettivi di qualità** richiesti le misure rilevate sui prodotti e sui processi devono raggiungere predefinite soglie, che sono dipendenti dal contesto di esecuzione del processo e dal committente del prodotto. Normalmente si definisce: - Un **intervallo di successo** entro i quali il processo od il prodotto si considera abbia raggiunto l'obiettivo; - Una **soglia di insuccesso** al di sotto della quale il processo od il prodotto è rigettato. Paradigma GQM (Goal, Question, Metric) ====================================== Il **GQM** è un paradigma che fornisce le modalità di **[costruzione di modelli]** [orientati agli obiettivi di qualità attraverso linee guida.] Esso è un approccio sistematico per specializzare gli obiettivi sulla base delle esigenze di progetto e di organizzazione, inoltre tale approccio [assicura] che l'operatività dei risultati delle misurazioni sia anch'essa sistematica, ovvero alla stessa combinazione di [valori delle misure sia associabile un'unica interpretazione, più oggettiva possibile.] [Lo **scopo del GQM** è quello di assicurare *l'adeguatezza, la consistenza e la completezza* del modello di qualità], di valutare e controllare la complessità del piano di misurazione e di comprendere la dipendenza tra entità osservabili e relativi attributi della qualità che si vuole misurare. [Il metodo **GQM (Goal-Question-Metric)** è un approccio] [strutturato per definire e utilizzare metriche,] tipicamente applicato nei contesti di valutazione e miglioramento di processi o prodotti. Il modello è suddiviso in tre livelli principali: **1. Obiettivo (Goal)** [Questo livello definisce in modo chiaro e formale ciò che si vuole raggiungere con il modello metrico]. L\'obiettivo viene descritto considerando: - **[Oggetto]**: cosa si vuole misurare (es. un prodotto o un processo). - **[Scopo]**: la finalità della misurazione (es. migliorare, valutare, monitorare). - **[Prospettiva]**: l\'aspetto o [fattore] di qualità da [analizzar]e (es. [efficienza, affidabilità]). - **Punto di vista**: [lo stakeholder interessato alla misurazio]ne (es. cliente, sviluppatore). - **Ambiente**: il contesto in cui si effettua la misurazione (es. specifici progetti o condizioni operative). **2. Quesiti (Question)** [Sono domande logiche che permettono di raccogliere le informazioni necessarie per raggiungere l\'obiettivo]. Le categorie principali sono: - **Conformità del [processo]**[:] verifica se il processo reale segue le regole definite. - **Conformità ai [requisiti del processo]**: verifica se strumenti, personale e procedure sono adeguati. - **[Attributi logici e fisici]**: analizza quantitativamente il prodotto, valutando [parametri come dimensione e complessità.] - **[Contesto operativo]**: misura aspetti relativi all\'utilizzatore e al suo modo di interagire con il prodotto. **3. Metriche (Metric)** Rappresentano i dati operativi da raccogliere per rispondere ai quesiti. - [Le metriche sono usate per quantificare attributi], ma non sempre i valori raccolti sono immediatamente comprensibili. - [È fondamentale **interpretare i valori**] confrontandoli con dati simili o standard di riferimento per ottenere un significato pratico. Il **ciclo di vita del GQM** è così organizzato: - **Individuazione del progetto e caratterizzazione del contesto di riferimento**: questa prima fase serve a specificare [il focus della valutazione], in modo da poter identificare le entità da valutare; - **Progettazione del modello di qualità**: utilizzando esperienza pregressa e l'intervento degli stakeholder è possibile [definire gli obiettivi, i quesiti e le metriche]; - **Verifica della correttezza** **e della completezza**: si [effettua una verifica sulla correttezza sintattica e semantica;] - **Validazione del modello di qualità**: [si ispeziona il modello di qualità con tutti gli stakeholder, per verificare se le misure utilizzate nel modello rispondono ai valori che ognuno vede nell'obiettivo]; - **Produzione di un piano di misurazione**: [si specificano le misure osservate e calcolate;] - **Esecuzione del piano e raccolta di dati delle misurazioni**: le metriche osservate sono raccolte direttamente sull'entità che si stava valutando e le metriche calcolate sono ottenute dalle metriche osservate, sulla base di ciascun modello di calcolo fornito; - **Controllo della correttezza, completezza e consistenza dei dati raccolti**: [si eliminano i dati inutilizzati;] - **Elaborazione dei dati, interpretazione degli stessi e produzione dei relativi rapporti**: [si sintetizzano i dati in modo da facilitarne l'interpretazione tramite grafici] e si individuano i punti di debolezza del processo; - **Analisi a posteriori: per migliorare eventualmente i fattori del GQM in questa fase devono essere confermati i criteri di validità del modello di qualità, validate le interpretazioni delle misure e validate le relazioni tra le azioni migliorative ed i risultati attesi;** - **Punti di debolezza di un sistema di qualità**: vengono analizzate la complessità del sistema di qualità, la comprensibilità del sistema di qualità e l'operatività del sistema di qualità.  1. **Quadrante in alto a sinistra: Le condizioni** - **Qui vengono elencate le situazioni o i fattori che influenzano una decisione (ad esempio, \"temperatura\", \"livello di risorse\").** - **Rappresentano cosa bisogna osservare o valutare.** 2. **Quadrante in alto a destra: Le combinazioni di valori delle condizioni** - **Questo spazio mostra tutte le possibili combinazioni di valori che le condizioni possono assumere ([ad esempio, \"temperatura alta\" + \"risorse sufficienti\").]** - **[Ogni combinazione corrisponde a una regola di decisione: cioè una situazione ben definita.]** 3. **Quadrante in basso a sinistra: Le componenti di base** - **Qui sono elencate le azioni o elementi di base necessari per attuare le decisioni.** - **[Sono le risorse, gli strumenti o le iniziative necessarie per migliorare o reagire.]** 4. **Quadrante in basso a destra: Le iniziative di miglioramento** - **Qui si specificano le azioni da intraprendere per ogni combinazione di condizioni.** - **Ogni azione è collegata a una combinazione di condizioni ed è composta dalle componenti elencate nel quadrante in basso a sinistra.** **Senso logico** **Le tavole di decisione ti permettono di:** 1. **Identificare chiaramente le condizioni che influenzano una decisione.** 2. **Creare regole di decisione, combinando queste condizioni.** 3. **Definire azioni specifiche in base alle regole di decisione.** 4. **Associare le risorse necessarie alle azioni previste.** **L'interpretazione dipende dal numero di regole**, perciò essa è tanto più complessa quante sono le regole necessarie per definire l'interpretazione per un obiettivo. Le **tavole di decisione**, però hanno dei **punti deboli**, ad esempio la loro costruzione e verifica richiede molto tempo, inoltre se alcune condizioni hanno domini di definizione a più alta cardinalità il numero di regole aumenta notevolmente. Gestione della Qualità del Software =================================== Secondo lo standard ISO 9000, la **qualità** è definita come l'insieme delle caratteristiche di un prodotto necessarie per soddisfare i requisiti prefissati. Negli ultimi vent'anni il concetto di qualità si è sempre più focalizzato intorno alla soddisfazione dei clienti che richiedono alte prestazioni dei requisiti, sviluppo rapido dei prodotti, livelli di tecnologia più alti, meno difetti e processi spinti al limite. La **qualità** è intesa sia come qualità di processo che di prodotto, siccome 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 la selezioni di elementi buoni dai cattivi. Dopo la guerra, sino [agli anni '50] iniziarono ad [emergere concetti di] **[controllo di qualità]**, in cui venivano usate tecniche matematiche e statistiche, tabelle di campionamento e carte di controllo. Dagli [anni '50-'60] il controllo di qualità è diventato anche **[assicurazione di qualità]** e si poneva maggiore enfasi sulla prevenzione piuttosto che sull'identificazione dei problemi[. Oggi l'attenzione è posta sulla gestione della **qualità** quale **fattore strategico**], includendo aspetti come la qualità definita dai clienti, la qualità legata alla redditività del mercato, la qualità come parte integrante dei processi strategici di pianificazione. [Il **project manager** ha la maggiore responsabilità della gestione di qualità del progetto e 20-30% del lavoro del project office è attribuibile alla gestione della qualità]. Ci sono **sei concetti che supportano la esecuzione di ogni progetto**: - [**Politica di qualità**:] è generalmente un [documento elaborato] [da esperti] [di qualità e supportato dal top management]. Esso stabilisce gli obiettivi di qualità, i livelli di qualità accettabili per l'organizzazione e le responsabilità di ciascun membro nell'applicare la politica di qualità; - **[Obiettivi di qualità]**: [consistono in obiettivi specifici], [insieme all'intervallo di tempo entro cui soddisfarli.] Gli obiettivi devono essere perseguibili e fattibili con quelle che sono le capacità dell'organizzazione stessa e un buon obiettivo deve essere perseguibile, deve definire obiettivi specifici, deve essere comprensibile e deve stabilire scadenze; - **Assicurazione della qualità**: si riferisce [alle attività formali e ai processi manageriali, che assicurano che i prodotti e servizi raggiungano e abbiano i livelli di qualità prefissati]. Essa assicura che lo scopo del progetto, i costi e i tempi siano integrati tra loro; - **Controllo della qualità**: indica l'insieme di attività e tecniche che mirano a creare specifiche caratteristiche di qualità. Essa include il monitoraggio continuo dei processi, l'identificazione e l'eliminazione delle cause di problemi, l'uso di ([Statistical Process Control) **SPC** per ridurre la variabilità dei processi ed incrementarne l'efficaci]a. [Il controllo di qualità certifica che gli obiettivi di qualità dell'organizzazione si stiano raggiungendo.] Le attività di controllo della qualità mirano a migliorare la qualità dal punto di vista della correzione di difetti dei prodotti (e non solo), inoltre in seguito al controllo qualità, è possibile prendere alcune decisioni, come accettare o meno un prodotto, fare rielaborazioni, che permettono ad un prodotto scartato di essere considerato nuovamente valido e modificare il processo che si sta eseguendo; - [**Verifica della qualità**: è una valutazione indipendente], fatta da parte di personale qualificato, il quale verifica che il progetto sia conforme ai requisiti di qualità e che stia procedendo secondo le procedure e le politiche stabilite; - [**Piano di qualità**: dettaglia come il team di management intende svolgere la politica di qualità dell'organizzazione]. Il piano di qualità include dettagli sugli aspetti di controllo qualità, [assicurazione della qualità], approcci per il miglioramento continuo da mettere in atto durante il progetto. Esso può essere formale o informale, molto dettagliato o loscamente pianificato, dipendentemente dalle esigenze di progetto. Esso può portare come benefici la riduzione dei costi e il project overrun in seguito a rilavorazioni. Immagine che contiene testo, schermata, Carattere, design Descrizione generata automaticamente Metodi statistici hanno acquisito sempre più importanza quale strumento di supporto alle decisioni sulla base di dati quantificabili. Si distinguono **strumenti** per identificare ed analizzare opportunità di miglioramento, consentendo di organizzare i dati numerici, facilitare la pianificazione e migliorare il processo decisionale. Alcuni di questi strumenti sono: - **Data tables**: forniscono una maniera sistematica per raccogliere e mostrare dati e sono progettate principalmente per collezionare dati, soprattutto provenienti da strumenti automatici; - **Diagramma causa-effetto**: permette di identificare le relazioni tra un effetto e le sue potenziali cause. Esso è composto dai seguenti sei step: identificare il problema usando vari tool di controllo statistico, selezionare il team di brainstorming in modo da contribuire ad individuare le cause, specificare i Problem box, specificare le categorie che contribuiscono al problema, identificare le cause legate a ciascuna categoria e identificare le azioni correttive; - **Scatter Plot**: organizza i dati usando due variabili chiamate indipendente e dipendente, ed è una buona modalità per individuare eventuali dipendenze tra variabili. Dall'analisi del grafico 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 sistematica (una linea, una curva); - **Istogrammi**: sono una rappresentazione grafica dei dati in termini di frequenza della distribuzione. Fornisce un quadro dei dati rispetto ad un prefissato data point nel tempo. Non mostra trend o distribuzioni nel tempo. Ogni barra è una caratteristica di una situazione e l'altezza indica la frequenza di quella caratteristica; - **Pareto chart**: particolare tipo di istogramma in cui le variabili sono ordinate per frequenza di occorrenza, per aiutare a identificare quelli che contribuiscono maggiormente a problemi di qualità; - **Diagramma di flusso**: rappresenta graficamente la logica e il flusso dei processi, consentendo di analizzare i problemi e decidere come possono migliorare; - **Trend Analysis**: è il metodo statistico usato per determinare la migliore equazione che interpola i punti di uno scatter plot. L'equazione individuata descrive la relazione tra la variabile dipendente (output) e quella indipendente (input) ed è usato per prevedere gli effetti dei cambiamenti durante il processo; - **Run Chart**: è un diagramma che mostra il trend storico e il modello di variazione dell'andamento di un processo nel tempo. Inoltre il diagramma è costituito da linee che collegano i punti di osservazione (dati) tracciandoli in relazione ad una scala temporale; - **Control Chart**: è una rappresentazione grafica di dati che mostra i risultati di un processo nel tempo e principalmente sono utilizzati per prevenire i difetti. Si differenziano 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 dovuti ad eventi casuali in natura; invece, quando un processo è fuori controllo, le variazioni nei risultati non sono dovuti a eventi casuali, ma a problemi nel processo. In tal caso è necessario identificare la causa e regolare il processo per correggere o eliminarli.  [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 allarme di anomalie e disservizi. Il monitoraggio implica la necessità di definire opportune soglie utili a valutare le prestazioni osservate rispetto a quelle attese e sottende la necessità di individuare comportamenti anomali e reagire prontamente. [Inoltre, deve avere una sensibilità variabile in funzione del fenomeno osservato.] Miglioramento continuo dei processi =================================== Poiché [il processo software è uomo-centrico] ed [il comportamento di questo] [non è né simmetrico né conforme,] **[la qualità dei processi deve essere continuamente monitorata]**. La diversità dei processi e quella dell'apprendimento delle tecnologie che ogni processo contiene, rende il processo software sperimentale, pertanto, il suo miglioramento deve essere graduale. Ci sono vari **[approcci] che puntano al [miglioramento] della qualità**: - [**Schemi**: definiscono i livelli di qualità dei processi] e come essi si caratterizzano ([**ISO**, **CMM** e **SPICE**]); - [**Paradigmi**: definiscono una strategia per raggiungere un prefissato livello] di qualità e come esso si migliori (**PDCA**, **QIP** ed **EF**). [La **ISO 9000** è un insieme di standard per il controllo e la guida della qualità in tutti i settori produttivi]. L'organizzazione che adotta l'ISO 9000 deve dotarsi di [un sistema qualità], [che definisca le modalità per valutare, controllare e guidare la qualità di tutti i processi di produzione]. La **norma** è un documento prodotto attraverso consenso e [approvato da un organismo riconosciuto], [fornisce le caratteristiche o le linee guida relative a determinate attività o prodotti e ha lo scopo di assicurare ordine ed uniformità in un determinato contesto]. Inoltre, punta a salvaguardare gli interessi dei consumatori e della collettività, migliorare il sistema produttivo attraverso l'unificazione dei processi e dei prodotti, [migliorare lo scambio di informazioni attraverso l'applicazione di standard per simboli, codici, interfacce e promuove la sicurezza dell'uomo e dell'ambiente]. I **processi primari** portano alla realizzazione della missione dell'organizzazione. Determinano la creazione, realizzazione, manutenzione e, in generale, la produzione del sistema software. I processi primari si suddividono in **cinque categorie**: - **Acquisizione**: tale processo ha lo scopo di definire le attività [che l'acquirente deve seguire per venire in possesso di un determinato software]. ***[Si rivolge alle organizzazioni che acquistano un sistema softwar]***e, un prodotto software o un servizio software; - **Fornitura**: tale processo ha lo scopo di definire le attività che il fornitore deve seguire per rendere disponibile l'acquisizione di software da parte di un cliente. ***[Si rivolge alle organizzazioni che forniscono un sistema softwar]***e, un prodotto software o un servizio software rivolto all'acquirente; - **Sviluppo**: tale processo ha lo scopo di definire le attività che devono essere seguite da un'organizzazione per la definizione e lo sviluppo di un prodotto software; - **Gestione operativa**: tale processo ha lo scopo di definire le attività dell'operatore, ossia di colui che utilizza un calcolatore all'interno dell'organizzazione stessa, di cui fa parte; - **Manutenzione**: tale processo ha lo scopo di definire le attività che l'organizzazione deve seguire per la manutenzione di un prodotto software.  I **processi di supporto** sono necessari, siccome la loro esecuzione coadiuva l'esecuzione dei processi primari, ai quali offrono servizi che contribuiscono al successo e alla qualità di un progetto. I processi di supporto si suddividono in **otto categorie**: - **Documentazione**: la preparazione e l'utilizzazione della documentazione sono intese come attività dinamiche con alto valore aggiunto. La documentazione è importante per il miglioramento della qualità. Quando le procedure sono documentate, spiegate ed attuate è possibile determinare con confidenza come sono solitamente eseguiti i processi e misurare la prestazione corrente. Di conseguenza, l'affidabilità della misurazione dell'effetto di una modifica è maggiore. Inoltre, le procedure operative correnti documentate sono essenziali per conservare i benefici derivanti da un'attività di miglioramento della qualità. - **Gestione della Configurazione**: rappresenta il fulcro intorno al quale ruota tutta la produzione ed include le operazioni necessarie alla catalogazione, identificazione e recupero di un qualsiasi manufatto prodotto all'interno dell'organizzazione. La gestione della configurazione è necessaria, in generale, per controllare l'integrità di tutti gli artefatti ottenuti dall'esecuzione del processo e per verificare la loro aderenza agli standard imposti. - **Assicurazione di qualità**: definisce le attività necessarie a certificare oggettivamente che il prodotto software e il processo utilizzato per la sua costruzione, sono conformi agli standard qualitativi che l'organizzazione ha fissato; - **Verifica**: definisce le attività da seguire per la verifica del processo utilizzato. La verifica viene effettuata alla fine di ogni fase prevista, e determina se l'esecuzione del processo è conforme al modello di processo adottato e il prodotto ottenuto è conforme al prodotto atteso in termini di costi di realizzazione, risorse impiegate, requisiti, vincoli imposti; - **Validazione**: tale processo ha lo scopo di definire le attività da seguire per la validazione di un prodotto software; - **Revisione o joint review**: definisce le attività da seguire per valutare lo stato e i prodotti di un'attività. Lo scopo di tale processo è di informare il cliente sul progresso del progetto e permette di assicurare che i prodotti sviluppati soddisfino le sue necessità; - **Audit**: definisce le attività necessarie a determinare la conformità del prodotto software ai requisiti, al processo e al contratto (in alcuni casi questo processo viene assorbito dal processo di assicurazione della qualità o da quelli di verifica e validazione); - **Gestione dei problemi**: definisce le attività necessarie ad individuare e risolvere i problemi, qualsiasi sia la loro natura, e qualsiasi sia la fase in cui vengono riscontrati. Immagine che contiene testo, schermata, cerchio, design Descrizione generata automaticamente I **processi organizzativi** sono utilizzati per definire ed implementare una struttura logica di fondo, da seguire, al fine di migliorare la struttura stessa e i processi utilizzati all'interno dell'organizzazione. Con la parola struttura si intende far riferimento alla ripartizione di compiti, competenze, responsabilità e potere decisionale, all'interno dell'organizzazione. I processi organizzativi si suddividono in **quattro categorie**: - **Gestione processo**: definisce le attività base per la gestione dell'organizzazione e dei processi coinvolti nel ciclo di vita di un progetto o prodotto software; - **Gestione infrastrutture**: definisce le attività da seguire per determinare e manutenere le infrastrutture di cui necessitano gli altri processi. Per infrastrutture si intende Hardware, Software, tools, tecniche e standard; - **Miglioramento**: definisce le attività necessarie per determinare, consolidare, misurare, controllare e migliorare i processi coinvolti nel ciclo di vita di un software; - **Addestramento e Formazione**: definisce le attività necessarie a dare un'adeguata formazione, cioè ad istruire e mantenere aggiornato secondo le necessità il personale interno all'organizzazione. Lo **SPICE project** (ISO 15504) è uno standard internazionale, che serve per la **comprensione** dei processi software operanti nella propria organizzazione, per la **determinazione** delle capacità dei processi sia della propria organizzazione, sia delle organizzazioni fornitrici e come **guida** per il miglioramento del processo, attraverso le analisi delle misure e l'individuazione dei processi da migliorare**[. ISO 15504 è il modello di riferimento per i modelli di maturità]** (costituito da livelli di capacità che a loro volta sono costituiti dagli attributi del processo e consistono inoltre in pratiche generiche), **[rispetto ai quali i valutatori]**, sulla base di evidenze raccolte durante il processo di valutazione, **[possono determinare la capacità dell'organizzazione di fornire prodott]**i (software, sistemi e servizi IT). Tutti i processi di un'organizzazione sono classificati in **categorie**: - **Fornitore-Committente**: regolano la relazione con i committenti ed impattano consistentemente sulla soddisfazione di questi ultimi; - **Ingegneristici**: specifica, progettazione, implementazione o manutenzione dei sistemi e dei prodotti software; - **Progetti**: definizione dei processi di produzione, controllo e guida degli stessi durante la loro esecuzione; - **Supporto**: supporto ai processi di produzione per assicurare l'efficacia di questi ultimi; - **Organizzazione**: definizione degli obiettivi di business e di processi di sviluppo, prodotti, risorse disponibili che consentono di raggiungere gli obiettivi di business. Il **livello di capacità** è un indicatore della qualità raggiunta nella gestione del processo stesso ed esso 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 di processi adottati dall\'unità organizzativa oggetto dell\'assessment. Essi si distinguono in: Il **raggiungimento di un livello di capacità** è determinato dal grado di presenza (achievement) nel processo di 9 attributi di processo distribuiti sui 5 diversi livelli di capacità. Ogni attributo di processo rappresenta una caratteristica misurabile del processo e il valutatore, con l'aiuto di indicatori ed esaminando le evidenze oggettive, esprime un giudizio sul grado di presenza (achievement) dell'attributo, attraverso una scala di valori definita (4 valori). La valutazione (rating) si basa sulle evidenze raccolte rispetto a ciascun attributo, che ne dimostrano il livello di soddisfacimento ISO 15504 fornisce **linee guida per eseguire una valutazione** (assessment), la quale avviene nel seguente modo: - Il **valutatore raccoglie i dati** relativamente ad un processo attraverso interviste con persone che eseguono il processo, raccolta di documenti e dati di qualità e raccolta di dati statistici di processo; - Il **valutatore convalida i dati** per assicurarsi che siano accurati e coprano completamente l\'ambito della valutazione; - Il **valutatore valuta i dati** (in base alla sua esperienza) rispetto alle pratiche di base di un processo e alle pratiche generiche della capacità; - Poiché la valutazione del processo (rating) si basa sul giudizio di un esperto, è fondamentale **verificare qualifiche** **e** **competenze del valutatore**; - Il process rating è presentato **come risultati preliminari allo sponsor**, per verificare che condividano l'accuratezza della valutazione. In alcuni casi, potrebbero esserci cicli di feedback che richiedono un\'ulteriore valutazione prima che si raggiunga la valutazione finale del processo. Il **CMM** (capability maturity model) permette di effettuare il **riesame** della propria organizzazione per identificare i punti di forza e di debolezza in un'organizzazione, di **valutare** organizzazioni esterne per stimare i rischi nel selezionare un fornitore di servizi e di prodotti (es. gare di appalto, commesse) e permette di **fare da guida** per il miglioramento del processo attraverso le analisi delle misure e la individuazione dei processi da migliorare. Un **livello di maturità** è uno stadio evolutivo ben definito in un cammino di maturazione di un\'organizzazione produttrice di software. Ogni livello è uno strato delle fondamenta per il miglioramento continuo e nel CMM sono [previsti] **cinque livelli di maturità**: - **Iniziale**: il processo non è ben definito, il suo successo dipende solo dall'impegno personale degli sviluppatori; - **Ripetibile**: sono eseguite le attività di base per la gestione dei progetti: traccia dei costi, della schedulazione e della funzionalità. Il processo è sufficientemente disciplinato per essere ripetuto; - **Definito**: il processo è conforme agli standard dell'organizzazione e tutte le attività ingegneristiche e manageriali sono documentate; - **Gestito**: dettagliate misure dei processi e dei prodotti sono rilevate e raccolte, così che entrambi siano ben capiti; - **Ottimizzato**: il miglioramento continuo dei processi è attivo sfruttando le analisi post-mortem dei progetti eseguiti e le opportunità di tecnologie innovative. *[Ogni **area di processi chiave**]* identifica un insieme di attività che [se eseguite collettivamente assicurano la crescita delle capacità dei processi.] Le aree dei processi chiave [sono organizzate per **fattori comuni**] che sono attributi, [per assicurare che l'esecuzione] [e l'istituzionalizzazion]e di un processo [chiave sia efficace, ripetibile e definitiva]. APPROCCI AL MIGLIORAMENTO DELLA QUALITA ======================================= Paradigmi. Definiscono una strategia per raggiungere un prefissato livello di qualità e come questo si migliora. Questi richiedono un modello di qualità, come ad esempio il PDCA (Plan Do Check Act), IL QIP (Quality Improvement Process) e L'EF (Experience Factory). Il **ciclo di Deming** (PDCA) è costituito da: - **Pianificazione** (Plan): si definiscono gli obiettivi e le attività necessarie per fornire i risultati in accordanza con i requisit, le policy e i piani. - **Realizzazione** (Do): implemento il processo. - **Valutazione** (Check): monitoro e misuro il processo e i risultati confrontadoli con le policy, gli obbiettivi e i requisiti del prodotto e prendo noto dei risultati. - **Intervento** (Act): fare il necessario per migliorare continunuamente le prestazioni del processo. Nel **QIP** vi è un miglioramento dei processi che deve essere continuo, inoltre il miglioramento è un processo con le seguenti attività: - **Caratterizzare e comprendere**: si determinano le caratteristiche del progetto e dell'ambiente in cui esso si svolge; - **Definire gli obiettivi**: si determinano gli obiettivi che sono rappresentativi delle esigenze del contesto e del progetto preso in esame; - **Selezione del processo**: si determinano gli appropriati modelli di processo, metodi e tools da migliorare facendo attenzione che siano coerenti con gli obiettivi scelti. I **principi alla base del QIP** sono: - **Esecuzione**: attivazione del processo in accordo con i goals definiti; - **Analisi**: le misure sono raccolte ed analizzate per determinare le eventuali azioni correttive; - **Pacchettizzazione**: alla fine del progetto i dati raccolti sono analizzati per ricavare lezioni, che sono trasformate in pacchetti da utilizzare nei successivi progetti. **ORGANIZZAZIONE DELLA FABBRICA DI ESPERIENZA**  Software Product Quality ISO 25000 ================================== [Un **prodotto software** è una serie di istruzioni fornite ad un computer per fargli realizzare determinate operazioni rispettando i requisiti concordati con il cliente.] La ISO ha emesso norme che definiscono il modello di qualità del software in vari contesti di utilizzo: - **ISO 9126**: modello di riferimento per definire le caratteristiche di qualità del software e le metriche per la valutazione della qualità che il software possiede; - **ISO 14598**: guida la valutazione della qualità del software secondo i criteri 9126; - **ISO 25000**: integra ISO 9126 e ISO 14598 per la valutazione della qualità di prodotto. La ISO 9126 può essere utilizzata da acquirenti, sviluppatori, auditors, addetti all'assicurazione qualità secondo diverse prospettive, per vari scopi tra cui: - **Definire i requisiti di qualità** del software (quality goals) nei capitolati tecnici o nelle offerte tecniche che vengono prodotte in risposta ai capitolati; - **Validare la completezza** di un documento di specifica dei requisiti o di progettazione del software; - **Identificare obiettivi** che vanno soddisfatti dal disegno tecnico del software; - **Identificare criteri** di assicurazione della qualità e di accettazione, test e collaudo del software; La **norma** si compone delle seguenti parti: - **ISO/IEC 9126-1**: il modello delle caratteristiche e sotto-caratteristiche di qualità del software. Essa inoltre definisce un modello a quattro livelli: - **Tre punti di vista** sulla qualità del software (esterno, interno, in uso) che qualsiasi progetto di sviluppo deve prendere in considerazione e soddisfare; - **I principali attributi** (requisiti qualitativi) che qualificano un software secondo tre punti di vista; - **Per ogni attributo**, le sotto-caratteristiche (requisiti quantitativi misurabili) che la rappresentano e che dovranno essere misurate per valutare il livello di qualità effettivamente raggiunto nel software; - **Le metriche** per effettuare le misure. - **ISO/IEC 9126-2**: le metriche per la misura della qualità esterna; - **ISO/IEC 9126-3**: le metriche per la misura della qualità interna; - **ISO/IEC 9126-4**: le metriche per la misura della qualità in uso. [La **qualità interna** rappresenta le proprietà intrinseche del prodotto] [(quelle misurabili direttamente sul codice sorgente]). Si realizza a partire dai requisiti utente (external quality requirements) che rappresentano le specifiche di qualità, così come le dà l'utente, fornendo il primo input al progetto e dalle specifiche tecniche (internal quality requirements) che rappresentano la qualità richiesta dall'utente e tradotte dallo sviluppatore nell'architettura del software, nella struttura del programma e nelle interfacce del software. La **qualità esterna** è quella rappresentata dalle prestazioni del prodotto e dalle funzionalità che offre (il prodotto è visto come una black box da testare). Essa riguarda il comportamento dinamico del software in un dato ambiente operativo e dipende strettamente dai requisiti del cliente, inoltre le caratteristiche di qualità esterne del software lo qualificano in relazione all'ambiente e premettono di osservarne il comportamento mentre è utilizzato operativamente. La **qualità in uso** riguarda il livello con cui il prodotto si dimostra utile all'utente nel suo contesto di utilizzo, in particolare, la capacità del prodotto di dare efficacia ed efficienza al lavoro dell'utente a fronte di una sicurezza di utilizzo e di una soddisfazione nel fare uso del prodotto. [La possiamo definire come una misura della interazione tra utente e prodotto in un determinato contesto d'uso.] La **qualità di un prodotto software** dipende dalla qualità del processo di sviluppo adoperato e dalla maturità dell\'organizzazione che lo produce, con tecniche e strumenti adeguati, determinando una sequenza logica di azioni lungo il ciclo di vita. Il focus sulla qualità cambia durante il **ciclo di vita**: - **All'inizio**, durante la raccolta ed analisi dei requisiti, la qualità è specificata dai requisiti utente, soprattutto da un punto di vista esterno e funzionale; - **Nella fase di progettazione**, la qualità esterna si traduce in un disegno tecnico, confrontandosi con il punto di vista degli sviluppatori sulla qualità interna del software e completandosi con i requisiti impliciti che il software deve rispettare; - **La qualità finale** (quella in uso) deve essere quella appropriata per gli utenti ed il contesto d'uso. Non esiste una qualità perfetta ed assoluta. Esiste quella necessaria e sufficiente per un dato contesto (la qualità è relativa). Le **sei caratteristiche che rappresentano la qualità** esterna ed interna di un prodotto software sono: - **Funzionalità**: capacità di fornire servizi tali da soddisfare, in determinate condizioni, requisiti funzionali espliciti o impliciti (il software fa ciò per il quale è stato acquistato); - **Affidabilità**: capacità di mantenere le prestazioni stabilite nelle condizioni e nei tempi fissati (il software reagisce bene a variazioni esterne); - **Usabilità**: capacità di essere compreso, appreso, usato con soddisfazione dall'utente in determinate condizioni d'uso (il software gestisce bene l'interazione con gli utenti); - **Efficienza**: rapporto fra prestazioni e quantità di risorse utilizzate, in condizioni definite di funzionamento (il software usa bene le risorse disponibili); - **Manutenibilità**: capacità di essere modificato con un impegno contenuto (per evoluzioni o correzioni o adeguamenti); - **Portabilità**: facilità con cui il software può essere trasferito da un ambiente operativo ad un altro. La **qualità in uso è rappresentata da quattro caratteristiche**, che rappresentano il punto di vista dell'utente sul software: - **Efficacia**, la capacità di supportare un utente nel raggiungere i suoi obiettivi con accuratezza e completezza in un dato contesto; - **Produttività**, la capacità di supportare un utente nello spendere l'appropriata quantità di risorse in relazione all'efficacia dei risultati da raggiungere; - **Soddisfazione**, la capacità di soddisfare un utente in un dato contesto d'uso; - **Sicurezza**, la capacità di raggiungere accettabili livelli di rischio per le persone, l'ambiente di utilizzo, le attività dell'utilizzatore, in un dato contesto d'uso. Nella 9126 non è possibile separare nettamente le varie caratteristiche, rispetto ai loro effetti sul software e le diverse caratteristiche interne ed esterne influenzano la qualità in uso. Un problema rilevato nell'uso può essere riferito a caratteristiche di qualità esterne o a caratteristiche interne. Esistono diverse relazioni ed interdipendenze tra le tre classi di metriche e molte delle caratteristiche 9126 possono essere misurate contemporaneamente da metriche interne ed esterne. La **qualità** va quindi misurata **come combinazione** delle misure riferite alle tre qualità, in modo da coprire i diversi punti di vista sulla qualità. La norma ISO 9126 è in corso di revisione ed il modello di qualità del software è confluito nel sistema di norma ISO 25000 senza modifiche. La serie di standard **ISO 25000** ha l'obiettivo di creare un framework per la valutazione della qualità di prodotti software. Esso consiste di cinque raggruppamenti: - **ISO 2500n** (Quality Management Division): definiscono i modelli comuni, termini e definizioni di riferimento per i vari standard; - **ISO 2501n** (Quality Model Division): [definiscono modelli di qualità dettagliati per sistemi software], prodotti software, qualità in uso e dei dati; - **ISO 2502n** (Quality Measurement Division[): definiscono modelli di riferimento per rilevare le misure di prodotto], definizioni matematiche di misure di qualità (osservate, calcolate), suggerimenti per la loro applicazione; - **ISO 2503n** (Quality Requirements Division[): specifica dei requisiti di qualità] che possono essere usati nel processo di elicitazione di requisiti di qualità di un prodotto software; - **ISO 2504n** (Quality Evaluation Division): requisiti, raccomandazioni [e linee guida per la valutazione di prodotti software.] La **ISO 25040** fornisce una descrizione del processo da adottare per valutare la qualità di un prodotto software e stabilisce i requisiti per l'applicazione del processo. Essa è composta da cinque attività: - **Stabilire i requisiti per la valutazione**: si indica lo scopo della validazione, si ottengono i requisiti della qualità del prodotto, si identificano le parti del prodotto da valutare e si definisce il rigore della valutazione; - **Specificare la valutazione**: si selezionano i moduli di valutazione, si definiscono i criteri di decisione per le metriche e si definiscono i criteri di decisione per la valutazione; - **Progettare la valutazione**: si pianificano le attività di valutazione al fine di ottenere una specifica dettagliata del piano di valutazione ed una specifica dei metodi di valutazione; - **Eseguire la valutazione**: si rilevano le misure, si applicano i criteri di decisione per le metriche e per le valutazioni; - **Concludere la valutazione**: si esaminano i risultati delle valutazioni, si creano le relazioni di valutazione, si controlla la qualità delle valutazioni e si ottengono i feedback. Elementi di Project Management ============================== Le attività principali di **Project Management** sono: - **Pianificare**: identificare gli obiettivi del progetto e dell'impresa e definire procedure, policy e quant'altro necessario a raggiungerli. Tra le assunzioni più importanti nell'ambito della pianificazione vi sono quelle relative ai fattori ambientali, che possono influenzare la riuscita del progetto, e ai fattori organizzativi, circa gli assets presenti e futuri dell'impresa come esistenza di metodologie, sistemi di supporto e competenze varie. La pianificazione la si può intendere su più livelli: quello strategico, quando guarda ad obiettivi strategici da conseguire su un arco temporale di 5 o più anni, quello tattico, quando fa riferimento ad obiettivi concreti di medio lungo periodo, da 1 a 5 anni, e quello operativo, quando fa riferimento all'immediato. A livello operativo le previsioni sono più semplici e meno sensibili ai fattori ambientali ed organizzativi, invece a livello strategico-tattico presentano notevoli difficoltà; - **Integrare**: unire i contributi delle varie unità per creare il risultato finale.; - **Eseguire i piani**: coordinare le risorse per raggiungere gli obiettivi nei tempi e costi previsti.. Il **Project Management** è l'applicazione di conoscenze, capacità, strumenti e tecniche alle attività di progetto per soddisfarne i requisiti nel rispetto dei costi e dei tempi definiti, sulla base delle prestazioni e livelli di qualità desiderati e utilizzando efficacemente ed efficientemente le risorse disponibili. A grandi linee, la gestione di un progetto solitamente include: - **L'identificazione dei requisiti**; - Considerare interessi e aspettative degli stakeholder durante la pianificazione e lo svolgimento del progetto; - **Bilanciamento dei vincoli** del progetto in conflitto. La relazione tra tali fattori è tale che, al modificare di uno qualunque di questi fattori, almeno un altro potrà esserne influenzato. Un **progetto ha successo** quando esso risulta concluso nei **tempi definiti**, all'interno del **budget definito**, nel rispetto delle **specifiche** e delle **performance definite**, con l'accettazione del **committente**, con cambiamenti minimi dello **scopo** iniziale, senza aver causato disturbo ed impatti negativi sulla normale **produzione** e senza aver cambiato la **cultura** dell'impresa. Il **Project Management** si sostanzia attraverso la corretta applicazione e integrazione di un insieme di processi logicamente raggruppati in cinque macrocategorie: - **Avvio:** definizione del progetto, studio di fattibilità e autorizzazione per iniziare il progetto. - **Pianificazione**: è l'insieme dei processi necessari a stabilire lo scopo del progetto, raffinare gli obiettivi, definire il flusso di azioni necessarie ad ottenere i risultati desiderati e alla produzione del Project Management Plan. L'insieme dei processi di pianificazione vengono eseguiti iterativamente ogni volta che si verifica un qualche evento che richiede di rivisitare la pianificazione fatta e le assunzioni alla base di questa; - **Esecuzione**: sono i processi che complessivamente consentono la messa in opera della pianificazione fatta ed implicano il coordinamento di tutte le risorse coinvolte. coordinamento delle risorse e adattamento ai cambiamenti. - **Monitoraggio e controllo**: Monitoraggio e controllo: verifica e revisione dello stato del progetto. - **Chiusura**: racchiude l'insieme dei processi necessari alla formale chiusura di un progetto. **Un progetto** è un'iniziativa temporanea intrapresa per creare un prodotto, un servizio o un risultato con caratteristiche di unicità. [Sebbene ci possano essere elementi ripetitivi nel ciclo di lavoro, tale ripetizione non lede le caratteristiche di unicità]. La natura temporanea dei progetti indica un inizio e una fine definiti, e la fine si raggiunge quando sono stati ottenuti gli obiettivi del progetto, quando il progetto è terminato poiché non si riesce a raggiungere tali obiettivi o quando non sussiste più l'esigenza del progetto. Il progetto non è un impegno lavorativo continuativo o l'applicazione di un processo predefinito e ripetitivo che segue le procedure esistenti di un'organizzazione. Il **tempo** è la risorsa più preziosa nella gestione di un progetto, siccome le altre risorse necessarie ad un progetto possono essere reperite, il tempo tipicamente no. Esso influenza fortemente la comunicazione, ovvero uno degli elementi essenziali per la collaborazione ed il coordinamento e permea la gestione progettuale risultando fondamentale nell'avvio, nella pianificazione e nel monitoraggio. Nella **comunicazione** risulta fondamentale, tralasciando per un attimo il tipo di contenuto, ridurre al minimo possibile la distanza temporale. Nonostante la forza della **comunicazione asincrona** come supporto al lavoro (e-mail, gruppi di discussione, tool di management), risulta ancora di cruciale importanza la **comunicazione sincrona** (telefono, conferenze audio-video, condivisione di risorse), siccome la prima spesso ritarda o complica la risoluzione di problemi, invece la seconda supera equivoci, malintesi, piccoli problemi prima che divengono ingestibili. Una possibilità per superare questa barriera è quella di favorire la comunicazione sincrona, minimizzando la differenza tra fusi orari, avvicinandosi il più possibile a zero e tentando di non superare le quattro ore di differenza. Il **Project Management** è fatto di un insieme di linee guida e strumenti rigorosi a supporto della pianificazione, tuttavia nella pratica manageriale, spesso si ricorre a strumenti meno formali e rigorosi, pensati ad hoc per soddisfare un fabbisogno informativo del manager in un dato momento. Questi strumenti, principalmente, non fanno altro che incrociare o presentare, attraverso l'uso di molteplici viste con granularità diversificata, informazioni relative alle componenti principali di un progetto: tempi, costi, uomini, qualità. Un progetto nasce con la creazione del **Project Charter**, a valle del quale occorre dare risposta alle seguenti domande: **what** (WBS e DBS), **when** (Gantt, PERT e CPM), **who** (RACI) e **how** (Budget Estimation, EVM e Quality Management). - Il **work breakdown structure** (WBS)  Suddivide il progetto in sotto-attività semplificando la pianificazione.. Esso definisce quali sono le attività da eseguire e quali sono i rapporti gerarchici tra le attività, inoltre semplifica l'attività di pianificazione in quanto, a seguito della decomposizione in attività più semplici, risultano meno complesse le successive stime di tempi, costi e risorse. I diagrammi **Gantt** aggiungono ulteriori informazioni a quelle già fornite dalla WBS introducendo la coordinata temporale. Mostra tempi, vincoli e stato di avanzamento in un grafico con assi (tempo e attività). Sono essenzialmente riconducibili ad una coppia di assi cartesiani dove sull'asse delle x è rappresentata a coordinata temporale con un'unità opportuna (giorni, settimane, mesi), sull'asse Y sono riportate le attività di progetto così come presentate dalla WBS e l'origine degli assi coincide con l'inizio del progetto. I **PERT Evidenzia durata e vincoli tra attività (senza dettagli temporali)**. Rappresentano uno strumento più snello da utilizzare, soprattutto nelle fasi di pianificazione preliminare.  Il diagramma **PERT** definito ad inizio progetto può essere modificato durante l'esecuzione, ad esempio, supponiamo che B e C richiedono risorse della stessa area funzionale, allora il manager deve ridurre l'attività di B di una settimana (da 2 a 1), spostando risorse dalla C alla B. L'attività di C aumenterà di una settimana (da 3 a 4). Rischedulando il PERT si ha che il CP è ridotto di una settimana (avendo ridotto un'attività del CP), quindi potrebbero cambiare anche gli Slack Times in corrispondenza delle varie attività. **RACI** prende la propria denominazione dalle iniziali dei ruoli previsti in lingua inglese per l\'esecuzione delle attività di progetto: - **Responsible** (R): è colui che esegue l\'attività; - **Accountable** (A): è colui che ha la responsabilità sul risultato dell\'attività. A differenza degli altri tre ruoli, per ciascuna attività deve [essere] univocamente assegnato; - **Consulted** (C): è la persona che aiuta e collabora con il Responsible per l\'esecuzione dell\'attività; - **Informed** (I): è colui che deve essere informato al momento dell\'esecuzione dell\'attività. Il **Project management** fornisce un insieme di strumenti rigorosi a supporto della pianificazione, tuttavia, nella pratica manageriale, spesso si ricorre a strumenti meno formali e rigorosi, pensati ad hoc per soddisfare un fabbisogno informativo del manager in un dato momento. Questi strumenti, principalmente, non fanno altro che incrociare o presentare, attraverso l'uso di molteplici viste con granularità diversificata, informazioni relative alle tre componenti principali di un progetto: tempi, costi, uomini. Algoritmi di Trasformazione =========================== Il **processo** è la descrizione concettuale delle attività da eseguire e dei manufatti di input e output necessari ad ognuna di queste. Per gli scopi del presente modulo didattico, lo si può considerare come una ennupla P=(A, I, O) dove: - A = {Ai} è l'insieme delle attività elementari Ai da eseguire; - I = è l'unione degli I~i~, con I~i~ uguale all'insieme dei manufatti di input necessari all'esecuzione dell'attività Ai; - O = è l'unione degli Oi, con Oi uguale all'insieme dei manufatti di output risultanti dalla esecuzione dell'attività Ai. Il **piano di progetto** indica la sequenza temporale potenziale con cui sono eseguibili le attività A dichiarate nel modello di processo. Il piano di progetto rappresenta la pianificazione ottimale del progetto, in quanto pianifica la sequenza di esecuzione tenendo conto dei soli vincoli di precedenza imposti dal fabbisogno di manufatti delle attività e ignorando i vincoli di tempi, costi e uomini. **Fasi per passare dal processo al piano di progetto**: - Porre nel diagramma PERT il nodo START; - Inizializzare l'insieme MD = {insieme di tutti i manufatti disponibili all'avvio del progetto} e successivamente per ogni attività Ai appartenente ad A non ancora inclusa nel PERT, se Ii è un sottoinsieme di MD allora: - si inserisce nel diagramma PERT il nodo Ni corrispondente all'attività Ai; - poi per ogni nodo Nj già contenuto nel PERT, se Oj intersecato con Ii è diverso dall'insieme vuoto, si collegano gli Ni a Nj nel PERT; - MD = MD unito Oi. - Porre nel diagramma PERT il nodo STOP; - Collegare il nodo STOP a tutti gli Ni senza frecce uscenti. Il **piano esecutivo** indica la sequenza temporale reale delle attività A, considerati i vincoli di progetto e le decisioni manageriali. Il piano esecutivo, partendo dalla pianificazione ottimale dettata dal piano di progetto, e tenendo conto delle precedenze imposte da questo, lo si rimodula sulla base dei vincoli di tempi, costi e uomini. Quindi le attività in sequenza nel piano di progetto devono rimanere tali anche nel piano esecutivo e le attività in parallelo del piano di progetto restano in parallelo nel piano esecutivo, se ci sono tutte le risorse disponibili e vengono rese sequenziali se sono indisponibili le risorse. Il **piano esecutivo** può essere **raffinato** più volte, coerentemente ai cambiamenti del contesto in cui si opera e in generale i suoi raffinamenti implicano l'agire sui possibili parallelismi. Nel caso si debbano eseguire in sequenza due **attività** potenzialmente **eseguibili in parallelo** occorre valutare la priorità d'esecuzione. In caso di **uguale priorità** la decisione può essere adottata con una di queste strategie: - **Efficacia del progetto**: si esegue prima l'attività che produce i manufatti intermedi che sono più immediatamente tracciabili con i manufatti di output, così è più vicina la produzione dei deliverable riconosciuti dal committente; - **Flessibilità della schedulazione**: si esegue prima l'attività che produce i manufatti con più alto scope (numero di attività che utilizzano il manufatto) così che aumenti il numero di attività che possono partire, perché sono pronti i manufatti in input. Ogni **raffinamento** punta alla ottimizzazione del piano rispetto ai nuovi vincoli circa: - **Tempi**: accrescendo le unità di personale, tendendo il piano esecutivo verso il piano di progetto e rivisitando le attività del processo sui cammini critici; - **Costi**: mediando la qualità del prodotto finale attraverso la riduzione delle risorse coinvolte e il conseguente accrescimento dei tempi di esecuzione, demandando l'esecuzione di alcune attività a terzi con costi inferiori e riducendo le unità di personale impiegate e quindi aumentando il tempo; - **Uomini**: è possibile ottimizzare l'allocazione delle unità di personale nel tempo agendo sui possibili parallelismi e si può ridurre l''impiego di personale sacrificando i tempi di progetto. **Esempio**: gli input esterni disponibili sono I1 e I2 e le attività A1 e A2 si possono eseguite parallelamente poiché tutti i dati necessari sono disponibili. Terminata A1 può partire A4 perché sono disponibili m1 e m2, terminate A1 ed A2 può partire l'attività A3 perché, terminate le loro esecuzioni, sono disponibili m2 e m3. A4 e A3 possono essere eseguite parallelamente. Infine, l'attività A5 può partire quando A4 e A3 sono terminate e, quindi, sono disponibili i manufatti m4 e m5. **Esempio di Piano Esecutivo**: a partire dal piano di progetto della figura a, si supponga di non avere le risorse umane per eseguire le attività A1 e A2 in parallelo. Esse devono essere eseguite in sequenza. Il Piano Esecutivo è mostrato in figura b. Si supponga ora che le attività A3 ed A4 debbano essere eseguite da due programmatori con almeno 4 anni di esperienza, le attività A3 ed A4 sono eseguite in sequenza dall'unico programmatore disponibile, dando luogo ad un ulteriore raffinamento del piano esecutivo (figura c). Per **trasformare un modello di processo in un piano di progetto**, sarà applicato l'algoritmo a tutto il modello di processo, perciò il PMF coinciderà con il modello di processo dettagliato nelle sue attività elementari e per la trasformazione si usa il seguente l'algoritmo di trasformazione: - Porre nel diagramma PERT il nodo START e inizializzare l'insieme dei manufatti disponibili {MD} = {insieme di tutti i manufatti e i dati di ingresso disponibili}; - Per ogni attività Ai appartenente al PMF considerato, se tutti gli input necessari alla sua esecuzione sono disponibili allora si inserisce nel diagramma PERT(PMF) il nodo Ni corrispondente all'attività considerata; - Per ogni attività Ai appartenente al PMF considerato si collegano gli Ni a tutti i nodi già tracciati i cui manufatti di output sono utilizzati dall'attività Ai e si aggiorna l'insieme {MD} aggiungendo i manufatti prodotti dall'esecuzione delle attività Ai; - Ripetere il passo due e tre finché ad ogni Ai appartenente a PMF corrisponda un Ni appartenente al PERT(PMF); - Terminare la costruzione di PERT (PMF) con il nodo STOP connettendolo ad ogni Ni appartenente al PERT(PMF) tale che Ni non ha frecce uscenti.