Pięć poziomów CMM
Ciągły proces poprawy opiera się bardziej na wielu małych krokach, niż na rewolucyjnych innowacjach. CMM dostarcza schematu, aby uporządkować te kroki w pięć następujących po sobie poziomów, które stanowią fundament ciągłej poprawy. Te pięć poziomów definiuje uporządkowaną skalę, według której można mierzyć dojrzałość procesu tworzenia oprogramowania oraz szacować jego wydajność.
Każdy poziom jest dobrze ustabilizowanym stanem. Przechodzenie na wyższe poziomy odpowiada osiąganiu coraz to większej doskonałości procesu tworzenia oprogramowania. Poziom zawiera zestaw celów, których osiąganie stabilizuje pewien składnik naszego procesu. Osiąganie każdego z poziomów schematu stabilizuje inny składnik procesu tworzenia oprogramowania, co prowadzi do poprawy wydajności w ujęciu globalnym.
Struktura CMM i jego podział jest przedstawiony na rys. 3.1. Etykiety na strzałkach wskazują, jakie zmiany są wprowadzane na każdym z poziomów.
Rysunek 3.1. Pięć poziomów dojrzałości procesu tworzenia oprogramowania
Poniżej zostało pokrótce opisane, jak zmienia się proces na poszczególnych poziomach:
Wstępny - proces jest chaotyczny, opisywany sporadycznie i chaotycznie „ad hoc”. Niewiele procesów jest zdefiniowanych, a sukces zależy od indywidualnego nakładu i w dużym stopniu od przypadku.
Powtarzalny – wprowadza się w podstawowym stopniu proces zarządzania projektem, śledząc koszty, plany i funkcjonalność.
Zdefiniowany – obydwa procesy: zarządzanie i czynności inżynieryjne są udokumentowane, zestandaryzowane i zintegrowane w standardy procesu tworzenia oprogramowania. Wszystkie projekty używają zatwierdzonej, jednolitej wersji standardów organizacyjnych.
Zarządzany – zbierane są szczegółowe pomiary procesu tworzenia oprogramowania i badana jest jakość produktu. Zarówno proces tworzenia oprogramowania, jak i produkty są mierzalne, zrozumiałe i kontrolowane.
Optymalizujący – możliwa jest ciągła poprawa dzięki sprzężeniu zwrotnemu pomiędzy procesem, innowacyjnymi ideami i nową technologią.
Zachowawcza charakterystyka poziomów dojrzałości
Poziomy od 2 do 5 mogą być scharakteryzowane poprzez czynności dokonywane przez organizację, aby ustanowić, a następnie udoskonalać proces tworzenia oprogramowania, poprzez czynności dokonywane w każdym projekcie oraz poprzez zmieniającą się wydajność. Charakterystyka poziomu 1 stanowi bazę dla porównania ze stanem procesów na wyższych poziomach.
Poziom 1 – wstępny
Na poziomie wstępnym organizacja zasadniczo nie dostarcza stałego środowiska dla rozwoju i utrzymywania oprogramowania. Jeśli w organizacji brakuje solidnych praktyk zarządzania, wtedy pożytki wynikające z poprawnych praktyk inżynieryjnych są osłabiane poprzez nieefektywne planowanie oraz reakcyjne siły samego systemu.
Podczas kryzysów w projektach odchodzi się od zaplanowanych procedur zwracając się w stronę kodowania i testowania. Sukces zależy wtedy tylko od wysiłków managera i efektywności zespołu w tym okresie. Czasami zdolni i silni managerowie mogą oprzeć się naciskom upraszczania procesu tworzenia oprogramowania, ale jeżeli takie osoby odejdą z projektu i zabraknie ich stabilizującego działania, wtedy nic już nie jest w stanie uratować procesu od częściowego lub całkowitego niepowodzenia, zwłaszcza w kontekście zapewnienia jakości. Nawet silny inżynieryjnie proces nie może pokonać niestabilności wynikającej z braku odpowiedniego zarządzania.
Wydajność procesu tworzenia oprogramowania na poziomie 1 jest nieprzewidywalna, ponieważ proces tworzenia oprogramowania ciągle ulega zmianom i jest modyfikowany wraz z rozwojem prac. Plany, budżet, funkcjonalność i jakość produktu są trudne do przewidzenia. Wykonanie zależy od wydajności jednostek, ich wrodzonych umiejętności, wiedzy i motywacji. Istnieje bardzo mało jasno widocznych procesów, a wykonanie zależy nie od zdolności organizacyjnych, ale od indywidualnych wysiłków.
Poziom 2 - poziom powtarzalny
Na poziomie powtarzalnym ustanowiona jest polityka zarządzania projektem oprogramowania i procedury tej polityki. Planowanie i zarządzanie nowymi projektami opiera się na doświadczeniach z podobnymi projektami w przeszłości. Cel, jaki osiągamy wchodząc na poziom 2, to ustanowienie skutecznego procesu zarządzania procesem tworzenia oprogramowania, który pozwala organizacji powtarzać pomyślne praktyki rozwinięte we wcześniejszych projektach. Niemniej jednak, wdrożone specyficzne procesy mogą się różnić. Skuteczny proces charakteryzowany jest jako sprawny, udokumentowany, wprowadzony, mierzalny i możliwy do udoskonalania.
W poziomie 2 organizacja zakłada podstawową kontrolę zarządzającą. Zarządzanie projektem opiera się na wynikach zaobserwowanych we wcześniejszych projektach i na wymaganiach bieżącego projektu. Managerowie zarządzający projektem śledzą koszty, plany i funkcjonalność. Na zebraniach identyfikowane są powstające problemy. Produkty rozwijane są tak, aby odpowiadały wymaganiom i kontrolowana jest ich integralność.
Definiowane są standardy oprogramowania i organizacja zapewnia, że będą one dokładnie przestrzegane. Projekt rozwijany jest przy współpracy z subkontrahentami, jeśli istnieją, po to, aby ustanowić silny związek klient-dostawca.
Wydajność procesu na poziomie 2 może być podsumowana jako zdyscyplinowana, ponieważ istnieje planowanie i śledzenie kosztów, a poprzednie sukcesy mogą być powtarzane. Proces projektu jest pod efektywną kontrolą systemu zarządzającego projektem, następne plany opierają się na obserwacjach dokonań poprzednich projektów.
Poziom 3 - zdefiniowany
Na poziomie zdefiniowanym standardowy proces rozwoju i zarządzania oprogramowaniem jest udokumentowany zarówno jeśli chodzi o inżynierię oprogramowania, jak i o proces zarządzania, przy czym te procesy są zintegrowane w jedną koherentną całość. Procesy ustanowione na poziomie 3 są używane, aby pomóc kierownikom i personelowi technicznemu pracować bardziej wydajnie. Standaryzując swoje procesy organizacja wykorzystuje efektywnie praktyki inżynierii oprogramowania. Istnieje zespół odpowiedzialny za czynności software’owe, np. grupa inżynierów procesu tworzenia oprogramowania – SEPG (Software Engineering Process Group) [Fowler 90]. W całej organizacji wdrażany jest program szkoleniowy, aby zapewnić, że personel i managerowie mają wiedzę i umiejętności odpowiednie do pełnionej funkcji.
Projekty dopasowują organizacyjny proces tworzenia oprogramowania do ich własnego zdefiniowanego procesu tworzenia oprogramowania, który odpowiada cechom charakterystycznym projektu. Zdefiniowany proces tworzenia oprogramowania zawiera koherentny, zintegrowany zestaw dobrze zdefiniowanych procesów inżynieryjnych i procesów zarządzania. Dobrze zdefiniowany proces może być scharakteryzowany jako zawierający kryteria gotowości, dane wejściowe, standardowe procedury wykonujące prace, mechanizmy weryfikacji (takie jak peer reviews), dane wyjściowe, kryteria zakończenia. Proces tworzenia oprogramowania jest dobrze zdefiniowany, więc zarządzanie ma dobry wgląd w techniczne postępy wszystkich projektów.
Podsumowując, na poziomie 3 zarówno prace inżynieryjne, jak i czynności zarządzania są stałe i powtarzalne. W obrębie linii produkcyjnych koszty, plany, funkcjonalność i jakość pozostają pod kontrolą. To wszystko opiera się na zrozumieniu poszczególnych czynności, ról i obszarów odpowiedzialności w zdefiniowanym procesie.
Poziom 4 - poziom zarządzany
Na poziomie zarządzanym celem jakościowym i ilościowym organizacji jest zarówno produkt software’owy, jak i proces. Produktywność i jakość dla ważnych czynności procesów są mierzone w obrębie całego projektu i jest to część programu pomiarowego organizacji. W bazie danych procesu tworzenia oprogramowania zbierane są i analizowane dostępne dane pochodzące z procesów zdefiniowanych w projekcie. Procesy tworzenia oprogramowania są wyposażone w narzędzia pomiarowe, aby proces mierzenia był dobrze zdefiniowany i konsystentny.
Projekt osiąga kontrolę nad swoimi produktami i procesami poprzez zawężenie zmienności wydajności swoich procesów do ściśle określonych granic. Znacząca zmienność w procesie może być dalej dostrzegalna, będzie to tzw. losowa zmienność (szum), szczególnie w ustabilizowanych liniach.
Reasumując, wydajność procesu tworzenia oprogramowania na poziomie 4 jest do przewidzenia, ponieważ proces jest mierzony i zarządzany w mierzalnych granicach. Ten poziom pozwala organizacji przewidzieć trendy w procesach i jakość produktu mieszczące się w określonych granicach. Jeżeli te granice są przekraczane, podejmowana jest odpowiednia akcja, by skorygować sytuację. Produkty posiadają więc wysoką jakość.
Poziom 5 - poziom optymalizujący
Na poziomie optymalizującym cała organizacja koncentruje się na ciągłym udoskonalaniu procesu. Organizacja posiada środki, aby zidentyfikować słabości i wzmocnić proces, mając na celu zapobieganie występowaniu defektów. Dane o efektywności procesu tworzenia oprogramowania są używane do analizy finansowej nowych technologii i proponowanych zmian w procesie tworzenia oprogramowania. Innowacje, które eksploatują najlepsze praktyki inżynieryjne są identyfikowane i przenoszone na całą organizację.
Zespół projektowy organizacji analizuje defekty, aby wyznaczyć ich przyczyny. Proces tworzenia oprogramowania jest oceniany, aby zabezpieczyć się przed powracaniem poznanych wcześniej typów defektów, a wyciągnięte doświadczenia są rozpropagowywane na inne projekty.
Wydajność procesu tworzenia oprogramowania na poziomie 5 stale wzrasta, ponieważ organizacja na poziomie 5 nieprzerwanie dokłada starań, aby zwiększyć wydajność procesu, poprawiając wykonanie swoich procesów. Ciągłe udoskonalanie zachodzi zarówno poprzez przyrostowy rozwój istniejących projektów, jak i innowacje wynikające ze stosowania nowych technologii.
Zrozumienie poziomów dojrzałości
CMM jest modelem opisowym, tzn. opisuje zasadnicze atrybuty i cechy charakteryzujące organizacje, których oczekuje się na poszczególnych poziomach modelu. Jest to model normatywny, tzn. od szczegółowego procesu oczekuje się, aby charakteryzował się znormalizowanym typem zachowania na tle projektu dużej skali. Zamierzeniem CMM jest dostateczny poziom abstrakcji i nie wymusza się dokładnie tego, jak procesy mają być implementowane przez organizacje, ale po prostu opisuje się, jakie mają być podstawowe atrybuty procesu tworzenia oprogramowania odpowiednio na kolejnych poziomach modelu.
CMM nie jest modelem perspektywicznym, nie mówi organizacji jak ulepszać. Opisuje jedynie każdy poziom nie dając recepty jakie należy dokładnie podjąć środki aby go osiągnąć. Zazwyczaj upływa kilka lat, zanim organizacja przejdzie z poziomu 1 na 2. Doświadczenia wielu firm pokazują, że do przejścia na kolejny poziom potrzeba co najmniej dwóch lat.
Proces poprawy oprogramowania następuje w kontekście strategicznych planów organizacji, interesów służbowych, jej struktury organizacyjnej, używanej technologii, towarzyskiej kultury i systemu zarządzania.
Zrozumienie Poziomu Podstawowego
Chociaż poziom ten jest bardzo chaotyczny, czasami daje on w efekcie produkt, który funkcjonuje poprawnie, niemniej jednak może nie mieścić się w budżecie, terminach dostaw i poziomie jakości. Sukces na tym poziomie zależy od indywidualnych cech i kompetencji jednostek zaangażowanych w projekt i nie wynika z zastosowania CMM.
Zrozumienie Poziomu Powtarzalnego i Zdefiniowanego
W miarę, jak rośnie rozmiar i złożoność projektu, uwaga musi się przesunąć z zagadnień technicznych w kierunku zagadnień organizacyjnych.
Nabywanie niezbędnych umiejętności na drodze szkoleń oraz udokumentowanie procesu poprzez personel umożliwia wydajniejsza i efektywniejszą pracę.
Aby osiągnąć poziom 2, zarządzanie musi się skoncentrować na swoich własnych procesach, aby osiągnąć jeden zdyscyplinowany proces tworzenia oprogramowania. Poziom 2 dostarcza fundamentu pod poziom 3, ponieważ koncentruje się na czynnościach zarządzania i poprawia je. Zarządzanie zajmuje wiodąca pozycję w pracach nad osiągnięciem poziomu 2.
Poziom 3 tworzy podstawy zarządzania w projekcie poprzez zdefiniowanie, zintegrowanie i dokumentowanie całego procesu tworzenia oprogramowania. Integracja w tym przypadku oznacza, że wyniki jednego zadania są płynnie przekazywane jako dane wejściowe do następnego zadania. Jeśli istnieje niezgodność zadań, jest ona łatwo identyfikowalna już w fazie planowania procesu tworzenia oprogramowania, jeszcze zanim proces zacznie działać. Jednym z wyzwań poziomu 3 jest zbudowanie procesów, które legalizują i umacniają działanie jednostki.
Zrozumienie poziomów zarządzania i optymalizującego
Rysunek 3.2. Diagram Juran’a: planowanie jakości, kontrola jakości, i poprawa jakości
Poziomy 4 i 5 stanowią jeszcze obszar słabo poznany. Istnieje tylko niewiele przykładów procesów i organizacji, które weszły tak wysoko. Jest ich zbyt mało, aby wyciągać ogólne wnioski na temat cech charakterystycznych poziomów 4 i 5.
Właściwości tych poziomów zostały zdefiniowane zarówno poprzez analogię do dziedzin pozakomputerowych, jak i na podstawie przykładów tych niewielu istniejących organizacji, które osiągnęły wysokie poziomy CMM.
Wiele właściwości poziomu 4 i 5 opiera się na wyobrażeniu (koncepcie) kontroli procesu statystycznego, jak to przedstawiono na rys. 3.2. Diagram Juran Trilogy ilustruje zasadnicze cele zarządzania procesem.
Juran dzieli zarządzanie procesem na 3 podstawowe procesy kierownicze [Juran 88]. Celem planowania jakości jest dostarczenie sił operacyjnych, tj. producentów oprogramowania z ich środkami produkujących produkt odpowiadający wymaganiom klienta. Siły operacyjne produkują produkt, ale jest wymagany pewien ponowny nakład pracy z powodu wad jakości. Ta strata jest chroniczna, ponieważ proces był zaplanowany w ten sposób, że kontrola jakości tylko zapobiega spadkowi jakości. Sporadyczne piki na wykresie 3.2 w procesie są widoczne i reprezentują niestabilność procesu. Ta chroniczna strata dostarcza nam sposobności do udoskonalenia naszego procesu i wskazuje, że celem dalszego udoskonalania jest poprawa jakości produktu.
Pierwszy obszar odpowiedzialności poziomu 4 to kontrola procesu. Proces tworzenia oprogramowania jest zarządzany w taki sposób, że porusza się w strefie kontroli jakości. Istnieje nieuchronna chroniczna strata i mogą istnieć pojedyncze piki, które musza być kontrolowane, ale system generalnie jest całkowicie stabilny. To właśnie w tym miejscu wchodzi w grę pojęcie kontroli nadzwyczajnych przyczyn odchyleń jakości. Ponieważ proces jest zarówno stabilny, jak i mierzalny, jeśli zachodzą wyjątkowe okoliczności, "nadzwyczajna przyczyna" odchylenia jakości może być zidentyfikowana i można się nią zająć.
Drugi obszar odpowiedzialności poziomu 5 to ciągłe udoskonalanie procesu. Proces tworzenia oprogramowania jest zmieniany, aby poprawić jakość i strefa jakości ulega przesunięciu. Doświadczenia, które wyciągnęliśmy poprawiając taki proces są wykorzystywane w planowaniu następnego procesu. Chroniczna strata istnieje w każdym procesie. Jest ona rozumiana jako ponowny nakład pracy uzależniony od losowej zmienności. Nie możemy tego zaakceptować, dlatego nowym wyzwaniem jest zredukowanie tej chronicznej straty i udoskonalenie procesu poprzez usunięcie typowych przyczyn niskiej wydajności.
Od organizacji, które osiągają najwyższy poziom dojrzałości CMM oczekuje się, że ich procesy będą produkować nadzwyczaj niezawodne oprogramowanie mieszcząc się w kosztach, planowanych terminach i poziomach jakości. Wraz z lepszym zrozumieniem wysokich poziomów CMM, procesy kluczowe są modyfikowane, redefiniowane oraz powstają w modelu nowe. CMM bierze swoje pochodzenie od idei manufacturingu, z tym że w procesach tworzenia oprogramowania nie mamy tak wiele do czynienia z kwestią replikacji, jak to ma miejsce przy produkcji. Tutaj bardziej dominuje kwestia projektowania i wiedza.
Wgląd w proces tworzenia oprogramowania
Inżynierowie oprogramowania mają dokładny wgląd w stan projektu, ponieważ posiadają informacje z pierwszej ręki na temat statusu i wykonania. Jednakże, w dużych projektach ich pogląd opiera się zwykle tylko na doświadczeniach z ich wąskiego zakresu odpowiedzialności. Z kolei managerowie na wyższych szczeblach widzą całość, ale zbyt ogólnie, opierając się jedynie na periodycznych recenzjach. Brakuje im szczegółowego wglądu w proces projektowania, aby móc monitorować projekt. Rys. 3.3 przedstawia poziom wglądu w status projektu i wykonania dla kadry zarządzającej na każdym poziomie dojrzałości. Widzimy wyraźny przyrost, każdy następny poziom dostarcza lepszego wglądu w procesy tworzenia oprogramowania.
Rysunek 3.3. Wgląd w proces tworzenia oprogramowania na poszczególnych poziomach z punktu widzenia kadry zarządzającej
Na poziomie 1 proces tworzenia oprogramowania jest bezpostaciowy (czarna skrzynka), wgląd w procesy projektu jest ograniczony. Jest to dla managerów skrajnie trudny okres, aby ustalić status rozwoju projektu. To prowadzi do reguły Ninety-Ninety Rule - 90% projektów jest gotowych w 90% w momencie upłynięcia terminu końcowego.
Wymagania wpływają do procesów w niekontrolowany sposób. Tworzenie oprogramowania jest często widziane jako "czarna magia", zwłaszcza przez zarządzających, których wiedza o pisaniu programów nie jest duża.
Na poziomie 2 kontrolowane są wymagania klienta i produkty pracy oraz ustanawiane są podstawowe praktyki zarządzania. Ta kontrola zarządzająca pozwala na łatwy wgląd w projekt w zdefiniowanych miejscach. Proces tworzenia oprogramowania jest widziany jako szereg „czarnych skrzynek”. Pozwala to zarządowi na wgląd w punkty transakcyjne pomiędzy czarnymi skrzynkami (kamienie milowe projektu). Niemniej jednak zarząd dokładnie nie wie, co dzieje się w poszczególnych czarnych skrzynkach. Identyfikowane są jedynie produkty końcowe poszczególnych procesów oraz punkty kontrolne dla potwierdzenia, że proces pracuje prawidłowo. W razie potrzeby zarząd reaguje na powstałe problemy.
Na poziomie 3 wewnętrzna struktura wyżej wspomnianych czarnych skrzynek, tj. wewnętrzne zadania procesów są już widoczne. Wewnętrzna struktura reprezentuje sposób, w jaki proces tworzenia oprogramowania został zastosowany do specyficznego projektu. Zarówno managerowie, jak i inżynierowie rozumieją swoje role i odpowiedzialność w obrębie procesu oraz wzajemne zależności pomiędzy ich działaniami na odpowiednim poziomie szczegółowości. Kierownictwo stopniowo przygotowuje się do ryzyka, które może zaistnieć. Jednostki spoza dziedziny projektu mogą otrzymać szybko dokładny status stanu aktualnego, ponieważ zdefiniowany proces posiada dobry wgląd w czynności projektowe.
Na poziomie 4 zdefiniowany proces jest zaopatrzony w narzędzia pomiarowe i jest kontrolowany ilościowo. Kierownictwo jest w stanie mierzyć postępy i problemy. Ma w ten sposób obiektywną i ilościową podstawę do podejmowania decyzji. Może także z coraz większą dokładnością przewidywać rezultaty, ponieważ zmienność w procesach stale się zmniejsza.
Na poziomie 5 ciągle wypróbowywane są nowe i poprawione sposoby tworzenia oprogramowania, dzieje się to w kontrolowany sposób, co poprawia produktywność i jakość. Kontrolowane i zdyscyplinowane zmiany są „stylem życia”. W ten sposób wszystkie elementy niewydajne i skłonne do defektów są identyfikowane, zastępowane, bądź poprawiane. Wnikliwość wykracza już poza ramy procesu i wkracza w efekty potencjalnych zmian procesów. Kierownictwo ma możliwość szacowania i śledzenia rezultatów wprowadzanych i planowanych zmian.
Wydajność procesu i predykcja wykonania
Dojrzałość procesu tworzenia oprogramowania w organizacji pomaga przewidzieć zdolność procesów do realizowania wyznaczonych celów. Na poziomie 1 istnieją duże wahania (zmienności) w osiąganiu celów, kosztach, planach, funkcjonalności i docelowej jakości. Rys 3.4 przedstawia, jak osiągane są zamierzone cele na każdym z poziomów.
Rysunek 3.4. Wydajność procesu na poszczególnych poziomach
Po pierwsze, wraz ze wzrostem dojrzałości, maleje różnica pomiędzy celami zamierzonymi i rezultatami rzeczywistymi w obrębie całego projektu. Na przykład, jeśli 10 projektów tego samego rozmiaru miało określoną tą samą docelową datę zakończenia, to wraz z rozwojem dojrzałości rzeczywista data zakończenia zbliża się do planowanej. Poziom 1 często charakteryzuje się niedotrzymywaniem terminu wykonania z powodu dużego marginesu, podczas gdy na poziomie 5 założenia odnośnie terminów powinny być spełniane z dużą dokładnością. Dzieje się tak dlatego, że na poziomie 5 organizacja stosuje dokładnie skonstruowane procesy tworzenia oprogramowania działające w obrębie dobrze znanych parametrów. Organizacja posiada już dużą ilość danych na temat procesów i ich wydajności, a wybór daty docelowej opiera się na tych danych. Na rys. 3.4 widzimy, jak dużo obszaru pod krzywą leży na prawo od linii celów.
Po drugie, wraz z rozwojem dojrzałości zmienność rzeczywistych wyników wokół wyniku docelowego maleje. Na przykład, na poziomie 1 data dostarczenia produktu jest trudna do przewidzenia i zmienia się w szerokim zakresie. W projekcie podobnych rozmiarów na poziomie 5 widzimy bardzo wąski zakres zmian. Mamy do czynienia ze zmniejszającą się zmiennością, ponieważ wszystkie projekty faktycznie działają w obrębie ściśle określonych parametrów zbliżając się do celów zamierzonych. Widzimy jak dużo obszaru pod krzywą koncentruje się blisko linii celów.
Po trzecie poprawiają się wyniki docelowe wraz z rozwojem dojrzałości organizacji. To znaczy, koszty maleją, czas rozwoju staje się krótszy, produktywność i jakość wzrastają. Na poziomie 1 czas rozwoju może być bardzo długi z powodu dużego wtórnego nakładu pracy na poprawę błędów. Natomiast na poziomie 5 organizacja w procesie udoskonalania wypracowała techniki przeciwdziałania błędom, zwiększając wydajność procesów, eliminując błędy i skracając czas rozwoju. Na rysunku ilustruje nam to horyzontalne przemieszczenie linii celów.
Wszystko ulega większej komplikacji wraz z wprowadzaniem nowych, mało znanych technologii. Co za tym idzie, może się obniżyć wydajność procesu z powodu wzrostu zmienności. Ale nawet w tym przypadku, gdy mamy do czynienia z systemami nowymi i nie spotykanymi dotychczas, cechy charakterystyczne praktyk zarządzania i praktyk inżynieryjnych w dojrzałych organizacjach pozwalają wcześniej zidentyfikować i zająć się problemami w cyklu rozwoju, niż to jest możliwe w mało dojrzałych organizacjach. Wcześniejsza detekcja defektów przyczynia się do wzrostu stabilności projektu i eliminuje ponowny nakład pracy w fazach późniejszych. Zarządzanie ryzykiem jest integralną częścią zarządzania projektem w dojrzałym procesie.
Pomijanie poziomów dojrzałości
Pomijanie poziomów jest nieproduktywne, ponieważ każdy poziom dostarcza niezbędnego fundamentu, na którym można budować następny. CMM dostarcza poziomów, przez które organizacja musi stopniowo przechodzić, aby osiągnąć doskonałość inżynierii oprogramowania. Procesy bez odpowiedniego fundamentu nie dostarczają postaw do późniejszego udoskonalania, ewentualnie mogą niespodziewanie upaść w momencie krytycznym, w warunkach dużego stresu.
Próba zaimplementowania procesu zdefiniowanego (poziom 3), zanim ustanowimy proces powtarzalny (poziom 2) kończy się zazwyczaj niepowodzeniem, ponieważ managerowie projektu są przytłoczeni presją planów i kosztów. Jest to zasadniczy powód, dla którego koncentrujemy się na zarządzaniu procesem zanim przejdziemy do inżynierii procesu. Pozornie może wydawać się, że łatwiej jest zdefiniować najpierw kwestie inżynieryjne, a potem proces zarządzania, ale bez dyscypliny zarządzania procesy inżynieryjne mogą łatwo pójść w złym kierunku.
Organizacja, która próbuje zaimplementować proces zarządzany (poziom 4) nie mając procesu zdefiniowanego (poziom 3) zazwyczaj skazana jest na niepowodzenie, ponieważ nie istnieje ogólna podstawa do interpretowania miar bez posiadania zdefiniowanych procesów. Dane zbierane są indywidualnie z poszczególnych procesów, a niektóre wymiary mają duże znaczenie w obrębie całego projektu. Stąd takie rozdzielenie wpływa niekorzystnie na wzrost zrozumienia procesu tworzenia oprogramowania. Przy braku zdefiniowanych procesów jest niezwykle trudno dokonywać pomiarów z powodu dużych zmienności w mierzonych projektach.
Próba zaimplementowania procesu optymalizującego (5) przy braku procesu zarządzanego ma również małą szansę powodzenia z powodu braku zrozumienia działania zmian procesu. Nie kontrolujemy procesu w odpowiednio wąskich granicach, istnieją zbyt duże zmienności miary procesu . W danych jest dużo szumu i trudno jest określić obiektywnie, czy odpowiednie udoskonalanie procesu przynosi jakikolwiek efekt. Dlatego też wiele decyzji może być podejmowanych pochopnie i błędnie.
Wysiłek wkładany w udoskonalanie procesu powinien koncentrować się na potrzebach organizacji w kontekście ich środowiska. Możliwość implementowania procesów z wyższych poziomów dojrzałości nie oznacza, że poziomy mogą być pomijane.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.