Dom » Plany biznesowe » Modele oceny dojrzałości organizacji tworzących systemy oprogramowania. Normy ISO, SW-CMM

Modele oceny dojrzałości organizacji tworzących systemy oprogramowania. Normy ISO, SW-CMM

W listopadzie 1986 roku Amerykański Instytut Inżynierii Oprogramowania (SEI) wraz z Miter Corporation rozpoczęły opracowywanie przeglądu dojrzałości procesów rozwojowych. oprogramowanie co miało pomóc usprawnić ich wewnętrzne procesy.

Opracowanie takiej ankiety zostało zainspirowane prośbą rządu federalnego USA o metodę oceny podwykonawców w zakresie rozwoju oprogramowania. Prawdziwym problemem był brak możliwości zarządzania dużymi projektami. W wielu firmach projekty były realizowane ze znacznymi opóźnieniami i przekraczając zaplanowany budżet. Trzeba było znaleźć rozwiązanie tego problemu.

We wrześniu 1987 roku SEI wydał krótka recenzja procesy rozwoju oprogramowania opisujące ich poziomy dojrzałości oraz kwestionariusz do identyfikacji obszarów w firmie wymagających poprawy. Jednak większość firm uznała ten kwestionariusz za: gotowy model, w wyniku czego po 4 latach ankieta została przekształcona w rzeczywisty model, Capability Maturity Model for Software (CMM). Pierwsza wersja CMM (wersja 1.0), wydana w 1991 roku, została zrewidowana w 1992 roku przez uczestników warsztatów, w których wzięło udział około 200 specjalistów od oprogramowania i członków społeczności programistów.

W rezultacie został wydany standard CMM, wersja 1.1, który jest nadal aktywnie używany na całym świecie.

Ryż. 1. Globalny wpływ korzystania z SMM

Powody tego zainteresowania SMM są jasne. Pomimo tego, że zarówno twórcy oprogramowania, jak i ich kadra kierownicza często bardzo dobrze zdają sobie sprawę z bieżących problemów, nie mogą dojść do porozumienia, jakich zmian firma potrzebuje w pierwszej kolejności. Bez opracowania ujednoliconej strategii wprowadzania ulepszeń kierownictwo nie może znaleźć wzajemnego zrozumienia ze swoimi pracownikami w zakresie zadań o najwyższym priorytecie w zakresie doskonalenia. Aby osiągnąć maksymalny wynik wysiłków włożonych w doskonalenie procesów, konieczne jest posiadanie stopniowej strategii rozwoju, która stopniowo, w sposób ewolucyjny, poprawi dojrzałość procesów rozwojowych.

Ciągłe doskonalenie procesów opiera się na stopniowym kultywowaniu kultury firmy, a nie na rewolucyjnych innowacjach. CMM zapewnia ramy dla tego stopniowego doskonalenia, podzielone na 5 poziomów dojrzałości procesu. Te 5 poziomów reprezentuje skalę oceny poziomu dojrzałości procesów wytwarzania oprogramowania w firmie oraz pomiaru ich parametrów.

Ryż. 2. Zasada konsekwentnego podnoszenia poziomu dojrzałości: możliwości rozwoju organizacji

Oto główne cechy każdego poziomu:

Początkowy - Proces rozwoju jest chaotyczny. Tylko kilka procesów zostało zidentyfikowanych, a powodzenie projektów zależy od poszczególnych wykonawców.
Powtarzalne - Ustalone są główne procesy zarządzania projektami: śledzenie kosztów, harmonogram i funkcjonalność. Usprawniono niektóre procesy wymagane do powielenia wcześniejszych osiągnięć w podobnych projektach (projekty z podobnymi aplikacjami).
Zdefiniowane - Procesy rozwoju oprogramowania i zarządzania projektami są opisane i zaimplementowane w ujednolicony system procesy firmy. Wszystkie projekty wykorzystują standardowy proces organizacyjny wytwarzania i wsparcia oprogramowania, dostosowany do konkretnego projektu.
Zarządzane - Zbieraj szczegółowe dane ilościowe dotyczące wydajności i jakości procesu rozwoju produkt finalny... Analizie podlega znaczenie i dynamika tych danych.
Optymalizacja — Ciągłe doskonalenie procesów opiera się na ilościowych danych procesowych oraz pilotażu nowych pomysłów i technologii.

Wprowadzenie do SW-CMM

(Poprawa dojrzałości procesów wytwarzania oprogramowania w oparciu o Model Dojrzałości Dojrzałości Software Engineering Institute for Software)

Kurs przeznaczony jest dla:
Dla szefów firm programistycznych, szefów działów i projektów rozwoju oprogramowania oraz specjalistów ds. jakości, którzy są zainteresowani:

poprawa przejrzystości istniejących procesów produkcyjnych;

zwiększenie produktywności procesów i firmy jako całości;

zmniejszenie kosztów produkcji i wielkości istniejącej „ukrytej” produkcji;

podniesienie reputacji firmy w środowisku zawodowym;

otwieranie nowych rynków dla produktów.

2.1 Koszt, czas trwania i uzyskane wyniki. Statystyki branżowe
2.2 Zwrot z inwestycji w CMM

3.1 TQM (Total Quality Management), SPI (Software Process Improvement) i Best Business Practices jako podstawa CMM
3.2 Podstawowe koncepcje TQM. Zastosowanie podejść TQM w produkcji oprogramowania
3.3 Korzyści i zagrożenia związane z modelem doskonalenia procesów CMM
3.4 Pojęcie procesu. Główne elementy podejścia procesowego
3.5 Poziomy dojrzałości procesu

9.1 System standardów dla branży IT (Roadmap)
9.2 Relacja ISO z CMM, Rational Unified Process, Zarządzanie projektami
9.3 Stosowanie CMM w małych organizacjach
9.4 Czego brakuje w SMM
9.5 Dokumenty i procesy

10.1 Ostateczny przegląd modelu SW-CMM. Dystrybucja na świecie. Główne trudności
10.2 CMMI (Integracja modelu dojrzałości zdolności) - dalszy rozwój Modele współrzędnościowe

Zestaw slajdów, materiały do ćwiczeń praktycznych, materiały dodatkowe do samodzielnej nauki.

Komplet dokumentów dotyczących SW-CMM (tekst normy, metody oceny, materiały statystyczne dotyczące branży, przykłady dokumentów)

Praktyczny kurs dotyczący technologii wdrażania modelu SW-CMM w firmach IT

Krótka adnotacja:
Kurs ten ma na celu pomóc firmom samodzielnie i kompetentnie zaplanować i przeprowadzić prace nad wdrożeniem modelu poprawy dojrzałości procesów, aby pomóc uniknąć typowe błędy i problemy wdrożeniowe.

Kurs przeznaczony jest dla:
Kurs przeznaczony jest dla kierowników przedsiębiorstw i działów zajmujących się tworzeniem oprogramowania, kierowników projektów, kierowników jakości i innych osób zainteresowanych poprawą jakości swoich projektów oraz certyfikacją swoich procesów zgodnie z CMM.

Przegląd uznanych standardów zarządzania jakością dla IT (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. Do CMM przez ISO?

Jakość oprogramowania jest prawdopodobnie jednym z największych problemów w branży oprogramowania. Jakość to znacznie więcej niż tylko brak błędów. Przyjmuje zestaw różnych cech: niezawodność, odporność na hacki, adaptacyjność, 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ść była łatwa do zmierzenia: albo nam płacono, albo nie.
Dziekan Leffingwell, Don Widrig.
Zarządzanie wymaganiami oprogramowania

WMP / WMP

Za najistotniejszy chyba 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 – jej główne postanowienia opublikowano już w 1986 roku.

Kilka czynników z góry określiło sukces CMM. Ten standard był jednym z pierwszych, który początkowo uwzględniał specyfikę tworzenia oprogramowania. Okazała się dość prosta i przejrzysta zarówno do zrozumienia, jak i do użytku, regulowała „co”, a nie „jak” robić, a więc była odpowiednia dla różnych metodyk rozwoju i nie nakładała żadnych ograniczeń na standardy dokumentacji, narzędzia, środowisko i języki używane 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 wykorzystanie standardu przy realizacji projektów zlecanych przez ten departament.

Model CMM (tabela 1) przewiduje pięć poziomów dojrzałości, z których każdy odpowiada określonym kluczowym obszarom procesów (Kluczowe Obszary Procesów, 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 procesów.
2	Powtarzalne	Zarządzanie konfiguracją oprogramowania Zapewnienie jakości oprogramowania Zarządzanie umowami z wykonawcami Monitorowanie postępu projektu Oprogramowanie Planowanie projektu Zarządzanie wymaganiami
3	Określony	Oceny eksperckie Koordynacja interakcji pomiędzy zespołami projektowymi Inżynieria Produkt oprogramowania Kompleksowe zarządzanie oprogramowaniem Program szkolenia personelu Definicja procesu organizacyjnego Zakres procesu organizacyjnego
4	Zarządzany	Zarządzanie jakością oprogramowania - sterowanie procesem w oparciu o metody ilościowe
5	Optymalizacja	Zarządzanie zmianą procesu Zarządzanie zmianą procesu Zapobieganie defektom

Podział na poziomy i zdefiniowanie KPA dla każdego z nich pozwala na spójną realizację CMM, posługując się standardem jako przewodnikiem, który może zapewnić ciągłe doskonalenie procesu rozwoju.

Standard CMM okazał się bardzo udany, a następnie na jego podstawie powstała cała seria norm (tab. 2). Ponadto otrzymała nową nazwę - SW-CMM (Capability Maturity Model for Software), która dokładniej oddaje jego pozycję w dość licznej rodzinie standardów.

Tabela 2. Rozwój standardów CMM

Nazwa standardu	Opis
Inżynieria systemów CMM (SE-CMM)	Koncentruje się na zagadnieniach inżynierii systemów - rozwoju produktów (analiza wymagań, projektowanie i integracja systemów produktów) oraz ich produkcja (planowanie i eksploatacja linii produkcyjnej)
Zaufana WMP (T-CMM)	Zaprojektowany, aby służyć wrażliwym i zamkniętym systemy oprogramowania które wymagają gwarancji 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 kwestie rozwoju personelu w organizacjach programistycznych
Pozyskiwanie oprogramowania CMM (SA-CMM)	Obejmuje kwestie zakupu oprogramowania od organizacji zewnętrznych
Zintegrowany WMP do opracowywania produktów (IPD-CMM)	Stanowi środowisko do integracji wysiłków rozwojowych na wszystkich etapach cyklu życia i po stronie każdego działu firmy

Jednak praktyczne zastosowanie standardów serii CMM pokazało, że nie zapewniają one bezwarunkowego sukcesu w tworzeniu oprogramowania. Standardy te nie były ze sobą dobrze skoordynowane – jednoczesne wdrażanie różnych modyfikacji CMM mogło być dość trudnym zadaniem i dezorientować specjalistów z organizacji, którzy mieli z tym do czynienia.

Istotnym problemem związanym z maszyną współrzędnościową jest również konieczność „zestrojenia” wszystkich procesów. Jeśli organizacja próbuje certyfikować do pewnego poziomu, musi zapewnić odpowiedni poziom dla wszystkich swoich procesów. Nawet jeśli specyfika, metodologia czy cechy konstrukcyjne nie sprzyjają realizacji pewnych procesów, certyfikacja tego wymaga.

Kolejny problem wynika z pozycji, jaką standardy CMM zajęły w dzisiejszej branży oprogramowania. Ponieważ organizacja z wysokim poziomem zgodnie z CMM musi zapewniać wyższą wydajność produktów oprogramowania w porównaniu do tych, które są certyfikowane na niższych poziomach, standard zaczął być stosowany jako kryterium wyboru do udziału w przetargach na rozwój oprogramowania lub projekty outsourcingowe. Zapotrzebowanie na certyfikowane organizacje zrodziło propozycję „szybkiej i bezbolesnej certyfikacji”.

Taka sytuacja była możliwa dzięki niedociągnięciom procesu certyfikacji. Certyfikacji podlega nie cała organizacja jako całość, a jedynie konkretny projekt. Nic nie stoi na przeszkodzie, aby organizacja stworzyła projekt „wizytowy”, realizowany z uwzględnieniem wszystkich wymagań wysokich poziomów Standard współrzędnościowy, uzyskać odpowiedni poziom certyfikacji i zadeklarować, że wszystkie produkty spełniają ten poziom normy.

Aby rozwiązać większość problemów, CMM ma na celu: 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 łączyć istniejące opcje CMM i wykluczyć wszelkie sprzeczności w jej praktycznym zastosowaniu w różnych obszarach działalności firm high-tech.

Aby wyeliminować konieczność „układania” procesów organizacji i być bardziej dopasowanym do jej potrzeb biznesowych, a nie odwrotnie, standard CMMI posiada dwie formy prezentacji – klasyczną, wielopoziomową, odpowiadającą CMM, oraz nowy, ciągły. Prezentacja ciągła nie uwzględnia Poziomów Dojrzałości, ale Poziomy Zdolności, które są oceniane dla poszczególnych Obszarów Procesu (PA). Tabela 3 pokazuje zgodność między poziomami dojrzałości standardu CMM, a także poziomami dojrzałości prezentacji warstwowej CMMI i poziomów możliwości ciągłej prezentacji CMMI.

SEI odchodzi od CMM iw zamian aktywnie promuje CMMI, obiecując zacieśnienie kontroli nad procesem certyfikacji poprzez wprowadzenie nowych klas w celu obniżenia kosztów i uczynienia go bardziej atrakcyjnym dla małych organizacji; zapewnienie zgodności z normami ISO. Jednak faktem pozostaje: in nowoczesne warunki obecność certyfikatu określonego poziomu CMM/CMMI nie jest tak istotnym czynnikiem jak kilka lat temu i jest akceptowana bez dodatkowych pytań, z wyjątkiem projektów realizowanych na zlecenie rządu.

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

CM-CEI Capability Maturity Model to model organizacyjny opisujący 5 etapów (poziomów) ewolucji, na których zarządzane są procesy w organizacji.

Uzasadnieniem modelu dojrzałości zdolności, pierwotnie zaprojektowanego do tworzenia oprogramowania, jest to, że organizacja musi być w stanie zaakceptować i wspierać swoje aplikacje. Model sugeruje również konkretne kroki i inicjatywy, które pomogą organizacji wznieść się na wyższy poziom.

5 etapów modelu dojrzałości zdolności

Początkowe (procesy są doraźne, chaotyczne lub w rzeczywistości niewiele z nich jest zdefiniowanych) Powtarzalne (podstawowe procesy są ustalone i istnieje dyscyplina przestrzegania tych procesów) Zdefiniowane (wszystkie procesy są zdefiniowane, udokumentowane, ujednolicone i zintegrowane) Zarządzane (procesy są mierzone poprzez agregację szczegółowych danych procesowych i ich jakości) Optymalizacja ( Ciągły rozwój proces wykorzystujący ilościową informację zwrotną i testowanie nowych pomysłów i technologii)

Model rozwoju oprogramowania

CMM opisuje zasady i praktyki, które leżą u podstaw koncepcji dojrzałości procesu tworzenia oprogramowania. Zostały zaprojektowane, aby pomóc firmom zajmującym się opracowywaniem oprogramowania i marketingiem poprawić zaawansowanie ich procesów oprogramowania w sposób ewolucyjny. Od doraźnych, chaotycznych procesów po dojrzałe, zdyscyplinowane procesy oprogramowania. Nacisk kładziony jest na identyfikację kluczowych obszarów procesów i najlepszych praktyk, które mogą stanowić zdyscyplinowane procesy oprogramowania. Koncepcja dojrzałości CMM tworzy kontekst, w którym:

prace produkcyjne

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

Struktura modelu rozwoju funkcjonalności

ogólna charakterystyka

Kryteria definiowania procesu

Kryteria definiowania procesu to zbiór elementów procesu, które muszą być zawarte w opisie procesu oprogramowania, aby ludzie mogli z nich korzystać w praktyce. W celu ustalenia kryteriów należy zadać pytanie - "Jakie informacje o przebiegu programu są potrzebne do dokumentacji?"

Organizacje zajmujące się rozwojem, dostawą, wdrażaniem i utrzymaniem oprogramowania oraz integracją systemów coraz bardziej odczuwają, że jakość i niskie koszty, produkcyjność produkcji są podstawą ich konkurencyjności.

Liderzy takich organizacji nie zawsze potrafią sformułować strategię doskonalenia i rozwoju technologii działania ich firmy; na rynku pracy specjaliści z niezbędnymi kwalifikacjami to zdecydowanie za mało. Jednocześnie, w zakresie doskonalenia procesów technologicznych wytwarzania i eksploatacji oprogramowania, doświadczenie międzynarodowe od wielu lat jest niedostatecznie uogólnione i sformalizowane. Dopiero na początku lat 90. Amerykański Instytut Inżynierii Oprogramowania (SEI) utworzył Model Dojrzałości Zdolności (CMM) organizacji, określający poziomy dojrzałości technologicznej i ich charakterystyczne cechy. Na przestrzeni dekady SMM był testowany w wielu organizacjach, jego skuteczność i niezawodność zostały zweryfikowane przez organizacje zamawiające, dostawców oprogramowania, firmy tworzące oprogramowanie na zamówienie oraz zajmujące się programowaniem offshore.

Dziś na zachodzie firma deweloperska ma praktycznie duże trudności z pozyskiwaniem zleceń, jeśli nie jest certyfikowana przez CMM. Klienci żądają gwarancji wykonalności firmy realizującej, gwarancji, że wykonawca nie może wykonać usługi niskiej jakości.

Ocenę dojrzałości technologicznej firm można wykorzystać:

· przez klienta w wyborze najlepszych wykonawców (np. w przetargu);

· Firmy programistyczne do systematycznej oceny stanu swoich procesów technologicznych i wyboru kierunków ich doskonalenia;

· Firmy, które zdecydują się przejść certyfikację w celu oceny „wielkości katastrofy”, tj. jego obecny stan;

· Audytorzy w celu określenia standardowej procedury certyfikacji i dokonania niezbędnych ocen;

· Firmy konsultingowe restrukturyzujące firmy i usługi dostawców technologii informatycznych oraz usługi pokrewne.

Wraz ze wzrostem dojrzałości technologicznej organizacji procesy tworzenia i utrzymywania oprogramowania stają się coraz bardziej ustandaryzowane i spójne. Jednocześnie sformalizowanie procesów umożliwia ujednolicenie oczekiwanych rezultatów ich realizacji oraz zapewnienie przewidywalności rezultatów realizacji projektów.

Dojrzałość procesu oprogramowania jest stopień ich sterowalności, sterowalności i skuteczności. Rosnąca dojrzałość technologiczna wskazuje na potencjał zwiększonej odporności procesów i wskazuje na stopień, w jakim procesy tworzenia i utrzymania oprogramowania są wykorzystywane efektywnie i konsekwentnie w całej organizacji. Rzeczywiste wykorzystanie procesów jest niemożliwe bez ich udokumentowania i zwrócenia na nie uwagi personelu organizacji, bez stałego monitorowania i doskonalenia ich realizacji. Dobrze zaprojektowane procesy są w pełni zdefiniowane. Rosnąca dojrzałość technologiczna procesów powoduje, że wydajność i jakość wyników ich realizacji może stale wzrastać.

W organizacjach, które osiągnęły dojrzałość technologiczną, procesy tworzenia i utrzymywania oprogramowania mają status standardu, są utrwalane w strukturach organizacyjnych i określają taktykę i strategię produkcji. Ich wprowadzenie do stanu prawnego pociąga za sobą konieczność zbudowania niezbędnej infrastruktury i stworzenia wymaganej Kultura korporacyjna branże, które wspierają odpowiednie praktyki, operacje i procedury biznesowe nawet po opuszczeniu organizacji przez tych, którzy je stworzyli.

Model CMM rozwija zapisy dotyczące systemu jakości organizacji, tworząc kryteria jego doskonałości – pięć poziomów dojrzałości technologicznej, które w zasadzie może osiągnąć rozwijająca się organizacja. Najwyższe – poziom czwarty i piąty – to właściwie cechy organizacji, które opanowały metody kolektywnego rozwoju, w których procesy tworzenia i utrzymania oprogramowania są kompleksowo zautomatyzowane i wspierane technologicznie.

Od 1990 roku SEI, przy wsparciu agencji rządowych USA i organizacji zajmujących się rozwojem oprogramowania, stale rozwija i udoskonala ten model, uwzględniając wszystkie najnowsze osiągnięcia w dziedzinie tworzenia i utrzymania oprogramowania.

SMM to materiał metodyczny, który określa zasady kształtowania systemu zarządzania tworzeniem i utrzymaniem oprogramowania oraz metody stopniowego i ciągłego doskonalenia kultury produkcji. Celem SMM jest zapewnienie organizacjom rozwojowym niezbędne instrukcje w sprawie wyboru strategii poprawy jakości procesów poprzez analizę stopnia ich dojrzałości technologicznej oraz czynników, które w największym stopniu wpływają na jakość produktów. Koncentrując się na niewielkiej liczbie najbardziej krytycznych operacji oraz systematycznie zwiększając efektywność i jakość ich realizacji, organizacja może w ten sposób osiągać stałą poprawę kultury tworzenia i utrzymania oprogramowania.

CMM jest modelem opisowym w tym sensie, że opisuje podstawowe (lub kluczowe) atrybuty, które określają poziom dojrzałości technologicznej organizacji. Jest to model normatywny w tym sensie, że szczegółowy opis metodologii wyznacza poziom organizacji wymagany do realizacji projektów o różnej złożoności i czasie trwania w ramach kontraktów z agencjami rządowymi USA. CMM nie jest receptą, nie określa organizacji, jak się rozwijać. CMM opisuje charakterystykę organizacji dla każdego z poziomów dojrzałości technologicznej, nie podając żadnych instrukcji, jak przechodzić z poziomu na poziom. Przejście z poziomu pierwszego na drugi może zająć organizacji kilka lat, a przejście z poziomu na poziom jest bardzo mało czasu. Proces doskonalenia technologii wytwarzania oprogramowania znajduje odzwierciedlenie w planach strategicznych organizacji, jej strukturze, stosowanych technologiach, ogólnej kulturze społecznej i systemie zarządzania.

Na każdym poziomie ustalane są wymagania, po spełnieniu których następuje stabilizacja najważniejszych wskaźników procesów. Osiągnięcie każdego poziomu dojrzałości technologicznej jest wynikiem pojawienia się w procesach wytwarzania oprogramowania określonej liczby komponentów, co z kolei prowadzi do wzrostu ich produktywności i jakości. Na ryc. 1.7 przedstawia pięć poziomów dojrzałości technologicznej SMM.

Ryż. 1.7. Pięć poziomów dojrzałości technologicznej SMM

Groty strzałek identyfikują cechy usprawniania procesów podczas przechodzenia z poziomu na poziom.

Poziomy od drugiego do piątego można scharakteryzować poprzez operacje mające na celu standaryzację i (lub) unowocześnienie procesów tworzenia oprogramowania oraz poprzez operacje składające się na procesy jego tworzenia. Co więcej, pierwszy poziom jest niejako podstawą, fundamentem dla analiza porównawcza wyższe poziomy.

Na poziomie 1 (początkowym) główne procesy tworzenia i utrzymywania oprogramowania są losowe i chaotyczne. Powodzenie projektu zależy wyłącznie od indywidualnych wysiłków personelu. Na tym poziomie organizacja z reguły nie posiada stabilnego środowiska niezbędnego do tworzenia i utrzymywania oprogramowania.

Powodzenie projektu z reguły zależy wyłącznie od stopnia energii i doświadczenia kierownictwa oraz poziom profesjonalny wykonawców. Może się zdarzyć, że energiczny lider pokona wszystkie przeszkody w procesie projektu i osiągnie wydanie naprawdę opłacalnego oprogramowania. Ale po odejściu takiego lidera ze stanowiska znika gwarancja, że kolejny taki projekt zakończy się sukcesem. W przypadku braku niezbędnego poziomu zarządzania projektami sytuacji nie uratuje nawet zaawansowana technologia.

Procesy pierwszego poziomu charakteryzują się nieprzewidywalnością ze względu na to, że ich skład, cel i kolejność w procesie realizacji projektu zmienia się losowo, w zależności od aktualnej sytuacji. W rezultacie przydzielone środki są przekraczane, a harmonogramy pracy są zakłócane. Przygotowanie zdolne i kompetentni profesjonaliści w organizacjach jest głównym warunkiem sukcesu na wszystkich poziomach dojrzałości, ale na pierwszym poziomie jest to jedyna szansa na osiągnięcie przynajmniej niektórych pozytywnych wyników.

Na poziomie 2 (poziom procesów powtarzalnych) procesy zarządzania projektami zapewniają bieżącą kontrolę kosztów projektu, harmonogramu i funkcji. Dyscyplina projektu jest taka, że można przewidzieć powodzenie projektów tworzenia podobnych produktów oprogramowania.

Na tym poziomie planowanie prac projektowych i zarządzanie nowymi projektami opiera się na doświadczeniu z pomyślnie zakończonych podobnych projektów. Główną cechą drugiego poziomu jest obecność sformalizowanych i udokumentowanych efektywnych procesów zarządzania projektami, co pozwala na wykorzystanie pozytywnych doświadczeń z pomyślnie zakończonych projektów. Efektywne procesy można zdefiniować jako procesy, które są udokumentowane, faktycznie wykorzystywane, policzalne i nadające się do modernizacji. Niezbędne jest przeszkolenie personelu w zakresie ich użytkowania.

Każdy poziom HMM, począwszy od drugiego, charakteryzuje się występowaniem szeregu tzw. kluczowych obszarów procesowych (KRA). Model CMM zawiera 18 takich grup, najnowsza wersja modelu CMMI zawiera 20 grup. Poziom 2 CMM charakteryzuje się obecnością w organizacji następujących procesów (ich nazwy odpowiadają CMMI):

· Zarządzanie wymaganiami;

· Zarządzanie konfiguracją;

· Planowanie;

· Monitorowanie i kontrola projektu;

· Zarządzanie kontraktami;

· Pomiary i analizy;

· Zapewnienie jakości procesu i produktu.

Procesy na drugim poziomie można scharakteryzować jako uporządkowane ze względu na to, że są zaplanowane z wyprzedzeniem, a ich realizacja jest ściśle kontrolowana, dzięki czemu uzyskuje się przewidywalność rezultatów projektu. Wraz ze wzrostem i komplikacją projektów uwaga przesuwa się z technicznych aspektów ich realizacji na aspekty organizacyjne i zarządcze. Realizacja procesów wymaga bardziej wydajnej i skoordynowanej pracy personelu, co z kolei wymaga studiowania udokumentowanych najlepszych praktyk w celu doskonalenia umiejętności zawodowych.

Na poziomie 3 (poziom procesów standaryzowanych) procesy wytwarzania oprogramowania są udokumentowane, ustandaryzowane i stanowią jeden system technologiczny, który jest obowiązkowy dla wszystkich działów organizacji. Wszystkie projekty wykorzystują sprawdzoną, zatwierdzoną i ustandaryzowaną zunifikowaną technologię tworzenia i utrzymywania oprogramowania.

Na tym poziomie do procesów poziomu 2 dodawane są następujące procesy:

· Specyfikacja wymagań;

· Integracja produktu;

· Weryfikacja;

· Certyfikacja;

· Standaryzacja procesów organizacyjnych;

· Edukacja;

· Zintegrowane zarządzanie projektami;

· Zarządzanie ryzykiem;

· Analiza i podejmowanie decyzji.

Głównym kryterium wykorzystania i, jeśli to konieczne, dostosowania procesów na tym poziomie jest pomoc kadrze zarządzającej i specjalistom technicznym w poprawie efektywności realizacji projektów. Na tym poziomie w organizacji tworzona jest specjalna grupa odpowiedzialna za skład operacji składających się na procesy - grupa procesów inżynierii oprogramowania (SEPG).

Na podstawie jednej technologii dla każdego projektu można opracować własne procesy, biorąc pod uwagę jego specyfikę. Takie procesy w CMM nazywane są „procesami tworzenia oprogramowania zorientowanymi na projekt” (zdefiniowany proces tworzenia oprogramowania przez projekt).

Opis każdego procesu zawiera warunki jego realizacji, dane wejściowe, standardy i procedury realizacji, mechanizmy weryfikacji (np. ekspertyzy), wyjście i warunki zakończenia. Opis procesu zawiera również informacje o narzędziach niezbędnych do jego realizacji oraz wskazanie roli odpowiedzialnej za jego realizację.

Głównym celem poziomu 4 (poziom procesów kontrolowanych) jest monitorowanie procesów. Kierownictwo powinno zapewnić, że procesy są przeprowadzane w określonej jakości. Mogą wystąpić nieuniknione straty i chwilowe szczyty mierzalnych wyników, które wymagają interwencji, ale cały system musi być stabilny.

Poziom 4 dodaje następujące procesy:

· Zarządzanie wydajnością i produktywnością;

· Ilościowe zarządzanie projektami.

Na tym poziomie w praktyce stosowana jest szczegółowa ocena jakości zarówno procesów tworzenia, jak i samego tworzonego oprogramowania. W tym przypadku stosuje się ilościowe kryteria oceny.

W całej organizacji opracowywany jest ujednolicony program ilościowej kontroli produktywności i jakości tworzenia oprogramowania. Aby ułatwić analizę procesów, tworzona jest ujednolicona baza danych procesów wytwarzania i utrzymania oprogramowania dla wszystkich projektów realizowanych w organizacji. Opracowywane są uniwersalne metody ilościowej oceny produktywności procesów i jakości ich realizacji. Pozwala to na ilościową analizę i ocenę procesów wytwarzania i utrzymania oprogramowania.

Rezultaty realizacji procesów na poziomie czwartym stają się przewidywalne, ponieważ są mierzalne i wahają się w określonych granicach ilościowych. Na tym poziomie możliwe staje się zaplanowanie z wyprzedzeniem określonej jakości procesów i produktów końcowych.

Głównym celem poziomu 5 (poziom zoptymalizowanych procesów) jest ciągłe doskonalenie i unowocześnianie procesów tworzenia i utrzymania oprogramowania. W celu planowanej modernizacji technologii wytwarzania oprogramowania organizacja tworzy jednostka specjalna, której głównymi zadaniami jest zbieranie danych o realizacji procesów, ich analiza, modernizacja istniejących i tworzenie nowych procesów, sprawdzanie ich na projektach pilotażowych oraz nadawanie im statusu standardów korporacyjnych.

Poziom 5 dodaje następujące procesy:

· Wprowadzenie innowacji technologicznych i organizacyjnych;

· Analiza przyczynowo-skutkowa i rozwiązywanie problemów. Procesy tworzenia i utrzymania oprogramowania charakteryzują się:

konsekwentnie doskonalone, ponieważ organizacja nieustannie stara się je unowocześniać. Udoskonalenie to obejmuje zarówno identyfikację dodatkowych możliwości wykorzystywanych procesów, jak i tworzenie nowych optymalnych procesów oraz wykorzystanie nowych technologii.

Innowacje, które mogą przynieść największe korzyści, są standaryzowane i dostosowywane do systemu technologicznego w całej organizacji. Personel zaangażowany w realizację projektu analizuje defekty i identyfikuje przyczyny ich powstawania. Procesy rozwoju oprogramowania są oceniane, aby zapobiec powtarzaniu się sytuacji prowadzących do defektów, a wyniki oceny są brane pod uwagę w kolejnych projektach.

Każdy kolejny poziom dodatkowo zapewnia pełniejszy wgląd w procesy tworzenia i utrzymania oprogramowania.

Na pierwszym poziomie procesy są amorficzne („czarne skrzynki”), a ich widoczność jest bardzo ograniczona. Od samego początku skład i cel działań praktycznie nie są określone, co stwarza znaczne trudności w określeniu stanu projektu i jego zaawansowania. Wymagania dotyczące realizacji procesów są ustalane w sposób niekontrolowany. Tworzenie oprogramowania czasami wygląda jak czarna magia w oczach menedżerów (zwłaszcza tych, którzy sami nie są programistami).

Na drugim poziomie kontrolowane jest spełnienie wymagań użytkownika i tworzenie oprogramowania, ponieważ określane są podstawy procesów zarządzania projektami. Proces tworzenia oprogramowania można postrzegać jako sekwencję „czarnych skrzynek”, którymi można sterować w punktach przejścia z jednej „skrzynki” do drugiej – ustalone etapy. Nawet jeśli menedżer nie wie, co się dzieje „w pudełku”, jest dokładnie ustalone, jaki powinien być wynik procesu, a także określone są kamienie milowe jego rozpoczęcia i zakończenia. Dzięki temu kierownictwo może rozpoznawać problemy w punktach interakcji „czarnych skrzynek” i reagować na nie w odpowiednim czasie.

Na trzecim poziomie zdefiniowana jest wewnętrzna struktura „czarnych skrzynek”; zadania składające się na procesy. Struktura wewnętrzna to sposób, w jaki standardowe procesy w organizacji są stosowane do konkretnych projektów. Kadra zarządzająca i wykonawcy znają swoje role i obowiązki w ramach projektu z wymaganym stopniem szczegółowości. Kierownictwo jest z wyprzedzeniem przygotowane na ryzyka, które mogą pojawić się w trakcie realizacji projektu. Ponieważ ustandaryzowane i udokumentowane procesy stają się przejrzyste, pracownicy nie zaangażowani bezpośrednio w projekt mogą na czas otrzymywać dokładne informacje o jego aktualnym stanie.

Na czwartym poziomie realizacja procesów jest sztywno powiązana z narzędziami, co umożliwia określenie: cechy ilościowe ich złożoność i jakość realizacji. Menedżerowie, mając obiektywną bazę pomiarów ilościowych, mają możliwość dokładnego zaplanowania etapów i etapów projektu, przewidzenia postępów projektu oraz potrafią terminowo i adekwatnie reagować na pojawiające się problemy. Wraz ze spadkiem ewentualnych odchyleń od ustalonych terminów, kosztów i jakości w trakcie realizacji projektu, ich zdolność do przewidywania wyników stale się zwiększa.

Na piątym poziomie, w celu podniesienia jakości produktów i zwiększenia efektywności ich tworzenia, stale i systematycznie prowadzone są prace nad tworzeniem nowych, udoskonalonych metod i technologii tworzenia oprogramowania. Jednocześnie zwraca się uwagę nie tylko na te już użytkowane, ale także na nowe, wydajniejsze procesy i technologie. Liderzy mogą określić ilościowo wpływ i skuteczność zmian w technologii tworzenia i konserwacji oprogramowania.

Poziomy czwarty i piąty są rzadkością w branży oprogramowania. I tak, podczas gdy kilkaset firm na świecie osiągnęło poziom trzeci, na poziomie piątym (według SEI w 2002 r.) było 62 firm, a na czwartym – 72. Należy zauważyć, że nie wszystkie firmy ogłaszają swój poziom dojrzałości. Niektórzy nie są zainteresowani reklamowaniem swoich technologii organizacyjnych, podczas gdy inni przeprowadzają certyfikację po prostu pod presją klienta.

Osiągnięcie najwyższych poziomów SMM zajmuje dziesięć lub więcej lat. Ale nawet poziom 3 pozwala śmiało wkroczyć na arenę międzynarodową. Aby korzystać z SMM, firma nie musi szukać pracowników o unikalnych zdolnościach, wystarczy, że rozumie ogólną ideę. W opisie modelu CMM szczegółowo określono, co należy zrobić, aby rozwijać się zgodnie z tym modelem. Każdy menedżer klasy średniej jest w stanie śledzić uregulowane działania SMM.

Najnowsza wersja CMM 1.1 skierowana jest głównie do dużych firm zajmujących się realizacją dużych projektów, ale z powodzeniem może być wykorzystywana przez grupy dwu- lub trzyosobowe lub indywidualnych programistów do realizacji małych projektów (do trzech miesięcy). W takich przypadkach model SMM może odgrywać istotną rolę, ponieważ nowe zamówienia są w dużej mierze zdeterminowane jakością poprzednich projektów. Małe grupy będą całkiem zadowolone z poziomu 2, ponieważ w przypadku małego projektu nie jest ważne odejście od terminu o kilka tygodni.

Od 2002 roku oficjalnie dystrybuowana jest specjalna wersja integracyjna CMMI. To nowość od SEI, obejmująca wszystkie aspekty działalności firmy: od opracowania i wyboru wykonawcy po szkolenia, wdrożenie i wsparcie. Ponadto model CMMI jest rozszerzony o podejścia z inżynierii systemów. Model ten zawierał zmiany poczynione podczas projektowania wersji CMM 2.0 (nie została ukończona), główne zmiany miały na celu doprecyzowanie procesów dla firm czwartego i piątego poziomu, co jest najbardziej istotne dla dużych amerykańskich projektowanie.

Model HMM jest dość ważki i ważny, ale nie powinien być wykorzystywany jako jedyna podstawa, która determinuje cały proces tworzenia oprogramowania. Przeznaczony był przede wszystkim dla firm tworzących oprogramowanie dla Departamentu Obrony USA. Systemy te charakteryzują się dużymi rozmiarami i długą żywotnością, a także złożonością interfejsu ze sprzętem i innymi systemami oprogramowania. Nad stworzeniem takich systemów pracują dość duże zespoły programistów, które muszą spełniać wymagania i standardy opracowane przez MON.

Wady SMM obejmują:

1. Model skupia się wyłącznie na zarządzaniu projektami, a nie na procesie tworzenia oprogramowania. Model nie uwzględnia takich ważne czynniki, jako zastosowanie niektórych metod, np. prototypowania, metod formalnych i strukturalnych, narzędzi analizy statycznej itp.

2. W modelu brakuje analizy ryzyk i decyzji, co nie pozwala na wykrycie problemów zanim nie wpłyną one na proces rozwoju.

3. Zakres modelu nie jest zdefiniowany, choć autorzy przyznają, że jest on uniwersalny i odpowiedni dla wszystkich organizacji. Autorzy nie wprowadzają jednak wyraźnego rozróżnienia między organizacjami, które mogą lub nie mogą wdrażać SMM w swoich działaniach. Mniejsze firmy uważają ten model za zbyt biurokratyczny. W odpowiedzi na tę krytykę opracowano strategie doskonalenia przepływu pracy dla małych organizacji.

Główny cel stworzenie modelu SMM było intencją Departamentu Obrony USA w celu oceny możliwości dostawców oprogramowania. W chwili obecnej nie ma jasnych wymagań dotyczących osiągnięcia określonego poziomu rozwoju organizacji rozwojowych. Jednak ogólnie przyjmuje się, że organizacja, która osiągnęła wysoki poziom, ma większe szanse na wygranie przetargu na dostawę oprogramowania. Jako alternatywę dla HMM proponuje się uogólnioną klasyfikację procesów poprawy dojrzałości technologicznej, która jest odpowiednia dla większości organizacji i projektów oprogramowania. Istnieje kilka powszeche typy procesy doskonalenia.

1. Proces nieformalny. Nie ma jasno zdefiniowanego modelu doskonalenia. Z powodzeniem może być wykorzystywany przez osobny zespół programistów.

kow. Nieformalność procesu nie wyklucza takich formalnych działań jak zarządzanie konfiguracją, jednak same działania i ich relacje nie są z góry określone.

2. Proces z przewodnikiem. Posiada przygotowany model, który kieruje procesem doskonalenia. Model definiuje czynności, ich harmonogram oraz relacje między nimi.

3. Metodycznie zdrowy proces. Rozumie się, że istnieją pewne techniki (na przykład systematycznie stosowane są techniki projektowania obiektowego). Dla procesów tego typu przydatne będą narzędzia wspomagające projektowanie i analizę procesów (narzędzia CASE).

4. Proces bezpośredniego doskonalenia. Ma jasno określony cel doskonalenia procesu technologicznego, dla którego istnieje osobna linia w budżecie organizacji oraz określone są normy i procedury wprowadzania innowacji. Częścią tego procesu jest ilościowe określenie procesu doskonalenia.

Tej klasyfikacji nie można nazwać jasną i wyczerpującą - niektóre procesy mogą jednocześnie należeć do kilku typów. Na przykład nieformalność procesu to wybór zespołu programistów. Ten sam zespół może wybrać konkretną metodologię rozwoju, mając jednocześnie wszelkie możliwości bezpośredniego doskonalenia procesu. Taki proces podlega klasyfikacji nieformalne, metodycznie ugruntowane, bezpośrednie doskonalenie.

Potrzeba powyższej klasyfikacji wynika z faktu, że daje ona podstawę do kompleksowego doskonalenia technologii wytwarzania oprogramowania oraz umożliwia organizacji wybór różnych typów procesów doskonalenia. Na ryc. 1.8 pokazuje związek między różne rodzaje systemy oprogramowania i procesy usprawniające ich rozwój.

Ryż. 1.8. Możliwość zastosowania procesów doskonalenia

Znajomość rodzaju opracowywanego produktu spowoduje zgodność między systemami oprogramowania a procesami doskonalenia, pokazaną na ryc. 1.8 przydatne w wyborze procesu doskonalenia. Na przykład musisz stworzyć program do obsługi przenoszenia oprogramowania z jednej platformy komputerowej na drugą. Taki program ma dość krótką żywotność, dlatego jego opracowanie nie wymaga standardów i administracja specjalna proces doskonalenia, jak w tworzeniu systemów długowiecznych.

Wiele procesy technologiczne obecnie posiadamy narzędzia wsparcia CASE, więc można je nazwać obsługiwane procesy. Metodycznie procesy dźwiękowe wspierane przez narzędzia analityczne i projektowe. Skuteczność narzędzia wsparcia zależy od zastosowanego procesu doskonalenia. Na przykład w procesie nieformalnym można użyć typowych narzędzi pomocniczych (narzędzia do prototypowania, kompilatory, narzędzia do debugowania, edytory tekstu itp.). Jest mało prawdopodobne, aby bardziej wyspecjalizowane narzędzia wsparcia były wykorzystywane na bieżąco w procesach nieformalnych.

CMM nie jest wyjątkowy. Prawie każdy duża firma opracowuje własne technologie tworzenia oprogramowania, czasami technologie te stają się powszechnie dostępne i bardzo popularne. Model SMM jest powszechnie znany ze względu na jego wsparcie państwa ale prawdziwa skuteczność SMM została skrytykowana przez wielu czołowych ekspertów. Jedna z głównych wad SMM wiąże się ze zbyt rygorystycznym wymogiem nieodchodzenia od zasad tego modelu, nawet jeśli zdrowy rozsądek podpowiada inaczej. Takie roszczenia do posiadania absolutnej prawdy muszą budzić podejrzenia, dlatego wśród małych i średnich firm bardziej popularne są podejścia, które pozostawiają dużo więcej swobody dla indywidualnej i zbiorowej kreatywności. Rozważana poniżej metodologia SPMN zajmuje miejsce pośrednie między sztywnymi, „ciężkimi” rozwiązaniami, takimi jak SMM, które są skuteczne w dużych organizacjach, a najbardziej elastycznymi technologiami. Przedstawia się najlepsza opcja dla firm, które z jednej strony chcą usprawnić swoje działania zarządcze, a z drugiej strony planują wejść na poziom międzynarodowy gdzie certyfikacja SMM jest wysoce pożądana.

Korzystając ze zdefiniowanego procesu tworzenia oprogramowania, organizacje otrzymują spójny przebieg tego procesu, który mogą dostosować do swoich specyficznych potrzeb. Niekompatybilnymi potrzebami dostosowywania i standaryzacji można zaradzić, konstruując strukturę procesu składającą się ze standardowych modułów lub „podstawowych” kroków oraz reguł używanych do opisywania i ustalania relacji między tymi krokami. W tym przypadku adaptację uzyskuje się poprzez połączenie ich w model procesu.

Zazwyczaj zarządzanie jakością projektów oprogramowania opiera się na wiedzy z trzech źródeł:

Inżynieria oprogramowania (ACM, IEEE);

Zarządzanie projektami (PMI);

Jakość (ASQ).

Instytut Inżynierii Oprogramowania (SEI) na Uniwersytecie Carnegie Mallon łączy te trzy źródła.

Model dojrzałości funkcjonalnej (ZdolnośćDojrzałośćModel, WMP), służy jako „szkielet” procesu tworzenia oprogramowania. Model ten jest oparty na działaniu i odzwierciedla najlepsze wyniki osób pracujących nad doskonaleniem procesu tworzenia oprogramowania i przeprowadzających analizę ewaluacyjną tego procesu. W dalszej części odniesiemy się do tego, jak zarządzanie jakością projektów oprogramowania odpowiada modelowi CMM SEI. Ponieważ HMM jest dobrze znany w środowiskach programistycznych, nie ma potrzeby go definiować. Podamy tylko krótki opis tego, aby wykazać potrzebę wykorzystania cyklu życia w procesie rozwoju. Poniżej znajduje się krótki uogólniony opis poziomów rozwoju możliwości funkcjonalnych modelu HMM.

HMM to schemat, według którego etapy rozwoju odpowiadają pięciu poziomom rozwoju funkcjonalności, na podstawie których realizowane jest ciągłe doskonalenie procesu rozwoju. Mówiąc o poziomie rozwoju funkcjonalności, zwykle mają na myśli ściśle określony etap rozwoju, mający na celu uzyskanie pełnego procesu wytwarzania oprogramowania. Dzieląc HMM na pięć poziomów, skupiono się na działaniach doskonalących wymaganych do ukończenia prac nad rozwojem funkcjonalności procesu. Te pięć poziomów można podsumować, przypisując im następujące cechy.

Oryginał. Proces tworzenia oprogramowania można scharakteryzować jako specjalny, dostosowany do potrzeb proces, a czasem jako chaotyczny. Tylko niewielka liczba procesów może zostać zidentyfikowana, a sukces zależy od indywidualnego wysiłku i zdecydowanych działań.

Powtarzalne. Tworzone są podstawowe procesy zarządzania projektami w celu śledzenia kosztów, harmonogramu i funkcjonalności. Tutaj obserwuje się niezbędną kolejność procesu, mającą na celu powtórzenie osiągnięć uzyskanych wcześniej przy realizacji podobnych projektów.

Określony. Wszystkie projekty wykorzystują przetestowaną, zindywidualizowaną wersję standardowego procesu tworzenia oprogramowania w organizacji.

Zarządzany. Zbierane są szczegółowe wskaźniki procesu tworzenia oprogramowania i charakterystyki jakości produktu. Zarządzanie procesem wytwarzania oprogramowania odbywa się na poziomie ilościowym.

Poziom optymalizacji. Ciągłe doskonalenie procesu rozwoju osiągane jest poprzez ilościową informację zwrotną.

Połączenie to osiąga się poprzez realizację samego procesu, a także w oparciu o innowacyjne pomysły i technologie. Każdy poziom dojrzałości jest podzielony na kilka kluczowych obszarów procesu, które wskazują, co jeszcze należy zrobić, aby usprawnić proces tworzenia oprogramowania. Każdy kluczowy obszar procesu (Kluczprocespowierzchnia,KPA) określa zestaw powiązanych ze sobą działań wymaganych do optymalizacji tego procesu.

Obszary KPA na poziomie 2 dotyczą zagadnień pojawiających się podczas realizacji projektu oprogramowania, które są związane z tworzeniem podstawowych narzędzi do zarządzania projektami. W tym momencie dyskusji musimy wiedzieć, że proces iteracyjny (poziom 2) może zoptymalizować strukturę i zarządzanie w organizacji. Dzięki takiej definicji tworzy się wspólny język i ułatwia się okresy przejściowe, gdy w proces włącza się programistów, zwłaszcza jeśli nie mają wystarczającego doświadczenia w tej dziedzinie.

Jednak obecność powtarzającego się procesu (poziom 2) z pewnością nie prowadzi do dobrze zaprojektowanego procesu. Ogólnie rzecz biorąc, doskonalenie procesów następuje, gdy organizacja osiąga poziom 3. Poziom 3 dotyczy zarówno realizacji projektów, jak i problemów organizacyjnych, ponieważ organizacja tworzy infrastrukturę, która zapewnia efektywną inżynierię oprogramowania i zarządzanie we wszystkich projektach. Dwa obszary CPA, definicja organizacji procesu i zintegrowane zarządzanie programami, są powiązane z obszarem tematycznym. cykle życia.

Cel definicji struktura organizacyjna obszar procesowy KPA na poziomie 3 polega na opracowaniu i utrzymaniu łatwego w obsłudze zestawu przydatnych właściwości procesu wytwarzania oprogramowania, które poprawiają efektywność procesu przy realizacji szeregu projektów. Definicja procesu obejmuje opracowanie i utrzymanie specyficznego dla organizacji procesu rozwoju standardu oraz powiązanych właściwości wartości procesu. Celem określenia struktury organizacyjnej procesu jest opracowanie i utrzymanie standardowego procesu wytwarzania oprogramowania dla danej organizacji.

Działania kształtujące proces budowania struktury organizacyjnej obejmują dokumentowanie i utrzymywanie cech opisowych cykle życia wytwarzania oprogramowania. Celem zintegrowanego zarządzania oprogramowaniem w obszarze CRA na poziomie 3 jest połączenie inżynierii oprogramowania i działań zarządczych w spójnie zdefiniowany proces wytwarzania oprogramowania, wynikający z dostosowania standardowego procesu wytwarzania oprogramowania w danej organizacji i związanego z tym cennego właściwości procesu opisane w „Definiowanie procesu na poziomie jego struktury”.

CMM odnosi się do grupy modeli procesów tworzenia oprogramowania opracowanych na podstawie szerokiej bazy wspieranej przez społeczność programistów. Ponieważ mamy do czynienia z modelem, następuje uproszczenie samego procesu inżynierskiego. Reprezentujący normę model CMM identyfikuje możliwości organizacji, która mieści się w kategorii o takim lub innym stopniu dojrzałości.

Organizacje wykorzystujące ten model jako mechanizm pomiaru i doskonalenia procesów powinny stosować akceptowalną interpretację obszarów wiedzy procesowej pod kątem celów biznesowych. Stosowany jako narzędzie oceny i pomiaru procesu, model ten staje się mapą drogową skutecznego doskonalenia procesów. Ogólnie rzecz biorąc, CMM można postrzegać jako zbiór dobrze sformułowanych koncepcji inżynieryjnych i zarządzania opartych na sprawdzonych zasadach zapewniania. W procesie tworzenia oprogramowania, gdy wiedza wymaga właściwej oceny i ochrony, należy zwrócić szczególną uwagę na zasady zapewniania jakości. Model CMM nie to zbiór recept na każdą okazję. Nie określa, w jaki sposób organizacja powinna ustawić atrybuty procesu. Również jego zastosowanie nie gwarantuje natychmiastowego sukcesu. Proces wdrażania usprawnień wymaga czasu i ciągłego wysiłku w całej organizacji. Jednocześnie szczególne znaczenie ma kadra kierownicza i alokowane środki finansowe. Model CMM trudno zaliczyć do metodologii uniwersalnej, gdy „jeden rozmiar pasuje na każdą okazję”. Pierwszym krokiem do zastosowania tego modelu jest dostosowanie aplikacji poziomu dojrzałości do konkretnej organizacji i zestawu projektów. Firma SEI opracowała inne modele dojrzałości zdolności, które mają zastosowanie do personelu organizacyjnego, nabywania oprogramowania, inżynierii systemów, zintegrowanego rozwoju oprogramowania i oprogramowania osobistego.

Ponieważ oprogramowanie, jak każdy inny kapitał, może być reprezentowane w postaci wiedzy zmaterializowanej, a także ze względu na fakt, że wiedza jest początkowo niesystematyczna, nieokreślona i w zasadzie niekompletna, każdy program można przedstawić jako proces nauki społeczne... Proces ten realizowany jest w formie dialogu, podczas którego niezbędna wiedza materializuje się w postaci gotowego produktu programowego. Jednocześnie prowadzona jest komunikacja między użytkownikami a programistami, realizowana jest interakcja między użytkownikami a wymaganymi narzędziami (technologią). Proces jest iteracyjny, a używane narzędzia tworzą środowisko, w którym odbywa się komunikacja. Każda nowa runda dialogu przyczynia się do pozyskiwania coraz bardziej przydatnej wiedzy od zaangażowanych specjalistów.

Jednym z głównych zastosowań modelu HMM jest określenie, co oznacza proces, który osiągnął pewien stopień dojrzałości. W zastosowaniu do oprogramowania możemy powiedzieć, że dojrzały proces ma następujące atrybuty:

Zdefiniowane — wskazuje „metodę wymaganą do zakończenia sprawy”;

Udokumentowany - zaprojektowany w taki sposób, aby mógł być znany i używany w przyszłości;

Learned - nauka oparta na dokumentacji;

Praktyczny - można go zastosować w praktyce, a nie odkładać na tył palnika;

Utrzymane - dostępne, poprawione i ulepszone;

Kontrolowane – zmiany zostały zatwierdzone przez „uczestników wspólnego biznesu”;

Zweryfikowany — proces przebiega poprawnie;

Zaznaczone - dokładnie taki proces jest wykonywany;

Mierzone - Szacowana wydajność jest wykorzystywana jako podstawa do monitorowania i doskonalenia procesu;

Zdolność doskonalenia - elastyczność i zdolność do zmiany.

Inżynieria produktów software'owych należy do obszaru procesów kluczowych dla poziomu 3, tj. "niektórzy". Do 1968 roku w ogóle nie używano terminu „inżynieria oprogramowania”. Inżynieria oprogramowania to praktyczne zastosowanie wiedzy naukowej do projektowania i tworzenia programów komputerowych. Ten proces jest również nazywany rozwój oprogramowania lub produkcja programów.

Pierwsze rozpowszechnione oprogramowanie pojawiło się w 1890 roku. W tym czasie w American Census Centers pojawiły się karty Punch Card Hermana Cholerita (1860-1929), MIT, Cambridge, MA.

Jednocześnie pierwsze przekroczenia kosztów nastąpiły z winy „komputerów”. Wyniki Centrów Spisu Ludności Stanów Zjednoczonych zostały wstępnie zestawione za pomocą mechanicznych urządzeń pomocniczych; tabulatory mechaniczne Hermana Holleritha. W tym samym czasie zaczęła się rozwijać produkcja kart perforowanych. Środki wydane na zestawienie danych z centrów spisowych były o 98% wyższe niż poniesione w przeszłości. Wynika to częściowo z faktu, że szablon zastosowany do danych tabelarycznych został opracowany bardzo szczegółowo, a ilość danych tabelarycznych przekroczyła minimalną wymaganą ilość. Chociaż sam proces tworzenia tabel został znacznie przyspieszony. W tym samym czasie pojawiły się karty dziurkowane, których odczyt odbywał się elektrycznie.

Wracając do modelu HMM, zauważamy, że na poziomie 2 proces tworzenia oprogramowania można przedstawić jako zbiór „czarnych skrzynek” z określonymi punktami kontrolnymi (etapami). Jak pokazano na ryc. 2.1 wymagania są uwzględniane w procesie i płynnie „przepływają” w zestaw „czarnych skrzynek”.

Ryż. 2.1. Proces poziomu 2

Wyniki obliczeń są generowane dla każdego pudełka, a etapy i punkty kontrolne są stosowane do monitorowania procesu tworzenia oprogramowania. Potem następuje etap wdrażania polityk, standardów i procedur. Doświadczenie to jest określane ilościowo za pomocą podstawowego systemu metrycznego zastosowanego w tym projekcie. Kontrola odbywa się poprzez stosowanie praktyk formalnych związanych z procesem zarządzania projektami. Śledzone są również koszty, wykresy i zestaw właściwości funkcjonalnych. Głównymi przedmiotami procesu są wymagania programowe i produkty pracy, a ich integralność jest monitorowana za pomocą systemu zarządzania konfiguracją. Projekty charakteryzują się bliskimi relacjami z obsługą klienta. Rozwija również umiejętność wdrażania procesów oprogramowania.

Na poziomie 3, czyli „zdefiniowany”, standardowy proces wykorzystywany do tworzenia i utrzymania oprogramowania w organizacji jest udokumentowany i konsekwentnie stosowany, co pokazano schematycznie na ryc. 2.2.

Ryż. 2.2. Proces poziomu 3

W ramach projektów dostosowywane są standardowe procesy informatyczne organizacji, tak aby je skonkretyzować. Procesy zarządzania i inżynierii oprogramowania są również zintegrowane. Możliwości przeprowadzenia standardowego procesu są standardowe, a zespół programistów odpowiada za czynności wykonywane w projekt oprogramowania... Poniżej znajdują się obszary CRA dla trzeciego poziomu dojrzałości:

1) zakres procesu organizacyjnego;

2) określenie procesu organizacyjnego;

3) inżynieria oprogramowania;

4) zintegrowane zarządzanie oprogramowaniem;

5) interakcja między grupami;

6) ekspertyzy;

7) program nauczania.

Na poziomie 3 proces tworzenia oprogramowania opiera się na dobrze zdefiniowanym procesie. W trakcie realizacji procesu wymagana jest świadomość ról i obowiązków. Proces produkcyjny produktu oprogramowania jest wyświetlany podczas wykonywania procesu oprogramowania.

Poziom 4 (rys. 2.3), tj. „kontrolowany” obejmuje dwa obszary CRA: ilościowe zarządzanie procesami oraz zarządzanie jakością oprogramowania.

Ryż. 2.3. Proces poziomu 4

Dzięki zastosowaniu rozszerzonego systemu metryki akumulowane są wyniki szczegółowej oceny procesu wytwarzania oprogramowania i zapewnienia jakości produktu programowego. Przeprowadzana jest ilościowa ocena i kontrola procesów i produktów oprogramowania. Proces zarządzania opiera się na obiektywnych kryteriach sformułowanych w celu podejmowania decyzji i mierzenia wyników w określonych granicach.

Na poziomie 5 („optymalizacja”) obszary CPA koncentrują się na etapach zarządzania zmianą technologii, zarządzania zmianą procesów i zapobiegania defektom. Poprzez ciągłe doskonalenie procesów, ilościowe Sprzężenie zwrotne w związku z procesem tworzenia oprogramowania. Na tym poziomie organizacja może testować nowe pomysły i technologie, które poprawiają jakość produktu programowego, co schematycznie pokazano na ryc. 2.4.

Ryż. 2.4. Proces poziomu 5

Poprzez kontrolowane zmiany w istniejącym procesie wprowadzane jest podejście organizacyjne umożliwiające ciągłe doskonalenie procesu. Organizacja tych zmian jest ważna z następujących powodów:

1) proces powinien być zgodny z tradycjami kulturowymi organizacji;

2) kierownictwo ma obowiązek przyczyniać się do podnoszenia poziomu kultury;

3) kultura powinna promować wprowadzanie wzorów do naśladowania i nagród.

Podsumowując, można zauważyć, że model SMM jest swoistą „mapą drogową”, która gwarantuje pomyślne doskonalenie procesów. Jego interpretacja i zastosowanie mieści się w kontekście celów biznesowych organizacji. Obecnie w organizacjach zajmujących się tworzeniem oprogramowania najpopularniejszą metodą jest model CMM (tendencja ta jest typowa dla wielu krajów i dużej różnorodności obszarów zastosowań). Model ten jest normatywny, nienakazowy, a także charakteryzuje się dużym marginesem stabilności. Jego rozwój i wsparcie jest realizowane przez wielu programistów zrzeszonych w społeczności profesjonalistów.