Model dojrzalosci organizacyjnej CMM


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


Wyszukiwarka