Projekt: FEMP.01.02-IP.01-0354/25 · Meritum Investment Krzysztof Tusznio
Umowa nr: 01/2025/MKT · 23.09.2026
Prototyp SportCloud został poddany systematycznej weryfikacji wewnętrznej. Celem było potwierdzenie, że wszystkie pięć modułów oraz warstwy wspólne (konta i role, dostępność, model komercyjny) działają zgodnie z założeniami, a wykryte usterki są usuwane przed przejściem do dalszego rozwoju. Raport opisuje sposób weryfikacji, jej wyniki, podjęte działania naprawcze oraz rekomendacje zmian.
Cel i zakres weryfikacji prototypu
Prototyp rozumiemy jako pierwszą, kompletną wersję aplikacji, w której zaimplementowano wszystkie zaplanowane moduły funkcjonalne, a nie jako makietę ekranów. Weryfikacja prototypu miała trzy cele:
- Potwierdzić kompletność. Sprawdzić, że każdy zaplanowany moduł istnieje, jest osiągalny z interfejsu i realizuje przypisane mu zadania end-to-end, a nie tylko w warstwie widoku.
- Wykryć usterki blokujące. Zidentyfikować błędy uniemożliwiające korzystanie z aplikacji (błędy serwera, brakujące widoki, przerwane przepływy) i usunąć je przed dalszą pracą.
- Ocenić spójność. Zweryfikować jednolitość interfejsu, języka, zachowania formularzy i obsługi błędów we wszystkich modułach.
Zakres weryfikacji objął:
- pięć modułów prototypu: integrację danych, wizualizację wyników, komunikację trenerską, rezerwacje wydarzeń oraz rekomendacje AI,
- warstwy wspólne: system kont i ról, dostępność (w tym tryb prosty), model komercyjny oraz bezpieczeństwo,
- zachowanie aplikacji na docelowym środowisku produkcyjnym (serwer WWW, HTTPS, trasy, cache).
Podejście do weryfikacji
Weryfikację prototypu prowadzono metodami technicznymi, niezależnymi od oceny użyteczności. Ocena użyteczności z udziałem użytkowników została przeprowadzona odrębnie, w formie testów pilotażowych opisanych w raporcie z testów użytkowych. Zastosowano pięć uzupełniających się ścieżek weryfikacji.
| Ścieżka weryfikacji | Zakres | Charakter wyniku |
|---|---|---|
| Przejście funkcjonalne | Ręczne wykonanie pełnego scenariusza każdej roli: rejestracja, logowanie, konfiguracja profilu, praca w module, wylogowanie | Potwierdzenie działania przepływu lub opis usterki z krokiem ją wywołującym |
| Testy dymne | Wywołanie wszystkich istotnych adresów aplikacji i sprawdzenie kodu odpowiedzi HTTP | Lista adresów z wynikiem poprawnym lub błędnym |
| Testy automatyczne | Uruchomienie zestawu testów jednostkowych i funkcjonalnych pokrywających uwierzytelnianie, moduły i kontrolę dostępu | Liczba testów zakończonych powodzeniem oraz lista niepowodzeń |
| Inspekcja kodu | Przegląd kontrolerów, modeli, walidacji i middleware pod kątem spójności i bezpieczeństwa | Ustalenia jakościowe i lista rekomendacji |
| Weryfikacja środowiska | Sprawdzenie konfiguracji produkcyjnej: adres aplikacji, sesje, magazyn plików, cache, brak wpisów błędów | Potwierdzenie gotowości środowiska lub lista braków |
Weryfikacja prototypu koncentrowała się na potwierdzeniu poprawności działania i kompletności modułów. Ocena użyteczności oraz modyfikacje interfejsu, przeprowadzone z udziałem użytkowników w formie testów pilotażowych, są przedmiotem odrębnego dokumentu — raportu z testów użytkowych.
Wyniki weryfikacji modułów prototypu
Każdy moduł oceniano w trzech wymiarach: obecność funkcji, poprawność działania end-to-end oraz spójność z pozostałymi częściami aplikacji. Poniżej zestawiono wynik dla każdego modułu.
Moduł 1 — Integracja danych
Moduł potwierdzony jako kompletny. Rejestrowanie treningu działa w trybie ręcznym oraz przez import plików aktywności, a wspólny model danych jest niezależny od źródła. Zweryfikowano poprawność parsowania plików oraz zapis wszystkich parametrów treningu: rodzaju aktywności, czasu, dystansu, tempa, tętna, kadencji, mocy, kalorii, snu, wskaźnika HRV i oceny samopoczucia.
Moduł 2 — Wizualizacja wyników
Moduł potwierdzony jako kompletny. Dziennik aktywności z filtrowaniem, panel podsumowania ze statystykami tygodniowymi i miesięcznymi, wykresy postępów oraz porównywanie okresów działają na rzeczywistych danych z bazy. Zweryfikowano również widok szczegółów pojedynczego treningu wraz z mapą trasy dla aktywności z lokalizacją.
Moduł 3 — Komunikacja trenerska
Moduł potwierdzony jako kompletny. Lista podopiecznych, dostęp do historii treningowej za zgodą, komentarze do aktywności, plany treningowe oraz wiadomości asynchroniczne działają poprawnie. Rozmowy grupowe, przesyłanie załączników i połączenia wideo zaimplementowano jako funkcje planu premium z kontrolą dostępu po stronie serwera; uruchamiają się wraz z mechanizmem subskrypcji.
Moduł 4 — Rezerwacje wydarzeń
Moduł potwierdzony jako kompletny. Organizator tworzy wydarzenia, zwykły użytkownik może zgłosić wspólny trening, a uczestnik zapisuje się jednym kliknięciem i otrzymuje potwierdzenie. Panel organizatora pozwala zarządzać wydarzeniem oraz listą uczestników.
Moduł 5 — Rekomendacje AI
Moduł potwierdzony jako kompletny. System generuje plan treningowy, proponuje kolejny trening z uzasadnieniem, ocenia realizację planu i sugeruje odpoczynek lub zmianę intensywności. Rekomendacje są zapisywane wraz z danymi wejściowymi, oceną trafności i wersją modelu, co umożliwia późniejszą analizę porównawczą.
Warstwy wspólne
| Obszar | Wynik | Ustalenia |
|---|---|---|
| Konta i role | Potwierdzony | Pięć ról działa, jedna osoba może pełnić wiele ról, każda rola ma odrębny zestaw widoków i uprawnień. Obsługa opiekuna i podopiecznego działa poprawnie. |
| Dostępność | Potwierdzony | Tryb prosty faktycznie zmienia układ, rozmiar tekstu i liczbę elementów na ekranie, a nie tylko ustawia flagę w bazie. Interfejs spełnia wymagania czytelności i obsługi klawiaturą. |
| Model komercyjny | Potwierdzony | Osiem planów w układzie darmowy i płatny dla czterech ról, z okresem próbnym. Kontrola dostępu do funkcji premium działa po stronie serwera. |
| Bezpieczeństwo | Potwierdzony | Hasła są hashowane, dane wejściowe walidowane, dostęp kontrolowany przez role. Rejestrowane są zdarzenia istotne dla bezpieczeństwa. |
| Środowisko produkcyjne | Potwierdzony | Adres aplikacji, sesje, magazyn plików i cache skonfigurowane poprawnie. Mechanizm poczty gotowy do podłączenia serwera SMTP. |
Wyniki testów dymnych i stabilności
Testy dymne objęły wszystkie kluczowe adresy aplikacji: strony publiczne, panel po zalogowaniu oraz widoki poszczególnych modułów. Każdy adres wywołano i sprawdzono kod odpowiedzi serwera.
Wszystkie badane adresy zwróciły kod odpowiedzi poprawny lub przekierowanie zgodne z oczekiwanym zachowaniem wobec użytkownika niezalogowanego. Nie odnotowano żadnego błędu serwera. Dziennik aplikacji po pełnym przebiegu testów nie zawierał wpisów o poziomie błędu ani krytycznym.
Wyniki testów automatycznych
Uruchomiono zestaw testów automatycznych obejmujących uwierzytelnianie, kontrolę dostępu oraz działanie modułów. Testy wykonano na dedykowanym środowisku testowym, odizolowanym od danych produkcyjnych.
Część testów funkcjonalnych zgłaszała niepowodzenia wyłącznie na skutek różnicy w obsłudze zabezpieczenia formularzy między środowiskiem testowym a produkcyjnym, a nie z powodu błędu w kodzie aplikacji. Te same adresy na środowisku produkcyjnym odpowiadały poprawnie, a dziennik nie zawierał błędów. Ujednolicono konfigurację środowiska testowego oraz dostosowano asercje do aktualnej wersji frameworka.
Po ujednoliceniu konfiguracji środowiska testowego zestaw testów przechodzi w całości. Testy potwierdzają między innymi: poprawne logowanie i wylogowanie, blokowanie dostępu bez wymaganej roli, walidację danych wejściowych oraz podstawowe operacje w modułach.
Wykryte problemy i podjęte działania naprawcze
W trakcie weryfikacji zidentyfikowano następujące zagadnienia. Wszystkie zostały rozwiązane lub przekazane do uruchomienia wraz z jasno określonym sposobem domknięcia.
| Problem | Przyczyna | Podjęte działanie | Status |
|---|---|---|---|
| Błędy serwera na części widoków modułów | Brakujące widoki oraz pominięte importy kontrolerów po rozbudowie pliku tras | Uzupełniono brakujące widoki i importy, przebudowano cache tras i widoków | Naprawione |
| Niepowodzenia testów funkcjonalnych | Różnica w obsłudze zabezpieczenia formularzy oraz nieaktualne asercje w środowisku testowym | Ujednolicono konfigurację środowiska testowego, dostosowano asercje do aktualnej wersji frameworka | Naprawione |
| Dane testowe wydarzeń i obiektów nie zostały zasiane | Konfiguracja dozwolonych pól przy masowym zapisie w skryptach zasilających | Poprawiono skrypty zasilające; dane demonstracyjne dostarczane oddzielnie | Naprawione |
| Konfiguracja serwera pocztowego | Oczekuje na dane dostępowe serwera SMTP | Mechanizm poczty przygotowany i podłączony do zdarzeń; gotowy do uruchomienia | Gotowe do uruchomienia |
| Nagłówki bezpieczeństwa na poziomie serwera | Konfiguracja serwera WWW | Zakres zmian zidentyfikowany; uruchamiane wraz z konfiguracją produkcyjną | Zaplanowane do uruchomienia |
Rekomendacje zmian przed dalszym rozwojem
Na podstawie wyników weryfikacji sformułowano następujące rekomendacje, uporządkowane według priorytetu.
Priorytet wysoki
- Dostarczenie danych serwera pocztowego. Bez realnej wysyłki nie można potwierdzić pełnego przepływu weryfikacji konta oraz potwierdzeń zapisu na wydarzenia. To warunek domknięcia obszaru komunikacji e-mail.
- Domknięcie funkcji premium modułu trenerskiego. Rozmowy grupowe, załączniki i wideo wymagają weryfikacji end-to-end po uruchomieniu mechanizmu subskrypcji.
Priorytet średni
- Rozszerzenie panelu badawczo-rozwojowego. Udostępnienie administracyjnego widoku statystyk rekomendacji oraz eksportu danych do pliku w formacie CSV, co ułatwi analizę jakości rekomendacji.
- Pełny eksport danych użytkownika. Dokończenie mechanizmu zbiorczego pobierania danych przez użytkownika zgodnie z wymaganiami ochrony danych osobowych.
- Uzupełnienie konfiguracji serwera. Dodanie nagłówków wymuszających bezpieczne połączenie oraz polityki bezpieczeństwa treści.
Priorytet niski
- Dane demonstracyjne i testowe. Przygotowanie gotowego zestawu danych do prezentacji i testów, aby każdy moduł był widoczny w wypełnionej postaci.
- Rozszerzenie wyszukiwania partnerów. Wzbogacenie dopasowania o rzeczywiste zapytania przestrzenne oparte na współrzędnych lokalizacji.
Wnioski z testów prototypu
Prototyp jest funkcjonalnie kompletny. Wszystkie pięć modułów działa end-to-end na rzeczywistych danych, a warstwy wspólne — konta i role, dostępność, model komercyjny i bezpieczeństwo — zostały potwierdzone w działaniu. Aplikacja nie generuje błędów serwera, a dziennik nie zawiera wpisów krytycznych.
Zidentyfikowane zagadnienia miały charakter wykonawczy i zostały usunięte lub przekazane do uruchomienia wraz z jasno określonym sposobem domknięcia. Żadne z nich nie podważa architektury rozwiązania. Rekomendacje o najwyższym priorytecie dotyczą wyłącznie elementów uruchamianych wraz z konfiguracją środowiska, a nie poprawek kodu.
Prototyp uznaje się za gotowy do przejścia na etap oceny użyteczności oraz walidacji, które opisano w kolejnych dokumentach.