Návrh a realizace informačního a rezervačního systému pro společnost Decstore

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh a realizace informačního a rezervačního systému pro společnost Decstore Diplomová práce

Vedoucí práce: Ing. Pavel Haluza, Ph.D.

Bc. Martin Procházka

Brno 2015

2

Děkuji vedoucímu mé práce, panu Ing. Pavlu Haluzovi, Ph.D., za vedení, ochotný přístup, trpělivost a odbornou pomoc během psaní této práce.

4

Čestné prohlášení Prohlašuji, že jsem tuto práci: Návrh a realizace informačního a rezervačního systému pro společnost Decstore vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše.

V Brně dne 15. května 2015

................................................................

6

7

Abstract PROCHÁZKA, M. Design and realization of information and reservation system for Decstore company. Brno, 2015. Diploma thesis. Thesis deals with the issue of design and implementation of information and reservation systems. Given problem conceives both in general level and solved a concrete specific problems of the company Decstore. At the beginning specifies requirements for the system and informs about the issue. Completely new design of the system and all it’s components are created by the requirement. From the requirements on system were elected software resources used for implementation. By the using these devices, and from the results of analysis and design have been proceed to implement the system. In the thesis is described the implementation of information and the reservation system separately. The outcome of thesis is tested of course and the end is properly assessed and future enhancements of the system are designed.

Abstrakt PROCHÁZKA, M. Návrh a realizace informačního a rezervačního systému pro společnost Decstore. Brno, 2015. Diplomová práce. Práce se zabývá problematikou návrhu a realizace informačních a rezervačních systémů. Zadanou úlohu pojímá v obecné rovině a zároveň řeší i konkrétní specifické problémy společnosti Decstore. Na začátku specifikuje požadavky na systém a informuje o dané problematice. Z požadavků je dále vytvořen nový kompletní návrh systému se všemi jeho komponentami. Podle požadavků na systém byly zvoleny i programové prostředky použité pro implementaci. Za použití těchto prostředků a z výsledků analýzy a návrhu bylo přistoupeno k implementaci systému. V práci je popsána zvlášť implementace informačního a rezervačního systému. Výsledek práce je samozřejmě otestován a na konec je i řádně zhodnocen. Navrženy jsou i budoucí vylepšení systému.

8

9

OBSAH

Obsah 1 Úvod a cíl práce 11 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2 Společnost Decstore 13 2.1 Specifikace požadavků . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3 Literární přehled 3.1 Pojem informační systém . . . . . . . . . 3.2 Historie . . . . . . . . . . . . . . . . . . 3.3 Druhy informačních systémů . . . . . . . 3.4 Životní cyklus IS . . . . . . . . . . . . . 3.5 Ukazatele přínosů informačního systému 3.6 Existující řešení . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Porovnání s informačním systémem K2

16 16 16 17 18 18 19 21

5 Návrh systému 23 5.1 Funkční model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2 Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Entity navrhovaného systému . . . . . . . . . . . . . . . . . . . . . . 27 6 Programové prostředky použité při implementaci 6.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Kaskádové styly . . . . . . . . . . . . . . . . . . . . 6.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . 6.5 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 SQL . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

30 30 30 31 32 32 33

7 Popis informačního systému 7.1 Obecná funkcionalita . . . 7.2 Přídavné moduly . . . . . 7.3 Sekce můj účet . . . . . . 7.4 Sekce zaměstnanci . . . . 7.5 Sekce zákazník . . . . . . 7.6 Sekce zboží . . . . . . . . 7.7 Speciální funkce . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

35 36 37 40 40 41 41 43

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

8 Popis rezervačního systému 47 8.1 Postup rezervace zboží . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Sekce kategorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

10

OBSAH

8.2

8.3

Sekce detail produktu . . . . . . . . . . . . . . . . . . . . . . . Sekce košík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procesy běžící na pozadí . . . . . . . . . . . . . . . . . . . . . . Popis procesů probíhají během nákupu zákazníka bez registrace Popis procesů probíhají během nákupu registrovaného zákazníka Změna počtu kusů u zboží . . . . . . . . . . . . . . . . . . . . . Data mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Režim nepřihlášeného uživatele . . . . . . . . . . . . . . . . . . Režim přihlášeného uživatele . . . . . . . . . . . . . . . . . . . . Analýza nákupního koše . . . . . . . . . . . . . . . . . . . . . .

9 Bezpečnost

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

49 50 52 52 52 53 54 55 56 56 58

10 Testování 61 10.1 Výsledky testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 11 Diskuze a závěr 63 11.1 Diskuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 11.2 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 12 Literatura

65

1

ÚVOD A CÍL PRÁCE

1 1.1

11

Úvod a cíl práce Úvod

Vývoj informačních a komunikačních technologií jde každým rokem kupředu. Podle Moorova zákona se jenom výkon procesorů každých 18 měsíců zdvojnásobí při zachování stejné ceny. Toto tvrzení bylo vysloveno v roce 1965 a stále je považováno za velmi přesné. Tento dlouholetý trend nabízí spoustu možností jak tyto technologie využívat ve svůj prospěch. I v oblasti informačních systému docházelo, a určitě stále bude docházet k vývoji směrem kupředu. Informační i rezervační systémy ve spojení s kvalitním hardwarem umožnují výrazným způsobem zvyšovat proudění informací napříč firemními procesy. Informační systémy dokáží vyvolávat změny ve stylu podnikání a stále měnit a vylepšovat podnikové procesy. Správné používání a kvalitní analýza výstupů těchto systémů může firmám poskytovat nezanedbatelnou konkurenční výhodu, popřípadě rozšiřovat působnost na trhu. Existuje velká spousta informačních a rezervačních systémů. Jedno mají ale všechny systémy společné. Aby mohly naplno využít svůj potenciál, musí splňovat řadu důležitých parametrů. Musí disponovat potřebnou funkcionalitou, pracovat plynule a bez poruch, bezpečně chránit citlivá firemní data a v neposlední řadě být uživatelsky přívětivé. I přes společné parametry kvalitních systémů se může každý ve mnoha věcech odlišovat. Rozdíly nalezneme v jejich účelu, obsahu, rozsahu, strukturální složitosti, počtu a typu uživatelů a územním zaměření. Předností IS je schopnost ukládat, zpracovávat a reprezentovat data tak, aby bylo možné z těchto výsledků vyvodit relevantní, ale hlavně do budoucna pozitivní rozhodnutí. To znamená, že vlastně slouží jako podpora pro řízení podniku. Společnosti Decstore by měl přinést, kromě potřebné podpory pro řízení, evidenci veškerých důležitých informací, ale také podporu prodeje. Odvětví nákupu, popřípadě půjčování dekorací, je poměrně moderní. Nejvíce výrazné to může být právě na svatbách. Každá svatba se pokouší na venek působit jako ta nejhezčí nebo nejoriginálnější popřípadě oboje. Dříve ale nebylo trendem si na takovéto akce shánět speciální dekorace. Dnes se situace obrací a nevěsty se snaží, aby bylo vše dokonale sladěné jak barevně, tak po stránce materiálové. Díky tomu na scénu nastupují půjčovny a prodejci dekorací, kteří tyto doplňky nabízejí. Stejným trendem směřují firemní večírky, ale i rodinné a především dětské oslavy. Pro toto odvětví platí, že disponuje potenciálem budoucího růstu. V tomto případě je funkční a hlavně kvalitní softwarová podpora nezbytností. Dokáže do budoucna předejít spoustě problému a také pomůže v rychlejším růstu a rozvoji. Tato podpora se skládá z informačního a rezervačního systému. IS se stará o ukládání informací do databáze a jejich zpracovávání. Rezervační systém se stará o jejich prezentaci.

12

1.2

1 ÚVOD A CÍL PRÁCE

Cíl práce

Cílem této práce bylo vytvoření informačního a rezervačního systému podle specifických požadavků společnosti Decstore. Důvodem tvorby této softwarové podpory bylo zvýšení komfortu pro zákazníky, zrychlení, zefektivnění a usnadnění administrativních činností pro zaměstnance a snížení nákladů na tuto práci. To by mělo mít za následek obsloužení většího počtu zákazníků za jednotku času a díky tomu i možnost generovat větší zisk. Což přinese užitek jak zákazníkům, tak i uživatelům a provozovatelům IS. To vše se stálou zárukou nízkých nákladů na tvorbu a především provoz systému. Cílem bylo zároveň vytvořit IS, který by měl poskytovat tyto informace řídícím pracovníkům tak, aby byli schopni vykonávat funkce, mezi které patří zejména plánování, koordinace a kontrola veškerých procesů firmy. Rezervační systém by měl vhodnou prezentací produktů a systémem doporučování zvyšovat tržby a podíl firmy na trhu.

2

SPOLEČNOST DECSTORE

2

13

Společnost Decstore

V pozadí tohoto projektu stojí dva rodinné podniky, které společně udržují přátelské kontakty. Oba podniky mají svoje svatební agentury (www.jedinecnasvatba.cz a www.callmebride.cz). Jak sami říkají, své podnikaní budují trpělivě a spolehlivě tak, aby za nimi byla vždy dobře odvedená práce a spokojení klienti. Oba podniky mají podobné vize a společný pohled na věc, dokonce již v minulosti spolupracovali na několika společných projektech. To byl prvotní impuls, proč začali uvažovat o myšlence společného podniku. Společnost vznikla ze vzrůstající poptávky po dekoracích, nejen pro svatební účely. Druhým impulsem pro realizaci tohoto konceptu byla koupě zázemí v podobě statku, který by se dokonale hodil jako sklad dekorací. Další plány s tímto statkem souvisí s možností vybudovat ateliér, který bude sloužit pro další část podnikání, a to pořádání kurzů a workshopů na různá témata. Budoucí myšlenky společnosti nesměřují pouze k půjčovně a ateliéru, snaží se také o vybudování místa, kde si budou moci lidé vyrobit svoje dekorace nebo se naučit něco nového. Tato myšlenka je inspirována kulturou DIY1 . Proto v roce 2014 vznikl nápad spojit definitivně služby obou rodinných podniků a založit společnost, která bude nabízet nadstandardní půjčovnu dekorací a poskytne doplňkové služby, které na trhu chybí. Společnost Decstore s.r.o. vznikla oficiálně v únoru 2015. Jednatelkami se staly Zuzana Černochová a Michaela Dvořáčková. Má tři stálé zaměstnance a spolupracuje s několika brigádníky, kteří se starají o sklad nebo jezdí zdobit svatby. Základem podnikání bude půjčovna především svatebních dekorací. Sortiment půjčovny se již několik let postupně rozrůstá o různé dekorační předměty, které se nyní budou půjčovat široké veřejnosti v rámci vytvořeného e-shopu. Myšlenka půjčovny bude sloužit nejen nevěstám, ale i obyčejným lidem, kteří si chtějí vytvořit ze svého domova pěkné místo, například na Vánoce či Velikonoce. Kvůli tomu si nemusejí kupovat zbytečně dekorace, kterou by už nevyužili, ale jednoduše si je mohou půjčit. Cílem je obsluhovat jak koncové zákazníky, tak i svatební a jiné agentury, které si zboží budou půjčovat. Výhodou společnosti jsou sklady o rozloze asi 300 m2 , kde se může skladovat i nábytek (židle, stoly), který se nyní hojně na svatbách využívá. Další vizí do budoucna, která je spojená se svatbami, je floristika. To obnáší vybudování vazárny květin, kde se budou moci vyrábět originální kytice nejen pro svatby. Já jsem se o společnosti Decstore dozvěděl před více jak půl rokem. Pro mě byl Decstore novým projektem s cílem zacelit díru na trhu v oblasti půjčování popřípadě prodeje předmětů a dekorací na společenské akce. V celé České republice je minimum společností nabízejících tak velkou škálu zboží na jednom místě. V Brně a okolí je jich ještě méně. Potenciálními zákazníky by měly být firmy popřípadě středně movití nebo bohatší jednotlivci, kteří si potrpí na svých večírcích, oslavách nebo svatbách na stylových dekoracích. Firma je založena sloučením lidí, kteří se 1

Do it yourself (Udělej si sám) – jedná se o druh kultury, ve které si člověk sám, bez profesionální podpory, zhotoví užitečný výrobek, který slouží jemu nebo ostatním lidem.

14

2

SPOLEČNOST DECSTORE

úspěšně pohybují v tomto oboru delší dobu a chtějí rozšířit svoje působení na trhu. K tomuto účelu je samozřejmě v dnešní době nutná softwarová podpora a to především na internetu. To byl hlavní důvod začátku spolupráce. Decstore potřeboval nejen svoje webové stránky pro nabízení svých služeb, ale také interní informační systém pro jednoduchou správu svých firemních zdrojů. Možnost odstartování tohoto projektu jako součást mé diplomové práce, byla pro obě strany výhodná. Pro mě bylo dané téma vhodné, protože s podobným projektem už mám jisté zkušenosti, pro vedení společnosti bylo výhodné po finanční stránce. Před spuštěním toho projektu společnost Decstore neměla žádný elektronický informační systém. Všechny procesy od evidence zakázek, až po evidenci zboží musely být prováděny ručně za pomoci excelových tabulek a podobných nástrojů. Taková práce se skládá ze stále stejných rutinních činností a zdlouhavých procesů. Internetové stánky společnosti sice existovaly, ale přesnější označení by bylo spíše internetová stránka. Jednalo se jen o úvodní stránku s odkazem na facebook a o telefonní čísla na zprostředkovatele, jak jde vidět na obrázku číslo 1. Hlavní práci z hlediska reklamy a marketingu zastávala již zmíněná facebooková stránka, která je stále aktivní, ale nedostačují pro uspokojení potřeb cílových zákazníků. To je hlavní důvod proč bylo přistoupeno k návrhu informačního a rezervačního systému.

Obrázek 1: Ukázka původních webových stránek Decstoru.

Komunikace se společností probíhala ve dvou rovinách. Ze začátku se skládala výhradně z osobních schůzek, kde byla řešena specifikace, návrh systému a design. Během implementační části se změnila spíše na telefonickou a e-mailovou komunikaci s občasnými sezeními kde se konzultovali výsledky.

2.1

2.1

Specifikace požadavků

15

Specifikace požadavků

Hlavním záměrem bylo vytvořit webové stránky, kde si potenciální zákazník může vypůjčit produkty z daného sortimentu společnosti. Dále pak informační systém, který bude s tím rezervačním propojen a bude pracovat pod stejnou databází. Informační systém by se měl starat o správu a evidenci následujících entit: • Zaměstnanci – Sekce bude obsahovat zvlášť evidence zaměstnanců a brigádníků. U každého bude možnost vytvoření uživatelského účtu do informačního systému. V databázi uchovávat důležité informace včetně adresy. • Zákazníci – Sekce bude obsahovat evidence stávajících zákazníku včetně historických záznamů. U každého bude možnost vytvoření uživatelského účtu do rezervačního systému. V databázi uchovávat důležité informace včetně adresy. • Zakázky – Sekce obsahuje možnosti pro evidenci a správu zakázek. Ke každé zakázce bude nutné přiřadit zákazníka. Zakázka bude dále rozdělena na jednotlivé části podle kategorie. • Zboží – Sekce obsahuje evidenci všech produktů z nabídky společnosti a zároveň vytváří kompletní uživatelsky přívětivé prostředí pro editaci a vytváření produktu. Informace zadané v této sekci se ihned musí promítat v rezervačním systému. Rezervační systém by měl být schopný danému zákazníkovi doporučovat vhodné zboží podle toho, co vloží do košíku, popřípadě to co je zrovna v akci. Systém musí dále obsahovat standardní funkce jako je vyhledávání, řazení, filtrování, vkládání do kategorií a podobně. Všechna data musí být bezpečně uchovávány a zpřístupňovány jen vhodným osobám. Databáze musí být schopna uchovávat historické informace k tvorbě přehledů a jako podklad pro dataminingové funkce. Systém musí být navržen tak, aby ho byli schopni obsluhovat kromě vedení i zaměstnanci a brigádníci. Koncepce byla navržena tak, že vedoucí rozdává úkoly skrz informační systém a systém oznámí zaměstnancům, co má udělat. Jakmile zaměstnanec vyřídí nějakou část objednávky, tak systém informuje vedení o tom, že je tato část dokončena a že si jí muže zkontrolovat. Další požadavky: • Nízká pořizovací cena. • Společné propojení informačního a rezervačního systému. • Práce pod jednou databází. • Implementace do webového prohlížeče. • Uživatelskou přívětivost, snadné ovládání, přehledné rozmístění funkčních prvků. • Možnost bezpečného přihlašování.

16

3 3.1

3

LITERÁRNÍ PŘEHLED

Literární přehled Pojem informační systém

Existuje velké množství definic tohoto pojmu. Přesná definice přesto neexistuje, protože každý uživatel nebo tvůrce informačního systému preferuje jiné terminologie a zdůrazňuje jiné aspekty systému. Podle (Hronek, 2007) umožňuje informační systém účelné uspořádání sběru, uchovávání, zpracovávání a poskytování informací. Podle (Šmíd, 2002) můžeme říci, že informační systém lze chápat jako systém vzájemně propojených informací a procesů, které s těmito informacemi pracují. Přičemž pod pojmem procesy rozumíme funkce, které zpracovávají informace do systému vstupující a transformují je na informace ze systému vystupující. V podstatě tento proces zabezpečuje sběr, přenos, uložení, zpracování a distribuci informací. Pod pojmem informace pak rozumíme data, která slouží zejména pro rozhodování a řízení v rozsáhlejším systému. Zjednodušeně můžeme říci, že definice procesů u (Šmíd, 2002) je podobná jako definice celého systému u (Hronek, 2007). Kromě samotného IS je nutné definovat i další důležitou část a tou je okolí. Okolí informačního systému tvoří takové objekty, které ovlivňují samotný systém při změně svých atributů a také objekty, které naopak mění své atributy v závislosti na systému. (Šmíd, 2002)

3.2

Historie

První náznaky informačních systémů se objevují už v šedesátých letech. Roku 1958 vychází v IBM Journal článek A Business Intelligence Systém“ od H. P. Luhna. V té ” době bylo zpracování informací na nízké úrovni a jednalo se spíše o koncept distribuce dat. Vývoj systému neprobíhal jen ve velkých organizacích, jak by se mohlo na první pohled zdát, ale také na vysokých školách. Nejdříve se uplatňují v obchodu a průmyslu obvykle v účetních odděleních větších podniků. Předpokládalo se, že tato oblast dokáže nejvíce využít předností IS. Počítače v té době byly mimo dosah středních a menších podniků. Zpočátku je interaktivita s uživateli nízká a výpočetní středisko je odděleno od zbytku podniku. (Rana, 2001) Během sedmdesátých let už většina větších podniku uznala význam IS. Tušili, jakou flexibilitu do podnikání to může přinést. Potřeba organizovaného a snadného přístupu k informacím se ukázala jako stěžejní pro dynamicky se vyvíjející podniky. Některé firmy utrácely obrovské množství peněz na vývoj systému a softwaru, bez jistoty návratu investic. Přesto byly systémy složité a často se měnily. Docházelo ke zmatkům a problémům ve fungování a proto se začala objevovat první pravidla pro tvorbu systémů. V sedmdesátých letech společnost Lockheed použila první interaktivní aplikaci pro manažery (Management Information and Decision Support) (Winter, Haux, 2011). V osmdesátých letech většina výrobních firem začala přesouvat do IS předpovědi prodeje, přijímané objednávky, správu a distribuci produktů. Na základě poskyto-

3.3

Druhy informačních systémů

17

vaných informací z IS měli řídicí pracovníci lepší možnosti rozhodování. Koncem osmdesátých let se objevil první komerční EIS (Executive Information System), založen na multidimenzionálním zpracování a uložení dat. V devadesátých letech se objevil první produkt i na českém trhu. Po vynálezu World Wide Web a protokolu HTML informační systémy rozšířily podnikání a průmysl na globální trhy. Nejdříve byli součástí interní části podniku s využitím intranetu a později i internetu. Tento krok dal podnikům schopnost komunikovat v rámci celé své organizace. Kdykoliv a kdekoliv na světě mohly efektivně předávat pokyny a informace. (Foresman, 1998)

3.3

Druhy informačních systémů

Existuje velké množství parametrů, podle kterých se dají IS rozdělovat. Každý autor používá různá měřítka a rozdělení. Naštěstí existují některé všeobecně ustálené rozdělení. Podle (Pospíchal, 2003) existují následující druhy IS. • Transakční systémy (TPS) – Snaží se mechanizovat stále se opakující firemní úkony, jako jsou mzdy, fakturace apod. Jsou nástupníky klasických dávkových systémů, které se používali dříve. Tuto změnu zapříčinilo využití on-line systémů. • IS pro řízení (MIS) – Také využívány v účetních a ekonomických odděleních. Typické jsou detailní přehledy o fungování některých dílen, provozů, závodů i celých podniků. Zpravidla produkují velké množství tištěných výstupů. • Systémy pro podporu rozhodování (DDS) – Jsou výsledkem MIS. Tyto systémy se využívají na analýzu dat bez potřeby složitějšího programování. Slouží pro vyšší managment. Výstupy jsou často neurčité a vyjasňují se až v průběhu řešení úlohy. • Útvarové systémy (DS) – Využívají principů TPS a DSS. Jejich rozsah však nemá tvořit obecné výsledky, ale snaží se specifikovat určitý útvar nebo místo. Např. laboratorní systém v nemocnici. • Strategické informační systémy (SIS) – Jsou přímo spjaty s výrobou nebo výrobkem. Slouží jako prostředek pro modelování analytických a rozhodovacích procesů. Snaží se o zvýšení konkurenceschopnosti podniku. • Expertní systémy (ES) – IS, který pomáhá ne příliš zkušenému pracovníkovi, řešit úlohy diagnostického charakteru. Jeho posláním je poskytnout znalosti, které má například jen jeden člověk, ostatním pracovníkům. • IS pro vrcholové řízení (EIS) – Soubor manažerských aplikací IS/IT určené pro vrcholovou a střední úroveň řízení podniku. Slouží pro podporu řízení. Zajímají se i o okolí podniku (trh, banka). • Metainformační systémy (METIS) – Říká se jim také podnikovou encyklopedií, protože sledují veškeré IS v podniku jejich prvky a aktuálnost.

18

3.4

3

LITERÁRNÍ PŘEHLED

Životní cyklus IS

Podle (Sodomka, Klčová, 2010) můžeme životní cyklus podnikového informačního systému rozdělit do následujících šesti etap: • Provedení analytických prací a volba rozhodnutí – Analytická činnost by měla vycházet z podnikové a informační strategie firmy. Manažer by měl odpovědět na základní otázku, jestli potřebuje nový informační systém. Při této etapě vývoje by měly být definovány požadavky na systém a charakteristiky cílů a přínosů systému. Zároveň by měl být proveden rozbor dopadů tohoto rozhodnutí na danou úroveň podnikání i celou organizaci. • Výběr systému a implementačního partnera – V této etapě se specifikují hardwarové a softwarové požadavky na systém. Dále se popisuje infrastruktura a potřebné služby, které odpovídají nárokům organizace. Při výběru implementačního partnera se hodnotí úroveň funkcionality, cena, kvalita a servisní služby. V praxi hrají velkou roli i preference a kontakty. • Projektová studie nebo-li návrh – Výsledný dokument této části slouží jako podklad pro obsah smlouvy s dodavatelem systému o návrhu a realizaci IS. Obsahuje časový harmonogram, cenu produktu, datový model, fyzický model, servis a podmínky celkového předání IS. Tato část je výsledkem analýzy systému. Řeší i problém konkrétní implementace systému a podmínky zavádění v organizaci. • Implementace – V této etapě se provádí samotná tvorba informačního systému. Výsledný produkt je samozřejmě přizpůsobován specifickým potřebám zákazníka. Pokud je produkt vedením firmy přijatý, provádí se školení uživatelů. Samotné školení pak zasahuje i do dalších etap vývoje IS. • Užívání a údržba – Funkčnost informačního systému je směrodatná pro jeho úspěšné používání. Správa a údržba je zcela zásadní pro dosažení plné funkčnosti IS. Tato etapa zahrnuje ostrý provoz, který umožní využít očekávaných přínosů. • Rozvoj a inovace – Tato etapa může nastat brzy po implementaci jádra systému, ale zároveň pokud systém vyhovuje potřebám firmy, tak muže nastat až po letech užívání. Inovace mohou nastat také proto, že původní informační systém nedokáže zajistit potřebnou kvalitu. V rámci této etapy jsou integrovány do podnikového systému další aplikace. Cílem je detailněji pokrýt klíčové procesy za účelem zisku vyšších přínosů.

3.5

Ukazatele přínosů informačního systému

Hodnocení přínosu IS je poměrné náročný proces, protože přínosy z něj se v organizaci projevují nepřímo. Zatímco náklady na systém jsou viditelné, tak ukazatele přínosu z těchto výdajů je těžké kvantifikovat. Podle (Thorp, 1998) se zatím ne-

3.6

Existující řešení

19

podařilo vymyslet žádný univerzální a konzistentní vztah mezi náklady a ukazateli úspěšnosti IS. Je to dáno hlavně tím, že přínosy se projevují až po delší době, a je těžké je přisuzovat pouze zavedení informačního systému. Podle (Edwards, Ward, Bytheway, 1995) můžeme ukazatele přínosů rozdělit do několika hledisek: • kvantitativní/kvalitativní • finanční/nefinanční • přímé/nepřímé • krátkodobé/dlouhodobé • absolutní/relativní

Obrázek 2: Model užitku (Molnár, 2000)

3.6

Existující řešení

Existuje velká spousta informačních systému. Ve velké většině si jsou dost podobné. V této podkapitole budou popsány tuzemské i zahraniční IS které se nejvíce přibližují požadavků společnosti Decsotre. • Altus Vario – je kompletní podnikový software kategorie all-in-one ERP sys” tém“. Vede ekonomickou agendu, obchodní a výrobní aktivity. Limitem je počet uživatelů, který by měl být asi do sta současně pracujících. Počet obchodních případů je limitován zhruba 100 000 měsíčně. (Altus Vario, 2014)

20

3

LITERÁRNÍ PŘEHLED

• ABRA – je řešením pro podporu řízení firmy a evidenci podnikových procesů pokrývajících oblasti obchodu, ekonomických a účetních agend a manažerské řízení a plánování. Systém ABRA je podle výrobce vhodný pro velké firmy, podnikatele, živnostníky, neziskové organizace i státní správu. Obsahuje osmdesát modulů a dalších funkčních doplňků. Deklaruje dostupnost na PC, tabletu i mobilu. (Abra, 2013) • SIGNYS – obsahuje řešení pro obchod a sklad, finance a účetnictví, výrobu a TPV, internetový obchod, řízení firmy, personalistiku a mzdy. Podle výrobce zaručuje efektivitu, přizpůsobitelnost bezpečnost a spolehlivost informačního systému. (Signys, 2014) • Directis – uvádí, že je moderní a cenově dostupný software pro řízení dokumentů, firemních agend a procesů určený pro nejmenší, malé a střední firmy. Deklaruje přístupnost přes webové rozhraní, řízení oprávnění, skupiny active directory, verzování, používání metadat (kódování, kategorie, odpovědnosti) a fulltextové vyhledávání. (Directis Acmark, 2015) • SAP Business One – přináší podle výrobce přehled a kontrolu nad financemi i celým podnikem, zamezuje ztrátám a přispívá k vyšší ziskovosti. Snižuje náklady, omezuje chybovost, zrychluje a zefektivňuje činnosti i celé procesy. Obsahuje aktuální informace pro rozhodování. SAP Business One má moduly pro firmy ze všech oborů podnikání. Přináší řešení na míru potřebám jednotlivých firem. (SAP Business One, 2013) • Money S3 – je informační systém pro menší a střední společnosti. Výrobce udává, že Money S3 by mělo být nasazeno během několik dní. Typickým uživatelem tohoto systému je společnost, která používá až 10 PC a ročně pracuje do 100 000 dokladů. Cena podnikového informačního systému Money S3 se pohybuje v průměru od 10 000 do 50 000 Kč. Pro vytíženější firmy slouží systém Money S4. (Money S3, 2015) V následující kapitole byl vybrán informační systém K2, který nejvíce odpovídá požadavkům společnosti Decstore a s tímto systémem bude detailněji porovnáno řešení, které je obsahem této diplomové práce.

4

4

POROVNÁNÍ S INFORMAČNÍM SYSTÉMEM K2

21

Porovnání s informačním systémem K2

Existuje spousta společností, které se nějakým způsobem zabývají problematikou informačních systémů. Některé společnosti se specializují na velké podniky a některé nabízí svoje služby středním a menším podnikatelům. Zároveň je důležité si kontrolovat to, jak velká je působnost na českém trhu. Některé společnosti sice nabízí služby v češtině, ale podle recenzí a hodnocení se pak můžeme dozvědět, že u nás může být špatná podpora ze strany této společnosti. Trh je plný nabídek od velkých hráčů jako je SAP, Oracle, Helios nebo menších firem jako je Abra a Money. Já jsem se pro porovnání s informačním a rezervačním systémem Decstore snažil najít co nejpodobnější produkt, aby bylo porovnání relevantní. Zvolil jsem si tuzemskou společnost K2 a jejich řešení informačního systému. K2 jsem zvolil proto, že mají v nabídce také možnost propojit informační systém s jejich e-shopem. Tento e-shop může v podstatě reprezentovat náš rezervační systém produktů. Společnost K2 atmitec s.r.o. sama o sobě říká, že se řadí mezi přední výrobce informačních systémů. Jejich filozofií by mělo být to, že se snaží přinášet potenciálnímu zákazníkovi kompletní ICT řešení. Nabízí spoustu služeb od projektových činností, přes softwarová a hardwarová řešení, po cloudové služby. K2 atmitec vznikla v roce 1991 jako společnost s ryze českým kapitálem. Na stránkách firmy se můžeme dočíst, že K2 je jednou z velehor pohoří Himaláje a je symbolem pro nadčasovost, stabilitu a vytrvalost. Právě tyto charakteristiky by měly být příznačné pro informační systém K2. Atmitec je složeninou slov átmika a technologies, což vyjadřuje technologii, která vychází z vnitřní podstaty každé firmy. Jejich hlavními činnostmi jsou zejména vývoj, implementace a servis informačního systému K2 a provoz vlastního datového centra K2. Podle výroční zprávy činil zisk této firmy během let 2003–2013 1 575 722 Kč. Průměrně tedy necelých 160 000 Kč za rok. Po porovnání systému Decstore a K2 poslouží tři základní roviny. První rovinou jsou subjektivní parametry. K2 píše, že hlavní výhody jejich řešení je zpřehlednění činnosti firmy, relevantní podklady pro rozhodování, zvýšení produktivity práce, snížení nákladů a podobně. Obecně se dá říct, že tyto benefity má každý alespoň trošku funkční informační systém. Otázka je, do jaké míry dokáže zpřehledňovat činnost firmy nebo zvyšovat produktivitu práce. Podle mého názoru taková firma nemá tolik času se věnovat jednomu zákazníkovi, aby dokázala ušít systém přesně na míru. Zvlášť pokud zákazník nemá profesionální znalosti o fungování těchto systémů a tak nedokáže přesně zformulovat svoje požadavky a dochází poté k četným úpravám. Podle mého názoru je v těchto parametrech systém Decstore lepší, protože je vytvořen přesně podle striktních požadavků a podle zaběhlých firemních procesů tak, aby práci usnadňoval a efektivitu zvyšoval co nejvíce. Informační systém K2 přináší velkou spoustu modulů specializovaných na marketing, prodej, nákup, sklad, dopravu, celnice, výroba, finance a podobně. Samozřejmě většinu z nich společnost Decstore vůbec nepotřebuje. Je otázka do jaké míry je možné tyto moduly kombinovat protože na stránkách ani v informacích o tom není ani zmínka. U konkurenčních produktů totiž bylo většinou nutné zakoupit různé balíčky, které obsahovali tři, pět

22

4 POROVNÁNÍ S INFORMAČNÍM SYSTÉMEM K2

nebo deset těchto modulů. Tím se snižuje variabilita použití. Pro firmu je zbytečné mít o jeden modul navíc, který nevyužije, popřípadě aby jí jeden chyběl, jen proto, že balíčkové řešení je finančně výhodnější. Druhá rovinou porovnávání je schopnost propojení informačního systému s obchodem v reálném čase. K2 atmitec deklaruje, že jakákoliv změna se ihned projeví na obou místech zároveň a není nutné čekat na často chybové exportní a importní soubory. V této rovině se chová K2 stejně jako systém Decstore. Příkladem může být vytvoření nové objednávky v rezervačním systému. Jakmile návštěvník vloží zboží do košíku, začíná systém tento potencionální nákup evidovat. V případě, že je nákupní proces dokončen, úspěšně vzniká objednávka. Toto deklaruje K2 systém. Systém Decstore navíc k zakázce přiřadí i vhodného zaměstnance a zároveň ho o vzniklé zakázce informuje pomocí e-mailu. Třetí rovinou, podle které je nutné systémy porovnat, je cena. Ta bývá většinou primárním atributem výběru. Zvlášť u menších a středních firem by vyšší náklady mohly způsobit nemalé komplikace. Málokterá firma si ale dokáže přesně převést přínos informačního systému do finančních ukazatelů. Společnost K2 atmitec na svých stánkách neuvádí žádné pořizovací náklady na jejich řešení informačního systému. Ze zveřejněné výroční zprávy si ale lze udělat dostatečný obrázek. V ní se můžeme dočíst, že průměrná smluvní cena prodané licence byla v roce 2013 175 149 Kč. Pokud budeme uvažovat, že požadavky společnosti Decstore nebudou nijak náročné, ba dokonce dost podprůměrné, můžeme se dostat řekněme na 100 000 Kč za licenci. Z výroční zprávy dále zjistíme, že 54% zisků je za informační systém K2 a zbytek je za hardware a ostatní. To znamená, že pořizovací náklady podprůměrné licence systému K2 je 54 000 Kč. Což je poměrně velký zásah do prvotního kapitálu nově založené společnosti s ručením omezeným. Pokud vezmeme v potaz možný růst firmy, a tím pádem i nutnost rozšiřování informačního systému, rázem se dostáváme za hranici 100 000 Kč za licenci.

5

NÁVRH SYSTÉMU

5

23

Návrh systému

Návrh je nedílnou součástí vývoje informačního systému. Podle (Rábová, 2008) je nalezení nedokonalosti ve fázi návrhu několikrát výhodnější jak po časové stránce, tak po stránce finanční, než stejné zjištění v kterékoliv další fázi. Návrh nám zároveň pomáhá vytvořit si ucelenou představu o funkcionalitě systému. Návrh by se měl skládat minimálně z funkčního a datového modelu.

5.1

Funkční model

Účelem funkčního model je prezentace způsobu zpracování dat. Někdy se také označuje jako DFD2 . Hlavní výhodou funkčního modelu je možnost dekompozice. Umožňuje systematicky rozkládat složitější problém na větší množství jednodušších problémů. Při dekompozici procesů vznikají subprocesy a dekompozicí datových toků subtoky. Podle (Rábová, 2008) obsahuje funkční model čtyři základní prvky. • Procesy – jejich hlavním úkolem je transformace vstupních dat na data výstupní. • Terminátory – jedná se většinou o osoby nebo jiné entity, ovlivňující modelovaný systém z venku. • Datové toky – jsou naznačovány v podobě šipek a vymezují prvky mezi kterými a jakým směrem daná data tečou. • Datová skladiště – jsou struktury, které umožňují data ukládat a číst. Datové sklady ve fyzickém modelu odpovídají entitám v datovém modelu. Zároveň platí, že každé datové skladiště musí mít alespoň jeden datový tok pro zápis a jeden tok pro použití nebo výpis dat. Tvorba DFD diagramu začíná návrhem kontextového diagramu. Kontextový diagram vymezuje rozsah systému a zároveň je základním prvkem pro další budoucí dekompozici. Je složen jen z jednoho základního procesu, který reprezentuje systém jako celek. Na druhou stranu ale obsahuje všechny terminátory, které na systém z venku mohou působit. Vztahy mezi terminátory se v tomto diagramu nevyjadřují. V případě, že tyto vazby existují, nejsou součástí DFD. Jediný způsob, jak propojit terminátory je takový, že datové toky vedou přes procesy. To stejné platí i pro datastory, které se ale vyskytují až v dalších diagramech. Vazby mezi procesem a terminátory jsou reprezentovány pomocí datových toků. Jak můžeme vidět na obrázku číslo 3 hlavní proces v kontextovém diagramu se jmenuje Is Decstore. Dekompozicí tohoto hlavního procesu získáváme systémový diagram. Z hlavního procesu bylo vytvořeno pět subprocesů. Na obrázku číslo 4 můžeme vidět, že se jedná o procesy zákazníci, zakázky, zboží, účetnictví a zaměstnanci. Všechny tyto procesy je nutné ještě dále dekomponovat. Z kontextového diagramu jsou převedeny 2

DFD – Data Flow Diagram (Diagram datových toků)

24

5 NÁVRH SYSTÉMU

Obrázek 3: Kontextový diagram informačního systému Decstore.

všechny terminátory a všechny datové toky do systémového diagramu a jsou zde využívany. Systémový diagram je nejkomplexnější diagram a poslední diagram, který ukazuje systém jako celek se všemi jeho subsystémy při jejich vzájemné interakci. Procesy nejsou v systému nikdy o samotě, vždy spolu navzájem spolupracují a komunikují minimálně přes jeden datový tok. Datové toky sebou nesou data potřebná pro vzájemnou komunikaci V systémovém diagramu můžeme dále dekomponovat všech pět procesů. Díky tomu dostáváme detailnější pohled na to, jak tyto procesy fungují a jaké funkce nabízí. Jako ideální ukázka poslouží dekompozice procesu zaměstnanci. Tento diagram se nazývá DFD zaměstnanci a jeho podrobnosti jsou k vidění na obrázku číslo 5. Původní proces zaměstnanci se nám rozpadl na dva subprocesy. • Evidence nových zaměstnanců – Pokud chce nový zaměstnanec požádat o místo, tak musí nejdříve poslat svoje osobní údaje. To platí v obou případech, ať už se jedná o zaměstnance nebo o brigádníka. Osobní údaje samotné nestačí. Tomuto zaměstnanci musí dát potvrzení vedoucí, ještě před tím než se dostane do evidence nových zaměstnanců. Pokud je potvrzení kladné, nový zaměstnanec/brigádník dostane svoje přístupové údaje do systému.

5.1

Funkční model

25

Obrázek 4: Systémový diagram informačního systému Decstore.

• Evidence stávajících zaměstnanců – Proces evidence stávajících zaměstnanců získá osobní údaje zaměstnanců/brigádníků z procesu evidence nových zaměstnanců. Každý nový zaměstnanec/brigádník je nejdříve uložen do datového skladiště určeného pro zaměstnance. Z tohoto skladiště potom přes proces evidence stávajícich zaměstnanců čerpají data i ostatní procesy v systému. V našem případě čerpá informace z tohoto datového skladiště proces účetnictví a proces zakázky. Účetnictví potřebuje osobní informace například při výplatách. Proces zakázky potřebuje zaměstnance pro přidělení do jednotlivých částí zakázek. Procesy v DFD zaměstnanci už není třeba dále dekomponovat. Oba dva procesy jsou dostatečně pochopitelné. V tomto případě musí být označeny parametrem lowest level (nejnižší úroveň). Znamená to, že tyto procesy se stávají listy ve stromové sturktuře a je umožněno konkrétně specifikovat jednotlivé datové toky. K tomuto účelu slouží minispecifikace. Minispecifikace k procesu evidence nových zaměstnanců je znázorněna na obrázku číslo 6. Proces pracuje v cyklu následovně: 1. Pokud jsou vyplněny informace od zaměstnance nebo brigádníka, tak přečti potvrzení od vedoucího. Pokud nejsou, ukonči proces. 2. Pokud je potvrzení negativní, tak se vrať na začátek.

26

5 NÁVRH SYSTÉMU

Obrázek 5: DFD zaměstnanci pro informační systém Decstore.

3. Pokud je potvrzení pozitivní a pokud se jedná o informace od zaměstnance, tak tyto údaje přečti, vytvoř data pro datový tok přijetí zaměstnance a data odešli. Dále vytvoř přístupové údaje pro nového zaměstnance a pošli mu je. 4. Pokud je potvrzení pozitivní a pokud se jedná o informace od brigádníka, tak tyto údaje přečti, vytvoř data pro datový tok přijetí zaměstnance a data odešli. Dále vytvoř přístupové údaje pro nového brigádníka a pošli mu je. 5. Vrať se zpátky ke kroku 1. Pro vytvoření všech částí data flow diagramu byl použit CASE nastroj Power designer Proces analyst. Pro tvorbu minispecifikace byl použit pseudokód3 . 3

Pseudokód je neformální způsob zápisu počítačového algoritmu, který používá strukturní konvence programovacích jazyků, ale nezahrnuje detailní syntaxi, která je specifická pro konkrétní programovací jazyky.

5.2

Datový model

27

Obrázek 6: Minispecifikace procesu evidence nových zaměstnanců.

5.2

Datový model

Datový model se nazývá ERD4 a slouží jako formální nákres datové struktury systému. Je využíván pro návrh fyzické struktury databáze, protože vyjadřuje vztahy mezi daty. ERD neobsahuje informace o funkcích, protože prezentuje pouze statickou část systému. Základními prvky ERD jsou entity a relace mezi nimi. Každá entita je popsána v návrhu a obsahuje vlastní atributy. Atribut má určený název, povinnost a příslušný datový typ. Relace jsou také povinné nebo nepovinné a dále se u nich určuje kardinalita. Existují tři typy kardinality, nebo-li násobností 1:1, 1:N nebo N:1 a M:N. Entity v ERD odpovídají datastorům v DFD. (Rábová, 2008) Pro tvorbu ERD byl použit nástroj Microsoft Visio 2010. V diagramu jsou z důvodu vetší přehlednosti vypsány pouze primární a cizí klíče. Zbylý obsah entit je vypsán zvlášť. Entity navrhovaného systému • t_adresa_zakaznik – id_adresa_zakaznik, ulice, cp, co, mesto, psc, zeme, typ_adresy, id_zakaznik • t_adresa_zamestnanci – id_adresa_zamestnanci, ulice, cp, co, mesto, psc, zeme, typ_adresy, id_zamestnanci 4

ERD – entity-relationship diagram (Diagram entit a jejich vztahů)

28

5 NÁVRH SYSTÉMU

Obrázek 7: ERD informačního systému Decstore.

• t_casti_zakazek – id_casti_zakazky, id_zakazky, nazev, cena_bez_dph, cena_s_dph, stav, specifikace, deadline, datum_zadani, datum_dokonceni, datum_vlozeni, vlozil, posledni_aktualizace, aktualizoval • t_historie_produkt – id_historie_produkt, zakazka, zakaznik • t_kategorie – id_kategorie,nazev • t_kategorie_podkategorie – id_podkategorie, id_kategorie • t_nakupni_kos – id_zakazka, id_produkt, cena, pocet_kusu, zpusob_doruceni, zpusob_platby • t_parametr – id_parametr, hodnota, id_parametr_name • t_parametr_name – id_parametr_name, name

5.2

Datový model

29

• t_podkategorie – id_podkategorie, nazev • t_produkt – id_produkt, nazev, fotka, specifikace, id_podkategorie, id_stav_produkt, vlozil, datum_vlozeni, aktualizoval, posledni_aktualizace • t_produkt_historie_cena – id_produkt_historie_cena, puvodni_cena, aktualni, datum_aktualizace, aktualizoval • t_produkt_parametr – id_produkt,id_parametr • t_stav_produkt – id_stav_produkt, nazev • t_vykony – id_vykonu, id_casti_zakazky, id_zamestnanci, id_zamestnanci_vedouci, nazev, zadani, stav, odmena, deadline, datum_zadani, datum_dokonceni, notifikace_dokonceni, datum_vlozeni, vlozil, posledni_aktualizace, aktualizoval • t_zakazky – id_zakazky, nazev, specifikace, datum_naberu, datum_predani, datum_vlozeni, vlozil, posledni_aktualizace, aktualizoval, id_zakaznik • t_zakaznik – id_zakaznik, nazev, cislo_uctu, kod_banky, ic, dic, web, telefon, email, datum_vlozeni, vlozil, posledni_aktualizace, aktualizoval • t_zamestnanci – id_zamestnanci, typ, jmeno, prijmeni, titul_pred, titul_za, datum_narozeni, email, telefon, web, cislo_uctu, kod_banky, postaveni, login, password, ban, datum_vlozeni, vlozil, posledni_aktualizace, aktualizoval

30

6

6 PROGRAMOVÉ PROSTŘEDKY POUŽITÉ PŘI IMPLEMENTACI

Programové prostředky použité při implementaci

Jak vyplynulo z požadavků společnosti Decstore s.r.o., chtějí svoje produkty nabízet prostřednictvím internetu. To znamená, že rezervační systém musí být implementován jako webová aplikace, aby zprostředkovávala zákazníkovy aktuální nabídku produktů. U informačního systému požadavky tak striktní nebyly. V tomto případě stálo minimálně za to, uvažovat nad tím, jaké výhody přináší webová aplikace, a jestli by nebylo lepší zvolit aplikaci desktopovou. Nakonec jsme se i po konzultaci s vedením firmy rozhodli pro aplikaci webovou, protože desktopová aplikace by stejně musela v reálném čase komunikovat se serverem a databází v případě nahrávání nebo úpravy produktů. Navíc díky tomu lze zvolit stejné prostředky pro implementaci a celý projekt získá jednotnější formu. Programové prostředky, které byly použity pro implementaci, jsou popsány v následující kapitole.

6.1

PHP

PHP je strukturovaný programovací jazyk, jehož počátky spadají až do roku 1994. Lze ho použít k tvorbě konzolových a desktopových aplikací, ale více se hodí na vytváření dynamických webových stránek. PHP je proto velice vhodný pro psaní intranetových a internetových informačních systémů. PHP podporuje mnoho knihoven ke zpracování textu, grafiky, práci se soubory a pro náš případ nejdůležitější knihovny ke komunikaci s databázovými systémy. Kód PHP aplikace se vkládá přímo do HTML kódu a je zřetelně oddělený uvozovkami. PHP interpreter vyhodnocuje části kódu napsané v PHP jazyce a nahradí ho výstupem z interpreteru. Tahle vlastnost slouží k ochraně algoritmů programátora. Umožňuje skrytí při zobrazení zdrojového kódu aplikace webovým prohlížečem na serveru popřípadě localhostu. (Kofler, Öggl, 2007) V současné době je nejpoužívanější verze PHP 5 obsahující například vylepšenou podporu XML a nové objektové rozhraní pro práci s databázemi. Poskytovatel hostingu společnosti Decstore nabízí PHP od verze 5.3 po verzi 5.6, ale defaultně podporuje verzi 5.5. Kód PHP je proto implementován tak, aby byl interpretován verzí 5.5 a kód byl plně funkční.

6.2

HTML

Název HTML je zkratkou od názvu HyperText Markup Language a je česky označován jako hypertextový značkovací jazyk. Slovo HyperText označuje schopnost vzájemně propojovat texty na základě odkazů, Markup vyjadřuje možnost jazyka HTML přiřazovat význam jednotlivým blokům textu za pomoci HTML tagů (např. vypsat část textu jako nadpis nebo třeba určit textu tučnost písma). Jazyk HTML

6.3

Kaskádové styly

31

patří do široké rodiny značkovacích jazyků SGML5 . Vznikl v roce 1990 ve Švýcarsku a postupně se vyvíjel v závislosti na nejpoužívanějších prohlížečích až k současné verzi HTML 5. Při tom byl vývoj od verze 4 na patnáct let zastaven, neboť existovaly názory, že modernějším přístupem bude použití XHTML. XHTML zkratka z anglického extensible hypertext markup language, nebo-li rozšiřitelný hypertextový značkovací jazyk. XHTML je aplikací jazyka XML, z čehož plynou některé odlišnosti, například nutnost deklarace kódování, přísnější pravidla pro zápis elementů (např. musí být uzavřené) a atributů (malými písmeny, v uvozovkách). Vývoj XHTML byl ale také ukončen. (Adaptic, 2007) Od 7. března 2007 byla založena nová pracovní skupina, jejímž cílem byl vývoj nové verze HTML a dnes již je HTML 5 plně funkční. Existují argumenty proč uvažovat nad XHTML, ale výhody HTML 5 tyto úvahy převažují. HTML5 obsahuje nové značky definující strukturu stránky, plně podporují práci s relačními databázemi, je kladen důraz na zkrácený a rychlá zápis značek, obsahují vetší množství formulářových prvků včetně jejich kontroly. Proto byla pro tvorbu tohoto projektu zvolena verze HTML 5.

6.3

Kaskádové styly

Kaskádové styly, se nejčastěji uvadí pod zkratkou CSS (z anglického Cascading Style Sheets). Tento jazyk slouží k efektivnímu formátování stránek psaných v jazycích HTML a XHTML. Slovo kaskádové značí jejich nejdůležitější vlastnost – jednotlivá pravidla CSS stylů se dokáží navzájem překrývat. Díky tomu získávají kaskádové styly vyšší efektivitu, jsou-li správně používány. Jejich další výhodou je to, že umožňují celkové oddělení designu stránky od jeho obsahu. Toto oddělení prezentační vrstvy od vrstvy strukturální zvyšuje přístupnost webové stránky a právě v tom je i největší rozdíl proti formátování stránek za pomocí atributů, který se používal před vynálezem kaskádových stylů. Další výhody kaskádových stylů: • větší možnosti formátování • snazší správa větších prezentací (CSS šablony) • rychlejší načítání stránky • menší zatížení serveru • společně s JavaScriptem lze s CSS vytvářet dynamické HTML (Adaptic, 2007) Zatím byly vydány 3 verze specifikace CSS 1, CSS 2 CSS 3. První dvě verze jsou již zastaralé, protože společně s HTML 5 vyšla nová verze CSS 3. Většina vlastností verze 3 jsou ze strany prohlížečů podporovány, avšak plné využití se uplatňuje až s využitím HTML 5. Pro tvorbu tohoto projektu jsou používány prvky CSS 3. 5

SGML (Standard Generalized Markup Language) je univerzální značkovací metajazyk, který umožňuje definovat značkovací jazyky jako své vlastní podmnožiny. SGML je komplexní jazyk poskytující mnoho značkovacích syntaxí.

32

6 PROGRAMOVÉ PROSTŘEDKY POUŽITÉ PŘI IMPLEMENTACI

6.4

JavaScript

JavaScript je objektově orientovaný programovací jazyk, který je interpretovaný ve webovém prohlížeči. Jeho syntaxe patří do rodiny jazyků C/C++/Java. Nejvíce se používá jako skriptovací jazyk na straně klienta, ale dá se použít i na straně serveru. Slovo Java v názvu JavaScript je pouze marketingový tah, protože jazyk Java byl během tvorby JavaScriptu velice populární. Pokud JavaScript běží na straně klienta, slouží ke generování kódu samotné stránky. JavaScript se používá především pro vytváření interaktivních webových stránek. Používá se například ke kontrole správného vyplnění formulářů, pro hover efekt po přejetí myší, na rozbalovací menu a tak dále. Společně s jazykem HTML a CSS je JavaScript součástí DHTML6 . K tomu JavaScript využívá tzv. DOM7 , rozhraní umožňující přistupovat k jednotlivým prvkům stránky. JavaScript vyvinula společnost Netscape v roce 1995 a v roce 1998 byl standardizován organizací ISO. (Adaptic, 2007) Při tvorbě informačního a rezervačního systému společnosti Decstore, byl použit nativní JavaScript v aktuální verzi 1.8.5 pro tvorbu jednodušších funkcí jako je filtrovaní zboží nebo přepočet ceny. Pro složitější funkce, které pracují s elementy DOM, byla použita knihovna jQuery. Tato knihovna usnadňuje právě vyhledávání a práci s elementy DOM. V projektu bylo použito více verzí jQuery při čemž nejnovější byla verze 1.9.2. Pro speciální případy návrhu uživatelského rozhraní, například pro tvorbu funkce autocomplete (popsáno v kapitole – Popis rezervačního systému) byla použita knihovna jQuery UI.

6.5

AJAX

Zkratka AJAX pochází z anglického Asynchronous JavaScript and XML. Je to moderní technologie často využívaná v současných webových aplikacích. AJAX není sám o sobě implementací technologie, ale jedná se pouze o skupinu provázaných webových technik používaných na straně klienta. Pomáhají vytvářet asynchronní webové aplikace. Hlavní výhodou AJAXu je to, že aplikace může poslat nebo obdržet data ze serveru asynchroně bez obnovení dané stránky, na rozdíl od klasických odkazů. Navíc se nejedná o žádnou novou technologií, pouze o kombinaci už známých technologií, tj. HTML, JavaScriptu, XML a XMLHttpRequest8 . Právě XMLHttpRequestu umožnuje asynchronní volání serveru. Což umožňuje vyvolat libovolný 6

Souboru technik a postupů zaměřených na zlepšení uživatelského rozhraní a zvýšení prožitku z používání stránek. 7 Document Object Model (objektový model dokumentu) – je objektově orientovaná reprezentace XML nebo HTML dokumentu. DOM umožňuje přístup či modifikaci obsahu, struktury, nebo stylu dokumentu, či jeho částí. 8 Rozhraní umožňující webovým aplikacím komunikaci mezi serverem a klientem prostřednictvím protokolu HTTP. Umožňuje změnu části obsahu stránky bez nutnosti jejího opětovného kompletního načtení ze serveru. Jeho největší výhodou je dvoucestná konverzace mezi klientem a serverem. (Gourley, Totty, 2002)

6.6

SQL

33

počet nezávislých požadavků, jejichž výsledky mohou ovlivnit pouze patřičné části uživatelského rozhraní (Powell, 2008). Hodně se o AJAXu mluví, protože je součástí RIA9 , směru programování vedoucímu k vyššímu uživatelskému komfortu a funkčnosti aplikací. Díky tomu se AJAX hodí na formuláře, které se automaticky předem vyplňují podle stisknuté klávesy, AJAX ankety a další aplikace, které uživateli usnadňují práci. Na obrázku číslo 9 je vidět rozdíl mezi klasickým webovým aplikačním modelem a modelem využívajícím technologie AJAX. Důležité je ovšem správné použití a před nasazením i důkladné otestování na uživatelích. V opačném případě totiž AJAX snižuje významně efektivitu a použitelnost stránek. (Adaptic, 2007)

Obrázek 8: Klasický webový model v porovnání s technologií AJAX (Garrett, 2005)

6.6

SQL

Tento databázový jazyk vznikl pod hlavičkou firmy IBM. Původně byl označován jako SEQUEL. Prvotním cílem bylo vymyslet způsob dotazování se do databáze jazykem, který je podobný angličtině. Je to neprocedurální nástroj s množinovým přístupem k datům. SQL umožňuje manipulaci, správu a organizování dat uložených v databázi. Vytvořené interaktivní dotazy dokáží téměř okamžitě získat odpovědi i na velmi komplikované otázky. Komunikace probíhá s relačním databázovým serverem, který odpovídá výpisem výstupní množiny dat. Podle svého účelu se dělí do tří skupin: 9

Rich Internet Application (Bohatá internetová aplikace) – je webová aplikace, která má některé vlastnosti grafické desktopové aplikace. (Darie, 2012)

34

6 PROGRAMOVÉ PROSTŘEDKY POUŽITÉ PŘI IMPLEMENTACI

• DDL (Data definition language) – Slouží pro vytváření, změny, rušení a definování tabulek, procedur, triggerů, indexů atd. – CREATE, ALTER, DROP • DML (Data manipulation language) – Slouží k získávání, aktualizaci, vkládání a mazání dat v databázi. – SELECT, UPDATE, INSERT, MERGE, DELETE • DCL (Data control language) – Slouží k řízení, údržbě a provozu databáze. – START TRANSACTION, COMMIT, ROLLBACK (Lacko, 2002) Pro potřeby společnosti Decstore byl použit relační databázový systém MySQL vlastněný firmou Oracle. Jedná se o multiplatformní databázový systém komunikující pomocí jazyka SQL. MySQL se využívá jako univerzální řešení ve velké většině databázových projektů a je dostupný ve většíně webhostingů, protože je volně šiřitelné. Samozřejmě toto řešení není tak propracované jako některá placená implementace, nepodporuje složitější programátorské konstrukce a nemá dostatečný výkon v opravdu náročných webových aplikacích. Tehdy se používají konkurenční databáze, například PostgreSQL. V našem případě ovšem MySQL vyhovuje dostatečně. Obzvlášť když některé konstrukce, které MySQL nezná, lze obcházet skriptováním. (Adaptic, 2007)

Obrázek 9: Ukázka SQL dotazu na databázi Decstore pro výpis názvu zboží a ceny zboží, u kterých je cena vetší než 200 Kč. Seřazeno od nejdražšího.

7

7

POPIS INFORMAČNÍHO SYSTÉMU

35

Popis informačního systému

Tvorba informačního systému pro společnost Decstore byla ovlivněna spoustou specifických požadavků. Je to i hlavní důvod, proč se firma nerozhodla si pořídit předvytvořený univerzální systém pro správu firemních zdrojů. Tyto specifické požadavky, ať už se jedná o návrhové, designové nebo implementační, nemohla společnost získat obecným řešením nějaké firmy. Prvním požadavkem pro tvorbu informačního systému byla nízká pořizovací cena, čehož by bylo poměrně obtížné docílit při koupi licencovaného produktu. Druhým požadavkem bylo společné propojení informačního a rezervačního systému. Dosáhnout kompatibility mezi těmito systémy by také nebylo zrovna jednoduché, pokud nejsou obě části vytvořeny společně a nepracují pod stejnou databází. Třetí důležitým požadavkem bylo používání obou systému ve webovém prohlížeči. Internet dává uživatelům velké možnosti a pohodlí při používání. Není třeba žádná instalace, ale hlavně je možné v systému pracovat odkudkoliv, kde je přístup na internet. Další výhodou osobní spolupráce je to, že výsledný systém je vytvořen přesně na klíč pro danou firmu. Obsahuje a zohledňuje specifické požadavky a potřeby dané firmy. Nesnaží se tvořit obecná řešení, ale soustředí se na efektivní fungování a řešení konkrétních problémů v daných situacích. Informační systém zohledňuje pracovní procesy a fungování firmy a je navržen tak, aby byl ve všech směrech nápomocný ke zvyšování efektivity práce. Důraz byl kladen na uživatelskou přívětivost, snadné ovládání, přehledné rozmístění funkčních prvků za stálého zachování maximální funkčnosti a jednoznačnosti při používání. Mezi další požadavky patří samozřejmě minimální chybovost na straně klienta a stálá funkčnost na straně serveru, tedy trvalá dostupnost na internetu. V dnešní době se používání informačního systému neobejde bez spousty bezpečnostních prvků. Požadavkem byla nutnost přihlašování se do systému, ale i po přihlášení je na bezpečnost kladen velký důraz. Žádná firma dobrovolně nevypouští citlivé firemní údaje nebo dokonce přihlašovací údaje svých zaměstnanců. Použité bezpečnostní prvky jsou popsány níže v sekci bezpečnost. Požadavky ohledně jazykových mutací, nebyly nijak zvlášť specifikovány. Jelikož se jedná o českou firmu působící na českém trhu, tak byl explicitně zvolen jako primární jazyk čeština. Stejně tak byl řešen problém s použitou měnou. Informační systém všechny finanční údaje zobrazuje v korunách českých (Kč/CZK). Na informační část systému nebyly kladeny tak velké nároky co se týče designu a grafiky, na rozdíl od té rezervační. Přece jen se jedná o interní systém a hlavním požadavkem je funkčnost, přesto jsou použity firemní barvy doplněné o firemní motivy a logo. Nicméně i tak byl vzhled, ale především funkčnost, často upravován v průběhu tvorby řešení. První návrhy ne vždy dokonale řešily komplexnost problému, a proto musely být často konzultovány a docházelo tak k úpravám.

36

7.1

7

POPIS INFORMAČNÍHO SYSTÉMU

Obecná funkcionalita

Ve zbytku kapitoly budou popsány jednotlivé vlastnosti a funkcionalita informačního systému. Ještě před tím než budou popsány jednotlivé sekce a jejich specifické vlastnosti, bude pár odstavců věnováno společným funkcím pro celý informační systém. Všechny sekce obsahují explicitně několik společných funkcí: • Vyhledávání – Slouží k tématickému vyhledávání v jednotlivých sekcích. Vyhledávač hledá shodu v těch parametrech položek, které jsou vypsány v hlavičce seznamu položek. Jak jde vidět na obrázku číslo 10, tak v sekci zboží je možné vyhledávat podle názvu zboží, názvu podkategorie zboží a stavu zboží. • Řazení – Řazení seznamu položek pomocí uživatelem zvoleného parametru je nedílnou součástí uživatelsky přívětivé aplikace. V každém seznamu položek je možné řadit vždy podle hlavičky seznamu. Jak jde vidět opět na obrázku číslo 10, tak šipka u sloupce název značí, že je seznam řazen podle názvu zboží. Pokud klikneme na sloupec podkategorie, tak bude seřazen podle názvu podkategorie.

Obrázek 10: Ukázka hlavičky pro vyhledávání v sekcích.

• Stránkování – Slouží k nastavení počtu položek v seznamu na jednu stránku. Počet položek na stránce je možné měnit na intervalu od jedné do tisíce včetně. Stránkování zvyšuje uživatelskou přívětivost a možnosti procházení jednotlivými položkami. • Zobrazení detailu položky – U každé jednotlivé položky dané sekce lze zobrazit detailní pohled na položku. Každý zaměstnanec, zákazník, zakázka i produkt má svůj detail, ve kterém jsou popsány všechny informace o dané položce. • Přidávání/editace položek – Informační systém umožňuje ruční přidávání a editaci položek. Při této manipulaci s položkami je důležité, hlídat si vyplnění povinných vstupních polí. Jedná se o položky, které systém využívá pro svou práci, a proto musí být v každé situaci vyplněny. Tyto položky jsou vždycky označeny červenou hvězdičkou, aby uživatel systému věděl, že jsou důležité. Lidé často chybují při zadávání údajů, a proto si jejich vyplnění informační systém hlídá sám. To stejné platí v případě, že není dodržený potřebný formát vstup-

7.2

Přídavné moduly

37

ního pole. Jedná se například o formáty dat10 nebo e-mailů, které mají zvláštní požadavky na formát. Další problém může nastat, pokud není dodržena potřebná délka vstupu, například u hesla. V těchto případech, informační systém editovanou/přidávanou položku neuloží, ale zobrazí varovnou hlášku s popisem problému a dává uživateli možnost svou chybu opravit. Na obrázku číslo 11 je možné vidět příklad varovného hlášení při nedodržení správného formátu e-mailu.

Obrázek 11: Ukázka varovného hlášení při špatném vstupu.

• Mazání položek – Systematické mazání jednotlivých položek informačního systému není ve většině případů příliš žádoucí. S ohledem na budoucnost fungování firmy je dobré mít historické nebo právě nepotřebné položky systému stále uloženy v databázi. Pro tyto případy je možné měnit stav položek. Například u zboží je možné změnit stav na nedostupné. V některých případech se ovšem mazání nevyhneme. Existují tři způsoby, jak je možné položku smazat. První způsob je stisknout tlačítko pro smazání v detailu položky. Další možnost je smazání položky v přehledu dané sekce, kde má každá položka svoje volby a jednou z voleb je i smazání dané položky. Poslední třetí možností je hromadné mazání. Toto mazání se opět nachází v přehledu dané sekce. Stačí zaškrtnout checkbox u položek, které chceme smazat, a poté stisknout potvrzující tlačítko. Druhý a třetí případ můžeme vidět na obrázku číslo 10.

7.2

Přídavné moduly

Další částí společnou pro více sekcí jsou přídavné moduly nebo také pluginy. V zásadě nepracují samostatně, ale slouží k rozšíření funkčnosti a možností informačního systému. Všechny moduly jsou open-source11 software. Pluginy jsou kompatibilní mezi prohlížeči, které podporují JavaScript. Napříč sekcemi se používají tři druhy přídavných modulů. • ElFinder – Tento plugin slouží ke správě souborů. V informačním systému se hodí pro správu obrázků, ukládání faktur a podobně. Tento správce souborů je napsán v javaScriptu za použití jQuery. Byl vytvořen výhradně pro webové prohlížeče. Na oficiálních stránkách12 je napsáno, že tento program byl inspirován jednoduchostí programu Finder používaného v operačních systémech 10

Dat – slovo skloňované podle slova datum do druhého pádu, množného čísla. Open-source (otevřený software) je počítačový software s otevřeným zdrojovým kódem. Otevřenost zde znamená jak technickou dostupnost kódu, tak legální dostupnost. 12 http://elfinder.org/ 11

38

7

POPIS INFORMAČNÍHO SYSTÉMU

Mac OS X. Systém souborů umožňuje základní operace jako upload, kopírování, přesouvání, vytváření složek/souborů, mazání, přejmenovávání a podobně. Od HTML 5 podporuje nahrávání souboru pomocí drag and drop. Dále podporuje tvorbu a rozbalování nejpoužívanějších archivů. Zároveň umožňuje použití spousty formátů, což jde vidět na obrázku číslo 12. Na obrázku lze také vidět dva druhy zobrazení ikon, detailní a s podrobnostmi. ElFinder vytváří stromovou strukturu dokumentů a u textových souborů, formátů PDF nebo obrázků zobrazuje náhledy. Pokud se jedná o archívy nebo soubory typu Microsoft Office, tak umožňuje jejich stažení.

Obrázek 12: Ukázka dvou zobrazení ikon v ElFinderu.

• CkEditor – Plugin ckEditor slouží k tvorbě nebo úpravě textových dokumentů. V informačním systému je používán na tvorbu specifikace a textu emailů. Stejně jako elFinder je napsán v javaScriptu a je určen pro webové prohlížeče. CkEditor zjednodušuje, ale hlavně zlepšuje tvorbu webového obsahu. Jedná se o WYSIWYG13 editor, který přenáší funkce desktopových textových procesorů přímo na webové stránky. Obsahuje v sobě veškeré základní funkcionality pro správu textu. Umožňuje změny formátu a barev písma, odrážky, zarovnávání, psaní speciálních znaků a spoustu dalších možností pro práci s textem. Kromě toho umí pracovat s obrázky, tabulkami a obsahuje v sobě i vestavěné šablony. Jako velkou výhodu považuji importování textu z jiných textových editorů, včetně Microsoft Word. CkEditor je dostupný na oficiálních stánkách14 editoru. V první polovině obrázku číslo 13 je možné vidět tvorbu textového obsahu, ve druhé polovině potom samotné zobrazení textu na webové stránce. 13

WYSIWYG je akronym anglické věty „What you see is what you get“, česky „co vidíš, to dostaneš“. Tato zkratka označuje způsob editace dokumentů v počítači, při kterém je verze zobrazená na obrazovce vzhledově totožná s výslednou verzí dokumentu. 14 http://ckeditor.com/

7.2

Přídavné moduly

39

Obrázek 13: Ukázka použití ckEditoru a zobrazení výsledného textu.

• PhpMailer – Tento plugin slouží k odesílání e-mailů přímo z informačního systému. Slouží k notifikaci zaměstnanců, v případě když jsou rozdělovány zakázky, popřípadě k notifikaci vedení po tom co je zakázka dokončena. I když neexistují oficiální statistiky, tak se jedná pravděpodobně o nejpoužívanější kód k posílání e-mailů přímo z PHP. Částečně je to zapříčiněno tím, že se jedná o open-source ale má i spoustu předností. PhpMailer obvykle posílá poštu přes místní poštovní server, což funguje na Linuxu, BSD15 nebo OS X platformy. Systém Windows obvykle neobsahuje místní poštovní server, pro tyto případy phpMailer zavádí integrovaný SMTP16 , umožňující odesílání zpráv bez místního poštovního serveru. Tento plugin je samozřejmě kompatibilní s PHP 5 i novějšími a podporuje šifrování a digitální podpisy, například S/MIME17 . Další výhodou je počet jazykových mutací. Obsahuje preš 40 jazyků včetně češtiny. Na obrázku 14 je zobrazena část kódu, jehož úkolem je právě za použití phpMaileru odeslat email. Nejdříve se vytvoří instance třídy PHPMailer a poté se nastaví jazyk a kódování. Dále je potřeba nastavit základní proměnné jako e-mail, formát, předmět e-mailu, samotný text popřípadě jméno, zalamování a podobně. 15

BSD (Berkeley Software Distribution, též Berkeley Unix) byl Unixový operační systém distribuovaný Kalifornskou univerzitou v Berkeley. Jméno je rovněž společně používáno pro moderní následníky této distribuce. 16 Simple Mail Transfer Protocol (zkratka SMTP) je internetový protokol určený pro přenos zpráv elektronické pošty (e-mailů) mezi přepravci elektronické pošty. 17 S/MIME (Secure/Multipurpose Internet Mail Extensions) je v současnosti používaný k zabezpečení elektronické pošty jako standard pro veřejný klíč šifrování a podepisování. Je to speciální verze protokolu MIME – S/MIME (Secure MIME).

40

7

POPIS INFORMAČNÍHO SYSTÉMU

Obrázek 14: Ukázka kódu odeslání emailu pomocí phpMaileru.

7.3

Sekce můj účet

Sekce můj účet uchovává informace o právě přihlášeném uživateli. Informace o něm jsou uloženy v poli proměnných $_SESSION, popsané podrobněji níže v sekci funkce v odrážce přihlašování do systému. Tato sekce je rozdělena na dvě části. První část se jmenuje osobní nastavení. Zde jsou všechny osobní, kontaktní, platební informace o právě přihlášeném uživateli a adresa. Zde má uživatel také možnost měnit si svoje přihlašovací údaje. Ve druhé části, která se jmenuje mé práce, jsou zobrazeny všechny výkony právě přihlášeného uživatele. Obsahuje jeho osobní výkony, popřípadě výkony, ve kterých je určen jako vedoucí.

7.4

Sekce zaměstnanci

Tato sekce slouží k evidenci zaměstnanců a zobrazování základních osobních a pracovních informací o jednotlivých zaměstnancích. Evidence zaměstnanců je rozdělena na dvě podsekce. Na samotnou podsekci zaměstnanci a na podsekci brigádníci. Jsou dva hlavní důvody tohoto rozdělení. Prvním důvodem je fakt, že brigádníci nebudou zaměstnáni klasicky přes pracovní smlouvu, ale budou s nimi podepisovány pouze dohody o provedení práce. Druhý důvod je ten, že budou mít omezený přístup do informačního systému. Nebudou moci přidávat, mazat ani editovat položky a ani jim nebudou zobrazovány citlivé firemní informace. V obou podsekcích se uchovávají o zaměstnancích/brigádnících kromě základních informací jako je jméno, příjmení a podobně, také kontaktní informace, platební údaje, adresa trvalého bydliště, případně doručovací adresa, a také můžou být zaměstnanci přiděleny přístupové údaje. Přístupové údaje se skládají z loginu a hesla.

7.5

Sekce zákazník

41

Obrázek 15: Ukázka detailu zaměstnance.

7.5

Sekce zákazník

Sekce zákazník slouží k evidenci historických, současných popřípadě potenciálních budoucích zákazníků. Zákazník musí být vytvořen před vytvořením samotné zakázky, protože jednotlivé zakázky jsou poté přiřazovány již vytvořeným zákazníkům. To zamezuje vzniku duplicit mezi zákazníky a udržuje konzistenci v databázi. Uchovávane informace o zákaznících jsou velmi podobné jako v případě zaměstnanců. Jedná se o kontaktní informace, adresy, a platební údaje. Zákazníkům můžou být přiděleny také přihlašovací údaje, ale v tomto případě se nejedná o přihlašovací údaje do informačního systému, ale do rezervačního systému. Tato varianta ale nebude příliš využívána, protože přihlašovací údaje si uživatel vyplňuje sám při registraci v rezervačním systému. Přístupové údaje se i v tomto případě skládají z loginu a hesla.

7.6

Sekce zboží

Sekce zboží slouží jako podrobný přehled všech produktů společnosti Decstore. Obsahuje produkty bez ohledu na to jestli jsou skladem, vypůjčené nebo třeba rozbité. U jednotlivých produktů je vždy nutné určit kromě jejich jmen také zařazení do podkategorie. Každá podkategorie už musí být zároveň už předem zařazená do jed-

42

7

POPIS INFORMAČNÍHO SYSTÉMU

Obrázek 16: Ukázka přidávání zákazníka.

notlivých kategorií. Každý produkt musí mít učený aktuální stav, aby zákazník věděl dostupnost produktu. Dále májí produkty svoje parametry, specifikaci a fotogalerii. Vždy musí být zvolena náhledová fotografie, pokud produkt má nějakou fotografii. Pro práci s fotografiemi je použitý soubor funkcí SimpleImage.php volně dostupných na http://www.white-hat-web-design.co.uk/blog/resizing-images-withphp/. Umožnuje efektivně provádět standardní funkce s obrázky, například změna velikosti, měřítka, ořezávání a podobně. Přehled zboží umožňuje kromě vyhledávání a řazení také filtrovat produkty podle kategorie, což může ulehčit uživateli prohledávání produktů. I když se to nemusí na první pohled zdát, tak sekce zboží je nejsložitější sekce jak po stránce návrhové, tak po stránce implementační. Při návrhu sekce zboží bylo nutné vyřešit dva základní problémy. První problém byl návrh struktury kategoriepodkategorie a druhý byl návrh parametrů. Zároveň muselo být přihlédnuto k zadání a to znělo, že počet kategorií, podkategorií i atributů bude variabilní. To znamená, že se uživatel může libovolně přidávat, editovat a mazat jednotlivé kategorie, podkategorie i atributy. Problém s návrhem struktury kategorie-podkategorie souvisí s tím, že kategorie může obsahovat více podkategorií a podkategorie může být součástí více kategorií. Jinak řečeno, vzniká nám vazba M:N. V praxi nelze tento vztah vyjádřit přímo a používá se proto pomocné tabulky s vazbami 1:N na požadované tabulky. Tento problém je řešen pomocnou tabulkou t_kategorie_podkategorie, jak jde vidět na ER diagramu. V rámci jedné tabulky bude dvojice kategorie a podkategorie unikátní. Z takto vytvořené tabulky jsem schopni zjistit, do jaké kategorie

7.7

Speciální funkce

43

patří jednotlivé podkategorie a zároveň i množinu kategorií určité podkategorie. Druhý problém s návrhem atributů je komplexnější. Intuitivním řešením by bylo, že se atributy produktu vloží přímo do tabulky produkt. Toto řešení ale není příliš šťastné, protože neznáme počet atributů u jednotlivých produktů. V hraničním případě může mít jeden produkt jenom 3 atributy, zatímco v opačném případě jiný produkt i přes deset atributů. To by znamenalo v tabulce produkt spoustu volného místa, proto musí být parametry v jiné tabulce. V tomto případě nám ale vzniká opět vazba M:N. Tento problém je řešen pomocnou tabulkou t_produkt_parametr. V zadání bylo určeno, že počet kategorií, podkategorií i atributů se bude měnit v průběhu používání informačního systému Decstore. Díky tomuto návrhu je to možné, dokonce to umožňují přímo funkce informačního systému bez zásahu administrátora. Kategorie a atributy je možné přidávat jednoduše při vytváření nebo editaci produktu. Před přidáním podkategorie je ještě nutné, zvolit do kterých kategorií bude daná podkategorie zařazena. Druhá část této sekce se jmenuje správa podkategorií. V této části, jak už vyplývá z názvu, je možné detailněji pracovat s podkategoriemi. Zde je možnost kromě přidávání, jednotlivé podkategorie editovat nebo mazat. Na obrázku číslo 17 je možné vidět detail produktu.

Obrázek 17: Ukázka detailu zboží.

7.7

Speciální funkce

Informační systém obsahuje skryté funkcionality, které nemusí být na první pohled patrné. Navíc se mohou proplétat napříč jednotlivými moduly, proto budou popsány zvlášť.

44

7

POPIS INFORMAČNÍHO SYSTÉMU

• Generování obsahu podle identifikačního čísla osoby (IČO) – Při vytvaření nového nebo editaci stávajícího zákazníka je možné využít funkci načítání dat z administrativního registru ekonomických subjektu (ARES)18 . Data z databáze ARES jsou poskytovány přes XML soubor nebo-li XML feed. Dotazování je možné jak metodou HTTP POST19 tak i HTTP GET20 . V obou případech bez nutnosti digitálního podpisu. Poskytovatelem této webové služby je Ministerstvo financí České republiky (MFČR). Implementace je prováděna pomocí jQuery, kdy daná funkce reaguje na AJAXový požadavek. Podle identifikačního čísla osoby můžeme získat například název subjektu, DIČ, kompletní adresu a jiné. V našem případě nám postačí pouze tyto informace. Všechny informace bohužel nejsou vždy dostupné. U některých subjektů jsou načteny pouze některé informace. • Kontrola činnosti uživatelů IS – Každá sekce informačního systému si vede jednoduchý logový soubor“ do kterého se ukládají prováděné akce jednotli” vých uživatelů. Slovo soubor je v uvozovkách protože se nejedná o soubor jako takový, ale data jsou ukládána do databáze. Tento log neslouží ani tak ke zpětnému dohledání chyb informačního systému, jako spíš k dohledání činnosti jednotlivých uživatelů. Při každém přidání položky se do databáze ukládá, kdo danou položku vytvořil a kdy byla vytvořena. Při každé editaci položky se do databáze ukládá, kdo danou položku aktualizoval a kdy byla aktualizace provedena. Atributy vytvořil a datum vytvoření jsou stálé a nepřepisují se. Atributy aktualizoval a datum aktualizace se přepisují právě aktuální hodnotou. To znamená, že se v podstatě jedná o poslední aktualizaci položky. Díky těmto čtyřem atributům, můžeme zpětně zjistit historický vývoj položky a pokud u ní nastala nějaká chyba, tak zjistit kdo danou chybu udělal a kdy. • Generátor obsahu vstupu – Informační systém Decstore používá čtyři druhy generátoru pro automatické vyplnění vstupního pole. Pro formuláře, kde je třeba vyplnit datum, existuje možnost automaticky vyplnit pole aktuálním datem bez ručního psaní. To se hodí například u právě zakládaných zakázek. U některých formulářů je třeba vyplnit aktuální datum i čas. To je druhý typ generátoru. Tento typ je možné vidět na obrázku číslo 18. Pokud uživatel stiskne rotující šipku u pole datum zadání nebo deadline, tak bude pole vyplněno aktuálním datem i časem. Třetím druhem je autofill funkce která po zadání ceny bez DPH automaticky vyplní cenu s DPH. To je možné použít také na obrázku číslo 18, ale v tomhle případě není třeba rotující šipka. Cena s DPH se vyplní automaticky po zadání ceny bez DPH. Čtvrtý a poslední generátor slouží k vytvoření náhodného hesla. Tato funkce se využívá u vytváření uživatelských 18 Administrativní registr ekonomických subjektů je informační systém, který umožňuje vyhledávání nad ekonomickými subjekty registrovanými v České republice. Zprostředkovává zobrazení údajů vedených v jednotlivých registrech státní správy, ze kterých čerpá data. 19 Metoda GET odešle data v adrese stránky. 20 Metoda POST data odesílá v hlavičce HTTP požadavku a adresu stránky neovlivní.

7.7

Speciální funkce

45

účtů jednotlivých zaměstnanců. Způsob generování hesla je vidět na obrázku číslo 19. Funkce převezme jako atribut délku hesla a vygeneruje náhodné posobě jdoucí znaky dané délky. Heslo musí vždy obsahovat alespoň jeden znak ze všech těchto množin {a–z}, {A–Z}, {0–9}. Pokud některá z množin není zastoupena, tak se heslo generuje znova. Funkce končí, jakmile jsou všechny dané podmínky splněny.

Obrázek 18: Ukázka formuláře používajícího generátor vstupu.

Obrázek 19: Funkce pro generování a kontrolu hesla.

• Přihlašování do systému – Po přihlášení uživatele do systému musí informační systém v každou chvíli vědět, který uživatel je právě přihlášený. Informace o právě přihlášeném uživateli využívá sekce Můj účet“ k změně osobního ”

46

7

POPIS INFORMAČNÍHO SYSTÉMU

nastavení a podle daného uživatele se potom můžou nastavovat přístupy do jednotlivých sekcí. K uchovávání potřebných informací o právě přihlášeném uživateli slouží pole proměnných $_SESSION. Pokud uživatel při přihlašování zvolí možnost trvalého přihlášení, tak data uložená na serveru v proměnné $_SESSION už nejsou dostatečná. V tomto případě je nutné, aby server poslal uživateli data ve formě cookies. Ty jsou uložena v počítači uživatele a při otevření stránek informačního systému jsou tyto data nahrávána zpátky na server. Díky tomu se uživatel nemusí znovu přihlašovat. U cookies je nastavená časová známka na jeden rok. Po uplynutí jednoho roku platnost cookies vyprší a uživatel se musí přihlásit znovu. Při ručním odhlášení uživatele je zničena proměnná $_SESSION a časová známka cookies je posunuta o jeden rok dopředu. To znamená že proměnná $_SESSION je nepřístupná, platnost cookies vypršela a uživatel se musí znovu přihlásit. • Komunikace IS s uživatelem – Při práci uživatele v informačním systému, musí mít uživatel zpětnou vazbu o tom, jestli jsou jeho akce bezproblémově prováděny. Ke komunikaci s uživatelem dochází pomocí tří druhu hlášení. První typ hlášení nastává při bezproblémovém chodu dané operace, jedná se o hlášení success“. Nastává v případě, kdy uživatel úspěšně dokončil danou akci, ” například editaci zakázky. V případě, pokud uživatel zapomněl vyplnit povinnou položku nebo vstup jakkoliv neodpovídá deklarovaným pravidlům, systém použije druhý typ hlášení warning“. Tento druh hlášení nastává výhradně při ” chybě uživatele. Naopak třetí typ hlášení error“ nastává převážně při nějaké ” neočekávané chybě. Může se jednat o chybu v systému nebo o chybu komunikace s databází a podobně. Toto hlášení většinou uživatel sám neopraví a musí se obrátit na administrátora. Ukázky všech tří typů hlášení jsou vidět na obrázku číslo 20. První zelená hláška je typu success“, oranžová warning“ a červená ” ” je typu error“. ”

Obrázek 20: Ukázka tří druhů systémových hlášení.

8

POPIS REZERVAČNÍHO SYSTÉMU

8

47

Popis rezervačního systému

Informační systém DecIs je komplexnější a rozsáhlejší systém, jak do počtu napsaných řádků kódu, tak do počtu funkcionalit, než systém rezervační. Přesto tento systém sám o sobě není tak důležitý z pohledu zákazníka, jako systém rezervační. DecIs zprostředkovává uživatelsky přívětivou komunikaci s databázovým systémem a díky tomu je v podstatě podvrstvou pro práci rezervačního systému. Až rezervační systém prezentuje zákazníkovy výsledný produkt. Pokud chce firma Decstore nabízet nějaký produkt, tak se přihlásí do systému DecIs, tam vytvoří nový produkt, zařadí ho do kategorie a podkategorie, vyplní základní údaje jako je název, cena, počet kusů, specifikace a tak dále. Po úspěšném vytvoření je produkt přesunut do evidence zboží. Od této chvíle, když zákazník otevře rezervační systém a napíše do vyhledávače název produktu, tak je zákazníkovy tento nový produkt zobrazen a má možnost si ho rezervovat. To samozřejmě platí i pokud ho nevyhledává, ale pokud ho hledá ručně mezi kategoriemi a podkategoriemi.

8.1

Postup rezervace zboží

Otevření úvodní stránky index.php je vidět na obrázku číslo 21. Tato stránka je navržená a designovaná tak, aby uživatele snadno nasměrovala k produktům, které ho nejvíce zajímají. Jednotlivé kategorie jsou reprezentovány obrázky v bublině, které po najetí myší dělají efekt nafouknutí. Pokud má potencionální zákazník zájem o dekorace na svatbu, vybere si kategorii svatba, pokud chce pořádat firemní večírek, tak si vybere kategorii firmy.

Obrázek 21: Úvodní stránka rezervačního systému.

48

8 POPIS REZERVAČNÍHO SYSTÉMU

Sekce kategorie Po výběru kategorie se otevře stránka kategorie.php, která v URL přebírá jako parametr název vybrané kategorie. Na základě tohoto parametru se potom odvýjí další nákup. Pro další průběh nákupu budeme předpokládat, že uživatel pořádá svatbu a potřebuje vypůjčit dekorace určené pro svatbu.

Obrázek 22: Produkty na stránce kategorie.php a ukázka animace po najetí myši.

V horní části stránky kategorie.php se zobrazí úvodní fotka. Tato fotka se týká vždy vybrané kategorie. Takže v našem případě svatby. V horní části pod úvodním obrázkem se dále nachází navigace. V našem případě je aktivní pole svatba. V levé části se nachází menu a v menu se nám objevily podkategorie týkající se svatby. Tyto podkategorie se dynamicky mění podle toho jaká podkategorie je vybrána, stejně jako v případě úvodního obrázku. Každá kategorie může mít jiné podkategorie, ale můžou být i společné pro více kategorií. Náležitost do určité kategorie je možné nastavit v informačním systému v sekci zboží. Uvnitř těla stránky jsou uživateli nabízeny ty produkty, které jsou zařazené alespoň do jedné zobrazované podkategorie. Můžou to být svícny, talíře a tak podobně.

Obrázek 23: Ukázka funkce autocomplete.

Uživatel si může zpřesnit vyhledávání tak, že vybere podkategorii, kterou hledá. Pokud by měl zájem jen o talíře, tak nemusí vyhledávat ve všech produktech zařazených do svatby, ale jen z produktů zařazených do talířů. Po najetí na spodní část náhledové fotky produktu, tak jak jde vidět na obrázku 22, vyjede poloprůhledná karta, která obsahuje kompletní název produktu, jeho cenu a dostupný počet kusů. Pokud myš opustí prostor této karty, tak zase zajede zpátky do původní pozice.

8.1

Postup rezervace zboží

49

Jednotlivé zobrazené produkty je možné ještě dále filtrovat. Rezervační systém používá tři filtry. První filtr vybere zboží, které má menší finanční hodnotu než vybraná částka. Druhý filtr vybere zboží, které má zadanou barvu. Poslední filtruje podle materiálu produktu. Filtry lze používat samostatně, nebo je uživatel může mezi sebou kombinovat. To umožňuje lépe specifikovat výběr. Rezervační systém může například zobrazit všechny tyrkysové skleněné vázy, které stojí do 200 Kč. V případě, že uživatel není stále spokojen, je mu umožněno si zboží ještě seřadit. Pokud není spokojen se základním řazením, může řadit od nejlevnějšího, od nejdražšího a podle počtu dostupných kusů. Další možností jak vybrat zvolený produkt, pokud uživatel ví, co hledá, je vyhledávání. Uživatelská přívětivost vyhledávače je zvyšována pomocí funkci autocomplete21 (obrázek číslo 23). Autocomplete našeptává možnosti nejvíce odpovídající napsanému textu. Tyto možnosti se dynamicky mění po stisknutí každé klávesy. Vyhledávač vyhledává vždy podle celého názvu zboží. Komfortu vyhledávání jsou podřízeny i názvy zboží, které ve svém názvu ve většině případů obsahují informace o materiálu, barvě, velikosti nebo tvaru. Typickým příkladem takového názvu může být například váza porcelánová velká baňatá. Autocomplete tuto možnost zařazuje do svého seznamu, ať napíšeme slovo váza, porcelánová, velká nebo baňatá. Sekce detail produktu Poté, co je uživatel spokojený a klikne na náhledovou fotografii vybraného produktu nebo potvrdí vybraný text ve vyhledávači, tak se mu otevře stránka detail_prouktu.php (obrázek číslo 24). Jak z názvu vyplývá, na stránce se dozví důležité informace o daném produktu. Na stránce jsou zobrazeny náhledové fotografie, kdy po kliknutí na danou fotku dojde k jejímu zvětšení. Fotky je možné odebírat a přidávat v informačním systému, ostatně jako změna všech parametrů a specifikace zboží. Dále se na stránce dozvíme jednotlivé parametry zboží, jako je materiál, barva, stav, velikost a tak dále. Zároveň může být v detailu produktu zboží popsáno pomocí detailnější specifikace. Ve specifikaci se zákazník může dozvědět důležité informace o tom jak produkt používat, k čemu slouží nebo jaké jsou jeho výhody oproti ostatním produktům. V detailu produktu nechybí samozřejmě také tlačítko pro rezervaci zboží. Před potvrzením rezervace formulář obsahuje vstupní pole typu number, v kterém je možné zvolit počet kusů pro rezervaci. Do košíku není možné vložit vícekrát jeden produkt, ale pouze jednou, s počtem kusů daného produktu. Minimální hodnota pro objednávku je jeden kus a maximální hodnota je určena maximální počtem dostupných kusů. Tlačítko rezervovat se zobrazuje pouze v případě, že je zboží na skladu, tedy v případě, kdy má zboží určen stav skladem. 21

Autocomplete – funkce automatického doplňování, někdy v češtině uváděno jako našeptávač.

50

8 POPIS REZERVAČNÍHO SYSTÉMU

Obrázek 24: Ukázka detailního náhledu na zboží.

Sekce košík Pokud uživatel rezervuje nějaké zboží, tak přejde na stránku košík.php. V košíku jsou uloženy položky všech zákazníka, které nejsou potvrzeny jako objednávka. Jakmile jsou potvrzeny jako objednávka, tak se z košíku odstraní a přesouvají se do zakázek. Objednávka daného zákazníka je identifikována pomocí unikátního identifikátoru v databázi, pojmenovaný jako id_session. Tento identifikátor je složený z IP adresy22 a aktuálního data. To znamená, že pokud uživatel vloží do košíku nějaké zboží a potom se mu například vypne počítač, tak se mu košík nevyprázdní, ale vydrží až do konce dne. Pokud se uživatel chce k nákupu vrátit. Identifikátor je dostatečně velký, aby zvládl i 128 bitové IP adresy verze 6. Objednávky, které nejsou potvrzeny, zůstávají v košíku pro budoucí možnost uplatnění data miningu. Pokud vezmeme zboží ze zakázek a zboží co zůstalo v nákupním košíku, tak můžeme zjistit, které zboží je nejčastěji vkládáno do košíku, a potom analyzovat a porovnávat, proč se nákup v některých případech neuskutečnil. V nákupním košíku se ještě kromě již zmíněného identifikátoru ukládají informace, o jaké zboží se jedná, kolik kusů si zákazník objednal a také způsob dopravy a platby. Na stránce kosik.php, jak jde vidět na obrázku číslo 24, se u každé položky zobrazuje zmenšenina náhledové fotografie, 22

IP adresa je číslo, které jednoznačně identifikuje síťové rozhraní v počítačové síti, která používá IP (internetový protokol).

8.1

Postup rezervace zboží

51

celý název produktu s odkazem zpět na detail daného produktu, počet kusů který se dá stále měnit a celková cena, která se mění automatiky po změně počtu kusů. Dále je možné zvolit způsob platby a způsob dopravy. Pro potvrzení těchto parametrů objednávky slouží tlačítko pokračovat v nákupu. V případě, že není způsob platby nebo dopravy zvolen, tak je uživatel vyzván k tomu, aby dané údaje vyplnil.

Obrázek 25: Ukázka zboží vloženého do košíku.

Po stisknutí tlačítka pro pokračování v nákupu se otevírá stránka kosik2.php. Zde uživatel musí vyplnit osobní informace a adresu, aby mohl potvrdit objednávku. Teoreticky by tato stránka nemusela existovat a vše by mohlo být na jedné stránce. Vyplnění těchto informací je odděleno z důvodu přehlednosti a lepší orientaci pro zákazníka. V horní části této stránky vidíme opět vypsané jednotlivé produkty, které jsou vložené do košíku, ale tady už nemůžeme měnit počet kusů. V této fázi nákupu mají zobrazené produkty pouze informativní charakter. Pro případné změny by se uživatel musel vrátit do první části košíku, kde touto možností editace stále disponuje. K tomuto účelu slouží tlačítko zpět ve spodní části formuláře. Samotný nákup lze provést ve dvou režimech. Jedním je nákup bez registrace, což je vhodné pro příležitostní zákazníky. Může se jednat o zákazníky, kteří jsou zde poprvé a neví, jestli budou chtít služby společnosti Decstore dále využívat, nebo pro ty, kteří nakupují opravdu jen ojediněle. V tomto případě není důležité obtěžovat povinnou registrací. V případě, kdy zákazník nakupuje opakovaně, tak mu registrace může urychlit čas strávený opětovným a pořád se dokola opakujícím vyplňováním stále stejných osob-

52

8 POPIS REZERVAČNÍHO SYSTÉMU

ních údajů a adresy. Tyto informace jsou pro registrované zákazníky předvyplněné podle hodnot zadaných v registraci. Nakonec zákazník může vyplnit text box, který je určen pro poznámky nebo speciální přání.

8.2

Procesy běžící na pozadí

Před tím než jsou tyto procesy spuštěny, zákazník vyplní povinné údaje pro nákup (jméno, příjmení, telefon, email a kompletní adresu). Tyto pole jsou označeny tmavě červeným rámečkem kolem vstupního pole. Poté proběhne javaScriptová kontrola vstupních dat. V případě špatného vstupu nebo nevyplněných povinných polích je zákazník informován, kde se chyba vyskytla. V případě, že byl vstup správný, tak je zákazník informován o tom, že objednávka proběhla úspěšně a další procesy už běží na pozadí. Popis procesů probíhají během nákupu zákazníka bez registrace 1. Do tabulky t_zakaznik je vložen nový zákazník. Tento zákazník je ihned zobrazován v informačním systému. 2. Do tabulky t_adresa_zakaznik je vložena fakturační adresa. Zároveň je vložena i adresa doručovací, pokud je vyplněna. 3. Do tabulky t_zakazka je vložena nová zakázka, která je provázána s právě vytvořeným zákazníkem. Tato zakázka je ihned zobrazována v informačním systému. 4. V informačním systému je vytvořená složka, která se jmenuje podle id právě vytvořené zakázky. Do této složky je možné z informačního systému nahrávat soubory týkající se této zakázky pomoci pluginu ElFinder, který je popsaný výše. 5. V tabulce t_casti_zakazek jsou vytvářeny části zakázek podle toho, co uživatel měl vloženo v košíku. Jednotlivé části zakázky odpovídají podkategoriím v košíku. To znamená, že všechny vázy jsou v jedné části zakázky, všechny talíře jsou v druhé části zakázky a tak dále. Díky tomu je možné se lépe orientovat i v rozsáhlejších zakázkách a zároveň to usnadňuje vyhledávání zboží ve skladu, když jsou všechny položky seřazeny podle podkategorie. 6. Pokud vše proběhlo bez problému, je vyprázdněn nákupní koš o položky, které jsou evidovány v této zakázce. Popis procesů probíhají během nákupu registrovaného zákazníka Jak už bylo zmíněno, tak registrovaný uživatel má všechny povinná pole vyplněna už z registrace. Povinná pole u registrace odpovídají povinným polím při nákupu. Pokud uživatel nic nezmění, tak kontrola údajů proběhne v pořádku. V případě

8.2

Procesy běžící na pozadí

53

potřeby je ale uživateli dána možnost všechny informace změnit. Po tom, co je zákazník informován o tom, že objednávka proběhla úspěšně, běží první procesy rozdílně u registrovaného a neregistrovaného zákazníka, a proto jsou popsány zvlášť. 1. V případě změny osobních údajů jsou v tabulce t_zakaznik aktualizovány atributy tohoto uživatele. Jeho aktualizované údaje jsou ihned zobrazovány v informačním systému. 2. V případě změny adresy je v tabulce t_adresa_zakaznik aktualizována fakturační adresa. Zároveň je aktualizována i adresa doručovací, pokud je vyplněna a pokud byla vyplněna i u registrace. Pokud je vyplněna v nákupním košíku, ale při registraci vyplněna nebyla, tak je do tabulky t_adresa_zakaznik vložena nyní. 3. Do tabulky t_zakazka je vložena nová zakázka, která je provázána s právě přihlášeným zákazníkem. Tato zakázka je ihned zobrazována v informačním systému. 4. Další kroky už jsou stejné pro neregistrovaného i registrovaného zákazníka. V informačním systému je vytvořena složka, která slouží k nahrávání souborů, které se týkají této zakázky. Poté jsou vytvořeny jednotlivé části zakázky podle stejného principu, jaký byl již popsán a nakonec se vyprázdní nákupní koš o položky, která jsou evidovány v této zakázce. Změna počtu kusů u zboží V případě, že si zákazník objednal nějaké zboží, nesmí existovat možnost, že si toto zboží rezervuje další zájemce. Tomu je zabráněno tak, že tlačítko rezervovat se uživateli rezervačního systému zobrazuje jen v případě, kdy jsou dodržena dvě pravidla. • Zboží je ve stavu Skladem • Ve skladě je evidován minimálně jeden kus. Zaměstnanec, který má přístup do informačního systému, může měnit stav každého produktu. V případě, kdy je zboží vypůjčeno nebo poškozeno nebo jakýmkoliv jiným způsobem nedostupné, změní stav tohoto zboží. Jsou evidovány stavy čtyři základní stavy (skladem, vypůjčeno, rezervováno, nedostupné). Díky tomu zákazník ví o tom, že toto zboží existuje, ale není zrovna skladem. V případě potřeby, se může informovat o dostupnosti, pokud má o toto zboží zájem. Jakmile uživatel odešle objednávku, tak se jednotlivé položky košíku propojí se zakázkou a s jednotlivými částmi zakázky. Objednané počty kusů se jednoduše odečtou od dostupných počtu kusů. V rezervačním systému je potom nabízen takový počet kusů, který je aktuálně na skladě. Propojení se zakázkou je důležité,

54

8 POPIS REZERVAČNÍHO SYSTÉMU

když je všechno vypůjčené zboží vráceno zároveň. Pokud je zboží vráceno bez problémů a nepoškozené, tak se jednoduše v informačním systému předá zakázka do účetnictví jako dokončená. K tomu slouží tlačítko Předat nyní v detailu zakázky. Poté se aktualizuje dostupný počet kusů zboží. Pokud měl zákazník vypůjčené dva stoly, tak počet kusů dostupných stolů se zvýší o dva. Někdy může nastat situace, že některá část zboží je vypůjčena jen na jeden den, ale například stoly a židle na více dnů. V tomto případě je důležité propojení s částmi zakázky. Části zakázek jsou tvořeny vždy celou podkategorií, takže pokud uživatel vrátí talíře, tak je možné dokončit pouze část zakázky s názvem talíře, a potom se zpřístupní pouze vypůjčené talíře. Stoly zůstanou stále nedostupné. Nastat může i speciální případ, že zákazník chce vrátit první den deset stolů, ale dalších deset si chce ponechat i na druhý den. To může nastat, pokud chce například ušetřit peníze. I na tento případ je informační systém připraven v podobě výkonů. Půjčení stolů lze rozložit na více výkonů a potom dokončovat jednotlivé výkony zvlášť a aktualizovat počet kusů po částech. Propojení s výkonem se ovšem neděje automaticky, jen v případě, kdy má zákazník o tuto možnost zájem.

8.3

Data mining

Data mining je stále se rozvíjející oblast IT, jejíž úlohou je dolování informací z dat. Podle (Han, Kamber, Pei, 2012) se data mining zabývá řešením problémů pomocí analýzy dat, která jsou v daném čase k dispozici. Odhalená znalost pak může účinně pomáhat při odhadu budoucích jevů. Data mining se převážně zaměřuje na elektronicky uložená data, přičemž prohledávání dat je automatizované pomocí počítačů. Obecně platí, že více dat obsahuje více informací. To znamená, že jsme schopni získat více znalostí, které jsou ale stále složitější. V rezervačním systému Decstore je využití data miningu platné převážně v komerční sféře. Pomáhá v marketingu při rozhodování, kterým klientům a jak doporučovat nabídku produktů. Obecně existuje spoustu způsobů, jak doporučit zboží zákazníkovi. Pokud se podíváme na různé e-shopy, tak používají rozdílné metody jak zboží doporučit. Někdo si vystačí s explicitním nastavením toho, co se má doporučit nebo doporučuje jen akční zboží. Dalším možností je vytvořit si nějaký vlastní sofistikovanější způsob.

Obrázek 26: Ukázka doporučených produktů.

8.3

Data mining

55

Rezervační systém Decstore, se snaží analyzovat data o tom, o které zboží zákazník projevuje svůj zájem a zároveň obecné informace o tom jak se chovali ostatní zákazníci. Na základě získaných informací dosazuje vhodné produkty do čtyř sekcí, které jsou tomuto účelu vyhrazeny. Pro lepší názornost jsou na obrázku číslo 26, sekce označeny písmeny A, B, C a D. Tento prostor vyhraněný pro doporučování se nachází ve spodní části stránky detail produktu. Doporučování zboží dále probíhá ve dvou režimech. Režim nepřihlášeného uživatele Tento režim doporučování probíhá v případě, kdy v rezervačním systému není přihlášený žádný uživatel. • Sekce A – V této sekci je doporučován produkt, který je ze stejné kategorie jako produkt, o který projevil zákazník zájem. Zároveň ale platí, že nesmí být ze stejné podkategorie. To znamená, že bude vybrán produkt z kategorie svatba ale nebude to váza, protože se předpokládá, že z váz si zvolil právě tu kterou si zobrazuje. Proto mu bude doporučeno jiné zboží ze svateb, například etažér. Dále musí platit, že zboží musí být skladem a počet kusů nesmí být nula. Poslední parametry, které by měl doporučovaný produkt splňovat, je stejná barva a stejný materiál. Pokud produkt splňující všechny tyto parametry existuje, tak je doporučen. Pokud neexistuje, odebírají se podmínky pro výběr zpětně. To znamená, že nejdříve se zruší podmínka materiálu. Pokud není produkt stále nalezen, tak se zruší podmínka o barvě a tak dále. V krajním případě, kdy neexistuje produkt, který se v něčem shodoval, je doporučen libovolný produkt, který pouze musí náležet do stejné kategorie. V kategorii je vždy více než jeden produkt, proto tento případe nemůže nastat. • Sekce B – Doporučování v této sekci probíhá stejně jako v sekci A, akorát musí platit, že produkt v sekci A není stejný jako produkt v sekci B. Při tomto použití by ale všechny čiré skleněné vazy co splňují i ostatní požadavky, měli doporučované vždy stejné zboží v těchto dvou sekcích. Proto je do algoritmu zanesena i proměnná náhody. Stejná váza má doporučovaný produkt vždy stejný, ale jiná váza se stejnými parametry bude mít doporučovaný jiný produkt, pokud existuje takový, který splňuje napsaná pravidla. • Sekce C – Do této sekce je vkládáno zboží, které je v dané kategorii nejprodávanější. Musí platit, že toto zboží je rozdílné od zboží v sekcích A a B. Dále platí i pravidlo o rozdílné podkategorii, pravidlo že zboží musí být skladem a že počet kusů nesmí být nula. V případě že takové zboží neexistuje, jsou podmínky výběru odebíraný zpětně, až nakonec může být doporučeno libovolné zboží z dané kategorie. Tento případ ale může nastat jen na začátku prodeje. V případě kdy je košík naplněn dostatečným počtem záznamů se procento nenalezení shody podstatně snižuje.

56

8 POPIS REZERVAČNÍHO SYSTÉMU

• Sekce D – Do této sekce je vkládáno zboží, které je v dané kategorii nejvkládanější do košíku. Rozdíl mezi nejprodávanějším a nejvkládanějším zbožím je jednoduchý. Platí vzorec, že nejvkládanější se rovná nejprodávanějšímu zboží plus zboží, které bylo sice vloženo do košíku, ale z nějakých důvodů zboží nebylo vypůjčeno. Pokud je nejprodávanější a nejvkládanější zboží stejné, tak je vybráno druhé v pořadí. Jinak platí stejné podmínky výběru jako v sekci C. Režim přihlášeného uživatele Tento režim doporučování probíhá v případě, kdy je v rezervačním systému přihlášený libovolný uživatel. Tento režim doporučování zboží probíhá v sekcích A a C stejně jako v režimu nepřihlášeného uživatele. Liší se pouze v sekcích B a D. • Sekce B – Doporučování v této sekci probíhá velice podobně, jako v sekci C u nepřihlášeného uživatele s tím rozdílem, že je vybráno pouze zboží, které přihlášený uživatel v minulosti nejvíce kupoval. Filozofie tohoto doporučení je taková, že se systém snaží doporučit zboží, se kterým byl uživatel v minulosti nejvíce spokojen. Spokojenost je posouzena podle toho, že toto zboží kupoval nejčastěji. • Sekce D – V této sekci probíhá doporučování podobně, jako v sekci D u nepřihlášeného uživatele s tím rozdílem, že je opět vybráno pouze zboží, které přihlášený uživatel v minulosti nejvíce vkládal do košíku. Rezervační systém se tímto snaží o osobnější přístup k jednotlivým zákazníkům. Analýza nákupního koše Do budoucna se plánuje nahradit sekce C a D výstupem z analýzy nákupních košíků. Z důvodu nedostatku dat pro analýzu a z důvodu získání relevantních dat byl použit volně dostupný soubor supermarket.csv, který je přiložen v příloze na CD. Tento soubor reprezentuje údaje ze supermarketu. Jeden řádek v tomto souboru simuluje jeden nákup respektive jeden nákupní košík. V každém řádku jsou informace o tom, které zboží daný košík obsahuje. Díky tomu můžeme analyzovat informace, které zboží se nejčastěji kupuje společně. Pokud zjistíme, které zboží se kupuju společně, můžeme toto zboží zákazníkům předem doporučovat. Soubor obsahuje téměř 5 000 řádků. Výpočet takového počtu řádků je časově i prostorově náročný. Mluvíme o řádově desítkách sekund, což je na webovou stránku moc dlouhá doba. Proto byly nákupní košíky analyzovány ve specializovaném softwaru SPSS Modeler, který je doporučen v (Provost, 2013). Pro testování dat byly použity dva základní algoritmy Aprioty a GRI. Jejich použití lze vidět na obrázku číslo 27. Výsledkem těchto algoritmů není zjistit, které zboží se kupuje nejčastěji, ale které dvojice popřípadě trojice se společně kupují nejčastěji. Z analýzy vyplývá, že v daném obchodě se nejčastěji společně kupovalo ovoce a zelenina. Tato dvojice mezi

8.3

Data mining

57

Obrázek 27: Ukázka použití SPSS Modeler na analýzu nákupních košíků.

sebou dává racionální smysl. Například ovoce a zeleninu kupují lidé, kteří pečují o své zdravý. Druhým nejlepším výsledkem byl společný nákup vína a sladkostí. Z této analýzy bude moci v budoucnu společnost Decstore vyvozovat zajímavé závěry. Například pokud si uživatel chce koupit vázu, systém mu doporučí květiny, protože ví, že nejvíce zákazníků si k váze kupuje květiny. Takovéto použití programu SPSS Modeler lze jednoduše automatizovat. Export z databáze z tabulky t_nakupni_kos lze uzpůsobit tak, aby ho jako vstup přijímal data miningový program. Do databáze potom lze k jednotlivým položkám ukládat nejvhodnějšího kandidáta k doporučení.

58

9

9 BEZPEČNOST

Bezpečnost

Pro přístup do informačního systému je nutné použít heslo. Problém zvolení dostatečně silného hesla je dnes obligátní problém. Problém obecně známý, i když ve spoustě případů silně podceňovaný. Silné heslo by mělo být dostatečně dlouhé, nemělo být dohledatelné v slovníku, mělo by obsahovat velká i malá písmena, čísla a někdy i speciální znaky. Určitě existuje ještě více parametrů, podle čeho je možné hodnotit kvalitu hesla. Volba správného hesla je ale jen jednou stranou mince. Tou druhou, přinejmenším stejně závažnou je způsob, jak heslo uložit. První možností je heslo ukládat do databáze v prosté textové podobě, tak jak ho uživatel napíše do formuláře. Tato možnost je nejjednodušší, ale z pohledu bezpečnosti hrozivá. V případě, kdy útočník odchytne odeslaný požadavek na server, může si bez problému přečíst odeslané heslo. Proto už samotné heslo musí být chráněno před samotným odesláním na server. Další možností, která by se nabízela je heslo před odesláním zašifrovat. K použití šifrování také není opodstatněný důvod, i když je to lepší varianta něž předchozí případ. Hlavním důvodem proč nepoužívat šifrovací algoritmy je to, že heslo nikdy nepotřebuje dešifrovat do původní podoby, takže už samotná možnost dešifrování hesla vybízí útočníka se této výzvě postavit a heslo dešifrovat. Tento způsob zabezpečení je určen spíše pro tajné zprávy, které je někdy někde nutno rekonstruovat. Další možností je zprávu hashovat. Základní vlastnosti hashe jsou vhodné pro skrytí původní podoby hesla. Hashovací funkce nám při jakémkoliv vstupu dá vždy stejně dlouhý výstup. Každá mála změna vstupu dá na výstupu velký rozdíl, ve kterém nejsou očividné závislosti a hlavní výhodou je to, že z hashe je obecně velmi obtížné v reálném čase rekonstruovat původní heslo. Proto je použití této varianty v dnešní době už samozřejmostí. Přesto může nastat problém v případě, kdy útočník získá hash hesla. Útočník se může pokusit porovnat hashové reprezentace slov ze slovníku s hashem, který odchytl při komunikaci se serverem. V případě, kdy uživatel použije slovníkové heslo, je velká pravděpodobnost že útočník může najít shodu mezi slovníkem a získaným otiskem hesla. Tento způsob útoku je naštěstí možné ještě znesnadnit. A to je i případ, který je použit u informačního systému Decstore. Tato možnost se jmenuje salted hash. Princip spočívá v tom, že k heslu připojíme náhodnou posloupnost znaků, takzvaný salt. Vzniklý řetězec pak teprve hashujete. Útočník tak nemůže použít již předem hashovaný slovník, ale musí slova ze svého slovníku spojit se saltem a teprve potom hashovat. Salt jako takový není nic tajného a může se klidně uložit do databáze jako další pole. Tajné je však to, jak je salt použit. Může se připojit na začátek, na konec, za druhý znak a podobně. V našem případě jsme použili ještě jedno vylepšení. V databázi žádné pole salt není a místo toho jsme jako salt použili login uživatele. Takže i v případě, pokud by se útočník dostal do databáze tak nepozná, že je v heslu použit salt a navíc jsme ušetřili jedno pole v databázi. (Jícha, 2005)

9

BEZPEČNOST

59

Přidání uživatelského účtu se provádí následovně: • Uživatel zadá svůj login (délka loginu musí být delší než 5 znaků a musí být v databázi unikátní). – My si pro příklad zvolíme login martin“. ” • Uživatel zadá heslo (délka hesla musí být delší než 6 znaků a musí obsahovat alespoň jeden znak ze všech těchto množin {a–z}, {A–Z}, {0–9}). – My si pro příklad zvolíme heslo Aa1bB2“. ” • Uživatel zadá heslo podruhé pro ověření (obě zadaná hesla se musí shodovat). • Na heslo se použije funkce salt. – Funkce salt vezme prvních pět písmen z loginu marti“. ” – Postupně vkládá tuto zbylou část loginu do hesla tak, že první znak z loginu jde na druhou pozici hesla, druhy znak loginu jde na třetí pozici hesla atd. – Výsledné heslo poté vypadá následovně Amaa1rbtBi2“. ” • Na slated heslo se použije funkce hash. – Pro hashování je použita funkce SHA–512 a výsledný hash vypadá následovně f2afc80ca94ff7c572fd6ffd67627ad211bad041e7f62abd116d189282608538 ” c2a27cb259c93cf4468e1abfdcb3c2185a83e034a1fcd6e8f170c5eb354ed421“. • Login a salted hash se uloží do databáze. Díky hashování má útočník pouze minimální šanci dostat se k původnímu heslu. Jediné co může získat je hašhována podoba salted hesla. Kdyby se mu povedlo hash rozluštit, získá pouze salted heslo Amaa1rbtBi2“. Tohle heslo ale pro přístup ” fungovat nebude. Teď by ještě musel vědět, že se jedná o salted heslo a rozluštit jak je salt použit. To by mělo útočníka přinejmenším odradit. Což nám stačí. Ověření uživatelského účtu: • Uživatel zadá svůj login. – V našem případě je login martin“. ” • Uživatel zadá svoje heslo. – V našem případě je heslo Aa1bB2“. ” • Na heslo se použije stejná funkce salt. – Výsledné heslo poté vypadá následovně Amaa1rbtBi2“. ” • Na slated heslo se použije funkce hash. – Výsledný hash potom vypadá stejně jako u přidávání uživatelského účtu.

60

9 BEZPEČNOST

• SQL dotazem zjistíme uloženou hodnotu ve sloupci heslo u uživatele martin“. ” • Pokud v databázi existuje uživatel martin“ a výsledek funkce hash se rovná ” získané hodnotě v databázi, tak je přístup do informačního systému povolen. Ověření platnosti uživatelského vstupu je jen analogie k postupu přidávání uživatelského účtu. Z následující ukázky vyplývá, že pokud uživatel zvolí dostatečně silné heslo a informační systém použije funkci salt a hash, tak by pro útočníka mělo být nadlidským úkolem získat přístupové údaje do informačního systému Decstore.

10

10

TESTOVÁNÍ

61

Testování

Testování výsledného produktu je nedílnou součástí vývoje softwaru. Pomáhá odhalit poslední problémy a nedostatky jednotlivých částí aplikace a snaží se předejít budoucím problémům při nasazení produktu. Testování se provádí i z důvodu zjištění a kontroly kvality produktu a obecně patří do procesu verifikace a validace. Testování může probíhat během celého životního cyklu aplikace. Existuje hodně způsobů testování přes ruční testy až po tvorbu testovacích skriptů. Testování výsledného produktu by neměl provádět tvůrce popřípadě tvůrci. Je obecně známo, že tvůrce pohlíží na svůj program jinak a dokáže předpovídat jeho chování. Pro testování informačního a rezervačního systému společnosti Decstore budou použity principy heuristické analýzy a kognitivního průchodu. Zároveň bude systém testován ze strany zákazníka i ze strany zaměstnance. Cílem testování bude zjištění obtížnosti a proveditelnosti zadaného cíle a intuitivnost řešení za pomoci dané aplikace. Tester se bude snažit nalézt nedostatky a nejasnosti v dané aplikaci. • Úkony testované u zákazníka v rezervačním systému: 1. Registrace nového zákazníka 2. Změna přihlašovacích údajů nového zákazníka 3. Za pomoci navigace a levého menu nalézt a vložit do košíku Svícen skleněný čirý duo/oboustranný 4. Za pomoci filtru nalézt a vložit do košíku čirý etažér nad 200 Kč 5. Změnit počet kusů u libovolného zboží 6. Dokončit objednávku podle libovolných potřeb • Úkony testované u zaměstnance v informačním systému: 1. Přihlásit se do systému 2. Upravit doručovací adresu zákazníka 3. Zobrazit libovolnou nepředanou zakázku 4. Nahrát do zakázky libovolný *.pdf soubor, otevřít ho a potom ho smazat 5. Všem nedokončeným částem zakázky vytvořit jeden výkon a určit sebe jako zaměstnance i jako vedoucího a zaškrtnou obě notifikace. 6. Dokončit výkon a zkontrolovat svou emailovou adresu jestli byla notifikace doručena 7. Přidat nového brigádníka a vyzkoušet se přihlásit na jeho účet. 8. Vymazat jeho účet

62

10

10.1

TESTOVÁNÍ

Výsledky testování

Nejdříve byly k testování vybrány tří osoby, které budou testovat stranu zákazníka a tří osoby, které budou simulovat zaměstnance. Optimální počet lidí, kteří by měli testovat je podle (Nielsen, 1993) u heuristické analýzy tři až pět. Záleží na rozsahu a významnosti softwaru. Během testování byly sepisovány poznatky hodnotitelů a podle možností byla udělána taková opatření, aby byl daný problém odstraněn. V tabulkách 1 a 2 lze vyčíst daný problém, závažnost problému, při kterém kroku problém nastal a výsledné řešení použité k odstranění problému. Kroky, které nejsou zapsány v tabulkách, probíhaly bez problému. Tabulka 1: Výsledky testování zákazníka

Číslo úkonu

Závažnost problému

1

závažné

1

zanedbatelné

5

nezanedbatelné

6

zanedbatelné

Důvod

Oprava

v souboru index.php nelze rolovat neinformovanost uživatele o úspěšné registraci v košíku není částka za všechny položky neinformovanost uživatele o úspěšném nákupu

oprava CSS atributu overflow přidána hláška po registraci přidán součet všech položek košíku přidána hláška po nákupu

Tabulka 2: Výsledky testování zaměstnance

Číslo úkonu

Závažnost problému

3

nezanedbatelné

5

nezanedbatelné

6

zanedbatelné

6

závažné

Důvod uživatel se nemůže najít nepředanou zakázku uživatel se neorientuje jestli je v zakázce, části zakázky nebo výkonu v notifikaci v e-mailu není jasný název zakázky Při dokončení výkony nastal error

Oprava proškolit zaměstnance u názvů je klíčové slovo zakázka, část zakázky nebo výkon úprava textu notifikace stav výkonu kolidoval se stavem části zakázky (opraveno)

11

DISKUZE A ZÁVĚR

11 11.1

63

Diskuze a závěr Diskuze

Tvorba informačního a rezervačního systému je komplexním problémem. Skládá se z mnoha elementárních úkonů. Bez funkčnosti jedné části můžeme ztratit funkčnost celého systém. Takovými příklady může být připojení a funkčnost databáze, využití session a podobně. Proto se snažíme tyto společné stěžejní části eliminovat a rozsáhlý systém dekomponovat do jednotlivých částí s vlastní funkcionalitou. Tento proces je samozřejmě zdlouhavý, ale přináší tížený úspěch. Informační systém je dokonalým příkladem využití jednotlivých oddělených sekcí. Systém pro společnost Decstore se skládá ze sekcí, které pracují odděleně a bez společných závislostí. To do budoucna umožňuje přidávat i odebírat další moduly, bez nutnosti dalšího zásahu. IS poskytuje uživateli spoustu možností a nástrojů, které může v jednu chvíli použít. Opačným případem je fungování rezervačního systému. Tam je uživatel naváděn jedním přesným směrem. Snaží se uživateli poskytnout ideální nákup, který je dán přesnou posloupností stránek a kliknutí, po kterých získá to, co právě požaduje. Výjimkou je samozřejmě řazení, vyhledávání a filtrování, které uživateli poskytuje potřebnou uživatelskou přívětivost. Do budoucna se plánuje i řada dalších vylepšení. Prioritou zůstává přechod informačního systému na zabezpečený síťový protokol HTTPS. Dále je v IS plánována tvorba finančních přehledů a také tvorba tiskových sestav smluv a faktur. V rezervačním systému bude prioritou dokončení odkazů nacházejících se v patičce stránky. Jejich dosavadní nedokončení je způsobeno vytížením společnosti Decstore, která nemá tolik času dodávat podklady pro jejich tvorbu. Důležité je také zmínit, že v této fázi vývoje není rezervace produktů časově omezená. Společnost Decstore řeší tento problém ve svém skladovém systému. V období podzimu a zimy se počítá s přesunutím této funkce do rezervačního systému, kdy vytíženost svatebních agentur není tak vysoká.

11.2

Závěr

Tvorba projektu započala v prosinci roku 2014. Skládala se z konzultací s vedením firmy, kde byly utřiďovány první představy společné spolupráce. Samotná práce se skládala z klasických posloupností. Po dokončení první části se mohlo pokračovat částí druhou. Práce postupovala přes specifikaci požadavků k návrhu, implementaci a testování výsledků. Během práce byly výsledky konzultovány s firemním grafikem a také poskytovatelem hostingu. Projekt splňující rozsah této práce byl dokončen začátkem května 2015. Od té doby probíhá vylepšování a testování, aby mohla být koncem června nasazena ve firmě beta verze. Během vývoje se požadavky na systém několikrát změnily, což zapříčinilo hned několik problémů. Dokonce i změnu návrhu ERD. Naštěstí tyto komplikace na-

64

11 DISKUZE A ZÁVĚR

staly na začátku a vyplývaly pravděpodobně z neznalosti tvorby takovýchto systémů na straně vedení společnosti. V průběhu práce už nebyly zaznamenány žádné velké nesrovnalosti. Občas panovaly rozdílné názory, které se ale postupem času vždy podařilo vyřešit. Mým cílem bylo vycházet společnosti Decstore vstříc a vytvořit systém podle jejich představ, přestože jsem řešení navrhované firmou nepovažoval vždy za nejschůdnější a navrhoval jiná řešení. Zpětně hodnotím spolupráci kladně. Osobně jsem za zkušenosti získané při vytváření projektu rád a považuji ho za dobrý přínos do budoucna. Tvorbu tohoto projektu mi usnadnily znalosti získané z předmětů, jako jsou databázové systémy, informační systémy a podobně. Zadané cíle diplomové práce se podařily úspěšně splnit. Oba systémy jsou schopny vykonávat požadované funkce a softwarová podpora podnikatelských záměrů společnosti Decstore s.r.o. je tak plně zabezpečena.

12

12

LITERATURA

65

Literatura

Abra. Informační systém pro firmy všech velikostí. [online]. 2013 [cit. 2015-05-09]. Dostupné z: http://www.abra.eu/informacni-systemy. Adaptic. Internetový slovníček. [online]. 2005, aktualizováno 2013. [cit. 2013-0426]. Dostupné z: http://www.adaptic.cz/znalosti/slovnicek/. Altus Vario. Software pro malé a střední firmy. Software pro malé a střední firmy [online]. 2014 [cit. 2015-05-09]. Dostupné z: http://www.vario.cz/vybersoftware/velikost-firmy/mala-firma/. Darie C. AJAX a PHP – tvoříme interaktivní webové aplikace profesionálně. Brno: Zoner Press, 2006. 320 s. ISBN 80-86815-47-1. Directis Acmark. Popis systému. [online]. 2015 [cit. 2015-05-09]. Dostupné z: http://www.directis.cz/directis/. Edwards C., Ward J., Bytheway A. The essence of information systems. 2nd ed. New York: Prentice Hall, 1995, x, 211 p. ISBN 01-335-9308-8. Foresman Timothy W. The history of geographic information systems. Upper Saddle River, NJ: Prentice Hall PTR, c1998, xviii, 397 p. ISBN 0138621454. Gourley, D., Totty, B. HTTP: the definitive guide. 1st ed. Sebastopol, CA: O’Reilly, 2002, xviii, 635 p. ISBN 15-659-2509-2. Garrett Jesse J. Adaptive path. Ajax: A New Approach to Web Applications. [online]. 2005 [cit. 2015-05-05]. Dostupné z: http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/. Han J., Kamber M., Pei J. Data mining: concepts and techniques. 3rd ed. Waltham: Morgan Kaufmann, c2012, xxxv, 703 s. Morgan Kaufmann series in data management systems. ISBN 978-0-12-381479-1. Hronek J. Informační systémy. [online]. Olomouc 2007 [cit. 2015-05-14]. Dostupné z: http://phoenix.inf.upol.cz/esf/ucebni/infoSys.pdf. Univerzita Palackého. Jícha R. Interval salted hash. online] 2005 [cit. 2015-03-29]. Dostupné z: http://www.interval.cz/clanky/salted-hash-dalsi-krok-ke-zvysenibezpecnosti/. Kofler M., Öggl B. PHP 5 a MySQL 5: průvodce webového programátora. Vyd. 1. Brno: Computer Press, 2007, 607 s. ISBN 978-80-251-1813-9. Lacko L. Oracle : správa, programování a použití databázového systému. 1. vyd. Brno: Computer Press, 2002. 464 s. Rychle a jistě - databáze. ISBN 80-7226699-3.

66

12

LITERATURA

Molnár Z. Efektivnost IS/IT. [online]. 2000 [cit. 2013-05-20]. Dostupné z: http://gis.vsb.cz/GIS_Ostrava/GIS_Ova_2000/Sbornik/Molnar/Referat.htm. Money S3. Money S3: účetní program pro menší společnosti a živnostníky. [online]. 2015 [cit. 2015-05-09]. Dostupné z: http://www.money.cz/money-s3/. Nielsen J. Usability engineering. Boston: Academic Press, c1993, xiv, 358 p. ISBN 0125184050. Pospíchal V. Druhy informačních systémů. [online]. 2003 [cit. 2015-05-08]. Dostupné z: http://pit.wz.cz/informacni-systemy.php. Powell T. Ajax the complete reference. New York: McGraw-Hill, 2008. ISBN 00715-9662-3. Provost F. Data science for business: what you need to know about data mining and data-analytic thinking. 1st ed. Sebastopol: O´Reilly, 2013, xviii, 384 s. Data Science/Business. ISBN 978-1-449-36132-7. Rana M. History of information systems. [online]. 2001 [cit. 2015-05-08]. Dostupné z: http://www.uh.edu/ mrana/try.htm. Rábová I. Podnikové informační systémy a technologie jejich vývoje. V Tribun EU vyd. 1. Brno: Tribun EU, 2008, 139 s. ISBN 978-807-3995-997. SAP Business One. Podnikový informační systém SAP Business One. [online]. 2013 [cit. 2015-05-09]. Dostupné z: http://www.elegis.cz/reseniprodukty/podnikovy-informacni-system-sap-business-one/. Signys. Podnikový informační systém Signys. [online]. 2014 [cit. 2015-05-09]. Dostupné z: http://www.signys.cz/podnikovy-informacni-system. Sodomka P., Klčová H. Informační systémy v podnikové praxi. 2. vyd. Brno: Computer Press, 2010. 501 s. ISBN 978-80-251-2878-7. Šmíd V. Management informačního systému. [online]. 2002 [cit. 2006-12-04]. Dostupné z: http://www.fi.muni.cz/ smid/managis.html . Thorp J. Information paradox: realizing the business of information technology. S�l: McGraw-Hill, 1998. ISBN 0071342656. Winter A., Haux A. Health information systems: architectures and strategies. New York: Springer, 2011. 337 s. ISBN 978-1-84996-440-1.