Praca magisterska z informatyki rządzi się innymi prawami niż praca z nauk humanistycznych czy medycznych. Oceniasz ją nie tylko tekstem, ale działającym systemem, a promotor i recenzent będą sprawdzać, czy Twój opis implementacji jest dokładny, czy diagramy odpowiadają kodowi i czy testy rzeczywiście coś weryfikują. Ten przewodnik przeprowadza przez wszystkie etapy: od wyboru typu pracy i specyfikacji wymagań, przez architekturę i opis kodu, aż po dokumentowanie wyników eksperymentów i cytowanie w systemie IEEE.
Praca magisterska vs. inżynierska z informatyki, kluczowe różnice
Zanim zaczniesz pisać, ustal z promotorem typ pracy. Wymagania formalne są różne na każdej uczelni, ale w praktyce różnica sprowadza się do trzech elementów:
| Kryterium | Praca inżynierska | Praca magisterska |
|---|---|---|
| Nacisk | Działający system / aplikacja | System + warstwa badawcza lub analityczna |
| Teoria | Ogólna, skrótowa | Pogłębiona, powiązana z własną tezą |
| Oryginalność | Implementacja rozwiązania istniejącego problemu | Nowe podejście, nowy algorytm, nowe porównanie lub istotna adaptacja |
| Przegląd literatury | 15-30 pozycji, przegląd ogólny | 40-80+ pozycji, krytyczna analiza related work |
| Eksperymenty | Opcjonalne (demo, scenariusze użycia) | Oczekiwane (benchmarki, testy porównawcze, ewaluacja) |
| Objętość tekstu | 40-60 stron | 60-100 stron |
Praca magisterska musi stawiać tezę lub pytanie badawcze i udzielać na nie odpowiedzi, sama implementacja działającego systemu nie wystarczy.
Typy prac magisterskich z informatyki
Praca projektowa
Tworzysz aplikację, system informatyczny lub narzędzie rozwiązujące konkretny problem. Kluczowe elementy: analiza wymagań, projekt architektury, implementacja, testy. Teza może brzmieć: „Zaproponowane podejście architektoniczne pozwala na obsługę X żądań na sekundę przy zachowaniu opóźnienia poniżej Y ms.”
Praca badawcza
Eksperymentujesz z algorytmami, modelami uczenia maszynowego, protokołami sieciowymi lub metodami bezpieczeństwa. Implementacja jest środkiem do potwierdzenia/obalenia hipotezy, nie celem samym w sobie. Wymaga rzetelnej ewaluacji (metryki, zbiory testowe, statystyki).
Praca przeglądowa (survey)
Systematyczne zestawienie istniejących metod rozwiązania problemu z własną klasyfikacją i analizą porównawczą. Rzadsza na poziomie magisterskim; wymaga dostępu do szerokiej literatury i własnej, uzasadnionej systematyki.
Struktura pracy projektowej, rozdział po rozdziale
Wstęp
Odpowiedz na trzy pytania: jaki problem rozwiązujesz? dlaczego jest ważny (motywacja)? co konkretnie zrobiłeś (zakres pracy)?
Unikaj ogólników w stylu „Informatyka odgrywa coraz większą rolę”. Zacznij od konkretnego problemu: „Systemy monitorowania infrastruktury IT w małych przedsiębiorstwach…”
Wstęp kończy się opisem struktury pracy: „Rozdział 2 zawiera analizę istniejących rozwiązań. Rozdział 3 opisuje specyfikację wymagań…”
Analiza istniejących rozwiązań (related work)
To nie jest lista narzędzi z Internetu, to krytyczne zestawienie stanu wiedzy.
Struktura: pogrupuj rozwiązania tematycznie (np. podejścia komercyjne, open-source, algorytmy z literatury naukowej). Dla każdej grupy: krótki opis, mocne strony, ograniczenia. Zakończ akapitem wskazującym lukę, którą wypełnia Twoja praca.
Cytuj artykuły naukowe (IEEE Xplore, ACM Digital Library, arXiv), nie dokumentację produktową jako główne źródło.
Specyfikacja wymagań
Tabela wymagań z klasyfikacją MoSCoW (Must have, Should have, Could have, Won’t have):
| ID | Typ | Opis wymagania | Priorytet MoSCoW |
|---|---|---|---|
| REQ-F-01 | Funkcjonalne | System umożliwia rejestrację użytkownika przez e-mail | Must |
| REQ-F-02 | Funkcjonalne | Użytkownik może eksportować dane do formatu CSV | Should |
| REQ-F-03 | Funkcjonalne | System obsługuje logowanie przez OAuth 2.0 (Google, GitHub) | Could |
| REQ-NF-01 | Niefunkcjonalne | Czas odpowiedzi API < 200 ms dla 95. percentyla obciążenia | Must |
| REQ-NF-02 | Niefunkcjonalne | Aplikacja działa poprawnie na Chrome 120+, Firefox 120+, Safari 17+ | Must |
| REQ-NF-03 | Niefunkcjonalne | Kod pokryty testami jednostkowymi w ≥ 80% (coverage) | Should |
Wymagania funkcjonalne opisują CO system robi. Wymagania niefunkcjonalne, JAK dobrze to robi (wydajność, bezpieczeństwo, skalowalność, dostępność).
Architektura systemu
Omów i umieść w pracy następujące diagramy UML:
- Diagram przypadków użycia (use case), kto (aktor) robi co (use case); pokazuje zakres systemu z perspektywy użytkownika
- Diagram klas, główne klasy/encje, ich atrybuty, metody i związki (dziedziczenie, asocjacja, agregacja, kompozycja). Dla systemów obiektowych
- Diagram sekwencji, dla kluczowych przepływów (np. proces logowania, realizacja zamówienia).
- Diagram wdrożenia (deployment), serwery, kontenery, bazy danych, komunikacja między komponentami
Dla baz danych: diagram ERD (Entity-Relationship Diagram) z encjami, atrybutami i związkami (1:1, 1:N, M:N).
Zasada: nie wklejaj diagramów bez opisu. Każdy rysunek/schemat musi być numerowany (Rysunek 3.1), mieć podpis i być omówiony w tekście.
Opis implementacji
To najczęściej słabo napisany rozdział. Typowy błąd: autor opisuje każdą klasę z osobna albo kopiuje fragmenty kodu bez wyjaśnienia.
Jak pisać dobrze:
1. Wybierz 3-5 kluczowych problemów technicznych, które rozwiązałeś (np. synchronizacja danych w czasie rzeczywistym, optymalizacja zapytań, integracja z zewnętrznym API).
2. Dla każdego problemu: opis problemu → podjęta decyzja → dlaczego ta, a nie inna → fragment kodu.
3. Fragment kodu jako listing z numerem i podpisem: Listing 4.1. Implementacja strategii retry dla połączeń z API.
Czego nie pisać: nie opisuj standardowych bibliotek (jak używać ReactRouter albo jak działa ORM), zakładasz, że czytelnik zna te narzędzia. Opisuj swoje decyzje i niestandardowe rozwiązania.
Decyzje architektoniczne: jeśli wybrałeś mikroserwisy zamiast monolitu, REST zamiast GraphQL, PostgreSQL zamiast MongoDB, wyjaśnij dlaczego. Dobra praca to świadome wybory, nie przypadkowy dobór technologii.
Wyślij fragment tekstu, bezpłatną wycenę otrzymasz w 24 h. Poprawki bez limitu w cenie usługi.
Dokumentowanie testów
Plan testów
Przed opisem wyników testów opisz plan:
– typy testów i narzędzia (np. Jest dla unit tests, Cypress dla E2E, Postman/Newman dla API),
– kryteria jakości (np. ≥ 80% code coverage),
– środowisko testowe.
Testy jednostkowe i integracyjne
Podaj liczbę testów i wynik (liczba przechodzących/nieprzechodzących). Opcjonalnie: zrzut ekranu raportu coverage. Nie cytuj każdego test case’a, opisz podejście i podsumuj wyniki.
Testy E2E
Lista przetestowanych scenariuszy użytkownika (happy path + edge cases). Wyniki: przechodzi/nie przechodzi, czas wykonania.
Testy wydajnościowe
Jeśli wydajność jest wymaganiem (REQ-NF-01), przeprowadź load test (np. k6, JMeter, Locust) i raportuj wyniki w tabeli.
Jak dokumentować wyniki eksperymentów
Dla prac badawczych (ML, algorytmy, benchmarki) wyniki to serce pracy.
Tabela wyników dla różnych typów systemów
| Metryka | Algorytm A | Algorytm B | Algorytm C | Uwagi |
|---|---|---|---|---|
| Klasyfikacja | ||||
| Accuracy | 0,923 | 0,911 | 0,897 | Zbiór testowy n = 2000 |
| Precision | 0,918 | 0,903 | 0,881 | Micro-average |
| Recall | 0,931 | 0,924 | 0,908 | Micro-average |
| F1-score | 0,924 | 0,913 | 0,894 | Micro-average |
| Wydajność | ||||
| Czas trenowania (s) | 12,4 | 8,7 | 3,1 | GPU RTX 4090 |
| Czas inferencji (ms/próbka) | 0,8 | 1,2 | 0,4 | Batch size 32 |
| Pamięć (MB) | 450 | 280 | 120 | Parametry modelu |
Zasady raportowania:
– Podaj środowisko eksperymentu (hardware, OS, wersja frameworka).
– Dla ML: opisz podział danych (train/val/test), stratyfikację, cross-walidację.
– Użyj tabel dla porównań wielowymiarowych; wykresy (bar chart, krzywa ROC) jako rysunki numerowane.
– Nie interpretuj wyników w rozdziale „Wyniki”, to robi się w „Dyskusji”.
Cytowanie w systemie IEEE
System IEEE używa numerów w nawiasach kwadratowych, ale, inaczej niż Vancouver, dopuszcza ponowne użycie tego samego numeru dla tej samej pozycji w całym tekście.
Artykuł konferencyjny (ACM/IEEE)
[1] J. Dean i S. Ghemawat, „MapReduce: Simplified Data Processing on Large Clusters,” w Proc. 6th Symp. Operating Systems Design and Implementation (OSDI), San Francisco, CA, USA, 2004, ss. 137-150.
Artykuł z arXiv
[2] A. Vaswani i in., „Attention Is All You Need,” arXiv:1706.03762 [cs.CL], 2017. [Online]. Dostępny: https://arxiv.org/abs/1706.03762. [Dostęp: 12 mar. 2025].
Dokumentacja techniczna / standard ISO
[3] ISO/IEC 25010:2011, Systems and Software Engineering, Systems and Software Quality Requirements and Evaluation (SQuaRE), System and Software Quality Models, ISO, Genewa, 2011.
Książka
[4] R. C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design, Upper Saddle River, NJ, USA: Prentice Hall, 2017.
Zasady ogólne:
– Tytuł artykułu: cudzysłów. Tytuł czasopisma/konferencji/książki: kursywa.
– Lista cytowań w kolejności pierwszego cytowania w tekście.
– Odwołanie w tekście: [1], [2], [3, 4] lub [1]-[4] (zakres ciągły).
– Materiały internetowe: zawsze podaj datę dostępu.
Najczęstsze błędy w pracach z informatyki
- Brak tezy / pytania badawczego, sama implementacja to za mało na poziomie magisterskim
- Diagramy UML niespójne z kodem, recenzent sprawdza, czy klas diagram odpowiada klasom w repozytorium
- Related work bez krytyki, lista narzędzi bez wskazania luk nie jest analizą
- Opis implementacji = lista klas z opisami getterów, wyjaśniaj decyzje, nie dokumentuj oczywistości
- Brak środowiska eksperymentu, wyniki bez specyfikacji sprzętu/oprogramowania nie są reprodukowalne
- Cytowanie strony producenta zamiast artykułu naukowego, dla twierdzeń metodologicznych szukaj źródeł w IEEE Xplore, ACM DL lub arXiv
FAQ, najczęściej zadawane pytania
Ile kodu powinienem wkleić do pracy magisterskiej?
Minimum, tylko fragmenty kluczowe dla zilustrowania Twoich decyzji (trudny algorytm, niestandardowy wzorzec). Każdy listing powinien być numerowany i opisany. Kompletny kod umieszcza się w repozytorium (link w pracy lub załącznik na płycie/DVD/GitHub). Wklejanie dziesiątek stron kodu bez komentarza obniża ocenę.
Czy muszę pisać testy, jeśli promotor o tym nie mówił?
Testy to element specyfikacji jakości systemu. Jeśli w wymaganiach niefunkcjonalnych masz kryterium jakości (coverage, liczba testów), to tak, musisz. W nowoczesnych pracach z informatyki brak sekcji o testach jest widocznym brakiem. Nawet krótki opis unit testów i scenariuszy manualnych podnosi ocenę.
Jak opisać technologie użyte w projekcie?
Nie pisz rozdziału „Omówienie technologii” z encyklopedycznym opisem Reacta czy Springa, recenzent je zna. Zamiast tego w rozdziale o architekturze wymień stos technologiczny (tabela: warstwa → technologia → wersja → uzasadnienie wyboru) i dalej skupiaj się na tym, co zrobiłeś z tymi narzędziami.
Jak pisać o bezpieczeństwie w pracy z informatyki?
Jeśli tworzysz system webowy lub API, uwzględnij minimum jeden akapit w wymaganiach niefunkcjonalnych (np. OWASP Top 10) i opisz konkretne zabezpieczenia w implementacji (np. hashowanie haseł, bcrypt, CSRF token, walidacja wejścia). Nie opisuj teorii bezpieczeństwa, opisuj to, co zaimplementowałeś.
Czy praca z informatyki wymaga korekty językowej?
Tak, szczególnie prace pisane po polsku przez osoby na co dzień pracujące w języku angielskim (kod, dokumentacja, literatura). Typowe problemy: kalk językowych z angielskiego, błędy w odmianie terminów technicznych, niespójne nazewnictwo (ta sama klasa/funkcja różnie nazywana w tekście). Korekta prac technicznych z zachowaniem terminologii informatycznej jest dostępna na dobrzenapisane.pl, wycena w 24 godziny.
Ile pozycji bibliograficznych powinno być w pracy magisterskiej z informatyki?
Dla pracy projektowej: 30-60 pozycji. Dla pracy badawczej lub survey: 60-100+. Priorytetuj artykuły z recenzowanych konferencji (ACM, IEEE, USENIX, NeurIPS, ICML) i journali. Dokumentacja techniczna jako źródło uzupełniające, nie jako główna podstawa twierdzeń merytorycznych.
