1. CS 577b Software Engineering II -- Introduction
1 June 2018
CMMI 1.3
CS 577b Software Engineering II
Supannika Koolmanojwong
© USC Center for Software Engineering

2. What is CMMI?
C onsultant M oney M aking I nitiative
© 2016 USC-CSSE

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

4. 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
© 2016 USC-CSSE
[Ref: Garcia 2005]

5. 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)
© 2016 USC-CSSE

6. 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
……………………
© 2016 USC-CSSE

7. 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
© 2016 USC-CSSE

8. Example of a CMMI Process Area
© 2016 USC-CSSE

9. 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)
© 2016 USC-CSSE

10. 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
© 2016 USC-CSSE
[Ref: Rudge]

11. Process Area Information: 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
© 2016 USC-CSSE

12. SGs and # of SGs are different from process area to process area
GGs for every process area are the same
© 2016 USC-CSSE

13. 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
© 2016 USC-CSSE

14. 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.
© 2016 USC-CSSE
[Ref: Lazaris]

15. 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
© 2016 USC-CSSE
[Ref: Lazaris]

16. 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
© 2016 USC-CSSE

17. 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
© 2016 USC-CSSE

18. 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
© 2016 USC-CSSE
[Ref: CMMI]

19. 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
© 2016 USC-CSSE
[Ref: CMMI]

20. CMMI Maturity Levels
© 2016 USC-CSSE
[Ref: Buchholtz 2003]

21. 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)
© 2016 USC-CSSE

22. 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)
© 2016 USC-CSSE

23. 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
© 2016 USC-CSSE
[Based on Ref: Rudge]

24. 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)
© 2016 USC-CSSE

25. Basic Project Management Category
© 2016 USC-CSSE

26. Advanced Project Management Category
© 2016 USC-CSSE

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

28. Engineering Category
© 2016 USC-CSSE

29. 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)
© 2016 USC-CSSE

30. Basic Support Category
© 2016 USC-CSSE

31. Advanced Support Category
© 2016 USC-CSSE

32. 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)
© 2016 USC-CSSE

33. Basic Process Management Category
© 2016 USC-CSSE

34. Advanced Process Management Category
© 2016 USC-CSSE

35. CMMI Appraisal example
Process Area Specific Goals and Specific Practices
Read the process area description and assess whether your team process comply with CMMI requirements? If yes, please state an evidence
SP 1.1 Understand Requirements
SP 1.2 Obtain Commitment to Requirements
Subpractices
Establish criteria for distinguishing appropriate requirements providers.
Establish objective criteria for the evaluation and acceptance of requirements. Lack of evaluation and acceptance criteria often results in inadequate verification, costly rework, or customer rejection.
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.
Example Work Products
Lists of criteria for distinguishing appropriate requirements providers
Criteria for evaluation and acceptance of requirements
Results of analyses against criteria
A set of approved requirements
Subpractices
Assess the impact of requirements on existing commitments.
Negotiate and record commitments.
Example Work Products
Requirements impact assessments
Documented commitments to requirements and requirements changes
© 2016 USC-CSSE

36. CMMI Appraisal example
Process Area Specific Goals and Specific Practices
Read the process area description and assess whether your team process comply with CMMI requirements? If yes, please state an evidence
SP 1.3 Manage Requirements Changes
SP 1.4 Maintain Bidirectional Traceability of Requirements
Subpractices
1. Document all requirements and requirements changes that are given to or generated by the project.
2. Maintain a requirements change history, including the rationale for changes.
Maintaining the change history helps to track requirements volatility.
3. Evaluate the impact of requirement changes from the standpoint of relevant stakeholders.
Requirements changes that affect the product architecture can affect many stakeholders.
4. Make requirements and change data available to the project.
Example Work Products
1. Requirements change requests
2. Requirements change impact reports
3. Requirements status
4. Requirements database
Subpractices
Maintain requirements traceability to ensure that the source of lower level (i.e., derived) requirements is documented.
Maintain requirements traceability from a requirement to its derived requirements and allocation to work products.
Generate a requirements traceability matrix.
Example Work Products
Requirements traceability matrix
Requirements tracking system
© 2016 USC-CSSE

37. CMMI Appraisal example
Process Area Specific Goals and Specific Practices
Read the process area description and assess whether your team process comply with CMMI requirements? If yes, please state an evidence
SP 1.5 Ensure Alignment Between Project Work and Requirements
Subpractices
Review project plans, activities, and work products for consistency with requirements and changes made to them.
Identify the source of the inconsistency (if any).
Identify any changes that should be made to plans and work products resulting from changes to the requirements baseline.
Initiate any necessary corrective actions.
Example Work Products
Documentation of inconsistencies between requirements and project plans and work products, including sources and conditions
Corrective actions
© 2016 USC-CSSE

38. CMMI Appraisal result © 2016 USC-CSSE

39. Now – workshop – CMMI Appraisal
Identify gap analysis between ICSM and given process areas
Requirements Development
Technical Solution
Configuration Management
Prepare for presentation
Off-campus student, assess Verification process area and complete gap analysis, get template on D2L
Resources
© 2016 USC-CSSE

40. 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
© 2016 USC-CSSE

41. TechTalk Date Presenter Topic Category 31-Mar Theerapat Chawannakul
Sonar Qube
Code Quality
Yutong Guo
JSHint
Static Code Analysis
David Tasky
SideKick
Code Analysis
Fereshteh Khorzani
WebLoad
Load Testing
7-Apr
Qing Wei
Cucumber
BDD
Guancheng Li
Jbehave
Vahagen Sinanian
Apache Zeppelin
Data visualization
Juan Andrade 
Apache Spark
Big Data
Dennis Xiang
Apache Solr
21-Apr
Basir Navab
Veracode
Security
Cheng Zhang
Torch
Machine Learning
Hamed Sadeghi
TensorFlow
Tatsuhiko Tomita
Sw Arch analysis method
Architecture
Steven Holland
© 2016 USC-CSSE

42. Individual Presentation
55 points
2 types – Pick one
TechTalk
Product evaluation
Individual Research Presentation
New trends in software engineering
15 minutes presentation
(C)USC-CSSE

43. Marks allocation TechTalk Research presentation 55 points 55 points
10 points : Time management
15 points : Quality of Demo Scenario
20 points : Quality of Product evaluation
10 points : Quality of Presentation
Research presentation
55 points
10 points : Time management
15 points : Contribution to SE students, interesting, soundness
20 points : Quality of Research Work
10 points : Quality of Presentation