Informatyka czasu dojrzałości

Lata 80. w informatyce upłynęły na szukaniu "srebrnej kuli" - technologii, języka programowania, metodyki itd., która natychmiast i na zawsze rozwiązałaby kryzys inżynierii oprogramowania. Z początkiem lat 90. zdano sobie sprawę, że nie da się wytwarzać coraz bardziej złożonego oprogramowania do coraz trudniejszych zadań, jeżeli nie dopracuje się procesu jego tworzenia. Tak narodziło się zarządzanie projektem informatycznym, a wraz z nim pojawiły się modele dojrzałości organizacyjnej. Najbardziej znany z nich to Capability Maturity Model.

Lata 80. w informatyce upłynęły na szukaniu "srebrnej kuli" - technologii, języka programowania, metodyki itd., która natychmiast i na zawsze rozwiązałaby kryzys inżynierii oprogramowania. Z początkiem lat 90. zdano sobie sprawę, że nie da się wytwarzać coraz bardziej złożonego oprogramowania do coraz trudniejszych zadań, jeżeli nie dopracuje się procesu jego tworzenia. Tak narodziło się zarządzanie projektem informatycznym, a wraz z nim pojawiły się modele dojrzałości organizacyjnej. Najbardziej znany z nich to Capability Maturity Model.

Software Engineering Institute (SEI) z Carnegie Mellon University mieści się w Pittsburghu. Wschodnie wybrzeże USA zawsze znane było z innego podejścia do informatyki niż Kalifornia. Gdy w Krzemowej Dolinie królowały marzenia, spontaniczność i Internet, a informatyczne fortuny powstawały i upadały w zawrotnym tempie, po drugiej stronie kontynentu próbowano znaleźć odpowiedź na kilka prostych pytań: Co sprawia, że jedne programy są dobre, a inne złe? Dlaczego jedne firmy robią zawsze dobre oprogramowanie, a innym zdarzają się ewidentne buble? Jakie praktyki organizacyjne pomagają w zapewnieniu jakości oprogramowania? W jaki sposób można zmierzyć, czy projekt informatyczny jest prowadzony dobrze czy źle. Wynikiem tej pracy stał się właśnie Capability Maturity Model (CMM).

Czym jest Capability Maturity Model

Najogólniej mówiąc, to model pozwalający na zakwalifikowanie procesu tworzenia oprogramowania w organizacji do jednego z pięciu poziomów: Podstawowego (Initial), Powtarzalnego (Repeatable), Zdefiniowanego (Defined), Zarządzanego (Managed) i Optymalizującego (Optimizing).

Same nazwy dają już duże pojęcie o celu istnienia modelu i jego treści, ale oczywiście naukowcy z SEI nie zatrzymali się na tym etapie. Dla każdego z poziomów składających się na ten model (z wyjątkiem pierwszego) zdefiniowano kluczowe obszary działań (key process area). Przykłady takich obszarów działań to np. planowanie projektu (na poziomie drugim) albo program szkoleń (na poziomie trzecim).

Dla każdego obszaru działań określono jego cele (goals), zobowiązania (commitment to perform), praktyki (ability to perform), działania (activities performed), miary i analizy (measurement and analysis) oraz sposoby weryfikacji (verifying implementation). Aby lepiej je przybliżyć, przyjrzyjmy się wszystkim elementom obszaru działań, określonego jako planowanie projektu (na poziomie drugim).

Jednym z celów, które tam zdefiniowano, jest to, że prace i role w projekcie zaplanowano i udokumentowano. Wynika z tego zobowiązanie, że projekt musi posiadać swojego kierownika, którego odpowiedzialnością jest wynegocjowanie ról w zespole oraz stworzenie planu projektu. Praktyką takiego projektu powinno być, aby istniał formalny plan projektu, zawierający następstwo działań, wymagania techniczne, identyfikację docelowego użytkownika, koszty, standardy itd. Oczywiście, konieczne są teraz działania - zaliczymy do nich np. uczestniczenie grupy wykonującej projekt w procesie jego planowania, stworzenie estymacji czasu trwania, rozmiaru i budżetu projektu, a także przewidzenie i opisanie ryzyka związanego z projektem itd. Miarami i analizami będą przede wszystkim kroki milowe projektu, czyli dobrze opisana funkcjonalność tworzonego oprogramowania, umieszczona na osi czasu i w konkretnym budżecie. I wreszcie sposobem weryfikacji będzie przegląd projektu i jego osiągnięć dokonywany przez grupę roboczą.

Widać, że CMM, pomyślany jako metoda certyfikacji, zawiera jednocześnie wiele bardzo praktycznych wskazówek dla szefów projektów informatycznych i ich zespołów, które pozwolą im "wspinać się" po szczeblach drabiny dobrze zarządzanego procesu. Oczywiście na tym pozio- mie ogólności, na jakim jest zdefiniowany CMM, nie można mówić o konkretnych wytycznych dla konkretnego zespołu, pracującego nad konkretnym projektem. Ale zanim przejdziemy do stosowalności CMM w praktyce, warto dokładnie opisać jego poziomy.

Poziom pierwszy, czyli zerowy

Literatura o CMM temu poziomowi poświęca najmniej miejsca. Nic dziwnego - nie ma chyba na świecie informatyka, który nie miałby z nim do czynienia. Brak porządnej inżynierii wymagań, słaba współpraca w zespole, zaniedbana analiza i projekt struktury systemu, spontanicznie rozpoczynane programowanie, brak procedur zapewnienia jakości... w wielu firmach informatycznych, nie tylko w Polsce, to nadal codzienność.

Obok wyznaczników technologicznych takie-go początkowego (chciałoby się powiedzieć: chaotycznego) procesu tworzenia oprogramowania warto wymienić jeszcze wyznaczniki organizacyjne. Nie są jasno określone role w zespole i nie wszyscy mają świadomość wspólnego celu (o ile taki cel jasno postawiono...). Ludzie czują się zmęczeni i skłóceni, systematycznie przekraczany jest czas lub budżet (a najczęściej jedno i drugie), zaś kierownik projektu raczej reaguje na bieżące trudności, niż stara się im aktywnie przeciwdziałać.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200