Erorile utilizatorului

Erorile utilizatorului sunt numeroase în interacțiunea sa cu programul și acestea se resimt acum în mediul online cel mai mult. Programele cele mai puternice sunt construite în așa fel încât:

- atenționează pe utilizator prompt că a greșit la introducerea datelor;

- efectuează automat corecții și cere acordul utilizatorului;

- propune valori introduse anterior de utilizator și acesta alege.

Am văzut programe care nu fac așa ceva și atunci când a terminat și utilizatorul apasă butonul SEND îi apar tot felul de mesaje de omul săracul de el se ia de cap. Eu cred că era mai bine dacă introducea data nașterii i se valida că nu este corect să scrie 34.15.-1900 căci luna are cel mult 31 de zile, anul are cel mult 12 luni, iar an negativ n-am prea pomenit. Dacă la introducerea datei i se oferă posibilitatea de a selecta din cele trei seturi de variante corelând chiar lunile era excepțional. Se știe că la  numărul cardului trebuie introduse 16 cifre, drept care la trecerea către un câmp următor, utilizatorul trebuie atenționat că are mai puțin de 16 cifre. dacă este tentat să introducă altceva decât cifre acest lucru să nu fie posibil. În plus, există o cifră de control ce se calculează, drept care i se va spune utilizatorului că cele 16 cifre ale lui nu sunt număr de card. Scriu toate acestea că am interacționat cu aplicații așa de proaste încât chiar am avut probleme, iar băncile nu iartă deși greșeala era le ele în curte.

Cel mai tare program în vremurile de demult era acela care nu-l ierta pe client și-i semnala orice eroare, mai ales că acesta pierdea timp. De fiecare dată trebuia să-și perforeze cartelele cu date corecte și să ducă încă și încă o dată programul la dispecerat pentru a-i fi rulat.

Să nu uităm că în FORTRAN era cartela FORMAT care spunea clar în ce coloane ale cartelei trebuie perforat câmpul. Dacă programatorul deplasa aiurea numărul mai la stânga sau mai la dreapta, nu se făceau conversiile de azi și erorile de citire a datelor curgeau gârlă. Acum se citesc datele ca șiruri de caractere, se fac validări, se fac alinieri, se fac conversii și micile erori se trec cu vederea prin mărinimia programatorului.

Pe vremuri componentele de validare erau esențiale și se testau:

- caracterul numeric;

- apartenența la un interval;

- apartenența la o mulțime;

- caracterul alfabetic;

- codurile identice;

- corectitudinea codului prin calculul cifrei de control;

- dacă numărul este pozitiv;

- dacă numărul este divizibil prin ceva;

- dacă numărul este prim.

La un moment dat programatorii scriseseră programe de validare și parametrizând câmpuri reuțeau să nu mai se obosească cu scrisul de secvențe. Cartelele se rulau cu acel program și rezulta noianul de erori. Programatorul uneori sau utilizatorul cel mai adeasea făceau corecțiile și se rula efectiv programul dacă nu erau erori.

Programul era de-a dreptul puer dacă mai făcea și teste în interior și semnala erori pe care o validare de doi bani oricât de sofisticată ar fi fost nu era în stare să le scoată în evidență. Să ne amintim de grafurile care aveau noduri ce nu se legau cu nimic. Să ne amintim de articolele care nu sunt utilizate în niciun fel. Se ne amintim de optimizările sau de calculul cu iterații care nu se mai sfârșesc. Toate acestea trebuie marcate prin erori ale programului. Mî gândeam la replica lui Gheorghe DINICĂ din filmul Filantropica:  mâna întinsă care nu spune o poveste nu primește pomană. Fii profesionist, ce dracu! Acela nu este un program, dacă nu se încheie cu mesaje proprii și nu semnalizează toate erorile.
Erorile utilizatorului sunt nenumărate, iar utilizatorul este cel care decide soarta programarul este bun sau prost. Utilizatorul dă vina pe alții, deci pe programator și atunci când el a definit incorect datele, iar programul nu-i arată erorile din date, din superficialitatea programatorului, care a crezut și crede că toți sunt ca el.

(01 decembrie 2017)

Erorile de programare

Erorile de programare sunt nenumărate. Nu există activitate în scrierea programelor care să nu fie bântuită de erori.

Există mai multe criterii de clasificare a erorilor de programare, înțelegând aici doar activitatea desfășurată de programatori și nu și activitățile de analiză, de testare, de elaborare a documentației.

După criteriul nivelului de severitate se identifică:

- erori care deși sunt făcute, programul intră în execuție și rezultatele sunt complete și corecte;

- erori de logică, care duc la obținerea de rezultate uneori corecte, alteori incorecte;

- erori care duc la întreruperea execuției programului după efcetuarea parțială a prelucrărilor;

- erori din cauza cărora programul nu trece de compilare;

- erori din cauza cărora programul nu trece de editarea de lebături;

- erori în cartelele de comandă și se obține doar o mică fâșioară de hârtie.

După tipul erorilor se identifică:

- erori sistematice făcute de programator că neglijează exact mereu același lucru;

- erori întâmplătoare din faptul că uită ceva din definiri sau din formulele de calcul.

După cauzele care produs erorile de execuție se identifică:

- erori de alegere a tipului în raport cu utilizarea;

- utilizarea de variabile nedefinite;

- depășirea domeniului de definire a structurilor la derularea secvențelor repetitive;

- lucru cu variabile neinițializate;
- ciclarea infinită din neinițializarea variabilei de control;
- expresii condiționale care fac selecții incomplete;
- neconcordanțe între listele de parametri ai procedurilor;
- împărțirea la zero.
După locul unde s-au produs erorile se identifică:
- erori de definire a problemei;
- erori de elaborare specificații;
- erori de construire a soluției;
- erori de scriere a textelor sursă;
- erori de testare mai ales incompletă;
- erori de elaborare a documentației;
- erori de implementare;
- erori de utilizare;
- erori de mentenanță.
A porni de la efect la cauză este singura modalitate de a face depanare. Dacă se dorește să se facă depanare eficientă trebuie să se facă și calcule de probabilități ca la stabilirea diagnosticelor în medicină, mergând de la efect spre cauza cu probabilitatea cea mai mare. Rând pe rând se trece la cauzele cu probabilități mai mici, dar în niciun caz nu se va merge din start pe cauza cu probabilitatea cea mai scăzută de producere a erorii.
Acum mulți ani am scris un articol după ce au fost făcute statistici ale erorilor de programare, analiza fiind foarte utilă în creșterea eficienței procesului de depanare a programelor referit prin : Al. Balog, A. Ivan, M. Macesanu - Analiza statistică a erorilor specifice produselor-program, Revista de statistică nr. 10/1985, Bucureşti, pg. 27-37.

(28 noiembrie 2017)

Efectul de ondulanță în programare

Numai cine nu muncește, nu greșește. De când mă știu eu programator o singură dată mi s-a întâmplat să scriu un program destul de lunguț, să-l compilez și din prima a fost fără erori de compilare, apoi al trecut la editarea de legături și acolo a fost OK, iar la execuție, nu-mi venea să cred, toate seturile de date de test au trecut cu brio. Făcusem un program care a mers din prima. M-am uitat și l-am verificat încă și încă pentru că nu credeam că așa ceva este posibil. Mai mult, nu lucrasem pe el mai mult ca pe alte programe, ci normal. Dar așa a fost să fie. Era un accident.

În programele mele am avut:

• erori de compilare cu diferite cauze, unele ale mele, altele din cauza perforării căci mai încurcam pe zero cu litera o sau una defineam ca variabile și alta refeream în virtutea inerției. Au fost și situații când la perforare punctul cu care se încheiau instrucțiunile COBOL a fost perforat ca virgulă și totul s-a dus de râpă. Alterori am folosit variabile nedefinite sau nedeclarate sau am utilizat etichete care erau altfel date în prealabil sau pur și simplu nu erau definite;
• erori de editare de legături destul de frecvente căci solicitam eu resurse care nu erau definite sau programul după compilare când trecea la editarea de legături identifica neconcordanțe ce determinau întreruperea procesului de editare; învățasem pe dinafară ce nu trebuie să fac astfel încât să nu-mi apară erori de linkage editor, destul de greu de localizat mai atunci când erau chestiuni de rafinament la transferul de parametrii cu consecințele ce decurg din toate neconcordanțele de tip, de lungime sau de ordine în listă;
• erori de execuție cu nenumărate cauze care aducerau mare tristețe mai ales atunci când din cauza neconcordanței dintre ceea ce era perforat în cartele și formatele după care se făceau citirile, mă trăgeau de urechi cu câte un mesaj neplăcut; nici situațiile de conversii aiuritoare de la citirea aleatoare de câmpuri se răsfrângea după principiul unde dai și unde crapă asupra muncii mele de programator chinuit și cu frică de Dumnezeu;
• erori de logică, erori de care m-a ferit Cel de Sus pentru că nu începeam să scriu nicio linie sursă fără să fia avut clar despre ce era vorba; Eram cam pisălog, dar știam că dacă mă apuc să scriu un program fără să am clar ce trebuie să fac și fără să fi înțeles algoritmul, dacă îmi dădeam seama de greșeala de logică fie mai devreme, fie mai târziu, nu trebuia să fac corecții în program, ci să-l iau de la capăt, căci a cârpi ceva profund greșit duce la o construcție care oricum trebuie abandonată.

În tinerețea mea, m-am apucat și am studiat sistematic erorile de programare și am scris și oarece articole pe această temă, referite prin:

• Ion IVAN, Alexandru BALOG, Andrei GOGA, Marian MACESANU - Analiza statistica a erorilor specifice produselor - program, Revista de Statistica, vol. 34, nr. 10, 1985, pg. 27 - 37
• Ion IVAN, Cristian AMANCEI - Stabilitatea coeficientilor modelului global de calitate software, teorie, practica, experimente, Editura ASE, Bucuresti 2006, 172 pg.
• Ion IVAN, Adrian PÎRVULESCU, Paul POCATILU  - Software Quality Verification Through Empirical Testing, Journal of Applied Quantitative Methods, vol. 2, nr. 1, 2007, pg. 38 - 60.

Împreună cu Alexandru BALOG am dezbătut foarte mult fenomenele legate de fluctuațiile erorilor din programe și care se studiază generic sub denumirea de efect de ondulanță, identificând situațiile în care evoluția erorilor se comportă asemeni undelor amortizate, ceea ce este excelent pentru că programtorul speră ca erorile din programul său să scadă până la dispariție. Când erorile se comportă ca undele neamortizate și cresc în frecvențe, deja înseamnă că programul are o gravă problemă și programatorul a intrat în panică și în loc să repare, mai mult strică. Atunci trebuie făcută o schimbare majoră, în ideia asistenței dată de un alt programator cu experiență care va găsi rapid remediul situației care tinde să scape de sub control.
Efectul de ondulanță în programare este exemplul clar de translatare a conceptelor din fizica undelor electromagnetice către ingineria software și către tehnicile de depanare eficiente, pe care niciun programator nu trebuie să le neglijeze, dar pe care trebuie să le cunoască tocmai pentru a face programe cât mai bune.

(22 noiembrie 2017)