VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika
I n f o r m a č n í s y s t é m p ro I T s p o l e č n o s t bakalářská práce
Autor: Adam Caha Vedoucí práce: Ing. Karel Pohl Jihlava 2016
Abstrakt Cílem této bakalářské práce je vytvořit informační systém pro IT společnost, který nahradí dosavadní řešení několika navzájem nepropojených aplikací. Webová aplikace bude sloužit ke správě interních a zákaznických požadavků. Systém bude evidovat počet odpracovaných hodin zaměstnanců a bude v něm možno vytvářet přehledy zejména pro fakturaci či výpočet mezd. Aplikace, vytvořená v prostředí .NET/C#, bude integrována do stávající aplikace SH-Portal, používaná v současnosti jako redakční systém pro publikování.
Klíčová slova C#, SH-Portal, informační systém, webová aplikace, .NET, incident, ITIL, service desk
Abstract This bachelor’s thesis aims to create an information system for an IT company, which would replace the current solution consisting of several mutually unconnected applications. This web application will be used to administer both internal and customer requests. It will register employee’s work hours and enable to create summaries for invoices and calculation of wages. This application will be created in .NET/C# framework, and it will be integrated in existing application called SH-Portal, which is used as editorial system for publishing.
Key words C#, SH-Portal, Information system, Web application, .NET, Incident, ITIL, Service desk
Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu 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ů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval svému vedoucímu práce Ing. Karlu Pohlovi za poskytnutí tématu a možnost vytvářet ho pod jeho vedením.
Obsah 1
Úvod.......................................................................................................................... 8
2
Analýza ..................................................................................................................... 9 2.1
Katalog požadavků ........................................................................................... 10
2.2
Definice použitých pojmů ................................................................................ 10
2.2.1
Nepřihlášený uživatel ............................................................................... 13
2.2.2
Zákaznická sekce ...................................................................................... 13
2.2.3
Technická sekce ........................................................................................ 14
2.2.4
Administrátorská sekce ............................................................................. 16
2.3
3
2.3.1
E-R Diagram ............................................................................................. 17
2.3.2
Model případů užití ................................................................................... 18
Návrh řešení ............................................................................................................ 20 3.1
Grafické rozhraní ............................................................................................. 20
3.1.1
Návrh zákaznické sekce ............................................................................ 20
3.1.2
Návrh technické sekce .............................................................................. 21
3.2
Existující řešení ................................................................................................ 23
3.3
Využité technologie ......................................................................................... 24
3.3.1
.NET Framework ...................................................................................... 24
3.3.2
ASP.NET WebForms................................................................................ 25
3.3.3
Microsoft SQL Server 2012 ...................................................................... 26
3.3.4
Visual Studio Team Services .................................................................... 27
3.3.5
SH-Portal .................................................................................................. 27
3.4
4
Modely ............................................................................................................. 17
Vývojové prostředí ........................................................................................... 30
3.4.1
Microsoft Visual Studio Community 2015 ............................................... 30
3.4.2
SQL Server Management Studio .............................................................. 31
3.4.3
Pencil ........................................................................................................ 32
3.4.4
Creately ..................................................................................................... 32
Realizace ................................................................................................................. 33 4.1
Databáze ........................................................................................................... 33
4.2
Moduly ............................................................................................................. 33
4.2.1
Zákazník.................................................................................................... 33
4.2.2
Technik ..................................................................................................... 34
4.2.3
Administrátor ............................................................................................ 35
4.3
Zajímavé funkce a metody ............................................................................... 35
4.3.1
Označení a změna Služeb zákazníka ........................................................ 35
4.3.2
Výpočet odpracovaných hodin během vybraného dne ............................. 36
4.4
Základní nastavení aplikace SH-Portal ............................................................ 38
4.5
Bezpečnost ....................................................................................................... 38
4.5.1
Autentizace a autorizace ........................................................................... 39
4.5.2
Další zranitelnosti ..................................................................................... 39
5
Testování ................................................................................................................. 41
6
Závěr ....................................................................................................................... 42 6.1
Zhodnocení výsledků ....................................................................................... 42
6.2
Problémy a jejich řešení ................................................................................... 42
6.3
Možnosti rozšíření a budoucnost systému ....................................................... 43
Seznam použité literatury ............................................................................................... 44 Seznam obrázků a tabulek .............................................................................................. 46 Seznam použitých zkratek .............................................................................................. 47 Obsah přiloženého CD .................................................................................................... 48
1 Úvod Téma bakalářské práce jsem si vybral již během odborné praxe ve firmě, kde jsem praxi absolvoval. Můj nadřízený mi nabídl možnost zpracovat jako téma bakalářské práce informační systém firmy, který by sloužil jako nástupce dosavadního řešení. Jedná se o webovou aplikaci založenou na interním publikačním systému SH-Portal1, která je vytvořená jako ASP.NET aplikace s podporou Microsoft SQL serveru. [1] Vzhledem k dosavadnímu studiu a mé volbě povinně volitelných předmětů se mi možnost propojení téměř všech studovaných odborností v rámci jednoho projektu velmi zamlouvala. Zároveň právě tvorba informačních systémů a komunikace se zákazníkem jsou obory, kterým bych se chtěl v budoucnu více věnovat a nadále je i studovat. Líbila se mi možnost zakomponování jednotlivých funkcionalit .NET Frameworku a dalších volně dostupných knihoven do již existujícího projektu. Zároveň spolupráce na funkčním projektu, hledisko zodpovědnosti a práce v týmu s verzovacím systémem byla neocenitelnou, avšak velmi náročnou, zkušeností. Základní požadavky byly dány na základě aplikací BUGtracker.NET2, MyHours3 a Jira4, které firma dosud využívala. Další požadavky byly dány zadavatelem. Zákazník bude mít možnost zadávat jednotlivé požadavky přímo do systému a bude mít možnost stávající požadavky monitorovat. Technik bude moci jednotlivé požadavky upravovat a spolu s kolegy a zákazníkem může komunikovat skrze veřejné i neveřejné komentáře, které jsou součástí každého požadavku. Pro řízení společnosti bude možné evidovat v rámci jednotlivých požadavků počty odpracovaných hodin zaměstnanců, a to především pro vytváření podkladů pro generování faktur klientům a mezd zaměstnancům.
1
http://shweb.cz/Default.aspx?t=101&docid=88 http://ifdefined.com/ 3 http://old.myhours.com/ 4 https://www.atlassian.com/software/jira/service-desk 2
8
2 Analýza Analýza celého projektu byla zjednodušena tím, že zadavatelem práce byl zároveň majitel firmy, který se v oboru IT pohybuje celý život. Měl jasnou představu o celé aplikaci již před zahájením tvorby. Firma tou dobou (léto 2015) využívala pro správu agendy zákazníků, správu požadavků jak interních, tak zákaznických, volně dostupné aplikace a systémy jako MyHours nebo BUGtracker.NET. Cílem projektu je vytvořit ucelený systém, který umožní evidovat požadavky, pracovní dobu a podklady pro mzdy a fakturaci. Systém také usnadní práci klientům, kteří uvidí všechny své požadavky na jednom místě a zefektivní komunikaci s poskytovatelem služeb. Vzhledem k jasně definovaným cílům, úkolům a hranicím systému jsem se rozhodl postupovat metodou sekvenčního vývoje – metodou vodopádu. Metoda byla poprvé popsána Winstonem Roycem, který ji ovšem popsal jako iterativní. Sám považoval za důležité, aby byl celý proces proveden dvakrát či třikrát, aby bylo možné z předchozích chyb vyvodit důsledky a proces zopakovat, avšak bez již známých chyb. Vodopád, neboli také Waterfall „padá“ stejně jako voda. Výhoda tohoto způsobu vývoje je zároveň jeho hlavní nevýhoda. [2] Jakmile je totiž jedna část hotová, nelze se vrátit a jedná se tak o poněkud neflexibilní metodu. Pro návrh jasně daného a definovaného systému, u kterého stačí vyřešit detaily, rozvržení a realizaci je však právě vodopád vhodným řešením.
Obrázek 1 - Model vodopád (Waterfall) (Zdroj: Page (2009))
Mým úkolem tedy bylo vytvořit moduly do stávajícího systému SH-Portal, který aktuálně slouží jako redakční systém. Aplikace SH-Portal, která byla vyvinuta firmou, pro níž práci zpracovávám, je webová aplikace vytvořená v C# využívající ASP.NET a Microsoft SQL Server.
9
Systém je postaven na zásadách ITIL, což je souhrn „dobrých praktik“, které se v IT praxi osvědčily a mnohé z nich čerpá i oficiální standard ISO 9000 nebo ISO / IEC 20000.
2.1 Katalog požadavků Katalog požadavků slouží k vydefinování specifických funkcí, požadavků a hlavních charakteristik vznikajícího systému. Každá podkapitola se věnuje určité uživatelské roli, kterou je možné libovolně přiřazovat uživatelům nebo skupinám uživatelů, a tím jim poskytovat přístupová práva k jednotlivým modulům a stránkám aplikace. Na konci každé z podkapitol bude následovat exaktně vydefinovaný souhrn všech funkčních požadavků na systém dle metod využívaných v softwarovém inženýrství. Mnoho systémů se během analýzy potýká s problémem nekončící množiny nadbytečných požadavků, a tím se nepřiměřeně zvyšují náklady a doba potřebná na vývoj. Dochází k oddalování spuštění aplikace do ostrého provozu a náklady na systém nepřiměřeně rostou. Z tohoto důvodu nejsou součástí katalogu definovány žádné nefunkční požadavky, jako například požadavek na dostupnost nebo přístupnost systému, nebo uživatelské rozhraní v jiném než národním jazyce. Požadavky tohoto typu by pouze prodlužovaly dobu vývoje, aniž by se očekávalo jejich využití.
2.2 Definice použitých pojmů Důležitou součástí analýzy softwarového řešení je přesná definice použitých pojmů v dokumentaci i v implementaci řešení. V praxi se obecně analýza a příprava projektů velmi podceňuje, a to jak ze strany nároků na zákazníka, tak i ze strany požadovaných zdrojů a času potřebného pro vývoj nového IS. Přitom právě správně provedená analýza a exaktní definice vytyčených pojmů a požadavků jsou základem bezproblémového vývoje a nasazení systému. [3] Vzhledem k tomu, že odběratelem a poskytovatelem služby byla v tomto případně jedna a tatáž firma, neměl jsem během analýzy problém vyřešit jakékoliv nejasnosti, a tím se celý proces analýzy velmi zjednodušil. Definici užitých pojmů, založené na standardech ITIL, jsou uvedeny níže (Tabulka 1).
10
Tabulka 1 - Definice použitých pojmů (Zdroj: vlastní, [4])
Pojem
Definice
Zákaznický portál
Nabízí uživatelům možnost vytvořit požadavek na službu samostatně. Požadavek lze zadat přímo uživatelem, nebo zaměstnancem poskytovatele služeb v případě, že byl požadavek oznámen telefonicky, či e-mailem. Uživatelům jsou jejich požadavky zobrazovány v tabulce. V mé práci a vyvíjené aplikaci se také používá pojmů informační systém nebo klientský portál. [5]
Zákazník
Neboli klient, je jméno organizace, zastupující uživatele s oprávněním uzavírat dohody s poskytovatelem služeb o jejich využívání. [6] V aplikaci a mém textu se zákazník může vyskytovat i ve smyslu zákaznického profilu.
Uživatel
Osoba, která používá zákaznický portál pro svou každodenní práci. [6]
Požadavek
Požadavek se v systému používá ve dvou významech. Ve vyšším, nadřazeném významu je to obecný název pro vzniklou a zapsanou událost do systému. Každá událost má své unikátní identifikační číslo, název, stav, prioritu (není viditelná pro zákazníky systému), popis, komentáře (veřejné i neveřejné), záznam o vytvoření a poslední editaci. Ve významu nižším je na stejné úrovni jako incident, tedy typ vytvořeného požadavku. Požadavek může být například žádost o vylepšení některých služeb, úpravu nastavení systému apod. Nejedná se tedy primárně o chybu.
Typ požadavku
Vlastnost každého požadavku, například incident nebo požadavek. Uživatelé se zákaznickou uživatelskou rolí nevidí tuto položku.
Incident
Druh požadavku, který indikuje nestandardní chování služby s potenciální možností ztráty funkčnosti.
Priorita
Neboli důležitost je označení, které má několik stupňů dané předdefinovaným číselníkem. Uživatelé se zákaznickou uživatelskou rolí nevidí tuto položku.
11
Stav
Každý požadavek má přiřazen stav. Ve svém životním cyklu prochází požadavek několika stavy a začíná zpravidla stavem „nový“ a končí, v případě, že je úspěšně uzavřen, stavem „uzavřeno“.
Komentář
Každý požadavek může mít jakýkoliv počet komentářů a ty mohou být veřejné, či neveřejné. Zákazník systému vždy vkládá veřejný komentář a vidí ho všichni ostatní uživatelé přiřazeni k tomuto zákaznickému profilu a zároveň zaměstnanci klientského portálu. Tento komentář slouží ke komunikaci mezi zákazníkem a pracovníky portálu. Technik může vložit oba typy komentáře. Veřejný komentář vkládá pro již zmíněnou komunikaci a neveřejný pro komunikaci s ostatními pracovníky na daném požadavku, ale i pro detailní popis aktuální stavu požadavku. Komentáře se řadí sestupně podle data vzniku a zapisuje se do nich kdo a kdy je vytvořil a naposledy upravil.
Služba
Název typu práce, který bude zaměstnanec provádět na daném požadavku. Každý zákazník má svou vlastní sadu služeb a každá služba má cenu a tarif.
Tarif
Je druh sazby služby, zpravidla se jedná o minutovou (vzdálená pomoc po telefonu) nebo hodinovou (vývoj, poradenství).
WorkLog
Neboli pracovní výkaz nebo Timesheets slouží pro sledování pracovní činnosti a vytížení jednotlivých pracovníků (zaměstnanců). Sleduje se, na kterém požadavku pracovali, jak dlouho a jaký typ služby svou prací poskytovali a kterému klientovi (zákazníkovi). Data uložená ve WorkLogu slouží pro následné vyúčtovaní služeb klientům a tvorbě mezd zaměstnancům.
Report
Tabulkové zobrazení WorkLogu vytvořené pro určité časové období a další zadané parametry jako například jméno pracovníka nebo zákazníka.
Zákaznický profil
Každý zákazník (společnost), který je smluvním klientem zákaznického portálu má vlastní zákaznický profil. Pod svým profilem může mít uživatelské účty, pomocí kterých interaguje s klientským portálem.
12
Uživatelský účet
Každý zákaznický profil musí mít vytvořen alespoň jeden
zákaznického profilu
uživatelský účet. Pomocí uživatelských účtů, přičemž platí, že každý zaměstnanec klienta (zákazníka) má vlastní uživatelský účet, pak zákazník (společnost) používá klientský portál.
2.2.1 Nepřihlášený uživatel Nepřihlášený uživatel nemá přístup k žádným datům aplikace a nemůže žádným způsobem se systémem interagovat. To je zejména proto, že internetové stránky, na nichž je aplikace dostupná, jsou určeny právě a jenom smluvním klientům (zákazníkům) a zaměstnancům poskytovatele služeb. Úvodní stránka však obsahuje odkaz na „obchodní“ prezentaci, aby mohl být i náhodný návštěvník správně nasměrován. Tabulka 2 - Funkční požadavky: Nepřihlášený uživatel (Zdroj: vlastní)
Požadavek
Popis
N1 – Přihlášení
Každý uživatel, který navštíví stránku klientského portálu má možnost se přihlásit. Po úspěšném přihlášení se mu zobrazí nabídka vstupu do aplikace na základě uživatelských rolí, které systém nabízí. Aplikace nabízí možnost „Pamatuj si mě“, která slouží pro zapamatování přihlášeného uživatele i v případě zavření prohlížeče.
N2 – Data
Nepřihlášený uživatel nemá přístup k žádným datům aplikace.
N3 – Prohlížení
Nepřihlášený vidí pouze úvodní (přihlašovací) stránku, na které jsou uvedeny základní informace, k čemu a komu portál slouží, odkaz na oficiální firemní stránky, kontaktní e-mail a modul přihlášení.
N4 – Registrace
Každý návštěvník s odkazem se může registrovat, avšak nezískává žádná práva. Ty mu musí přidělit Administrátor. Registrace slouží pro pracovníky zákazníka, kteří si mohou snadno vytvořit uživatelský účet (včetně vlastního hesla) a následně zažádat o přidělení oprávnění.
2.2.2 Zákaznická sekce Zákazník pod svým profilem může mít několik uživatelských účtů (ty slouží zaměstnancům zákazníka), viz také Tabulka 1 - Definice použitých pojmů. Uživatelé pak mohou přidávat nové požadavky, u kterých vyplňují pouze název a popis, a smí vkládat veřejné komentáře. Každý zaměstnanec (uživatelský účet vytvořený pod daným 13
zákaznickým profilem) vidí pouze požadavky zákaznického profilu, k němuž jsou přiřazeny. Tabulka 3 - Funkční požadavky: Zákaznická sekce (Zdroj: vlastní)
Požadavek
Popis
Z1 – Účet
Zákaznický účet definuje skupinu uživatelů, které patří právě pod jednoho zákazníka. Zákaznický účet vytváří technik-administrátor pomocí modulu Správa zákazníků. Uživatele k zákaznickému účtu přiřazuje technik-administrátor v modulu Správa uživatelských účtů. Zákazník si sám nemůže spravovat uživatelské účty, které jsou k němu přiřazeny, ani přidávat další. Aby zákazník mohl vstoupit do systému, musí mít jeho zákaznický profil alespoň jednoho uživatele. Každý uživatelský účet má ve vyvíjené aplikaci stejná práva.
Z2 – Vytvoření
Každý uživatel (uživatelský účet s přístupovou rolí zákazník) má
požadavku
možnost vytvořit požadavek. Požadavek má dvě povinná textová pole: název a popis požadavku.
Z3 – Přehled
Každý uživatel má možnost si zobrazit všechny požadavky
požadavků
zákaznického profilu, jemuž je jeho uživatelský účet podružen.
Z4 – Filtrování
Požadavky lze filtrovat pomocí názvu (nebo jeho části), ID, nebo stavu.
požadavků
Implicitně se zobrazují všechny vytvořené požadavky.
Z5 – Zobrazení
Uživatel si může zobrazit jakýkoliv požadavek a prohlédnout si kromě
detailu požadavku
parametrů, podle kterých lze požadavky filtrovat, také popis a všechny veřejné komentáře.
Z6 – Vkládání
Každý uživatel může vložit, prohlížet a upravovat komentáře všech
komentáře
svých požadavků.
2.2.3 Technická sekce Tato sekce slouží zaměstnancům poskytovatele služeb (technikům). Mají přístup do zákaznické sekce, kde mají stejné možnosti jako zákazníci systému. Navíc mají přístup do technické sekce, která slouží ke správě jednotlivých požadavků a k vykazování odpracovaných hodin. Zároveň mohou generovat i reporty, které mohou sloužit pro kontrolu vykazovaných hodin a rovněž jako podklady pro výpočet zaměstnaneckých mezd nebo zákaznických faktur.
14
Rozšířením technické sekce bude sekce technik-administrátor, která bude i samostatnou uživatelskou rolí, která vznikne rozšířením technické uživatelské role. Bude se jednat o roli vedoucího zaměstnance (týmového vedoucího). Tato role bude mít navíc možnost spravovat zákazníky a jejich uživatele, vytvářet nové služby a přiřazovat je jednotlivým zákazníkům. Tabulka 4 - Funkční požadavky: Technická část (Zdroj: vlastní)
Požadavek
Popis
T1 – Vytvoření
Technik může vytvářet požadavky stejně jako zákazník (uživatel se
požadavku
zákaznickou uživatelskou rolí), navíc musí zadat druh požadavku, přiřadit k požadavku zákazníka, prioritu, stav a datum dokončení. Navíc může přiřadit k danému požadavku zodpovědné zaměstnance a připsat veřejný či neveřejný komentář.
T2 – Přehled
Technik si může zobrazit požadavky jakéhokoliv zákazníka.
požadavků T3 – Filtrování
Technik může filtrovat požadavky pomocí aktuálního stavu nebo dle
požadavků
zákazníka či priority.
T4 – Detail
Technik si může zobrazit detail jakéhokoli požadavku. Vidí všechny
požadavku
vlastnosti požadavku a s výjimkou ID, zákazníka a informací o vytvoření, může veškeré informace upravovat. Navíc je zde i pole pro vložení WorkLogu, kde může zaměstnanec vložit informace o pracovním záznamu nad daným požadavkem.
T5 – Vytvoření
Technik zaznamenává své výkazy práce přes klientský portál. Pokaždé,
WorkLogu
když technik pracuje na určitém požadavku, zapíše do systému počáteční a koncový čas, vybere název prováděné služby a může připsat poznámku, která detailněji popíše náplň práce. Je možné vytvořit záznam pouze s počátečním časem. Pracovník založí WorkLog ve chvíli, kdy začíná požadavek řešit a ve chvíli kdy končí, opět pouze daný WorkLog otevře a vloží koncový čas.
T6 – Úprava
Technik může upravovat pouze své pracovní záznamy a to tak, že si
WorkLogu
nastaví určité datum a systém mu vypíše všechny pracovní záznamy pro daný den. Technik může pracovní výkaz smazat nebo upravit veškeré jeho parametry (s výjimkou ID).
15
T7 – Výpočet
Součástí WorkLogu je i možnost zobrazit pro určitý den všechny
odpracovaných
pracovní výkazy se všemi vlastnostmi. Systém spočítá součet všech
hodin WorkLogu
odpracovaných hodin v systému. Navíc umožňuje zvolit jednu službu (například pohotovost) a ta se bude počítat zvlášť.
T8 - Reporty
Report je výpis všech vykázaných hodin v zadaném čase. Report je možné vytvářet pro vybraného zákazníka nebo jeho službu, nebo pro jednoho či všechny zaměstnance. Reporty budou v další verzi aplikace sloužit pro generování mezd a faktur klientům.
TA1 – Technik-
Technik-Administrátor má stejná práva jako technik a navíc může
Administrátor
spravovat služby, zákazníky a jejich uživatele.
TA2 – Správa
Technik-Administrátor může vytvářet nové služby. Každá služba musí
služeb
mít název, tarif a cenu za tarifní jednotku. Služby se také dají editovat a mazat.
TA3 – Správa
Technik-Administrátor může vytvářet nové zákazníky, upravovat nebo
zákazníků
mazat stávající. Každý zákazník má jméno, ID, IČO, DIČ a adresu.
TA4 – Registrace
Technik-Administrátor může registrovat, případně odebírat služby
služeb
jednotlivým zákazníkům. Každý zákazník může mít přiřazený libovolný počet služeb.
TA5 – Nový
Technik-Administrátor může vytvořit nového uživatele bez přístupových
uživatel
práv. Uživatel musí mít přiřazené identifikační číslo zákazníka, ke kterému patří. Na základě uživatelských účtů v aplikaci SH-Portal může Administrátor spárovat vytvořené přístupové účty s uživatelskými, a tím uživatelům přidělit přístupová práva.
2.2.4 Administrátorská sekce Administrátorská sekce slouží k nastavení samotné aplikace a vytvoření hotových stránek z již vytvořených modulů. Je možné zde vytvářet horizontální i vertikální, případně vícestupňová navigační menu. Dají se zde nastavovat pravidla přístupu pro uživatele nebo skupiny uživatelů. Do administrátorské sekce mají přístup pouze uživatelé znající rozhraní aplikace SH-Portal, protože se jedná o velmi mocný nástroj, a v případě špatného použití může dojít k destrukci celých stránek. Aktuálně mají Administrátorskou uživatelskou roli přiřazenou pouze zkušení zaměstnanci společnosti, kteří systém
16
využívají jako redakční systém pro tvorbu webů, a zároveň dochází k pravidelnému zálohování SQL serveru, takže riziko ztráty dat je minimální. Většina administrátorských modulů i funkcí, které s moduly spolupracují, je již součástí aplikace SH-Portal, a proto nebude potřeba tyto moduly znovu vytvářet. Jedinou výjimkou bude přidání záznamu do tabulky s parametry aplikace, která slouží pro konkrétní nastavení některých modulů (například počet zobrazených novinek v modulu Novinky). Bude se jednat o záznam s identifikačním číslem služby Pohotovost, která má vlastní výpis času.
2.3 Modely Vytváření modelů pomáhá identifikovat potřebné služby v další fázi. I v případě, že je navrhovaný systém jednoduchý, je vhodné věnovat tvorbě modelů dostatečný čas. Samozřejmě pak platí úměra, čím složitější je systém, tím komplexnější by měly být i jednotlivé modely. Já uvádím v práci E-R diagram a model případů užití.
2.3.1 E-R Diagram Tento model se v softwarovém inženýrství používá pro abstraktní znázornění dat. V práci jsem nejdříve namodeloval hlavní části databáze, a pak jsem ji rozšiřoval o další části a atributy. Zde je uvedena hlavní část databáze s jejich vztahy, sloužící k ujasnění potřeby uložených informací v databázi. Využívám metodiky Crow’s Foot, která díky absenci kosočtverců přináší dle mého názoru při stejných rozměrech přehlednější graf (Obrázek 2).
17
Obrázek 2 - E-R, Crow’s Foot (Zdroj: vlastní)
2.3.2 Model případů užití Model případů užití, neboli use case diagram se běžně používá při návrhu softwarových projektů pro nalezení hranic, aktérů (uživatelů systému) a možný způsobů využití systému. [7] Uvedený model (Obrázek 3) není kompletním návrhem, slouží spíše k vyjasnění poměrů a pojmů popsaných v katalogu požadavků.
18
Obrázek 3 - Diagram užití (Zdroj: vlastní)
19
3 Návrh řešení V této kapitole popíšu nejprve grafické rozhraní, které bude součástí vyvíjené aplikace, poté srovnám aplikaci s ostatními na trhu a vysvětlím, proč jsme se rozhodli vytvořit vlastní klientský portál. Na konci kapitoly se krátce zmíním o vývojových technologiích.
3.1 Grafické rozhraní Vzhledem k tomu, že jsem nikdy sám nezpracovával tak rozsáhlý projekt a většina literatury ohledně vývoje softwaru se zmiňuje o důležitosti analýzy a návrhu, rozhodl jsem se jako součást práce zpracovat i návrh uživatelského rozhraní (GUI) tak, jak by měla vypadat hotová aplikace. Samotný návrh jsem poté předložil vedoucímu práce a po schválení jsem teprve začal zpracovávat databázový model. Na základě většiny školních i mimoškolních projektů si troufám odhadovat, že právě grafický návrh v prostředí programu Pencil mi pomohl namodelovat funkční aplikaci „na poprvé“, aniž bych ji musel zásadním způsobem měnit během vývoje. Další nezměřitelnou výhodou byla nepopiratelná úspora času. Přesunovat pouze grafické prvky je násobně jednodušší (i časově), než přetvářet celou aplikaci ve vývojovém prostředí. Na základě dosavadních zkušeností si myslím, že dobrá analýza a grafický návrh skutečně může zachránit spoustu projektů a celkový čas na vývoj výrazně zkrátit. Navíc také představa zákazníka se často v praxi liší od reálných možností a právě grafický návrh může vnést pověstné světlo na celý projekt. Zákazník s poskytovatelem služeb mohou dojít k vzájemné shodě, případně odhalit chybu v návrhu, již na začátku projektu. To může ušetřit obrovské zdroje. Například Steve McConnell (1996) odhaduje, že pokud se nepodaří odhalit chybu během specifikace požadavků nebo návrhu, projekt může stát i dvě stě krát tolik, než kdyby se chyba odhalila v rané fázi projektu. [8] V práci uvádím pouze moduly pro přehled požadavků. Další jsou k zobrazení v příloze na přiloženém disku.
3.1.1 Návrh zákaznické sekce Jako první jsem namodeloval zákaznické moduly, protože jsem očekával, že se bude jednat o nejsnazší část. Je zde málo parametrů a i počet všech modulů je mnohem nižší.
20
Obrázek 4 - GUI – Zákazník, přehled požadavků (Zdroj: vlastní)
3.1.2 Návrh technické sekce Pro srovnání vkládám Obrázek 5, na kterém je vyobrazen stejný modul, nýbrž pro technika. Základní funkce obou modulů je totožná, avšak z větších oprávnění technika, vyplývají i rozšířenější možnosti editace požadavků, a tím větší počet editovatelných polí. V horní části se dají zadat parametry pro vyhledávání, pak pomocí tlačítka „Filtrovat“ zobrazíte pouze odpovídající požadavky. Poté z tabulky, která se dá řadit, můžete pomocí sloupce „Zobrazit“ vybrat jednu z položek, a tím se zobrazí detail požadavku a skryje se vyhledávání. Viditelné jsou jednotlivé komentáře, které se dají editovat. Vložit se dá i WorkLog. Zpět na vyhledávání se můžeme dostat pomocí tlačítka „Zpět na výpis“.
21
Obrázek 5 - GUI – Technik, přehled požadavků (Zdroj: vlastní)
22
3.2 Existující řešení Na trhu existuje opravdu nepřeberné množství různých systémů pro správu požadavků. Moje práce se však nezbývá srovnáváním a vybíráním jednoho vhodného řešení. Využil jsem proto poněkud starší, ale o to komplexnější srovnání společnosti Byznysweb (2012), který v době prezentování příspěvku poměrně detailně testoval 28 různých systémů pro správu požadavků. [9] I když rozdíly mezi jednotlivými produkty byly obrovské, jedno tyto systémy spojovalo. Pokud chceme systém s rozšířenými možnostmi nastavení, nezávislý na dodávaných modulech, řešený podle vlastních požadavků, a navíc vlastnit uložená data, je velmi náročné najít vhodného kandidáta. Dalším problém je cena. Služby společnosti FreshDesk, aktuálně pravděpodobně nejprogresivnějšího hráče na trhu5, jsou sice v základní verzi navždy zdarma, ale tato licence nabízí bezplatně pouze tři uživatelské účty pro agenty spravující požadavky. V plné verzi pak stojí tato aplikace dokonce 70 USD za agenta měsíčně. Druhým zástupcem, se kterým jsem se osobně seznámil a aktivně ho používám, je systém Jira od společnosti Atlassian. Zde se mi líbí možnost vytvoření vlastního pole pro vyhledávání požadavků nebo upravený „SQL jazyk“, sloužící k vytváření vlastních složitých filtrů pro vyhledávání požadavků. Avšak například absence možnosti editace předdefinované odpovědi v komentářích, která v nové verzi přibyla, mne ujistila, že tento systém bych svým zákazníkům nedoporučil. Je pravdou, že rozsáhlost projektů a poskytovaných služeb je neporovnatelná se systémem, který je součástí této práce, ale právě jednoduchost a možnost jakéhokoliv rozšíření díky programování v jazyce C# či znovupoužitelnost modulů jsou největší předností mnou vyvíjeného systému. Dalším důvodem pro vývoj aplikace je možnost jejího komerčního využití jako hotového systému pro správu požadavků. A vzhledem k tomu, že systém je vytvářen pro IT společnost, je také vhodné, aby využívala během správy požadavků klientů vlastní systém.
Firma vznikla v roce 2010, prvního zákazníka získala v roce 2011 a nyní na svých stránkách uvádí přes 50 000 zákazníků. Navíc vyhledávač Google nalézá a řadí výsledky společnosti FreshDesk na první místa. To vypovídá nejen o placené reklamě (znamenající silný marketing společnosti), ale i o často vyhledávaném, případně odkazovaném heslu „FreshDesk“.[18] 5
23
Podstatným důvodem pro tvorbu vlastního řešení je možnost řízení a ovlivňování budoucího vývoje aplikace nezávisle na třetí straně.
3.3 Využité technologie V této části popíšu jednotlivé technologie. Aplikace SH-Portal, která je vyvinuta společností Smart Horse, s.r.o, jasně definuje způsob vývoje podruženého systému, a proto je vhodné se o této části zmínit detailněji. Pro kompletnost popisuji i ostatní vývojová prostředí.
3.3.1 .NET Framework V roce 2002 Microsoft uvedl na trh novou platformu .NET. Po téměř 15 letech je více než zřejmé, že firmě Microsoft se povedlo představit funkční řešení, které si získává čím dál větší oblibu. Výhodou této platformy je možnost programovat v jakémkoli podporovaném vysokoúrovňovém jazyce na různých počítačových platformách bez nutnosti měnit nastavení překladačů. Jazyky jsou pak překládány do mezijazyka označovaného jako Common Intermediate Language (CIL). Druhou velkou výhodu přináší .NET v podobě svých knihoven, které umožňují snazší vývoj. Také zajišťuje kompatibilitu aplikací na spuštěných strojích s instalovaným frameworkem v aktuální verzi. [10]
Obrázek 6 - Common Language Infrastructure (Zdroj: https://en.wikipedia.org/wiki/Common_Language_Infrastructure)
24
3.3.2 ASP.NET WebForms ASP.NET je součástí .NET Frameworku, a byl vyvinut pro tvorbu webových aplikací a služeb. Pro práci s webem využívá HTML, CSS a JavaScript. Přestože protokol HTTP je bezstavový, událostmi řízené programování, jakým WebForms jsou, vyžaduje uchování informací při aktualizaci stránky. Řešení ASP.NET nachází v kombinaci HTML a JavaScriptu, konkrétně v poli viewstate. Pokaždé při odeslání formuláře na server se stavy jednotlivých ovládacích prvků zapíší do skrytého kódovaného pole viewstate. Server může jednotlivé prvky upravit a jejich stav (v pozměněném viewstate) odeslat zpět. Jednotlivé prvky jsou dekódovány na serveru a na straně klienta je pak možné je přečíst pomocí kolekce ViewState. [11] Změnu ve viewstate před a po kliknutí na tlačítko dokumentují obrázky Obrázek 7 a Obrázek 8.
Obrázek 7 - Porovnání viewstate – před kliknutím (Zdroj: vlastní)
25
Obrázek 8 - Porovnání viewstate – po kliknutí (Zdroj: vlastní)
3.3.3 Microsoft SQL Server 2012 Jako databázový server jsem během vývoje používal Microsoft SQL Server 2012 ve verzi Express, která je volně dostupná přímo na stránkách Microsoftu. Ačkoliv Visual Studio obsahuje již základní verzi databázového serveru a je možné používat lokální databázi, rozhodl jsem se použít dedikovaný server. SH-Portal standardně běží na serveru s Microsoft SQL Serverem, a proto bylo příhodné na samostatně stojícím serveru i vyvíjet. Například přenos testovacích dat mezi lokální a vzdálenou databází byl velmi jednoduchý, protože jsem mohl být připojen k oběma databázím najednou a pouze data vyexportovat z jedné databáze a naimportovat do druhé. Stejně jednoduše pak probíhala i úprava samotné databáze.
26
Obrázek 9 - MS SQL Server - Pohled požadavek (Zdroj: vlastní)
3.3.4 Visual Studio Team Services Tato webová služba od společnosti Microsoft prošla během posledních několika let velkými změnami. Dnes se jedná o rozsáhlou hostovanou službu, která je však pro malé týmy (do pěti uživatelů) zdarma. Součástí VSTS je i centralizovaný verzovací systém TFVC, kvůli kterému Visual Studio Team Services pro vývoj používáme. Umožňuje nastavit oprávnění pro jednotlivé složky s programovým kódem a díky tomu, že veškeré aktualizace uživatelů se nahrávají zpět na server, je možné auditovat jednotlivé aktualizace kódu, a pomocí komentářů je i hodnotit či schvalovat.
3.3.5 SH-Portal Aplikace SH-Portal byla navržena pro rychlé vytváření webových prezentací, ale i složitých informačních systémů. Výhodou této aplikace, která je vyvíjena v ASP.NET WebForms, je rychlá konfigurace, modulárnost a především jednoduchá přenositelnost
hotových
řešení.
Velkou
předností
je
také
možnost
využití
předdefinovaných šablon s CSS, a tím lehce měnit vzhled jednotlivých prvků a celé webové aplikace, viz Obrázek 10. Důležité je, že šablony vzhledu mohou upravovat také rozložení jednotlivých prvků (modulů) na stránce, a že pro každou stránku lze nastavit jiné rozložení (Obrázek 11). 27
Obrázek 10 - SH-Portal – Šablona vzhledu (Zdroj: http://shweb.cz/Default.aspx?t=101&docid=88)
¨ Obrázek 11 - SH-Portal – Rozložení modulů na stránce (Zdroj: http://shweb.cz/Default.aspx?t=101&docid=88)
Moduly jsou z technického hlediska další ovládací prvky, soubory s příponou ascx, které jsou pomocí aplikace SH-Portal nahrávány na přesně určená místa pomocí Master Page, která je definována předem připravenou šablonou. Díky aplikaci SH-Portal lze vybírat z nabídky hotových modulů z webového rozhraní Administrátora (Obrázek 12), a tím vzniká redakční systém podobný jiným dostupným řešením. Na rozdíl od nich, ale SH-Portal přináší takřka neomezené a velmi jednoduše proveditelné změny ve funkčních modulech, a proto není problém modul vždy upravit přesně dle potřeb zákazníka, případně navrhnout nový modul odvozený od již hotového.
28
Stejně tak vývoj nových modulů je díky ASP.NET velmi jednoduchý. Zakomponování nového modulu prakticky spočívá pouze v jeho nahrání na server. Díky možnosti znovupoužití jednotlivých modulů a rychlému nastavení vzhledu pomocí šablon s předdefinovanými styly je možné vytvářet webové stránky rychle a levně. Navíc má zákazník možnost si aplikaci sám nastavovat, přidávat další stránky, psát a přidávat články pomocí WYSIWYG CKEditor.NET editoru (Obrázek 13), či vytvářet fotogalerie. Lze také upravovat pravidla přístupu, a to vše díky rozhraní správy, které má k dispozici každý zákazník.
Obrázek 12 - SH-Portal – Administrace (Zdroj: http://klient2015.smarthorse.cz/mgmt/Default.aspx?t=11)
Obrázek 13 - SH-Portal – Úprava článku (Zdroj: http://shweb.cz/Default.aspx?t=101&docid=88)
29
SH-Portal je ve své aktuální verzi již pokročilým redakčním systémem. Kromě možnosti změny vzhledu díky CSS či přidávání stránek do systému, je možné na jednotlivých stránkách měnit rozvržení či přidávat moduly. Nasazená aplikace SH-Portal vždy obsahuje moduly pro přihlášení (viz kapitola Bezpečnost 4.5), odhlášení, registraci, změnu hesla nebo přiřazení uživatelských rolí. Tyto moduly jsou esenciálními prvky každé instance aplikace SH-Portal a zákazník nemůže měnit jejich nastavení. SH-Portal má však připravené i další moduly. Mimo specifické moduly pro určité zákazníky (například systém sledování zásilek) jsou k dispozici moduly pro tvorbu webových prezentací a mezi ně patří: moduly pro generování nabídek (horizontálních, vertikálních i vícestupňových), modul pro kontaktní formulář, newsletter, přidávání či editaci článku, modul novinek nebo moduly pro vytváření fotogalerií či slideshow.
3.4 Vývojové prostředí V této části krátce popíšu vývojová prostředí, která jsem použil, mimo známého IDE Microsoft Visual Studia, jsem použil také například SQL Server Management Studio nebo bezplatné nástroje Pencil a online dostupný software pro nákres diagramů užití.
3.4.1 Microsoft Visual Studio Community 2015 Microsoft uvolnil své IDE ve verzi Community již 12. listopadu 2014. Tato verze, funkcemi podobná verzi Visual Studio Professional, nabízí na rozdíl od verze Express více jazyků a podporu dalších rozšíření. Určena je pro malé týmy a v použití do pěti uživatelů je i ke komerčnímu použití zdarma. [12] [13]
30
Obrázek 14 - MS Visual Studio – ukázka (Zdroj: vlastní)
3.4.2 SQL Server Management Studio Velmi mocným nástrojem, se kterým jsem se během výuky nesetkal a sám to považuji za nedostatek, je SQL Server Management Studio. S nadsázkou lze říci, že většina funkcí, které jsem v Management Studiu využíval, je i součástí Visual Studia. Nicméně práci v odděleném programu nebo práci s více databázemi paralelně (dokonce některé z nich mohou být vzdálené a ne lokální), považuji za velkou výhodu a pohodlí.
Obrázek 15 - SQL Server Management Studio – dbo.Zakaznik (Zdroj: vlastní)
31
3.4.3 Pencil Pencil je volně dostupný program vytvořený pro návrh GUI prototypů. Využíval jsem ho pro tvorbu nákresů jednotlivých modulů i celých stránek budoucího systému. Líbí se mi jednoduchost tohoto programu, zároveň ale možnosti, které poskytuje, jsou velmi široké. Například v prosté tabulce lze pomocí různých zástupných znaků vytvořit buňky různého typu. Lze nastavit libovolně velkou pracovní plochu, dá se pracovat ve vrstvách, nabízí zcela zdarma velký výběr předpřipravených grafických prvků, a co považuji za největší přednost, je možnost exportu zcela bez omezení. Buď v PNG formátu anebo ve vektorovém SVG, což přináší export bez komprese.
3.4.4 Creately Inovativní aplikace, kterou používají i takové organizace jako NASA nebo PayPal, nabízí zdarma své služby. Pokud však využíváte aplikaci zdarma, jsou vytvořené návrhy veřejně dostupné k nahlédnutí. Jedná se o velmi pokročilou službu pro tvorbu různých grafických návrhů [14]. Já jsem ji využíval již během studia na vysoké škole a myslím, že není lepší volně dostupný nástroj pro tvorbu nejrůznějších diagramů. Mezi největší výhody řadím možnost tvorby pravoúhlých i zaoblených čar, možnost vypnout kontrolu gramatiky nebo přepínání mezi přichytáváním k mřížce či nikoli. Za velmi užitečnou vlastnost považuji též možnost úpravy a nahlížení na stejný diagram v reálném čase více uživateli. Jedná se o skvělou týmovou funkčnost, kdy je možné daný problém vyřešit se zákazníkem nebo v týmu, a to vzdáleně. Navíc nabízí plugin pro prostředí Jira, které jsem popisoval v kapitole 3.2. Existující řešení.
32
4 Realizace Vývoj trval několik měsíců a nejvíce času zabraly finální úpravy a ladění kódu. Celkově realizaci hodnotím jako náročnou část projektu a to asi hlavně z toho důvodu, že jsem nikdy nepracoval na rozsáhlejším projektu, kde je zapotřebí dlouhodobého neustávajícího úsilí.
4.1 Databáze Data celé aplikace SH-Portal a mnou vytvářených modulů jsou součástí stejné databáze. Z toho důvodu jsem si musel při vzniku nebo upravování databáze na serveru dávat pozor, abych nesmazal žádná data. Pro tvorbu databáze podle navrženého modelu jsem používal Miscrost SQL Management Studio, které mi dovolovalo navrženou strukturu ihned testovat používáním jednoduchých SQL příkazů a značně mi pomohlo ve tvorbě složitějších pohledů. Systém je navržen tak, aby se veškeré vstupy, spojení a omezení řešily aplikačně, což poskytuje určitý vývojářský komfort. Nevýhodou řešení na úrovni aplikace je možné zpomalení systému, nicméně vzhledem k jeho plánované vytíženosti se bavíme o řádu milisekund, což pro klientský portál řešící požadavky zákazníků není překážkou. SQL skript pro vytvoření databáze je dostupný v příloze na disku.
4.2 Moduly Po návrhu všech modulů jsem mohl přistoupit k implementační fázi. Vzhledem k tomu, že aplikace SH-Portal již obsahovala řadu vytvořených modulů, mohl jsem se inspirovat řešením různých problémů jako například v řešení přístupu do databáze nebo způsoby pojmenovávání jednotlivých ovládacích prvků.
4.2.1 Zákazník Pro zákazníka jsou zatím vytvořeny dva moduly – prohlížení požadavků a přidávání požadavků. Tvorba modulů byla po namodelování případů užití a návrhu databáze relativně snadnou záležitostí. Uvádím HTML kód ovládacího prvku gridview, který
33
v aplikaci zobrazuje přihlášenému uživateli požadavky zákaznického profilu, k němuž je podružen.
Obrázek 16 - Ukázka HTML ovládacího prvku GridView (Zdroj: vlastní)
4.2.2 Technik Uživatelská role Technik má k dispozici funkčních modulů více. Byly realizovány moduly pro: přehled požadavků a jeho vytvoření, vytvoření WorkLogu, vytváření Reportů. Navíc je tato role rozšířena o roli Technik-Administrátor, která má další tři moduly – správa zákazníků, uživatelů a správa zákazníků. Na ukázku uvádím Obrázek 17, který je pořízený z již hotové aplikace běžící v testovacím provozu. Je na něm vyobrazen modul s Reporty. V tomto modulu si Technik systému může vybrat období, za které se má report generovat, poté si vybere druh reportu a případně další parametry v závislosti na zvoleném druhu. Modul je řešený za pomoci ovládacího prvku multiview, který zobrazuje pouze vybraný aktivní pohled. Mohl jsem si tedy definovat pro každý druh reportu specifický gridview a vše ponechat na jedné stránce.
34
Obrázek 17 - Ukázka aplikace – Report (Zdroj: vlastní)
4.2.3 Administrátor Pro tuto uživatelskou roli nebyly implementovány žádné moduly, protože již byly kompletně připravené v administrační části aplikace SH-Portal. Pouze jsem doplnil záznam do konfigurační tabulky aplikace SH-Portal ID služby Pohotovost.
4.3 Zajímavé funkce a metody Během psaní kódu aplikace jsem mnohokrát čelil otázce typu „Jak to naprogramovat?“. Většinou jsem pak postupoval metodou pokus-omyl nebo jsem používal uvedených zdrojů.
4.3.1 Označení a změna Služeb zákazníka Úkolem této funkce je označení všech aktuálně přiřazených Služeb vybraného zákazníka. Následně je možné označit či odznačit další nebo některé upravit. Data načítám do list boxu a ten procházím a případně označuji jednotlivé položky v případě shody se záznamem v databázi (Obrázek 18 a Obrázek 19).
35
Obrázek 18 - Ukázka kódu – Změna Služeb zákazníka (Zdroj: vlastní)
Obrázek 19 - Ukázka aplikace – Změna Služeb zákazníka (Zdroj: vlastní)
4.3.2 Výpočet odpracovaných hodin během vybraného dne Tato funkce se používá v modulu WorkLog uživatelské role Technik a počítá odpracované hodiny daného dne. Záznamy jsou uloženy v databázi a mají počáteční a koncový čas. Pomocí vhodných podmínek (ID přihlášeného uživatele, porovnání 36
vybraného dne na ovládacím prvku kalendáře s daty v databázi (Obrázek 20)) nahrávám data do ovládacího prvku gridview. V gridview měním pole, která využívám, na pole šablony (TemplateField), abych mohl s obsahem buněk programově pracovat. Pak již pokračuje níže uvedený kód (Obrázek 21). Pro počítání určité služby zvlášť je ještě zapotřebí pomocí funkce načíst hodnotu z konfigurační tabulky aplikace SH-Portal. Obrázek 22 zobrazuje nastavení na vyčítání služby Pohotovost. Tato funkce již byla součástí řešení SH-Portal.
Obrázek 20 - SQL dotaz pro výpočet odpracovaných hodin (Zdroj: vlastní)
Obrázek 21 - Ukázka kódu – Výpočet odpracovaného času (Zdroj: vlastní) Obrázek 22 - Načtení parametru z aplikace SH-Portal (Zdroj: vlastní)
37
4.4 Základní nastavení aplikace SH-Portal Důležitá nastavení pro ASP.NET aplikace jsou uchována v konfiguračním souboru web.config, který je součástí projektu. V tomto dokumentu jsou uloženy například informace důležité pro komunikaci s databází, nebo možnost zakázat či povolit role v řešení.
Další důležitá nastavení pak jsou v Administrátorském rozhraní aplikace, kde je zapotřebí nastavit ID služby Pohotovost (Obrázek 23), a také nastavit role a jednotlivé uživatele systému k nim přiřadit, k tomu slouží jednoduchý modul pro správu rolí a uživatelů.
Obrázek 23 - Administrace – Parametry aplikace (Zdroj: vlastní)
4.5 Bezpečnost Důležitým prvkem je bezpečnost aplikace. Aby každý zákazník viděl jen svá data a nikdo jiný neviděl data určitého zákazníka je zapotřebí správně autentizovat a autorizovat každého uživatele, který se chce do systému přihlásit. Pro zjišťování dalších zranitelností jsem používal Top 10 OWASP [15] a další dostupné informace na internetu. Je zapotřebí zabezpečit bezpečný chod stránek a to především proti SQL Injection a před základním odposloucháváním z důvodu vulnerability HTTP protokolu.
38
Při řešení IT bezpečnosti by vždy měla odpovídat míra zabezpečení možné výši rizika, protože se zvětšujícími se požadavky na bezpečnost také rostou náklady vynaložené na ochranu. Jelikož se jedná o portál, na kterém jsou uloženy data zákazníků, ale i data interní, snaží se společnost chránit informace například umístěním svého serveru v datovém centru, pravidelnými zálohami a archivací dat, patch managementem nebo zabezpečením před viry a malwarem nasazením firewallů a antivirů.
4.5.1 Autentizace a autorizace První částí zabezpečení je korektní autentizace uživatelů. Autentizace je proces, kdy se ověřuje identita subjektu určitým způsobem. V aplikaci SH-Portal, která používá předdefinovaný modul Login.ascx a Register.ascx se uživatel ověřuje pomocí hesla (splňující zásady nastavené politiky) a uživatelského jména. Hesla jsou ukládána v hashované podobě a z tohoto hlediska není důvod se obávat prolomení. Stejně tak je modul zabezpečený vůči SQL Injection kontrolou vstupů. Po ověření identity uživatele přichází fáze autorizace, což je proces, kdy se uživateli přiřazují práva k určitým operacím. V aplikaci SH-Portal se uživatelská oprávnění přiřazují prostřednictvím uživatelských rolí, které jsou definovány správcem systému a definují přístupová práva každého uživatele ke složkám a modulům systému. Autentizace a autorizace jsou již součástí SH-Portalu a nemusel jsem tyto funkčnosti vyvíjet.
4.5.2 Další zranitelnosti Ve vývojové verzi se nepoužívá šifrovaný protokol (HTTPS), nicméně společnost se zabezpečením pomocí SSL počítá. Tato technologie chrání uživatele (při ověření certifikátu důvěryhodnou certifikační autoritou) proti útokům známým jako Man in the middle, díky kterým útočník může odposlouchávat veškerý provoz. Dokonce se může vydávat za opačnou stranu a upravovat zasílaná data. Při korektním použití HTTPS protokolu s podepsaným certifikátem, dochází k vytvoření dostatečně bezpečného tunelu mezi klientem a serverem a riziko odposlechu je přijatelné. Dalším nebezpečím při použití formulářových prvků jako je text box, je napadení databázové vrstvy programu. Dochází k tomu vsunutím SQL příkazu přes neošetřený vstup. Jsou známé případy použití tohoto útoku i proti takovým společnostem jako je
39
Microsoft [16] nebo poněkud paradoxně MySQL [17], společnost stojící za jednou z nejpoužívanějších databází. ASP.NET validuje vstupy a při nesprávně zadaném vstupu se vyvolá výjimka, která může být ošetřena. Další obranou je předávání parametrů SQL serveru pomocí funkcí Visual Studia, které zajistí převod a kontrolu správné hodnoty, nebo escapování nebezpečných znaků či použití validátorů nebo regulárních výrazů.
40
5 Testování Jelikož jednotlivé moduly není problém testovat již během vývoje nad zkušebními daty, většinu funkčností jsem testoval již lokálně. Druhá vlna testování přišla po zakomponování do aplikace SH-Portal, tentokrát již s použitím šablony. Po vytvoření úvodní sady modulů jsme aplikaci nasadili na veřejnou adresu dostupnou v internetu a od 1. března 2016 běží aplikace ve zkušebním provozu, aniž by společnost používala jiný systém pro správu požadavků. Během testování v ostrém provozu, ve chvíli, kdy aplikaci začali používat zaměstnanci společnosti pro řešení firemních požadavků, se začaly objevovat první funkční nedostatky. Zde uvádím pouze některé. Ty, které čekaly na odstranění během psaní této práce. Pro zaznamenání potřebných změn a úprav, případně nahlášení chyb se již používal klientský portál. Se zvyšujícím se počtem vytvořených požadavků začalo být pro Technika systému velmi nepřehledné implicitní zobrazení všech založených požadavků (i ty uzavřené). Je zapotřebí změnit implicitní nastavení, aby aplikace standardně nezobrazovala požadavky, které jsou „uzavřeny“, a pro lepší přehlednost by bylo vhodné, aby se požadavky v závislosti na stavu barevně odlišily. Dalším prvkem, který jsem během analýzy nezapracoval do návrhu a nyní to pokládám za nedostatek, je absence možnosti nahrání obrázku k požadavku. Obrázek často mnohem lépe popisuje daný problém a stejně tak je dobrým nástrojem pro komunikaci mezi techniky při popisování aktuálního stavu požadavku. WorkLog v případě, že nasčítá více než 24 hodin, zobrazuje odpracovaný čas ve formátu dd:hh:mm. Tento formát zvyšuje náročnost dalšího zpracování, a proto dojde k úpravě na formát hh:mm. V tomto modulu bude zapotřebí krom zmíněného ještě přidat funkčnost, která bude zobrazovat všechny WorkLogy přihlášeného uživatele bez koncového času, protože tyto záznamy pak nejsou ve výpočtu času používány a zůstávají v databázi bez využití, a stávají se tak z nich redundantní data. Posledním větším požadavkem na změnu je přidání práv pro Administrátorský modul správy skupin a uživatelských rolí roli Technik-Administrátor.
41
6 Závěr Na systému jsem pracoval od léta 2015, během celé doby jsem se potýkal s menšími či většími problémy, ale nakonec se mi povedlo naplnit cíle, a to především díky cenným radám vedoucího práce a jeho nekonečné trpělivosti.
6.1 Zhodnocení výsledků Cílem práce bylo vytvořit ucelený systém, který nahradí stávající způsob správy požadavků. Měl jsem rozšířit stávající aplikaci SH-Portal, která do té doby sloužila pouze jako redakční systém. Aplikaci jsem rozšiřoval o funkční moduly, soubory ascx, které jsou v ASP.NET WebForms běžně používány jako ovládací prvky. Tyto funkční celky jsem poté zakomponoval do systému SH-Portal. Aplikace i s nově přidanými moduly, byla nasazena na webový server, kde jsem ji nakonfiguroval a nakonec byla spuštěna do testovacího provozu. Všechny plánované moduly byly úspěšně vytvořeny a otestovány v reálném provozu. Součástí práce byl vývoj modulů pro zákazníky i zaměstnance společnosti. Vzhledem k pozitivnímu výsledku testování a plánům na další rozšiřování systému považuji práci za úspěšnou.
6.2 Problémy a jejich řešení Během vývoje jsem se musel naučit pracovat s novými technologiemi a naučit se týmové práci. Analýza a návrh řešení díky jasně definovaným požadavkům na aplikaci proběhly bez větších úskalí. Implementační část zahrnovala nejen založení databáze, ale i vytváření dotazů a pohledů a procedur vracejících požadované informace. Práci s databází považuji za nejobtíženější, ale zároveň nejzajímavější z celé práce. Naprogramování komponent v jazyku C# a jejich přidání do aplikace SH-Portal sice trvalo déle, než jsem očekával, ale i tak jsem práci bez větších problémů stihl dokončit v požadovaném termínu. Jsem velmi rád, že jsem mohl využít pro řešení problémů pokročilých nástrojů, jakými jsou Visual Studio nebo SQL Server Management Studio.
42
6.3 Možnosti rozšíření a budoucnost systému Ačkoliv souhrn zadaných požadavků byl naplněn, vývoj aplikace bude po úspěšném testování v provozu pokračovat. V první řadě se bude jednat o úpravy některých modulů, které sice plní svoji funkčnost, nicméně jejich použití je v některých případech uživatelsky nepřívětivé. V další vlně vývoje bych rád přidal automatický součet ceny za služby a možnost vytváření předvolených balíčků služeb, které budou pro zákazníka například cenově výhodnější. Důležitým rozšířením aplikace bude přidání notifikací v první řadě e-mailem. Technikovi systému přijde zpráva o změně stavu požadavku, ke kterému je přiřazen, případně pokud bude vytvořen požadavek nový, a s tím spojené logování veškerých změn v systému a jejich ukládání do historie. Do budoucna bych chtěl vytvořit i klienta pro Windows, který by byl součástí oznamovací oblasti (system tray) systému Windows a dovoloval by uživateli rychle zapnout počítání času práce zvoleného požadavku. Tím by se částečně odstranila nutnost zapínání webového klienta a došlo by ke zvýšení pohodlnosti a efektivity práce se systémem.
43
Seznam použité literatury [1] SH web - webové stránky pro každého. SH web [online]. 2016 [cit. 2016-05-25]. Dostupné z: http://shweb.cz/Default.aspx?t=101&docid=88 [2] Životní cyklus softwarového vývoje. PAGE, Alan. Jak testuje software Microsoft. Brno: COMPUTER PRESS, 2009, s. 63. ISBN 9788025128695. [3] Jakých chyb se vyvarovat při implementaci ERP? Hospodářské noviny - byznys, politika, názory (IHNED.cz) [online]. Economia, a.s, 2015 [cit. 2016-05-14]. Dostupné z: http://ihned.cz/c1-64357780-jakych-chyb-se-vyvarovat-pri-implementaci-erp [4] ITIL - výkladový slovník. ItSMF Czech Republic | The IT Service Management Forum [online]. 2012 [cit. 2016-05-21]. Dostupné z: http://itsmf.cz/wp-content/uploads/2013/12/itil_2011_czech_glossary_v2.0.pdf [5] Plnění požadavků. BUCKSTEEG, Martin et al. ITIL 2011. Brno: Computer Press, 2012, s. 159. ISBN 978-80-251-3732-1. [6] Služby a správa služeb. BUCKSTEEG, Martin et al. ITIL 2011. Brno: Computer Press, 2012. s. 81-82. ISBN 978-80-251-3732-1. [7] Prezentace 4a: Modelování podnikových procesů. Kurz: Softwarové inženýrství [online]. 2015 [cit. 2016-05-24]. Dostupné z: https://elearning.vspj.cz/course/view.php?id=738 [8] Rapid development: taming wild software schedules. Redmond: Microsoft Press, c1996, s. 71. ISBN 1-55615-900-5. [9] Jak najít dobrý helpdesk systém? Helpdesk systém zdarma. Levná tvorba webových stránek a eshopu - ByznysWeb [online]. 2012 [cit. 2016-05-19]. Dostupné z: http://blog.byznysweb.cz/2012/06/jak-jsme-novy-helpdesk-system-hledali-nakonec-azdaleke-indii-nasli/ [10] ISO/IEC 23271:2006 - Information technology -- Common Language Infrastructure (CLI) Partitions I to VI. ISO - International Organization for Standardization[online]. 2006 [cit. 2016-05-24]. Dostupné z: http://www.iso.org/iso/catalogue_detail?csnumber=42927 [11] ViewState in ASP.NET - ExtremeExperts. Internet Archive: Wayback Machine [online]. 2008 [cit. 2016-05-19]. Dostupné z: http://web.archive.org/web/20071014005507/http://www.extremeexperts.com/Net/ Articles/ViewState.aspx
44
[12] Microsoft Launches Free, Unrestricted Version.. TechCrunch - The latest technology news and information on startups [online]. 2014 [cit. 2016-05-18]. Dostupné z: http://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/ [13] Bezplatné nástroje pro vývojáře – Visual Studio Community 2015. Visual Studio – Microsoft Developer Tools [online]. 2016 [cit. 2016-05-18]. Dostupné z: https://www.visualstudio.com/products/visual-studio-community-vs [14] Online Diagram Software to draw Flowcharts, UML .. [online]. 2016 [cit. 2016-05-19]. Dostupné z: http://creately.com [15] OWASP top 10 2013. OWASP [online]. 2015 [cit. 2016-05-23]. Dostupné z: https://www.owasp.org/images/f/f3/OWASP_Top_10_-_2013_Final_-_Czech_V1.1.pdf [16] Mass SQL Injection Attack Targets Chinese Web Sites | PCWorld. PCWorld News, tips and reviews from the experts on PCs, Windows, and more [online]. 2008 [cit. 2016-05-20]. Dostupné z: http://www.pcworld.com/article/146048/article.html [17] MySQL.com Database Hacked via SQL Injection. Latest News & Reviews by Softpedia [online]. 2011 [cit. 2016-05-20]. Dostupné z: http://news.softpedia.com/news/MySQL-com-Database-Hacked-via-SQL-Injection191635.shtml [18] Freshdesk - Online customer support software and helpdesk solution [online]. 2016 [cit. 2016-05-19]. Dostupné z: https://freshdesk.com/
45
Seznam obrázků a tabulek Obrázek 1 - Model vodopád (Waterfall)........................................................................... 9 Obrázek 2 - E-R, Crow’s Foot ........................................................................................ 18 Obrázek 3 - Diagram užití .............................................................................................. 19 Obrázek 4 - GUI – Zákazník, přehled požadavků .......................................................... 21 Obrázek 5 - GUI – Technik, přehled požadavků ............................................................ 22 Obrázek 6 - Common Language Infrastructure .............................................................. 24 Obrázek 7 - Porovnání viewstate – před kliknutím ........................................................ 25 Obrázek 8 - Porovnání viewstate – po kliknutí............................................................... 26 Obrázek 9 - MS SQL Server - Pohled požadavek .......................................................... 27 Obrázek 10 - SH-Portal – Šablona vzhledu .................................................................... 28 Obrázek 11 - SH-Portal – Rozložení modulů na stránce ................................................ 28 Obrázek 12 - SH-Portal – Administrace ......................................................................... 29 Obrázek 13 - SH-Portal – Úprava článku ....................................................................... 29 Obrázek 14 - MS Visual Studio – ukázka....................................................................... 31 Obrázek 15 - SQL Server Management Studio – dbo.Zakaznik .................................... 31 Obrázek 16 - Ukázka HTML ovládacího prvku GridView ............................................ 34 Obrázek 17 - Ukázka aplikace – Report ......................................................................... 35 Obrázek 18 - Ukázka kódu – Změna Služeb zákazníka ................................................. 36 Obrázek 19 - Ukázka aplikace – Změna Služeb zákazníka ............................................ 36 Obrázek 20 - SQL dotaz pro výpočet odpracovaných hodin .......................................... 37 Obrázek 21 - Ukázka kódu – Výpočet odpracovaného času .......................................... 37 Obrázek 22 - Načtení parametru z aplikace SH-Portal ................................................... 37 Obrázek 23 - Administrace – Parametry aplikace .......................................................... 38
Tabulka 1 - Definice použitých pojmů ........................................................................... 11 Tabulka 2 - Funkční požadavky: Nepřihlášený uživatel ................................................ 13 Tabulka 3 - Funkční požadavky: Zákaznická sekce ....................................................... 14 Tabulka 4 - Funkční požadavky: Technická část ............................................................ 15
46
Seznam použitých zkratek ASP.NET - Active Server Pages, network CIL – Common Intermediate Language CSS – Cascading Style Sheets (Kaskádové styly) DIČ – Daňové identifikační číslo ERD – Entity Relationship Diagram (E-R Diagram, entitně vztahový model) GUI – Graphical User Interface (Grafické uživatelské rozhraní) HTML – HyperText Markup Language HTTPS – Hypertext Transfer Protocol Secure IČO – Identifikační číslo osoby ID – Identifikátor, identifikační číslo IDE – Integrated Development Environment– (Vývojové prostředí) IS – Informační systém IT – Informační technologie ITIL – IT Infrastructure Library PNG – Portable Network Graphics (Přenosná síťová grafika) SQL - Structured Query Language (Strukturovaný dotazovací jazyk) SSL – Secure Sockets Layer SVG – Scalable Vector Graphics (Škálovatelná vektorová grafika) TFVC – Team Foundation Version Control (Team Foundation – správa verzí) USD – United States dollar (Americký dolar) VSTS – Visual Studio Team Services WYSIWYG – What you see is what you get (akronym, „co vidíš, to dostaneš“)
47
Obsah přiloženého CD Na přiloženém CD se v kořenovém adresáři nachází tato bakalářská práce ve formátu bakalarska_prace.pdf a přílohy uložené ve složce Přílohy jako jednotlivé dokumenty.
48
