diff --git a/materiały na laboratorium/.ipynb_checkpoints/02_projekty_CBK_lab-checkpoint.ipynb b/materiały na laboratorium/.ipynb_checkpoints/02_projekty_CBK_lab-checkpoint.ipynb new file mode 100644 index 0000000..bc515a7 --- /dev/null +++ b/materiały na laboratorium/.ipynb_checkpoints/02_projekty_CBK_lab-checkpoint.ipynb @@ -0,0 +1,91 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Systemy informatyczne

\n", + "

2. Projekty CBK

\n", + "

Filip Graliński (2023)

\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Cel laboratorium nr 2\n", + "\n", + "Celem laboratorium będzie zaznajomienie studentów z systemem kontroli wersji Git." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Plan laboratorium\n", + "\n", + "## Zadanie 1. Projekty CSI\n", + "Utworzyć nowe grupy zajęciowe. W każdej grupie musi nastąpić zmiana lidera oraz co najmniej jedna zmiana osobowa w stosunku do zajęć numer 1. W odpowiedzi na to zadanie wpisać skład grupy na obecnych zajęciach.\n", + "\n", + "Uruchomić i krótko przetestować każdy z systemów stworzonych w Centrum Sztucznej Inteligencji (informacje o systemach podane są w prezentacji zamieszczonej w \"Materiałach pomocniczych do labów\").\n", + "Ocenić każdy system w skali od 1 do 5 (5 = najwyższa ocena), uzasadniając krótko (1 - 3 zdania) przydatność każdego z nich dla użytkowników. \n", + "Wybrać jeden z systemów (niekoniecznie najlepszy) do dokładnego przetestowania. Wykonać testowanie systemu, a jego wynik przedstawić w postaci skróconego raportu testowania. Przykładowy raport testowania podany jest w \"Materiałach pomocniczych do labów\". Na zajęciach oczekuje się zdefiniowania pięciu przypadków testowych w taki sposób, aby objęły one możliwie największy zakres funkcji systemu. \n", + "(10 pkt)\n", + "\n", + "## Zadanie 2. Projekty studenckie z roku 2023/2024\n", + "2.2. Przeanalizować prezentacje projektów z roku 2023/2024. Przeprowadzić na ich podstawie ocenę jakości systemu, wybierając te aspekty, które można ocenić na podstawie samej prezentacji. Przykładowe aspekty zaproponowane są w schematach FURPS, CUPRIMDA lub CUPRIMDSO (wyjaśnienie odszukać w Internecie). Dla każdego systemu ocenić każdy aspekt w skali od 1 do 5.\n", + "Na podstawie ocen poszczególnych aspektów wybrać najlepszy projekt.\n", + "(10 pkt)\n", + "\n", + "## Zadanie 3. Burza mózgów\n", + "Wykonać burzę mózgów (https://en.wikipedia.org/wiki/Brainstorming) w celu wypracowania wstępnej koncepcji systemu opracowywanego na zajęciach. Koncepcja ta nie musi stać się podstawą do systemu informatycznego analizy danych, realizowanego w dalszej części semestru.\n", + "Założenia systemu realizowanego na zajęciach są następujące:\n", + "\n", + "System powinien przetwarzać pewien duży zbiór danych wejściowych za pomocą metod uczenia maszynowego (przykładowe zbiory danych podane są tutaj: \n", + "https://git.wmi.amu.edu.pl/jassem/SysInf/src/branch/master/Tematy%20projekt%C3%B3w_2023.ipynb \n", + "System powinien wykazywać pewną nowatorską cechę\n", + "\n", + "Przedstawić notatkę z dyskusji.\n", + "Oceniane będą: \n", + " zgodność z teorią burzy mózgów podaną w WIkipedii, skrótowo:\n", + "Nie krytykuj pomysłów – wszystkie pomysły są mile widziane, nie ma złych odpowiedzi.\n", + "Idź na ilość – celem jest wygenerowanie jak największej liczby pomysłów.\n", + "Buduj na pomysłach innych – rozwijaj pomysły współuczestników, dodając nowe elementy.\n", + "Myśl nieszablonowo – zachęca się do kreatywnych, odważnych i nietypowych pomysłów.\n", + "Odkładaj na bok ocenę – na tym etapie nie skupiamy na ocenie i analizie wykonalności.\n", + "Krótko i zwięźle – pomysły powinny być przedstawiane szybko, bez wchodzenia w szczegóły.\n", + " efekt burzy mózgów - ilość/kreatywność pomysłów nie odbiegających daleko od przyjętych wyżej założeń\n", + " (10 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": "01. Prezentacje publiczne[laboratorium]", + "title": "Projekt badawczo-rozwojowy", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na laboratorium/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych_lab-checkpoint.ipynb b/materiały na laboratorium/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych_lab-checkpoint.ipynb new file mode 100644 index 0000000..baf82f6 --- /dev/null +++ b/materiały na laboratorium/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych_lab-checkpoint.ipynb @@ -0,0 +1,59 @@ +{ + "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", + "(10 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": "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/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych_lab-checkpoint.ipynb b/materiały na laboratorium/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych_lab-checkpoint.ipynb new file mode 100644 index 0000000..791f025 --- /dev/null +++ b/materiały na laboratorium/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych_lab-checkpoint.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/.ipynb_checkpoints/05_prototypowanie_GIT_lab-checkpoint.ipynb b/materiały na laboratorium/.ipynb_checkpoints/05_prototypowanie_GIT_lab-checkpoint.ipynb new file mode 100644 index 0000000..b02019e --- /dev/null +++ b/materiały na laboratorium/.ipynb_checkpoints/05_prototypowanie_GIT_lab-checkpoint.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/02_git.ipynb b/materiały na laboratorium/02_git.ipynb deleted file mode 100644 index 6ada709..0000000 --- a/materiały na laboratorium/02_git.ipynb +++ /dev/null @@ -1,70 +0,0 @@ -{ - "cells": [ - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "
\n", - "

Systemy informatyczne

\n", - "

2. System kontroli wersji - Gitaboratorium]

\n", - "

Filip Graliński (2023)

\n", - "
" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "# Cel laboratorium nr 2\n", - "\n", - "Celem laboratorium będzie zaznajomienie studentów z systemem kontroli wersji Git." - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "# Plan laboratorium (brudnopis)\n", - "\n", - "1. Utwórzcie repozytorium na wydziałowym Gicie dla projektu wyceny mieszkań. Repozytorium powinno wstępnie zawierać wyłącznie króki plik tekstowy readme (max 1 zdanie) oraz dwa pliki kodów źródłowych utworzone na lab 1 (interfejs użytkownika oraz funkcja wycena mieszkania). Repozytorium powinno być prywatne, ale przy tym dostępne dla prowadzących zajęcia (4pkt).\n", - "2. Sklonujcie repozytorium dla każdego członka grupy. \n", - "3. Podzielcie się zadaniami:\n", - " - modyfikacja pliku readme, aby plik ten zawierał opis projektu (1 pkt)\n", - " - modyfikacja pliku .gitignore, tak aby nie zapisywały się kopie zapasowe wybranego edytora (1 pkt)\n", - " - modyfikacja kodu zródłowego z interfejsem użytkownika z lab 1 zgodnie z komentarzami podanymi w ocenie zadania (3 pkt)\n", - " - modyfikacja kodu zródłowego z interfejsem użytkownika w taki sposób, aby uruchamiał on funkcję wyceny mieszkania (może być w uproszczonej postaci, nie będziemy oceniali skuteczności), (3 pkt)\n", - " - modyfikacja funkcję wyceny mieszkania z lab 1 zgodnie z komentarzami podanymi w ocenie zadania (3 pkt)\n", - " - poprawienie rysunku interfejsu użytkownika. (3 pkt)\n", - "4. **Uwaga** repozytorium powinno zawierać 2 gałęzie: główną, main lub master i with-pictures. (4 pkt) Obrazki powinny się znaleźć się wyłącznie w gałezi with-pictures. (4 pkt)\n", - "5. Wypchnijcie swoje zmiany w taki sposób, aby każdy członek grupy dokonał przynajmniej jednej zmiany w repozytorium zdalnym. (2 pkt, brak spełnionego warunku: -8 pkt) Repozytorium powinno zawierać przynajmniej jedno scalenie (merge). (2 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.11.5" - }, - "subtitle": "01. Prezentacje publiczne[laboratorium]", - "title": "Projekt badawczo-rozwojowy", - "year": "2021" - }, - "nbformat": 4, - "nbformat_minor": 4 -} diff --git a/materiały na laboratorium/02_projekty_CBK_lab.ipynb b/materiały na laboratorium/02_projekty_CBK_lab.ipynb new file mode 100644 index 0000000..bc515a7 --- /dev/null +++ b/materiały na laboratorium/02_projekty_CBK_lab.ipynb @@ -0,0 +1,91 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Systemy informatyczne

\n", + "

2. Projekty CBK

\n", + "

Filip Graliński (2023)

\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Cel laboratorium nr 2\n", + "\n", + "Celem laboratorium będzie zaznajomienie studentów z systemem kontroli wersji Git." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "# Plan laboratorium\n", + "\n", + "## Zadanie 1. Projekty CSI\n", + "Utworzyć nowe grupy zajęciowe. W każdej grupie musi nastąpić zmiana lidera oraz co najmniej jedna zmiana osobowa w stosunku do zajęć numer 1. W odpowiedzi na to zadanie wpisać skład grupy na obecnych zajęciach.\n", + "\n", + "Uruchomić i krótko przetestować każdy z systemów stworzonych w Centrum Sztucznej Inteligencji (informacje o systemach podane są w prezentacji zamieszczonej w \"Materiałach pomocniczych do labów\").\n", + "Ocenić każdy system w skali od 1 do 5 (5 = najwyższa ocena), uzasadniając krótko (1 - 3 zdania) przydatność każdego z nich dla użytkowników. \n", + "Wybrać jeden z systemów (niekoniecznie najlepszy) do dokładnego przetestowania. Wykonać testowanie systemu, a jego wynik przedstawić w postaci skróconego raportu testowania. Przykładowy raport testowania podany jest w \"Materiałach pomocniczych do labów\". Na zajęciach oczekuje się zdefiniowania pięciu przypadków testowych w taki sposób, aby objęły one możliwie największy zakres funkcji systemu. \n", + "(10 pkt)\n", + "\n", + "## Zadanie 2. Projekty studenckie z roku 2023/2024\n", + "2.2. Przeanalizować prezentacje projektów z roku 2023/2024. Przeprowadzić na ich podstawie ocenę jakości systemu, wybierając te aspekty, które można ocenić na podstawie samej prezentacji. Przykładowe aspekty zaproponowane są w schematach FURPS, CUPRIMDA lub CUPRIMDSO (wyjaśnienie odszukać w Internecie). Dla każdego systemu ocenić każdy aspekt w skali od 1 do 5.\n", + "Na podstawie ocen poszczególnych aspektów wybrać najlepszy projekt.\n", + "(10 pkt)\n", + "\n", + "## Zadanie 3. Burza mózgów\n", + "Wykonać burzę mózgów (https://en.wikipedia.org/wiki/Brainstorming) w celu wypracowania wstępnej koncepcji systemu opracowywanego na zajęciach. Koncepcja ta nie musi stać się podstawą do systemu informatycznego analizy danych, realizowanego w dalszej części semestru.\n", + "Założenia systemu realizowanego na zajęciach są następujące:\n", + "\n", + "System powinien przetwarzać pewien duży zbiór danych wejściowych za pomocą metod uczenia maszynowego (przykładowe zbiory danych podane są tutaj: \n", + "https://git.wmi.amu.edu.pl/jassem/SysInf/src/branch/master/Tematy%20projekt%C3%B3w_2023.ipynb \n", + "System powinien wykazywać pewną nowatorską cechę\n", + "\n", + "Przedstawić notatkę z dyskusji.\n", + "Oceniane będą: \n", + " zgodność z teorią burzy mózgów podaną w WIkipedii, skrótowo:\n", + "Nie krytykuj pomysłów – wszystkie pomysły są mile widziane, nie ma złych odpowiedzi.\n", + "Idź na ilość – celem jest wygenerowanie jak największej liczby pomysłów.\n", + "Buduj na pomysłach innych – rozwijaj pomysły współuczestników, dodając nowe elementy.\n", + "Myśl nieszablonowo – zachęca się do kreatywnych, odważnych i nietypowych pomysłów.\n", + "Odkładaj na bok ocenę – na tym etapie nie skupiamy na ocenie i analizie wykonalności.\n", + "Krótko i zwięźle – pomysły powinny być przedstawiane szybko, bez wchodzenia w szczegóły.\n", + " efekt burzy mózgów - ilość/kreatywność pomysłów nie odbiegających daleko od przyjętych wyżej założeń\n", + " (10 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": "01. Prezentacje publiczne[laboratorium]", + "title": "Projekt badawczo-rozwojowy", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na laboratorium/03_ciągła_integracja_ewaluacja_lab.ipynb b/materiały na laboratorium/03_ciągła_integracja_ewaluacja_lab.ipynb deleted file mode 100644 index e8a690a..0000000 --- a/materiały na laboratorium/03_ciągła_integracja_ewaluacja_lab.ipynb +++ /dev/null @@ -1,80 +0,0 @@ -{ - "cells": [ - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "
\n", - "

Systemy informatyczne

\n", - "

3. Ciągła integracja i ciągłą ewaluacja[laboratorium]

\n", - "

Filip Graliński (2023)

\n", - "
" - ] - }, - { - "cell_type": "markdown", - "metadata": {}, - "source": [ - "# Cel laboratorium nr 3\n", - "Celem laboratorium jest zaznajomienie studentów z systemem ciągłej integracji Jenkins oraz z systemem ewaluacji systemów ML o nazwie Gonito. \n", - "\n", - "### Zadanie 3-1 Jenkins\n", - "\n", - "Skonfiguruj swoje zadanie na wydziałowym serwerze Jenkins (https://jenkins.wmi.amu.edu.pl). \n", - "\n", - "Wersja minimalna (5 pkt): puste zadanie, które pobiera repozytorium opracowane na poprzednich zajęciach (trzeba będzie dodać plik Jenkinsfile do repozytoriów) automatycznie wyzwalane po każdym wypchnięciu do gita.\n", - "\n", - "Wersja rozszerzona (+5 pkt): uruchomienia lintera typu flake8/black lub uruchomienie programu z jakimś sprawdzeniem (np. czy cena jest zawsze dodatnia).\n", - "\n", - "### Zadanie 3-2 Gonito (raport)\n", - "\n", - "(6 pkt)\n", - "\n", - "Przygotować krótki raport (2/3 - 1 strona A4) z oceną systemu Gonito, w wersji . Raport powinien zawierać krótką ogólną recenzję i raport znalezionych błędów (mogą to być większe błędy, ale też drobniejsze usterki). Raport powinien dotyczyć zarówno \"przeklikania\" serwera bez logowania, jak i problemów wynikłych przy rozwiązaniu zadania 3.3.\n", - "\n", - "### Zadanie 3-3 Gonito (zgłoszenie rozwiązania)\n", - "\n", - "Zgłosić rozwiązanie do wyzwania mieszkania5 z . \n", - "\n", - "Punktacja - wg pozycji w rankingu (biorąc pod uwagę grupy z przedmiotu): I miejsce - 15 pkt, II miejce - 14pkt itd.\n", - "\n", - "Rozwiązanie powinno mieć lepszy (niższy) wynik niż 100000\n", - "\n", - "\n", - "## Materiały pomocnicze\n", - "\n", - "* jak sprząc Jenkins/git w naszej infrastrukturze wydziałowej - \n", - "* przykładowa konfiguracja Jenkinsa dla Pythona \n", - "* przykładowe rozwiązanie dla mieszkania5: \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 -}