Informační systém pro společnosti zabývající se vývojem webu. Petr Kulich

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Informační systém pro společnosti zabývající se vývojem webu Petr Kulich

Vedoucí práce: Mgr. Jan Stoklasa

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 26. května 2010

iv

v

Poděkování Děkuji všem profesorům, kteří se jakýmkoliv způsobem podepsali na mém vzdělání na Elektrotechnické fakultě.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 26. 5. 2010

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

viii

Abstract This Bachelor’s project arose from a need for transparency website creation. It was mainly about fixing client requirements on the final product and approval of work done, such as graphics. Very often the case that a customer changes very significantly its requirements and thus leads to cost overruns on the product Web site creator. The information system should eliminate the above problems that the customer must approve each step of development. Subsequently provide the basis for any negotiations on price increases for changes to the award. In addition to create the transparency requirements to track the sites that are managed and charge according to the needs of the job and financial trends graphically represent the creator of the Web (earnings in production and management of sites).

Abstrakt Tato Bakalářská práce vznikla na základě potřeby zprůhlednit tvorbu internetových stránek. Jednalo se hlavně o zafixování požadavků zadavatele na výsledný produkt a schvalování vykonané práce, jako je např. grafika. Velice často se totiž stává, že zákazník mění zásadně své požadavky, a tím dochází k prodražování produktu na straně tvůrce webu. Tento informační systém by měl výše uvedené problémy odstranit tím, že zákazník musí jednotlivé kroky vývoje schválit. Následně poskytne podklady pro případná jednání o navýšení ceny při změnách zadání. Kromě zprůhlednění tvorby umožňuje sledovat požadavky na weby, které jsou spravovány a vyúčtovat, dle potřeby odvedenou práci a graficky vyobrazit finanční trendy tvůrce webu (výdělky v oblastech tvorby a správy internetových stránek).

ix

x

Obsah 1 Úvod

1

2 Popis problému, specifikace cíle

3

3 Analýza a návrh řešení 3.1 Podrobná analýza projektu . . . . . . . . 3.1.1 FURPS analýza . . . . . . . . . . . 3.1.2 Případ užití . . . . . . . . . . . . . 3.1.3 SWOT analýza . . . . . . . . . . . 3.1.4 Analýza rizik - ze strany zadavatele 3.1.5 Analýza rizik - projektová rizika . 3.1.6 Volba implementačního prostředí . 3.1.7 Časový harmonogram . . . . . . . 4 Realizace 4.1 Návrh databáze . . . . . . . 4.2 Přihlašování . . . . . . . . . 4.2.1 Vstup do systému . . 4.3 Správa uživatelů . . . . . . 4.4 Projekty . . . . . . . . . . . 4.5 Spravované weby . . . . . . 4.6 Vyúčtování odvedené práce 4.7 Grafické statistiky . . . . . 4.8 Ověření vstupních dat . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 5 5 7 8 8 9 10 11

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

13 13 14 16 16 19 20 21 23 24

5 Testování 5.1 Kontrola vzhledu aplikace v různých prohlížečích 5.2 Funkčnost hypertextových odkazů . . . . . . . . . 5.3 Uživatelské testy . . . . . . . . . . . . . . . . . . 5.4 Kontrola formulářů . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

25 25 26 27 27

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

6 Závěr

29

A Seznam použitých zkratek

33

B Vzory tištěných dokumentů

35

xi

xii

OBSAH

C Instalační a uživatelská příručka 37 C.1 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 C.2 Způsob zápisu příručky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 C.3 Uživatelská příručka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 D Obsah přiloženého CD

41

Seznam obrázků 3.1 3.2

Případ užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Harmonogram projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 4.2 4.3 4.4 4.5

Návrh databáze . . . . . . . . . . . . . . . . . . . . . . . . Formulář pro vložení nového a editaci stávajícího uživatele Rozhraní pro přístup k funkcím jednotlivých projektů . . Formulář pro vložení webu do správy . . . . . . . . . . . . Ukázka grafického výstupu . . . . . . . . . . . . . . . . . .

5.1

Ukázka výstupu při testování odkazů . . . . . . . . . . . . . . . . . . . . . . . 26

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

15 17 19 21 24

B.1 Vzor faktury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.2 Vzor objednávky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

xiii

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 3.1 3.2 3.3 3.4 3.5 3.6

SWOT analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Riziko - nedostatečné adaptability na změny . . . . . . . . . . . . . Riziko - nasazení systému do provozu po plánovaném termínu . . . Riziko - nedostupnost systému po jeho nasazení . . . . . . . . . . . Riziko - změna požadavků v průběhu práce na systému . . . . . . . Riziko - větší náročnost systému, než bylo původně předpokládáno

xv

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. 8 . 8 . 9 . 9 . 9 . 10

xvi

SEZNAM TABULEK

Kapitola 1

Úvod S velkým rozvojem Informačních a komunikačních technologií dochází k potřebě optimalizovat veškeré práce, které jsou s výpočetní technikou spojeny. Na základě zkušeností s tvorbou internetových stránek a s problémy, které tuto tvorbu provází, jsem se rozhodl vytvořit Informační systém, který by měl některé nešvary odstranit a zároveň zprůhlednit celý proces tvorby webu. V průběhu tvorby webu se často objevují problémy, které pramení z neznalosti problematiky ze strany zadavatele. Ač se na úvodních jednáních vždy domluví určitý postup a parametry, jak bude budoucí webová prezentace vypadat a jaké bude mít funkce, přesto často dochází v průběhu práce ke změnám zadání. Je to pravděpodobně způsobeno tím, že si zadavatel nedovede přesně představit dopady svých rozhodnutí. A až poté, co mu je představena testovací verze produktu, si uvědomuje, že chce provést zásadní změny v zadání. Někdy se i stane, že se webová stránka zásadním způsobem přepracuje a zadavatel zjistí, že pracovník firmy měl předtím pravdu a použije se původní verze. Výše uvedené problémy způsobují prodražování tvorby aplikací, ač se jedná o webovou stránku nebo komplexní software pro firmu. Já jako tvůrce webu jsem dříve vše řešil ústní dohodou, protože jsem nepovažoval za důležité sepisovat sáhodlouhá ujednání o výsledné podobě produktu. Po čase jsem zjistil, že to není možné tímto způsobem řešit ani u malých webů a přikročil jsem k papírové podobě objednávky, kde se specifikují základní parametry stránek. Objednávka odstranila potíže s označením některých činností jako vícepráce, kde je požadováno navýšení částky na vytvoření webu. Jednalo se např. o případy, kdy v prvních fázích byl požadován určitý počet stránek a vodorovná navigace. Po dokončení zadavatel zjistil, že je potřeba počet stránek navýšit a zároveň s tím počet odkazů ve vodorovné navigaci, která již rozšířit nešla. Celý projekt, tedy musel být upraven pro svislou navigaci. To obnáší nejen čas na nakódování webu, ale znovu práci grafika, který musí celý design přepracovat. Po těchto zkušenostech jsem se rozhodl vytvořit Informační systém, který poskytne poklady, při případných jednáních o splnění cílů vyvíjeného produktu. Vzhledem k tomu, že vytvořením stránek vše nekončí, IS obsahuje i funkce pro následnou správu webu a přehledné grafické statistiky rozbrazující trendy finančního rozvoje nebo poklesu firmy. Zákazníkum grafický přehled poskytuje přehled o investovaných prostředcích.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle Jak již bylo naznačeno v úvodu, bylo potřebné nalézt řešení, které zprůhlední tvorbu internetových stránek, umožní jednoduše řešit schvalovací procesy v jednotlivých etapách vývoje a poskytne podklady pro případná jednání o změnách v projektech. Výsledné řešení bylo navrhováno pro mé osobní potřeby, které vychází ze zkušeností s návrhem malých internetových projektů (zpravidla do 15 stran obsahu) nebo dílčích úkonech na větších webech. Pro dané požadavky jsem nenalezl žádný odpovídající systém, který by pokryl požadované potřeby. Bylo by samozřejmě možné použít některý z groupwarových systémů, který by se modifikoval např. eGroupWare. To by mělo za následek, že by systém obsahoval celou řadu funkcí, které by se, alespoň ze začátku, nevyužívaly. Z toho důvodu jsem se rozhodl vytvořit systém vlastní, který se bude v budoucnu rozšiřovat na základě vzniklých potřeb. Po opominutí pracnosti této varianty, bude mít takovéto řešení i celou řadu výhod. Mezi nejvýznamější patří, že řešení bude přesně odpovídat kladeným požadavkům a zároveň bude jednodušší doplňování funkčnosti, protože správa vlastního zdrojového kódu je značně jednodušší. Výstupem mé práce by měl být Informační systém, který by potlačil případné neshody v tom, co bylo nebo nebylo objednáno. Již krátkou dobu používám papírovou formu objednávky, kde se přesně specifikuje, jak bude výsledná internetová stránka koncipována. Jedná se o objednávku, která je do určité míry podobná dotazníkovému průzkumu, kde jsou specifikovány nejdůležitější funkce webové stránky. To odstranilo určité nesrovnalosti ke kterým docházelo. Tato objednávka je se zákazníkem podepisována zpravidla na úvodních jednáních. Postupem času se opět objevily nedokonalosti tohoto způsobu. Jedná se o to, že člověk, aby provedl kvalitní rozhodnutí, potřebuje vždy určitý čas na to, aby si mohl řádně promyslet dopady. Zde si dovolím provést drobný příměr: Jsou určité oblasti podnikání, které jsou založeny na rychlých rozhodnutích zákazníka. Pokud by se zákazník rychle nerozhodl, bylo by to klíčem neúspěchu pro obchodníka nabízejícího produkt nebo službu. Zde jsem narážel na obchodní praktiky podomních prodejců a prodejců po telefonu. Tvorba webu a obecně tvorba softwaru určitě nespadá do kategorie obchodu, který je založen na nátlaku a rychlých rozhodnutích kupujícího resp. zákazníka. To je důvodem, proč je nutné nechat zákazníkovi po podepsání objednávky ještě určitý čas na rozmyšlenou, zda nechce v úvodním zadání provést změny. Může se to zdát jako banalita, ale většinou zákazník ví, že chce stránky, ale veškerá vysvětlení, co a jak se dělá, obdrží až na úvodním jednání

3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

(a zde dojde většinou i k podpisu objednávky). A právě proto je zde nutný čas na ono domyšlení. Tyto myšlenky ve mě podnítily potřebu vytvořit systém, který bude umožňovat stávající postup objednávání, ale zároveň vytvoří určitý prostor, aby si zákazník mohl vše promyslet nebo prodiskutovat ve svém okolí. To v praxi znamená, že na úvodní schůzce bude podepsána objednávka se specifikací produktu. Tato objednávka je přenesena do systému a zákazník má prostor se k zadání ještě vyjadřovat a následně objednávku zafixovat (schválit). Obdobný postup schvalování bude aplikován na grafický návrh, HTML šablonu a dokončení celého webu. Jak by se mohlo z předchozího textu zdát, mělo by se jednat pouze o určitý objednávkový systém, ale to je skutečně pouze zdání. Výše uvedený text je pouze popisem, který podnítil potřebu vytvoření určitého rozhraní mezi zákazníkem a tvůrcem webu. Žádný projekt vetšinou nekončí jeho předáním a vyúčtováním, ale je nutná jeho následná údržba a správa, účtování odvedené práce, sledování expirace domén a sledování výkonnosti firmy. A to jsou všechno věci, který by měl nově vytvářený systém postihnout. Obecné požadavky na systém: • Snadná obsluha • Přístup z kteréhokoliv místa, kde je k dispozici připojení k internetu • Umožnění přístupu k datům pouze oprávněným osobám • Uchování požadavků na projekty a schvalování průběhu prací • Zadávání požadavků na aktualizace stránek, které jsou spravovány • Grafické zpracování statistik Podrobné požadavky jsou rozvedené v následující kapitole.

Kapitola 3

Analýza a návrh řešení S ohledem na kladené obecné požadavky přístupu vyvstaly dvě základní možnosti řešení uvedeného problému. 1. Vytvoření běžné aplikace, která by byla provozována v interní síti firmy, kam by se uživatelé mohli přihlašovat pomocí VPN tunelu. 2. Vytvoření webové aplikace, která by byla lehce přístupná pouze po zadání přihlašovacích údajů. V prvním případě by byl přístup zákazníků ztížen nutností vybudování tunelu. Zároveň by museli dvakrát zadávat přihlašovací údaje (pro vybudování tunelu a pro přístup na server). Bylo by nutné před připojením k serveru zadávat prostředky lokálního počítače, které budou chtít využívat po připojení k serveru interní sítě. Dalším důvodem, který ztěžoval implementaci tohoto řešení, byla nedostupnost počítače, který by zastával funkce serveru a byl dostupný v režimu 24/7. Tento systém je navrhován pro malou firmu, kde by dodatečné náklady způsobily výrazné navýšení potřebného rozpočtu na chod firmy. S ohledem na výše popsané nevýhody byla tato varianta zavržena. Další kroky analýzy směřovaly již pouze k vytvoření aplikace, která bude přístupná přes internet a uživatelé se k ní budou moci dostat pouze za využití připojení k internetu, internetového prohlížeče a znalosti přístupových údajů. Pro přesné stanovení cílů byla provedena podrobná analýza.

3.1 3.1.1

Podrobná analýza projektu FURPS analýza

Funkčnost: • Snadná obsluha. • Vstup do systému ze strany zaměstnance vývoje i zadavatele. • Zobrazení patřičných údajů na základě uživatelských práv a zadaných zakázek.

5

6

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

• Možnost vstupu bez omezení místem. • Vkládání požadavků na nové internetové stránky. • Vkládání vytvořené grafiky pro jednotlivé projekty. • Možnosti komentářů ze strany zadavatele. • Schvalování jednotlivých kroků vývoje. • Evidence spravovaných internetových stránek. • Vkládání požadavků na aktualizace k internetovým stránkám, které jsou evidovány ve správě. • Evidování doby zpracování jednotlivých požadavků. • Možnost vystavení dokladu o provedené práci. • Doklady a vstupní prvky musí co nejvíce odpovídat již realizovaným tištěným formulářům (pokud jsou k dispozici). • Grafické zpracování statistik, které budou umožňovat sledovaní ekonomických trendů firmy. • Sledování a uchování expirace domén, které jsou evidovány ve správě webu. Použitelnost: • Funkční ve všech běžně požívaných prohlížečích (Internet Explorer od verze 7 včetně, FireFox a Opera). Spolehlivost: • Dostupnost služby by měla být minimálně 98% času, 24 hodin denně. • Žádné chyby znemožňující nebo omezující práci v systému. • V případě nahlášení chyby je nutné zajistit její odstranění do 24 hodin. Výkonnost: • K systému by měly mít přístup řádově jednotky uživatelů. Nepočítá se, že by najednou v systému pracovalo více jak 5% z jeich celkového počtu. • Řádově desítky záznamů a přístupů za den. Bezpečnost: • Systém bude zabezpečen proti neoprávněnému přistupu k uloženým datům. • Vzhledem k rozmanitému přístupu uživatelů k systému nebude aplikována filtrace uživatelů na základě IP adresy.

3.1. PODROBNÁ ANALÝZA PROJEKTU

3.1.2

7

Případ užití

Na základě podrobných požadavků a pro úplnost zde uvádím případ užití, který ilustruje dané uživatelské role a funkce, ke kterým budou mít přístup.

Obrázek 3.1: Případ užití

8


3.1.3

SWOT analýza

SWOT analýza

Příležitosti

Hrozby

Silné stránky

Slabé stránky

- dostupnost dat z libovolného počítače připojeného k internetu

- předávání informací pouze v papírové podobě

- nízké náklady na provoz a údržbu

- zpoždění informací

- zefektivnění provozu

- dochází k předávání neaktuálních informací

Tabulka 3.1: SWOT analýza

3.1.4

Analýza rizik - ze strany zadavatele

Popis rizika

Nedostatečná adaptabilita na změny

Stav

Nastalo

Vlastník

Zadavatel

Pravděpodobnost výskytu

50%

Dopad

Neprůkazné začleňování změn

Plán pro potlačení rizika

Nasazení vhodného informačního systému

Tabulka 3.2: Riziko - nedostatečné adaptability na změny


Popis rizika

Nasazení systému do provozu po plánovaném termínu

Stav

Potencionální

Vlastník

Dodavatel


20%

Dopad

Prodloužení stávajícího stavu


Vytvoření kvalitního plánu nasazení zdrojů

Tabulka 3.3: Riziko - nasazení systému do provozu po plánovaném termínu Popis rizika

Nedostupnost systému po jeho nasazení

Stav

Potencionální

Vlastník

Dodavatel


5%

Dopad

Nedostupné informace a nemožnost jejich aktualizace


Provádět úpravy systému v nočních hodinách

Tabulka 3.4: Riziko - nedostupnost systému po jeho nasazení

3.1.5

Analýza rizik - projektová rizika

Popis rizika

Změna požadavků v průběhu práce na systému

Vlastník

Dodavatel


15%

Dopad

Prodloužení realizace systému Neodevzdání Bakalářské práce v řádném termínu


Zajistit základní funkčnost systému a nedůležité změny odložit

Tabulka 3.5: Riziko - změna požadavků v průběhu práce na systému

9

10


Popis rizika

Větší náročnost systému, než bylo původně předpokládáno

Vlastník

Dodavatel


30%

Dopad

Nedodání systému v požadovaném termínu Dodání systému v nižší jakosti Neodevzdání Bakalářské práce v řádném termínu


Kvalitní úvodní studie

Krizový plán

Přesčasová práce na projektu

Tabulka 3.6: Riziko - větší náročnost systému, než bylo původně předpokládáno Rizika ze strany zadavatele a projektová rizika byla shrnuta v tabulkách 3.2 - 3.6. V tomto případě bylo členění vlastníka rizik vytvořeno uměle. O umělé členění se jedná proto, že projekt je vyvíjen pro mou vlastní potřebu a pro účely naplnění požadavků Bakalářské práce, takže s ohledem na rozčlenění rizik působím v roli zadavatele i dodavatele. Umělé členění vlastníka rizika bylo zvoleno, aby rozdělení odpovídalo běžně prováděné zakázkové tvorbě softwaru.

3.1.6

Volba implementačního prostředí

Pro vývoj webové aplikace je v dnešní době dostupná celá řada programovacích (skriptovacích) jazyků, kde mezi nejvýznamnější pravděpodobně patří: • ASP • ASP.NET • PHP • JSP A v návaznosti na výše uvedené jazyky připadají možnosti pro ukládání dat: • ukládání dat do souboru • MySQL • PostgreSQL • MS Access • MS SQL Server


11

Určitě nelze provést jednoznačné vyhodnocení, který z výše uvedených jazyků je pro implementaci informačního systému nejlepší. Volba byla provedena na základě určitých zkušeností s jedním z nich a podle již předplaceného hostingu webu, kde bude IS provozován. Na serveru, kde bude informační systém v prvních fázích provozován, je nainstalovaný Linux a webový server Apache. Zde je tedy jasný důvod pro výběr skriptovacího jazyka PHP. V návaznosti na tuto volbu je použit pro ukládání dat databázový systém MySQL. Jedná se v podstatě o standardní volbu v případě použití PHP, protože tento jazyk vyniká poměrně pevnou vazbou na tento databázový systém. Po výběru patřičného jazyka pro implementaci IS by měly další kroky vést k patřičnému výběru aplikace pro ladění skriptů popř. k volbě frameworku. Tento krok byl v tomto případě vynechán. Jsem zastáncem přímého zapisování v některém z textových editorů a následného ladění pomocí podmínek a výpisu přímo ve zdrojovém kódu. Z tohoto důvodu jsem pro zapisování kompletního zdrojového kódu použil freewarový textový editor PSPad viz.[9]. Tento editor umožňuje vytváření kódu v různých programovacích jazycích s patřičným zvýrazňováním syntaxe. Plně pokryl celé spektrum jazyků, které jsem pro potřeby systému použil. Celkem bylo použito pět jazyků pro vytvoření systému. Jednalo se o XHTML, CSS, JavaScript, PHP a dotazovací jazyk SQL.

3.1.7

Časový harmonogram

Pro vyhotovení projektu jsem vypracoval harmonogram tvorby jednotlivých částí. Tak jak se u projektů někdy stává, byl tento harmonogram dodržen s určitým zpožděním. Celkový plán byl koncipovaný na vypracování projektu do první třetiny května. Tento termín byl vybrán s určitou rezervou na odevzdání Bakalářské práce. Celkem byl plán podhodnocen o deset dní. Harmonogram je na obr.3.2.

12


Obrázek 3.2: Harmonogram projektu

Kapitola 4

Realizace Pro realizaci byly zvoleny jazyky XHTML, CSS, JavaScript a PHP (verze 5). Jako databázový systém jsem využil MySQL (také verze 5). V první fázi projektu jsem vytvořil šablonu budoucího vzhledu, který byl otestován pomocí webové aplikace browsershots.org [4]. Další podrobnosti o této aplikaci budou zmíněny v následující kapitole, která pojednává o testování vytvořeného programu. Šablona byla vytvořena pomocí XHTML a CSS. Při psaní šablony jsem se inspiroval knihou Mistrovství v CSS viz.[1]. Aby byly dodrženy standardy tvorby webových aplikací nebo obecně internetových stránek, skládala se ze dvou souborů kde první byl zdroj XHTML, který se odkazoval na šablonu vzhledu CSS. Toto je běžný způsob tvorby, aby se omezilo, nebo v ideálním případě úplně zamezilo, vkládání prvků vzhledu do XHTML dokumentu, který by měl vyjadřovat sémantiku stránky. Takovéto rozdělení se v budoucnu odmění ve snadné snadné úpravě vzhledu. Následně jsem šablonu rozdělil pro použití v PHP, kde je výsledná stránka poskládaná z fragmentů výchozí šablony. Rozdělení jsem provedl na 4 části - hlavičku, navigaci, obsah stránky a patičku. Rozdělení na jednotlivé části je velice účelné, pokud by v průběhu času došlo ke změnám v některé častí. Např. pokud by došlo ke změně loga, nemusí se změna provádět ve všech souborech, ale provede se pouze ve zdrojovém souboru hlavičky. To samé platí pro rozšiřování navigace. U navigace je toto dělení daleko důležitější, protože navigace je složena ze dvou částí. První část je hlavní navigace a druhá je podnavigace, která je odlišná pro každou sekci, kde se uživatel právě nachází. Každý z těchto dvou prvků má dvě verze. Každá z verzí se používá na základě zanoření souboru ve stromové struktuře webu. Další kroky tvorby již vedly k zajištění požadovaných funkcí informačního systému.

4.1

Návrh databáze

Pokud mám být zcela upřímný, tak jsem si myslel, že začnu psát, aniž bych si musel databázi nakreslit. Při tvorbě uživatelů a uživatelských rolí, tato domněnka zafungovala velice dobře. Po dosažení dalších kroků implementace mi bylo jasné, že takto to nadále není možné dělat. Zapátral jsem v paměti a zavzpomínal, jaké nástroje jsem používal pro návrhy v průběhu studia. Jasnou volbou pro mě byla aplikace ER- modelář, ve které jsem si nakreslil návrh

13

14

KAPITOLA 4. REALIZACE

obr.4.1, který je k dispozici na následující stránce. V tomto případě jsem ho použil skutečně pouze jako „kreslítko“. Odkaz na aplikaci ER-modelář zde neuvádím, protože byla dostupná pouze po zápisu předmětu Databázové systémy a již nejsem schopen funkci tohoto odkazu ověřit.

4.2

Přihlašování

Přihlašování bylo prvním krokem implementace IS. Pro první experimenty jsem vytvořil tabulku uživatelů, kde jsem založil jediného uživatele. Veškeré tabulky a přidávání experimentálních dat jsem prováděl přes rozhraní provozovatele webhostingových služeb MySQL Forpsi. Jedná se o velice oblíbenou aplikaci pro správu MySQL databází, která se jmenuje phpMyAdmin. Pro přihlašování jsem jako uživatelské jméno zvolil adresu elektronické pošty. Hlavním důvodem byla jednoznačnost tohoto identifikátoru a obejití vymýšlení uživatelských jmen, která by si uživatelé museli pamatovat. Jedná se o postup, který jsem volil na základě funkce systému. Do tohoto systému se není možno registrovat, ale uživatel je do systému zadán po sjednání některé z nabízených služeb. Po zavedení do systému je již možná editace uživatelských dat ze strany uživatele. Hesla nejsou v databázi ukládána v původním tvaru, ale je z nich vytvořen MD5 hash. Vytvoření hashe je ošetřeno pomocí funkce, které je předán jako jediný argument řetězec reprezentující heslo uživatele. Výstupem funkce je zde zmíněný hash. Tato funkce vrací pro všechny vstupní hodnoty hash konstantní délky. Po přihlášení jsou uživatelské údaje uloženy do relace s cookies a při přechodech na další stránky kontrolovány, zda jsou nastaveny a jaké mají hodnoty. Podle těchto hodnot je uživateli povolen nebo odepřen přístup do určité části systému. Tento způsob realizace má oproti samotnému použití pouze cookie podstatnou bezpečnostní výhodu. V případě použítí cookies se do prohlížeče přenášejí veškeré údaje, které jsou následně potřebné pro udržení relace. V případě použití relace s cookie je do souboru cookie ukládáná pouze identifikace relace tzv. Session ID, která slouží pro identifikaci intrernetového prohlížeče, který relaci zahájil. Další potřebné údaje, které jsou zapotřebí k identifikaci klienta jsou uloženy pouze na serveru a nejsou přenášeny do internetového prohlížeče. Platnost cookie je nastavena do doby, než je ukončena relace. To znamená, že je zneplatněna po uzavření okna prohlížeče, ale pokud by uživatel přešel na jinou stránku, aniž by okno zavřel, bude cookie stále platná. To mělo za následek, že by následně mohl pod tímto uživatelským učtem pracovat jiný uživatel, který by měl přístup ke stejnému počítači. K zamezení tohoto bezpečnostního rizika jsem zakomponoval do rozhraní odkaz pro odhlášení. Po kliknutí na tento odkaz jsou odstraněny všechny session proměnné, odstraněna cookie relace a následně je uživatel přesměrován na přihlašovací stránku. Při tvorbě přihlašování jsem vytvořil pomocí objektově orientovaného programování objekt, který slouží pro přístup k databázi a je využívat k přístupu do databáze pro celý systém. Tomuto objektu jsou předávány přihlašovací údaje k databázi, které jsou uložený mimo prostor webové složky na serveru. Uložení přihlašovacích dat mimo webovou složku jsem zvolil s ohledem na zabezpečení přístupových údajů k databázi. Zároveň obsahuje funkce, které jsou využívány pro předání MySQL dotazu a navrácení výsledku dotazu viz. [3].

4.2. PŘIHLAŠOVÁNÍ

15

Obrázek 4.1: Návrh databáze

16

4.2.1


Vstup do systému

Z důvodu ladění a otestování sytému jsem ho umístil na adresu www.spravawebovek.cz/admin. Pro otestování funkčnosti jsou k dispozici následující uživatelské účty: Administrátorský přístup: Uživatelské jméno: [email protected] Heslo: admin Uživatelský přístup: Uživatelské jméno: [email protected] Heslo: noname

4.3

Správa uživatelů

Ve správě uživatelů je umožněno uživatele přidávat, editovat a odstraňovat. Jako povinné položky pro editaci uživatele je jeho jméno, příjmení a adresa elektronické pošty. Pro vložení nového k předchozím přibývá ještě nutnost zadání hesla. Při vkládání nového uživatele je nutné do pole pro zadání hesla a pro ověření hesla zadat řetězce, které mají přesně stejný formát. Tato shoda je před odesláním ověřena pomocí funkce, kterou jsem vytvořil pomocí JavaScriptu. Volbu uživatelských práv jsem nezahrnoval do povinných položek a z bezpečnostních důvodů je implicitně nastaveno oprávnění pro zákazníky. Zadání dalších údajů je pouze dobrovolné, ale to pouze do chvíle, kdy je nutné vystavit doklad o poskytnutých službách (fakturu). Tyto údaje jsem se rozhodl kontrolovat ručně, při vystavování faktury. Tento způsob jsem volil z důvodu, že při „prvokontaktu“ nejsou tyto údaje většinou zjišťovány. Formulář použitý pro zádání nového uživatele a editaci stávajícího je na obrázku 4.2. U editace bylo nutné ošetřit, zda bylo zadáno nové heslo. Kdyby k tomuto ošetření nedošlo a „updatoval“ by se celý řádek tabulky pro daného uživatele, došlo by k tomu, že se pro heslo odesílá hodnota prázdného formulářového prvku. To by mělo za následek (např. pouze po změně telefonního čísla), že dojde k vymazání původního hesla. Celá kontrola je založena na kombinaci kontroly, zda byla v polích pro hesla zadána nějaká hodnota. Pokud ano, je zkontrolována shoda v obou polích a následně odeslán celý formulář. Ve skriptu pro aktualizaci hodnot je provedena aktualizace bez hesla a následně, pokud bylo zadána hodnota nového hesla i aktualizace toho záznamu. Celý systém jsem v prvních krocích realizoval pouze s přístupem administrátora. Po odladění požadované funkčnosti jsem provedl úpravy pro kontrolu uživatelského přístupu. Uživatelský přístup je zde realizován na dvě uživatelské role - zaměstnanec a zákázník. Zaměstnanec má přístup k libovolným datům, která jsou v systému obsažena. Zároveň může přidávat a měnit údaje pro uživatele, nové projekty, weby ve správě a vystavovat faktury pro odvedenou práci. Zákázník si může prohlížet pouze data, která jsou spojena s projekty, které zadal k vypracování nebo s internetovými stránkami, které zadal do správy. Zde si dovolím udělat drobnou odbočku pro objasnění funkce. Každá stránka je poskládána z částí, které jsou představovány z hlavičky, navigace, obsahu stránky a patičky. Jednotlivé části jsou následně poskládány pomocí funkcí do jednoho celku představujícího celou stránku.

4.3. SPRÁVA UŽIVATELŮ

17

Obrázek 4.2: Formulář pro vložení nového a editaci stávajícího uživatele

Toto uspořádání umožňuje flexibilní úpravy jednotlivých položek. Jedná se např. o přidání odkazu do navigace, ale zároveň umožnilo začlenění komplexní kontroly přístupu do systému. V hlavičce systému je začleněna hlavní kontrola ověřující přístup po přihlášení. Tato kontrola ověřuje, zda je nastavena session proměnná přihlášen a obsahuje správnou hodnotu. V případě, že nastavena není nebo obsahuje chybnou hodnotu, je uživatel přesměrován na přihlašovací stránku. Tím je zamezen přístup proti neoprávněnému přistupu do celého systému. Ukázka zdrojového kódu z hlavičky: if ((true != isset($_SESSION[’prihlasen’])) && ($_SESSION[’prihlasen’]!="ok")) { header ("Location: http://". $_SERVER[’HTTP_HOST’]."/admin/index.php"); } Pokud je kontrola v hlavičce uspěšná tj. neproběhne přesměrování na přihlašovácí stránku, jsou zobrazeny další části stránky, které byly popsány v předchozích odstavcích. V obsahu stránky jsem realizoval kontrolu pro ověření oprávněného přístupu po příhlašení do systému. Jedná se o kontrolu, která ověřuje uživatelská práva a v případě přístupu zákazníkem omezuje přístup na patřičné stránky nebo zajišťuje zobrazení relevantních údajů daného zákazníka. Pro omezení zobrazení nepotřebných odkazů po přihlášení zákazníka jsem vytvořil dvě verze navigace. Jednu verzi pro zobrazení po přihlášení zaměstnance, kde jsou dostupné všechny položky a druhou, která zobrazuje relevantní položky pouze pro zaměstnance. Ukázka zdrojového kódu, kde je vidět porovnání proměnné s řetězcem „zam“, který ověřuje přístup zaměstnance. V případě, že je porovnání vyhodnoceno jako nepravdivé, je přepokládán přístup zákazníka.

18


if($_SESSION[’uziv_prava’]=="zam"){ require_once(’navigace.php’); } else{ require_once(’navigacezak.php’); } V dokumentu je na podobném principu vytvořena segmentace zobrazených dat. Pro zaměstnance se zobrazují všechna dostupná data a pro uživatele je na základě identifikátoru uživatele (primární klíč v tabulce uživatelů), omezeno zobrazení pouze na údaje, která jsou s daným uživatelem svázána. Pro lepší představu uváním opět ukázku zdrojového kódu. if($_SESSION[’uziv_prava’]=="zam"){ if($vysledek = $db->dotaz("SELECT ...;")) { zobraz_tabulku($vysledek); } } else{ $uzivatel=$_SESSION[’prihlaseny_uziv’]; if($vysledek = $db->dotaz("SELECT ... WHERE ID_uziv=’$uzivatel’ ... ;")) { zobraz_tabulku($vysledek); } } Aby nemohlo dojít k neoprávněnému přistupu zákazníka na stránku, která je určena pouze pro zaměstnance (v případě znalosti její adresy). Je opět prováděna podobná kontrola, která ověřuje, zda je přihlášen zaměstnance. Pokud je přihlášen zákazník, dochází k přesměrování na přihlašovací stránku a zobrazení výzvy k přihlášení s patřičným oprávněním. if($_SESSION[’uziv_prava’]!="zam"){ header ("Location: http://". $_SERVER[’HTTP_HOST’]. $root . "/index.php"); $_SESSION[’prihl’]="maleopr"; } Veškeré údaje, které používám pro kontrolu práv, jsou nastaveny do proměnných relace ihned po přihlášení uživatele. Tyto proměnné jsou platné do doby odhlášení uživatele nebo uzavření prohlížeče.

4.4. PROJEKTY

4.4

19

Projekty

Sekce projekty se využívá pro založení nového projektu. Zde se projektem míní vytvoření internetové stránky nebo libovolného webu (e-shop, stránka výuky jazyků, atd.). Pro založení nově vytvářeného webu jsem vytvořil formulář, korespondující s papírovou verzí objednávky, která je součástí této práce v příloze B - Vzory papírových dokumentů (obr. B.1). Založení nového projektu jsem podmínil vložením jeho zadavatele, kterého je nutné vybrat z dostupných uživatelů a názvu projektu. Při založení nového projektu je podle jeho názvu rovnou vytvořena patřičná složka pro vložení grafiky k projektu a materiálů pro vytvoření webu od uživatele. Po vytvoření je možné kdykoliv projekt editovat. Pro editaci jsem pouze zakázal změnu názvu projektu. To jsem provedl v návaznosti na výše uvedené vytváření složek při založení nového projektu. Pro další funkce jsem pro každý projekt vytvořil přehledné rozhraní, zpřístupňující všechny funkce pro jednotlivé projekty obr.4.3.

Obrázek 4.3: Rozhraní pro přístup k funkcím jednotlivých projektů

Obsahuje kromě nejdůležitějších informací o projektu také tlačítka, která poskytují přístup k požadovaným funkcím. Jedná se o vložení grafiky návrhu webu, zobrazení podrobností o projektu, připomínky k projektu a rozhraní pro nahrání podkladů ze strany uživatele. Pravděpodobně nejdůležitější funkcí tohoto rozhraní je schvalování jednotlivých kroků vývoje. Schvalování jsem rozdělil na čtyři části. Schválení zadání, grafiky, HTML šablony a dokončeného projektu. Tyto schvalovací kroky jsem volil na základě zkušeností s vytvářením internetových stránek. Zde jsem vycházel z toho, že není vhodné začít zpracovávat grafiku ihned po podepsání objednávky, ale chce nechat určitý čas zadavateli, aby si svá rozhodnutí ještě promyslel. Tento způsob práce systému to umožňuje, protože bude vznikat určitá prodleva, než se uživatel a projekt do systému zavede a než toho zadání schválí. Po tomto schválení se již může začít zpracovávat grafika, ale to jen za předpokladu, že jsou dostupné požadované materiály ze strany zadavatele. Z tohoto důvodu se do parametrů projektu zahrnuje datum do kdy bylo dohodnuto předání potřebných materiálů. Pokud by do určeného data nebyly dodány, byl by to podklad, při případných jednáních o nedodání webové stránky v dohodnutém termínu. Po schválení zadání může také dojít k registraci požadované domény resp. domén.

20


Po vytvoření grafiky webu je připraveno rozhraní umožňující tuto grafiku nahrát. Systém akceptuje běžné grafické formáty (soubory typu jpg, bmp, png). Pro zobrazení jsem využil tzv. lightboxu. Jedná se o balíček poskytující nevtíravé funkce pro zobrazení obrázku, aniž by docházelo ke znovu načítání stránky nebo otevírání nové záložky prohlížeče. Zároveň vycentruje obrázek na střed stránky, zobrazí na volných stranách poloprůhledné pozadí a zajistí zobrazení tlačítek pro procházení obrázků vpřed a vzad a zavření prohlíženého obrázku. Lightbox využívá DOM a bližší podrobnosti lze nalézt na webu výrobce [8]. Podrobnosti projektu, které zobrazují zadané údaje při jeho vytváření nebo po editaci a připomínky, které jsem vytvořil pouze jako formulář pro vkládání textu nepotřebuje bližší komentář. Schvalování je velice důležitou částí a pokusil jsem se ho vyřešit jednoduchým způsobem. Jednotlivé stavy mají svůj číselný ekvivalent, který se požívá i v databázi. Číselné ekvivalenty jsou patrné při pohledu na ilustrační obrázek obr.4.3. Ve spodní části se nachází indikátor stavu „žížala“, který přehledně ilustruje postup schvalování a obsahuje, již zmíněné stavy. Řešení spočívá v tom, že se při výpisu zjistí aktuální stav projektu a do pole pro schválení se zobrazí stav, který následuje stavu aktuálnímu. Při zobrazování je číselný ekvivalent stavu nahrazen slovním popisem a za slovním popisem se zobrazí tlačítko pro schválení, které po stisknutí zajistí aktualizaci stavu v databázi. Celé schvalování a zobrazení stavu je řešeno jednoduše pomocí větvení realizovaného příkazem switch.

4.5

Spravované weby

Realizaci spravovaných webů jsem rozdělil na weby, kde se spravuje celý web nebo je ve správě pouze doména. Tento přístup jsem zvolil z důvodu, že některé weby mají hlavní doménu, pro kterou je objednaný webhosting a další domény, které se používají pouze jako alias pro doménu hlavní. Vložení webu do správy jsem omezil na vyplnění všech vstupních prvků formuláře. Do formuláře jsem začlenil i pole pro zadání data (od-do je správa nasmlouvaná). Položka „Správa od“ slouží pouze pro komplexnost zadávaných údajů a případné budoucí statistiky. Položku „Správa do“ využívám pro omezení vkládání požadavků na aktualizace po tomto datu. Tím jsem zajistil vyloučení prováděných prací v případě, že již není aktuální smlouva o správě webu. Pro zadávání data jsem použil datePicker viz. [7]. Jedná se plugin pro jQuery, který umožňuje zobrazit kalendář a po vybrání požadovaného data, hodnotu vložit do příslušného pole formuláře. Formulář je zobrazen na obr. 4.4. V návaznosti na správu, jsem vytvořil sekci zobrazující všechny domény, které jsou ve správě (režim pouze doména, ale i celý web) a je možné k nim načíst expiraci domény a při načítání ji rovněž uložit do databáze. Pro načtení je vytvořen objekt, jehož funkce se pokusí připojit k definovaným serverům a načíst expiraci požadované domény. Následně jsou kompletní whois informace předány funkci, která provede „ořezání“ získaných informací a vrací pouze datum expirace. Spravované weby jsem koncipoval tak, že po vložení webu do správy, kde je web s příznakem „celý web“, je možné vkládat požadavky na aktualizace. Požadavek obsahuje nejenom textovou informaci od zákázníka, ale rozšířil jsem toto rozhraní o možnost náhrání souboru. Pro vkládáné soubory jsem vytvořil na serveru složku, kde se nahrané soubory ukládají.

4.6. VYÚČTOVÁNÍ ODVEDENÉ PRÁCE

21

Obrázek 4.4: Formulář pro vložení webu do správy

Při náhrávání souboru je prováděno oddělení přípony a nahrazení původního názvu novým. Jako nový název používám řetězec „aktualizace“ a jedinečný klíč identifikující požadavek. Tento systém přejmenovávání umožnuje v jedné složce soustředit všechny soubory, aniž by hrozilo riziko, že budou soubory se stejnými názvy (ač od různých zákazníků) přepsány. Po zpracování aktualizace je nutné doplnit časový údaj, kolik času provedení požadované práce zabralo. To následně slouží pro vyúčtování odvedené práce.

4.6

Vyúčtování odvedené práce

Nejdůležitějším bodem pro vyúčtování odvedené práce bylo vytvoření faktury. Při plánování vyúčtování jsem si myslel, že faktury budu vytvářet ve formátu pdf. Tento plán bohužel není proveditelný, protože hosting na kterém se bude informační systém provozovat tuto možnost neumožňuje. Nehodlal jsem se této možnosti vzdát, tak jsem zahájil komunikaci s technickou podporou poskytovatele hostingu, ale bohužel bez výsledku. Z toho důvodu jsem nasadil nouzový plán, kde jsou všechny faktury vytvářeny ve formátu HTML. Použití tohoto formátu v sobě neslo určitá omezení, díky nimž jsem se do tohoto formátu rozhodl nevkládat razítko, ani podpis. Rozhraní pro účtování jsem rozdělil na dvě sekce. Rozdělení na vyúčtované a nevyúčtované položky. Pro rozlišení, zda byla práce vyúčtovaná či nikoliv, je v příslušné databázové tabulce příznak vyúčtování. Pro výpis vyúčtování jsem zvolit takový výpis, který bude umožňovat označit položky, které se mají na fakturu sloučit. Vzhledem k tomu, že jsem pro vypisování položek zvolit jednoduchý způsob výpisu, což znamená, že se vypisují na jednotlivých řádcích tabulky, bylo nutné ošetřit, aby nebylo možné sloučit položky různých domén. Tento problém jsem vyřešil tak, že jsem do zdrojového kódu zařadil kontrolu. Tato kontrola je vytvořena tak, že se první doména uloží do proměnné a postupně je porovnávána se všemi označenými doménami k vyúčtování. Pokud je nalezena neshoda, vyúčtování není provedeno. K vyúčtování dokončených projektů využívám jiný systém. Každý projekt, který je vytvářen, je nutné účtovat zvlášť a není logicky možné provádět žádné slučování. Každý dokončený a schválený projekt je na stránce pro vyúčtování opatřen tlačítkem pro výúčtování a po jeho stisknutí je vytvořena požadovaná faktura. Při vytváření faktur jsem čelil jedné zásadní otázce, jak realizovat vkládání variabilního symbolu. Byly dvě možnosti, jak to udělat. První možnost byla založena na tom, že se VS

22


bude vypisovat ručně do příslušného formulářového prvku a následně bude vložen do výsledné faktury. To by umožnilo používat stejnou čítelnou řadu pro všechny vystavené faktury. Zde se jedná o vystavování faktur, které nebudou procházet přes tento systém. Tuto možnost jsem následně zavrhl a použil jsem automatické vkládání VS s číselnou řadou, která je tvořena z osmi číslic. První dvojice vyjadřuje rok vystavení, druhá dvojice měsíc, třetí den a poslední dvoučíslí pořadové číslo faktury, která byla vystavena v jednom dni. Pokud by se vystavovaly nějaké faktury mimo systém, byly by na začátku doplněny prefixovou číslicí, která by označovala činnost, ke které se faktura vztahuje. Pak bylo nutno zajistit, číslo naposledy vystaveného dokladu. To jsem řešil na základě načtení čísel dokladu z databáze a jejích následném porovnávání prvního čísla dokladu s aktuálním datem. Následně jsem odtrhl datovou část a pořadové číslo dokladu jsem zvýšil o jedna. Při tomto řešení se následně vyskytl problém s řazením faktur, protože toto řešení zkracovalo celý VS z 8 číslic na 7, za předpokladu, že bylo ten den vystaveno méně než deset faktur. Celé řešení ilustruje následující zdrojový kód. Zde je vidět doplnění čísla 0 do VS faktury. $pref=date("ymd"); if(strPos($c_dokladu[0], $pref, 0)!==FALSE){ $postfix=subStr($c_dokladu[0], 6); $postfix++; if($postfix<10){ $vs="$pref"."0"."$postfix"; } else{ $vs="$pref"."$postfix"; } } else{ $vs=$pref."01"; } Při ukládání faktur do formátu HTML jsem použil vytvoření těla faktury s vyplněnými patřičnými údaji vč. splatnosti. Toto tělo (obsah dokumentu) jsem uložil do dočasného souboru, a následně po potvrzení správnosti vygenerované faktury jsem obsah dočasného souboru načetl, doplnil hlavičku XHTML dokumentu a uzavírací značky. Tento soubor je následně uložen do předpřipravené složky. Jako název používám VS dokladu. Při testování aplikace jsem zjistil, že tento způsob není zcela idelální, protože umožňoval zobrazit faktury neoprávněným uživatelům. Toto zobrazení umožňovala pouze znalost příslušného variabilního symbolu, pod kterým byla faktura ukládána. Zachoval jsem uložení faktury ve formátu HTML, ale použil jsem drobné rozšíření v podobě PHP, kde provádím kontrolu oprávněnosti přístupu k požadovanému souboru. Tato úprava obnášela změnu přípony ukládaných souborů na .php, ale zůstal zachovaný původní formát souboru. Vystavené faktury jsou v systému uspořádany do tabulky, kde jsou řazeny podle VS a je umožněno jejich prohlížení. Prohlížení faktury jsem koncipoval, aby se faktury po jejich zobrazení daly vytisknout. To je zajištěno nevkládáním hlavičky, navigace a patičky do zobrazovaného souboru.

4.7. GRAFICKÉ STATISTIKY

4.7

23

Grafické statistiky

Pro výstup grafických statistik jsem použil volně šiřitelnou třídu od Jiřího Zachara, která je ke stažení na jeho internetových stránkách viz.[5]. Tuto třídu jsem použil bez úprav, ale bylo nutné připravit skript, který připraví řádně data pro vykreslení. Výstup statistik je zobrazen na obrázku 4.5. Vytvořil jsem si funkci, která ve svém těle zjistí součty odvedené práce pro jednotlivé měsíce a uloží je do pole vč. měsíce pro který je daný součet. Tato data nebylo možné použít v tomto formátu, protože výsledek použitého dotazu pro zjištění součtů neobsahuje data, pokud nebyla v daném měsíci odvedena žádná práce viz.[2]. SELECT SUM(castka), DATE_FORMAT(zpracovano, ’%c%Y’) AS m_r FROM pozadavky_spr WHERE vyuctovano=$vyuct GROUP BY m_r Připravil jsem další funkci, která generuje posloupnosti dat od zvoleného začátku. Funkci pro zjištění součtu a generování posloupnosti dat jsem použil, jako vstupy pro funkci vytvářející pole dat pro vykreslení. Tato funkce ve svém tělě porovnává posloupnost dat a data pro jednotlivé součty. V případě, že pro dané období není nalezena žádná hodnota, je automaticky do pole doplněna nula. Výstupem funkce je pole, které je následně předáno do členské funkce pro vykreslení grafu. Zde je ukázka vytvoření vstupních dat pro statistiky. $data_grafu_vyuct=data_graf($posloupnost_data, soucty_pozadavky(1, $db, $prava, $uzivatel)); function data_graf($posloupnost_data, $p_soucty){ $data_graf=array(); $index_data=1; // v 0 se predava pocet mesicu $index_p_obdobi=1; $index_p_soucty=0; $pocet_mesicu=$posloupnost_data[0]; for($i=0; $i<$pocet_mesicu; $i++){ if($posloupnost_data[$index_data]!=$p_soucty[$index_p_obdobi]){ $data_graf[$i]=0; $index_data++; } else{ $data_graf[$i]=$p_soucty[$index_p_soucty]; $index_p_soucty+=2; $index_p_obdobi+=2; $index_data++; } } return $data_graf; }

24


Pokud by nebyla tato úprava provedena, docházelo by k posunutí časové osy. V případě, že by v určitém měsíci nebyla vyúčtována žádná částka, tak by se data následujícího měsíce považovala za hodnoty předcházejícího. Tím by byl výstup statistik velice zkreslený a neobjektivní.

Obrázek 4.5: Ukázka grafického výstupu

4.8

Ověření vstupních dat

Ověření vstupních dat jsem realizoval na dvou úrovních zdrojového kódu. První úrovní ověření je kontrola relevantnosti zadávaných údajů. Na této úrovni je kontrolováno, zda jsou do formulářových prvků zadávány odpovídající hodnoty. Aby ve formulářovém prvku pro zadání e-mailové adresy byla vložena hodnota, která splňuje parametry této hodnoty atd. V případě kontroly e-mailové adresy to znamená ověřit minimálně, zda vstupní řetězec obsahuje znak zavináč a zda jsou nenulové délky řetězce před a po tomto znaku. To jsem realizoval pomocí JavaScriptu, který kontrolu provádí na straně klienta a není nutné data odesílat na server, který by je zkontroloval a následně výsledek posílal zpět do prohlížeče. Další úroveň kontroly a případné ošetření vstupních dat jsem realizoval na úrovni serveru. Kontroly a ošetření dat jsem vložil do zdrojového kódu PHP. Zde se jedná o začlenění kontroly speciálních symbolů, které může uživatel vložit do formulářového prvku. Ve vstupech bylo nutné ošetřit hlavně symboly jednoduchých, dvojitých uvozovek a znak středníku, které by způsobovaly chyby při vkládání dat do MySQL databáze. V případě neošetření speciálních symbolů by bylo zvýšené riziko výskytu chybových hlášení a možnosti útoku na systém. V PHP je pro tyto případy začleněna funkce htmlentities( ) a htmlspecialchars( ), nahrazující tyto znaky jejich HTML ekvivalentem, který žádné problémy nemůže způsobit. Jako vstup této funkce je předán řetězec, který má být ošetřen.

Kapitola 5

Testování Při dokončování jsem se zaměřil na následující testy: • Kontroly vzhledu aplikace v různých prohlížečích • Funkčnost všech hypertextových odkazů • Uživatelské testy • Formuláře (možnosti zadání hodnot v chybném formátu)

5.1

Kontrola vzhledu aplikace v různých prohlížečích

Pro kontrolu vzhledu aplikace v jednotlivých prohlížečích jsem zvolil dvě metody. První metoda byla založena na ruční kontrole v nejpoužívanějších internetových prohlížečích. Konkrétně se jednalo o Internet Explorer ve verzi 8 a FireFox 3.6. Jako výchozí prohlížeč pro ladění jsem používal FireFox s následnou kontrolou v Internet Exporeru. Po této ruční kontrole následovalo ruční otestování vzhledu pro Internet Explorer verze 7, které jsem prováděl přepnutím módu ve stejnojmenném prohlížeči verze 8. Zde se ukázaly podstatné nedostatky. Jednalo se o špatné zobrazení navigace, kde se navigace náchálela v jiném místě, než bylo pvodně zamýšleno a navigační prvky měly jiný vzhled. První nalezenou nesrovnalost jsem následně opravil a druhou, která nebrání v dalším provozu systému, jsem ponechal. Dalším krokem ověření vzhledu bylo využití služeb internetové aplikace browsershots viz. [4]. Jedná se o aplikaci, která umožňuje testovat stránky na různých platformách a prohlížečích. Je jí předáná adresa stránky, která se má otestovat a následně se v připraveném prohlížeči označí platformy a prohlížeče, které chce uživatel testovat. Následně jsou požadavky předány, spřáteleným serverům, které stránku načtou a vrátí obrázk (screenshot) zadané stránky. Tímto je možné kontrolovat vizuální podobu webu, aniž by musel mít tvůrce nainstalovány různé operační systémy a prohlížeče. Testování v takovéto míře by nebylo možné individuálně obsáhnout. Tento test ukázal, že vzhled stránek je v požadovaných prohlížečích akceptovatelný.

25

26

5.2

KAPITOLA 5. TESTOVÁNÍ

Funkčnost hypertextových odkazů

Kontrolu hypertextových odkazů jsem prováděl za pomocí aplikace Xenu Link Sleuth viz.[6]. Tato aplikace umožňuje po zadání výchozí stránky, kontrolu všech odkazů, které se na stránce zobrazují. Jedná se o odkazy viditelné na stránce, ale i ty, které vidět nejsou (odkazy na šablony stylů, soubory s javascriptem atd.). Tento test odhalil některé nefunkční odkazy. Po výše provedené kontrole jsem příslušné stránky prošel a neplatné odkazy opravil. Po této změně následovalo opětovné otestování, zda je vše skutečně v pořádku. Zde si dovolím udělat drobnou poznámku. Aplikace Xenu není schopna testovat stránky, vyžadující zadání přihlašovacích údajů. Z toho důvodu jsem musel před zahájením testování kontrolu oprávnění vyřadit a po dokončení testu ji opětovně zprovoznit.

Obrázek 5.1: Ukázka výstupu při testování odkazů

5.3. UŽIVATELSKÉ TESTY

5.3

27

Uživatelské testy

Uživatelské testy jsem prováděl vlastnoručně a za přispění jedné osoby. Tento způsob testů jsem si vybral z toho důvodu, že pokud bych testy provávěl pouze sám, mělo by to s nějvětší pravděpodobností za následek přehlížení vlastních chyb. Zároveň by testování bylo neobjektivní, protože jsem tvůrcem systému a přesně vím, jak jsem danou sekci zamýšlel. Testování svou vlastní osobou jsem použil pro odkrytí závad, které jsem mohl způsobit nějakou chybou ve zdrojovém kódu. Takže jsem se snažil ověřit kompletní funkčnost pro jednotlivé případy zadání. Testování druhou osobou mi posloužilo pro ověření alespoň částečné intuitivnosti ovládání systému. Toto testování bude následně použito pro konfrontaci testů probíhajících po nasazení do bežného provozu. Výsledky testů poukázaly na určité chyby na úrovni formulářů. Bylo zjištěno, že u výpisů projektů a jejich stavu dochází k záměně funkce tlačítek. Tato závada se tvářila jako čistě nahodilá, ale nakonec jsem zjistil, že k této chybě dochází v případě, kdy je projekt schválen a za ním následuje jiný. Bylo to způsobeno chybou, kterou jsem zanesl do generovaného formuláře tím, že výpis projektu se generuje na základě jeho stavu. V případě, že byl projekt již schválen, jsem v příslušné větvy zdrojového kódu opomněl vložit značku pro ukončení formuláře a to mělo za následek pokračování formulářové oblasti do dalšího výpisu. V dalším výpise se vyskytla výše popsaná závada prohození funkce tlačítek. Dále testování poukázalo na možnost neuložení faktury po jejím vygenerování. Po vygenerování dokladu jsem tlačítko pro jeho uložení umístil ke spodnímu okraji faktury a test ukázal na možnost opomenutí fakturu po vygenerování uložit. Tato závada by se dala odstranit vložením tlačítka i nad vrchní část dokladu. Změna zatím provedena nebyla, protože nepředpokládám, že by se jednalo o zásadní chybu. Zároveň nepředpokládám, že by faktury vystavoval někdo jiný než já. Pokud by tomu v budoucnosti bylo, určitě bych provedl dálší testování.

5.4

Kontrola formulářů

Kontrola vstupních formulářových prvků byla to systému zahrnuta v nejzažší fázi vývoje. Otestování jsem provedl zadáváním nevhodných údajů do formulářů a testovánín zda systém data příjme, či nikoliv. Testování této funkce proběhlo bez problémů. Bylo průběžně prováděno v době psaní kontrolních skriptů. Z toho důvodu je možné, že jako autor skriptů jsem některé možnosti opomenul a jsem si jist, že pokud v systému zůstaly některé mezery kontroly dat, budou brzy po nasazení systému odhaleny.

28

KAPITOLA 5. TESTOVÁNÍ

Kapitola 6

Závěr Tento Informační systém je připraven pro nasazení do bežného provozu, což bude v nejbližší době provedeno. Budu ho používat, dle stanovených cílů a zároveň bude probíhat podrobný monitoring jeho funkce s přímou vazbou na zákazníka. Dále budou sbírány podněty ze strany zákazníků, které by mohly přispět ke zkvalitnění systému. Plánuji, že do systému budu po určitých časových obdobích zahrnovat úpravy a případná rozšíření na základě požadavků ze strany zákazníků. Jde o funkce, které vyvstanou z potřeby každodenního využívání. V této fázi si myslím, že byly splněny všechny cíle, které byly stanoveny na vytvoření tohoto informačního systému. Toto tvrzení vychází z požadavků, které jsou na systém v současné době kladeny. Poskytuje lehce dostupnou možnost spravování vytvářených internetových projektů a sledování webových stránek, které má firma ve správě. U vytvořených projektů a spravovaných webů poskytuje možnost vyúčtování odvedené práce a nemůže se stát, jako tomu je u doručování požadavků e-mailem, že se opomene nějaká aktualizace zaúčtovat. Zároveň se podařilo jednoduše vyřešit zobrazování statistik poskytujících přehledně jednotlivé údaje o nevýúčtovaných a vyúčtovaných položkách pro dané období. V případě, že by byl systém intenzivně a dlouhodobě používám, bylo by pravděpodobně nutné vytvořit stránkování pro jednotlivé výpisy a možnosti filtrování prohlížených údajů. Tyto možnosti zatím nebyly řešeny z toto důvodu, že chci nejpve zístak objektivní informace od zákazníků, zda je pro ně používání takovéhoto systému přínosem nebo budou upřednosťovat komunikaci pomocí elektronické pošty. Zároveň není v současné době přesně znám objem dat, která budou systémem procházet. Výše zmíněné úpravy je vhodné zahrnout s ohledem na počet zákazníků obsluhovaných tímto systémem. Dále by se mohlo časem ukázat, že bude nutné doplnit fakturování spravovaných domén, které se blíží datu expirace. V současnosti není tato funkce důležitá. Většina domén, které jsou spravovány jsou registrovány na zadavatele spravovaného webu, který si registraci a prodlužování domén provádí sám. Zároveň se i při vytváření nových webových stránek zadavatel přeje, aby registrace proběhla jeho jménem. Tím pádem není momentálně důležité, aby systém zajišťoval fakturování těchto úkonů nebo odesílal upozornění na expiraci domény, protože tuto funkci zajišťuje systém registrátora příslušné domény.

29

30

KAPITOLA 6. ZÁVĚR

Literatura [1] CROFT, J. – LLOYD, I. – RUBIN, D. Mistrovství v CSS. CPress, 1st edition, 2007. In Czech. [2] KOFLER, M. Mistrovství v MySQL 5 - Kompletní průvodce webového vývojáře. APress, 1st edition, 2007. In Czech. [3] KOFLER, M. – OGGL, B. PHP 5 a MySQL 5 - Průvodce webového programátora. CPress, 1st edition, 2007. In Czech. [4] web:browsershots.org. Webová aplikace pro testování vzhledu internetových stránek Browsershots. http://www.browsershots.org, stav ze 6. 3. 2010. [5] web:grafy.zaachi.com. Grafy v PHP. http:/grafy.zaachi.com, stav ze 20. 4. 2010. [6] web:home.snafu.de/tilman/xenulink.html. Domovská stánka aplikace pro otestování neplatných odkazů. http://home.snafu.de/tilman/xenulink.html, stav ze 17. 5. 2010. [7] web:kelvinluck.com. Vkládání data z kalendáře - datePicker. http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/, 23. 5. 2010.

stav

ze

[8] web:www.huddletogether.com. Lightbox - zajišťuje efektní zobrazení obrázků ve fotogaleriích. http://www.huddletogether.com/projects/lightbox2/, stav ze 16. 5. 2010. [9] web:www.pspad.com. Freewarový editor pro psaní skriptů. http://www.pspad.com/, stav ze 26. 5. 2010.

31

32

LITERATURA

Příloha A

Seznam použitých zkratek ASP Active Server Page CSS Jazyk pro formátování webových stránek DOM Document object model FURPS Analýza založená na průzkumu funkčnosti, použitelnosti, spolehlivosti, vykonnosti a bezpečnosti systému IP adresa Adresa, identifikující síťové rozhraní IS Informační systém JavaScript Skriptovací jazyk, běžící v prohlížeči na straně klienta JSP Java Server Page jQuery Framework pro JavaScript MD5 Message-Digest algorithm - hešovací funkce MySQL Databázový systém PHP Skriptovací jazyk, pro tvorbu dynamických webových stránek, bežící na straně serveru SWOT Analýza založena na identifikaci silných a slabých stránek projektu VS Variabilní symbol XHTML Značkovací jazyk pro tvorbu internetových stránek PDF Portable Document Format

33

34

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

Vzory tištěných dokumentů

Obrázek B.1: Vzor faktury

35

36

PŘÍLOHA B. VZORY TIŠTĚNÝCH DOKUMENTŮ

Obrázek B.2: Vzor objednávky

Příloha C

Instalační a uživatelská příručka C.1

Instalace

U tohoto systému se nejedná o instalaci v pravém slova smyslu. Pro jeho zprovoznění na libovolné doméně je nutné překopírování zdrojových souborů do patřičné složky na serveru poskytovatele webhostingových služeb. Pro plnou funkčnost je nutné, aby byl server provozován na operačním systému Linux a obsahoval PHP verze 5 a databázový systém MySQL min. verze 4. Je nutné zabezpečit, aby byly nastaveny direktivy php magic_quotes_gpc, magic_quotes_runtime a magic_quotes_sybase na hodnotu - Off. Po splnění těchto požadavků je nutné v root složce vytvořit složku admin, kam budou nakopírovány jednotlivé zdrojové soubory. Dále se přihlásit do aplikace phpMyAdmin nebo jiné, kterou provozuje poskytovatel hostingových služeb pro správu MySQL databází a v rozhraní SQL otevřít soubor, který se nachází na přiloženém CD. Soubor je uložen ve složce „databaze“ a jedná se o soubor data.sql. Po jeho otevření a provedení příkazů v phpMyAdmin dojde k vytvoření všech potřebných tabulek pro provoz systému. Aby mohl systém s touto databází komunikovat je nutné vytvořit složku data, nacházející se na stejné úrovni jako je složka www, kam byla umístěna složka admin. Do složky data se musí vložit soubor datadb.php, který obsahuje příslušné přihlašovací údaje k databázi. Na CD se nachází ve složce „databaze“. Tento soubor je nutné otevřít a zadat do příslušných proměnných hodnoty, které se týkají přístupu do vámi vytvořené databáze. Po provedení těchto kroků je již systém plně připraven k použítí a testování jeho funkcí. K přístupu do systému je možné použít následující uživatelské údaje. Administrátorský přístup: Uživatelské jméno: [email protected] Heslo: admin Uživatelský přístup: Uživatelské jméno: [email protected] Heslo: noname Tyto uživatele lze kdykoliv změnit nebo je dokonce ze systému odstranit.

37

38

C.2

PŘÍLOHA C. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Způsob zápisu příručky

V následujícím textu je dodržen následující zápis. Pokud je nutné vybrat položku z hlavní navigace je její název uveden v běžném textu. V případě, že je nutné dodržet posloupnost kroků např. výběr položky z hlavní navigace a následný výběr z podnavigace je použit zápis, kde je posloupnost určena šipkou. Zároveň je text vysázen kurzivou př. Položka hlavní navigace > Položka podnavigace. Popisy tlačítek jsou v textu uváděny v uvozovkách. Př. „Vložit záznam“. Tato příručka si neklade za cíl dopodrobna popisovat veškeré postupy, ale pouze přiblížit postup jednotlivých kroků pro nejběžněji prováděné operace.

C.3

Uživatelská příručka

Zaměstnanec může provádět veškeré úkony, které jsou systémem nabízeny. V případě, že je přihlášen zákazník, jsou mu funce omezeny pouze na záznamy, které jsou svázány s jím zadanými projekty nebo správou webu. Pro založení nového projektu k realizaci nebo vložení nového webu do správy je nutné vědět, zda je zákazník již vložen do systému. Pokud ne, je prvním krokem vložení nového uživatele. Uživatelé: Nového uživatele přidáme výběrem Uživatele >Přídání záznamu a vyplněním údajů do formuláře. Je nutné vyplnit položky jméno, příjmení, e-mail, heslo a vybrat příslušná práva, která budou novému uživateli náležet. V případě, že jsou známy všechny údaje nebo alespoň většina, je vhodné je zadat rovnou při zakládání uživatele, protože jsou následně používány pro vystavení faktury. Zadané údaje potvrdíme tlačítkem „Přidat uživatele“. Pak je již možné uživateli přidělovat projekty a spravované weby. Následně je možné výběrem patřičné položky v podnavigaci Uživatele provádět úpravy a odstraňování jednotlivých záznamů. Při odstraňování je jeden záznam zablokovaný, aby nemohlo dojít k jeho nechtěnému smazání. Jedná se o přihlašovací údaje majitele systému. Projekty: Přídání projektu je možné po výběru položek Projekty > Nový projekt. Zde se předpokládá zadání všech položek nacházejících se ve vrchní části formuláře. Je to minimum, které by mělo být známo, aby byl projekt vkládán do systému. U názvu projektu se předpokládá, že nebude obsahovat tečky, mezery nebo jiné speciální symboly. Po zadání potřebných údajů je možné projekt uložit. Po uložení projektu je možné provádět jeho úpravy, ale nikoliv ho ze systému odstranit. Úpravy projektu jsou vázány na přihlášení uživatele s oprávněním zaměstnance. Zákazník může ovlivňovat zadání a další prováděné práce pouze na základě vložení připomínky k projektu. Po přidání nového projektu je již k dispozici přehledné rozhraní (položka Projekty), kde je dostupná většina položek. Zde je možné zobrazovat připomínky k projektům, které byly vloženy. Pokud na přípomínku ještě nebylo reagováno, je zobrazeno pole umožňující zapsat reakci. Zde se většinou očekává, že bude zádáno - „Připomínka zapracována“ nebo zdůvodnění, proč nebyla zapracována kompletně. Dále jsou pro projekty dostupná tlačítka pro zobrazení a vkládání grafiky a podkladů. Zde je nutné vložit případné podklady a grafiku, ale v závislosti na objednávce zákazníka. Dále je možné zobrazit podrobnosti o projektu. Posledním tlačítkem je tlačítko „Schválit“, kterým je realizován schvalovací proces. Pokud by zákazník nechtěl využívat tento systém je nutné, aby schvalování prováděl zaměstnanec, ale

C.3. UŽIVATELSKÁ PŘÍRUČKA

39

to pouze v případě, že daná etapa byla skutečně schválena. Pouze jedna položka se nachází v podnavigaci Vložit připomínku, umožňující vkládání komentářů k projektu. Domény: V doménách není možné provádět žádné změny je pouze možné provést načtení expirace. V případě úspěšného načtení expirace je zobrazeno patřičné datum. Pokud se expiraci nepodaří načíst (pravděpodobně z důvodu omezení připojení k serveru), je zobrazen úryvek textu o neúspěšném načtení. V tomto rozhraní jsou zobrazeny domény, které jsou evidovány ve správě. Správa webu: Správa webu umožňuje zaměstnancům vkládat weby do správy, následně je upravovat a zobrazovat požadavky na aktualizace s následným vložením času, který aktualizace trvala. Kromě těchto položek má zaměstnanec dostupné ještě položky, které jsou společné pro zákazníky. Jedná se o odkazy zobrazující přehledy požadavků, které jsou zpracovány a které čekají na zpracování. A ještě položku Vložit požadavek umožňující vkládat požadavky na aktualizaci webu. Účty: Po zobrazení rozhraní Účty je k dispozici globální statistika zobrazující stručný přehled o účtech, uživatelých a doménách ve správě. Kromě přehledu účtu se všem uživatelům zobrazují stejné hodnoty. V podnavigaci jsou uspořádány položky zpřístupňující funkce umožňující práci s účty. Všechny položky jsou dosptupné pro všechny uživatelské role. Kromě položky Vyúčtovat jsou všechny dostupné pouze přehledové. Odkaz pro vyúčtování umožňuje zaměstnanci provést vyúčtování odvedené práce. V případě aktualizace některého spravovaného webu je nutné označit aktualizace, které mají být vloženy do jedné faktury. Nelze vybrat aktualizace prováděné pro různé domény. Každý dokončený projekt je opatřen přímo tlačítkem, které umožní provést vyúčtování pro každý zvlášť. Po výběru je zobrazena faktura, kde je nutné zkontrolovat adresu zadavatele a celkovou částku na kterou je doklad vystavován. Po kontrole je nutné pomocí tlačítka „Uložit fakturu“ fakturu uložit. Statistiky: Statistiky jsou dostupné po kliknutí na stejnojmennou položku v hlavní navigaci. Rozhraní je rozdělěno na dvě části, kde jsou zobrazeny příslušné statistiky. První obrázek statistiky vyobrazuje hodnoty vyúčtovaných a nevyúčtovaných aktualizací a druhý vyobrazuje bilance projektů. Ve statistikách není možné provádět žádné úpravy žádným uživatelem. Jsou generovány automaticky na základě učetních hodnot. Po přihlášení zákazníka je zajištěno zobrazení statistik pouze pro jeho osobu a nejsou mu zobrazeny statistiky globální.

40

PŘÍLOHA C. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Příloha D

Obsah přiloženého CD . |-| |-| |-| |-| | |-|-|-|-‘--

BP ‘-- bakalarka.tex - zdrojový soubor Bakalářské práce ve formátu TEX absCZ ‘-- abstrakt.txt - abstrakt v češtině absEN ‘-- abstract.txt - abstrakt v angličtině databaze |-- datadb.php - soubor s přihlašovacími údaji k databázi ‘-- data.sql - záloha databáze nutná pro chod systému img - obrázky použité v práci install.txt - popis instalace readme.txt - manuál k systému src - zdrojové soubory aplikace text ‘-- bakalarka.pdf - text Bakalářské práce

41

Informační systém pro společnosti zabývající se vývojem webu. Petr Kulich

Recommend Documents