Compare commits
9 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
a3d6f62192 | ||
|
|
0b558be7dc | ||
|
|
f52d9150b7 | ||
|
|
92ed3ecbf0 | ||
|
|
08d32d58a1 | ||
|
|
9a142a322e | ||
|
|
31ec680541 | ||
|
|
14d3fe7526 | ||
|
|
e8d30d4f3d |
@ -1,167 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Organizacja prezentacji koncepcji projektów\n",
|
||||
"Informacje dotyczą prezentacji koncepcji projektów na zajęciach PBR. \n",
|
||||
"Podane poniżej informacje mogą ulec korektom do dnia 8 listopada włącznie."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Termin i forma prezentacji\n",
|
||||
" * Prezentacje będą prowadzone w formie zdalnej za pomocą platformy MS-Teams. Każdy zespół będzie prowadził prezentację ze swojej sali laboratoryjnej (Uwaga: sale 16-17 będą remontowane - zamiast nich mamy zarezerwowane sale 18 i 20). Szacowany czas na jedną prezentację to 6 minut.\n",
|
||||
"\n",
|
||||
" * Podczas prezentacji pozostali studenci będą obserwować wypowiedzi kolegów, przebywająć w swoim laboratorium. Na zajęciach nie są przewidziane żadne inne zadania. \n",
|
||||
"\n",
|
||||
" * Zajęcia rozpoczną się o 15.15, a zakończą o 17.15. Przepraszam za przedłużenie ćwiczeń."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Ocena prezentacji\n",
|
||||
" * Każda prezentacja, spełniająca podstawowe oczekiwania dot. prezentacji, otrzyma ocenę bazową: 20 punktów. \n",
|
||||
" * Do oceny bazowej zostaną doliczone punkty bonusowe za prezentacje wyróżnione przez:\n",
|
||||
" * studentów,\n",
|
||||
" * prowadzących oraz zaproszonych gości.\n",
|
||||
" * Punkty bonusowe przyznane przez obie grupy odbiorców są sumowane.\n",
|
||||
"\n",
|
||||
" * Wyróżnienia będą przyznawane na podstawie wyników ankiet. W ramach ankiety każdy student i każdy prowadzący (gość) będzie poproszony o wskazanie pięciu najlepszych prezentacji. Studenci nie mogą głosować na prezentacje swoich grup.\n",
|
||||
"\n",
|
||||
" * Ankieta dla studentów https://forms.gle/wmkmPvc1bjhQSgkVA\n",
|
||||
"\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",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Miejce</td> <td> Nazwa projektu </td> <td>Punkty bonusowe</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td>1.</td><td> BitSearch</td> <td>10</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>2.</td><td> Meetify </td> <td>7</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>3.</td><td> Rozpoznawanie komend głosowych </td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>4</td><td> Transfix </td><td>3</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>5</td><td> Lech Analytics </td><td>2</td>\n",
|
||||
" </tr>\n",
|
||||
"</table> \n",
|
||||
"\n",
|
||||
"### Prezentacje wyróżnione przez prowadzących i gości\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Miejce</td> <td> Nazwa projektu </td> <td>Punkty bonusowe</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr> \n",
|
||||
" <td>1.</td> <td> BitSearch</td> <td>10</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>2.</td> <td> HoneyPot </td> <td>7</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>3.</td> <td> Wyszukiwanie w dokumentach</td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>4</td><td> Rozpoznawanie komend głosowych </td><td>3</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>5</td><td> RandomSec</td> <td>2</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>5</td><td> PhishandWare</td> <td>2</td>\n",
|
||||
" </tr>\n",
|
||||
"</table> \n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Plan zajęć\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"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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
|
||||
}
|
||||
@ -4,26 +4,7 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Organizacja zajęć na przedmiotach PPB, SYI oraz PBR"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Przygotowanie do projektu badawczo-rozwojowego (PPB)\n",
|
||||
"Przygotowanie do projektu badawczo-rozwojowego to przedmiot prowadzony w formie wykładów dla studentów II roku studiów magisterskich na kierunku Informatyka. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia projektu badawczo-rozwojowego. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Systemy informatyczne (SYI)\n",
|
||||
"Systemy informatyczne to przedmiot prowadzony w formie wykładów i laboratoriów dla studentów III semestru studiów magisterskich na kierunku Analiza i Przetwarzanie Danych. \n",
|
||||
"Celem przedmiotu jest zaznajomienie studentów z przebiegiem tworzenia systemu informatycznego - na przykładzie projektu badawczo-rozwojowego rozwijanego przez studentów studiów magisterskich na kierunku Informatyka. \n",
|
||||
"W ramach laboratorium do przedmiotu SYI studenci uczestniczą w tworzeniu projektów badawczo-rozwojowych razem ze studentami Informatyki."
|
||||
"# Organizacja zajęć na przedmiocie Projekt badawczo-rozwojowy"
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -46,9 +27,6 @@
|
||||
"## Ocena końcowa z przedmiotu PBR\n",
|
||||
"Studentom informatyki ocenę końcową z laboratorium wystawia opiekun projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Ocena końcowa z laboratorium SYI\n",
|
||||
"Studentom analizy i przetwarzania danych ocenę końcową wystawia prowadzący laboratorium na wniosek opiekuna projektu badawczo-rozwojowego.\n",
|
||||
"\n",
|
||||
"## Umiejętności nabywane podczas przedmiotu PBR\n",
|
||||
"Student informatyki powinien nabyć następujące umiejętności:\n",
|
||||
"* tworzenie koncepcji projektu badawczo-rozwojowego,\n",
|
||||
@ -56,14 +34,7 @@
|
||||
"* stosowanie praktyki ciągłej integracji w rozwoju systemu informatycznego,\n",
|
||||
"* wdrożenie systemu będącego wynikiem projektu badawczo-rozwojowego w praktyce gospodarczej.\n",
|
||||
"\n",
|
||||
"## Umiejętności nabywane podczas laboratorium SYI\n",
|
||||
"Student analizy i przetwarzania danych powinien nabyć następujące umiejętności:\n",
|
||||
"* dostarczanie i analiza danych do systemu informatycznego,\n",
|
||||
"* tworzenie dokumentacji projektowej,\n",
|
||||
"* przygotowanie i prowadzenie testów funkcjonalnych,\n",
|
||||
"* opracowanie raportów użyteczności,\n",
|
||||
"* tworzenie skryptów wspomagających implementację i testowanie.\n"
|
||||
]
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
@ -8,7 +8,7 @@
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 4. <i>Publiczne prezentacje projektów</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"<h3>Krzysztof Jassem, Tomasz Piłka (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
@ -7,8 +7,8 @@
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 4/5. <i>Kody źródłowe / Kryteria powodzenia </i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"<h2> 4. <i>Kody źródłowe / Kryteria powodzenia </i>[laboratorium]</h2> \n",
|
||||
"<h3>Tomasz Piłka (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
@ -18,9 +18,9 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Opis laboratorium nr 4/5\n",
|
||||
"# Opis laboratorium nr 4\n",
|
||||
"\n",
|
||||
"Laboratorium będzie miało przebieg niezwiązany z żadnym wykładem z powodu dnia dziekańskiego w dniu 15 listopada. "
|
||||
"Od tego laboratorium praca podczas zajęć jest realizowana alternatywną ścieżką do pozostałych grup zajęciowych. Rozpoczynamy prace związane z implementacją projektu badawczego. "
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -29,11 +29,9 @@
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
"Podczas laboratorium poszczególne grupy pracować będą przez 60 minut (dla wyrównania dłuższych zajęć w dniu 9 listopada).\n",
|
||||
"\n",
|
||||
"Punkty zdobyte podczas tego laboratorium będą bonusowe - dodatkowe w stosunku do zaplanowanych na początku kursu. \n",
|
||||
"\n",
|
||||
"Wykonać można jedno lub dwa z zadań proponowanych poniżej - w zależności od potrzeb danego projektu - do uzgodnienia z prowadzącym:\n",
|
||||
"Proszę o wykonanie następujacych zadań (w kontekście realziowanego prjektu badawczego):\n",
|
||||
"\n",
|
||||
" 1. Odszukać ogólno-dostępne kody źrodłowe projektów podobnych do wykonywanego. Przeanalizować, czy kody źródłowe tych rozwiązań mogą być przydatne w projekcie. \n",
|
||||
" Możliwe pochodzenie otwartych kodów:\n",
|
||||
@ -49,7 +47,7 @@
|
||||
" * manualna\n",
|
||||
" * krytium lub kryteriów, których osiągnięcie uznane będzie za sukces projektu.\n",
|
||||
"\n",
|
||||
"Maksymalna ocena do uzsyakania na zajęciach to **20 punktów**, przy czym każdy prowadzący indywidualnie ustala z zespołem zakres prac do wykonania."
|
||||
"Maksymalna ocena do uzyskania na zajęciach to **20 punktów**."
|
||||
]
|
||||
}
|
||||
],
|
||||
@ -7,8 +7,8 @@
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 5. <i>Metodyka Prince2Agile</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"<h2> 6. <i>Metodyka Prince2</i> [laboratorium]</h2> \n",
|
||||
"<h3> Tomasz Piłka (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
@ -18,8 +18,8 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 5\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac w metodologii Prince lub Agile lub połączeniu obu metodologii."
|
||||
"# Cel laboratorium nr 6\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac w metodologii Prince2."
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -33,7 +33,7 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Na laboratorium mają zostać wykonane trzy z podanych niżej pięciu zadań - do wyboru."
|
||||
"Podczas laboratoirium w zespołach prjektowych nalezy wykonać następujące zadania. Rozwiązania lider zespołu przekazuje poprzez MS Teams."
|
||||
]
|
||||
},
|
||||
{
|
||||
@ -76,31 +76,6 @@
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 4. Role w projekcie według metodyki Scrum\n",
|
||||
"Podzielcie się rolami w projekcie według metodyki Scrum i opiszcie, jak widzicie swoje zadania w projekcie.\n",
|
||||
"\n",
|
||||
"Opracujcie 5-punktowy manifest pracy w Waszym zespole. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" ## Zadanie 5. Zakładamy backlog \n",
|
||||
"* Utwórzcie projekt w systemie JIRA. \n",
|
||||
"* Opracujcie profile członków grupy (zdjęcia mile widziane). \n",
|
||||
"* Wpiszcie do backloga \"user stories\" związane z projektem - założcie w tym momencie, że wykonacie cały produkt high-tech.\n",
|
||||
"* Sprobujcie oszacować czas realizacji każdego \"user story\" za pomocą punktów, zakładając że 10 punktów odpowiada sumie pracy całego zespołu podczas jednego tygodniowego sprintu. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów "
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
@ -7,8 +7,8 @@
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 14. <i>Zarządzanie pracami badawczo-rozwojowymi</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"<h2> 10. <i>Analiza postepu prac w projekcie badawczo-rozwojowym </i>[laboratorium]</h2> \n",
|
||||
"<h3>Tomasz Pilka (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
@ -18,18 +18,17 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cel laboratorium nr 14\n",
|
||||
"Celem laboratorium jest przygotowanie publicznej demonstracji projektu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Plan laboratorium\n",
|
||||
"Podczas laboratorium studenci demonstrują wykonany system informatyczny swojemu opiekunowi. \n",
|
||||
"Opiekun podejmuje decyzję, czy system jest na 6. poziomie gotowości technicznej. \n",
|
||||
"W przypadku pozytywnym wyraża zgodę na wykonanie demonstracji publicznej. "
|
||||
"# Cel laboratorium nr 10\n",
|
||||
"Celem laboratorium jest określenie postęu prac poszczególnych zespołów w realizacji projektów. \n",
|
||||
"\n",
|
||||
"# Plan laboratorium\n",
|
||||
"Podczas zajęć nie ma przypisanego zadania. Prowadzący prowadzi anaizę postępu prac w poszczególnych zespołach. Omawiane są założenia do zrealizowania w aktualnym kamieniu milowym, zaangażowanie członków zespołu, używane narzędzia do prowadzenia projektu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"Max 30 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
@ -54,7 +53,7 @@
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "14. Zarządzanie pracami badawczo-rozwojowymi[laboratorium]",
|
||||
"subtitle": "08. Testowanie w programowaniu zwinnym[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
@ -7,8 +7,8 @@
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 11. <i>Aspekty użyteczności</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"<h2> 11. <i>Raport z realizacji kamienia milowgo nr 2 </i>[laboratorium]</h2> \n",
|
||||
"<h3>Tomasz Pilka (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
@ -19,30 +19,24 @@
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 11\n",
|
||||
"Celem laboratorium jest przananalizowanie użyteczności projektowanego systemu pod różnymi aspektami."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Celem laboratorium jest określenie realizacji projektu na podstawie Kamienia milowego nr 2. \n",
|
||||
"\n",
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Aspekty użyteczności\n",
|
||||
"Wybierzcie z wykładu 15 pytań, które są najbardziej adekwatne do Waszej aplikacji i odpowiedzcie na nie. \n",
|
||||
"Wnioskiem z analizy ma być zmiana w backlogu Waszego projektu. Omówcie tę zmianę. \n",
|
||||
"Prowadzący prowadzi dyskusję z każdym z zespołów. Raport powstaje w trakcie laboratorium lub bezpośrednio po osiągnięciu kamienia milowego. (jeżeli kamień milowy kończy się po nich).\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Diagram Venna\n",
|
||||
"Opracujcie diagram Venna dla użytkowników Waszej aplikacji. \n",
|
||||
"Odpowiedzcie na pytanie, jaki wpływ na zadania planowane przez Waszą grupę może mieć ten diagram. \n",
|
||||
"## Zadanie \n",
|
||||
"Przygotować raport z realizacji kamienia milowego nr 2. W raporcie powinny znaleźć się informację związane z omówieniem zaimplementowanych rozwiązań, przygotowanych datasetów. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"W raporcie powinno również znaleźć się\n",
|
||||
" * odniesienie do realizacji (bieżące osiągnięcie) wskaźników\n",
|
||||
" * odniesienie do ryzyka zdefiniowanego w projekcie (czy wystąpiły, a jaki sposób zespół reagował na nie)\n",
|
||||
" * propozycje zmian w realizacji zadań w kolejnym sprincie.\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Wypełnienie raportu użyteczności\n",
|
||||
"Przeprowadźcie badanie użyteczności zgodnie z szablonem raportu przygotowanym na laboratorium nr 10. Wnioski z raportu wpiszcie do szablonu.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
"\n",
|
||||
" \n",
|
||||
"Max 30 punktów."
|
||||
]
|
||||
}
|
||||
],
|
||||
@ -67,7 +61,7 @@
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "11. Aspekty użyteczności[laboratorium]",
|
||||
"subtitle": "08. Testowanie w programowaniu zwinnym[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
@ -1,86 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 6. <i>Prototypowanie i ciagła integracja</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 6\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac implementacyjnych z zastosowaniem ciągłej integracji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Zorganizowanie repozytorium\n",
|
||||
"Załóżcie repozytorium Git na serwerze wydziałowym. Wstawcie do niego plik Readme. \n",
|
||||
"Sklonujcie repozytorium na maszynach lokalnych deweloperów. \n",
|
||||
"Zintegrujcie Wasz projekt w systemie Jira z wydziałowym serwerem Git (w tym celu zgłoście takie zadania w wydziałowym systemie Helpdesk, podając nazwę repozytorium Git oraz nazwę projektu Jira). \n",
|
||||
"Wykażcie, że integracja się powiodła, umieszczając w Teamsach zrzut ekranu obrazujący integrację Waszego projektu z Gitem. (Integracja przebiegła pomyślnie, jeśli informacja o commicie w systemie Git pojawia się automatycznie w systemie Jira.) \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Nasz prototyp\n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany prototyp za pomocą zaktualizowanej w stosunku do laboratorium nr 2 makiety dynamicznej. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## 3. Serwer ciągłej integracji\n",
|
||||
"Połączcie Wasze wydziałowe repozytorium Git z Jenkinsem (jenkins.wmi.amu.edu.pl). \n",
|
||||
"W celu utworzenia pipeline’u dla Waszego projektu utwórzcie zgłoszenie w systemie Helpdesk, podając login osoby odpowiedzialnej za projekt (sXXXXXX), nazwę projektu, a także ewentualne loginy innych członków zespołu, którzy mają mieć dostęp do projektu w Jenkinsie. \n",
|
||||
"Stwórzcie *Jenkinsfile* budujący Waszą aplikację oraz uruchamiający prosty test. \n",
|
||||
"\n",
|
||||
"Rozwiązaniem zadania będzie poprawnie zakończony pipeline zdefiniowany na podstawie *Jenkinsfile* (który musi zostać umieszczony w Waszym repozytorium Git). \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Pierwszy sprint!\n",
|
||||
"Zalóżcie pierwszy sprint. \n",
|
||||
"Przenieście wybrane elementy (\"issues\") z backloga do sprintu, podzielcie je na zadania, przypiszcie zadania ludziom i skomentujcie je (w ich opisie). \n",
|
||||
"Oszacujcie w punktach pracochłonność wykonania każdego zadania."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "06. Prototypowanie i ciagła integracja[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,189 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 1. <i>Organizacja pracy zespołowej</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Proponowana punktacja zadań wykonywanych na przedmiocie PBR\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Typ zadania</td> <td>Liczba punktów</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Zadania na laboratoriach</td><td>13 x 30 = 390</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Sprinty</td><td>6 x 10 = 60</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Ocena końcowa za wynik projektu</td><td>150</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>Suma</td><td>600</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Proponowana skala ocen na przedmiocie PBR\n",
|
||||
"<table>\n",
|
||||
" <tr>\n",
|
||||
" <td>Liczba punktów</td> <td>Ocena</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>500-600</td><td>5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>450-499</td><td>4,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>400-449</td><td>4</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>350-399</td><td>3,5</td>\n",
|
||||
" </tr>\n",
|
||||
" <tr>\n",
|
||||
" <td>300-349</td><td>3</td>\n",
|
||||
" </tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 1\n",
|
||||
"Celem laboratorium jest zamodelowanie sytuacji, w której zespół ludzi ma do wykonania zadanie wymagające zróżnicowanych umiejętnosci. Zadanie wykonywane jest pod presją czasu. \n",
|
||||
"Zadanie polega na opracowaniu założeń projektu badawczo-rozwojowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"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",
|
||||
"\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)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Proponowany plan laboratorium"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 1. Zorganizowanie zespołu projektowego.\n",
|
||||
"Czas wykonania: 30 minut. \n",
|
||||
"Rezultat: Dokument, zawierający informacje o liderze i pozostałych członkach zespołu oraz o opiekunie zespołu. \n",
|
||||
"Dla lidera należy podać: \n",
|
||||
" * Jego preferowany typ przywództwa wg charaketrystyki z wykładu,\n",
|
||||
" * Typ motywacji i podejścia do zadań (np. A1) według klasyfikacji podanej na wykładzie.\n",
|
||||
" \n",
|
||||
"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"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 2. Burza mózgów i praca indywidualna\n",
|
||||
"Czas: 30 minut.\n",
|
||||
"\n",
|
||||
"Przebieg: Studenci dyskutują nad wizją projektu, którą chcą przedstawić jako efekt pracy na Laboratorium nr. 1. Może to być projekt, który zespół planuje implementować na przyszłych zajęciach. Jeśli takich planów nie ma, można opracować wizję systemu do prowadzenia testów na wykładach prowadzonych na WMI (lepszego od cybertest!). \n",
|
||||
"\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",
|
||||
" \n",
|
||||
"Maksymalna ocena: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" ## Zadanie 3. Praca zespołowa\n",
|
||||
"Czas: 30 minut. \n",
|
||||
" \n",
|
||||
"Cel: przedstawienie wspólnej wizji projektu. \n",
|
||||
"\n",
|
||||
"Rezultat:\n",
|
||||
" * jeden szkich interfejsu lub schematu działania wykonany w dowolnym programie graficznym (np. figma);\n",
|
||||
" * jeden dokument (10-15 zdań) opisujący działanie projektowanego systemu.\n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 15 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.7.6"
|
||||
},
|
||||
"subtitle": "01. Praca zespołowa[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,95 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 2. <i>Pojęcie projektu badawczo-rozwojowego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium\n",
|
||||
"\n",
|
||||
"Celem laboratorium jest opracowanie koncepcji projektu badawczo-rozwojowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Organizacja zespółów projektowych na laboratorium nr 2\n",
|
||||
"W stosunku do laboratorium nr. 1 studenci mogą zorganizować się w nowe grupy. \n",
|
||||
"Można opracować koncepcję zupełnie nowego projektu badawczo-rozwojowego lub kontynuować projekt z poprzednich zajęć. Liderem zespołu może być dowolna osoba. \n",
|
||||
"\n",
|
||||
"Składy zespołów mogą zmieniać się do zajęć nr 3 włącznie.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium nr 2\n",
|
||||
"\n",
|
||||
"## Zadanie 1. Makieta dynamiczna \n",
|
||||
"Skonstruujcie jeden prototyp wymarzonego systemu w postaci mockupu dynamicznego.\n",
|
||||
"\n",
|
||||
"Przykładowa aplikacja on-line: https://www.figma.com. \n",
|
||||
"Wybór narzędzia należy jednak do Was. Omówienie bezpłatnych narzędzi do makiet dynamicznych: \n",
|
||||
"https://invette.pl/blog/najlepsze-narzedzia-dla-ui-ux/. \n",
|
||||
"Rezultatem zadania jest makieta zapisana jako strona HTML, czyli spakowany plik zawierający plik (np. prototyp.htm) oraz powiązany folder (np. prototyp_pliki). \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Rozwiązania konkurencyjne \n",
|
||||
"1. Znajdźcie dwa lub trzy rozwiązania z podobnej dziedziny do Waszego rozwiązania. Omówcie je i potencjalnie pokażcie (za pomocą zrzutów ekranu). \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
"\n",
|
||||
"2. Przeprowadźcie analizę porównawczą Waszego pomysłu i rozwiązań konkurencyjnych. \n",
|
||||
"Wybierzcie 3-4 zasady z 9 zasad sukcesu produktu high-tech, według których wykażecie przewagę Waszego rozwiązania nad rozwiązaniami konkurecyjnymi \n",
|
||||
"Maksymalna ocena: 5 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Poziomy gotowości technologicznej\n",
|
||||
"Przedstawcie, jak wyobrażacie sobie poszczególne poziomy gotowości technologicznej dla Waszego projektu. \n",
|
||||
"Maksymalna ocena: 5 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": "02. Pojęcie projektu badawczo-rozwojowego[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,70 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 3. <i>Prezentacja koncepcji projektu B+R</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cel i efekty laboratorium\n",
|
||||
"Celem laboratorium jest opracowanie koncepcji projektu B+R: (produktu HT / usługi / przedsięwzięcia), który będzie realizowany w ramach projektu zespołówego.\n",
|
||||
"\n",
|
||||
"Wynikami pracy będą:\n",
|
||||
" * jedno-zdaniowy \"elevator pitch\" \n",
|
||||
" * prezentacja w formie slajdów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadania\n",
|
||||
"### Zadanie 1. Elevator pitch w jednym zdaniu - 5 punktów \n",
|
||||
"Każdy członek grupy przygotowuje indywidualnie jednozdaniowy \"elevator pitch\" wg wzorca podanego na wykładzie.\n",
|
||||
"Następnie grupa opracowuje jeden wzorzec jako syntezę najlepszych pomysłów indywidualnych członków.\n",
|
||||
"Odpowiedź zawiera n (liczba członków zespołu) rozwiązań + jedno finalne.\n",
|
||||
"\n",
|
||||
"### Zadanie 2. Prezentacje dla inwestora - 15 punktów \n",
|
||||
"Każdy członek grupy przygotowuje indywidualnie prezentację dla inwestora wg wzorca podanego na wykładzie. UWAGA: slajd dotyczący prognozy finansowej należy raczej pominąć. Zamiast niego obowiązkowo powinien znaleźć się slajd(y) możliwie szczegółowo wyjaśniający(e), jaka część projektu zostanie prawdopodobnie zrealizowana podczas kursu SI.\n",
|
||||
"Odpowiedź zawiera n (liczba członków zespołu) rozwiązań. \n",
|
||||
"Uwaga: Obowiązkowym slajdem jest analiza konkurencji (która może być wykonana wspólnie, a przedstawiona na różne sposoby).\n",
|
||||
"\n",
|
||||
"### Zadanie 3. Końcowa wersja prezentacji - 10 punktów\n",
|
||||
"W odpowiedzi na tę misję zostawcie prezentację, która Waszym zdaniem jest syntezą najlepszych części prezentacji indywidualnych."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.7.6"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,83 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 4/5. <i>Kody źródłowe / Kryteria powodzenia </i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Opis laboratorium nr 4/5\n",
|
||||
"\n",
|
||||
"Laboratorium będzie miało przebieg niezwiązany z żadnym wykładem z powodu dnia dziekańskiego w dniu 15 listopada. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
"Podczas laboratorium poszczególne grupy pracować będą przez 60 minut (dla wyrównania dłuższych zajęć w dniu 9 listopada).\n",
|
||||
"\n",
|
||||
"Punkty zdobyte podczas tego laboratorium będą bonusowe - dodatkowe w stosunku do zaplanowanych na początku kursu. \n",
|
||||
"\n",
|
||||
"Wykonać można jedno lub dwa z zadań proponowanych poniżej - w zależności od potrzeb danego projektu - do uzgodnienia z prowadzącym:\n",
|
||||
"\n",
|
||||
" 1. Odszukać ogólno-dostępne kody źrodłowe projektów podobnych do wykonywanego. Przeanalizować, czy kody źródłowe tych rozwiązań mogą być przydatne w projekcie. \n",
|
||||
" Możliwe pochodzenie otwartych kodów:\n",
|
||||
" * platformy dedykowane do danego rozwiązania,\n",
|
||||
" * projekty na GitHubie,\n",
|
||||
" * biblioteki programistyczne. \n",
|
||||
" \n",
|
||||
" 2. Kryteria sukcesu projektu\n",
|
||||
"Zadanie polega na określeniu:\n",
|
||||
" * miary jakości osiągniętego rozwiązania\n",
|
||||
" * metody ewaluacji jakości:\n",
|
||||
" * automatyczna lub\n",
|
||||
" * manualna\n",
|
||||
" * krytium lub kryteriów, których osiągnięcie uznane będzie za sukces projektu.\n",
|
||||
"\n",
|
||||
"Maksymalna ocena do uzsyakania na zajęciach to **20 punktów**, przy czym każdy prowadzący indywidualnie ustala z zespołem zakres prac do wykonania."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "04/05. Kody żródłowe / Kryteria sukcesu[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,6 +0,0 @@
|
||||
{
|
||||
"cells": [],
|
||||
"metadata": {},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,67 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 4. <i>Publiczne prezentacje projektów</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,94 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 5. <i>Metodyka Prince2Agile</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 5\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac w metodologii Prince2Agile."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 1. Zadanie związane z metodologią Prince2\n",
|
||||
"TO DO \n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" ## Zadanie 2. Zaczynamy pracować zwinnie\n",
|
||||
"Podzielcie się rolami w projekcie i opiszcie, jak widzicie swoje zadania w projekcie:\n",
|
||||
"* zespół deweloperski, a w nim scrum master\n",
|
||||
"* zespół product ownera, a w nim tester\n",
|
||||
"\n",
|
||||
"Opracujcie 5-punktowy manifest pracy w Waszym zespole. \n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" ## Zadanie 3. Zakładamy backlog \n",
|
||||
"* Utwórzcie projekt w systemie JIRA. \n",
|
||||
"* Opracujcie profile członków grupy (zdjęcia mile widziane). \n",
|
||||
"* Wpiszcie do backloga \"user stories\" związane z projektem - założcie w tym momencie, że wykonacie cały produkt high-tech.\n",
|
||||
"* Sprobujcie oszacować czas realizacji każdego \"user story\" za pomocą punktów, zakładając że 10 punktów odpowiada sumie pracy całego zespołu podczas jednego tygodniowego sprintu. \n",
|
||||
"Ocena maksymalna: 10 punktów "
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "05. Metodologia Prince2Agile[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,137 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 5. <i>Metodyka Prince2Agile</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 5\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac w metodologii Prince lub Agile lub połączeniu obu metodologii."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"Na laboratorium mają zostać wykonane trzy z podanych niżej pięciu zadań - do wyboru."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 1. Motywy przewodnie Prince2\n",
|
||||
"### 1. Potrzeba biznesowa\n",
|
||||
"Wyjaśnijcie genezę projektu. Kto będzie korzystał z projektu, jaka jest potrzeba biznesowa (dlaczego i komu przyniesie korzyści finansowe)? \n",
|
||||
"Podajcie jakie są grupy interesariuszy projektu: biznes, użytkownicy, dostawca.\n",
|
||||
"\n",
|
||||
"### 2. Jakość\n",
|
||||
"Jakie są aspekty jakości, które ma spełniać tworzony produkt (np. szybkość działania, użyteczność, funkcjonalność)? W jaki sposób można zmierzyć jakość pod wzgledem tych aspektów? Jakie stawiamy kryteria jakości w tych aspektach?\n",
|
||||
"\n",
|
||||
"### 3. Plany\n",
|
||||
"Podzielcie projekt na etapy. Dla poszczególnych etapów zdefiniujcie, co powinno być ich efektem.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 2. Role w projekcie według metodyki Prince 2\n",
|
||||
"Przydzielcie osobom wszystkie role według metodyki Prince 2.\n",
|
||||
"Wyjaśnijcie, jak te role będą przekładać się na konkretne czynności w Waszym projekcie.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 3. Analiza ryzyka\n",
|
||||
"\n",
|
||||
"Spróbuj wykonać uproszczoną analizę ryzyka projektu według wskazówek podanych w Encyklopedii Zarządzania:\n",
|
||||
"https://mfiles.pl/pl/index.php/Analiza_ryzyka\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Zadanie 4. Role w projekcie według metodyki Scrum\n",
|
||||
"Podzielcie się rolami w projekcie według metodyki Scrum i opiszcie, jak widzicie swoje zadania w projekcie:\n",
|
||||
"* zespół deweloperski, a w nim scrum master\n",
|
||||
"* zespół product ownera, a w nim tester\n",
|
||||
"\n",
|
||||
"Opracujcie 5-punktowy manifest pracy w Waszym zespole. \n",
|
||||
"\n",
|
||||
"Podsumujcie, która metodyka pracy bardziej Wam odpowiada pod kątem podziału ról. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" ## Zadanie 5. Zakładamy backlog \n",
|
||||
"* Utwórzcie projekt w systemie JIRA. \n",
|
||||
"* Opracujcie profile członków grupy (zdjęcia mile widziane). \n",
|
||||
"* Wpiszcie do backloga \"user stories\" związane z projektem - założcie w tym momencie, że wykonacie cały produkt high-tech.\n",
|
||||
"* Sprobujcie oszacować czas realizacji każdego \"user story\" za pomocą punktów, zakładając że 10 punktów odpowiada sumie pracy całego zespołu podczas jednego tygodniowego sprintu. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów "
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "05. Metodologia Prince2Agile[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,86 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 6. <i>Prototypowanie i ciagła integracja</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 6\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac implementacyjnych z zastosowaniem ciągłej integracji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Zorganizowanie repozytorium\n",
|
||||
"Załóżcie repozytorium Git na serwerze wydziałowym. Wstawcie do niego plik Readme. \n",
|
||||
"Sklonujcie repozytorium na maszynach lokalnych deweloperów. \n",
|
||||
"Zintegrujcie Wasz projekt w systemie Jira z wydziałowym serwerem Git (w tym celu zgłoście takie zadania w wydziałowym systemie Helpdesk, podając nazwę repozytorium Git oraz nazwę projektu Jira). \n",
|
||||
"Wykażcie, że integracja się powiodła, umieszczając w Teamsach zrzut ekranu obrazujący integrację Waszego projektu z Gitem. (Integracja przebiegła pomyślnie, jeśli informacja o commicie w systemie Git pojawia się automatycznie w systemie Jira.) \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Nasz prototyp\n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany system za pomocą prototypu papierowego.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## 3. Serwer ciągłej integracji\n",
|
||||
"Połączcie Wasze wydziałowe repozytorium Git z Jenkinsem (jenkins.wmi.amu.edu.pl). \n",
|
||||
"W celu utworzenia pipeline’u dla Waszego projektu utwórzcie zgłoszenie w systemie Helpdesk, podając login osoby odpowiedzialnej za projekt (sXXXXXX), nazwę projektu, a także ewentualne loginy innych członków zespołu, którzy mają mieć dostęp do projektu w Jenkinsie. \n",
|
||||
"Stwórzcie *Jenkinsfile* budujący Waszą aplikację oraz uruchamiający prosty test. \n",
|
||||
"\n",
|
||||
"Rozwiązaniem zadania będzie poprawnie zakończony pipeline zdefiniowany na podstawie *Jenkinsfile* (który musi zostać umieszczony w Waszym repozytorium Git). \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Pierwszy sprint!\n",
|
||||
"Zalóżcie pierwszy sprint. \n",
|
||||
"Przenieście wybrane elementy (\"issues\") z backloga do sprintu, podzielcie je na zadania, przypiszcie zadania ludziom i skomentujcie je (w ich opisie). \n",
|
||||
"Oszacujcie w punktach pracochłonność wykonania każdego zadania."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "06. Prototypowanie i ciagła integracja[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,79 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 7. <i>Specyfikacja projektu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 7\n",
|
||||
"Celem laboratorium jest opracowanie specyfikacji systemu informatycznego będącego wynikiem projektu B+R.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Aktorzy i ich oczekiwania\n",
|
||||
"Dla tworzonego systemu:\n",
|
||||
"* Określ charakterystykę poszczególnych użytkowników systemu.\n",
|
||||
"* Sporządź listę aktor - cel.\n",
|
||||
"* Sporządź tabelę IN-OUT. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
" \n",
|
||||
"## Zadanie 2. Specyfikacja wymagań\n",
|
||||
"Sporządź specyfikację wymagań funkcjonalnych i niefunkcjonalnych: \n",
|
||||
"* każde wymaganie funckjonalne w osobnej tabelce; \n",
|
||||
"* wszystkie wymagania niefunkcjonalne w jednej tabelce razem. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Przypadki użycia\n",
|
||||
"Wykonaj pełną specyfikację trzech wybranych przypadków użycia swojego systemu. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "07. Specyfikacja projektu informatycznego[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,72 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 9. <i>Testowanie integracyjne i systemowe</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 9\n",
|
||||
"Celem laboratorium jest opracowanie planu testów integracyjnych i systemowych oraz przeprowadzenie prostego eksperymentu z testowaniem automatycznym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
" ## Zadanie 1. Testy systemowe\n",
|
||||
"Opracujcie plan testów, zawierający przypadki testowe. \n",
|
||||
"Należy założyć, że testy mają obejmować co najmniej 3 typy testowania. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 20 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Testy automatyczne\n",
|
||||
"Korzystając z frameworku Selenium opracujcie test automatyczny, sprawdzający jakąś podstawową funkcjonalność Waszego systemu (np. logowanie.) \n",
|
||||
"(W zastępstwie można opracować test automatyczny logowania do jednego z systemów: USOS, Jira lub Git.) \n",
|
||||
"Jako wynik zadania umieśćcie nagranie testu. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "09. Testowanie integracyjne i systemowe[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,75 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 10. <i>Wybrane zagadnienia użyteczności</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 10\n",
|
||||
"Celem laboratorium jest nabycie umiejętności analizy systemu informatycznego pod kątem jego użyteczności.\n",
|
||||
"Stworzony zostanie ponadto szablon raportu użyteczności."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
"## Zadanie 1. Analiza użyteczności systemu\n",
|
||||
"Przeanalizujcie treści z wykładu pod kątem Waszego projektu. Dla każdej **wskazówki do tworzenia użytecznego systemu informatycznego** określ (i omów), czy: \n",
|
||||
"A) została przez Was już uwzględniona \n",
|
||||
"B) nie została przez Was uwzględniona, bo nie dotyczy projektu \n",
|
||||
"C) nie została przez Was uwzględniona, choć powinna, ale jest za mało czasu, by to zmienić \n",
|
||||
"D) nie została przez Was uwzględniona, ale uda się to nadrobić. \n",
|
||||
"\n",
|
||||
"Maskymalna ocena: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Przygotowanie raportu użyteczności\n",
|
||||
"Przygotujcie raport badania użyteczności dla Waszego systemu - pozostawiając do wypełnienia przebieg badania i wnioski z badania (dokumenty te zostaną wypełnione na przyszłych zajęciach). \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 20 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": "10. Wybrane zagadnienia użyteczności",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,76 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. <i>Aspekty użyteczności</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 11\n",
|
||||
"Celem laboratorium jest przananalizowanie użyteczności projektowanego systemu pod różnymi aspektami."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Aspekty użyteczności\n",
|
||||
"Wybierzcie z wykładu 15 pytań, które są najbardziej adekwatne do Waszej aplikacji i odpowiedzcie na nie. \n",
|
||||
"Wnioskiem z analizy ma być zmiana w backlogu Waszego projektu. Omówcie tę zmianę. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Diagram Venna\n",
|
||||
"Opracujcie diagram Venna dla użytkowników Waszej aplikacji. \n",
|
||||
"Odpowiedzcie na pytanie, jaki wpływ na zadania planowane przez Waszą grupę może mieć ten diagram. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Wypełnienie raportu użyteczności\n",
|
||||
"Przeprowadźcie badanie użyteczności zgodnie z szablonem raportu przygotowanym na laboratorium nr 10. Wnioski z raportu wpiszcie do szablonu.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "11. Aspekty użyteczności[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,84 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 12. <i>Ocena jakości systemu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 12\n",
|
||||
"Celem laboratorium jest określenie funkcji, która wylicza ogólną jakość projektowanego systemu na podstawie oceny jego poszczególnych cech."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
"## Zadanie 1. Metryki kodu\n",
|
||||
"Zbadajcie LOC Waszego systemu i na tej podstawie obliczcie wykonane już punkty funkcyjne. \n",
|
||||
"Obliczcie metryki Haelsteada dla wybranej funkcji w Waszym kodzie i porównajcie z własnym doświadczeniem. \n",
|
||||
"Dla wybranej klasy zróbcie analizę metryk WMC i RFC. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów \n",
|
||||
"\n",
|
||||
"## Zadanie 2. Jakość podobnego systemu\n",
|
||||
"Wyszukajcie istniejącą, dostępną aplikację, możliwie najbardziej zbliżoną do Waszej pod względem funkcjonalności i użyteczności. \n",
|
||||
"Oceńcie punktowo (np. w skali od 1 do 10) jakość systemu - każdy członek grupy osobno:\n",
|
||||
" * każdą z cech systemu podanych w schemacie FURPS, CUPRIMDA lub CUPRIMDSO (schemat do wyboru).\n",
|
||||
" * ogólną satysfakcję z systemu (w przypadku CUPRIMDSO ogólna satysfakcja zawarta jest w cesze oznaczonej przez O, więc nie ma sensu jej powtarzać). \n",
|
||||
" \n",
|
||||
"Wyniki oceny zaprezentujcie w tabeli (Excel).\n",
|
||||
"Zaproponujcie wzór dla zdefiniowania ogólnej satysfakcji z systemu jako funkcji ocen cząstkowych, tak aby korelacja wyników ze wzoru i ocen użytkowników była bliska 1. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Jakość Waszego systemu.\n",
|
||||
"Poddajcie Wasz system (ostatnia działająca wersja) pod ocenę pięciu osobom spoza Waszej grupy dokładnie według tych samych zasad, jak w zadaniu 2. \n",
|
||||
"Sprawdżcie korelację wyników operatora agregacji z ocenami ogólnymi systemu (czy oceny wyliczane za pomocą agregacji \"zgadzają się\" z ocenami ludzkimi). \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "12. Ocena jakości systemu informatycznego[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,69 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 13. <i>Planowanie prac badawczo-rozwojowych</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 13\n",
|
||||
"\n",
|
||||
"Celem laboratorium jest opracowanie harmonogramu wstecznego dla zadań wykonanych w trakcie przedmiotu Projekt badawczo-rozwojowy. Harmonogram uwzględniać ma ponadto zadania planowane do wykonania w drugim semestrze."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"Utwórzcie harmonogram wykonania zadań utworzony w programie MS-Project. \n",
|
||||
"Harmonogram powinien odtwarzać autentyczne terminy zadań już wykonanych. \n",
|
||||
"Ponadto harmonogram zawierać ma zadania do wykonania do końca 1. semestru oraz w 2. semestrze przedmiotu Projekt badawczo-rozwojowy. \n",
|
||||
"Dokumentację wyniku zadania będą stanowić:\n",
|
||||
"* plik .mpp,\n",
|
||||
"* wydruk wykresu Gantta (zawierający m.in. procent aktualnego wykonania każdego zadania),\n",
|
||||
"* odpowiednie raporty potwierdzające poprawność przydzielenia zasobów,\n",
|
||||
"* dotychczasową estymację kosztów wykonania projektu; ceny jednostkowe za zasoby (w tym osobogodziny) powinny opierać się na udokumentowanych źródłach."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "13. Planowanie prac badawczo-rozwojowych[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,63 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 14. <i>Zarządzanie pracami badawczo-rozwojowymi</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cel laboratorium nr 14\n",
|
||||
"Celem laboratorium jest przygotowanie publicznej demonstracji projektu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Plan laboratorium\n",
|
||||
"Podczas laboratorium studenci demonstrują wykonany system informatyczny swojemu opiekunowi. \n",
|
||||
"Opiekun podejmuje decyzję, czy system jest na 6. poziomie gotowości technicznej. \n",
|
||||
"W przypadku pozytywnym wyraża zgodę na wykonanie demonstracji publicznej. "
|
||||
]
|
||||
}
|
||||
],
|
||||
"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. Praca zespołowa[laboratorium]",
|
||||
"title": "Zarządzanie pracami badawczo-rozwojowymi",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,66 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 15. <i>Demonstracja wyników projektu badawczo-rozwojowego - wnioski</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cel laboratorium nr 15\n",
|
||||
"Celem laboratorium jest wyciągnięcie wniosków z demonstracji projektu badawczo-rozwojowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Dyskusja i ocena projektu\n",
|
||||
"Opiekun projektu przeprowadza z zespołem projektowym dyskusję na temat demonstracji wyników projektu badawczo-rozwojowego. Wynikiem dyskusji jest ocena projektu.\n",
|
||||
"## Ocena końcowa z przedmiotu Projekt badawczo-rozwojowy.\n",
|
||||
"Opiekun wystawia oceny końcowe studentom. Oceny mogą się różnić między osobami w grupie, jeśli:\n",
|
||||
" * skład grupy zmieniał się na początkowych zajęciach,\n",
|
||||
" * niektórzy studenci nie brali udziału we wszystkich zajęciach."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "15. Demonstracja projektu[laboratorium]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,86 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 6. <i>Prototypowanie i ciagła integracja</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 6\n",
|
||||
"Celem laboratorium jest rozpoczęcie prac implementacyjnych z zastosowaniem ciągłej integracji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Zorganizowanie repozytorium\n",
|
||||
"Załóżcie repozytorium Git na serwerze wydziałowym. Wstawcie do niego plik Readme. \n",
|
||||
"Sklonujcie repozytorium na maszynach lokalnych deweloperów. \n",
|
||||
"Zintegrujcie Wasz projekt w systemie Jira z wydziałowym serwerem Git (w tym celu zgłoście takie zadania w wydziałowym systemie Helpdesk, podając nazwę repozytorium Git oraz nazwę projektu Jira). \n",
|
||||
"Wykażcie, że integracja się powiodła, umieszczając w Teamsach zrzut ekranu obrazujący integrację Waszego projektu z Gitem. (Integracja przebiegła pomyślnie, jeśli informacja o commicie w systemie Git pojawia się automatycznie w systemie Jira.) \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Nasz prototyp\n",
|
||||
"Określ typ prototypu opracowanego na zajęciach (na skali: pionowy - poziomy). Zilustruj projektowany system za pomocą prototypu papierowego.\n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## 3. Serwer ciągłej integracji\n",
|
||||
"Połączcie Wasze wydziałowe repozytorium Git z Jenkinsem (jenkins.wmi.amu.edu.pl). \n",
|
||||
"W celu utworzenia pipeline’u dla Waszego projektu utwórzcie zgłoszenie w systemie Helpdesk, podając login osoby odpowiedzialnej za projekt (sXXXXXX), nazwę projektu, a także ewentualne loginy innych członków zespołu, którzy mają mieć dostęp do projektu w Jenkinsie. \n",
|
||||
"Stwórzcie *Jenkinsfile* budujący Waszą aplikację oraz uruchamiający prosty test. \n",
|
||||
"\n",
|
||||
"Rozwiązaniem zadania będzie poprawnie zakończony pipeline zdefiniowany na podstawie *Jenkinsfile* (który musi zostać umieszczony w Waszym repozytorium Git). \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Drugi sprint!\n",
|
||||
"Zalóżcie drugi sprint. \n",
|
||||
"Przenieście wybrane elementy (\"issues\") z backloga do sprintu, podzielcie je na zadania, przypiszcie zadania ludziom i skomentujcie je (w ich opisie). \n",
|
||||
"Oszacujcie w punktach pracochłonność wykonania każdego zadania."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "06. Prototypowanie i ciagła integracja[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,79 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 7. <i>Specyfikacja projektu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 7\n",
|
||||
"Celem laboratorium jest opracowanie specyfikacji systemu informatycznego będącego wynikiem projektu B+R.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Zadanie 1. Aktorzy i ich oczekiwania\n",
|
||||
"Dla tworzonego systemu:\n",
|
||||
"* Określ charakterystykę poszczególnych użytkowników systemu.\n",
|
||||
"* Sporządź listę aktor - cel.\n",
|
||||
"* Sporządź tabelę IN-OUT. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
" \n",
|
||||
"## Zadanie 2. Specyfikacja wymagań\n",
|
||||
"Sporządź specyfikację wymagań funkcjonalnych i niefunkcjonalnych: \n",
|
||||
"* każde wymaganie funckjonalne w osobnej tabelce; \n",
|
||||
"* wszystkie wymagania niefunkcjonalne w jednej tabelce razem. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Przypadki użycia\n",
|
||||
"Wykonaj pełną specyfikację trzech wybranych przypadków użycia swojego systemu. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "07. Specyfikacja projektu informatycznego[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,73 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 8. <i>Testowanie w programowaniu zwinnym</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 8\n",
|
||||
"Celem laboratorium jest opracowaniu testów mających zastosowanie w programowaniu zwinnnym.\n",
|
||||
"\n",
|
||||
"# Proponowany plan laboratorium\n",
|
||||
"## Zadanie 1.\n",
|
||||
"Wykorzystać wiedzę z wykładu do opracowania dwóch typów nowych testów jednostkowych. Proponowane typy testów to \"mock\" oraz \"stub\". \n",
|
||||
"\n",
|
||||
"10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2.\n",
|
||||
"Dla istniejącej wersji projektowanego systemu:\n",
|
||||
" * Opracować kilka przypadków testowych skłądających się z jednej akcji;\n",
|
||||
" * Opracować jeden przypadek testowy ze scenariuszem składającym się z kilku kroków.\n",
|
||||
" \n",
|
||||
"10 punktów\n",
|
||||
" \n",
|
||||
"## Zadanie 3.\n",
|
||||
"Zbudować podwaliny pod metodę \"Test first\" poprzez opracowaie przypadków testowych funkcji systemu, które nie zostały jeszcze zaimplementowane:\n",
|
||||
" * Opracować kilka przypadków testowych skłądających się z jednej akcji;\n",
|
||||
" * Opracować jeden przypadek testowy ze scenariuszem składającym się z kilku kroków.\n",
|
||||
" \n",
|
||||
"10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "08. Testowanie w programowaniu zwinnym[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,72 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 9. <i>Testowanie integracyjne i systemowe</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 9\n",
|
||||
"Celem laboratorium jest opracowanie planu testów integracyjnych i systemowych oraz przeprowadzenie prostego eksperymentu z testowaniem automatycznym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
" ## Zadanie 1. Testy systemowe\n",
|
||||
"Opracujcie plan testów, zawierający przypadki testowe. \n",
|
||||
"Należy założyć, że testy mają obejmować co najmniej 3 typy testowania. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 20 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 2. Testy automatyczne\n",
|
||||
"Korzystając z frameworku Selenium opracujcie test automatyczny, sprawdzający jakąś podstawową funkcjonalność Waszego systemu (np. logowanie.) \n",
|
||||
"(W zastępstwie można opracować test automatyczny logowania do jednego z systemów: USOS, Jira lub Git.) \n",
|
||||
"Jako wynik zadania umieśćcie nagranie testu. \n",
|
||||
"\n",
|
||||
"Maksymalna ocena: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "09. Testowanie integracyjne i systemowe[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,84 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 12. <i>Ocena jakości systemu informatycznego</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 12\n",
|
||||
"Celem laboratorium jest określenie funkcji, która wylicza ogólną jakość projektowanego systemu na podstawie oceny jego poszczególnych cech."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"\n",
|
||||
"## Zadanie 1. Metryki kodu\n",
|
||||
"Zbadajcie LOC Waszego systemu i na tej podstawie obliczcie wykonane już punkty funkcyjne. \n",
|
||||
"Obliczcie metryki Haelsteada dla wybranej funkcji w Waszym kodzie i porównajcie z własnym doświadczeniem. \n",
|
||||
"Dla wybranej klasy zróbcie analizę metryk WMC i RFC. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów \n",
|
||||
"\n",
|
||||
"## Zadanie 2. Jakość podobnego systemu\n",
|
||||
"Wyszukajcie istniejącą, dostępną aplikację, możliwie najbardziej zbliżoną do Waszej pod względem funkcjonalności i użyteczności. \n",
|
||||
"Oceńcie punktowo (np. w skali od 1 do 10) jakość systemu - każdy członek grupy osobno:\n",
|
||||
" * każdą z cech systemu podanych w schemacie FURPS, CUPRIMDA lub CUPRIMDSO (schemat do wyboru).\n",
|
||||
" * ogólną satysfakcję z systemu (w przypadku CUPRIMDSO ogólna satysfakcja zawarta jest w cesze oznaczonej przez O, więc nie ma sensu jej powtarzać). \n",
|
||||
" \n",
|
||||
"Wyniki oceny zaprezentujcie w tabeli (Excel).\n",
|
||||
"Zaproponujcie wzór dla zdefiniowania ogólnej satysfakcji z systemu jako funkcji ocen cząstkowych, tak aby korelacja wyników ze wzoru i ocen użytkowników była bliska 1. \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów\n",
|
||||
"\n",
|
||||
"## Zadanie 3. Jakość Waszego systemu.\n",
|
||||
"Poddajcie Wasz system (ostatnia działająca wersja) pod ocenę pięciu osobom spoza Waszej grupy dokładnie według tych samych zasad, jak w zadaniu 2. \n",
|
||||
"Sprawdżcie korelację wyników operatora agregacji z ocenami ogólnymi systemu (czy oceny wyliczane za pomocą agregacji \"zgadzają się\" z ocenami ludzkimi). \n",
|
||||
"\n",
|
||||
"Ocena maksymalna: 10 punktów"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "12. Ocena jakości systemu informatycznego[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,69 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 13. <i>Planowanie prac badawczo-rozwojowych</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Cel laboratorium nr 13\n",
|
||||
"\n",
|
||||
"Celem laboratorium jest opracowanie harmonogramu wstecznego dla zadań wykonanych w trakcie przedmiotu Projekt badawczo-rozwojowy. Harmonogram uwzględniać ma ponadto zadania planowane do wykonania w drugim semestrze."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"Utwórzcie harmonogram wykonania zadań utworzony w programie MS-Project. \n",
|
||||
"Harmonogram powinien odtwarzać autentyczne terminy zadań już wykonanych. \n",
|
||||
"Ponadto harmonogram zawierać ma zadania do wykonania do końca 1. semestru oraz w 2. semestrze przedmiotu Projekt badawczo-rozwojowy. \n",
|
||||
"Dokumentację wyniku zadania będą stanowić:\n",
|
||||
"* plik .mpp,\n",
|
||||
"* wydruk wykresu Gantta (zawierający m.in. procent aktualnego wykonania każdego zadania),\n",
|
||||
"* odpowiednie raporty potwierdzające poprawność przydzielenia zasobów,\n",
|
||||
"* dotychczasową estymację kosztów wykonania projektu; ceny jednostkowe za zasoby (w tym osobogodziny) powinny opierać się na udokumentowanych źródłach."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "13. Planowanie prac badawczo-rozwojowych[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,66 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Projekt badawczo-rozwojowy</h1>\n",
|
||||
"<h2> 15. <i>Demonstracja wyników projektu badawczo-rozwojowego - wnioski</i>[laboratorium]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cel laboratorium nr 15\n",
|
||||
"Celem laboratorium jest wyciągnięcie wniosków z demonstracji projektu badawczo-rozwojowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Plan laboratorium\n",
|
||||
"## Dyskusja i ocena projektu\n",
|
||||
"Opiekun projektu przeprowadza z zespołem projektowym dyskusję na temat demonstracji wyników projektu badawczo-rozwojowego. Wynikiem dyskusji jest ocena projektu.\n",
|
||||
"## Ocena końcowa z przedmiotu Projekt badawczo-rozwojowy.\n",
|
||||
"Opiekun wystawia oceny końcowe studentom. Oceny mogą się różnić między osobami w grupie, jeśli:\n",
|
||||
" * skład grupy zmieniał się na początkowych zajęciach,\n",
|
||||
" * niektórzy studenci nie brali udziału we wszystkich zajęciach."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "15. Demonstracja projektu[laboratorium]",
|
||||
"title": "Projekt badawczo-rozwojowy",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,274 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 1. <i>Praca zespołowa</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Praca zespołowa w projekcie badawczo-rozwojowym\n",
|
||||
"## Cele wykładu\n",
|
||||
"1. Stworzenie zespołów projektowych\n",
|
||||
"2. Zapewnienie dobrej współpracy w zespołach\n",
|
||||
"3. Wybór liderów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Jak działa nasza pamięć?\n",
|
||||
"## Rodzaje pamięci\n",
|
||||
"### Pamięć sensoryczna\n",
|
||||
"Pamięć sensoryczna to inaczej pamięć zmysłów.\n",
|
||||
"#### Charaterystyka pamięci sensorycznej\n",
|
||||
"* krótki czas trwania (do ok. 0,5 s),\n",
|
||||
"* duża pojemność (ok. 99% nadchodzących informacji),\n",
|
||||
"* powiązanie ze zmysłami (węch, wzrok, dotych, słuch, smak)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\"> \n",
|
||||
"<h2>Przykład</h2>\n",
|
||||
" \n",
|
||||
"Dźwięk słyszymy przez pewien czas (min. 0,5 sek. - nawet gdy trwa krócej)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Interakcje pamięci sensorycznej\n",
|
||||
"Informacje z pamięci sensorycznej przekazywane są do pamięci krótkotrwałej.\n",
|
||||
"\n",
|
||||
"### Pamięć krótkotrwała\n",
|
||||
"Przechowuje niewielkie ilości informacji przez krótki okres (bez dokonywania powtórek: kilka do kilkunastu sekund).\n",
|
||||
"\n",
|
||||
"#### Interakcje pamięci krótkotrwałej\n",
|
||||
"Pobiera informacje z pamięci sensorycznej, z pamięci krótkotrwałej oraz z pamięci długotrwałej.\n",
|
||||
"Przekazuje informacje do pamięci krótkotrwałej i długotrwałej.\n",
|
||||
"\n",
|
||||
"#### Liczba Millera\n",
|
||||
"Jest to liczba ustalona przez George'a Millera (1920 - 2012), amerykańskiego psychologa, uważanego za twórzę psychologii poznawczej, w roku 1956 na podstawie badań psychologicznych nad zapamiętywaniem informacji. Liczba ta waha się w zależności od rodzaju informacji do zapamiętania (dźwięk, smak, obraz, liczba), ale zawsze jest to około 7 (±2).\n",
|
||||
"\n",
|
||||
"##### Wnioski w pracy zespołowej\n",
|
||||
"* Nie warto zasypywać kolegi z zespołu nadmiarem informacji zo zapamiętania (bo i tak nie zapamięta).\n",
|
||||
"* Pozycje do zapamiętania lepiej jest podzielić na kategorie, (między 5-9). \n",
|
||||
"* Można dokonać kolejnego podziału pozycji na podkategorie. Takich podziałów można dokonać wgłąb do poziomu 7 :)\n",
|
||||
"\n",
|
||||
"### Pamięć długotrwała\n",
|
||||
"* W pamięci długotrwałej tworzony jest wynik przetwarzania informacji - trwały ślad pamięciowy. \n",
|
||||
"* Pamięć długotrwała zawiera całą naszą wiedzę na temat świata, wszystkie wspomnienia i umiejętności. \n",
|
||||
"* Jest to pamięć o największej pojemności i najdłuższym czasie przechowywania informacji.\n",
|
||||
"\n",
|
||||
"#### Interakcje pamięci długotrwałej\n",
|
||||
"* Pobiera informacje z pamięci krótkotrwałej.\n",
|
||||
"* Przekazuje informacje do pamięci krótkotrwałej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Motywacja do pracy\n",
|
||||
">Motywowanie do pracy to proces świadomego i celowego oddziaływania na pracowników poprzez dostarczanie środków i możliwości spełnienia ich oczekiwań w taki sposób, aby obie strony (pracodawca i pracownik) odniosły korzyści (Encyklopedia zarządzania)\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Piramida potrzeb Maslova</h2>\n",
|
||||
" <ol>\n",
|
||||
" <li>Potrzeby fizjologiczne (najniższy rząd potrzeb) </li>\n",
|
||||
"<li>Potrzeby bezpieczeństwa</li>\n",
|
||||
"<li>Potrzeby przynależności</li>\n",
|
||||
"<li>Potrzeby uznania</li>\n",
|
||||
"<li>Potrzeby samorealizacji</li>\n",
|
||||
" </ol>\n",
|
||||
"\n",
|
||||
"<h2>Teoria Maslova</h2>\n",
|
||||
" <ul>\n",
|
||||
"<li>Motywacja to chęć zaspokojenie potrzeby najsilniej odczuwanej.</li>\n",
|
||||
"<li>Zaspokojenie potrzeby wyższego rzędu może nastąpić nie wcześniej niż po zaspokojeniu potrzeby niższego rzędu.</li>\n",
|
||||
" </ul>\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Typy pracowników\n",
|
||||
"W rzeczywistości po zaspokojeniu potrzeb najniższych kolejność potrzeb wyższego rzędu zależy od osobowości pracownika. Pracownicy różnią się bowiem w aspektach motywacji do pracy (co motywuje najbardziej) i podejścia do pracy (sposób realizacji pracy).\n",
|
||||
"\n",
|
||||
"### Typy pracowników pod względem motywacji\n",
|
||||
"A. Pracownik nastawiony na wykonanie zadania \n",
|
||||
"B. Pracownik nastawiony na siebie (własny rozwój; satysfakcję) \n",
|
||||
"C. Pracownik nastawiony na interakcję (komunikację w grupie)\n",
|
||||
"\n",
|
||||
"### Typy pracowników pod względem podejścia do pracy\n",
|
||||
"1. Posuwający pracę do przodu\n",
|
||||
"2. Wybitny technik; specjalista w dziedzinie\n",
|
||||
"3. Uznający priorytet komunikacji, współpracy między wykonawcami projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Zespół projektowy\n",
|
||||
"> Zespół projektowy to niewielka liczba ludzi posiadających komplementarne umiejętności, zaangażowanych w realizację wspólnego celu ogólnego oraz celów cząstkowych, których podejście opiera się na współodpowiedzialności” (J.Katzenach, D.Smith 2001, Siła zespołów. Wpływ pracy zespołowej na efektywność organizacji\", s. 26).\n",
|
||||
"\n",
|
||||
"Na skuteczność pracy w zespole mają wpływ 4 główne czynniki:\n",
|
||||
"* Skład zespołu\n",
|
||||
"* Spójność grupy\n",
|
||||
"* Komunikacja w zespole\n",
|
||||
"* Organizacja zespołu\n",
|
||||
"\n",
|
||||
"## Skład zespołu\n",
|
||||
"### Członkowie zespołu\n",
|
||||
"Grupa powinna zawierać uzupełniające się osobowości:\n",
|
||||
"* ludzi mających własne pomysły - wybitnych techników (B2)\n",
|
||||
"* ludzi nastawionych na komunikację z innymi (C3)\n",
|
||||
"* ludzi nastawionych na posuwanie pracy do przodu (A1) \n",
|
||||
"\n",
|
||||
"### Lider zespołu\n",
|
||||
"* Lider odgrywa najważniejszą rolę w zespole.\n",
|
||||
"* Liderzy z reguły są mianowani i odpowiadają przed menedżerem przedsięwzięcia.\n",
|
||||
"* Liderzy muszą codziennie śledzić pracę swojej grupy i blisko współpracować z menedżerami przedsięwzięcia.\n",
|
||||
"* Lider musi być akceptowany przez zespół.\n",
|
||||
"\n",
|
||||
"## Spójność grupy\n",
|
||||
"Grupa spójna (inaczej: zgrana) to grupa, w której:\n",
|
||||
"* członkowie mają wspólne cele,\n",
|
||||
"* nie występują kliki (podgrupy).\n",
|
||||
"\n",
|
||||
"### Zalety grupy spójnej\n",
|
||||
"* Można wypracować grupowy standard jakości.\n",
|
||||
"* Bliska współpraca – członkowie uczą się od siebie nawzajem.\n",
|
||||
"* Członkowie grupy znają nawzajem swoje prace. Opuszczenie grupy przez jej członka nie powoduje utracenie ciągłości pracy.\n",
|
||||
"* Programowanie jest pozbawione indywidualizmu (program uważany jest za własność grupy).\n",
|
||||
"\n",
|
||||
"### Wady grupy spójnej\n",
|
||||
"* Nieracjonalny opór przed zmianą lidera;\n",
|
||||
"* Myślenie grupowe – krytyczne umiejętności członków grupy osłabione są przez lojalność wobec grupy.\n",
|
||||
"\n",
|
||||
"## Komunikacja w zespole\n",
|
||||
"Proces skutecznej komunikacji to przekazywanie informacji w sposób powodujący realizację celów. \n",
|
||||
"Skutkiem efektywnej komunikacji jest zwiększenie motywacji do pracy oraz zmniejszenie oporu wobec zmian. \n",
|
||||
"\n",
|
||||
"### Zasady skutecznej komunikacji\n",
|
||||
"* Dostosowanie klarowności wypowiedzi do odbiorcy\n",
|
||||
"* Dostosowanie *metod komunikacji* do zespołu\n",
|
||||
"\n",
|
||||
"### Metody komunikacji\n",
|
||||
"* Pionowa lub pozioma\n",
|
||||
"* Jednostronna lub dwustronna\n",
|
||||
"* Werbalna lub pisemna\n",
|
||||
"* Formalna lub nieformalna\n",
|
||||
"\n",
|
||||
"## Organizacja zespołu\n",
|
||||
"Organizacja zespołu to hierarchia ról przypisanych członkom zespołu.\n",
|
||||
"\n",
|
||||
"### Rodzaje organizacji zespołu\n",
|
||||
"#### Organizacja formalna (hierachiczna)\n",
|
||||
"Formalna, hierarchiczna organizacja zespołu jest niezbędna w przypadku pracowników niedoświadczonych.\n",
|
||||
"\n",
|
||||
"#### Organizacja nieformalna\n",
|
||||
"Organizacja nieformalna sprawdza się, gdy większość członków to ludzie doświadczeni i kompetentni.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Lider zespołu\n",
|
||||
"Lider zespołu to w ogólności osoba zarządzająca członkami zespołu w celu realizacji celów powierzonego projektu. \n",
|
||||
"W prezentowanym NA TYM WYKŁADZIE podejściu lider to osoba zapewniająca motywację do pracy członkom zespołu.\n",
|
||||
"\n",
|
||||
"## Typy lidera (wg Daniela Goldmana)\n",
|
||||
"\n",
|
||||
"> Daniel Goleman (ur. 7 marca 1946 w Stockton) – amerykański psycholog żydowskiego pochodzenia, publicysta naukowy. Autor bestselleru Inteligencja emocjonalna (1995). (Wikipedia)\n",
|
||||
"\n",
|
||||
"### Wizjoner: \"Chodź ze mną\"\n",
|
||||
"* Pokazuje kierunek działania.\n",
|
||||
"* Motywuje do osiągania wspólnych celów.\n",
|
||||
"* Pozwala ludziom samodzielnie poszukiwać nowych rozwiązań.\n",
|
||||
"* Przyciąga ludzi do siebie, docenia i promuje rolę poszczególnych osób w zespole.\n",
|
||||
"\n",
|
||||
"### Trener: \"Rozwijaj się\"\n",
|
||||
"* Motywuje ludzi do lepszej pracy poprzez rozpoznawanie ich mocnych i słabych stron.\n",
|
||||
"* Zachęca ludzi, aby walczyli z przeciwnościami i rozwijali się.\n",
|
||||
"* Zachęca, by korzystali ze swoich mocnych, pozytywnych cech i czerpali z nich napęd do pracy.\n",
|
||||
"\n",
|
||||
"### Lider afiliacyjny: \"Porozmawiajmy\"\n",
|
||||
"* Szanuje każdą osobę pracującą w organizacji.\n",
|
||||
"* „Ludzie to nie roboty” – odczuwają radość i zmęczenie.\n",
|
||||
"* Szczerze interesuje się życiem swoich pracowników.\n",
|
||||
"* Dba o dobrą atmosferę pracy.\n",
|
||||
"* Posiada wysoką empatię, czyli umiejętność odczytywania uczuć i dostrzegania punktu widzenia innych osób.\n",
|
||||
"\n",
|
||||
"### Demokrata: \"Każdy głos jest ważny\"\n",
|
||||
"* Liczy się zdanie każdego pracownika.\n",
|
||||
"* Potrafi słuchać ludzi i wykorzystywać ich pomysły.\n",
|
||||
"* Potrafi przyjmować również krytykę.\n",
|
||||
"* Pracownicy mają poczucie, że uczestniczą w decyzjach podejmowanych w firmie, przez co bardziej angażują się w pracę.\n",
|
||||
"\n",
|
||||
"### Poganiacz: \"Zrób to natychmiast\"\n",
|
||||
"* Ustawia wysokie standardy pracy zarówno dla siebie jak i dla swoich pracowników\n",
|
||||
"* Jest bardzo mocno nastawiony na sukces, koncentruje się na nieustannym poprawianiu wyników. \n",
|
||||
"* Jego popularne powiedzenie to: „rób to, co ja – natychmiast!”.\n",
|
||||
"\n",
|
||||
"### Dyktator: \"Rób, co każę\"\n",
|
||||
"* Nazywany „zarządzaniem przez strach”.\n",
|
||||
"* Polega na ciągłym kontrolowaniu pracowników, wydawaniu im poleceń i oczekiwaniu, że zostaną one wypełnione dokładnie tak, jak wymaga tego przywódca. \n",
|
||||
"* To on podejmuje decyzje, a polecenia wydaje w sposób zdecydowany, stanowczy i nie znoszący sprzeciwu.\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.8.5"
|
||||
},
|
||||
"subtitle": "01. Praca zespołowa[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,311 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 2. <i>Projekt badawczo-rozwojowy</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"- 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",
|
||||
" - 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",
|
||||
"<img src=\"obrazy/AISearcher.png\" alt=\"Zrzut ekranu systemu AISearcher\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Poziomy gotowości technologicznej projektu B+R\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 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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Wyraz \"technologia\" pochodzi z języka greckiego:\n",
|
||||
" <ul>\n",
|
||||
" <li>techne: sztuka, umiejętność</li>\n",
|
||||
" <li>logia: nauka (czegoś)</li>\n",
|
||||
" </ul>\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.8.5"
|
||||
},
|
||||
"subtitle": "02. Projekt badawczo-rozwojowy[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,418 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 3. <i>Prezentacja koncepcji projektu B+R</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<p>DLA (określenie klienta docelowego)</p> \n",
|
||||
"<p>KTÓRY (ma potrzebę)</p>\n",
|
||||
"<p>NAZWA NASZEGO PRODUKTU (PRZEDSIĘWZIĘCIA)</p>\n",
|
||||
"<p>TO (typ produktu / przedsięwzięcia)</p> \n",
|
||||
"<p>KTÓRY (ma unikalną cechę)</p> \n",
|
||||
"<p>W PRZECIWIEŃSTWIE (nazwa znanej konkurencji)</p>\n",
|
||||
"<p>MA PRZEWAGĘ (typ przewagi)</p>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Przykład jednozdaniowego \"elevator pitch\"</h3>\n",
|
||||
" \n",
|
||||
"<p>(DLA) Dla każdej osoby biorącej leki lub suplementy,</p>\n",
|
||||
"<p>(KTÓRA) zwłaszcza dla tych którzy mają tendencje zapominać.</p> \n",
|
||||
"<p>(NAZWA PRODUKTU) Take Your Meds</p>\n",
|
||||
"<p>(TO) to aplikacja mobilna,</p>\n",
|
||||
"<p>(KTÓRA) która zapewni, że bez pomyłek weźmiemy wszystkie leki.</p>\n",
|
||||
"<p>(W PRZECIWIEŃSTWIE) w przeciwieństwie do standardowych powiadomień na telefonie i notatek na kartce,</p>\n",
|
||||
"<p>(MA PRZEWAGĘ) Take Your Meds zapewnia szczegółowe informacje i nie pozwala się pomylić.</p>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówki</h4>\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
" \n",
|
||||
"<li>Nie bądź gadatliwy!</li>\n",
|
||||
"<li>Uchwyć uwagę widza!</li>\n",
|
||||
"<li>Jeśli tutaj nie chwycisz widza za gardło, to przepadłeś.</li>\n",
|
||||
" \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówka:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
" <li> Pamiętaj: nie chodzi o Twój problem, tylko o problem potencjalnego użytkownika! </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówki:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
" <li> Bądź konkretny!</li> \n",
|
||||
" <li> Nie zalewaj! </li> \n",
|
||||
" <li> Nie czaruj!</li> \n",
|
||||
" </ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4> Wskazówki: </h4>\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Przekonaj, że Wasze rozwiązanie jest\n",
|
||||
" <ul>\n",
|
||||
"<li> użyteczne,\n",
|
||||
"<li> funkcjonalne\n",
|
||||
" </ul>\n",
|
||||
"<li> Najlepiej przedstaw działanie wizulanie - np. na schemacie, rysunku, filmie.\n",
|
||||
" </ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówki:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
"<li> Ponownie możesz przedstawić schemat... </li> \n",
|
||||
"<li> Ale uważaj, żeby nie przesadzić ze szczegółami technicznymi!</li> \n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### 6. Przedstaw konkurencję\n",
|
||||
" * Jakie produkty / firmy są Waszą konkurencją?\n",
|
||||
" * Co robią inaczej?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4> Wskazówka: </h4>\n",
|
||||
" \n",
|
||||
"Wykaż, że jesteście lepsi:\n",
|
||||
"<ul>\n",
|
||||
"<li>jakość,</li>\n",
|
||||
"<li>cena,</li>\n",
|
||||
"<li>funkcjonalność,</li>\n",
|
||||
"<li>użyteczność,</li>\n",
|
||||
"<li>elastyczność.</li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4> Wskazówki:</h4>\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
" <li>Możecie interpretować powyższe pojęcia w sposób potoczny: </li>\n",
|
||||
"<ul>\n",
|
||||
" <li>TAM - Jak duży jest cały tort?</li>\n",
|
||||
" <li>SAM - Jak duży kawałek tortu jestem w stanie uciąć dla siebie?</li>\n",
|
||||
" <li>TM - Ile jestem w stanie zjeść?</li>\n",
|
||||
"</ul>\n",
|
||||
"<li>Inwestor oczekuje, że potraficie oszacować wartość każdego zasięgu rynku na podstawie wiarygodnych źródeł.</li>\n",
|
||||
" </ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h4> Wskazówka: </h4>\n",
|
||||
"\n",
|
||||
"Wyjaśnij swój pomysł na sprzedaż, np.\n",
|
||||
"<ul>\n",
|
||||
"<li>licencje / sprzedaż jednorazowa,</li>\n",
|
||||
"<li>sprzedaż bezpośrednia / dystrybutorzy,</li>\n",
|
||||
"<li>dochody z reklam,</li>\n",
|
||||
"<li>mechanizmy przyciągnięcia klienta, np. programy lojalnościowe, grywalizacja.</li>\n",
|
||||
" </ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h4> Wskazówki: </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li>Udowodnij, że znasz realia lub...dostosuj się do oczekiwań inwestora. </li>\n",
|
||||
"<li>Kiedyś prognozę układało się na 5 lat, a dzisiaj... 5 lat to dłużej niż wieczność. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h4>Wskazówki:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
"<li> Można pokazać zdjęcia, jeśli ludzie się na to zgadzają. </li>\n",
|
||||
" <li> Jeśli w zespole jest gwiazda, pozwól jej lśnić. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "03. Prezentacja koncepcji projektu B+R[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,622 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 5. <i>Metodyki adaptacyjne w programowaniu</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Metodyki adaptacyjne w programowaniu (Agile Software Development)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"\n",
|
||||
"<b> Agile </b> (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Nic dobrego nie wynika <BR>\n",
|
||||
"Bez udziału użytkownika.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"2. Agile Development Teams Must Be Empowered."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Nie warta praca mozołu, <BR>\n",
|
||||
"Gdy władza nie w rękach zespołu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"3. Time waits for no man."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Czas płynie wartko jak rzeka, <BR>\n",
|
||||
"I na nikogo nie czeka.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"4. Agile Requirements Are Barely Sufficient."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Dosłownie w kilku dziś zdaniach <BR>\n",
|
||||
"Streścimy swe wymagania.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"5. How do you eat an elephant? One bite at a time."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Sekretów uchylam wieczko: <BR>\n",
|
||||
"Jedz słonia małą łyżeczką.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"6. Fast but not so furious."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Byli szybcy, lecz nie wściekli, <BR>\n",
|
||||
"I na czas produkt dowlekli.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"7. Done Means DONE!"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Praca była \"wykonana\", <BR>\n",
|
||||
"I działało... aż do rana.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"8. Enough is enough."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Projekt ciągle się rozrasta, <BR>\n",
|
||||
"Trzeba krzyknąć: \"Stop i Basta!\"\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"9. Agile Testing Is Not For Dummies."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Wiedz, by dobrze móc testować, <BR>\n",
|
||||
"Twa głowa ma być pomysłowa.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"10. No place for snipers."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Choć mocno znów cierpi Twe ego, <BR>\n",
|
||||
"Nie strzelaj - do siebie samego.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<b>Scrum</b> jest metodyką, w której kluczowym elementem jest <b>Sprint</b> - 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",
|
||||
"</div>\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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Rejestr Produktu (Product Backlog)</h5>\n",
|
||||
"\n",
|
||||
"<b> Rejestr Produktu </b> to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Rejestr produktu utrzymywany jest przez Właściciela Produktu.</li>\n",
|
||||
" <li> Zadania, których efekt widoczny jest dla użytkownika mają często postać <b> User Story </b>.</li>\n",
|
||||
" <li> Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu.</li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>User Story </h5>\n",
|
||||
"\n",
|
||||
"> <b> User story </b> 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 <Kto?> chcę wykonać<Co?> aby<Dlaczego?>\n",
|
||||
"\n",
|
||||
"<h6> Przykład User Story </h6>\n",
|
||||
" \n",
|
||||
"> Jako <b> klient sklepu </b> chcę <b> dodać produkt do koszyka </b> aby go później <b> kupić </b>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Rejestr Sprintu (Sprint Backlog)</h5>\n",
|
||||
"\n",
|
||||
"<b> Rejestr Sprintu </b> to lista <b>Zadań</b> do wykonania podczas Sprintu:\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> utrzymywana przez Zespół Deweloperski,</li>\n",
|
||||
" <li> tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Zadanie (Task)</h5>\n",
|
||||
"\n",
|
||||
"<b> Zadanie </b> w Rejestrze Sprintu zawiera następujące informacje:\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> opis zadania,</li>\n",
|
||||
" <li> szacowany czas wykonania zadania, </li>\n",
|
||||
" <li> członek zespołu odpowiedzialnego za wykonanie zadania, </li>\n",
|
||||
" <li> status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Role w metodyce Scrum"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Udziałowcy (stakeholders)</h5>\n",
|
||||
"Udziałowcy to ludzie, którzy finansują projekt:\n",
|
||||
"<ol>\n",
|
||||
" <li> właściciele firmy realizującej projekt,</li>\n",
|
||||
" <li> klienci, </li>\n",
|
||||
" <li> przyszli użytkownicy.</li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Właściciel Produktu (Product Owner)</h5>\n",
|
||||
"\n",
|
||||
"<b> Właściciel Produktu </b> to rola, która reprezentuje interesy biznesu.\n",
|
||||
"\n",
|
||||
"<h6> Zadania Właściciela Produktu: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> nadzoruje pisanie <b> User Stories</b>,</li>\n",
|
||||
" <li> analizuje na bieżąco potrzeby biznesu i na tej podstawie...</li>\n",
|
||||
" <li> ustala priorytet User Stories w <b>Rejestrze Produktu</b>,</li>\n",
|
||||
" <li> decyduje, co jest WYKONANE. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h5>Zespół Deweloperski (Development Team)</h5>\n",
|
||||
" \n",
|
||||
"<b>Zespół Deweloperski </b> to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.\n",
|
||||
" \n",
|
||||
"<h6> Zadania Zespołu Deweloperskiego: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> jest odpowiedzialny za implementację, </li>\n",
|
||||
" <li> na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint, </li>\n",
|
||||
" <li> wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu),</li>\n",
|
||||
" <li> sam decyduje o sposobie realizacji zadań. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h5> Scrum Master </h5>\n",
|
||||
"\n",
|
||||
"Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.\n",
|
||||
"\n",
|
||||
"<h6> Zadania Scrum Mastera: </h6>\n",
|
||||
"<ol>\n",
|
||||
" <li> prowadzi <b>Daily </b> (spotkanie zespołu), </li>\n",
|
||||
" <li> prowadzi <b> Retrospektywę</b>, </li>\n",
|
||||
" <li> buduje relacje w zespole, </li>\n",
|
||||
" <li> pomaga rozwiązywać konflikty, </li>\n",
|
||||
" <li> pośredniczy w rozmowach z Właścicielem produktu. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cykl pracy w metodyce Scrum"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Sprint </h5> \n",
|
||||
"\n",
|
||||
"<b> Sprint </b> 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",
|
||||
"<ol>\n",
|
||||
" <li> Planowanie Sprintu, </li>\n",
|
||||
" <li> Implementacja, </li>\n",
|
||||
" <li> Codzienne spotkania, </li>\n",
|
||||
" <li> Przegląd Sprintu, </li>\n",
|
||||
" <li> Retrospektywa. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Planowanie Sprintu (Sprint Planning) </h5> \n",
|
||||
"\n",
|
||||
"<b> Planowanie sprintu </b> jest pierwszym spotkaniem podczas każdego sprintu. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu. </li> \n",
|
||||
"<li> Planowanie Sprintu prowadzone jest przez Scrum Mastera. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h6> Standardowy przebieg Planowania Sprintu: </h6> \n",
|
||||
"<ol>\n",
|
||||
" <li> Analizy Rejestru Produktu - wybór wymagań do realizacji, </li>\n",
|
||||
" <li> Określenie celu sprintu - na podstawie wybranych wymagań, </li>\n",
|
||||
" <li> Określenie pełnego zakresu prac: jak będzie działał system po Sprincie, </li>\n",
|
||||
" <li> Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań, </li>\n",
|
||||
" <li> Estymacja pracochłonności zadań. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Codzienne Spotkania (Daily Scrum) </h5> \n",
|
||||
"\n",
|
||||
"<b> Codzienne Spotkanie </b> (stosowana nazwa w j. polskim - <b> Daily </b>) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Daily bierze udział Zespół Deweloperski. </li> \n",
|
||||
"<li> Daily prowadzone jest przez Scrum Mastera. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Daily: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Przegląd prac w ciągu ostatniego dnia, </li>\n",
|
||||
" <li> Omówienie pojawiających się problemów, </li>\n",
|
||||
" <li> Omówienie planu na kolejny dzień. </li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Przegląd Sprintu </h5> \n",
|
||||
"\n",
|
||||
"<b> Przegląd Sprintu </b> jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu. </li> \n",
|
||||
"<li> Przegląd Sprintu prowadzony jest przez Właściciela Produktu. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Przeglądu Sprintu: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały \"Wykonane”, a które nie. </li>\n",
|
||||
" <li> Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano. </li>\n",
|
||||
" <li> Zespół Deweloperski prezentuje \"Wykonaną” pracę; dyskusja. </li>\n",
|
||||
" <li> Właściciel Produktu omawia obecny Rejestr Produktu. </li>\n",
|
||||
" <li> Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.\n",
|
||||
" <li> Właściciel produktu aktualizuje Rejestr Produktu.\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Retrospektywa Sprintu</h5> \n",
|
||||
"\n",
|
||||
"<b> Retrospektywa Sprintu </b> to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Retrospektywie udział bierze Zespół Deweloperski. </li> \n",
|
||||
"<li> Retrospektywę prowadzi Scrum Master. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Retrospektywy: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Sprawdzenie, co działo się w ostatnim Sprincie, </li>\n",
|
||||
" <li> Zidentyfikowanie elementów, które sprawdziły się w działaniu, </li>\n",
|
||||
" <li> Zidentyfikowanie elementów, które kwalifikują się do usprawnienia,</li>\n",
|
||||
" <li> Stworzenie planu wprowadzania w życie usprawnień. </li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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.8.5"
|
||||
},
|
||||
"subtitle": "05. Metodologia Prince2Agile[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,622 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 5. <i>Metodyki adaptacyjne w programowaniu</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Metodyki adaptacyjne w programowaniu (Agile Software Development)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"\n",
|
||||
"<b> Agile </b> (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Nic dobrego nie wynika <BR>\n",
|
||||
"Bez udziału użytkownika.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"2. Agile Development Teams Must Be Empowered."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Nie warta praca mozołu, <BR>\n",
|
||||
"Gdy władza nie w rękach zespołu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"3. Time waits for no man."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Czas płynie wartko jak rzeka, <BR>\n",
|
||||
"I na nikogo nie czeka.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"4. Agile Requirements Are Barely Sufficient."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Dosłownie w kilku dziś zdaniach <BR>\n",
|
||||
"Streścimy swe wymagania.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"5. How do you eat an elephant? One bite at a time."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Sekretów uchylam wieczko: <BR>\n",
|
||||
"Jedz słonia małą łyżeczką.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"6. Fast but not so furious."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Byli szybcy, lecz nie wściekli, <BR>\n",
|
||||
"I na czas produkt dowlekli.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"7. Done Means DONE!"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Praca była \"wykonana\", <BR>\n",
|
||||
"I działało... aż do rana.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"8. Enough is enough."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Projekt ciągle się rozrasta, <BR>\n",
|
||||
"Trzeba krzyknąć: \"Stop i Basta!\"\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"9. Agile Testing Is Not For Dummies."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Wiedz, by dobrze móc testować, <BR>\n",
|
||||
"Twa głowa ma być pomysłowa.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"10. No place for snipers."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Choć mocno znów cierpi Twe ego, <BR>\n",
|
||||
"Nie strzelaj - do siebie samego.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<b>Scrum</b> jest metodyką, w której kluczowym elementem jest <b>Sprint</b> - 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",
|
||||
"</div>\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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Rejestr Produktu (Product Backlog)</h5>\n",
|
||||
"\n",
|
||||
"<b> Rejestr Produktu </b> to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Rejestr produktu utrzymywany jest przez Właściciela Produktu.</li>\n",
|
||||
" <li> Zadania, których efekt widoczny jest dla użytkownika mają często postać <b> User Story </b>.</li>\n",
|
||||
" <li> Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu.</li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>User Story </h5>\n",
|
||||
"\n",
|
||||
"> <b> User story </b> 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 <Kto?> chcę wykonać<Co?> aby<Dlaczego?>\n",
|
||||
"\n",
|
||||
"<h6> Przykład User Story </h6>\n",
|
||||
" \n",
|
||||
"> Jako <b> klient sklepu </b> chcę <b> dodać produkt do koszyka </b> aby go później <b> kupić </b>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Rejestr Sprintu (Sprint Backlog)</h5>\n",
|
||||
"\n",
|
||||
"<b> Rejestr Sprintu </b> to lista <b>Zadań</b> do wykonania podczas Sprintu:\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> utrzymywana przez Zespół Deweloperski,</li>\n",
|
||||
" <li> tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Zadanie (Task)</h5>\n",
|
||||
"\n",
|
||||
"<b> Zadanie </b> w Rejestrze Sprintu zawiera następujące informacje:\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> opis zadania,</li>\n",
|
||||
" <li> szacowany czas wykonania zadania, </li>\n",
|
||||
" <li> członek zespołu odpowiedzialnego za wykonanie zadania, </li>\n",
|
||||
" <li> status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Role w metodyce Scrum"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Udziałowcy (stakeholders)</h5>\n",
|
||||
"Udziałowcy to ludzie, którzy finansują projekt:\n",
|
||||
"<ol>\n",
|
||||
" <li> właściciele firmy realizującej projekt,</li>\n",
|
||||
" <li> klienci, </li>\n",
|
||||
" <li> przyszli użytkownicy.</li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Właściciel Produktu (Product Owner)</h5>\n",
|
||||
"\n",
|
||||
"<b> Właściciel Produktu </b> to rola, która reprezentuje interesy biznesu.\n",
|
||||
"\n",
|
||||
"<h6> Zadania Właściciela Produktu: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> nadzoruje pisanie <b> User Stories</b>,</li>\n",
|
||||
" <li> analizuje na bieżąco potrzeby biznesu i na tej podstawie...</li>\n",
|
||||
" <li> ustala priorytet User Stories w <b>Rejestrze Produktu</b>,</li>\n",
|
||||
" <li> decyduje, co jest WYKONANE. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h5>Zespół Deweloperski (Development Team)</h5>\n",
|
||||
" \n",
|
||||
"<b>Zespół Deweloperski </b> to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.\n",
|
||||
" \n",
|
||||
"<h6> Zadania Zespołu Deweloperskiego: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> jest odpowiedzialny za implementację, </li>\n",
|
||||
" <li> na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint, </li>\n",
|
||||
" <li> wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu),</li>\n",
|
||||
" <li> sam decyduje o sposobie realizacji zadań. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h5> Scrum Master </h5>\n",
|
||||
"\n",
|
||||
"Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.\n",
|
||||
"\n",
|
||||
"<h6> Zadania Scrum Mastera: </h6>\n",
|
||||
"<ol>\n",
|
||||
" <li> prowadzi <b>Daily </b> (spotkanie zespołu), </li>\n",
|
||||
" <li> prowadzi <b> Retrospektywę</b>, </li>\n",
|
||||
" <li> buduje relacje w zespole, </li>\n",
|
||||
" <li> pomaga rozwiązywać konflikty, </li>\n",
|
||||
" <li> pośredniczy w rozmowach z Właścicielem produktu. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cykl pracy w metodyce Scrum"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Sprint </h5> \n",
|
||||
"\n",
|
||||
"<b> Sprint </b> 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",
|
||||
"<ol>\n",
|
||||
" <li> Planowanie Sprintu, </li>\n",
|
||||
" <li> Implementacja, </li>\n",
|
||||
" <li> Codzienne spotkania, </li>\n",
|
||||
" <li> Przegląd Sprintu, </li>\n",
|
||||
" <li> Retrospektywa. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Planowanie Sprintu (Sprint Planning) </h5> \n",
|
||||
"\n",
|
||||
"<b> Planowanie sprintu </b> jest pierwszym spotkaniem podczas każdego sprintu. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu. </li> \n",
|
||||
"<li> Planowanie Sprintu prowadzone jest przez Scrum Mastera. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h6> Standardowy przebieg Planowania Sprintu: </h6> \n",
|
||||
"<ol>\n",
|
||||
" <li> Analizy Rejestru Produktu - wybór wymagań do realizacji, </li>\n",
|
||||
" <li> Określenie celu sprintu - na podstawie wybranych wymagań, </li>\n",
|
||||
" <li> Określenie pełnego zakresu prac: jak będzie działał system po Sprincie, </li>\n",
|
||||
" <li> Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań, </li>\n",
|
||||
" <li> Estymacja pracochłonności zadań. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Codzienne Spotkania (Daily Scrum) </h5> \n",
|
||||
"\n",
|
||||
"<b> Codzienne Spotkanie </b> (stosowana nazwa w j. polskim - <b> Daily </b>) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Daily bierze udział Zespół Deweloperski. </li> \n",
|
||||
"<li> Daily prowadzone jest przez Scrum Mastera. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Daily: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Przegląd prac w ciągu ostatniego dnia, </li>\n",
|
||||
" <li> Omówienie pojawiających się problemów, </li>\n",
|
||||
" <li> Omówienie planu na kolejny dzień. </li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Przegląd Sprintu </h5> \n",
|
||||
"\n",
|
||||
"<b> Przegląd Sprintu </b> jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu. </li> \n",
|
||||
"<li> Przegląd Sprintu prowadzony jest przez Właściciela Produktu. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Przeglądu Sprintu: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały \"Wykonane”, a które nie. </li>\n",
|
||||
" <li> Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano. </li>\n",
|
||||
" <li> Zespół Deweloperski prezentuje \"Wykonaną” pracę; dyskusja. </li>\n",
|
||||
" <li> Właściciel Produktu omawia obecny Rejestr Produktu. </li>\n",
|
||||
" <li> Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.\n",
|
||||
" <li> Właściciel produktu aktualizuje Rejestr Produktu.\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Retrospektywa Sprintu</h5> \n",
|
||||
"\n",
|
||||
"<b> Retrospektywa Sprintu </b> to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Retrospektywie udział bierze Zespół Deweloperski. </li> \n",
|
||||
"<li> Retrospektywę prowadzi Scrum Master. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Retrospektywy: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Sprawdzenie, co działo się w ostatnim Sprincie, </li>\n",
|
||||
" <li> Zidentyfikowanie elementów, które sprawdziły się w działaniu, </li>\n",
|
||||
" <li> Zidentyfikowanie elementów, które kwalifikują się do usprawnienia,</li>\n",
|
||||
" <li> Stworzenie planu wprowadzania w życie usprawnień. </li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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.8.5"
|
||||
},
|
||||
"subtitle": "05. Metodologia Prince2Agile[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,462 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 6. <i>Prototypowanie i ciągła integracja</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Prototyp </h2> \n",
|
||||
"Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Prototyp papierowy </h2> \n",
|
||||
" \n",
|
||||
"<b>Prototyp papierowy</b> 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",
|
||||
"<b>Prototypowanie papierowe - etapy </b>:\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności. </li>\n",
|
||||
"<li> Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Makieta statyczna </h2> \n",
|
||||
" \n",
|
||||
" \n",
|
||||
"<b>Makieta statyczna</b> to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
" <li> Obrazuje wybrane widoki bez połączeń między nimi. </li>\n",
|
||||
"</ul> \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Makieta dynamiczna </h2> \n",
|
||||
" \n",
|
||||
" \n",
|
||||
"<b>Makieta dynamiczna</b> to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku. </li>\n",
|
||||
"</ul> \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Graficzny interfejs użytkownika (GUI) </h2> \n",
|
||||
"\n",
|
||||
"<b> Graficzny interfejs użytkownika </b> to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n",
|
||||
" \n",
|
||||
"Prototypem poziomym nazwiemy GUI, który: \n",
|
||||
"<ul>\n",
|
||||
"<li> Pokazuje menu. </li>\n",
|
||||
"<li> Pozwala na nawigację. </li>\n",
|
||||
"<li> Akceptuje input. </li>\n",
|
||||
"<li> Wyświetla losowy output. </li>\n",
|
||||
"<li> NIE wspiera logiki aplikacji. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Ciągła integracja </h2> \n",
|
||||
" \n",
|
||||
"Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
|
||||
"<ul>\n",
|
||||
" <li> zmiany w kodzie są regularnie przesyłane do centralnego repozytorium, </li>\n",
|
||||
" <li> po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Główne przesłanki CI </h2> \n",
|
||||
" \n",
|
||||
"Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
|
||||
"<ul>\n",
|
||||
" <li> szybsze lokalizowanie błędów w kodzie, </li>\n",
|
||||
" <li> ciągły wzrost jakości oporgramowania, </li>\n",
|
||||
" <li> szybkie wydawanie nowych wersji. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "06. Prototypowanie i ciągła integracja[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,478 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 7. <i>Specyfikacja projektu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Zakres systemu informatycznego</h3>\n",
|
||||
" \n",
|
||||
"Zakres systemu to obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co leży poza projektem (np. jest zadaniem projektowym kogoś innego).\n",
|
||||
"\n",
|
||||
"Zakres <b> funkcjonalny </b>– zestaw usług oferowanych przez system.\n",
|
||||
"\n",
|
||||
"Zakres <b> projektowy </b>– zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Jak zdefiniować zakres projektu?\n",
|
||||
"\n",
|
||||
"Zakres projektu jest stopniowo uściślany za pomocą następującyh działań:\n",
|
||||
"\n",
|
||||
"1. Określenie ogólnego zakresu projektu, a w nim:\n",
|
||||
"\n",
|
||||
" * Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu\n",
|
||||
" * Charakterystyka wykonawców\n",
|
||||
" * Lista „wykonawca-cel”\n",
|
||||
" * Lista „in-out”\n",
|
||||
"\n",
|
||||
"2. Specyfikacja wymagań\n",
|
||||
" * Wymagania funkcjonalne\n",
|
||||
" * Wymaganie niefunkcjonalne\n",
|
||||
" \n",
|
||||
"3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Określenie ogólnego zakresu projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Uczestnicy i wykonawcy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Uczestnik</h3>\n",
|
||||
" \n",
|
||||
"Uczestnik – ktoś lub coś, mający interes związany z zachowaniem systemu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"Uczestnik może być osobą, firmą lub przedsiębiorstwem, programem komputerowym lub systemem komputerowym.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Wykonawca</h3>\n",
|
||||
" \n",
|
||||
"<b> Wykonawca </b> to Uczestnik, który kontaktuje się z systemem.\n",
|
||||
"\n",
|
||||
"<b> Wykonawca główny </b> to Wykonawca, który kontaktuje się z systemem w celu uzyskania jednej z jego usług. Wykonawca główny najczęściej rozpoczyna przypadek użycia. \n",
|
||||
"\n",
|
||||
"<b> Wykonawca pomocniczy </b> to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Uczestnik ma interesy. \n",
|
||||
"Wykonawca ma zachowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Charakterystyka wykonawców\n",
|
||||
"Charakterystykę wykonawców można opisać za pomocą tabeli. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawcy.png\" alt=\"Lista Wykonawców\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista Wykonawca-Cel\n",
|
||||
"Na podstawie charakterystyki wykonawców oraz zakresu systemu tworzy się listę **Wykonawca - Cel**, w której dla każdego typu wykonawców określa się cele, jakie wykonawca stawia przed systemem. \n",
|
||||
"\n",
|
||||
"Jeśli projektowany system dotyczy interesów uczestników niebędących wykonawcami, pożądane może być sporządzenie szerszej listy: **Uczestnik – Cel**. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawca-cel.png\" alt=\"Lista wykonawca-cel\" width=600px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista In-Out\n",
|
||||
"Na podstawie listy Wykonawca-Cel, biorąc pod uwagę priorytety celów, tworzy się listę In-Out, która precyzyjnie określa zakres systemu. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"<img src=\"obrazy/in-out.png\" alt=\"Lista In-Out\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Specyfikacja wymagań"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Specyfikacja wymagań</h3>\n",
|
||||
" \n",
|
||||
"Specyfikacja wymagań to dokument, w którym zebrano wszystkie oczekiwania stawiane przyszłemu systemowi (np. wymagania funkcjonalne i niefunkcjonalne aplikacji).\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymagania użytkownika\n",
|
||||
"**Wymagania użytkownika** to ogólny opis oczekiwań względem systemu w języku naturalnym, będacy rezultatem wstępnych rozmów wykonawcy z zamawiającym lub użytkownikiem.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * menedżerów zamwiającego.\n",
|
||||
" * menedżerów wykonawcy,\n",
|
||||
" * potencjalnych użytkowników systemu.\n",
|
||||
" \n",
|
||||
"Przykład wymagań użytkownika (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymagania użytkownika.png\" alt=\"Przykład wymagań użytkownika\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymaganie systemowe\n",
|
||||
"**Wymagania systemowe** to sformalizowany opis oczekiwań względem systemu.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * inżynierów zamwiającego,\n",
|
||||
" * twórców oprogramowania, \n",
|
||||
" * architektów systemu. \n",
|
||||
" \n",
|
||||
"Wymagania systemowe dzielą się na:\n",
|
||||
" * funkcjonalne,\n",
|
||||
" * niefunkcjonalne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania funkcjonalne\n",
|
||||
" * Opisują funkcje (czynności, operacje) wykonywane przez system.\n",
|
||||
" * Dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem.\n",
|
||||
" \n",
|
||||
"Przykłady wymagań funkcjonalnych (system do prowadzenia testów na wykładzie):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne1.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne2.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania niefunkcjonalne\n",
|
||||
" * Opisują warunki, przy których system musi realizować swoje funkcje:\n",
|
||||
" * Wymagania dotyczące produktu\n",
|
||||
" * Wymagania dotyczące procesu\n",
|
||||
" * Wymagania zewnętrzne\n",
|
||||
" * Wymagania niefunkcjonalne powinny być weryfikowalne. Realizowane jest to przy pomocy systemu miar opisujących wymagane cechy systemu.\n",
|
||||
"\n",
|
||||
"Przykłady miar wymagań niefunkcjonalnych:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/miary.png\" alt=\"Przykłady miar wymagań niefunkcjonalnych\" width=600px>\n",
|
||||
"\n",
|
||||
"Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymagania niefunkcjonalne.png\" alt=\"Przykład wymagań niefunkcjonalnych\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Przypadek użycia (PU) </h3>\n",
|
||||
" \n",
|
||||
"Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li>Przypadek użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie wykonawcy głównego.\n",
|
||||
" <li>Przypadek użycia reprezentowany jest przez sekwencję <b> akcji </b> realizowanych przez system, które dają zauważalny efekt; Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 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",
|
||||
"4. Wyzwalacz\n",
|
||||
"5. Gwarancje minimalne\n",
|
||||
"6. Gwarancja powodzenia\n",
|
||||
"7. Scenariusz powodzenia\n",
|
||||
"8. Rozszerzenia scenariusza"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1. Przypadek użycia. Poziom celu\n",
|
||||
"Poziom celu określa stopień ogólności przypadku użycia:\n",
|
||||
" * Poziom streszczenia – najbardziej ogólny,\n",
|
||||
" * Poziom użytkownika – pośredni,\n",
|
||||
" * Poziom podfunkcji – najbardziej szczegółowy.\n",
|
||||
" \n",
|
||||
"#### Poziom streszczenia\n",
|
||||
"Przypadki użycia o poziomie streszczenia pokazują kontekst, w którym występują przypadki użycia niższego poziomu:\n",
|
||||
" * Pokazują kolejność działania przypadków użycia niższego poziomu,\n",
|
||||
" * Stanowią spis treści przypadków użycia niższego poziomu (użytkownika).\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie streszczenia (podkreśleniem oznaczone są przypadki niższego poziomu):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom streszczenia.png\" alt=\"Przykład przypadku użycia o poziomie streszczenia\" width=400px>\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",
|
||||
" * Najczęściej spełniają warunek: „jedna osoba i jedno krótkie posiedzenie”.\n",
|
||||
" * Przypadki te są najbardziej warte opisania w specyfikacji.\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie użytkownika:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom użytkownika.png\" alt=\"Przykład przypadku użycia o poziomie użytkownika\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom podfunkcji\n",
|
||||
"Przypadki użycia o poziomie podfunkcji opisują podcele, które są potrzebne do osiągnięcia celów użytkownika.\n",
|
||||
" * Uwzględniane są w opisie przypadków tylko w sytuacjach absolutnie niezbędnych („nie musisz – nie pisz”).\n",
|
||||
" * Trzy przykłady przypadków użycia o poziomie podfunkcji:\n",
|
||||
" > Wybierz odpowiedź na pytanie testowe. \n",
|
||||
" > Przejdź do następnego pytania. \n",
|
||||
" > Zaloguj się w systemie. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Przypadek użycia. Warunki początkowe\n",
|
||||
"**Warumek początkowy** to proste stwierdzenie o stanie świata w chwili otwarcia przypadku użycia. \n",
|
||||
" * Warunek początkowy może być wyrażony za pomocą przypadków użycia, które musiały zajść przed otwarciem opisywanego przypadku. \n",
|
||||
" * Warunek początkowy określa, co musi być zapewnione przed zezwoleniem na przypadek użycia. \n",
|
||||
" \n",
|
||||
" Przykład warunku początkowego (system do testów):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/warunek początkowy.png\" alt=\"Przykład warunku początkowego\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Przypadek użycia. Wyzwalacz\n",
|
||||
"**Wyzwalacz** to zdarzenie, które automatycznie powoduje rozpoczęcie przypadku użycia.\n",
|
||||
"\n",
|
||||
" Przykłady wyzwalaczy (system do testów):\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/wyzwalacze.png\" alt=\"Przykłady wyzwalaczy\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
" * 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",
|
||||
" <img src=\"obrazy/gwarancje minimalne.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Przypadek użycia. Gwarancja powodzenia\n",
|
||||
"**Gwarancja powodzenia** ustala, jakie interesy uczestników są zaspokojone po udanym zakończeniu przypadku użycia (scenariusz powodzenia).\n",
|
||||
" * Zapisywana jest w postaci prostych stwierdzeń, opisujących świat po udanym zakończeniu przypadku użycia.\n",
|
||||
" * Często ma postać rozszerzenia minimalnych gwarancji.\n",
|
||||
" \n",
|
||||
"Przykłady gwarancji powodzenia:\n",
|
||||
"\n",
|
||||
" <img src=\"obrazy/gwarancja powodzenia.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"\n",
|
||||
"##### 1. Używaj prostych składni zdań\n",
|
||||
"<img src=\"obrazy/prosta składnia.png\" alt=\"Przykład prostej składni\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 2. Jasno i jednoznacznie wskaż podmiot czynności\n",
|
||||
"<img src=\"obrazy/podmiot.png\" alt=\"Przykład podmiotu czynności\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 3. Pisz \"z lotu ptaka\"\n",
|
||||
"<img src=\"obrazy/lot ptaka.png\" alt=\"Przykład z lotu ptaka\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 4. Przesuwaj proces wyraźnie do przodu\n",
|
||||
"<img src=\"obrazy/proces.png\" alt=\"Przykład przesuwania procesu\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n",
|
||||
"<img src=\"obrazy/że.png\" alt=\"Przykład stwierdzania że\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n",
|
||||
"<img src=\"obrazy/odwołania.png\" alt=\"Przykłady odwołania\" width=300px>\n",
|
||||
"\n",
|
||||
"##### 7. Stosuj iteracje, jeśli jest taka potrzeba\n",
|
||||
"<img src=\"obrazy/iteracje.png\" alt=\"Przykłady iteracji\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Przypadek użycia. Rozszerzenia scenariusza\n",
|
||||
"**Rozszerzenie scenariusza** to niestandardowe zachowanie systemu, które\n",
|
||||
" * zaczyna się w konkretnym kroku w scenariuszu powodzenia,\n",
|
||||
" * gdy zdarzają się niestandardowe sytuacje – zwane **warunkami rozszerzenia scenariusza**.\n",
|
||||
" \n",
|
||||
"#### Warunki rozszerzenia scenariusza\n",
|
||||
"**Warunki rozszerzenie scenariusza** to sytuacje, w których system zachowuje się inaczej, niż to przewidziano w scenariuszu powodzenia.\n",
|
||||
"* Warunki rozszerzenia sformułowane są z punktu widzenia systemu (co system może wykryć, a nie - co się stało).\n",
|
||||
"<img src=\"obrazy/warunki rozszerzenia.png\" alt=\"Przykłady warunku rozszerzenia\" width=300px>\n",
|
||||
"\n",
|
||||
"##### Jak znajdować potencjalne rozszerzenia scenariusza?\n",
|
||||
" * Przemyśl alternatywne ścieżki scenariusza, np.\n",
|
||||
" * Wykonawca głóny postępuje niepoprawnie\n",
|
||||
" * Brak działania wykonawcy głównego\n",
|
||||
" * Wykonawca pomocniczy reaguje z opóźnieniem\n",
|
||||
" * Przeanalizuj wszystkie wystąpienia wyrażeń typu „System stwierdza, że...”\n",
|
||||
" * Przeanalizuj sytuacje awaryjne\n",
|
||||
" * Awarie wewnętrzne projektowanego systemu, które należy wykryć i obsłużyć\n",
|
||||
" * Awarie wewnętrzne systemu, które wystarczy wykryć"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
" 5. Wymagania funkcjonalne \n",
|
||||
" 6. Wymaganie niefunkcjonalne \n",
|
||||
" 7. Opis przypadków użycia "
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "07. Specyfikacja projektu informatycznego[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,476 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 8. <i>Testowanie w programowaniu zwinnym</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. Przykłady katastrof spowodowanych złym testowaniem"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Start sondy kosmicznej Mariner-1 (1962) </h3>\n",
|
||||
"<a href=\"https://plwiki.pl/Leksykon/Mariner_1\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Start sondy kosmicznej Mariner-1 (1962) </h3>\n",
|
||||
"<a href=\"https://plwiki.pl/Leksykon/Mariner_1\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Maszyna do radioterapii Therac-25 (1985-1987) </h3>\n",
|
||||
"<a href=\"https://ucgosu.pl/2018/09/therac-25-czyli-blad-w-sofcie-medycznym-powodujacy-smierc-pacjentow/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Zestrzelenie Airbusa 290 (1988) </h3>\n",
|
||||
"<a href=\"https://www.msn.com/pl-pl/wiadomosci/historia/jak-w-1988-roku-zestrzelono-ira%C5%84ski-samolot-pasa%C5%BCerski/ar-BBYPtLv?li=BBr5MK7\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Awaria sieci AT T (1990) </h3>\n",
|
||||
"<a href=\"https://www.computerworld.pl/news/Najgorsze-skutki-bledow-programistow,369992.html\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Błąd systemu obrony przeciwrakietowej Patriot (1992) </h3>\n",
|
||||
"<a href=\"https://www.konflikty.pl/technika-wojskowa/na-ladzie/patriot-dhahran-co-sie-stalo/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Awaria rakiety Ariane-5 (1996) </h3>\n",
|
||||
"<a href=\"https://ucgosu.pl/2018/09/ariane-5-int-overflow-ktory-wysadzil-w-powietrze-rakiete/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Błąd konwersji w sondzie Mars Climate Orbiter (1999) </h3>\n",
|
||||
"<a href=\"https://ichi.pro/pl/blad-konwersji-wynoszacy-328-milionow-dolarow-271395322355666\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Awaria systemu PEKA (2014) </h3>\n",
|
||||
"<a href=\"https://www.fakt.pl/wydarzenia/polska/poznan/awaria-systemu-peka-w-poznaniu-awaria-kart-peka/9d1pbb1\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Podstawowe pojęcia testowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Błąd (error)</h3>\n",
|
||||
" \n",
|
||||
"<b>Błąd</b> to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Defekt (fault)</h3>\n",
|
||||
" \n",
|
||||
"<b>Defekt</b> to niedoskonałość w kodzie programu. \n",
|
||||
"\n",
|
||||
"<i>Błąd</i> ujawniony w czasie testów świadczy o <i>defekcie</i> w testowanym kodzie.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie</h3>\n",
|
||||
" \n",
|
||||
"<b>Testowanie </b> to proces, który ma na celu <b><i>wykazanie</i></b> istnienia defektów w kodzie programu poprzez wywołanie błędów w działaniu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Usuwanie defektów</h3>\n",
|
||||
" \n",
|
||||
"<b>Usuwanie defektów </b> to proces lokalizacji i poprawiania defektów.\n",
|
||||
"\n",
|
||||
"Procesy testowania i usuwania defektów często przeplatają się w pętlach iteracyjnych:\n",
|
||||
"<ol>\n",
|
||||
"<li>Wywołaj błąd (testowanie)</li>\n",
|
||||
"<li>Zlokalizuj defekt (usuwanie defektów)</li>\n",
|
||||
"<li>Zaprojektuj naprawę defektu (usuwanie defektów)</li>\n",
|
||||
"<li>Napraw defekt (usuwanie defektów)</li>\n",
|
||||
"<li>Wróć do 1.</li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testy bialej skrzynki</h3>\n",
|
||||
" \n",
|
||||
"<b>Testy białej skrzynki</b> zakładają wgląd w wewnętrzną strukturę (kod) programu – na tej podstawie tworzone są przypadki testowe.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testy czarnej skrzynki</h3>\n",
|
||||
" \n",
|
||||
"W <b> testach czarnej skrzynki</b> program traktowany jest jak czarna skrzynka, której zawartość pozostaje nieznana; \n",
|
||||
"<ul>\n",
|
||||
"<li>Przypadki testowe tworzone są bez znajomości kodu.\n",
|
||||
"<li>Celem testowania jest wykrycie sytuacji, w których dane wejściowe przekształcane są na wyniki niezgodnie z oczekiwaniami.\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h3>Zasady testowania</h3>\n",
|
||||
" \n",
|
||||
"<ol>\n",
|
||||
"<li> Programiści nie testują swoich programów (poza tworzeniem testów jednostkowych).\n",
|
||||
"<li> Firma nie testuje swoich produktów (a dokładniej: niezbędne jest testowanie zewnętrzne)\n",
|
||||
"<li> Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych.\n",
|
||||
"<li> Testowanie jest czynnością kreatywną.\n",
|
||||
"</ol>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3. Przypadki testowe"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Przypadek testowy</h3>\n",
|
||||
" \n",
|
||||
"<b>Przypadek testowy</b> to eksperyment przeprowadzany w testowaniu, który można opisać w kategoriach:\n",
|
||||
"<ul>\n",
|
||||
"<li> wartości wprowadzanych danych, \n",
|
||||
"<li> akcji wykonywanej przez użytkownika\n",
|
||||
"<li> oczekiwanych wyników. \n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"Przypadki testowe służą do <b>ograniczenia</b> przestrzeni sytuacji, które należy sprawdzić, aby wywołać błąd programu. \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Jak tworzyć przypadki testowe?\n",
|
||||
"\n",
|
||||
" * Analiza klas równoważności:\n",
|
||||
" * Klasa równoważności – wszystkie możliwe wartości danych wejściowych przetwarzanych w ten sam sposób. \n",
|
||||
" * Jeden przypadek testowy reprezentuje jedną klasę równoważności. \n",
|
||||
"\n",
|
||||
"**Przykład**: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić klas równoważności?\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/klasy równoważności.png\" alt=\"Klasy równoważności przypadków testowych\" width=400px>\n",
|
||||
"\n",
|
||||
" * Analiza wartości brzegowych\n",
|
||||
" * Metoda zakłada, że błędy mogą być spowodowane nieprzewidzianym zachowaniem programu w okolicach wartości brzegowych.\n",
|
||||
" * Jeden przypadek testowy odpowiada jednej wartości brzegowej.\n",
|
||||
"\n",
|
||||
"**Przykład**: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić przypadków testowych metodą analizy wartości brzegowych? \n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wartości brzegowe.png\" alt=\"Analiza wartości brzegowych\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Jak opisywać przypadki testowe?\n",
|
||||
"\n",
|
||||
" * W metodzie białej skrzynki – za pomocą testów jednostkowych, stosując metodę analizy wartości brzegowych lub klas równoważności\n",
|
||||
" * W metodzie czarnej skrzynki – w postaci:\n",
|
||||
" * Prostej instrukcji do testera\n",
|
||||
" * Scenariusza przypadku testowego\n",
|
||||
" \n",
|
||||
"**Przykład opisu przypadków testowych logowania do systemu:**\n",
|
||||
"<img src=\"obrazy/przypadki testowe.png\" alt=\"Opis przypadków testowych\" width=900px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4. Poziomy testowania\n",
|
||||
"\n",
|
||||
"* Znalezienie defektu jest tym trudniejsze, im dłuższa droga dzieli miejsce defektu od miejsca ujawnienia błędu.\n",
|
||||
"\n",
|
||||
"* Każdemu etapowi wytwarzania oprogramowania odpowiada określony poziom testowania.\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziomy testowania.gif\" alt=\"Poziomy testowania\" width=600px>\n",
|
||||
"(źródło: https://edux.pjwstk.edu.pl/mat/200/lec/wyklady/11_3.html)\n",
|
||||
"\n",
|
||||
"* Zarządzanie poziomami testowania ma na celu skrócenie drogi od spowodowania defektu do wykrycia błędu.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Poziomy testowania w Scrumie\n",
|
||||
"\n",
|
||||
"* W programowaniu tradycyjnym testowanie odbywa się sekwencyjnie.\n",
|
||||
"\n",
|
||||
"* W Scrumie testowanie na wszystkich poziomach odbywa się równolegle (codziennie lub co przyrost).\n",
|
||||
"\n",
|
||||
"* Wnioski:\n",
|
||||
"\n",
|
||||
" * 1: Każdy zespół powinien zawierać osobę, która zajmuje się testowaniem „na pełen etat”.\n",
|
||||
" * 2: W każdym sprincie powinno odbyć się testowanie na każdym poziomie.\n",
|
||||
" * 3: W każdym kolejnym sprincie pojawiają się nowe przypadki testowe, ale wszystkie „stare” pozostają.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5. Testowanie jednostkowe\n",
|
||||
"### Zasady testowania jednostkowego\n",
|
||||
"\n",
|
||||
" 1. Przedmiotem testowania są podstawowe jednostki programu.\n",
|
||||
" 2. Testy jednostkowe tworzone są przez dewelopera - programistę.\n",
|
||||
" 3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First.\n",
|
||||
" 4. Test jednostkowy powinien testować jednostkę w izolacji. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.1. Przedmiotem testowania są podstawowe jednostki programu\n",
|
||||
" * Every method needs to be tested.”\n",
|
||||
" * W praktyce testowane są tylko metody publiczne…\n",
|
||||
" * …Co oznacza, że testy metod publicznych muszą być tak dokładne, by testowały WSZYSTKIE wywoływane przez nie metody prywatne…\n",
|
||||
" * …Co również oznacza, że defekty w metodach prywatnych ujawnione zostaną dopiero w testach dla metod publicznych.\n",
|
||||
" * „Keep test logic out of production code”\n",
|
||||
" * Nie wprowadzaj testów jednostkowych do kodu produkcyjnego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.2. Testy jednostkowe tworzone są przez programistę\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/testy jednostkowe.png\" alt=\"Testy jednostkowe\" width=800px>\n",
|
||||
"(rysunek na podstawie: Tilo Linz, \"Testing in Scrum\")"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First\n",
|
||||
"#### Zasady strategii Test First \n",
|
||||
" * Zanim napiszesz linijkę kodu, napisz test automatyczny, który się nie powodzi.\n",
|
||||
" * Pisz kod tak długo, aż powiodą się wszystkie testy.\n",
|
||||
"#### Zalety strategii TestFirst\n",
|
||||
" * Testowanie zastępuje metodę prób i błędów.\n",
|
||||
" * Realizacja przypadków testowych jest obiektywną miarą postępów w pracy.\n",
|
||||
" * Przypadki testowe zastępują formalną specyfikację.\n",
|
||||
" * „Test first” wprowadza porządek w interfejsach między klasami.\n",
|
||||
" * „Test first” świetnie wpisuje się w Scrum."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.4. Test jednostkowy powinien testować wyłącznie jednostkę (w izolacji)\n",
|
||||
" * Każdy obiekt testowany jest indywidualnie…\n",
|
||||
" * …Ale działanie obiektu może zależeć od innych komponentów…\n",
|
||||
" * …Które mogą być niezaimplementowane w czasie testowania.\n",
|
||||
" * Takie komponenty zastępuje się zamiennikami (ang. placeholder).\n",
|
||||
"\n",
|
||||
" * Typy zamienników:\n",
|
||||
" * Stub (zalążek) - imituje obiekt zewnętrzny, który przekazuje dane do testowanego obiektu).\n",
|
||||
" * Spy (szpieg) - zapamiętuje historię danych przekazywanych przez testowany obiekt).\n",
|
||||
" * Mock (atrapa) - \"inteligentnie\" imituje obiekt zewnętrzny, który reaguje na dane przekazywane z testowanego obiektu.\n",
|
||||
" * Fake (podróbka) - mocno uproszczona atrapa obiektu zewnętrznego, która nie ma wpływu na wynik testowania.\n",
|
||||
" * Dummy (manekin) - pusty obiekt.\n",
|
||||
" * Blog na temat zamienników:\n",
|
||||
" [Przeczytaj o zamiennikach](https://dariuszwozniak.net/posts/kurs-tdd-19-mock-stub-fake-spy-dummy)\n",
|
||||
" \n",
|
||||
" **Przykład stuba (zalążka)**: \n",
|
||||
" <img src=\"obrazy/stub.png\" alt=\"Przykład zalążka\" width=400px>\n",
|
||||
"(rysunek na podstawie: wikipedia\")\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6. Testowanie integracyjne w Scrumie\n",
|
||||
" * Celem testowania integracyjnego jest sprawdzenie, czy niezależne komponenty (np. klasy) prawidłowo ze sobą współpracują.\n",
|
||||
" * Testowanie wykonują deweloperzy (na swojej maszynie) lub zespół testujący (w repozytorium).\n",
|
||||
" * Metody testowania integracyjnego:\n",
|
||||
" * Metoda wielkiego wybuchu\n",
|
||||
" * Metoda stopniowej integracji i testowania\n",
|
||||
" * W metodyce Scrum możliwe jest stosowanie obu metod:\n",
|
||||
" * Metoda wielkiego wybuchu na zakończenie sprintu lub\n",
|
||||
" * Metoda Ciągłej Integracji (testowanie po każdej zmianie)\n",
|
||||
" * Systemy Ciągłej Integracji ułatwiają testowanie po każdej zmianie poprzez uruchamianie testów automatycznych. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Podsumowanie\n",
|
||||
" * Niewykryte defekty w kodzie programu mogą doprowadzić do poważnej awarii lub katastrofy.\n",
|
||||
" * Testowanie jest czynnością kreatywną, której celem jest wykazanie istnienia defektów w kodzie.\n",
|
||||
" * Przypadki testowe mają na celu ograniczenie przestrzeni wyszukiwania defektów.\n",
|
||||
" * Testowanie odbywa się na różnych poziomach – w tradycyjnych systemach jest to proces sekwencyjny, a w Scrumie – iteracyjny."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "08. Testowanie w programowaniu zwinnym[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,464 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 9. <i>Testowanie systemowe i adaptacyjne</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Testowanie systemowe i adaptacyjne - wyjaśnienie pojęć"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie systemowe</h3>\n",
|
||||
" \n",
|
||||
"Przedmiotem <b>testowania systemowego</b> jest całość oprogramowania zainstalowana w pewnym środowisku wykonawczym.\n",
|
||||
" * Środowisko testowania musi być zbliżone do środowiska pracy.\n",
|
||||
" * Testowanie systemowe odbywa się metodą „czarnej skrzynki”.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie adaptacyjne</h3>\n",
|
||||
" \n",
|
||||
"Przedmiotem <b>testowania adaptacyjnego </b> jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy.\n",
|
||||
" * Testowana jest zgodność z wymaganiami i potrzebami użytkownika.\n",
|
||||
" * Testowanie akceptacyjne przeprowadza użytkownik / klient.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Typy testowania systemowego"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"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",
|
||||
" * 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",
|
||||
" * testy zdroworozsądkowe\n",
|
||||
" * testy regresywne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy dymne\n",
|
||||
"**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",
|
||||
"<img src=\"obrazy/testy dymne.png\" alt=\"Przykład testów dymnych\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy zdroworozsądkowe\n",
|
||||
"**Testy zdroworozsądkowe** 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",
|
||||
"<img src=\"obrazy/sanity test.png\" alt=\"Przykład testów zdroworozsądkowych\" width=900px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy regresywne\n",
|
||||
"**Testy regresywne** to szczegółowe testy, pozwalające wykazać, że w aplikacji powstały nieznane błędów będące wynikiem wprowadzonych zmian.\n",
|
||||
"\n",
|
||||
"**Przykład przypadku testowego na poziomie testowania regresywnego:**\n",
|
||||
"<img src=\"obrazy/testy regresywne.png\" alt=\"Przykład testów regresywnych\" width=900px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Raport z testowania funkcjonalnego\n",
|
||||
"Przypadki testowe w testowaniu funkcjonalnym warto tworzyć w takiej formie, aby łatwo można je było rozszerzyć o wyniki testowania - tworząc raport z testowania.\n",
|
||||
"\n",
|
||||
"**Fragment raportu z testowania funkcjonalnego:**\n",
|
||||
"<img src=\"obrazy/raport z testowania.png\" alt=\"Przykład raportu z testowania\" width=900px>\n",
|
||||
"\n",
|
||||
"W raporcie z testowania można zawrzeć dodatkowe informacje np. o wydajności działania danego przypadku testowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Testowanie wydajności (performance testing)\n",
|
||||
"Zadaniem **testowania wydajności** jest wykazanie, że system nie daje odpowiedzi w wystarczająco krótkim czasie pod ustalonym obciążeniem produkcyjnym, np. przy dużym wolumenie przetwarzanych danych.\n",
|
||||
"\n",
|
||||
"**Przykładowy fragment raportu z testowania wydajności systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/performance test.png\" alt=\"Przykład raportu z testowania wydajności\" width=600px>\n",
|
||||
"\n",
|
||||
"**Stronę internetową** można bardzo szybko przetestować pod kątem wydajności, korzystając np. z narzędzia dostępnego na stronie https://webspeed.intensys.pl/.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"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",
|
||||
"\n",
|
||||
"**Przykład raportu tekstowego z testu przeciążeń systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/load test - raport tekstowy.png\" alt=\"Przykład raportu z testowania\" width=800px>\n",
|
||||
"\n",
|
||||
"**Przykład raportu graficznego z testu przeciążeń systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/load test - raport graficzny.png\" alt=\"Przykład raportu z testowania\" width=800px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.4. Testowanie pamięci (memory testing)\n",
|
||||
"Celem **testowania pamięci** jest wykazanie, że system narusza narzucone wymagania pamięciowe."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.5. Testowanie ochrony danych (security testing)\n",
|
||||
"Proces ma wykazać, że dane nie są chronione w odpowiedni sposób.\n",
|
||||
" * Przypadki testowe mają wymusić naruszenie mechanizmów ochrony danych."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.6. Testowanie konfiguracji\n",
|
||||
"**Testowanie konfiguracji** ma na celu zweryfikowanie działania systemu w różnych konfiguracjach sprzętowych i programowych.\n",
|
||||
" * Testowanie może odbywać się za pomocą specjalnie przygotowanej maszyny wirtualnej.\n",
|
||||
" * Dla serwisów webowych istotne jest testowanie różnych urządzeń oraz różnych typów przeglądarek."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.7. Testowanie zgodności wersji\n",
|
||||
"**Testowanie zgodności wersji** ma na celu wykazanie niezgodności z przeszłymi wersjami programów:\n",
|
||||
" * testowanie patchów i aktualizacji,\n",
|
||||
" * testowanie nowych wersji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.8. Testowanie zgodności z dokumentacją użytkownika\n",
|
||||
"Jest to próba wykrycia rozbieżności między programem a jego specyfikacją zapisaną w dokumentacji użytkownika.\n",
|
||||
" * Przy okazji porównuje się dokumentację użytkownika z pierwotnymi celami projektowymi.\n",
|
||||
" * Ten typ testowania stosowany jest również w testowaniu akceptacyjnym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.9. Testowanie procedury instalacyjnej\n",
|
||||
"Celem jest wykazanie istnienia defektów poprzez wywołanie błędów w trakcie procedury instalacyjnej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.10. Testowanie odporności (resilience testing)\n",
|
||||
"Zadaniem **testowania odporności** jest postawienie pod znakiem zapytania odporności systemu na awarie. \n",
|
||||
" * Testowanie polega na umyślnym „zasianiu” w kodzie programu różnorakich błędów.\n",
|
||||
" * Odporność na awarie mierzy się przy pomocy MTTR (mean time to recovery).\n",
|
||||
" * Celem testowania jest wskazanie, że łączny czas przestojów przekracza limit określony w celach projektowych."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Testowanie akceptacyjne\n",
|
||||
"## Cele testowania akcpetacyjnego\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",
|
||||
" * Wykrycie defektów.\n",
|
||||
" \n",
|
||||
" ## Kto i kiedy wykonuje testowanie akceptacyjne?\n",
|
||||
"* Testowanie akceptacyjne wykonywane jest przez: \n",
|
||||
" * właścicieli produktów (przedstawicieli wykonawców);\n",
|
||||
" * wyznaczonych przedstawicieli strony zamawiającej;\n",
|
||||
" * operatorów systemów (np. pełniących rolę administratora);\n",
|
||||
" * użytkowników końcowych.\n",
|
||||
"* Testowanie akceptacyjne jest zazwyczaj ostatnim etapem sekwencyjnego cyklu życia oprogramowania.\n",
|
||||
"* W iteracyjnych modelach wytwarzania oprogramowania testowanie akceptacyjne może odbywać się na zakończenie każdej iteracji (np. sprintu). \n",
|
||||
"\n",
|
||||
"## Typy testowania akceptacyjnego\n",
|
||||
" * Testowanie akceptacyjne przez użytkownika\n",
|
||||
" * Testowanie produkcyjne\n",
|
||||
" * Testowanie akceptacyjne zgodności \u000b",
|
||||
"z umową i zgodności \u000b",
|
||||
"z przepisami prawa\n",
|
||||
" * Testy alfa i testy beta"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Testowanie akceptacyjne przez użytkownika\n",
|
||||
"Ma na celu sprawdzenie, czy system nadaje się do użytkowania przez przyszłych odbiorców: \n",
|
||||
" * czy spełni ich potrzeby, \n",
|
||||
" * czy wypełni postawione wymagania,\n",
|
||||
" * wykona proces biznesowy z minimalną liczbą problemów, minimalnymi kosztem i ryzykiem."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2 Produkcyjne testy akceptacyjne\n",
|
||||
"Są to testy systemu przez operatorów lub administratorów, które mogą obejmować:\n",
|
||||
" * testowanie mechanizmów tworzenia kopii zapasowych i odtwarzania danych;\n",
|
||||
" * instalowanie, odinstalowywanie i aktualizowanie oprogramowania;\n",
|
||||
" * usuwanie skutków awarii;\n",
|
||||
" * zarządzanie użytkownikami;\n",
|
||||
" * wykonywanie czynności pielęgnacyjnych;\n",
|
||||
" * wykonywanie czynności związanych z ładowaniem i migracją danych;\n",
|
||||
" * sprawdzanie, czy występują podatności zabezpieczeń;\n",
|
||||
" * wykonywanie testów wydajnościowych."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 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",
|
||||
" * Wykonywane jest często przez niezależnych testerów pod nadzorem."
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"# 4. Testowanie automatyczne\n",
|
||||
"**Automatyzacja testowania** polega na zastąpienia testera oprogramowaniem, które:\n",
|
||||
"* Steruje testem,\n",
|
||||
"* Porównuje wyniki z oczekiwaniami,\n",
|
||||
"* Raportuje błędy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Podejścia do testowania automatycznego\n",
|
||||
"\n",
|
||||
"### Code-driven testing (testowanie sterowane kodem)\n",
|
||||
" * Testowane są publiczne interfejsy do klas (modułów, bibliotek) poprzez podanie różnorakich danych wejściowych i walidacji wyników.\n",
|
||||
" * Jest to poziom testów jednostkowych.\n",
|
||||
"\n",
|
||||
"### Graphical user interface testing (testowanie graficznego interfejsu użytkownika)\n",
|
||||
" * Generowane są zdarzenia interfejsu takie jak: kliknięcia myszką czy naciśnięcie klawiszy i obserwowane są zmiany w interfejsie użytkownika. \n",
|
||||
" * Jest to poziom testów systemowych.\n",
|
||||
" \n",
|
||||
"#### Testowanie za pomocą makr, np. Macro Express (https://www.macros.com/)\n",
|
||||
"1. Nagrywamy makro realizujące ciąg zdarzeń (kliknięć, klawiszy itp.),\n",
|
||||
"2. przygotowujemy zestaw plików graficznych, które obrazują kolejne oczekiwane wyglądy interfejsu,\n",
|
||||
"3. podczas testowania każdorazowo porównujemy obrazy interfejsu z obrazami oczekiwanymi.\n",
|
||||
"\n",
|
||||
"#### Testowanie za pomocą oprogramowania, np. Selenium\n",
|
||||
"(http://tynecki.pl/pdf/Automating-functional-tests-using-Python-and-Selenium-Piotr-Tynecki.pdf)\n",
|
||||
"* Opracowujemy sekwencję zdarzeń (kliknięć, klawiszy itp.).\n",
|
||||
"* Sprawdzamy powodzenie testowanej operacji (np. sprawdzamy, czy istnieje na stronie poszukiwany element).\n",
|
||||
"\n",
|
||||
"#### Zalety automatycznego testowania GUI\n",
|
||||
"* Może być stosowane do każdego oprogramowania z graficznym interfejsem użytkownika.\n",
|
||||
"* Znakomicie wkomponowuje się w paradygmat „continous integration”.\n",
|
||||
"\n",
|
||||
"#### Wady automatycznego testowania GUI\n",
|
||||
"* Przygotowanie przypadków testowych jest czasochłonne.\n",
|
||||
"* Każda najmniejsza zmiana interfejsu powoduje konieczność opracowania nowego zestawu testowego.\n",
|
||||
"* W scenariuszach zawarte są się często operacje nieistotne z punktu widzenia testowania."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Plan testów\n",
|
||||
"**Plan testów** to dokument opisujący organizację procesu testowania. \n",
|
||||
" * Dotyczy zazwyczaj testowania systemowego.\n",
|
||||
" * Plan testów składa się z następujących elementów:\n",
|
||||
" * Zakres testów\n",
|
||||
" * Strategia testowania\n",
|
||||
" * Zasoby niezbędne do testów\n",
|
||||
" * Specyfikacja testów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5.1. Zakres testów\n",
|
||||
" * Identyfikacja testowanego produktu (co testujemy?)\n",
|
||||
" * Określenie wymagań (właściwości), które testujemy\n",
|
||||
" * Określenie wymagań (właściwości), których nie testujemy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5.2. Metodologia testowania\n",
|
||||
" * Określenie typów testowania, które przeprowadzimy.\n",
|
||||
" * Określenie typów testowania, których nie przeprowadzimy.\n",
|
||||
" * Zdefiniowanie metod oceny testu\n",
|
||||
" * Zdefiniowanie typów błędów (awarie, błędy istotne, błędy nieistotne)\n",
|
||||
" * Określenie kryteriów pozytywnego zakończenia testów\n",
|
||||
" * Przykładowo: określenie dopuszczalnej liczby błędów poszczególnego typu\n",
|
||||
" * Określenie postaci raportu z testów\n",
|
||||
" \n",
|
||||
"**Przykład definicji błędów:**\n",
|
||||
" <img src=\"obrazy/definicje błędów.png\" alt=\"Przykład definicji błędów\" width=500px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.3. Zasoby niezbędne do testów\n",
|
||||
" * Środowisko testowe\n",
|
||||
" * Oprogramowanie zastosowane w testowaniu\n",
|
||||
" * Zespół wykonawców\n",
|
||||
" * Warunki początkowe, np.:\n",
|
||||
" * np. wykonane prace instalacyjne lub konfiguracyjne\n",
|
||||
" * stopień ukończenia prac implementacyjnych\n",
|
||||
" \n",
|
||||
"**Przykład oprogramowania zastosowanego w testowaniu:**\n",
|
||||
"<img src=\"obrazy/software.png\" alt=\"Przykład definicji błędów\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.4. Specyfikacja testów \n",
|
||||
"**Specyfikacja testów** to zestaw scenariuszy testowych (przypadków testowych)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
" * Testowanie manualne jest wciąż najczęściej stosowaną metodą testowania systemowego i akceptacyjnego.\n",
|
||||
" * Testowanie automatyczne staje się coraz bardziej popularne; \n",
|
||||
" * jest pracochłonne w przygotowaniu,\n",
|
||||
" * ale oszczędza czas samego procesu testowania.\n",
|
||||
" * Niezależnie od typu testowania, jest to czynność, którą należy starannie zaplanować."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "09. Testowanie integracyjne i systemowe[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,585 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 10. <i>Wybrane zagadnienia użyteczności</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Pojęcie użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \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",
|
||||
"<h3> Cechy aplikacji użytecznej </h3>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
"<li> Łatwa do nauki: Jak łatwo jest użytkownikom wykonać dane zadanie po raz pierwszy?\n",
|
||||
"<li> Wydajna w pracy: Jak szybko użytkownicy wykonują zadania, gdy już się nauczyli programu?\n",
|
||||
"<li> Satysfakcja: Czy korzystanie z programu daje satysfakcję?\n",
|
||||
"<li> 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",
|
||||
"<li> Zapamiętywalna po czasie: Jak łatwo powrócić do biegłości użytkowania po pewnym okresie nieużytkowania programu?\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Wskazówki do tworzenia użytecznej aplikacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Klasyka w oparciu o \"Don't make me think\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<a href=\"https://www.uxbooth.com/articles/10-usability-lessons-from-steve-krugs-dont-make-me-think/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"<ol> \n",
|
||||
" \n",
|
||||
"<li> Usability Means… </li>\n",
|
||||
"\n",
|
||||
"<li>Web applications should explain themselves. </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t Make Me Think </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t waste my time </li>\n",
|
||||
" \n",
|
||||
"<li> Users still cling to their back buttons </li>\n",
|
||||
"\n",
|
||||
"<li> We’re creatures of habit </li>\n",
|
||||
"\n",
|
||||
"<li> No Time for Small Talk </li>\n",
|
||||
"\n",
|
||||
"<li> Don’t lose search </li>\n",
|
||||
"\n",
|
||||
"<li> We form mental site-maps </li>\n",
|
||||
"\n",
|
||||
"<li> Make it easy to go home </li>\n",
|
||||
" \n",
|
||||
"</ol>\n",
|
||||
"\n",
|
||||
"<div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Podejście (bardziej) współczesne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Wskazówki do tworzenia użytecznego systemu informatycznego</h3> \n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
"<li> Autorze: Poznaj użytkownika, a TY nie jesteś użytkownikiem. </li> \n",
|
||||
" <li> Użytkownik powinien mieć kontrolę nad systemem, a nie odwrotnie: to użytkownik jest szefem i system powinien to okazywać. </li> \n",
|
||||
" <li> System musi ułatwiać użytkownikowi życie:</li>\n",
|
||||
" <ul>\n",
|
||||
" <li> 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. </li>\n",
|
||||
" <li> Każda akcja użytkownika powinna mieć reakcję programu. </li>\n",
|
||||
" <li> Kiedy użytkownik ma do podjęcia decyzję, system podaje mu całą dostępną informację. </li>\n",
|
||||
" </ul> \n",
|
||||
" <li> System musi być \"idioto-odporny\": </li>\n",
|
||||
" <ul>\n",
|
||||
" <li> Każdy robi błędy, więc każdy błąd powinien dać się naprawić. </li>\n",
|
||||
" <li> Gdy użytkownik zrobi błąd, System daje mu o tym znać, zanim … wpadnie w PRAWDZIWE kłopoty. </li>\n",
|
||||
" <li> Informacje o błędach powinny być zrozumiałe dla użytkownika i mówić mu, jak naprawić problem. </li>\n",
|
||||
" </ul> \n",
|
||||
" <li> Wczuj się w użytkownika </li>\n",
|
||||
" <ul>\n",
|
||||
" <li> Eliminuj niepotrzebne decyzje (nie pytaj, jak nie musisz). </li>\n",
|
||||
" <li> Im mniej kroków do celu, tym lepiej.</li> \n",
|
||||
" <li> Użytkownik powinien zawsze móc dowiedzieć się, co robić dalej. </li>\n",
|
||||
" <li> Użytkownik powinien zawsze wiedzieć, co się dzieje.\n",
|
||||
" </ul>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3. Zasady dobrej nawigacji na portalu internetowym\n",
|
||||
"### 3.1. Pojęcie nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<b> Nawigacja </b> to stały, niezmieniający się zestaw elementów w serwisie ułatwiający poruszanie się na niej.\n",
|
||||
" \n",
|
||||
"Najczęściej stosowanymi elementami nawigacji są: \n",
|
||||
"<ul>\n",
|
||||
"<li> Menu główne </li>\n",
|
||||
"<li> Menu narzędziowe </li>\n",
|
||||
"<li> Identyfikator witryny </li>\n",
|
||||
"<li> Wyszukiwarka </li>\n",
|
||||
"<li> Odsyłacz do strony startowej (zawarty w logo) </li>\n",
|
||||
"<li> Flagi narodowe (przełączenie języków) </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Cechy dobrej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Szybkie przechodzenie po różnych elementach serwisu.\n",
|
||||
" * Łatwe prowadzenie użytkownika do poszukiwanej informacji. \n",
|
||||
" * Klarowność: użytkownik wie gdzie jest, gdzie może się skierować, jak wrócić, a także posiada informacje o odwiedzonych miejscach. \n",
|
||||
" * Oszczędność: główne menu witryny nie powinno zawierać zbyt wielu elementów (między 5 a 9)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.3. Zasady użytecznej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 1. Widoczność\n",
|
||||
"Wszystkie elementy nawigacji muszą być bardzo dobrze widoczne na każdej stronie i podstronie serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 2. Przewidywalność\n",
|
||||
" * Nazwy elementów menu powinny pozwalać na przewidzenie zawartości\n",
|
||||
" * Elementy menu powinny informować użytkownika o całej zawartości witryny.\n",
|
||||
" * Odwiedzone linki powinny być oznaczone innym kolorem niż nieodwiedzone. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 3. Łatwość orientacji w strukturze serwisu\n",
|
||||
"* Powinno się stosować różne style wyróżnienia jego elementów:\n",
|
||||
" * dla całej kategorii, na której aktualnie znajduje się kursor (np. Aktualności),\n",
|
||||
" * dla pozycji w menu, z której aktualnie korzysta użytkownik (np. Publikacje zagraniczne),\n",
|
||||
" * dla pozostałych elementów serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 4. Zasada odwróconej piramidy\n",
|
||||
" * Na najwyższym poziomie należy umieścić kategorie najbardziej ogólne, a następnie przechodzić do podziału bardziej szczegółowego. \n",
|
||||
" * Na tym samym poziomie powinny znajdować się kategorie o tym samym stopniu szczegółowości."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 5. Właściwe nazewnictwo\n",
|
||||
" * Wykluczający podział etykiet menu: \n",
|
||||
" * dana pozycja w menu może należeć tylko do jednej kategorii.\n",
|
||||
" * Proste nazewnictwo: \n",
|
||||
" * etykiety powinno formułować się w języku zrozumiałym dla użytkownika,\n",
|
||||
" * powinno unikać się specjalistycznego słownictwa.\n",
|
||||
" * Unikalne nazwy: \n",
|
||||
" * dana nazwa powinna pojawiać się w serwisie internetowym nie więcej niż raz,\n",
|
||||
" * każda strona powinna mieć swoja nazwę.\n",
|
||||
" * Nazwa strony musi być dobrze widoczna:\n",
|
||||
" * nazwa strony musi być w dobrze umiejscowiona i wyróżniona za pomocą rozmiaru i koloru czcionki.\n",
|
||||
" * Nazwa strony lub podstrony musi być zgodna z nazwą odsyłacza, który do niej prowadzi."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 6. Spójność w wyglądzie i działaniu elementów nawigacyjnych\n",
|
||||
"* Należy stosować te same konwencje w obrębie całego menu. \n",
|
||||
"* Elementy pierwszego poziomu powinny pozostawać niezmienne w trakcie korzystania z całego serwisu internetowego. \n",
|
||||
"* Wszystkie pozycje w menu powinny funkcjonować na tej samej zasadzie. \n",
|
||||
"* Przy formułowaniu nazw w menu należy w każdym przypadku stosować tę samą formę gramatyczną.\n",
|
||||
"* Pozycje menu należące do jednego poziomu powinny być sformatowane w jednym stylu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Automatyczne metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Badanie współczynnika konwersji\n",
|
||||
"**Współczynnik konwersji** wskazuje, jaka część internautów odwiedzających daną stronę dokonała pożądanej akcji np.\n",
|
||||
" * Dokonała zakupu\n",
|
||||
" * Wypełniła formularz\n",
|
||||
" * Wysłała maila na wskazany adres\n",
|
||||
" * Zarejestrowała się do systemu\n",
|
||||
" * Pobrała software"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy A/B (testy porównawcze)\n",
|
||||
"* Metoda polega na porównaniu dwóch wersji tej samej aplikacji.\n",
|
||||
"* Najczęściej stosowana jest do stron internetowych.\n",
|
||||
"* Różnicę (postęp lub regres) między wersjami wyznacza się poprzez porównanie wartości pewnej miary, np. współczynnika konwersji dla stron internetowych. \n",
|
||||
"\n",
|
||||
"[Przeczytaj w Internecie](https://www.optimizely.com/ab-testing/)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analityka ruchu na portalu internetowym\n",
|
||||
"Metoda polega na obserwacji dotyczących ruchu na witrynie, takich jak:\n",
|
||||
" * Wskaźnik odrzuceń – procentowa wartość osób, które opuściły stronę wejściową serwisu bez wykonania żadnej akcji\n",
|
||||
" * Wskaźnik porzuceń – wskaźnik analogiczny dla podstron danego serwisu,\n",
|
||||
"Metoda wskazuje działania użytkownika – nie wskazuje jego przyczyn. \n",
|
||||
"\n",
|
||||
"Przykładowa witryna: \n",
|
||||
"https://www.google.com/analytics/"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Click-tracking\n",
|
||||
"\n",
|
||||
"Metoda dostarcza informacji o poszczególnych elementach strony za pomocą następujących typów informacji\n",
|
||||
" * Heat maps. \n",
|
||||
" * Wskazują, w jakie miejsca na stronie ludzie klikają (see what’s hot and what’s not).\n",
|
||||
" * Confetti\n",
|
||||
" * Analiza kliknięć: jak klikały poszczególne grupy użytkowników i w poszukiwaniu czego.\n",
|
||||
" * Scrollmap\n",
|
||||
" * Analiza, jak daleko w dół strony użytkownicy przewijają stronę – pozwala przeanalizować miejsca, w których strona jest najczęściej porzucana.\n",
|
||||
" * Overlay report\n",
|
||||
" * Liczba kliknięć na poszczególne elementy strony.\n",
|
||||
"\n",
|
||||
"Przykładowy dostawca: \n",
|
||||
"http://www.crazyegg.com"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analiza kontrastu\n",
|
||||
"\n",
|
||||
"Dostarcza informacji o kontraście pomiędzy elementami strony, co jest szczególnie istotne dla osób z upośledzeniem wzroku.\n",
|
||||
"\n",
|
||||
"* Przykładowy adres\n",
|
||||
" * https://webaim.org/resources/contrastchecker/\n",
|
||||
" * Można wpisać adres strony, która ma zostać przeanalizowana pod względem kontrastu – otrzymuje się pełen raport."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Metody z udziałem użytkowników\n",
|
||||
"\n",
|
||||
"W metodach z udziałem użytkowników można posłużyć się zastosowaniem *persony*, w celu optymalizacji kosztów badania.\n",
|
||||
" * **Persona** to fikcyjna postać stworzona by reprezentować typy użytkowników (demograficzne i technograficzne).\n",
|
||||
" * Persony to inaczej archetypy grup użytkowników i ich potrzeb. Dzięki personom cała populacja docelowa reprezentowana jest przez kilka konceptów.\n",
|
||||
" > Przykład persony: Jan Kowalski, lat 37, elektryk, mieszkaniec Ząbkowic Śląskich\n",
|
||||
" \n",
|
||||
" Przykładowy proces testowania użyteczności z udziałem użytkowników:\n",
|
||||
" 1. Określ grupy użytkowników np. przy użyciu persony (co najmniej jedna persona na grupę).\n",
|
||||
" 2. Dla każdej persony utwórz potencjalny scenariusz użycia – w jaki sposób dana persona chce korzystać z systemu.\n",
|
||||
" 3. Dla każdej persony zorganizuj użytkowników reprezentatywnych (minimum jednego użytkownika dla persony).\n",
|
||||
" 4. Poproś ich o wykonanie zadań charakterystycznych dla danej persony.\n",
|
||||
" 5. Obserwuj lub nagrywaj działania użytkowników: gdzie im się powodzi, a gdzie mają trudności.\n",
|
||||
" 6. Potencjalnie poproś użytkowników o wypełnienie ankiet.\n",
|
||||
"\n",
|
||||
"Wyróżniamy następujące typy metod z udziałem użytkowników:\n",
|
||||
" * podgląd sesji użytkowników.\n",
|
||||
" * obserwacja użytkownika,\n",
|
||||
" * metoda wywiadu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Podgląd sesji użytkowników\n",
|
||||
"* Działalność użytkownika jest „nagrywana”.\n",
|
||||
"* Autor oprogramowania może odtworzyć działania użytkownika z perspektywy użytkownika.\n",
|
||||
"* Każde kliknięcie, poruszenie myszą, przesunięcie kursora zostaje zapisane."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Obserwacja użytkownika\n",
|
||||
"* Działalność użytkownika jest obserwowana.\n",
|
||||
"* Obserwator zapisuje poczynania użytkownika.\n",
|
||||
"* Obserwacje są analizowane w celu ulepszenia użyteczności aplikacji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Metoda wywiadu\n",
|
||||
" * Sposoby przeprowadzenia wywiadu:\n",
|
||||
" * Analiza celów użytkowników i wykonywania przez nich zadań,\n",
|
||||
" * Dyskusja prowadzona przez moderatora,\n",
|
||||
" * Wypełnienie ankiet / kwestionariuszy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Raport badania użyteczności\n",
|
||||
"Raport badania użyteczności to sprawozdanie z badania użyteczności aplikacji, w którym wskazuje się **obszary problemowe**.\n",
|
||||
"Przykładowo raport użytecznści może składać się z następujących części:\n",
|
||||
"1. Informacje wstępne\n",
|
||||
"2. Metodologia badania\n",
|
||||
"3. Obszary problemowe\n",
|
||||
"4. Dodatki"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.1. Informacje wstępne\n",
|
||||
"Ta część zawiera ogólne informacje o prowadzonym badaniu, np. :\n",
|
||||
" * Daty tworzenia raportu\n",
|
||||
" * Harmonogram prowadzenia badań\n",
|
||||
" * Odwołanie do standardów badania użyteczności\n",
|
||||
" * Autorzy raportu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.2. Metodologia badania\n",
|
||||
"Opis tej części zależy od przejętej metody badania. Przykładowo, dla metody wywiadu część ta może mieć następującą postać:\n",
|
||||
"\n",
|
||||
"### 5.2.1. Zakres badania\n",
|
||||
" * Określenie zakresu projektowego: badanie gotowego produktu, czy ocena prototypu,\n",
|
||||
" * Określenie celu, np., wskazanie wyłącznie błędów w systemie, czy również wskazanie proponowanych ulepszeń,\n",
|
||||
" * Określenie zastosowanej metody badania użyteczności.\n",
|
||||
"\n",
|
||||
"### 5.2.2. Profile użytkowników\n",
|
||||
" * Określenie kilku segmentów odbiorców pod względem:\n",
|
||||
" * Danych demograficznych\n",
|
||||
" * Doświadczenia z programami podobnymi (wcześniejszymi wersjami systemu)\n",
|
||||
" * Oczekiwań względem systemu\n",
|
||||
"\n",
|
||||
"### 5.2.3. Grupa badawcza\n",
|
||||
" * Określenie liczebności grupy badawczej (około 5 osób)\n",
|
||||
" * Określenie charakterystyki grupy badawczej pod względem różnych kryteriów , np.\n",
|
||||
" * płeć, \n",
|
||||
" * wiek, \n",
|
||||
" * miejsce zamieszkania, \n",
|
||||
" * wykształcenie, \n",
|
||||
" * zawód, \n",
|
||||
" * wielkość firmy, \n",
|
||||
" * branża, \n",
|
||||
" * obsługa komputera, \n",
|
||||
" * doświadczenie z podobnymi programami, itp.\n",
|
||||
" * Liczebność i charakterystykę grupy badawczej można zobrazować za pomocą wykresów.\n",
|
||||
"\n",
|
||||
"### 5.2.4. Scenariusz badania\n",
|
||||
"W tej części należy opisać, jak będzie przebiegać scenariusz badania.\n",
|
||||
"Przykładowy scenariusz badania w metodzie wywiadu:\n",
|
||||
"1. Omówienie zadań i sposobu wypełniania kwestionariusza\n",
|
||||
"2. Podanie informacji o regulaminie przeprowadzenia testu wykonania zadań\n",
|
||||
"3. Test wykonania zadań\n",
|
||||
"4. Wypełnienie przygotowanego kwestionariusza przez użytkowników\n",
|
||||
"\n",
|
||||
"### 5.2.5. Lista zadań do wykonania przez użytkowników\n",
|
||||
"W tej częścI dla każdego zadania należy podać kryterium pomyślnego ukończenia zadania. Lista zadań może być podana w postaci tabelki:\n",
|
||||
" * Opis zadania\n",
|
||||
" * Kryterium ukończenia zadania\n",
|
||||
"\n",
|
||||
"### 5.2.6. Ocena wykonania zadań \n",
|
||||
"W tej części należy ocenić, jak badani wykonali zadania.\n",
|
||||
"Przykładowa ocena wykonania zadań:\n",
|
||||
" * Liczba błędów krytycznych użytkownika\n",
|
||||
" * Liczba błędów niekrytycznych użytkownika\n",
|
||||
" * Liczba zadań wykonanych zgodnie z założeniami\n",
|
||||
" * Liczba zdań niewykonanych zgodnie z założeniami\n",
|
||||
" * Czas wykonania zadań\n",
|
||||
"\n",
|
||||
"Ten etap raportu można zakończyć wykresami."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.3. Obszary problemowe\n",
|
||||
"Obszary problemowe to **wnioski** z badania użyteczności.\n",
|
||||
" * W tej częśći raportu określone zostają obszary problemowe (składowe systemu, które sprawiają kłopoty).\n",
|
||||
" * Dla każdego obszaru problemowego określa się zestaw problemów użytkowania.\n",
|
||||
" * Problem użytkowania składa się z:\n",
|
||||
" * Tytułu problemu,\n",
|
||||
" * Opisu problemu,\n",
|
||||
" * Jeśli problemem jest zbyt długi czas wykonania zadania, to można podać średnie czasy rozwiązania,\n",
|
||||
" * Filmiku wideo (jeśli takim dysponujemy),\n",
|
||||
" * Rekomendacji rozwiązania problemu,\n",
|
||||
" * Opisu proponowanego scenariusza działania użytkownika po rozwiązaniu problemu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.4. Dodatki\n",
|
||||
"W tej części raportu składamy materiały pomocnicze, np.\n",
|
||||
" ### 5.4.1. Ankieta\n",
|
||||
"\n",
|
||||
"W ankiecie mogą znaleźć się przykładowe pytania:\n",
|
||||
" * Jak ocenia Pan/Pani trudność poszczególnych zadań?\n",
|
||||
" * Co sprawiło Panu/Pani największy problem podczas testów?\n",
|
||||
" * Jakie inne funkcjonalności byłyby pożyteczne (wskazać listę do wyboru)?\n",
|
||||
" * Jakie elementy systemu były niezrozumiałe?\n",
|
||||
"\n",
|
||||
" Wyniki ankiety potestowej możemy przedstawić na wykresach.\n",
|
||||
" \n",
|
||||
"### 5.4.2. Inne materiały pomocnicze\n",
|
||||
"Przykładowe materiały pomocnicze:\n",
|
||||
" * Lista filmów video ilustrujących błędy użyteczności aplikacji,\n",
|
||||
" * Wnioski i rekomendacje ekspertów użyteczności,\n",
|
||||
" * Inne materiały w zależności od zastosowanej metody badawczej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie wykładu\n",
|
||||
"1. Tworząc aplikację, myśl przede wszystkim o jej użyteczności, a potem dopiero o jej funkcjonalności.\n",
|
||||
"2. O sukcesie aplikacji stanowi pomysł, a nie wielość funkcji.\n",
|
||||
"3. Zawsze (!) pamiętaj o wskazówkach użyteczności.\n",
|
||||
"4. Tworząc portal internetowy, stosuj zasady dobrej nawigacji.\n",
|
||||
"5. Przekonaj się, jak Twój program jest używany – wykonaj badanie użyteczności."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "10. Wybrane zagadnienia użyteczności[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,691 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. <i>Aspekty użyteczności</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Aspekty użyteczności w pytaniach... często bez odpowiedzi\n",
|
||||
"Na podstawie książki \"Postaw na użyteczność\" Matta Laceya (Wydawnictwo Naukowe PWN, 2019).\n",
|
||||
"\n",
|
||||
"Podczas konstruowania systemu informatycznego warto zadać sobie pytania, na które odpowiedź wcale nie musi być oczywista - zależeć może ona od typu aplikacji i środowiska, w którym aplikacja będzie używana."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Definicja użyteczności (...jeszcze jedna)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \n",
|
||||
"\n",
|
||||
"Użyteczność to zestaw cech aplikacji, które sprawiają, że korzysta się z niej <b>łatwo</b>.\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Przepis na sukces\n",
|
||||
"\n",
|
||||
"SUKCES = WARTOŚĆ + ODCZUCIA UŻYTKOWNIKA + SZCZĘŚCIE"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Wartość</h3> \n",
|
||||
"\n",
|
||||
"Wartość aplikacji to suma korzyści dla użytkownika: \n",
|
||||
"<ul>\n",
|
||||
"<li>zadanie jest wykonalne\n",
|
||||
"<li>zadanie jest łatwiejsze\n",
|
||||
"<li>zadanie można wykonać szybciej\n",
|
||||
"<li>aplikacja dostarcza dochód lub oszczędza środki\n",
|
||||
"<li>dostarczenie rozrywki\n",
|
||||
"<li>dostarczenie informacji\n",
|
||||
"<li>edukacja \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Odczucia użytkownika (User Experience)</h3> \n",
|
||||
"\n",
|
||||
"Odczucia użytkownika to uczucia i emocje użytkownika doznawane podczas korzystania z aplikacji.\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Szczęście</h3> \n",
|
||||
"\n",
|
||||
"\"Szczęście przychodzi do tego, kto jest przygotowany i napotyka okazje.\" (Seneka)\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Sześć magicznych składników użyteczności...\n",
|
||||
"...czyli sześć aspektów, pod którymi powinniśmy rozpatrywać użyteczność:\n",
|
||||
"* kontekst, \n",
|
||||
"* wprowadzanie danych, \n",
|
||||
"* wyprowadzanie danych, \n",
|
||||
"* responsywność, \n",
|
||||
"* dostęp do sieci, \n",
|
||||
"* zasoby."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Kontekst"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Kontekst</h3> \n",
|
||||
"\n",
|
||||
"Kontekst to środowisko i okoliczności używania aplikacji. Odpowiada na pytania:\n",
|
||||
"<ul>\n",
|
||||
"<li>Kto?\n",
|
||||
"<li>Gdzie?\n",
|
||||
"<li>Kiedy?\n",
|
||||
"<li>Jak? \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Kto?\n",
|
||||
"\n",
|
||||
"ZASADY:\n",
|
||||
"\n",
|
||||
"1. Musisz precyzyjnie poznać użytkownika.\n",
|
||||
"2. To nie Ty jesteś użytkownikiem.\n",
|
||||
"3. Każdy jest inny.\n",
|
||||
"4. Użytkownik ma prawo robić coś innego\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.1. Musisz precyzyjnie poznać użytkownika\n",
|
||||
"\n",
|
||||
"* Dla kogo aplikacja będzie stanowić wartość?\n",
|
||||
" * Wskazówka: (patrz definicja wartości)\n",
|
||||
"* Kto dokładnie będzie użytkownikiem aplikacji?\n",
|
||||
" * Wskazówka: wykonaj diagram Venna\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/diagram Venna.png\" alt=\"Diagram Venna\" width=500px>\n",
|
||||
"(Przykładowy diagram Venna, Źródło: Matt Lacey, \"Postaw na użyteczność\")\n",
|
||||
"\n",
|
||||
"* Jakie są grupy użytkowników?\n",
|
||||
" * Wskazówka: metoda persony"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.2. To nie Ty jesteś użytkownikiem\n",
|
||||
" * Czym użytkownik różni się od siebie?\n",
|
||||
" * Czym mogą się rożnić oczekiwania innych uzytkowników od Twoich?\n",
|
||||
" * W stosunku do jakich niedociągnięć użytkownicy mogą być od Ciebie mniej pobłażliwi?\n",
|
||||
" * Dlaczego TY nie jesteś przeciętnym użytkownikiem Twojej aplikacji?\n",
|
||||
" * Jakie umiejętności Cię wyróżniają?\n",
|
||||
" * Dlaczego Tobie będzie łatwiej używać aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.3. Każdy jest inny\n",
|
||||
" * Czy użytkownicy aplikacji mogą się różnić w aspekcie dostępności?\n",
|
||||
" Na dostępność składają się:\n",
|
||||
" * umiejętności\n",
|
||||
" * wiedza\n",
|
||||
" * kultura\n",
|
||||
" * lokalizacja\n",
|
||||
" * płeć\n",
|
||||
" * wiek\n",
|
||||
" * niepełnosprawność\n",
|
||||
" * choroby (daltonizm)\n",
|
||||
" * Czy użytkownicy aplikacji mogą mieć od niej różne oczekiwania?\n",
|
||||
" * Czy użytkownicy aplikacji mogą chcieć uzyskać dzięki niej różne cele?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.4. Użytkownik ma prawo robić coś innego\n",
|
||||
" * Jakie inne działania będą podejmować użytkownicy podczas pracy z naszą aplikacją?\n",
|
||||
" * Jak się o tym dowiedzieć?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. 2. Gdzie?\n",
|
||||
"ZASADA: \n",
|
||||
"Czy aplikacja będzie stosowana w różnych krajach?\n",
|
||||
" * Jesli nie, to pomiń dalsze pytania.\n",
|
||||
" * Jeśli tak, to odpowiedz na dalsze pytania.\n",
|
||||
"\n",
|
||||
"PYTANIA:\n",
|
||||
" * Czy zaplanowałeś wielojęzyczność aplikacji?\n",
|
||||
" * Jakimi językami posługują się użytkownicy w innych krajach?\n",
|
||||
" * Zaplanuj tłumaczenie aplikacji\n",
|
||||
" * Czy użytkownicy innych krajów stosują te same formaty liczb / dat?\n",
|
||||
" * Jeśli nie, to opracuj algorytmy konwersji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Kiedy?\n",
|
||||
"### 1.3.1. Pora (dnia, tygodnia, miesiąca, roku)\n",
|
||||
"Czy aplikacja może działać w różny sposób w zależności od:\n",
|
||||
" * pory dnia\n",
|
||||
" * dnia tygodnia\n",
|
||||
" * dnia miesiąca\n",
|
||||
" * pory roku"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.3.2. Czas użytkowania\n",
|
||||
" * Jak długo trwa jedna sesja użytkowania?\n",
|
||||
" * daj możliwość korzystania nawet w bardzo krótkim czasie\n",
|
||||
" * Po jakim czasie użytkownik porzuci aplikację?\n",
|
||||
" * zachęcaj do pozostania z aplikacją"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.4. Jak?\n",
|
||||
"### 1.4.1. Okoliczności\n",
|
||||
" * Czy użytkownik jest w ruchu?\n",
|
||||
" * Czy użytkownik może wykonywać inne czynności?\n",
|
||||
" * Jakie?\n",
|
||||
" * Czy jest skupiony na naszej aplikacji?\n",
|
||||
" * Czy nasza aplikacja współpracuje z innymi?\n",
|
||||
" * W jakiej pozycji użytkownik korzysta z aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.4.2. Urządzenia\n",
|
||||
" * Zasada WORE (Write Once Run Everywhere)\n",
|
||||
" * Plusy\n",
|
||||
" * szybciej powstaje\n",
|
||||
" * łatwiejsza w utrzymaniu\n",
|
||||
" * możliwość dostosowania dla wielu urządzeń\n",
|
||||
" * przydatna szczególnie w grach (niestandardowy UI)\n",
|
||||
" * Minusy\n",
|
||||
" * wymagana znajomość różnych platform\n",
|
||||
" * wymagana dyscyplina kodu\n",
|
||||
" * konieczność dostosowania elementów wizualnych do różnych platform\n",
|
||||
" * konieczność testowania na wielu platformach\n",
|
||||
" * Różne systemy operacyjne\n",
|
||||
" * W jakich systamach operacyjnych ma działać aplikacja?\n",
|
||||
" * Czy wziąłeś pod uwagę ograniczenia narzucane przez różne sklepy?\n",
|
||||
" * Czy wygląd aplikacji jest zgodny z przyzwyczajeniami użytkowników danego systemu?\n",
|
||||
"\n",
|
||||
" * Wielkość urządzenia\n",
|
||||
" * Czy wziąłeś pod uwagę, że wielkość ekranu ma wpływ na to, co jest wyświetlane?\n",
|
||||
" * Czy pomyślałeś, jak trzymane jest urządzenie?\n",
|
||||
" \n",
|
||||
" * Przyciski sprzętowe\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Czujniki\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Wskazówka: Współczesne urządzenia mogę mieć kilkanaście czujników:\n",
|
||||
" * ruchu\n",
|
||||
" * pozycji\n",
|
||||
" * położenia\n",
|
||||
" * środowiskowe "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Wprowadzanie danych (Input)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Input</h3> \n",
|
||||
"\n",
|
||||
"Information fed into a data processing system or computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Interakcja użytkownik - system\n",
|
||||
"### 2.1.1. Wejście dotykowe\n",
|
||||
" * Czy wziąłeś pod uwagę zalecane minimalne wielkości obszarów dotykowych?\n",
|
||||
" * iOS: 11 mm\n",
|
||||
" * Android: 7-10 mm\n",
|
||||
" * Windows: 7-9 mm\n",
|
||||
"\n",
|
||||
" * Czy gesty obsługiwane są standardowo?\n",
|
||||
" * pojedyncze dotknięcie\n",
|
||||
" * podwójne dotknięcie\n",
|
||||
" * przesunięcie palcem po ekranie\n",
|
||||
" * dotknięcie i przytrzymanie\n",
|
||||
" * uszczypnięcie / rozciąganie\n",
|
||||
" * obracanie\n",
|
||||
" * inne (powstające)\n",
|
||||
" \n",
|
||||
" * Czy pomyślałeś o tym, że podczas dotykania ekranu jego część będzie zasłonięta?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.2. Rysik\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wprowadzania danych za pomocą rysika?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.3. Mysz i klawiatura\n",
|
||||
"\n",
|
||||
" * Czy aplikacja będzie obługiwana myszą i / lub klawiaturą?\n",
|
||||
" * Jeśli myszą, to weź pod uwagę spójność dotyku i uzycia myszy:\n",
|
||||
" * pojedyncze dotknięcie - pojedyncze kliknięcie\n",
|
||||
" * podwójne dotknięcie - podwójne kliknięcie\n",
|
||||
" * prawy przycisk myszy - przytrzymanie\n",
|
||||
" * przesuwanie myszą - przesuwanie palcem\n",
|
||||
" * Jeśli klawiaturą, to weź pod uwagę standardową reakcję klawiszy:\n",
|
||||
" * Tab\n",
|
||||
" * Enter\n",
|
||||
" * Ctrl\n",
|
||||
" * Shift"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.4. Wejście głosowe\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wejścia głosowego?\n",
|
||||
" * Jeśli tak, to weź pod uwagę ograniczenia techniczne systemów rozpoznawania mowy (np. architektura: klient - serwer)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Ułatwienia wprowadzania danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.1. Minimalizacja wysiłku użytkownika\n",
|
||||
" * Czy pomyślałeś o zminimalizowaniu wysiłku użytkownika przy wprowadzaniu danych?\n",
|
||||
" * Wskazówki:\n",
|
||||
" * proponowane wyboru zamiast ręcznego wprowadzania\n",
|
||||
" * skróty (szybki dostęp)\n",
|
||||
" * autosugestie (autouzupełnianie)\n",
|
||||
" * łączenie wprowadzania danych (np. daty przyjazdu / wyjazdu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.2. Optymalizacja formularzy\n",
|
||||
" * Czy w Twojej aplikacji dane są wprowadzane za pomocą formularzy? Jeśli tak, to odpowiedz na następujące pytania:\n",
|
||||
" * Czy dobrze posortowałeś listy wyboru?\n",
|
||||
" * Czy program reaguje już po części wpisanych danych?\n",
|
||||
" * Czy nad polami są ich etykiety?\n",
|
||||
" * Czy program podpowiada format danych?\n",
|
||||
" * Czy zapewniłeś wartości domyślne?\n",
|
||||
" * Czy pomyślałeś o walidacji danych?\n",
|
||||
" * Czy błędy pokazywane są w odpowiednim miejscu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.3. Altenatywne metody wprowadzania danych\n",
|
||||
" * Czy wziąłeś pod uwagę alternatywne metody wejścia?\n",
|
||||
" * wirtualna klawiatura\n",
|
||||
" * pismo ręczne\n",
|
||||
" * optyczne rozpoznawanie znaków\n",
|
||||
" * interaktywne mapy, pozwalające wskazać adres (lokalizację)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.3. Dane z innych źródeł"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Dane z innych źródeł</h3> \n",
|
||||
"\n",
|
||||
"Są to dane niewprowadzone przez użytkownika aplikacji.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.1. Dane z serwisów sieciowych\n",
|
||||
" * W jaki sposób nasza aplikacja może pozyskiwać informacje dane z serwisów sieciowych?\n",
|
||||
" * w formie odpowiedzi na żądanie\n",
|
||||
" * w formie powiadomień (notyfikacji)\n",
|
||||
" * w formie SMS-ów\n",
|
||||
" * Czy pomyślałeś o obsłudze komunikatów o błędach przesłanych z serwisów sieciowych?\n",
|
||||
" * Czy pomyślałeś o przetworzeniu przesłanych komunikatów (np. skróceniu ich, wyekstrahowaniu tego, co najważniejsze)?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.2. Dane z systemu operacyjnego\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane PIM (Personal Information Manager)?\n",
|
||||
" * wyszukiwanie danych teleadresowych\n",
|
||||
" * wyszukiwanie kontaktów\n",
|
||||
" * sprawdzanie poprawności wprowadzanych danych\n",
|
||||
" * korzystanie z osobistego kalendarza\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z systemu plików?\n",
|
||||
" * zdjęcia\n",
|
||||
" * filmy\n",
|
||||
" * teksty"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.3. Dane z innych aplikacji\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z innych aplikacji? \n",
|
||||
" * Jeśli tak, to w jaki sposób dane są współdzielone?\n",
|
||||
" * wspólne dane przechowywane lokalnie\n",
|
||||
" * natywne współdzielenie (wbudowany mechanizm współdzielenia danych)\n",
|
||||
" * formaty plików (typy MIME: Multipurpose Internet Mail Extensions)\n",
|
||||
" * metoda \"kopiuj i wklej\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.4. Dane z czujników\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z czujników? \n",
|
||||
" * Jeśli tak, to czy zadbałeś o to, aby\n",
|
||||
" * zapytać użytkownika o uprawnienia\n",
|
||||
" * wyjaśnić, w jaki sposób aplikacja będzie korzystać z czuujników\n",
|
||||
" * wyjaśnić, do czego dane te są potrzebne\n",
|
||||
" * wspomnieć o kwestiach polityki prywatności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.5. Inne typy wprowadzania danych\n",
|
||||
" * Czy istnieją jeszcze inne metody, w jaki aplikacja może pozyskać dane?\n",
|
||||
" * np. karta z chipem"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Wyprowadzanie danych (wyjście)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Output</h3> \n",
|
||||
"\n",
|
||||
"Information produced by a computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Wyjście wizualne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Zasady projektowania wizualnych komponentów wyprowadzania danych:</h3> \n",
|
||||
" \n",
|
||||
"<ol>\n",
|
||||
"<li> \"Cele użytkownika na pierwszym miejscu.\"\n",
|
||||
"<li> Spełnianie oczekiwań użytkowników\n",
|
||||
"<li> Uwzględnianie rodzaju urządzenia\n",
|
||||
"<li> Przestrzeganie norm i konwencji\n",
|
||||
"</ol>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Wyjście niewizualne\n",
|
||||
" * Czy wziąłeś pod uwagę możliwości wyprowadzania danych w inny sposób niż wizualnie?\n",
|
||||
" * dźwięki i wibracje\n",
|
||||
" * kanały komunikacji dla innych aplikacji\n",
|
||||
" * powiadomienia \"push\"\n",
|
||||
" * poczta elektroniczna\n",
|
||||
" * SMS"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Responsywność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Responsywność</h3> \n",
|
||||
"\n",
|
||||
"Cecha aplikacji, która powoduje, że użytkownicy uważają, że mogą uzyskać swój cel szybko - bez straty czasu.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Responsywność aplikacji to nie to samo co responsive design.**\n",
|
||||
"> Responsive design oznacza, że to co jest wyświetlane w danym momencie w aplikacji, dostosowuje się do zmieniającej się wielkości ekranu. \n",
|
||||
"> Pojęcie responsywności jest dużo szersze: aplikacja powinna reagować nie tylko na wielkość ekranu, lecz na akcje użytkownika i działania aplikacji. Szybkość i sposób, w jaki aplikacja odpowiada, przekłada się na doświadczenia użytkownika."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Dostęp do sieci\n",
|
||||
" * Czy wziąłeś pod uwagę potencjalne problemy z dostępem do sieci:\n",
|
||||
" * szybkość połączenia może się różnić\n",
|
||||
" * koszt połączenia może być zmienny\n",
|
||||
" * połączenie może być niedostępne\n",
|
||||
" * połączenie może być utracone"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 6. Zasoby"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Resource</h3> \n",
|
||||
"\n",
|
||||
"A source of supply, support, or aid, especially one that can be readily drawn upon when needed (www. dictionary.com)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" > A gdy się zasoby skończą, to ich nie będzie.\n",
|
||||
" \n",
|
||||
"Ilość zasobów jest skończona, więc naszym obowiązkiem jest je oszczędzać:\n",
|
||||
"\n",
|
||||
" * Energia\n",
|
||||
" * Pojemność dysku\n",
|
||||
" * Pojemność pamięci\n",
|
||||
" * Zasoby procesora\n",
|
||||
" * Możliwości przesyłu danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
"Użyteczność często rozumiana jest jako synonim łatwości użytkowania aplikacji.\n",
|
||||
"\n",
|
||||
"Zapewnienie, aby aplikacja używana była **łatwo**, nie jest zadaniem banalnym. Wymaga zadania wielu pytań, na które odpowiedzi mogą być zupełnie różne w zależności od typu aplikacji."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "11. Aspekty użyteczności[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,613 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 12. Ocena jakości systemu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Czym jest jakość produktu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Toma de Marco</h3> \n",
|
||||
" \n",
|
||||
"Jakość produktu to funkcja tego, jak bardzo zmienia on świat na lepsze.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Geralda Weinberga</h3> \n",
|
||||
" \n",
|
||||
"Jakość to subiektywnie pojmowana wartość.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Josepha Jurana</h3> \n",
|
||||
" \n",
|
||||
"1. Jakość składa się z tych cech produktu, które spełniają potrzeby klientów i dostarczają im satysfakcji. \n",
|
||||
"2. Jakość to brak braków.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Armanda Feigenbauma</h3> \n",
|
||||
" \n",
|
||||
"Jakość to coś, co określa tylko i wyłącznie klient - a nie inżynier, dział marketiingu, czy też kierownictwo.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Williama Edwardsa Deminga</h3> \n",
|
||||
" \n",
|
||||
"Cała trudność w zdefiniowaniu jakości polega na przełożeniu przyszłych potrzeb użytkownika na wymierne cechy w taki sposób, aby produkt dawał klientowi satysfakcję za akceptowalną cenę.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Definicja jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
" \n",
|
||||
"<b> Jakość oprogramowania </b> to funkcja wypadkowa wartości określonych właściwości oprogramowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Proces określania jakości oprogramowania\n",
|
||||
"Proces określenia jakości oprogramowania składa się z dwóch etapów:\n",
|
||||
"1. Zdefiniowanie funkcji jakości oprogramowania:\n",
|
||||
"\n",
|
||||
" > 1. Określ właściwości istotne dla danego typu oprogramowania (np. rozmiar, funkcjonalność, użyteczności, dostępność).\n",
|
||||
" > 2. Dla każdej włąsciwości zdefiniuj zakres wartości liczbowych lub kategorii, określających, w jakim stopniu spełnia ona oczekiwania użytkowników.\n",
|
||||
" > 3. Zdefiniuj jakość oprogramowania jako funkcję wartości poszczególnych właściwości: \n",
|
||||
" > **Quality = q(wartości właściwości)**\n",
|
||||
" \n",
|
||||
"2. Ocena jakości oprogramowania\n",
|
||||
" > 1. Wyznacz wartości poszczególnych cech oprogramowania.\n",
|
||||
" > 2. Oblicz jakość oprogramowania za pomocą zdefiniowanej funkcji *Quality*."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Jakość kodu źródłowego\n",
|
||||
"Cechy kodu żródłowego:\n",
|
||||
" * rozmiar,\n",
|
||||
" * złożoność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Metryki rozmiaru kodu źródłowego\n",
|
||||
"\n",
|
||||
"### 3.1.1. Liczba wierszy (LOC - Lines of Code)\n",
|
||||
"LOC mierzy **liczbę wierszy** w metodzie, klasie lub całej aplikacji.\n",
|
||||
"\n",
|
||||
"W obliczaniu LOC trzeba podjąć kilka nieoczywistych decyzji.\n",
|
||||
"\n",
|
||||
"Przykłady:\n",
|
||||
"\n",
|
||||
"<table>\n",
|
||||
"<tr> \n",
|
||||
" <td> Decyzja </td> <td> Rekomendacja </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> Czy liczyć puste wiersze?</td> <td> NIE </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> Czy liczyć komentarze?</td> <td> NIE </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> Czy liczyć liczbę wierszy czy liczbę instrukcji?</td> <td> Liczbę wierszy </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Reguła 30</h3> \n",
|
||||
" \n",
|
||||
"Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"> **Methods** should not have more than an average of 30 code lines (not counting line spaces and comments). \n",
|
||||
"> **A class** should contain an average of less than 30 methods, resulting in up to 900 lines of code. \n",
|
||||
"> **A package** shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines. \n",
|
||||
"> **Subsystems** with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code. \n",
|
||||
"> **A system** with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines. \n",
|
||||
"[Przeczytaj w Internecie](https://dzone.com/articles/rule-30-%E2%80%93-when-method-class-or)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1.2. Punkty funkcyjne\n",
|
||||
"\n",
|
||||
"**Punkty Funkcyjne** - metryka, która wyznacza liczbę funkcjonalności dostarczaną przez system.\n",
|
||||
"\n",
|
||||
"**Współczynnik produktywności języka programowania**: ile (średnio) linii kodu potrzeba do zakodowania jednego punktu funkcyjnego? \n",
|
||||
"\n",
|
||||
"Wartość kodu w punktach funkcyjnych wyznacza się, dzieląc wartośćLOC przez współczynnik produktywności.\n",
|
||||
"\n",
|
||||
"**Tablica produktywności języków programowania**\n",
|
||||
" <img src=\"obrazy/LOC vs FP.jpg\" alt=\"Tablica produktywności\" width=500px>\n",
|
||||
" źródło: Adam Roman, \"Testowanie i jakość oprogramowania\"\n",
|
||||
"\n",
|
||||
"[Porównaj w Internecie](https://www.qsm.com/resources/function-point-languages-table)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1.3. Liczba tokenów - metryka Halsteada\n",
|
||||
"\n",
|
||||
"Metryka Halsteada wyznacza objętość (wielkość) kodu na podstawie liczby unikatowych tokenów.\n",
|
||||
"Wyróżniane są dwa typy tokenów:\n",
|
||||
" * operatory (funkcje, słowa kluczowe itp.),\n",
|
||||
" * operandy (zmienne, stałe, wartości).\n",
|
||||
" \n",
|
||||
"Wartości metryk Halsteada (w przeciwieństwie do LOC) nie zależą od długości przyjętego nazewnictwa.\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/Halstead1.png\" alt=\"Liczby tokenów\" width=300px>\n",
|
||||
"źródło: Wikipedia\n",
|
||||
"\n",
|
||||
"Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/Halstead2.png\" alt=\"wielkość programu\" width=300px>\n",
|
||||
"źrodło: Wikipedia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Metryki oceny złożoności kodu źródłowego "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.1. Metryki złożoności Halsteada\n",
|
||||
"Złożoność programu szacowana jest pod kilkoma aspektami - na podstawie liczby tokenów:\n",
|
||||
" * D: trudność implementacji,\n",
|
||||
" * L: poziom programu (im wyższy tym program jest mniej podatny na błędy),\n",
|
||||
" * E: wysiłek implementacji,\n",
|
||||
" * T: czas implementacji\n",
|
||||
" * B: liczba błędów.\n",
|
||||
"<img src=\"obrazy/Halstead3.png\" alt=\"metryki złożoności Halsteada\" width=100px>\n",
|
||||
"żródło: Wikipedia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.2. Złożoność cyklomatyczna\n",
|
||||
"**Złożoność cyklomatyczna** określa liczbę niezależnych ścieżek przebiegu programu. \n",
|
||||
"\n",
|
||||
"Jeśli program reprezentowany jest w postaci schematu blokowego (grafu), to:\n",
|
||||
"\n",
|
||||
"> CC = e - n + 2 * p \n",
|
||||
"> e – liczba krawędzi grafu \n",
|
||||
"> n – liczba węzłów grafu \n",
|
||||
"> p – liczba składowych grafu \n",
|
||||
"\n",
|
||||
"Złożoność cykolmatyczną można łatwo wyliczyć na podstawie wzoru:\n",
|
||||
"\n",
|
||||
"> CC = d + 1, gdzie d oznacza liczbę węzłów decyzyjnych, np. instrukcji: \n",
|
||||
"> * if \n",
|
||||
"> * while \n",
|
||||
"> * for \n",
|
||||
"> * case"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.3. Uśrednione metody na klasę (Weighted Methods per Class - WMC)\n",
|
||||
"\n",
|
||||
"Metryka uwzględnia zarówno liczbę metod w klasie, jak i ich złożoność cyklomatyczną: (n oznacza liczbę metod w klasie, a c<sub>i</sub> oznacza złożoność cykolomatyczną i-tej metody).\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/WMC.png\" alt=\"Uśrednione metody na klasę \" width=200px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.4. Odpowiedzialność klasy (Response for a Class - RFC)\n",
|
||||
"\n",
|
||||
"Metryka RFC oznacza całkowitą liczbę metod, które mogą być potencjalnie wywołane w odpowiedzi na komunikat odebrany przez obiekt klasy. \n",
|
||||
"\n",
|
||||
"Wysoka wartość RFC oznacza większą funkcjonalność, ale zarazem i wyższą złożoność."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Właściwości produktu wpływające na ocenę jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Przydatność funkcjonalna (Functional Suitability - F)\n",
|
||||
"**Przydatność funkcjonalna** określa stopień, w jakim program dostarcza oczekiwane funkcjonalności.\n",
|
||||
"\n",
|
||||
"Wartość przydatności funkcjonalnej można wyznaczyć podczas testowania:\n",
|
||||
"\n",
|
||||
"> **M = 1 - A/B**\n",
|
||||
"> * A = funkcjonalności problemowe \n",
|
||||
"> * B = wszystkie testowane funkcjonalności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Niezawodność\n",
|
||||
"\n",
|
||||
"**Niezawodność** określa prawdopodobieństwo, że wykonanie operacji przez program będzie bezbłędne.\n",
|
||||
"\n",
|
||||
"Wartość niezawodności można wyznaczyć podczas testowania:\n",
|
||||
"\n",
|
||||
"> **M = A/B** \n",
|
||||
"> * A = liczba testów ukończonych pomyślnie, \n",
|
||||
"> * B = liczba wszystkich testów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.3. Użyteczność (Usability - U)\n",
|
||||
"\n",
|
||||
"**Użyteczność** określa łatwość użytkowania.\n",
|
||||
"\n",
|
||||
"Wartość użyteczności można wyznaczyć podczas testów użyteczności:\n",
|
||||
"\n",
|
||||
"> **M = A/B**\n",
|
||||
"> * A = liczba funkcjonalności odkryta przez użytkownika, \n",
|
||||
"> * B = liczba wszystkich funkcjonalości."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.4. Wydajność (Performance Efficiency)\n",
|
||||
"**Wydajność** określa liczbę wykonanych operacji w odniesieniu do czasu i zużytych zasobów.\n",
|
||||
"\n",
|
||||
"Przykładowe metryki pomiaru wydajności:\n",
|
||||
"\n",
|
||||
"> * Czas odpowiedzi: **M = T1 (end) - T2 (start)** \n",
|
||||
"> * Czas postoju: **M = T1 (waiting time) / T2 (total time)**\n",
|
||||
"> * Przepustowość = Liczba zadań wykonanych w jednostce czasu \n",
|
||||
"> * Zużycie pamięci (w bajtach) "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.5. Łatwość konserwacji (Maintainability - M)\n",
|
||||
"**Łatwość konserwacji** to łatwość, z jaką program jest utrzymywany w celu:\n",
|
||||
" * poprawiania błędów,\n",
|
||||
" * wprowadzania nowych funkcji.\n",
|
||||
"\n",
|
||||
"Przykładowa metryka: Ile czasu zajmuje średnio naprawienie błędu?\n",
|
||||
"\n",
|
||||
"> **M = SUM(czas naprawy) / N** \n",
|
||||
"> * N oznacza liczbę napraw"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.6. Przenośność (Portability - P)\n",
|
||||
"**Przenośność** to Łatwość przenoszenia systemu pomiędzy różnymi środowiskami platformami / systemami operacyjnymi. \n",
|
||||
"\n",
|
||||
"Przykładowe metryki:\n",
|
||||
" * łatwość adaptacji\n",
|
||||
" > **M = T** \n",
|
||||
" > * T oznacza czas adaptacji do nowego środowiska\n",
|
||||
"\n",
|
||||
" * łatwość instalacji: \n",
|
||||
" > **M = A / B**\n",
|
||||
" > * A = przypadki pomyślnej instalacji \n",
|
||||
" > * B = wszystkie przypadki instalacji "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.7. Dostępność (Availibility - A)\n",
|
||||
"**Dostępność** to czas, w którym program zobowiązany jest odpowiadać zgodnie z oczekiwaniami.\n",
|
||||
"\n",
|
||||
"* Metryka:\n",
|
||||
"\n",
|
||||
"> **M = A / B**\n",
|
||||
"> * A = Czas dostępności \n",
|
||||
"> * B = Czas całkowity \n",
|
||||
"\n",
|
||||
"* Przykładowe wartości metryki dostępności:\n",
|
||||
"\n",
|
||||
"<table>\n",
|
||||
"<tr> \n",
|
||||
" <td> Miara dostępności </td> <td> Czas niedostępności w roku </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,999 </td> <td> 5 minut 20 sekund </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,8</td> <td> 17 godzin 30 minut </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 97,5 </td> <td> 219 godzin </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.8. Kompatybilność (Compatibility)\n",
|
||||
"**Kompatybilność** to możliwość współpracowania z systemami zewnętrznymi."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.9. Bezpieczeństwo (Security - S)\n",
|
||||
"**Bezpieczeństwo** to możliwość chronienia danych przetwarzanych przez aplikację.\n",
|
||||
"\n",
|
||||
"* Przykładowa metryka:\n",
|
||||
"\n",
|
||||
"> **M = A / B** \n",
|
||||
"> * A = Liczba przetestowanych funkcji programu uznanych jako bezpieczne\n",
|
||||
"> * B = Liczba wszystkich przetestowanych funkcji "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Schematy oceny jakości\n",
|
||||
"\n",
|
||||
"Aby ocenić jakość oprogramowania należy wybrać właściwości oprogramowania, które wchodzą w skład oceny. Służą do tego **schematy oceny jakości**.\n",
|
||||
"\n",
|
||||
"## 5.1. CUMPRIMDSO (schamat wprowadzony przez IBM)\n",
|
||||
"* Capability (odpowiednik przydatności funkcjonalnej)\n",
|
||||
"* Usability (użyteczność)\n",
|
||||
"* Performance – wydajność\n",
|
||||
"* Reliability – niezawodność\n",
|
||||
"* Installability – łatwość instalacji\n",
|
||||
"* Maintainibility – łatwość utrzymania (pielęgnowalność)\n",
|
||||
"* Documentation – dokumentacja\n",
|
||||
"* Service – serwis\n",
|
||||
"* Overall - ocena ogólna\n",
|
||||
"\n",
|
||||
"## 5.2. CUMPRIMDA\n",
|
||||
"* Capability (odpowiednik przydatności funkcjonalnej)\n",
|
||||
"* Usability (użyteczność)\n",
|
||||
"* Performance – wydajność\n",
|
||||
"* Reliability – niezawodność\n",
|
||||
"* Installability – łatwość instalacji\n",
|
||||
"* Maintainibility – łatwość utrzymania (pielęgnowalność)\n",
|
||||
"* Documentation – dokumentacja\n",
|
||||
"* Availibility - dostępność\n",
|
||||
"\n",
|
||||
"## 5.3. FURPS (schemat wprowadzony przez Hewlett-Packard)\n",
|
||||
"* Functionality\n",
|
||||
"* Usability\n",
|
||||
"* Reliability\n",
|
||||
"* Performance\n",
|
||||
"* Supportability – łatwość wspierania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 6. Funkcja oceny jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.1. Pojęcie korelacji\n",
|
||||
"\n",
|
||||
"**Korelacja** to miara zależności pomiędzy dwoma zmiennymi (cechami).\n",
|
||||
"\n",
|
||||
"Korelacja przyjmuje wartości z przedziału [-1, 1]. \n",
|
||||
"* korealacja > 0 → korelacja dodatnia\n",
|
||||
" * gdy wartości jednej cechy rosną, to drugiej również rosną.\n",
|
||||
"* r < 0 → korelacja ujemna\n",
|
||||
" * gdy wartości jednej cechy rosną, to drugiej maleją i odwrotnie\n",
|
||||
"* r = 0 → korelacja zerowa\n",
|
||||
" * brak związku między cechami.\n",
|
||||
" \n",
|
||||
"Przykłady korelacji: \n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/korelacja.png\" alt=\"korelacja Pearsona\" width=600px>\n",
|
||||
"źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.2. Korelacja między właściwościami oprogramowania\n",
|
||||
"Korelację między poszczególnymi właściwościami oprogramowania obrazuje tabela:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/korelacja właściwości.png\" alt=\"Korelacja między właściwościomi oprogramowania\" width=600px>\n",
|
||||
"źródło: opracowanie własne na podstawie: Stephen H. Kan \"Metryki i modele w inżynierii jakości oprogramowania\"\n",
|
||||
"\n",
|
||||
"Tabela wskazuje, że polepszenie jednej cechy oprogramowania (np. przydatności funkcjonalnej) może pogorszyć inną cechę (np. wydajność), bo cechy te są ujemnie skorelowane."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.3. Waga właściwości oprogramowania\n",
|
||||
"Istotność poszczególnych właściwości oprogramowania zależy od typu programu.\n",
|
||||
"\n",
|
||||
"Stephen H. Kan (\"Metryki i modele w inżynierii jakości oprogramowania\") podaje, że dla metryki UPRIMDA najbardziej odpowiednie kolejności właściwości są następujące: \n",
|
||||
"* RUIPMDA\n",
|
||||
"* RUAIMPD"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.4. Wzór na ocenę jakości oprogramowania\n",
|
||||
"\n",
|
||||
"Procedura opracowania wzoru na ocenę jakości oprogramowania odpowiedniego dla danego typu programu:\n",
|
||||
"\n",
|
||||
"> 1. Wybierz schemat (np. FURPS) \n",
|
||||
"> \n",
|
||||
"> 2. Zdefiniuj typ funkcji (np. funkcja liniowa) \n",
|
||||
"> **Quality = a + b*F + c*U +d*R + e*P + f*S** \n",
|
||||
"> \n",
|
||||
"> 3. Zdefiniuj współczynniki tak, by korelacja z oceną ludzką była jak najwyższa."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przykładowy proces dostrajania współczynników jakości\n",
|
||||
"\n",
|
||||
"> 1. Zorganizuj grupę użytkowników (co najmniej 5 osób). \n",
|
||||
"> 2. Zbierz od użytkowników oceny poszczególnych właściwości oprogramowania. \n",
|
||||
"> 3. Zbierz od użytkowników oceny ogólne jakości. \n",
|
||||
"> 4. Określ heurystycznie wartości współczynników we wzorze na ocenę ogolną. \n",
|
||||
"> 5. Oblicz współczynnik korelacji między:\n",
|
||||
"> * ocenami ogólnymi jakości podanymi przez użytkowników, \n",
|
||||
"> * ocenami ogólnymi jakości wyznaczonymi przez wzór na oceną ogólną na podstawie ocen cząstkowych użytkownikow.\n",
|
||||
"> 6. Jeśli korelacja jest niska, to powróć do punktu 4."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
" * Istnieje wiele definicji jakości programowania.\n",
|
||||
" * Na wykładzie zdefiniowano jakość jako funkcję poszczególnych właściwości oprogramowania.\n",
|
||||
"\n",
|
||||
"* Istnieją metryki oceny **kodu źrodłowego**. \n",
|
||||
" * Na ich podstawie można ocenić jakość kodu.\n",
|
||||
" \n",
|
||||
" * Jakość oprogramowania można oceniać również z punktu widzenia klienta. \n",
|
||||
" * Stosowane są różne schematy oceny, które biorą pod uwagę różne właściwości oprogramowania.\n",
|
||||
" \n",
|
||||
" * Ocenę ogólną oprogramowania (z punktu widzenia klienta) można zdefiniować jako **funkcję liniową** ocen poszczególnych właściwości."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "12. Ocena jakości systemu informatycznego[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,733 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 13. <i>Planowanie prac badawczo-rozwojowych</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Harmonogram projektu</h3> \n",
|
||||
" \n",
|
||||
"Harmonogram projektu to plan uzyskania celów projektu uwzględniający:\n",
|
||||
"<ul>\n",
|
||||
" <li> podział pracy na etapy i zadania,</li>\n",
|
||||
" <li> przydział zasobów do zadań,</li>\n",
|
||||
" <li> terminy wykonania zadań.</li>\n",
|
||||
"</ul>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Zasady planowania harmonogramu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Bierz pod uwagę ograniczenia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Ograniczenia</h3> \n",
|
||||
" \n",
|
||||
"Ograniczenia to czynniki, które wpływają na realizację harmonogramu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Rodzaje ograniczeń:\n",
|
||||
"Wyróżniamy następujace typy ograniczeń:\n",
|
||||
" * Ograniczenia czasowe\n",
|
||||
" * Ograniczenia techniczne\n",
|
||||
" * Ograniczenia organizacyjne "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia czasowe\n",
|
||||
"**Ograniczenie czasowe** to ramy czasowe, w których musi się zmieścić projekt lub jego etap.\n",
|
||||
"\n",
|
||||
"* Rodzaje ograniczeń czasowych:\n",
|
||||
" * Nie wcześniej niż,\n",
|
||||
" * Nie później niż,\n",
|
||||
" * W konkretnym dniu.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń czasowych:\n",
|
||||
" * wykonanie pewnego zadania jest uwarunkowane ukończeniem innego zadania,\n",
|
||||
" * projekt ma być zakończony w określonym terminie.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczaniami czasowymi?\n",
|
||||
" * Ustawiać zależności między zadaniami (patrz ...),\n",
|
||||
" * Ustawiać hamronogram \"od końca\" (czyli od podania czasu zakończenia)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia techniczne\n",
|
||||
"**Ograniczenie techniczne** to ograniczenia wynikające z przyczyn zewnętrznych, niezależnych od zespołu projektowego.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń technicznych:\n",
|
||||
" * termin dostawy sprzętu,\n",
|
||||
" * załamanie pogody,\n",
|
||||
" * pandemia,\n",
|
||||
" * współpraca z podmiotami zewnętrznymi.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczeniami technicznymi?\n",
|
||||
"\n",
|
||||
" * Ustawiać zależność ZR (Zakończenie Rozpoczęcie) dla zadań zależnych od innych przedsiębiorstw (patrz ...),\n",
|
||||
" * Dodawać do zadań odstępy czasowe (patrz ...),\n",
|
||||
" * Dodawać rezerwę kierowniczą (patrz ...)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia organizacyjne\n",
|
||||
"**Ograniczenia organizacyjne** to ograniczenia wynikające z zależności pomiędzy kilkoma projektami realizowanymi:\n",
|
||||
" * w jednym zespole,\n",
|
||||
" * przez daną osobę, \n",
|
||||
" * z wykorzystaniem tych samych zasobów.\n",
|
||||
"\n",
|
||||
" * Wskazówki: ak radzić sobie z ograniczeniami organizacyjnymi?\n",
|
||||
" * Odpowiednio zarządzać zasobami: technicznymi i ludzkimi,\n",
|
||||
" * Współdzielić zasoby między projektami,\n",
|
||||
" * Ustawiać indywidualne czasy pracy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.2. Zarządzaj zapasem czasu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zapas czasu</h3> \n",
|
||||
" \n",
|
||||
"<b> Zapas czasu </b> to czas, o który może opóźnić się realizacja zadania, nie wpływając na termin ukończenia projektu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Ścieżka krytyczna</h3> \n",
|
||||
" \n",
|
||||
"<b> Ścieżka krytyczna </b> to sekwencja zadań od rozpoczęcia do zakończenia projektu, której czas przejścia jest najdłuższy.\n",
|
||||
"\n",
|
||||
"Zadania na ścieżce krytycznej mają zerowy zapas czasu.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ścieżka krytyczna.png\" alt=\"Przykład ścieżki krytycznej\" width=500px>\n",
|
||||
"<figcaption> Przykład ścieżki krytycznej </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Zarządzanie zapasem czasu** może polegać na:\n",
|
||||
" * dodawaniu zapasu czasu do zadań obarczonych ryzykiem,\n",
|
||||
" * dodawaniu zapasu czasu z powodów ograniczeń technicznych lub organizacyjnych, \n",
|
||||
" * zmniejszaniu zapasu czasu (dla zadań leżących poza ścieżką krytyczną),\n",
|
||||
" * analizie (i ew. modyfikacji) zadań leżących na ścieżce krytycznej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Zarządzaj rezerwą kierowniczą\n",
|
||||
"**Rezerwa kierownicza** to fikcyjne zadanie dodane na końcu siatki zadań. Czas na jego realizację to około 10-15% czasu całego projektu.\n",
|
||||
" * Rezerwę kierowniczą dodajemy po stworzeniu całości harmonogramu.\n",
|
||||
" * Tworząc rezerwę pomocniczą, pamiętaj o prawie Parkinsona."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Prawo Parkinsona</h3> \n",
|
||||
" \n",
|
||||
"Praca będzie się rozrastać, aby wypełnić cały czas na nią przewidziany.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/prawo Parkinsona.png\" alt=\"Prawo Parkinsona\" width=500px>\n",
|
||||
"<figcaption> Prawo Parkinsona, źródło: https://www.timeflies.us/blog/what-is-parkinson-s-law-and-how-it-can-make-you-more-productive</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Struktura podziału pracy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Struktura Podziału Pracy</h3> \n",
|
||||
" \n",
|
||||
"Struktura Podziału Pracy to hierarchiczna reprezentacja podziału pracy w projekcie.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Wykonanie prac w projekcie podzielone jest na **etapy**. \n",
|
||||
" * Etap jest częścią projektu, która musi być dokończona przed zaczęciem następnej. Etap składa się z **zadań**.\n",
|
||||
" * Zadania mogą być wykonywane równolegle.\n",
|
||||
" * Zadania mogą zostać podzielone na **podzadania**. \n",
|
||||
" \n",
|
||||
" * Elementy Struktury Podziału Pracy a efekty pracy: \n",
|
||||
" * Etap – efekt jest widoczny dla klienta,\n",
|
||||
" * Zadanie – efekt jest widoczny dla kierownika,\n",
|
||||
" * Podzadanie – efekt jest widoczny dla programisty.\n",
|
||||
" \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/SPP.jfif\" alt=\"Struktura Podziału Pracy\" width=600px>\n",
|
||||
"<figcaption> Struktura Podziału Pracy, źródło: http://pm2pm.pl/slownik-project-managera-wbs/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h3>Zasada 8 - 80</h3>\n",
|
||||
"Wykonanie najmniejszej jednostki harmonogramu powinno zajmować między 8 a 80 godzin.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Tworzenie harmonogramu w programie MS-Project"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Ustawienie daty początku projektu\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie daty.png\" alt=\"Ustawienie daty\" width=300px>\n",
|
||||
"<figcaption> Ustawienie daty początku projektu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Stworzenie Struktury Podziału Pracy\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/stworzenie SPP.png\" alt=\"Stworzenie SPP\" width=300px>\n",
|
||||
"<figcaption> Stworzenie SPP</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Ustawienie trybów zadań\n",
|
||||
"\n",
|
||||
"* Tryb ręczny (oznaczony przez pineskę) stosujemy, gdy chcemy mieć pełną kontrolę nad czasem trwania zadania.\n",
|
||||
"* Tryb automatyczny wykonuje ważną jednak pracę wspomagającą - przesuwa na osi czasu zadania, które są od siebie zależne.\n",
|
||||
"\n",
|
||||
"Stosowanie trybu automatycznego oznacza, że brana jest pod uwagę wskazówka: \"Bierz pod uwagę ograniczenia czasowe\". \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/tryby zadań.png\" alt=\"Ustawianie trybów zadań\" width=500px>\n",
|
||||
"<figcaption> Ustawianie trybów zadań</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.4. Określenie punktów kontrolnych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Punkt kontrolny</h3> \n",
|
||||
" \n",
|
||||
"<b>Punkt kontrolny</b> (ang. milestone) – punkt na osi czasu, który podsumowuje określony zestaw zadań, bądź daną fazę projektu.\n",
|
||||
"<ul>\n",
|
||||
" <li> Może to być: podpisanie dokumentu, otrzymanie wyniku, ważne spotkanie, zatwierdzenie pracy itp.\n",
|
||||
" <li> Zazwyczaj osiągnięcie punktu kontrolnego wiąże się z dalszymi decyzjami odnośnie rozwoju projektu.\n",
|
||||
" <li> Punkt kontrolny ma zerowy czas trwania.\n",
|
||||
" <li> Pojęcie punktu kontrolnego zastąpiło pojęcie kamienia milowego.\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie punktu kontrolnego.png\" alt=\"Ustawianie punktu kontrolnego\" width=900px>\n",
|
||||
"<figcaption> Ustawianie punktu kontrolnego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/punkt kontrolny.png\" alt=\"Punkt kontrolny w MS-Project\" width=500px>\n",
|
||||
"<figcaption> Oznaczenie punktu kontrolnego w MS-Project</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Określenie tygodniowego kalendarza czasu pracy dla zespołu\n",
|
||||
"\n",
|
||||
"Tygodniowy plan pracy dla zespołu obowiązuje tych członków zespołu, dla których nie określono planu indywidualnego. \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 1.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - przycisk</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 2.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - kalendarz</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.6. Modyfikacja diagramu Gantta"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Diagram Gantta</h3> \n",
|
||||
" \n",
|
||||
"<b> Diagram Gantta </b> to graficzny sposób reprezentacji harmonogramu, w którym uwzględnia się podział projektu na \n",
|
||||
"poszczególne zadania, oraz rozplanowanie ich w czasie.\n",
|
||||
"\n",
|
||||
"<br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/diagram Gantta.png\" alt=\"diagram Gantta\" width=500px>\n",
|
||||
"<figcaption> Przykładowy diagram Gantta, źródło: https://kierownikprojektu.com/2020/06/11/16-zalet-wykresu-gantta/ </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<h4> Zalety wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> przedstawia następstwo zdarzeń, </li>\n",
|
||||
"<li> uwzględnia zadania wykonywane równolegle, </li>\n",
|
||||
"<li> dobrze sprawdza się dla niewielkich projektów. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h4> Wady wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> nie zawiera szczegółowych opisów zadań, </li>\n",
|
||||
"<li> wymusza podanie konkretnych dat, </li>\n",
|
||||
"<li> nie pokazuje najkrótszej drogi do ukończenia prac. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Diagram Gantta w MS-Project\n",
|
||||
"\n",
|
||||
"Diagram Gantta tworzony jest częściowo manualne, a częściowo automatycznie.\n",
|
||||
"\n",
|
||||
" * Czas trwania zadania można wpisać ręcznie w kolumnie **czas trwania** (w godzinach, dniach).\n",
|
||||
" * W czasie trwania zadania uwzględniane są tylko dni robocze – zgodnie z kalendarzem.\n",
|
||||
" * Jeśli wpiszemy czasy rozpoczęcia i zakończenia, to czas trwania oblicza się sam. Analogicznie sam oblicza się koniec zadania o znanym rozpoczęciu i czasie trwania.\n",
|
||||
" * Dni wolne od pracy są zaznaczone kolorem szarym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Ustawienie zależności między zadaniami"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zależności między zadaniami</h3> \n",
|
||||
" \n",
|
||||
"Zadanie B jest <b>zależne</b> od A, gdy zmiana terminu wykonania A wpływa na termin wykonania B. Zadanie A nazywamy <b>poprzednikiem</b>, a B – <b>następnikiem </b>. \n",
|
||||
" \n",
|
||||
"<h4> Typy zależności </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> Zadania typu ZR (zakończenie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RR (rozpoczęcie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po rozpoczęciu poprzednika(A).\n",
|
||||
"<li> Zadania typu ZZ (zakończenie-zakończenie). Następnik (B) może się zakończyć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RZ (rozpoczęcie-zakończenie). Następnik (B) może się zakończyć dopiero po rozpoczęciu poprzednika (A).\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Ustawianie zależności między zadaniami w MS-Project\n",
|
||||
"\n",
|
||||
" * Aby określić zadania zależne, należy zaznaczyć dwa zadania i połączyć je (ikoną węzła).\n",
|
||||
" * Aby zmienić typ zależności między zadaniami, należy kliknąć na strzałeczkę łączącą zadania na wykresie Gantta.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zależności.png\" alt=\"Ustawianie zależności między zadaniami\" width=500px>\n",
|
||||
"<figcaption> Ustawianie zależności między zadaniami</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.8. Ustawienie odstępów między zadaniami\n",
|
||||
"Pomiędzy zadaniami zależnymi można ustawić odstęp czasowy (tzw. zwłokę). Pełni on rolę bufora – aby zapewnić zakończenie zadania przed rozpoczęciem następnego.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odstęp czasowy.png\" alt=\"Ustawianie odstępów czasowych\" width=500px>\n",
|
||||
"<figcaption> Ustawianie odstępów czasowych</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.9 Określenie zasobów w projekcie"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zasoby </h3> \n",
|
||||
" \n",
|
||||
"<b>Zasoby (ang. resources) </b> – wszystko, co jest potrzebne do wykonania projektu, a czego brak spowodowałby niewykonanie planu. \n",
|
||||
"W MS-Project wyróżniamy następujące typy zasobów:\n",
|
||||
"<ul>\n",
|
||||
"<li> Praca (ludzie lub komputery)\n",
|
||||
"<li> Materiał (np. energia)\n",
|
||||
"<li> Koszt (np. koszt podróży)\n",
|
||||
"</ul>\n",
|
||||
"</div> "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Zdefiniowanie zasobów w MS-Project\n",
|
||||
"\n",
|
||||
"Prawidłowe określenie wszystkich zasobów niezbędnych w projekcie umożliwia prawidłowe oszacowanie kosztów projektu.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 1.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=400px>\n",
|
||||
"<figcaption> Definiowanie zasobów - arkusz zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 2.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=800px>\n",
|
||||
"<figcaption> Definiowanie zasobów - dane zasobów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 10. Ustawienie tygodniowego kalendarza czasu pracy dla poszczególnych osób (zasobów)\n",
|
||||
"\n",
|
||||
"W programie MS-Project możliwe jest zindywidualizowanie czasu pracy każdej osoby - lub ogólniej - dowolnego zasobu. \n",
|
||||
"\n",
|
||||
"Wykres Gantta reprezentujący harmonogram pracy dostosowuje się do czasu pracy zasobów. Na przykład wykonanie zadania szacowanego na 16 godzin przez osobę, która pracuje 8 godzin w tygodniu, będzie zajmowało dwa tygodnie w harmonogramie.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu.png\" alt=\"Czas pracy zasobu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - wybranie zasobu</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu 2.png\" alt=\"Czas pracy zasobu 2\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - zmiana tygodniowego planu pracy</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 11. Przydzielenie zasobów do zadań\n",
|
||||
"Do kazego zadania powinny być przydzielone zasoby niezbędne do jego wykonania (w tym zasoby ludzkie). \n",
|
||||
"\n",
|
||||
" * Można przydzielić całość lub część zasobu do danego zadania (np. 50%). Będzie to oznaczało, że zasób jest zaangażowany w to zadanie tylko w określonym procencie swojego czasu.\n",
|
||||
" * Do jednego zadania można przydzielić kilka osób.\n",
|
||||
" * Zasób może być jednocześnie przypisany do kilku zadań.\n",
|
||||
" \n",
|
||||
" <br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przydzielanie zasobów.png\" alt=\"Przydzielanie zasobów do zadań\" width=500px>\n",
|
||||
"<figcaption> Przydzielanie zasobów do zadań</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 12. Sprawdzenie poprawności alokacji zasobów\n",
|
||||
"\n",
|
||||
"* Skoro zasób może być jednocześnie przypisany do kilku zadań, to można popełnić błąd, nadmiernie przeciążając zasób, tak że musiałby pracować więcej niż to wynika z jego kalendarza.\n",
|
||||
"\n",
|
||||
" * Obciążenie zasobów można sprawdzić następująco:\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 1.png\" alt=\"Sprawdzenie przeciążenia zasobów\" width=400px>\n",
|
||||
"<figcaption> Sprawdzenie przeciążenia zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 2.png\" alt=\"Zasoby z nadmierną alokacją pracy\" width=800px>\n",
|
||||
"<figcaption> Zasoby z nadmierną alokacją pracy - przykład</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 13. Wyeliminowanie przeciążeń zasobów\n",
|
||||
"\n",
|
||||
"Nadmierną alokację (przeciążenie) zasobów należy eliminować. Można to zrobić na dwa sposoby:\n",
|
||||
" * manualne odciążanie zasobów,\n",
|
||||
" * automatyczne bilansowanie zasobów.\n",
|
||||
" \n",
|
||||
"Manualne odciążanie zasobów może polegać na zmniejszeniu zaangażowania danego zasobu w zadanie:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odciążanie ręczne.png\" alt=\"Odciążanie ręczne\" width=500px>\n",
|
||||
"<figcaption> Zmniejszenie zaangażowania zasobu w zadanie</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Automatyczne bilansowanie zasobu wykonywane jest przez MS-Porject na żądanie użytkownika.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/automatyczne bilansowanie zasobów.png\" alt=\"automatyczne bilansowanie zasobów\" width=500px>\n",
|
||||
"<figcaption>Automatyczne bilansowanie zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Efekt bilansowania może spowodować przesunięcie pracy w czasie, a co za tym idzie, opóźnienie realizacji projektu:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 1.png\" alt=\"obciążenie zasobu przez bilansowaniem\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu przez bilansowaniem</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 2.png\" alt=\"obciążenie zasobu po bilansowaniu\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu po bilansowaniu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 14. Analiza ścieżki krytycznej\n",
|
||||
"\n",
|
||||
"Zadania leżące na ścieżce krytycznej nazywne są **zadaniami krytycznymi**.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zadania krytyczne.png\" alt=\"ścieżka krytyczna\" width=600px>\n",
|
||||
"<figcaption>Wyświetlenie ścieżki krytycznej </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"W wyniku analizy ścieżki krytycznej można przykładowo:\n",
|
||||
" * zmienić zależności między zadaniami na ścieżce krytycznej (może to przyspieszyć realizację planu)\n",
|
||||
" * zwiększyć zapasy czasu dla zadań krytycznych (zwiększając bezpieczeństwo kosztem czasu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 15. Generowanie raportów\n",
|
||||
"MS-Project umożliwia generowanie różnego typu raportów. Umożliwiają one m.in:\n",
|
||||
" * obliczenie kosztów projektu,\n",
|
||||
" * wyznaczenie, jaki procent planu jest wykonany,\n",
|
||||
" * obliczenie zaangażowania poszczególnych osób w projekt,\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport całościowy.png\" alt=\"raport całościowy\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu całościowego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport zasobów.png\" alt=\"raport zasobów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport kosztów.png\" alt=\"raport kosztów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu kosztów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 16. Poprawianie harmonogramu (czyli co robić, gdy harmonogram się „nie spina”)\n",
|
||||
"\n",
|
||||
"Następujące działania mogą pomóc w poprawieniu harmonogramu\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/modyfikacja planu.png\" alt=\"modyfikacja planu\" width=600px>\n",
|
||||
"<figcaption>Metody poprawiania harmonogramu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Wnioski\n",
|
||||
" * Zarządzanie projektem jest procesem zindywidualizowanym\n",
|
||||
" * Gdyby tak nie było, to MS Project składałby się tylko z jednego przycisku "
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "13. Planowanie prac badawczo-rozwojowych[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,87 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 14. Zarządzanie projektami badawczo-rozowjowymi</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Produkuj hamburgery, sprzedawaj hamburgery...\n",
|
||||
"## ... czyli czym różni się zarządzanie projektem B+R od kierowania barem szybkiej obsługi\n",
|
||||
"Różnice w zarządzaniu można zobrazować w kilku aspektach:\n",
|
||||
" * Podejście do popełniania błędów przez pracowników\n",
|
||||
" * Sposób motywowania: bodźce negatywne i pozytywne\n",
|
||||
" * Podejście do indywidualistów\n",
|
||||
" * Podejście do kreatywności i samodoskonalenia się pracowników"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Czy ludzie pracują lepiej pod presją?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Prawo Parkinsona - mit czy rzeczywistość?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 7 syrenich śpiewów...\n",
|
||||
"## ...czyli o pokusach w zarządzaniu, które prowadzą na manowce"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jakie czynniki faktycznie wpływają na lepszą pracę informatykó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": "14. Zarządzanie pracami badawczo-rozwojowymi[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,54 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 15. <i>Demonstracja wyników projektu badawczo-rozwojowego </i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"Demonstrowane projekty powinny być na 6. poziomie gotowości technologicznej.\n",
|
||||
"</div>"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "15. Demonstracja projektu[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,297 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Projekt badawczo-rozwojowy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"- 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",
|
||||
" - 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\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<img src=\"AI%20Seracher%20result.png\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Poziomy gotowości technologicznej projektu B+R\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żóny 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 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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Wyraz \"technologia\" pochodzi z języka greckiego:\n",
|
||||
"* techne: sztuka, umiejętność,\n",
|
||||
"* logia: nauka (czegoś) \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\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.\n",
|
||||
"\n"
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.7.6"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,114 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": 3,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": [
|
||||
"#procedura napisywania plików ipynb (generowanie nagłówka i metadanych)\n",
|
||||
"import json\n",
|
||||
"\n",
|
||||
"def modjup(filen,numer,tytul,typ,author,email,lang,title,year):\n",
|
||||
" zerocell=['\\n',\n",
|
||||
" '<div class=\"alert alert-block alert-info\">\\n', \n",
|
||||
" '<h1> %s </h1>\\n'%(title),\n",
|
||||
" '<h2> %s. <i>%s</i> [%s]</h2> \\n'%(numer,tytul,typ),\n",
|
||||
" '<h3> %s (%s)</h3>\\n'%(author,year),\n",
|
||||
" '</div>\\n',\n",
|
||||
" '\\n',\n",
|
||||
" '']\n",
|
||||
" zerodict={'cell_type': 'markdown','metadata': {'collapsed': False},'source': zerocell}\n",
|
||||
" with open(filen, 'r+') as f:\n",
|
||||
" ll=json.load(f)\n",
|
||||
" ll[\"metadata\"][\"author\"]=author\n",
|
||||
" ll[\"metadata\"][\"email\"]=email\n",
|
||||
" ll[\"metadata\"][\"lang\"]=lang\n",
|
||||
" subtitle=\"%s.%s[%s]\"%(numer,tytul,typ)\n",
|
||||
" ll[\"metadata\"][\"subtitle\"]=subtitle\n",
|
||||
" ll[\"metadata\"][\"title\"]=title\n",
|
||||
" ll[\"metadata\"][\"year\"]=year\n",
|
||||
" \n",
|
||||
" if not(ll['cells'][0]['source'][0]==zerocell[0]):\n",
|
||||
" ll['cells'].insert(0,zerodict)\n",
|
||||
" else:\n",
|
||||
" ll['cells'][0]=zerodict\n",
|
||||
" f.seek(0)\n",
|
||||
" json.dump(ll,f,indent=4)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": 5,
|
||||
"metadata": {},
|
||||
"outputs": [
|
||||
{
|
||||
"ename": "UnicodeDecodeError",
|
||||
"evalue": "'charmap' codec can't decode byte 0x81 in position 8350: character maps to <undefined>",
|
||||
"output_type": "error",
|
||||
"traceback": [
|
||||
"\u001b[1;31m---------------------------------------------------------------------------\u001b[0m",
|
||||
"\u001b[1;31mUnicodeDecodeError\u001b[0m Traceback (most recent call last)",
|
||||
"\u001b[1;32m<ipython-input-5-1005847c1bc8>\u001b[0m in \u001b[0;36m<module>\u001b[1;34m\u001b[0m\n\u001b[0;32m 13\u001b[0m \u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 14\u001b[0m \u001b[1;31m#uruchom procedurę\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[1;32m---> 15\u001b[1;33m \u001b[0mmodjup\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mfilen\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mnumer\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mtytul\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mtyp\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mauthor\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0memail\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mlang\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mtitle\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0myear\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m",
|
||||
"\u001b[1;32m<ipython-input-3-2ca9011d1935>\u001b[0m in \u001b[0;36mmodjup\u001b[1;34m(filen, numer, tytul, typ, author, email, lang, title, year)\u001b[0m\n\u001b[0;32m 13\u001b[0m \u001b[0mzerodict\u001b[0m\u001b[1;33m=\u001b[0m\u001b[1;33m{\u001b[0m\u001b[1;34m'cell_type'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[1;34m'markdown'\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;34m'metadata'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[1;33m{\u001b[0m\u001b[1;34m'collapsed'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[1;32mFalse\u001b[0m\u001b[1;33m}\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;34m'source'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[0mzerocell\u001b[0m\u001b[1;33m}\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 14\u001b[0m \u001b[1;32mwith\u001b[0m \u001b[0mopen\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mfilen\u001b[0m\u001b[1;33m,\u001b[0m \u001b[1;34m'r+'\u001b[0m\u001b[1;33m)\u001b[0m \u001b[1;32mas\u001b[0m \u001b[0mf\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[1;32m---> 15\u001b[1;33m \u001b[0mll\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mjson\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mload\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mf\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m\u001b[0;32m 16\u001b[0m \u001b[0mll\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"metadata\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"author\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mauthor\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 17\u001b[0m \u001b[0mll\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"metadata\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"email\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0memail\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n",
|
||||
"\u001b[1;32m~\\anaconda3\\lib\\json\\__init__.py\u001b[0m in \u001b[0;36mload\u001b[1;34m(fp, cls, object_hook, parse_float, parse_int, parse_constant, object_pairs_hook, **kw)\u001b[0m\n\u001b[0;32m 291\u001b[0m \u001b[0mkwarg\u001b[0m\u001b[1;33m;\u001b[0m \u001b[0motherwise\u001b[0m\u001b[0;31m \u001b[0m\u001b[0;31m`\u001b[0m\u001b[0;31m`\u001b[0m\u001b[0mJSONDecoder\u001b[0m\u001b[0;31m`\u001b[0m\u001b[0;31m`\u001b[0m \u001b[1;32mis\u001b[0m \u001b[0mused\u001b[0m\u001b[1;33m.\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 292\u001b[0m \"\"\"\n\u001b[1;32m--> 293\u001b[1;33m return loads(fp.read(),\n\u001b[0m\u001b[0;32m 294\u001b[0m \u001b[0mcls\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mcls\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0mobject_hook\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mobject_hook\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 295\u001b[0m \u001b[0mparse_float\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mparse_float\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0mparse_int\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mparse_int\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n",
|
||||
"\u001b[1;32m~\\anaconda3\\lib\\encodings\\cp1250.py\u001b[0m in \u001b[0;36mdecode\u001b[1;34m(self, input, final)\u001b[0m\n\u001b[0;32m 21\u001b[0m \u001b[1;32mclass\u001b[0m \u001b[0mIncrementalDecoder\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mcodecs\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mIncrementalDecoder\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 22\u001b[0m \u001b[1;32mdef\u001b[0m \u001b[0mdecode\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mself\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0minput\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0mfinal\u001b[0m\u001b[1;33m=\u001b[0m\u001b[1;32mFalse\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[1;32m---> 23\u001b[1;33m \u001b[1;32mreturn\u001b[0m \u001b[0mcodecs\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mcharmap_decode\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0minput\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mself\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0merrors\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mdecoding_table\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;36m0\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m\u001b[0;32m 24\u001b[0m \u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 25\u001b[0m \u001b[1;32mclass\u001b[0m \u001b[0mStreamWriter\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mCodec\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mcodecs\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mStreamWriter\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n",
|
||||
"\u001b[1;31mUnicodeDecodeError\u001b[0m: 'charmap' codec can't decode byte 0x81 in position 8350: character maps to <undefined>"
|
||||
]
|
||||
}
|
||||
],
|
||||
"source": [
|
||||
"#zmodyfikuj te dane\n",
|
||||
"filen=\"01_praca_zespolowa.ipynb\"\n",
|
||||
"\n",
|
||||
"numer=\"1\"\n",
|
||||
"tytul=\"\"\n",
|
||||
"typ=\"wyklad\"\n",
|
||||
"\n",
|
||||
"author=\"Krzysztof Jassem\"\n",
|
||||
"email=\"jassem@amu.edu.pl\"\n",
|
||||
"lang= \"pl\"\n",
|
||||
"title=\"Przygotowanie do projektu badawczo-rozwojowego\"\n",
|
||||
"year=\"2021\"\n",
|
||||
"\n",
|
||||
"#uruchom procedurę\n",
|
||||
"modjup(filen,numer,tytul,typ,author,email,lang,title,year)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.7.6"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,274 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 1. <i>Praca zespołowa</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Praca zespołowa w projekcie badawczo-rozwojowym\n",
|
||||
"## Cele wykładu\n",
|
||||
"1. Stworzenie zespołów projektowych\n",
|
||||
"2. Zapewnienie dobrej współpracy w zespołach\n",
|
||||
"3. Wybór liderów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Jak działa nasza pamięć?\n",
|
||||
"## Rodzaje pamięci\n",
|
||||
"### Pamięć sensoryczna\n",
|
||||
"Pamięć sensoryczna to inaczej pamięć zmysłów.\n",
|
||||
"#### Charaterystyka pamięci sensorycznej\n",
|
||||
"* krótki czas trwania (do ok. 0,5 s),\n",
|
||||
"* duża pojemność (ok. 99% nadchodzących informacji),\n",
|
||||
"* powiązanie ze zmysłami (węch, wzrok, dotych, słuch, smak)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\"> \n",
|
||||
"<h2>Przykład</h2>\n",
|
||||
" \n",
|
||||
"Dźwięk słyszymy przez pewien czas (min. 0,5 sek. - nawet gdy trwa krócej)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Interakcje pamięci sensorycznej\n",
|
||||
"Informacje z pamięci sensorycznej przekazywane są do pamięci krótkotrwałej.\n",
|
||||
"\n",
|
||||
"### Pamięć krótkotrwała\n",
|
||||
"Przechowuje niewielkie ilości informacji przez krótki okres (bez dokonywania powtórek: kilka do kilkunastu sekund).\n",
|
||||
"\n",
|
||||
"#### Interakcje pamięci krótkotrwałej\n",
|
||||
"Pobiera informacje z pamięci sensorycznej, z pamięci krótkotrwałej oraz z pamięci długotrwałej.\n",
|
||||
"Przekazuje informacje do pamięci krótkotrwałej i długotrwałej.\n",
|
||||
"\n",
|
||||
"#### Liczba Millera\n",
|
||||
"Jest to liczba ustalona przez George'a Millera (1920 - 2012), amerykańskiego psychologa, uważanego za twórzę psychologii poznawczej, w roku 1956 na podstawie badań psychologicznych nad zapamiętywaniem informacji. Liczba ta waha się w zależności od rodzaju informacji do zapamiętania (dźwięk, smak, obraz, liczba), ale zawsze jest to około 7 (±2).\n",
|
||||
"\n",
|
||||
"##### Wnioski w pracy zespołowej\n",
|
||||
"* Nie warto zasypywać kolegi z zespołu nadmiarem informacji zo zapamiętania (bo i tak nie zapamięta).\n",
|
||||
"* Pozycje do zapamiętania lepiej jest podzielić na kategorie, (między 5-9). \n",
|
||||
"* Można dokonać kolejnego podziału pozycji na podkategorie. Takich podziałów można dokonać wgłąb do poziomu 7 :)\n",
|
||||
"\n",
|
||||
"### Pamięć długotrwała\n",
|
||||
"* W pamięci długotrwałej tworzony jest wynik przetwarzania informacji - trwały ślad pamięciowy. \n",
|
||||
"* Pamięć długotrwała zawiera całą naszą wiedzę na temat świata, wszystkie wspomnienia i umiejętności. \n",
|
||||
"* Jest to pamięć o największej pojemności i najdłuższym czasie przechowywania informacji.\n",
|
||||
"\n",
|
||||
"#### Interakcje pamięci długotrwałej\n",
|
||||
"* Pobiera informacje z pamięci krótkotrwałej.\n",
|
||||
"* Przekazuje informacje do pamięci krótkotrwałej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Motywacja do pracy\n",
|
||||
">Motywowanie do pracy to proces świadomego i celowego oddziaływania na pracowników poprzez dostarczanie środków i możliwości spełnienia ich oczekiwań w taki sposób, aby obie strony (pracodawca i pracownik) odniosły korzyści (Encyklopedia zarządzania)\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Piramida potrzeb Maslova</h2>\n",
|
||||
" <ol>\n",
|
||||
" <li>Potrzeby fizjologiczne (najniższy rząd potrzeb) </li>\n",
|
||||
"<li>Potrzeby bezpieczeństwa</li>\n",
|
||||
"<li>Potrzeby przynależności</li>\n",
|
||||
"<li>Potrzeby uznania</li>\n",
|
||||
"<li>Potrzeby samorealizacji</li>\n",
|
||||
" </ol>\n",
|
||||
"\n",
|
||||
"<h2>Teoria Maslova</h2>\n",
|
||||
" <ul>\n",
|
||||
"<li>Motywacja to chęć zaspokojenie potrzeby najsilniej odczuwanej.</li>\n",
|
||||
"<li>Zaspokojenie potrzeby wyższego rzędu może nastąpić nie wcześniej niż po zaspokojeniu potrzeby niższego rzędu.</li>\n",
|
||||
" </ul>\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Typy pracowników\n",
|
||||
"W rzeczywistości po zaspokojeniu potrzeb najniższych kolejność potrzeb wyższego rzędu zależy od osobowości pracownika. Pracownicy różnią się bowiem w aspektach motywacji do pracy (co motywuje najbardziej) i podejścia do pracy (sposób realizacji pracy).\n",
|
||||
"\n",
|
||||
"### Typy pracowników pod względem motywacji\n",
|
||||
"A. Pracownik nastawiony na wykonanie zadania \n",
|
||||
"B. Pracownik nastawiony na siebie (własny rozwój; satysfakcję) \n",
|
||||
"C. Pracownik nastawiony na interakcję (komunikację w grupie)\n",
|
||||
"\n",
|
||||
"### Typy pracowników pod względem podejścia do pracy\n",
|
||||
"1. Posuwający pracę do przodu\n",
|
||||
"2. Wybitny technik; specjalista w dziedzinie\n",
|
||||
"3. Uznający priorytet komunikacji, współpracy między wykonawcami projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Zespół projektowy\n",
|
||||
"> Zespół projektowy to niewielka liczba ludzi posiadających komplementarne umiejętności, zaangażowanych w realizację wspólnego celu ogólnego oraz celów cząstkowych, których podejście opiera się na współodpowiedzialności” (J.Katzenach, D.Smith 2001, Siła zespołów. Wpływ pracy zespołowej na efektywność organizacji\", s. 26).\n",
|
||||
"\n",
|
||||
"Na skuteczność pracy w zespole mają wpływ 4 główne czynniki:\n",
|
||||
"* Skład zespołu\n",
|
||||
"* Spójność grupy\n",
|
||||
"* Komunikacja w zespole\n",
|
||||
"* Organizacja zespołu\n",
|
||||
"\n",
|
||||
"## Skład zespołu\n",
|
||||
"### Członkowie zespołu\n",
|
||||
"Grupa powinna zawierać uzupełniające się osobowości:\n",
|
||||
"* ludzi mających własne pomysły - wybitnych techników (B2)\n",
|
||||
"* ludzi nastawionych na komunikację z innymi (C3)\n",
|
||||
"* ludzi nastawionych na posuwanie pracy do przodu (A1) \n",
|
||||
"\n",
|
||||
"### Lider zespołu\n",
|
||||
"* Lider odgrywa najważniejszą rolę w zespole.\n",
|
||||
"* Liderzy z reguły są mianowani i odpowiadają przed menedżerem przedsięwzięcia.\n",
|
||||
"* Liderzy muszą codziennie śledzić pracę swojej grupy i blisko współpracować z menedżerami przedsięwzięcia.\n",
|
||||
"* Lider musi być akceptowany przez zespół.\n",
|
||||
"\n",
|
||||
"## Spójność grupy\n",
|
||||
"Grupa spójna (inaczej: zgrana) to grupa, w której:\n",
|
||||
"* członkowie mają wspólne cele,\n",
|
||||
"* nie występują kliki (podgrupy).\n",
|
||||
"\n",
|
||||
"### Zalety grupy spójnej\n",
|
||||
"* Można wypracować grupowy standard jakości.\n",
|
||||
"* Bliska współpraca – członkowie uczą się od siebie nawzajem.\n",
|
||||
"* Członkowie grupy znają nawzajem swoje prace. Opuszczenie grupy przez jej członka nie powoduje utracenie ciągłości pracy.\n",
|
||||
"* Programowanie jest pozbawione indywidualizmu (program uważany jest za własność grupy).\n",
|
||||
"\n",
|
||||
"### Wady grupy spójnej\n",
|
||||
"* Nieracjonalny opór przed zmianą lidera;\n",
|
||||
"* Myślenie grupowe – krytyczne umiejętności członków grupy osłabione są przez lojalność wobec grupy.\n",
|
||||
"\n",
|
||||
"## Komunikacja w zespole\n",
|
||||
"Proces skutecznej komunikacji to przekazywanie informacji w sposób powodujący realizację celów. \n",
|
||||
"Skutkiem efektywnej komunikacji jest zwiększenie motywacji do pracy oraz zmniejszenie oporu wobec zmian. \n",
|
||||
"\n",
|
||||
"### Zasady skutecznej komunikacji\n",
|
||||
"* Dostosowanie klarowności wypowiedzi do odbiorcy\n",
|
||||
"* Dostosowanie *metod komunikacji* do zespołu\n",
|
||||
"\n",
|
||||
"### Metody komunikacji\n",
|
||||
"* Pionowa lub pozioma\n",
|
||||
"* Jednostronna lub dwustronna\n",
|
||||
"* Werbalna lub pisemna\n",
|
||||
"* Formalna lub nieformalna\n",
|
||||
"\n",
|
||||
"## Organizacja zespołu\n",
|
||||
"Organizacja zespołu to hierarchia ról przypisanych członkom zespołu.\n",
|
||||
"\n",
|
||||
"### Rodzaje organizacji zespołu\n",
|
||||
"#### Organizacja formalna (hierachiczna)\n",
|
||||
"Formalna, hierarchiczna organizacja zespołu jest niezbędna w przypadku pracowników niedoświadczonych.\n",
|
||||
"\n",
|
||||
"#### Organizacja nieformalna\n",
|
||||
"Organizacja nieformalna sprawdza się, gdy większość członków to ludzie doświadczeni i kompetentni.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Lider zespołu\n",
|
||||
"Lider zespołu to w ogólności osoba zarządzająca członkami zespołu w celu realizacji celów powierzonego projektu. \n",
|
||||
"W prezentowanym NA TYM WYKŁADZIE podejściu lider to osoba zapewniająca motywację do pracy członkom zespołu.\n",
|
||||
"\n",
|
||||
"## Typy lidera (wg Daniela Goldmana)\n",
|
||||
"\n",
|
||||
"> Daniel Goleman (ur. 7 marca 1946 w Stockton) – amerykański psycholog żydowskiego pochodzenia, publicysta naukowy. Autor bestselleru Inteligencja emocjonalna (1995). (Wikipedia)\n",
|
||||
"\n",
|
||||
"### Wizjoner: \"Chodź ze mną\"\n",
|
||||
"* Pokazuje kierunek działania.\n",
|
||||
"* Motywuje do osiągania wspólnych celów.\n",
|
||||
"* Pozwala ludziom samodzielnie poszukiwać nowych rozwiązań.\n",
|
||||
"* Przyciąga ludzi do siebie, docenia i promuje rolę poszczególnych osób w zespole.\n",
|
||||
"\n",
|
||||
"### Trener: \"Rozwijaj się\"\n",
|
||||
"* Motywuje ludzi do lepszej pracy poprzez rozpoznawanie ich mocnych i słabych stron.\n",
|
||||
"* Zachęca ludzi, aby walczyli z przeciwnościami i rozwijali się.\n",
|
||||
"* Zachęca, by korzystali ze swoich mocnych, pozytywnych cech i czerpali z nich napęd do pracy.\n",
|
||||
"\n",
|
||||
"### Lider afiliacyjny: \"Porozmawiajmy\"\n",
|
||||
"* Szanuje każdą osobę pracującą w organizacji.\n",
|
||||
"* „Ludzie to nie roboty” – odczuwają radość i zmęczenie.\n",
|
||||
"* Szczerze interesuje się życiem swoich pracowników.\n",
|
||||
"* Dba o dobrą atmosferę pracy.\n",
|
||||
"* Posiada wysoką empatię, czyli umiejętność odczytywania uczuć i dostrzegania punktu widzenia innych osób.\n",
|
||||
"\n",
|
||||
"### Demokrata: \"Każdy głos jest ważny\"\n",
|
||||
"* Liczy się zdanie każdego pracownika.\n",
|
||||
"* Potrafi słuchać ludzi i wykorzystywać ich pomysły.\n",
|
||||
"* Potrafi przyjmować również krytykę.\n",
|
||||
"* Pracownicy mają poczucie, że uczestniczą w decyzjach podejmowanych w firmie, przez co bardziej angażują się w pracę.\n",
|
||||
"\n",
|
||||
"### Poganiacz: \"Zrób to natychmiast\"\n",
|
||||
"* Ustawia wysokie standardy pracy zarówno dla siebie jak i dla swoich pracowników\n",
|
||||
"* Jest bardzo mocno nastawiony na sukces, koncentruje się na nieustannym poprawianiu wyników. \n",
|
||||
"* Jego popularne powiedzenie to: „rób to, co ja – natychmiast!”.\n",
|
||||
"\n",
|
||||
"### Dyktator: \"Rób, co każę\"\n",
|
||||
"* Nazywany „zarządzaniem przez strach”.\n",
|
||||
"* Polega na ciągłym kontrolowaniu pracowników, wydawaniu im poleceń i oczekiwaniu, że zostaną one wypełnione dokładnie tak, jak wymaga tego przywódca. \n",
|
||||
"* To on podejmuje decyzje, a polecenia wydaje w sposób zdecydowany, stanowczy i nie znoszący sprzeciwu.\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": "01. Praca zespołowa[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,311 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 2. <i>Projekt badawczo-rozwojowy</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"- 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",
|
||||
" - 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",
|
||||
"<img src=\"obrazy/AISearcher.png\" alt=\"Zrzut ekranu systemu AISearcher\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Poziomy gotowości technologicznej projektu B+R\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 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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Wyraz \"technologia\" pochodzi z języka greckiego:\n",
|
||||
" <ul>\n",
|
||||
" <li>techne: sztuka, umiejętność</li>\n",
|
||||
" <li>logia: nauka (czegoś)</li>\n",
|
||||
" </ul>\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.8.5"
|
||||
},
|
||||
"subtitle": "02. Projekt badawczo-rozwojowy[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,418 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 3. <i>Prezentacja koncepcji projektu B+R</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<p>DLA (określenie klienta docelowego)</p> \n",
|
||||
"<p>KTÓRY (ma potrzebę)</p>\n",
|
||||
"<p>NAZWA NASZEGO PRODUKTU (PRZEDSIĘWZIĘCIA)</p>\n",
|
||||
"<p>TO (typ produktu / przedsięwzięcia)</p> \n",
|
||||
"<p>KTÓRY (ma unikalną cechę)</p> \n",
|
||||
"<p>W PRZECIWIEŃSTWIE (nazwa znanej konkurencji)</p>\n",
|
||||
"<p>MA PRZEWAGĘ (typ przewagi)</p>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Przykład jednozdaniowego \"elevator pitch\"</h3>\n",
|
||||
" \n",
|
||||
"<p>(DLA) Dla każdej osoby biorącej leki lub suplementy,</p>\n",
|
||||
"<p>(KTÓRA) zwłaszcza dla tych którzy mają tendencje zapominać.</p> \n",
|
||||
"<p>(NAZWA PRODUKTU) Take Your Meds</p>\n",
|
||||
"<p>(TO) to aplikacja mobilna,</p>\n",
|
||||
"<p>(KTÓRA) która zapewni, że bez pomyłek weźmiemy wszystkie leki.</p>\n",
|
||||
"<p>(W PRZECIWIEŃSTWIE) w przeciwieństwie do standardowych powiadomień na telefonie i notatek na kartce,</p>\n",
|
||||
"<p>(MA PRZEWAGĘ) Take Your Meds zapewnia szczegółowe informacje i nie pozwala się pomylić.</p>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówki</h4>\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
" \n",
|
||||
"<li>Nie bądź gadatliwy!</li>\n",
|
||||
"<li>Uchwyć uwagę widza!</li>\n",
|
||||
"<li>Jeśli tutaj nie chwycisz widza za gardło, to przepadłeś.</li>\n",
|
||||
" \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówka:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
" <li> Pamiętaj: nie chodzi o Twój problem, tylko o problem potencjalnego użytkownika! </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówki:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
" <li> Bądź konkretny!</li> \n",
|
||||
" <li> Nie zalewaj! </li> \n",
|
||||
" <li> Nie czaruj!</li> \n",
|
||||
" </ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4> Wskazówki: </h4>\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Przekonaj, że Wasze rozwiązanie jest\n",
|
||||
" <ul>\n",
|
||||
"<li> użyteczne,\n",
|
||||
"<li> funkcjonalne\n",
|
||||
" </ul>\n",
|
||||
"<li> Najlepiej przedstaw działanie wizulanie - np. na schemacie, rysunku, filmie.\n",
|
||||
" </ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4>Wskazówki:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
"<li> Ponownie możesz przedstawić schemat... </li> \n",
|
||||
"<li> Ale uważaj, żeby nie przesadzić ze szczegółami technicznymi!</li> \n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### 6. Przedstaw konkurencję\n",
|
||||
" * Jakie produkty / firmy są Waszą konkurencją?\n",
|
||||
" * Co robią inaczej?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4> Wskazówka: </h4>\n",
|
||||
" \n",
|
||||
"Wykaż, że jesteście lepsi:\n",
|
||||
"<ul>\n",
|
||||
"<li>jakość,</li>\n",
|
||||
"<li>cena,</li>\n",
|
||||
"<li>funkcjonalność,</li>\n",
|
||||
"<li>użyteczność,</li>\n",
|
||||
"<li>elastyczność.</li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h4> Wskazówki:</h4>\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
" <li>Możecie interpretować powyższe pojęcia w sposób potoczny: </li>\n",
|
||||
"<ul>\n",
|
||||
" <li>TAM - Jak duży jest cały tort?</li>\n",
|
||||
" <li>SAM - Jak duży kawałek tortu jestem w stanie uciąć dla siebie?</li>\n",
|
||||
" <li>TM - Ile jestem w stanie zjeść?</li>\n",
|
||||
"</ul>\n",
|
||||
"<li>Inwestor oczekuje, że potraficie oszacować wartość każdego zasięgu rynku na podstawie wiarygodnych źródeł.</li>\n",
|
||||
" </ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h4> Wskazówka: </h4>\n",
|
||||
"\n",
|
||||
"Wyjaśnij swój pomysł na sprzedaż, np.\n",
|
||||
"<ul>\n",
|
||||
"<li>licencje / sprzedaż jednorazowa,</li>\n",
|
||||
"<li>sprzedaż bezpośrednia / dystrybutorzy,</li>\n",
|
||||
"<li>dochody z reklam,</li>\n",
|
||||
"<li>mechanizmy przyciągnięcia klienta, np. programy lojalnościowe, grywalizacja.</li>\n",
|
||||
" </ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h4> Wskazówki: </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li>Udowodnij, że znasz realia lub...dostosuj się do oczekiwań inwestora. </li>\n",
|
||||
"<li>Kiedyś prognozę układało się na 5 lat, a dzisiaj... 5 lat to dłużej niż wieczność. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h4>Wskazówki:</h4>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
"<li> Można pokazać zdjęcia, jeśli ludzie się na to zgadzają. </li>\n",
|
||||
" <li> Jeśli w zespole jest gwiazda, pozwól jej lśnić. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "03. Prezentacja koncepcji projektu B+R[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,622 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 5. <i>Metodyki adaptacyjne w programowaniu</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Metodyki adaptacyjne w programowaniu (Agile Software Development)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"\n",
|
||||
"<b> Agile </b> (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Nic dobrego nie wynika <BR>\n",
|
||||
"Bez udziału użytkownika.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"2. Agile Development Teams Must Be Empowered."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Nie warta praca mozołu, <BR>\n",
|
||||
"Gdy władza nie w rękach zespołu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"3. Time waits for no man."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Czas płynie wartko jak rzeka, <BR>\n",
|
||||
"I na nikogo nie czeka.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"4. Agile Requirements Are Barely Sufficient."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Dosłownie w kilku dziś zdaniach <BR>\n",
|
||||
"Streścimy swe wymagania.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"5. How do you eat an elephant? One bite at a time."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Sekretów uchylam wieczko: <BR>\n",
|
||||
"Jedz słonia małą łyżeczką.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"6. Fast but not so furious."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Byli szybcy, lecz nie wściekli, <BR>\n",
|
||||
"I na czas produkt dowlekli.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"7. Done Means DONE!"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"Praca była \"wykonana\", <BR>\n",
|
||||
"I działało... aż do rana.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"8. Enough is enough."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Projekt ciągle się rozrasta, <BR>\n",
|
||||
"Trzeba krzyknąć: \"Stop i Basta!\"\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"9. Agile Testing Is Not For Dummies."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Wiedz, by dobrze móc testować, <BR>\n",
|
||||
"Twa głowa ma być pomysłowa.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"10. No place for snipers."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Choć mocno znów cierpi Twe ego, <BR>\n",
|
||||
"Nie strzelaj - do siebie samego.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<b>Scrum</b> jest metodyką, w której kluczowym elementem jest <b>Sprint</b> - 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",
|
||||
"</div>\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": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Rejestr Produktu (Product Backlog)</h5>\n",
|
||||
"\n",
|
||||
"<b> Rejestr Produktu </b> to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Rejestr produktu utrzymywany jest przez Właściciela Produktu.</li>\n",
|
||||
" <li> Zadania, których efekt widoczny jest dla użytkownika mają często postać <b> User Story </b>.</li>\n",
|
||||
" <li> Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu.</li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>User Story </h5>\n",
|
||||
"\n",
|
||||
"> <b> User story </b> 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 <Kto?> chcę wykonać<Co?> aby<Dlaczego?>\n",
|
||||
"\n",
|
||||
"<h6> Przykład User Story </h6>\n",
|
||||
" \n",
|
||||
"> Jako <b> klient sklepu </b> chcę <b> dodać produkt do koszyka </b> aby go później <b> kupić </b>.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Rejestr Sprintu (Sprint Backlog)</h5>\n",
|
||||
"\n",
|
||||
"<b> Rejestr Sprintu </b> to lista <b>Zadań</b> do wykonania podczas Sprintu:\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> utrzymywana przez Zespół Deweloperski,</li>\n",
|
||||
" <li> tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Zadanie (Task)</h5>\n",
|
||||
"\n",
|
||||
"<b> Zadanie </b> w Rejestrze Sprintu zawiera następujące informacje:\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> opis zadania,</li>\n",
|
||||
" <li> szacowany czas wykonania zadania, </li>\n",
|
||||
" <li> członek zespołu odpowiedzialnego za wykonanie zadania, </li>\n",
|
||||
" <li> status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Role w metodyce Scrum"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Udziałowcy (stakeholders)</h5>\n",
|
||||
"Udziałowcy to ludzie, którzy finansują projekt:\n",
|
||||
"<ol>\n",
|
||||
" <li> właściciele firmy realizującej projekt,</li>\n",
|
||||
" <li> klienci, </li>\n",
|
||||
" <li> przyszli użytkownicy.</li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h5>Właściciel Produktu (Product Owner)</h5>\n",
|
||||
"\n",
|
||||
"<b> Właściciel Produktu </b> to rola, która reprezentuje interesy biznesu.\n",
|
||||
"\n",
|
||||
"<h6> Zadania Właściciela Produktu: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> nadzoruje pisanie <b> User Stories</b>,</li>\n",
|
||||
" <li> analizuje na bieżąco potrzeby biznesu i na tej podstawie...</li>\n",
|
||||
" <li> ustala priorytet User Stories w <b>Rejestrze Produktu</b>,</li>\n",
|
||||
" <li> decyduje, co jest WYKONANE. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h5>Zespół Deweloperski (Development Team)</h5>\n",
|
||||
" \n",
|
||||
"<b>Zespół Deweloperski </b> to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.\n",
|
||||
" \n",
|
||||
"<h6> Zadania Zespołu Deweloperskiego: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> jest odpowiedzialny za implementację, </li>\n",
|
||||
" <li> na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint, </li>\n",
|
||||
" <li> wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu),</li>\n",
|
||||
" <li> sam decyduje o sposobie realizacji zadań. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h5> Scrum Master </h5>\n",
|
||||
"\n",
|
||||
"Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.\n",
|
||||
"\n",
|
||||
"<h6> Zadania Scrum Mastera: </h6>\n",
|
||||
"<ol>\n",
|
||||
" <li> prowadzi <b>Daily </b> (spotkanie zespołu), </li>\n",
|
||||
" <li> prowadzi <b> Retrospektywę</b>, </li>\n",
|
||||
" <li> buduje relacje w zespole, </li>\n",
|
||||
" <li> pomaga rozwiązywać konflikty, </li>\n",
|
||||
" <li> pośredniczy w rozmowach z Właścicielem produktu. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Cykl pracy w metodyce Scrum"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Sprint </h5> \n",
|
||||
"\n",
|
||||
"<b> Sprint </b> 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",
|
||||
"<ol>\n",
|
||||
" <li> Planowanie Sprintu, </li>\n",
|
||||
" <li> Implementacja, </li>\n",
|
||||
" <li> Codzienne spotkania, </li>\n",
|
||||
" <li> Przegląd Sprintu, </li>\n",
|
||||
" <li> Retrospektywa. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Planowanie Sprintu (Sprint Planning) </h5> \n",
|
||||
"\n",
|
||||
"<b> Planowanie sprintu </b> jest pierwszym spotkaniem podczas każdego sprintu. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu. </li> \n",
|
||||
"<li> Planowanie Sprintu prowadzone jest przez Scrum Mastera. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h6> Standardowy przebieg Planowania Sprintu: </h6> \n",
|
||||
"<ol>\n",
|
||||
" <li> Analizy Rejestru Produktu - wybór wymagań do realizacji, </li>\n",
|
||||
" <li> Określenie celu sprintu - na podstawie wybranych wymagań, </li>\n",
|
||||
" <li> Określenie pełnego zakresu prac: jak będzie działał system po Sprincie, </li>\n",
|
||||
" <li> Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań, </li>\n",
|
||||
" <li> Estymacja pracochłonności zadań. </li>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Codzienne Spotkania (Daily Scrum) </h5> \n",
|
||||
"\n",
|
||||
"<b> Codzienne Spotkanie </b> (stosowana nazwa w j. polskim - <b> Daily </b>) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Daily bierze udział Zespół Deweloperski. </li> \n",
|
||||
"<li> Daily prowadzone jest przez Scrum Mastera. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Daily: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Przegląd prac w ciągu ostatniego dnia, </li>\n",
|
||||
" <li> Omówienie pojawiających się problemów, </li>\n",
|
||||
" <li> Omówienie planu na kolejny dzień. </li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Przegląd Sprintu </h5> \n",
|
||||
"\n",
|
||||
"<b> Przegląd Sprintu </b> jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu. </li> \n",
|
||||
"<li> Przegląd Sprintu prowadzony jest przez Właściciela Produktu. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Przeglądu Sprintu: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały \"Wykonane”, a które nie. </li>\n",
|
||||
" <li> Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano. </li>\n",
|
||||
" <li> Zespół Deweloperski prezentuje \"Wykonaną” pracę; dyskusja. </li>\n",
|
||||
" <li> Właściciel Produktu omawia obecny Rejestr Produktu. </li>\n",
|
||||
" <li> Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.\n",
|
||||
" <li> Właściciel produktu aktualizuje Rejestr Produktu.\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h5> Retrospektywa Sprintu</h5> \n",
|
||||
"\n",
|
||||
"<b> Retrospektywa Sprintu </b> to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> W Retrospektywie udział bierze Zespół Deweloperski. </li> \n",
|
||||
"<li> Retrospektywę prowadzi Scrum Master. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<h6> Standardowy plan Retrospektywy: </h6>\n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
" <li> Sprawdzenie, co działo się w ostatnim Sprincie, </li>\n",
|
||||
" <li> Zidentyfikowanie elementów, które sprawdziły się w działaniu, </li>\n",
|
||||
" <li> Zidentyfikowanie elementów, które kwalifikują się do usprawnienia,</li>\n",
|
||||
" <li> Stworzenie planu wprowadzania w życie usprawnień. </li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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.8.5"
|
||||
},
|
||||
"subtitle": "05. Metodologia Prince2Agile[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,462 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 6. <i>Prototypowanie i ciągła integracja</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Prototyp </h2> \n",
|
||||
"Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Prototyp papierowy </h2> \n",
|
||||
" \n",
|
||||
"<b>Prototyp papierowy</b> 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",
|
||||
"<b>Prototypowanie papierowe - etapy </b>:\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności. </li>\n",
|
||||
"<li> Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Makieta statyczna </h2> \n",
|
||||
" \n",
|
||||
" \n",
|
||||
"<b>Makieta statyczna</b> to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
" <li> Obrazuje wybrane widoki bez połączeń między nimi. </li>\n",
|
||||
"</ul> \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Makieta dynamiczna </h2> \n",
|
||||
" \n",
|
||||
" \n",
|
||||
"<b>Makieta dynamiczna</b> to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li> Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku. </li>\n",
|
||||
"</ul> \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Graficzny interfejs użytkownika (GUI) </h2> \n",
|
||||
"\n",
|
||||
"<b> Graficzny interfejs użytkownika </b> to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n",
|
||||
" \n",
|
||||
"Prototypem poziomym nazwiemy GUI, który: \n",
|
||||
"<ul>\n",
|
||||
"<li> Pokazuje menu. </li>\n",
|
||||
"<li> Pozwala na nawigację. </li>\n",
|
||||
"<li> Akceptuje input. </li>\n",
|
||||
"<li> Wyświetla losowy output. </li>\n",
|
||||
"<li> NIE wspiera logiki aplikacji. </li>\n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Ciągła integracja </h2> \n",
|
||||
" \n",
|
||||
"Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
|
||||
"<ul>\n",
|
||||
" <li> zmiany w kodzie są regularnie przesyłane do centralnego repozytorium, </li>\n",
|
||||
" <li> po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h2>Główne przesłanki CI </h2> \n",
|
||||
" \n",
|
||||
"Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
|
||||
"<ul>\n",
|
||||
" <li> szybsze lokalizowanie błędów w kodzie, </li>\n",
|
||||
" <li> ciągły wzrost jakości oporgramowania, </li>\n",
|
||||
" <li> szybkie wydawanie nowych wersji. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "06. Prototypowanie i ciągła integracja[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,479 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 7. <i>Specyfikacja projektu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Zakres systemu informatycznego</h3>\n",
|
||||
" \n",
|
||||
"Zakres systemu to obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co leży poza projektem (np. jest zadaniem projektowym kogoś innego).\n",
|
||||
"\n",
|
||||
"Zakres <b> funkcjonalny </b>– zestaw usług oferowanych przez system.\n",
|
||||
"\n",
|
||||
"Zakres <b> projektowy </b>– zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Jak zdefiniować zakres projektu?\n",
|
||||
"\n",
|
||||
"Zakres projektu jest stopniowo uściślany za pomocą następującyh działań:\n",
|
||||
"\n",
|
||||
"1. Określenie ogólnego zakresu projektu, a w nim:\n",
|
||||
"\n",
|
||||
" * Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu\n",
|
||||
" * Charakterystyka wykonawców\n",
|
||||
" * Lista „wykonawca-cel”\n",
|
||||
" * Lista „in-out”\n",
|
||||
"\n",
|
||||
"2. Specyfikacja wymagań\n",
|
||||
" * Wymagania funkcjonalne\n",
|
||||
" * Wymaganie niefunkcjonalne\n",
|
||||
" \n",
|
||||
"3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Określenie ogólnego zakresu projektu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Uczestnicy i wykonawcy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Uczestnik</h3>\n",
|
||||
" \n",
|
||||
"Uczestnik – ktoś lub coś, mający interes związany z zachowaniem systemu.\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"Uczestnik może być osobą, firmą lub przedsiębiorstwem, programem komputerowym lub systemem komputerowym.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Wykonawca</h3>\n",
|
||||
" \n",
|
||||
"<b> Wykonawca </b> to Uczestnik, który kontaktuje się z systemem.\n",
|
||||
"\n",
|
||||
"<b> Wykonawca główny </b> to Wykonawca, który kontaktuje się z systemem w celu uzyskania jednej z jego usług. Wykonawca główny najczęściej rozpoczyna przypadek użycia. \n",
|
||||
"\n",
|
||||
"<b> Wykonawca pomocniczy </b> to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"Uczestnik ma interesy. \n",
|
||||
"Wykonawca ma zachowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Charakterystyka wykonawców\n",
|
||||
"Charakterystykę wykonawców można opisać za pomocą tabeli. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawcy.png\" alt=\"Lista Wykonawców\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista Wykonawca-Cel\n",
|
||||
"Na podstawie charakterystyki wykonawców oraz zakresu systemu tworzy się listę **Wykonawca - Cel**, w której dla każdego typu wykonawców określa się cele, jakie wykonawca stawia przed systemem. \n",
|
||||
"\n",
|
||||
"Jeśli projektowany system dotyczy interesów uczestników niebędących wykonawcami, pożądane może być sporządzenie szerszej listy: **Uczestnik – Cel**. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wykonawca-cel.png\" alt=\"Lista wykonawca-cel\" width=600px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Lista In-Out\n",
|
||||
"Na podstawie listy Wykonawca-Cel, biorąc pod uwagę priorytety celów, tworzy się listę In-Out, która precyzyjnie określa zakres systemu. \n",
|
||||
"\n",
|
||||
"Przykład tabeli dla systemu Cybertest2:\n",
|
||||
"<img src=\"obrazy/in-out.png\" alt=\"Lista In-Out\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Specyfikacja wymagań"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Specyfikacja wymagań</h3>\n",
|
||||
" \n",
|
||||
"Specyfikacja wymagań to dokument, w którym zebrano wszystkie oczekiwania stawiane przyszłemu systemowi (np. wymagania funkcjonalne i niefunkcjonalne aplikacji).\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymagania użytkownika\n",
|
||||
"**Wymagania użytkownika** to ogólny opis oczekiwań względem systemu w języku naturalnym, będacy rezultatem wstępnych rozmów wykonawcy z zamawiającym lub użytkownikiem.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * menedżerów zamwiającego.\n",
|
||||
" * menedżerów wykonawcy,\n",
|
||||
" * potencjalnych użytkowników systemu.\n",
|
||||
" \n",
|
||||
"Przykład wymagań użytkownika (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymagania użytkownika.png\" alt=\"Przykład wymagań użytkownika\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Wymaganie systemowe\n",
|
||||
"**Wymagania systemowe** to sformalizowany opis oczekiwań względem systemu.\n",
|
||||
" * Skierowane są do:\n",
|
||||
" * inżynierów zamawiającego,\n",
|
||||
" * twórców oprogramowania, \n",
|
||||
" * architektów systemu. \n",
|
||||
" \n",
|
||||
"Wymagania systemowe dzielą się na:\n",
|
||||
" * funkcjonalne,\n",
|
||||
" * niefunkcjonalne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania funkcjonalne\n",
|
||||
" * Opisują funkcje (czynności, operacje) wykonywane przez system.\n",
|
||||
" * Dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem.\n",
|
||||
" \n",
|
||||
"Przykłady wymagań funkcjonalnych (system do prowadzenia testów na wykładzie):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne1.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymaganie funkcjonalne2.png\" alt=\"Przykład wymagania funkcjonalnego\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Wymagania niefunkcjonalne\n",
|
||||
" * Opisują warunki, przy których system musi realizować swoje funkcje:\n",
|
||||
" * Wymagania dotyczące produktu\n",
|
||||
" * Wymagania dotyczące procesu\n",
|
||||
" * Wymagania zewnętrzne\n",
|
||||
" * Wymagania niefunkcjonalne powinny być weryfikowalne. Realizowane jest to przy pomocy systemu miar opisujących wymagane cechy systemu.\n",
|
||||
"\n",
|
||||
"Przykłady miar wymagań niefunkcjonalnych:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/miary.png\" alt=\"Przykłady miar wymagań niefunkcjonalnych\" width=600px>\n",
|
||||
"\n",
|
||||
"Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wymagania niefunkcjonalne.png\" alt=\"Przykład wymagań niefunkcjonalnych\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Opis przypadków użycia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Przypadek użycia (PU) </h3>\n",
|
||||
" \n",
|
||||
"Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n",
|
||||
"\n",
|
||||
"<ul>\n",
|
||||
"<li>Przypadek użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie wykonawcy głównego.\n",
|
||||
" <li>Przypadek użycia reprezentowany jest przez sekwencję <b> akcji </b> realizowanych przez system, które dają zauważalny efekt; Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 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. Warunki początkowe\n",
|
||||
"4. Wyzwalacz\n",
|
||||
"5. Gwarancje minimalne\n",
|
||||
"6. Gwarancja powodzenia\n",
|
||||
"7. Scenariusz powodzenia\n",
|
||||
"8. Rozszerzenia scenariusza"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1. Przypadek użycia. Poziom celu\n",
|
||||
"Poziom celu określa stopień ogólności przypadku użycia:\n",
|
||||
" * Poziom streszczenia – najbardziej ogólny,\n",
|
||||
" * Poziom użytkownika – pośredni,\n",
|
||||
" * Poziom podfunkcji – najbardziej szczegółowy.\n",
|
||||
" \n",
|
||||
"#### Poziom streszczenia\n",
|
||||
"Przypadki użycia o poziomie streszczenia pokazują kontekst, w którym występują przypadki użycia niższego poziomu:\n",
|
||||
" * Pokazują kolejność działania przypadków użycia niższego poziomu,\n",
|
||||
" * Stanowią spis treści przypadków użycia niższego poziomu (użytkownika).\n",
|
||||
" \n",
|
||||
"Przykład przypadku użycia o poziomie streszczenia (podkreśleniem oznaczone są przypadki niższego poziomu):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom streszczenia.png\" alt=\"Przykład przypadku użycia o poziomie streszczenia\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom użytkownika\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",
|
||||
"Przykład przypadku użycia o poziomie użytkownika:\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziom użytkownika.png\" alt=\"Przykład przypadku użycia o poziomie użytkownika\" width=400px>\n",
|
||||
"\n",
|
||||
"#### Poziom podfunkcji\n",
|
||||
"Przypadki użycia o poziomie podfunkcji opisują podcele, które są potrzebne do osiągnięcia celów użytkownika.\n",
|
||||
" * Uwzględniane są w opisie przypadków tylko w sytuacjach absolutnie niezbędnych („nie musisz – nie pisz”).\n",
|
||||
" * Trzy przykłady przypadków użycia o poziomie podfunkcji:\n",
|
||||
" > Wybierz odpowiedź na pytanie testowe. \n",
|
||||
" > Przejdź do następnego pytania. \n",
|
||||
" > Zaloguj się w systemie. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Przypadek użycia. Warunki początkowe\n",
|
||||
"**Warumek początkowy** to proste stwierdzenie o stanie świata w chwili otwarcia przypadku użycia. \n",
|
||||
" * Warunek początkowy może być wyrażony za pomocą przypadków użycia, które musiały zajść przed otwarciem opisywanego przypadku. \n",
|
||||
" * Warunek początkowy określa, co musi być zapewnione przed zezwoleniem na przypadek użycia. \n",
|
||||
" \n",
|
||||
" Przykład warunku początkowego (system do testów):\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/warunek początkowy.png\" alt=\"Przykład warunku początkowego\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Przypadek użycia. Wyzwalacz\n",
|
||||
"**Wyzwalacz** to zdarzenie, które automatycznie powoduje rozpoczęcie przypadku użycia.\n",
|
||||
"\n",
|
||||
" Przykłady wyzwalaczy (system do testów):\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/wyzwalacze.png\" alt=\"Przykłady wyzwalaczy\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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 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",
|
||||
" <img src=\"obrazy/gwarancje minimalne.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Przypadek użycia. Gwarancja powodzenia\n",
|
||||
"**Gwarancja powodzenia** ustala, jakie interesy uczestników są zaspokojone po udanym zakończeniu przypadku użycia (scenariusz powodzenia).\n",
|
||||
" * Zapisywana jest w postaci prostych stwierdzeń, opisujących świat po udanym zakończeniu przypadku użycia.\n",
|
||||
" * Często ma postać rozszerzenia minimalnych gwarancji.\n",
|
||||
" \n",
|
||||
"Przykłady gwarancji powodzenia:\n",
|
||||
"\n",
|
||||
" <img src=\"obrazy/gwarancja powodzenia.png\" alt=\"Przykłady gwarancji minimalnych\" width=300px>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"\n",
|
||||
"**Wskazówki przy pisaniu scenariusza powodzenia:**\n",
|
||||
"\n",
|
||||
"#### 1. Używaj prostych składni zdań\n",
|
||||
"<img src=\"obrazy/prosta składnia.png\" alt=\"Przykład prostej składni\" width=300px>\n",
|
||||
"\n",
|
||||
"#### 2. Jasno i jednoznacznie wskaż podmiot czynności\n",
|
||||
"<img src=\"obrazy/podmiot.png\" alt=\"Przykład podmiotu czynności\" width=300px>\n",
|
||||
"\n",
|
||||
"#### 3. Pisz \"z lotu ptaka\"\n",
|
||||
"<img src=\"obrazy/lot ptaka.png\" alt=\"Przykład z lotu ptaka\" width=300px>\n",
|
||||
"\n",
|
||||
"#### 4. Przesuwaj proces wyraźnie do przodu\n",
|
||||
"<img src=\"obrazy/proces.png\" alt=\"Przykład przesuwania procesu\" width=300px>\n",
|
||||
"\n",
|
||||
"#### 5. Stwierdzaj \"że\", a nie - sprawdzaj \"czy\"\n",
|
||||
"<img src=\"obrazy/że.png\" alt=\"Przykład stwierdzania że\" width=300px>\n",
|
||||
"\n",
|
||||
"#### 6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz\n",
|
||||
"<img src=\"obrazy/odwołania.png\" alt=\"Przykłady odwołania\" width=300px>\n",
|
||||
"\n",
|
||||
"#### 7. Stosuj iteracje, jeśli jest taka potrzeba\n",
|
||||
"<img src=\"obrazy/iteracje.png\" alt=\"Przykłady iteracji\" width=300px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Przypadek użycia. Rozszerzenia scenariusza\n",
|
||||
"**Rozszerzenie scenariusza** to niestandardowe zachowanie systemu, które\n",
|
||||
" * zaczyna się w konkretnym kroku w scenariuszu powodzenia,\n",
|
||||
" * gdy zdarzają się niestandardowe sytuacje – zwane **warunkami rozszerzenia scenariusza**.\n",
|
||||
" \n",
|
||||
"#### Warunki rozszerzenia scenariusza\n",
|
||||
"**Warunki rozszerzenie scenariusza** to sytuacje, w których system zachowuje się inaczej, niż to przewidziano w scenariuszu powodzenia.\n",
|
||||
"* Warunki rozszerzenia sformułowane są z punktu widzenia systemu (co system może wykryć, a nie - co się stało).\n",
|
||||
"<img src=\"obrazy/warunki rozszerzenia.png\" alt=\"Przykłady warunku rozszerzenia\" width=300px>\n",
|
||||
"\n",
|
||||
"##### Jak znajdować potencjalne rozszerzenia scenariusza?\n",
|
||||
" * Przemyśl alternatywne ścieżki scenariusza, np.\n",
|
||||
" * Wykonawca głóny postępuje niepoprawnie\n",
|
||||
" * Brak działania wykonawcy głównego\n",
|
||||
" * Wykonawca pomocniczy reaguje z opóźnieniem\n",
|
||||
" * Przeanalizuj wszystkie wystąpienia wyrażeń typu „System stwierdza, że...”\n",
|
||||
" * Przeanalizuj sytuacje awaryjne\n",
|
||||
" * Awarie wewnętrzne projektowanego systemu, które należy wykryć i obsłużyć\n",
|
||||
" * Awarie wewnętrzne systemu, które wystarczy wykryć"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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 „Wwykonawca-Cel” \n",
|
||||
" 4. Lista „In-Out” \n",
|
||||
" 5. Wymagania funkcjonalne \n",
|
||||
" 6. Wymaganie niefunkcjonalne \n",
|
||||
" 7. Opis przypadków użycia "
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "07. Specyfikacja projektu informatycznego[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,474 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 8. <i>Testowanie w programowaniu zwinnym</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. Przykłady katastrof spowodowanych złym testowaniem"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Start sondy kosmicznej Mariner-1 (1962) </h3>\n",
|
||||
"<a href=\"https://plwiki.pl/Leksykon/Mariner_1\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Start sondy kosmicznej Mariner-1 (1962) </h3>\n",
|
||||
"<a href=\"https://plwiki.pl/Leksykon/Mariner_1\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Maszyna do radioterapii Therac-25 (1985-1987) </h3>\n",
|
||||
"<a href=\"https://ucgosu.pl/2018/09/therac-25-czyli-blad-w-sofcie-medycznym-powodujacy-smierc-pacjentow/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Zestrzelenie Airbusa 290 (1988) </h3>\n",
|
||||
"<a href=\"https://www.msn.com/pl-pl/wiadomosci/historia/jak-w-1988-roku-zestrzelono-ira%C5%84ski-samolot-pasa%C5%BCerski/ar-BBYPtLv?li=BBr5MK7\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Awaria sieci AT T (1990) </h3>\n",
|
||||
"<a href=\"https://www.computerworld.pl/news/Najgorsze-skutki-bledow-programistow,369992.html\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Błąd systemu obrony przeciwrakietowej Patriot (1992) </h3>\n",
|
||||
"<a href=\"https://www.konflikty.pl/technika-wojskowa/na-ladzie/patriot-dhahran-co-sie-stalo/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Awaria rakiety Ariane-5 (1996) </h3>\n",
|
||||
"<a href=\"https://ucgosu.pl/2018/09/ariane-5-int-overflow-ktory-wysadzil-w-powietrze-rakiete/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Błąd konwersji w sondzie Mars Climate Orbiter (1999) </h3>\n",
|
||||
"<a href=\"https://ichi.pro/pl/blad-konwersji-wynoszacy-328-milionow-dolarow-271395322355666\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"\n",
|
||||
"<h3> Awaria systemu PEKA (2014) </h3>\n",
|
||||
"<a href=\"https://www.fakt.pl/wydarzenia/polska/poznan/awaria-systemu-peka-w-poznaniu-awaria-kart-peka/9d1pbb1\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Podstawowe pojęcia testowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Błąd (error)</h3>\n",
|
||||
" \n",
|
||||
"<b>Błąd</b> to objaw nieoczekiwanego działania programu ujawniony podczas testów.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Defekt (fault)</h3>\n",
|
||||
" \n",
|
||||
"<b>Defekt</b> to niedoskonałość w kodzie programu. \n",
|
||||
"\n",
|
||||
"<i>Błąd</i> ujawniony w czasie testów świadczy o <i>defekcie</i> w testowanym kodzie.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie</h3>\n",
|
||||
" \n",
|
||||
"<b>Testowanie </b> to proces, który ma na celu <b><i>wykazanie</i></b> istnienia defektów w kodzie programu poprzez wywołanie błędów w działaniu.\n",
|
||||
" \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Usuwanie defektów</h3>\n",
|
||||
" \n",
|
||||
"<b>Usuwanie defektów </b> to proces lokalizacji i poprawiania defektów.\n",
|
||||
"\n",
|
||||
"Procesy testowania i usuwania defektów często przeplatają się w pętlach iteracyjnych:\n",
|
||||
"<ol>\n",
|
||||
"<li>Wywołaj błąd (testowanie)</li>\n",
|
||||
"<li>Zlokalizuj defekt (usuwanie defektów)</li>\n",
|
||||
"<li>Zaprojektuj naprawę defektu (usuwanie defektów)</li>\n",
|
||||
"<li>Napraw defekt (usuwanie defektów)</li>\n",
|
||||
"<li>Wróć do 1.</li>\n",
|
||||
"</ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testy bialej skrzynki</h3>\n",
|
||||
" \n",
|
||||
"<b>Testy białej skrzynki</b> zakładają wgląd w wewnętrzną strukturę (kod) programu – na tej podstawie tworzone są przypadki testowe.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testy czarnej skrzynki</h3>\n",
|
||||
" \n",
|
||||
"W <b> testach czarnej skrzynki</b> program traktowany jest jak czarna skrzynka, której zawartość pozostaje nieznana; \n",
|
||||
"<ul>\n",
|
||||
"<li>Przypadki testowe tworzone są bez znajomości kodu.\n",
|
||||
"<li>Celem testowania jest wykrycie sytuacji, w których dane wejściowe przekształcane są na wyniki niezgodnie z oczekiwaniami.\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h3>Zasady testowania</h3>\n",
|
||||
" \n",
|
||||
"<ol>\n",
|
||||
"<li> Programiści nie testują swoich programów (poza tworzeniem testów jednostkowych).\n",
|
||||
"<li> Firma nie testuje swoich produktów (a dokładniej: niezbędne jest testowanie zewnętrzne)\n",
|
||||
"<li> Przypadki testowe muszą być zapisane. Nie należy tworzyć przypadków ulotnych.\n",
|
||||
"<li> Testowanie jest czynnością kreatywną.\n",
|
||||
"</ol>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3. Przypadki testowe"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Przypadek testowy</h3>\n",
|
||||
" \n",
|
||||
"<b>Przypadek testowy</b> to eksperyment przeprowadzany w testowaniu, który można opisać w kategoriach:\n",
|
||||
"<ul>\n",
|
||||
"<li> wartości wprowadzanych danych, \n",
|
||||
"<li> akcji wykonywanej przez użytkownika\n",
|
||||
"<li> oczekiwanych wyników. \n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"Przypadki testowe służą do <b>ograniczenia</b> przestrzeni sytuacji, które należy sprawdzić, aby wywołać błąd programu. \n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Jak tworzyć przypadki testowe?\n",
|
||||
"\n",
|
||||
" * Analiza klas równoważności:\n",
|
||||
" * Klasa równoważności – wszystkie możliwe wartości danych wejściowych przetwarzanych w ten sam sposób. \n",
|
||||
" * Jeden przypadek testowy reprezentuje jedną klasę równoważności. \n",
|
||||
"\n",
|
||||
"**Przykład**: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić klas równoważności?\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/klasy równoważności.png\" alt=\"Klasy równoważności przypadków testowych\" width=400px>\n",
|
||||
"\n",
|
||||
" * Analiza wartości brzegowych\n",
|
||||
" * Metoda zakłada, że błędy mogą być spowodowane nieprzewidzianym zachowaniem programu w okolicach wartości brzegowych.\n",
|
||||
" * Jeden przypadek testowy odpowiada jednej wartości brzegowej.\n",
|
||||
"\n",
|
||||
"**Przykład**: Testowany komponent systemu operuje na parze danych, z których pierwszy element oznacza godzinę, a drugi minutę. Ile można wyróżnić przypadków testowych metodą analizy wartości brzegowych? \n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/wartości brzegowe.png\" alt=\"Analiza wartości brzegowych\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Jak opisywać przypadki testowe?\n",
|
||||
"\n",
|
||||
" * W metodzie białej skrzynki – za pomocą testów jednostkowych, stosując metodę analizy wartości brzegowych lub klas równoważności\n",
|
||||
" * W metodzie czarnej skrzynki – w postaci:\n",
|
||||
" * Prostej instrukcji do testera\n",
|
||||
" * Scenariusza przypadku testowego\n",
|
||||
" \n",
|
||||
"**Przykład opisu przypadków testowych z prostą instrukcją:**\n",
|
||||
"<img src=\"obrazy/przypadki testowe.png\" alt=\"Opis przypadków testowych\" width=900px>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"**Przykład opisu przypadku testowego ze scenariuszem:**\n",
|
||||
"<img src=\"obrazy/przypadek testowy ze scenariuszem.png\" alt=\"Opis przypadku testowego ze scenariuszem\" width=900px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4. Poziomy testowania\n",
|
||||
"\n",
|
||||
"* Znalezienie defektu jest tym trudniejsze, im dłuższa droga dzieli miejsce defektu od miejsca ujawnienia błędu.\n",
|
||||
"\n",
|
||||
"* Każdemu etapowi wytwarzania oprogramowania odpowiada określony poziom testowania.\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/poziomy testowania.gif\" alt=\"Poziomy testowania\" width=600px>\n",
|
||||
"(źródło: https://edux.pjwstk.edu.pl/mat/200/lec/wyklady/11_3.html)\n",
|
||||
"\n",
|
||||
"* Zarządzanie poziomami testowania ma na celu skrócenie drogi od spowodowania defektu do wykrycia błędu.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Poziomy testowania w Scrumie\n",
|
||||
"\n",
|
||||
"* W programowaniu tradycyjnym testowanie odbywa się sekwencyjnie.\n",
|
||||
"\n",
|
||||
"* W Scrumie testowanie na wszystkich poziomach odbywa się równolegle (codziennie lub co przyrost).\n",
|
||||
"\n",
|
||||
"* Wnioski:\n",
|
||||
"\n",
|
||||
" * 1: Każdy zespół powinien zawierać osobę, która zajmuje się testowaniem „na pełen etat”.\n",
|
||||
" * 2: W każdym sprincie powinno odbyć się testowanie na każdym poziomie.\n",
|
||||
" * 3: W każdym kolejnym sprincie pojawiają się nowe przypadki testowe, ale wszystkie „stare” pozostają.\n",
|
||||
"\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5. Testowanie jednostkowe\n",
|
||||
"### Zasady testowania jednostkowego\n",
|
||||
"\n",
|
||||
" 1. Przedmiotem testowania są podstawowe jednostki programu.\n",
|
||||
" 2. Testy jednostkowe tworzone są przez dewelopera - programistę.\n",
|
||||
" 3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First.\n",
|
||||
" 4. Test jednostkowy powinien testować jednostkę w izolacji. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.1. Przedmiotem testowania są podstawowe jednostki programu\n",
|
||||
" * Every method needs to be tested.”\n",
|
||||
" * W praktyce testowane są tylko metody publiczne…\n",
|
||||
" * …Co oznacza, że testy metod publicznych muszą być tak dokładne, by testowały WSZYSTKIE wywoływane przez nie metody prywatne…\n",
|
||||
" * …Co również oznacza, że defekty w metodach prywatnych ujawnione zostaną dopiero w testach dla metod publicznych.\n",
|
||||
" * „Keep test logic out of production code”\n",
|
||||
" * Nie wprowadzaj testów jednostkowych do kodu produkcyjnego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.2. Testy jednostkowe tworzone są przez programistę\n",
|
||||
" \n",
|
||||
"<img src=\"obrazy/testy jednostkowe.png\" alt=\"Testy jednostkowe\" width=800px>\n",
|
||||
"(rysunek na podstawie: Tilo Linz, \"Testing in Scrum\")"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.3. W testowaniu jednostkowym (jak i w całym procesie Scrum) polecana strategia to Test First\n",
|
||||
"#### Zasady strategii Test First \n",
|
||||
" * Zanim napiszesz linijkę kodu, napisz test automatyczny, który się nie powodzi.\n",
|
||||
" * Pisz kod tak długo, aż powiodą się wszystkie testy.\n",
|
||||
"#### Zalety strategii TestFirst\n",
|
||||
" * Testowanie zastępuje metodę prób i błędów.\n",
|
||||
" * Realizacja przypadków testowych jest obiektywną miarą postępów w pracy.\n",
|
||||
" * Przypadki testowe zastępują formalną specyfikację.\n",
|
||||
" * „Test first” wprowadza porządek w interfejsach między klasami.\n",
|
||||
" * „Test first” świetnie wpisuje się w Scrum."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 5.4. Test jednostkowy powinien testować wyłącznie jednostkę (w izolacji)\n",
|
||||
" * Każdy obiekt testowany jest indywidualnie…\n",
|
||||
" * …Ale działanie obiektu może zależeć od innych komponentów…\n",
|
||||
" * …Które mogą być niezaimplementowane w czasie testowania.\n",
|
||||
" * Takie komponenty zastępuje się zamiennikami (ang. placeholder).\n",
|
||||
"\n",
|
||||
" * Typy zamienników:\n",
|
||||
" * Stub (zalążek) - imituje obiekt zewnętrzny, który przekazuje dane do testowanego obiektu).\n",
|
||||
" * Spy (szpieg) - zapamiętuje historię danych przekazywanych przez testowany obiekt).\n",
|
||||
" * Mock (atrapa) - \"inteligentnie\" imituje obiekt zewnętrzny, który reaguje na dane przekazywane z testowanego obiektu.\n",
|
||||
" * Fake (podróbka) - mocno uproszczona atrapa obiektu zewnętrznego, która nie ma wpływu na wynik testowania.\n",
|
||||
" * Dummy (manekin) - pusty obiekt.\n",
|
||||
" * Blog na temat zamienników:\n",
|
||||
" [Przeczytaj o zamiennikach](https://dariuszwozniak.net/posts/kurs-tdd-19-mock-stub-fake-spy-dummy)\n",
|
||||
" \n",
|
||||
" **Przykład stuba (zalążka)**: \n",
|
||||
" <img src=\"obrazy/stub.png\" alt=\"Przykład zalążka\" width=400px>\n",
|
||||
"(rysunek na podstawie: wikipedia\")\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6. Testowanie integracyjne w Scrumie\n",
|
||||
" * Celem testowania integracyjnego jest sprawdzenie, czy niezależne komponenty (np. klasy) prawidłowo ze sobą współpracują.\n",
|
||||
" * Testowanie wykonują deweloperzy (na swojej maszynie) lub zespół testujący (w repozytorium).\n",
|
||||
" * Metody testowania integracyjnego:\n",
|
||||
" * Metoda wielkiego wybuchu\n",
|
||||
" * Metoda stopniowej integracji i testowania\n",
|
||||
" * W metodyce Scrum możliwe jest stosowanie obu metod:\n",
|
||||
" * Metoda wielkiego wybuchu na zakończenie sprintu lub\n",
|
||||
" * Metoda Ciągłej Integracji (testowanie po każdej zmianie)\n",
|
||||
" * Systemy Ciągłej Integracji ułatwiają testowanie po każdej zmianie poprzez uruchamianie testów automatycznych. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Podsumowanie\n",
|
||||
" * Niewykryte defekty w kodzie programu mogą doprowadzić do poważnej awarii lub katastrofy.\n",
|
||||
" * Testowanie jest czynnością kreatywną, której celem jest wykazanie istnienia defektów w kodzie.\n",
|
||||
" * Przypadki testowe mają na celu ograniczenie przestrzeni wyszukiwania defektów.\n",
|
||||
" * Testowanie odbywa się na różnych poziomach – w tradycyjnych systemach jest to proces sekwencyjny, a w Scrumie – iteracyjny."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "08. Testowanie w programowaniu zwinnym[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,436 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 9. <i>Testowanie systemowe i akceptacyjne</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Testowanie systemowe i akceptacyjne - wyjaśnienie pojęć"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie systemowe</h3>\n",
|
||||
" \n",
|
||||
"Przedmiotem <b>testowania systemowego</b> jest całość oprogramowania zainstalowana w pewnym środowisku wykonawczym.\n",
|
||||
" * Środowisko testowania musi być zbliżone do środowiska pracy.\n",
|
||||
" * Testowanie systemowe odbywa się metodą „czarnej skrzynki”.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Testowanie akceptacyjne</h3>\n",
|
||||
" \n",
|
||||
"Przedmiotem <b>testowania akceptacyjnego </b> jest oprogramowanie stanowiące przedmiot dostawy do użytkownika w docelowym środowisku pracy.\n",
|
||||
" * Testowana jest zgodność z wymaganiami i potrzebami użytkownika.\n",
|
||||
" * Testowanie akceptacyjne przeprowadza użytkownik / klient.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Typy testowania systemowego"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"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",
|
||||
" * 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",
|
||||
" * testy zdroworozsądkowe\n",
|
||||
" * testy regresywne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy dymne\n",
|
||||
"**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",
|
||||
"<img src=\"obrazy/testy dymne.png\" alt=\"Przykład testów dymnych\" width=400px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy zdroworozsądkowe\n",
|
||||
"**Testy zdroworozsądkowe** 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 zdroworozsądkowego:**\n",
|
||||
"<img src=\"obrazy/sanity test.png\" alt=\"Przykład testów zdroworozsądkowych\" width=900px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy regresywne\n",
|
||||
"**Testy regresywne** to szczegółowe testy, pozwalające wykazać, że w aplikacji powstały nieznane błędów będące wynikiem wprowadzonych zmian.\n",
|
||||
"\n",
|
||||
"**Przykład przypadku testowego na poziomie testowania regresywnego:**\n",
|
||||
"<img src=\"obrazy/testy regresywne.png\" alt=\"Przykład testów regresywnych\" width=900px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Raport z testowania funkcjonalnego\n",
|
||||
"Przypadki testowe w testowaniu funkcjonalnym warto tworzyć w takiej formie, aby łatwo można je było rozszerzyć o wyniki testowania - tworząc raport z testowania.\n",
|
||||
"\n",
|
||||
"**Fragment raportu z testowania funkcjonalnego:**\n",
|
||||
"<img src=\"obrazy/raport z testowania.png\" alt=\"Przykład raportu z testowania\" width=900px>\n",
|
||||
"\n",
|
||||
"W raporcie z testowania można zawrzeć dodatkowe informacje np. o wydajności działania danego przypadku testowego."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Testowanie wydajności (performance testing)\n",
|
||||
"Zadaniem **testowania wydajności** jest wykazanie, że system nie daje odpowiedzi w wystarczająco krótkim czasie pod ustalonym obciążeniem produkcyjnym, np. przy dużym wolumenie przetwarzanych danych.\n",
|
||||
"\n",
|
||||
"**Przykładowy fragment raportu z testowania wydajności systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/performance test.png\" alt=\"Przykład raportu z testowania wydajności\" width=600px>\n",
|
||||
"\n",
|
||||
"**Stronę internetową** można bardzo szybko przetestować pod kątem wydajności, korzystając np. z narzędzia dostępnego na stronie https://webspeed.intensys.pl/.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"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",
|
||||
"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",
|
||||
"\n",
|
||||
"**Przykład raportu tekstowego z testu przeciążeń systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/load test - raport tekstowy.png\" alt=\"Przykład raportu z testowania\" width=800px>\n",
|
||||
"\n",
|
||||
"**Przykład raportu graficznego z testu przeciążeń systemu tłumaczenia:**\n",
|
||||
"<img src=\"obrazy/load test - raport graficzny.png\" alt=\"Przykład raportu z testowania\" width=800px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.4. Testowanie pamięci (memory testing)\n",
|
||||
"Celem **testowania pamięci** jest wykazanie, że system narusza narzucone wymagania pamięciowe."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.5. Testowanie ochrony danych (security testing)\n",
|
||||
"Proces ma wykazać, że dane nie są chronione w odpowiedni sposób.\n",
|
||||
" * Przypadki testowe mają wymusić naruszenie mechanizmów ochrony danych."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.6. Testowanie konfiguracji\n",
|
||||
"**Testowanie konfiguracji** ma na celu zweryfikowanie działania systemu w różnych konfiguracjach sprzętowych i programowych.\n",
|
||||
" * Testowanie może odbywać się za pomocą specjalnie przygotowanej maszyny wirtualnej.\n",
|
||||
" * Dla serwisów webowych istotne jest testowanie różnych urządzeń oraz różnych typów przeglądarek."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.7. Testowanie zgodności wersji\n",
|
||||
"**Testowanie zgodności wersji** ma na celu wykazanie niezgodności z przeszłymi wersjami programów:\n",
|
||||
" * testowanie patchów i aktualizacji,\n",
|
||||
" * testowanie nowych wersji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.8. Testowanie zgodności z dokumentacją użytkownika\n",
|
||||
"Jest to próba wykrycia rozbieżności między programem a jego specyfikacją zapisaną w dokumentacji użytkownika.\n",
|
||||
" * Przy okazji porównuje się dokumentację użytkownika z pierwotnymi celami projektowymi.\n",
|
||||
" * Ten typ testowania stosowany jest również w testowaniu akceptacyjnym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.9. Testowanie procedury instalacyjnej\n",
|
||||
"Celem jest wykazanie istnienia defektów poprzez wywołanie błędów w trakcie procedury instalacyjnej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.10. Testowanie odporności (resilience testing)\n",
|
||||
"Zadaniem **testowania odporności** jest postawienie pod znakiem zapytania odporności systemu na awarie. \n",
|
||||
" * Testowanie polega na umyślnym „zasianiu” w kodzie programu różnorakich błędów.\n",
|
||||
" * Odporność na awarie mierzy się przy pomocy MTTR (mean time to recovery).\n",
|
||||
" * Celem testowania jest wskazanie, że łączny czas przestojów przekracza limit określony w celach projektowych."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Testowanie akceptacyjne\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",
|
||||
" * Wykrycie defektów.\n",
|
||||
" \n",
|
||||
" ## Kto i kiedy wykonuje testowanie akceptacyjne?\n",
|
||||
"* Testowanie akceptacyjne wykonywane jest przez: \n",
|
||||
" * właścicieli produktów (przedstawicieli wykonawców);\n",
|
||||
" * wyznaczonych przedstawicieli strony zamawiającej;\n",
|
||||
" * operatorów systemów (np. pełniących rolę administratora);\n",
|
||||
" * użytkowników końcowych.\n",
|
||||
"* Testowanie akceptacyjne jest zazwyczaj ostatnim etapem sekwencyjnego cyklu życia oprogramowania.\n",
|
||||
"* W iteracyjnych modelach wytwarzania oprogramowania testowanie akceptacyjne może odbywać się na zakończenie każdej iteracji (np. sprintu). \n",
|
||||
"\n",
|
||||
"## Typy testowania akceptacyjnego\n",
|
||||
" * Testowanie akceptacyjne przez użytkownika\n",
|
||||
" * Testowanie produkcyjne\n",
|
||||
" * Testowanie akceptacyjne zgodności \u000b",
|
||||
"z umową i zgodności \u000b",
|
||||
"z przepisami prawa\n",
|
||||
" * Testy alfa i testy beta"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Testowanie akceptacyjne przez użytkownika\n",
|
||||
"Ma na celu sprawdzenie, czy system nadaje się do użytkowania przez przyszłych odbiorców: \n",
|
||||
" * czy spełni ich potrzeby, \n",
|
||||
" * czy wypełni postawione wymagania,\n",
|
||||
" * wykona proces biznesowy z minimalną liczbą problemów, minimalnymi kosztem i ryzykiem."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2 Produkcyjne testy akceptacyjne\n",
|
||||
"Są to testy systemu przez operatorów lub administratorów, które mogą obejmować:\n",
|
||||
" * testowanie mechanizmów tworzenia kopii zapasowych i odtwarzania danych;\n",
|
||||
" * instalowanie, odinstalowywanie i aktualizowanie oprogramowania;\n",
|
||||
" * usuwanie skutków awarii;\n",
|
||||
" * zarządzanie użytkownikami;\n",
|
||||
" * wykonywanie czynności pielęgnacyjnych;\n",
|
||||
" * wykonywanie czynności związanych z ładowaniem i migracją danych;\n",
|
||||
" * sprawdzanie, czy występują podatności zabezpieczeń;\n",
|
||||
" * wykonywanie testów wydajnościowych."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 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",
|
||||
" * Wykonywane jest często przez niezależnych testerów pod nadzorem."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Testowanie automatyczne\n",
|
||||
"**Automatyzacja testowania** polega na zastąpienia testera oprogramowaniem, które:\n",
|
||||
"* Steruje testem,\n",
|
||||
"* Porównuje wyniki z oczekiwaniami,\n",
|
||||
"* Raportuje błędy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Podejścia do testowania automatycznego\n",
|
||||
"\n",
|
||||
"### Code-driven testing (testowanie sterowane kodem)\n",
|
||||
" * Testowane są publiczne interfejsy do klas (modułów, bibliotek) poprzez podanie różnorakich danych wejściowych i walidacji wyników.\n",
|
||||
" * Jest to poziom testów jednostkowych.\n",
|
||||
"\n",
|
||||
"### Graphical user interface testing (testowanie graficznego interfejsu użytkownika)\n",
|
||||
" * Generowane są zdarzenia interfejsu takie jak: kliknięcia myszką czy naciśnięcie klawiszy i obserwowane są zmiany w interfejsie użytkownika. \n",
|
||||
" * Jest to poziom testów systemowych.\n",
|
||||
" \n",
|
||||
"#### Testowanie za pomocą makr, np. Macro Express (https://www.macros.com/)\n",
|
||||
"1. Nagrywamy makro realizujące ciąg zdarzeń (kliknięć, klawiszy itp.),\n",
|
||||
"2. przygotowujemy zestaw plików graficznych, które obrazują kolejne oczekiwane wyglądy interfejsu,\n",
|
||||
"3. podczas testowania każdorazowo porównujemy obrazy interfejsu z obrazami oczekiwanymi.\n",
|
||||
"\n",
|
||||
"#### Testowanie za pomocą oprogramowania, np. Selenium\n",
|
||||
"(http://tynecki.pl/pdf/Automating-functional-tests-using-Python-and-Selenium-Piotr-Tynecki.pdf)\n",
|
||||
"* Opracowujemy sekwencję zdarzeń (kliknięć, klawiszy itp.).\n",
|
||||
"* Sprawdzamy powodzenie testowanej operacji (np. sprawdzamy, czy istnieje na stronie poszukiwany element).\n",
|
||||
"\n",
|
||||
"#### Zalety automatycznego testowania GUI\n",
|
||||
"* Może być stosowane do każdego oprogramowania z graficznym interfejsem użytkownika.\n",
|
||||
"* Znakomicie wkomponowuje się w paradygmat „continous integration”.\n",
|
||||
"\n",
|
||||
"#### Wady automatycznego testowania GUI\n",
|
||||
"* Przygotowanie przypadków testowych jest czasochłonne.\n",
|
||||
"* Każda najmniejsza zmiana interfejsu powoduje konieczność opracowania nowego zestawu testowego.\n",
|
||||
"* W scenariuszach zawarte są się często operacje nieistotne z punktu widzenia testowania."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Plan testów\n",
|
||||
"**Plan testów** to dokument opisujący organizację procesu testowania. \n",
|
||||
" * Dotyczy zazwyczaj testowania systemowego.\n",
|
||||
" * Plan testów składa się z następujących elementów:\n",
|
||||
" * Zakres testów\n",
|
||||
" * Strategia testowania\n",
|
||||
" * Zasoby niezbędne do testów\n",
|
||||
" * Specyfikacja testów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5.1. Zakres testów\n",
|
||||
" * Identyfikacja testowanego produktu (co testujemy?)\n",
|
||||
" * Określenie wymagań (właściwości), które testujemy\n",
|
||||
" * Określenie wymagań (właściwości), których nie testujemy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5.2. Metodologia testowania\n",
|
||||
" * Określenie typów testowania, które przeprowadzimy.\n",
|
||||
" * Określenie typów testowania, których nie przeprowadzimy.\n",
|
||||
" * Zdefiniowanie metod oceny testu\n",
|
||||
" * Zdefiniowanie typów błędów (awarie, błędy istotne, błędy nieistotne)\n",
|
||||
" * Określenie kryteriów pozytywnego zakończenia testów\n",
|
||||
" * Przykładowo: określenie dopuszczalnej liczby błędów poszczególnego typu\n",
|
||||
" * Określenie postaci raportu z testów\n",
|
||||
" \n",
|
||||
"**Przykład definicji błędów:**\n",
|
||||
" <img src=\"obrazy/definicje błędów.png\" alt=\"Przykład definicji błędów\" width=500px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.3. Zasoby niezbędne do testów\n",
|
||||
" * Środowisko testowe\n",
|
||||
" * Oprogramowanie zastosowane w testowaniu\n",
|
||||
" * Zespół wykonawców\n",
|
||||
" * Warunki początkowe, np.:\n",
|
||||
" * np. wykonane prace instalacyjne lub konfiguracyjne\n",
|
||||
" * stopień ukończenia prac implementacyjnych\n",
|
||||
" \n",
|
||||
"**Przykład oprogramowania zastosowanego w testowaniu:**\n",
|
||||
"<img src=\"obrazy/software.png\" alt=\"Przykład definicji błędów\" width=600px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.4. Specyfikacja testów \n",
|
||||
"**Specyfikacja testów** to zestaw scenariuszy testowych (przypadków testowych)."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
" * Testowanie manualne jest wciąż najczęściej stosowaną metodą testowania systemowego i akceptacyjnego.\n",
|
||||
" * Testowanie automatyczne staje się coraz bardziej popularne; \n",
|
||||
" * jest pracochłonne w przygotowaniu,\n",
|
||||
" * ale oszczędza czas samego procesu testowania.\n",
|
||||
" * Niezależnie od typu testowania, jest to czynność, którą należy starannie zaplanować."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "09. Testowanie integracyjne i systemowe[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,578 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 10. <i>Wybrane zagadnienia użyteczności</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Pojęcie użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \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",
|
||||
"<h3> Cechy aplikacji użytecznej </h3>\n",
|
||||
" \n",
|
||||
"<ul>\n",
|
||||
"<li> Łatwa do nauki: Jak łatwo jest użytkownikom wykonać dane zadanie po raz pierwszy?\n",
|
||||
"<li> Wydajna w pracy: Jak szybko użytkownicy wykonują zadania, gdy już się nauczyli programu?\n",
|
||||
"<li> Satysfakcja: Czy korzystanie z programu daje satysfakcję?\n",
|
||||
"<li> 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",
|
||||
"<li> Zapamiętywalna po czasie: Jak łatwo powrócić do biegłości użytkowania po pewnym okresie nieużytkowania programu?\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Wskazówki do tworzenia użytecznej aplikacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Klasyka w oparciu o \"Don't make me think\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<a href=\"https://www.uxbooth.com/articles/10-usability-lessons-from-steve-krugs-dont-make-me-think/\">Przeczytaj w Internecie</a>\n",
|
||||
"\n",
|
||||
"<ol> \n",
|
||||
" \n",
|
||||
"<li> Usability Means… </li>\n",
|
||||
"\n",
|
||||
"<li>Web applications should explain themselves. </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t Make Me Think </li>\n",
|
||||
"\n",
|
||||
"<li>Don’t waste my time </li>\n",
|
||||
" \n",
|
||||
"<li> Users still cling to their back buttons </li>\n",
|
||||
"\n",
|
||||
"<li> We’re creatures of habit </li>\n",
|
||||
"\n",
|
||||
"<li> No Time for Small Talk </li>\n",
|
||||
"\n",
|
||||
"<li> Don’t lose search </li>\n",
|
||||
"\n",
|
||||
"<li> We form mental site-maps </li>\n",
|
||||
"\n",
|
||||
"<li> Make it easy to go home </li>\n",
|
||||
" \n",
|
||||
"</ol>\n",
|
||||
"\n",
|
||||
"<div>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Podejście (bardziej) współczesne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Wskazówki do tworzenia użytecznego systemu informatycznego</h3> \n",
|
||||
"\n",
|
||||
"<ol>\n",
|
||||
"<li> Autorze: Poznaj użytkownika, a TY nie jesteś użytkownikiem. </li> \n",
|
||||
" <li> Użytkownik powinien mieć kontrolę nad systemem, a nie odwrotnie: to użytkownik jest szefem i system powinien to okazywać. </li> \n",
|
||||
" <li> System musi ułatwiać użytkownikowi życie:</li>\n",
|
||||
" <ul>\n",
|
||||
" <li> 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. </li>\n",
|
||||
" <li> Każda akcja użytkownika powinna mieć reakcję programu. </li>\n",
|
||||
" <li> Kiedy użytkownik ma do podjęcia decyzję, system podaje mu całą dostępną informację. </li>\n",
|
||||
" </ul> \n",
|
||||
" <li> System musi być \"idioto-odporny\": </li>\n",
|
||||
" <ul>\n",
|
||||
" <li> Każdy robi błędy, więc każdy błąd powinien dać się naprawić. </li>\n",
|
||||
" <li> Gdy użytkownik zrobi błąd, System daje mu o tym znać, zanim … wpadnie w PRAWDZIWE kłopoty. </li>\n",
|
||||
" <li> Informacje o błędach powinny być zrozumiałe dla użytkownika i mówić mu, jak naprawić problem. </li>\n",
|
||||
" </ul> \n",
|
||||
" <li> Wczuj się w użytkownika </li>\n",
|
||||
" <ul>\n",
|
||||
" <li> Eliminuj niepotrzebne decyzje (nie pytaj, jak nie musisz). </li>\n",
|
||||
" <li> Im mniej kroków do celu, tym lepiej.</li> \n",
|
||||
" <li> Użytkownik powinien zawsze móc dowiedzieć się, co robić dalej. </li>\n",
|
||||
" <li> Użytkownik powinien zawsze wiedzieć, co się dzieje.\n",
|
||||
" </ul>\n",
|
||||
" </ol>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3. Zasady dobrej nawigacji na portalu internetowym\n",
|
||||
"### 3.1. Pojęcie nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<b> Nawigacja </b> to stały, niezmieniający się zestaw elementów w serwisie ułatwiający poruszanie się na niej.\n",
|
||||
" \n",
|
||||
"Najczęściej stosowanymi elementami nawigacji są: \n",
|
||||
"<ul>\n",
|
||||
"<li> Menu główne </li>\n",
|
||||
"<li> Menu narzędziowe </li>\n",
|
||||
"<li> Identyfikator witryny </li>\n",
|
||||
"<li> Wyszukiwarka </li>\n",
|
||||
"<li> Odsyłacz do strony startowej (zawarty w logo) </li>\n",
|
||||
"<li> Flagi narodowe (przełączenie języków) </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Cechy dobrej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Szybkie przechodzenie po różnych elementach serwisu.\n",
|
||||
" * Łatwe prowadzenie użytkownika do poszukiwanej informacji. \n",
|
||||
" * Klarowność: użytkownik wie gdzie jest, gdzie może się skierować, jak wrócić, a także posiada informacje o odwiedzonych miejscach. \n",
|
||||
" * Oszczędność: główne menu witryny nie powinno zawierać zbyt wielu elementów (między 5 a 9)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.3. Zasady użytecznej nawigacji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 1. Widoczność\n",
|
||||
"Wszystkie elementy nawigacji muszą być bardzo dobrze widoczne na każdej stronie i podstronie serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 2. Przewidywalność\n",
|
||||
" * Nazwy elementów menu powinny pozwalać na przewidzenie zawartości\n",
|
||||
" * Elementy menu powinny informować użytkownika o całej zawartości witryny.\n",
|
||||
" * Odwiedzone linki powinny być oznaczone innym kolorem niż nieodwiedzone. "
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 3. Łatwość orientacji w strukturze serwisu\n",
|
||||
"* Powinno się stosować różne style wyróżnienia jego elementów:\n",
|
||||
" * dla całej kategorii, na której aktualnie znajduje się kursor (np. Aktualności),\n",
|
||||
" * dla pozycji w menu, z której aktualnie korzysta użytkownik (np. Publikacje zagraniczne),\n",
|
||||
" * dla pozostałych elementów serwisu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 4. Zasada odwróconej piramidy\n",
|
||||
" * Na najwyższym poziomie należy umieścić kategorie najbardziej ogólne, a następnie przechodzić do podziału bardziej szczegółowego. \n",
|
||||
" * Na tym samym poziomie powinny znajdować się kategorie o tym samym stopniu szczegółowości."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 5. Właściwe nazewnictwo\n",
|
||||
" * Wykluczający podział etykiet menu: \n",
|
||||
" * dana pozycja w menu może należeć tylko do jednej kategorii.\n",
|
||||
" * Proste nazewnictwo: \n",
|
||||
" * etykiety powinno formułować się w języku zrozumiałym dla użytkownika,\n",
|
||||
" * powinno unikać się specjalistycznego słownictwa.\n",
|
||||
" * Unikalne nazwy: \n",
|
||||
" * dana nazwa powinna pojawiać się w serwisie internetowym nie więcej niż raz,\n",
|
||||
" * każda strona powinna mieć swoja nazwę.\n",
|
||||
" * Nazwa strony musi być dobrze widoczna:\n",
|
||||
" * nazwa strony musi być w dobrze umiejscowiona i wyróżniona za pomocą rozmiaru i koloru czcionki.\n",
|
||||
" * Nazwa strony lub podstrony musi być zgodna z nazwą odsyłacza, który do niej prowadzi."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Zasada 6. Spójność w wyglądzie i działaniu elementów nawigacyjnych\n",
|
||||
"* Należy stosować te same konwencje w obrębie całego menu. \n",
|
||||
"* Elementy pierwszego poziomu powinny pozostawać niezmienne w trakcie korzystania z całego serwisu internetowego. \n",
|
||||
"* Wszystkie pozycje w menu powinny funkcjonować na tej samej zasadzie. \n",
|
||||
"* Przy formułowaniu nazw w menu należy w każdym przypadku stosować tę samą formę gramatyczną.\n",
|
||||
"* Pozycje menu należące do jednego poziomu powinny być sformatowane w jednym stylu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Automatyczne metody badania użyteczności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Badanie współczynnika konwersji\n",
|
||||
"**Współczynnik konwersji** wskazuje, jaka część internautów odwiedzających daną stronę dokonała pożądanej akcji np.\n",
|
||||
" * Dokonała zakupu\n",
|
||||
" * Wypełniła formularz\n",
|
||||
" * Wysłała maila na wskazany adres\n",
|
||||
" * Zarejestrowała się do systemu\n",
|
||||
" * Pobrała software"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Testy A/B (testy porównawcze)\n",
|
||||
"* Metoda polega na porównaniu dwóch wersji tej samej aplikacji.\n",
|
||||
"* Najczęściej stosowana jest do stron internetowych.\n",
|
||||
"* Różnicę (postęp lub regres) między wersjami wyznacza się poprzez porównanie wartości pewnej miary, np. współczynnika konwersji dla stron internetowych. \n",
|
||||
"\n",
|
||||
"[Przeczytaj w Internecie](https://www.optimizely.com/ab-testing/)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analityka ruchu na portalu internetowym\n",
|
||||
"Metoda polega na obserwacji dotyczących ruchu na witrynie, takich jak:\n",
|
||||
" * Wskaźnik odrzuceń – procentowa wartość osób, które opuściły stronę wejściową serwisu bez wykonania żadnej akcji\n",
|
||||
" * Wskaźnik porzuceń – wskaźnik analogiczny dla podstron danego serwisu,\n",
|
||||
"Metoda wskazuje działania użytkownika – nie wskazuje jego przyczyn. \n",
|
||||
"\n",
|
||||
"Przykładowa witryna: \n",
|
||||
"https://www.google.com/analytics/"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Click-tracking\n",
|
||||
"\n",
|
||||
"Metoda dostarcza informacji o poszczególnych elementach strony za pomocą następujących typów informacji\n",
|
||||
" * Heat maps. \n",
|
||||
" * Wskazują, w jakie miejsca na stronie ludzie klikają (see what’s hot and what’s not).\n",
|
||||
" * Confetti\n",
|
||||
" * Analiza kliknięć: jak klikały poszczególne grupy użytkowników i w poszukiwaniu czego.\n",
|
||||
" * Scrollmap\n",
|
||||
" * Analiza, jak daleko w dół strony użytkownicy przewijają stronę – pozwala przeanalizować miejsca, w których strona jest najczęściej porzucana.\n",
|
||||
" * Overlay report\n",
|
||||
" * Liczba kliknięć na poszczególne elementy strony.\n",
|
||||
"\n",
|
||||
"Przykładowy dostawca: \n",
|
||||
"http://www.crazyegg.com"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Analiza kontrastu\n",
|
||||
"\n",
|
||||
"Dostarcza informacji o kontraście pomiędzy elementami strony, co jest szczególnie istotne dla osób z upośledzeniem wzroku.\n",
|
||||
"\n",
|
||||
"* Przykładowy adres\n",
|
||||
" * https://webaim.org/resources/contrastchecker/\n",
|
||||
" * Można wpisać adres strony, która ma zostać przeanalizowana pod względem kontrastu – otrzymuje się pełen raport."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Metody z udziałem użytkowników\n",
|
||||
"\n",
|
||||
"W metodach z udziałem użytkowników można posłużyć się zastosowaniem *persony*, w celu optymalizacji kosztów badania.\n",
|
||||
" * **Persona** to fikcyjna postać stworzona by reprezentować typy użytkowników (demograficzne i technograficzne).\n",
|
||||
" * Persony to inaczej archetypy grup użytkowników i ich potrzeb. Dzięki personom cała populacja docelowa reprezentowana jest przez kilka konceptów.\n",
|
||||
" > Przykład persony: Jan Kowalski, lat 37, elektryk, mieszkaniec Ząbkowic Śląskich\n",
|
||||
" \n",
|
||||
" Przykładowy proces testowania użyteczności z udziałem użytkowników:\n",
|
||||
" 1. Określ grupy użytkowników np. przy użyciu persony (co najmniej jedna persona na grupę).\n",
|
||||
" 2. Dla każdej persony utwórz potencjalny scenariusz użycia – w jaki sposób dana persona chce korzystać z systemu.\n",
|
||||
" 3. Dla każdej persony zorganizuj użytkowników reprezentatywnych (minimum jednego użytkownika dla persony).\n",
|
||||
" 4. Poproś ich o wykonanie zadań charakterystycznych dla danej persony.\n",
|
||||
" 5. Obserwuj lub nagrywaj działania użytkowników: gdzie im się powodzi, a gdzie mają trudności.\n",
|
||||
" 6. Potencjalnie poproś użytkowników o wypełnienie ankiet.\n",
|
||||
"\n",
|
||||
"Wyróżniamy następujące typy metod z udziałem użytkowników:\n",
|
||||
" * podgląd sesji użytkowników.\n",
|
||||
" * obserwacja użytkownika,\n",
|
||||
" * metoda wywiadu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Podgląd sesji użytkowników\n",
|
||||
"* Działalność użytkownika jest „nagrywana”.\n",
|
||||
"* Autor oprogramowania może odtworzyć działania użytkownika z perspektywy użytkownika.\n",
|
||||
"* Każde kliknięcie, poruszenie myszą, przesunięcie kursora zostaje zapisane."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Obserwacja użytkownika\n",
|
||||
"* Działalność użytkownika jest obserwowana.\n",
|
||||
"* Obserwator zapisuje poczynania użytkownika.\n",
|
||||
"* Obserwacje są analizowane w celu ulepszenia użyteczności aplikacji."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Metoda wywiadu\n",
|
||||
" * Sposoby przeprowadzenia wywiadu:\n",
|
||||
" * Analiza celów użytkowników i wykonywania przez nich zadań,\n",
|
||||
" * Dyskusja prowadzona przez moderatora,\n",
|
||||
" * Wypełnienie ankiet / kwestionariuszy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Raport badania użyteczności\n",
|
||||
"Raport badania użyteczności to sprawozdanie z badania użyteczności aplikacji, w którym wskazuje się **obszary problemowe**.\n",
|
||||
"Przykładowo raport użytecznści może składać się z następujących części:\n",
|
||||
"1. Informacje wstępne\n",
|
||||
"2. Metodologia badania\n",
|
||||
"3. Obszary problemowe\n",
|
||||
"4. Dodatki"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.1. Informacje wstępne\n",
|
||||
"Ta część zawiera ogólne informacje o prowadzonym badaniu, np. :\n",
|
||||
" * Daty tworzenia raportu\n",
|
||||
" * Harmonogram prowadzenia badań\n",
|
||||
" * Odwołanie do standardów badania użyteczności\n",
|
||||
" * Autorzy raportu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.2. Metodologia badania\n",
|
||||
"Opis tej części zależy od przejętej metody badania. Przykładowo, dla metody wywiadu część ta może mieć następującą postać:\n",
|
||||
"\n",
|
||||
"### 5.2.1. Zakres badania\n",
|
||||
" * Określenie zakresu projektowego: badanie gotowego produktu, czy ocena prototypu,\n",
|
||||
" * Określenie celu, np., wskazanie wyłącznie błędów w systemie, czy również wskazanie proponowanych ulepszeń,\n",
|
||||
" * Określenie zastosowanej metody badania użyteczności.\n",
|
||||
"\n",
|
||||
"### 5.2.2. Profile użytkowników\n",
|
||||
" * Określenie kilku segmentów odbiorców pod względem:\n",
|
||||
" * Danych demograficznych\n",
|
||||
" * Doświadczenia z programami podobnymi (wcześniejszymi wersjami systemu)\n",
|
||||
" * Oczekiwań względem systemu\n",
|
||||
"\n",
|
||||
"### 5.2.3. Grupa badawcza\n",
|
||||
" * Określenie liczebności grupy badawczej (około 5 osób)\n",
|
||||
" * Określenie charakterystyki grupy badawczej pod względem różnych kryteriów , np.\n",
|
||||
" * płeć, \n",
|
||||
" * wiek, \n",
|
||||
" * miejsce zamieszkania, \n",
|
||||
" * wykształcenie, \n",
|
||||
" * zawód, \n",
|
||||
" * wielkość firmy, \n",
|
||||
" * branża, \n",
|
||||
" * obsługa komputera, \n",
|
||||
" * doświadczenie z podobnymi programami, itp.\n",
|
||||
" * Liczebność i charakterystykę grupy badawczej można zobrazować za pomocą wykresów.\n",
|
||||
"\n",
|
||||
"### 5.2.4. Scenariusz badania\n",
|
||||
"W tej części należy opisać, jak będzie przebiegać scenariusz badania.\n",
|
||||
"Przykładowy scenariusz badania w metodzie wywiadu:\n",
|
||||
"1. Omówienie zadań i sposobu wypełniania kwestionariusza\n",
|
||||
"2. Podanie informacji o regulaminie przeprowadzenia testu wykonania zadań\n",
|
||||
"3. Test wykonania zadań\n",
|
||||
"4. Wypełnienie przygotowanego kwestionariusza przez użytkowników\n",
|
||||
"\n",
|
||||
"### 5.2.5. Lista zadań do wykonania przez użytkowników\n",
|
||||
"W tej częścI dla każdego zadania należy podać kryterium pomyślnego ukończenia zadania. Lista zadań może być podana w postaci tabelki:\n",
|
||||
" * Opis zadania\n",
|
||||
" * Kryterium ukończenia zadania\n",
|
||||
"\n",
|
||||
"### 5.2.6. Ocena wykonania zadań \n",
|
||||
"W tej części należy ocenić, jak badani wykonali zadania.\n",
|
||||
"Przykładowa ocena wykonania zadań:\n",
|
||||
" * Liczba błędów krytycznych użytkownika\n",
|
||||
" * Liczba błędów niekrytycznych użytkownika\n",
|
||||
" * Liczba zadań wykonanych zgodnie z założeniami\n",
|
||||
" * Liczba zdań niewykonanych zgodnie z założeniami\n",
|
||||
" * Czas wykonania zadań\n",
|
||||
"\n",
|
||||
"Ten etap raportu można zakończyć wykresami."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.3. Obszary problemowe\n",
|
||||
"Obszary problemowe to **wnioski** z badania użyteczności.\n",
|
||||
" * W tej częśći raportu określone zostają obszary problemowe (składowe systemu, które sprawiają kłopoty).\n",
|
||||
" * Dla każdego obszaru problemowego określa się zestaw problemów użytkowania.\n",
|
||||
" * Problem użytkowania składa się z:\n",
|
||||
" * Tytułu problemu,\n",
|
||||
" * Opisu problemu,\n",
|
||||
" * Jeśli problemem jest zbyt długi czas wykonania zadania, to można podać średnie czasy rozwiązania,\n",
|
||||
" * Filmiku wideo (jeśli takim dysponujemy),\n",
|
||||
" * Rekomendacji rozwiązania problemu,\n",
|
||||
" * Opisu proponowanego scenariusza działania użytkownika po rozwiązaniu problemu."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 5.4. Dodatki\n",
|
||||
"W tej części raportu składamy materiały pomocnicze, np.\n",
|
||||
" ### 5.4.1. Ankieta\n",
|
||||
"\n",
|
||||
"W ankiecie mogą znaleźć się przykładowe pytania:\n",
|
||||
" * Jak ocenia Pan/Pani trudność poszczególnych zadań?\n",
|
||||
" * Co sprawiło Panu/Pani największy problem podczas testów?\n",
|
||||
" * Jakie inne funkcjonalności byłyby pożyteczne (wskazać listę do wyboru)?\n",
|
||||
" * Jakie elementy systemu były niezrozumiałe?\n",
|
||||
"\n",
|
||||
" Wyniki ankiety potestowej możemy przedstawić na wykresach.\n",
|
||||
" \n",
|
||||
"### 5.4.2. Inne materiały pomocnicze\n",
|
||||
"Przykładowe materiały pomocnicze:\n",
|
||||
" * Lista filmów video ilustrujących błędy użyteczności aplikacji,\n",
|
||||
" * Wnioski i rekomendacje ekspertów użyteczności,\n",
|
||||
" * Inne materiały w zależności od zastosowanej metody badawczej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"attachments": {},
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie wykładu\n",
|
||||
"1. Tworząc aplikację, myśl przede wszystkim o jej użyteczności, a potem dopiero o jej funkcjonalności.\n",
|
||||
"2. O sukcesie aplikacji stanowi pomysł, a nie wielość funkcji.\n",
|
||||
"3. Zawsze (!) pamiętaj o wskazówkach użyteczności.\n",
|
||||
"4. Tworząc portal internetowy, stosuj zasady dobrej nawigacji.\n",
|
||||
"5. Przekonaj się, jak Twój program jest używany – wykonaj badanie użyteczności."
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "10. Wybrane zagadnienia użyteczności[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,691 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 11. <i>Aspekty użyteczności</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Aspekty użyteczności w pytaniach... często bez odpowiedzi\n",
|
||||
"Na podstawie książki \"Postaw na użyteczność\" Matta Laceya (Wydawnictwo Naukowe PWN, 2019).\n",
|
||||
"\n",
|
||||
"Podczas konstruowania systemu informatycznego warto zadać sobie pytania, na które odpowiedź wcale nie musi być oczywista - zależeć może ona od typu aplikacji i środowiska, w którym aplikacja będzie używana."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Definicja użyteczności (...jeszcze jedna)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Użyteczność</h3> \n",
|
||||
"\n",
|
||||
"Użyteczność to zestaw cech aplikacji, które sprawiają, że korzysta się z niej <b>łatwo</b>.\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Przepis na sukces\n",
|
||||
"\n",
|
||||
"SUKCES = WARTOŚĆ + ODCZUCIA UŻYTKOWNIKA + SZCZĘŚCIE"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Wartość</h3> \n",
|
||||
"\n",
|
||||
"Wartość aplikacji to suma korzyści dla użytkownika: \n",
|
||||
"<ul>\n",
|
||||
"<li>zadanie jest wykonalne\n",
|
||||
"<li>zadanie jest łatwiejsze\n",
|
||||
"<li>zadanie można wykonać szybciej\n",
|
||||
"<li>aplikacja dostarcza dochód lub oszczędza środki\n",
|
||||
"<li>dostarczenie rozrywki\n",
|
||||
"<li>dostarczenie informacji\n",
|
||||
"<li>edukacja \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Odczucia użytkownika (User Experience)</h3> \n",
|
||||
"\n",
|
||||
"Odczucia użytkownika to uczucia i emocje użytkownika doznawane podczas korzystania z aplikacji.\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Szczęście</h3> \n",
|
||||
"\n",
|
||||
"\"Szczęście przychodzi do tego, kto jest przygotowany i napotyka okazje.\" (Seneka)\n",
|
||||
"\n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Sześć magicznych składników użyteczności...\n",
|
||||
"...czyli sześć aspektów, pod którymi powinniśmy rozpatrywać użyteczność:\n",
|
||||
"* kontekst, \n",
|
||||
"* wprowadzanie danych, \n",
|
||||
"* wyprowadzanie danych, \n",
|
||||
"* responsywność, \n",
|
||||
"* dostęp do sieci, \n",
|
||||
"* zasoby."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Kontekst"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Kontekst</h3> \n",
|
||||
"\n",
|
||||
"Kontekst to środowisko i okoliczności używania aplikacji. Odpowiada na pytania:\n",
|
||||
"<ul>\n",
|
||||
"<li>Kto?\n",
|
||||
"<li>Gdzie?\n",
|
||||
"<li>Kiedy?\n",
|
||||
"<li>Jak? \n",
|
||||
"</ul>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Kto?\n",
|
||||
"\n",
|
||||
"ZASADY:\n",
|
||||
"\n",
|
||||
"1. Musisz precyzyjnie poznać użytkownika.\n",
|
||||
"2. To nie Ty jesteś użytkownikiem.\n",
|
||||
"3. Każdy jest inny.\n",
|
||||
"4. Użytkownik ma prawo robić coś innego\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.1. Musisz precyzyjnie poznać użytkownika\n",
|
||||
"\n",
|
||||
"* Dla kogo aplikacja będzie stanowić wartość?\n",
|
||||
" * Wskazówka: (patrz definicja wartości)\n",
|
||||
"* Kto dokładnie będzie użytkownikiem aplikacji?\n",
|
||||
" * Wskazówka: wykonaj diagram Venna\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/diagram Venna.png\" alt=\"Diagram Venna\" width=500px>\n",
|
||||
"(Przykładowy diagram Venna, Źródło: Matt Lacey, \"Postaw na użyteczność\")\n",
|
||||
"\n",
|
||||
"* Jakie są grupy użytkowników?\n",
|
||||
" * Wskazówka: metoda persony"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.2. To nie Ty jesteś użytkownikiem\n",
|
||||
" * Czym użytkownik różni się od siebie?\n",
|
||||
" * Czym mogą się rożnić oczekiwania innych uzytkowników od Twoich?\n",
|
||||
" * W stosunku do jakich niedociągnięć użytkownicy mogą być od Ciebie mniej pobłażliwi?\n",
|
||||
" * Dlaczego TY nie jesteś przeciętnym użytkownikiem Twojej aplikacji?\n",
|
||||
" * Jakie umiejętności Cię wyróżniają?\n",
|
||||
" * Dlaczego Tobie będzie łatwiej używać aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.3. Każdy jest inny\n",
|
||||
" * Czy użytkownicy aplikacji mogą się różnić w aspekcie dostępności?\n",
|
||||
" Na dostępność składają się:\n",
|
||||
" * umiejętności\n",
|
||||
" * wiedza\n",
|
||||
" * kultura\n",
|
||||
" * lokalizacja\n",
|
||||
" * płeć\n",
|
||||
" * wiek\n",
|
||||
" * niepełnosprawność\n",
|
||||
" * choroby (daltonizm)\n",
|
||||
" * Czy użytkownicy aplikacji mogą mieć od niej różne oczekiwania?\n",
|
||||
" * Czy użytkownicy aplikacji mogą chcieć uzyskać dzięki niej różne cele?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.1.4. Użytkownik ma prawo robić coś innego\n",
|
||||
" * Jakie inne działania będą podejmować użytkownicy podczas pracy z naszą aplikacją?\n",
|
||||
" * Jak się o tym dowiedzieć?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1. 2. Gdzie?\n",
|
||||
"ZASADA: \n",
|
||||
"Czy aplikacja będzie stosowana w różnych krajach?\n",
|
||||
" * Jesli nie, to pomiń dalsze pytania.\n",
|
||||
" * Jeśli tak, to odpowiedz na dalsze pytania.\n",
|
||||
"\n",
|
||||
"PYTANIA:\n",
|
||||
" * Czy zaplanowałeś wielojęzyczność aplikacji?\n",
|
||||
" * Jakimi językami posługują się użytkownicy w innych krajach?\n",
|
||||
" * Zaplanuj tłumaczenie aplikacji\n",
|
||||
" * Czy użytkownicy innych krajów stosują te same formaty liczb / dat?\n",
|
||||
" * Jeśli nie, to opracuj algorytmy konwersji"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Kiedy?\n",
|
||||
"### 1.3.1. Pora (dnia, tygodnia, miesiąca, roku)\n",
|
||||
"Czy aplikacja może działać w różny sposób w zależności od:\n",
|
||||
" * pory dnia\n",
|
||||
" * dnia tygodnia\n",
|
||||
" * dnia miesiąca\n",
|
||||
" * pory roku"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.3.2. Czas użytkowania\n",
|
||||
" * Jak długo trwa jedna sesja użytkowania?\n",
|
||||
" * daj możliwość korzystania nawet w bardzo krótkim czasie\n",
|
||||
" * Po jakim czasie użytkownik porzuci aplikację?\n",
|
||||
" * zachęcaj do pozostania z aplikacją"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.4. Jak?\n",
|
||||
"### 1.4.1. Okoliczności\n",
|
||||
" * Czy użytkownik jest w ruchu?\n",
|
||||
" * Czy użytkownik może wykonywać inne czynności?\n",
|
||||
" * Jakie?\n",
|
||||
" * Czy jest skupiony na naszej aplikacji?\n",
|
||||
" * Czy nasza aplikacja współpracuje z innymi?\n",
|
||||
" * W jakiej pozycji użytkownik korzysta z aplikacji?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 1.4.2. Urządzenia\n",
|
||||
" * Zasada WORE (Write Once Run Everywhere)\n",
|
||||
" * Plusy\n",
|
||||
" * szybciej powstaje\n",
|
||||
" * łatwiejsza w utrzymaniu\n",
|
||||
" * możliwość dostosowania dla wielu urządzeń\n",
|
||||
" * przydatna szczególnie w grach (niestandardowy UI)\n",
|
||||
" * Minusy\n",
|
||||
" * wymagana znajomość różnych platform\n",
|
||||
" * wymagana dyscyplina kodu\n",
|
||||
" * konieczność dostosowania elementów wizualnych do różnych platform\n",
|
||||
" * konieczność testowania na wielu platformach\n",
|
||||
" * Różne systemy operacyjne\n",
|
||||
" * W jakich systamach operacyjnych ma działać aplikacja?\n",
|
||||
" * Czy wziąłeś pod uwagę ograniczenia narzucane przez różne sklepy?\n",
|
||||
" * Czy wygląd aplikacji jest zgodny z przyzwyczajeniami użytkowników danego systemu?\n",
|
||||
"\n",
|
||||
" * Wielkość urządzenia\n",
|
||||
" * Czy wziąłeś pod uwagę, że wielkość ekranu ma wpływ na to, co jest wyświetlane?\n",
|
||||
" * Czy pomyślałeś, jak trzymane jest urządzenie?\n",
|
||||
" \n",
|
||||
" * Przyciski sprzętowe\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Czujniki\n",
|
||||
" * Czy przewidziałeś ich wykorzystanie?\n",
|
||||
" * Wskazówka: Współczesne urządzenia mogę mieć kilkanaście czujników:\n",
|
||||
" * ruchu\n",
|
||||
" * pozycji\n",
|
||||
" * położenia\n",
|
||||
" * środowiskowe "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2. Wprowadzanie danych (Input)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Input</h3> \n",
|
||||
"\n",
|
||||
"Information fed into a data processing system or computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Interakcja użytkownik - system\n",
|
||||
"### 2.1.1. Wejście dotykowe\n",
|
||||
" * Czy wziąłeś pod uwagę zalecane minimalne wielkości obszarów dotykowych?\n",
|
||||
" * iOS: 11 mm\n",
|
||||
" * Android: 7-10 mm\n",
|
||||
" * Windows: 7-9 mm\n",
|
||||
"\n",
|
||||
" * Czy gesty obsługiwane są standardowo?\n",
|
||||
" * pojedyncze dotknięcie\n",
|
||||
" * podwójne dotknięcie\n",
|
||||
" * przesunięcie palcem po ekranie\n",
|
||||
" * dotknięcie i przytrzymanie\n",
|
||||
" * uszczypnięcie / rozciąganie\n",
|
||||
" * obracanie\n",
|
||||
" * inne (powstające)\n",
|
||||
" \n",
|
||||
" * Czy pomyślałeś o tym, że podczas dotykania ekranu jego część będzie zasłonięta?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.2. Rysik\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wprowadzania danych za pomocą rysika?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.3. Mysz i klawiatura\n",
|
||||
"\n",
|
||||
" * Czy aplikacja będzie obługiwana myszą i / lub klawiaturą?\n",
|
||||
" * Jeśli myszą, to weź pod uwagę spójność dotyku i uzycia myszy:\n",
|
||||
" * pojedyncze dotknięcie - pojedyncze kliknięcie\n",
|
||||
" * podwójne dotknięcie - podwójne kliknięcie\n",
|
||||
" * prawy przycisk myszy - przytrzymanie\n",
|
||||
" * przesuwanie myszą - przesuwanie palcem\n",
|
||||
" * Jeśli klawiaturą, to weź pod uwagę standardową reakcję klawiszy:\n",
|
||||
" * Tab\n",
|
||||
" * Enter\n",
|
||||
" * Ctrl\n",
|
||||
" * Shift"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.1.4. Wejście głosowe\n",
|
||||
" * Czy wziąłeś pod uwagę możliwość wejścia głosowego?\n",
|
||||
" * Jeśli tak, to weź pod uwagę ograniczenia techniczne systemów rozpoznawania mowy (np. architektura: klient - serwer)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.2. Ułatwienia wprowadzania danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.1. Minimalizacja wysiłku użytkownika\n",
|
||||
" * Czy pomyślałeś o zminimalizowaniu wysiłku użytkownika przy wprowadzaniu danych?\n",
|
||||
" * Wskazówki:\n",
|
||||
" * proponowane wyboru zamiast ręcznego wprowadzania\n",
|
||||
" * skróty (szybki dostęp)\n",
|
||||
" * autosugestie (autouzupełnianie)\n",
|
||||
" * łączenie wprowadzania danych (np. daty przyjazdu / wyjazdu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.2. Optymalizacja formularzy\n",
|
||||
" * Czy w Twojej aplikacji dane są wprowadzane za pomocą formularzy? Jeśli tak, to odpowiedz na następujące pytania:\n",
|
||||
" * Czy dobrze posortowałeś listy wyboru?\n",
|
||||
" * Czy program reaguje już po części wpisanych danych?\n",
|
||||
" * Czy nad polami są ich etykiety?\n",
|
||||
" * Czy program podpowiada format danych?\n",
|
||||
" * Czy zapewniłeś wartości domyślne?\n",
|
||||
" * Czy pomyślałeś o walidacji danych?\n",
|
||||
" * Czy błędy pokazywane są w odpowiednim miejscu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.2.3. Altenatywne metody wprowadzania danych\n",
|
||||
" * Czy wziąłeś pod uwagę alternatywne metody wejścia?\n",
|
||||
" * wirtualna klawiatura\n",
|
||||
" * pismo ręczne\n",
|
||||
" * optyczne rozpoznawanie znaków\n",
|
||||
" * interaktywne mapy, pozwalające wskazać adres (lokalizację)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.3. Dane z innych źródeł"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Dane z innych źródeł</h3> \n",
|
||||
"\n",
|
||||
"Są to dane niewprowadzone przez użytkownika aplikacji.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.1. Dane z serwisów sieciowych\n",
|
||||
" * W jaki sposób nasza aplikacja może pozyskiwać informacje dane z serwisów sieciowych?\n",
|
||||
" * w formie odpowiedzi na żądanie\n",
|
||||
" * w formie powiadomień (notyfikacji)\n",
|
||||
" * w formie SMS-ów\n",
|
||||
" * Czy pomyślałeś o obsłudze komunikatów o błędach przesłanych z serwisów sieciowych?\n",
|
||||
" * Czy pomyślałeś o przetworzeniu przesłanych komunikatów (np. skróceniu ich, wyekstrahowaniu tego, co najważniejsze)?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.2. Dane z systemu operacyjnego\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane PIM (Personal Information Manager)?\n",
|
||||
" * wyszukiwanie danych teleadresowych\n",
|
||||
" * wyszukiwanie kontaktów\n",
|
||||
" * sprawdzanie poprawności wprowadzanych danych\n",
|
||||
" * korzystanie z osobistego kalendarza\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z systemu plików?\n",
|
||||
" * zdjęcia\n",
|
||||
" * filmy\n",
|
||||
" * teksty"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.3. Dane z innych aplikacji\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z innych aplikacji? \n",
|
||||
" * Jeśli tak, to w jaki sposób dane są współdzielone?\n",
|
||||
" * wspólne dane przechowywane lokalnie\n",
|
||||
" * natywne współdzielenie (wbudowany mechanizm współdzielenia danych)\n",
|
||||
" * formaty plików (typy MIME: Multipurpose Internet Mail Extensions)\n",
|
||||
" * metoda \"kopiuj i wklej\""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.4. Dane z czujników\n",
|
||||
" * Czy nasza aplikacja wykorzystuje dane z czujników? \n",
|
||||
" * Jeśli tak, to czy zadbałeś o to, aby\n",
|
||||
" * zapytać użytkownika o uprawnienia\n",
|
||||
" * wyjaśnić, w jaki sposób aplikacja będzie korzystać z czuujników\n",
|
||||
" * wyjaśnić, do czego dane te są potrzebne\n",
|
||||
" * wspomnieć o kwestiach polityki prywatności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 2.3.5. Inne typy wprowadzania danych\n",
|
||||
" * Czy istnieją jeszcze inne metody, w jaki aplikacja może pozyskać dane?\n",
|
||||
" * np. karta z chipem"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Wyprowadzanie danych (wyjście)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Output</h3> \n",
|
||||
"\n",
|
||||
"Information produced by a computer (słownik: Miriam - Webster)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Wyjście wizualne"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Zasady projektowania wizualnych komponentów wyprowadzania danych:</h3> \n",
|
||||
" \n",
|
||||
"<ol>\n",
|
||||
"<li> \"Cele użytkownika na pierwszym miejscu.\"\n",
|
||||
"<li> Spełnianie oczekiwań użytkowników\n",
|
||||
"<li> Uwzględnianie rodzaju urządzenia\n",
|
||||
"<li> Przestrzeganie norm i konwencji\n",
|
||||
"</ol>\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Wyjście niewizualne\n",
|
||||
" * Czy wziąłeś pod uwagę możliwości wyprowadzania danych w inny sposób niż wizualnie?\n",
|
||||
" * dźwięki i wibracje\n",
|
||||
" * kanały komunikacji dla innych aplikacji\n",
|
||||
" * powiadomienia \"push\"\n",
|
||||
" * poczta elektroniczna\n",
|
||||
" * SMS"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Responsywność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Responsywność</h3> \n",
|
||||
"\n",
|
||||
"Cecha aplikacji, która powoduje, że użytkownicy uważają, że mogą uzyskać swój cel szybko - bez straty czasu.\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Responsywność aplikacji to nie to samo co responsive design.**\n",
|
||||
"> Responsive design oznacza, że to co jest wyświetlane w danym momencie w aplikacji, dostosowuje się do zmieniającej się wielkości ekranu. \n",
|
||||
"> Pojęcie responsywności jest dużo szersze: aplikacja powinna reagować nie tylko na wielkość ekranu, lecz na akcje użytkownika i działania aplikacji. Szybkość i sposób, w jaki aplikacja odpowiada, przekłada się na doświadczenia użytkownika."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Dostęp do sieci\n",
|
||||
" * Czy wziąłeś pod uwagę potencjalne problemy z dostępem do sieci:\n",
|
||||
" * szybkość połączenia może się różnić\n",
|
||||
" * koszt połączenia może być zmienny\n",
|
||||
" * połączenie może być niedostępne\n",
|
||||
" * połączenie może być utracone"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 6. Zasoby"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Resource</h3> \n",
|
||||
"\n",
|
||||
"A source of supply, support, or aid, especially one that can be readily drawn upon when needed (www. dictionary.com)\n",
|
||||
" \n",
|
||||
"<div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" > A gdy się zasoby skończą, to ich nie będzie.\n",
|
||||
" \n",
|
||||
"Ilość zasobów jest skończona, więc naszym obowiązkiem jest je oszczędzać:\n",
|
||||
"\n",
|
||||
" * Energia\n",
|
||||
" * Pojemność dysku\n",
|
||||
" * Pojemność pamięci\n",
|
||||
" * Zasoby procesora\n",
|
||||
" * Możliwości przesyłu danych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
"Użyteczność często rozumiana jest jako synonim łatwości użytkowania aplikacji.\n",
|
||||
"\n",
|
||||
"Zapewnienie, aby aplikacja używana była **łatwo**, nie jest zadaniem banalnym. Wymaga zadania wielu pytań, na które odpowiedzi mogą być zupełnie różne w zależności od typu aplikacji."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "11. Aspekty użyteczności[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,626 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 12. Ocena jakości systemu informatycznego</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Czym jest jakość produktu?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Toma de Marco</h3> \n",
|
||||
" \n",
|
||||
"Jakość produktu to funkcja tego, jak bardzo zmienia on świat na lepsze.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Geralda Weinberga</h3> \n",
|
||||
" \n",
|
||||
"Jakość to subiektywnie pojmowana wartość.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Josepha Jurana</h3> \n",
|
||||
" \n",
|
||||
"1. Jakość składa się z tych cech produktu, które spełniają potrzeby klientów i dostarczają im satysfakcji. \n",
|
||||
"2. Jakość to brak braków.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Armanda Feigenbauma</h3> \n",
|
||||
" \n",
|
||||
"Jakość to coś, co określa tylko i wyłącznie klient - a nie inżynier, dział marketiingu, czy też kierownictwo.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Definicja wg Williama Edwardsa Deminga</h3> \n",
|
||||
" \n",
|
||||
"Cała trudność w zdefiniowaniu jakości polega na przełożeniu przyszłych potrzeb użytkownika na wymierne cechy w taki sposób, aby produkt dawał klientowi satysfakcję za akceptowalną cenę.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Definicja jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Jakość oprogramowania</h3> \n",
|
||||
" \n",
|
||||
"<b> Jakość oprogramowania </b> to funkcja wypadkowa wartości określonych właściwości oprogramowania.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 2.1. Proces określania jakości oprogramowania\n",
|
||||
"Proces określenia jakości oprogramowania składa się z dwóch etapów:\n",
|
||||
"1. Zdefiniowanie funkcji jakości oprogramowania:\n",
|
||||
"\n",
|
||||
" > 1. Określ właściwości istotne dla danego typu oprogramowania (np. rozmiar, funkcjonalność, użyteczności, dostępność).\n",
|
||||
" > 2. Dla każdej włąsciwości zdefiniuj zakres wartości liczbowych lub kategorii, określających, w jakim stopniu spełnia ona oczekiwania użytkowników.\n",
|
||||
" > 3. Zdefiniuj jakość oprogramowania jako funkcję wartości poszczególnych właściwości: \n",
|
||||
" > **Quality = q(wartości właściwości)**\n",
|
||||
" \n",
|
||||
"2. Ocena jakości oprogramowania\n",
|
||||
" > 1. Wyznacz wartości poszczególnych cech oprogramowania.\n",
|
||||
" > 2. Oblicz jakość oprogramowania za pomocą zdefiniowanej funkcji *Quality*."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Jakość kodu źródłowego\n",
|
||||
"Cechy kodu żródłowego:\n",
|
||||
" * rozmiar,\n",
|
||||
" * złożoność"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Metryki rozmiaru kodu źródłowego\n",
|
||||
"\n",
|
||||
"### 3.1.1. Liczba wierszy (LOC - Lines of Code)\n",
|
||||
"LOC mierzy **liczbę wierszy** w metodzie, klasie lub całej aplikacji.\n",
|
||||
"\n",
|
||||
"W obliczaniu LOC trzeba podjąć kilka nieoczywistych decyzji.\n",
|
||||
"\n",
|
||||
"Przykłady:\n",
|
||||
"\n",
|
||||
"<table>\n",
|
||||
" <caption> Jak mierzyć liczbę wierszy w metryce LOC </caption> \n",
|
||||
"<tr> \n",
|
||||
" <td> Decyzja </td> <td> Rekomendacja </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> Czy liczyć puste wiersze?</td> <td> NIE </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> Czy liczyć komentarze?</td> <td> NIE </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> Czy liczyć liczbę wierszy czy liczbę instrukcji?</td> <td> Liczbę wierszy </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Reguła 30</h3> \n",
|
||||
" \n",
|
||||
"Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"> **Methods** should not have more than an average of 30 code lines (not counting line spaces and comments). \n",
|
||||
"> **A class** should contain an average of less than 30 methods, resulting in up to 900 lines of code. \n",
|
||||
"> **A package** shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines. \n",
|
||||
"> **Subsystems** with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code. \n",
|
||||
"> **A system** with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines. \n",
|
||||
"[Przeczytaj w Internecie](https://dzone.com/articles/rule-30-%E2%80%93-when-method-class-or)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1.2. Punkty funkcyjne\n",
|
||||
"\n",
|
||||
"**Punkty Funkcyjne** - metryka, która wyznacza liczbę funkcjonalności dostarczaną przez system.\n",
|
||||
"\n",
|
||||
"**Współczynnik produktywności języka programowania**: ile (średnio) linii kodu potrzeba do zakodowania jednego punktu funkcyjnego? \n",
|
||||
"\n",
|
||||
"Wartość kodu w punktach funkcyjnych wyznacza się, dzieląc wartośćLOC przez współczynnik produktywności.\n",
|
||||
"\n",
|
||||
"**Tablica produktywności języków programowania**\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/LOC vs FP.jpg\" alt=\"Tablica produktywności\" width=500px>\n",
|
||||
"<figcaption> Tablica produktywności. Źródło: Adam Roman, \"Testowanie i jakość oprogramowania\" </figcaption> \n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"[Porównaj w Internecie](https://www.qsm.com/resources/function-point-languages-table)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.1.3. Liczba tokenów - metryka Halsteada\n",
|
||||
"\n",
|
||||
"Metryka Halsteada wyznacza objętość (wielkość) kodu na podstawie liczby unikatowych tokenów.\n",
|
||||
"Wyróżniane są dwa typy tokenów:\n",
|
||||
" * operatory (funkcje, słowa kluczowe itp.),\n",
|
||||
" * operandy (zmienne, stałe, wartości).\n",
|
||||
" \n",
|
||||
"Wartości metryk Halsteada (w przeciwieństwie do LOC) nie zależą od długości przyjętego nazewnictwa.\n",
|
||||
"\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead1.png\" alt=\"Liczby tokenów\" width=300px>\n",
|
||||
"<figcaption> Liczby tokenów. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:\n",
|
||||
"\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead2.png\" alt=\"wielkość programu\" width=300px>\n",
|
||||
"<figcaption> Objętość programu. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.2. Metryki oceny złożoności kodu źródłowego "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.1. Metryki złożoności Halsteada\n",
|
||||
"Złożoność programu szacowana jest pod kilkoma aspektami - na podstawie liczby tokenów:\n",
|
||||
" * D: trudność implementacji,\n",
|
||||
" * L: poziom programu (im wyższy tym program jest mniej podatny na błędy),\n",
|
||||
" * E: wysiłek implementacji,\n",
|
||||
" * T: czas implementacji\n",
|
||||
" * B: liczba błędów.\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/Halstead3.png\" alt=\"metryki złożoności Halsteada\" width=100px>\n",
|
||||
"<figcaption> Metryki złożoności Halsteada. Źródło: wikipedia </figcaption> \n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.2. Złożoność cyklomatyczna\n",
|
||||
"**Złożoność cyklomatyczna** określa liczbę niezależnych ścieżek przebiegu programu. \n",
|
||||
"\n",
|
||||
"Jeśli program reprezentowany jest w postaci schematu blokowego (grafu), to:\n",
|
||||
"\n",
|
||||
"> CC = e - n + 2 * p \n",
|
||||
"> e – liczba krawędzi grafu \n",
|
||||
"> n – liczba węzłów grafu \n",
|
||||
"> p – liczba składowych grafu \n",
|
||||
"\n",
|
||||
"Złożoność cykolmatyczną można łatwo wyliczyć na podstawie wzoru:\n",
|
||||
"\n",
|
||||
"> CC = d + 1, gdzie d oznacza liczbę węzłów decyzyjnych, np. instrukcji: \n",
|
||||
"> * if \n",
|
||||
"> * while \n",
|
||||
"> * for \n",
|
||||
"> * case"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.3. Uśrednione metody na klasę (Weighted Methods per Class - WMC)\n",
|
||||
"\n",
|
||||
"Metryka uwzględnia zarówno liczbę metod w klasie, jak i ich złożoność cyklomatyczną: (n oznacza liczbę metod w klasie, a c<sub>i</sub> oznacza złożoność cykolomatyczną i-tej metody).\n",
|
||||
"\n",
|
||||
"<img src=\"obrazy/WMC.png\" alt=\"Uśrednione metody na klasę \" width=150px>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2.4. Odpowiedzialność klasy (Response for a Class - RFC)\n",
|
||||
"\n",
|
||||
"Metryka RFC oznacza całkowitą liczbę metod, które mogą być potencjalnie wywołane w odpowiedzi na komunikat odebrany przez obiekt klasy. \n",
|
||||
"\n",
|
||||
"Wysoka wartość RFC oznacza większą funkcjonalność, ale zarazem i wyższą złożoność."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 4. Właściwości produktu wpływające na ocenę jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.1. Przydatność funkcjonalna (Functional Suitability - F)\n",
|
||||
"**Przydatność funkcjonalna** określa stopień, w jakim program dostarcza oczekiwane funkcjonalności.\n",
|
||||
"\n",
|
||||
"Wartość przydatności funkcjonalnej można wyznaczyć podczas testowania:\n",
|
||||
"\n",
|
||||
"> **M = 1 - A/B**\n",
|
||||
"> * A = funkcjonalności problemowe \n",
|
||||
"> * B = wszystkie testowane funkcjonalności"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.2. Niezawodność\n",
|
||||
"\n",
|
||||
"**Niezawodność** określa prawdopodobieństwo, że wykonanie operacji przez program będzie bezbłędne.\n",
|
||||
"\n",
|
||||
"Wartość niezawodności można wyznaczyć podczas testowania:\n",
|
||||
"\n",
|
||||
"> **M = A/B** \n",
|
||||
"> * A = liczba testów ukończonych pomyślnie, \n",
|
||||
"> * B = liczba wszystkich testów"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.3. Użyteczność (Usability - U)\n",
|
||||
"\n",
|
||||
"**Użyteczność** określa łatwość użytkowania.\n",
|
||||
"\n",
|
||||
"Wartość użyteczności można wyznaczyć podczas testów użyteczności:\n",
|
||||
"\n",
|
||||
"> **M = A/B**\n",
|
||||
"> * A = liczba funkcjonalności odkryta przez użytkownika, \n",
|
||||
"> * B = liczba wszystkich funkcjonalości."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.4. Wydajność (Performance Efficiency)\n",
|
||||
"**Wydajność** określa liczbę wykonanych operacji w odniesieniu do czasu i zużytych zasobów.\n",
|
||||
"\n",
|
||||
"Przykładowe metryki pomiaru wydajności:\n",
|
||||
"\n",
|
||||
"> * Czas odpowiedzi: **M = T1 (end) - T2 (start)** \n",
|
||||
"> * Czas postoju: **M = T1 (waiting time) / T2 (total time)**\n",
|
||||
"> * Przepustowość = Liczba zadań wykonanych w jednostce czasu \n",
|
||||
"> * Zużycie pamięci (w bajtach) "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.5. Łatwość konserwacji (Maintainability - M)\n",
|
||||
"**Łatwość konserwacji** to łatwość, z jaką program jest utrzymywany w celu:\n",
|
||||
" * poprawiania błędów,\n",
|
||||
" * wprowadzania nowych funkcji.\n",
|
||||
"\n",
|
||||
"Przykładowa metryka: Ile czasu zajmuje średnio naprawienie błędu?\n",
|
||||
"\n",
|
||||
"> **M = SUM(czas naprawy) / N** \n",
|
||||
"> * N oznacza liczbę napraw"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.6. Przenośność (Portability - P)\n",
|
||||
"**Przenośność** to Łatwość przenoszenia systemu pomiędzy różnymi środowiskami platformami / systemami operacyjnymi. \n",
|
||||
"\n",
|
||||
"Przykładowe metryki:\n",
|
||||
" * łatwość adaptacji\n",
|
||||
" > **M = T** \n",
|
||||
" > * T oznacza czas adaptacji do nowego środowiska\n",
|
||||
"\n",
|
||||
" * łatwość instalacji: \n",
|
||||
" > **M = A / B**\n",
|
||||
" > * A = przypadki pomyślnej instalacji \n",
|
||||
" > * B = wszystkie przypadki instalacji "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.7. Dostępność (Availibility - A)\n",
|
||||
"**Dostępność** to czas, w którym program zobowiązany jest odpowiadać zgodnie z oczekiwaniami.\n",
|
||||
"\n",
|
||||
"* Metryka:\n",
|
||||
"\n",
|
||||
"> **M = A / B**\n",
|
||||
"> * A = Czas dostępności \n",
|
||||
"> * B = Czas całkowity \n",
|
||||
"\n",
|
||||
"* Przykładowe wartości metryki dostępności:\n",
|
||||
"\n",
|
||||
"<table>\n",
|
||||
" <caption> Wartości metryki dostępności </caption>\n",
|
||||
"<tr> \n",
|
||||
" <td> Miara dostępności </td> <td> Czas niedostępności w roku </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,999 </td> <td> 5 minut 20 sekund </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 99,8</td> <td> 17 godzin 30 minut </td>\n",
|
||||
"</tr>\n",
|
||||
"<tr>\n",
|
||||
" <td> 97,5 </td> <td> 219 godzin </td>\n",
|
||||
"</tr>\n",
|
||||
"</table>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.8. Kompatybilność (Compatibility)\n",
|
||||
"**Kompatybilność** to możliwość współpracowania z systemami zewnętrznymi."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 4.9. Bezpieczeństwo (Security - S)\n",
|
||||
"**Bezpieczeństwo** to możliwość chronienia danych przetwarzanych przez aplikację.\n",
|
||||
"\n",
|
||||
"* Przykładowa metryka:\n",
|
||||
"\n",
|
||||
"> **M = A / B** \n",
|
||||
"> * A = Liczba przetestowanych funkcji programu uznanych jako bezpieczne\n",
|
||||
"> * B = Liczba wszystkich przetestowanych funkcji "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 5. Schematy oceny jakości\n",
|
||||
"\n",
|
||||
"Aby ocenić jakość oprogramowania należy wybrać właściwości oprogramowania, które wchodzą w skład oceny. Służą do tego **schematy oceny jakości**.\n",
|
||||
"\n",
|
||||
"## 5.1. CUMPRIMDSO (schamat wprowadzony przez IBM)\n",
|
||||
"* Capability (odpowiednik przydatności funkcjonalnej)\n",
|
||||
"* Usability (użyteczność)\n",
|
||||
"* Performance – wydajność\n",
|
||||
"* Reliability – niezawodność\n",
|
||||
"* Installability – łatwość instalacji\n",
|
||||
"* Maintainibility – łatwość utrzymania (pielęgnowalność)\n",
|
||||
"* Documentation – dokumentacja\n",
|
||||
"* Service – serwis\n",
|
||||
"* Overall - ocena ogólna\n",
|
||||
"\n",
|
||||
"## 5.2. CUMPRIMDA\n",
|
||||
"* Capability (odpowiednik przydatności funkcjonalnej)\n",
|
||||
"* Usability (użyteczność)\n",
|
||||
"* Performance – wydajność\n",
|
||||
"* Reliability – niezawodność\n",
|
||||
"* Installability – łatwość instalacji\n",
|
||||
"* Maintainibility – łatwość utrzymania (pielęgnowalność)\n",
|
||||
"* Documentation – dokumentacja\n",
|
||||
"* Availibility - dostępność\n",
|
||||
"\n",
|
||||
"## 5.3. FURPS (schemat wprowadzony przez Hewlett-Packard)\n",
|
||||
"* Functionality\n",
|
||||
"* Usability\n",
|
||||
"* Reliability\n",
|
||||
"* Performance\n",
|
||||
"* Supportability – łatwość wspierania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 6. Funkcja oceny jakości oprogramowania"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.1. Pojęcie korelacji\n",
|
||||
"\n",
|
||||
"**Korelacja** to miara zależności pomiędzy dwoma zmiennymi (cechami).\n",
|
||||
"\n",
|
||||
"Korelacja przyjmuje wartości z przedziału [-1, 1]. \n",
|
||||
"* korealacja > 0 → korelacja dodatnia\n",
|
||||
" * gdy wartości jednej cechy rosną, to drugiej również rosną.\n",
|
||||
"* r < 0 → korelacja ujemna\n",
|
||||
" * gdy wartości jednej cechy rosną, to drugiej maleją i odwrotnie\n",
|
||||
"* r = 0 → korelacja zerowa\n",
|
||||
" * brak związku między cechami.\n",
|
||||
" \n",
|
||||
"Przykłady korelacji: \n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/korelacja.png\" alt=\"korelacja Pearsona\" width=600px>\n",
|
||||
" <figcaption>źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.2. Korelacja między właściwościami oprogramowania\n",
|
||||
"Korelację między poszczególnymi właściwościami oprogramowania obrazuje tabela:\n",
|
||||
"\n",
|
||||
"<figure>\n",
|
||||
"<img src=\"obrazy/korelacja właściwości.png\" alt=\"Korelacja między właściwościomi oprogramowania\" width=600px>\n",
|
||||
" <figcaption> Korelacje między właściwościami oprogramowania źródło: opracowanie własne na podstawie: Stephen H. Kan \"Metryki i modele w inżynierii jakości oprogramowania\"</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"Tabela wskazuje, że polepszenie jednej cechy oprogramowania (np. przydatności funkcjonalnej) może pogorszyć inną cechę (np. wydajność), bo cechy te są ujemnie skorelowane."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.3. Waga właściwości oprogramowania\n",
|
||||
"Istotność poszczególnych właściwości oprogramowania zależy od typu programu.\n",
|
||||
"\n",
|
||||
"Stephen H. Kan (\"Metryki i modele w inżynierii jakości oprogramowania\") podaje, że dla metryki UPRIMDA najbardziej odpowiednie kolejności właściwości są następujące: \n",
|
||||
"* RUIPMDA\n",
|
||||
"* RUAIMPD"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 6.4. Wzór na ocenę jakości oprogramowania\n",
|
||||
"\n",
|
||||
"Procedura opracowania wzoru na ocenę jakości oprogramowania odpowiedniego dla danego typu programu:\n",
|
||||
"\n",
|
||||
"> 1. Wybierz schemat (np. FURPS) \n",
|
||||
"> \n",
|
||||
"> 2. Zdefiniuj typ funkcji (np. funkcja liniowa) \n",
|
||||
"> **Quality = a + b*F + c*U +d*R + e*P + f*S** \n",
|
||||
"> \n",
|
||||
"> 3. Zdefiniuj współczynniki tak, by korelacja z oceną ludzką była jak najwyższa."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Przykładowy proces dostrajania współczynników jakości\n",
|
||||
"\n",
|
||||
"> 1. Zorganizuj grupę użytkowników (co najmniej 5 osób). \n",
|
||||
"> 2. Zbierz od użytkowników oceny poszczególnych właściwości oprogramowania. \n",
|
||||
"> 3. Zbierz od użytkowników oceny ogólne jakości. \n",
|
||||
"> 4. Określ heurystycznie wartości współczynników we wzorze na ocenę ogolną. \n",
|
||||
"> 5. Oblicz współczynnik korelacji między:\n",
|
||||
"> * ocenami ogólnymi jakości podanymi przez użytkowników, \n",
|
||||
"> * ocenami ogólnymi jakości wyznaczonymi przez wzór na oceną ogólną na podstawie ocen cząstkowych użytkownikow.\n",
|
||||
"> 6. Jeśli korelacja jest niska, to powróć do punktu 4."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Podsumowanie\n",
|
||||
" * Istnieje wiele definicji jakości programowania.\n",
|
||||
" * Na wykładzie zdefiniowano jakość jako funkcję poszczególnych właściwości oprogramowania.\n",
|
||||
"\n",
|
||||
"* Istnieją metryki oceny **kodu źrodłowego**. \n",
|
||||
" * Na ich podstawie można ocenić jakość kodu.\n",
|
||||
" \n",
|
||||
" * Jakość oprogramowania można oceniać również z punktu widzenia klienta. \n",
|
||||
" * Stosowane są różne schematy oceny, które biorą pod uwagę różne właściwości oprogramowania.\n",
|
||||
" \n",
|
||||
" * Ocenę ogólną oprogramowania (z punktu widzenia klienta) można zdefiniować jako **funkcję liniową** ocen poszczególnych właściwości."
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "12. Ocena jakości systemu informatycznego[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,739 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 13. <i>Planowanie prac badawczo-rozwojowych</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Harmonogram projektu</h3> \n",
|
||||
" \n",
|
||||
"Harmonogram projektu to plan uzyskania celów projektu uwzględniający:\n",
|
||||
"<ul>\n",
|
||||
" <li> podział pracy na etapy i zadania,</li>\n",
|
||||
" <li> przydział zasobów do zadań,</li>\n",
|
||||
" <li> terminy wykonania zadań.</li>\n",
|
||||
"</ul>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 1. Zasady planowania harmonogramu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.1. Bierz pod uwagę ograniczenia"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Ograniczenia</h3> \n",
|
||||
" \n",
|
||||
"Ograniczenia to czynniki, które wpływają na realizację harmonogramu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Rodzaje ograniczeń:\n",
|
||||
"Wyróżniamy następujace typy ograniczeń:\n",
|
||||
" * Ograniczenia czasowe\n",
|
||||
" * Ograniczenia techniczne\n",
|
||||
" * Ograniczenia organizacyjne "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia czasowe\n",
|
||||
"**Ograniczenie czasowe** to ramy czasowe, w których musi się zmieścić projekt lub jego etap.\n",
|
||||
"\n",
|
||||
"* Rodzaje ograniczeń czasowych:\n",
|
||||
" * Nie wcześniej niż,\n",
|
||||
" * Nie później niż,\n",
|
||||
" * W konkretnym dniu.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń czasowych:\n",
|
||||
" * wykonanie pewnego zadania jest uwarunkowane ukończeniem innego zadania,\n",
|
||||
" * projekt ma być zakończony w określonym terminie.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczaniami czasowymi?\n",
|
||||
" * Ustawiać zależności między zadaniami\n",
|
||||
" * Ustawiać hamronogram \"od końca\"."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia techniczne\n",
|
||||
"**Ograniczenie techniczne** to ograniczenia wynikające z przyczyn zewnętrznych, niezależnych od zespołu projektowego.\n",
|
||||
"\n",
|
||||
"* Przykłady ograniczeń technicznych:\n",
|
||||
" * termin dostawy sprzętu,\n",
|
||||
" * załamanie pogody,\n",
|
||||
" * pandemia,\n",
|
||||
" * współpraca z podmiotami zewnętrznymi.\n",
|
||||
" \n",
|
||||
"* Wskazówki: jak radzić sobie z ograniczeniami technicznymi?\n",
|
||||
"\n",
|
||||
" * Ustawiać zależność ZR (Zakończenie Rozpoczęcie) dla zadań zależnych od innych przedsiębiorstw,\n",
|
||||
" * Dodawać do zadań odstępy czasowe,\n",
|
||||
" * Dodawać rezerwę kierowniczą."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### Ograniczenia organizacyjne\n",
|
||||
"**Ograniczenia organizacyjne** to ograniczenia wynikające z zależności pomiędzy kilkoma projektami realizowanymi:\n",
|
||||
" * w jednym zespole,\n",
|
||||
" * przez daną osobę, \n",
|
||||
" * z wykorzystaniem tych samych zasobów.\n",
|
||||
"\n",
|
||||
" * Wskazówki: jak radzić sobie z ograniczeniami organizacyjnymi?\n",
|
||||
" * Odpowiednio zarządzać zasobami: technicznymi i ludzkimi,\n",
|
||||
" * Współdzielić zasoby między projektami,\n",
|
||||
" * Ustawiać indywidualne czasy pracy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.2. Zarządzaj zapasem czasu"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zapas czasu</h3> \n",
|
||||
" \n",
|
||||
"<b> Zapas czasu </b> to czas, o który może opóźnić się realizacja zadania, nie wpływając na termin ukończenia projektu.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
" \n",
|
||||
"<h3>Ścieżka krytyczna</h3> \n",
|
||||
" \n",
|
||||
"<b> Ścieżka krytyczna </b> to sekwencja zadań od rozpoczęcia do zakończenia projektu, której czas przejścia jest najdłuższy.\n",
|
||||
"\n",
|
||||
"Zadania na ścieżce krytycznej mają zerowy zapas czasu.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ścieżka krytyczna.png\" alt=\"Przykład ścieżki krytycznej\" width=500px>\n",
|
||||
"<figcaption> Przykład ścieżki krytycznej </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"**Zarządzanie zapasem czasu** może polegać na:\n",
|
||||
"\n",
|
||||
" * dodawaniu zapasu czasu do zadań obarczonych ryzykiem,\n",
|
||||
" * dodawaniu zapasu czasu z powodów ograniczeń technicznych lub organizacyjnych, \n",
|
||||
" * zmniejszaniu zapasu czasu (dla zadań leżących poza ścieżką krytyczną),\n",
|
||||
" * analizie (i ew. modyfikacji) zadań leżących na ścieżce krytycznej."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 1.3. Zarządzaj rezerwą kierowniczą\n",
|
||||
"**Rezerwa kierownicza** to fikcyjne zadanie dodane na końcu siatki zadań. Czas na jego realizację to około 10-15% czasu całego projektu.\n",
|
||||
" * Rezerwę kierowniczą dodajemy po stworzeniu całości harmonogramu.\n",
|
||||
" * Tworząc rezerwę pomocniczą, pamiętaj o prawie Parkinsona."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Prawo Parkinsona</h3> \n",
|
||||
" \n",
|
||||
"Praca będzie się rozrastać, aby wypełnić cały czas na nią przewidziany.\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/prawo Parkinsona.png\" alt=\"Prawo Parkinsona\" width=500px>\n",
|
||||
"<figcaption> Prawo Parkinsona, źródło: https://www.timeflies.us/blog/what-is-parkinson-s-law-and-how-it-can-make-you-more-productive</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 2. Struktura podziału pracy"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Struktura Podziału Pracy</h3> \n",
|
||||
" \n",
|
||||
"Struktura Podziału Pracy to hierarchiczna reprezentacja podziału pracy w projekcie.\n",
|
||||
"\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
" * Wykonanie prac w projekcie podzielone jest na **etapy**. \n",
|
||||
" * Etap jest częścią projektu, która musi być dokończona przed zaczęciem następnej. Etap składa się z **zadań**.\n",
|
||||
" * Zadania mogą być wykonywane równolegle.\n",
|
||||
" * Zadania mogą zostać podzielone na **podzadania**. \n",
|
||||
" \n",
|
||||
" * Elementy Struktury Podziału Pracy a efekty pracy: \n",
|
||||
" * Etap – efekt jest widoczny dla klienta,\n",
|
||||
" * Zadanie – efekt jest widoczny dla kierownika,\n",
|
||||
" * Podzadanie – efekt jest widoczny dla programisty.\n",
|
||||
" \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/SPP.jfif\" alt=\"Struktura Podziału Pracy\" width=600px>\n",
|
||||
"<figcaption> Struktura Podziału Pracy, źródło: http://pm2pm.pl/slownik-project-managera-wbs/</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-info alert-success\">\n",
|
||||
"<h3>Zasada 8 - 80</h3>\n",
|
||||
"Wykonanie najmniejszej jednostki harmonogramu powinno zajmować między 8 a 80 godzin.\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# 3. Tworzenie harmonogramu w programie MS-Project"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 3.1. Ustawienie daty początku projektu\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie daty.png\" alt=\"Ustawienie daty\" width=300px>\n",
|
||||
"<figcaption> Ustawienie daty początku projektu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.2. Stworzenie Struktury Podziału Pracy\n",
|
||||
"\n",
|
||||
"W nomenklaturze MS Project wyróżniamy:\t\n",
|
||||
" * zadania sumaryczne (odpowiednik Etapu),\n",
|
||||
" * zadania,\n",
|
||||
" * podzadania. \n",
|
||||
"\n",
|
||||
"#### Wskazówka \n",
|
||||
"Ustawiaj hierarchię zadań poprzez tworzenie wcięć w zadaniach podrzędnych.\n",
|
||||
"\n",
|
||||
"<br> </br> \n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/stworzenie SPP.png\" alt=\"Stworzenie SPP\" width=300px>\n",
|
||||
"<figcaption> Stworzenie SPP</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.3. Ustawienie trybów zadań\n",
|
||||
"\n",
|
||||
"* Tryb ręczny (oznaczony przez pineskę) stosujemy dla zadania, gdy chcemy mieć pełną kontrolę nad jego czasem trwania.\n",
|
||||
"* Tryb automatyczny wykonuje ważną jednak pracę wspomagającą - przesuwa na osi czasu zadania, które są od siebie zależne.\n",
|
||||
"\n",
|
||||
"Stosowanie trybu automatycznego oznacza, że brana jest pod uwagę wskazówka: \"Bierz pod uwagę ograniczenia czasowe\". \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/tryby zadań.png\" alt=\"Ustawianie trybów zadań\" width=500px>\n",
|
||||
"<figcaption> Ustawianie trybów zadań</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.4. Określenie punktów kontrolnych"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Punkt kontrolny</h3> \n",
|
||||
" \n",
|
||||
"<b>Punkt kontrolny</b> (ang. milestone) – punkt na osi czasu, który podsumowuje określony zestaw zadań, bądź daną fazę projektu.\n",
|
||||
"<ul>\n",
|
||||
" <li> Może to być: podpisanie dokumentu, otrzymanie wyniku, ważne spotkanie, zatwierdzenie pracy itp.\n",
|
||||
" <li> Zazwyczaj osiągnięcie punktu kontrolnego wiąże się z dalszymi decyzjami odnośnie rozwoju projektu.\n",
|
||||
" <li> Punkt kontrolny ma zerowy czas trwania.\n",
|
||||
" <li> Pojęcie punktu kontrolnego zastąpiło pojęcie kamienia milowego.\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/ustawienie punktu kontrolnego.png\" alt=\"Ustawianie punktu kontrolnego\" width=900px>\n",
|
||||
"<figcaption> Ustawianie punktu kontrolnego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/punkt kontrolny.png\" alt=\"Punkt kontrolny w MS-Project\" width=500px>\n",
|
||||
"<figcaption> Oznaczenie punktu kontrolnego w MS-Project</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.5. Określenie tygodniowego kalendarza czasu pracy dla zespołu\n",
|
||||
"\n",
|
||||
"Tygodniowy plan pracy dla zespołu obowiązuje tych członków zespołu, dla których nie określono planu indywidualnego. \n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 1.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - przycisk</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy 2.png\" alt=\"Ustawianie czasu pracy dla zespołu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie czasu pracy dla zespołu - kalendarz</figcaption>\n",
|
||||
"</figure>\n",
|
||||
" "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.6. Modyfikacja diagramu Gantta"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Diagram Gantta</h3> \n",
|
||||
" \n",
|
||||
"<b> Diagram Gantta </b> to graficzny sposób reprezentacji harmonogramu, w którym uwzględnia się podział projektu na \n",
|
||||
"poszczególne zadania, oraz rozplanowanie ich w czasie.\n",
|
||||
"\n",
|
||||
"<br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/diagram Gantta.png\" alt=\"diagram Gantta\" width=500px>\n",
|
||||
"<figcaption> Przykładowy diagram Gantta, źródło: https://kierownikprojektu.com/2020/06/11/16-zalet-wykresu-gantta/ </figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<h4> Zalety wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> przedstawia następstwo zdarzeń, </li>\n",
|
||||
"<li> uwzględnia zadania wykonywane równolegle, </li>\n",
|
||||
"<li> dobrze sprawdza się dla niewielkich projektów. </li>\n",
|
||||
"</ul>\n",
|
||||
"\n",
|
||||
"<h4> Wady wykresu Gantta </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> nie zawiera szczegółowych opisów zadań, </li>\n",
|
||||
"<li> wymusza podanie konkretnych dat. </li>\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Diagram Gantta w MS-Project\n",
|
||||
"\n",
|
||||
"Diagram Gantta tworzony jest częściowo manualne, a częściowo automatycznie.\n",
|
||||
"\n",
|
||||
" * Czas trwania zadania można wpisać ręcznie w kolumnie **czas trwania** (w godzinach, dniach).\n",
|
||||
" * W czasie trwania zadania uwzględniane są tylko dni robocze – zgodnie z kalendarzem.\n",
|
||||
" * Jeśli wpiszemy czasy rozpoczęcia i zakończenia, to czas trwania oblicza się sam. Analogicznie sam oblicza się koniec zadania o znanym rozpoczęciu i czasie trwania.\n",
|
||||
" * Dni wolne od pracy są zaznaczone kolorem szarym."
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.7. Ustawienie zależności między zadaniami"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zależności między zadaniami</h3> \n",
|
||||
" \n",
|
||||
"Zadanie B jest <b>zależne</b> od A, gdy zmiana terminu wykonania A wpływa na termin wykonania B. Zadanie A nazywamy <b>poprzednikiem</b>, a B – <b>następnikiem </b>. \n",
|
||||
" \n",
|
||||
"<h4> Typy zależności </h4>\n",
|
||||
"<ul>\n",
|
||||
"<li> Zadania typu ZR (zakończenie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RR (rozpoczęcie-rozpoczęcie). Następnik (B) może się rozpocząć dopiero po rozpoczęciu poprzednika(A).\n",
|
||||
"<li> Zadania typu ZZ (zakończenie-zakończenie). Następnik (B) może się zakończyć dopiero po zakończeniu poprzednika (A).\n",
|
||||
"<li> Zadania typu RZ (rozpoczęcie-zakończenie). Następnik (B) może się zakończyć dopiero po rozpoczęciu poprzednika (A).\n",
|
||||
"</ul>\n",
|
||||
"</div>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Ustawianie zależności między zadaniami w MS-Project\n",
|
||||
"\n",
|
||||
" * Aby określić zadania zależne, należy zaznaczyć dwa zadania i połączyć je (ikoną węzła).\n",
|
||||
" * Aby zmienić typ zależności między zadaniami, należy kliknąć na strzałeczkę łączącą zadania na wykresie Gantta.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zależności.png\" alt=\"Ustawianie zależności między zadaniami\" width=500px>\n",
|
||||
"<figcaption> Ustawianie zależności między zadaniami</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.8. Ustawienie odstępów między zadaniami\n",
|
||||
"Pomiędzy zadaniami zależnymi można ustawić odstęp czasowy (tzw. zwłokę). Pełni on rolę bufora – aby zapewnić zakończenie zadania przed rozpoczęciem następnego.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odstęp czasowy.png\" alt=\"Ustawianie odstępów czasowych\" width=500px>\n",
|
||||
"<figcaption> Ustawianie odstępów czasowych</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 3.9 Określenie zasobów w projekcie"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"<h3>Zasoby </h3> \n",
|
||||
" \n",
|
||||
"<b>Zasoby (ang. resources) </b> – wszystko, co jest potrzebne do wykonania projektu, a czego brak spowodowałby niewykonanie planu. \n",
|
||||
"W MS-Project wyróżniamy następujące typy zasobów:\n",
|
||||
"<ul>\n",
|
||||
"<li> Praca (ludzie lub komputery),\n",
|
||||
"<li> Materiał (np. energia),\n",
|
||||
"<li> Koszt (np. koszt podróży).\n",
|
||||
"</ul>\n",
|
||||
"</div> "
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"#### Zdefiniowanie zasobów w MS-Project\n",
|
||||
"\n",
|
||||
"Prawidłowe określenie wszystkich zasobów niezbędnych w projekcie umożliwia prawidłowe oszacowanie kosztów projektu.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 1.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=400px>\n",
|
||||
"<figcaption> Definiowanie zasobów - arkusz zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zasoby 2.png\" alt=\"Zdefiniowanie zasobów w MS-Project\" width=800px>\n",
|
||||
"<figcaption> Definiowanie zasobów - dane zasobów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 10. Ustawienie tygodniowego kalendarza czasu pracy dla poszczególnych osób (zasobów)\n",
|
||||
"\n",
|
||||
"W programie MS-Project możliwe jest zindywidualizowanie czasu pracy każdej osoby - lub ogólniej - dowolnego zasobu. \n",
|
||||
"\n",
|
||||
"Wykres Gantta reprezentujący harmonogram pracy dostosowuje się do czasu pracy zasobów. Na przykład wykonanie zadania szacowanego na 16 godzin przez osobę, która pracuje 8 godzin w tygodniu, będzie zajmowało dwa tygodnie w harmonogramie.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu.png\" alt=\"Czas pracy zasobu\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - wybranie zasobu</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/czas pracy zasobu 2.png\" alt=\"Czas pracy zasobu 2\" width=500px>\n",
|
||||
"<figcaption> Ustawianie indywidualnego czasu pracy - zmiana tygodniowego planu pracy</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 11. Przydzielenie zasobów do zadań\n",
|
||||
"Do kazego zadania powinny być przydzielone zasoby niezbędne do jego wykonania (w tym zasoby ludzkie). \n",
|
||||
"\n",
|
||||
" * Można przydzielić całość lub część zasobu do danego zadania (np. 50%). Będzie to oznaczało, że zasób jest zaangażowany w to zadanie tylko w określonym procencie swojego czasu.\n",
|
||||
" * Do jednego zadania można przydzielić kilka zasobów (np. osób).\n",
|
||||
" * Zasób (np. osoba) może być jednocześnie przypisany do kilku zadań.\n",
|
||||
" \n",
|
||||
" <br> </br>\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przydzielanie zasobów.png\" alt=\"Przydzielanie zasobów do zadań\" width=500px>\n",
|
||||
"<figcaption> Przydzielanie zasobów do zadań</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 12. Sprawdzenie poprawności alokacji zasobów\n",
|
||||
"\n",
|
||||
"* Skoro zasób może być jednocześnie przypisany do kilku zadań, to można popełnić błąd, nadmiernie przeciążając zasób, tak że musiałby pracować więcej niż to wynika z jego kalendarza.\n",
|
||||
"\n",
|
||||
" * Obciążenie zasobów można sprawdzić następująco:\n",
|
||||
"\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 1.png\" alt=\"Sprawdzenie przeciążenia zasobów\" width=400px>\n",
|
||||
"<figcaption> Sprawdzenie przeciążenia zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/przeciążenie zasobów 2.png\" alt=\"Zasoby z nadmierną alokacją pracy\" width=800px>\n",
|
||||
"<figcaption> Zasoby z nadmierną alokacją pracy (zasoby przeciążone) - przykład</figcaption>\n",
|
||||
"</figure>\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 13. Wyeliminowanie przeciążeń zasobów\n",
|
||||
"\n",
|
||||
"Nadmierną alokację (przeciążenie) zasobów należy eliminować. Można to zrobić na dwa sposoby:\n",
|
||||
" * manualne odciążanie zasobów,\n",
|
||||
" * automatyczne bilansowanie zasobów.\n",
|
||||
" \n",
|
||||
"Manualne odciążanie zasobów może polegać na zmniejszeniu zaangażowania danego zasobu w zadanie:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/odciążanie ręczne.png\" alt=\"Odciążanie ręczne\" width=500px>\n",
|
||||
"<figcaption> Zmniejszenie zaangażowania zasobu w zadanie</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Automatyczne bilansowanie zasobu wykonywane jest przez MS-Porject na żądanie użytkownika.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/automatyczne bilansowanie zasobów.png\" alt=\"automatyczne bilansowanie zasobów\" width=500px>\n",
|
||||
"<figcaption>Automatyczne bilansowanie zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"Efekt bilansowania może spowodować przesunięcie pracy w czasie, a co za tym idzie, opóźnienie realizacji projektu:\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 1.png\" alt=\"obciążenie zasobu przez bilansowaniem\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu przez bilansowaniem</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/bilansowanie automatyczne 2.png\" alt=\"obciążenie zasobu po bilansowaniu\" width=400px>\n",
|
||||
"<figcaption>Obciążenie zasobu po bilansowaniu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 14. Analiza ścieżki krytycznej\n",
|
||||
"\n",
|
||||
"Zadania leżące na ścieżce krytycznej nazywne są **zadaniami krytycznymi**.\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/zadania krytyczne.png\" alt=\"ścieżka krytyczne\" width=600px>\n",
|
||||
"<figcaption>Ścieżka krytyczna - przykład</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"W wyniku analizy ścieżki krytycznej można przykładowo:\n",
|
||||
" * zmienić zależności między zadaniami na ścieżce krytycznej (może to przyspieszyć realizację planu)\n",
|
||||
" * zwiększyć zapasy czasu dla zadań krytycznych (zwiększając bezpieczeństwo kosztem czasu)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 15. Generowanie raportów\n",
|
||||
"MS-Project umożliwia generowanie różnego typu raportów. Umożliwiają one m.in:\n",
|
||||
" * obliczenie kosztów projektu,\n",
|
||||
" * wyznaczenie, jaki procent planu jest wykonany,\n",
|
||||
" * obliczenie zaangażowania poszczególnych osób w projekt,\n",
|
||||
" \n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport całościowy.png\" alt=\"raport całościowy\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu całościowego</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport zasobów.png\" alt=\"raport zasobów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu zasobów</figcaption>\n",
|
||||
"</figure>\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/raport kosztów.png\" alt=\"raport kosztów\" width=600px>\n",
|
||||
"<figcaption>Przykład raportu kosztów</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"### 16. Poprawianie harmonogramu (czyli co robić, gdy harmonogram się „nie spina”)\n",
|
||||
"\n",
|
||||
"Następujące działania mogą pomóc w poprawieniu harmonogramu\n",
|
||||
"\n",
|
||||
"<br> </br>\n",
|
||||
"<figure> \n",
|
||||
"<img src=\"obrazy/modyfikacja planu.png\" alt=\"modyfikacja planu\" width=600px>\n",
|
||||
"<figcaption>Metody poprawiania harmonogramu</figcaption>\n",
|
||||
"</figure>"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# Wnioski\n",
|
||||
" * Zarządzanie projektem jest procesem zindywidualizowanym\n",
|
||||
" * Gdyby tak nie było, to MS Project składałby się tylko z jednego przycisku "
|
||||
]
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"author": "Krzysztof Jassem",
|
||||
"email": "jassem@amu.edu.pl",
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"lang": "pl",
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.8.5"
|
||||
},
|
||||
"subtitle": "13. Planowanie prac badawczo-rozwojowych[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,87 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 14. Zarządzanie projektami badawczo-rozowjowymi</i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Produkuj hamburgery, sprzedawaj hamburgery...\n",
|
||||
"## ... czyli czym różni się zarządzanie projektem B+R od kierowania barem szybkiej obsługi\n",
|
||||
"Różnice w zarządzaniu można zobrazować w kilku aspektach:\n",
|
||||
" * Podejście do popełniania błędów przez pracowników\n",
|
||||
" * Sposób motywowania: bodźce negatywne i pozytywne\n",
|
||||
" * Podejście do indywidualistów\n",
|
||||
" * Podejście do kreatywności i samodoskonalenia się pracowników"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Czy ludzie pracują lepiej pod presją?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Prawo Parkinsona - mit czy rzeczywistość?"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## 7 syrenich śpiewów...\n",
|
||||
"## ...czyli o pokusach w zarządzaniu, które prowadzą na manowce"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Jakie czynniki faktycznie wpływają na lepszą pracę informatykó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": "14. Zarządzanie pracami badawczo-rozwojowymi[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,54 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"\n",
|
||||
"<div class=\"alert alert-block alert-info\">\n",
|
||||
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||||
"<h2> 15. <i>Demonstracja wyników projektu badawczo-rozwojowego </i>[wykład]</h2> \n",
|
||||
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||||
"</div>\n",
|
||||
"\n",
|
||||
""
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<div class=\"alert alert-block alert-success\">\n",
|
||||
"Demonstrowane projekty powinny być na 6. poziomie gotowości technologicznej.\n",
|
||||
"</div>"
|
||||
]
|
||||
}
|
||||
],
|
||||
"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": "15. Demonstracja projektu[wykład]",
|
||||
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||||
"year": "2021"
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
@ -1,114 +0,0 @@
|
||||
{
|
||||
"cells": [
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": 3,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": [
|
||||
"#procedura napisywania plików ipynb (generowanie nagłówka i metadanych)\n",
|
||||
"import json\n",
|
||||
"\n",
|
||||
"def modjup(filen,numer,tytul,typ,author,email,lang,title,year):\n",
|
||||
" zerocell=['\\n',\n",
|
||||
" '<div class=\"alert alert-block alert-info\">\\n', \n",
|
||||
" '<h1> %s </h1>\\n'%(title),\n",
|
||||
" '<h2> %s. <i>%s</i> [%s]</h2> \\n'%(numer,tytul,typ),\n",
|
||||
" '<h3> %s (%s)</h3>\\n'%(author,year),\n",
|
||||
" '</div>\\n',\n",
|
||||
" '\\n',\n",
|
||||
" '']\n",
|
||||
" zerodict={'cell_type': 'markdown','metadata': {'collapsed': False},'source': zerocell}\n",
|
||||
" with open(filen, 'r+') as f:\n",
|
||||
" ll=json.load(f)\n",
|
||||
" ll[\"metadata\"][\"author\"]=author\n",
|
||||
" ll[\"metadata\"][\"email\"]=email\n",
|
||||
" ll[\"metadata\"][\"lang\"]=lang\n",
|
||||
" subtitle=\"%s.%s[%s]\"%(numer,tytul,typ)\n",
|
||||
" ll[\"metadata\"][\"subtitle\"]=subtitle\n",
|
||||
" ll[\"metadata\"][\"title\"]=title\n",
|
||||
" ll[\"metadata\"][\"year\"]=year\n",
|
||||
" \n",
|
||||
" if not(ll['cells'][0]['source'][0]==zerocell[0]):\n",
|
||||
" ll['cells'].insert(0,zerodict)\n",
|
||||
" else:\n",
|
||||
" ll['cells'][0]=zerodict\n",
|
||||
" f.seek(0)\n",
|
||||
" json.dump(ll,f,indent=4)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": 7,
|
||||
"metadata": {},
|
||||
"outputs": [
|
||||
{
|
||||
"ename": "UnicodeDecodeError",
|
||||
"evalue": "'charmap' codec can't decode byte 0x81 in position 8350: character maps to <undefined>",
|
||||
"output_type": "error",
|
||||
"traceback": [
|
||||
"\u001b[1;31m---------------------------------------------------------------------------\u001b[0m",
|
||||
"\u001b[1;31mUnicodeDecodeError\u001b[0m Traceback (most recent call last)",
|
||||
"\u001b[1;32m<ipython-input-7-dc51dba53985>\u001b[0m in \u001b[0;36m<module>\u001b[1;34m\u001b[0m\n\u001b[0;32m 13\u001b[0m \u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 14\u001b[0m \u001b[1;31m#uruchom procedurę\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[1;32m---> 15\u001b[1;33m \u001b[0mmodjup\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mfilen\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mnumer\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mtytul\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mtyp\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mauthor\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0memail\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mlang\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mtitle\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0myear\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m",
|
||||
"\u001b[1;32m<ipython-input-3-2ca9011d1935>\u001b[0m in \u001b[0;36mmodjup\u001b[1;34m(filen, numer, tytul, typ, author, email, lang, title, year)\u001b[0m\n\u001b[0;32m 13\u001b[0m \u001b[0mzerodict\u001b[0m\u001b[1;33m=\u001b[0m\u001b[1;33m{\u001b[0m\u001b[1;34m'cell_type'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[1;34m'markdown'\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;34m'metadata'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[1;33m{\u001b[0m\u001b[1;34m'collapsed'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[1;32mFalse\u001b[0m\u001b[1;33m}\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;34m'source'\u001b[0m\u001b[1;33m:\u001b[0m \u001b[0mzerocell\u001b[0m\u001b[1;33m}\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 14\u001b[0m \u001b[1;32mwith\u001b[0m \u001b[0mopen\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mfilen\u001b[0m\u001b[1;33m,\u001b[0m \u001b[1;34m'r+'\u001b[0m\u001b[1;33m)\u001b[0m \u001b[1;32mas\u001b[0m \u001b[0mf\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[1;32m---> 15\u001b[1;33m \u001b[0mll\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mjson\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mload\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mf\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m\u001b[0;32m 16\u001b[0m \u001b[0mll\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"metadata\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"author\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mauthor\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 17\u001b[0m \u001b[0mll\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"metadata\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;34m\"email\"\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0memail\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n",
|
||||
"\u001b[1;32m~\\anaconda3\\lib\\json\\__init__.py\u001b[0m in \u001b[0;36mload\u001b[1;34m(fp, cls, object_hook, parse_float, parse_int, parse_constant, object_pairs_hook, **kw)\u001b[0m\n\u001b[0;32m 291\u001b[0m \u001b[0mkwarg\u001b[0m\u001b[1;33m;\u001b[0m \u001b[0motherwise\u001b[0m\u001b[0;31m \u001b[0m\u001b[0;31m`\u001b[0m\u001b[0;31m`\u001b[0m\u001b[0mJSONDecoder\u001b[0m\u001b[0;31m`\u001b[0m\u001b[0;31m`\u001b[0m \u001b[1;32mis\u001b[0m \u001b[0mused\u001b[0m\u001b[1;33m.\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 292\u001b[0m \"\"\"\n\u001b[1;32m--> 293\u001b[1;33m return loads(fp.read(),\n\u001b[0m\u001b[0;32m 294\u001b[0m \u001b[0mcls\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mcls\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0mobject_hook\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mobject_hook\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 295\u001b[0m \u001b[0mparse_float\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mparse_float\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0mparse_int\u001b[0m\u001b[1;33m=\u001b[0m\u001b[0mparse_int\u001b[0m\u001b[1;33m,\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n",
|
||||
"\u001b[1;32m~\\anaconda3\\lib\\encodings\\cp1250.py\u001b[0m in \u001b[0;36mdecode\u001b[1;34m(self, input, final)\u001b[0m\n\u001b[0;32m 21\u001b[0m \u001b[1;32mclass\u001b[0m \u001b[0mIncrementalDecoder\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mcodecs\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mIncrementalDecoder\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 22\u001b[0m \u001b[1;32mdef\u001b[0m \u001b[0mdecode\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mself\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0minput\u001b[0m\u001b[1;33m,\u001b[0m \u001b[0mfinal\u001b[0m\u001b[1;33m=\u001b[0m\u001b[1;32mFalse\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[1;32m---> 23\u001b[1;33m \u001b[1;32mreturn\u001b[0m \u001b[0mcodecs\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mcharmap_decode\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0minput\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mself\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0merrors\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mdecoding_table\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m[\u001b[0m\u001b[1;36m0\u001b[0m\u001b[1;33m]\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m\u001b[0;32m 24\u001b[0m \u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0;32m 25\u001b[0m \u001b[1;32mclass\u001b[0m \u001b[0mStreamWriter\u001b[0m\u001b[1;33m(\u001b[0m\u001b[0mCodec\u001b[0m\u001b[1;33m,\u001b[0m\u001b[0mcodecs\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mStreamWriter\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m:\u001b[0m\u001b[1;33m\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n",
|
||||
"\u001b[1;31mUnicodeDecodeError\u001b[0m: 'charmap' codec can't decode byte 0x81 in position 8350: character maps to <undefined>"
|
||||
]
|
||||
}
|
||||
],
|
||||
"source": [
|
||||
"#zmodyfikuj te dane\n",
|
||||
"filen=\"01_praca_zespolowa.ipynb\"\n",
|
||||
"\n",
|
||||
"numer=\"1\"\n",
|
||||
"tytul=\"\"\n",
|
||||
"typ=\"wyklad\"\n",
|
||||
"\n",
|
||||
"author=\"Krzysztof Jassem\"\n",
|
||||
"email=\"jassem@amu.edu.pl\"\n",
|
||||
"lang= \"pl\"\n",
|
||||
"title=\"\"\n",
|
||||
"year=\"2021\"\n",
|
||||
"\n",
|
||||
"#uruchom procedurę\n",
|
||||
"modjup(filen,numer,tytul,typ,author,email,lang,title,year)"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"kernelspec": {
|
||||
"display_name": "Python 3",
|
||||
"language": "python",
|
||||
"name": "python3"
|
||||
},
|
||||
"language_info": {
|
||||
"codemirror_mode": {
|
||||
"name": "ipython",
|
||||
"version": 3
|
||||
},
|
||||
"file_extension": ".py",
|
||||
"mimetype": "text/x-python",
|
||||
"name": "python",
|
||||
"nbconvert_exporter": "python",
|
||||
"pygments_lexer": "ipython3",
|
||||
"version": "3.7.6"
|
||||
}
|
||||
},
|
||||
"nbformat": 4,
|
||||
"nbformat_minor": 4
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 175 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 180 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.5 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 2.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 612 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 6.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 110 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 467 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.8 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user