CS 577b Software Engineering II -- Introduction 19 April 2017 CMMI 1.3 CS 577b Software Engineering II Supannika Koolmanojwong © 2002-6 USC Center for 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

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

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]

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]

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]

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

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

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

Example of a CMMI Process Area © 2011 USC-CSSE

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]

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]

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]

© 2011 USC-CSSE [Ref: Rudge]

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

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]

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

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

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

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

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Garcia 2002]

© 2011 USC-CSSE [Ref: Rudge]

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

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]

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]

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]

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]

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]

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]

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]

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

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

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

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

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

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

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]

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]

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]

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]

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

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]

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]

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]