1. University of Southern California Center for Systems and Software Engineering CMMI 1.3 CS 577b Software Engineering II Supannika Koolmanojwong

2. University of Southern California Center for Systems and Software Engineering What is CMMI? C onsultant M oney M aking I nitiative © 2011 USC-CSSE2

3. University of Southern California Center for Systems and Software Engineering CMMI Models V1.3 CMMI® (Capability Maturity Model® Integration) models are collections of best practices that help organizations to improve their processes © 2011 USC-CSSE3 [Ref: CMMI]

4. University of Southern California Center for Systems and Software Engineering 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-CSSE4 [Ref: Garcia 2005]

5. University of Southern California Center for Systems and Software Engineering 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-CSSE5

6. University of Southern California Center for Systems and Software Engineering 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 1.Establish criteria for distinguishing appropriate requirements providers. 2.Establish objective criteria for the evaluation and acceptance of requirements. 3.Analyze requirements to ensure that established criteria are met. 4.Reach an understanding of requirements with requirements providers so that project participants can commit to them. SP 1.2......... SP 1.5 © 2011 USC-CSSE6 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 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 …………………… Examples of evaluation and acceptance criteria include the following: Clearly and properly stated Complete Consistent with one another Uniquely identified ……………………

7. University of Southern California Center for Systems and Software Engineering CMMI terminologies CMMIICSM Process AreaPractice Requirements Management Project Planning System and Software Requirements Dev Practice Life Cycle Planning Practice Specific goalTask Specific practiceStep SubpracticeDetailed step Work ProductWork Product / Artifact / Output A set of approved requirementsAgreed Win Conditions © 2011 USC-CSSE7

8. University of Southern California Center for Systems and Software Engineering Example of a CMMI Process Area © 2011 USC-CSSE8

9. University of Southern California Center for Systems and Software Engineering CMMI-DEVCMMI - SVCCMMI - 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 Planning (PP) Project Monitoring and ControlWork Monitoring and Control (WMC)Project Monitoring and Control (PMC) Integrated Project ManagementIntegrated Work Management (IWM)Integrated Project Management (IPM) Quantitative Project ManagementQuantitative 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) © 2011 USC-CSSE9 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)

10. University of Southern California Center for Systems and Software Engineering Low Maturity OrganizationsHigh Maturity Organizations 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-CSSE10 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 [Ref: Rudge]

11. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE11 Process Area Information : Purpose Statement, Introductory Notes, Related Process Areas Information : Purpose Statement, Introductory Notes, Related Process Areas Specific Goals Specific Practices Example Work Products Subpractices Specific Goals Specific Practices Example Work Products Subpractices Generic Goals Generic Practices Subpractices Generic Practice Elaborations Generic Goals Generic Practices Subpractices Generic Practice Elaborations

12. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE12 GGs for every process area are the same SGs and # of SGs are different from process area to process area SGs and # of SGs are different from process area to process area

13. University of Southern California Center for Systems and Software Engineering 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-CSSE13

14. University of Southern California Center for Systems and Software Engineering 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-CSSE14 [Ref: Lazaris]

15. University of Southern California Center for Systems and Software Engineering 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-CSSE15 [Ref: Lazaris]

16. University of Southern California Center for Systems and Software Engineering Comparison of Capability and Maturity Levels Level Continuous Representation Capability Levels Staged Representation Maturity Levels Level 0Incomplete Level 1PerformedInitial Level 2Managed Level 3Defined Level 4Quantitatively Managed Level 5Optimizing © 2011 USC-CSSE16

17. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE17 Capability Level 1: Performed - accomplishes the needed work to produce work products; the specific goals of the process area are satisfied To achieve a capability level, pick a process area 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

18. University of Southern California Center for Systems and Software Engineering 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-CSSE18 [Ref: CMMI]

19. University of Southern California Center for Systems and Software Engineering 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-CSSE19 [Ref: CMMI]

20. University of Southern California Center for Systems and Software Engineering CMMI Maturity Levels © 2011 USC-CSSE20 [Ref: Buchholtz 2003]

21. University of Southern California Center for Systems and Software Engineering Categories of Process Areas © 2011 USC-CSSE21 Process AreaCategory Product Integration (PI)Engineering Requirements Development (RD)Engineering Technical Solution (TS)Engineering Validation (VAL)Engineering Verification (VER)Engineering Organizational Process Definition (OPD)Process Management Organizational Process Focus (OPF)Process Management Organizational Performance Management (OPM)Process Management Organizational Process Performance (OPP)Process Management Organizational Training (OT)Process Management Integrated Project Management (IPM)Project Management Project Monitoring and Control (PMC)Project Management Project Planning (PP)Project Management Quantitative Project Management (QPM)Project Management Requirements Management (REQM)Project Management Risk Management (RSKM)Project Management Supplier Agreement Management (SAM)Project Management Causal Analysis and Resolution (CAR)Support Configuration Management (CM)Support Decision Analysis and Resolution (DAR)Support Measurement and Analysis (MA)Support Process and Product Quality Assurance (PPQA)Support

22. University of Southern California Center for Systems and Software Engineering Process Areas by Maturity Levels © 2011 USC-CSSE22 Process AreaCategoryMaturity Level Project Monitoring and Control (PMC)Project Management2 Project Planning (PP)Project Management2 Requirements Management (REQM)Project Management2 Supplier Agreement Management (SAM)Project Management2 Configuration Management (CM)Support2 Measurement and Analysis (MA)Support2 Process and Product Quality Assurance (PPQA)Support2 Product Integration (PI)Engineering3 Requirements Development (RD)Engineering3 Technical Solution (TS)Engineering3 Validation (VAL)Engineering3 Verification (VER)Engineering3 Organizational Process Definition (OPD)Process Management3 Organizational Process Focus (OPF)Process Management3 Organizational Training (OT)Process Management3 Integrated Project Management (IPM)Project Management3 Risk Management (RSKM)Project Management3 Decision Analysis and Resolution (DAR)Support3 Organizational Process Performance (OPP)Process Management4 Quantitative Project Management (QPM)Project Management4 Organizational Performance Management (OPM)Process Management5 Causal Analysis and Resolution (CAR)Support5

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

24. University of Southern California Center for Systems and Software Engineering Categories of Process Areas © 2011 USC-CSSE24 Process AreaCategoryLevel Integrated Project Management (IPM)Project ManagementAdvanced - 3 Project Monitoring and Control (PMC)Project ManagementBasic - 2 Project Planning (PP)Project ManagementBasic - 2 Quantitative Project Management (QPM)Project ManagementAdvanced - 4 Requirements Management (REQM)Project ManagementBasic - 2 Risk Management (RSKM)Project ManagementAdvanced - 3 Supplier Agreement Management (SAM)Project ManagementBasic - 2

25. University of Southern California Center for Systems and Software Engineering Basic Project Management Category © 2011 USC-CSSE25

26. University of Southern California Center for Systems and Software Engineering Advanced Project Management Category © 2011 USC-CSSE26

27. University of Southern California Center for Systems and Software Engineering Categories of Process Areas © 2011 USC-CSSE27 Process AreaCategoryLevel Product Integration (PI)Engineering3 Requirements Development (RD)Engineering3 Technical Solution (TS)Engineering3 Validation (VAL)Engineering3 Verification (VER)Engineering3

28. University of Southern California Center for Systems and Software Engineering Engineering Category © 2011 USC-CSSE28

29. University of Southern California Center for Systems and Software Engineering Categories of Process Areas © 2011 USC-CSSE29 Process AreaCategoryLevel Causal Analysis and Resolution (CAR)SupportAdvanced - 5 Configuration Management (CM)SupportBasic - 2 Decision Analysis and Resolution (DAR)SupportAdvanced - 3 Measurement and Analysis (MA)SupportBasic - 2 Process and Product Quality Assurance (PPQA)SupportBasic - 2

30. University of Southern California Center for Systems and Software Engineering Basic Support Category © 2011 USC-CSSE30

31. University of Southern California Center for Systems and Software Engineering Advanced Support Category © 2011 USC-CSSE31

32. University of Southern California Center for Systems and Software Engineering Categories of Process Areas © 2011 USC-CSSE32 Process AreaCategoryLevel Organizational Process Definition (OPD)Process ManagementBasic - 3 Organizational Process Focus (OPF)Process ManagementBasic - 3 Organizational Performance Management (OPM)Process ManagementAdvanced - 5 Organizational Process Performance (OPP)Process ManagementAdvanced - 4 Organizational Training (OT)Process ManagementBasic - 3

33. University of Southern California Center for Systems and Software Engineering Basic Process Management Category © 2011 USC-CSSE33

34. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE34 Advanced Process Management Category

35. University of Southern California Center for Systems and Software Engineering Next time Comparison to other standards –ISO/IEEE –Six Sigma –Lean Six Sigma –ITIL © 2011 USC-CSSE35

36. University of Southern California Center for Systems and Software Engineering Now – workshop – CMMI Appraisal Form 3 groups –Try not to team with your own team member Identify gap analysis between ICSM and given process areas –Risk Management (RSKM) –Validation (VAL) –Produce and Process Quality Assurance (PPQA) Off-campus student, pick one process area and complete gap analysis Resources http://www.sei.cmu.edu/reports/10tr033.pdf © 2011 USC-CSSE36

37. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE37

38. University of Southern California Center for Systems and Software Engineering References [CSSE 2002] USC CSE Annual Research Review 2002 [CMMI]Software Engineering Institute's CMMI website: http://www.sei.cmu.edu/cmmi/ http://www.sei.cmu.edu/cmmi/ [CMMIRocks] http://cmmirocks.ning.com/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-CSSE38

39. University of Southern California Center for Systems and Software Engineering Back up slides © 2011 USC-CSSE39

40. University of Southern California Center for Systems and Software Engineering 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-CSSE40 [Ref: Garcia 2005]

41. University of Southern California Center for Systems and Software Engineering 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-CSSE41 [Ref: Garcia 2005]

42. University of Southern California Center for Systems and Software Engineering 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-CSSE42 [Ref: Garcia 2005]

43. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE43 [Ref: Garcia 2005]

44. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE44 [Ref: Garcia 2005]

45. University of Southern California Center for Systems and Software Engineering © 2011 USC-CSSE45 [Ref: Garcia 2005]

46. University of Southern California Center for Systems and Software Engineering 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-CSSE46 [Ref: CMMIRocks]

47. University of Southern California Center for Systems and Software Engineering 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-CSSE47 [Ref: CMMIRocks]

48. University of Southern California Center for Systems and Software Engineering Top new 8 concepts in CMMI1.3 2.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-CSSE48 [Ref: CMMIRocks]

49. University of Southern California Center for Systems and Software Engineering Top new 8 concepts in CMMI1.3 1.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-CSSE49 [Ref: CMMIRocks]