Integracja modelu dojrzałości w tle z możliwościami (CMMI)
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Ostateczny przewodnik dotyczący integracji modelu dojrzałości możliwości (CMMI) na potrzeby programowania jest publikowany przez Instytut Inżynierii Oprogramowania jako "CMMI: Guidelines for Process Integration and Product Improvement". W tej książce opisano w szczególności cmMI for Development (CMMI-DEV) w wersji 1.3, która jest jednym z modeli w pakiecie produktów CMMI. Można również znaleźć "CMMI Distilled: A Practical Introduction to Integrated Process Improvement" (CmMI Distilled: Praktyczne wprowadzenie do zintegrowanego ulepszania procesów), aby być przydatną i dostępną książką dotyczącą cmMI.
Uwaga
Przedstawione tutaj wskazówki są oparte na wersji 1.3 dla usługi CMMI i obsługują proces CMMI dostępny w usłudze Azure DevOps. Obecnie nie istnieją żadne plany aktualizacji tej zawartości w celu obsługi nowszych wersji.
Notatki historyczne
CmMI rozpoczął się w 1987 roku jako model dojrzałości możliwości (CMM), projekt w Software Engineering Institute (SEI). SEI jest ośrodkiem badawczym na Uniwersytecie Carnegie-Mellon, który został ustanowiony i finansowany przez Departament Obrony Stany Zjednoczone. Po raz pierwszy opublikowany w 1991 roku CMM for Software rozpoczął się jako lista kontrolna kluczowych czynników sukcesu. Model opiera się również na badaniach w International Business Machines (IBM) Corporation i 20-wiecznych liderów kontroli jakości, takich jak Philip Crosby i W. Edwards Deming. Zarówno nazwa, model dojrzałości możliwości, jak i reprezentacja etapowa pięć poziomów zostały zainspirowane przez model dojrzałości produkcyjnej Crosby'ego. Stosowane głównie do programów obronnych, CMM osiągnął znaczne wdrożenie i przeszedł kilka poprawek. Jego sukces doprowadził do rozwoju cmms dla różnych tematów poza oprogramowaniem. Rozprzestrzenianie nowych modeli było mylące. W odpowiedzi rząd sfinansował dwuletni projekt w celu utworzenia jednej, rozszerzalnej struktury zintegrowanej inżynierii systemów, inżynierii oprogramowania i tworzenia produktów. Ten wysiłek obejmował ponad 200 ekspertów branżowych i akademickich. Wynik był CMMI.
CMMI-DEV to model. Nie jest to proces, ani recepta, która ma być przestrzegana. Zamiast tego CMMI-DEV udostępnia zestaw zachowań organizacyjnych, które okazały się być używane w programach programistycznych i inżynieryjnych systemów. Dlaczego warto używać takiego modelu? Jaki jest jego cel? I jak najlepiej należy go używać? Te krytyczne pytania są prawdopodobnie najbardziej niezrozumiałymi problemami z cmMI.
Dlaczego warto używać modelu?
Wysiłki na rzecz poprawy wymagają modelu działania organizacji, funkcji, których potrzebują, oraz sposobu interakcji z tymi funkcjami. Model zapewnia zrozumienie elementów organizacyjnych i pomaga w dyskusjach na temat tego, jak i co można i co można ulepszyć.
Model oferuje następujące korzyści:
- Udostępnia wspólną strukturę i język, który ułatwia komunikację
- Wykorzystuje wieloletnie doświadczenie
- Pomaga użytkownikom rozważyć duży obraz podczas skupienia się na ulepszaniu
- Jest często wspierana przez trenerów i konsultantów
- Może pomóc w rozwiązywaniu sporów poprzez zapewnienie uzgodnionych standardów
Jaki jest cel modelu CMMI?
Celem modelu CMMI jest ocena dojrzałości procesów organizacji oraz zapewnienie wskazówek dotyczących ulepszania procesów z celem poprawy produktów. Ponadto cmMI to model zarządzania ryzykiem i umożliwia mierzenie zdolności organizacji do zarządzania ryzykiem. Możliwość zarządzania czynnikami ryzyka w zdolność organizacji do dostarczania produktów wysokiej jakości. Inną perspektywą na zarządzanie ryzykiem jest to, jak dobrze organizacja radzi sobie ze stresem. Wysoka dojrzałość, wysoka zdolność organizacji może łatwo reagować na nieoczekiwane, stresujące zdarzenia. Organizacja o niskiej dojrzałości i niższych możliwościach ma tendencję do paniki pod stresem, ślepo przestrzegać przestarzałych procedur lub całkowicie wyrzucić cały proces i wycofać się z powrotem do chaosu.
CmMI nie jest jednak sprawdzonym wskaźnikiem wyników ekonomicznych organizacji. Mimo że organizacje o wyższej dojrzałości mogą lepiej zarządzać ryzykiem i być bardziej przewidywalne, istnieją dowody na to, że wyższe firmy dojrzałości wydają się być odwrotne. Niechęć do ryzyka może prowadzić do braku innowacji lub dowodów na większą biurokrację, która skutkuje długim czasem prowadzenia i brakiem konkurencyjności. Niższe firmy dojrzałości wydają się być bardziej innowacyjne i kreatywne, ale chaotyczne i nieprzewidywalne. Gdy wyniki są osiągane, często są wynikiem heroicznego wysiłku poszczególnych osób lub menedżerów.
Jaki jest najlepszy sposób korzystania z modelu CMMI?
Model został zaprojektowany tak, aby był używany jako podstawa inicjatywy poprawy procesu, z jego zastosowaniem w ocenie tylko system wsparcia do pomiaru poprawy. Wystąpił mieszany sukces z tym użyciem. Zbyt łatwo jest pomylić model definicji procesu i spróbować go wykonać, zamiast mapy, która identyfikuje luki w istniejących procesach, które mogą być wypełnione. Podstawowy blok konstrukcyjny CMMI to obszar procesu, który definiuje cele i kilka działań, które są często używane do ich spełnienia. Jednym z przykładów obszaru procesu jest Proces i Kontrola jakości produktów. Innym jest zarządzanie konfiguracją. Ważne jest, aby zrozumieć, że obszar procesu nie jest procesem. Pojedynczy proces może przekraczać wiele obszarów procesu, a pojedynczy obszar procesu może obejmować wiele procesów.
CmMI-DEV to naprawdę dwa modele, które współdzielą te same podstawowe elementy. Pierwszą i najbardziej znaną jest reprezentacja etapowa, która przedstawia 22 obszary procesów mapowane na jeden z pięciu poziomów dojrzałości organizacyjnej. Ocena organizacji oceniłaby poziom działania organizacji, a ten poziom byłby wskaźnikiem zdolności do zarządzania ryzykiem i, jak, realizacji obietnic.
Poziomy 4 i 5 są często określane jako wyższe poziomy dojrzałości. Często istnieje wyraźna różnica między organizacjami o wyższej dojrzałości, które pokazują zarządzanie ilościowe i optymalizowanie zachowań oraz niższe organizacje dojrzałości, które są jedynie zarządzane lub wykonywane zgodnie ze zdefiniowanymi procesami. Organizacje o wyższej dojrzałości pokazują niższą zmienność procesów i często używają wiodących wskaźników w ramach metody zarządzania, która jest statystycznie defensowalna. W rezultacie organizacje o wyższej dojrzałości wydają się być zarówno bardziej przewidywalne, jak i szybsze w reagowaniu na nowe informacje, zakładając, że inna biurokracja nie dostaje się w ten sposób. Jeśli organizacje o niskiej dojrzałości mają tendencję do wykazania heroicznego wysiłku, organizacje o wysokiej dojrzałości mogą ślepo podążać za procesami w przypadku stresu i nie rozpoznać, że zmiana procesu może być bardziej odpowiednią odpowiedzią.
Możliwość przetwarzania modeli ciągłej reprezentacji w każdym z 22 obszarów procesów indywidualnie, co pozwala organizacji dostosować swoje wysiłki na rzecz poprawy procesów, które oferują najwyższą wartość biznesową. Ta reprezentacja jest bardziej zgodna z oryginalnym modelem Crosby'ego. Oceny w stosunku do tego modelu powodują, że profile możliwości, a nie pojedyncza liczba. Ponieważ poziom dojrzałości organizacyjnej jest poziomem, który większość menedżerów i kadry kierowniczej rozumie, istnieją sposoby mapowania wyników ciągłej oceny modelu na pięć etapów.
Użycie modelu etapowego jako podstawy dla programu poprawy procesu może być niebezpieczne, gdy implementatory zapominają, że cmMI nie jest procesem ani modelem przepływu pracy. Zamiast tego cmMI ma na celu zapewnienie celów dla procesu i przepływu pracy w celu osiągnięcia. Spełnienie takich celów zwiększa dojrzałość organizacji i prawdopodobieństwo, że wydarzenia rozwijają się zgodnie z planem. Być może największym trybem awarii jest osiągnięcie poziomu celu, a następnie tworzenie procesów i infrastruktury po prostu przejść ocenę. Celem każdego działania poprawy procesu powinno być wymierne ulepszenie, a nie liczba.
Model Ciągły cieszył się sukcesem jako przewodnik po ulepszaniu procesów. Niektóre firmy konsultingowe decydują się tylko na oferowanie wskazówek dotyczących modelu ciągłego. Najbardziej oczywistą różnicą jest to, że program poprawy procesu zaprojektowany wokół modelu ciągłego nie ma sztucznych celów, które są określane przez poziomy dojrzałości. Model ciągły nadaje się również do stosowania poprawy procesów w obszarach, w których najprawdopodobniej skorzysta z korzyści ekonomicznych dla organizacji. W związku z tym ci, którzy korzystają z modelu Ciągłe, są bardziej skłonni otrzymywać pozytywne opinie z inicjatywy opartej na modelu CMMI. Ponadto pozytywne opinie są bardziej prawdopodobne, aby doprowadzić do rozwoju cnotliwego cyklu ulepszeń.
Elementy modelu CMMI
W poniższej tabeli wymieniono 22 obszary procesów składające się na model CMMI (wersja 1.3):
| Akronim | Obszar procesu |
|---|---|
| SAMOCHÓD | Analiza przyczynowa i rozwiązanie |
| Chassis Manager (CM) | Zarządzanie konfiguracją |
| DAR | Analiza decyzji i rozwiązanie |
| IPM | Zintegrowane zarządzanie projektami |
| MA | Pomiar i analiza |
| IDENTYFIKATOR OID | Innowacje organizacyjne i wdrażanie |
| OPD | Definicja procesu organizacyjnego |
| OPF | Fokus procesu organizacyjnego |
| OPP | Wydajność procesu organizacyjnego |
| OT | Szkolenie organizacyjne |
| PI | Integracja produktu |
| PMC | Monitorowanie i kontrola projektu |
| PP | Planowanie projektu |
| PPQA | Kontrola jakości procesów i produktów |
| QPM | Zarządzanie projektami ilościowymi |
| RD | Definicja wymagań |
| REQM | Zarządzanie wymaganiami |
| RSKM | Zarządzanie ryzykiem |
| SAM | Zarządzanie umową dostawcy |
| SFZ | Rozwiązanie techniczne |
| VER | Weryfikacja |
| VAL | Walidacja |
W reprezentacji etapowej obszary procesu są mapowane na każdy etap, jak pokazano na poniższej ilustracji.
W ciągłej reprezentacji obszary procesu są mapowane na grupy funkcjonalne, jak pokazano na poniższej ilustracji.
Każdy obszar procesu składa się z wymaganych, oczekiwanych i informacyjnych składników. Tylko wymagane składniki są rzeczywiście wymagane, aby spełnić ocenę modelu. Wymagane składniki są konkretnymi i ogólnymi celami dla każdego obszaru procesu. Oczekiwane składniki są konkretnymi i ogólnymi rozwiązaniami dla każdego konkretnego lub ogólnego celu. Należy pamiętać, że ponieważ oczekiwany składnik jest jedynie oczekiwany i nie jest wymagany, oznacza to, że konkretna lub ogólna praktyka może zostać zastąpiona równoważną praktyką. Oczekiwane praktyki są dostępne, aby kierować implementacjami i rzeczoznawcami. Jeśli zostanie wybrana alternatywna praktyka, należy do osoby wdrażającej, aby doradzić rzeczoznawcy i uzasadnić, dlaczego alternatywna praktyka jest odpowiednia. Składniki informacyjne zawierają szczegółowe informacje, które pomagają implementatorom rozpocząć pracę z inicjatywą poprawy procesu, która jest prowadzona przez model CMMI. Składniki informacyjne obejmują podpracowania ogólnych i specyficznych praktyk i typowych produktów roboczych.
Wymagane są tylko ogólne i określone cele. Wszystko inne jest udostępniane jako przewodnik. W przypadku przykładów oczekiwanych i informacyjnych składników literatura CMMI pobierała dane z dużych projektów systemów kosmicznych i obronnych. Projekty te mogą nie odzwierciedlać typu projektów, które są podejmowane w organizacji, ani mogą odzwierciedlać najnowszych trendów w branży, takich jak pojawienie się metod tworzenia oprogramowania Agile.
Powiązane artykuły
- Proces CMMI
- Software Engineering Institute wydaje wersję 1.3 pakietu produktów CMMI
- CMMI for Development: Wytyczne dotyczące integracji procesów i poprawy produktu, trzecia wersja
- CMMI for Development: Guidelines for Process Integration and Product Improvement (CMMI for Development: Guidelines for Process Integration and Product Improvement (Seria SEI w inżynierii oprogramowania)
- Co to jest programowanie agile?