Lokalne modele LLM w pracy analityka i architekta

W poprzednim wpisie, Analiza i projektowanie aplikacji z wykorzystaniem LLM, pokazałem, jak duży model językowy wspiera analityka i projektanta w kolejnych fazach cyklu życia oprogramowania. Wszystkie przykłady dotyczyły jednego projektu: aplikacji rezerwacyjnej dla wypożyczalni pojazdów „Trasa”. Ten tekst jest kontynuacją tamtego wpisu.

Tym razem stawiam bardziej praktyczne pytanie. Czy model uruchomiony lokalnie, na zwykłym laptopie, bez wysyłania ani jednego zdania do chmury, da wynik użyteczny jako pierwszy szkic dla analityka i architekta? Żeby na nie odpowiedzieć, przeprowadziłem prosty test. Te same cztery zadania z analizy i architektury dostało pięć modeli lokalnych oraz ChatGPT jako punkt odniesienia.

W tekście znajdziesz uzasadnienie, dlaczego modele lokalne w ogóle warto brać pod uwagę, opis sprzętu i ustawień, pełne treści promptów, wszystkie odpowiedzi modeli bez skrótów, ich ocenę według jednej rubryki oraz moje rekomendacje.

Dlaczego modele lokalne są ważne?

W pracy analityka najcenniejszy materiał to dokumenty klienta: notatki ze spotkań, opisy procesów, regulaminy, umowy, czasem dane osobowe. Właśnie tych materiałów najczęściej nie wolno wysłać do zewnętrznej usługi. Model lokalny działa na Twoim komputerze, więc dane nie opuszczają maszyny.

Najważniejsze powody, dla których warto mieć model lokalny pod ręką:

• Poufność i tajemnica przedsiębiorstwa. Dokumenty klienta zostają na Twoim dysku, a nie na serwerze dostawcy usługi.
• Dane osobowe i RODO. Nie musisz analizować, czy i na jakiej podstawie przekazujesz dane podmiotowi trzeciemu.
• NDA i polityki bezpieczeństwa. Wiele umów i regulaminów wewnętrznych wprost zabrania wklejania dokumentów do zewnętrznych narzędzi AI.
• Praca bez internetu. Pociąg, samolot, serwerownia klienta bez dostępu do sieci.
• Brak opłat za tokeny. Płacisz raz za sprzęt, a potem uruchamiasz model tyle razy, ile potrzebujesz.
• Niezależność od dostawcy. Nikt nie zmieni Ci modelu z dnia na dzień i nie wycofa funkcji, na której oparłeś swój sposób pracy.
• Powtarzalność. Ten sam plik modelu za rok działa tak samo jak dziś. Prompt dopracowany raz pozostaje dopracowany.

Nie oznacza to, że model lokalny zawsze jest lepszym wyborem. Poniższa tabela pokazuje, jak sam dzielę zadania.

Sytuacja	Mój wybór
Analiza dokumentów objętych NDA, sektor publiczny, bankowość, ochrona zdrowia, projekty obronne	model lokalny
Wstępne porządkowanie notatek ze spotkań z klientem	model lokalny
Powtarzalne zadania na szablonach (tabela wymagań, lista pytań, rejestr decyzji)	model lokalny
Praca w podróży lub bez dostępu do sieci	model lokalny
Zadania wymagające aktualnej wiedzy lub wyszukiwania w internecie	chmura
Bardzo długie dokumenty, które nie mieszczą się w kontekście małego modelu	chmura
Złożone rozumowanie architektoniczne z wieloma kompromisami	chmura albo największy model lokalny, jaki uruchomisz
Liczy się czas, a sprzęt jest słaby	chmura
Materiały publiczne, przy których poufność nie ma znaczenia	chmura, bo jest szybsza i mocniejsza

Krótko mówiąc: model lokalny ma sens tam, gdzie poufność jest ważniejsza niż wygoda i szybkość.

Na czym testowałem?

Test przeprowadziłem na laptopie Lenovo ThinkPad P14s Gen 6 AMD (21RV0011PB). To mobilna stacja robocza z procesorem AMD Ryzen AI 9 HX PRO 370 (12 rdzeni, 24 wątki), zintegrowanym układem graficznym AMD Radeon 890M, jednostką NPU do 50 TOPS, 64 GB pamięci RAM DDR5-5600 w dwóch kanałach i 14-calowym ekranem WUXGA. Laptop nie ma osobnej karty graficznej. Model językowy korzysta z pamięci RAM współdzielonej z układem graficznym. Modele uruchamiałem w programie LM Studio.

Przy generowaniu tekstu o szybkości decyduje głównie przepustowość pamięci: mój laptop ma około 90 GB/s, a karta NVIDIA GeForce RTX 4090 ma 1008 GB/s. To oznacza, że laptop dysponuje mniej więcej 9% przepustowości tej karty, więc odpowiedzi generuje w przybliżeniu jedenaście razy wolniej. Ma za to przewagę pojemności: w 64 GB RAM zmieści większy model niż w 24 GB pamięci RTX 4090.

Szybkości działania nie mierzyłem i nie podaję jej w tym tekście. Interesowała mnie wyłącznie jakość odpowiedzi.

Jakie modele porównałem?

Model	Producent	Rozmiar	Kwantyzacja	Charakterystyka	Do czego się nadaje
Bielik-11B-v3.0-Instruct	SpeakLeash, ACK Cyfronet AGH	11 mld parametrów	Q8	polski model, trenowany z naciskiem na język polski	teksty po polsku, streszczenia, korespondencja
Gemma 3 27B	Google	27 mld	Q4	większy model starszej generacji w mocniejszej kwantyzacji	zadania ogólne, gdy jest dużo pamięci
Gemma 4 12B	Google	12 mld	Q8	mniejszy model nowej generacji	zadania ogólne na laptopie
gpt-oss-20b	OpenAI (otwarte wagi)	20 mld	MXFP4	model z rozumowaniem	zadania wymagające wnioskowania
Qwen3.5-9B	Alibaba	9 mld	Q8	mały model z trybem myślenia	zadania wymagające wnioskowania przy małej ilości pamięci
ChatGPT (GPT-6, rozumowanie średnie)	OpenAI	nieujawniony	—	model w chmurze, punkt odniesienia	porównanie z najlepszym, co jest dostępne

Kwantyzacja to zapis wag modelu z mniejszą precyzją: Q8 oznacza około 8 bitów na wagę, a Q4 około 4 bity, co zmniejsza zapotrzebowanie na pamięć kosztem nieco niższej jakości. Dzięki temu Gemma 3 27B w Q4 mieści się na laptopie, choć ma ponad dwa razy więcej parametrów niż Gemma 4 12B w Q8.

Jak ustawiłem LM Studio?

Wszystkie modele lokalne uruchamiałem z tymi samymi ustawieniami. Poniżej wyjaśniam je językiem analityka, a nie inżyniera uczenia maszynowego.

Parametr	Wartość	Co robi
Temperature	0,1	niska losowość; odpowiedzi są bardziej przewidywalne i mniej „kreatywne”
Top K Sampling	40	przy każdym słowie model wybiera tylko spośród 40 najbardziej prawdopodobnych kontynuacji
Top P Sampling	0,8	odrzuca kontynuacje z „długiego ogona” mało prawdopodobnych
Min P Sampling	0,05	pomija kontynuacje o bardzo niskim prawdopodobieństwie
Repeat Penalty	1,1	zniechęca model do powtarzania tych samych fraz
Presence Penalty	wyłączone	brak dodatkowej kary za powracanie do tematu
Limit Response Length	wyłączone	odpowiedź nie jest ucinana
Context Overflow	Truncate Middle	przy przepełnieniu kontekstu usuwany jest środek rozmowy
Structured Output	wyłączone	model nie jest zmuszany do odpowiedzi w sztywnym formacie danych
System prompt	pusty	cały kontekst przekazuję w treści wiadomości

ChatGPT uruchomiłem w czacie tymczasowym, bez pamięci i bez własnych instrukcji. Temperatury nie da się tam ustawić, co jest jednym z ograniczeń porównania.

Jak wyglądał test?

Każdy model dostał cztery zadania. Każde zadanie uruchamiałem w osobnej, nowej rozmowie i tylko raz. Każda wiadomość zaczynała się od tego samego pakietu kontekstu: karty projektu „Trasa” z potrzebami biznesowymi PB1–PB3 (eliminacja podwójnych rezerwacji, ograniczenie ręcznej pracy, rezerwacja o każdej porze), tabeli wymagań WF-01–WF-06 i WNF-01–WNF-03 oraz specyfikacji przypadku użycia PU-01 „Zarezerwuj pojazd” ze scenariuszem głównym, wyjątkami 1a–9a i pytaniami otwartymi. Treść tych artefaktów odpowiada temu, co pokazałem w poprzednim wpisie.

Po pakiecie następowało jedno z czterech zadań. Każde wymaga stałych sekcji odpowiedzi, co ułatwia porównanie. Każde zawiera też zastrzeżenie, które w poprzednim wpisie uznałem za najważniejsze: „nie zgaduj”.

A1. Model dziedziny (analiza)

Zadanie sprawdza, czy model zbuduje analityczny diagram klas bez wchodzenia w implementację i czy uczciwie wypisze założenia.

Jesteś analitykiem systemowym. Na podstawie kontekstu projektu, wymagań WF-01–WF-06 i przypadku użycia PU-01 zbuduj analityczny model dziedziny jako diagram klas w PlantUML.
Uwzględnij tylko pojęcia biznesowe, ich najważniejsze atrybuty oraz powiązania z licznościami. Pomiń typy danych, klucze, identyfikatory techniczne, metody i wszystko, co dotyczy implementacji.
Odpowiedź podaj w dwóch sekcjach:
1. "Diagram" – jeden blok kodu od @startuml do @enduml.
2. "Założenia" – lista decyzji, których nie potwierdzają materiały; każdą zapisz też jako pytanie do klienta.
Nie uzupełniaj braków domysłami podanymi jako fakty. Wszystko, czego nie wiesz, przenieś do założeń.

A2. Cykl życia rezerwacji i luki w wymaganiach (analiza)

Zadanie sprawdza, czy model opisze stany obiektu i wskaże sytuacje biznesowe, których wymagania nie obsługują.

Jesteś analitykiem systemowym. Na podstawie PU-01 opisz cykl życia obiektu Rezerwacja.
Odpowiedź podaj w dwóch sekcjach:
1. "Tabela przejść" – tabela z kolumnami: stan, zdarzenie, warunek, stan następny. Uwzględnij też stany końcowe.
2. "Luki w wymaganiach" – sytuacje biznesowe, których obecne wymagania i PU-01 nie obsługują. Każdą opisz jednym zdaniem i zapisz jako pytanie do klienta.
Nie wymyślaj wartości liczbowych (np. limitów czasu). Jeśli są potrzebne, oznacz je "do ustalenia".

A3. Modularny monolit czy mikrousługi (architektura)

Zadanie sprawdza, czy model podejmie decyzję architektoniczną z uwzględnieniem realnych ograniczeń projektu.

Jesteś architektem IT. Porównaj dla systemu rezerwacji wypożyczalni "Trasa" dwa warianty: modularny monolit i mikrousługi.
Weź pod uwagę ograniczenia z karty projektu (termin 1 czerwca, budżet 400 tys. zł, jeden informatyk w firmie) oraz wymagania WF-02, WNF-01 i WNF-02.
Odpowiedź podaj w trzech sekcjach:
1. "Porównanie" – tabela: kryterium, modularny monolit, mikrousługi.
2. "Rekomendacja" – jeden wariant i uzasadnienie w maksymalnie 5 zdaniach.
3. "Czego nie wiem" – informacje, których brakuje do podjęcia decyzji.
Nie podawaj kosztów ani liczb, których nie ma w materiałach.

A4. Diagram sekwencji (projektowanie)

Zadanie sprawdza, czy model przełoży przypadek użycia na poprawny diagram sekwencji i świadome decyzje projektowe.

Jesteś projektantem systemu. Dla wariantu "modularny monolit" przygotuj diagram sekwencji w PlantUML dla scenariusza głównego PU-01 oraz wyjątku 6a (brak dostępności w chwili zatwierdzenia).
Uczestnicy: Klient, Aplikacja web, Moduł rezerwacji, Baza danych, Bramka płatności, System księgowy.
Odpowiedź podaj w dwóch sekcjach:
1. "Diagram" – jeden blok kodu od @startuml do @enduml.
2. "Decyzje projektowe" – lista decyzji, które wynikają z diagramu, każda z odwołaniem do wymagania lub wyjątku.
Nie dodawaj uczestników ani funkcji spoza listy i spoza PU-01.

Jak oceniałem odpowiedzi?

Każda odpowiedź dostała wynik z listy kontrolnej, pięć ocen w skali 1–5 i dwa liczniki błędów. Wszystkie odpowiedzi oceniałem według tej samej rubryki i tych samych list kontrolnych.

Kryterium	Skala	Co oznacza
Trafienia z listy kontrolnej	np. 4/6	ile punktów listy kontrolnej zadania znalazło się w odpowiedzi
Poprawność merytoryczna	1–5	czy treść jest zgodna z wiedzą analityczną i materiałami
Zgodność z poleceniem	1–5	wymagane sekcje, format, limity, notacja
Oznaczanie niewiadomych	1–5	czy model mówi „nie wiem” zamiast zgadywać
Język polski	1–5	poprawność i naturalność, terminologia branżowa
Użyteczność jako szkic	1–5	ile pracy trzeba, żeby wynik nadawał się na warsztat z klientem
Zmyślenia	liczba	wymyślone liczby lub fakty podane jako pewne
Nadmiarowy zakres	liczba	funkcje, technologie lub elementy, o które nikt nie prosił

Skala 1–5: 1 = bezużyteczne, 3 = nadaje się po poprawkach, 5 = gotowe do pokazania klientowi.

Listy kontrolne w skrócie:

• A1 (6 pkt): diagram poprawny składniowo; klasy Klient, Rezerwacja, Pojazd, Klasa pojazdu, Oddział, Płatność; odróżnienie klasy pojazdu od konkretnego pojazdu; brak typów danych, kluczy i metod; założenie „klasa czy pojazd”; założenie o oddziale zwrotu lub liczbie płatności.
• A2 (4 pkt): komplet stanów łącznie z realizacją najmu, zakończeniem i nieodebraniem pojazdu; limity czasu „do ustalenia”; co najmniej 3 z 4 luk (zwrot zaliczki przy anulowaniu, zmiana terminu, przedłużenie najmu, zwrot po terminie); brak sprzeczności z PU-01.
• A3 (6 pkt): rekomendacja modularnego monolitu; uzasadnienie odwołujące się do jednego informatyka i terminu; WF-02 jako jedna transakcja w monolicie i problem spójności w mikrousługach; skala (120 pojazdów, 3 oddziały) jako argument; brak wiedzy o interfejsie systemu księgowego lub ruchu w sezonie; brak wymyślonych liczb.
• A4 (6 pkt): diagram poprawny składniowo; wyjątek 6a w bloku alt/else; sprawdzenie i blokada w jednej transakcji; wynik płatności z bramki; asynchroniczne przekazanie do systemu księgowego (9a); tylko uczestnicy z listy.

Wszystkie diagramy PlantUML wyrenderowałem. Jeśli kod się nie renderował, odpowiedź traciła punkt za składnię, niezależnie od tego, jak dobrze wyglądała treść.

Wyniki modeli

Poniżej omawiam każdy model osobno: najpierw tabela ocen, potem komentarz, a na końcu wszystkie cztery odpowiedzi w całości, dokładnie w takiej postaci, w jakiej je otrzymałem. Kolejność odpowiada końcowemu rankingowi.

Gemma 4 12B (Q8)

Zadanie	Lista kontrolna	Poprawność	Zgodność	Niewiadome	Język	Użyteczność	Zmyślenia	Nadmiar
A1 Model dziedziny	6/6	4	4	5	5	4	0	0
A2 Cykl życia	2/4	4	4	5	4	3	0	0
A3 Architektura	6/6	5	5	5	5	5	0	0
A4 Diagram sekwencji	6/6	3	5	4	4	4	0	0

Gemma 4 najlepiej trzymała się poleceń spośród modeli lokalnych. Model dziedziny jest czysty: bez typów, z rozróżnieniem klasy pojazdu i egzemplarza oraz z założeniami zamienionymi na pytania do klienta. W zadaniu architektonicznym zebrała komplet punktów i jako jedyny model lokalny użyła skali firmy jako argumentu: „wystarczająca dla floty 120 pojazdów przy odpowiedniej optymalizacji bazy danych”. Rekomendacja ma dokładnie pięć zdań i trafia w sedno:

„Monolit znacznie łatwiej zapewni spójność danych niezbędną do wyeliminowania podwójnych rezerwacji (WF-02) w ramach jednej transakcji bazy danych.”

Najpoważniejszy błąd jest w diagramie sekwencji, choć lista kontrolna go nie wychwyciła. Model najpierw pobiera płatność (Web -> Bramka: Przetwarzanie płatności (Krok 7)), a dopiero potem sprawdza dostępność i blokuje pojazd. W wyjątku 6a klient zapłaci więc za pojazd, którego już nie ma. Tabela przejść w A2 jest z kolei zbyt uboga: rezerwacja kończy życie w stanie „Potwierdzona”.

Pełna odpowiedź – A1 Model dziedziny:

Diagram

@startuml
skinparam classAttributeIconSize 0class Oddział {
    nazwa
}
class Pojazd {
    status
}
class KlasaPojazdu {
    nazwa
    cena
}
class Klient {
    dane_osobowe
    dane_prawa_jazdy
}
class Rezerwacja {
    numer_rezerwacji
    data_godzina_odbioru
    data_godzina_zwrotu
    status
}
class Płatność {
    kwota
    status
}
Oddział "1" -- "" Pojazd : posiada
KlasaPojazdu "1" -- "" Pojazd : definiuje
Klient "1" -- "" Rezerwacja : dokonuje
Rezerwacja "" -- "1" Oddział : przypisana do
Rezerwacja "*" -- "0..1" Pojazd : dotyczy
Rezerwacja "1" -- "1" Płatność : zawiera
@enduml

Założenia

1. Przypisanie pojazdu: Przyjąłem, że mimo iż klient wybiera klasę pojazdu (PU-01 pkt 3), system w procesie rezerwacji przypisuje konkretny egzemplarz Pojazd do obiektu Rezerwacja, aby umożliwić realizację wymogu WF-02 (blokowanie konkretnego pojazdu).
   • Pytanie do klienta: Czy klient rezerwuje konkretny pojazd, czy klasę pojazdu?
2. Lokalizacja odbioru/zwrotu: Przyjąłem, że odbiór i zwrot odbywają się w tym samym oddziale (rezerwacja jest powiązana z jednym Oddziałem).
   • Pytanie do klienta: Czy odbiór i zwrot mogą odbywać się w różnych oddziałach?
3. Statusy rezerwacji: Przyjąłem, że Rezerwacja posiada statusy takie jak „Oczekuje na płatność” oraz „Potwierdzona”, wynikające bezpośrednio z opisów PU-01 i WF-03.
4. Płatność jako zaliczka: Przyjąłem, że każda rezerwacja ma przypisany jeden obiekt Płatność (zaliczka), który musi zostać potwierdzony, aby status rezerwacji zmienił się na „Potwierdzona”.
5. Czas blokady: Przyjąłem, że pojazd jest blokowany w systemie od momentu rozpoczęcia procesu rezerwacji do czasu zmiany statusu lub wygaśnięcia czasu na płatność (brak precyzyjnych reguł czasowych).
   • Pytanie do klienta: Jak długo pojazd jest blokowany w oczekiwaniu na płatność?
6. Czas przygotowania: Przyjąłem, że system nie uwzględnia automatycznie czasu technicznego na przygotowanie pojazdu między rezerwacjami (brak danych o czasie serwisowym).
   • Pytanie do klienta: Ile czasu potrzeba na przygotowanie pojazdu między zwrotem a kolejnym wydaniem?
7. Weryfikacja uprawnień: Przyjąłem, że dane prawa jazdy są zbierane jako atrybuty klienta, ale system nie wykonuje automatycznej weryfikacji ważności/stażu (brak specyfikacji reguł).
   • Pytanie do klienta: Jakie są wymagania dotyczące wieku kierowcy i stażu prawa jazdy?

Pełna odpowiedź – A2 Cykl życia:

Oto opis cyklu życia obiektu Rezerwacja oraz analiza luk w wymaganiach przygotowane na podstawie dostarczonej dokumentacji.

1. Tabela przejść

Stan początkowy	Zdarzenie	Warunek	Stan następny
Oczekująca na płatność	Płatność potwierdzona	Sukces z systemu płatności	Potwierdzona
Oczekująca na płatność	Płatność odrzucona	Błąd z systemu płatności	Oczekująca na płatność
Oczekująca na płatność	Upływ czasu	Czas > do ustalenia	Anulowana
Potwierdzona	(Stan końcowy)	–	–
Anulowana	(Stan końcowy)	–	–

Uwaga: Stan „Oczekująca na płatność” powstaje w momencie przejścia do kroku 7 (po akceptacji regulaminu i przed otrzymaniem potwierdzenia z systemu płatności).

2. Luki w wymaganiach

1. Czy klient może samodzielnie anulować rezerwację przez system i czy w takim przypadku zaliczka jest automatycznie zwracana?
2. Czy system powinien umożliwiać edycję już istniejącej rezerwacji (np. zmianę terminu lub klasy pojazdu)?
3. Jakie konkretne akcje (np. ręczne potwierdzenie, anulowanie, zmiana statusu) mogą wykonywać pracownicy w panelu dla rezerwacji klientów?
4. Co dzieje się z rezerwacją i dostępnością pojazdu, jeśli klient nie pojawi się w oddziale w wyznaczonym czasie odbioru (tzw. „no-show”)?
5. Czy system ma obsługiwać sytuację zwrotu pojazdu w innym oddziale niż ten, w którym został odebrany?
6. Jak system ma reagować na sytuację, gdy klient chce zarezerwować więcej niż jeden pojazd jednocześnie?
7. Czy system powinien generować dokumenty (np. umowę najmu) do pobrania przez klienta lub wydruku przez pracownika na podstawie danych z rezerwacji?

Pełna odpowiedź – A3 Architektura:

Porównanie

Kryterium	Modularny monolit	Mikrousługi
Złożoność rozwoju	Niższa – łatwiejsze zarządzanie kodem i relacjami między modułami w jednym projekcie.	Wyższa – konieczność obsługi komunikacji sieciowej, API i rozproszonej logiki.
Spójność danych (WF-02)	Wysoka – łatwe zapewnienie transakcyjności ACID przy blokowaniu pojazdów.	Trudniejsza – wymaga implementacji wzorców takich jak Saga lub 2PC dla uniknięcia podwójnych rezerwacji.
Zasoby ludzkie	Odpowiedni dla jednego informatyka – mniejszy narzut na infrastrukturę i DevOps.	Bardzo trudny dla jednej osoby – wymaga zaawansowanej wiedzy o orkiestracji i monitorowaniu wielu usług.
Czas wdrożenia (do 1 czerwca)	Krótszy – szybsze przygotowanie podstawowej infrastruktury i integracja z systemem księgowym.	Dłuższy – duży nakład pracy na konfigurację środowiska przed napisaniem logiki biznesowej.
Dostępność i wydajność (WNF-01, WNF-02)	Dobra – wystarczająca dla floty 120 pojazdów przy odpowiedniej optymalizacji bazy danych.	Bardzo wysoka – pozwala na niezależne skalowanie komponentów, ale może być nadmiarowa dla obecnej skali.

Rekomendacja

Rekomenduję wybór modularnego monolitu. Przy ograniczeniu do jednego informatyka i krótkim terminie (1 czerwca), mikrousługi wprowadziłyby zbyt duży narzut operacyjny i infrastrukturalny, odciągając uwagę od kluczowych funkcji biznesowych. Monolit znacznie łatwiej zapewni spójność danych niezbędną do wyeliminowania podwójnych rezerwacji (WF-02) w ramach jednej transakcji bazy danych. Rozwiązanie to pozwala na szybsze dostarczenie działającego systemu i łatwiejszą integrację z istniejącym systemem księgowym. Modularna struktura pozwoli jednak na ewentualną separację komponentów w przyszłości, gdyby firma znacząco zwiększyła skalę działania.

Czego nie wiem

1. Jakie konkretnie API lub protokoły komunikacyjne oferuje obecny system księgowy (kluczowe dla realizacji WF-06)?
2. Jaki jest przewidywany maksymalny ruch jednoczesny użytkowników (do oszacowania wydajności WNF-01)?
3. Jakie są konkretne wartości „do ustalenia” dla czasu ładowania listy pojazdów oraz dostępności miesięcznej systemu?
4. Czy system księgowy pozwala na asynchroniczne przyjmowanie danych o płatnościach (ważne dla scenariusza 9a)?

Pełna odpowiedź – A4 Diagram sekwencji:

Diagram

@startuml
autonumber
skinparam Style strictumlactor Klient
participant "Aplikacja web" as Web
participant "Moduł rezerwacji" as Modul
database "Baza danych" as DB
participant "Bramka płatności" as Bramka
participant "System księgowy" as Ksiegowy
== Scenariusz główny PU-01 ==
Klient -> Web: Wybór oddziału, daty i godzin (Krok 1)
Web -> Modul: Pobierz dostępne klasy
Modul -> DB: Zapytaj o dostępność w danym terminie
DB --> Modul: Wyniki dostępności
Modul --> Web: Wyświetl klasy i ceny (Krok 2)
Klient -> Web: Wybór klasy pojazdu (Krok 3)
Klient -> Web: Podanie danych osobowych i prawa jazdy (Krok 4)
Web -> Modul: Walidacja danych i przygotowanie podsumowania
Modul --> Web: Podsumowanie i kwota zaliczki (Krok 5)
Klient -> Web: Akceptacja regulaminu i płatność (Krok 6)
Web -> Bramka: Przetwarzanie płatności (Krok 7)
Bramka --> Web: Potwierdzenie sukcesu płatności
Web -> Modul: Finalizacja rezerwacji
alt Wyjątek 6a: Brak dostępności w chwili zatwierdzenia
    Modul -> DB: Sprawdź i zablokuj pojazd (Check-and-Set)
    DB --> Modul: Błąd: Pojazd już zarezerwowany przez inny proces
    Modul --> Web: Komunikat o braku dostępności
    Web --> Klient: Wyświetl komunikat i powrót do kroku 2
else Sukces rezerwacji
    Modul -> DB: Zapisz rezerwację ze statusem „Potwierdzona”
    DB --> Modul: Potwierdzenie zapisu
    Modul --> Web: Sukces finalizacji
    Web --> Klient: Wyślij e-mail z potwierdzeniem i wyświetl sukces (Krok 8)
    Modul -> Ksiegowy: Przekaż dane o płatności (Krok 9)
end
@enduml

Decyzje projektowe

1. Mechanizm „Check-and-Set” w bazie danych: Aby obsłużyć wyjątek 6a oraz spełnić WF-02, system musi wykonywać finalną weryfikację dostępności i blokadę pojazdu w jednej transakcji bazodanowej w momencie finalizacji rezerwacji (tuż przed zapisem), a nie tylko podczas wyświetlania listy.
2. Separacja logiki biznesowej: Wykorzystanie „Modułu rezerwacji” jako dedykowanej warstwy logicznej pozwala na izolację zasad dostępności i walidacji od warstwy prezentacji („Aplikacja web”), co ułatwia utrzymanie systemu przez jednego informatyka (zgodnie z ograniczeniami projektu).
3. Statusowa obsługa płatności: Rezerwacja przechodzi w status „Potwierdzona” dopiero po otrzymaniu sukcesu od „Bramki płatności” i pomyślnym zapisie w bazie danych, co realizuje WF-03.
4. Asynchroniczna integracja z systemem księgowym: Przekazanie danych do „Systemu księgowego” następuje po potwierdzeniu rezerwacji dla klienta. Zgodnie z wyjątkiem 9a, błąd w tym module nie może blokować procesu rezerwacji (rezerwacja pozostaje potwierdzona).
5. Walidacja danych przed podsumowaniem: Moduł rezerwacji waliduje dane osobowe i prawa jazdy przed wyświetleniem kwoty zaliczki, co ogranicza zbędne wywołania bramki płatności i redukuje ręczną pracę pracowników (PB2).

Qwen3.5-9B (Q8)

Zadanie	Lista kontrolna	Poprawność	Zgodność	Niewiadome	Język	Użyteczność	Zmyślenia	Nadmiar
A1 Model dziedziny	6/6	3	4	5	4	3	0	1
A2 Cykl życia	1/4	3	3	4	4	3	0	0
A3 Architektura	5/6	4	5	4	4	4	0	0
A4 Diagram sekwencji	3/6	3	2	3	4	2	0	0

Qwen to najmniejszy model w zestawieniu, a mimo to drugi wśród modeli lokalnych. Dobrze poradził sobie z założeniami w A1 i z argumentacją w A3, gdzie poprawnie wskazał, że WF-02 w mikrousługach wymaga „wzorców rozproszonych transakcji (Saga)”. Słabe są szczegóły. W modelu dziedziny liczności są w kilku miejscach odwrócone lub zbyt ciasne, np.:

Pojazd "1" -- "1" KlasaPojazdu : należy do klasy

Oznacza to, że do jednej klasy należy jeden pojazd. W A2 zabrakło stanów końcowych, a przejście „Konflikt dostępności → Anulowana” jest sprzeczne z blokadą pojazdu z WF-02. Diagram sekwencji się nie renderuje, bo nazwy uczestników ze spacjami nie są ujęte w cudzysłowy (participant Aplikacja web). To typowy błąd, który dla analityka znającego notację jest drobiazgiem, ale dla początkującego oznacza pusty ekran.

Pełna odpowiedź – A1 Model dziedziny:

Diagram

@startuml
left to right direction
skinparam classAttributeIconSize 0class "Klient" {
    +imię i nazwisko
    +dane_prawa_jazdy
}
class "Oddział" {
    +nazwa_oddziału
    +miasto_lokalizacji
}
class "Pojazd" {
    +numer_rejestracyjny
    +stan_dostępności
}
class "KlasaPojazdu" {
    +nazwa_klasy
    +cena_dzienna
}
class "Rezerwacja" {
    +numer_rezerwacji
    +data_odbioru
    +data_zwrotu
    +status
}
class "Płatność" {
    +kwota_zaliczki
    +data_płatności
    +status_płatności
}
class "Pracownik" {
    +imię i nazwisko
    +stanowisko
}
class "ZapisKsięgowy" {
    +numer_zapisu
    +kwota
    +data_wystawienia
}
' Relacje biznesowe
Klient "1" -- "" Rezerwacja : dokonuje
Oddział "1" -- "" Pojazd : posiada
Pojazd "1" -- "1" KlasaPojazdu : należy do klasy
Rezerwacja "1" -- "1" Oddział : dotyczy oddziału (odbioru)
Rezerwacja "1" -- "1" Pojazd : dotyczy pojazdu
Rezerwacja "0..1" -- "1" Płatność : zawiera płatność
Płatność "1" -- "1" ZapisKsięgowy : tworzy zapis
Pracownik "1" -- "*" Oddział : pracuje w
@enduml

Założenia

Poniższa lista zawiera decyzje analityczne, które nie zostały jednoznacznie potwierdzone w dostarczonych materiałach oraz pytania wymagające doprecyzowania z klientem:

1. Rezerwacja konkretnego pojazdu vs klasy: W modelu zakłada się, że rezerwacja jest przypisana do konkretnego Pojazdu (numer rejestracyjny), który należy do danej KlasyPojazdu. Pytanie do klienta: Czy klient wybiera klasę i system losuje wolny pojazd z tej klasy, czy musi wybrać konkretny numer rejestracyjny?
2. Oddział odbioru i zwrotu: W modelu Rezerwacja jest powiązana z jednym Oddziałem. Pytanie do klienta: Czy klient może odebrać pojazd w jednym oddziale (np. Warszawa) i zwrócić go w innym (np. Kraków)? Jeśli tak, model wymaga dodania relacji dla miejsca zwrotu.
3. Czas blokowania pojazdu: Wymagania nie precyzują czasu trwania blokady pojazdu po rezerwacji przed płatnością. Pytanie do klienta: Ile czasu pojazd jest zarezerwowany (zablokowany), ale jeszcze nie potwierdzony płatnością?
4. Wymagania dla kierowcy: Wymagania biznesowe i scenariusz nie określają szczegółów weryfikacji wieku lub stażu prawa jazdy. Pytanie do klienta: Czy system ma blokować rezerwację automatycznie przy niezgodności z wymaganiami (np. wiek < 21 lat), czy to kontrola manualna pracownika?
5. Czas przygotowania pojazdu: Wymagania nie określają czasu potrzebnego na przygotowanie pojazdu po zwrocie. Pytanie do klienta: Czy czas ten wpływa na dostępność w systemie (np. pojazd jest „wolny” dopiero po X godzinach od zwrotu)?
6. System księgowy: W modelu ZapisKsięgowy został przedstawiony jako obiekt powiązany z płatnością, aby uwzględnić wymóg WF-06 o przekazywaniu danych. Pytanie do klienta: Czy system księgowy jest traktowany jako zewnętrzny system (integracja API) czy wewnętrzny moduł?
7. Panel pracownika: Wymagania WF-05 wskazują na widoczność tylko rezerwacji danego oddziału. Pytanie do klienta: Czy pracownik może zarządzać pojazdami w innych oddziałach, czy tylko przeglądać i obsługiwać te z przypisanego mu oddziału?
8. Statusy płatności: Scenariusz PU-01 wspomina o statusie „Oczekuje na płatność” (7a). Pytanie do klienta: Czy rezerwacja może istnieć bez płatności w systemie, czy płatność jest warunkiem koniecznym powstania obiektu Rezerwacja?

Pełna odpowiedź – A2 Cykl życia:

1. Tabela przejść

Stan	Zdarzenie	Warunek	Stan następny
Oczekuje na płatność	Płatność udana	Kwota zaliczki wpłacona zgodnie z regulaminem	Potwierdzona
Oczekuje na płatność	Przekroczenie czasu oczekiwania	Czas od utworzenia rezerwacji przekracza limit do ustalenia	Anulowana
Oczekuje na płatność	Konflikt dostępności pojazdu	Pojazd został zarezerwowany przez innego użytkownika w międzyczasie	Anulowana
Potwierdzona	Odbiór pojazdu	Klient fizycznie przybył do wybranego oddziału i potwierdził odbiór	W trakcie realizacji
W trakcie realizacji	Zwrot pojazdu	Pojazd został zwrócony w wyznaczonym terminie lub wcześniejszym	Zakończona
Potwierdzona	Anulowanie przez klienta	Klient zgłosił chęć anulowania przed momentem odbioru	Anulowana
Oczekuje na płatność	Płatność odrzucona	System płatności zwrócił błąd lub transakcja nie powiodła się	Oczekuje na płatność

2. Luki w wymaganiach

1. Zmiana danych rezerwacji – Obecny proces opisuje tylko tworzenie i anulowanie, brak mechanizmu modyfikacji terminu czy klasy pojazdu po zatwierdzeniu.
   • Czy klient powinien mieć możliwość edycji istniejącej rezerwacji (np. zmiany daty), czy wyłącznie jej anulowania i utworzenia nowej?
2. Zasady anulowania z opłatami – Wymagania definiują potwierdzenie, ale nie określają konsekwencji finansowych ani czasowych dla klienta decydującego się na rezygnację.
   • Jakie są zasady i ewentualne opłaty za anulowanie rezerwacji przez klienta w zależności od czasu upływu przed odbiorem pojazdu?
3. Elastyczność lokalizacji zwrotu – Wymagania zakładają zazwyczaj jeden wybrany oddział, podczas gdy biznesowo może być potrzebna możliwość zwrotu w innym miejscu niż odbiór.
   • Czy klient może wybrać oddział do zwrotu inny niż wybrany przy rezerwacji (odbiorze), czy system ma obsługiwać różne lokalizacje?
4. Zakres danych dla księgowości – System przekazuje dane o płatnościach, ale nie definiuje, czy ma również informować o fakcie rozpoczęcia i zakończenia najmu.
   • Czy system ma informować księgowość o fakcie rozpoczęcia i zakończenia najmu, czy tylko o płatnościach zaliczkowych?

Pełna odpowiedź – A3 Architektura:

Porównanie

Kryterium	Modularny monolit	Mikrousługi
Czas do uruchomienia	Krótszy, jeden kod i baza danych	Dłuższy, wymaga konfiguracji wielu usług i komunikacji między nimi
Złożoność utrzymania dla 1 informatyka	Niska, łatwiejsze debugowanie i wdrożenia	Wysoka, wymaga wiedzy o orkiestracji i sieciach
Integracja z księgowością	Prostsza, jeden punkt integracji	Skomplikowana, wymaga synchronizacji między usługami
Spójność transakcji (WF-02)	Łatwiejsza realizacja w ramach jednej bazy danych	Wymaga wzorców rozproszonych transakcji (Saga), zwiększając ryzyko błędów
Dostępność 24/7 (WNF-02)	Prostsze zarządzanie serwerem aplikacji	Możliwe, ale wymaga zaawansowanego monitorowania i skalowania

Rekomendacja

Rekomenduję wariant modularnego monolitu ze względu na krytyczny termin do 1 czerwca oraz ograniczoną liczbę pracowników IT. Jeden informatyk nie będzie w stanie efektywnie zarządzać infrastrukturą mikrousług, co groziłoby przekroczeniem budżetu i opóźnieniem projektu. Monolit ułatwia realizację wymogu blokowania rezerwacji (WF-02) dzięki transakcjom ACID w jednej bazie danych oraz zapewnia szybsze ładowanie listy pojazdów (WNF-01). Wybór tej architektury pozwoli na szybkie uruchomienie systemu przed sezonem letnim w ramach dostępnego budżetu. Jest to wystarczające rozwiązanie dla obecnej skali floty i nie wymaga nadmiernej złożoności technologicznej.

Czego nie wiem

• Czy system księgowy posiada gotowe API do integracji, czy wymaga dedykowanego modułu?
• Jakie są szacowane obciążenia ruchem w sezonie letnim (np. liczba zapytań na sekundę)?
• Czy płatności odbywają się przez zewnętrzny bramkę płatności wymagającą specyficznej konfiguracji bezpieczeństwa?
• Jaki jest stan techniczny obecnych serwerów i infrastruktury sieciowej firmy?

Pełna odpowiedź – A4 Diagram sekwencji:

Diagram

@startuml
participant Klient
participant Aplikacja web
participant Moduł rezerwacji
participant Baza danych
participant Bramka płatności
participant System księgowyKlient -> Aplikacja web: 1. Wybierz oddział, daty odbioru i zwrotu
Aplikacja web -> Moduł rezerwacji: Sprawdź dostępność pojazdów
Moduł rezerwacji -> Baza danych: Zapytaj o wolne pojazdy
Baza danych --> Moduł rezerwacji: Zwrot listy dostępnych klas
alt Dostępność potwierdzona
    Moduł rezerwacji --> Aplikacja web: Wyświetl dostępne klasy i ceny
    Klient -> Aplikacja web: 2. Wybierz klasę, podaj dane osobowe
    Aplikacja web -> Moduł rezerwacji: Zapisz dane klienta (temp)
alt Walidacja dostępności przed zatwierdzeniem
    Moduł rezerwacji -> Baza danych: Sprawdź aktualną dostępność pojazdu
    Baza danych --> Moduł rezerwacji: Potwierdź dostępność

    alt Dostępność utracona (Wyjątek 6a)
        Moduł rezerwacji --> Klient: Komunikat o braku dostępności
        Klient -> Aplikacja web: Wróć do wyboru pojazdu (Krok 2)
    else Dostępność zachowana
        Moduł rezerwacji --> Aplikacja web: Pokaż podsumowanie i kwotę zaliczki
        Klient -> Aplikacja web: 3. Akceptuj regulamin, inicjuj płatność
        Aplikacja web -> Bramka płatności: Przekieruj do płatności
        Bramka płatności --> Aplikacja web: Potwierdź wpłatę zaliczki
        Aplikacja web -> Moduł rezerwacji: Zapisz rezerwację ze statusem "Potwierdzona"
        Moduł rezerwacji -> Baza danych: Zapisz rezerwację, zablokuj pojazd
        Moduł rezerwacji --> System księgowy: Przekazaj dane o płatności
        Moduł rezerwacji --> Aplikacja web: Wyślij e-mail z potwierdzeniem
        Aplikacja web --> Klient: E-mail z numerem rezerwacji i danymi
    end
else Brak wolnych pojazdów
    Moduł rezerwacji --> Klient: Proponuj inny oddział lub termin
end
end
@enduml

Decyzje projektowe

1. Walidacja dostępności w czasie rzeczywistym przed zapisem – Zabezpieczenie przed podwójnymi rezerwacjami (PB1, WF-02) oraz obsługa wyjątku 6a poprzez ponowne zapytanie do bazy danych tuż przed zatwierdzeniem rezerwacji.
2. Integracja z bramką płatności – Realizacja wymogu płatności zaliczki online (WF-03) poprzez przekierowanie klienta do zewnętrznej usługi płatniczej, a nie ręczne przetwarzanie kart.
3. Automatyzacja komunikacji e-mailowej – Eliminacja ręcznej pracy przy wysyłaniu potwierdzeń (PB2, WF-04) poprzez generowanie wiadomości przez system po udanej rezerwacji.
4. Integracja z systemem księgowym – Automatyczne przekazywanie danych o płatnościach do systemu księgowego (WF-06) w celu zgodności finansowej i raportowania.
5. Zarządzanie stanem rezerwacji – Rezerwacja uzyskuje status „Potwierdzona” dopiero po sukcesie płatności i zapisie w bazie, co chroni przed utratą danych przy awariach (WF-03).
6. Obsługa wyjątków w pętli głównej – W przypadku braku dostępności (wyjątek 6a) system automatycznie informuje klienta i zwraca go do wyboru pojazdu, zamiast blokować proces ręcznie przez pracownika.

Gemma 3 27B (Q4)

Zadanie	Lista kontrolna	Poprawność	Zgodność	Niewiadome	Język	Użyteczność	Zmyślenia	Nadmiar
A1 Model dziedziny	3/6	2	2	4	4	2	0	0
A2 Cykl życia	1/4	2	3	4	3	2	0	4
A3 Architektura	4/6	3	4	5	4	4	0	0
A4 Diagram sekwencji	4/6	3	4	4	4	3	0	0

Gemma 3 ma najwięcej parametrów wśród badanych modeli lokalnych, a jednak przegrała z młodszą i mniejszą Gemmą 4. W A1 zignorowała polecenie pominięcia typów danych (- status : enum (Potwierdzona, OczekujeNaPlatność, Anulowana)). Zgubiła też klasy Klasa pojazdu i Płatność, przez co model dziedziny nie oddaje kluczowej decyzji o rezerwacji klasy. W A2 pomieszała cykl życia obiektu z krokami ekranu („Wybór klasy pojazdu”, „Podanie danych osobowych”). Najbardziej charakterystyczny jest jednak rozrost zakresu w lukach w wymaganiach:

„Czy istnieje możliwość integracji systemu z mapami Google w celu wyświetlania lokalizacji oddziałów i dostępnych pojazdów?”

To dokładnie to, przed czym ostrzegałem w poprzednim wpisie: model dorzuca funkcje, o które nikt nie prosił. Za to część architektoniczna i diagram sekwencji są poprawne i nadają się do dalszej pracy.

Pełna odpowiedź – A1 Model dziedziny:

Diagram

@startuml
class Oddział {
    - nazwa : string
}class Pojazd {
    - klasa : string
    - numerRejestracyjny : string
}
class Rezerwacja {
    - numerRezerwacji : string
    - dataOdbioru : datetime
    - dataZwrotu : datetime
    - status : enum (Potwierdzona, OczekujeNaPlatność, Anulowana)
    - kwotaZaliczki : decimal
}
class Klient {
    - imie : string
    - nazwisko : string
    - email : string
    - numerPrawaJazdy : string
}
Oddział "1" -- "*" Pojazd : posiada
Rezerwacja "1" -- "1" Oddział : dotyczy
Rezerwacja "1" -- "1" Klient : dokonana przez
Rezerwacja "1" -- "1" Pojazd : obejmuje
note top of Rezerwacja: Status rezerwacji zmienia się w zależności od płatności i czasu.
@enduml

Założenia

Poniżej lista decyzji, których nie potwierdzają materiały oraz pytania do klienta:

• Czy klient rezerwuje konkretny pojazd, czy klasę pojazdu? (Zgodnie z przypadkiem użycia PU-01 klient wybiera klasę pojazdu. Jednak w WF-01 system pokazuje wolne pojazdy, a nie klasy pojazdów.)
  • Pytanie do klienta: Czy rezerwacja dotyczy konkretnego pojazdu o danym numerze rejestracyjnym, czy tylko wybranej klasy pojazdu?
• Czy odbiór i zwrot mogą odbywać się w różnych oddziałach? (Brak informacji na ten temat.)
  • Pytanie do klienta: Czy klient ma możliwość odebrać pojazd w jednym oddziale, a zwrócić w innym?
• Jak długo pojazd jest blokowany w oczekiwaniu na płatność? (W przypadku odrzucenia płatności rezerwacja przechodzi w status „OczekujeNaPlatność”, ale nie wiadomo jak długo trwa ten stan.)
  • Pytanie do klienta: Ile czasu pojazd jest blokowany dla innych klientów, gdy rezerwacja ma status „Oczekuje na płatność”?
• Czy istnieje możliwość zmiany rezerwacji? (Brak informacji o możliwości modyfikacji rezerwacji po jej dokonaniu.)
  • Pytanie do klienta: Czy klienci będą mieli możliwość zmiany daty, godziny odbioru/zwrotu lub klasy pojazdu po dokonaniu rezerwacji?
• Czy system ma obsługiwać kaucje? (Wymagania mówią o zaliczce, ale nie wspominają o ewentualnej kaucji.)
  • Pytanie do klienta: Czy oprócz zaliczki pobierana jest również kaucja za pojazd?
• Czy system ma obsługiwać dodatkowe usługi (np. ubezpieczenie)? (Brak informacji na ten temat.)
  • Pytanie do klienta: Czy klienci będą mogli dokupić dodatkowe usługi, takie jak ubezpieczenie lub fotelik dla dziecka podczas rezerwacji?
• Czy system ma obsługiwać rabaty/promocje? (Brak informacji na ten temat.)
  • Pytanie do klienta: Czy w systemie będą dostępne rabaty lub promocje dla klientów?
• Jakie są wymagania dotyczące wieku kierowcy i stażu prawa jazdy? (Wymagania wspominają o danych prawa jazdy, ale nie określają minimalnego wieku ani stażu.)
  • Pytanie do klienta: Jakie są minimalne wymagania wiekowe i stażowe dla kierowców wypożyczających pojazdy?
• Ile czasu potrzeba na przygotowanie pojazdu między zwrotem a kolejnym wydaniem? (Brak informacji o czasie potrzebnym na przegląd/przygotowanie pojazdu po zwrocie.)
  • Pytanie do klienta: Ile czasu zajmuje przygotowanie pojazdu po jego zwrocie, zanim będzie gotowy do ponownego wypożyczenia?
• Czy system ma obsługiwać listę oczekujących na rezerwację danego pojazdu/klasy pojazdu? (Brak informacji o takiej funkcjonalności.)
  • Pytanie do klienta: Czy klienci będą mieli możliwość zapisania się na listę oczekujących w przypadku braku dostępności pojazdów?

Pełna odpowiedź – A2 Cykl życia:

Cykl życia obiektu Rezerwacja

1. Tabela przejść

Stan	Zdarzenie	Warunek	Stan następny
Nowa	Wybór oddziału, daty i godziny odbioru/zwrotu	–	Wybór klasy pojazdu
Wybór klasy pojazdu	Brak wolnych pojazdów	–	Brak dostępności
Wybór klasy pojazdu	Wybór klasy pojazdu	–	Podanie danych osobowych
Podanie danych osobowych	Wprowadzenie danych osobowych i prawa jazdy	Dane poprawne	Podsumowanie rezerwacji
Podanie danych osobowych	Błąd walidacji danych	–	Podanie danych osobowych (z komunikatem o błędzie)
Podsumowanie rezerwacji	Akceptacja regulaminu	–	Przekierowanie do płatności
Przekierowanie do płatności	Udana płatność	–	Potwierdzona
Przekierowanie do płatności	Płatność odrzucona	–	Oczekuje na płatność
Oczekuje na płatność	Ponowna próba płatności (udana)	–	Potwierdzona
Oczekuje na płatność	Brak płatności w ciągu [do ustalenia]	–	Anulowana
Potwierdzona	System księgowy dostępny	–	Zaksięgowana
Potwierdzona	System księgowy niedostępny	–	Potwierdzona (ponawianie przekazania danych)
Brak dostępności	Propozycja innego oddziału/terminu zaakceptowana	–	Wybór klasy pojazdu
Brak dostępności	Klient rezygnuje z rezerwacji	–	Anulowana
Anulowana	–	–	Końcowy: Anulowana
Zaksięgowana	–	–	Końcowy: Zaksiękowana

2. Luki w wymaganiach

• Czy system powinien automatycznie wysyłać przypomnienie o odbiorze pojazdu klientowi na dzień przed planowanym odbiorem?
• Jakie działania podejmuje pracownik oddziału, gdy klient nie odbierze zarezerwowanego pojazdu w ustalonym terminie?
• Czy system powinien umożliwiać modyfikację rezerwacji (np. zmiana daty odbioru/zwrotu)?
• Czy istnieje możliwość anulowania rezerwacji przez klienta online i jakie są związane z tym ewentualne opłaty?
• Jak system obsługuje sytuacje, gdy klient zgłosi uszkodzenia pojazdu przy odbiorze lub zwrocie?
• Czy system powinien uwzględniać różne taryfy cenowe w zależności od sezonu, dnia tygodnia lub długości rezerwacji?
• Czy istnieje możliwość dodania dodatkowych opcji do rezerwacji (np. ubezpieczenie, fotelik dziecięcy)?
• Jakie informacje o pojeździe są wyświetlane klientowi podczas wyboru klasy pojazdu (np. model, pojemność silnika, wyposażenie)?
• Czy system powinien umożliwiać pracownikom oddziału dodawanie i usuwanie pojazdów z floty?
• Czy istnieje możliwość integracji systemu z mapami Google w celu wyświetlania lokalizacji oddziałów i dostępnych pojazdów?

Pełna odpowiedź – A3 Architektura:

Porównanie Modularny Monolit vs. Mikrousługi dla Systemu Rezerwacji „Trasa”

1. Porównanie

Kryterium	Modularny Monolit	Mikrousługi
Szybkość rozwoju i wdrożenia	Wysoka – jeden kod, łatwiejsze testowanie i wdrażanie początkowe.	Niższa – wiele niezależnych usług do opracowania, konfiguracji i integracji.
Skalowalność	Ograniczona – skaluje się cały system, nawet jeśli tylko jedna część wymaga większej mocy obliczeniowej.	Wysoka – każda usługa może być skalowana niezależnie w zależności od obciążenia.
Złożoność operacyjna	Niższa – jeden proces wdrażania i monitorowania.	Wyższa – wiele procesów, infrastruktura do zarządzania usługami (np. konteneryzacja, orkiestracja).
Odporność na awarie	Niższa – awaria jednego modułu może wpłynąć na cały system.	Wyższa – awaria jednej usługi nie musi wpływać na działanie innych.
Technologie	Jednolita – łatwiejsze utrzymanie i rozwój w jednym języku/frameworku.	Różnorodna – możliwość wykorzystania różnych technologii dla poszczególnych usług, ale zwiększa to złożoność.
Integracja z systemem księgowym (WF-06)	Relatywnie prosta – jeden punkt integracji.	Bardziej skomplikowana – wymaga integracji każdej usługi odpowiedzialnej za płatności i dane finansowe.
Wydajność (WNF-01)	Trudniejsza optymalizacja pod konkretne funkcjonalności.	Łatwiejsza optymalizacja poszczególnych usług, np. usługa rezerwacji może być zoptymalizowana pod szybkie ładowanie listy wolnych pojazdów.
Dostępność (WNF-02)	Trudniejsza – prace serwisowe wymagają wyłączenia całego systemu lub jego części.	Łatwiejsza – możliwość wdrażania zmian i aktualizacji poszczególnych usług bez wpływu na działanie innych.
Zarządzanie danymi	Centralne – potencjalnie łatwiejsze zarządzanie spójnością danych.	Rozproszone – wymaga starannego planowania integracji danych między usługami.
Wymagany poziom kompetencji zespołu	Niższy – jeden informatyk może ogarnąć cały system.	Wyższy – wymagana wiedza z zakresu architektury rozproszonej, DevOps i zarządzania infrastrukturą.

2. Rekomendacja

Rekomenduję modularny monolit. Biorąc pod uwagę ograniczony budżet, krótki termin wdrożenia (1 czerwca) oraz fakt, że firma posiada tylko jednego informatyka, modularny monolit jest bardziej realistyczną opcją. Umożliwi on szybkie opracowanie i wdrożenie systemu spełniającego podstawowe potrzeby biznesowe (PB1-PB3), a także łatwiejszą integrację z istniejącym systemem księgowym (WF-06). Monolit pozwoli na efektywne wykorzystanie zasobów informatyka, skupiając się na implementacji kluczowych funkcjonalności. W przyszłości, po zdobyciu doświadczenia i zwiększeniu budżetu, można rozważyć stopniowe przechodzenie do architektury mikrousług.

3. Czego nie wiem

Do podjęcia ostatecznej decyzji brakuje mi następujących informacji: * Szczegółowy zakres funkcjonalności systemu księgowego i możliwości integracji: Jakie API oferuje system księgowy? Czy wymaga on specyficznych formatów danych? * Oczekiwane obciążenie systemu w szczycie sezonu letniego: Jaka jest przewidywana liczba rezerwacji dziennie/miesięcznie? To pomoże ocenić, czy skalowalność monolitu będzie wystarczająca. * Dokładne wymagania dotyczące czasu ładowania listy wolnych pojazdów (WNF-01): 2 sekundy to wstępna propozycja – czy jest to wartość krytyczna? * Poziom zaawansowania technicznego informatyka: Jakie technologie zna i w jakich czuje się komfortowo? * Planowane rozszerzenia funkcjonalności systemu w przyszłości: Czy przewidywane są nowe usługi, które mogłyby być lepiej zaimplementowane jako mikrousługi? * Dokładna definicja „klasy pojazdu”: Czy klient rezerwuje konkretny model samochodu, czy tylko ogólną klasę (np. kompaktowy)? To wpływa na złożoność logiki blokowania rezerwacji (WF-02).

Pełna odpowiedź – A4 Diagram sekwencji:

Diagram

@startuml
participant Klient
participant "Aplikacja web" as WebApp
participant "Moduł rezerwacji" as Rezerwacje
participant "Baza danych" as DB
participant "Bramka płatności" as Platnosc
participant "System księgowy" as Ksiegowyactivate Klient
Klient -> WebApp : Wybiera oddział, datę i godzinę odbioru/zwrotu
WebApp -> Rezerwacje : Sprawdź dostępność pojazdów
Rezerwacje -> DB : Zapytanie o dostępne klasy pojazdów
DB --> Rezerwacje : Lista dostępnych klas pojazdów z cenami
Rezerwacje --> WebApp : Wyświetl listę klas pojazdów
activate WebApp
Klient -> WebApp : Wybiera klasę pojazdu
WebApp -> Rezerwacje : Zarezerwuj pojazd (klasa, oddział, termin)
Rezerwacje -> DB : Sprawdź dostępność konkretnego pojazdu w wybranej klasie
alt Brak wolnych pojazdów (6a)
    DB --> Rezerwacje : Brak dostępności
    Rezerwacje --> WebApp : Informacja o braku dostępności
    WebApp -> Klient : Proponuje inny oddział/termin
else Dostępny pojazd
    DB --> Rezerwacje : Potwierdzenie dostępności
    Rezerwacje -> DB : Zablokuj pojazd na wybrany termin
    DB --> Rezerwacje : Potwierdzenie blokady
    Rezerwacje -> WebApp : Wyświetl podsumowanie i kwotę zaliczki
end
Klient -> WebApp : Podaje dane osobowe, akceptuje regulamin
WebApp -> Rezerwacje : Zapisz dane rezerwacji (status: Oczekuje na płatność)
Rezerwacje -> DB : Zapisz dane rezerwacji
DB --> Rezerwacje : Potwierdzenie zapisu
WebApp -> Platnosc : Przekaż dane do płatności
activate Platnosc
Platnosc -> WebApp : Potwierdzenie wpłaty (status: Potwierdzona)
deactivate Platnosc
Rezerwacje -> DB : Zaktualizuj status rezerwacji na "Potwierdzona"
DB --> Rezerwacje : Potwierdzenie aktualizacji
Rezerwacje -> Ksiegowy : Przekaż dane o płatności
Ksiegowy --> Rezerwacje : Potwierdzenie przyjęcia danych
Rezerwacje --> WebApp : Wyślij e-mail z potwierdzeniem rezerwacji
WebApp -> Klient : E-mail z potwierdzeniem
deactivate WebApp
deactivate Rezerwacje
@enduml

Decyzje projektowe

• Dostępność pojazdów w czasie rzeczywistym (WF-01, WF-02): Moduł rezerwacji musi sprawdzać dostępność pojazdów bezpośrednio w bazie danych przed każdym zatwierdzeniem rezerwacji. Blokada pojazdu w bazie danych jest kluczowa dla eliminacji podwójnych rezerwacji.
• Blokada tymczasowa (wyjątek 6a, pytanie otwarte 1): Diagram pokazuje scenariusz braku dostępności po zatwierdzeniu wyboru klasy pojazdu. Należy zdefiniować czas blokady pojazdu w oczekiwaniu na płatność i mechanizm automatycznego odblokowania w przypadku niepowodzenia płatności (wyjątek 7b).
• Rezerwacja klasy, a nie konkretnego pojazdu (pytanie otwarte 2): Diagram zakłada rezerwację klasy pojazdu. Moduł rezerwacji sprawdza dostępność konkretnego pojazdu w wybranej klasie i blokuje go.
• Integracja z systemem księgowym (WF-06): Moduł rezerwacji przekazuje dane o płatności do systemu księgowego po potwierdzeniu wpłaty przez bramkę płatności. Należy uwzględnić scenariusz niedostępności systemu księgowego (wyjątek 9a) i mechanizm ponownego wysyłania danych.
• Status rezerwacji (WF-03, wyjątek 7a): Rezerwacja przechodzi przez status „Oczekuje na płatność” do „Potwierdzona”. W przypadku odrzucenia płatności status zmienia się na „Oczekuje na płatność”, umożliwiając ponowną próbę.
• Zapis danych rezerwacji (WF-04): Moduł rezerwacji zapisuje dane osobowe klienta i szczegóły rezerwacji w bazie danych, co jest niezbędne do wysyłki potwierdzenia e-mail.
• Komunikacja z klientem: Aplikacja web odpowiada za komunikację z klientem (wyświetlanie informacji, prośby o dane). Moduł rezerwacji przekazuje informacje do aplikacji web w celu wyświetlenia ich użytkownikowi.

gpt-oss-20b (MXFP4)

Zadanie	Lista kontrolna	Poprawność	Zgodność	Niewiadome	Język	Użyteczność	Zmyślenia	Nadmiar
A1 Model dziedziny	4/6	2	3	4	2	2	0	1
A2 Cykl życia	1/4	2	3	4	4	2	0	0
A3 Architektura	5/6	4	5	4	3	4	0	0
A4 Diagram sekwencji	3/6	2	3	3	3	2	0	0

Po modelu z rozumowaniem spodziewałem się więcej. Najlepiej wypadła część architektoniczna: porównanie jest rzeczowe, wskazuje, że w mikrousługach blokada rezerwacji wymaga dodatkowego mechanizmu, a rekomendacja jest krótka i trafna:

„Monolit zapewnia natychmiastową integralność danych (WF‑02) oraz krótsze czasy odpowiedzi przy pobieraniu dostępnych pojazdów (WNF‑01).”

W pozostałych zadaniach model miał problemy. Mimo polskiego kontekstu nazwał klasy po angielsku (Customer, Reservation, Vehicle), pominął klasę pojazdu jako osobne pojęcie i zdublował powiązania (Reservation "*" -- "1" Vehicle : for > oraz Vehicle "1" -- "*" Reservation : scheduled in >). W cyklu życia rezerwacji pomieszał stany obiektu z krokami formularza, a stan „Zakończona” oznacza u niego przekazanie danych do księgowości. Diagram sekwencji zszedł na poziom zapytań SQL (SELECT * FROM Pojazdy WHERE Oddział = ? AND Dostępny = true), a wyjątek 6a pokazał jako osobny fragment bez bloku alt/else, w dodatku ze sprawdzeniem dostępności dopiero po autoryzacji płatności. Mocną stroną jest dyscyplina: model nie wymyślił żadnej liczby, a niewiadome zamienił na pytania.

Pełna odpowiedź – A1 Model dziedziny:

Diagram

@startuml
' Business conceptsclass Customer {
  +name
  +email
  +driverLicenseNumber
}
class Branch {
  +location
  +workingHours
}
class Vehicle {
  +model
  +registrationNumber
  +vehicleClass
}
class Reservation {
  +reservationDate
  +pickupDateTime
  +returnDateTime
  +status   ' (e.g. Pending, Confirmed, Cancelled)
}
class Payment {
  +amount
  +paymentDate
  +status   ' (e.g. Completed, Failed, Awaiting)
}
class AccountingSystem {
  +name
}
' Relationships
Customer "1" -- "" Reservation : makes >
Reservation "" -- "1" Vehicle : for >
Vehicle "1" -- "" Reservation : scheduled in >
Vehicle "1" -- "1" Branch : located at >
Branch "1" -- "" Vehicle : owns >
Branch "1" -- "*" Reservation : manages >
Reservation "1" -- "1" Payment : has >
Payment "1" -- "1" AccountingSystem : reported to >
@enduml

Założenia

1. Czy klient rezerwuje konkretny pojazd, czy tylko klasę pojazdu?
2. Jak długo pojazd jest blokowany w oczekiwaniu na płatność (czas od momentu utworzenia rezerwacji do jej potwierdzenia)?
3. Czy odbiór i zwrot mogą odbywać się w różnych oddziałach?
4. Jaki jest minimalny czas przygotowania pojazdu między zwrotem a kolejnym wydaniem?
5. Jakie są wymagania dotyczące wieku kierowcy oraz stażu prawa jazdy (np. ograniczenia wiekowe, dodatkowe opłaty)?
6. Czy system księgowy posiada interfejs API do przyjmowania danych płatności, czy wymaga ręcznego importu?
7. Jakie informacje powinny być zawarte w e‑mailowym potwierdzeniu rezerwacji (np. numer rezerwacji, szczegóły pojazdu, adres URL do zarządzania rezerwacją)?
8. Czy istnieje potrzeba obsługi różnych walut i metod płatności?
9. Jakie są kryteria blokowania pojazdu w przypadku podwójnej rezerwacji (np. pełny czas wynajmu czy tylko część dnia)?
10. Czy system musi przechowywać historię zmian statusu rezerwacji oraz powiązanych płatności?

Pełna odpowiedź – A2 Cykl życia:

1. Tabela przejść – cykl życia obiektu Rezerwacja

Stan początkowy	Zdarzenie (wyzwalacz)	Warunek (jeśli dotyczy)	Stan końcowy
Nowa (rezerwacja utworzona, brak płatności)	Klient wybiera oddział i termin	–	Weryfikacja dostępności
Weryfikacja dostępności	System sprawdza wolność pojazdu w wybranym terminie	Pojazd jest wolny	Kwalifikowana
Weryfikacja dostępności	System sprawdza wolność pojazdu	Pojazd nie jest wolny (inny klient zarezerwował)	Brak dostępności
Brak dostępności	Klient wybiera inny oddział/termin	–	Weryfikacja dostępności
Kwalifikowana	Klient podaje dane i akceptuje regulamin	–	Płatność w toku
Płatność w toku	System płatności potwierdza wpłatę	Płatność zatwierdzona	Potwierdzona
Płatność w toku	System płatności odrzuca płatność	–	Oczekuje na płatność
Oczekuje na płatność	Klient ponawia płatność	Płatność zatwierdzona	Potwierdzona
Oczekuje na płatność	Brak płatności w czasie do ustalenia	–	Anulowana (brak płatności)
Potwierdzona	System przekazuje dane do księgowości	Księgowość dostępna	Zakończona
Potwierdzona	Księgowość niedostępna	–	Potwierdzona (z zapisem w kolejce)
Anulowana (brak płatności)	Klient rezerwuje ponownie	–	Nowa
Brak dostępności	System proponuje alternatywę	–	Weryfikacja dostępności

Opis stanów

Stan	Krótki opis
Nowa	Rezerwacja utworzona, klient dopiero wprowadza dane.
Weryfikacja dostępności	System sprawdza, czy wybrany pojazd jest wolny na podane terminy.
Kwalifikowana	Pojazd jest wolny; klient przechodzi do podania danych i akceptacji regulaminu.
Brak dostępności	Nie ma wolnego pojazdu w wybranym terminie – klient musi zmienić wybór.
Płatność w toku	Klient płaci zaliczkę; system czeka na potwierdzenie od bramki płatniczej.
Oczekuje na płatność	Płatność nie została dokonana w wyznaczonym czasie – rezerwacja pozostaje aktywna, ale z statusem oczekiwania.
Potwierdzona	Płatność zatwierdzona; pojazd blokowany na termin; system wysyła e‑mail i przekazuje dane księgowości.
Anulowana (brak płatności)	Rezerwacja anulowana, gdy klient nie zapłaci w wyznaczonym czasie.
Zakończona	Rezerwacja zakończona sukcesem; wszystkie integracje zakończone.

2. Luki w wymaganiach – pytania do klienta

1. Jak długo pojazd jest blokowany w oczekiwaniu na płatność?
   Pytanie: „Do jakiego czasu ma być utrzymany status ‘Oczekuje na płatność’ przed automatycznym anulowaniem rezerwacji?”
2. Czy klient rezerwuje konkretny pojazd, czy tylko klasę pojazdu?
   Pytanie: „Czy w systemie powinna być możliwość wyboru konkretnego pojazdu (np. numer VIN) zamiast jedynie klasy pojazdu?”
3. Czy odbiór i zwrot mogą odbywać się w różnych oddziałach?
   Pytanie: „Czy klient ma prawo odebrać pojazd w jednym oddziale, a zwrócić w innym?”
4. Ile czasu potrzeba na przygotowanie pojazdu między zwrotem a kolejnym wydaniem?
   Pytanie: „Jak długi jest minimalny czas serwisowy/oczyszczania pomiędzy dwoma rezerwacjami tego samego pojazdu?”
5. Jakie są wymagania dotyczące wieku kierowcy i stażu prawa jazdy?
   Pytanie: „Czy istnieją ograniczenia wiekowe lub minimalny staż prawa jazdy, które muszą być sprawdzone przy rezerwacji?”
6. Co się dzieje z płatnością, jeśli system księgowy jest niedostępny w momencie przekazania danych?
   Pytanie: „Czy rezerwacja ma pozostać potwierdzona i czy powinna być automatycznie ponawiana próba integracji po przywróceniu dostępności księgowości?”
7. Jakie są procedury anulowania rezerwacji przez klienta przed odbiorem pojazdu?
   Pytanie: „Czy klient może samodzielnie anulować rezerwację online, a jeśli tak – czy ma to wpływ na zwrot zaliczki?”
8. Czy istnieje limit liczby jednoczesnych rezerwacji w systemie (np. dla testów obciążeniowych)?
   Pytanie: „Jak duże obciążenie systemu przewiduje firma, abyśmy mogli ustalić odpowiednie parametry skalowalności?”
9. Czy klient ma możliwość zmiany terminu lub klasy pojazdu po złożeniu rezerwacji?
   Pytanie: „Czy w systemie powinna być funkcja modyfikacji istniejącej rezerwacji (zmiana daty, klasy, itp.)?”
10. Jakie informacje o kliencie muszą być przechowywane i jak długo?
    Pytanie: „Na jaki okres mają być zachowane dane osobowe klienta zgodnie z RODO oraz wewnętrznymi politykami firmy?”

Pełna odpowiedź – A3 Architektura:

1. Porównanie

Kryterium	Modularny monolit	Mikrousługi
Rozwój i wdrożenie	Jeden kod‑base, jeden build → łatwiejsze dla jednego informatyka; szybszy start projektu.	Wymaga podziału na kilka repozytoriów/komponentów; więcej konfiguracji CI/CD, co zwiększa czas przygotowania.
Zgodność z wymaganiami WF‑02	Blokowanie rezerwacji realizowane w jednej bazie danych → prostsze zapewnienie integralności i szybsze odrzucanie konfliktów.	Każda usługa może mieć własną bazę; wymaga dodatkowego mechanizmu (np. distributed lock) do zapobiegania podwójnym rezerwacjom, co zwiększa złożoność.
Czas ładowania listy wolnych pojazdów (WNF‑01)	Jedna baza danych i jeden serwer → mniejsze opóźnienia przy odczycie; łatwiejsze optymalizacje indeksów.	Rozproszone zapytania do kilku usług mogą wprowadzić dodatkowe latencje; wymaga cache’owania lub agregacji wyników.
Dostępność 24/7 (WNF‑02)	Cały system działa na jednym serwerze → jednorazowa awaria powoduje przestój całej aplikacji.	Usługi mogą być skalowane niezależnie i restartowane pojedynczo; łatwiejsza izolacja błędów, ale wymaga bardziej zaawansowanego monitoringu i orkiestracji.
Integracja z systemem księgowym	Jedna warstwa integracyjna → prostsze utrzymanie połączenia.	Każda usługa może potrzebować własnego adaptera; zwiększa liczbę punktów integracyjnych, ale pozwala na niezależne aktualizacje.
Zarządzanie danymi osobowymi (RODO)	Jedna baza danych → łatwiejsze audytowanie i kontrola dostępu.	Rozproszone dane wymagają koordynacji polityk bezpieczeństwa w wielu usługach, co podnosi ryzyko błędów konfiguracyjnych.
Zarządzanie zespołem (1 informatyk)	Jeden projekt → mniejsze obciążenie administracyjne i łatwiejsze zarządzanie kodem.	Wymaga podziału na zespół/role, co może być trudne przy ograniczonej liczbie osób.
Czas wdrożenia do 1 czerwca	Krótszy cykl rozwoju → większa szansa spełnienia terminu.	Dłuższy czas przygotowania infrastruktury i testów integracyjnych, co ryzykuje opóźnienie.

2. Rekomendacja

Zalecam modularny monolit.
Jest on prostszy do zbudowania i utrzymania przy jednym informatyku oraz pozwala szybciej spełnić wymóg uruchomienia 1 czerwca. Monolit zapewnia natychmiastową integralność danych (WF‑02) oraz krótsze czasy odpowiedzi przy pobieraniu dostępnych pojazdów (WNF‑01). Rozproszone usługi w mikrousługach zwiększałyby złożoność i ryzyko opóźnień, co nie jest zgodne z ograniczeniami budżetowymi i czasowymi.

3. Czego nie wiem

1. Czy istnieje już infrastruktura (np. konteneryzacja, orkiestracja) w firmie, która mogłaby wspierać mikrousługi?
2. Jakie są dokładne wymagania dotyczące skalowalności – czy przewiduje się duży wzrost liczby rezerwacji po sezonie letnim?
3. Czy system księgowy posiada API umożliwiające łatwe integracje, czy wymaga ręcznego eksportu danych?
4. Jakie są oczekiwania dotyczące dostępności (downtime) w okresach szczytowych – czy 24/7 jest absolutnym wymaganiem, czy wystarczy minimalne przestoje?
5. Czy istnieją już procesy testowe i CI/CD, które można wykorzystać przy wdrożeniu jednej aplikacji lub wielu usług?

Pełna odpowiedź – A4 Diagram sekwencji:

Diagram

@startuml
actor Klientparticipant "Aplikacja web" as WebApp
participant "Moduł rezerwacji" as Rezervacja
participant "Baza danych" as BD
participant "Bramka płatności" as PayGate
participant "System księgowy" as Księgowość
== Scenariusz główny PU‑01 ==
Klient -> WebApp : Wybór oddziału i terminów
WebApp -> Rezervacja : Pobierz dostępne klasy pojazdów (oddział, data)
Rezervacja -> BD : SELECT * FROM Pojazdy WHERE Oddział = ? AND Dostępny = true
BD --> Rezervacja : Lista klas z cenami
Rezervacja --> WebApp : Wyświetl klasy i ceny
Klient -> WebApp : Wybór klasy pojazdu
WebApp -> Rezervacja : Zarezerwuj tymczasowo (klasa, termin)
Rezervacja -> BD : INSERT INTO Rezerwacje (...) VALUES (..., status='Oczekuje')
BD --> Rezervacja : Potwierdzenie wstawienia
Klient -> WebApp : Podanie danych osobowych i prawa jazdy
WebApp -> Rezervacja : Zapisz dane klienta (idRezerwacji)
Rezervacja -> BD : UPDATE Rezerwacje SET DaneKlienta = ? WHERE Id = ?
BD --> Rezervacja : Potwierdzenie
Klient -> WebApp : Podsumowanie i kwota zaliczki
WebApp -> Rezervacja : Pobierz kwotę (klasa, termin)
Rezervacja -> BD : SELECT CenaZaliczki FROM Ceny WHERE Klasa = ?
BD --> Rezervacja : Kwota
Rezervacja --> WebApp : Wyświetl podsumowanie
Klient -> WebApp : Akceptuje regulamin i przechodzi do płatności
WebApp -> PayGate : Przekaż dane płatności (kwota, idRezerwacji)
PayGate --> PayGate : Autoryzacja
PayGate --> WebApp : Status=OK
WebApp -> Rezervacja : Aktualizuj status na 'Potwierdzona'
Rezervacja -> BD : UPDATE Rezerwacje SET Status='Potwierdzona' WHERE Id = ?
BD --> Rezervacja : Potwierdzenie
Rezervacja -> Księgowość : Przekaż informację o płatności (idRezerwacji, kwota)
Księgowość --> Rezervacja : Potwierdzenie
Rezervacja --> WebApp : Powiadom klienta o potwierdzeniu
WebApp --> Klient : Wyślij e‑mail z potwierdzeniem
== Wyjątek 6a – brak dostępności w chwili zatwierdzania ==
Klient -> WebApp : Akceptuje regulamin i przechodzi do płatności
WebApp -> PayGate : Przekaż dane płatności (kwota, idRezerwacji)
PayGate --> PayGate : Autoryzacja
PayGate --> WebApp : Status=OK
WebApp -> Rezervacja : Sprawdź dostępność klasy w terminie
Rezervacja -> BD : SELECT COUNT(*) FROM Rezerwacje WHERE Klasa = ? AND Termin = ? AND Status <> 'Anulowana'
BD --> Rezervacja : Liczba (np. 0)
Rezervacja --> WebApp : Brak dostępności – komunikat
WebApp --> Klient : Wyświetl komunikat i powróć do kroku 2
@enduml

Decyzje projektowe

Decyzja	Opis	Odwołanie
Tymczasowa rezerwacja przy wyborze klasy	System tworzy w bazie rekord z statusem „Oczekuje” zanim klient przejdzie do płatności, aby uniknąć podwójnych rezerwacji.	WF‑01, WF‑02
Blokowanie pojazdu po potwierdzeniu płatności	Po otrzymaniu pozytywnego zwrotu z bramki płatności status zmieniany na „Potwierdzona” i pojazd jest blokowany na termin.	PB1, WF‑02
Weryfikacja dostępności w momencie zatwierdzania (wyjątek 6a)	System ponownie sprawdza liczbę rezerwacji dla klasy/terminu po autoryzacji płatności; jeśli brak wolnych pojazdów, informuje klienta i wraca do wyboru.	6a
Przekazywanie danych o płatności do systemu księgowego	Po potwierdzeniu rezerwacji rekord jest wysyłany do systemu księgowego; w razie niedostępności systemu księgowego, przekazanie jest odświeżane później.	WF‑06
Wysyłka e‑maila z potwierdzeniem	Po zapisaniu rezerwacji jako „Potwierdzona” aplikacja wysyła e‑mail do klienta z numerem rezerwacji, terminem i oddziałem.	WF‑04
Obsługa płatności odrzuconej (7a)	Jeśli bramka płatności zwróci status „Odrzucono”, system pozostawia rekord w stanie „Oczekuje na płatność” i umożliwia ponowne próby.	7a
Czas blokowania pojazdu przed płatnością	Wymagane jest ustalenie maksymalnego czasu oczekiwania na płatność; po przekroczeniu limitu rezerwacja zostaje anulowana.	Pytanie otwarte #1
Zarządzanie dostępnością w czasie rzeczywistym	System musi obsługiwać równoczesne żądania, aby uniknąć podwójnych rezerwacji – wymaga transakcyjnego zapisu i blokowania rekordów.	PB1

Bielik-11B-v3.0-Instruct (Q8)

Zadanie	Lista kontrolna	Poprawność	Zgodność	Niewiadome	Język	Użyteczność	Zmyślenia	Nadmiar
A1 Model dziedziny	4/6	1	1	1	3	1	3	2
A2 Cykl życia	1/4	2	3	3	4	2	0	2
A3 Architektura	4/6	2	4	4	4	2	0	2
A4 Diagram sekwencji	4/6	2	2	2	3	2	0	1

Na Bielika liczyłem najbardziej, bo to polski model. Polszczyzna rzeczywiście jest poprawna, ale w zadaniach analitycznych model wypadł najsłabiej. W A1 złamał niemal wszystkie zasady polecenia: diagram ma typy danych, identyfikatory, metody i klasy techniczne (karta płatnicza, przelew), a liczności zapisane bez cudzysłowów (Klient --> 1..* Rezerwacja) powodują błąd składni. Najpoważniejszy problem to jednak zmyślone wartości w założeniach:

„Jak długo pojazd jest blokowany w oczekiwaniu na płatność? (Założenie: 24 godziny)”

Podobnie model „ustalił” godzinę na przygotowanie pojazdu i 21 lat jako minimalny wiek kierowcy. W A3 odwrócił kluczowy argument: blokadę rezerwacji (WF-02) uznał za łatwiejszą w mikrousługach. Diagram sekwencji nie zawiera bloku alt/else dla wyjątku 6a, choć decyzje projektowe twierdzą, że wyjątek jest obsłużony. Moim zdaniem Bielik lepiej sprawdzi się w zadaniach językowych niż w modelowaniu.

Pełna odpowiedź – A1 Model dziedziny:

Diagram

@startumlclass Klient {
    +imie: String
    +nazwisko: String
    +email: String
    +telefon: String
    +pesel: String
    +prawoJazdy: PrawoJazdy
}
class PrawoJazdy {
    +numer: String
    +dataWydania: Date
    +dataWaznosci: Date
}
class Oddzial {
    +nazwa: String
    +adres: String
    +flota: List<Pojazd>
}
class Pojazd {
    +id: Integer
    +klasa: KlasaPojazdu
    +numerRejestracyjny: String
    +status: StatusPojazdu
    +rezerwacje: List<Rezerwacja>
}
class KlasaPojazdu {
    +id: Integer
    +nazwa: String
    +cenaDobowa: Double
}
class Rezerwacja {
    +id: Integer
    +klient: Klient
    +oddzial: Oddzial
    +pojazd: Pojazd
    +dataOdbioru: Date
    +godzinaOdbioru: Time
    +dataZwrotu: Date
    +godzinaZwrotu: Time
    +status: StatusRezerwacji
    +zaliczka: Double
}
class StatusPojazdu {
    +AKTYWNY
    +ZAREZERWOWANY
}
class StatusRezerwacji {
    +OCZEKUJE_NA_PLATNOSC
    +POTWIERDZONA
    +ANULOWANA
}
class Platnosc {
    +id: Integer
    +kwota: Double
    +data: Date
    +status: StatusPlatnosci
    +rezerwacja: Rezerwacja
}
class StatusPlatnosci {
    +OPLACONA
    +ODRZUCONA
    +W_TOKU
}
class SystemKsiegowy {
    +zapiszPlatnosc(platnosc: Platnosc)
}
class SystemPlatnosci {
    +przetworzPłatność(kwota: Double, dane: DanePłatności)
}
class DanePłatności {
    +karta: KartaPłatnicza
    +przelew: PrzelewBankowy
}
class KartaPłatnicza {
    +numer: String
    +dataWaznosci: Date
}
class PrzelewBankowy {
    +iban: String
    +kwota: Double
}
Klient --> 1..* Rezerwacja
Oddzial --> 1..* Pojazd
Pojazd --> 1..* Rezerwacja
Rezerwacja --> 1 Platnosc
Platnosc --> 1 Rezerwacja
SystemKsiegowy --> SystemPlatnosci
@enduml

Założenia

• Pytanie 1: Jak długo pojazd jest blokowany w oczekiwaniu na płatność? (Założenie: 24 godziny)
• Pytanie 2: Czy klient rezerwuje konkretny pojazd, czy klasę pojazdu? (Założenie: klasa pojazdu)
• Pytanie 3: Czy odbiór i zwrot mogą odbywać się w różnych oddziałach? (Założenie: tak, ale wymaga dodatkowej logiki w systemie)
• Pytanie 4: Ile czasu potrzeba na przygotowanie pojazdu między zwrotem a kolejnym wydaniem? (Założenie: 1 godzina)
• Pytanie 5: Jakie są wymagania dotyczące wieku kierowcy i stażu prawa jazdy? (Założenie: minimum 21 lat, prawo jazdy od 2 lat)

Pełna odpowiedź – A2 Cykl życia:

Tabela przejść dla obiektu Rezerwacja

Stan	Zdarzenie	Warunek	Stan następny
Nowa	Utworzona przez klienta	Klient wybrał pojazd i termin	Oczekuje na płatność
Oczekuje na płatność	Płatność zaliczki potwierdzona	System płatności zwrócił sukces	Potwierdzona
Oczekuje na płatność	Brak płatności w wyznaczonym czasie	Czas do ustalenia przekroczony	Anulowana
Potwierdzona	Zwrot pojazdu przez klienta	Pojazd zwrócony	Zamknięta
Anulowana	Ręczne anulowanie przez pracownika	Prośba klienta lub błąd systemu	Anulowana (ręcznie)
Potwierdzona	Podwójna rezerwacja tego samego pojazdu	Inny klient zarezerwował ten sam pojazd	Odrzucona

Luki w wymaganiach

1. Co się dzieje, gdy klient chce zmienić termin rezerwacji po jej potwierdzeniu? Czy system umożliwia taką zmianę i jakie są warunki (np. koszt)?
2. Jak system obsługuje sytuację, gdy pojazd ulegnie awarii między rezerwacją a odbiorem? Czy klient jest informowany i czy ma prawo do zwrotu zaliczki lub zamiany pojazdu?
3. Czy system umożliwia rezerwację dodatkowych usług (np. fotelik dla dziecka, nawigacja) i jak są one rozliczane?
4. Jakie są procedury w przypadku spóźnienia klienta na odbiór pojazdu? Czy rezerwacja jest automatycznie anulowana czy przedłużana?
5. Czy system śledzi historię rezerwacji klienta i oferuje rabaty lub program lojalnościowy?

Pełna odpowiedź – A3 Architektura:

Porównanie wariantów architektury systemu rezerwacji dla wypożyczalni „Trasa”

Kryterium	Modularny Monolit	Mikrousługi
Czas rozwoju	Szybsze wdrożenie podstawowej funkcjonalności, ale dłuższy czas na modyfikacje.	Dłuższy czas początkowego wdrożenia ze względu na konieczność integracji usług, ale łatwiejsze wprowadzanie zmian i skalowanie.
Skalowalność	Ograniczona – cały system musi być aktualizowany przy każdej zmianie.	Wysoka – poszczególne usługi mogą być niezależnie skalowane i aktualizowane.
Wydajność	Zależna od optymalizacji całego systemu, może wymagać dużych zasobów przy intensywnym ruchu (np. sezon letni).	Lepsza wydajność dzięki rozproszeniu obciążenia między usługi i łatwiejszemu balansowaniu obciążenia.
Integracja z systemem księgowym	Prostsza, ponieważ cały system jest spójny – jedna baza danych lub bezpośrednie wywołania API.	Wymaga dobrze zaprojektowanych interfejsów API i mechanizmów synchronizacji danych między usługami, co może być czasochłonne.
Obsługa wymagania WF-02 (blokada rezerwacji)	Możliwa poprzez centralne zarządzanie stanem pojazdów w bazie danych, ale wymaga synchronizacji między modułami.	Łatwiejsza do implementacji dzięki dedykowanej usłudze zarządzającej rezerwacjami i blokadami pojazdów.
Obsługa wymagania WNF-01 (czas ładowania listy pojazdów)	Zależna od optymalizacji zapytań do bazy danych – może być trudna do spełnienia bez dodatkowych mechanizmów cache’owania.	Łatwiejsza do optymalizacji poprzez dedykowaną usługę odpowiedzialną za prezentację dostępnych pojazdów, z możliwością użycia cache’owania na poziomie usługi.
Obsługa wymagania WNF-02 (dostępność 24/7)	Możliwa poprzez odpowiednie skonfigurowanie serwera i bazy danych, ale wymaga ciągłego monitoringu.	Łatwiejsza do zapewnienia dzięki rozproszonej architekturze – awaria jednej usługi nie blokuje całego systemu.
Koszt początkowy	Niższy ze względu na prostszą strukturę i mniejszą złożoność integracji, ale wyższe koszty utrzymania przy rozbudowie systemu.	Wyższy ze względu na konieczność inwestycji w infrastrukturę i narzędzia do zarządzania mikrousługami (np. Kubernetes, API Gateway), ale niższe koszty utrzymania przy skalowaniu.
Wymagana wiedza techniczna	Wystarczy jeden informatyk znający język programowania i framework monolityczny (np. Spring Boot, Django).	Wymaga specjalistycznej wiedzy z zakresu architektury mikrousług, konteneryzacji (Docker), orkiestracji (Kubernetes) i integracji API.

Rekomendacja

Rekomenduję wybór modularnego monolitu ze względu na krótki termin realizacji (1 czerwca) i ograniczony budżet (400 tys. zł). Architektura ta pozwoli szybciej dostarczyć podstawową funkcjonalność, a jeden informatyk będzie w stanie ją obsłużyć bez konieczności posiadania zaawansowanej wiedzy o mikrousługach. Mikrousługi, choć bardziej skalowalne i wydajne w dłuższej perspektywie, wymagają większych nakładów czasowych i finansowych na początkowym etapie.

Czego nie wiem

1. Szczegółowe wymagania dotyczące wydajności systemu – brak danych o przewidywanym ruchu (np. liczba rezerwacji na godzinę) i czasie odpowiedzi akceptowalnym dla użytkowników końcowych.
2. Dostępność zasobów ludzkich – nie wiadomo, czy firma planuje zatrudnić dodatkowego specjalistę do utrzymania systemu po wdrożeniu.
3. Wymagania dotyczące bezpieczeństwa i backupów – brak informacji o polityce kopii zapasowych, szyfrowaniu danych czy zgodności z regulacjami (np. RODO).
4. Planowane rozszerzenia funkcjonalności – nie wiadomo, czy system będzie rozbudowywany o nowe moduły (np. rezerwacja akcesoriów), co mogłoby wpłynąć na wybór architektury.
5. Koszty utrzymania infrastruktury – brak danych o przewidywanych kosztach hostingu, skalowania i monitoringu systemu w perspektywie kilku lat.

Pełna odpowiedź – A4 Diagram sekwencji:

Diagram

@startuml participant Klient
 participant Aplikacja_web
 participant Modul_rezerwacji
 participant Baza_danych
 participant Bramka_platnosci
 participant System_ksiegowy
 Klient ->> Aplikacja_web: wybiera oddział i termin
 Aplikacja_web --> Modul_rezerwacji: pobierz dostępne pojazdy
 Modul_rezerwacji --> Baza_danych: sprawdź dostępność
 Baza_danych --> Modul_rezerwacji: zwróć listę wolnych pojazdów
 Modul_rezerwacji --> Aplikacja_web: wyświetl klientowi opcje
 Klient --> Aplikacja_web: wybiera pojazd i podaje dane
 Aplikacja_web --> Modul_rezerwacji: zapisz rezerwację wstępną
 Modul_rezerwacji --> Baza_danych: zablokuj termin dla pojazdu
 Klient --> Bramka_platnosci: płaci zaliczkę
 Bramka_platnosci --> Aplikacja_web: potwierdza transakcję
 Aplikacja_web --> Modul_rezerwacji: zmień status na "Potwierdzona"
 Modul_rezerwacji --> Baza_danych: zaktualizuj rezerwację
 Aplikacja_web --> System_ksiegowy: przekaż dane płatności
 System_ksiegowy --> Aplikacja_web: potwierdź zapis
 Aplikacja_web --> Klient: wyślij e-mail z potwierdzeniem
@enduml

Decyzje projektowe

1. Wymaganie WF-01: Moduł rezerwacji komunikuje się z bazą danych, aby sprawdzić i wyświetlić tylko wolne pojazdy (blokowanie terminów odbywa się dopiero po płatności).
2. Wymaganie WF-02: System blokuje rezerwację, jeśli ten sam pojazd jest już zarezerwowany w tym samym czasie – realizowane przez sprawdzanie dostępności w bazie danych przed zapisem.
3. Wyjątek 6a: Jeśli ostatni pojazd klasy zostanie zarezerwowany równolegle, aplikacja web informuje klienta i cofa go do wyboru innej opcji (komunikat zwrotny od modułu rezerwacji).
4. Wymaganie WF-03: Integracja z bramką płatności następuje po akceptacji klienta – status rezerwacji zmienia się dopiero po potwierdzeniu transakcji.
5. Wymaganie WF-04: E-mail jest generowany automatycznie przez aplikację web po zakończeniu procesu (zawiera dane rezerwacji).
6. Wymaganie WF-06: Dane płatności są przekazywane do systemu księgowego asynchronicznie – w przypadku błędu system nie blokuje potwierdzenia rezerwacji (obsługa wyjątku 9a).
7. Wymaganie WNF-03: Przetwarzanie danych osobowych zgodne z RODO – wszystkie operacje na danych klienta są szyfrowane, a dostęp ograniczony do niezbędnych modułów.

ChatGPT (GPT-6, rozumowanie średnie) – punkt odniesienia

Zadanie	Lista kontrolna	Poprawność	Zgodność	Niewiadome	Język	Użyteczność	Zmyślenia	Nadmiar
A1 Model dziedziny	6/6	5	5	5	4	5	0	0
A2 Cykl życia	2/4	5	5	5	5	4	0	0
A3 Architektura	5/6	5	5	5	5	5	0	0
A4 Diagram sekwencji	5/6	4	5	5	4	5	0	0

ChatGPT zgodnie z oczekiwaniami był najlepszy, ale nie we wszystkim. Jego odpowiedzi wyróżniają się dyscypliną: każde założenie ma pytanie do klienta, w A3 rekomendacja ma pięć zdań, a lista „Czego nie wiem” obejmuje dziesięć konkretnych pytań. W A2 model świadomie nie wyszedł poza materiały:

„Materiały nie definiują stanu „Zakończona” ani kompletnego cyklu realizacji wynajmu, więc nie przedstawiono ich jako faktów.”

Lista kontrolna oceniła to surowo (2/4), bo zabrakło stanów wydania i zakończenia najmu. Moim zdaniem to jednak postawa, której oczekuję od analityka: zamiast zgadywać, model pyta o te stany w lukach. Słabsze punkty to brak asynchronicznego przekazania do księgowości w A4 oraz nazwy na diagramach zapisane bez polskich znaków.

Pełna odpowiedź – A1 Model dziedziny:

Diagram

@startuml
hide methods
skinparam classAttributeIconSize 0class Klient {
  dane osobowe
  adres e-mail
  dane prawa jazdy
}
class Oddzial {
  nazwa
  lokalizacja
}
class Pracownik
class Pojazd {
  rodzaj
  status aktywnosci
}
class KlasaPojazdu {
  nazwa
  cena wynajmu
}
class Rezerwacja {
  numer rezerwacji
  data i godzina odbioru
  data i godzina zwrotu
  status
  kwota zaliczki
  akceptacja regulaminu
}
class Platnosc {
  kwota
  status
}
Klient "1" -- "0.." Rezerwacja : sklada
Oddzial "1" -- "0.." Rezerwacja : obsluguje
Oddzial "1" -- "0.." Pojazd : dysponuje
Oddzial "1" -- "0.." Pracownik : zatrudnia
KlasaPojazdu "1" -- "0.." Pojazd : klasyfikuje
KlasaPojazdu "1" -- "0.." Rezerwacja : wybrana w
Rezerwacja "0.." -- "0..1" Pojazd : przypisany pojazd
Rezerwacja "1" -- "0.." Platnosc : platnosci
note right of Rezerwacja
  Przypisanie konkretnego pojazdu
  i moment przypisania wymagaja potwierdzenia.
end note
@enduml

Założenia

• Przypisanie pojazdu: diagram dopuszcza rezerwację bez wskazanego egzemplarza; to decyzja niepotwierdzona. Pytanie: Czy klient rezerwuje klasę czy konkretny pojazd i kiedy przypisuje się egzemplarz?
• Oddział pojazdu: przyjęto jeden oddział przypisany do pojazdu w danym momencie. Pytanie: Czy pojazdy mogą być przenoszone między oddziałami i czy trzeba śledzić historię tych przeniesień?
• Oddział rezerwacji: przyjęto pojedynczy oddział obsługujący rezerwację. Pytanie: Czy odbiór i zwrot mogą odbywać się w różnych oddziałach?
• Klasa i cena: cena jest pokazana przy klasie jako uproszczenie pojęciowe. Pytanie: Czy cena zależy również od oddziału, terminu, długości najmu lub taryfy?
• Płatności: przyjęto możliwość wielu zapisów płatności dla rezerwacji, aby nie wykluczyć ponowień. Pytanie: Czy każda próba płatności jest osobnym zapisem, czy ewidencjonuje się tylko skutecznie opłaconą zaliczkę?
• Dane kierowcy: dane prawa jazdy przypisano klientowi. Pytanie: Czy klient i kierowca są zawsze tą samą osobą i jakie wymagania dotyczą wieku oraz stażu prawa jazdy?
• Dostępność: nie modelowano osobnej jednostki przygotowania pojazdu. Pytanie: Ile czasu po zwrocie potrzeba przed kolejnym wydaniem pojazdu?
• Blokada przed płatnością: nie ustalono zasad utrzymywania rezerwacji oczekującej na płatność. Pytanie: Jak długo blokuje ona dostępność pojazdu?
• Pracownicy: przyjęto przypisanie pracownika do jednego oddziału. Pytanie: Czy pracownik może obsługiwać kilka oddziałów?
• Potwierdzenie i księgowanie: nie dodano odrębnych klas dla e-maila i systemu księgowego, ponieważ są to kanał komunikacji i system zewnętrzny, a nie koniecznie pojęcia dziedziny. Pytanie: Czy trzeba biznesowo śledzić historię wysyłki potwierdzeń i status przekazania każdej płatności do księgowości?

Pełna odpowiedź – A2 Cykl życia:

Tabela przejść

Stan	Zdarzenie	Warunek	Stan następny
Brak rezerwacji	Klient wybiera oddział, termin i klasę, wprowadza dane oraz akceptuje regulamin	Termin poprawny, pojazd nadal dostępny; moment utworzenia obiektu do ustalenia	Oczekuje na płatność
Brak rezerwacji	Próba zatwierdzenia formularza	Ostatni pojazd klasy został zarezerwowany przez inną osobę (6a)	Brak rezerwacji; powrót do wyboru klasy
Brak rezerwacji	Wprowadzenie błędnego terminu	Zwrot przed odbiorem lub termin w przeszłości (1a)	Brak rezerwacji; poprawienie danych
Brak rezerwacji	Wyszukanie dostępności	Brak wolnych pojazdów (2a)	Brak rezerwacji; propozycja innego oddziału lub terminu
Oczekuje na płatność	Potwierdzenie wpłaty przez system płatności	Płatność udana (PU-01, WF-03)	Potwierdzona
Oczekuje na płatność	Odrzucenie płatności	Płatność nieudana (7a)	Oczekuje na płatność; możliwe ponowienie
Oczekuje na płatność	Ponowienie płatności	Klient podejmuje kolejną próbę (7a)	Oczekuje na płatność, do wyniku próby
Oczekuje na płatność	Upływ czasu na płatność	Brak wpłaty w czasie do ustalenia (7b)	Anulowana; zwolnienie pojazdu
Potwierdzona	Nieudane przekazanie danych do księgowości	System księgowy niedostępny (9a)	Potwierdzona; ponowienie przekazania później
Potwierdzona	Potwierdzenie przekazania płatności do księgowości	Dane przekazane (krok 9)	Potwierdzona
Anulowana	—	Stan końcowy dla anulowania wskazanego w 7b	Anulowana
Potwierdzona	—	Koniec opisanego PU-01; dalsze zdarzenia najmu nie zostały zdefiniowane	Potwierdzona (końcowy w zakresie PU-01, niekoniecznie w całym cyklu życia)

Stan „Oczekuje na płatność” jest podany w wyjątku 7a; przyjęcie go również przed pierwszą próbą zapłaty jest propozycją wymagającą potwierdzenia. Materiały nie definiują stanu „Zakończona” ani kompletnego cyklu realizacji wynajmu, więc nie przedstawiono ich jako faktów.

Luki w wymaganiach

• Nie określono chwili powstania rezerwacji i pierwszego statusu: czy rezerwacja jest tworzona przed przekierowaniem do płatności, czy dopiero po jej potwierdzeniu?
• Nie określono okresu blokady pojazdu: jak długo rezerwacja oczekująca na płatność blokuje dostępność (czas do ustalenia)?
• Nie opisano anulowania z inicjatywy klienta: czy klient może anulować potwierdzoną rezerwację i na jakich zasadach?
• Nie opisano modyfikacji rezerwacji: czy klient lub pracownik może zmienić termin, oddział lub klasę pojazdu po potwierdzeniu?
• Nie określono stanów po odbiorze i zwrocie pojazdu: czy należy dodać stany dotyczące wydania, trwania najmu i zakończenia wynajmu?
• Nie opisano niepojawienia się klienta: jaki status i skutki ma nieodebranie pojazdu w umówionym terminie?
• Nie określono obsługi zwrotów zaliczek: czy po anulowaniu potwierdzonej rezerwacji zaliczka jest zwracana i jak odzwierciedlać tę operację w statusie?
• Nie opisano problemów po pobraniu płatności, lecz przed potwierdzeniem rezerwacji: jak postępować, jeśli płatność się powiedzie, ale zapis rezerwacji nie?
• Nie sprecyzowano skutków braku wysłania e-maila: czy nieudane potwierdzenie e-mail wymaga osobnego statusu, ponowienia czy tylko obsługi błędu?
• Nie określono granicy między anulowaniem i zrealizowaną rezerwacją: które stany mają być końcowe w pełnym cyklu życia i czy dopuszcza się przywrócenie anulowanej rezerwacji?

Pełna odpowiedź – A3 Architektura:

Porównanie

Kryterium	Modularny monolit	Mikrousługi
Termin uruchomienia do 1 czerwca	Mniej elementów do budowy, integracji i wdrożenia; mniejsze ryzyko opóźnienia	Wymagają przygotowania komunikacji i wdrażania wielu usług; większe ryzyko terminowe
Budżet 400 tys. zł	Zwykle mniej kosztów początkowych związanych z infrastrukturą i operacjami	Zwykle większy narzut na infrastrukturę, obserwowalność i utrzymanie; brak danych do wyceny
Jeden informatyk w firmie	Prostsze wdrożenia, diagnostyka i utrzymanie jednej aplikacji	Większy zakres kompetencji operacyjnych, monitoringu i zarządzania usługami
WF-02: brak nakładających się rezerwacji	Kontrolę spójności można skoncentrować w module rezerwacji i jednej bazie/transakcji	Trzeba zaprojektować spójność i koordynację operacji między usługami, jeśli dostępność i rezerwacje będą rozdzielone
WNF-01: czas wyświetlania dostępności (propozycja 2 s)	Mniej połączeń sieciowych wewnątrz systemu; wydajność nadal wymaga pomiarów	Możliwe niezależne skalowanie odczytów, ale komunikacja sieciowa może zwiększyć opóźnienia
WNF-02: dostępność całodobowa, prace nocne	Prostsza eksploatacja, ale awaria wspólnego procesu może wpłynąć na całą aplikację	Możliwa izolacja awarii i niezależne wdrożenia, lecz więcej punktów awarii i elementów utrzymania
Skalowanie i rozwój	Początkowo skalowanie całej aplikacji; granice modułów ułatwiają późniejszy podział	Niezależne skalowanie poszczególnych usług i autonomiczne wdrożenia
Integracja z istniejącym systemem księgowym	Integracja z jednego wyodrębnionego modułu	Integracja może być osobną usługą, ale wymaga dodatkowej komunikacji i obsługi błędów

Rekomendacja

Rekomenduję modularny monolit, ponieważ przy terminie do 1 czerwca, budżecie 400 tys. zł i jednym informatyku ogranicza złożoność wdrożenia i utrzymania. WF-02 łatwiej egzekwować przy spójnej obsłudze konfliktów rezerwacyjnych i transakcyjnym zapisie. WNF-01 nie uzasadnia obecnie rozproszenia, ponieważ docelowy czas odpowiedzi i obciążenie nie zostały potwierdzone. WNF-02 wymaga odpowiedniego hostingu, monitorowania, kopii zapasowych i procedur wdrożeniowych niezależnie od wybranego wariantu. Warto zachować wyraźne granice modułów, umożliwiające ewentualne wydzielenie usług w przyszłości.

Czego nie wiem

• Jaka jest dokładna data rozpoczęcia prac, realny czas realizacji i dostępność zespołu wykonawczego poza jednym informatykiem?
• Jakie są przewidywane i szczytowe liczby użytkowników, wyszukiwań oraz jednoczesnych prób rezerwacji?
• Jaka ma być ostateczna granica czasu odpowiedzi (WNF-01), przy jakim obciążeniu i dla jakich operacji?
• Jaki jest wymagany miesięczny poziom dostępności, maksymalny dopuszczalny przestój i sposób prowadzenia prac serwisowych (WNF-02)?
• Jakie są wymagania co do utraty danych, odtwarzania awaryjnego i odporności na awarię infrastruktury?
• Czy istnieją ograniczenia środowiska wdrożeniowego, technologii, hostingu i kompetencji dostawcy?
• Jak działa API obecnego systemu księgowego, jak często ma odbywać się synchronizacja i jakie są reguły ponawiania?
• Jakie zasady blokady pojazdu i współbieżnej rezerwacji mają obowiązywać przy płatności (WF-02)?
• Jaki jest oczekiwany rozwój liczby oddziałów, floty i zespołów produktowych?
• Czy budżet obejmuje tylko wdrożenie, czy również hosting, licencje, utrzymanie i rozwój?

Pełna odpowiedź – A4 Diagram sekwencji:

Diagram

@startuml
actor Klient
participant "Aplikacja web" as Web
participant "Moduł rezerwacji" as Rez
participant "Baza danych" as DB
participant "Bramka płatności" as Pay
participant "System księgowy" as KsKlient -> Web : Wybiera oddzial oraz termin odbioru i zwrotu
Web -> Rez : Pobierz dostepne klasy i ceny(oddzial, termin)
Rez -> DB : Sprawdz dostepnosc i ceny
DB --> Rez : Dostepne klasy i ceny
Rez --> Web : Lista dostepnych klas i cen
Web --> Klient : Wyswietl klasy i ceny
Klient -> Web : Wybiera klase, podaje dane osobowe i prawa jazdy
Web -> Rez : Przygotuj podsumowanie i zaliczke
Rez --> Web : Podsumowanie i kwota zaliczki
Web --> Klient : Wyswietl podsumowanie
Klient -> Web : Akceptuje regulamin i zatwierdza
Web -> Rez : Zatwierdz rezerwacje
Rez -> DB : Sprawdz ponownie i atomowo zablokuj dostepnosc
note over Rez, DB
  Ponowna weryfikacja i blokada chronia
  przed nakladajacymi sie rezerwacjami (WF-02).
end note
alt Brak dostepnosci (wyjatek 6a)
  DB --> Rez : Brak wolnego pojazdu klasy
  Rez --> Web : Brak dostepnosci
  Web --> Klient : Komunikat; powrot do wyboru klasy
  Web -> Rez : Pobierz aktualne klasy i ceny
  Rez -> DB : Odczytaj dostepnosc i ceny
  DB --> Rez : Aktualne klasy i ceny
  Rez --> Web : Lista klas i cen
  Web --> Klient : Wyswietl aktualne opcje (krok 2)
else Pojazd dostepny (scenariusz glowny)
  DB --> Rez : Dostepnosc zablokowana
  Rez --> Web : Mozna przejsc do platnosci
  Web -> Pay : Zainicjuj platnosc zaliczki
  Pay --> Web : Potwierdzenie wplaty
  Web -> Rez : Potwierdz oplacona rezerwacje
  Rez -> DB : Zapisz status Potwierdzona i blokade terminu
  DB --> Rez : Zapis potwierdzony
  Rez --> Web : Numer, termin, oddzial, klasa
  Web --> Klient : Potwierdzenie rezerwacji e-mailem
  Rez -> Ks : Przekaz informacje o platnosci
  Ks --> Rez : Przyjeto dane platnosci
end
@enduml

Decyzje projektowe

• Ponowna kontrola dostępności przy zatwierdzaniu: lista wyświetlona wcześniej nie jest gwarancją miejsca; ponowienie kontroli realizuje wyjątek 6a i wspiera WF-01/WF-02.
• Atomowa rezerwacja dostępności w bazie: weryfikacja konfliktu i blokada muszą wykluczać jednoczesne zatwierdzenie tego samego pojazdu na pokrywające się terminy (WF-02); mechanizm szczegółowy nie jest przesądzony.
• Brak pobrania zaliczki w ścieżce 6a: po utracie dostępności klient otrzymuje komunikat i aktualną listę klas zamiast przejścia do płatności (PU-01, 6a).
• Potwierdzenie po udanej płatności: zapis statusu „Potwierdzona” następuje po pozytywnym wyniku bramki (WF-03; PU-01, kroki 7–8).
• Potwierdzenie klienta: po zapisaniu rezerwacji przekazywane są numer, termin, oddział i klasa pojazdu; wysłanie e-maila przedstawiono na linii aplikacji, bez dodawania nieprzewidzianego uczestnika (WF-04; PU-01, krok 8).
• Przekazanie płatności do istniejącej księgowości: po zapisaniu rezerwacji moduł przekazuje informację o płatności (WF-06; PU-01, krok 9).
• Granica opracowania: diagram pokazuje tylko scenariusz główny i wyjątek 6a; czas blokady w oczekiwaniu na płatność i obsługa niepowodzeń płatności nie są w nim rozstrzygane.

Zestawienie zbiorcze

Miejsce	Model	Rodzaj	Średnia ocen 1–5	Lista kontrolna	Zmyślenia	Nadmiarowy zakres
1	ChatGPT (GPT-6, rozumowanie średnie)	chmura	4,8	18/22	0	0
2	Gemma 4 12B (Q8)	lokalny	4,4	20/22	0	0
3	Qwen3.5-9B (Q8)	lokalny	3,6	15/22	0	1
4	Gemma 3 27B (Q4)	lokalny	3,3	12/22	0	4
5	gpt-oss-20b (MXFP4)	lokalny	3,1	13/22	0	1
6	Bielik-11B-v3.0-Instruct (Q8)	lokalny	2,4	13/22	3	7

Średnia to średnia arytmetyczna pięciu ocen 1–5 ze wszystkich czterech zadań. Lista kontrolna sumuje trafienia z czterech zadań (maksymalnie 22 punkty).

Podsumowanie testów

Który model lokalny wygrał?

Najlepszym modelem lokalnym w moim teście była Gemma 4 12B w kwantyzacji Q8, ze średnią 4,4 i 20 z 22 punktów listy kontrolnej. Nie zmyśliła żadnej liczby i nie dodała niczego ponad zakres. Model dziedziny i analiza wariantów architektury nadawały się do pokazania klientowi niemal bez poprawek. Przewaga nad drugim Qwenem (średnia 3,6) jest wyraźna, a nad Gemmą 3 (3,3), gpt-oss-20b (3,1) i Bielikiem (2,4) duża.

Ciekawe jest to, że większa Gemma 3 27B w Q4 przegrała z mniejszą Gemmą 4 12B w Q8. Nowsza generacja modelu okazała się ważniejsza niż liczba parametrów. Być może zadecydowała kwantyzacja. Podobnie gpt-oss-20b, mimo trybu rozumowania i większego rozmiaru, przegrał z dwa razy mniejszym Qwenem.

O ile lepszy był ChatGPT?

ChatGPT uzyskał średnią 4,8 wobec 4,4 Gemmy 4. W zadaniu architektonicznym A3 różnicy praktycznie nie było: obie odpowiedzi dostały maksymalne oceny. W modelu dziedziny różnica była niewielka. Największa była w diagramie sekwencji: ChatGPT poprawnie umieścił sprawdzenie dostępności przed płatnością, a Gemma 4 zrobiła to po płatności, co jest błędem projektowym. Na liście kontrolnej Gemma 4 zdobyła nawet więcej punktów (20 wobec 18), co pokazuje, że listy kontrolne nie zastąpią przeczytania odpowiedzi.

Silne strony modelu lokalnego

• Trzymanie się formatu. Najlepsze modele lokalne oddały wszystkie wymagane sekcje, tabele i bloki kodu.
• Decyzje architektoniczne na poziomie chmury. W porównaniu modularnego monolitu z mikrousługami Gemma 4 nie ustępowała ChatGPT.
• Poprawny polski. Wszystkie modele pisały zrozumiałą polszczyzną; problemem była treść, a nie język.
• Poufność. Ani jedno zdanie nie opuściło laptopa.

Słabe strony modelu lokalnego

• Zmyślone liczby. Bielik podał 24 godziny, 1 godzinę i 21 lat tam, gdzie należało zapytać klienta.
• Błędy składni i notacji PlantUML. Dwa z dziesięciu diagramów modeli lokalnych się nie wyrenderowały, a kolejne zawierały zdublowane powiązania lub zapytania SQL zamiast komunikatów; w ChatGPT oba diagramy działały.
• Gubienie logiki wyjątków. Kolejność sprawdzenia dostępności i płatności oraz obsługa wyjątku 6a sprawiały kłopot prawie wszystkim modelom lokalnym. Gemma 4 i gpt-oss-20b sprawdzały dostępność dopiero po pobraniu zaliczki.
• Rozrost zakresu. Gemma 3 i Bielik chętnie dopisywały mapy Google, program lojalnościowy czy Kubernetes.

Ograniczenia testu

To nie jest benchmark naukowy. Każde zadanie uruchomiłem tylko raz, a ten sam prompt uruchomiony drugi raz może dać inny wynik. Test obejmuje jeden przykład biznesowy, jeden laptop i ocenę jednej osoby. Wyniki traktuj więc jako obserwację praktyka, a nie ostateczny ranking.

Jedno się nie zmienia od poprzedniego wpisu. Żaden model, lokalny ani chmurowy, nie odpowiedział na pytanie, ile czasu pojazd jest blokowany w oczekiwaniu na płatność. Najlepsze modele zadały to pytanie, najsłabszy wymyślił odpowiedź. Decyzja i odpowiedzialność zostają po stronie analityka.

Rekomendacje: jak lepiej wykorzystać modele lokalne?

Prompt

• Wymagaj stałych sekcji odpowiedzi. Sekcje „Diagram”, „Założenia”, „Czego nie wiem” najlepiej dyscyplinowały wszystkie modele.
• Zakazuj liczb wprost i podawaj zamiennik. Zamiast „nie zgaduj” pisz: „każdą wartość, której nie ma w materiałach, oznacz «do ustalenia»”. Bielik zignorował ogólny zakaz, ale słowo „do ustalenia” pojawiało się częściej tam, gdzie polecenie było konkretne.
• Jedno zadanie na prompt. Małe modele gubią się, gdy w jednej wiadomości dostają kilka produktów do przygotowania.
• Podawaj przykład notacji. Dwie linijki poprawnego PlantUML, np. z licznościami w cudzysłowach, zapobiegną najczęstszym błędom składni.
• Pytaj osobno o kolejność kroków. Przy diagramach sekwencji dopisz: „sprawdź, czy kolejność komunikatów jest zgodna z krokami przypadku użycia”.

Ustawienia

• Niska temperatura. Do zadań analitycznych używaj wartości 0–0,2; kreatywność nie jest tu zaletą.
• Wystarczający kontekst. Pakiet kontekstu i odpowiedź muszą zmieścić się w oknie modelu. Ustawienie „Truncate Middle” po cichu usuwa środek rozmowy, a tam często są wymagania.
• Nowa rozmowa dla każdego zadania. Resztki poprzednich odpowiedzi w kontekście małego modelu częściej szkodzą, niż pomagają.
• Kwantyzacja dopasowana do pamięci. Przy 64 GB RAM mniejszy model w Q8 może dać lepszy wynik niż większy w Q4, co pokazało porównanie obu Gemm.

Wybór modelu

• Do modelowania i architektury: Gemma 4 12B, a jeśli brakuje pamięci, Qwen3.5-9B z kontrolą liczności i składni.
• Do tekstów po polsku: Bielik, ale w zadaniach językowych, a nie analitycznych.
• Model z rozumowaniem to nie gwarancja: gpt-oss-20b dobrze argumentował w architekturze, ale słabo modelował; jeśli go używasz, wymuś w prompcie polskie nazwy pojęć.
• Do zadań, w których błąd kosztuje dużo: chmura, o ile pozwalają na to dane i umowa z klientem.
• Zawsze: sprawdź model na własnym przykładzie, zanim oprzesz na nim pracę. Ranking z tego tekstu może nie przenieść się na Twoje zadania.

Jeśli pracujesz z dokumentami, których nie możesz wysłać do chmury, model lokalny jest dziś realną opcją, a nie ciekawostką. Traktuj go jednak jak młodszego kolegę: szybko przygotuje szkic, ale każdą liczbę, liczność i strzałkę na diagramie musisz sprawdzić sam. Najpierw naucz się, jak wygląda dobry model UML. Wtedy LLM, lokalny czy chmurowy, stanie się tym, czym powinien być: narzędziem wzmacniającym pamięć i wyobraźnię analityka, a nie jego zamiennikiem.