CMMI-Dev V1.3. Capability Maturity Model Integration for Software Development, Version 1.3. Roma, 2012 Ercole Colonese

Transcript

1 CMMI-Dev V1.3 Capability Maturity Model Integration for Software Development, Version 1.3 Roma, 2012

2 Agenda Che cos è il CMMI Costellazione di modelli Approccio staged e continuous Aree di processo Goals and Practices, generic and specific Appraisal Possibile piano di implementazione Strumenti a supporto Formazione (Awareness) 2

3 Che cos è? CMMI (Capability Maturity Model Integration) è un modello per il miglioramento dei processi aziendali Nasce negli anni 70 negli USA (DoD) per valutare la qualità dei prodotti e servizi dei fornitori Si è esteso in tutto il mondo come standard qualitativo per il miglioramento dei processi Il modello è gestito dal Software Engineering Institute (SEI) che lo fa evolvere in base alle esigenze del mercato e delle tecnologie emergenti 3

4 Costellazioni La versione attuale del modello (v.1.3) consta di tre modelli distinti: CMMI for Development, CMMI-DEV, Version 1.3 November 2010 Improving processes for developing better products and services CMMI for Services, CMMI-SVC, Version 1.3 November 2010 Improving processes for providing better services CMMI for Acquisition, CMMI-ACQ, Version 1.3 November 2010 Improving processes for acquiring better products and services 4

5 Il problema dei progetti che falliscono Nel campo IT (ma non solo), il problema è affrontato con un approccio di miglioramento continuo delle prestazioni aziendali (Continuous Process Improvement, CPI). Il miglioramento di un processo è inteso a tutto tondo e coinvolge, in maniera sincrona e sinergica, l aspetto umano (l organizzazione intesa come cultura, atteggiamento, impegno, coinvolgimento, responsabilizzazione, motivazione ecc.), le tecnologie (tecnologie informatiche, metodi, tecniche, metriche, strumenti ecc.) e ovviamente i processi. Figura 1. Collegamento tra processo, competenza e tecnologia (fonte: SEI). 5

6 Il modello CMMI Il modello CMMI prevede un approccio «continuo» ed uno «a stadi» per la sua implementazione CL 5 CL 4 CL 3 CL 2 CL 1 CL 0 PP PMC «staged» model «continuous» model 6

7 Livelli di maturità Livello Descrizione 1. Iniziale Il processo di sviluppo software è caratterizzato da una scarsa strutturazione, spesso è assente, a volte è caotico. Solo pochi processi sono definiti ed il successo dipende dall impegno dei singoli, a volte eroico. 2.Ripetibile (Gestito) Sono stabili processi base di gestione dei progetti di sviluppo software per tracciare i costi, la schedulazione delle attività e le funzionalità sviluppate. Il processo è stabilito per essere ripetibile su progetti che sviluppano applicazioni simili. 3. Definito Il processo di sviluppo software, sia per la parte di gestione che per quella di sviluppo tecnico, è definito, documentato, standardizzato ed integrato in azienda per l intera organizzazione. Tutti i progetti utilizzano una versione 4.Gestito quantitativamente del processo approvata, standardizzata ed adattabile ai singoli progetti. Si effettuano misure sul processo di sviluppo software e sulla qualità dei prodotti sviluppati. Sia il processo di sviluppo che i prodotti sviluppati sono quantitativamente interpretati e controllati. 5. Ottimizzato Esiste un processo di miglioramento continuo basato su feed-back quantitativi provenienti dall utilizzo del processo e dalla sperimentazione di progetti pilota su innovazioni e nuove tecnologie. 7

8 Aree di processo (KPAs) Level Focus Area di processo 5 Optimizing Continuous Process Organizational Performance Management (OPM) Improvement Causal Analysis and Resolution (CAR) 4 Quantitatively Managed Quantitative Management Organizational Process Performance (OPP) Quantitative Project Management (QPM) 3 Defined Process Standardization Requirements Development (RD) 2 Managed Basic Project Management Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD) Organizational Training (OT) Integrated Project Management (IPM) Risk Management (RSKM) Decision Analysis and Resolution (DAR) Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Supplier Agreement Management (SAM) Measurement and Analysis (MA) Process and Product Quality Assurance (PPQA) Configuration Management (CM) 1 Initial None None 8

9 Miglioramento continuo La metodologia per il miglioramento continuo Pianificare (Plan) Mantenere e migliorare (Act) Realizzare (Do) Verificare (Check) IDEAL: Initiating-Diagnosing-Establishing-Acting-Learning (fonte: SEI) PDCA: Plan-Do-Check-Act (fonte: Deming) 9

10 Approccio semplificato (PDCA) Mantenere e migliorare (Act) 1. Obiettivo raggiunto: Standardizzare, consolidare e addestrare il personale; 2. Procedere ad un eventuale PDCA per un ulteriore miglioramento; 3. Ripetere un nuovo ciclo PDCA sullo stesso tema, analizzando criticamente le varie fasi del ciclo precedente per individuare le cause del non raggiungimento dell obiettivo. Pianificare (Plan) Pianificare (Plan) 1. Rendere consapevole il Management (Awareness) 2. Definire la strategia di miglioramento (politiche, obiettivi, azioni) 3. Pianificare il miglioramento (SPI Plan) 4. Costituire i gruppi di lavoro (MSG, SEPG, TWGs, Process Owners) 5. Formare i gruppi di lavoro (CMMI Training) Mantenere e migliorare (Act) Realizzare (Do) Verificare (Check) 1. Monitorare i processi (misurazioni) 2. Verificare i risultati e confrontarli con gli obiettivi 3. Valutare i risultati (Appraisal di classe A, B o C) 4. Obiettivo raggiunto: a. Passare al punto 1 della fase Act; 5. Obiettivo non raggiunto: a. Passare al punto 2 della fase Act. Verificare (Check) Realizzare (Do) 1. Strutturare il Ciclo di vita del software (CVS) 2. Istituzionalizzare le 7 aree di processo (KPAs) 3. Addestrare il personale coinvolto 4. Adottare i processi stabiliti nei progetti reali 10

11 La valutazione del livello di maturità SCAMPI: Standard CMMI Appraisal Method for Process Improvement Class A, B or C Lead Appraiser Two stages: Final Report: 1. Documentation review 2. Visit (on-site) Level appraised Strenghts and Weakeness SCAMPI Classes (fonte: SEI) 11

12 Goals and Practices (Generic) Generic Goal GG 1 Achieve Specific Goals GG 2 Institutionalize a Managed Process Generic Practice GP 1.1 Perform Specific Practices GP 2.1 Establish a Managed Process GP 2.2 Plan the Process GP 2.3 Provide Resources GP 2.4 Assign Responsibility GP 2.5 Train People GP 2.6 Control Work Products GP 2.7 Identify and Involve Relevant Stakeholders GP 2.8 Monitor and Control Process GP 2.9 Objectively Evaluate Adherence GG 3 Institutionalize a Defined Process GP 2.10 Review Status with Higher Level Management GP 3.1 Establish a Defined Process GP 3.2 Collect Process Related Experiences 12

13 Goals and Practices (Specific) Specific Goal SG 1 Determine Causes of Selected outcomes Generic Practice SP 1.1 Select Outcomes for Analsys SP 1.2 Analyze Causes SG 2 Address Causes of Selected Outcomes GP 2.1 Implement Action Proposals SP 2.2 Evaluate the Effect of Implemented Actions SP 2.3 Record Causal Analysis Data 13

14 Modello dei processi (Livello 2) Strategia: Politiche, Obiettivi, Azioni, Riesame Ciclo di vita del software (CVS) REQM PP PMC SAM PPQA CM MA Altri processi aziendali (SGQ) Strumenti a supporto (Tool) Miglioramento continuo dei processi (SPI Program) Flusso delle fasi del CVS Linee guida Feedback 14

15 Un possibile piano di implementazione Mese: Appraisal (classe C) Mgmt Training Pianificazione Modello staged Livello di maturità 2 (7 aree di processo) Organizzazione di medie dimensioni fortemente motivata SEPG & Training Ciclo di vita del software (CVS) Istituzionalizzazione delle 7 aree di processo (KPAs) Adozione di strumenti (tool) Misurazioni e analisi Organizzazione Appraisal Appraisal (classe A o B) Azioni Documentazione Visita 15

16 Elementi del sistema Politica Ciclo di vita del software (CVS) Documenti di progetto Obiettivi Azioni Piano di miglioramento Aree di processo (KPAs) Documenti di prodotto Riferimento a Risultati Processi e SGQ aziendali Misurazione dei processi Valutazione degli obiettivi raggiunti 16

17 Strumenti a supporto Politica Obiettivi Ciclo di vita del software (CVS) CVS Requisiti Richieste di modifica Azioni Processi (KPAs) Erogazione dei servizi Gestione configurazione Riesame della Direzione Reporting Measurement and Analysis Anomalie software Qualità del software Costo dei progetti Test Tempi di consegna DB Misure 17

18 Formazione Formazione del Management (Awareness) Si tratta di una mezza giornata (se necessario, 2 mezze giornate) in cui viene presentato il modello CMMI-Dev nella corrente versione La formazione tende ad aiutare il Management a comprendere i reali vantaggi del modello ma anche, e soprattutto, le difficoltà a implementarlo In particolare, serve a rendere noto al Management il proprio ruolo di promotore dell iniziativa (Sponsorship) e la responsabilità di verificarne lo stato di implementazione, l efficacia (misurazioni) e a mettere in atto le azioni opportune Formazione dei gruppi di lavoro (SEPG) L implementazione del modello richiede la costituzione di uno o più gruppi di lavoro (SEPG, Software Engineering Process Group) cui viene affidato il compito di realizzare i processi necessari, divulgarli all interno dell organizzazione e fornire il supporto tecnico alla loro adozione In particolare, si evidenzia la necessità di produrre e mantenere aggiornata la documentazione dei processi, adottare strumenti a supporto, implementare e utilizzare le metriche necessarie La formazione in questo caso è più tecnica e approfondita per i singoli processi (KPA) 18

19 Domande? 19

20 Grazie per l attenzione (+39) [email protected]