Source: Presentation
made by Mike Phillips at the SEPG 2006
List of 10 major changes in CMMI V1.2
The
10 major changes address three themes :
Reduce
Complexity and Size, Expand Model Coverage, Increase confidence in and
usefulness of SCAMPI appraisal results.
Renamed as: CMMI
for Development V1.2 or CMMI-DEV V1.2, the model has 22 process areas,
release dated August 2006. [DOWNLOAD
CMMI-DEV 1.2]
1. Notion
of advanced practices (Engineering Process Areas) and the term common
features with references to Commitment to Perform, Ability To Perform,
Directing Implementation and Verifying Implementation have been
eliminated.
2.
Integrated Supplier Management is now part of Maturity Level 3 (and not a
separate component of the model - /SS (Supplier Sourcing), just as
Supplier Agreement Management is part of the core model itself at Level 2.
Two Specific Practices were added to SG2 in SAM:
o
SP 2.2 (NEW) – Monitor
Selected Supplier Processes
o
SP 2.3 (NEW) – Evaluate
Selected Supplier Work Products
o
SG2 of SAM has now 5 specific practices instead of 4. The
other three specific practices in SAM are -
SP 2.1 Execute the
Supplier Agreement
SP 2.4 Accept the
Acquired Product
SP 2.5 Transition
Products
3.
Practice removed from SAM:
o
SAM: SP 2.1: Review
COTS Products (Deleted) from SG 2. This practice is now a sub practice
under Technical Solutions Process Area - SP 1.1 ' Develop Alternative
Solutions and Selection Criteria'.
4. With
hardware additions, CMMI will now take a single book approach as
CMMI-DEVELOPMENT + IPPD, where DEVELOPMENT could include Software
Engineering, Systems Engineering and Hardware Engineering; SIX
HARDWARE AMPLIFICATIONS ADDED.
·
Users can choose
‘representation specific content’, ‘addition specific content’, and the
appropriate amplifications for hw, software, and systems
·
Other models under
development are CMMI for Acquisition and CMMI for Services (Will be
available in 2007)
5. The
number of Not Applicable process areas is significantly constrained to
only SAM; such decisions must be recorded in the ADS.
6.
ADDED EMPHASIS ON PROJECT START UP: Two 'work environment' practices
were added; one each into OPD (for an organizational look) and IPM (for
project specifics) as follows:
o
OPD: SP1.6 (NEW) -
Establish Work Environment Standards
o
IPM: SP 1.3 (NEW) -
Establish the Project's Work Environment
o
IPM: SP 1.1
(Statement Modified) - Establish and
maintain the Project's Defined Process … (added) … from project start-up
through the life of the project
o
OPF: SP 1.2
(Statement Modified) – Appraise the ‘organization’s process’ (instead
of processes of the organization) periodically and as needed to maintain
an understanding of their strengths and weaknesses.
o
OPF: SG 2
(Statement Redefined) – Plan and Implement Process Improvement(s)
Activities
o
OPF:
SG 3 (NEW) – Deploy Organizational
Process Assets and Incorporate Lessons Learned. Contains 4 SPs. Two
new and two old from SG 2 reshuffled.
(RESHUFFLED SP 2.3)
SP 3.1 Deploy
Organizational Process Assets
(NEW) SP 3.2 Deploy
Standard Processes
(NEW) SP 3.3 Monitor
Implementation
(RESHUFFLED SP 2.4)
SP 3.4 Incorporate Process-Related Experiences into the Organizational
Process Assets
7. IPPD
Process Areas of OEI and IT have been merged into OPD and IPM
respectively by adding a new goal in OPD and consolidating the goal
statements in IPM as follows:
o
OPD+IPPD has: SG 2 (NEW)
- Enable IPPD Management
§
SP 2.1 - Establish Empowerment Mechanisms
§
SP 2.2 - Establish Rules and Guidelines for
Integrated Teams
§
SP 2.3 - Balance Team and Home Organization
Responsibilities
IPM+IPPD: SG 3
(NEW, CONSOLIDATION OF SG3 AND SG4 WITH INTEGRATED
TEAMING) - Apply IPPD Principles
§
SP 3.1 - Establish the project's shared vision
§
SP 3.2 - Establish integrated team structure for the
project
§
SP 3.2 - Allocate requirements to integrated teams
§
SP 3.4 - Establish Integrated Teams
§
SP 3.5 - Establish coordination among interfacing teams
8.
CHANGES TO ENGINEERING PROCESS AREAS
§
RM: Bi-directional
traceability in Requirements Management is now - "Maintain Bidirectional
traceability among the requirements and work products". - no longer
mentions project plan and the capability level (which earlier was at 2)
§
RM: SP 1.2 – OBTAIN
COMMITMENT TO REQUIREMENTS
(Note
the dropping out of -2)
§
RD: All references to
lower level specific practices have been eliminated in the engineering
category; so, SP 1.1-1 of RD - Collect
Stakeholder Needs has been subsumed into SP 1.1 of RD and reads as – SP
1.1 - Elicit Needs. (Note the dropping out of
-1)
§
RD: SP 3.4-3. Dropped
-3 attribute for ANALYZE REQUIREMENTS TO ACHIEVE BALANCE.
§
RD: SP 3.5 Validate
requirements has been combined with Validate Requirements using
Comprehensive Methods and now reads: VALIDATE REQUIREMENTS
§
TS: SP 1.1 Develop
alternative solutions and Selection Criteria has been combined with
Develop Detailed Alternative Solutions and Selection Criteria and now
reads as: DEVELOP ALTERNATIVE SOLUTIONS AND SELECTION CRITERIA
§
TS: SP 2.3 Establish
Interface Descriptions has been combined with Design interfaces using
criteria and now reads as: DESIGN INTERFACES USING CRITERIA.
§
TS: SP 2.4-3. Dropped
-3 attribute for ‘PERFORM MAKE BUY OR REUSE ANALYSIS
§
TS: (DELETED SP 1.2 –
Evolve Operational Concepts and Scenarios) and incorporated into RD - SP
3.1 Establish Operational Concepts and Scenarios.
§
PI: SP 1.2-2 – Est.
Product Integration env., and SP 1.3-3 – Est. Product Integration
Procedures and Criteria (Higher level attributes dropped).
§
VER: SP 1.2-2 – Est.
Verification Env., and SP 1.3-3 – Est. Verification Procedures and
Criteria, SP 2.3-2 – Analyze Peer-review data, SP 3.2-2 – Analyze
Verification Results and Identify Corrective Action (higher level
attributes dropped).
§
VER: SP 3.2
(Statement Title Modified) – Analyze Verification Results and
Identify Correction Actions [NOTE:
Corrective Actions is handled in PMC SG2 – Manage Corrective
Actions to Closure]
§
VAL: SP 1.2-2 – Est.
Validation Env., and SP 1.3-3 – Est. Validation Procedures and Criteria
(Higher level attributes dropped)
§
VAL: SP 2.2
(Statement Modified) – Analyze the results of validation activities
and identify issues.
9.
Practices in OID and OPP have been revised as follows:
o
OID: SP 1.4 Select
Improvements for Deployment
:: Select process and technology improvements proposals for
deployment across the organization.
o
OPP: SP 1.1: Select
the processes and sub-processes (not process elements) in the
organization's set of standard processes that are to be included in the
organization's process performance analysis
10.
CHANGES TO GENERIC PRACTICES
-
GP 1.1 – Perform ‘SPECIFIC’ practices and not base practices
-
GP 2.2 – Plan the Process informative material was condensed
-
GP 2.4 – Assign responsibilities includes ‘authority’ in the informative
component
-
GP 2.6 – reads as Manage Configurations: Place designated work products
of <PA NAME> under appropriate levels of control (NOT Configuration
management).
-
GP 2.9 – Objectively evaluate adherence – informative material
emphasizes work products
-
GP 5.2 – Correct root causes of problems – added notes that the focus is
on a quantitatively managed process.
The detailed presentation is
published for the benefit of the user community at:
http://www.SITARATECH.com/MikePhillipsSEPG_2006.zip
MAJOR ANNOUNCEMENTS:
January 1, 2006: Sunset
of CMMI V1.1 (Staged ONLY) and (Continuous ONLY) - These two courses
are no longer offered by SITARA Technologies since they are not valid
anymore. Instead, the new CMMI V1.1 (Staged and Continuous) would be
taught in
SITARA's rendering of the SEI Authorized Introduction to CMMI.
SITARA will be able to offer Introduction to CMMI V1.2 as and when
this course becomes available.
Launch of CMMI V1.2 is scheduled around
July 2006 - Instructor and Appraiser upgrades will happen around
October 2006.
The purpose of Capability Maturity Model (CMM®) IntegrationSM
is to provide guidance for improving your organization's processes and
your ability to manage the development, acquisition, and maintenance of
products and services. CMM Integration places proven practices into a
structure that helps your organization assess its organizational maturity
and process area capability, establish priorities for improvement, and
guide the implementation of these improvements.
The CMM Integration project was formed to address the problem of having
to use multiple Capability Maturity Models. The initial mission of the
project was to combine three source models:
Capability Maturity Model for Software (SW-CMM) v2.0 draft C
Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems
Engineering Capability Model (SECM)
Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98
into a single model for use by organizations pursuing enterprise-wide
process improvement.
SITARA can help you with the following beginning January 1, 2002 -
Facilitate your transition from your existing process infrastructure to
the CMMI-SE/SW/IPPD framework.
Provide you with innovative solutions to back your management needs and
engineering decisions
Provide you with assessment services using the SCAMPISM method
Engineer your development processes and practices around the following
process areas giving you a quick ability to adopt, adapt and create
self-sustaining process programs using the CMMI-SE/SW/IPPD (on both continuous
and staged versions).
Since there are two
representations to choose from, the obvious question would be - which one?
You may choose the Staged Representation if you are already familiar with
the Software CMM Version 1.1. The governing philosophy behind the staged
representation has not changed and it calls for working on ALL of
the Process Areas belonging to a "Maturity Level" at once. In
doing so, the organizational processes mature UP to an "evolutionary
plateau" that signifies organizational maturity. In the CMMI-SE/SW/IPPD Version 1.02 there are 7 Process Areas that will need the
necessary and sufficient process infrastructure, the systems and practices
to be in place. After these process areas have shown the tenacity and a
degree of detail that is necessary for them to improve, the process areas
at Level 3 can be attempted. And so on until Level 5.
However, there is no reason why
a process area at say the Level 5 need not be addressed in the process
context while still attempting to articulate a Level 3 process
infrastructure. Many times focusing attention on the higher maturity level
process areas may just be what is needed to get a sufficiently robust
Level 2 or Level 3 process area. Organizations that have done remarkably
on their process improvement journey by showing orders of magnitude
improvement in their delivery capacity and have accomplished high process
capability have done just that - shown great foresight in addressing the
practices belonging to the higher maturity process areas with the support
of the much needed talented individuals.
And of course, the question of
- "what do I do if a particular process area, say Causal
Analysis and Resolution" is less relevant to me at the moment
while some other process area, such as Requirements Management is where I
am having all the toughest challenges and therefore is more applicable in
my business context?" - just got answered with the introduction of
the "Continuous Representation".
Theoretically, it is possible
to improve the capability of just one process area to a high enough
maturity so that other process areas can subsequently be improved.
Practically speaking, it is indeed possible to improve the lower
level process areas in the staged representation to a sufficient degree of
robustness. And so the concept of "individual process area
capability" was introduced. Requirements Management belonging to the
Engineering Category of the Continuous Representation can be moved to a
Capability Level 2 by addressing the Specific and Generic Goals at Level 2
by identifying requirements management practices, performing these base
practices and institutionalizing a managed process. After this is
accomplished, requirements management can be further improved by defining
a process that establishes a basis for collecting improvement information.
And then, further work on the process area by establishing specific
quality objectives to control the special causes of variation in
requirements management by stabilizing the performance of sub processes
such as requirements capture, requirements tracking and managing
volatility. Once a process area has matured UP to this level of process
capability, it becomes recognized as a "STABLE process".
At this time, the most important next step is to make it a "CAPABLE
process" by removing process variation due to common causes. From
experience the most common reasons for "common causes of process
variation" in software development is inadequate training and
imposition of personal preferences. Quite rightly these common
cause variations can be reduced by training, process automation and a host
of other techniques - in which SITARA has a significant body of
intellectual property in SITARA Process JewelBoxTM.
Measurement and Analysis assumes a significant importance in the
CMMI-SE/SW/IPPD and a presentation rendered by SITARA Technologies at
the Software Engineering Institute on September 11, 2001 is
available here.
The philosophy behind any process improvement framework remains the
same, whether the CMMI or the SW-CMM. What will be different however is
the "degree of detail" and the practices that are recommended.
To provide you with a comparison of how Software Project Planning and
Software Project Tracking of the Software CMM Version 1.1 has
metamorphosed in the CMMI as Project Planning and Project Monitoring and
Control, a presentation rendered by SITARA Technologies at the Software
Engineering Institute on November 14, 2001 is
available here.
SITARA has been asked several pertinent questions and some of them find a
place here. Questions posed & SITARA's responses to them will be
posted from time to time. If you want to submit a question, please use the
Ask SITARA Form.
