Wdrażanie technologii CASE (cz. IV)

W poprzednim odcinku staraliśmy się scharakteryzować pojęcie procesu produkcji oprogramowania, pomagając sobie analogią między wyimaginowaną fabryką systemów informatycznych a fabryką samochodów. W tym odcinku przedstawimy model, który pozwala na lepsze zrozumienie procesu produkcji oprogramowania i - co najważniejsze - na właściwą ocenę poziomu umiejętności organizacji zajmujących się tworzeniem programów.

W poprzednim odcinku staraliśmy się scharakteryzować pojęcie procesu produkcji oprogramowania, pomagając sobie analogią między wyimaginowaną fabryką systemów informatycznych a fabryką samochodów. W tym odcinku przedstawimy model, kóry pozwala na lepsze zrozumienie procesu produkcji oprogramowania i - co najważniejsze - na właściwą ocenę poziomu umiejętności organizacji zajmujących się tworzeniem programów.

Process Management a Project Management

Zacznijmy od podstaw, czyli od zarządzania procesem produkcji oprogramowania ( process management). Termin ten wystąpił kilkakrotnie w naszych artykułach i czas go wreszcie wyjaśnić. Aby jednak wyjaśnić czym JEST process management, wyjaśnimy najpierw, że NIE jest to project management. Niektórym oba terminy mogą się mylić, toteż należy chyba zacząć od pokazania różnicy.

Project management to zespół działań, które mają za zadanie doprowadzenie konkretnego projektu informatycznego do szczęśliwego zakończenia. Zakłada się przy tym, że szczęśliwe zakończenie jest precyzyjnie zdefiniowane i ma być osiągnięte w oznaczonym czasie, przez określonych ludzi, za określone pieniądze i według ustalonego planu. Istnieje wiele metod zarządzania projektami i wszyscy, którzy muszą, jakoś sobie z nimi dają radę.

Zarządzanie projektami informatycznymi związane z różnymi zagadnieniami odnoszącymi się bezpośrednio do projektów informatycznych np. z zarządzaniem konfiguracjami projektów, organizacją i podziałem pracy, sporządzaniem harmonogramów, kontrolą jakości, etc. Wszystkie te elementy składają się razem na proces produkcji oprogramowania.

Czy potrzebne jest coś jeszcze? Owszem - wprawdzie potrafimy jakoś dawać sobie radę z zarządzaniem projektami, ale nie chodzi przecież tylko o to, by doprowadzać kolejne z nich do udanego zakończenia. Chcielibyśmy jeszcze, aby każdy następny projekt był przeprowadzony lepiej od poprzedniego.

Od razu nasuwają się pytania:

* Co to znaczy "lepiej"? Kiedy jest "źle" a kiedy "dobrze"? Czy czas i pieniądze są obiektywnymi miarami?

* Jakie są poziomy umiejętności wytwarzania oprogramowania?

* Jak osiągać coraz wyższe poziomy umiejętności? Jak stwierdzić, że się je osiągnęło?

Głębokie zastanowienie się nad sensem tych pytań prowadzi do podstawowej koncepcji zarządzania procesem produkcji oprogramowania, tzn. ciągłego "mierzenia" i "ważenia" różnych aspektów tego procesu, co umożliwia prowadzenie takich działań, które pozwalają na stałą poprawę i stopniowe wznoszenie się na kolejne poziomy umiejętności. I to jest właśnie process management.

Capability Maturity Model

Idea zarządzania procesem produkcji oprogramowania jest oczywiście pochodną badań nad jakością prowadzonych w innych gałęziach przemysłu (np. doświadczeń zebranych przy odbudowie Japonii po II Wojnie Światowej). Bezpośrednie zaaplikowanie wyników tych badań do produkcji oprogramowania nie było jednak możliwe, toteż ważnymi etapami w rozwoju inżynierii oprogramowania były inicjatywy standaryzacyjne podejmowane przez takie organizacje jak Departament Obrony USA, ISO, ANSI lub IEEE.

Najciekawszym, naszym zdaniem, rezultatem wielu lat doświadczeń i badań nad specyfiką produkcji oprogramowania jest Capability Maturity Model (z braku lepszego pomysłu nazwiemy go Modelem Dojrzałości i Umiejętności), w skrócie CMM, dający podstawy do zrozumienia, czym właściwie jest produkcja oprogramowania, gdzie tkwi jej specyfika, jakie główne komponenty składają się na proces tworzenia programów i co w związku z tym należy zrobić, aby tworzyć je jak najlepiej.

Model ten powstał w USA, a jego twórcą jest amerykański Software Engineering Institute (SEI) działający przy Carnegie Mellon University. CMM stosowany jest coraz szerzej przez coraz większą liczbę organizacji, które dostrzegły jego ogromną wartość praktyczną. Prace nad nim prowadzone były w drugiej połowie lat 80. i są prowadzone obecnie zarówno przez SEI, jak i organizacje komercyjne ("przemysłowe" adaptacje CMM opracowane przez Learmonth & Burchett Management Systems lub James Martin & Co.). Dostępne są już na rynku pierwsze książki poświęcone tej tematyce, pojawiły się także pierwsze programy wspomagające Process Management "w duchu" CMM.

W ogromnym uproszczeniu można powiedzieć, że na CMM składają się opisy pięciu poziomów dojrzałości (ang. maturity levels) procesu produkcyjnego oprogramowania. Każdy z tych poziomów dojrzałości wyznacza charakterystyczną dla niego, maksymalną, możliwą do osiągnięcia, wydolność procesu produkcji oprogramowania ( process capability). Oszacowanie wydolności procesu produkcji danej organizacji daje możliwość przewidywania rezultatów, które mogą być oczekiwane w wyniku przeprowadzenia przez tę organizację projektu informatycznego. Jednocześnie, aby osiągnąć dany poziom dojrzałości, potrzebne jest spełnienie pewnych warunków, tzn. podjęcie działań w tych sferach działalności ( key process areas), które na danym poziomie uważa się za ważne, np. zarządzanie projektami i wymaganiami, czy planowanie projektów.

Pełny opis CMM jest długi i nie mamy, niestety, miejsca na jego przedstawienie. Spóbujemy zatem nieformalnie opisać każdy z pięciu poziomów CMM posługując się przykładem firmy produkującej oprogramowanie "pod klucz".

Poziom 1. Chaotyczny. Na tym poziomie firma zazwyczaj nie jest stabilnym środowiskiem do tworzenia i pielęgnowania oprogramowania. Zaniedbuje się podstawowe mechanizmy zarządzania projektami, toteż korzyści płynące z umiejętności inżynierskich są niweczone nieefektywnym planowaniem i reaktywnymi metodami działania. Jeśli następuje kryzys, zazwyczaj porzuca się ustalone procedury pracy i wszyscy "rzucają się" do kodowania oraz testowania. Sukces zależy wyłącznie od tego, czy ma się dobrego kierownika projektu i zaprawiony w bojach zespół programistów. Jeżeli nawet niektórzy szefowie projektów są w stanie odeprzeć pokusę "pójścia na skróty", to ich stablizujący wpływ znika wraz z nimi.

Na poziomie 1 wydolność procesu produkcji oprogamowania jest nieprzewidywalna, ponieważ podejście do projektów jest nieustannie zmieniane ad hoc, w miarę postępu prac. Harmonogramy prac, budżet, funkcjonalność i jakość powstających programów nie dają się przewidzieć. Wyniki zależą głównie od cech indywidualnych i poziomu umiejętności poszczególnych pracowników i nie mają związku z praktyką funkcjonowania firmy jako całości.

Poziom 2. Powtarzalny. Na poziomie powtarzalnym prowadzona jest polityka zmierzająca do sprawnego zarządzania projektami informatycznymi, wdrożone są również procedury pracy służące osiągnięciu tego celu. Planowanie i zarządzanie bazuje na doświadczeniu uzyskanym w podobnych projektach. Głównym celem na poziomie 2 jest instytucjonalizacja efektywnych procesów zarządzania projektami, co pozwala firmie na wykorzystywanie praktyk opracowanych w poprzednich projektach oraz na nieprzypadkowe powtarzanie już osiągniętych sukcesów.

Poziom 3. Zdefiniowany. Na poziomie 3 sposób tworzenia i pielęgnacji oprogramowania w firmie jest dokumentowany, zarówno jeśli chodzi o sferę inżynierską, jak i procedury zarządzania, a procesy te są zintegrowane w całość. Istnieje całościowy "standardowy proces produkcji oprogramowania", który jest wykorzystywany zarówno przez kadrę kierowniczą, jak i personel techniczny, co istotnie podnosi efektywność działania. Funkcjonuje grupa pracowników odpowiedzialna za pielęgnację procesu produkcji oprogramowania. Wdrożony jest program szkoleń, dzięki któremu każdy pracownik firmy zna dokładnie swoje zadania i ma umiejętności niezbędne do ich realizacji.

Poziom 4. Zarządzany. Na poziomie 4 ustanowione są cele i mierzalne kryteria dotyczące zarówno jakości procesu produkcji oprogramowania, jak i samych produktów. Produktywność i jakość osiągane w kolejnych projektach są mierzone i są częścią ogólnego programu mierzenia wszystkiego, co dotyczy działalności informatycznej firmy. Baza danych, zawierająca opis procesu produkcji oprogramowania, zawiera również dane ilościowe opisujące przeprowadzone dotąd projekty, co pozwala na analizowanie zgromadzonych danych i daje podstawy do oceny procesu produkcji.

Poziom 5. Optymalizowany. Na tym poziomie firma koncentruje się na ciągłym optymalizowaniu swojego procesu produkcji oprogramowania. Istnieją środki do identyfikacji i oceny silnych oraz słabych stron stosowanego procesu produkcyjnego, co pozwala na przewidywanie możliwości wystąpienia defektów i zapobieganie im. Dane o wydajności procesu produkcyjnego są wykorzystywane do analizowania kosztów i korzyści wynikających z wprowadzenia nowych technologii lub proponowanych zmian w procesie produkcyjnym.

Czy to tylko teoria? W tabeli 1 zamieszczono wyniki badań ilościowych przeprowadzonych przez SEI w 1991 r. Badania te miały za zadanie ocenić, jak wiele organizacji zajmujących się inżynierią oprogramowania znajduje się na poszczególnych poziomach rozwoju (w nawiasach podano wyniki analogicznych badań z 1988 r.).

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

TOP 200