Korekta pracy magisterskiej z informatyki, specyfika i wymagania

Praca magisterska z informatyki to jeden z najbardziej specyficznych tekstów naukowych, z którymi pracuję. Wymaga innego podejścia niż praca z nauk humanistycznych, ekonomii czy psychologii, i wielu korektorów po prostu tego podejścia nie ma. Nie wystarczy znajomość zasad poprawnej polszczyzny. Trzeba rozumieć, dlaczego „serwer” pisze się przez jedno „r”, dlaczego „framework” zostaje po angielsku, a „oprogramowanie” nie zastępuje „software” w każdym kontekście, i umieć odróżnić błąd językowy od decyzji merytorycznej autora, której korektor nie powinien zmieniać.

Ten artykuł wyjaśnia, czego powinieneś oczekiwać od korekty pracy informatycznej i jak przygotować tekst, żeby korekta przyniosła maksymalne efekty.

Specyfika językowa prac informatycznych

Terminologia angielska a polskie odpowiedniki

W informatyce żyją obok siebie trzy grupy terminów:

Grupa 1: Terminy, które mają ustalone polskie odpowiedniki i należy ich używać

Oto lista najczęstszych:
– algorithm → algorytm
– database → baza danych
– operating system → system operacyjny
– network → sieć
– file → plik
– user → użytkownik
– variable → zmienna
– function → funkcja
– loop → pętla
– compiler → kompilator

Te terminy mają jednoznaczne, powszechnie akceptowane odpowiedniki. Użycie „database” zamiast „baza danych” w polskim tekście naukowym to błąd językowy, który korektor poprawia.

Grupa 2: Terminy, które funkcjonują równolegle, angielski i polski

• software ↔ oprogramowanie (oba poprawne, konsekwencja wewnątrz pracy jest ważniejsza)
• hardware ↔ sprzęt komputerowy / sprzęt
• framework ↔ środowisko programistyczne / platforma (ale „framework” bywa akceptowany w tekstach akademickich jako termin specjalistyczny)
• deployment ↔ wdrożenie
• bug ↔ błąd / usterka
• patch ↔ łatka / aktualizacja

Tu decyzja należy do autora. Jeżeli wybierasz „oprogramowanie”, używaj go konsekwentnie w całej pracy. Jeżeli decydujesz się na „software” jako termin techniczny, upewnij się, że nie mieszasz go z „oprogramowaniem” w losowych miejscach.

Grupa 3: Terminy, których nie tłumaczymy lub których tłumaczenie jest nieakceptowane

• Python, JavaScript, React, Docker, Kubernetes, Git, to nazwy własne, nie tłumaczymy
• API (Application Programming Interface), akronim anglojęzyczny, powszechnie używany po angielsku; przy pierwszym użyciu w tekście naukowym dopuszcza się rozwinięcie
• REST, SOAP, GraphQL, JSON, XML, akronimy i protokoły techniczne, zostają po angielsku
• machine learning ↔ uczenie maszynowe (oba akceptowane, „deep learning” można oddać jako „uczenie głębokie”, ale praktyka akademicka przyjęła angielski termin)

Przy korekcie pracy magisterskiej z informatyki nie zmieniam decyzji terminologicznych autora, jeżeli konsekwentnie wybrałeś „learning maszynowy” zamiast „uczenie maszynowe”, zaznaczę to jako sugestię, ale ostateczna decyzja jest twoja.

Spolszczenia nazw technologii

Spolszczenia wymagają odmiany przez przypadki. Tu pojawiają się typowe błędy:

• „Pythona” (D. lp.), poprawne
• „Pythonie” (Ms. lp.), poprawne: „w Pythonie”, „aplikacja w Reactcie” jest akceptowana w mowie potocznej, ale w tekście naukowym lepiej „aplikacja w technologii React” lub „aplikacja napisana w Reakcie” (choć to drugie brzmi dziwnie)
• „Dockera” (D. lp.), poprawne: „obraz Dockera”, „kontenery Dockera”
• „Gita” (D. lp.), poprawne: „repozytorium Gita”

Zasada ogólna: technologie o zakończeniu spółgłoskowym spolszczamy przez dodanie końcówek fleksyjnych bez apostrofu. Apostrofa używamy tylko wyjątkowo, przy nazwach kończących się na literę, która nie pozwala na intuicyjną wymowę.

Opisywanie implementacji i kodu źródłowego

Jak cytować kod w pracy magisterskiej

Kod źródłowy w pracy magisterskiej cituje się jako listing. Każdy listing powinien:

• być ponumerowany (Listing 1, Listing 2…),
• mieć tytuł opisujący funkcję kodu (np. „Listing 3. Implementacja funkcji sortowania przez wstawianie”),
• być sformatowany czcionką o stałej szerokości (Courier New, Consolas),
• być oddzielony od tekstu głównego, nie wplatamy kodu w akapity narracyjne
• być odwołany w tekście („jak przedstawia Listing 3” lub „co ilustruje kod zamieszczony w Listingu 3”).

Przykład: nie piszesz „zaimplementowałem funkcję def sort_insert(arr): for i in range...” w środku akapitu. Piszesz „zaimplementowałem algorytm sortowania przez wstawianie (Listing 3)”, a sam kod pojawia się jako wyodrębniony blok z numerem i tytułem.

Długość listingów: nie wklejaj do pracy całego projektu. Cytuj fragmenty o znaczeniu kluczowym dla omawianych zagadnień. Kompletny kod trafia do aneksu albo do repozytorium (z podaniem URL w pracy).

Styl pisania o implementacji

Prace informatyczne mają tendencję do pasywnego opisu technicznego: „system został zaimplementowany przy użyciu architektury trójwarstwowej, w której warstwa prezentacji komunikuje się z warstwą logiki biznesowej za pośrednictwem interfejsów REST API”. To zdanie jest poprawne, ale ciężkie.

Dobra praktyka to naprzemienne stosowanie strony czynnej i biernej. Strona bierna w opisie systemu („warstwa została zaimplementowana”) jest akceptowalna i typowa dla polskich prac naukowych. Strona czynna („autor zaimplementował warstwę”) brzmi czasem sztuczne w kontekście technicznym. Decyzja należy do autora, korektor pilnuje tylko konsekwencji.

Unikaj skrótów myślowych, które są zrozumiałe w mowie, a na piśmie wyglądają niedbale:

• „odpalić serwer” → „uruchomić serwer”
• „wrzucić do bazy” → „zapisać do bazy danych” / „załadować dane do bazy”
• „zrobić request” → „wysłać żądanie HTTP” / „wykonać zapytanie”
• „puknąć endpoint” → to sformułowanie nie powinno w ogóle pojawiać się w tekście naukowym

Diagramy UML i schematy blokowe, zasady opisu

Każdy diagram UML, schemat blokowy, diagram przepływu danych lub diagram architektury musi być:

1. Ponumerowany jako rysunek lub schemat (zależnie od konwencji wydziału).
2. Opatrzony tytułem poniżej diagramu lub powyżej, zależnie od wymagań wydziału
3. Odwołany w tekście przed jego pojawieniem się: „architektura systemu przedstawiona na Rysunku 4 składa się z…”.
4. Opisany słownie, nie zostawiaj diagramu bez objaśnienia. Diagram uzupełnia tekst, nie zastępuje go

Co korektor ocenia w diagramach

Korektor językowy nie ocenia poprawności diagramu UML jako takiego, to zadanie promotora i recenzenta. Sprawdzam natomiast:

• czy diagram ma numer i tytuł
• czy tytuł jest gramatycznie poprawny i informacyjny
• czy w tekście jest odwołanie do diagramu
• czy opis słowny diagramu jest spójny z tym, co diagram przedstawia (w zakresie, w jakim to oceniam jako osoba czytająca tekst),
• czy nazwy elementów w diagramie są spójne z nazwami używanymi w tekście (np. jeżeli w UML jest „UserService”, a w tekście autor pisze o „serwisie użytkownika”, zaznaczam niespójność jako sugestię).

Cytowanie dokumentacji technicznej, RFC, ISO, IEEE

To obszar, w którym prace informatyczne wyróżniają się na tle innych dziedzin. Cytowanie standardów technicznych ma swoją specyfikę.

RFC (Request for Comments)

RFC to formalne dokumenty standardów internetowych publikowane przez IETF. Cytuje się je przez numer i autorów:

• Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., & Berners-Lee, T. (1999). Hypertext Transfer Protocol, HTTP/1.1. RFC 2616. Internet Engineering Task Force

Alternatywny format (w przypisach):
– RFC 2616 (HTTP/1.1), IETF, 1999.

Normy ISO i IEEE

Normy cytuje się pełnymi tytułami z numerem normy:

• ISO/IEC 25010:2011. (2011). Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models. International Organization for Standardization.

• IEEE Std 829-2008. (2008). IEEE Standard for Software and System Test Documentation. Institute of Electrical and Electronics Engineers.

Dokumentacja techniczna oprogramowania

Dokumentacja bibliotek, frameworków i narzędzi (np. React docs, Django documentation) jest cytowana jak zasób internetowy z datą dostępu:

• React Team. (2023). React Documentation: Hooks. Pobrano 12 marca 2024 z https://react.dev/reference/react

Sprawdź, jakiego stylu cytowania wymaga twój wydział, APA, Vancouver czy własny styl uczelniany. Różne style mają różne wymagania dotyczące daty dostępu i formatowania URL.

Wymagania wydziałowe, przegląd

AGH (Akademia Górniczo-Hutnicza, Kraków)

AGH udostępnia oficjalny szablon pracy dyplomowej w LaTeXu i Wordzie. Wymagania:
– Czcionka: Times New Roman 12 (tekst główny), nagłówki wg szablonu.
– Marginesy: 2,5 cm z każdej strony (lewy może być szerszy przy oprawie).
– Interlinia: 1,5 w tekście głównym.
– Kod źródłowy: czcionka Courier New 10, wyodrębniony blok.
– Styl cytowania: IEEE (literatura techniczna) lub wg decyzji promotora.

AGH przykłada wagę do poprawności opisów rysunków i listingów, to element oceniany formalnie.

Politechnika Wrocławska

PWr wymaga złożenia pracy przez system APD (Archiwum Prac Dyplomowych). Obowiązują wytyczne wydziałowe (różne na różnych wydziałach). Na Wydziale Informatyki i Telekomunikacji standardem jest:
– LaTeX preferowany, Word akceptowany.
– Styl bibliograficzny: IEEE lub ACM (zależy od katedry).
– Wymagany streszczenie po polsku i po angielsku.

Politechnika Warszawska

PW ma bardzo szczegółowe wymagania formalne dostępne na stronie wydziału. Wydział Elektryczny i Wydział Informatyki mają częściowo odmienne szablony. Wspólne zasady:
– Marginesy: lewy 3 cm (oprawa), pozostałe 2,5 cm.
– Czcionka tekstu: Times New Roman 12 lub Arial 11.
– Numeracja stron: dolna, środkowa lub prawa.
– Diagramy i rysunki: podpisy pod spodem, numerowane per rozdział (Rysunek 2.3 = trzeci rysunek drugiego rozdziału).

PJATK (Polsko-Japońska Akademia Technik Komputerowych)

PJATK dopuszcza pisanie pracy magisterskiej po angielsku lub po polsku. Przy pracy po polsku obowiązuje streszczenie w języku angielskim. PJATK kładzie nacisk na aspekt praktyczny, wiele prac to implementacje systemów, co oznacza obszerną dokumentację techniczną w aneksach.

Co korektor może, a czego nie może ocenić

Co korektor ocenia w pracach informatycznych

• Poprawność językową i stylistyczną całego tekstu (interpunkcja, fleksja, składnia).
• Konsekwencję terminologiczną, czy ten sam termin jest używany w tej samej formie przez całą pracę
• Poprawność tytułów rozdziałów, listingów, rysunków i tabel
• Spójność odwołań do rysunków i listingów z ich faktyczną lokalizacją
• Formalne aspekty opisów elementów graficznych
• Styl naukowy, eliminacja kolokwializmów, slangu technicznego, nieprecyzyjnych sformułowań
• Poprawność cytowań pod kątem formalnym (format, kompletność, spójność z bibliografią).

Czego korektor nie ocenia

• Poprawności algorytmów, kodu, architektury systemu, wyboru technologii, to zadanie promotora i recenzenta
• Merytorycznej poprawności twierdzeń technicznych (np. czy opisana architektura mikrousług jest właściwym rozwiązaniem dla danego problemu).
• Kompletności implementacji, czy system działa, czy testy pokrywają wymagany zakres
• Poprawności diagramów UML pod kątem zgodności z notacją (czy klasy i relacje są poprawnie reprezentowane), chyba że błąd jest oczywisty i wpływa na czytelność tekstu

Jeżeli widzę coś, co wygląda na błąd merytoryczny, zaznaczam jako sugestię z komentarzem „sprawdź z promotorem”, ale nie poprawiam samodzielnie.

Błędy językowe specyficzne dla prac informatycznych

Powtórzenia terminologiczne

Informatyczne prace naukowe mają tendencję do używania wąskiego zasobu słów kluczowych, co generuje powtórzenia. Szczególnie dotyczy to słów „implementacja/zaimplementować”, „system”, „dane”, „użytkownik”.

Rozwiązanie nie polega na szukaniu synonimów na siłę, „system” nie zawsze można zastąpić „rozwiązaniem” bez zmiany znaczenia. Lepsza technika to przebudowa zdań, żeby te same słowa nie pojawiały się w dwóch sąsiednich zdaniach.

Nadużywanie strony biernej

„Dane zostały pobrane, przetworzone i zapisane do bazy. Wyniki zostały zwrócone do interfejsu. Interfejs wyświetlił dane użytkownikowi”, trzy zdania z bierną z rzędu to za dużo. Przeplataj stroną czynną.

Błędna odmiana nazw własnych technologii

• „w Django”, poprawne
• „w Djangu”, błąd (końcówka narzucana przez polską fleksję bez podstawy)
• „przy pomocy Reacta”, poprawne
• „przy pomocy React”, nieodmienione, w tekście naukowym niezalecane
• „za pomocą Git-a”, apostrof niepotrzebny, „za pomocą Gita” wystarczy

Mieszanie systemów numeracji

Raz „Rysunek 1”, raz „Rys. 1”, raz „Fig. 1” w tej samej pracy, to błąd konsekwencji. Wybierz jeden format i stosuj go przez całą pracę.

Czas realizacji korekty pracy z informatyki

Korekta pracy magisterskiej z informatyki zajmuje więcej czasu niż korekta pracy humanistycznej o zbliżonej objętości. Powody:

• Terminologia wymaga uwagi i konsekwentnego sprawdzania każdego użycia
• Opisy algorytmów i implementacji wymagają wolniejszego czytania
• Listingi kodu wymagają weryfikacji podpisów i odwołań

Dla pracy o objętości 80-100 stron znormalizowanych czas korekty to zazwyczaj 5-7 dni roboczych. Przy pracach zawierających obszerną dokumentację techniczną (powyżej 120 stron), 7-10 dni.

Zawsze podaję realny termin przy wycenie, żebyś mógł zaplanować oddanie pracy. Jeżeli masz twardy deadline związany z obroną, napisz mi o nim od razu, ustalimy, czy jest to wykonalne i co zrobić, jeżeli czas jest bardzo napięty.

Zanim wyślesz pracę do korekty, przeczytaj mój poradnik o metodologii pracy magisterskiej, często właśnie sekcja metodologiczna w pracach informatycznych wymaga największej pracy redakcyjnej.

Jak przygotować pracę informatyczną do korekty

1. Wyślij kompletny dokument, nie fragmenty. Korektor musi widzieć całość, żeby ocenić spójność terminologiczną
2. Dołącz informację o stylu cytowania (APA, IEEE, własny uczelniany).
3. Jeżeli używasz skrótów i akronimów, dołącz listę skrótów z rozwinięciami albo upewnij się, że każdy akronim jest rozwinięty przy pierwszym użyciu
4. Wskaż, czy praca zawiera fragmenty po angielsku (abstrakt, opisy w kodzie, komentarze), żebym wiedziała, co oceniam jako tekst główny, a co jako cytowanie lub kod
5. Podaj wymagania formalne swojego wydziału albo dołącz link do wytycznych

Najczęściej zadawane pytania

Natalia Witek-Dąbrowska

Redaktorka i korektorka z 20-letnim doświadczeniem

Specjalizuję się w korekcie prac naukowych i dyplomowych. Jeśli potrzebujesz pomocy z tekstem, napisz do mnie.