Proiectarea și realizarea unui produs software

Parcurgerea etapelor de dezvoltare a unui proiect informatic de complexitate medie.

Ciclul de viață al unui produs software

Un program de câteva zeci de linii se poate scrie direct. Un produs software — o aplicație folosită de alți oameni, întreținută ani la rând — nu. De aceea dezvoltarea urmează un ciclu de viață: succesiunea etapelor prin care trece produsul, de la ideea inițială până la retragerea din uz.

Etapele clasice, în ordinea cerută la examen:

• analiza cerințelor — se stabilește ce trebuie să facă produsul, împreună cu beneficiarul;
• proiectarea — se stabilește cum va fi construit: structura modulelor, structurile de date, algoritmii, interfața;
• implementarea (codificarea) — se scrie efectiv codul, modul cu modul;
• testarea — se verifică dacă produsul face ce s-a cerut și se identifică erorile;
• implementarea la beneficiar (punerea în funcțiune) — instalare, configurare, instruirea utilizatorilor;
• întreținerea (mentenanța) — corectarea erorilor descoperite ulterior și adaptarea la cerințe noi.

Două observații care sunt de fapt esența capitolului. Prima: întreținerea este cea mai lungă și cea mai costisitoare etapă, nu scrierea codului — un produs se scrie luni și se întreține ani. A doua: costul corectării unei erori crește dramatic cu etapa în care e descoperită. O cerință înțeleasă greșit, prinsă în analiză, costă o discuție; aceeași cerință greșită, descoperită după livrare, poate însemna rescrierea aplicației.

Modelele de organizare a etapelor diferă. Modelul cascadă (waterfall) parcurge etapele strict una după alta și e potrivit când cerințele sunt clare și stabile de la început. Modelele iterative și incrementale repetă ciclul pe versiuni succesive, fiecare adăugând funcționalități și permițând corecții de traseu — abordare potrivită proiectelor unde cerințele se limpezesc pe parcurs.

Analiza cerințelor și specificațiile

Analiza răspunde la o singură întrebare: ce anume trebuie să facă produsul. Rezultatul ei este specificația cerințelor — documentul care descrie funcționalitățile, datele de intrare, rezultatele așteptate și restricțiile.

Cerințele se împart în două categorii care se cer separat:

• cerințe funcționale — ce face sistemul: „aplicația permite adăugarea unui elev”, „calculează media pe clasă”, „exportă lista în fișier”;
• cerințe nefuncționale — cum se comportă sistemul: timp de răspuns, volum maxim de date, securitate, ușurință în utilizare, portabilitate.

O cerință bine scrisă este clară, completă, necontradictorie, realizabilă și mai ales verificabilă. Testul practic: dacă nu poți spune ce anume trebuie măsurat ca să dovedești că cerința e îndeplinită, cerința e prost formulată. „Aplicația să fie rapidă” nu e verificabilă; „orice căutare returnează rezultatul în cel mult o secundă pentru maximum 10.000 de înregistrări” este.

În analiză se stabilesc și datele: ce informații se rețin despre fiecare entitate, ce tipuri au, ce valori sunt permise, ce restricții există între ele. Tot aici se decide modul de stocare — fișiere text, fișiere binare sau bază de date — decizie care influențează direct proiectarea.

Greșeala tipică de proiect școlar este sărirea peste această etapă: elevul începe să scrie cod după cinci minute de gândire, apoi descoperă la jumătatea implementării că structura de date aleasă nu suportă o cerință de bază. Analiza nu e birocrație — e ceea ce împiedică rescrierea de la zero.

La final, analiza se completează cu planificarea: împărțirea muncii pe etape, estimarea timpului și stabilirea reperelor intermediare.

Proiectarea modulară

Proiectarea transformă cerințele în structura concretă a produsului. Metoda fundamentală este descompunerea (top-down): problema mare se împarte în subprobleme, fiecare subproblemă se împarte mai departe, până când fiecare bucată e suficient de simplă cât să fie rezolvată de un subprogram sau de un modul.

Un modul este o componentă cu o responsabilitate bine definită, care comunică cu restul programului printr-o interfață — lista de funcții pe care le oferă și datele pe care le primește. Restul, adică felul în care modulul își face treaba, rămâne ascuns.

Două criterii de calitate a descompunerii, ambele întrebate frecvent:

• coeziune mare în interiorul modulului: toate funcțiile lui servesc același scop. Un modul care se ocupă și de citirea din fișier, și de afișarea meniului, și de calculul mediilor are coeziune slabă.
• cuplare slabă între module: fiecare depinde de cât mai puține detalii ale celorlalte. Cuplarea slabă înseamnă că poți modifica interiorul unui modul fără să atingi restul aplicației.

Avantajele proiectării modulare, în forma cerută la teorie: dezvoltarea se poate face în paralel, de mai multe persoane; fiecare modul se poate testa separat; codul se reutilizează; întreținerea devine posibilă, pentru că o eroare se localizează într-un modul, nu în tot programul.

Tot în proiectare se aleg structurile de date și algoritmii, se stabilește interfața cu utilizatorul și se decid convențiile de scriere a codului: nume sugestive pentru variabile și funcții, indentare consecventă, comentarii acolo unde intenția nu e evidentă din cod.

Confuzia clasică: proiectarea nu înseamnă desenarea interfeței grafice. Interfața e doar o parte; proiectarea privește în primul rând structura internă a aplicației.

Implementarea, testarea și depanarea

Implementarea înseamnă scrierea codului conform proiectului, modul cu modul. Ordinea uzuală e de jos în sus: se scriu întâi modulele de bază, apoi cele care le folosesc, astfel încât fiecare nivel să se poată testa pe date reale.

Testarea verifică dacă produsul se comportă conform specificației. Nu se confundă cu depanarea: testarea descoperă existența erorilor, depanarea le localizează și le corectează. Formularea inversă e capcană sigură la itemii de teorie.

Nivelurile de testare:

• testare unitară — fiecare subprogram sau modul, separat de restul;
• testare de integrare — modulele împreună, verificând că interfețele se potrivesc;
• testare de sistem — aplicația întreagă, față de cerințe;
• testare de acceptanță — făcută de beneficiar, care confirmă că primește ce a cerut.

Alegerea datelor de test este partea în care se pierd cele mai multe puncte la proiecte. Un set bun conține: cazuri obișnuite, cazuri limită (zero elemente, un singur element, valoarea minimă și cea maximă admisă) și date invalide, pentru a verifica reacția programului la intrări greșite. Un program care merge pe exemplul din enunț nu este un program testat.

Tipuri de erori, cu deosebirea esențială:

• erori de sintaxă — semnalate de compilator, programul nici nu se generează;
• erori de execuție — apar la rulare (împărțire la zero, depășirea limitelor unui tablou, fișier inexistent);
• erori de logică — programul rulează și dă un rezultat, dar rezultatul e greșit. Sunt cele mai periculoase, pentru că nimic nu le semnalează automat.

Depanarea folosește urmărirea pas cu pas, puncte de întrerupere, inspectarea valorilor variabilelor și, în lipsa unui depanator, afișări temporare în punctele critice. Regula de aur: se caută prima valoare greșită din execuție, nu ultima — eroarea e acolo unde o variabilă devine incorectă prima dată.

Documentarea, livrarea și întreținerea

Documentația nu este un apendice scris în ultima seară, ci parte din produs. Ea are două destinatare distincte, iar confundarea lor e greșeala tipică:

• documentația de utilizare — pentru cel care folosește aplicația: ce face aplicația, cum se instalează, cum se execută operațiile uzuale, ce mesaje de eroare pot apărea și ce înseamnă. Nu conține cod.
• documentația tehnică — pentru cel care va întreține sau dezvolta produsul: structura modulelor, structurile de date folosite, algoritmii aleși și motivul alegerii, formatul fișierelor, dependențele.

La acestea se adaugă comentariile din cod, care explică de ce s-a făcut ceva, nu ce face linia respectivă — un comentariu care repetă codul e zgomot; unul care explică o decizie neevidentă salvează ore.

Punerea în funcțiune presupune instalarea la beneficiar, transferul datelor existente, configurarea și instruirea utilizatorilor. O aplicație corectă pe care nimeni nu știe s-o folosească este un proiect ratat.

Întreținerea are mai multe forme, utile de reținut distinct:

• corectivă — repararea erorilor descoperite în exploatare;
• adaptivă — adaptarea la un mediu nou (alt sistem de operare, alte formate de date);
• perfectivă (evolutivă) — adăugarea de funcționalități noi și îmbunătățirea performanțelor.

Pe tot parcursul, controlul versiunilor ține evidența modificărilor și permite revenirea la o stare anterioară funcțională — obicei care transformă o greșeală gravă într-un inconvenient minor.

Criteriile după care se evaluează un produs software, la final: corectitudinea (face ce s-a cerut), fiabilitatea (funcționează stabil în timp), eficiența (folosește rezonabil timpul și memoria), utilizabilitatea, portabilitatea și mentenabilitatea (poate fi modificat fără a se strica).

Test — 6 întrebări ca la examen