Prace magisterskie i dyplomowe/inżynierskie - FAQ (wersja 2024.06.18)

Mam już opiekuna/promotora i co teraz?

• wspólna praca z opiekunem/promotorem rozpoczyna się od zgody promotora na opiekę nad pracą
• wspólnie z promotorem ustala się obszar merytoryczny i techniczny pracy. Bywa że promotor miewa jakąś “pulę” tematów, natomiast w przypadku zwłaszcza prac inżynierskich typu “program realizujący określone zadanie użytkowe” powodzeniu pracy lepiej wróży jeśli to student sam zaproponuje obszar merytoryczny. Pracę po prostu łatwiej i przyjemniej się przygotowuje kiedy się ma pozytywny stosunek emocjonalny do tego co się robi, a o to trudniej wtedy kiedy propozycja tematu wypływa od promotora
• przygotowanie propozycji studenta ma konkretną formę i cel. Celem jest wpisanie pracy do systemu zapisów gdzie znajduje się rejestr prac magisterskich i dyplomowych, a propozycje są zatwierdzane przez instytutową Komisję (zatwierdzanie odbywa się elektronicznie). Forma propozycji studenta obejmuje:
  • sformułowanie tematu pracy - powinno być kompromisem między byciem adekwatnym do zawartości pracy a byciem “zbyt” szczegółowym. Temat powinien zawierać imiesłów określający charakter pracy (implementacja, porównanie, …) oraz rozwinięcie.
    • dobry temat to np. “Implementacja aplikacji internetowej do zarządzania wydatkami”
    • niedobry temat to np. “Implementacja trzech formularzy internetowych w technologii PHP do zarządzania wydatkami” - temat jest zbyt szczegółowy i daje mało możliwości manewru w trakcie tygodni/miesięcy pracy nad nim
    • niedobry temat to np. “Implementacja aplikacji internetowej” - temat jest zbyt ogólny
  • opis pracy - opis umieszczany w systemie zapisów to dwa akapity, łącznie zajmujące ok. pół strony A4. Akapit pierwszy opisuje temat (tło merytoryczne). Akapit drugi odnosi się do realiów technicznych (technologii) jakie zostaną użyte.
• po zatwierdzeniu propozycji studenta przez promotora, praca zostaje zarejestrowana w systemie zapisów przez promotora i oczekuje na akceptację przez Komisję
• po akceptacji przez Komisję (zwykle trwa to do tygodnia) student będzie widział swoją propozycję w systemie zapisów i przechodzi się do faktycznego realizowania pracy
• w trakcie realizacji pracy, w początkowym etapie student raportuje postępy w interwałach 2-3 tygodniowych i zgłasza ewentualne wątpliwości. Możliwe są spotkania lub korespondencja mailowa. W początkowym okresie należy się skupić na części technicznej. Mniej więcej 4-8 tygodni przed terminem prezentacji/obrony należy zacząć przygotowywać część pisemną
• od samego początku dobrze jest utrzymywać całość (implementacja i część pisemna) w repozytorium typu GitHub, do którego wgląd ma promotor. Implementacja może być w repozytorium publicznym, część pisemna może być w repozytorium prywatnym
• rekomendowane jest przygotowanie dość wcześnie planu obsługiwanych funkcjonalności (przypadków użycia) i skonsultowanie jej z promotorem. Taki plan staje się mapą drogową dalszej pracy, można go korygować (zawężać, poszerzać) ale od samego początku wiadomo dzięki temu jaki jest kierunek i mniej więcej oczekiwany rezultat
• o tym czy finalny rezultat spełnia wymagania prawie nigdy nie wiadomo na początku. Studenci lubią pytać na samym początku “a czy tyle wystarczy”? Na co odpowiedź jest “a czy już dziś wiadomo że to wszystko się uda”? Może uda się zrobić mniej, może więcej, tego nie wiadomo na starcie pracy, a dopiero na końcu. Ciekawe pomysły mogą pojawić się dopiero w trakcie, z kolei pewne rzeczy mogą okazać się trudne i trzeba z nich rezygnować. Efekt końcowy jest równie ważnym elementem oceny jak i to jakie było zaangażowanie w trakcie całej pracy. Stąd tak ważne jest regularny kontakt z promotorem.

Wymagania ogólne do części pisemnej pracy

• praca magisterska - praca na zakończenie studiów II stopnia
• praca inżynierska/dyplomowa - praca na zakończenie studiów I stopnia
  • praca inżynierska zawiera elementy praktyczne
  • praca dyplomowa obejmuje raczej zagadnienia teoretyczne
• uwaga ogólna - czym więcej praca wymienia elementów “subiektywnych”, zwraca uwagę na to co się udało samemu zrobić, czym się odróżnia od innych, czego udało się nauczyć, tym lepiej dla pracy.
• praca powinna być złożona w systemie LateX który ma akceptowalną typografię. Składanie pracy w jakimkolwiek innym systemie (np. Word) obniża jej subiektywną wartość w kategorii “forma” - zbyt trudno jest nad tą formą w czymś innym niż LateX zapanować
• dobrym pomysłem jest użycie Overleaf który pozwala dodać promotora do kontrybutorów co bardzo ułatwia nanoszenie korekt technicznych
• praca powinna mieć obowiązkowo wstęp w którym jeśli to możliwe znajduje się, po opisaniu tego czego praca dotyczy, link do repozytorium kodu - jeśli repozytorium jest publiczne. Link do repozytorium należy powtórzyć w części pracy gdzie opisuje się część techniczną
• praca powinna mieć obowiązkowo plan pracy. Plan pracy jest częścią pierwszego rozdziału (wstęp) i jest akapitem lub osobnym podrozdziałem, który zbudowany jest następująco “W rozdziale drugim opisano ….”, “W rozdziale trzecim opisano …”, “W kolejnym, czwartym rozdziale opisano ….” …
• praca powinna mieć obowiązkowo część dotyczącą “porównania z innymi rozwiązaniami”. W zależności od ważności tego elementu, może to być część wstępu (mniejsza ważność) albo osobny rozdział (większa ważność). W tym porównaniu należy umieć wskazać co najmniej jeden, dwa przykłady aplikacji/rozwiązań/pomysłów, które dotyczą podobnego obszaru co ten opisany w pracy. Pominięcie tego elementu jest błędem formalnym. Również celowe pominięcie istnienia jakiegoś podobnego rozwiązania jest błędem - należy liczyć się z tym że recenzent wykaże minimum zainteresowania i znajdzie podobne rozwiązania - jeśli istnieją - a jeśli je znajdzie sam i w pracy nie będą one wzmiankowane, to recenzent potraktuje to jako mankament
• praca powinna mieć obowiązkowo rozdział “teoretyczny”, opisujący problem/zagadnienie od strony wymagań funkcjonalnych i niefunkcjonalnych - jaki jest kontekst tego co się robi
• praca powinna mieć obowiązkowo rozdział techniczny opisujący użyte technologie, model danych (może schemat bazy danych lub diagram modelu pojęciowego). Jeśli chodzi o prezentację architektury aplikacji to proszę się wzorować na modelu C4 w którym poziomy 2 i 3 (odpowiednio Container i Component) podpowiadają jak to można opisać (i zilustrować)
• praca powinna zawierać inne elementy wymienione w wymaganiach na stronie II. Wyjątkiem jest sytuacja w której dla prac licencjackich mówi się o instrukcji dla uzytkownika i spisie przypadków użycia - z tych dwóch elementów można wybrać tylko jeden (zwykle wybiera się instrukcję dla użytkownika z przykładowymi ekranami aplikacji)
• praca powinna mieć obowiązkowo rozdział ostatni “podsumowanie” w którym należy jeszcze raz powtórzyć co udało się zrobić, czego udało się nauczyć, czego się nie udało lub co się pominęło. Ten rozdział powinien mieć też obowiązkowo sekcję “future work” czyli “a gdyby tę pracę / tę aplikację” trzeba było kontynuować, to co jest do zrobienia, jakie kierunki badawcze / praktyczne ta praca otwiera
• w rozdziale technicznym powinny znaleźć się elementy:
  • komponenty techniczne użyte w implementacji
  • instrukcja kompilacji (w tym powtórzony link do repozytorium) oraz klarowne, zrozumiałe i łatwe polecenia uzyskania działającej wersji. Ideałem jest instrukcja typu “sklonować repozytorium i wykonać polecenie npm install a potem npm start” ale dopuszczalna jest oczywiście instrukcja typu
    • sklonować repozytorium
    • zlokalizować skrypt bazy danych (foo.sql), uruchomić ten skrypt na pustej bazie PostreSQL
    • ciąg połączenia do bazy danych wpisać do pliku appSettings.js (lub gdziekolwiek)
  • jeżeli kompilacja/uruchomienie aplikacji wymaga dodatkowych narzędzi (node.js, visual studio, android sdk, docker itd) to należy je traktować jako “czarne skrzynki” - nie wypisywać instrukcji instalacji tylko napisać “zainstalować X, Y, Z” i założyć że ktoś wie jak to zrobić
  • należy założyć że recenzent spróbuje skompilować aplikację, jeżeli mu się to nie uda, to zwróci uwagę że instrukcja kompilacji była niekompletna, niezrozumiała, nieaktualna itd.
  • część techniczna powinna obowiązkowo statystyki kodu, wykonane na przykład narzędziem cloc, z pominieciem oczywiście zewnętrznych bibliotek (tylko kod wchodzący w skład pracy)
• typowy rozmiar pracy to
  • 40-50 stron pracy inżynierskiej
  • 50-70 stron pracy magisterskiej

Aspekt “naukowy” pracy

• opracowanie autorskiego projektu “czegoś” (języka, specyfikacji), rozszerzenie istniejącej specyfikacji o jakiś istotny element
• opracowanie autorskiej implementacji “czegoś” (wzorca projektowego, narzędzia użytkowego) i porównanie go z jakimiś istniejącymi rozwiązaniami:
  • porównanie pod kątem listy funkcjonalności / zgodności ze standardem
    • jeżeli narzędzie implementuje jakiś standard to lista funkcjonalności aplikacji na tle listy wynikającej ze standardu
    • jeżeli narzędzie autorskie i narzędzie istniejące pokrywają się funkcjonalnie to po prostu zestawienie które (oczekiwane) właściwości są realizowane w jednym i drugim narzędziu
  • porównanie pod względem jakościowym
    • testy wydajnościowe - spreparowane przypadki testowe dla różnych rozmiarów “danych wejściowych” (cokolwiek to znaczy w kontekście rozwiązywanego zagadnienia) i pokazanie jak autorskie narzędzie wypada na tle istniejących
    • testy zużycia pamięci - jeżeli da się to mierzyć

Inne uwagi techniczne do pracy

• praca moze być napisana w języku polskim lub angielskim
• najbezpieczniej jest używać form bezosobowych, “zrobiono, zaproponowano” zamiast “zrobiłem/zrobiłam”. Jeżeli forma osobowa, to bezpieczniej mnoga “w pracy pokazujemy że…”.
• jeżeli rozdział zawiera tylko jeden podrozdział (na przykład rozdział 3 ma tylko 3.1) albo podrozdział ma tylko jeden podpodrozdział (na przykład 3.1 ma tylko 3.1.1) to jest to błąd struktury. Należy albo usunąć ten jeden podrozdział (i zostawić zero) albo dodać co najmniej dwa
• pracę należy obowiązkowo przepuścić przez spellchecker, błędy stylistyczne można przegapić, ale literówki - są niedopuszczalne
• ryciny, rysunki, diagramy w tekście - niedopuszczalna jest sytuacja w której diagram nie ma numeru i podpisu. Niedopuszczalna jest sytuacja w której numer pod diagramem nie występuje w tekście. Czyli nie wolno napisać “ilustacja znajduje się poniżej”. Należy napisać “ten element jest przedstawiony na diagramie 4.5”
• jeżeli rycina pochodzi z zewnątrz (np. z witryny internetowej) to niedopuszczalne jest jej po prostu wklejenie do pracy, trzeba wtedy napisac w podpisie że “źródło diagramu: {link}”. Najbezpieczniej jest takie ryciny przemalowywać samodzielnie, np. w Visual Paradigm lub innym narzędziu.
• ryciny oraz inne elementy pracy nie powinny być oznaczone kolorami, ilustracja która ma coś np. czerwonego i zielonego a potem opis który się do tego odnosi to błąd. Proszę pamiętać że po standardowym wydrukowaniu (odcienie szarości) czerwień i zieleń będzie wyglądała dokładnie tak samo. Dlatego wykresy, ryciny itd używają elementów graficznych do odróżnienia elementów - na przykład linie na wykresie nie “czerwona i zielona” ale “kropkowana i złożona z małych plusików”
• Kod źródłowy lub pseudokod w pracy - tylko czcionką o stałej szerokości i jeżeli z numerami linii, to zawsze osobne numerowanie w każdym snippecie (niedopuszczalna jest sytuacja że snippet pierwszy ma numery linii 1-22 a snippet kolejny numery linii 23-27, jeżeli to jest nowy, kolejny snippet to ma mieć swoje własne numery linii, od 1)
• Poprawna bibliografia zawiera kompletne referencje bibliograficzne: nazwiska autorów, tytuł, rok wydania, wydawnictwo. W przypadku linków obowiązkowa jest nazwa strony (jeśli to jest strona domowa to należy napisać “Strona domowa projektu”....), adres oraz obowiązkowo - adnotacja “data dostępu xx.yy.zzzz” żeby było wiadomo kiedy autor pracy odwiedził konkretną witrynę internetową

Przykładowa struktura (spis treści) pracy inżynierskiej

• Wprowadzenie
  • Przedstawienie problematyki
  • Plan pracy
• Opis i analiza zagadnienia
  • Historyjki użytkownika
  • Dodatkowe wymagania funkcjonalne
  • Wymagania niefunkcjonalne
• Porównanie z innymi implementacjami (może być również częścią wprowadzenia przed planem pracy)
• Implementacja
  • Spis użytych technologii i narzędzi (narzędzia pracy grupowej, github, narzędzia do przygotowania makiet itd.)
  • Model danych (+ diagramy)
  • Architektura (+ diagramy)
  • Opis rozwiazania wybranych problemów
• Instrukcja użytkownika (+ zrzuty ekranów)
• Część dla programisty
  • Instrukcja instalacji
  • Statystyki, testy jednostkowe
• Podsumowanie i dalszy rozwój
• Bibliografia

Wymagania techniczne do części implementacyjnej

• kod źródłowy powinien zawierać komentarze, przynajmniej na składowych (klasach/metodach) publicznych. Kod bez komentarzy obniża wartość pracy
• wszystkie stałe w kodzie powinny być jawnie deklarowane jako stałe (a nie użyte jako “magic numbers”)
• parametry konfiguracyjne (ciągi połączeń do baz danych, tokeny dostępu itd. itp.) powinny być najlepiej w jednym pliku, typu (przykładowo) appSettings.js, opisane jako “maski”, znaczy bez konkretnych wartości ale z komentarzem że tu trzeba wstawić konkretną wartość. Podawanie konkretnych wartości w repozytorium (na przykład prawdziwe hasło albo prawdziwy token dostępu) jest traktowane jako błąd
• kod musi mieć obowiązkowo jakiś zestaw testów jednostkowych - należy się wykazać umiejętnością ich przygotowania. W instrukcji dla programisty należy, oprócz opisanych wcześniej statystyk kodu, napisać ile jest testów jednostkowych i jak je uruchomić

APD

• Składając pracę w systemie APD należy się upewnić że uploaduje się dwa pliki, PDF z pracą i ZIP z kodem źródłowym jako załącznik. To powinien być ten sam kod który jest w repozytorium (jeśli jest repozytorium), oczywście sam kod (bez pakietów, zawartości node_modules itd. itp.)

Prezentacja/obrona

• praca magisterska ma obronę. Obrona pracy magisterskiej składa się z kilku części:
  • prezentacja samej pracy przez studenta
  • pytania/dyskusja na temat pracy. Pytania mogą mieć charakter dociekliwy i nie należy odbierać tego jako próby podważenia wartości pracy tylko jako próbę poszerzenia wiedzy członków komisji na temat tego jak szeroko temat pracy został zbadany, zarówno w obszarze tym który jest spisany w ramach pracy jak i tym który nie jest spisany
  • 3 pytania z wybranych przedmiotów - wybór możliwych przedmiotów jest opisany w programie studiów (cytat: Do ukończenia studiów konieczne jest złożenie pracy magisterskiej i zdanie egzaminu magisterskiego. Do pracy magisterskiej musi być załączone streszczenie w języku angielskim. W trakcie egzaminu student musi wykazać się znajomością tematyki pracy, ogólną wiedzą informatyczną i szczegółową znajomością trzech zaawansowanych dziedzin informatycznych (z zakresu przedmiotów: Języki formalne i złożoność obliczeniowa oraz przedmiotów z grupy I2), w tym dwóch spoza tematyki pracy. Wybór dziedzin zatwierdza przewodniczący komisji egzaminacyjnej
• praca inżynierska/dyplomowa nie ma obrony, ma prezentację
  • prezentacja samej pracy przez studenta
  • pytania/dyskusja - zwykle mniej dociekliwa niż w przypadku prac magisterskich, regułą jest raczej to że recenzent dzieli się uwagami bardziej krytycznymi (zwraca uwagę na rzeczy które można było poprawić) a promotor bardziej wspierającymi (stara się docenić to co zostało zrobione dobrze)
• prezentacja pracy w każdym przypadku (praca magisterska/inżynierska) trwa 15 do 20 minut. Prezentację należy sobie w głowie podzielić na trzy części
• dwie części (z trzech) prezentacji zajmuje opowieść o pracy. Do tego należy obowiązkowo mieć prezentację ze slajdami (tym razem nie ma wymagań na to jak jest przygotowana, może być Powerpoint, Canva, cokolwiek). Bardzo proszę o pilnowanie czasu. Typowe błędy tej części prezentacji
  • prelegent ma za dużo slajdów - optymalna liczba slajdów to 10, góra 15
  • prelegent zbyt dużo czasu spędza na pierwszych, nieciekawych slajdach - czasu jest naprawdę mało. Jeżeli widać że prezentacja ma 15 slajdów a po 8 minutach ktoś jest na 3 slajdzie, to już wiadomo że nie jest dobrze
  • dlatego należy obowiązkowo co najmniej jeden raz zrobić próbę - samemu do lustra, do kolegi, koleżanki, rodzeństwa, do gumowej kaczuszki, jabłka: zaprezentować to co się ma do pokazania i zmierzyć czas. Jeśli wychodzi więcej niż 15 minut, trzeba przeprojektować prezentację i ją skrócić lub nauczyć się opowiadać zwięźlej
  • prezentacja krótsza niż 10-12 minut też jest uznawana za błąd, oznacza że się nie ma wiele do powiedzenia
• ostatnia część (z trzech) prezentacji to pokaz na żywo - przejście przez główne/ciekawsze ścieżki aplikacji. Recenzenta nie zainteresuje jak się tworzy konta i rejestruje użytkowników ani czy hasło ma wymaganą określoną złożoność. Recenzenta zainteresują główne przypadki użycia, zrobienie wrażenia czymś unikalnym, a nie tym co na pewno w aplikacji musi być. Jeśli jest ryzyko że ta część się nie uda z powodów technicznych, można mieć awaryjnie film ze zrzutem pulpitu, gdzie się klika po aplikacji (nagrany wcześniej na przykład w OBS Studio) i tylko puścić ten film. Film - jeśli ma być, to raczej bez dźwięku, należy samemu na żywo dodać do niego narrację.
• jeśli prezentacja jest stacjonarna - należy mieć swój laptop do slajdów i pokazu
• jeśli prezentacja jest zdalna - należy być przygotowanym na udostępnienie pulpitu i pokazanie slajdów i pokaz aplikacji zdalnie

Uwagi inne

• recenzent jest osobą bardzo techniczną. Może nie znać konkretnej technologii, ale zna zasady projektowania i programowania. Należy unikać mówienia o rzeczach oczywistych, nie tłumaczyć czym jest React czy PHP, bo to wiadomo
• recenzent ma obycie, wie jakie rzeczy są trudne a jakie łatwe, próba budowania fałszywego wrażenia że coś było trudne w sytuacji gdy tak nie jest, jest skazana na niepowodzenie
• recenzent potrafi korzystać z wyszukiwarki i zadawać jej dobre pytania. Próba powtórzenia czyjejś pracy, sklonowania czyjegoś repozytorium jest oczywiście niedopuszczalna i oznacza bezwarunkową dyskwalifikację pracy
• proszę pamiętać że pracę ocenia głównie recenzent i to jego wrażenie jest ważne. Promotor jest tylko doradcą, podpowie czy jaki jest jego zdaniem wkład pracy studenta. Ale z propozycją oceny zwyczajowo wychodzi recenzent.
• Praca poprawna, niezawierająca błędów, kompletna, jest zasadniczo wyjściowo oceniana na ocenę dobrą. Ocenę bardzo dobrą dostaje praca, która zdaniem recenzenta wyróżnia się w jakimś aspekcie, należy więc potraktować ewentualną ocenę bardzo dobrą jako wyróżnienie. Ocena dobra oznacza dokładnie tyle ze to jest “dobra” praca, że takie prace chcemy i z przyjemnością czytamy i recenzujemy. Słabsza ocena niż dobra oznacza że były jakieś istotne mankamenty, na przykład zignorowanie którejś z powyższych wskazówek.