Omogenitatea se manifestă peste tot ceea ce înseamnă proiect de realizare a unui produs software. Echipa de dezvoltare trebuie să fie omogenă din punct de vedere al:
- calificării,
- experienţei,
- performanţei,
- calităţii livrabilelor,
- nivelului de exigenţă,
- gradului de asumare a responsabilităţilor,
- modalităţilor de comunicare,
- instrumentelor utilizate.
Componentele produsului software trebuie să fie omogene prin:
- limbajul utilizat,
- structurile de articole definite,
- tipurile de operatori,
- stilul de programare folosit,
- seturile de date de test utilizate,
- instrumentele de asistare,
- indicatorii de măsurare a calităţii,
- procedurile de culegere a datelor,
- nivelul de autodocumentare a componentelor.
Omogenitatea va avea drept rezultat un produs software format din componente care nu diferă semnificativ ca:
- nivel de calitate,
- tehnologii utilizate,
- stil de programare,
- mod de derulare a etapelor ciclului de dezvoltare,
de parcă ar fi fost realizat de un singur programator sau de un singur analist, ceea ce înseamnă că managerul de proiect a avut din start ca obiectiv realizarea unui produs software omogen din toate punctele de vedere.
Eu mă gândesc la măsurarea omogenităţii cam în felul următor:
- detaşamentul de gardă de la prezident trebuie să fie format din tineri omogeni ca înălţime,
- se stabileşte ca înălţime optimă 185 cm,
- se stabileşte prin completarea de formulare cam care este diferenţa în plus sau minus, de înălţime care să nu fie sesizabilă cu ochiul liber, adică să nu deranjeze,
- se fac calcule statistice şi rezultă că variaţiile sunt de cel mult 2 cm în plus sau în minus,
- intervalul va fi de 4 cm,
- înălţimea minimă va fi 183 cm, iar înălţimea maximă va fi 187 cm,
- dacă parametrul de măsurat este cu valoare medie X, atunci lungimea intervalului este 0,02*X iar nivelul minim acceptat va fi 0,99*X şi nivelul maxim acceptat va fi 1,01*X.
statistica vorbeşte de omogenitate în alţi termeni, dar noi va trebui să fim pragmatici, fără a face exagerări care să ne ducă la imposibilitatea de a conchide că am făcut un produs omogen, deşi a fi prea exigent nu este lucrul cel mai bun în ziua de azi, dar frica păzeşte bostănăria. *******************************************
*******************************************
Omogenitatea modulelor din produsul software Prin omogenitate nu vom înţelege altceva decât:
- utilizarea aceluiaşi stil de programare,
- folosirea aceloraşi nume de variabile pentru aceleaşi câmpuri din articol,
- asigurarea corespondenţei perfecte între listele de parametri formali şi cei reali,
- folosirea la maximum a procedurilor din biblioteca organizaţiei,
- respectarea structurii de prezentare a comentariilor din textele sursă,
- dispunerea blocurilor în pagină pentru a face lizibil textul.
Este bine ca produsul software să fie alcătuit din module omogene pentru că:
- forţa de muncă este fluidă şi anumite module neterminate trebuie continuate de alţii,
- procesul de mentenanţă se face de alte persoane decât cei ce au scris modulele,
- folosind un stil de programare bun, modulele sunt cu acelaşi nivel de calitate,
- asamblarea modulelor u mai ridică probleme mari căci se respectă un minim de reguli,
- productivitatea muncii este mărită din moment ce comunicarea între programatori e simplă.
Multă lume crede că omogenitatea înseamnă monotonie. Dacă se vrea elaborarea de produse software în regim industrial, omogenitatea este caracteristica esenţială, iar programatorii ca şi designerii trebuie să facă tot ce depinde de ei pentru a face module omogene:
- folosind acelaşi limbaj de programare,
- utilizând cam aceleaşi structuri de expresii cu operatori condiţionali şi logici,
- referind după aceeaşi regulă procedurile,
- structurând după aceeaşi regulă listele de parametri,
- construind blocurile în acelaşi fel,
- folosind aceleaşi funcţii de bibliotecă,
- regrupând instrucţiunile în secvenţă după aceeaşi regulă.
Dacă toate acestea se vor respecta, se creează senzaţia că toate modulele au fost scrise de un acelaşi programator.
Acum mulţi ani am încercat să implementez câteva reguli încât mai mulţi programatori la început de carieră să rezolve o aceeaşi problemă. Am lăsat pe respectivii să scrie programe pentru aceeaşi problemă, respectând aceleaşi reguli. La final, am observat că programele lor erau foarte asemănătoare, ca lungime, ca nivel de complexitate şi mai ales, punându-i pe fiecare să citească programul scris de altul şi efortul de înţelegere a fost minim. Mai mult, existenţa regulilor face ca productivitatea muncii a acestora să fie foarte bună ca nivel.
Omogenitatea apare şi din faptul că structurile create au reguli unice. Dacă se folosesc liste simple, să se folosească liste simple. Dacă structura este arborescentă, desenul ei să arate că arcele de la componente respectă aceeaşi regulă, iar revenirile nu se fac cu lopata, aşa cum se întâmplă pe la site-urile mioritice unde chiar că revenirile sunt ala-n dala sau modulele sunt fără revenire, ci sunt suspendate, de parcă sunt făcute de inşi cu creierul cât nuca, creier care sună rău într-o tigvă neocupată decât în mică măsură. Programatorii sunt persoane care acceptă cu dificultate să se încadreze în reguli pentru că ei consideră că nu este de bon ton să intre într-o turmă şi să lucreze ca nişte roboţei, adică, altfel spus, programatorii nu acceptă să fie disciplinaţi, că ei ca orice artişti sunt boemi, poeţi, creativi şi geniali în felul lor, deci nu scriu programe omogene, ceea ce le dă un aer vetust şi uneori eroic sau epic.