"<h3>Definicja wg Williama Edwardsa Deminga</h3> \n",
" \n",
"Cała trudność w zdefiniowaniu jakości polega na przełożeniu przyszłych potrzeb użytkownika na wymierne cechy w taki sposób, aby produkt dawał klientowi satysfakcję za akceptowalną cenę.\n",
"<b> Jakość oprogramowania </b> to funkcja wypadkowa wartości określonych właściwości oprogramowania.\n",
"</div>"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## 2.1. Proces określania jakości oprogramowania\n",
"Proces określenia jakości oprogramowania składa się z dwóch etapów:\n",
"1. Zdefiniowanie funkcji jakości oprogramowania:\n",
"\n",
" > 1. Określ właściwości istotne dla danego typu oprogramowania (np. rozmiar, funkcjonalność, użyteczności, dostępność).\n",
" > 2. Dla każdej włąsciwości zdefiniuj zakres wartości liczbowych lub kategorii, określających, w jakim stopniu spełnia ona oczekiwania użytkowników.\n",
" > 3. Zdefiniuj jakość oprogramowania jako funkcję wartości poszczególnych właściwości: \n",
" > **Quality = q(wartości właściwości)**\n",
" \n",
"2. Ocena jakości oprogramowania\n",
" > 1. Wyznacz wartości poszczególnych cech oprogramowania.\n",
" > 2. Oblicz jakość oprogramowania za pomocą zdefiniowanej funkcji *Quality*."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# 3. Jakość kodu źródłowego\n",
"Cechy kodu żródłowego:\n",
" * rozmiar,\n",
" * złożoność"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## 3.1. Metryki rozmiaru kodu źródłowego\n",
"\n",
"### 3.1.1. Liczba wierszy (LOC - Lines of Code)\n",
"LOC mierzy **liczbę wierszy** w metodzie, klasie lub całej aplikacji.\n",
"\n",
"W obliczaniu LOC trzeba podjąć kilka nieoczywistych decyzji.\n",
"\n",
"Przykłady:\n",
"\n",
"<table>\n",
" <caption> Jak mierzyć liczbę wierszy w metryce LOC </caption> \n",
"<tr> \n",
" <td> Decyzja </td> <td> Rekomendacja </td>\n",
"</tr>\n",
"<tr>\n",
" <td> Czy liczyć puste wiersze?</td> <td> NIE </td>\n",
"</tr>\n",
"<tr>\n",
" <td> Czy liczyć komentarze?</td> <td> NIE </td>\n",
"</tr>\n",
"<tr>\n",
" <td> Czy liczyć liczbę wierszy czy liczbę instrukcji?</td> <td> Liczbę wierszy </td>\n",
"<figcaption> Metryki złożoności Halsteada. Źródło: wikipedia </figcaption> \n",
"</figure>"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### 3.2.2. Złożoność cyklomatyczna\n",
"**Złożoność cyklomatyczna** określa liczbę niezależnych ścieżek przebiegu programu. \n",
"\n",
"Jeśli program reprezentowany jest w postaci schematu blokowego (grafu), to:\n",
"\n",
"> CC = e - n + 2 * p \n",
"> e – liczba krawędzi grafu \n",
"> n – liczba węzłów grafu \n",
"> p – liczba składowych grafu \n",
"\n",
"Złożoność cykolmatyczną można łatwo wyliczyć na podstawie wzoru:\n",
"\n",
"> CC = d + 1, gdzie d oznacza liczbę węzłów decyzyjnych, np. instrukcji: \n",
"> * if \n",
"> * while \n",
"> * for \n",
"> * case"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### 3.2.3. Uśrednione metody na klasę (Weighted Methods per Class - WMC)\n",
"\n",
"Metryka uwzględnia zarówno liczbę metod w klasie, jak i ich złożoność cyklomatyczną: (n oznacza liczbę metod w klasie, a c<sub>i</sub> oznacza złożoność cykolomatyczną i-tej metody).\n",
"\n",
"<img src=\"obrazy/WMC.png\" alt=\"Uśrednione metody na klasę \" width=150px>"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### 3.2.4. Odpowiedzialność klasy (Response for a Class - RFC)\n",
"\n",
"Metryka RFC oznacza całkowitą liczbę metod, które mogą być potencjalnie wywołane w odpowiedzi na komunikat odebrany przez obiekt klasy. \n",
"\n",
"Wysoka wartość RFC oznacza większą funkcjonalność, ale zarazem i wyższą złożoność."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# 4. Właściwości produktu wpływające na ocenę jakości oprogramowania"
"## 6.2. Korelacja między właściwościami oprogramowania\n",
"Korelację między poszczególnymi właściwościami oprogramowania obrazuje tabela:\n",
"\n",
"<figure>\n",
"<img src=\"obrazy/korelacja właściwości.png\" alt=\"Korelacja między właściwościomi oprogramowania\" width=600px>\n",
" <figcaption> Korelacje między właściwościami oprogramowania źródło: opracowanie własne na podstawie: Stephen H. Kan \"Metryki i modele w inżynierii jakości oprogramowania\"</figcaption>\n",
"</figure>\n",
"\n",
"Tabela wskazuje, że polepszenie jednej cechy oprogramowania (np. przydatności funkcjonalnej) może pogorszyć inną cechę (np. wydajność), bo cechy te są ujemnie skorelowane."
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## 6.3. Waga właściwości oprogramowania\n",
"Istotność poszczególnych właściwości oprogramowania zależy od typu programu.\n",
"\n",
"Stephen H. Kan (\"Metryki i modele w inżynierii jakości oprogramowania\") podaje, że dla metryki UPRIMDA najbardziej odpowiednie kolejności właściwości są następujące: \n",
"* RUIPMDA\n",
"* RUAIMPD"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## 6.4. Wzór na ocenę jakości oprogramowania\n",
"\n",
"Procedura opracowania wzoru na ocenę jakości oprogramowania odpowiedniego dla danego typu programu:\n",
"\n",
"> 1. Wybierz schemat (np. FURPS) \n",
"> \n",
"> 2. Zdefiniuj typ funkcji (np. funkcja liniowa) \n",
