====== Metryki oprogramowania ======

Od początku swego istnienia inżynieria oprogramowania szukała sposobów na jasny i obiektywny sposób pomiaru jakości oprogramowania. W związku z tym wprowadzono kilka pojęć pomocniczych:
  * **Pomiar** - proces, w którym atrybutom elementów świata rzeczywistego przydzielane są liczby lub symbole w taki sposób, aby scharakteryzować te atrybuty  według jasno określonych zasad. Jednostki przydzielone atrybutom nazywamy ich miarą.
Teoria procesów pomiarowych daje podstawę do ustalenia, czy proponowana miara rzeczywiście charakteryzuje interesujący nas atrybut, oraz dostarcza podstaw do rozróżnienia typów skal pomiarowych.

Dalsze rozróżnienie dotyczy **miary**(wg powyższej definicji) i **metryki**: metryka to proponowana (postulowana) miara - tylko wtedy gdy rzeczywiście charakteryzuje ona dany atrybut, można ją uznać za miarę rozpatrywanego atrybutu.
Przykład: 
  * LOC (Line of Code) - jest jednostką miary długości programu w wersji źródłowej - ale nie złożoności ani nawet rozmiaru.

**Dla lepszego zrozumienia sensu pomiaru w kontekście oprogramowania, charakteryzujemy elementy i ich atrybuty, które chcemy scharakteryzować w sensie liczbowym:**
  * **Proces** - każde określone działanie, zbiór działań lub okres czasu w ramach projektu wytwarzania lub eksploatacji oprogramowania (np. projektowanie wymagań, projektowanie, kodowanie i weryfikację, określony okres czasu, np. pierwsze trzy miesiące) 
  * **Produkt** - każdy przedmiot powstały w wyniku procesu (kod źródłowy, specyfikacja, modyfikacja, plan testów, podręcznik użytkownika, pakiet instalacyjny) 
  * **Zasób** -  każdy element niezbędny do realizacji procesu(osoby, zespoły, oprogramowanie, infrastruktura, biura)

**Rozróżniamy również atrybuty wewnętrzne i zewnnętrzne powyższych obiektów:**
  * **Wewnętrzne** - odnosza sie wyłącznie do tworzonego obiektu: np. ilosc linii kodu
  * **Zewnętrzne** - odnosza sie do reakcji obiekt - otoczenie: np. jakosc, niezawodnosc

**Wśród znanych metryk wyróżniamy:**




===== Metryka gęstości defektów =====

Jest najczęściej stosowanym sposobem pomiaru jakości **fragmentu kodu**, (w przykładzie oznaczonym jako C):

**M = (ilość defektów odkrytych w C) / (rozmiar C)**

gdzie C jest zwykle określany w KLOC (tysiącach linii kodu)


====Występujące problemy:====

 
  * nie jest jasne, czy wyraża jakość programu, czy raczej rzetelność testowania programu
  * brak zgody co do definicji defektu (usterka/awaria)
  * brak zgody co do sposobu pomiaru rozmiaru kodu (czy wliczane powinny być również deklaracje, komentarze itp.)

Mimo powyższych problemów, gęstosć defektów stała się de facto standardową miarą jakości oprogramowania w przemyśle informatycznym. 






===== Metryki wielkości (długości kodu źródłowego) =====

Metryki wielkości są stosowane jako czynnik normalizujący w większości miar jakości oprogramowania i wydajności programistów, są także kluczowym parametrem dla modeli nakładu pracy związanej z wytworzeniem oprogramowania.

    * **LOC** – LinesOfCode,
    * **KLOC** - KiloLinesOfCode,
    * **Liczba instrukcji**,
    * **Liczba instrukcji wykonywalnych**,
    * **DSI** - Delivered Source Instructions - liczba instrukcji źródłowych w dostarczonym produkcie,
    * **MOD** - liczba modułów kodu

==== Występujące problemy: ====

    * charakteryzują tylko jednen aspekt wielkości - długość, nie mówią nic o złożoności i funkcjonalności
    * problemy z wcześniejszym prognozowaniem - dają się definiować tylko w odniesieniu do istniejącego już kodu




====== Kluczowe metryki oprogramowania ======
Do kluczowych metryk oprogramowania możemy zaliczyć **metryki złożoności**, **modele szacowania nakładów**, oraz **metryki funkcjonalności**.


===== Metryki złożoności =====
Dotychczas zaproponowano setki metryk złożoności, większość z nich jest ograniczona do kodu programu. Najszerzej znane to tzw. **nauka o programach Halsteada** (Halsteads's software science) i **liczba cyklomatyczna McCabea** (McCabe's cyclomatic number)




===== Nauka o programach Halsteada - pomiary złożoności =====
(__Złozoność programu__ - stopień trudnosci zrozumienia działania programu, określany wyłącznie na podstawie jego kodu źródłowego)

Halstead zdefiniował szereg metryk opartych o elementy składniowe programu (operatory i operandy), niektóre z nich pokazano poniżej:

W programie P wyróżniane są **operatory** i **operandy**:
  * **n1** – liczba różnych operatorów
  * **n2** – liczba różnych operandów
  * **N1** – całkowita liczba wystąpień operatorów w P
  * **N2** – całkowita liczba wystąpień operandów w P

//Słownik// P zawiera n = n1 + n2 elementów.

//Wielkość// P wynosi N = N1 + N2.

**Twierdzenie:** Szacunkowa wartość N wynosi: n1·log(n1) + n2·log(n2)

**Twierdzenie:** //Wysiłek// potrzebny do wytworzenia P wynosi:
E = [n1·N2·N·log(n)] / 2·n2 //[elementarnych jednostek]//

**Twierdzenie:** //Czas// potrzebny do wytworzenia P wynosi:
T ≈ E / 18 [s]



===== Liczba cyklometryczna McCabea (miara złożoności programu)=====

Liczba McCabea odnosi się do schematu blokowego, i **jest równa liczbie niezależnych dróg w tym schemacie**.

Jeśli przyjmniemy za M liczbę niezależnych dróg w schemacie blokowym, to metryka McCabea bedzie wynosic:

**M** = liczba decyzji w programie + 1.

==== Występujące problemy: ====
 
Niektórzy twierdzą, że powyższe dwie metryki nie są lepsze niż LOC ponieważ:
  * nie pozwalają lepiej przewidzieć nakładu pracy,niezawodności, pielęgnowalności
  * mierzalne na etapie implementacji
  * wciąż zbyt uproszczone (nie uwzględniają złożoności przepływów danych, zagnieżdżenia itd..)

Wszystkie opisane wyżej metryki są definiowane w odniesieniu do indywidualnych programów.
Zaproponowano także liczne metryki złożoności systemu na bazie jego elementów składowych, np. **modułów**, **procedur** czy **funkcji
**. Najbardziej znane są metryki **Henry'ego i Kafury**, oparte na liczeniu **przepływów informacji między modułami**. Ich podstawową zaletą jest możliwość ich uzyskania **przed kodowaniem**, na etapie projektowania.


===== Modele szacowania nakładów - Model COCOMO (Constructive Cost Model) =====

Tak jak większość modeli szacowania nakładów, COCOMO przyjmuje ogólną postać: **nakład pracy = f(fozmiar)**

Pozwala on na okreslenie nakładu pracy, czasu wykonania projektu i optymalnej wielkości zespołu. 
Operuje na liniach kodu (KDSI) oraz trzech kategoriach klasyfikacji projektu : organiczny, półoderwany, osadzony.

**Przedsięwzięcia organiczne (organic projects):**
  * Odnosi się do autonomicznych systemów przetwarzania danych.
  * Przedsięwzięcie wykonywane przez małe zespoły, złożone z osób o podobnym, wysokim poziomie umiejętności technicznych.
  * Dziedzina problemu jest dość dobrze znana.
  * Przedsięwzięcie jest wykonywane za pomocą dobrze znanych metod i narzędzi.

**Przedsięwzięcia półoderwane (semi-detached projects):**
  * Odnosi się do systemów sytuujących się między systemami organicznymi a osadzonymi
  * Członkowie zespołu różnią się stopniem zaawansowania.
  * Pewne aspekty problemu, część metod i narzędzi nie jest dobrze znana.

**Przedsięwzięcia osadzone (embedded projects):**
  * Odnosi się do systemów czasu rzeczywistego lub systemów podlegających dodatkowym ograniczeniom, znacznie komplikującym ich rozwój.
  * Realizacja systemów o bardzo złożonych wymaganiach
  * Dziedzina problemu, stosowane metody i narzedzia w dużej mierze nieznane
  * Większość członków zespołu nie ma doświadczenia w realizacji podobnych zadań

----

**Podstawowe wyrażenie w modelu COCOMO pozwalające wyliczyć nakład pracy to:**

//**Nakład[osobomiesiące]=A·(KDSI)^b**//

  * **KDSI** nie obejmuje fragmentów kodu, które nie zostały ostatecznie wykorzystane w systemie, mimo iz ich opracowanie mogło wymagać dużych nakładów.
  * Wartości stałych **A** i **b** zależą od klasy, do której zaliczono przedsięwzięcie:
    * **Organiczne:** Nakład=2,4·(KDSI)^1,05
    * **Półoderwane:** Nakład=3·(KDSI)^1,12
    * **Osadzone:** Nakład=3,6·(KDSI)^1,20

Znając nakład pracy jesteśmy w stanie oszacować czas realizacji przedsięwzięcia, z czego wynika przybliżona wielkość zespołu, który przedsięwzięcie powinien realizować:
    * **Organiczne:** Czas[miesiące]=2,5·(KDSI)^0,32
    * **Półoderwane:** Czas[miesiące]=2,5·(KDSI)^0,35
    * **Osadzone:** Czas[miesiące]=2,5·(KDSI)^0,38

Powyżej został przedstawiony podstawowy model COCOMO. Otrzymane w ten sposób oszacowania powinny zostać skorygowane poprzez przemnożenie przez  tzw. czynniki korygującye, nieznacznie mniejsze(zmniejszenie nakładów) lub większy(zwiększenie nakładów) od jedności, dla każdego z atrybutów. 

**Czynniki modyfikujące tworzy się biorąc pod uwagę następujące atrybuty przedsięwzięcia:**
  * wymagania wobec niezawodności systemu
  * rozmiar bazy danych w stosunku do rozmiaru kodu
  * złozoność systemu (struktur danych, algorytmów komunikacja z innymi systemami, stosowanie obliczeń równoległych)
  * wymagania co do wydajności
  * ograniczenia pamięci
  * zmienność maszyny wirtualnej (zmienność sprzętu i oprogramowania systemowego)

==== Występujące problemy: ====

  * wymagana znajomość rozmiaru kodu (jeden problem prognostyczny zastępujemy innym)


===== Metryki funkcjonalności -  Metoda punktów funkcyjnych Albrechta =====

Odzwierciedla punkt widzenia użytkownika na zagadnienie funkcjonalności systemu.
Główną jej zaletą w porównaniu z poprzednio opisywanymi metrykami długości i złożoności jest to, iż nie jest ona ograniczona do kodu.
Jest to metoda precyzyjna, prognoza uzyskiwana jest na podstawie szczegółowej specyfikacji systemu, zatem nie trzeba prognozować rozmiaru) .

**FP = UFC · TCF**

  * **UFC** – pierwotna liczba punktów funkcyjnych, uzyskiwana przez sumowanie ważone ilości wejść, wyjść, logicznych plików głównych (pamięć danych), plików interfejsowych i usług widocznych dla klienta systemu. Wagi stosowane do powyższych elementów zależą od typu elementu(prosty,przeciętny, złożony). Elementy są oceniane pod względem złożoności w zależności od liczby pozycji danych oraz typów pliku.
  * **TCF** – współczynnik złożoności technicznej leżący między 0,65 a 1,35, ustalany poprzez dodatkowe uwzględnienie wpływu 14 czynników i jest określone w odniesieniu do rozpatrywanego systemu.


==== Występujące problemy: ====
 
  * metoda jest skomplikowana.
