Sunteți pe pagina 1din 8

Sistem de gestiune a unui restaurant

1. Cadrul organizational
1.1 Descrierea companiei.
Compania Fun Software SRL este un startup infiintat de catre Georgescu Theodor
Nikolas impreuna cu niste colegi de facultate si alti prieteni care are ca scop crearea unui
software pentru sistemul de management intern al unui restaurant folosind tehnologiile actuale
si adaptand oferta restaurantelor la nevoile cetatenilor si ale societatii.
Compania doreste sa furnizeze un software competitiv si totodata va furniza si suport
plus alte dezvoltari suplimentare pentru ca produsul sa evolueze in acelas ritm cu nevoile
utilizatorilor. Vom avea ca scop si furnizarea de servicii de marketing pentru promovarea
restaurantelor in interiorul solutie.

1.2 Cadrul organizational.


Firma Fun Software SRL este formata din doi managing parteners si dintr-o echipa
formata din 4 persoane.
Fiind o companie aflata la inceput de drum, nevoile de personal sunt reduse, insa odata
cu evolutia aplicatiei si cresterea numarului de clienti, firma va creste si ca numar.
Compania este organizata astfel:
-

Managing Partener Georgescu Theodor-Nikolas


Managing Partener Popescu Ionut
Software Developer Andrei Oprea
Software Developer Alin Ionescu
Software Developer Ionut Costescu
Software Developer Marian Ieni

Fiind un startup, iar numarul de clienti este redus, Georgescu Theodor devine si
Project Manager, iar Popescu Ionut se ocupa de partea de Marketing pentru promovarea
solutiei, atat in mediul online cat si in mediul offline.

1.3 Incadrarea proiectului in organizatie.


Ideea proiectul apartine celor doi managing parteners, care au vazut o oportunitatea pe
aceasta piata, vazand ca modul de prezentare al restaurantelor si al sistemului de management
nu a evoluat odata cu tehnologizarea excesiva a lumii in care traim.
De aceea Fun Software vine cu o solutie ieftina pentru gestiunea unui restaurant, iar
sistemul de rezervare al meselor va fi revolutionat, deoarece toate restaurantele care vor alege
sa foloseasca solutia noastra software vor beneficia de un cont pe site, unde utilizatorii vor
putea sa isi rezerve mese cu cateva ore, zile si chiar luni inainte.
Avand aceasta solutie patronii de restaurante nu vor mai avea nevoie sa isi faca griji cu
gradul de ocupare al restaurantului, profitabilitatea afacerii deoarece in orice moment ar putea
scoate niste rapoarte care sa ii ajute cu statistici legate de profitabilitate si alti indicatori pe
care ii mai doresc.

2. Descrierea proiectului
1.1 Obiectivul proiectului.
Obiectivul proiectului este de a usura munca restaurantelor in a se face cunoscute pe
piata din Romania, in a usura accesul utilizatorului la informatii legate de restaurante, pentru a
alege restaurantul care ii place si ii satisface toate cerintele culinare, monetare si de
amplasare.
Prin intermediul acestui produs utilizatorii vor avea acces prin intermediul catorva
click-uri la programul de functionare, disponibilitatea meselor in datile alese de el, meniul,
preturi, dar si posibilitatea sa discute direct cu managerul restaurantului pentru a putea
organiza mai usor diferite evenimente.
Un alt obiectiv al proiectului este de a da posibilitatea restaurantelor de familie sau
restaurantelor noi deschise de a-si putea face reclama la costuri reduse prin intermediul

siteului, folosindu-se de rating-urile utilizatorilor care l-au frecventat, astfel un restaurant care
are o servire impecabila, un mod de prezentare frumos si mancare foarte buna, sa poata sa se
promoveze la niste costuri scazute, iar utilizatorii sa il poata descoperi mai usor.
Un alt obiectiv al proiectului este de a da posibilitatea de a da managerilor de
restaurante posibilitatea sa isi fidelizeze clientii mai usor, sa le ofere promotii si diferite
discount-uri prin intermediul site-ului si fara a mai fi nevoie de carduri de fidelitate pentru
astfel de activitati.
Un alt obiectiv este de a da posibilitatea clientului sa discute, mai usor, cu managerul
restaurantului pentru a organiza o masa pentru un eveniment special (ex: cerere in casatorie)
asa cum isi doreste si a putea afla un cost dinainte.

1.2 Necesitatea proiectului.


Acest proiect vine in ajutorul utilizatorilor, dar si a patronilor de restaurante, practic
acest site creeaza o conexiune mult mai usor intre manageri si clientii lor.
Avand in vedere ca ne aflam, in secolul XXI si pentru a putea afla detalii despre un
restaurant trebuie sa cauti pe un site, pentru a rezerva o masa trebuie sa cauti pe alt site sau sa
suni, in conditiile in care uneori raspund alteori nu, pentru a afla meniul restaurantului trebuie
sa cauti pe alt site si este posibil sa nu gasesti din prima, aceste probleme trebuiesc
centralizate pentru ca un utilizator sa aiba acces la informatia pe care si-o doreste intr-un mod
mult mai usor decat pana acum.
Oamenii secolului XXI au nevoie de informatii si au nevoie acum, traim intr-o epoca
in care timpul si informatia sunt cele mai importante doua resurse, iar omul nu mai doreste sa
caute pe nenumarate site-ul pentru a gasi informatia pe care si-o doreste.
El vrea sa limiteze cat mai mult interactiunile inutile cu alte persoane, iar totul sa se
poata realiza pe internet, cat mai repede si cat mai usor.
Practic acest proiect vine si usureaza omului munca de a gasi un restaurant special
pentru o intalnire de afaceri, pentru o iesire cu prietenii sau pentru a sarbatori o zi importanta
cu familia. Cu acest proiect, acest lucru nu mai necesita timp pierdut, deoarece poti gasi in

timp real toate restaurantele care se potrivesc nevoilor tale si in acelas timp poti vedea toate
restaurantele care au disponibilitati in ziua dorita.

1.3 Piata vizata si concurenta.


Piata vizata pentru inceput este piata restaurantelor din toata Romania, care doresc sa
isi fidelizeze clientii, sa se dezvolte si sa atraga si mai multi clienti.
Piata as putea spune ca este neincercata deoarece in momentul de fata nu exista o
astfel de aplicatie care sa indeplineasca toate functiile si sa unifice toate restaurantele pe un
singur website pentru a facilita accesul mai usor la informatii al utilizatorului.
De aceea singura concurenta pe care o voi intampina, este formata din schimbarea
mentalitatii managerilor pentru a imbratisa schimbarea, deoarece in ziua de azi, in care
tehnologia avanseaza pe zi ce trece, singura sansa de supravietuire a unui business, este de a
evolua si de a intelege nevoile oamenilor.

3. Implementarea proiectului folosind SCRUM


3.1 Descrierea rolurilor
3.1.1

Product Owner

Product Owner-ul aplicatie este si managing partenerul, Georgescu Theodor, el este


persoana care trebuie sa explice echipei de dezvoltare obiectivul aplicatiei si toate featurile pe
care acestia trebuie sa le dezvolte, creeaza cerintele pentru echipa de dezvoltare, impreuna cu
Popescu Ionut discuta cu potentiali clienti, explica conceptele aplicatiei si discuta cu acestia
despre posibilele dezvoltari suplimentare pe care acestia le doresc. El este si persoana
responsabila de Product Backlog.

3.1.2

SCRUM Master

Scrum master este Popescu Ionut si are ca rol gestionarea eficace a backlog-ului
produsului, ajuta echipa de dezvoltare sa dezvolte produse cu o valoare ridicata, protejeaza
echipa de dezvoltare de distrageri interne si externe. Planifica implementarle SCRUM in
cadrul organizatiei, ajuta angajati sa inteleaga si sa adopte SCRUM precum si dezvoltarea
empirica a produselor.

3.1.3

Echipa de dezvoltare

Echipa de dezvoltare este formata din profesionisti care livreaza incremente, potential
lansabile pe piata ale produsului la sfarsitul fiecarui Sprint. Echipa este formata din cei 4
dezvoltatori, au competente de baze de date, POO, limbaje de programare cum ar fi
JavaScript, C#.NET, SQL. Andrei Oprea este team leader-ul echipei de dezvoltare si este cel
care ajuta la organizarea echipei pentru indeplinirea task-urilor pana la sfarsitul sprintului.

3.2 Artefacte
3.2.1

Product Backlog

Contine toate cerintele ce trebuiesc dezvoltate ordonate in functie de prioritatea lor si


sunt sub forma unor User Story. Product Log-ul initial va fi format din 7 user story:
-

Crearea bazei de date pentru stocarea informatiilor


Crearea interfetei pentru inregistrarea utilizatorului casnic.
Crearea interfetei pentru utilizatorul juridic juridic
Crearea interfetei de prezentare a restaurantului
Crearea interfetei de prezentare a utilizatorului
Crearea paginii principale de prezentare a restaurantelor, de cautare etc.
Crearea paginii alocata fiecarui restaurant pentru organizarea rezervarilor.

Aceste sunt Initial User Story, dar odata cu venirea unui client nou si vor adauga noi
user story-uri in functie de nevoile si cerintele pe care acesta la doreste implementate)
Cerintele sunt prioritizate de sus in jos deoarece cel mai important lucru pentru o astfel
de aplicatie este baza de date si creearea structurii acesteia foarte atent pentru a intampina
probleme de integritate sau viteza de accesare. Este important in primul rand ca utilizatorul
casnic sa se poata conecteze la aplicatie si sa poata vedea la ce se asteapta, odata ce aplicatia a
adus cativa clienti, restaurantele vor fi mai interesate de aceasta aplicatie, de aceea pasul 3
este sa creeam interfata pentru acestea, sa inteleaga posibilitatile pe care le au daca devin
clientii nostri. Pasul 4 prezentarea restaurantului, va fi in mare parte gestionat de restaurant,
noi vom da posibilitatea sa isi creeze interfata singur cum isi doresc(asemenea Facebook).
Pasul 5 este important sa stim cine este utilizatorul, deoarece restaurant trebuie sa aiba
posibilitatea sa isi selecteze clientela. De aceea pe pagina de prezentare a utilizatorului vom
vedea restaurantele la care a fost hobby-uri, mancare preferata si comportamentul acestuia din
prisma rezervarilor, cate a onorat, cate nu. Pasul 6 crearea paginii principale unde utilizatorul

sa poata cauta restaurante, implementarea unui motor de cautare. Pasul 7 este creearea paginii
alocate fiecarui restaurant pentru gestionarea rezervarilor.
3.2.2

Definition of Done

Un element din product backlog este DOD atunci cand:


-

Nu prezinta niciun tip de eroare.


Indeplineste cerintele prezentate in BackLog(ex: pentru creearea interfetei
de inregistrare a utilizatorului casnic, pentru a se considera finalizat trebuie
ca, utilizatorul sa poata sa se logheze, sa vada niste informatii despre site,

despre tipul acestuia, sa vada datele de inregistrare, sa poata sa le modifice)


TeamLeader-ul echipei este de acord cu partea de FrontEnd.
Au fost create Unit Tests pentru testari viitoare.
Clientul final a fost multumit de interfata si de modul de utilizare.

3.2.3

Sprint

Sprintul in proiect va fi de 2 saptamani deoarece este timpul de realizare al unui


proiect de asemenea magnitudine este destul de mic, iar timpul nu este in favoarea noastra.
Inceputul si sfarsitul fiecarui sprint vor fi Sarbatorite cu o sedinta in care Product
Owner-ul impreuna cu Scrum Master-ul, descriu echipei de dezvoltare cerintele pe care le au
de indeplinit, probleme pe care le vor intampina si cum vor trece peste ele.

3.3 Sprint Planning


3.3.1

Alocare resurse

Avand in vedere faptul ca firma este la inceput si numarul este unul redus, pe toata
durata unui sprint vor fi 3 dezvoltatori si 1 tester, tester-ul va fi altul de fiecare data pentru
prospetime in activitatea de testare. Echipa din 4 oameni va fi dispusa astfel 75% dezvoltare,
25% testare. La sfarsitul fiecarui sprint va fi o sedinta in care se va discuta probleme intalnite
pe parcursul sprint-ului si ce ar trebui imbunatatit pentru a nu mai intampina astfel de
probleme.
3.3.2

Estimare User Story-uri

La fiecarui sprint se doreste 70% din timp dezvoltare user-story-ul preluat pentru
dezvoltare si 30% testare, asta datorita timpului destul de scurt de dezvoltare si anume 3 luni.
Astfel fiecare sprint va prelua un user story pentru dezvoltare(din cele prezentate mai
sus) , este necesar ca la sfarsitul sprintului user-story-ul sa fie finalizat si testat, daca acest
lucru nu se intampla datorita diferitelor probleme intampinate, cerintele ramase de dezvoltat
vor fi raportate pentru urmatorul sprint.
Modul de estimare al user story-urilor se face in functie de complexitatea acestora
dedusa din analiza facuta de product owner.
3.3.3

Selectare US-uri

User story-urile selectate sunt :


-

Crearea bazei de date pentru stocarea informatiilor


Crearea interfetei pentru inregistrarea utilizatorului casnic.
Crearea interfetei pentru utilizatorul juridic
Crearea interfetei de prezentare a restaurantului
Crearea interfetei de prezentare a utilizatorului
Crearea paginii principale de prezentare a restaurantelor, de cautare etc.
Crearea paginii alocata fiecarui restaurant pentru organizarea rezervarilor.

Ele au fost selectate in functie de prioritatea lor si in functie de timpul pus la dispozitie
pentru a avea cat mai repede un produs finit.
3.3.4

Definirea obiectivului sprintului

Obiectivul sprintului este acela de a putea pune la dispozitia clientilor un produs stabil
cat mai repede. Astfel dupa fiecare sprint, ar trebui sa putem sa avem o aplicatie functionala
pusa la dispozitia clientilor si sa primim feedback in timp real de la clienti prin intermediul
optiunii de Trimite feedback care va fi prezenta pe site.
3.3.5 Detalierea User Story-urilor in sub-task-uri
a) Crearea bazei de date pentru stocarea informatiilor
- Creearea tabelelor cu cheile primare si cheilor secundare
- Creearea indexilor pe coloanele care au fost analizate ca vor fi foarte
b)
-

folosite
Creearea job-urilor de mentenanta a bazei de date
Testarea server-ului pentru maximul de user concurenti pe ca ni-l dorim.
Crearea interfetei pentru inregistrarea utilizatorului casnic.
Crearea formei.
Crearea functiilor de interogare a bazei de date.

c)
d)
e)
f)
g)
-

Testarea aplicatiei.
Crearea interfetei pentru utilizatorul juridic
Crearea formei.
Crearea functiilor de interogare a bazei de date.
Testarea aplicatiei.
Crearea interfetei de prezentare a restaurantului
Crearea formei.
Crearea functiilor de interogare a bazei de date.
Testarea aplicatiei.
Crearea interfetei de prezentare a utilizatorului
Crearea formei.
Crearea functiilor de interogare a bazei de date.
Testarea aplicatiei.
Crearea paginii principale de prezentare a restaurantelor, de cautare etc.
Crearea formei.
Crearea functiilor de interogare a bazei de date.
Testarea aplicatiei.
Crearea algoritmului pentru motorul de cautare pe site.
Crearea paginii alocata fiecarui restaurant pentru organizarea rezervarilor.
Crearea formei.
Crearea functiilor de interogare a bazei de date.
Testarea aplicatiei.
Testarea explicita a securitatii site-ului.

4. Concluzii
Conform planului, vor fi dezvoltatele user-story-urile pana la data de 20 mai 2016
pentru a putea trece la etapa urmatoare si anume dezvoltarea unor noi functionalitati pentru a
imbunatati experienta utilizatorului cu aplicatia prezentata.
Scopul este de a furniza cat mai repede o aplicatie functionala pentru a putea incepe
promovarea acesteia in mediul online si offline si ca utilizatori nostri sa poata beneficia de un
produs stabil si functional.
Am ales sa folosim metodologia Agile deoarece se potriveste foarte bine pe nevoile
noastre si este o metodologie dinamica bine pusa la punct care pune la dispozitie toate
instrumentele necesare pentru a putea furniza pana la sfarsitul sprinturilor un produs stabil si
gata de utilizat.