Notes
Slide Show
Outline
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
Background
 Dr. 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
How are
CMMs used?
  • Process
    Improvement
  • Process Definition
  • Competency
    Assessment
  • Risk Management
  • Communication
7
The Current Situation - every silver lining has a dark cloud
  • Explosion of CMMs
    and CMM-like models
  • Multiple models within
    an organization


8
 
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
The Common Basis for Model-Based Process Improvement
  • Improvement in any discipline is a function of performing:
    • Implementing practices that reflect the fundamentals of a particular topic (e.g. configuration management)
    • Institutionalizing practices that lead to sustainment and improvement of an implementation
11
All CMMI source models contain:
  • Implementing practices grouped by affinity


  • Institutionalizing practices that vary from model to model, however all models specify levels that describe increasing capability to perform
12
Improvement Levels
13
The CMMI Project
  • DoD sponsored
  • Collaborative endeavor
    • Industry
    • Government
    • Academia
  • Over 100 people involved


14
 
15
The CMMI Development Team
  • 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


16
"Integrate the models,"
  • 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
Staged Model
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
Assessment Methods
  • 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
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
 
29
The CMMI Product Line
30
CMMI Product Suite
31
Framework
  • Components
  • Construction rules
  • Conceptual architecture
32
The CMMI Framework
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
34
CMMI V0.2 Process Areas - 1
 Maturity Level 2
  • 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
35
CMMI V0.2 Process Areas - 2
 Maturity Level 3
  • 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
36
CMMI V0.2 Process Areas - 3
Maturity 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
Issues Concerning
Initial CMMI Drafts
  • 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
44
CMMI-SE/SW compared to
SW-CMM v1.1
Dr. 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
48
SW-CMM v1.1     CMMI
49
Software Product Engineering
SW-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.
50
Software Product Engineering
SW-CMM v1.1 Activities (continued)
  • 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.
51
Common Feature Comparison
52
Conclusions
  • Organizations using SW-CMM v1.1 should be able to smoothly transition to CMMI
    • Measurement and Analysis & Data Mgmt at L2
    • Risk Management & Decision Analysis and Resolution at L3
    • Expansion of Software Product Engineering
    • Configuration Management for all Process Areas
53
Comparing CMMI-SE/SW
to EIA IS 731-SECM
  • Objectives
  • Philosophy
  • Process Area Comparison
  • Planned IPPD Extensions
54
Philosophy - 1
  • EIA 731 was created as a merger of the SE-CMM and INCOSE SECM models
    • Used as a source model for CMMI
  • CMMI-SE/SW merges software ideas
    • Staged representation of SE available
    • Continuous representation with “equivalent staging”
55
 
56
EIA 731 Focus Areas - 1
  • Technical Focus Areas
    • Define Stakeholder and
      System Level Requirements
    • Define Technical Problem
    • Define Solution
    • Assess and Select
    • Integrate System
    • Verify System
    • Validate System
57
EIA 731 Focus Areas - 2
  • Management Focus Areas
    • Plan and Organize
    • Monitor and Control
    • Integrate Disciplines
    • Coordinate with Suppliers
    • Manage Risk
    • Manage Data
    • Manage Configurations
    • Ensure Quality
58
EIA 731 Focus Areas - 3
  • Environment Focus Areas
    • Define and Improve the
      Systems Engineering Process
    • Manage Competency
    • Manage Technology
    • Manage Systems
      Engineering Support Environment
59
What’s New?
  • Not a EIA 731 Focus Area
    (but in the content)
    • Causal Analysis and Resolution
    • Process Innovation Deployment
    • Quantitative Process and
      Quality Mgmt
    • Organizational Process
      Performance
60
Conclusions
  • EIA 731 users should be able to smoothly transition to the CMMI-SE/SW model
    • Continuous representation (+ “equivalent” staged representation)
    • Some lower level differences
  • Integrated Product and Process Development (IPPD) will be added
    • Based on IPPD-CMM practices
61
Assessment Methodology
Dr. Rick Hefner (TRW)
Assessment Methodology Team Co-lead
  • Objectives
  • Assessment approach
  • Assessment Requirements for CMMI (ARC)
  • SCAMPI assessment method
  • Lead Assessor program, transition plan
62
Assessment Methods
  • CBA IPI Method
    • Rating of goals
    • Single digit rating
    • Full goal satisfaction
    • More strict data validation requirement
  • SECM Method
    • Rating of practices
    • Granularity options
    • Partial credit options
    • Less strict data validation requirement
63
Assessment Requirements for CMMI (ARC)
  • Similar to the current CMM
    Appraisal Framework (CAF) V1.0
    • Specifies the minimum
      requirements for full, comprehensive
      assessment methods, e.g., SCAMPI
  • Other assessment methods may be defined for situations not requiring a comprehensive assessment
    • initial assessment, quick-look, process improvement monitoring, etc.
64
Standard CMMI Assessment Method
for Process Improvement (SCAMPI)
  • Similar to CBA IPI method
  • Led by authorized Lead Assessor
  • Tailorable to organization and model scope
  • Artifacts:
    • SCAMPI Method description document
    • Maturity questionnaire, work aids, templates
  • Current activities
    • Merger of SECM appraisal method features
65
CMMI Lead Assessor Program
  • Similar to existing SEI Lead Assessor
    and Lead Evaluator programs
  • Grandfather current Lead Assessors
  • Under consideration
    • Delineate by discipline, e.g., SW Lead Assessors, SE Lead Assessors?
    • Details of transition process for current Lead Assessors and other assessment leaders
    • Required training in CMMI models
66
Comment Process
Dr. Jack Ferguson
  • Release CMMI-SE/SW v0.2 August 31
    • Available at http://www.sei.cmu.edu
    • Public comments due November 30
  • Release CMMI-SE/SW/IPPD November 30
    • Comments due February 28
  • Hold Focus Group discussions
    • SEI Transition
    • Assessors for both communities
    • SPINs

67
Pilot Assessments
  • Nine initial assessments (desired)
    • Supported by 3 Product Development Team (PDT) members,
    • Covering all CMMI models, staged and continuous representations
    • Nine organizations (4 DoD & 5 industry) volunteered to participate
      • 1 - CMMI SE/SW with IPPD, staged or continuous representation
      • 4 - CMMI SE/SW, staged representation
      • 2 - CMMI SE/SW, continuous representation
      • 1 - CMMI SE, continuous representation
      • 1 - CMMI SW, staged representation
  • Product Development Team (PDT) member roles
    • CMMI Product Suite Training
    • Coaching and structured observation
  • Structured feedback from assessment participants
    • Assessors and Sponsors, and
    • Participating organization members
68
CMMI Transition Plan
  • Development Phase
    • Development of CMMI products
    • Verification and Validation of CMMI products
  • Transition Phase
    • Approval of a CMMI Product for public release
    • Evidence of sufficient use
    • Transition planning to help organizations use CMMI products
  • Sustainment Phase
    • Upkeep & continuous improvement of the product suite
    • Additional evidence of adoption and use


69
Transitioning to Use of CMMI
  • Understand how models are used:
    • Steps to enterprise-wide process improvement
  • Apply Lessons Learned in transitioning from single-discipline models
    • Federal Aviation Administration’s experiences with iCMM
    • US Air Force experiences with transitioning between models
    • Others...
70
Steps to Enterprise-wide Organizational Maturity
71
CMMI Benefits
  • CMMI product users can expect to:
    • Efficiently and effectively improve and assess multiple disciplines across their organization
    • Reduce costs (including training) associated with improving and assessing processes
    • Deploy a common, integrated vision of process improvement that can be used
      as a basis for enterprise-wide process improvement efforts.
72
The promise...
  • CMMI team is working to assure the CMMI Product Suite addresses needs of software and systems engineering communities of practice
  • Use of an integrated model to guide enterprise process improvement promises to be one of the more sustainable & profitable initiatives that any organization might pursue