jassem
/
SysInf
6
4
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
SysInf/materiały na wykład/06_prototypowanie i ciągła ...

15 KiB
Raw Blame History

Logo 1

Systemy informatyczne

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

Krzysztof Jassem (2022)

Logo 2

Prototyp

Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.

Cele prototypowania

  • Zademonstrowanie umiejętności wykonania produktu końcowego
  • Określenie realistycznych wymagań końcowych
  • Przekonanie się o wpływie innych systemów, środowisk na produkt.
  • Sprawdzenie implementacji kluczowych funkcji

Potencjalne efekty prototypowania

  • Wykrycie nieporozumień między klientem i wykonawcą
  • Określenie brakujących funkcji
  • Wykrycie błędów w specyfikacji
  • Przewidywanie przyszłych trudności

Prototyp poziomy a pionowy

Prototyp poziomy (Horizontal Prototype)

Prototyp poziomy obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.

Przykłady prototypów poziomych w informatyce:

  • Prototyp papierowy
  • Makieta statyczna
  • Makieta dynamiczna
  • Graficzny interfejs użytkownika

Prototyp papierowy

Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. * Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. * Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.

Prototypowanie papierowe - etapy :

  • Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności.
  • Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów.

Makieta statyczna

Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny.
  • Obrazuje wybrane widoki bez połączeń między nimi.

Makieta dynamiczna

Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem.
  • Widoki są "klikalne" - po kliknięciu użytkowniki kierowany jest do nowego widoku.

Graficzny interfejs użytkownika (GUI)

Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.

Prototypem poziomym nazwiemy GUI, który:

  • Pokazuje menu.
  • Pozwala na nawigację.
  • Akceptuje input.
  • Wyświetla losowy output.
  • NIE wspiera logiki aplikacji.

Prototyp pionowy (Vertical Prototype)

Prototyp pionowy to pełna realizacja kluczowej (kluczowych) funkcji systemu.

Cele prototypowania pionowego:

  • sprawdzenie wyboru technologii
  • pomiary wydajności
  • sprawdzenie poprawności algorytmów i struktur danych

Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem.

Prototypowanie z porzuceniem a prototypowanie ewolucyjne

Prototypowanie z porzuceniem (Thow-away Prototyping)

W prototypowaniu z porzuceniem budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.

Cele prototypowania z porzuceniem:

  • minimalizacja ryzyka,
  • głębokie zrozumienie problemów technicznych

Koszty:

  • Koszty prototypowania z porzuceniem są wysokie.

Prototypowanie ewolucyjne (Ewolutionary Prototyping)

Prototypowanie ewolucyjne polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania...

...Wtedy prototyp staje się produktem.

Prototyp ewolucyjny powinien być budowany:

  • w środowisku zbliżonym do produkcyjnego,
  • z dużą dbałością o jakość.

Prototypowanie - podsumowanie

  • Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu.
  • W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji.
  • W prototypach pionowych chodzi o szczegóły techniczne.
  • Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome);
    • jest bardziej kosztowne, ale minimalizuje ryzyko.
  • Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe);
    • jest mniej kosztowne, ale bardziej ryzykowne.

Ciągła integracja

Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:
  • zmiany w kodzie są regularnie przesyłane do centralnego repozytorium,
  • po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy.

Główne przesłanki CI

Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:
  • szybsze lokalizowanie błędów w kodzie,
  • ciągły wzrost jakości oporgramowania,
  • szybkie wydawanie nowych wersji.

Schemat CI/CD

Przebieg pracy w Ciągłej Integracji

  1. Take Integrated Code
  • Pobieram kod z repozytorium.
  • Instaluję kopię na swojej stacji roboczej.
  1. Do Your Part
  • Opracowuję nowy kod.
  • Opracowuję nowe testy jednostkowe.
  1. Build on your machine
  • Repeat
    • Kompiluję swój kod i buduję wersję wykonywalną,
    • Przeprowadzam testy jednostkowe,
  • Until
    • Kod się skompilował poprawnie oraz
    • Testy zakończyły się powodzeniem.
  1. Integrate with Repository
  • Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.
    • Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.
      • Go back to: Take Integrated Code
    • Przypadek 2. Tetsy się powodzą
      • Continue
  1. End Session
  • Gdy powiodły się wszystkie testy, mogę zakończyć sesję.

Dobre praktyki Ciągłej Integracji

(wg https://www.martinfowler.com/articles/continuousIntegration.html)

Maintain a Single Source Repository

  • Załóż mainline (linię główną):
    • Deweloperzy powinni większość pracy składać na mainline.
  • Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:
    • naprawy błędów,
    • tymczasowych eksperymentów,
    • oznaczania wersji publikowalnych.

Automate the Build

  • Wersja wykonywalna powinna być tworzona jednym poleceniem.
  • Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych.

Test Yourself

  • Pisz testy jednostkowe.
  • Uruchamiaj testy po każdej kompilacji.

Everyone Commits Everyday

  • Każdy powinien "codziennie" wypychać swój kod do linii głównej.
  • Umożliwia to wczesne wykrywanie konfliktów, gdyż...
    • Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.
  • Postulat wymaga rozbicia projektu na małe kawałki.

Every Commit Should Build the Mainline

  • Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.
  • Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins).

Fix the Broken Builds Immediately

Co zrobić, jeśli jednak kod na "mainline" się nie buduje?
Znalezienie i poprawienie blędu jest priorytetem, ale:

  • Nie debugguj kodu na centralnym repozytorium.
  • Przywróć wersję wykonywalną na "mainline".
  • Debugguj kod na maszynie lokalnej.

Make it Easy to Run the Latest Executable

  • Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.
  • Jest to niezbędne do:
    • testowania integracyjnego (tester),
    • rozmów z klientem (zarząd lub sprzedawca),
    • prowadzenia projektu (kierownik zespołu).
  • W specjalnej lokalizacji przetrzymuj wersje stabilne - "do pokazania".

Keep the Build Fast

  • Maximum 10 minut na build + testy.
  • A jeśli testy trwają dłużej?
    • Testy dwuetapowe:
      • kompilacja + testy jednostkowe przy każdym commicie,
      • testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów).

Clone the Environment

  • Przygotuj klon środowiska produkcyjnego:
    • ta sama wersja systemu operacyjnego
    • ta sama baza danych
    • te same biblioteki (nawet jak ich nie potrzebujesz)
  • Wszystkie testy przeprowadzaj na przygotowanym środowisku.

Everyone Can See What's Happening

System powinien informować użytkowników o swoim statusie.

Automate Deployment

  • Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.
  • Pozwala to na szybką reakcję, gdy "coś się dzieje".

Narzędzia Ciągłej Integracji

https://www.katalon.com/resources-center/blog/ci-cd-tools/

  1. Jenkins
  2. Circle CI
  3. Team City
  4. Bamboo
  5. GitLab

Korzyści z Ciągłej Integracji

  • Minimalizacja ryzyka
  • Łatwiejsze szacowanie terminu zakończenia prac
  • Szybsza lokalizacja i naprawa błędów
  • Świadomość stanu prac u całego zespołu
  • Możliwość kontynuowania prac w przypadku odejścia dewelopera
  • Możliwość pracy w środowisku rozproszonym
  • Możliwość usunięcia bariery między wykonawcą i klientem

Przykład - Jenkins

https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile