\n",
- "\n"
- ]
- }
- ],
- "metadata": {
- "author": "Krzysztof Jassem",
- "email": "jassem@amu.edu.pl",
- "kernelspec": {
- "display_name": "Python 3 (ipykernel)",
- "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.10.10"
- },
- "subtitle": "06. Prototypowanie i ciagła integracja[laboratorium]",
- "title": "Projekt badawczo-rozwojowy",
- "year": "2021"
- },
- "nbformat": 4,
- "nbformat_minor": 4
-}
diff --git a/materiały na laboratorium/03_ewaluacja_systemów_analizy_danych_lab.ipynb b/materiały na laboratorium/03_ewaluacja_systemów_analizy_danych_lab.ipynb
new file mode 100644
index 0000000..6f9ba88
--- /dev/null
+++ b/materiały na laboratorium/03_ewaluacja_systemów_analizy_danych_lab.ipynb
@@ -0,0 +1,76 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Systemy informatyczne analizy danych
\n",
+ " 3. Ewalucja systemów analizy danych[laboratorium]
\n",
+ "Krzysztof Jassem (2024)
\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Cel laboratorium\n",
+ "Zapoznanie studentów z systemem AmuEval.\n",
+ "\n",
+ "## Zadanie 1. Utworzenie wyzwania\n",
+ "Utworzyć nowe wyzwanie na platformie AmuEval. Jako dane uczące i testowe do wyzwania mogą posłużyć podzbiory podane tutaj: https://git.wmi.amu.edu.pl/jassem/SysInf/src/branch/master/Tematy%20projekt%C3%B3w_2023.ipynb)\n",
+ "Wskazane jest zdefiniowanie więcej niż jednej metryki ewaluacji.\n",
+ "Dla wyzwania należy zamieścić rozwiązanie bazowe.\n",
+ "W odpowiedzi na zadanie proszę podać:\n",
+ " Nazwę wyzwania\n",
+ " Opis wyzwania, w tym uzasadnienie wyboru metryk.\n",
+ "\n",
+ "(10 pkt)\n",
+ "\n",
+ "## Zadanie 2. Zgłoszenie rozwiązania\n",
+ "Zgłosić rozwiązanie do istniejącego zadania na AmuEval - innego niż własne.\n",
+ "Wskazane jest zgłoszenie rozwiązania do zadania opracowanego przez inną grupę, ale możliwe jest również zgłoszenie do zadania już istniejącego na AmuEval.\n",
+ "\n",
+ "Jako rozwiązanie należy podać:\n",
+ " identyfikator zgłaszającego rozwiązanie na AmuEval\n",
+ " omówienie metryki stosownej w wyzwaniu (wykazanie jej zasadności dla zadania lub krytykę wyboru)\n",
+ "analizę swojego wyniku.\n",
+ "\n",
+ "(10 pkt)\n",
+ "\n",
+ "## Zadanie 3. Konkluzje z burzy mózgów\n",
+ "Wyprowadzić wnioski z burzy mózgów przeprowadzonej na Lab 2. Wynikiem zadania ma być lista pomysłów ograniczona do nie więcej niż trzech przykładów. Dla omawianych przykładów wskazać ich silne i słabe strony. Szczególną uwagę zwrócić na oryginalność (wyjątkowość) planowanego projektu.\n",
+ "\n",
+ "(10 pkt)"
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3 (ipykernel)",
+ "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.9.13"
+ },
+ "subtitle": "06. Prototypowanie i ciagła integracja[laboratorium]",
+ "title": "Projekt badawczo-rozwojowy",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na laboratorium/04_zaawansowane_platformy_analizy_danych_lab.ipynb b/materiały na laboratorium/04_zaawansowane_platformy_analizy_danych_lab.ipynb
new file mode 100644
index 0000000..791f025
--- /dev/null
+++ b/materiały na laboratorium/04_zaawansowane_platformy_analizy_danych_lab.ipynb
@@ -0,0 +1,73 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ " Systemy informatyczne analizy danych
\n",
+ " 4. Zaawansowane platformy analizy danych[laboratorium]
\n",
+ "Filip Graliński (2024)
\n",
+ "\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Cel laboratorium\n",
+ "Celem laboratorium jest zapoznanie studentów z narzędziem Snowflake, które udostępnia przyjzany interfejs do analizy dużych zbiorów danych.\n",
+ "\n",
+ "## Zadanie 1. Zapoznanie się z platformą Snowflake\n",
+ "Załóż konto w Snowflake'u, bazę, schemat (scheme), co najmniej dwie tabelę, stage z co najmniej jednym plikiem. Załaduj dane do bazy (np. poprzez stage). Przeprowadź 2-3 proste analizy danych używając worksheet SQL albo notatnika Pythonowego.\n",
+ "\n",
+ "Najlepiej, żeby dane były jakoś powiązane z rozpatrywanym/planowanym pomysłem na projekt.\n",
+ "\n",
+ "(10 pkt)\n",
+ "\n",
+ "## Zadanie 2. Aplikacja w Streamlit\n",
+ "Napisz aplikację używając Streamlit in Snowflake. Najlepiej, żeby stanowiła ona prosty prototyp rozpatrywanego pomysłu na projekt albo chociaż w jakiś sposób nawiązywała do niego.\n",
+ "\n",
+ "Wymagania:\n",
+ " korzystanie z danych w bazie danych\n",
+ " użytkownik ma możliwość wpisania / podjęcia jakiejś akcji (nie może to być prosty statyczny dashboard)\n",
+ " powinna zawierać przynjamniej jeden wykres\n",
+ " wykorzystanie jakiejś funkcji Cortex (np. TRANSLATE, COMPLETE itp.)\n",
+ " \n",
+ "(15 pkt)\n",
+ "\n",
+ "## Zadanie 3. Snowflake - wrażenia\n",
+ "\n",
+ "Napisz krótki dokument omawiający, co - subiektywnie - zniechęca / zachęca cię do używania Snowflake'a.\n",
+ "\n",
+ "(5 pkt)\n"
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3 (ipykernel)",
+ "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.9.13"
+ },
+ "subtitle": "02. Prezentacja koncepcji projektu badawczo-rozwojowego[laboratorium]",
+ "title": "Projekt badawczo-rozwojowy",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na laboratorium/05_prototypowanie_GIT_lab.ipynb b/materiały na laboratorium/05_prototypowanie_GIT_lab.ipynb
new file mode 100644
index 0000000..7ce1731
--- /dev/null
+++ b/materiały na laboratorium/05_prototypowanie_GIT_lab.ipynb
@@ -0,0 +1,72 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ " Systemy informatyczne analizy danych
\n",
+ " 5. Prototypowanie i GIT[laboratorium]
\n",
+ "Krzysztof Jassem, Filip Graliński(2024)
\n",
+ "\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Cel laboratorium\n",
+ "Celem laboratorium jest przybliżenie metody prototypowania za pomocą makiety dynamicznej oraz zapoznanie z systemem kontroli wersji GIT.\n",
+ "\n",
+ "## Zadanie 1. Prototyp aplikacji\n",
+ "Przeprowadźcie dyskusję co do planowanego typu prototypowania podczas zajęć: 1) prototypowanie z porzuceniem czy ewolucyjne 2) prototypowanie poziome czy pionowe. Zapiszcie wynik dyskusji (2 pkt).\n",
+ "\n",
+ "Opracujcie pierwszy prototyp Waszej aplikacji, czyli dynamiczną makietę, która reprezentuje wybrany widok Waszej aplikacji. Dynamicznosć makiety ma polegać na tym, że kliknięcie w niektóre elementy spowoduje wykonanie jakiejś akcji (8 pkt) \n",
+ "\n",
+ "(10 pkt)\n",
+ "\n",
+ "## Zadanie 2. Ćwiczenia z GITa\n",
+ "Utwórzcie repozytorium na wydziałowym Gicie dla Waszego projektu. Repozytorium powinno wstępnie zawierać wyłącznie krótki plik tekstowy readme (max 1 zdanie). Repozytorium powinno być prywatne, ale przy tym dostępne dla prowadzących zajęcia (4 pkt).\n",
+ "\n",
+ "Sklonujcie repozytorium dla każdego członka grupy (2 pkt) (efekt tego zadanie będzie sprawdzalny, jeśli każda osoba z grupy dokona podczas dalszych ćwiczeń przynajmniej jednego wypchnięcia do repozytorium).\n",
+ "\n",
+ "Podzielcie się zadaniami:\n",
+ " * modyfikacja na swoim komputerze pliku readme, aby plik ten zawierał opis projektu i wypchnięcie nowego opisu do repozytorium (2 pkt)\n",
+ " * utworzenie nowej gałęzi o nazwie \"mockups\" i umieszczenie w niej pliku makiety dynamicznej stworzonej w zadaniu 1. (2 pkt)\n",
+ " * dowolna modyfikacja pliku makiety dynamicznej i wypchnięcie zmiany przez innego członka grupy niż wykonującego polecenie poprzednie (2 pkt)\n",
+ " * stworzenie minimalnego kodu źródłowego związanego z zadaniem (np. implementującego widok z makiety dynamicznej bez logiki aplikacji; kod musi się poprawnie kompilować) i wypchnięcie go do repozytorium (5 pkt)\n",
+ " * dowolna modyfikacja kodu źródłowego przez innego autora (kod musi się poprawnie kompilować) i wypchnięcie zmian do repozytorium (3 pkt)\n",
+ "\n",
+ "(Zadanie może jeszcze ulec zmianom przed zajęciami).\n",
+ "\n",
+ "(20 pkt)"
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3 (ipykernel)",
+ "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.9.13"
+ },
+ "subtitle": "02. Prezentacja koncepcji projektu badawczo-rozwojowego[laboratorium]",
+ "title": "Projekt badawczo-rozwojowy",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na laboratorium/05_innowacyjny projekt informatyczny_lab.ipynb b/materiały na laboratorium/prototypowanie_GIT_lab.ipynb
similarity index 100%
rename from materiały na laboratorium/05_innowacyjny projekt informatyczny_lab.ipynb
rename to materiały na laboratorium/prototypowanie_GIT_lab.ipynb
diff --git a/materiały na laboratorium/04_systemy_analizy_danych_lab.ipynb b/materiały na wykład/.ipynb_checkpoints/02_badania CBK-checkpoint.ipynb
similarity index 61%
rename from materiały na laboratorium/04_systemy_analizy_danych_lab.ipynb
rename to materiały na wykład/.ipynb_checkpoints/02_badania CBK-checkpoint.ipynb
index ebf5333..92c0a20 100644
--- a/materiały na laboratorium/04_systemy_analizy_danych_lab.ipynb
+++ b/materiały na wykład/.ipynb_checkpoints/02_badania CBK-checkpoint.ipynb
@@ -4,20 +4,18 @@
"cell_type": "markdown",
"metadata": {},
"source": [
+ "\n",
"
Systemy informatyczne analizy danych
\n",
- " 4. Systemy analizy danych[wykład]
\n",
- "Krzysztof Jassem (2023)
\n",
- "\n"
+ " 2. Projekty Centrum Badań Kosmicznych[wykład]
\n",
+ "Tomasz Zawistowski (2024)
\n",
+ ""
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "# Cel laboratorium\n",
- "Laboratorium się nie odbyło z powodu godzin dziekańskich.\n",
- "\n",
- "Można wykorzystać dodatkowy tydzień na opracowanie nowej, lepszej wersji systemu do wyceny mieszkań."
+ "Materiały z wykładu dostępne są wyłącznie na grupie zajęciowej w Teamsach."
]
}
],
@@ -42,8 +40,8 @@
"pygments_lexer": "ipython3",
"version": "3.9.13"
},
- "subtitle": "02. Prezentacja koncepcji projektu badawczo-rozwojowego[laboratorium]",
- "title": "Projekt badawczo-rozwojowy",
+ "subtitle": "01. Praca zespołowa[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
"year": "2021"
},
"nbformat": 4,
diff --git a/materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb
index 144e1eb..c95aebd 100644
--- a/materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb
+++ b/materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb
@@ -6,8 +6,8 @@
"source": [
"\n",
"
Systemy informatyczne analizy danych
\n",
- " 3. Ciągła integracja i ciągła ewaluacja[wykład]
\n",
- "Filip Graliński, Krzysztof Jassem (2023)
\n",
+ " 3. Ewaluacja systemów analizy danych[wykład]
\n",
+ " Krzysztof Jassem (2024)
\n",
""
]
},
@@ -15,241 +15,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "\n",
- " \n",
- "
Ciągła integracja
\n",
- " \n",
- "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
- "
\n",
- " - zmiany w kodzie są regularnie przesyłane do centralnego repozytorium,
\n",
- " - po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Główne przesłanki CI
\n",
- " \n",
- "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
- "
\n",
- " - szybsze lokalizowanie błędów w kodzie,
\n",
- " - ciągły wzrost jakości oporgramowania,
\n",
- " - szybkie wydawanie nowych wersji.
\n",
- "
\n",
- "
\n",
- "\n",
- " \n",
- "\n"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Przebieg pracy w Ciągłej Integracji\n",
- "1. **Take Integrated Code**\n",
- " * Pobieram kod z repozytorium.\n",
- " * Instaluję kopię na swojej stacji roboczej. \n",
- " \n",
- "2. **Do Your Part**\n",
- " * Opracowuję nowy kod.\n",
- " * Opracowuję nowe testy jednostkowe.\n",
- " \n",
- "3. **Build on your machine**\n",
- "\n",
- " * **Repeat** \n",
- " * Kompiluję swój kod i buduję wersję wykonywalną,\n",
- " * Przeprowadzam testy jednostkowe,\n",
- " * **Until**\n",
- " * Kod się skompilował poprawnie oraz\n",
- " * Testy zakończyły się powodzeniem.\n",
- " \n",
- "4. **Integrate with Repository**\n",
- "\n",
- " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n",
- " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n",
- " * **Go back to: Take Integrated Code**\n",
- " * Przypadek 2. Tetsy się powodzą\n",
- " * **Continue**\n",
- " \n",
- "5. **End Session**\n",
- " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Dobre praktyki Ciągłej Integracji\n",
- "(wg https://www.martinfowler.com/articles/continuousIntegration.html)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Maintain a Single Source Repository\n",
- " * Załóż mainline (linię główną): \n",
- " * Deweloperzy powinni większość pracy składać na mainline.\n",
- " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n",
- " * naprawy błędów,\n",
- " * tymczasowych eksperymentów,\n",
- " * oznaczania wersji publikowalnych.\n"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Automate the Build\n",
- " * Wersja wykonywalna powinna być tworzona jednym poleceniem.\n",
- " * Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Test Yourself\n",
- " * Pisz testy jednostkowe.\n",
- " * Uruchamiaj testy po każdej kompilacji."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Everyone Commits Everyday\n",
- " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n",
- " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n",
- " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n",
- " * Postulat wymaga rozbicia projektu na małe kawałki."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Every Commit Should Build the Mainline\n",
- " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n",
- " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Fix the Broken Builds Immediately\n",
- "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n",
- "Znalezienie i poprawienie blędu jest priorytetem, ale:\n",
- " * Nie debugguj kodu na centralnym repozytorium. \n",
- " * Przywróć wersję wykonywalną na \"mainline\".\n",
- " * Debugguj kod na maszynie lokalnej."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Make it Easy to Run the Latest Executable\n",
- "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n",
- "* Jest to niezbędne do:\n",
- " * testowania integracyjnego (tester),\n",
- " * rozmów z klientem (zarząd lub sprzedawca),\n",
- " * prowadzenia projektu (kierownik zespołu).\n",
- "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Keep the Build Fast\n",
- "\n",
- " * Maximum 10 minut na build + testy.\n",
- " * A jeśli testy trwają dłużej?\n",
- " * Testy dwuetapowe:\n",
- " * kompilacja + testy jednostkowe przy każdym commicie,\n",
- " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Clone the Environment\n",
- " * Przygotuj klon środowiska produkcyjnego:\n",
- " * ta sama wersja systemu operacyjnego\n",
- " * ta sama baza danych\n",
- " * te same biblioteki (nawet jak ich nie potrzebujesz) \n",
- " * Wszystkie testy przeprowadzaj na przygotowanym środowisku."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Everyone Can See What's Happening\n",
- "System powinien informować użytkowników o swoim statusie."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Automate Deployment\n",
- " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n",
- " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". "
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Narzędzia Ciągłej Integracji\n",
- "\n",
- "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n",
- "\n",
- "1. Jenkins\n",
- "2. Circle CI\n",
- "3. Team City\n",
- "4. Bamboo\n",
- "5. GitLab"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Korzyści z Ciągłej Integracji\n",
- " * Minimalizacja ryzyka\n",
- " * Łatwiejsze szacowanie terminu zakończenia prac\n",
- " * Szybsza lokalizacja i naprawa błędów\n",
- " * Świadomość stanu prac u całego zespołu\n",
- " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n",
- " * Możliwość pracy w środowisku rozproszonym\n",
- " * Możliwość usunięcia bariery między wykonawcą i klientem"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Przykład - Jenkins\n",
- "\n",
- "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n",
+ "Materiały do wykładu dostępne są wyłącznie na grupie zajęciowej w Teamsach.\n",
"\n"
]
}
@@ -273,7 +39,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.9.12"
+ "version": "3.9.13"
},
"subtitle": "06. Prototypowanie i ciągła integracja[wykład]",
"title": "Przygotowanie do projektu badawczo-rozwojowego",
diff --git a/materiały na wykład/.ipynb_checkpoints/05_prototypowanie i GIT-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/05_prototypowanie i GIT-checkpoint.ipynb
new file mode 100644
index 0000000..e9282dd
--- /dev/null
+++ b/materiały na wykład/.ipynb_checkpoints/05_prototypowanie i GIT-checkpoint.ipynb
@@ -0,0 +1,234 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Systemy informatyczne analizy danych
\n",
+ " 5. Prototypowanie i GIT[wykład]
\n",
+ " Filip Graliński, Krzysztof Jassem (2024)
\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Prototyp
\n",
+ "Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n",
+ "\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Cele prototypowania\n",
+ " * Zademonstrowanie umiejętności wykonania produktu końcowego\n",
+ " * Określenie realistycznych wymagań końcowych\n",
+ " * Przekonanie się o wpływie innych systemów, środowisk na produkt. \n",
+ " * Sprawdzenie implementacji kluczowych funkcji\n",
+ "\n",
+ "## Potencjalne efekty prototypowania\n",
+ "* Wykrycie nieporozumień między klientem i wykonawcą \n",
+ "* Określenie brakujących funkcji \n",
+ "* Wykrycie błędów w specyfikacji\n",
+ "* Przewidywanie przyszłych trudności "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototyp poziomy a pionowy\n",
+ "### Prototyp poziomy (Horizontal Prototype)\n",
+ "\n",
+ "**Prototyp poziomy** obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.\n",
+ "\n",
+ "Przykłady prototypów poziomych w informatyce:\n",
+ " * Prototyp papierowy\n",
+ " * Makieta statyczna\n",
+ " * Makieta dynamiczna\n",
+ " * Graficzny interfejs użytkownika"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Prototyp papierowy
\n",
+ " \n",
+ "
Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. \n",
+ " \n",
+ "* Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. \n",
+ "* Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.\n",
+ "\n",
+ "
Prototypowanie papierowe - etapy :\n",
+ "\n",
+ "
\n",
+ "- Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności.
\n",
+ "- Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów.
\n",
+ "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Makieta statyczna
\n",
+ " \n",
+ " \n",
+ "
Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n",
+ "\n",
+ "
\n",
+ " - Obrazuje wybrane widoki bez połączeń między nimi.
\n",
+ "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Makieta dynamiczna
\n",
+ " \n",
+ " \n",
+ "
Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n",
+ "\n",
+ "
\n",
+ "- Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku.
\n",
+ "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Graficzny interfejs użytkownika (GUI)
\n",
+ "\n",
+ "
Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n",
+ " \n",
+ "Prototypem poziomym nazwiemy GUI, który: \n",
+ "
\n",
+ "- Pokazuje menu.
\n",
+ "- Pozwala na nawigację.
\n",
+ "- Akceptuje input.
\n",
+ "- Wyświetla losowy output.
\n",
+ "- NIE wspiera logiki aplikacji.
\n",
+ "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototyp pionowy (Vertical Prototype)\n",
+ "**Prototyp pionowy** to pełna realizacja kluczowej (kluczowych) funkcji systemu.\n",
+ "\n",
+ "Cele prototypowania pionowego:\n",
+ "* sprawdzenie wyboru technologii\n",
+ "* pomiary wydajności\n",
+ "* sprawdzenie poprawności algorytmów i struktur danych\n",
+ "\n",
+ "Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototypowanie z porzuceniem a prototypowanie ewolucyjne"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototypowanie z porzuceniem (Thow-away Prototyping)\n",
+ "\n",
+ "W **prototypowaniu z porzuceniem** budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.\n",
+ "\n",
+ "Cele prototypowania z porzuceniem:\n",
+ "* minimalizacja ryzyka,\n",
+ "* głębokie zrozumienie problemów technicznych\n",
+ "\n",
+ "Koszty:\n",
+ " * Koszty prototypowania z porzuceniem są wysokie."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototypowanie ewolucyjne (Ewolutionary Prototyping)\n",
+ "\n",
+ "**Prototypowanie ewolucyjne** polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania... \n",
+ "\n",
+ "...Wtedy prototyp staje się produktem.\n",
+ "\n",
+ "Prototyp ewolucyjny powinien być budowany:\n",
+ " * w środowisku zbliżonym do produkcyjnego, \n",
+ " * z dużą dbałością o jakość."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototypowanie - podsumowanie\n",
+ "\n",
+ "* Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu. \n",
+ "* W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji. \n",
+ "* W prototypach pionowych chodzi o szczegóły techniczne.\n",
+ "* Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome); \n",
+ " * jest bardziej kosztowne, ale minimalizuje ryzyko.\n",
+ "* Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe); \n",
+ " * jest mniej kosztowne, ale bardziej ryzykowne."
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3 (ipykernel)",
+ "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.9.13"
+ },
+ "subtitle": "02. Rozwój systemu informatycznego[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2024"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/01_praca_zespolowa.ipynb b/materiały na wykład/01_praca_zespolowa.ipynb
index 7bb55c1..fdd4fa4 100644
--- a/materiały na wykład/01_praca_zespolowa.ipynb
+++ b/materiały na wykład/01_praca_zespolowa.ipynb
@@ -245,7 +245,7 @@
"author": "Krzysztof Jassem",
"email": "jassem@amu.edu.pl",
"kernelspec": {
- "display_name": "Python 3",
+ "display_name": "Python 3 (ipykernel)",
"language": "python",
"name": "python3"
},
@@ -260,7 +260,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.8.5"
+ "version": "3.9.13"
},
"subtitle": "01. Praca zespołowa[wykład]",
"title": "Przygotowanie do projektu badawczo-rozwojowego",
diff --git a/materiały na wykład/02_badania CBK.ipynb b/materiały na wykład/02_badania CBK.ipynb
new file mode 100644
index 0000000..92c0a20
--- /dev/null
+++ b/materiały na wykład/02_badania CBK.ipynb
@@ -0,0 +1,49 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Systemy informatyczne analizy danych
\n",
+ " 2. Projekty Centrum Badań Kosmicznych[wykład]
\n",
+ "Tomasz Zawistowski (2024)
\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Materiały z wykładu dostępne są wyłącznie na grupie zajęciowej w Teamsach."
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3 (ipykernel)",
+ "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.9.13"
+ },
+ "subtitle": "01. Praca zespołowa[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb b/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb
index 85707d9..c95aebd 100644
--- a/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb
+++ b/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb
@@ -7,7 +7,7 @@
"\n",
"
Systemy informatyczne analizy danych
\n",
" 3. Ewaluacja systemów analizy danych[wykład]
\n",
- "Filip Graliński, Krzysztof Jassem (2023)
\n",
+ " Krzysztof Jassem (2024)
\n",
""
]
},
@@ -15,238 +15,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "\n",
- " \n",
- "
Ciągła integracja
\n",
- " \n",
- "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
- "
\n",
- " - zmiany w kodzie są regularnie przesyłane do centralnego repozytorium,
\n",
- " - po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Główne przesłanki CI
\n",
- " \n",
- "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
- "
\n",
- " - szybsze lokalizowanie błędów w kodzie,
\n",
- " - ciągły wzrost jakości oporgramowania,
\n",
- " - szybkie wydawanie nowych wersji.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Przebieg pracy w Ciągłej Integracji\n",
- "1. **Take Integrated Code**\n",
- " * Pobieram kod z repozytorium.\n",
- " * Instaluję kopię na swojej stacji roboczej. \n",
- " \n",
- "2. **Do Your Part**\n",
- " * Opracowuję nowy kod.\n",
- " * Opracowuję nowe testy jednostkowe.\n",
- " \n",
- "3. **Build on your machine**\n",
- "\n",
- " * **Repeat** \n",
- " * Kompiluję swój kod i buduję wersję wykonywalną,\n",
- " * Przeprowadzam testy jednostkowe,\n",
- " * **Until**\n",
- " * Kod się skompilował poprawnie oraz\n",
- " * Testy zakończyły się powodzeniem.\n",
- " \n",
- "4. **Integrate with Repository**\n",
- "\n",
- " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n",
- " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n",
- " * **Go back to: Take Integrated Code**\n",
- " * Przypadek 2. Tetsy się powodzą\n",
- " * **Continue**\n",
- " \n",
- "5. **End Session**\n",
- " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Dobre praktyki Ciągłej Integracji\n",
- "(wg https://www.martinfowler.com/articles/continuousIntegration.html)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Maintain a Single Source Repository\n",
- " * Załóż mainline (linię główną): \n",
- " * Deweloperzy powinni większość pracy składać na mainline.\n",
- " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n",
- " * naprawy błędów,\n",
- " * tymczasowych eksperymentów,\n",
- " * oznaczania wersji publikowalnych.\n"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Automate the Build\n",
- " * Wersja wykonywalna powinna być tworzona jednym poleceniem.\n",
- " * Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Test Yourself\n",
- " * Pisz testy jednostkowe.\n",
- " * Uruchamiaj testy po każdej kompilacji."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Everyone Commits Everyday\n",
- " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n",
- " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n",
- " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n",
- " * Postulat wymaga rozbicia projektu na małe kawałki."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Every Commit Should Build the Mainline\n",
- " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n",
- " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Fix the Broken Builds Immediately\n",
- "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n",
- "Znalezienie i poprawienie blędu jest priorytetem, ale:\n",
- " * Nie debugguj kodu na centralnym repozytorium. \n",
- " * Przywróć wersję wykonywalną na \"mainline\".\n",
- " * Debugguj kod na maszynie lokalnej."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Make it Easy to Run the Latest Executable\n",
- "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n",
- "* Jest to niezbędne do:\n",
- " * testowania integracyjnego (tester),\n",
- " * rozmów z klientem (zarząd lub sprzedawca),\n",
- " * prowadzenia projektu (kierownik zespołu).\n",
- "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Keep the Build Fast\n",
- "\n",
- " * Maximum 10 minut na build + testy.\n",
- " * A jeśli testy trwają dłużej?\n",
- " * Testy dwuetapowe:\n",
- " * kompilacja + testy jednostkowe przy każdym commicie,\n",
- " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Clone the Environment\n",
- " * Przygotuj klon środowiska produkcyjnego:\n",
- " * ta sama wersja systemu operacyjnego\n",
- " * ta sama baza danych\n",
- " * te same biblioteki (nawet jak ich nie potrzebujesz) \n",
- " * Wszystkie testy przeprowadzaj na przygotowanym środowisku."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Everyone Can See What's Happening\n",
- "System powinien informować użytkowników o swoim statusie."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Automate Deployment\n",
- " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n",
- " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". "
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Narzędzia Ciągłej Integracji\n",
- "\n",
- "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n",
- "\n",
- "1. Jenkins\n",
- "2. Circle CI\n",
- "3. Team City\n",
- "4. Bamboo\n",
- "5. GitLab"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Korzyści z Ciągłej Integracji\n",
- " * Minimalizacja ryzyka\n",
- " * Łatwiejsze szacowanie terminu zakończenia prac\n",
- " * Szybsza lokalizacja i naprawa błędów\n",
- " * Świadomość stanu prac u całego zespołu\n",
- " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n",
- " * Możliwość pracy w środowisku rozproszonym\n",
- " * Możliwość usunięcia bariery między wykonawcą i klientem"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Przykład - Jenkins\n",
- "\n",
- "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n",
+ "Materiały do wykładu dostępne są wyłącznie na grupie zajęciowej w Teamsach.\n",
"\n"
]
}
@@ -270,7 +39,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.9.12"
+ "version": "3.9.13"
},
"subtitle": "06. Prototypowanie i ciągła integracja[wykład]",
"title": "Przygotowanie do projektu badawczo-rozwojowego",
diff --git a/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb b/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb
index 565fe74..6ca2199 100644
--- a/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb
+++ b/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb
@@ -12,11 +12,11 @@
]
},
{
- "cell_type": "code",
- "execution_count": null,
+ "cell_type": "markdown",
"metadata": {},
- "outputs": [],
- "source": []
+ "source": [
+ "Do tego wykładu nie ma materiałów pomocniczych. "
+ ]
}
],
"metadata": {
@@ -38,7 +38,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.9.12"
+ "version": "3.9.13"
},
"subtitle": "06. Prototypowanie i ciągła integracja[wykład]",
"title": "Przygotowanie do projektu badawczo-rozwojowego",
diff --git a/materiały na wykład/05_prototypowanie i GIT.ipynb b/materiały na wykład/05_prototypowanie i GIT.ipynb
new file mode 100644
index 0000000..060537b
--- /dev/null
+++ b/materiały na wykład/05_prototypowanie i GIT.ipynb
@@ -0,0 +1,234 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "
Systemy informatyczne analizy danych
\n",
+ " 5. Prototypowanie i GIT[wykład]
\n",
+ " Krzysztof Jassem, Filip Graliński (2024)
\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Prototyp
\n",
+ "Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n",
+ "\n",
+ ""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Cele prototypowania\n",
+ " * Zademonstrowanie umiejętności wykonania produktu końcowego\n",
+ " * Określenie realistycznych wymagań końcowych\n",
+ " * Przekonanie się o wpływie innych systemów, środowisk na produkt. \n",
+ " * Sprawdzenie implementacji kluczowych funkcji\n",
+ "\n",
+ "## Potencjalne efekty prototypowania\n",
+ "* Wykrycie nieporozumień między klientem i wykonawcą \n",
+ "* Określenie brakujących funkcji \n",
+ "* Wykrycie błędów w specyfikacji\n",
+ "* Przewidywanie przyszłych trudności "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototyp poziomy a pionowy\n",
+ "### Prototyp poziomy (Horizontal Prototype)\n",
+ "\n",
+ "**Prototyp poziomy** obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.\n",
+ "\n",
+ "Przykłady prototypów poziomych w informatyce:\n",
+ " * Prototyp papierowy\n",
+ " * Makieta statyczna\n",
+ " * Makieta dynamiczna\n",
+ " * Graficzny interfejs użytkownika"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Prototyp papierowy
\n",
+ " \n",
+ "
Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. \n",
+ " \n",
+ "* Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. \n",
+ "* Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.\n",
+ "\n",
+ "
Prototypowanie papierowe - etapy :\n",
+ "\n",
+ "
\n",
+ "- Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności.
\n",
+ "- Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów.
\n",
+ "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Makieta statyczna
\n",
+ " \n",
+ " \n",
+ "
Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n",
+ "\n",
+ "
\n",
+ " - Obrazuje wybrane widoki bez połączeń między nimi.
\n",
+ "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Makieta dynamiczna
\n",
+ " \n",
+ " \n",
+ "
Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n",
+ "\n",
+ "
\n",
+ "- Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku.
\n",
+ "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
Graficzny interfejs użytkownika (GUI)
\n",
+ "\n",
+ "
Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n",
+ " \n",
+ "Prototypem poziomym nazwiemy GUI, który: \n",
+ "
\n",
+ "- Pokazuje menu.
\n",
+ "- Pozwala na nawigację.
\n",
+ "- Akceptuje input.
\n",
+ "- Wyświetla losowy output.
\n",
+ "- NIE wspiera logiki aplikacji.
\n",
+ "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototyp pionowy (Vertical Prototype)\n",
+ "**Prototyp pionowy** to pełna realizacja kluczowej (kluczowych) funkcji systemu.\n",
+ "\n",
+ "Cele prototypowania pionowego:\n",
+ "* sprawdzenie wyboru technologii\n",
+ "* pomiary wydajności\n",
+ "* sprawdzenie poprawności algorytmów i struktur danych\n",
+ "\n",
+ "Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototypowanie z porzuceniem a prototypowanie ewolucyjne"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototypowanie z porzuceniem (Thow-away Prototyping)\n",
+ "\n",
+ "W **prototypowaniu z porzuceniem** budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.\n",
+ "\n",
+ "Cele prototypowania z porzuceniem:\n",
+ "* minimalizacja ryzyka,\n",
+ "* głębokie zrozumienie problemów technicznych\n",
+ "\n",
+ "Koszty:\n",
+ " * Koszty prototypowania z porzuceniem są wysokie."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototypowanie ewolucyjne (Ewolutionary Prototyping)\n",
+ "\n",
+ "**Prototypowanie ewolucyjne** polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania... \n",
+ "\n",
+ "...Wtedy prototyp staje się produktem.\n",
+ "\n",
+ "Prototyp ewolucyjny powinien być budowany:\n",
+ " * w środowisku zbliżonym do produkcyjnego, \n",
+ " * z dużą dbałością o jakość."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototypowanie - podsumowanie\n",
+ "\n",
+ "* Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu. \n",
+ "* W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji. \n",
+ "* W prototypach pionowych chodzi o szczegóły techniczne.\n",
+ "* Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome); \n",
+ " * jest bardziej kosztowne, ale minimalizuje ryzyko.\n",
+ "* Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe); \n",
+ " * jest mniej kosztowne, ale bardziej ryzykowne."
+ ]
+ }
+ ],
+ "metadata": {
+ "author": "Krzysztof Jassem",
+ "email": "jassem@amu.edu.pl",
+ "kernelspec": {
+ "display_name": "Python 3 (ipykernel)",
+ "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.9.13"
+ },
+ "subtitle": "02. Rozwój systemu informatycznego[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2024"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/05_rozwój_systemów_informatycznych.ipynb b/materiały na wykład/05_rozwój_systemów_informatycznych.ipynb
deleted file mode 100644
index 5d1fb03..0000000
--- a/materiały na wykład/05_rozwój_systemów_informatycznych.ipynb
+++ /dev/null
@@ -1,464 +0,0 @@
-{
- "cells": [
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- "
Systemy informatyczne analizy danych
\n",
- " 2. Rozwój systemów informatycznych[wykład]
\n",
- " Filip Graliński, Krzysztof Jassem (2024)
\n",
- ""
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Prototyp
\n",
- "Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n",
- "\n",
- ""
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Cele prototypowania\n",
- " * Zademonstrowanie umiejętności wykonania produktu końcowego\n",
- " * Określenie realistycznych wymagań końcowych\n",
- " * Przekonanie się o wpływie innych systemów, środowisk na produkt. \n",
- " * Sprawdzenie implementacji kluczowych funkcji\n",
- "\n",
- "## Potencjalne efekty prototypowania\n",
- "* Wykrycie nieporozumień między klientem i wykonawcą \n",
- "* Określenie brakujących funkcji \n",
- "* Wykrycie błędów w specyfikacji\n",
- "* Przewidywanie przyszłych trudności "
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Prototyp poziomy a pionowy\n",
- "### Prototyp poziomy (Horizontal Prototype)\n",
- "\n",
- "**Prototyp poziomy** obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.\n",
- "\n",
- "Przykłady prototypów poziomych w informatyce:\n",
- " * Prototyp papierowy\n",
- " * Makieta statyczna\n",
- " * Makieta dynamiczna\n",
- " * Graficzny interfejs użytkownika"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Prototyp papierowy
\n",
- " \n",
- "
Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. \n",
- " \n",
- "* Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. \n",
- "* Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.\n",
- "\n",
- "
Prototypowanie papierowe - etapy :\n",
- "\n",
- "
\n",
- "- Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności.
\n",
- "- Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów.
\n",
- "
\n",
- " \n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Makieta statyczna
\n",
- " \n",
- " \n",
- "
Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n",
- "\n",
- "
\n",
- " - Obrazuje wybrane widoki bez połączeń między nimi.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Makieta dynamiczna
\n",
- " \n",
- " \n",
- "
Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n",
- "\n",
- "
\n",
- "- Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Graficzny interfejs użytkownika (GUI)
\n",
- "\n",
- "
Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n",
- " \n",
- "Prototypem poziomym nazwiemy GUI, który: \n",
- "
\n",
- "- Pokazuje menu.
\n",
- "- Pozwala na nawigację.
\n",
- "- Akceptuje input.
\n",
- "- Wyświetla losowy output.
\n",
- "- NIE wspiera logiki aplikacji.
\n",
- "
\n",
- " \n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Prototyp pionowy (Vertical Prototype)\n",
- "**Prototyp pionowy** to pełna realizacja kluczowej (kluczowych) funkcji systemu.\n",
- "\n",
- "Cele prototypowania pionowego:\n",
- "* sprawdzenie wyboru technologii\n",
- "* pomiary wydajności\n",
- "* sprawdzenie poprawności algorytmów i struktur danych\n",
- "\n",
- "Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Prototypowanie z porzuceniem a prototypowanie ewolucyjne"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Prototypowanie z porzuceniem (Thow-away Prototyping)\n",
- "\n",
- "W **prototypowaniu z porzuceniem** budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.\n",
- "\n",
- "Cele prototypowania z porzuceniem:\n",
- "* minimalizacja ryzyka,\n",
- "* głębokie zrozumienie problemów technicznych\n",
- "\n",
- "Koszty:\n",
- " * Koszty prototypowania z porzuceniem są wysokie."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Prototypowanie ewolucyjne (Ewolutionary Prototyping)\n",
- "\n",
- "**Prototypowanie ewolucyjne** polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania... \n",
- "\n",
- "...Wtedy prototyp staje się produktem.\n",
- "\n",
- "Prototyp ewolucyjny powinien być budowany:\n",
- " * w środowisku zbliżonym do produkcyjnego, \n",
- " * z dużą dbałością o jakość."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Prototypowanie - podsumowanie\n",
- "\n",
- "* Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu. \n",
- "* W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji. \n",
- "* W prototypach pionowych chodzi o szczegóły techniczne.\n",
- "* Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome); \n",
- " * jest bardziej kosztowne, ale minimalizuje ryzyko.\n",
- "* Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe); \n",
- " * jest mniej kosztowne, ale bardziej ryzykowne."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Ciągła integracja
\n",
- " \n",
- "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
- "
\n",
- " - zmiany w kodzie są regularnie przesyłane do centralnego repozytorium,
\n",
- " - po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "\n",
- " \n",
- "
Główne przesłanki CI
\n",
- " \n",
- "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n",
- "
\n",
- " - szybsze lokalizowanie błędów w kodzie,
\n",
- " - ciągły wzrost jakości oporgramowania,
\n",
- " - szybkie wydawanie nowych wersji.
\n",
- "
\n",
- "
"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Przebieg pracy w Ciągłej Integracji\n",
- "1. **Take Integrated Code**\n",
- " * Pobieram kod z repozytorium.\n",
- " * Instaluję kopię na swojej stacji roboczej. \n",
- " \n",
- "2. **Do Your Part**\n",
- " * Opracowuję nowy kod.\n",
- " * Opracowuję nowe testy jednostkowe.\n",
- " \n",
- "3. **Build on your machine**\n",
- "\n",
- " * **Repeat** \n",
- " * Kompiluję swój kod i buduję wersję wykonywalną,\n",
- " * Przeprowadzam testy jednostkowe,\n",
- " * **Until**\n",
- " * Kod się skompilował poprawnie oraz\n",
- " * Testy zakończyły się powodzeniem.\n",
- " \n",
- "4. **Integrate with Repository**\n",
- "\n",
- " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n",
- " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n",
- " * **Go back to: Take Integrated Code**\n",
- " * Przypadek 2. Tetsy się powodzą\n",
- " * **Continue**\n",
- " \n",
- "5. **End Session**\n",
- " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Dobre praktyki Ciągłej Integracji\n",
- "(wg https://www.martinfowler.com/articles/continuousIntegration.html)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Maintain a Single Source Repository\n",
- " * Załóż mainline (linię główną): \n",
- " * Deweloperzy powinni większość pracy składać na mainline.\n",
- " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n",
- " * naprawy błędów,\n",
- " * tymczasowych eksperymentów,\n",
- " * oznaczania wersji publikowalnych."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Test Yourself\n",
- " * Pisz testy jednostkowe.\n",
- " * Uruchamiaj testy po każdej kompilacji."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Everyone Commits Everyday\n",
- " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n",
- " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n",
- " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n",
- " * Postulat wymaga rozbicia projektu na małe kawałki."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Every Commit Should Build the Mainline\n",
- " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n",
- " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Fix the Broken Builds Immediately\n",
- "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n",
- "Znalezienie i poprawienie blędu jest priorytetem, ale:\n",
- " * Nie debugguj kodu na centralnym repozytorium. \n",
- " * Przywróć wersję wykonywalną na \"mainline\".\n",
- " * Debugguj kod na maszynie lokalnej."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Make it Easy to Run the Latest Executable\n",
- "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n",
- "* Jest to niezbędne do:\n",
- " * testowania integracyjnego (tester),\n",
- " * rozmów z klientem (zarząd lub sprzedawca),\n",
- " * prowadzenia projektu (kierownik zespołu).\n",
- "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Keep the Build Fast\n",
- "\n",
- " * Maximum 10 minut na build + testy.\n",
- " * A jeśli testy trwają dłużej?\n",
- " * Testy dwuetapowe:\n",
- " * kompilacja + testy jednostkowe przy każdym commicie,\n",
- " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Clone the Environment\n",
- " * Przygotuj klon środowiska produkcyjnego:\n",
- " * ta sama wersja systemu operacyjnego\n",
- " * ta sama baza danych\n",
- " * te same biblioteki (nawet jak ich nie potrzebujesz) \n",
- " * Wszystkie testy przeprowadzaj na przygotowanym środowisku."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Everyone Can See What's Happening\n",
- "System powinien informować użytkowników o swoim statusie."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "### Automate Deployment\n",
- " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n",
- " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". "
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Narzędzia Ciągłej Integracji\n",
- "\n",
- "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n",
- "\n",
- "1. Jenkins\n",
- "2. Circle CI\n",
- "3. Team City\n",
- "4. Bamboo\n",
- "5. GitLab"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Korzyści z Ciągłej Integracji\n",
- " * Minimalizacja ryzyka\n",
- " * Łatwiejsze szacowanie terminu zakończenia prac\n",
- " * Szybsza lokalizacja i naprawa błędów\n",
- " * Świadomość stanu prac u całego zespołu\n",
- " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n",
- " * Możliwość pracy w środowisku rozproszonym\n",
- " * Możliwość usunięcia bariery między wykonawcą i klientem"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Przykład - Jenkins\n",
- "\n",
- "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n",
- "\n"
- ]
- }
- ],
- "metadata": {
- "author": "Krzysztof Jassem",
- "email": "jassem@amu.edu.pl",
- "kernelspec": {
- "display_name": "Python 3 (ipykernel)",
- "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.9.12"
- },
- "subtitle": "02. Rozwój systemu informatycznego[wykład]",
- "title": "Przygotowanie do projektu badawczo-rozwojowego",
- "year": "2024"
- },
- "nbformat": 4,
- "nbformat_minor": 4
-}