Twórcy CMM zwracają uwagę, że mimo to firmy znajdujące się na podstawowym poziomie dojrzałości (czy raczej niedojrzałości) wprowadzają zupełnie dobre produkty. Podkreślają jednak, że dzieje się tak nie ze względu na to, że taka organizacja firmy jest dobra, a z powodu ponadprzeciętnych umiejętności wielu informatyków, ich oddania, wytężonej pracy i tolerancji klientów na błędy.

Powtarzalność przeciw chaosowi

Kluczową rolę w CMM ma poziom drugi, powtarzalny. Przejście między pierwszym a drugim poziomem jest zasadniczym skokiem jakościowym: od chaosu do porządku. Powtarzalność procesu na drugim poziomie oznacza, że przedsiębiorstwo jest w stanie wprowadzić produkt podobnego typu o podobnej jakości także za drugim i każdym następnym razem. Sześć obszarów działań tego poziomu określa wszystko to, co jest pierwszym krokiem do świadomego zarządzania procesem informatycznym: zarządzanie wymaganiami, planowanie projektu informatycznego (pojedynczego), śledzenie go i przewidywanie, zarządzanie podwykonawstwem, zapewnienie jakości i zarządzanie konfiguracją.

Inżynieria wymagań to najczęściej zaniedbywana część procesu tworzenia oprogramowania. Niesłusznie, bo co komu z oprogramowania, które co prawda jest dobre pod względem technicznym, ale nie zaspokaja potrzeb klienta. Dobrze przeprowadzona inżynieria wymagań jest o tyle istotna, że mało który klient potrafi dobrze wyartykułować swoje potrzeby i trzeba nie lada talentu, aby stworzyć dobry dokument je opisujący. CMM wiele uwagi poświęca tej części procesu, doradzając zawarcie wymagań w dokumencie, który jest przedmiotem akceptacji zarówno ze strony klienta, jak i zespołu zarządzającego projektem. Rozdzielono wymagania od przydzielonych wymagań (allocted requirements) - te pierwsze to wszelkie potrzeby klienta, a te drugie to tylko takie, które produkt informatyczny ma rozwiązywać. Warto przytoczyć zdanie, które przy okazji pada w podręczniku do CMM: "Analiza i przydzielanie wymagań nie jest odpowiedzial- nością grupy tworzącej oprogramowanie, ale warunkiem koniecznym rozpoczęcia przez nich pracy". Jakże często w polskich realiach - i nie tylko polskich - informatycy przystępują do pracy, zanim dokładnie poznają potrzeby klienta.

Nie sposób całkowicie rozdzielić zarządzania wymaganiami od zarządzania projektem. Przecież jeżeli w programie obsługującym imprezy masowe klient potrzebuje funkcji wydruku biletów, to konieczne jest stworzenie modułu cen, modułu seansów i modułu wydruków. A stąd już krok do planowania projektu, gdyż każdy z tych nich musi być stworzony rękami zespołu lub podwykonawcy albo zostać zakupiony na rynku. W kontekście zarządzania projektem informatycznym CMM przytacza typowe sposoby zarządzania przedsięwzięciami: określenie produktów, dat ich zakończenia, kamieni milowych, budżetu i składu zespołów itd. Model zaleca także posługiwanie się narzędziami informatycznymi typu Microsoft Project czy nawet arkusze kalkulacyjne, aby obliczyć podstawowe parametry projektu. Kierownik projektu powinien zdecydować się także na jeden z modeli cykli życia produktu informatycznego (model kaskadowy, spiralny, nakładający się kaskadowy itd.). Nie zaleca konkretnego (choć może przydałoby się, zważywszy na znane wady choćby modelu kaskadowego), ale mówi: cokolwiek zdecydujesz, bądź świadom swojej decyzji i jej konsekwencji.

Zarządzanie podwykonawstwem oznacza świadome i zorganizowane znalezienie wykonawcy danego, wydzielonego fragmentu oprogramowania, określenie mu standardów jakości i interfejsu, a także określenie dokładnie tego co, kiedy i w jaki sposób ma dostarczyć. Dodajmy, że CMM nie zawęża rozumienia "podwykonawców" do firm zewnętrznych, ale także jako poszczególnych pracowników (jeżeli pracują oni np. w modelu telepracy).

Jakość oprogramowania to kolejny temat, który jest kluczowy dla drugiego poziomu mode- lu CMM. Aby firma mogła powiedzieć o sobie, że znajduje się na drugim poziomie CMM, musi wykazać się posiadaniem m.in. grupy odpowiedzialnej za zapewnienie jakości, planu testów, automatycznych procedur testowych, zbioru zalecanych praktyk programistycznych itd. Działania związane z testowaniem oprogramowania powinny być dokumentowane, a radzenie sobie z błędami powinno przebiegać według określonej i opisanej procedury. Grupa odpowiedzialna za jakość powinna uczestniczyć w przeglądach, co wydaje się naturalne, zważywszy że niedostateczna jakość oprogramowania jest najczęstszą przyczyną opóźnień w projekcie.

Zarządzanie konfiguracją, ostatni z obszarów aktywności na drugim poziomie CMM, to przede wszystkim stosowanie narzędzi informatycznych do centralizacji źródeł, udokumentowane uaktualnienia do tych źródeł, posiłkowanie się procedurami włączania elementów oprogramowania w produkt finalny itd. Większość firm informatycznych stosuje narzędzia pozwalające na kontrolę wersji, które rozwiązują większość problemów z tego obszaru aktywności.

Podsumowując drugi poziom modelu CMM, należy powiedzieć, że większość istotnych wyznaczników dobrze zarządzanego procesu informatycznego pojawia się już tutaj. Tworzenie powtarzalnego oprogramowania to bardzo dużo na ścieżce przedsiębiorstwa do organizacyjnej doskonałości.