Tak, aplikacja webowa może być w pełni wartościowym tematem pracy inżynierskiej, ale tylko wtedy, gdy program rozwiązuje konkretny problem, a autor opisze go zgodnie z regułami inżynierii oprogramowania: wymagania, architektura, projekt w UML, testy i wdrożenie. Ustawa traktuje „dokonanie techniczne” jako pełnoprawną formę pracy dyplomowej (art. 76 ust. 2 PSWN).
Popularność tego typu projektów sprawia, że promotorzy i recenzenci mają coraz wyższe oczekiwania. Na kierunkach informatycznych sama działająca aplikacja nie wystarczy. Musi jej towarzyszyć tekst, który wykaże, że autor potrafi świadomie podejmować decyzje projektowe, uzasadnić je literaturą przedmiotu i zweryfikować ich skutki. Literatura z zakresu inżynierii oprogramowania (m.in. podręczniki Sommerville’a i Sachy) pokazuje, że wytwarzanie systemu to cykl: od określenia wymagań, przez projekt i implementację, po testowanie i utrzymanie. Praca dyplomowa powinna ten cykl odzwierciedlać. Problem badawczy da się sformułować następująco: jak zaprojektować, zaimplementować i zweryfikować aplikację webową tak, aby spełniała przyjęte wymagania, a cały proces był udokumentowany w sposób sprawdzalny dla komisji? Poniższe sekcje prowadzą przez kolejne etapy tego zadania.
Dobry temat łączy realny problem użytkownika z zakresem, który da się zrealizować w jeden lub dwa semestry. Zgodnie z definicją aplikacji internetowej taki system to program działający na serwerze, z którym użytkownik komunikuje się przez przeglądarkę. W praktyce projekt obejmuje więc zarówno warstwę serwerową, jak i interfejs, co samo w sobie daje sporo materiału do opisu.
Przy wyborze tematu warto kierować się kilkoma kryteriami:
Typowe sformułowania tematów to np. „Projekt i implementacja aplikacji webowej do zarządzania rezerwacjami sal dydaktycznych” albo „Aplikacja internetowa wspierająca ewidencję sprzętu IT w przedsiębiorstwie z wykorzystaniem architektury REST”. Jeśli wahasz się między wersją przeglądarkową a natywną, porównaj swój pomysł z zestawieniem, w którym omówiliśmy, jak może wyglądać aplikacja mobilna na pracę inżynierską. Kryteria oceny są podobne, inna jest platforma docelowa.
Analiza wymagań polega na spisaniu, co system ma robić (wymagania funkcjonalne) i w jakich warunkach ma działać (wymagania niefunkcjonalne), zanim powstanie pierwsza linia kodu. Ten rozdział jest dla recenzenta sygnałem, że projekt wynika z przemyślanej specyfikacji, a nie z improwizacji.
Wymagania funkcjonalne najlepiej zapisać jako ponumerowaną listę lub historyjki użytkownika (user stories). Przykład: „WF-03: Zalogowany użytkownik może anulować rezerwację najpóźniej 24 godziny przed terminem”. Każde wymaganie powinno być jednoznaczne, testowalne i przypisane do konkretnego aktora: gościa, użytkownika, administratora. Dobrym zwyczajem jest priorytetyzacja metodą MoSCoW (must, should, could, won’t), bo od razu pokazuje, co tworzy minimalny produkt.
Wymagania niefunkcjonalne opisują jakość systemu: wydajność, bezpieczeństwo, dostępność, użyteczność i przenośność. Przydatnym punktem odniesienia jest model jakości z normy ISO/IEC 25010. Zamiast ogólników („aplikacja ma być szybka”) podaj wartości weryfikowalne, np. czas odpowiedzi API poniżej 500 ms dla 95% żądań przy 50 równoczesnych użytkownikach albo zgodność interfejsu z wytycznymi WCAG 2.1 na poziomie AA. Wtedy w rozdziale o testach będzie można odnieść się do tych liczb i wykazać, czy cel został osiągnięty.
Wybór technologii trzeba uzasadnić porównaniem alternatyw względem wymagań projektu, a nie samym stwierdzeniem, że autor zna dany framework. Komisja oczekuje argumentacji inżynierskiej: dlaczego to narzędzie lepiej spełnia wymagania niż inne.
Najczęściej spotykane zestawy technologiczne w pracach inżynierskich to:
Uzasadnienie warto przedstawić w tabeli porównawczej z kryteriami takimi jak wydajność, dojrzałość ekosystemu, dostępność bibliotek, krzywa uczenia, licencja i wsparcie społeczności. Osobno uzasadnia się wybór bazy danych: relacyjnej, gdy dane mają stabilną strukturę i wymagają transakcji, albo dokumentowej (np. MongoDB), gdy schemat jest elastyczny. Na koniec opisz architekturę: monolit warstwowy, MVC, REST API z oddzielnym frontendem albo mikroserwisy. W pracy inżynierskiej skala projektu rzadko uzasadnia mikroserwisy. Dobrze przemyślany monolit z czytelnym podziałem na warstwy zwykle ocenia się wyżej niż rozproszony system, którego autor nie potrafi obronić. Więcej praktycznych wskazówek dla kierunków technicznych znajdziesz w tekście o tym, jak wygląda pisanie prac inżynierskich z informatyki.
Projekt systemu dokumentuje się zestawem diagramów UML, z których każdy odpowiada na inne pytanie o budowę aplikacji. Diagramy muszą być spójne z wymaganiami i z kodem. Rozbieżności, np. klasa z diagramu, której nie ma w repozytorium, recenzenci wychwytują bardzo szybko.
Uzupełnieniem jest diagram ERD bazy danych oraz makiety interfejsu (wireframes) przygotowane np. w Figmie.
Implementację opisuje się wybiórczo: pokazuje się fragmenty kodu ilustrujące istotne rozwiązania, a nie cały program. Dobre przykłady to mechanizm autoryzacji, walidacja danych, obsługa transakcji, integracja z API czy optymalizacja zapytań. Każdy listing powinien mieć numer, podpis i komentarz w tekście. Warto też opisać strukturę katalogów projektu, konwencje nazewnictwa, sposób zarządzania wersjami (Git, strategia gałęzi) i dokumentację API, np. generowaną automatycznie w standardzie OpenAPI/Swagger. Szczegółowe zasady dotyczące tej części omówiliśmy w artykule „praca inżynierska: struktura i dokumentacja techniczna”.
Rozdział o testach, bezpieczeństwie i wdrożeniu ma udowodnić, że aplikacja spełnia wymagania określone na początku pracy. To właśnie tu zamyka się logika całego dokumentu: wymaganie, realizacja, weryfikacja.
Wyniki najlepiej zestawić w tabeli: identyfikator wymagania, przypadek testowy, oczekiwany rezultat, wynik. Jeśli w ramach testu użyteczności zbierasz oceny od respondentów, przyda się podstawowa analiza statystyczna wyników.
Bezpieczeństwo opisuje się najczęściej w odniesieniu do listy OWASP Top 10, czyli najczęstszych zagrożeń aplikacji webowych. W pracy warto pokazać, jak zabezpieczono system przed wstrzykiwaniem SQL (zapytania parametryzowane, ORM), atakami XSS i CSRF, jak przechowywane są hasła (bcrypt, Argon2) i jak działa kontrola dostępu oparta na rolach. Jeżeli aplikacja przetwarza dane osobowe, należy krótko odnieść się do zasad RODO, np. minimalizacji danych.
Wdrożenie można przeprowadzić na serwerze VPS, w chmurze lub w kontenerach Docker. Warto opisać konfigurację środowiska, proces CI/CD (np. automatyczne uruchamianie testów po każdym commicie), obsługę zmiennych środowiskowych i certyfikat HTTPS. Nawet jeśli aplikacja działa tylko w środowisku demonstracyjnym, opis procedury wdrożeniowej pokazuje dojrzałość inżynierską autora.
Typowa praca inżynierska o aplikacji webowej ma od pięciu do siedmiu rozdziałów i liczy zwykle od 50 do 80 stron, choć ostateczne wymogi określa regulamin dyplomowania danej uczelni. Najczęściej spotykany układ wygląda tak:
Wyraz „aplikacja” ma w polszczyźnie kilka znaczeń, dlatego w terminologii pracy warto trzymać się jednego z nich. Słownikowe znaczenie słowa aplikacja w kontekście informatycznym sprowadza się do komputerowego programu użytkowego. Zadbaj o spójność pojęć: jeśli we wstępie piszesz „aplikacja internetowa”, nie zamieniaj jej w kolejnych rozdziałach na „portal”, „serwis” czy „platformę” bez wyjaśnienia.
Pamiętaj też o wymogach formalnych. Zgodnie z art. 76 ustawy – Prawo o szkolnictwie wyższym i nauce pisemna praca dyplomowa jest przed egzaminem sprawdzana w Jednolitym Systemie Antyplagiatowym, a recenzje są jawne. Fragmenty kodu i dokumentacji bibliotek również mogą podnosić współczynniki podobieństwa, dlatego cudze rozwiązania trzeba oznaczać i opatrywać przypisami.
Przygotowanie do obrony obejmuje zwykle 10–15-minutową prezentację i odpowiedzi na pytania komisji. Najlepiej sprawdza się krótka demonstracja na żywo (z nagraniem wideo jako planem awaryjnym), jeden slajd z architekturą i jeden z wynikami testów. Komisje pytają najczęściej o uzasadnienie wyboru technologii, sposób zabezpieczenia danych, ograniczenia systemu i możliwości dalszego rozwoju. Jeśli chcesz zobaczyć, jak inni opisują podobne projekty, przejrzyj ogłoszenia w kategorii prace inżynierskie, gdzie publikowane są przykładowe opracowania z różnych dziedzin technicznych.
Najlepiej wybrać stos, który spełnia wymagania projektu i który potrafisz merytorycznie uzasadnić, np. React z Node.js i PostgreSQL albo Spring Boot z Angularem. Popularność technologii nie jest argumentem sama w sobie. Komisja oczekuje porównania alternatyw według jasno określonych kryteriów, np. wydajności, dojrzałości ekosystemu i dostępności dokumentacji.
Część teoretyczna opisuje dziedzinę problemu, istniejące rozwiązania i podstawy technologiczne, a projektowa dokumentuje to, co sam zaprojektowałeś, zaimplementowałeś i przetestowałeś. W pracach inżynierskich proporcje zwykle przesuwają się wyraźnie w stronę części projektowej. Teoria powinna jednak dostarczać kryteriów, którymi posłużysz się później przy wyborze technologii i ocenie wyników.
Testy opisuje się przez odniesienie każdego przypadku testowego do konkretnego wymagania i zestawienie wyników w tabeli. Wdrożenie przedstawia się jako procedurę: środowisko, konfiguracja, konteneryzacja, pipeline CI/CD i zabezpieczenie połączenia HTTPS. Warto dołączyć zrzuty ekranu z raportów testowych i krótko omówić napotkane błędy oraz sposób ich usunięcia.
Zależy to od regulaminu uczelni, ale większość wydziałów technicznych wymaga dołączenia kodu w formie załącznika: na nośniku, w repozytorium lub w systemie archiwizacji prac. W samym tekście zamieszcza się wyłącznie wybrane, skomentowane fragmenty. Repozytorium powinno zawierać plik README z instrukcją uruchomienia, aby recenzent mógł odtworzyć działanie systemu.
Serwis korzysta z cookies do anonimowych statystyk odwiedzin. Uruchamiamy je wyłącznie po Twojej zgodzie. Szczegóły znajdziesz w polityce prywatności.