Po trzecie: zdefiniowany

O "oczko" wyżej od poziomu powtarzalnego znajduje się poziom zdefiniowany. Nacisk w nim jest położony na działania wyższego rzędu niż na drugim poziomie: integrację, definicję procesów, standaryzację i koordynację. Przytoczmy kluczowe obszary działań trzeciego poziomu CMM: koncentracja na procesach, ich definicja, program szkoleń, zintegrowane zarządzanie oprogramowaniem, inżynieria produktu, koordynacja międzyzespołowa oraz przeglądy partnerskie.

Zanim omówimy je pokrótce, warto powiedzieć, że potrzeba wdrożenia wielu praktyk z trzeciego poziomu CMM pojawia się dopiero w firmie średniej wielkości. Na przykład w firmie kilkuosobowej, która na dodatek zatrudnia pracowników nie częściej niż raz na rok, nie ma raczej potrzeby tworzenia kosztownych procedur wdrożenia ich w pracę.

Nie znaczy to jednak, że żaden element z trzeciego poziomu CMM nie może być zastosowany nawet w najmniejszej firmie. Najważniejszym chyba obszarem działań są koncentracja na procesach i ich zdefiniowanie. Na przykład na poprzednim poziomie wspomniano, że kierownik projektu powinien zdecydować się na jakiś model cyklu życia produktu (kaskadowy, spiralny itp.). Na trzecim poziomie, jak sama jego nazwa wskazuje, powinien być zdefiniowany cykl życia procesów w organizacji, a poszczególne projekty powinny przestrzegać tego standardu. Podobne zasady powinny być stworzone i - uwaga! - przejrzyście udokumentowane dla innych dziedzin: inżynierii wymagań, kodowania, projektowania, testów, interfejsu użytkownika.

Osobnym tematem są szkolenia. Trzeci poziom CMM wymaga, aby wdrożenie nowego pracownika w prace zespołu informatycznego było ujęte w szkolenie, z programem, opiekunem szkolenia i dokumentacją wyników.

Znalezienie się na poziomie zdefiniowanym wymaga już szerszego zastosowania narzędzi informatycznych wspomagających pracę twórców oprogramowania i menedżerów. Przykładem jest wewnętrzna, intranetowa baza wiedzy, która powinna się pojawić w firmie, jeżeli chce ona sprostać wymogom trzeciego poziomu CMM.

Na koniec opisu trzeciego poziomu CMM poświęćmy trochę uwagi przeglądom partnerskim (peer reviews). W typowym przedsiębiorstwie pojęcie to jest zawężane do przeglądów kodu, które jeden informatyk robi dla drugiego informatyka (częściej: przeciwko drugiemu informatykowi).

Przeglądy partnerskie w rozumieniu CMM mają szersze zadania, bo obejmują także modele projektowe, architekturę systemu, wymagania i akcentują wiele perspektyw takiego przeglądu. Oczywiście przede wszystkim chodzi o poprawność, ale także kompletność rozwiązania, stosowanie się do standardów i reguł, a także - co bardzo ważne - możliwość utrzymania i rozwijania rozwiązania w przyszłości.

Cztery razy zarządzanie

Czwarty poziom modelu CMM mógłby się także nazywać poziomem "mierzonym". Kluczowym jego wyznacznikiem jest bowiem zdefiniowanie, udokumentowanie i zbieranie miar, czyli ilościowa kontrola procesu informatycznego. Na tym poziomie są zdefiniowane jedynie dwa kluczowe obszary działań: zarządzanie ilościowe procesem oraz zarządzanie jakością oprogramowania.

Zarządzanie ilościowe procesem jest stosunkowo jasne i mimo że znajduje się aż na czwartym poziomie CMM, to jest obecne w wielu polskich przedsiębiorstwach. Przede wszystkim firma powinna zbierać w standardowy sposób dane dotyczące budowy systemów: a więc liczbę godzin poświęconych na realizację zadania, liczebność zespołów, inwestycje w narzędzia, godziny szkoleń i wydatki na nie itd. Dane te powinny być systematycznie obrabiane (tj. za pomocą metod statystycznych), by uzyskać dane syntetyczne. Na przykład mierzymy liczbę roboczogodzin poświęconych na budowę poszczególnych cech określonych w planie projektu, a następnie obliczamy średnią, odchylenie standardowe, odchylenie od przewidzianej wartości itd.

Zarządzanie jakością oprogramowania z grubsza obejmuje to samo, co zarządzanie procesem, tylko brane są pod uwagę dane dotyczące jakości, a więc liczba błędów, godziny testów, przeglądy, zgodność z planem i przydzielonymi wymaganiami; wreszcie ogólny koszt wytworzenia jednej cechy w oprogramowaniu.