The Grill House - Sistem de management al restaurantului

Proiect Simplilearn pentru Capstone

Trimis de: Channamallikarjun Hiremath

Cuprins
Sarcinile proiectului.........................................................................................................................1
Rezumatul proiectului:.....................................................................................................................2
Schema de clasificare a cerințelor:...................................................................................................4
Implementarea domeniilor de cunoaștere:.......................................................................................8
Modelarea domeniului................................................................................................................16
Modelarea datelor:......................................................................................................................17

Sarcinile proiectului
S Sarcini Referințe
Nu.
1. Identificarea părților interesate – Creați o listă de părți interesate (așa cum este
predat în Zona de cunoștințe privind planificarea și monitorizarea analizei de •
Figura 1: Harta părților interesate
afaceri) prin
Matricea părților interesate
• Tabelul 3: Cunoștințe BA aplicate
2. Identificați enunțul problemei în acest sistem
• Tabelul 1: BACCM
3. Identificați obiectivele noului sistem de management al restaurantelor
• Tabelul 1: BACCM
 4. Creați așa cum este și harta proceselor viitoare (folosind diagrame)
• Figura 4: Procesul de stare curentă
• Figura 5: Procesul privind starea
5. În calitate de analist de afaceri care lucrează la acest proiect, aflați domeniul de
aplicare al Sistemului de management al restaurantelor. Pentru a găsi domeniul • Figura 6: Modelarea proceselor
de aplicare, puteți utiliza diagrama de caz (UML) sau diagrama de context folosind diagrama cazurilor de
6. Notați principalele caracteristici care trebuie dezvoltate. utilizare (UML)
• Tabelul 4: Componente de nivel
înalt
7. Scrieți elementele din domeniul de aplicare și din afara domeniului de aplicare
pentru acest software. • Tabelul 5: Produs în domeniul de
aplicare și afară
8. Desenați o diagramă de activitate pentru sistem.
• Figura 9: Diagrama de activitate
pentru
9. Desenați o diagramă ER a sistemului.
• Figura 8: Modelarea datelor
folosind
10. Scrieți cerințele de afaceri, atât cerințele funcționale, cât și cele nefuncționale.
• Tabelul 2: Cerință
Schema de clasificare
11. Desenați wireframes sau ecrane simulate pentru oricare dintre funcții și anume
Crearea meniului și orice altă caracteristică considerată potrivită de către •
Figura 10: Crearea comenzii de
student. chelner
Ecrane simulate
• Figura 11: Crearea meniului Mock

Rezumatul proiectului:
Mai jos este capturat obiectivul proiectului folosind modelul de concept de bază de analiză de afaceri (BACCM)

Tabelul 1: BACCM
Nevoia The Grill House este un lanț mare de restaurante din diferite orașe din SUA. Este deținut de un celebru bucătar
afacerii / american James Oliver. Tendințele de vânzări și performanța lanțului de restaurante sunt gestionate manual de
Declarația fiecare restaurant. Facturile sunt pe hârtie și toate informațiile despre vânzări sunt introduse manual la sfârșitul
problemei zilei. Aceasta este o gestionare descentralizată de zi cu zi a restaurantelor.

Următoarele sunt provocările cu care se confruntă angajații în timpul gestionării zilnice a lanțurilor de
restaurante:
• Sistem manual pe bază de hârtie.
• Comenzile sunt preluate de chelneri pe hârtie, iar factura pe hârtie este dată clientului.
 • Restaurantele nu își pot actualiza cu ușurință meniul.

• Nu pot căuta cu ușurință preparatele din meniu.

Schimb
are
• Nu pot recunoaște diferite tipuri de utilizatori, cum ar fi manageri, ospătari etc.

• Un sistem automat de management al restaurantului care ar putea economisi timp chelnerii și

managerilor.
• Servicii îmbunătățite pentru clienți.
• Permite căutarea preparatelor din meniu.
• Oferă managerilor posibilitatea de a crea sau actualiza cu ușurință meniul.
• Oferă posibilitatea managerilor de a rezerva mese.
• Arată ce fel de mâncare sunt populare.
Soluţie • Reduceți costul de funcționare al restaurantului.
• Poate salva feedback-ul clienților.
• Oferă tendințe de vânzări, cum ar fi vânzările totale, vânzările pe articole, bazate pe rapoarte zilnice, săptămânale și
lunare.
• Îmbunătățiți productivitatea angajaților

Sistem de management al restaurantului bazat pe web, care ar permite utilizatorilor să caute în meniuri, să genereze facturi,
plățile clienților să fie acceptate printr-o poartă de plată, să stocheze feedback-ul clienților, să rezerve tabele și
să creeze rapoarte pentru a afișa tendințe și detalii precum vânzările zilnice, săptămânale și lunare.
P
ă
r
ț
i

i
n
t
e
r
e
s
a
t
e

e
r

Figura 1: Harta părților interesate prin matricea părților

interesate și diagrama cu coajă de ceapă
 Valoare/ • Sistem automat de management al restaurantului
Obiective
• Disponibilitate mai bună a serviciului, deoarece crește eficiența ospătrilor și a managerilor
• Puteți căuta cu ușurință meniul după categorie.
• Eficiență în rezervarea și urmărirea meselor
• Permite unui gateway de plată să ofere flexibilitate de plată clienților
• Primește feedback și informații ale clienților
• Permite un control mai bun asupra unor opțiuni ale sistemului oferite anumitor utilizatori.
• Pot fi luate decizii mai rapide pentru a schimba felurile de mâncare din meniu pe baza tendințelor de vânzări
• Timp redus de generare a rapoartelor zilnice

Context Asta pentru un lanț mare de restaurante din SUA. Aceasta este o mare inițiativă de tranziție de la un sistem
manual pe hârtie la un sistem automat, pentru a permite o gestionare mai bună de zi cu zi. Rezervările la mese și
modificările meniului au fost provocatoare. Facturile sunt scrise de ospătari pe hârtie și date clienților. Este nevoie de timp
pentru a vedea tendințele, deoarece managerii trebuie să introducă facturile pe hârtie în fișierele Excel la EOD. Tendințele de
vânzări ajută la luarea deciziilor de a schimba meniul și experiența clienților în timp util. Este un sistem descentralizat de
management al restaurantului. Există mult timp și efort petrecut doar pentru proces. Nu există nicio modalitate de a urmări
feedback-ul clienților. Acestea sunt circumstanțele care duc la schimbare.

Schema de clasificare a cerințelor:

Tabelul 2: Schema de clasificare a cerințelor

Cerințe de afaceri De ce o vreau?

Cerințe pentru părțile interesate Care sunt nevoile?
• Lanțul de restaurante Grill House se află în toată SUA. În medie, fiecare
restaurant are câteva sute de clienți zilnic pentru a lua masa.
Un sistem automat de management al restaurantului
care ar trebui să:

• Gestionarea manuală pe hârtie a restaurantului provoacă mai • Meniul poate fi creat și actualizat cu
ușurință de către manager, pe baza
multe probleme. Chelnerii preiau comenzile pe hârtie și o mâncărurilor populare.
factură pe hârtie este prezentată clienților. Aceste facturi sunt
introduse la EOD de către manager în Excel pentru a cunoaște • Posibilitatea pentru toți ospătarii și
vânzările totale și vânzările pe articole pentru ziua respectivă. managerii de a căuta articole în meniu
Rapoartele sunt create folosind fișierul Excel pentru a cunoaște folosind facilitatea de căutare.
tendințele vânzărilor sau pentru a afla feluri de mâncare
populare și feluri de mâncare care nu merg bine.
• Ar trebui să stocheze aspectul mesei și
rezervările de masă.
• Conducerea a decis să treacă de la un proces manual la un sistem • Căutați disponibilitatea meselor pentru
clienții cu locuri.
automat de management al restaurantelor, astfel încât să poată urmări
mai bine vânzările și să își gestioneze mai bine afacerea de zi cu zi.
• Managerii pot face rezervări de masă.
• Obiectivul aici este de a avea un sistem online automatizat • Generați factura.
pentru managementul restaurantelor, care să le permită să • Fiecare factură generată ar trebui să aibă
utilizeze eficient resursele sale pentru a crește productivitatea ID-ul chelnerului și ar trebui să aibă
și vânzările. Rapoartele generate în timp util vor arăta numărul de masă.
tendințele de vânzări pentru a lua decizii de afaceri mai bune.
• Acest lucru poate capta feedback-ul clienților. • Trebuie să aibă autentificare pentru
ospătari, manageri și James Oliver (CEO)
cu posibilitatea de a schimba parola.
• Ar trebui să aibă o poartă de plată, astfel
încât clienții să aibă flexibilitatea de a
plăti cu numerar sau cu cardul.
• Stocați feedback-ul clienților și informații
despre clienți, cum ar fi numele, adresa,
numărul de telefon mobil, e-mailul, data
nașterii, datele aniversare ale clienților și
feedback-ul acestora. Managerii ar trebui
să aibă capacitatea de a introduce
manual detaliile formularului de
feedback în sistem.
• Ar trebui să genereze rapoarte care să
arate tendințe și detalii, cum ar fi
vânzările totale zilnice, vânzările zilnice
pe articole, vânzările zilnice, săptămânale
și lunare. Generați un raport pentru a
identifica preparatele populare.
• Prin automatizarea procesului de
management al restaurantului,
restaurantul va putea funcționa eficient
cu forță de muncă mai mică.

Cerințe Cerințe
de de
soluție tranziție
Ce vreau? Care sunt
conditiile?

Cerințe funcționale: • Nu există o poartă de plată pentru acesta,

• Toate detaliile angajaților ar trebui să fie stocate în sistem.
Informațiile angajaților sunt verificate de sistem înainte de
astfel încât plata pentru preparatele
comandate va fi dedusă din salariul
configurarea acreditărilor de conectare. angajatului. Prin urmare, angajații trebuie să se
• Chelnerul poate deschide pagina web a Sistemului de
management al restaurantului. El/ea poate selecta o masă
înscrie pentru deducerea plății salariului.
Sistemul de salarizare se va ocupa de
pentru a găzdui clienții, poate căuta meniul, poate plasa o deducerile din salariu.
comandă, poate genera factura clienților, poate procesa plata și
poate imprima un formular de feedback. • Acesta este un sistem nou-nouț și va face
• Chelnerul poate verifica mesele disponibile și poate selecta o
masă pentru a lua masa în clienții care urmează să fie așezați.
tranziția de la actuala hârtie manuală sistem
bazat pe un nou sistem de management al
• Chelnerul sau managerul poate căuta în meniu un anumit fel de restaurantelor online.
mâncare.
• Managerul poate crea și actualiza meniul.
 • Managerul poate rezerva mese.
•
• Managerul restaurantului (angajatul Grill House) poate crea
meniul și actualiza meniul pentru restaurantul său.
Noul sistem va fi creat și menținut în Java. Java
este o alegere bună de software pentru a
dezvolta această aplicație, deoarece nu se va
• Chelnerul poate selecta preparatele pe care clientul ar dori să le schimba prea mult în timp și va avea nevoie de
primească și poate crea o comandă. Ar trebui să poată edita foarte puțină întreținere dacă este bine
articolele din comanda clientului înainte de a plasa comanda. codificat.
Ospătarul poate adăuga mai multe articole înainte de a genera

•
factura.
Odată ce comanda este confirmată și trimisă, chelnerul NU ar
• Asigurați-vă că toate caracteristicile sistemului
sunt conform cerințelor.
trebui să poată anula sau edita comanda.
• Managerul restaurantului ar trebui să poată vizualiza comenzile
plasate de ospătari. El va face un inventar al tuturor preparatelor
• Importarea informațiilor istorice despre
comandate și le va da bucătarului pentru gătit. angajat, restaurant, meniu și clienți etc. ar
• Odată ce bucătarul a pregătit felurile de mâncare, managerul
restaurantului ar trebui să poată solicita chelnerului să livreze
trebui importate din fișierele Excel în noile
tabele de sistem.

•
felurile de mâncare la masa clientului.
Odată ce clientul a terminat cu masa lui. Chelnerul va da clientului
• Creați date de conectare pentru toți ospătarii,
managerii și CEO-ul cu funcția de schimbare a
factura generata. parolei.
• Factura generată trebuie să aibă ID-ul ospătarului și numărul
mesei. • Creați un manual de utilizare cu instrucțiuni
• Chelnerul va prelua plata clientului fie cash, fie ca card de credit.
Plata cu cardul de credit va fi procesată folosind un gateway de
despre caracteristicile sistemului. Efectuați
instruirea utilizatorilor pentru părțile
interesate cheie și obțineți aprobarea
plată. acestora.
• Chelnerul sau managerul va oferi clientului un formular de
feedback. • Efectuați UAT pentru a vă asigura că
• Pentru comenzile cu livrare la domiciliu comanda la pachet este
rezultatele cheie sunt îndeplinite atunci când
treceți de la starea actuală la starea viitoare
pregătită de bucătar. Va exista un angajat cu livrare la domiciliu dorită. Asigurarea că toate accesul
(delivery boy) care va livra comanda la adresa clientilor. Factura
este generată și plasată cu comanda de livrare la domiciliu. Odată
cu comanda este oferit și un formular de feedback. Clientul poate plăti cu cardul de credit la telefon sau poate da numerar
livratorului. După livrarea comenzii și plata clientului, managerul va închide comanda clientului.
• Factura generată de livrare la domiciliu va avea numele clienților, numărul de telefon și adresa clienților.
• Odatăfeedback.
ce clienții returnează formularele de feedback. Managerul poate introduce în sistem informațiile din formularul de

• Conducerea ar dori următoarele rapoarte:

• Ce fel de mâncare sunt cele mai populare?
•clienți.Satisfactia clientilor cu privire la calitatea serviciilor. Acest lucru ar trebui urmărit bazat pe feedback-ul transmis de
• Totalvânzăridecel zi prin cina în clienți.
• Totalvânzăridecel zide către clienții cu livrare la domiciliu.
• Totalvânzăridecel zi(livrare la domiciliu și cina în
clienți consolidați).
• Numiți primele 10 feluri de mâncare cele mai vândute pentru ziua respectivă.
• Vânzări totale în fiecare weekend (se fac prin introducerea codului
datele)
• Vânzări totale în fiecare lună (se face prin introducerea datelor)
• Lista de preparate care nu sunt vândute în luna curentă (aceasta este pentru a elimina treptat preparatele pe care
clienții nu le comandă).
• Vânzări totale în toate orașele.
• Vânzări totale pentru fiecare oraș.
• Prognoza comenzii, adică o predicție a articolelor care vor fi comandate și când vor fi comandate.
Cerințe non-funcționale:
• Utilizabilitate : Ecranele ar trebui să se explice de la sine și foarte ușor de utilizat.
• Scalabilitate și performanță : Acest sistem de management al restaurantelor este necesar pentru a susține un volum de 2500 de
angajați în toate statele din SUA. Paginile web ar trebui să fie accesate rapid, iar informațiile ar trebui să fie disponibile rapid.
• Disponibilitate : Sistemul ar trebui să aibă performanțe ridicate, trebuie
să fie eficient și să fie disponibil în proporție de 99%.
• Securitate : Utilizatorii sunt validați înainte de a crea log in id.
 • Nivel de servicii Acord: provizii de inventar date, Ordin
prognoza.
• Conformitate : Politica și conformitatea HR.

• Interfață : The sistemul urmează să fie creat și menținut în Java.

Java nu se va schimba prea mult în timp, iar dacă sistemul este bine dezvoltat, codul va avea nevoie de foarte puțină întreținere.

Implementarea domeniilor de cunoaștere:

Tabelul 3: Domenii de cunoștințe aplicate BA

Analiza afacerii Planificare și monitorizare

KA Sarcini Detalii sarcini

Abordarea BA Adaptiv

Soluţie
Definit în iterații pentru a ajunge la cea mai bună soluție sau pentru a îmbunătăți o soluție existentă
Definiție

Nivelul de Informal – informațiile sunt colectate prin interacțiunea echipei și feedback.

Formalitate
Formalitatea și nivelul
de detaliu al
rezultatelor analizei de
• Activitățile vor fi împărțite în iterații cu livrabile mai întâi și apoi sarcinile asociate
sunt identificate.
afaceri Activități
• Lucrările din fiecare iterație vor fi prioritizate și planificate pe baza produsului convenit
foaie de parcurs.

Sincronizare
•Sarcinile
Foaia de parcurs pentru produse va fi revizuită trimestrial pentru a surprinde orice modificări
sunt efectuate iterativ

• Analizați nevoile afacerii

• Definiți un caz de afaceri

Activitati BA
Timpul de lucru de analiză de afaceri
• Obțineți informații de la părțile interesate
• Colaborați cu părțile interesate
• Prioritizează cerințele
• Definiți starea viitoare
• Cerințe de model
• Validați soluțiile
• Management de proiect
Sarcinile BA vor fi efectuate iterativ pe parcursul inițiativei.

Complexitate și risc
• Abilități de operare a calculatorului și instruire pentru personalul de conducere al
restaurantului (furnizor de masă,
Manager restaurant, ospătar și CEO).
• Modificări ale cerințelor și domeniului de aplicare în mijlocul iterațiilor (de exemplu, variația
 • Întârziere în lansarea soluției Web.
Acceptare Testarea de acceptare a afacerilor pentru fiecare lansare planificată va fi utilizată ca semnare a
părților interesate.
Părți interesate de produs:
Extern
• Managementul Restaurantului
• Furnizor
• Manager de meniu
• bucătari
• Livrator de masă
• Client

Identificați părțile interesate Analist de afaceri

Implicarea părților interesate și
colaborare
Intern
• Conducerea Grill House
• Sponsor de program
• Angajatii
• HR
• Obiectul de implementare Expert
• Manager de proiect
•Întâlniri
Dezvoltator
de revizuire Sprint/Iterație – La sfârșitul fiecărui Sprint, părțile interesate mai apropiate de
livrarea soluției se vor întâlni pentru a discuta despre ceea ce s-a făcut ca parte a Sprintului. Ce
lucrare a fost finalizată și ce nu a fost finalizată și a fost transferată la următoarea iterație.
Conexiuni săptămânale / bisăptămânale - Cu Business & Technology pentru a clarifica orice îndoială
și/sau a solicita feedback cu privire la activitatea desfășurată până acum.
Întâlniri de planificare a sprintului/iterării – Discutați și decideți ce lucrări sau sarcini vor fi preluate
de echipa de tehnologie pentru următorul sprint/iterație.
Sesiuni de îngrijire a backlog-ului – Pentru a prioritiza stocul de produse și a se asigura că munca
necesară pentru dezvoltarea produsului este capturată
Sesiuni trimestriale de planificare – Cu părțile interesate pentru a discuta despre progresul general
al produsului, pentru a rezolva orice preocupări sau conflicte ale părților interesate, pentru a evalua
și ajusta termenul de livrare a produsului în cazul oricăror riscuri sau întârzieri identificate. Discutați
pașii următori pentru a rezolva orice conflicte și preocupări imediate, Reajustați foaia de parcurs
pentru produse, dacă este necesar, Discutați prioritățile cerințelor pentru afaceri și părțile interesate.

Elicitare și colaborare

KA Sarcini Detalii sarcini

Întâlniri săptămânale cu părțile interesate pentru:

Elicitarea cerințelor
• Generați idei și discutați despre cerințe.
• Repetați înțelegerea cerințelor.
• Examinați Cerințele documentate la nivel înalt sau detaliate
• Examinați cerințele modelate și solicitați feedback
• Pregătiți și revizuiți machete simulate pentru sistem
• Discutați orice complexitate sau risc
Aceste întâlniri ar trebui să se alinieze cu fiecare iterație și ar trebui să se concentreze pe capacitățile
produsului dezvoltate în următoarele iterații.
 Rapoarte lunare (diagrame de viteză, rapoarte de defecte, valori de modificare a domeniului de
aplicare, diagrame de ardere etc.)
Plan de comunicare Rapoarte Agile Dashboard
Întâlniri privind stadiul proiectului
Planuri de lansare.
Analiza Strategiei
KA Sarcini Detalii sarcini
• Deoarece acesta este un sistem nou, nu va exista nicio analiză a stării curente a unui sistem
existent.
• Cu toate acestea, analiza stării curente ar putea fi efectuată pentru sistemele similare existente
în
Analiza stării curente
Organizație pentru analiza proceselor de implementare a securității, implementare tehnologică
și infrastructură, viziune arhitecturală.
• Analiza părților interesate externe (de exemplu, managementul restaurantelor, vânzătorii și
furnizorii de alimente) la
înțelegeți dacă există lacune în modelul lor de cost, procese, forță de muncă (nivel de calificare)
• Definiți structura organizatorică pentru program

• Definiți rolurile și responsabilitățile în structura organizației

• Definiți domeniul de aplicare la nivel înalt al programului
Analiza stării viitoare
• Definiți cronologia de livrare a produsului
• Definiți foaia de parcurs pentru produse pentru anul
• Definiți criteriile de succes la nivel de program și la nivel de livrare
• Definiți arhitectura de nivel înalt a produsului.
• Instruirea personalului restaurantului in utilizarea corecta a sistemului
• Asigurarea că toate comenzile sunt pregătite și livrate.
Evaluați riscurile
• Întârzieri de comandă din cauza volumelor mari de comenzi sau a informațiilor incorecte sau
incomplete ale Clientului sau
Eroare de navigare de către Livrator etc.
• Disponibilitatea aplicației web sau timpul de nefuncționare al aplicației.
• Analizați dacă există lacune cu managementul actual al restaurantelor și furnizorii.
Schimbarea strategiei • Identificați modul în care aceste lacune pot fi acoperite.
• Care va fi costul la îmbarcarea unui nou furnizor de restaurante sau de management al
restaurantului?
• Identificați dacă există grupuri suplimentare de părți interesate care vor trebui să se implice,
Analiza și proiectarea cerințelor
KA Sarcini Detalii sarcini

• Definiți cerințele la nivel de sistem :

o Utilizatorii (ospătari/administratori) pot plasa comenzile clienților pe RMS.
o Utilizatorii pot adăuga articole suplimentare la comandă până când clientul este gata și
gata
pentru primirea facturii.
o Ultimele comenzi pentru prânz trebuie plasate până la ora 14:00, iar comenzile pentru
cină până la ora 22:00.
Cerințe de model o Există o poartă de plată, astfel încât plata vaselor comandate se va plăti prin credit
card sau numerar.
o Utilizatorii (ospătari/administratori) pot căuta în meniu, pot imprima formularul de
feedback, pot genera factură,
căutați în tabele clienții și plasați comenzi pentru clienți.
o Managerii pot crea și actualiza meniul.
o Managerul poate rezerva mese.
o Managerul ar trebui să poată introduce în sistem informații din formularul de feedback.
o Managerul poate urmări comenzile și poate verifica dacă sunt gata pentru livrare la
domiciliu sau pentru a lua masa
 o Acest sistem de comenzi pentru restaurante este necesar pentru a susține un volum
de 2500 de angajați în toate restaurantele.
Definiți cerințele la nivel de subsistem :
Sistemul de comandă la
restaurant Utilizatorii (ospătari/administratori) ar trebui să poată plasa comanda.
Ospătarii/Administratorii ar trebui să poată vizualiza meniul zilei cu
prețurile articolelor.
o Ospătarii/Administratorii ar trebui să poată edita comanda înainte de a
o o confirma.
o Ospătarii/Administratorii nu pot modifica sau anula comanda după
o confirmare.
o Managerii ar trebui să poată crea și actualiza meniul.
o Managerii ar trebui să poată rezerva mese.
Managerii/Chelnerii ar trebui să poată genera factura.
Ospătarii/Administratorii ar trebui să poată procesa plățile clienților cu
cardul de credit utilizând gateway-ul de plată.
Sistem de Ecranele ar trebui să fie ușor de utilizat și ușor de navigat.
procesare Restaurant Manger ar trebui să poată vedea comenzile.
Comenzile ar trebui să fie procesate secvenţial, adică trebuie să fie onorate
conform principiului First In First Out.
Comenzile pot fi grupate în funcție de Articole, astfel încât Managerul
Restaurantului să poată face un inventar al tuturor preparatelor
comandate de diferiți clienți și să le gătească de bucătar.
Managerul restaurantului ar trebui să poată solicita o livrare la adresa de
domiciliu a clienților.
Managerul ar trebui să poată actualiza starea comenzii după livrare.
Managerii pot introduce în sistem informații din formularul de feedback al
clienților.
Sistem de
administrare
Managerul restaurantului ar trebui să poată adăuga meniul și
prețul articolului. Managerul restaurantului ar trebui să poată
actualiza meniul și prețul articolului. Managementul restaurantului
ar trebui să poată adăuga/actualiza un chestionar de feedback.
Conducerea ar trebui să poată extrage rapoarte.
Definiți cerințele la nivel de componentă :
Logare utilizator
■ Roluri și autorizare utilizator
Creați, actualizați și vizualizați meniul
Creați comanda și vizualizați comanda
Informații despre contul utilizatorului
Procesarea comenzii – Solicitarea livrării, Actualizarea stării
comenzii
Raportare Instrumentul de
Stack de identificare BI
tehnologie: Autentificarea aplicației
■ Arhitectura aplicațiilor și bazelor de
date
Modelarea datelor
Cadrul de aplicație
Contracte API
Design interfață utilizator
Monitorizarea aplicației
Plan de recuperare în caz de
dezastru
Asigurați-vă că există un plan de verificare și validare.
Verificarea și validarea cerințelor se pot face la fiecare nivel de componentă, sub Nivel de
sistem și nivel de sistem.
Verificați și validați
Cerințe Verificați dacă produsul dezvoltat se aliniază cu cerințele specificate (după cum este
specificat în criteriile de acceptare).
Validați că subsistemul asamblat sau soluția îndeplinește cerințele de afaceri și părți
interesate, efectuând testarea de acceptare a utilizatorului pe produsul asamblat.

Definiți opțiunile de proiectare
Analizați valoarea potențială și
recomandați soluția
KA Sarcini
Cerințe de urmărire
Menține cerințele
păstrare
Prioritizează cerințele
avea
• Ar trebui să putem urmări proiectarea la nivel de componentă până la nivelul sistemului
cerințele furnizate de părțile interesate prin Planul de verificare.
• Astfel putem constata că sistemul este complet acoperit în raport cu
Validarea verificarii.
• Evaluați Build vs Buy.
Bazat pe cost, securitate, întreținere, complexități de integrare, suport operațional etc.
• Analiza furnizorilor pentru sistemul de management al restaurantelor.
• Build Pro :
o Securitatea datelor
o Întreținere internă
o Costul Construcției
o Poate monitoriza sistemultimpul de rulare
o Rezoluție rapidă în caz de oprire a sistemului.
o Aliniați-vă cu organizația Standarde și politici
• Construirea contra:
o Mai mult timp de pus în producție
o Cost mai mare de întreținere
• Cumpărați Pro:
o Timp mai mic de pus în producțieadicăPriza șiUtilizați soluția
o Răspunderea minimă de întreținere
o Cost mai mic de întreținere
• Cumpărați Contra:
o Mai puțină vizibilitate în monitorizarea sistemului & Timp de nefuncţionare.
o Timp de răspuns mai mare în caz de nefuncționare sau defecțiune a sistemului.
o Mai nu satisfaceOrganizare Standarde și politici.
o Date Schimb valutar.
o Extern intern SistemIntegrare
o Cost de Cumparare
Cerințe Managementul ciclului de viață
Detalii sarcini
• Nivelul de abstractizare al cerințelor poate fi împărțit în cerințe de afaceri,
Cerințe pentru părțile interesate, cerințe pentru soluții și cerințe de tranziție, fiecare nivel
oferind o vedere mai detaliată a cerințelor. Acest lucru se realizează prin Schema de clasificare
a cerințelor menționată în secțiunea anterioară a documentului.
• În plus, sistemul poate fi împărțit la diferite niveluri pentru a vă asigura că toate
specificațiile cerințelor sunt acoperite, iar cerințele pot fi urmărite până la nivelul cel mai
granular. Acest lucru se poate face prin defalcarea sistemului în cerințe la nivel de sistem, care
este o cerință de nivel superior furnizată de utilizatori, apoi sub Nivelul sistemului și apoi
cerințele nivelului componentelor.
• Fiecare cerință de afaceri și părți interesate va trece prin următoarele faze:
Analiză detaliată, Proiectare, Dezvoltare, Testare funcțională, Testare de acceptare a utilizatorilor,
Testare de performanță.
• Fiecare Cerință din întârziere ar trebui să aibă un Criterii de Acceptare în consens din partea
Părțile interesate înainte de a trece la orice Sprint/Iterație activă.
• Nivelul subsistemului și cerințele nivelului componentelor ar trebui definite astfel încât fiecare
cerința poate fi testată exclusivă reciproc față de celelalte cerințe și atunci când este integrată
funcționează în armonie cu celelalte cerințe
• Asigurați-vă că definiția cerinței rămâne consecventă pe tot parcursul ciclului său de viață prin
Poveștile și documentele utilizatorilor actualizate.
• Orice modificare a cerințelor va fi înregistrată ca o nouă cerință în Agile
tabloul de bord și va trebui să treacă prin îngrijirea backlog și prioritizare.
•
Prioritatea cerinței ar trebui să fie definită de criticitatea afacerii și de valoarea pe care o va
 • Orice modificare a cerințelor va fi înregistrată ca o nouă cerință în Agile
tabloul de bord și va trebui să treacă prin îngrijirea backlog și prioritizare.

• Modificările aduse cerinței sunt actualizate în documentele User story.

Evaluați modificările aduse
Cerinţă • Orice dependențe cunoscute ar trebui să fie legate de cerințele din tabloul de bord Agile.

• Orice modificare adusă cerinței ar trebui să fie urmărită de la Cerința inițială până la ultima
modificare adusă Cerinței.

• Evaluați impactul modificării asupra termenului de livrare a produsului sau soluției, costul,
sinergia cu celelalte componente asociate.

Evaluarea soluției
KA Sarcini Detalii despre sarcină
o Reduceți costurile de operare a restaurantului cu 15% în decurs de 12 luni, după lansarea
inițială.
o Reduceți risipa de stoc cu cel puțin 30% în decurs de 6 luni de la prima lansare.
Scară: risipa de ingrediente pentru cele mai puțin populare feluri de mâncare în fiecare săptămână
prin examinarea inventarului restaurantului
Trebuie să planificați pentru: mai puțin de 15%
Măsurați performanța soluției o Creșteți timpul mediu de lucru efectiv, permițând chelnerilor și managerilor să conducă
serviciul
eficient în fiecare zi, în decurs de 3 luni
Prin automatizarea procesului de comandă și prin furnizarea de servicii mai bune clientului, atât
pentru masă, cât și pentru livrarea la domiciliu, restaurantul va putea funcționa cu forță de muncă
mai mică.
o Scalabilitate și performanță :
Acest sistem de management al restaurantelor este necesar pentru a susține un volum de

Odată ce soluția sau o parte a soluției asamblate este disponibilă în producție pentru managementul
restaurantului, ar trebui să monitorizăm în mod continuu următoarele în funcție de măsurile de
performanță definite mai sus:
•
Cantitatea de risipă de inventar
•
Ospatari/ Manageri Timp de lucru eficient
Analizați Măsurile de Performanță •
Costul de funcționare al restaurantului
•
Încărcare sau trafic primit, adică numărul de comenzi pe unitatea de timp.
•
Timpul de rulare a aplicației și timpul de nefuncționare, dacă există.
•
Timp total pentru a îndeplini Comanda.
•
Cum funcționează planul de reducere a riscurilor?
•
Feedback utilizator

Evaluați limitarea soluției Orice Măsuri de Performanță subperformante menționate mai sus.

o Abilitatea de a oferi contabilitate preplătită și postplătită pentru comenzi.

Limitarea întreprinderii o Soluția acceptă contabilitatea preplătită, permițând clienților să plătească folosind Credit
Carduri, dar nu online banking.

Stare inițială -Manual

Dezvoltați software-ul Creați o bază de date Creați date de

centralizată și completați Configurați computere și alt conectare și rapoarte
hardware pentru fiecare pentru utilizatori
data istorică
locație.
Figura 4: Procesul de stare
curentă
 Restaurant

Chelnerul
plasează
comanda
folosind
managementul
restaurantului

Chelnerul
verifică mesele Managerul cere
și locurile Chelnerul Comanda este chelnerului să livreze
clientului preia livrata clientului comanda
comanda
clienților Managerul colectează
comanda și o dă
bucătarului

Figura 4: Procesul privind

starea viitoare

Modelarea
proceselor
Verificați față Figura 6: Modelarea proceselor folosind diagrama
de cazurilor de utilizare (UML)
componentă
verificarea
nivelului

Figura 7:
Model de
verificare și
validare a
produsului

Modelarea
domeniului
Tabelul 4:
Componente
de nivel înalt
care trebuie
construite

Roluri de utilizator Componente / Caracteristici Autorizare

• Sunt
Lista de meniu Vedere

Chelner Formular de feedback Vedere

Comanda masa Vizualizați, editați

Starea comenzii Vedere

Rezervare de masă Vedere

Lista de meniu Vizualizați,

adăugați, editați
Vizualizați,
Formular de feedback
adăugați
Comanda masa Vedere

Manager de restaurant Starea comenzii Vizualizați, editați

Grupați comenzi în funcție de Vedere
articolele din meniu
Solicitați Livrare Editați | ×

Rezervare de masă Vizualizați, editați

Echipa de pregătire a Starea comenzii Vedere

comenzilor Starea comenzii Vedere

CEO Rapoarte Vedere

Tabelul 2: Produs în domeniul de aplicare și în afara domeniului de aplicare
În vedere Fara scop
Meniu Vizualizare Plată preplătită
Comanda masa
Vezi comanda
Editați comanda
Vedeți starea comenzii Cerere pentru inventar și furnizor
Livrarea Comanda catre Client
Gateway de plată
Meniu Creare/Actualizare
Selectarea mesei/Rezervare

Generați Bill

Feedback/Comentarii ale clienților

Rapoarte/Date

Modelarea datelor:
ID-ul vasului
Numele farfurii
Preț Permisiune de rol
„Definiția rolului”
Cantitate (Nr. piese) ID angajat Rolul Modul
Categorie ID permisiunea
Prenume utilizatorului ID rol
Disponibilitate element de meniu -t ID angajat - —1 Nume rol Nume permisiunea H Modulul IO
Nume ID modul permis ID Numele
ID-ul vasului
rol asociat modulului
Disponibilitate
Număr de
Data
telefon
E-mail
Adresa ID
restaurant
Restaurant
ID restaurant ID restaurant
ID de masă card de identitate al
Nume stradă
angajatului Meni
Oraș Stat Cod Locuri de
identificare a
ID tabel ul
Cod ID-ul vasului
Număr de restaurantului Cantitate
telefon Email Stare , Starea comenzii
Data comandă
Cantitatea comenzii
Client Instrucțiuni Speciale
Tip comandă (Dine In/livrare)
ID client
Prenume
Prenume
Număr de
telefon
Adresă E-mail

Data aniversară
Data nașterii
Comanda ID
ID- ul vasului
Evaluarea farfurii
Feedback Comentarii

Figura 8: Modelarea datelor folosind diagrama ER

Diagrama activității pistei de înot: Diagrama folosește benzile de înot
pentru a afișa bara de responsabilitate sau de sincronizare pentru a
reprezenta procesele paralele în mai multe zone. Aici activitatea de
comanda online a alimentelor reprezintă modul în care datele circulă pe
benzi.
 The Grill House - Sistem de management al
restaurantului
RMS Bază de
Utilizator
N date •
Logare utilizator

Bază de
Restaurantul D date
Site-ul de gestionare

44

' Selectați clientul N

1______masa
_______ __v
Căutați meniul și selectați
comanda clientului

Plasați comanda și
confirmați
comanda
5
v
Verificarea
inventarului
_____v____
Comanda în coada
P

Comandă pregătită de

____v___
Chef
t
D
Comanda livrata
Clientului

Administrator
1----------1----------N
Generați factura
clientului
______■____
Plătește cu plata S
gateway.
________ T
Clientul
completează M
Formular de
feedback
Comanda inchisa
Wireframe pentru sistemul de management al restaurantelor online:

The Grill House • Managementul restaurantului

< • X C (https //The Grill House/Restouront Monogement System
Sistem ID restaurant NJ258
____________________________________eu CD

i
ID de angajat W12345

Y
r 3
Dine-In

Scoate
Concluzie: Sistemul de management al restaurantelor online ar trebui să
atingă obiectivele de afaceri la lansare.
Obiectivul de afaceri 1: Gestionarea îmbunătățită a lanțurilor de
restaurante, permițând accesul managerilor pentru a actualiza meniul, a
face rezervări și a ține evidența vânzărilor. Ospătarii pot plasa comenzi
pe baza celui mai actual meniu și pot factura clienților cu acuratețe.
Scară: Valoarea este calitatea serviciilor și economisirea de timp.
• Anterioare – facturi pe hârtie
 Obiectivul de afaceri 2: Reducerea costurilor de operare a restaurantului
cu 15% în decurs de 6 luni, după lansarea inițială.
Obiectivul de afaceri 3: Creșterea timpului mediu efectiv de lucru cu 30
de minute per ospătar pe zi și creșterea timpului de lucru al managerului
cu 1 oră în decurs de 3 luni.
Obiectivul de afaceri 4: Rapoartele vor fi generate mai rapid datorită
informațiilor disponibile imediat și acest lucru va ajuta la cunoașterea
tendințelor de vânzări pentru a lua decizii mai bune de planificare și de
meniu.
Obiectivul de afaceri 5: Managementul poate lua decizii mai bune cu
feedback-ul clienților.

Restante produs
Titlu Stat Prioritate Puncte Criteriul de acceptare Calea de
în stoc de iterație
poveste
Ca utilizator vreau să Aprobat 9 2 Având în vedere că utilizatorul Lansarea 1-
îmi creez un cont are acces la aplicație. Dacă Sprint 1
pentru a putea folosi utilizatorul este un angajat
sistemul de valid (ospătar, manager sau
management al altul), atunci contul poate fi
restaurantelor. creat, altfel se afișează „Contul
nu poate fi creat”.

Ca utilizator vreau să Aprobat 9 1 Un utilizator poate schimba Lansarea 1-

schimb parola pentru a parola atunci când introduce Sprint 1
o reseta. vechea sa parolă și i se
permite să creeze o nouă
parolă. Când noua parolă este
introdusă, aceasta ar trebui să
aibă 8 caractere și ar trebui să
aibă 1 caracter, 1 număr și 1
caracter special.

Ca ospătar vreau să Aprobat 5 4 Când se află în aplicație, Lansarea 1-

caut în meniu ca să utilizatorul poate găsi Sprint 1
pot căuta feluri de căutarea. Utilizatorul introduce
mâncare și prețuri. orice valoare și valoarea va fi
afișată.
În calitate de manager, Aprobat
vreau să adaug
elemente noi, să șterg
elementele existente,
precum și să creez noi
meniuri de la zero,
astfel încât meniul să
fie corect.
Ca chelner vreau Aprobat
acces la sistem, așa
că
3 5 Când managerul este în Lansarea 1-
aplicație, ar trebui să poată Sprint 1
găsi meniul. Ei pot adăuga,
șterge sau edita orice articole
și prețuri din meniu.
3 2 Când este în aplicație, Lansarea 1-
chelnerul ar trebui să poată Sprint 2
ca pot plasa comanda pentru a localiza meniul de
clientului. comandă și a selecta feluri de
mâncare pentru a plasa
comanda clientului.
Ca ospătar vreau Aprobat 4 2 Când se află în aplicație, Lansarea 1-
acces la sistem, astfel chelnerul ar trebui să poată Sprint 2
încât să pot genera găsi opțiunea de factură și să
facturi la masă. genereze factura.

Ca ospătar vreau să Aprobat 4 2 Când se află în aplicație, Lansarea 1-

generez nota de plată chelnerul ar trebui să poată Sprint 2
etichetată la mine selecta masa, astfel încât atât
(chelnerul care o numele mesei, cât și id-ul
generează) și numărul chelnerului să fie pe factura
mesei pentru a putea fi generată.
urmărită.

Ca iesle vreau să Aprobat 7 3 Când ieslea este în aplicație, Lansarea 1-

rezerv mese pentru a el poate selecta mese și le Sprint 3
putea fi rezervate. poate rezerva clienților.

În calitate de chelner, Aprobat 6 2 Când se află în aplicație, Lansarea 1-

vreau să analizez chelnerul ar trebui să poată Sprint 3
software-ul pentru a căuta mesele disponibile și să
determina ce mese selecteze masa pentru a
trebuie rezervate, găzdui clienții.
astfel încât să pot lua
masa la clienți.

În calitate de ospătar Nou 4 4 Când utilizatorul se află în Lansarea 1-

sau manager, vreau să aplicație, acesta poate prelua Sprint 3
accesez gateway-ul de plățile clienților prin numerar
plată din sistem, astfel sau cu cardul de credit folosind
încât clienții să poată poarta de plată.
plăti cu numerar sau
card.
În calitate de CEO Nou 5 4 Când este pornit Lansarea 1-
vreau să fie oferit Sprint 3
fiecărui client un
formular de feedback,
astfel încât detalii
precum numele,
adresa, numărul de
telefon mobil, e-mailul,
data nașterii, datele
aniversare ale clienților
și feedbackul lor să
poată fi captate.
Ca manager, vreau să Nou 6 4 Când sunt în aplicație ca Lansarea 1-
introduc manual manager, ar trebui să pot găsi Sprint 4
clientul formularul de feedback
detalii precum numele, pentru imprimare și să poată
adresa, numărul de introduce în sistem informațiile
telefon mobil, e-mailul, din formularul de feedback.
data nașterii, datele
aniversare și
comentariile acestora,
astfel încât feedback-
ul și informațiile
clienților să poată fi
stocate în sistem.

În calitate de Nou 3 8 Când se află în aplicație, Lansarea 1-

conducere vreau conducerea ar trebui să poată Sprint 4
rapoarte despre genera rapoarte care arată
tendințele vânzărilor la tendințele vânzărilor.
EOD, astfel încât să se
poată lua decizii.