This is an old revision of the document!
Lucrarea trebuie să fie într-o formă bună, să fie valoroasă, pentru a fi susținută în iulie. Altfel, amânăm pentru susținere în septembrie. Nu este nici o problemă asta; e un lucru bun pentru că veți aduce proiectul și lucrarea într-o formă cât mai bună.
Pentru a fi într-o formă bună, lucrarea trebuie să prezinte foarte bine și convigător motivația proiectului și obiectivele proiectului. Adică răspunsurile la întrebările “De ce?” și “Ce?”:
Observați că este mai puțin important răspunsul la întrebarea “Cum?”. Implementarea e relevantă, dar contează rezultatul (“Ce?”-ul). Demonstrarea relevanței se face prin evaluarea rezultatelor (cel mai bine să fie comparativă: before/after, comparație cu alte soluții) pe diverse criterii: performanță, spațiu ocupat, memorie folosită, ușurință în utilizare, portabilitate etc. Grafice, tabele, rezultate numerice sunt foarte importante în evaluare pentru a demonstra utilitate soluției.
În măsura în care proiectul/lucrarea nu răspunde într-un mod convingător la întrebările de forma “De ce?” și “Ce?”, atunci trebuie să mai lucrați.
Cu circa 3-4 săptămâni înainte de predarea lucrării e util să începeți să structurați documentul/lucrarea. Pentru început, să puneți la un punct o structură a documentului lucrării de disertație (table of contents) pe care să îl completați apoi iterativ: întâi titluri de secțiuni, apoi cuvinte cheie, apoi idei principale, apoi idei de figuri, grafice, apoi scris text. Încă de la început insistați pe răspunsul la întrebările de mai sus; dacă răspunsul la întrebări este neconvigător, trebuie să găsim funcționalități sau cazuri de utilizare suplimentare care să facă proiectul relevant. Folosiți un document Google pentru că va fi ușor de adăugat comentarii în cadrul documentului.
Lucrarea de diplomă, la fel ca alte lucrări științifice, urmează, de regulă, următoarea structură:
La partea de State of the Art/Background + Related Work + Motivație + Cazuri de utilizare, poate fi avut în vedere următorul plan:
Faceți titluri de capitole și de secțiuni non-generice. Nu spuneți “Arhitectura proiectului”, spuneți “Componentele sistemului LiSA”; fiți preciși în exprimare. Nu spuneți “Implementare”, spuneți “Implementarea funcționalităților de video streaming” etc.
Înainte de a începe o nouă secțiune sau capitol trebuie să fi anticipat secțiunea/capitolul. Adică, în secțiunile anterioare trebuie să fie prezentat cadrul și motivația prezentării acestui nou capitol: dacă trebuie să vorbesc despre un modul de import dintr-o bază de date în alta, trebuie inainte să precizez de ce este nevoie de așa, la ce este util, în ce context activează. Trebuie ca cititorul să nu fie luat prin suprindere de un capitol nou; acesta trebuie să vină natural și să fie bine motivat, să nu prezentați lucruri doar de dragul de a le prezenta.
Nu este nevoie de o împărțire strictă pe 5-6 capitole: Introducere și motivație, Prezentare generală, Arhitectură și proiectare, Implementare, Testare și evaluare, Concluzii și dezvoltări ulterioare. Puteți face mai multe capitole sau altă structură. Mai ales legat de capitolele de “Arhitectură și proiectare” și “Implementare”.
În capitolul de introducere trebuie să prezentați motivația proiectului. Trebuie să reiasă cât mai bine la ce este util proiectul. Trebuie să răspundeți la întrebarea “De ce?”. Oricine citește acel capitol trebuie să prindă din primele paragrafe ceea ce ați făcut și să fie convins că este util ceea ce veți prezenta în continuare; să fie clară ideea și descrierea proiectului din primele 3-4 paragrafe. În general în introducere veți avea:
În capitolul de început introduceți gradual noțiunile. Un astfel de capitol trebuie să poată fi parcurs și înțeles și de cineva cu o pregătire tehnică redusă.
Stăpânul vostru este cititorul vostru. Documentul trebuie să fie ușor de parcurs și de înțeles. Puneți-vă în pantofii cuiva care nu știe despre ce este vorba, poate un continuator al proiectului vostru – cineva care îl parcurge, e interesat, se uită la capitolul de “Concluzii și dezvoltări ulterioare” și vrea să îl continue. Trebuie să capete cât mai mult know how din parcurgerea documentului vostru. Gândiți-vă la cititorul vostru. În mod ideal, veți da lucrarea voastră cuiva care nu are legătură cu proiectul și îl/o veți întreba: “Înțelegi ce zic acolo?”
Apare adesea o confuzie legată de “State of the Art” și “Related Work”. “State of the Art” se referă, de regulă, la nivelul curent de dezvoltare: care este starea curentă a domeniului, unde ne găsim, care este contextul. “Related Work” se referă la activități curente, similare abordării noastre, care încearcă să împingă state of the art-ul la următorul nivel. “State of the Art” se referă la stare/stadiu. “Related Work” se referă la acțiuni/activități.
În mod tipic (nu e musai să fie tot timpul) un proiect răspunde la trei cerințe:
Prima cerință (funcționalitățile) este prezentă în capitolul/capitolele de “Implementare”. Celelalte două sunt prezente în capitolul/capitolele de “Testare și evaluare”. A doua este vorba de testare, cealaltă de evaluare.
Testare înseamnă un test din care rezulta DA sau NU, checked sau non-checked, passed sau failed. Adică dacă acele funcționalități au fost implementate corect.
Evaluarea rezultă în procente, timpi, cantitate. Poate fi vorba de viteză, de overhead, de resurse consumate, de cât de bine scalează pe un număr de procesoare. Aici apar tabele cu procente și rezultate numerice și grafice. În mod obișnuit, aici se fac comparații și teste comparative cu alte proiecte similare (dacă există) și se extrag puncte tari și puncte slabe.
Evaluarea spune cât de bine merge aplicatia. Ții cont de avantajele pe care le-ai menționat și demonstrezi viabilitatea abordării / aplicației, de dorit prin comparație cu alte abordări (dacă se poate). Folosești niște criterii de evaluare care să demonstreze acest lucru (overhead, memorie ocupată, timp de rulare, ușurință în utilizare etc.). Cuvântul cheie la evaluare este “metrică”: trebuie să ai noțiuni măsurabile/cuantificabile. Dacă nu numere, măcar niște calificative (o scară valorică).
Parte de rezultate are cam 3 pași:
Cele trei cerințe de mai sus (să meargă, să meargă corect, să meargă repede) constituie punctul de plecare pentru capitolul de “Dezvoltări ulterioare”. Este vorba de trei tipuri de activități ulterioare posibile:
În capitolul de Concluzii nu se mai prezintă nimic legat de starea domeniului (state of the art). Se trece la propoziții afirmative despre cele realizate: În acest proiect am realizat, am implementat, am testat, am obținut. Aspecte precise legate de activitatea realizată și de rezultatele obținute. De obicei se cuplează cu “Dezvoltări ulterioare”; din activitățile realizate și rezultatele obținute, se pot extrage idei pentru dezvoltare ulterioară.
În concluzii descrieți în paragrafe: ce ați obținut, ce obiective ați avut, cum este relevant proiectul, ce rezultate ați obținut, cum ați evaluat.
Concluziile sunt în forma: trecut, prezent, viitor. Adică “ce am făcut? ce am obținut în final? cum am verificat/validat/evaluat? ce urmează să fac?”
În general capitolul de Concluzii începe cu o frază de genul “În această lucrare am realizat/obținut/dezvoltat/proiectat un proiect/o aplicație/o soluție/o infrastructură/un modul …”.
Exemple de lucrări de diplomă (documente și slide-uri) se găsesc aici.
Exemple de lucrări de disertație și rapoarte de cercetare (documente și slide-uri) se găsesc aici.
Right click → Manage versions → Upload new version
. Detalii aici.Shift+z
); nu faceți o copie a fișierului/documentului că devine dificilă gestiunea sa: o modificare trebuie făcută apoi în mai multe locuri.Urmăriți definițiile și indicațiile legate de plagiat aici.
Puteți face verificare de gramatică, exprimare și de plagiat pe Grammarly: https://www.grammarly.com/plagiarism-checker
Lucrările sunt verificate anti-copiere. Pentru aceasta conținutul lucrărilor trebuie să fie original. O lucrare având conținut neoriginal (adică paragrafe întregi copiate și necitate) va fi respinsă.
Parcurgeți indicațiile legate de citare.
Niște recomandări legate de etica publicării găsiți aici sau (mai detaliat) aici.
Este utilă și parcurgerea acestei imagini.
===== RD: iulie 2014 =====
Lucrarea trebuie să fie o lucrare bună pentru a putea fi susținută în sesiunea iulie: să aibă motivația clară, contribuții, rezultate și evaluare. Dacă suntem de părere că nu este încă la acel nivel, cel mai nimerit este să o amânăm pentru septembrie.
Pentru lucrările pe care agreem că pot fi susținute în iulie, să țineți cont, vă rog, de cele de mai jos:
Right click → Manage versions → Upload new version
.===== RD: septembrie 2014 =====
Lucrarea trebuie să fie o lucrare bună pentru a putea fi susținută în sesiunea septembrie: să aibă motivația clară, contribuții, rezultate și evaluare. Dacă suntem de părere că nu este încă la acel nivel, cel mai nimerit este să o amânăm pentru anul viitor.
Pentru lucrările pe care agreem că pot fi susținute în septembrie, să țineți cont, vă rog, de cele de mai jos:
Right click → Manage versions → Upload new version
.