Wstęp

Najważniejszą częścią nowoczesnych złożonych systemów są produkty programistyczne - składnik intelektualny. Produkty software'owe są obecnie wykorzystywane do rozwiązywania problemów zarządczych w niemal wszystkich obszarach działalności człowieka: w gospodarce, społecznej, wojskowej i innych. Bezpieczeństwo Wysoka jakość krajowe oprogramowanie z ich masowy rozwój i dostawy do różnych zastosowań w kraju i na rynku światowym stały się celem strategicznym.

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ędzynarodowej Organizacji Normalizacyjnej) i modelami dojrzałości SEI (US Software Engineering Institute). Pierwsze są 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 odniesienia.

Poprawę wskaźników techniczno-ekonomicznych oraz jakości oprogramowania, a także zapobieganie błędom i usterkom zapewnia zastosowanie nowoczesne technologie inżynieria oprogramowania i systemy projektowanie wspomagane komputerowo,. Są to wysokowydajne, oszczędzające zasoby technologie do tworzenia kompleksów oprogramowania 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 należy przede wszystkim zastosować metody i narzędzia do analizy i projektowania, zapewniające od początku konkretyzację i jak najdokładniejsze odwzorowanie celów, celów i funkcji. koło życia(LC) PS i zapobieganie rozprzestrzenianiu się ewentualnych wad systemu na kolejne etapy rozwoju. Takie technologie inżynierii oprogramowania umożliwiają wyeliminowanie lub znaczne zmniejszenie poziomu błędów systemowych, algorytmicznych i programowych w produktach programowych przekazywanych do eksploatacji. Ponadto są skuteczne w modyfikowaniu i utrzymywaniu PS, a także w zmianach w środowisku zewnętrznym.

Aby poświadczyć jakość, niezawodność i bezpieczeństwo użytkowania złożonych, krytycznych systemów, stosowane w nich oprogramowanie poddawane jest orzecznictwo certyfikowane, zorientowane na problem centra testowe lub laboratoria. Takie testy powinny być przeprowadzane, gdy programy zarządzają złożonymi, krytycznymi procesami lub informacjami procesowymi tak ważnymi, że ich defekty lub niewystarczająca jakość mogą spowodować znaczne szkody. Testy certyfikacyjne powinny ustalać zgodność kompleksów oprogramowania z wymaganiami dokumentacji i umożliwiać im działanie w granicach zmian parametrów środowiska zewnętrznego badanego podczas testów. Tego typu testy charakteryzują się największą surowością i głębokością kontroli i powinny być wykonywane przez specjalistów niezależnych od deweloperów i klientów (użytkowników).

Podstawą certyfikacji powinny być szczegółowe i skuteczne programy i metody testowania pakietó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. Zastosowanie w przedsiębiorstwach-twórcach oprogramowania, certyfikowanych systemów jakości dla zapewnienia cyklu życia PS w oparciu o wymagania 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. W związku z tym klienci złożonych projektów informatycznych wybierają wykonawców wdrożeniowych, którzy posiadają certyfikaty poświadczają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ą szerokie pole dowolności specjalistów w ocenie jakości ich pracy, a także pojawianiu się licznych defektów i błędów w projektach programistycznych. Rosnąca złożoność i odpowiedzialność nowoczesnych zadań rozwiązywanych przez programy, a także możliwe szkody wynikające z niewystarczającej jakości ich wyników, znacznie zwiększyły znaczenie opanowania metod pełnego, znormalizowanego opisu wymagań dotyczących cech jakościowych i metod pomiaru ich realne, osiągane wartości na różnych etapach cyklu życia oprogramowania. Zdecydowanie wzrosła potrzeba znajomości przez specjalistów pojęć, definicji i metod oceny cech jakości 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 deweloperów zawarte w umowach dotyczące dostarczania wysokiej jakości oprogramowania w uzgodnionych ramach czasowych często nie są dotrzymywane. Często dzieje się tak dlatego, ż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 potrzebnych 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 z zakresu 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 - wykonaniem procesów projektowych do opanowania, 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 stosowania złożonych pakietów oprogramowania 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. Znacząca uwaga w CMMI zajmuje się procesami rozwoju i rozliczaniem iteracji przy zmianie wymagań klienta, ich identyfikowalności z funkcjami, komponentami, testami i dokumentami projektowymi. Ostatnio pojawiły się informacje o modernizacji wersji SEI do wersji 2003. CMMI-1.1 na podstawie zgromadzonych doświadczeń i informacji zwrotnych od przedsiębiorstw. W 2006 roku ma wypuścić nową, znacznie ulepszoną wersję 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 korporacyjnej w zakresie inżynierii oprogramowania. Okres ważności certyfikatu będzie ograniczony 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 zaprojektowany, aby zapewnić ciągły ocena kompleksu procesów w pewien obszar tworzenie oprogramowania lub fazowe ocena i poprawa dojrzałości przedsiębiorstwa, a także organizacja cyklu życia kompleksów programowych w ogóle. Modele CMMI pomagamy specjalistom w organizacji i doskonaleniu ich produktów, a także w usprawnianiu i obsłudze procesów rozwoju i utrzymania PS. Koncepcja tych modeli obejmuje zarządzanie i ocenę dojrzałości złożonych systemów, inżynierię oprogramowania, a także procesy tworzenia zintegrowanych produktów oprogramowania i doskonalenia ich rozwoju. Komponenty modeli ciągłych i fazowych 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;
• 1 sekcja - wprowadzenie;
• Sekcja 2 - model komponentowy;
• 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 w sekcji 7 są opisane, ich ogólny przegląd i schematy interakcji procesów CMMI:
  • 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 zastosowania modelu i szkolenia; zauważono zgodność i zgodność procesów modelowych 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 całego dokumentu, czyli 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(ciągły) model odzwierciedla 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, ciągła reprezentacja (CMMI-SE/SW/IPPD, V1.1, ciągły). Zintegrowana inżynieria systemów/inżynieria oprogramowania/zintegrowane produkty i model oceny dojrzałości procesu rozwoju — ciągły widok. 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 ekspansji;
• zarządzanie projektem:
  • 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 (atest, aprobata);
• Pomoc:
  • Zarządzanie konfiguracją;
  • analiza i podejmowanie decyzji dotyczących zmian;
  • analiza przyczyn źródłowych i rozwiązywanie problemów (eliminacja defektów).

Pięć załączników zawiera:

ALE- skład wykorzystanych źródeł literackich i dokumentów, który jednak nie wymienia norm ISO;

W- skróty;

Z- terminologia oparta na glosariuszu ISO stosowany 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 skupia się na procesach organizacyjnych, na planowaniu, zarządzaniu i kontrolowaniu procesów wdrażania projektów oprogramowania, na opracowywaniu i zarządzaniu wymaganiami dla produktów oprogramowania. Poniżej znajdują się przykłady szczegółów w CMMI niektórzy z nich.

Planowanie w tym jak iw drugim modelu obejmuje:

• ocena możliwego rozmiaru (skala) oprogramowania;
• ocena złożoności funkcji i cech projektu PS;
• definicja modelu i etapów cyklu życia pakietu oprogramowania;
• studium wykonalności projektu – określenie kosztów, pracochłonności i czasu trwania cyklu życia podstacji;
• opracowanie podzielonego na etapy harmonogramu prac i budżetu projektu;
• analiza, identyfikacja i ocena ryzyk projektowych;
• planowanie i zarządzanie dokumentacją procesów i produktów 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 dla etapów cyklu życia przez dewelopera z klientem projektu PS;
• udokumentowanie planu pracy i jego zatwierdzenie przez kierownika projektu.

Procesy opracowywania 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ń projektu pakietu oprogramowania;
• dekompozycja podstawowych wymagań początkowych dla funkcji PS 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 oba modele obejmują:

• uzyskanie jednoznacznego zrozumienia wymagań dotyczących projektu PS przez klienta i programistów;
• uzyskanie przez klienta od twórców zobowiązań do spełnienia wszystkich jego wymagań dotyczących oprogramowania;
• zarządzanie zmianami wymagań dla projektu PS uzgodnionymi pomiędzy klientem a deweloperem;
• zapewnienie poprawności zmian z wymagań ogólnych dla projektu PS na wymagania dla komponentów i poszczególnych procesów;
• identyfikacja i identyfikacja rozbieżności mię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). Zintegrowana inżynieria systemów/inżynieria oprogramowania/zintegrowane produkty i model oceny dojrzałości procesu rozwoju — stopniowe wprowadzenie. 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 zalecane do ograniczenia cztery główne poziomy:

• drugi poziom- formalizuje podstawowe zarządzanie projektowanie:
  • zarządzanie wymaganiami;
  • planowanie;
  • monitorowanie i kontrola projektu;
  • 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 reprezentacji 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 udostępnianie zasobów;
  • 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ę aplikowanie na każdym wyższym poziomie dojrzałości wszystkie procesy poprzednie niższe poziomy. W obu wersjach modelu każdy z wyróżnionych powyżej podstawowych procesów jest skomentowany szczegółowymi zaleceniami jego praktycznej realizacji, zawierającymi opisy około 20–30 stron ujednoliconych w strukturze:

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

Rekomendacje te pod względem zakresu, treści i kompletności opisów podstawowych procesów są zbliżone do szeregu standardów dla Profilu Cyklu Życia PS przedstawionych w. Porządkowanie i ocena kompletności wykorzystywanych procesów zgodnie z poziomami dojrzałości, pozwala na ustalenie potencjału produkcyjnego przedsiębiorstw – twórców oprogramowania pod kątem przewidywanej jakości procesów i wyników ich działań oraz gotowości do certyfikacji na zgodność z określonym poziomem dojrzałości modelu CMMI - 1.1.

Nacisk na modele CMMI podlega procesom zarządzania projektem PS. Te wymagania i procesy modeli praktycznie odpowiadają uregulowanym i szczegółowym zaleceniom zawartym w normach. ISO 9001:2000 oraz główne elementy profilu złożonych standardów cyklu życia PS [ , ]. Wymagania dla procesów w sekcjach funkcjonalnych 4-8 norm ISO 9001, ISO 9004, ISO 90003 w modelu można porównać szereg sekcji adekwatnych do treści CMMI(na rys. 1 strefa nakładania się treści). 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 i modeli dojrzałości

Z punktu widzenia wspierania i regulowania pełnego cyklu życia dużych projektów oprogramowania, niedociągnięcia modeli CMMI dotyczące profilu istniejących norm ISO może obejmować:

W 1998 r. opracowano i zatwierdzono obszerny raport techniczny w celu określenia poziomów dojrzałości przedstawionych powyżej procesów zapewniających cykl życia PS. ISO 15504, składający się z dziewięciu części i wielu zastosowań. Przedstawia model dojrzałości WMP i osiem podstawowe zasady inżynieria oprogramowania w oparciu o standard ISO 9000:2000. Następnie w ISO dokument ten przeszedł radykalną rewizję, redukcję, uproszczenie struktury i treści, przy pełnym zachowaniu celów i koncepcji oraz zatwierdzony standardowo w pięciu częściach.

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

• ustanowić własne państwo procesy technologiczne i ich doskonalenie;
• określić przydatność własnych procesów do spełnienia określonych wymagań lub klas wymagań klienta;
• pod kątem przydatności do wykonania niektóre traktaty z klientami PS i systemów.

Standard przyczynia się do: samooceny dojrzałości przedsiębiorstw, zapewnienia odpowiedniego zarządzania atestowanymi procesami, określenia profilu ocen procesów, a także pasuje do dowolnego zakresu i wielkości systemów operacyjnych i systemów. Stosowanie standardu ma na celu rozwój przedsiębiorstw i specjalistów kultura dojrzałości technologicznej ciągłego doskonalenia zapewnienie cyklu życia PS zgodnego z celami biznesowymi projektów oraz optymalizacja wykorzystania dostępnych zasobów. Ocena dojrzałości procesów przedsiębiorstwa daje możliwość ich porównania i wyboru, 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: możliwość 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 maturalnych: ramy prowadzenia i doskonalenia procesów oceniania.

Zatwierdzenie w normie zajmuje się w dwa aspekty: usprawnienie procesów cyklu życia PS i systemów konkretnego przedsiębiorstwa oraz ustalenie, czy deklarowana dojrzałość procesów wsparcia projektu lub przedsiębiorstwa odpowiada faktycznie stosowanym procesom. Znajduje to odzwierciedlenie w kolejnych pięciu częściach standardu. ISO 15504:1-5:2003-2006.

Część 1 - Pojęcie i słownictwo. Zawiera ogólne informacje o procesach certyfikacji dojrzałości oprogramowania i systemów oraz zalecenia dotyczące stosowania części normy. Przedstawione Ogólne wymagania dla certyfikacji, terminologii, struktury określa się zakres pozostałych części normy.

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

Część 3 - Wytyczne dotyczące produkcji certyfikacji. Zawiera przegląd technologii wykonywania procesów oceny dojrzałości i interpretacji implementacji wymagań. Odzwierciedla: wykonanie certyfikacji; narzędzia pomiarowe do określania procesów dojrzałości; wybór i zastosowanie narzędzi certyfikacyjnych; ocena kompetencji certyfikujących; weryfikacja zgodności atestacji z deklarowanymi wymaganiami. Narzędzia walidacji mogą być wykorzystywane przez przedsiębiorstwa w planowaniu, zarządzaniu, monitorowaniu, kontrolowaniu i ulepszaniu produktów i systemów oprogramowania, w ich nabywaniu, rozwijaniu, stosowaniu i utrzymaniu.

Część 4 – Wskazówki dla użytkownika dotyczące doskonalenia i dojrzałości procesu w tych dwóch aspektach. Zalecanych jest kilka kroków, które obejmują: zastosowanie wyników procesów walidacji; wyznaczanie celów oceny dojrzałości; określenie danych początkowych do certyfikacji; 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 kwalifikacyjnej z wymaganiami.

Część 5 - Przykładowy model procesów atestacji na zgodność z wymaganiami przedstawionymi w Części 2. Obszerny dokument (162 strony) zawiera praktyczne przykłady poprzednich części standardu dotyczące organizacji, oceny i doskonalenia oceny dojrzałości procesu cyklu życia dla różnych obszarów aplikacji, projektów oprogramowania i przedsiębiorstw.

W praktycznej realizacji projektów i zapewnieniu cyklu życia złożonego oprogramowania, czasami deweloperom i dostawcom trudno jest zidentyfikować i uwypuklić zalety modeli do zastosowania. CMMI. W zależności od tradycji przedsiębiorstwa i specyfiki dużego projektu często zaleca się stosowanie PS jako głównego pełnego profil standardówISO i do oceny klienta poziom dojrzałości obsługa zarządcza, organizacyjna i technologiczna projektów PS stosować określone zalecenia CMMI. Te wytyczne mogą być skutecznie wykorzystywane w: certyfikacja jakości procesu w przedsiębiorstwach zapewniających cykl życia PS, jako alternatywa lub wraz z certyfikacją według zbioru standardów zarządzania ISO 9000, w zależności od specyfiki projektu i wymagań wnioskodawcy o certyfikację 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 uregulowane procedury i dokumenty i muszą być realizowane przez wykwalifikowanych, certyfikowanych ekspertów - inspektorów. Za certyfikację przedsiębiorstwa-dewelopera 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 cyklu życia PS. Wymienione poniżej procesy i dokumenty są przeznaczone dla dużych projektów i mogą zostać zredukowane w drodze porozumienia między programistami, klientami i jednostkami certyfikującymi w prostszych przypadkach.

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 stosowności akredytacji. Jeżeli wyniki badań są pozytywne, sporządzane i wydawane jest świadectwo akredytacji.

Przepisy dotyczące jednostki certyfikującej lub laboratorium jest głównym dokumentem ustalającym przedmiot akredytacji, status prawny, funkcje, strukturę, prawa i obowiązki, metody, środki i organizację badań. Paszport laboratorium certyfikującego (ośrodka) musi zawierać informacje o sprzęcie Informatyka niezbędne do testowania, na personel i personel, sprzęt z narzędziami testowymi, dostarczenie dokumentów regulacyjnych, technicznych i metodologicznych, a także innych zasobów niezbędnych do testowania.

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

• polityka w zakresie zapewnienia jakości testów i badań;
• wyposażenie centrum w odpowiednie 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ę wyrobów lub procesów podlegających certyfikacji przesyła do jednostki certyfikującej wniosek w formie przyjętej w systemie certyfikacji. Jednostka certyfikująca prowadzi prace nad przygotowaniem i organizacją certyfikacji wyrobów na wniosek. Ta praca obejmuje:

• wybór schematu certyfikacji uwzględniającego specyfikę produktów (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 identyfikacja akredytowanego laboratorium badawczego do przeprowadzenia badań;
• przygotowanie projektu umowy o wykonanie pracy.

Część przygotowawcza prac nad certyfikacją 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ę selekcję i badanie aktualnych dokumentów regulacyjnych dla produktów zgłoszonych do certyfikacji, metody 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 w celu zapewnienia procesów weryfikacji. Może przedłożyć jednostce certyfikującej raporty z badań przeprowadzonych podczas opracowywania i produkcji wyrobów, dokumenty z badań przeprowadzonych przez zewnętrzne laboratoria badawcze oraz inne dokumenty wskazujące na zgodność technologii lub wyrobów z ustalonymi wymaganiami. Na podstawie przedstawionej wraz z wnioskiem analizy udokumentowanych dowodów zgodności 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. Jeżeli nie jest możliwe przeprowadzenie badań w placówce badawczej laboratorium akredytowanego, badania mogą być wykonywane przez personel tego laboratorium u producenta lub konsumenta tego produktu przy użyciu własnych urządzeń laboratorium badawczego lub pomieszczeń 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ę) organu kompetentnego w tym zakresie oraz certyfikowanego laboratorium do wykonywania badań certyfikacyjnych;
• złożenie przez wnioskodawcę wniosku o przeprowadzenie badań do jednostki certyfikującej i przyjęcie przez osoby certyfikujące decyzji w sprawie wniosku, wybór programu certyfikacji, zawarcie umowy o certyfikację;
• identyfikacja wymagań dotyczących systemu jakości przedsiębiorstwa i/lub wersji oprogramowania, które ma być testowane;
• przeprowadzanie testów certyfikacyjnych systemu jakości przedsiębiorstwa lub wersji oprogramowania przez laboratorium certyfikujące;
• analiza uzyskanych wyników i decyzja laboratorium i/lub jednostki certyfikującej o możliwości wydania wnioskodawcy certyfikatu zgodności;
• wydanie przez jednostkę certyfikującą wnioskodawcy certyfikatu i licencji na używanie znaku zgodności i wydawanie certyfikowanych produktów - wersje oprogramowania;
• wdrożenie kontroli inspekcji przez jednostkę certyfikującą certyfikowanego systemu jakości przedsiębiorstwa i / lub produktów;
• przeprowadzenie przez wnioskodawcę działań naprawczych w przypadku naruszenia zgodności procesów systemu jakości i / lub produktów z ustalonymi wymaganiami oraz w przypadku nieprawidłowego zastosowania znaku zgodności.

Sprawdzając odpowiedzialność kierownictwa dewelopera za jakość produktu, należy ustalić, czy przedsiębiorstwo lub projekt posiada udokumentowaną politykę jakości, cele i zobowiązania, a także stopień, w jakim ta polityka jest zrozumiała, wdrożona i utrzymywana w stanie roboczym w wszystkie poziomy 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. Dostępność wymagań, procedur, narzędzi i przeszkolonego personelu do praktycznej realizacji procesów systemu jakości, a także aktualność i systematyczna dokumentacja wszystkich elementów, wymagań i postanowień systemu jakości, który jest procesem zintegrowanym przez całe życie cykl PS, należy sprawdzić. 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;
• istnienie 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 specjaliści laboratorium badawczego powinni przeprowadzić badanie stopnia faktycznego stosowania systemu jakości, w przedsiębiorstwie. Testowanie rozpoczyna się od opracowania programu testowania systemu jakości, który powinien służyć jako plan pracy dla dalszej pracy. Program jest wewnętrznym dokumentem roboczym laboratorium badawczego i powinien zawierać wykaz prac, uszczegółowiony zgodnie ze specyfiką przedsiębiorstwa deweloperskiego wraz z analizą kompletności i jakości przedłożonych dokumentów źródłowych oraz stopnia ich praktycznego zastosowania w projektowaniu, rozwoju i dostarczaniu 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 obecności specjalistów-opracowników odpowiednich dokumentów w miejscu pracy oraz kompletności stosowania ich przepisów i zaleceń. Przeglądy stanu projektu i audyty wewnętrzne systemu jakości, procesów i/lub wyrobów powinny być przeprowadzane przez personel niezależny od osób bezpośrednio odpowiedzialnych za realizację tych prac.

Metody sprawdzania jakości rozwoju powinien być dostarczony niezbędne zasoby do realizacji programu testów, metod planowania i opracowania prywatnych procedur testowych. Metody powinny zawierać: przedmioty i cele testowania; oceniane wskaźniki jakości; warunki i procedura testowania; metody przetwarzania, analizy i oceny wyników badań; pomoc techniczna testowanie i raportowanie. Należy wskazać sprzęt i oprogramowanie używane podczas testów oraz procedurę testową, a także oczekiwane wyniki kontroli. Należy opracować metody kontroli poprawek, działań mających na celu naprawienie defektów, jeśli takie żądanie otrzyma służba zarządzania audytem. Służba zarządzania programem testów powinna ustanowić procedury zachowania poufności wszelkich informacji o testach, jak również danych posiadanych przez osoby oceniające.

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

Wnioski dotyczące wyników testów certyfikacyjnych jest opracowywany przez osoby certyfikujące i zawiera uogólnione informacje o wynikach badań i uzasadnieniu wydania certyfikatu. W przypadku uzyskania negatywnych wyników badań certyfikacyjnych podejmuje się decyzję o odmowie wydania certyfikatu zgodności. Po zakończeniu certyfikowanego produktu lub systemu jakości testy można powtórzyć. Wyniki analizy stanu technologii lub jakości produktu są sporządzane przez ustawę, który zawiera szacunki dla wszystkich pozycji Programu Testowego i zawiera wnioski, w tym ogólną ocenę stanu produkcji i produktów, potrzebę 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 inspekcji, a także do opracowania środków naprawczych.

Na podstawie wyników badań certyfikacyjnych i badania dokumentacji podejmowana jest decyzja o wydaniu certyfikatu. W przypadku uzyskania negatywnych wyników badań certyfikacyjnych podejmuje się decyzję o: odmowa wydania zaświadczenia zgodność. Ponadto do wnioskodawcy mogą zostać przesłane propozycje usunięcia rzekomych przyczyn negatywnych wyników badań, po zakończeniu certyfikowanych wyrobów badania mogą być powtórzone.

Jednostka certyfikująca po przeanalizowaniu raportów z badań, ocenie produkcji, certyfikacji systemu jakości, przeanalizowaniu dokumentacji określonej w decyzji w sprawie wniosku, ocenia zgodność wyrobów z ustalonymi wymaganiami, sporządza certyfikat na podstawie opinii ekspertów i rejestruje go. Dokonując zmian w projekcie lub dokumentacji operacyjnej, które mogą mieć wpływ na jakość systemu lub oprogramowania certyfikowanego podczas certyfikacji, wnioskodawca musi powiadomić o tym jednostkę certyfikującą w celu podjęcia decyzji 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 prowadzona jest w formie okresowej i niezaplanowane inspekcje zgodność z wymaganiami dotyczącymi jakości technologii i certyfikowanych produktó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 zakresu inspekcji brane są pod uwagę następujące czynniki: stopień potencjalnego zagrożenia produktu programowego, stabilność produkcji, wielkość wydania, dostępność i zastosowanie systemu jakości podczas opracowywania, informacje o wynikach badań wyrobu i jego produkcji przeprowadzonych przez producenta, państwowe organy kontroli i nadzoru.

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

• fundamentalne zmiany w modelu dojrzałości, profilu standardów, 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 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ąć wykryte przyczyny niezgodności i potwierdzić, bez ponownego badania w akredytowanym laboratorium zgodności produktu lub procesów z dokumentami normatywnymi. Jeżeli 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 przez jednostkę certyfikującą, która go wydała, wnioskodawcy, konsumentom i innym zainteresowanym organizacjom. Ważność certyfikatu i prawo do oznaczania wyrobów znakiem zgodności może zostać odnowione, jeżeli przedsiębiorstwo deweloperskie spełni następujące warunki:

• identyfikacja przyczyn niezgodności i ich eliminacja;
• 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.

Dokumentacja procesów i wyników certyfikacji produktów 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 niezbędny zestaw dokumentów dla każdego przedsiębiorstwa lub projektu należy wybrać i dostosować w odniesieniu do tych cech. Wskaźnikami systemu jakości ocenianym podczas certyfikacji jest dostępność odpowiednich dokumentów oraz praktyczne spełnienie wymagań określonego poziomu modelu dojrzałości. SMMI lub dostosowany profil standardów oparty na ISO 9000:2000, a także tworzone na ich podstawie, opisy stanowisk pracy specjaliści przedsiębiorstwa-dewelopera. Wnioskodawca musi przygotować i przedłożyć laboratorium badawczemu zestaw dokumentów uzgodnionych między klientem a wykonawcą i zatwierdzonych w celu weryfikacji ich wiarygodności, wystarczalności składu i wykonania 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 opartych o ISO 9000:2000 lub modele dojrzałości SMMI, 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 dane 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 audytu (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 być redukowany i dostosowywany zgodnie z ustaleniami 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 oprogramowania

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 rozdziałów i zaleceń norm ISO 12207, ISO 15504, ich zmian oraz wytycznych stosowania, wyselekcjonowanych podczas adaptacji i obowiązkowych do stosowania w systemie jakości danego przedsiębiorstwa lub projektu oprogramowania.
3. Dostosowana wersja lub lista rozdziałów i zaleceń normy ISO 900003, wybrany w trakcie adaptacji i obowiązkowy do stosowania w systemie jakości przedsiębiorstwa produkującego oprogramowanie.
4. Podstawowe cechy i atrybuty jakościowe projektu PS, zidentyfikowane, dostosowane i określone na podstawie norm ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. Dostosowana wersja i zatwierdzona edycja podręcznika zarządzania utrzymaniem i konfiguracją w oparciu o zalecenia norm 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 zaangażowanego w procedury 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 tworzonych 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 przedsiębiorstwa-dewelopera w zakresie systemu jakości, kryteriów jakości procesów i produktów wytwarzania, dostarczania i obsługi całego cyklu życia oprogramowania.
3. Zestaw dokumentów operacyjnych dostarczonych do klienta i użytkowników w celu zapewnienia cyklu życia i użytkowania określonej wersji oprogramowania w oparciu o zaadaptowane standardy ISO 9294, ISO 15910, ISO 18019.
4. Narzędzia do 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 utrzymania, identyfikacja komponentów i dokumentacji produktu oprogramowania, analiza i zatwierdzanie wersji oprogramowania i kompleksów danych.
7. Metodyka zarządzania konfiguracją, zatwierdzania, przechowywania, ochrony, kopiowania wersji oprogramowania i dokumentów towarzyszących, a także gromadzenia i przechowywania danych o cechach jakościowych zarejestrowanych w archiwum przedsiębiorstwa podczas cyklu życia wersji oprogramowania.

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

1. Raport o dostępności, trafności i systematycznym wykonywaniu dokumentacji dostosowanej 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, przeprowadzanego okresowo w celu określenia jego przydatności i skuteczności.
3. Raport o dostępności i utrzymaniu metod przeprowadzania przeglądów oraz udokumentowane raporty o wynikach osiągniętej jakości w spełnieniu 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 sprawdzania realizacji cyklu życia PS.
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 środowiska i generatorów testów oraz ocena ich wystarczalności do przeprowadzenia 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 weryfikacji rzeczywistych cech cyklu życia systemu 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 -- SMMI to krok w przyszłość. -- systemy otwarte., N 5-6.(2005), N2.(2006), 2005, 2006

Ocena i certyfikacja dojrzałości procesów tworzenia i utrzymania narzędzi programowych 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 -- Metody zapewnienia jakości oprogramowania wielkoskalowego.-- M.: RFBR. SINTEG, 2003

antisource: „Produkty programowe są obecnie wykorzystywane do rozwiązywania problemów zarządczych w niemal wszystkich obszarach działalności człowieka: 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]$

Adnotacja: Szczegółowo badany jest krąg idei leżących u podstaw prawdopodobnie najbardziej znanej metodologii doskonalenia procesów rozwojowych. oprogramowanie- SMM. Analizowana jest logika i struktura HMM. Pokazano związek między HMM a wcześniej badanymi modelami procesów.

Wspaniałe praktyczne narzędzie stworzone w ramach podejście procesowe do opisu działalności organizacja projektowa w szczególności organizacja, która się rozwija Systemy informacyjne , przedstawia metodologię HMM. 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 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 systemem kryteriów wyboru podwykonawców w projektach rozwoju oprogramowania. Prace zakończono w 1991 roku, a efektem była maszyna współrzędnościowa. Musimy natychmiast zastrzec, że model nie zawiera żadnych finansowych, ekonomicznych, politycznych, organizacyjnych Kryteria wyboru podwykonawcy, a także kryteria możliwości dopuszczenia do pracy tajnej (prawdopodobnie takie zadania nie zostały ustalone). Mówimy tylko o kryteriach, które opisują 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 poczynili pewne nietrywialne założenia, które następnie zostały zaakceptowane i uznane za sprawiedliwe przez wielu specjalistów IT (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 w celu zwiększenia swoich szans w walce o kontrakty Departamentu Obrony, ale także w celu własnego doskonalenia).

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, w tym samym czasie gwałtownie 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. SMM „Level Ladder” została szeroko zaakceptowana i rozpowszechniona. Oto jak ona wygląda.

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

Poziom 2 „Powtarzalny”. Ustanowiono główne procesy zarządzania projektami, pozwalające śledzić koszty, monitorować harmonogram prac oraz funkcjonalność tworzonego rozwiązania programowego. Ustalono dyscyplinę procesową niezbędną do odtworzenia wcześniejszych sukcesów w podobnych projektach tworzenia aplikacji.

Poziom 3 „Określony”. Proces produkcyjny jest udokumentowany i ustandaryzowany dla obu praca menedżerska jak również do projektowania. Proces ten jest zintegrowany ze standardowym procesem produkcyjnym organizacji. Wszystkie projekty wykorzystują zatwierdzoną, dostosowaną do potrzeb wersję standardowego procesu operacyjnego organizacji.

Poziom 4 „Zarządzany”. Zbierane są szczegółowe ilościowe wskaźniki procesu produkcyjnego i jakości tworzonego produktu. Zarówno proces produkcyjny, jak i produkty są oceniane i kontrolowane z ilościowego punktu widzenia.

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

Mimo braku rygoru 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 na wyższy poziom, a także dlaczego warto w ogóle o takie przejście dążyć. Jednocześnie model HMM nie zawiera żadnego ilościowego ani nawet formalnego uzasadnienia takiego podejścia, co jednak nie umniejsza jego meritum.

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

Ryż. 7.1.

Na ryc. 7.1 zawiera następujące pojęcia.

Grupa kluczowych procesów. Jak stwierdzono w (Paulk et al., 1995), „każda grupa procesów kluczowych definiuje blok powiązanych ze sobą czynności, w wyniku którego osiągany jest zestaw celów, które są istotne dla zwiększenia produktywności procesu produkcyjnego. przykład dla grupy kluczowych procesów” Zarządzanie wymaganiami„(Patrz rysunek 7.2) celem jest uzgodnienie wymagań projektu rozwoju oprogramowania między klientem a deweloperem”.

W CMM nie ma indywidualnych procesów. Zamiast tego są prace indywidualne, zwane praktykami kluczowymi (patrz poniżej), połączone ze sobą wejściami i wyjściami i służące jako materiał źródłowy dla procesów budowlanych. CMM nie zawiera wytycznych dotyczących struktury procesów, tj. łączenia kluczowych praktyk w logiczne sekwencje. Zestawy praktyk kluczowych nazywane są grupami procesów kluczowych.

Ryż. 7.2.

Grupy kluczowych procesów w CMM są mapowane do poziomów dojrzałości (rysunek 7.2), tj. wszystkie praktyki na poziomie oddziałują tylko ze sobą i nie wchodzą w interakcję z praktykami na innych poziomach. Pozwala 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” oznacza, że ​​istnieją grupy procesów(tj. zestawy praktyk), które nie są kluczowe z punktu widzenia określonego poziomu dojrzałości, tj. nie są związane z osiągnięciem celów tego poziomu (patrz poniżej). Model HMM nie opisuje wszystkiego grupy procesów związanych z rozwojem i utrzymaniem oprogramowania . Opisuje tylko te grupy, które zostały zidentyfikowane jako kluczowe determinanty produktywności procesu produkcyjnego.

Cele. Cele w CMM 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 wdrożeniu kluczowych praktyk, uzyskuje się pożądany rezultat, a po drugie, uzyskuje się go dość konsekwentnie. Sposób, w jaki cele Grupy Procesów Kluczowych są osiągane, może różnić się w zależności od projektu ze względu na różnice 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, który jest skorelowany z tą grupą procesów kluczowych.

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ą realizowane i w jakim stopniu są zalegalizowane w organizacji, tj. oficjalnie zatwierdzone i skoordynowane z procedurami, politykami i innymi procesami korporacyjnymi. Oto pięć sekcji.

Obowiązki wykonania

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

Warunki wstępne

Opisać warunki wstępne, które muszą być spełnione w projekcie lub organizacji w celu właściwego wdrożenia procesu produkcyjnego; zazwyczaj dotyczą zasobów, struktur organizacyjnych i wymaganych szkoleń.

Operacje w toku

Sekcja Operacje w toku opisuje prace merytoryczne, które należy wykonać na tym poziomie. Wykonywane operacje zazwyczaj obejmują tworzenie planów i wdrażanie określonych operacji, wykonywanie i śledzenie prac oraz podejmowanie działań naprawczych w razie potrzeby.

Pomiary i analizy

Sekcja „Pomiary i

„Każda grupa procesów kluczowych jest wyrażona przez praktyki kluczowe, których realizacja przyczynia się do osiągnięcia celów grupy. Praktyki kluczowe opisują infrastrukturę i operacje, które najbardziej przyczyniają się do efektywnego wdrożenia i ustanowienia grupy procesów kluczowych.

Każda kluczowa praktyka składa się z jednego zdania, po którym często następuje bardziej szczegółowy opis, który może zawierać przykłady i wyjaśnienia. Kluczowe praktyki, czasami określane jako kluczowe praktyki najwyższego poziomu, określają podstawowe zasady, procedury i operacje dla grupy kluczowych procesów. Elementy szczegółowego opisu są często określane jako podpraktyki."

Kluczowe praktyki opisują CO należy zrobić, ale nie należy ich traktować jako dogmat o tym, JAK należy osiągnąć cele. Cele grupy procesów kluczowych 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 czynności zarządzania IT, w których zamiast procesów brane są pod uwagę ich komponenty – kluczowe praktyki, a procesy są obecne tylko wirtualnie, jako 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 przez wprowadzenie gotowych procesów z referencyjnego modelu procesów. Teraz istnieje zestaw poziomów zawierających odmienne (tj. niezintegrowane z procesami) kluczowe praktyki oraz zalecaną kolejność poruszania się po poziomach. Zarządzanie IT, według CMM, poprawia się wraz z przejściem na wyższy poziom dojrzałości. Co dzieje się z tą promocją?

W definicjach poziomów (patrz Rysunek 7.2) pojawiło się coś takiego jak „proces produkcyjny”. Występuje również w definicji grupy kluczowych procesów i nie jest to przypadek. Proces produkcyjny lub, jak to trafnie nazywa się w CMM, Standard Proces produkcji Organizacje (OSS) to jedna z głównych koncepcji całego modelu.

W listopadzie 1986 roku Amerykański Instytut Inżynierii Oprogramowania (SEI), we współpracy z Miter Corporation, rozpoczął opracowywanie badania dojrzałości procesu tworzenia oprogramowania, które miało pomóc usprawnić ich wewnętrzne procesy.

Opracowanie tego przeglądu 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 z opóźnieniem i przekroczeniem budżetu. Trzeba było znaleźć rozwiązanie tego problemu.

We wrześniu 1987 roku firma SEI wydała krótka recenzja procesy wytwarzania oprogramowania wraz z opisem ich poziomów dojrzałości, a także kwestionariusz przeznaczony do identyfikacji obszarów w firmie, w których potrzebne były usprawnienia. Jednak większość firm uznała ten kwestionariusz za gotowy model, w wyniku czego po 4 latach kwestionariusz został przekształcony w rzeczywisty model, Capability Maturity Model for Software (CMM). Pierwsza wersja CMM (wersja 1.0), wydana w 1991 r., została zrewidowana w 1992 r. przez uczestników spotkania roboczego, w którym wzięło udział około 200 specjalistów od oprogramowania oraz członków społeczności programistów.

1. Podstawowy. Najbardziej prymitywny status organizacji. Organizacja jest zdolna do tworzenia oprogramowania. Organizacja nie ma jednoznacznie świadomego procesu, a jakość produktu jest całkowicie zdeterminowana indywidualnymi możliwościami programistów. Jeden przejmuje inicjatywę, a zespół postępuje zgodnie z jego instrukcjami. Sukces jednego projektu nie gwarantuje sukcesu innego. Po zakończeniu projektu dane dotyczące kosztów pracy, harmonogramu i jakości nie są rejestrowane.
2. powtarzalne. W pewnym stopniu proces jest monitorowany. Prowadzone są ewidencje kosztów pracy i planów. Funkcjonalność każdego projektu jest opisana na piśmie. W połowie 1999 roku tylko 20% organizacji miało poziom 2 lub wyższy.
3. Zainstalowany. Mieć zdefiniowany, udokumentowany i ustalony proces praca niezależna od jednostek. To znaczy, zgodziłem się profesjonalne standardy, a programiści je zaimplementują. Takie organizacje są w stanie dość rzetelnie przewidzieć koszty projektów podobnych do wcześniej zrealizowanych.
4. Zarządzany. Potrafią dokładnie przewidzieć terminy i koszty pracy. Dostępna jest baza danych skumulowanych pomiarów. Ale nie ma zmian wraz z pojawieniem się nowych technologii i paradygmatów.
5. Zoptymalizowany. Trwa procedura poszukiwania i opanowania nowych i ulepszonych metod i narzędzi.

Rozwój

Zastosowanie modelu w praktyce ujawniło niejednoznaczność w podejściach do osiągania wyższych poziomów organizacji procesów wytwarzania oprogramowania. Dlatego do 2002 roku opracowywane są zalecenia mające na celu usprawnienie procesu rozwoju, które nazywane są CMMI (Integracja modelu dojrzałości zdolności). W tej chwili Ostatnia wersja CMMi - 1.3 (opublikowany w listopadzie 2010 r.) .

Zobacz też

Spinki do mankietów

MIT Student Forum > Sekcja główna > Testy > Symulacja systemów sterowania

Pogląd pełna wersja: Symulacja systemów sterowania

Rozwiązałem wszystkie moduły, wszystko zdałem na 4, a ostatni na 2, teraz za trzy dni spróbuję zdać ponownie, nie było ani jednego identycznego pytania. Próbowałem poprawić test końcowy, ale sprawdź, za poprawność nie mogę ręczyć.Wyeksponuję wszystko co mam, może ktoś zda to lepiej ode mnie. Jeśli ktoś ma drugą, trzecią próbę, znoś, jeśli nie masz nic przeciwko, dyscyplinę, naprawdę bardzo trudno.:eek:

Test końcowy 100 na 100

Czy wynik jest za każdym razem inny?

Więcej pytań, które nie są tutaj wymienione i mnie przyłapały. Odpowiedzi nie szukałem, bo bez tego zdałem 4. Kto chce się pomylić, do końca wrzuć odpowiedzi 🙂

Moduł 1:
Czego nie należy uważać za cechę charakterystyczną procesu biznesowego?

Wartość dodana

Wybierz jedną odpowiedź:
Produkt procesu, który ucieleśnia wcześniej ustalone cele

Wybierz jedną odpowiedź:

W finale (przeszedł na 4.

Czym jest model dojrzałości zdolności? (WMP)

Te pytania + te już na forum):
1. Wybierz prawidłowe stwierdzenie.
Wybierz jedną odpowiedź:
Proces biznesowy oddziałów składa się z różnych łańcuchów wartości (NIE PEWNO)
Kompleksowy proces biznesowy składa się z procesów biznesowych różne organizacje
Wielofunkcyjny proces biznesowy z reguły składa się z procesów biznesowych działów

2. Co nie jest elementem uniwersalnego schematu przepływu procesów biznesowych?
Wybierz jedną lub więcej odpowiedzi:
Zasoby procesowe
Zagrożenia
Działania związane z zarządzaniem procesami biznesowymi
Czynniki środowiskowe
Aktywność polegająca na konwersji danych wejściowych na wyniki

3. Zasoby materialne jako podstawowy element procesów są:
Wybierz jedną odpowiedź:
Aktywne podmioty działalności zjednoczone w systemach współdziałających ze sobą i innymi zasobami
Działania kontrolne kierowane przez podmioty działania na przedmiotach działania, które określają cele i wyniki procesów
Obiekty i czynności pasywne wykorzystywane do realizacji procesów (NIE PEWNO)

28.03.2014, 10:07

Moduł 1:
Czego nie należy uważać za cechę charakterystyczną procesu biznesowego? Wybierz jedną lub więcej odpowiedzi:
Konwersja wejść na wyjścia
Dostawa produktu do konsumenta zewnętrznego
Wartość dodana
Formowanie wartości dodatkowej i/lub użytkowej

Wyniki jako podstawowe elementy procesów to:
Wybierz jedną odpowiedź:
Aktywne podmioty działalności zjednoczone w systemach współdziałających ze sobą i innymi zasobami
Produkt procesu, który uosabia wcześniej ustalone cele Pasywne udogodnienia i czynności wykorzystywane do realizacji procesów
Zbiór obiektów materialnych, energetycznych i informacyjnych niezbędnych do zakończenia procesu

Czym jest informacja zwrotna w procesie biznesowym?
Wybierz jedną odpowiedź:
Celowy i świadomy wpływ na proces, mający na celu zapewnienie pożądanego rezultatu
Analiza i porównanie wyników procesu z wcześniej ustalonymi celami
Wpływ na system obiektów i czynników środowiska, będących źródłem różnego rodzaju odchyleń w funkcjonowaniu systemu
Tak odpowiedziałem! ale i tak wyszło 4

W finale - te pytania + te, które już istnieją:
1 Wybierz z listy niedociągnięcia w projektowanych konstrukcjach docelowych.

2 Wybierz z listy przykłady użycia poleceń.
Kubki wysokiej jakości
Komisje
Zespoły robocze

3 Wybierz z listy warunki stosowania organicznych struktur organizacyjnych.
Pracownicy są motywowani złożonymi potrzebami
Cele są rozmyte i dynamicznie się zmieniają
Władza jest kwestionowana i testowana, wymaga potwierdzenia od podwładnych

4 Wybierz z listy zalety struktur organizacyjnych opartych na projektach.
uzyskuje się bezpośrednie podporządkowanie pracowników kierownikowi projektu, a tym samym jednoznaczność kierunku działań tych pracowników

5 Procesy wspierające:
Dostarczać skuteczne wdrożenie główne procesy

Ocena końcowa 5
Pytanie 1
Wybierz z listy przykładów użycia poleceń.

Kubki wysokiej jakości
Komisje
Zespoły robocze

pytanie 2
Do czego służą pośrednicy w strukturze funkcjonalnej?

Integracja działań różnych pionów strukturalnych

pytanie 3
Nazwij typy relacji w modelu SADT:
Kontrola
mechanizm wyjścia
Wejściowa informacja zwrotna

Pytanie 4
Który z poniższych procesów biznesowych jest najkrótszy?
Proces biznesowy dywizji

Pytanie 5
Jakie metody, metodologie i narzędzia można wykorzystać do tworzenia modeli informacji o procesach biznesowych?

Metodologia Geina-Sarsona
Język modelowania Chen i Barker

Pytanie 6
Która reprezentacja procesu biznesowego odpowiada najniższemu poziomowi (z wymienionych)?

Operacje procesów biznesowych

Pytanie 7
Długość procesu biznesowego:

To jest subiektywne

Pytanie 8
Zasoby materiałowe jako podstawowy element procesów to:

Pasywne środki i przedmioty działalności wykorzystywane do realizacji procesów

Pytanie 9
Wybierz z listy zalety struktur organizacyjnych opartych na projektach.

Wdrażane jest bezpośrednie podporządkowanie pracowników kierownikowi projektu, dzięki czemu uzyskuje się jednoznaczność kierunku działań tych pracowników

Pytanie 10
Wybierz z listy korzyści płynące z macierzowych struktur organizacyjnych.

Możliwość elastycznego dostosowania struktura organizacyjna w szerokim spektrum: od słabej do mocnej matrycy

Pytanie 11
Co obejmuje druga pętla zarządzania systemem biznesowym?

Podsystem kontroli pracy
podsystem zarządzania rozwojem

Pytanie 12
Ogólny model procesu systemu biznesowego obejmuje następujące elementy:

Wyjście
proces
Wejście
Niepokojenie

Pytanie 13
Który standard IDEF umożliwia modelowanie działań, przepływów i stanu obiektów?

Pytanie 14
Jakie są uprawnienia Project Managera w silnej strukturze macierzowej?

Średnia do wysokiej

Pytanie 15
Co można przypisać głównym elementom procesów inwestycyjnych i finansowych?

Inwestorzy
Kredytodawcy

Pytanie 16
Wybierz z listy niedociągnięcia w projektowanych konstrukcjach docelowych.

Zredukowana zdolność produkcyjna w obszarach funkcjonalnych

Modeling systemów sterowania.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Jaka jest kolejność dominacji na diagramach SADT?
Odpowiedź: Najbardziej dominujące funkcje znajdują się w lewym górnym rogu.

pomóż 3 w szkoleniu, kto to ma, pliz

Dodano po 1 minucie
Proszę o 3 szkolenia od każdego, kto ma Modelowanie systemów sterowania

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Tłumaczenie, które możesz powiedzieć:

Metodologia rozwoju SI. Model dojrzałości CMM/CMMI.

W 1991 r. Instytut Inżynierii Oprogramowania Uczelni

Carnegie Mellon (Instytut Inżynierii Oprogramowania, SEI) stworzył model dojrzałości CMM (Capability Maturity Model) do tworzenia oprogramowania. Z biegiem czasu wypuszczona została cała rodzina modeli:

SW-CMM - do oprogramowania, SE-CMM - do inżynierii systemów, Acquisition CMM - do zakupów, People CMM - do zarządzania zasobami ludzkimi, ICMM - do integracji produktów.

Różnorodność modeli okazała się dość trudna do zrozumienia i wdrożenia. Odkąd powstały różne grupy specjalistów, treść tych modeli nie zawsze była ze sobą spójna, jak również z

wymagania norm międzynarodowych. Dlatego w 2002 roku firma SEI opublikowała nowy model CMMI (Capability Maturity Model Integration), łączący wcześniej wydane modele i uwzględniający wymagania

międzynarodowe standardy. CMMI to zestaw modeli (metodologii) usprawniających procesy w organizacjach o różnej wielkości i działalności. CMMI wyróżnia następujące grupy obszarów doskonalenia: zarządzanie procesami, zarządzanie projektami, obszary inżynierskie, serwis

obszary. W tym przypadku wszystkie obszary są określone w postaci wymagań, które określają nie sposób ich realizacji, ale wymagania dotyczące interfejsu. Z tego wynikają dwie konsekwencje.

Konsekwencja 1. CMMI pozwala na różne implementacje i nie jest metodologią tworzenia oprogramowania jak MSF, Scrum, RUP itp. Te ostatnie można wykorzystać w jego implementacji. Na przykład w VSTS dla CMMI istnieje specjalny szablon procesu o nazwie MSF dla CMMI.

Wniosek 2. CMMI służy do certyfikacji firm pod kątem dojrzałości ich procesów. Początkowo, na przełomie lat 80. i 90., CMM (wtedy jeszcze nie CMMI) powstał właśnie jako środek certyfikacji

podwykonawcy federalni. Dopiero później, rozpowszechniwszy się na świecie, zaczęto go stosować, a następnie koncentrować na ulepszaniu procesów. Odnotowujemy jeszcze jeden ważna cecha CMMI. Przeznaczony jest nie tylko do tworzenia systemów oprogramowania. Wiele duże firmy produkują nie oprogramowanie, ale produkty docelowe, w których oprogramowanie stanowi integralną część.

Na przykład lotnictwo, przemysł lotniczy i kosmiczny. Czyli tworzenie oprogramowania

występuje wraz z pracami inżynierskimi innych typów. A często zdarza się, że w jednym projekcie zaangażowane są więcej niż dwa różne rodzaje inżynierii. Zadaniem CMMI jest udostępnienie takim projektom i firmom jednej platformy do organizacji procesu rozwoju.

W przeciwieństwie do klasycznego modelu CMM, który był ściśle hierarchiczny i pozwalał jedynie na sekwencyjne doskonalenie procesów według poziomów, model CMMI ma dwa wymiary – sekwencyjny, taki

tak samo jak w CMM, i ciągłym, pozwalającym w dowolnym stopniu na doskonalenie procesów w organizacji. Tutaj skupimy się na model sekwencyjny. Ma 5 poziomów

dojrzałość procesu (rys. 1).

Pierwszy poziom(poziom dojrzałości 1) to poziom, na którym z definicji znajduje się każda firma. Na tym poziomie tworzenie oprogramowania jest mniej lub bardziej chaotyczne.

Zarządzany poziom(poziom dojrzałości 2) - już tutaj pojawiają się polityki i procedury organizacji procesów zatwierdzone na poziomie firmy. Ale pełny zakres procesów istnieje tylko w ramach poszczególnych projektów.

Pewien poziom(poziom dojrzałości 3) – tutaj standardowy proces pojawia się na poziomie całej firmy jako całości.

Co to jest model dojrzałości zdolności (CMM)? Czym są poziomy CMM?

To duży i stale powiększający się zestaw zasobów procesowych: szablony dokumentów,

modele cyklu życia, narzędzia programowe, praktyki itp. Każdy konkretny proces uzyskuje się poprzez odcięcie się od tego standardu.

Poziom ilościowy(poziom dojrzałości 4) implikuje pojawienie się w firmie systemu miar, które odbywają się na podstawie standardowego procesu i umożliwiają ilościowe zarządzanie rozwojem.

Poziom optymalizacji(poziom dojrzałości 5) oznacza ciągłe doskonalenie procesów rozwojowych, zarówno przyrostowych, przyrostowych, jak i rewolucyjnych. Jednocześnie zmiany te nie są wymuszone, ale proaktywnymi problemami i trudnościami. Proces sam się doskonali i stale wdrażane są odpowiednie mechanizmy.

Wiele osób zna skrót CMMI, wiele osób wie, że jest to model, czyli zestaw rekomendacji, jak usprawnić procesy związane np. z tworzeniem oprogramowania. Ale niewiele osób wie, że istnieje kilka modeli CMMI. Najbardziej znanym z nich jest CMMI for Development (CMMI-DEV), który pod wieloma względami jest rzeczywiście powiązany z działalnością firm deweloperskich (czyli tych firm i organizacji, które opracowują i dostarczają określony produkt programowy lub inne złożone oprogramowanie i sprzęt). rozwiązanie).

Ale co z tymi, którzy dostarczają nie produkt, ale usługi (na przykład wsparcie produktu z nieznacznym udziałem rozwoju w całkowitych kosztach pracy lub w ogóle zerowe koszty pracy)? Dla nich istnieje również zestaw rekomendacji – model CMMI for Services (CMMI-SVC). Na przykład dla działów IT ten model (dokładniej jego zalecenia) może pomóc zrozumieć, co należy zrobić, aby na przykład te same zalecenia ITIL stały się normalnym procesem, a nie jakąś „świętą praktyką”.

Model dojrzałości zdolności (CMM)

Ciekawe, że zalecenia tego modelu są dość uniwersalne i nie „zamykają się” tylko na Technologia informacyjna. Pilotażowe wprowadzenie praktyk tego modelu miało miejsce… w jednym ze szpitali w Stanach Zjednoczonych (w końcu opieka medyczna to także usługa).

Jednak każdy z wymienionych modeli jest lepszy do nauczenia. A jeśli jest kilkaset osób przeszkolonych w modelu CMMI-DEV dla całego CIS (około 250-300 osób), to w CIS jest tylko 6 osób przeszkolonych w modelu CMMI-SVC. Mówimy o przeszkolonych, a nie instruktorach. To był właśnie główny problem do grudnia 2011 roku: dla CMMI-DEV na całym świecie był tylko jeden instruktor mówiący po rosyjsku z certyfikatem SEI (CMMI model developer), a dla innych modeli nie było żadnego! Teraz pojawił się również taki instruktor według modelu CMMI-SVC (stąd pierwszych 6 przeszkolonych). Ten instruktor jest autorem tej publikacji, który jest dostępny, aby odpowiedzieć na wszelkie pytania dotyczące wspomnianych modeli i formalnego szkolenia. Zapytać się!

Ten materiał jest prywatnym zapisem członka społeczności Club.CNews.
Redakcja CNews nie ponosi odpowiedzialności za jej treść.

Rozważymy ewolucję modeli zapewniania jakości na podstawie „modelu dojrzałości procesu” lub „modelu poprawy zdolności” CMM (Model Dojrzałości Zdolności). Mimo że model SMM ma na celu zapewnienie jakości oprogramowania, jego aspekty metodologiczne mają zastosowanie do modeli zapewnienia jakości dowolnego produktu (towarów, robót, usług).

Główny w modelu SMM to pojęcie dojrzałości organizacyjnej.

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

Dojrzały Uznaje się, że organizacja spełnia następujące warunki:

• – istnieją dobrze zdefiniowane procedury tworzenia oprogramowania i zarządzania projektami, które są dopracowywane i udoskonalane w projekty pilotażowe analizując składniki „koszt – zysk”;
• – szacunki czasu i kosztów wykonania pracy oparte są na zgromadzonym doświadczeniu i dlatego są dość dokładne;
• – firma posiada standardy procesów rozwoju, testowania i wdrażania oprogramowania, zasady projektowania finalnego kodu programu, komponenty, interfejsy itp. Wszystko to składa się na infrastrukturę i Kultura korporacyjna wspierający proces tworzenia oprogramowania.

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

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

Pierwszy poziom (poziom początkowy) jest podstawą rozwoju przedsiębiorstwa na kolejnych poziomach. Uważa się, że w przedsiębiorstwie klasy podstawowej organizacji nie ma stabilnych warunków do tworzenia wysokiej jakości oprogramowania. W konsekwencji wynik każdego projektu zależy wyłącznie od osobistych cech menedżera i doświadczenia programistów. Oznacza to, że sukces w jednym projekcie można powtórzyć tylko wtedy, gdy ci sami menedżerowie i programiści zostaną przypisani do kolejnego projektu. Jeśli jednak z przedsiębiorstwa odchodzą menedżerowie lub programiści, którzy zdobyli doświadczenie w projektach, to wraz z ich odejściem gwałtownie spada jakość wytwarzanego oprogramowania.

Należy uznać, że na początkowym poziomie, w sytuacjach stresowych, duża zależność od czynnik ludzki proces rozwoju sprowadza się do pisania kodu i jego minimalnego testowania.

Osiągnięcie drugiego powtarzalny poziom (powtarzalny poziom) zależy od wdrożenia technologii zarządzania projektami w przedsiębiorstwie. Planowanie i zarządzanie projektami w przedsiębiorstwie opiera się na zgromadzonym doświadczeniu, istnieją i są stosowane standardy opracowanego oprogramowania, których przestrzeganie jest kontrolowane przez specjalną grupę ds. zapewnienia jakości. Uważa się, że poziom drugi może zarówno stwarzać możliwości dalszego doskonalenia (przejście na poziom trzeci), jak i nie wyklucza możliwości regresywnego powrotu jakości procesu wytwarzania oprogramowania do poziomu wyjściowego w warunkach krytycznych.

Trzeci, pewien poziom (zdefiniowane po lewej) charakteryzuje się tym, że standardowy proces tworzenia i utrzymania oprogramowania jest w pełni udokumentowany, od rozwoju oprogramowania po zarządzanie projektami. Hipotezą wprowadzenia tego poziomu jest to, że w procesie standaryzacji przedsiębiorstwo przechodzi do najefektywniejszych praktyk i technologii. Aby stworzyć i utrzymać funkcjonowanie standardów tworzenia oprogramowania i zarządzania projektami w organizacji, należy stworzyć specjalną grupę. Warunkiem osiągnięcia trzeciego poziomu jest obecność w przedsiębiorstwie programu ustawicznego rozwoju zawodowego i szkolenia pracowników. Uważa się, że począwszy od tego poziomu organizacja przestaje zależeć od cech konkretnych programistów i nie ma tendencji do ześlizgiwania się na niższy poziom w sytuacjach stresowych.

Czwartego zarządzany poziom (poziom zarządzany) przedsiębiorstwo ustala ilościowe wskaźniki jakości - zarówno dla produktów oprogramowania, jak i ogólnie dla procesów ich tworzenia. W ten sposób lepsze zarządzanie projektami osiąga się poprzez zmniejszenie odchyleń różnych wskaźników projektowych. Jednocześnie oddzielane są znaczące (sygnałowe) wariacje zaimplementowanych procesów wytwarzania oprogramowania oraz losowe (szumowe) wariacje procesu.

piąty (najwyższy), poziom optymalizacji (poziom optymalizacji) charakteryzuje się tym, że środki doskonalące stosuje się nie tylko do istniejących procesów, ale także do oceny skuteczności wprowadzania nowych technologii. Głównym zadaniem przedsiębiorstwa na tym poziomie jest ciągłe doskonalenie istniejących procesów. Jednocześnie doskonalenie procesów powinno zapobiegać: możliwe błędy i wad. Jednocześnie należy prowadzić prace nad obniżeniem kosztów wytwarzania oprogramowania.

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 ewolucji (poziomów), na których zarządzane są procesy w organizacji.

Pierwotnie stworzony do tworzenia oprogramowania, celem modelu dojrzałości zdolności jest to, że organizacja powinna 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, aby się ich trzymać) Zdefiniowane (wszystkie procesy są zdefiniowane, udokumentowane), ujednolicone i zintegrowane) Zarządzane ( procesy są mierzone poprzez agregowanie szczegółowych danych o procesach i ich jakości) Optymalizacja (ciągły rozwój procesów poprzez ilościowe informacje zwrotne oraz 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ę tworzeniem oprogramowania i sprzedażą w udoskonalaniu ich procesów oprogramowania w sposób ewolucyjny. Zaczynając od doraźnych, chaotycznych procesów, przechodząc do dojrzałych, zdyscyplinowanych procesów oprogramowania. Nacisk kładziony jest na identyfikację kluczowych obszarów procesów i przykładowych praktyk, które mogą stanowić zdyscyplinowane procesy oprogramowania. Pojęcie dojrzałości CMM tworzy kontekst, w którym:

Praktyki można powtarzać. Jeśli nie powtarzasz jakiejś operacji, nie powinieneś jej poprawiać. Istnieją zasady, procedury i praktyki, które zmuszają organizację do wdrożenia i konsekwentnego wykonywania. Najlepsze praktyki dotyczące organizacji pracy produkcyjnej można szybko udostępniać grupom. Praktyki są zdefiniowane tak, aby umożliwić wymianę między projektami, zapewniając w ten sposób pewną standaryzację dla organizacji. Odchylenia w wykonaniu tych metod są zminimalizowane. Zadania są wyznaczane ilościowo; a pomiary są ustalane, produkowane i utrzymywane w celu stworzenia podstawy do 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 cech

Poziomy dojrzałości są koncepcją warstwową, która zapewnia spójność dyscypliny, która jest potrzebna do osiągnięcia ciągłego doskonalenia. Należy tutaj zauważyć, że organizacja rozwija umiejętność oceny konsekwencji nowej praktyki, technologii lub narzędzia. Dlatego nie 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 bezpieczny sposób. Stopień, w jakim cele są osiągane, wskazuje, jaki rodzaj zdolności organizacja ustanowiła na tym poziomie doskonałości. Cele wyznaczają zakres, granice i cel każdego kluczowego obszaru procesu. Charakterystyka ogólna – Charakterystyka ogólna obejmuje praktyki, które wdrażają i instytucjonalizują kluczowe obszary procesów. Te 5 typów ogólna charakterystyka obejmują: zobowiązanie do wykonania, zdolność do wykonania, inicjatywy do wykonania, pomiar i analizę oraz kontrolę realizacji. Kluczowe praktyki — Kluczowe praktyki opisują elementy infrastruktury i praktyki, które najbardziej efektywnie 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 na temat proces oprogramowania potrzebne do dokumentacji?