RestSys. Iterace 6. Restaurační systém pro malé restaurace a kiosky

Rozměr: px

Začít zobrazení ze stránky:

Download "RestSys. Iterace 6. Restaurační systém pro malé restaurace a kiosky"

Karla Svobodová
před 8 lety
Počet zobrazení:

1 RestSys Restaurační systém pro malé restaurace a kiosky Iterace 6 Zkratka projektu RES projektu restsys@uxsoft.cz Stránky projektu Seznam řešitelů Jan Dryk Termín cvičení Úterý 14:30 Jméno cvičícího Ing. Martin Komárek Datum odevzdání

2 Obsah Obsah Zpráva o testování Zpráva o nasazení Vyhodnocení plánů Doporučení pro další vývoj Výkaz práce jednotlivých členů Jan Dryk Celkem Individuální zpětné hodnocení celého projektu Jan Dryk Skupinové zpětné hodnocení celého projektu Tabulka s přerozdělením bodů

Celkem Individuální zpětné hodnocení celého projektu Jan Dryk

3 Zpráva o testování Testování zahrnovalo šest automatických testů na základní funkce aplikace, které probíhaly za pomocí třídy FluentAutomation, která se využívá k testování webového rozhraní. Těchto šest testů proběhlo úspěšně bez nutné změny v aplikaci. Bohužel zbylé testy na evidenci objednávek (v klientské aplikaci) nemohly být provedeny, protože tyto testy není možné vytvořit pomocí aplikace Selenium. Automatické testy pro kontrolu: vytvoření zboží úpravy zboží vytvoření produktu úpravy produktu přidání uživatele odebrání uživatele Zpráva o nasazení Webová aplikace byla vytvořena pomocí technologie Microsoft ASP.NET MVC. Jako databázi jsme zvolili Microsoft SQL Server. Přístup a mapování do databáze nám zajišťuje Microsoft Entity Framework. K tvorbě RESTového endpointu jsme využili součásti Microsoft ASP.NET stacku Microsoft ASP.NET Web Api. Webová aplikace běží ve webovém serveru IIS. VM Uživatel: Rest VM Heslo: 12!@abAB Webovou (serverovou část) systému lze po zpuštění zpřístupnit v prohlížeči na adrese V aplikaci je předpřipravený účet pro testovací účely, se kterým je možné se do systému přihlásit: Uživatelské jméno: test Heslo: test Klientská aplikace: Nastavení se objeví, když se klientská aplikace nedokáže připojit k serveru. Lze jej vyvolat kdykoliv z tzv. charms menu systému (to lze zobrazit najetím myší do pravého horního rohu hýbnutím myši směrem dolů, potom zvolením ozubeného kola. V tomto menu má RestSys sekci Nastavení) Aplikace také využívá menu App Bar které lze vyvolat pravým klikem blízko dolní části obrazovky. V Settings nastavte adresu serveru ( a stiskněte spojit. Pokud spojení proběhne úspěšně proveďte to samé pro přihlášení. Přihlašovací údaje jsou totožné se serverovou aplikací (test test).

Bohužel zbylé testy na evidenci objednávek (v klientské aplikaci) nemohly být provedeny, protože tyto testy není možné vytvořit pomocí aplikace Selenium.

4 Vyhodnocení plánů Na projektu jsme celkem splnili 20 požadavků, 6 jich bylo splněno částečně a 1 vůbec. Klientská aplikace pro Windows 8 byla dokončena částečně. Je schopna vytvářet objednávky, přidávat do objednávek produkty, označovat zaplacené produkty, vytvářet a tisknout účtenky. Naopak v ní není implementována spolupráce se čtečkou čárových kódů, správa produktů a zboží. Webová část systému byla dokončena téměř celá, ale nelze v ní vyhledávat položky, podle zadaného klíče (nicméně je možné je vyhledávat pomocí staromódního Ctrl+F). Neimplementované a rozdělané části projektu jsou důsledkem práce na klientské aplikaci pro Windows 8, kterou jsme silně podcenili. Při vytváření kritické cesty jsme předpokládali, že na něm strávíme 4 dny práce. Ve skutečnosti bychom potřebovali minimálně dvojnásobek času. Také jsme nestihli dokončit testování klientské aplikace. Při vytváření vize jsme odhadovali na základě ukázkových projektů, že každý člen týmu stráví prací na projektu zhruba 120 hodin. Tento odhad se ukázal být naprosto mimo, zčásti je to použitím rozdílných technologií, než které byly v ukázkových projektech a zčásti nezkušeností týmu s podobnými projekty.

Naopak v ní není implementována spolupráce se čtečkou čárových kódů, správa produktů a zboží.

5 Doporučení pro další vývoj Část systému nebyla implementována, případně pouze rozpracována. Doporučovali bychom při dalším vývoji začít tam: Klientská aplikace Správa zboží V aplikaci by uživatel měl být schopen vytvořit nové zboží a upravit ho Podpora pro čtečku čárových kódů pro jednoduchou evidenci dostupného zboží na skladě Uživatelské rozhraní UI aplikace je velice jednoduché, strohé a uživatelsky nepřívětivé, doporučovali bychom ho předělat (v rámci možností Win8) Webová část systému Vyhledávání položek Není doimplementováno vyhledávání uživatelů, produktů, zboží a objednávek podle zadaného klíče přihlášeným uživatelem Globální administrace Není doimplementovaná sekce s informacemi pro zadavatele projektu a majitele restaurace. V sekci měla být vyplněna měna, jméno restaurace a její logo, které by se pak zobrazovalo v jídelním lístku a na účtenkách.

jednoduchou evidenci dostupného zboží na skladě Uživatelské rozhraní UI aplikace je velice jednoduché, strohé a uživatelsky nepřívětivé, doporučovali bychom ho předělat (v rámci možností Win8) Webová

6 Výkaz práce jednotlivých členů Jan Dryk

7 Celkem Iterace Počet hodin Iterace 1 11 Iterace Iterace Iterace 4 22 Iterace Iterace Celkem Individuální zpětné hodnocení celého projektu Jan Dryk Pokud bych znova dělal takový projekt, tak bych rozhodně nezvolil systémy assembla.com a Git které pro nás nefungovaly. Git jako source control system nedokáže fungovat s binárními soubory korektně a navíc nesouhlasím s decentralizovaným source control systémem jako takovým vzhledem k jeho nevýhodám. Assembla pro nás byla spíš práce navíc než způsob jak managovat práci jelikož jsme si stejně museli rozdělit práci slovně a pak jsme jenom to, co už jsme udělali zpětně zapisovali do assembly. Assembla tak pro nás byla spíš prítěž než užitek. Místo Assembly bych spíš využil Visual Studio Online (visualstudio.com), které nám je schopno poskytnout Team Foundation Server Source Control System, který odstraňuje problémy s Gitem a nabízí podobné služby jako assembla ale má mnoho výhod navíc jako integraci s source controlem a Visual Studiem. S celkovou prací na projektu jsem byl spokojen. Rozhodně ale mohla být lepší v tom, že by se členové více zajímali o dění projektu a nečekali, až jim někdo něco přidělí. To lze ale z velké části svést na množství práce pro jiné předměty. Osvědčila se nám struktura kde jeden člověk měl na starost rozdělovat práci a koordinovat tým. Role v týmu jsme si rozdělili hned první týden, díky čemuž bylo jasné, kdo bude mít kterou část projektu na starost. Problémy ale nastaly při samotné práci s *.eap souborem s projektem, který jsme nešťastně sdíleli přes GitHub. V projektu vznikaly konflikty, protože se zapomínalo

Git jako source control system nedokáže fungovat s binárními soubory korektně a navíc nesouhlasím s decentralizovaným source control systémem jako takovým vzhledem k jeho nevýhodám.

8 commitovat/stahovat poslední verzi, apod. Oprava těchto konfliktů zabrala hodně času, který by se dal strávit jinak. Další problémy vznikaly při komunikaci v zadávání úkolů v týmu (což byla hlavně moje zodpovědnost) zatímco jednomu členu týmu stačilo vysvětlit stručně, co je třeba udělat; dalšímu to nestačilo a bylo nutné mu vše vysvětlit do detailu. Projevilo se to nejvíc na společné kontrole dokumentace před jejím odevzdáním. Na konci projektu byla poměrně špatně rozdělena práce, následkem neaktivity jednoho člena týmu na jedné z iterací a nespokojenosti s jeho prací na vzhledu a generování dokumentace, kterou převzal někdo jiný. Projekt celkově považuji za poučnou záležitost (z pohledu práce a dynamiky v týmu, analýzy i programatorského využili jsme technologie, které na škole nejsou běžnou praxí). Bohužel jsme nestihli dodělat celý projekt nesplněny zůstávají 4 požadavky z 27. Podcenili jsme náročnost programování klientské aplikace pro Windows 8 a zároveň si věřím, že by byla znát i jeden člen týmu navíc. Jako tým jsme spíš fungovali většinou samostatně(každý svojí část) pouze když se něco opravovalo a kontrolovalo tak jsme o tom diskutovali, prišlo by mi občas lepší,kdyby jsme některé složitější věci řešili rovnou všichni tak by se to pak mohlo rychleji a lépe vyřešit. Skupinové zpětné hodnocení celého projektu Od prvního jsme si rozdělili role v týmu a před každou iterací rozhodli, kdo za kterou část projektu nese zodpovědnost, případně s kým ji má konzultovat. Před odevzdáním iterace jsme dokumentaci společně prošli a opravili nedostatky. Rozhodně doporučujem zapisovat si tyto úkoly i mimo Assemblu, např. na Google Docs s poznámkami, aby byl o všech úkolech přehled. Velice důležité je taky mít rovnoměrně rozdělovat práci v průběhu celého projektu.

bylo nutné mu vše vysvětlit do detailu. Projevilo se to nejvíc na společné kontrole dokumentace před jejím odevzdáním.

9 Tabulka s přerozdělením bodů 11. Týden 13. Týden Jméno Celkem bodů Důvod Body Celkem Dryk Jan 3 Domluvené srovnání bodů na Nguyen Tat Phong Ondřej Štembera 0 Domluvené srovnání bodů na Domluvené srovnání bodů na Celkem Pozn.: Celá tabulka se nevešla do dokumentu, a je dostupná na wiki projektu. Uvedená tabulka obsahuje pouze relevantní sloupce pro současnou iteraci.

Phong Ondřej Štembera 0 Domluvené srovnání bodů na 0 0 0 3 Domluvené srovnání bodů na 0 3 0 Celkem

Podobné dokumenty

TouchGuard Online pochůzkový systém

TouchGuard Online pochůzkový systém Uživatelský manuál TTC TELEKOMUNIKACE, s.r.o. Třebohostická 987/5 100 00 Praha 10 tel.: 234 052 111 fax.: 234 052 999 e-mail: ttc@ttc.cz http://www.ttc-telekomunikace.cz