6. Capability Maturity Model Integration (CMMI)

1. 6. Capability Maturity Model Integration (CMMI) 2007

2. Kõrgküpsed organisatsioonid 2003 • 2003. a. seisuga oli 197 kõrgküpset organisatsiooni: • 100 neljanda taseme ja • 97 viienda taseme organisatsiooni • väljaspool USA-d oli 98 kõrgküpset organisatsiooni Indias (kusjuures 2001. aastal oli neid vaid 69. 2000. a. 24!), • Motorola Global Software Group – Krakow 5s tase

3. Kõrgküpsed organisatsioonid 2003 • 2003. aastal lisandus vaid 4 neljanda ja 4 viienda taseme organisatsiooni – oli alanud CMMI ajastu

4. CMMI High Level Organizations Feb 2004

5. CMMI Published Level 5 Organizations • Blue Star Infotech Limited,Mumbai, India • GE Capital International Services - Software, Hyderabad & Gurgaon Development Centers, India • Infosys Technologies Limited Development Centre in Chennai • Larsen & Toubro Limited, EmSyS,Mysore, India • Lockheed Martin Management & Data Systems (M&DS) King of Prussia, Pennsylvania • SSI TECHONOLOGIES (SSIT) A DIVISION OF SSI LIMITED CHENNAI, INDIA • Wipro Technologies Doddkannelli, Sarjapur Road Bangalore • Wipro technologies is world's first CMMI Level 5 Ver1.1 organization • http://www.prdomain.com/companies/w/wipro/news_releases/200205may/pr_wipro_20020530.htm

6. CMMI Published Level 4 Organizations • IBM Japan, Ltd., IBM Global Services Japan, Public Sector Services 19-21, Nihonbashi Hakozaki-cho Chuo-ku, Tokyo 103-8510 Japan • Digital Design, Software Development Department, St. Petersburg, Russia • Digital Design sets the standard by becoming the first Russian software company to successfully undergo a formal CMMI assessment. • Hitachi Software Engineering Co.,Ltd., Financial Systems Group, 4-12-6 Higashishinagawa Shinagawa-ku, Tokyo 140-0002 Japan • (1)Hitachi Software achieved CMMI Level 3 in all the business groups. (2)Achieved CMMI Level 3 at the whole company level. • Hitachi Software Engineering Co.,Ltd., Government & Public Corporation Systems Division, 4-12-6 Higashishinagawa Shinagawa-ku, Tokyo 140-0002 Japan • Hitachi Software Engineering Co.,Ltd., Software Development Division, Tokyo Japan • Nihon Unisys, Ltd., Financial, Koto-ku, Tokyo, Japan • Northrop Grumman Mission Systems, Command, Control and Intelligence Division, Omaha Site • Northrop Grumman Mission Systems, Tactical Systems Division • Rockwell Collins Government Systems • Soza & Company, Ltd

7. CMM-i probleemid • Kuna CMM-i tasemed 4 ja 5 on (peaaegu) kättesaamatud, siis on enamiku organisatsioonide eesmärgiks küpsustaseme 3 saavutamine. • Oluliseks küpsustaseme saavutamise instrumendiks on reglementeeritud hindamisprotsess – Software Capability Evaluation (SCE), mis määrab kindlaks, kas organisatsioon „räägib, mis teeb ja teeb, mis räägib“. • Pisut teisiti: kas organisatsiooni toimimine on poliitikate, direktiivide jmt määratletud ja kas ka tegelikult nendest määratlustest kinni peetakse. • Protsessi võtmealad (KPA) on suunatud traditsioonilisele kosemudelile vastava protsessi toimingutele ja toiminguid kajastavatele tulemitele (artifacts): • nõudmiste spetsifikatsioonid, • dokumenteeritud plaanid, • kvaliteedi auditi protokollid, • dokumenteeritud protsessid ja protseduurid.

8. CMM-i probleemid • Tarkvaraprotsessi tegelikku eesmärki – töötavat süsteemi – määratlevaid/tagavaid tulemeid • süsteemi arhitektuur, • kavandimudelid, • lähtekood, • süsteemi evitamine jmt protsessi võtmealad ei käsitle. • CMM ületähtsustab mitmesuguseid traditsioonilisi kvaliteedi tagamise meetmeid (spetsifikatsioonide, kavandi, koodi ülevaatusi jmt), mis pole piisavad tarkvara protsessi edukuseks.

9. CMM-i probleemid • CMM-i rakendamisel hakkab organisatsioon looma (tootma?) järjest enam dokumentatsiooni, koostama plaane, kehtestama kontrollpunkte jne – mida paksem dokumentatsioon ja mida pikemad nõupidamised, seda parem. • Samal ajal on karmistunud konkurentsiõhkkonnas vaja luua tarkvara kiiremini, odavamalt, selleks on aga vaja minimeerida „mittemasina“ (=inimese) poolt koostatavaid dokumente jt abi-/vahetulemeid.

10. CMM-i probleemid • Probleemiks on ka organisatsiooni küpsuse mõõtmine. • CMM kasutab toimingupõhist küpsuse mõõtmist: kui te viite läbi ettenähtud toimingud projektis, siis olete tasemel 2. • Kui te viite läbi ettenähtud toimingud organisatsiooni ulatuses, siis olete tasemel 3. Ja nii edasi. • Pole midagi, mis näitaks/iseloomustaks/mõõdaks, kui hästi (missuguse kvaliteediga) te neid toiminguid teostate. • Täiendavalt oleks vaja organisatsiooni küpsuse tulemipõhist mõõtmist: kui te suudate korrata tarkvaprotsessi ennustatava maksumuse, kvaliteedi ja ajagraafikuga – siis olete näiteks tasemel 2. • Kui te aga suudate järgnevates projektides ühte mõõtmetest (maksumus, kvaliteet, ajagraafik) parandada, siis olete tasemel 3 jne. • Kombineerides toimingupõhise ja tulemipõhise küpsuse mõõtmise saame adekvaatsemalt määrata organisatsiooni tarkvaraprotsessi taset.

11. CMM-i probleemid • Kosemudelil tuginev nõuetepõhine tarkvara kvaliteedi hindamine teeb spetsifikatsiooni järgimise olulisemaks kliendi tegelike vajaduste rahuldamisest (pole haruldane, et klient ei suuda esialgu nõudeid korrektselt spetsifitseerida, ka võivad kliendi vajadused aja jooksul muutuda). • CMM-i erinevad standardid (CMM for Software (SW-CMM), People CMM (P‑CMM), SA-CMM (CMM for Software Acquisition), Systems Engineering Capability Model (SECM) jt) on osaliselt kattuvad (nt projektijuhtimise metoodika, nõuete spetsifitseerimine, protsessi määratlus), isegi vasturääkivad.

12. Roots of CMMI

13. Intro • U.S. Department of Defense—specifically, the Deputy Under Secretary of Defense (Science and Technology)—teamed up with the National Defense Industrial Association (NDIA) to jointly sponsor the development of Capability Maturity Model Integration (CMMI). • Working with the Software Engineering Institute (SEI) at Carnegie Mellon University, this effort produced the first integrated CMMI models in 2000, together with associated appraisal and training materials; 2002 saw the release of CMMI version 1.1.

14. Intro • CMMI provides guidance for your managerial processes. • CMMI guidance on technical matters includes ways to develop, elaborate, and manage requirements, and to develop technical solutions that meet those requirements.

15. Process Improvement • The improvement information in CMMI models includes the creation of a viable, improvable process infrastructure. • Processes need to be planned just like projects, and it helps if the organization has given some weight and validity to it through policy. • You need to make sure that resources are available for trained, empowered people to perform the process. • Processes become more capable when they are standardized across the organization and their performance is monitored against historical data.

16. Produce quality products or services • The process-improvement concept in CMMI models evolved out of the Deming, Juran, and Crosby quality paradigm: • Quality products are a result of quality processes • CMMI has a strong focus on quality-related activities including requirements management, quality assurance, verification, and validation.

17. Create value for the stockholders • Mature organizations are more likely to make better cost and revenue estimates than those with less maturity, and then perform in line with those estimates. • CMMI supports quality products, predictable schedules, and effective measurement to support management in making accurate and defensible forecasts. • This process maturity can guard against project performance problems that could weaken the value of the organization in the eyes of investors.

18. Be an employer of choice • Watts Humphrey has said, "Quality work is not done by accident; it is done only by skilled and motivated people."[1] • CMMI emphasizes training, both in disciplines and in process. • Experience has shown that organizations with mature processes have far less turnover than immature organizations. [1] Humphrey, W. Winning with Software, Boston: Addison-Wesley, 2002

19. Implement cost savings and best practices • Processes that are documented, measured, and continuously improved are perfect candidates for becoming best practices, resulting in cost savings for the organization. • CMMI encourages measurement as a managerial tool. • By using the historical data collected to support schedule estimation, an organization can identify and widely deploy practices that work, and eliminate those that don't.

20. Gain an industry-wide recognition for excellence • The best way to develop a reputation for excellence is to consistently perform well on projects, delivering quality products and services within cost and schedule parameters. • Having processes that conform to CMMI requirements can enhance that reputation.

21. CMMI Milestones • 1997- CMMI initiated by U.S. Department of Defense and NDIA • 1998- First team meeting held • 1999- First pilot completed • 2000: • CMMI-SE/SW version 1.0 released for initial use • CMMI-SE/SW/IPPD version 1.0 released for initial use • CMMI-SE/SW/IPPD/SS version 1.0 released for piloting • 2002: • CMMI-SE/SW version 1.1 released • CMMI-SE/SW/IPPD version 1.1 released • CMMI-SE/SW/IPPD/SS version 1.1 released • CMMI-SW version 1.1 released

22. SE SW Industry CMMI Product Suite IPPD ... SEI Government Assess Training CMMI- SE/SW • Team of Teams • Modeling and Discipline Experts • Collaborative Process Acquisition ... CMMI- SE/SW/ IPPD CMMI- SE/SW/ IPPD/SA The CMMI Product Line Approach Software- SW-CMM, draft version 2(c) Systems Engineering- EIA/IS 731 Integrated Product and Process Development- IPD-CMM, version 0.98 Supplier Sourcing (SS)

23. Content of CMMI

24. Buyer/Supplier Mismatch Mismatch Matched Team • match of skills, maturity • team risk approach • execution to plan • measurable performance • quantitative management • highest probability of success Acquirer • mature buyer must mentor low maturity developer • outcome not predictable Mismatch Disaster • constant crises • no req’s mgt. • no risk mgt. • no discipline • no process. . . • no product • “Customer is always right” hurts. • Customer encourages “short cuts.” increasing Management Capability Level increasing Developer

25. One Model, Two Representations Appendixes Appendixes Support CM, PPQA, MA, CAR, DAR Maturity Level 5 OID, CAR Maturity Level 4 OPP, QPM Engineering REQM, REQD, TS, PI, VER, VAL Maturity Level 3 REQD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR Project Management PP, PMC, SAM IPM, RSKM, QPM Maturity Level 2 REQM, PP, PMC, SAM, MA, PPQA, CM Process Management OPF, OPD, OT, OPP, OID Overview Introduction Structure of the Model Model Terminology Maturity Levels, Common Features, and Generic Practices Understanding the Model Using the Model Overview Introduction Structure of the Model Model Terminology Capability Levels and Generic Model Components Understanding the Model Using the Model Process Management PAs - Goals - Practices CMMI-SE/SW Staged CMMI-SE/SW Continuous

26. CMMI-SE/SW/IPPD/A - Continuous CMMI Engineering Support Process Management Project Management • Organizational Process Focus • Organizational Process • Definition • Organizational Training • Organizational Process • Performance • Organizational Innovation and Deployment • Project Planning • Project Monitoring and • Control • Supplier Agreement Mgmt. • Integrated Project Mgmt. • Risk Management • Quantitative Project Mgmt. • Requirements Management • Requirements Development • Technical Solution • Product Integration • Verification • Validation • Configuration Mgmt. • Process and Product • Quality Assurance • Measurement & Analysis • Decision Analysis and • Resolution • Causal Analysis and • Resolution Acquisition IPPD • Supplier Selection and Monitoring • Integrated Supplier Management • Quantitative Supplier Management • Organizational Environment • for Integration • Integrated Team

27. Quantitatively Managed (4) Optimizing (5) Defined (3) Managed (2) Initial (1) CMMI-SE/SW/IPPD/A - Staged Focus • Organizational Innovation and Deployment (OID) • Causal Analysis and Resolution (CAR) Continuous Process Improvement (2 PAs) • Organizational Process Performance (OPP) • Quantitative Project Management (QPM) Quantitative Management (2 PAs) • Quantitative Supplier • Management (QSM) • Requirements Development (RD) • Technical Solution (TS) • Product Integration (PI) • Verification (VER) • Validation (VAL) • Organizational Process Focus (OPF) • Organizational Process Definition (OPD) • Organization Training (OT) • Integrated Project Management (IPM) * • Risk Management(RSKM) • Decision Analysis and Resolution (DAR) • Organization Environment • for Integration (OEI) • Integrated Team (IT) Process Standardization (11 PAs) • Integrated Supplier • Management (ISM) Basic Project Management (7 PAs) • Requirements Management (REQM) • Project Planning (PP) • Project Monitoring and Control (PMC) • Supplier Agreement Management (SAM) • Measurement and Analysis (M&A) • Process and Product Quality Assurance (PPQA) • Configuration Management (CM) • Supplier Selection and • Monitoring (SSM) * Additional PA goals and activities added for IPPD Ad hoc, chaotic processes

28. Process Areas • CMMI selects only the most important topics for process improvement and then groups those topics into "areas." • This classification results in CMMI version 1.1 models with a relatively small set of process areas: • 22 in CMMI-SE/SW and CMMI-SW, • 24 in CMMI-SE/SW/IPPD, • and 25 in CMMI-SE/SW/IPPD/SS.

29. CMMI Process Area Contents • Purpose • Introductory Notes • Goals: Specific and Generic • Generic Practices • Specific Practices • Notes • Work Products • Subpractices • Amplifications • Elaborations Required Expected Informative

30. Content Classification • Any process-improvement model must, of necessity, include a scale relating to the importance and role of the materials contained in the model. • In the CMMI models, a distinction is drawn between the terms "required," "expected," and "informative."

31. Required Materials • The sole required component of the CMMI models is the "goal." • A goal represents a desirable end state, the achievement of which indicates that a certain degree of project and process control has been achieved. • When a goal is unique to a single process area, it is called a "specific goal" (SG). • In contrast, when a goal may apply across all of the process areas, it is called a "generic goal" (GG).

32. Specific Goals - Requirements Management • REQM SG 1: Requirements are managed and inconsistencies with project plans and work products are identified.

33. Specific Goals - Project Monitoring and Control • PMC SG 2: Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.

34. Specific Goals - Organizational Process Performance • OPP SG 1: Baselines and models that characterize the expected process performance of the organization's set of standard processes are established and maintained.

35. Specific Goals - Causal Analysis and Resolution • CAR SG 2: Root causes of defects and other problems are systematically addressed to prevent their future occurrence.

36. Expected Materials • The only expected component of the CMMI models is the statement of a "practice." • A practice represents the "expected" means of achieving a goal. • Every practice in the CMMI models is mapped to exactly one goal. • A practice is not a required component, however; a specific organization may possess demonstrated means of achieving a goal that do not rely on the performance of all the practices that are mapped to that goal. • That is, "alternative" practices may provide an equally useful way of reaching the goal.

37. Expected Materials • When a practice is unique to a single process area, it is called a "specific practice" (SP). • When a practice may apply across all of the process areas, it is called a "generic practice" (GP).

38. Specific Goal REQM SG 1: Requirements are managed and inconsistencies with project plans and work products are identified. Specific Practice REQM SP 1.1-1: Develop an understanding with the requirements providers on the meaning of the requirements. Specific Practices Associated with Specific Goals

39. Specific Goal PMC SG 2: Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan. Specific Practice PMC SP 2.1-1: Collect and analyze the issues and determine the corrective actions necessary to address the issues. Specific Practices Associated with Specific Goals

40. Specific Goal OPP SG 1: Baselines and models that characterize the expected process performance of the organization's set of standard processes are established and maintained. Specific Practice OPP SP 1.2-1: Establish and maintain definitions of the measures that are to be included in the organization's process performance analyses. Specific Practices Associated with Specific Goals

41. Specific Goal CAR SG 2: Root causes of defects and other problems are systematically addressed to prevent their future occurrence. Specific Practice CAR SP 2.2-1: Evaluate the effect of changes on process performance. Specific Practices Associated with Specific Goals

42. Informative Materials • Purpose • Introductory Note • Reference • Names • Practice-to-Goal Relationship Table • Notes • Typical Work Products • Subpractices • Discipline Amplifications • Generic Practice Elaborations

43. Document Map

44. CMMI Representations

45. Staged Continuous ML5 ML4 Capability 0 1 2 3 4 5 ML3 ML2 ML 1 PA PA PA Organization Process CMMI Model Representations

46. Expected Required CMMI Model Structure Staged Continuous Maturity Levels Process Area 1 Process Area 2 Process Area n Process Area 1 Process Area 2 Process Area n Specific Goals Generic Goals Generic Goals Specific Goals Common Features Directing Implementation Capability Levels Ability to Perform Commitment to Perform Verifying Implementation Specific Practices Specific Practices Generic Practices Generic Practices

47. Staged Models • The term "staged" comes from the way that the model describes this road map as a series of "stages" that are called "maturity levels." • Each maturity level has a set of process areas that indicate where an organization should focus to improve its organizational process. • Each process area is described in terms of the practices that contribute to satisfying its goals. • The practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the process areas. • Progress occurs by satisfying the goals of all process areas in a particular maturity level

48. Staged Models • The CMM for Software is the primary example of a staged model

49. Continuous Models • Continuous models provide less specific guidance on the order in which improvement should be accomplished. • They are called continuous because no discrete stages are associated with organizational maturity. • Like the staged models, continuous models have process areas that contain practices. • Unlike in staged models, however, the practices of a process area in a continuous model are organized in a manner that supports individual process area growth and improvement. • Most of the practices associated with process improvement are generic; they are external to the individual process areas and apply to all process areas

50. Continuous Models • The generic practices are grouped into capability levels (CLs), each of which has a definition that is roughly equivalent to the definition of the maturity levels in a staged model. • Process areas are improved and institutionalized by implementing the generic practices in those process areas. • In a continuous model goals are not specifically stated, which puts even more emphasis on practices. • The collective capability levels of all process areas determine organizational improvement, and an organization can tailor a continuous model and target only certain process areas for improvement. • In other words, they create their own "staging" of process areas.