Pracownia dyplomowa inżynierska

Z promotorem należy kontaktować się w regularnych odstępach czasowych (najlepiej co miesięcznych). Przed wysłaniem pracy/poprawek należy całość jeszcze raz przeczytać pod kątem błędów ortograficznych, gramatycznych, językowych czy interpunkcyjnych.

Struktura pracy inżynierskiej

Praca ma mieć następujący układ:

  1. Wstęp
  2. Charakterystyka/analiza problemu
  3. Analiza istniejących rozwiązań
  4. Projekt ogólny systemu <NAZWA>
  5. Dokumentacja użytkowa systemu <NAZWA>
  6. Dokumentacja techniczna systemu <NAZWA>
  7. Testy i weryfikacja systemu
  8. Zakończenie
  9. Bibliografia
  10. Spis rysunków
  11. Spis tabel

Spis rysunków i tabel jest opcjonalny.

Wstęp

Wstęp ma wykazać, że autor potrafi konkretnie przedstawić swoje motywacjecele oraz plan działania. Podzielony jest na akapity. Wyróżnia się trzy logiczne części:

  • Charakterystyka rozwiązywanego w pracy problemu, można przedstawić motywację jego podjęcia, tutaj należy  jasno i jednoznacznie określić czego dotyczy (potencjalnie enigmatyczny) temat pracy. Ten fragment to motywacja pracy.
  • Jasno określony cel/e (zgodny z kartą opisu tematu pracy), akapit rozpoczynający się od: „Celem pracy jest zaprojektowanie i realizacja systemu … pozwalającego na/przeznaczonego dla/umożliwiającego/dedykowanego dla …” po czym następuje krótkie wyszczególnienie przewidywanych funkcji projektowanego systemu oraz wymienienie przewidywanych metod i narzędzi realizacji (krotko: aplikacja desktop, internetowa, mobilna, języki, biblioteki) — najczęściej ok. 1/2 strony. Ten fragment to cel pracy.Uwaga – celem pracy nie może być „opisanie”, „przedstawienie”, „przybliżenie” i tym podobne ogólniki. Celem pracy inżynierskiej może być „zaprojektowanie …”, „zaprojektowanie i implementacja …”, „projekt i realizacja …”, „opracowanie algorytmu i analiza jego efektywności …”, itd.
  • Streszczenie zawartości kolejnych rozdziałów: „Rozdział drugi przedstawia…, w rozdziale trzecim opisano…” —najczęściej ok. 1/2 strony. Ten fragment to zakres pracy.

Jeżeli charakterystyka/motywacja jest długa to można wydzielić podrozdział pt. „Cel i zakres pracy”. typowa, sumaryczna objętość całego rozdziału wstępu to 1-2 strony.

Charakterystyka/analiza problemu

Ten rozdział ma wykazać, że autor posiada umiejętności analityczne — że potrafi zrozumieć problem, potrafi przeprowadzić jego systematyczną analizę, potrafi dostrzec jego potencjalne zawiłości, warianty rozwiązania. Rozdział koncentruje się na problemie nie na metodach jego rozwiązania.

Rozdział zawiera rozwinięcie charakterystyki i motywacji problemu krótko zaznaczonej we wstępie pracy. Przedstawiana jest szczegółowa dyskusja problemu inżynierskiego rozważanego w pracy, ze szczególnym uzasadnieniem tego, że rzeczywiście ten problem jest warty pracy inżynierskiej. Jeżeli system ma np. wspomagać pracę pewnej firmy, należy jasno i szczegółowo opisać jak przebiegają procesy biznesowe w firmie, co jest w nich charakterystycznego, jakie są warianty, sytuacje nietypowe, jakie występują problemy, w jaki sposób proponowane rozwiązanie informatyczne może te problemy rozwiązać.

Zwykle jest to opis ze strony dziedziny problemu, z punktu widzenia potencjalnego użytkownika/klienta biznesowego. Staramy się w tym rozdziale nie opisywać konkretnej technologii i narzędzi realizacji, ograniczając się do określenia klasy proponowanego rozwiązania (np. aplikacja WWW, aplikacja desktop, aplikacja mobilna). Rozdział może/powinien zawierać rysunki, schematy ideowe i poglądowe. Jeżeli, przykładowo, system mam wyeliminować obieg dokumentów papierowych w pewnej organizacji, warto dokładnie opisać jak taki obieg wygląda (diagram), warto przedstawić jakie uczestniczą w nim dokumenty (skany).

W tym rozdziale można opisać problem szeroko i wielowariantowo, wykraczając poza ramy proponowanego rozwiązania.

Typowa, sumaryczna objętość — 5-10 stron. Uwaga, ten rozdział nie może być krótki! Jeżeli opis problemu jest krótki, to najprawdopodobniej oznacza, że problem jest trywialny i nie nadaje się na pracę inżynierską. W skrajnym przypadku recenzent może zanegować sensowność pracy ze względu na jej trywialność.

Analiza istniejących rozwiązań

Ten rozdział ma wykazać, że autor potrafi dokonać krytycznej analizy istniejących rozwiązań, dostrzec ich wady i zalety oraz sformułować użyteczne wnioski.

Praca inżynierska rzadko ma charakter tak odkrywczy, że nikt jeszcze wcześniej nie próbował rozwiązań problemu rozważanego w pracy. Na początku tego rozdziału należy jasno przedstawić co i dlaczego będzie analizowane w tym rozdziale (systemy, pakiety, metody, algorytmy). Skąd wzięte zostaną informację do tej analizy, jak ona będzie realizowana. Należy jasno określić, czego spodziewamy się z tej analizy dowiedzieć, co z niej ma wynikać.

Dalej następuje prezentacja istniejących rozwiązań zbliżonych do proponowanego w pracy. Zwykle 3-5 rozwiązań. Spójny opis wg tych samych kryteriów porównawczych, zakończony podsumowaniem wad i zalet. Ten rozdział ma pozwolić na świadomy wybór własnej koncepcji, wykorzystującej najlepsze cechy rozwiązań istniejących, unikającej cech wskazanych jako wady.

Wskazówki

Zwykle dla każdego opisywanego rozwiązania tworzymy osobny podrozdział. Proszę nie tytułować tych podrozdziałów jedynie nazwą rozwiązania. Załóżmy, że analizujemy istniejące systemy informatyczne zbliżone do proponowanego w pracy, załóżmy że istnieje system o nazwie X47Alpha, niech tytuł podrozdziału to „System X47Alpha”, „Serwis X47Alpha”, „Aplikacja X47Alpha” w zależności od jego specyfiki. Każde analizowane rozwiązanie powinno być opisane w ten sam sposób. Dobrze przeprowadzona analiza powinna rozpoczynać się od wskazania jakie cechy rozważanych rozwiązań będą analizowane (np. producent, cena, rodzaj licencji, typ, właściwości funkcjonalne, wydajność, bezpieczeństwo, skalowalność) i dlaczego. Analiza powinna się kończyć podsumowaniem, jasno wskazującym wady oraz zalety każdego z rozwiązań, pamiętamy o tym, że analizujemy po to, by we własnym rozwiązaniu uniknąć wad a wzorować się na zaletach. Jeżeli bazujemy na materiałach producenta (strony WWW, dokumentacje) wstawiamy wciągamy je do bibliografii i wstawiamy w tekście odnośniki do nich. Jeżeli wstawiamy rysunki pochodzące z tych źródeł, w podpisach rysunków wstawiamy odnośniki do nich.

3 Analiza istniejących rozwiązań
W rozdziale tym przedstawione zostaną...
3.1 Kryteria analizy porównawczej
Analiza obejmować będzie następujące cechy...
3.2 {Rozwiązanie|System|Aplikacja|Algorytm|Serwis|Strona} X
...
3.3 {Rozwiązanie|System|Aplikacja|Algorytm|Serwis|Strona} Y
...
...
3.N Podsumowanie
...

Typowa, sumaryczna objętość to 8-15 stron.

Projekt ogólny

Ten rozdział ma wykazać, że autor potrafi w sposób systematyczny opracować ogólną koncepcje organizacji systemu. Określamy jakiego rodzaju będzie system (system klasy desktop, mobilny, internetowy). W zależności od danego rodzaju systemu określamy czy będzie podzielony na podsystemy, elementy, warstwy, moduły, określamy gdzie będą one ulokowane i jak będą ze sobą współpracować. Przykład: „System będzie trójwarstwową aplikacją internetową. Warstwa kliencka działać będzie w środowisku przeglądarki, będzie ona się komunikować z warstwą usług serwerowych za pośrednictwem API REST. API będzie korzystało z bazy danych umieszczonej na osobnym, dedykowanym serwerze”.  Najważniejsza część tego rozdziału to specyfikacja wymagań funkcjonalnych i niefunkcjonalnych. Specyfikacja wymagań jest fragmentem SRS — Software Requirements Specification. Szczegółowe informacje na temat dokumentu SRS dostępne są tutaj (opracowanie dr R. Simiński). Specyfikacja wymagań funkcjonalnych zawiera opis funkcji udostępnianych przez system. Np. Otwarcie istniejącego raportuUtworzenie nowego raportuEdycja ustawień, itp. Poszczególne wymagania mogą być prezentowane w postaci listy numerowanej lub bardziej szczegółowo w postaci tabeli. Wymagania niefunkcjonalne dotyczą aspektów systemu nie przekładających się bezpośrednio na akcje wykonywane przez system, dotyczą takich aspektów jak architektura, bezpieczeństwo, wydajność, ergonomia interfejsu użytkownika, kolorystyka. Wystarczy prezentacja wymagań niefunkcjonalnych w postaci listy numerowanej. Dobrze jest jednak odnieść się w jaki sposób będą one realizowane (np. wysoki poziom bezpieczeństwa przez zastosowanie szyfrowanego protokołu HTTPS itp.).

Standardowa długość rozdziału – ok. 2 strony.

Dokumentacja użytkowa

Ten rozdział stanowi pomoc dla użytkownika w zakresie jak stworzony system działa, jak go zainstalować. W ramach tego rozdziału należy określić minimalne wymagania sprzętowe i programowe, niezbędne do działania stworzonego rozwiązania. Istotnym podrozdziałem jest też proces instalacji, który wspomaga użytkownika/recenzenta pracy w zadaniu zainstalowania i uruchomienia rozwiązania. Dobrze odnieść się do nazw katalogów stworzonych na nośniku (zazwyczaj płyta CD/DVD), gdzie znajduje się wersja instalacyjna wszystkich wymaganych do działania systemu składników. Zalecane jest stworzenie gotowego instalatora, jednakże nie jest to obowiązkowe. Podrozdział  ten nie powinien być zbyt rozwlekły. Najważniejszy podrozdział dotyczy opisu wszystkich funkcji stworzonego systemu – autor pracy dokumentuje poszczególne wszystkie funkcje systemu wraz z zrzutami ekranu. Często ten podrozdział stanowi dla recenzenta punkt wyjścia do oceny stworzonego oprogramowania.
Często dodawany jest również podrozdział zatytułowany „Przykładowy scenariusz użytkowania”. W przeciwieństwie do poprzedniego prezentuje on przykładową interakcję konkretnego użytkownika ze stworzonym oprogramowaniem – najpierw użytkownik otwiera plik xml, prezentowane mu są konkretne wyniki, dokonuje analiz na wykresie i drukuje raport. Zatem prezentowane są tutaj wyłącznie przykładowe (często najważniejsze) funkcje oprogramowania w typowym wykorzystaniu (a nie wszystkie szczegółowe jak to ma miejsce podrozdział wcześniej).
Wielkość rozdziału zależy od stopnia skomplikowania danego rozwiązania i najczęściej liczy 10 – 20 stron.

Dokumentacja techniczna

Struktura tego rozdziału mocno zależy od architektury danego rozwiązania, zastosowanych metod i narzędzi realizacji. Należy rozpocząć od schematu rzeczywistej struktury systemu, prezentującego poszczególne składowe: pakiety, moduły, biblioteki, klasy. Każda składowa powinna zostać omówiona, opis powinien zawierać nazwę składowej, jej rolę w projekcie, przeznaczenie, strukturę wewnętrzną.

Ten rozdział to dobre miejsce na umieszczenie różnorodnych diagramów projektowych, takich jak diagram przypadków użycia, hierarchii klas, związków encji, diagramy sekwencji, kolaboracji, itp., itd.. Tutaj można przedstawić opisy metod i/lub stosowane algorytmy. Każdy diagram powinien być omówiony w treści pracy. Często prezentowany jest też opis wykorzystywanych bibliotek i technologii. Proszę pamiętać, że opis dotyczący wykorzystywanego środowiska, języka programowania czy innych elementów powszechnie znanych należy skrócić do absolutnego minimum (co najwyżej po 1 akapicie dla danego elementu) bądź w ogóle z niego zrezygnować.

Przy opisie składowych systemu warto przedstawić fragmenty wybranych kodów źródłowych, prezentujące szczególnie istotneciekawe czy nietypowe rozwiązania oraz algorytmy. Nie należy przedstawiać fragmentów kodu operacji typowych lub trywialnych. Proszę nie zamieszczać długich, ciągnących się przez wiele stron listingów kodu. Opis kodu zapisujemy w sekwencji: kilka linijek a potem fragment opisujący istotne operacje realizowane w kodzie, kilka linijek a potem fragment opisujący istotne operacje realizowane w kodzie… itd.

Fragmenty kodu proszę zamieszczać jako odpowiednio sformatowane teksty, zwykle pisane nieproporcjonalnym krojem pisma. Proszę zadbać o to, by zamieszczane kody były poprawne z punktu widzenia inżynierii programowania, poprawne merytorycznie oraz właściwie sformatowane. Proszę nie umieszczać w tekście fragmentów kodu w postaci rysunków zawierających zrzuty ekranów.

Proszę pamiętać, że praca inżynierska ma być wymiernym dowodem wysokich kompetencji jej autora w zakresie informatyki, niechlujny kod takich kompetencji nie potwierdza.

Testy i weryfikacja systemu

Ten rozdział ma wykazać, że autor pracy zna i rozumie znaczenie zapewnienia jakości w procesie realizacji oprogramowania oraz potrafi zaplanować i przeprowadzić proces testowania systemu.

Realizowany system musi być testowany. W zależności od tego jakie testy przewidziano w rozdziale tym powinno się opisać jak takie testy zaplanowano i przygotowano, jak je realizowano oraz jakie uzyskano rezultaty. Zwykle realizuje się testy: jednostkowe, integracyjne, akceptacyjne oraz aktualnie zwykle testy responsywności. Jeżeli aplikacja była testowana bardzo solidnie (np. była realizowana z wykorzystaniem metodyki TDD) nie trzeba zamieszczać opisu wszystkich testów, proszę przytoczyć wybrane testy, szczególnie te w wyniku których wykryto błędy. Warto napisać, że wykryte błędy zostały usunięte, można również wskazać co było przyczyną błędu i w jaki sposób błąd usunięto. Typowa forma opisu: tekst + tabelki opisujące przypadki testowe oraz ew. wybrane fragmenty kodu: powodujący błąd i skorygowany. Uwaga: to nie ma być drobiazgowy raport dla działu QA, w tym rozdziale należy wykazać się umiejętnością testowania poprzez przedstawienie wybranych testów systemu, najlepiej testów różnego typu. Typowa, sumaryczna objętość rozdziału to 2-5 stron.

Zakończenie

Zakończenie ma wykazać, że autor potrafi konkretnie podsumować wyniki swojej pracy, wykazać, że zrealizował cel pracy określony we wstępie, wskazać wady i zalety zaproponowanego rozwiązania oraz możliwości jego rozwoju.

Rozpoczynamy od przypomnienia celu pracy (zgodnego z celem określonym we wstępie!): „Celem pracy było …”. Używany czasu przeszłego, dokonanego. Opisujemy krótko właściwości funkcjonalne zaproponowanego rozwiązania (np. jakie system oferuje funkcje, co umożliwia) — 1/3 do 1/2 strony. Również krótko przypominamy zastosowane technologie, narzędzia, biblioteki — 1/3 do 1/2 strony. Potem opisujemy spostrzeżenia związane z realizacją pracy, co było ciekawe, co zaskakujące (negatywnie i pozytywnie), napotkane trudności, opisujemy jak zaproponowane rozwiązanie sprawdza się w praktyce, a może jest wdrożone, i można pochwalić się opiniami użytkowników? A może będzie wdrożone — warto o tym napisać. Należy się pochwalić (bez zbytniego marketingu) tym co dobrze wyszło, tym co ciekawe, efektywne, funkcjonalne. Nie ukrywamy ewidentnych wad, wskazujemy je i sugerujemy jak je planujemy poprawić. Opisujemy możliwe kierunki rozwoju, zarówno w sensie funkcjonalnym jak i technologicznym. Całość 1-2 stron, preferowane 1 i 1/2. Zakończenia nie dzielimy na podpunkty.

Wstęp i Zakończenie mają być komplementarneZakończenie ma jasno i konkretnie wskazywać, że obietnice i plany sformułowane we Wstępie zostały zrealizowane. Uwaga — Wstęp i Zakończenie będą na pewno uważnie przeczytane przez recenzenta, mają być zatem dopieszczone i wycyzelowane zarówno pod względem treści jak i formy, tutaj jakiekolwiek usterki językowe są niedopuszczalne. Typowa, sumaryczna objętość to 1-2 strony.

Zasady redagowania pracy

Przedstawione niżej zasady są odpowiedzią na ciągle powtarzające się błędy występujące w pracach.

Forma wypowiedzi, styl narracji

Opracowania naukowe i teksty techniczne piszę się zwykle z formie bezosobowej, pozbawionej emocjonalności, wolnej od kolokwializmów i żargonu informatycznego.

Przykład: W proponowanym projekcie wykorzystany zostanie język C# oraz biblioteka WPF. Dane zapisywane będą w plikach XML z wykorzystaniem bibliotek dostępnej w środowisku Visual Studio.

Język, żargon, kolowializmy

Praca inżynierska ma być konkretem dowodzącym wysokich kompetencji autora w zakresie rozwiązywania nietrywialnych problemów z zakresu informatyki. Na podstawie oddanej pracy, po pozytywnie zakończonej obronie, autor otrzymuje tytuł inżyniera potwierdzający wyższe wykształcenie. Aspirowanie do posiadania wykształcenia wyższego zobowiązuje, w pracy należy posługiwać się poprawnym językiem polskim, przestrzegać ogólnie przyjętych zasad ortografii, gramatyki i interpunkcji. W pracy nie należy używać kolokwializmów, żargonu informatycznego, zwracać się do czytelnika per „ty”, stosować wypowiedzi nadmiernie egzaltowanych oraz unikać wszelkiego bełkotu, a szczególnie marketingowego. Zatem w pracy nie piszemy, że coś „nie pykło”, nie stosujemy „frameworków” (a tym bardziej „frejmłorków”), „ticketów”, „commitów”, nie szukamy „bugów”. Dla większości nieakceptowalnych akademicko sformułowań obcych (akceptowalny jest np. interfejs) poszukujemy polskojęzycznych odpowiedników. Zatem stosujemy „pakiety szablonowe”, przyjmujemy „zgłoszenia”, „zatwierdzamy” zmiany, szukamy „błędów”. Nie wymyślamy nieistniejących w języku polskim słów, takich „funkcjonalności” (są funkcje), nawet jeżeli pojawiają się one na dziesiątkach stron internetowych.

Czytelnikami pracy dyplomowej są członkowie społeczności akademickiej — zarówno wykładowcy jak i inni studenci. Najważniejszym czytelnikiem jest Recenzent. Od jego oceny zależy w dużej mierze wynik obrony. Proszę zatem nie pisać w pracy „zaraz pokażę ci”, „zobaczysz w następnym rozdziale”. Wszelki bełkot marketingowy jest surowo zakazany, czyli niedopuszczalne są sformułowania takie jak „…zastosuję potężną bibliotekę X…”, „…zastosowanie pakietu Y sprawia iż problemy rozwiązują się same…”, „…niekończąca się elastyczność oraz porażająca skuteczność języka Z…”.

Podział na podrozdziały

Każdy rozdział i podrozdział powinien posiadać swój numer, wchodzący automatycznie do spisu treści pracy. Spis treści umieszcza się na początku pracy, przed wstępem. Zwykle wstęp i zakończenie pracy nie są numerowane, ale ze względu na mechanizmy automatyzacji w procesorach tekstu, numery przy wstępie i zakończeniu są dozwolone.

Akapity w języku polskim rozróżnia się poprzez zastosowanie wcięć – nie należy stosować linii odstępu między akapitami tak jak jest to realizowane w języku angielskim. Ponadto należy bardzo unikać akapitów jednozdaniowych.

Każdy główny rozdział pracy rozpoczyna się na nowej stronie. Nie dotyczy to jednak podrozdziałów.

Każdy rozdział pierwszego poziomu musi się rozpoczynać krótkim wprowadzeniem opisującym co rozdział zawiera, dlaczego powstał, w jaki sposób jest powiązany z tematem pracy. Dopiero potem można rozpocząć pierwszy podrozdział.

Przykład

Rozdział ten zawiera charakterystykę wybranych serwerów baz danych, których wydajność będzie analizowana w części badawczej pracy. Omówione zostaną serwery Z, Y, Z, przedstawione zostaną informacje o producencie, sposobie licencjonowania, wymaganiach instalacyjnych, dostępnych mechanizmach definiowania schematów bazy, tabel oraz metodach tworzenia i optymalizacji zapytań. Rozdział zakończy porównanie wybranych właściwości funkcjonalnych w postaci zestawienia tabelarycznego.

Rozdział pierwszego poziomu jest podstawową jednostką organizacji tekstu. Nie może być on nadmiernie krótki, ani przesadnie długi. Zakładając, że docelowa objętość pracy to np. 60, oraz że dzielimy ją na 4 rozdziały (nie licząc wstępu i zakończenia), zrównoważona struktura pracy powinna skutkować rozdziałami o objętości 10-20 stron. Duże dysproporcje w objętości rozdziałów są zwykle rezultatem niewłaściwego przemyślenia struktury pracy. A to może powodować obniżenie jej oceny.

Nie należy przesadzać z głębokością zagnieżdżenia podrozdziałów. Zwykle numerujemy podrozdziały aż do trzeciego poziomu zagnieżdżenia.

Bibliografia i jej znaczenie

Każda praca musi posiadać bibliografię, zawierającą uporządkowany (np. alfabetycznie, narastająco wg. nazwisk autorów) spis materiałów źródłowych wykorzystanych w pracy. Bibliografia umieszczana jest na końcu pracy. Spotyka się różny sposób podziału materiałów źródłowych. W najprostszej postaci jest to jednolita lista uporządkowana alfabetycznie według nazwisk autorów lub kolejności pojawiania się odsyłaczy w tekście.

Rozbudowana bibliografia zawierająca wartościowe źródła informacji świadczy to tym, że autor pracy jest solidnie się przygotował do jej napisania.

Proszę nie lekceważyć bibliografii! Recenzent na pewno sprawdzi czy ona jest, ile liczy pozycji, jakiego rodzaju materiały się na niej znajdują. Materiały źródłowe oraz sposób ich wykorzystania są oceniane w recenzji pracy. To, w jaki sposób jest ona sformatowana, nie jest również bez znaczenia.

Każda pozycja umieszczona w bibliografii musi być przynajmniej raz zacytowana. W pracy nie należy cytować materiałów, które nie są umieszczone w bibliografii. Zalecenia odnośnie bibliografii:

  1. Nie mniej niż 10 pozycji (praca inżynierska), 20 pozycji (praca magisterska).
  2. W bibliografii powinny to być głównie solidne książki, również ebooki i inne dokumenty dostępne elektronicznie. Proszę zrezygnować z Wikipedii jako źródła.
  3. Dokumenty dokumenty elektroniczne dostępne online via Internet powinny mieć normalny opis bibliograficzny a nie tylko wpis zawierający ich URL. Ponadto muszą być one opatrzone datą dostępu.
  4. Można umieszczać w bibliografii wpisy na stronach internetowych, blogach, z zachowaniem powyższej uwagi.
  5. Można korzystać z mechanizmów automatyzacji dostępnych w popularnych procesorach tekstu.

Korzystanie z bibliografii — cytowania

Każdy fragment tekstu pochodzący z materiałów źródłowych musi zostać opatrzony stosownym odsyłaczem, tzw. „cytowaniem” (uwaga — nie chodzi tutaj o wstawienie tekstu w cudzysłowach). Cytowanie polega na wskazaniu źródła informacji poprzez wskazanie jego pozycji w bibliografii. Częste cytowanie różnorodnych źródeł dowodzi oczytania i elokwencji autora.

Spotyka się dwa rodzaje cytowań. Pierwszy to umieszczenie pod koniec cytowanego fragmentu numeru cytowanej pozycji na liście w bibliografii, np.: „… zgodnie z definicją przedstawioną w [1] …”. Drugi rodzaj to wykorzystywanie przypisów dolnych. Proszę nie stosować odnośników w postaci przypisów dolnych.

Zwracam uwagę, że umieszczanie w pracy przepisanych (bądź skopiowanych) dosłownie fragmentów nie jest dozwolone. Jest to plagiat (a praca sprawdzana jest systemem anty-plagiatowym przed ewentualnym dopuszczeniem do obrony). Również nie jest dozwolone umieszczanie fragmentów tekstu opartych na materiałach źródłowych bez ich zacytowania. W przypadku rozdziałów pracy, mających charakter przeglądu literaturowego, naturalnym jest korzystanie z materiałów źródłowych. Nikt od studenta nie wymaga np. wymyślenia genezy Internetu, usług internetowych czy podstawowych pojęć z zakresu e‑marketingu. Jednak dokonując takiego przeglądu należy pisać „własnymi słowami”, cytując wykorzystywane prace, nawet, jeżeli jest ich wiele. Uwaga — cytowanie nie uprawomocnia przepisywania! Przepisanie z materiałów źródłowych całej strony i opatrzenie cytowaniem, nie zmienia faktu, iż autor umieścił w pracy fragment, którego autorem jest ktoś inny.

Kiedy cytujemy pozycje źródłowe?

  1. Kiedy przytaczamy dosłownie pewne treści, np. definicje, wzory, pojęcia, reguły. Nie wymyślamy ich przecież, nie są one nasze. Zatem cytujemy. Można w treści wstawiać odpowiednie sformułowania, np.: „… w pracy [1] znaleźć można następującą definicję…”, „Opierając się na pracy [7] można stwierdzić…”. dotyczy to również rysunków, schematów, tabel.
  2. Kiedy chcemy podeprzeć swoje stwierdzenia, tezy, sugestie wiarygodnymi inspiracjami, np. „… przedstawione w pracy podejście jest podobne do opisywanego w [9]…”.
  3. Kiedy chcemy odesłać czytelnika pracy do materiałów źródłowych zawierających więcej szczegółowych informacji, np. „… więcej szczegółów na ten temat znaleźć można w pracy [7]”, „… szczegółowy opis funkcji oferowanych przez moduł zawiera [10]”.

Rysunki, tabele

Rysunki umieszczamy w tekście jako wyśrodkowane, zapewniając odstęp rzędu 6 pkt. od tekstu. Raczej nie stosujemy „oblewania” tekstem rysunku. Każdy rysunek powinien mieć podpis opatrzony odpowiednią etykietą i numerem („Rys. 4. Treść podpisu”, „Rysunek 5. Treść podpisu”). Podpisy umieszczane są oczywiście pod rysunkami. Nie ma wymogu drukowania pracy w kolorze, chyba że ma to istotne znaczenie (praca dotyczy grafiki komputerowej). Przy wydruku czarno-białym proszę zadbać o czytelność rysunków w oryginale kolorowych.

Tabele umieszczamy w tekście jako wyśrodkowane, zapewniając odstęp rzędu 6 pkt. od tekstu. Również raczej nie stosujemy „oblewania” tekstem tabeli. Każda tabela powinna posiadać nagłówek opatrzony odpowiednią etykietą i numerem („Tab. 4. Treść nagłówka”, „Tabela 5. Treść nagłówka”). Nagłówki umieszczane są oczywiście nad tabelami.

Każdy rysunek/tabela wstawiony do pracy powinien być opatrzony informacją o źródle, z którego pochodzi (odsyłacz do odpowiedniej pozycji w bibliografii). Informacja o źródle znajduje się pod rysunkiem/tabelą. Przykładowo zapis „Źródło: [1]” odnosi się do pierwszej pozycji bibliograficznej. W przypadku rysunków, które wymyślił, zaprojektował i sporządził sam autor, jako źródło przyjmuje się „opracowanie własne” (zapis „Źródło: opracowanie własne”). Rysunek opracowaniem własnym nie jest, jeżeli opiera się na rysunku cudzym, nawet, jeżeli nie jest skopiowany czy zeskanowany. Jeżeli rysunek źródłowy stanowi tylko inspirację, a ten zamieszczony w pracy różni się od oryginału, uznajemy, że źródło to opracowanie własne na podstawie rysunku źródłowego.

Obowiązuje nadrzędność tekstu nad rysunkami i tabelami. Treść rozdziału musi rozpoczynać przynajmniej jednozdaniowy tekst – tuż po nagłówku rozdziału czy podrozdziału nie może występować od razu rysunek czy tabela. Do każdego rysunki i każdej tabeli w tekście musi wystąpić odwołanie, np. „Rysunek 1 prezentuje…”, „na rysunku 3 przedstawiono…”, „Tabela 3 zawiera zestawienie wyników…”. Uwaga: proszę nie stosować sformułowań „… na rysunku poniżej…”, „… powyższa tabela…” tylko stosować odwołania z konkretną etykietą i numerem. Dzięki temu rysunek czy tabela do której się odnosimy nie musi znajdować się dokładnie obok odwołującego się tekstu, co pozwala na umieszczanie tekstu czy tabeli wcześniej albo później w tekście, tak aby zoptymalizować wykorzystanie miejsca na stronie.

W przypadku stosowania automatyzacji odwołań należy zwrócić uwagę na wstawiany z automatu tekst etykiety i dopasować szyk zdania do niego. Jeżeli automat wstawia „Rysunek 1”, to nie piszemy „… na Rysunek 1 przedstawiono…”, tylko „… Rysunek 1 przestawia…”. To samo dotyczy tabeli i innych obiektów posiadających opisy.

Spisy rysunków i tabel umieszcza się na końcu pracy, po bibliografii. Informacje o nich powinny one być włączone do spisu treści.

Interpunkcja

Po tytule pracy i po tytułach rozdziałów i podrozdziałów nie stawiamy kropek. W wypunktowaniach i wyliczeniach stosujemy znaki interpunkcyjne. Jeżeli treści w podpunktach zaczynają się od litery dużej, to stanowią one zdanie, i na ich końcu powinna być kropka. Jeżeli treści zaczynają się od litery małej, to całe wypunktowanie albo wyliczenie stanowi jedno duże zdanie, i poszczególne podpunkty powinny być zakończone przecinkiem lub średnikiem, a na samym końcu powinna znaleźć się kropka kończąca to — często dość długie — zdanie.

Przykład

Wyliczenie w postaci osobnych zdań:

  1. Zdanie pierwsze.
  2. Zdanie drugie.

Wyliczenie w postaci jednego zdania:

  1. fragment pierwszy,
  2. fragment drugi.

Na końcu tytułu pracy, na końcu tytułów rozdziałów i podrozdziałów nie stawiamy kropek.

Zalecane kroje/wielkości pisma

Główny tekst pracy powinien być sporządzony przy użyciu czcionki szeryfowej – Calibri, Georgia, Times New Roman o wielkości 11 – 12 pt. Najczęściej stosowane marginesy to 2,5cm z każdej strony, z możliwością delikatnej korekty.

Lista czego robić nie należy:

  1. Umieszczać tytułu zawodowego albo naukowego przed swoim nazwiskiem na pierwszej stronie.
  2. Umieszczać kropek po temacie pracy, pisać tematu pracy w cudzysłowach, pozostawiać w akapicie tematu pracy „wdów” i „bękartów”.
  3. Umieszczać numeru strony na stronie tytułowej. Numeracja stron zaczyna się po spisie treści.
  4. Umieszczać kropek po tytule rozdziału.
  5. Formułować tytuł rozdziału zawierający tylko nazwę własną jakiegoś bytu, zatem nie „Python” tylko „Język Python”, nie „.Net” a „Pakiet .Net”.
  6. Umieszczać w bibliografii opisów bibliograficznych źródeł internetowych wyłącznie w postaci adresu URL, proszę zapoznać się z zasadami tworzenia opisów takich, i nie tylko takich źródeł.
  7. Przesuwać tekst do następnej strony naciskając wielokrotnie klawisz Enter. Ten klawisz oznacza koniec akapitu. Przejście do nowej strony odbywa się poprzez wstawienie znacznika podziału strony. Proszę pamiętać, że istnieją odpowiednie komendy/style do uzyskiwania wcięcia akapitu i pozostałych zasad formatowania.
  8. Wstawiać kodów źródłowych programów jako rysunków — zrzutów ekranów z edytorów i środowisk IDE. Wstawiamy jako tekst sformatowany nieproporcjonalnym krojem pisma.
  9. Wstawiać kodów źródłowych programów jako „rozjeżdżających” się tekstów sformatowanych krojem nieproporcjonalnym. Kody wstawiamy jako tekst sformatowany nieproporcjonalnym krojem pisma, dbając o czytelność, szczególnie przy podziale długich linii na linii kilka.
  10. Używać sformułowania „funkcjonalności”. System ma „funkcje”, „opcje”, „możliwości” a nie nie „funkcjonalności”. Możemy dodać nową „funkcję” a nie „funkcjonalność”. To samo dotyczy słowa „ficzer”. Proszę unikać również słów „framework” (pakiet, szablon, pakiet szablonowy, wzorcowy), „templatki” (szablony), „formatki” (formularze), „kontrolki” (elementy sterujące), itp., itd.
  11. Rozpoczynać treści rozdziałów od rysunku, tabeli, kodu. Rozdział rozpoczyna zawsze przynajmniej jeden akapit tekstu.
  12. Wstawiać do pracy rysunków i tabeli bez opisu, przy czym rysunki mają podpisy umieszczone pod rysunkiem, a tabele mają nagłówki umieszczone nad nimi.
  13. Wstawiać do pracy rysunków, tabeli, wzorów, źródeł, do których nie ma tekście w pracy żadnego odniesienia. Jeżeli jest w pracy taki element, przynajmniej raz w tekście musi wystąpić odniesienie, np. „… co ilustruje rysunek 23”, „Tabela 12 prezentuje…”, „W pracy [6] przedstawiono…”.
  14. Używać do treści dokumentu kroju bezszeryfowego. Bezszeryfowy krój pisma — nagłówki, tabele, opisy rysunków, wykresów.
  15. Używać obok siebie dwóch różnych, lecz podobnych w sensie rodzaju krojów pisma. Np. Times New Roman i Georgia, Arial i Verdana.
  16. Zadawać pytania w nazwie rozdziałów/podrozdziałów np. Czym jest system komputerowy?
  17. Stosować interlinii różnej wielkości w głównej treści pracy.
  18. Tworzyć stronę tytułową i 2 stronę pracy niezgodnych ze wzorem na apd.us.edu.pl

Komentowanie wyłączone.

WordPress SEO fine-tune by Meta SEO Pack from Poradnik Webmastera