Ar fi de-a dreptul idilic să aflăm că întocmirea documentaţiei produselor software este o activitate:
- ritmică,
- la timp,
- după reguli,
- voluntară,
- dorită.
Toată lumea ştie că atunci când trebuie întocmită documentaţia, cei ce o fac este ca şi cum ar bea apă cu sare amară. Toată lumea consideră munca de întocmire a documentaţiei ca pe o corvoadă şi o lasă pentru ceasul al XII-lea. Cei ce nu-şi fac notiţe deloc pe durata ciclului de realizare a unui produs software şi se apucă să facă documentaţia din nimic, se trezesc că trebuie să muncească din greu.
Acum, documentaţia nu se întocmeşte la voia întâmplării, căci există standarde şi multe companii de dezvoltare software au deja metodologii de urmat, care sunt foarte stricte. Documentaţia are capitole distincte, are formulare şi textele sunt supuse unui control cantitativ, dar şi unui control calitativ.
Am fost pus în situaţia de a elabora documentaţii chiar în condiţiile în care toată lumea lucra având ca obiectiv realizare sistemului de programe, care avea termen de livrare, documentaţia trebuind livrată şi ceva mai târziu.
S-a muncit din greu, folosind documentaţia rezultată în faza de analiză şi au fost utilizate masiv textele sursă. S-a discutat cu programatorii şi cu greu s-a reuşit să se întocmească o documentaţie care să fie acceptată de beneficiar.
Cu timpul, am trecut la completarea într-un fişier a acelor elemente care mi s-au părut interesante legate de fiecare componentă software la care am lucrat. Am făcut şi însemnări, schiţe, tabele, grafice, dar şi mici texte care să mă ajute la momentul potrivit.
Acum, după experienţa acumulată, consider că documentaţia trebuie construită simultan cu etapele ciclului de realizare a produsului software. Numai după ce se obţine şi forma finită a produsului software este posibilă definitivarea documentaţiei.
Trebuie să existe o concordanţă perfectă între produsul software şi tabelele, graficele, dar şi diagramele din documentaţie. Ar fi nefiresc să apară o descriere de articol în program cu 30 de câmpuri şi în documentaţie să aibă uneori 29 de câmpuri şi alteori 31 de câmpuri sau chiar dacă sunt 30 de câmpuri, în diagrama din documentaţie poziţia câmpurilor să fie diferită de poziţia câmpurilor din articolul descris în programe.
Consider că fiecare programator sau analist sau tester, trebuie:
- să citească cu mare atenţie standardele de întocmire a documentaţiei,
- să le înţeleagă,
- să-şi construiască şabloane de completat pe parcurs,
- să facă însemnări şi schiţe pe măsură ce dezvoltă produsul software,
- să verifice concordanţa dintre însemnări şi componenta software realizată,
- să treacă la elaborarea documentaţiei produsului, numai după ce acesta e considerat încheiat.
Cei mai mulţi programatori, designeri, analişti, testări, implementatori, evită să scrie la documentaţie când produsul software nu este într-un stadiu finit, pentru că ei consideră că trebuie să revină şi să facă ajustări, până ce produsul devine finit. Este adevărat că este şi aceasta o muncă în plus. Totuşi, dacă se fac însemnări, corecţiile sunt destul de simplu de făcut. Dacă avem în faţă un produs finit, este foarte greu să scriem despre el, căci la un moment dat nici nu mai ştim cu ce să începem.
Mulţi dintre cei care au lucrat la un produs software trec să lucreze la alte produse şi este foarte greu ca o singură persoană să întocmească o documentaţie de calitate, fără să existe nişte însemnări cât de cât riguroase, făcute pe parcurs, după nişte reguli. Una este să urmărim o diagramă a algoritmului după care au fost scrise secvenţe de instrucţiuni şi cu totul altfel este să avem în faţă textul sursă al produsului software livrat şi să descifrăm cam ce ar fi trebuit autorul textului să scrie despre algoritm, în condiţiile în care respectivul autor nu este disponibil să se discute cu el.
Cine acordă atenţie cuvenită întocmirii documentaţiei, în aşa fel încât la fiecare etapă de livrare intermediară componenta software să fie însoţită de documentaţia aferentă, creează premise solide ca documentaţia produsului software să devină realitate, nu să fie o himeră, după care aleargă un debutant, pus de şefi să realizeze o sarcină ingrată, aceea de a face documentaţia unui produs software aflat în folosire curentă de câteva luni bune.
Numai reguli stricte de elaborare a documentaţiei vor genera condiţii ca documentaţia să fie de calitate şi să rezulte ca proces de alipire a bucăţilor realizate de diferite persoane care au lucrat la produs, dar care în ceea ce priveşte documentaţia, vorbesc o aceeaşi limbă.
|
