Modelli e metodi per la qualità del Software PDF

Modelli e metodi per la qualità del Software Riassunto del materiale didattico Miglioramento continuo dei processi =================================== Per costruire software di qualità è necessario **superare tutti i problemi dei processi di produzione**. In quanto **uomocentrico**, il **processo...

Modelli e metodi per la qualità del Software Riassunto del materiale didattico Miglioramento continuo dei processi =================================== Per costruire software di qualità è necessario **superare tutti i problemi dei processi di produzione**. In quanto **uomocentrico**, il **processo** **software** non è né simmetrico e né conforme e **deve essere** **continuamente** **monitorato**. La **diversità** dei processi e quella dell'apprendimento delle tecnologie rende il **processo software sperimentale**, e **il suo miglioramento graduale**. Il Business è influenzato direttamente dalla **qualità** dei **prodotti** o **servizi** **offerti** ai clienti. La **qualità** dei **prodotti/servizi** è, d'altra parte, **influenzata** dalla **qualità** dei **processi** di sviluppo. **Migliorare i processi migliora quindi il Business**. Il miglioramento della qualità segue degli **schemi** che definiscono i livelli di qualità dei processi e come essi si caratterizzano. Questi prevedono anche un modello di qualità. - ISO 9000; - ISO 12270; - Capability Maturity Model (CMM-I); - Software Process Improvement and Capability dEtermination (SPICE). I **paradigmi** definiscono una strategia per il raggiungimento di un livello di qualità prefissato, e come questo si migliora. Questi richiedono un modello di qualità. - **Plan Do Check Act** (**PDCA**); - **Quality Improvement Process** (**QIP**); - **Experience Factory** (**EF**). ### ISO 9000 (VISION 2000) #### Principi di base Esso è un **insieme di standard** per il **controllo** e la **guida** della **qualità** in tutti i settori produttivi. L'organizzazione che lo adotta deve adottare un **Sistema Qualità** che definisce le **modalità** per **valutare**, **controllare** e **guidare** la **qualità** di tutti i **processi** di produzione. I dettagli del Sistema Qualità sono contenuti in **Manuale di Qualità**. ### Le norme per i sistemi di qualità Una **norma** è un **documento** prodotto attraverso consenso e approvato da un organismo riconosciuto. Fornisce, per usi comuni e ripetuti, **le caratteristiche o le linee guida relative a determinate attività o prodotti**. Ha lo **scopo di assicurare ordine e uniformità** in un determinato **contesto**. Si pone come obiettivi quelli di: - **Salvaguardare** gli **interessi** dei **consumatori** e della collettività; - **Migliorare** il sistema produttivo attraverso l'**unificazione** dei **processi** e dei **prodotti**; - **Migliorare** lo **scambio** di informazioni attraverso l'**applicazione** di **standard** per simboli, codici, interfacce...; - **Promuovere la sicurezza dell'uomo e dell'ambiente**. #### Significato delle norme - **ISO** **9000**: descrive i **fondamenti** dei **sistemi** di **gestione** per la qualità e ne specifica la **terminologia**. - **ISO** **9001**: specifica i **requisiti dei sistemi di gestione per la qualità** da utilizzare quando un'organizzazione deve dimostrare la propria capacità a fornire prodotti in grado di **soddisfare i** **requisiti** dei clienti, quelli legali e normativi e che migliorino la **soddisfazione dei clienti**. - **ISO** **9004**: fornisce delle **linee guida** che tengono conto **dell'efficacia** e **dell'efficienza** dei **sistemi** **di gestione per la qualità**. Lo scopo della guida è il **miglioramento** **continuo** delle prestazioni dell'organizzazione, della **soddisfazione** di **clienti** e **stakeholders**. - **ISO** **19011**: fornisce una guida sulle **verifiche ispettive** di sistemi di gestione per la qualità e ambientali. #### Norme di settore - **ISO** **IEC** **12207**: definisce i processi del **ciclo di vita** del software; - **ISO** **IEC** **9126**: riguarda la **qualità** del **prodotto** **software**; - **ISO** **IEC** **14598**: definisce il **processo** per la **valutazione dei prodotti**; - **ISO** **IEC** **25000**: definisce un **quadro completo** della **qualità del software**, **incorpora** le norme **ISO IEC 9126 e ISO IEC 14598**. ### ISO IEC 12207: Software Lifecycle Processes La norma **ISO/IEC 12207** definisce un quadro di **riferimento** per i **processi** del **ciclo di vita del software**, coprendo tutte le fasi **dalla concezione alla dismissione**. ISO/IEC 12207 è organizzata in tre categorie di processi: **processi** **primari**, **processi di supporto** e **processi organizzativi**. #### Processi primari Sono quelli che **portano alla realizzazione della missione dell'organizzazione**, determinando in generale la produzione del sistema software. Si dividono in cinque categorie: 1. **Acquisizione**: definisce le **attività** che l'**acquirente** deve eseguire per **entrare in possesso di un determinato software**. Si rivolge alle organizzazioni che acquistano un sistema, prodotto o servizio software. 2. **Fornitura**: definisce le **attività** che il **fornitore** deve eseguire per **rendere disponibile l'acquisizione di software da parte di un committente**. Si rivolge alle organizzazioni che forniscono/vendono un sistema, prodotto o servizio software. 3. **Sviluppo**: definisce le attività che devono essere seguite dall'organizzazione per la **definizione e lo sviluppo di un prodotto** software. *Esempio: analisi dei requisiti del sistema e del software, progettazione architetturale del sistema e del software, progettazione di dettaglio del software, codifica e test, integrazione del sistema e del software, test di qualificazione del sistema e del software...* 4. **Gestione** **operativa**: definisce le **attività dell'operatore**, ovvero colui che **utilizza** un calcolatore **all'interno dell'organizzazione** di cui fa parte. 5. **Manutenzione**: definisce le **attività** che l'organizzazione deve seguire per la **manutenzione di un prodotto software**. #### Processi di supporto **Coadiuvano** l'esecuzione dei processi primari fornendovi servizi che contribuiscono al successo e alla qualità di un progetto. Si dividono in otto categorie: 1. **Documentazione**: attività dinamiche con alto valore aggiunto, importanti per il miglioramento della qualità. Quando le procedure sono documentate, spiegate e attuate, è possibile **determinare** con confidenza **come sono eseguiti solitamente i processi** e **misurarne le prestazioni**. Di conseguenza, la **misurazione** dell'effetto di una modifica è **più affidabile**. Inoltre, documentare le procedure correnti è **essenziale per preservare i miglioramenti** della qualità e garantire che le **buone** **pratiche** vengano **mantenute nel tempo**. 2. **Gestione della configurazione**: **fulcro** intorno al quale ruota la **produzione**, include le operazioni necessarie alla **catalogazione**, **identificazione** e **recupero** di un qualsiasi **manufatto** **prodotto** **all'interno dell'organizzazione**. La gestione della configurazione è necessaria per **controllare** tutti gli **artefatti ottenuti dall'esecuzione** del processo e verificarne la loro **conformità** agli standard imposti. La gestione della configurazione si realizza attraverso: a. **Identificazione** degli **artefatti** generati dai processi; b. **Controllo** delle **modifiche** e delle release del software; c. **Registrazione** dello **stato** degli artefatti e delle richieste di modifica; d. **Verifica** della **completezza** e **coerenza** degli artefatti prodotti. 3. **Assicurazione della qualità**: garantisce che sia il **prodotto** software sia il **processo** di sviluppo **rispettino** **gli** **standard** **qualitativi** stabiliti dall\'organizzazione. Si realizza attraverso: e. **Pianificazione**: identificazione, programmazione e schedulazione delle attività di quality assurance, incluse le misurazioni; f. **Definizione** **degli** **standard**: scelta di metodi, procedure e strumenti per garantire la qualità; g. **Allocazione** **delle** **risorse**: identificazione delle risorse necessarie e delle responsabilità; h. **Esecuzione** delle attività. 4. **Verifica**: definisce le **attività**, **a carico dell'organizzazione**, da seguire per la **verifica del processo** utilizzato. Viene effettuata alla fine di **ogni fase** prevista e determina se l'esecuzione del processo è conforme al modello di processo adottato, se il prodotto è conforme al **prodotto atteso** in termini di costi, risorse impiegate, requisiti, vincoli ecc. 5. **Validazione**: definisce le attività da seguire per la validazione (da parte del fornitore o del beneficiario) di un prodotto software, ovvero se esso **soddisfa la richiesta**. 6. **Revisione o joint review**: processo di **valutazione** dello **stato** e dei prodotti di un\'attività, con lo scopo di **informare** **il cliente sui progressi** del progetto e garantire che i **risultati** raggiunti siano **conformi** alle sue **esigenze**/requisiti. Le attività di questo processo si compongono di diverse tipologie: **revisione del contratto**, **revisione tecnica** e **revisione di accettazione**. Tali verifiche sono effettuate durante le **fasi di sviluppo** e i **periodi** sono definiti nel **contratto**. 7. **Audit**: definisce le attività necessarie a **determinare** la **conformità** dei prodotti ai **requisiti**, al **processo** e al **contratto**. In **alcuni casi** questo processo viene **assorbito dal processo di assicurazione della qualità o da quelli di verifica e validazione**. 8. **Gestione dei problemi**: definisce le attività volte all'**individuazione** e **risoluzione** di **problemi** di qualunque natura e in qualsiasi fase essi siano riscontrati. Comprende le seguenti fasi: i. **Realizzazione** del **report** dei problemi; j. **Definizione** della **priorità** del problema; k. **Determinazione** della **risoluzione**; l. **Correzione** dei difetti; m. **Distribuzione** del prodotto corretto. #### Processi organizzativi Utilizzati per **definire e implementare una struttura logica di fondo da seguire**, al fine di migliorare la struttura stessa e i processi utilizzati all'interno dell'organizzazione. Con "**struttura**" si intende far riferimento alla ripartizione di compiti, competenze, responsabilità e potere decisionale all'interno dell'organizzazione (definizione dell'organigramma). I processi organizzativi si suddividono in quattro categorie: 1. **Gestione** **del processo**: definisce le **attività** di base per la **gestione** **dell'organizzazione** e dei **processi coinvolti** nel ciclo di vita di un progetto o prodotto software. 2. **Gestione infrastrutture**: definisce le **attività** da seguire per **determinare** e **manutenere** le **infrastrutture** (hardware, software, tools, standards...) di cui necessitano gli altri processi. 3. **Miglioramento**: definisce le **attività** necessarie per determinare, consolidare, misurare, controllare e **migliorare i processi** coinvolti nel ciclo di vita di un software. 4. **Addestramento e formazione**: definisce le **attività** necessarie a dare un'adeguata **formazione** alle **risorse umane** all'interno dell'organizzazione. ### Process models (Modelli di Processo) I **modelli di processo** sono molto utili per definire l\'**insieme** **dei** **processi** da implementare, la \"natura\" delle **capacità dei processi** e un percorso per il **miglioramento**. Tuttavia, è importante fare attenzione: **i modelli sono solo un\'approssimazione semplificata della realtà**, che offre una visione generale ma non può cogliere tutte le **complessità** del mondo reale. Ecco alcuni esempi di modelli di processo: - **CMMI** (**Capability Maturity Model Integration**): è un modello che aiuta le **organizzazioni** a **migliorare** i propri **processi** di sviluppo software e gestione. Si basa su una serie di **livelli di** **maturità** che guidano l\'**evoluzione** **delle capacità di processo**. - **SPICE** (**Software Process Improvement and Capability dEtermination**): fornisce una **struttura** per la **valutazione** e il **miglioramento** dei **processi** di sviluppo software. SPICE si concentra sull\'**analisi** **della capacità dei processi** e sulla loro **evoluzione** verso una **maggiore** **efficienza**. - **SOA (Service-Oriented Architecture)**: descrive un approccio architetturale per lo sviluppo di software che enfatizza l\'interoperabilità e la modularità. Si tratta di un paradigma che permette di strutturare i processi aziendali in modo flessibile e facilmente integrabile. - **COBIT (Control Objectives for Information and Related Technologies)**: framework per la gestione e il controllo dei processi software. Supporta le organizzazioni nella gestione dei rischi e nell\'uso delle tecnologie informatiche, migliorando la governance e l\'efficienza dei processi. ### ISO IEC 15504 (oggi ISO 33000): The SPICE Project (Software Process Improvement and Capability dEtermination) #### Principi base Perché adottare ISO IEC 15504? Tre principali motivi: - **Comprensione dei processi** software operanti nella propria organizzazione; - **Determinazione delle capacità dei processi**, sia della propria organizzazione che delle organizzazioni fornitrici; - **Guida il miglioramento del processo** attraverso le analisi delle misure e l'individuazione dei processi da migliorare. ISO/IEC 15504 è un modello di riferimento per valutare la **maturità dei processi** all\'interno di un\'organizzazione. Si basa su **livelli di capacità**, che sono suddivisi in attributi del processo e consistono in pratiche generiche. I **valutatori** raccolgono evidenze durante la valutazione per determinare la **capacità dell\'organizzazione** di fornire prodotti (software, sistemi e servizi IT) di qualità. #### Categorie di processo Tutti i processi di un\'organizzazione sono classificati in categorie: - **Fornitore-Committente**: regolano la **relazione** con i committenti ed impattano 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 assicurarne l\'efficacia; - **Organizzazione**: definizione degli **obiettivi** **di** **business** e dei processi di sviluppo, prodotti, risorse disponibili che consentono di **raggiungere** tali **obiettivi** di business. #### Livelli di capacità Il **livello di capacità** è un **indicatore** della **qualità raggiunta** nella gestione del **processo**. Si determina attraverso l'osservazione di un set di **attributi di processo**, associati a ciascun livello. I livelli di capacità si riferiscono al **singolo processo** e non all'intero set. +-----------------------------------+-----------------------------------+ | #### Livello | #### Definizione | +===================================+===================================+ | 0 | **Difformità** | | | **nell'esecuzione** delle | | **Non eseguito**\ | pratiche di base e **risultati** | | *Incompleto* | finali o parziali del progetto | | | **non facilmente | | | identificabili**. | +-----------------------------------+-----------------------------------+ | 1 | Le **pratiche di base** del | | | processo sono **generalmente | | **Eseguito informalmente**\ | eseguite**, anche se a volte | | Eseguito | **non rigorosamente** pianificate | | | e monitorate. Sono | | | **identificabili i risultati** e | | | i prodotti parziali e finali. | +-----------------------------------+-----------------------------------+ | 2 | La prestazione nelle **pratiche | | | di base** è **pianificata** e | | **Pianificato e monitorato**\ | **monitorata** **coerentemente** | | *Gestito* | con procedure **predefinite**. I | | | **risultati** e i prodotti sono | | | **conformi** a specifici | | | standard. | +-----------------------------------+-----------------------------------+ | 3 | Le **pratiche di base** sono | | | **eseguite** **concordemente** | | **Ben definito**\ | con un **processo definito**, il | | *Stabilito* | quale è una **specializzazione di | | | un processo** **standard** | | | preventivamente approvato. Questo | | | livello si differenzia dal | | | precedente in quanto il | | | **processo è definito e | | | controllato** usando un processo | | | standard a livello di | | | organizzazione. | +-----------------------------------+-----------------------------------+ | 4 | Le **misure** **di** | | | **prestazione** sono **raccolte** | | **Quantitativamente | e **analizzate** così da poter | | controllato**\ | capire **quantitativamente** il | | *Prevedibile* | processo e stimarne a priori le | | | prestazioni. La qualità dei | | | prodotti e dei risultati sono | | | quantitativamente rilevabili. La | | | distinzione con il precedente | | | livello è data dall'uso di | | | **misure quantitative**. | +-----------------------------------+-----------------------------------+ | 5 | Gli **obiettivi di efficacia e di | | | efficienza sono sempre definiti** | | **Migliorato continuamente** | sulla base di **obiettivi di | | | business**. Il **miglioramento** | | *Ottimizzato* | verso questi obiettivi è eseguito | | | in base **all'analisi delle | | | misure quantitative** raccolte, | | | le quali fanno capire le | | | **contro** **azioni** necessarie | | | per superare eventuali | | | **carenze**. La differenza con il | | | precedente livello è il | | | **continuo affinamento dei | | | processi** nei confronti degli | | | obiettivi. | +-----------------------------------+-----------------------------------+ Il raggiungimento di un **livello di capacità** è determinato dal **grado di presenza** (**achievement**) nel processo di 9 **attributi** suddivisi sui 5 livelli. Ognuno di questi attributi è **misurabile** (**rating**) attraverso una **scala** di valori definita (4 valori): N -- not achieved; P -- partially; L -- largely; F -- fully. \# Livello Attributo di processo Significato ---- ------------- --------------------------------- --------------------------------------------------------------------- 0 Incompleto 1 Eseguito PA 1.1 Esecuzione del processo Eseguito (anche se in maniera informale); produce risultati attesi. 2 Gestito PA 2.1 Gestione dell'esecuzione Esecuzione pianificata e gestita per produrre risultati previsti. PA 2.2 Gestione dei risultati Risultati documentati e gestiti. 3 Stabilito PA 3.1 Definizione del processo Esiste ed è mantenuta una definizione standard del processo. PA 3.2 Utilizzo del processo Eseguito sulla base di una personalizzazione del processo standard. 4 Prevedibile PA 4.1 Misurazione del processo La performance del processo è misurata. PA 4.2 Controllo del processo Processo controllato quantitativamente attraverso le misure. 5 Ottimizzato PA 5.1 Innovazione del processo Cambiamenti effettuati in modo controllato. PA 5.2 Miglioramento continuo Processo soggetto a miglioramento continuo. #### Assessment ISO IEC 15504 fornisce linee guida per eseguire il processo di **valutazione** (**assessment**) e lo segue in tutti i suoi passi (**avvio** -ad opera dello **sponsor**-, **selezione** del **valutatore**/gruppo di valutazione, **pianificazione**, **raccolta** e **convalida** dei **dati**, **rating** e **reporting**). Il **valutatore** raccoglie i dati relativi a un processo attraverso **interviste** con il personale coinvolto, **raccolta** di **documenti** e dati di qualità, raccolta di **dati statistici**. Il valutatore **convalida** i dati per assicurarsi che siano **accurati** e coprano completamente l'ambito della valutazione, per poi valutarli rispetto alle **politiche** di base di un processo e alle pratiche generiche della capacità. È importante che **siano verificate qualifiche e competenze del valutatore**. Il **process rating** è presentato sotto forma di risultati in forma preliminare **allo sponsor per verificarne l'accuratezza**. Può essere necessario attivare **cicli** di feedback per **ulteriori valutazioni** prima che si raggiunga la valutazione finale del processo. ### CMM -- Capability Maturity Model #### Principi base Secondo il **SEI** (**Software Engineering Institute**) il primo passo per assestare e **migliorare il processo** è la sua **valutazione**. Sono previste tre classi di valutazione dei processi: - **Software Process Capability**: metodo per **predire** il più probabile **risultato** **atteso** nei progetti futuri; - **Software Process Performance**: rappresenta il **risultato** **raggiunto** eseguendo un processo software; - **Software Process Maturity**: esprime quanto un **processo** sia esplicitamente **definito**, **gestito**, **misurato**, **controllato** ed **efficace**. Perché usare il CMM? Tre motivi: - **Riesame** della propria **organizzazione** per identificare punti di **forza** e di **debolezza**; - **Valutazione** **organizzazioni** **esterne** per stimare i **rischi** nella selezione di un **fornitore**; - **Guida** per il **miglioramento** **del** **processo** attraverso le analisi delle misure e l'individuazione dei punti da migliorare. #### Livelli di maturità Un **livello di maturità** è uno **stadio** evolutivo ben definito in un **cammino di maturazione** di un'**organizzazione** produttrice di software. Nel CMM sono previsti cinque livelli, ognuno fondamentale per il **miglioramento continuo**. La **capacità di un processo** indica i potenziali risultati attesi dall'esecuzione del **singolo processo**, sia ai fini dell'automiglioramento che della valutazione della capacità di un fornitore.  +-------------+-------------+-------------+-------------+-------------+ | #### Inizia | #### Ripeti | #### Defini | #### Gestit | #### Ottimi | | le (1) | bile (2) | to (3) | o (4) | zzato (5) | +=============+=============+=============+=============+=============+ | **Processo | Sono | Il processo | Vengono | **Miglioram | | non ben | eseguite le | è | raccolte | ento** | | definito**: | **attività | **conforme | **dettaglia | **continuo* | | il suo | di base per | agli | te | * | | successo | la gestione | standard** | misure dei | **dei | | dipende | dei | dell'organi | processi** | processi** | | solo | processi**. | zzazione | e dei | sfruttando | | dall'impegn | Il processo | e tutte le | **prodotti* | analisi | | o | è | attività | *, | post-mortem | | degli | **sufficien | sono | così che | dei | | sviluppator | temente | **documenta | entrambi | progetti | | i | disciplinat | te**. | siano ben | eseguiti e | | | o** | | **capiti**. | le | | | per essere | | | opportunità | | | ripetuto. | | | di | | | | | | tecnologie | | | | | | innovative. | +-------------+-------------+-------------+-------------+-------------+ **La classificazione dei singoli processi in livelli di capacità contribuisce alla collocazione dell'intera organizzazione nel suo livello di maturità.** #### Aree chiave di processo (Key Process Areas) Ogni area di processi chiave identifica un **insieme di attività** che, se eseguite **collettivamente**, assicurano la **crescita delle capacità dei processi**. In altre parole, le aree chiave di processo contengono tutte quelle attività che, se perseguite, consentono al processo di **salire a un livello più alto** di maturità. #### Fattori comuni Le aree chiave di processo sono organizzate in fattori comuni, ovvero **attributi** che assicurano che **l'esecuzione** e **l'istituzionalizzazione** di un processo chiave è **efficace**, **ripetibile** e **definitiva**. #### Pratiche chiave Descrivono le **infrastrutture** e le **attività** che contribuiscono **all'efficace** **implementazione** del **processo**. ### 1993: CMM → 2000: CMM-I Il Capability Maturity Model (CMM) è stato introdotto nel 1993 dal SEI (Software Engineering Institute) ed era limitato alle discipline di software engineering, utilizzando un modello a livelli di maturità (Staged Representation). Tra il 1993 e il 2000, sono stati sviluppati **diversi modelli CMM per varie discipline** (sistemi, sicurezza, personale, ecc). Nel 2000, il SEI ha **integrato questi modelli** creando il **Capability Maturity Model Integration** (**CMMI**), un **framework** per il **miglioramento dei processi** utilizzato in vari settori e richiesto in contratti governativi, soprattutto negli USA. CMMI si divide in tre aree principali: - **CMMI-DEV** (development): fornisce linee guida per la **gestione**, **misurazione** e **monitoraggio** dei **processi di** **sviluppo**; - **CMMI-SVC** (services): aiuta a gestire e **fornire** **servizi** sia all\'interno delle organizzazioni che verso i **clienti esterni**; - **CMMI-ACQ** (acquisition): fornisce supporto **nell'acquisizione di prodotti e servizi**. Vi sono 16 aree chiave di processo in tutti i modelli di CMMI. CMMI è il successore del CMM, che è stato sviluppato tra il 1987 e il 1997. Le sue versioni principali sono state: CMMI v1.1 (2002), CMMI v1.2 (2006) e CMMI v1.3 (2010). Secondo il SEI, CMMI aiuta le organizzazioni a integrare funzioni aziendali, stabilire priorità di miglioramento, garantire processi di qualità e fornire riferimenti per la valutazione dei processi. #### Appraisal (valutazione) Un\'organizzazione non può essere \"certificata\" in **CMMI** perché il CMMI (Capability Maturity Model Integration) **non è un sistema di certificazione** come, ad esempio, ISO 9001. Un'organizzazione può essere invece **valutata** e ottenere un **livello di maturità** (1-5) o un profilo di conseguimento del livello di capacità. Le valutazioni vengono generalmente condotte per determinare in che misura i processi dell'organizzazione **soddisfano le best practice CMMI** e identificare le aree in cui è possibile **migliorare**. Le valutazioni sono utili anche a **informare clienti e fornitori** del modo in cui i processi dell'organizzazione soddisfano tali best practice. Alcune organizzazioni trovano valore nel condurre una valutazione anche solo per **soddisfare i requisiti contrattuali** dei clienti. Il **metodo** per condurre le **valutazioni CMMI** si chiama "**Standard CMMI Appraisal Method for Process Improvement** (**SCAMPI**)". I risultati di una valutazione SCAMPI possono essere pubblicati sul sito web CMMI del SEI. **SCAMPI supporta la condotta di ISO IEC 15504 (SPICE)**. ### Rappresentare i dati (CMMI e SPICE) Nel 2000 viene introdotta la **Continuous Representation** (**ispirandosi alla ISO 15504-SPICE**). Insieme alla **Staged Representation**, costituisce un modo per rappresentare i livelli di **capacità** (continuous) o **maturità** (staged) con evidenza delle sedici aree chiave di processo (**KPA**).  #### Staged Representation Si basa sui **livelli di maturità** per misurare il miglioramento dei processi. I livelli fanno riferimento alla **maturità complessiva dell'organizzazione**. Il miglioramento è dettato dagli **insiemi** predefiniti di **aree** **di processo** (KPA). #### Continuous Representation Usa i **livelli di capacità** per misurare il miglioramento dei **processi**. I livelli di capacità si applicano al raggiungimento del miglioramento dei processi **per ciascuna area del processo** (KPA). I miglioramenti sono definiti dalla **singola area di processo**. ### CMMI vs SPICE #### Ownership - **CMMI** è **proprietario** -- Software Engineering Institute (SEI); - **SPICE** è uno **standard** **internazionale** -- ISO IEC 15504. #### Dominio di applicazione dei modelli di processo - **CMMI** è un sistema **chiuso** che si sviluppa in tre modelli (DEV, SVC, ACQ); - **SPICE** (ISO IEC 15504) è "**aperto**": definisce **regole** per **costruire modelli di processo per qualsiasi disciplina**. Chiunque può costruire modelli di processo per le valutazioni SPICE, e alcuni di questi sono stati sviluppati da ISO / IEC. #### Staged & Continuous Representation - CMMI e SPICE le coprono **entrambe**; - I **livelli di maturità** possono essere **derivati** da profili di **capacità** di **entrambi** i modelli; - Nell'ultima versione CMMI 1.3 i livelli di capacità sono tre (precedentemente cinque); - **CMMI** ha un **livello di maturità vuoto** (livello 1) mentre SPICE include due processi base già dal primo livello.