Capability Maturity Model - Capability Maturity Model

Capability Maturity Model ( CMM ) jest model rozwoju stworzony w 1986 roku po badaniu dane zebrane od organizacji zakontraktowanych z amerykańskiego Departamentu Obrony , który sfinansował badania. Termin „dojrzałość” odnosi się do stopnia formalności i optymalizacji procesów, od praktyk ad hoc , poprzez formalnie zdefiniowane kroki, do zarządzanych metryk wyników, po aktywną optymalizację procesów.

Model ma na celu usprawnienie istniejących procesów wytwarzania oprogramowania , ale można go również zastosować w innych procesach.

W 2006 roku Instytut Inżynierii Oprogramowania na Carnegie Mellon University opracował Capability Maturity Model Integration , który w dużej mierze zastąpił CMM i rozwiązuje niektóre z jej wad.

Przegląd

Model dojrzałości zdolności został pierwotnie opracowany jako narzędzie do obiektywnej oceny zdolności procesów wykonawców rządowych do wdrożenia zakontraktowanego projektu oprogramowania. Model ten oparty jest na ramach dojrzałości procesowej pierwszy opisany w IEEE Software , a później, w 1989 roku książce zarządzania procesem oprogramowania przez Watts Humphrey . Został on później opublikowany w raporcie w 1993 r. I jako książka tych samych autorów w 1995 r.

Chociaż model pochodzi z dziedziny tworzenia oprogramowania , jest również używany jako model do wspomagania procesów biznesowych, a także był szeroko stosowany na całym świecie w urzędach rządowych, handlu i przemyśle.

Historia

Wcześniejsza potrzeba procesów oprogramowania

W latach osiemdziesiątych korzystanie z komputerów stało się bardziej powszechne, bardziej elastyczne i mniej kosztowne. Organizacje zaczęły przyjmować skomputeryzowane systemy informacyjne, a zapotrzebowanie na rozwój oprogramowania znacznie wzrosło. Wiele procesów tworzenia oprogramowania było w powijakach, z kilkoma zdefiniowanymi standardowymi lub „ najlepszymi praktykami ” podejść.

W efekcie wzrostowi towarzyszyły bóle wzrostowe: niepowodzenia projektów były powszechne, dziedzina informatyki znajdowała się jeszcze w początkowym okresie, a ambicje dotyczące skali i złożoności projektów przekraczały możliwości rynkowe do dostarczenia odpowiednich produktów w ramach zaplanowanego budżetu. Osoby takie jak Edward Yourdon , Larry Constantine , Gerald Weinberg , Tom DeMarco i David Parnas zaczęły publikować artykuły i książki z wynikami badań, próbując sprofesjonalizować procesy tworzenia oprogramowania.

W latach 80. kilka amerykańskich projektów wojskowych z udziałem podwykonawców oprogramowania przekroczyło budżet i zostało ukończonych znacznie później niż planowano, jeśli w ogóle. Starając się ustalić, dlaczego tak się dzieje, Siły Powietrzne Stanów Zjednoczonych sfinansowały badanie w Software Engineering Institute (SEI).

Prekursor

Po raz pierwszy model stopniowej dojrzałości w IT nie został zastosowany przez CMU / SEI, ale raczej przez Richarda L. Nolana , który w 1973 r. Opublikował model etapów wzrostu dla organizacji IT.

Watts Humphrey zaczął rozwijać swoje koncepcje dojrzałości procesowej na późniejszych etapach swojej 27-letniej kariery w IBM.

Rozwój w Instytucie Inżynierii Oprogramowania

Aktywny rozwój tego modelu przez amerykański Departament Obrony Instytutu Inżynierii Oprogramowania (SEI) rozpoczął się w 1986 roku, kiedy Humphrey dołączył do Software Engineering Institute znajdującego się na Carnegie Mellon University w Pittsburghu w Pensylwanii po przejściu na emeryturę z IBM. Na prośbę Sił Powietrznych Stanów Zjednoczonych zaczął formalizować swoje ramy dojrzałości procesu, aby pomóc Departamentowi Obrony USA w ocenie zdolności wykonawców oprogramowania w ramach przyznawania kontraktów.

Rezultatem badania Sił Powietrznych był model do wykorzystania przez wojsko jako obiektywna ocena dojrzałości zdolności procesowych podwykonawców oprogramowania. Humphrey oparł te ramy na wcześniejszej siatce dojrzałości zarządzania jakością opracowanej przez Philipa B. Crosby'ego w jego książce „Jakość jest bezpłatna”. Podejście Humphreya różniło się ze względu na jego unikalny pogląd, że organizacje dojrzewają etapami, opierając się na rozwiązywaniu problemów procesowych w określonej kolejności. Humphrey oparł swoje podejście na etapowej ewolucji systemu praktyk tworzenia oprogramowania w organizacji, zamiast mierzyć dojrzałość każdego oddzielnego procesu rozwoju niezależnie. W ten sposób CMM była używana przez różne organizacje jako ogólne i potężne narzędzie do zrozumienia, a następnie poprawy ogólnej wydajności procesów biznesowych.

Model dojrzałości zdolności (CMM) Wattsa Humphreya został opublikowany w 1988 r., A jako książka w 1989 r. W Managing the Software Process .

Organizacje zostały pierwotnie ocenione za pomocą kwestionariusza dojrzałości procesu i metody oceny możliwości oprogramowania opracowanej przez Humphreya i jego współpracowników z Software Engineering Institute.

Pełne przedstawienie Modelu Dojrzałości Zdolności jako zestawu zdefiniowanych obszarów procesu i praktyk na każdym z pięciu poziomów dojrzałości zostało zapoczątkowane w 1991 r., A wersja 1.1 została ukończona w styczniu 1993 r. CMM została opublikowana jako książka w 1995 r. autorzy, Mark C. Paulk, Charles V. Weber, Bill Curtis i Mary Beth Chrissis. Stany Zjednoczone Ameryki Nowy Jork, USA.

Integracja modelu dojrzałości zdolności

Zastosowanie modelu CMM w tworzeniu oprogramowania czasami sprawiało problemy. Stosowanie wielu modeli, które nie są zintegrowane w ramach organizacji i poza nią, może być kosztowne w przypadku szkoleń, ocen i działań doskonalących. Projekt Capability Maturity Model Integration (CMMI) powstał w celu rozwiązania problemu stosowania wielu modeli w procesach tworzenia oprogramowania, dlatego model CMMI zastąpił model CMM, chociaż model CMM nadal jest ogólnym teoretycznym modelem możliwości procesu używanym w domeny publicznej.

Przystosowany do innych procesów

CMM pierwotnie miał służyć jako narzędzie do oceny zdolności wykonawców rządowych do wykonania zakontraktowanego projektu oprogramowania. Chociaż wywodzi się z obszaru tworzenia oprogramowania, może być, był i nadal jest szeroko stosowany jako ogólny model dojrzałości procesu (np. Procesów zarządzania usługami IT ) w organizacjach IS / IT (i innych).

Modelowe tematy

Modele dojrzałości

Model dojrzałości mogą być postrzegane jako zbiór poziomów strukturyzowanych, które opisują, jak również zachowań, praktyk i procesów organizacji może niezawodnie i trwale wytworzenia wymaganych rezultatów.

Model dojrzałości może służyć jako punkt odniesienia do porównań i jako pomoc w zrozumieniu - na przykład do oceny porównawczej różnych organizacji, w których istnieje coś wspólnego, co można wykorzystać jako podstawę do porównań. Na przykład w przypadku maszyny współrzędnościowej podstawą do porównania byłyby procesy opracowywania oprogramowania w organizacji.

Struktura

Model obejmuje pięć aspektów:

  • Poziomy dojrzałości: pięciopoziomowe kontinuum dojrzałości procesów - gdzie najwyższy (piąty) poziom jest teoretycznie idealnym stanem, w którym procesy byłyby systematycznie zarządzane poprzez kombinację optymalizacji procesów i ciągłego doskonalenia procesów.
  • Kluczowe obszary procesu: kluczowy obszar procesu identyfikuje zespół powiązanych działań, które wykonywane razem pozwalają osiągnąć zestaw celów uznanych za ważne.
  • Cele: cele kluczowego obszaru procesu podsumowują stany, które muszą istnieć, aby ten kluczowy obszar procesu został wdrożony w skuteczny i trwały sposób. Stopień, w jakim cele zostały osiągnięte, jest wskaźnikiem tego, jakie zdolności organizacja posiada na tym poziomie dojrzałości. Cele określają zakres, granice i zamiary każdego kluczowego obszaru procesu.
  • Cechy wspólne : cechy wspólne obejmują praktyki, które wdrażają i instytucjonalizują kluczowy obszar procesu. Istnieje pięć typów wspólnych cech: zobowiązanie do wykonania, zdolność do wykonania, wykonywane czynności, pomiary i analiza oraz weryfikacja wdrożenia.
  • Kluczowe praktyki: Kluczowe praktyki opisują elementy infrastruktury i praktyki, które najskuteczniej przyczyniają się do wdrażania i instytucjonalizacji obszaru.

Poziomy

Istnieje pięć poziomów zdefiniowanych wzdłuż kontinuum modelu i zgodnie z SEI: „Uważa się, że przewidywalność, skuteczność i kontrola procesów oprogramowania w organizacji ulegają poprawie wraz z postępem organizacji w górę tych pięciu poziomów. Dowody empiryczne nie są rygorystyczne, ale do tej pory potwierdza to przekonanie ”.

  1. Inicjalny (chaotyczny, ad hoc, indywidualny heroizm) - punkt wyjścia do zastosowania nowego lub nieudokumentowanego procesu powtarzania.
  2. Powtarzalny - proces jest przynajmniej wystarczająco udokumentowany, aby można było podjąć próbę powtórzenia tych samych kroków.
  3. Zdefiniowany - proces jest definiowany / potwierdzany jako standardowy proces biznesowy
  4. Zdolny - proces jest zarządzany ilościowo zgodnie z ustalonymi miernikami.
  5. Efektywne - zarządzanie procesami obejmuje celową optymalizację / ulepszanie procesów.

W ramach każdego z tych poziomów dojrzałości znajdują się Kluczowe Obszary Procesu, które charakteryzują ten poziom, a dla każdego takiego obszaru istnieje pięć czynników: cele, zaangażowanie, zdolności, pomiar i weryfikacja. Niekoniecznie są one charakterystyczne dla CMM i reprezentują - tak jak one - etapy, przez które organizacje muszą przejść na drodze do dojrzałości.

Model zapewnia teoretyczne kontinuum, wzdłuż którego dojrzałość procesu może być rozwijana stopniowo od jednego poziomu do następnego. Pomijanie poziomów jest niedozwolone / wykonalne.

Poziom 1 - początkowy
Charakterystyczne dla procesów na tym poziomie jest to, że są (zazwyczaj) nieudokumentowane i znajdują się w stanie dynamicznych zmian, z tendencją do kierowania ad hoc , niekontrolowanym i reaktywnym przez użytkowników lub zdarzenia. Zapewnia to chaotyczne lub niestabilne środowisko dla procesów. (Przykład - chirurg wykonujący nową operację kilka razy - poziom negatywnego wyniku nie jest znany).
Poziom 2 - powtarzalne
Charakterystyczne dla tego poziomu dojrzałości jest to, że niektóre procesy są powtarzalne i mogą dawać spójne wyniki. Jest mało prawdopodobne, aby dyscyplina procesowa była rygorystyczna, ale jeśli istnieje, może pomóc w zapewnieniu utrzymania istniejących procesów w okresach stresu.
Poziom 3 - zdefiniowany
Charakterystyczne dla procesów na tym poziomie jest to, że istnieją zestawy zdefiniowanych i udokumentowanych standardowych procesów, które zostały ustanowione i które z czasem podlegają pewnym udoskonaleniom. Te standardowe procesy są stosowane. Procesy mogły nie być stosowane systematycznie lub wielokrotnie - wystarczające, aby użytkownicy stali się kompetentni lub proces został zweryfikowany w szeregu sytuacji. Można to uznać za etap rozwojowy - przy zastosowaniu w szerszym zakresie warunków i rozwoju kompetencji użytkownika proces może rozwinąć się do następnego poziomu dojrzałości.
Poziom 4 - zarządzany (z możliwością)
Charakterystyczne dla procesów na tym poziomie jest to, że stosując metryki procesowe, efektywne osiągnięcie celów procesu można wykazać w szeregu warunków operacyjnych. Sprawdzono przydatność procesu w wielu środowiskach, a proces udoskonalono i zaadaptowano. Użytkownicy procesu doświadczyli procesu w wielu różnych warunkach i są w stanie wykazać swoje kompetencje. Dojrzałość procesu pozwala na dostosowanie się do poszczególnych projektów bez wymiernych strat jakościowych czy odchyleń od specyfikacji. Zdolność procesu jest ustalana na tym poziomie. (Przykład - chirurg wykonujący operację setki razy z ujemnym wynikiem bliskim zeru).
Poziom 5 - Optymalizacja (wydajność)
Cechą charakterystyczną procesów na tym poziomie jest to, że nacisk kładzie się na ciągłe doskonalenie wydajności procesu zarówno poprzez stopniowe, jak i innowacyjne zmiany / ulepszenia technologiczne. Na poziomie dojrzałości 5 procesy zajmują się rozwiązywaniem statystycznych wspólnych przyczyn zmienności procesu i zmianą procesu (na przykład w celu przesunięcia średniej wydajności procesu) w celu poprawy wydajności procesu. Byłoby to robione w tym samym czasie, co utrzymanie prawdopodobieństwa osiągnięcia ustalonych ilościowych celów doskonalenia procesu.

W latach 2008-2019 około 12% wydanych ocen miało 4 i 5 poziom zapadalności.

Krytyka

Model miał pierwotnie służyć do oceny zdolności wykonawców rządowych do wykonania projektu oprogramowania. Był używany i może być do tego dostosowany, ale krytycy wskazywali, że dojrzałość procesu zgodnie z CMM niekoniecznie jest obowiązkowa dla pomyślnego tworzenia oprogramowania.

Ramy procesu tworzenia oprogramowania

Udokumentowane ramy procesu tworzenia oprogramowania mają stanowić wskazówkę dla tych, którzy chcą ocenić spójność organizacji lub projektu z kluczowymi obszarami procesu. Dla każdego poziomu dojrzałości istnieje pięć typów list kontrolnych:

Rodzaj Opis
Polityka Opisuje treść polityki i cele KPA zalecane przez Kluczowe Obszary Procesowe.
Standard Opisuje zalecaną zawartość wybranych produktów pracy opisanych w Kluczowych obszarach procesu.
Proces Opisuje zawartość informacji o procesie zalecaną przez Kluczowe Obszary Procesu. Są one dopracowane w listach kontrolnych dla:
  • Role, kryteria wejściowe, dane wejściowe, czynności, produkty wyjściowe, kryteria zakończenia, przeglądy i audyty, produkty pracy zarządzane i kontrolowane, pomiary, udokumentowane procedury, szkolenia i narzędzia
Procedura Opisuje zalecaną zawartość udokumentowanych procedur opisanych w Kluczowych obszarach procesów.
Przegląd poziomów Zawiera przegląd całego poziomu dojrzałości. Są one dalej uszczegóławiane w listach kontrolnych dla:
  • Cele, cele, zasady i standardy kluczowych obszarów procesów; opisy procesów; procedury; trening; przybory; przeglądy i audyty; produkty pracy; pomiary

Zobacz też

Bibliografia

Zewnętrzne linki