Zanim promotor zaakceptuje temat pracy inżynierskiej z informatyki, chce zobaczyć projekt badawczy — krótki dokument, który dowodzi, że pomysł da się zrealizować w wyznaczonym czasie, a nie tylko brzmi dobrze w jednym zdaniu. Ten artykuł pokazuje osiem elementów takiego projektu, gotowy — w pełni ilustracyjny — przykład na temacie systemu rezerwacji sal uczelnianych oraz listę błędów, przez które promotorzy najczęściej odsyłają proposal do poprawy. Jeśli dopiero zaczynasz, przeczytaj go od początku do końca — kolejność sekcji odpowiada kolejności, w jakiej warto pisać sam dokument.
Czym projekt badawczy w informatyce różni się od proposalu w naukach społecznych
W naukach społecznych proposal opisuje głównie metodę zbierania danych od ludzi. W informatyce chodzi o co innego: trzeba udowodnić, że da się zaprojektować, zbudować i przetestować konkretny system w czasie jednego lub dwóch semestrów, mając do dyspozycji jedną osobę i ograniczony budżet sprzętowy. Dlatego projekt badawczy do pracy inżynierskiej z informatyki jest bliższy dokumentacji projektowej niż klasycznemu proposalowi badawczemu — ale wciąż musi odpowiadać na pytanie, czego dokładnie dowodzi ukończony projekt.
Czym różni się projekt badawczy od karty tematu pracy dyplomowej
Wiele wydziałów wymaga formalnej „karty tematu” — jednostronicowego dokumentu z tytułem, promotorem i jednozdaniowym opisem, który zatwierdza dziekanat. Projekt badawczy opisany w tym artykule to zupełnie inny, obszerniejszy dokument: powstaje zwykle przed kartą tematu albo równolegle z nią i służy przekonaniu samego promotora, że temat jest wykonalny, zanim jeszcze trafi do formalnego obiegu. Mylenie tych dwóch dokumentów to częsta przyczyna nieporozumień na pierwszych konsultacjach — karta tematu nie zastępuje przemyślanego planu technicznego, a plan techniczny nie zwalnia z wypełnienia karty.
Osiem elementów projektu badawczego — i dlaczego każdy jest potrzebny
- Temat i uzasadnienie — jedno zdanie mówiące, jaki problem system rozwiązuje i dla kogo.
- Cel i zakres — co system ma robić, a czego świadomie NIE robi (zakres negatywny chroni przed rozrostem projektu w trakcie realizacji).
- Wstępna analiza wymagań — lista wymagań funkcjonalnych i niefunkcjonalnych na poziomie ogólnym, do rozwinięcia w rozdziale analitycznym pracy.
- Stack technologiczny i uzasadnienie wyboru — nie „bo znam ten język”, tylko kryteria: wydajność, dostępność bibliotek, zgodność z wymaganiami niefunkcjonalnymi.
- Szkic architektury — diagram wysokiego poziomu (moduły, przepływ danych), bez szczegółów implementacyjnych.
- Plan pracy i harmonogram — kamienie milowe powiązane z semestrem akademickim, nie tylko „analiza — implementacja — testy”.
- Kryteria oceny i plan testów — jak sprawdzisz, że system spełnia założenia (testy funkcjonalne, wydajnościowe, akceptacyjne).
- Ryzyka i plan B — co zrobisz, jeśli wybrana biblioteka okaże się niewystarczająca albo harmonogram się przesunie.
Ile miejsca zająć każdemu elementowi — orientacyjny rozkład
Poniższy rozkład jest orientacyjny — dla dwu-czterostronicowego proposalu, jaki najczęściej akceptują promotorzy informatyki:
| Element | Orientacyjny udział | Typowy błąd do uniknięcia |
|---|---|---|
| Temat, uzasadnienie, cel i zakres | ok. 20% | brak zakresu negatywnego |
| Wymagania (funkcjonalne/niefunkcjonalne) | ok. 20% | przeniesienie pełnej specyfikacji z rozdziału analitycznego |
| Stack i architektura | ok. 25% | wybór technologii bez uzasadnienia |
| Harmonogram | ok. 15% | etapy bez dat i punktów kontrolnych |
| Kryteria oceny i ryzyka | ok. 20% | brak planu B dla ryzyka technicznego |
Przykład: system rezerwacji sal uczelnianych — projekt badawczy (treść ilustracyjna)
Temat i uzasadnienie: „System rezerwacji sal dydaktycznych z modułem powiadomień dla studentów i pracowników wydziału” — rozwiązuje realny problem podwójnych rezerwacji w arkuszach współdzielonych.
Cel i zakres: celem jest zbudowanie aplikacji webowej pozwalającej rezerwować sale w czasie rzeczywistym i wysyłającej powiadomienia e-mail o zmianach. Poza zakresem: integracja z systemem dziekanatowym, aplikacja mobilna, obsługa wielu uczelni jednocześnie.
Wymagania (wybrane): system musi obsłużyć min. 50 równoczesnych rezerwacji bez konfliktu (funkcjonalne), czas odpowiedzi interfejsu poniżej dwóch sekund przy typowym obciążeniu (niefunkcjonalne, do zweryfikowania testem wydajnościowym w rozdziale z wynikami).
Stack: backend w architekturze REST, baza relacyjna ze względu na silne wymogi spójności rezerwacji, framework frontendowy z gotowym kalendarzem komponentów — wybór uzasadniony potrzebą szybkiego UI, nie osobistym sentymentem.
Ryzyko: biblioteka kalendarza może nie obsługiwać stref czasowych poprawnie — plan B to komponent własny na bazie prostszej biblioteki dat.
Wymagania funkcjonalne i niefunkcjonalne — gdzie kończy się proposal, a zaczyna rozdział analityczny
Częsty błąd: student przenosi do proposalu pełną specyfikację wymagań, którą planował dopiero opracować w pracy. Proposal potrzebuje tylko wymagań na tyle konkretnych, żeby ocenić wykonalność — reszta trafia do rozdziału analitycznego pracy, gdzie ma znacznie więcej miejsca na uzasadnienie każdego wyboru. Pełną strukturę takiego rozdziału i to, jak wygląda gotowy rozdział z wynikami dla pracy inżynierskiej z informatyki, pokazaliśmy w osobnym artykule: jak napisać rozdział z wynikami, testami i dyskusją w pracy inżynierskiej z informatyki. Dobra praktyka: w proposalu wypisz maksymalnie pięć–siedem wymagań kluczowych dla wykonalności, resztę odłóż do rozdziału analitycznego, gdzie i tak trzeba je będzie rozwinąć o kryteria akceptacji.
Jak dobrać stack technologiczny, żeby promotor nie zapytał „dlaczego akurat to”
Trzy kryteria, które działają w każdej rozmowie z promotorem: zgodność z wymaganiami niefunkcjonalnymi (np. wydajność, skalowalność), dostępność dokumentacji i wsparcia społeczności (istotne przy jednoosobowym projekcie bez zespołu), oraz zgodność z tym, czego uczy program studiów — wybór technologii kompletnie spoza sylabusa wymaga dodatkowego uzasadnienia, dlaczego był konieczny. Zdanie „wybrałem X, bo jest popularny” nigdy nie wystarcza — zawsze potrzebne jest odniesienie do konkretnego wymagania projektu.
Harmonogram — jak powiązać go z semestrem, a nie tylko z etapami projektu
Harmonogram złożony wyłącznie z etapów „analiza, projekt, implementacja, testy, pisanie” nie mówi promotorowi nic o realnym ryzyku terminowym. Lepszy harmonogram przypisuje każdemu etapowi tygodnie kalendarzowe semestru i zaznacza punkty kontrolne — konsultacje z promotorem, w których student pokazuje działający fragment systemu, a nie tylko opowiada o planach.
Kryteria oceny i plan testów — trzy poziomy, które warto rozróżnić
Dobry proposal rozróżnia trzy poziomy testowania, które później stają się osobnymi podrozdziałami rozdziału z wynikami: testy funkcjonalne (czy system robi to, co ma robić), testy wydajnościowe (czy robi to wystarczająco szybko przy założonym obciążeniu) oraz testy akceptacyjne (czy końcowy użytkownik — w tym przykładzie pracownik dziekanatu — uznaje system za użyteczny). Zapowiedzenie tych trzech poziomów już w proposalu pokazuje promotorowi, że student rozumie różnicę między „działa” a „działa wystarczająco dobrze”.
Jak przedstawić proposal na pierwszych konsultacjach z promotorem
Promotor, czytając proposal po raz pierwszy, szuka odpowiedzi na trzy pytania, nawet jeśli nie zada ich wprost: czy student rozumie różnicę między tym, co chce zbudować, a tym, co da się zbudować w wyznaczonym czasie; czy wybory technologiczne mają uzasadnienie, a nie są przypadkowe; czy student przewidział, co może pójść nie tak. Warto przygotować krótkie, jednozdaniowe odpowiedzi na każde z tych pytań przed spotkaniem — nawet jeśli nie padną wprost, rozmowa i tak będzie wokół nich krążyć.
Dlaczego warto pokazać proposal komuś spoza własnego kierunku
Osoba niezaznajomiona z tematem technicznym szybko wychwyci to, czego student — zanurzony w projekcie od tygodni — już nie widzi: żargon bez wyjaśnienia, założenia, które wydają się oczywiste tylko autorowi, oraz luki w opisie, dlaczego dany problem w ogóle wymaga rozwiązania informatycznego. Jeśli osoba z zewnątrz rozumie cel i zakres projektu po jednorazowej lekturze, to dobry sygnał, że promotor — który czyta dziesiątki takich dokumentów rocznie — zrozumie go jeszcze szybciej.
Co zrobić, jeśli zakres zmienia się w trakcie realizacji
Rzadko kiedy realizacja przebiega dokładnie według pierwotnego proposalu — biblioteka okazuje się niewystarczająca, wymaganie trzeba doprecyzować po pierwszych testach z użytkownikiem, albo harmonogram przesuwa się o dwa tygodnie. To normalne, pod jednym warunkiem: każda istotna zmiana zakresu, stacku lub harmonogramu powinna zostać krótko udokumentowana i zgłoszona promotorowi, najlepiej z jednym zdaniem uzasadnienia. Taka notatka staje się też gotowym materiałem do rozdziału metodycznego pracy — sekcja „ograniczenia i zmiany względem pierwotnego planu” pisze się wtedy sama, zamiast wymagać rekonstrukcji z pamięci tuż przed obroną.
Czy warto konsultować proposal z kimś poza własnym promotorem
Jeśli wydział przewiduje wcześniejsze przypisanie recenzenta albo opiekuna roku, krótka konsultacja proposalu z tą osobą — jeszcze przed formalnym złożeniem tematu — bywa tańsza niż poprawki po fakcie. Recenzent czyta pracę inaczej niż promotor: mniej interesuje go entuzjazm wobec technologii, bardziej to, czy zakres da się rzetelnie ocenić w wyznaczonym czasie egzaminu. Warto też, jeśli to możliwe, skonsultować proposal ze starszym rocznikiem, który przechodził już przez obronę na tym samym wydziale — praktyczna wiedza o tym, czego konkretny promotor lub komisja oczekuje, rzadko trafia do oficjalnego regulaminu.
Najczęstsze błędy w projekcie badawczym do pracy z informatyki
- Zakres bez granicy negatywnej. Brak jasnego „czego system NIE robi” prowadzi do rozrostu projektu w trakcie realizacji i przesunięcia terminu.
- Stack wybrany bez uzasadnienia. „Bo znam ten język” to za mało — promotor oczekuje powiązania wyboru z wymaganiami.
- Harmonogram bez punktów kontrolnych. Same nazwy etapów, bez dat i bez sposobu sprawdzenia postępu, nie pozwalają wychwycić opóźnienia, zanim będzie za późno na reakcję.
- Brak planu B dla ryzyka technicznego. Projekt, który zakłada, że wszystko zadziała za pierwszym razem, jest podejrzany dla każdego, kto kiedykolwiek pisał kod.
Co dalej po zaakceptowanym proposalu
Zaakceptowany projekt badawczy to dopiero brama do pracy właściwej. Pełną strukturę rozdział po rozdziale, zgodną z wymaganiami polskich wydziałów informatyki, opisaliśmy osobno: jak napisać pracę inżynierską z informatyki. Jeśli temat z tego przykładu Cię nie przekonuje, zobacz też 30 przykładów tytułów prac dyplomowych z informatyki w sześciu obszarach. A jeśli w projekcie planujesz korzystać z generatywnej AI przy pisaniu kodu, sprawdź najpierw zasady deklarowania takiej pomocy: AI w pracy inżynierskiej z informatyki — co wolno, co trzeba zadeklarować.
Najczęstsze pytania o projekt badawczy do pracy inżynierskiej z informatyki
Ile stron powinien mieć projekt badawczy (proposal) do pracy inżynierskiej?
Najczęściej dwie do czterech stron — to dokument roboczy do akceptacji promotora, nie rozdział pracy. Dokładny limit ustala regulamin wydziału lub sam promotor.
Czy proposal musi zawierać kod źródłowy lub prototyp?
Zwykle nie — proposal opisuje plan, nie implementację. Część promotorów akceptuje krótki szkic architektury lub makietę interfejsu jako załącznik, ale nie jest to standardowy wymóg.
Co zrobić, jeśli w trakcie realizacji trzeba zmienić stack technologiczny z proposalu?
Zgłoś zmianę promotorowi od razu, z krótkim uzasadnieniem — dlaczego pierwotny wybór okazał się niewystarczający. Nieprzedyskutowana zmiana technologii bez wiedzy promotora bywa traktowana jako odejście od zaakceptowanego zakresu.
Czy zakres negatywny („czego system nie robi”) jest obowiązkowy?
Nie ma jednego ogólnopolskiego wymogu, ale w praktyce mocno chroni przed rozrostem projektu — promotorzy chętnie go widzą, nawet jeśli regulamin go nie wymaga wprost.
Czy projekt badawczy do informatyki różni się między pracą inżynierską a magisterską?
Tak — praca magisterska zwykle wymaga głębszej analizy alternatywnych rozwiązań i szerszego planu ewaluacji, podczas gdy praca inżynierska kładzie większy nacisk na sam działający produkt.
Czy karta tematu i projekt badawczy to ten sam dokument?
Nie. Karta tematu to krótki formalny dokument zatwierdzany przez dziekanat, projekt badawczy to obszerniejszy plan techniczny przygotowywany dla promotora, zwykle przed kartą tematu lub równolegle z nią.
Jak udokumentować zmiany zakresu, żeby ułatwić sobie pisanie rozdziału metodycznego?
Wystarczy krótka notatka po każdej istotnej zmianie: co się zmieniło i dlaczego. Zebrane razem, takie notatki stają się gotowym materiałem do sekcji o ograniczeniach i odstępstwach od pierwotnego planu.
Podsumowanie w trzech zdaniach
Dobry projekt badawczy do pracy inżynierskiej z informatyki mieści się na kilku stronach, ale odpowiada na wszystkie pytania, które promotor i tak zada podczas obrony. Osiem elementów z tego artykułu — temat, cel i zakres, wymagania, stack, architektura, harmonogram, kryteria oceny i ryzyka — to nie biurokracja, tylko najtańszy sposób na wychwycenie problemów, zanim pochłoną tygodnie pracy. Im wcześniej powstanie, tym mniej niespodzianek czeka na etapie pisania rozdziałów właściwej pracy.