CMMI Version 1.2
0 likes507 views
This document provides an overview of the Capability Maturity Model Integration (CMMI) Version 1.2. It discusses the history and development of CMM models, the reasons for integrating them into CMMI, and the key components and concepts of CMMI including constellations, maturity levels, process areas, and continuous improvement. CMMI Version 1.2 focuses on systems engineering and software engineering and covers five levels of process maturity from initial/ad hoc processes to optimized, continuously improving processes.
CMMI Version 1.2
- 1. CMMI: Version 1.2 Basics A presentation by QAI INDIA | USA | UK © QAI India Limited. All rights|reserved. | CHINA | MALAYSIA SINGAPORE
- 2. CMMI Version 1.2 Basics
- 3. History of CMMs • CMM v1.0 (Software) was the first to be developed • Others were developed subsequently: – SE CMM (Systems Engineering) CMM – Integrated Product Development CMM – SA (Software Acquisition) CMM – People CMM 3
- 4. Why Integrate? • Adaptability to enterprise needs – designed for evolution to meet current and future enterprise-wide process improvement needs – can add new process areas, generic improvement approach still applies 4
- 5. CMMI - SE/ SW • Systems Engineering – Covers the development of total systems, which may or may not include software – Focus on transforming customer needs, expectations, and constraints into product solutions and supporting those product solutions throughout the product life cycle • Software Engineering – Covers the development of software systems – Focus on applying systematic, disciplined, and quantifiable approaches to the development, operation and maintenance of software • CMMI - SE/SW covers both 5
- 6. Why Use CMMI SE/SW? • Increased dependency between systems engineering and software engineering • Low maturity of the interfaces between systems engineering and software engineering 6
- 7. What’s New in CMMI Ver 1.2 7
- 8. CMMI® Framework • Constellation: Collection of CMMI® components that includes the model, its training materials and appraisal-related documents for an area of interest. CMMI models for development, services and acquisition • Model for development provides amplifications for the systems engineering, software engineering, and hardware engineering disciplines • “Additions” used to expand constellations for specific additional content - CMMI® Dev has one such addition (CMMI® - Dev + IPPD) (In V1.1, IPPD was a discipline.) • Based on the initial efforts to maximize commonality among CMMI models, 16 of the 22 process areas of CMMI-DEV comprise the process improvement core for the three areas of interest currently being pursued: development, acquisition, and services. 8
- 9. Concept of Constellations • Latest version of CMMI i.e. CMMI ver 1.2 for Development was launched in Aug’06 • Constellation: Collection of CMMI® components that includes the model, its training materials and appraisal-related documents for an area of interest • Other constellations in making – Acquisition – Services 9
- 10. Concept of Maturity • Software Process Maturity – Extent to which a specific process is explicitly defined, managed, measured, controlled and effective – Implies a potential growth in capability and indicates both the richness of an organization’s software process and the consistency with which it is applied in projects throughout the organization • Maturity Level – A well defined evolutionary plateau toward achieving a mature software process – Each level provides a layer in the foundation for continuous process improvement 10
- 11. Staged Approach • Proven sequence of typical areas to focus on for improvement • Permits comparison across organizations - assessment results can be summarized into a single rating • Easy migration from SW-CMM SM 11
- 12. The Five Levels of Process Maturity Continuous Improvement Optimizing Institutionalize Process Improvement (5) d Quantitatively Process measured Quantitative Managed and controlled Management (4) Process characterized Process Defined for the organization Standardization (3) and is proactive Managed Process characterized for Basic Project projects and is often Management (2) reactive Process unpredictable, Initial poorly controlled and (1) reactive © Software Engineering Institute 12
- 13. Level 1 Process Areas There are no Process Areas at Level 1 13
- 14. The Initial Level (1) • Environment not stable for developing and maintaining systems • Inadequate management and engineering practices • Ineffective planning • Reaction-driven commitment systems • Emphasis on development and testing during crisis • Success depends on having exceptional people • Unpredictable process capability • Unpredictable schedules, budgets, functionality, and quality • Few stable processes 14
- 15. Level 2 Process Areas • Focus is on enabling institutionalizing Project Management Practices Instilling basic discipline into project management Requirements Management practices. Project Planning Each project may follow Project Monitoring and Control their own Supplier Agreement Management set of processes. Measurement and Analysis Process and Product Quality Assurance Configuration Management 15
- 16. The Managed Level (2) • Policies for managing projects • Planning and managing based on experience • Allows repeatability of successful practices • Specific processes implemented by the projects may differ • Realistic project commitments • Costs, schedules and functionality tracked • Requirements and work products are baselined • Standards defined and conformed to • Strong customer-supplier relationship with subcontractors • A measurement process is in place 16
- 17. Level 3 Process Area • Focus is on developing technical/ engineering practices integrating it with management practices and institutionalizing it. Developing Requirements Development engineering practices, integrating Technical Solution them with management Product Integration practices and Verification standardizing Validation processes across Organizational Process Focus the organization Organizational Process Definition + IPPD Organizational Training Integrated Project Management + IPPD Risk Management Decision Analysis and Resolution 17
- 18. The Defined Level (3) • Organization-wide standard processes • Effective engineering practices • Integration of engineering and management processes • Reuse of organizational learning • Process Engineering Group (PEG) • Organization-wide training program • Project’s “Defined Process” • Good management insight into the technical progress on all projects 18
- 19. Level 4 Process Area • Focus is on quantitatively managing project and organization wide performance Quantitatively manage organizational processes Organizational Process Performance Quantitative Project Management 19
- 20. The Quantitatively Managed Level (4) • Quantitative goals for projects and processes • Variation in process performance narrowed • Meaningful variations can be distinguished from random variation • Products are of high quality • Projects are controlled quantitatively 20
- 21. Level 5 Process Area • Focus is on continuously improving project and organizational capability Continuously improve project and organizational Organizational Innovation and capability Deployment through innovations & Causal Analysis and Resolution do root cause analysis for common causes 21
- 22. The Optimizing Level (5) • Organization focused on process improvement – incremental advances in existing processes – innovations using new technologies and methods • Proactive identification of weaknesses to strengthen processes • Goal of preventing occurrence of defects through error-cause removal • Cost-Benefit analyses of introducing new technologies and proposed process changes 22
- 23. Skipping Maturity Levels • Counter-productive • Each level builds a foundation for succeeding levels • Required leverage for implementing processes effectively and efficiently • However, processes described at a higher maturity level can be used 23
- 24. Continuous Model • Allows you to select the order of improvement that best meets your organization’s business objectives • Enables comparisons across and among organizations on a process- area-by-process-area basis • Provides an easy migration from models with a continuous representation to CMMI • Uses predefined sets of process areas to define an improvement path for an organization 24
- 25. Structure of PA No common features 25
- 26. http://www.qaiglobal.com INDIA USA UK CHINA MALAYSIA SINGAPORE Click here for more on Software Process Improvement CONTACT US QAI India: QAI USA: QAI Malaysia: 1010 - 1012, Ansal Towers, 38 Nehru Windsor at Metro Center, 2101 Park Level 36, Menara Citibank, 165, Jalan Place Center Dr., Suite 200, Orlando, FL Ampang, 50450 Kuala Lumpur, New Delhi - 110019, India 32835-7614 Malaysia Phone: +91- 11- 26219792, 26220580 Phone: +407-363-1111 Phone: +603 2169 6241 conferences@qaiglobal.com conferences@qaiglobal.com conferences@qaiglobal.com QAI UNICOM / UK: QAI Singapore: QAI China: Unicom R&D House, One Oxford 391B Orchard Road #23-01, Rm. 1211, No. 498 Guoshoujing Rd. Road Ngee Ann City Tower B, Shanghai Uxbridge, Middlesex, London, United Singapore - 238874 Zhangjiang Hi-Tech Park, Pudong New Kingdom, Zip: UB9 4DA Phone:+65-6225-8139 Area, Phone : +44 (0)1895 256484 conferences@qaiglobal.com Shanghai, China Zip: 201203 conferences@qaiglobal.com Phone : +86-21-51314155 conferences@qaiglobal.com www.qaiglobal.c © QAI India Limited. All rights QAI © reserved. All rights reserved. No part of this document may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without prior written permission of QAI