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.

Într-o lucrare de diplomă este important ca studentul să demonstreze înțelegerea literaturii (state-of-the-art = SotA), apoi să aplice tehnologii/metode/abordări pentru a replica ceva din literatura domeniului ales, să dezvolte plecând de la SotA, și apoi să compare/evalueze coerent (folosind aceleași metrici) cu rezultatele din SotA. Rezultatele calitative și/sau cantitative obținute pot fi pozitive sau negative, cel mai important fiind ca explicațiile/motivațiile să fie coerente și relevante în contextul domeniului specific abordat.

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, obiectivele şi rezultatele 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 detalierea utilitarelor și a tehnologiilor e importantă, ci abordarea si ideea propusă de autor.)
6. Ce obții în final? (Care sunt obiectivele proiectului/soluției/abordării/ideii? Care vor fi rezultatele sale (palpabile sau teoretice)? Ce va exista în final ce până acum nu există?)
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 comparabile sau cercetări anterioare - open source sau proprietare)? (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 cel 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 superioară 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ă motivația („De ce ?“) rezultatul/obiectivele („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 utilitatea 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 la el pană cand raspundeti satisfăcător la aceste intrebări.

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.

Î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 asta, 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.

În capitolul de introducere trebuie să prezentați motivația, obiectivele și o scurtă descriere a 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. Î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 un proiect răspunde la urmatoarele trei cerințe:

1. să meargă (să existe o funcționalitatea nouă și aceasta 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 disponibile)

Prima cerință (reprezentand funcționalitățile aplicatiei) este prezentă în capitolul/capitolele de „Implementare“. Celelalte două sunt prezente în capitolul/capitolele de „Testare și evaluare“.

Testare înseamnă un test din care rezulta un DA sau un NU, checked sau non-checked, passed sau failed. Adică dacă acele funcționalități au fost implementate corect sau nu.

Evaluarea rezultă în procente, timpi, cantitate, numere. Poate fi vorba de viteză, de overhead, de resurse consumate, de cât de bine scalează pe un număr de procesoare, etc. Aici apar tabele cu procente, 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ă acest lucru este posibil). Trebuiesc utilizate 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ă aveti noțiuni măsurabile si cuantificabile. Dacă nu numere, măcar niște calificative, intr-o scară valorică. În evaluare, explicați datele, tabelele și graficele pe care le prezentați și insistați pe relevanța lor, in urmatorul stil: „e bine așa pentru că …“; explicați cititorului nu doar datele ci și semnificația lor și cum sunt acestea interpretate. Și din această semnificație și interpretare să rezulte că proiectul vostru este bun, sau care sunt lucrurile ce s-ar putea face pentru a il imbunatati in continuare.

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 discutați despre 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.

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

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

• Urmăriți indicațiile de aici.
• Dacă nu există o solicitare explicită din partea coordonatorului, o copertă simplă, cu spirală, așa cum se face la xerox-ul din hol EC, lângă EC004, este OK.
• Coperta poate fi făcută ce limbă doriți (română sau engleză). Puteți avea text în engleză și copertă în română.

• Urmăriți indicațiile generale de aici.
• Recomandăm să 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

• Lucrarea poate fi scrisă în română sau engleză; nu este obligatorie una sau alta.
• 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 designed“, „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
• 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.
• 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.
• Contează să fie informație utilă, nu multă sau puțină.
• Preocupați-vă de conținut, structură, prezentare, mai puțin de dimensiune.

• NU puneți referințe la Wikipedia.
• Note de subsol se utilizeaza dacă referiți un link mai puțin seminificativ o singură dată.
• Daca nota este referințiata de mai multe ori, atunci utilizati o nota 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 sau referinta - este de preferat utilizarea unei note de subsol).
• Referințele se pun direct legate de textul referit (de exemplu „KVM [1] uses“ …). Nu este recomandat 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, „state of the art“, „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 „state of the art“, „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]“.

• 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).
  • Dacă nu puteți folosi figuri în format vectorial, folosiți, pe cât posibil, figuri în format PNG (lossless compression), în loc de format JPEG (lossy compression).
• Incercati sa utilizati imagini de rezolutie de minim 600 DPI.
• O figură nu va niciodata in document o pagină intreaga ci doar 1/3 sau maxim 1/2 pagină. Restul paginii trebuie sa fie dedicata explicației acesteia.
  • O figură nu ajunge să fie doar o figura. Ea este doar o formă de suport pe care o justificati în text și o explicati in diverse componente, module din cadrul figurii/imaginii/digramei/graficului.
• La fel si în cazul tabelelor.
• La fel si î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 le explica, ci pentru a argumenta o decizie.
  • De regulă, un snippet va avea 15-30 de linii de cod și liniile vor fi numerotate. 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 caption-urile de la figurile, tabele, si secțiuni de cod.
  • Folosiți caption-uri pentru toate componentele de mai sus.
  • Puneți figuri suficient de mari cât să se vadă (rezolutie minima 600 DPI).
  • 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ă.
  • Utilizati o scala logaritmica atunci cand este cazul.
  • E greu să numeri zero-urile și să te prinzi care este valoarea.
  • In 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 se leagă, faceți referire la capitolul următor.
• Nu introduceți concepte, noțiuni din senin, 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.

• După ce terminați documentul, stați cel puțin una doua zile și faceți altceva. Apoi parcurgeți-l și vedeți dacă vi se pare clar, natural, ce ați scris; dacă vouă nu 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“
  • 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. Acelea 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.
  • Sugeram font monotype/teletype (\texttt{…} în LaTeX, Courier în suite Office).
  • Pot fi folosite și fonturi cursiv/italice 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.

• 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 putine 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.

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-urilor este

1. de ce? (nevoie / utilitate / motivaț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.

• 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.

• Template-uri pentru document și slide-uri găsiți și pe în arhiva Systems.
• Aveți în vedere indicațiile despre titulaturi.
  • Este posibil să fie neactualizat template-ul. Actualizați-l cu numele corecte ale entităților: universitate, facultate, departament.

• 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 atrag foarte mult atenția (culori țipătoare, animații continue, scris mic), atunci pierdeți publicul, și în fapt nu doriți acest lucru.
  • 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. 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, mai ales cand aveti o prezentare scurta, de maxim 10 minute.
• 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.

• 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 pentr 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.
• 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.

• La programul de licență, toate susținerile sunt în limba română, ca atare faceți slide-urile în limba română. La master puteți face slide-urile în limba engleză și prezenta în limba 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ăspuns 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ă.