W 1982 roku Departament Obrony Stanów Zjednoczonych utworzył komisję, której głównym zadaniem było badanie problemów pojawiających się podczas rozwoju oprogramowania w organizacjach departamentalnych. W wyniku działań komisji w grudniu 1984 roku powstał Instytut Inżynierów Rozwoju oprogramowanie(Instytut Inżynierii Oprogramowania, SEI) z siedzibą na Uniwersytecie Carnegie Mellon w Pittsburghu.

1987 SEI publikuje: krótki opis Struktury maszyn współrzędnościowych; metody oceny procesów wytwarzania oprogramowania; metody oceny dojrzałości procesów wytwarzania oprogramowania; kwestionariusz pozwalający określić stopień dojrzałości procesów (do przeprowadzania niezależnych audytów wewnętrznych i zewnętrznych).

1991 Wydanie CMM v1.0.

1992 Wydanie CMM v1.1.

1997 Wydanie kolejnej (ulepszonej) wersji CMM.

Metodologia CMM została opracowana i rozwijana w USA w celu wyłonienia najlepszych producentów oprogramowania do realizacji zamówień rządowych. W tym celu należało stworzyć kryteria oceny dojrzałości kluczowych procesów firmy deweloperskiej oraz określić zestaw działań niezbędnych do ich dalszego doskonalenia. W rezultacie metodologia okazała się niezwykle przydatna dla większości firm pragnących jakościowo ulepszyć istniejące procesy projektowania, rozwoju i testowania oprogramowania oraz sprowadzić ich zarządzanie do zrozumiałych i łatwych do wdrożenia algorytmów i technologii opisanych w jednym standardzie.

SMM stał się de facto właśnie takim standardem. Jego zastosowanie umożliwia oparcie rozwoju oprogramowania na zasadach przemysłowych, zwiększenie sterowalności kluczowych procesów i kultury produkcji jako całości oraz zagwarantowanie wysokiej jakości pracy i terminowej realizacji projektów. Podstawą powstania SMM była podstawowa teza, że ​​zasadniczym problemem „kryzysu” procesu tworzenia wysokiej jakości oprogramowania nie jest brak nowych metod i narzędzi programistycznych, ale nieumiejętność organizacji firmy procesy technologiczne i zarządzaj nimi.

Aby ocenić stopień gotowości przedsiębiorstwa do opracowania wysokiej jakości oprogramowania, SMM wprowadza kluczowe pojęcie dojrzałości organizacyjnej (Maturity). Organizację uważa się za niedojrzałą, jeżeli:

  • nie ma planowania długoterminowego i projektowego;
  • nie zidentyfikowano procesu wytwarzania oprogramowania i jego kluczowych elementów, realizacja procesu zależy od aktualnych warunków, konkretnych menedżerów i wykonawców;
  • metody i procedury nie są znormalizowane ani udokumentowane;
  • wynik nie jest z góry przesądzony przez rzeczywiste kryteria wynikające z planowanych wskaźników, wykorzystania standardowych technologii i opracowanych metryk;
  • proces wypracowywania rozwiązania następuje spontanicznie, na granicy sztuki.

W takim przypadku istnieje duże prawdopodobieństwo, że pojawią się nieoczekiwane problemy, przekroczony zostanie budżet lub projekt nie zostanie oddany w terminie. W takiej firmie menedżerowie i programiści z reguły nie zarządzają procesami - są zmuszeni do rozwiązywania bieżących i spontanicznie pojawiających się problemów. Zauważmy, że większość rosyjskich firm jest na tym etapie rozwoju.

Główne cechy dojrzałej organizacji:

  • firma ma jasno określone i udokumentowane procedury zarządzania wymaganiami, planowania działania projektowe, zarządzanie konfiguracją, tworzenie i testowanie oprogramowania, sprawdzone mechanizmy zarządzania projektami;
  • procedury te są stale udoskonalane i udoskonalane;
  • szacunki czasu, złożoności i kosztów pracy opierają się na zgromadzonym doświadczeniu, opracowanych metrykach i wskaźnikach ilościowych, co czyni je dość dokładnymi;
  • zaktualizowano standardy zewnętrzne dla kluczowych procesów i procedur oraz stworzono standardy wewnętrzne;
  • istnieją obowiązkowe zasady przygotowania oprogramowania metodologicznego i dokumentacji użytkownika;
  • technologie zmieniają się nieznacznie w zależności od projektu w oparciu o stabilne i sprawdzone podejścia i techniki;
  • maksymalne wykorzystanie doświadczeń organizacyjnych i produkcyjnych zdobytych w poprzednich projektach, modułach oprogramowania i bibliotekach oprogramowania;
  • Nowe technologie są aktywnie testowane i wdrażane, a ich efektywność oceniana.

CMM definiuje pięć poziomów dojrzałości technologicznej firmy, dzięki którym klienci mogą ocenić potencjalnych kandydatów do zamówienia, a programiści mogą usprawnić procesy tworzenia oprogramowania.

Każdy poziom, z wyjątkiem pierwszego, składa się z kilku kluczowych obszarów procesowych (Key Process

5 etapów ewolucyjnych w zarządzaniu procesami organizacyjnymi. Wyjaśnienie modelu dojrzałości zdolności. CMM

Model Dojrzałości Zdolności CM-CEI to model organizacyjny opisujący 5 etapów (poziomów) ewolucyjnych, na których zarządza się procesami w organizacji.

Model dojrzałości zdolności, pierwotnie stworzony na potrzeby tworzenia oprogramowania, zakłada, że ​​organizacja musi być w stanie adoptować i wspierać swoje aplikacje. Model sugeruje także konkretne kroki i inicjatywy, które pomogą organizacji wznieść się na wyższy poziom.

5 etapów Modelu Dojrzałości Zdolności

Początkowy (procesy są doraźne, chaotyczne lub tak naprawdę jest ich niewiele) Powtarzalny (ustalone są podstawowe procesy i należy ich przestrzegać) Zdefiniowany (wszystkie procesy są zdefiniowane, udokumentowane, ujednolicone i zintegrowane) Zarządzane ( procesy mierzone są poprzez agregację szczegółowych danych o procesach i ich jakości) Optymalizacja (ciągły rozwój procesu za pomocą ilościowych informacja zwrotna i testowanie nowych pomysłów i technologii)

Model rozwoju oprogramowania

CMM opisuje zasady i praktyki leżące u podstaw koncepcji dojrzałości procesu tworzenia oprogramowania. Zostały zaprojektowane, aby pomóc firmom zajmującym się tworzeniem oprogramowania i sprzedażą w udoskonalaniu procesów tworzenia oprogramowania w sposób ewolucyjny. Od procesów ad hoc, chaotycznych, po dojrzałe, zdyscyplinowane procesy oprogramowania. Nacisk położony jest na identyfikację kluczowych obszarów procesów i przykładowych praktyk, które mogą stanowić zdyscyplinowane procesy tworzenia oprogramowania. Koncepcja dojrzałości CMM tworzy kontekst, w którym:

    Praktyki można powtarzać. Jeśli nie powtarzasz operacji, nie powinieneś jej ulepszać. Istnieją zasady, procedury i praktyki, które zmuszają organizację do wdrożenia i konsekwentnego wykonywania. Najlepsze praktyki organizacyjne praca produkcyjna można szybko udostępniać pomiędzy grupami. Praktyki są zdefiniowane tak, aby umożliwić wymianę między projektami, zapewniając w ten sposób pewną standaryzację dla organizacji. Odchylenia w realizacji tych metod są zminimalizowane. Dla zadań wyznaczane są cele ilościowe; oraz pomiary są ustanawiane, przeprowadzane i utrzymywane w celu stworzenia podstawy oceny. Praktyki są stale ulepszane w celu poprawy możliwości (optymalizacja).

Model dojrzałości zdolności jest przydatny nie tylko do tworzenia oprogramowania, ale także do ogólnego opisu poziomów ewolucyjnych organizacji i opisu poziomu zarządzania, jaki organizacja wdrożyła lub chce osiągnąć.

Struktura Modelu Rozwoju Zdolności
    Poziomy dojrzałości to koncepcja wielowarstwowa, która zapewnia spójność dyscypliny niezbędną do osiągnięcia ciągłego doskonalenia. Należy tutaj zauważyć, że organizacja rozwija umiejętność oceny konsekwencji nowej praktyki, technologii lub narzędzia. Dlatego nie jest to kwestia przyjęcia tych innowacji, ale raczej tego, w jaki sposób te innowacyjne wysiłki wpływają na istniejące praktyki. Wspiera projekty, grupy i organizacje, dając im podstawę do świadomych wyborów. Obszary Procesu Kluczowego – Obszar Procesu Kluczowego (KPA) definiuje grupę powiązanych ze sobą działań, które wykonywane łącznie pozwalają osiągnąć szereg ważnych celów. Cele – cele kluczowego obszaru procesu opisują postanowienia, które muszą istnieć dla tego kluczowego obszaru procesu. Przepisy muszą być wdrażane w sposób skuteczny i niezawodny. Stopień, w jakim cele zostały osiągnięte, wskazuje, jaki rodzaj zdolności organizacja osiągnęła na danym poziomie doskonałości. Cele określają zakres, granice i cel każdego kluczowego obszaru procesu. Wspólne cechy – wspólne cechy obejmują praktyki wdrażające i instytucjonalizujące kluczowe obszary procesów. Te 5 typów ogólna charakterystyka obejmują: zaangażowanie w wykonanie, zdolność do wykonania, zrealizowane inicjatywy, pomiary i analizy oraz monitorowanie wdrożenia. Podstawowe praktyki – podstawowe praktyki opisują elementy infrastruktury i praktyki, które najskuteczniej przyczyniają się do wdrożenia i instytucjonalizacji kluczowych obszarów procesów.
Kryteria definiowania procesu

Kryteria definicji procesu to zbiór elementów procesu, które muszą zostać zawarte w opisie procesu tworzenia oprogramowania, aby ludzie mogli je zastosować w praktyce. Aby ustalić kryteria, należy zadać pytanie - „Jakie informacje o procesie tworzenia oprogramowania są potrzebne do dokumentacji?”

Jakość oprogramowania jest prawdopodobnie jednym z najpoważniejszych problemów w branży oprogramowania. Jakość to znacznie więcej niż tylko brak błędów. Zakłada zestaw różnych cech: niezawodność, odporność na ataki hakerskie, zdolność adaptacji, kompatybilność, łatwość konserwacji, przenośność, wydajność itp. Nic dziwnego, że w branży oprogramowania istnieje tak duża różnorodność standardów jakości.

Jakość można było łatwo zmierzyć: albo otrzymaliśmy zapłatę, albo nie.
Dziekan Leffingwell i Don Widrig.
Zarządzanie wymaganiami oprogramowania

CMM/CMMI

Za chyba najbardziej znany standard jakości należy uznać Capability Maturity Model (CMM) – model oceny poziomu dojrzałości procesów rozwojowych wraz z jego pochodnymi. Został stworzony przez SEI (Instytut Inżynierii Oprogramowania), który jest finansowany przez Departament Obrony USA i jest jednostką strukturalną Uniwersytetu Carnegie Mellon. Pierwsza oficjalna wersja standardu została opublikowana w 1993 roku, choć prace nad nią rozpoczęły się znacznie wcześniej – jego główne postanowienia opublikowano już w 1986 roku.

O sukcesie CMM zadecydowało kilka czynników. Standard ten jako jeden z pierwszych uwzględniał początkowo specyfikę tworzenia oprogramowania. Okazało się to dość proste i przejrzyste zarówno do zrozumienia, jak i użycia, oraz regulowało „co”, a nie „jak” zrobić, a zatem było odpowiednie dla różnych metodologii programowania i nie nakładało żadnych ograniczeń na standardy dokumentacji, narzędzia, środowisko i języków używanych w projektach. I być może głównym czynnikiem, który przesądził o popularności CMM, była współpraca SEI z Departamentem Obrony USA, co de facto oznaczało stosowanie standardu przy realizacji projektów zlecanych przez ten departament.

Model CMM (Tabela 1) zapewnia pięć poziomów dojrzałości, z których każdy odpowiada określonym kluczowym obszarom procesów (Key Process Areas, KPA).

Tabela 1. Poziomy modelu CMM
Poziom nr Nazwa poziomu Kluczowe obszary procesów
1 Podstawowy Jeśli organizacja jest na tym poziomie, to nie ma dla niej kluczowych obszarów procesowych
2 Powtarzalne Zarządzanie konfiguracją oprogramowania Zapewnienie jakości produktów oprogramowania Zarządzanie umowami z wykonawcami Monitorowanie postępu projektów Planowanie projektów oprogramowania Zarządzanie wymaganiami
3 Określony Oceny eksperckie Koordynacja interakcji pomiędzy zespołami projektowymi Inżynieria produktu oprogramowania Zintegrowane zarządzanie oprogramowaniem Program szkoleń personelu Definicja procesu organizacyjnego Zakres procesu organizacyjnego
4 Zarządzany Zarządzanie jakością oprogramowania Zarządzanie procesami w oparciu o metody ilościowe
5 Optymalizacja Zarządzanie zmianami w procesach Zarządzanie zmianami w procesach Zapobieganie defektom

Podział na poziomy i zdefiniowanie KPA dla każdego pozwala na spójne wdrożenie CMM, traktując normę jako wskazówkę, która może zapewnić ciągłe doskonalenie procesu rozwoju.

Standard CMM okazał się bardzo udany i później powstał na jego bazie cała seria standardy (tabela 2). Ponadto otrzymał nową nazwę – SW-CMM (Capability Maturity Model for Software), dokładniej odzwierciedlającą jego pozycję w dość dużej rodzinie standardów.

Tabela 2. Rozwój standardów CMM
Standardowa nazwa Opis
Inżynieria systemowa CMM (SE-CMM) Koncentruje się na zagadnieniach inżynierii systemów – rozwój produktów (analiza wymagań, projektowanie i integracja systemów produktów) oraz ich produkcja (planowanie i eksploatacja linii produkcyjnej)
Zaufana maszyna współrzędnościowa (T-CMM) Zaprojektowany do obsługi wrażliwych i zastrzeżonych systemów oprogramowania, które wymagają zapewnienia wysokiej jakości oprogramowania
Inżynieria bezpieczeństwa systemu CMM (SSE-CMM) Koncentruje się na aspektach bezpieczeństwa inżynierii oprogramowania, zapewnia bezpieczny proces rozwoju, w tym bezpieczeństwo członków zespołu
Ludzie CMM (P-CMM) Rozważa zagadnienia rozwoju personelu w organizacjach tworzących oprogramowanie
Pozyskiwanie oprogramowania CMM (SA-CMM) Obejmuje zagadnienia związane z zakupem oprogramowania od organizacji zewnętrznych
Zintegrowany rozwój produktu CMM (IPD-CMM) Służy jako medium integrujące wysiłki rozwojowe na wszystkich etapach koło życia oraz z każdego działu firmy

Praktyczne zastosowanie standardów serii CMM pokazało jednak, że nie zapewniają one bezwarunkowego sukcesu w tworzeniu oprogramowania. Normy te nie były ze sobą dobrze skoordynowane – jednoczesne wdrażanie różnych modyfikacji CMM mogło być zadaniem dość złożonym i wprawiającym w zakłopotanie specjalistów organizacji, które się z tym spotkały.

Istotnym problemem CMM jest także konieczność „ujednolicenia” wszystkich procesów. Jeśli organizacja stara się uzyskać certyfikację na określonym poziomie, musi zadbać o to, aby wszystkie jej procesy były na odpowiednim poziomie. Nawet jeśli specyfika, metodyka czy cechy rozwojowe nie pozwalają na realizację określonych procesów, certyfikacja tego wymaga.

Inny problem wynika ze stanowiska, jakie zajęły normy CMM nowoczesny przemysł PRZEZ. Ponieważ organizacja certyfikowana na wysokim poziomie zgodnie z CMM powinna zapewniać wyższą wydajność produktów oprogramowania w porównaniu do certyfikowanych na niższych poziomach, standard stał się stosowany jako kryterium selekcji do udziału w przetargach na rozwój oprogramowania lub projektach outsourcingowych. Zapotrzebowanie na certyfikowane organizacje zrodziło propozycję „szybkiej i bezbolesnej certyfikacji”.

Taka sytuacja była możliwa dzięki niedociągnięciom w procesie certyfikacji. Certyfikacji nie podlega cała organizacja jako całość, a jedynie konkretny projekt. Nic nie stoi na przeszkodzie, aby organizacja stworzyła „wzorcowy” projekt spełniający wszystkie wymagania wysokich poziomów normy CMM, uzyskała odpowiedni poziom certyfikacji i zadeklarowała, że ​​wszystkie produkty spełniają ten poziom normy.

CMM został zaprojektowany, aby rozwiązać większość problemów nowy standard SEI – Capability Maturity Model Integrated (CMMI) – Zintegrowany model oceny poziomu dojrzałości procesów rozwojowych. Standard CMMI został pierwotnie stworzony w taki sposób, aby połączyć istniejące opcje CMM i wyeliminować wszelkie sprzeczności w jego wdrażaniu. praktyczne zastosowanie V różne pola działalność firm high-tech.

Aby wyeliminować konieczność „dopasowywania” procesów organizacji i być bardziej dostosowanym do jej potrzeb biznesowych, a nie odwrotnie, standard CMMI posiada dwie formy prezentacji – klasyczną, wielopoziomową, odpowiadającą CMM oraz nową , ciągły. Ciągła forma prezentacji nie uwzględnia poziomów dojrzałości, ale raczej poziomów zdolności, które są oceniane dla poszczególnych obszarów procesu (PA). W tabeli 3 pokazuje zgodność pomiędzy poziomami dojrzałości standardu CMM, a także poziomami dojrzałości wielopoziomowego widoku CMMI i poziomów możliwości ciągłego widoku CMMI.

SEI odchodzi od CMM, a zamiast tego aktywnie promuje CMMI, obiecując zacieśnienie kontroli nad procesem certyfikacji, wprowadzenie nowych klas w celu obniżenia kosztów i uatrakcyjnienia go dla mniejszych organizacji; zapewnienie zgodności z normami ISO. Fakt pozostaje jednak faktem: w nowoczesnych warunkach obecność certyfikatu określonego poziomu CMM/CMMI nie jest już tak istotnym czynnikiem jak jeszcze kilka lat temu i jest akceptowana bez dodatkowych pytań, z wyjątkiem projektów realizowanych na zamówienia rządowe .

Pierwotnym celem opracowania standardu było stworzenie metodologii, która umożliwiłaby dokonanie wyboru dużym organizacjom rządowym USA najlepsi dostawcy PRZEZ. W tym celu zaplanowano stworzenie kompleksowego opisu sposobów oceny procesów wytwarzania oprogramowania i metod ich dalszego doskonalenia. Dzięki temu autorom udało się osiągnąć taki poziom szczegółowości i szczegółowości, że standard był odpowiedni także dla zwykłych firm deweloperskich pragnących ulepszyć istniejące procesy.

Główną koncepcją standardu jest dojrzałość organizacyjna. Organizację, w której proces tworzenia oprogramowania zależy wyłącznie od konkretnych wykonawców i menedżerów, a decyzje często po prostu improwizuje się na bieżąco, uważa się za niedojrzałą. W takim przypadku istnieje duże prawdopodobieństwo przekroczenia budżetu lub niedotrzymania terminu realizacji projektu, dlatego menedżerowie zmuszeni są zajmować się wyłącznie rozwiązywaniem doraźnych problemów.

Z drugiej strony dojrzała organizacja ma dobrze zdefiniowane procedury tworzenia oprogramowania i zarządzania projektami. Procedury te są w razie potrzeby udoskonalane i ulepszane poprzez projekty pilotażowe lub analizę kosztów i korzyści. Szacunki dotyczące czasu i kosztów wykonania prac opierają się na zgromadzonym doświadczeniu i są dość dokładne. Wreszcie firma posiada standardy procesów tworzenia, testowania i wdrażania oprogramowania, zasady projektowania finalnego kodu programu, komponentów, interfejsów itp. Wszystko to składa się na infrastrukturę I Kultura korporacyjna, wspierając proces tworzenia oprogramowania.

Są to podstawowe założenia normy CMM. Można powiedzieć, że standard jako całość składa się z kryteriów oceny dojrzałości organizacji i recept na doskonalenie istniejących procesów. Jest to zasadnicza różnica w stosunku do modelu przyjętego przez ISO 9001, gdyż ISO 9001 formułuje jedynie warunki niezbędne do osiągnięcia pewnego minimalnego poziomu organizacji procesów i nie podaje żadnych zaleceń dotyczących dalszego istnienia procesów.

Model CMM definiuje pięć poziomów dojrzałości organizacyjnej. W wyniku certyfikacji firmie zostaje przydzielony określony poziom, który można następnie podnieść lub (teoretycznie) obniżyć. Na ryc. 1 wymienia niektóre technologie, których wdrożenie jest konieczne do osiągnięcia różne poziomy dojrzałość organizacji. Należy pamiętać, że każdy kolejny poziom zawiera wszystkie kluczowe cechy poprzednich.

Ryż. 1. Pięć poziomów dojrzałości w modelu CMM

Poziom początkowy opisany jest w standardzie jako podstawa do porównań z kolejnymi poziomami. W przedsiębiorstwie podstawowym nie ma stabilnych warunków do tworzenia oprogramowania wysokiej jakości. Wynik każdego projektu zależy całkowicie od cech osobistych menedżera i doświadczenia programistów, a sukces jednego projektu można powtórzyć tylko wtedy, gdy do kolejnego projektu zostaną powołani ci sami menedżerowie i programiści. Co więcej, jeśli tacy menedżerowie lub programiści opuszczą przedsiębiorstwo, wówczas wraz z ich odejściem jakość produkowanego oprogramowania gwałtownie spada. W stresujących sytuacjach proces rozwoju sprowadza się do pisania kodu i minimalnych testów.

Aby osiągnąć powtarzalny poziom, w przedsiębiorstwie muszą zostać wdrożone technologie zarządzania projektami. Jednocześnie planowanie projekty opierają się na zdobytych doświadczeniach, istnieją standardy dla tworzonego oprogramowania (i zapewniona jest zgodność z tymi standardami) oraz istnieje specjalny zespół ds. zapewnienia jakości. W razie potrzeby organizacja może współpracować z podwykonawcami. W warunkach krytycznych proces ma tendencję do cofania się do poziomu początkowego.

Następnie następuje poziom zdefiniowany, który charakteryzuje się tym, że udokumentowany jest standardowy proces tworzenia i utrzymywania oprogramowania (obejmujący zarówno tworzenie oprogramowania, jak i zarządzanie projektami). Rozumie się, że w procesie standaryzacji następuje przejście do najbardziej efektywnych praktyk i technologii. W organizacji należy utworzyć specjalną grupę, która będzie odpowiedzialna za tworzenie i utrzymywanie standardu. Wreszcie warunkiem osiągnięcia tego poziomu jest obecność w przedsiębiorstwie programu ciągłego rozwoju zawodowego i szkolenia pracowników. Od tego poziomu organizacja przestaje być uzależniona od cech konkretnych programistów i nie ma tendencji do schodzenia na niższy poziom w stresujących sytuacjach.

Na poziomie zarządzanym (poziom menedżera) organizacja ustala ilościowe wskaźniki jakości - zarówno dla oprogramowania, jak i produktów w ogóle. Zatem lepsze zarządzanie projektami osiąga się poprzez zmniejszenie wariancji różnych wskaźników projektu. W ten sposób można odróżnić znaczące różnice w wydajności procesu od przypadkowych zmian (szum), szczególnie w obszarach dobrze rozwiniętych.

Wreszcie poziom optymalizacji charakteryzuje się tym, że działania usprawniające stosowane są nie tylko do istniejących procesów, ale także do oceny efektywności wprowadzenia nowych technologii. Głównym zadaniem całej organizacji na tym poziomie jest ciągłe doskonalenie istniejących procesów. Jednocześnie doskonalenie procesów powinno w idealnym przypadku pomóc w zapobieganiu możliwym błędom lub defektom. Ponadto należy dążyć do obniżenia kosztów wytwarzania oprogramowania, na przykład poprzez tworzenie i ponowne wykorzystywanie komponentów.

Po certyfikacji Zgodność wszystkich kluczowych obszarów oceniana jest w 10-punktowej skali. Aby pomyślnie zakwalifikować się w tym kluczowym obszarze, musisz zdobyć co najmniej 6 punktów. Obszar kluczowy oceniany jest w oparciu o następujące wskaźniki:

  • Zainteresowanie kierownictwa tym obszarem (czy planowana jest praktyczna realizacja tego kluczowego obszaru, czy kierownictwo rozumie potrzebę tego obszaru itp.).
  • Jak szeroko ten obszar jest wykorzystywany w organizacji (na przykład wynik 4 punktów odpowiada fragmentarycznej aplikacji).
  • Sukces wykorzystania tego obszaru w praktyce (przykładowo wynik 0 punktów oznacza całkowity brak jakiegokolwiek efektu, a wynik 8 punktów otrzymuje się, jeśli występuje systematyczny i mierzalny pozytywny wynik w niemal całej organizacji).

Zasadniczo certyfikowany może być tylko jeden proces lub jednostka organizacji; na przykład: Dział rozwoju oprogramowania IBM posiada certyfikat poziomu piątego. Swoją drogą, na świecie jest bardzo niewiele firm, które mogą pochwalić się posiadaniem piątego poziomu CMM w przynajmniej jednym ze swoich oddziałów – jest ich zaledwie 50. Z drugiej strony, firm posiadających certyfikaty CMM jest kilka tysięcy. Poziom 3 lub 4, czyli istnieje kolosalna przepaść pomiędzy zoptymalizowanym poziomem dojrzałości a poziomami poprzednimi. Jednak jeszcze większą lukę obserwuje się pomiędzy liczbą organizacji na poziomie podstawowym a liczbą ich bardziej zaawansowanych odpowiedników – według niektórych szacunków ponad 70% wszystkich firm deweloperskich znajduje się na pierwszym poziomie CMM.

Ciekawym pytaniem jest związek poziomów CMM z normą ISO 9001: na jakim poziomie CMM powinna znajdować się organizacja, aby otrzymać certyfikat zgodności z ISO 9001? Na pierwszy rzut oka trzeba do tego mieć co najmniej 3. lub 4. poziom CMM. Istnieją jednak przykłady organizacji poziomu 1, które posiadają certyfikat ISO 9001. Jedną z przyczyn takich absurdów jest wysoki poziom abstrakcji ISO 9001 i związana z tym swoboda interpretacji rewident księgowy. Czasami, co dziwne, audytorom brakuje podstawowej znajomości rzeczywistych praktyk tworzenia oprogramowania. Bardziej szczegółowy raport na temat związku pomiędzy ISO 9001 i CMM znajduje się w artykule.

Niektóre ważne kwestie, takie jak selekcja, rozwój i utrzymanie kompetentnych pracowników, pozostawały poza zakresem CMM. Niemniej jednak pytania te są niezwykle istotne, gdyż jak zauważono w artykule: „…a 20-30 lat temu było wiadomo, że dwóch programistów siedzących przy sąsiednich stołach i otrzymujących tę samą pensję, może pisać programy różniące się szybkością obliczeń, powiedz 10 razy.” Nawiasem mówiąc, sytuacja w Rosji jest jeszcze bardziej skomplikowana w porównaniu z krajami zachodnimi - rosyjscy programiści mogą nie tylko przenieść się do innej pracy, ale także przenieść się do innego kraju z wyższą pensją!

Naturalnie dobór pracowników jest szczególnie ważny dla organizacji pierwszego poziomu, ponieważ pracownicy są dla nich naturalną gwarancją jakości. Ale nawet na wyższych poziomach dojrzałości „czynnik ludzki” zachowuje swoje znaczenie. Dlatego w 1995 roku opublikowano standard People CMM, który jest dodatkiem do Software CMM i ma ogólnie podobną strukturę. Wdrożenie tego standardu równolegle ze zwykłym CMM zapewnia organizacji cały zestaw procedur oceny i rozwoju całego systemu zatrudniania, szkolenia i zatrzymywania wykwalifikowanych pracowników. W ciekawej, choć nieco ekscentrycznej formie, idee People CMM formułuje w artykule jeden z czołowych autorów.

Oprócz People CMM pojawiło się kilka innych modeli, które uzupełniają CMM, na przykład przy pozyskiwaniu oprogramowania lub opracowywaniu dużych systemów. Aby w pełni zintegrować te modele i obniżyć całkowite koszty ich wdrożenia, podjęto projekt CMM Integration (w imię jego wdrożenia w 1998 roku odwołano nawet wydanie CMM w wersji 2.0).

Rozważymy ewolucję modeli zapewnienia jakości w oparciu o „model dojrzałości procesowej” lub „model poprawy zdolności” CMM (Model dojrzałości zdolności). Pomimo tego, że model SMM ma na celu zapewnienie jakości oprogramowania; jego aspekty metodologiczne mają zastosowanie do modeli zapewnienia jakości dowolnego produktu (towaru, robót budowlanych, usług).

Najważniejsze w modelu SMM jest koncepcja dojrzałości organizacyjnej.

Niedojrzały uważana jest za organizację, w której proces tworzenia oprogramowania zależy wyłącznie od konkretnych wykonawców i menedżerów, a decyzje często podejmowane są „w locie”. W takim przypadku istnieje duże prawdopodobieństwo przekroczenia budżetu lub niedotrzymania terminu realizacji projektu, dlatego menedżerowie zmuszeni są zajmować się wyłącznie rozwiązywaniem doraźnych problemów.

Dojrzały Organizację uznaje się za spełnioną, jeśli spełnione są następujące warunki:

  • – istnieją jasno określone procedury tworzenia oprogramowania i zarządzania projektami, które są wyjaśniane i udoskonalane w projektach pilotażowych poprzez analizę elementów „koszt – zysk”;
  • – szacunki czasu i kosztów wykonania pracy opierają się na zgromadzonym doświadczeniu i dlatego są dość dokładne;
  • – firma posiada standardy dotyczące procesów wytwarzania, testowania i wdrażania oprogramowania, zasady projektowania finalnego kodu programu, komponentów, interfejsów itp. Wszystko to składa się na infrastrukturę i kulturę korporacyjną wspierającą proces tworzenia oprogramowania.

Zatem standard SMM to model zapewnienia jakości, który składa się z kryteriów oceny dojrzałości organizacji oraz recept na doskonalenie istniejących procesów. W modelu SMM Zdefiniowano pięć poziomów dojrzałości organizacji, których charakterystykę przedstawiono na rys. 5.3.

Ryż. 5.3. Pięć poziomów dojrzałości modelu SMM

Pierwszy poziom (Początkowy poziom) stanowi podstawę rozwoju przedsiębiorstwa na kolejnych poziomach. Uważa się, że na początkowym poziomie organizacji nie ma stabilnych warunków do tworzenia wysokiej jakości oprogramowania. W związku z tym wynik każdego projektu zależy całkowicie od osobistych cech menedżera i doświadczenia programistów. Oznacza to, że sukces w jednym projekcie można powtórzyć tylko wtedy, gdy do kolejnego projektu przydzieleni zostaną ci sami menedżerowie i programiści. Jeśli z przedsiębiorstwa odejdą menedżerowie lub programiści, którzy zdobyli doświadczenie w projektach, wówczas wraz z ich odejściem jakość produkowanego oprogramowania gwałtownie spada.

Należy uznać, że na początkowym poziomie w sytuacjach stresowych istnieje duża zależność czynnik ludzki Proces rozwoju sprowadza się do pisania kodu i minimalnych testów.

Osiągnięcie drugiego, powtarzalnego poziomu (powtarzalny poziom) jest uwarunkowane wdrożeniem w przedsiębiorstwie technologii zarządzania projektami. Planowanie i zarządzanie projektami w przedsiębiorstwie opiera się na zgromadzonym doświadczeniu, istnieją standardy i są stosowane w opracowywanym oprogramowaniu, których przestrzeganie monitoruje specjalna grupa ds. zapewnienia jakości. Uważa się, że poziom drugi może zarówno dawać możliwości dalszego doskonalenia (przejście na poziom trzeci), jak i nie wyklucza możliwości, w warunkach krytycznych, regresywnego powrotu jakości procesu tworzenia oprogramowania do poziomu wyjściowego.

Trzeci, konkretny poziom (określony poziom) charakteryzuje się tym, że standardowy proces tworzenia i utrzymywania oprogramowania jest w pełni udokumentowany, od opracowania oprogramowania po zarządzanie projektem. Hipotezą realizacji tego poziomu jest założenie, że w procesie standaryzacji przedsiębiorstwo przechodzi do najbardziej efektywnych praktyk i technologii. W organizacji należy utworzyć dedykowaną grupę do tworzenia i utrzymywania standardów rozwoju oprogramowania i zarządzania projektami. Warunkiem osiągnięcia trzeciego poziomu jest obecność w przedsiębiorstwie programu ciągłego rozwoju zawodowego i szkolenia pracowników. Uważa się, że począwszy od tego poziomu organizacja przestaje być uzależniona od cech konkretnych programistów i nie ma tendencji do schodzenia na niższy poziom w sytuacjach stresowych.

Na czwartym, kontrolowanym poziomie (poziom zarządzany) Przedsiębiorstwo ustanawia ilościowe wskaźniki jakości - zarówno dla produktów oprogramowania, jak i dla procesów ich tworzenia jako całości. Zatem lepsze zarządzanie projektami osiąga się poprzez zmniejszenie wariancji różnych wskaźników projektu. W tym przypadku znaczące (sygnałowe) zmiany wdrożonych procesów tworzenia oprogramowania są oddzielane od przypadkowych (szumów) zmian procesu.

Piąty (najwyższy), poziom optymalizacji (poziom optymalizacji) charakteryzuje się tym, że działania usprawniające stosowane są nie tylko do istniejących procesów, ale także do oceny efektywności wprowadzania nowych technologii. Głównym zadaniem przedsiębiorstwa na tym poziomie jest ciągłe doskonalenie istniejących procesów. Jednocześnie doskonalenie procesów powinno pomóc zapobiegać możliwe błędy i wady. Jednocześnie należy prowadzić prace nad obniżeniem kosztów wytwarzania oprogramowania.