The CMM Integration Project

1. The CMM Integration Project Dr. Jack R. Ferguson Dr. Rick Hefner CMMI Project Manager Assessment Team Co-Lead

2. Objectives • Present the background and current status of the CMM Integration Project • Discuss structure and sample content of the new maturity models • Discuss timeline for public release of the models and pilot assessments • Discuss transition from the current maturity models and assessment methods

3. Agenda • Introduction Dr. Jack Ferguson (SEI) • Background • Design Approach • Comparison to SW-CMM v1.1 Dr. Rick Hefner (TRW) • Comparison to EIA IS 731 (SECM) • Assessment Methodology • Comment Process Dr. Jack Ferguson (SEI) • Transition Process • Discussion

4. BackgroundDr. Jack Ferguson Objectives • Review project objectives • Review key requirements and source material • Discuss CMMI project team • Compare and contrast current maturity models • CMM for Software, SECM, IPD-CMM • Staged, continuous

5. What are Capability Maturity Models? • Organized collections of best practices • Based on work by Crosby, Deming, Juran, Humphrey... • Systematic ordered approach to process improvement. • Means of measuring organizational maturity. • Have proven to bring significant return on investment in productivity and quality.

6. CMM I How are CMMs used? • Process Improvement • Process Definition • Competency Assessment • Risk Management • Communication

7. The Current Situation - every silver lining has a dark cloud • Multiple assessments • Multiple training • Multiple expenses • Explosion of CMMs and CMM-like models • Multiple models within an organization

8. Courtesy Sarah Sheard, SPC

9. Why is This a Problem? • Similar process improvement concepts, but... • Different model representations (e.g. staged, continuous, questionnaire, hybrid) • Different terminology • Different content • Different conclusions • Different appraisal methods

10. Improvement in any discipline is a function of performing: Implementingpractices that reflect the fundamentals of a particular topic (e.g. configuration management) Institutionalizingpractices that lead to sustainment and improvement of an implementation The Common Basis for Model-Based Process Improvement

11. All CMMI source models contain: • Implementing practicesgrouped by affinity • Institutionalizing practices that vary from model to model, however all models specify levelsthat describe increasing capability to perform

12. Improvement Levels Continuously Optimizing (5) improving process Quantitatively Managed (measured) Predictable (4) process (standard) Standard, Defined (3) consistent process (planned and tracked) Managed Disciplined (2) process (performed) Initial (1) Not performed (0)

13. The CMMI Project • DoD sponsored • Collaborative endeavor • Industry • Government • Academia • Over 100 people involved

14. CMM Integration Project Steering Group Stakeholder/ Reviewers Co-Chairs P. Babel / B. Rassa Product Development Team Chief Architect R. Bate Project Manager J. Ferguson Coordinating IPT Team leads Editors (CCB) Training Meth. IPT Assessment Meth. IPT Architecture IPT PA Author Groups IPPD IPT Reqmts. IPT Usability Team Lotus Notes Team Pilot Planning

15. U.S. Air Force U.S. Navy Federal Aviation Administration National Security Agency Software Engineering Institute (SEI) ADP, Inc. Boeing Computer Sciences Corp. Ericsson Canada General Dynamics Honeywell Litton Lockheed Martin Northrop Grumman Pacific Bell Raytheon Rockwell Collins Thomson CSF TRW The CMMI Development Team

16. CMMI Design Goals • Integrate the models, eliminate inconsistencies, reduce duplication • Reduce the cost of implementing model-based process improvement • Increase clarity and understanding • Common terminology • Consistent style • Uniform construction rules • Common components • Assure consistency with ISO 15504 • Be sensitive to impact on legacy efforts

17. Benefits • Efficient, effective assessment and improvement across multiple process disciplines in an organization • Reduced training and assessment costs • A common, integrated vision of improvement for all elements of an organization • A means of representing new discipline-specific information in a standard, proven process improvement context

18. The Challenge • Extract the common or best features from the source models • Provide users the ability to produce single- or multiple-discipline models, both continuous and staged, tailored to their organizational needs. • Provide users the ability to assess and train based on these models.

19. CMMI Source Models • Capability Maturity Model for Software V2, draft C (SW-CMM V2C) • EIA Interim Standard 731, System Engineering Capability Model (SECM) • Integrated Product Development Capability Maturity Model, draft V0.98 (IPD-CMM)

20. Staged Representations • Key Process Areas are grouped in the stages (levels) from 2 to 5 • A Key Process Area contains specific practices (activities) to achieve the purpose of the process area. • For a Key Process Area at a given stage, institutionalization practices are integral to the process area.

21. 2 Repeatable Staged Model Level Focus Key Process Areas Org Improvement Deployment Org Process and Tech Innovation Defect Prevention Continuous 5 process Optimizing improvement 4 Quantitatively Managed Organization Process Performance Statistical Process Management Org Software Asset Commonality Quantitative management Peer Reviews Project Interface Coordination Software Product Engineering Organization Training Program Organization Process Definition Organization Process Focus 3 Process Standardization Defined Software Configuration Management Software Quality Assurance Software Acquisition Management Software Project Control Software Project Planning Requirements Management Basic Project Management 1 Competent people and heroics Initial

22. Continuous Representations • A process area contains specific practices to achieve the purpose of the process area. • Generic practices are grouped in Capability Levels • Generic practices are added to the specific practices of each process area to attain a capability level for the process area. • The order in which Process Areas are addressed can follow a recommended staging.

23. Continuous Model

24. Source Model Terminology

25. CBA IPI Method Rating of goals Single digit rating Full goal satisfaction More strict data validation requirement SECM Assessment Method Rating of practices Granularity options Partial credit options Less strict data validation requirement Assessment Methods Both methods use the same basic set of activities

26. The CMMI Challenge • Integrate three source models that have many differences • Provide consistency with ISO 15504 • Maintain support from user communities • Develop framework to allow growth to other disciplines

27. Design Approach Objectives • Review design goals • Discuss framework of CMMI models • Describe CMMI terminology and components • Outline CMMI products • Discuss CMMI Schedule and current issues

28. SE SW Industry IPPD ... CMMI Product Suite SEI Assess Government Training CMMI- SW CMMI- SE CMMI- SE/SW • Team of Teams • Modeling and Discipline Experts • Collaborative Process ... CMMI- SE/SW/ IPPD The CMMI SolutionA Product Line Approach

29. Domain Architecture Components The CMMI Product Line The CMMI product line is a product suite sharing a common, managed set of features that satisfy specific needs of a selected domain. pertain to is satisfied by share an Products guides development of are built from

30. CMMI Product Suite Framework Input Transform Output • Common • content • Discipline • content • Criteria for • content • Rules for • generating • products • -Model • -Assessment • -Training • Integrated • model(s) • Assessment • method(s) • Training • materials Repository

31. Framework • Components • Construction rules • Conceptual architecture

32. The CMMI Framework • Framework General • Glossary • Development Standards and Guidelines • Document Templates • Assessment Methodology • Framework Training Materials Shared (Discipline X+Y) Discipline Y Discipline X (DX) DX AmplificationsDX Process Areas DX Assessment Material DX Model Training Material DX Assessment Training Material Process Management Core (PMC) PMC Generic Practices/Templates PMC Process Areas PMC Assessment Material PMC Model Training Material PMC Assessment Training Material Integration Core (IC)IPPD Environment IC Generic Practices/Templates IC Process Areas IC Assessment Material IC Model Training Material IC Assessment Training Material + Output Models Assessment Methods Model Training Materials Assessment Training Materials

33. CMMI Terminology CMMI Models contain institutionalization (Generic) and implementation (Specific) parts: • Front matter • Process Areas that contain: • Generic and Specific Goals • Generic and Specific Practices(in Common Features in staged representation) • Subpractices • Notes • Discipline-specific amplifications • Glossary and tailoring guidelines Required Expected Informative

34. Process Management Core Engineering Shared (SE & SW) Project Planning Requirements Management Project Monitoring and Control Configuration Management Process & Product Quality Assurance Supplier Agreement Management Data Management Measurement & Analysis CMMI V0.2 Process Areas - 1Maturity Level 2

35. Process Management Core Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis & Resolution Engineering Shared (SE & SW) Customer & Product Requirements Technical Solution Product Integration Product Verification Validation CMMI V0.2 Process Areas - 2Maturity Level 3

36. CMMI V0.2 Process Areas - 3Maturity Levels 4 & 5 Process Management Core • Quantitative Management of Quality and Process • Organizational Process Performance • Causal Analysis and Resolution • Organizational Process Technology Innovation • Process Innovation Deployment

37. CMMI Products • CMMI Models • Assessment Material • Training Material • Model Developer Material

38. CMMI Models • Staged and Continuous (with equivalent staging) versions of: • Software Engineering • Systems Engineering • Systems Engineering + Software • Systems Engineering + Software with IPPD • Tailoring Guidance

39. Assessment Material • Assessment requirements • Assessment methodology • Assessment data collection methods and tools (e.g., questionnaires, interviews) • Assessment Team qualifications

40. Training Material • Model Training • Assessment Training • Team Training • Lead Assessor Training

41. Model Developer Material • Glossary • Framework and model content criteria • Framework Training

42. CMMI Schedule • August 31, 1999 Release CMMI-SE/SW V0.2 for public review. • Nov 30, 1999 Release CMMI-SE/SW/IPPD for public review • Nov 1999-May 2000 Pilot assessments • Jun-Aug 2000 Publish models V1.0

43. Size of model Complexity of model “Normative” model Goals and Themes Order of process areas ISO Consistency Equivalence between staged and continuous representations “Advanced” practices Process area boundaries Generic practices Issues Concerning Initial CMMI Drafts CMMI team received 4000+ change requests from reviewers

44. CMMI-SE/SW compared to SW-CMM v1.1Dr. Rick Hefner Objectives • Philosophy • Model Component Comparison • Process Area Comparison • Common Features Comparison

45. Philosophy - 1 • SEI had completed updates to the SW-CMM when the CMMI project was started • SW-CMM v2 Draft C was used as the source model for CMMI • Adapted for compatibility with SE • Most of the community is currently using SW-CMM v1.1 • Detailed traceability matrices are being developed

46. Philosophy - 2 • CMMI- SE/SW staged representation is similar to SW-CMM v1.1 • Maturity Levels composed of Process Areas • Goals are required; implemented & institutionalized • Key practices are expected; alternative practices are acceptable if effective at meeting the goals • All else is informative • CMMI- SE/SW continuous representation reflects the same info in a SPICE-like structure

47. Model Component Comparison CMMI ModelsSW CMM Process Area Key Process Area Generic Goal Planning Goal sometimes used v1.1, Institutionalization Goal in 2.0 Specific Goal KPA Goal Generic Practice Key practices from institutionalization common features Specific Practice Key Practice from Activities Performed Common Features Subpractice Subpractice Maturity Level Maturity Level Capability Level None Notes Explanatory Material Work Products Examples “For Software Engineering” Examples and explanatory materiel

48. SW-CMM v1.1 CMMI Defect prevention Causal Analysis and Resolution Technology change mgmt Org. Process Technology Innovation Process change mgmt Process Innovation Deployment Quantitative process mgmt Org. Process Performance Software quality mgmt Quantitative Mgmt of Quality & Process Organization process focus Organization process focus Organization process definition Organization process definition Training program Organizational training Integrated software mgmt Integrated project management Risk Management Software product engr Customer and Product Reqmts Technical Solution Product Integration Intergroup coordination Product Verification Peer reviews Validation Decision Analysis and Resolution Requirements management Requirements management Software project planning Project planning Software project tracking & oversight Project Monitoring and Control Software subcontract mgmt Supplier Agreement Management Software quality assurance Product & Process Quality Assurance Software configuration mgmt Configuration Management Data Management Measurement and Analysis LEVEL 5 OPTIMIZING LEVEL 4 MANAGED LEVEL 3 DEFINED LEVEL 2 REPEATABLE

49. CMM I Software Product EngineeringSW-CMM v1.1 Activities 1 Appropriate software engineering methods and tools are integrated into the project's defined software process. 2 The software requirements are developed, maintained, documented, and verified by systematically analyzing the allocated requirements according to the project's defined software process. 3 The software design is developed, maintained, documented, and verified, according to the project's defined software process, to accommodate the software requirements and to form the framework for coding. 4 The software code is developed, maintained, documented, and verified, according to the project's defined software process, to implement the software requirements and software design. 5 Software testing is performed according to the project's defined software process. Customer and Product Req PA Technical Solution PA Technical Solution PA Product Verification PA

50. CMM I Software Product EngineeringSW-CMM v1.1 Activities (continued) Product Integration PA 6 Integration testing of the software is planned and performed according to the project's defined software process. 7 System and acceptance testing of the software are planned and performed to demonstrate that the software satisfies its requirements. 8 The documentation that will be used to operate and maintain the software is developed and maintained according to the project's defined software process. 9 Data on defects identified in peer reviews and testing are collected and analyzed according to the project's defined software process. 10 Consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software requirements, software design, code, test plans, and test procedures. Product Verification PA CMMI 50