Se poate trece la capitolul următor cu tasta ► și se poate reveni la un capitol precedent cu tasta ◄

Roluri în dezvoltarea unei aplicații


<

C
a
p
i
t
o
l
u
l

a
n
t
e
r
i
o
r

<

Roluri

Precum în arta dramaturgică şi în domeniul informaticii avem parte de roluri. Şi ca în acest domeniu al artei teatrale, dacă fiecare actor îşi joacă bine rolul, piesa va avea succes. Asta dacă idea de bază a piesei e suficient de bună şi implementarea nu lasă de dorit. Exact ca în cazul dezvoltării unei aplicaţii. Mereu mă surprinde corectitudinea paralelor ce se pot face între mai multe domenii.

Analistul

Dar să revenim la lucrurile serioase. Când vine vorba să dezvolţi o aplicaţie pentru altcineva, prima persoană care va apărea pe scenă va fi analistul. El are nefasta şansă uriaşa onoare de a fi persoana care se întâlneşte cu clientul şi discută despre ce va trebui aplicaţia să conţină, care sunt funcţiile pe care trebuie să le îndeplinească; trebuie să înţeleagă cum funcţionează domeniul clientului şi să fie extrem de enervant diplomat punând o mulţime de întrebări clarificatoare.

La prima mână, nimica nu pare să ceară atâta efort însă până şi cea mai simplă problemă, aceea de a calcula suma a două numere, poate crea dificultăţi ( Ce fel de numere? Întregi, reale, cu câte zecimale, cu ce aproximaţie, de unde sunt luate? Le scrie cineva la tastatură? O maimuţă cu puterea minţii şi le imaginează? Sau poate e un test pentru cobai ce implică multe echipamente și fire electrice ). Poate de aceea cuvântul analist cuprinde termenul „anal” cu semnificaţia din limba engleză de a fi enervant. Una peste alta, pot spune din experienţa mea că aceştia sunt destul de huliţi. Sau poate eu am un mod enervant de a face pe analistul.

Proiectantul

După ce analistul îşi face treabă şi strânge toate informaţiile, obosit şi sătul, le aruncă în braţele proiectantului. Şi pleacă. Departe. Acum proiectantul, care e un fel de Dumnezeu local, se pune pe treabă. El se ocupă de transformarea din limbajul comun în entităţi şi tot ce are sens pentru a face o aplicaţie pe un sistem informatic. Sună pompos însă nu toate aplicaţiile sunt făcute pentru a fi folosite pe calculatoare personale. Telefoanele mobile au şi ele aplicaţii. Şi sunt aproape convins că şi avioanele au aplicaţii şi în cabină nu am văzut să fie PC-uri sau laptop-uri. De fapt ştiu sigur că e interzis să foloseşti telefoane mobile şi laptopuri într-un avion.

El se ocupă cu proiectarea (vedeţi ce am făcut aici? Proiectantul proiectează) bazelor de date, cu împărţirea aplicaţiei în sub-aplicaţii şi multe alte lucruri pe care dacă le detaliez aici îți va face mintea să devină foarte confuză, foarte rapid. O să ajungem şi acolo.

Programatorul

După ce totul e zis şi, mai ales, făcut de proiectant, acesta dă rezultatul programatorului şef. El e un fel de... Mai bine nu zic. El împarte munca programatorilor de sub „comanda” sa şi în mare parte nu face altceva. Bineînţeles că poate şi el să lucreze, sunt sigur că mulţi o fac, dar, personal, dacă aş atinge nivelul ăsta, nu aş sta să-mi bat capul prea mult. Nu cu lucrurile simple.

Abia acuma am ajuns la programarea efectivă. Planificarea are un rol major la dezvoltarea unei aplicaţii de orice fel. Poţi scrie cod fără să faci nici o analiză şi nici o proiectare, şi de multe ori aşa se şi întâmplă, iar rezultatul poate avea forme diverse, de la amuzante la tragice. „A scrie cod” e o expresie asociată cu o muncă uşoară pe care oricine o poate face. Nu sunt de acord cu aceasta, am văzut multe persoane de-a lungul anilor care nu au nici un interes de a programa. Nu că nu ar putea, doar că... motive, motive. Şi e în regulă. Nu toată lumea trebuie să fie programator, sunt atâtea discipline din care poți învăța și face foarte multe lucruri. Însă dacă calculatoarele te intrigă, mai târziu sau mai devreme, vei învăța să le programezi.

Testarea

Dar să revenim. După ce toate etapele acestea au fost parcurse, următorul pas e făcut de testeri. Niciodată nu m-am simţit bine spunând tester (la singular). Întotdeauna m-am gândit la ei ca la un stol. Ca la lăcuste. De fiecare dată când vezi doar una te întrebi unde îi sunt suratele. Aşa sunt şi testerii: vin întotdeauna în numere mari, dau năvală prin munca ta şi lasă praf şi pulbere în urma lor. Şi ăsta e un lucru bun căci rolul lor este de a face cu aplicaţia orice lucru dăunător posibil. Şi sunt cărţi întregi despre cum poţi face o testare. Ei trebuie să facă pe tipul ăla gras și dezinteresat care în loc să apese o tastă, apasă șapte; ăia care nu citesc instrucţiunile de folosire căci „ştiu ei cum funcţionează chestia asta”, dar şi să caute nod în papură în părţi ale aplicaţiei pe care nimeni, niciodată nu le va folosi.

Şi, repet, e bine căci sunt plătiţi de aceaşi firmă. Sau sunt oameni care sunt entuziaşti faţă de ceva aplicaţie şi ajută la testarea ei. µTorrent lansează versiuni BETA pe forum-ul propriu, de pe urma cărora dezvoltatorii primesc răspunsuri de la utilizatori. Personal mi se pare o alegere leneşă, dar rezultatul e bun, costurile probabil mult mai reduse şi, hei, e mai bine decât în cazul Windows 98-ului.

În momentul ăsta au loc o mulţime de schimburi de informaţie (şi de scântei) între testeri şi progamatori şi cine afirmă că cele două grupuri se înţeleg e un mare mincinos! De ce? De fiecare dată când ceva nu merge bine, e retrimis către programatori, iar ei trebuie să îl repare. Însă nu întotdeaună „ceea ce nu merge bine” e exprimat corect. Există standarde pentru a raporta un defect, dar în momentul când testarea se face de public, totul capătă o altă conotaţie. Un indiciu: Benny Hill.

Mentenanța

După ce aplicaţia e finalizată şi standardele de calitate sunt îndeplinite (sau nu - Windows Millenium), aplicaţia e dată spre folosire şi întreţinută. Aici intervine rolul de întreţinere. E un pic ciudat fiindcă întreţinerea ar trebui făcută de aceleaşi persoane care au construit-o, însă de un număr de ori e făcută de o firmă din India sau România. Şi nu am întâlnit încă un caz de întreţinere care să decurgă cu bine (de fapt acum îmi amintesc dar e doar un singur caz) atunci când e făcută de altcineva decât de echipa iniţială. Desigur, este o parte serioasă şi un rol care la rândul său cuprinde oameni care fac tot ce am descris până aici. Însă e foarte costisitor. E nevoie de timp ca o altă echipă să înţeleagă cum a fost gândită aplicaţia iniţial ca apoi să o modifice.

Documentația

Un ultim rol, care preferabil să fie de sine stătător, este cel al responsabilului de documentaţie. Un cuvânt care doreşte să cuprindă toată hârţogăria (virtuală sau pe hârtie) scrisă de la analist până la utilizatorul final. Partea bună e că totul e standardizat. Partea prostă e că nu am văzut şi nici nu am auzit de oameni care să facă doar acest lucru. De obicei fiecare îşi face propria documentaţie după cum se pricepe.

În companii mari rolurile acestea se respectă chiar dacă nu şi terminologia. Totuși lucrurile sunt cât se poate de serioase. Până la urmă, nu am fi aici ca civilizaţie dacă totul ar fi fost făcut prost.

Recapitulând avem în total 6 roluri majore:

  • analist
  • proiectant
  • programator(i)
  • testeri
  • mentenanţă
  • documentaţie

Indiferent de aplicaţia pe care o facem, trecem prin cel puţin 4 roluri: analist, proiectant, programator şi tester. Uneori (la început) sărim direct în rolul de programator şi începem să scriem cod și e în regulă. Însă când cerinţele problemei sunt suficient de încâlcite, obligatoriu o luăm pe drumul descris aici.


>

C
a
p
i
t
o
l
u
l

u
r
m
ă
t
o
r

>

Ți-a fost de ajutor ce am scris aici?
Hei, mersi de răspuns.