Proiect de informatică

Elevii realizează un proiect integrator care combină competențele dobândite pe parcursul anului.

Etapele unui proiect informatic

Un proiect nu începe cu scrierea codului. Cea mai frecventă cauză a proiectelor ratate este exact aceasta: elevul deschide editorul în prima zi și abia la final descoperă că a rezolvat altceva decât se cerea.

Etapele, în ordinea obligatorie:

1. Analiza cerințelor – stabilești CE trebuie să facă aplicația. Rezultatul este o listă de funcții concrete, scrise pe hârtie: ce date primește, ce afișează, ce operații permite. 2. Proiectarea – stabilești CUM va fi construită: ce structuri de date folosești, în ce module se împarte, cum arată interfața. Aici se desenează schemele logice și se scrie pseudocodul părților dificile. 3. Implementarea – abia acum scrii codul, urmând proiectul. 4. Testarea și depanarea – verifici că funcționează corect pe date variate și corectezi erorile găsite. 5. Documentarea – scrii ce face aplicația și cum se folosește. 6. Prezentarea și întreținerea – demonstrezi rezultatul, apoi îl corectezi sau îl îmbunătățești în urma observațiilor.

Împreună, aceste etape formează ciclul de viață al unui produs software. Ordinea nu este o formalitate, ci o economie de efort: o greșeală descoperită în etapa de analiză se repară într-un minut, aceeași greșeală descoperită după implementare cere rescrierea unei părți întregi din program.

De reținut totuși că ciclul nu este strict liniar. În practică te întorci de multe ori la etapa anterioară: testele arată o cerință înțeleasă greșit, iar tu revii la analiză. Acest du-te-vino este normal, nu un semn de eșec.

Ultima idee: documentarea nu este ultima etapă cronologic. Notițele se scriu pe parcurs, altfel la final nu îți mai amintești de ce ai ales o anumită soluție.

Planificarea: temă, cerințe și organizarea muncii

Alegerea temei se face după trei criterii simple: să fie utilă sau interesantă pentru tine, să poată fi terminată în timpul disponibil și să folosească ce ai învățat în acest an. Teme potrivite pentru clasa a VIII-a: un catalog de note cu calculul mediilor, un mic joc de ghicit numărul, un program de gestiune a unei biblioteci personale, un site simplu de prezentare a clasei, un chestionar cu punctaj automat.

Un proiect prea ambițios este cea mai frecventă capcană. Este mult mai bine să predai o aplicație mică și funcțională decât una mare și neterminată. Regula practică: mai întâi construiești versiunea minimă care merge, apoi adaugi funcții suplimentare dacă mai ai timp.

Cerințele se scriu ca propoziții verificabile. În loc de „programul gestionează note”, scrii:

• programul citește numele elevului și trei note;
• calculează media aritmetică cu două zecimale;
• afișează un mesaj dacă media este sub 5;
• permite adăugarea unui nou elev fără repornirea programului.

Diferența e că a doua formă poate fi bifată la final; prima nu.

Planificarea în timp se face invers: pornești de la data predării și împarți sarcinile pe săptămâni, lăsând obligatoriu o rezervă la final pentru testare și pentru situațiile neprevăzute. Cine planifică implementarea până în ziua predării nu mai are când să testeze.

Dacă proiectul e făcut în echipă, sarcinile se împart pe module, nu pe rânduri de cod, iar fiecare membru știe exact de ce răspunde. Se stabilește de la început unde se păstrează fișierele comune.

În fine, copiile de siguranță. Un proiect ține de la o versiune la alta, iar pierderea fișierului cu o zi înainte de predare e o poveste reală în fiecare clasă. Proiectul se ține în cel puțin două locuri, iar versiunile importante se salvează separat, cu data în nume, ca să te poți întoarce la ele.

Implementarea: cod scris ca să poată fi citit

Implementarea înseamnă transformarea proiectului în cod care funcționează. Câteva principii care fac diferența dintre un proiect de nota 7 și unul de nota 10.

Construiește pe bucăți, nu totul deodată. Scrii o funcție, o rulezi, verifici că dă rezultatul corect, abia apoi treci la următoarea. Cine scrie două sute de rânduri și abia atunci compilează primește un munte de erori în care nu mai știe de unde să înceapă.

Împarte programul în subprograme. Fiecare funcție face un singur lucru și are un nume care spune ce face: citesteNote, calculeazaMedia, afiseazaRaport. Avantajele sunt concrete: partea greșită se găsește mai repede, aceeași funcție se folosește în mai multe locuri, iar într-o echipă doi elevi pot lucra în paralel.

Alege nume care se explică singure. Variabilele numite a, b, x2 devin de neînțeles peste o săptămână, inclusiv pentru autorul lor. numarElevi și mediaClasei nu cer nicio explicație.

Comentează motivele, nu evidențele. Un comentariu de tipul „adun 1 la i” nu ajută pe nimeni — asta se vede din cod. Comentariul util explică de ce: de ce ai ales acea limită, ce presupunere ai făcut despre datele de intrare.

Verifică datele primite de la utilizator. Un program bun nu se blochează dacă în locul unei note se tastează o literă sau numărul 47. Tratarea acestor situații se numește validarea datelor de intrare și este unul dintre criteriile de evaluare.

Dacă proiectul este o pagină web, aceleași principii se aplică altfel: structura în HTML, aspectul separat în fișierul CSS, denumiri clare pentru fișiere și imagini, totul într-un singur folder cu căi relative — altfel proiectul funcționează pe calculatorul tău și se rupe pe calculatorul profesorului.

Testarea și depanarea: cele trei tipuri de erori

Testarea nu înseamnă să rulezi programul o dată cu datele care îți convin. Înseamnă să încerci activ să îl faci să greșească.

Cele trei tipuri de erori, cerute mereu la evaluare:

• Erori de sintaxă – încalci regulile limbajului: lipsește punctul și virgula, o acoladă, un nume e scris greșit. Sunt semnalate de compilator, programul nici nu pornește. Sunt cele mai ușor de reparat, pentru că îți arată linia.
• Erori de execuție (rulare) – programul pornește, dar se oprește brusc în timpul funcționării: împărțire la zero, ieșire în afara limitelor unui vector, citirea unui fișier care nu există.
• Erori de logică – cele periculoase. Programul rulează până la capăt, fără niciun mesaj, dar rezultatul este greșit: ai scris plus în loc de minus, ai împărțit la 2 în loc de 3, bucla merge cu un pas prea mult. Nimeni nu te avertizează; le găsești doar comparând rezultatul cu ce ar fi trebuit să iasă.

De aici concluzia care se cere frecvent: un program care compilează și rulează nu este automat un program corect.

Cum se testează organizat. Îți pregătești un set de date de test care acoperă:

• cazul obișnuit – date normale, rezultat cunoscut dinainte, calculat de tine pe hârtie;
• cazurile-limită – valoarea minimă, valoarea maximă, zero, un singur element, listă goală. Aici apar cele mai multe erori;
• cazurile greșite – litere în loc de cifre, valori negative acolo unde nu au sens, notă 47.

Depanarea (debugging) este procesul de găsire și eliminare a erorilor. Tehnicile utile la acest nivel: afișarea valorilor intermediare pe ecran ca să vezi unde se abate programul, executarea pas cu pas cu instrumentul de depanare din mediul de programare și metoda hârtiei — parcurgi algoritmul manual, notând valorile variabilelor la fiecare pas.

O regulă practică: după fiecare corectură, rulezi din nou toate testele, nu doar pe cel care pica. Reparațiile strică adesea altceva.

Documentarea, prezentarea și evaluarea proiectului

Documentația este partea pe care elevii o lasă la urmă și o scriu în grabă, deși ea cântărește mult în notă. Un proiect fără documentație este, pentru evaluator, un program pe care nu știe cum să îl pornească.

Ce conține documentația unui proiect de clasa a VIII-a:

• titlul și autorul, clasa, data;
• scopul aplicației – ce problemă rezolvă, în două-trei fraze;
• cerințele îndeplinite, ca listă;
• descrierea soluției – ce structuri de date ai folosit, în ce module e împărțit programul, eventual schema logică a algoritmului principal;
• manualul de utilizare – cum se pornește aplicația, ce introduce utilizatorul, ce obține;
• testele efectuate – ce date ai încercat și ce a rezultat;
• limitări și dezvoltări viitoare – ce nu face încă aplicația și ce ai adăuga;
• bibliografia și sursele – tutoriale, imagini, bucăți de cod preluate.

Ultimul punct este o chestiune de onestitate, nu de formalism. Codul preluat de undeva se citează, iar cel care nu îți aparține și pe care nu îl poți explica te dezavantajează la întrebări.

Prezentarea durează de obicei cinci-zece minute și are o structură care funcționează: problema aleasă, soluția, demonstrația live pe date reale, ce a fost dificil și ce ai învățat. Demonstrația e partea decisivă — un proiect care merge, arătat pe loc, convinge mai mult decât zece diapozitive. De aceea se pregătesc dinainte datele de test și se verifică aplicația pe calculatorul pe care va rula, nu doar pe al tău.

Criteriile de evaluare, ca să știi unde se dau punctele: funcționalitatea (aplicația face ce a promis), corectitudinea rezultatelor, calitatea codului (structurare, denumiri, comentarii), originalitatea, documentația și prezentarea. Un proiect care rulează perfect, dar nu poate fi explicat de autor, pierde puncte exact acolo unde nu se aștepta.

Test — 6 întrebări ca la examen