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. 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. What is CMMI?
C onsultant M oney M aking I nitiative
© 2011 USC-CSSE

4. CMMI Models V1.3
CMMI® (Capability Maturity Model® Integration) models are collections of best practices that help organizations to improve their processes
© 2011 USC-CSSE
[Ref: CMMI]

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

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

7. Configuration Management (CM) Causal Analysis and Resolution (CAR)
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

8. Requirements Management Process Area
Purpose: to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.
Specific Goal 1 Requirements are managed and inconsistencies with plans and work products are identified.
Specific Practice 1.1 Develop an understanding with the requirements providers on the meaning of the requirements.
Subpractices
Establish criteria for distinguishing appropriate requirements providers.
Establish objective criteria for the evaluation and acceptance of requirements.
Analyze requirements to ensure that established criteria are met.
Reach an understanding of requirements with requirements providers so that project participants can commit to them.
SP 1.2
SP 1.5
Example Work Products
1. Lists of criteria for distinguishing appropriate requirements providers
2. Criteria for evaluation and acceptance of requirements
3. Results of analyses against criteria
4. A set of approved requirements
Examples of evaluation and acceptance criteria include the following:
Clearly and properly stated
Complete
Consistent with one another
Uniquely identified
……………………
© 2011 USC-CSSE

9. CMMI terminologies CMMI ICSM Process Area Practice Specific goal Task
Requirements Management
Project Planning
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

10. Example of a CMMI Process Area
© 2011 USC-CSSE

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

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

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

14. © 2011 USC-CSSE
[Ref: Rudge]

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

16. 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.
focus on activities for initiating and managing the acquisition of products and services to meet the needs of customers and end users.
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 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]

17. Comparison of process areas
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)
16 Core Process Areas
© 2011 USC-CSSE

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

19. Model Specific Process Areas
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)
Model Specific Process Areas
Organizational Performance Management (OPM)
Organizational Process Performance (OPP)
Organizational Training (OT)
Process and Product Quality Assurance (PPQA)
Requirements Management (REQM)
Risk Management (RSKM)
© 2011 USC-CSSE

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

21. © 2011 USC-CSSE
[Ref: Garcia 2002]

22. © 2011 USC-CSSE
[Ref: Garcia 2002]

23. © 2011 USC-CSSE
[Ref: Garcia 2002]

24. © 2011 USC-CSSE
[Ref: Garcia 2002]

25. © 2011 USC-CSSE
[Ref: Garcia 2002]

26. © 2011 USC-CSSE
[Ref: Garcia 2002]

27. © 2011 USC-CSSE
[Ref: Garcia 2002]

28. © 2011 USC-CSSE
[Ref: Rudge]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43. 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 in OPD
5. Customer satisfaction
Emphasize the importance of customer satisfaction
© 2011 USC-CSSE
[Ref: CMMIRocks]

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

45. Top new 8 concepts in CMMI1.3
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. non-functional requirements (e.g., quality attributes)
© 2011 USC-CSSE
[Ref: CMMIRocks]

46. Top new 8 concepts in CMMI1.3
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]

47. References [CSSE 2002] USC CSE Annual Research Review 2002
[CMMI]Software Engineering Institute's CMMI website:
[CMMIRocks]
[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

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

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

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