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
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
2
University of Southern California
Center for Systems and Software Engineering
What is CMMI?
C onsultant
M oney
M aking
I nitiative
© 2011 USC-CSSE
3
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]
4
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
© 2011 USC-CSSE
[Ref: CrossTalk2010]
5
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]
6
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
7
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
8
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
9
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
10
University of Southern California
Center for Systems and Software Engineering
How is CMMI Different from Other
Process Reference Models?
In contrast to most other reference models used for process
improvement, CMMI:
• Emphasizes and supports improving processes through
institutionalization practices
– These are called generic practices
– These are practices that can be applied to any process of
interest in an evolutionary fashion
• Emphasizes changes in observable behavior
• Emphasizes evolution, not just binary compliance
• Adoption isn’t “all or nothing”; pieces of the model
can be applied individually to accrue particular
business benefits
© 2011 USC-CSSE
[Ref: Garcia 2005]
11
University of Southern California
Center for Systems and Software Engineering
What Is Institutionalization?
Institutionalization involves implementing practices
that
• Ensure processes can be communicated about
(they are defined, documented, understood)
• Ensure the processes are effective, repeatable
and lasting
• Provide needed infrastructure support
• Enable organizational learning to improve the
process
© 2011 USC-CSSE
[Ref: Garcia 2005]
12
University of Southern California
Center for Systems and Software Engineering
Why is Institutionalization Important?
Without institutionalization
• Process improvement may not relate to business goals
• Processes will not be executed or managed consistently
• The processes will not survive staff or leadership changes
• The organization will find itself continuously “reinventing the
wheel”
• Commitment to provide resources or infrastructure to
support or improve the processes will be missing or
insufficient
• Historical data will not be useful to support future projects
© 2011 USC-CSSE
[Ref: Garcia 2005]
13
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Rudge]
14
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
15
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
• CMMI for Acquisition (CMMI-ACQ), provides a comprehensive
integrated set of guidelines for acquiring products and services.
–
•
CMMI for Development (CMMI-DEV) provides a comprehensive
integrated set of guidelines for developing products and services.
–
•
focus on activities for developing quality products and services to meet the needs
of customers and end users
CMMI for Services (CMMI-SVC) provides a comprehensive
integrated set of guidelines for providing superior services
–
•
•
focus on activities for initiating and managing the acquisition of products and
services to meet the needs of customers and end users.
focus on activities for providing quality services to customers and end users.
CMMI-SVC : best practices for providing services
CMMI-DEV : for the development of the service system
© 2011 USC-CSSE
[Ref: CMMI]
16
University of Southern California
Center for Systems and Software Engineering
Comparison of process areas
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 Management (SAM)
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)
Agreement Management (AM)
Acquisition Requirements Development
(ARD)
Acquisition Technical Management (ATM)
Acquisition Validation (AVAL)
Acquisition Verification (AVER)
Solicitation and Supplier Agreement
Development (SSAD)
16 Core Process Areas
© 2011 USC-CSSE
17
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)
18
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)
Project Planning (PP)
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)
Work Planning
(WP)
Planning (PP)
Model
Specific
Process Project
Areas
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 Management (SAM)
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)
19
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
20
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
21
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
22
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
23
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
24
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
25
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
26
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2002]
27
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Rudge]
28
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
29
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]
30
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]
31
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]
32
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]
33
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]
34
University of Southern California
Center for Systems and Software Engineering
An improvement initiative must be
managed as a project
A customer
Sponsorship of the Top Management
Objective
Clear identification of business objective and
improvement scope
Responsibilities
A project leader and people involved Activities
Definition / improvement of practices Deployment
Training
Budget / schedule
Estimation / Tracking of cost and delay
Milestones
Tracking of the actions Regular mini-assessments
Final Acceptance
Official assessment
Product
Change of culture and practices on projects and in
the organization
© 2011 USC-CSSE
[Ref: USC ARR 2002]
35
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]
36
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
37
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005b]
38
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005b]
39
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005b]
40
University of Southern California
Center for Systems and Software Engineering
© 2011 USC-CSSE
[Ref: Garcia 2005b]
41
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
42
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]
43
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]
44
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]
45
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]
46
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
47
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]
48
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]
49
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]
50