Il Capability Maturity Model CMM. Il Capability Maturity Model. Il concetto di maturità (2) Il concetto di capability. Rapporti tra i livelli

Transcript

1 Il Capability Maturity Model Il Capability Maturity Model CMM Il SW-CMM (SW - Capability Maturity Model) definisce un modello dei processi di sviluppo del software e un insieme di regole per il loro miglioramento. Links E stato sviluppato nel 1993 dal SEI, Software Engineering Institute della Carnegie Mellon University, Pittsburgh, USA, per conto del DOD (Dept. Of Defense, USA). G.Raiss - 11 maggio G.Raiss - 11 maggio Il concetto di capability Il modello CMM permette di valutare le organizzazioni che operano nel settore IT in funzione del loro livello di maturità e della capability dei processi che attuano. Per capability si intende, in termini di produzione industriale, la qualità attesa dei risultati di un processo. Dipende, sostanzialmente, dal livello di definizione, gestibilità, misurabilità, controllabilità ed effettiva implementazione raggiunto da uno specifico processo. Il concetto di maturità (2) La maturità di una organizzazione è la capacità di fornire prodotti di qualità attraverso la capacità dei processi che attua. In una organizzazione è quindi la capacità di controllare/prevedere/garantire la qualità dei prodotti in uscita dai processi. In funzione di questa capacità le organizzazioni possono essere posizionate su una scala ordinale da 0 a 5. G.Raiss - 11 maggio G.Raiss - 11 maggio Rapporti tra i livelli La differenza tra i. diversi livelli non è confrontabile. Si può solo dire che il livello 5 è maggiore del livello 4 ed il 4 del 3 e così via... La scala evidenzia il proposito del CMM di essere un supporto per la evoluzione delle organizzazioni. Per fare un confronto, la ISO 9001 definisce uno stadio cui tendere, senza indicare il percorso. Il CMM definisce i passi del percorso che di miglioramento. Lo schema base del CMM Molto schematicamente,. si può dire che il CMM si basa su uno schema che vale per ogni livello. Input Passi Obiettivi Pe ogni livello cambiano input/output e passi da eseguire. G.Raiss - 11 maggio G.Raiss - 11 maggio

2 Utilizzo del modello Il modello CMM può essere utilizzato per: riesame di una organizzazione per identificarne i punti di forza e di debolezza valutazione di organizzazioni esterne al fine di selezionare un fornitore di beni e servizi guida al miglioramento dei processi di una organizzazione, attraverso l analisi delle misure di processo rilevate La scala di maturità Il CMM utilizza una scala ordinale a 5 livelli per valutare le organizzazioni. I livelli di maturità vanno dallo stato caotico e destrutturato (livello 1) ad uno disciplinato ed in grado di misurarsi per migliorare (livello 5). G.Raiss - 11 maggio G.Raiss - 11 maggio La struttura del modello contiene Key process areas Common Features Key practices Indica Raggiunge Indirizza Descrive Process capability GOALS consolidamento consolidamento Process capabilities & Key process areas Per ogni livello di maturità, sono definite le process capabilities ovvero un insieme di risultati attesi dalla messa in atto dei processi di sviluppo software a quel determinato livello di maturità. Con l eccezione del livello 1, ogni livello ha associate alcune KEY Process Areas che rappresentano i processi cruciali che una organizzazione deve implementare correttamente per poter raggiungere i risultati attesi per quel livello. G.Raiss - 11 maggio G.Raiss - 11 maggio Le Key Process Areas Le KPAs sono da considerare un cluster di attività correlate che, quando svolte collettivamente, permettono il raggiungimento di obiettivi considerati importanti ai fini della dimostrazione del miglioramento dei processi. Le KPAs sono 18 (nella vers. 1.1 del CMM) e sono proprie dei vari livelli di maturità. Il livello 1 non ne ha. Il livello 5 deve possederle tutte e 18. Il CMM non descrive tutti i processi coinvolti nello sviluppo del sw, ma solo quelli che considera chiave. Key Process Areas e Goals Rispetto ad ogni KPA sono identificati dei goals ovvero degli obiettivi da raggiungere per poter considerare soddisfatta l implementazione corretta della KPA. Ad esempio, un goal per la KPA Software Process Planning (appartenente al Livello 2) è le stime della dimensione del software e dell impegno nello sviluppo sono documentate ed utilizzate per pianificare il progetto e tracciarne l andamento. G.Raiss - 11 maggio G.Raiss - 11 maggio

3 I livelli - i contenuti - Livelli 1 & 2 I livelli - i contenuti - Livello 1 LIVELLO 1 - INITIAL Il SW prodotto è caratterizzato dall'essere costruito "ad hoc", seguendo strategie occasionali e caotiche Solo alcuni processi produttivi sono ben definiti ed i successi dipendono solo da sforzi individuali Solo alcuni processi produttivi sono stabili LIV. 2 - REPETEABLE I processi di gestione (project management) dei progetti più importanti sono definiti in modo da: Permettere la loro pianificazione Tenere traccia dei costi (tempo e denaro) L'obiettivo principale è poter riprodurre le stesse condizioni che hanno portato al successo in applicazioni precedenti Livello 1 - Iniziale Il Il processo software è definito di di volta in in volta e occasionalmente risulta caotico. Pochi processi sono definiti e il il successo dipende dalle capacità individuali dei professionisti G.Raiss - 11 maggio G.Raiss - 11 maggio I livelli - i contenuti - Livello 2 Livello 2 - Ripetibile I I processi base di di project management sono definiti per tracciare tempi, costi e funzionalità. La disciplina di di processo ha lo lo scopo di di ripetere il il successo di di precedenti progetti per applicazioni similari Livello 2 - Key Process Areas LIVELLO 2 - REPETEABLE Key process areas: GESTIONE DEI REQUISITI (RM) PIANIFICAZIONE DEI PROGETTI SW (PP) TRACCIABILITA E VISIBILITA DEI PROGETTI (PT) GESTIONE DEI SUBAPPALTI (SM) ASSICURAZIONE DELLA QUALITA DEL SW (QA) GESTIONE DELLA CONFIGURAZIONE DEL SW (CM) G.Raiss - 11 maggio G.Raiss - 11 maggio Livello 2 - Key Process Areas & Goals I livelli - i contenuti - Livello 3 LIVELLO 2 - REPETEABLE KPA - GESTIONE DEI REQUISITI (RM) Goal 1: I requisiti del sistema che sono stati assegnati al software sono controllati per poter costituire una linea di base ad uso dell ingegnere e dell amministratore del software Goal 2: I piani, i prodotti e le attività devono essere consistenti con i requisiti del sistema assegnati al software Livello 3 - Definito Il Il processo software, sia per le le attività di di gestione che di di realizzazione, è documentato, standardizzato e integrato su scala aziendale. Tutti i i progetti utilizzano la la versione approvata e adattata del processo standard aziendale per lo lo sviluppo e la la manutenzione del software G.Raiss - 11 maggio G.Raiss - 11 maggio

4 Livello 3 - Key Process Areas I livelli - i contenuti - Livelli 4 & 5 LIVELLO 3 - DEFINED Key Process Areas: DEFINIZIONE E STANDARDIZZAZIONE DEI PROCESSI ORGANIZZATIVI (PF + PD) COORDINAZIONE INTERGRUPPO (IC) INGEGNERIZZAZIONE DEI PRODOTTI SW(PE) GESTIONE DELLE INTEGRAZIONI DEL SW (IM) CONFRONTI E VERIFICHE (PR) PROGRAMMI DI FORMAZIONE(TP) LIVELLO 4 - MANAGED Collezione di misure dettagliate sui processsi di produzione e sui prodotti KPAs: MISURE E ANALISI DI PROCESSO GESTIONE DELLA QUALITA LIVELLO 5 - OPTIMIZED Miglioramento continuo del processo tramite: feed-back quantitativi introduzione di tecnologie innovative KPAs: PREVENZIONE DEI DIFETTI INNOVAZIONI TECNOLOGICHE GESTIONE DEL PROCESSO DI CAMBIAMENTO G.Raiss - 11 maggio G.Raiss - 11 maggio I livelli - i contenuti - Livello 4 I livelli - i contenuti - Livello 5 Livello 4 - Gestito Sono raccolte misure dettagliate del processo software e della qualità del prodotto. Entrambi il il processo e il il prodotto sono quantitativamente valutati e controllati Livello 5 - Ottimizzato Il Il continuo miglioramento è assicurato dalla raccolta di di dati quantitativi e dall utilizzo di di idee e tecnologie innovative G.Raiss - 11 maggio G.Raiss - 11 maggio Le Key Process Areas - considerazioni (1) Le Key Process Areas - considerazioni (2) Le KPAs al liv. 2 focalizzano l attenzione sulla messa a punto degli strumenti base di controllo dei progetti: di questo gruppo fanno parte la Pianificazione, la Gestione dei Sub-appalti, la Quality Assurance e la Gestione della Configurazione. Al livello 3 le KPAs riguardano sia aspetti progettuali che organizzativi: tra gli aspetti affrontati sono la formazione, l ingegneria del sw, la definizione dei processi organizzativi, il coordinamento intersettoriale. Al liv. 4 il focus delle KPAs è nello stabilire una comprensione quantitativa sia dei processi che dei prodotti sw sviluppati. Al liv. 5 l obiettivo è il miglioramento continuo, attuato attraverso la prevenzione dei difetti, la gestione delle modifiche tecnologiche e di processo. G.Raiss - 11 maggio G.Raiss - 11 maggio

5 Le KPAs e le Common Features Ogni KPA ha associate 5 tipologie di attributi, chiamate common features, che devono permettere di valutare se la implementazione ed istituzionalizzazione della KPA è effettiva e stabilizzata, fino a far parte della cultura aziendale (istituzionalizzata). Le 5 tipologie di common features sono Activities performed che descrive le attività di implementazione, Commitment to perform, Ability to perform, Measurement and analysis, Verifying the implementation che ne descrivono la istituzionalizzazione Le Key Practices Ogni KPA è descritta anche in termini di Key pratices ovvero di infrastrutture ed attività che contribuiscono in modo rilevante alla implementazione ed istituzionalizzazione del processo. Per esempio, una delle Key practices per la KPA Software Process Planning è il piano di progetto è sviluppato in accordo con una procedura documentata. La Key Practice descrive quindi cosa deve essere fatto, ma non è vincolante sul come, consentendo anche diverse modalità di raggiungimento degli obiettivi ( goals ) della KPA. G.Raiss - 11 maggio G.Raiss - 11 maggio La struttura del modello (2) I fattori di promozione 5 liv. di maturità 18 KPAs 5 common features per KPA con 1-n Key practices ognuna KPAs per liv. di maturità KPA Key practices = 316 key practices = 52 goals 2-4 goals per KPA G.Raiss - 11 maggio Formazione Revisioni e test sistematici Standard Project management Controllo della configurazione Assicurazione di qualità Cambiamenti di tecnologia Prevenzione dei problemi Misure di processo Analisi di processo Piani di qualità quantitativi Iniziale Ripetibile Definito Gestito Ottimizzante Processo definito in modo istituzionale Dati qualitativi Attribuzione di responsabilità Riuso di esperienza pregressa Processo non controllato strumenti non integrati nel processo assenza di procedure formali Misure di costi, tempi, qualità G.Raiss - 11 maggio CMM vs ISO 9001 Formazione Revisioni e test sistematici Standard Project management Controllo della configurazione Assicurazione di qualità Cambiamenti di tecnologia Prevenzione dei problemi Misure di processo Analisi di processo Piani di qualità quantitativi Ripetibile Definito Gestito / Ottimizzante CMM vs ISO 9001 Non vi è corrispondenza 1:1 tra i processi coperti Il livello di dettaglio è diverso (maggiore nel CMM) CMM è interessato soprattutto al migliramento, la 9000 alla conformità ad un set minimo di requisiti Nella 9000 c è in più: 4.7 controllo dei prodotti forniti dal cliente 4.15 movimentazione, immagazzinamento, imballaggio, conservazione e consegna Iniziale G.Raiss - 11 maggio G.Raiss - 11 maggio

6 CMM vs ISO Dettaglio (1) CMM vs ISO Dettaglio (2) ISO Politica per la qualità definita documentata/mantenuta responsabilità ed autorità individuate risorse INTERNE individuate e addestrate manager designato CMM - QA: Software Quality Assurance livello 2 (Ripetibile) individua le responsabilità e le autorità CMM - QM: Software Quality Management livello 4(Gestito) simile ma quantitativo. ISO 9001 molto più vago ISO Sistema qualità documentato (Piano + Manuale) procedure e istruzioni integrato con l'intero processo produttivo (ISO ) CMM - QA: Software Quality Assurance livello 2 (Ripetibile) minore enfasi sulla documentazione CMM - PD: Organization Process Definition 3 (Definito) definisce gli standard le procedure e la descrizione del processo ISO Revisione del contratto Gestione dei cambiamenti dei requisiti utente CMM - RM: Requirement Management livello 2 (Ripetibile) pensato solo per i requisiti software CMM - PP: Software Project Planning livello 2 (Ripetibile) prevede, tra l altro, la revisione dei piani di progetto tenendo conto delle specifiche contrattuali ISO Controllo del progetto pianificazione delle attività di progetto identificazione input & outputs controllo modifiche al progetto CMM - PE: Software Product Engineering livello 3 (Definito) analisi requisiti-progetto-codificatest CMM - PP: Software Project Planning livello 2 (Ripetibile) pianificazione G.Raiss - 11 maggio G.Raiss - 11 maggio CMM vs ISO Dettaglio (3) ISO Controllo documentazione Standardizzazione distribuzione gestione CMM - CM: Software Configuration Management livello 2 (Ripetibile) coper anche la documentazione (tra i vari aspetti) ISO Approvvigionamento valutazione fornitori verifica prodotti CMM - SM: Software Subcontract Management livello 2 (Ripetibile) identico alla ISO 9000 CMM vs ISO 9001 Una organizzazione ISO 9001 compliant rispetta i requisiti del livello 1 CMM e parte di quelli dei livelli 2 e 3. G.Raiss - 11 maggio G.Raiss - 11 maggio CMM vs ISO Riepilogo CMM vs ISO (1) La ISO copre un insieme di processi più ampi rispetto al CMM. I requisiti non coperti dal CMM sono: System requirements, Design, Integration, Qualification testing, Database design, User documentation, Software installation, Maintenance process, Documentation standards, Project closure. Una organizzazione a livello 3 CMM dovrebbe comunque coprire tutti i requisiti G.Raiss - 11 maggio G.Raiss - 11 maggio

7 CMM vs ISO (2) CMM vs ISO (3) processes CMM KPAs Primari Acquisition Sw subcontractor management Supply Development Sw product engineering Operation Maintenance Supporto Documentation Sw product engineering Configuration management Sw configuration management Quality assurance Sw quality assurance Verification Sw product engineering Validation Sw product engineering Joint review Sw project tracking and oversight Audit Sw quality assurance Problem Resolution Sw configuration management G.Raiss - 11 maggio processes CMM KPAs Organizzativi Management Sw project planning, Sw project tracking and oversight, Integrated sw management, Sw Quality management Infrastructure Organization process definition Improvement Organization process, focus, Organization process definition Training Training program G.Raiss - 11 maggio I modelli CMM La suite dei modelli CMM CMMI SM CMM Integration SM SW-CMM Capability Maturity Model for Software P-CMM People Capability Maturity Model SA-CMM Software Acquisition Capability Maturity Model SE-CMM Systems Engineering Capability Maturity Model IPO-CMM Integrated Product Development Capability Maturity Model CMM Survey ed evoluzioni A gennaio 2001 il SEI ha notizia di 48 organizzazioni di livello 5. Il Software Engineering Institute (SEI) della Carnegie Mellon Univ. (USA) che ha sviluppato il CMM, ha partecipato al progetto SPICE ed ai TRIALS per la sperimentazione del modello ISO E probabile che a breve il modello CMM confluisca in quello G.Raiss - 11 maggio G.Raiss - 11 maggio Bootstrap Bootstrap Bootstrap è una metodologia per l assessment del processo di sviluppo software e per il suo miglioramento, sviluppata nel corso del progetto Esprit 5441 della Comunità Europea negli anni e poi gestita ed implementata dal Consorzio Bootstrap (Ente non-profit formato da organismi ed aziende europee) fondato nel G.Raiss - 11 maggio BOOTSTRAP comprende un modello di processi ed un metodo per l assessment basato su quel modello Il metodo è di proprietà del Bootstrap Institute fondato dai membri del Consorzio; attualmente è rilasciata la versione 3.0 (settembre 1997) Links G.Raiss - 11 maggio

8 Bootstrap La metodologia si basa sul processo di sviluppo definito dallo standard ESA PSS 05-0 (tradizionale, a cascata) ed integra quanto definito nel CMM 1.1, ISO/IEC 12207:1995, ISO :1997, ISO/IEC 15504:1998 G.Raiss - 11 maggio Bootstrap: architettura Il modello BOOSTRAP divide i processi del CVS in 2 rami, Organizzazione e Metodologia. Il Ramo Organizzazione contiene 3 processi, Business Engineering, Gestione risorse umane, Gestione infrastrutture. Il ramo metodologia è composto da 3 gruppi di processi 8Life Cycle dependent (composto da 11 processi) 8Life Cycle independent 8Process Related (2 processi) G.Raiss - 11 maggio Bootstrap: architettura Bootstrap: la scala di valutazione I processi dipendenti dal ciclo di vita sono ulteriormente organizzati in 8Manageriali (4 processi) 8di Supporto (8 processi) 8relativi alla interazione Customer-Supplier (5 processi). In totale il modello BOOTSTRAP definisce 33 diversi processi G.Raiss - 11 maggio L assessment utilizza i 6 livelli di maturità del CMM [0,5] come scala di misura. L influenza della Tecnologia è considerata in funzione della sua innovatività e del suo uso nel CVS e può essere alta o bassa. Esistono corsi di qualificazione per assessor che devono valutare il livello di maturità dei processi di una organizzazione rispetto al modello BOOTSTRAP. G.Raiss - 11 maggio Bootstrap: struttura Trillium Il modello Trillium è stato sviluppato nel 1994 dalla Bell - Canada. G.Raiss - 11 maggio G.Raiss - 11 maggio

9 Utilizzo dei modelli di processo I modelli di processo possono essere utilizzati: dal committente, per selezionare i fornitori (certificazione ISO 9001, TICKIT in UK) definire nei capitolati tecnici i requisiti di processo cui si deve attenere il fornitore (ISO 12207, 13407, CMM, Bootstrap, Trillium) nell attuazione dell appalto, per verificare la corretta attuazione dei processi messi in atto e la loro efficacia ed efficienza a servire il contratto (ISO , Boostrap, CMM) Utilizzo dei modelli di processo dal fornitore, per definire il proprio sistema di assicurazione e gestione della qualità (ISO 9001, , , EFQM, TQM) compilare le offerte tecniche (ISO 12207, 13407, CMM, Bootstrap) condurre assessment sui propri processi ai fini di mantenerli costantemente conformi alle esigenze dei clienti e per migliorarne efficacia ed efficienza (ISO , CMM, Boostrap) G.Raiss - 11 maggio G.Raiss - 11 maggio