Se zice că dacă un halterofil este la punctul maxim al efortului, dacă pe haltera lui se aşează o muscă, îl va doborî. Tot aşa este şi în ceea ce priveşte distrugerea calităţii unui produs software. Nu trebuie făcut un efort foarte mare. Să zicem că avem o linie sursă în care se calculează o expresie aritmetică ceva mai complicată, de fapt este vorba de a împărţi două subexpresii aritmetice una la alta. Doar lipsa unui test ce priveşte numitorul va duce programul de răpă, căci o împărţire prin zero, dacă nu este gestionată prin program, deja nu e o chestiune care să facă plăcere niciunui client care tocmai face o afacere la bursă sau o tranzacţie bancară. Nimeni nu vrea să distrugă calitatea unui produs software cu intenţie. Numai că, prin modul defectuos de a lua decizii şi prin modul aiuritor de a acţiona, tocmai se distruge calitatea.
Cei ce pleacă de la idei preconcepute în a construi un produs software, crezănd că experienţa este de partea lor, apucă să acţioneze pe căi greşite şi vrănd-nevrănd, distruc galitatea produsului pentru că:
- folosesc resurse neadecvate,
- uită detalii semnificative,
- se grăbesc şi sar etape,
- nu comunică suficient,
- merg în virtutea inerţiei,
- evită să ţină seama de progresele din domeniu.
Pentru orice etapă a ciclului de realizare a produsului software se găsesc cel puţin un milion de modalităţi de a distruge calitatea produsului. Nu trebuie nici un efort pentru a le enumera pe primele 500.000 de modalităţi care sunt la îndemăna noastră şi care nici nu costă vreun ban pentru a le pune în operă.
Dacă sărim una din etapele ciclului de realizare a produsului software, chiar distrugem calitatea. Fără o analiză temeinică nu există produs software bun, dar fără o analiză căt de căt, produsul software se construieşte aproximativ, după ureche şi aleatoriu, ceea ce nu duce spre nici o finalitate rezonabilă. Fără etapa de scriere de cod, cu siguranţă că va exista un produs software obţinut ca derulare a unui proces de copy-paste, aşa cum se mai întămplă la cei ce preiau integral produse open source şi le prezintă ca fiind operele lor.
Nici nu vreau să mă găndesc cam cum arată calitatea unui produs software pentru care s-a sărit de etapa de testare. Este adevărat că fiecare membru al echipei îşi testează componenta realizată, dar o face în felul său. Nu înseamnă că dacă toate componentele au fost testate excelent, produsul va funcţiona excelent. Cu siguranţă că produsul netestat va avea probleme, căci distrugerea calităţii sale s-a făcut prin simpla eliminare a etapei de testare, cănd dacă era folosit un set reprezentativ de date de test, ar fi scos la iveală nişte disfuncţionalităţi, care ar fi fost corectate, desigur. Sărind testarea, utilizatorii vor fi puşi faţă-n faţă cu tot felul de erori sau de întreruperi, ceea ce le va zdruncina încrederea în produs, pănă la abandonarea produsului software, căci, vorba proverbului, are balta peşte, adică se găsesc în tărg nenumărate alte produse software similare, cu mult mai bune.
Ideea de bază este ca dezvoltatorii să nu distrugă calitatea produselor lor, iar clienţii să nu distrugă datele de intrare, căci numai un produs software de calitate, care utilizează date de intrare de calitate va furniza rezultatele aşteptate de client, adică acele rezultate complete, corecte şi în timp util.
|