PROGRAMUL DE STUDIU : MANAGEMENTUL TEHNOLOGIEI [629403]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA
INFORMAȚIEI
PROGRAMUL DE STUDIU : MANAGEMENTUL TEHNOLOGIEI
INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT : CU FRECVENȚĂ

MANAGEMENTUL UNOR
APLICAȚII DE MONITORIZARE
A REȚELELOR DE
SOCIALIZARE

COORDONATOR ȘTIINȚIFIC
Prof. dr. ing. CORNELIA GYŐRÖDI

ABSOLVENT: [anonimizat]
2017

1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……. 3
1.1. Prezentare generală ………………………….. ………………………….. ………………………….. ………………. 3
1.2. Scopul proiectului ………………………….. ………………………….. ………………………….. ………………… 4
2. Organizarea proiectului ………………………….. ………………………….. ………………………….. ……………….. 5
2.1. Modelul de proces ………………………….. ………………………….. ………………………….. ………………… 5
2.2. Structura organizatorică ………………………….. ………………………….. ………………………….. ………… 9
3. Procesul de management ………………………….. ………………………….. Error! Bookmark not defined.
3.1. Obiective ………………………….. ………………………….. …………….. Error! Bookmark not defined.
3.2. Managementul riscului ………………………….. ………………………. Error! Bookmark not defined.
3.3. Monitorizarea și controlarea procesului de dezvoltare ……….. Error! Bookmark not defined.
3.4. Planul de marketing ………………………….. ………………………….. Error! Bookmark not defined.
4. Procesul tehnic ………………………….. ………………………….. …………… Error! Bookmark not defined.
4.1. Decizii tehnice ………………………….. ………………………….. ……… Error! Bookmark not defined.
4.1.1. Baze de date ………………………….. ………………………….. ….. Error! Bookmark not defined.
4.1.2. T ehnologii frontend ………………………….. …………………….. Error! Bookmark not defined.
4.2. Prezentarea aplicației ………………………….. ………………………… Error! Bookmark not defined.
Concluzii ………………………….. ………………………….. ………………………. Error! Bookmark not defined.
Bibliografie ………………………….. ………………………….. …………………… Error! Bookmark not defined.

1. Introducere
Principala caracteristică a unui proiect de succes este planificarea bună și din timp. Cu toate acestea,
problema principală pe care o întâlnim în IT nu este lipsa planificării ci mai degrabă provocarea pe
care o prezintă înțelegerea unor procese complexe de business. Abordarea populară este de a separa
IT-ul de zona de business, cu toate că această separare duce, în anumite cazuri, la tensiune provenite
din neînțelegerea industriei cu care lucrăm. Astfel, în cele ce urmează vom descrie un nou stil de
manag ement, având în rolul principal un manager de proiect al cărui rol clasic se extinde pentru a
include responsabilitate mai mare și o bază de cunoștințe care reflectă cerințele industriei. De
asemenea, vom vehicula ideea de a forma o echipă de programatori generaliști, în detrimentul
programatorilor care sunt specializați pe o singură tehnologie. Vom sublinia importanța formării unei
echipe cu cunoștințe în domeniul pentru care se dezvoltă proiectul.

1.1. Prezentare generală
Implementarea cu succes al proiectelor IT prezintă o provocare continuă și având în vedere importanța
sistemelor tehnologice, acestea pot prezenta un risc major eșec, putând astfel chiar distruge o
companie. Proiectele IT sunt mult mai predispu ne la riscul de a eșua decât s -a prevăz ut, iar motivația
din spatele acestui lucru îl reprezintă mediile foarte schimbătoare – schimbările pieței, ale
reglementărilor guvernamental și alte cerințe într -o organizație necesită revizii constante al sistemelor
tehnologice care îngăduie buna funcțio nare a afacerii. Este de la sine înțeles că riscurile asociate cu
reviziile acestor sistemele sunt profunde, dovadă fiind faptul că în IT eșecurile proiectelor încă sunt
în creștere [1]. Pe de altă parte, multe dintre studii examinează achiziția de cunoști nțe și împărțirea
cunoștințelor de business în proiectele IT, iar constatările acestora au scos în lumină importanța lipsei
de cunoștințe a business -ului de către profesioniștii IT. Managerii responsabili de aceste proiecte sunt
foarte frecvent puși în poz iția de a trece peste provocarea de a rezolva atât cerințe IT cât și de business,
iar ca aceștia să poată să rezolve eficient și în mod corect aceste probleme, evident, au nevoie de
cunoștințe în ambele zone. Aceste activități ale mangerului, foarte diferi te, creează tensiuni, principul
motiv fiind obiectivele incompatibile având nevoia de a fi eficient, de a evita greșeli, dar și de a atinge
obiective pe termen scurt și de a se păstra suficient de flexibil pentru a se putea ajusta la situațiile
nesigure ra pid. Un exemplu foarte bun este cel al unei sonde de pe Marte care a fost proiectată pentru
a primi și stoca noi instrucțiuni. În timp, memoria de stocare a început să devină din ce în ce mai
puțină, astfel managerul de proiect a fost confruntat cu o dilem ă majoră: cu cât se rezolvă mai repede
problemă, cu atât se poate continua mai repede acumularea de date. După ce se realizează că modulul
de aterizare ar elibera un spațiu de memorie suficient de mare și că nu mai este nevoie de acest modul,
având în vede re că sonda nu va mai ateriza, a fost trimisă o instrucțiune pentru a șterge acest modul.

Prin consecință, contactul cu această sondă a fost pierdut deoarece capacitatea de navigație celestială,
necesară modulului de aterizare pentru scopul aterizării, era indispensabil pentru a îngădui
comunicarea adecvată. Sonda de pe Marte a fost pierdută pentru totdeauna. Presiunea de a atinge un
obiectiv business (furnizarea de noi instrucțiuni pentru a strânge noi informații) înseamnă alegerea
unei soluții „suficient de bune” ceea ce favorizează atingerea obiectivelor pe termen scurt (eliberarea
spațiului de stocare prin ștergerea modulului de aterizare); cu toate acestea „suficient de bun”
înseamnă că vom avea timp, efort și resurse insuficiente focusate pe livrarea u nei soluții de calitate și
pe termen lung (testare bună a sistemului, implicații pentru business etc.). Acest lucru se mai numește
și tensiune paradoxală [2] și se definește ca fiind elemente interdependente dar contradictorii care
există simultan și persi stă în timp [3].

Având aceste exemple și cercetări în minte se dorește dezvoltarea unui produs de monitorizare rețele
de socializare al cărui management îi poate oferi cele mai bune șanse de succes. Produsul se numește
ChatterBox Monitoring și a fost crea t cu gândul la simplificare vieții sociale online a unei companii.
Ținta principală sunt companiile mari ale căror rețele de socializare sunt active mereu, fiind astfel
foarte greu de gestionat și urmărit. Însă acest produs nu -i exclude nici pe cei ai căro r companie este
încă în creștere – monitorizarea rețelelor de socializare încă de la începuturi oferă grafice și prognoze
de activitate acurate. Lucrarea dorește să se focuseze pe alegerile de management pentru a dezvolta
aplicația cu succes, pe deciziile mai neortodoxe. Concluziile vor reflecta cunoștințele acumulate după
trei ani de dezvoltare al produsului.
1.2. Scopul proiectului
Scopul proiectului de a prezenta o nouă abordare de management care favorizează atât afacerea, cât
și dezvoltatorii și care, deși nu asigură, oferă o șansă mai mare de succes. Ideile prezentate nu sunt
mereu idei noi, ci mai degrabă idei foarte bine testate în alte domenii, dar care se pot aplica cu succes
și în IT. Capitolul 2 și 3 vor prezenta organizarea proiectului și proces ele de management aplicate,
mai apoi în Capitolul 4 se va vorbi despre deciziile tehnice din proiect și cum abordarea de
management favorizează cercetarea. În final vom prezenta concluziile trase după dezvoltarea
proiectului.

2. Organizarea proiectului
Ingineria software este o activitate deosebit de complexă. Ea implică interacțiuni între persoane,
procese și instrumente pentru dezvoltarea unui produs. În practică, dezvoltarea unui produs software
este făcută de către echipe formate din zeci și chiar ze ci de mii de oameni, iar aceștia la rândul lor
lucrează conform unei structuri organizatorice . Cercetările făcute pentru a găsi o corelație între felul
în care este afectată calitatea produsului și structura organizatorică , au relevat că într -adevăr aceast ă
din urmă este un indicator bun pentru posibilitatea unui eșec [4]. Din acest motiv , în cele ce urmează
vom explora diversele modele de proces existente și mai apoi modelul de proces ales, c ât și structura
organizatorică potrivită pentru un produs softwar e de asemenea amploare.
2.1. Modelul de proces
Un model de proces în dezvoltarea unui software este o reprezentare abstractă al unui proces. Acesta
prezintă o descriere a unui proces din mai multe perspective, cum ar fi: specificații, design, validare,
evoluție

Există mai multe modele generale de proces, cum ar fi: modelul cascadă (Waterfall), dezvoltarea
evoluționară , dezvoltarea bazată pe reutilizare etc. În urma cercetărilor făcute, pentru aplicația care
se dorește a fi dezvoltată, focusul a fost pe urm ătoarele modele:
▪ Modelul cascadă;
▪ Modelul iterativ;
▪ Modelul spirală .

Modelul Cascadă (Waterfall)
Modelul cascadă este considerat un model clasic în ingineria software. Este unul dintre cele mai vechi
modele și este foarte utilizat în proiecte de stat și î n multe companii mari. În acest model accentul
pică pe planificarea în stagiile preliminare și expune posibilele defecte de design înainte ca ele să fie
dezvoltate. Pe lângă toate acestea, faptul că implică documentație și planificare intensă îl face să fi e
foarte potrivit pentru proiecte în c are controlul calității este de maximă importanță.

Modelul cascadă pur constă în mai multe stagii care nu se suprapun, după cum se poate observa în
Figura 2.1.1. Modelul începe prin stabilirea cerințelor de sistem și software și se continuă cu design –
ul arhitectural, proiectarea detaliată, dezvoltarea, testarea și într -un final, mentenanța. Modelul
cascadă constituie baza a multor modele.

Figura 2.1.1. Modelul cascadă [5]

Pentru u tilizarea acestui modelul, trebuie să efectuăm următorii pași:
▪ Cerințele sistemului – la acest pas sunt stabilite componentele pentru construirea sistemului,
incluzând cerințele hardware, instrumentele software, și alte componente necesare. Exemplele
includ decizii legate de hardware, cum ar fi numărul de servere, cât și decizii legate de piesele
externe al aplicației, cum sunt bazele de date și alte biblioteci utilizate (framework -uri
frontend etc.);
▪ Cerințele aplicației – la acest pas se stabilesc așteptările în ceea ce privește funcționa litatea
aplicației și se identifică care dintre cerințele de sistem sunt afectate de către cerințele
software. Analiza cerințelor include determinarea interacțiunilor necesare cu alte aplicații și
baze de date, cerințe legate de performanță și așa mai dep arte;
▪ Design arhitectural – se determină framework -ul unui sistem care să satisfacă cerințele.
Acest design definește componentele majore și interacțiunile acestora, dar nu definește
structura fiecărei componente. Interfețele externe și instrumentele utili zate în proiect pot fi
determinate de către proiectant;
▪ Design detaliat – la acest pas se examinează componentele software definite la stagiul de
design arhitectural și se produce o specificație pentru cum trebuie să se implementeze fiecare
componentă;
▪ Dezvoltarea – se implementează specificațiile din stagiul anterior;
▪ Testarea – se verifică dacă funcționalitățile din aplicație corespund specificațiilor;
▪ Mentenanța – se adresează probleme și cerințele de îmbunătățire după ce se lansează
produsul software.

La fiecare stagiu/pas se creează documente care relatează obiectivele și descriu cerințele pentru fază
creată. La finalul fiecărui stagiu, se va face o revizuire pentru a determina dacă se poate trece la
următorul stagiu.

Multă lume consideră că modelul nu poate fi aplicat la toate situațiile. Având în vedere că la niciun
moment stagiile nu trebuie să interpună, intervine problema care într -un context real este foarte
fezabilă și -anume, se pot descoperi probleme atât în tim pul proiectării sistemului cât și în timpul
dezvoltării în sine care ne pun în lumină anumite erori în cerințe sau chiar cerințe lipsă.
Cu toate acestea, metoda cascadă nu interzice întoarcerea la o fază anterioară, de exemplu, de la faza
de design la cea de cerințe, doar că toate aceste întoarceri reprezintă un efort financiar. Fiecare fază
completă necesită revizuire și documentație de dezvoltare extensivă. Astfel, orice omitere făcută la
faza de cerințe este costisitoare de corectat.

Deoarece faza de d ezvoltare propriu -zisă se întâmplă atât de târziu în proces, nu vor putea fi văzute
rezultate imediat, uneori procesul fiind foarte lung până să aducă rezultate. Acest lucru este de sine
înțeles problematică pentru management și clienți care doresc să vadă rezultate rapid.
În scopul cercetării unui proces cât mai bun, am analizat și o versiune modificată a acestui proces.
Versiunea modificată utilizează aceleași faze cu diferența că nu este atât de discontinuă. Acest lucru
îngădui ca fazele să se interpună atunci când este necesar.

Modelul iterativ
Problemele modelului cascadă au creat o necesitate de a avea o metodă nouă de dezvoltare sisteme
care pot produce rezultate mai rapide, necesită informații mai puține și oferă o flexibilitate mai mare.
În specia l în cazul companiilor care sunt micuțe și încep cu un produs nou, avem nevoie de
flexibilitate mare. Astfel, cu dezvoltarea iterativă, proiectul este împărțit în bucăți micuțe. Acest lucru
îngăduie echipei de dezvoltare să arate rezultate mai rapid și să obțină feedback valoros de pe
utilizatorii sistemului. Deseori, fiecare iterație este un proces cascadă micuț cu feedback -ul de la
prima fază oferind informații valoroase pentru proiectarea din următoarea fază. Putem observa acest
model în Figura 2 .1.2.

Figura 2 .1.2. Ciclul de dezvoltare iterativ [6]

Modelul spirală

Figura 2.1.3. Modelul spirală [7]

Acest model este similar cu modelul incremental cu accentul pus pe analiza riscului , Figura 2.1.3 .
Modelul spirală are patru faze: planificare, analiza de risc, engineering și evaluare. Un proiect va trece
în mod repetat prin aceste faze în iterații (n umite spirale în acest model). În s pirala de bază, începând
cu faza de planificare, se adună cerințele și se analizează riscul. Fiecare spirală ce urmează s e
construiește peste spirala de bază. Cerințele sunt adunate la faza de planificare, iar în faza de analiză

de risc, se începe un proces de identificare a riscului și de găsire a soluțiilor alternative. Se produce
un prototip la finalul fazei de analiză de risc. Dezvoltarea produsului se face efectiv la faza de
engineering, împreună cu testarea care se face la finalul fazei. Faza de evaluare îngăduie clientului
sau managementului să analizeze rezultatul ca mai apoi proiectul să poată continua cu următoarea
spirală. În acest model, componentele unghiulare reprezintă progresul, iar raza spiralei reprezintă
costul.

Dorindu -se dezvoltarea unei aplicați i de monitorizare rețele de socializare, un produs amplu și foarte
important p entru companie, alegerea făcută pentru modelul de proces este modelul spirală. Avantajele
acestui model – analiza de risc și rezultatele parțiale rapide sunt foarte importante. Acest model ne
oferă flexibilitatea de care e nevoie într -un proiect tânăr și c u toate acestea, se analizează în mod
constant care sunt următorii pași.
2.2. Structura organizatorică
Datorită faptului că se dorește o abordare nouă de management, având un manager de proiect hibrid
– care să cunoască atât domeniul IT, cât și cel al moni torizării rețelelor de socializare, structura
organizatorică trebuie să fie una destul de specifică.

Echipele de dezvoltare obișnuite sunt împărțite în zonele pe care le cunosc cel mai bine. De exemplu,
o echipă care se ocupă de zo na de backend în dezvol tarea aplicației, iar membrii ei au cunoștințe
specifice. Se dorește maximizarea eficienței echipei, astfel alegerea susținută de management este
formarea echipelor cu așa zișii generaliști , dezvoltatori care vor putea lucra cu orice tehnologie.
Pentru a a juta însă procesul de învățare, se aduc dezvoltatori care au și experiență în proiectare
arhitecturală, fie în arhitecturi frontend sau backend. Astfel, completând echipa și având oameni în
poziții cheie care să poată să susțină dezvoltatorii cu experiență mai limitată.

Luând toate aceste lucruri în considerare, organizația definește poziția de manager de proiect – nivelul
de autoritate și autonomie, și relația sa atât cu organizația, cât și cu alte proiecte și alte zone ale
organizației. Structura organiz atorică aleasă va fi cea care îi conferă managerului de proiect deplină
autoritate și anume cea bazată pe proiect.

În timpul de organizare bazat pe proiect managerii au un nivel înalt de autoritate pentru a gestiona și
controla resursele proiectului. Mana gerul de proiect are autoritate totală asupra proiectului și poate
achiziționa resurse după cum are nevoie pentru a îndeplini obiectivele proiectului atât din interior cât

și din exteriorul companiei. Singurul impediment ar fi contextul proiectului, calita tea și eventual
restrângerile de buget.

În această structură, personalul angajat sunt asignați pe proiect și raportează direct managerului de
proiect. Acesta din urmă este responsabil pentru progresul carierei membrilor echipei, cât și de
evaluările de p erformanță, lucru care duce la loialitate crescută pe proiect. Faptul că managerul de
proiect are autoritate totală asupra proiectului asigură un control mai bun în proiect și o comunicare
mai ușoară , ceea ce duce la reacții rapide . Personalul de pe proiec t este angajat pe perioadă lungă
tocmai pentru a crea un puternic simț al identității și responsabilității pe proiect, cât și pentru a crea
loialitate pe proiect și o înțe legere bună al naturii activităților de pe proiect și al obiectivelor.