• Informații complete despre proiectul de diplomă (date, comisii, indicații) găsiți pe wiki-ul Departamentului de Calculatoare.
• Pentru înscrierea la proiectul de diplomă trebuie să urmați pașii de aici.

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?”:

1. De ce este relevant proiectul? (de ce este relevant domeniul proiectului, ce creșteri sau evoluții determină rezolvarea proiectului)
2. Ce neajunsuri există (pe care proiectul le va rezolva)? (Ce aspecte din domeniul proiectului nu există implementate/dezvoltate? Ce aspecte sunt rezolvate ineficient sau neoptim? Ce aspecte merită îmbunătățite?)
3. De ce alte proiecte nu le rezolvă? (Ce alte proiecte/abordări/idei sunt dezvoltate? Ce rezolvă fiecare? Ce nu rezolvă și își va propune proiectul curent să rezolve?)
4. De ce sunt relevante neajunsurile/problemele? (Cum va fi soluționarea lor utilă utilizatorilor? Care vor fi beneficiarii acestei soluții? Cum le va face viața mai bună?)
5. Ce soluție propui? (Ce propui cu adevărat? Ce abordare/idei propui? - nu detaliere de utilitare și tehnologii, e importantă abordarea/ideea)
6. Ce obții în final? (Care sunt obiectivele proiectului/soluției/abordării/ideii? Care vor fi rezultatele sale (palpabile)? Ce va exista în final ce până acum nu exista?)
7. De ce este soluția propusă (cea) mai bună? (De ce altă abordare/idee nu ar fi mai potrivită?)
8. Ce diferențiatori are soluția (față de alte soluții)? (Cum te compari cu alte soluții? Dacă alte soluții/abordări rezovlă aceeași problemă cum te compari cu ele, ce aduci în plus? Dacă nu există soluții pentru problema curentă, insistă pe problemă și pe faptul că doar tu o soluționezi în modul pe care-l consideri ce-l mai potrivit.)
9. Ce cazuri de utilizare sunt avantajoase pentru soluție? (Care sunt scenariile de utilizare în care soluția este relevantă și este folosibilă? De ce în aceste scenarii soluția propusă este superioadă altora? - scenariile sunt o întârire a diferențiatorilor)

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ă:

• Introducere: ce faci, pe scurt; clar, concret să îi fie clar cititorului despre ce este vorba. Vezi aici indicații despre scrierea introducerii. Trebuie să clarificați, pe scurt, motivația proiectului. E recomandat să scrieți capitolul de introducere după ce ați scris restul lucrării, și nu atunci când începeți să scrieți lucrarea.
• State of the Art/Background + Related Work + Motivație + Cazuri de utilizare
• Design + Implementare + Testare (merge sau nu merge)
• Evaluare (cât de bine merge)
• Concluzii (sumar a ceea ce ai făcut, rezultate concrete, contribuții) + Further Work (ce este de făcut în continuare, ce îți propui să faci în continuare)

La partea de State of the Art/Background + Related Work + Motivație + Cazuri de utilizare, poate fi avut în vedere următorul plan:

• Acesta este contextul larg (SotA). Nu trebuie foarte punctual precizat; poate fi vorba de un context mai larg de aplicații / abordări care au legătură cu cea propusă de tine.
• Acestea sunt problemele / neajunsurile / nevoile curente (SotA + Motivație). Pot să fie lipsuri (nu merge în cazul X, nu are suport pentru Y), pot să fie aspecte negative (nu merge suficient de bine în cazul X). În general răspunsuri la întrebări de forma “De ce?”
• Acestea sunt abordările (și aplicațiile curente). Astea sunt câteva dintre neajunsurile acestor abordări (Related Work).
• Aici îmi propun să ajung. Ținând cont de problemele / neajunsurile / nevoile curente și de soluțiile existe, îmi propun să ajung la următoarele rezultate și la o viitoare stare a lucrurilor. (Obiective, răspunsul la întrebare “Ce?”)
• Aceasta este abordarea pe care eu o propun. Are aceste avantajele / diferențiatorii față de abordările curente (Prezentarea soluției, răspunsul la întrebarea “Cum?”).
• Acestea sunt scenariile / cazurile de utilizare pentru abordarea pe care o propun (Cazuri de utilizare): demonstrează utilitate. Coroborat cu avantajele ei față de abordările / aplicațiile existente, înseamnă că are sens existența acestei abordări / aplicații și ajută la atingerea rezultatelor / obiectivelor.

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:

• paragrafe de context care să prezinte starea lucrurilor
• o descriere scurtă a proiectului și a lucrării
• motivația proiectului (probleme, neajunsuri, nevoi, răspunsuri la întrebări de forma “De ce?”)
• obiectivele proiectului (rezultate propuse, noua stare a lucrurilor după proiect, răspunsuri la întrebări de forma “Ce?”)
• un sumar al lucrării, al celorlalte capitole

Î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:

1. să meargă (funcționalitatea nouă să existe și să funcționeze – să pornească aplicația, să rezulte ceva din rularea ei)
2. să meargă corect (conform specificațiilor)
3. să meargă repede, eficient, scalabil (adică să fie performant, să fie comparat cu alte soluții)

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ă).

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:

1. Este utilă o nouă funcționalitate; de implementat.
2. Unele funcționalități au fost testate și au probleme; există defecte, issues, neajunsuri, buguri care trebuie rezolvate.
3. În unele scenarii de evaluare performanța este redusă sau se comportă mai slab decât soluții similare; este de dorit să fie rezolvate aceste neajunsuri pentru asigurarea unei performanțe ridicate sau comparabile sau mai bune decât alte soluții.

Î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 …”.

• Urmăriți indicațiile generale de aici.
• Template-uri pentru document și slide-uri găsiți în repository-ul templates.
  • Nu sunt obligatorii, puteți folosi și alte template-uri.

• LaTeX și pachete aferente pentru document (booktabs, listing)
• Pentru diagrame
  • Dia
  • Inkscape
  • Google Draw
  • https://www.draw.io/
  • https://www.websequencediagrams.com/
  • http://www.asciiflow.com/#Draw
  • Ditaa
  • http://www.gliffy.com/
• Pentru Mockup de interfețe grafice
  • Balsamiq
  • Balsamiq GDrive

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.

• Pentru lucrul la proiectul de diplomă (partajare informații, structură, răspunsuri la întrebări, idei) e recomandat să folosiți Google Drive și să partajați conținutul cu coordonatorii. Cel mai bine creați un director partajat în care să puneți toate documentele, fișierele și resursele legate de proiectul de diplomă. Are persistență, e mai ușor de distribuit un link mai multor persoane și poate fi organizat împreună cu alte informații. Dați un nume reprezentativ directorului partajat Google Drive, de forma “Diploma 2013-2014 - NUME Prenume - Nume Proiect” și partajați-l cu persoanele relevante.
  • Evitați trimiterea de atașamente. Sunt dificil de regăsit și se pierde centralizarea de pe Google Drive.
• Pe cât posibil folosiți documente Google pentru discuții legate de proiectul de diplomă; coordonatorul vă poate da ușor recenzie în formă de editare colaborativă sau comentarii. La fel ca în cazul directorului, dați un nume reprezentativ documentul, de forma “Diploma 2013-2014 - NUME Prenume - Titlu proiect”.
• Dacă alegeți să nu folosiți document Google, folosiți fișiere în format PDF.
  • Puteți uploada versiuni diferite ale aceluiași fișier în aceeași “intrare” în Google Drive. Folosiți Right click → Manage versions → Upload new version. Detalii aici.
• Când lucrați la documentul pentru lucrarea de diplomă și îl veți trimite pentru recenzie, să fie în în format PDF (e universal și se vede peste tot la fel).
• Pentru fișierele obținute din redactare, folosiți format PDF (portabil) și un nume reprezentativ. De exemplu: “Diploma 2013-2014 - NUME Prenume - Nume Proiect.pdf” ca să fie ușor de identificat când îl puneți pe un stick sau îl atașați la un e-mail sau îl publicați la un loc cu altele.
• Când trimiteți un fișier coordonatorului sau unei alte persoane, e recomandat să îl puneție pe Google Drive / Dropbox / alt serviciu de sharing.
• Dacă aveți de adăugat un document/fișier în mai multe directoare pe Google Drive, folosiți facilitatea specifică Google Drive (cu ajutorul combinației de taste 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 indicațiile de aici.
• Puteți printa față-verso sau doar față, nu există ceva impus.
• În general, nu este nevoie de o copertă “șmecheră” decât dacă așa solicită coordonatorul.
  • RD: Pentru ce care lucrați cu mine: Lucrarea o printați și o spiralați, copertă simplă, să dureze maxim 10 minute tot procesul la xeroxul de lângă sala EC004. KISS.
  • Dacă nu există o solicitare explicită din partea coordonatorului, o copertă simplă, îndosariată cu plastic (folie transparentă în față, plastic/carton în spate)., așa cum se face la xerox-ul din hol EC, lângă EC004, este OK.
  • Dacă vreți voi musai sau vi se solicită o copertă “șmecheră”, o puteți face în ce limbă doriți (română sau engleză). Puteți avea text în engleză și copertă “șmecheră” în română.

• Urmăriți indicațiile generale de aici.
• Vedeți inficațiile legate de editare/redactare de aici (în limba engleză).
• Redactați iterativ lucrarea, după fiecare iterație consultați și echipa de coordonare:
  • Întâi cuprinsul (titlul capitolelor și secțiunilor)
  • Ideile principale în capitole și secțiuni
  • Ce figuri, tabele, snippet-uri de cod vor intra în fiecare secțiune
  • Dezvoltarea ideilor în pagrafrae
  • Parcurgerea lucrării cap coadă pentru a verifica faptul că exprimarea și formatarea sunt consecvente
• Fiți consecvenți: dacă optați pentru un stil de exprimare sau formatare, folosiți-l pe acela

• Lucrarea poate fi scrisă în română sau engleză; nu este obligatorie una sau alta.
  • Recomand engleză pentru că este ușor să exprimi termeni tehnici, dar alegerea limbii aparține fiecăruia.
• Când scrieți în limba română sau aveți nume în limba română, folosiți diacritice corecte (comma below).
• Când scrieți în engleză, începeți cu majusculă (capitalizați) cuvintele din titlurile de capitole, secțiuni, titlul lucrării; excepție fac articolele, prepozițiile și conjuncțiile.
  • Nu e obligatoriu să faceți asta pentru figuri, tabele și snippet-uri de cod. Oricum ar fi, fiți consecvenți. Fie capitalizați peste tot în figuri, tabele și snippet-uri de cod, fie nicăieri.
• Folosiți spell checker. În Vim se face folosind comanda “:set spell”.
• Dacă redactați în limba engleză, aveți grijă la forma corectă sau adecvată dintre posibilitățile de mai jos:
  • this vs. these
  • can vs. may
  • As you can see → As one can see
  • because vs. as
  • it's vs. its
  • it's vs. is
  • needed vs. required
  • necessary vs. required
  • like vs. such as
  • to have vs. to possess
  • level vs. layer (networking stack)
  • fairer vs. improved fairness
  • also vs. at the same time/moreover
  • it can be given vs. it may be given
  • given vs. provided
  • the tests vs. tests
  • between vs. among
  • data vs. the data
  • students vs. the students (at beginning of sentence)
  • because vs. due to
  • as such vs. consequently
  • course vs. class
  • problem vs. issue
  • which vs. that
  • big vs. large
  • few vs. little vs. small
  • so vs. as such
  • verify vs. check
  • too vs. as well
• Dacă redactați în limba română aveți grijă la greșelile frecvente de mai jos:
  • folosirea cuvântului “librărie”, corect este “bibliotecă”
  • folosirea cuvântului “adiționale”, corect este “suplimentare”
  • folosirea expresiei “nucleul/kernel-ul de Linux”, corect este “nucleul/kernel-ul Linux”
• Folosiți diateza activă când spuneți ce ați făcut și ce decizii ați luat: “we chose to”, “we designed”, “we implemented”, “we surveyed”, “we evaluated”. Nu folosiți diateza pasivă, pentru că nu este afirmativă, pare deresponsabilizantă: “X was degined”, “a survey was conducted”, “the following were evaluated”.
• Evitați exprimarea informală/colocvială de forma “we can see in the picture”, “we will move to the next chapter”. Folosiți “In the picture above we present” sau “The picture above shows”.
• Folosiți timpul trecut când prezentați în lucrare activități deja realizate, pentru că e ceva ce ați făcut. Nu folosiți timpul viitor pentru asta. Puteți folosi timpul viitor pentru a indica ce veți prezenta în continuare în lucrare, dar nu pentru a prezenta activități deja realizate în proiect și rezultate deja obținute.

• Când puneți numele coordonatorului/coordonatorilor, fie îl puneți fără titulatură, fie cu titulatura corectă. Exemple de titulaturi corecte:
  • As.ing. - pentru asistenți
  • As.drd.ing. - pentru asistenți doctoranzi
  • As.dr.ing. - pentru asistenți doctori
  • Șl.dr.ing. - pentru șefi de lucrări
  • Conf.dr.ing. - pentru conferențiari
  • Prof.dr.ing. - pentru profesori
• Nu folosiți spații între câmpurile titulaturii. “Prof.dr.ing.” e OK, “Prof. dr. ing.” e mai puțin estetic.
• Folosiți forma “Prenume Nume”, în loc de “Nume Prenume”, atât pentru numele vostru cât și pentru coordonatori.
• Trebuie sa existe cel puțin un coordonator din facultate, cu nomenclatorul de mai sus și eventual alți co-supervizori. Aceștia pot să nu fie membri ai facultății. Puteti să îi treceți fără titulatură sau cu titulatură. Exemple de titulaturi corecte:
  • Ing. - pentru ingineri
  • Drd.ing. - pentru ingineri doctoranzi
  • Dr.ing. - pentru ingneri doctori
• În cazul în care la coordonare au participat mai multe persoane, treceți-le pe toate în pagina de titlu, în ordinea relevenței. Adică, la un proiect la care sunt coordonatori Răzvan Deaconescu și Daniel Băluță, ordinea să fie:
• # Daniel Băluță
• # Răzvan Deaconescu
  • pentru că în mod cert Daniel va fi fost mai mult implicat.
• Numele instituțiilor sunt cele indicate aici.
  • Universitatea POLITEHNICA din București / University POLITEHNICA of Bucharest
  • Facultatea de Automatică și Calculatoare / “Automatic Control and Computers Faculty” or “Faculty of Automatic Control and Computers”
  • Departamentul de Calculatoare / Computer Science and Engineering Department

• Nu vă concentrați pe dimensiune. Cât iese, iese; va fi suficient; nu băgați umplutură.
  • Recomandarea este de maxim 40 de pagini.
• Contează să fie informație utilă, nu multă.
• Preocupați-vă de conținut, structură, prezentare, mai puțin de dimensiune.

• NU puneți referințe la Wikipedia.
• Nu știu o regulă legat de footnote-uri sau referințe, dar dau recomandarea:
  • dacă referiți un link mai puțin seminificativ și o singură dată, puneți notă de subsol;
  • altfel puneți referință bibliografică.
• Dacă o imagine este introdusă în text și nu este făcută de autorul lucrării, trebuie citată sursa ei (ca notă de subsol).
• Referințele se pun direct legate de text (de exemplu “KVM[1] uses” …). Nu este musai să spuneți “as stated in [12]” sau “as described in [11]”.
• Afirmațiile de forma “are numerous”, “have grown exponentially”, “are among the most used”, “are an important topic” trebuie să fie acoperite cu citări.
  • Mai ales în capitolele de introducere și de “state of the art” sau “related work” sau “background” trebuie să vă argumentați afirmațiile prin citări. Fiți autocritici și gândiți-vă dacă afirmațiile au nevoie de citări, chiar și cele pe care le considerați evidente.
  • Cea mai mare parte dintre citări vor fi în capitolele de introducere și de “state of the art” sau “related work” sau “background”.
• Intrările bibliografice trebuie citate în text. Nu le adăugați pur și simplu la final.
• Nu copiați sau traduceți elemente mai mari de un paragraf. Dacă este util un paragraf sau o propoziție puneți între ghilimele și citați sursa.
• Dacă reformulați idei sau creați un paragraf rezumat al unor idei folosind cuvintele voastre, precizați cu citare (referință bibliografică) sau cu notă de subsol sursa sau sursele de unde ați preluat ideile.
• Puneți referințele direct în text în zona aferentă; nu este nevoie de precizări explicite de forma “mai multe aici[1]”.

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

• Folosiți figuri, diagrame și tabele oriunde posibili. O figură face cât o mie de cuvinte și face mai ușor de înțeles textul.
  • Puteți folosi imagini, diagrame arhitecturale, diagrame de flux, diagrame de cazuri de utilizare, diagrame de interacțiune etc.
• Ca figuri, folosiți, pe cât posibil, figuri în format vectorial (PDF, EPS, SVG pentru LaTeX sau direct în Office).
  • Figurile în format vectorial sunt scalabile în document; la zoom in pot deveni mai clare spre deosebire de formatul bitmap.
  • Dacă nu puteți folosi figuri în format vectorial și aveți nevoie să folosiți figuri în format bitmap/raster, folosiți, pe cât posibil, format PNG (lossless compression), în loc de format JPEG (lossy compression).
• O figură va ocupa din document o pagină: circa 1/3 sau 1/2 pagină poza și restul explicației acesteia.
  • O figură nu ajunge să fie doar figura. Ea este doar o formă de suport pe care o justifici în text și explici diversele componente, module din cadrul figurii/imaginii/digramei/graficului.
• La fel în cazul tabelelor.
• La fel în cazul snippet-urilor de cod.
  • Snippet-urile de cod sunt utile pentru a justifica o decizie luată. Nu veți explica bucăți de cod doar de dragul de a explica, ci pentru a argumenta o decizie.
  • De regulă, un snippet va avea 15-30 de linii de cod și vor fi numerotate liniile. Veți explica, la fel ca într-o imagine rolul snippet-ului și anumite linii de cod importante.
  • Folosiți un font monospace pentru snippet-uri de cod.
  • Adăugați caption-uri sub snippet-uri de cod de forma: “Listing 1: Sample Algorithm”.
  • În măsura în care sunt greu vizibile, încadrați snippet-urile într-un chenar sau puneți o culoare de fundal (un gri deschis, de exemplu).
  • În LaTeX, pentru snippet-uri de cod puteți folosi pachetul listings.
• Centrați în text figuri, tabele, secțiuni de cod.
  • Folosiți caption-uri pentru cele de mai sus.
• Puneți figuri suficient de mari cât să se vadă.
• Referiți figurile în text și detaliați ce înseamnă. Evitați să puneți o figură și să precizați doar vag în text despre ce este vorba.
• Dacă folosiți diagrame cu un flux, atunci puneți numere deasupra săgeților din diagrame, numere care să justifice ordinea.
• Nu încărcați figurile și tabelele. Trebuie să rezulte repede aspectele importante dintr-o figură sau tabel.
• Dacă în figuri aveți multe zero-uri la numerele de pe verticală/orizontală, sau în tabele, decupați din zero-uri și schimbați unitatea de măsură.
  • E greu să numeri zero-urile și să te prinzi care este valoarea.
  • Adică în loc de a spune 100 ms, 1000ms, 10000 ms, spune 0.1s, 1s, 10s.
• Figurile care nu sunt făcute de autorul articolului trebuie citate (fie referință bibliografică, fie notă de subsol (footnote)).
• În LaTeX, pentru tabele folosiți pachetul booktabs.
• Pentru generarea automată a imaginilor din Dia și Inkscape urmăriți indicațiile de aici.

• Anexele sunt opționale (adică, la fel ca P.S.-ul într-un e-mail, de obicei nu veți avea nevoie de ele și nu vor apărea într-un document). Ce poate intra în anexe:
  • Exemplu de fișier de configurare sau compilare.
  • Un set de tabele mai mari.
  • Un set de screenshot-uri.
  • Un exemplu de rulare a unor comenzi plus outputul acestora.
  • În mod tipic, în anexe intră lucruri care ocupă mai mult de o pagină și care ar rupe firul de parcurgere din text.

• Țineți cont de halo effect. Întâi precizați ce ați făcut, partea existentă, partea de succes și apoi spuneți ce nu ați făcut, ce mai este de făcut, parte lipsă.
• Nu începeți capitole sau secțiuni brusc. Trebuie să luați ușor cititorul, să îi prezentați contextul și apoi conceptele.
• Nu începeți o secțiune direct după un titlu de capitol. După un titlul de capitol spuneți despre ce este vorba în acel capitol, apoi începeți titlul secțiunii și descrieți acea secțiune.
• Fiecare capitol trebuie să înceapă cu o prezentare a acelui capitol. Să-i fie clar cititorul ce va găsi în acel capitol, să nu-l surprindă prezența sau succesiunea unor secțiuni.
• Încheiați fiecare capitol cu un sumar al capitolului, a ceea ce ați prezentat și a relevanței celor prezentate; în mod ideal, dacă se poate și nu pare picat din OZN, faceți referire la capitolul următor.
• Nu introduceți concepte, noțiuni din OZN, adică dintr-o dată, fără o prezentare în prealabil a cadrului. Nu trebuie să suprindeți pe cititor, trebuie să reiasă natural, din text, introducerea unei noțiuni.
• Nu puneți o singură secțiune la un subcapitol sau o singură subsecțiune la un capitol. Dacă este una singură, atunci nu își are sensul acolo; nefiind o altă secțiune/subsecțiune după ea, conținutul fi “integrat” în secțiunea/capitolul părinte.
• Cititorul trebuie să aibă imaginea de ansamblu a proiectului în minte. Trebuie să structurați lucrarea și să vă exprimați în așa fel încât cititorul să aibă în minte vederea de ansamblu (“pădurea”) și să nu fie suprins când se prezintă o componentă sau alta (“copacii”). Orice termen sau idee nou introdusă trebuie să fie anticipată în lucrare, astfel încât cititorul să nu fie suprins de vederea acesteia.
• Când prezentați ceva, trebuie să exprimați într-o formă sau alta răspunsuri la întrebări de forma “De ce?”: “De ce am ales această variantă?”, “De ce prezint această tehnologie?”, “De ce prezint acest lucru aici și nu altundeva în lucrare?”, “De ce este aceasta cea mai potrivită soluție?”, “De ce este această informație relevantă în cadrul lucrării?” și așa mai departe.

• După ce terminați documentul, stați cel puțin jumătate de zi și faceți altceva. Apoi parcurgeți-l și vedeți dacă vi se pare clar, natural, ce ați scris; dacă vouă ni vi se pare clar, o să fie greu pentru cititori.
  • Dacă aveți un amic cu oarece cultură tehnică, e ideal să-i dați pentru citire documentul să vă ofere feedback/recenzie.

• Nu puneți punct după titlul unui capitol sau al unei secțiuni.
• Aveți grijă la virgule; există tendința de a se folosi virgule în mod exagerat. Parcurgeți acest articol.

• Evitați exprimă de forma:
  • “Nobody likes to”
  • “Everybody enjoys”/“Everybody knows”
  • Sunt afirmații generaliste pentru care nu ai acoperire.
  • Se poate spune “We assume/It is assumed that nobody likes to …”.
• Evitați folosirea exprimărilor de forma:
  • “This thesis aims to”
  • “In this thesis we want to”
  • Păi ori vrei/țintești ori chiar ai făcut ceva
  • Teza are niște afirmații clare/concrete. Spui ce ai făcut, ce prezintă teza, implementare, proiectare; nu spui ce urmărești. Ai urmărit ceva, ai ajuns undeva. Teza prezintă ce ai făcut și unde ai ajuns, nu are alte obiective sau dorințe. Alea pot apărea la “Future Work”.
• Când folosiți termeni vagi precum “context” sau “background” sau “concept”, alipiți-i de niște termeni concreți ca să fie clar la ce vă referiți.
• Nu folosiți forma posesivă pentru obiecte:
  • “system's health” → “system health”
  • “module's desing” → “design of the module”
• Evitați folosirea cuvintelor “some”, “many”, “a lot”. Nu au valoarea cantitativă absolută și pot să însemne lucruri diferite pentru fiecare.
  • Dacă le folosiți, aveți nevoie de o citare care să argumenteze că sunt “puține”, “multe” etc.
• Când folosiți pentru prima oară un acronim în text detaliați despre ce este vorba. De exemplu: “ISA (Instruction Set Architecture)”, “TCP (Transmission Control Protocol)”, “SQL (Standard Query Language)”.

• Folosiți un format consecvent pentru nume de funcții, macro-uri, variabile, excepții - elemente care apar, de obicei, în cod.
  • Sugerez font monotype/teletype (\texttt{…} în LaTeX, Courier în suite Office).
  • Am văzut folosit și un font cursiv/italic, care arată, de asemenea, bine.
  • Cuvântul cheie, legat de formatare, este consecvență.
• Nu indentați paragrafele. Folosiți un spațiu între paragrafe (“Use space after paragraph”).
  • În LaTeX puteți folosi pachetul parskip.
• Numerotați paginile lucrării.
• Folosiți formatul “justified” pentru a încadra textul în pagină.

• Urmăriți indicațiile de aici.

• Dacă o frază ocupă 3 sau mai multe rânduri este candidat la a fi împărțită. Fraze astfel de lungi sunt, în general, greu de înțeles.
  • Dacă o frază este atât de lungă și este greu de înțeles la citire, spargeți-o în două sau mai multe fraze.
• Paragrafele au, în general, între 5 și 10 rânduri. Un paragraf = o idee. Pot exista mai multe sau mai multe rânduri cât timp ideea se regăsește în acel paragraf.
  • Dacă un paragraf este prea mare devine greu de citit, pare un munte de text. Vedeți dacă sintetizați mai multe idei în acel paragraf, caz în care spărgeți-l în subparagrafe.

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.

Mindset-ul vostru trebuie să fie unul: să insist la fiecare pas pe DE CE am făcut (motivație, obiective) și CE AM OBȚINUT (rezultate), mai puțin pe CE AM FĂCUT și CUM AM FĂCUT.

Succesiunea ideilor trebuie să fie de la concret la abstract. Arătați întâi ceva concret: use case, un exemplu de rezultat unde vrei să ajungi, o problemă concretă, apoi prezinți ideea (de rezolvare, de proiectare, de investigare). Când prezinți concretul prima oară, audiența va înțelege ce vrei și apoi prezinți ideea ta. În general (pot fi și excepții), ordinea ideilor / slide-urilo este

1. de ce? (nevoie / utilitate / movitație, scenarii)
2. ce? (ce urmărim să facem, unde vrem să ajungem obiective)
3. cum? (cum am făcut, ce pași, arhitectură)
4. ce a rezultat? (unde suntem, ce avem, ce vrem să mai facem)

Nu trebuie (ba chiar e contra-indicat) să aveți structura slide-urilor similară cu a documentului. Documentul este o informație completă, exhaustivă care poate fi parcursă în orice mod dorește cititorul. Slide-urile (și prezentare) sunt o selecție a ideilor puse într-o formă narativă, o poveste coerentă, cu legătură între slide-uri, care “vând” audienței în primul rând IDEEA și REZULTATELE proiectului, abia apoi IDEEA DE IMPLEMENTARE sau PRINCIPIILE DE PROIECTARE.

Mindset-ul vostru nu trebuie să fie riguros și profesoral / pedagogic. Nu trebuie (ba chiar e contra-productiv) să insistați pe fiecare detaliu, să explicați fiecare parte tehnică și fiecare decizie; nu trebuie să aveți acoperire până la ultimul nivel de cunoaștere a ceea ce prezentați. Mindset-ul trebuie să fie unul de sales, de pitching, în care prezinți în linii mari idea și insiști pe IMPACT, MOTIVAȚIE, ORIGINALITATE, BENEFICII. Detaliile se găsesc în document. Prezentarea e mai mult un act de vânzare / de persuasiune a ideii proiectului vostru.

Să îți fie clar pentru fiecare slide “Care este rostul acestui slide? Ce vreau să arăt cu acest slide?”.

Un slide = o idee. Nu puneți mai multe idei pe un slide, va fi confuzant. Titul slide-ului corespunde ideii prezentate în acel slide.

• Realizați slide-urile în mod iterativ. După fiecare iterație cereți feedback de la echipa de coordonare:
  • Întâi creați titlurile slide-urilor.
  • Scrieți ideile principale.
  • Precizați unde doriți să apară imagini, tabele, snippet-uri de cod.
  • Dezvoltați ideile principale în conținut.
  • Faceți o parcurgere a slide-urilor și asigurați-vă că aveți exprimare și formatare consecventă.
• Pentru comunicare cu echipa de coordonare, urmăriți indicațiile de publicare a fișirelor.
• În realizarea slide-urilor și în susținerea prezentării urmăriți și indicațiile de aici.

Slide-urile să urmeze un fir narativ cursiv. Să fie ușor pentru public să urmărească prezentarea. Asta înseamnă o structură de forma:

1. prezentarea voastră și a proiectului
2. contextul proiectului
3. problema, nevoia, motivația
4. cazuri de utilizare (use cases) cu exemple concrete care să justifice soluția voastră
5. obiectivele, descrierea scurtă a soluției, ce vă propuneți să faceți
6. ce există deja, plusuri/minusuri, unde se plasează soluția voastră (state of the art + beyond state of the art)
7. cum ați rezolvat problemele, detalii de arhitectură, implementare
8. testare și evaluare
9. concluzii, dezvoltări ulterioare

• Template-uri pentru document și slide-uri găsiți aici. Vedeți și template-urile LaTeX Beamer.
  • Nu sunt obligatorii, puteți folosi și alte template-uri.
• Sunt foarte importante indicațiile despre titulaturi.
  • Este posibil să fi neactualizat template-ul. Actualizați-l cu numele corecte ale entităților: universitate, facultate, departament.

• Slide-urile să fie format 4:3, nu format 16:9.
• Câteva metrici recomandate (dar nu impuse):
  • Slide-urile sunt suport de prezentare în primul rând pentru voi, apoi pentru public; publicul vă ascultă în primul rând pe voi, apoi se uită la slide-uri; dacă stați și urmăriți slide-urile sau dacă slide-urile conțin lucruri care îți atrag foarte mult atenția (culori țipătoare, animații continue, scris mic), atunci pierdeți publicul.
  • 10-15 slide-uri
  • 3-6 bullet-uri pe slide
  • 20-40 de cuvinte per slide

• Slide-urile trebuie să prezinte în special “pădurea” (viziunea, motivația, nevoia, obiectivele, evaluarea), mai puțin “copacii” (implementarea, tehnologiile folosite, metricile).
• Evitați propozițiile (predicatele) contează ideile.
• Slide-urile cu imaginie sunt mai bune decât slide-urile cu text.
• Slide-urile trebuie să urmeze o poveste, o cronologie, nu să fie “bucăți” din proiect.
• Trebuie să reiasă de la bun început motivația proiectului (“De ce?”-ul).
• La fel ca în document, când prezentați, țineți cont de halo effect; întâi precizați ce ați făcut, partea existentă, partea de succes și apoi spuneți ce nu ați făcut, ce mai este de făcut, parte lipsă.
• Nu trebuie să prezentați în slide-uri tot proiectul vostru cu tot ce ați făcut, ci doar ce este necesar pentru ca o comisie să înțeleagă ce ați facut, de ce ați făcut și care au fost deciziile pe care le-ați luat pe parcursul lucrării. Toate detaliile le veți avea în lucrarea scrisă și nu trebuie prezentate în același mod în slide-uri.

• Nu insistați mai mult de 2 slide-uri pe partea de “state of the art”.
• Nu folosiți slide de cuprins. Nu prea ajută și consumă din timpul prezentării.
• E recomandat ca slide-ul/slide-urile de rezultate/evaluare să conțină rezultate concrete: numere, tabele, grafice.
• Slide-ul de concluzii este de forma forma: trecut, prezent, viitor. Adică “ce am făcut? ce am obținut în final? cum am verificat/validat/evaluat? ce urmează să fac?”
• Nu folosiți un slide de final cu un semn de întrebare. Slide-ul de final poate fi:
  • slide-ul de concluzii sau
  • un slide care să conțină cuvintele cheie aferente prezentării
• Slide-urile trebuie să “curgă”, să fie coerente. Să urmăriți slide-urile să nu aveți “rupturi” între slide-uri. Adică un slide să nu apară “ca nuca în perete” ci să fie anunțat de un alt slide. Dacă nu puteți anunța un slide cu un alt slide să faceți asta verbal în timpul prezentării.
• Să fie clar din slide-uri și din prezentare care este contribuția voastră. Mai ales în cadrul unui proiect existent la care voi ați contribuit. Să fie foarte clar (din slide-uri, din ton, din concluzii) care era starea proiectului și care a fost contribuția voastră și cum ați îmbunătățit proiectul.
• Neapărat să aveți la final un slide de concluzii. Nu puneți doar slide de “Dezvoltări ulterioare”. Puneți un slide de concluzii în care să sumarizați ce ați obținut, cum poate fi folosit, cum ați testat/validat/evaluat. Apoi pus conținut de tipul “Dezvoltări ulterioare”.

• Aveți în vedere să folosiți animații simple (de tip “appear”) în slide-uri atunci când aveți mai multe informații pe slide. Atât pentru slide-uri cu multe bullet-uri cât și pe slide-uri cu imagini cu mai multe componente.
  • Dacă un slide conține prea multe informații atunci este greu de urmărit. Publicul va primi prea mult conținut pe slide-uri dintr-o dată.
  • Folosiți animații pentru ca informațiile să apară pe rând: bullet după bullet, sau “imaginea, săgeată, imagine” etc. Adică să apară aceste lucruri în timpul prezentării pe măsură ce vorbești; adică slide-urile să vă ajute.
  • Evitați animații complexe care fură privirea și nu sunt utile. Adică folosiți doar animații de tipul “appear”.
• Nu folosiți fundal de culoare închisă.
• Când folosiți imagini, folosiți culori care să se vadă pe proiector.
• Când folosiți text peste imagini, folosiți o culoare opusă (scrieți text alb peste fundal roșu și text negru peste fundal galben, nu invers).
• Când folosiți imagini, folosiți text de dimensiune mare, să se vadă.
  • Insistați pe acest lucru. De prea multe ori
• Nu încărcați slide-ul cu text sau imagini; dacă o imagine e prea mare, eliminați bucăți sau folosiți două slide-uri. Și folosiți animații, ca să nu apară totul dintr-o dată.
• Nu puneți titluri de slide-uri care nu spun nimic: de exemplu “Introducere”. Titluri mai generice dar care spun ceva pot fi: “Motivație”, “Neajunsuri curente”, “Context”, “Obiective”, “Arhitectură”, “Rezultate”, “Evaluare”, “Testare”, “Concluzii”.
• Dacă un slide are un singur bullet principal și restul sub-bullet-uri, atunci acel bullet poate dispărea, eventual integrat în titlu.
• Evitați folosirea slide-urilor cu același titlu. Dacă mai multe slide-uri prezintă același lucru continuu, atunci puneți un sufix “(2)” după titlul celui de-al doilea slide, “(3)” după titlul celui de-al treilea slide etc.
• La nevoie ajustați dimensiunea fontului pentru ca titlul unui slide să încapă pe un singur rând.
• Numerotați slide-urile ca să vă poată fi referite pentru întrebări și observații.
• Pe slide-urile cu rezultate să fie clar, eventual să puneți cu bold sau să încercuiți rezultatele relevante.
• Pe slide-urile cu rezultate ajută să fie rezultatele și în format numeric procentual/relativ nu doar absolut.
• O imagine este de multe ori mai expresivă decât un bullet. Dacă slide-ul vostru poate folosi imagini în loc de bullet-uri, folosiți imagini.

• Puteți face slide-urile în engleză și susține prezentarea în română.
• Puteți face documentul în limba engleză și slide-urile prezentării în limba română.
• Sunt mai puțin importante tehnologiile folosite sau detaliile de implementare și mai importante motivația proiectului, relevanța, obiectivele, rezultatele obținute și evaluarea acelor rezultate.
• Slide-urie conțin idei, nu fraze. Evitați folosirea frazelor și verbelor în slide-uri.

• Dacă folosiți imagini externe, să le citați; în acest caz puneți link-urile într-un slide final, ca să nu ocupe loc pe fiecare slide.
• Citați imaginile pe care le folosiți în slide-uri dacă nu sunt făcut de voi. La fel citați statistici sau alte lucruri pe care le prezentați la capitolul context. Pentru a nu încărca fiecare slide e recomandat ca aceste referințe să se găsească pe un ultim slide; dar un slide pe care nu îl veți afișa publicului; e doar un slide care să aibă referințele pentru a fi legitime slide-urile și pentru a permite cuiva consultarea offline a referințelor.

• Găsiți indicații generice aici.
• Trebuie să se încadreze în 8 minute.
• E recomandat să repetați prezentarea acasă de vreo 3-4 ori ca să vă asigurați că vă încadrați în timp și că aveți ideile formulate.
• Nu insistați pe detalii dar nici nu vorbiți generic; e nevoie de o cale de mijloc (prea tehnic, se înțelege greu, prea netehnic, e apă de ploaie).
• Pot apărea întrebări dubioase din comisie; unele pot fi din cauză că nu au înțeles; nu vă fie jenă să spuneți “nu”, “nu știu” sau “nu am înțeles întrebarea”.
• Un răpsuns negativ, dar direct (fără a fi însă agresiv sau nepoliticos), este mai bun decât unul ezitant.
• Când prezentați un slide, o anti-tehnică des întâlnită este: click pentru next slide, ăăă, titlul slide-ului, se vorbește despre slide.
  • NU precizați titlul slide-ului. E clar; trecerea între slide-uri nu este o întreupere a poveștii, povestea trebuie să fie fluentă.
• Nu vorbiți în fraze lungi, interminabile. Folosiți fraze scurte și încheiați frazele din intonație. Folosiți intonație și pauze scurte de vorbire pentru a demarca frazele.
• Repetați prezentarea și vedeți dacă aveți “ăăă”-uri sau “îîî”-uri în vorbire. Dacă este cazul, străduiți-vă să le eliminați sau să le diminuați.

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:

1. Să creați un director Google Drive pe care să-l partajați cu mine.
2. În acel director să uploadați versiunile draft ale lucrării de diplomă și a slide-urilor (sau eventual folosiți Google Presentation).
3. Uploadați versiuni PDF ale documentelor.
4. * Puteți uploada versiuni diferite ale aceluiași fișier în aceeași “intrare” în Google Drive. Folosiți Right click → Manage versions → Upload new version.
5. * Pentru recenzie voi folosi Adobe Reader pe Windows pentru a face comentarii/adnotări în fișierul PDF. Va trebui să folosiți și voi Adobe Reader pe Windows pentru a le putea vedea.
6. În acel director creați un document în care să răspundeți la întrebările de aici. Scrieți fiecare întrebare și răspunsul la acea întrebare. Pe baza răspunsului la aceste întrebări vom decide dacă lucrarea va fi susținută sau nu în iulie. Mă anunțați de acest document ca să vin cu comentarii (direct în document).
7. În denumirea directoarele, documentelor, fișierelor, slide-urilor etc. țineți cont de precizările de aici.
8. Să obțineți de la secretariat fișele necesare pentru susținerea lucrării de diplomă în sesiunea iulie 2014 și să veniți să vi le semnez.
9. Să începeți să lucrați la lucrarea de diplomă. Să țineți, vă rog, cont de recomandările din această pagină. Parcurgeți-le de mai multe ori (scuze că sunt multe și relativ neorganizate) și asigurați-vă că țineți cont de ele. Când aveți versiuni draft ale lucrării, să le puneți pe Google Drive, în directorul partajat și să mă anunțați de acest lucru ca să vin cu observații.
10. Pentru predarea și susținerea lucrării, aveți în vedere precizările de pe wiki.cs.pub.ro. Veți face parte din comisia 1.
11. După definitivarea lucrării (sau, mai bine, în timpul lucrului) să realizați slide-uri pentru prezentare. Fie folosiți Google Presentation și atunci le puneți direct în directorul partajat Google, fie folosiți Office/LaTeX Beamer și apoi le publicați în acel director. În realizarea slide-urilor țineți cont de precizările de aici sau aici. Mă anunțați de acest lucru pentru a veni cu observații.
12. Să vă rezervați perioada 4-6 iulie 2014 pentru o repetiție a prezentării pentru diplomă (rehearsal). Să vă rezervați un interval de câteva ore ca să faceți prezentarea și să vedeți și prezentările altora.
13. Alte detalii legate de susținere sunt aici.

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:

1. Să creați un director Google Drive pe care să-l partajați cu mine.
2. În acel director să uploadați versiunile draft ale lucrării de diplomă și a slide-urilor (sau eventual folosiți Google Presentation).
3. Uploadați versiuni PDF ale documentelor.
4. * Puteți uploada versiuni diferite ale aceluiași fișier în aceeași “intrare” în Google Drive. Folosiți Right click → Manage versions → Upload new version.
5. * Pentru recenzie voi folosi Adobe Reader pe Windows pentru a face comentarii/adnotări în fișierul PDF. Va trebui să folosiți și voi Adobe Reader pe Windows (pe Linux nu merge) pentru a le putea vedea. Pe Linux, puteți folosi Okular pentru a parcurge recenziile, dar interfața e mai slabă ca Adobe Reader pe Windows.
6. În acel director creați un document în care să răspundeți la întrebările de aici. Scrieți fiecare întrebare și răspunsul la acea întrebare. Pe baza răspunsului la aceste întrebări vom decide dacă lucrarea va fi susținută sau nu în iulie. Mă anunțați de acest document ca să vin cu comentarii (direct în document).
7. În denumirea directoarele, documentelor, fișierelor, slide-urilor etc. țineți cont de precizările de aici.
8. Să obțineți de la secretariat fișele necesare pentru susținerea lucrării de diplomă în sesiunea septembrie 2014 și să veniți să vi le semnez.
9. Să începeți să lucrați la lucrarea de diplomă. Să țineți, vă rog, cont de recomandările din această pagină. Parcurgeți-le de mai multe ori (scuze că sunt multe și relativ neorganizate) și asigurați-vă că țineți cont de ele. Când aveți versiuni draft ale lucrării, să le puneți pe Google Drive, în directorul partajat și să mă anunțați de acest lucru ca să vin cu observații.
10. Pentru predarea și susținerea lucrării, aveți în vedere precizările de pe wiki.cs.pub.ro.
11. După definitivarea lucrării (sau, mai bine, în timpul lucrului) să realizați slide-uri pentru prezentare. Fie folosiți Google Presentation și atunci le puneți direct în directorul partajat Google, fie folosiți Office/LaTeX Beamer și apoi le publicați în acel director. În realizarea slide-urilor țineți cont de precizările de aici sau aici. Mă anunțați de acest lucru pentru a veni cu observații.
12. Să vă rezervați perioada 11-14 septembrie 2014 pentru o repetiție a prezentării pentru diplomă (rehearsal). Să vă rezervați un interval de câteva ore ca să faceți prezentarea și să vedeți și prezentările altora.
13. Alte detalii legate de susținere sunt aici.