Specializarea Informatică Economică Lucrare de licență Absolvent, Măgurean FINEAS -EMILIAN Coordonator științific, Conf. univ. dr. Sitar -Tăut DAN… [615155]

UNIVERSITATEA BABEȘ -BOLYAI
Facultatea de Științe Economice și Gestiunea Afacerilor
Specializarea Informatică Economică

Lucrare de licență

Absolvent: [anonimizat],
Conf. univ. dr. Sitar -Tăut DAN -ANDREI

2019

i
UNIVERSITATEA BABEȘ -BOLYAI
Facultatea de Științe Economice și Gestiunea Afacerilor
Specializarea Informatică Economică

Lucrare de licență

Baza de date a unei companii de jocuri video

Absolvent: [anonimizat],
Conf. univ. dr. Sitar -Tăut DAN -ANDREI

2019

ii
Rezumat

Lucrarea abordează tematica bazei de date a unei comp anii de jocuri video din zilele noastre.
Pentru a ajunge la necesitatea unei baze de date într -o compaine IT, trebuie mai întâi să ne
falimiarizăm cu infrasctructura aceste ia. Știm că pentru orice companie care face și marketing, este
nevoie de câteva departamente care sunt prezente în majoritatea organizațiilor di n toate domeniile
cum ar fi : departamentul de resurse umane și departamentul de vânzări. Fără aceste două elemente,
o companie nu poate funcționa. Însă pe lângă aceste departamente, lucrarea ne introduce în
cunoașterea celorlalte elemente cruciale în dezvo ltarea produselor de tip joc uri video. Pe parcursul
lucrării vom învăța despre departamentul de programare, de testare, de localizare și de hardware
pentru o bună înțelegere a etapelor prin care un produs trece prin aceste departamente , ca mai apoi
sa fie apt pentru livrare /scoatere în producție . Metodologia de lucru aleasă care este baza
funționării propice a serviciilor oferite de companie este Agile. Folosind această metodologie vom
vedea că are avantaje semnificative pentru aceste tipuri de proiecte și este cea mai bună alegere în
acest sens. După ce am prezentat importanța acestor departamente ca baza a lucrării, pe această
bază voi con strui ceea ce se numește necesitatea unei baze de date intr -o com panie de jocuri vieo.
În această parte a lucrării vom vedea căci aceste departamente nu pot funcționa fara o baza de date
de calitate, inclusiv angajații companiei nu vor putea să își desfășoare activitatea de zi cu zi fără a
lucra pe o bază de date. Prin această lucrare vreau să evidențiez faptul că o bază de date este
indispensabilă acestui tip de companie din zilele noastre și cunoașterea internă a proceselor care
se desfășoară în acest tip de companie .

iii

Cuprins

Lista tabelelor și figurilor ………………………….. ………………………….. ………………………….. …………………….. iv
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……………… 1
1. Arhitectura internă a companiei ………………………….. ………………………….. ………………………….. ……….. 3
1.1 Clarificarea Compartimentelor ………………………….. ………………………….. ………………………….. ……….. 4
1.2 Stabilirea canalelor de comunicare ………………………….. ………………………….. ………………………….. ….. 6
1.3 Metodolog ia ………………………….. ………………………….. ………………………….. ………………………….. …….. 6
1.3.1 Agile ………………………….. ………………………….. ………………………….. ………………………….. ……… 10
1.3.2 Scrum ………………………….. ………………………….. ………………………….. ………………………….. ……. 13
2. Departamentele unei companii IT de j ocuri video ………………………….. ………………………….. …………. 16
2.1 Departamentul de resurse umane ………………………….. ………………………….. ………………………….. …… 16
2.1.1 Cerin țele proiectului din partea clientului ………………………….. ………………………….. …………… 18
2.2 Departamentul de programare ………………………….. ………………………….. ………………………….. ……….. 22
2.3 Departamentul de testare, localizare ………………………….. ………………………….. ………………………….. . 28
2.4 Departamentul de vânzări ………………………….. ………………………….. ………………………….. …………….. 36
2.5 Departamentul de h ardware ………………………….. ………………………….. ………………………….. ………….. 38
3. Necesitatea unei baze de date ………………………….. ………………………….. ………………………….. …………… 39
3.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. …….. 39
3.2 De ce este nevoie de o bază de date? ………………………….. ………………………….. ………………………….. 41
4. Baza de date MongoDB ………………………….. ………………………….. ………………………….. …………………… 44
4.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. …….. 44
4.2 Arhitectura ………………………….. ………………………….. ………………………….. ………………………….. …….. 45
4.3 Avantaje ………………………….. ………………………….. ………………………….. ………………………….. ………… 46
4.4 Aplicația ………………………….. ………………………….. ………………………….. ………………………….. ………… 47
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 49
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……………. 50

iv
Lista tabelelor și figurilor

Tabele:
1. Tabelul de riscuri ale proiectului ………………………….. ………………………….. ………………………….. …… 32
2. Tabelul planului de testare ………………………….. ………………………….. ………………………….. ……………. 33
3. Tabelul reperelor proiectului ………………………….. ………………………….. ………………………….. …………. 34

Figuri:
1. Procente din populație care aleg jocurile video ………………………….. ………………………….. ……………… 1
2. Câștigurile anuale ale industriei jocurilor video ………………………….. ………………………….. …………….. 1
3. Modelul ierarhic între superior și subordonat ………………………….. ………………………….. ………………… 4
4. Schema Framework -ului penrtru procesul de dezvoltare a aplicațiilor software ………………………….. 8
5. Schema metodologiei Agile ………………………….. ………………………….. ………………………….. ………….. 10
6. Schema metodologiei Sc rum ………………………….. ………………………….. ………………………….. ………… 13
7. Schema mecanismului Antikzthera al planetelor ………………………….. ………………………….. ………….. 40
8. Arhitectura bazei de date MongoDB NoSQL ………………………….. ………………………….. ………………. 45
9. A Colecția “Angajați” din baza de date ………………………….. ………………………….. ………………………. 48
10. Colecția “Jocuri Video” din gaza de date ………………………….. ………………………….. ………………….. 48

1
Introducere
În jurul anilor 1950 -1950 jocurile video erau doar o simplă curiozitate în lumea
calculatoarelor, însă începând cu anul 1970 au început să fie cunoscute în lumea întreagă atingând
astfel o popularitate la scară largă care a continuat să crească foarte rapid, iar după anul 2010
indusria jocruilor video a explodat și se numără în activitățile zilnice a majorității oamenilor.
Jocurile fiind disponibile pe o mare varietate de platforme precum ele sunt accesate de către
sute de milioane de utilizatori din întreaga lume, în fiecare zi ca o metodă de relaxare și de petrecere
a timpului liber. Industria jocurilor se află într -o continuă dezvoltare și ajunge la câștiguri anuale
de zeci de miliarde de dolari asfel construind în jurul lor o putere de top a economiei mondiale.
Aceste câștiguri c resc de la un an la altul, principalele motive fiind progresul sigur și rapid al
tehnologiei din industria calculatoarelor, dar și numărul tot mai mare al persoanelor care intră în
contact cu această lume.

100 70
80 60 Miliarde de
60 50 dolari
40 Bărbați 40
20 Femei 30
0 20
10
0

Fig.1 Procente din populație care aleg jocurile video Fig. 2 Câștigurile anuale ale industrie i jocurilor video

Deși fiecare platformă pentru dezvoltarea jocurilor video are un rol important și bine
definit, atenția ne este atrasă de companiile care produc aceste jocuri. La început fiecare companie
care este la ora actuală în top, a început de jos având o mână de oameni ca personal angajat și un
sediu mic unde acești oameni se adunau pentru a lucra la construirea de noi produse, de jocuri. De –
a lungul anilor companiile au luat amploare, evol uând , astfel că în ziua de azi aceste companii
micuțe au ajuns să aibă sute de angajați, zeci de proiecte concomitent și multe sedii care au fost
răspândite în multe țări din lume. Investițiile fanilor către aceste companii au fost și sunt tot mai
Marea Britanie
Germania
Franța
Olanda
Belgia
S.U.A.

2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015

2
mari, în cât multe jocuri video de top au fost făcute în întregime numai din donații financiare ale
fanilor care iubesc aceasta lume a jocurilor.
Deoarece cu trecerea timpului jocurile sunt tot mai mari și mai complexe și necesită tot
mai mulți oameni pentru dezvoltarea propice a acestora, însemnând creșterea personalului in
companii, cantitatea de informații ce trebuie stocată devine tot mai mare, astfel că este nevoie de
o baz ă de date capabilă să facă aceste lucruri. La ora actuală orice companie din lume care nu este
neaparat in domeniul jocurilor video, are nevoie de o baza de date care să țină evidența acțiunilor
acesteia plus o organizare mult mai bună.
Înainte de a ajunge la nevoia de bază de date într -o companie de jocuri video, această
companie trebuie să înceapă să existe într -o manieră organizată sub umbra unei ierarhii în
rânduială. Înainte ca jocurile să fie produse iar mai apoi puse pe piață, trebuie să existe mai întâi
cineva în spatele acestora care să investească bani și timp pentru aceste a, și aici nu ne referim la
câțiva indivizi, ci la o întreagă companie care se ocupă de confecționarea lor. Compartimente atât
tehnice cât si admin istratoriale formează un întreg pentru a lucra în armonie unele cu altele , având
un spirit de comunicare și înțetelere cât mai vizibil si mai b un. Toate aceste lucruri /informații de
la începutul unui proiect si până la finalizarea acestuia, alte proiecte care rămân ale firmei, detalii
despre angajați, detalii despre clienți, colaborări sau contracte cu alte firme trebuiesc stocate
undeva, unde nimeni din exterior nu are acces la ele ci numai firma si angajații, stocate undeva
având o securitate ri dicată și copii de rezervă ale acestora în caz de accidente neprevăzute, într -o
bază de date.
În urma acumulării de informații pe parcursul timpului în acest domeniu, ne propunem prin
intermediul acestei lucrări s ă dezvolt ăm structura internă a unei compa nii de jocuri video pentru a
ne familiariza cu exitențele și scopul ei și a întelege de ce este nevoie pentru ca un joc sa poată să
fie conceput și mai apoi lansat pe piață ca în final s ă vedem căci aceste lucruri nu sunt posibile fără
implementarea și existența unei baze de date. O baza de date este indispensabilă unei astfel de
companii și vreau pe parcursul lucrării sa punctez acest lucru esential, după care să vedem ce fel
de bază de date ne oferă aceste sericii și o calitate de top în realizarea acesto r lucruri.
Lucrarea este organizată după cum urmează: Capitolul 1 prezintă arhitectura internă a
companiei și metodologia pe baza căreia compania funcționeaza, Capidolul 2 descrie
compartimentele esențiale ale companiei precum si un proiect de tip joc vi deo de la etapele

3
incipiente ale acestuia până ce produsul este gata de livrare, Capitolul 3 punctează nevoia unei
baze de date si foloasele -avantajele acestea și ultimul capitol, Capitolul 4 abordează baza de date
MongoDB și prezintă aplicația bazată pe a ceastă bază de date. Lucrarea se încheie cu concluzii și
direcții viitoare de studiu. Materialele suport sunt reunite în cadrul Anexelor.

1. Arhitectura internă a companiei
O afacere, oricât de mică ar fi, necesită o structură organizatorică pentru o funcționare
normală, având în vedere că aceasta este singura cale de exercitare a autorității (dreptul de a
comanda un grup de angajați să acționeze în cadrul firmei). Indiferent de tipul firmei, stabilirea
unei structuri organizato rice conferă următoarele avantaje pentru derularea activităților:
Pentru o percepere armonioasă a sarcinilor atribuite angajaților din firmă, este necesar
ca fiecare persoană, implicată în afacere, să știe foarte exact: cine este însărcinat?, cu ce?, de
către cine? Astfel, diviziunea muncii din cadrul firmei este dependentă de corelația autoritate –
responsabilitate, iar subsistemele independente ale organigramei firmei se bazează pe modelul
superior – subordonat.
Deși fiind o firm ă de IT specializată pe jo curi video, fiecare angajat din orice department
ar fi, trebuie să cunoască sarcinile care i -au fost date de c ătre superiorul lui. Organizarea și
comunicarea sunt cheia pentru a avea succes în munca depusă, aceste dou ă virtuții sunt absolut
necesare în cad rul companiei între angajați.
Relația dintre superior si subordonat trebuie să fie strânsă pe plan profesional deoarece
superiorul r ăspunde în fața clientului de greșelile din partea subordonațilo r săi. Niciodată pe
client nu îl va interesa care dintre oam enii alocați proiectului a întârziat cu sarcinile de lucru
astfel că nu au fost terminate la timp, ci el se va duce direct la omul care este desemnat să poarte
conversații cu clientul și acesta va da socoteală dacă ceva nu merge bine în fluxul de lucru,
superiorul va răspunde primul în fața clientului. În urma acestor repercursiuni, superiorul va
veni la subordonații alocați lui și le va comunica despre greșala pe care au facut -o caz în care se
poate să îi și penalizeze.

4

Fig. 3 Modelul ierarhic între superior si subordonat

1.1 Clarificarea compartimentelor /departamentelor :
Într-o firmă de IT este nevoie de câteva compartimente esențiale care cuprind în totalitate
dezvoltarea unui proiect (joc video). Fiecare departament în parte va avea anumite sarcini
individuale, care nu se vor intersecta cu ale celorlalte departamente, sarcini bine definite care au
un rol crucial în dezvoltarea proiectelor. Între departamente este deasemenea nevoie de o
comunicare foarte bună, deoarec e munca unuia depinde de munca altuia care face parte dintr -un
întreg. Dac ă vreun departament are probleme în realizarea sarcinilor acordate, tot proiectul va
suferi astfel că toată compania va avea de pierdut din această cauză.
⚫ Compartimentul de programare :
Fiind o firmă care are propriile proiecte sau jocuri video este nevoie de existența unui
departament de programare. Acesta este format din personal specializat în diferite limbaje de
programare care sunt necesare în dezvoltarea jocurilor video. Ei sunt defapt creatorii jocurilor
video și se ocupă atât de partea grafică a unui jo c care putem spune că este partea vizibilă, cât și
de partea din spatele lui adică de codul sursă. Ei sunt persoanele care lucrează cu codul sursă și îl
cunosc în funcție de cerințele dorite pentru proiectul respectiv. Ei trebuie să se adapteze oricărui
tip de joc : de strategie, de rol, acțiune, puzzle etc. și să fie flexibili în redarea codului necesar
tipului de joc. Programatorii sunt singurii din companie care au acces la codul sursă deoarece tot
ei sunt singurii care cunosc codul și pot să lucreze pe e l.
Superior
Subordonat

5
⚫ Compartimentul de testare și localizare :
Asemenea nevoii de programatori este și nevoia de testeri , aceștia preiau proiectul de la
programatori și il testează cu gândul de a găsi erori, greșeli care trebuie reparate. Datoria lor este
de a se asigura c ă înainte ca produsul să fie lansat pe piață, acesta trebuie să fie capabil de a fi rulat
de către utilizatorul final fără probleme, fără a exista erori în interiorul jocului, adică jocul sa
respecte cerințele proiectului și să fie căt mai aproape de perfe cțtiune . Trebuie să ținem cont că
nici un proiect nu va putea fi testat 100% astfel c ă nu există jocuri care să nu aibă erori chiar dup ă
lansarea acestuia , numai că aceste erori trebuie să fie minimalizate.
Până să se ajungă la produsul finit, mai multe etape sunt necesare în care programatorul
creează o schiță, un prototip din joc după care această schiță este predată testerului . El o testează
și găsește erori după care o trimite înapoi programatorului ca să fixeze greșelile. Programatorul
trimite apoi o schiță îmbunătățită la tester care o retestează și astfel acest proces se tot repetă până
când proiectul ia formă și ajunge în stadiul final capabil să fie pus pe piață.
Departamentul de localizare deși este separat față de celelalte ca și structur ă, are aceași
funcționalitate ca și compartimentul de testare numai puțin diferită. În realizarea unui joc video
este necesar un aspect important și acesta este suport pentru mai multe limbi străine. Deși proiectul
este conceput intr -o anumită țară unde se lucrează în limba proprie, este necesar ca jocul sa fie
tradus în mai multe limbi din diferite motive. Dacă jocul este lansat numai pe piața țării proprii
atunci vânzările sunt limitate astfel că profitul este mediocru, însă dacă se face trecerea la
expor tarea și vânzarea produsul în mai multe țări din lume atunci profitul crește considerabil, însă
jocul trebuie să suporte fiecare limbă a țării în care va fi disponibil.
Aici intervine echipa de localizare care la fel ca echipa de testare, va avea datoria să testeze
produsul și să găsească greșeli dar numai pe partea de text, gramatică adica partea de traducere. În
acest compartiment vor fi aloca te persoane care cunosc limbile străine conform țărilor în care jocul
va fi distribuit. Pentru ac eastă sarcină es te nevoie de cunostiințe avansate în termeni de traducere
cât si cunoașterea limbii , mai ales pe parte gramatical ă deoarece traducerile trebuie să fie perfecte.
Procesul se repetă la fel ca în ca zul testerului de aplicație unde schițele sunt retestate până se ajunge
la produsul final.

6
1.2 Stabilirea canalelor de comunicare :
Unul dintre cele mai bune canale de comunicare între departamente, între angajați este
adaptarea sistemului la o baz ă internă de date. Toate stațiile de lucru vor fi conectate între ele la
aceeași rețea și bază de date, acest lucru făcând posibil accesul comun la documente , conversații,
proiecte etc. O companie IT nu se poate lipsi de o baz ă de date internă chiar dacă ac easta este
personalizată sau comună, deoarece fără ea nu ar mai fi posibilă comunicarea internă și externă cu
clientul sau companiile asociate acesteia.
Pe lângă o baz ă de date , un alt canal de comunicare important este o aplicație desktop
pentru convorbi ri video sau text (mesaj) . În acest sens aplicația Skype este alegerea cea mai bună
a oricarei firme, aceasta caz în care firma nu și -a dezvoltat propria aplicație de comunicare . Pentru
a evita deplasarea de la o stație de lucru la alta în cadrul unui depa rtament sau chiar în cadrul a mai
multor departamente, comunicarea online sub forma mesaj text este obligatorie. Probleme,
întrebări, nedumeriri apar zilnic intr -un proiect, între membrii echipelor, de aceea aceste probleme
se pot rezolva prin comunicare c u alți membri de echipă sau chiar cu departamentul de
administrație. Apelurile video se fac de obicei între companie și client care nu ia parte la întrunirea
între aceștia fizic, de aceea se va comunica prin intermediul video și de multe ori se întâmplă ca
clientul s ă fie din altă țară si fiind client asociat este de dorit ca această metodă de comunicare să
existe.
Trimiterea mail -urilor de înștiințare în leg ătura cu sarcinile echipelor, respectiv membrilor,
a mail -urilor cu privire la inormațiile personal e despre contractul de muncă, salariu, concediu etc.
se fac și se încadrează într -un canal de comunicare care va fi o aplicație (bază de date) internă de
obicei personalizată, proprie a firmei .

1.3 Metodologia:
Compania nu poate funcționa fără o organizare la nivel de dezvoltare a proiectelor, a
jocurilor video. Atât clientul cât si personalul alocat proiectului respectiv trebuie sa fie conștienți
de ce metodologie se utilizează pentru că aceasta îi implică pe am bii.

7
Ramură a disciplinei Ingineria software , care se ocupă cu definirea, structurarea și controlul
procesului de dezvoltare a aplicațiilor software.
Acest framework este utilizat pentru structurarea, planificarea și controlul procesului de
dezvoltare a unui sistem software, care include rezutate specifice predefinite, artefacte care sunt
create si completate de către echipa de proiect pentru a dezvolta sau de a întreține un sistem
software.
Metodologia pune la dispoziția tuturor celor implicați în derularea proiectelor un cadru
formal care reglem enteaza și asigură desfașurarea eficientî a activităților de dezvoltare și
implementare, asiguraâd atingerea cu succes a obiectivelor: creșterea calității livrabilelor,
scurtarea duratei proiectelor, standardizarea proceselor, cresterea eficienței tuturor resurselor.
De asemenea, metodologia are rolul de a ghida și asista activitatea project managerilor pe tot
parcursul desfășurării proiectelor și de a urmari daca au fost atinse obiectivele și beneficiile
stabilite ale proiectelor respective.
Documentele p rincipale care guverneaza desfășurarea proiectului sunt “Contractul”,
“Project Charter -ul” ( întotdeauna ultima versiune) și “Specificația Functionala si de Design”,
inclusiv anexele acestora. Orice înțelegere verbală sau în scris între cele două părți contractante,
care nu este formalizat ă în unul din aceste documente, nu va fi luat ă în considerare.

➢ Metodologia se bazeaza pe câțiva factori esențiali pentru desfasurarea cu succes a
proiectului:
• un set de reguli, proceduri, template -uri și unelte informa tice care permit inițierea, planificarea
executța, monitorizarea și controlul eficient al derularii proiectului
• planificarea de ansamblu și detaliată atent realizată, cu implicarea activa a ambelor echipe de
proiect și actualizata periodic pe parcursul des fașurării proiectului;
• analiza, înțelegerea, descrierea și design -ul corect și eficient al Funcționalităților proiectului
(care satisfac Obiectivele de business), în cadrul Specificației Functionale și de Design

8
Fig. 4 Schema Framework -ului pentru procesul de dezvoltare a aplicațiilor software

Specifica ții Import Plan de Acceptare
Structura Testare Finală
Definirea
Planificării După
implementare Management de proiect
Managementul de integrare a proiectului
Managementul de scop a proiectului
Managementul de timp a proiectului
Managementul de cost a proiectului
Managementul de integrare aproiectului
Managementul de resurse umane a proiectului
Managementul de comunicare a proiectului
Managementul de procurare a proiectului Module
Noi
Schimbarea
Cererii Începutul
Proiectului
Definirea
Strategiei
Planificare
&
Lansare Suport
Tehnic
Analiză & Customizare & Migrare Instalare & Testare de Live Terminarea
Design Configurare Data Training Acceptare Proiectului

9
⚫ Beneficiile metodologiei :
Rezultatul direct al utiliz ării metodologiei sus men ționate const ă în cre șterea profitabilit ății
proiectelor, în cre șterea calit ății produselor și a serviciilor oferite precum și reducerea timpului de
implementare astfel încat partenerii no ștri pot:
– să beneficieze de toate func ționalit ățile aplica ției din prima zi;
– să controleze costurile implement ării și durata fiec ărei faze a implement ării;
– să reduc ă complexitatea reduc ând astfel și timpul și costul;
– să obțină un beneficiu mult mai rapid al investi ției.
Ca modalitate de abordare a proceselor de management și de derulare a proiectelor, metodologia
are la baz ă câteva elemente principale:
➢ trateaz ă atât disciplinele procesului de project management (managementul timpului,
managementul bugetului, management ul riscului, managementul schimb ării etc.), c ât și
modalitatea de desf ășurare a fazelor din ciclul de via ță al proiectului;
➢ este orientat ă către acele reguli și proceduri care reglementeaz ă un mod de lucru standard
pentru activitatea project managerilor și a echipelor de proiect, ea nefiind o colec ție de
bune practici facultativ a fi aplicate pe parcursul derul ării proiectului;
➢ este adaptat ă realit ăților și necesit ăților tipurilor de proiect e derulate;
➢ este orientat ă către cre șterea eficien ței proiectelor
➢ define ște și utilizeaz ă indicatori de performan ță care vor fi urma riți atât la finalizarea
proiectelor, c ât și pe parcursul derul ării acestora;
➢ este un proces dinamic, metodologia se va act ualiza periodic pentru a servi c ât mai bine
derul ării proiectelor.

10

1.3.1 Agile:

Fig. 5 Schema metodologiei Agile

Ce este Agile?
⚫ Metod ologie de management a proiectelor ce încearcă să micșoreze riscurile de dezvoltare
și timpul de execuție prin implementarea proiectelor în formă foarte flexibil ă și interactiv ă.

11
Caracteristicile Agile:
⚫ Este iterativ : o iterație are între 1 -4 saptămîni , în rezultat sunt livrate anumite funcț ionalități
ale proiectului.
⚫ Este bazat pe timp : durata iterației e fixă și nu poate fi modificată pe parcursul proiectului.
În acest fel există întotdeauna un rezultat productiv la finalul iterației.
⚫ Deschis către client : la finalul fiecărei iterații exist ă un rezultat care poate fi prezentat
clientului.
⚫ Bazat pe livrarea de versiuni intermediare ale produsului : fiecare iterație va implementa
complet toate “task -urile” cuprinse în acea iterație
Principii:
1. Livrări neîntâriziate și continue de software valoros
2. Schimbarea cerințelor în decursul procesului de dezvoltare
3. Intervale mai scurte de timp
4. Oamenii de afaceri și dezvoltatorii lucrează împreună
5. Proiectele sunt construite în jurul persoanelor motivate
6. Comunicare eficientă către și în interiorul echipei de dezvoltare
7. Software funcțional
8. Ritm constant pe timp nedefinit
9. Superioritate tehnică și proiectare bună
10. Simplitate
11. Echipe organizate propriu
12. Brainstorm -ing pentru evoluția internă a echipei

12
➢ Colaborarea cu clientul:
Contractele creea ză cultura în care schimbarea nu este o opțiune. Agile creează cultura unde
schimbarea este așteptată. Însă cum controlăm schimbarea? Printr -o colaborare strânsă cu clienții.
Agile presupune că avem acces nelimitat la clienții noștri și că întotdeauna pute m discuta cu ei. În
contextul în care developerii rezolvă probleme în mod natural, ei au totuși nevoie și de perspectiva
clientului pentru a înțelege în detaliu care este problema reală.
Contractele sunt folositoare, însă au un efect neplăcut: oamenii tind să fie preocupați de a livra
proiectul în timpul și banii stabiliți, mai mult decât să îndeplinească scopul de business. Mai
departe, când echipa este presată de timp, rezultatul este frustrare, panică și o calitate mai mică a
produsului.
Mai mult, când s emnăm un contract în primele faze ale proiectelor, tindem să aproximăm greșit
timpul petrecut pe proiect. Însă tot va fi nevoie să ne încadrăm în termene chiar dacă ele nu au de
a face cu nevoile reale. De aceea, Agile favoriezează colaborarea cu clientul și livrarea proiectului
în mai multe etape. Asta lasă timp echipei să descopere ceea ce nu știa despre proiect.
Metodologii Agile:
⚫ AGILE exist ă în mai multe feluri:
⚫ XP
⚫ SCRUM
⚫ DSDM,
⚫ Crystal,
⚫ Feature Driven
⚫ Lean Development
Toate folosesc principii de baza ale filozofiei AGILE, dar o implementeaz ă în moduri diferite.

13
1.3.2 Scrum:

Fig. 6 Schema metodologiei Scrum

Principiul metodologiei Scrum:
• dezvoltarea incrementală a aplicați ei software ;
• livrări frecvente – de regulă au loc o dată la 4 săptămâni ;
• clientul primește de fiecare dată o aplicație ce conține un număr tot mai mare de
funcționalități și care se află în perfectă stare de funcționare.

Reguli in Scrum:
⚫ Această metodă necesită patru tipuri de ședințe :
• Ședințele zilnice: echipa se reunește î n fiecare zi și petrece circa 15 minute, în
picioare, pentru a răspunde la următoarele trei întrebări: ce am făcut ieri? Ce voi
face azi? Cu ce obstacole mă confrunt azi?

14
• Ședințele de planificare: întreaga echipă se adună pentru a decide care sunt
funcțion alitățile care vor alcătui următorul sprint, și pentru a actualiza lista
generală.
• Ședințele de revizuire a activității: în timpul acestei ședințe, fiecare membru
prezintă ceea ce a făcut pe durata sprintului. Se organizează o demonstrație a noilor
funcțio nalități și o prezentare a arhitecturii. Aceasta este o ședință informală, de
două ore, la care participă toată echipa.
• Ședințele retrospective: la finalul fiecărui sprint, echipa analizează aspectele care
au funcționat bine, precum și pe cele care au func ționat mai puțin bine. În timpul
acestei ședințe de 15 –30 de minute, se organizează un vot de încredere pentru a
decide ce îmbunătățiri trebuie implementate .

Avantaje:
• reducerea documentației la minimul cu scopul sporirii productivității ;
• evitarea „efectu lui de tunel", adică faptul de a obține rezultatul abia la livrarea finală și de
a nu întrezări nimic concret pe durata întregii faze de dezvoltare ;
• compunerea secvențială a conținutului sprint -urilor permite efectuarea unei modificări sau
adăugarea unei f uncționalități care nu era prevăzută inițial. Acesta este principalul aspect
care face ca această metodă să fie „agilă“ ;
• metodă participativă: fiecare membru al echipei este invitat să își exprime părerea și poate
contribui la toate deciziile luate în cadr ul proiectului, fiind astfel mai implicat și mai
motivat ;
• facilitarea comunicării: lucr înd în aceeași sală de dezvoltare sau fiind conectată prin
intermediul diferitelor mijloace de comunicare, echipa poate comunica ușor și poate
schimba informații despre impedimentele întâlnite în scopul eliminării cât mai rapide a
acestora ;

15
• ameliorarea cooperării: comunicarea zilnică dintre client și echipa face posibilă o
colaborare mai strânsă între cele două părți ;
• creșterea productivității: prin eliminarea anumitor „exigențe" specifice metodelor clasice,
precum documentația ;
• timpul de livrare a produsului final se reduce semnificativ.
Riscuri și solu ții:
• Dimensiunea echipei: fiind limitată la 7 -10 persoane, dimensiunea echipei se poate
transforma într-un obstacol dacă se depășește numărul de membri recomandat. În acest caz,
organizarea de ședințe devine imposibilă . Soluția constă în realizarea unui „Scrum of
Scrums“ – împărțirea proiectului în echipe de dimensiuni standard și adăugarea unei
instanț e superioare care să grupeze ScrumMasterii fiecărui Scrum;
• Cereri multiple: cererile pot proveni din mai multe surse în cadrul unui proiect și pot uneori
să fie dificil de gestionat datorită aspectului lor contradictoriu. Pentru a remedia această
problemă, trebuie să se utilizeze în mod obligatoriu o aplicație de gestiune a cererilor;
• Calitatea produsului realizat: cu cât numărul echipelor este mai mare, cu atât calitatea este
mai greu de controlat. Pentru aceasta, este important să existe o politică de cal itate
riguroasă și un plan de calitate a proiectului. Verificarea frecventă a codului și introducerea
unor indicatori pentru măsurarea performanței programatorilor permit reducerea la
minimum a acestui risc.
Organizare:
• Metodologia SCRUM implică intervenți a a trei protagoniști :
Product owner: responsabilul de produs și coordonatorul echipei clientului. El este cel care
definește și stabilește funcționalitățile prioritare și alege data și conținutul fiecărui sprint pe baza
volumelor de lucru comunicate de e chipă.
ScrumMaster: acesta facilitează buna desfășurare a proiectului, are grijă ca fiecare membru să
poată lucra la capacitate maximă eliminând impedimentele și protejând echipa de perturbările
exterioare. De asemenea, acordă o atenție specială respectări i diferitelor faze SCRUM.

16
Echipa: fiind de regulă alcătuită din circa 4 -10 persoane, echipa adună la un loc specialiștii necesari
în cadrul unui proiect, și anume: arhitectul, designerul, programatorul, testerul etc. Echipa se
organizează singură și rămâne neschimbată pe toată durata sprintului.
• Acest tip de organizare poate fi utilizat în majoritatea proiectelor;
• Metodologia Agile – SCRUM este destinată în special proiectelor care nu au un cadru bine
conturat;
• E nevoie o echipă cu inițiativă care cuprinde oameni cărora le place să experimenteze, să
schimbe și să se adapteze cerințelor;
• Echipe care stiu sa se organizeze ;

2. Departamentele unei companii IT de jocuri video
2.1 Departamentul de resurse umane
Ce presupun de fapt serviciile de resurse umane ?
De cele mai multe ori, când ne gândim la servicii de resurse umane, înclinăm să le punem
pe acestea pe același picior de egalitate cu recrutarea de personal. În realitate însă, recrutare a de
personal este doar o ramură a resurselor umane, deoarece acest domeniu urmează trei direcții
principale, după cum vom vedea în cele ce urmează.
Servicii administrare personal :
Această ramură a serviciilor de resurse umane are în vedere totalitatea acț iunilor pe care le
întreprindem în vederea monitorizării și a menținerii unei evidențe corecte a personalului angajat
într-o firmă. Avem în vedere în acest caz aspecte ce țin de contracte de muncă, de acte adiționale,
de arhivarea documentelor, de decizii, de eliberarea unor documente solicitate de către angajați,
dar și de menținerea unei bune legături între angajat și firmă, astfel încât aceste aspecte să nu mai
dea bătăi de cap angajatorilor.

17
Servicii salarizare :
Este lesne de înțeles ce presupune acest serviciu, însă și aici sunt câteva aspecte pe care ar
trebui să le menționăm. Această ramură ce ține de servicii resurse umane are în vedere legătura
dintre companie și angajat la nivel financiar, dar și re prezentarea companiei în relația cu anumite
instituții financiare. Efectuarea calculelor aferente plăților salariilor, prelucrarea datelor ce țin de
activitatea angajaților, dar și realizarea documentelor contabile ce au legătură cu aceasta,
reprezintă asp ecte importante ale muncii noastre, în ceea ce privește serviciile de resurse umane
pe care le oferim.

Servicii recrutare personal :
Așa cum menționam anterior, ideea de servicii de resurse umane este deseori confundată
cu ideea de recrutare personal, însă diferențele dintre cele două servicii sunt evidente. În etapa de
recrutare vorbim despre căutarea, verificarea, selectarea și mai apoi angajarea candidaților, în
funcție de aptitudinile acestora și de necesit ățile companiei. În această etapă vorbim mai mult de
interacțiune umană decât de calcule și date, sau chiar de documente, deoarece aceasta este situația
în care se elaborează practic o strategie de lucru ce va avea în vedere decizia de a alege forța de
lucru umană calificată pentru cerințele firmei.

Fie că vorbim despre manageri, despre specialiști în anumite domenii, sau despre lucrători
comerciali, alegerea acestora se face în cadrul etapei de recrutare și reprezintă de fapt un aspect
separat al servicii lor de resurse umane. Noi, specialiștii în servicii de resurse umane de la Upline
HR, oferim fiecare dintre aceste servicii, însă ne axăm cu preponderență pe partea de salarizare și
administrare personal deoarece cre dem în libertatea fiecărui antreprenor de a -și alege persoanele
potrivite pentru realizarea taskurilor zilnice. Cu toate acestea, suntem întotdeauna deschiși
colaborărilor în domeniul serviciilor de resurse umane, deoarece cunoaștem importanța acestui
segm ent și implicațiile pe care acesta le are în ceea ce privește dezvoltarea continuă a fiecărei
companii în parte.

Pentru a înțelege cu ușurință următoarele departamente practice (programare, testare și
localizare) am pregătit un produs, un joc video numit “Jumping Square ” și toate etapele de

18
dezvoltare ale acestuia de către fiecare departament în parte, pentru a observa și a înțelege cum
exact și precis se lucreaza într -o firm ă IT de dezvoltare a jocurilor video.

2.1.1 Cerințele proiectului din partea clientului
Jumping Square : Document de cerin țe/specifica ții
Proiect: Jumping Square
Pregătit de: Magurean Fineas

Starea documentului: Proiect=>Propus=>Validat=>Aprobat

➢ Introducere :
Acest document con ține cerin țele de sistem pentru Jumping Square.

➢ Scopul acestui document :
Acest document este destinat pentru a informa echipele care se ocupă de dezvolt area lui Jumping
Square.
➢ Schița: prima versiune sau versiunea de proiect este compilat ă după ce au fost descoperite,
înregistra te, clasificate și prioritizate cerin țele. Acest document va trece prin mai multe
etape:
➢ Propus: focumentul proiectului este apoi propus ca o poten țială specifica ție a
cerin țelor. Documentul propus trebuie revizuit de mai multe p ărți, care pot comenta orice
cerin țe și priorit ăți, fie de a fi de acord, de a nu fi de acord, sau de a identifica cerin țele
lipsă. Cititorii includ utilizatorii finali, dezvoltatorii, managerii de proiect si orice alte p ărți
interesate. Documentul poate fi modificat și reprodus de mai multe ori înainte de a trece la
etapa urm ătoare.
➢ Validat: odată ce diferitele p ărți interesate au fost de acord cu cerin țele din document,
acestea sunt considerate valide.
➢ Aprobat: documentul validat este acceptat de reprezentan ții fiec ărei părți a
compartimentelor interesate ca o declara ție adecvat ă a cerin țelor pentru
proiect. Dezvoltatorii apoi folosesc documentul privind cerin țele ca un ghid al

19
implement ării și pentru a verifica progresul proiectului în timp ce acesta este dezvoltat.

➢ Cum se utilizeaza acest document
Ne a șteptăm ca acest document s ă fie folosit de persoane cu seturi diferite de calific ări. Aceast ă
sectiune explic ă ce părți ale acestui document ar trebui revizuite de diferite tipuri de cititori.
➢ Contextul tehnic necesar :
Cunostiin țele necesare pentru a înțelege un proiect software sunt de dorit pentru fiecare membru
participant .

➢ Prezentare general ă Secțiuni:
Partea de la punctul 3 de cerin țe specific e.

➢ Secțiunea Ordine Dependin țe:
Documentul trebuie citit de la început la sf ârșit în totalitate.

➢ Domeniul de aplicare al produsului :
Domeniul de aplicare va fi acela de joc video la nivel mondial folosind platforma web pentru ca
acesta să poată fi accesat . Produsul va fi un joc video de tip strategie, simplu din punct de vedere
tehnic și grafic dar complex din punct de vedere al mecanicii acestuia. Produsul trebuie executat
ca fiind functional 100%, totu și dimensiunea acestu ia este mic ă.

➢ Caz de afaceri pentru produs :
Acest produs este necesar pentru lansarea primului proiect de tip joc video al companiei noastre;
pentru ca compania s ă poată fi cunoscut ă pe latura aceasta a dezvolt ării de jocuri video.
Obiectivul nostru este de a ne face numele cu noscut în rândul juc ătorilor și acest produs ne va
iniția so ajuta în îndeplinirea lui.

➢ Prezentare general ă a documentului privind cerin țele
Proiectul are o dimensiune mic ă și complex ă. Dorim ca implementarea grafic ă să iși facă datoria
în rolul de a avea un contrast al culoriilor din interiorul jocului c ât mai pronun țate pentru a ajuta
utilizatorul s ă disting ă elementele jocului. De altfel dorim un set de controale pentru unitatea

20
principal ă a jocului c ât mai simple pentru a putea fi utilizate de oric ine cu vârsta de minim 10 ani .
Textul care descrie funcționalitatea de schimbare a culorii elementului principal trebuie s ă fie
tradus și în limba englez ă si franceză , astfel că aici intervine partea de localizare. Produsul trebuie
să fie func țional numai pe platforma Web a oricărui browser pentru Windows 10.

➢ Descriere general ă:
Aceast ă secțiune va oferi cititorului o imagine de ansamblu a proiectului, inclusiv de ce a fost
conceput ?, ce va face atunci c ând este complet ?, și tipurile de persoane pe care le astept ăm să îl
utilizeze. De asemenea, men ționăm constr ângerile care s -au confruntat în timpul dezvolt ării și
ipotezele pe care le -am făcut despre cum vom proceda.

➢ Perspectiva produsului :
Este aceea de a ne lansa în industria aceasta a jocurilor video. Va fi nevoie de produse de acest tip
pentru a îmbun ătăți acest gen la nivel mondial pentru ca utilizatorii s ă pună cât mai mult accent pe
aceste produse. Partea interesat ă în elaborarea acestui proiect este firma noas tra iar beneficiarii
acestui produs vor fi utilizatorii finali care credem c ă vor fi in numar mare , doritori s ă încerce.

➢ Func țiile produsului
Produsul ofera utilizatorului un timp relaxant permi țându-i astfel s ă își elibereze mintea de toate
problemele pe durata utiliz ării acestuia. Activit ățile pe care utilizatorii le pot efectua sunt de a fi
focusa ți pe joc și de a g ăndi urm ătoarele mi șcări pe care le vor face în joc.

➢ Caracteristicile utilizatorilor :
Ne a șteptăm ca utilizatorii finali s ă fie personae cuprinse între v ârsta de 10-25 ani, dar orice
prsoana capabila va putea folosi produsul indifferent de v ârstă. Motiva ția de a folosi acest produs
este aceea pentru recreere proprie și competitivitate.
Consider ăm că nu sunt obstacole în a utiliza acest produs c ât timp de ținătorul produsului va avea
un device propriu, precum un calculator sau laptop și conec xiune la internet .

21
➢ Constr ângeri generale :
Produsul va fi disponibil numai pentru platformele web a oricărui browser pentru sistemul de
operare Windows 10. Nu avem în plan s ă lansăm produsul pe alte platforme.

➢ Ipoteze si dependen țe:
Dacă produsul va avea succes conform dorin țelor și astept ărilor n oastre atunci ne vom g ândi s ă
lansăm și o func ționalitate nou ă produsului, precum s ă îl optimiz ăm pentru mai multe platforme
inclusiv cele mobile.
➢ Cerițe specific e:
Aceasta sec țiune a documentului enumer ă cerin țele specifice pentru Jumping Sqare. Cerin țele sunt
împărțite în urm ătoarele sec țiuni:
➢ Cerin țele utilizatorilor : acestea sunt cerin țe scrise din punctul de vedere al utilizatorilor
finali, de obicei exprimate în form ă narativ ă.
➢ Cerin țe de sistem: a cestea sunt specifica ții detaliate care descriu func țiile pe care sistemul
trebuie s ă le poat ă face.
➢ Cerin țe privind interfa ța: acestea sunt cerin țe privind interfa ța cu utilizatorul, care pot fi
exprimate ca o list ă, ca nara țiune sau ca imagini ale machetelor de ecran.

➢ Cerin țe utilizator :
– o aplica ție de tip joc simpl ă de utilizat
– tip de joc asem ănător cu aplica ția “Flappy Bird”

➢ Cerințe de s istem :
– rularea aplica ției pe sistemul de operare Windows 10
– rularea aplica ției pe browser -ul Google Chrome , Microsoft Edge, Mozilla Firefox și Opera
– rularea aplica ției pe o configura ție de sistem minimă : procesor I ntel HD Graphics , 2 Gb RAM
ddr3, placa video 1Gb VRAM

➢ Cerințe privind interfața :
– un frame al aplica ției în partea dreapta sus al pagini web cu o bordur ă neagr ă
– backround -ul frame -ului s ă aibă culoarea turcoaz

22
– unitatea principal ă să fie de forma unui p ătrat și să aibă culoarea albastr ă
– obstacolele s ă fie în interiorul frame -ului și să aibă culoare neagr ă

2.2 Departamentul de programare
Design aplica ție, implementare de c ătre programatori :
➢ Build 1
Aplica ție design:
– Va fi implementat un frame cu bordur ă de culoare neagr ă
– Background -ul frame -ului va avea culoarea turcoaz
– În interiorul frame -ului vom avea unitatea principal ă un patrat de culoare albastr ă, care va
fi așezat în partea st ângă a frame -ului la pu țină distan ță față de bordur ă
– Obstacolele din interiorul frame -ului vor fi de culoare neagr ă și vor avea form ă cilindric ă;
vor fi implementate pe partea de sus și pe parte a de jos a frame -ului care vor porni din
bordu ă frame -ului
Design -ul va fi similar cu al aplica ției “Flappy Bird” , inclusiv mecanica aplica ției. În build -ul 1 nu
se va implementa nimic mai mult în afar ă de par țile de design enumerate mai sus.

➢ Build 2
Func ționalit ăți:
– Sub frame -ul aplica ției se va introduce un buton care va avea func ția urm ătoare: la ap ăsarea
butonului, unitatea principal ă “patratul” va putea fi ridicat pe verticala frame -ului c ât timp
este ținut ap ăsat butonul prin func ția de “click st ânga” a mouse -ului. C ând butonul este
lăsat de la ap ăsarea lui , atunci unitatea principal ă va “c ădea” p ână când va lovi bordura de
jos a frame -ului. Aceast ă funcție asigur ă “mișcarea” elementului de baz ă.
– Când se intr ă pe pagina jocul este declan șat iar pentru aceasta se creaza o func ție în care
obstacolele din frame se vor derula de la dreapta la st ânga astfel oblig ând utilizatorul s ă
foloseasca butonul de mi șcare a unit ății principale.

23
– Obstacolele se vor derula la infinit sau p ână când unitatea principa lă va ating e un obstacol.
Cand acest lucru se întampl ă, jocul se opre ște iar pentru a putea fi derulat din nou trebuie
să se dea restart la pagina web.
– Sub butonul de “accelerare” se vor l ăsa dou ă rânduri libere și sub aceste r ânduri se vor
implementa 3 bu toane pe acela și rând, unul l ângă altul. Primele dou ă butoane vor avea
funcționalitatea de a colora unitatea principal ă când sunt ap ăsate. Primul buton va colora
alb și al doilea buton ro șu. Pentru a reveni la culoarea inițială a unit ății principale se va da
restart la pagina web. Al treilea buton va fi introdus și va avea func ționalitatea de a traduce
tot textul implementat pe pagina aplica ției în dou ă limbi. În acest build se va implementa
funcționalitatea de traducere , dar numai în urmatorul build se va introduce textul și limbile
în care va fi tradus.
In build -ul 2 nu se va implementa nimic mai mult în afar ă de p ărțille de func ționalitate
enumerate mai sus.

➢ Build 3:
Localizare:
➢ Text informativ al aplica ției
Vom avea sub interfa ța aplica ției, pe site -ul web urm ătoarele implement ări:
– În interiorul bu tonului de accelera re vom avea introdus urmatorul text:
Limba roman ă : “Accelereaza”
Limba englez ă: “Accelerate”
Limba francez ă: “Accélère”
– Sub butonul de accelerare vom avea 2 r ânduri de text informativ:
Limba roman ă: “Folose ște butonul de accelerare pentru a sta în aer”
“Cât de mult po ți sta în via ță?”
Limba englez ă: “Use the accelerate button to stay in the air”

24
“How long can you stay alive?”
Limba francez ă: “Utilisez le bouton accélère pour rester en l'air”
“Combien de temps pouvez -vous rester en vie?”
– Sub cele dou ă rânduri de text vom avea 3 butoane cu urm ătorul text:
Primul buton:
Limba roman ă: “Alb”
Limba englez ă: “White”
Limba francez ă: “Blanc”
Al doilea buton:
Limba roman ă: “Ro șu”
Limba englez ă: ”Red”
Limba francez ă: “Rogue”
Al treilea buton va avea urm ătorul text f ără altfel de traduceri:
“Roman ă/English/ Français”
➢ Text informativ al paginii web
Vom avea în dreapta interfe ței aplica ției, pe site -ul web urmatoarele implement ări:
Limba roman ă:
“Membrii:
– Magurean Fineas: managerul de proiect
programatorul principal
testerul principal

25
Sarcini:
– Întocmirea documentelor de specifica ții, informa ții a proiectului
– Întocmirea bazei de date a proiectului plus sec țiunea de raportare a bug-urilor
– Întocmirea diagramei Grantt pentru monitorizarea dezvolt ării proiectului
– Întocmirea planului de testare
– Întocmirea design -ului aplica ției
– Creearea și implementarea codului aplica ției plus partea de cod de localizare
– Traducerea în dou ă limbi a p ărții de localizare
– Testarea aplica ției plus raportarea și fixarea bug -urilor
– Monitorizarea bunului mers al proiectului
Date de contact:
Num ăr de telefon: 0747635872 – Project Manager Magurean Fineas
Adresa email: fineasm@yahoo.com
Ajutor!: Pentru informa ții suplimentare v ă rugăm să ne contacta ți prin telefon sau prin email, care
pot fi g ăsite la sec țiunea de “Date de contact”.

Limba englez ă:

"Members:
– Magurean Fineas: project manager
the main programmer
the main tester
Tasks:
– Drawing up the documents of specifications, informations of the project
– Drawing up the project database plus the bug reporting section
– Grant the Grantt chart for project development monitoring

26
– Drawing up the test plan
– Drawing up the design of the application
– Creating and implementing the application code plus the localization code part
– Two-language translation of the localization part
– Testing the application plus reporting and fixing the bugs
– Monitoring the good progress of the project
Contacts:
Phone number: 0747635872 – Project Manager Magurean Fineas
Email address: fineasm@yahoo.com
Help!: For further information please contact us via phone or email, which can be found at the
"Contact Us" section.

Limba francez ă:

”Membres:
– Magurean Fineas: chef de projet
le programmeur principal
le testeur principal
Tâches:
– Rédaction de cahiers des charges, informations de projet
– Rédaction de la base de données du projet et de la section de rapport de bogues
– Accorder le diagramme Grantt pour le suivi du développement du projet
– Elaboration du plan de test
– Rédaction du design de l'application
– Création et implémentation du code d'application et de la partie code de localisation
– Traduction bilingue de la partie localisation

27
– Tester l'application, signaler et corriger les bugs
– Suivre le bon déroulement du projet
Coordonnées:
Numéro de téléphone: 0747635872 – Chef de projet Magurean Fineas
Adresse e -mail: fineasm@yahoo.com
Aide!: Pour plus d'informations, veuillez nous contacter par tél éphone ou par courrier électronique,
à la section "Contactez -nous".

⚫ Rapoarte Programare

Build -ul 1: a fost preg ătit și implementat din data de 05.01.2019 – 10.01.2019
Primul build a fost implementat cu succes în urma informa țiilor prim ite din documenta ția “Design
aplica ție implementare” și a fost predat echipei de testa re. În urma test ării s-au raportat 3 bug -uri
care au fost fixate de c ătre noi echipa de programare și au fost introdu se în urm ătorul build.
Nu au fost întâmpinate probleme în înțelegerea și implementarea documenta ției în tool -ul folosit
“html” de c ătre membrii echipei.
Build -ul 2: a fost preg ătit și implementat din data de 13.01.2019 – 14.01.2019
Al doilea build a fost implementat cu success și trimis echipei de testare. S -a întâmpinat o problem ă
de către echipa de testare și a fost raportat ă. Acest bug a împiedicat echipa s ă continue testarea
deoarece bug -ul era major. În urmatorul build acest bug a fost fixat de c ătre echipa de programare.
Alte probleme majore nu au fost identificate.
Build -ul 3: a fost preg ătit și implementat din data de 16.01.2019 – 17.01.2019
Al treilea build a fost implementat cu success și trimis echipei de testare. În acest build a intervenit
echipa de localizare pentru a putea implementa traducerile în cele dou ă limbi: englez ă și francez ă.
În urma test ării build -ului s -au raportat 2 bug -uri de localizare. Aceste bug -uri au fost rezolvate în
build -ul final ce urmeaz ă să fie trimis echipei de testare.

28
Build -ul final: a fost pregatit și implementat din data de 18.01.2019 – 20.01.2019
Build -ul final a fost preg ătit și trimis echipei de testare. În urma test ării build -ului s -a constatat c ă
toate problemele sunt fixate și produsul este gata de lansare.

2.3 Departamentul de testare si localizare
⚫ Cerin țe și specifica ții testare :
➢ Build 1:
În primul build vor fi implementate urm ătoarele func ționalit ăți:
– Interfa ța grafic ă de design a aplica ției
– Culorile și modelele de unit ăți prezente în aplica ție

▪ Testare Black Box:
Testare Smoke:
– se va începe testarea prin a ve rifica dacă pagina aplica ției se deschide cu success
– se va testa dac ă conținutul aplica ției este acela și ca și func țional itățile implementate mai
sus
Testare de Explorare:
– se vor testa p ărțile aplica ției care sunt implementate și în acel și timp se va învăța software –
ul

➢ Build 2:
Este implementat ă funcționalitatea de rulare a unit ății principale, butoanele de schimbare a culorii
unității principale și butonul de traducere sunt implementate
▪ Testare Func țional ă:
Testare de Regresare :

29
– aici se vor testa bug -urile din build -ul 1 (bug -urile cu numarul 1, 2, 3) și se va vedea dac ă
încă sunt prezente
Testa re de Integrare:
– se va testa func ționalitatea de rulare a aplica ției principale, respectiv dac ă butonul de rulare
este în armonie cu mi șcarea unit ății principale
– se va testa func ționalitatea butoanelor de schimbare de culoare a unit ății principale, dac ă
culoarea din buton corespunde cu cul oarea unita ții principale

➢ Build 3:
Este implementat textul de localizare care este tradus în 2 limbi (englez ă și francez ă) și
funcționalitatea butonului de traducere
▪ Testare Black Box:
Testare de Localizare:
– aici se va testa dac ă textul introdus corespunde cu cel din documentul de “Informa ții text
traduceri”
– se va testa dac ă funcționalitatea butonului de traducere se deruleaz ă corect
– se va testa dac ă traducerea întregului text este corect ă în cele dou ă limbi (englez ă și
francez ă) și în limba de baz ă
Testare de Regresie:
– aici se vor testa bug -urile din build -ul 2 (bug -ul cu numarul 4) și se va vedea dac ă încă sunt
prezente

Testare de Acceptare:
se va testa daca aplica ția ruleaz ă correct pe sistemul de operare Windows 10, browser -ele Google
Chrome , Microsoft Edge, Mozilla Firefox, Opera, si configurația minima de sistem : procesor I ntel
HD Graphics , 2 Gb RAM ddr3, placa video 1Gb VRAM

30
➢ Build -ul final:
▪ Testare de Regresie:
– se vor te sta bug -urile din build -ul 3 (bug -urile cu numarul 5, 6) și se va vedea dac ă încă
sunt prezente
▪ Testare de Compatibilitate:
– se va vedea dac ă cerin țele aplica ției sunt îndeplinite dup ă ce aplica ția este testat ă de către
client

➢ Planul de testare:
➢ Introducere :
Planul de testare a fost creat pentru a comunica abordarea de testare membrilor echipei. Acesta
include obiectivele, domeniul de aplicare, programul, riscurile și abordarea. Acest document va
identifica în mod clar c are vor fi rezultatele test ului și ce se consider ă în afara domeniului de
aplicare.
➢ Obiective :
Programul “Word ” este un instrument pentru a crea și a stoca teste, precum și rezultatele execut ării
acestor teste. Echipa de testare este responsabil ă de testarea produsului și de asigurarea c ă acesta
corespunde nevoilor clientului . Echipa de testare este at ât clientul, c ât și testerul din acest proiect.

Prima fază a proiectului va livra TC (Test Case) cu func ționalitate pentru a crea și a stoca teste le
manuale. Acest lucru va permite echipei de testare să înceap ă transferul testelor c ătre noul
sistem. Trebuie s ă conțină toate funcționalit ățile și acest lucru este considerat mai important dec ât
data livr ării a proiectului .

➢ Domeniu :
Faza ini țială va include toate cerin țele "trebuie s ă aibă". Acestea și orice alte cerin țe care trebuie
incluse, trebuie s ă fie testate. La sf ârșitul fazei 1, un tester trebuie s ă fi urmărit acești pași :
– Crea ți un test manual cu c âți pași este necesar
– Acest test manual trebuie salvat
– Trebuie să conțină posibilitatea de a putea fi vizualizat la rularea testului

31
– Trebuie să fie introduse rezultatele și comentariile corespunz ătoare
– Rezultate

Pe m ăsura ce echipa lucreaz ă cu produsul, ei vor defini nevoile celei de -a doua faz ă.
Încercarea de încărcare nu va fi considerat ă parte a acestui proiect, deoarece baza de utilizatori
este cunoscut ă și nu constituie o problem ă.
Rescrierea, mutarea sau portarea cazurilor de testare e xistente din document ul Word nu este
considerat ă parte a acestui proiect.

⚫ Ipoteze / riscuri :
➢ Ipoteze :
Aceast ă secțiune listeaz ă ipotezele care sunt f ăcute specifice acestui proiect.
– Livrarea produsului este în format pe care echipa de testare îl poate verifica.

➢ Riscuri :
Următoarele riscuri au fost identificate și acțiunea corespunz ătoare a fost identificat ă pentru a
diminua impactul acestora asupra proiectului. Impactul (sau gravitatea) riscului se bazeaz ă pe
modul în care proiectul ar fi afectat în cazul declan șării riscului. Punctul de declan șare este ceea
ce reprezint ă un eveniment sau eveniment care ar f ace ca riscul sa devin ă o problem ă care trebuie
abordat ă.

32
# Risc Grad Efect Plan de atenuare
1 Domeniul de aplicare –
deoarece testerii devin
mai familiariza ți cu
instrumentul, vor dori
mai mult e
funcționalități Ridicat Întârzieri
pentru data
implement ării În fiecare itera ție,
funcționalitatea, va fi
monitorizat ă îndeaproape.
Priorit ățile vor fi stabilite și
discutate de către părtile
interesate
2 Modific ările aduse
funcționalit ății pot
anula testele deja scrise
și se pot pierde cazuri
de testare Ridicat Pierderea
tuturor
cazurilor de
testare Exporta ți date înainte de
orice actualizare
3 Livrarea pe s ăptămână
nu este posibil ă
deoarece dezvoltatorul
lucreaza în afara site –
ului Mediu Produsul nu a
fost livrat la
timp Definirea priorit ăților
dezvoltatorului
Tab. 1 Tabelul de riscuri ale proiectului

⚫ Abordare de testare :
Proiectul foloseste o abordare Agile , cu itera ții săptămânale. La sf ârșitul fiec ărei s ăptămâni
cerin țele identificate pentru aceast ă iterație vor fi livrate echipei și vor fi testate.

Testarea experimental ă va juca un rol foarte important , deoarece echipa nu a folosit niciodat ă acest
tip de testare și va învăța cum funcționează . Testele pentru func ționalitatea planificat ă vor fi create
și ad ăugate la TC, deoarece vom ob ține itera ții ale produsului.

⚫ Mediu de testare :
Un server nou este necesar pentru serverul web, aplica ția și baza de date.

33
⚫ Momente / rezultate :
➢ Program de testare :
Schema ini țială de testare:

Nume sarcin ă Start Finalizare Efort Comentarii
Planificarea de testare 05.01.2019 10.01.2019 5 z S-a întocmit plan
test-ul
Consulta ți documentele privind
cerin țele 10.01.2019 10.01.2019 1 z Toți testerii au luat
la cuno știință
documenta ția
Crea ți estim ările ini țiale ale
testelor 10.01.2019 11.01.2019 2 z Estim ările ini țiale
ale test elor au fost
finalizate
Implementa ți mai întâi mediul
de testare QA 10.01.2019 10.01.2019 1 z Fiecare tester în
parte a primit task –
uri
Testarea func țional ă – Iterație 1 10.01.2019 12.01.2019 3 z Au fost g ăsite și
raportate 3 bug -uri
Iterația 2 se desf ășoară în
mediul de testare QA 14.01.2019 16.01.2019 3 z A fost gasit și
raportat un bug
major
Testarea func țional ă – Iterația 3 17.01.2019 18.01.2019 2 z Au fost g ăsite și
raportate 2 bug -uri
Testarea prin regresie 14.01.2019 20.01.2019 7 z Toate bug-urile au
fost fixate
Rezolvarea defectelor finale și
testarea final ă a construirii 20.01.2019 21.01.2019 2z S-au testat ultimele
funcționalit ăți
Eliberare în produc ție 05.02.2019 – – Produsul este
terminat
Tab. 2 Tabelul planului de testare

34

➢ Repere
Livrabil Pentru Data
Planul de testare Manager de proiect;
Directorul QA; Echipa de
testare 10.01.2019
Traceabilitatea Manager de proiect;
Directorul QA 10.01.2019
Rezultatele testului Manager de proiect 21.01.2019
Raport privind starea
testului Directorul QA 10.01.2019 – 20.01.2019
în fiecare zi
Valori Toți membrii echipei 1 – Magurean Fineas
Tab. 3 Tabelul reperelor proiectului

⚫ Rapoarte Testare

Build -ul 1: testat din data de 10.01.2019 – 12.01.2019
Testarea a progresat în cele 3 zile de p ână când a fost trimis urm ătorul build. Pe parcursul test ării
au fost întâmpinate 3 bug -uri care au fost raportate în baza de date oficial ă și care trebuiesc
corectate în urm ătorul build.
În mare parte ceea ce este implementat în primul build func ționeaz ă iar infrastructura este prezent ă
așa cum se cere în documenta ție, mai pu țin câteva probleme de grafic ă a culoruiilor interfe ței.
Bug-urile au fost detectate și raportate cu secces la timpu l potrivit.
Build -ul 2: testat din data de 14.01.2019 – 16.01.2019
Tetarea a progresat în cele 3 zile. De altfel s-a re-testat cele 2 bug -uri prezente în primul build și
s-a constatat c ă sunt fixate , fapt care a și fost raportat în baza de date oficial ă. Pe parcursul test ării

35
s-a gasit un bug major care a fost raportat și dac ă nu este fixat p ână în build -ul urm ător nu se poate
continua testarea.
Build -ul 3: testat din data de 17.01.2019 – 18.01.2019
Testarea a progresat în cele 2 zil e. De altfel s -a facut și testarea de localizare și partea de re -testare.
Bug-ul care a fost gasit în build -ul 2 este fixat și astfel se poate continua testatrea func ționalit ății
de mi șcare a unit ății principale. Pe parte de localizare s -au găsit 2 bug -uri care au fost raportate în
baza de date oficial ă și se așteaptă să fie fixate p ână la build -ul final.
Build -ul final: din data de 20.01.2019 – 21.01.2019
Testara a luat sf ârșit cu acest build. Bug -urile de func ționalitate care au fost prezente în build -ul 3
au fost fixate, inclu sive toate bug -urile existente de p ână acum. Produsul este gata de lansare.

⚫ Localizae :
➢ Documentatie Localizare :
▪ Aspecte Localizate :
Aten ție echipelor de programare (implementare a codului) de localizare și de testare; vom avea de
tradus aplica ția în dou ă limbi, pe l ângă cea implementat ă de la început. Vom avea de tradus în
limba englez ă și în limba francez ă. Aceast ă parte important ă va fi implementat ă numai în build -ul
cu numarul “3” al aplica ției adic ă în buildul final. Documentele le ve ți primi încă de la primul
build a șa că se dorește mare aten ție din partea voastr ă în a nu implementa partea de localizare
prematur .
▪ Elementele din interiorul aplicatiei care trebuie traduse :
– avem în primul r ând func ționalitatea de “accelereaz ă” care este sub forma unui buton cu
funcția de a accelera unitatea principal ă “patratul”
– pe urm ă sunt prezente încă două butoane care schimb ă culorile “patratului”, pe fiecare
buton este scris culoarea , respectiv atributul care va fi însușit “patratului”. Vrem ca cele
două butoane sa fie traduse în cele dou ă limbi respectiv englez ă și francez ă

36
– între butonul “accelereaz ă” și butoanele pentru a schimba culoarea “patratului” avem
implementat dou ă rânduri de text care va trebui tradus în cele dou ă limbi respectiv englez ă
și francez ă
– în partea dreapt ă a pagini web vom avea implementat text cu date referitoare la : membrii
echipei de dezvoltare a aplica ției, sarcinile care au fost alocate membrilor echipei, datele
de contact si fuc ționalitatea de “ajut ă”; vrem ca și aceste informa ții să fie traduce în cele
două limbi englez ă respectiv francez ă

➢ Pentru echipa de programare:
Cu ajutorul acestui document și a documentului de informa ții referitoare la datele aplica ției
(respectiv a textului care va trebui implementat) ve ți implementa direct în sursa de cod toate
informa țiile care vin de la Project Manager. Recomand c itirea cu aten ție a documentului de
localizare și a documentului de informa ții pentru a putea implementa cu success sarcinile.
➢ Pentru echipa de testare :
Dupa ce au fost implementate toate elementele de localizare de catre echipa de programare, dorim
testarea amanuntita de catre tester -ii specializati in traducere. Dorim ca fiecare “cuvant” sa fie
tradus cu exactitate si orice bug referitor la traducere dorim sa fie raportat in baza de date a bug –
urilor “Bugzilla” pentru a fi intampinate de catre progr amatori si ulterior fixate.

2.4 Departamentul de vânzări
Un departament de vânzări este legătura directă dintre produsul sau serviciul unei companii
și clienții săi. Cu toate acestea, un departament de vânzări bine instruit face mai mult decât să facă
vânzări. Personalul departamentului de vânzări dezvoltă relații cu clienți. Mai mult, un agent de
vânzări de calitate ajută la identificarea nevoilor unice ale clienților și se asigură că aceste nevoi
sunt îndeplinite. Având în vedere că vânzătorii au contac te directe cu clienții în mod continuu, ei
devin interesați de informațiile personale care ajută la îmbunătățirea interacțiunilor vânzărilor.
Profesioniștii de vânzări bine pregătiți personalizează vânzările pe teren , clienților individuali și
învață cum s ă le îndeplinească nevoile.

37
⚫ Care sunt obiectivele departamentului de vânzări:

Un departament de vânzări are mai multe obiective, pe lângă realizarea de vânzări.
Deoarece departamentul de vânzări este adesea legătura dintre clienții și produsul sau serviciul
oferit de companie, există și alte funcții necesare pe care un departament de vânzări trebuie să le
îndeplinească:
➢ Conversia vânzărilor: desigur, principalul obiectiv al departamentului de vânzări este de a
face vânzări. Cu toate acestea, ele tre buie, de asemenea, să o facă în mod eficient și cât mai
ieftin posibil. Nu este suficient să se colecteze informații despre cărțile de credit și să se
proceseze o comandă. Un departament de vânzări este întotdeauna preocupat de
îmbunătățirea ratei de conve rsie. O rată de conversie este procentajul clienților care
finalizează o vânzare. Deci, dacă echipa de vânzări vorbește cu 100 de potențiali clienți pe
zi și 20 dintre aceste conversații duc la o vânzare, atunci echipa are o rată de conversie de
20%. Un de partament de vânzări bine lubrifiat caută mereu modalități de a -și îmbunătăți
rata de conversie. O conversie mai bună înseamnă că întreprinderea cheltuie mai puțini
bani pentru a transforma fiecare client, rezultând profituri mai mari.
➢ Menținerea cliențilo r: echipa de vânzări este responsabilă pentru păstrarea clienților, o
sarcină monumentală importantă. Costă o afacere de cinci până la 25 de ori mai mulți bani
pentru a atrage noi clienți decât pentru a menține clienții existenți. Cercetările arată în plus
că creșterea ratei de reținere a clienților cu numai 5% poate determina creșterea profiturilor
de 25 -95% pentru afacere. Are sens totdeauna ca clienții să fie satisfăcuți . Aici intră echipa
de vânzări. Ca punct de contact direct pentru afacere, departamen tul de vânzări creează
relații valoroase cu clienții. O echip ă de vânzări care urmare ște cu clien ții și se asigur ă că
sunt ferici ți cu produsul sau serviciul furnizat este crucial. Deci, un obiectiv al unui
personal de vânzări este asigurarea că clienții r ămân fericiți și continuă să facă afaceri cu
compania.
➢ Creșterea afacerilor: departamentul de vânzări este unul dintre cele mai importante sectoare
ale afacerilor pentru creștere economică. Prin construirea de relații și menținerea clienților
fericiți, rec omandările cresc. În plus, clienții mulțumiți sunt de obicei dispuși să lase
recenzii pozitive pentru compani e.

38
➢ Printr -un serviciu de clienți remarcabil, clienții devin loiali și cântă laudele altora, aducând
noi afaceri. Mai mult, un personal de vânzări de calitate va fi mereu în căutarea unor noi
clienți potențiali care dezvolte compania în continuare.

2.5 Departamentul de hardware
⚫ Structura departamentului :
➢ Atribu ții generale ale departamentului:
– conducerea departamentului este asigurată de căt re un Sef de Departament subordonat
direct conducerii superioare a companiei
– organizează și răspunde de buna funcționare și corectitudinea sistemelor informatice, a
sistemelor de calcul și a bazelor de date în sistem electronic ale companiei
– stochează informațiile pe suport și asigură arhivarea lor
– asigurarea primului nivel de int ervenție în cazul defectării echipamentelor (calculatoare,
imprimante) și contactează firmele de service în cazul defectării acestor echipamente
– asigurare stocare arhivă pe suport și întreținerea programului de arhivă
– asigur ă respectarea legislației în domeniul tehnicii de calcul și al softului
– asigură funcționarea cu licență a programelor implementate
– administrare rețea – instalare cabluri UTP, prize rețea, configurare etc
– administrare server – creare utilizatori, grupuri, partajare resurse în resurse (imprimante,
CDROM)
– instalări sisteme de operare, software (imprimante, etc)
– asigură secretul informației conform legilor în vigoare
– îndeplinește și alte sarcini repartizate de conducere
– actualizează și modific ă programele c are gestionează baza de date
– asigurarea bunei funcționări a rețelei de calculatoare și a echipamentelor hardware din
cadru l companiei
– asigurarea primului nivel de intervenție în cazul defectării echipamentelor audio -video
(depanare hardware)
– comunicarea permanentă cu firmele care asigură garanția echipamentelor hardware
– o bună funcționare a serverelor de telefonie, a sistemelor de operare și a aplicaților de

39
sistem
– realizarea periodică a backupurilor
– întreținerea tehnicii de calcul și evidența echipamen telor de comunicatii din cadrul
companiei
– asigurarea și conectarea fizic ă a diverselor loca ții la re țeaua IT a companiei
⚫ Administrarea sistemului
Administrarea sistemului și securizarea reprezintă aplicarea unui set de combinații de sarcini
în vederea monitorizării și gestionării infrastructurii IT. Aceasta reprezintă un concept mult mai
larg în comparație cu cunoscuta rețea. Administratorii de sistem nu sunt programatori, deși au
nevoie de anumite cunoștințe în acest domeniu. În funcție de tipu l aplicației, de numărul de
utilizatori, în atribuțiile lor intră controlarea și menținerea bunei funcționări a rețelei.
Managementul companiilor din zilele noast re se bazează pe informații corecte care sunt
condiționate de utilizarea tehnologiei moderne de comunicare, care subliniază și mai mult
importanța administratorilor de sistem. Administrarea și prelucrarea informațiilor sunt direct
dependente de aplicarea t ehnologiei informației, de care este responsabil administratorul de sistem.
Sistemul de informații trebuie să fie disponibil 24 ore pe zi, 7 zile pe săptămână, orice cădere a
sistemului putând avea repercursiuni grave. Activitatea companiilor depinde de pu terea sistemului
de informații, ceea ce înseamnă că trebuie să existe un plan bine pus la punct de sistemul de
administrație de care se ocupă, bineînțeles, administratorul de sistem.

3. Necesitatea unei baze de date:
3.1 Inroducere
Filosoful Aristotel nu avea o bază de date – oricum una electronică. Dar el a crezut în
importanța diferențierii și analizării datelor. În lucrarea "Categorii", el a prezentat 10 moduri de a
descrie un lucru. Acestea includ cantitatea, calitatea, locul, ti mpul, poziția și acțiunea. El a fost
pregătit să grupeze date, să stabilească inter -relațiile sale și să ajungă la concluzii. O asemenea
pledoarie pentru clasificare – pe care Aristotel la aplicat biologiei, printre altele – a fost o forță

40
motrice în crear ea mentalității analitice pentru întreaga civilizație occidentală. El a crezut că modul
în care abordăm datele este important.
În timp ce grecii antic i, în mod surprinzător, au calculat date astronomice cu computere
analogice uimitoare, cum ar fi mecanism ul Antikythera, nu suntem conștienți de datele stocate sau
analizate. Dar, dacă ar fi posibil, anticii ar fi fost fericiți să angajeze un sistem de gestionare a
bazelor de date (DBMS) pentru a -și pune buna gândire la folosire. Există multe motive pentru a
susține ideea că oricine ar putea folosi un sistem de gestionare a bazelor de date bune în viața și
munca de zi cu zi .

Fig. 7 Schem a mecanismului Antikzthera al planetelor

41
3.2 De ce este nevoie de o ba ză de da te?
➢ Un sistem de gestionare a bazelor de date (DBMS) este o extensie a logicii umane
De ce am pus paralela de referire la filosofie și biologie într -o lucrare despre bazele de date pentru
profesioniștii din domeniul tehnic ? Ei bine, atâta cât iubim mașinile digitale și ceea ce pot face
pentru viața noastră, noi nu am mers încă cu ei. Iar puterile computaționale de date despre carne și
sânge le dăm computerelor noastre, este doar extinderea puterii raționamentului intelectulu i uman.
Baza de date care este creat ă pentru a gestiona cunoștințele umane va îmbunătăți abilitățile de a
corela, de a interoga și de a raporta informațiile colectate ale companiei . Gestionarea companiei
cu un DBMS bine dezvoltat este un lucru logic de făc ut.
➢ Computerele pot răspunde rapid la multe întrebări
Alex : "Fini, să-ți pun adresa de e -mail, te rog?"
Fini: "Sigur, este fineasm @yahoo.com ".
Între timp, Fini se încurcă puțin că a fost pentru a cincisprezecea oară c ând i s-a cerut adresa
de e-mail în timpul primei sale săptămâni de angajare. Fini este șocat să afle că nu există o bază
de date centrală în care să lucreze și toată lumea pare să fi dezvoltat prop riile foi de calcul cu
diferite niveluri de exactitate și de completare. Chiar și colecțiile simple de date cum ar fi o listă
de contacte de bază sau o tabelă de baze de date sunt uneori neglijate de organizații care se grăbesc
să stingă incendii și să fie văzute ca fiind productive.
Pierderea cumulată a timpului în întreaga organizație de către persoanele care caută astfel
de informații ar putea fi destul de surprinzătoare. Dar o bază de date centralizată, ușor accesibilă
de toți, poate oferi răspunsuri r apide la întrebări care sună izbitor de asemănătoare cu cele ale
filosofului antic antic.
➢ Unele întrebări pot fi foarte complicate
A fi capabil de a explora date și de a descoperi informații este motivul unor astfel de idei
noi, cum ar fi miniere de date și analize. Dar bazele de date convenționale au răspuns la întrebări
complexe de zeci de ani. Poate dori m să afl ăm câți angajați sunt calificați într -o anumită zonă. O
interogare simplă a unei foi de calcul sau a unei căutări a datelor într -un director ar putea oferi ușor
informațiile de care ave m nevoie. Dar dacă trebuie să localiz ăm numai angajați calificați dintr -un
anumit stat care au cinci ani de experiență, sunt dispuși să se mute și să vorbească o anumită limbă

42
străină? Pentru a interoga date bazate pe mai multe criterii, ave m nevoie de un sistem de gestionare
a bazelor de date. Cu cât interogarea este mai complexă, cu atât mai mult va trebui să fie DBMS –
ul. Un sistem bun ne spune tot ce trebuie să ști m cu câteva clicuri de mouse.
➢ Suntem ușor copleșiț i de informații
Ținând -o simplă este o idee bună în orice domeniu al vieții. Nimeni nu vrea să fie
împotmolit cu cerințe inutile sau lucrări suplimentare. Dar o bază de date bună are, în general, un
frontsimplu care este înțele s intuitiv de către utilizat or și structurează datele astfel încât oamenii
să înțeleagă fără prea multă dificultate. În timp ce terminologia și conceptele din date pot fi
specifice competenței de bază a utilizatorului, experiența utilizatorului însuși face posibilă
concentrarea asupra datelor, mai degrabă decât a complexității legăturilor și formularelor bazei de
date. O bază de date bine organizată face ca o mare comoară a informațiilor să fie mai ușor de
gestionat și oferă utilizatorului doar ceea ce are nevoie atu nci pentru a -și face treaba mai bine.
➢ Automatizarea este cheia eficienței
În mod normal, ne uităm la automatizare pentru a efectua sarcini repetitive care ar lua mult
mai mult cu mâna. ENIAC a creat tabele de ardere pentru planificatorii militari în câtev a minute,
în comparație cu săptămânile necesare muncii umane pe o sarcină similară. Charles Babbage a
strigat pentru o soluție cu aburi pentru calcularea graficelor de navigație. Ne bazăm pe computerul
personal pentru a face față sarcinilor misionale care ar fi putut fi generate de timpul și munca
intensă pentru generațiile anterioare.
Compilarea unei game largi de inventar sau a altor astfel de informații și punerea la
dispoziție pentru interogări și rapoarte este o necesitate în lumea afacerilor de ast ăzi. O căutare
rapidă a bazei de date Google oferă rezultate aproape instantanee pe baza analizei a milioane de
surse. Pe măsură ce colecția de date crește, v om avea nevoie de procese automate mai sofisticate
pentru a găsi nivelul de eficiență dorit pentru compani e.
Excepția la aceasta ar putea fi atunci când ar fi nevoie de mai mult timp pentru a crea
procesul automatizat decât pentru a efectua operația manuală în sine. Este destul de ușor să ne
abținem în dezvoltarea unui instrument digital atât de mult încât să dev enim cu adevărat exagera ți.
Să presupunem că, în momentul în care mergem sa dezvoltăm aplicația acelui ucigaș,
administratorul vechii școli, care gestionează consumabilele de birou, ar fi putut să o facă (crima)
și să se ducă acasă la cină. Un DBMS este un instrument care ar trebui folosit pe termen lung.

43
➢ Un DBMS este mai bun decât procesele manuale în multe moduri
Mediile de date sunt compuse din date, hardware, software, oameni și proceduri.
Avantajele utilizării bazelor de date au fost susți nute de mulți și pot fi marcate cu caracteristici
specifice ale SGBD. De exemplu, în timp ce foile de calcul Excel și bazele de date de acces sunt
utilizate în general de o singură persoană, sistemele de gestionare a bazelor de date adevărate
permit accesu l simultan al mai multor utilizatori. O bază de date este o singură aplicație software
care poate folosi mai multe tabele, formulare și rapoarte, decât o mulțime de foi de calcul
gestionate de oameni în întreaga companie . O bază de date bună este un magazin unic pentru a
aduce oamenii și procesele împreună.
➢ Sunte m interesa ți în realizarea și economisirea de bani, nu -i așa?
Ar trebui să fim toți fericiți pentru că sistemele de gestionare a bazelor de date ne pot
îmbunătăți viața și munca. Dar o mare parte din activitatea corporatistă este preocupată de a face
mai mulți bani sau de a reduce orele de muncă excesive în îndeplinirea unor obiective specifice.
Eficiența produsă de sistemul de gestionare a datelor va mer ita probabil timpul, banii și efortul
depus pentru a finaliza baza de date.
➢ Concluzie
Logica sunetului este utilă pentru orice aspect al vieții. Este, de asemenea, o parte
integrantă a gestionării bazelor de date. În timp ce s -ar putea să fi m mai înclinaț i să lucr ăm pe
propriul DBMS după citirea acestui subiect , există un punct al susținerii că ave m nevoie de un
sistem de gestionare a bazelor de date. De asemenea, ave m nevoie de un bun designer de baze de
date. Aceasta este o persoană care se poate așeza c u stilou și hârtie și schițează diagrame care arată
fluxul ideal de date și cele mai bune modalități de a introduce, captura, analiza și raporta informații.
După toți acești ani, avem încă nevoie de categorii și de clasificări pentru a dist ribui corect date le.
Experții bazei de date buni fac baze de date bune. Viața este complicată și uneori ave m nevoie de
tot ajutorul pe care îl pute m găsi pentru a găsi abordarea corectă a datelor cu care ne confruntăm
în fiecare zi. Ave m nevoie de un sistem de gestionare a bazelor de date.

44
4. Baza de date MongoDB
4.1 Introducere
Odată cu creșterea datelor din întreaga lume, a existat un interes observabil și în creștere
în jurul valorii de val de bază de date non -relaționale, de asemenea, cunoscut sub numele de
"NoSQL". Întreprinderile și organizațiile caută metode noi de gestionare a inundațiilor de date și
sunt îndreptate către instrumentele și sistemele de gestionare a bazei de date alternative, care sunt
diferite de sistemele tradiționale de baze de date rela ționale. Aici vine MongoDB în imagine.
⚫ Ce este MongoDB
Ca o definiție, MongoDB este o bază de date open source care utilizează un model de date
orientat spre documente și un limbaj de interogare nestructurat. Este unul dintre cele mai puternice
sisteme și baze de date NoSQL din jurul zilelor noastre
Fiind un instrument NoSQL înseamnă că nu utilizează rândurile și coloanele obișnuite care
se atribuie atât de mult managementului bazelor de date relaționale. Este o arhitectură construită
pe colecții și docum ente. Unitatea de bază de date din această bază de date constă dintr -un set de
perechi cheie -valoare.
Permite documentelor să aibă domenii și structuri diferite. Această bază de date utilizează
un format de stocare a documentelor numit BSON, care este un stil binar de documente JSON.
Modelul de date pe care îl urmează MongoDB este unul foarte elastic, care permite să se
combin e și să se stocheze date de tipuri multivariate fără a fi nevoie de compromisuri în ceea ce
privește opțiunile puternice de indexar e, accesul la date și regulile de validare. Nu există o perioadă
de nefuncționare atunci când se dorește să se modific e dinamic schemele.

45
4.2 Arhitectura

Fig. 8 Arhitectura bazei de date MongoDB NoSQL
⚫ Baza de date
Cu cuvinte simple, poate fi numit containerul fizic pentru date. Fiecare dintre bazele de date are
propriul set de fișiere în sistemul de fișiere cu mai multe baze de date existente pe un singur server
MongoDB.
⚫ Colecția

Un grup de documente de bază poate fi numit colecție. Echivalen tul RDBMS al colecției este un
tabel. Întreaga colecție există într -o singură bază de date. Nu există scheme când vine vorba despre
colecții. În interiorul colecției diferitele documente pot avea domenii variate, dar în cea mai mare
parte documentele dintr -o colecție sunt destinate aceluiași scop sau servesc aceluiași scop final.
⚫ Documentul
Un set de perechi cheie -valoare poate fi desemnat ca un document. Documentele sunt asociate cu
scheme dinamice. Beneficiul de a avea scheme dinamice este acela că documentul dintr -o singură
colecție nu trebuie să aibă aceeași structură sau câmpuri. De asemenea, câmpurile comune din
documentul colecției pot avea diferite tipuri de date.
4.3 Avantaje
⚫ Model flexibil de date
MongoDB stochează date în documente JSON fle xibile, ceea ce face persistența datelor și
combinarea ușoară. Obiectele din codul de aplicație sunt cartografiate pe modelul de document,

46
datorită cărora lucrul cu datele a devenit ușor. Este inutil să spun em că controalele de control al
schemelor, accesu l la date, agregările complexe și funcționalitatea bogată de indexare nu sunt
compromise în nici un fel. Fără timp de nefuncționare, se poate modifica dinamic schema. Datorită
acestei flexibilități, un dezvoltator trebuie să se îngrijoreze mai puțin de man ipularea datelor și mai
mult despre utilizarea acestor date.
⚫ Stochează volume mari de date care adesea au o structură mică sau deloc
Bazele de date relaționale stochează date structurate. Dar pentru creșterea informațiilor
nestructurate – de exemplu, preferințele unui client, locația, achizițiile anterioare etc – o bază de
date NoSQL nu stabilește limite și permite să se adauge diferite tipuri de date pe măsură ce nevoile
se schimbă Deoarece MongoDB este flexibil și bazat pe documente, se poate stoca acele puncte
de date binare JSON (denumite BSON) într -un singur loc fără a trebui să se definească ce "tipuri"
de date sunt în prealabil.
⚫ Profit ă la maximum de computerele cloud și de spațiul de stocare
Stocarea pe bază de cloud este o soluție exce lentă de economisire a costurilor, dar necesită
distribuirea cu ușurință a datelor pe mai multe servere pentru a crește. MongoDB poate încărca un
volum mare de date și oferă o mulțime de flexibilitate și disponibilitate într -un mediu bazat pe
cloud, cu sol uții integrate de împărțire care ușurează împărțirea și împrăștierea datelor pe mai
multe servere.
⚫ Dezvoltare și lansare rapidă
Dacă proiectul este dezvoltat în cadrul sprinturilor Agile de două săptămâni, în timp ce se
fac noi iterații rapide sau dacă se dorește să se actualiz eze frecvent structura de date fără prea multe
întreruperi între versiuni, modificarea unei baze de date relaționale va încetini procesul . Cu
schemele dinamice ale MongoDB, se poate încerca lucruri noi și rapid e. Datele nu trebuie p regătite
anticipat, iar echip a poate încorpora ceva nou, rapid și la un cost mai mic.
⚫ Scalarea arhitecturii bazei de date este eficient și ieftin ă
Cu MongoDB, este ușor ca datele să se răspândească de pe hardware pe site sau în cloud
fără a avea nevoie de software suplimentar.

47
4.4 Apli cația
În urma contsruirii unei idei complexe despre partea internă și de bază a unei companii și
în urma înțelegerii acestea și a departamentelor care alcătuiesc o astfel de organizație, cea mai
bună opțiune este exemplificarea lucrării prin o aplicație care reflectă b aza de date a companiei.
Aplicația va fi o bază de date în care vom regăsi atât elemente descirse în lucrare cât și elemente
noi care țin de anumite departamente, pentru a vedea și a înțelege cum arată o astfel de bază de
date. Ne vom folosi de MongoDB ca baza de date pentru a crea diferite colecții și a le popula cu
diferite documente specifice colecțiilor. Acestea vor reflecta structura internă de la angajați și până
la proiectele care se desfășoară cu detalii despre fiecare, cât și multe alte elemente.
Vrem să proiectăm o baza de date pentru a vedea cum arată și cum se lucrează cu ea.
Aceasta va deține toate informațiile esențiale care sunt disponibile fiecărui angajat nu numai ca să
lucreze cu ele, ci multe informații sunt necesare a fi stocate pentru a nu se pierde deoarece este
nevoie ca să se țină evidența lor pe parcursul trecerii timpului. După cum am spus, fiecare
department va lucra pe o astfel de bază de date pentru a primi și prelua informații referitoare la
proiectele în desfășurare și totodata pentru a urca iformații care să ajungă la alte departamente cât
și la client.
Ca o mică descriere a ceea ce va conține baza noastră de date, vom începe cu colecția de
“Angajați” unde sunt stocate informatii private despre toți angajații firmei. Aceste in formații se
pot referi la: un ID pentru fiecare angajat, nume și prenume, varsta, adresa, statusul lor în firmă
etc. Este nevoie ca să se țină evidența angajatiilor pentru a cunoaste detalii despre ei, pentru a
evidenția statusul lor, pentru a ști adresa l or în cazul în care se întâmplă situații neașteptate, sunt
informatiile generale de care trebuie să dispună orice firmă, deoarce vor veni situații când este
nevoie despre aceste informații

Colecția “Proiecte” va conține informații cu proiectele firmei, pr odusele care ori sunt în
dezvoltare ori sunt lansate. Aceste informații se pot referi la: un ID unic pentru fiecare produs,
numele, platformele care suportă aplicația, genul produsului, prețul etc. Vor fi detalii cu privire
la informațiile esentiale pe car e angajatul trebuie să le vadă, pentru a cunaste de ce dispune

48
produsul, pentru a cunoaște detaliile proiectelor și pe baza cărora își vor exercita munca de zi cu
zi.
Aceste două colecții sunt numai câteva exemple dintre multele colecții care vor exista în
baza de date, cu scopul de a crea o imagine a ceea ce va conține aplicația noastră. Pentru acestea
am pregătit două screenshot -uri/figuri care arată colecțiile în baza de date.

Fig. 9 Colecția “Angajați” din baza de date

Fig. 10 Colecția “Jocuri Video” din gaza de date

49
Concluzii
În această lucrare am abordat existența unei entități în care se produc și se pun în vânzare,
jocuri video. În urma luării la cunoștiință a elementelor din interiorul companiei cât și a nevoii
unei baze de date, cititorii are trebui să aibă o imagine de an samblu mult mai complexă a ce este
nevoie ca un astfel de business să existe. O bază de date capabilă aduce un plus atât companiei cât
și personalului, dacă un viitor cititor are în plan investiția într -o astfel de organizație, recomand ăm
cu încredere util izarea bazei de date MongoDB pentru a pune baza dezvoltării unor produse de
calitate. Pe partea de departamente, nici unul dintre cele descrise în lucrare, nu ar trebui neglijat
sub nici o formă deoarece lucrând împreună într -o armonie strânsă, completează cu baza de date,
produse care vor aduce un profit considerabil companiei. Credem că în urma luării la cunoștiință
a proiectului „Jumping Square ” care a fost prezentat pe parcursul lucrării, cititorul s -a familiarizat
cu etapele prin care un produs de tip joc video trece, realizând că întemeierea unui astfel de proiect
este posibilă pentru cine dorește, este foarte accesibilă unor persoane cu cunoștiințe de baz ă în
domeniul IT și chiar încurajăm inovarea unor astfel de proiecte.
Aducem mulțumiri coordo nator ului științific, Conf. univ. dr. Sitar -Tăut DAN -ANDREI ,
pentru îndrumarea bună și de calitate pe parcursul contruirii acestei lucrări ; pentru răspunsurile și
sugestile primite din partea dânsului în urma neajunsurilor noastre ; pentru răbdarea de a cor ecta și
re-corecta lucrarea până în punctul în care aceasta este gata de prezentare și nu în ultimul rând
pentru acceptarea dânsului ca coordonator al lucrarii noastre.

50
Bibliografie

Abhijeet Vaikar (2017), ”MongoDB tutorial”, slide share,
https://www.slideshare.net/AbhijeetVaikar/mongo -db-102.
Bogdan Oancea și Adina Crețan (2013), Baze de date,
Editura Pro Universitatea, București.
Hector Garcia -Molina, Jeffrey D. Ullman ș i Jennifer Widom (2009), Database Szstems The Complete Book,
Second Edition, Editura Pearson Prentice Hall, Boston, Statele Unite ale Americii.
Luis Gonclaves (2019), Agile methodolohy, ”What is Agile”,
https://luis -goncalves.com/what -is-agile -methodology/ .
Luis Gonclaves (2019), Scrum metodology, ” What is Scrum metodology, everything you need to know,
overview”,
https ://luis -goncalves.com/what -is-scrum -methodology/ .
Nick Harley (2016), ”Software Testing – Is It Time To Fire Your QA Team? ”,
https://raygun.com/blog/software -testing/ .
Ramez Elmasri și Shamkant B. Navathe (2010), Fundamentals of Database Systems, Sixth Edition,
Editura Addison -Wesley Pearson, Boston, Statele Unite ale Americii.
Sitar -Tăut Dan -Andrei (2018), Suport de curs, Eleme nte Avansate de Baze de Dat e.
Video game industry, overview revenue per years ,
https://vgsales.fandom.com/wiki/Video_game_industry .
(2018) ”Program Design and Performance Management Toolkit ”,
https://www.state.gov/wp -content/uploads/2018/12/Program -Design -and-Performance -Management –
Toolkit.pdf .
”MongoDB is new generation database, information technology”,

51
https://barlowminerals.com/unique -essays/mongodb -is-new-generation -database -information -technology –
essay -2322 .
”Guide to localization management” (2004), Rubric, San Francisco, America de Nord,
https://www.issco.unige.ch/en/research/projects/ecolore/localisation/Components/White%20Papers/Guide
%20t o%20Localisation%20Management.pdf .
Wikipedia contribuitori, ”Software testing ”,
https://en.wikipedia.org/wiki/Software_testing .
Wikipedia contribuitori, „Computer programming”,
https://en.wikipedia.org/wiki/Computer_programming