forked from AITech/aitech-ppb-pbr
merge
This commit is contained in:
commit
4ab5147740
@ -11,68 +11,78 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Przygotowanie do projektu badawczo-rozwojowego (PPB)\n",
|
||||
"# 1. Założenia ogólne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Przygotowanie do projektu badawczo-rozwojowego (PPB)\n",
|
||||
"Przygotowanie do projektu badawczo-rozwojowego to przedmiot prowadzony w formie wykładów dla studentów II roku studiów magisterskich na kierunku Informatyka. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia projektu badawczo-rozwojowego. "
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia projektu badawczo-rozwojowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Systemy informatyczne (SYI)\n",
|
||||
"Systemy informatyczne to przedmiot prowadzony w formie wykładów i laboratoriów dla studentów III semestru studiów magisterskich na kierunku Analiza i Przetwarzanie Danych. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia systemu informatycznego - na przykładzie projektu badawczo-rozwojowego rozwijanego przez studentów studiów magisterskich na kierunku Informatyka. \n",
|
||||
"W ramach laboratorium do przedmiotu SYI studenci uczestniczą w tworzeniu projektów badawczo-rozwojowych razem ze studentami Informatyki."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Projekt badawczo-rozwojowy (PBR)\n",
|
||||
"## Laboratorium przedmiotu SYI\n",
|
||||
"Projekt badawczo-rozwojowy to przedmiot prowadzony w formie laboratoriów dla studentów II semestru studiów magisterskich na kierunku Informatyka.\n",
|
||||
"## 1.2. Projekt badawczo-rozwojowy (PBR)\n",
|
||||
"Projekt badawczo-rozwojowy to przedmiot prowadzony w formie laboratoriów dla studentów II roku studiów magisterskich na kierunku informatyka.\n",
|
||||
"\n",
|
||||
"Wskazane jest, aby projekt badawczo-rozwojowy przyczyniał się do rozwoju prac magisterskich członków zespołu.\n",
|
||||
"\n",
|
||||
"Studenci Informatyki współpracują ze studentami Analizy i Przetwarzania Danych, tworząc razem zespoły o liczności od trzech do pięciu studentów. Aby umożliwić taką współpracę, laboratoria z przedmiotów SYI i PBR prowadzone są w ten sam dzień tygodnia i o tej samej godzinie. Studenci obu kierunków współpracują w tworzeniu wspólnego projektu badawczo-rozwojowego. \n",
|
||||
"* Student informatyki powinien nabyć następujące umiejętności:\n",
|
||||
" * tworzenie koncepcji projektu badawczo-rozwojowego,\n",
|
||||
" * implementacja systemu informatycznego w metodyce zwinnej,\n",
|
||||
" * stosowanie praktyki ciągłej integracji w rozwoju systemu informatycznego,\n",
|
||||
" * wdrożenie systemu będącego wynikiem projektu badawczo-rozwojowego w praktyce gospodarczej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Systemy informatyczne (SYI)\n",
|
||||
"Systemy informatyczne to przedmiot prowadzony w formie wykładów i laboratoriów dla studentów III semestru studiów magisterskich na kierunku Analiza i Przetwarzanie Danych. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia systemu informatycznego - na przykładzie projektu badawczo-rozwojowego rozwijanego przez studentów studiów magisterskich na kierunku Informatyka. \n",
|
||||
"W ramach laboratorium do przedmiotu SYI studenci uczestniczą w tworzeniu projektów badawczo-rozwojowych razem ze studentami Informatyki.\n",
|
||||
"\n",
|
||||
" * Student analizy i przetwarzania danych powinien nabyć następujące umiejętności:\n",
|
||||
"\n",
|
||||
" * dostarczanie i analiza danych do systemu informatycznego,\n",
|
||||
" * tworzenie dokumentacji projektowej,\n",
|
||||
" * przygotowanie i prowadzenie testów funkcjonalnych,\n",
|
||||
" * opracowanie raportów użyteczności,\n",
|
||||
" * tworzenie skryptów wspomagających implementację i testowanie."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Współpraca studentów na przedmiotach SYI oraz PBR\n",
|
||||
"\n",
|
||||
"Studenci przedmiotów SYI oraz PBR współpracują ze sobą, tworząc razem zespoły o liczności od trzech do pięciu studentów. W skład zespołów wchodzą studenci obu przedmiotów. \n",
|
||||
"\n",
|
||||
"Aby umożliwić taką współpracę, laboratoria z przedmiotów SYI i PBR prowadzone są w ten sam dzień tygodnia i o tej samej godzinie. Studenci obu kierunków współpracują w tworzeniu wspólnego projektu badawczo-rozwojowego. \n",
|
||||
"\n",
|
||||
"Zespół projektowy powinien zatem składać się ze studentów obu kierunków (idealnie: dwóch studentów informatyki i dwóch studentów analizy danych). Skład zespołów może się kształtować podczas pierwszych trzech laboratoriów. Począwszy od laboratorium nr 4 studenci pracują w stałych zespołach.\n",
|
||||
"\n",
|
||||
"Osobą oceniającą pracę całego zespołu projektowego jest opiekun projektu badawczo-rozwojowego. \n",
|
||||
"Każdy zespół ma opiekuna - osobę z kadry WMI UAM.\n",
|
||||
"\n",
|
||||
"Opiekunowie otrzymują od wykładowcy przedmiotu PPB proponowane scenariusze wszystkich laboratoriów przedmiotu PBR wraz z wytycznymi dotyczącymi oceniania pracy studentów. Opiekun projektu ma jednak prawo odstąpić od proponowanych scenariuszy - częściowo lub w całości, dostosowując przebieg laboratorium do specyfiki projektu. W każdym wypadku wymaga się jednak, aby praca projektowa była udokumentowana.\n",
|
||||
"Opiekunowie otrzymują od wykładowcy przedmiotu PPB proponowane scenariusze wszystkich laboratoriów przedmiotu PBR wraz z wytycznymi dotyczącymi oceniania pracy studentów. Opiekun projektu ma jednak prawo odstąpić od proponowanych scenariuszy - częściowo lub w całości, dostosowując przebieg laboratorium do specyfiki projektu. \n",
|
||||
"\n",
|
||||
"## Ocena końcowa z przedmiotu PBR\n",
|
||||
"Studentom informatyki ocenę końcową z laboratorium wystawia opiekun projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z laboratorium SYI\n",
|
||||
"Studentom analizy i przetwarzania danych ocenę końcową wystawia prowadzący laboratorium na wniosek opiekuna projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Umiejętności nabywane podczas przedmiotu PBR\n",
|
||||
"Student informatyki powinien nabyć następujące umiejętności:\n",
|
||||
"* tworzenie koncepcji projektu badawczo-rozwojowego,\n",
|
||||
"* implementacja systemu informatycznego w metodyce zwinnej,\n",
|
||||
"* stosowanie praktyki ciągłej integracji w rozwoju systemu informatycznego,\n",
|
||||
"* wdrożenie systemu będącego wynikiem projektu badawczo-rozwojowego w praktyce gospodarczej.\n",
|
||||
"\n",
|
||||
"## Umiejętności nabywane podczas laboratorium SYI\n",
|
||||
"Student analizy i przetwarzania danych powinien nabyć następujące umiejętności:\n",
|
||||
"* dostarczanie i analiza danych do systemu informatycznego,\n",
|
||||
"* tworzenie dokumentacji projektowej,\n",
|
||||
"* przygotowanie i prowadzenie testów funkcjonalnych,\n",
|
||||
"* opracowanie raportów użyteczności,\n",
|
||||
"* tworzenie skryptów wspomagających implementację i testowanie.\n"
|
||||
"W każdym wypadku wymaga się jednak, aby praca projektowa była udokumentowana."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Organizacja wykładów PPB oraz SYI\n",
|
||||
"Wykłady z przedmiotów SYI i PBR prowadzone są równolegle, aby umożliwić współpracę studentów obu kierunków podczas laboratoriów PRB oraz SYI.\n",
|
||||
"# 3. Zasady zaliczenia wykładów PPB i SYI\n",
|
||||
"Zasady zaliczania wykładów PPB i SYI są takie same.\n",
|
||||
"\n",
|
||||
"### Zasady zaliczenia wykładu\n",
|
||||
"Wykład może być zaliczony albo na podstawie punktów uzyskanych za rozwiązywanie testów podawanych na wykładzie, albo poprzez egzamin końcowy. \n",
|
||||
"\n",
|
||||
"Za prawidłowe odpowiedzi na pytania testowe podawane podczas wykładu studenci otrzymują punkty (1 punkt za prawidłową odpowiedź). Testy rozwiązywane mogą być na dowolnych urządzeniach, które dysponują przeglądarką internetową. System do testów jest osiągalny pod adresem: \n",
|
||||
@ -105,16 +115,122 @@
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>poniżej</td><td>egzamin</td>\n",
|
||||
" </tr>\\n\n",
|
||||
"</table>"
|
||||
" </tr>\n",
|
||||
"</table>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
"source": [
|
||||
"# 4. Zasady zaliczenia z laboratoriów PBR i SYI\n",
|
||||
"\n",
|
||||
"Zasady zaliczenia obu przedmiotów są takie same.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z przedmiotu PBR\n",
|
||||
"Studentom informatyki ocenę końcową z laboratorium wystawia opiekun projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z laboratorium SYI\n",
|
||||
"Studentom analizy i przetwarzania danych ocenę końcową wystawia prowadzący laboratorium na wniosek opiekuna projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Proponowana punktacja zadań wykonywanych na przedmiocie PBR\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Typ zadania</td> <td>Liczba punktów</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Zadania na laboratoriach</td><td>12 x 30 = 360</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Sprinty</td><td>6 x 10 = 60</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Ocena końcowa za wynik projektu</td><td>180</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Suma</td><td>600</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>\n",
|
||||
"\n",
|
||||
"## Ocena projektu\n",
|
||||
"\n",
|
||||
"Na przedostatnich zajęciach z laboratorium w dniu 25 stycznia 2022 opiekun projektu decyduje, czy projekt spełnił swoje założenia. Zgodnie z propozycją z wykładu projekt powinien znajdować się na 6. poziomie gotowości technologicznej:\n",
|
||||
"\n",
|
||||
"* Poziom 5.\n",
|
||||
" * Zweryfikowano działanie w warunkach zbliżónych do rzeczywistego (np. przeprowadzono testowanie prototypu wdrożónego na serwerze WMI).\n",
|
||||
"* Poziom 6.\n",
|
||||
" * Dokonano demonstracji działania w warunkach zbliżónych do rzeczywistych (np. zademonstrowano wdrożony prototyp z interakcją użytkowników).\n",
|
||||
" \n",
|
||||
"Jeśli projekt nie spełnia założeń, to ocena końcowa za wynik projektu wynosi 0 punktów (na 180).\n",
|
||||
"\n",
|
||||
"Jeśli projekt spełnia założenia, to opiekun projektu proponuje ocenę w skali do 180 punktów.\n",
|
||||
"\n",
|
||||
"Proponowane składowe oceny implementacji systemu\n",
|
||||
"\n",
|
||||
"<table>\n",
|
||||
" <tr> \n",
|
||||
" <td> Za co? </td> <td> Maksymalna liczba punktów do zdobycia </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td> Functionality (funkcjonalność) </td> <td> 40 </td> \n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Usability (Użyteczność) </td> <td> 30 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td> Reliability (niewystępowanie błędów) </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Performance (wydajność: zużycie zasobów, czas odpowiedzi) </td> <td>10 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Supportability (możliwość instalacji i działania na różnych platformach) </td> <td> 10 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Podręcznik użytkowania lub pomocy dla użytkownika) </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td>Raport z testowania wersji końcowej </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Raport użyteczności wersji końcowej </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Documentation (zebranie wytworzonych dokumentów systemu oraz podręcznika i raportów (testowania i użyteczności)) </td> <td> 10 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> SUMA </td> <td> 180 </td>\n",
|
||||
" </tr>\n",
|
||||
" </table>\n",
|
||||
" \n",
|
||||
"Ocena proponowana przez opiekuna jest weryfikowana przez komisję, w skład której wchodzą wszyscy opiekunowie po demonstracji publicznej projektu w dniu 2 lutego 2022.\n",
|
||||
"\n",
|
||||
"## Demontracje projektów\n",
|
||||
"\n",
|
||||
"Demonstracje publiczne projektów odbędą się w dniu 1 lutego 2022 (wtorek). Demonstracje trwać będą sumarycznie około trzech godzin (po 10 minut na system). Godziny demonstracji zostaną uzgodnione z prowadzącymi seminarium mgr - mniej więcej między godziną 14.00 i 17.00.\n",
|
||||
"\n",
|
||||
"## Proponowana skala ocen na przedmiocie PBR\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Liczba punktów</td> <td>Ocena</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>500-600</td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>450-499</td><td>4,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>400-449</td><td>4</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>350-399</td><td>3,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>300-349</td><td>3</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>\n"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
|
||||
@ -159,7 +159,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.7.6"
|
||||
"version": "3.8.5"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
|
||||
257
Organizacja zajęć na przedmiotach SYI oraz PBR.ipynb
Normal file
257
Organizacja zajęć na przedmiotach SYI oraz PBR.ipynb
Normal file
@ -0,0 +1,257 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Organizacja zajęć na przedmiotach PPB, SYI oraz PBR"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Założenia ogólne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Przygotowanie do projektu badawczo-rozwojowego (PPB)\n",
|
||||
"Przygotowanie do projektu badawczo-rozwojowego to przedmiot prowadzony w formie wykładów dla studentów II roku studiów magisterskich na kierunku Informatyka. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia projektu badawczo-rozwojowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.2. Projekt badawczo-rozwojowy (PBR)\n",
|
||||
"Projekt badawczo-rozwojowy to przedmiot prowadzony w formie laboratoriów dla studentów II roku studiów magisterskich na kierunku informatyka.\n",
|
||||
"\n",
|
||||
"Wskazane jest, aby projekt badawczo-rozwojowy przyczyniał się do rozwoju prac magisterskich członków zespołu.\n",
|
||||
"\n",
|
||||
"* Student informatyki powinien nabyć następujące umiejętności:\n",
|
||||
" * tworzenie koncepcji projektu badawczo-rozwojowego,\n",
|
||||
" * implementacja systemu informatycznego w metodyce zwinnej,\n",
|
||||
" * stosowanie praktyki ciągłej integracji w rozwoju systemu informatycznego,\n",
|
||||
" * wdrożenie systemu będącego wynikiem projektu badawczo-rozwojowego w praktyce gospodarczej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Systemy informatyczne (SYI)\n",
|
||||
"Systemy informatyczne to przedmiot prowadzony w formie wykładów i laboratoriów dla studentów III semestru studiów magisterskich na kierunku Analiza i Przetwarzanie Danych. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia systemu informatycznego - na przykładzie projektu badawczo-rozwojowego rozwijanego przez studentów studiów magisterskich na kierunku Informatyka. \n",
|
||||
"W ramach laboratorium do przedmiotu SYI studenci uczestniczą w tworzeniu projektów badawczo-rozwojowych razem ze studentami Informatyki.\n",
|
||||
"\n",
|
||||
" * Student analizy i przetwarzania danych powinien nabyć następujące umiejętności:\n",
|
||||
"\n",
|
||||
" * dostarczanie i analiza danych do systemu informatycznego,\n",
|
||||
" * tworzenie dokumentacji projektowej,\n",
|
||||
" * przygotowanie i prowadzenie testów funkcjonalnych,\n",
|
||||
" * opracowanie raportów użyteczności,\n",
|
||||
" * tworzenie skryptów wspomagających implementację i testowanie."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Współpraca studentów na przedmiotach SYI oraz PBR\n",
|
||||
"\n",
|
||||
"Studenci przedmiotów SYI oraz PBR współpracują ze sobą, tworząc razem zespoły o liczności od trzech do pięciu studentów. W skład zespołów wchodzą studenci obu przedmiotów. \n",
|
||||
"\n",
|
||||
"Aby umożliwić taką współpracę, laboratoria z przedmiotów SYI i PBR prowadzone są w ten sam dzień tygodnia i o tej samej godzinie. Studenci obu kierunków współpracują w tworzeniu wspólnego projektu badawczo-rozwojowego. \n",
|
||||
"\n",
|
||||
"Zespół projektowy powinien zatem składać się ze studentów obu kierunków (idealnie: dwóch studentów informatyki i dwóch studentów analizy danych). Skład zespołów może się kształtować podczas pierwszych trzech laboratoriów. Począwszy od laboratorium nr 4 studenci pracują w stałych zespołach.\n",
|
||||
"\n",
|
||||
"Każdy zespół ma opiekuna - osobę z kadry WMI UAM.\n",
|
||||
"\n",
|
||||
"Opiekunowie otrzymują od wykładowcy przedmiotu PPB proponowane scenariusze wszystkich laboratoriów przedmiotu PBR wraz z wytycznymi dotyczącymi oceniania pracy studentów. Opiekun projektu ma jednak prawo odstąpić od proponowanych scenariuszy - częściowo lub w całości, dostosowując przebieg laboratorium do specyfiki projektu. \n",
|
||||
"\n",
|
||||
"W każdym wypadku wymaga się jednak, aby praca projektowa była udokumentowana."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Zasady zaliczenia wykładów PPB i SYI\n",
|
||||
"Zasady zaliczania wykładów PPB i SYI są takie same.\n",
|
||||
"\n",
|
||||
"Wykład może być zaliczony albo na podstawie punktów uzyskanych za rozwiązywanie testów podawanych na wykładzie, albo poprzez egzamin końcowy. \n",
|
||||
"\n",
|
||||
"Za prawidłowe odpowiedzi na pytania testowe podawane podczas wykładu studenci otrzymują punkty (1 punkt za prawidłową odpowiedź). Testy rozwiązywane mogą być na dowolnych urządzeniach, które dysponują przeglądarką internetową. System do testów jest osiągalny pod adresem: \n",
|
||||
" **cybertest2.wmi.amu.edu.pl** \n",
|
||||
"Logowanie do systemu odbywa się za pomocą standardowych danych dostępowych na WMI. \n",
|
||||
"\n",
|
||||
"Wykładowca zobowiązuje się do przeprowadzenia testów z minimum 120 pytaniami podczas całego kursu (standardowo: 5 pytań powtórkowych na początku wykładu i 5 pytań na końcu wykładu). \n",
|
||||
"\n",
|
||||
"### Zwolnienia z egzaminu\n",
|
||||
"Student zwolniony jest z egzaminu z oceną dostateczny plus lub wyższą, wynikającą z punktów zdobytych za rozwiązanie zadań testowych podawanych na wykładach. \n",
|
||||
"\n",
|
||||
"Studenci niespełniający powyższego kryterium zdają egzamin obejmujący materiał przedstawiany na wykładach. Studenci mogą zdawać egzamin również w sytuacji, gdy nie satysfakcjonuje ich ocena uzyskana na podstawie zdobytych punktów.\n",
|
||||
"\n",
|
||||
"### Skala ocen z wykładu \n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Liczba prawidłowych odpowiedzi</td> <td>Ocena</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td>100-120</td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>90-99</td><td>4,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>80-89</td><td>4</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>70-79</td><td>3,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>poniżej</td><td>egzamin</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Zasady zaliczenia z laboratoriów PBR i SYI\n",
|
||||
"\n",
|
||||
"Zasady zaliczenia obu przedmiotów są takie same.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z przedmiotu PBR\n",
|
||||
"Studentom informatyki ocenę końcową z laboratorium wystawia opiekun projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z laboratorium SYI\n",
|
||||
"Studentom analizy i przetwarzania danych ocenę końcową wystawia prowadzący laboratorium na wniosek opiekuna projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Proponowana punktacja zadań wykonywanych na przedmiocie PBR\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Typ zadania</td> <td>Liczba punktów</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Zadania na laboratoriach</td><td>12 x 30 = 360</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Sprinty</td><td>6 x 10 = 60</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Ocena końcowa za wynik projektu</td><td>180</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Suma</td><td>600</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>\n",
|
||||
"\n",
|
||||
"## Ocena projektu\n",
|
||||
"\n",
|
||||
"Na przedostatnich zajęciach z laboratorium w dniu 25 stycznia 2022 opiekun projektu decyduje, czy projekt spełnił swoje założenia. Zgodnie z propozycją z wykładu projekt powinien znajdować się na 6. poziomie gotowości technologicznej:\n",
|
||||
"\n",
|
||||
"* Poziom 5.\n",
|
||||
" * Zweryfikowano działanie w warunkach zbliżónych do rzeczywistego (np. przeprowadzono testowanie prototypu wdrożónego na serwerze WMI).\n",
|
||||
"* Poziom 6.\n",
|
||||
" * Dokonano demonstracji działania w warunkach zbliżónych do rzeczywistych (np. zademonstrowano wdrożony prototyp z interakcją użytkowników).\n",
|
||||
" \n",
|
||||
"Jeśli projekt nie spełnia założeń, to ocena końcowa za wynik projektu wynosi 0 punktów (na 180).\n",
|
||||
"\n",
|
||||
"Jeśli projekt spełnia założenia, to opiekun projektu proponuje ocenę w skali do 180 punktów.\n",
|
||||
"\n",
|
||||
"Proponowane składowe oceny implementacji systemu\n",
|
||||
"\n",
|
||||
"<table>\n",
|
||||
" <tr> \n",
|
||||
" <td> Za co? </td> <td> Maksymalna liczba punktów do zdobycia </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td> Functionality (funkcjonalność) </td> <td> 40 </td> \n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Usability (Użyteczność) </td> <td> 30 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td> Reliability (niewystępowanie błędów) </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Performance (wydajność: zużycie zasobów, czas odpowiedzi) </td> <td>10 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Supportability (możliwość instalacji i działania na różnych platformach) </td> <td> 10 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Podręcznik użytkowania lub pomocy dla użytkownika) </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td>Raport z testowania wersji końcowej </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Raport użyteczności wersji końcowej </td> <td> 20 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> Documentation (zebranie wytworzonych dokumentów systemu oraz podręcznika i raportów (testowania i użyteczności)) </td> <td> 10 </td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td> SUMA </td> <td> 180 </td>\n",
|
||||
" </tr>\n",
|
||||
" </table>\n",
|
||||
" \n",
|
||||
"Ocena proponowana przez opiekuna jest weryfikowana przez komisję, w skład której wchodzą wszyscy opiekunowie po demonstracji publicznej projektu w dniu 2 lutego 2022.\n",
|
||||
"\n",
|
||||
"## Demontracje projektów\n",
|
||||
"\n",
|
||||
"Demonstracje publiczne projektów odbędą się w dniu 1 lutego 2022 (wtorek). Demonstracje trwać będą sumarycznie około trzech godzin (po 10 minut na system). Godziny demonstracji zostaną uzgodnione z prowadzącymi seminarium mgr - mniej więcej między godziną 14.00 i 17.00.\n",
|
||||
"\n",
|
||||
"## Proponowana skala ocen na przedmiocie PBR\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Liczba punktów</td> <td>Ocena</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>500-600</td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>450-499</td><td>4,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>400-449</td><td>4</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>350-399</td><td>3,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>300-349</td><td>3</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>\n"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"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.7.6"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,112 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Organizacja zajęć na przedmiocie Projekt badawczo-rozwojowy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Projekt badawczo-rozwojowy (PBR)\n",
|
||||
"## Laboratorium przedmiotu SYI\n",
|
||||
"Projekt badawczo-rozwojowy to przedmiot prowadzony w formie laboratoriów dla studentów II semestru studiów magisterskich na kierunku Informatyka.\n",
|
||||
"Wskazane jest, aby projekt badawczo-rozwojowy przyczyniał się do rozwoju prac magisterskich członków zespołu.\n",
|
||||
"\n",
|
||||
"Studenci Informatyki współpracują ze studentami Analizy i Przetwarzania Danych, tworząc razem zespoły o liczności od trzech do pięciu studentów. Aby umożliwić taką współpracę, laboratoria z przedmiotów SYI i PBR prowadzone są w ten sam dzień tygodnia i o tej samej godzinie. Studenci obu kierunków współpracują w tworzeniu wspólnego projektu badawczo-rozwojowego. \n",
|
||||
"\n",
|
||||
"Zespół projektowy powinien zatem składać się ze studentów obu kierunków (idealnie: dwóch studentów informatyki i dwóch studentów analizy danych). Skład zespołów może się kształtować podczas pierwszych trzech laboratoriów. Począwszy od laboratorium nr 4 studenci pracują w stałych zespołach.\n",
|
||||
"\n",
|
||||
"Osobą oceniającą pracę całego zespołu projektowego jest opiekun projektu badawczo-rozwojowego. \n",
|
||||
"\n",
|
||||
"Opiekunowie otrzymują od wykładowcy przedmiotu PPB proponowane scenariusze wszystkich laboratoriów przedmiotu PBR wraz z wytycznymi dotyczącymi oceniania pracy studentów. Opiekun projektu ma jednak prawo odstąpić od proponowanych scenariuszy - częściowo lub w całości, dostosowując przebieg laboratorium do specyfiki projektu. W każdym wypadku wymaga się jednak, aby praca projektowa była udokumentowana.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z przedmiotu PBR\n",
|
||||
"Studentom informatyki ocenę końcową z laboratorium wystawia opiekun projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Umiejętności nabywane podczas przedmiotu PBR\n",
|
||||
"Student informatyki powinien nabyć następujące umiejętności:\n",
|
||||
"* tworzenie koncepcji projektu badawczo-rozwojowego,\n",
|
||||
"* implementacja systemu informatycznego w metodyce zwinnej,\n",
|
||||
"* stosowanie praktyki ciągłej integracji w rozwoju systemu informatycznego,\n",
|
||||
"* wdrożenie systemu będącego wynikiem projektu badawczo-rozwojowego w praktyce gospodarczej.\n",
|
||||
"\n",
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Organizacja wykładów PPB oraz SYI\n",
|
||||
"Wykłady z przedmiotów SYI i PBR prowadzone są równolegle, aby umożliwić współpracę studentów obu kierunków podczas laboratoriów PRB oraz SYI.\n",
|
||||
"\n",
|
||||
"### Zasady zaliczenia wykładu\n",
|
||||
"Wykład może być zaliczony albo na podstawie punktów uzyskanych za rozwiązywanie testów podawanych na wykładzie, albo poprzez egzamin końcowy. \n",
|
||||
"\n",
|
||||
"Za prawidłowe odpowiedzi na pytania testowe podawane podczas wykładu studenci otrzymują punkty (1 punkt za prawidłową odpowiedź). Testy rozwiązywane mogą być na dowolnych urządzeniach, które dysponują przeglądarką internetową. System do testów jest osiągalny pod adresem: \n",
|
||||
" **cybertest2.wmi.amu.edu.pl** \n",
|
||||
"Logowanie do systemu odbywa się za pomocą standardowych danych dostępowych na WMI. \n",
|
||||
"\n",
|
||||
"Wykładowca zobowiązuje się do przeprowadzenia testów z minimum 120 pytaniami podczas całego kursu (standardowo: 5 pytań powtórkowych na początku wykładu i 5 pytań na końcu wykładu). \n",
|
||||
"\n",
|
||||
"### Zwolnienia z egzaminu\n",
|
||||
"Student zwolniony jest z egzaminu z oceną dostateczny plus lub wyższą, wynikającą z punktów zdobytych za rozwiązanie zadań testowych podawanych na wykładach. \n",
|
||||
"\n",
|
||||
"Studenci niespełniający powyższego kryterium zdają egzamin obejmujący materiał przedstawiany na wykładach. Studenci mogą zdawać egzamin również w sytuacji, gdy nie satysfakcjonuje ich ocena uzyskana na podstawie zdobytych punktów.\n",
|
||||
"\n",
|
||||
"### Skala ocen z wykładu \n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Liczba prawidłowych odpowiedzi</td> <td>Ocena</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td>100-120</td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>90-99</td><td>4,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>80-89</td><td>4</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>70-79</td><td>3,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>poniżej</td><td>egzamin</td>\n",
|
||||
" </tr>\\n\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"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.7.6"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -6,7 +6,7 @@
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 8. <i>Testowanie w programowaniu zwinnym</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
@ -22,7 +22,24 @@
|
||||
"Celem laboratorium jest opracowaniu testów mających zastosowanie w programowaniu zwinnnym.\n",
|
||||
"\n",
|
||||
"# Proponowany plan laboratorium\n",
|
||||
"TO DO"
|
||||
"## Zadanie 1.\n",
|
||||
"Wykorzystać wiedzę z wykładu do opracowania dwóch typów nowych testów jednostkowych. Proponowane typy testów to \"mock\" oraz \"stub\". \n",
|
||||
"\n",
|
||||
"10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2.\n",
|
||||
"Dla istniejącej wersji projektowanego systemu:\n",
|
||||
" * Opracować kilka przypadków testowych skłądających się z jednej akcji;\n",
|
||||
" * Opracować jeden przypadek testowy ze scenariuszem składającym się z kilku kroków.\n",
|
||||
" \n",
|
||||
"10 punktów\n",
|
||||
" \n",
|
||||
"## Zadanie 3.\n",
|
||||
"Zbudować podwaliny pod metodę \"Test first\" poprzez opracowaie przypadków testowych funkcji systemu, które nie zostały jeszcze zaimplementowane:\n",
|
||||
" * Opracować kilka przypadków testowych skłądających się z jednej akcji;\n",
|
||||
" * Opracować jeden przypadek testowy ze scenariuszem składającym się z kilku kroków.\n",
|
||||
" \n",
|
||||
"10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
@ -48,7 +65,7 @@
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "08. Testowanie w programowaniu zwinnym[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
|
||||
@ -5,8 +5,7 @@
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<div Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 9. <i>Testowanie integracyjne i systemowe</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
@ -27,17 +26,14 @@
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Testy integracyjne\n",
|
||||
"TO DO \n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
"\n",
|
||||
" ## Zadanie 2. Testy systemowe\n",
|
||||
" ## Zadanie 1. Testy systemowe\n",
|
||||
"Opracujcie plan testów, zawierający przypadki testowe. \n",
|
||||
"Należy założyć, że testy mają obejmować co najmniej 3 typy testowania. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
"Maksymalna ocena: 20 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Testy automatyczne\n",
|
||||
"## Zadanie 2. Testy automatyczne\n",
|
||||
"Korzystając z frameworku Selenium opracujcie test automatyczny, sprawdzający jakąś podstawową funkcjonalność Waszego systemu (np. logowanie.) \n",
|
||||
"(W zastępstwie można opracować test automatyczny logowania do jednego z systemów: USOS, Jira lub Git.) \n",
|
||||
"Jako wynik zadania umieśćcie nagranie testu. \n",
|
||||
@ -68,7 +64,7 @@
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "09. Testowanie integracyjne i systemowe[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 12. <i>Ocena jakości systemu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h2> 11. <i>Ocena jakości systemu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\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."
|
||||
]
|
||||
},
|
||||
@ -82,14 +82,10 @@
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 4. Role w projekcie według metodyki Scrum\n",
|
||||
"Podzielcie się rolami w projekcie według metodyki Scrum i opiszcie, jak widzicie swoje zadania w projekcie:\n",
|
||||
"* zespół deweloperski, a w nim scrum master\n",
|
||||
"* zespół product ownera, a w nim tester\n",
|
||||
"Podzielcie się rolami w projekcie według metodyki Scrum i opiszcie, jak widzicie swoje zadania w projekcie.\n",
|
||||
"\n",
|
||||
"Opracujcie 5-punktowy manifest pracy w Waszym zespole. \n",
|
||||
"\n",
|
||||
"Podsumujcie, która metodyka pracy bardziej Wam odpowiada pod kątem podziału ról. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
|
||||
@ -49,8 +49,8 @@
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Pierwszy sprint!\n",
|
||||
"Zalóżcie pierwszy sprint. \n",
|
||||
"## Drugi sprint!\n",
|
||||
"Zalóżcie drugi sprint. \n",
|
||||
"Przenieście wybrane elementy (\"issues\") z backloga do sprintu, podzielcie je na zadania, przypiszcie zadania ludziom i skomentujcie je (w ich opisie). \n",
|
||||
"Oszacujcie w punktach pracochłonność wykonania każdego zadania."
|
||||
]
|
||||
|
||||
@ -0,0 +1,84 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 11. <i>Ocena jakości systemu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"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
|
||||
}
|
||||
@ -14,6 +14,13 @@
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Pojęcie użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -22,7 +29,7 @@
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \n",
|
||||
"\n",
|
||||
"Użyteczność narzędzia: łatwość, z jaką ludzie potrafią korzystać z pewnego narzędzia w celu osiągnięcia określonego celu.\n",
|
||||
"Użyteczność narzędzia: łatwość, z jaką ludzie potrafią korzystać z tego narzędzia w celu osiągnięcia określonego celu.\n",
|
||||
"\n",
|
||||
"<h3> Cechy aplikacji użytecznej </h3>\n",
|
||||
" \n",
|
||||
@ -36,6 +43,63 @@
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Wskazówki do tworzenia użytecznej aplikacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Klasyka w oparciu o \"Don't make me think\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<a href=\"https://www.uxbooth.com/articles/10-usability-lessons-from-steve-krugs-dont-make-me-think/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"<ol> \n",
|
||||
" \n",
|
||||
"<li> Usability Means… </li>\n",
|
||||
"\n",
|
||||
"<li>Web applications should explain themselves. </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t Make Me Think </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t waste my time </li>\n",
|
||||
" \n",
|
||||
"<li> Users still cling to their back buttons </li>\n",
|
||||
"\n",
|
||||
"<li> We’re creatures of habit </li>\n",
|
||||
"\n",
|
||||
"<li> No Time for Small Talk </li>\n",
|
||||
"\n",
|
||||
"<li> Don’t lose search </li>\n",
|
||||
"\n",
|
||||
"<li> We form mental site-maps </li>\n",
|
||||
"\n",
|
||||
"<li> Make it easy to go home </li>\n",
|
||||
" \n",
|
||||
"</ol>\n",
|
||||
"\n",
|
||||
"<div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Podejście (bardziej) współczesne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -74,16 +138,420 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Użyteczność portali internetowych\n",
|
||||
"### 10 heurystyk Jakoba Nielsena i Rolfa Molicha\n",
|
||||
"### Zasady dobrej nawigacji"
|
||||
"## 3. Zasady dobrej nawigacji na portalu internetowym\n",
|
||||
"### 3.1. Pojęcie nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<b> Nawigacja </b> to stały, niezmieniający się zestaw elementów w serwisie ułatwiający poruszanie się na niej.\n",
|
||||
" \n",
|
||||
"Najczęściej stosowanymi elementami nawigacji są: \n",
|
||||
"<ul>\n",
|
||||
"<li> Menu główne </li>\n",
|
||||
"<li> Menu narzędziowe </li>\n",
|
||||
"<li> Identyfikator witryny </li>\n",
|
||||
"<li> Wyszukiwarka </li>\n",
|
||||
"<li> Odsyłacz do strony startowej (zawarty w logo) </li>\n",
|
||||
"<li> Flagi narodowe (przełączenie języków) </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Tworzenie raportu użyteczności"
|
||||
"## 3.2. Cechy dobrej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Szybkie przechodzenie po różnych elementach serwisu.\n",
|
||||
" * Łatwe prowadzenie użytkownika do poszukiwanej informacji. \n",
|
||||
" * Klarowność: użytkownik wie gdzie jest, gdzie może się skierować, jak wrócić, a także posiada informacje o odwiedzonych miejscach. \n",
|
||||
" * Oszczędność: główne menu witryny nie powinno zawierać zbyt wielu elementów (między 5 a 9)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.3. Zasady użytecznej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 1. Widoczność\n",
|
||||
"Wszystkie elementy nawigacji muszą być bardzo dobrze widoczne na każdej stronie i podstronie serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 2. Przewidywalność\n",
|
||||
" * Nazwy elementów menu powinny pozwalać na przewidzenie zawartości\n",
|
||||
" * Elementy menu powinny informować użytkownika o całej zawartości witryny.\n",
|
||||
" * Odwiedzone linki powinny być oznaczone innym kolorem niż nieodwiedzone. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 3. Łatwość orientacji w strukturze serwisu\n",
|
||||
"* Powinno się stosować różne style wyróżnienia jego elementów:\n",
|
||||
" * dla całej kategorii, na której aktualnie znajduje się kursor (np. Aktualności),\n",
|
||||
" * dla pozycji w menu, z której aktualnie korzysta użytkownik (np. Publikacje zagraniczne),\n",
|
||||
" * dla pozostałych elementów serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 4. Zasada odwróconej piramidy\n",
|
||||
" * Na najwyższym poziomie należy umieścić kategorie najbardziej ogólne, a następnie przechodzić do podziału bardziej szczegółowego. \n",
|
||||
" * Na tym samym poziomie powinny znajdować się kategorie o tym samym stopniu szczegółowości."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 5. Właściwe nazewnictwo\n",
|
||||
" * Wykluczający podział etykiet menu: \n",
|
||||
" * dana pozycja w menu może należeć tylko do jednej kategorii.\n",
|
||||
" * Proste nazewnictwo: \n",
|
||||
" * etykiety powinno formułować się w języku zrozumiałym dla użytkownika,\n",
|
||||
" * powinno unikać się specjalistycznego słownictwa.\n",
|
||||
" * Unikalne nazwy: \n",
|
||||
" * dana nazwa powinna pojawiać się w serwisie internetowym nie więcej niż raz,\n",
|
||||
" * każda strona powinna mieć swoja nazwę.\n",
|
||||
" * Nazwa strony musi być dobrze widoczna:\n",
|
||||
" * nazwa strony musi być w dobrze umiejscowiona i wyróżniona za pomocą rozmiaru i koloru czcionki.\n",
|
||||
" * Nazwa strony lub podstrony musi być zgodna z nazwą odsyłacza, który do niej prowadzi."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 6. Spójność w wyglądzie i działaniu elementów nawigacyjnych\n",
|
||||
"* Należy stosować te same konwencje w obrębie całego menu. \n",
|
||||
"* Elementy pierwszego poziomu powinny pozostawać niezmienne w trakcie korzystania z całego serwisu internetowego. \n",
|
||||
"* Wszystkie pozycje w menu powinny funkcjonować na tej samej zasadzie. \n",
|
||||
"* Przy formułowaniu nazw w menu należy w każdym przypadku stosować tę samą formę gramatyczną.\n",
|
||||
"* Pozycje menu należące do jednego poziomu powinny być sformatowane w jednym stylu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Automatyczne metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Badanie współczynnika konwersji\n",
|
||||
"**Współczynnik konwersji** wskazuje, jaka część internautów odwiedzających daną stronę dokonała pożądanej akcji np.\n",
|
||||
" * Dokonała zakupu\n",
|
||||
" * Wypełniła formularz\n",
|
||||
" * Wysłała maila na wskazany adres\n",
|
||||
" * Zarejestrowała się do systemu\n",
|
||||
" * Pobrała software"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy A/B (testy porównawcze)\n",
|
||||
"* Metoda polega na porównaniu dwóch wersji tej samej aplikacji.\n",
|
||||
"* Najczęściej stosowana jest do stron internetowych.\n",
|
||||
"* Różnicę (postęp lub regres) między wersjami wyznacza się poprzez porównanie wartości pewnej miary, np. współczynnika konwersji dla stron internetowych. \n",
|
||||
"\n",
|
||||
"[Przeczytaj w Internecie](https://www.optimizely.com/ab-testing/)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analityka ruchu na portalu internetowym\n",
|
||||
"Metoda polega na obserwacji dotyczących ruchu na witrynie, takich jak:\n",
|
||||
" * Wskaźnik odrzuceń – procentowa wartość osób, które opuściły stronę wejściową serwisu bez wykonania żadnej akcji\n",
|
||||
" * Wskaźnik porzuceń – wskaźnik analogiczny dla podstron danego serwisu,\n",
|
||||
"Metoda wskazuje działania użytkownika – nie wskazuje jego przyczyn. \n",
|
||||
"\n",
|
||||
"Przykładowa witryna: \n",
|
||||
"https://www.google.com/analytics/"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Click-tracking\n",
|
||||
"\n",
|
||||
"Metoda dostarcza informacji o poszczególnych elementach strony za pomocą następujących typów informacji\n",
|
||||
" * Heat maps. \n",
|
||||
" * Wskazują, w jakie miejsca na stronie ludzie klikają (see what’s hot and what’s not).\n",
|
||||
" * Confetti\n",
|
||||
" * Analiza kliknięć: jak klikały poszczególne grupy użytkowników i w poszukiwaniu czego.\n",
|
||||
" * Scrollmap\n",
|
||||
" * Analiza, jak daleko w dół strony użytkownicy przewijają stronę – pozwala przeanalizować miejsca, w których strona jest najczęściej porzucana.\n",
|
||||
" * Overlay report\n",
|
||||
" * Liczba kliknięć na poszczególne elementy strony.\n",
|
||||
"\n",
|
||||
"Przykładowy dostawca: \n",
|
||||
"http://www.crazyegg.com"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analiza kontrastu\n",
|
||||
"\n",
|
||||
"Dostarcza informacji o kontraście pomiędzy elementami strony, co jest szczególnie istotne dla osób z upośledzeniem wzroku.\n",
|
||||
"\n",
|
||||
"* Przykładowy adres\n",
|
||||
" * https://webaim.org/resources/contrastchecker/\n",
|
||||
" * Można wpisać adres strony, która ma zostać przeanalizowana pod względem kontrastu – otrzymuje się pełen raport."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Metody z udziałem użytkowników\n",
|
||||
"\n",
|
||||
"W metodach z udziałem użytkowników można posłużyć się zastosowaniem *persony*, w celu optymalizacji kosztów badania.\n",
|
||||
" * **Persona** to fikcyjna postać stworzona by reprezentować typy użytkowników (demograficzne i technograficzne).\n",
|
||||
" * Persony to inaczej archetypy grup użytkowników i ich potrzeb. Dzięki personom cała populacja docelowa reprezentowana jest przez kilka konceptów.\n",
|
||||
" > Przykład persony: Jan Kowalski, lat 37, elektryk, mieszkaniec Ząbkowic Śląskich\n",
|
||||
" \n",
|
||||
" Przykładowy proces testowania użyteczności z udziałem użytkowników:\n",
|
||||
" 1. Określ grupy użytkowników np. przy użyciu persony (co najmniej jedna persona na grupę).\n",
|
||||
" 2. Dla każdej persony utwórz potencjalny scenariusz użycia – w jaki sposób dana persona chce korzystać z systemu.\n",
|
||||
" 3. Dla każdej persony zorganizuj użytkowników reprezentatywnych (minimum jednego użytkownika dla persony).\n",
|
||||
" 4. Poproś ich o wykonanie zadań charakterystycznych dla danej persony.\n",
|
||||
" 5. Obserwuj lub nagrywaj działania użytkowników: gdzie im się powodzi, a gdzie mają trudności.\n",
|
||||
" 6. Potencjalnie poproś użytkowników o wypełnienie ankiet.\n",
|
||||
"\n",
|
||||
"Wyróżniamy następujące typy metod z udziałem użytkowników:\n",
|
||||
" * podgląd sesji użytkowników.\n",
|
||||
" * obserwacja użytkownika,\n",
|
||||
" * metoda wywiadu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Podgląd sesji użytkowników\n",
|
||||
"* Działalność użytkownika jest „nagrywana”.\n",
|
||||
"* Autor oprogramowania może odtworzyć działania użytkownika z perspektywy użytkownika.\n",
|
||||
"* Każde kliknięcie, poruszenie myszą, przesunięcie kursora zostaje zapisane."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Obserwacja użytkownika\n",
|
||||
"* Działalność użytkownika jest obserwowana.\n",
|
||||
"* Obserwator zapisuje poczynania użytkownika.\n",
|
||||
"* Obserwacje są analizowane w celu ulepszenia użyteczności aplikacji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Metoda wywiadu\n",
|
||||
" * Sposoby przeprowadzenia wywiadu:\n",
|
||||
" * Analiza celów użytkowników i wykonywania przez nich zadań,\n",
|
||||
" * Dyskusja prowadzona przez moderatora,\n",
|
||||
" * Wypełnienie ankiet / kwestionariuszy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Raport badania użyteczności\n",
|
||||
"Raport badania użyteczności to sprawozdanie z badania użyteczności aplikacji, w którym wskazuje się **obszary problemowe**.\n",
|
||||
"Przykładowo raport użytecznści może składać się z następujących części:\n",
|
||||
"1. Informacje wstępne\n",
|
||||
"2. Metodologia badania\n",
|
||||
"3. Obszary problemowe\n",
|
||||
"4. Dodatki"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.1. Informacje wstępne\n",
|
||||
"Ta część zawiera ogólne informacje o prowadzonym badaniu, np. :\n",
|
||||
" * Daty tworzenia raportu\n",
|
||||
" * Harmonogram prowadzenia badań\n",
|
||||
" * Odwołanie do standardów badania użyteczności\n",
|
||||
" * Autorzy raportu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.2. Metodologia badania\n",
|
||||
"Opis tej części zależy od przejętej metody badania. Przykładowo, dla metody wywiadu część ta może mieć następującą postać:\n",
|
||||
"\n",
|
||||
"### 5.2.1. Zakres badania\n",
|
||||
" * Określenie zakresu projektowego: badanie gotowego produktu, czy ocena prototypu,\n",
|
||||
" * Określenie celu, np., wskazanie wyłącznie błędów w systemie, czy również wskazanie proponowanych ulepszeń,\n",
|
||||
" * Określenie zastosowanej metody badania użyteczności.\n",
|
||||
"\n",
|
||||
"### 5.2.2. Profile użytkowników\n",
|
||||
" * Określenie kilku segmentów odbiorców pod względem:\n",
|
||||
" * Danych demograficznych\n",
|
||||
" * Doświadczenia z programami podobnymi (wcześniejszymi wersjami systemu)\n",
|
||||
" * Oczekiwań względem systemu\n",
|
||||
"\n",
|
||||
"### 5.2.3. Grupa badawcza\n",
|
||||
" * Określenie liczebności grupy badawczej (około 5 osób)\n",
|
||||
" * Określenie charakterystyki grupy badawczej pod względem różnych kryteriów , np.\n",
|
||||
" * płeć, \n",
|
||||
" * wiek, \n",
|
||||
" * miejsce zamieszkania, \n",
|
||||
" * wykształcenie, \n",
|
||||
" * zawód, \n",
|
||||
" * wielkość firmy, \n",
|
||||
" * branża, \n",
|
||||
" * obsługa komputera, \n",
|
||||
" * doświadczenie z podobnymi programami, itp.\n",
|
||||
" * Liczebność i charakterystykę grupy badawczej można zobrazować za pomocą wykresów.\n",
|
||||
"\n",
|
||||
"### 5.2.4. Scenariusz badania\n",
|
||||
"W tej części należy opisać, jak będzie przebiegać scenariusz badania.\n",
|
||||
"Przykładowy scenariusz badania w metodzie wywiadu:\n",
|
||||
"1. Omówienie zadań i sposobu wypełniania kwestionariusza\n",
|
||||
"2. Podanie informacji o regulaminie przeprowadzenia testu wykonania zadań\n",
|
||||
"3. Test wykonania zadań\n",
|
||||
"4. Wypełnienie przygotowanego kwestionariusza przez użytkowników\n",
|
||||
"\n",
|
||||
"### 5.2.5. Lista zadań do wykonania przez użytkowników\n",
|
||||
"W tej częścI dla każdego zadania należy podać kryterium pomyślnego ukończenia zadania. Lista zadań może być podana w postaci tabelki:\n",
|
||||
" * Opis zadania\n",
|
||||
" * Kryterium ukończenia zadania\n",
|
||||
"\n",
|
||||
"### 5.2.6. Ocena wykonania zadań \n",
|
||||
"W tej części należy ocenić, jak badani wykonali zadania.\n",
|
||||
"Przykładowa ocena wykonania zadań:\n",
|
||||
" * Liczba błędów krytycznych użytkownika\n",
|
||||
" * Liczba błędów niekrytycznych użytkownika\n",
|
||||
" * Liczba zadań wykonanych zgodnie z założeniami\n",
|
||||
" * Liczba zdań niewykonanych zgodnie z założeniami\n",
|
||||
" * Czas wykonania zadań\n",
|
||||
"\n",
|
||||
"Ten etap raportu można zakończyć wykresami."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.3. Obszary problemowe\n",
|
||||
"Obszary problemowe to **wnioski** z badania użyteczności.\n",
|
||||
" * W tej częśći raportu określone zostają obszary problemowe (składowe systemu, które sprawiają kłopoty).\n",
|
||||
" * Dla każdego obszaru problemowego określa się zestaw problemów użytkowania.\n",
|
||||
" * Problem użytkowania składa się z:\n",
|
||||
" * Tytułu problemu,\n",
|
||||
" * Opisu problemu,\n",
|
||||
" * Jeśli problemem jest zbyt długi czas wykonania zadania, to można podać średnie czasy rozwiązania,\n",
|
||||
" * Filmiku wideo (jeśli takim dysponujemy),\n",
|
||||
" * Rekomendacji rozwiązania problemu,\n",
|
||||
" * Opisu proponowanego scenariusza działania użytkownika po rozwiązaniu problemu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.4. Dodatki\n",
|
||||
"W tej części raportu składamy materiały pomocnicze, np.\n",
|
||||
" ### 5.4.1. Ankieta\n",
|
||||
"\n",
|
||||
"W ankiecie mogą znaleźć się przykładowe pytania:\n",
|
||||
" * Jak ocenia Pan/Pani trudność poszczególnych zadań?\n",
|
||||
" * Co sprawiło Panu/Pani największy problem podczas testów?\n",
|
||||
" * Jakie inne funkcjonalności byłyby pożyteczne (wskazać listę do wyboru)?\n",
|
||||
" * Jakie elementy systemu były niezrozumiałe?\n",
|
||||
"\n",
|
||||
" Wyniki ankiety potestowej możemy przedstawić na wykresach.\n",
|
||||
" \n",
|
||||
"### 5.4.2. Inne materiały pomocnicze\n",
|
||||
"Przykładowe materiały pomocnicze:\n",
|
||||
" * Lista filmów video ilustrujących błędy użyteczności aplikacji,\n",
|
||||
" * Wnioski i rekomendacje ekspertów użyteczności,\n",
|
||||
" * Inne materiały w zależności od zastosowanej metody badawczej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie wykładu\n",
|
||||
"1. Tworząc aplikację, myśl przede wszystkim o jej użyteczności, a potem dopiero o jej funkcjonalności.\n",
|
||||
"2. O sukcesie aplikacji stanowi pomysł, a nie wielość funkcji.\n",
|
||||
"3. Zawsze (!) pamiętaj o wskazówkach użyteczności.\n",
|
||||
"4. Tworząc portal internetowy, stosuj zasady dobrej nawigacji.\n",
|
||||
"5. Przekonaj się, jak Twój program jest używany – wykonaj badanie użyteczności."
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@ -18,13 +18,99 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Aspekty użyteczności\n",
|
||||
"Użyteczność aplikacji powinna być analizowana pod kątem sześciu aspektów:\n",
|
||||
"# Aspekty użyteczności w pytaniach... często bez odpowiedzi\n",
|
||||
"Na podstawie książki \"Postaw na użyteczność\" Matta Laceya (Wydawnictwo Naukowe PWN, 2019).\n",
|
||||
"\n",
|
||||
"Podczas konstruowania systemu informatycznego warto zadać sobie pytania, na które odpowiedź wcale nie musi być oczywista - zależeć może ona od typu aplikacji i środowiska, w którym aplikacja będzie używana."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Definicja użyteczności (...jeszcze jedna)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \n",
|
||||
"\n",
|
||||
"Użyteczność to zestaw cech aplikacji, które sprawiają, że korzysta się z niej <b>łatwo</b>.\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Przepis na sukces\n",
|
||||
"\n",
|
||||
"SUKCES = WARTOŚĆ + ODCZUCIA UŻYTKOWNIKA + SZCZĘŚCIE"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Wartość</h3> \n",
|
||||
"\n",
|
||||
"Wartość aplikacji to suma korzyści dla użytkownika: \n",
|
||||
"<ul>\n",
|
||||
"<li>zadanie jest wykonalne\n",
|
||||
"<li>zadanie jest łatwiejsze\n",
|
||||
"<li>zadanie można wykonać szybciej\n",
|
||||
"<li>aplikacja dostarcza dochód lub oszczędza środki\n",
|
||||
"<li>dostarczenie rozrywki\n",
|
||||
"<li>dostarczenie informacji\n",
|
||||
"<li>edukacja \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Odczucia użytkownika (User Experience)</h3> \n",
|
||||
"\n",
|
||||
"Odczucia użytkownika to uczucia i emocje użytkownika doznawane podczas korzystania z aplikacji.\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Szczęście</h3> \n",
|
||||
"\n",
|
||||
"\"Szczęście przychodzi do tego, kto jest przygotowany i napotyka okazje.\" (Seneka)\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Sześć magicznych składników użyteczności...\n",
|
||||
"...czyli sześć aspektów, pod którymi powinniśmy rozpatrywać użyteczność:\n",
|
||||
"* kontekst, \n",
|
||||
"* wprowadzanie danych, \n",
|
||||
"* wyprowadzanie danych, \n",
|
||||
"* responsywność, \n",
|
||||
"* łączność z siecią, \n",
|
||||
"* dostęp do sieci, \n",
|
||||
"* zasoby."
|
||||
]
|
||||
},
|
||||
@ -32,42 +118,547 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Kontekst"
|
||||
"# 1. Kontekst"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Wprowadzanie danych"
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Kontekst</h3> \n",
|
||||
"\n",
|
||||
"Kontekst to środowisko i okoliczności używania aplikacji. Odpowiada na pytania:\n",
|
||||
"<ul>\n",
|
||||
"<li>Kto?\n",
|
||||
"<li>Gdzie?\n",
|
||||
"<li>Kiedy?\n",
|
||||
"<li>Jak? \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Wyprowadzanie danych"
|
||||
"## 1.1. Kto?\n",
|
||||
"\n",
|
||||
"ZASADY:\n",
|
||||
"\n",
|
||||
"1. Musisz precyzyjnie poznać użytkownika.\n",
|
||||
"2. To nie Ty jesteś użytkownikiem.\n",
|
||||
"3. Każdy jest inny.\n",
|
||||
"4. Użytkownik ma prawo robić coś innego\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Responsywność"
|
||||
"### 1.1.1. Musisz precyzyjnie poznać użytkownika\n",
|
||||
"\n",
|
||||
"* Dla kogo aplikacja będzie stanowić wartość?\n",
|
||||
" * Wskazówka: (patrz definicja wartości)\n",
|
||||
"* Kto dokładnie będzie użytkownikiem aplikacji?\n",
|
||||
" * Wskazówka: wykonaj diagram Venna\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/diagram Venna.png\" alt=\"Diagram Venna\" width=500px>\n",
|
||||
"\n",
|
||||
"(Przykładowy diagram Venna, Źródło: Matt Lacey, \"Postaw na użyteczność\")\n",
|
||||
"\n",
|
||||
"* Jakie są grupy użytkowników?\n",
|
||||
" * Wskazówka: metoda persony"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Łączność z siecią"
|
||||
"### 1.1.2. To nie Ty jesteś użytkownikiem\n",
|
||||
" * Czym użytkownik różni się od siebie?\n",
|
||||
" * Czym mogą się rożnić oczekiwania innych uzytkowników od Twoich?\n",
|
||||
" * W stosunku do jakich niedociągnięć użytkownicy mogą być od Ciebie mniej pobłażliwi?\n",
|
||||
" * Dlaczego TY nie jesteś przeciętnym użytkownikiem Twojej aplikacji?\n",
|
||||
" * Jakie umiejętności Cię wyróżniają?\n",
|
||||
" * Dlaczego Tobie będzie łatwiej używać aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zasoby"
|
||||
"### 1.1.3. Każdy jest inny\n",
|
||||
" * Czy użytkownicy aplikacji mogą się różnić w aspekcie dostępności?\n",
|
||||
" Na dostępność składają się:\n",
|
||||
" * umiejętności\n",
|
||||
" * wiedza\n",
|
||||
" * kultura\n",
|
||||
" * lokalizacja\n",
|
||||
" * płeć\n",
|
||||
" * wiek\n",
|
||||
" * niepełnosprawność\n",
|
||||
" * choroby (daltonizm)\n",
|
||||
" * Czy użytkownicy aplikacji mogą mieć od niej różne oczekiwania?\n",
|
||||
" * Czy użytkownicy aplikacji mogą chcieć uzyskać dzięki niej różne cele?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.4. Użytkownik ma prawo robić coś innego\n",
|
||||
" * Jakie inne działania będą podejmować użytkownicy podczas pracy z naszą aplikacją?\n",
|
||||
" * Jak się o tym dowiedzieć?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. 2. Gdzie?\n",
|
||||
"ZASADA: \n",
|
||||
"Czy aplikacja będzie stosowana w różnych krajach?\n",
|
||||
" * Jesli nie, to pomiń dalsze pytania.\n",
|
||||
" * Jeśli tak, to odpowiedz na dalsze pytania.\n",
|
||||
"\n",
|
||||
"PYTANIA:\n",
|
||||
" * Czy zaplanowałeś wielojęzyczność aplikacji?\n",
|
||||
" * Jakimi językami posługują się użytkownicy w innych krajach?\n",
|
||||
" * Zaplanuj tłumaczenie aplikacji\n",
|
||||
" * Czy użytkownicy innych krajów stosują te same formaty liczb / dat?\n",
|
||||
" * Jeśli nie, to opracuj algorytmy konwersji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Kiedy?\n",
|
||||
"### 1.3.1. Pora (dnia, tygodnia, miesiąca, roku)\n",
|
||||
"Czy aplikacja może działać w różny sposób w zależności od:\n",
|
||||
" * pory dnia\n",
|
||||
" * dnia tygodnia\n",
|
||||
" * dnia miesiąca\n",
|
||||
" * pory roku"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.3.2. Czas użytkowania\n",
|
||||
" * Jak długo trwa jedna sesja użytkowania?\n",
|
||||
" * daj możliwość korzystania nawet w bardzo krótkim czasie\n",
|
||||
" * Po jakim czasie użytkownik porzuci aplikację?\n",
|
||||
" * zachęcaj do pozostania z aplikacją"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.4. Jak?\n",
|
||||
"### 1.4.1. Okoliczności\n",
|
||||
" * Czy użytkownik jest w ruchu?\n",
|
||||
" * Czy użytkownik może wykonywać inne czynności?\n",
|
||||
" * Jakie?\n",
|
||||
" * Czy jest skupiony na naszej aplikacji?\n",
|
||||
" * Czy nasza aplikacja współpracuje z innymi?\n",
|
||||
" * W jakiej pozycji użytkownik korzysta z aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.4.2. Urządzenia\n",
|
||||
" * Zasada WORE (Write Once Run Everywhere)\n",
|
||||
" * Plusy\n",
|
||||
" * szybciej powstaje\n",
|
||||
" * łatwiejsza w utrzymaniu\n",
|
||||
" * możliwość dostosowania dla wielu urządzeń\n",
|
||||
" * przydatna szczególnie w grach (niestandardowy UI)\n",
|
||||
" * Minusy\n",
|
||||
" * wymagana znajomość różnych platform\n",
|
||||
" * wymagana dyscyplina kodu\n",
|
||||
" * konieczność dostosowania elementów wizualnych do różnych platform\n",
|
||||
" * konieczność testowania na wielu platformach\n",
|
||||
" * Różne systemy operacyjne\n",
|
||||
" * W jakich systamach operacyjnych ma działać aplikacja?\n",
|
||||
" * Czy wziąłeś pod uwagę ograniczenia narzucane przez różne sklepy?\n",
|
||||
" * Czy wygląd aplikacji jest zgodny z przyzwyczajeniami użytkowników danego systemu?\n",
|
||||
"\n",
|
||||
" * Wielkość urządzenia\n",
|
||||
" * Czy wziąłeś pod uwagę, że wielkość ekranu ma wpływ na to, co jest wyświetlane?\n",
|
||||
" * Czy pomyślałeś, jak trzymane jest urządzenie?\n",
|
||||
" \n",
|
||||
" * Przyciski sprzętowe\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Czujniki\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Wskazówka: Współczesne urządzenia mogę mieć kilkanaście czujników:\n",
|
||||
" * ruchu\n",
|
||||
" * pozycji\n",
|
||||
" * położenia\n",
|
||||
" * środowiskowe "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Wprowadzanie danych (Input)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Input</h3> \n",
|
||||
"\n",
|
||||
"Information fed into a data processing system or computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Interakcja użytkownik - system\n",
|
||||
"### 2.1.1. Wejście dotykowe\n",
|
||||
" * Czy wziąłeś pod uwagę zalecane minimalne wielkości obszarów dotykowych?\n",
|
||||
" * iOS: 11 mm\n",
|
||||
" * Android: 7-10 mm\n",
|
||||
" * Windows: 7-9 mm\n",
|
||||
"\n",
|
||||
" * Czy gesty obsługiwane są standardowo?\n",
|
||||
" * pojedyncze dotknięcie\n",
|
||||
" * podwójne dotknięcie\n",
|
||||
" * przesunięcie palcem po ekranie\n",
|
||||
" * dotknięcie i przytrzymanie\n",
|
||||
" * uszczypnięcie / rozciąganie\n",
|
||||
" * obracanie\n",
|
||||
" * inne (powstające)\n",
|
||||
" \n",
|
||||
" * Czy pomyślałeś o tym, że podczas dotykania ekranu jego część będzie zasłonięta?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.2. Rysik\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wprowadzania danych za pomocą rysika?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.3. Mysz i klawiatura\n",
|
||||
"\n",
|
||||
" * Czy aplikacja będzie obługiwana myszą i / lub klawiaturą?\n",
|
||||
" * Jeśli myszą, to weź pod uwagę spójność dotyku i uzycia myszy:\n",
|
||||
" * pojedyncze dotknięcie - pojedyncze kliknięcie\n",
|
||||
" * podwójne dotknięcie - podwójne kliknięcie\n",
|
||||
" * prawy przycisk myszy - przytrzymanie\n",
|
||||
" * przesuwanie myszą - przesuwanie palcem\n",
|
||||
" * Jeśli klawiaturą, to weź pod uwagę standardową reakcję klawiszy:\n",
|
||||
" * Tab\n",
|
||||
" * Enter\n",
|
||||
" * Ctrl\n",
|
||||
" * Shift"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.4. Wejście głosowe\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wejścia głosowego?\n",
|
||||
" * Jeśli tak, to weź pod uwagę ograniczenia techniczne systemów rozpoznawania mowy (np. architektura: klient - serwer)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Ułatwienia wprowadzania danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.1. Minimalizacja wysiłku użytkownika\n",
|
||||
" * Czy pomyślałeś o zminimalizowaniu wysiłku użytkownika przy wprowadzaniu danych?\n",
|
||||
" * Wskazówki:\n",
|
||||
" * proponowane wyboru zamiast ręcznego wprowadzania\n",
|
||||
" * skróty (szybki dostęp)\n",
|
||||
" * autosugestie (autouzupełnianie)\n",
|
||||
" * łączenie wprowadzania danych (np. daty przyjazdu / wyjazdu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.2. Optymalizacja formularzy\n",
|
||||
" * Czy w Twojej aplikacji dane są wprowadzane za pomocą formularzy? Jeśli tak, to odpowiedz na następujące pytania:\n",
|
||||
" * Czy dobrze posortowałeś listy wyboru?\n",
|
||||
" * Czy program reaguje już po części wpisanych danych?\n",
|
||||
" * Czy nad polami są ich etykiety?\n",
|
||||
" * Czy program podpowiada format danych?\n",
|
||||
" * Czy zapewniłeś wartości domyślne?\n",
|
||||
" * Czy pomyślałeś o walidacji danych?\n",
|
||||
" * Czy błędy pokazywane są w odpowiednim miejscu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.3. Altenatywne metody wprowadzania danych\n",
|
||||
" * Czy wziąłeś pod uwagę alternatywne metody wejścia?\n",
|
||||
" * wirtualna klawiatura\n",
|
||||
" * pismo ręczne\n",
|
||||
" * optyczne rozpoznawanie znaków\n",
|
||||
" * interaktywne mapy, pozwalające wskazać adres (lokalizację)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.3. Dane z innych źródeł"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Dane z innych źródeł</h3> \n",
|
||||
"\n",
|
||||
"Są to dane niewprowadzone przez użytkownika aplikacji.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.1. Dane z serwisów sieciowych\n",
|
||||
" * W jaki sposób nasza aplikacja może pozyskiwać informacje dane z serwisów sieciowych?\n",
|
||||
" * w formie odpowiedzi na żądanie\n",
|
||||
" * w formie powiadomień (notyfikacji)\n",
|
||||
" * w formie SMS-ów\n",
|
||||
" * Czy pomyślałeś o obsłudze komunikatów o błędach przesłanych z serwisów sieciowych?\n",
|
||||
" * Czy pomyślałeś o przetworzeniu przesłanych komunikatów (np. skróceniu ich, wyekstrahowaniu tego, co najważniejsze)?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.2. Dane z systemu operacyjnego\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane PIM (Personal Information Manager)?\n",
|
||||
" * wyszukiwanie danych teleadresowych\n",
|
||||
" * wyszukiwanie kontaktów\n",
|
||||
" * sprawdzanie poprawności wprowadzanych danych\n",
|
||||
" * korzystanie z osobistego kalendarza\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z systemu plików?\n",
|
||||
" * zdjęcia\n",
|
||||
" * filmy\n",
|
||||
" * teksty"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.3. Dane z innych aplikacji\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z innych aplikacji? \n",
|
||||
" * Jeśli tak, to w jaki sposób dane są współdzielone?\n",
|
||||
" * wspólne dane przechowywane lokalnie\n",
|
||||
" * natywne współdzielenie (wbudowany mechanizm współdzielenia danych)\n",
|
||||
" * formaty plików (typy MIME: Multipurpose Internet Mail Extensions)\n",
|
||||
" * metoda \"kopiuj i wklej\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.4. Dane z czujników\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z czujników? \n",
|
||||
" * Jeśli tak, to czy zadbałeś o to, aby\n",
|
||||
" * zapytać użytkownika o uprawnienia\n",
|
||||
" * wyjaśnić, w jaki sposób aplikacja będzie korzystać z czuujników\n",
|
||||
" * wyjaśnić, do czego dane te są potrzebne\n",
|
||||
" * wspomnieć o kwestiach polityki prywatności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.5. Inne typy wprowadzania danych\n",
|
||||
" * Czy istnieją jeszcze inne metody, w jaki aplikacja może pozyskać dane?\n",
|
||||
" * np. karta z chipem"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Wyprowadzanie danych (wyjście)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Output</h3> \n",
|
||||
"\n",
|
||||
"Information produced by a computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Wyjście wizualne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Zasady projektowania wizualnych komponentów wyprowadzania danych:</h3> \n",
|
||||
" \n",
|
||||
"<ol>\n",
|
||||
"<li> \"Cele użytkownika na pierwszym miejscu.\"\n",
|
||||
"<li> Spełnianie oczekiwań użytkowników\n",
|
||||
"<li> Uwzględnianie rodzaju urządzenia\n",
|
||||
"<li> Przestrzeganie norm i konwencji\n",
|
||||
"</ol>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Wyjście niewizualne\n",
|
||||
" * Czy wziąłeś pod uwagę możliwości wyprowadzania danych w inny sposób niż wizualnie?\n",
|
||||
" * dźwięki i wibracje\n",
|
||||
" * kanały komunikacji dla innych aplikacji\n",
|
||||
" * powiadomienia \"push\"\n",
|
||||
" * poczta elektroniczna\n",
|
||||
" * SMS"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Responsywność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Responsywność</h3> \n",
|
||||
"\n",
|
||||
"Cecha aplikacji, która powoduje, że użytkownicy uważają, że mogą uzyskać swój cel szybko - bez straty czasu.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Responsywność aplikacji to nie to samo co responsive design.**\n",
|
||||
"> Responsive design oznacza, że to co jest wyświetlane w danym momencie w aplikacji, dostosowuje się do zmieniającej się wielkości ekranu. \n",
|
||||
"> Pojęcie responsywności jest dużo szersze: aplikacja powinna reagować nie tylko na wielkość ekranu, lecz na akcje użytkownika i działania aplikacji. Szybkość i sposób, w jaki aplikacja odpowiada, przekłada się na doświadczenia użytkownika."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Dostęp do sieci\n",
|
||||
" * Czy wziąłeś pod uwagę potencjalne problemy z dostępem do sieci:\n",
|
||||
" * szybkość połączenia może się różnić\n",
|
||||
" * koszt połączenia może być zmienny\n",
|
||||
" * połączenie może być niedostępne\n",
|
||||
" * połączenie może być utracone"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 6. Zasoby"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Resource</h3> \n",
|
||||
"\n",
|
||||
"A source of supply, support, or aid, especially one that can be readily drawn upon when needed (www. dictionary.com)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" > A gdy się zasoby skończą, to ich nie będzie.\n",
|
||||
" \n",
|
||||
"Ilość zasobów jest skończona, więc naszym obowiązkiem jest je oszczędzać:\n",
|
||||
"\n",
|
||||
" * Energia\n",
|
||||
" * Pojemność dysku\n",
|
||||
" * Pojemność pamięci\n",
|
||||
" * Zasoby procesora\n",
|
||||
" * Możliwości przesyłu danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
"Użyteczność często rozumiana jest jako synonim łatwości użytkowania aplikacji.\n",
|
||||
"\n",
|
||||
"Zapewnienie, aby aplikacja używana była **łatwo**, nie jest zadaniem banalnym. Wymaga zadania wielu pytań, na które odpowiedzi mogą być zupełnie różne w zależności od typu aplikacji."
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@ -0,0 +1,626 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. Ocena jakości systemu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Czym jest jakość produktu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Toma de Marco</h3> \n",
|
||||
" \n",
|
||||
"Jakość produktu to funkcja tego, jak bardzo zmienia on świat na lepsze.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Geralda Weinberga</h3> \n",
|
||||
" \n",
|
||||
"Jakość to subiektywnie pojmowana wartość.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Josepha Jurana</h3> \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",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Armanda Feigenbauma</h3> \n",
|
||||
" \n",
|
||||
"Jakość to coś, co określa tylko i wyłącznie klient - a nie inżynier, dział marketiingu, czy też kierownictwo.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<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",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Definicja jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
" \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",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Reguła 30</h3> \n",
|
||||
" \n",
|
||||
"Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/LOC vs FP.jpg\" alt=\"Tablica produktywności\" width=500px>\n",
|
||||
"<figcaption> Tablica produktywności. Źródło: Adam Roman, \"Testowanie i jakość oprogramowania\" </figcaption> \n",
|
||||
"</figure>\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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead1.png\" alt=\"Liczby tokenów\" width=300px>\n",
|
||||
"<figcaption> Liczby tokenów. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n",
|
||||
"\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead2.png\" alt=\"wielkość programu\" width=300px>\n",
|
||||
"<figcaption> Objętość programu. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead3.png\" alt=\"metryki złożoności Halsteada\" width=100px>\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"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<table>\n",
|
||||
" <caption> Wartości metryki dostępności </caption>\n",
|
||||
"<tr> \n",
|
||||
" <td> Miara dostępności </td> <td> Czas niedostępności w roku </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,999 </td> <td> 5 minut 20 sekund </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,8</td> <td> 17 godzin 30 minut </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 97,5 </td> <td> 219 godzin </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/korelacja.png\" alt=\"korelacja Pearsona\" width=600px>\n",
|
||||
" <figcaption>źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<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",
|
||||
"> **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
|
||||
}
|
||||
@ -18,7 +18,7 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Czym jest jakość produktu?"
|
||||
"# 1. Czym jest jakość produktu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -41,7 +41,7 @@
|
||||
" \n",
|
||||
"<h3>Definicja wg Geralda Weinberga</h3> \n",
|
||||
" \n",
|
||||
"Jakość to subiektywnie pojmowana wartość dla kogoś.\n",
|
||||
"Jakość to subiektywnie pojmowana wartość.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
@ -86,7 +86,76 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Definicja jakości oprogramowania"
|
||||
"# 2. Definicja jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
" \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",
|
||||
"<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",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -95,9 +164,9 @@
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
"<h3>Reguła 30</h3> \n",
|
||||
" \n",
|
||||
"Jakość oprogramowania to funkcja <b>cech</b> oprogramowania, które spełniają oczekiwania użytkownika: znane i przewidywane.\n",
|
||||
"Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
@ -105,35 +174,412 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jakość kodu źródłowego\n",
|
||||
"### Metryki oceny rozmiaru kodu źródłowego\n",
|
||||
"### Metryki oceny złożoności kodu źródłowego"
|
||||
"> **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": [
|
||||
"## Cechy oprogramowania wpływające na ocenę jakości\n",
|
||||
"### Funkcjonalność\n",
|
||||
"### Niezawodność\n",
|
||||
"### Użyteczność\n",
|
||||
"### Wydajność\n",
|
||||
"### Łatwość konserwacji\n",
|
||||
"### Przenośność\n",
|
||||
"### Dostępność\n",
|
||||
"### Bezpieczeństwo\n",
|
||||
"### Kompatybilność"
|
||||
"### 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",
|
||||
" <img src=\"obrazy/LOC vs FP.jpg\" alt=\"Tablica produktywności\" width=500px>\n",
|
||||
" źródło: Adam Roman, \"Testowanie i jakość oprogramowania\"\n",
|
||||
"\n",
|
||||
"[Porównaj w Internecie](https://www.qsm.com/resources/function-point-languages-table)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Schematy oceny jakości\n",
|
||||
"### CUPRIMDSO\n",
|
||||
"### FURPS\n",
|
||||
"### CUPRIMDA"
|
||||
"### 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",
|
||||
"<img src=\"obrazy/Halstead1.png\" alt=\"Liczby tokenów\" width=300px>\n",
|
||||
"źródło: Wikipedia\n",
|
||||
"\n",
|
||||
"Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/Halstead2.png\" alt=\"wielkość programu\" width=300px>\n",
|
||||
"źrodło: Wikipedia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<img src=\"obrazy/Halstead3.png\" alt=\"metryki złożoności Halsteada\" width=100px>\n",
|
||||
"żródło: Wikipedia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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=200px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<table>\n",
|
||||
"<tr> \n",
|
||||
" <td> Miara dostępności </td> <td> Czas niedostępności w roku </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,999 </td> <td> 5 minut 20 sekund </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,8</td> <td> 17 godzin 30 minut </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 97,5 </td> <td> 219 godzin </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<img src=\"obrazy/korelacja.png\" alt=\"korelacja Pearsona\" width=600px>\n",
|
||||
"źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<img src=\"obrazy/korelacja właściwości.png\" alt=\"Korelacja między właściwościomi oprogramowania\" width=600px>\n",
|
||||
"źródło: opracowanie własne na podstawie: Stephen H. Kan \"Metryki i modele w inżynierii jakości oprogramowania\"\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."
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@ -30,6 +30,20 @@
|
||||
"</ul>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Zasady planowania harmonogramu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Bierz pod uwagę ograniczenia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -45,12 +59,128 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Rodzaje ograniczeń\n",
|
||||
"### Rodzaje ograniczeń:\n",
|
||||
"Wyróżniamy następujace typy ograniczeń:\n",
|
||||
" * Ograniczenia czasowe\n",
|
||||
" * Ograniczenia techniczne\n",
|
||||
" * Ograniczenia organizacyjne "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia czasowe\n",
|
||||
"**Ograniczenie czasowe** to ramy czasowe, w których musi się zmieścić projekt lub jego etap.\n",
|
||||
"\n",
|
||||
"* Rodzaje ograniczeń czasowych:\n",
|
||||
" * Nie wcześniej niż,\n",
|
||||
" * Nie później niż,\n",
|
||||
" * W konkretnym dniu.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń czasowych:\n",
|
||||
" * wykonanie pewnego zadania jest uwarunkowane ukończeniem innego zadania,\n",
|
||||
" * projekt ma być zakończony w określonym terminie.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczaniami czasowymi?\n",
|
||||
" * Ustawiać zależności między zadaniami (patrz ...),\n",
|
||||
" * Ustawiać hamronogram \"od końca\" (czyli od podania czasu zakończenia)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia techniczne\n",
|
||||
"**Ograniczenie techniczne** to ograniczenia wynikające z przyczyn zewnętrznych, niezależnych od zespołu projektowego.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń technicznych:\n",
|
||||
" * termin dostawy sprzętu,\n",
|
||||
" * załamanie pogody,\n",
|
||||
" * pandemia,\n",
|
||||
" * współpraca z podmiotami zewnętrznymi.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczeniami technicznymi?\n",
|
||||
"\n",
|
||||
" * Ustawiać zależność ZR (Zakończenie Rozpoczęcie) dla zadań zależnych od innych przedsiębiorstw (patrz ...),\n",
|
||||
" * Dodawać do zadań odstępy czasowe (patrz ...),\n",
|
||||
" * Dodawać rezerwę kierowniczą (patrz ...)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia organizacyjne\n",
|
||||
"**Ograniczenia organizacyjne** to ograniczenia wynikające z zależności pomiędzy kilkoma projektami realizowanymi:\n",
|
||||
" * w jednym zespole,\n",
|
||||
" * przez daną osobę, \n",
|
||||
" * z wykorzystaniem tych samych zasobów.\n",
|
||||
"\n",
|
||||
" * Wskazówki: ak radzić sobie z ograniczeniami organizacyjnymi?\n",
|
||||
" * Odpowiednio zarządzać zasobami: technicznymi i ludzkimi,\n",
|
||||
" * Współdzielić zasoby między projektami,\n",
|
||||
" * Ustawiać indywidualne czasy pracy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.2. Zarządzaj zapasem czasu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zapas czasu</h3> \n",
|
||||
" \n",
|
||||
"<b> Zapas czasu </b> to czas, o który może opóźnić się realizacja zadania, nie wpływając na termin ukończenia projektu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Ścieżka krytyczna</h3> \n",
|
||||
" \n",
|
||||
"<b> Ścieżka krytyczna </b> to sekwencja zadań od rozpoczęcia do zakończenia projektu, której czas przejścia jest najdłuższy.\n",
|
||||
"\n",
|
||||
"Zadania na ścieżce krytycznej mają zerowy zapas czasu.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ścieżka krytyczna.png\" alt=\"Przykład ścieżki krytycznej\" width=500px>\n",
|
||||
"<figcaption> Przykład ścieżki krytycznej </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Zarządzanie zapasem czasu** może polegać na:\n",
|
||||
" * dodawaniu zapasu czasu do zadań obarczonych ryzykiem,\n",
|
||||
" * dodawaniu zapasu czasu z powodów ograniczeń technicznych lub organizacyjnych, \n",
|
||||
" * zmniejszaniu zapasu czasu (dla zadań leżących poza ścieżką krytyczną),\n",
|
||||
" * analizie (i ew. modyfikacji) zadań leżących na ścieżce krytycznej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Zarządzaj rezerwą kierowniczą\n",
|
||||
"**Rezerwa kierownicza** to fikcyjne zadanie dodane na końcu siatki zadań. Czas na jego realizację to około 10-15% czasu całego projektu.\n",
|
||||
" * Rezerwę kierowniczą dodajemy po stworzeniu całości harmonogramu.\n",
|
||||
" * Tworząc rezerwę pomocniczą, pamiętaj o prawie Parkinsona."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -60,9 +190,21 @@
|
||||
" \n",
|
||||
"Praca będzie się rozrastać, aby wypełnić cały czas na nią przewidziany.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/prawo Parkinsona.png\" alt=\"Prawo Parkinsona\" width=500px>\n",
|
||||
"<figcaption> Prawo Parkinsona, źródło: https://www.timeflies.us/blog/what-is-parkinson-s-law-and-how-it-can-make-you-more-productive</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Struktura podziału pracy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -79,117 +221,485 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Tworzenie harmonogramu projektu w programie MS-Project"
|
||||
" * Wykonanie prac w projekcie podzielone jest na **etapy**. \n",
|
||||
" * Etap jest częścią projektu, która musi być dokończona przed zaczęciem następnej. Etap składa się z **zadań**.\n",
|
||||
" * Zadania mogą być wykonywane równolegle.\n",
|
||||
" * Zadania mogą zostać podzielone na **podzadania**. \n",
|
||||
" \n",
|
||||
" * Elementy Struktury Podziału Pracy a efekty pracy: \n",
|
||||
" * Etap – efekt jest widoczny dla klienta,\n",
|
||||
" * Zadanie – efekt jest widoczny dla kierownika,\n",
|
||||
" * Podzadanie – efekt jest widoczny dla programisty.\n",
|
||||
" \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/SPP.jfif\" alt=\"Struktura Podziału Pracy\" width=600px>\n",
|
||||
"<figcaption> Struktura Podziału Pracy, źródło: http://pm2pm.pl/slownik-project-managera-wbs/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie daty początku projektu"
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h3>Zasada 8 - 80</h3>\n",
|
||||
"Wykonanie najmniejszej jednostki harmonogramu powinno zajmować między 8 a 80 godzin.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie struktury podziału pracy"
|
||||
"# 3. Tworzenie harmonogramu w programie MS-Project"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie trybów zadań"
|
||||
"## 3.1. Ustawienie daty początku projektu\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie daty.png\" alt=\"Ustawienie daty\" width=300px>\n",
|
||||
"<figcaption> Ustawienie daty początku projektu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie kamieni milowych"
|
||||
"### 3.2. Stworzenie Struktury Podziału Pracy\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/stworzenie SPP.png\" alt=\"Stworzenie SPP\" width=300px>\n",
|
||||
"<figcaption> Stworzenie SPP</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie tygodniowego kalendarza czasu pracy dla zespołu"
|
||||
"### 3.3. Ustawienie trybów zadań\n",
|
||||
"\n",
|
||||
"* Tryb ręczny (oznaczony przez pineskę) stosujemy, gdy chcemy mieć pełną kontrolę nad czasem trwania zadania.\n",
|
||||
"* Tryb automatyczny wykonuje ważną jednak pracę wspomagającą - przesuwa na osi czasu zadania, które są od siebie zależne.\n",
|
||||
"\n",
|
||||
"Stosowanie trybu automatycznego oznacza, że brana jest pod uwagę wskazówka: \"Bierz pod uwagę ograniczenia czasowe\". \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/tryby zadań.png\" alt=\"Ustawianie trybów zadań\" width=500px>\n",
|
||||
"<figcaption> Ustawianie trybów zadań</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustalenie zależności między zadaniami"
|
||||
"### 3.4. Określenie punktów kontrolnych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie odstępów między zadaniami"
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Punkt kontrolny</h3> \n",
|
||||
" \n",
|
||||
"<b>Punkt kontrolny</b> (ang. milestone) – punkt na osi czasu, który podsumowuje określony zestaw zadań, bądź daną fazę projektu.\n",
|
||||
"<ul>\n",
|
||||
" <li> Może to być: podpisanie dokumentu, otrzymanie wyniku, ważne spotkanie, zatwierdzenie pracy itp.\n",
|
||||
" <li> Zazwyczaj osiągnięcie punktu kontrolnego wiąże się z dalszymi decyzjami odnośnie rozwoju projektu.\n",
|
||||
" <li> Punkt kontrolny ma zerowy czas trwania.\n",
|
||||
" <li> Pojęcie punktu kontrolnego zastąpiło pojęcie kamienia milowego.\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie zasobów w projekcie: \n",
|
||||
" * Praca (ludzie + komputery), \n",
|
||||
" * Materiały, \n",
|
||||
" * Inne koszty"
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie punktu kontrolnego.png\" alt=\"Ustawianie punktu kontrolnego\" width=900px>\n",
|
||||
"<figcaption> Ustawianie punktu kontrolnego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/punkt kontrolny.png\" alt=\"Punkt kontrolny w MS-Project\" width=500px>\n",
|
||||
"<figcaption> Oznaczenie punktu kontrolnego w MS-Project</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie tygodniowego kalendarza czasu pracy dla zasobów typu \"praca\""
|
||||
"### 3.5. Określenie tygodniowego kalendarza czasu pracy dla zespołu\n",
|
||||
"\n",
|
||||
"Tygodniowy plan pracy dla zespołu obowiązuje tych członków zespołu, dla których nie określono planu indywidualnego. \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 1.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - przycisk</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 2.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - kalendarz</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przydzielenie zasobów do zadań"
|
||||
"### 3.6. Modyfikacja diagramu Gantta"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Sprawdzenie poprawności alokacji zasobów"
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Diagram Gantta</h3> \n",
|
||||
" \n",
|
||||
"<b> Diagram Gantta </b> to graficzny sposób reprezentacji harmonogramu, w którym uwzględnia się podział projektu na \n",
|
||||
"poszczególne zadania, oraz rozplanowanie ich w czasie.\n",
|
||||
"\n",
|
||||
"<br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/diagram Gantta.png\" alt=\"diagram Gantta\" width=500px>\n",
|
||||
"<figcaption> Przykładowy diagram Gantta, źródło: https://kierownikprojektu.com/2020/06/11/16-zalet-wykresu-gantta/ </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<h4> Zalety wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> przedstawia następstwo zdarzeń, </li>\n",
|
||||
"<li> uwzględnia zadania wykonywane równolegle, </li>\n",
|
||||
"<li> dobrze sprawdza się dla niewielkich projektów. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h4> Wady wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> nie zawiera szczegółowych opisów zadań, </li>\n",
|
||||
"<li> wymusza podanie konkretnych dat, </li>\n",
|
||||
"<li> nie pokazuje najkrótszej drogi do ukończenia prac. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wyeliminowanie przeciążeń zasobów\n",
|
||||
" * manualne bilansowanie zasobów\n",
|
||||
" * automatyczne bilansowanie zasobów"
|
||||
"#### Diagram Gantta w MS-Project\n",
|
||||
"\n",
|
||||
"Diagram Gantta tworzony jest częściowo manualne, a częściowo automatycznie.\n",
|
||||
"\n",
|
||||
" * Czas trwania zadania można wpisać ręcznie w kolumnie **czas trwania** (w godzinach, dniach).\n",
|
||||
" * W czasie trwania zadania uwzględniane są tylko dni robocze – zgodnie z kalendarzem.\n",
|
||||
" * Jeśli wpiszemy czasy rozpoczęcia i zakończenia, to czas trwania oblicza się sam. Analogicznie sam oblicza się koniec zadania o znanym rozpoczęciu i czasie trwania.\n",
|
||||
" * Dni wolne od pracy są zaznaczone kolorem szarym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analiza ścieżki krytycznej"
|
||||
"### 3.7. Ustawienie zależności między zadaniami"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Sporządzanie raportów"
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zależności między zadaniami</h3> \n",
|
||||
" \n",
|
||||
"Zadanie B jest <b>zależne</b> od A, gdy zmiana terminu wykonania A wpływa na termin wykonania B. Zadanie A nazywamy <b>poprzednikiem</b>, a B – <b>następnikiem </b>. \n",
|
||||
" \n",
|
||||
"<h4> Typy zależności </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> Zadania typu ZR (zakończenie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RR (rozpoczęcie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po rozpoczęciu poprzednika(A).\n",
|
||||
"<li> Zadania typu ZZ (zakończenie-zakończenie). Następnik (B) może się zakończyć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RZ (rozpoczęcie-zakończenie). Następnik (B) może się zakończyć dopiero po rozpoczęciu poprzednika (A).\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Modyfikacja harmonogramu podczas trwania projektu"
|
||||
"#### Ustawianie zależności między zadaniami w MS-Project\n",
|
||||
"\n",
|
||||
" * Aby określić zadania zależne, należy zaznaczyć dwa zadania i połączyć je (ikoną węzła).\n",
|
||||
" * Aby zmienić typ zależności między zadaniami, należy kliknąć na strzałeczkę łączącą zadania na wykresie Gantta.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zależności.png\" alt=\"Ustawianie zależności między zadaniami\" width=500px>\n",
|
||||
"<figcaption> Ustawianie zależności między zadaniami</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.8. Ustawienie odstępów między zadaniami\n",
|
||||
"Pomiędzy zadaniami zależnymi można ustawić odstęp czasowy (tzw. zwłokę). Pełni on rolę bufora – aby zapewnić zakończenie zadania przed rozpoczęciem następnego.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odstęp czasowy.png\" alt=\"Ustawianie odstępów czasowych\" width=500px>\n",
|
||||
"<figcaption> Ustawianie odstępów czasowych</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.9 Określenie zasobów w projekcie"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zasoby </h3> \n",
|
||||
" \n",
|
||||
"<b>Zasoby (ang. resources) </b> – wszystko, co jest potrzebne do wykonania projektu, a czego brak spowodowałby niewykonanie planu. \n",
|
||||
"W MS-Project wyróżniamy następujące typy zasobów:\n",
|
||||
"<ul>\n",
|
||||
"<li> Praca (ludzie lub komputery)\n",
|
||||
"<li> Materiał (np. energia)\n",
|
||||
"<li> Koszt (np. koszt podróży)\n",
|
||||
"</ul>\n",
|
||||
"</div> "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Zdefiniowanie zasobów w MS-Project\n",
|
||||
"\n",
|
||||
"Prawidłowe określenie wszystkich zasobów niezbędnych w projekcie umożliwia prawidłowe oszacowanie kosztów projektu.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 1.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=400px>\n",
|
||||
"<figcaption> Definiowanie zasobów - arkusz zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 2.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=800px>\n",
|
||||
"<figcaption> Definiowanie zasobów - dane zasobów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 10. Ustawienie tygodniowego kalendarza czasu pracy dla poszczególnych osób (zasobów)\n",
|
||||
"\n",
|
||||
"W programie MS-Project możliwe jest zindywidualizowanie czasu pracy każdej osoby - lub ogólniej - dowolnego zasobu. \n",
|
||||
"\n",
|
||||
"Wykres Gantta reprezentujący harmonogram pracy dostosowuje się do czasu pracy zasobów. Na przykład wykonanie zadania szacowanego na 16 godzin przez osobę, która pracuje 8 godzin w tygodniu, będzie zajmowało dwa tygodnie w harmonogramie.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu.png\" alt=\"Czas pracy zasobu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - wybranie zasobu</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu 2.png\" alt=\"Czas pracy zasobu 2\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - zmiana tygodniowego planu pracy</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 11. Przydzielenie zasobów do zadań\n",
|
||||
"Do kazego zadania powinny być przydzielone zasoby niezbędne do jego wykonania (w tym zasoby ludzkie). \n",
|
||||
"\n",
|
||||
" * Można przydzielić całość lub część zasobu do danego zadania (np. 50%). Będzie to oznaczało, że zasób jest zaangażowany w to zadanie tylko w określonym procencie swojego czasu.\n",
|
||||
" * Do jednego zadania można przydzielić kilka osób.\n",
|
||||
" * Zasób może być jednocześnie przypisany do kilku zadań.\n",
|
||||
" \n",
|
||||
" <br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przydzielanie zasobów.png\" alt=\"Przydzielanie zasobów do zadań\" width=500px>\n",
|
||||
"<figcaption> Przydzielanie zasobów do zadań</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 12. Sprawdzenie poprawności alokacji zasobów\n",
|
||||
"\n",
|
||||
"* Skoro zasób może być jednocześnie przypisany do kilku zadań, to można popełnić błąd, nadmiernie przeciążając zasób, tak że musiałby pracować więcej niż to wynika z jego kalendarza.\n",
|
||||
"\n",
|
||||
" * Obciążenie zasobów można sprawdzić następująco:\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 1.png\" alt=\"Sprawdzenie przeciążenia zasobów\" width=400px>\n",
|
||||
"<figcaption> Sprawdzenie przeciążenia zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 2.png\" alt=\"Zasoby z nadmierną alokacją pracy\" width=800px>\n",
|
||||
"<figcaption> Zasoby z nadmierną alokacją pracy - przykład</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 13. Wyeliminowanie przeciążeń zasobów\n",
|
||||
"\n",
|
||||
"Nadmierną alokację (przeciążenie) zasobów należy eliminować. Można to zrobić na dwa sposoby:\n",
|
||||
" * manualne odciążanie zasobów,\n",
|
||||
" * automatyczne bilansowanie zasobów.\n",
|
||||
" \n",
|
||||
"Manualne odciążanie zasobów może polegać na zmniejszeniu zaangażowania danego zasobu w zadanie:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odciążanie ręczne.png\" alt=\"Odciążanie ręczne\" width=500px>\n",
|
||||
"<figcaption> Zmniejszenie zaangażowania zasobu w zadanie</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Automatyczne bilansowanie zasobu wykonywane jest przez MS-Porject na żądanie użytkownika.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/automatyczne bilansowanie zasobów.png\" alt=\"automatyczne bilansowanie zasobów\" width=500px>\n",
|
||||
"<figcaption>Automatyczne bilansowanie zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Efekt bilansowania może spowodować przesunięcie pracy w czasie, a co za tym idzie, opóźnienie realizacji projektu:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 1.png\" alt=\"obciążenie zasobu przez bilansowaniem\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu przez bilansowaniem</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 2.png\" alt=\"obciążenie zasobu po bilansowaniu\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu po bilansowaniu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 14. Analiza ścieżki krytycznej\n",
|
||||
"\n",
|
||||
"Zadania leżące na ścieżce krytycznej nazywne są **zadaniami krytycznymi**.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zadania krytyczne.png\" alt=\"ścieżka krytyczna\" width=600px>\n",
|
||||
"<figcaption>Wyświetlenie ścieżki krytycznej </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"W wyniku analizy ścieżki krytycznej można przykładowo:\n",
|
||||
" * zmienić zależności między zadaniami na ścieżce krytycznej (może to przyspieszyć realizację planu)\n",
|
||||
" * zwiększyć zapasy czasu dla zadań krytycznych (zwiększając bezpieczeństwo kosztem czasu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 15. Generowanie raportów\n",
|
||||
"MS-Project umożliwia generowanie różnego typu raportów. Umożliwiają one m.in:\n",
|
||||
" * obliczenie kosztów projektu,\n",
|
||||
" * wyznaczenie, jaki procent planu jest wykonany,\n",
|
||||
" * obliczenie zaangażowania poszczególnych osób w projekt,\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport całościowy.png\" alt=\"raport całościowy\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu całościowego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport zasobów.png\" alt=\"raport zasobów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport kosztów.png\" alt=\"raport kosztów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu kosztów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 16. Poprawianie harmonogramu (czyli co robić, gdy harmonogram się „nie spina”)\n",
|
||||
"\n",
|
||||
"Następujące działania mogą pomóc w poprawieniu harmonogramu\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/modyfikacja planu.png\" alt=\"modyfikacja planu\" width=600px>\n",
|
||||
"<figcaption>Metody poprawiania harmonogramu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Wnioski\n",
|
||||
" * Zarządzanie projektem jest procesem zindywidualizowanym\n",
|
||||
" * Gdyby tak nie było, to MS Project składałby się tylko z jednego przycisku "
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@ -451,7 +451,7 @@
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.7.6"
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "06. Prototypowanie i ciągła integracja[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 9. <i>Testowanie systemowe i adaptacyjne</i>[wykład]</h2> \n",
|
||||
"<h2> 9. <i>Testowanie systemowe i akceptacyjne</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
@ -18,7 +18,7 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Testowanie systemowe i adaptacyjne - wyjaśnienie pojęć"
|
||||
"# 1. Testowanie systemowe i akceptacyjne - wyjaśnienie pojęć"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -39,9 +39,9 @@
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie adaptacyjne</h3>\n",
|
||||
"<h3>Testowanie akceptacyjne</h3>\n",
|
||||
" \n",
|
||||
"Przedmiotem <b>testowania adaptacyjnego </b> jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy.\n",
|
||||
"Przedmiotem <b>testowania akceptacyjnego </b> jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy.\n",
|
||||
" * Testowana jest zgodność z wymaganiami i potrzebami użytkownika.\n",
|
||||
" * Testowanie akceptacyjne przeprowadza użytkownik / klient.\n",
|
||||
"</div>"
|
||||
@ -60,7 +60,7 @@
|
||||
"source": [
|
||||
"## 2.1. Testowanie funkcjonalne (functional testing)\n",
|
||||
"**Testowanie funkcjonalne** ma na celu wykazanie rozbieżności między programem a jego specyfikacją zapisaną w postaci wymagań funkcjonalnych lub przypadków użycia.\n",
|
||||
" * Przypadki testowe (scenariusze testowe) wielokrotnie tworzy się na podstawie przypadków użycia.\n",
|
||||
" * Przypadki testowe (scenariusze testowe) często tworzy się na podstawie przypadków użycia.\n",
|
||||
" * Podstawowa zasada:Im więcej błędów wykryto w pewnej funkcji programu, tym (prawdopodobnie) większą liczbę błędów ona jeszcze ukrywa.\n",
|
||||
" * Testowanie funkcjonalne może odbywać się na różnych poziomach szczegółowości:\n",
|
||||
" * testy dymne\n",
|
||||
@ -76,7 +76,7 @@
|
||||
"**Testy dymne** (ang. smoke tests) to powierzchowne testy pozwalające wykazać błędy krytyczne,\n",
|
||||
" * Przykładem testu dymnego może być test CRUD (Create, Read, Update, Delete).\n",
|
||||
" \n",
|
||||
"**Przykład opisu testów dymnych:**\n",
|
||||
"**Przykład opisu testów dymnych (system automatycznego tłumaczenia dokumentów):**\n",
|
||||
"<img src=\"obrazy/testy dymne.png\" alt=\"Przykład testów dymnych\" width=400px>"
|
||||
]
|
||||
},
|
||||
@ -85,10 +85,10 @@
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy zdroworozsądkowe\n",
|
||||
"**Testy zdroworozsądkowe** mają wykazać, że aplikacja nie działa zgodnie ze stawianymi przed nią wymaganiami.\n",
|
||||
"**Testy zdroworozsądkowe** (ang. sanity tests) mają wykazać, że aplikacja nie działa zgodnie ze stawianymi przed nią wymaganiami.\n",
|
||||
">\"Smoke test określa, czy w ogóle coś działa, a sanity test - czy działa tak, jak ma działać”.\n",
|
||||
"\n",
|
||||
"**Przykład przypadków testowych na poziomie testowania regresywnego:**\n",
|
||||
"**Przykład przypadków testowych na poziomie testowania zdroworozsądkowego:**\n",
|
||||
"<img src=\"obrazy/sanity test.png\" alt=\"Przykład testów zdroworozsądkowych\" width=900px>"
|
||||
]
|
||||
},
|
||||
@ -100,7 +100,7 @@
|
||||
"**Testy regresywne** to szczegółowe testy, pozwalające wykazać, że w aplikacji powstały nieznane błędów będące wynikiem wprowadzonych zmian.\n",
|
||||
"\n",
|
||||
"**Przykład przypadku testowego na poziomie testowania regresywnego:**\n",
|
||||
"<img src=\"obrazy/testy regresywne.png\" alt=\"Przykład testów regresywnych\" width=900px>"
|
||||
"<img src=\"obrazy/testy regresywne.png\" alt=\"Przykład testów regresywnych\" width=700px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -133,15 +133,34 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.3. Testowanie przeciążeń (load testing)\n",
|
||||
"**Przeciążenie** to skumulowanie w krótkim czasie dużej liczby jednocześnie działających użytkowników lub przeprowadzanych transakcji. \n",
|
||||
"\n",
|
||||
"## 2.3. Testowanie przeciążeń (load testing)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Przeciążenie</h3>\n",
|
||||
" \n",
|
||||
"Przeciążenie to skumulowanie w krótkim czasie dużej liczby jednocześnie działających użytkowników lub przeprowadzanych transakcji. \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Celem **testowania przeciążeń** jest zweryfikowania działania systemu przy wysokim obciążeniu.\n",
|
||||
" * Przykładowy scenariusz testowania przeciążeń:\n",
|
||||
" * Nagranie ciągu operacji wykonywanych przez jednego klienta (np. \u000b",
|
||||
"w postaci makra)\n",
|
||||
" * Odtworzenie nagranego ciągu operacji dla wybranej (dużej) liczby klientów\n",
|
||||
" * Analiza raportu\n",
|
||||
" * Analiza raportu \n",
|
||||
"\n",
|
||||
" * Lista narzędzi do testowania przeciążeń: \n",
|
||||
"https://testerzy.pl/baza-wiedzy/narzedzia/10-najlepszych-narzedzi-do-testow-wydajnosci\n",
|
||||
"\n",
|
||||
"**Przykład raportu tekstowego z testu przeciążeń systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/load test - raport tekstowy.png\" alt=\"Przykład raportu z testowania\" width=800px>\n",
|
||||
@ -188,7 +207,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -199,7 +217,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -208,7 +225,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -220,12 +236,11 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Testowanie akceptacyjne\n",
|
||||
"## Cele testowania akcpetacyjnego\n",
|
||||
"## Cele testowania akceptacyjnego\n",
|
||||
" * Sprawdzenie kompletności systemu i jego prawidłowego działania;\n",
|
||||
" * Sprawdzanie zgodności zachowania funkcjonalnego i niefunkcjonalnego systemu ze specyfikacją;\n",
|
||||
" * Spełnienie wymagań wynikających z obowiązujących przepisów prawa lub norm/standardów;\n",
|
||||
@ -250,7 +265,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -262,7 +276,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -279,11 +292,10 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.3. Testowanie akceptacyjne zgodności z umową i zgodności z przepisami prawa!\n",
|
||||
"## 3.3. Testowanie akceptacyjne zgodności z umową i zgodności z przepisami prawa\n",
|
||||
"**Testowanie zgodności z umową** to weryfikowanie zgodności działania z kryteriami akceptacji zapisanymi w umowie. \n",
|
||||
"\n",
|
||||
"**Testowanie zgodności z przepisami prawa** sprawdza zgodność działania z ustawami, rozporządzeniami czy normami bezpieczeństwa. \n",
|
||||
@ -291,20 +303,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.4. Testy alfa i testy beta\n",
|
||||
"**Testowanie alfa** jest wykonywane w siedzibie wykonawcy.\n",
|
||||
" * Wykonują je potencjalni lub obecni klienci, i/lub operatorzy bądź niezależni testerzy. \n",
|
||||
" \n",
|
||||
"**Testowanie beta** wykonują obecni lub potencjalni klienci we własnych lokalizacjach. \n",
|
||||
" * Celem może być wykrywanie błędów związanych z warunkami i środowiskiem (środowiskami), w których system będzie używany."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -316,7 +314,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -351,7 +348,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -366,7 +362,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -377,7 +372,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -395,7 +389,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -412,7 +405,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -421,7 +413,6 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
@ -432,13 +423,6 @@
|
||||
" * ale oszczędza czas samego procesu testowania.\n",
|
||||
" * Niezależnie od typu testowania, jest to czynność, którą należy starannie zaplanować."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
@ -14,6 +14,13 @@
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Pojęcie użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -22,7 +29,7 @@
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \n",
|
||||
"\n",
|
||||
"Użyteczność narzędzia: łatwość, z jaką ludzie potrafią korzystać z pewnego narzędzia w celu osiągnięcia określonego celu.\n",
|
||||
"Użyteczność narzędzia: łatwość, z jaką ludzie potrafią korzystać z tego narzędzia w celu osiągnięcia określonego celu.\n",
|
||||
"\n",
|
||||
"<h3> Cechy aplikacji użytecznej </h3>\n",
|
||||
" \n",
|
||||
@ -36,6 +43,63 @@
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Wskazówki do tworzenia użytecznej aplikacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Klasyka w oparciu o \"Don't make me think\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<a href=\"https://www.uxbooth.com/articles/10-usability-lessons-from-steve-krugs-dont-make-me-think/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"<ol> \n",
|
||||
" \n",
|
||||
"<li> Usability Means… </li>\n",
|
||||
"\n",
|
||||
"<li>Web applications should explain themselves. </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t Make Me Think </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t waste my time </li>\n",
|
||||
" \n",
|
||||
"<li> Users still cling to their back buttons </li>\n",
|
||||
"\n",
|
||||
"<li> We’re creatures of habit </li>\n",
|
||||
"\n",
|
||||
"<li> No Time for Small Talk </li>\n",
|
||||
"\n",
|
||||
"<li> Don’t lose search </li>\n",
|
||||
"\n",
|
||||
"<li> We form mental site-maps </li>\n",
|
||||
"\n",
|
||||
"<li> Make it easy to go home </li>\n",
|
||||
" \n",
|
||||
"</ol>\n",
|
||||
"\n",
|
||||
"<div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Podejście (bardziej) współczesne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
@ -74,16 +138,413 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Użyteczność portali internetowych\n",
|
||||
"### 10 heurystyk Jakoba Nielsena i Rolfa Molicha\n",
|
||||
"### Zasady dobrej nawigacji"
|
||||
"## 3. Zasady dobrej nawigacji na portalu internetowym\n",
|
||||
"### 3.1. Pojęcie nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<b> Nawigacja </b> to stały, niezmieniający się zestaw elementów w serwisie ułatwiający poruszanie się na niej.\n",
|
||||
" \n",
|
||||
"Najczęściej stosowanymi elementami nawigacji są: \n",
|
||||
"<ul>\n",
|
||||
"<li> Menu główne </li>\n",
|
||||
"<li> Menu narzędziowe </li>\n",
|
||||
"<li> Identyfikator witryny </li>\n",
|
||||
"<li> Wyszukiwarka </li>\n",
|
||||
"<li> Odsyłacz do strony startowej (zawarty w logo) </li>\n",
|
||||
"<li> Flagi narodowe (przełączenie języków) </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Tworzenie raportu użyteczności"
|
||||
"## 3.2. Cechy dobrej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Szybkie przechodzenie po różnych elementach serwisu.\n",
|
||||
" * Łatwe prowadzenie użytkownika do poszukiwanej informacji. \n",
|
||||
" * Klarowność: użytkownik wie gdzie jest, gdzie może się skierować, jak wrócić, a także posiada informacje o odwiedzonych miejscach. \n",
|
||||
" * Oszczędność: główne menu witryny nie powinno zawierać zbyt wielu elementów (między 5 a 9)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.3. Zasady użytecznej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 1. Widoczność\n",
|
||||
"Wszystkie elementy nawigacji muszą być bardzo dobrze widoczne na każdej stronie i podstronie serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 2. Przewidywalność\n",
|
||||
" * Nazwy elementów menu powinny pozwalać na przewidzenie zawartości\n",
|
||||
" * Elementy menu powinny informować użytkownika o całej zawartości witryny.\n",
|
||||
" * Odwiedzone linki powinny być oznaczone innym kolorem niż nieodwiedzone. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 3. Łatwość orientacji w strukturze serwisu\n",
|
||||
"* Powinno się stosować różne style wyróżnienia jego elementów:\n",
|
||||
" * dla całej kategorii, na której aktualnie znajduje się kursor (np. Aktualności),\n",
|
||||
" * dla pozycji w menu, z której aktualnie korzysta użytkownik (np. Publikacje zagraniczne),\n",
|
||||
" * dla pozostałych elementów serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 4. Zasada odwróconej piramidy\n",
|
||||
" * Na najwyższym poziomie należy umieścić kategorie najbardziej ogólne, a następnie przechodzić do podziału bardziej szczegółowego. \n",
|
||||
" * Na tym samym poziomie powinny znajdować się kategorie o tym samym stopniu szczegółowości."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 5. Właściwe nazewnictwo\n",
|
||||
" * Wykluczający podział etykiet menu: \n",
|
||||
" * dana pozycja w menu może należeć tylko do jednej kategorii.\n",
|
||||
" * Proste nazewnictwo: \n",
|
||||
" * etykiety powinno formułować się w języku zrozumiałym dla użytkownika,\n",
|
||||
" * powinno unikać się specjalistycznego słownictwa.\n",
|
||||
" * Unikalne nazwy: \n",
|
||||
" * dana nazwa powinna pojawiać się w serwisie internetowym nie więcej niż raz,\n",
|
||||
" * każda strona powinna mieć swoja nazwę.\n",
|
||||
" * Nazwa strony musi być dobrze widoczna:\n",
|
||||
" * nazwa strony musi być w dobrze umiejscowiona i wyróżniona za pomocą rozmiaru i koloru czcionki.\n",
|
||||
" * Nazwa strony lub podstrony musi być zgodna z nazwą odsyłacza, który do niej prowadzi."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 6. Spójność w wyglądzie i działaniu elementów nawigacyjnych\n",
|
||||
"* Należy stosować te same konwencje w obrębie całego menu. \n",
|
||||
"* Elementy pierwszego poziomu powinny pozostawać niezmienne w trakcie korzystania z całego serwisu internetowego. \n",
|
||||
"* Wszystkie pozycje w menu powinny funkcjonować na tej samej zasadzie. \n",
|
||||
"* Przy formułowaniu nazw w menu należy w każdym przypadku stosować tę samą formę gramatyczną.\n",
|
||||
"* Pozycje menu należące do jednego poziomu powinny być sformatowane w jednym stylu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Automatyczne metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Badanie współczynnika konwersji\n",
|
||||
"**Współczynnik konwersji** wskazuje, jaka część internautów odwiedzających daną stronę dokonała pożądanej akcji np.\n",
|
||||
" * Dokonała zakupu\n",
|
||||
" * Wypełniła formularz\n",
|
||||
" * Wysłała maila na wskazany adres\n",
|
||||
" * Zarejestrowała się do systemu\n",
|
||||
" * Pobrała software"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy A/B (testy porównawcze)\n",
|
||||
"* Metoda polega na porównaniu dwóch wersji tej samej aplikacji.\n",
|
||||
"* Najczęściej stosowana jest do stron internetowych.\n",
|
||||
"* Różnicę (postęp lub regres) między wersjami wyznacza się poprzez porównanie wartości pewnej miary, np. współczynnika konwersji dla stron internetowych. \n",
|
||||
"\n",
|
||||
"[Przeczytaj w Internecie](https://www.optimizely.com/ab-testing/)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analityka ruchu na portalu internetowym\n",
|
||||
"Metoda polega na obserwacji dotyczących ruchu na witrynie, takich jak:\n",
|
||||
" * Wskaźnik odrzuceń – procentowa wartość osób, które opuściły stronę wejściową serwisu bez wykonania żadnej akcji\n",
|
||||
" * Wskaźnik porzuceń – wskaźnik analogiczny dla podstron danego serwisu,\n",
|
||||
"Metoda wskazuje działania użytkownika – nie wskazuje jego przyczyn. \n",
|
||||
"\n",
|
||||
"Przykładowa witryna: \n",
|
||||
"https://www.google.com/analytics/"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Click-tracking\n",
|
||||
"\n",
|
||||
"Metoda dostarcza informacji o poszczególnych elementach strony za pomocą następujących typów informacji\n",
|
||||
" * Heat maps. \n",
|
||||
" * Wskazują, w jakie miejsca na stronie ludzie klikają (see what’s hot and what’s not).\n",
|
||||
" * Confetti\n",
|
||||
" * Analiza kliknięć: jak klikały poszczególne grupy użytkowników i w poszukiwaniu czego.\n",
|
||||
" * Scrollmap\n",
|
||||
" * Analiza, jak daleko w dół strony użytkownicy przewijają stronę – pozwala przeanalizować miejsca, w których strona jest najczęściej porzucana.\n",
|
||||
" * Overlay report\n",
|
||||
" * Liczba kliknięć na poszczególne elementy strony.\n",
|
||||
"\n",
|
||||
"Przykładowy dostawca: \n",
|
||||
"http://www.crazyegg.com"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analiza kontrastu\n",
|
||||
"\n",
|
||||
"Dostarcza informacji o kontraście pomiędzy elementami strony, co jest szczególnie istotne dla osób z upośledzeniem wzroku.\n",
|
||||
"\n",
|
||||
"* Przykładowy adres\n",
|
||||
" * https://webaim.org/resources/contrastchecker/\n",
|
||||
" * Można wpisać adres strony, która ma zostać przeanalizowana pod względem kontrastu – otrzymuje się pełen raport."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Metody z udziałem użytkowników\n",
|
||||
"\n",
|
||||
"W metodach z udziałem użytkowników można posłużyć się zastosowaniem *persony*, w celu optymalizacji kosztów badania.\n",
|
||||
" * **Persona** to fikcyjna postać stworzona by reprezentować typy użytkowników (demograficzne i technograficzne).\n",
|
||||
" * Persony to inaczej archetypy grup użytkowników i ich potrzeb. Dzięki personom cała populacja docelowa reprezentowana jest przez kilka konceptów.\n",
|
||||
" > Przykład persony: Jan Kowalski, lat 37, elektryk, mieszkaniec Ząbkowic Śląskich\n",
|
||||
" \n",
|
||||
" Przykładowy proces testowania użyteczności z udziałem użytkowników:\n",
|
||||
" 1. Określ grupy użytkowników np. przy użyciu persony (co najmniej jedna persona na grupę).\n",
|
||||
" 2. Dla każdej persony utwórz potencjalny scenariusz użycia – w jaki sposób dana persona chce korzystać z systemu.\n",
|
||||
" 3. Dla każdej persony zorganizuj użytkowników reprezentatywnych (minimum jednego użytkownika dla persony).\n",
|
||||
" 4. Poproś ich o wykonanie zadań charakterystycznych dla danej persony.\n",
|
||||
" 5. Obserwuj lub nagrywaj działania użytkowników: gdzie im się powodzi, a gdzie mają trudności.\n",
|
||||
" 6. Potencjalnie poproś użytkowników o wypełnienie ankiet.\n",
|
||||
"\n",
|
||||
"Wyróżniamy następujące typy metod z udziałem użytkowników:\n",
|
||||
" * podgląd sesji użytkowników.\n",
|
||||
" * obserwacja użytkownika,\n",
|
||||
" * metoda wywiadu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Podgląd sesji użytkowników\n",
|
||||
"* Działalność użytkownika jest „nagrywana”.\n",
|
||||
"* Autor oprogramowania może odtworzyć działania użytkownika z perspektywy użytkownika.\n",
|
||||
"* Każde kliknięcie, poruszenie myszą, przesunięcie kursora zostaje zapisane."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Obserwacja użytkownika\n",
|
||||
"* Działalność użytkownika jest obserwowana.\n",
|
||||
"* Obserwator zapisuje poczynania użytkownika.\n",
|
||||
"* Obserwacje są analizowane w celu ulepszenia użyteczności aplikacji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Metoda wywiadu\n",
|
||||
" * Sposoby przeprowadzenia wywiadu:\n",
|
||||
" * Analiza celów użytkowników i wykonywania przez nich zadań,\n",
|
||||
" * Dyskusja prowadzona przez moderatora,\n",
|
||||
" * Wypełnienie ankiet / kwestionariuszy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Raport badania użyteczności\n",
|
||||
"Raport badania użyteczności to sprawozdanie z badania użyteczności aplikacji, w którym wskazuje się **obszary problemowe**.\n",
|
||||
"Przykładowo raport użytecznści może składać się z następujących części:\n",
|
||||
"1. Informacje wstępne\n",
|
||||
"2. Metodologia badania\n",
|
||||
"3. Obszary problemowe\n",
|
||||
"4. Dodatki"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.1. Informacje wstępne\n",
|
||||
"Ta część zawiera ogólne informacje o prowadzonym badaniu, np. :\n",
|
||||
" * Daty tworzenia raportu\n",
|
||||
" * Harmonogram prowadzenia badań\n",
|
||||
" * Odwołanie do standardów badania użyteczności\n",
|
||||
" * Autorzy raportu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.2. Metodologia badania\n",
|
||||
"Opis tej części zależy od przejętej metody badania. Przykładowo, dla metody wywiadu część ta może mieć następującą postać:\n",
|
||||
"\n",
|
||||
"### 5.2.1. Zakres badania\n",
|
||||
" * Określenie zakresu projektowego: badanie gotowego produktu, czy ocena prototypu,\n",
|
||||
" * Określenie celu, np., wskazanie wyłącznie błędów w systemie, czy również wskazanie proponowanych ulepszeń,\n",
|
||||
" * Określenie zastosowanej metody badania użyteczności.\n",
|
||||
"\n",
|
||||
"### 5.2.2. Profile użytkowników\n",
|
||||
" * Określenie kilku segmentów odbiorców pod względem:\n",
|
||||
" * Danych demograficznych\n",
|
||||
" * Doświadczenia z programami podobnymi (wcześniejszymi wersjami systemu)\n",
|
||||
" * Oczekiwań względem systemu\n",
|
||||
"\n",
|
||||
"### 5.2.3. Grupa badawcza\n",
|
||||
" * Określenie liczebności grupy badawczej (około 5 osób)\n",
|
||||
" * Określenie charakterystyki grupy badawczej pod względem różnych kryteriów , np.\n",
|
||||
" * płeć, \n",
|
||||
" * wiek, \n",
|
||||
" * miejsce zamieszkania, \n",
|
||||
" * wykształcenie, \n",
|
||||
" * zawód, \n",
|
||||
" * wielkość firmy, \n",
|
||||
" * branża, \n",
|
||||
" * obsługa komputera, \n",
|
||||
" * doświadczenie z podobnymi programami, itp.\n",
|
||||
" * Liczebność i charakterystykę grupy badawczej można zobrazować za pomocą wykresów.\n",
|
||||
"\n",
|
||||
"### 5.2.4. Scenariusz badania\n",
|
||||
"W tej części należy opisać, jak będzie przebiegać scenariusz badania.\n",
|
||||
"Przykładowy scenariusz badania w metodzie wywiadu:\n",
|
||||
"1. Omówienie zadań i sposobu wypełniania kwestionariusza\n",
|
||||
"2. Podanie informacji o regulaminie przeprowadzenia testu wykonania zadań\n",
|
||||
"3. Test wykonania zadań\n",
|
||||
"4. Wypełnienie przygotowanego kwestionariusza przez użytkowników\n",
|
||||
"\n",
|
||||
"### 5.2.5. Lista zadań do wykonania przez użytkowników\n",
|
||||
"W tej częścI dla każdego zadania należy podać kryterium pomyślnego ukończenia zadania. Lista zadań może być podana w postaci tabelki:\n",
|
||||
" * Opis zadania\n",
|
||||
" * Kryterium ukończenia zadania\n",
|
||||
"\n",
|
||||
"### 5.2.6. Ocena wykonania zadań \n",
|
||||
"W tej części należy ocenić, jak badani wykonali zadania.\n",
|
||||
"Przykładowa ocena wykonania zadań:\n",
|
||||
" * Liczba błędów krytycznych użytkownika\n",
|
||||
" * Liczba błędów niekrytycznych użytkownika\n",
|
||||
" * Liczba zadań wykonanych zgodnie z założeniami\n",
|
||||
" * Liczba zdań niewykonanych zgodnie z założeniami\n",
|
||||
" * Czas wykonania zadań\n",
|
||||
"\n",
|
||||
"Ten etap raportu można zakończyć wykresami."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.3. Obszary problemowe\n",
|
||||
"Obszary problemowe to **wnioski** z badania użyteczności.\n",
|
||||
" * W tej częśći raportu określone zostają obszary problemowe (składowe systemu, które sprawiają kłopoty).\n",
|
||||
" * Dla każdego obszaru problemowego określa się zestaw problemów użytkowania.\n",
|
||||
" * Problem użytkowania składa się z:\n",
|
||||
" * Tytułu problemu,\n",
|
||||
" * Opisu problemu,\n",
|
||||
" * Jeśli problemem jest zbyt długi czas wykonania zadania, to można podać średnie czasy rozwiązania,\n",
|
||||
" * Filmiku wideo (jeśli takim dysponujemy),\n",
|
||||
" * Rekomendacji rozwiązania problemu,\n",
|
||||
" * Opisu proponowanego scenariusza działania użytkownika po rozwiązaniu problemu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.4. Dodatki\n",
|
||||
"W tej części raportu składamy materiały pomocnicze, np.\n",
|
||||
" ### 5.4.1. Ankieta\n",
|
||||
"\n",
|
||||
"W ankiecie mogą znaleźć się przykładowe pytania:\n",
|
||||
" * Jak ocenia Pan/Pani trudność poszczególnych zadań?\n",
|
||||
" * Co sprawiło Panu/Pani największy problem podczas testów?\n",
|
||||
" * Jakie inne funkcjonalności byłyby pożyteczne (wskazać listę do wyboru)?\n",
|
||||
" * Jakie elementy systemu były niezrozumiałe?\n",
|
||||
"\n",
|
||||
" Wyniki ankiety potestowej możemy przedstawić na wykresach.\n",
|
||||
" \n",
|
||||
"### 5.4.2. Inne materiały pomocnicze\n",
|
||||
"Przykładowe materiały pomocnicze:\n",
|
||||
" * Lista filmów video ilustrujących błędy użyteczności aplikacji,\n",
|
||||
" * Wnioski i rekomendacje ekspertów użyteczności,\n",
|
||||
" * Inne materiały w zależności od zastosowanej metody badawczej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie wykładu\n",
|
||||
"1. Tworząc aplikację, myśl przede wszystkim o jej użyteczności, a potem dopiero o jej funkcjonalności.\n",
|
||||
"2. O sukcesie aplikacji stanowi pomysł, a nie wielość funkcji.\n",
|
||||
"3. Zawsze (!) pamiętaj o wskazówkach użyteczności.\n",
|
||||
"4. Tworząc portal internetowy, stosuj zasady dobrej nawigacji.\n",
|
||||
"5. Przekonaj się, jak Twój program jest używany – wykonaj badanie użyteczności."
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@ -1,101 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. <i>Aspekty użyteczności</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Aspekty użyteczności\n",
|
||||
"Użyteczność aplikacji powinna być analizowana pod kątem sześciu aspektów:\n",
|
||||
"* kontekst, \n",
|
||||
"* wprowadzanie danych, \n",
|
||||
"* wyprowadzanie danych, \n",
|
||||
"* responsywność, \n",
|
||||
"* łączność z siecią, \n",
|
||||
"* zasoby."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Kontekst"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Wprowadzanie danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Wyprowadzanie danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Responsywność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Łączność z siecią"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zasoby"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "11. Aspekty użyteczności[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
626
materiały na PPB (wykład)/11_ocena_jakości_systemu.ipynb
Normal file
626
materiały na PPB (wykład)/11_ocena_jakości_systemu.ipynb
Normal file
@ -0,0 +1,626 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. Ocena jakości systemu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Czym jest jakość produktu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Toma de Marco</h3> \n",
|
||||
" \n",
|
||||
"Jakość produktu to funkcja tego, jak bardzo zmienia on świat na lepsze.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Geralda Weinberga</h3> \n",
|
||||
" \n",
|
||||
"Jakość to subiektywnie pojmowana wartość.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Josepha Jurana</h3> \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",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Armanda Feigenbauma</h3> \n",
|
||||
" \n",
|
||||
"Jakość to coś, co określa tylko i wyłącznie klient - a nie inżynier, dział marketiingu, czy też kierownictwo.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<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",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Definicja jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
" \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",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Reguła 30</h3> \n",
|
||||
" \n",
|
||||
"Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/LOC vs FP.jpg\" alt=\"Tablica produktywności\" width=500px>\n",
|
||||
"<figcaption> Tablica produktywności. Źródło: Adam Roman, \"Testowanie i jakość oprogramowania\" </figcaption> \n",
|
||||
"</figure>\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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead1.png\" alt=\"Liczby tokenów\" width=300px>\n",
|
||||
"<figcaption> Liczby tokenów. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n",
|
||||
"\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead2.png\" alt=\"wielkość programu\" width=300px>\n",
|
||||
"<figcaption> Objętość programu. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead3.png\" alt=\"metryki złożoności Halsteada\" width=100px>\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"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<table>\n",
|
||||
" <caption> Wartości metryki dostępności </caption>\n",
|
||||
"<tr> \n",
|
||||
" <td> Miara dostępności </td> <td> Czas niedostępności w roku </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,999 </td> <td> 5 minut 20 sekund </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,8</td> <td> 17 godzin 30 minut </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 97,5 </td> <td> 219 godzin </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/korelacja.png\" alt=\"korelacja Pearsona\" width=600px>\n",
|
||||
" <figcaption>źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"<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",
|
||||
"> **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
|
||||
}
|
||||
@ -1,167 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 12. Ocena jakości systemu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Czym jest jakość produktu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Toma de Marco</h3> \n",
|
||||
" \n",
|
||||
"Jakość produktu to funkcja tego, jak bardzo zmienia on świat na lepsze.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Geralda Weinberga</h3> \n",
|
||||
" \n",
|
||||
"Jakość to subiektywnie pojmowana wartość dla kogoś.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Josepha Jurana</h3> \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",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Armanda Feigenbauma</h3> \n",
|
||||
" \n",
|
||||
"Jakość to coś, co określa tylko i wyłącznie klient - a nie inżynier, dział marketiingu, czy też kierownictwo.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<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",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Definicja jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
" \n",
|
||||
"Jakość oprogramowania to funkcja <b>cech</b> oprogramowania, które spełniają oczekiwania użytkownika: znane i przewidywane.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jakość kodu źródłowego\n",
|
||||
"### Metryki oceny rozmiaru kodu źródłowego\n",
|
||||
"### Metryki oceny złożoności kodu źródłowego"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cechy oprogramowania wpływające na ocenę jakości\n",
|
||||
"### Funkcjonalność\n",
|
||||
"### Niezawodność\n",
|
||||
"### Użyteczność\n",
|
||||
"### Wydajność\n",
|
||||
"### Łatwość konserwacji\n",
|
||||
"### Przenośność\n",
|
||||
"### Dostępność\n",
|
||||
"### Bezpieczeństwo\n",
|
||||
"### Kompatybilność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Schematy oceny jakości\n",
|
||||
"### CUPRIMDSO\n",
|
||||
"### FURPS\n",
|
||||
"### CUPRIMDA"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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
|
||||
}
|
||||
@ -0,0 +1,739 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 13. <i>Planowanie prac badawczo-rozwojowych</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Harmonogram projektu</h3> \n",
|
||||
" \n",
|
||||
"Harmonogram projektu to plan uzyskania celów projektu uwzględniający:\n",
|
||||
"<ul>\n",
|
||||
" <li> podział pracy na etapy i zadania,</li>\n",
|
||||
" <li> przydział zasobów do zadań,</li>\n",
|
||||
" <li> terminy wykonania zadań.</li>\n",
|
||||
"</ul>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Zasady planowania harmonogramu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Bierz pod uwagę ograniczenia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Ograniczenia</h3> \n",
|
||||
" \n",
|
||||
"Ograniczenia to czynniki, które wpływają na realizację harmonogramu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Rodzaje ograniczeń:\n",
|
||||
"Wyróżniamy następujace typy ograniczeń:\n",
|
||||
" * Ograniczenia czasowe\n",
|
||||
" * Ograniczenia techniczne\n",
|
||||
" * Ograniczenia organizacyjne "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia czasowe\n",
|
||||
"**Ograniczenie czasowe** to ramy czasowe, w których musi się zmieścić projekt lub jego etap.\n",
|
||||
"\n",
|
||||
"* Rodzaje ograniczeń czasowych:\n",
|
||||
" * Nie wcześniej niż,\n",
|
||||
" * Nie później niż,\n",
|
||||
" * W konkretnym dniu.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń czasowych:\n",
|
||||
" * wykonanie pewnego zadania jest uwarunkowane ukończeniem innego zadania,\n",
|
||||
" * projekt ma być zakończony w określonym terminie.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczaniami czasowymi?\n",
|
||||
" * Ustawiać zależności między zadaniami\n",
|
||||
" * Ustawiać hamronogram \"od końca\"."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia techniczne\n",
|
||||
"**Ograniczenie techniczne** to ograniczenia wynikające z przyczyn zewnętrznych, niezależnych od zespołu projektowego.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń technicznych:\n",
|
||||
" * termin dostawy sprzętu,\n",
|
||||
" * załamanie pogody,\n",
|
||||
" * pandemia,\n",
|
||||
" * współpraca z podmiotami zewnętrznymi.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczeniami technicznymi?\n",
|
||||
"\n",
|
||||
" * Ustawiać zależność ZR (Zakończenie Rozpoczęcie) dla zadań zależnych od innych przedsiębiorstw,\n",
|
||||
" * Dodawać do zadań odstępy czasowe,\n",
|
||||
" * Dodawać rezerwę kierowniczą."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia organizacyjne\n",
|
||||
"**Ograniczenia organizacyjne** to ograniczenia wynikające z zależności pomiędzy kilkoma projektami realizowanymi:\n",
|
||||
" * w jednym zespole,\n",
|
||||
" * przez daną osobę, \n",
|
||||
" * z wykorzystaniem tych samych zasobów.\n",
|
||||
"\n",
|
||||
" * Wskazówki: jak radzić sobie z ograniczeniami organizacyjnymi?\n",
|
||||
" * Odpowiednio zarządzać zasobami: technicznymi i ludzkimi,\n",
|
||||
" * Współdzielić zasoby między projektami,\n",
|
||||
" * Ustawiać indywidualne czasy pracy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.2. Zarządzaj zapasem czasu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zapas czasu</h3> \n",
|
||||
" \n",
|
||||
"<b> Zapas czasu </b> to czas, o który może opóźnić się realizacja zadania, nie wpływając na termin ukończenia projektu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Ścieżka krytyczna</h3> \n",
|
||||
" \n",
|
||||
"<b> Ścieżka krytyczna </b> to sekwencja zadań od rozpoczęcia do zakończenia projektu, której czas przejścia jest najdłuższy.\n",
|
||||
"\n",
|
||||
"Zadania na ścieżce krytycznej mają zerowy zapas czasu.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ścieżka krytyczna.png\" alt=\"Przykład ścieżki krytycznej\" width=500px>\n",
|
||||
"<figcaption> Przykład ścieżki krytycznej </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Zarządzanie zapasem czasu** może polegać na:\n",
|
||||
"\n",
|
||||
" * dodawaniu zapasu czasu do zadań obarczonych ryzykiem,\n",
|
||||
" * dodawaniu zapasu czasu z powodów ograniczeń technicznych lub organizacyjnych, \n",
|
||||
" * zmniejszaniu zapasu czasu (dla zadań leżących poza ścieżką krytyczną),\n",
|
||||
" * analizie (i ew. modyfikacji) zadań leżących na ścieżce krytycznej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Zarządzaj rezerwą kierowniczą\n",
|
||||
"**Rezerwa kierownicza** to fikcyjne zadanie dodane na końcu siatki zadań. Czas na jego realizację to około 10-15% czasu całego projektu.\n",
|
||||
" * Rezerwę kierowniczą dodajemy po stworzeniu całości harmonogramu.\n",
|
||||
" * Tworząc rezerwę pomocniczą, pamiętaj o prawie Parkinsona."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Prawo Parkinsona</h3> \n",
|
||||
" \n",
|
||||
"Praca będzie się rozrastać, aby wypełnić cały czas na nią przewidziany.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/prawo Parkinsona.png\" alt=\"Prawo Parkinsona\" width=500px>\n",
|
||||
"<figcaption> Prawo Parkinsona, źródło: https://www.timeflies.us/blog/what-is-parkinson-s-law-and-how-it-can-make-you-more-productive</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Struktura podziału pracy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Struktura Podziału Pracy</h3> \n",
|
||||
" \n",
|
||||
"Struktura Podziału Pracy to hierarchiczna reprezentacja podziału pracy w projekcie.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Wykonanie prac w projekcie podzielone jest na **etapy**. \n",
|
||||
" * Etap jest częścią projektu, która musi być dokończona przed zaczęciem następnej. Etap składa się z **zadań**.\n",
|
||||
" * Zadania mogą być wykonywane równolegle.\n",
|
||||
" * Zadania mogą zostać podzielone na **podzadania**. \n",
|
||||
" \n",
|
||||
" * Elementy Struktury Podziału Pracy a efekty pracy: \n",
|
||||
" * Etap – efekt jest widoczny dla klienta,\n",
|
||||
" * Zadanie – efekt jest widoczny dla kierownika,\n",
|
||||
" * Podzadanie – efekt jest widoczny dla programisty.\n",
|
||||
" \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/SPP.jfif\" alt=\"Struktura Podziału Pracy\" width=600px>\n",
|
||||
"<figcaption> Struktura Podziału Pracy, źródło: http://pm2pm.pl/slownik-project-managera-wbs/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h3>Zasada 8 - 80</h3>\n",
|
||||
"Wykonanie najmniejszej jednostki harmonogramu powinno zajmować między 8 a 80 godzin.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Tworzenie harmonogramu w programie MS-Project"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Ustawienie daty początku projektu\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie daty.png\" alt=\"Ustawienie daty\" width=300px>\n",
|
||||
"<figcaption> Ustawienie daty początku projektu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Stworzenie Struktury Podziału Pracy\n",
|
||||
"\n",
|
||||
"W nomenklaturze MS Project wyróżniamy:\t\n",
|
||||
" * zadania sumaryczne (odpowiednik Etapu),\n",
|
||||
" * zadania,\n",
|
||||
" * podzadania. \n",
|
||||
"\n",
|
||||
"#### Wskazówka \n",
|
||||
"Ustawiaj hierarchię zadań poprzez tworzenie wcięć w zadaniach podrzędnych.\n",
|
||||
"\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/stworzenie SPP.png\" alt=\"Stworzenie SPP\" width=300px>\n",
|
||||
"<figcaption> Stworzenie SPP</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Ustawienie trybów zadań\n",
|
||||
"\n",
|
||||
"* Tryb ręczny (oznaczony przez pineskę) stosujemy dla zadania, gdy chcemy mieć pełną kontrolę nad jego czasem trwania.\n",
|
||||
"* Tryb automatyczny wykonuje ważną jednak pracę wspomagającą - przesuwa na osi czasu zadania, które są od siebie zależne.\n",
|
||||
"\n",
|
||||
"Stosowanie trybu automatycznego oznacza, że brana jest pod uwagę wskazówka: \"Bierz pod uwagę ograniczenia czasowe\". \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/tryby zadań.png\" alt=\"Ustawianie trybów zadań\" width=500px>\n",
|
||||
"<figcaption> Ustawianie trybów zadań</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.4. Określenie punktów kontrolnych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Punkt kontrolny</h3> \n",
|
||||
" \n",
|
||||
"<b>Punkt kontrolny</b> (ang. milestone) – punkt na osi czasu, który podsumowuje określony zestaw zadań, bądź daną fazę projektu.\n",
|
||||
"<ul>\n",
|
||||
" <li> Może to być: podpisanie dokumentu, otrzymanie wyniku, ważne spotkanie, zatwierdzenie pracy itp.\n",
|
||||
" <li> Zazwyczaj osiągnięcie punktu kontrolnego wiąże się z dalszymi decyzjami odnośnie rozwoju projektu.\n",
|
||||
" <li> Punkt kontrolny ma zerowy czas trwania.\n",
|
||||
" <li> Pojęcie punktu kontrolnego zastąpiło pojęcie kamienia milowego.\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie punktu kontrolnego.png\" alt=\"Ustawianie punktu kontrolnego\" width=900px>\n",
|
||||
"<figcaption> Ustawianie punktu kontrolnego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/punkt kontrolny.png\" alt=\"Punkt kontrolny w MS-Project\" width=500px>\n",
|
||||
"<figcaption> Oznaczenie punktu kontrolnego w MS-Project</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Określenie tygodniowego kalendarza czasu pracy dla zespołu\n",
|
||||
"\n",
|
||||
"Tygodniowy plan pracy dla zespołu obowiązuje tych członków zespołu, dla których nie określono planu indywidualnego. \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 1.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - przycisk</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 2.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - kalendarz</figcaption>\n",
|
||||
"</figure>\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.6. Modyfikacja diagramu Gantta"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Diagram Gantta</h3> \n",
|
||||
" \n",
|
||||
"<b> Diagram Gantta </b> to graficzny sposób reprezentacji harmonogramu, w którym uwzględnia się podział projektu na \n",
|
||||
"poszczególne zadania, oraz rozplanowanie ich w czasie.\n",
|
||||
"\n",
|
||||
"<br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/diagram Gantta.png\" alt=\"diagram Gantta\" width=500px>\n",
|
||||
"<figcaption> Przykładowy diagram Gantta, źródło: https://kierownikprojektu.com/2020/06/11/16-zalet-wykresu-gantta/ </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<h4> Zalety wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> przedstawia następstwo zdarzeń, </li>\n",
|
||||
"<li> uwzględnia zadania wykonywane równolegle, </li>\n",
|
||||
"<li> dobrze sprawdza się dla niewielkich projektów. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h4> Wady wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> nie zawiera szczegółowych opisów zadań, </li>\n",
|
||||
"<li> wymusza podanie konkretnych dat. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Diagram Gantta w MS-Project\n",
|
||||
"\n",
|
||||
"Diagram Gantta tworzony jest częściowo manualne, a częściowo automatycznie.\n",
|
||||
"\n",
|
||||
" * Czas trwania zadania można wpisać ręcznie w kolumnie **czas trwania** (w godzinach, dniach).\n",
|
||||
" * W czasie trwania zadania uwzględniane są tylko dni robocze – zgodnie z kalendarzem.\n",
|
||||
" * Jeśli wpiszemy czasy rozpoczęcia i zakończenia, to czas trwania oblicza się sam. Analogicznie sam oblicza się koniec zadania o znanym rozpoczęciu i czasie trwania.\n",
|
||||
" * Dni wolne od pracy są zaznaczone kolorem szarym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Ustawienie zależności między zadaniami"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zależności między zadaniami</h3> \n",
|
||||
" \n",
|
||||
"Zadanie B jest <b>zależne</b> od A, gdy zmiana terminu wykonania A wpływa na termin wykonania B. Zadanie A nazywamy <b>poprzednikiem</b>, a B – <b>następnikiem </b>. \n",
|
||||
" \n",
|
||||
"<h4> Typy zależności </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> Zadania typu ZR (zakończenie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RR (rozpoczęcie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po rozpoczęciu poprzednika(A).\n",
|
||||
"<li> Zadania typu ZZ (zakończenie-zakończenie). Następnik (B) może się zakończyć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RZ (rozpoczęcie-zakończenie). Następnik (B) może się zakończyć dopiero po rozpoczęciu poprzednika (A).\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Ustawianie zależności między zadaniami w MS-Project\n",
|
||||
"\n",
|
||||
" * Aby określić zadania zależne, należy zaznaczyć dwa zadania i połączyć je (ikoną węzła).\n",
|
||||
" * Aby zmienić typ zależności między zadaniami, należy kliknąć na strzałeczkę łączącą zadania na wykresie Gantta.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zależności.png\" alt=\"Ustawianie zależności między zadaniami\" width=500px>\n",
|
||||
"<figcaption> Ustawianie zależności między zadaniami</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.8. Ustawienie odstępów między zadaniami\n",
|
||||
"Pomiędzy zadaniami zależnymi można ustawić odstęp czasowy (tzw. zwłokę). Pełni on rolę bufora – aby zapewnić zakończenie zadania przed rozpoczęciem następnego.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odstęp czasowy.png\" alt=\"Ustawianie odstępów czasowych\" width=500px>\n",
|
||||
"<figcaption> Ustawianie odstępów czasowych</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.9 Określenie zasobów w projekcie"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zasoby </h3> \n",
|
||||
" \n",
|
||||
"<b>Zasoby (ang. resources) </b> – wszystko, co jest potrzebne do wykonania projektu, a czego brak spowodowałby niewykonanie planu. \n",
|
||||
"W MS-Project wyróżniamy następujące typy zasobów:\n",
|
||||
"<ul>\n",
|
||||
"<li> Praca (ludzie lub komputery),\n",
|
||||
"<li> Materiał (np. energia),\n",
|
||||
"<li> Koszt (np. koszt podróży).\n",
|
||||
"</ul>\n",
|
||||
"</div> "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Zdefiniowanie zasobów w MS-Project\n",
|
||||
"\n",
|
||||
"Prawidłowe określenie wszystkich zasobów niezbędnych w projekcie umożliwia prawidłowe oszacowanie kosztów projektu.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 1.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=400px>\n",
|
||||
"<figcaption> Definiowanie zasobów - arkusz zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 2.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=800px>\n",
|
||||
"<figcaption> Definiowanie zasobów - dane zasobów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 10. Ustawienie tygodniowego kalendarza czasu pracy dla poszczególnych osób (zasobów)\n",
|
||||
"\n",
|
||||
"W programie MS-Project możliwe jest zindywidualizowanie czasu pracy każdej osoby - lub ogólniej - dowolnego zasobu. \n",
|
||||
"\n",
|
||||
"Wykres Gantta reprezentujący harmonogram pracy dostosowuje się do czasu pracy zasobów. Na przykład wykonanie zadania szacowanego na 16 godzin przez osobę, która pracuje 8 godzin w tygodniu, będzie zajmowało dwa tygodnie w harmonogramie.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu.png\" alt=\"Czas pracy zasobu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - wybranie zasobu</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu 2.png\" alt=\"Czas pracy zasobu 2\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - zmiana tygodniowego planu pracy</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 11. Przydzielenie zasobów do zadań\n",
|
||||
"Do kazego zadania powinny być przydzielone zasoby niezbędne do jego wykonania (w tym zasoby ludzkie). \n",
|
||||
"\n",
|
||||
" * Można przydzielić całość lub część zasobu do danego zadania (np. 50%). Będzie to oznaczało, że zasób jest zaangażowany w to zadanie tylko w określonym procencie swojego czasu.\n",
|
||||
" * Do jednego zadania można przydzielić kilka zasobów (np. osób).\n",
|
||||
" * Zasób (np. osoba) może być jednocześnie przypisany do kilku zadań.\n",
|
||||
" \n",
|
||||
" <br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przydzielanie zasobów.png\" alt=\"Przydzielanie zasobów do zadań\" width=500px>\n",
|
||||
"<figcaption> Przydzielanie zasobów do zadań</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 12. Sprawdzenie poprawności alokacji zasobów\n",
|
||||
"\n",
|
||||
"* Skoro zasób może być jednocześnie przypisany do kilku zadań, to można popełnić błąd, nadmiernie przeciążając zasób, tak że musiałby pracować więcej niż to wynika z jego kalendarza.\n",
|
||||
"\n",
|
||||
" * Obciążenie zasobów można sprawdzić następująco:\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 1.png\" alt=\"Sprawdzenie przeciążenia zasobów\" width=400px>\n",
|
||||
"<figcaption> Sprawdzenie przeciążenia zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 2.png\" alt=\"Zasoby z nadmierną alokacją pracy\" width=800px>\n",
|
||||
"<figcaption> Zasoby z nadmierną alokacją pracy (zasoby przeciążone) - przykład</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 13. Wyeliminowanie przeciążeń zasobów\n",
|
||||
"\n",
|
||||
"Nadmierną alokację (przeciążenie) zasobów należy eliminować. Można to zrobić na dwa sposoby:\n",
|
||||
" * manualne odciążanie zasobów,\n",
|
||||
" * automatyczne bilansowanie zasobów.\n",
|
||||
" \n",
|
||||
"Manualne odciążanie zasobów może polegać na zmniejszeniu zaangażowania danego zasobu w zadanie:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odciążanie ręczne.png\" alt=\"Odciążanie ręczne\" width=500px>\n",
|
||||
"<figcaption> Zmniejszenie zaangażowania zasobu w zadanie</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Automatyczne bilansowanie zasobu wykonywane jest przez MS-Porject na żądanie użytkownika.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/automatyczne bilansowanie zasobów.png\" alt=\"automatyczne bilansowanie zasobów\" width=500px>\n",
|
||||
"<figcaption>Automatyczne bilansowanie zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Efekt bilansowania może spowodować przesunięcie pracy w czasie, a co za tym idzie, opóźnienie realizacji projektu:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 1.png\" alt=\"obciążenie zasobu przez bilansowaniem\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu przez bilansowaniem</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 2.png\" alt=\"obciążenie zasobu po bilansowaniu\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu po bilansowaniu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 14. Analiza ścieżki krytycznej\n",
|
||||
"\n",
|
||||
"Zadania leżące na ścieżce krytycznej nazywne są **zadaniami krytycznymi**.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zadania krytyczne.png\" alt=\"ścieżka krytyczne\" width=600px>\n",
|
||||
"<figcaption>Ścieżka krytyczna - przykład</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"W wyniku analizy ścieżki krytycznej można przykładowo:\n",
|
||||
" * zmienić zależności między zadaniami na ścieżce krytycznej (może to przyspieszyć realizację planu)\n",
|
||||
" * zwiększyć zapasy czasu dla zadań krytycznych (zwiększając bezpieczeństwo kosztem czasu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 15. Generowanie raportów\n",
|
||||
"MS-Project umożliwia generowanie różnego typu raportów. Umożliwiają one m.in:\n",
|
||||
" * obliczenie kosztów projektu,\n",
|
||||
" * wyznaczenie, jaki procent planu jest wykonany,\n",
|
||||
" * obliczenie zaangażowania poszczególnych osób w projekt,\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport całościowy.png\" alt=\"raport całościowy\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu całościowego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport zasobów.png\" alt=\"raport zasobów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport kosztów.png\" alt=\"raport kosztów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu kosztów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 16. Poprawianie harmonogramu (czyli co robić, gdy harmonogram się „nie spina”)\n",
|
||||
"\n",
|
||||
"Następujące działania mogą pomóc w poprawieniu harmonogramu\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/modyfikacja planu.png\" alt=\"modyfikacja planu\" width=600px>\n",
|
||||
"<figcaption>Metody poprawiania harmonogramu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Wnioski\n",
|
||||
" * Zarządzanie projektem jest procesem zindywidualizowanym\n",
|
||||
" * Gdyby tak nie było, to MS Project składałby się tylko z jednego przycisku "
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "13. Planowanie prac badawczo-rozwojowych[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,223 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 13. <i>Planowanie prac badawczo-rozwojowych</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Harmonogram projektu</h3> \n",
|
||||
" \n",
|
||||
"Harmonogram projektu to plan uzyskania celów projektu uwzględniający:\n",
|
||||
"<ul>\n",
|
||||
" <li> podział pracy na etapy i zadania,</li>\n",
|
||||
" <li> przydział zasobów do zadań,</li>\n",
|
||||
" <li> terminy wykonania zadań.</li>\n",
|
||||
"</ul>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Ograniczenia</h3> \n",
|
||||
" \n",
|
||||
"Ograniczenia to czynniki, które wpływają na realizację harmonogramu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Rodzaje ograniczeń\n",
|
||||
" * Ograniczenia czasowe\n",
|
||||
" * Ograniczenia techniczne\n",
|
||||
" * Ograniczenia organizacyjne "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Prawo Parkinsona</h3> \n",
|
||||
" \n",
|
||||
"Praca będzie się rozrastać, aby wypełnić cały czas na nią przewidziany.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Struktura Podziału Pracy</h3> \n",
|
||||
" \n",
|
||||
"Struktura Podziału Pracy to hierarchiczna reprezentacja podziału pracy w projekcie.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Tworzenie harmonogramu projektu w programie MS-Project"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie daty początku projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie struktury podziału pracy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie trybów zadań"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie kamieni milowych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie tygodniowego kalendarza czasu pracy dla zespołu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustalenie zależności między zadaniami"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie odstępów między zadaniami"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Określenie zasobów w projekcie: \n",
|
||||
" * Praca (ludzie + komputery), \n",
|
||||
" * Materiały, \n",
|
||||
" * Inne koszty"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ustawienie tygodniowego kalendarza czasu pracy dla zasobów typu \"praca\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przydzielenie zasobów do zadań"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Sprawdzenie poprawności alokacji zasobów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wyeliminowanie przeciążeń zasobów\n",
|
||||
" * manualne bilansowanie zasobów\n",
|
||||
" * automatyczne bilansowanie zasobów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analiza ścieżki krytycznej"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Sporządzanie raportów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Modyfikacja harmonogramu podczas trwania projektu"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "13. Planowanie prac badawczo-rozwojowych[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
692
materiały na PPB (wykład)/13_aspekty_użyteczności.ipynb
Normal file
692
materiały na PPB (wykład)/13_aspekty_użyteczności.ipynb
Normal file
@ -0,0 +1,692 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. <i>Aspekty użyteczności</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Aspekty użyteczności w pytaniach... często bez odpowiedzi\n",
|
||||
"Na podstawie książki \"Postaw na użyteczność\" Matta Laceya (Wydawnictwo Naukowe PWN, 2019).\n",
|
||||
"\n",
|
||||
"Podczas konstruowania systemu informatycznego warto zadać sobie pytania, na które odpowiedź wcale nie musi być oczywista - zależeć może ona od typu aplikacji i środowiska, w którym aplikacja będzie używana."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Definicja użyteczności (...jeszcze jedna)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \n",
|
||||
"\n",
|
||||
"Użyteczność to zestaw cech aplikacji, które sprawiają, że korzysta się z niej <b>łatwo</b>.\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Przepis na sukces\n",
|
||||
"\n",
|
||||
"SUKCES = WARTOŚĆ + ODCZUCIA UŻYTKOWNIKA + SZCZĘŚCIE"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Wartość</h3> \n",
|
||||
"\n",
|
||||
"Wartość aplikacji to suma korzyści dla użytkownika: \n",
|
||||
"<ul>\n",
|
||||
"<li>zadanie jest wykonalne\n",
|
||||
"<li>zadanie jest łatwiejsze\n",
|
||||
"<li>zadanie można wykonać szybciej\n",
|
||||
"<li>aplikacja dostarcza dochód lub oszczędza środki\n",
|
||||
"<li>dostarczenie rozrywki\n",
|
||||
"<li>dostarczenie informacji\n",
|
||||
"<li>edukacja \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Odczucia użytkownika (User Experience)</h3> \n",
|
||||
"\n",
|
||||
"Odczucia użytkownika to uczucia i emocje użytkownika doznawane podczas korzystania z aplikacji.\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Szczęście</h3> \n",
|
||||
"\n",
|
||||
"\"Szczęście przychodzi do tego, kto jest przygotowany i napotyka okazje.\" (Seneka)\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Sześć magicznych składników użyteczności...\n",
|
||||
"...czyli sześć aspektów, pod którymi powinniśmy rozpatrywać użyteczność:\n",
|
||||
"* kontekst, \n",
|
||||
"* wprowadzanie danych, \n",
|
||||
"* wyprowadzanie danych, \n",
|
||||
"* responsywność, \n",
|
||||
"* dostęp do sieci, \n",
|
||||
"* zasoby."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Kontekst"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Kontekst</h3> \n",
|
||||
"\n",
|
||||
"Kontekst to środowisko i okoliczności używania aplikacji. Odpowiada na pytania:\n",
|
||||
"<ul>\n",
|
||||
"<li>Kto?\n",
|
||||
"<li>Gdzie?\n",
|
||||
"<li>Kiedy?\n",
|
||||
"<li>Jak? \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Kto?\n",
|
||||
"\n",
|
||||
"ZASADY:\n",
|
||||
"\n",
|
||||
"1. Musisz precyzyjnie poznać użytkownika.\n",
|
||||
"2. To nie Ty jesteś użytkownikiem.\n",
|
||||
"3. Każdy jest inny.\n",
|
||||
"4. Użytkownik ma prawo robić coś innego\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.1. Musisz precyzyjnie poznać użytkownika\n",
|
||||
"\n",
|
||||
"* Dla kogo aplikacja będzie stanowić wartość?\n",
|
||||
" * Wskazówka: (patrz definicja wartości)\n",
|
||||
"* Kto dokładnie będzie użytkownikiem aplikacji?\n",
|
||||
" * Wskazówka: wykonaj diagram Venna\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/diagram Venna.png\" alt=\"Diagram Venna\" width=500px>\n",
|
||||
"\n",
|
||||
"(Przykładowy diagram Venna, Źródło: Matt Lacey, \"Postaw na użyteczność\")\n",
|
||||
"\n",
|
||||
"* Jakie są grupy użytkowników?\n",
|
||||
" * Wskazówka: metoda persony"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.2. To nie Ty jesteś użytkownikiem\n",
|
||||
" * Czym użytkownik różni się od siebie?\n",
|
||||
" * Czym mogą się rożnić oczekiwania innych uzytkowników od Twoich?\n",
|
||||
" * W stosunku do jakich niedociągnięć użytkownicy mogą być od Ciebie mniej pobłażliwi?\n",
|
||||
" * Dlaczego TY nie jesteś przeciętnym użytkownikiem Twojej aplikacji?\n",
|
||||
" * Jakie umiejętności Cię wyróżniają?\n",
|
||||
" * Dlaczego Tobie będzie łatwiej używać aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.3. Każdy jest inny\n",
|
||||
" * Czy użytkownicy aplikacji mogą się różnić w aspekcie dostępności?\n",
|
||||
" Na dostępność składają się:\n",
|
||||
" * umiejętności\n",
|
||||
" * wiedza\n",
|
||||
" * kultura\n",
|
||||
" * lokalizacja\n",
|
||||
" * płeć\n",
|
||||
" * wiek\n",
|
||||
" * niepełnosprawność\n",
|
||||
" * choroby (daltonizm)\n",
|
||||
" * Czy użytkownicy aplikacji mogą mieć od niej różne oczekiwania?\n",
|
||||
" * Czy użytkownicy aplikacji mogą chcieć uzyskać dzięki niej różne cele?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.4. Użytkownik ma prawo robić coś innego\n",
|
||||
" * Jakie inne działania będą podejmować użytkownicy podczas pracy z naszą aplikacją?\n",
|
||||
" * Jak się o tym dowiedzieć?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. 2. Gdzie?\n",
|
||||
"ZASADA: \n",
|
||||
"Czy aplikacja będzie stosowana w różnych krajach?\n",
|
||||
" * Jesli nie, to pomiń dalsze pytania.\n",
|
||||
" * Jeśli tak, to odpowiedz na dalsze pytania.\n",
|
||||
"\n",
|
||||
"PYTANIA:\n",
|
||||
" * Czy zaplanowałeś wielojęzyczność aplikacji?\n",
|
||||
" * Jakimi językami posługują się użytkownicy w innych krajach?\n",
|
||||
" * Zaplanuj tłumaczenie aplikacji\n",
|
||||
" * Czy użytkownicy innych krajów stosują te same formaty liczb / dat?\n",
|
||||
" * Jeśli nie, to opracuj algorytmy konwersji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Kiedy?\n",
|
||||
"### 1.3.1. Pora (dnia, tygodnia, miesiąca, roku)\n",
|
||||
"Czy aplikacja może działać w różny sposób w zależności od:\n",
|
||||
" * pory dnia\n",
|
||||
" * dnia tygodnia\n",
|
||||
" * dnia miesiąca\n",
|
||||
" * pory roku"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.3.2. Czas użytkowania\n",
|
||||
" * Jak długo trwa jedna sesja użytkowania?\n",
|
||||
" * daj możliwość korzystania nawet w bardzo krótkim czasie\n",
|
||||
" * Po jakim czasie użytkownik porzuci aplikację?\n",
|
||||
" * zachęcaj do pozostania z aplikacją"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.4. Jak?\n",
|
||||
"### 1.4.1. Okoliczności\n",
|
||||
" * Czy użytkownik jest w ruchu?\n",
|
||||
" * Czy użytkownik może wykonywać inne czynności?\n",
|
||||
" * Jakie?\n",
|
||||
" * Czy jest skupiony na naszej aplikacji?\n",
|
||||
" * Czy nasza aplikacja współpracuje z innymi?\n",
|
||||
" * W jakiej pozycji użytkownik korzysta z aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.4.2. Urządzenia\n",
|
||||
" * Zasada WORE (Write Once Run Everywhere)\n",
|
||||
" * Plusy\n",
|
||||
" * szybciej powstaje\n",
|
||||
" * łatwiejsza w utrzymaniu\n",
|
||||
" * możliwość dostosowania dla wielu urządzeń\n",
|
||||
" * przydatna szczególnie w grach (niestandardowy UI)\n",
|
||||
" * Minusy\n",
|
||||
" * wymagana znajomość różnych platform\n",
|
||||
" * wymagana dyscyplina kodu\n",
|
||||
" * konieczność dostosowania elementów wizualnych do różnych platform\n",
|
||||
" * konieczność testowania na wielu platformach\n",
|
||||
" * Różne systemy operacyjne\n",
|
||||
" * W jakich systamach operacyjnych ma działać aplikacja?\n",
|
||||
" * Czy wziąłeś pod uwagę ograniczenia narzucane przez różne sklepy?\n",
|
||||
" * Czy wygląd aplikacji jest zgodny z przyzwyczajeniami użytkowników danego systemu?\n",
|
||||
"\n",
|
||||
" * Wielkość urządzenia\n",
|
||||
" * Czy wziąłeś pod uwagę, że wielkość ekranu ma wpływ na to, co jest wyświetlane?\n",
|
||||
" * Czy pomyślałeś, jak trzymane jest urządzenie?\n",
|
||||
" \n",
|
||||
" * Przyciski sprzętowe\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Czujniki\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Wskazówka: Współczesne urządzenia mogę mieć kilkanaście czujników:\n",
|
||||
" * ruchu\n",
|
||||
" * pozycji\n",
|
||||
" * położenia\n",
|
||||
" * środowiskowe "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Wprowadzanie danych (Input)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Input</h3> \n",
|
||||
"\n",
|
||||
"Information fed into a data processing system or computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Interakcja użytkownik - system\n",
|
||||
"### 2.1.1. Wejście dotykowe\n",
|
||||
" * Czy wziąłeś pod uwagę zalecane minimalne wielkości obszarów dotykowych?\n",
|
||||
" * iOS: 11 mm\n",
|
||||
" * Android: 7-10 mm\n",
|
||||
" * Windows: 7-9 mm\n",
|
||||
"\n",
|
||||
" * Czy gesty obsługiwane są standardowo?\n",
|
||||
" * pojedyncze dotknięcie\n",
|
||||
" * podwójne dotknięcie\n",
|
||||
" * przesunięcie palcem po ekranie\n",
|
||||
" * dotknięcie i przytrzymanie\n",
|
||||
" * uszczypnięcie / rozciąganie\n",
|
||||
" * obracanie\n",
|
||||
" * inne (powstające)\n",
|
||||
" \n",
|
||||
" * Czy pomyślałeś o tym, że podczas dotykania ekranu jego część będzie zasłonięta?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.2. Rysik\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wprowadzania danych za pomocą rysika?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.3. Mysz i klawiatura\n",
|
||||
"\n",
|
||||
" * Czy aplikacja będzie obługiwana myszą i / lub klawiaturą?\n",
|
||||
" * Jeśli myszą, to weź pod uwagę spójność dotyku i uzycia myszy:\n",
|
||||
" * pojedyncze dotknięcie - pojedyncze kliknięcie\n",
|
||||
" * podwójne dotknięcie - podwójne kliknięcie\n",
|
||||
" * prawy przycisk myszy - przytrzymanie\n",
|
||||
" * przesuwanie myszą - przesuwanie palcem\n",
|
||||
" * Jeśli klawiaturą, to weź pod uwagę standardową reakcję klawiszy:\n",
|
||||
" * Tab\n",
|
||||
" * Enter\n",
|
||||
" * Ctrl\n",
|
||||
" * Shift"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.4. Wejście głosowe\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wejścia głosowego?\n",
|
||||
" * Jeśli tak, to weź pod uwagę ograniczenia techniczne systemów rozpoznawania mowy (np. architektura: klient - serwer)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Ułatwienia wprowadzania danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.1. Minimalizacja wysiłku użytkownika\n",
|
||||
" * Czy pomyślałeś o zminimalizowaniu wysiłku użytkownika przy wprowadzaniu danych?\n",
|
||||
" * Wskazówki:\n",
|
||||
" * proponowane wyboru zamiast ręcznego wprowadzania\n",
|
||||
" * skróty (szybki dostęp)\n",
|
||||
" * autosugestie (autouzupełnianie)\n",
|
||||
" * łączenie wprowadzania danych (np. daty przyjazdu / wyjazdu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.2. Optymalizacja formularzy\n",
|
||||
" * Czy w Twojej aplikacji dane są wprowadzane za pomocą formularzy? Jeśli tak, to odpowiedz na następujące pytania:\n",
|
||||
" * Czy dobrze posortowałeś listy wyboru?\n",
|
||||
" * Czy program reaguje już po części wpisanych danych?\n",
|
||||
" * Czy nad polami są ich etykiety?\n",
|
||||
" * Czy program podpowiada format danych?\n",
|
||||
" * Czy zapewniłeś wartości domyślne?\n",
|
||||
" * Czy pomyślałeś o walidacji danych?\n",
|
||||
" * Czy błędy pokazywane są w odpowiednim miejscu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.3. Altenatywne metody wprowadzania danych\n",
|
||||
" * Czy wziąłeś pod uwagę alternatywne metody wejścia?\n",
|
||||
" * wirtualna klawiatura\n",
|
||||
" * pismo ręczne\n",
|
||||
" * optyczne rozpoznawanie znaków\n",
|
||||
" * interaktywne mapy, pozwalające wskazać adres (lokalizację)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.3. Dane z innych źródeł"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Dane z innych źródeł</h3> \n",
|
||||
"\n",
|
||||
"Są to dane niewprowadzone przez użytkownika aplikacji.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.1. Dane z serwisów sieciowych\n",
|
||||
" * W jaki sposób nasza aplikacja może pozyskiwać informacje dane z serwisów sieciowych?\n",
|
||||
" * w formie odpowiedzi na żądanie\n",
|
||||
" * w formie powiadomień (notyfikacji)\n",
|
||||
" * w formie SMS-ów\n",
|
||||
" * Czy pomyślałeś o obsłudze komunikatów o błędach przesłanych z serwisów sieciowych?\n",
|
||||
" * Czy pomyślałeś o przetworzeniu przesłanych komunikatów (np. skróceniu ich, wyekstrahowaniu tego, co najważniejsze)?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.2. Dane z systemu operacyjnego\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane PIM (Personal Information Manager)?\n",
|
||||
" * wyszukiwanie danych teleadresowych\n",
|
||||
" * wyszukiwanie kontaktów\n",
|
||||
" * sprawdzanie poprawności wprowadzanych danych\n",
|
||||
" * korzystanie z osobistego kalendarza\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z systemu plików?\n",
|
||||
" * zdjęcia\n",
|
||||
" * filmy\n",
|
||||
" * teksty"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.3. Dane z innych aplikacji\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z innych aplikacji? \n",
|
||||
" * Jeśli tak, to w jaki sposób dane są współdzielone?\n",
|
||||
" * wspólne dane przechowywane lokalnie\n",
|
||||
" * natywne współdzielenie (wbudowany mechanizm współdzielenia danych)\n",
|
||||
" * formaty plików (typy MIME: Multipurpose Internet Mail Extensions)\n",
|
||||
" * metoda \"kopiuj i wklej\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.4. Dane z czujników\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z czujników? \n",
|
||||
" * Jeśli tak, to czy zadbałeś o to, aby\n",
|
||||
" * zapytać użytkownika o uprawnienia\n",
|
||||
" * wyjaśnić, w jaki sposób aplikacja będzie korzystać z czuujników\n",
|
||||
" * wyjaśnić, do czego dane te są potrzebne\n",
|
||||
" * wspomnieć o kwestiach polityki prywatności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.5. Inne typy wprowadzania danych\n",
|
||||
" * Czy istnieją jeszcze inne metody, w jaki aplikacja może pozyskać dane?\n",
|
||||
" * np. karta z chipem"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Wyprowadzanie danych (wyjście)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Output</h3> \n",
|
||||
"\n",
|
||||
"Information produced by a computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Wyjście wizualne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Zasady projektowania wizualnych komponentów wyprowadzania danych:</h3> \n",
|
||||
" \n",
|
||||
"<ol>\n",
|
||||
"<li> \"Cele użytkownika na pierwszym miejscu.\"\n",
|
||||
"<li> Spełnianie oczekiwań użytkowników\n",
|
||||
"<li> Uwzględnianie rodzaju urządzenia\n",
|
||||
"<li> Przestrzeganie norm i konwencji\n",
|
||||
"</ol>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Wyjście niewizualne\n",
|
||||
" * Czy wziąłeś pod uwagę możliwości wyprowadzania danych w inny sposób niż wizualnie?\n",
|
||||
" * dźwięki i wibracje\n",
|
||||
" * kanały komunikacji dla innych aplikacji\n",
|
||||
" * powiadomienia \"push\"\n",
|
||||
" * poczta elektroniczna\n",
|
||||
" * SMS"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Responsywność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Responsywność</h3> \n",
|
||||
"\n",
|
||||
"Cecha aplikacji, która powoduje, że użytkownicy uważają, że mogą uzyskać swój cel szybko - bez straty czasu.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Responsywność aplikacji to nie to samo co responsive design.**\n",
|
||||
"> Responsive design oznacza, że to co jest wyświetlane w danym momencie w aplikacji, dostosowuje się do zmieniającej się wielkości ekranu. \n",
|
||||
"> Pojęcie responsywności jest dużo szersze: aplikacja powinna reagować nie tylko na wielkość ekranu, lecz na akcje użytkownika i działania aplikacji. Szybkość i sposób, w jaki aplikacja odpowiada, przekłada się na doświadczenia użytkownika."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Dostęp do sieci\n",
|
||||
" * Czy wziąłeś pod uwagę potencjalne problemy z dostępem do sieci:\n",
|
||||
" * szybkość połączenia może się różnić\n",
|
||||
" * koszt połączenia może być zmienny\n",
|
||||
" * połączenie może być niedostępne\n",
|
||||
" * połączenie może być utracone"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 6. Zasoby"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Resource</h3> \n",
|
||||
"\n",
|
||||
"A source of supply, support, or aid, especially one that can be readily drawn upon when needed (www. dictionary.com)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" > A gdy się zasoby skończą, to ich nie będzie.\n",
|
||||
" \n",
|
||||
"Ilość zasobów jest skończona, więc naszym obowiązkiem jest je oszczędzać:\n",
|
||||
"\n",
|
||||
" * Energia\n",
|
||||
" * Pojemność dysku\n",
|
||||
" * Pojemność pamięci\n",
|
||||
" * Zasoby procesora\n",
|
||||
" * Możliwości przesyłu danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
"Użyteczność często rozumiana jest jako synonim łatwości użytkowania aplikacji.\n",
|
||||
"\n",
|
||||
"Zapewnienie, aby aplikacja używana była **łatwo**, nie jest zadaniem banalnym. Wymaga zadania wielu pytań, na które odpowiedzi mogą być zupełnie różne w zależności od typu aplikacji."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "11. Aspekty użyteczności[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
BIN
materiały na PPB (wykład)/obrazy/Halstead1.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/Halstead1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
materiały na PPB (wykład)/obrazy/Halstead2.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/Halstead2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
BIN
materiały na PPB (wykład)/obrazy/Halstead3.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/Halstead3.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.1 KiB |
BIN
materiały na PPB (wykład)/obrazy/LOC vs FP.jpg
Normal file
BIN
materiały na PPB (wykład)/obrazy/LOC vs FP.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 94 KiB |
BIN
materiały na PPB (wykład)/obrazy/SPP.jfif
Normal file
BIN
materiały na PPB (wykład)/obrazy/SPP.jfif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
materiały na PPB (wykład)/obrazy/SPP.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/SPP.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.5 KiB |
BIN
materiały na PPB (wykład)/obrazy/WMC.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/WMC.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 118 KiB |
BIN
materiały na PPB (wykład)/obrazy/bilansowanie automatyczne 1.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/bilansowanie automatyczne 1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
materiały na PPB (wykład)/obrazy/bilansowanie automatyczne 2.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/bilansowanie automatyczne 2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
BIN
materiały na PPB (wykład)/obrazy/czas pracy 1.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/czas pracy 1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
BIN
materiały na PPB (wykład)/obrazy/czas pracy 2.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/czas pracy 2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
BIN
materiały na PPB (wykład)/obrazy/czas pracy zasobu 2.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/czas pracy zasobu 2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
BIN
materiały na PPB (wykład)/obrazy/czas pracy zasobu.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/czas pracy zasobu.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
BIN
materiały na PPB (wykład)/obrazy/diagram Gantta.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/diagram Gantta.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.6 KiB |
BIN
materiały na PPB (wykład)/obrazy/diagram Venna.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/diagram Venna.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
BIN
materiały na PPB (wykład)/obrazy/korelacja właściwości.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/korelacja właściwości.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
BIN
materiały na PPB (wykład)/obrazy/korelacja.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/korelacja.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 4.0 KiB |
BIN
materiały na PPB (wykład)/obrazy/modyfikacja planu.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/modyfikacja planu.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
materiały na PPB (wykład)/obrazy/odciążanie ręczne.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/odciążanie ręczne.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
materiały na PPB (wykład)/obrazy/odstęp czasowy.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/odstęp czasowy.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
BIN
materiały na PPB (wykład)/obrazy/prawo Parkinsona.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/prawo Parkinsona.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.7 KiB |
BIN
materiały na PPB (wykład)/obrazy/przeciążenie zasobów 1.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/przeciążenie zasobów 1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
materiały na PPB (wykład)/obrazy/przeciążenie zasobów 2.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/przeciążenie zasobów 2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
BIN
materiały na PPB (wykład)/obrazy/przydzielanie zasobów.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/przydzielanie zasobów.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
BIN
materiały na PPB (wykład)/obrazy/punkt kontrolny.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/punkt kontrolny.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
materiały na PPB (wykład)/obrazy/raport całościowy.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/raport całościowy.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 82 KiB |
BIN
materiały na PPB (wykład)/obrazy/raport kosztów.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/raport kosztów.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
BIN
materiały na PPB (wykład)/obrazy/raport zasobów.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/raport zasobów.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
BIN
materiały na PPB (wykład)/obrazy/stworzenie SPP.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/stworzenie SPP.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
BIN
materiały na PPB (wykład)/obrazy/tryby zadań.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/tryby zadań.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
BIN
materiały na PPB (wykład)/obrazy/ustawienie daty.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/ustawienie daty.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 82 KiB |
BIN
materiały na PPB (wykład)/obrazy/wypadkowa.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/wypadkowa.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.1 KiB |
BIN
materiały na PPB (wykład)/obrazy/zadania krytyczne.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/zadania krytyczne.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
BIN
materiały na PPB (wykład)/obrazy/zależności.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/zależności.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 55 KiB |
BIN
materiały na PPB (wykład)/obrazy/zasoby 1.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/zasoby 1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
materiały na PPB (wykład)/obrazy/zasoby 2.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/zasoby 2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
BIN
materiały na PPB (wykład)/obrazy/ścieżka krytyczna.png
Normal file
BIN
materiały na PPB (wykład)/obrazy/ścieżka krytyczna.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 177 KiB |
Loading…
Reference in New Issue
Block a user