Peklák (PKK) interní rezervační systém

Transkript

1 Peklák (PKK) interní rezervační systém Předmět A7B36USI paralelka 111 Pondělí 12:45 cvičící Ing. Martin Komárek ČVUT FEL Odkaz Michal Haba, Jiří Rychlovký, Jan Teplý, Barbora Tomková, Josef Veselý Termín odevzdání: 28. října 2013

2 Peklák interní rezervační systém Obsah Peklák interní rezervační systém Stručný popis Zainteresované osoby Zadavatel a dodavatel Uživatelé systému Současný stav Nevýhody stávající situace Výhody stávajícího řešení Klíčové vlastnosti Na straně uživatele systému (uživ. role: Klient, přístup: mobilní aplikace) Na straně správce systému (uživ. role: Zaměstnanec, přístup: terminál) Implementace Centrální aplikace Terminál Mobilní aplikace Požadavky pro funkční nasazení Omezení požadavků Minimální požadavky Finance Licenční ujednání Rozdělení případných zisků Termíny

3 1.0 Stručný popis Sportovní areál Peklák (informace dostupné na adrese pro zkvalitnění služeb potřebuje dodat systém, který umožní evidovat rezervace, směny zaměstnanců a vést záznamy o poskytnutých službách. Systém umožní zákazníkům rezervovat si termín půjčení kol, objednat si návštěvu lanového parku či si zamluvit lekce v lyžařské škole. Provozovateli bude umožněno evidovat počet návštěvníků, odučených lekcí, půjčených kol a také směny zaměstnanců a spravovat zarezervované termíny. 2.0 Zainteresované osoby 2.1 Zadavatel a dodavatel Firma zákazníka - Sportovní areál Peklák Vývojový tým - Michal Haba (habamich@fel.cvut.cz) - Jiří Rychlovský (rychljir@fel.cvut.cz) - Jan Teplý (teplyja1@fel.cvut.cz) - Barbora Tomková (tomkobar@fel.cvut.cz) - Josef Veselý (veseljo5@fel.cvut.cz) Vedoucí projektu Ing. Martin Komárek (komarem@fel.cvut.cz) Konzultantka Tereza Soukupová (soukuter@fel.cvut.cz) 2.2 Uživatelé systému - Zákazníci jedná se o zákazníky areálu Peklák - Zaměstnanci ty dále dělíme do tří podskupin, které se liší tím, jaká mají oprávnění: Manažer jedná se o vedoucího pracovníka Zaměstnanec řadový zaměstnanec, který se stará o chod areálu Lektor má na starost lyžařské kurzy. 3.0 Současný stav V současné době je plánování směn zaměstnanců a rezervace řešena tak, že směny si zaměstnanci domlouvají telefonem nebo em, a takto získané informace pak manažer zapíše do tabulky, která je rozeslána zaměstnancům. Následná docházka je kontrolována pomocí čipových karet. 3

4 Rezervace zákazníků jsou opět přijímány em nebo telefonicky a poté jsou ručně zapisovány do tabulkového procesoru. 3.1 Nevýhody stávající situace Nevýhodou tohoto řešení je nedostatečný přehled a orientace ve směnách lektorů a zaměstnanců. Současná evidence návštěvníků a směn zaměstnanců může vést k chybám, způsobeným lidským faktorem. 3.2 Výhody stávajícího řešení Naopak výhodou je, že stávající systém není závislý na připojení k internetu a počítačových technologiích celkově. Co se dá považovat za výhodu je také to, že zaměstnancům stávající situace vyhovuje. 4.0 Klíčové vlastnosti 4.1 Na straně uživatele systému (uživ. role: Klient, přístup: mobilní aplikace) - Prohlédnutí nabídky služeb (sportů) - Možnost rezervace a zrušení rezervace vybavení na určený čas - Rezervace případné zrušení rezervace konkrétního sportu na určený čas - Možnost přihlášení a odhlášení na kurz u lektora sportu - Možnost zamluvení areálu pro skupinu - Možnost hodnocení spokojenosti s poskytnutými službami - Možnost sledování historie svých aktivit - Možnost zobrazení kalendáře připravovaných a proběhlých akcí 4.2 Na straně správce systému (uživ. role: Zaměstnanec, přístup: terminál) - Sledování rezervací v reálném čase - Možnost přihlášení lektora na směnu - Možnost přidání a smazání uživatele typicky lektora - Možnost sledování obsazenosti areálu - Možnost sledování zbývajícího a půjčeného vybavení - Evidence zákazníků a jejich aktivita - Sledování statistik o Oblíbenost sportů o Návštěvnost o Půjčování náčiní o Finanční statistiky - Možnost vytváření a správa akcí - Sledování feedbacků od zákazníků 4

5 5.0 Implementace Následující popis je pouze prvotním návrhem implementace, která se může v průběhu vývoje aplikace měnit. Centrální aplikace bude psána v programovacím jazyce Java a poběží na serveru v areálu. Přes protokol TCP bude komunikovat s desktopovou aplikací běžící na místním počítači a s mobilní aplikací pro platformu Android, kterou si návštěvníci areálu mohou stáhnout do svých chytrých telefonů. Způsob komunikace s mobilní aplikací zatím není navržen. 5.1 Centrální aplikace Program bude přistupovat k databázi, kde budou zaznamenány veškeré informace o uživatelích, akcích, lekcích a směnách. Aplikace musí poskytovat všechny služby, jak pro správce systému (viz kapitola Klíčové vlastnosti), tak i pro běžné uživatele systému. 5.2 Terminál Terminál bude sloužit pouze pro zaměstnance areálu. Zde se zaměstnanec přihlásí pod svůj uživatelský účet a tím získá práva v systému. Možnosti využití podle úrovně účtu jsou popsány v kapitole 4.3 Role uživatelů systému. 5.3 Mobilní aplikace Mobilní aplikace a aplikace dostupná z terminálu poskytuje funkce pouze pro běžné uživatele (viz kapitola 4.0 Klíčové vlastnosti). 6.0 Požadavky pro funkční nasazení Hlavní aplikace bude realizována v prostředí Java. Pro analýzu a návrh bude použit nástroj Enterprise Architect. Mobilní aplikace bude navržena pro tablety a mobilní telefony s operačním systémem Android 2.0 a vyšším. Platforma Android byla zvolena, protože tato platforma je podle průzkumů nejrozšířenější na českém trhu. 6.1 Omezení požadavků Vzhledem k velice obtížnému prosazení programovacího jazyka PHP se zvolil pro realizaci jazyk Java. Z databázových systémů využijeme bezplatného řešení SQL. 6.2 Minimální požadavky Operační systém Windows - Windows XP SP3 - RAM 512MB - Volné místo na disku 124MB 5

6 Operační systém Mac OS - Mac OS X (Lion) 7.0 Finance Projekt s největší pravděpodobností nebude nasazen v praxi, a proto si žádný ze členů vývojového týmu nenárokuje žádné finanční ohodnocení. V případě reálného nasazení se budeme řídit podle bodu 7.1 Licenční ujednání a bodu 7.2 Rozdělení případných zisků. 7.1 Licenční ujednání Pro reálné nasazení tohoto produktu je nutný souhlas všech členů vývojového týmu. Případné manipulace se zdrojovým kódem musí být odsouhlasený podpisem celého vývojového týmu bez výjimky a zdrojový kód předložen k nahlédnutí. Pokud se provozovatel (sportovní areál Peklák) rozhodne využít tento software, má plné právo na využívání programu v plném rozsahu. Není dovolena žádná manipulace se zdrojovým kódem ani poskytnutí žádné části programu třetí straně, s výjimkou mobilní aplikace, která bude veřejně přístupná. Vývojový tým si však vyhrazuje právo na správu softwaru a případné nástavby softwaru. 7.2 Rozdělení případných zisků Software a licence je nabízena zdarma. V případě finančního ohodnocení se zisk rozpočítá poměrově k počtu odpracovaných hodin jednotlivce. 8.0 Termíny Termíny odevzdání jednotlivých částí projektu se řídí organizací semestru předmětu A7B36USI. 3. týden semestru Vize projektu 5. týden semestru Prvotní analýza 8. týden semestru Detailní analýza 10. týden semestru Model architektury 12. týden semestru Odevzdání hotového projektu 6