V Konferencja PLOUG Zakopane Pazdziernik 1999 Model dojrzałości organizacyjnej CMM (Capability Maturity Model) dr inż. Wiesław Byrski Wyższa Szkoła Zarządzania Streszczenie Model CMM (Capability Maturity Model) został opracowany w celu usprawnienia zarządzania procesami tworzenia systemów oprogramowania. W modelu wyróżnia się 5 faz charakteryzujących stopień dojrzałości firmy wytwarzającej oprogramowanie. Pierwsza z nich, faza początkowa, charakteryzuje się pełną spontanicz- nością i brakiem wypracowanych procedur postępowania, pojawiające się problemy rozwiązywane są ad hoc. W najwyższej, piątej fazie organizacja procesów jest pełna i kompletna, a firma może pozwolić sobie na ich optymalizację. Na wzór modelu CMM można opracować analogiczny model dla firm znajdujących się w rożnych fazach informatyzacji - od pozbawionej nawet elementów komputeryzacji do fazy optymalizacji procesów nakierow- nych na cele. 1. Wstęp Prowadzane przez kilka lat intensywne badania firm produkujących oprogramowanie w celu usprawnienia przemysłowego procesu wytwarzania oprogramowania doprowadziły do stworzenia bardzo ciekawego Modelu dojrzałości organizacji software owej (Capabi- lity Maturity Model for Software) w skrócie CMM. Model ten opracowano w 1991 r. So- ftware Engineering Institute z Carnagie Mellon University. Raport SEI znalezć można np. w [4], a bogatą bibliografię nt. modeli CMM w [1]. Konstrukcję CMM oparta jest na koncepcji dojrzałości zarządzania procesami1, gdzie przez dojrzałość rozumiany jest stopień zapanowania nad zachodzącymi w firmie proce- sami. Chodzi tu nie tylko o procesy techniczne związane z bezpośrednim wytwarzaniem oprogramowania ale również o procesy zarządzania na poziomie operacyjnym i poziomie strategicznym. Bezpośrednia korzyść z modelu polega na wskazaniu kierunku zmian orga- nizacji w celu osiągnięcia większej skuteczności. W modelu CMM zawarte są powszech- nie przyjmowane zasady i ustalone praktyki postępowania określające stopień dojrzałości swoich procesów software owych co może pomóc organizacjom wytwarzającym oprogra- mowanie na zaplanowanie ewolucyjnej ścieżki swojego rozwoju od chaotycznego, ad hoc, procesu do zdyscyplinowanego, mierzalnego i bezustannie doskonalonego dojrzałego pro- cesu. 2. Konstrukcja modelu CMM 2.1. Struktura modelu CMM W modelu CMM wyróżniono pięć poziomów dojrzałości. Każdy poziom, z wyjątkiem pierwszego, ma podobną strukturę, przedstawioną na rys. 1: 1 warto wspomnieć w tym miejscu, że orientacja zarządzania na procesy została wywołana przez funkcjonującą w biznesie modę na reinżynierię procesu zarządzania, w chwili obec- nej zostało z niej jako najwartościowsza część właśnie spojrzenie na firmę przez pryzmat zachodzących w niej procesów 2 Poziom dojrzałości określa Wyznaczony przez Dojrzałość procesu Kluczowe procesy Określane przez Organizowane Cele Atrybuty procesu Z zakresu Opisują Implementacji i organizacji Zasady praktyki określające Infrastructurę albo działanie rys 1 Struktura modelu CMM Poszczególne pojęcia za pomocą których opisywany jest model CMMM pokazany na rysunku 1 określane są następująco: " poziom dojrzałości (maturity level) - rozumie się w tym modelu ustabilizowany poziom organizacji procesów zarządzania i technologicznych, " dojrzałość procesu (proces capability) oznacza stopień możliwości przewidzenia jakie będą skutki tego procesu przy kolejnym jego uruchomieniu, " procesy kluczowe (key process areas) określają grupę powiązanych odpowiednimi relacjami działań, które wykonywane wspólnie pozwolą na osiągnięcie celów uznawanych za istotne dla stopnia dojrzałości procesu, " cele (goals) wyznaczają zakres, granice i intencje każdej dziedziny procesu, " atrybuty procesu (common features) określone są w pięciu grupach: akceptacji stosowania, możliwości stosowania, mierzalności i analiz oraz weryfikacji imple- mentacji. Atrybuty te pozwalają na określenie czy stosowanie kluczowych proce- sów jest efektywne, powtarzalne i skuteczne. Występuje silne powiązanie z ogólną kulturą organizacyjną firmy. " zasady praktyki (key practices) określają infrastrukturę i postępowanie w celu najskuteczniejszego wykonania kluczowych procesów. 3 2.2 Poziomy dojrzałości Hierarchię poziomów dojrzałości w modelu CMM przedstawia rys. 2. Ciągłe do- skonalenie Optymalizacji procesów Przewidywalne procesy Zarządzany Standardowe, spójne procesy Zdefiniowany Procesy Powtarzalny uporząd- kowane Początkowy Rys. 2. Pięć poziomów dojrzałości software owej (Software Process Maturity) 1) Poziom początkowy: Organizacje znajdujące się na tym poziomie z reguły nie mają stabilnego środowiska projektowania i produkcji oprogramowania. Nawet jeżeli firma ma dobrze opanowaną techniczną stronę produkcji oprogramowania (narzędzia, fachowcy, metodyka itp.) to gdy brakuje w niej dobrych organizatorów proces wytwarzania oprogramowania jest nieustalony, wymyślany ad hoc, a często nawet chaotyczny. Zaledwie niektóre procesy są zdefiniowane (o ile w ogóle jakiekolwiek istnieją), a udanie się projektu zależy od indywidualnego wysiłku i talentu poszczególnych projektantów. Jakość wytworzonego oprogramowania jest sprawą przypadku i silnie zależy od umiejętności zaangażowa- nych jednostek. Dla menadżerów takich firm, jeżeli nie są informatykami, proces pro- dukcji oprogramowania jest jedną, wielką czarną skrzynką. 2) Poziom powtarzalny Na tym poziomie znajduje się organizacja, która wprowadziła podstawowe procesy za- rządzania projektami czyli opanowała umiejętność określenia wielkości oprogramowa- nia, niezbędnych zasobów do jego wytworzenia, potrafi oszacować koszt i harmono- 4 gram itp. Opanowane są również elementy zarządzania jakością. Poziom ten nazywa się powtarzalnym, gdyż organizacja stosuje sposoby wykształcone w podobnych dzia- łaniach. Ciągle jednak występuje silna zależność sukcesu projektu od umiejętności jed- nostek, a w momencie stresu pojawia się tendencja do cofnięcia się organizacji do po- ziomu pierwszego. Proces tworzenia oprogramowania ewoluował od jednej czarnej skrzynki do kilku mniejszych, które przekazują sobie sterowanie poprzez punkty kontrolne (kamienie milowe projektu). Menadżerowie nawet gdy nie wiedzą co się dzieje wewnątrz czar- nych skrzynek znają ich produkty i punkty kontrolne pozwalające na identyfikację pro- cesu. 3) Poziom zdefiniowany Procesy zarówno zarządzania jak i inżynierskie są dokumentowane, standaryzowane i integrowane w standardowe procesy software owe organizacji (w zakresie produkowa- nych aplikacji). We wszystkich projektach używa się sprawdzonych, dopasowanych standardów do projektowania i pielęgnacji oprogramowania. W firmie prowadzone są szkolenia i treningi dla zapewnienia pracownikom i menadżerom odpowiedniej wiedzy i umiejętności wymaganej przy pełnieniu przypisanej im roli. Występuje mniejsza za- leżność powodzenia projektów od jednostek. W momencie stresu nie porzuca się praktyk tego poziomu. Wewnętrzna struktura czarnych skrzynek tj. procesów w prowadzonych projektach jest zdefiniowana. Przedstawia ona sposób w jaki organizacja aplikuje standardy do reali- zowanych projektów. Aatwo i szybko da się określić stan projektu w każdym momen- cie dzięki temu, że zdefiniowane procesy pozwalają na pełną obserwowalność działań. 4) Poziom zarządzany: Do poziomu czwartego podstawową sprawą jest jakość produktu. Na czwartym pozio- mie organizacja musi opracować dokładne metody pomiaru procesów i zastosować je do działań korygujących. Zarówno proces software owy jak i sam produkt są opisane pod względem jakości i dają się sterować. Menedżerowie dostali obiektywne, ilościo- we metody podejmowania decyzji. Trafność tych decyzji rośnie ponieważ zmniejsza się nieokreśloność procesów. Gdy uda się takie miary określić organizacja wstępuje na drogę implementacji ciągłego doskonalenia procesów 5) Poziom optymalizacji Stosowane jest ciągłe doskonalenie procesów poprzez sprzężenie zwrotne i wprowa- dzanie innowacyjnych idei i technologii. Opracowane na poprzednim poziomie metody mierzenia procesów nie tylko pozwalają na doskonalenie procesów istniejących ale również na badanie opłacalności wprowadzania nowych technologii do organizacji. 2.3. Kluczowe procesy modelu CMM Na rysunku 2 przy poszczególnych poziomach podane zostało hasło obowiązujące na tym poziomie dojrzałości. Zobaczmy teraz jakie kluczowe procesy muszą być przez organiza- cję opanowane aby mogła znalezć się ona na kolejnym poziomie modelu CMM. Przedsta- wia to rysunek 3. 5 Optymalizacji Zarządzanie zmianami Zarządzanie technologią Zapobieganie błędom Zarządzany Zarządzanie jakością procesu Mierzalność procesu Zdefiniowany Przeglądy powykonawcze Koordynacja pracy grup Inżynieria produktu softwareowego Integracja zarządzania softwarem Program szkoleń Definicja procesów organizacyjnych Koncentracja na proc. organizacji Powtarzalny Zarządzanie jakością projektu Zarządzanie podwykonawcami Nadzorowanie projektów Planowanie projektów Analiza warunków i wymagań Początkowy Rys. 3. Kluczowe problemy modelu CMM Przyjrzyjmy się trochę dokładniej kluczowym procesom i spróbujmy je zakwalifikować do jednej z trzech kategorii zarządzania: operacyjnego, strategicznego i technologicznego (informatycznego) (patrz rysunek 4). Widać wyraznie, że w miarę osiągania wyższego poziomu dojrzałości organizacja większy nacisk kłaść musi na problemy strategiczne. Z modelu wynika również, że nie ma większego pożytku ze stosowania rozwiązań, które nie współgrają z innymi kluczowymi procesami określonego poziomu. Zwykle jednak firma nie będzie dojrzewać równomiernie, niektóre procesy mogą być już z wyższego pozio- mu, a część jeszcze nie w pełni udoskonalona może powodować problemy. W tym mo- 6 mencie widzimy pożytek ze stosowania modelu CMM właśnie w przewidywaniu kolejnej fazy ewolucji zarządzania produkcją oprogramowania. Rozważania o powiązaniu modelu CMM z planowaniem strategicznym można znalezć w [7] Kategoria Operacyjny Strategiczny Informatyczny Planowanie projektów, Planowanie strategicz- Analiza wymagań, pro- Procesu zarządzanie itp. ne zmian, technologii, jektowanie, kodowanie, itp. testowanie, itp. Poziom 5 Optymalizacji Zarządzanie techno- logią Zarządzanie zmiana- Unikanie błędów mi 4 Zarządzany Ilościowa ocena pro- Zarządzanie jakością cesów oprogramowania 3 Zdefiniowany Zintegrowane zarzą- Koncentracja na pro- Inżynieria oprogra- dzanie softwarem cesach organizacyj- mowania nych 2 Powtarzalny Kontrola jakości pro- jektu Zarządzanie podwy- konawcami Nadzorowanie pro- jektów Planowanie projektów Analiza warunków i wymagań 1 Początkowy Procesy ad hoc Rys. 4. Przyporządkowanie głównych procesów do trzech kategorii procesów 3. Model CMM a standard ISO 9001 W pracy [8] Mark C. Paulk przebadał 20 warunków ISO 9001 i porównał je z zapisami przyjętymi w modelu CMM. Dochodzi do wniosku, że model i seria standardów ISO 9000 koncentrują się na tych samych zagadnieniach: jakości i zarządzaniem procesami. Te pro- blemy są podobnie traktowane i są intuicyjnie skorelowane różnią się jednak w swoim filozoficznym podejściu: ISO 9001 określa minimalne wymagania dla systemu kontroli jakości podczas gdy model CMM podkreśla konieczność ciągłego doskonalenia procesów. Na trzy pytania : " Na jakim poziomie CMM znajduje się organizacja, która posiada certyfikat ISO 9001? " Czy organizacja będąca na 2 (lub 3) poziomie CMM może być traktowana jako posia- dacz certyfikatu ISO 9001? " Czy zarządzanie jakością software'u i doskonalenie procesów oprzeć na ISO 9001 czy na CMM? 7 Pada odpowiedz, że wszystkie procesy kluczowe modelu CMM są w jakimś stopniu w relacji do ISO 9001. Generalnie zawarte w CMM zasady odpowiadają wymaganiom ISO 9001. W drugą stronę jest to mniej prawdziwe, co powoduje, że konstruowanie dokładnego odpowiednika jest mało przydatne ale podobieństwo jest znaczące. W efekcie można po- wiedzieć, że: " Organizacja posiadająca certyfikat ISO 9001 powinna spełniać większość celów z po- ziomu 2 i wiele z poziomu 3. I w drugą stronę organizacja znajdująca się na poziomie 1 może starać się o certyfikat ISO. " Organizacja z poziomu 2 (lub 3) prawdopodobnie będzie spełniała wymagania ISO ale nawet będąc na 3 poziomie musi zwrócić uwagę na pewne procesy (np. dostaw i insta- lacji oprogramowania). " Na pytanie ISO czy CMM pada odpowiedz, że najpewniej firma będzie chciała (mu- siała) zastosować obydwa rozwiązania: jedno wymuszone przez rynek (standardy ISO) i drugie z powodu praktycznej użyteczności. Obydwa te modele pozwalają na oparcie budowy swojej przewagi konkurencyjnej na pew- nych formalnych kryteriach, certyfikacie czy stopniu dojrzałości. Można to robić w szer- szym biznesowym kontekście filozofii Total Quality Management. 4. Użyteczność modelu CMM Oprogramowanie staje się coraz bardziej złożone i coraz ważniejsze staje się jego niezawodne działanie. Dotrzymanie terminów, zmieszczenie się w budżecie i przede wszystkim sama realizacja warunków zlecenia stają się coraz trudniejsze do spełnienia. Organizacje potrzebują metod oceny możliwości realizacji kontraktów software owych niezależnie czy występują w roli wykonawcy, podwykonawcy czy wreszcie zleceniodaw- cy. Model CMM dostarczając spójną bazę, na której gruncie można ocenić procesy softwa- re owe pozwala na porównywanie możliwości jednej organizacji z inną. Przyjmując za pożądaną ścieżkę ewolucji organizacji od poziomu 1 nieustruktury- zowanych procesów do najwyższego, optymalizującego model CMM może być użyty do opracowania strategii firmy. Z modelu wynikają bowiem wprost cele strategiczne, jakie należy osiągnąć aby znalezć się na kolejnych poziomach rozwoju, łatwo również dobrać drogę dojścia do tego celu [patrz np. 9] czyli określić strategię firmy. Nieoceniony jest również wkład teoretyczny przy badaniu kierunków rozwoju or- ganizacji nie tylko software'owych. W jednym, zintegrowanym modelu umieszczone zo- stały odrębnie funkcjonujące techniki i metody co nadaje im inny wymiar. Model CMM może być użyty również do opisu innej niż software'owa działalności inżynierskiej patrz np. [9]. Analizując problemy z wdrażaniem informatyki w organizacjach również można posłużyć się koncepcją "dojrzałości procesów", które miałyby być wspomagane technolo- gią informatyczną, pewne próby takiego opisu zawarte są w pracy [10]. 8 Literatura: 1. A Software Process Bibliografy, august 1999 ftp://ftp.sei.cmu.edu/pub/cmm/Misc/biblio.pdf 2. David Lipton: Function Points and the SEI Capability Maturity Model http://www.qpmg.com/seicmm2.htm 3. Emmanuel R. Baker, Frank J. Koch, The SEI Capability Maturity Model, Proces Per- spectives, No. 1 Fall 1993 http://www.process-strategies.com/pp_1.htm 4. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, The Capability Maturity Model For Software, Version 1.1, Software Engineering Institute ,Carnegie Mellon University Pittsburgh, CMU/SEI-93-TR-24 http://rbse.jsc.nasa.gov/cmm/TR24/tr24.html 5. Paulk, Mark C., et al The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995 6. Praca zbiorowa SEI: A Systems Engineering Capability Maturity ModelSM Version 1.1 http://www.sei.cmu.edu/pub/documents/95.reports/pdf/mm003.95.pdf 7. Frank J. Koch and Emanuel R. Baker: Strategic Planning for Software Process Im- provement, , Proces Perspectives, No.6 - Winter 1999 http://www.process-strategies.com/pp_6.htm 8. Mark C. Paulk: How ISO 9001 compares with the CMM http://www.sei.cmu.edu/publications/documents/96.reports/96.ar.iso.vs.cmm.html 9. W. Byrski, R. Gambin: Algorytmiczne podejście do tworzenia strategii firmy, mate- riały PLOUG'98 10. W. Byrski: Modele firmy dla celów zarządzania procesem informatyzacji, w: Zarzą- dzanie Zmianami, Biuletyn informacyjny Wyższej Szkoły Zarządzania, Warszawa- Kraków-Legnica, (w druku) 9