University of Southern California
Center for Systems and Software Engineering
CMMI 1.3
CS 577b Software Engineering II
Supannika Koolmanojwong
University of Southern California
Center for Systems and Software Engineering
What is CMMI?
C onsultant
M oney
M aking
I nitiative
© 2011 USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
CMMI Models V1.3
CMMI® (Capability Maturity Model® Integration) models are
collections of best practices that help organizations to
improve their processes
Procedures and methods
defining the relationship of
tasks
B
A
D
C
PROCESS
People
with skills,
training, and
motivation
Tools and
equipment
© 2011 USC-CSSE
[Ref: CMMI]
3
University of Southern California
Center for Systems and Software Engineering
Brief Characterization of “CMMI”
CMMI (Capability Maturity Model Integration) is….
• A framework of management, engineering, and support best
practices organized into topics, called Process Areas
• An approach to improving the capability of any of the
Process Areas by incrementally applying a set of Generic
Practices that enhance the functioning of an individual
process
• Best thought of as a set of “process requirements” that help
guide an organization who is defining and implementing
processes related to the topics
• NOT a pre-defined, implementable “as is” process definition
© 2011 USC-CSSE
[Ref: Garcia 2005]
4
University of Southern California
Center for Systems and Software Engineering
Process Areas
Configuration Management (CM)
Causal Analysis and Resolution (CAR)
Decision Analysis and Resolution (DAR)
Integrated Project Management (IPM)
Measurement and Analysis (MA)
Organizational Performance Management (OPM)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Process Performance (OPP)
Organizational Training (OT)
Process and Product Quality Assurance (PPQA)
Product Integration (PI)
Project Monitoring and Control (PMC)
Project Planning (PP)
Quantitative Project Management (QPM)
Requirements Development (RD)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
© 2011 USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
Requirements Management Process Area
Purpose: to manage requirementsExample
of the project’s
products and product
Work Products
components and to ensure alignment
between
requirements
and the
1. Lists
of criteriathose
for distinguishing
appropriate
project’s plans and work products.requirements providers
2. Criteria for evaluation and acceptance of requirements
Specific Goal 1 Requirements are3.managed
and inconsistencies
with plans
Results of analyses
against criteria
and work products are identified. 4. A set of approved requirements
• Specific Practice 1.1 Develop an understanding with the requirements
providers on the meaning of the requirements.
–
•
•
•
Subpractices
1. Establish criteria for distinguishing appropriate requirements providers.
2. Establish objective criteria for the evaluation and acceptance of requirements.
3. Analyze requirements to ensure that established criteria are met.
4. Reach an understanding of requirements with requirements providers so that
project participants can commit to
them. of evaluation and acceptance criteria
Examples
include the following:
SP 1.2
•Clearly and properly stated
.........
•Complete
•Consistent with one another
SP 1.5
•Uniquely identified
•……………………
© 2011 USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
CMMI terminologies
CMMI
Process Area
• Requirements Management
• Project Planning
ICSM
Practice
• System and Software Requirements Dev Practice
• Life Cycle Planning Practice
Specific goal
Task
Specific practice
Step
Subpractice
Detailed step
Work Product
Work Product / Artifact / Output
• A set of approved requirements
• Agreed Win Conditions
© 2011 USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Example of a CMMI Process Area
Specific Goal
Specific Practice
Example Work Product
Example Box
Reference
Subpractice
© 2011 USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
CMMI-DEV
CMMI - SVC
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Measurement and Analysis (MA)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
CMMI - ACQ
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Process and Product Quality Assurance (PPQA)
Requirements Management (REQM)
Risk Management (RSKM)
Project Planning (PP)
Work Planning (WP)
Project Planning (PP)
Project Monitoring and Control
Work Monitoring and Control (WMC)
Project Monitoring and Control (PMC)
Integrated Project Management
Integrated Work Management (IWM)
Integrated Project Management (IPM)
Quantitative Project Management
Quantitative Work Management (QWM)
Quantitative Project Management (QPM)
Supplier Agreement
Agreement Management
Management (SAM)
(SAM)
Supplier
Product Integration (PI)
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Capacity and Availability Management
(CAM)
Incident Resolution and Prevention (IRP)
Service Continuity (SCON)
Service Delivery (SD)
Service System Development (SSD)
Service System Transition (SST)
Strategic Service Management (STSM)
© 2011 USC-CSSE
Agreement Management (AM)
Acquisition Requirements Development
(ARD)
Acquisition Technical Management (ATM)
Acquisition Validation (AVAL)
Acquisition Verification (AVER)
Solicitation and Supplier Agreement
Development (SSAD)
9
University of Southern California
Center for Systems and Software Engineering
Low Maturity Organizations
• Highly dependent on current
practitioners
• Improvised by practitioners and
management
• Not rigorously followed
• Results difficult to predict
• Low visibility into progress and
quality
• Compromise of product
functionality and quality to meet
schedule
• Use of new technology is risky
High Maturity Organizations
• A disciplined approach for
development and management
• Defined and continuously
improving
• Supported by management and
others
• Well controlled
• Supported by measurement
• Basis for disciplined use of
technology Institutionalized
© 2011 USC-CSSE
[Ref: Rudge]
10
University of Southern California
Center for Systems and Software Engineering
Process Area
Information:
Purpose Statement,
Introductory Notes,
Related Process Areas
Specific Goals
Specific Practices
•Example Work Products
•Subpractices
Generic Goals
Generic Practices
• Subpractices
• Generic Practice Elaborations
© 2011 USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
SGs and # of SGs are different
from process area to process area
GGs for every process area are the same
© 2011 USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Two improvement paths using levels
• Capability levels,
– continuous representation
– process improvement achievement in individual process areas
– These levels are a means for incrementally improving the processes
corresponding to a given process area.
– 4 capability levels, numbered 0 through 3.
• Maturity levels
– staged representation
– process improvement achievement across multiple process areas
– These levels are a means of improving the processes corresponding to
a given set of process areas
– 5 maturity levels, numbered 1 through 5
© 2011 USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
Using Continuous Representation
• When you know the processes that need to
be improved
• Improve the performance of a single
process area (the trouble spot) or several
process areas
• Allow an organization to improve different
processes at different rates.
© 2011 USC-CSSE
[Ref: Lazaris]
14
University of Southern California
Center for Systems and Software Engineering
Factors in your decision
• Business Factors
– Mature knowledge of its own business objectives
(continuous)
– Product-line focus; entire organization (staged)
• Cultural Factors
– Depend on org’s capability
• Process-based – Continuous
• Little experience in process improvement - staged
• Legacy
– Continuation from using other model
© 2011 USC-CSSE
[Ref: Lazaris]
15
University of Southern California
Center for Systems and Software Engineering
Comparison of Capability and Maturity Levels
Level
Continuous Representation
Capability Levels
Staged Representation
Maturity Levels
Level 0
Incomplete
Level 1
Performed
Initial
Level 2
Managed
Managed
Level 3
Defined
Defined
Level 4
Quantitatively Managed
Level 5
Optimizing
© 2011 USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
To achieve a capability level,
pick a process area
Capability Level 1: Performed
- accomplishes the needed work to
produce work products; the specific
goals of the process area are satisfied
Capability Level 2: Managed
- A managed process is a performed
process that is planned and executed
in accordance with policy; employs
skilled people having adequate
resources to produce controlled
outputs; involves relevant
stakeholders; is monitored, controlled,
and reviewed; and is evaluated for
adherence to its process description.
Capability Level 3: Defined
- A defined process is a managed
© 2011 USC-CSSE
process that is tailored from the
organization’s set of standard
processes according to the
organization’s tailoring guidelines; has
a maintained process description; and
contributes process related
experiences to the organizational
process assets
17
University of Southern California
Center for Systems and Software Engineering
Capability Levels
• Capability Level 0: Incomplete
– not performed or is partially performed.
– One or more of the specific goals of the process area are
not satisfied
– no generic goals exist for this level since there is no
reason to institutionalize a partially performed process
• Capability Level 1: Performed
– accomplishes the needed work to produce work
products; the specific goals of the process area are
satisfied
– Although capability level 1 results in important
improvements, those improvements can be lost over time
if they are not institutionalized
© 2011 USC-CSSE
[Ref: CMMI]
18
University of Southern California
Center for Systems and Software Engineering
Capability Levels
• Capability Level 2: Managed
– A managed process is a performed process that is
planned and executed in accordance with policy; employs
skilled people having adequate resources to produce
controlled outputs; involves relevant stakeholders; is
monitored, controlled, and reviewed; and is evaluated for
adherence to its process description.
• Capability Level 3: Defined
– A defined process is a managed process that is tailored
from the organization’s set of standard processes
according to the organization’s tailoring guidelines; has a
maintained process description; and contributes process
related experiences to the organizational process assets
© 2011 USC-CSSE
[Ref: CMMI]
19
University of Southern California
Center for Systems and Software Engineering
CMMI Maturity Levels
© 2011 USC-CSSE
[Ref: Buchholtz 2003]
20
University of Southern California
Center for Systems and Software Engineering
Categories of Process Areas
Process Area
Product Integration (PI)
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Integrated Project Management (IPM)
Project Monitoring and Control (PMC)
Project Planning (PP)
Quantitative Project Management (QPM)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
Causal Analysis and Resolution (CAR)
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
© 2011 USC-CSSE
Category
Engineering
Engineering
Engineering
Engineering
Engineering
Process Management
Process Management
Process Management
Process Management
Process Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Support
Support
Support
Support
Support
21
University of Southern California
Center for Systems and Software Engineering
Process Areas by Maturity Levels
Process Area
Project Monitoring and Control (PMC)
Project Planning (PP)
Requirements Management (REQM)
Supplier Agreement Management (SAM)
Configuration Management (CM)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Product Integration (PI)
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Organizational Process Definition (OPD)
Organizational Process Focus (OPF)
Organizational Training (OT)
Integrated Project Management (IPM)
Risk Management (RSKM)
Decision Analysis and Resolution (DAR)
Organizational Process Performance (OPP)
Quantitative Project Management (QPM)
Organizational Performance Management (OPM)
Causal Analysis and Resolution (CAR)
Category
Project Management
Project Management
Project Management
Project Management
Support
Support
Support
Engineering
Engineering
Engineering
Engineering
Engineering
Process Management
Process Management
Process Management
Project Management
Project Management
Support
Process Management
Project Management
Process Management
Support
© 2011 USC-CSSE
Maturity Level
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
3
4
4
5
5
22
University of Southern California
Center for Systems and Software Engineering
CMMI Process Areas (Staged)
Level
Project Management
Engineering
CAR: Causal Analysis and
Resolution
5 Optimizing
4 Quantitatively
Managed
3 Defined
Support
OPM: Organizational
Performance Management
OPP: Organizational
Process Performance
QPM: Quantitative
Project Management
IPM: Integrated Project
Management
RD: Requirements
Development
RSKM: Risk
Management
TS: Technical Solution
DAR: Decision Analysis
and Resolution
PI: Product Integration
OT: Organizational
Training
VAL: Validation
PP: Project Planning
OPF: Organizational
Process Focus
OPD: Organizational
Process Definition
VER: Verification
MA: Measurement and
Analysis
PMC: Project Monitoring
and Control
2 Managed
Process Management
PPQA: Process & Product
Quality Assurance
SAM: Supplier Agreement
Management
CM: Configuration
Management
REQM: Requirements
Management
1 Initial
© 2011 USC-CSSE
[Based on Ref: Rudge]
23
University of Southern California
Center for Systems and Software Engineering
Categories of Process Areas
Process Area
Category
Level
Integrated Project Management (IPM)
Project Management
Advanced - 3
Project Monitoring and Control (PMC)
Project Management
Basic - 2
Project Planning (PP)
Project Management
Basic - 2
Quantitative Project Management (QPM)
Project Management
Advanced - 4
Requirements Management (REQM)
Project Management
Basic - 2
Risk Management (RSKM)
Project Management
Advanced - 3
Supplier Agreement Management (SAM)
Project Management
Basic - 2
© 2011 USC-CSSE
24
University of Southern California
Center for Systems and Software Engineering
Categories of Process Areas
Process Area
Product Integration (PI)
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
© 2011 USC-CSSE
Category Level
Engineering 3
Engineering 3
Engineering 3
Engineering 3
Engineering 3
25
University of Southern California
Center for Systems and Software Engineering
Categories of Process Areas
Process Area
Category
Causal Analysis and Resolution (CAR)
Support
Advanced - 5
Configuration Management (CM)
Support
Basic - 2
Decision Analysis and Resolution (DAR)
Support
Advanced - 3
Measurement and Analysis (MA)
Support
Basic - 2
Process and Product Quality Assurance (PPQA) Support
Basic - 2
© 2011 USC-CSSE
Level
26
University of Southern California
Center for Systems and Software Engineering
Categories of Process Areas
Process Area
Category
Level
Organizational Process Definition (OPD)
Process Management
Basic - 3
Organizational Process Focus (OPF)
Process Management
Basic - 3
Organizational Performance Management (OPM) Process Management Advanced - 5
Organizational Process Performance (OPP)
Process Management Advanced - 4
Organizational Training (OT)
Process Management
© 2011 USC-CSSE
Basic - 3
27
University of Southern California
Center for Systems and Software Engineering
CMMI Appraisal
• Identify gap analysis between given
process areas and your process
– Practice
• Activities
• Action Items
– Work Product
• Artifacts
• Documents
• Reports
© 2011 USC-CSSE
28
University of Southern California
Center for Systems and Software Engineering
CMMI Appraisal - PPQA
Does our 577 process comply with
CMMI requirements? If yes, please
state an evidence
Adherence of the performed process and associated work products and services to
applicable process descriptions, standards, and procedures is objectively evaluated.
Objectively evaluate the designated performed processes against the applicable process
descriptions, standards, and procedures
Promote an environment (created as part of project
management) that encourages employee
participation in identifying and reporting quality
issues.
Product and Process Quality Assurance (PPQA) Process Area
SG 1
SP 1.1
SP 1.1-1
SP 1.1-2
Establish and maintain clearly stated criteria for the
evaluations.
SP 1.1-3
Use the stated criteria to evaluate performed
processes for adherence to process descriptions,
standards, and procedures.
SP 1.1-4
Identify each noncompliance found during the
evaluation.
SP 1.1-5
Identify lessons learned that could improve
processes for future products and services.
SP 1.1-WP 1
SP 1.1-WP 2
SP 1.1-WP 3
Evaluation reports
Noncompliance reports
Corrective actions
© 2011 USC-CSSE
29
University of Southern California
Center for Systems and Software Engineering
CMMI Appraisal
Requirements Development
SP 1.1
Elicit stakeholder needs, expectation, constraints, and interfaces for all phases of
the product lifecycle
SP 1.1-1
Engage relevant stakeholders using
methods for eliciting needs, expectations,
constraints, and external interfaces.
SP 1.2
Transform stakeholder needs, expectations, constraints, and interfaces into
customer requirements
SP 1.2-1
Translate the stakeholder needs,
expectations, constraints, and interfaces
into documented customer requirements.
SP 1.2-2
Define constraints for verification and
validation.
SP 1.2-WP 1 Customer requirements
SP 1.2-WP 2 Customer constraints on the conduct of
verification
SP 1.2-WP 3 Customer constraints on the conduct of
validation
© 2011 USC-CSSE
30
University of Southern California
Center for Systems and Software Engineering
CMMI Appraisal
Requirements Development
SP 2.1
Establish and maintain product and product-component requirements, which
are based on the customer requirements
SP 2.1-1
Develop requirements in technical
terms necessary for product and
product component design.
SP 2.1-2
Derive requirements that result
from design decisions
SP 2.1-3
Establish and maintain
relationships between requirements
for consideration during change
management and requirements
allocation
SP 2.1-WP 1 Derived requirements
SP 2.1-WP 2 Product requirements
SP 2.1-WP 3 Product component requirements
© 2011 USC-CSSE
31
University of Southern California
Center for Systems and Software Engineering
What is Six Sigma?
32
University of Southern California
Center for Systems and Software Engineering
What is six sigma?
• Sigma - a statistical term that measures how
far a given process deviates from
perfection.
• if you can measure how many "defects" you
have in a process, you can systematically
figure out how to eliminate them and get as
close to "zero defects" as possible
• To achieve Six Sigma, a process must not
produce more than 3.4 defects per million
opportunities or 99.9997% perfect.
33
University of Southern California
Center for Systems and Software Engineering
Think about a pizza delivery
• Not to deliver later than 25 minutes
• If achieve 68% of the time, you are
running at 1 Sigma
• if achieve 99.9997% of the time then
you are at 6 Sigma
• Six sigma measures quality.
• It measures the Variance and does
not rely on the Mean.
34
University of Southern California
Center for Systems and Software Engineering
Examples of the Sigma Scale
In a world at 3 sigma. . .
In a world at 6 sigma. . .
• There are 964 U.S. flight
cancellations per day.
• 1 U.S. flight is cancelled
every 3 weeks.
• The police make 7 false
arrests every 4 minutes.
• There are fewer than 4 false
arrests per month.
• In MA, 5,390 newborns are
dropped each year.
• 1 newborn is dropped every
4 years in MA.
• In one hour, 47,283
international long distance
calls are accidentally
disconnected.
• It would take more than
2 years to see the same
number of dropped
international calls.
35
University of Southern California
Center for Systems and Software Engineering
Lean Six Sigma
• Lean + Six Sigma
• Six Sigma
– recognize and eliminate defects and or low profit margins.
– recognize that variations in analyzing and measuring can
hinder or often block the ability to deliver high quality services.
– Focus on data
– Need a team of professionals (champion, black / green belts)
• Lean Six Sigma
– focus is on maximizing products or perform things faster by
removing the wastes
– seven forms of waste or "muda“ (Defects, overproduction,
overprocessing, motion, transportation, inventory and waiting)
– Six Sigma Quality + Lean Speed
36
University of Southern California
Center for Systems and Software Engineering
Lean Six Sigma
• Measurement activity of the 6δ DMAIC
takes a long time and lots of data
• Lean 6δ does not ignore measurement, will
do as necessary
37
University of Southern California
Center for Systems and Software Engineering
Lean Thinking provides a sharp degree of focus on customer value, and provides
mechanisms for rapid improvement
Six Sigma is the statistical control and performance prediction capability associated with
stable processes
[Ref: CrossTalk2010]
38
University of Southern California
Center for Systems and Software Engineering
ITIL - IT Infrastructure Library
• V3 - consists of 5 volumes:
–
–
–
–
–
Service Strategy
Service Design
Service Transition
Service Operation
Continual Service Improvement.
39
users.ox.ac.uk/~tony/itilv3.ppt
University of Southern California
Center for Systems and Software Engineering
The Service Lifecycle
• Service Strategy
– Strategy generation
– Financial management
– Service portfolio
management
– Demand management
• Service Design
management
– Change management
– Knowledge Management
• Service Operation
– Problem & Incident
management
– Request fulfilment
– Event & Access
management
– Capacity, Availability,
Info Security
Management
• Continual Service
– Service level & Supplier
Improvement
Management
– Service measurement &
• Service Transition
reporting
– Planning & Support
– 7-step improvement
process
– Release & Deployment
– Asset & Config
40
users.ox.ac.uk/~tony/itilv3.ppt
University of Southern California
Center for Systems and Software Engineering
How the Lifecycle stages fit
together
users.ox.ac.uk/~tony/itilv3.ppt
41
University of Southern California
Center for Systems and Software Engineering
Service Strategy
42
University of Southern California
Center for Systems and Software Engineering
Service Strategy has four
activities
Define the Market
Develop the Offerings
Develop Strategic Assets
Prepare for Execution
users.ox.ac.uk/~tony/itilv3.ppt
43
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
44
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
45
University of Southern California
Center for Systems and Software Engineering
Service Design
46
University of Southern California
Center for Systems and Software Engineering
Service Design
•
•
•
•
How are we going to provide it?
How are we going to build it?
How are we going to test it?
How are we going to deploy it?
Holistic approach to determine the impact
of change introduction on the existing
services and management processes
users.ox.ac.uk/~tony/itilv3.ppt
47
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
48
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
49
University of Southern California
Center for Systems and Software Engineering
Service Transition
50
University of Southern California
Center for Systems and Software Engineering
Service Transition
•
•
•
•
•
Build
Deployment
Testing
User acceptance
Bed-in (phased or big bang)
users.ox.ac.uk/~tony/itilv3.ppt
51
University of Southern California
Center for Systems and Software Engineering
Service Operation
52
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
53
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
54
University of Southern California
Center for Systems and Software Engineering
CMMI vs ITIL
CMMI
ITIL
Origins
CMU
United Kingdom’s Office of
Government Commerce
Scope
maturity model, best
practices applied in the
development of software
codes of best practices, and
controlling and managing all
aspects of IT related operations
Application
focused toward software
development, maintenance,
and product integration
broader in scope and provides a
framework for IT service
management and operations
including a hardware life cycle.
Structure
not a process but a
description of effective
process characteristics.
provides solutions on how to
undertake each process area. E.g.
how to do reqm mgnt
55
http://www.brighthubpm.com/monitoring-projects/72298-differences-in-cmmi-vs-itil/
University of Southern California
Center for Systems and Software Engineering
References
• [CSSE 2002] USC CSE Annual Research Review 2002
• [CMMI]Software Engineering Institute's CMMI website:
http://www.sei.cmu.edu/cmmi/
• [CMMIRocks] http://cmmirocks.ning.com/
• [CrossTalk 2010] CrossTalk Magazines Jan/Feb 2010
• [Garcia 2002] Suz Garcia, Are you prepared for CMMI ?
• [Garcia 2005] Suzanne Garcia, SEI CMU, Why Should you Care about CMMI?
• [Garcia 2005b] Suz Garcia, Thoughts on Applying CMMI in small settings
• [Rudge ]CMMI® : St George or the Dragon?, T. Rudge, Thales
© 2011 USC-CSSE
56
University of Southern California
Center for Systems and Software Engineering
Back up slides
© 2011 USC-CSSE
57
University of Southern California
Center for Systems and Software Engineering
When Project Planning isn’t done well…
What you’ll see…
•
•
•
•
Poor estimates that lead to cost and schedule overruns
Unable to discover deviations from undocumented plans
Resources aren’t available/applied when needed
Unable to meet commitments
Why Should You Care? Because….
• Customers don’t trust suppliers who waste their resources -loss of future business
• No lessons learned for future projects means making the
same mistakes on multiple projects
• Unhappy customers, employees ,and stockholders means a
short life for the business
• If you fail to plan then you plan to fail!
© 2011 USC-CSSE
[Ref: Garcia 2005]
58
University of Southern California
Center for Systems and Software Engineering
When Project Monitoring and Control isn’t
done well….
What you’ll see
•
•
•
•
•
Crisis management
High rework levels throughout the project
Lots of time spent in meetings trying to “discover” project status
rather than reporting on it
Data needed for management decisions is unavailable when needed
Actions that should have been taken early on aren’t discovered until
it’s too late
Why Should You Care? Because….
•
•
•
If you don’t know what’s going on, corrective action can’t be taken
early when it’s least expensive
Lack of management insight/oversight makes project results highly
unpredictable, even later in the project
If your confidence in the status you give to your customer is low,
they probably perceive that!
© 2011 USC-CSSE
[Ref: Garcia 2005]
59
University of Southern California
Center for Systems and Software Engineering
When Requirements Management isn’t done well
What you’ll see:
•
•
•
•
High levels of re-work throughout the project
Requirements accepted by staff from any source they deem to be
authoritative
“Galloping” requirements creep
Inability to “prove” that the product meets the approved
requirements
Why Should You Care? Because….
•
•
•
•
Lack of agreement among stakeholders as to what are the “real”
requirements increases time and cost to complete the
Project
You’re highly likely to deliver an incorrect or incomplete product
Revisiting requirements changes over and over is a waste of
resource highly visible to the customer
© 2011 USC-CSSE
[Ref: Garcia 2005]
60
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005]
61
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005]
62
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005]
63
University of Southern California
Center for Systems and Software Engineering
Top new 8 concepts in CMMI1.3
8. Organizational-level contracts
–
Mentioning of preferred suppliers in SAM
7. Prioritized customer requirements
–
Prioritized customer requirements in RD
6. Lifecycle needs and standards
–
Acknowledging standards e.g. ISO 12207 in OPD
5. Customer satisfaction
–
Emphasize the importance of customer satisfaction
© 2011 USC-CSSE
[Ref: CMMIRocks]
64
University of Southern California
Center for Systems and Software Engineering
Top new 8 concepts in CMMI1.3
4. Causal analysis at low levels of maturity
–
–
Explicit encouragement of using causal analysis
New: QPM-SP 2.3 Perform Root Cause Analysis
3. Teaming concepts
–
–
–
IPPD (Integrated Process and Product Development) is gone
“Teams” is not addition/optional anymore
New: IPC-SP1.6 Establish and maintain teams
© 2011 USC-CSSE
[Ref: CMMIRocks]
65
University of Southern California
Center for Systems and Software Engineering
Top new 8 concepts in CMMI1.3
2. Modernized development practices
–
–
–
Adding concepts of LOS, product line, release
increments, architecture-centric, technology
maturation
Glossary updates
Informative material updates in all three
constellations (especially in RD, REQM, VAL, and
VER) to bring more balance to functional vs. nonfunctional requirements (e.g., quality attributes)
© 2011 USC-CSSE
[Ref: CMMIRocks]
66
University of Southern California
Center for Systems and Software Engineering
Top new 8 concepts in CMMI1.3
1. Agile interpretive guidance
–
–
–
Help those who use Agile methods to interpret
CMMI
Add introductory notes about agile to the following
process areas in CM, PI, PMC, PP, PPQA, RD,
REQM, RSKM, TS, and VER.
Example: "In agile environments... Teams plan, monitor, and
adjust plans in each iteration as often as it takes (e.g., daily).
Commitments to plans are demonstrated when tasks are assigned
and accepted during iteration planning, user stories are elaborated
or estimated, and iterations are populated with tasks from a
maintained backlog of work.
© 2011 USC-CSSE
[Ref: CMMIRocks]
67
University of Southern California
Center for Systems and Software Engineering
Basic Project Management Category
Status, issues, and results of process and
product evaluations; measures and analyses
Corrective action
PMC
Corrective action
What to
monitor
n
ne
SAM
Supplier
agreement
REQM
nd o
t a o mp
c
du t c nts
Prooduc eme
pr quir
re
What to build
Replan
Status, issues,
and results of
reviews and
monitoring
Plans
t
PP
What to do
Commitments
Product and
product
component
requirements
Engineering and Support
process areas
Measurement
needs
Product component requirements, technical
issues, completed product components, and
acceptance reviews and tests
Supplier
PMC = Project Monitoring and Control
PP = Project Planning
REQM = Requirements Management
SAM = Supplier Agreement Management
© 2011 USC-CSSE
68
University of Southern California
Center for Systems and Software Engineering
Advanced Project Management Category
Statistical management data
QPM
Risk exposure due to
unstable processes
Quantitative objectives,
subprocesses to statistically
manage, project’s composed
and defined process
Organization’s standard processes,
work environment standards, and
supporting assets
RSKM
IPM
Process Management
process areas
Product architecture
for structuring teams
Project’s defined
process and work
environment
Coordination,
commitments, and issues
to resolve
Teams for performing engineering
and support processes
Engineering and Support
process areas
Risk taxonomies
and parameters,
risk status, risk
mitigation plans,
and corrective
action
Basic Project Management
process areas
IPM= Integrated Project Management
QPM = Quantitative Project Management
RSKM = Risk Management
© 2011 USC-CSSE
69
University of Southern California
Center for Systems and Software Engineering
Engineering Category
Project Management
process areas
Product and
product component
requirements
Requirements
Product
components
Alternative
solutions
TS
RD
Product
PI
Customer
Requirements
Requirements, Product
components, work products,
verification and validation reports
VER
VAL
Customer needs
PI = Product Integration
RD = Requirements Development
TS = Technical Solution
VAL = Validation
VER = Verification
© 2011 USC-CSSE
70
University of Southern California
Center for Systems and Software Engineering
Basic Support Category
Quality and
noncompliance
issues
Measurements
and analyses
MA
PPQA
All process areas
Information
needs
Controlled
configuration
items, baselines,
and audit reports
Configuration
items and
change
requests
Processes and
work products,
standards, and
procedures
CM
CM = Configuration Management
MA = Measurement and Analysis
PPQA = Process and Product Quality Assurance
© 2011 USC-CSSE
71
University of Southern California
Center for Systems and Software Engineering
Advanced Support Category
CAR
Process
improvement
proposals
Defects,
other problems,
and successes
All process areas
Selected
issues
Formal
evaluations
DAR
CAR = Causal Analysis and Resolution
DAR = Decision Analysis and Resolution
© 2011 USC-CSSE
72
University of Southern California
Center for Systems and Software Engineering
O
pr rga
an oc niz
d e ss a t
ob n io
je ee n’s
ct d
i ve s
s
Basic Process Management Category
Senior
management
Organization’s
business
objectives
Training for projects and
support groups in standard
process and assets
OT
Standard
process
and other
assets
Tra
in
ing
nee
ds
Standard process, work,
environment standards, and
other assets
OPF
Resources and
coordination
OPD
Project Management,
Support, and Engineering
process areas
Improvement information
(e.g., lessons learned, data,
and artifacts
Process improvement proposals; participation in
defining, assessing, and deploying processes
OPD = Organizational Process Definition
OPF = Organizational Process Focus
OT = Organizational Training
© 2011 USC-CSSE
73
University of Southern California
Center for Systems and Software Engineering
Advanced Process Management Category
Improvements
Organization
ce
an
m
r
rfo lity
Pe p a b i
ca
Senior
management
Business objectives
fit
ne ted
be ilo s
nd p nt
t a rom me
os f e
C ta ov
da pr
im
OPM
Quality and process
measures, baselines,
Performance objectives,
and models
OPP
Project Management,
Support, and Engineering
process areas
Quality and process
objectives
on
mm res
C o e a su
m
Ability to develop and
deploy standard process
and other assets
Performance
capability data
Basic
Process Management
process areas
OPM = Organizational Performance Management
OPP = Organizational Process Performance
© 2011 USC-CSSE
74
University of Southern California
Center for Systems and Software Engineering
CMMI vs ITIL
75
http://www.dtic.mil/ndia/2007cmmi/Tues7Mitryk_Presentation.pdf
University of Southern California
Center for Systems and Software Engineering
CMMI vs ITIL
76
http://www.dtic.mil/ndia/2007cmmi/Tues7Mitryk_Presentation.pdf
University of Southern California
Center for Systems and Software Engineering
CMMI vs ITIL
77
http://www.dtic.mil/ndia/2007cmmi/Tues7Mitryk_Presentation.pdf
University of Southern California
Center for Systems and Software Engineering
CMMI vs ITIL
78
http://www.dtic.mil/ndia/2007cmmi/Tues7Mitryk_Presentation.pdf
University of Southern California
Center for Systems and Software Engineering
Now – workshop – CMMI
Appraisal
• Form 3 groups
– Try not to team with your own team member
• Identify gap analysis between ICSM and
given process areas
– Risk Management (RSKM)
– Validation (VAL)
– Produce and Process Quality Assurance (PPQA)
• Off-campus student, pick one process area
and complete gap analysis
• Resources http://www.sei.cmu.edu/reports/10tr033.pdf
© 2011 USC-CSSE
79