Model dojrzałości organizacyjnej CMM

V Konferencja PLOUG
Zakopane
Październik 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ą spontanicznoś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 nakierownych 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” (Capability Maturity Model for Software) w skrócie CMM. Model ten opracowano w 1991 r. Software Engineering Institute z Carnagie Mellon University. Raport SEI znaleźć 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 procesami. 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 organizacji w celu osiągnięcia większej skuteczności. W modelu CMM zawarte są powszechnie 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 oprogramowanie na zaplanowanie ewolucyjnej ścieżki swojego rozwoju od chaotycznego, ad hoc,
procesu do zdyscyplinowanego, mierzalnego i bezustannie doskonalonego dojrzałego procesu.
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 obecnej 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 implementacji. Atrybuty te pozwalają na określenie czy stosowanie kluczowych procesó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 doskonalenie
procesów
Przewidywalne
procesy
Optymalizacji
Zarządzany
Standardowe,
spójne procesy
Zdefiniowany
Procesy
uporządkowane
Powtarzalny
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żowanych jednostek. Dla menadżerów takich firm, jeżeli nie są informatykami, proces produkcji
oprogramowania
jest
jedną,
wielką
czarną
skrzynką.
2) Poziom powtarzalny
Na tym poziomie znajduje się organizacja, która wprowadziła podstawowe procesy zarządzania projektami czyli opanowała umiejętność określenia wielkości oprogramowania, 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 jednostek, a w momencie stresu pojawia się tendencja do cofnięcia się organizacji do poziomu 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 czarnych skrzynek znają ich produkty i punkty kontrolne pozwalające na identyfikację procesu.
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 produkowanych 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 zależ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 realizowanych projektów. Łatwo i szybko da się określić stan projektu w każdym momencie 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 poziomie 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ściowe 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 wprowadzanie 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 organizację opanowane aby mogła znaleźć się ona na kolejnym poziomie modelu CMM. Przedstawia 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ć wyraźnie, ż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 poziomu, 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 znaleźć w [7]
Kategoria Operacyjny
Procesu Planowanie projektów,
zarządzanie itp.
Poziom
5 Optymalizacji
4 Zarządzany
3 Zdefiniowany
Strategiczny
Informatyczny
Planowanie strategiczne zmian, technologii,
itp.
Analiza wymagań, projektowanie, kodowanie,
testowanie, itp.
Zarządzanie technologią
Zarządzanie zmianami
Ilościowa ocena procesów
Zintegrowane zarządzanie softwarem
Koncentracja na procesach organizacyjnych
2 Powtarzalny
Kontrola jakości projektu
Zarządzanie podwykonawcami
Nadzorowanie projektów
Planowanie projektów
Analiza warunków i
wymagań
1 Początkowy
Procesy ad hoc
Unikanie błędów
Zarządzanie jakością
oprogramowania
Inżynieria oprogramowania
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 problemy 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 posiadacz certyfikatu ISO 9001?
• Czy zarządzanie jakością software'u i doskonalenie procesów oprzeć na ISO 9001 czy
na CMM?
7
Pada odpowiedź, ż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 powiedzieć, że:
• Organizacja posiadająca certyfikat ISO 9001 powinna spełniać większość celów z poziomu 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 instalacji oprogramowania).
• Na pytanie ISO czy CMM pada odpowiedź, że najpewniej firma będzie chciała (musiał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 pewnych formalnych kryteriach, certyfikacie czy stopniu dojrzałości. Można to robić w szerszym 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 zleceniodawcy. Model CMM dostarczając spójną bazę, na której gruncie można ocenić procesy software’owe pozwala na porównywanie możliwości jednej organizacji z inną.
Przyjmując za pożądaną ścieżkę ewolucji organizacji od poziomu 1 nieustrukturyzowanych 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 znaleźć 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 organizacji nie tylko software'owych. W jednym, zintegrowanym modelu umieszczone został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 technologią 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 Perspectives, 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 Improvement, , 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, materiał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, WarszawaKraków-Legnica, (w druku)
9