Transcript No Slide Title

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
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)
2
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
•
•
What is CMMI ?
CMMI 1.3 : ACQ, DEV, SVC
What will CMMI mean to stakeholders ?
CMMI vs Agile
CMMI for small company
New concepts for CMMI 1.3
© 2011 USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Differences
• “Core Values”
CMMI
 Measure and Improve Process
[Better Process

Better Product]
 People Characteristics
- Disciplined
- Follow Rules
- Risk Averse
 Communication
- Organizational
- Macro
 Knowledge Management
- Process Assets
AGILE METHODS
 Customer Responses
 Minimal Overhead
 Requirements Refinement
- Metaphor
- Business Case
 People Characteristics
- Comfortable
- Creative
- Risk Takers
 Communication
- Person to Person
- Micro
 Knowledge Management
- People
© 2011 USC-CSSE
[Ref: USC ARR 2002]
4
University of Southern California
Center for Systems and Software Engineering
Differences
• “Characteristics”
CMMI
AGILE METHODS
 Improve Organizationally
-Uniformity
-Leveling
 Improve within Project
- Oral Tradition
- Innovation
 Capability/Maturity
- Success by Predictability
 Capability/Maturity
- Success by Realizing
Opportunities
 Body of Knowledge
- Cross-Dimensional
- Standardized
 Body of Knowledge
- Personal
- Evolving
- Temporal
 Shortcutting Rules
- Discouraged
 Shortcutting Rules
- Encouraged
© 2011 USC-CSSE
[Ref: USC ARR 2002]
5
University of Southern California
Center for Systems and Software Engineering
Differences
• “Characteristics”
CMMI
AGILE METHODS
 Committees
 Individuals
 Customer Trust
- In Process Infrastructure
 Front Loaded
- Move to Right
 Scope of View
[Stakeholder, Product]
- Broad
- Inclusive
- Organizational
 Level of Discussion
- Words
- Definitions
- Enduring
- Comprehensive
 Customer Trust
- Working SW, Participants
 Test Driven
- Move to Left
 Scope of View
[Stakeholder, Product]
- Small
- Focused
 Level of Discussion
- Job at Hand
© 2011 USC-CSSE
[Ref: USC ARR 2002]
6
University of Southern California
Center for Systems and Software Engineering
Differences
• “Approach”
CMMI
AGILE METHODS
 Descriptive
 Prescriptive
 Quantitative
- Hard Scientific Numbers
 Qualitative
- Tacit Knowledge
 Universality
 Situational
 Activities
 Product
 Strategic
 Tactical
 “What do we call it?”
 “Just do it!”
 Risk Management
- Proactive
 Risk Management
- Reactive
© 2011 USC-CSSE
[Ref: USC ARR 2002]
7
University of Southern California
Center for Systems and Software Engineering
Differences
• “Focus”
CMMI
AGILE METHODS
 Business Focus
- Internal
- Rules
 Business Focus
- External
- Innovation
 Predictability
 Performance
 Stability
 Speed
• “Challenge”
CMMI
 Scaling Down
- Doable, but difficult
AGILE METHODS
 Scaling Up
- Undefined
© 2011 USC-CSSE
[Ref: USC ARR 2002]
8
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]
9
University of Southern California
Center for Systems and Software Engineering
Process Area
Informative:
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
10
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
11
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
12
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]
13
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]
14
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
15
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
16
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]
17
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]
18
University of Southern California
Center for Systems and Software Engineering
CMMI Maturity Levels
© 2011 USC-CSSE
[Ref: Buchholtz 2003]
19
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
20
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
21
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]
22
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
23
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
24
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
25
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
26
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
27
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
28
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
29
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
30
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
31
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
32
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
33
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]
34
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]
35
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]
36
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005]
37
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005]
38
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005]
39