Aplikacja mobilna na pracę inżynierską z informatyki – jak zaplanować

Aplikacja mobilna to jeden z najczęściej wybieranych projektów na pracę inżynierską z informatyki, bo łączy programowanie, projektowanie interfejsu i pracę z danymi w jednym, łatwym do pokazania produkcie. Żeby obroniła się jako praca dyplomowa, musi jednak rozwiązywać konkretny problem konkretnej grupy użytkowników, mieć udokumentowane wymagania, przemyślaną architekturę i testy – sam działający program to dopiero połowa sukcesu.

Opisujemy, jak wybrać pomysł, technologię i zakres, jak zbudować rozdziały pracy wokół aplikacji oraz czego promotorzy najczęściej wymagają na obronie.

Od czego zacząć: problem, a nie technologia

Dobry projekt zaczyna się od pytania „komu i w czym ta aplikacja pomoże?”. Pomysły typu „aplikacja do planowania dnia”, „aplikacja wspierająca zdrową dietę” czy „aplikacja do śledzenia drobnych inwestycji” są dobrym punktem wyjścia, ale warto je doprecyzować: dla kogo, w jakiej sytuacji, czym różni się od rozwiązań dostępnych w sklepie z aplikacjami.

Przed zgłoszeniem tematu przejrzyj trzy–pięć istniejących aplikacji o podobnym przeznaczeniu i spisz, czego im brakuje. To gotowy materiał do rozdziału z analizą rynku i uzasadnieniem celu pracy.

Ile funkcji to wystarczająco dużo?

Dobrym punktem odniesienia jest wersja minimalna (MVP): zestaw funkcji, bez których aplikacja nie spełnia swojego celu. Dla dziennika żywienia będą to dodawanie posiłku, wyszukiwanie produktu i dzienne podsumowanie kalorii. Logowanie przez media społecznościowe, motyw ciemny czy integracja z zegarkiem to już funkcje dodatkowe – można je zaplanować w rozdziale o kierunkach rozwoju.

W praktyce praca inżynierska z aplikacją mobilną zwykle obejmuje 5–10 ekranów, lokalną lub zdalną bazę danych, logowanie użytkownika i jedną funkcję wyróżniającą projekt, np. algorytm powtórek, analizę zdjęcia albo integrację z zewnętrznym API. Taki zakres da się dopracować w kilka miesięcy i pokazać na obronie bez pośpiechu.

Wybór technologii – natywnie czy wieloplatformowo?

Technologię dobierz do tego, co już umiesz, i do wymagań projektu. Na obronie i tak trzeba będzie uzasadnić wybór, więc warto porównać co najmniej dwie opcje w rozdziale teoretycznym.

Python bywa używany po stronie serwera, ale do samej aplikacji mobilnej standardem są wymienione wyżej narzędzia. Jeśli projekt ma część webową, warto zajrzeć też do poradnika o aplikacji webowej na pracę inżynierską.

Jak zawęzić pomysł: przykład krok po kroku

Załóżmy, że interesuje Cię zdrowe odżywianie. Pierwszy pomysł – „aplikacja o zdrowym stylu życia” – jest za szeroki, bo obejmuje dietę, sport, sen i nawodnienie. Po zawężeniu do jednego problemu powstaje „dziennik żywienia dla studentów”. Kolejny krok to wskazanie, czym różni się od istniejących rozwiązań: na przykład szybkim dodawaniem posiłków ze stołówki uczelnianej i tygodniowym budżetem na jedzenie. Wtedy temat może brzmieć: „Projekt i implementacja aplikacji mobilnej wspierającej planowanie posiłków i budżetu żywieniowego studentów”.

Tak sformułowany temat od razu podpowiada zakres: baza produktów, dodawanie posiłków, budżet, podsumowania. Łatwo też zaplanować testy – wystarczy kilku studentów, którzy przez tydzień będą korzystać z aplikacji i ocenią jej przydatność.

Jak ułożyć pracę wokół aplikacji?

1. Wstęp – problem, cel pracy, zakres projektu.
2. Analiza dziedziny i rynku – istniejące rozwiązania, ich wady, wnioski dla projektu.
3. Wymagania – funkcjonalne (co aplikacja robi) i niefunkcjonalne (wydajność, bezpieczeństwo, dostępność), przypadki użycia.
4. Projekt – architektura (np. MVVM), model danych, makiety ekranów.
5. Implementacja – najważniejsze fragmenty kodu z omówieniem, a nie cały kod.
6. Testy – testy jednostkowe, testy z użytkownikami, wnioski.
7. Podsumowanie – co osiągnięto, czego nie, kierunki rozwoju.

Kod źródłowy zwykle trafia do załącznika lub repozytorium, a w pracy omawia się tylko kluczowe rozwiązania. Ogólne wymagania dla tego typu prac opisujemy na stronie o pracach inżynierskich.

Diagramy i dokumentacja projektu

Część projektowa pracy powinna zawierać kilka diagramów, które pokazują, jak aplikacja jest zbudowana. Najczęściej wymagane są diagram przypadków użycia (kto i co może zrobić w aplikacji), diagram klas lub model danych (jakie obiekty przechowujesz i jak są powiązane) oraz diagram sekwencji dla jednej kluczowej operacji, np. zapisu danych z synchronizacją z serwerem. Do tego makiety ekranów – najlepiej wykonane przed implementacją, np. w Figmie – i krótki opis nawigacji między ekranami.

Diagramy nie są ozdobą: każdy powinien być omówiony w tekście i powiązany z wymaganiami. Recenzent sprawdza, czy to, co zaplanowano w projekcie, faktycznie znalazło się w aplikacji.

Jak przetestować aplikację?

Testy to rozdział, który najczęściej odróżnia ocenę dobrą od bardzo dobrej. Zaplanuj trzy poziomy. Testy jednostkowe sprawdzają logikę – obliczenia, walidację danych, działanie algorytmów – i dają się uruchomić automatycznie. Testy na urządzeniach obejmują różne rozmiary ekranów i wersje systemu; wystarczą dwa–trzy telefony i emulatory. Testy z użytkownikami polegają na tym, że 5–8 osób z grupy docelowej wykonuje kilka zadań, a Ty notujesz czas, błędy i uwagi. Do oceny ogólnej użyteczności sprawdza się krótki kwestionariusz SUS.

W pracy opisz scenariusze testów, wyniki i poprawki, które wprowadziłeś na ich podstawie. Takie podejście pokazuje, że projekt był rozwijany świadomie, a nie tylko zaprogramowany.

Najczęstsze błędy przy aplikacji na inżynierkę

• Za duży zakres – „aplikacja jak Instagram” to projekt na lata. Lepiej trzy dopracowane funkcje niż dziesięć niedziałających.
• Brak rozdziału z wymaganiami – bez niego trudno wykazać, że aplikacja realizuje cel pracy.
• Kod bez testów – nawet kilka testów jednostkowych i krótkie badanie użyteczności z 5–8 osobami podnosi ocenę.
• Zrzuty ekranu zamiast opisu – każdy ekran trzeba omówić: po co jest i jak działa.
• Brak kopii zapasowej repozytorium – utrata kodu tydzień przed oddaniem zdarza się częściej, niż się wydaje.

Rozdział teoretyczny – co w nim powinno się znaleźć?

Część teoretyczna w pracy z aplikacją nie powinna być historią smartfonów. Lepiej, żeby wprowadzała pojęcia potrzebne do zrozumienia projektu: architekturę aplikacji mobilnych (natywne, hybrydowe, wieloplatformowe), wzorce projektowe interfejsu i zarządzania stanem, sposoby przechowywania danych na urządzeniu i w chmurze, zasady projektowania dla urządzeń dotykowych oraz wymagania dostępności. Warto też krótko omówić wymagania sklepów z aplikacjami i wytyczne projektowe Material Design oraz Human Interface Guidelines, bo do nich odnoszą się decyzje o wyglądzie ekranów. Do tego przegląd 3–5 istniejących aplikacji z podobnej kategorii z oceną ich mocnych i słabych stron – to bezpośrednie uzasadnienie, dlaczego Twój projekt ma sens.

Dane osobowe i bezpieczeństwo w aplikacji

Jeśli aplikacja przechowuje dane użytkowników – imiona, adresy e-mail, wyniki pomiarów zdrowia czy historię transakcji – w pracy warto pokazać, jak je chronisz. Promotorzy i recenzenci coraz częściej pytają o to na obronie, a odpowiedź „nie myślałem o tym” wypada słabo.

Wystarczy krótki podrozdział: jakie dane zbierasz i po co, gdzie są przechowywane (lokalnie na telefonie czy na serwerze), czy połączenie jest szyfrowane, jak działa logowanie i co się dzieje z danymi po usunięciu konta. Dobrą praktyką jest zbieranie tylko tych informacji, które są naprawdę potrzebne do działania aplikacji, oraz przechowywanie haseł wyłącznie w postaci skrótu.

Co pokazać na obronie?

Obrona pracy z aplikacją to zwykle krótka prezentacja i pokaz działania. Przygotuj scenariusz demonstracji na 3–5 minut: jedno typowe zadanie użytkownika od początku do końca, np. dodanie posiłku i obejrzenie podsumowania tygodnia. Nagraj też zapasowy film z ekranu – na wypadek problemów z siecią lub rzutnikiem.

Komisja często pyta o uzasadnienie wyboru technologii, o to, jak testowano aplikację, i o to, co byś zmienił, mając więcej czasu. Odpowiedzi warto mieć gotowe, bo wynikają wprost z rozdziałów o wymaganiach, testach i podsumowaniu. Pytania o konkretne fragmenty kodu też się zdarzają, dlatego dobrze znać architekturę własnego projektu, a nie tylko jego wygląd.

Harmonogram projektu

Najczęstsze pytania

Czy aplikacja musi być opublikowana w sklepie?

Nie. Wystarczy działająca wersja, którą da się zainstalować i pokazać na obronie. Publikacja w sklepie jest miłym dodatkiem, ale nie wymogiem.

Czym różni się aplikacja na inżynierkę od aplikacji na magisterkę?

W pracy inżynierskiej najważniejszy jest działający projekt i jego dokumentacja. W magisterskiej oczekuje się dodatkowo elementu badawczego, np. porównania rozwiązań – więcej piszemy o tym w tekście o aplikacji mobilnej na pracę magisterską.

Czy aplikacja może korzystać z gotowych bibliotek?

Tak, to normalna praktyka. W pracy wymień użyte biblioteki, ich licencje i to, do czego służą. Twoim wkładem jest architektura, logika aplikacji i integracja elementów.

Czy potrzebuję serwera?

Nie zawsze. Wiele aplikacji na inżynierkę działa lokalnie z bazą SQLite lub Room. Serwer albo usługa typu Firebase przydaje się, gdy dane mają być synchronizowane między urządzeniami lub użytkownikami.

Jak długo trwa przygotowanie aplikacji na inżynierkę?

Zwykle 4–6 miesięcy łącznie z pisaniem. Sama implementacja to najczęściej dwa–trzy miesiące, jeśli znasz już wybraną technologię. Gdy uczysz się jej od zera, dolicz co najmniej miesiąc.

Czy mogę liczyć na pomoc przy projekcie?

Tak – pomagamy przy analizie wymagań, architekturze, dokumentacji i opisie implementacji. Szczegóły znajdziesz na stronie o projektach informatycznych.