Diplomski

Diplomski rad iz informatike

Kako se piše diplomski rad iz informatike: odnos teorije i implementacije, opis arhitekture, testiranje, verzije alata i navođenje AI pomoći.

7 min čitanja

Informatički diplomski rad ima obrnut odnos teorije i prakse od društvenih nauka. Ako si napravio rešenje, ono je rad — a teorija objašnjava zašto je napravljeno baš tako.

Najčešća greška je suprotno: trideset strana o istoriji tehnologije i pet strana o sopstvenom rešenju.

Druga greška je suptilnija i tiče se granice između dva medija. Rešenje se demonstrira, a rad se čita. Ono što se vidi dok aplikacija radi — brzina, izgled, tok kroz ekrane — u radu ne postoji dok ne bude opisano, izmereno ili nacrtano. Zato je pola posla pri pisanju odluka o tome šta od projekta uopšte ulazi u tekst, a šta ostaje za pokazivanje pred komisijom.

Dva tipa rada

Rad sa rešenjem — aplikacija, sistem, model, baza, analiza podataka. Najčešći i najbolje prolazi.

Istraživački rad — poređenje algoritama ili pristupa, merenje performansi, eksperiment sa modelima. Traži ozbiljniju metodologiju: unapred određene uslove merenja, ponavljanja i način na koji se rezultati porede.

Razlika nije u tome koliko koda ima nego u tome šta rad tvrdi. Prvi tip tvrdi da je problem rešen i pokazuje kako; drugi tvrdi da je nešto bolje od nečega i to mora da izmeri. Ako u zadatku stoji poređenje ili evaluacija, u pitanju je drugi tip, i tada se metodologija piše pre nego što se napiše prva linija koda.

Struktura rada sa rešenjem

  1. Uvod — problem i zašto je vredan rešavanja
  2. Pregled postojećih rešenja — šta već postoji i u čemu je nedostatak
  3. Zahtevi — funkcionalni i nefunkcionalni
  4. Odabrane tehnologije i obrazloženje izbora
  5. Arhitektura rešenja — dijagrami i opis komponenti
  6. Implementacija — ključni delovi, ne ceo kod
  7. Testiranje i rezultati
  8. Zaključak i pravci razvoja

Dve tačke koje se najčešće preskaču su treća i sedma — a upravo one razlikuju rad od projekta.

Zahtevi su najkorisnije poglavlje u celom radu, jer se sve kasnije na njih vraća. Napisani kao proverljive stavke — šta sistem mora da omogući i pod kojim uslovima — daju ti spisak po kom se piše testiranje i po kom se u zaključku kaže šta je ostvareno, a šta nije. Zahtev formulisan kao „sistem treba da bude brz” ne može se ni testirati ni odbraniti.

Drugo poglavlje nije istorija oblasti nego poređenje. Tri do pet postojećih rešenja, po istim kriterijumima, i rečenica o tome šta nijedno ne pokriva — to je obrazloženje zašto tvoje rešenje postoji.

Obrazloženje izbora tehnologije

„Korišćen je Python” nije obrazloženje. Obrazloženje kaže šta je bio kriterijum i zašto je izabrano rešenje najbolje po njemu:

Izabran je Python zbog zrelih biblioteka za obradu prirodnog jezika i zato što sistem ne zahteva izvršavanje u realnom vremenu. Razmatran je i Java, koja bi dala bolje performanse, ali bi implementacija obrade teksta zahtevala znatno više koda bez dobiti za ovaj slučaj upotrebe.

Ovaj pasus komisija gotovo uvek pita.

Obrazloženje sme da bude i praktično. „Izabrano je okruženje sa kojim sam već radio, jer je rok bio ograničen” je legitiman razlog ako se napiše otvoreno i ako se uz njega kaže šta bi drugi izbor doneo. Ono što se ne prima je izbor bez ijednog razmatranog alternativnog rešenja.

Isto važi i za odluke unutar rešenja: izbor baze, način čuvanja podataka, biblioteka za jedan zadatak. Dve do tri takve odluke, obrazložene po istom obrascu, nose celo poglavlje.

Šta ide u rad, a šta se demonstrira

Ovo je granica koja odlučuje kako rad izgleda.

U rad ide ono što se može pročitati i proveriti:

  • Isečci koda po petnaestak linija, sa objašnjenjem šta rade i zašto su izabrani baš oni
  • Dijagrami — arhitekture, toka podataka, baze, sekvenci, slučajeva upotrebe; jedan dijagram vredi više od tri strane opisa
  • Šema baze i opis ključnih tabela i veza
  • Tabele sa rezultatima testova i uslovima pod kojima su dobijeni
  • Opis toka kroz sistem — šta korisnik radi i šta se u sistemu dešava, korak po korak

Za demonstraciju ostaje ono što se vidi samo dok radi: ponašanje interfejsa, brzina odziva u stvarnom vremenu, tok kroz ekrane, oporavak od greške pred publikom.

Pravila za kod u tekstu:

  • Ceo kod ne ide u rad. Izvorni kod ide u prilog ili u repozitorijum na koji se upućuje, sa oznakom verzije — prilozi u diplomskom radu
  • Kod se formatira jednoobrazno, u fontu sa jednakim širinama znakova, i numeriše kao listing
  • Nikad snimci ekrana koda — nečitljivi su u štampi i ne mogu se kopirati
  • Snimci ekrana aplikacije su korisni, ali samo uz objašnjenje šta se na njima vidi; niz slika bez teksta nije poglavlje
  • Svaki listing, dijagram i slika imaju broj i potpis, i pominju se u tekstu — potpisi tabela i slika

Provera koja se isplati: pročitaj poglavlje o implementaciji zamišljajući da nemaš pristup aplikaciji. Ako se iz teksta ne razume šta sistem radi, nedostaje dijagram ili opis toka, a ne još jedan isečak koda.

Šta poneti na samu demonstraciju i kako je pripremiti: tehnička priprema za odbranu.

Testiranje, merenje i verzije

Rad koji tvrdi da rešenje radi, a ne pokazuje nijedan pokazatelj, nije potpun. Šta se očekuje:

  • Funkcionalno testiranje — spisak slučajeva i ishoda, vezan za zahteve iz trećeg poglavlja
  • Merenje performansi, ako su bitne — vreme odziva, propusnost, potrošnja resursa
  • Uslovi merenja — konfiguracija, veličina podataka, broj ponavljanja
  • Granični slučajevi — šta se dešava pri praznom ulazu, velikom opterećenju, prekidu veze

Tabela sa rezultatima testova je najkorisniji prilog koji ovakav rad može da ima. Uz nju ide i pošteno navedeno šta nije prošlo: test koji je pao, pa je popravljen, deo je rada, a ne sramota.

Jedno merenje nije merenje. Ako navodiš vreme izvršavanja, navedi broj ponavljanja i koju vrednost prikazuješ — prosek, medijanu ili najbolji rezultat. Bez toga se broj ne može ni ponoviti ni uporediti.

Verzije su deo nalaza. Tvrdnja o ponašanju biblioteke bez verzije je bezvredna, jer se u sledećem izdanju može promeniti. Navodi se: jezik i verzija, ključne biblioteke sa verzijama, okruženje u kom je testirano, verzija baze i operativnog sistema. Ako je rad o poređenju alata, verzija ide uz svaki rezultat, ne samo u uvodnu napomenu.

Izvori i navođenje AI pomoći

  • Zvanična dokumentacija — legitiman izvor, sa verzijom i datumom pristupa
  • Radovi sa konferencija — u računarstvu često važniji od časopisa
  • Standardi i specifikacije
  • Repozitorijumi koda — kada se poziva na konkretnu implementaciju, uz oznaku verzije ili revizije

Ono što nije izvor: odgovor sa foruma bez potpisa, blog bez autora, tekst bez datuma.

Knjige brzo zastarevaju, pa se za praktične stvari koriste novije reference nego u drugim oblastima. Koliko izvora treba diplomski rad. Kako se navodi dokumentacija i stranica: kako citirati internet izvor.

Ako si u rešenju koristio tuđi kod — biblioteku, isečak, primer iz dokumentacije — navedi odakle je i pod kojim uslovima se koristi. To nije mana rada; nenavedeno preuzimanje jeste.

Isto važi i za AI alate. Ako si deo koda generisao njihovom pomoću, to se navodi. Sve više fakulteta to izričito traži, a i tamo gde ne traži, prećutkivanje je rizik — na odbrani ćeš morati da objasniš svaku liniju. Kako se navodi i gde je granica: AI alati i akademsko pisanje i kako citirati ChatGPT.

Najčešće greške

  • Teorija bez rešenja, kada je zadatak tražio rešenje
  • Kod bez objašnjenja
  • Nema obrazloženja izbora tehnologije
  • Nema zahteva, pa se ne zna šta je trebalo postići
  • Nema testiranja
  • Nema verzija alata i biblioteka
  • Snimci ekrana umesto dijagrama
  • Merenje bez uslova i bez ponavljanja
  • Izvori stariji od deset godina za temu koja se menja svake godine

Za seminarski rad iste oblasti: seminarski rad iz informatike.

Povezani vodiči