1 / 28

Groupe de discussion CMM(I)

Groupe de discussion CMM(I). 20 Octobre 2005. Du SW-CMM au CMMI. CETIC – 20 Octobre 2005. Contexte du SW-CMM. Développé par le Software Engineering Institute de la Carnegie Mellon University (1987 – 1993) http://www.sei.cmu.edu Motivation:

oleg
Download Presentation

Groupe de discussion CMM(I)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Groupe de discussion CMM(I) 20 Octobre 2005

  2. Du SW-CMM au CMMI CETIC – 20 Octobre 2005

  3. Contexte du SW-CMM • Développé par le Software Engineering Institute de la Carnegie Mellon University (1987 – 1993) • http://www.sei.cmu.edu • Motivation: • Département de la défense US (DoD) sous traite certains développements de logiciels critiques. Ils veulent un outil pour évaluer la capacité (capability) des sous-traitants intéressés. • Basé sur: • Travaux de Watts Humphrey sur le processus logiciel • Données collectées via des assessments + feedback des industries et des administrations US

  4. Les niveaux de maturité Optimizing Optimizing Focus on continuous process improvement 5 Quantitatively Managed – Managed Process measuredand controlled 4 Defined Defined Process characterized for the organization and is proactive 3 Managed – Repeatable Process characterized for projects and is often reactive 2 Initial Process unpredictable, poorly controlled, and reactive 1

  5. Niveau 5 Temps/$/Qualité/... Productivité & Qualité Performance prévue Niveau Focus Le processus est modifié pour atteindre des objectifs de performance, tout en maintenant une maîtrise statistique du processus. Temps/$/Qualité/... Le processes est géré de manière quantitative (vs. qualitative) et prédictible. Optimizing (Optimisé) Le processus d’un projet est une version adaptée du processus standard de l’organisation. Temps/$/Qualité/... Quantitatively Managed (Maîtrisé) Gestion des spécifications, processus du projet planifiés, exécutés, mesurés, et contrôlés même en période de stress. Risque Defined (Défini) Temps/$/Qualité/... Managed (Géré) Temps/$/Qualité/... Evolution de la performance 1 Tendance à sous-estimer, abandon des processus en temps de crise, et incapable de reproduire des succès passés. Initial Niveau 1

  6. Structure du SW-CMM Maturity Levels Maturity Levels Process Area 1 Key Process Area 1 Process Area 2 Key Process Area 2 Process Area n Key Process Area n Goals Generic Goals Implementation Institutionalization Common Features Common Features Commitment Commitment Ability Ability Measurement Directing Verifying Verifying Activities Performed to Perform to Perform to Perform to Perform And Analysis Implementation Implementation Implementation Implementation Implementation Key Practices

  7. Optimizing Optimizing Quantitatively Managed – Managed Defined Defined Managed – Repeatable Initial Secteurs clés (KPA) - niveau 2 Requirement Management (RM) SW Project Planning (SPP) SW Project Tracking and Oversight (SPTO) SW Quality Assurance (SQA) SW Configuration Management (SCM) SW Subcontract Management (SSM) 5 4 2 11

  8. Assets – niveau 2 (exemples) • Procédures pour: • Faire des estimations (taille, complexité, effort, etc.) • Traiter les déviations en matière d’effort, taille, etc. • Choisir des sous-traitants • Les spécifications logicielles documentées, l’analyse d’impact des changements de spécifications • Des estimations (et ré-estimations) sur la taille, l’effort, la durée • Un plan de développement logiciel incluant des plans QA et CM • Une base de données des anomalies avec leur état et l’effort pour les corriger • Des rapports d’audit

  9. Optimizing Optimizing Quantitatively Managed – Managed Defined Defined Managed – Repeatable Initial Secteurs clés (KPA) - niveau 3 Organization Process Focus (OPF) Organization Process Definition (OPD) Integrated Software Management (ISM) Training Program (TP) Software Product Engineering (SPE) Intergroup Coordination (IC) Peer Reviews (PR)

  10. Du niveau 2 au niveau 3 Analyse Projets Organisation Processus P1 Best practices Processus P2 Processus de l’organisation Processus P3 Niveau 2 Niveau 3

  11. Assets – niveau 3 (exemples) • Un plan pour l’amélioration du processus logiciel (OPF), des plans d’actions après audits SPI • Des descriptions de cycle de développement (waterfall, spirale, etc.) (ISM) • Des règles pour l’adaptation du processus de l’organisation aux projets (ISM) • Des plans de gestion de risques (identification, plans de mitigation, solution) (ISM) • Des checklists pour les revues de pairs, des données sur les défauts trouvés, etc. (PR) • Des procédures de tests, des résultats, une analyse de leur efficience (SPE)

  12. Planning Customer Rqmts. Design Implement Test Formal Customer TOTAL Leaked Analysis ation Test Before Planning 2.03 0 0 0 0 0 0 0 2.03 0 Customer 0 1.8 1.4 0 4.06 0 16.15 0 23.41 21.61 Rqmts. 0 0 7.32 12.04 32.77 41.6 56.09 0.79 150.61 143.29 Analysis Design 0 0 0.13 41.99 8.2 23.2 118.94 5.28 197.74 155.75 Implement 0 0 0.17 0.5 154 90.3 88.88 23.3 357.15 203.15 ation Test 0 0 0 0.16 0.03 19.92 4.5 0 24.61 4.69 Formal 0 0 0 0 0 2.34 149.25 0 151.59 2.34 Test Customer 0 0 0 0 0 0 2.7 13.6 16.3 13.6 Before TOTAL 2.03 1.8 9.02 54.69 199.06 177.36 436.51 42.97 923.44 544.43 Du niveau 3 aux niveaux 4 et 5 Organisation Processus de l’organisation Niveau 3 Hors limites Business Goals Qualité Manpower Outils Composants Niveau 5 Niveau 4

  13. Optimizing Quantitatively Managed Defined Managed Evolution de la gestion de projets Niveau Secteur clé Caractéristiques Accent mis sur la prévention de défauts et la collecte d’expériences Process Change Management Indicateurs avancés basés sur une connaissance quantitative du processus Quantitative Project Management Meilleure anticipation des problèmes (gestion des risques – indicateurs) Integrated Software Management Gestion de projet réactive aux événements Software Software Project Project Planning Tracking and Oversight 1 Initial Software Project Management Done

  14. Origine du CMMI EIA Interim Standard 731, System Engineering Capability Model (SECM) Capability Maturity Model for Software V2, draft C (SW-CMM V2C) SE Industry SW ... CMMI Product Suite SEI IPD Government Assess Training CMMI- SE/SW CMMI- SE/SW/ IPPD Integrated Product Development Capability Maturity Model, draft V0.98 (IPD-CMM) • Team of Teams • Modeling and Discipline Experts • Collaborative Process SA CMMI-SE/SW/IPPD/SS Software Acquisition Capability Maturity Model (SA-CMM)

  15. Les représentations du CMMI Par niveaux Continu ML5 ML4 Capacité 0 1 2 3 4 5 ML3 ML2 ML 1 PA PA PA Organisation Processus

  16. Comparaison SW-CMM vs. CMMI (par niveaux) SW-CMM key process areasCMMI Process Areas Causal Analysis and Resolution Organizational Innovation and Deployment Organizational Process Performance Quantitative Project Management Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Requirements Development Technical Solution Product Integration Verification Validation Decision Analysis and Resolution Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Product & Process Quality Assurance Configuration Management Measurement and Analysis Defect Prevention Technology Change Management Process Change Management Quantitative Process Management Software Quality Management Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews Requirements Mgmt Software Project Planning Software Project Tracking & Oversight Software Subcontractor Management Software Quality Assurance Software Configuration Management Level 5 Optimizing Level 4 Managed Level 3 Defined Level 2 Repeatable

  17. Structure du CMMI – Par niveaux The implemented activities in each PA Planning and managing the implemented activities in each PA

  18. Représentation continue du CMMI Planification, exécution et mesure des améliorations sur base des Process Areas Capacité Optimizing 5 Quantitatively Managed 4 Defined 3 Managed 2 Performed 1 PP RM PMC

  19. PA REQM – Capacité 1 vers Capacité 2 Level 2 Specific Practices (advanced) Managed Process Level 2 Generic Practices • GG 2 Institutionalize a Managed Process • GP 2.1 Establish an Organizational Policy • GP 2.2 Plan the Process • GP 2.3 Provide Resources • GP 2.4 Assign Responsibility • GP 2.5 Train People • GP 2.6 Manage Configurations • GP 2.7 Identify and Involve Relevant Stakeholders • GP 2.8 Monitor and Control the Process • GP 2.9 Objectively Evaluate Adherence • GP 2.10 Review Status with Higher Level Management Capability SP 1.2 Obtain Commitment to Requirements SP 1.4 Maintain Bidirectional Traceability of Requirements Level 1 Specific Practices (base) Performed Process Level 1 Generic Practices GP 1.1 Perform Base Practices SG Manage Requirements - SP 1.1 Obtain an Understanding of Requirements - SP 1.3 Manage Requirements Changes - SP 1.5 Identify Inconsistencies between Project Work and Requirements

  20. PA REQM – Capacité 2 vers Capacité 3 Level 3 Specific Practices (advanced) Defined Process Level 3 Generic Practices Capability • GG 3 Institutionalize a Defined Process • GP 3.1 Establish a Defined Process • GP 3.2 Collect Improvement Information Level 2 Specific Practices (base + advanced) Managed Process Level 2 Generic Practices • All Generic practices (Capability Level 1 and 2): • GP 1.1 (Perform Base Practices) • GP 2.1 to GP 2.10 (Institutionalize a Managed Process) SG Manage Requirements - SP 1.1 Obtain an Understanding of Requirements - SP 1.2 Obtain Commitment to Requirements - SP 1.3 Manage Requirements Changes - SP 1.4 Maintain Bidirectional Traceability of Requirements - SP 1.5 Identify Inconsistencies between Project Work and Requirements

  21. Structure du CMMI - Continue Process Area 1 Process Area 1 Process Area 2 Process Area 2 Process Area n Process Area n Specific Goals Specific Goals Generic Goals Generic Goals Capability Levels Specific Practices Generic Practices Generic Practices

  22. Optimizing Quantitatively Managed Defined Managed Bilan comparatif SW-CMM vs. CMMI Niveau SW-CMM SE/SW-CMMI 3 Key Process Areas 56 pratiques 2 Process Areas 36 pratiques 2 Key Process Areas 31 pratiques 2 Process Areas 37 pratiques 7 Key Process Areas 108 pratiques 11 Process Areas 214 pratiques 6 Key Process Areas 121 pratiques 7 Process Areas 125 pratiques 22 Process Areas 412 pratiques 18 Key Process Areas 316 pratiques Total

  23. Plus d’informations • SEI Website • http://sei.cmu.edu/cmmi • Introduction au SW-CMM: • A Guide to the CMM: Understanding the Capability Maturity Model for Software par Kenneth M. Dymond (ISBN # 0-9646008-0-3) • The SEI Series in Software Engineering – Addison Wesley: • CMM in Practice: Processes for Executing Software Projects at Infosys par Pankaj Jalote • CMMI Distilled: A Practical Introduction to Integrated Process Improvement par Dennis M. Ahern, Aaron Clouse, et Richard Turner

  24. Backup slides

  25. Modèles CMMI existants • SE/SW Staged • SE/SW Continuous • SE/SW/IPPD Staged • SE/SW/IPPD Continuous • SE/SW/IPPD/SS Staged • SE/SW/IPPD/SS Continuous • SW Staged • SW Continuous

  26. Choix d’un modèle CMMI • Une société développe des systèmes en se procurant du Hardware COTS, en développant un Software spécifique avec des équipes intégrées • CMMI-SW applicable uniquement au développement Software • CMMI-SE/SW applicable au système Hardware + Software • CMMI-SE/SW/IPPD applicable au système (HW + SW) et à l’équipe intégrée • CMMI-SE/SW/IPPD/SS applicable au système (HW + SW), à l’équipe intégrée, et à l’acquisition de COTS

  27. Pratiques • Les pratiques sont les briques des Process Areas • Exemple - Project Planning Process Area • Specific Practice 1.1 - Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. • Pour satisfaire aux objectifs, les pratiques décrites dans le CMMI sont attendues par les appraisers et la plupart des organisations les implémentent comme telles • Néanmoins, on peut appliquer des pratiques équivalentes si elles ont un effet équivalent pour la satisfaction de l’objectif (générique ou spécifique) • Ce sont les pratiques alternatives (“alternative practices”) • Moins fréquentes dans le CMMI que dans le SW-CMM • “Equivalent” est un jugement/appréciation personnel – à discuter avec l’appraiser

  28. Organisation des PA - Continu CatégorieProcess Areas Project Management Support Engineering Process Management Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management Risk Management Quantitative Project Management Configuration Management Product & Process Quality Assurance Measurement and Analysis Causal Analysis and Resolution Decision Analysis and Resolution Requirements Management Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment

More Related