Zarządzanie jakością oprogramowania - krótki przewodnik

Oprogramowanie wysokiej jakości odnosi się do oprogramowania, które jest wolne od błędów lub defektów, jest dostarczane na czas iw określonym budżecie, spełnia wymagania i / lub oczekiwania oraz jest możliwe do utrzymania. W kontekście inżynierii oprogramowania jakość oprogramowania odzwierciedla jedno i drugiefunctional quality jak również structural quality.

  • Software Functional Quality - Odzwierciedla, jak dobrze spełnia dany projekt, w oparciu o wymagania funkcjonalne lub specyfikacje.

  • Software Structural Quality - Zajmuje się obsługą wymagań niefunkcjonalnych, które wspierają spełnienie wymagań funkcjonalnych, takich jak solidność lub łatwość konserwacji oraz stopień, w jakim oprogramowanie zostało wyprodukowane poprawnie.

  • Software Quality Assurance- Software Quality Assurance (SQA) to zestaw działań mających na celu zapewnienie jakości w procesach inżynierii oprogramowania, które ostatecznie prowadzą do wysokiej jakości produktów oprogramowania. Działania ustanawiają i oceniają procesy, które wytwarzają produkty. Obejmuje działanie skoncentrowane na procesie.

  • Software Quality Control- Kontrola jakości oprogramowania (SQC) to zestaw działań mających na celu zapewnienie jakości oprogramowania. Działania te koncentrują się na określeniu wad faktycznie wytworzonych produktów. Obejmuje działanie skoncentrowane na produkcie.

Wyzwanie dotyczące jakości oprogramowania

W branży oprogramowania programiści nigdy nie zadeklarują, że oprogramowanie jest wolne od wad, w przeciwieństwie do innych producentów produktów przemysłowych. Ta różnica wynika z następujących powodów.

Złożoność produktu

Jest to liczba trybów pracy, na które pozwala produkt. Zwykle produkt przemysłowy umożliwia tylko mniej niż kilka tysięcy trybów pracy przy różnych kombinacjach ustawień maszyny. Jednak pakiety oprogramowania zapewniają miliony możliwości operacyjnych. Dlatego też zapewnienie wszystkich tych możliwości operacyjnych w prawidłowy sposób jest głównym wyzwaniem dla branży oprogramowania.

Widoczność produktu

Ponieważ produkty przemysłowe są widoczne, większość jego wad można wykryć podczas procesu produkcyjnego. Również brak części w produkcie przemysłowym można łatwo wykryć w produkcie. Jednak wady oprogramowania, które jest przechowywane na dyskietkach lub dyskach CD, są niewidoczne.

Rozwój produktu i proces produkcyjny

W produkcie przemysłowym wady można wykryć w następujących fazach -

  • Product development - Na tym etapie projektanci i pracownicy działu zapewnienia jakości (QA) sprawdzają i testują prototyp produktu w celu wykrycia jego wad.

  • Product production planning- Na tym etapie proces produkcji i narzędzia są projektowane i przygotowywane. Ta faza zapewnia również możliwość sprawdzenia produktu w celu wykrycia wad, które pozostały niezauważone w fazie rozwoju.

  • Manufacturing- Na tym etapie procedury zapewniania jakości są stosowane do wykrywania awarii samych produktów. Wady produktu wykryte w pierwszym okresie wytwarzania można zwykle skorygować poprzez zmianę konstrukcji produktu, materiałów lub narzędzi produkcyjnych w sposób eliminujący takie wady w produkowanych w przyszłości produktach.

Jednak w przypadku oprogramowania jedyną fazą, w której można wykryć defekty, jest faza rozwoju. W przypadku oprogramowania planowanie produkcji i fazy produkcyjne nie są wymagane, ponieważ tworzenie kopii oprogramowania i drukowanie instrukcji oprogramowania odbywa się automatycznie.

W poniższej tabeli przedstawiono czynniki wpływające na wykrywanie defektów w oprogramowaniu w porównaniu z innymi produktami przemysłowymi.

Charakterystyka Oprogramowanie Inne produkty przemysłowe
Złożoność Miliony opcji operacyjnych tysiące opcji operacyjnych
widoczność produktu Produkt niewidoczny Trudno jest wykryć wady wzrokiem Widoczny produkt Skuteczne wykrywanie wad wzrokiem
Charakter rozwoju i procesu produkcyjnego może uszkodzić wady tylko w jednej fazie może wykryć usterki we wszystkich następujących fazach
  • Rozwój produktu
  • Planowanie produkcji produktów
  • Manufacturing

Te cechy oprogramowania, takie jak złożoność i niewidoczność, sprawiają, że opracowanie metodologii zapewniania jakości oprogramowania i jej pomyślne wdrożenie jest wysoce profesjonalnym wyzwaniem.

Różne czynniki wpływające na oprogramowanie nazywane są czynnikami oprogramowania. Można je ogólnie podzielić na dwie kategorie. Pierwsza kategoria czynników to czynniki, które można zmierzyć bezpośrednio, takie jak liczba błędów logicznych, a druga kategoria obejmuje czynniki, które można zmierzyć tylko pośrednio. Na przykład łatwość konserwacji, ale każdy z czynników ma być zmierzony, aby sprawdzić zawartość i kontrolę jakości.

Na przestrzeni lat zaproponowano kilka modeli czynników jakości oprogramowania i ich kategoryzacji. Klasyczny model czynników jakości oprogramowania, zaproponowany przez McCall, składa się z 11 czynników (McCall i in., 1977). Podobnie modele składające się z 12 do 15 czynników zostały zaproponowane przez Deutscha i Willisa (1988) oraz Evansa i Marciniaka (1987).

Wszystkie te modele nie różnią się zasadniczo od modelu McCall. Model czynnikowy McCalla zapewnia praktyczną, aktualną metodę klasyfikacji wymagań programowych (Pressman, 2000).

Model czynnikowy McCalla

Model ten klasyfikuje wszystkie wymagania oprogramowania na 11 czynników jakości oprogramowania. Te 11 czynników jest podzielonych na trzy kategorie - działanie produktu, rewizja produktu i czynniki przejścia produktu.

  • Product operation factors - Poprawność, niezawodność, wydajność, integralność, użyteczność.

  • Product revision factors - Konserwowalność, elastyczność, testowalność.

  • Product transition factors - Przenośność, możliwość ponownego użycia, interoperacyjność.

Czynniki jakości oprogramowania operacyjnego produktu

Zgodnie z modelem McCall kategoria działania produktu obejmuje pięć czynników jakości oprogramowania, które dotyczą wymagań, które mają bezpośredni wpływ na codzienne działanie oprogramowania. Są następujące -

Poprawność

Wymagania te dotyczą poprawności danych wyjściowych systemu oprogramowania. Obejmują one -

  • Misja wyjściowa

  • Wymagana dokładność wyników, na którą mogą mieć negatywny wpływ niedokładne dane lub niedokładne obliczenia.

  • Kompletność informacji wyjściowych, na którą mogą mieć wpływ niekompletne dane.

  • Aktualność informacji zdefiniowana jako czas między zdarzeniem a odpowiedzią systemu oprogramowania.

  • Dostępność informacji.

  • Standardy kodowania i dokumentowania systemu oprogramowania.

Niezawodność

Wymagania dotyczące niezawodności dotyczą awarii usługi. Określają maksymalną dopuszczalną awaryjność systemu oprogramowania i mogą odnosić się do całego systemu lub do jednej lub więcej jego oddzielnych funkcji.

Wydajność

Zajmuje się zasobami sprzętowymi potrzebnymi do wykonywania różnych funkcji systemu oprogramowania. Obejmuje możliwości przetwarzania (podane w MHz), jego pojemność (podaną w MB lub GB) oraz zdolność przesyłania danych (podaną w MBPS lub GBPS).

Dotyczy również czasu pomiędzy doładowaniami jednostek przenośnych systemu, takich jak jednostki systemu informatycznego umieszczone w komputerach przenośnych lub jednostki meteorologiczne umieszczone na zewnątrz.

Integralność

Czynnik ten dotyczy bezpieczeństwa systemu oprogramowania, czyli uniemożliwienia dostępu osobom nieupoważnionym, a także rozróżnienia między grupą osób, które mają otrzymać pozwolenie na odczyt i zapis.

Użyteczność

Wymagania dotyczące użyteczności dotyczą zasobów kadrowych potrzebnych do przeszkolenia nowego pracownika i obsługi systemu oprogramowania.

Czynniki jakościowe rewizji produktu

Zgodnie z modelem McCall, kategoria wersji produktu obejmuje trzy czynniki jakości oprogramowania. Czynniki te są następujące -

Konserwowalność

Czynnik ten uwzględnia wysiłki, które będą potrzebne dla użytkowników i personelu konserwacyjnego, aby zidentyfikować przyczyny awarii oprogramowania, naprawić awarie i zweryfikować powodzenie poprawek.

Elastyczność

Czynnik ten dotyczy możliwości i wysiłków wymaganych do wspierania działań związanych z konserwacją adaptacyjną oprogramowania. Obejmują one dostosowanie obecnego oprogramowania do dodatkowych okoliczności i klientów bez zmiany oprogramowania. Wymogi tego czynnika wspierają również perfekcyjne czynności konserwacyjne, takie jak zmiany i dodatki do oprogramowania w celu usprawnienia jego obsługi i dostosowania go do zmian w środowisku technicznym lub handlowym firmy.

Testowalność

Wymagania testowalności dotyczą testowania systemu oprogramowania, a także jego działania. Zawiera predefiniowane wyniki pośrednie, pliki dziennika, a także automatyczną diagnostykę wykonywaną przez system oprogramowania przed uruchomieniem systemu, aby dowiedzieć się, czy wszystkie elementy systemu są sprawne i uzyskać raport o wykrytych usterkach. Inny rodzaj tych wymagań dotyczy automatycznych testów diagnostycznych stosowanych przez techników utrzymania ruchu w celu wykrycia przyczyn awarii oprogramowania.

Współczynnik jakości oprogramowania zmiany produktu

Zgodnie z modelem McCall trzy czynniki jakości oprogramowania są zawarte w kategorii przejścia produktu, która dotyczy adaptacji oprogramowania do innych środowisk i jego interakcji z innymi systemami oprogramowania. Czynniki te są następujące -

Ruchliwość

Wymagania dotyczące przenośności mają tendencję do dostosowywania systemu oprogramowania do innych środowisk składających się z innego sprzętu, różnych systemów operacyjnych i tak dalej. Oprogramowanie powinno umożliwiać dalsze korzystanie z tego samego oprogramowania podstawowego w różnych sytuacjach.

Możliwość ponownego użycia

Czynnik ten dotyczy wykorzystania modułów oprogramowania pierwotnie zaprojektowanych dla jednego projektu w obecnie opracowywanym nowym projekcie oprogramowania. Mogą także umożliwić przyszłym projektom wykorzystanie danego modułu lub grupy modułów aktualnie tworzonego oprogramowania. Oczekuje się, że ponowne użycie oprogramowania pozwoli zaoszczędzić zasoby programistyczne, skrócić okres opracowywania i zapewnić moduły o wyższej jakości.

Interoperacyjność

Wymagania dotyczące interoperacyjności koncentrują się na tworzeniu interfejsów z innymi systemami oprogramowania lub z innym oprogramowaniem sprzętowym. Na przykład oprogramowanie sprzętowe maszyn produkcyjnych i wyposażenia testującego łączy się z oprogramowaniem sterującym produkcją.

Software Quality Assurance(SQA) to zbiór działań mających na celu zapewnienie jakości w procesach inżynierii oprogramowania. Zapewnia, że ​​opracowane oprogramowanie spełnia określone lub znormalizowane specyfikacje jakościowe i jest z nimi zgodne. SQA to ciągły proces w ramach cyklu życia oprogramowania (SDLC), który rutynowo sprawdza opracowane oprogramowanie, aby upewnić się, że spełnia wymagane mierniki jakości.

Praktyki SQA są wdrażane w większości typów tworzenia oprogramowania, niezależnie od używanego podstawowego modelu tworzenia oprogramowania. SQA obejmuje i wdraża metodologie testowania oprogramowania w celu testowania oprogramowania. Zamiast sprawdzać jakość po zakończeniu, procesy SQA testują jakość na każdym etapie rozwoju, aż do ukończenia oprogramowania. Dzięki SQA proces tworzenia oprogramowania przechodzi do następnej fazy tylko wtedy, gdy bieżąca / poprzednia faza spełnia wymagane standardy jakości. SQA generalnie działa na jednym lub kilku standardach branżowych, które pomagają w tworzeniu wytycznych dotyczących jakości oprogramowania i strategii wdrażania.

Obejmuje następujące działania -

  • Definicja i wdrożenie procesu
  • Auditing
  • Training

Procesy mogą być -

  • Metodologia tworzenia oprogramowania
  • Zarządzanie projektami
  • Zarządzanie konfiguracją
  • Opracowywanie / zarządzanie wymaganiami
  • Estimation
  • Projektowanie Oprogramowania
  • Testowanie itp.

Po zdefiniowaniu i wdrożeniu procesów zapewnianie jakości ma następujące obowiązki:

  • Zidentyfikuj słabości procesów
  • Popraw te słabości, aby stale ulepszać proces

Elementy systemu SQA

System SQA zawsze łączy w sobie szeroką gamę komponentów SQA. Te komponenty można podzielić na sześć następujących klas -

Komponenty przedprojektowe

Gwarantuje to, że zobowiązania projektowe zostały jasno określone, biorąc pod uwagę wymagane zasoby, harmonogram i budżet; a plany rozwoju i jakości zostały prawidłowo określone.

Składowe oceny działań w cyklu życia projektu

Cykl życia projektu składa się z dwóch etapów: etapu cyklu rozwojowego oraz etapu eksploatacji i utrzymania.

Komponenty etapu cyklu rozwojowego wykrywają błędy projektowe i programistyczne. Jego komponenty są podzielone na następujące podklasy: recenzje, opinie ekspertów i testy oprogramowania.

Komponenty SQA używane na etapie eksploatacji i utrzymania obejmują wyspecjalizowane komponenty utrzymania, jak również komponenty cyklu rozwojowego, które są stosowane głównie w celu usprawnienia zadań konserwacyjnych.

Komponenty zapobiegania błędom infrastruktury i poprawy

Głównym celem tych komponentów, stosowanym w całej organizacji, jest wyeliminowanie lub przynajmniej zmniejszenie wskaźnika błędów, w oparciu o zgromadzone doświadczenie organizacji w zakresie SQA.

Elementy zarządzania jakością oprogramowania

Ta klasa komponentów ma kilka celów, takich jak kontrola działań rozwojowych i konserwacyjnych oraz wprowadzenie wczesnych działań wspierających kierownictwo, które głównie zapobiegają lub minimalizują awarie harmonogramu i budżetu oraz ich skutki.

Elementy normalizacji, certyfikacji i oceny systemu SQA

Komponenty te wdrażają międzynarodowe standardy zawodowe i menedżerskie w organizacji. Głównymi celami tej klasy jest wykorzystanie międzynarodowej wiedzy zawodowej, usprawnienie koordynacji systemów jakości organizacji z innymi organizacjami oraz ocena osiągnięć systemów jakości według wspólnej skali. Poszczególne standardy można podzielić na dwie główne grupy: standardy zarządzania jakością i standardy procesu projektowego.

Organizacja dla SQA - komponenty ludzkie

Baza organizacyjna SQA obejmuje menedżerów, personel testujący, jednostkę SQA oraz osoby zainteresowane jakością oprogramowania, takie jak powiernicy SQA, członkowie komitetów SQA i członkowie forum SQA. Ich głównym celem jest inicjowanie i wspieranie wdrażania komponentów SQA, wykrywanie odstępstw od procedur i metodologii SQA oraz sugerowanie ulepszeń.

Przedprojektowe komponenty jakości oprogramowania

Te komponenty pomagają ulepszyć wstępne kroki podjęte przed rozpoczęciem projektu. Obejmuje -

  • Przegląd kontraktu
  • Plany rozwoju i jakości

Przegląd kontraktu

Zwykle oprogramowanie jest opracowywane na potrzeby umowy negocjowanej z klientem lub na wewnętrzne zamówienie opracowania oprogramowania układowego do wbudowania w produkt sprzętowy. We wszystkich tych przypadkach dział rozwoju jest zobowiązany do przestrzegania uzgodnionej specyfikacji funkcjonalnej, budżetu i harmonogramu. W związku z tym czynności związane z przeglądem umowy muszą obejmować szczegółowe badanie projektu propozycji projektu i wersji roboczych umowy.

W szczególności czynności związane z przeglądem umowy obejmują -

  • Wyjaśnienie wymagań klienta

  • Przegląd harmonogramu projektu i szacunków zapotrzebowania na zasoby

  • Ocena zdolności profesjonalnej kadry do realizacji proponowanego projektu

  • Ocena zdolności klienta do wypełnienia swoich zobowiązań

  • Ocena ryzyk rozwojowych

Plany rozwoju i jakości

Po podpisaniu umowy na rozwój oprogramowania z organizacją lub działem wewnętrznym tej samej organizacji, przygotowywany jest plan rozwoju projektu i jego zintegrowanych działań w zakresie zapewnienia jakości. Plany te zawierają dodatkowe szczegóły i potrzebne poprawki na podstawie wcześniejszych planów, które stanowiły podstawę dla aktualnej oferty i kontraktu.

Od złożenia oferty do podpisania umowy mija najczęściej kilka miesięcy. W tym okresie zasoby, takie jak dostępność personelu, możliwości zawodowe, mogą ulec zmianie. Plany są następnie korygowane w celu odzwierciedlenia zmian, które zaszły w międzyczasie.

Główne kwestie uwzględnione w planie rozwoju projektu to:

  • Schedules
  • Wymagane zasoby ludzkie i sprzętowe
  • Oceny ryzyka
  • Kwestie organizacyjne: członkowie zespołu, podwykonawcy i partnerstwa
  • Metodologia projektu, narzędzia programistyczne itp.
  • Plany ponownego wykorzystania oprogramowania

Główne kwestie uwzględnione w planie jakości projektu to:

  • Cele jakościowe, wyrażone w odpowiednich mierzalnych kategoriach

  • Kryteria rozpoczęcia i zakończenia każdego etapu projektu

  • Listy przeglądów, testów i innych zaplanowanych działań weryfikacyjnych i walidacyjnych

Metryki oprogramowania można podzielić na trzy kategorie -

  • Product metrics - Opisuje cechy produktu, takie jak rozmiar, złożoność, cechy konstrukcyjne, wydajność i poziom jakości.

  • Process metrics - Te cechy można wykorzystać do usprawnienia działań związanych z rozwojem i utrzymaniem oprogramowania.

  • Project metrics- Te metryki opisują charakterystykę i wykonanie projektu. Przykłady obejmują liczbę programistów, schemat zatrudnienia w całym cyklu życia oprogramowania, koszt, harmonogram i produktywność.

Niektóre metryki należą do wielu kategorii. Na przykład metryki jakości projektu w toku to zarówno metryki procesu, jak i metryki projektu.

Software quality metricsto podzbiór metryk oprogramowania, które koncentrują się na aspektach jakości produktu, procesu i projektu. Są one ściślej związane z metrykami procesu i produktu niż z metrykami projektu.

Wskaźniki jakości oprogramowania można dalej podzielić na trzy kategorie -

  • Wskaźniki jakości produktu
  • Wskaźniki jakości w procesie
  • Wskaźniki jakości utrzymania

Wskaźniki jakości produktu

Te dane obejmują:

  • Średni czas do awarii
  • Gęstość defektów
  • Problemy klientów
  • Satysfakcja konsumenta

Średni czas do awarii

To czas między awariami. Ta metryka jest najczęściej używana w systemach krytycznych dla bezpieczeństwa, takich jak systemy kontroli ruchu lotniczego, awionika i broń.

Gęstość defektów

Mierzy wady w stosunku do rozmiaru oprogramowania wyrażone jako linie kodu lub punktu funkcyjnego, itp., Tj. Mierzy jakość kodu na jednostkę. Ta metryka jest używana w wielu komercyjnych systemach oprogramowania.

Problemy klientów

Mierzy problemy, które napotykają klienci podczas korzystania z produktu. Zawiera perspektywę klienta w odniesieniu do przestrzeni problemowej oprogramowania, która obejmuje problemy niezwiązane z defektami wraz z problemami defektów.

Metryka problemów jest zwykle wyrażana w postaci Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Gdzie,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM jest zwykle obliczany dla każdego miesiąca po wprowadzeniu oprogramowania na rynek, a także dla średnich miesięcznych według roku.

Satysfakcja konsumenta

Zadowolenie klienta jest często mierzone danymi ankietowymi klientów w pięciostopniowej skali -

  • Bardzo zadowolony
  • Satisfied
  • Neutral
  • Dissatisfied
  • Bardzo nieusatysfakcjonowany

Zadowolenie z ogólnej jakości produktu i jego konkretnych wymiarów uzyskuje się zwykle poprzez różne metody ankietowania klientów. Na podstawie danych w pięciostopniowej skali można skonstruować i wykorzystać kilka metryk z niewielkimi różnicami, w zależności od celu analizy. Na przykład -

  • Procent całkowicie zadowolonych klientów
  • Procent zadowolonych klientów
  • Procent niezadowolonych klientów
  • Procent niezadowolonych klientów

Zwykle używany jest ten procent satysfakcji.

Wskaźniki jakości w procesie

Metryki jakości w procesie dotyczą śledzenia pojawiania się defektów podczas formalnych testów maszyn w niektórych organizacjach. Te dane obejmują -

  • Gęstość defektów podczas testowania maszyn
  • Wzór pojawienia się defektu podczas testowania maszyny
  • Schemat usuwania defektów oparty na fazie
  • Skuteczność usuwania wad

Gęstość defektów podczas testowania maszyn

Współczynnik defektów podczas formalnego testowania maszynowego (testowanie po zintegrowaniu kodu z biblioteką systemową) jest skorelowany ze współczynnikiem defektów w terenie. Wyższe wskaźniki defektów wykryte podczas testowania wskazują, że oprogramowanie napotkało więcej błędów podczas procesu tworzenia, chyba że wyższy wskaźnik defektów testowych jest wynikiem nadzwyczajnego wysiłku testowego.

Ta prosta miara defektów na KLOC lub punkt funkcyjny jest dobrym wskaźnikiem jakości, podczas gdy oprogramowanie jest nadal testowane. Szczególnie przydatne jest monitorowanie kolejnych wersji produktu w tej samej organizacji programistycznej.

Wzór pojawienia się defektu podczas testowania maszyny

Ogólna gęstość defektów podczas testowania będzie stanowić jedynie podsumowanie defektów. Schemat pojawiania się defektów dostarcza więcej informacji na temat różnych poziomów jakości w terenie. Obejmuje następujące -

  • Pojawienie się wad lub usterek zgłoszonych podczas fazy testowania według przedziałów czasowych (np. Tydzień). Tutaj wszystko to nie będzie ważne wady.

  • Wzór pojawiających się prawidłowych defektów, gdy określono problem dla zgłoszonych problemów. To jest prawdziwy wzór wady.

  • Wzór zaległości w nadgodzinach defektów. Ta miara jest potrzebna, ponieważ organizacje programistyczne nie mogą natychmiast zbadać i naprawić wszystkich zgłoszonych problemów. To jest zarówno deklaracja obciążenia pracą, jak i deklaracja jakości. Jeśli lista defektów jest duża na koniec cyklu rozwojowego i wiele poprawek nie zostało jeszcze zintegrowanych z systemem, wpłynie to na stabilność systemu (a tym samym na jego jakość). Konieczne jest ponowne testowanie (test regresji), aby zapewnić osiągnięcie docelowego poziomu jakości produktu.

Schemat usuwania defektów oparty na fazie

Jest to rozszerzenie miernika gęstości defektów podczas testowania. Oprócz testowania śledzi defekty na wszystkich etapach cyklu rozwoju, w tym w przeglądach projektu, inspekcjach kodu i formalnych weryfikacjach przed testowaniem.

Ponieważ duży procent defektów programistycznych jest związany z problemami projektowymi, przeprowadzanie przeglądów formalnych lub weryfikacji funkcjonalnych w celu zwiększenia zdolności procesu usuwania defektów w procesie na froncie zmniejsza liczbę błędów w oprogramowaniu. Schemat usuwania defektów w oparciu o fazy odzwierciedla ogólną zdolność do usuwania defektów w procesie rozwoju.

W odniesieniu do metryk dotyczących fazy projektowania i kodowania, oprócz wskaźników defektów, wiele organizacji programistycznych stosuje wskaźniki, takie jak zasięg inspekcji i nakłady inspekcji, do zarządzania jakością w trakcie procesu.

Skuteczność usuwania wad

Można go zdefiniować w następujący sposób -

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

Metrykę tę można obliczyć dla całego procesu programowania, dla front-endu przed integracją kodu i dla każdej fazy. To się nazywaearly defect removal gdy jest używany do front-endu i phase effectivenessdla określonych faz. Im wyższa wartość miernika, tym efektywniejszy proces rozwoju i mniej defektów przeszło do następnej fazy lub do pola. Ta miara jest kluczową koncepcją modelu usuwania defektów przy tworzeniu oprogramowania.

Wskaźniki jakości utrzymania

Chociaż nie można wiele zrobić, aby zmienić jakość produktu na tym etapie, poniżej przedstawiono poprawki, które można wykonać, aby jak najszybciej wyeliminować wady przy zachowaniu doskonałej jakości mocowania.

  • Napraw indeks zaległości i zarządzania zaległościami
  • Napraw czas odpowiedzi i napraw responsywność
  • Procent zaległych poprawek
  • Popraw jakość

Napraw indeks zaległości i zarządzania zaległościami

Backlog napraw jest powiązany ze współczynnikiem pojawiania się defektów i szybkością, z jaką dostępne są poprawki dla zgłoszonych problemów. Jest to prosta liczba zgłoszonych problemów, które pozostają na koniec każdego miesiąca lub tygodnia. Używając go w formacie wykresu trendów, metryka ta może dostarczyć znaczących informacji do zarządzania procesem konserwacji.

Wskaźnik zarządzania zaległościami (BMI) służy do zarządzania zaległościami w zakresie otwartych i nierozwiązanych problemów.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

Jeśli BMI jest większe niż 100, oznacza to zmniejszenie zaległości. Jeśli BMI jest mniejsze niż 100, to zaległości wzrosły.

Napraw czas odpowiedzi i napraw responsywność

Metryka czasu reakcji na naprawę jest zwykle obliczana jako średni czas wszystkich problemów od otwarcia do zamknięcia. Krótki czas reakcji na naprawę prowadzi do satysfakcji klienta.

Ważnymi elementami fix responsive są oczekiwania klienta, uzgodniony czas na ustalenie oraz umiejętność wywiązania się ze swojego zobowiązania wobec klienta.

Procent zaległych poprawek

Jest obliczany w następujący sposób -

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

Popraw jakość

Jakość poprawek lub liczba wadliwych poprawek to kolejny ważny miernik jakości dla fazy konserwacji. Poprawka jest wadliwa, jeśli nie rozwiązała zgłoszonego problemu lub jeśli naprawiła pierwotny problem, ale wprowadziła nową usterkę. W przypadku oprogramowania o znaczeniu krytycznym wadliwe poprawki są szkodliwe dla satysfakcji klienta. Miara procentu wadliwych poprawek to odsetek wszystkich wadliwych poprawek w przedziale czasu.

Wadliwą poprawkę można zarejestrować na dwa sposoby: zarejestrować ją w miesiącu, w którym została wykryta, lub zarejestrować ją w miesiącu, w którym została dostarczona. Pierwsza to miara klienta; druga to miara procesu. Różnica między tymi dwoma datami to ukryty okres wadliwej poprawki.

Zwykle im dłuższe opóźnienie, tym bardziej dotkną klientów. Jeśli liczba defektów jest duża, mała wartość wskaźnika procentowego pokaże optymistyczny obraz. Celem jakościowym procesu konserwacji jest oczywiście zero wadliwych poprawek bez opóźnień.

Pomiar to czynność mierzenia czegoś. Jest to przypisanie liczby do cechy obiektu lub zdarzenia, którą można porównać z innymi obiektami lub zdarzeniami.

Formalnie można to zdefiniować jako proces, za pomocą którego przypisuje się liczby lub symbole atrybutom bytów w świecie rzeczywistym, w taki sposób, aby opisać je według jasno określonych reguł.

Pomiar w życiu codziennym

Pomiary są wykorzystywane nie tylko przez profesjonalnych technologów, ale także przez nas wszystkich w życiu codziennym. W sklepie cena jest miarą wartości towaru. Podobnie pomiary wysokości i rozmiaru zapewnią, czy materiał będzie dobrze pasował, czy nie. Tak więc pomiar pomoże nam porównać przedmiot z innym.

Pomiar pobiera informacje o atrybutach jednostek. Istota to obiekt, taki jak osoba lub wydarzenie, takie jak podróż do prawdziwego świata. Atrybut to cecha lub właściwość istoty, taka jak wzrost osoby, koszt podróży itp. W prawdziwym świecie, nawet jeśli myślimy o mierzeniu rzeczy, w rzeczywistości mierzymy atrybuty tych rzeczy.

Atrybuty są najczęściej definiowane za pomocą liczb lub symboli. Na przykład cenę można określić w rupiach lub dolarach, rozmiar odzieży można określić w kategoriach mały, średni, duży.

Dokładność pomiaru zależy od przyrządu pomiarowego, a także od definicji pomiaru. Po uzyskaniu pomiarów musimy je przeanalizować i wyciągnąć wnioski o obiektach.

Pomiar jest bezpośrednim kwantyfikacją, podczas gdy obliczenia są pośrednim, w którym łączymy różne pomiary za pomocą pewnych wzorów.

Pomiary w inżynierii oprogramowania

Inżynieria oprogramowania obejmuje zarządzanie, wycenę, planowanie, modelowanie, analizowanie, określanie, projektowanie, wdrażanie, testowanie i konserwację oprogramowania. Dlatego pomiar odgrywa znaczącą rolę w inżynierii oprogramowania. Rygorystyczne podejście będzie konieczne do pomiaru atrybutów oprogramowania.

W przypadku większości projektów deweloperskich

  • Nie wyznaczamy mierzalnych celów dla naszych produktów programowych
  • Nie rozumiemy i nie określamy ilościowo kosztów składowych projektów oprogramowania
  • Nie określamy ilościowo ani nie przewidujemy jakości wytwarzanych przez nas produktów

Zatem do kontrolowania oprogramowania konieczne jest mierzenie atrybutów. Każde działanie pomiarowe musi być motywowane konkretnym celem lub potrzebą, która jest jasno zdefiniowana i łatwo zrozumiała. Cele pomiaru muszą być konkretne, uwzględniać to, co menedżerowie, programiści i użytkownicy powinni wiedzieć. Pomiary są wymagane do oceny stanu projektu, produktu, procesów i zasobów.

W inżynierii oprogramowania pomiary są niezbędne dla następujących trzech podstawowych czynności -

  • Aby zrozumieć, co dzieje się podczas projektowania i konserwacji
  • Kontrolowanie tego, co dzieje się w projekcie
  • Aby poprawić procesy i cele

Reprezentacyjna teoria pomiaru

Pomiar mówi nam o zasadach, które stanowią podstawę do opracowywania i rozumowania wszelkiego rodzaju pomiarów. Jest to mapowanie ze świata empirycznego do formalnego świata relacyjnego. W konsekwencji miarą jest liczba lub symbol przypisany do jednostki przez to odwzorowanie w celu scharakteryzowania jednostki.

Relacje empiryczne

W prawdziwym świecie rozumiemy rzeczy, porównując je, a nie przypisując im numery.

Na przykład, aby porównać wzrost, używamy terminów „wyższy niż”, wyższy niż ”. Zatem te „wyższy niż”, wyższy niż „są empirycznymi relacjami wzrostu.

Możemy zdefiniować więcej niż jedną relację empiryczną na tym samym zbiorze.

Na przykład X jest wyższy niż Y. X, Y są znacznie wyższe niż Z.

Relacje empiryczne mogą być jednoargumentowe, binarne, trójskładnikowe itp.

X jest wysoki, Y nie wysoki to relacje jednoargumentowe.

X jest wyższy niż Y jest relacją binarną.

Relacje empiryczne w świecie rzeczywistym można odwzorować na formalnym świecie matematycznym. Przeważnie te relacje odzwierciedlają osobiste preferencje.

Poniżej przedstawiono niektóre techniki mapowania lub oceny używane do mapowania tych empirycznych relacji ze światem matematycznym:

Skala Likerta

Tutaj użytkownicy otrzymają oświadczenie, na które muszą się zgodzić lub nie.

For example - To oprogramowanie działa dobrze.

Stanowczo się zgadzam Zgodzić się Ani się zgadzam, ani się nie zgadzam Nie zgadzać się Zdecydowanie Disgaree
         

Wymuszony ranking

Uporządkuj podane alternatywy od 1 (najlepsza) do n (najgorsza).

Na przykład: Oceń następujące 5 modułów oprogramowania według ich wydajności.

Nazwa modułu Ranga
Moduł A
Moduł B
Moduł C
Moduł D
Moduł E

Werbalna skala częstotliwości

For example - Jak często ten program zawodzi?

Zawsze Często Czasami Rzadko Nigdy
         

Skala porządkowa

Tutaj użytkownicy otrzymają listę alternatyw i będą musieli wybrać jedną.

For example - Jak często ten program zawodzi?

  • Hourly
  • Daily
  • Weekly
  • Monthly
  • Kilka razy w roku
  • Raz lub dwa razy w roku
  • Never

Skala porównawcza

Tutaj użytkownik musi podać liczbę, porównując różne opcje.

Very superiorAbout the sameVery inferior

12345678910

Skala numeryczna

Tutaj użytkownik musi podać liczbę zgodnie z jej ważnością.

UnimportantImportant

12345678910

Zasady mapowania

Aby wykonać mapowanie, musimy określić domenę, zakres oraz zasady wykonywania mapowania.

For example - Domena - Świat rzeczywisty

  • Range - Świat matematyczny, taki jak liczby całkowite, liczby rzeczywiste itp.

  • Rules - Do pomiaru wzrostu, buty do noszenia czy nie

Podobnie, w przypadku pomiaru oprogramowania, lista kontrolna instrukcji powinna być zawarta w wierszach kodu, które mają zostać określone.

Reprezentacyjne warunki pomiaru

Warunek reprezentacji potwierdza, że ​​odwzorowanie pomiaru (M) musi odwzorowywać byty na liczby, a relacje empiryczne na relacje liczbowe w taki sposób, aby relacje empiryczne zachowywały i są zachowywane przez relacje numeryczne.

Na przykład: relacja empiryczna „wyższy niż” jest odwzorowana na relację liczbową „>”. Tj. X is taller than Y, if and only if M(X) > M(Y)

Ponieważ w danym zbiorze może istnieć wiele relacji, warunek reprezentacji ma również konsekwencje dla każdej z tych relacji.

Ponieważ jednoargumentowa relacja „jest wysoka”, możemy mieć relację liczbową

X > 50

Warunek reprezentacji wymaga tego dla każdego środka M,

X is tall if and only if M(X) > 50

Kluczowe etapy pomiaru formalnego

Kluczowe etapy pomiaru można podsumować następująco:

Modele są przydatne do interpretowania zachowania elementów numerycznych rzeczywistych bytów, a także do ich pomiaru. Aby wspomóc proces pomiarowy, model odwzorowania powinien być również uzupełniony o model dziedziny mapowania. Model powinien również określać, w jaki sposób te jednostki są powiązane z atrybutami i jak te cechy są powiązane.

Pomiary są dwojakiego rodzaju -

  • Pomiar bezpośredni
  • Pomiar pośredni

Pomiar bezpośredni

Są to pomiary, które można zmierzyć bez udziału jakiegokolwiek innego podmiotu lub atrybutu.

Następujące środki bezpośrednie są powszechnie stosowane w inżynierii oprogramowania.

  • Długość kodu źródłowego według LOC
  • Czas trwania celu testowego według upływającego czasu
  • Liczba defektów wykrytych podczas procesu testowania poprzez zliczanie defektów
  • Czas, który programista spędza nad programem

Pomiar pośredni

Są to pomiary, które można zmierzyć w kategoriach dowolnego innego podmiotu lub atrybutu.

Następujące miary pośrednie są powszechnie stosowane w inżynierii oprogramowania.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

Pomiary do przewidywania

Aby przydzielić odpowiednie zasoby do projektu, musimy przewidzieć wysiłek, czas i koszt opracowania projektu. Pomiar na potrzeby przewidywania zawsze wymaga modelu matematycznego, który wiąże atrybuty, które mają być przewidywane, z jakimś innym atrybutem, który możemy teraz zmierzyć. Stąd system predykcyjny składa się z modelu matematycznego wraz z zestawem procedur predykcyjnych służących do określania nieznanych parametrów i interpretacji wyników.

Skale pomiarowe to odwzorowania używane do reprezentowania empirycznego systemu relacji. Jest to głównie 5 typów -

  • Skala nominalna
  • Skala porządkowa
  • Skala interwałowa
  • Skala proporcji
  • Skala absolutna

Skala nominalna

Umieszcza elementy w schemacie klasyfikacji. Zajęcia nie będą zamawiane. Każdy podmiot powinien być umieszczony w określonej klasie lub kategorii na podstawie wartości atrybutu.

Ma dwie główne cechy -

  • System relacji empirycznych składa się tylko z różnych klas; nie ma pojęcia uporządkowania między klasami.

  • Dowolna odrębna numeracja lub symboliczna reprezentacja klas jest dopuszczalną miarą, ale nie istnieje pojęcie wielkości związane z liczbami lub symbolami.

Skala porządkowa

Umieszcza elementy w uporządkowanym schemacie klasyfikacji. Ma następujące cechy -

  • System relacji empirycznych składa się z klas, które są uporządkowane według atrybutu.

  • Każde odwzorowanie, które zachowuje kolejność, jest dopuszczalne.

  • Liczby przedstawiają tylko ranking. Dlatego dodawanie, odejmowanie i inne działania arytmetyczne nie mają znaczenia.

Skala interwałowa

Ta skala zawiera informacje o wielkości przedziałów oddzielających klasyfikację. Dlatego jest silniejszy niż skala nominalna i skala porządkowa.

Ma następujące cechy -

  • Zachowuje porządek jak skala porządkowa.

  • Zachowuje różnice, ale nie stosunek.

  • Dodawanie i odejmowanie można wykonywać w tej skali, ale nie mnożenia ani dzielenia.

Jeśli atrybut jest mierzalny na skali interwałowej, i M i M’ są odwzorowaniami spełniającymi warunek reprezentacji, wtedy zawsze możemy znaleźć dwie liczby a i b takie, że

M = aM '+ b

Skala proporcji

Jest to najbardziej użyteczna skala pomiaru. Tutaj istnieje relacja empiryczna, aby uchwycić współczynniki. Ma następujące cechy -

  • Jest to odwzorowanie pomiarów, które zachowuje uporządkowanie, rozmiar odstępów między jednostkami i stosunek między jednostkami.

  • Istnieje element zerowy, reprezentujący całkowity brak atrybutów.

  • Odwzorowanie pomiaru musi zaczynać się od zera i rosnąć w równych odstępach, zwanych jednostkami.

  • Można zastosować wszystkie operacje arytmetyczne.

Tutaj mapowanie będzie miało postać

M = aM’

Gdzie ‘a’ jest dodatnim skalarem.

Skala absolutna

W tej skali będzie tylko jedna możliwa miara atrybutu. Stąd jedyną możliwą transformacją będzie transformacja tożsamości.

Ma następujące cechy -

  • Pomiar dokonywany jest poprzez zliczenie liczby elementów w zestawie encji.

  • Atrybut zawsze ma postać „liczba wystąpień x w encji”.

  • Jest tylko jedno możliwe odwzorowanie pomiaru, a mianowicie liczba rzeczywista.

  • Wszystkie operacje arytmetyczne można wykonać na wynikowej liczbie.

Badania empiryczne obejmują naukowe badanie dowolnego narzędzia, techniki lub metody. To dochodzenie obejmuje głównie następujące 4 zasady.

  • Wybór techniki dochodzenia
  • Stawianie hipotezy
  • Utrzymanie kontroli nad zmienną
  • Nadanie sensowi śledztwa

Wybór techniki badawczej

Kluczowymi elementami badania empirycznego w inżynierii oprogramowania są:

  • Survey
  • Studium przypadku
  • Formalny eksperyment

Ankieta

Ankieta to retrospektywne badanie sytuacji w celu udokumentowania relacji i wyników. Ma to miejsce zawsze po wystąpieniu zdarzenia. Na przykład w inżynierii oprogramowania można przeprowadzać ankiety, aby określić, jak użytkownicy zareagowali na określoną metodę, narzędzie lub technikę w celu określenia trendów lub zależności.

W tym przypadku nie mamy kontroli nad obecną sytuacją. Możemy nagrać sytuację i porównać ją z podobną.

Studium przypadku

Jest to technika badawcza, w której identyfikuje się kluczowe czynniki, które mogą wpływać na wynik działania, a następnie dokumentuje działanie: jego nakłady, ograniczenia, zasoby i wyniki.

Formalny eksperyment

Jest to rygorystyczne kontrolowane badanie działania, w którym kluczowe czynniki są identyfikowane i manipulowane w celu udokumentowania ich wpływu na wynik.

Konkretną metodę badania można wybrać zgodnie z następującymi wytycznymi -

  • Jeśli aktywność już miała miejsce, możemy przeprowadzić ankietę lub studium przypadku. Jeśli ma to jeszcze nastąpić, można wybrać studium przypadku lub formalny eksperyment.

  • Jeśli mamy wysoki poziom kontroli nad zmiennymi, które mogą wpływać na wynik, możemy użyć eksperymentu. Jeśli nie mamy kontroli nad zmienną, preferowaną techniką będzie studium przypadku.

  • Jeśli replikacja nie jest możliwa na wyższych poziomach, eksperyment nie jest możliwy.

  • Jeśli koszt replikacji jest niski, możemy rozważyć eksperyment.

Stawianie hipotezy

Aby podbić decyzję o konkretnej technice badawczej, cel badań należy wyrazić jako hipotezę, którą chcemy przetestować. Hipoteza jest wstępną teorią lub przypuszczeniem, które zdaniem programisty wyjaśnia zachowanie, które chce zbadać.

Utrzymywanie kontroli nad zmiennymi

Po sformułowaniu hipotezy, następnie musimy zdecydować, jakie zmienne wpływają na jej prawdziwość, a także na ile mamy nad nią kontrolę. Jest to istotne, ponieważ kluczowym czynnikiem odróżniającym eksperyment od studiów przypadku jest stopień kontroli nad zmienną, która wpływa na zachowanie.

Zmienna stanu, która jest czynnikiem, który może charakteryzować projekt, a także może wpływać na wyniki oceny, służy do odróżnienia sytuacji kontrolnej od eksperymentalnej w eksperymencie formalnym. Jeśli nie możemy odróżnić kontroli od eksperymentu, preferowaną metodą będzie studium przypadku.

Na przykład, jeśli chcemy ustalić, czy zmiana języka programowania może wpłynąć na produktywność projektu, to język będzie zmienną stanu. Załóżmy, że obecnie używamy FORTRANU, który chcemy zastąpić Adą. Wtedy FORTRAN będzie językiem kontrolnym, a Ada językiem eksperymentalnym.

Nadanie sensu śledztwu

Wyniki eksperymentu są zwykle bardziej ogólne niż studium przypadku lub ankieta. Wyniki studium przypadku lub ankiety mogą zwykle mieć zastosowanie tylko do określonej organizacji. Poniższe punkty dowodzą skuteczności tych technik w udzielaniu odpowiedzi na różne pytania.

Zgodne teorie i konwencjonalna mądrość

Studia przypadków lub ankiety mogą być wykorzystane w celu potwierdzenia skuteczności i użyteczności konwencjonalnej wiedzy i wielu innych standardów, metod lub narzędzi w jednej organizacji. Jednak formalny eksperyment może zbadać sytuacje, w których twierdzenia są ogólnie prawdziwe.

Odkrywanie relacji

Relacje między różnymi atrybutami zasobów i oprogramowania można zasugerować w studium przypadku lub ankiecie.

Na przykład badanie ukończonych projektów może wykazać, że oprogramowanie napisane w określonym języku ma mniej błędów niż oprogramowanie napisane w innych językach.

Zrozumienie i zweryfikowanie tych relacji ma zasadnicze znaczenie dla powodzenia wszelkich przyszłych projektów. Każdą z tych relacji można wyrazić jako hipotezę, a formalny eksperyment można zaprojektować w celu sprawdzenia stopnia, w jakim relacje te utrzymują się. Zwykle wartość jednego konkretnego atrybutu jest obserwowana poprzez utrzymywanie innych atrybutów na stałym poziomie lub pod kontrolą.

Ocena dokładności modeli

Modele są zwykle używane do przewidywania wyniku działania lub do kierowania stosowaniem metody lub narzędzia. Stanowi to szczególnie trudny problem podczas projektowania eksperymentu lub studium przypadku, ponieważ ich przewidywania często wpływają na wynik. Kierownicy projektów często przekształcają prognozy w cele do ukończenia. Ten efekt jest powszechny, gdy używane są modele kosztów i harmonogramu.

Niektóre modele, takie jak modele niezawodności, nie wpływają na wynik, ponieważ niezawodności mierzonej jako średni czas do awarii nie można ocenić, dopóki oprogramowanie nie będzie gotowe do użycia w terenie.

Środki walidacyjne

Istnieje wiele miar oprogramowania służących do wychwytywania wartości atrybutu. W związku z tym należy przeprowadzić badanie, aby sprawdzić, czy dana miara odzwierciedla zmiany w atrybucie, który ma uchwycić. Walidacja polega na skorelowaniu jednej miary z drugą. Do walidacji należy zastosować drugą miarę, która jest również bezpośrednią i ważną miarą czynnika wpływającego. Takie środki nie zawsze są dostępne lub łatwe do zmierzenia. Ponadto zastosowane miary muszą być zgodne z ludzkim wyobrażeniem o mierzonym czynniku.

Struktura pomiaru oprogramowania opiera się na trzech zasadach -

  • Klasyfikacja podmiotów do zbadania
  • Określenie odpowiednich celów pomiarowych
  • Określenie poziomu dojrzałości, który osiągnęła organizacja

Klasyfikacja podmiotów do zbadania

W inżynierii oprogramowania istnieją głównie trzy klasy jednostek. Oni są -

  • Processes
  • Products
  • Resources

Wszystkie te podmioty mają zarówno podmioty wewnętrzne, jak i zewnętrzne.

  • Internal attributesto te, które można zmierzyć wyłącznie w kategoriach samego procesu, produktu lub zasobów. Na przykład: rozmiar, złożoność, zależność między modułami.

  • External attributesto takie, które można zmierzyć tylko w odniesieniu do jej relacji ze środowiskiem. Na przykład: Całkowita liczba błędów, których doświadczył użytkownik, czas potrzebny na przeszukanie bazy danych i pobranie informacji.

Różne atrybuty, które można zmierzyć dla każdej z jednostek, są następujące:

Procesy

Procesy to zbiory działań związanych z oprogramowaniem. Poniżej przedstawiono niektóre wewnętrzne atrybuty, które można zmierzyć bezpośrednio dla procesu -

  • Czas trwania procesu lub jednej z jego czynności

  • Wysiłek związany z procesem lub jedną z jego czynności

  • Liczba incydentów określonego typu powstałych w trakcie procesu lub jednej z jego czynności

Różne zewnętrzne cechy procesu to koszt, możliwość kontroli, skuteczność, jakość i stabilność.

Produkty

Produkty to nie tylko elementy, które kierownictwo jest zobowiązane dostarczyć, ale także wszelkie artefakty lub dokumenty powstałe w trakcie cyklu życia oprogramowania.

Różne wewnętrzne atrybuty produktu to rozmiar, nakład pracy, koszt, specyfikacja, długość, funkcjonalność, modułowość, ponowne użycie, nadmiarowość i poprawność składniowa. Wśród tych rozmiarów, wysiłku i kosztów można stosunkowo łatwo zmierzyć niż inne.

Różne atrybuty produktu zewnętrznego to użyteczność, integralność, wydajność, testowalność, możliwość ponownego użycia, przenośność i interoperacyjność. Te atrybuty opisują nie tylko kod, ale także inne dokumenty wspierające prace programistyczne.

Zasoby

Są to encje wymagane przez działanie procesu. Może to być dowolny wkład do produkcji oprogramowania. Obejmuje personel, materiały, narzędzia i metody.

Różne wewnętrzne atrybuty zasobów to wiek, cena, rozmiar, szybkość, rozmiar pamięci, temperatura itp. Różne zewnętrzne atrybuty to produktywność, doświadczenie, jakość, użyteczność, niezawodność, komfort itp.

Określanie odpowiednich celów pomiarowych

Konkretny pomiar będzie przydatny tylko wtedy, gdy pomoże zrozumieć proces lub jeden z jego produktów. Udoskonalenie procesu lub produktów można przeprowadzić tylko wtedy, gdy projekt ma jasno określone cele dla procesów i produktów. Jasne zrozumienie celów może posłużyć do wygenerowania sugerowanych metryk dla danego projektu w kontekście ram dojrzałości procesu.

Paradygmat cel – pytanie – metryka (GQM)

Podejście GQM zapewnia ramy obejmujące następujące trzy kroki -

  • Wymienienie głównych celów projektu rozwoju lub utrzymania

  • Wyprowadzenie pytań z każdego celu, na który należy odpowiedzieć, aby określić, czy cele zostały osiągnięte

  • Zdecyduj, co należy zmierzyć, aby móc odpowiednio odpowiedzieć na pytania

Aby skorzystać z paradygmatu GQM, najpierw określamy ogólne cele organizacji. Następnie generujemy pytania w taki sposób, aby znane były odpowiedzi, abyśmy mogli określić, czy cele zostały osiągnięte. Później przeanalizuj każde pytanie pod kątem tego, jakiego pomiaru potrzebujemy, aby odpowiedzieć na każde pytanie.

Typowe cele są wyrażane w kategoriach produktywności, jakości, ryzyka, satysfakcji klienta itp. Cele i pytania należy konstruować z uwzględnieniem ich odbiorców.

Aby pomóc w generowaniu celów, pytań i wskaźników, Basili & Rombach dostarczyli serię szablonów.

  • Purpose - Aby (scharakteryzować, ocenić, przewidzieć, motywować itp.) (Procesu, produktu, modelu, miernika itp.) W celu zrozumienia, oceny, zarządzania, projektowania, uczenia się, doskonalenia itp. Example: Scharakteryzowanie produktu w celu nauczenia się go.

  • Perspective - Zbadaj (koszty, efektywność, poprawność, wady, zmiany, pomiary produktu itp.) Z punktu widzenia dewelopera, menedżera, klienta itp. Example: Zbadaj usterki z punktu widzenia klienta.

  • Environment - Na środowisko składają się: czynniki procesowe, czynniki ludzkie, czynniki problemowe, metody, narzędzia, ograniczenia itp. Example: Klientami tego oprogramowania są ci, którzy nie mają wiedzy na temat narzędzi.

Pomiary i doskonalenie procesów

Zwykle pomiar jest przydatny w przypadku -

  • Zrozumienie procesu i produktów
  • Ustalenie punktu odniesienia
  • Dostęp i przewidywanie wyniku

W zależności od stopnia dojrzałości procesu podanego przez SEI, rodzaj pomiaru i program pomiarowy będą różne. Poniżej przedstawiono różne programy pomiarowe, które można zastosować na każdym poziomie dojrzałości.

Level 1: Ad hoc

Na tym poziomie wejścia są źle zdefiniowane, podczas gdy wyniki są oczekiwane. Przejście od wejścia do wyjścia jest niezdefiniowane i niekontrolowane. Na tym poziomie dojrzałości procesu pomiary bazowe są potrzebne, aby zapewnić punkt wyjścia do pomiaru.

Level 2: Repeatable

Na tym poziomie można zidentyfikować dane wejściowe i wyjściowe procesu, ograniczenia i zasoby. Powtarzalny proces można opisać poniższym diagramem.

Miarami wejściowymi mogą być wielkość i zmienność wymagań. Wyniki można mierzyć pod względem rozmiaru systemu, zasobów pod względem nakładu pracy personelu oraz ograniczeń pod względem kosztów i harmonogramu.

Level 3: Defined

Na tym poziomie definiuje się działania pośrednie, a ich nakłady i produkty są znane i rozumiane. Prosty przykład zdefiniowanego procesu został przedstawiony na poniższym rysunku.

Można zbadać, zmierzyć i ocenić wkład i wyniki działań pośrednich.

Level 4: Managed

Na tym poziomie informacje zwrotne z wczesnych działań projektowych można wykorzystać do ustalenia priorytetów dla bieżących działań, a później dla działań projektowych. Potrafimy mierzyć efektywność działań procesowych. Pomiar odzwierciedla charakterystykę całego procesu oraz interakcji pomiędzy głównymi działaniami i pomiędzy nimi.

Level 5: Optimizing

Na tym poziomie pomiary z czynności są wykorzystywane do usprawnienia procesu poprzez usuwanie i dodawanie czynności procesowych oraz dynamiczną zmianę struktury procesu w odpowiedzi na pomiarowe informacje zwrotne. Zatem zmiana procesu może wpłynąć na organizację i projekt, a także na proces. Proces będzie działał jak czujniki i monitory, a my możemy znacząco zmienić proces w odpowiedzi na znaki ostrzegawcze.

Na danym poziomie dojrzałości możemy zbierać pomiary dla tego poziomu i wszystkich poziomów poniżej niego.

Określenie poziomu dojrzałości

Dojrzałość procesu sugeruje mierzenie tylko tego, co jest widoczne. Zatem połączenie dojrzałości procesu z GQM zapewni najbardziej użyteczne miary.

  • W level 1projekt prawdopodobnie będzie miał źle zdefiniowane wymagania. Na tym poziomie pomiar charakterystyk wymagań jest trudny.

  • W level 2wymagania są dobrze zdefiniowane i można zebrać dodatkowe informacje, takie jak rodzaj każdego wymagania i liczba zmian każdego typu.

  • W level 3czynności pośrednie są definiowane za pomocą kryteriów wejścia i wyjścia dla każdego działania

Analiza celu i pytania będzie taka sama, ale metryka będzie się różnić w zależności od dojrzałości. Im bardziej dojrzały proces, tym bogatsze będą pomiary. Paradygmat GQM, wraz z dojrzałością procesu, został wykorzystany jako podstawa kilku narzędzi, które pomagają menedżerom w projektowaniu programów pomiarowych.

GQM pomaga zrozumieć potrzebę pomiaru atrybutu, a dojrzałość procesu sugeruje, czy jesteśmy w stanie zmierzyć go w sensowny sposób. Razem tworzą kontekst dla pomiaru.

Walidacja pomiaru systemu oprogramowania obejmuje dwa etapy -

  • Walidacja systemów pomiarowych
  • Walidacja systemów predykcji

Walidacja systemów pomiarowych

Miary lub systemy pomiarowe są używane do oceny istniejącej jednostki poprzez numeryczne scharakteryzowanie jednego lub większej liczby jego atrybutów. Miara jest ważna, jeśli dokładnie charakteryzuje atrybut, który ma mierzyć.

Walidacja oprogramowania systemu pomiarowego to proces zapewniania, że ​​miara jest poprawną charakterystyką numeryczną deklarowanego atrybutu poprzez wykazanie, że warunek reprezentacji jest spełniony.

Do walidacji systemu pomiarowego potrzebujemy zarówno modelu formalnego, który opisuje jednostki, jak i mapowania numerycznego, które zachowuje atrybut, który mierzymy. Na przykład, jeśli istnieją dwa programy P1 i P2 i chcemy je połączyć, to oczekujemy, że każdy środekm długości, aby to zaspokoić,

m (P1 + P2) = m (P1) + m (P2)

Jeśli program P1 ma więcej czasu niż program P2, potem dowolny środek m powinny również zadowolić,

m (P1)> m (P2)

Długość programu można zmierzyć, licząc wiersze kodu. Jeśli ta liczba spełnia powyższe zależności, możemy powiedzieć, że wiersze kodu są prawidłową miarą długości.

Formalny wymóg walidacji miernika polega na wykazaniu, że charakteryzuje on określony atrybut w rozumieniu teorii pomiaru. Walidacja może służyć do upewnienia się, że osoby dokonujące pomiaru są właściwie zdefiniowane i są zgodne z zachowaniem jednostki w świecie rzeczywistym.

Walidacja systemów prognozowania

Systemy predykcyjne są używane do przewidywania niektórych atrybutów przyszłej jednostki obejmującej model matematyczny z powiązanymi procedurami predykcji.

Walidacja systemów predykcyjnych w danym środowisku to proces ustalania dokładności systemu predykcji metodami empirycznymi, tj. Poprzez porównanie działania modelu ze znanymi danymi w danym środowisku. Obejmuje eksperymentowanie i testowanie hipotez.

Stopień dokładności dopuszczalny do walidacji zależy od tego, czy system predykcji jest deterministyczny czy stochastyczny, a także od osoby dokonującej oceny. Niektóre systemy przewidywania stochastycznego są bardziej stochastyczne niż inne.

Przykładami systemów predykcji stochastycznych są takie systemy, jak szacowanie kosztów oprogramowania, szacowanie nakładu pracy, szacowanie harmonogramu itp. Dlatego, aby formalnie zweryfikować system predykcji, musimy zdecydować, jak jest stochastyczny, a następnie porównać wydajność systemu predykcji ze znanymi danymi.

Metryki oprogramowania to standard miary, który obejmuje wiele działań, które obejmują pewien stopień pomiaru. Można je podzielić na trzy kategorie: metryki produktu, metryki procesu i metryki projektu.

  • Product metrics opisać cechy produktu, takie jak rozmiar, złożoność, cechy konstrukcyjne, wydajność i poziom jakości.

  • Process metricsmożna wykorzystać do usprawnienia tworzenia i konserwacji oprogramowania. Przykłady obejmują skuteczność usuwania defektów podczas programowania, schemat testowania pojawiania się defektów i czas reakcji procesu naprawy.

  • Project metricsopisać cechy i wykonanie projektu. Przykłady obejmują liczbę programistów, schemat zatrudnienia w całym cyklu życia oprogramowania, koszt, harmonogram i produktywność.

Niektóre metryki należą do wielu kategorii. Na przykład metryki jakości projektu w toku to zarówno metryki procesu, jak i metryki projektu.

Zakres metryk oprogramowania

Metryki oprogramowania obejmują wiele działań, które obejmują:

  • Szacowanie kosztów i nakładu pracy
  • Miary i model produktywności
  • Gromadzenie danych
  • Modele i miary ilościowe
  • Modele niezawodności
  • Modele wydajności i oceny
  • Miary strukturalne i złożoności
  • Zdolność - ocena dojrzałości
  • Zarządzanie przez metryki
  • Ocena metod i narzędzi

Pomiar oprogramowania to zróżnicowany zbiór tych czynności, od modeli przewidujących koszty projektu oprogramowania na określonym etapie po miary struktury programu.

Szacowanie kosztów i nakładu pracy

Wysiłek jest wyrażany jako funkcja jednej lub więcej zmiennych, takich jak rozmiar programu, możliwości twórców i poziom ponownego wykorzystania. Zaproponowano modele szacowania kosztów i nakładu pracy, aby przewidywać koszty projektu we wczesnych fazach cyklu życia oprogramowania. Różne proponowane modele to -

  • Model COCOMO firmy Boehm
  • Smukły model Putnama
  • Model punktu funkcyjnego Albrechta

Model produktywności i miary

Produktywność można uznać za funkcję wartości i kosztu. Każdy z nich można rozłożyć na inny mierzalny rozmiar, funkcjonalność, czas, pieniądze itp. Na poniższym diagramie można przedstawić różne możliwe komponenty modelu produktywności.

Gromadzenie danych

Jakość każdego programu pomiarowego jest wyraźnie zależna od starannego gromadzenia danych. Zebrane dane można wydestylować na proste wykresy i wykresy, aby menedżerowie mogli zrozumieć postęp i problem rozwoju. Gromadzenie danych jest również niezbędne do naukowego badania zależności i trendów.

Modele i miary jakości

Modele jakości zostały opracowane do pomiaru jakości produktu, bez których produktywność nie ma znaczenia. Te modele jakości można łączyć z modelem produktywności w celu pomiaru prawidłowej wydajności. Modele te są zwykle zbudowane w kształcie drzewa. W górnych gałęziach znajdują się ważne czynniki jakościowe wysokiego poziomu, takie jak niezawodność i użyteczność.

Pojęcie dziel i rządź zostało wdrożone jako standardowe podejście do pomiaru jakości oprogramowania.

Modele niezawodności

Większość modeli jakości obejmuje niezawodność jako czynnik składowy, jednak potrzeba przewidywania i pomiaru niezawodności doprowadziła do oddzielnej specjalizacji w modelowaniu i prognozowaniu niezawodności. Podstawowym problemem teorii niezawodności jest przewidywanie, kiedy system ostatecznie ulegnie awarii.

Ocena wydajności i modele

Obejmuje obserwowalne zewnętrznie cechy wydajności systemu, takie jak czasy odpowiedzi i wskaźniki ukończenia, oraz wewnętrzne działanie systemu, takie jak wydajność algorytmów. To kolejny aspekt jakości.

Miary strukturalne i złożoności

Tutaj mierzymy atrybuty strukturalne reprezentacji oprogramowania, które są dostępne przed wykonaniem. Następnie próbujemy ustanowić empirycznie predykcyjne teorie wspierające zapewnianie jakości, kontrolę jakości i przewidywanie jakości.

Ocena dojrzałości zdolności

Model ten może oceniać wiele różnych atrybutów rozwoju, w tym wykorzystanie narzędzi, standardowe praktyki i nie tylko. Opiera się na kluczowych praktykach, które powinien stosować każdy dobry wykonawca.

Zarządzanie przez metryki

W zarządzaniu projektem oprogramowania pomiar odgrywa kluczową rolę. Aby sprawdzić, czy projekt jest realizowany, użytkownicy i programiści mogą polegać na wykresie i wykresie opartym na pomiarach. Standardowy zestaw pomiarów i metod raportowania jest szczególnie ważny, gdy oprogramowanie jest wbudowane w produkt, a klienci zwykle nie są dobrze zorientowani w terminologii oprogramowania.

Ocena metod i narzędzi

Zależy to od projektu eksperymentu, właściwej identyfikacji czynników, które mogą wpłynąć na wynik oraz odpowiedniego pomiaru atrybutów czynników.

Metryki oprogramowania to standard miary obejmujący wiele czynności, które obejmują pewien stopień pomiaru. Sukces pomiaru oprogramowania polega na jakości gromadzonych i analizowanych danych.

Co to są dobre dane?

Zebrane dane można uznać za dobre dane, jeśli mogą dostarczyć odpowiedzi na następujące pytania -

  • Are they correct? - Dane można uznać za prawidłowe, jeżeli zostały zebrane zgodnie z dokładnymi zasadami definicji miernika.

  • Are they accurate? - Dokładność odnosi się do różnicy między danymi a rzeczywistą wartością.

  • Are they appropriately precise? - Precyzja dotyczy liczby miejsc dziesiętnych potrzebnych do wyrażenia danych.

  • Are they consistent? - Dane można uznać za spójne, jeśli nie wykazują dużej różnicy między jednym urządzeniem pomiarowym a innym.

  • Are they associated with a particular activity or time period? - Jeśli dane są powiązane z konkretną czynnością lub okresem, to należy to wyraźnie określić w danych.

  • Can they be replicated?- Zwykle badania, takie jak ankiety, studia przypadków i eksperymenty, są często powtarzane w różnych okolicznościach. Dlatego też powinno być możliwe łatwe kopiowanie danych.

Jak zdefiniować dane?

Dane zbierane do celów pomiarowych są dwojakiego rodzaju -

  • Raw data- Surowe dane wynikają z początkowego pomiaru procesu, produktów lub zasobów. Na przykład: Tygodniowy grafik pracowników w organizacji.

  • Refined data - Udoskonalone dane wynikają z ekstrakcji niezbędnych elementów danych z surowych danych w celu wyprowadzenia wartości atrybutów.

Dane można zdefiniować według następujących punktów -

  • Location
  • Timing
  • Symptoms
  • Wynik końcowy
  • Mechanism
  • Cause
  • Severity
  • Cost

Jak zbierać dane?

Gromadzenie danych wymaga obserwacji i raportowania przez ludzi. Menedżerowie, analitycy systemowi, programiści, testerzy i użytkownicy muszą zapisywać dane wierszy w formularzach. Aby zebrać dokładne i kompletne dane, ważne jest:

  • Utrzymuj proste procedury

  • Unikaj niepotrzebnego nagrywania

  • Przeszkol pracowników w zakresie konieczności rejestrowania danych i stosowanych procedur

  • Dostarczaj wyniki gromadzenia i analizy danych pierwotnym dostawcom szybko i w użytecznej formie, która pomoże im w ich pracy

  • Sprawdź poprawność wszystkich danych zebranych w centralnym punkcie zbierania

Planowanie zbierania danych obejmuje kilka etapów -

  • Na podstawie analizy GQM zdecyduj, które produkty mierzyć

  • Upewnij się, że produkt jest pod kontrolą konfiguracji

  • Zdecyduj dokładnie, które atrybuty mierzyć i jak będą uzyskiwane miary pośrednie

  • Gdy zestaw wskaźników jest jasny, a zestaw komponentów do pomiaru został zidentyfikowany, opracuj schemat identyfikacji każdej czynności zaangażowanej w proces pomiaru

  • Ustanów procedurę obsługi formularzy, analizowania danych i raportowania wyników

Planowanie gromadzenia danych należy rozpocząć w momencie rozpoczęcia planowania projektu. Rzeczywiste gromadzenie danych odbywa się na wielu etapach rozwoju.

For example - Niektóre dane dotyczące personelu projektu można zebrać na początku projektu, podczas gdy inne gromadzenie danych, takie jak nakład pracy, rozpoczyna się w momencie rozpoczęcia projektu i jest kontynuowane w trakcie eksploatacji i konserwacji.

Jak przechowywać i wyodrębniać dane

W inżynierii oprogramowania dane powinny być przechowywane w bazie danych i konfigurowane za pomocą systemu zarządzania bazą danych (DBMS). Przykład struktury bazy danych pokazano na poniższym rysunku. Ta baza danych będzie przechowywać dane różnych pracowników pracujących w różnych działach organizacji.

Na powyższym diagramie każde pole jest tabelą w bazie danych, a strzałka oznacza mapowanie wiele do jednego z jednej tabeli do drugiej. Mapowania definiują ograniczenia, które zachowują logiczną spójność danych.

Po zaprojektowaniu bazy danych i wypełnieniu jej danymi, możemy wykorzystać języki manipulacji danymi do wyodrębnienia danych do analizy.

Po zebraniu odpowiednich danych musimy je odpowiednio przeanalizować. Przy wyborze techniki analizy należy wziąć pod uwagę trzy główne elementy.

  • Charakter danych
  • Cel eksperymentu
  • Rozważania projektowe

Charakter danych

Aby przeanalizować dane, musimy również spojrzeć na większą populację reprezentowaną przez dane, a także na rozkład tych danych.

Pobieranie próbek, populacja i dystrybucja danych

Próbkowanie to proces wybierania zestawu danych z dużej populacji. Przykładowe statystyki opisują i podsumowują pomiary uzyskane od grupy badanych eksperymentalnych.

Parametry populacji reprezentują wartości, które zostałyby uzyskane, gdyby mierzono wszystkie możliwe osoby.

Populację lub próbę można opisać za pomocą miar tendencji centralnej, takich jak średnia, mediana i tryb, oraz miar dyspersji, takich jak wariancja i odchylenie standardowe. Wiele zestawów danych jest dystrybuowanych normalnie, jak pokazano na poniższym wykresie.

Jak pokazano powyżej, dane będą równomiernie rozłożone na temat średniej. co jest istotną cechą rozkładu normalnego.

Istnieją również inne rozkłady, w których dane są wypaczone, tak że po jednej stronie średniej znajduje się więcej punktów danych niż po drugiej. Na przykład: jeśli większość danych znajduje się po lewej stronie średniej, możemy powiedzieć, że rozkład jest skośny w lewo.

Cel eksperymentu

Zwykle przeprowadza się eksperymenty -

  • Aby potwierdzić teorię
  • Aby zbadać związek

Aby osiągnąć każdy z tych celów, cel należy formalnie wyrazić za pomocą hipotezy, a analiza musi bezpośrednio odnosić się do hipotezy.

Aby potwierdzić teorię

Badanie musi mieć na celu zbadanie prawdy teorii. Teoria zwykle stwierdza, że ​​użycie określonej metody, narzędzia lub techniki ma szczególny wpływ na badanych, czyniąc je w pewnym sensie lepszymi od innych.

Należy wziąć pod uwagę dwa przypadki danych: normal data i non-normal data.

Jeśli dane pochodzą z rozkładu normalnego i istnieją dwie grupy do porównania, do analizy można użyć testu t-Studenta. Jeśli do porównania są więcej niż dwie grupy, można zastosować ogólną analizę testu wariancji zwaną statystyką F.

Jeśli dane nie są normalne, można je przeanalizować za pomocą testu Kruskala-Wallisa, oceniając je.

Aby zbadać związek

Badania mają na celu określenie związku między punktami danych opisującymi jedną zmienną lub wiele zmiennych.

Istnieją trzy techniki udzielania odpowiedzi na pytania dotyczące relacji: wykresy pudełkowe, wykresy punktowe i analiza korelacji.

  • ZA box plot może reprezentować podsumowanie zakresu zbioru danych.

  • ZA scatter plot reprezentuje związek między dwiema zmiennymi.

  • Correlation analysis używa metod statystycznych, aby potwierdzić, czy istnieje prawdziwy związek między dwoma atrybutami.

    • Dla wartości o rozkładzie normalnym użyj Pearson Correlation Coefficient aby sprawdzić, czy te dwie zmienne są wysoce skorelowane.

    • W przypadku danych innych niż normalne, uszereguj dane i użyj rozszerzenia Spearman Rank Correlation Coefficientjako miara skojarzenia. Inną miarą dla niestandardowych danych jestKendall robust correlation coefficient, który bada związek między parami punktów danych i może zidentyfikować częściową korelację.

Jeśli ranking zawiera dużą liczbę powiązanych wartości, a chi-squared testw tabeli kontyngencji można użyć do przetestowania powiązania między zmiennymi. Podobnie,linear regression może posłużyć do wygenerowania równania opisującego związek między zmiennymi.

W przypadku więcej niż dwóch zmiennych multivariate regression może być zastosowane.

Uwagi projektowe

Wybierając techniki analizy, należy wziąć pod uwagę projekt badania. Jednocześnie złożoność analizy może wpłynąć na wybrany projekt. Wiele grup używa statystyk F zamiast testu t-Studenta w dwóch grupach.

W przypadku złożonych planów czynnikowych z więcej niż dwoma czynnikami potrzebny jest bardziej wyrafinowany test powiązania i istotności.

Techniki statystyczne można wykorzystać do wyjaśnienia wpływu jednego zestawu zmiennych na inne lub do skompensowania efektów czasowych lub uczenia się.

Wewnętrzne atrybuty produktu opisują oprogramowanie w sposób zależny tylko od samego produktu. Głównym powodem mierzenia wewnętrznych atrybutów produktu jest to, że pomoże to w monitorowaniu i kontrolowaniu produktów podczas opracowywania.

Mierzenie wewnętrznych atrybutów produktu

Główne wewnętrzne atrybuty produktu obejmują size i structure. Rozmiar można mierzyć statycznie bez konieczności ich wykonywania. Rozmiar produktu mówi nam o wysiłku potrzebnym do jego stworzenia. Podobnie, struktura produktu odgrywa ważną rolę w projektowaniu konserwacji produktu.

Mierzenie rozmiaru

Rozmiar oprogramowania można opisać trzema atrybutami -

  • Length - To jest fizyczny rozmiar produktu.

  • Functionality - Opisuje funkcje dostarczane użytkownikowi przez produkt.

  • Complexity - Złożoność jest różnego rodzaju, na przykład.

    • Problem complexity - Mierzy złożoność podstawowego problemu.

    • Algorithmic complexity - Mierzy złożoność algorytmu zastosowanego w celu rozwiązania problemu

    • Structural complexity - Mierzy strukturę oprogramowania używanego do implementacji algorytmu.

    • Cognitive complexity - Mierzy nakład pracy wymagany do zrozumienia oprogramowania.

Pomiar tych trzech atrybutów można opisać następująco:

Długość

Istnieją trzy produkty programistyczne, których pomiar rozmiaru jest przydatny do przewidywania wysiłku potrzebnego do prognozowania. Są to specyfikacja, projekt i kod.

Specyfikacja i projekt

Dokumenty te zazwyczaj łączą tekst, wykres oraz specjalne schematy i symbole matematyczne. Pomiar specyfikacji może służyć do przewidywania długości projektu, który z kolei jest predyktorem długości kodu.

Diagramy w dokumentach mają jednolitą składnię, taką jak znakowane digrafy, diagramy przepływu danych lub schematy Z. Ponieważ dokumentacja specyfikacji i projektu składa się z tekstów i wykresów, jej długość można zmierzyć za pomocą pary liczb reprezentujących długość tekstu i długość diagramu.

W przypadku tych pomiarów obiekty atomowe należy zdefiniować dla różnych typów diagramów i symboli.

Atomowe obiekty diagramów przepływu danych to procesy, jednostki zewnętrzne, magazyny danych i przepływy danych. Jednostkami atomowymi dla specyfikacji algebraicznych są rodzaje, funkcje, operacje i aksjomaty. Atomowe jednostki dla schematów Z to różne linie pojawiające się w specyfikacji.

Kod

Kod można tworzyć na różne sposoby, na przykład za pomocą języka proceduralnego, orientacji obiektowej i programowania wizualnego. Najczęściej stosowaną tradycyjną miarą długości programu w kodzie źródłowym są linie kodu (LOC).

Całkowita długość,

LOC = NCLOC + CLOC

to znaczy,

LOC = Non-commented LOC + Commented LOC

Oprócz linii kodu, do pomiaru długości można również wykorzystać inne alternatywy, takie jak rozmiar i złożoność sugerowane przez Maurice'a Halsteda.

Nauka o oprogramowaniu Halstead próbowała uchwycić różne cechy programu. Zaproponował trzy wewnętrzne atrybuty programu, takie jak długość, słownictwo i objętość, które odzwierciedlają różne spojrzenia na rozmiar.

Zaczął od zdefiniowania programu Pjako zbiór tokenów klasyfikowanych według operatorów lub operandów. Podstawowe wskaźniki dla tych tokenów to:

  • μ1 = Liczba unikalnych operatorów

  • μ2 = Liczba unikalnych operandów

  • N1 = Całkowita liczba wystąpień operatorów

  • N2 = Liczba unikalnych operatorów

Długość P można zdefiniować jako

$$N = N_{1}+ N_{2}$$

Słownictwo języka P jest

$$\mu =\mu _{1}+\mu _{2}$$

Objętość programu = liczba porównań mentalnych potrzebnych do napisania programu o długości N, jest

$$V = N\times {log_{2}} \mu$$

Poziom programu P objętości V jest,

$$L = \frac{V^\ast}{V}$$

Gdzie, $V^\ast$ jest potencjalną objętością, tj. wielkością minimalnego rozmiaru realizacji P

Odwrotnością poziomu jest trudność -

$$D = 1\diagup L$$

Zgodnie z teorią Halsteada możemy obliczyć szacunek L tak jak

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

Podobnie szacowana długość programu to: $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

Wysiłek wymagany do wygenerowania P jest określony przez,

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

Gdzie jednostka miary E to elementarne mentalne rozróżnienia potrzebne do zrozumienia P

Inne możliwości pomiaru długości to -

  • Pod względem liczby bajtów pamięci komputera wymaganej dla tekstu programu

  • Pod względem liczby znaków w tekście programu

Rozwój zorientowany obiektowo sugeruje nowe sposoby pomiaru długości. Pfleeger i in. odkryli, że liczba obiektów i metod prowadzi do dokładniejszych szacunków produktywności niż te wykorzystujące wiersze kodu.

Funkcjonalność

Ilość funkcjonalności tkwiącej w produkcie jest miarą wielkości produktu. Istnieje wiele różnych metod pomiaru funkcjonalności oprogramowania. Jedną z takich metod - metodę punktów funkcyjnych Albrechta - omówimy w następnym rozdziale.

Metryki punktów funkcyjnych zapewniają znormalizowaną metodę pomiaru różnych funkcji aplikacji. Mierzy funkcjonalność z punktu widzenia użytkownika, czyli na podstawie tego, czego użytkownik żąda i otrzymuje w zamian. Analiza punktów funkcyjnych jest standardową metodą pomiaru rozwoju oprogramowania z punktu widzenia użytkownika.

Miara Function Point pierwotnie wymyślona przez Albrechta zyskała popularność wraz z powstaniem Międzynarodowej Grupy Użytkowników Punktów Funkcyjnych (IFPUG) w 1986 r. W 2002 r. Punkty Funkcyjne IFPUG stały się międzynarodowym standardem ISO - ISO / IEC 20926.

Co to jest punkt funkcyjny?

FP (Function Point)to najbardziej rozpowszechnione metryki typu funkcjonalnego odpowiednie do kwantyfikacji aplikacji. Opiera się na pięciu możliwych do zidentyfikowania przez użytkownika „funkcjach” logicznych, które są podzielone na dwa typy funkcji danych i trzy typy funkcji transakcyjnych. Dla danej aplikacji każdy z tych elementów jest określany ilościowo i ważony, zliczając jego charakterystyczne elementy, takie jak odwołania do plików lub pola logiczne.

Wynikowe liczby (nieskorygowane FP) są grupowane w zestawy funkcji dodanych, zmienionych lub usuniętych i łączone ze współczynnikiem korekty wartości (VAF) w celu uzyskania ostatecznej liczby PR. Dla każdego typu liczenia używana jest odrębna ostateczna formuła: aplikacja, projekt programistyczny lub projekt ulepszenia.

Zastosowanie metody punktów funkcyjnych Albrechta

Zrozummy teraz, jak zastosować metodę punktów funkcyjnych Albrechta. Jego procedura jest następująca -

Określ liczbę składników (EI, EO, EQ, ILF i ELF)

  • EI- Liczba wejść zewnętrznych. Są to podstawowe procesy, w których dane pochodne przechodzą przez granicę z zewnątrz do wewnątrz. W przykładowym systemie bibliotecznej bazy danych wprowadź numer istniejącej karty czytelnika.

  • EO- Liczba wyjść zewnętrznych. Są to podstawowe procesy, w których dane pochodne przechodzą przez granicę z wewnątrz na zewnątrz. W przykładowym systemie bazy danych biblioteki wyświetl listę książek oddanych do czytelnika.

  • EQ- liczba zapytań zewnętrznych. Są to podstawowe procesy zawierające zarówno komponenty wejściowe, jak i wyjściowe, które powodują pobranie danych z jednego lub większej liczby wewnętrznych plików logicznych i zewnętrznych plików interfejsu. W przykładowym systemie bazy danych biblioteki określ, jakie książki są aktualnie wypożyczane do czytelnika.

  • ILF- liczba wewnętrznych plików dziennika. Są to możliwe do zidentyfikowania przez użytkownika grupy logicznie powiązanych danych, które znajdują się całkowicie w granicach aplikacji, które są utrzymywane przez zewnętrzne dane wejściowe. W przykładowym systemie bibliotecznej bazy danych zbiór książek w bibliotece.

  • ELF- Liczba zewnętrznych plików dziennika. Są to możliwe do zidentyfikowania przez użytkownika grupy logicznie powiązanych danych, które są używane wyłącznie w celach informacyjnych i które znajdują się całkowicie poza systemem. W przykładowym systemie bazy danych biblioteki: plik zawierający transakcje w systemie rozliczeniowym biblioteki.

Oblicz nieskorygowaną liczbę punktów funkcyjnych (UFC)

  • Oceń każdy składnik jako low, average, lub high.

  • Do transakcji (EI, EO, and EQ), ocena jest oparta na FTR i DET.

    • FTR - Liczba plików zaktualizowanych lub do których istnieją odniesienia.

    • DET - liczba pól rozpoznawalnych przez użytkownika.

    • Na podstawie poniższej tabeli plik EI który odnosi się do 2 plików i 10 elementów danych zostałoby sklasyfikowany jako average.

FTR DETs
1-5 6-15 >15
0-1 Niska Niska Średni
2-3 Niska Średni Wysoki
>3 Średni Wysoki Wysoki
  • W przypadku plików (ILF and ELF), ocena jest oparta na RET i DET.

    • RET - Liczba rozpoznawalnych przez użytkownika elementów danych w pliku ILF lub ELF.

    • DET - liczba pól rozpoznawalnych przez użytkownika.

    • Na podstawie poniższej tabeli plik ILF zawierający 10 elementów danych i 5 pól zostanie sklasyfikowanych jako high.

RETs DETs
1-5 6-15 >15
1 Niska Niska Średni
2-5 Niska Średni Wysoki
>5 Średni Wysoki Wysoki
  • Konwertuj oceny na UFCs.

Ocena Wartości
EO EQ EI ILF ELF
Low 4 3 3 7 5
Average 5 4 4 10 7
High 6 5 6 15 10

Oblicz ostateczną liczbę punktów funkcyjnych (FPC)

  • Oblicz współczynnik korekty wartości (VAF) na podstawie 14 ogólnych cech systemu (GSC).

Ogólna charakterystyka systemu Krótki opis
GSC 1 Komunikacja danych Ile urządzeń komunikacyjnych jest dostępnych, aby pomóc w przekazywaniu lub wymianie informacji z aplikacją lub systemem?
GSC 2 Rozproszone przetwarzanie danych Jak obsługiwane są rozproszone dane i funkcje przetwarzania?
GSC 3 Wydajność Czy czas odpowiedzi lub przepustowość były wymagane przez użytkownika?
GSC 4 Mocno używana konfiguracja Jak mocno wykorzystywana jest obecna platforma sprzętowa, na której będzie wykonywana aplikacja?
GSC 5 Kurs transakcyjny Jak często wykonywane są transakcje codziennie, co tydzień, co miesiąc itd.?
GSC 6 Wprowadzanie danych on-line Jaki procent informacji jest wprowadzanych online?
GSC 7 Wydajność użytkownika końcowego Czy aplikacja została zaprojektowana z myślą o wydajności użytkownika końcowego?
GSC 8 Aktualizacja on-line Ile ILF jest aktualizowanych przez transakcję online?
GSC 9 Złożone przetwarzanie Czy aplikacja ma obszerne przetwarzanie logiczne lub matematyczne?
GSC 10 Możliwość ponownego użycia Czy aplikacja została stworzona z myślą o potrzebach jednego lub wielu użytkowników?
GSC 11 Łatwość instalacji Jak trudna jest konwersja i instalacja?
GSC 12 Łatwość obsługi Jak skuteczne i / lub zautomatyzowane są procedury uruchamiania, tworzenia kopii zapasowych i odzyskiwania?
OWS 13 Wiele witryn Czy aplikacja została specjalnie zaprojektowana, opracowana i obsługiwana w celu zainstalowania w wielu lokalizacjach w wielu organizacjach?
OWS 14 Ułatw zmiany Czy aplikacja została specjalnie zaprojektowana, opracowana i obsługiwana w celu ułatwienia zmian?
  • Zważ każdy GSC w skali od 0 do 5 w zależności od tego, czy nie ma wpływu na silny wpływ.

  • Oblicz FPC w następujący sposób -

    FPC = UFC * (0,65+ (suma (GSC) * .01))

Złożoność

Złożoność jest oddzielnym składnikiem rozmiaru. Jest dwojakiego rodzaju -

  • Complexity of a problem - To ilość zasobów potrzebnych do optymalnego rozwiązania problemu.

  • Complexity of a solution- To zasoby potrzebne do wdrożenia konkretnego rozwiązania. Ma dwa aspekty. Są następujące -

    • Time complexity - Zasobem jest czas komputera.

    • Space complexity - Zasób to pamięć komputera.

Pomiar złożoności

Jednym z aspektów złożoności jest wydajność. Mierzy każde oprogramowanie, które można zamodelować jako algorytm.

Na przykład: jeśli algorytm rozwiązywania wszystkich wystąpień określonego problemu wymaga f(n) obliczenia f(n) jest asymptotycznie optymalna, jeśli dla każdego innego algorytmu o złożoności g rozwiązuje problem f jest O(g). Wtedy złożoność danego problemu jest duża -O asymptotycznie optymalnego algorytmu rozwiązania problemu.

Pomiar właściwości strukturalnych oprogramowania jest ważny dla oszacowania prac rozwojowych, jak również dla utrzymania produktu. Struktura wymagań, projekt i kod pomaga zrozumieć trudności, jakie pojawiają się przy konwersji jednego produktu na inny, testowaniu produktu lub przewidywaniu atrybutów oprogramowania zewnętrznego na podstawie wczesnych wewnętrznych pomiarów produktu.

Rodzaje środków strukturalnych

Struktura oprogramowania składa się z trzech części. Oni są -

  • Control-flow structure - Jest to sekwencja, w której instrukcje są wykonywane w programie.

  • Data-flow structure - Jest to zachowanie danych podczas interakcji z programem.

  • Data structure - Jest to organizacja elementów danych w postaci list, kolejek, stosów lub innych dobrze zdefiniowanych struktur wraz z algorytmem ich tworzenia, modyfikowania lub usuwania.

Pomiar struktury przepływu sterowania

Miary przepływu sterowania są zwykle modelowane za pomocą wykresu skierowanego, w którym każdy węzeł lub punkt odpowiada instrukcjom programu, a każdy łuk lub skierowana krawędź wskazuje przepływ sterowania z jednej instrukcji do drugiej. Te wykresy nazywane są grafami sterowania lub wykresami skierowanymi.

Gdyby ‘m’ jest miarą strukturalną zdefiniowaną w kategoriach modelu schematu przepływu i programu A jest strukturalnie bardziej złożony niż program B, a następnie środek m(A) powinna być większa niż m(B).

Pomiar struktury przepływu danych

Przepływ danych lub informacji może być międzymodułowy (przepływ informacji w modułach) lub wewnątrzmodułowy (przepływ informacji pomiędzy poszczególnymi modułami a resztą systemu).

Ze względu na sposób, w jaki dane przepływają przez system, można je podzielić na:

  • Local direct flow - Jeśli albo moduł wywołuje drugi moduł i przekazuje do niego informacje, albo wywoływany moduł zwraca wynik do wywołującego.

  • Local indirect flow - Jeśli wywołany moduł zwraca informacje, które są następnie przekazywane do drugiego wywoływanego modułu.

  • Global flow - Jeśli informacje przepływają z jednego modułu do drugiego poprzez globalną strukturę danych.

Złożoność przepływu informacji można wyrazić według Henry'ego i Kafury jako:

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))2

Gdzie,

  • Fan-in (M) - liczba przepływów lokalnych kończących się na M + liczba struktur danych, z których informacje są pobierane przez M.

  • Fan–out (M) - Liczba lokalnych przepływów, które pochodzą z M + liczba struktur danych, które są aktualizowane przez M.

Pomiar struktury danych

Struktura danych może obejmować obie local i global.

Locally, zostanie zmierzona ilość struktury w każdej pozycji danych. Do analizy i pomiaru właściwości poszczególnych struktur danych można zastosować podejście oparte na teorii grafów. W tym przypadku proste typy danych, takie jak liczby całkowite, znaki i wartości logiczne, są postrzegane jako liczby pierwsze i rozważane są różne operacje, które pozwalają nam budować bardziej złożone struktury danych. Miary struktury danych można następnie zdefiniować hierarchicznie pod względem wartości liczb pierwszych i wartości powiązanych z różnymi operacjami.

Globally, zostanie zmierzona całkowita liczba zmiennych zdefiniowanych przez użytkownika.

W rozwój standardów SQA zaangażowanych jest kilka krajowych i międzynarodowych instytutów normalizacyjnych, organizacji zawodowych i branżowych.

Następujące instytuty i organizacje są głównymi twórcami standardów SQA i inżynierii oprogramowania -

  • IEEE (Institute of Electrical and Electronics Engineers) Computer Society
  • ISO (Międzynarodowa Organizacja Normalizacyjna)
  • DOD (Departament Obrony USA)
  • ANSI (American National Standards Institute)
  • IEC (Międzynarodowa Komisja Elektrotechniczna)
  • EIA (Electronic Industries Association)

Organizacje te zapewniają zaktualizowane międzynarodowe standardy jakości działań zawodowych i kierowniczych wykonywanych w organizacjach zajmujących się opracowywaniem i utrzymaniem oprogramowania.

Zapewniają również certyfikację SQA poprzez niezależne profesjonalne audyty jakości. Te zewnętrzne audyty oceniają osiągnięcia w rozwoju systemów SQA i ich wdrażaniu. Certyfikacja, która jest przyznawana po audytach okresowych, będzie ważna tylko do następnego auditu, w związku z czym musi zostać odnowiona. Obecnie Usługa Certyfikacji ISO 9000 jest najważniejszym dostawcą certyfikacji SQA w Europie i innych krajach.

Dostarczają także narzędzi do samooceny systemu SQA organizacji i jego funkcjonowania. Model dojrzałości wydajności (CMM) opracowany przez Software Engineering Institute (SEI), Carnegie Mellon University i ISO / IEC Std 15504 są przykładami tego podejścia.

Standardy SQA

Standardy zapewniania jakości oprogramowania można podzielić na dwie główne klasy -

  • Standardy zarządzania zapewnianiem jakości oprogramowania, w tym metodologie certyfikacji i oceny (standardy zarządzania jakością)

  • Standardy procesu tworzenia projektów oprogramowania (standardy procesu projektowego)

Standardy zarządzania jakością

Koncentrują się one na systemie SQA organizacji, infrastrukturze i wymaganiach, pozostawiając wybór metod i narzędzi organizacji. Dzięki standardom zarządzania jakością organizacje mogą stale zapewniać, że ich oprogramowanie osiąga akceptowalny poziom jakości.

Example - ISO 9000-3 i model dojrzałości zdolności (CMM)

Standardy procesu projektowego

Koncentrują się one na metodologiach wdrażania projektów rozwoju i utrzymania oprogramowania. Normy te obejmują:

  • Kroki, które należy podjąć
  • Wymagania dotyczące dokumentacji projektowej
  • Treść dokumentów projektowych
  • Recenzje projektów i problemy z recenzjami
  • Testowanie oprogramowania do wykonania
  • Tematy testowe

Oczywiście, ze względu na swoje właściwości, wiele standardów SQA w tej klasie może służyć jako standardy inżynierii oprogramowania i odwrotnie.

Charakterystykę tych dwóch klas norm podsumowano w poniższej tabeli.

Charakterystyka Standardy zarządzania jakością Standardy procesu projektowego
Jednostka docelowa Zarządzanie rozwojem oprogramowania, utrzymaniem i określonymi jednostkami SQA Zespół projektu rozwoju i utrzymania oprogramowania
Główny cel Organizacja systemów, infrastruktury i wymagań SQA Metodologie prowadzenia projektów rozwoju i utrzymania oprogramowania
Cel normy „Co” osiągnąć "Jak wystąpić
Cel standardu Zapewnienie jakości oprogramowania dostawcy i ocena możliwości jego procesu tworzenia oprogramowania Zapewnienie jakości oprogramowania dostawcy i ocena możliwości jego procesu tworzenia oprogramowania Zapewnienie jakości konkretnego projektu oprogramowania.
Przykłady WMP ISO 9000-3 SEI ISO / IEC 12207 IEEEStd 1012-1998

Certyfikat ISO 9001

ISO (Międzynarodowa Organizacja Normalizacyjna) jest światową federacją krajowych organów normalizacyjnych. Komitety techniczne ISO przygotowują Normy Międzynarodowe. ISO ściśle współpracuje z Międzynarodową Komisją Elektrotechniczną (IEC) we wszystkich kwestiach normalizacji elektrotechnicznej.

Normy międzynarodowe są opracowywane zgodnie z zasadami podanymi w Dyrektywach ISO / IEC, Część 2. Projekt Norm Międzynarodowych przyjęty przez komitety techniczne jest przekazywany organom członkowskim do głosowania. ISO 9001 został przygotowany przez Komitet Techniczny ISO / TC 176, Zarządzanie jakością i zapewnienie jakości, Podkomitet SC 2, Systemy jakości.

Podejście procesowe

Niniejsza Norma Międzynarodowa promuje przyjęcie podejścia procesowego przy opracowywaniu, wdrażaniu i ulepszaniu skuteczności systemu zarządzania jakością w celu zwiększenia satysfakcji klienta poprzez spełnienie jego wymagań. Aby organizacja mogła efektywnie funkcjonować, musi określić i zarządzać wieloma powiązanymi działaniami. Działanie lub zestaw działań wykorzystujących zasoby i zarządzanych w celu umożliwienia przekształcenia nakładów w produkty można uznać za proces.

Często dane wyjściowe jednego procesu bezpośrednio stanowią dane wejściowe do następnego. Zastosowanie systemu procesów w organizacji, wraz z identyfikacją i interakcjami tych procesów oraz zarządzaniem nimi w celu uzyskania pożądanego rezultatu, można nazwać“process approach”.

Zaletą podejścia procesowego jest ciągła kontrola, którą zapewnia powiązanie pomiędzy poszczególnymi procesami w systemie procesów, a także ich kombinację i interakcję. Takie podejście stosowane w systemie zarządzania jakością podkreśla znaczenie następujących -

  • Zrozumienie i spełnienie wymagań
  • Trzeba rozpatrywać procesy w kategoriach wartości dodanej
  • Uzyskaj wyniki wydajności i skuteczności procesu
  • Ciągłe doskonalenie procesów w oparciu o obiektywny pomiar

ISO 9001 - Application to Software: the TickIT Initiative

TickIT został uruchomiony pod koniec lat 80. przez brytyjski przemysł oprogramowania we współpracy z brytyjskim Departamentem Handlu i Przemysłu w celu promowania rozwoju metodologii dostosowania ISO 9001 do specyfiki branży oprogramowania, znanej jako inicjatywa TickIT.

TickIT dodatkowo specjalizuje się w informatyce (IT). Obejmuje cały zakres usług związanych z tworzeniem i utrzymaniem oprogramowania komercyjnego. TickIT, obecnie zarządzany i utrzymywany przez Departament DISC BSI (British Standards Institute), posiada akredytację w zakresie certyfikacji organizacji IT w Wielkiej Brytanii i Szwecji.

Jego działalność obejmuje -

  • Publikacja przewodnika TickIT, który wspiera wysiłki branży oprogramowania mające na celu rozpowszechnianie certyfikacji ISO 9001. Aktualny przewodnik (wydanie 5.0, TickIT, 2001), który zawiera odniesienia do ISO / IEC 12207 i ISO / IEC 15504, jest rozprowadzany do wszystkich klientów TickIT.

  • Wykonywanie opartych na audytach ocen systemów jakości oprogramowania oraz konsultacje dla organizacji w zakresie doskonalenia procesów rozwoju i utrzymania oprogramowania, oprócz zarządzania nimi.

  • Przeprowadzaj audyty certyfikacyjne ISO 9000.

Audytorzy TickIT, którzy przeprowadzają oceny oparte na audytach i audyty certyfikacyjne, są zarejestrowani w Międzynarodowym Rejestrze Certyfikowanych Audytorów (IRCA). Zarejestrowani audytorzy IRCA są zobowiązani między innymi do posiadania doświadczenia w zarządzaniu i tworzeniu oprogramowania; muszą również pomyślnie ukończyć kurs audytora.

Zarejestrowani audytorzy wiodący są zobowiązani do posiadania udokumentowanego doświadczenia w przeprowadzaniu i kierowaniu audytami TickIT.

Ocena procesu tworzenia oprogramowania to zdyscyplinowane badanie procesów oprogramowania stosowanych w organizacji w oparciu o model procesu. Ocena obejmuje identyfikację i charakterystykę obecnych praktyk, identyfikację obszarów mocnych i słabych stron oraz zdolność obecnych praktyk do kontrolowania lub unikania istotnych przyczyn niskiej jakości (oprogramowania), kosztów i harmonogramu.

Ocena oprogramowania (lub audyt) może mieć trzy typy.

  • ZA self-assessment (first-party assessment) jest wykonywana wewnętrznie przez własny personel organizacji.

  • ZA second-party assessment jest przeprowadzana przez zewnętrzny zespół oceniający lub organizacja jest oceniana przez klienta.

  • ZA third-party assessment jest wykonywana przez stronę zewnętrzną lub (np. dostawca oceniany przez stronę trzecią w celu zweryfikowania jego zdolności do zawierania umów z klientem).

Oceny procesów oprogramowania są przeprowadzane w otwartym i opartym na współpracy środowisku. Przeznaczone są do użytku organizacji w celu ulepszenia jej procesów oprogramowania, a wyniki są poufne dla organizacji. Oceniana organizacja musi mieć członków zespołu oceniającego.

Ocena dojrzałości procesu tworzenia oprogramowania

Zakres oceny procesu tworzenia oprogramowania może obejmować wszystkie procesy w organizacji, wybrany podzbiór procesów oprogramowania lub określony projekt. Większość podejść do oceny procesu opartych na standardach niezmiennie opiera się na koncepcji dojrzałości procesu.

Gdy celem oceny jest organizacja, wyniki oceny procesu mogą się różnić, nawet przy kolejnych zastosowaniach tej samej metody. Istnieją dwa powody różnych wyników. Oni są,

  • Należy określić badaną organizację. W przypadku dużej firmy możliwych jest kilka definicji organizacji, dlatego rzeczywisty zakres oceny może się różnić w kolejnych ocenach.

  • Nawet w przypadku tego, co wydaje się być tą samą organizacją, próbka projektów wybrana do reprezentowania organizacji może wpływać na zakres i wynik.

Gdy docelowa jednostka oceny znajduje się na poziomie projektu, ocena powinna obejmować wszystkie znaczące czynniki, które przyczyniają się do sukcesu lub niepowodzenia projektu. Nie należy go ograniczać ustalonymi wymiarami danego modelu dojrzałości procesu. Tutaj ocenia się stopień realizacji i ich skuteczność, potwierdzoną danymi z projektu.

Dojrzałość procesu staje się istotna, gdy organizacja zamierza zastosować ogólną długoterminową strategię doskonalenia. Oceny projektów oprogramowania powinny być niezależnymi ocenami, aby były obiektywne.

Cykl oceny procesu tworzenia oprogramowania

Według Paulka i współpracowników (1995) podejście do oceny oparte na CMM wykorzystuje sześciostopniowy cykl. Oni są -

  • Wybierz zespół - członkowie zespołu powinni być profesjonalistami posiadającymi wiedzę w zakresie inżynierii oprogramowania i zarządzania.

  • Przedstawiciele ocenianego miejsca wypełniają standardowy kwestionariusz dojrzałości procesu.

  • Zespół oceniający przeprowadza analizę odpowiedzi na pytania zawarte w kwestionariuszu i identyfikuje obszary, które wymagają dalszej eksploracji zgodnie z kluczowymi obszarami procesu CMM.

  • Zespół oceniający przeprowadza wizytę w witrynie w celu zrozumienia procesu tworzenia oprogramowania w witrynie.

  • Zespół oceniający sporządza listę ustaleń, która identyfikuje mocne i słabe strony procesu tworzenia oprogramowania w organizacji.

  • Zespół oceniający przygotowuje analizę profilu Kluczowego Obszaru Procesu (KPA) i przedstawia wyniki odpowiedniej grupie odbiorców.

Na przykład, zespołem oceniającym musi kierować upoważniony Główny Asesor SEI. Zespół musi składać się z od czterech do dziesięciu członków zespołu. Co najmniej jeden członek zespołu musi pochodzić z ocenianej organizacji, a wszyscy członkowie zespołu muszą ukończyć wprowadzenie SEI do kursu CMM (lub jego odpowiednika) oraz szkolenie zespołu SEI CBA IPI. Członkowie zespołu muszą również spełnić pewne wytyczne dotyczące selekcji.

Jeśli chodzi o gromadzenie danych, CBA IPI opiera się na czterech metodach:

  • Standardowy kwestionariusz dojrzałości
  • Wywiady indywidualne i grupowe
  • Recenzje dokumentów
  • Informacja zwrotna z przeglądu wstępnych ustaleń z uczestnikami oceny

SCAMPI

Standardowa metoda oceny CMMI dla doskonalenia procesu (SCAMPI) została opracowana w celu spełnienia wymagań modelu CMMI (Software Engineering Institute, 2000). Opiera się również na CBA IPI. Zarówno CBA IPI, jak i SCAMPI składają się z trzech faz -

  • Plan i przygotowanie
  • Przeprowadź ocenę na miejscu
  • Zgłoś wyniki

Działania związane z planem i fazą przygotowawczą obejmują:

  • Określ zakres oceny
  • Opracuj plan oceny
  • Przygotuj i przeszkol zespół oceniający
  • Dokonaj krótkiej oceny uczestników
  • Administrować kwestionariuszem oceny CMMI
  • Sprawdź odpowiedzi na pytania zawarte w kwestionariuszu
  • Przeprowadź wstępny przegląd dokumentów

Działania na etapie oceny na miejscu obejmują:

  • Przeprowadź spotkanie otwierające
  • Prowadzić przesłuchania
  • Skonsoliduj informacje
  • Przygotuj prezentację wstępnych ustaleń
  • Przedstaw wstępne ustalenia
  • Konsoliduj, oceniaj i przygotuj ostateczne ustalenia

Działania w fazie raportowania wyników obejmują:

  • Przedstaw ostateczne ustalenia
  • Przeprowadź sesję wykonawczą
  • Podsumuj ocenę

Definicja IEEE dotycząca zapewniania jakości oprogramowania jest następująca:

„Zaplanowany i systematyczny wzorzec wszystkich działań niezbędnych do zapewnienia odpowiedniej pewności, że przedmiot lub produkt spełnia ustalone wymagania techniczne. Zestaw działań opracowanych w celu oceny procesu, w ramach którego produkty są opracowywane lub wytwarzane”.

Cele działań SQA

Cele działań SQA są następujące -

W tworzeniu oprogramowania (zorientowane na proces)

  • Zapewnienie akceptowalnego poziomu pewności, że oprogramowanie będzie zgodne z funkcjonalnymi wymaganiami technicznymi.

  • Zapewnienie akceptowalnego poziomu pewności, że oprogramowanie będzie zgodne z harmonogramem kierowniczym i wymaganiami budżetowymi.

  • Inicjowanie i zarządzanie działaniami na rzecz doskonalenia i zwiększania efektywności tworzenia oprogramowania i działań SQA.

Konserwacja oprogramowania (zorientowana na produkt)

  • Zapewnienie z akceptowalnym poziomem pewności, że działania związane z utrzymaniem oprogramowania będą zgodne z funkcjonalnymi wymaganiami technicznymi.

  • Zapewnienie z akceptowalnym poziomem pewności, że działania związane z utrzymaniem oprogramowania będą zgodne z harmonogramem kierowniczym i wymaganiami budżetowymi.

  • Inicjowanie i zarządzanie działaniami usprawniającymi i zwiększającymi efektywność utrzymania oprogramowania i działań SQA. Wiąże się to z poprawą perspektyw spełnienia wymagań funkcjonalnych i zarządczych przy jednoczesnym obniżeniu kosztów.

Organizacja zapewniająca jakość

Ramy organizacyjne zapewniania jakości, które działają w ramach struktury organizacyjnej, obejmują następujących uczestników:

Menedżerowie

  • Kadra kierownicza najwyższego szczebla, zwłaszcza osoba zarządzająca bezpośrednio odpowiedzialna za zapewnienie jakości oprogramowania

  • Kierownicy działów rozwoju i utrzymania oprogramowania

  • Kierownicy działów testowania oprogramowania

  • Kierownicy projektów i liderzy zespołów projektów rozwoju i utrzymania

  • Liderzy zespołów testujących oprogramowanie

Testerzy

  • Członkowie zespołów testujących oprogramowanie

Specjaliści SQA i zainteresowani praktycy -

  • Powiernicy SQA
  • Członkowie komitetu SQA
  • Członkowie forum SQA
  • Członkowie zespołu jednostki SQA

Jedynie kierownicy i pracownicy działu testowania oprogramowania są zajęci w pełnym wymiarze godzin przy wykonywaniu zadań SQA. Inni poświęcają część swojego czasu kwestiom jakości, czy to podczas pełnienia funkcji kierowniczych lub zadań zawodowych, czy też jako wolontariusze w innych, najczęściej komitecie SQA, forum SQA lub jako powiernicy SQA.

Zasadniczo w organizacjach tworzących oprogramowanie istnieje trójpoziomowa struktura zarządzania -

  • Najwyższe kierownictwo
  • Zarządzanie działem
  • Zarządzanie projektami

Obowiązki najwyższego kierownictwa w zakresie jakości oprogramowania

Poniżej przedstawiono obowiązki najwyższego kierownictwa w zapewnianiu jakości oprogramowania -

  • Zapewnienie jakości oprogramowania firmy i usług konserwacji oprogramowania

  • Informuj pracowników wszystkich szczebli o znaczeniu jakości produktów i usług, a także satysfakcji klienta

  • Zapewniamy satysfakcjonujące funkcjonowanie i pełną zgodność z wymaganiami klienta

  • Upewnij się, że cele jakościowe są ustalone dla systemu SQA organizacji i że jego cele są osiągnięte

  • Inicjowanie planowania i nadzorowanie wdrażania zmian niezbędnych do dostosowania systemu SQA do głównych zmian wewnętrznych i zewnętrznych związanych z klientelą organizacji, konkurencją i technologią

  • Interweniuj bezpośrednio, aby wspierać rozwiązywanie sytuacji kryzysowych i minimalizować szkody

  • Zapewnij dostępność zasobów wymaganych przez systemy SQA

Najwyższe kierownictwo może podjąć następujące kroki, aby wypełnić swoje obowiązki:

  • Ustanowienie i aktualizacja polityki jakości oprogramowania organizacji.

  • Wyznaczenie jednego z kierowników, takiego jak wiceprezes ds. SQA, odpowiedzialnego za kwestie jakości oprogramowania

  • Prowadzenie regularnych przeglądów zarządzania wydajnością pod kątem problemów z jakością oprogramowania

Polityka jakości oprogramowania

Polityka jakości oprogramowania organizacji powinna komunikować następujące wymagania -

  • Zgodność z celem i celami organizacji

  • Zaangażowanie w ogólne koncepcje zapewniania jakości oprogramowania

  • Zaangażowanie w standardy jakości przyjęte przez organizację

  • Zobowiązanie do przydzielenia odpowiednich zasobów w celu zapewnienia jakości oprogramowania

  • Zaangażowanie w ciągłe doskonalenie jakości i produktywności organizacji

Kierownik odpowiedzialny za jakość oprogramowania

Obowiązki dyrektora odpowiedzialnego za kwestie jakości oprogramowania można podzielić na:

  • Odpowiedzialność za przygotowanie rocznego programu i budżetu działań SQA

  • Odpowiedzialność za przygotowanie planów rozwoju systemu SQA

  • Ogólna kontrola realizacji rocznego programu regularnych działań SQA i planowanych projektów rozwoju SQA

  • Prezentacja i popieranie kwestii SQA kierownictwu wykonawczemu

Odpowiedzialność za przygotowanie rocznego programu działań SQA

Wymaga to od wykonawcy:

  • Ustal cele SQA systemu na nadchodzący rok

  • Przegląd propozycji przygotowanych przez jednostkę SQA dla rocznego programu działań i weryfikacja potencjału propozycji w zakresie realizacji celów wyznaczonych dla systemu SQA

  • Określić, czy program działań jest adekwatny do specyfiki i zakresu usług podwykonawców oraz zakupów oprogramowania planowanych na nadchodzący rok

  • Określić adekwatność siły roboczej i innych zasobów planowanych do realizacji programu SQA

  • Zatwierdź ostateczną wersję rocznego programu i budżetu działań SQA

Odpowiedzialność za przygotowanie planów rozwoju systemu SQA

Plany te muszą być dostosowane do zmian technologicznych, a także wymagań klientów i konkurencji. Obowiązki obejmują -

  • Przegląd trendów, które mają wpłynąć na jakość oprogramowania organizacji w najbliższej przyszłości

  • Przegląd propozycji adaptacji SQA, takich jak przygotowanie nowych procedur odpowiednich do nowych narzędzi i standardów SQA

  • Przygotowanie programów szkoleniowych dla doświadczonych zespołów programistycznych i nowo rekrutowanych członków zespołu

  • Opracowanie mierników jakości oprogramowania odpowiednich do oceny nowych narzędzi i standardów, a także sukcesu programów szkoleniowych

  • Zatwierdzenie ostatecznej wersji planowanych projektów deweloperskich SQA, w tym ich harmonogramów i budżetów

Ogólna kontrola realizacji rocznego programu SQA

Osoba zarządzająca jest odpowiedzialna za:

  • Ogólny nadzór nad rocznym programem działań

  • Przegląd postępów w projektach adaptacyjnych SQA

  • Ogólny nadzór nad działaniami podejmowanymi w celu realizacji osiągnięć jakościowych podyktowanych celami zespołów (na podstawie okresowych raportów)

  • Przegląd zgodności z procedurami i standardami SQA na podstawie wewnętrznych audytów jakości

  • Ogólne monitorowanie zgodności z harmonogramami i budżetami projektów tworzenia oprogramowania

  • Ogólne monitorowanie świadczenia usług utrzymania jakości klientom zewnętrznym i wewnętrznym

Prezentacja i popieranie kwestii SQA dla kierownictwa wykonawczego

W celu promowania jakości i rozwiązywania problemów związanych z systemem SQA wymaga -

  • Przedstawienie do ostatecznego zatwierdzenia proponowanego rocznego programu działań i budżetu

  • Prezentacja do ostatecznego zatwierdzenia planowanych projektów adaptacyjnych SQA wraz z odpowiednimi budżetami

  • Inicjowanie i prowadzenie okresowych spotkań przeglądowych kierownictwa poświęconych jakości oprogramowania organizacji

  • Rozpoczęcie dyskusji na szczeblu kierowniczym poświęconych szczególnym zdarzeniom związanym z jakością oprogramowania, takim jak poważne awarie jakości, zagrożenia pomyślnego zakończenia projektów z powodu poważnych niedoborów kadrowych, kryzysów menedżerskich w jednostce SQA itp.

Obowiązki kierownictwa działu SQA

Do obowiązków kierownictwa średniego szczebla w zakresie zapewnienia jakości należą:

  • Zarządzanie systemem zarządzania jakością oprogramowania (zadania związane z systemem jakości)

  • Zarządzanie zadaniami związanymi z projektami i usługami wykonywanymi przez jednostki lub zespoły z upoważnienia danego kierownika (zadania projektowe)

Obowiązki związane z systemem jakości

Obejmują one działania SQA do wykonania na poziomie działu -

  • Przygotowanie rocznego programu i budżetu działań działu SQA na podstawie rekomendowanego programu przygotowanego przez jednostkę SQA

  • Przygotowanie planów rozwoju systemów SQA wydziału w oparciu o rekomendowany plan przygotowany przez jednostkę SQA

  • Kontrola realizacji rocznego programu działań SQA departamentu i projektów rozwojowych

  • Prezentacja zagadnień SQA działu najwyższemu kierownictwu

Obowiązki związane z projektem

Różnią się one w zależności od procedur organizacji i podziału uprawnień; zazwyczaj obejmują -

  • Kontrola przestrzegania procedur zapewnienia jakości w jednostkach departamentu, w tym w organach CAB, SCM i SCCA

  • Szczegółowe działania następcze po wynikach przeglądu umów i zatwierdzeniach propozycji

  • Przegląd wykonania przez jednostkę planowanych działań przeglądowych; zatwierdzenie dokumentów projektowych i zakończenie fazy projektowej

  • Śledzenie testów oprogramowania i wyników testów; zatwierdzanie oprogramowania projektu

  • Śledzenie postępów w realizacji harmonogramów projektów rozwoju oprogramowania i odchyleń budżetowych

  • Doradztwo i wsparcie dla kierowników projektów w rozwiązywaniu problemów związanych z harmonogramem, budżetem i relacjami z klientami

  • Monitorowanie jakości świadczonych usług serwisowych

  • Szczegółowe monitorowanie ryzyk projektowych i ich rozwiązań

  • Monitorowanie zgodności projektu z wymaganiami klienta i jego satysfakcji

  • Zatwierdzanie dużych zleceń zmiany oprogramowania i znacznych odchyleń od specyfikacji projektu

Odpowiedzialność za zarządzanie projektem w zakresie jakości oprogramowania

Większość obowiązków związanych z zarządzaniem projektem jest określona w procedurach i instrukcjach roboczych; kierownik projektu jest osobą odpowiedzialną za zapewnienie, że wszyscy członkowie zespołu przestrzegają wspomnianych procedur i instrukcji.

Do jego zadań należą zadania zawodowe i kierownicze, w szczególności:

  • Professional hands-on tasks

    • Przygotowanie projektów i planów jakości oraz ich aktualizacja

    • Udział we wspólnym komitecie klientów i dostawców

    • Ścisłe monitorowanie personelu zespołu projektowego, w tym udział w rekrutacji, szkoleniach i instruktażach

  • Management tasks

    Kierownicy projektów zajmują się następującymi kwestiami, takimi jak -

    • Wykonywanie czynności przeglądowych i wynikających z nich korekt

    • Wykonywanie czynności związanych z tworzeniem i utrzymaniem oprogramowania, działaniami integracyjnymi i testami systemowymi oraz poprawkami i testami regresyjnymi

    • Przeprowadzenie testów akceptacyjnych

    • Instalacja oprogramowania w zdalnych lokalizacjach klienta i wykonanie systemu oprogramowania przez klienta

    • Szkolenie SQA i instruktaż członków zespołu projektowego

    • Harmonogramy i zasoby przydzielone na działania projektowe

    • Żądania i satysfakcja klientów

    • Ewoluujące ryzyko związane z opracowywaniem projektów, stosowanie rozwiązań i kontrola wyników

Struktura jednostki SQA różni się w zależności od rodzaju i wielkości organizacji. Poniższy rysunek przedstawia przykład standardowej konstrukcji i wszystkich komponentów w jednostce SQA. W tym rozdziale omówimy role i obowiązki każdej podjednostki.

Zadania wykonywane przez Kierownika Jednostki SQA

Kierownik jednostki SQA jest odpowiedzialny za wszystkie zadania związane z zapewnieniem jakości realizowane przez jednostkę SQA i jej pododdziały. Zadania te można podzielić na następujące kategorie -

  • Planowanie zadań
  • Zarządzanie jednostką
  • Działalność zawodowa SQA

Planowanie zadań

  • Przygotowanie proponowanego rocznego programu działań i budżetu jednostki

  • Planowanie i aktualizacja systemu zarządzania jakością oprogramowania w organizacji

  • Przygotowanie rekomendowanych rocznych programów działań SQA i planów rozwoju systemów SQA dla działów rozwoju i utrzymania oprogramowania

Zadania zarządcze

  • Zarządzanie działaniami zespołu SQA

  • Monitorowanie realizacji programu działań SQA

  • Nominacja członków zespołu, członków komisji SQA i powierników SQA

  • Sporządzanie raportów specjalnych i okresowych, np. Stanu problemów z jakością oprogramowania w organizacji oraz miesięcznych raportów wydajnościowych

Działania SQA Professional

  • Udział we wspólnych komitetach projektowych
  • Udział w formalnych przeglądach projektów
  • Przegląd i zatwierdzenie odstępstw od specyfikacji
  • Konsultacje z kierownikami projektów i liderami zespołów
  • Udział w komitetach i forach SQA

Cykl życia projektu SQA

Zadania SQA związane z podjednostką cyklu życia projektu można podzielić na dwie grupy -

  • „Czyste” kierownicze zadania związane z monitorowaniem i zatwierdzaniem (zadania związane z kontrolą cyklu życia projektu)

  • „Praktyczny” lub aktywny udział w działaniach SQA zespołu projektowego, gdzie wymagany jest wkład zawodowy (zadania partycypacyjne)

Zadania kontroli cyklu życia projektu

  • Monitorowanie przestrzegania przez zespół ds. Rozwoju i utrzymania procedur SQA i instrukcji pracy

  • Zatwierdzanie lub rekomendowanie oprogramowania zgodnie z odpowiednimi procedurami

  • Monitorowanie świadczenia usług utrzymania oprogramowania klientom wewnętrznym i zewnętrznym

  • Monitorowanie satysfakcji klienta i utrzymywanie kontaktu z przedstawicielami zapewnienia jakości klienta

Zadania partycypacyjne

Zadania te obejmują udział w -

  • Przeglądy umów
  • Przygotowanie i aktualizacja planów rozwoju projektów i jakości
  • Formalne przeglądy projektów
  • Formalne przeglądy projektów podwykonawców
  • Testowanie oprogramowania, w tym testy akceptacyjne klienta
  • Testy akceptacyjne oprogramowania podwykonawców
  • Instalacja nowych produktów oprogramowania

Zadania operacyjne infrastruktury SQA

Systemy SQA wykorzystują różnorodne komponenty infrastruktury, aby działać płynnie, a mianowicie -

  • Procedury i instrukcje pracy
  • Obsługa urządzeń wysokiej jakości (szablony, listy kontrolne)
  • Szkolenie personelu, instruktaż i certyfikacja
  • Działania zapobiegawcze i naprawcze
  • Zarządzanie konfiguracją
  • Kontrola dokumentacji

Dokładniej, zadania pododdziału SQA dotyczące tych komponentów obejmują:

  • Publikacja zaktualizowanych wersji procedur, instrukcji pracy, szablonów, list kontrolnych itp., Wraz z ich obiegiem w formie papierowej i / lub drogą elektroniczną

  • Przekazywanie szkoleń i instrukcji dotyczących przestrzegania i stosowania procedur SQA, instrukcji pracy i podobnych elementów nowym i obecnym pracownikom

  • Instruktaż powierników SQA dotyczący nowych i poprawionych procedur, a także narzędzi i metod programistycznych, między innymi

  • Monitorowanie i wspieranie wdrażania nowych i poprawionych procedur SQA

  • Kontynuacja działań w zakresie certyfikacji personelu

  • Propozycja tematów wymagających działań prewencyjnych i korygujących, w tym udziału w komitetach CAB

  • Kontynuacja działań związanych z zarządzaniem konfiguracją, w tym udział w komitetach CCA

  • Monitorowanie przestrzegania procedur dokumentacji i instrukcji pracy

Zadania audytu wewnętrznego i certyfikacji SQA

Rodzaje audytów SQA przeprowadzanych w organizacjach oprogramowania lub przez organizacje programistyczne można sklasyfikować w następujący sposób:

  • Audyty wewnętrzne

  • Audyty podwykonawców i dostawców w celu oceny ich systemów SQA

  • Audyty zewnętrzne przeprowadzane przez jednostki certyfikujące

  • Audyty zewnętrzne wykonywane przez klientów, którzy chcą ocenić system SQA przed przyjęciem organizacji jako dostawcy

Pierwsze dwie klasy audytów są inicjowane i przeprowadzane przez pododdział SQA, dwie ostatnie przez organy zewnętrzne.

Jednostka SQA wykonuje następujące zadania dla wewnętrznych audytów SQA

  • Przygotowanie rocznych programów audytów wewnętrznych SQA

  • Przeprowadzanie wewnętrznych audytów SQA

  • Kontynuacja poprawek i ulepszeń do wykonania przez kontrolowane zespoły i inne jednostki

  • Przygotowywanie okresowych raportów podsumowujących stan ustaleń z audytu, w tym rekomendacji ulepszeń

Jednostka SQA realizuje następujące zadania w zakresie audytów podwykonawców i dostawców -

  • Przygotowanie rocznego programu audytów SQA podwykonawców i dostawców

  • Przeprowadzanie audytów SQA podwykonawców i dostawców

  • Monitorowanie poprawek i ulepszeń, które mają zostać przeprowadzone przez skontrolowanych podwykonawców i dostawców

  • Zbieranie danych o wynikach podwykonawców i dostawców ze źródeł wewnętrznych i zewnętrznych

  • Okresowa ocena systemów SQA certyfikowanych podwykonawców i dostawców organizacji na podstawie raportów z audytów oraz informacji zebranych z innych źródeł wewnętrznych i zewnętrznych. Raport z oceny zawiera -

    • Zalecenia dotyczące certyfikacji podwykonawców i dostawców

    • Audyty zewnętrzne przeprowadzane przez jednostki certyfikujące obejmują następujące zadania -

      • Koordynacja treści i harmonogramu audytu certyfikacyjnego

      • Przygotowanie dokumentów określonych przez jednostki certyfikujące

      • Pouczenie audytowanych zespołów i wykonanie przygotowań do audytów certyfikujących

      • Udział w audytach certyfikacyjnych

      • Upewnij się, że wprowadzono wymagane poprawki i ulepszenia

Audyty SQA wykonywane przez klientów organizacji obejmują następujące zadania -

  • Koordynacja treści i harmonogramu audytu

  • Przygotowanie dokumentów określonych przez audytora klienta

  • Pouczenie audytowanych zespołów i wykonanie przez klientów organizacji przygotowań do audytów SQA

  • Udział w audytach

  • Upewnij się, że zostały wykonane wymagane poprawki i ulepszenia

Zadania wsparcia SQA

Większość odbiorców usług wsparcia SQA znajduje się w organizacji. Są wśród nich kierownicy projektów, liderzy zespołów i powiernicy SQA. Do ich zadań należy:

  • Przygotowanie planów projektów i planów jakości projektów

  • Zespoły oceniające personel

  • Wybór środków w celu rozwiązania zidentyfikowanych zagrożeń związanych z tworzeniem oprogramowania

  • Wybór środków w celu rozwiązania problemów z opóźnieniami w harmonogramie i przekroczeniami budżetu

  • Wybór mierników SQA i składników kosztów oprogramowania

  • Korzystanie z systemu informacyjnego SQA

  • Wybór metodologii i narzędzi programistycznych, które odzwierciedlają dane o doświadczeniach awarii zgromadzone przez jednostkę SQA

Standardy i procedury SQA Zadania

Podjednostka SQA jest ściśle zaangażowana w podejmowanie decyzji, które standardy SQA zostaną przyjęte, a także w opracowywanie i utrzymywanie procedur organizacji. Aby wypełnić związane z tym obowiązki, jednostka SQA musi:

  • Przygotowanie rocznego programu rozwoju nowych procedur i aktualizacji procedur

  • Odpowiadać za opracowywanie nowych procedur i aktualizacje procedur, z udziałem w odpowiednich komitetach i forach

  • Śledzenie rozwoju i zmian w standardach SQA i inżynierii oprogramowania; wprowadzenie dodatkowych procedur i zmian istotnych dla organizacji

  • Inicjowanie aktualizacji i dostosowań procedur w odpowiedzi na zmiany standardów zawodowych, w tym przyjęcie lub usunięcie standardów stosowanych przez organizację

Zadania inżynierskie SQA

Śledzenie postępów zawodowych, rozwiązywanie problemów operacyjnych i ekspercka analiza awarii to bezpośrednie cele tej podjednostki SQA.

Stąd główne zadania inżynieryjne obejmują:

  • Testowanie aspektów jakości i produktywności w odniesieniu do nowych narzędzi programistycznych i nowych wersji obecnie używanych narzędzi programistycznych

  • Ocena jakości i produktywności nowych metod rozwoju i konserwacji oraz doskonalenie metod

  • Opracowanie rozwiązań problemów napotykanych w stosowaniu aktualnie stosowanych narzędzi i metod wytwarzania oprogramowania

  • Rozwój metod pomiaru jakości oprogramowania i produktywności zespołu

  • Zapewnienie wsparcia technologicznego komitetom CAB przy analizach awarii oprogramowania i formułowaniu proponowanych rozwiązań

Zadania SQA Information Systems

Systemy informacyjne SQA mają na celu ułatwienie i usprawnienie funkcjonowania systemów SQA. Do zadań należy:

  • Rozwój systemów informatycznych SQA dla jednostek rozwoju i utrzymania oprogramowania dla

    • zbieranie danych dotyczących działalności

    • przetwarzanie np. raportów okresowych, list, raportów o wyjątkach i zapytań

    • przetwarzanie np. raportów okresowych, list, raportów o wyjątkach i zapytań

  • Rozwój systemów informacyjnych SQA ułatwiających jednostce SQA przetwarzanie informacji dostarczanych przez jednostki rozwoju i utrzymania oprogramowania, w tym szacunki mierników jakości oprogramowania i kosztów jakości oprogramowania

  • Aktualizacja systemów informacyjnych SQA

  • Rozwój i utrzymanie serwisu internetowego / intranetowego SQA organizacji

Powiernicy SQA i ich zadania

Powiernicy SQA to ci członkowie, którzy są głównie zaangażowani w promowanie jakości oprogramowania. Członkowie ci zapewniają wewnętrzne wsparcie niezbędne do pomyślnego wdrożenia komponentów SQA.

Ich zadania mogą się różnić w zależności od organizacji. W związku z tym mogą to być zadania związane z jednostkami i / lub organizacjami.

Zadania związane z jednostką

  • Wspieraj kolegów w rozwiązywaniu trudności podczas wdrażania procedur jakości oprogramowania i instrukcji pracy

  • Pomagaj kierownikowi jednostki w wykonywaniu powiązanych zadań SQA

  • Promuj zgodność i monitoruj wdrażanie procedur SQA i instrukcji roboczych przez współpracowników

  • Zgłaszaj jednostce SQA istotne i systematyczne przypadki niezgodności

  • Zgłoś poważne błędy jakości oprogramowania jednostce SQA

Zadania związane z organizacją

  • Wyzwalaj zmiany i aktualizacje procedur SQA w całej organizacji i instrukcji pracy

  • Wyzwalaj usprawnienia procesów rozwoju i utrzymania w organizacji

  • Zainicjować wnioski do CAB dotyczące rozwiązań powtarzających się awarii zaobserwowanych w odpowiednich jednostkach

  • Zidentyfikuj potrzeby szkoleniowe SQA w całej organizacji i zaproponuj odpowiednie szkolenia lub programy instruktażowe, które zostaną przeprowadzone przez jednostkę SQA

Komitety SQA i ich zadania

Komitety SQA mogą być stałe lub ad hoc. Zadania mogą się znacznie różnić w zależności od organizacji.

  • Permanent committees zwykle zajmują się SCC (kontrola zmian oprogramowania), CA (działania naprawcze), procedurami, narzędziami do opracowywania metod i miernikami jakości.

  • Ad hoc committees zwykle zajmują się konkretnymi przypadkami interesu ogólnego, takimi jak aktualizacja określonej procedury, analiza i rozwiązanie awarii oprogramowania, opracowywanie metryk oprogramowania dla docelowego procesu lub produktu, aktualizacja kosztów jakości oprogramowania i metod gromadzenia danych dla konkretnego problemu.

Stałe komitety SQA są integralnymi częściami ram organizacyjnych SQA; ich zadania i działanie są zwykle określone w procedurach SQA organizacji.

Komitety ad hoc są tworzone krótkoterminowo dla każdego problemu, a członkowie są nominowani przez kierownika odpowiedzialnego za kwestie jakości oprogramowania, kierownika jednostki SQA, podjednostek SQA, stałych komitetów SQA lub innego organu, który zainicjował jego powstanie i jest zainteresowany pracą. Organ ten określa również zadania komitetu ad hoc.