Model SW-CMM je dnes nejrozšířenějším prostředkem pro posuzování kvality procesů při tvorbě software. Seznámení s ním a využití jeho principů k návrhu a realizaci programů umožní firmám lépe zvládnout problematiku jakosti vytvářených produktů.


Model vznikl z potřeby hodnotit pro ministerstvo obrany USA softwarové firmy při výběrových řízeních na státní zakázky v počátku osmdesátých let. Byl vytvořen pracovníky Institutu softwarového inženýrství Carnegie Mellon univerzity v Pitsburgu. Vžil se pod označením CMM (Capability Maturity Model) nebo také pod označením SW-CMM, protože později začaly vznikat jeho modifikace pro různé jiné oblasti (PM-CMM pro projektové řízení a další). Model definuje firemní procesy v softwarových firmách do pěti úrovní:

1. Initial
Na této úrovni dominují nahodilé (ad hoc) procesy. Software je vytvářen bez firemních pravidel chaoticky, takže se jeho tvorba často dostává do kritických situací. Dosažený úspěch ve vývoji software je důsledkem šťastné náhody a závisí na individuálních schopnostech a znalostech programátorů. Dohodnuté termíny nejsou většinou dodržovány a ukončení vývoje je dosahováno nesmírným heroickým úsilím na konci projektu. Celkové náklady na projekt jsou sečteny po ukončení vývoje a posuzují se jako důsledek vývoje a nutných výdajů. O kvalitě software se sice hovoří, ale nijak se nezajišťuje. Každý spoléhá na toho druhého, že kvalitu zajistí.

2. Repeatable
Opakovaně se dosahuje dobrých výsledků. Firma využívá základních postupů projektového řízení, ale z projektu na projekt se přenášejí jen některé úspěšné prvky řízení. Nicméně intuitivně zaběhané procesy a povědomí, že je potřeba pracovat kvalitně, vytvářejí dost stabilní prostředí pro udržení přijatelné úrovně jakosti softwarových produktů.

3. Defined
Software je vyvíjen podle předem stanoveného postupu, metodicky, plánovitě, s využitím pokročilého projektového řízení s cílem dosáhnout vypracování požadovaného software v čase, s rozpočtovanými náklady a disponibilními zdroji. Provádí se pravidelné vyhodnocování odchylek od plánu a přijímají se opatření ke krácení termínů jednotlivých činností, aby software byl dodán včas. O kvalitu produktů a služeb se s ohledem na zákazníky explicitně usiluje, proto je kvalita softwaru dodržována na velmi dobré úrovni a má tendenci vykazovat určité zlepšování.

4. Manage
Firma má všechny procesy jasně definovány a stanoven pro ně postup měření, který vyhodnocuje jejich podíl a efektivitu při tvorbě software. Zjištěné charakteristiky procesů jsou postupně upravovány tak, aby se firma přizpůsobila měnícím se podmínkám trhu, aniž by to mělo dopad na jakost vyvíjeného softwaru, jehož kvalitativní parametry jsou firmou cílevědomě stále zvyšovány a dosahují vysoké úrovně.

5. Optimizing
Neustálá zpětná vazba ovlivňuje následné softwarové projekty tak, aby se firemní procesy neustále zlepšovaly a dosahovaly předem definovaných, optimálních parametrů. Firma dosahuje trvale špičkové jakosti, aniž by náklady na kvalitu softwaru měly dopad na hospodaření firmy. Naopak, garantovaná kvalita software usnadňuje jeho prodej.

Model se poměrně rychle v průběhu osmdesátých let rozšířil a řada dalších univerzit a firem rozpracovávala a propracovávala jeho dílčí aspekty. Pro model byly definovány jednotlivé kroky, které umožňují postup na vyšší úroveň:
· z 1. na 2. úroveň - disciplína, zodpovědnost, pořádek, cílevědomost,
· z 2. na 3. úroveň - standardizace, stálost a provázanost firemních procesů, monitorování procesů,
· ze 3. na 4. úroveň - kritéria a měření procesů, řízení změn a využívání predikce vývoje procesů,
· ze 4. na 5. úroveň - neustálé zlepšování procesů, vícekriteriální optimalizace procesů, adaptibilita procesů.

Rovněž pro jednotlivé úrovně byly definovány klíčové aspekty úspěchu (key process areas), viz tabulka 1.




Zajímavé je hodnocení podílu množství rizika, kvality a produktivity v jednotlivých úrovních modelu, který znázorňuje tabulka 2.




Principy CMM jsou natolik obecné z hlediska zralosti firemních procesů, že se začaly používat v procesním inženýrství jako univerzální model pro zdokonalování firemních procesů. Dále byly vytvářeny další specializované modely pro jiné oblasti než softwarové inženýrství. Byla již vzpomenuta varianta CMM pro oblast projektového řízení. Další známou variantou je SW-TMM (software testing maturity model) [5]. Model CMM je nejvíce rozšířen v USA, a to jak v oblasti státního departmentu, tak i v soukromých firmách. Existuje i řada kritických hlasů [3]. Nejčastěji se namítá, že model není založen na teoretické bázi a existuje pro něj pouze vágní empirická podpora. Proto vznikly alternativní modely jakostní tvorby software, např. v rámci normalizační organizace ISO [2], nebo obecné modely jakosti, např. model EFQM, u nás popsaný J.Nenadálem z VŠB-TU Ostrava [6]. Na druhé straně řada autorů ukazuje na skutečnost, že mnoho softwarových firem produkuje nekvalitní software způsobem, který nelze odhodnotiti ani příslušností do první úrovně. Tom Schorsch a jiní [4] definovaly proto záporné úrovně modelu CMM. Ty odrážejí fakt, že v oblasti tvorby software ještě celá řada softwarových firem nepovažuje jakost za nutnou součást svých firemních procesů. Proto byl model CMM doplněn o další záporné úrovně, které jsou charakterizovány následovně:

0. Negligent
Nedbalost, nepozornost, řada chybně navržených procesů a špatná organizace firmy způsobuje, že vytvořený software má velký počet chyb, které se ani nestačí identifikovat, natož opravit. Termíny se nedaří plnit, plánované náklady se překračují, často se žádné plánování nákladů ani neprovádí. Práce, která je přesto provedena, je nakonec zmařena v důsledku různých jiných nedostatků. Vedení firmy i pracovníci často spoléhají na nějaká zázračná řešení, která způsobí okamžité divy. Produkty se firmě od zákazníků neustále vracejí, aby byly opraveny a dopracovány, přičemž řada zákazníků žádá slevy na dodané produkty.

-1. Obstructive
Řada kontraproduktivních opatření ve firmě a protichůdných procesů téměř znemožňuje vytvořit kvalitní software. Často se objevují odmítavá stanoviska k zavádění takových věcí jako projektové řízení, řízení jakosti, uznávané metody tvorby software, produkty CASE apod., s odůvodněním, že se jedná jen o byrokratická, administrativní opatření, která komplikují programátorům a dalším zaměstnancům práci. Jedna reorganizace stíhá druhou, stejně zmatenou jako byla ta předchozí. Kvalita software je tak špatná, že zákazníci neustále produkty reklamují, firmu penalizují a postupně přecházejí k jiným firmám.

-2. Contemptuous
Ve firmě pracovníci přehlížejí jakákoliv doporučení a zásady softwarového inženýrství. Programování je prohlašováno za umění, takže jakékoliv snahy o zavádění pořádku a systému do vývoje software je označováno jako útok na uměleckou tvořivost a svobodu. Nejsou vedeny žádné údaje o postupu vývoje softwaru, často jsou takové údaje záměrně ničeny. Zákazníkům není nasloucháno a jsou naopak přesvědčováni, že produkty, které dostali, jsou ty nejlepší, a jejich nefunkčnost je zapříčiněna vlastní nízkou úrovní znalostí uživatelů v používání počítačů.

-3. Undermining
Samorostlé názory pracovníků firmy na tvorbu software jsou zcela mimo chápání normálních lidí a podkopávají důvěru veřejnosti v softwarové inženýrství.

Tyto špatné výsledky tvorby programového vybavení pro automatizované informační systémy jsou také zapříčiněny absencí propracovaných metod tvorby software, např. metodou RUP. O aplikaci této metody u nás ve spolupráci s firmou Unicorn, s rozšířením o principy řízení projektu na principech KKTR (kvalita-kvantita-termín-rozpočet), referovala dvojice Beránek-Slabý na konferenci Objekty 2004 [7]. Zatím poměrně málo softwarových firem vlastní certifikát svého systému řízení jakosti podle řady norem ISO 9000:2000. Přitom naléhavost problematiky kvality softwaru je dnes v centru pozornosti zejména ze tří důvodů:
· Software se stal velmi rozšířeným zbožím a zákazníci by měli být chráněni před nekvalitními produkty.
· Do softwaru se investují obrovské finanční částky a z celospolečenského i tržního hlediska je potřeba zajistit jejich efektivní zhodnocení.
· Stále více se používá software v aplikacích pro automatické řízení procesů, kde chyby v programovém vybavení mohou mít velké, často katastrofální důsledky (řízení jaderných reaktorů, řízení zdravotnických zařízení, navigace letadel apod.).

To vše nutí softwarové firmy zamýšlet se nad tím, jak navrhnout a realizovat ve svých týmech procesy tvorby software, aby výsledný programový produkt byl dodán zákazníkovi v požadované kvalitě. Model SW CMM představuje filozofii, jak se k jakosti tvorby software dopracovat.

Použité zdroje:

[1] Paulk,Mark,et al, Capability Maturity Model 1.1. (CMU/SEI-93-TR-24)
[2] ISO 15 504 - SPICE (Software Process Improvement and Capability dEterministic)
[3] James Bach: The Immaturity of CMM. American Programmer, September 1994
[4] Anthony Finkelstein: A Software Process Immaturity Model (viz www.cs.ucl.ac.uk/staff/A.Finkelstein/papers/immaturity.pdf)
[5] Thomas C. Staab: Using SW-TMM to Improve the Testing Process (viz www.windridgeinternational.com)
[6] Nenadál, J.: Inovovaný model EFQM - orientace na výjimečnost (viz www.fmmi.vsb.cz/639/mj02-cz.htm)
[7] Beránek, M. - Slabý, A.: Řízení projektu dle RUP využívající princip KKTR. In: Sborník 9. konference Objekty 2004. ČZU PEF Praha 2004, str. 47-56
[8] Kreslíková, J.: A Comparison of EN ISO 9001:2000 and the Capability Maturity Model for Software, Kolokvium ASIS 2001, MARQ, Ostrava, 2001, s. 283-289

Autor článku, doc. Ing. Branislav Lacko, Csc., působí v ústavu automatizace a informatiky Fakulty strojního inženýrství VUT v Brně.