Zasady pisania pracy dyplomowej

Promotor: dr inż. Marcin Tomana

Założenia dotyczące spisu treści oraz zawartości dodatkowo wg wytycznych dostępnych dla dyplomantów w WSIZ.

Komunikacja ze mną

email: imie@nazwisko.pl  <- nie przepisywać wprost!

Przesyłać proszę do mnie tylko wersje DOC (nie docx) oraz najlepiej PDF. Najpierw uzgadniamy spis treści, następnie kolejne rozdziały przesyłacie do wstępnej akceptacji (nie czytam szczegółowo jeszcze) i na końcu jak jest całość to czytam szczegółowo i w formie komentarzy nanoszę poprawki. Potrzebuję na to zazwyczaj tygodnia. Proszę przeczytać co się napisało przed wysyłką do mnie :-)

Idealny plan to taki, że na sem.6 powstaje pierwszy rozdział przeglądowy oraz powstaje program w wersji prawie gotowej. Na sem.7 kończona jest dokumentacja oraz wnoszone są ostateczne poprawki do programu.

Spis treści

Wprowadzenie

Wielkość ok. 3 str.

Geneza pracy – kilka akapitów wprowadzających, z czego powinno wynikać, że zrobienie takiego systemu jest potrzebne i ma sens.

Cel pracy – koniecznie sformułowania „Celem ogólnym pracy jest…”, „Celami szczegółowymi pracy są…”

Teza pracy – twierdzenie z zielonej karty

Struktura pracy – opis co w poszczególnych rozdziałach się znajduję.

1. Wprowadzenie do tematyki lub Przegląd rozwiązań lub Sformułowanie problemu

Wielkość ok. 12 str.

Sformułowanie problemu (1-2 str)

Przegląd istniejących rozwiązań (5 str)

Prace dyplomowe z uczelni (1 str)

Przegląd możliwych rozwiązań technicznych (3 str)

2. Projekt systemu …

Wielkość ok. 12 str.

Rozdział pisany jest w formie niedokonanej, czyli „… będzie…, … powinno być …, należy zrobić…”.

Ogólny opis założeń systemu oraz wytyczne dla programisty. Najlepiej schematy z dokładnym opisem. Tutaj również schemat bazy danych. Można w tym rozdziale ewentualnie dodać kilka stron opisu specyficznych narzędzi lub bibliotek, z których ma korzystać programista.

3. Implementacja systemu…

Wielkość ok. 12 str.

Opis obsługi samego programu w formie instrukcji obsługi lub spis wszystkich modułów i opcji. Opis szczególnych rozwiązań technicznych wraz z komentowanymi fragmentami kodu źródłowego.

4. Testowanie systemu …

Wielkość ok. 10 str.

Opis metodologii testowania, ogólne informacje jak był testowany system, ile danych wprowadzono oraz jakie w tym procesie znaleziono błędy i jakie wynikły z tego zmiany systemu. W przypadku systemów mobilnych dobrze byłoby pokazać, że system był testowany na różnych urządzeniach.

Zakończenie

Wielkość ok. 2 str.

Wnioski końcowe – ustosunkować się do celów i tezy – wykazać, że cel został osiągnięty i teza jest prawdziwa.

Zmiany na przyszłość – co można by jeszcze w systemie zrobić w przyszłości.

Ogólne informacje

Nie używa się w pracach liczby pierwszej. Wszystko co osiągnąłeś pisze się bezosobowo, czyli np. „Wykonano aplikację” zamiast „Wykonałem aplikację”.

Nie bać się cytowania – nie ma sensu własnymi słowami opisywać co to jest PHP. Pamiętać, że cytat czcionką pochyłą i zawsze przypis na dole strony skąd jest wzięty.

Rozdziały powinny zaczynać się i kończyć normalnym tekstem. Nie kończy się rozdziałów rysunkiem lub tabelą.

Wszelkie wyliczanki muszą być oddzielane znakiem interpunkcyjnym przecinka, średnika lub kropki. Jeżeli są krótkie to po dwukropku z małej litery ale za każdą przecinek i za ostatnią kropka. Jeżeli są długie to za każdym punktem średnik a za ostatnim kropka. Jeżeli wyliczanki wielozdaniowe, to z dużej litery i za każdym punktem kropka.

Rysunki i schematy

Podpis pod rysunkiem powinien jednoznacznie i kompletnie opisywać co na nim jest, czyli zamiast „Screen aplikacji” powinno być „Widok modułu składania zapytań ofertowych dla klienta indywidualnego”.

Pamiętać, że schemat blokowy to odzwierciedlenie algorytmu, czyli musi być start i koniec i jednoznaczna ścieżka. Przy blokach warunkowych 2 wyjścia z opisem „tak”, „nie”. I wszędzie strzałki najlepiej nie krzyżujące się (ewentualnie z tzw. mostkiem).

Pod rysunkami własnymi dodawać w podpisie „[opracowanie własne]”. Pod rysunkami obcymi zawsze musi być przypis i informacja skąd jest wzięty. Nie można oczywiście zamieszczać zdjęć, do których nie ma się praw. Screeny aplikacji mogą być zamieszczane ale trzeba to jednoznacznie zaznaczyć skąd to pobrane – najlepiej adres witryny + informacja, że to materiały reklamowe. Pod widokami witryn dodawać url i sformułowanie „stan na dzień xx.xx.xxxx”.

Screeny swojej aplikacji wstawiać z wypełnionymi w miarę realnymi danymi. Nie może być pustych list, pustych pól w dialogach.

Do wszystkich rysunków przydałoby się odwołanie w tekście w formie np. : „…, co widoczne jest na rys. nr …”.

Sformułowania

Nie używa się w pracach sformułowań potocznych, np. „lekki framework”, „screen”, „walidowane”.

Tytuł rozdziału powinien być równoważnikiem zdania a nie nazwą, czyli zamiast „Język PHP” powinno być „Zastosowanie języka PHP w systemie”.

Nazwy obce nie powinny być używane samodzielnie, czyli zamiast „przy pomocy bluetooth” powinno być „przy pomocy protokołu bluetooth”, zamiast „z użyciem jQuery” powinno być „z użyciem biblioteki jQuery”, zamiast „zgodny z JSR-82”, powinno być „zgodny ze standardem JSR-82”.

Przebieg obrony i prezentacja

Na referowanie jest zwykle 10-15 minut. Trzeba sobie to poćwiczyć. Nie ma co zagłębiać się w szczegóły (poza przypadkami, że ktoś pyta o nie). Trzeba zrobić to w formie podsumowania i przedstawienia wyników pracy.

Rzadko jest czas, żeby zaprezentować cały program. Należy pokazać, że on jest i nie trzeba wprowadzać żadnych danych. Najlepiej jak dane przykładowe są w programie wprowadzone. Nie pokazywać na danych typu „abcdefg” albo „xyz”, tylko na w miarę realnych danych.

W prezentacji nie wstawiać długich tekstów małą czcionką, tylko krótkie hasła, które są pomocne przy referowaniu.

Prezentacja powinna być wykonana wg schematu:

1 slajd tytułowy z logiem szkoły

1 slajd z genezą, celami i tezą (krótkie hasła tylko)

1 slajd wniosków z analizy rozwiązań (krótkie hasła, podsumowanie, statystyka)

2-3 slajdy z projektu (założenia, schemat ogólny aplikacji, kluczowe schematy blokowe)

2-3 slajdy z implementacji – kluczowe dokonania, zrzuty ekranu z programu (tutaj przy referowaniu można się przełączyć na aplikacje i pokazać to na żywo)

1 slajd podsumowania i wniosków

Wpisz komentarz

You must be logged in to post a comment.