Principy a hodnoty CMMI

Od Davida J.Anderson.David J.Anderson je autorem dvou knih, „Agilní správa softwarového inženýrství: aplikování teorie omezení obchodních výsledků“ [1] vydané v roce 2003 a „Kanban: úspěšné evoluční změny pro podnikové technologie“ [2] vydané v roce 2010.Byl členem týmu, který vytvořil Metodu agilního vývoje softwaru; Funkcemi řízený vývoj, v Singapuru mezi roky 1997 a 1999.Je autorem Principů agilní správy projektů, které byly definovány v Prohlášení vzájemné závislosti v roce 2005.David vytvořil MSF pro zlepšování procesu CMMI a je spoluautorem technické poznámky ústavu Software Engineering Institute „CMMI nebo agilní metody: proč není vhodné podpořit obojí!“. [3] Je viceprezidentem organizace Lean Software & Systems Consortium, http://www.leanssc.org a vede mezinárodní společnost pro školení managementu a konzultace, David J.Společnost Anderson & Associates Inc., http://www.agilemanagement.net, která pomáhá podnikům z oblasti technologií zvýšit efektivitu zavedením lepších zásad pro správu a lepšího rozhodování.

Leden 2012

Anderson popisuje, jak pohled na organizace prostřednictvím modulu CMMI poskytuje cenné informace pro manažery, technology procesů a všechny externí zúčastněné strany, včetně zákazníků, investorů, správních úřadů a auditorů.

Platí pro

Správa životního cyklu aplikací; CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

Původní model CMM (Capability Maturity Model) byl publikován v roce 1991.O desetiletí později se vyvinulo do modelu CMMI (Capability Maturity Model Integration).CMMI je nyní řada tří modelů (jako jsou známy) a tento článek odkazuje konkrétně na model CMMI pro vývoj (CMMI-DEV).CMM bylo vyvinuto, aby pomohlo ministerstvu obrany Spojených států lépe pochopit nákladná selhání softwarových projektů v rámci rozsáhlých vládních programů zadávání státních zakázek.Hodnocení založené na modelu CMM bylo použito k určení „vhodnosti“ pro vládní zakázky.Později se vyvinulo do definovaného schématu hodnocení založeného na CMMI.

Pojem organizační vyspělost zůstává sporný.Jak lze například posoudit vyspělost organizace?A vykazuje organizace skutečně chování, které se liší od chování a akcí jednotlivců?Konceptem je, že organizaci můžete hodnotit zejména v konkrétní úrovni vyspělosti a že tento indikátor je schopen dodávat spolehlivou práci vládě, což je předmětem pokračujících diskusí.Stále však věřím v CMMI a podporuji ho a věřím, že pohled na organizace prostřednictvím modulu CMMI poskytuje cenné informace pro manažery, technology procesů a všechny externí zúčastněné strany, včetně zákazníků, investorů, správních úřadů a auditorů.

Smysl organizační vyspělosti

Vyspělost v CMMI má vyjadřovat přístup a schopnost vyhodnocení a řízení rizik a úsudek uplatňovaný při rozhodování.Termín „vyspělost“ je skutečně používán ve smyslu společného využití ve vztahu k jednotlivcům.Například, pojistitelé nás mohou informovat, že muži staří 18 let mají větší pravděpodobnost automobilové nehody než 55 let staré ženy.18letý muž pravděpodobně vykazuje při rozhodování horšího úsudku souvisejícího s používáním vozidla a zřejmě nemá dostatek zkušeností k přiměřenému posouzením rizik spojených s konkrétními činnostmi.Výsledkem může být nehoda, které se může vyhnout 55letá žena.Pojišťovací společnosti jsou schopny obzvláště dobře posuzovat rizika, protože sbírají statistická data a vytvářejí korelace mezi jednotlivými poznatky.

Jeden problém s CMMI je vnímaná pejorativní povaha termínu „vyspělost“. Vždy se předpokládá, že vyšší vyspělost je lepší, než nižší.A že je nutné vždy usilovat o větší vyspělost.Pokud bychom takto uvažovali u jednotlivých podmínek, ne vždy by to dávalo smysl.Pojišťovací firma může stanovit levnější cenu pojištění automobilu levněji pro zkušenější řidiče, je však pravděpodobné, že závodní tým si bude více cenit mladické nevázanosti a ochoty riskovat.Pro závodní tým jsou automobilové havárie součástí podnikání.Řidiči, kteří nikdy v životě nenabourali, by vlastně byli propuštěni.

Tato zpráva je, že požadovaná úroveň vyspělosti by měla okolnostem a kontextu.Více neznamená nutně lépe, ale možnost správně určit a ohodnotit vyspělost organizace pomáhá při hodnocení, zda je podnik schopen řídit rizika a uplatňovat správný úsudek při rozhodování o projektech a produktech.

Mělo by docházet k silné korelaci mezi úrovněmi a pravděpodobnost dosažení nebo dodání požadovaných výsledků.Organizace s vysokou vyspělostí by měla mít velmi vysokou šanci zajistit výsledek podobný požadavkům.To zahrnuje schopnost posoudit pravděpodobnost a dosažitelnost možných výsledků a stanovit příslušné výstupy a cíle.U organizace s nižší vyspělostí je méně pravděpodobné, že stanoví dosažitelné cíle a dodá žádoucí výsledek proti očekávání.Druhou stranou této mince je, že vysoce vyspělá organizace nese rizika, a nastavuje sestavu snadno dostupných cílů, zatímco pružnost organizace nižší vyspělosti může dosáhnout výjimečného výkonu díky kombinaci štěstí a tvrdé práce.

Inspirace pro model CMMI

Původní model CMM byl vyvinut Wattsem Humphreyem a prvně představen (bez názvu CMM) v jeho knize Managing the Software Process (Proces řízení softwaru)[4].Byl inspirován hnutím za zajištění kvality výroby ve 20. století a prací Josepha M. Jurana.Edwards Deming a Philip Crosby.Termín „model vyspělosti“ a jeho pěti úrovní byly inspirovány Crosbyho modelem zralosti výroby.CMM však musí být vnímáno jako skutečná syntéza nápadů.Termín „schopnost“ je téměř jistě inspirovaný Demingem.

Deming používá termín „schopnost“ s velmi specifickým významem, který je mnohem hlubší než běžné chápání tohoto slova.Přesněji řečeno, „schopnost“ může být pokládána za „přírodní filozofii“ systému nebo operace v rámci systému.Deming podporoval manažery, aby „zkoumali schopnosti“ a statisticky je analyzovali.Vyvinul svůj Systém hlubokých znalostí[5], který je určen k použití jako rámec pro rozhodování, který pomáhá vedoucím pracovníkům provádět vhodné intervence designu systému.Deming přemýšlel skutečně systémově.V tomto případě slovo „systém“ znamená proces prováděný lidmi.Neexistuje žádný záměr, který by znamenal technologii nebo automatizaci.

Deming věřil a shromáždil důkazy, že 95 % výkonu systému vychází z návrhu systému a nikoli schopností jednotlivců pracujících v rámci systému.Jinými slovy, pro dosažení zlepšení je třeba se zaměřit na změnu procesu, systému, ve kterém lidé pracují, namísto zlepšování výkonu jednotlivců.V důsledku toho nevěřil v cíle, řízení podle cílů, motivační plakáty ani potrestání osob za nízký výkon.

Deming tak poskytnul model schopností v systému hlubokých znalostí a Crosby poskytnul model vyspělosti.Humphrey se snažil sloučit tyto koncepce a aplikovat je na poli softwarového inženýrství. Výsledkem byl Model schopnosti a vyspělosti.

Vzhledem k soustředění se na hodnocení a snahu o plnění úrovní vyspělosti pro veřejné zakázky, Modelování kapacity a Demingův vliv zmizely z většiny literatury o CMM a CMMI.Demingův vliv je jasně patrný v oblastech procesu vyšší úrovně vyspělosti.

Účelem modelu CMMI bylo vždy poskytovat rámec pro podporu vzniku kultury neustálého zlepšování v rámci organizace a byl vždy zamýšlen jako přístup systémového myšlení.V kořenech CMMI existují velmi zřejmé paralely k metodice Lean.

CMMI je model.

CMMI je model pochopení organizační vyspělosti a schopností.Nejedná se o normu ani o definici procesu vývoje softwaru nebo správy projektů.Obecné postupy popsané v tomto článku se vztahují na schopnost procesu a nikoli určitého projektu nebo na vývoj produktu.Například, pokud je plánování uvedené v následující tabulce, odkazuje na plánování implementace procesu, nikoli na jakýkoliv projektu nebo dodání produktu.

Model CMMI je složen ze 22 oblastí procesu a tří obecných cílů, u nichž se očekává, že je budou všechny organizace vykonávat.

3 obecné cíle jsou následující:

22 oblastí procesu je uspořádáno do 4 kategorií: inženýrství, správa projektů, správa procesů a podpora.Každá oblast procesu se skládá z jednoho až tří konkrétních cílů a všech tří obecných cílů.Běžně se čeká, že při dosahování každého cíle bude využito většího počtu postupů.V rámci cvičení mohou být navrženy podřazené postupy.Pouze CMMI vyžaduje nebo předepisuje cíle.Postupy definované v rámci cílů modelu CMMI jsou očekávané, ale nejsou povinné.Pokud nejsou k dispozici, musí být nahrazeny odpovídajícím náhradním postupem.Následující tabulka zobrazuje seskupení oblastí procesu:

Organizační zaměření	Oblast procesu
Konstrukce	Vývoj požadavků Technické řešení Integrace produktu Ověření Ověření
Řízení projektu	Plánování projektu Sledování a řízení projektu Integrovaná správa projektů Dohoda o vedení dodavatele Správa požadavků Řízení rizik Správa množstevních projektu
Správa procesů	Zaměření na organizační proces Organizační definice procesu Organizační školení Výkon organizačního procesu Organizační inovace a nasazení
Podpora	Správa konfigurace Zajištění kvality procesu a produktu Měření a analýza Analýza rozhodnutí a řešení Analýza a řešení příčin

Takže princip je jednoduchý: Pokud organizace může vykazovat schopnost dosažení cílů v oblasti každého procesu, pak mohou říci, že mají možnost v konkrétní oblasti procesu.

Oblasti procesu jsou seskupeny do úrovní vyspělosti, které poskytují metodu zjednodušených popisů vyspělosti.Ačkoli seskupení oblastí procesu do úrovní zůstává na několika úrovních sporné, mé zjištění z pozorování organizací během posledních dvou desetiletí je takové, že aktuální verze 1.3 modelu (s ohledem na to, že CMMI je ve skutečnosti verze 2 CMM) je obecně správná.Chaotické organizace s nízkou úrovní vyspělosti mají tendenci vyvíjet schopnosti v oblastech procesů definované na úrovni vyspělosti 2 před vývojem schopností v oblastech procesů definovaných s vyšší úrovní.

Následující tabulka zobrazuje seskupení oblastí procesu do úrovní.

Úroveň vyspělosti	Oblasti procesu
5	CAR – Analýza a řešení příčin OPM – správa organizační výkonnosti
4	OPP – výkon organizačního procesu QPM – správa množstevních projektu
3	RD – vývoj požadavků TS – technické řešení PI – integrace produktu VER – Ověření VAL – Ověření IPM – integrovaná správa projektů RSKM - Řízení rizik OPF – zaměření na organizační proces OPD – organizační definice procesu OT - Organizační školení DAR – analýza rozhodnutí a řešení Zajištění kvality procesu a produktu
2	CM - Správa konfigurace MA – měření a analýza SAM – správa dohody dodavatele PP – plánování projektu PMC – sledování a řízení projektu RM - Správa požadavků
1	Neexistují žádné oblasti procesu v rámci modelu úrovně 1.Úroveň 1 představuje nedefinovaný proces bez introspekce nebo schopnosti definovat proces nebo zopakovat výsledek prostřednictvím pochopení procesu, který jej vytvořil.Technicky je v hodnocení CMMI organizace, která nesplňuje cíle v oblastech procesu modelu úrovně 2, stále na úrovni 1.Takže na organizace s nově vznikajícími procesy budu stále technicky vzato pohlíženo jako na model úrovně 1, i když od stavu nedefinovaného chaosu prošly dlouhou cestou k vyspělosti.

Následující tabulka obsahuje přehled laických podmínek předmětu nebo účelu každé oblasti procesu:

Oblast procesu	Účel
CAR – Analýza a řešení příčin	Zjistěte hlavní příčinu výjimečných problémů procesu (zvláštní proměny příčin pro použití W.Termín Edwardse Deminga) a navrhněte a implementujte změny procesu, abyste zabránili opakování.Pozornost je směrována na neobvyklé chování kvantitativně chápaných stabilních procesů.Každodenní překvapení by byla pravděpodobně považována za součást řízení rizika (RSKM), nikoli CAR.
CM - Správa konfigurace	Namísto pouhého řízení verze zdrojového kódu tato oblast procesu zahrnuje veškerou správu týkající se systémového prostředí, konfigurace součástí, platforem, middleware, aplikací a dokumentace.Schopnost úspěšně vytvářet a zavádět pracovní kód spadající do této oblasti procesu.
DAR – analýza rozhodnutí a řešení	Pro všechna klíčová rozhodnutí v rámci projektu nebo vývoje produktu ukažte, že byla zvážena sada alternativ nebo možností a že k posouzení vhodnosti možností byly použity kontextové prvky.Zaznamenejte rozhodnutí a vybrané důvody.
IPM - integrovaná správa projektů	Tato druhá úroveň řízení projektů v rámci modelu CMMI naznačuje, že organizace je schopna zpracovávat více potenciálně závislých projektů současně.To je často dosaženo pomocí programu nebo portfolia podnikové správy.
MA – měření a analýza	Sběr dat o výkonu procesu, projektu a produktu.Vytváření metrik a ukazatelů ve formě sestav založených na datech.
OPD - organizační definice procesu	Organizace by měly mít jednu nebo více definic procesů, které jsou definovány v kontextu.Kontext popisuje profil rizika.U každého projektu lze posoudit rizika a definici procesu vybranou z organizačního katalogu a pak odpovídajícím způsobem přizpůsobit.
OPF – zaměření na organizační proces	Organizace by se měly domnívat, že proces definice definuje a ovlivňuje schopnost a že zlepšení schopností je především úsilím vylepšených procesů.V důsledku toho organizace aktivně spravuje své definice procesů a monitory (pomocí oblasti procesu PPQA) s cílem zajistit, že jsou tyto definice dodrženy.
OPM – správa organizační výkonnosti	Tato procesní oblast zapouzdří pojem statistická znalost, jak dobré výsledky proces poskytuje oproti očekávaným možnostem.Změny procesu za účelem zlepšení schopnosti lze vyhodnotit a posoudit základní model pro proces, pokud zjištěné výsledky neodpovídají výsledkům předpokládaným základním modelem při provedení změny definice procesu.Jeho obchodní potřeby organizace spravuje svůj výkon prostřednictvím svých obchodních procesů.
OPP – výkon organizačního procesu	Tato procesní oblast zapouzdří pojem porovnání výkonu, který je často označován jako „benchmarking“ (testování). OPP vytvoří procesní modely z porovnání dat směrného plánu.To umožňuje organizaci odpovědět na otázky typu „Které naše tři produktové týmy jsme měli zvolit pro [tento určitý projekt]?“
Organizační školení	Individuální schopnosti při specifických postupech jsou důležité pro výkon procesu a možnosti systému.Správně fungující systém se silným výkonem bude mít silnou schopnost školení vedoucí ke snížení variability ve schopnostech na místní úrovni praxe.
Integrace produktu	Možnost integrovat více komponent do formy kompletního výrobku a spravovat požadované prvky, aby to bylo možné.
Sledování a řízení projektu	Shromažďujte údaje o probíhajících projektech, porovnávejte je oproti plánům, projekcím a simulacím a na jejich základě přijímejte vhodná opatření.
Plánování projektu	Plánujte projekty na základě odhadů, simulace a analýzy požadavků.
Zajištění kvality procesu a produktu	Především proces auditu shody.Účelem je ukázat, že systém pracuje v souladu se záměrem.Pomáhá zabránit potenciálním chybám správy a změnit proces za účelem nápravy problému, pokud není dodržován správný postup procesu.
Správa množstevních projektu	Toto je třetí a nejvyšší úroveň řízení projektu v rámci modelu CMMI.To znamená, že statisticky spolehlivé kvantitativní metody slouží k plánování, monitorování a řízení projektů.
Vývoj požadavků	Existuje definovaný, opakovatelný proces k vyzývání, vyjednávání, analýze a dokumentaci požadavků.
Správa požadavků	Požadavky jsou sledovány po celou dobu životnosti projektu a ideálním existuje kompletní sledovatelnost mezi dodanou konfigurací a původní žádostí s požadavky.
Řízení rizik	Přestože celý model CMMI lze vnímat jako rámec pro řízení rizik, tato oblast procesu řeší především „rizika na základě událostí“ nebo pravděpodobnost a dopad změn zvláštních příčin a každodenních překvapení.Tato oblast vyžaduje proces omezení rizika, zmírnění, pohotovostního plánování, správy problémů a řešení.
Dohoda o vedení dodavatele	Možnost spravovat externí dodavatele, definovat dohody, spravovat kontrakt a převzít dodávku požadovaného produktu nebo služby.
Technické řešení	Všechny dovednosti vyžadované vzhledem k architektuře softwaru, návrhu a kódování.
Ověření	Souhlas s testováním podle požadavků zákazníků.
Ověření	Testování proti návrhu (z technického řešení).Usiluje o zajištění toho, že vytvářené produkty budou představeny, navrženy a sestaveny tak, aby vyhovovaly potřebám uživatelů a fungovaly v jejich prostředí.

Pro každou oblast procesu lze vyhodnotit úroveň schopností.Čtyři úrovně schopnosti jsou definovány v v1.3 CMMI:

0.Nekompletní

1.Provedeno

2.Spravované

3.Definice

Pokud je splněn každý konkrétní cíl a některé obecné cíle, schopnost pro danou oblast procesu bude hodnocena minimálně úrovní 1 - provedeno.Úroveň schopnosti 1 znamená, že členové týmu vědí, co dělat, a dělají to.Je nepravděpodobné, že se daný postup při statistické analýze prokáže jako stabilní.Postupy se dodržují, ale je zde stále nedostatek konzistence.Úroveň schopnosti 2 znamená, že tým chápe, jak něco funguje, a jeho úroveň dovedností umožňuje předvídatelné provádění v praxi a pravděpodobně bude vykazovat statistickou regulaci.Je pravděpodobné že bude uplatněno školení nebo společné pracovní postupy pro dosažení větší soudržnosti mezi členy týmu.Úroveň schopnosti 3 znamená zvládnutí dovednosti a schopnost rozvíjet nové a zdokonalené techniky, které povedou k dosažení cíle.Schopnost úrovně 3 znamená, že jakákoli statistická analýza by vyžadovala změnu základní čáry po každé explicitní změně základní techniky nebo postupu.

Zjednodušené pochopení principů CMMI

Takže model CMMI v zásadě uvádí, že nové a nezralé organizace budou nejprve rozvíjet schopnosti v postupech pro správu konfigurace a správu prostředků, shromažďování dat o projektech a vykonávané práce, plánování projektů, sledování požadavků, sledování průběhu projektu a akcí založených na porovnání skutečných dat proti plánu.Toto je podstatou vyspělosti úrovně 2.

Při uplatnění schopností úrovně vyspělosti 2 organizace a její lidé obracejí pozornost k jiným záležitostem, takže se začne objevovat schopnost definování požadavků, testování, architektury a návrhu, integrace a definování procesů tak, aby je bylo možné opakovat.Když se věci více stabilizují, dochází k pochopení toho, jak kultura a styl řízení ovlivňují výkon, a snad i k porozumění, že přístup systémového myšlení je nutný k dosažení dalších zlepšení výkonu.Během stabilizace záležitostí a řešení každodenních problémů plánování a přirozeného sledování projektu je čas zvážit řízení rizik a analýza možností a alternativ před přijetím rozhodnutí.Může dojít ke koordinaci více závislých projektů a vylepšenému řízení sdílených prostředků.Možná výukový program, schéma rad, schéma rad stylem mistra a učně, nebo forma spolupráce převedená do rituálu dá vzniknout zlepšení a zvýší celkovou úroveň výkonu.V případě potřeby může dojít na interní audit nebo funkci zabezpečení kvality procesu.To vše je podstatou vyspělosti úrovně 3.

Po spuštění organizace plné vyspělosti na úrovni 3 vše funguje jako na drátkách.Organizace plní své sliby a je chápána jako velmi stabilní a spolehlivá.Vysoká úroveň důvěryhodnosti vyplývá ze vztahů se zákazníky.Vedoucí pracovníci kladou otázky jako „Kde je třeba investovat pro zajištění dalšího zlepšení?“ a „Který tým zajišťuje nejlepší hospodářskou výkonnost?“ Manažeři začínají vyvíjet pokročilejší pohledy na funkce a výkon a zjišťují, že mohou pomocí simulace a statistické analýzy zlepšit kvalitu produktu, dodávku zákazníkovi a jeho spokojenost.Rozhodnutí správy jsou nyní zcela objektivní a zdůvodnitelná díky statistickým údajům.Toto je podstatou organizace vyspělosti úrovně 4.Pro většinu vedoucích pracovníků úrovně vyspělosti 4 představuje jejich ideální stav.Vše pracuje jako hodinky, k dispozici jsou srovnávací data výkonu a lze splnit slíbenou dodávku s vysokou úrovní přesnosti.Ekonomická výkonnost je výrazně vyšší a výkon organizace je vysoce předvídatelný.

Chování úrovně vyspělosti 5 se často objeví mnohem dříve, než organizace skutečně dosáhne úrovně 5.Analýza hlavní příčiny je často vidět v organizacích se zralostí úrovně 3.Schopnost na úrovni 5 je určena tím, zda se provádí analýza hlavní příčiny pomocí kvantitativních údajů a je statisticky zdůvodnitelná.Vznikem standardizovaného procesu pro proces inovace a zlepšení nasazení může také dojít před tím, než organizace může skutečně být považována na úrovni vyspělosti 5.Na úrovni 5 bylo vylepšení procesu institucionalizováno a zavedeno do kultury organizace.Kultura je vždy jednou z výzev statu quo a hledání vylepšení možností, zlepšení kvality produktů a zlepšeného ekonomického výkonu.

Ocenění CMMI

Hodnocení vyspělosti CMMI se určuje prostřednictvím zhodnocení.Existuje standardní proces pro provádění hodnocení SCAMPI – standardní metoda hodnocení CMMI pro zlepšování procesu.To bylo zavedeno k vytvoření opakovatelnosti procesu a posílení důvěry v jeho výsledky.Tři úrovně jsou při ocenění označovány jako třída A, B a C, kde třída A je nejpřísnější.Ocenění třídy A jsou nutná pro hodnocení na úrovni modelu, které je přijatelné pro veřejné záznamy nebo požadavky Ministerstva obrany USA.

Všechna posouzení třídy A a většina posouzení tříd B a C je prováděna hlavními hodnotiteli CMMI, kteří jsou autorizováni ústavem Software Engineering Institute k provádění posouzení.Tito konzultanti prošli prostřednictvím programu důkladným školením než byli licencováni k praxi.Někteří hodnotitelé prošli dalším školení a jsou označeni jako vedoucí hodnotitelé s vysokou mírou zkušeností CMMI.Organizace, které vyžadují zhodnocení úrovně modelu 4 nebo 5, musí pracovat s vysokou mírou zkušeností Lead.

Ocenění vyžadují důkazy, že byly provedeny postupy k dosažení cílů v oblastech procesu modelu CMMI.V rámci organizace systémem portfolia projektů a možná s několika obchodními divizemi je ke zjištění počtu projektů v příslušném oboru třeba použít složitého vzorce.Cílem je zajistit spravedlivé pokrytí ukázkové sady projektů, která ukazuje, že organizace má institucionární schopností v každé oblasti požadovaného procesu.Vedoucí znalec určí projekty, které se hodnotí na základě tohoto vzorce.

V rámci hodnocení každého projektu je třeba sbírat důkazy prokazující metody, které jsou třeba k dosažení dostatečné schopnosti v oblasti dokončeného postupu.Pro každý postup znalec hledá pevný, hmatatelný důkaz, který je označován jako artefakty a často se nachází v dokumentech, jakými jsou plány, zdrojový kód, návrhy a architektonické dokumenty.Navíc vyžadují potvrzení.Potvrzení je obecně nepřímý důkaz, jako jsou zaměstnanci hovořící o provádění postupů, například anekdoty popisující účast na plánovací schůzce.Potvrzení jsou získávána pomocí rozhovorů se zaměstnanci účastnícími se projektů, které jsou hodnoceny.Potvrzení mohou posílit písemné důkazy nebo je vyvrátit, což vede vedoucího hodnotitele ke zpochybnění platnosti dokumentace.

Ocenění CMMI nejsou nutná, aby byl model CMMI užitečný.CMMI pomáhá organizacím vyvíjejícím software pochopit své schopnosti a vyspělost a porovnávat je oproti očekávání svých zákazníků a ostatních zainteresovaných stran.Hrubá představa o tom, organizace mapuje ve srovnání s CMMI modelem, poskytuje způsob hodnocení, jak může reagovat pod stresem a jaká je její schopnost dodávat podle očekávání.Organizace, u kterých jsou pozorovány vyspělejší aktivity, ale nemají pevné základy z chování s nižší vyspělostí, mohou být často nepředvídatelné.Zatímco je chování vyspělé, což je chvályhodné, tyto vyspělé praktiky nejsou spolehlivé, protože nemají pevný základ.

Ocenění CMMI jsou často používána jako způsob ověření iniciativy vedoucí ke zlepšování procesů v celé organizaci.Tím se vytvoří tlak na „předání testu“. Fokus se stane jedním z prokazujících, že jsou za každou praxí v oblasti zobrazeny tyto důkazy.Může dojít ke ztrátě pozornosti z toho je skutečně důležité – vyobrazení možností oproti očekáváním zákazníka – a vylepšení schopností pomocí výslovných akcí řízení.Toto zaměření na „předání zkoušky“ je často vedlo k významným vedlejším účinků a dysfunkcí v organizacích.V důsledku toho vyvinul model CMMI silný blok detraktorů v průmyslu.To je škoda, skutečně věřím, že je model CMMI platný a poskytuje cenné informace o technologii pro vedoucí v organizaci – pohledy, které by měly vést ke zlepšení schopností, výkonu a spokojenosti zákazníků.

[1] Anderson, David J., agilní správa softwarového inženýrství: aplikování teorie omezení obchodních výsledků, Prentice Hall PTR, 2003

[2] Anderson, David J., Kanban: úspěšné evoluční změny pro podnikové technologie, Blue Hole Press, 2010

[3] Glazer Hillel a Jan Dalton, David J.Anderson, Michael D.Konrad, Sandra Shrum, CMMI or Agile: Why not embrace both!, Software Engineering Institute, listopad 2008

[4] Humphrey, Watts S., Správa zpracování softwaru, Addison Wesley Professional, 1989

[5] Deming, W.Edwards, Nová ekonomika pro průmysl, vládu, vzdělávání, 2. vydání, The MIT Press, 2000