České vysoké učení technické v Praze. katedra počítačů BAKALÁŘSKÁ PRÁCE. Konfigurační databáze

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

BAKALÁŘSKÁ PRÁCE Konfigurační databáze

Autor: DOUBRAV Lukáš Vedoucí práce: MACEK Ondřej Ing.

Praha 2011

ii

Prohlašuji, že jsem předloženou práci vypracoval samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce a jejím zveřejňováním. V Praze dne 16. května 2011

DOUBRAV Lukáš

v

vi

Na tomto místě bych chtěl poděkovat Ing. O. Mackovi za poskytnutí řady odborných konzultací.

Název práce: Konfigurační databáze Autor: DOUBRAV Lukáš Katedra: Katedra počítačů Vedoucí bakalářské práce: MACEK Ondřej Ing. Abstrakt: Klíčová slova:

Title: Configuration database Author: DOUBRAV Lukáš Department: Department of Computer Science and Engineering Supervisor: MACEK Ondřej Ing. Abstract: Keywords:

ix

x

Obsah Zadání práce

iii

Abstrakt

ix

Úvod

1

1 Motivace 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Vlastní řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Podobné projekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 4 4

2 Analýza a návrh řešení 2.1 Analýza byznys procesů . . . . . . . . . . . . . 2.1.1 Požadavek HW . . . . . . . . . . . . . . 2.1.2 Nákup HW . . . . . . . . . . . . . . . . 2.1.3 Vyřazení HW . . . . . . . . . . . . . . . 2.2 Katalog požadavků . . . . . . . . . . . . . . . . 2.2.1 Funkční požadavky: . . . . . . . . . . . 2.2.2 Nefunkční požadavky: . . . . . . . . . . 2.3 Případy užití . . . . . . . . . . . . . . . . . . . 2.3.1 10 Vytvoření HW . . . . . . . . . . . . . 2.3.2 14 Vytvoření předávacího protokolu . . 2.3.3 15 Vytvorření návrhu na vyřazení . . . . 2.3.4 16 Vytvoření protokolu o odbernání HW 2.3.5 17 Schválnení návrhu na vyrazení HW . 2.3.6 26 Potvrzení odbrání HW . . . . . . . . 2.3.7 27 Přidělení evidenčního čísla . . . . . . 2.3.8 28 Přidělení čísla objednávky . . . . . . 2.4 Doménový model . . . . . . . . . . . . . . . . . 2.5 Programovací metoda MVC -> orazek mvc . . 2.6 Návrhový systém, implementační platforma . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 7 7 8 12 14 14 15 15 16 17 18 19 19 20 21 21 22 24 25

3 Implementace 3.1 Datový model . . 3.1.1 Inkrement 3.1.2 Inkrement 3.1.3 Inkrement 3.1.4 Inkrement

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

27 27 29 29 30 31

. 1 2 3 4

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

xi

. . . . .

. . . . .

. . . . .

xii

OBSAH 3.2 3.3 3.4 3.5

Zdrojový kód . . . . Grafické rozhraní . . Ergonomie ovládání Škálovatelnost (API)

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 Testování 4.1 White box testing . . . . . . . . . . . . . . . . . . . . . . . 4.2 Black box texting (akceptační test) . . . . . . . . . . . . . . 4.2.1 Test 1: Přidání již existujícího HW . . . . . . . . . 4.2.2 Test 3: Požadavek na pořízení HW (nový HW) . . . 4.2.3 Test 4: Přidělení čísla objednávky . . . . . . . . . . 4.2.4 Test 6: Přidělení inventárního čísla . . . . . . . . . 4.2.5 Test 7: Předávací protokol vytvoření . . . . . . . . . 4.2.6 Test 9: Protokol o odebrání HW vytvoření . . . . . 4.2.7 Test 11: Změna uživatele HW . . . . . . . . . . . . 4.2.8 Test 12: Návrh na vyřazení . . . . . . . . . . . . . . 4.2.9 Test 13: Schválení návrhu na vyřazení (logistik) . . 4.2.10 Test 14: Schválení návrhu na vyřazení (vedoucí csiit) 4.2.11 Test 25: Zapůjčení HW . . . . . . . . . . . . . . . . 4.2.12 Test 27: Vrácení zapůjčeného HW . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

33 33 33 33

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35 35 35 35 35 35 36 36 36 36 36 36 36 37 37

. . . . . . . . . . .

Závěr

39

Literatura

41

[co je to konfigurační databáze...]

1

2

OBSAH

Kapitola 1

Motivace 1.1

Úvod do problematiky

Každá firma v dnešní době potřebuje pro svůj provoz a rozvoj výpočetní techniku. Výpočetní technika potřebuje pravidelnou údržbu, kontrolu a obměnu. V menších firmách není problém udržovat povědomí a přehled o výpočetní technice, jedná-li se o počty v řádu jednotek počítačů, tiskáren apod. Tuto činnost zajišťuje pravděpodobně jeden zaměstnanec, který má i zmocnění pořídit nový počítač, objednat opravu, či náhradní díl. Rozhodování o těchto investicích probíhá ve zkráceném řízení přímo s nejužším vedením firmy. U společností středních a velkých tuto aktivitu zajišťují různá oddělení. O nákup zařízení včetně výpočetní techniky, jejich evidence a účetní úkony se stará oddělení správy majetku resp. logistiky. Zaměstnanci tohoto oddělení, ale nemají pro výběr výpočetní techniky dostatečnou kvalifikaci ani informace. O to se stará jiiné oddělení, oddělení pro správu výpočetní techniky. Toto specializované oddělení zajišťuje správu zařízení skrze celou společnost, mnohdy rozdělenou na několik dislokovaných poboček. Zaměstnanci oddělení pro správu výpočetní techniky, spráci, osobně připravují k předání a následně předávají nový hardware do rukou zaměstnanců, vyřizují opravy a odstraňují zastaralá zařízení, vytváří speficikace a konfigurace výpočetní techniky podle požadavku uživatelů. Tyto informace dále poskytují zaměstnancům logistiky, kteří tyto změny evidují ve specializovaném systému a zajišťují přímé objednání daných zařízení. Z předcházejícího plyne první požadavek na informační systém, kterým je automatizace a sjednocení předávání informací o výpočetní technice mezi oddělením logistiky a oddělením pro správu výpočetní techniky. S výměnou informací mezi logistikou a správci výpočetní techniky souvisí také jednoznačnost označení výpočetní techniky. Pro potřeby logistiky jsou jediným přĳatelným ientifikátorem evidenční číslo zařízení, které jim přidělí. Toto číslo je nalepeno na kryt zařízení. Identifikace zařízení na tomto základě má hned několik nevýhod. První a nejzásadnější nevýhodou je nutnost fizické přítomnosti osoby při identifikaci zařízení. Tato osoba musí štítek nejprve najít, poté správně přečíst a tuto informaci teprve následně předá správci. Může se stát, že bude štítek s evidenčním číslem úmyslně či neúmyslně poškozen, umístěn na nevhodném místě, nebo jen může dojít k opomenutí a tento štítek se na zařízení vůbec nedostane. Správci výpočetní techniky identifikují zařízení na základě jejich sériových čísel. Tato čísla jsou nejen vylepena na každém zařízení, ale jsou i implementována v elektronické podobě uvnitř zařízení. Tuto elektronickou podobu je schopen správce načíst i vzdáleně, je-li zařízení připojeno do počítačové sítě. Aby vše bylo ještě o něco složitější tak informační systémy, které jsou využívány logistikou pro evidenci majetku mají vestavěnou nativní podporu právě pro evidenční čísla a nikoli pro sériová. Tímto nám vykrystalizoval další požadavek na informační systém, kterým je uchování informace o páru evidenčního a sériového čísla náležící jednomu zařízení.

3

4

KAPITOLA 1. MOTIVACE

Další změna spojená s nárůstem počtu spravovaných zařízení a počtu jejich správců je způsob odstraňování potíží na zařízeních a podpora jejich uživatelů. S rostoucí vzdáleností výpočetní technky od správců se začínají využívat metody pro vzdálenou správu a podpru. Problémem této metody je způsob identifikace zařízení. Nutnost zásahu správce hlasí nejčastěji uživatel zařízení, z toho vyplývá že nejefektivnější způsob zařízení je přes uživatele. Jednoznačná identifikace zařízení na základě uživatele je tedy dalším požadavkem na informační systém. Je zvykem, že pro správu určitého množství zařízení, nebo určité lokality je vyhrazen jeden správce. Tento správce však musí být zastupitelný v případě nemoci, dovolené apod. Aby bylo možné zajistit kvalitní zastoupení je nutné vést dokumentaci o nestandardních řešeních, specielních režimech, specifikacích jednotlivých zařízení, zárukách apod. Často se stává, že jednotliví správci, kteří se navzájem zastupují nejsou v osobním kontaktu, což snižuje možnost výměny informací. Informace o výpočetní technice se v různých lokalitách evidují v různých formách odpovídajících potřebám místních správců a uživatelů. Dalším logickým požadavekem je tedy unifikovaná evidence informací o zařízeních výpočetní techniky.

1.2

Vlastní řešení

Na základě výše uvedených požadavků jsem se rozhodl vytvořit informační systém, který pokryje tyto požadavky a zefektivní agendu týkající se správy výpočetní techniky. Systém pro správu výpočetní techniky (SVT) implementuje pouze základní metody a nezabývá se příliš spcifickýmy požadavky. SVT je postaven na serverovém řešení ve formě webové aplikace. Jako klient pro práci se systémem postačí jakýkoli prohlížeč internetového obsahu implementující javascript. Takto k systému může přistupovat i správce v terénu a se zařízeními na různých platformách. Webová aplikace také umožní jednoduché škálování a rozšiřitelnost celého systému. Systém rozenává několik uživatelských rolí a k nim náležící funkcionality, které implementují základní business procesy vynucené vnitřími předpisy společnosti. Jiné úkoly v systému muže provádět logistik, jiné správce a jiné administrátor. Blíže se těmto rozdělením a procesům věnuji v následujících kapitolách. Předávání informací mezi oddělením logistiky a oddělením pro správu výpočetní techniky je zajištěno jednak zasíláním notifikací mailem a jednak implementací business logiky na jednotlivé role uživatelů formou generování příslušných požadavků. Pomocí požadavků je také zajištěno uložení informace o dvojici evidenční a sériové číslo, které v systému vystupují se stejnou vahou. Plnění databáze daty je požadováno přímo po uživatelích, systém žádným způsobem data automaticky neplní z jiných aplikací. Tento přístup byl použit čistě z pragmatických důvodů. Cílem systému není nahradit úkony zaměstnanců, ale pouze jejich zefektivnění a odstranění určitého stereotypu a redundance těchto úkonů. V celém systému vystupují objekty reprezentující předměty reálného světa. Tyto objekty jsou uloženy do relační databáze, která zajistí rychlou reakční dobu, stabilitu a konzistenci dat a umožní využívat data i jiným aplikacím. Nejdůležitějšími objekty jsou uživatel, který reprezentuje osobu využívající nějaké zařízení výpočetní techniky a zařízení reprezentující přímo zařízení výpočetní techniky. Informace o jednotlivých zařízeních jsou implementovány jako objekt poznámka.

1.3

Podobné projekty

Existuje široká řada systémů pro evidenci majetku, či pro evidenci a správu počítačů. Všechny tyto sytémy jsou však příliš sofistikované a neumožňují přístup k určitým datům na základě rolí a nemají možnost implementace business procesů, fungují pouze jako evidenční systémy. Jako reprezentanta systému pro správu majetku mohu uvést systém Helios Green, který velmi podrobně zpracovává evidenci jak po logistické tak po účetní stránce. Nevýhodou systému je velmi

1.3. PODOBNÉ PROJEKTY

5

špatná podpora sériových čísel. Možnost k určitému majetku přiřadit sériové číslo sice existuje, systém však nedokáže podle těchto čísel indexovat a vyhledávat. Další nevýhodou je nutnost licence pro každého správce, tedy finanční náročnost. Mezi software používaný pro správu počítačů patří například Lan-Desk. Tento sytém velmi dobře pracuje se sériovými čísly, které dokáže načítat i vzdáleně. Nevýhodou je nemožnost přidat informaci o evidenčním číslu, nebo uživateli zařízení. Další nevýhodou je omezený repertoár zařízení, které je možné tímto systémem evidovat. Mezi neméně významné nedostatky je i velmi malá schopnost rozlišení přístupu k určitým oblastem systému na základě rolí.

6

KAPITOLA 1. MOTIVACE

Kapitola 2

Analýza a návrh řešení 2.1

Analýza byznys procesů

Každá společnost, která řeší problém neefektivity a malého výkonu pracovníků časem dojde k tomu, že je nutné popsat a následně implementovat postupy, které budou tyto neduhy řešit. Vesměs tyto problémy řeší politika řízení jakosti, kde jsou popsány postupy a náležitosti učitých úkonů. Cílem analýz těchto postupů je získat přehled o současném stavu systému provádění daných úkolů a navrhnout jejich automatizaci a optimalizaci, která povede k zvýšení efektivity. Jako prostředek pro zlepšení je nejvhodnější použit informační systém, který bude implementovat konfigurační databázi a nativně podporovat analyzované byznys procesy.

2.1.1

Požadavek HW

Pro pořízení, resp. vyřazení zařízení je nutný oficiální pokyn od kompetentní osoby. Tento pokyn se provádí vyplnění speciálního formuláře Požadavek HW. Tento požadavek vyplňuje pro svého podřízeného příslušný vedoucí oddělení, nebo vedoucí CSIIT, který může podat požadavek týkající se kteréhokoli zaměstnance. Jestliže se cena zařízení odhaduje pod 40tis. Kč, stačí potvrzení od ředitele příslušné pobočky, v opačném případě je nutné schválené ředitele celé divize. Formulář Požadavek HW je vytvořen v slouladu s vnitřím programem pro řízení jakosti a následně zajišťuje nezbytné podmínk pro certifikaci ISO. Tento dokument zajišťuje provedení několika různých úkonů, kromě zmíněného pořízení a vyřazení zařízení, také převod zařízení na jiného zaměstnance, pořízení programového vybavení, či upgrade zařízení. Formulář zatím nebyl oficiálně převeden do elektronické formy a proto systém neřeší jeho implementaci a vystupuje v systému pouze jako naskenovaný dokument.

7

8

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

Obrázek 2.1. Požadavek HW

2.1.2

Nákup HW

Současná stav 1. správce obdrží (mail) schválený požadavek HW/SW - pořízení HW 2. správce požádá (mail obsahuje požadavek na HW/SW) o přidělení čísla objednávky pracovníka logistiky

2.1. ANALÝZA BYZNYS PROCESŮ

9

3. logistik založí objednávku v Heliosu 4. logistik pošle (mail) správci číslo objednávky 5. správce poptá (mail) u dodavatele HW 6. správce nabídku+požadavek HW/SW (mail) pošle ke schválení vedoucímu CSIIT 7. správce na základě nabídky vytvoří objednávku s číslem objednávky, které obdržel od logistika 8. pošle objednávku (mail) dodavateli 9. dodavatel pošle potvrzení (mail) správci 10. správce potvrzení přepošle (mail) logistikovi, správcům pobočky, které se nákup týká, vedoucímu CSIIT, řediteli pobočky 11. správce při převzetí dodaného zboží archivuje dodací list 12. fakturační oddělení informuje logistika o zaplacení faktury (helios) 13. logistik přidělí inventární číslo HW 14. logistik přepošle (mail) inventární číslo správci 15. správce připraví HW pro předání 16. správce vytvoří předávací protokol (zaznamená STAG, inventární číslo, uživatele, datum předání) 17. správce předá HW uživateli 18. správce informuje (mail) logistika o přidělení HW 19. logistik polepí HW štítkem s inventárním číslem

Nevýhody • není definováno umístění dokumentů týkajících se jednoho HW (faktura, dodací list, inv.č., s-tag, objednávka, nabídka, předávací protokol) • není zaručeno spárování s.tag, inv.č.

• mailová komunikace není efektivní (přeposílání příloh, duplicity) • ruční vytváření předávacího protokolu

S využitím systému 1. správce obdrží (mail) schválený požadavek HW/SW - pořízení HW 2. správce vloží požadavek do IS 3. IS kontaktuje logistika o novém požadavku na číslo objednávky 4. logistik založí objednávku v Heliosu 5. logistik vloží číslo objednávky do IS 6. IS kontaktuje správce o přidělení čísla objdenávky 7. správce poptá (mail) u dodavatele HW 8. správce nabídku vloží do IS

10

KAPITOLA 2. ANALÝZA A NÁVRH ŘEŠENÍ 9. IS informuje vedoucího CSIIT o požadavku na schválení nabídky

10. vedoucí CSIIT v IS potvrdí/zamítne nabídku 11. IS informuje správce o události 12. správce na základě nabídky vytvoří objednávku s číslem objednávky, které obdržel v IS 13. pošle objednávku (mail) dodavateli 14. dodavatel pošle potvrzení (mail) správci 15. správce potvrzení vloží do IS 16. IS informuje o potvrzení objednávky ostatní správce, vedoucího CSIIT, logistika, ředitele pobočky 17. správce při převzetí dodaného zboží vloží do systému dodací list, vytvoří záznam o novém HW 18. fakturační oddělení informuje logistika o zaplacení faktury (helios) 19. logistik vloží do IS fakturu 20. logistik přidělí inventární číslo HW 21. logistik vloží inventární číslo do IS 22. IS informuje správce o nové události 23. správce předá HW uživateli 24. správce vytvoří záznam o předání v IS 25. IS informuje logistika o předání 26. logistik polepí HW štítkem s inventárním číslem

Zlepšení • veškeré informace se hromadí v IS • odpadá nutnost přeposílat maily s přílohou (pořadavek, nabídka, potvrzení objednávky) • protokol o předání se generuje automaticky na základě vložených informací do IS • automaticky se zaznamenává informace o páru s.tag, inv.č.

2.1. ANALÝZA BYZNYS PROCESŮ

Obrázek 2.2. Nákup zařízení

11

12


2.1.3

Vyřazení HW

Současná stav 1. správce obdrží (mail) požadavek HW/SW - vyřazení HW 2. spravce vytvoří návrh na vyřazení (formou odprodeje, ekologické likvidace, rozebrání na náhradní díly) 3. správce odešle (mail) návrh ke schválení vedoucímu CSIIT 4. vedoucí CSIIT potvrdí/zamítne návrh 5. vedoucí rozhodnutí pošle (mail) správci 6. správce pošle (mail) návrh logistikovi 7. logistik na základě návrhu vytvoří vyřazovací protokol 8. logistik předá vyřazovací protokol ke schválení ředitely pobočky 9. logistik po schválení vyřadí HW z evidence v systému Helios 10. logistik informuje (mail) správce o vyřazení 11. správce naloží s HW podle návrhu na vyřazení

S využitím systému 1. správce obdrží (mail) požadavek HW/SW - vyřazení HW 2. správce vloží požadavek HW/SW do IS 3. spravce vytvoří návrh na vyřazení (formou odprodeje, ekologické likvidace, rozebrání na náhradní díly) v IS 4. IS informuje vedoucího CSIIT o požadavku na schválení 5. vedoucí CSIIT potvrdí/zamítne návrh v IS 6. IS informuje správce o výsledku 7. IS informuje logistika o požadavku na vyřazení 8. logistik vytvoří vyřazovací protokol 9. logistik předá vyřazovací protokol ke schválení ředitely pobočky 10. logistik po schválení vyřadí HW z evidence v systému Helios 11. logistik zaznamená vyřazení v IS 12. IS informuje správce o nové události 13. správce naloží s HW podle návrhu na vyřazení

2.1. ANALÝZA BYZNYS PROCESŮ Zlepšení • systém zjednodušuje vytvoření návrhu na vyřazení (z uložených informací) • zefektivňuje komunikaci (neposílá mail s přílohou) • udržuje informaci o tom, který HW je vyřazen

Obrázek 2.3. Vyřazení zařízení

13

14

2.2


Katalog požadavků

Katalogem požadavků je myšlen soubor vlastností, které informační systém musí splňovat. Vychází z požadavků zadavatele a budoucích uživatelů a splňuje podmínky pro implementaci výše zmíněných byznys procesů a jejich optimalizaci. Na základě katalogu požadavků je možné navrhnout případy užití, které poslouží k přesnější definici funkcionality systému.

2.2.1

Funkční požadavky:

1 správa databáze zaměstnanců 1.1

zobrazení seznamu zaměstnanců

1.2

zobrazení detailního náhledu zaměstnance

1.3

vytvoření nového záznamu zaměstnance

1.4

úprava existujícího záznamu zaměstnance

1.5

zrušení záznamu zaměstnance

2 správa databáze HW 2.1

zobrazení seznamu HW

2.2

zobrazení detailního náhledu HW

2.3

vytvoření nového záznamu HW

2.4

úprava existujícího záznamu HW

2.5

zrušení záznamu HW

2.6

vytvoření předávacího protokolu

2.7

vytvoření protokolu o odebrání

2.8

vytvoření návrhu na vyřazení

2.9

potvrzení / zmítnutí návrhu na vyřazení

2.10

vytvoření požadavku na pořízení HW

2.11

přidělení čísla objednávky

2.12

přidělení evidenčního čísla

2.13

záznam o zapůjčení / vrácení HW

2.14

vytvoření protokolu o zapůjčení HW

2.15

vložení poznámky

3 správa databáze pobočky 3.1

zobrazení seznamu poboček

3.2

zobrazení detailního náhledu pobočky

3.4

vytvoření nového záznamu pobočky

3.5

úprava existujícího záznamu pobočky

3.6

zrušení záznamu pobočky

2.3. PŘÍPADY UŽITÍ

15

4 správa databáze divize 4.1

zobrazení seznamu divize

4.2

zobrazení detailního náhledu divize

4.4

vytvoření nového záznamu divize

4.5

úprava existujícího záznamu divize

4.6

zrušení záznamu divize

5 automatická notifikace příslušných uživatelů u definovaných akcí 5.1

prostřednictvím emailu

5.2

prostřednictvím sms

2.2.2

Nefunkční požadavky:

6 přístup pomocí webového rozhraní 8 přístup k různým zdrjům na základě rolí (vlastnost systému) 9 serverová čás na Microsoft Windows platfomě

2.3

Případy užití

Případy užití popisují dílčí operace nad systémem. Slouží k lepšímu pochopení jednotlivých operací, které jsou v systému prováděny a ke konečné definici všech funkcionalit, které systém bude nabízet. Zde je uveden pouze vzorek požadavků, které jsou stěžejními pro ilustraci zavedených zlepšení. Celý katalog případů užití je uveden v příloze. Kromě klasického způsobu zápisu případů užití je u každého případu uveden seznam zlepšení, které systém zavádí. Pro větší názornost je zde uveden obrázek se všemi případy užití, rozdělenými podle tématických okruhů. Toto rozdělení bylo následně použito při plánování realizace jednotlivých částí systému.

16


Obrázek 2.4. Případy užití

2.3.1

10 Vytvoření HW

10.1

spustí volbu pro vstup do části systému spravující HW

10.2

zobrazí seznam HW

10.3

spustí volbu pro vytvoření HW

10.4

zobrazí formulář pro zadání ivn.č., s.tag.,popisu HW

10.5

vyplní potřebné údaje

10.6

spustí volbu pro pokračování

10.7

zobrazí formulář pro výběr uživatele

10.8

vybere uživatele (podle jména, čísla, pobočky...)

10.9


10.10

zobrazí formulář pro vložení faktury, dodacího listu, objednávky, požadavek na HW

10.11

vloží náležité soubory (nemusí)

10.12

spustí volbu pro uložení

10.13

uloží HW

2.3. PŘÍPADY UŽITÍ 10.14

zobrazí seznam HW

10.5a

nezná inv.č.

10.5a.1

vytvoří žádost o přidělení inv.č.

10.5a.2

pošle mail logistikovi

10.5a.3

označí HW jako neúplný

10.5a.4

pokračuje v bodě 10.6

10.5b

nezná s.tag.

10.5b.1

zobrazí formulář pro vložení požadavku na HW

10.5b.2

vloží požadavek na HW

10.5b.3

vytvoří žádost o přidělení čísla objednávky

10.5b.4


10.5b.5

označí HW jako neúplný

10.5b.5


10.6a

spustí volbu pro přerušení

10.6a.1


10.7a

uživatel neexistuje

10.9a


10.9a.1


10.12a


10.12a.1


Přínosy • vynutí spárování inv.č. a stag

• shromáždí dokumenty a informace o HW na jednom místě

• komunikace mezi členy různých oddělení je automatizovaná tj. spolehlivější • vynutí dodržení nařízeného postupu

2.3.2

14 Vytvoření předávacího protokolu

14.1


14.2

zobrazí seznam uložených HW

14.3

vyhledá HW v seznamu (podle uživatele, s.tagu, inv.č., č.objednávky)

14.4

označí HW

14.5

spustí volbu pro vytvoření předávacího protokolu

14.6

zobrazí formulář s položkou datum předání

17

18


14.7

vyplní datum

14.8

spustí volbu pro vytvoření předávacího protokolu

14.9

uloží předávací protokol

14.10

zobrazí formulář předávacího protokolu

14.11

spustí volbu pro tisk

14.12

vytiskne předávací protokol

14.13

pošle mail správcům pobočky, logistikovi

14.14

zobrazí seznam HW

14.9a

neexistuje inv.č.

14.9a.1

vytvoří požadavek na přidělení inv.č.

14.9a.2


14.9a.3


Přínosy • vynutí pracovní postup

• usnadní komunikaci (je automatizovaná) • předvyplní formulář (eliminace chyby)

2.3.3

15 Vytvorření návrhu na vyřazení

15.1


15.2


15.3


15.4

označí HW

15.5

spustí volbu pro vytvoření návrhu na vyřazení

15.6

zobrazí formulář pro vložení soboru s požadavkem na HW

15.7

předá soubor

15.8


15.9

zobrazí formulář pro zadání důvodu vyřazení, způsobu likvidace

15.10

vyplní příslušné údaje

15.11

spustí volbu pro dokončení

15.12

vytvoří požadavek na schválení návrhu na vyřazení

15.13

pošle mail vedoucímu CSIIT

15.14

zobrazí seznam HW

2.3. PŘÍPADY UŽITÍ Přínosy • vynutí pracovní postup


2.3.4

16 Vytvoření protokolu o odbernání HW

16.1


16.2


16.3


16.4

označí HW

16.5

spustí volbu pro vytvoření odebíracího protokolu

16.6

zobrazí formulář pro vložení požadavku HW, datum odebrání

16.7

předá soubor a vyplní datum

16.8


16.9

uloží odebírací protokol

16.10

zobrazí formulář odebíracího protokolu

16.11

spustí volbu pro tisk

16.12

vytiskne odebírací protokol

16.13

pošle mail správcům pobočky, logistikovi

16.14

zobrazí seznam HW



2.3.5

17 Schválnení návrhu na vyrazení HW

17.1

spustí volbu pro vstup do části systému spravující návrhy na vyřazení

17.2

zobrazí seznam uložených návrhů

17.3

vyhledá návrh v seznamu (podle uživatele, HW, id, zhotovitele návrhu)

17.4

označí návrh

17.5

spustí volbu pro náhled návrhu

17.6

zobrazí formulář s pložkami HW, odůvodnění

17.7

spustí volbu pro schválení

17.8

uloží návrh

19

20


17.9

vytvoří žádost o odebrání HW z evidence

17.10

pošle mail logistikovi, správcům pobočky

17.11

zobrazí seznam návrhů na vyřazení

17.7a

spustí volbu pro zamítnutí

17.7a.1

uloží návrh

17.7a.2

pošle mail správci (tvůrci požadavku)

17.7a.3


Přínosy • vynutí pracovní postup • usnadní komunikaci (je automatizovaná)

2.3.6

26 Potvrzení odbrání HW

26.1

spustí volbu pro vstup do části systému spravující požadavky

26.2

zobrazí seznam požadavků

26.3

vyhledá požadavek na odebrání HW (číslo požadavku, HW, zadavatel)

26.4

označí požadavek

26.5

spustí volbu pro zobrazení

26.6

zobrazí detaily požadavku (HW, zadavatel)

26.7

spustí volbu pro potvrzení odebrání HW z majetku

26.8

uloží požadavek na odebrání HW

26.9

pošle mail správcům pobočky

26.10

zobrazí seznam poboček

Přínosy • vynutí pracovní postup • usnadní komunikaci (je automatizovaná) • urychlí postup

2.3. PŘÍPADY UŽITÍ

2.3.7

27 Přidělení evidenčního čísla

27.1


27.2


27.3

vyhledá požadavek na přidělení inv.č. (číslo požadavku, zadavatel)

27.4

označí požadavek

27.5


27.6


27.7

spustí volbu pro přidělení inv.č.

27.8

zobrazí formulář pro zadání inv.č.

27.9

vyplní ivn.č.

27.10

spustí volpu pro pokračování

27.11

uloží požadavek

27.12



• usnadní komunikaci (je automatizovaná) • urychlí postup

2.3.8

28 Přidělení čísla objednávky

28.1


28.2


28.3

vyhledá požadavek na přidělení č. ojednávky (číslo požadavku, zadavatel)

28.4

označí požadavek

28.5


28.6


28.7

spustí volbu pro přidělení č.objednávky

28.8

zobrazí formulář pro zadání č.objednávky

28.9

vyplní č.objednávky

28.10

spustí volpu pro pokračování

28.11

uloží požadavek

28.12


21

22



• usnadní komunikaci (je automatizovaná) • urychlí postup

Obrázek 2.5. HardUse

2.4

Doménový model

Základním prvkem infomračního systému jsou data. Proto je prvním krokem k úspěšné implementaci pojmenování jendotlivých dat a jejich uskupejní a popis jednotlivých závislostí. Pro názoros jsou jednotlivé objekty a vztahy mezi nimi modelovány pomocí diagramu.

2.4. DOMÉNOVÝ MODEL

23

Obrázek 2.6. Doménový model

24

2.5


Programovací metoda MVC -> orazek mvc

Přístup k programování pomocí metody MVC roděluje programový kód na tři základní separovatelné části. Těmi jsou model, view a controler. Tyto části jsou uchovávány odděleně, většinou i v separátních souborech. Základní myšlenkou celého konceptu je předpoklad, že je možné každý projek rozdělit na část charakterizující datový obsah, část reprezentující grafické rozhraní a část zprostředkovávající logiku aplikace. Tento přístup zajišťuje škálovatelnost a přehlednost kódu, při editaci a úpravě jednoho modulu je nemožné negativně ovlivnit jiné moduly. Je možné například upravit grafické rozhraní (view) aniž by bylo nutné zasahovat do jiné části kódu aplikace. Proto je možné části projektu rodělit mezi různé týmy popřípadě separátně upravovat specifické moduly.

Obrázek 2.7. MVC

Model reprezentuje podobu dat se kterými systém pracuje, tato podoba vychází z datového modelu. Usnadňuje přístupk fyzickým datům uloženým v databázi. V tomto případě je pro každou tabulku z datovéhom modelu vytvořena vlastní třída. Pomocí instancí objektů vytvořených na základě těchto tříd je velmi jednoduché předávat modifikovaná data do databáze, nebo z databáze data číst. View zajišťuje interakci s uživatelem a zprostředkovává zobrazení dat a potřebných informací pro správnou funkci systému. View jsou reprezentovány soubory, které implementují vlastnosti šablon, tím je zajištěna možnost plošné změny vzhledu, a mohou rovněž obsahovat příkazy skriptovacího jazyka. Jsou to jediné soubory obsahující HTML. Data jsou do view předávány pomocí odpovídajícího modelu. Je zde však malý zádrhel. Představme si model, který reprezentuje objek typu divize, úkolem tohoto objektu je zastřešovat hierarchickou struturu společnosti, tedy schraňovat pod sebe jednotlivé pobočky. Z pohledu datového modelu nás seznam poboček, které do divize patří nezajímá, avšak z pohledu uživatele je tato informace důležitá. Tedy v případě použití klasického modelu uživatel přichází o podstatnou část informace. Řešením je vytovření speciální třídy tzv. ViewModel, která bude vhodnější pro předávání dat do view, ale nebude přistupovat k databázi. Může například obsahovat instanci třídy divize a seznam položek třídy pobočka. V rámci ukládání a načítání informací z databáze se nic nemění, pouze v případě předávání inforamce do view se použĳe instance třídy ViewModel a takto se do view předá i informace o všech pobočkách spadajících pod danou divizi. Controler zpracovává požadavky uživatele a na základě vnitřní logiky rozhoduje co se nadále bude dít. Pomocí modelu dotazuje data z úložiště a předává vybranému view. Zpracovává požadavky POST

2.6. NÁVRHOVÝ SYSTÉM, IMPLEMENTAČNÍ PLATFORMA

25

a GET zaslané webovým formulářem (view) a na základě jejich obsahu volá příslušné metody. Jako příklad uvedu kontroler pro oblast správy uživatelů user_controler, který je zavolán http dotazem na adresu ./user/detail/1. Kontroler rozená metodu detail a proměnou typu int s hodnotou 1. Pokusí se zavolat metodu detail apředat jí hodnotu 1. Metoda je spuštěna a z parametru 1 zjistí, že je třeba získat model uživatele s id=1 a tento model předat view pro zobrazení informace o uživateli. Tím se nám zobrazí na obrazovce stránka s detailními informacemi o oživateli s id=1.

2.6

Návrhový systém, implementační platforma

V katalogu požadavků je jasně definováno, že serverová část informačního systému má být provozována v prostředí se systémem Microsoft Windows. Z předchozího vyplývá, že dalším požadavkem je nativní podpora MVC. Obě tyto vlastnosti splňuje zdarma dostupný produkt Visual Web Developer Express od společnosti Microsoft.

26


Kapitola 3

Implementace

3.1

Datový model

Datový model již přesně specifikuje obraz dat, který bude uložen v databázi. Vychází z doménového modelu a zohledňuje byznys procesy. Za povšimnutí stojí řešení identifikace uživatelů. V našem konkrétním případě je potřeba evidovat veškeré zaměstnance, kteří mají přiděleno k užívání nějaké zařízení. Jedním z požadavků na systém je rozdělení přístupů do částí systému na základě rolí. Uživatelé využívající systém (aktéři) jsou jistě také zaměstnanci, kteří mají přiděleno nějaké zařízení. Protože je vetšině firmej již samozřejmostí centrální ověřování uživateů budou tito aktéři vlasnit nějaký účet, kterým se mohou prokázat. Uživatelské jméno však s velkou pravděpodobností nebude korespondovat s jedinečným identifikátorem objektu Uzivatel. Proto byla navržena tabulka Prihlaseni, která spojuje informace o vnitřním objektu Uzivatel s vněším uživatelským jménem Login. Tímto je zajištěno ověření uživatele systému oproti firemnímu ověřovacímu mechanizmu a zároveň je zachována vnitřní integrita systému. Tabulka s názvem Vztah_pobocka řeší situaci, kdy jeden uživatel je správcem, nebo logistikem ve více pobočkách, ale také situaci, kdy jedna pobočka má více správců, či logistiků.

27

28

KAPITOLA 3. IMPLEMENTACE

Obrázek 3.1. Datový model

3.1. DATOVÝ MODEL

3.1.1

29

Inkrement 1

Uzivatel • osobní číslo (Int)

• příjmení (String) • jméno (String) • mail (String)

• pobočka (Pobocka)

Pobocka • jméno (String)

• adresa (String) • divize (Divize)

Divize • jméno

[Spravce] • divize (Divize)

• uivatel (Uzivatel)

[Logistik] • divize (Divize)

• uivatel (Uzivatel)

[Vedouci CSIIT] • uivatel (Uzivatel)

3.1.2

Inkrement 2

Zarizeni • (pc,tiskárna,skener,projektor,síový prvek) • evidenční číslo (Int)

• sériové číslo (String)

• platnost záruky do(Date) • číslo objednávky (String)

• popis (String) - vyřazen (Bool)

• typ zařízení (TypZarizeni) (server, stolní počítač, notebook, tiskárna, síový prvek, projektor)

30

KAPITOLA 3. IMPLEMENTACE • výrobce (Vyrobce) - model (Model) • požadavek HW (.pdf) • objednávka (.pdf) • dodací list (.pdf) • faktura (.pdf) • návrh na vyřazení (.pdf)

Vyrobce • název (String) • info (String)

TypZarizeni • název (String) • popis (String)

Model • název (String) • popis (String) • web podpory (String)

3.1.3

Inkrement 3

[Pozadavek cisla objednavky] • datum (Date) • správce (Uzivatel) • uivatel (Uzivatel) • zařízení (Zarizeni)

[Pozadavek inventarni cislo] • datum (Date) • správce (Uzivatel) • zařízení (Zarizeni)

3.1. DATOVÝ MODEL [Predani HW] • datum (Date)

• zařízení (Zarizeni) • uivatel (Uzivatel)

• správce (Uzivatel)

• předávací protokol (.pdf)

[Odebrani HW] • datum (Date)

• správce (Uzivatel)

• zánam o předání (Predani HW) • protokol o odebrání (.pdf)

[Navrh na vyrazeni HW] • datum (Date)

• zřízení (Zarizeni)

• správce (Uzivatel) • důvod (String)

• schválení logistika (Bool)

• schválení vedoucí CSIIT (Bool) • návrh na vyřazení (.pdf)

3.1.4

Inkrement 4

[Zapujceni HW] • správce (Uzivatel)

• dočasný uivatel (Uzivatel) • zařízení (Zarizeni)

• datum zapůjčení (Date)

• důvod zapůjčení (String)

[Vraceni HW] • správce (Uzivatel)

• záznam o zapůjčeni(Zapujceni HW) • datum navrácení (Date) • poznámka (String)

• protokol vrácení zapůjčenéh HW (.pdf)

31

32


[Zavada HW] • datum (Date) • správce (Uzivatel) • zařízení (Zarizeni) • popis závady (String)

[Vasledek opravy HW] • datum (Date) - správce (Uzivatel) • záznam o závadě HW (Zavada HW) • protokol o zásahu technika (.pdf) • poznámka (String)

[Poznamka] • datum (date) • zařízení (Zarizeni) • správce (Uzivael) • text poznámky (String) • druh poznámky (DruhPoznamky) • mail pro správce (Bool)

[DruhPoznamky] • název (String) • popis (String)

[SQL dotaz] • název (String) • pozpis (String) • SQL dotaz (String) • autor (Uzivatel)

3.2. ZDROJOVÝ KÓD [Plan SQL dotazu] • název (String)

• pozpis (String)

• SQL dotaz (SQL dotaz) • autor (Uzivatel)

• seznam odběratelů (Spravce) • čas sputění (Time)

• datum sputění (Date)

• opakované sputění (OpakovaneSpusteni)

[OpakovaneSpusteni] • den v tydnu (po, ut, st, ct, pa, so, ne, NULL) • den v mesici (1-31, posledni, prvni, NULL) • mesic (1 - 12)

3.2

Zdrojový kód

3.3

Grafické rozhraní

3.4

Ergonomie ovládání

3.5

Škálovatelnost (API)

33

34


Kapitola 4

Testování 4.1

White box testing

4.2

Black box texting (akceptační test)

Akceptační test vychází z katalogu požadavků, je zde uvedena jen malá část celého akceptačního testu těch testů, které mají zásadní důležitost vrámci business procesů, nebo základních požadavků. Test má předem definovaný vstup a očekávaný výstup. Test je označen jako úspěšný v případě že na daný vstup systém předá daný výstup.

4.2.1

Test 1: Přidání již existujícího HW

Přidání zařízení, které již existovalo a bylo používáno před zavedením systému. • vstup: inventární číslo sériové číslo platnost záruky do výrobce typ zařízení model popis uživatel • výstup: souhrnný přehled mail na [email protected], [email protected] vytvoření záznamu HW

4.2.2

Test 3: Požadavek na pořízení HW (nový HW)

Pokud vznikne potřeba přídit nové zařízení. • vstup: požadavek na pořízení HW (.pdf) model popis uživatel • výstup: souhrnný přehled vytvoření záznamu požadavek na přidělení čísla objednávky mail na [email protected], [email protected] vytvoření záznamu HW

4.2.3

Test 4: Přidělení čísla objednávky

Po vložení požadavku na pořízení HW. • vstup: číslo objednávky • výstup: souhrnný přehled mail na [email protected] aktualizace záznamu HW

35

36

KAPITOLA 4. TESTOVÁNÍ

4.2.4

Test 6: Přidělení inventárního čísla

Předpokladem je existující požadavek na pořízení HW a číslo objednávky. • vstup: inventární číslo

• výstup: souhrnný přehled mail na [email protected] aktualizace záznamu požadavek na přidělení inventárního čísla přiděleno aktualizace záznamu o HW

4.2.5

Test 7: Předávací protokol vytvoření

Předávací protokol je nutné vytisknou před fyzickým předáním zařízení. • vstup: pokyn k vytvoření protokolu

• výstup: souhrnný přehled tisk protokolu na tiskárnu

4.2.6

Test 9: Protokol o odebrání HW vytvoření

Protokol je nutné vytiskou před fyzickým odebráním zařízení. • vstup: pokyn k vytvoření protokolu

• výstup: souhrnný přehled tisk protokolu na tiskárnu

4.2.7

Test 11: Změna uživatele HW

Předpokladem je, že zařízení není monentálně přiřazeno žádnému uživateli, má evidenční číslo, a není vyřazeno. • vstup: nový uživatel požadavek na přidělení HW (.pdf) (HW nesmí být přiřazen žádnému uživateli) • výstup: souhrnný přehled mail na [email protected], [email protected] vytvoření záznamu předání HW

4.2.8

Test 12: Návrh na vyřazení

• vstup: důvod vyřazení

• výstup: souhrnný přehled vytvoření záznamu o návrhu na vyřazení mail na [email protected], [email protected], [email protected]

4.2.9

Test 13: Schválení návrhu na vyřazení (logistik)

• vstup: pokyn ke schválení

• výstup: souhrnný přehled aktualizace záznamu návrh na vyřazení mail na [email protected], [email protected]

4.2.10

Test 14: Schválení návrhu na vyřazení (vedoucí csiit)

• vstup: pokyn ke schválení

• výstup: souhrnný přehled aktualizace záznamu návrh na vyřazení mail na [email protected], [email protected]

4.2. BLACK BOX TEXTING (AKCEPTAČNÍ TEST)

4.2.11

37

Test 25: Zapůjčení HW

Předpokladem je zařízení, které nemá přiděleno žádného uživatele. • vstup: komu se zapůjčuje (uživatel) co se zapůjčuje (HW) důvod zapůjčení od (datum) do (datum) • výstup: souhrnný přehled mail na [email protected] vytvoření záznamu zapůjčení HW

4.2.12

Test 27: Vrácení zapůjčeného HW

Předpokladem je existující záznam o zapůjčení. • vstup: protokol o vrácení zapůjčeného HW (.pdf) poznámka (nepovinná)

• výstup: souhrnný přehled mail na [email protected] vytvoření záznamu o vrácení zapůjčeného HW

38


možnosti rozšíření, zhodnocení

39

40


Literatura [1] M. Fowler, přeložil M. Pavlíček, Destilované UML, Grada Publishing, a.s., Praha, 2009. [2] , H. Kanisová, M. Müller, UML srozumitelně, Computer Press, a.s., Brno 2007.

41

42

LITERATURA

Přílohy Odborný slovník zařízení - hardware - HW - výpočetní technika • elektronický majetek společnosti s pořizovací cenou > 5000Kč, který je připojitelný k počítači, notebooku či serveru, nebo samotný počítač, notebook, server • npař.: tiskárna, ploter, projektor, swtich, inteligentní UPS, počítač, notebook, serve

správce • zaměstnanec společenosti, zodpovědný za provoz výpočetní techniky

logistik • zaměstnanec společenosti, zodpovědný evidenci výpočetní techniky

uživatel • zaměstnanec společenosti, využívající ke své práci výpočetní techniku

divize • organizační útvar společnosti, který seskupuje pobočky v jednom regionu

pobočka • samostatná funkční část společnosti s vlastním rozpočtem a majetkem

CSIIT - Centrální Správa Infrastruktury Informačních Technologií • oddělení společnosti seskupující správce

předávací protokol • dokument ISO, jednoznačně identifikující zařízení, uživatele a správce,

protokol o odebrání • dokument ISO, jednoznačně identifikující zařízení, uživatele a správce

43

44

LITERATURA

evidenční číslo - inventární číslo • číslo pod kterým je zařízení evidováno v systému pro správu majetku • nalepeno na krytu zařízení

sériové číslo - stag • šíslo od výrobce které jednoznačně identifikuje zařízení • nalepeno na krytu zařízení

• uloženo na základní desce zařízení v elektronické podobě

číslo objednávky • generuje systém pro správu majetku, příděluje logistik, pod tímto číslem se páruje objednávka s fakturou

Případy užití Akceptační test Instalační uživatelská příručka Uživatelská příručka

45

46

LITERATURA

České vysoké učení technické v Praze. katedra počítačů BAKALÁŘSKÁ PRÁCE. Konfigurační databáze

Recommend Documents