Aplikacja webowa na pracę inżynierską z informatyki – poradnik

Aplikacja webowa to program uruchamiany w przeglądarce, z którym użytkownik wchodzi w interakcję – loguje się, dodaje dane, przegląda raporty – a nie tylko czyta treści jak na zwykłej stronie. Na pracę inżynierską z informatyki nadaje się bardzo dobrze, bo pozwala pokazać cały proces wytwarzania oprogramowania: analizę potrzeb, projekt bazy danych, część serwerową, interfejs, testy i wdrożenie. Warunek jest jeden – projekt musi mieć konkretnego odbiorcę i zakres możliwy do zrealizowania w kilka miesięcy.

W tym poradniku znajdziesz pomysły na aplikacje z opisem tego, co sprawia, że są wartościowe jako praca dyplomowa, porównanie technologii, przykładowy plan pracy z opisem rozdziałów oraz listę błędów, które najczęściej obniżają ocenę.

Pomysły na aplikację webową

Najlepsze pomysły wynikają z problemów, które znasz z własnego otoczenia: z pracy, studiów, hobby albo działalności znajomej firmy. Wtedy łatwiej zebrać wymagania i znaleźć osoby do testów.

Pomysły z pierwszych dziesięciu wierszy pochodzą z naszej wcześniejszej listy – każdy z nich warto jednak doprecyzować o konkretnego odbiorcę. „Aplikacja dla kancelarii” staje się dobrym tematem dopiero wtedy, gdy wiesz, jaki problem kancelarii rozwiązuje, np. pilnowanie terminów procesowych.

Jak zawęzić pomysł – przykład

Weźmy pomysł „aplikacja dla gabinetu kosmetologicznego”. W tej postaci nie wiadomo, co ma robić. Rozmowa z właścicielką gabinetu pokazuje, że największym problemem są nieodwołane wizyty i ręczne prowadzenie kart klientek. Temat zawęża się więc do „Projekt i implementacja aplikacji webowej do rezerwacji wizyt i prowadzenia historii zabiegów w gabinecie kosmetologicznym”. Zakres staje się jasny: kalendarz z rezerwacjami online, przypomnienia o wizycie, karta klientki z historią zabiegów i panel właścicielki z podsumowaniem obłożenia.

Taki temat ma też naturalną metodę oceny: porównanie liczby nieodwołanych wizyt przed wdrożeniem i po kilku tygodniach korzystania z aplikacji, uzupełnione krótką ankietą wśród klientek. Nawet jeśli wdrożenie jest testowe, wnioski są konkretne i dobrze wypadają na obronie.

Jak wybrać technologię?

Technologia, w której zbudujesz aplikację, zostanie z Tobą po studiach – warto więc wybrać ją świadomie, biorąc pod uwagę własne umiejętności, wymagania projektu i rynek pracy. W pracy porównaj co najmniej dwie opcje i uzasadnij wybór.

Nie musisz używać najmodniejszego frameworka. Lepiej zbudować solidną aplikację w technologii, którą znasz, niż połowę projektu w narzędziu poznawanym od zera.

Zakres projektu: co jest minimum, a co dodatkiem?

Dobrze przyjmowana aplikacja inżynierska zwykle zawiera: rejestrację i logowanie z co najmniej dwiema rolami użytkowników (np. klient i administrator), kilka powiązanych tabel w bazie danych, pełną obsługę dodawania, edycji i usuwania danych, wyszukiwanie lub filtrowanie, jeden element wyróżniający projekt – np. kalendarz, raporty z wykresami, integrację z zewnętrznym API albo powiadomienia e-mail – oraz responsywny interfejs działający na telefonie.

Wszystko ponad to – płatności, aplikacja mobilna, czat w czasie rzeczywistym – warto potraktować jako rozszerzenie. Jeśli zostanie czas, dodasz je na końcu; jeśli nie, opiszesz je w rozdziale o kierunkach rozwoju.

Przykładowy plan pracy z opisem rozdziałów

Wstęp przedstawia problem, cel i zakres pracy oraz krótko opisuje strukturę dokumentu. Warto tu napisać wprost, czego aplikacja nie obejmuje.

Analiza dziedziny i istniejących rozwiązań opisuje, jak dziś wygląda obsługa danego procesu (np. zapisy do gabinetu przez telefon) i jakie narzędzia są dostępne na rynku. Kończy się wnioskami: czego brakuje i dlaczego warto zbudować własne rozwiązanie.

Wymagania to lista wymagań funkcjonalnych i niefunkcjonalnych z priorytetami oraz diagram przypadków użycia. Dobrą praktyką jest numerowanie wymagań, żeby w rozdziale o testach wskazać, które z nich zostały sprawdzone.

Projekt obejmuje architekturę aplikacji, model bazy danych (diagram ERD), projekt interfejsu użytkownika (makiety) oraz opis bezpieczeństwa: uwierzytelnianie, uprawnienia, ochronę przed typowymi atakami.

Implementacja omawia strukturę projektu i najważniejsze rozwiązania – np. obsługę rezerwacji bez kolizji terminów albo generowanie raportów. Zamiast wklejać duże fragmenty kodu, wybierz kilka kluczowych i wyjaśnij, jak działają.

Testy i wdrożenie przedstawiają testy jednostkowe i integracyjne, testy z użytkownikami oraz sposób uruchomienia aplikacji na serwerze lub w kontenerze.

Podsumowanie odpowiada na pytanie, czy cel został osiągnięty, i wskazuje możliwe kierunki rozwoju.

Ogólne wymagania dla prac tego typu opisujemy na stronie o pracach inżynierskich.

Co powinno się znaleźć w części teoretycznej?

Część teoretyczna nie powinna być encyklopedią technologii internetowych. Wystarczy omówić to, czego używasz i na czym opierasz decyzje: architekturę klient–serwer i wzorzec MVC lub warstwowy, sposób komunikacji przez REST API, wybrany system bazodanowy, mechanizmy uwierzytelniania (sesje, tokeny JWT) oraz zasady projektowania interfejsów i dostępności. Każdy podrozdział powinien kończyć się zdaniem, jak dana wiedza przekłada się na Twój projekt.

Bezpieczeństwo – o co zapyta recenzent?

Aplikacja webowa jest dostępna z internetu, więc recenzenci zwracają uwagę na bezpieczeństwo. W pracy pokaż, że hasła przechowujesz jako skrót z solą, formularze są zabezpieczone przed atakami CSRF, zapytania do bazy – przed wstrzyknięciem SQL, a dane wyświetlane w przeglądarce – przed XSS. Wspomnij o połączeniu szyfrowanym HTTPS i o tym, jakie dane osobowe zbiera aplikacja i jak długo je przechowuje. Dobrym punktem odniesienia jest lista OWASP Top 10 – krótka tabela z informacją, jak Twoja aplikacja odpowiada na każde z zagrożeń, robi dobre wrażenie.

Jak przetestować aplikację webową?

Testy jednostkowe sprawdzają logikę biznesową, np. czy system nie pozwoli zarezerwować zajętego terminu. Testy integracyjne obejmują współpracę z bazą danych i interfejsem programistycznym. Testy end-to-end, np. w narzędziu Playwright lub Cypress, symulują działania użytkownika w przeglądarce. Do tego krótkie badanie użyteczności: 5–8 osób z grupy docelowej wykonuje typowe zadania, a Ty notujesz trudności i czas. Warto też zmierzyć wydajność kluczowych stron, np. w Lighthouse, i opisać wyniki.

Wdrożenie i dokumentacja techniczna

Nawet jeśli aplikacja nie będzie publicznie dostępna, opisz, jak ją uruchomić. Najwygodniej przygotować konfigurację Docker Compose, która jednym poleceniem startuje serwer aplikacji i bazę danych, oraz plik z instrukcją: wymagania, zmienne środowiskowe, kolejność kroków, konto testowe administratora. Recenzent, który bez trudu uruchomi projekt, oceni go spokojniej niż taki, który wymaga godziny konfiguracji. W załączniku warto umieścić też krótką dokumentację interfejsu programistycznego, np. wygenerowaną w Swaggerze.

Harmonogram

Obrona pracy z aplikacją webową

Na obronie zwykle trzeba w kilka minut pokazać, co aplikacja robi i dlaczego jest zbudowana w ten sposób. Przygotuj scenariusz demonstracji obejmujący jedną pełną ścieżkę użytkownika – np. rezerwację wizyty przez klientkę i jej potwierdzenie w panelu administratora – oraz nagranie zapasowe na wypadek problemów z siecią. Typowe pytania dotyczą wyboru technologii, struktury bazy danych, zabezpieczeń i tego, jak aplikacja poradziłaby sobie z większą liczbą użytkowników. Odpowiedzi warto oprzeć na tym, co opisałeś w rozdziałach o projekcie i testach.

Najczęstsze błędy

• Brak konkretnego użytkownika – „system dla firmy” bez opisu firmy i jej procesów utrudnia analizę wymagań.
• Zbyt wiele funkcji – dziesięć niedokończonych modułów wypada gorzej niż pięć dopracowanych.
• Projekt bazy danych bez normalizacji – powtarzające się dane i brak kluczy obcych to częsta uwaga recenzenta.
• Brak części o bezpieczeństwie – zwłaszcza gdy aplikacja przechowuje dane osobowe.
• Zrzuty ekranu bez komentarza – każdy ekran powinien być omówiony w odniesieniu do wymagań.

Jeśli zastanawiasz się nad wersją mobilną projektu, porównaj to podejście z poradnikiem o aplikacji mobilnej na pracę inżynierską.

Najczęstsze pytania

Czy aplikacja musi działać w internecie?

Nie musi być publicznie dostępna. Wystarczy, że da się ją uruchomić lokalnie lub w kontenerze i zaprezentować na obronie. Wdrożenie na serwer to atut, ale nie wymóg.

Czy mogę użyć gotowego szablonu interfejsu?

Tak, korzystanie z bibliotek komponentów (np. Bootstrap, Material UI) jest normalne. Opisz to w pracy – Twoim wkładem jest logika, architektura i integracja.

Ile stron ma praca inżynierska z aplikacją?

Najczęściej 50–80 stron bez załączników. Kod źródłowy dołącza się na nośniku lub podaje adres repozytorium.

Czym aplikacja webowa różni się od strony internetowej?

Strona głównie prezentuje treści, a aplikacja przetwarza dane użytkownika i reaguje na jego działania. Na inżynierkę lepiej sprawdza się aplikacja, bo ma bogatszą warstwę logiki i danych.

Czy w pracy muszą być diagramy UML?

Zwykle tak – przynajmniej diagram przypadków użycia i model danych. Dodatkowo przydaje się diagram sekwencji dla jednej kluczowej operacji. Dokładne wymagania zależą od promotora i wydziału.

Czy mogę rozwijać aplikację po obronie?

Tak, i warto – rozbudowany projekt w repozytorium to dobra pozycja w portfolio przy szukaniu pierwszej pracy. Sprawdź tylko, czy regulamin uczelni nie przewiduje praw do pracy dyplomowej, które mogłyby to ograniczać.

Czy pomagacie przy takich projektach?

Tak – przy analizie wymagań, projekcie bazy danych, dokumentacji i opisie implementacji. Zakres opisujemy na stronie o projektach informatycznych, a widełki cenowe w cenniku.