CMM Przekierowano ze strony: Capability Maturity Model ang. Capability Maturity Model

CMM
Model
Zarządzanie dojrzałością
WłaścicielCarnegie Mellon University
RozpowszechnianieSoftware Engineering Institute
Powstanie1991
Aktualna wersja1.1
Oficjalna strona internetowa


CMM - stworzony przez Software Engineering Institute (SEI) model przeznaczony do oceny procesu wytwórczego służącego do produkcji oprogramowania. CMM ocenia praktyki stosowane podczas produkcji. Model ocenia proces w skali pięciostopniowej - od chaotycznego (nic nie jest sterowane ani kontrolowane), aż do ścisłego, zdyscyplinowanego procesu uwzględniającego wszystkie potrzebne aspekty.

Spis treści

Rozwój standardu

Lata 70. i 80. XX był okresem wzmożonego rozwoju informatyki i przemysłu informatycznego, który zaczął na niespotykaną do tej pory skalę produkcję sprzętu, oprogramowania, systemów. Rosło także zapotrzebowanie na systemy oparte na sieciach komputerowych. Ów wzrost w branży wpłynął na intensyfikacje realizowanych projektów. Niestety ilość nie szła w parze z jakością. Rychło okazało się, że w wielu przypadkach realizacja projektów o czasie, w zgodzie z zakładanym budżetem była niemożliwa a zakładane progi przekraczano nawet o kilkaset procent. Pierwszy sygnał ostrzegawczy i jednocześnie impuls do zmian wypłynął z Departamentu Obrony Narodowej USA, w związku z niezadowoleniem agencji z jakości oprogramowania zamówionego na potrzeby armii.

Zły software źle wpływał na funkcjonowanie armii i zmniejszało jej zdolność militarną, co w latach 80. było kluczowe dla polityki USA. Z pomocą przyszło SEI, które miało opracować narzędzie weryfikujące dostawców oprogramowania. W związku z tym w roku 1987 powstał pierwszy szkic CMM, lecz dopiero w 1991 opublikowano pierwszy oficjalny opis modelu dojrzałości projektowej czyli tzw. Software Capability Maturity Model v. 1.0. Model ten obejmował swym zakresem tylko proces produkcji i dostarczania oprogramowania. Mimo ograniczonego zakresu przyczynił się on do znacznego wzrostu odsetka projektów realizowanych w terminie, w zgodzie z budżetem i założeniami.

Rychło okazało się, że CMM w wersji 1.0 jest bardzo atrakcyjnym modelem dla firm sektora prywatnego. Firmy zaczęły niebawem domagać się podobnego modelu dla innych obszarów działalności biznesowej. SEI podjęło decyzję o pracach nad nowym modelem. Efektem ich prac było CMM v. 1.1 z 1993 roku oraz kilka nowych narzędzi. CMM został opisany w książce z roku 1995 przez Marka C. Paulka, Charlesa V. Webera, Billa Curtisa oraz Mary Beth Chrissis.

Zastosowanie

Oprogramowanie staje się coraz bardziej złożone i coraz ważniejsze staje się jego niezawodne działanie. Dotrzymanie terminów, zmieszczenie się w budżecie i przede wszystkim sama realizacja warunków zlecenia stają się coraz trudniejsze do spełnienia. Organizacje potrzebują zatem metod oceny możliwości realizacji kontraktów software’owych niezależnie czy występują w roli wykonawcy, podwykonawcy czy wreszcie zleceniodawcy.

Model CMM dostarczając spójną bazę, na której gruncie można ocenić procesy software’owe pozwala na porównywanie możliwości jednej organizacji z inną. Przyjmując za pożądaną ścieżkę ewolucji organizacji od poziomu nieustrukturyzowanych procesów do najwyższego, optymalizującego, model CMM może być użyty do opracowania strategii firmy. Z modelu wynikają bowiem wprost cele strategiczne, jakie należy osiągnąć aby znaleźć się na kolejnych poziomach rozwoju, łatwo również dobrać drogę dojścia do tego celu czyli określić strategię firmy.

Nieoceniony jest również wkład teoretyczny przy badaniu kierunków rozwoju organizacji nie tylko software'owych. W jednym, zintegrowanym modelu umieszczone zostały odrębnie funkcjonujące techniki i metody co nadaje im inny wymiar. Model CMM może być użyty również do opisu innej niż software'owa działalności inżynierskiej patrz np. Analizując problemy z wdrażaniem informatyki w organizacjach również można posłużyć się koncepcją "dojrzałości procesów", które miałyby być wspomagane technologią informatyczną, pewne próby takiego opisu zawarte są w pracy.

Model dojrzałości CMM może być stosowany jako pewnego rodzaju zestaw uporządkowanych poziomów opisujących, jak dobrze różne działania, praktyki i procesy w organizacji mogą niezawodnie i trwale realizować zamierzone plany biznesowe i generować odpowiedni przychód. Model dojrzałości może podsunąć firmie punkt startowy, zyski wynikające z doświadczeń, wspólny język i wizję, schemat do priorytetyzacji działań, sposób definiowania usprawnień dla organizacji. Model dojrzałości może być także wzorcem porównawczym albo pomocą przy zrozumieniu różnych procesów i procedur np. może wspomagać procesy oceny różnych organizacji, które łączy np. wspólny rynek albo podobny produkt. W przypadku CMM wspólnym obszarem oceny i porównań będą procesy rozwoju oprogramowania.

Opis

Model CMM obejmuje pięć aspektów:
  • Poziomy dojrzałości - pięciostopniowy schemat dojrzałości w którym piąty etap jest swoistym typem idealnym rozwoju projektu, na którym to każdy projekt jest na tyle dobrze zarządzany, że teraz starczy tylko stopniowo ulepszać i optymalizować proces.
  • Kluczowe obszary procesowe - identyfikują one zespół powiązanych działań, które wykonywane wspólnie mogą przyczynić sie do osiągnięcia celów uznanych za ważne. Należą do nich z kolei:
    • przeglądy powykonawcze
    • koordynacja pracy grup
    • inżynieria produktu softwareowego
    • integracja zarządzania softwarem
    • program szkoleń
    • definicja procesów organizacyjnych
    • koncentracja na proc. organizacji
    • zarządzanie jakością procesu
    • mierzalność procesu
    • zarządzanie jakością projektu
    • zarządzanie podwykonawcami
    • nadzorowanie projektów
    • planowanie projektów
    • analiza warunków i wymagań
    • zarządzanie zmianami
    • zarządzanie technologią
    • zapobieganie błędom
  • Cele - cele kluczowych obszarów określają to co musi zostać zrealizowane aby owe obszary zostały odpowiednio zdefiniowane oraz efektywnie zaimplementowane.
  • Atrybuty procesu - pozwalają one na określenie czy stosowanie kluczowych procesów
jest efektywne, powtarzalne i skuteczne. W ich przypadku występuje silne powiązanie z ogólną kulturą organizacyjną firmy. Określone są w pięciu grupach:
    • akceptacja stosowania
    • możliwość stosowania
    • mierzalność
    • analiza
    • weryfikacja implementacji
  • Kluczowe praktyki - opis elementów infrastruktury i działań, które przyczyniają się najskuteczniej do realizacji i określonych obszarów.


Poziomy CMM

W przypadku modelu CMM SEI wyróżnia 5 poziomów określających efektywność, kontrolę i przejrzystość procesów informatycznych w organizacji:
  1. Wstępny (ang. Initial) - oprogramowanie tworzone chaotycznie, bez żadnych formalnych procedur, ewentualnie z takimi, które są szczątkowe - nie określają procesu.
  2. Powtarzalny (ang. Repeatable) - stosowane są podstawowe techniki śledzenia projektu. Śledzi się Koszt, harmonogram oraz funkcjonalność. Stosuje się techniki pozwalające na powtarzanie udanych projektów na podstawie informacji zapisanych przy okazji poprzednich.
  3. Zdefiniowany (ang. Defined) - proces wytwórczy jest opisany, wszystkie wykonywane czynności są udokumentowane w postaci procedur lub instrukcji.
  4. Zarządzany (ang. Managed) - podczas projektów stosuje się szczegółowe metryki dotyczące samego procesu, oraz jakości produktu.
  5. Optymalizujący (ang. Optimizing) - stosuje się praktyki mające na celu ciągłe poprawianie procesu wytwórczego oprogramowania - poprzez monitorowanie procesu pod względem możliwości usprawnień oraz poprzez ich wprowadzanie.

Poziom wstępny

Procesy na 1 poziomie dojrzałości charakteryzują działania ad hoc, spora część prac ma charakter okazjonalny lub chaotyczny. Niewiele elementów procesu na tym poziomie rozwoju jest zdefiniowanych przed rozpoczęciem prac, a i tak efekt zwykle bardziej zależy od indywidualnego układu pracy niż zapisów w planie projektu.

Organizacja prowadząca projekty na poziomie pierwszym charakteryzuje się zwykle brakiem stabilnej technologii wytwarzania i utrzymania produktów. Sukces projektu zależy od charyzmy kierownika projektu i nakładu pracy członków zespołu. Rzadko kierownik projektu zdobywa się na odwagę i odmawia pominięcia rzekomo zbędnych procedur takich jak dokumentowanie czy ponowne testowanie. Zwykle zwyciężają argumenty sponsora wymagającego dotrzymania terminu za wszelką cenę.

Zakres projektu realizowanych na pierwszym poziomie dojrzałości jest zupełnie nieprzewidywalny. Sposób wykonywania, podobnych w gruncie rzeczy, prac podlega stałym zmianom generowanych potrzebą chwili. Harmonogram i budżet funkcjonalności oraz jakość wykonywanego produktu jest w zakresie nieprzewidywalna. Także wydajność pracy bardziej zależy od indywidualnych umiejętności i zaangażowania, niż od skutecznego wykorzystanie posiadanych zasobów. Parametry procesu nad którym sprawuje się kontrolę, stanowią zdecydowaną mniejszość w zbiorze parametrów procesu produkcji.

Poziom powtarzalny

Proces wymaga od członków zespołu coraz to bardziej efektywnej pracy, zdobywanie nowych umiejętności, uczenie się na własnych błędach, a więc również umiejętności dokumentowania zdobywanych doświadczeń. Drugi poziom dojrzałości to samoświadomość, umiejętność zdefiniowania sposobu w jaki się pracuje. Projekty będące na danym poziomie dojrzałości charakteryzuje się dążeniem do powtórzenia raz osiągniętego sukcesu. Podstawowe procedury są mniej więcej zdefiniowane i opanowane od strony zarządczej. Wiedza historyczna jest podstawową informacją kształtującą plan działania bieżącego projektu.

Proces posiada udokumentowane standardy dokumentacji, szkoleń i utrzymywania stworzonego oprogramowania. Projekt ma również w miarę ustabilizowane środowisko pracy i procedury zarządzania. Spotkania kierownictwa projektu zwoływane są systematycznie, co pozwala na bieżące rozwiązywanie problemów pojawiających się w obszarze harmonogramu, przydziału zasobów (np. ludzi, sprzętu) oraz realizowanego zakresu funkcjonalnego. Osiągnięcie założonej funkcjonalności produktu odbywa się w oparciu o wyznaczone w kluczowych momentach projektu linie bazowe. Poziom ten charakteryzuje zdyscyplinowanie, realizacja zapisów harmonogramu i zakresu prac.

Poziom zdefiniowany

Charakteryzuje go szczególna dbałość o bezkonfliktowe następowanie po sobie zaplanowanych zadań oraz identyfikacja zagrożeń i nieprawidłowości w przebiegu procesu, zanim negatywne skutki tych zjawisk zaczną odciskać swoje piętno na kolejnych zadaniach wykonywanych w ramach projektu.

Na tym poziomie pojawia się spójny zbiór definicji i standardów ukonstytuowany nie tylko na poziomie projektu, ale również na poziomie organizacji realizującej projekt. Wiedza o sposobie prowadzeniu i organizowaniu pracy nad projektem staje się sposobem funkcjonowania firmy. Standardy i procedury modyfikowane są w miarę zmieniających się uwarunkowań technologicznych lub organizacyjnych. Wyodrębniają się role członków zespołów projektowych. Polaryzują wymagania i umiejętności. W zespole wyodrębniają się specjaliści od realizacji poszczególnych zadań, a organizacja dąży do wyposażenia ich w niezbędną wiedzę i umiejętności.

Projekt na tym poziomie rozwoju zaczyna mieć, bądź kształtować swoją świadomość, mającą na celu zdefiniowanie własnego sposobu realizacji produktu. Zmniejsza się znaczenie metodyk zapożyczonych. Organizacja zaczyna na podstawie własnych doświadczeń modyfikować sposób prowadzenia projektów, tak aby maksymalnie odpowiadał specyfice organizacji i tworzonego przez nią produktu. Definicja projektu dobrze poprowadzonego nie zawiera jedynie wymogu odniesienia sukcesu. Na poziomie trzecim dobrze przeprowadzony projekt to projekt dobrze zdefiniowany, poprawnie i systematycznie udokumentowany, posiadający spójny i odpowiadający specyfice organizacji zbiór ukonstytuowanych i używanych standardów i procedur. To projekt posiadający mechanizmy i kryteria weryfikacji jakości produktu, punkty kontrolne, procedury weryfikacyjne zarówno w obszarze jakości produktu, jak i w obszarach zarządzania projektem. To projekt stabilny i powtarzalny.

Poziom zarządzany

Jeżeli proces jest zarządzany to znaczy, że w jakimś zdefiniowanym obszarze wyniki podejmowanych działań przenoszą określone rezultaty, które można zmierzyć za pomocą wcześniej zdefiniowanych metryk. Nie chroni to przed ponoszeniem kosztów popełniania i naprawy pewnej liczby błędów, które zawsze przytrafić się mogą, ale daje podstawę do oceny stabilności procesu.

Tutaj, mimo iż proces jest zarządzalny i mierzalny, można zawsze znaleźć miejsca wyjątkowo niebezpieczne, które powinny zostać poddane bardziej szczegółowej kontroli (zarządzanie ryzykiem). Zadania, których wykonanie nie generuje dużej liczby błędów mogą być kontrolowane z mniejszą częstotliwością, zaś obszary zdefiniowane jako potencjalnie niebezpieczne np. w związku ze zmianą technologii, mogą podlegać ściślejszej kontroli. Nakłady na identyfikację problemów i opracowanie metod zapobiegania ich powstawaniu powinny minimalizować koszty korygowania błędów podczas realizacji kolejnych projektów.

Poziom optymalizujący

Proces optymalizujący to ideał, który firma stara się jeszcze ulepszyć. Proces jest już tak dobrze zorganizowany i zarządzany, że nie pozostaje nic innego, jak tylko dalsze podnoszenie stawianych przed procesem wymagań. Celem stawianym na tym poziomie jest optymalizacja i dalsze ulepszanie procesu, zwiększanie jego efektywności (polepszanie wyników) oraz wydajności (zmniejszanie kosztów).

Organizacja jest już na tyle dojrzała, aby móc określić silne i słabe strony procesu. Informacje te służą dalszym analizom, mającym na celu wybór bardziej efektywnych technologii lub rozwiązań organizacyjnych.Organizację stać finansowo i organizacyjnie na projekty pilotażowe (studium wykonalności) sprawdzające w praktyce nowe pomysły na szybki i efektywny proces produkcji. Dopiero po takiej weryfikacji, nowe rozwiązania mają szansę stać się dla organizacji obowiązujące.

Zobacz też

Bibliografia

  • CMM, Wikipedia en
  • CMM, Wikipedia pl
ostatnia modyfikacja 20 sierpnia 2016 r.