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í:

Obecný cíl

Obecná praxe

Účel

GG 1 - Proces podporuje a umožňuje dosažení zvláštních cílů v oblasti procesu, a to transformací identifikovatelné vstupní práce produktů za účelem produkce identifikovatelné výstupní práce produktů.

GP 1.1 - Provádějte specifické postupy procesu a rozvíjejte tak pracovní produkty a poskytujte služby k dosažení konkrétních cílů v oblasti procesu.

Základním předpokladem je, že předvídatelné výsledky pocházejí z následujícího procesu.

GG 2 - Proces je institualizován jako spravovaný proces.

GP 2.1 - Vytvořte a udržujte organizační zásady pro plánování a provádění procesu.

Správa by měla podporovat GP 2.1 podporou vytváření, udržování a využití procesu. Existuje identifikovatelná správy zásad/poznámek stanovující, že proces by měl být následován zajištěním předvídatelných výsledků.

GP 2.2 - Vytvořte a udržujte plán pro provádění procesu.

Existuje plán k zajištění, aby nové činnosti přijaly postup a řídily se podle něj.

GP 2.3 - Poskytujte dostatečné zdroje pro provádění procesu, vývoj pracovních produktů a poskytování služeb procesu.

Správa skutečně podporuje následující proces a nastaví projekty pro úspěch poskytnutím správných prostředků.

GP 2.4 - Přiřaďte odpovědnost a autoritu pro provádění procesu, vývoj pracovních produktů a poskytování služeb procesu.

Vedoucí pracovníci delegují pravomoci a stanovují role a odpovědnosti u projektu tak, aby bylo jisté, že je proces řízen a vznikne pracovní produkt podle očekávání.

GP 2.5 - Vyškolte osoby provádějící nebo podporující proces podle potřeby.

Je zaveden výukový program k zajištění toho, aby pracovníci na projektu byli odpovídajícím způsobem kvalifikováni k provádění zadaných úkolů a poskytování požadované schopnosti pro oblast procesu.

GP 2.6 - Vybrané pracovní produkty patřičně pečlivě kontrolujte.

Existuje správa konfigurace a správa dokumentů pro všechny základní artefakty k vytvoření produktu práce, např. požadavky na řízení a sledování, řízení verze zdrojového kódu a řízení konfigurace prostředí.

GP 2.7 - Identifikujte a podle plánu zapojte akcionáře.

Jsou zapojeny všechny nezbytné zúčastněné strany. Předvídatelná rizika jsou označena jako výsledek.

GP 2.8 - Sledujte a řiďte proces proti plánu pro provádění procesu a provádějte vhodné opravné akce.

To souvisí s GP 2.2 a žádá, aby byl plán pro následující proces sledován a ukázat, že je dodržován. Například, pokud plán vyžaduje, aby se technik procesu setkal s manažerem projektu a přizpůsobil definici, opravdu se tato schůzka odehrála?

GP 2.9 - Objektivně vyhodnocujte dodržování popisu procesu, standardů, postupů a řešte jejich neplnění.

Sledujte, zda je proces dodržován, nikoli obcházen nebo ignorován. Zvažte úpravu definovaného procesu, pokud neodpovídá provozním skutečnostem.

GP 2.10 - Kontrola aktivity, stavu a výsledků procesu s vyšší úrovní správy a řešení problémů.

Zachovejte účast a podporu vyššího managementu. Proveďte formulář kontroly operací s vedoucím pracovníkem a porovnat schopnosti s očekáváními a požadavky. Zvažte, zda jsou zdroje a školení odpovídající, a proveďte kroky k vyřešení problémů schopností v definici procesu nebo v oblasti procesu podle potřeby.

GG 3 - Proces je institualizován jako definovaný proces.

GP 3.1 – Vytvořte a udržujte popis definovaného procesu.

Aby mohl být proces opakovatelný a mohl být dodržen dle záměru, je zapotřebí písemného popisu.

GP 3.2 - Shromažďujte produkty práce, opatření, výsledky měření a informace o zlepšování odvozené z plánování a provádění procesu pro podporu budoucího použití a zlepšování organizačních procesů a prostředků procesů.

Řízení správnosti procesu prostřednictvím kvantitativních prostředků a vývoj podle potřeby pro splnění potřeb při jejich vývoji.

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