CMMI 1
The CMM Integration Project
Dr. Jack R. Ferguson Dr. Rick HefnerCMMI Project Manager Assessment Team Co-Lead
CMMI 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
CMMI 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
CMMI 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
CMMI 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.
CMMI 6
How are CMMs used?
• Process Improvement
• Process Definition• Competency
Assessment
• Risk Management
• Communication
CMMI 7
The Current Situation - every silver lining has a dark cloud
• Explosion of CMMs and CMM-like models
• Multiple models within an organization
• Multiple assessments
• Multiple training
• Multiple expenses
CMMI 8
SW-CMM
Also see www.software.org/quagmire
The Frameworks QuagmireThe Frameworks QuagmireMIL-Q -9858
Trillium Baldrige
IEEE Stds. 730,828829, 830,1012,1016
1028,1058,1063ISO 15504*(SPICE)
People CMM
IPD-CMM*
DODIPPD
SECAMAF IPD Guide
SDCCR
SCE
NATO AQAP1,4,9
BS5750
MIL-STD-498
DOD-STD -2167A
DOD-STD -7935A
MIL-STD-499B*
ISO/IEC12207
IEEE1220 ISO 10011
SDCE
SE-CMM SECM*(EIA/IS 731)
EIA/IS632
ISO 9000Series
EIA/IEEEJ-STD-016
IEEE/EIA12207
EIA 632*
MIL-STD-1679
IEEE 1074
TickITSSE-CMM
ISO 15288*
EQA
* Not yet released
CMMI*
PSP
SA-CMM
Q9000
DOD-STD-2168
quag14d: 5 June 1998
FAA-iCMM
DO-178B
SW-CMM
Courtesy Sarah Sheard, SPC
CMMI 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
CMMI 10
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
The Common Basis for Model-Based Process Improvement
CMMI 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
CMMI 12
Initial (1)
Managed (2)
Defined (3)
QuantitativelyManaged (4)
Optimizing (5)
Disciplined process
Standard, consistent process
Predictable
process
Continuously
improving
process
Not performed (0)
(performed)
(planned and tracked)
(standard)
(measured)
Improvement Levels
CMMI 13
The CMMI Project
• DoD sponsored
• Collaborative endeavor– Industry– Government– Academia
• Over 100 people involved
CMMI 14
CMM Integration Project
Project Manager J. Ferguson
Chief ArchitectR. Bate
Steering GroupStakeholder/Reviewers Co-Chairs
P. Babel / B. Rassa
Reqmts. IPT
Architecture IPT
PA Author Groups
TrainingMeth.IPT
Assessment Meth. IPT
Coordinating IPTTeam leads
Product Development Team
IPPD IPT
Usability Team Lotus Notes Team
Editors (CCB)
Pilot Planning
CMMI 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
CMMI 16
• 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
CMMI Design Goals
CMMI 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
CMMI 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.
CMMI 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)
CMMI 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.
CMMI 21
Staged Model
1 Initial Competent people and heroics
Org Improvement DeploymentOrg Process and Tech InnovationDefect Prevention
5 Optimizing
4 Quantitatively
Managed
3 Defined
2 Repeatable
Continuous process improvement
Quantitativemanagement
ProcessStandardization
Organization Process PerformanceStatistical Process ManagementOrg Software Asset CommonalityPeer ReviewsProject Interface CoordinationSoftware Product EngineeringOrganization Training ProgramOrganization Process DefinitionOrganization Process Focus
Level Focus Key Process Areas
BasicProjectManagement
Software Configuration ManagementSoftware Quality AssuranceSoftware Acquisition ManagementSoftware Project ControlSoftware Project PlanningRequirements Management
CMMI 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.
CMMI 23
CL5 GPGPGP
CL4 GPGPGP
CL3 GPGPGPGPGP
CL2 GPGPGPGPGP
Implemented NI NA NRProcess Area NE RQ OS TR PM KM QA VS … SR FD IN
PA - Process AreaCLn - Capability Level n institutionalized (Level n GPs satisfied for PA)
GP - Generic PracticeImp - Implemented Base PracticesNI - Not ImplementedNA - Not ApplicableNR - Not Rated
Continuous Model
CMMI 24
Source Model Terminology
SW-CMMV2C
EIA IS 731SECM
IPD-CMMV0.98
Staged Continuous HybridMaturity Levels Capability Levels
CategoriesMaturity andCapability Levels
Key Process Areas Focus Areas Process AreasKey Process AreaGoals
Themes Capability andProcess Area Goals
Activities CommonFeature
Specific Practices Base Practices
Common Features Generic Practices Generic PracticesAdvanced PracticesGeneric Attributes(process effective-ness, product value)
CBA IPI Method SECM AppraisalMethod
CMMI 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
Both methods use the same basic set of activities
CMMI 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
CMMI 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
CMMI 28
The CMMI SolutionA Product Line Approach
CMMIProduct Suite
CMMI-SW
CMMI-SE
CMMI-SE/SW
CMMI-SE/SW/
IPPD
...
SW SE
IPPD
Assess
Training
...Industry
SEI
Government
•Team of Teams •Modeling and Discipline Experts
•Collaborative Process
CMMI 29
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.
Domain
Architecture
Components
pertain to
share an
are built from
is satisfied by
guides development ofProducts
CMMI 30
Input•Commoncontent•Discipline content•Criteria forcontent
Transform•Rules forgeneratingproducts-Model-Assessment-Training
Framework
Repository
Output•Integrated model(s)•Assessment method(s)•Training materials
CMMI Product Suite
CMMI 32
Shared (Discipline X+Y)Discipline Y
The CMMI FrameworkFramework General•Glossary•Development Standards and Guidelines•Document Templates•Assessment Methodology•Framework Training Materials
Process Management Core (PMC)PMC Generic Practices/TemplatesPMC Process AreasPMC Assessment MaterialPMC Model Training MaterialPMC Assessment Training Material
Integration Core (IC)IPPD EnvironmentIC Generic Practices/TemplatesIC Process AreasIC Assessment MaterialIC Model Training MaterialIC Assessment Training Material
Discipline X (DX)
DX Amplifications DX Process AreasDX Assessment MaterialDX Model Training MaterialDX Assessment Training Material
+
OutputModelsAssessment MethodsModel Training MaterialsAssessment Training Materials
CMMI 33
CMMI TerminologyCMMI 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
Informative
Expected
Required
CMMI 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
CMMI 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
CMMI 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
CMMI 37
CMMI Products
• CMMI Models
• Assessment Material
• Training Material
• Model Developer Material
CMMI 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
CMMI 39
Assessment Material
• Assessment requirements
• Assessment methodology
• Assessment data collection methods and tools (e.g., questionnaires, interviews)
• Assessment Team qualifications
CMMI 40
Training Material
• Model Training
• Assessment Training– Team Training– Lead Assessor Training
CMMI 41
Model Developer Material
• Glossary
• Framework and model content criteria
• Framework Training
CMMI 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
CMMI 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
CMMI team received 4000+ change requests from reviewers
CMMI 44
CMMI-SE/SW compared to SW-CMM v1.1
Dr. Rick Hefner
Objectives
• Philosophy
• Model Component Comparison
• Process Area Comparison
• Common Features Comparison
CMMI 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
CMMI 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
CMMI 47
Process Area Key Process Area
CMMI Models SW CMM
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 NoneNotes Explanatory Material
Work Products Examples
“For Software Engineering” Examples and explanatory materiel
Model Component Comparison
CMMI 48
SW-CMM v1.1 CMMIDefect prevention Causal Analysis and ResolutionTechnology change mgmt Org. Process Technology InnovationProcess change mgmt Process Innovation Deployment
Quantitative process mgmt Org. Process PerformanceSoftware quality mgmt Quantitative Mgmt of Quality & Process
Organization process focus Organization process focus Organization process definition Organization process definitionTraining program Organizational trainingIntegrated software mgmt Integrated project management
Risk ManagementSoftware product engr Customer and Product Reqmts
Technical SolutionProduct Integration
Intergroup coordination Product VerificationPeer reviews Validation
Decision Analysis and Resolution
Requirements management Requirements managementSoftware project planning Project planningSoftware project tracking & oversight Project Monitoring and ControlSoftware subcontract mgmt Supplier Agreement ManagementSoftware quality assurance Product & Process Quality Assurance Software configuration mgmt Configuration Management
Data ManagementMeasurement and Analysis
LEVEL 5OPTIMIZING
LEVEL 4MANAGED
LEVEL 3DEFINED
LEVEL 2REPEATABLE
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
Software Product EngineeringSW-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.
10Consistency 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 Integration PA
Product Verification PA
CMMI 50
CMMI 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
CMMI 53
Comparing CMMI-SE/SW to EIA IS 731-SECM
Objectives
• Philosophy
• Process Area Comparison
• Planned IPPD Extensions
CMMI 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”
CMMI 56
Project Planning (PM)Project Monitoring and Control (PM)Configuration Management (PM)Product and Process Quality Assurance (PM)Supplier Agreement Management (PM)Data Management (PM)Measurement and Analysis (PM)Requirements Management (Eng)
Organizational Process Focus (PM)Organizational Process Definition (PM)Organizational Training (PM)Integrated Project Management (PM)Risk Management (PM) Decision Analysis and Resolution (PM)Customer and Product Requirements (Eng)Technical Solution (Eng) Product Integration (Eng)Product Verification (Eng) Validation (Eng)
Quantitative Mgmt of Quality and Process (PM)Organizational Process Performance (PM)
Causal Analysis and Resolution (PM)Org Process Technology Innovation (PM)Process Innovation Deployment (PM)
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
CMMI 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
Project Planning (PM)Project Monitoring and Control (PM)Configuration Management (PM)Product and Process Quality Assurance (PM)Supplier Agreement Management (PM)Data Management (PM)Measurement and Analysis (PM)Requirements Management (Eng)
Organizational Process Focus (PM)Organizational Process Definition (PM)Organizational Training (PM)Integrated Project Management (PM)Risk Management (PM) Decision Analysis and Resolution (PM)Customer and Product Requirements (Eng)Technical Solution (Eng) Product Integration (Eng)Product Verification (Eng) Validation (Eng)
Quantitative Mgmt of Quality and Process (PM)Organizational Process Performance (PM)
Causal Analysis and Resolution (PM)Org Process Technology Innovation (PM)Process Innovation Deployment (PM)
CMMI 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
Project Planning (PM)Project Monitoring and Control (PM)Configuration Management (PM)Product and Process Quality Assurance (PM)Supplier Agreement Management (PM)Data Management (PM)Measurement and Analysis (PM)Requirements Management (Eng)
Organizational Process Focus (PM)Organizational Process Definition (PM)Organizational Training (PM)Integrated Project Management (PM)Risk Management (PM) Decision Analysis and Resolution (PM)Customer and Product Requirements (Eng)Technical Solution (Eng) Product Integration (Eng)Product Verification (Eng) Validation (Eng)
Quantitative Mgmt of Quality and Process (PM)Organizational Process Capability (PM)
Causal Analysis and Resolution (PM)Org Process Technology Innovation (PM)Process Innovation Deployment (PM)
CMMI 59
Project Planning (PM)Project Monitoring and Control (PM)Configuration Management (PM)Product and Process Quality Assurance (PM)Supplier Agreement Management (PM)Data Management (PM)Measurement and Analysis (PM)Requirements Management (Eng)
Organizational Process Focus (PM)Organizational Process Definition (PM)Organizational Training (PM)Integrated Project Management (PM)Risk Management (PM) Decision Analysis and Resolution (PM)Customer and Product Requirements (Eng)Technical Solution (Eng) Product Integration (Eng)Product Verification (Eng) Validation (Eng)
Quantitative Mgmt of Quality and Process (PM)Organizational Process Performance (PM)
Causal Analysis and Resolution (PM)Org Process Technology Innovation (PM)Process Innovation Deployment (PM)
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
CMMI 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
CMMI 61
Assessment MethodologyDr. Rick Hefner (TRW)
Assessment Methodology Team Co-lead
Objectives
• Assessment approach
• Assessment Requirements for CMMI (ARC)
• SCAMPI assessment method
• Lead Assessor program, transition plan
CMMI 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
Essentially the same activities in the two methods
CMMI 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.
CMMI 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
CMMI 65
CMMI Lead Assessor Program
• Similar to existing SEI Lead Assessorand 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
CMMI 66
Comment ProcessDr. 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
CMMI 67
• 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
Pilot Assessments
CMMI 68Development Phase
Transition Phase
Sustainment Phase
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
CMMI 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...
CMMI 70
MetricsCapture
ActivityBased
Costing
ProcessLevel
Evolution
ProjectManagement Simulation
Section name Section name Section name Section name
Org name
1. Vision, Goals, Buy-in
USED AT: AUTHOR: Joel Van Berkum DATE:
RE V:P ROJECT: MWSS S SOFTWARE PROCE SS
9/23/98
10/23/98
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMME NDE D
PUB LICATION
READE R DATE CONTEXT:
2
NODE : TITLE: NUMBER:APPROVE VCN2.3
2.3.1
GE T DRAFT VCNAP PROVAL
2.3.2
REVIE WCCB PACKAGE
2.3.3
DRY-RUNCCB
2.3.4
MODIFY CCB
S LIDE S
2.3.5
RE VIEW
CCBPACKAGE
2.3.6
REVIEW VCNB Y CCB
CCBpackage
CCB VCNapproval
Draft of VCNstaff sum m arysheet
Final CCB package
SSM
P roposedCCB agenda
Conditionallyapproved CCBpackage
Delayed CCB
package
DisapprovedCCB
package
Draft VCN approval
P MCustom er
CCBm inutes
Final CCBagenda
Personnel
Configuration
Managem ent
Configuration Managem ent
Delayed CCB package
ApprovedCCBpackage
4. Process Transformation From Process,
all good things flow!
USE D AT: AUTHOR: Joel Van Berkum DATE :
RE V:P ROJECT: MWS SS S OFTWARE P ROCES S
9/18/98
11/2/98
NOTE S: 1 2 3 4 5 6 7 8 9 10
WORK ING
DRAFT
RECOMMENDED
P UB LICATION
READER DATE CONTE XT:
-0
NODE: TITLE: NUMBE R:MAINTAIN AIR FORCE SPACE COMMANDSENSOR SOFTWARE0
1
PROCE SS RCP
PHASE 1
2
PLAN, COORDINATEAND AP PROVE A
MAINTENANCESOFTWARE P ROJE CT
PACKAGEPHAS E 2
3
P UT THE MAINTENANCE
SOFTWARE PROJE CTON CONTRACT
PHAS E 3
4
MANAGE THE
EXECUTION OFTHE MAINTE NANCE
SOFTWARE PROJE CTPHASE 4
5
CLOS EOUT THE MAINTENANCE
SOFTWARE PROJE CTPHASE 5
RCPValidatedRCP
Personnel
Operational acceptance m essage
CCB VCNapproval
CAT2 Defic iencies
AwardedContract
ContractorReports
Rejectedcontractor costproposal
MWS SS OI 21-7
Distributedsignedprojectcloseoutreport
Final CCB package2. Process Capture
Organization Processes
US ED AT: AUTHOR: Joel Van B erkum DATE:
REV:P ROJECT: MWS SS SOFTWARE PROCE SS
10/21/98
10/22/98
NOTES : 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDE D
P UBLICATION
READE R DATE CONTEXT:
2
NODE: TITLE: NUMB ER:PLAN PROJECT2.1
2.1.1
PERFORM VCNANALYS IS
2.1.2
CONSULT WITHSOFTWARE IP T
2.1.3
PREPARECCB
PACKAGE
2.1.4
P REP ARE ACQUIS ITIONSTRATE GY B RIE FING
2.1.5
CONDUCT ACQUISITION
S TRATE GY
2.1.6
PREPARE AND COORDINATE
DRAFT VCN
OASB m inutes
Sensor IPT
21ST SW21-10401
OARB m inutes
Release Fac tors
CCB package templateValidatedRCP
Draft VCN
DelayedCCBpackage
Mystic Algorithm s
CCB package
Acquisitionstrategy briefing
Inform al assessm entof Release Fac tors
Approvedacquisitionstrategy
Validated RCP
Rejectedcontractorcostproposal
3. Gap Analysis Best Practices
Steps to Enterprise-wide Organizational Maturity
CMMI 71
Improved Processes
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.
CMMI 72
• 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
The promise...
Top Related