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

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

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]

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]

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

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

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

Example of a CMMI Process Area © 2016 USC-CSSE

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

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]

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

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

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

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]

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]

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

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

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]

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]

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

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

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

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]

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

Basic Project Management Category © 2016 USC-CSSE

Advanced Project Management Category © 2016 USC-CSSE

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

Engineering Category © 2016 USC-CSSE

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

Basic Support Category © 2016 USC-CSSE

Advanced Support Category © 2016 USC-CSSE

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

Basic Process Management Category © 2016 USC-CSSE

Advanced Process Management Category © 2016 USC-CSSE

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

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

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

CMMI Appraisal result © 2016 USC-CSSE http://www.trinity-cmmi.co.uk/CMMI_Factfiles/SCAMPI_Appraisals.htm

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 http://www.sei.cmu.edu/reports/10tr033.pdf © 2016 USC-CSSE

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

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

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

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