V. Iljina.

Kierownik Działu Jakości firmy TopSBI

„Jeśli coś zrobisz

źle - niepotrzebne
oczekuj właściwego wyniku ”.

Chińska mądrość ludowa

Kompleksowe rozwiązanie problemów związanych z zapewnieniem jakości narzędzia programowe polega na opracowaniu i wdrożeniu określonego systemu zarządzania jakością (System Zarządzania Jakością - SZJ). W praktyce światowej najbardziej rozpowszechniony jest system oparty na wymaganiach norm międzynarodowych. Seria ISO 9000, ponieważ definiuje precyzyjnie najbardziej ogólne wymagania, w tym dla systemów oprogramowania, a co za tym idzie generalnie określa już wstępną dojrzałość procesów niezbędną do spełnienia wielu modeli branżowych i standardów z dziedziny IT .

Ale na pytanie, czy wprowadzenie systemu jakości i pomyślna certyfikacja gwarantuje wydanie produktu wysokiej jakości, należy szczerze odpowiedzieć - „nie”.

Podkreślając, że ISO 9000 to „świetny pomysł”, Gartner Group zaleca, aby certyfikację ISO 9001 traktować jedynie jako punkt wyjścia na drodze do jakości (1).

Określa rodzaj „szkieletu” systemu jakości, a wypełnienie tego systemu „mięśniami” (profesjonalne treści oparte na już specjalnych, branżowych standardach i metodykach, takich jak CMM) może zapewnić poziom jakości odpowiadający rosnącemu rynkowi wymagania.

W związku z powyższym, zarówno z metodologicznego, jak i praktycznego punktu widzenia, wielu ekspertów w dziedzinie zarządzania jakością uważa za celowe zbudowanie strategii rozwoju firm IT w następujący sposób:

Najpierw opracuj i wdroż SZJ w oparciu o model ISO 9001:2000. (W końcu większość firm, które są obecnie na 4 i 5 poziomie SW-CMM, najpierw przeszła przez dostosowanie swoich procesów do modelu ISO. Jak pokazuje praktyka, to najlepsza opcja w zakresie zarządzania rozwojem SZJ i ograniczania ryzyka).

I dopiero wtedy zaczynamy opracowywać i wdrażać kluczowe procesy modelu SW-CMM i dalej, jeśli to konieczne, modelu CMMI.

Aby zrozumieć, jak to jest naprawdę poprawne, porównajmy te modele.

1. Przegląd kandydatów.

Zrealizujemy krótka recenzja najpopularniejsze standardy, które firma IT może wykorzystać do optymalizacji procesów biznesowych.

ISO 9001. Najpopularniejszy, a zwłaszcza w Europie, jest ISO 9001 (2)

Jednocześnie metodycznie, w pełnej zgodzie z dyscypliną budowlaną złożone systemy, norma ISO 9001 zapewnia z jednej strony konstrukcję system organizacyjny„odgórnie”: od celów przedsiębiorstwa i jego polityki – po strukturę organizacyjną i kształtowanie procesów biznesowych, az drugiej – iteracyjny rozwój systemu organizacyjnego poprzez mechanizmy pomiaru i doskonalenia.

Mówiąc prościej, „jakość” według serii norm ISO 9000 to sytuacja, w której konsumenci otrzymują od producenta produkty spełniające ich bezpośrednie wymagania i ukryte oczekiwania. Dlatego zarządzanie jakością, zgodnie z ISO 9000, polega na wykorzystaniu tzw. „podejście procesowe”, kiedy najbardziej optymalny łańcuch „procesów transformacji” jest modelowany i wdrażany, zapewniając, że potrzeby konsumentów są postrzegane przez producenta i zawarte w każdym produkcie bez zniekształceń.

Ta dobrze znana seria norm ISO 9000 była z powodzeniem stosowana przez wiele organizacji zajmujących się oprogramowaniem. Nowa wersja normy z tej serii zostały wydane w 2000 roku i zawierają już takie pojęcia, jak podejście procesowe, analiza i pomiary, doskonalenie procesów, zapożyczone z modelu CMM i nieobecne wcześniej w poprzednich wersjach ISO 9000. Należy jednak zauważyć, że normy z tej serii są uniwersalne – nie są nastawione na żadną konkretną branżę, nie uwzględniają specyfiki sfery IT i w tym sensie oczywiście pod względem stopnia konkretyzacji są zauważalnie gorsze od SMM. Ponadto ISO 9000 nie implikuje stopniowania (poziomów) zgodności, a tym samym utrudnia określenie „prawdziwych” zdolności organizacji, a co za tym idzie – sposobów ich dalszego rozwoju.

WMP(Capability Maturity Model) został opracowany przez Instytut Inżynierii Oprogramowania na Uniwersytecie Carnegie Mellon (USA) i opisuje model dojrzałości dla procesów rozwojowych oprogramowanie w przedsiębiorstwach (3). W ramach tego modelu dla każdej firmy można porównać pewien poziom (jeden z pięciu możliwych), wskazujący na osiągniętą jakość procesu wytwarzania oprogramowania. Ponieważ standardy te zostały opracowane przede wszystkim w celu usprawnienia procesu wyboru wykonawców dla Departamentu Obrony USA, koncentrują się one na procesach zarządzania projektami oprogramowania, podczas gdy techniczne aspekty rozwoju są mniej uwzględnione.

W SW-CMM v.1.1 (Model Dojrzałości Zdolności dla Oprogramowania) istnieje 316 Kluczowych Praktyk. Kluczowe Praktyki są tym, co powinno zostać wdrożone w przedsiębiorstwie i na co zwróci uwagę zespół oceny procesów. Są one zjednoczone w obszarze – Obszary Kluczowych Praktyk (KPA) – jest to już zbiór powiązanych ze sobą procesów, które wspólnie wykonywane prowadzą do osiągnięcia określonego zestawu celów.

CMMI(Capability Maturity Model Integration) – dalszy rozwój modelu CMM. W CMMI-SE / SW w wersji 1.02 (CMMI for Systems Engineering / Software Engineering), być może najbardziej akceptowalna dla programistów systemy oprogramowania, - liczba kluczowych praktyk osiągnęła już 417.

Wzrost Key Practices jest związany z samym celem rozwoju CMMI - model powinien pomóc uniknąć problemów związanych z używaniem różnych branżowych modeli CMM.

(Od 1991 r. maszyny współrzędnościowe zostały opracowane do różnych zastosowań, z których najważniejsze to:

Model dojrzałości zdolności dla oprogramowania (SW-CMM)
- model dojrzałości procesu dla przebudowy systemu (Electronic Industries Alliance Interim Standard - EIA / IS 731)
- model dojrzałości procesów zintegrowanego rozwoju produktu Model Dojrzałości Zintegrowanego Rozwoju Produktu (IPD-CMM)

Na podstawie tych modeli zbudowano CMMI. Wchłonął to, co najlepsze z tych modeli, eliminując niejednoznaczność w interpretacji niektórych pojęć ze względu na obecność wielu modeli – stąd liczba kluczowych praktyk znacznie wzrosła).

Widać, że okazał się to model znacznie bardziej „ciężki” – zob. Ryż. jeden, który zresztą nie został jeszcze dostatecznie przetestowany w praktyce (ukazał się dopiero w 2002 r.). W związku z tym moim zdaniem przy wdrażaniu modelu możliwe są duże ryzyka związane zarówno z nieuzasadnionymi stratami w szybkości wytwarzania oprogramowania, jak i przy jednoznacznym wzroście kosztów pracy dla obsługi (i wsparcia) wdrożonego KPA - zobaczyć. Rys 1. Mnie, jako praktykowi, który zbudował już SZJ w trzech różnych profilach firm IT, wydaje się, że model CMMI jest wyraźnie nierówny pomiędzy tym, co konieczne i wystarczające – personelem firmy IT (i tymi , z reguły są w większości "artystami kodu") po prostu nie "przyjmą do wykonania" takiej liczby kontrolowanych przepisów (istnieje bardzo duże ryzyko zbudowania "wioski potiomkinowskiej")!

Ryż. 1 Porównanie składu KPA w modelach CMM i CMMI.

Ponadto ocena dla CMMI będzie znacznie droższa, ponieważ autoryzowana SEI Główny Asesor " Będzie ich na razie bardzo mało, a usługi te będą znacznie droższe niż przy ocenie zgodności z modelem CMM.

Co więcej, wielu zagranicznych ekspertów w dziedzinie zarządzania jakością (z którymi w tej chwili w pełni się zgadzam) jest raczej sceptycznie nastawionych do CMMI w kontekście jego przydatności do wdrożenia w małych i średnich organizacjach (są to organizacje, które są po prostu charakterystyczne dla Rosji ). Pojawia się nawet opinia, że ​​po pewnym czasie SEI będzie musiał albo wypuścić zaadaptowany SW-CMM v.2, albo podjąć podobne kroki. Tych. jeśli rynek nie akceptuje modelu, a takie warunki wstępne są już spełnione w momencie pisania tego tekstu, SEI będzie musiało dostosować się do wymagań rynku.

W związku z powyższym właściwe wydaje się przeanalizowanie wspomnianego już bilansu niezbędnych i wystarczających we wszystkich tych podstawowych modelach SZJ.

Narysujmy to w następujących współrzędnych (patrz. Ryż. 2) :

stopień regulacji procesów rozwojowych - wyznaczmy tę koncepcję - RP,

prawdopodobieństwo osiągnięcia zaplanowanych rezultatów - wyznaczmy tę koncepcję - PQ.

Na ryc. 2 przedstawia ekspercką ocenę bilansu stopnia regulacji i prawdopodobieństwa osiągnięcia planowanych rezultatów, przeprowadzoną przez autora na podstawie wyników praktyki wprowadzania wymagań tych modeli do tworzenia i wdrażania systemów oprogramowania ( oprogramowanie).

W kategoriach matematycznych wielkość pochodnej to: F (Q) = dPQ \ dRQ(wzrost efektywności w osiąganiu jakości dPQ wraz ze wzrostem kosztów czasu pracy wspierającego spełnienie wymagań DRQ), zmniejsza się odpowiednio w następującej kolejności : ISO 9000, WMP, WMP.

Dlatego ryc. 2 jasno i prosto wyjaśnia:

popularność modelu ISO 9000,

poprawność metodologii: najpierw ISO, a dopiero potem, jeśli to konieczne, CMM,

pewien sceptycyzm co do skuteczności modelu CMMI.

Ryż. 2 Analiza równowagi pomiędzy stopniem regulacji a prawdopodobieństwem osiągnięcia planowanych rezultatów (według ekspertyzy autora)

Rozważmy teraz jeszcze jeden poradnik, który jest szeroko stosowany w firmach IT i zostanie wymieniony poniżej, analizując zagadnienia praktyki wdrożeniowej SZJ.

Ten PMBoK(Przewodnik po Zarządzanie projektami Ciało wiedzy) jest projekt projektu Instytut Zarządzania, który pochłonął zgromadzoną wiedzę z zakresu zarządzania projektami. Ostatnia wersja dokumentu została opublikowana w 2000 roku i jednocześnie uzyskała status normy Amerykańskiego Instytutu Normalizacyjnego ANSI (choć normy ANSI i IEEE są formalnie uznawane za amerykańskie, to większość z nich ma de facto charakter międzynarodowy). Ważną cechą PMB®K jest to, że uwzględnia zarządzanie projektami w sensie ogólnym, bez odniesienia do konkretnych obszarów tematycznych, takich jak IT, i dlatego nie może być stosowany samodzielnie - poniżej zastanowimy się, jaki efekt daje to w połączeniu z ISO 9000.

Zastanówmy się teraz, jak wymagania popularnej już normy ISO 9001:2000 odnoszą się do ogólnych właściwości coraz popularniejszego modelu CMM {3}- cm. Ryż. 3.

Ryż. 3. Korespondencja między ogólnymi właściwościami CMM a elementami normy ISO 9001:2000

Każdy poziom SMM, jak wspomniano powyżej, charakteryzuje się zestawem obszary kluczowych procesów - KPA (Key Process Areas) - cm. Rys. 3. Osiągnięcie wszystkich celów w ciągu KPA dla pewnego poziomu CMM określa zgodność organizacji z tym poziomem. Jeśli przynajmniej jeden cel jest przynajmniej jednym KPA jeśli poziom CMM nie został osiągnięty, to organizacja nie może osiągnąć tego poziomu CMM. KPA można podzielić na trzy kategorie: dyrektorzy zarządzający , organizacyjny oraz dostarczanie (cm. Ryż. 4).

CMM nie definiuje wszystkich procesów związanych z tworzeniem oprogramowania; podkreśla tylko te, które są niezbędne do osiągnięcia poziomu SMM i są zawarte w KPA... Każdy KPA jest podzielony na 5 wspólnych cech: Komentarz do wykonania; Zdolność do wykonywania; Wykonane czynności; Pomiar i analiza; Weryfikacja wdrożenia

Właściwość ogólna ” Wykonane czynności” opisuje działania, które należy wykonać, aby osiągnąć cele KPA, pozostałe cztery ogólne właściwości opisują czynniki formalne, które czynią proces częścią Kultura organizacyjna... Całkowite spełnienie wszystkich kluczowa praktyka wszystkich wspólnych właściwości zapewnia osiągnięcie celów KPA... Kluczowe praktyki operacyjne opisują, czym powinien się stać przepływ pracy (lub element procesu lub część infrastruktury), ale nie definiują sposobu osiągnięcia ( konkretne technologie lub technik), chociaż podano ogólne wytyczne dla niektórych technik. Do różne warunki ten sam wynik można osiągnąć na różne sposoby. To jest raczej ogólne zasady praca niż konkretne działanie.

Sekwencyjna implementacja wspólnych właściwości faktycznie realizuje cykl doskonalenia procesów biznesowych (Buisness-process Improvement - BPI-cm. Ryż. 5.), tj. ciągłe doskonalenie procesów biznesowych (BP).

Ryż. 5. Cykl ciągłego doskonalenia procesów biznesowych według modelu CMM oraz normy ISO 9000:2000.

Chęć uzyskania certyfikatu zgodności w jak najkrótszym czasie zmusza firmy konsultingowe i specjalistów ds. zarządzania jakością do wykorzystywania elastyczności i ram wymagań wszystkich wymienionych modeli wysokiego poziomu do własnych „najemniczych” celów.
W wyniku tego forsowania zdarzeń, np. organizacja, która uzyskała certyfikat wg ISO 9000:2000, ma tylko minimalny zestaw procesów niezbędnych do zapewnienia zgodności z ISO 9001, a nie wszystkie procesy, których firma potrzebuje do funkcjonować efektywnie - zobacz. Ryż. 2... Ponadto poziom szczegółowości procesów może nie być wystarczający do jasnego zrozumienia, co dzieje się w procesach i kto jest odpowiedzialny za jakie zadania w ramach procesu.
V najlepszy przypadek tylko kilka projektów testowych przeszło przez nowe procedury i po pewnym czasie staje się jasne, że należy je poprawić i uzupełnić. Często zaraz po certyfikacji SZJ o procesach zapomina się do czasu kolejnego audytu nadzorczego, zapominając jednocześnie o wydatkowanych zasoby finansowe i entuzjazm personelu.
Rzeczywiście, działając jako niezależny audytor, bardzo trudno jest udowodnić, że przyjęty poziom szczegółowości procesu jest wyraźnie niewystarczający do skutecznego funkcjonowania SZJ firmy. Niezwykle trudno jednak udowodnić coś przeciwnego w czasie przeznaczonym na audyt wg ISO 9000 (można to z powodzeniem wykorzystać w przypadku sprzeciwu wobec audytora). Praktyka pokazuje, że nie da się szybko zbudować efektywnych procesów nawet na 3 poziomie dojrzałości (a także procesów opartych na ISO 9000).
Aby to osiągnąć, nie wystarczy po prostu opisać procesy z uwzględnieniem wymagań wybranego modelu. Największym wyzwaniem jest to, że musisz przeprojektować kulturę produkcji w organizacji .

I nie jest to możliwe dzięki silnej decyzji kierownictwa. Dlatego podejście zdefiniowane w CMM jest po prostu bardziej opłacalne i realistyczne niż modele ISO 9000 cm. Ryż. 5.

Zastanówmy się teraz, jak w praktyce zbudować SZJ kompatybilny z obydwoma modelami.

Ekspercką ocenę stopnia pokrycia kluczowych procesów CMM wymaganiami normy ISO 9000:2000, zgodnie z oceną samych autorów CMM (4), przedstawiono w Rys. 6.

Faktyczna ocena została przez nich przeprowadzona w dwóch współrzędnych:

stopień utrzymalności (w%) zgodność procesów rozwojowych (SWP) z poziomem dojrzałości w ramach CMM -" bezpieczeństwo ";

stopień wykonalności (w%) takiej dostępności, który zapewnia ISO 9000: 2000 - " możliwość".

Jak widać z Ryż. 6, Tworzenie wymagań ISO 9000: 2000 prawdziwa okazja osiągnąć nawet wyższy (CMM Level 5) poziom dojrzałości SWP.

Jednak w sensie zapewnienia już dojrzałości SWP co najmniej na poziomie 3 (CMM Level 3), SZJ wg modelu ISO 9000:2000 wymaga niewielkiej modyfikacji – mianowicie opracowania i wdrożenia jeszcze dwóch procedur organizacyjnych ( Definicja procesu organizacji i ostrości) i procedury ogólne kierownictwo (Zintegrowane zarządzanie oprogramowaniem ), których treść nie jest trudna dla żadnej firmy informatycznej.

Ale można i trzeba iść dalej (CMM Level 4) – np. autorska ocena tego artykułu (w tych samych współrzędnych – dostępność i możliwości) jest pokazana w nawiasach, co odpowiada SZJ wg ISO 9000: model 2000, w którym krajobraz procesowy SZJ uzupełniany jest o zarządzanie projektami procesów zgodnie z wymaganiami drugiej ww. normy PM Bok- dzięki temu znacznie zwiększysz dojrzałość nawet takich SWP, w jaki sposób:

Monitorowanie postępu projektów (śledzenie i nadzór nad projektami oprogramowania);

• Planowanie projektów (Planowanie projektów oprogramowania);

Ogólne zarządzanie oprogramowaniem (Zintegrowane zarządzanie oprogramowaniem);

Ilościowe zarządzanie procesem.

Ryż. 6. Ekspercka ocena stopnia pokrycia kluczowych procesów CMM wymaganiami normy ISO 9000: 2000

Jak widać z Rys. 6., model CMM pod względem zawartych w nim zasad jest bardzo zbliżony do SZJ zbudowanego zgodnie z normą ISO 9001:2000 i uzupełnionego o procesy zarządzania projektami zgodnie z PM BoK..

Za nie robienie dodatkowa praca przy jednoczesnej certyfikacji wg ISO 9000 i późniejszej ocenie wg CMM, polecam przy definiowaniu swoich procesów produkcyjnych uwzględnić (a może ograniczyć je - w końcu to dla firmy IT i są procesy produkcyjne!) wśród nich wszystkie niezbędne w modelu CMM KPA. W ten sposób firma jednocześnie:

spełnia wymagania ISO 9001: 2000 w sprawie wdrożenia podejścia procesowego;

wszystkie niezbędne dokumenty WMP procesy ( KPA);

jednocześnie realizuje szereg tak ważnych wymagań ISO 9001: 2000 w jaki sposób:

kontrola procesu oparta na metrykach (Ilościowe zarządzanie procesem);

Zarządzanie dostawcami w oparciu o zarządzanie podwykonawcami ( Zarządzanie umowami podwykonawstwa oprogramowania );

analiza wymagań konsumentów na podstawie y wymagania dotyczące zarządzania ( Zarządzanie wymaganiami );

zarządzanie zasobami ludzkimi w oparciu o Programy szkoleniowe dla personelu (Program szkoleniowy );

zarządzanie komunikacją w oparciu o Formalne budowanie modelu procesy organizacyjne ( Definicja procesu organizacji );

uruchamia mechanizm doskonalenia (Zaplanuj-Wykonaj-Sprawdź-Działanie) wszystkie opisane procesy (SWP) poprzez sekwencyjną realizację wszystkich pięciu Wspólne cechy-cm. Ryż. 5.

Tak więc, jeśli używasz KPA CMM jako BP i stosujesz wymagania dotyczące procedur zarządzania projektami przy tworzeniu systemów oprogramowania premiera BoK, to tak skonstruowany SZJ można z powodzeniem oszacować na CMM Poziom 4 - cm. Ryż. 7.

Ryż. 7. Schemat osiągnięcia CMM Level 4 przy zastosowaniu modelu QMS wg ISO 9000 i podręcznika PM BoK 2000.

Podsumowując, dla jasności (stylizowany przez autora) przedstawiam schemat funkcjonowania SZJ firmy informatycznej przy konsekwentnym wdrażaniu modeli ISO 9000 i CMM – patrz. Ryż. osiem.

Ryż. 8. Schemat funkcjonowania SZJ z sekwencyjną implementacją modeli ISO 9000 i CMM (stylizowany przez autora)

Ważne jest, aby zrozumieć, że zarówno CMM, jak i ISO 9001:2000 są same w sobie tylko narzędziami do ciągłego doskonalenia.

Tym samym certyfikacja zgodnie z normą ISO 9001:2000 oraz potwierdzenie certyfikatu powinny przyczynić się do wzrostu jakości procesów firmy, gdzie kryterium oceny wzrostu jakości procesów jest wejście firmy na nowy poziom. BPI, czyli ich ocena jest już oparta na modelu, a mianowicie WMP {3}.

Literatura

„Ocena jakości oprogramowania”, V. Lipaev, Sinteg, 2001

ISO 9001:2000. System zarządzania jakością. Wymagania.

Paulk MC, Curtis B., Chrissis MB, Weber CV Capability Maturity Model for Software (SW-CMM), wersja 1.1. // CMU / SEI-93-TR-024, - luty, 1993.

Adnotacja: Szczegółowo badany jest zakres pomysłów leżących u podstaw prawdopodobnie najbardziej znanej metodologii usprawniania procesów wytwarzania oprogramowania – CMM. Analizowana jest logika i struktura SMM. Pokazano powiązanie HMM z wcześniej badanymi modelami procesów.

Cudowne praktyczne narzędzie wbudowane w podejście procesowe do opisu czynności organizacja projektowa w szczególności rozwijającej się organizacji Systemy informacyjne, przedstawia metodologię SMM. CMM oznacza Capability Maturity Model, co z grubsza oznacza „model dojrzałości systemu zarządzania”. W literaturze CMM jest częściej określane jako model dojrzałości organizacyjnej i ja również będę podążał za tą tradycją.

Historia powstania SMM jest następująca. Pod koniec lat 80-tych. W ubiegłym wieku Departament Obrony USA zlecił Instytutowi Inżynierii Oprogramowania 1eng. SEI - Instytut Inżynierii Oprogramowania Carnegie Mellon University pracuje nad ustaleniem systemu kryteriów wyboru podwykonawców w projektach rozwoju oprogramowania. Prace zakończono w 1991 roku, a efektem był model CMM. Konieczne jest natychmiastowe zastrzeżenie, że model nie zawiera żadnych finansowych, ekonomicznych, politycznych, organizacyjnych Kryteria wyboru podwykonawcę, a także kryteria możliwości dopuszczenia do pracy tajnej (prawdopodobnie nie ustalono takich zadań). Mówimy tylko o kryteriach opisujących zdolności potencjalnego podwykonawcy w zakresie tworzenia systemów oprogramowania.

Struktura CMM

Twórcy modelu przyjęli procesy organizacji jako podstawę oceny zdolności organizacji do wykonywania pracy wysokiej jakości, którą (zdolność) nazwano dojrzałością. Następnie przyjęli kilka nietrywialnych założeń, które później zostały zaakceptowane i uznane za sprawiedliwe przez wielu informatyków (a może i większość z nich).

Założenie 1... Istnieją jakościowo różne poziomy dojrzałości organizacja projektowa rozwój Systemy informacyjne(w modelu HMM jest pięć takich poziomów).

Założenie 2... Każda organizacja rozwojowa jest zainteresowana przejściem na wyższy poziom dojrzałości (nie tylko po to, by zwiększyć swoje szanse w walce o kontrakty z MON, ale także po to, by się doskonalić).

Założenie 3... Przejście jest możliwe tylko do następnego poziomu w kolejności. Nie da się „przeskoczyć” tego poziomu (dokładniej, dramatycznie wzrasta ryzyko dla organizacji).

W ten sposób poziomy tworzą „drabinę”, wzdłuż której organizacja wznosi się jako własny rozwój... Każdy poziom charakteryzuje się określonym składem i właściwościami procesów organizacji. „Drabina poziomów” SMM zyskała powszechną akceptację i dystrybucję. Tak to wygląda.

Poziom 1 „Początkujący”... Całość procesu produkcyjnego charakteryzuje się tym, że każdorazowo jest tworzona dla konkretnego projektu, a czasem wręcz chaotyczna. Zdefiniowanych jest tylko kilka procesów, a sukces projektu zależy od wysiłków poszczególnych osób.

Poziom 2 „Powtarzalny”... Ustanowione zostały główne procesy zarządzania projektami, pozwalające śledzić koszty, monitorować harmonogram prac oraz funkcjonalność tworzonych rozwiązanie programowe... Ugruntowana dyscyplina procesowa w celu odtworzenia poprzednich sukcesów w podobnych projektach rozwoju aplikacji.

Poziom 3 „Zdefiniowany”... Proces produkcyjny jest udokumentowany i ustandaryzowany zarówno pod kątem pracy zarządczej, jak i projektowania. Proces ten jest zintegrowany ze standardowym procesem produkcyjnym organizacji. Wszystkie projekty wykorzystują zatwierdzoną, dostosowaną do potrzeb wersję standardowego procesu produkcyjnego organizacji.

Poziom 4 „Zarządzany”... Zbierane są szczegółowe ilościowe wskaźniki procesu produkcyjnego oraz jakości tworzonego produktu. Zarówno proces produkcyjny, jak i produkty są określane ilościowo i monitorowane.

Poziom 5 „Optymalizacja”... Ciągłe doskonalenie procesu osiąga się poprzez ilościowe sprzężenie zwrotne z procesem i wdrażaniem w nim zaawansowanych pomysłów i technologii.

Mimo luzu powyższa definicja intuicyjnie najczęściej nie budzi zastrzeżeń. Co więcej, doświadczeni specjaliści rozumieją, dlaczego przejścia są możliwe tylko do sąsiedniego poziomu, a także dlaczego generalnie warto dążyć do takiego przejścia. Jednocześnie model HMM nie zawiera ilościowego ani przynajmniej formalnego uzasadnienia takiego podejścia, co jednak w najmniejszym stopniu nie umniejsza jego meritum.

Ponadto, jak mówią, jest to kwestia technologii. Określana jest struktura modelu (ryc. 7.1), podane są definicje, a żmudna praca zaczyna się od dokładnego opisywania każdego procesu na każdym poziomie. Aby docenić praktyczną wartość tego, co zostało zrobione, przejdziemy przez część tej ścieżki.

Ryż. 7.1.

Na ryc. 7.1 istnieją następujące koncepcje.

Grupa procesów kluczowych... Jak stwierdzono w (Paulk i in., 1995), „każda grupa procesów kluczowych definiuje blok powiązanych ze sobą czynności, w wyniku których realizacji osiągany jest zestaw celów istotnych dla zwiększenia produktywności produkcji proces. Na przykład dla grupy kluczowych procesów”. Zarządzanie wymaganiami„(patrz rysunek 7.2) celem jest dostosowanie wymagań projektu rozwoju oprogramowania między klientem a deweloperem”.

CMM nie poszczególne procesy... Zamiast tego istnieją odrębne czynności, zwane praktykami podstawowymi (patrz poniżej), które są ze sobą powiązane pod względem I/O i służą jako materiał wyjściowy do procesów budowlanych. CMM nie zawiera wskazówek dotyczących struktury procesów, czyli tego, w jaki sposób kluczowe praktyki są połączone w logiczne sekwencje. Zestawy podstawowych praktyk nazywane są grupami procesów podstawowych.

Ryż. 7.2.

Grupy kluczowych procesów w CMM są mapowane do poziomów dojrzałości (rys. 7.2), co oznacza, że ​​wszystkie praktyki na poziomie oddziałują tylko ze sobą i nie wchodzą w interakcje z praktykami na innych poziomach. Pozwala nam to zagwarantować pełną realizację wszystkich procesów na określonym poziomie, a tym samym skorelować poziom z zakończonym etapem rozwoju organizacji.

Przymiotnik „klucz” sugeruje, że istnieją grupy procesów(tj. zestaw praktyk), które nie są kluczowe z punktu widzenia określonego poziomu dojrzałości, tj. nie są związane z realizacją celów tego poziomu (patrz niżej). CMM nie obejmuje wszystkiego grupy procesów dotyczące rozwoju i utrzymania oprogramowania. Opisuje tylko te grupy, które zostały zidentyfikowane jako kluczowe determinanty produktywności procesu produkcyjnego.

Cele... Cele w SMM nie są powiązane z procesami, ale z grupami kluczowych procesów. Jak wspomniano powyżej, cele osiągane są poprzez wdrażanie kluczowych praktyk. W CMM osiągnięcie celu oznacza, że ​​po pierwsze po wykonaniu kluczowych praktyk uzyskuje się pożądany rezultat, a po drugie okazuje się on dość stabilny. Sposób, w jaki cele grupy procesów kluczowych są osiągane, może różnić się w zależności od projektu, w zależności od różnic w Tematyka lub środowisko.

Jeżeli cele te są realizowane dla wszystkich projektów, oznacza to, że organizacja osiągnęła poziom dojrzałości procesu produkcyjnego, co jest powiązane ta grupa kluczowe procesy.

Rozdział... Sekcje (jest ich pięć na każdym poziomie i zawsze są takie same) reprezentują właściwości grup kluczowych procesów, które muszą być zaimplementowane na odpowiednim poziomie. Właściwości te opisują, w jaki sposób procesy są wdrażane i jak są zalegalizowane w organizacji, to znaczy są oficjalnie zatwierdzone i zgodne z procedurami, politykami i innymi procesami korporacyjnymi. Oto pięć sekcji.

Zobowiązania do spełnienia

Opisz działania, które organizacja musi podjąć, aby zapewnić, że proces jest ustalony i stabilny. Obowiązki zgodności zwykle dotyczą ustanowienia polityki organizacyjnej i wsparcia ze strony kierownictwa wyższego szczebla.

Warunki wstępne

Opisać warunki wstępne, które musi spełnić projekt lub organizacja, aby właściwie wdrożyć proces produkcyjny; zwykle odnoszą się do zasobów, struktury organizacyjne i wymagane szkolenie.

Wykonane operacje

Sekcja „Wykonywane operacje” opisuje prace merytoryczne, które należy wykonać na tym poziomie. Wykonywane operacje zazwyczaj obejmują planowanie i wykonywanie określonych operacji, wykonywanie i śledzenie pracy oraz podejmowanie działań naprawczych w razie potrzeby.

Pomiary i analizy

Sekcja „Pomiary i

„Każdą Grupę Kluczowych Procesów wyrażają Kluczowe Praktyki, których wdrożenie przyczynia się do osiągnięcia celów Grupy. Kluczowe Praktyki opisują infrastrukturę i operacje, które najbardziej przyczyniają się do efektywnego wdrożenia i utworzenia Grupy Kluczowych Procesów.

Każda Kluczowa Praktyka składa się z jednego zdania, często poszerzonego o bardziej szczegółowy opis, który może zawierać przykłady i wyjaśnienia. Kluczowe praktyki, czasami nazywane kluczowymi praktykami Najwyższy poziom, ustalić podstawowe zasady, procedury i operacje dla grupy kluczowych procesów. składniki szczegółowy opis często nazywane sub-praktykami.”

Kluczowe Praktyki opisują CO należy zrobić, ale nie powinny być traktowane jako dogmaty mówiące JAK osiągnąć cele. Cele głównej grupy procesów można osiągnąć poprzez alternatywne praktyki. Interpretacja praktyk kluczowych powinna być rozsądna, pozwalająca na osiągnięcie celów grupy procesów kluczowych efektywny sposób, choć być może formalnie i różni się od zalecanej CMM.

Spojrzenie na działania zarządzania IT, w których zamiast procesów brane są pod uwagę ich komponenty – kluczowe praktyki, a procesy są obecne tylko wirtualnie, jako że coś, co można zbudować z kluczowych praktyk, na pierwszy rzut oka wygląda nieco egzotycznie. Do tej pory zadanie usprawnienia zarządzania IT rozwiązywane było poprzez wprowadzenie gotowych procesów z referencyjnego modelu procesów. Obecnie istnieje wiele poziomów, które zawierają odmienne (tj. niezintegrowane z procesami) kluczowe praktyki oraz zalecaną kolejność postępów na poszczególnych poziomach. Zarządzanie IT, według CMM, poprawia się wraz z przejściem na wyższy poziom dojrzałości. Co się dzieje z takim postępem?

W definicjach poziomów (patrz rys. 7.2) pojawiło się takie pojęcie jak „proces produkcyjny”. Występuje również w definicji grupy kluczowych procesów i nie jest to przypadkowy zbieg okoliczności. Proces produkcyjny lub, jak to trafnie nazwano w CMM, Standard Proces produkcji Organizacje (SPO) to jedna z głównych koncepcji całego modelu.

W listopadzie 1986 r. amerykański Instytut Inżynierii Oprogramowania (SEI), we współpracy z Mitre Corporation, rozpoczął opracowywanie Ankiety Dojrzałości Procesów Tworzenia Oprogramowania, która miała pomóc ulepszyć 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ła nieumiejętność zarządzania duże projekty... 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 r. firma SEI wydała streszczenie procesów tworzenia 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ł zwolniony Standard CMM, wersja 1.1, która jest nadal aktywnie używana 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:

1. Początkowy - Proces rozwoju jest chaotyczny. Tylko kilka procesów zostało zidentyfikowanych, a powodzenie projektów zależy od poszczególnych wykonawców.
2. 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).
3. 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.
4. 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.
5. 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 Związek ISO z CMM, Rational Unified Process, Project Management
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 (Capability Maturity Model Integration) – dalszy rozwój modelu CMM

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?

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

Model dojrzałości zdolności CM-CEI model organizacyjny, który opisuje 5 etapów (poziomów) ewolucyjnych, na których kontrolowane 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:

Praktyki można powtarzać. Jeśli nie powtarzasz operacji, nie powinieneś jej poprawiać. Istnieją zasady, procedury i praktyki, które zmuszają organizację do wdrożenia i konsekwentnego wdrażania. Najlepsze praktyki w zakresie organizacji pracy produkcyjnej można szybko rozpowszechniać wśród grup. Praktyki są zdefiniowane tak, aby umożliwić wymianę między projektami, zapewniając w ten sposób pewną standaryzację dla organizacji. Odchylenia w działaniu tych metod są zminimalizowane. Cele ilościowe są ustalane dla celów; a pomiary są ustalane, sporządzane i utrzymywane w celu stworzenia podstawy oceny. Praktyki są stale ulepszane w celu poprawy zdolności (optymalizacji).

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

Poziomy dojrzałości to koncepcja warstwowa, która zapewnia spójność dyscypliny niezbędną do ciągłego doskonalenia. Należy tutaj zauważyć, że organizacja rozwija umiejętność oceny konsekwencji nowej praktyki, technologii lub narzędzia. Dlatego nie chodzi o akceptację tych innowacji, ale raczej o to, jak te innowacyjne wysiłki wpływają na istniejące praktyki. Wspiera projekty, grupy i organizacje, dając im podstawę do dokonywania świadomych wyborów. Obszary procesów kluczowych — Obszar procesów kluczowych (KPA) definiuje grupę powiązanych ze sobą działań, które, wykonywane razem, pozwalają osiągnąć szereg ważnych celów. Cele — cele obszaru procesu kluczowego opisują postanowienia, które muszą istnieć dla tego obszaru procesu kluczowego. Regulacje muszą być wdrażane w skuteczny i niezawodny sposób. Stopień, w jakim cele są spełnione, pokazuje, jakie możliwości organizacja wyznaczyła na tym poziomie doskonałości. Cele określają obszary działalności, granice i cel każdego kluczowego obszaru procesu. Cechy wspólne — cechy wspólne obejmują praktyki, które wdrażają i instytucjonalizują kluczowe obszary procesów. Te 5 typów ogólna charakterystyka Należą do nich: Zaangażowanie w Zgodność, Zdolność do Zgodności, Podejmowane Inicjatywy, Pomiary i Analizy oraz Kontrola Wdrożeń. Kluczowe praktyki — Kluczowe praktyki opisują elementy infrastruktury i praktyki, które najskuteczniej przyczyniają się do wdrażania i instytucjonalizacji kluczowych obszarów procesów.

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?"

Wstęp

Najważniejszą częścią nowoczesnych złożonych systemów są oprogramowanie - składnik intelektualny. Produkty software'owe są obecnie wykorzystywane do rozwiązywania problemów zarządczych w niemal wszystkich sferach ludzkiej działalności: w gospodarce, społecznej, wojskowej i innych. Zapewnienie wysokiej jakości rodzimych produktów software'owych podczas ich masowego rozwoju i dostarczania dla różnych obszarów zastosowań w kraju i na rynku światowym stało się cel strategiczny.

Obecnie istnieją dwa niemal niezależne obszary standaryzacji w inżynierii oprogramowania i zapewnianiu jakości oprogramowania, które można warunkowo nazwać profilami norm ISO ( Międzynarodowa Organizacja standaryzacji) oraz modele dojrzałości SEI (US Software Engineering Institute). Pierwsze są wystarczająco w pełni reprezentowane w [,], a drugie - w [,]. Główna treść artykułu poświęcona jest modelom dojrzałości.

Aby zapewnić konkurencyjność w świecie złożonych produktów oprogramowania i możliwość ich pomyślnego eksportu, muszą być one opracowane i certyfikowane zgodnie z wymaganiami profile międzynarodowych standardów na bazie ISO 9000: 2000 lub modele dojrzałości - CMMI: 2003(Capability Maturity Model Integration - Zintegrowany model oceny dojrzałości inżynierii oprogramowania). Te dwa kierunki są metodologicznie bardzo bliskie i częściowo przecinają się poprzez wzajemne powiązania.

Poprawa wskaźników techniczno-ekonomicznych i jakości oprogramowania, a także zapobieganie błędom i usterkom zapewnia zastosowanie nowoczesnych technologii i systemów inżynierii oprogramowania projektowanie wspomagane komputerowo,... Są to wysokowydajne, oszczędzające zasoby technologie do tworzenia kompleksów programów o wysokiej jakości, niezawodności i bezpieczeństwie, mające na celu zmniejszenie całkowitego kosztu zasobów do projektowania, wdrażania i konserwacji narzędzi programowych (PS). W tym celu przede wszystkim konieczne jest zastosowanie metod i narzędzi analizy i projektowania, które od samego początku zapewniają konkretyzację i jak najdokładniejsze odwzorowanie celów, celów i funkcji. koło życia(Lifecycle) systemów oprogramowania i zapobieganie rozprzestrzenianiu się ewentualnych usterek systemowych na kolejne etapy rozwoju. Takie technologie inżynierii oprogramowania umożliwiają wykluczenie lub znaczne zmniejszenie poziomu błędów systemowych, algorytmicznych i programowych w produktach programowych przekazywanych do eksploatacji. Ponadto sprawdzają się przy modyfikowaniu i utrzymywaniu PS, a także przy zmianie otoczenie zewnętrzne.

Aby poświadczyć jakość, niezawodność i bezpieczeństwo złożonych, krytycznych systemów, stosowane w nich oprogramowanie poddawane jest orzecznictwo certyfikowane, zorientowane na problem centra testowe lub laboratoria. Takie testowanie jest konieczne, gdy programy kontrolują złożone, krytyczne procesy lub przetwarzają informacje tak ważne, że defekty lub niewystarczająca jakość mogą spowodować znaczne szkody. Testy certyfikacyjne muszą ustalić zgodność kompleksów oprogramowania z wymaganiami dokumentacji i pozwolić im działać w granicach zmian parametrów środowiska zewnętrznego, badanych podczas przeprowadzonych kontroli. Tego typu testy charakteryzują się największym rygorem i głębokością kontroli i powinny być wykonywane przez specjalistów niezależnych od twórców i klientów (użytkowników).

Podstawą certyfikacji powinny być szczegółowe i skuteczne programy i metody testowania kompleksów oprogramowania pod kątem zgodności ze znormalizowanymi wymaganiami klienta, specjalnie zaprojektowane problemy testowe i generatory do ich tworzenia, a także wysokie kwalifikacje i autorytet testerów. Stosowanie certyfikowanych systemów jakości w celu zapewnienia cyklu życia oprogramowania w oparciu o wymagania przedsiębiorstw tworzących oprogramowanie ISO 9000: 2000 lub CMMI: 2003, gwarantuje wysoką, zrównoważoną jakość zarządzania procesami i produktami ich cyklu życia, a także pozwala w wielu przypadkach ułatwić certyfikację finalnego produktu programowego. Dlatego też klienci złożonych projektów oprogramowania wybierają wykonawców, którzy posiadają certyfikaty potwierdzające stosowanie przez nich systemów zapewnienia jakości opartych na dostosowanych profilach norm międzynarodowych lub modelach dojrzałości.

Luki w nauczaniu metod inżynierii oprogramowania pozostawiają duży margines na dowolność specjalistów w ocenie jakości ich pracy, a także na pojawianie się licznych defektów i błędów w projektach programistycznych. Rosnąca złożoność i odpowiedzialność współczesne wyzwania, rozwiązane przez programy, a także ewentualne szkody wynikające z niedostatecznej jakości ich wyników, znacznie zwiększyły znaczenie opanowania metod pełnego, znormalizowanego opisu wymagań dla cech jakościowych i metod pomiaru ich rzeczywistych, osiąganych wartości​ ​na różnych etapach cyklu życia PS. Zdecydowanie wzrosła potrzeba znajomości przez specjalistów pojęć, definicji i metod oceny cech jakościowych oprogramowania.

Szybki wzrost i komplikacja kompleksów oprogramowania prowadzi do tworzenia dużych zespołów programistycznych z profesjonalnym podziałem pracy, w których konieczne jest uregulowanie skoordynowanych działań grup specjalistów w ramach jednego projektu. Obietnice umowne deweloperów dotyczące dostarczania wysokiej jakości oprogramowania w uzgodnionym terminie często nie są dotrzymywane. Dzieje się tak często ze względu na to, że klient i wykonawca oceniają poziom jakości według różnych kryteriów i nie mają porozumienia w tej kwestii, a podejście do oceny jakości programów nie jest wystarczająco sformalizowane. Ponadto czasami brakuje umiejętności właściwej oceny zasobów wymaganych do osiągnięcia wysokiej jakości programów. W rezultacie jakość oprogramowania często pozostaje niska, zawodna i niekonkurencyjna na rynku międzynarodowym. Dlatego najważniejszym problemem w rozwoju i zastosowaniu wielu nowoczesne systemy to szkolenie i kształcenie specjalistów w zakresie inżynierii oprogramowania, stosowanie międzynarodowych standardów, które przyczyniają się do wysokiej jakości oprogramowania oraz jego rzetelna ocena z głównym celem realizacji procesów projektowych zarządzany a wyniki są możliwy do przewidzenia... Niezbędna jest umiejętność sformalizowania wymagań i osiągnięcia określonych wartości cech jakości funkcjonowania i wykorzystania złożonych kompleksów programów, z uwzględnieniem dostępnych zasobów zapewniających i poprawiających tę jakość.

Model dojrzałości CMMI - 1,1, dopracowuje i ulepsza poprzednie modele WMP(patrz), a także częściowo uwzględnia podstawowe wymagania istniejących norm międzynarodowych w dziedzinie zarządzania oprogramowaniem. Znaczna uwaga w CMMI koncentruje się na procesach rozwoju i rozliczaniu iteracji, gdy zmieniają się wymagania klienta, śledząc je do funkcji, komponentów, testów i dokumentów projektowych. V Ostatnio pojawiła się informacja o modernizacji wersji 2003 przez instytut SEI CMMI - 1,1 w oparciu o doświadczenia i informacje zwrotne od firm. W 2006 roku planowane jest wydanie nowej, znacznie zmodernizowanej wersji modelu CMMI - 1,2, po czym wersja 1.1 powinna zostać wycofana. Do końca 2007 roku użytkownicy powinni przejść na wersję CMMI - 1,2, aw przyszłości stanie się obowiązkowa dla sformalizowanej oceny jakości (certyfikacji) technologii przedsiębiorstw w zakresie inżynierii oprogramowania. W takim przypadku ważność certyfikatu zostanie ograniczona do trzech lat. Klienci i twórcy dużych systemów oprogramowania powinni przygotować się na te zmiany przed oficjalną publikacją wersji 1.2 przez SEI.

Struktura i zawartość Modelu Dojrzałości CMMI - 1.1

Dwie opcje modelu CMMI - 1,1 stworzony, aby zapewnić ciągły ocena zbioru procesów w określonym obszarze tworzenia oprogramowania lub dla fazowe ocena i poprawa dojrzałości przedsiębiorstwa, a także organizacja cyklu życia kompleksów oprogramowania w ogóle. Modele CMMI udzielamy pomocy specjalistom w organizacji i doskonaleniu ich produktów, a także w usprawnianiu i utrzymaniu procesów tworzenia i utrzymania systemów oprogramowania. Koncepcja tych modeli obejmuje zarządzanie i ocenę dojrzałości złożonych systemów, inżynierię oprogramowania oraz procesy tworzenia zintegrowanych produktów oprogramowania i doskonalenia ich rozwoju. Komponenty modeli ciągłych i etapowych są w dużej mierze podobne i mogą być wybierane i stosowane w różnym składzie i kolejności użytkowania w zależności od właściwości i cech konkretnych projektów.

Opcje opisu modelu są budowane według jednego schematu, który zawiera sekcje ogólne:

• przedmowa;
• Sekcja 1 - wprowadzenie;
• Sekcja 2 — Model komponentów;
• Sekcja 3 - Terminologia;
• Sekcja 4 - zawartość poziomów i główne elementy każdej wersji modelu (opracowanie celów i procedur);
• Sekcja 5 - struktura interakcji procesów; cztery kategorie procesów z sekcji 7, ich ogólny przegląd i schematy interakcji procesów CMMI są opisane:
  • zarządzanie procesem;
  • zarządzanie - zarządzanie projektami;
  • technologia inżynieryjna);
  • Pomoc;
• Sekcja 6 - korzystanie z modelu CMMI- krótkie zalecenia dla użytkowników dotyczące korzystania z modelu i szkolenia; zauważono zgodność i zgodność procesów modelu z regulowanymi procesami poprzedniego modelu CMM w częściach 2 i 3 normy ISO 15504.
• Sekcja 7 jest ostatnią, największą w każdym standardzie, zajmuje około 500 stron z całkowitej objętości dokumentu, która wynosi ponad 700 stron. W tej sekcji znajdują się szczegółowe zalecenia dotyczące realizacji każdego z wymienionych w niej procesów, uwzględniające cechy konkretnego modelu.

Pierwsza opcja Model (ciągły) odzwierciedla dokument: Capability Maturity Model Integration (CMMI) dla inżynierii systemów / inżynierii oprogramowania / zintegrowanego rozwoju produktów i procesów, wersja 1.1, ciągła reprezentacja (CMMI-SE / SW / IPPD, V1.1, ciągły). Zintegrowany model oceny dojrzałości dla inżynierii systemów / inżynierii oprogramowania / zintegrowanych produktów i procesów rozwoju - ciągła prezentacja... W tym modelu sekcja siódma składa się z procesów:

• zarządzanie procesem:
  • organizacja szkoleń;
  • organizacja transformacji (zmian) procesów;
  • organizowanie innowacji i rozszerzeń;
• zarządzanie projektami:
  • planowanie;
  • monitorowanie i kontrola procesów projektowych;
  • Zarządzanie ryzykiem;
  • ilościowe zarządzanie projektami;
• technologia inżynieryjna):
  • zarządzanie wymaganiami;
  • opracowanie wymagań;
  • rozwiązania techniczne;
  • integracja produktów;
  • weryfikacja;
  • walidacja (certyfikacja, aprobata);
• Pomoc:
  • Zarządzanie konfiguracją;
  • analiza i podejmowanie decyzji dotyczących zmian;
  • analiza przyczyn i rozwiązywanie problemów (eliminacja usterek).

Pięć załączników zawiera:

A- skład wykorzystanej literatury i dokumentów, który jednak nie wymienia norm ISO;

V- skróty;

Z- słowniczek oparty na terminologii ISO stosowane tylko w czterech standardach ISO 9000, ISO 12207, ISO 15504: 1-9, ISO 15288;

D - opisy wymagań i propozycje tworzenia elementów modelu według poziomów dojrzałości;

E - lista uczestników rozwoju CMMI- projekt.

W tym modelu uwaga skupiona jest na procesach organizacyjnych, na planowaniu, zarządzaniu i kontroli realizacji projektów software'owych, na rozwoju i zarządzaniu wymaganiami dla produktów software'owych. Poniżej znajdują się przykłady szczegółowości w CMMI niektórzy z nich.

Planowanie zarówno w tym, jak iw drugim modelu obejmuje:

• ocena możliwy rozmiar(skala) oprogramowania;
• ocena złożoności funkcji i cech projektu PS;
• określenie modelu i etapów cyklu życia kompleksu programów;
• studium wykonalności projektu – określenie kosztów, pracochłonności i czasu trwania cyklu życia PS;
• opracowanie etapowego harmonogramu prac i budżetu projektu;
• analiza, identyfikacja i ocena ryzyk projektowych;
• planowanie i dokumentowanie zarządzania procesami i produktami w cyklu życia projektu PS;
• planowanie i dystrybucja zasobów technicznych i ludzkich według etapów cyklu życia PS;
• planowanie zapewnienia wiedzy i kwalifikacji zespołu specjalistów do realizacji projektu;
• generalizacja i analiza zbioru planów projektu PS;
• koordynacja prac i zasobów według etapów cyklu życia przez dewelopera z klientem projektu PS;
• udokumentowanie planu pracy i zatwierdzenie go przez kierownika projektu.

Procesy rozwoju wymagań do oprogramowania są podobne do procesów w obu modelach i obejmują:

• identyfikacja rzeczywistych potrzeb klienta i użytkowników w zakresie funkcji i właściwości oprogramowania;
• opracowanie i koordynacja między klientem a twórcą wstępnych, podstawowych wymagań dotyczących funkcji oprogramowania;
• określenie dostępnych zasobów i ograniczeń zespołu projektowego programów;
• dekompozycja podstawowych wymagań początkowych dla funkcji systemów oprogramowania na zbiór wymagań dla komponentów i testów pakietu oprogramowania;
• sformalizowanie wymagań dotyczących interfejsów pomiędzy komponentami, ze środowiskiem operacyjnym i zewnętrznym;
• opracowanie koncepcji oprogramowania i scenariuszy jego wykorzystania;
• opracowanie wymagań dla uogólnionych charakterystyk przydatności funkcjonalnej i wykorzystania funkcji oprogramowania zgodnie z jego przeznaczeniem.

Zarządzanie wymaganiami w obu modelach zawiera:

• osiągnięcie jednoznacznego zrozumienia wymagań projektu PS przez klienta i programistów;
• otrzymanie przez klienta od twórców zobowiązań do spełnienia wszystkich jego wymagań dotyczących oprogramowania;
• zarządzanie zmianami wymagań do projektu PS uzgodnionymi pomiędzy klientem a deweloperem;
• zapewnienie możliwości śledzenia poprawności zmian od wymagań ogólnych dla projektu PS do wymagań dla komponentów i procesów prywatnych;
• identyfikacja i identyfikacja niezgodności pomiędzy procesami rozwoju projektu a wymaganiami klienta.

Druga opcja przedstawia dokument: Integracja modelu dojrzałości (CMMI) dla inżynierii systemów / inżynierii oprogramowania / zintegrowanego rozwoju produktów i procesów, wersja 1.1, reprezentacja etapowa (CMMI-SE / SW / IPPD, V1.1, etapowe). Zintegrowany Model Oceny Dojrzałości dla Inżynierii Systemów Złożonych / Inżynierii Oprogramowania / Zintegrowanych Produktów i Procesów Rozwoju - prezentacja etapowa... Model opiera się na utrzymaniu koncepcji pięciu poziomów dojrzałości WMP[,]. Kompozycja procesów praktycznie powtarza tę podaną powyżej dla pierwszej wersji modelu, ale w nieco innej kolejności i ze stosunkowo niewielkimi dodatkami.

Pierwszy poziom charakteryzuje się znaczną niepewnością w składzie i treści procesów w różnych stosunkowo prostych projektach, dlatego nie jest komentowana w dokumencie. Dlatego przy wyjaśnianiu i uszczegóławianiu treści procesów w wersji etapowej CMMI zaleca się ograniczenie cztery główne poziomy:

• drugi poziom- formalizuje podstawowe zarządzanie projektowanie:
  • zarządzanie wymaganiami;
  • planowanie;
  • monitorowanie i kontrola projektów;
  • zarządzanie umowami z dostawcami;
  • pomiar i analiza procesów i produktów;
  • zapewnienie jakości procesów i produktów;
  • Zarządzanie konfiguracją;
• trzeci poziom- zawiera standaryzację głównych procesów:
  • opracowanie wymagań;
  • rozwiązania techniczne;
  • integracja produktów;
  • weryfikacja;
  • walidacja (certyfikacja);
  • treść procesów organizacyjnych;
  • definicja procesów organizacyjnych;
  • organizacja szkoleń;
  • zintegrowane zarządzanie procesami projektowymi i produktami;
  • Zarządzanie ryzykiem;
  • integracja zespołu programistów;
  • zintegrowane zarządzanie dostawcami;
  • analiza i rozwiązywanie problemów (eliminacja usterek);
  • organizacja środowiska integracji;
• czwarty poziom- określa zarządzanie ilościowe:
  • organizacja prezentacji jakości procesów;
  • ilościowe zarządzanie całym projektem i zasobami;
• piąty poziom- optymalizacja, ciągłe doskonalenie:
  • organizacja, innowacyjność, ilościowe zarządzanie procesami i zasobami;
  • analiza przyczyn defektów, poprawa jakości oraz zarządzanie procesami i produktami.

Aplikacje w drugiej wersji modelu mają podobny skład do powyższych aplikacji dla pierwszego modelu. Zaleca się aplikować na każdym wyższym poziomie dojrzałości wszystkie procesy poprzednie niższe poziomy. W obu wersjach modelu, każda z wyróżnionych powyżej, podstawowy proces jest skomentowany szczegółowymi zaleceniami jego praktycznej realizacji, które zawierają ujednolicone opisy o objętości około 20-30 stron:

• ogólne cele procesu do osiągnięcia;
• uwagi wstępne i ogólny opis funkcje procesu;
• konkretne cele procesu;
• zarządzanie procesem;
• opracowanie wymagań procesowych;
• interakcja i interfejsy z innymi procesami;
• cele praktyczne to wymagane wyniki działań procesowych;
• planowanie działań w pewnym procesie;
• analiza i walidacja (zatwierdzenie) wyników realizacji procesu;
• monitorowanie i kontrola procesu.

Te zalecenia dotyczące objętości, treści i kompletności opisów podstawowych procesów są podobne do szeregu norm dotyczących cyklu życia PS przedstawionych w. Usprawnienie i ocena kompletności wykorzystywanych procesów zgodnie z poziomami dojrzałości, pozwala na ustalenie potencjału produkcyjnego przedsiębiorstw - programistów zgodnie z przewidywaną jakością procesów i wyników ich działań oraz gotowością do certyfikacji na zgodność z pewien poziom dojrzałości modelu CMMI - 1.1.

Szczególna uwaga w modelach CMMI dotyczy procesów zarządzania projektem PS. Te wymagania i procesy modelowe są ściśle powiązane z określonymi i szczegółowymi wytycznymi zawartymi w normach. ISO 9001: 2000 oraz główne elementy profilu standardów cyklu życia dla złożonych systemów oprogramowania [,]. Wymagania dla procesów w punktach funkcjonalnych 4-8 standardów ISO 9001, ISO 9004, ISO 90003 można porównać wiele sekcji w modelu, które są adekwatne pod względem treści CMMI(na Rysunku 1 występuje nakładanie się obudowy). Wspólność procesów i wymagań polega na podobieństwie: składu, terminologii, struktury, listy zalecanych procesów zarządzania, planowania, rozliczania dostępnych zasobów, realizacji procesów inżynierii oprogramowania, oceny i organizacji specjalistów.

Rysunek 1. Wspólność procesów i wymagań standardów oraz modeli dojrzałości

Z punktu widzenia wsparcia i regulacji pełnego cyklu życia dużych projektów oprogramowania na wady modeli CMMI o profilu istniejących standardów ISO obejmują następujące elementy:

Aby określić powyższe poziomy dojrzałości procesów zapewnienia cyklu życia oprogramowania, opracowano obszerny raport techniczny, który został wstępnie zatwierdzony w 1998 roku. ISO 15504, składający się z dziewięciu części i wielu zastosowań. Określa model dojrzałości WMP oraz osiem podstawowych zasad inżynierii oprogramowania opartych na standardzie ISO 9000: 2000... Następnie w ISO dokument ten przeszedł radykalną rewizję, redukcję, uproszczenie struktury i treści, z pełnym zachowaniem celów i koncepcji oraz został zatwierdzony standardowo w pięciu częściach.

Standard ISO 15504: 1-5: 2003-2006 reguluje ocenę i poświadczanie dojrzałości procesów tworzenia, utrzymania i doskonalenia narzędzi i systemów oprogramowania realizowanych przez przedsiębiorstwa:

• ustalenie stanu własnych procesów technologicznych i ich udoskonalenie;
• określić przydatność własnych procesów do spełnienia określonych wymagań lub klas wymagań klienta;
• w celu jego przydatności do realizacji niektórych umów z klientami PS i systemów.

Norma przyczynia się do: samocertyfikacji dojrzałości przedsiębiorstw, zapewnienia odpowiedniego zarządzania certyfikowanymi procesami, określenia profilu ocen procesów, a także jest odpowiednia dla dowolnych obszarów zastosowań i wielkości PS i systemów. Stosowanie normy ma na celu rozwój przedsiębiorstw i specjalistów kultura ciągłego doskonalenia dojrzałości technologii zapewnienie cyklu życia PS spełniającego cele biznesowe projektów i optymalizującego wykorzystanie dostępnych zasobów. Poświadczenie dojrzałości procesów przedsiębiorstwa daje możliwość ich porównania i selekcji, które są preferowane w przypadku niektórych projektów:

• dla klientów, nabywców, użytkowników oprogramowania i systemów: możliwość określenia aktualnej i potencjalnej dojrzałości procesów cyklu życia dostawcy;
• dla dostawców i deweloperów: umiejętność określenia aktualnej i potencjalnej dojrzałości własnych procesów cyklu życia oprogramowania i systemów, obszarów i priorytetów doskonalenia procesów;
• dla asesorów dojrzałości: podstawa prowadzenia i doskonalenia procesów atestacyjnych.

Aprobaty w normie są adresowane w: dwa aspekty: doskonalenie procesów cyklu życia PS i systemów konkretnego przedsiębiorstwa oraz określenie zgodności deklarowanej dojrzałości procesów zapewnienia projektu lub przedsiębiorstwa z faktycznie stosowanymi procesami. Znajduje to odzwierciedlenie w kolejnych pięciu częściach standardu ISO 15504: 1-5: 2003-2006.

Część 1 - Pojęcie i słownictwo. Zawiera informacje ogólne w sprawie procesów poświadczania dojrzałości oprogramowania i systemów oraz zaleceń dotyczących stosowania części normy. Podano ogólne wymagania dotyczące atestacji, terminologii, struktury, określono zakres pozostałych części normy.

Część 2 - Wykonanie (produkcja) atestu. Zawiera szczegółowe wymagania dla procesów atestacyjnych jako podstawę do doskonalenia i określania poziomu dojrzałości procesów technologicznych dla zapewnienia cyklu życia oprogramowania i systemów. Dokument definiuje procesy przeprowadzania atestacji, modele zalecanych procesów atestacyjnych oraz weryfikacji procesów tak, aby były obiektywne, znaczące i reprezentatywne.

Część 3 - Instrukcja do produkcji atestu. Zawiera przegląd technologii wykonywania procesów atestacji dojrzałości i interpretacji implementacji wymagań. Odzwierciedla: wykonanie certyfikacji; przyrządy pomiarowe do określania procesów dojrzałości; wybór i zastosowanie narzędzi certyfikacyjnych; ocena kompetencji asesorów; weryfikacja zgodności certyfikacji z deklarowanymi wymaganiami. Narzędzia certyfikacyjne mogą być wykorzystywane przez przedsiębiorstwa w planowaniu, zarządzaniu, monitorowaniu, kontroli i doskonaleniu produktów i systemów oprogramowania, w ich nabywaniu, rozwoju, stosowaniu i utrzymaniu.

Część 4 – Wskazówki dla użytkowników dotyczące procesów doskonalenia i określania dojrzałości procesu w tych dwóch aspektach. Zalecany jest szereg kroków, które obejmują: zastosowanie wyników procesów kwalifikacyjnych; wyznaczanie celów dla poświadczania dojrzałości; ustalenie danych wyjściowych do atestacji; ocena ewentualnego ograniczenia wynikającego z tego ryzyka; kroki w celu poprawy procesów; kroki w celu określenia poziomu dojrzałości; porównanie wyników analizy atestacyjnej z wymaganiami.

Część 5 - Przykładowy model procesów walidacji na zgodność z wymaganiami przedstawionymi w Części 2. Obszerny dokument (162 strony) zawiera przykłady praktycznego zastosowania poprzednich części normy do organizowania, oceny i doskonalenia atestacji dojrzałości procesów cyklu życia dla różnych obszarów zastosowań, projektów oprogramowania i przedsiębiorstw.

W praktycznej realizacji projektów i zapewnieniu cyklu życia złożonych systemów oprogramowania, czasami deweloperom i dostawcom trudno jest zidentyfikować i wyizolować zalety modeli do wykorzystania. CMMI... W zależności od tradycji przedsiębiorstwa i specyfiki dużego projektu PS, często wskazane jest zastosowanie kompletnego profil standardówISO i do oceny przez klientów poziom dojrzałości zarządzanie, wsparcie organizacyjne i technologiczne projektów PS w celu zastosowania określonych zaleceń CMMI... Zalecenia te można skutecznie wykorzystać, gdy certyfikacja jakości procesu w przedsiębiorstwach świadczących usługi cyklu życia, jako alternatywa lub wraz z certyfikacją wg zbioru standardów zarządzania ISO 9000, w zależności od specyfiki projektu i wymagań wnioskodawcy dotyczących certyfikacji oprogramowania lub technologii w celu zapewnienia jego cyklu życia.

Organizacja certyfikacji produktów oprogramowania

Certyfikacja składa się z szeregu procesów organizacyjnych, które składają się system certyfikacji Procesy te są wspierane przez regulowane procedury i dokumenty i muszą być realizowane przez wykwalifikowanych, certyfikowanych inspektorów. Za certyfikację przedsiębiorstwa deweloperskiego i wyników jego działalności - oprogramowanie, modele CMMI lub standardy profili ISO[,] zalecana jest pewna dyscyplina, która powinna być dostosowana do specyfiki obiektów i środowiska zewnętrznego cyklu życia systemu oprogramowania. Wymienione poniżej procesy i dokumenty skupiają się na dużych projektach, a ich skład można w prostszych przypadkach zmniejszyć poprzez porozumienie między programistami, klientami i jednostkami certyfikującymi.

Prace certyfikacyjne rozpoczynają się od akredytacji jednostki lub laboratorium badawczego, sporządzenia i złożenia wniosku oraz kompletu dokumentów do Centralnej Jednostki Certyfikującej w celu podjęcia decyzji o celowości akredytacji. W przypadku pozytywnego wyniku badań wystawiany i wydawany jest certyfikat akredytacji.

Rozporządzenie w sprawie jednostki certyfikującej lub laboratorium jest głównym dokumentem ustalającym obszar tematyczny akredytacji, status prawny, funkcje, strukturę, prawa i obowiązki, metody, środki i organizację badań. Paszport laboratorium certyfikującego (ośrodka) musi zawierać informacje o wyposażeniu w sprzęt komputerowy niezbędny do badań, personel i personel, wyposażenie w narzędzia badawcze, dostarczenie dokumentów regulacyjnych, technicznych i metodologicznych, a także inne zasoby niezbędne do badań.

Przewodnik jakości zawiera zestawienie zasad, opis metod i procedur związanych z realizacją głównych funkcji i zadań jednostki certyfikującej lub laboratorium, zapewniających jakość wykonywanych testów oraz zaufanie do wyników ocen, testów i badań. Podręcznik jakości zwykle zawiera sekcje [TWLSC $

• polityka zapewniania jakości testowania i badania;
• wyposażenie centrum w nowoczesne materiały metodyczne oraz oprogramowanie i narzędzia testujące;
• formalizacja wymagań dla obiektów testowych;
• polityka w zakresie wyposażenia technicznego ośrodka i rozwoju kadr;
• archiwizacja i kontrola bezpieczeństwa dokumentacji wyników certyfikacji.

Wnioskodawca ubiegający się o ocenę wyrobu lub procesu podlegającego certyfikacji powinien przesłać do jednostki certyfikującej wniosek w formie przyjętej w systemie certyfikacji. Na żądanie jednostka certyfikująca prowadzi prace związane z przygotowaniem i organizacją certyfikacji wyrobów. Ta praca obejmuje:

• wybór schematu certyfikacji uwzględniającego specyfikę produktu (wolumen, technologia, wymagania dokumentów regulacyjnych itp.) oraz propozycje dewelopera;
• określenie liczby i kolejności pobierania próbek oraz składników do badania, jeżeli nie jest to określone w normach;
• wybór i wyznaczenie akredytowanego laboratorium badawczego, które powinno przeprowadzać badania;
• przygotowanie projektu umowy o wykonanie pracy.

Część przygotowawcza prac certyfikacyjnych kończy się wydaniem decyzji w formie przyjętej w systemie certyfikacji. Decyzja wraz z projektem umowy o wykonanie prac przesyłana jest do wnioskodawcy. Organizując testy certyfikacyjne, przeprowadza się wybór i badanie aktualnych dokumentów regulacyjnych dla produktów zgłoszonych do certyfikacji, metody ich testowania i oceny wyników.

Wnioskodawca podejmuje ostateczne decyzje, które elementy systemu jakości, obszary oraz rodzaje działań organizacyjno-technicznych podlegają weryfikacji podczas certyfikacji w zadanym przedziale czasowym. Wnioskodawca musi stworzyć warunki i złożyć dokumenty wspierające procesy weryfikacji. Potrafi przedłożyć jednostce certyfikującej raporty z badań przeprowadzonych podczas opracowywania i wprowadzania produktów do produkcji, dokumenty z badań przeprowadzonych przez zewnętrzne laboratoria badawcze oraz inne dokumenty potwierdzające zgodność technologii lub produktów z ustalonymi wymaganiami. Na podstawie analizy dokumentacji dowodowej dostarczonej wraz z wnioskiem o zgodność swoich wyrobów z ustalonymi wymaganiami, jednostka certyfikująca może podjąć decyzję o zmniejszeniu zakresu badań lub wydaniu certyfikatu.

Testy są przeprowadzane przez laboratoria badawcze akredytowane do przeprowadzania tylko tych testów, które są przewidziane w ich regulacyjnych dokumentach akredytacyjnych. W przypadku braku możliwości przeprowadzenia badań w bazie badawczej laboratorium akredytowanego, badania mogą być wykonywane przez personel tego laboratorium u producenta lub konsumenta tego produktu przy użyciu środków własnych laboratorium badawczego lub narzędzi badawczych dostępnych u dostawcy.

Proces certyfikacji oprogramowania i systemów jakości przedsiębiorstwa obejmuje:

• analiza i wybór przez dewelopera lub klienta (wnioskodawcę) jednostki i certyfikowanego laboratorium właściwego w tym zakresie do wykonywania badań certyfikacyjnych;
• wnioskodawca składa wniosek o przeprowadzenie badań do jednostki certyfikującej, a osoby certyfikujące podejmują decyzję w sprawie wniosku, wyboru systemu certyfikacji, zawarcia umowy o certyfikację;
• identyfikacja wymagań dotyczących systemu jakości przedsiębiorstwa i/lub wersji testowanego oprogramowania;
• wykonywanie testów certyfikacyjnych systemu jakości przedsiębiorstwa lub wersji oprogramowania przez laboratorium certyfikujące;
• analiza uzyskanych wyników i podjęcie przez laboratorium i/lub jednostkę certyfikującą decyzji o możliwości wydania wnioskodawcy certyfikatu zgodności;
• wydanie wnioskodawcy przez jednostkę certyfikującą certyfikatu i licencji na używanie znaku zgodności oraz na dopuszczenie certyfikowanych produktów - wersji oprogramowania;
• wdrożenie kontroli inspekcji przez jednostkę certyfikującą certyfikowanego systemu jakości przedsiębiorstwa i / lub produktów;
• podjęcie działań naprawczych przez wnioskodawcę w przypadku naruszenia zgodności procesów systemu jakości i/lub wyrobów z ustalonymi wymaganiami oraz w przypadku nieprawidłowego stosowania znaku zgodności.

Przegląd odpowiedzialności kierownictwa dewelopera za jakość produktu powinien określić, czy obiekt lub projekt ma udokumentowaną politykę jakości, cele i zobowiązania oraz stopień, w jakim polityka jest zrozumiana, wdrożona i utrzymywana na wszystkich poziomach organizacji. Należy ustalić, że przedsiębiorstwo ma przedstawiciela kierownictwa, który niezależnie od innych obowiązków ma uprawnienia i odpowiedzialność za ciągłe wdrażanie wymagań norm i dokumentów regulacyjnych systemu jakości. Niezbędne jest sprawdzenie dostępności wymagań, procedur, narzędzi i przeszkolonego personelu do praktycznej realizacji procesów systemu jakości, a także aktualności i prawidłowości dokumentacji dla wszystkich elementów, wymagań i zapisów systemu jakości, który jest zintegrowany proces przez cały cykl życia PS. Kontrole systemu jakości powinna zawierać definicję:

• dostępność i kompletność dokumentacji technologicznej oraz zgodność z jej wymaganiami w praktyce;
• stan urządzeń technologicznych i dostępność systemu do ich konserwacji;
• dostępność i skuteczność systemu kontroli i testowania;
• stan przyrządów pomiarowych i testujących;
• dostępność systemu do identyfikacji i eliminacji zidentyfikowanych braków w produktach lub technologii.

Na podstawie przeprowadzonych testów uzyskane wyniki są oceniane i uzasadnione wnioski dotyczące zgodności lub niezgodności produktów lub procesów z wymaganiami dokumentów regulacyjnych. Sprawozdania z badań są przedkładane jednostce certyfikującej, a także wnioskodawcy na jego żądanie. Sprawozdania z badań podlegają przechowywaniu przez okresy ustalone w regulaminach systemów certyfikacji wyrobów oraz w dokumentach laboratorium badawczego, nie krócej jednak niż trzy lata.

Po otrzymaniu i sprawdzeniu kompletności i jakości dokumentacji przez specjalistów laboratorium badawczego, badanie stopnia rzeczywistego zastosowania systemu jakości, w przedsiębiorstwie. Testowanie rozpoczyna się od programu audytu systemu jakości, który powinien służyć jako plan pracy dla dalszych prac. Program jest wewnętrznym dokumentem roboczym laboratorium badawczego i musi zawierać wykaz prac, uszczegółowiony zgodnie ze specyfiką twórcy oraz zawierający analizę kompletności i jakości przedłożonych dokumentów źródłowych oraz stopień ich praktycznego zastosowania w projektowanie, rozwój i dostarczanie systemów oprogramowania. Badanie stosowania procedur systemu jakości przeprowadzane jest przez laboratorium badawcze na stanowiskach pracy przedsiębiorstwa, które zapewnia cykl życia PS. Przeprowadzane są kontrole dostępności specjalistów-deweloperów odpowiednich dokumentów w miejscu pracy oraz kompletności wykorzystania ich przepisów i zaleceń. Przeglądy statusu projektu oraz audyty wewnętrzne systemu jakości, procesów i/lub produktów powinny być wykonywane przez personel niezależny od osób bezpośrednio odpowiedzialnych za pracę.

Metodyki kontroli jakości rozwoju muszą otrzymać niezbędne zasoby do przeprowadzenia programu badań, metod planowania i opracowania prywatnych procedur inspekcji. Metody powinny zawierać: przedmioty i cele testowania; oceniane wskaźniki jakości; warunki i procedura testowania; metody przetwarzania, analizy i oceny wyników badań; testowe wsparcie techniczne i raportowanie. Należy wskazać sprzęt i oprogramowanie używane podczas testów oraz procedurę testową, a także oczekiwane wyniki testów. Należy opracować metody monitorowania poprawek, działania mające na celu naprawę usterek, jeśli takie żądanie otrzyma służba zarządzania inspekcją. Służba zarządzania programem testów powinna opracować metody zachowania poufności wszelkich informacji testowych, jak również danych posiadanych przez ekspertów.

Raporty z testów przedłożony wnioskodawcy i jednostce certyfikującej. Wnioskodawca może przedłożyć jednostce certyfikującej sprawozdania z badań, z uwzględnieniem warunków ich ważności, przeprowadzonych podczas opracowywania i wprowadzania wyrobów do produkcji, lub dokumenty z badań przeprowadzonych przez krajowe lub zagraniczne laboratoria badawcze, akredytowane lub uznane w certyfikacji system. Na podstawie protokołów badań certyfikacyjnych uzyskane wyniki są oceniane, a wyciągnięte wnioski dotyczące zgodności lub niezgodności produktów z wymaganiami dokumentów regulacyjnych są uzasadnione.

Wnioski dotyczące wyników testów certyfikacyjnych jest opracowywany przez osoby certyfikujące i zawiera uogólnione informacje o wynikach badań oraz uzasadnienie celowości wydania certyfikatu. W przypadku negatywnych wyników badań certyfikacyjnych podejmuje się decyzję o odmowie wydania certyfikatu zgodności. Po rewizji certyfikowanego produktu lub systemu jakości testy można powtórzyć. Wyniki analizy stanu technologii lub jakości produktu sformalizowane przez ustawę, który zawiera oceny dla wszystkich elementów Programu Testowego i zawiera wnioski, w tym: ocena ogólna stan produkcji i produktów, konieczność podjęcia działań naprawczych. Ustawa jest wykorzystywana przez jednostkę certyfikującą wraz z raportami z badań, wnioskiem o wydanie i ustalenie okresu ważności certyfikatu dla oprogramowania, częstotliwości kontroli inspekcyjnych, a także do opracowania działań naprawczych.

Na podstawie wyników badań certyfikacyjnych i badania dokumentacji podejmowana jest decyzja o wydaniu certyfikatu. W przypadku negatywnych wyników badań certyfikacyjnych podejmowana jest decyzja o: odmowa wydania zaświadczenia zgodność. Dodatkowo do wnioskodawcy mogą zostać wysłane propozycje wyeliminowania domniemanych przyczyn negatywnych wyników testów, po zakończeniu certyfikowanego produktu testy mogą zostać powtórzone.

Jednostka certyfikująca po przeanalizowaniu raportów z badań, ocenie produkcji, certyfikacji systemu jakości, przeanalizowaniu dokumentacji określonej w decyzji o wniosku, ocenia zgodność wyrobów z ustalonymi wymaganiami, na podstawie ekspertyzy sporządza certyfikat i rejestruje go . W przypadku wprowadzenia zmian do projektu lub dokumentacji operacyjnej, które mogą mieć wpływ na jakość systemu lub oprogramowania, certyfikowanego podczas certyfikacji, wnioskodawca musi powiadomić jednostkę certyfikującą, aby podjęła decyzję o potrzebie przeprowadzenia dodatkowych testów. Po rejestracji certyfikat wchodzi w życie i jest wysyłany do firmy wnioskodawcy. Równolegle z wydaniem certyfikatu może zostać wydane przedsiębiorstwo wnioskodawcy licencja o prawo do używania znaku zgodności.

dla certyfikowanych produktów programowych podczas ich eksploatacji przez cały okres ważności certyfikatu zgodności, kontrola inspekcyjna... Kontrola inspekcyjna realizowana jest w formie kontroli okresowych i pozaplanowych zgodności z wymaganiami dotyczącymi jakości technologii i certyfikowanych wyrobów. Przedmiotem kontroli, w zależności od schematu certyfikacji, są wyroby certyfikowane, system jakości lub stabilność produkcji dewelopera. Przy określaniu częstotliwości i głośności kontrola inspekcyjna brane są pod uwagę następujące czynniki: stopień potencjalnego zagrożenia produktu programowego, stabilność produkcji, wielkość produkcji, obecność i zastosowanie systemu jakości podczas rozwoju, informacje o wynikach testów produktu i jego produkcja realizowana przez producenta, władze kontrola państwowa i nadzór.

Wyniki kontroli inspekcji sformalizowane przez ustawę, który ocenia wyniki badań próbek i innych kontroli, wyciąga ogólny wniosek o stanie produkcji certyfikowanych wyrobów oraz o możliwości zachowania ważności wydanego certyfikatu. Akt jest przechowywany przez jednostkę certyfikującą, a jego kopie wysyłane są do dewelopera i organizacji, które wzięły udział w kontroli inspekcji. Na podstawie wyników kontroli jednostka certyfikująca może zawiesić lub unieważnić ważność certyfikatu oraz cofnąć licencję na prawo do używania znaku zgodności w przypadku niezgodności wyrobu z wymaganiami dokumentów regulacyjnych kontrolowanych podczas certyfikacji, a także w następujących przypadkach:

• fundamentalne zmiany w modelu dojrzałości, profilu norm, regulacjach produktowych czy metodzie badań;
• zmiany w projekcie (skład), kompletność produktów;
• zmiany w organizacji lub technologii rozwoju i produkcji;
• niezgodność z wymaganiami technologii, metod kontroli i badań, systemu jakości, jeżeli wymienione zmiany mogą powodować niezgodność wyrobów z wymaganiami kontrolowanymi podczas certyfikacji.

Decyzja o zawieszeniu ważności certyfikatu i licencji na prawo do używania znaku zgodności nie jest podejmowana, jeżeli wnioskodawca za pomocą środków naprawczych uzgodnionych z jednostką certyfikującą, która go wydała, może usunąć stwierdzone przyczyny niezgodności oraz potwierdzić, bez ponownego badania w akredytowanym laboratorium, zgodność produktu lub procesów z dokumentami regulacyjnymi. Jeśli nie jest to możliwe, ważność certyfikatu zostaje unieważniona, a licencja na prawo do używania znaku zgodności zostaje unieważniona. Informacja o zawieszeniu lub unieważnieniu certyfikatu jest przekazywana wnioskodawcy, konsumentom i innym zainteresowanym organizacjom przez jednostkę certyfikującą, która go wydała. Ważność certyfikatu i prawo do oznaczania wyrobów znakiem zgodności można odnowić, jeżeli przedsiębiorstwo deweloperskie spełni następujące warunki:

• zidentyfikowanie przyczyn niezgodności i ich wyeliminowanie;
• przedłożenie jednostce certyfikującej sprawozdania z pracy wykonanej w celu poprawy i zapewnienia jakości produktu;
• przeprowadzenie dodatkowych badań wyrobów zgodnie z metodami i pod kontrolą jednostki certyfikującej oraz uzyskanie pozytywnych wyników.

Dokumentowanie procesów i wyników certyfikacji oprogramowania,

Skład i zawartość dokumentacji do certyfikacji systemu jakości przedsiębiorstwa są uzależnione od cech projektowania, rozwoju i modyfikacji oprogramowania, a także od wymagań dotyczących jego jakości i charakterystyki środowiska technologicznego. Dlatego wymagany zestaw dokumentów dla każdego przedsiębiorstwa lub projektu powinien być wybrany i dostosowany w odniesieniu do tych cech. Wskaźnikami systemu jakości ocenianymi podczas certyfikacji są dostępność odpowiednich dokumentów oraz praktyczne spełnienie wymagań określonego poziomu modelu dojrzałości CMMI lub dostosowany profil standardów oparty na ISO 9000: 2000, a także tworzone na ich podstawie opisy stanowisk pracy przez specjalistów z przedsiębiorstwa deweloperskiego. Wnioskodawca musi przygotować i przedłożyć laboratorium badawczemu zestaw dokumentów uzgodnionych między klientem a wykonawcą oraz zatwierdzony zestaw dokumentów w celu sprawdzenia ich wiarygodności, wystarczalności składu i jakości produkcji zgodnie z dokumentami regulacyjnymi.

Orientacyjny zestaw podstawowych dokumentów do certyfikacji składa się z trzech grup:

• podstawowy przepisy prawne systemy jakości zgodne z nomenklaturą i treścią profilu norm w oparciu o ISO 9000: 2000 lub modele dojrzałości CMMI, a także program, podręcznik i instrukcje przygotowane na ich podstawie przez programistów, przedstawione testerom (ekspertom) systemu jakości lub produktów audytowanego przedsiębiorstwa;
• dokumenty źródłowe charakteryzujące konkretne przedsiębiorstwo lub projekt oraz cykl życia narzędzia programowego, przygotowane przez kierownictwo projektu do certyfikacji jego jakości;
• dokumenty sprawozdawcze testerów, odzwierciedlające wyniki weryfikacji (certyfikacji) systemu jakości przedsiębiorstwa i / lub oprogramowania, przedłożone jednostce certyfikującej, wnioskodawcy i kierownictwu badanego przedsiębiorstwa.

Produkt oprogramowania lub system jakości przedsiębiorstwa zgłoszony do certyfikacji należy przedłożyć wraz z odpowiednią dokumentacją. Lista i przybliżona zawartość grup tych dokumentów koncentruje się na ogólnym przypadku sprawdzania systemów jakości przedsiębiorstw, które zapewniają cykl życia dużych produktów oprogramowania. Zbiór dokumentów może zostać skrócony i dostosowany w drodze porozumienia pomiędzy wnioskodawcą, certyfikującym i kierownictwem audytowanego przedsiębiorstwa zgodnie z charakterystyką projektów oprogramowania. Niektóre dokumenty można łączyć w zintegrowane raporty z wyraźną odpowiedzialnością określonych specjalistów za ich wdrożenie.

Podstawowe dokumenty systemu jakości przedsiębiorstwa i cyklu życia narzędzia programowego

1. Koncepcja, terminologia, wymagania i wytyczne dotyczące doskonalenia wydajności - systemy zarządzania jakością - ISO 9000: 2000 lub wersja modelu dojrzałości CMMI.
2. Dostosowane wersje lub wykaz klauzul i zaleceń norm ISO 12207, ISO 15504, ich zmian i instrukcji stosowania, wyróżnionych podczas adaptacji i obowiązkowych do stosowania w systemie jakości danego przedsiębiorstwa lub projektu oprogramowania.
3. Dostosowana wersja lub lista klauzul i zaleceń normy ISO 900003, przydzielone podczas adaptacji i obowiązkowe do stosowania w systemie jakości przedsiębiorstwa wytwarzającego oprogramowanie.
4. Podstawowe cechy i atrybuty jakościowe projektu PS wyróżnione, dostosowane i określone na podstawie norm ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Dostosowana wersja i zatwierdzona edycja wytycznych dotyczących zarządzania utrzymaniem i konfiguracją w oparciu o zalecenia standardów ISO 14764, ISO 10007, ISO 15846.
6. Zbiór opisów stanowisk, które określają odpowiedzialność, uprawnienia i procedurę współdziałania całego kierownictwa, wykonującego i sprawdzającego pracę personelu uczestniczącego w procedurach systemu jakości przedsiębiorstwa dla konkretnego projektu PS.

Dokumenty źródłowe odzwierciedlające cechy cyklu życia konkretnego narzędzia programowego

1. Opis charakterystyk produktów programowych powstających w przedsiębiorstwie, systemu i środowiska zewnętrznego ich cyklu życia, niezbędnych do adaptacji i przygotowania roboczych wersji standardów i wymagań projektu PS oraz systemu jakości przedsiębiorstwa zgodnie z zalecenia standardów ISO 12207, ISO 15504, ISO 90003 oraz ISO 9126.
2. Opis celów, wymagań i obowiązków dewelopera przedsiębiorstwa w zakresie systemu jakości, kryteriów jakości procesów i produktów wytwarzania, dostarczania i obsługi całego cyklu życia systemu oprogramowania.
3. Zestaw dokumentów operacyjnych dostarczonych do klienta i użytkowników w celu zapewnienia cyklu życia i użytkowania określonej wersji produktu oprogramowania w oparciu o zaadaptowane standardy ISO 9294, ISO 15910, ISO 18019.
4. Narzędzia dokumentacji i automatyzacji do projektowania, rozwoju, modyfikacji, kontroli i testowania wykorzystywane w celu zapewnienia cyklu życia oprogramowania.
5. Plany i metody testowania aplikacji i oceny efektywności procesów systemu jakości przedsiębiorstwa i oprogramowania.
6. Metody konserwacji, identyfikacja komponentów i dokumentacji produktów oprogramowania, analiza i zatwierdzanie wersji oprogramowania i kompleksów danych.
7. Metodyka zarządzania konfiguracją, zatwierdzania, przechowywania, zabezpieczania, kopiowania wersji oprogramowania i dokumentów towarzyszących oraz gromadzenia i przechowywania danych o cechach jakościowych zarejestrowanych w archiwum przedsiębiorstwa w trakcie cyklu życia wersji oprogramowania produkt.

Powstałe dokumenty testowe - certyfikacja systemu jakości przedsiębiorstwa i / lub oprogramowania

1. Raport o dostępności, trafności i systematyczności dokumentacji, dostosowany do wymagań i zapisów systemu jakości przedsiębiorstwa, który zapewnia zintegrowany proces zapewnienia jakości w całym cyklu życia oprogramowania.
2. Wyniki monitoringu i badania stanu oraz stosowania systemu jakości prowadzonego okresowo w celu określenia jego przydatności i skuteczności.
3. Raport o dostępności i utrzymaniu procedur kontrolnych oraz udokumentowane raporty o wynikach osiągniętej jakości spełniania wymagań umowy certyfikacyjnej z klientem.
4. Wyniki rejestracji uzyskanych cech jakościowych pakietu oprogramowania: identyfikacja, gromadzenie, przechowywanie zarejestrowanych danych dotyczących cech i atrybutów jakości produktu oprogramowania i jego komponentów.
5. Wyniki realizacji planu rozwoju, udokumentowane dane wejściowe i wyjściowe etapów rozwoju oraz protokoły weryfikacji realizacji cyklu życia oprogramowania.
6. Wyniki praktycznej realizacji programu jakości oraz realizacji uregulowanych działań w zakresie jakości na wszystkich etapach cyklu życia PS.
7. Wyniki certyfikacji symulatorów środowiskowych i generatorów testów oraz ocena ich wystarczalności do wykonywania testów certyfikacyjnych oprogramowania.
8. Wyniki analizy realizacji planów i metod testowych, raporty z testów, oceny zgodności wyników testów z wymaganiami, a także wyniki testów zatwierdzone przez przedstawicieli wnioskodawcy, klienta i dostawcy.
9. Akt wyników kontroli rzeczywistych cech cyklu życia oprogramowania i systemu jakości przedsiębiorstwa, wnioski dotyczące ich zgodności z wymaganiami certyfikacji produkcji oprogramowania.
10. Certyfikat systemu jakości przedsiębiorstwa i/lub oprogramowania i zapewnienia jego cyklu życia, licencja na stosowanie znaków zgodności.

Literatura

W.W. Lipajew - Profile standardów cyklu życia oprogramowania. -- Informacje o Jet, Biuletyn, N 12, 2005

K. Milman, S. Milman - СММI - krok w przyszłość. -- Systemy otwarte., N 5-6 (2005), N2 (2006), 2005, 2006

Ocena i poświadczenie dojrzałości procesów tworzenia i utrzymania oprogramowania i systemów informatycznych ISO IEC TR 15504-CMMI. Za. z angielskiego -- M.: Książka i biznes, 2001

W.W. Lipajew - Procesy i standardy cyklu życia złożonego oprogramowania. Informator.- M.: SINTEG, 2006

W.W. Lipajew - Techniki zapewniania jakości oprogramowania na dużą skalę.- M.: RFBR. SYNTEGA, 2003

"; antisource:" Produkty programowe są obecnie wykorzystywane do rozwiązywania problemów zarządzania w prawie wszystkich sferach ludzkiej działalności: w gospodarce, społecznej, wojskowej i innych. Zapewnienie wysokiej jakości rodzimych produktów software'owych podczas ich masowego rozwoju i dostarczania do różnych zastosowań w kraju i na rynku światowym stało się zadaniem strategicznym."; Warunek: 1] $