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

Przygotowanie do projektu badawczo-rozwojowego

\n", "

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

\n", "

Krzysztof Jassem (2021)

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