Prezentarea proiectului de atestat: cum susții proba orală în fața comisiei

A doua probă a atestatului de informatică nu e o probă de programare. E o probă de explicat. Metodologia o numește prezentarea și motivarea teoretică a proiectului — iar cuvântul care contează acolo e motivarea.

Diferența e mai mare decât pare. Poți veni cu o aplicație care merge impecabil și să iei o notă mică, fiindcă n-ai putut răspunde de ce ai ales structura aia de date. Și invers: un proiect modest, dar explicat coerent, trece fără probleme. Comisia nu verifică dacă ai scris cod mult. Verifică dacă înțelegi codul pe care îl prezinți ca fiind al tău.

Pagina asta acoperă cadrul comun, din metodologie, plus partea practică — cum decurge efectiv o susținere. Criteriile exacte de notare se stabilesc însă la nivelul comisiei din liceul tău, deci întreabă profesorul îndrumător ce punctează el.

Ce spune metodologia despre proba asta

Puțin, și merită citit exact:

• proba constă în prezentarea și motivarea teoretică a proiectului realizat în timpul orelor de laborator din ultimul an de studiu;
• durata susținerii e de maximum 30 de minute;
• comisia îți poate pune întrebări pe marginea proiectului;
• proiectul se depune la secretariat până la 1 mai, însoțit de referatul profesorului îndrumător, finalizat cu admis sau respins;
• proba se susține în laboratoarele liceului, în afara orelor de curs.

Cele 30 de minute sunt un plafon, nu o normă. La multe licee prezentarea efectivă e considerabil mai scurtă, pentru că o comisie are de ascultat zeci de candidați într-un interval fix. Nu presupune că ai o jumătate de oră — întreabă câte minute ai efectiv și pregătește-te pentru varianta scurtă. O prezentare de 10 minute care spune tot e mai bună decât una de 25 care se oprește la jumătate pentru că s-a terminat timpul.

Cine te ascultă și cine te notează

Comisia are cinci membri, dar doar doi notează: cei doi profesori de specialitate cu drept de notare, de regulă din aceeași școală. Președintele (directorul), vicepreședintele (un metodist al inspectoratului sau un profesor din afara școlii) și secretarul nu dau note.

Cei doi evaluatori te notează separat, fiecare după criteriile stabilite de comisie. Nota finală la proiect e media aritmetică a celor două. Dacă între ele e o diferență de peste un punct, vicepreședintele reevaluează proba și stabilește el nota.

Practic: vorbești pentru doi oameni, nu pentru cinci. Dar vicepreședintele — singurul care poate veni din afara școlii — e cel care intervine când ceva nu se potrivește, așa că merită să prezinți ca și cum în sală ar fi cineva care nu te cunoaște deloc.

Pragul de la proiect e mai mare decât la proba practică

Detaliul pe care mulți elevi îl află prea târziu:

Probă	Notă minimă
Proba practică (biletul cu trei subiecte)	6
Proiect	7
Media finală	7

Proiectul cântărește jumătate din media finală și are pragul mai sus. Un proiect slab nu se compensează cu o probă practică bună. Și, pentru că nu se admit contestații la niciuna dintre probe, nota din ziua aia e definitivă.

Concluzia practică: dacă trebuie să alegi unde investești ultimele două săptămâni, investește în susținere, nu în încă o funcționalitate pe care n-o vei apuca să o arăți.

Ce întreabă comisia, de fapt

Întrebările nu sunt un test de cultură generală de informatică. Sunt, aproape întotdeauna, verificări că proiectul e al tău. Tipurile care revin:

„De ce ai ales tehnologia asta?" Nu există răspuns greșit, există doar răspuns absent. „Am ales PHP cu MySQL pentru că aveam nevoie de date persistente între sesiuni și lucrasem deja cu SQL la laborator" e un răspuns complet. „Pentru că așa am găsit un tutorial" nu e.

„Arată-mi unde se întâmplă X în cod." Cea mai directă verificare de autorship. Trebuie să poți naviga în propriul proiect fără să cauți. Dacă deschizi patru fișiere până găsești funcția de login, se vede.

„Ce se întâmplă dacă introduc aici o valoare greșită?" Validarea datelor. Aproape orice proiect de elev are aici o gaură, iar comisia o știe. Răspunsul bun nu e „nu se poate întâmpla" — e „am pus validare pe client, dar pe server verific doar tipul, aici e o limitare pe care o știu".

„Cum ai structurat baza de date și de ce?" Dacă proiectul are o bază de date, asta vine sigur. Trebuie să poți explica tabelele, cheile și legăturile dintre ele — vezi teoria de baze de date și SQL și interogările SQL.

„Ce ai face diferit dacă ai lua-o de la capăt?" Întrebarea asta pare o capcană, dar e opusul: e invitația să arăți că înțelegi limitele propriei lucrări. Un răspuns onest aici valorează mai mult decât insistența că totul e perfect.

Cum îți structurezi prezentarea

Ordinea care funcționează, indiferent de câte minute ai:

1. Problema, în primele 30 de secunde

Ce rezolvă aplicația și pentru cine. O singură frază, fără preambul. „E o aplicație de gestiune pentru o bibliotecă școlară: bibliotecarul înregistrează împrumuturile și vede ce cărți sunt întârziate." Comisia trebuie să știe la ce se uită înainte să vadă primul ecran.

Nu începe cu „bună ziua, mă numesc X și am ales tema asta pentru că mi s-a părut interesantă". Se știe cine ești, e pe listă.

2. Aplicația care rulează

Arată un singur scenariu complet, de la un capăt la altul: cineva se autentifică, face o operație reală, vede rezultatul. Nu fiecare buton, nu fiecare ecran. Un flux care funcționează convinge mai mult decât nouă ecrane atinse în fugă.

3. Partea tehnică: de ce arată așa

Aici e motivarea teoretică din metodologie, adică miezul probei. Trei lucruri:

• structura datelor — ce tabele / ce clase / ce fișiere și de ce așa;
• o decizie pe care ai luat-o conștient — de ce ai separat fișierele așa, de ce ai ales o listă în loc de un vector, de ce validezi acolo și nu dincolo;
• o bucată de cod pe care o poți explica linie cu linie. Alege-o tu, dinainte. E singura parte din prezentare pe care o controlezi complet.

4. Limitări și dezvoltări ulterioare

Închide spunând ce nu face aplicația și ce ai adăuga. Asta anticipează jumătate din întrebările comisiei și te așază în poziția celui care își cunoaște lucrarea, nu a celui care o apără.

Demo live sau capturi de ecran

Demo live, dacă poți. O aplicație care rulează în fața comisiei e cel mai puternic argument din toată prezentarea.

Dar pregătește varianta fără. Calculatorul din laborator nu e al tău: poate să nu aibă serverul local pornit, versiunea de runtime pe care o folosești tu, sau conexiune la internet. Minimul de prudență:

• testează proiectul pe un alt calculator decât al tău, măcar o dată, înainte de examen;
• ai baza de date populată cu date de test dinainte — nu introduce date live, pierzi minute și te expui la greșeli de tastare în fața comisiei;
• ai un set de capturi de ecran cu fluxul principal, în documentație sau pe stick, ca plan B;
• adu proiectul pe stick, nu doar în cloud.

Dacă demo-ul pică, nu e capăt de drum — treci la capturi și continuă. Panica se vede mai tare decât un server care nu pornește.

Dacă prezentați în echipă

Proiectul poate fi realizat în echipă de 2–3 elevi, în funcție de complexitate. La prezentare, regula nescrisă e simplă: fiecare trebuie să poată răspunde despre tot, nu doar despre partea lui.

Comisia va întreba, aproape sigur, cine ce a făcut. Iar apoi va întreba pe cineva despre partea altcuiva. Împărțiți prezentarea pe secțiuni, dar treceți împreună prin tot codul înainte de examen.

Notele sunt individuale. Un coleg care nu poate explica ce a scris nu te trage după el, dar nici nu te acoperă.

Greșeli frecvente

• Citirea documentației cu voce tare. Comisia o are deja în față. Prezentarea trebuie să adauge ceva peste documentație, nu să o repete.
• Cod care nu poate fi explicat. Dacă ai luat o funcție de undeva și nu știi cum funcționează, scoate-o înainte de examen. O aplicație mai simplă, dar înțeleasă, ia notă mai mare.
• Începutul cu tehnologii. „Am folosit HTML, CSS, JavaScript, PHP și MySQL" nu spune nimic despre ce face aplicația. Tehnologiile vin la punctul 3, ca justificare, nu la punctul 1, ca listă.
• Introducerea de date live în demo. Fiecare tastare e o ocazie de greșeală, în fața a doi oameni care notează.
• Scuzele. „N-am apucat să fac partea de rapoarte" spus din proprie inițiativă atrage atenția exact acolo. Spune ce face aplicația; limitările le formulezi la final, ca dezvoltări ulterioare.
• Proiectul depus, dar nu și repetat. Termenul de depunere e 1 mai, examenul e în mai. Între ele e singurul interval în care poți repeta prezentarea cu voce tare, cronometrat. Aproape nimeni n-o face.

Cu o zi înainte

• Proiectul rulează pe un calculator care nu e al tău
• Baza de date are date de test, populate deja
• Capturile de ecran cu fluxul principal sunt pregătite, ca plan B
• Totul e pe stick, nu doar în cloud
• Ai ales bucata de cod pe care o explici linie cu linie
• Poți spune în două fraze ce face aplicația și pentru cine
• Ai repetat o dată, cu voce tare și cu ceasul pornit
• Știi câte minute îți dă efectiv comisia

Întrebări frecvente

Cât durează prezentarea? Maximum 30 de minute, conform metodologiei. În practică poate fi mult mai puțin, în funcție de câți candidați are comisia. Întreabă înainte.

Trebuie să fac slide-uri? Metodologia nu cere. Unele licee da, altele nu — întreabă profesorul îndrumător. Dacă faci, ține-le puține: aplicația care rulează e mai convingătoare decât slide-urile despre ea.

Pot să prezint un proiect făcut în echipă? Da, în echipă de 2–3 elevi, în funcție de complexitatea proiectului. Notele rămân individuale.

Ce se întâmplă dacă aplicația nu pornește în ziua examenului? Treci la capturile de ecran și continuă prezentarea. De asta contează planul B — și de asta merită testat proiectul pe alt calculator înainte.

Pot contesta nota de la proiect? Nu. Metodologia prevede explicit că nu se admit contestații la niciuna dintre probe.

Ce notă îmi trebuie la proiect? Minimum 7 — mai mult decât la proba practică, unde pragul e 6. Media finală trebuie să fie tot minimum 7.

Comisia se uită la cod sau doar la aplicație? La amândouă. Proba se numește prezentarea și motivarea teoretică a proiectului, deci întrebările despre cod sunt normale și așteptate.

Mai departe

• Cum îți alegi tema de proiect — decizia se ia în decembrie–ianuarie
• Documentația proiectului: ce conține și cum se scrie
• Atestatul de informatică: structura examenului și notarea
• Biletele date în examen și exercițiile cu rezolvări explicate, pentru cealaltă probă

De unde vin informațiile de aici

Partea de cadru — durata, componența comisiei, pragurile de notare, termenele, regimul contestațiilor — e din Metodologia de organizare și desfășurare a examenului de atestare a competențelor profesionale ale absolvenților claselor de matematică-informatică și matematică-informatică, intensiv informatică, aprobată prin OMECI nr. 4.843/2009, publicată în Monitorul Oficial, Partea I, nr. 694 din 15 octombrie 2009, și modificată prin OM nr. 3.009 din 6 ianuarie 2021.

Partea de sfaturi — structura prezentării, tipurile de întrebări, lista de verificare — nu e reglementată și nu are cum să fie: criteriile concrete de evaluare a proiectului se stabilesc de comisia din fiecare liceu. Tratează-o ca pe o metodă de pregătire, nu ca pe o cerință oficială, și verifică întotdeauna la profesorul îndrumător ce punctează comisia ta.