Źródła Capability Maturity Model
Wyprodukowanie na czas niezawodnego i użytecznego oprogramowania przy jednoczesnym nieprzekroczeniu zakładanego wcześniej budżetu jest dla wielu firm zadaniem skrajnie trudnym. Wiele produktów jest dostarczanych zbyt późno, koszty są zazwyczaj większe od zakładanych, a same produkty nie spełniają założonych kryteriów jakościowych. Rodzi to problemy zarówno u samych producentów oprogramowania, jak i u ich klientów. Rozpoczynają się coraz to większych rozmiarów projekty i wyżej wymienione problemy nabierają dużego znaczenia. Ich pokonanie jest możliwe poprzez skoncentrowanie się na wysiłkach w budowaniu infrastruktury efektywnej inżynierii oprogramowania i praktyk zarządzania.
Aby zbudować tą infrastrukturę, organizacje produkujące oprogramowanie potrzebują metod oceny ich zdolności do przedstawienia procesu tworzenia oprogramowania. Potrzebują także wskazówek i kierownictwa, aby poprawić zdolność przetwarzania, a naczelni dostawcy oprogramowania potrzebują efektywniejszych metod szacowania zdolności organizacyjnych.
Proces dojrzały i niedojrzały
Proces tworzenia oprogramowania w organizacjach niedojrzałych jest wynikiem improwizacji i eksperymentów inżynierów praktyków i kadry zarządzającej w trakcie trwania projektu. Nawet jeśli proces wcześniej był sprecyzowany, nie jest on rygorystycznie przestrzegany i egzekwowany. Managerowie często koncentrują uwagę na rozwiązywaniu bardziej szczegółowych kwestii i problemów, a przy tym nie potrafią objąć i zapanować nad całym procesem, który w miarę postępowania prac nad projektem coraz bardziej wymyka się spod kontroli. Plany i budżet są rutynowo przekraczane, ponieważ nie opierają się na realistycznej ocenie stanu. Aby terminowo wykonać plany, zaniedbuje się często jakość produktu i jego funkcjonalność.
Oprócz tego, nie ma obiektywnej podstawy do oceniania jakości produktu ani do rozwiązywania problemów związanych z produktem czy procesem. Dlatego też jakość jest trudna do przewidzenia. Czynności podnoszące jakość, takie jak przeglądy i testy są ograniczane z powodu naglących terminów.
Z kolei organizacja dojrzała posiada zdolność zarządzania tworzeniem i utrzymywaniem procesu. Proces tworzenia oprogramowania precyzyjnie komunikuje się z personelem i wszystkie czynności przeprowadzane są zgodnie z zaplanowanym procesem. Jeśli zachodzi potrzeba, zdefiniowany proces jest uaktualniany i udoskonalany na podstawie wyników pilotażowych testów i analizy opłacalności. Role i odpowiedzialności w obrębie procesu są jasne i zdefiniowane w całym projekcie.
Ważną cechą dojrzałej organizacji jest przewidywalność. Na podstawie odpowiednich analiz można przewidzieć koszty, terminy zakończenia prac, potrzebne zasoby, stopień ryzyka, itd. dla danego przedsięwzięcia.
W organizacji dojrzałej kontrolowana jest jakość produktu software‘owego i satysfakcja klienta. Istnieje obiektywna ilościowa baza do oceniania jakości produktu i analizowania problemów związanych z produktem i procesem. Plany i koszty opierają się na poprzednich doświadczeniach i są realistyczne, a wymagana jakość produktu jest zazwyczaj osiągana. Specyfikacja procesu jest ściśle przestrzegana i pracownicy rozumieją znaczenie tego faktu, wiec istnieje infrastruktura niezbędna do wspierania procesu.
Na podstawie tych obserwacji został skonstruowany szkielet dojrzałego procesu tworzenia oprogramowania. Opisuje on, jaka jest droga od chaotycznego procesu ad-hoc do zdyscyplinowanego dojrzałego procesu. Bez tego szkieletu programy poprawy mogą okazać się nieefektywne, gdyż brakuje fundamentu do wspierania kolejnych udoskonaleń.
Podstawowe pojęcia leżące u podstaw dojrzałości procesu
Podamy teraz definicje kilku kluczowych pojęć często używanych w tej części pracy.
Według słownika Webster proces to „system operacji przy produkowaniu czegoś ... cykl akcji, zmian albo funkcji które osiągają określony rezultat”. IEEE definiuje proces jako „sekwencję kroków wykonywanych w zadanym celu” [IEEE-STD-610]. Możemy zdefiniować proces tworzenia oprogramowania jako zestaw czynności, metod, praktyk i transformacji, które używane są do tworzenia i utrzymywania oprogramowania i związanych z nim produktów. Wraz z rozwojem dojrzałości organizacji proces jest coraz lepiej zdefiniowany i bardziej konsystentnie implementowany.
Wydajność procesu tworzenia oprogramowania opisuje zakres oczekiwanych rezultatów, które mogą być osiągnięte przez proces. Wydajność procesu tworzenia oprogramowania organizacji dostarcza jej środków do przewidywania wyników następnych podejmowanych projektów.
Dojrzałość procesu tworzenia oprogramowania jest stopniem, w którym określony proces jest explicite zdefiniowany, zarządzany, mierzalny, kontrolowany i efektywny. Dojrzałość implikuje potencjał dla wzrostu wydajności i wskazuje konsystencje, z jaką proces jest stosowany w projekcie. Proces jest dobrze rozumiany w dojrzałych organizacjach poprzez dokumentację i szkolenia. Proces jest ciągle monitorowany i udoskonalany. Wydajność dojrzałego procesu tworzenia oprogramowania jest znana. Dojrzałość implikuje to, że produktywność i jakość procesu tworzenia oprogramowania może ulegać poprawie poprzez osiąganie lepszej dyscypliny w procesie.
Przegląd modelu CMM
Pomimo, że inżynierowie i kadra zarządzająca często znają swoje problemy w szczegółach, to nie zawsze się zgadzają, która droga poprawy jest właściwa. Bez zorganizowanej strategii poprawy trudno jest osiągnąć porozumienie pomiędzy zarządzającymi i personelem specjalistów co do tego, które czynności mają być podjęte najpierw. Aby osiągnąć trwały sukces w staraniach o poprawę procesu, konieczne jest zaprojektowanie ewolucyjnej ścieżki, która stopniowo zwiększa dojrzałość procesu tworzenia oprogramowania organizacji. Model dojrzałości porządkuje fazy i kroki w taki sposób, że każdy poziom dojrzałości dostarcza podstawy pod budowanie poziomów następnych. Strategia wynikająca z CMM dostarcza planu ciągłej poprawy procesu, wspiera rozwój i określa braki i słabości organizacji. Dzieje się to na długiej drodze i jest to coś zupełnie innego, niż rozwiązywanie chwilowych problemów.
Capability Maturity Model dostarcza organizacjom software’owym wskazówek, jak zyskać kontrolę nad swoimi procesami rozwijając i konserwując oprogramowanie oraz kulturę inżynierii oprogramowania i jej zarządzania.
Wielopoziomowa struktura CMM opiera się na zasadach jakości produktu, które istnieją już prawie 70 lat. W latach trzydziestych Walter Shewart ogłosił zasady statystycznej kontroli jakości. Jego zasady zostały następnie rozwinięte i przedstawione w pracy Edwarda Deminga [Deming 86] i Josepha Jurana [Juran 88, Juran 89]. Te zasady zostały ostatecznie zaadoptowane przez SEI4 do schematu dojrzałości CMM, który stanowi podstawę dla inżynierów i kadry zarządzającej do ilościowej kontroli procesu tworzenia oprogramowania.
Schemat dojrzałości, który zaadoptował powyższe zasady jakości został po raz pierwszy zaproponowany przez Philipa Crosby w jego pracy Quality is Free [Crosby 79]. System dojrzałości Crosby’ego określa pięć następujących po sobie ewolucyjnych poziomów. Ten schemat został następnie przyjęty przez Rona Radice i jego współpracowników pracujących pod kierunkiem Wattsa Humphrey’a (IBM) [Radice 85]. Humphrey przeniósł ten schemat na grunt Software Engineering Institute i rozwinął jego założenia dostosowując je do obecnych zastosowań w przemyśle software’owym.
Wcześniejsze wersje schematu dojrzałości Humhprey‘a są opisane w technicznych raportach SEI [Humhprey 87a, Humhprey 87b] oraz w jego pracy Managing the Software Process [Humphrey 89]. Wstępny kwestionariusz dojrzałości [Humhrey 87b] został wydany w 1987 roku i służył jako narzędzie pozwalające organizacjom na scharakteryzowanie dojrzałości ich procesów tworzenia oprogramowania. Wtedy też rozwinęły się dwie metody oceny dojrzałości procesu: ocena procesu (software process assessment) i ewaluacja wydajności (software capability evaluation). Od 1990 roku SEI z pomocą organizacji rządowych i przedstawicieli przemysłu wciąż rozwija i redefiniuje model opierając się na wielu latach doświadczeń w tej dziedzinie.
komentarze
Copyright © 2008-2010 EPrace oraz autorzy prac.