Wskaźniki jakości oprogramowania

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ęciopunktowej skali można skonstruować i wykorzystać kilka metryk z niewielkimi odchyleniami, 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ą systemu) jest skorelowany ze współczynnikiem defektów w terenie. Wyższe współczynniki 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 podczas testowania 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 zapewni 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.

• Wzorzec prawidłowych zgłoszonych defektów, gdy określono problem dla zgłoszonych problemów. To jest prawdziwy wzór wady.

• Wzorzec 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 oświadczenie dotyczące obciążenia pracą, a także oświadczenie dotyczące 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 początku zmniejsza liczbę błędów w oprogramowaniu. Schemat usuwania defektów w oparciu o fazy odzwierciedla ogólną zdolność usuwania defektów w procesie rozwoju.

Jeśli chodzi o metryki fazy projektowania i kodowania, oprócz wskaźników defektów, wiele organizacji programistycznych korzysta z mierników, takich jak zasięg inspekcji i wysiłek inspekcyjny do zarządzania jakością w trakcie procesu.

Skuteczność usuwania wad

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

$$ DRE = \ frac {Wada \: usunięta \: podczas \: a \: rozwoju \: faza} {Wady \: latent \: w \: \: produkcie} \ times 100 \% $$

Metrykę tę można obliczyć dla całego procesu rozwoju, 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 tym 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 wskaźnikiem 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 {liczba \: z \: problemów \: zamknięte \: w trakcie \: \: miesiąca} {liczba \: \: problemów \: dotarły \: w \: \: \ :miesiącu} \ 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 {liczba \: z \: poprawek \: które \: przekroczono \: \: odpowiedź \: czas \: kryteria \: przez \: stopień ważności \: poziom} {liczba \: \: poprawki \: dostarczone \: w \: a \: określone \: czas} \ razy 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: Zapisz ją w miesiącu, w którym została wykryta, lub zapisz 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ń.