Wstęp

Najważniejszą częścią nowoczesnych złożonych systemów są produkty programowe – komponent intelektualny. Produkty programowe są obecnie wykorzystywane do rozwiązywania problemów zarządzania w niemal wszystkich obszarach działalności człowieka: w gospodarce, społeczeństwie, wojsku i innych. Bezpieczeństwo Wysoka jakość domowy produkty oprogramowania z nimi masowy rozwój i dostaw do różnych zastosowań w kraju i na rynku światowym stało się celem strategicznym.

Obecnie istnieją dwa prawie niezależne obszary normalizacji w inżynierii oprogramowania i zapewnianiu jakości oprogramowania, które można warunkowo nazwać profilami standardów ISO ( organizacja międzynarodowa standaryzacja) oraz modele dojrzałości SEI (US Software Engineering Institute). Te 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 programistycznych i możliwość ich udanego eksportu, muszą one być rozwijane i certyfikowane zgodnie z wymaganiami profile międzynarodowe standardy 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 defektom zapewnia stosowanie 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 obniżenie całkowitego kosztu zasobów do projektowania, wdrażania i utrzymania. narzędzia oprogramowania(PS). Aby to zrobić, należy przede wszystkim zastosować metody i narzędzia analizy i projektowania, zapewniające od początku konkretyzację i jak najdokładniejsze odwzorowanie celów, zadań i funkcji. koło życia(LC) PS i zapobieganie rozprzestrzenianiu się ewentualnych wad systemu na kolejne etapy rozwoju. Takie technologie inżynierii oprogramowania pozwalają na wyeliminowanie lub znaczne ograniczenie poziomu błędów systemowych, algorytmicznych i programowych w przekazywanych do eksploatacji produktach programowych. 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, wykorzystywane w nich oprogramowanie poddawane jest orzecznictwo certyfikowane, zorientowane na problemy centra testowe lub laboratoria. Testy takie powinny być przeprowadzane, gdy programy zarządzają złożonymi, krytycznymi procesami lub przetwarzają informacje na tyle ważne, że wady w nich lub niedostateczna jakość mogą spowodować znaczne szkody. Testy certyfikacyjne powinny ustalić zgodność kompleksów oprogramowania z wymaganiami dokumentacji i pozwolić im działać w granicach zmian parametrów środowiska zewnętrznego badanego podczas testów. Tego typu testy charakteryzują się największą surowością i dogłębnością kontroli i powinny być przeprowadzane przez specjalistów niezależnych od programistó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 klientów, 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 systemach jakości zapewniających cykl życia PS w oparciu o wymagania ISO 9000:2000 Lub CMMI:2003, gwarantuje wysokie, zrównoważone zarządzanie jakością procesów i produktów ich cyklu życia, a także pozwala w wielu przypadkach ułatwić certyfikację końcowego produktu oprogramowania. Dlatego też klienci skomplikowanych projektów informatycznych wybierają wykonawców wdrożeniowych, którzy posiadają certyfikaty potwierdzające stosowanie przez nich systemów zapewnienia jakości opartych na dostosowanych profilach standardów międzynarodowych lub modelach dojrzałości.

Luki w nauczaniu metod inżynierii oprogramowania pozostawiają szerokie pole do arbitralności specjalistów w ocenie jakości ich pracy, a także pojawiania się licznych defektów i błędów w projektach programistycznych. Rosnąca złożoność i odpowiedzialność współczesnych zadań rozwiązywanych przez programy, a także możliwe szkody wynikające z niedostatecznej jakości ich wyników, znacznie zwiększyły przydatność metod opanowania dla pełnego, znormalizowanego opisu wymagań dotyczących cech jakościowych i metod pomiaru ich rzeczywiste, osiągane wartości na różnych etapach cyklu życia oprogramowania. Gwałtownie wzrosła potrzeba znajomości przez specjalistów pojęć, definicji i metod oceny cech jakości oprogramowania.

Gwałtowny wzrost i komplikacja kompleksów oprogramowania prowadzi do powstawania dużych zespołów programistycznych z profesjonalnym podziałem pracy, w których konieczne jest uregulowanie skoordynowanych działań grup specjalistów nad jednym projektem. Obietnice programistów w umowach dotyczące dostarczenia 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ą w tej kwestii zgody, 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 stosowaniu 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 i jego rzetelnej oceny z głównym celem – aby procesy projektowe do opanowania, a wyniki są możliwy do przewidzenia. Konieczna 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 zasobów, którymi dysponuje się w celu zapewnienia i poprawy tej jakości.

Model Dojrzałość CMM I-1.1 udoskonala i ulepsza poprzednie modele WMP(patrz ), a także częściowo uwzględnia podstawowe wymagania istniejących standardów międzynarodowych w zakresie zarządzania oprogramowaniem. Znaczna uwaga w CMMI dotyczy procesów rozwojowych i uwzględniania iteracji przy zmianie wymagań klienta, ich identyfikowalności z funkcjami, komponentami, testami i dokumentami projektowymi. Ostatnio pojawiły się informacje o modernizacji wersji SEI wersji z 2003 roku. 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 przedsiębiorstwa 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 firmę 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 etapowe ocena i poprawa dojrzałości przedsiębiorstwa, a także ogólna organizacja cyklu życia kompleksów programowych. modele CMMI udzielanie pomocy specjalistom w organizowaniu i ulepszaniu 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. Składowe modeli ciągłych i etapowych są w dużej mierze podobne i mogą być dobierane i stosowane w różnych kompozycjach i kolejności użycia, w zależności od właściwości i charakterystyki konkretnych projektów.

Opcje opisu modelu są zbudowane zgodnie z jednym schematem, który obejmuje sekcje ogólne:

• Przedmowa;
• 1 sekcja - wprowadzenie;
• Sekcja 2 - model składowy;
• Sekcja 3 - terminologia;
• Sekcja 4 - zawartość poziomów i główne komponenty każdej wersji modelu (opracowanie celów i procedur);
• Sekcja 5 - struktura interakcji procesów; cztery kategorie procesów w sekcji 7 są opatrzone adnotacjami, ich ogólny przegląd oraz schematy interakcji procesów CMMI:
  • zarządzanie procesem;
  • zarządzanie - zarządzanie projektami;
  • technologia inżynieryjna);
  • wsparcie;
• Sekcja 6 — Używanie modelu CMMI- krótkie zalecenia dla użytkowników dotyczące stosowania modelu i szkolenia; odnotowuje się kompatybilność i zgodność procesów wzorcowych z procesami regulowanymi 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. Ta sekcja zawiera szczegółowe zalecenia dotyczące realizacji każdego z wymienionych w niej procesów, które uwzględniają cechy konkretnego modelu.

Pierwsza opcja(ciągły) model 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). Zintegrowana inżynieria systemów/inżynieria oprogramowania/zintegrowane produkty i model oceny dojrzałości procesu rozwoju — widok ciągły. 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 projektami:
  • planowanie;
  • monitorowanie i kontrola procesów projektowych;
  • Zarządzanie ryzykiem;
  • ilościowe zarządzanie projektami;
• technologia inżynieryjna):
  • zarządzanie wymaganiami;
  • rozwój wymagań;
  • rozwiązania techniczne;
  • integracja produktów;
  • weryfikacja;
  • walidacja (certyfikacja, zatwierdzenie);
• wsparcie:
  • Zarządzanie konfiguracją;
  • analiza i podejmowanie decyzji o zmianach;
  • analiza przyczyn źródłowych i rozwiązanie problemu (eliminacja defektów).

Pięć załączników zawiera:

A- skład wykorzystanych źródeł literackich i dokumentów, który jednak nie wspomina o normach ISO;

W- skróty;

Z- terminologia oparta na glosariuszu 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, planowaniu, zarządzaniu i kontrolowaniu procesów wdrażania projektów oprogramowania, opracowywaniu i zarządzaniu wymaganiami dotyczącymi produktów oprogramowania. Poniżej przedstawiono przykłady szczegółów w CMMI niektórzy z nich.

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

• ocena możliwej wielkości (skali) oprogramowania;
• ocena złożoności funkcji i charakterystyki projektu PS;
• zdefiniowanie modelu i etapów cyklu życia pakietu oprogramowania;
• studium wykonalności projektu - określenie kosztu, pracochłonności i długości cyklu życia stacji;
• opracowanie etapowego 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 zaopatrzenia w wiedzę i kwalifikacje zespołu specjalistów do realizacji projektu;
• uogólnienie i analiza zestawu planów dla 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 charakterystyki 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ń wstępnych dla funkcji PS na zestaw wymagań dla komponentów i testów pakietu oprogramowania;
• sformalizowanie wymagań dla interfejsów między komponentami, ze środowiskiem operacyjnym i zewnętrznym;
• opracowanie koncepcji oprogramowania i scenariuszy jego wykorzystania;
• opracowanie wymagań dotyczących ogólnych cech przydatności funkcjonalnej i wykorzystania funkcji oprogramowania zgodnie z jego przeznaczeniem.

Zarządzanie wymaganiami oba modele zawierają:

• osiągnięcie jednoznacznego zrozumienia wymagań dla projektu PS przez klienta i deweloperów;
• uzyskanie przez klienta od twórców zobowiązania do spełnienia wszystkich jego wymagań dotyczących oprogramowania;
• zarządzanie zmianami wymagań dla projektu PS uzgodnionych 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 pomiędzy procesami rozwoju projektu a wymaganiami klienta.

Druga opcja przedstawia dokument: Capability Maturity Model Integration (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 — wstęp etapowy. Model opiera się na zachowaniu koncepcji pięciu poziomów dojrzałości WMP[ , ]. Skład procesów praktycznie powtarza ten podany powyżej dla pierwszej wersji modelu, ale w nieco innej kolejności i ze stosunkowo niewielkimi dodatkami.

Pierwszy poziom charakteryzuje się znaczną niepewnością co do składu i treści procesów w różnych stosunkowo prostych projektach, dlatego nie jest komentowana w dokumencie. Dlatego podczas wyjaśniania i uszczegóławiania treści procesów w wersji etapowej CMMI zaleca się ograniczyć cztery główne poziomy:

• drugi poziom- formalizuje podstawowe zarządzanie projektami:
  • 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:
  • rozwój 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 deweloperskiego;
  • zintegrowane zarządzanie dostawcami;
  • analiza i rozwiązywanie problemów (eliminacja usterek);
  • organizacja środowiska do integracji;
• czwarty poziom- definiuje zarządzanie ilościowe:
  • organizacja reprezentacji jakości procesów;
  • zarządzanie ilościowe całym projektem i zasobami;
• piąty poziom- optymalizacja, ciągłe doskonalenie:
  • organizacja, innowacyjność, ilościowe zarządzanie procesami i udostępnianiem zasobów;
  • analiza przyczyn wad, doskonalenie 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ę stosowanie na każdym wyższym poziomie dojrzałości wszystkie procesy poprzednie niższe poziomy. W obu wersjach modelu każdy wyróżniony powyżej podstawowy proces opatrzony jest szczegółowymi rekomendacjami jego praktycznej realizacji, które zawierają opisy na około 20–30 stronach ujednoliconych w strukturze:

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

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

Z naciskiem na modele CMMI przypisuje się 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 składowe profilu złożonych standardów cyklu życia PS [ , ]. Wymagania dla procesów w działach funkcjonalnych 4-8 norm ISO 9001, ISO 9004, ISO 90003 w modelu można porównać kilka odpowiednich pod względem treści sekcji CMMI(na ryc. 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 programistycznych, mankamenty modeli CMMI dotyczące profilu istniejących norm ISO może zawierać następujące elementy:

Opracowano i wstępnie zatwierdzono w 1998 r. 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 aplikacji. Przedstawia model dojrzałości WMP i osiem podstawowe zasady inżynieria oprogramowania oparta na standardzie ISO 9000:2000. potem w ISO niniejszy dokument został poddany radykalnej rewizji, redukcji, uproszczeniu 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 programistycznych realizowanych przez przedsiębiorstwa:

• ustalanie stanu własnych procesów technologicznych i ich doskonalenie;
• określenia przydatności 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.

Norma przyczynia się do: samooceny dojrzałości przedsiębiorstw, zapewnienia odpowiedniego zarządzania atestowanymi procesami, określenia profilu ocen procesów, a także dopasowuje się do dowolnego zakresu i wielkości systemów operacyjnych i systemów. Zastosowanie standardu ma na celu rozwój przedsiębiorstw i specjalistów kultura ciągłego doskonalenia dojrzałości technologii zapewnienie cyklu życia PS odpowiadającego celom biznesowym projektów oraz optymalizacja wykorzystania dostępnych zasobów. Ocena dojrzałości procesowej przedsiębiorstwa daje możliwość porównania i wyboru tych, które są preferowane dla określonych 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 programistów: umiejętność określenia aktualnej i potencjalnej dojrzałości procesów cyklu życia własnego 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 jest rozpatrywane w dwa aspekty: usprawnienie procesów cyklu życia PS i systemów konkretnego przedsiębiorstwa oraz określenie, czy deklarowana dojrzałość procesów wspierających projekt lub przedsiębiorstwo odpowiada rzeczywiście zastosowanym procesom. Znajduje to odzwierciedlenie w kolejnych pięciu częściach normy. 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 wykorzystania części normy. Przedstawiono ogólne wymagania dotyczące certyfikacji, terminologię, strukturę, określono zakres pozostałych części normy.

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

Część 3 - Wytyczne dotyczące produkcji certyfikatów. Zawiera przegląd technologii przeprowadzania procesów oceny dojrzałości i interpretacji implementacji wymagań. Odzwierciedla: wykonanie certyfikacji; narzędzia pomiarowe do określania procesów dojrzałości; dobór i zastosowanie narzędzi certyfikacji; ocena kompetencji osób certyfikujących; weryfikacja zgodności atestu 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 pozyskiwaniu, rozwijaniu, stosowaniu i utrzymywaniu.

Część 4 – Wskazówki dla użytkownika dotyczące doskonalenia procesu i dojrzałości procesu w tych dwóch aspektach. Zaleca się szereg kroków, które obejmują: zastosowanie wyników procesów walidacji; ustalanie celów oceny dojrzałości; określenie danych wstępnych do certyfikacji; ocena możliwości ograniczenia wynikających z tego zagrożeń; kroki mające na celu usprawnienie 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 przedstawiony w części 2. Obszerny dokument (162 strony) zawiera praktyczne przykłady poprzednich części standardu do organizowania, oceny i ulepszania ocen 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żonego oprogramowania programistom i dostawcom czasami trudno jest zidentyfikować i podkreślić zalety modeli do zastosowania. CMMI. W zależności od tradycji przedsiębiorstwa i specyfiki dużego projektu często wskazane jest wykorzystanie PS jako głównego pełnego profil standardówISO oraz do oceny klientów poziom dojrzałości zarządzający, organizacyjni i technologiczni wspierający projekty PS stosują określone zalecenia CMMI. Wytyczne te mogą być skutecznie stosowane w certyfikacja jakości procesu w przedsiębiorstwach zapewniających cykl życia PS, jako alternatywa lub wraz z certyfikacją według zestawu standardów zarządzania ISO 9000, w zależności od specyfiki projektu i wymagań wnioskującego 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 się składają system certyfikacji, procesy te są poparte uregulowanymi procedurami i dokumentami i muszą być przeprowadzane przez wykwalifikowanych, certyfikowanych rzeczoznawców – inspektorów. Do certyfikacji przedsiębiorstwa-programisty i wyników jego działalności - oprogramowanie, modele CMMI lub profile standardowe 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 iw prostszych przypadkach mogą zostać ograniczone w drodze porozumienia między programistami, klientami i podmiotami certyfikującymi.

Prace certyfikacyjne rozpoczynają się od akredytacji jednostki lub laboratorium badawczego, utworzenia i złożenia wniosku oraz zestawu dokumentów do Centralnej Jednostki Certyfikującej w celu podjęcia decyzji w sprawie wykonalności akredytacji. W przypadku pozytywnego wyniku testu sporządzany i wydawany jest certyfikat akredytacji.

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

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

• polityka w zakresie zapewniania jakości badań i egzaminów;
• wyposażenie ośrodka w odpowiednie materiały metodyczne oraz oprogramowanie i narzędzia badawcze;
• formalizacja wymagań dla obiektów testowych;
• polityka w zakresie wyposażenia technicznego ośrodka i rozwoju kadry;
• archiwizacja i kontrola bezpieczeństwa dokumentacji wyników certyfikacji.

W celu oceny wyrobów lub procesów podlegających certyfikacji wnioskodawca przesyła wniosek do jednostki certyfikującej 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ący specyfikę produktów (wielkość, technologię, 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 prac.

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

Wnioskodawca podejmuje ostateczne decyzje, które elementy systemu jakości, obszary i rodzaje działań organizacyjno-technicznych podlegają weryfikacji podczas certyfikacji w danym 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 produktów, dokumenty z badań przeprowadzonych przez zewnętrzne laboratoria badawcze oraz inne dokumenty wskazujące na zgodność technologii lub produktów z ustalonymi wymaganiami. Na podstawie analizy przedstawionych wraz z wnioskiem udokumentowanych dowodów zgodności swoich wyrobów z ustalonymi wymaganiami jednostka certyfikująca może podjąć decyzję o ograniczeniu zakresu badań lub wydaniu certyfikatu.

Testy są przeprowadzane przez laboratoria badawcze akredytowane do przeprowadzania tylko tych badań, które są przewidziane w ich dokumentach akredytacyjnych. W przypadku braku możliwości przeprowadzenia badań w placówce badawczej akredytowanego laboratorium, badania mogą być przeprowadzone przez personel tego laboratorium u producenta lub konsumenta tego wyrobu z wykorzystaniem własnych placówek laboratorium badawczego lub placówek badawczych udostępnionych przez dostawcę .

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

• analiza i wybór przez dewelopera lub klienta (wnioskodawcę) właściwego w tej dziedzinie organu oraz certyfikowanego laboratorium do wykonania badań certyfikacyjnych;
• złożenie przez wnioskodawcę wniosku o przeprowadzenie badań do jednostki certyfikującej i podjęcie przez certyfikujących decyzji w sprawie wniosku, wybór schematu certyfikacji, zawarcie umowy certyfikacyjnej;
• identyfikacja wymagań dla systemu jakości przedsiębiorstwa i/lub wersji testowanego oprogramowania;
• wykonanie testów certyfikacyjnych systemu jakości firmy lub wersji oprogramowania przez laboratorium certyfikujące;
• analiza uzyskanych wyników i podjęcie decyzji przez laboratorium i/lub jednostkę certyfikującą o możliwości wydania wnioskodawcy certyfikatu zgodności;
• wydanie wnioskodawcy przez jednostkę certyfikującą - certyfikatu i licencji na używanie znaku zgodności i wydawanie certyfikowanych produktów - wersje oprogramowania;
• wdrożenie kontroli kontrolnej przez jednostkę certyfikującą certyfikowany system jakości przedsiębiorstwa i / lub produktów;
• przeprowadzenie przez wnioskodawcę działań korygujących 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ę, cele i obowiązki w zakresie jakości, a także stopień zrozumienia, realizacji i utrzymywania tej polityki w stanie gotowości do pracy 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. Dostępność wymagań, procedur, narzędzi i wyszkolonego personelu do praktycznej realizacji procesów systemu jakości, a także przydatność i systematyczna dokumentacja wszystkich elementów składowych, wymagań i postanowień systemu jakości, który jest procesem zintegrowanym przez całe życie należy sprawdzić cykl PS. Kontrole systemu jakości powinien zawierać definicję:

• dostępność i kompletność dokumentacji technologicznej oraz zgodność z jej wymaganiami w praktyce;
• stan urządzeń technologicznych i dostępność systemu ich utrzymania;
• istnienie i skuteczność systemu kontroli i badań;
• stan przyrządów pomiarowych i badawczych;
• dostępność systemu identyfikacji i eliminacji stwierdzonych braków w produktach lub technologii.

Na podstawie przeprowadzonych badań ocenia się uzyskane wyniki i uzasadnia wnioski o zgodności lub niezgodności produktów lub procesów z wymaganiami dokumentów regulacyjnych. Sprawozdania z badań są przekazywane jednostce certyfikującej, a także wnioskodawcy na jego żądanie. Sprawozdania z badań podlegają przechowywaniu przez okresy określone w regulaminie 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 i zawierający analizę kompletności i jakości przedłożonych dokumentów źródłowych oraz stopień ich praktycznego zastosowania w projektowaniu, rozwijaniu i dostarczaniu oprogramowania. Badanie stosowania procedur systemu jakości przeprowadza laboratorium badawcze na stanowiskach pracy przedsiębiorstwa, które zapewnia cykl życia PS. Przeprowadzane są kontrole obecności specjalistów-twórców odpowiednich dokumentów w miejscu pracy oraz kompletności stosowania ich postanowień i zaleceń. Przeglądy stanu projektu oraz 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 należy podać niezbędne zasoby za realizację programu testów, metody planowania i opracowanie 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 wykorzystywane podczas testów oraz procedurę testową, a także przewidywane wyniki kontroli. Należy opracować metody kontroli korekt, działań mających na celu usunięcie wad, jeśli taka prośba zostanie odebrana przez służbę 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żone wnioskodawcy i jednostce certyfikującej. Wnioskodawca może przedłożyć jednostce certyfikującej raporty z badań, z uwzględnieniem terminów ich ważności, przeprowadzonych podczas opracowywania 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 ocenia się uzyskane wyniki i uzasadnia wyciągnięte 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ń oraz uzasadnienie wydania certyfikatu. W przypadku uzyskania negatywnych wyników badań certyfikacyjnych wydawana jest decyzja o odmowie wydania certyfikatu zgodności. Po zakończeniu certyfikowanego produktu lub systemu jakości badania można powtórzyć. Wyniki analizy stanu technologii lub jakości produktu sporządza się aktem, który podaje szacunki dla wszystkich pozycji Programu Testów i zawiera wnioski, w tym ogólną ocenę stanu produkcji i produktów, potrzebę działań naprawczych. Ustawa jest wykorzystywana przez jednostkę certyfikującą wraz z raportami z badań, wnioskiem o wydanie i określeniem okresu ważności certyfikatu dla oprogramowania, częstotliwości kontroli, a także do opracowania działań korygujących.

Na podstawie wyników badań certyfikacyjnych i badania dokumentacji podejmowana jest decyzja o wydaniu certyfikatu. W przypadku uzyskania negatywnych wyników badań certyfikacyjnych, podejmowana jest decyzja o odmowa wydania zaświadczenia zgodność. Ponadto do wnioskującego przedsiębiorstwa można przesyłać propozycje wyeliminowania rzekomych przyczyn negatywnych wyników badań, po zakończeniu certyfikowanych produktów badania można powtórzyć.

Jednostka certyfikująca po analizie raportów z badań, ocenie produkcji, certyfikacji systemu jakości, analizie dokumentacji określonej w decyzji o wniosku, ocenia zgodność wyrobów z ustalonymi wymaganiami, sporządza certyfikat na podstawie opinii ekspertów i rejestruje go. W przypadku dokonywania zmian w projekcie lub dokumentacji eksploatacyjnej, 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 wnioskującego przedsiębiorstwa. Równocześnie z wydaniem zaświadczenia może zostać wydane przedsiębiorstwo wnioskujące licencja o prawo do używania znaku zgodności.

Dla certyfikowanych produktów oprogramowania podczas ich eksploatacji przez cały okres ważności certyfikatu zgodności, kontrola inspekcji. Kontrola kontrolna przeprowadzana jest w formie okresowych i niezaplanowane kontrole zgodność z wymaganiami dotyczącymi jakości technologii i certyfikowanych produktów. Przedmiotem kontroli, w zależności od systemu certyfikacji, są certyfikowane wyroby, system jakości lub stabilność produkcji dewelopera. Przy ustalaniu częstotliwości i zakresu kontroli brane są pod uwagę następujące czynniki: stopień potencjalnego zagrożenia oprogramowania, stabilność produkcji, wielkość wydań, dostępność i zastosowanie systemu jakości w trakcie rozwoju, informacje na wynikach badań wyrobu i jego produkcji przeprowadzonych przez producenta, państwowe organy kontroli i nadzoru.

Wyniki kontroli inspekcyjnej sporządza się aktem, która ocenia wyniki badań próbek i innych sprawdzeń, formułuje ogólne wnioski 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 brały udział w kontroli kontrolnej. Na podstawie wyników kontroli inspekcyjnej 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 wyrobów 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, przepisach produktowych czy metodzie badań;
• zmiany w projekcie (składzie), kompletności produktów;
• zmiany w organizacji lub technologii rozwoju i produkcji;
• niezgodności z wymaganiami technologii, metod kontroli i badań, systemu jakości, jeżeli wymienione zmiany mogą spowodować niezgodność wyrobów z wymaganiami kontrolowanymi podczas certyfikacji.

Decyzja o zawieszeniu ważności certyfikatu i licencji uprawniającej do używania znaku zgodności nie zostaje podjęta, jeżeli wnioskodawca w drodze działań naprawczych uzgodnionych z wydającą ją jednostką certyfikującą może wyeliminować stwierdzone 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, wówczas ważność certyfikatu zostaje anulowana, a licencja na prawo do używania znaku zgodności zostaje anulowana. 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 produktów znakiem zgodności może zostać odnowiona, jeżeli przedsiębiorstwo deweloperskie spełni następujące warunki:

• identyfikowanie przyczyn niezgodności i ich eliminowanie;
• przedłożenie jednostce certyfikującej raportu z prac wykonanych 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ębiorstw zależą od charakterystyki projektowania, rozwoju i modyfikacji oprogramowania, a także od wymagań dotyczących ich jakości oraz charakterystyki środowiska technologicznego. Dlatego niezbędny zestaw dokumentów dla każdego przedsięwzięcia lub projektu powinien zostać dobrany i dostosowany w odniesieniu do tych cech. Wskaźnikami systemu jakości ocenianymi podczas certyfikacji są dostępność odpowiednich dokumentów oraz praktyczne spełnianie wymagań określonego poziomu dojrzałości modelu. 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 deweloperem i zatwierdzonych w celu sprawdzenia 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 systemów jakości zgodnych z nomenklaturą i treścią profilu norm opartych na ISO 9000:2000 lub modele dojrzałości SMMI, a także przygotowany na ich podstawie program, podręcznik i instrukcje, przedstawione testerom (ekspertom) systemu jakości lub wyrobów audytowanego przedsiębiorstwa;
• dokumenty źródłowe charakteryzujące konkretne przedsiębiorstwo lub projekt, a także cykl życia narzędzia programistycznego, przygotowane przez kierownictwo projektu w celu 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 audytowanego przedsiębiorstwa.

Zgłoszone do certyfikacji oprogramowanie lub system jakości przedsiębiorstwa należy zł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. Zestaw dokumentów może zostać zmniejszony i dostosowany zgodnie z ustaleniami między wnioskodawcą, osobą certyfikującą i kierownictwem audytowanego przedsiębiorstwa zgodnie z charakterystyką projektów oprogramowania. Niektóre dokumenty można połączyć w zintegrowane raporty z wyraźną odpowiedzialnością określonych specjalistów za ich realizację.

Podstawowe dokumenty systemu jakości przedsiębiorstwa i cyklu życia oprogramowania

1. Pojęcie, 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 sekcji i zaleceń norm ISO 12207, ISO 15504, ich zmiany oraz wytyczne stosowania, wybrane podczas adaptacji i obowiązkowe do stosowania w systemie jakości konkretnego przedsiębiorstwa lub projektu oprogramowania.
3. Dostosowana wersja lub wykaz sekcji i zaleceń normy ISO 900003, wybrane podczas adaptacji i obowiązkowe 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 zatwierdzone wydanie podręcznika zarządzania utrzymaniem i konfiguracją w oparciu o zalecenia norm ISO 14764, ISO 10007, ISO 15846.
6. Zestaw opisów stanowisk, które określają odpowiedzialność, uprawnienia i procedurę interakcji wszystkich kierowniczych, wykonujących i sprawdzających pracę personelu zaangażowanego w procedury systemu jakości przedsiębiorstwa dla określonego projektu PS.

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

1. Opis charakterystyk wytwarzanych w przedsiębiorstwie oprogramowania, systemu i środowiska zewnętrznego cyklu ich życia, niezbędnych do adaptacji i przygotowania roboczych wersji standardów i wymagań projektu PS oraz korporacyjnego systemu jakości zgodnie z zalecenia norm ISO 12207, ISO 15504, ISO 90003 I ISO 9126.
2. Opis celów, wymagań i obowiązków przedsiębiorstwa-programisty w zakresie systemu jakości, kryteriów jakości dla procesów i produktów rozwoju, dostarczania i obsługi całego cyklu życia oprogramowania.
3. Zestaw dokumentów eksploatacyjnych dostarczanych klientowi i użytkownikom w celu zapewnienia cyklu życia i użytkowania określonej wersji oprogramowania w oparciu o przyjęte standardy ISO 9294, ISO 15910, ISO 18019.
4. Dokumentacja i narzędzia 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 oprogramowania, analiza i zatwierdzanie wersji oprogramowania i kompleksów danych.
7. Metodyka zarządzania konfiguracją, zatwierdzania, przechowywania, zabezpieczania, kopiowania wersji oprogramowania i towarzyszących mu dokumentów oraz gromadzenia i przechowywania danych o cechach jakościowych zarejestrowanych w archiwum przedsiębiorstwa w trakcie cyklu życia wersji oprogramowania.

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

1. Raport o dostępności, aktualności i systematycznym wykonywaniu dokumentacji dostosowanej do wymagań i zapisów korporacyjnego systemu jakości, który zapewnia zintegrowany proces zapewnienia jakości w całym cyklu życia oprogramowania.
2. Wyniki monitorowania i badania stanu i stosowania systemu jakości, przeprowadzanych okresowo w celu określenia jego przydatności i skuteczności.
3. Raport o dostępności i utrzymywaniu metod przeprowadzania inspekcji 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 o cechach i atrybutach jakości oprogramowania i jego komponentów.
5. Wyniki realizacji planu rozwoju, udokumentowane dane wejściowe i wyjściowe etapów rozwoju oraz protokoły kontroli realizacji cyklu życia PS.
6. Wyniki praktycznej realizacji programu jakości oraz realizacji działań regulowanych w zakresie jakości na wszystkich etapach cyklu życia PS.
7. Wyniki certyfikacji symulatorów środowiska i generatorów testów oraz ocena ich przydatności do przeprowadzania testów certyfikacyjnych produktu programistycznego.
8. Wyniki analizy realizacji planów i metod badań, sprawozdania z badań, oceny zgodności wyników badań z wymaganiami, a także wyniki badań 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 dotyczącymi certyfikacji produkcji oprogramowania.
10. Certyfikat systemu jakości przedsiębiorstwa i/lub oprogramowania oraz zapewnienie jego cyklu życia, licencja na używanie znaków zgodności.

Literatura

VV Lipajew -- Profile standardów cyklu życia oprogramowania. -- Informacje o odrzutowcu, 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 utrzymywania narzędzi programistycznych i systemów informatycznych ISO IEC TR 15504-CMMI. Za. z angielskiego -- M.: Książka i biznes, 2001

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

VV Lipajew -- Metody zapewniania jakości oprogramowania wielkoskalowego.-- M.: RFBR. SINTEG, 2003

"; antisource: "Oprogramowanie jest obecnie wykorzystywane do rozwiązywania problemów zarządzania w prawie wszystkich obszarach działalności człowieka: w gospodarce, społeczeństwie, wojsku 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]$

Jakość oprogramowania jest prawdopodobnie jednym z najpoważniejszych problemów w branży oprogramowania. Jakość to znacznie więcej niż tylko brak błędów. Oznacza zestaw różnych cech: niezawodność, łatwość hakowania, adaptowalność, kompatybilność, łatwość konserwacji, przenośność, wydajność itd. Nic dziwnego, że istnieje tak wiele standardów jakości w branży oprogramowania.

Jakość była łatwa do zmierzenia: albo dostaliśmy zapłatę, albo nie.
Dean Leffingwell, Don Widrig.
Zarządzanie wymaganiami oprogramowania

WMP/CMMI

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

Na sukces CMM złożyło się kilka czynników. Ten standard był jednym z pierwszych, początkowo uwzględniającym specyfikę tworzenia oprogramowania. Okazało się, że jest dość proste i przejrzyste zarówno do zrozumienia, jak i użytkowania, i regulowało „co”, a nie „jak” robić, a zatem było odpowiednie dla różnych metodologii programistycznych i nie nakładało żadnych ograniczeń na standardy dokumentacji, narzędzia, środowisko i języki używane w projektach. I być może głównym czynnikiem, który przesądził o popularności CMM była współpraca SEI z Departamentem Obrony USA, co de facto oznaczało wykorzystanie standardu przy realizacji projektów zleconych przez ten resort.

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

Tabela 1. Warstwy modelu CMM

numer poziomu	Nazwa poziomu	Kluczowe obszary procesowe
1	Podstawowy	Jeśli organizacja jest na tym poziomie, to nie ma dla niej kluczowych obszarów procesowych
2	powtarzający się	Zarządzanie konfiguracją oprogramowania Zapewnienie jakości oprogramowania Zarządzanie umowami z wykonawcami Monitorowanie postępu projektu Oprogramowanie Planowanie projektów Zarządzanie wymaganiami
3	Określony	Oceny eksperckie.Koordynacja interakcji między zespołami projektowymi.Inżynieria produktu software.Kompleksowe zarządzanie oprogramowaniem.Program szkolenia personelu.Definicja procesu organizacyjnego.Zakres procesu organizacyjnego
4	Zarządzany	Zarządzanie jakością oprogramowania Zarządzanie procesami w oparciu o metody ilościowe
5	Optymalizacja	Zarządzanie zmianami procesowymi. Zarządzanie zmianami technologicznymi. Zapobieganie defektom

Podział na poziomy i zdefiniowanie KPA dla każdego z nich pozwala na konsekwentne wdrażanie CMM z wykorzystaniem standardu jako przewodnika, co może zapewnić ciągłe doskonalenie procesu rozwoju.

Norma CMM okazała się dużym sukcesem, a następnie na jej podstawie stworzono cały szereg norm (tab. 2). Ponadto otrzymał nową nazwę – SW-CMM (Capability Maturity Model for Software), która dokładniej odzwierciedla jego pozycję w dość dużej rodzinie standardów.

Tabela 2. Rozwój standardów CMM

Nazwa normy	Opis
Inżynieria systemowa CMM (SE-CMM)	Koncentruje się na zagadnieniach inżynierii systemowej - rozwoju produktów (analiza wymagań, projektowanie i integracja systemów produktowych) oraz ich produkcji (planowanie i eksploatacja linii produkcyjnych)
Zaufana CMM (T-CMM)	Zaprojektowany do obsługi wrażliwych i zamkniętych systemów oprogramowania, które wymagają zapewnienia wysokiej jakości oprogramowania
Inżynieria bezpieczeństwa systemu CMM (SSE-CMM)	Koncentruje się na aspektach bezpieczeństwa inżynierii oprogramowania, zapewnia bezpieczny proces wytwarzania, w tym bezpieczeństwo członków zespołu tworzącego
Ludzie CMM (P-CMM)	Rozważa zagadnienia rozwoju personelu w organizacjach programistycznych
Pozyskiwanie oprogramowania CMM (SA-CMM)	Obejmuje zakup oprogramowania od organizacji zewnętrznych
Zintegrowany rozwój produktu CMM (IPD-CMM)	Służy jako środowisko do integracji wysiłków rozwojowych na wszystkich etapach cyklu życia i z każdego działu w firmie

Praktyczne zastosowanie standardów serii CMM pokazało jednak, że nie zapewniają one bezwarunkowego sukcesu w tworzeniu oprogramowania. Standardy te nie były ze sobą dobrze skoordynowane – jednoczesne wdrażanie różnych modyfikacji CMM mogło być nie lada wyzwaniem i dezorientować specjalistów organizacji, które się z nim mierzyły.

Również istotnym problemem CMM jest konieczność „ujednolicenia” wszystkich procesów. Jeśli organizacja próbuje uzyskać certyfikat na określonym poziomie, musi upewnić się, że odpowiedni poziom jest stosowany do wszystkich jej procesów. Nawet jeśli specyfika, metodologia lub funkcje rozwojowe nie mają określonych procesów do wykonania, wymaga tego certyfikacja.

Kolejny problem wynika z pozycji, jaką standardy CMM zajęły we współczesnym przemyśle programistycznym. Ponieważ organizacja o wysokim poziomie zgodnie z CMM musi zapewniać wyższą wydajność oprogramowania niż te certyfikowane na niższych poziomach, standard zaczął być stosowany jako kryterium wyboru przy udziale w przetargach na rozwój oprogramowania lub projekty outsourcingowe. Zapotrzebowanie na certyfikowane organizacje zrodziło propozycję „szybkiej i bezbolesnej certyfikacji”.

Taka sytuacja stała się możliwa dzięki niedociągnięciom procesu certyfikacji. Certyfikacji podlega nie cała organizacja jako całość, a jedynie konkretny projekt. Nic nie stoi na przeszkodzie, aby organizacja stworzyła projekt „pokazowy”, który spełnia wszystkie wymagania wysokich poziomów standardu CMM, uzyska odpowiedni poziom certyfikacji i zadeklaruje, że wszystkie produkty spełniają taki a taki poziom standardu.

Rozwiąż większość problemów CMM została zaprojektowana nowy standard SEI - Capability Maturity Model Integrated (CMMI) - Zintegrowany model oceny poziomu dojrzałości procesów rozwojowych. Standard CMMI został pierwotnie stworzony w taki sposób, aby połączyć istniejące opcje CMM i wyeliminować wszelkie sprzeczności w jego praktycznym zastosowaniu w różnych obszarach działalności firm high-tech.

Aby wyeliminować konieczność „ujednolicania” procesów organizacji i być bardziej dostosowanym do jej potrzeb biznesowych, a nie odwrotnie, standard CMMI posiada dwie formy prezentacji – klasyczną, wielopoziomową, nawiązującą do CMM, i nowy, ciągły. Ciągła forma prezentacji nie uwzględnia poziomów dojrzałości (Maturity Levels), ale Capability Levels, które są oceniane dla poszczególnych obszarów procesowych (Process Areas, PA). w tabeli. 3 przedstawia mapowanie poziomów dojrzałości standardu CMM, jak również poziomów dojrzałości warstwowej prezentacji CMMI oraz poziomów możliwości ciągłej prezentacji CMMI.

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

Adnotacja: Szczegółowo zbadano zakres pomysłów leżących u podstaw prawdopodobnie najbardziej znanej metodologii doskonalenia procesów tworzenia oprogramowania, CMM. 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 czynności organizacja projektowa w szczególności organizacja, która się rozwija Systemy informacyjne demonstruje metodologię HMM. CMM to skrót od 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. ubiegłego wieku Departament Obrony USA zlecił Instytutowi Inżynierii Oprogramowania 1 inż. SEI - Instytut Inżynierii Oprogramowania Carnegie Mellon University pracuje nad systemem kryteriów wyboru podwykonawców w projektach wytwarzania oprogramowania. Prace zakończono w 1991 r., a ich efektem była współrzędnościowa maszyna pomiarowa. Musimy od razu zastrzec, że model nie zawiera żadnych finansowych, ekonomicznych, politycznych, organizacyjnych Kryteria wyboru podwykonawcy, a także kryteria dopuszczenia do pracy tajnej (prawdopodobnie takich zadań nie ustalono). Mówimy tylko o kryteriach opisujących możliwości potencjalnego podwykonawcy w zakresie tworzenia systemów oprogramowania.

Struktura maszyny współrzędnościowej

Twórcy modelu przyjęli procesy organizacji jako podstawę do oceny zdolności organizacji do wykonywania jakościowej pracy, którą (zdolność) nazwano dojrzałością. Następnie przyjęli pewne nietrywialne założenia, które następnie zostały zaakceptowane i uznane za uczciwe przez wielu specjalistów IT (a może większość z nich).

Założenie 1. Istnieją jakościowo różne poziomy dojrzałości organizacja projektowa rozwijający się 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 samodoskonalenia).

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

W ten sposób poziomy tworzą „drabinę”, po której wznosi się organizacja 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 została powszechnie zaakceptowana i rozpowszechniona. Oto jak ona wygląda.

Poziom 1 „Początkujący”. Proces produkcyjny jako całość charakteryzuje się tworzeniem każdorazowo pod konkretny projekt, a czasem wręcz chaotycznie. Zdefiniowanych jest tylko kilka procesów, a sukces projektu zależy od wysiłków poszczególnych osób.

Poziom 2 „Powtarzalny”. Ustalone zostały główne procesy zarządzania projektami, pozwalające na śledzenie kosztów, monitorowanie harmonogramu prac oraz funkcjonalności tworzonego oprogramowania. Ustanowił dyscyplinę procesową potrzebną do powtórzenia wcześniejszych sukcesów w podobnych projektach tworzenia aplikacji.

Poziom 3 „Zdecydowany”. Proces produkcji jest udokumentowany i znormalizowany dla obu praca kierownicza jak również do projektowania. Proces ten jest zintegrowany ze standardowym procesem produkcyjnym organizacji. Wszystkie projekty wykorzystują zatwierdzoną, dostosowaną wersję standardowego procesu operacyjnego organizacji.

Poziom 4 „Zarządzany”. Gromadzone są szczegółowe wskaźniki ilościowe procesu produkcyjnego oraz jakości powstającego 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 sprzężenie zwrotne z procesu oraz wdrażanie 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 w ogóle warto do takiego przejścia dążyć. Jednocześnie model HMM nie zawiera żadnego ilościowego ani nawet formalnego uzasadnienia takiego podejścia, co jednak nie umniejsza jego zalet.

Dalej, jak mówią, jest to kwestia technologii. Struktura modelu jest zdefiniowana (rysunek 7.1), podane są definicje i rozpoczyna się żmudna praca nad dokładnym opisem każdego procesu na każdym poziomie. Aby ocenić praktyczną wartość tego, co zostało zrobione, przejdźmy kawałek tej ścieżki.

Ryż. 7.1.

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

Kluczowa Grupa Procesowa. 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 osiągany jest zestaw celów istotnych dla zwiększenia produktywności procesu produkcyjnego. Dla przykład dla grupy kluczowych procesów” Zarządzanie wymaganiami„(Patrz rysunek 7.2) celem jest pogodzenie wymagań projektu rozwoju oprogramowania między klientem a programistą”.

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

Ryż. 7.2.

Grupy kluczowych procesów w CMM są odwzorowywane na poziomy dojrzałości (rysunek 7.2), tj. wszystkie praktyki na poziomie wchodzą w interakcje tylko ze sobą i nie wchodzą w interakcje z praktykami na innych poziomach. Pozwala to zagwarantować pełną realizację wszystkich procesów na określonym poziomie, a co za tym idzie skorelować ten poziom z zakończonym etapem rozwoju organizacji.

Przymiotnik „klucz” sugeruje, że są grupy procesowe(tj. zestawów praktyk), które nie są kluczowe z punktu widzenia określonego poziomu dojrzałości, tj. niezwiązane z osiąganiem celów tego poziomu (patrz poniżej). Model HMM nie opisuje wszystkiego grupy procesowe związanych z rozwojem i utrzymaniem oprogramowania. Opisuje tylko te grupy, które są 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 są osiągane 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 Procesu Kluczowego są osiągane, może się różnić w zależności od projektu ze względu na różnice w zakresie 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ą zostać zaimplementowane na odpowiednim poziomie. Właściwości te opisują, w jaki sposób procesy są realizowane oraz w jakim stopniu są one zalegalizowane w organizacji, czyli oficjalnie zatwierdzone i skoordynowane z korporacyjnymi procedurami, politykami i innymi procesami. Oto pięć sekcji.

Zobowiązania do wykonania świadczenia

Opisz działania, które organizacja musi podjąć, aby zapewnić, że proces jest ustanowiony i stabilny. Zobowiązania do wykonania zadań zazwyczaj dotyczą ustanowienia zasad organizacyjnych i wsparcia ze strony najwyższego kierownictwa.

Wymagania wstępne

Opisać warunki wstępne, które muszą być spełnione w projekcie lub organizacji dla kompetentnej realizacji procesu produkcyjnego; zwykle dotyczą zasobów, struktur organizacyjnych i wymaganych szkoleń.

Operacje w toku

W sekcji Operacje w toku opisano 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 pracy oraz podejmowanie działań naprawczych w razie potrzeby.

Pomiary i analiza

Sekcja „Pomiary i

„Każda grupa procesów kluczowych jest wyrażona przez kluczowe praktyki, których realizacja 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 powstania grupy kluczowych procesów.

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 polityki, procedury i operacje dla grupy kluczowych procesów. Elementy szczegółowego opisu są często określane jako praktyki podrzędne”.

Kluczowe praktyki opisują CO należy zrobić, ale nie powinny być traktowane jako dogmat o tym, JAK cele powinny zostać osiągnięte. Cele grupy procesów kluczowych można osiągnąć poprzez alternatywne praktyki. Interpretacja kluczowych praktyk powinna być racjonalna, pozwalająca na osiągnięcie celów grupy kluczowych procesów efektywny sposób, choć być może formalnie i różni się od zalecanej CMM.

Spojrzenie na czynności związane z zarządzaniem IT, w których zamiast procesów uwzględnia się 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 poprzez wprowadzanie 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ść przechodzenia przez poziomy. Według CMM zarządzanie IT poprawia się, gdy przechodzi na wyższy poziom dojrzałości. Co się dzieje 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 procesów kluczowych i nie jest to przypadek. Proces produkcyjny lub, jak to trafnie nazywa się w CMM, Standard Proces produkcji Organizacje (OSS) to jedno z centralnych pojęć całego modelu.

Organizacje zajmujące się rozwojem, dostarczaniem, wdrażaniem i utrzymaniem oprogramowania oraz integracją systemów coraz częściej czują, że ich konkurencyjność opiera się na jakości i niskich kosztach produkcji.

Liderzy takich organizacji nie zawsze są w stanie sformułować strategię doskonalenia i rozwoju technologii działania swojej firmy; wyraźnie brakuje na rynku pracy specjalistów o niezbędnych kwalifikacjach. Jednocześnie w zakresie doskonalenia procesów technologicznych dla rozwoju i działania oprogramowania międzynarodowe doświadczenie przez wiele lat była niedostatecznie uogólniona i sformalizowana. Dopiero na początku lat 90. American Software Engineering Institute (SEI) stworzył model dojrzałości technologicznej organizacji CMM (Capability Maturity Model), określając poziomy dojrzałości technologicznej i ich cechy charakterystyczne. W ciągu dekady CMM był testowany w wielu organizacjach, jego skuteczność i niezawodność została zweryfikowana przez organizacje zamawiające, dostawców oprogramowania, firmy zajmujące się tworzeniem oprogramowania na zamówienie i oprogramowanie offshore.

Dziś na zachodzie firma deweloperska ma praktycznie duże trudności w pozyskiwaniu zleceń, jeśli nie posiada certyfikatu SMM. Klienci domagają się gwarancji zdolności produkcyjnej wykonawcy, gwarancji, że wykonawca nie może wykonać usługi niskiej jakości.

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

klient przy wyborze najlepszych wykonawców (na przykład w przetargu);

· firmom programistycznym do systematycznej oceny stanu ich procesów technologicznych i wybierania obszarów do ich doskonalenia;

· firmy, które zdecydują się na poddanie się zaświadczeniu w celu oceny „wymiaru katastrofy”, tj. twój obecny stan;

audytorzy w celu ustalenia standardowej procedury certyfikacji i przeprowadzenia niezbędnych ocen;

· firmy konsultingowe zaangażowany w restrukturyzację spółek i dostawców usług informatycznych i usług pokrewnych.

Wraz ze wzrostem dojrzałości technologicznej organizacji procesy tworzenia i utrzymywania oprogramowania stają się coraz bardziej ustandaryzowane i spójne. Jednocześnie formalizacja procesów pozwala na standaryzację oczekiwanych rezultatów ich realizacji oraz zapewnia przewidywalność rezultatów realizacji projektów.

Dojrzałość procesowa (dojrzałość procesu oprogramowania)- to stopień ich zaradności, sterowalności i skuteczności. Rosnąca dojrzałość technologiczna odnosi się do potencjału zwiększenia odporności procesów i wskazuje na stopień efektywności i spójności w stosowaniu procesów wytwarzania i utrzymania oprogramowania w całej organizacji. Rzeczywiste wykorzystanie procesów jest niemożliwe bez ich udokumentowania i zwrócenia uwagi personelu organizacji, bez ciągłego monitorowania i doskonalenia ich realizacji. Możliwości dobrze zaprojektowanych procesów są w pełni zdefiniowane. Zwiększanie dojrzałości technologicznej procesów sprawia, że ​​efektywność i jakość wyników ich realizacji może stale rosnąć.

W organizacjach, które osiągnęły dojrzałość technologiczną, procesy tworzenia i utrzymywania oprogramowania mają status standardu, są utrwalone w strukturach organizacyjnych i określają taktykę i strategię produkcji. Ich wprowadzenie do stanu prawnego pociąga za sobą konieczność budowy niezbędnej infrastruktury i stworzenia wymaganej Kultura korporacyjna branże, które utrzymują odpowiednie metody, operacje i procedury prowadzenia działalności, nawet po tym, jak wszyscy, którzy ją stworzyli, opuszczą organizację.

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

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

CMM to materiał metodyczny określający zasady tworzenia systemu zarządzania tworzeniem i utrzymaniem oprogramowania oraz metody stopniowego i ciągłego doskonalenia kultury produkcji. Celem SMM jest zapewnienie organizacjom programistów niezbędne instrukcje nad wyborem strategii doskonalenia jakości procesów poprzez analizę stopnia ich dojrzałości technologicznej oraz czynników, które w największym stopniu wpływają na jakość wyrobów. Skupiając się na niewielkiej liczbie najbardziej krytycznych operacji i systematycznie poprawiając efektywność i jakość ich wykonywania, organizacja może w ten sposób osiągnąć stałe, ciągłe doskonalenie kultury tworzenia i utrzymywania oprogramowania.

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

Na każdym poziomie ustalane są wymagania, w ramach których osiągana jest stabilizacja najważniejszych wskaźników procesów. Osiągnięcie każdego poziomu dojrzałości technologicznej jest wynikiem pojawienia się określonej liczby komponentów w procesach tworzenia oprogramowania, co z kolei prowadzi do wzrostu ich wydajności i jakości. na ryc. Rysunek 1.7 przedstawia pięć poziomów dojrzałości technologicznej CMM.

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

Napisy na strzałkach określają cechy doskonalenia procesów przy przechodzeniu z poziomu na poziom.

Poziomy od drugiego do piątego scharakteryzować można poprzez działania mające na celu standaryzację i (lub) unowocześnienie procesów tworzenia oprogramowania oraz poprzez działania, które same składają się na procesy jego tworzenia. Jednocześnie poziom pierwszy jest niejako bazą, fundamentem do analizy porównawczej poziomów wyższych.

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

Powodzenie projektu w tym przypadku z reguły zależy całkowicie od stopnia energii i doświadczenia kierownictwa i poziom profesjonalny wykonawcy. Może się zdarzyć, że energiczny menedżer pokona wszystkie przeszkody w procesie projektowym i doprowadzi do wydania naprawdę opłacalnego oprogramowania. Ale po odejściu takiego lidera ze stanowiska nie ma gwarancji, że kolejny taki projekt zakończy się sukcesem. W przypadku braku niezbędnego poziomu zarządzania projektami nawet zaawansowana technologia nie będzie w stanie uratować sytuacji.

Procesy na poziomie pierwszym charakteryzują się nieprzewidywalnością ze względu na to, że ich skład, cel i kolejność w procesie realizacji projektu zmieniają się losowo w zależności od aktualnej sytuacji. W rezultacie alokowane środki finansowe są nadmiernie wydatkowane, a harmonogramy pracy zaburzone. Szkolenie zdolnych i kompetentnych ludzi w organizacjach jest podstawowym warunkiem sukcesu na wszystkich poziomach dojrzałości, ale na pierwszym poziomie jest to jedyna droga do osiągnięcia jakichkolwiek pozytywnych rezultatów.

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

Na tym poziomie planowanie Praca projektowa a zarządzanie nowymi projektami opiera się na doświadczeniach z pomyślnie zakończonych podobnych projektów. Główną cechą drugiego poziomu jest obecność sformalizowanych i udokumentowanych skutecznych procesów zarządzania projektami, co pozwala na wykorzystanie pozytywnych doświadczeń z pomyślnie zakończonych projektów. Efektywne procesy to takie, które są udokumentowane, faktycznie stosowane, mierzalne i możliwe do ulepszenia. Konieczne jest przeszkolenie personelu w zakresie ich stosowania.

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

zarządzanie wymaganiami;

Zarządzanie konfiguracją;

planowanie;

monitorowanie i kontrola projektu;

zarządzanie umowami;

pomiar i analiza;

zapewnienie jakości procesu i produktu.

Procesy na drugim poziomie można scharakteryzować jako uporządkowane ze względu na to, że są zaplanowane z wyprzedzeniem, a ich realizacja jest ściśle kontrolowana, dzięki czemu uzyskuje się przewidywalność rezultatów projektu. Wraz ze wzrostem i złożonością projektów uwaga przesuwa się z technicznych aspektów ich realizacji na kwestie organizacyjne i aspekty menedżerskie. Realizacja procesów wymaga od ludzi bardziej efektywnej i spójnej pracy, co z kolei wymaga studiowania udokumentowanych najlepszych praktyk w celu doskonalenia doskonałości zawodowej.

Na poziomie 3 (poziom procesów standaryzowanych) procesy tworzenia oprogramowania są dokumentowane, standaryzowane i reprezentują jeden system technologiczny, który obowiązuje wszystkie działy organizacji. Wszystkie projekty wykorzystują jedną technologię tworzenia i utrzymywania oprogramowania, która została przetestowana, zatwierdzona i podniesiona do rangi standardu.

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

Specyfikacja wymagań;

integracja produktów;

weryfikacja;

orzecznictwo;

standaryzacja procesów organizacji;

· Edukacja;

zintegrowane zarządzanie projektami;

· Zarządzanie ryzykiem;

Analiza i podejmowanie decyzji.

Głównym kryterium stosowania iw razie potrzeby dostosowania procesów na tym poziomie jest pomoc kadrze zarządzającej i specjalistom technicznym w poprawie efektywności realizacji projektów. Na tym poziomie w organizacji tworzy się specjalną grupę odpowiedzialną za skład operacji składających się na procesy – grupę procesów inżynierii oprogramowania (SEPG).

Na podstawie jednej technologii dla każdego projektu można opracować własne procesy uwzględniające jego cechy. Takie procesy w CMM nazywane są „procesami tworzenia oprogramowania zorientowanymi na projekt” (proces oprogramowania zdefiniowany przez projekt).

Opis każdego procesu obejmuje jego warunki wykonania, dane wejściowe, standardy i procedury wykonania, mechanizmy weryfikacji (np. przeglądy koleżeńskie), dane wyjściowe oraz warunki zakończenia. Opis procesu zawiera również informację o narzędziach wymaganych do jego wykonania oraz wskazanie roli odpowiedzialnej za jego wykonanie.

Głównym celem poziomu 4 (poziom zarządzanych procesów) jest bieżąca kontrola nad procesami. Kierownictwo musi zapewnić, że procesy są realizowane w ramach określonej jakości. Mogą wystąpić nieuniknione straty i chwilowe szczyty w zmierzonych wynikach, które wymagają interwencji, ale ogólnie system musi być stabilny.

Na poziomie 4 dodano następujące procesy:

zarządzanie wydajnością i produktywnością;

Ilościowe zarządzanie projektami.

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

W ramach całej organizacji opracowywany jest ujednolicony program do ilościowej kontroli wydajności tworzenia oprogramowania i jego jakości. Dla ułatwienia analizy procesów tworzona jest jedna baza procesów tworzenia i utrzymywania oprogramowania dla wszystkich projektów realizowanych w organizacji. Opracowywane są uniwersalne metody ujęcie ilościowe produktywność procesów i jakość ich realizacji. Pozwala to na wykonanie analiza ilościowa oraz ocena procesów tworzenia i utrzymania oprogramowania.

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

Głównym celem poziomu 5 (poziom zoptymalizowanych procesów) jest konsekwentne doskonalenie i unowocześnianie procesów tworzenia i utrzymywania oprogramowania. Na potrzeby planowanej modernizacji technologii tworzenia oprogramowania w organizacji powołuje się specjalną komórkę, której głównymi zadaniami są zbieranie danych o realizacji procesów, ich analiza, modernizacja istniejących i tworzenie nowych procesów oraz sprawdzanie ich pod kątem projekty pilotażowe i nadanie im statusu standardów korporacyjnych.

Na poziomie 5 dodaje się następujące procesy:

wprowadzanie innowacji technologicznych i organizacyjnych;

analiza przyczynowo-skutkowa i rozwiązywanie problemów. Procesy tworzenia i utrzymywania oprogramowania charakteryzują się

jako konsekwentnie doskonalone, gdyż organizacja podejmuje nieustanne starania w celu ich unowocześnienia. To ulepszenie obejmuje zarówno identyfikację dodatkowe funkcje stosowanych procesów, a także tworzenie nowych optymalnych procesów i wykorzystanie nowych technologii.

Innowacje, które mogą przynieść największe korzyści, są standaryzowane i dostosowywane do systemu technologicznego w całej organizacji. Personel zaangażowany w realizację projektu analizuje usterki i identyfikuje przyczyny ich wystąpienia. Procesy wytwarzania oprogramowania są poddawane ewaluacji, aby zapobiec powtarzaniu się sytuacji prowadzących do powstania defektów, a wyniki oceny są uwzględniane w kolejnych projektach.

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

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

Na drugim poziomie kontroluje się spełnianie wymagań użytkowników i tworzenie oprogramowania, ponieważ określa się podstawy procesów zarządzania projektami. Proces tworzenia oprogramowania można postrzegać jako sekwencję „czarnych skrzynek”, którymi można sterować w punktach przejścia z jednej „skrzynki” do drugiej – ustalone etapy. Nawet jeśli menedżer nie wie, co się dzieje „w pudełku”, to jest dokładnie ustalone, co powinno być wynikiem procesu, i określane są punkty kontrolne jego początku i końca. Dzięki temu kierownictwo może rozpoznawać problemy w punktach interakcji typu „czarna skrzynka” i reagować na nie w odpowiednim czasie.

Na trzecim poziomie definiowana jest wewnętrzna struktura „czarnych skrzynek”, tj. zadania, które składają się na procesy. Struktura wewnętrzna to sposób, w jaki standardowe procesy w organizacji są stosowane do konkretnych projektów. Łącze kierownicze i wykonawcy znają swoje role i obowiązki w ramach projektu na wymaganym poziomie szczegółowości. Kierownictwo jest z wyprzedzeniem przygotowane na ryzyka, które mogą wystąpić w trakcie realizacji projektu. Ponieważ wystandaryzowane i udokumentowane procesy stają się „przejrzyste” do wglądu, pracownicy, którzy nie są bezpośrednio zaangażowani w projekt, mogą na czas otrzymywać dokładne informacje o jego aktualnym stanie.

Na poziomie czwartym realizacja procesów jest ściśle powiązana z narzędziami, co umożliwia określenie ilościowych charakterystyk ich pracochłonności i jakości wykonania. Menedżerowie, mając obiektywną bazę pomiarów ilościowych, otrzymują możliwość dokładnego zaplanowania etapów i etapów projektu, przewidywania przebiegu projektu oraz mogą szybko i adekwatnie reagować na pojawiające się problemy. Wraz z redukcją ewentualnych odchyleń od zadanych terminów, kosztów i jakości w procesie realizacji projektów, ich zdolność przewidywania rezultatów stale wzrasta.

Na poziomie piątym, w celu poprawy jakości produktów i zwiększenia efektywności ich tworzenia, stale i systematycznie prowadzone są prace nad tworzeniem nowych udoskonalonych metod i technologii tworzenia oprogramowania. Zwraca się uwagę nie tylko na już stosowane, ale także na nowe, wydajniejsze procesy i technologie. Menedżerowie mogą określić ilościowo wpływ i skuteczność zmian w technologii rozwoju i utrzymania oprogramowania.

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

Osiągnięcie najwyższego poziomu SMM zajmuje dziesięć lat lub więcej. Ale nawet poziom 3 pozwala odważnie wejść na arenę międzynarodową. Aby skorzystać z SMM, firma nie musi szukać pracowników o jakichś unikalnych zdolnościach, wystarczy, że zrozumie ogólną ideę. Opis modelu CMM szczegółowo określa, co należy zrobić, aby rozwijać się zgodnie z tym modelem. Każdy menedżer z klasy średniej jest w stanie śledzić regulowane działania CMM.

Najnowsza wersja SMM 1.1 koncentruje się głównie na duże firmy, zaangażowanych w realizację dużych projektów, ale może być również wykorzystywany przez dwu-, trzyosobowe grupy lub indywidualnych programistów do realizacji małych projektów (do trzech miesięcy). W takich przypadkach model HMM może odegrać kluczową rolę. ważna rola, gdyż o otrzymaniu nowych zleceń w dużej mierze decyduje jakość realizacji dotychczasowych projektów. Małe grupy będą całkiem zadowolone z poziomu 2, ponieważ dla małego projektu odstępstwo od terminu kilku tygodni nie ma znaczenia.

Od 2002 roku oficjalnie dystrybuowana jest specjalna wersja integracyjna CMMI. Ten nowy rozwój SEI, obejmujące wszystkie aspekty działalności firmy: od opracowania i wyboru wykonawcy po szkolenia, wdrożenie i utrzymanie. Ponadto model CMMI został rozszerzony o podejścia z inżynierii systemów. Model ten obejmuje zmiany dokonane podczas projektowania wersji CMM 2.0 (nie została ukończona), której główne zmiany miały na celu wyjaśnienie procesów dla firm czwartego i piątego poziomu, co jest najbardziej istotne dla amerykańskich projektów na dużą skalę.

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

Wady SMM obejmują:

1. Model koncentruje się wyłącznie na zarządzaniu projektami, a nie na procesie tworzenia oprogramowania. Model nie uwzględnia tak ważnych czynników, jak stosowanie niektórych metod, takich jak prototypowanie, formalne i metody strukturalne, narzędzia do analizy statycznej itp.

2. W modelu brakuje analizy ryzyka i decyzji, co uniemożliwia wykrycie problemów, zanim wpłyną one na proces rozwoju.

3. Nie określono zakresu modelu, choć autorzy uznają, że jest on uniwersalny i odpowiedni dla wszystkich organizacji. Autorzy nie dokonują jednak wyraźnego rozróżnienia między organizacjami, które mogą lub nie mogą wdrażać SMM w swojej działalności. Małe firmy uważają ten model za zbyt biurokratyczny. W odpowiedzi na tę krytykę opracowano strategie doskonalenia procesów dla małych organizacji.

główny cel Tworząc model CMM, intencją Departamentu Obrony USA była ocena możliwości dostawców oprogramowania. NA ten moment natomiast nie ma jednoznacznych wymagań dla osiągnięcia określonego poziomu rozwoju organizacji rozwojowych. Powszechnie jednak przyjmuje się, że organizacja, która osiągnęła wysoki poziom, ma większe szanse na wygranie przetargu na dostawę oprogramowania. Jako alternatywę dla CMM proponuje się uogólnioną klasyfikację procesów doskonalenia dojrzałości technologicznej, która jest odpowiednia dla większości organizacji i projektów oprogramowania. Można wyróżnić kilka powszeche typy procesy doskonalenia.

1. proces nieformalny. Nie ma jasno określonego modelu doskonalenia. Z powodzeniem może być używany przez odrębny zespół programistów

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

2. Zarządzany proces. Ma przygotowany model, który kieruje procesem doskonalenia. Model definiuje działania, ich harmonogram i relacje między nimi.

3. Metodycznie rozsądny proces. Zakłada się, że pewne metody zostały wprowadzone (np. systematycznie stosowane są metody projektowania zorientowanego obiektowo). Dla tego typu procesów przydatne będą narzędzia wspomagające projektowanie i analizę procesów (CASE-tools).

4. Proces bezpośredniego doskonalenia. Ma jasno określony cel doskonalenia procesu technologicznego, na który przewidziana jest odrębna pozycja w budżecie organizacji oraz określone są normy i procedury wprowadzania innowacji. Częścią takiego procesu jest ilościowa analiza procesu doskonalenia.

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

Potrzeba tej klasyfikacji wynika z faktu, że stanowi ona podstawę do kompleksowego doskonalenia technologii wytwarzania oprogramowania i umożliwia organizacji wybór różnych typów procesów doskonalenia. na ryc. 1.8 pokazuje związek między różne rodzaje systemów oprogramowania i procesów usprawniających ich rozwój.

Ryż. 1.8. Stosowalność procesów doskonalenia

Znajomość rodzaju opracowywanego produktu sprawi, że zgodność między systemami oprogramowania a procesami doskonalenia pokazana na ryc. 1.8 przydatne w wyborze doskonalenia procesu. Na przykład musisz stworzyć program wspierający przejście oprogramowania z jednej platformy komputerowej na inną. Taki program ma dość krótki czas życia, więc jego rozwój nie wymaga standardów i specjalnego zarządzania procesem doskonalenia, jak przy tworzeniu systemów długowiecznych.

Wiele przepływów pracy ma teraz obsługę CASE, więc można je wywoływać obsługiwane procesy. Metodyczne procesy są wspierane przez narzędzia analityczne i projektowe. Skuteczność narzędzia wsparcia zależy od zastosowanego procesu doskonalenia. Na przykład w procesie nieformalnym można zastosować typowe narzędzia pomocnicze (narzędzia do prototypowania, kompilatory, narzędzia do debugowania, edytory tekstu itp.). Jest mało prawdopodobne, aby bardziej wyspecjalizowane narzędzia wsparcia były stosowane na bieżąco w procesach nieformalnych.

Model SMM nie jest unikalny. Niemal każda duża firma opracowuje własne technologie tworzenia oprogramowania, czasami technologie te stają się publiczne i bardzo popularne. Szeroka popularność modelu HMM jest z nim związana wsparcie państwa, ale rzeczywista skuteczność SMM jest krytykowana przez wielu czołowych ekspertów. Jedna z głównych wad HMM wiąże się z niepotrzebnie sztywnym wymogiem nieodchodzenia od zasad tego modelu, nawet jeśli zdrowy rozsądek sugeruje coś przeciwnego. Takie pretensje do posiadania prawdy absolutnej nie mogą nie budzić podejrzeń, dlatego wśród małych i średnich firm bardziej popularne są podejścia, które pozostawiają znacznie więcej swobody indywidualnej i zbiorowej kreatywności. Rozważana poniżej technika SPMN zajmuje pozycję pośrednią między sztywną, „ciężką”, skuteczną dla duże organizacje rozwiązania takie jak SMM i najbardziej elastyczne technologie. Pojawia się najlepsza opcja dla firm, które z jednej strony chcą jak najszybciej usprawnić swoje działania zarządcze, az drugiej planują w przyszłości wejść na poziom międzynarodowy, gdzie certyfikacja CMM jest wysoce pożądana.

W listopadzie 1986 roku American Software Engineering Institute (SEI) we współpracy z Mitre Corporation rozpoczął opracowywanie przeglądu dojrzałości procesu tworzenia oprogramowania, który miał pomóc w ulepszeniu ich procesów wewnętrznych.

Opracowanie tego przeglądu zostało poproszone przez rząd federalny USA o metodę oceny podwykonawców do tworzenia oprogramowania. Prawdziwym problemem była niezdolność do zarządzania duże projekty. W wielu firmach projekty były dostarczane z dużym opóźnieniem i przekraczały budżet. Konieczne było znalezienie rozwiązania tego problemu.

We wrześniu 1987 SEI wydany krótka recenzja procesów tworzenia oprogramowania wraz z opisem ich poziomów dojrzałości, a także ankietę mającą na celu zidentyfikowanie obszarów w firmie, w których potrzebne są 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, czyli Capability Maturity Model for Software (CMM). Pierwsza wersja CMM (wersja 1.0), wydana w 1991 r., została poprawiona w 1992 r. przez uczestników spotkania roboczego, w którym wzięło udział około 200 programistów oraz członków stowarzyszenia programistów.

1. Podstawowy. Najbardziej prymitywny status organizacji. Organizacja jest zdolna do tworzenia oprogramowania. Organizacja nie posiada jawnie świadomego procesu, a jakość produktu jest w całości zdeterminowana indywidualnymi zdolnościami twórców. Jeden przejmuje inicjatywę, a zespół postępuje zgodnie z jego instrukcjami. Sukces jednego projektu nie gwarantuje sukcesu drugiego. Na koniec projektu dane dotyczące kosztów pracy, harmonogramu i jakości nie są rejestrowane.
2. powtarzalne. W pewnym stopniu proces ten jest monitorowany. Prowadzone są ewidencje kosztów i planów pracy. Funkcjonalność każdego projektu jest opisana pisemnie. W połowie 1999 r. tylko 20% organizacji miało poziom 2 lub wyższy.
3. Zainstalowane. Mieć określony, udokumentowany i ustalony proces praca niezależna od osób fizycznych. To znaczy zgoda profesjonalne standardy, a programiści je wdrażają. Takie organizacje są w stanie dość wiarygodnie przewidzieć koszty projektów podobnych do tych zrealizowanych wcześniej.
4. Zarządzany. Potrafią dokładnie przewidzieć czas i koszt prac. Istnieje baza danych zgromadzonych pomiarów. Ale nie ma zmian wraz z pojawieniem się nowych technologii i paradygmatów.
5. Zoptymalizowany. Istnieje ciągła procedura poszukiwania i doskonalenia nowych i udoskonalonych 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 usprawnienia procesu rozwojowego, tzw CMMI (integracja modelu dojrzałości zdolności). Obecnie najnowsza wersja CMMi to 1.3 (opublikowana w listopadzie 2010).

Zobacz też

Spinki do mankietów

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

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

Rozwiązałem wszystkie moduły, zdałem wszystko 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ź, nie ręczę za poprawność.Wystawiam wszystko co mam, może ktoś zda to lepiej ode mnie. Jeśli ktoś ma drugą, trzecią próbę, postaw, jeśli nie masz nic przeciwko, dyscyplinę, naprawdę bardzo trudne. :eek:

Test końcowy 100 na 100

Czy za każdym razem wynik jest inny?

Więcej pytań, które nie są tutaj wymienione i mnie złapały. Nie szukałem odpowiedzi, bo bez tego zdałem 4. Kto chce się pomylić, wrzuca odpowiedzi tutaj dla reszty 🙂

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

Wartość dodana

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

Wybierz jedną odpowiedź:

W finale (przeszedł 4.

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

Te pytania + te już na forum):
1. Wybierz poprawne stwierdzenie.
Wybierz jedną odpowiedź:
Proces biznesowy oddziałów składa się z różnych łańcuchów wartości (NIEPEWNOŚĆ)
Kompleksowy proces biznesowy składa się z procesów biznesowych różnych organizacji
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
Ryzyka
Działania związane z zarządzaniem procesami biznesowymi
Czynniki środowiskowe
Aktywność polegająca na konwersji wejść na wyjścia

3. Zasoby materialne jako podstawowy element procesów są:
Wybierz jedną odpowiedź:
Aktywne podmioty działania zjednoczone w systemach oddziałujących na siebie i inne zasoby
Działania kontrolne kierowane przez podmioty działalności na przedmioty działalności, które określają cele i wyniki procesów
Obiekty i czynności pasywne wykorzystywane do przeprowadzania procesów (NIE JESTEM PEWNY)

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
Tworzenie wartości dodatkowej i/lub użytkowej

Wyniki jako podstawowe elementy procesów to:
Wybierz jedną odpowiedź:
Aktywne podmioty działania zjednoczone w systemach oddziałujących na siebie i inne zasoby
Produkt procesu, który zawiera wcześniej ustalone cele Pasywne obiekty 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ź:
Celowe i świadome oddziaływanie na proces, mające na celu zapewnienie pożądanego rezultatu
Analiza i porównanie wyników procesu z wcześniej ustalonymi celami
Oddziaływanie na system obiektów i czynników otoczenia, które są źródłami 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 wady projektowanych struktur docelowych.

2 Wybierz przykłady użycia poleceń z listy.
Wysokiej jakości kubki
Komitety
Zespoły robocze

3 Wybierz z listy warunki zastosowania organicznych struktur organizacyjnych.
Pracowników motywują złożone potrzeby
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 wysiłków tych pracowników

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

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

Wysokiej jakości kubki
Komitety
Zespoły robocze

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

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

pytanie 3
Nazwij typy relacji w modelu SADT:
Kontrola
mechanizm wyjścia
Informacja zwrotna przy wejściu

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 Chena i Barkera

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

Operacje procesów biznesowych

Pytanie 7
Długość procesu biznesowego:

Jest subiektywny

Pytanie 8
Zasoby materialne jako podstawowy element procesów to:

Pasywne środki i przedmioty działania służące do przeprowadzania procesów

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

Realizowane jest bezpośrednie podporządkowanie pracowników kierownikowi projektu, a tym samym uzyskiwana jest jednoznaczność kierunku wysiłków tych pracowników

Pytanie 10
Wybierz z listy zalety macierzowych struktur organizacyjnych.

Istnieje możliwość elastycznego „dopasowania” struktury organizacyjnej w szerokim zakresie: od słabej do silnej matrycy

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

Podsystem sterowania pracą
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?

Średni do wysokiego

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

Inwestorzy
Pożyczkodawcy

Pytanie 16
Wybierz z listy wady projektowanych konstrukcji docelowych.

Zmniejszona zdolność produkcyjna w obszarach funkcjonalnych

Systemy sterowania Modeling.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óż 3szkoleniu, kto to ma, plz

Dodano po 1 minucie
Proszę o 3 szkolenia od każdego kto ma modelowanie układów sterowania

vBulletin® v3.8.7, prawa autorskie 2000-2018, vBulletin Solutions, Inc.

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

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

W 1991 roku Instytut Inżynierii Oprogramowania Uczelni

Carnegie Mellon (Software Engineering Institute, SEI) stworzył model dojrzałości CMM (Capability Maturity Model) do opracowywania oprogramowania. Z biegiem czasu została wydana cała rodzina modeli:

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

Różnorodność modeli okazała się dość trudna do zrozumienia i wdrożenia. Odkąd zostały stworzone różne grupy specjalistów, treść tych modeli nie zawsze była zgodna ze sobą, 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) doskonalenia procesów w organizacjach różnej wielkości i o różnej działalności. CMMI wyróżnia następujące grupy obszarów doskonalenia: zarządzanie procesami, zarządzanie projektami, obszary inżynierii, serwis

obszary. W tym przypadku wszystkie obszary są określone w formie wymagań, które określają nie sposób ich implementacji, ale wymagania interfejsu. Wynikają z tego dwie konsekwencje.

Konsekwencja 1. CMMI pozwala na różne implementacje i nie jest metodologią tworzenia oprogramowania jak MSF, Scrum, RUP itp. Ta ostatnia może być wykorzystana w jej implementacji. Na przykład istnieje specjalny szablon procesu w VSTS dla CMMI 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-tych i 90-tych, CMM (wówczas jeszcze nie CMMI) powstawała właśnie jako środek certyfikacji

federalni podwykonawcy. I dopiero później, po rozpowszechnieniu się na świecie, zaczął być używany, a następnie skupiony na ulepszaniu procesów. Odnotowujemy jeszcze jedno ważna cecha CMMI. Jest przeznaczony nie tylko do tworzenia systemów oprogramowania. Wiele dużych firm nie wydaje oprogramowania, ale dostarcza produkty, których integralną częścią jest oprogramowanie.

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

występuje wraz z pracami inżynierskimi innego typu. A często zdarza się, że w jednym projekcie bierze udział więcej niż dwie osoby. różnego rodzaju Inżynieria. Zadaniem CMMI jest zapewnienie takim projektom i firmom jednej platformy do organizacji procesu deweloperskiego.

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

taki sam jak we CMM i ciągły, pozwalający w pewnym stopniu na dowolne doskonalenie procesów w organizacji. Tutaj skupimy się na modelu sekwencyjnym. 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) - tu już pojawiają się polityki i procedury organizacji procesów zatwierdzone na poziomie firmy. Ale pełny zakres procesów istnieje tylko w ramach pojedynczych 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)? Co to są poziomy CMM?

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

modele cyklu życia, narzędzia oprogramowania, praktyki itp. Każdy określony proces uzyskuje się poprzez odcięcie od tego standardu.

Poziom ilościowy(poziom dojrzałości 4) implikuje powstanie w przedsiębiorstwie systemu miar, które odbywają się w oparciu o standardowy proces i pozwalają na ilościowe zarządzanie rozwojem.

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

Wiele osób zna skrót CMMI, wiele osób wie, że jest to model, tj. 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 jest rzeczywiście pod wieloma względami powiązany z działalnością firm programistycznych (to znaczy tych firm i organizacji, które opracowują i dostarczają określone oprogramowanie 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 przy znikomym udziale rozwoju w całkowitych kosztach pracy lub w ogóle bez kosztów pracy)? Dla nich jest też zestaw rekomendacji – model CMMI for Services (CMMI-SVC). Na przykład dla działów IT ten model (a dokładniej jego zalecenia) może pomóc zrozumieć, co należy zrobić, aby np. 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 też usługa).

Jednak każdy z wymienionych modeli jest lepszy do nauczenia się. A jeśli jest kilkaset osób przeszkolonych w modelu CMMI-DEV dla całego WNP (około 250-300 osób), to w WNP 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: w przypadku CMMI-DEV na całym świecie był tylko jeden rosyjskojęzyczny instruktor certyfikowany przez SEI (programista modeli CMMI), aw przypadku innych modeli nie było ich wcale! Teraz pojawił się też taki instruktor według modelu CMMI-SVC (stąd pierwszych 6 przeszkolonych). Ten instruktor jest autorem tej publikacji i jest dostępny, aby odpowiedzieć na wszelkie pytania dotyczące wspomnianych modeli i formalnego szkolenia. Zapytać!

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