1. CS 577b Software Engineering II -- Introduction
19 April 2017
CMMI 1.3
CS 577b Software Engineering II
Supannika Koolmanojwong
© USC Center for Software Engineering

2. CMMI-DEV CMMI - SVC CMMI - ACQ
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)
Work Planning (WP)
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)
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Process and Product Quality Assurance (PPQA)
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
© 2011 USC-CSSE

3. 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

4. Differences “Core Values” CMMI AGILE METHODS
 Measure and Improve Process
[Better Process 
Better Product]
 Customer Responses
 Minimal Overhead
 Requirements Refinement
- Metaphor
- Business Case
 People Characteristics
- Disciplined
- Follow Rules
- Risk Averse
- Comfortable
- Creative
- Risk Takers
 Communication
- Organizational
- Macro
- Person to Person
- Micro
 Knowledge Management
- Process Assets
- People
© 2011 USC-CSSE
[Ref: USC ARR 2002]

5. Differences “Characteristics” CMMI AGILE METHODS
 Improve Organizationally
-Uniformity
-Leveling
 Improve within Project
- Oral Tradition
- Innovation
 Capability/Maturity
- Success by Predictability
- Success by Realizing Opportunities
 Body of Knowledge
- Cross-Dimensional
- Standardized
- Personal
- Evolving
- Temporal
 Shortcutting Rules
- Discouraged
- Encouraged
© 2011 USC-CSSE
[Ref: USC ARR 2002]

6. Differences “Characteristics” CMMI AGILE METHODS  Committees
 Individuals
 Customer Trust
- In Process Infrastructure
- Working SW, Participants
 Front Loaded
- Move to Right
 Test Driven
- Move to Left
 Scope of View
[Stakeholder, Product]
- Broad
- Inclusive
- Organizational
- Small
- Focused
 Level of Discussion
- Words
- Definitions
- Enduring
- Comprehensive
- Job at Hand
© 2011 USC-CSSE
[Ref: USC ARR 2002]

7. 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
- Reactive
© 2011 USC-CSSE
[Ref: USC ARR 2002]

8. Differences “Focus” “Challenge” CMMI AGILE METHODS  Business Focus
- Internal
- Rules
- External
- Innovation
 Predictability
 Performance
 Stability
 Speed
CMMI        
AGILE METHODS 
 Scaling Down
- Doable, but difficult
 Scaling Up
- Undefined
© 2011 USC-CSSE
[Ref: USC ARR 2002]

9. Low Maturity Organizations High 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
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. Process Area Informative: Specific Goals Generic Goals
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. SGs and # of SGs are different from process area to process area
GGs for every process area are the same
© 2011 USC-CSSE

12. 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. 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. 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. Comparison of Capability and Maturity Levels
Continuous Representation
Capability Levels
Staged Representation
Maturity Levels
Level 0
Incomplete
Level 1
Performed
Initial
Level 2
Managed
Level 3
Defined
Level 4
Quantitatively Managed
Level 5
Optimizing
© 2011 USC-CSSE

16. 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 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

17. 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. 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. CMMI Maturity Levels
© 2011 USC-CSSE
[Ref: Buchholtz 2003]

20. Categories of Process Areas
Category
Product Integration (PI)
Engineering
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Organizational Process Definition (OPD)
Process Management
Organizational Process Focus (OPF)
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Integrated Project Management (IPM)
Project Management
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)
Support
Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
© 2011 USC-CSSE

21. Process Areas by Maturity Levels
Category
Maturity Level
Project Monitoring and Control (PMC)
Project Management 2
Project Planning (PP)
Requirements Management (REQM)
Supplier Agreement Management (SAM)
Configuration Management (CM)
Support
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Product Integration (PI)
Engineering 3
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
Organizational Process Definition (OPD)
Process Management
Organizational Process Focus (OPF)
Organizational Training (OT)
Integrated Project Management (IPM)
Risk Management (RSKM)
Decision Analysis and Resolution (DAR)
Organizational Process Performance (OPP) 4
Quantitative Project Management (QPM)
Organizational Performance Management (OPM) 5
Causal Analysis and Resolution (CAR)
© 2011 USC-CSSE

22. CMMI Process Areas (Staged)
Level
Project Management
Engineering
Support
Process Management
5 Optimizing
CAR: Causal Analysis and Resolution
OPM: Organizational Performance Management
4 Quantitatively Managed
QPM: Quantitative Project Management
OPP: Organizational Process Performance
3 Defined
IPM: Integrated Project Management
RSKM: Risk Management
RD: Requirements Development
TS: Technical Solution
PI: Product Integration
VER: Verification
VAL: Validation
DAR: Decision Analysis and Resolution
OPF: Organizational Process Focus
OPD: Organizational Process Definition
OT: Organizational Training
2 Managed
PP: Project Planning
PMC: Project Monitoring and Control
SAM: Supplier Agreement Management
REQM: Requirements Management
MA: Measurement and Analysis
PPQA: Process & Product Quality Assurance
CM: Configuration Management
1 Initial
© 2011 USC-CSSE
[Based on Ref: Rudge]

23. Categories of Process Areas
Category
Level
Integrated Project Management (IPM)
Project Management
Advanced - 3
Project Monitoring and Control (PMC)
Basic - 2
Project Planning (PP)
Quantitative Project Management (QPM)
Advanced - 4
Requirements Management (REQM)
Risk Management (RSKM)
Supplier Agreement Management (SAM)
© 2011 USC-CSSE

24. Basic Project Management Category
© 2011 USC-CSSE

25. Advanced Project Management Category
© 2011 USC-CSSE

26. Categories of Process Areas
Category
Level
Product Integration (PI)
Engineering 3
Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)
© 2011 USC-CSSE

27. Engineering Category
© 2011 USC-CSSE

28. Categories of Process Areas
Category
Level
Causal Analysis and Resolution (CAR)
Support
Advanced - 5
Configuration Management (CM)
Basic - 2
Decision Analysis and Resolution (DAR)
Advanced - 3
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
© 2011 USC-CSSE

29. Basic Support Category
© 2011 USC-CSSE

30. Advanced Support Category
© 2011 USC-CSSE

31. Categories of Process Areas
Category
Level
Organizational Process Definition (OPD)
Process Management
Basic - 3
Organizational Process Focus (OPF)
Organizational Performance Management (OPM)
Advanced - 5
Organizational Process Performance (OPP)
Advanced - 4
Organizational Training (OT)
© 2011 USC-CSSE

32. Basic Process Management Category
© 2011 USC-CSSE

33. Advanced Process Management Category
© 2011 USC-CSSE

34. 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]

35. 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]

36. 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]

37. © 2011 USC-CSSE
[Ref: Garcia 2005]

38. © 2011 USC-CSSE
[Ref: Garcia 2005]

39. © 2011 USC-CSSE
[Ref: Garcia 2005]