diff --git a/materiały na PBR (laboratorium)/.ipynb_checkpoints/11_ocena_jakości_systemu_lab-checkpoint.ipynb b/materiały na PBR (laboratorium)/.ipynb_checkpoints/11_ocena_jakości_systemu_lab-checkpoint.ipynb
new file mode 100644
index 0000000..e0d8b79
--- /dev/null
+++ b/materiały na PBR (laboratorium)/.ipynb_checkpoints/11_ocena_jakości_systemu_lab-checkpoint.ipynb
@@ -0,0 +1,84 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n",
+ "
\n",
+ "
Projekt badawczo-rozwojowy
\n",
+ "
11. Ocena jakości systemu informatycznego[laboratorium]
\n",
+ "
Krzysztof Jassem (2021)
\n",
+ "
\n",
+ "\n",
+ "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Cel laboratorium nr 11\n",
+ "Celem laboratorium jest określenie funkcji, która wylicza ogólną jakość projektowanego systemu na podstawie oceny jego poszczególnych cech."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Plan laboratorium\n",
+ "\n",
+ "## Zadanie 1. Metryki kodu\n",
+ "Zbadajcie LOC Waszego systemu i na tej podstawie obliczcie wykonane już punkty funkcyjne. \n",
+ "Obliczcie metryki Haelsteada dla wybranej funkcji w Waszym kodzie i porównajcie z własnym doświadczeniem. \n",
+ "Dla wybranej klasy zróbcie analizę metryk WMC i RFC. \n",
+ "\n",
+ "Ocena maksymalna: 10 punktów \n",
+ "\n",
+ "## Zadanie 2. Jakość podobnego systemu\n",
+ "Wyszukajcie istniejącą, dostępną aplikację, możliwie najbardziej zbliżoną do Waszej pod względem funkcjonalności i użyteczności. \n",
+ "Oceńcie punktowo (np. w skali od 1 do 10) jakość systemu - każdy członek grupy osobno:\n",
+ " * każdą z cech systemu podanych w schemacie FURPS, CUPRIMDA lub CUPRIMDSO (schemat do wyboru).\n",
+ " * ogólną satysfakcję z systemu (w przypadku CUPRIMDSO ogólna satysfakcja zawarta jest w cesze oznaczonej przez O, więc nie ma sensu jej powtarzać). \n",
+ " \n",
+ "Wyniki oceny zaprezentujcie w tabeli (Excel).\n",
+ "Zaproponujcie wzór dla zdefiniowania ogólnej satysfakcji z systemu jako funkcji ocen cząstkowych, tak aby korelacja wyników ze wzoru i ocen użytkowników była bliska 1. \n",
+ "\n",
+ "Ocena maksymalna: 10 punktów\n",
+ "\n",
+ "## Zadanie 3. Jakość Waszego systemu.\n",
+ "Poddajcie Wasz system (ostatnia działająca wersja) pod ocenę pięciu osobom spoza Waszej grupy dokładnie według tych samych zasad, jak w zadaniu 2. \n",
+ "Sprawdżcie korelację wyników operatora agregacji z ocenami ogólnymi systemu (czy oceny wyliczane za pomocą agregacji \"zgadzają się\" z ocenami ludzkimi). \n",
+ "\n",
+ "Ocena maksymalna: 10 punktów"
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3",
+ "language": "python",
+ "name": "python3"
+ },
+ "lang": "pl",
+ "language_info": {
+ "codemirror_mode": {
+ "name": "ipython",
+ "version": 3
+ },
+ "file_extension": ".py",
+ "mimetype": "text/x-python",
+ "name": "python",
+ "nbconvert_exporter": "python",
+ "pygments_lexer": "ipython3",
+ "version": "3.8.5"
+ },
+ "subtitle": "12. Ocena jakości systemu informatycznego[laboratorium]",
+ "title": "Projekt badawczo-rozwojowy",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na PBR (laboratorium)/11_ocena_jakości_systemu_lab.ipynb b/materiały na PBR (laboratorium)/11_ocena_jakości_systemu_lab.ipynb
index 4314bc4..e0d8b79 100644
--- a/materiały na PBR (laboratorium)/11_ocena_jakości_systemu_lab.ipynb
+++ b/materiały na PBR (laboratorium)/11_ocena_jakości_systemu_lab.ipynb
@@ -7,7 +7,7 @@
"![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n",
"
\n",
"
Projekt badawczo-rozwojowy
\n",
- "
12. Ocena jakości systemu informatycznego[laboratorium]
\n",
+ "
11. Ocena jakości systemu informatycznego[laboratorium]
\n",
"
Krzysztof Jassem (2021)
\n",
"
\n",
"\n",
@@ -18,7 +18,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "# Cel laboratorium nr 12\n",
+ "# Cel laboratorium nr 11\n",
"Celem laboratorium jest określenie funkcji, która wylicza ogólną jakość projektowanego systemu na podstawie oceny jego poszczególnych cech."
]
},
diff --git a/materiały na PPB (wykład)/.ipynb_checkpoints/11_ocena_jakości_systemu-checkpoint.ipynb b/materiały na PPB (wykład)/.ipynb_checkpoints/11_ocena_jakości_systemu-checkpoint.ipynb
new file mode 100644
index 0000000..73af4d5
--- /dev/null
+++ b/materiały na PPB (wykład)/.ipynb_checkpoints/11_ocena_jakości_systemu-checkpoint.ipynb
@@ -0,0 +1,626 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n",
+ "
\n",
+ " \n",
+ "1. Jakość składa się z tych cech produktu, które spełniają potrzeby klientów i dostarczają im satysfakcji. \n",
+ "2. Jakość to brak braków.\n",
+ "
\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",
+ "
\n",
+ " \n",
+ " Jakość oprogramowania to funkcja wypadkowa wartości określonych właściwości oprogramowania.\n",
+ "
"
+ ]
+ },
+ {
+ "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",
+ "
\n",
+ " \n",
+ "Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "> **Methods** should not have more than an average of 30 code lines (not counting line spaces and comments). \n",
+ "> **A class** should contain an average of less than 30 methods, resulting in up to 900 lines of code. \n",
+ "> **A package** shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines. \n",
+ "> **Subsystems** with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code. \n",
+ "> **A system** with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines. \n",
+ "[Przeczytaj w Internecie](https://dzone.com/articles/rule-30-%E2%80%93-when-method-class-or)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 3.1.2. Punkty funkcyjne\n",
+ "\n",
+ "**Punkty Funkcyjne** - metryka, która wyznacza liczbę funkcjonalności dostarczaną przez system.\n",
+ "\n",
+ "**Współczynnik produktywności języka programowania**: ile (średnio) linii kodu potrzeba do zakodowania jednego punktu funkcyjnego? \n",
+ "\n",
+ "Wartość kodu w punktach funkcyjnych wyznacza się, dzieląc wartośćLOC przez współczynnik produktywności.\n",
+ "\n",
+ "**Tablica produktywności języków programowania**\n",
+ "\n",
+ "\n",
+ " Tablica produktywności. Źródło: Adam Roman, \"Testowanie i jakość oprogramowania\" \n",
+ "\n",
+ "\n",
+ "[Porównaj w Internecie](https://www.qsm.com/resources/function-point-languages-table)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 3.1.3. Liczba tokenów - metryka Halsteada\n",
+ "\n",
+ "Metryka Halsteada wyznacza objętość (wielkość) kodu na podstawie liczby unikatowych tokenów.\n",
+ "Wyróżniane są dwa typy tokenów:\n",
+ " * operatory (funkcje, słowa kluczowe itp.),\n",
+ " * operandy (zmienne, stałe, wartości).\n",
+ " \n",
+ "Wartości metryk Halsteada (w przeciwieństwie do LOC) nie zależą od długości przyjętego nazewnictwa.\n",
+ "\n",
+ "\n",
+ "\n",
+ " Liczby tokenów. Źródło: wikipedia \n",
+ "\n",
+ "\n",
+ "Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n",
+ "\n",
+ "\n",
+ "\n",
+ " Objętość programu. Źródło: wikipedia \n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 3.2. Metryki oceny złożoności kodu źródłowego "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### 3.2.1. Metryki złożoności Halsteada\n",
+ "Złożoność programu szacowana jest pod kilkoma aspektami - na podstawie liczby tokenów:\n",
+ " * D: trudność implementacji,\n",
+ " * L: poziom programu (im wyższy tym program jest mniej podatny na błędy),\n",
+ " * E: wysiłek implementacji,\n",
+ " * T: czas implementacji\n",
+ " * B: liczba błędów.\n",
+ "\n",
+ "\n",
+ " Metryki złożoności Halsteada. Źródło: wikipedia \n",
+ ""
+ ]
+ },
+ {
+ "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 ci oznacza złożoność cykolomatyczną i-tej metody).\n",
+ "\n",
+ ""
+ ]
+ },
+ {
+ "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"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.1. Przydatność funkcjonalna (Functional Suitability - F)\n",
+ "**Przydatność funkcjonalna** określa stopień, w jakim program dostarcza oczekiwane funkcjonalności.\n",
+ "\n",
+ "Wartość przydatności funkcjonalnej można wyznaczyć podczas testowania:\n",
+ "\n",
+ "> **M = 1 - A/B**\n",
+ "> * A = funkcjonalności problemowe \n",
+ "> * B = wszystkie testowane funkcjonalności"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.2. Niezawodność\n",
+ "\n",
+ "**Niezawodność** określa prawdopodobieństwo, że wykonanie operacji przez program będzie bezbłędne.\n",
+ "\n",
+ "Wartość niezawodności można wyznaczyć podczas testowania:\n",
+ "\n",
+ "> **M = A/B** \n",
+ "> * A = liczba testów ukończonych pomyślnie, \n",
+ "> * B = liczba wszystkich testów"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.3. Użyteczność (Usability - U)\n",
+ "\n",
+ "**Użyteczność** określa łatwość użytkowania.\n",
+ "\n",
+ "Wartość użyteczności można wyznaczyć podczas testów użyteczności:\n",
+ "\n",
+ "> **M = A/B**\n",
+ "> * A = liczba funkcjonalności odkryta przez użytkownika, \n",
+ "> * B = liczba wszystkich funkcjonalości."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.4. Wydajność (Performance Efficiency)\n",
+ "**Wydajność** określa liczbę wykonanych operacji w odniesieniu do czasu i zużytych zasobów.\n",
+ "\n",
+ "Przykładowe metryki pomiaru wydajności:\n",
+ "\n",
+ "> * Czas odpowiedzi: **M = T1 (end) - T2 (start)** \n",
+ "> * Czas postoju: **M = T1 (waiting time) / T2 (total time)**\n",
+ "> * Przepustowość = Liczba zadań wykonanych w jednostce czasu \n",
+ "> * Zużycie pamięci (w bajtach) "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.5. Łatwość konserwacji (Maintainability - M)\n",
+ "**Łatwość konserwacji** to łatwość, z jaką program jest utrzymywany w celu:\n",
+ " * poprawiania błędów,\n",
+ " * wprowadzania nowych funkcji.\n",
+ "\n",
+ "Przykładowa metryka: Ile czasu zajmuje średnio naprawienie błędu?\n",
+ "\n",
+ "> **M = SUM(czas naprawy) / N** \n",
+ "> * N oznacza liczbę napraw"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.6. Przenośność (Portability - P)\n",
+ "**Przenośność** to Łatwość przenoszenia systemu pomiędzy różnymi środowiskami platformami / systemami operacyjnymi. \n",
+ "\n",
+ "Przykładowe metryki:\n",
+ " * łatwość adaptacji\n",
+ " > **M = T** \n",
+ " > * T oznacza czas adaptacji do nowego środowiska\n",
+ "\n",
+ " * łatwość instalacji: \n",
+ " > **M = A / B**\n",
+ " > * A = przypadki pomyślnej instalacji \n",
+ " > * B = wszystkie przypadki instalacji "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.7. Dostępność (Availibility - A)\n",
+ "**Dostępność** to czas, w którym program zobowiązany jest odpowiadać zgodnie z oczekiwaniami.\n",
+ "\n",
+ "* Metryka:\n",
+ "\n",
+ "> **M = A / B**\n",
+ "> * A = Czas dostępności \n",
+ "> * B = Czas całkowity \n",
+ "\n",
+ "* Przykładowe wartości metryki dostępności:\n",
+ "\n",
+ "
\n",
+ "
Wartości metryki dostępności
\n",
+ "
\n",
+ "
Miara dostępności
Czas niedostępności w roku
\n",
+ "
\n",
+ "
\n",
+ "
99,999
5 minut 20 sekund
\n",
+ "
\n",
+ "
\n",
+ "
99,8
17 godzin 30 minut
\n",
+ "
\n",
+ "
\n",
+ "
97,5
219 godzin
\n",
+ "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.8. Kompatybilność (Compatibility)\n",
+ "**Kompatybilność** to możliwość współpracowania z systemami zewnętrznymi."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 4.9. Bezpieczeństwo (Security - S)\n",
+ "**Bezpieczeństwo** to możliwość chronienia danych przetwarzanych przez aplikację.\n",
+ "\n",
+ "* Przykładowa metryka:\n",
+ "\n",
+ "> **M = A / B** \n",
+ "> * A = Liczba przetestowanych funkcji programu uznanych jako bezpieczne\n",
+ "> * B = Liczba wszystkich przetestowanych funkcji "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# 5. Schematy oceny jakości\n",
+ "\n",
+ "Aby ocenić jakość oprogramowania należy wybrać właściwości oprogramowania, które wchodzą w skład oceny. Służą do tego **schematy oceny jakości**.\n",
+ "\n",
+ "## 5.1. CUMPRIMDSO (schamat wprowadzony przez IBM)\n",
+ "* Capability (odpowiednik przydatności funkcjonalnej)\n",
+ "* Usability (użyteczność)\n",
+ "* Performance – wydajność\n",
+ "* Reliability – niezawodność\n",
+ "* Installability – łatwość instalacji\n",
+ "* Maintainibility – łatwość utrzymania (pielęgnowalność)\n",
+ "* Documentation – dokumentacja\n",
+ "* Service – serwis\n",
+ "* Overall - ocena ogólna\n",
+ "\n",
+ "## 5.2. CUMPRIMDA\n",
+ "* Capability (odpowiednik przydatności funkcjonalnej)\n",
+ "* Usability (użyteczność)\n",
+ "* Performance – wydajność\n",
+ "* Reliability – niezawodność\n",
+ "* Installability – łatwość instalacji\n",
+ "* Maintainibility – łatwość utrzymania (pielęgnowalność)\n",
+ "* Documentation – dokumentacja\n",
+ "* Availibility - dostępność\n",
+ "\n",
+ "## 5.3. FURPS (schemat wprowadzony przez Hewlett-Packard)\n",
+ "* Functionality\n",
+ "* Usability\n",
+ "* Reliability\n",
+ "* Performance\n",
+ "* Supportability – łatwość wspierania"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# 6. Funkcja oceny jakości oprogramowania"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 6.1. Pojęcie korelacji\n",
+ "\n",
+ "**Korelacja** to miara zależności pomiędzy dwoma zmiennymi (cechami).\n",
+ "\n",
+ "Korelacja przyjmuje wartości z przedziału [-1, 1]. \n",
+ "* korealacja > 0 → korelacja dodatnia\n",
+ " * gdy wartości jednej cechy rosną, to drugiej również rosną.\n",
+ "* r < 0 → korelacja ujemna\n",
+ " * gdy wartości jednej cechy rosną, to drugiej maleją i odwrotnie\n",
+ "* r = 0 → korelacja zerowa\n",
+ " * brak związku między cechami.\n",
+ " \n",
+ "Przykłady korelacji: \n",
+ "\n",
+ "\n",
+ " źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 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",
+ "\n",
+ "\n",
+ " 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\"\n",
+ "\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",
+ "> **Quality = a + b*F + c*U +d*R + e*P + f*S** \n",
+ "> \n",
+ "> 3. Zdefiniuj współczynniki tak, by korelacja z oceną ludzką była jak najwyższa."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Przykładowy proces dostrajania współczynników jakości\n",
+ "\n",
+ "> 1. Zorganizuj grupę użytkowników (co najmniej 5 osób). \n",
+ "> 2. Zbierz od użytkowników oceny poszczególnych właściwości oprogramowania. \n",
+ "> 3. Zbierz od użytkowników oceny ogólne jakości. \n",
+ "> 4. Określ heurystycznie wartości współczynników we wzorze na ocenę ogolną. \n",
+ "> 5. Oblicz współczynnik korelacji między:\n",
+ "> * ocenami ogólnymi jakości podanymi przez użytkowników, \n",
+ "> * ocenami ogólnymi jakości wyznaczonymi przez wzór na oceną ogólną na podstawie ocen cząstkowych użytkownikow.\n",
+ "> 6. Jeśli korelacja jest niska, to powróć do punktu 4."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Podsumowanie\n",
+ " * Istnieje wiele definicji jakości programowania.\n",
+ " * Na wykładzie zdefiniowano jakość jako funkcję poszczególnych właściwości oprogramowania.\n",
+ "\n",
+ "* Istnieją metryki oceny **kodu źrodłowego**. \n",
+ " * Na ich podstawie można ocenić jakość kodu.\n",
+ " \n",
+ " * Jakość oprogramowania można oceniać również z punktu widzenia klienta. \n",
+ " * Stosowane są różne schematy oceny, które biorą pod uwagę różne właściwości oprogramowania.\n",
+ " \n",
+ " * Ocenę ogólną oprogramowania (z punktu widzenia klienta) można zdefiniować jako **funkcję liniową** ocen poszczególnych właściwości."
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3",
+ "language": "python",
+ "name": "python3"
+ },
+ "lang": "pl",
+ "language_info": {
+ "codemirror_mode": {
+ "name": "ipython",
+ "version": 3
+ },
+ "file_extension": ".py",
+ "mimetype": "text/x-python",
+ "name": "python",
+ "nbconvert_exporter": "python",
+ "pygments_lexer": "ipython3",
+ "version": "3.8.5"
+ },
+ "subtitle": "12. Ocena jakości systemu informatycznego[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na PPB (wykład)/11_ocena_jakości_systemu.ipynb b/materiały na PPB (wykład)/11_ocena_jakości_systemu.ipynb
index b959570..73af4d5 100644
--- a/materiały na PPB (wykład)/11_ocena_jakości_systemu.ipynb
+++ b/materiały na PPB (wykład)/11_ocena_jakości_systemu.ipynb
@@ -7,7 +7,7 @@
"![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n",
"