Modelli e metodi per la qualità del software PDF - Appunti Universitari

MODELLI E METODI PER LA QUALITÀ DEL SOFTWARE (7+2 CFU) (M&M's) marcello se stai leggendo tira uno schiaffo a gabri pls Nel momento in cui si crea un software si ha un prodotto/sistema/soluzione che soddisfa i requisiti. In ingegneria del software si è usato lo SCRUM, progetto agile, supportato da strumenti come redmine, diagrammi e framework che hanno aiutato dalla fase di progettazione fino al software finito. Il certificato ISO 9000 è la certificazione di qualità per i processi di produzione, l’azienda sviluppa secondo processi di produzione certificati e conformi a quello che si dichiara. La ISO 14000 è la certificazione “ambientale”, si dà a chi opera rispettando la salvaguardia dell’ambiente, come lo smaltimento sostenibile dei rifiuti, materie prime a norma etc. La ISO 27000 è la certificazione sulla sicurezza e cybersecurity, i progetti sono gestiti avendo controllo della sicurezza dei dati, è una certificazione prettamente informatica. Avere le certificazioni ci fa presentare bene al pubblico, perché mostrano qualità. Inoltre, sono richieste e obbligatori per diverse gare d’appalto. Costituire conoscenze e abilità per il management dell’ingegneria del software, dove: -le Conoscenze sono le tecniche, i metodi ed i principi alla base della Qualità del software. -le Abilità sono le pratiche per usare adeguatamente le conoscenze onde trasformare in tecnologia i loro contenuti -il Management della Ingegneria del Software è il governo della qualità dei processi e dei prodotti per raggiungere l’obiettivo strategico della Ingegneria del Software: Sviluppare software senza sorprese ottimizzando i costi. Ogni prodotto deve essere creato per soddisfare le esigenze del momento. Se un sistema deve durare negli anni, ha senso investire sulla qualità e soprattutto sulla manutenibilità. I sistemi bancari scritti in cobol esistono ancora ma sono altamente manutenibili grazie anche alla tracciabilità del processo di costruzione. 1- INTRODUZIONE Un sistema deve essere tracciabile. Si può fare tracciando ogni modifica con strumenti software come Redmine, dove ogni cambiamento è stato caricato. Anche la progettazione; quindi, tutte le idee e anche lo sviluppo sono stati tracciabili. Partendo da un progetto, si inizia a creare, ma il progetto è anche modificabile se si trovano errori e se cambiano le esigenze. Per il corso si usano strumenti come Redmine e SVN (programma usato per caricare un progetto ad ogni sprint in ingegneria del software), sonarcloud e Fortify. Perché avere qualità? L’obiettivo finale è vendere, e questo è possibile riuscendo a convincere i clienti ad usare il software e ad espanderlo. E serve qualità. Come fare a dire che un prodotto è di qualità? Si fa valutare attraverso sistemi come Sonar Cloud e Fortify, ma si nota anche in fase di management dal numero di bestemmie (cit. prof) Se non si fa tracciamento, più tardi si scopre un errore più sarà impossibile risolverlo facilmente, specialmente se cambiano persone nel team di sviluppo. Ogni processo deve essere formalizzato per essere compreso anche da chi non ha effettivamente creato quella parte di software. La qualità è un termine ambiguo, “multidimensionale”, e bisogna definire dei requisiti per dire di essere su un certo livello di qualità. Non si possono usare caratteristiche soggettive ma punti oggettivi. Si sta valutando un’entità rispetto a quale prospettiva? Evidentemente ogni diversa prospettiva ha interessi diversi e percezioni diverse della qualità. Ci sono diversi livelli di astrazione. A volte si usa il concetto in senso ampio, in senso non formale. Altre volte viene usato per indicare un aspetto molto professionale e specifico di un prodotto. La qualità di una macchina dipende da quali fattori si devono esaminare. Se stai a palo in una strada passa poco più di un cavallo quindi mio padre con la bmw si arrabbia mentre il pandino ci passa. Ma la bmw ha molte più cose. Se si parla di qualità a livello formale, si ha una metrica per capire il livello, cioè si vede se i requisiti sono soddisfatti, e si hanno delle misure quantitative e qualitative come tasso di difetti, affidabilità e soddisfazione degli utenti. Di solito si pensa che il fatto che non ci siano bug di tipo funzionale sia il solo indice di qualità, ma non si pensa a quanti difetti possono esserci, a quanti fallimenti ci sono su ore di funzionamento, e a quanti utenti sono soddisfatti. DEFINIZIONE DI QUALITÀ DEL SOFTWARE L’ ISO è l’insieme di proprietà e 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. Non esiste una soluzione OTTIMA, ma esistono soluzioni OTTIMALI: cioè si deve fare un compromesso tra quello che si ha per ottenere il bilanciamento migliore nella realizzazione di un prodotto o servizio. Bisogna tenere presente quante risorse si hanno per poterle gestire al meglio. Non si può desiderare il mondo. La misurazione cattura informazioni sugli attributi delle entità. Un’entità è un oggetto o un evento del mondo reale (processo, prodotto, risorsa). -L’entità è descritta attraverso caratteristiche specifiche -Un attributo è un aspetto o una proprietà specifica di un’entità Si che un software ha qualità funzionali (requisiti funzionali, IF) e qualità strutturali (requisiti non funzionali) PRINCIPIO DI TOM DEMARCO: Non puoi controllare quello che non puoi misurare! Se non si hanno metriche di misurazione è impossibile determinare la qualità del prodotto. Non si può avere la percezione della qualità del prodotto se non si ha idea di quello che si vuole misurare in quanto a qualità. Nel momento in cui si ha un’entità ben definita e si sanno che metriche e misure effettuare, allora si ha conoscenza di ciò che si ha davanti e lo si può controllare. Il processo software deve essere quantificabile e misurabile per essere conosciuto e quindi controllato, e per farlo il processo deve essere formalizzato, per essere tracciato. Nel momento in cui si formalizza un processo si sa cosa aspettarsi da quel processo e cosa andare a controllare e misurare. Un processo potrebbe richiedere controlli ogni giorno ad esempio. Un processo di sviluppo non ben definito non può essere monitorato e così molti progetti che non danno l’attenzione adeguata alla qualità falliscono. Nell’immagine in alto ci sono le principali cause di fallimento o azioni legali sul software. Come esempio di requisiti instabili, dire che un software è user-friendly non è un concetto prestabilito ma dipende dal target del software. Un software user-friendly per un programmatore non è user-friendly per un bambino. Le misure del software interessano a sviluppatori individuali, team di progetto e organizzazioni di sviluppo software. SWEBOK (software engineering book of knowledge)In questo libro ci sono i fondamenti della qualità del software, cosa si intende per qualità quando bisogna fare gestione dei processi, e dei tool per la qualità del software. I processi di qualità sono particolarmente sentiti tanto da inserirli in libri e manuali di riferimento dell’ingegneria del software. La qualità è di prodotto ma anche di processo. Il prodotto può essere un’applicazione, un servizio, una componente embedded in un sistema maggiore etc. Assicurare la qualità di un prodotto o servizio è difficile. Nel caso del software valutarla o garantirla è particolarmente complesso. Esistono: -Attività legate alla qualità del software (es. testing) -Metodi orientati alla qualità di prodotto (es. Cleanroom) -Metodi orientati alla qualità di processo (es. ISO9000) Una volta chiarito che cosa si vuole misurare bisogna identificare lo scopo (obiettivo) che si ha dalla misura. Qualsiasi valutazione di qualità inizia dallo scopo che ha chi vuole valutare. Chi valuta dovrebbe avere chiari i propri obiettivi, legarli a domande specifiche sull’entità (prodotto o processo) oggetto di analisi, e definire metriche capaci di analizzare e quantificare le qualità richieste ai prodotti rispetto agli obiettivi. I quesiti imposti vanno ben progettati e scritti, per poi passare all’operazione effettiva. Rispetto alle misure raccolte si può poi fare un’interpretazione. Le misurazioni dovrebbero essere utili e costruttive, perché l’organizzazione deve imparare analizzandoli. Si definiscono degli obiettivi, si raccolgono le informazioni e si analizzano e rappresentano i dati. Esistono nelle aziende team di qualità che periodicamente stilano l’andamento in termini economici, finanziari, di rendimento, di specifiche tecniche del progetto, dell’impiego del personale nel progetto etc. Le metriche e le loro definizioni dovrebbero riflettere il punto di vista di diverse parti interessate. È fondamentale che le metriche debbano correlarsi agli obiettivi (ovvio). La metrica può avere sfaccettature diverse rispetto al contesto in cui va calata e interpretata. Quando si produce un software è buona cosa definire un processo e seguirlo, ed è buona cosa definire un minimo di formalizzazione che aiuta a capire, scrivere, trasferire che cosa si sta valutando e che modello di qualità avere. Un modello di qualità rappresenta dei passi da seguire: 1. Sviluppo dei goal e delle misure associate alla qualità 2. Generazione di domande che definiscono i goal quantificandoli 3. Specificare le misure da collezionare in conformità al goal: quali sono le metriche (es. Numero di linee di codice, complessità, numero di bug fix che risolvo in un gg(wp), user-friendliness) da rilevare? 4. Sviluppare i meccanismi operativi di collezione delle misure: con quali strumenti valutare bug/sicurezza etc.? 5. Raccogliere i dati e analizzarli onde sviluppare azioni correttive: utilizzare tool di reportistica, grafici, tabelle, vedere se si possono fare interpolazioni di dati, correlazioni tra risultati etc. L’obiettivo è cercare sempre di migliorare, capendo la situazione iniziale e introducendo operazioni correttive. I risultati sballati devono migliorarsi. 6. Analizzare i dati post-mortem per raccomandazioni sul futuro. Nel punto 5 si analizzano i dati, nel 6 il modello operativo. Le attività legate alla qualità sono: 1. Testing: processo di investigazione sui rischi connessi all’esecuzione di un sistema software. I mockup sono utilizzati per avere riscontro con clienti/stakeholder già con dei modelli prima di realizzare, per esplicitare problemi al committente, per capire cosa ha nella testa il cliente. 2. Misurazione: indicatori di qualità sia mediante ispezione che mediante esecuzione 3. Verifica: analisi delle funzioni rispetto alla specifica. Viene effettuata da altri e non da chi codifica. 4. Validazione: accettazione da parte degli stakeholder 5. Certificazione: analisi delle funzioni rispetto ai requisiti di legge da certificare Avere un marchio di qualità di un prodotto DOP, biologico, ISO etc. costa, ma è anche importante avere le certificazioni nel bigliettino da visita. I costi principali riguardano il fare bene le cose (conformità) e il rimettere a posto le cose sbagliate (non conformità). I costi si sostengono per adeguare la qualità del prodotto a quella richiesta. Il costo della conformità (COC) è il costo che si sostiene per soddisfare le esigenze espresse e implicite, sono costi di prevenzione degli insuccessi e costi di accertamento per oneri e collaudi. Il costo della non conformità (CNC) è il costo che si sostiene per risolvere insuccessi o fare “ciò che non si è voluto fare prima”, sono costi per gli insuccessi interni per prodotti che non soddisfano la qualità prima ancora della consegna, e costi per insuccessi esterni cioè costi di manutenzione, riparazione, garanzia, richiami, responsabilità. Ci sono diversi enti di standardizzazione (come ISO) che hanno dato delle definizioni specifiche di livelli di 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 ALLA MISURAZIONE E IL SUO LEGAME CON LA QUALITÀ La Misurazione ci aiuta a comprendere il mondo, ad interagire con l’ambiente circostante e migliorare la nostra vita La misurazione dovrebbe essere una parte naturale delle attività di sviluppo e manutenzione del software - Sviluppatori software: misurano le caratteristiche del software per capire se i requisiti sono coerenti e completi, il design è di alta qualità, il codice può essere testato; Gli sviluppatori sono interessati al PROGETTO. - Project Manager: misurano il processo e gli attributi del PRODOTTO per essere in grado di sapere quando il sw sarà pronto per la consegna; se il budget è stato superato; se il piano di progetto è rispettato; Lo sviluppatore ha degli interessi qualitativi nello sviluppo del progetto, mentre in manager ha interesse nel prodotto. Il manager ci mette i soldi, quindi, fa riferimento al budget, al ritorno dell’investimento, come gestire la commessa in generale, mentre lo sviluppatore è interessato alla produzione e alle caratteristiche tecnico-funzionali. Lo sviluppatore deve creare un progetto buono per il committente. - Clienti: misurano gli aspetti del prodotto finale per vedere se è conforme alle aspettative di qualità (ad es. Usabilità) e se sono soddisfatti i requisiti. Il cliente è interessato al prodotto finale e se è buono sarà fidelizzato. - Manutentori: valutano il prodotto finale per vedere cosa aggiornare e/o migliorare. Hanno interesse nel ricevere le fasi del processo scritte e documentate per poter manutenere al meglio. La misurazione è il processo attraverso cui numeri vengono assegnati ad entità del mondo reale in modo tale da determinarne il valore secondo regole chiaramente definite. Ed è importante catturare le informazioni sull’entità oggetto di valutazione perché sono caratteristiche di qualità. Rispetto alle caratteristiche si identificano le metriche per misurare la qualità. Il processo di misurazione attribuisce all’entità delle caratteristiche e delle metriche e ci assegna un numero utilizzabile per capire se la metrica è soddisfacente o meno, cioè se l’obiettivo è raggiunto o no. Gli attributi sono misurati con numeri e simboli. È importante nella specifica precisare la metrica e come andarla a rilevare, ad esempio specificare il prezzo in euro o dollari etc. Così come nel processo di sviluppo non bisogna lasciare troppi gradi di libertà ma definire per bene il più possibile, anche nella qualità bisogna specificare i livelli da raggiungere, gli obiettivi etc. Bisogna essere certi che si utilizzino range, valori, simboli chiaramente interpretabili e definiti. Potremo trarre conclusioni su una entità basandoci sui valori dei suoi attributi (caratteristiche di qualità) L’obiettivo è rendere le cose misurabili, far diventare misurabili le cose non misurabili. La misurazione rende i concetti più visibili e dunque più comprensibili e controllabili. Si deve procedere in maniera consapevole, è necessario che la qualità sia parte naturale della cultura dell’impresa, deve essere nel modus operandi dell’impresa. Nelle scienze fisiche, mediche, economiche, ingegnerie materiali, la misurazione è una procedura radicata in tutti i processi. La misurazione di qualità è parte della vita di tutti i giorni, e così si misura quella del software, considerando attributi come affidabilità, usabilità, manutenibilità, qualificati tramite specifiche metriche di misura. Per rendere le cose misurabili ci sono 2 tipi di quantificazioni: - con la misurazione si ha una quantificazione diretta, cioè si prende uno strumento di misura che rileva immediatamente, come un righello etc. - con il calcolo la quantificazione è frutto di una formula, servono dati e metriche per ottenere il calcolo, ad esempio per calcolare la media pesata servono il numero degli esami, il voto e i crediti di ognuno. Si usano formule. È importante non considerare la qualità del software come un “add-on”, ma deve essere parte dei processi produttivi, deve essere applicata sistematicamente, senza promettere delle caratteristiche prima di capire il budget e prima di capire come soddisfare o come misurare le caratteristiche. La qualità deve quindi essere parte della pianificazione del sistema. Spesso falliamo a comprendere e quantificare i costi che compongono un progetto software: molti progetti non fanno distinzione tra costi di progettazione e costi di codifica o di test. Non possiamo controllare i costi se non conosciamo i costi relativi ai componenti del costo. E non si sa se si sta spendendo troppo per una certa parte di software. Tante volte, quando si va a definire e formalizzare la commessa, si è così tanto focalizzati sui requisiti funzionali che si abbandonano quelli non funzionali come scalabilità, sicurezza e manutenibilità. Ci si focalizza sul lancio del prodotto trascurando caratteristiche importanti, ci si basa su un approccio non ben formalizzato per qualità. Spesso non si predice o quantifica la qualità dei prodotti, o ci si affida ad evidenze aneddotiche per convincersi a provare nuove tecnologie di sviluppo senza capire cosa sono, senza fare uno studio preliminare per determinare se la tecnologia è efficiente ed efficace. Non si sa se l’investimento è buono a breve e/o lungo termine per il progetto. Quindi anche oggi, spesso non si fanno misurazioni esaustive e coerenti, spesso perché manca un approccio rigoroso ai metodi di processo (come dire che si sta seguendo lo scrum, poi in realtà no). PROSPETTIVE DELLA MISURAZIONE Nella gestione di un progetto bisogna avere chiaramente in mente le attività e quanto dura l’attività. - Un project manager deve avere interesse su questi aspetti di costo e produttività per poter stimare la durata e i costi del progetto. Bisogna misurare tempo e impegno coinvolti nei processi che comprendono la produzione del software, e bisogna capire quanto è produttivo il personale misurando il tempo impiegato per specificare il sistema, progettarlo, codificarlo e testarlo, raccogliendo misure di dimensioni di specifiche, progetto, codice e piani di test. Però, gli umani sono diversi dalle macchine: la produttività di una macchina è sempre la stessa, mentre per gli umani si hanno delle variazioni di produttività a seconda del giorno, dello stato d’animo, del diamine di ciclo etc. Per capire quanto sono Skild (skilled) Skull Kid, le informazioni raccolte dall’analisi della qualità del codice e dalla customer satisfaction servono ad apportare miglioramenti sia in codice che in features del sistema sviluppato. - L’ingegnere del software invece è più focalizzato ad aspetti tecnici, alla “qualità interna”, cioè la qualità che riguarda la struttura del codice (statica). Analizza i requisiti per determinare se sono scritti in modo misurabile e verificabile, e misura il numero dei difetti tracciandoli rispetto alle loro cause (test, modelli, grafici etc). La prospettiva dell’ingegnere include anche misurare le caratteristiche di processo e di prodotto per capire se sono stati raggiunti gli obiettivi, la qualità è monitorata e controllata continuamente. Avere un software che progetta i 7 principi dell’ingegneria (rigore e formalità, separazione interessi, modularità, anticipazione al cambiamento, astrazione, generalità, incrementabilità) indica qualità, perché molto probabilmente al processo è applicata la formalizzazione, è stato applicato il principio di modularità quindi basso accoppiamento e alta coesione (oggettivi e misurabili), se il software è manutenibile è pronto ad anticipare il cambiamento. Gli scopi della misurazione sono 3: comprendere, controllare e migliorare. In questo ordine. -- Le misure aiutano a comprendere cosa accade durante le attività di sviluppo e manutenzione. Viene valutata la situazione attuale e vengono inseriti dei valori soglia (baselines) che bisogna avere e raggiungere perché aiutano a fissare obiettivi per strategie future. Le misurazioni inoltre rendono visibili gli aspetti del processo e del prodotto e quindi fanno comprendere le relazioni tra attività ed entità. I valori soglia devono essere fissati dopo attente analisi e osservazioni. -- Le misure aiutano a controllare cosa accade nei progetti. Sulla base dei valori soglia, degli obiettivi e delle relazioni 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à. Ad esempio, monitorare la complessità dei moduli rispetto ai valori soglia. -- Le misure aiutano a migliorare processi e prodotti basati sui risultati ottenuti e sui trend nel tempo. Una volta che si è capito che si è sulla giusta strada si possono alzare i valori soglia per migliorarsi, oppure si deve cercare di tornare sulla strada giusta se si sta sbandando. Si cerca di incrementare la produttività dopo aver introdotto un nuovo tool nelle linee di produzione, e di incrementare le aspettative di qualità (thresholds) in base alle esigenze di mercato. 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. Sfaccettature della misurazione: Nelle parti di pianificazione e progettazione della qualità hanno importanza: Le stime di Costo ed Effort, parte delle sfaccettature della misurazione (le stime fanno parte della misurazione). I modelli per la stima dei costi e dell’impegno sono lo strumento utilizzato dal manager per prevedere i costi di progetto durante le fasi iniziali del ciclo di vita del software. Il progetto ha almeno dei costi gestionali di tecnologia (luce, software…). Fare una stima è molto più complesso nell’ingegneria del software che nelle ingegnerie materiali. I modelli e le misure per la produttività hanno anche importanza, sono stati proposti misure e modelli per valutare la produttività del personale durante i diversi processi software e in diversi ambienti, verso la massima produttività. Un’altra parte importante è la raccolta dei dati, che implica che le misure siano definite in modo inequivocabile, e che la raccolta sia consistente e completa in modo che l'integrità dei dati non sia a rischio. La raccolta dei dati fa parte del processo della misurazione come parte preliminare. Tutte le decisioni sono basate sui dati raccolti, e non da sensazioni. I dati possono essere rappresentati in grafici per mostrare progressi e evidenziare i problemi nei processi e prodotti sviluppati o manutenuti. Essenziale per l'indagine scientifica sui rapporti causali e sulle tendenze. Esistono dei modelli di qualità definiti a priori (gerarchici), i modelli di qualità esplicitano e formalizzano i legami tra le entità di interesse (prodotto, processo, servizio...) e caratteristiche di qualità collegate alle proprie misurazioni. Bisogna capire quali sono le differenze tra misurazione di qualità del processo/prodotto e misurazione della gestione degli stessi. La produttività è legata alla qualità del prodotto, la velocità di produzione non ha significato se non è legata alla valutazione di qualità del prodotto. I grafici, ad albero, hanno i rami superiori con fattori di qualità di livello più alto, gli altri rami passo passo di livello più basso. Si parla di management attraverso le metriche perché attraverso le misure è possibile gestire un progetto tracciandone il progresso e verificare se il progetto rispetta la tabella di marcia. Manager e sviluppatori si affidano a tabelle e grafi per tracciare il progresso e verificare se il progetto rispetta la tabella di marcia. Le aziende e le organizzazioni definiscono standard di misura e metodi di reporting per controllare e confrontare i progetti. Riepilogando, altre discipline sottolineano che la misurazione deve avere un ruolo più significativo nell’ingegneria del software, e per fare misurazioni è fondamentale avere obiettivi chiaramente definiti, così che si possano prendere misure chiare per fare monitoraggio e capire a che punto si è. È necessario avere obiettivi chiaramente definiti per la misurazione che tengano conto delle diverse prospettive degli stakeholders. PERCHÉ MISURARE? Ci sono 4 motivi principali per misurare processi, prodotti o risorse software: - Caratterizzare, cioè stabilire quali sono le caratteristiche da usare come indicatori di qualità e le soglie di confronto - Valutare, cioè determinare l’avanzamento rispetto ai piani di progetto, valutare miglioramenti e stabilire obiettivi - Fare previsioni, cioè usare dati storici di relazioni tra processi/prodotti per capire i trend e procedere per il futuro - Migliorare, cioè raccogliere informazioni quantitative per identificare le inefficienze e migliorare in qualità. Maggiori info: https://elearning.uniba.it/pluginfile.php/142290/mod_resource/content/4/3-MeasurementScales.pdf La misurazione è un processo attraverso cui numeri e simboli sono assegnati agli attributi di entità del mondo reale in modo da caratterizzare gli attributi attraverso regole chiaramente specificate. Gli elementi della misurazione sono: - Entità: elementi del mondo reale che si desidera misurare, come prodotti o processi, attività, organizzazioni, ambienti etc. Possono anche essere gruppi o insiemi di altre entità come sottoprocessi. - Attributi: Sono caratteristiche o proprietà delle entità come altezza o colore degli occhi di una persona. Per il software possono essere: dimensione, costo, impegno, tempo di risposta etc. L’arte della misurazione consiste nel decidere quali attributi usare in modo da fornire una chiara idea delle entità considerate. Ciascuna entità è legata agli attributi che caratterizzano l’entità e alle misure che possono esser usate per quantificare gli attributi stessi. - Metriche: regole e scale per assegnare valori agli attributi. Bisogna usare metriche che siano fatte apposta per le entità con i loro attributi che bisogna misurare. Si hanno e si possono usare diverse scale di misurazione. Scale di misurazione: Le scale di misurazione forniscono valori e unità per descrivere gli attributi, come per un software il valore dell’impegno può essere fatto con una scala “ore-uomo”. Ovunque si effettui una misurazione e qualunque sia la sua forma, richiede sempre che vi siano delle scale ben definite per rilevare e registrare i valori misurati, non bisogna lasciare livelli di libertà per chi misura, ma essere chiari e concisi, semplici e precisi. Se si deve rilevare la temperatura, il rischio di rilevarla senza dire con quale scala ci può portare a dire che 40 gradi siano tanti, ma invece sono in scala Fahreneheit e corrispondono a 4 gradi Celsius. Le scale possono non essere solo numeriche, ma possono usare anche altre metriche: In una scala nominale ogni valore è rappresentato da una classe o categoria di appartenenza come “linguaggio utilizzato” oppure “tipo di errore”. I valori non sono ordinati e non c’è una grandezza, ma sono chiari e definiti. La scala ordinale aggiunge il concetto di ordine (ascendente o discendente) alla scala nominale. Si hanno delle priorità assegnate ad ogni valore. Lo spazio tra i valori, cioè la differenza “numerica”, non ha significato o dimensioni. Le classi vengono ordinate rispetto ad un attributo e i valori esprimono un punteggio senza usare operatori aritmetici. Un esempio è il livello di soddisfazione per un servizio. Dato che le scale nominali o ordinali sono più “soggettive” c’è bisogno di dare delle linee guida per rendere le misure coerenti. Si usa un “modello descrittivo”, che specifica come rilevare delle misure, cioè come intendere la misurazione e la scala. La scala ad intervallo aggiunge alla scala ordinale un intervallo ben definito e di valore fissato che separa le classi della scala. Preserva le differenze ma non i rapporti, quindi sono applicabili somme e sottrazioni ma non moltiplicazioni e divisioni. Nella scala non esiste valore nullo o 0 assoluto, lo 0 è un valore significativo. Ad esempio, 0 gradi non significano mancanza di temperatura, ma è un valore significativo. Allora 40 gradi non sono il doppio di 20 gradi. Per capire se una scala è ad intervallo, si può quindi vedere se lo 0 è assoluto oppure simbolico. La scala a ratio aggiunge l’origine alla scala ad intervallo, cioè mette uno 0 a ssoluto. Medie aritmetiche e pesate, densità di bug in un sistema etc. Due scale ratio M ed M’ sullo stesso attributo (ex: altezza) sono convertibili con la relazione M=a*M’ essendo “a” una costante. La dimensione di un programma misurata in LOC è una scala Ratio (m1); la dimensione in KLOC è un’altra scala ratio (m2); m2=1000*m1. La scala assoluta è una speciale scala ratio dove l’unico moltiplicatore ammissibile è 1. Cioè, si fa una misurazione sempre conteggiando gli elementi di una entità, come il numero di persone in un’aula, che varia sempre di 1 e mai di valori decimali, oppure quante righe di codice ha un sistema. Sono significative tutte le operazioni aritmetiche. In base al tipo di scala si possono applicare diverse operazioni aritmetiche ma anche funzioni statistiche. Dipendentemente dal tipo di scala si possono applicare funzioni statistiche diverse. Nel tempo è possibile cambiare il tipo di metrica e quindi di scala usata per una misurazione, man mano si possono usare anche altre modalità di misurazione di una metrica. Non si ha un’unica modalità per rilevare una metrica. --Una metrica oggettiva è uguale indipendentemente da chi la rileva. Un esempio di misura oggettiva è la lunghezza. Misurazione diretta: la misurazione diretta di un attributo di un’entità non implica altri attributi o caratteristiche in quanto è rilevato direttamente. Misurazione indiretta: implica che un attributo sia misurato combinando misure in relazione tra loro. necessita un modello di calcolo Al fine di limitare e contenere la dissonanza cognitiva (soggettività) delle misure soggettive, si associa un modello descrittivo in cui ogni valore del range è definito con una descrizione testuale. In generale per soddisfare gli obiettivi di qualità richiesti, le misure rilevate devono raggiungere predefinite soglie, queste sono dipendenti dal contesto di esecuzione e definite dal committente. Si definisce un intervallo di successo entro i quali il prodotto si considera raggiunto, mentre la soglia di insuccesso è il valore al di sotto del quale il prodotto viene rigettato. GESTIONE DELLA QUALITA DEL SOFTWARE Secondo lo standard ISO 9000, la qualità è definita come l’insieme delle caratteristiche di un prodotto/servizio 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, materiali e processi spinti al limite, e meno difetti. Per esempio, si chiede la recensione o il parere agli utenti. Anche il CONCETTO di qualità è cambiato nel tempo, da essere competenza non degli sviluppatori ma solo roba di competenza dei “blue-collar”, e non si chiedeva la recensione ai clienti, perché avere difetti di qualità era una “vergogna” da tenere lontano dai clienti, mentre oggi tutti gli sviluppatori devono pensare alla qualità, e anche i clienti devono comunicare i difetti trovati per promuovere soluzioni cooperative di tutto il team e per migliorarsi, migliorare la qualità non è un costo ma un investimento che dopo farà risparmiare parecchio, in generale la qualità non è trattata solo “ai piani alti” ma in tutto il processo di sviluppo. Il miglioramento continuo non è solo la qualità del prodotto ma anche il miglioramento continuo dei processi. Si è passati da un processo di “controllo qualità”, attività che si fa su prodotti già esistenti per individuare difetti con un’ispezione sul prodotto già esistente, all’assicurazione di qualità che riguarda il monitoraggio del processo di produzione per prevenire i difetti e arrivare alla fine con un prodotto qualitativamente stabile, ad esempio con cicli di produzione più piccoli che terminano con un controllo della qualità oppure confrontando il processo e il prodotto di ogni ciclo (sprint) con dei modelli di qualità prestabiliti oppure si producono report attraverso dei grafici che fanno vedere lo stato delle cose in un momento e creano trend di un insieme di misure rilevate sistematicamente sul processo e sul prodotto che si sta creando. In ultimo si è passati alla qualità totale, cioè al concetto di miglioramento continuo. Oggi attenzione è posta sulla gestione della qualità quale fattore strategico includendo aspetti quale: -- La qualità è definita dai clienti -- La qualità è legata alla redditività del mercato -- La qualità è parte integrante dei processi strategici di pianificazione -- La qualità richiede impegno da parte dell’intera organizzazione. Tecniche di monitoraggio: Bisogna capire cosa rilevare in termini di metriche, bisogna rilevare le metriche e capire se l’andamento del processo e le qualità del prodotto rispecchiano le “baseline” o “threshold”. Se non si rispettano allora bisogna migliorare, se invece si è sempre molto al di sopra è bene alzare il limite della baseline. Se invece il grafico del monitoraggio ha punti più su e più giù del threshold (vette e picchi) allora il processo è instabile, non prevedibile, e bisogna capire i problemi che vanno a destabilizzare il processo. Negli anni la cultura di “qualità” e sensibilità al concetto di controllo è migliorata nelle aziende, ora è parte delle politiche aziendali e molte aziende utilizzano Fortify o SonarCloud. Il controllo di qualità è un fattore strategico per un’impresa, e non solo per i prodotti informatici ma anche per idk vestiti: stanno nel cartellino le specifiche di qualità ambientali o dei materiali. La qualità è parte dell’intera cultura aziendale. Si possono intravedere 2 prospettive di qualità. La qualità non riguarda solo il fornitore ma anche il cliente. Il fornitore è sensibile verso i requisiti del contratto o commessa, il contratto deve essere rispettato in termini di tempi, funzionalità, costi. Deve controllare che il software sviluppato faccia quello che deve fare, che i prodotti svolgano adeguatamente le loro funzioni. Mentre il cliente è sensibile rispetto alla soddisfazione, alle aspettative, alle funzionalità rispetto agli scopi dichiarati, al servizio clienti differenziato rispetto alle varie esigenze (integrità, cortesia e rispetto). Il progetto è influenzato dal processo di sviluppo e dalle persone che danno delle valutazioni e hanno una certa soddisfazione. GESTIONE DELLA QUALITA Quando eseguiamo un progetto un componente importante è la gestione di qualità: il prodotto si sta eseguendo nella maniera corretta? Bisogna controllare e verificare elementi di politica di qualità, obiettivi di qualità, assicurazione della qualità, controllo della qualità, verifica della qualità e piano di qualità. La parte di gestione di qualità nelle imprese più piccole è data ad enti esterni. Nelle aziende maggiori invece è gestita internamente da un gruppo di sviluppatori che controllano la qualità (team di gestione e qualità). La politica di qualità è generalmente un documento elaborato da esperti di qualità e supportato dal top management. 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à.. Mentre nella politica di qualità si fa riferimento alla strategia, gli obiettivi di qualità sono specifici per ciascun progetto, l’obiettivo di qualità per un progetto è creato per puntare a certi traguardi in un dato intervallo di tempo. Devono essere traguardi raggiungibili, o si danneggia il morale del team e la buona riuscita del progetto. Se si conosce la capacità del team, il threshold non deve andare oltre le loro capacità. Bisogna segnare obiettivi perseguibili, specifici, comprensibili, e con una scadenza fissata per poter organizzare il proprio tempo tenuto conto della scadenza, così da organizzare il lavoro al meglio. L’assicurazione di qualità si riferisce alle attività formali e ai processi manageriali che assicurano che i prodotti e servizi raggiungano/abbiano i livelli di qualità prefissati. L’assicurazione di qualità assicura che lo scopo del progetto, i costi e i tempi siano integrati tra loro. Bisogna pianificare, anche se si è sicuri di essere capaci di fare qualcosa, perché potrebbero esserci imprevisti nello sviluppo, oppure si sono sovrastimate le competenze del gruppo etc. Un buon sistema di assicurazione della qualità deve: Identificare obiettivi e standard, essere orientato alla prevenzione, pianificare per collezionare e usare dati per il miglioramento continuo, includere verifiche (audits) di qualità. La pianificazione è importante per capire come comportarsi in caso di imprevisti e capire come gestire il gruppo per avere un successo alla fine del periodo di progettazione. La progettazione crea un piano per il team. Possono esserci situazioni imprevedibili come terremoti, allontanamento di un membro del gruppo, danni al server etc che destabilizzano il processo e che sono molto difficili da controllare e gestire. Secondo il Gantt, i controlli della qualità devono essere fatti periodicamente. Quando si fanno le verifiche di qualità bisogna segnare dei “checkpoint”. L’attività B è iniziata? L’attività A è completa al 15% almeno? Le altre attività non sono iniziate ancora, vero? (deliverable prodotti aiuto). Bisogna settare gli obiettivi da controllare sistematicamente. Bisogna rilevare informazioni relative alla qualità interna (in questa fase, ed è questo quello che faremo come esame per modelli, facciamo modelli di qualità statica, cioè codice sorgente). Il controllo della qualità indica l’insieme di attività e tecniche che mirano a creare specifiche caratteristiche di qualità. Include: monitoraggio continuo dei processi, identificazione ed eliminazione delle cause di problemi, uso di SPC per ridurre la variabilità dei processi ed incrementarne l’efficacia. Il controllo di qualità certifica 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 lo standard di qualità, monitorare e calibrare i dispositivi di misurazione, includere documentazione dettagliata per tutti i processi. L’assicurazione della qualità si concentra sulla prevenzione dei problemi lavorando sulla qualità del processo, mentre controlli della qualitàsi focalizza sull'identificazione e la correzione dei difetti nel prodotto finito. Fare verifica di qualità significa fare una valutazione indipendente fatta da personale qualificato esterno, che verifica che il progetto sia conforme ai requisiti di qualità e che stia procedendo secondo le procedure politiche stabilite. Ad esempio, per la ISO 9000 l’azienda prepara una serie di documenti per dimostrare che le pratiche organizzative sono organizzate secondo le regole dello standard, arriva il certificatore rappresentante della ISO e in 2 giorni si fanno le opportune verifiche su tot commesse e tot progetti dell’azienda, e si provano le evidenze del corretto processo di monitoraggio. Una verifica della qualità assicura che la qualità pianificata per il progetto sia raggiunta, che i prodotti sono adeguati all’uso, le leggi e le normative sono seguite, i sistemi di raccolta e distribuzione dei dati sono accurati e adeguati. Poi, si identificano opportune iniziative di miglioramento. Per gestire tutta l’organizzazione si crea il “piano di qualità”, che dettaglia come il team di management intende svolgere la politica di qualità dell’organizzazione. E’ parte del piano di project management. Generalmente contiene l’obiettivo del progetto, le metriche da rilevare, ogni quanto rilevarle e come interpretarle. Si carica su piattaforme come redmine per progettare il contenuto di ogni sprint, i dettagli di ogni sprint etc (in questo caso si ha un piano formale). Il piano di qualità può essere formale o informale, molto dettagliato o lascamente pianificato, dipendentemente dalle esigenze di progetto. Se si decide di dettagliare il piano su una piattaforma documentale allora il piano è formale. La formalità dipende dalle esigenze di progetto. Un’evidenza informale potrebbe essere invece caratteristica di un’azienda molto piccola. Il piano dovrebbe essere revisionato all’inizio del progetto per assicurare che le decisioni siano basate su informazioni accurate. La qualità non è gratis. Il controllo non può essere fatto alla fine di ogni singola commit o ogni giorno. Nel momento in cui si definisce il processo del prodotto che si deve creare si scrlgono sia requisiti funzionali che non funzionali, come requisiti qualitativi. Se il prodotto è usa e getta allora non deve esserci manutenzione, ma se non lo è la manutenzione serve. Bisogna individuare i costi di conformità (che si hanno durante il progetto per evitare di fare errori) e i costi di non conformità (che si spendono durante l’esecuzione del progetto e dopo il rilascio a causa di failures, bug o errori di qualità che non si sono risolti durante il progetto, che sono molto maggiori e impattanti!). STRUMENTI PER IL CONTROLLO DELLA QUALITA I metodi statistici hanno acquisito sempre più importanza come strumento di supporto per fare decisioni sulla base di dati quantificabili. Si distinguono degli strumenti per identificare ed analizzare opportunità di miglioramento. Questi consentono di organizzare i dati numerici, facilitare la pianificazione e migliorare il processo decisionale. Possiamo identificare una serie di strumenti da utilizzare per analizzare la qualità: 1-Data Tables: forniscono una maniera sistematica per raccogliere e mostrare dati. Sono delle tabelle che raccolgono dati rispetto a delle categorie specifiche, per rappresentare in maniera grafica e sintetica i dati. Esempio: Un’azienda generalmente ha modalità per censire fornitori e clienti, per capire la qualità del servizio, le problematiche etc. Le categorie di difetti e problemi che si possono riscontrare con i fornitori in questo esempio sono incolonnati in tabella. Sulla prima riga troviamo i placeholder dei nomi dei fornitori. Una tabella del genere è utile quando si devono prendere delle decisioni su dei fornitori. La tabella dice che il fornitore A è più problematico rispetto agli altri fornitori, e l’errore più ricorrente invece è l’ultimo (incorrect test documentation).Se serve un prodotto in poco tempo, ha più senso rivolgersi a B perché non ha mai consegnato materiali danneggiati che necessitano reso, anche se può mancare la documentazione. 2-Diagrammi causa-effetto o “a spina di pesce”: Servono a capire le cause di un certo problema scelto. Si prende un problema e bisogna investigare per capire cause e motivazioni, e sull’analisi identificare e ipotizzare delle azioni correttive. Si fa passo passo con l’obiettivo di identificare le cause di un effetto, dettagliandole lungo il diagramma. Il primo step è identificare il problema da analizzare, si identifica a seguito della raccolta di dati o di trend storici. Una volta identificato il problema si crea un “team di brainstorming” che cerca di identificare le possibili cause per ogni macro-classe/categoria di possibili cause e poi si vanno a documentare o specificare le cause. (non ti va di andare a lavorare perché sei LAZY). A valle dell’analisi del problema si propongono anche delle soluzioni e questi diagrammi servono per trovare soluzioni ai problemi coinvolgendo anche i membri dello staff e i dipendenti dell’azienda. 3-Scatter Plot: Organizzano i dati usando le variabili dipendente(y) e indipendente(x), e servono per capire, a seconda di come vengono plottati i numeri, se c’è una correlazione negativa, positiva, curvilinea tra delle variabili. Più i punti seguono una linea diagonale, maggiore è la correlazione tra le variabili mostrate. Dall’analisi di questo 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). Nell’esempio, si hanno i difetti rispetto alla complessità McCabe. Anche su SonarCloud è possibile avere dei grafici per la correlazione tra codice e bug. 4- Gli istogrammi rappresentano la frequenza di distribuzione di certi dati, come la distribuzione dei difetti in base alla criticità, con una scala di criticità da 1 a 4 come nell’esempio. 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 è un attributo/caratteristica di una situazione/problema. L’altezza è la frequenza di quella caratteristica. 5- I “Pareto Chart” sono un tipo particolare di istogramma, che oltre ad avere la distribuzione dei dati secondo una certa categoria ha anche una distribuzione “cumulativa”. Le variabili sono ordinate per frequenza di occorrenza per aiutare a identificare quelli che contribuiscono maggiormente a problemi di qualità. L’Analisi di Pareto è detta “regola 80-20”: 20% delle cause provocano 80% dei problemi. Nell’immagine, i problemi di login all'account di sistema rappresentano il 55% dei reclami degli utenti. Questo problema, insieme al sistema di blocco account rappresentano il 80% di tutti i reclami ricevuti. Ridurre i primi 2 problemi ridurrebbe notevolmente i reclami, e ridurre i reclami significa ridurre quei 2 problemi. 6- I diagrammi di flusso mostrano il flusso di informazioni come viene definito dipendentemente dai punti di decisione. Rappresentano graficamente la logica e il flusso 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- Analisi dei trend con Run chart: il Run chart (e control chart) è un metodo statistico usato per determinare la migliore equazione che interpola i punti di uno scatter plot (5). L’idea è di individuare la relazione tra la variabile dipendente (output) e quella indipendente (input). Mostrano il trend storico e come il processo cambia nel tempo, come variano nel tempo i vari difetti. Sull’analisi delle tendenze si possono fare delle previsioni. Il diagramma è costituito da linee che collegano i punti di osservazione (dati) tracciandoli in relazione ad una scala temporale. L’analisi dei trend è anche detta “Regressione” o “Minimi quadrati”. 8- Il control chart (carte di controllo) mostra i risultati di un processo nel tempo. Vengono usati anche per fare previsioni, e si differenziano dai Run chart perché incorporano un controllo statistico (Statistical Process Control SPC) e possono determinare se un processo è sotto controllo (le variazioni nei risultati sono dovute ad eventi casuali in natura) o fuori controllo (le variazioni sono dovute a problemi nel processo). Nel grafico si hanno dei “punti di osservazione” e due “limiti di controllo”. I control chart vengono usati come base per il monitoraggio delle prestazioni di un processo, espresse attraverso metriche operative. Si identificano metriche come il tasso di difetti che si rilevano periodicamente e si plottano, per vedere se ci sono delle oscillazioni oltre l’intervallo di riferimento che individuano anomalie nelle prestazioni del processo. In questo esempio, all’inizio si ha un processo abbastanza destabilizzato, che migliora andando avanti. Le linee in rosso sono gli intervalli di accettabilità definiti a seconda dei miglioramenti. Nella parte 2 si sono risolti degli errori grossi e infatti si è ristretto l’intervallo. All’inizio è ovvio che ci sia casino, perché bisogna abituarsi ancora. È importante fare uso di questi strumenti perché forniscono supporto al controllo di processi e danno previsioni, ma funzionano se i dati sono raccolti periodicamente. MIGLIORAMENTO CONTINUO DEI PROCESSI Per costruire dei software di qualità è necessario superare tutti i problemi dei processi di produzione. Il processo software è uomo-centrico e il suo comportamento non è né simmetrico né conforme. Per questo la qualità dei processi deve essere continuamente monitorata. Il processo software è sperimentale a causa della diversità dei processi e dell’apprendimento delle tecnologie che ogni processo contiene. Per questo il suo miglioramento deve essere graduale. Principi accettati da tutti: -Il business è influenzato dalla qualità del prodotto/servizio offerto al cliente -La qualità del prodotto/servizio è determinata soprattutto da quella dei processi usati per svilupparlo e mantenerlo -Se migliori i tuoi processi/metodi puoi migliorare il tuo business. In generale esistono diversi approcci al miglioramento della qualità, tra cui alcune normative ISO. Gli schemi definiscono i livelli di qualità dei processi e come essi si caratterizzano. Essi aiutano a fornire le indicazioni per l’ottenimento di una certificazione di qualità ben precise, alcuni esempi sono ISO 9000 e ISO 12270. Invece CMM-I (Capability Maturity Model) e SPICE (Software Process Improvement and Capability dEtermination) rendono possibile certificare il livello di maturità di un’intera organizzazione o di uno specifico schema produttivo. I paradigmi non danno certificazioni ma sono modalità operative che descrivono i comportamenti da attuare per raggiungere un livello di qualità prefissato e come questo si migliora. Richiedono un modello di qualità. Ad esempio il PDCA (Plan Do Check Act, Macario…), il QIP (Quality Improvement Process), e l’EF (Experience Factory) Il ciclo PDCA, noto anche come il ciclo di Deming o ciclo di Shewhart, è un modello iterativo di gestione della qualità per il miglioramento continuo dei processi. Il Quality Improvement Process (QIP) è un approccio strutturato e sistematico per migliorare la qualità dei prodotti, servizi o processi di un'organizzazione. L'Experience Factory (EF) è un approccio strutturato per raccogliere, analizzare e riutilizzare le esperienze accumulate in progetti passati per migliorare i processi futuri. ISO 9000 (VISION 2000) La ISO-9000 è un insieme di standard di qualità che certifica il processo di produzione, non è rivolta solo al software, ma a tutti i settori produttivi (l’ISO in generale). Chi adotta l’ISO 9000 deve dotarsi di un Sistema Qualità che definisce le modalità per valutare, controllare e guidare la qualità di tutti i processi di produzione. I dettagli del sistema qualità sono contenuti in un Manuale di Qualità. L’azienda esplicita il proprio processo di produzione definendo il sistema qualità. Ad esempio, tutti i passaggi compiuti da un’azienda per la realizzazione di un software commissionato, includendo anche le riunioni giornaliere dello SCRUM. Il controllo è fatto da una persona esterna, rappresentante dell’ente ISO che verifica attraverso l’AUDIT che tutto quello che è dichiarato nel sistema di qualità corrisponda a quello che è effettivamente fatto (il rappresentante è detto “Auditor”), osservando il lavoro e raccogliendo evidenze delle informazioni su progetti ed attività eseguite. Verifica che non ci siano non conformità come dichiarazioni non vere, o nel caso di un AUDIT intermedio l’Auditor sceglie se continuare ad assegnare la certificazione ISO-9000 o no all’azienda che l’aveva avuta al controllo prima. In Ser&P una volta l’anno viene l’esperto che verifica, prendendo 3 o 4 progetti di riferimento, che Ser&P abbia usato il processo SCRUM, che nelle commit si seguano delle procedure dichiarate, che i fornitori siano scelti e censiti. Se ci sono non conformità le evidenzia nella relazione, e dà un tempo limite per eliminare le non conformità, per poi concedere la certificazione o revocarla dopo il secondo controllo effettuato alla scadenza del limite. La 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 ed uniformità in un determinato contesto e salvaguardare gli interessi dei consumatori e delle collettività. Punta, inoltre, a migliorare il sistema produttivo attraverso l’unificazione dei processi e dei prodotti e a migliorare lo scambio di informazioni attraverso l’applicazione di standard per simboli, codici, interfacce, etc. Infine promuove la sicurezza dell’uomo e dell’ambiente L’ISO-9000 è composto da 4 certificazioni (da 9000-1 a 9000-4), ognuna con una norma, che descrivono linee guida per diversi obiettivi. In generale, la ISO-9000 descrive i fondamenti dei sistemi di gestione per la qualità e ne specifica la terminologia. La 9000-2 ha linee guida per implementare le ISO 1, 2 e 3. La 9000-3 ha linee guida per l’applicazione dell’ISO 9001 per sviluppo, fornitura e mantenimento del software, mentre la 9000-4 è un’applicazione per la gestione dell’affidabilità. La ISO 9001 specifica i requisiti dei sistemi di gestione per la qualità da utilizzarsi quando un'organizzazione debba dimostrare la propria capacità a fornire prodotti che soddisfino i requisiti dei clienti e quelli obbligatori (cogenti) applicabili e miri a conseguire la soddisfazione dei clienti. La ISO 9004 fornisce delle linee guida che tengono conto sia dell'efficacia che dell'efficienza dei sistemi di gestione per la qualità. Lo scopo della guida è il miglioramento continuo delle prestazioni dell'organizzazione e la soddisfazione dei clienti e delle altre parti interessate (stakeholders). La ISO 19011 fornisce una guida sulle verifiche ispettive di sistemi di gestione per la qualità ed ambientali. Altre certificazioni per il settore (“Norme di settore”) sono la ISO IEC 12207 che formalizza i processi del ciclo di vita del software, ISO IEC 9126 per la qualità del prodotto software e ISO IEC14598 per la valutazione del prodotto (ora unite sotto il nome di ISO IEC 25000). Esistono diverse normative che consentono di certificare sia i processi di produzione che i prodotti, per standardizzare la qualità di produzione e riconoscere garanzie su quella dei prodotti. Nel dettaglio, la ISO IEC 12207 è volta al processo del ciclo di vita del software, una guida su come strutturare i processi utili allo sviluppo del software. Un’azienda può organizzare e strutturare i processi secondo la 12207, al di là del fatto che possa certificarsi o meno. Seguire il processo porta ad un lavoro iniziale più lungo, ma è un indice aggiunto di credibilità dell’azienda, inoltre alla fine si risparmiano tempo e denaro con meno costi di non conformità! Attualmente per partecipare ai bandi è necessaria la ISO-9000 ma anche la ISO-14000 (qualità ambientale). Per un’azienda software certificarsi ISO-14000 significa utilizzare approcci che riducono la durata dei test di un blocco di programmi software o utilizzare meno iterazioni possibili per ridurre il consumo elettrico, e mettere i pannelli solari, o stampare meno carta, non buttare ma smaltire ecologicamente i dispositivi non più in uso etc. L’ISO 12207 ha 3 categorie di processi: primari, di supporto, organizzativi (tipo particolare di processi di supporto). Processo primario: processi direttamente legati alla produzione del software. Sono i processi fondamentali per l’esistenza di un’azienda di produzione del software, come: 1. Acquisizione: definisce i processi che l’acquirente deve seguire per venire in possesso di un determinato software. 2. Fornitura: definisce le attività che il fornitore deve seguire per rendere disponibile l’acquisizione di software da parte di un cliente. 3. Sviluppo: si intendono le attività che devono essere eseguite per creare un software (bisogna dichiarare e formalizzare che il processo di sviluppo sia SCRUM-based, oppure waterfall, etc.). 4. Gestione operativa: si definiscono le attività dell’operatore, cioè colui che utilizza un calcolatore nell’organizzazione di cui fa parte. 5. Manutenzione: si dichiarano le attività che l’organizzazione deve seguire per la manutenzione del software (come pacchetti manutenzione, oppure garanzie, oppure il metodo di risposta alle richieste degli utenti come un sistema di ticket). I processi di supporto migliorano la qualità dei processi primari (coadiuvare), anche se non sono d’obbligo e sono: 1. Documentazione: manufatto di progetto utile a determinare come sono solitamente seguiti i processi e misurare la prestazione corrente. 2. Gestione della configurazione: include le operazioni necessarie alla catalogazione, identificazione e recupero di un qualsiasi manufatto prodotto per controllarne l’integrità e per verificare l’aderenza agli standard. 3. Assicurazione di qualità: definisce le attività necessarie a certificare che il prodotto software e il processo utilizzato per la sua costruzione siano conformi agli standard qualitativi fissati. 4. Verifica: definisce le attività da seguire per la verifica del processo utilizzato (controllo)(il modello è stato costruito correttamente?). 5. Validazione: definisce le attività da seguire per la validazione del processo utilizzato (è stato costruito il modello voluto?). 6. Revisione (joint review): definisce le attività da seguire per valutare lo stato e i prodotti di un’attività con lo scopo di informare il cliente sul progresso del progetto e assicurare che i prodotti soddisfino le sue necessità. 7. Audit: definisce le attività necessarie a determinare la conformità del prodotto software ai requisiti, al processo e al contratto. 8. Gestione dei problemi: definisce le attività necessarie a determinare e risolvere i problemi. L’adozione di processi di supporto dei processi primari aiuta ad avere un servizio migliore che richiederà poca manutenzione. Nel momento in cui non si hanno processi di supporto, la pianificazione e le previsioni diventano difficili e caotiche e possono richiedere alla fine molto più tempo. 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 della organizzazione. Con “struttura” si fa riferimento alla ripartizione di compiti, competenze, responsabilità e potere decisionale. 1. Gestione Processo 2. Gestione Infrastrutture 3. Miglioramento 4. Addestramento e Formazione CMM-I e SPICE Il concetto base dei modelli di processo è quello di andare ad esaminare (misurare) i processi di produzione di un’azienda e andarli a classificare con una scala che permetta di fare un rating della maturità del processo. Si parte dal livello più basso di “informale e caotico” al livello più alto di “miglioramento continuo”. Questo segue un pattern di miglioramento naturale: inizialmente quando non si ha dimestichezza con il processo, questo sarà informale e caotico, senza percezione di qualità. Una volta che si capisce cosa fare e come farlo si va verso un minimo di pianificazione con pratiche ripetibili, per poi passare a processi standardizzati. Una volta standardizzati i processi si possono introdurre concetti di qualità per migliorare i processi qualitativamente fino ad avere un miglioramento continuo nella qualità e nell’esecuzione dei processi con un monitoraggio costante. SPICE: Il modello SPICE [(Software Process Improvement and Capability dEtermination) è detto anche modello ISO 15504 (nome vecchio) o (oggi) ISO 33000.] serve a fare la valutazione, secondo lo standard, di ogni processo. Capisce la capacità di un processo e fornisce una guida per il miglioramento. In primo piano serve per una comprensione dei processi software nella propria organizzazione, determinare la capacità dei propri processi per fare un’analisi della situazione e dipendentemente dai risultati dell’analisi offre una guida per il miglioramento del processo. Il concetto alla base di SPICE è la valutazione di ogni processo, uno alla volta. L’azienda ha diversi processi che devono essere caratterizzati e valutati, e a seconda della valutazione, si determinano le capacità del processo. ISO / IEC 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 prodotti (software, sistemi e servizi IT). Ogni processo, in quanto tale, ha uno scopo. Attraverso gli strumenti messi a disposizione dalla normativa si può capire il livello di capacità del processo. (inutile) Bisogna identificare a quale categoria di processo appartiene ogni processo aziendale: secondo la normativa un’impresa ha un insieme di processi, i processi aziendali sono classificati in un insieme di categorie di processo, in particolare secondo la normativa esistono 5 categorie di processo: processi “fornitore-committente”:. Regolano la relazione con i committenti, impattando molto sulla loro soddisfazione (es. fornitura dei servizi e gestione delle varie commesse). processi “ingegneristici”: tutti i processi che riguardano la produzione, la manutenzione e lo sviluppo dei prodotti software. processi “progetti”: definizione dei processi di produzione, controllo e guida durante la loro esecuzione. processi “supporto”: definiscono tutte le azioni di supporto ai processi di produzione. processi “organizzazione”: definiscono gli obiettivi di business, i processi di sviluppo, le risorse disponibili (che consentono di raggiungere gli obiettivi di business). (Secondo lo standard, nel momento in cui un’azienda desidera certificarsi con la ISO/IEC 15504 c’è prima bisogno di capire i processi e organizzarli nelle 5 categorie) Il Livello di Capacità è un indicatore della qualità raggiunta nella gestione del processo stesso. Si determina con un set di attributi di processo, la ISO definisce un insieme di indicatori e metriche detti “attributi di processo” che vengono valutati da un esterno per determinare il livello di capacità dell’intero processo. Livello 0 (Non eseguito, Incompleto): Non è chiaro il processo specifico, non è chiaro come viene effettivamente eseguito il processo di produzione. Non c’è pianificazione formale. In generale c’è difformità nella esecuzione delle pratiche di base. Non sono identificabili facilmente i risultati parziali o finali del progetto. Livello 1 (Eseguito informalmente): Le pratiche di base del processo sono generalmente eseguite. Anche se qualche volta non sono rigorosamente pianificate e monitorate. Sono identificabili i risultati ed i prodotti parziali e finali. Non sono però presenti evidenze di pianificazione formale o formalizzazione del processo di produzione. Livello 2 (Pianificato e monitorato, Gestito): Abbiamo la certezza dell’utilizzo di pratiche standardizzate. La prestazione nelle pratiche di base è pianificata e monitorata. Le prestazioni sono verificate concordemente con predefinite procedure. I risultati ed i prodotti sono conformi a specifici standard. Livello 3 (Ben definito, Stabilito): Le pratiche di base sono eseguite in maniera formale, si sanno bene quali sono le attività da eseguire e si ha standardizzazione a livello organizzativo, ad esempio si usa lo SCRUM e si eseguono tutte le procedure in maniera standardizzata. (Un esempio di processo standardizzato a livello organizzativo può essere la gestione delle ferie o dei permessi fatta da un software, o con delle regole ben precise accompagnate da richieste formali come la compilazione di un form o un’e-mail specifica mandata a personale specifico.) Livello 4 (Quantitativamente controllato, Prevedibile): si usano misure quantitative a supporto di un uso di processi già standardizzati e ben definiti, cioè delle metriche, salvate attraverso grafici e statistiche o attraverso software specifici, per poter analizzare i dati in un database (ad esempio tool come Redmine, tutti gli strumenti che consentono di eseguire i processi di supporto). Livello 5 (Migliorato continuamente, Ottimizzato): Oltre a tutte le caratteristiche del livello 4 si aggiunge l’utilizzo dei grafici per capire se si sta andando nella giusta direzione, come capire i punti di debolezza o il livello di miglioramento. Si raccolgono delle misure quantitative che sono analizzate. Gli obiettivi di efficacia e di efficienza sono sempre definiti sulla base degli obiettivi di business. Il livello di capacità (ISO) è determinato dal grado di presenza (achievement) nel processo di 9 attributi di processo distribuiti su 5 diversi livelli di capacità. I 9 attributi sono degli indicatori ciascuno con un valore espresso su una scala definita, secondo le evidenze oggettive di ogni indicatore si assegna un rating da 1 a 4 in base al soddisfacimento dell’attributo. A livello 0 non ci sono attributi, mentre al livello 1 si ha un attributo di processo, e dal livello 2 al 5 si hanno 2 attributi di processo da valutare per ogni livello. La scala usata per valutare ogni attributo di processo è una scala ordinale N – P – L – F: Not achieved, Partially, Largely, Fully (conseguito). ISO/IEC 15504 fornisce linee guida per eseguire una valutazione (assessment) tramite interviste, raccolta di dati (convalidati e valutati) e documenti da parte di un valutatore esterno qualificato. Il processo è generalizzato nei seguenti passi: avviare una valutazione (sponsor di valutazione) selezionare il valutatore e il gruppo di valutazione pianificare la valutazione, compresi processi e unità organizzativa (responsabile e gruppo di valutazione) briefing prevalutazione raccolta dati convalida dei dati per assicurarsi che siano accurati e coprono completamente l'ambito della valutazione. valutazione del processo (rating) rispetto alle pratiche di base di un processo e generiche della capacità reporting del risultato della valutazione (assessment) 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 valutatore, cioè colui che raccoglie i dati, li convalida, e fornisce una valutazione di ogni processo deve essere a sua volta esaminato per capire le sue competenze in materia. Alla fine di tutto il processo di assessment si ritrovano tutti i processi censiti e per ognuno di essi si ha il grado di completezza grazie agli attributi di processo. Affinché ad un processo si possa attribuire un livello di capacità tutti gli attributi di processo prima di quel livello devono essere completamente completati (fully achieved, tutto nero), non basta manco il “largely achieved”. Per fare questo bisogna dimostrare che siano completati gli attributi di processo, con delle evidenze concrete e oggettive, con risultati documentati. L’assessment di qualità dei processi consente di fare una “fotografia” dei processi e decidere dove andare a focalizzare l’attenzione, su quali processi bisogna investire per farli salire di livello, ma l’organizzazione può anche consapevolmente decidere di migliorare fino al livello 5 solo i processi fondamentali e non i meno impattanti. CMM-I: Mentre lo SPICE consente di valutare la capacità dei singoli processi organizzativi, il CMM del Software Engineering Institute fa un’analisi della maturità dell’azienda intera per usarla come guida per il miglioramento dei processi. Mentre SPICE focalizza l’attenzione sulla capacità dei singoli processi, CMM fa una valutazione di maturità di tutta l’organizzazione, che viene censita a diversi livelli. Il concetto è sempre quello di avere una scala di valori che censisce qualcosa (processo nello SPICE, azienda nel CMM) per porre quell’azienda in un punto preciso e dare opportunità di miglioramento. Sono previsti tre classi di valutazione dei processi: Software Process Capability, è un metodo per predire il più probabile risultato atteso nei progetti software futuri. Software Process Performance, rappresenta il risultato raggiunto eseguendo un processo software Software Process Maturity, esprime quanto un processo sia definito, gestito, misurato, controllato ed efficace Utilizzi del CMM: Riesame: identificazione di punti di forza e debolezza dell’azienda; Valutazione di organizzazioni esterne per stimare i rischi nel selezionarle (es. gare di appalto); Guida per il Miglioramento del processo. I livelli di maturità sono concettualmente uguali a quelli di SPICE tuttavia qui è l’intera azienda e non i processi singoli. Inoltre, nel CMM non esiste il livello 0 ed ogni livello è uno strato delle fondamenta per il miglioramento continuo. 1. Iniziale. Il processo non è ben definito, il suo successo dipende solo dall’impegno personale degli sviluppatori. 2. 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. 3. Definito. Il processo è conforme agli standard dell’organizzazione e tutte le attività ingegneristiche e manageriali sono documentate. 4. Gestito. Dettagliate misure dei processi e dei prodotti sono rilevate e raccolte, così che siano ben capiti. 5. Ottimizzato. Il miglioramento continuo dei processi è attivo sfruttando le analisi postmortem dei progetti eseguiti e le opportunità di tecnologie innovative. Secondo il CMM esistono un insieme di aree chiave di processo, le quali identificano un insieme di attività che se eseguite assicurano la crescita dei processi, queste inoltre devono essere valutate e sono utili per fare una valutazione dell’azienda. Nello SPICE si giudica la capacità dei processi individuali mentre nel CMM si ha una visione d’insieme sulla maturità dei processi organizzativi Riassumendo, a differenza della ISO dove è l’azienda a gestire i processi, classificandoli, qui è lo standard che identifica quali devono essere i processi chiave di un’azienda, catalogandoli nei diversi livelli. Per ottenere un certo livello un’azienda deve seguire i processi definiti dal CMM. I fattori comuni sono attributi per assicurare che l’esecuzione e la istituzionalizzazione di un processo chiave è efficace, ripetibile e definitivo, cioè sono un insieme di attività da eseguire. Le attività sono “sviscerate” in una serie di pratiche chiave (immagine) che devono essere applicate, eseguite e verificate nel momento in cui si fa la valutazione del modello di maturità. Il modello di maturità è strutturato in 5 aree chiave, ciascuna con fattori comuni che vanno verificati, verificando che ciascuna delle attività delle aree chiave sono eseguite dall’azienda. Non dobbiamo conoscere a memoria tutti i fattori comuni e aree chiave, ma dobbiamo sapere che il CMM è diviso in aree chiave, ognuna con la propria struttura ad attività, e che la verifica della maturità viene fatta verificando che le attività dele aree chiave siano effettivamente eseguite (completamente) per arrivare ad un certo livello. Gran parte delle aziende certificate CMM è a livello 3. Il CMM è uno standard specifico delle aree dell’ingegneria del software, invece l’ISO è per tutte le attività. Il CMM definisce il concetto di maturità dell’intera organizzazione detto “Staged representation”. Dopo il 2000 sono state integrate nel modello anche delle specializzazioni in 3 settori: Sviluppo, Servizi, Acquisizioni, il CMM ha cambiato così nome in CMMI (Capability Maturity Model Integration). Quello che rimane fisso è il fatto che il CMM è un programma di addestramento e valutazione del miglioramento dei processi e può essere usato per guidare il miglioramento dei processi attraverso un progetto, una divisione o un'intera organizzazione. Secondo il Software Engineering Institute (SEI, 2008), CMMI aiuta a "integrare funzioni organizzative che sono tradizionalmente separate; stabilire obiettivi e priorità di miglioramento dei processi; fornire linee guida per assicurare processi di qualità e fornire un punto di riferimento per la valutazione dei processi in organizzativi". Oggi la struttura del CMM è come un diagramma di Venn che ha intersezioni tra le 16 aree chiave di processo. Il CMM inizia con l’acquisizione, che comprende tutto il processo di progettazione e sviluppo. La parte di sviluppo è propria delle parti che vanno dai requisiti alla consegna, mentre la parte servizi è l’ultima. Aree di processo per maturità e categoria (i colori corrispondono molto poco) Per assegnare un livello servono delle evidenze comuni. ( recap dei 5 livelli ma come spiegato dalla prof: ) 1 Iniziale, non esiste organizzazione ed il processo non è ben definito, si fa qualcosa ma in maniera casuale e non formale. 2 Ripetibile, il processo è gestito in maniera informale, è caratterizzato per l’organizzazione e non standard, tuttavia il proceso è sufficientemente disciplinato per essere ripetuto. 3 Definito, si introduce il formalismo, i processi e le procedure sono standardizzati e si ha un approccio organizzato 4 Gestito, si effettuano misure dei processi per poter effettuare delle analisi, il processo è misurato e controllato 5 Ottimizzato, si fanno controlli statistici sui processi e si attua il miglioramento continuo, sfruttando le analisi postmortem dei progetti eseguiti. Sono poche le aziende certificate CMM livello 5 e sono soprattutto in Cina, India e Brasile, per attirare gli americani che hanno creato gli standard, inoltre la certificazione è una garanzia di qualità ed è un “bigliettino da visita”. Le aree chiave di processo si trovano maggiormente ai livelli 2 e 3, mentre i livelli 4 e 5 sono specifici e focalizzati dul miglioramento. Al livello 1 ovviamente non ce ne sono perché è il livello minimo. Il CMM può essere interpretato sia come un modello che descrive i livelli di maturità di un'organizzazione, sia come un sistema che raggruppa i processi in diverse categorie. Queste categorie sono quattro: Process Management (Gestione dei processi) Project Management (Gestione dei progetti) Engineering (Ingegneria) Support (Supporto) Ogni processo è associato a un’area chiave (Key Process Area, KPA). La norma ISO 33000 (SPICE), invece, si concentra sulla valutazione delle capacità dei processi e suddivide i processi in cinque categorie, ciascuna delle quali è associata a nove attributi di processo. L'obiettivo principale della SPICE è certificare la capacità dei singoli processi, non dell’intera organizzazione. Nel modello CMM-I (Capability Maturity Model Integration), invece, ci sono cinque livelli di maturità che valutano l’intera organizzazione. Questi livelli sono basati sulle Key Process Areas (KPA), che includono 16 processi complessivi, suddivisi in tre categorie: Acquisizione (ACQ) Sviluppo (DEV) Servizi (SVC) Il Project Planning (PP) è una delle aree chiave di processo, che ha come obiettivo strutturare un piano per definire le attività principali. Un’evidenza di questo può essere un Gantt. Si forniscono i fattori comuni (obiettivi) che bisogna raggiungere e specifica operativamente attraverso le pratiche chiavi, cioè un insieme di attività, cosa bisogna fare per raggiungere l’obiettivo. Il PP è quella KPA il cui scopo è quello di definire e condurre una pianificazione in grado di definire le attività di processo. Vengono effettuate delle stime sul PP e vengono stabiliti criteri di PP per le stime. Operativamente le pratiche specifiche (SP) definiscono nel dettaglio cosa fare, e bisogna dare evidenza del fatto che si sono seguite le linee guida, ad esempio si certificano inizio e durata del progetto, per ogni attività si fornisce una stima di costo delle attività e di impegno necessario. Il primo obiettivo è stimare che la pianificazione dei parametri di progetto sia stabilita e manutenuta. Il secondo obiettivo è quello di stabilire un piano, che deve essere mantenuto come base per la gestione del progetto, ad esempio si crea e valuta un MVP (prototipo minimo, che serve a far capire che si è compreso il compito) Il terzo obiettivo evidenzia come bisogna fornire quelle evidenze in merito all’esecuzione del piano. Si può avere la necessità di modificare la pianificazione per adeguarla a nuove condizioni, questo fa anche parte della parte di gestione del rischio dell’obiettivo 2. Il Project Monitoring and Control (PMC) (pdf) è un’altra area chiave di processo, che ha l’obiettivo di fornire una comprensione del progresso del processo così che si possano effettuare azioni correttive quando la performance del processo devia significativamente dal piano. Ha 2 obiettivi, la performance attuale del progetto e il progresso devono essere monitorati rispetto al piano, e le azioni correttive sono eseguite quando la performance o i risultati deviano dal piano. Tutto ciò serve per preparare l’organizzazione alla valutazione (appraisal). Tramite il loro “quality assessment team” si strutturano i processi secondo le KPA, così che possano essere valutate con il livello di maturità. Perché un’azienda vorrebbe proporsi per una valutazione CMM? Per informare clienti e fornitori esterni di come l’azienda soddisfi le pratiche migliori di processo, per poter attirare più gente, come un bigliettino da visita verso l’esterno, per poter soddisfare i requisiti contrattuali di uno o più clienti. Inoltre, un’azienda può capire se le proprie pratiche sono qualitativamente soddisfacenti, e dove migliorare. Il metodo per condurre le valutazioni CMMI è lo “Standard CMMI Appraisal Method for Process Improvement” (SCAMPI). I risultati di una valutazione SCAMPI possono essere pubblicati (se l'organizzazione valutata approva) sul sito Web CMMI del SEI. SCAMPI supporta anche la condotta di ISO/IEC-15504, nota anche come SPICE Assessments (Software Process Improvement and Capability Determination). Essendoci delle parti comuni chi ha la ISO 33000 può certificarsi CMM-I senza troppi sforzi. SPICE e CMMI si sono influenzati e ispirati a vicenda. Nel 2000 viene introdotta la “Continuous Representation” nel CMM-I, cioè viene introdotta la possibilità di valutare la capacità dei processi, e alla stessa maniera SPICE aggiunge la capacità di valutare l’intera organizzazione, integrano quello che aveva fatto l’altro standard. La differenza maggiore tra i 2 standard è che CMM-I definisce i processi mentre in SPICE sono definiti dall’azienda. Il CMM-I è stato originariamente sviluppato come modello staged (a livelli), mentre la ISO 33000 è nata come modello continuous (continuo). Oggi, entrambi i modelli integrano sia l’approccio staged che quello continuous, offrendo due rappresentazioni complementari: Rappresentazione Staged: ○ Utilizza i livelli di maturità complessiva dell’organizzazione (rappresentati spesso come una piramide) per misurare il miglioramento dei processi. ○ I livelli di maturità si riferiscono alla maturità complessiva dell'organizzazione. ○ Il miglioramento è guidato dall’avanzamento di insiemi predefiniti di aree di processo (Key Process Areas, KPA). Rappresentazione Continuous: ○ Utilizza i livelli di capacità per misurare il miglioramento dei singoli processi. ○ I livelli di capacità si applicano al miglioramento dei processi di un’organizzazione per ciascuna area di processo (KPA). ○ I miglioramenti sono focalizzati su singole aree di processo, una alla volta. Il contenuto di entrambe le rappresentazioni è molto simile, ma si differenziano nel metodo di misurazione e gestione del miglioramento: la rappresentazione staged valuta la maturità complessiva dell’organizzazione, mentre la rappresentazione continuous si concentra sulle capacità specifiche delle singole aree di processo. Confronto tra CMM-I e SPICE Proprietà: ○ CMMI è proprietario ed è stato sviluppato dal Software Engineering Institute (SEI). ○ SPICE è uno standard internazionale della serie ISO/IEC 15504, sviluppato e gestito da ISO/IEC. Dominio di applicazione: ○ CMMI è un sistema chiuso, composto da tre modelli principali: DEV (Sviluppo) SVC (Servizi) ACQ (Acquisizione) ○ SPICE è un sistema aperto: Definisce regole per costruire modelli di processo applicabili a qualsiasi disciplina. Chiunque può sviluppare modelli di processo per le valutazioni SPICE. Diversi modelli di processo sono stati sviluppati e standardizzati da ISO/IEC. Rappresentazioni Staged e Continuous: ○ Entrambi i modelli (CMMI e SPICE) supportano sia l’approccio staged che quello continuous. ○ I livelli di maturità possono essere derivati dai profili di capacità in entrambi i modelli. ○ Nell’ultima versione di CMMI (v1.3), i livelli di capacità sono stati ridotti da cinque a tre. ○ Una differenza importante è che CMMI include un livello di maturità vuoto (Maturity Level 1), mentre SPICE prevede processi base già al primo livello. Implementazione e Scelta delle Rappresentazioni Le rappresentazioni Staged e Continuous forniscono contenuti simili, ma rappresentati in modo diverso. La scelta dell’approccio più adatto dipende da vari fattori, tra cui: Gli obiettivi di business. La cultura organizzativa. La storia e le esperienze pregresse dell’organizzazione. È possibile mescolare le rappresentazioni in base alle esigenze: Implementare Continuous e valutare i risultati a livello organizzativo con Staged. Implementare Staged e valutare i risultati delle singole aree di processo con Continuous. Utilizzare entrambe le rappresentazioni (Staged e Continuous) per diverse parti dell’organizzazione. In ogni caso, è fondamentale assicurare che le attività di miglioramento continuo dei processi siano sempre collegate agli obiettivi di business. PROJECT MANAGEMENT Le attività principali in capo al Project Manager sono: Pianificare: identificare gli obiettivi del progetto e dell’impresa e definire procedure, policy e quant’altro necessario a raggiungerli; Integrare: fondere sinergicamente i contributi e semilavorati prodotti singole unità al fine di realizzare i prodotto/servizio in output al progetto; Eseguire i piani: orchestrare opportunamente le risorse dell’impresa al fine di raggiungere gli obiettivi di progetto in accordo alla pianificazione definita. I concetti di “gestione del progetto” sono uguali per molte figure professionali come ingegnere gestionale ma anche architetto, dottore in software etc. Fare una gestione del progetto significa anche raggruppare, integrare i risultati intermedi da diversi processi o linee di produzione. Ogni progetto ha alla base un minimo di pianificazione che dà una guida, e il PM deve essere in grado di organizzare le risorse per poter raggiungere gli obiettivi. La pianificazione, in particolare, si rende necessaria per: ridurre l’incertezza, accrescere l’efficienza dell’esecuzione di un progetto, pervenire ad una migliore comprensione degli obiettivi del progetto consentire il monitoraggio e controllo del lavoro. La pianificazione parte da un insieme di assunzioni in termini di: obiettivi perseguiti, benefici attesi, fattori ambientali e organizzativi, caratteristiche del prodotto/servizio da realizzare etc. Successivamente, viene prodotto il Project Management Plan che definisce i dettagli del come eseguire, monitorare, controllare e chiudere il progetto. Tra le assunzioni più importanti nell’ambito della pianificazione vi sono quelle relative a: Fattori ambientali: fattori ambientali esterni che possono influenzare la riuscita del progetto come, ad esempio, le condizioni del mercato, grado di interesse, tecnologie disponibili etc. Fattori organizzativi: assunzioni circa gli assets presenti e futuri dell’impresa come esisenza di metodologie, sistemi di supporto, best practices etc. Pianificazione in generale Pianificare implica il determinare cosa fare, quando, come e chi lo fa. Ci sono nove componenti principali della fase di pianificazione: Obiettivi, che si intendono raggiungere; Programma, ovvero la strategia che si intende adottare per raggiungere gli obiettivi; Schedulazione, ovvero la tempificazione in termini di avvio e terminazione delle attività che singoli o gruppi devono eseguire; Budget, ovvero la pianificazione della spesa necessaria per il raggiungimento degli obiettivi; Previsione, ovvero una proiezione di quel che accadrà; Organizzazione, ovvero identificazione del tipo e numero di posizioni, del corrispondente compreso e conseguenti responsabilità; Politiche aziendali, (Policy), ovvero linee guida generali per l’assunzione di decisioni e le azioni individuali; Procedure, ovvero l’insieme dettagliato dei passi necessari ad implementare le policy; Standard, ovvero i livelli di performance che singoli piuttosto che gruppi devono garantire per la riuscita del progetto. La pianificazione, altresì, la si può intendere su più livelli: Strategica, quando guarda ad obiettivi strategici da conseguire su un arco temporale di 5 o più anni; Tattica, quando fa riferimento ad obiettivi concreti di medio lungo periodo, da 1 a 5 anni; Operativa, quando fa riferimento all’immediato, dai 6 mesi ad 1 anno. A livello operativo le previsioni sono più semplici e meno sensibili ai fattori ambientali ed organizzativi. A livello strategico-tattico, invece, presentano notevoli difficoltà. Con riferimento a politiche, procedure e standard si evidenzia che variano da progetto a progetto a causa dell'unicità di ognuno di questi. Le politiche, in generale, sono leggermente più stabili. Avere un piano consente di avere sotto controllo una serie di altri aspetti compresi il raggiungimento delle caratteristiche del prodotto o servizio da lanciare sul mercato, ma anche gestire le risorse disponibili. Tutto è compreso in quello che si dice Project Management Plan. Il project management non è una cosa implicita, ma il project manager è una figura concreta Il Project Management è l’applicazione di conoscenze, capacità, strumenti e tecniche alle attività di progetto per soddisfare i requisiti del progetto stesso rispettando i costi, i tempi, e i livelli di qualità. Quando si realizza un progetto è necessario sapere le variabili come il tempo disponibile (o il giorno di consegna), le risorse disponibili in denaro o dispositivi, e la qualità che bisogna rispettare, cioè i requisiti non funzionali come “software portabile”. Bisogna usare al meglio le risorse necessarie senza andare a spendere tempo e soldi inutilmente. Il PMI (Project Management Institute) definisce il PMBOK, project management book of knowledge, cioè tutte le line guida e le buone pratiche che si dovrebbero seguire nella gestione del progetto. Il PMI definisce 5 gruppi di attività che devono essere eseguite per ogni processo: Avvio, Pianificazione, Esecuzione, Monitoraggio e Controllo, Chiusura. La gestione del progetto indica sicuramente l’identificazione dei requisiti, ma deve anche prendere in considerazione le varie esigenze degli utenti potenziali del prodotto, il progetto non deve essere un investimento senza senso; quindi, si identificano gli stakeholder e si fa in modo che le loro esigenze siano rispettate. Inoltre, bisogna bilanciare i vincoli, cioè i costi, le risorse, i rischi, il tempo a disposizione. Questi fattori non sono indipendenti, modificando uno dei vincoli si impattano anche gli altri, quindi, bisogna tenere conto delle interdipendenze. Si può dire che un progetto è considerato di successo nel momento in cui rispetta la pianificazione, quindi finisce nei tempi definiti rispettando i budget, rispettando le caratteristiche funzionali e qualitative fissate, con l’accettazione del committente, con cambiamenti minimi (cioè c’è un margine di errore) rispetto allo scopo iniziale, senza aver causato disturbo ed impatti negativi sulla normale produzione e senza aver cambiato la cultura dell’impresa. Oltre al PM esistono altre persone che hanno un ruolo nel successo del progetto. I ruoli sono: Project Manager, Line manager, Subordinates/associates, Top management e Project Sponsor. Il PMI organizza i processi in 5 gruppi. Ci sono 49 aree di processo, che, come mappa il PMI, sono distribuite nei vari gruppi di processo indicando anche delle caratteristiche di ogni attività in ogni gruppo. (questo pdf slide 11) Il gruppo di processi di AVVIO è l’insieme dei processi necessari alla definizione di un nuovo progetto o fase (nel caso di progetti esistenti), all’ottenimento della formale autorizzazione all’avvio delle attività, alla definizione dello scope di progetto, all’allocazione delle risorse finanziarie necessarie, alla individuazione degli stakeholder del progetto, alla individuazione del Project Manager qualora non sia già stato individuato, alla identificazione dei prodotti attesi a valle del progetto, alla definizione della durata, allo studio di fattibilità, di mercato e sostenibilità dell’iniziativa in termini tecnologici, sociali, legali. Il gruppo dei processi di Pianificazione è l’insieme dei processi che servono a definire lo scopo del processo, gli obiettivi, il flusso di azioni da fare, in maniera molto più dettagliata. Si vanno a vedere nel dettaglio le attività in modo che nell’esecuzione non ci siano livelli di libertà. L’insieme dei processi di pianificazione vengono eseguiti iterativamente ogni volta che di verifica un qualche evento che richiede di rivisitare la pianificazione fatta e le assunzioni alla base di questa. Pianificare significa disciplinare, all’interno del progetto, tutti gli aspetti concernenti: Visibilità e portata (Scope), Tempo (Time), Costi (Costs), Qualità (Quality), Comunicazione (Communication), Risorse (Resource), Rischi (Risks), Acquisizione (Procurement) Il gruppo dei processi di Esecuzione comprende i processi che complessivamente consentono la messa in opera della pianificazione fatta. Tali processi devono essere flessibili rispetto alle variazioni nella pianificazione e, al contempo, la pianificazione deve conformarsi alla esecuzione soprattutto nel caso di mancato rispetto dei vincoli imposti. L’esecuzione può, in alcuni casi, prendere un’altra strada rispetto a quanto detto dalla pianificazione. In quel caso la modifica all’esecuzione, quando approvata da tutti e verificata, deve diventare anche modifica della pianificazione. Questi processi assorbono la maggior parte delle risorse e del budget nell’esecuzione di un progetto Il gruppo dei processi di Monitoraggio e Controllo comprende i processi necessari a tracciare e revisionare il lavoro fatto, gestire il progresso del progetto e le sue performance, controllare i camb

Modelli e metodi per la qualità del software PDF - Appunti Universitari

Document Details

Tags

Related

Summary

Full Transcript