diff --git a/.ipynb_checkpoints/Demonstracje końcowe-checkpoint.ipynb b/.ipynb_checkpoints/Demonstracje końcowe-checkpoint.ipynb new file mode 100644 index 0000000..e36dee4 --- /dev/null +++ b/.ipynb_checkpoints/Demonstracje końcowe-checkpoint.ipynb @@ -0,0 +1,115 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Organizacja demonstracji projektów\n", + "Informacje dotyczą dmemostracji końcowych projektów na zajęciach PBR. \n", + "Podane poniżej informacje mogą ulec korektom do dnia 9 czerwca 2022 włącznie." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Termin i forma demonstracji\n", + " * Demonstracje będą prowadzone w dniu 10 czerwca 2022 w formie stacjonarnej w auli A.\n", + " * Czas na jedną demonstrację: 10 minut (włączając przerwę).\n", + " * Niezbędnym elementem demonstracji jest interakcja demonstrowanego systemu z widownią.\n", + " * Demonstracje rozpoczną się o godzinie 11.00, a zakończą lunchem o godzinie 15.30." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Oceny, wyróżnienia\n", + " * Demonstracje są oceniane przez jury: prowadzących projekty i zaproszonych gości z biznesu.\n", + " * Dla dwóch najwyżej ocenionych demonstracji przewidziane są nagrody ufundowane przez firmę DomData." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Plan dnia: Sztuczna Inteligencja, Cyberbezpieczeństwo, Biznes\n", + "\n", + "### Cyberware\n", + "\n", + "* Czas: 11.00 - 11.30\n", + " * HoneyPot\n", + " * RandomSec\n", + " * Phish&Ware\n", + " \n", + "### Learn and Play\n", + "\n", + "* Czas: 11.30 - 11.50\n", + " * Tao Testing - rożnorodne testy online\n", + " * Soita - inteligentny system nauczania\n", + " \n", + "### Natural Language Processing\n", + "\n", + "* Czas: 11.50 - 12.30\n", + " * Transfix - translacja i korekta testów\n", + " * Automatyczne generowanie tweetów\n", + " * Wyszukiwanie w dokumentach zdigitalizowaych\n", + " * Speakato - asystent głosowy poleceń systemu Windows \n", + "\n", + "### Przerwa na kawę\n", + "\n", + "* Czas: 12.30 - 13.00\n", + "\n", + "### Music i inne\n", + "\n", + "* Czas: 13.00 - 13.30\n", + " * System rekomendacji muzycznych\n", + " * Odgadywanie utworu muzycznego\n", + " * System rezerwacji lotów\n", + "\n", + "\n", + "### Sport Analysis\n", + "\n", + "* Czas: 13.30 - 14.30\n", + " * Metryki piłkarzy na poszczególnych pozycjach\n", + " * TV2D - analiza video meczu piłkarskiego\n", + " * Przewidywanie kontuzji w piłce nożnej\n", + " * Przewidywanie wyniku drużyny w tabeli końcowej\n", + "\n", + "\n", + "### Prezentacje projektu AI Tech oraz Centrum Sztucznej Inteligencji\n", + "\n", + "* Czas: 14.30 - 15.00\n", + "\n", + "### Prelekcje zproszonych gości z biznesu\n", + "\n", + "* Czas: 15.00 - 15.30\n", + "\n", + "### Lunch\n", + "\n", + "* Czas: 15.30 - 16.30" + ] + } + ], + "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 +} diff --git a/Demonstracje końcowe.ipynb b/Demonstracje końcowe.ipynb index f5d43a8..e36dee4 100644 --- a/Demonstracje końcowe.ipynb +++ b/Demonstracje końcowe.ipynb @@ -107,7 +107,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" } }, "nbformat": 4, diff --git a/Organizacja demonstracji projektów.ipynb b/Demonstracje projektów.ipynb similarity index 55% rename from Organizacja demonstracji projektów.ipynb rename to Demonstracje projektów.ipynb index a9bc7d0..37e325b 100644 --- a/Organizacja demonstracji projektów.ipynb +++ b/Demonstracje projektów.ipynb @@ -5,8 +5,7 @@ "metadata": {}, "source": [ "# Organizacja demonstracji projektów\n", - "Informacje dotyczą dmemostracji projektów na zajęciach PBR. \n", - "Podane poniżej informacje mogą ulec korektom do dnia 31 stycznia włącznie." + "Informacje dotyczą dmemostracji projektów na zajęciach SYI. " ] }, { @@ -14,10 +13,9 @@ "metadata": {}, "source": [ "## Termin i forma demonstracji\n", - " * Demonstracje będą prowadzone w formie zdalnej za pomocą platformy MS-Teams.\n", - " * Czas na demonstrację: 8 minut (+ 1 minuta przerwy)\n", - " * Niezbędnym elementem demonstracji jest interakcja demonstrowanego systemu z widownią.\n", - " * Zajęcia rozpoczną się o 13:45, a zakończą o 17:00." + " * Demonstracje będą prowadzone w formie stacjonarnej.\n", + " * Czas na demonstrację: minut (+ 1 minuta przerwy)\n", + " * Niezbędnym elementem demonstracji jest interakcja demonstrowanego systemu z widownią." ] }, { @@ -28,16 +26,8 @@ "\n", " * Każdy opiekun grupy będzie proponował ocenę systemu prezentowanego przez grupę w skali do 180 punktów laboratoryjnych w oparciu o:\n", " * ocenę dokumentacji projektu,\n", - " * ocenę stanu projektu na zajęciach laboratoryjnych w dniu 25 stycznia,\n", - " * ocenę demonstracji w dniu 1 lutego.\n", - " * Projekt powinien znajdować się na 6. poziomie gotowości technologicznej:\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", - " * Jeśli projekt spełnia założenia, to opiekun projektu proponuje ocenę w skali do 180 punktów.\n", + " * ocenę stanu projektu na zajęciach laboratoryjnych w dniu ...,\n", + " * ocenę demonstracji w dniu ...\n", " * Proponowane składowe oceny implementacji systemu\n", "\n", "\n", @@ -77,8 +67,8 @@ "
\n", " \n", " * Ocena będzie zatwierdzana przez komisję, w której skład wchodzić będą wszyscy opiekunowie.\n", - " * Do oceny zostaną doliczone punkty bonusowe za demonstracje wyróżnione przez studentów oraz zaproszonych gości.\n", - " * Punkty bonusowe będą przyznawane na podstawie wyników ankiety. W ramach ankiety każdy student i każdy prowadzący (gość) będzie poproszony o wskazanie sześciu najlepszych demonstracji. Studenci nie mogą głosować na demonstracje swoich grup.\n", + " * Do oceny zostaną doliczone punkty bonusowe za demonstracje wyróżnione przez studentów.\n", + " * Punkty bonusowe będą przyznawane na podstawie wyników ankiety. Studenci nie mogą głosować na demonstracje swoich grup.\n", "\n", " * Link do ankiety:\n", " https://forms.gle/Xrk3fCHc7MXkmFET8\n", @@ -91,19 +81,19 @@ " Miejce Nazwa projektu Punkty bonusowe\n", " \n", " \n", - " 1. Jaka to nuta? 20\n", + " 1. /td> 20\n", " \n", " \n", - " 2. DOC AI 15\n", + " 2. 15\n", " \n", " \n", - " 3. Songwise 12\n", + " 3. 12\n", " \n", " \n", - " 4 Speakato 9\n", + " 4 9\n", " \n", " \n", - " 5 PhishandWare 6\n", + " 5 6\n", " \n", " \n", " 6 Meetify 3\n", @@ -118,52 +108,8 @@ "## Plan zajęć\n", "\n", "### Wprowadzenie\n", - "* Czas 13.45 - 13.50\n", "\n", - "### Cyberware\n", - "\n", - "* Czas: 13.50 - 14.15\n", - " * HoneyPot\n", - " * RandomSec\n", - " * Phish&Ware\n", - " \n", - "### Learn and Play\n", - "\n", - "* Czas: 14.20 - 14.55\n", - " * Rozpoznawanie komend głosowych w grach\n", - " * Tao Testing\n", - " * Testy\n", - " * Ekosystem\n", - " \n", - "### Music\n", - "\n", - "* Czas: 15.00 - 15.25\n", - " * Wyszukiwanie słuchaczy podobnej muzyki\n", - " * Rekomandacje muzyczne\n", - " * Odgadywanie utworu muzycznego\n", - "\n", - "\n", - "### Natural Language Processing\n", - "\n", - "* Czas: 15.30 - 15.55\n", - " * Transfix\n", - " * Automatyczne generowanie kampanii\n", - " * Wyszukiwanie w dokumentach\n", - "\n", - "### Sport Analysis\n", - "\n", - "* Czas: 16.00 - 16.40\n", - " * Predykcja sukcesu w piłce nożnej\n", - " * TV2D\n", - " * Predykcja kontuzji\n", - " * Metryki piłkarzy\n", - " * Analiza przydatności zawodników w La Lidze\n", - "\n", - "### Wypełnienie ankiet i zakończenie\n", - "\n", - "* Czas: 16.45 - 17.00\n", - "\n", - "\n" + "### Wypełnienie ankiet i zakończenie\n" ] } ], @@ -183,7 +129,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" } }, "nbformat": 4, diff --git a/Organizacja zajęć.ipynb b/Organizacja zajęć.ipynb index 7ad82f8..294ed72 100644 --- a/Organizacja zajęć.ipynb +++ b/Organizacja zajęć.ipynb @@ -120,7 +120,7 @@ "### Punktacja zadań wykonywanych na laboratorium\n", "\n", " \n", - " \n", + " \n", " \n", " \n", " \n", @@ -142,12 +142,7 @@ "\n", "### Ocena prototypu\n", "\n", - "Na przedostatnich zajęciach z laboratorium opiekun projektu decyduje, czy pr0totyp projektu spełnił swoje założenia. Prototyp powinien osiagnąc co najmniej 5. poziom gotowości technologicznej:\n", - "\n", - "* 5. poziom gotowości technologicznej\n", - " * Zweryfikowano działanie w warunkach zbliżonych do rzeczywistego (np. przeprowadzono testowanie prototypu wdrożonego na serwerze WMI, a nie na serwerze lokalnym).\n", - "* 6. poziom gotowości technologicznej \n", - " * Dokonano demonstracji działania w warunkach zbliżonych do rzeczywistych (np. zademonstrowano wdrożony prototyp z interakcją użytkowników).\n", + "Na przedostatnich zajęciach z laboratorium opiekun projektu decyduje, czy prototyp projektu spełnił swoje założenia.\n", " \n", "Jeśli prototyp nie spełnia założeń, to ocena końcowa wynosi 0 punktów (na 180).\n", "\n", diff --git a/Prezentacje koncepcji.ipynb b/Prezentacje koncepcji.ipynb index 4db5754..c48716b 100644 --- a/Prezentacje koncepcji.ipynb +++ b/Prezentacje koncepcji.ipynb @@ -36,9 +36,6 @@ "\n", " * Ankieta dla gości oraz prowadzących poszczególne grupy https://forms.gle/qmdPovjist7ts2vi7\n", " \n", - " * Aby ułatwić ocenę, studenci powinni na początku zajęć w 2-3 zdaniach opisać swój projekt tutaj: \n", - "https://docs.google.com/document/d/16glWbhCF_OR1I-SbMlBszTK4iVBpUw4wSTLw810mEGk/edit?usp=sharing \n", - "(każdy ma prawo edycji)\n", "\n", "### Prezentacje wyróżnione przez studentów\n", "\n", @@ -47,19 +44,19 @@ " \n", " \n", " \n", - " \n", + " \n", " \n", " \n", - " \n", + " \n", " \n", " \n", - " \n", + " \n", " \n", " \n", - " \n", + " \n", " \n", " \n", - " \n", + " \n", " \n", "
Typ zadania Liczba punktówTyp zadania Maksymalna liczba punktów
Zadania na laboratoriach11 x 30 = 360Miejce Nazwa projektu Punkty bonusowe
1. BitSearch 101. 10
2. Meetify 72. 7
3. Rozpoznawanie komend głosowych 53. 5
4 Transfix 34 3
5 Lech Analytics 25 2
\n", "\n", @@ -69,22 +66,19 @@ " Miejce Nazwa projektu Punkty bonusowe\n", " \n", " \n", - " 1. BitSearch 10\n", + " 1. 10\n", " \n", " \n", - " 2. HoneyPot 7\n", + " 2. 7\n", " \n", " \n", - " 3. Wyszukiwanie w dokumentach5\n", + " 3. 5\n", " \n", " \n", - " 4 Rozpoznawanie komend głosowych 3\n", + " 4 3\n", " \n", " \n", - " 5 RandomSec 2\n", - " \n", - " \n", - " 5 PhishandWare 2\n", + " 5 2\n", " \n", " \n" ] @@ -94,48 +88,12 @@ "metadata": {}, "source": [ "## Plan zajęć\n", + "### Wrowadzenie\n", "\n", - "### Wprowadzenie\n", - "* Czas 15.15 - 15.20\n", - "\n", - "### Sport Analysis\n", - "\n", - "* Czas: 15.20 - 15.40\n", - "* Kolejność trzech prezentacji - do ustalenia.\n", - "\n", - "### Natural Language Processing\n", - "\n", - "* Czas: 15.40 - 16.05\n", - " * Transfix\n", - " * BitSearch\n", - " * Automatyczne generowanie kampanii\n", - " * Wyszukiwanie w dokumentach\n", - "\n", - "### Music\n", - "\n", - "* Czas: 16.05 - 16.25\n", - " * Wyszukiwanie słuchaczy podobnej muzyki\n", - " * Rekomandacje muzyczne\n", - " * Odgadywanie utworu muzycznego\n", - "\n", - "### Learn and Play\n", - "\n", - "* Czas: 16.25 - 16.50\n", - " * Rozpoznawanie komend głosowych w grach\n", - " * Tao Testing\n", - " * Testy\n", - " * Ekosystem\n", - "\n", - "### Cyberware\n", - "\n", - "* Czas: 16.50 - 17.05\n", - " * HoneyPot\n", - " * RandomSec\n", - " * Phish&Ware\n", " \n", "### Wypełnienie ankiet i zakończenie\n", "\n", - "* Czas: 17.05 - 17.15\n", + "\n", "\n", "\n" ] diff --git a/materiały na laboratorium/01_praca_zespolowa_lab.ipynb b/materiały na laboratorium/01_praca_zespolowa_lab.ipynb index 5d54c55..4807b0e 100644 --- a/materiały na laboratorium/01_praca_zespolowa_lab.ipynb +++ b/materiały na laboratorium/01_praca_zespolowa_lab.ipynb @@ -6,65 +6,14 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Projekt badawczo-rozwojowy

\n", - "

1. Organizacja pracy zespołowej[laboratorium]

\n", + "

Systemy informatyczne

\n", + "

1. Organizacja pracy zespołowej

\n", "

Krzysztof Jassem (2021)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" ] }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "# Proponowana punktacja zadań wykonywanych na przedmiocie PBR\n", - "\n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - "
Typ zadania Liczba punktów
Zadania na laboratoriach13 x 30 = 390
Sprinty6 x 10 = 60
Ocena końcowa za wynik projektu150
Suma600
" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "# Proponowana skala ocen na przedmiocie PBR\n", - "\n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - " \n", - "
Liczba punktów Ocena
500-6005
450-4994,5
400-4494
350-3993,5
300-3493
" - ] - }, { "cell_type": "markdown", "metadata": {}, @@ -79,21 +28,20 @@ "metadata": {}, "source": [ "# Organizacja zespółów projektowych na laboratorium nr 1\n", - "Studenci organizaują się w zespoły ok. 4-osobowe (liczba osób w zespole może się wahać) na przykład w następujący sposób: \n", - "Studenci przedmotu PBR lub przedmiotu Systemy Informatyczne ogłaszają na mediach społecznościowych swoje oczekiwania w stosunku do projektu realizowanego łącznie na przedmiotach PBR i SYI, np.\n", - "1. \"Przedstawiam krótką reklamówkę swojego projektu. Potrzebuję do zespołu...\n", - "2. \"Chcę dołączyć do zespołu z określonym projektem magisterskim\". Specjalizuję się w...\n", - "3. \"Chcę dołączyć do zespołu, który będzie dopiero definiował projekt systemu informatycznego.\"\n", + "Studenci organizaują się w zespoły ok. 4-osobowe. Zespoły organizowane są przez osoby, które uzyskały najwyższe wyniki w teście na lidera przeprowadzonym na wykładzie.\n", + "\n", + "Wskazane jest, aby w grupie znaleźli się studenci o różnych osobowościach (względem motywacji i podejścia do pracy).\n", "\n", - "Na podstawie tych informacji tworzone są zespoły, które będą współpracować na laboratorium nr 1. \n", - "Idealny skład zespołu to: dwie osoby z informatyki i dwie osoby z analizy danych, ale ten warunek nie jest konieczny. Składy zespołów mogą zmieniać się do zajęć nr 3 włącznie. \n", - "Podczas Laboratorium 1. liderem zespołu jest osoba, która uzyskała najwyższy wynik w teście na lidera podczas wykładu. (Lider może ulec zmianie do zajęć nr 3 włącznie). \n", "Wskazane jest, aby w każdym zespole znalazły się osoby o zróznicowanych umiejętnościach:\n", "* Wizjoner - osoba, która podejmuje decyzję o kierunku wspólnych prac: jaki projekt opracowujemy na Laboratorium 1. (Projekt może ulec zmianie do zajęć nr 3 włącznie).\n", "* Specjalista – grafik; jego zadaniem będzie stworzenie rysunku – projektu interfejsu użytkownika - najlepiej za pomocą jakiegoś narzędzia.\n", "* Bibliotekarz; jego zadaniem będzie opisanie wizji projektu słowami.\n", "\n", - "Wskazane (ale nie wymagane) jest, aby w grupie znaleźli się studenci o różnych osobowościach (względem motywacji i podejścia do pracy)." + "W ten sposob tworzone są zespoły, które będą współpracować na laboratorium nr 1. \n", + "\n", + "Podczas Laboratorium 1. liderem zespołu jest osoba, która uzyskała najwyższy wynik w teście na lidera podczas wykładu. \n", + "\n", + "Zarówno składy zespołów, jak i liderzy mogą ulec zmianie do zajęć nr 3 włącznie.\n" ] }, { @@ -117,11 +65,6 @@ "Dla pozostałych członków zespołu: \n", " * Rola w zespole (deweloper, bibliotekarz, grafik itp.),\n", " * Typ motywacji i podejścia do zadań (np. A1) według klasyfikacji podanej na wykładzie.\n", - " \n", - "Opiekun zespołu\n", - " * Jeśli praca związana jest z projektem mgr, to opiekunem automatycznie zostaje opiekun projektu mgr.\n", - " * Jeśli praca nie jest związana z projektem mgr, to opiekunem moze zostać dowolny pracownik WMI UAM, jeśli wyrazi zgodę.\n", - " * W pozostałych wypadkach opiekunem pozostaje wykładowca.\n", " \n", "Maksymalna ocena: 5 punktów" ] @@ -137,7 +80,7 @@ "\n", "Następnie każdy student indywidualnie szkicuje wizję projektu na kartce (w postaci interfejsu użytkownika lub schematu działania) i opisuje działanie systemu za pomocą 3-5 zdań. \n", "\n", - "Rezultat: Tyle dokumentów, ilu jest studentów w grupie. Kartki najlepiej sfotografować i umieścić w systemie ustalnym z opiekunem (np. Google Drive, Teams).\n", + "Rezultat: Tyle dokumentów, ilu jest studentów w grupie. Kartki najlepiej sfotografować i umieścić w systemie Teams.\n", " \n", "Maksymalna ocena: 10 punktów" ] diff --git a/materiały na laboratorium/02_projekt_badawczo-rozwojowy_lab.ipynb b/materiały na laboratorium/02_innowacyjny projekt informatyczny_lab.ipynb similarity index 100% rename from materiały na laboratorium/02_projekt_badawczo-rozwojowy_lab.ipynb rename to materiały na laboratorium/02_innowacyjny projekt informatyczny_lab.ipynb diff --git a/materiały na laboratorium/03_prezentacja_koncepcji_projektuBR_lab.ipynb b/materiały na laboratorium/03_prezentacja_koncepcji_projektu_lab.ipynb similarity index 100% rename from materiały na laboratorium/03_prezentacja_koncepcji_projektuBR_lab.ipynb rename to materiały na laboratorium/03_prezentacja_koncepcji_projektu_lab.ipynb diff --git a/materiały na laboratorium/04_prezentacje_publiczne_lab — kopia.ipynb b/materiały na laboratorium/04_prezentacje_publiczne_lab.ipynb similarity index 100% rename from materiały na laboratorium/04_prezentacje_publiczne_lab — kopia.ipynb rename to materiały na laboratorium/04_prezentacje_publiczne_lab.ipynb diff --git a/materiały na laboratorium/05_metodyki_Prince2_i_zwinne.ipynb b/materiały na laboratorium/05_metodyki_zwinne.ipynb similarity index 100% rename from materiały na laboratorium/05_metodyki_Prince2_i_zwinne.ipynb rename to materiały na laboratorium/05_metodyki_zwinne.ipynb diff --git a/materiały na laboratorium/13_aspekty_użyteczności_lab.ipynb b/materiały na laboratorium/11_aspekty_użyteczności_lab.ipynb similarity index 100% rename from materiały na laboratorium/13_aspekty_użyteczności_lab.ipynb rename to materiały na laboratorium/11_aspekty_użyteczności_lab.ipynb diff --git a/materiały na laboratorium/11_ocena_jakości_systemu_lab.ipynb b/materiały na laboratorium/12_ocena_jakości_systemu_lab.ipynb similarity index 100% rename from materiały na laboratorium/11_ocena_jakości_systemu_lab.ipynb rename to materiały na laboratorium/12_ocena_jakości_systemu_lab.ipynb diff --git a/materiały na laboratorium/12_planowanie_prac_badawczo-rozwojowych_lab.ipynb b/materiały na laboratorium/13_planowanie_prac_badawczo-rozwojowych_lab.ipynb similarity index 100% rename from materiały na laboratorium/12_planowanie_prac_badawczo-rozwojowych_lab.ipynb rename to materiały na laboratorium/13_planowanie_prac_badawczo-rozwojowych_lab.ipynb diff --git a/materiały na laboratorium/04_05_kody_źródłowe_kryteria.ipynb b/materiały na laboratorium/kody_źródłowe _materialy dodatkowe.ipynb similarity index 100% rename from materiały na laboratorium/04_05_kody_źródłowe_kryteria.ipynb rename to materiały na laboratorium/kody_źródłowe _materialy dodatkowe.ipynb diff --git a/materiały na wykład/.ipynb_checkpoints/01_praca_zespolowa-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/01_praca_zespolowa-checkpoint.ipynb index 6100c9d..cde8124 100644 --- a/materiały na wykład/.ipynb_checkpoints/01_praca_zespolowa-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/01_praca_zespolowa-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

1. Praca zespołowa[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -18,7 +18,7 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "# Praca zespołowa w projekcie badawczo-rozwojowym\n", + "# Praca zespołowa w projekcie informatycznym\n", "## Cele wykładu\n", "1. Stworzenie zespołów projektowych\n", "2. Zapewnienie dobrej współpracy w zespołach\n", @@ -263,7 +263,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "01. Praca zespołowa[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/02_projekt_badawczo-rozwojowy.ipynb b/materiały na wykład/.ipynb_checkpoints/02_innowacyjny_projekt_informatyczny-checkpoint.ipynb similarity index 91% rename from materiały na wykład/02_projekt_badawczo-rozwojowy.ipynb rename to materiały na wykład/.ipynb_checkpoints/02_innowacyjny_projekt_informatyczny-checkpoint.ipynb index 377e9c2..f79e368 100644 --- a/materiały na wykład/02_projekt_badawczo-rozwojowy.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/02_innowacyjny_projekt_informatyczny-checkpoint.ipynb @@ -1,14 +1,25 @@ { "cells": [ { - "cell_type": "markdown", + "cell_type": "code", + "execution_count": 2, "metadata": {}, + "outputs": [ + { + "ename": "SyntaxError", + "evalue": "invalid syntax (, line 2)", + "output_type": "error", + "traceback": [ + "\u001b[1;36m File \u001b[1;32m\"\"\u001b[1;36m, line \u001b[1;32m2\u001b[0m\n\u001b[1;33m
\u001b[0m\n\u001b[1;37m ^\u001b[0m\n\u001b[1;31mSyntaxError\u001b[0m\u001b[1;31m:\u001b[0m invalid syntax\n" + ] + } + ], "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", - "

2. Projekt badawczo-rozwojowy[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Systemy Informatyczne

\n", + "

2. Innowacyjny projekt informatyczny[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -18,25 +29,13 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "## Działalność badawczo-rozwojowa\n", - "> Działalność badawczo-rozwojowa to działalność **twórcza** \n", - "obejmująca **badania naukowe** lub **prace rozwojowe**, \n", - "podejmowana w **sposób systematyczny** \n", - "w celu **zwiększenia zasobów wiedzy** \n", - "oraz wykorzystania zasobów do **tworzenia nowych zastosowań**." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "## Definicja projektu badawczo-rozwojowego\n", - "Projekt badawczo-rozwojowy to system działań składający się z: \n", - "- zakresu projektu, \n", + "## Definicja projektu\n", + "Projekt to system działań składający się z: \n", + "- zakresu działań, \n", "- terminu realizacji, \n", "- zasobów potrzebnych do realizacji projektu (ludzie, kapitał, wiedza, technologia).\n", "\n", - "Projekt badawczo-rowojowy charakteryzuje się następującymi cechami: \n", + "Projekt innowacyjny charakteryzuje się następującymi cechami: \n", " - niepowtarzalność,\n", " - złożoność,\n", " - identyfikowalność." @@ -85,7 +84,7 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "## Poziomy gotowości technologicznej projektu B+R\n", + "## Poziomy gotowości technologicznej\n", "\n", "### Poziom 1.\n", "Rozpoczęto badania naukowe (np. zdefiniowano tematu pracy mgr).\n", @@ -119,7 +118,7 @@ "metadata": {}, "source": [ "# Produkt High-Tech\n", - "Oczekuje się, że wynikiem projektu badawczo-rozwojowego w informatyce jest produkt High-Tech.\n", + "Oczekuje się, że wynikiem innowacyjnego projektu badawczo-rozwojowego w informatyce jest produkt High-Tech.\n", "\n", "## Czym jest produkt High-Tech?\n", "\n", @@ -300,7 +299,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "02. Projekt badawczo-rozwojowy[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/03_prezentacja_koncepcji_projektuBR.ipynb b/materiały na wykład/.ipynb_checkpoints/03_prezentacja_koncepcji_projektu-checkpoint.ipynb similarity index 98% rename from materiały na wykład/03_prezentacja_koncepcji_projektuBR.ipynb rename to materiały na wykład/.ipynb_checkpoints/03_prezentacja_koncepcji_projektu-checkpoint.ipynb index 381b3cb..c27d1e5 100644 --- a/materiały na wykład/03_prezentacja_koncepcji_projektuBR.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/03_prezentacja_koncepcji_projektu-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", - "

3. Prezentacja koncepcji projektu B+R[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Systemy informatyczne

\n", + "

3. Prezentacja koncepcji projektu[wykład]

\n", + "

3. Krzysztof Jassem[wykład]

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -407,7 +407,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "03. Prezentacja koncepcji projektu B+R[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/04_metodologia_prince2-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/04_metodologia_prince2-checkpoint.ipynb index 4555d1b..adf734d 100644 --- a/materiały na wykład/.ipynb_checkpoints/04_metodologia_prince2-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/04_metodologia_prince2-checkpoint.ipynb @@ -6,9 +6,8 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", - "

4. Metodologia Prince2[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Systemy informatyczne

\n", + "

0. Metodologia Prince2[wykład]

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -1009,7 +1008,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "04. Metodologia Prince 2[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/04_metodyki zwinne-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/04_metodyki zwinne-checkpoint.ipynb new file mode 100644 index 0000000..74ad537 --- /dev/null +++ b/materiały na wykład/.ipynb_checkpoints/04_metodyki zwinne-checkpoint.ipynb @@ -0,0 +1,622 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy informatyczne

\n", + "

4. Metodyki adaptacyjne w programowaniu[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Metodyki adaptacyjne w programowaniu (Agile Software Development)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + " Agile (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Manifest Agile\n", + " * opublikowany w roku 2001\n", + " * autorzy: 17 teoretyków i praktyków programowania\n", + " * 4 wartości\n", + " * 12 zasad (pryncypiów)\n", + " \n", + " ### 4 wartości manifestu Agile\n", + " 1. Ludzie i interakcje ponad procesy i narzędzia.\n", + " 2. Działające oprogramowanie ponad szczegółową dokumentację.\n", + " 3. Współpraca z klientem ponad negocjację umów.\n", + " 4. Reagowanie na zmiany ponad podążaniem za planem.\n", + " \n", + " ### 12 pryncypiów manifestu Agile \n", + " [12 pryncypiów](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 10 pryncypiów wg Kelly Watersa (All About Agile: Agile Management Made Easy!, 2012)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "1. Active User Involvement Is Imperative." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Nic dobrego nie wynika
\n", + "Bez udziału użytkownika.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "2. Agile Development Teams Must Be Empowered." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Nie warta praca mozołu,
\n", + "Gdy władza nie w rękach zespołu.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "3. Time waits for no man." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Czas płynie wartko jak rzeka,
\n", + "I na nikogo nie czeka.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "4. Agile Requirements Are Barely Sufficient." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Dosłownie w kilku dziś zdaniach
\n", + "Streścimy swe wymagania.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "5. How do you eat an elephant? One bite at a time." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Sekretów uchylam wieczko:
\n", + "Jedz słonia małą łyżeczką.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "6. Fast but not so furious." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Byli szybcy, lecz nie wściekli,
\n", + "I na czas produkt dowlekli.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "7. Done Means DONE!" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "Praca była \"wykonana\",
\n", + "I działało... aż do rana.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "8. Enough is enough." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Projekt ciągle się rozrasta,
\n", + "Trzeba krzyknąć: \"Stop i Basta!\"\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "9. Agile Testing Is Not For Dummies." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Wiedz, by dobrze móc testować,
\n", + "Twa głowa ma być pomysłowa.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "10. No place for snipers." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Choć mocno znów cierpi Twe ego,
\n", + "Nie strzelaj - do siebie samego.\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przykład manifestu zespołu ludzi (PWN AI)\n", + "> 1. Biznes stawia **cele**, IT daje **rozwiązania**.\n", + "> 2. Wszystko da się zrobić.\n", + "> 3. Biznes wyjaśnia **potrzeby**, IT wyjaśnia **możliwości**.\n", + "> 4. **Komunikacja i zaangażowanie** – albo wyrzucanie pieniędzy w błoto.\n", + "> 5. Wszyscy jesteśmy **elastyczni**." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Metodyka SCRUM" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Scrum jest metodyką, w której kluczowym elementem jest Sprint - faza, która kończy się działającym prototypem. Po każdym Sprincie następuje planowanie działań w kolejnym Sprincie - biorące pod uwagę dotychczasowe doświadczenia.\n", + " \n", + "
\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "Struktura metodyki Scrum opiera się na trzech filarach:\n", + "* Artefakty\n", + "* Role\n", + "* Cykl Pracy" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Artefakty w metodyce Scrum" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "
Rejestr Produktu (Product Backlog)
\n", + "\n", + " Rejestr Produktu to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.\n", + "\n", + "
    \n", + "
  1. Rejestr produktu utrzymywany jest przez Właściciela Produktu.
    2. \n", + "
  2. Zadania, których efekt widoczny jest dla użytkownika mają często postać User Story .
    3. \n", + "
  3. Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu.
    4. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "
User Story
\n", + "\n", + "> User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu (Encyklopedia Zarządzania).\n", + "\n", + "User Story ma zwykle postać: \n", + "> Jako chcę wykonać aby\n", + "\n", + "
Przykład User Story
\n", + " \n", + "> Jako klient sklepu chcę dodać produkt do koszyka aby go później kupić .\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "
Rejestr Sprintu (Sprint Backlog)
\n", + "\n", + " Rejestr Sprintu to lista Zadań do wykonania podczas Sprintu:\n", + "\n", + "
    \n", + "
  1. utrzymywana przez Zespół Deweloperski,
    2. \n", + "
  2. tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu.
    3. \n", + "
\n", + "
\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "
Zadanie (Task)
\n", + "\n", + " Zadanie w Rejestrze Sprintu zawiera następujące informacje:\n", + "\n", + "
    \n", + "
  1. opis zadania,
    2. \n", + "
  2. szacowany czas wykonania zadania,
    3. \n", + "
  3. członek zespołu odpowiedzialnego za wykonanie zadania,
    4. \n", + "
  4. status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane).
    5. \n", + "
\n", + "
\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Role w metodyce Scrum" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "
Udziałowcy (stakeholders)
\n", + "Udziałowcy to ludzie, którzy finansują projekt:\n", + "
    \n", + "
  1. właściciele firmy realizującej projekt,
    2. \n", + "
  2. klienci,
    3. \n", + "
  3. przyszli użytkownicy.
    4. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "
Właściciel Produktu (Product Owner)
\n", + "\n", + " Właściciel Produktu to rola, która reprezentuje interesy biznesu.\n", + "\n", + "
Zadania Właściciela Produktu:
\n", + "\n", + "
    \n", + "
  1. nadzoruje pisanie User Stories,
    2. \n", + "
  2. analizuje na bieżąco potrzeby biznesu i na tej podstawie...
    3. \n", + "
  3. ustala priorytet User Stories w Rejestrze Produktu,
    4. \n", + "
  4. decyduje, co jest WYKONANE.
    5. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Zespół Deweloperski (Development Team)
\n", + " \n", + "Zespół Deweloperski to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.\n", + " \n", + "
Zadania Zespołu Deweloperskiego:
\n", + "\n", + "
    \n", + "
  1. jest odpowiedzialny za implementację,
    2. \n", + "
  2. na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint,
    3. \n", + "
  3. wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu),
    4. \n", + "
  4. sam decyduje o sposobie realizacji zadań.
    5. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Scrum Master
\n", + "\n", + "Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.\n", + "\n", + "
Zadania Scrum Mastera:
\n", + "
    \n", + "
  1. prowadzi Daily (spotkanie zespołu),
    2. \n", + "
  2. prowadzi Retrospektywę,
    3. \n", + "
  3. buduje relacje w zespole,
    4. \n", + "
  4. pomaga rozwiązywać konflikty,
    5. \n", + "
  5. pośredniczy w rozmowach z Właścicielem produktu.
    6. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Cykl pracy w metodyce Scrum" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Sprint
\n", + "\n", + " Sprint to okres, podczas którego tworzy się przyrost projektu, skutkujący prototypem gotowym do użycia. Sprint zazwyczaj trwa nie krócej niż tydzień i nie dłuzej niż miesiąc.\n", + "W skład Sprintu wchodzą:\n", + "
    \n", + "
  1. Planowanie Sprintu,
    2. \n", + "
  2. Implementacja,
    3. \n", + "
  3. Codzienne spotkania,
    4. \n", + "
  4. Przegląd Sprintu,
    5. \n", + "
  5. Retrospektywa.
    6. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Planowanie Sprintu (Sprint Planning)
\n", + "\n", + " Planowanie sprintu jest pierwszym spotkaniem podczas każdego sprintu. \n", + "\n", + "
    \n", + "
  • Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu.
    • \n", + "
  • Planowanie Sprintu prowadzone jest przez Scrum Mastera.
    • \n", + "
\n", + "\n", + "
Standardowy przebieg Planowania Sprintu:
\n", + "
    \n", + "
  1. Analizy Rejestru Produktu - wybór wymagań do realizacji,
    2. \n", + "
  2. Określenie celu sprintu - na podstawie wybranych wymagań,
    3. \n", + "
  3. Określenie pełnego zakresu prac: jak będzie działał system po Sprincie,
    4. \n", + "
  4. Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań,
    5. \n", + "
  5. Estymacja pracochłonności zadań.
    6. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Codzienne Spotkania (Daily Scrum)
\n", + "\n", + " Codzienne Spotkanie (stosowana nazwa w j. polskim - Daily ) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze. \n", + "\n", + "
    \n", + "
  • W Daily bierze udział Zespół Deweloperski.
    • \n", + "
  • Daily prowadzone jest przez Scrum Mastera.
    • \n", + "
\n", + " \n", + "
Standardowy plan Daily:
\n", + "\n", + "
    \n", + "
  1. Przegląd prac w ciągu ostatniego dnia,
    2. \n", + "
  2. Omówienie pojawiających się problemów,
    3. \n", + "
  3. Omówienie planu na kolejny dzień.
    4. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Przegląd Sprintu
\n", + "\n", + " Przegląd Sprintu jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu. \n", + "\n", + "
    \n", + "
  • W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu.
    • \n", + "
  • Przegląd Sprintu prowadzony jest przez Właściciela Produktu.
    • \n", + "
\n", + " \n", + "
Standardowy plan Przeglądu Sprintu:
\n", + "\n", + "
    \n", + "
  1. Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały \"Wykonane”, a które nie.
    2. \n", + "
  2. Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano.
    3. \n", + "
  3. Zespół Deweloperski prezentuje \"Wykonaną” pracę; dyskusja.
    4. \n", + "
  4. Właściciel Produktu omawia obecny Rejestr Produktu.
    5. \n", + "
  5. Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.\n", + "
  6. Właściciel produktu aktualizuje Rejestr Produktu.\n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "
Retrospektywa Sprintu
\n", + "\n", + " Retrospektywa Sprintu to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint. \n", + "\n", + "
    \n", + "
  • W Retrospektywie udział bierze Zespół Deweloperski.
    • \n", + "
  • Retrospektywę prowadzi Scrum Master.
    • \n", + "
\n", + " \n", + "
Standardowy plan Retrospektywy:
\n", + "\n", + "
    \n", + "
  1. Sprawdzenie, co działo się w ostatnim Sprincie,
    2. \n", + "
  2. Zidentyfikowanie elementów, które sprawdziły się w działaniu,
    3. \n", + "
  3. Zidentyfikowanie elementów, które kwalifikują się do usprawnienia,
    4. \n", + "
  4. Stworzenie planu wprowadzania w życie usprawnień.
    5. \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Wniosek\n", + "Nie zrobi informatyk \n", + "Złotego interesu, \n", + "Gdy nie będzie co tydzień \n", + "Słuchał potrzeb biznesu." + ] + } + ], + "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.7.6" + }, + "subtitle": "05. Metodologia Prince2Agile[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/.ipynb_checkpoints/05_metodyki zwinne-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/05_metodyki zwinne-checkpoint.ipynb index 1d0bc7d..d1362e9 100644 --- a/materiały na wykład/.ipynb_checkpoints/05_metodyki zwinne-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/05_metodyki zwinne-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

5. Metodyki adaptacyjne w programowaniu[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -611,7 +611,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "05. Metodologia Prince2Agile[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/05_prototypowanie i ciągła integracja-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/05_prototypowanie i ciągła integracja-checkpoint.ipynb new file mode 100644 index 0000000..7f6bf5b --- /dev/null +++ b/materiały na wykład/.ipynb_checkpoints/05_prototypowanie i ciągła integracja-checkpoint.ipynb @@ -0,0 +1,479 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy informatyczne

\n", + "

5. Prototypowanie i ciągła integracja[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Prototyp

\n", + "Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Cele prototypowania\n", + " * Zademonstrowanie umiejętności wykonania produktu końcowego\n", + " * Określenie realistycznych wymagań końcowych\n", + " * Przekonanie się o wpływie innych systemów, środowisk na produkt. \n", + " * Sprawdzenie implementacji kluczowych funkcji\n", + "\n", + "## Potencjalne efekty prototypowania\n", + "* Wykrycie nieporozumień między klientem i wykonawcą \n", + "* Określenie brakujących funkcji \n", + "* Wykrycie błędów w specyfikacji\n", + "* Przewidywanie przyszłych trudności " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prototyp poziomy a pionowy\n", + "### Prototyp poziomy (Horizontal Prototype)\n", + "\n", + "**Prototyp poziomy** obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.\n", + "\n", + "Przykłady prototypów poziomych w informatyce:\n", + " * Prototyp papierowy\n", + " * Makieta statyczna\n", + " * Makieta dynamiczna\n", + " * Graficzny interfejs użytkownika" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Prototyp papierowy

\n", + " \n", + "Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. \n", + " \n", + "* Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. \n", + "* Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.\n", + "\n", + "Prototypowanie papierowe - etapy :\n", + "\n", + "
    \n", + "
  • Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności.
    • \n", + "
  • Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów.
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Makieta statyczna

\n", + " \n", + " \n", + "Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n", + "\n", + "
    \n", + "
  • Obrazuje wybrane widoki bez połączeń między nimi.
    • \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Makieta dynamiczna

\n", + " \n", + " \n", + "Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n", + "\n", + "
    \n", + "
  • Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku.
    • \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Graficzny interfejs użytkownika (GUI)

\n", + "\n", + " Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n", + " \n", + "Prototypem poziomym nazwiemy GUI, który: \n", + "
    \n", + "
  • Pokazuje menu.
    • \n", + "
  • Pozwala na nawigację.
    • \n", + "
  • Akceptuje input.
    • \n", + "
  • Wyświetla losowy output.
    • \n", + "
  • NIE wspiera logiki aplikacji.
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Prototyp pionowy (Vertical Prototype)\n", + "**Prototyp pionowy** to pełna realizacja kluczowej (kluczowych) funkcji systemu.\n", + "\n", + "Cele prototypowania pionowego:\n", + "* sprawdzenie wyboru technologii\n", + "* pomiary wydajności\n", + "* sprawdzenie poprawności algorytmów i struktur danych\n", + "\n", + "Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prototypowanie z porzuceniem a prototypowanie ewolucyjne" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Prototypowanie z porzuceniem (Thow-away Prototyping)\n", + "\n", + "W **prototypowaniu z porzuceniem** budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.\n", + "\n", + "Cele prototypowania z porzuceniem:\n", + "* minimalizacja ryzyka,\n", + "* głębokie zrozumienie problemów technicznych\n", + "\n", + "Koszty:\n", + " * Koszty prototypowania z porzuceniem są wysokie." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Prototypowanie ewolucyjne (Ewolutionary Prototyping)\n", + "\n", + "**Prototypowanie ewolucyjne** polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania... \n", + "\n", + "...Wtedy prototyp staje się produktem.\n", + "\n", + "Prototyp ewolucyjny powinien być budowany:\n", + " * w środowisku zbliżonym do produkcyjnego, \n", + " * z dużą dbałością o jakość." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prototypowanie - podsumowanie\n", + "\n", + "* Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu. \n", + "* W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji. \n", + "* W prototypach pionowych chodzi o szczegóły techniczne.\n", + "* Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome); \n", + " * jest bardziej kosztowne, ale minimalizuje ryzyko.\n", + "* Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe); \n", + " * jest mniej kosztowne, ale bardziej ryzykowne." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Ciągła integracja

\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "
    \n", + "
  • zmiany w kodzie są regularnie przesyłane do centralnego repozytorium,
    • \n", + "
  • po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy.
    • \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Główne przesłanki CI

\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "
    \n", + "
  • szybsze lokalizowanie błędów w kodzie,
    • \n", + "
  • ciągły wzrost jakości oporgramowania,
    • \n", + "
  • szybkie wydawanie nowych wersji.
    • \n", + "
\n", + "
\n", + "\n", + " \n", + "\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przebieg pracy w Ciągłej Integracji\n", + "1. **Take Integrated Code**\n", + " * Pobieram kod z repozytorium.\n", + " * Instaluję kopię na swojej stacji roboczej. \n", + " \n", + "2. **Do Your Part**\n", + " * Opracowuję nowy kod.\n", + " * Opracowuję nowe testy jednostkowe.\n", + " \n", + "3. **Build on your machine**\n", + "\n", + " * **Repeat** \n", + " * Kompiluję swój kod i buduję wersję wykonywalną,\n", + " * Przeprowadzam testy jednostkowe,\n", + " * **Until**\n", + " * Kod się skompilował poprawnie oraz\n", + " * Testy zakończyły się powodzeniem.\n", + " \n", + "4. **Integrate with Repository**\n", + "\n", + " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n", + " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n", + " * **Go back to: Take Integrated Code**\n", + " * Przypadek 2. Tetsy się powodzą\n", + " * **Continue**\n", + " \n", + "5. **End Session**\n", + " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Dobre praktyki Ciągłej Integracji\n", + "(wg https://www.martinfowler.com/articles/continuousIntegration.html)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Maintain a Single Source Repository\n", + " * Załóż mainline (linię główną): \n", + " * Deweloperzy powinni większość pracy składać na mainline.\n", + " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n", + " * naprawy błędów,\n", + " * tymczasowych eksperymentów,\n", + " * oznaczania wersji publikowalnych.\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Automate the Build\n", + " * Wersja wykonywalna powinna być tworzona jednym poleceniem.\n", + " * Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Test Yourself\n", + " * Pisz testy jednostkowe.\n", + " * Uruchamiaj testy po każdej kompilacji." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Everyone Commits Everyday\n", + " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n", + " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n", + " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n", + " * Postulat wymaga rozbicia projektu na małe kawałki." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Every Commit Should Build the Mainline\n", + " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n", + " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Fix the Broken Builds Immediately\n", + "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n", + "Znalezienie i poprawienie blędu jest priorytetem, ale:\n", + " * Nie debugguj kodu na centralnym repozytorium. \n", + " * Przywróć wersję wykonywalną na \"mainline\".\n", + " * Debugguj kod na maszynie lokalnej." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Make it Easy to Run the Latest Executable\n", + "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n", + "* Jest to niezbędne do:\n", + " * testowania integracyjnego (tester),\n", + " * rozmów z klientem (zarząd lub sprzedawca),\n", + " * prowadzenia projektu (kierownik zespołu).\n", + "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Keep the Build Fast\n", + "\n", + " * Maximum 10 minut na build + testy.\n", + " * A jeśli testy trwają dłużej?\n", + " * Testy dwuetapowe:\n", + " * kompilacja + testy jednostkowe przy każdym commicie,\n", + " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Clone the Environment\n", + " * Przygotuj klon środowiska produkcyjnego:\n", + " * ta sama wersja systemu operacyjnego\n", + " * ta sama baza danych\n", + " * te same biblioteki (nawet jak ich nie potrzebujesz) \n", + " * Wszystkie testy przeprowadzaj na przygotowanym środowisku." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Everyone Can See What's Happening\n", + "System powinien informować użytkowników o swoim statusie." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Automate Deployment\n", + " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n", + " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Narzędzia Ciągłej Integracji\n", + "\n", + "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n", + "\n", + "1. Jenkins\n", + "2. Circle CI\n", + "3. Team City\n", + "4. Bamboo\n", + "5. GitLab" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Korzyści z Ciągłej Integracji\n", + " * Minimalizacja ryzyka\n", + " * Łatwiejsze szacowanie terminu zakończenia prac\n", + " * Szybsza lokalizacja i naprawa błędów\n", + " * Świadomość stanu prac u całego zespołu\n", + " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n", + " * Możliwość pracy w środowisku rozproszonym\n", + " * Możliwość usunięcia bariery między wykonawcą i klientem" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przykład - Jenkins\n", + "\n", + "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n", + "\n" + ] + } + ], + "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.7.6" + }, + "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/.ipynb_checkpoints/06_prototypowanie i ciągła integracja-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/06_prototypowanie i ciągła integracja-checkpoint.ipynb index 0c2b68f..f1a6b4f 100644 --- a/materiały na wykład/.ipynb_checkpoints/06_prototypowanie i ciągła integracja-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/06_prototypowanie i ciągła integracja-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

6. Prototypowanie i ciągła integracja[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -242,6 +242,13 @@ "\n" ] }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")" + ] + }, { "cell_type": "markdown", "metadata": {}, @@ -257,12 +264,12 @@ " \n", "3. **Build on your machine**\n", "\n", - "* **Repeat** \n", - " * Kompiluję swój kod i buduję wersję wykonywalną,\n", - " * Przeprowadzam testy jednostkowe,\n", - "* **Until**\n", - " * Kod się skompilował poprawnie oraz\n", - " * Testy zakończyły się powodzeniem.\n", + " * **Repeat** \n", + " * Kompiluję swój kod i buduję wersję wykonywalną,\n", + " * Przeprowadzam testy jednostkowe,\n", + " * **Until**\n", + " * Kod się skompilował poprawnie oraz\n", + " * Testy zakończyły się powodzeniem.\n", " \n", "4. **Integrate with Repository**\n", "\n", @@ -430,6 +437,16 @@ " * Możliwość pracy w środowisku rozproszonym\n", " * Możliwość usunięcia bariery między wykonawcą i klientem" ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przykład - Jenkins\n", + "\n", + "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n", + "\n" + ] } ], "metadata": { @@ -451,7 +468,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb index a151ae0..4310913 100644 --- a/materiały na wykład/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/07_specyfikacja_projektu_informatycznego-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

7. Specyfikacja projektu informatycznego[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -170,7 +170,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -193,7 +192,7 @@ "### Wymaganie systemowe\n", "**Wymagania systemowe** to sformalizowany opis oczekiwań względem systemu.\n", " * Skierowane są do:\n", - " * inżynierów zamwiającego,\n", + " * inżynierów zamawiającego,\n", " * twórców oprogramowania, \n", " * architektów systemu. \n", " \n", @@ -203,7 +202,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -219,7 +217,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -247,7 +244,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -271,7 +267,7 @@ "## Elementy składowe opisu przypadku użycia \n", "1. Wykonawca główny (który rozpoczyna wykonanie przypadku użycia)\n", "2. Poziom celu\n", - "3. Warunkie początkowe\n", + "3. Warunki początkowe\n", "4. Wyzwalacz\n", "5. Gwarancje minimalne\n", "6. Gwarancja powodzenia\n", @@ -280,7 +276,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -300,7 +295,7 @@ "\"Przykład\n", "\n", "#### Poziom użytkownika\n", - "Przypadki użycia o poziomie użytkownika opisują cel, który chce osiągnąć aktor główny, żeby wykonać swoje zadanie. \n", + "Przypadki użycia o poziomie użytkownika opisują cel, który chce osiągnąć wykonawca główny, żeby wykonać swoje zadanie. \n", " * Najczęściej spełniają warunek: „jedna osoba i jedno krótkie posiedzenie”.\n", " * Przypadki te są najbardziej warte opisania w specyfikacji.\n", " \n", @@ -318,7 +313,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -333,7 +327,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -346,13 +339,12 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ "### 3.4. Przypadek użycia. Gwarancje minimalne\n", "**Gwarancje minimalne** to najmniejsze obietnice składane przez system.\n", - " * Są realizowane zarówno wtedy, gdy cel aktora głównego jest spełniony (scenariusz powodzenia) i gdy nie jest on spełniony. (Szczególnie w tym drugim przypadku minimalne gwarancje są istotne).\n", + " * Są realizowane zarówno wtedy, gdy cel wykonawcy głównego jest spełniony (scenariusz powodzenia) i gdy nie jest on spełniony. (Szczególnie w tym drugim przypadku minimalne gwarancje są istotne).\n", " * Zapisywane są w postaci kilku stwierdzeń, które będą na pewno prawdziwe po zakończeniu przypadku użycia.\n", " \n", " Przykłady gwarancji minimalnych:\n", @@ -360,7 +352,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -375,39 +366,38 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ "### 3.6. Przypadek użycia. Scenariusz powodzenia\n", "**Scenariusz powodzenia** to ciąg akcji od rozpoczęcia do zakończenia przypadku użycia, który realizuje gwarancje powodzenia.\n", - "Scenariusz powodzenia opisuje najbardziej typowe zachowanie systemu i nie bierze pod uwagę zdarzeń niesprzyjających.\n", - "#### Wskazówki przy pisaniu scenariusza powodzenia\n", + "Scenariusz powodzenia opisuje najbardziej typowe zachowanie systemu i nie bierze pod uwagę zdarzeń niesprzyjających. \n", "\n", - "##### 1. Używaj prostych składni zdań\n", + "**Wskazówki przy pisaniu scenariusza powodzenia:**\n", + "\n", + "#### 1. Używaj prostych składni zdań\n", "\"Przykład\n", "\n", - "##### 2. Jasno i jednoznacznie wskaż podmiot czynności\n", + "#### 2. Jasno i jednoznacznie wskaż podmiot czynności\n", "\"Przykład\n", "\n", - "##### 3. Pisz \"z lotu ptaka\"\n", + "#### 3. Pisz \"z lotu ptaka\"\n", "\"Przykład\n", "\n", - "##### 4. Przesuwaj proces wyraźnie do przodu\n", + "#### 4. Przesuwaj proces wyraźnie do przodu\n", "\"Przykład\n", "\n", - "##### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n", + "#### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n", "\"Przykład\n", "\n", - "##### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n", + "#### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n", "\"Przykłady\n", "\n", - "##### 7. Stosuj iteracje, jeśli jest taka potrzeba\n", + "#### 7. Stosuj iteracje, jeśli jest taka potrzeba\n", "\"Przykłady" ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -433,15 +423,14 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ "# Podsumowanie - jak stworzyć specyfikację systemu informatycznego?\n", " 1. Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu \n", " 2. Charakterystyka wykonawców \n", - " 3. Lista „wykonawca-cel” \n", - " 4. Lista „in-out” \n", + " 3. Lista „Wwykonawca-Cel” \n", + " 4. Lista „In-Out” \n", " 5. Wymagania funkcjonalne \n", " 6. Wymaganie niefunkcjonalne \n", " 7. Opis przypadków użycia " @@ -467,7 +456,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "07. Specyfikacja projektu informatycznego[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb index c5e8f69..d505b24 100644 --- a/materiały na wykład/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/08_testowanie_w_programowaniu_zwinnym-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

8. Testowanie w programowaniu zwinnym[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -298,8 +298,12 @@ " * Prostej instrukcji do testera\n", " * Scenariusza przypadku testowego\n", " \n", - "**Przykład opisu przypadków testowych logowania do systemu:**\n", - "\"Opis" + "**Przykład opisu przypadków testowych z prostą instrukcją:**\n", + "\"Opis\n", + "\n", + " \n", + "**Przykład opisu przypadku testowego ze scenariuszem:**\n", + "\"Opis" ] }, { @@ -350,7 +354,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -364,7 +367,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -375,7 +377,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -392,7 +393,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -417,7 +417,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -434,7 +433,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ diff --git a/materiały na wykład/.ipynb_checkpoints/09_testowanie_systemowe_i_akceptacyjne-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/09_testowanie_systemowe_i_akceptacyjne-checkpoint.ipynb index 1bab75c..46409a4 100644 --- a/materiały na wykład/.ipynb_checkpoints/09_testowanie_systemowe_i_akceptacyjne-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/09_testowanie_systemowe_i_akceptacyjne-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", - "

9. Testowanie systemowe i adaptacyjne[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Systemy informatyczne

\n", + "

9. Testowanie systemowe i akceptacyjne[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -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": [ "
\n", - "

Testowanie adaptacyjne

\n", + "

Testowanie akceptacyjne

\n", " \n", - "Przedmiotem testowania adaptacyjnego jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy.\n", + "Przedmiotem testowania akceptacyjnego 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", "
" @@ -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", "\"Przykład" ] }, @@ -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", "\"Przykład" ] }, @@ -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", - "\"Przykład" + "\"Przykład" ] }, { @@ -133,15 +133,33 @@ "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": [ + "
\n", + "

Przeciążenie

\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", + "
" + ] + }, + { + "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", "\"Przykład\n", @@ -188,7 +206,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -199,7 +216,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -208,7 +224,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -220,12 +235,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 +264,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -262,7 +275,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -279,11 +291,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 +302,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 +313,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -351,7 +347,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -366,7 +361,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -377,7 +371,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -395,7 +388,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -412,7 +404,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -421,7 +412,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -453,7 +443,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "09. Testowanie integracyjne i systemowe[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/11_aspekty_użyteczności-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/11_aspekty_użyteczności-checkpoint.ipynb index 1e2cbaa..84b6507 100644 --- a/materiały na wykład/.ipynb_checkpoints/11_aspekty_użyteczności-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/11_aspekty_użyteczności-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

11. Aspekty użyteczności[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -681,7 +681,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "11. Aspekty użyteczności[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/11_wybrane_zagadnienia_użyteczności-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/11_wybrane_zagadnienia_użyteczności-checkpoint.ipynb new file mode 100644 index 0000000..ccef61a --- /dev/null +++ b/materiały na wykład/.ipynb_checkpoints/11_wybrane_zagadnienia_użyteczności-checkpoint.ipynb @@ -0,0 +1,561 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy informatyczne

\n", + "

10. Wybrane zagadnienia użyteczności[wykład]

\n", + "

Krzysztof Jassem (2021)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# 1. Pojęcie użyteczności" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Użyteczność

\n", + "\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", + "

Cechy aplikacji użytecznej

\n", + " \n", + "
    \n", + "
  • Łatwa do nauki: Jak łatwo jest użytkownikom wykonać dane zadanie po raz pierwszy?\n", + "
  • Wydajna w pracy: Jak szybko użytkownicy wykonują zadania, gdy już się nauczyli programu?\n", + "
  • Satysfakcja: Czy korzystanie z programu daje satysfakcję?\n", + "
  • Odporna na błędy: Ile błędów robią użytkownicy, jak poważne są to błędy i jak łatwo z nich się wydostać?\n", + "
  • Zapamiętywalna po czasie: Jak łatwo powrócić do biegłości użytkowania po pewnym okresie nieużytkowania programu?\n", + "\n", + "
" + ] + }, + { + "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\"" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Przeczytaj w Internecie\n", + "\n", + "
    \n", + " \n", + "
  1. Usability Means…
    2. \n", + "\n", + "
  2. Web applications should explain themselves.
    3. \n", + "\n", + "
  3. Don’t Make Me Think
    4. \n", + "\n", + "
  4. Don’t waste my time
    5. \n", + " \n", + "
  5. Users still cling to their back buttons
    6. \n", + "\n", + "
  6. We’re creatures of habit
    7. \n", + "\n", + "
  7. No Time for Small Talk
    8. \n", + "\n", + "
  8. Don’t lose search
    9. \n", + "\n", + "
  9. We form mental site-maps
    10. \n", + "\n", + "
  10. Make it easy to go home
    11. \n", + " \n", + "
\n", + "\n", + "
\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 2.2. Podejście (bardziej) współczesne" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki do tworzenia użytecznego systemu informatycznego

\n", + "\n", + "
    \n", + "
  1. Autorze: Poznaj użytkownika, a TY nie jesteś użytkownikiem.
    2. \n", + "
  2. Użytkownik powinien mieć kontrolę nad systemem, a nie odwrotnie: to użytkownik jest szefem i system powinien to okazywać.
    3. \n", + "
  3. System musi ułatwiać użytkownikowi życie:
    4. \n", + "
      \n", + "
    • Elementy, które wyglądają tak samo, powinny działać tak samo, a akcje, które nie działają tak samo powinny być inaczej reprezentowane.
      • \n", + "
    • Każda akcja użytkownika powinna mieć reakcję programu.
      • \n", + "
    • Kiedy użytkownik ma do podjęcia decyzję, system podaje mu całą dostępną informację.
      • \n", + "
    \n", + "
  4. System musi być \"idioto-odporny\":
    5. \n", + "
      \n", + "
    • Każdy robi błędy, więc każdy błąd powinien dać się naprawić.
      • \n", + "
    • Gdy użytkownik zrobi błąd, System daje mu o tym znać, zanim … wpadnie w PRAWDZIWE kłopoty.
      • \n", + "
    • Informacje o błędach powinny być zrozumiałe dla użytkownika i mówić mu, jak naprawić problem.
      • \n", + "
    \n", + "
  5. Wczuj się w użytkownika
    6. \n", + "
      \n", + "
    • Eliminuj niepotrzebne decyzje (nie pytaj, jak nie musisz).
      • \n", + "
    • Im mniej kroków do celu, tym lepiej.
      • \n", + "
    • Użytkownik powinien zawsze móc dowiedzieć się, co robić dalej.
      • \n", + "
    • Użytkownik powinien zawsze wiedzieć, co się dzieje.\n", + "
    \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 3. Zasady dobrej nawigacji na portalu internetowym\n", + "### 3.1. Pojęcie nawigacji" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + " Nawigacja 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", + "
    \n", + "
  • Menu główne
    • \n", + "
  • Menu narzędziowe
    • \n", + "
  • Identyfikator witryny
    • \n", + "
  • Wyszukiwarka
    • \n", + "
  • Odsyłacz do strony startowej (zawarty w logo)
    • \n", + "
  • Flagi narodowe (przełączenie języków)
    • \n", + "
\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 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" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Zasada 1. Widoczność\n", + "Wszystkie elementy nawigacji muszą być bardzo dobrze widoczne na każdej stronie i podstronie serwisu." + ] + }, + { + "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. " + ] + }, + { + "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." + ] + }, + { + "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." + ] + }, + { + "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." + ] + }, + { + "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" + ] + }, + { + "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/)" + ] + }, + { + "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/" + ] + }, + { + "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" + ] + }, + { + "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." + ] + }, + { + "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" + ] + }, + { + "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": "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." + ] + }, + { + "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." + ] + }, + { + "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." + ] + } + ], + "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.7.6" + }, + "subtitle": "10. Wybrane zagadnienia użyteczności[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/.ipynb_checkpoints/12_ocena_jakości_systemu-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/12_ocena_jakości_systemu-checkpoint.ipynb index b17444c..21a8eee 100644 --- a/materiały na wykład/.ipynb_checkpoints/12_ocena_jakości_systemu-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/12_ocena_jakości_systemu-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

12. Ocena jakości systemu informatycznego[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -143,6 +143,7 @@ "Przykłady:\n", "\n", "\n", + " \n", " \n", " \n", "\n", @@ -195,8 +196,10 @@ "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", - " \"Tablica\n", - " źródło: Adam Roman, \"Testowanie i jakość oprogramowania\"\n", + "
\n", + "\"Tablica\n", + "
Tablica produktywności. Źródło: Adam Roman, \"Testowanie i jakość oprogramowania\"
\n", + "
\n", "\n", "[Porównaj w Internecie](https://www.qsm.com/resources/function-point-languages-table)" ] @@ -214,13 +217,17 @@ " \n", "Wartości metryk Halsteada (w przeciwieństwie do LOC) nie zależą od długości przyjętego nazewnictwa.\n", "\n", + "
\n", "\"Liczby\n", - "źródło: Wikipedia\n", + "
Liczby tokenów. Źródło: wikipedia
\n", + "
\n", "\n", "Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n", "\n", + "
\n", "\"wielkość\n", - "źrodło: Wikipedia" + "
Objętość programu. Źródło: wikipedia
\n", + "
" ] }, { @@ -241,8 +248,10 @@ " * E: wysiłek implementacji,\n", " * T: czas implementacji\n", " * B: liczba błędów.\n", + "
\n", "\"metryki\n", - "żródło: Wikipedia" + "
Metryki złożoności Halsteada. Źródło: wikipedia
\n", + "
" ] }, { @@ -276,7 +285,7 @@ "\n", "Metryka uwzględnia zarówno liczbę metod w klasie, jak i ich złożoność cyklomatyczną: (n oznacza liczbę metod w klasie, a ci oznacza złożoność cykolomatyczną i-tej metody).\n", "\n", - "\"Uśrednione" + "\"Uśrednione" ] }, { @@ -405,6 +414,7 @@ "* Przykładowe wartości metryki dostępności:\n", "\n", "
Jak mierzyć liczbę wierszy w metryce LOC
Decyzja Rekomendacja
\n", + " \n", " \n", " \n", "\n", @@ -503,9 +513,10 @@ " * brak związku między cechami.\n", " \n", "Przykłady korelacji: \n", - "\n", + "
\n", "\"korelacja\n", - "źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/" + "
źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/
\n", + "
" ] }, { @@ -515,8 +526,10 @@ "## 6.2. Korelacja między właściwościami oprogramowania\n", "Korelację między poszczególnymi właściwościami oprogramowania obrazuje tabela:\n", "\n", + "
\n", "\"Korelacja\n", - "źródło: opracowanie własne na podstawie: Stephen H. Kan \"Metryki i modele w inżynierii jakości oprogramowania\"\n", + "
Korelacje między właściwościami oprogramowania źródło: opracowanie własne na podstawie: Stephen H. Kan \"Metryki i modele w inżynierii jakości oprogramowania\"
\n", + "
\n", "\n", "Tabela wskazuje, że polepszenie jednej cechy oprogramowania (np. przydatności funkcjonalnej) może pogorszyć inną cechę (np. wydajność), bo cechy te są ujemnie skorelowane." ] @@ -602,7 +615,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "12. Ocena jakości systemu informatycznego[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/12_planowanie prac badawczo-rozwojowych.ipynb b/materiały na wykład/.ipynb_checkpoints/13_planowanie prac badawczo-rozwojowych-checkpoint.ipynb similarity index 99% rename from materiały na wykład/12_planowanie prac badawczo-rozwojowych.ipynb rename to materiały na wykład/.ipynb_checkpoints/13_planowanie prac badawczo-rozwojowych-checkpoint.ipynb index 3042e5d..0ed97e5 100644 --- a/materiały na wykład/12_planowanie prac badawczo-rozwojowych.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/13_planowanie prac badawczo-rozwojowych-checkpoint.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

13. Planowanie prac badawczo-rozwojowych[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -728,7 +728,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "13. Planowanie prac badawczo-rozwojowych[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/15_demonstracja_projektu-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/15_demonstracja_projektu-checkpoint.ipynb index 473c78b..d06b28c 100644 --- a/materiały na wykład/.ipynb_checkpoints/15_demonstracja_projektu-checkpoint.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/15_demonstracja_projektu-checkpoint.ipynb @@ -6,22 +6,13 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

15. Demonstracja wyników projektu badawczo-rozwojowego [wykład]

\n", "

Krzysztof Jassem (2021)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "
\n", - "Demonstrowane projekty powinny być na 6. poziomie gotowości technologicznej.\n", - "
" - ] } ], "metadata": { @@ -43,7 +34,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "15. Demonstracja projektu[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/01_praca_zespolowa.ipynb b/materiały na wykład/01_praca_zespolowa.ipynb index 321f4c9..cde8124 100644 --- a/materiały na wykład/01_praca_zespolowa.ipynb +++ b/materiały na wykład/01_praca_zespolowa.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

1. Praca zespołowa[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -18,7 +18,7 @@ "cell_type": "markdown", "metadata": {}, "source": [ - "# Praca zespołowa w projekcie badawczo-rozwojowym\n", + "# Praca zespołowa w projekcie informatycznym\n", "## Cele wykładu\n", "1. Stworzenie zespołów projektowych\n", "2. Zapewnienie dobrej współpracy w zespołach\n", diff --git a/materiały na wykład/02_innowacyjny_projekt_informatyczny.ipynb b/materiały na wykład/02_innowacyjny_projekt_informatyczny.ipynb new file mode 100644 index 0000000..f79e368 --- /dev/null +++ b/materiały na wykład/02_innowacyjny_projekt_informatyczny.ipynb @@ -0,0 +1,310 @@ +{ + "cells": [ + { + "cell_type": "code", + "execution_count": 2, + "metadata": {}, + "outputs": [ + { + "ename": "SyntaxError", + "evalue": "invalid syntax (, line 2)", + "output_type": "error", + "traceback": [ + "\u001b[1;36m File \u001b[1;32m\"\"\u001b[1;36m, line \u001b[1;32m2\u001b[0m\n\u001b[1;33m
\u001b[0m\n\u001b[1;37m ^\u001b[0m\n\u001b[1;31mSyntaxError\u001b[0m\u001b[1;31m:\u001b[0m invalid syntax\n" + ] + } + ], + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy Informatyczne

\n", + "

2. Innowacyjny projekt informatyczny[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Definicja projektu\n", + "Projekt to system działań składający się z: \n", + "- zakresu działań, \n", + "- terminu realizacji, \n", + "- zasobów potrzebnych do realizacji projektu (ludzie, kapitał, wiedza, technologia).\n", + "\n", + "Projekt innowacyjny charakteryzuje się następującymi cechami: \n", + " - niepowtarzalność,\n", + " - złożoność,\n", + " - identyfikowalność." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przykład projektu badawczo-rozwojowego: AI Searcher\n", + "\n", + "### Definicja projektu:\n", + "System działań mających na celu stworzenie systemu informatycznego wspomagającego pracowników Polskiej Straży Granicznej. \n", + "\n", + "\n", + "### Zakres projektu: \n", + "System informatyczny wdrożony w siedzibie Straży Granicznej, który ma pomagać w znajdowaniu treści przestępczych w Internecie. \n", + "System realizuje następujący scenariusz działania:\n", + " 1. Pracownik Straży Granicznej wpisuje zapytanie.\n", + " 2. Moduł Rozszerzania Zapytań rozszerza zapytanie na zestaw kwerned do wyszukiwarek internetowych.\n", + " 3. Translator tłumaczy kwerendy na języki: rosyjski, ukraiński i białoruski.\n", + " 4. Crawler wyszukuje dokumentów w trzech językach przygranicznych i języku polskim.\n", + " 5. Translator tłumaczy znalezione teksty na język polski. \n", + " 6. Klasyfikator wybiera teksty potencjalnie przestępcze.\n", + " 7. Analizator Lingwistyczny oznacza informację dodatkową w dokumentach:\n", + " \n", + "### Termin realizacji: \n", + "grudzień 2018 - grudzień 2021\n", + "\n", + "### Zasoby:\n", + " * Ludzie: Wojskowa Akademia Techniczna, UAM, Ken-Bit https://www.kenbit.pl/\n", + " * Kapitał: dotacja z NCBR\n", + " * Wiedza: Najnowsze badania z klasyfikacji tekstu, uczenia automatycznego itp.\n", + " * Technologia: Framework do tworzenia interfejsu użytkownika, algorytmy do klasyfikacji tekstu, modele języka" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Poglądowy widok systemu AI Searcher\n", + "\"Zrzut" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Poziomy gotowości technologicznej\n", + "\n", + "### Poziom 1.\n", + "Rozpoczęto badania naukowe (np. zdefiniowano tematu pracy mgr).\n", + "### Poziom 2.\n", + "Znaleziono zastosowania badań naukowych (np. określono, na czym będzie polegał projekt mgr).\n", + "### Poziom 3.\n", + "Przeprowadzono pierwsze eksperymenty na krytycznych technologiach (np. wykonano proof-of-concept).\n", + "\n", + "### Poziom 4.\n", + "Zintegrowano podstawowe komponenty prototypu w warunkach laboratoryjnych (np. zrealizowano \"user-stories\" na komputerze dewelopera).\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", + "### Poziom 7.\n", + "Dokonano demonstracji systemu w warunkach operacyjnych (np. zademonstrowano prototyp wdrożony u użytkownika / klienta).\n", + "\n", + "### Poziom 8.\n", + "Potwierdzono zamierzony poziom technologii w warunkach operacyjnych (np. pomyślnie zakończono testowanie akceptacyjne).\n", + "\n", + "### Poziom 9.\n", + "Stwierdzono, że wypracowana technologia odniosła zamierzony efekt (np. stwierdzono, że stosowanie rozwiązania przynosi wymierne korzyści). \n", + "\n", + "[Formalny opis poziomów gotowości technologicznej](https://archiwum.ncbr.gov.pl/fileadmin/zalewska/5_1_1_1_2018/13_poziomy_gotowosci_technologicznej.pdf)\n", + "\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Produkt High-Tech\n", + "Oczekuje się, że wynikiem innowacyjnego projektu badawczo-rozwojowego w informatyce jest produkt High-Tech.\n", + "\n", + "## Czym jest produkt High-Tech?\n", + "\n", + "### Definicja produktu\n", + "Produkt = \n", + "Zawartość + \n", + "Funkcjonalność + \n", + "Konstrukcja + \n", + "Monetyzacja \n", + "Oczekuje się zatem, że z produkt posiada jakąś zawartość (Zawartość), z której kożna korzystać (Funkcjonalność), gdyż został odpowiednio skonstruowany (Konstrukcja), ale trzeba za to płacić (Monetyzacja)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Wyraz \"technologia\" pochodzi z języka greckiego:\n", + "
    \n", + "
  • techne: sztuka, umiejętność
    • \n", + "
  • logia: nauka (czegoś)
    • \n", + "
\n", + "\n", + "Technologia w dzisiejszym rozumieniu to zastosowanie wiedzy naukowej do stworzenia czegoś pożytecznego dla człowieka." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Czym jest produkt \"high-tech\"?\n", + "Produkt \"high tech\" to taki produkt, który wykorzystuje najnowszą wiedzę naukową i techniczną. \n", + "Produkt \"high tech\" wymaga nakładów na badania (*R&D investments*). \n", + "\n", + "R&D Investments a wartość produktu:\n", + "* Low-tech (< 1.0%);\n", + "* Medium-low-tech (1.0%-2.5%);\n", + "* Medium-high-tech (2.5%-8%); \n", + "* High-tech (>8.0%)\n", + "\n", + "### Cechy produktu \"high-tech\" z punktu widzenia inwestora\n", + "Dcydując się na wytworzenie produktu high-tech\", inwestor powinien brać pod uwagę ryzyko wynikające z następujących cech produktów tej kategorii:\n", + "* złożoność technologiczna,\n", + "* krótki cykl życia (spowodowany wyścigiem technologicznym),\n", + "* szybkie starzenie się,\n", + "* niewielka liczba klientów w początkowym stadium sprzedaży,\n", + "* duże nakłady na R&D,\n", + "* niepewności technologiczne.\n", + "\n", + "### Cechy produktu \"high-tech\" z punktu widzenia klienta\n", + "Dcydując się na zakup produktu high-tech\", klient powinien brać pod uwagę ryzyko wynikające z następujących cech produktów tej kategorii:\n", + "* dezorientacja klienta (np. jak działa produkt),\n", + "* niespełnianie oczekiwań (przez pierwsze wersje),\n", + "* duża konkurencja,\n", + "* możliwość błyskawicznego upadku rynku,\n", + "* spadająca cena produktu,\n", + "* szybki wzrost stosunku jakości do ceny.\n", + "\n", + "### Ocena ryzyka\n", + "Na 7 zaawansowanych pomysłów produktu high-tech: \n", + "* 4 wchodzą w fazę realizacji,\n", + "* 1.5 są uruchamiane,\n", + "* 1 odnosi sukces." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# \"Golden Rules\" na odniesienie sukcesu\n", + "Aby produkt high-tech miał szanse odnieść sukces na rynku, powinien spełniać przynajmniej kilka z wymienionych poniżej postulatów:\n", + "\n", + "## 1. \"Zapewnij nowatorską / wyjątkową (\"unique\") funkcję lub cechę\"\n", + "* Pomysł musi być nowatorski - a nie skopiowany.\n", + "* Taki produkt wymaga R&D...\n", + " * A to jest kosztowne i...\n", + " * Trudne w konstrukcji.\n", + "* Często pomysły chronione są przez patenty.\n", + "\n", + "\"Nowatorski\" może oznaczać \"nowy model sprzedaży\"\n", + "\n", + "## 2. \"Popraw wydajność użytkownika\"\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* Wykonuj wszystko szybciej i taniej:\n", + " * Skróć czas nauki\n", + " * Automatycznie poprawiaj błędy\n", + " * Automatyzuj niektóre kroki\n", + "* Dbaj o wygodę użytkowania\n", + "* Unikaj:\n", + " * Reklam\n", + " * Przestojów na płacenie (np. bramek)\n", + " * Ogólnie: czynności, ktore pochłaniają czas użytkownika\n", + "\n", + "## 3. \"Chroń inwestycje użytkownika\"\n", + "Zasada ta mówi o tym, aby szanować pieniądze wydane przez użytkownika przed wprowadzeniem naszego rozwiązania. Dotyczy to:\n", + "* hardware'u\n", + "* software'u\n", + "* danych\n", + "\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* Minimalizuj koszty zmian\n", + "* Wydłużaj czas życia produktów\n", + "* Twórz rozwiązania przenośne\n", + "\n", + "## 4. \"Minimalizuj koszty awarii lub utraty danych\"\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* Unikaj przerw w działaniu\n", + "* Skracaj czas i zmniejszaj koszty przywrócenia:\n", + " * działania\n", + " * danych\n", + "\n", + "## 5. \"Poprawiaj wspólczynnik jakości do ceny\"\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* Dostarczaj więcej za mniej\n", + " * Podwyższaj jakość\n", + " * Zmniejszaj cenę\n", + " * A najlepiej - obie czynności naraz\n", + " \n", + "* Jakość (wydajność) przedstawiaj w liczbach\n", + " * Gb, 100-punktowa miara jakości\n", + " * sekundy...\n", + "\n", + "## 6. \"Zapewnij elastyczność i skalowalność\"\n", + "Rozwiązanie jest **elastyczne**, jeśłi może być stosowane w różnych scenariuszach. \n", + "Rozwiązanie jest **skalowalne**, jeśli można je stsosować zarówno dla małych, jak i dużych wielkości danych.\n", + "\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* Umożliwiaj dodawanie / usuwanie funkcji\n", + "* Zapewnij użycie w różnych środowiskach\n", + "* Zapewnij możliwość stosowania dla większych zbiorów danych\n", + "\n", + "## 7. \"Zadbaj o atrakcyjny wygląd\"\n", + "Rozwiązanie powinno być ładne i ...modne.\n", + "\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* Weź pod uwagę:\n", + " * kolorystykę\n", + " * kształt\n", + " * wykończenie\n", + " * prostotę\n", + " \n", + "## 8. \"Dostarczaj rozrywkę\"\n", + "Czego oczekujemy od systemu informatycznego:\n", + "* \"Dzieci\" lubią się bawić - dostarczaj zabawę\n", + "* Ludzie lubią wyzwania - dostarczaj wyzwania\n", + "* Ludzie lubią rywalizację...\n", + "* Ludzie mają swoje hobby i upodobania...\n", + "* Wszyscy wolą wakacje od pracy... \n", + " \n", + "## 9. \"Stwórz nową modę\"\n", + "Stworzenie nowej mody jest niezwykle trudne i kosztowne. Ale kilku producentom się udało.\n", + "Wskazówki:\n", + "* Produkt musi być \"osobisty\".\n", + "* Musi mieć wygląd określany jako \"cool\".\n", + "* Trzeba sprzedawać go drogo...\n", + "* ... w niewielkich ilościach...\n", + "* ... ale za to robić wokół niego sporo szumu." + ] + } + ], + "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.7.6" + }, + "subtitle": "02. Projekt badawczo-rozwojowy[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/03_prezentacja_koncepcji_projektu.ipynb b/materiały na wykład/03_prezentacja_koncepcji_projektu.ipynb new file mode 100644 index 0000000..c27d1e5 --- /dev/null +++ b/materiały na wykład/03_prezentacja_koncepcji_projektu.ipynb @@ -0,0 +1,418 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy informatyczne

\n", + "

3. Prezentacja koncepcji projektu[wykład]

\n", + "

3. Krzysztof Jassem[wykład]

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Inwestorzy\n", + "\n", + "Opracowanie i rozwój projektu B+R wymaga środków finansowych. Środki finansowe zapewnia *inwestor*, któremu trzeba odpowiednio zaprezentować koncepcję projektu B+R, czyli przekonać go, że poświęcone środki finansowe się zwrócą. \n", + "\n", + "**Inwestor** to osoba lub instytucja, która przekazuje środki finansowe na przedsięwzięcie, oczekując zwrotu i zysku. \n", + "\n", + "**Anioł biznesu** to inwestor, który dostarcza początkowe środki finansowe (seed money) na rozpoczęcie biznesu w zamian za część udziałów lub *dług zamienny*. \n", + "\n", + "**Dług zamienny** to papier wartościowy, który może zostać wymienony na akcje lub udziały firmy. \n", + "\n", + "**Kapitał wysokiego ryzyka (ang. venture capital)** to kapitał dostarczony dla istniejącej firmy typu start-up, zwykle w przemyśle HT. Kapitał wysokiego ryzyka liczy na zwrot w przypadku wyjścia firmy na giełdę lub jej sprzedaży." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Główne atrybuty produktu HT\n", + "Produkt ma wnosić **wartość dodaną**, która spełni **potrzeby klienta** dzięki dobrze przemyślanej **konstrukcji**.\n", + "\n", + "1. Wartość dodana to zestaw korzyści z punktu widzenia klienta. \n", + "\n", + "Korzyść może być: \n", + " * Funkcjonalna (produkt wykonuje pracę dla klienta) \n", + " * Emocjonalna (produkt wpływa pozytywnie na samopoczucie klienta \n", + " * Rozwijająca osobowość klienta \n", + " * Społeczna (produkt wpływa na poprawę pozycji społecznej klienta) \n", + "\n", + "2. Spełnienie potrzeby użytkowników\n", + ">“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.” (Steve Jobs)\n", + "\n", + "Potrzeby użytkowników: \n", + " * Wypowiedziane (odczuwane dziś i świadome) - spełniają je przeciętne produkty;\n", + " * Ukryte (odczuwane dziś, ale nieświadome) - spełniają je produkty HT;\n", + " * Oczekiwane (odczuwane w przyszłości w sposób świadomy) - spełniają je wybitne produkty HT;\n", + " * Mające się pojawić (odczuwane w przyszłości w sposób nieświadomy) - spełniają je wizjonerskie produkty HT.\n", + "\n", + "3. Odpowiednia konstrukcja (design)\n", + "Produkt jest odpowiednio skonstruowany, jeśli ma następujące cechy:\n", + "* Pożyteczny (rozwiązuje problem lub wykonuje zadania), \n", + "* Użyteczny (łatwy w użytku, intuicyjny),\n", + "* Pożądany (wywołuje pozytywne emocje, sprawia przyjemność)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Elevator pitch\n", + "**Elevator pitch** to krótka prezentacja, ktorej celem jest zwięzłe i proste omówienie produktu lub przedsięwzięcia. Oczekuje się, że trwa niedłużej niż 2 minuty. \n", + "**Jednozdaniowy elevator pitch** to najkrótsza charakterystyka planowanego przedsięwzięcia. Ma postać: " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

DLA (określenie klienta docelowego)

\n", + "

KTÓRY (ma potrzebę)

\n", + "

NAZWA NASZEGO PRODUKTU (PRZEDSIĘWZIĘCIA)

\n", + "

TO (typ produktu / przedsięwzięcia)

\n", + "

KTÓRY (ma unikalną cechę)

\n", + "

W PRZECIWIEŃSTWIE (nazwa znanej konkurencji)

\n", + "

MA PRZEWAGĘ (typ przewagi)

\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Przykład jednozdaniowego \"elevator pitch\"

\n", + " \n", + "

(DLA) Dla każdej osoby biorącej leki lub suplementy,

\n", + "

(KTÓRA) zwłaszcza dla tych którzy mają tendencje zapominać.

\n", + "

(NAZWA PRODUKTU) Take Your Meds

\n", + "

(TO) to aplikacja mobilna,

\n", + "

(KTÓRA) która zapewni, że bez pomyłek weźmiemy wszystkie leki.

\n", + "

(W PRZECIWIEŃSTWIE) w przeciwieństwie do standardowych powiadomień na telefonie i notatek na kartce,

\n", + "

(MA PRZEWAGĘ) Take Your Meds zapewnia szczegółowe informacje i nie pozwala się pomylić.

\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prezentacja dla inwestora\n", + "### Reguła 30 / 20 / 10 (Czcionka / Minuty / Slajdy)\n", + "Reguła mówi o standardowych oczekiwaniach w stosunku do prezentacji (czyli: stosuj dużą czcionkę, nie gadaj dłużej ani krócej niż 2 minuty na slajd).\n", + "### Wzorzec 10 slajdów prezentacji dla inwestora\n", + "#### 1. Chwyć za gardło (ang. \\\"Grab\\\")\n", + " * Jaki masz pomysł?\n", + " * Czym się wyróżniasz pod względem korzyści: \n", + " * funkcjonalność, \n", + " * spełnienie potrzeby, \n", + " * konstrukcja?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki

\n", + "\n", + "
    \n", + " \n", + "
  • Nie bądź gadatliwy!
    • \n", + "
  • Uchwyć uwagę widza!
    • \n", + "
  • Jeśli tutaj nie chwycisz widza za gardło, to przepadłeś.
    • \n", + " \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 2. Przedstaw problem\n", + " * Dlaczego\n", + " * Wasz produkt jest niezbędny?\n", + " * ludzie go potrzebują?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówka:

\n", + " \n", + "
    \n", + "
  • Pamiętaj: nie chodzi o Twój problem, tylko o problem potencjalnego użytkownika!
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 3. Przedstaw rozwiązanie problemu\n", + " * Jak rozwiążecie problem ?\n", + " * Kto będzie korzystać z Waszego rozwiązania?\n", + " * I jakie będzie miał z tego korzyści?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki:

\n", + " \n", + "
    \n", + "
  • Bądź konkretny!
    • \n", + "
  • Nie zalewaj!
    • \n", + "
  • Nie czaruj!
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 4. Przedstaw sposób działania\n", + "* Jak działa nasze rozwiązanie?\n", + "* Co w działaniu jest takiego wyjątkowego? (\\\"magic souce\\\")?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki:

\n", + "\n", + "
    \n", + "
  • Przekonaj, że Wasze rozwiązanie jest\n", + "
      \n", + "
    • użyteczne,\n", + "
    • funkcjonalne\n", + "
    \n", + "
  • Najlepiej przedstaw działanie wizulanie - np. na schemacie, rysunku, filmie.\n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 5. Omów technologię\n", + " * Jaka jest konstrukcja (architektura) rozwiązania?\n", + " * Co w niej jest takiego wyjątkowego?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki:

\n", + " \n", + "
    \n", + "
  • Ponownie możesz przedstawić schemat...
    • \n", + "
  • Ale uważaj, żeby nie przesadzić ze szczegółami technicznymi!
    • \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 6. Przedstaw konkurencję\n", + " * Jakie produkty / firmy są Waszą konkurencją?\n", + " * Co robią inaczej?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówka:

\n", + " \n", + "Wykaż, że jesteście lepsi:\n", + "
    \n", + "
  • jakość,
    • \n", + "
  • cena,
    • \n", + "
  • funkcjonalność,
    • \n", + "
  • użyteczność,
    • \n", + "
  • elastyczność.
    • \n", + "
\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 7. Określ Wasz rynek\n", + "**Rynek** to ogół transakcji kupna–sprzedaży danego dobra lub czynnika produkcji. \n", + " * Na jaki rynek kierujecie Wasz produkt?\n", + " * Jaka jest wartość finansowa rynku dla Waszego produktu?\n", + " * Total Available Market - wartość ogólnoświatowego popytu na dany produkt usługę\\,\n", + " * Served Available Market - wartość rynku, na którym chcecie działać,\n", + " * Target Market - przewidywana wartość rynku Waszych prawdopodobnych nabywców." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki:

\n", + "\n", + "
    \n", + "
  • Możecie interpretować powyższe pojęcia w sposób potoczny:
    • \n", + "
      \n", + "
    • TAM - Jak duży jest cały tort?
      • \n", + "
    • SAM - Jak duży kawałek tortu jestem w stanie uciąć dla siebie?
      • \n", + "
    • TM - Ile jestem w stanie zjeść?
      • \n", + "
    \n", + "
  • Inwestor oczekuje, że potraficie oszacować wartość każdego zasięgu rynku na podstawie wiarygodnych źródeł.
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 8. Zdefiniuj model biznesowy\n", + "**Model biznesowy** to unikatowy przepis na sprzedawanie produktu lub usługi.\n", + " * W jaki sposób Wasz pomysł zarobi pieniądze?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "

Wskazówka:

\n", + "\n", + "Wyjaśnij swój pomysł na sprzedaż, np.\n", + "
    \n", + "
  • licencje / sprzedaż jednorazowa,
    • \n", + "
  • sprzedaż bezpośrednia / dystrybutorzy,
    • \n", + "
  • dochody z reklam,
    • \n", + "
  • mechanizmy przyciągnięcia klienta, np. programy lojalnościowe, grywalizacja.
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 9. Przedstaw prognozę finansową przedsięwzięcia\n", + "**Prognoza finansowa** to przewidywana wartość przyszłych wyników finansowych przesięwzięcia uwzględniająca przychody i koszty.\n", + " * Jaka jest prognoza finansowa na okres 18 miesięcy - 5 lat?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "

Wskazówki:

\n", + "
    \n", + "
  • Udowodnij, że znasz realia lub...dostosuj się do oczekiwań inwestora.
    • \n", + "
  • Kiedyś prognozę układało się na 5 lat, a dzisiaj... 5 lat to dłużej niż wieczność.
    • \n", + "
\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "#### 10. Pochwal się zespołem\n", + " * Jakie są kluczowe osoby w Twoim zespole?,\n", + " * Skąd pochodzą?\n", + " * Jaką wartość wnoszą?" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "\n", + "

Wskazówki:

\n", + " \n", + "
    \n", + "
  • Można pokazać zdjęcia, jeśli ludzie się na to zgadzają.
    • \n", + "
  • Jeśli w zespole jest gwiazda, pozwól jej lśnić.
    • \n", + "
\n", + " \n", + "
" + ] + } + ], + "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.7.6" + }, + "subtitle": "03. Prezentacja koncepcji projektu B+R[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/04_prezentacje_publiczne.ipynb b/materiały na wykład/04_prezentacje_publiczne.ipynb new file mode 100644 index 0000000..7e00297 --- /dev/null +++ b/materiały na wykład/04_prezentacje_publiczne.ipynb @@ -0,0 +1,67 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Projekt badawczo-rozwojowy

\n", + "

4. Publiczne prezentacje projektów[laboratorium]

\n", + "

Krzysztof Jassem (2021)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Cel laboratorium nr 4\n", + "\n", + "Celem laboratorium będzie publiczne przedstawienie koncepcji projektu badawczo-rozwojowego." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Plan laboratorium\n", + "\n", + "Podczas laboratorium poszczególne zespoły studentów przedstawiać będą: jednozdaniowy \"elevator pitch\" oraz prezentację dotyczącą swojego pomysłu. \n", + "\n", + "Widownią będą studenci wszystkich grup projektowych. Na ocenę prezentacji będą miały wpływ odczucia widowni - zebrane za pomocą ankiet.\n", + "\n", + "Maksymalna ocena: 30 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": "01. Prezentacje publiczne[laboratorium]", + "title": "Projekt badawczo-rozwojowy", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/05_metodyki zwinne.ipynb b/materiały na wykład/05_metodyki zwinne.ipynb index 1d0bc7d..d1362e9 100644 --- a/materiały na wykład/05_metodyki zwinne.ipynb +++ b/materiały na wykład/05_metodyki zwinne.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

5. Metodyki adaptacyjne w programowaniu[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -611,7 +611,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "05. Metodologia Prince2Agile[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/06_prototypowanie i ciągła integracja.ipynb b/materiały na wykład/06_prototypowanie i ciągła integracja.ipynb index df8b62a..f1a6b4f 100644 --- a/materiały na wykład/06_prototypowanie i ciągła integracja.ipynb +++ b/materiały na wykład/06_prototypowanie i ciągła integracja.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

6. Prototypowanie i ciągła integracja[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -468,7 +468,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/07_specyfikacja_projektu_informatycznego.ipynb b/materiały na wykład/07_specyfikacja_projektu_informatycznego.ipynb index 052b120..4310913 100644 --- a/materiały na wykład/07_specyfikacja_projektu_informatycznego.ipynb +++ b/materiały na wykład/07_specyfikacja_projektu_informatycznego.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

7. Specyfikacja projektu informatycznego[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -170,7 +170,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -203,7 +202,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -219,7 +217,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -247,7 +244,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -280,7 +276,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -318,7 +313,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -333,7 +327,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -346,7 +339,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -360,7 +352,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -375,7 +366,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -408,7 +398,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -434,7 +423,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -468,7 +456,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "07. Specyfikacja projektu informatycznego[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/08_testowanie_w_programowaniu_zwinnym.ipynb b/materiały na wykład/08_testowanie_w_programowaniu_zwinnym.ipynb index a83982d..d505b24 100644 --- a/materiały na wykład/08_testowanie_w_programowaniu_zwinnym.ipynb +++ b/materiały na wykład/08_testowanie_w_programowaniu_zwinnym.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

8. Testowanie w programowaniu zwinnym[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -463,7 +463,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "08. Testowanie w programowaniu zwinnym[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/09_testowanie_systemowe_i_akceptacyjne.ipynb b/materiały na wykład/09_testowanie_systemowe_i_akceptacyjne.ipynb index 0c3e93f..46409a4 100644 --- a/materiały na wykład/09_testowanie_systemowe_i_akceptacyjne.ipynb +++ b/materiały na wykład/09_testowanie_systemowe_i_akceptacyjne.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

9. Testowanie systemowe i akceptacyjne[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -148,7 +148,6 @@ ] }, { - "attachments": {}, "cell_type": "markdown", "metadata": {}, "source": [ @@ -444,7 +443,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "09. Testowanie integracyjne i systemowe[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/13_aspekty_użyteczności.ipynb b/materiały na wykład/11_aspekty_użyteczności.ipynb similarity index 99% rename from materiały na wykład/13_aspekty_użyteczności.ipynb rename to materiały na wykład/11_aspekty_użyteczności.ipynb index 1e2cbaa..84b6507 100644 --- a/materiały na wykład/13_aspekty_użyteczności.ipynb +++ b/materiały na wykład/11_aspekty_użyteczności.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

11. Aspekty użyteczności[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -681,7 +681,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "11. Aspekty użyteczności[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/11_wybrane_zagadnienia_użyteczności.ipynb b/materiały na wykład/11_wybrane_zagadnienia_użyteczności.ipynb new file mode 100644 index 0000000..ccef61a --- /dev/null +++ b/materiały na wykład/11_wybrane_zagadnienia_użyteczności.ipynb @@ -0,0 +1,561 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy informatyczne

\n", + "

10. Wybrane zagadnienia użyteczności[wykład]

\n", + "

Krzysztof Jassem (2021)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# 1. Pojęcie użyteczności" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Użyteczność

\n", + "\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", + "

Cechy aplikacji użytecznej

\n", + " \n", + "
    \n", + "
  • Łatwa do nauki: Jak łatwo jest użytkownikom wykonać dane zadanie po raz pierwszy?\n", + "
  • Wydajna w pracy: Jak szybko użytkownicy wykonują zadania, gdy już się nauczyli programu?\n", + "
  • Satysfakcja: Czy korzystanie z programu daje satysfakcję?\n", + "
  • Odporna na błędy: Ile błędów robią użytkownicy, jak poważne są to błędy i jak łatwo z nich się wydostać?\n", + "
  • Zapamiętywalna po czasie: Jak łatwo powrócić do biegłości użytkowania po pewnym okresie nieużytkowania programu?\n", + "\n", + "
" + ] + }, + { + "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\"" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "Przeczytaj w Internecie\n", + "\n", + "
    \n", + " \n", + "
  1. Usability Means…
    2. \n", + "\n", + "
  2. Web applications should explain themselves.
    3. \n", + "\n", + "
  3. Don’t Make Me Think
    4. \n", + "\n", + "
  4. Don’t waste my time
    5. \n", + " \n", + "
  5. Users still cling to their back buttons
    6. \n", + "\n", + "
  6. We’re creatures of habit
    7. \n", + "\n", + "
  7. No Time for Small Talk
    8. \n", + "\n", + "
  8. Don’t lose search
    9. \n", + "\n", + "
  9. We form mental site-maps
    10. \n", + "\n", + "
  10. Make it easy to go home
    11. \n", + " \n", + "
\n", + "\n", + "
\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 2.2. Podejście (bardziej) współczesne" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Wskazówki do tworzenia użytecznego systemu informatycznego

\n", + "\n", + "
    \n", + "
  1. Autorze: Poznaj użytkownika, a TY nie jesteś użytkownikiem.
    2. \n", + "
  2. Użytkownik powinien mieć kontrolę nad systemem, a nie odwrotnie: to użytkownik jest szefem i system powinien to okazywać.
    3. \n", + "
  3. System musi ułatwiać użytkownikowi życie:
    4. \n", + "
      \n", + "
    • Elementy, które wyglądają tak samo, powinny działać tak samo, a akcje, które nie działają tak samo powinny być inaczej reprezentowane.
      • \n", + "
    • Każda akcja użytkownika powinna mieć reakcję programu.
      • \n", + "
    • Kiedy użytkownik ma do podjęcia decyzję, system podaje mu całą dostępną informację.
      • \n", + "
    \n", + "
  4. System musi być \"idioto-odporny\":
    5. \n", + "
      \n", + "
    • Każdy robi błędy, więc każdy błąd powinien dać się naprawić.
      • \n", + "
    • Gdy użytkownik zrobi błąd, System daje mu o tym znać, zanim … wpadnie w PRAWDZIWE kłopoty.
      • \n", + "
    • Informacje o błędach powinny być zrozumiałe dla użytkownika i mówić mu, jak naprawić problem.
      • \n", + "
    \n", + "
  5. Wczuj się w użytkownika
    6. \n", + "
      \n", + "
    • Eliminuj niepotrzebne decyzje (nie pytaj, jak nie musisz).
      • \n", + "
    • Im mniej kroków do celu, tym lepiej.
      • \n", + "
    • Użytkownik powinien zawsze móc dowiedzieć się, co robić dalej.
      • \n", + "
    • Użytkownik powinien zawsze wiedzieć, co się dzieje.\n", + "
    \n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 3. Zasady dobrej nawigacji na portalu internetowym\n", + "### 3.1. Pojęcie nawigacji" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + " Nawigacja 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", + "
    \n", + "
  • Menu główne
    • \n", + "
  • Menu narzędziowe
    • \n", + "
  • Identyfikator witryny
    • \n", + "
  • Wyszukiwarka
    • \n", + "
  • Odsyłacz do strony startowej (zawarty w logo)
    • \n", + "
  • Flagi narodowe (przełączenie języków)
    • \n", + "
\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## 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" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Zasada 1. Widoczność\n", + "Wszystkie elementy nawigacji muszą być bardzo dobrze widoczne na każdej stronie i podstronie serwisu." + ] + }, + { + "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. " + ] + }, + { + "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." + ] + }, + { + "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." + ] + }, + { + "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." + ] + }, + { + "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" + ] + }, + { + "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/)" + ] + }, + { + "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/" + ] + }, + { + "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" + ] + }, + { + "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." + ] + }, + { + "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" + ] + }, + { + "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": "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." + ] + }, + { + "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." + ] + }, + { + "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." + ] + } + ], + "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.7.6" + }, + "subtitle": "10. Wybrane zagadnienia użyteczności[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/11_ocena_jakości_systemu.ipynb b/materiały na wykład/12_ocena_jakości_systemu.ipynb similarity index 99% rename from materiały na wykład/11_ocena_jakości_systemu.ipynb rename to materiały na wykład/12_ocena_jakości_systemu.ipynb index 73af4d5..21a8eee 100644 --- a/materiały na wykład/11_ocena_jakości_systemu.ipynb +++ b/materiały na wykład/12_ocena_jakości_systemu.ipynb @@ -6,9 +6,9 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", - "

11. Ocena jakości systemu informatycznego[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Systemy informatyczne

\n", + "

12. Ocena jakości systemu informatycznego[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -615,7 +615,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "12. Ocena jakości systemu informatycznego[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/13_planowanie prac badawczo-rozwojowych.ipynb b/materiały na wykład/13_planowanie prac badawczo-rozwojowych.ipynb new file mode 100644 index 0000000..0ed97e5 --- /dev/null +++ b/materiały na wykład/13_planowanie prac badawczo-rozwojowych.ipynb @@ -0,0 +1,739 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", + "
\n", + "

Systemy informatyczne

\n", + "

13. Planowanie prac badawczo-rozwojowych[wykład]

\n", + "

Krzysztof Jassem (2022)

\n", + "
\n", + "\n", + "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Harmonogram projektu

\n", + " \n", + "Harmonogram projektu to plan uzyskania celów projektu uwzględniający:\n", + "
    \n", + "
  • podział pracy na etapy i zadania,
    • \n", + "
  • przydział zasobów do zadań,
    • \n", + "
  • terminy wykonania zadań.
    • \n", + "
" + ] + }, + { + "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": [ + "
\n", + "

Ograniczenia

\n", + " \n", + "Ograniczenia to czynniki, które wpływają na realizację harmonogramu.\n", + "
" + ] + }, + { + "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": [ + "
\n", + "

Zapas czasu

\n", + " \n", + " Zapas czasu  to czas, o który może opóźnić się realizacja zadania, nie wpływając na termin ukończenia projektu.\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Ścieżka krytyczna

\n", + " \n", + " Ścieżka krytyczna 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", + "
\n", + "\"Przykład\n", + "
Przykład ścieżki krytycznej
\n", + "
\n", + "\n", + "
" + ] + }, + { + "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": [ + "
\n", + "

Prawo Parkinsona

\n", + " \n", + "Praca będzie się rozrastać, aby wypełnić cały czas na nią przewidziany.\n", + "\n", + "
\n", + "\"Prawo\n", + "
Prawo Parkinsona, źródło: https://www.timeflies.us/blog/what-is-parkinson-s-law-and-how-it-can-make-you-more-productive
\n", + "
\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# 2. Struktura podziału pracy" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Struktura Podziału Pracy

\n", + " \n", + "Struktura Podziału Pracy to hierarchiczna reprezentacja podziału pracy w projekcie.\n", + "\n", + "
" + ] + }, + { + "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", + "
\n", + "\"Struktura\n", + "
Struktura Podziału Pracy, źródło: http://pm2pm.pl/slownik-project-managera-wbs/
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Zasada 8 - 80

\n", + "Wykonanie najmniejszej jednostki harmonogramu powinno zajmować między 8 a 80 godzin.\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Ustawienie\n", + "
Ustawienie daty początku projektu
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Stworzenie\n", + "
Stworzenie SPP
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Ustawianie\n", + "
Ustawianie trybów zadań
\n", + "
\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### 3.4. Określenie punktów kontrolnych" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Punkt kontrolny

\n", + " \n", + "Punkt kontrolny (ang. milestone) – punkt na osi czasu, który podsumowuje określony zestaw zadań, bądź daną fazę projektu.\n", + "
    \n", + "
  • Może to być: podpisanie dokumentu, otrzymanie wyniku, ważne spotkanie, zatwierdzenie pracy itp.\n", + "
  • Zazwyczaj osiągnięcie punktu kontrolnego wiąże się z dalszymi decyzjami odnośnie rozwoju projektu.\n", + "
  • Punkt kontrolny ma zerowy czas trwania.\n", + "
  • Pojęcie punktu kontrolnego zastąpiło pojęcie kamienia milowego.\n", + "
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "

\n", + "
\n", + "\"Ustawianie\n", + "
Ustawianie punktu kontrolnego
\n", + "
\n", + "\n", + "

\n", + "
\n", + "\"Punkt\n", + "
Oznaczenie punktu kontrolnego w MS-Project
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Ustawianie\n", + "
Ustawianie czasu pracy dla zespołu - przycisk
\n", + "
\n", + "\n", + "

\n", + "
\n", + "\"Ustawianie\n", + "
Ustawianie czasu pracy dla zespołu - kalendarz
\n", + "
\n", + " " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### 3.6. Modyfikacja diagramu Gantta" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Diagram Gantta

\n", + " \n", + " Diagram Gantta 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", + "
\n", + "
\n", + "\"diagram\n", + "
Przykładowy diagram Gantta, źródło: https://kierownikprojektu.com/2020/06/11/16-zalet-wykresu-gantta/
\n", + "
\n", + "\n", + "\n", + "

Zalety wykresu Gantta

\n", + "
    \n", + "
  • przedstawia następstwo zdarzeń,
    • \n", + "
  • uwzględnia zadania wykonywane równolegle,
    • \n", + "
  • dobrze sprawdza się dla niewielkich projektów.
    • \n", + "
\n", + "\n", + "

Wady wykresu Gantta

\n", + "
    \n", + "
  • nie zawiera szczegółowych opisów zadań,
    • \n", + "
  • wymusza podanie konkretnych dat.
    • \n", + "
\n", + "
" + ] + }, + { + "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": [ + "
\n", + "

Zależności między zadaniami

\n", + " \n", + "Zadanie B jest zależne od A, gdy zmiana terminu wykonania A wpływa na termin wykonania B. Zadanie A nazywamy poprzednikiem, a B – następnikiem . \n", + " \n", + "

Typy zależności

\n", + "
    \n", + "
  • Zadania typu ZR (zakończenie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po zakończeniu poprzednika (A).\n", + "
  • Zadania typu RR (rozpoczęcie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po rozpoczęciu poprzednika(A).\n", + "
  • Zadania typu ZZ (zakończenie-zakończenie). Następnik (B) może się zakończyć dopiero po zakończeniu poprzednika (A).\n", + "
  • Zadania typu RZ (rozpoczęcie-zakończenie). Następnik (B) może się zakończyć dopiero po rozpoczęciu poprzednika (A).\n", + "
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Ustawianie\n", + "
Ustawianie zależności między zadaniami
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Ustawianie\n", + "
Ustawianie odstępów czasowych
\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### 3.9 Określenie zasobów w projekcie" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Zasoby

\n", + " \n", + "Zasoby (ang. resources) – 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", + "
    \n", + "
  • Praca (ludzie lub komputery),\n", + "
  • Materiał (np. energia),\n", + "
  • Koszt (np. koszt podróży).\n", + "
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"Zdefiniowanie\n", + "
Definiowanie zasobów - arkusz zasobów
\n", + "
\n", + "\n", + "

\n", + "\n", + "
\n", + "\"Zdefiniowanie\n", + "
Definiowanie zasobów - dane zasobów
\n", + "
" + ] + }, + { + "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", + "

\n", + "\n", + "
\n", + "\"Czas\n", + "
Ustawianie indywidualnego czasu pracy - wybranie zasobu
\n", + "
\n", + "\n", + "

\n", + "

\n", + "
\n", + "\"Czas\n", + "
Ustawianie indywidualnego czasu pracy - zmiana tygodniowego planu pracy
\n", + "
" + ] + }, + { + "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", + "

\n", + "\n", + "
\n", + "\"Przydzielanie\n", + "
Przydzielanie zasobów do zadań
\n", + "
\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", + "
\n", + "\"Sprawdzenie\n", + "
Sprawdzenie przeciążenia zasobów
\n", + "
\n", + "\n", + " \n", + "

\n", + "
\n", + "\"Zasoby\n", + "
Zasoby z nadmierną alokacją pracy (zasoby przeciążone) - przykład
\n", + "
\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", + "

\n", + "
\n", + "\"Odciążanie\n", + "
Zmniejszenie zaangażowania zasobu w zadanie
\n", + "
\n", + "\n", + "

\n", + "Automatyczne bilansowanie zasobu wykonywane jest przez MS-Porject na żądanie użytkownika.\n", + "\n", + "

\n", + "
\n", + "\"automatyczne\n", + "
Automatyczne bilansowanie zasobów
\n", + "
\n", + "\n", + "

\n", + "Efekt bilansowania może spowodować przesunięcie pracy w czasie, a co za tym idzie, opóźnienie realizacji projektu:\n", + "\n", + "

\n", + "
\n", + "\"obciążenie\n", + "
Obciążenie zasobu przez bilansowaniem
\n", + "
\n", + "\n", + "\n", + "

\n", + "
\n", + "\"obciążenie\n", + "
Obciążenie zasobu po bilansowaniu
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"ścieżka\n", + "
Ścieżka krytyczna - przykład
\n", + "
\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", + "

\n", + "
\n", + "\"raport\n", + "
Przykład raportu całościowego
\n", + "
\n", + "\n", + "

\n", + "
\n", + "\"raport\n", + "
Przykład raportu zasobów
\n", + "
\n", + "\n", + "

\n", + "
\n", + "\"raport\n", + "
Przykład raportu kosztów
\n", + "
" + ] + }, + { + "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", + "

\n", + "
\n", + "\"modyfikacja\n", + "
Metody poprawiania harmonogramu
\n", + "
" + ] + }, + { + "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.7.6" + }, + "subtitle": "13. Planowanie prac badawczo-rozwojowych[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/15_demonstracja_projektu.ipynb b/materiały na wykład/15_demonstracja_projektu.ipynb index 473c78b..d06b28c 100644 --- a/materiały na wykład/15_demonstracja_projektu.ipynb +++ b/materiały na wykład/15_demonstracja_projektu.ipynb @@ -6,22 +6,13 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", + "

Systemy informatyczne

\n", "

15. Demonstracja wyników projektu badawczo-rozwojowego [wykład]

\n", "

Krzysztof Jassem (2021)

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "
\n", - "Demonstrowane projekty powinny być na 6. poziomie gotowości technologicznej.\n", - "
" - ] } ], "metadata": { @@ -43,7 +34,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "15. Demonstracja projektu[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/04_metodologia_Prince2.ipynb b/materiały na wykład/metodologia_Prince2 (wykład dodatkowy).ipynb similarity index 99% rename from materiały na wykład/04_metodologia_Prince2.ipynb rename to materiały na wykład/metodologia_Prince2 (wykład dodatkowy).ipynb index 4555d1b..adf734d 100644 --- a/materiały na wykład/04_metodologia_Prince2.ipynb +++ b/materiały na wykład/metodologia_Prince2 (wykład dodatkowy).ipynb @@ -6,9 +6,8 @@ "source": [ "![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n", "
\n", - "

Przygotowanie do projektu badawczo-rozwojowego

\n", - "

4. Metodologia Prince2[wykład]

\n", - "

Krzysztof Jassem (2021)

\n", + "

Systemy informatyczne

\n", + "

0. Metodologia Prince2[wykład]

\n", "
\n", "\n", "![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)" @@ -1009,7 +1008,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.8.5" + "version": "3.7.6" }, "subtitle": "04. Metodologia Prince 2[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego",
Wartości metryki dostępności
Miara dostępności Czas niedostępności w roku