VYSOKÁ ŠKOLA MANAŢMENTU V TRENČÍNE VÝVOJ A IMPLEMENTÁCIA INFORMAČNÉHO SYSTÉMU V KONKRÉTNEJ ORGANIZÁCII Bc. Branislav Helcz

Transcription

1 VYSOKÁ ŠKOLA MANAŢMENTU V TRENČÍNE VÝVOJ A IMPLEMENTÁCIA INFORMAČNÉHO SYSTÉMU V KONKRÉTNEJ ORGANIZÁCII 2010 Bc. Branislav Helcz

2 VYSOKÁ ŠKOLA MANAŽMENTU V TRENČÍNE VÝVOJ A IMPLEMENTÁCIA INFORMAČNÉHO SYSTÉMU V KONKRÉTNEJ ORGANIZÁCII Diplomová práca Študijný program: Znalostný manaţment Pracovisko: VŠM, Bratislava Vedúci záverečnej práce: RNDr. Martin Nehéz Bratislava 2010 Bc. Branislav Helcz

3 2

4 OBSAH 1 Úvod a definícia problému Prehľad problematiky a literatúry Teoretické východiská implementácie podnikových informačných systémov Ţivotný cyklus vývoja softvéru Metodiky vývoja informačných systémov Návrh životného cyklu a metodiky realizácie fáz Ţivotný cyklus Správa poţiadaviek Analýza Návrh Realizácia Testovanie Zavedenie do produkcie a údrţba Implementácia informačného systému v spoločnosti Trilab s.r.o Správa poţiadaviek Funkčné poţiadavky na systém Nefunkčné poţiadavky na systém Analýza: Prípady pouţitia - Use Case Nastavenie systému Evidencia komunikácie Riadenie úloh Evidencia zákazníkov, dodávateľov a kontaktov Evidencia tovarov Fakturácia Riadenie projektov Analýza: Procesy a ich diagramy Riešenie úlohy Fakturácia Komunikácia Návrh systému Dátový model Logický dátový model Fyzický dátový model Stavové diagramy Realizácia IS Testovanie Zavedenie do produkcie Údrţba Záver

5 Zoznam obrázkov Zoznam bibliografických odkazov Prílohy

6 Zoznam skratiek a symbolov DB ERP FK GUI ICT IS MS PK SDLC SQL UML VBA XML - Databáza (DataBase) - Enterprise Resource Planning (podnikový informačný systém) - Foreign Key (cudzí kľúč) - Graphical User Interface (grafické pouţívateľské rozhranie) - Information and communication technologies (informačné a komunikačné technológie) - informačný systém - Microsoft - Primary Key (primárny kľúč) - Software Development Life Cycle (ţivotný cyklus vývoja softvéru) - Structured Query Language - Unified Modeling Language - Visual Basic for Applications - extensible Markup Language 4

7 Ďakujem vedúcemu diplomovej práce, RNDr. Martinovi Nehézovi za cenné rady, pripomienky a usmernenia, ktoré mi pomohli pri vypracovaní diplomovej práce. 5

8 1 Úvod a definícia problému Informačná technika a informačné systémy sú charakteristické pre dnešnú spoločnosť. Môţeme povedať, ţe svoje uplatnenie nachádzajú v kaţdej oblasti ľudskej činnosti, sú prostriedkom k efektívnejšiemu vyuţívaniu obmedzených zdrojov, uchovávania informácií v ľahko dosiahnuteľnej podobe takmer v okamţiku, ale i účinným nástrojom k získavaniu nových znalostí analýzou existujúcich informácií. Ich efektivita je závislá na dôkladnej analýze potrieb a jej správnej implementácií v podobe informačného systému. Bez dôkladnej prípravy a pochopenia príčin implementácie informačného systému je výsledok tohto snaţenia nejednoznačný. V organizáciach plnia informačné systémy podpornú funkciu pri strategickom rozhodovaní, odráţajú aktuálny stav organizácie a vnášajú organizovanosť a poriadok do vnútropodnikových procesov. Implementácia informačného systému v podniku je procesom neustálym a nikdy nekončiacim. Rovnako, ako sa podnik mení, musí jeho vývoj kopírovať aj informačný systém, inak sa stane skôr brzdou rozvoja a nie jedným z jeho akcelerátorov. Implementácia systému teda v sebe zahŕňa neustále opakujúci sa kolobeh analýzy poţiadaviek na systém, návrhu, programovania, testovania, zavedenia do produkcie a pravidelnej údrţby. Spomínané etapy implementácie informačného systému sú podľa špecifických potrieb tej ktorej implementácie dopĺňané o ďalšie kroky. V prípade, ţe nahrádzame systém úplne novým, musíme fázu zavedenia rozšíriť o prechod z jedného systému na druhý. Táto situácia si vyţaduje presné plánovanie a načasovanie, aby sa minimalizoval stav, počas ktorého nebude systém dostupný. V našej práci venujeme špeciálnu pozornosť prvým dvom fázam implementácie informačného systému analýze poţiadaviek a návrhu systému. Pochopenie významu navrhovaného systému pre organizáciu a poţiadaviek jeho budúcich pouţívateľov je esenciálne pre úspech celej implementácie, pretoţe systém stráca svoj zmysel, ak nevykonáva tie činnosti, ktoré sa od neho očakávajú, bez ohľadu na to ako kvalitne bol naprogramovaný a aké technológie boli pouţité. Nechceme tým ţiadnym spôsobom spochybňovať dôleţitosť ostatných etáp, pretoţe všetky priamo vplývajú na kvalitu celej implementácie, ale práve od kvality spracovania podkladov prvých dvoch etáp zavisí správnosť nasledujúcich. Analýza poţiadaviek spoločnosti, pre ktorú je implementácia uskutočňovaná, definovala náš cieľ ako vytvorenie systému, ktorý dokáţe sledovať a plánovať činnosti pracovníkov na projektoch. Projekt budeme chápať ako miesto, kde sa schádzajú všetky oblasti činnosti organizácie, ktoré majú priamo za cieľ jeho úspešné 6

9 ukončenie. S projektom teda súvisí komunikácia s kontaktmi zákazníka, činnosti jednotlivých členov tímu a dodávky tovarov. Jednoducho povedané potrebujeme navrhnúť systém, ktorý dokáţe vzájomne prepojiť entity súvisiacie s uskutočňovaním projektu. Metodika analýzy a návrhu systému závisí od zvolenej technológie. V práci sa budeme venovať faktorom, ktoré musíme zohľadniť pri jej výbere finančná náročnosť, technologické hľadiská, zloţitosť implementácie budúcich zmien, poţiadavky na údrţbu a moţnosť budúceho rastu riešenia spolu s organizáciou. Skôr ako začneme s programátorskými prácami, treba pochopiť činnosti organizácie, pre ktorú systém navrhujeme. Za prvé si ušetríme veľa zbytočnej roboty a za druhé vytvoríme systém, ktorý skutočne spĺňa poţiadavky organizácie. Našou prvou fázou je teda skúmanie poţiadaviek organizácie na systém a procesov, pre ktoré má byť systém podporou. Pri analýze a návrhu vyuţijeme prostriedky, ktoré nám ponúka jazyk UML (Unified Modeling Language). S ohľadom na zvolenú technológiu pre našu implementáciu vyuţijeme iba časť prostriedkov jazyka UML a to konkrétne definovanie prípadov pouţitia (Use Case) a ich diagramov, diagramy aktivít (Activity Diagram), prostriedky návrhu logického a fyzického modelu databázy a na definovanie stavov entít pouţijeme stavové diagramy (State Diagram). Posledná naša úloha je preniesť návrh systému do podoby reálnej aplikácie. Ako prvé prenesieme návrh fyzického dátového modelu do databázy, čím vytvoríme dátové štruktúry, v ktorých sa uchovávajú dáta a zadefinujeme ich vzájomné relácie. Po tomto kroku začneme programovať funkčnosti systému podľa podkladov z analýzy prípadov pouţitia, stavových diagramov a diagramov aktivít. Jazyk UML sa nevenuje pri analýze grafickému pouţívateľskému rozhraniu, prostredníctvom ktorého systém komunikuje s pouţívateľom. V práci uvedieme všeobecne platné pravidlá tvorby GUI, ktorých sa budeme podľa moţností, ktoré nám Access poskytuje, pridrţiavať. Dôraz kladieme na prehľadné, logicky usporiadané pouţívateľské prostredie. Funkcie systému majú byť podľa moţností čo najlogickejšie usporiadané, umiestnené a dostupné v čo najmenšom počte potrebných krokov. Na to, aby systém mohol dobre slúţiť, treba venovať patričnú pozornosť jeho údrţbe a priebeţným zmenám.uvedieme moţnosti, ktoré nám zvolená technológia poskytuje a ako budeme postupovať aby sme vystihli čas prechodu z natívnej DB na SQL Server. 7

10 2 Prehľad problematiky a literatúry Veľká miera globalizácie a s tým rastúca konkurencia neustále núti podniky zniţovať svoje náklady so zachovaním alebo aţ zvyšovaním kvality produkcie. Z tohoto dôvodu je potrebné dôkladne a neustále sledovať procesy v organizácii aby sme stále zvyšujúce sa poţiadavky dokázali udrţať. Bez správne navrhnutých podnikových informačných systémov by riadenie a sledovanie procesov bolo v súčasnosti nemoţné. Josef Basl a Roman Blaţíček vo svojej knihe opisujú nový pohľad na informačné systémy v podnikoch v prostredí informačnej spoločnosti, kedy sa pohľad na zavedenie systému mení z čisto technologického, na pohľad prínosu zo zavedenia systému (Basl & Blaţíček, 2008). Zaoberajú sa otázkami, ktoré musia byť zodpovedané skôr, ako sa pristúpi k samotnému zavedeniu informačných systémov. Sokolowsky (Sokolowsky, 2002) sa vo svojich skriptách venuje informačnému manaţmentu, teda riadeniu informácií nevyhnutných pre organizáciu. Bez rozdielu, či zakúpime parametrizovateľný informačný systém, alebo sa rozhodneme pre vlastný vývoj, musíme podrobiť naše poţiadavky naň, procesy v organizácii a očakávania z jeho implementácie dôkladnej analýze. Existuje viacero metodík, ktoré boli vyvinuté z dôvodu uľahčenia procesu implementácie a zníţenia rizika chýb pri analýze a návrhu. Prehľad a kategorizáciu metodík prináša vo svojej knihe Buchalcevová (Buchalcevová, 2005). Hana Kanisová a Miroslav Müller opisujú vo svojej knihe (Kanisová & Müller, 2006) metodiku Select Perspective od spoločnosti Select Business Solutions. Jim Arlow a Ila Nuestadt (Arlow & Neustadt, 2007) pri analýze a návrhu softvéru vyuţívajú metodiku UP Unified Process. Obidve spomínané metodiky vychádzajú z prostriedkov, ktoré poskytuje jazyk UML Unified Modeling Language, ktorý sme vo svojej analýze a návrhu vyuţili aj my. Na základe poţiadaviek kladených na navrhovaný systém, sme sa rozhodli vyuţiť pre implementáciu databázový systém Microsoft Access John Viescas a Jeff Conrad vo svojej knihe (Viescas & Conrad, 2008) poskytujú kompletný prehľad moţností tohto systému a návody ako ich vyuţiť. Bernd Held nám dáva vzory často pouţívaných rutín v jazyku VBA pre Access a zdrojové kódy k nim (Held, 2006). Kniha je plná inšpirácií, ktoré sme aj vyuţili pri riešení programátorských problémov. Srdcom kaţdého informačného systému je databáza, v ktorej sú obsiahnuté všetky informácie. Poznatky vedúce k úspešnému návrhu databázy prezentuje Hernandez (Hernandez, 2006). 8

11 Úspech kaţdej implementácie informačného systému závisí od dôkladnej analýzy poţiadaviek. Procesom zberu poţiadaviek sa podrobne venuje vo svojej knihe Karl E. Wiegers (Wiegers, 2008), ktorý hovorí o tejto úvodnej etape ţivotného cyklu ako o mieste, od ktorého závisí produktivita práce, spokojnosť zákazníkov, zníţenie nákladov na údrţbu a podporu systému a zvládnutie riadenia budúcich zmien poţiadaviek na systém. Dôleţitosť riadenia procesov pri vývoji softvéru potvrďuje existencia mnoţstva metodík, ktorých cieľom je priniesť do tohto procesu organizovanosť, a tým zvyšovať kvalitu vyvíjaných aplikácií. Kaţdá implementácia je špecifická, preto je len na nás ako a či pouţijeme ponúkané nástroje. Podstatné je ale uvedomiť si, ţe bez dobrej analýzy riskujeme úspech implementácie celého informačného systému. 9

12 3 Teoretické východiská implementácie podnikových informačných systémov Podnikové informačné systémy, alebo ERP (Enterprise Resource Planning), sa postupne stávajú neoddeliteľnou súčasťou podpory a riadenia podnikových procesov. Rozhodnutie zaviesť do organizácie informačný systém, by mal nasledovať po zrelom zváţení potrieb organizácie. Identifikácia potrieb je kľúčovým faktorom úspechu implementácie. Systém by mal priamo reflektovať tieto potreby a prostredníctvom vhodných metód pomáhať k ich napĺňaniu, preto je nevyhnutné, aby bol v súlade s podnikovými procesmi, pretoţe iba tak môţe byť prostriedkom podpory v kaţdej etape sledovanej činnosti a takýmto spôsobom zvyšoval ich rýchlosť a kvalitu prevedenia. Rozhodnutie zaviesť informačný systém by mal teda vychádzať z dôkladnej analýzy vlastných podnikových procesov a zistených deficitov informácií v ich jednotlivých oblastiach podnikateľskej činnosti. Basl a Blaţíček hovoria, ţe podniková informatika plní v zásade dva typy úloh. Podporujú napĺňanie podnikových cieľov prostredníctvom robenia správnych vecí a za druhé umoţňujú robiť veci správne (Basl & Blaţíček, 2008, str. 174). Na to, aby ale tieto dve úlohy informačný systém plnil, treba dôkladne analyzovať svoje potreby, vyhľadať slabé miesta v podnikových procesoch a určiť metódy na ich odstránenie. Je dôleţité si uvedomiť, ţe informačný systém nie je liekom na zlý podnikateľský plán a riadenie, ale nástroj, ktorý slúţi na jeho podporu (erpwire.com, dátum neznámy). Teda nestojí mimo procesov, ale je ich súčasťou. Pokiaľ nedokáţeme jasne zdôvodniť potrebu zavedenia systému, nie je rozumné informačný systém vôbec zavádzať. Informačný systém nedokáţe vyriešiť problémy, ktorých príčiny nepoznáme, ale naopak správnymi metódami môţe byť výrazne efektívny, pri odstraňovaní jasne vymedzených problémových častí procesov. 3.1 Ţivotný cyklus vývoja softvéru Ţivotný cyklus vývoja softvéru predstavuje opis krokov a ich následnosti od zberu poţiadaviek na softvér aţ po odovzdanie finálneho produktu a jeho údrţbu. Jedna z ďalších moţných definícií je, ţe ţivotný cyklus môţe byť definovaný ako časové pásmo od plánovaní softwarového systému aţ po jeho realizaci, zavedení do provozu a údrţbu (Sokolowsky, 2002, s. 103). Teórie softvérových ţivotných cyklov prechádzali rôznymi etapami vývoja a zmenami, čím sa snaţili priblíţiť rozvoju a novým potrebám ICT a čo najlepšie zodpovedali realite. Môţeme povedať, ţe modely sa v jednotlivých fázach nelíšia, rozdielnosť vidíme len v ich vzájomnom časovom previazaní. Od striktne 10

13 sekvenčného modelu vidíme postupný prechod k paralelnému spracovaniu jednotlivých fáz. Neskôr boli zohľadnené prírastkové alebo čiastkové prístupy k riešeniu vývoja softvéru, ktoré znamenali iteratívny prístup ako odpoveď na neustále rastúce poţiadavky a hlavne zloţitosť vyvíjaných systémov. Jednotlivé etapy vývoja sa označujú ako fázy, pričom je pre ne charakteristické (Sokolowsky, 2002, s. 103) : - rozhodnutie o začatí, ktoré znamená prvotné rozhodnutie o začatí alebo rozhodnutie vyplývajúce z výsledkov predchádzajúcich fáz - cieľ, ktorý vymedzuje úlohy, ktoré sú predmetom riešenia fázy a tým zároveň určuje východiskové predpoklady nasledujúcich fáz - metódy kontroly splnenia cieľov fázy Prvé modely ţivotných cyklov (označujú sa aj ako fázové modely) boli sekvenčné. Společným znakem měl být určitý přísny sekvenční postup jednotlivých, samostatně uzavřených fází vývoje softwaru. Nová fáze začne jen tehdy, byla-li ta předchozí úplne dokončena (Sokolowsky, 2002, s. 105). Predbežná štúdia Analýza Koncepcia Vývoj Implementácia - Cieľová analýza. - Analýza možností a rizík - Procesná analýza - Analýza aplikácií a inf. a dátových zdrojov - Priebeh procesov - tok informácií - inf.zdroje Rychlý prototyping - Optimalizačná fáza s účasťou konečného používateľa - testovanie - zavádzací koncept Obrázok 3.1 Sekvenčný fázový model (Zdroj: Sokolowsky, 2002) Z uvedeného modelu vychádza priamo vododopádový model, ktorý ho rozširuje o spätnú väzbu dvoch po sebe nasledujúcich fáz. Sekvenčné modely časom nevyhovovali realite akou boli softvérové produkty vytvárané. Vznikali nové ako špirálový model alebo prototypovanie prototyping. Spomínané ţivotné cykly sú z pohľadu tvorcov softvéru. Na znázornenie procesu implementácie z pohľadu podniku pouţijeme etapy, ktoré uvádzajú Basl a Blaţíček (Basl & Blaţíček, 2008, str. 215). Tí podnikový pohľad na implementáciu delia na štyri etapy: - výber IS hľadanie vhodného riešenia pre podnik z hľadiska pokrytia jeho potrieb a očakávaní 11

14 - implementácia IS zavedenie informačného systému do podniku vrátane nastavenia parametrov, naplnenie údajmi, zmeny podnikových procesov, školenia pouţívateľov a pod. - prevádzka IS zaistenie prevádzky IS, udrţiavanie chodu a odstraňovanie chýb - inovácia IS analýza nových potrieb a ich implementácia do IS, prípadne prechod na iný produkt 3.2 Metodiky vývoja informačných systémov Môţeme povedať, ţe vývoj dvoch informačných systémov nikdy nebude úplne zhodný aj keď vo všeobecnosti postupujeme podľa rovnakých fáz niektorého zo ţivotných cyklov. Metodiky stavajú na ţivotných cykloch, ale pridávajú k nim ďalšie dimenzie, ktoré vyplývajú zo špecifík a odlišností pri ich vývoji. Buchalcevová (Buchalcevová, 2005, s. 19) vidí príčinu existencie rôznych metodík v týchto skutočnostiach: - rôzne technológie vyţadujú rôzne techniky a metódy - úspešnosť metodiky závisí od firemnej kultúry, preto pri jej výbere je vhodné na tento fakt prihliadať - kaţdý jedinec je jedinečný, preto metodika nemusí vyhovovať kaţdému a je vhodné aby došlo k ich úprave na základe schopností a skúseností jednotlivcov - jedinečnosť tímu, ktorá vo svojej podstate vyplýva z jedinečnosti jednotlivca - veľkosť tímu, kedy pre malý projekt uskutočňovaný malým tímom stačí malá metodika - dôleţitosť projektu, nasadenie systémov v kritických oblastiach riadenia si vyţaduje dôkladné spôsoby kontroly - metodiky závisia od prostredia. Rôzne poţiadavky a pravidlá pre štátne zákazky, moţností dodávateľov ako rozpočet projektu a čas. Výber metodiky teda závisí od mnoţstva faktorov, pričom treba povedať, ţe metodika sa nemusí zameriavať na celý ţivotný cyklus ale môţe upravovať len určité jeho časti. Je asi zbytočné aby sme teraz prezentovali existujúce metodiky, lebo ako sme uviedli kaţdá z nich je vyvinutá aby spĺňala špecifkiká pouţitej technológie a prostredie jej nasadenia. Pre nás je predovšetkým dôleţité uvedomiť si aké všetky faktory môţu ovplyvňovať úspešnosť metodiky a vytvoriť takú, ktorá bude najlepšie zodpovedať našim podmienkam. 12

15 4 Návrh životného cyklu a metodiky realizácie fáz V predchádzajúcej kapitole sme uviedli, ţe fázy implementácie informačného systému alebo inak povedané jeho ţivotný cyklus, zavisí od viacerých faktorov. Táto kapitola má za cieľ navrhnúť fázy implementácie systému, ktoré budú vyhovovať projektu, čo do jeho rozsahu, zrozumiteľnosti a jednoduchosti implementácie krokov, pouţitej platforme a časových a kapacitných obmedzení. V jednotlivých fázach ţivotného cyklu vysvetlíme spôsoby a prostriedky, ktoré vyuţije pri ich realizácii. Výsledkom našeho snaţenia by mala byť metodika, ktorá nám pomôţe úspešne realizovať softvérový projekt pre konkrétnu organizáciu. 4.1 Ţivotný cyklus Implementácia informačného systému (vo všeobecnosti ľubovoľného softvérového produktu) je súbor následných a neustále opakujúcich sa činností. Dodrţanie náväznosti krokov je veľmi dôleţitá z pohľadu náročnosti riadenia tohoto procesu. Dôraz musíme klásť na dôkladné prevedenie kaţdej etapy, pretoţe tá nám vytvára predpoklady na zvládnutie ďalšej. Podcenenie niektorej z nich má za následok komplikácie v nasledujúcom kroku a moţno aj neúspech celého projektu. Výrobcovia ERP systémov si vytvárajú vlastné metodiky a postupy implementácie šité na mieru svojmu riešeniu, pričom sa kladie dôraz na organizáciu, kam je systém nasadzovaný. Technologické poţiadavky (nefunkčné) nám ovplyvňujú to, akú metodiku pouţijeme a špecifiká organizácie (funkčné poţiadavky) to, ako ju pouţijeme. Rozdielnosti môţeme nájsť v prípade rôznych odvetví priemyslu a zameraní organizácie výroba, sluţby a pod. Dodrţanie odporúčaní metodiky by malo zaručiť úspech implementácie. Vo všeobecnosti môţeme implementáciu informačného systému rozdeliť do šiestich fáz, ktoré sú zobrazené na Obrázok 4.1 Ţivotný cyklus: Proces implementácie informačného systému. Jedná sa o najjednoduchší moţný model s presne stanovenými fázami, ktorý neberie do úvahy paralelné spracovanie krokov. V našej metodike budeme vychádzať práve z tohto modelu. V našich podmienkach si v podstate ani nemôţeme veľmi vyberať. Nemáme ani tím analytikov a ani tým programátorov. Všetky úlohy sú spracovávané iba jednou osobou a v tomto prípade o paralelnom spracovaní úloh samozrejme nemôţe byť ani reč. Práve tá striktná následnosť fáz by mala byť prostriedkom, ktorý v tomto zdĺhavom procese bude neustále ukazovať správny smer a nedovolí vniesť chaos do uţ aj tak komplikovaného procesu. 13

16 Správa požiadaviek Zavedenie do produkcie a údržba Analýza Testovanie Návrh Realizácia Obrázok 4.1 Ţivotný cyklus: Proces implementácie informačného systému Správa poţiadaviek Poţiadavky definujú Kanisová a Müller ako popis (špecifikáciu) určitej funkcie alebo vlastnosti, ktorá by mala byť vo vyvíjanom systéme implementovaná. Inými slovami, poţiadavka je vyjadrenie prianí pouţívateľa (Kanisová & Müller, 2006, s. 17). Wiegers (Wiegers, 2008, s. 28) hovorí o vlastnosti, ktorý systém musí mať aby mal hodnotu pre niektorého z účastníkov (projektu). Teda nie len pre pouţívateľa ale i investora, majiteľa podniku, riadiacich pracovníkov a pouţívateľov. Ďalšia moţná definícia, ktorá rozširuje chápanie poţiadavky je (Sommerville & Sawyer, 2008): Poţiadavky sú (...) popis toho, čo všetko by sa malo implementovať. Popisujú ţiadané chovanie systému a jeho vlastnosti a môţu predstavovať určité obmedzenia procesu vývoja systému. Zoznam poţiadaviek je výstupom spolupráce zodpovedných osôb z organizácie, kde sa systém implementuje a implementátora informačného systému. Tu musíme zvýrazniť slovo spolupráca, pretoţe vzájomné pochopenie potrieb je nevyhnutnosťou pre návrh systému, ktorý spĺňa poţiadavky organizácie. Kanisová a Müller uvádzajú, ţe neúspech správy poţiadaviek a nedostatočné zapojenie pouţívateľov do tohto procesu vedie vo väčšine prípadov k neúspechu celého projektu (Kanisová & Müller, 2006, s. 16). Ako sme uţ spomínali, systém by mal pomôcť k efektívnejšiemu dosahovaniu 14

17 podnikových cieľov, preto je nevyhnutné, aby implementátor chápal aj povahu podnikateľských aktivít organizácie, pre ktorú bude systém zavádzať. Môţeme povedať, ţe víziu a ciele organizácie si vezme za svoje a bude myslieť ako jeden z tímu, pričom jeho prínosom k dosiahnutiu cieľov budú znalosti informačných systémov. Nevyhnutnou súčasťou je preto zapojenie kaţdej skupiny pouţívateľov do návrhu systému a pochopenie ich práce. Wiegers uvádza nasledovné skupiny ľudí, ktoré musia byť účastníkmi projektu (Wiegers, 2008, s. 26): - financujúci investori a zákazníci, pre ktorých je systém určený pre plnenie podnikateľských potrieb - Pouţívatelia priamo pracujúci so systémom - Analytici poţiadaviek, ktorý sú prostredníkmi medzi pouţívateľmi a vývojármi - Vývojári, ktorý systém navrhujú, implementujú a udrţujú - Testeri, ktorí overujú správnosť správania sa systému - Dokumentátori píšuci pouţívateľské príručky, školiace materiály a nápovedu - Vedúci projektu, ktorí plánujú a riadia vývojársky tím. - Právnici zodpovedajúci za to, ţe systém spĺňa zákony a legislatívne nariadenia - Ľudia z výroby ak sa jedná o systém, ktorý je súčasťou výrobku - Všetci ostatní, ktorí budú pracovať so systémom: predajné oddelenie, marketingové oddelenie, oddelenie technickej podpory a iní. Kanisova a Müller rozlišujú dva typy poţiadaviek (Kanisová & Müller, 2006): - Funkčné opisujú funkcionalitu systému - Nefunkčné ostatné vlastnosti systému, softvérové a hardvérové poţiadavky a obmedzenia, alebo iné skutočnosti ovplyvňujúce chod systému Funkčné poţiadavky sú podstatou našej práce. Na základe nich budeme podrobovať organizáciu a jej procesy dôkladnej analýze. Zjednodušene povedané funkčnými poţiadavkami je všetko to, čo zobezpečí aby pouţívateľ videl na svojom monitore tie informácie, ktoré vidieť potrebuje. Nefunkčné poţiadavky sa zameriavajú na vlastnosti systému, o ktorých nemusí mať budúci pouţívateľ ucelenú predstavu. Jedná sa napríklad o pouţitie určitého typu databázového servera, pouţitie konkrétneho programovacieho jazyka, moţnosti riadenia prístupu (zabezpečenie kontroly prístupu pouţívateľov do IS), moţnosti zálohovania, dostupnosti systému a podobne. Na základe poţadovaných vlastností sa potom vyberú 15

18 najvhodnejšie technológie. V praxi pri zavádzaní IS do podniku nevyberáme medzi technológiami, ktorými sú riešenia uskutočnené, ale medzi hotovými riešeniami, ktoré sa dolaďujú podľa prianí zákazníka. V našom prípade ale začíname úplne od základov, preto sa dôvodom výberu platformy, na ktorej vytvoríme IS budeme venovať. Musíme prezradiť, ţe toto rozhodnutie bolo urobené uţ pri návrhu ţivotného cyklu a metodík a od neho sa odvíja opisovaná metodika, napriek tomu sme ho logicky zaradili medzi nefunkčné poţiadavky na systém. To, či sa nám nakoniec podarilo zvoliť najvhodnejšie riešenie odpovedajúce reálnym potrebám a moţnostiam organizácie ukáţe aţ budúcnosť. Komplexný a vyčerpávajúci prístup k správe poţiadaviek uvádza vo svojej knihe K. Wiegers (Wiegers, 2008). Ten ich rozdeľuje do troch skupín: podnikateľské, pouţívateľské a funkčné. Okrem nich pridáva k nim, akoby oddelene, ďalšiu skupinu poţiadaviek naväzujúce na podnikateľské poţiadavky parametrické, ktoré vyplývajú z prostredia systému a nie z jeho funkcie. Môţeme povedať, ţe sa jedná o obdobu spomínaných nefunkčných poţiadaviek. Podnikateľské Pouţívateľské Funkčné Parametrické Poţiadavky najvyššej úrovne zohľadňujúce ciele organizácie. Hovoria o cieľoch, ktoré chce organizácia dosiahnuť nasadením systému. Tieto poţiadavky formulujú väčšinou investori, manaţéri a vedúci budúcich pouţívateľov Sú opisom úloh, ktoré musia byť schopný budúci pouţívatelia so systémom robiť. Najčastejším zápisom sú prípady pouţitia, scenáre a tabuľky reakcií na rôzne udalosti. Sú to poţiadavky na správanie sa systému, teda riešia softvérovú funkcionalitu, aby boli pouţívatelia schopní riešiť svoje úlohy. Jedná sa o tzv. behaviorálne poţiadavky. Sú to poţiadavky typu systém by mal Výkonnostné a kvalitatívne poţiadavky. Napr. pouţiteľnosť, prenositeľnosť, rýchlosť a odolnosť. Tabuľka 4-1 Poţiadavky podľa Wiegersa Analýza Napriek tomu, ţe sme upozorňovali na dôleţitosť kaţdého jedného kroku, tak analýza spolu so správou poţiadaviek, má medzi nimi určité výsostné postavenie. Sú to prvé kroky v procese implementácie, a preto nedôslednosť pri ich uskutočňovaní môţe ohroziť úspešnosť celého procesu, vytvoriť komplikácie v nasledujúcich krokoch a spôsobovať neustále vracanie sa na začiatok. Toto samozrejme vedie k výraznej časovej a finančnej náročnosti celého projektu implementácie. Analýza sa sústreďuje na skúmanie procesov v organizácii a spôsobov interakcie pouţívateľov so systémom. 16

19 Pri analýze budeme vyuţívať prostriedky, ktoré nám poskytuje jazyk UML. UML je univerzálni jazyk pro vizuální modelovaní systému. Přestoţe je nejčastěji spojován s modelováním objektově orientovaných softwarových systémů, má mnohem širší vyuţití, coţ vyplývá z jeho zabudovaných rozšiřovacích mechanismů (Arlow & Neustadt, 2007, str. 28). Práve táto univerzálnosť bola pre nás rozhodujúcim faktorom výberu vhodného nástroja a technologická nezávislosť UML ho predurčuje ako univerzálny nástroj pre modelovanie softvérových produktov. V našom prípade sme nevyuţili všetky moţnosti, ktoré nám tento jazyk ponúka, z dôvodu pouţitia platformy MS Access 2007 pre náš informačný systém. Vyuţili sme prípady pouţitia a ich diagramy (Use Case), diagramy aktivít (Activity Diagram), stavové diagramy (State Diagram) a diagramy tried (Class Diagram). Vyuţitím modelovania prípadov pouţitia pretvoríme funkčné poţiadavky na systém na prípady pouţitia a ich diagramy. Takto získame prehľadné a názorné zobrazenie práce pouţívateľov so systémom. Pod prípadmi pouţitia rozumieme typové úlohy, ktoré presne opisujú poskytovanú funkčnosť budúcim systémom. Kaţdý prípad pouţitia zodpovedá práve jednému spôsobu pouţitia systému. (Kanisová & Müller, 2006, s. 37) Modelovanie prípadov pouţitia dopĺňa tradičnú špecifikáciu systémových poţiadaviek. Modelovaním prípadov pouţitia konkrétne určíme (Arlow & Neustadt, 2007, s. 91): - Hranice systému - vyznačíme oblasti pôsobnosti systému - Aktérov, v podobe rolí, ktoré sú pridelené osobám a predmetom pouţívajúcich systém - Prípady pouţitia, teda činnosti, ktoré aktéri so systémom vykonávajú - Relácie, alebo vzťahy medzi aktérmi a prípadmi pouţitia Uvedené štyri elementy sú stavebné prvky diagramu prípadov pouţitia, ktorý znázorňuje ich vzájomné vzťahy - relácie. Diagramy prípadov pouţitia vysvetlíme na jednoduchom príklade: 17

20 Obrázok 4.2 Príklad diagramu prípadu pouţitia Hranice systému v našom príklade predstavuje obdĺţnik s popisom nákup, čo určuje oblasť systému, ktorej sa diagram venuje. V prípade jednoduchého diagramu nie je nevyhnutný. Aktéra predstavuje postavička s popisom nákupca je to rola, pridelená skupine pouţívateľov. Ovál predstavuje prípad pouţitia, teda činnosť, ktorú daná skupina pouţívateľov so systémom vykonáva. Relácie sú naznačené čiarami a určujú vzájomné vzťahy medzi aktérmi a prípadmi pouţitia a prípadmi pouţitia navzájom. Plná čiara znamená vzťah pouţívateľa s prípadom pouţitia. Prerušované čiary označujú vzťahy medzi prípadmi pouţitia. V našich diagramoch pouţívame relácie typu <<include>> a <<extend>>. Relácia <<include>> vyčleňuje často opakujúcu sa postupnosť krokov v prípadoch pouţitia a umoţňuje tak sprehľadnenie a zjednodušenie zápisu. Tento prípad pouţitia tak môţe byť jednoducho zahrnutý v ostatných bez nutnosti opakovaného zápisu. Relácia <<extend>> znamená rozšírenie prípadu pouţitia o ďalšie kroky. Narozdiel od <<include>> tieto nie sú vţdy súčasťou postupnosti krokov, ale znamenajú rozšírenie prípadu pouţitia za určitých podmienok. (Kanisová & Müller, 2006, s ) Prípady pouţitia sú spoločným jazykom pouţívateľa systému a jeho tvorcu. Je dôleţité, aby scenáre a diagramy boli jednoduché, preto je zachádzanie do prílišných detailov kontraproduktívne. Prehľadnosť je potrebná pre pochopenie modelov aj zo strany pouţívateľa, ktorý dokáţe poukázať na ich nedostatky, pretoţe proces modelovania prípadov pouţitia býva spojený s vykonávaním viacerých zmien v ich návrhu. Názvy prípadov pouţitia by mali byť jednoznačné, aby nedochádzalo k zlej interpretácii pri komunikácii medzi pracovníkmi spoločnosti a analytikmi z implementujúcej spoločnosti. Napriek tejto jednoznačnosti, je vhodné urobiť zoznam krokov, ktoré sú vykonávané 18

21 v daných prípadoch pouţitia. Túto postupnosť krokov označíme ako scenár. Ten nám sekvenčne opíše prácu aktéra v danom prípade pouţitia. Za pomoci scenárov by sma mali odstrániť posledné zbytky nejasnosti v komunikácii analytika a pracovníka a zároveň nám výborne poslúţia v poslednej fáze vývoja aplikácie testovaní. Pre zápis scenárov pouţijeme tabuľku so štruktúrou uvedenou v tabuľke Tabuľka 4-2 Šablóna pre zápis scenárov. Pri zápise scenárov sme sa inšpirovali zápisom, ktorý uvádzajú Arlow a Neustadt, ktorý sme si pre naše potreby zjednodušili (Arlow & Neustadt, 2007, s. 100). Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Alternatívny scenár Identifikátor a názov prípadu použitia Stručný popis prípadu pouţitia Nutné predpoklady, ktoré musia byť naplnené aby bolo moţné prípad pouţitia vykonať Stav systému po ukončení prípadu pouţitia Aktéri vo vzťahu k prípadu pouţitia Príčina spustenia prípadu pouţitia Sekvencia krokov prípadu pouţitia Moţné rozšírenia prípadu pouţitia Tabuľka 4-2 Šablóna pre zápis scenárov Analýza prípadov pouţitia je zameraná na definovanie funkčností, ktoré má IS pouţívateľom poskytovať, avšak nezohľadňuje časovú náväznosť, v ktorej sú činnosti uskutočňované. V predchádzajúcej časti sme zadefinovali, čo robí pouţívateľ so systémom, teraz to spresníme tým, ţe určíme ako to robí. Pre znázornenie procesov v organizácii pouţijeme diagramy aktivít. Diagramy aktivít modelujú procesy ako kolekciu aktivít a prechodov medzi nimi. Stále sa jedná o prostriedok komunikácie medzi pouţívateľmi a analytikmi, preto je dôleţité udrţať ich dostatočne prehľadné. (Kanisová & Müller, 2006, s. 95). Diagramy aktivít a prípady pouţitia sú vzájomne doplňujúce sa pohľady. Prípad pouţitia vyjadruje chovanie systému ako interakciu medzi pouţívateľom (aktérom) a systémom a diagram aktivít ako postupnosť akcií. (Arlow & Neustadt, 2007, s. 289) Návrh Návrh systému vychádza z poznatkov získaných v analýze. V návrhu určíme logické prvky systému, na ktoré budeme aplikovať poţadované funkčnosti. Logickým prvkom potom priradíme stavy. Stav je určenie správania sa entity za určitých okolností. Logický (dátový) model nám naznačuje stavbu fyzického dátového modelu. Je návodom 19

22 pri jeho tvorbe, hovorí, aké informácie má systém zaznamenávať a uchovávať, na základe neho potom môţeme určiť dátovú štruktúru polí v tabuľkách. Návrh databázy Databáza by mala poskytovať všetky potrebné informácie, ktoré vyplynuli z analýzy poţiadaviek. Jej štruktúra by mala byť navrhnutá tak, aby boli informácie ľahko dosiahnuteľné a efektívne uloţené i s ohľadom na jednoduchosť budúcich zmien. Dôleţitosť dôkladnej analýzy ukladaných údajov a jej dôsledkoch vyjadruje Hernandez (Hernandez, 2006, s. 56): Navrhnete-li databázi bez důkladného uváţení, bude velmi obtíţné získat některé druhy údajů a riskujete, ţe vaše vyhledávání bude vracet nepřesné údaje. Nepřesné údaje jsou pravděpodně nejhorším důsledkem špatného návrhu databáze mohou ovlivnit nejzákladnější fungování vaší organizace. Návrh databázy - logický model Cieľom logického (dátového) modelu je určenie logických prvkov systému. Logický dátový model neurčuje konkrétnu podobu uloţenia dát v databáze a teda je technologicky nezávislý na pouţitej technológií. Logický dátový model určuje teda čo budeme uchovávať v databáze a nie ako na toto slúţi fyzický dátový model. Logický dátový model definuje entity alebo objekty reálneho sveta, ich vlastnosti, ktoré budeme zaznamenávať a vzájomné vzťahy medzi entitami. Entita entitu môţeme chápať ako vyjadrenie objektu reálneho sveta vo virtuálnom prostredí informačného systému. Môţe sa jednať o zákazníka, dodací list, tovar a pod. Atribút je vlastnosťou entity (označuje sa aj ako poloţka entity (Kanisová & Müller, 2006, s. 104)). My sa budeme drţať označenia vlastnosť, pretoţe pojem poloţka môţe evokovať, ţe sa jedná o riadok v databázovej tabuľke jeden fyzický záznam. V prípade entity zákazník sú atribútmi názov, adresa, IČO a pod. Vzťah určuje vzájomné vzťahy medzi entitami. Rozoznávame tri typy: - 1:1 Príkladom môţe byť vzťah entity zákazníka a entita zľavová karta. Kaţdý zákazník môţe mať práve jednu zľavovú kartu a rovnako zľavová karta je vystavená pre konkrétneho zákazníka. Pri vytváraní fyzického dátového modelu dôjde k zlúčeniu entít so vzťahom 1:1 do jednej tabuľky. Vo výnimočných prípadoch je moţné zdôvodnenie existencie i takéhoto vzťahu. Ak máme napr. databázu ľudí, v ktorej udrţiavame informácie i o rodných číslach, môţeme ju 20

23 chcieť oddeliť od beţných informácií, aby nebola prístupná kaţdému, kto má prístup k všeobecným informáciam o zákazníkovi. Z pohľadu správnosti fyzického modelu sa ale tieto vzťahy snaţíme eliminovať. - 1:N Jedná sa o najčastejší vzťah medzi entitami, označovaný aj ako vzťah MASTER DETAIL. Ak sa budeme drţať nášho príkladu so zákazníkom, vzťah 1:N nájdeme vo vzťahu zákazníka a entity faktúra. Faktúra je na strane DETAIL (strana N), pretoţe jednému zákazníkovi môţeme vystaviť viacero faktúr. Zákazník je na strane MASTER, pretoţe faktúra môţe znieť len na meno jedného zákazníka. Pri tvorbe fyzického dátového modelu, po procese normalizácie by mali existovať len tieto vzťahy. - N:M Tento vzťah existuje len v logickom modely. Vzťah N:M nájdeme vo vzťahu zákazníka a entity tovar. Zákazník si môţe zakúpiť viacero tovarov a zároveň tovar je predávaný viacerým zákazníkom. Vo fyzickom modely ho nevieme implementovať a je nutné ho previesť na vzťahy 1:N pouţítím ďalšej entity zákazníkov nákup. Prepojenie by vyzeralo: zákazník (1) (N) zákazníkov nákup (N) (1) tovar Návrh databázy - fyzický dátový model Fyzický dátový model vzniká uplatnením vlastností pouţitej databázy nad logickým modelom, teda uţ je platformovo závislý. Stavové diagramy Stavové diagramy sú posledným článkom, ktorý nám dotvára ucelený pohľad na správanie sa systému. Ako sme uţ spomínali prípady pouţitia zobrazujú čo je vykonávane so systémom interakcia pouţívateľa a systému, diagramy aktivít ako prebiehajú aktivity a logický dátový model nám definuje s čím sa tieto aktivity vykonávajú. Logické prvky systému menia pod vplyvom týchto činností, ktoré sú s nimi vykonávané svoje stavy, čo vyjadríme stavovým diagramom. Stavové diagramy teda modelujú chovanie objektov naprieč všetkými prípadmi pouţitia a znázorňujú ako stavy sa objektov menia v závislosti od udalostí, ktoré sa ich dotýkajú. (Kanisová & Müller, 2006, s. 85) 21

24 4.1.4 Realizácia Je zbytočné, aby sme sa v práci venovali programovaciemu jazyku alebo vývoju aplikácii v konkrétnom prostredí. Len pre úplnosť uvedieme, ţe MS Access 2007 je programovateľný cez VBA Visual Basic for Application a poskytuje vlastné integrované prostredie pre vývoj aplikácií. Pre nás bude podstatné navrhnúť kvalitné grafické pouţívateľské prostredie tzv. GUI Graphical User Interface. V procese analýzy a návrhu sme sa venovali informačnému systému čisto z funkčného pohľadu. Riešili sme, čo má aplikácia vykonávať a ako má reagovať na nadobudnuté stavy systému, ale neriešili grafické prostredie (GUI), pomocou ktorého prebieha interakcia pouţívateľa s aplikáciou. Návrhu grafického pouţívateľského prostredia treba klásť rovnako pozornosť ako k predchádzajúcim krokom implementácie informačného systému. Hlavným dôvodom je, ţe sa jedná o tú časť aplikácie, s ktorou prichádza pouţívateľ priamo do styku. Je to tá časť systému, ktorá sprostredkúva funkčnosti aplikácie navrhnuté v predchádzajúcich krokoch a pokiaľ by sme ich nedokázali jednoducho a prehľadne pouţívateľovi poskytnúť, strácajú veľkú časť svojej pouţiteľnosti. To, čo vidí pouţívateľ na obrazovke, musí byť prehľadné a pouţítie ovládacich prvkov zrejmé. Najčastejšie pouţívané funkčnosti by mali byť okamţite dostupné, menej pouţívané môţeme ukryť pod logické voľby. Keby sme sa snaţili všetky funkčnosti sprístupniť pouţívateľovi hneď z hlavnej ponuky, stratila by svoju prehľadnosť. Treba navrhnúť prístupnosť funkčností podľa ich pouţívanosti a logicky usporiadať podľa prirodzenej postupnosti krokov, s akými pouţívateľ s aplikáciou pracuje. Pri návrhu grafického pouţívateľského prostredia by sme mali vychádzať zo štandardov, na ktoré je pouţívateľ uţ zvyknutý. Napríklad prebrať logiku informačného systému, na ktorom bude aplikácia prevádzkovaná. V prípade, ţe pretvárame uţ existujúce riešenie je nevyhnutné, aby sme dodrţali logiku grafického návrhu tejto aplikácie. K vlastným vylepšeniam by sme mali pristupovať veľmi opatrne a mali by sme ich dobre zváţiť, pretoţe môţu priniesť dezorientáciu pouţívateľa. Je dôleţité, aby sa dala aplikácia intuitívne ovládať, pôsobila ucelene a grafický návrh bol dodrţaný v celej aplikácií. Aplikácia musí poskytovať jasnú odozvu na operácie, ktoré s ňou pouţívateľ vykonal. James Hobart vo svojom článku (Hobart, 1995) ešte pridáva ďalší dôleţitý fakt pre zjednodušenie pouţívania aplikácie. Tvrdí, ţe to ţe vzniklo grafické prostredie ešte neznamená, ţe musíme pouţívateľa nútiť pouţívať myš ako primárny nástroj na ovládanie. Pouţívateľa vkladajúceho veľa textových informácii môţe naopak zdrţovať neustále striedanie myši a klávesnice. Mali by sme umoţniť pouţitie klávesových skratiek pre zrýchlenie prístupu k funkcionalitám aplikácie. 22

25 V poslednom období sa preferuje trend pouţitia tenkých klientov. Má to nesporne veľa výhod a existujúce webové technológie stierajú rozdiely medzi klasickým a tenkým klientom. Toto smerovanie je uplatňované aj v budúcej verzii MS Access 2010, ktorej beta verzia bolo prístupná na stiahnutie v čase písanie tejto práce. Ako jedna z najdôleţitejších noviniek bolo prezentované zjednodušenie zdieľania informácií prostredníctvom webu. Databázu je moţné navrhnúť tak, aby ju bolo moţné pouţívať v okne internetového prehliadača (Microsoft, 2010). Toto si samozrejme vyţaduje zmenu v myslení pri návrhu ovládzacích prvkov. Pouţívatelia sú inak zvyknutí pouţívať aplikácie beţiace cez web ako klasické desktopové aplikácie. Vynikajúcim vodítkom pri návrhu môţe byť kniha S.Kruga Webdesign:Nenuťte uţivatele přemýšlet (Krug, 2006). Cieľom práce nie je opisovať vlastnosti budúcich verzií MS Access, preto problematiku návrhu web database nebudeme ďalej rozoberať. Spomenuli sme ju hlavne ako jednu z moţností, ktoré v budúcnosti budeme môcť vyuţiť Testovanie Softvérové systémy sú neustále zloţitejšie a môţeme povedať, ţe neexistuje aplikácia, ktorá by neobsahovala nejakú chybu. Rozsiahlosť projektov ďaleko prevyšuje schopnosti človeka ustriehnuť kaţdú drobnosť súvisiacu s projektom. Preto prichádzajú postupy, ktoré by mali zabezpečiť akceptovateľnú úroveň kavality softvérových produktov. Čim kritickejšia je oblasť nasadenia systému, tým pouţívajú tieto metódy detailnejšie a prísnejšie kritéria hodnotenia. Do kritické prostredia je nasadzovaný aj kaţdý podnikový informačný systém. Moţno na ňom nazávisia ţivoty a zdravie ľudí, ale minimálne na ňom závisí konkuriencieschopnosť organizácie a tým v podstate i jej existencia. Výber spôsobu testovania závisí aj od oblasti, ktorú podrobujeme testovaniu. Môţeme testovať pouţiteľnosť, ktorá overuje schopnosť pouţívateľov pracovať s GUI systému, poprípade sa zameriame na testovanie zabezpečenia systému alebo rýchlosti spracovávania poţiadaviek pouţívateľov. Naše testovanie zameriame na funkčné oblasti systému, pričom cieľom je konštatovanie, ţe systém spĺňa zadefinované poţiadavky a jeho správanie je v súlade so scenármi prípadov pouţitia a stavovými diagramami. Podstatou testovania bude porovnávanie návrhu aplikácie (vieme ako má fungovať) s reálnym správaním sa. Nebudeme vytvárať ďalšie podklady pre túto etapu implementácie IS vo forme nových dokumentov ako napr. testovacích postupov. Ako podklady vyuţijeme 23

26 scenáre, diagramy aktivít a stavové diagramy, ktoré sme vytvorili počas analýzy. Budeme simulovať prácu pouţívateľov uskutočňovaním práce so systémom tak, ako je zadefinovaná v scenároch pouţitia. To či na udalosť systém reagoval správne overíme porovnaním so stavovými diagramami, tie nám totiţ zobrazujú predpokladané správanie sa systému a zmeny jeho stavov. Pri objavení chyby sa vrátime do etapy realizácie a chybu odstránime Zavedenie do produkcie a údrţba Zavedenie informačného systému do podniku musí zohľadňovať uţ existujúce IS. V prípade, ak podnik nepouţíva ţiaden informačný systém, ktorý by ovplyvňoval zavedenie nového, nie je nutné riešiť plán nasadenia systému. Takýto stav je ale skôr zriedkavý. Musíme teda všeobecne rozlišovať medzi troma moţnými situáciami, ktoré môţu nastať: - podnik nemá ţiaden IS, alebo implementovaný IS nie je nutné prepájať uţ s existujúcim - podnik má špecializovaný IS pre určitú oblasť a tento je nutné prepojiť s novým IS - podnik má IS a tento bude v plnej miere nahradený novým Zavedením do produkcie a následnou údrţbou ţivotný cyklus informačného systému nekončí. Rovnako ako sa organizácia a jej procesy menia musí drţať informačný systém krok s týmito zmenami, preto je proces implementácie znázornený v cykle. Pokiaľ by sa tak nestalo, prestal by IS plniť svoje poslanie a postupne by bol brzdou a prekáţkou rastu a inováciám v organizácií. 24

27 5 Implementácia informačného systému v spoločnosti Trilab s.r.o. Prvým krokom k zavedeniu informačného systému je pochopenie podnikateľskej činnosti spoločnosti a pochopenie organizácie práce v nej. Z tohoto dôvodu uvádzame stručnú charakteristiku spoločnosti, pre ktorú je systém navrhovaný: Trilab s.r.o je nová spoločnosť zaoberajúca sa predajom prístrojov a pomôcok pre lekárne a laboratória, servisom, poradenskou činnosťou a dodávkou laboratórií na mieru. Kmeňoví zamestnanci sú tohto času traja. Komplexnosť sluţieb je zabezpečovaná koordináciou mnoţstva subdodávateľov, čo si vyţaduje presné organizovanie činností. Spoločnosť na svojej strane sama charakterizuje oblasť svojej činnosti takto: Snaţíme sa, aby naše sluţby v oblasti laboratórií a lekární boli komplexné. Okrem obchodu s laboratórnymi a lekárenskými prístrojmi produkujeme laboratórny a lekárenský nábytok. Zabezpečujeme všetko na kľúč od dizajnérskeho a technického poradenstva a návrhu aţ po realizáciu. Zabezpečujeme stavebné úpravy a inštaláciu vody, elektriky a plynu vrátane revízií... Venujeme sa tieţ rekonštrukcii a obnove školských laboratórií, kde vychádzame v ústrety poţiadavkám na kvalitu a tieţ berieme zvýšený ohľad na finančnú náročnosť projektov. (TRILAB, s.r.o., 2009) Získavanie poţiadaviek spoločnosti na nový systém prebiehalo prostredníctvom osobných stretnutí, elektronickej pošty a telefonických rozhovorov. Nový systém by mal pomáhať pri riadení projektov a činností s nimi súvisiacimi. Okruhy problémov, ktoré bude riešiť systém boli navrhnuté s ohľadom na momentálnu etapu vývoja spoločnosti. Na jednej strane je tu nová spoločnosť, ktorá prechádza búrlivými zmenami a dalo by sa povedať, ţe hľadá samú seba, a na strane druhej náročnosť poskytovaných komplexných sluţieb vyţadujúcich si vynikajúcu organizáciu z dôvodu riadenia viacerých subdodávateľov na projekte a častú komunikáciu so zákazníkom pri špecifikácii jeho potrieb a organizovaním podkladov k nim. Pri návrhu systému sme vychádzali z analýzy procesov v organizácii a hľadali sme miesta, v ktorých by mohol systém uľahčiť, zrýchliť a sprehľadniť tento komplex činností. Nechceli sme nájsť riešenia na všetky oblasti ale riešili sme len časti procesov, ktoré sú pre spoločnosť esenciálne alebo v nich vidíme najväčšie rezervy. Firma momentálne nevyuţíva ţiadne špecializované softvérové produkty typu ERP. Pouţíva sa ekonomický systém Pohoda (pozri: a kancelársky balík OpenOffice. Komunikácia prebiehala formou osobných stretnutí, telefonickej a ovej komunikácie. Celý proces formulácie poţiadaviek na systém bol v našom prípade o niečo 25

28 jednoduchší pretoţe prebiehal v neformálnej podobe a tak bolo jednoduchšie nájdenie spoločnej reči, čo značne zrýchlilo celý proces oproti oficiálnym stretnutiam ako v prípade beţného zákazníka. Budúci systém sme orientovali na riadenie projektov prostredníctvom úloh viazaných na pracovníkov spoločnosti, evidenciu komunikácie so zákazníkmi a vytváranie fakturačných podkladov pre fakturanta. Tieto sú vytvorené obchodníkom a predané systémom fakturantovi na zaúčtovanie v ich primárnom účtovníckom systéme. Zákazník Úloha Projekt Fakturácia Komunikácia Obrázok 5.1 Pohľad navrhovaného systému na činnosť spoločnosti Projekt v našom prípade vytvára akési prepojenie medzi ostatnými oblasťami systému resp. činnosťami spoločnosti. Samozrejme, ţe existujú i ďalšie väzby medzi znázornenými elementami ako napríklad fakturácia je vţdy viazaná na zákazníka alebo komunikácia prebieha so zákazníkom, ale tie sme neuviedli pre zjednodušenie a zvýraznenie podstaty riešenia celej logiky systému. Logickým stredom systému bude projekt, pretoţe s ním môţe súvisieť kaţdý znázornený element. Schválne uvádzame môţe, pretoţe pre všestrannosť systému sme sa rozhodli neviazať striktne iba na projekt. Napríklad ak úloha nebude viazaná výlučne na projekt, môţeme ju vyuţiť aj na evidenciu ostatných činností nesúvisiacich s projektami. Obrázok je len pohľadom na logiku systému, preto tam chýbajú ostatné časti, ktoré musíme ešte implementovať evidencia tovarov, dodávateľov a číselníkov. 26

29 5.1 Správa poţiadaviek V úvode sme dostatočne naznačili smerovanie ďalšej analýzy poţiadaviek na informačný systém. Teraz je nutné rozobrať tieto funkčné poţiadavky detailnejšie, pretoţe ich vyuţijeme pri vytváraní scenárov prípadov pouţitia a modelovaní ich diagramov. K nefunkčným poţiadavkám sa dostaneme na konci tejto kapitoly Funkčné poţiadavky na systém Vychádzajúc z navrhovanej logiky systému sme identifikovali nasledovné oblasti informačného systému: Evidencia Komunikácie Riadenie úloh Evidencia zákazníkov, dodávateľov a kontaktov Riadenie projektov Fakturácia Evidencia tovarov Obrázok 5.2 Oblasti systému Evidencia komunikácie. Pod pojmom komunikácia budeme rozumieť telefonát, e- mail, klasickú poštu, fax alebo osobnú návštevu. Systém umoţní definovanie vlastných spôsobov komunikácie vytvoríme číselník, kam si nové spôsoby budeme môcť predbeţne dopĺňať. Systém umoţní daný záznam o komunikácii prepojiť so zákazníkom, jeho kontaktom a projektom. Pri komunikácii bude sledovať aj dátum, kedy bola uskutočnená, trvanie, stručný popis a prílohy, ak sa k danej komunikácii nejaké viaţu. Systém umoţní dodatočne previazať záznam o komunikácii s projektom, z dôvodu sledovania komunikácie vedúcej k získaniu projektu. Riadenie úloh. Pouţívatelia systému si budú môcť vzájomne predávať úlohy a kontrolovať ich plnenie. Úlohy budú slúţiť na evidenciu udalostí a činností, ktoré súvisia s podnikateľskou činnosťou subjektu. Bude sa jednať iba o jednoduchý zoznam pracovných povinností, ktoré budú rozdeľované na jednotlivých pouţívateľov. Systém bude umoţňovať priebeţne dopĺňať priebeh plnenia úlohy. Atribútmi úlohy: budú kto úlohu vytvoril,kto je riešiteľom, časové atribúty úlohy (čas a dátum zaloţenia úlohy, plánovaný dátum a čas ukončenia, stav dokončenia,...) a zadanie. Úlohu bude moţné previazať na 27

30 existujúci projekt z dôvodu sledovania činností na ňom uskutočnených. Pre zjednodušenie práce so systémom bude navrhnutá pracovná plocha pre konkrétneho pouţívateľa, kedy sa na základe prihlásenia zobrazí informácia o aktívnych úlohách iba pre daného konkrétneho pouţívateľa. Evidencia zákazníkov, dodávateľov a kontaktov. Bude sa jednať o jednoduchú evidenciu informácií o zákazníkoch a dodávateľoch. Evidenciu rozdelíme na spoločnosť, čo bude predstavovať zákazník alebo dodávateľ a jednotlivé kontakty osoby. Takýmto spôsobom umoţníme k zákazníkovi alebo dodávateľovi priradiť viacero kontaktných osôb a zároveň budeme môcť sledovať komunikáciu na úrovni konkrétnej osoby a nielen spoločnosti ako celku. Riadenie projektov. Projekt bude slúţiť na zastrešenie dlhodobejšej spolupráce so zákazníkom ako napríklad dodávka laboratórií a zariadenia na kľúč. Teda zákazky, s ktorými súvisí viacero činností, ktoré je nutné uskutočniť. Najdôleţitejšou časťou je umoţnenie prepojenia úloh, komunikácie, faktúr, zákazníka a primárneho kontaktu na projekt. Okrem tohto budeme evidovať časové atribúty a podklady k projektu dokumenty, špecifikácie, zmluvy a pod. Pre naplnenie spomínaného projektového pohľadu vytvoríme v aplikácii formulár, v ktorom bude moţné sledovať všetky prepojenia z úloh a komunikácie na daný projekt z jedného miesta. Fakturácia je časť systému umoţňujúca predávať podklady na fakturáciu smerom od obchodníka k fakturantovi. Ten potom na základe predaných podkladov vystaví faktúru v primárnom účtovníckom systéme. Vedenie účtovníctva nebude predmetom nášho projektu. Pod zaúčtovaním budeme v našom systéme rozumieť zmenu príznaku stav, ktorý bude hovoriť, či sa jedná o faktúru zaúčtovanú alebo nezaúčtovanú. Na riadkoch faktúry budú poloţky tovaru, zákazkového tovaru, činností napr. montáţ, doprava a pod. Pre činnosti bude musieť byť taktieţ zaloţená karta resp. jednoduchý číselník. Evidencia tovarov bude zahŕňať logistické informácie ako hmotnosť, počet kusov v balení, kódy tovaru číslo tovaru dodávateľa, sériové číslo, informáciu o záručnej dobe. Musíme umoţniť vytvorenie tovaru skladajúceho sa z iných tovarov sety. Tento tovar sa bude skladať z kombinácie viacerých beţných tovarov. Zvláštnym prípadom tovaru bude zákazkový tovar. Dôvodom rozdelenia tovaru na tieto dve skupiny je oddelenie beţne periodicky predávaného tovaru od jedinečného tovaru vyrábaného na mieru, pre konkrétneho zákazníka. Uvedeného členenia do oblastí sa budeme pridŕţať i v nasledujúcej časti našej analýzy v prípadoch pouţitia. 28

31 5.1.2 Nefunkčné poţiadavky na systém Na nami navrhovaný systém nie sú kladené vysoké technologické poţiadavky a svojim rozsahom sa jedná o veľmi malý systém, s ktorým bude pracovať len obmedzený počet pouţívateľov. Nefunkčné poţiadavky môţeme zhrnúť do nasledovných bodov: - Nemusí byť zabezpečená sofistikovaná správa prístupu pouţívateľov. Jedná sa len o troch pracovníkov a informácie môţu byť vzájomne v plnej miere zdieľané, alebo skôr musia - Pouţitá technológia musí mať moţnosti rastu spolu s organizáciou - Jednoduchosť implementácie budúcich zmien - Dôleţitým aspektom bola výška prvotnej investície ako aj cena budúcich investícii pri implementovaní zmien Môţeme povedať, ţe momentálne technologické poţiadavky na systém sú pomerne nízke a rozsahom sa taktieţ jedná o malý projekt. Z tohto pohľadu by sa mohlo zdať, ţe pri výbere technológie stačí brať iba ohľad na cenu a teda vybrať niektorú z voľne dostupných alebo open source technológií. Po zváţení všetkých kladov a záporov sme sa rozhodli pre pouţitie MS Access V našej implementácii si jedná o vytvorenie úplne nového systému. Preto máme moţnosť zvoliť si technológie. Z dôvodu rozsahu implementácie, jednoduchosti tvorby systému a moţnostiam budúceho rozšírenia o nové funkčnosti sme sa rozhodli pre databázový systém Microsoft Acces V našom prípade sa jedná o ideálny nástroj pre malý podnik s malým počtom pouţívateľov. Zahŕňa v sebe nielen pracovné pouţívateľské prostredie, ale aj všetky potrebné nástroje pre vývoj a zmeny aplikácie. Vytvorenie jednoduchej aplikácie zvládne aj pokročilejší pouţívateľ bez znalosti programovania. Samozrejme pre správny návrh dátovej štruktúry sa predpokladajú aspoň zákaldné znalosti relačných databáz. Práve táto jednoduchosť a rýchlosť návrhu zniţuje výrazne čas a teda aj náklady na vytvorenie aplikácie. Organizácia taktieţ nie je nútená hľadať počítačových expertov pre uskutočnenie i najmenších zmien, pretoţe ich dokáţe uskutočniť aj prostredníctvom skúsenejších pouţívateľov. Okrem iného Access dokáţe spolupracovať aj s dátami z iných pouţívaných zdrojov, vrátane mnoţstva populárnych desktopových databázových programov a prostredníctvom jazyka SQL s dátovými zdrojmi na serveroch, mobilných zariadeniach, na intranetových a internetových stránkach. Access spojený s Microsoft SQL Serverem (v počítači či na serveru) je pro mnoho středně velkých společností ideálnim nástrojem 29

32 k rychlému a nenákladnému vytváření nových aplikací pro systém Windows (Viescas & Conrad, 2008, s. 31). Pre import a export dát je moţné pouţiť jazyk XML. Navrhovaná aplikácia nebude pouţívať databázový server MS SQL. Pouţitie súboru ako dátového skladu má síce kapacitné obmedzenie 2GB, ale pre rozsah systému a overenie funkčnosti aplikácie je to plne postačujúce a taktieţ výkonnostné nároky z dôvodu počtu súčasne pracujúcich pouţívateľov sú nízke. Dôleţité je, ţe máme moţnosť pri dosiahnutí limitov tohto riešenia prejsť na vyšší stupeň uloţenia dát MS SQL Server, hoci aj za cenu dodatočného úsilia, času a financií. Nepochybnou výhodou zostáva ale rozloţenie finančnej náročnosti na dlhšie časové obdobie a zníţenie straty v prípade neúspechu implementácie. Systém dokáţe rásť s rastúcimi potrebami a taktieţ vyuţívať v prípade budúcich potrieb aj Windows SharePoint Services pre zvyšovanie produktivity väčšieho pracovného kolektívu (Viescas & Conrad, 2008). Informácie o Windows SharePoint Services nájdete na stránkach alebo priamo na Analýza: Prípady pouţitia - Use Case Prípady pouţitia naviaţeme na uţ definované funkčné poţiadavky na systém, pričom zachováme existujúce členenie do funkčných oblastí. Prípady pouţitia bliţšie špecifikujú funkcionality systému z pohľadu pouţívateľa ako s daným systémom bude pouţívateľ pracovať. Vytváranie prípadov pouţitia a ich diagramov spadá do oblasti UML, narozdiel od predchádzajúcej časti. Prípady pouţitia sú viazané iba na pouţívateľa systému, v čom je hlavný rozdiel od predchádzajúcej časti definovania poţiadaviek, ktoré sú viac všeobecné. Táto metodika nám umoţní nájsť hranice systému, vyhľadanie aktérov a nájdenie prípadov pouţitia (Arlow & Neustadt, 2007, s. 91). Je orientovaná čisto na budúcich pouţívateľov a ich predstavu práce so systémom. Neriešime tu vnútorné správanie systému, ale jeho vonkajšie odozvy smerom k pouţívateľovi. Funkčné poţiadavky sme v tomto kroku rozšírili o ďalšiu oblasť nastavenie systému Nastavenie systému Riadenie prístupu do databázy budeme riadiť veľmi jednoducho. Nejedná sa ani tak o zabezpečenie databázy, ako o identifikáciu pouţívateľa, ktorú potom pouţijeme na zvýšenie pouţiteľnosti systému. Systém tak bude môcť poskytovať pouţívateľovi 30

33 informácie z pohľadu dôleţitosti pre jeho osobu. Nebudeme blokovať prístup k ostatným informáciám, identifikáciu pouţijeme len na úvodnú filtráciu záznamov, nie zablokovanie prístupu k nim. Teda pouţívateľovi sa budeme snaţiť uľahčiť prácu zobrazením len pre neho relevantných údajov, ale v prípade potreby bude môcť pristupovať ku všetkým informáciám. Pre túto funkcionalitu vytvoríme jednoduché overenie pouţívateľa na základe mena a hesla. Systém umoţní definovať úlohu pouţívateľa v systéme fakturant, administrátor a aktívny príznak, ktorým povoľujeme vstup do systému. Nastavenie systému zahŕňa tieto prípady pouţitia: S.1 Nastav informácie o spoločnosti S.2 Pridaj pouţívateľa S.3 Zmena hesla S.4 Odopri prístup S.5 Vymazanie pouţívateľa Obrázok 5.3 Use Case Diagram: Nastavenie systému Prípad použitia Popis Stav systému po ukončení S.1 Nastav informácie o spoločnosti Administrátor alebo pouţívateľ ţiada nastaviť alebo zmeniť informácie o spoločnosti Nastavené informácie o spoločnosti 31

34 Aktéri Inicializácia prípadu Scenár Pouţívateľ 1. pri prvom spustení aplikácie ak tieto informácie nie sú nastavené 2. samostatne pri potrebe zmeniť údaje 1. Otvorenie karty s informáciami o spoločnosti 2. Vyplnenie údajov 3. Kontrola vyplnenia povinných polí a. Systém overí vyplnenie povinných polí b. AK nie sú vyplnené polia, TAK hlásenie o tejto skutočnosti a návrat na záznam c. AK Ignorovanie hlásenia o nevyplnených poliach TAK prerušenie vkladania alebo zmeny záznamu informácii o spoločnosti bez uloţenia zmien 4. Uloţenie záznamu Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár S.2 Pridaj používateľa Administrátor poţaduje pridanie nového pouţívateľa Pouţívateľov môţe pridávať iba administrátor Je vytvorený nový pouţívateľ systému Administrátor Administrátor ţiada pridať pouţívateľa 1. Administrátor otvorí novú kartu pouţívateľa 2. Vyplní informácie o pouţívateľovi 3. Priradí heslo 4. Uloţí záznam s novým pouţívateľom 5. Pri prvom prihlásení je pouţívateľ vyzvaný na zmenu hesla Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár S.3 Zmena hesla Pouţívateľ mení heslo pre prístup do systému Nastavené nové heslo pre prístup do systému Pouţívateľ 1. pri prvom spustení aplikácie novým pouţívateľom 2. samostatne pri potrebe zmeniť heslo 1. Systém pri spustení overí či uţ bolo pridelené heslo administrátorom pouţívateľom zmenené a poţiada o zmenu hesla 2. Pouţívateľ zadá nové heslo 3. Pouţívateľ overí zadanie nového hesla 4. Systém zapíše nové heslo Prípad použitia Popis Stav systému po ukončení S.4 Odopri prístup Administrátor potrebuje zamedziť prístup pouţívateľovi Určený pouţívateľ sa nedokáţe prihlásiť do systému 32

35 Aktéri Administrátor Inicializácia prípadu Administrátor otvorí kartu pouţívateľa a označí pouţívateľa ako neaktívneho (odznačí zaškrtávacie pole Aktívny ) Scenár 1. Otvorenie karty s informáciami o pouţívateľovi 2. Označenie pouţívateľa ako neaktívneho 3. Systém overí či sa jedná o administrátora, ktorý zmenu vykonal a. AK zmenu nevykonáva administrátor TAK nie je moţné meniť aktívnosť pouţívateľa a USE CASE sa preruší 4. Pouţívateľ je označený ako neaktívny Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár S.5 Vymazanie používateľa Administrátor potrebuje vymazať pouţívateľa zo systému Pouţívateľ je vymazaný zo systému Administrátor Administrátor otvorí kartu pouţívateľa a ţiada vymazať záznam 1. Otvorenie karty s informáciami o pouţívateľovi 2. Spustenie odstránenia záznamu 3. Systém overí či sa jedná o administrátora, ktorý zmenu vykonal 4. Systém overí či sa k danému pouţívateľovi nevzťahujú záznamy a. AK existujú záznamy TAK dôjde prerušeniu USE CASE 5. Záznam o pouţívateľovi za vymaţe Evidencia komunikácie Zaznamenávanie komunikácie so zákazníkom má pre nás prínos predovšetkým v sledovaní priebehu komunikácie v rámci projektu. Komunikácia prebieha s kontaktom (konkrétna osoba), ktorý patrí pod zákazníka a môţe sa viazať k projektu alebo ostáva bez väzby napr. ako oslovenie s ponukou nových produktov. Vytvorenie marketingových kampaní a následné previazanie tejto komunikácie so zákazníkom je moţné v budúcnosti dopracovať. Evidencia komunikácie zahŕňa len jeden prípad pouţitia: I.1 Zaznamenaj údaje o komunikácii 33

36 Obrázok 5.4 Use Case Diagram: Evidencia komunikácie Prípad použitia I.1 Zaznamenaj údaje o komunikácii Popis Pouţívateľ ţiada zaznamenať komunikáciu Predpoklady - Stav systému po ukončení Zaznamenaná informácia o komunikácii Aktéri Pouţívateľ Inicializácia prípadu Pouţívateľ ţiada o vloţenie novej komunikácie Scenár 1. Pouţívateľ zvolí vloţenie nového záznamu o komunikácii 2. Pouţívateľ zapíše informácie o uskutočnenej komunikácii a. INCLUDE: Z.8 Vyhľadaj kontakt b. AK sa komunikácia viaţe k projektu TAK EXTEND: P.3 Vyhľadaj projekt 3. Systém skontroluje vyplnenie povinných polí a. AK nie sú vyplnené polia TAK hlásenie o tejto skutočnosti a návrat na záznam 4. Zaznamenaná informácia o interakcii Riadenie úloh Oblasť aplikácie riadenia úloh patrí k náročnejším, pretoţe je nutné sledovať priebeh úlohy a od toho odvíjajúce sa operácie, ktoré s ňou môţu byť uskutočnené. S úlohami pracujú dvaja aktéri zadávateľ a riešiteľ. Môţe sa jednať aj o tú istú osobu, z dôvodu evidencie uskutočnených úloh spadajúcich pod projekt. Úloha ale nemusí nutne súvisieť s projektom. Riadenie úloh zahŕňa prípady pouţitia: U.1 Vytvor úlohu U.2 Zaznamenaj priebeh úlohy 34

37 U.3 Ukonči úlohu U.4 Zruš úlohu U.5 Schváľ úlohu U.6 Zisti priebeh riešenia úloh U.7 Vyhľadaj úlohu Obrázok 5.5 Use Case Diagram: Riadenie úloh Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár U.1 Vytvor úlohu Zadanie úlohy pre pouţívateľa systému inému alebo sebe Existencia pouţívateľa, ktorý je riešiteľom a zadávateľom Vytvorená úlohy v systéme Zadávateľ Zadávateľ ţiada o vloţenie novej úlohy 1. Otvorenie karty úlohy 2. Ţiadosť o vloţenie nového záznamu 35

38 3. Vyplnenie údajov komu je úloha určená, dátumy a popis 4. Kontrola vyplnenia povinných údajov 5. Vloţenie záznamu Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár U.2 Zaznamenaj priebeh úlohy Riešiteľ chce zaznamenať priebeh úlohy Úloha musí existovať Zmenené hodnoty atribútov úlohy percento dokončenia. Vloţenie informácie o priebehu úlohy. Riešiteľ Otvorenie karty s úlohou 1. Riešiteľ otvorí kartu s úlohami, ktoré má v riešení 2. INCLUDE U.8 Vyhľadaj úlohu: Vyhľadá úlohu, ktorej chce zmeniť stav alebo pridať záznam o priebehu 3. Vyplní údaje 4. Zápis údajov systémom Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár U.3 Ukonči úlohu Ukončenie úlohy Úloha musí existovať, vyplnené percento ukončenia Úloha ukončená a presunutá na schválenie Riešiteľ, Zadávateľ Spustenie funkcie ukonči úlohu 1. Riešiteľ zapíše dôvod a percento ukončenia 2. Nastaví úlohu do stavu ukončené cez funkciu 3. Zadávateľovi sa zobrazí táto úloha medzi úlohami na schválenie EXTEND: U.5 Schváľ úlohu Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár U.4 Zruš úlohu Zrušenie aktívnej úlohy Úloha je aktívna Úloha má príznak zrušená Riešiteľ,Zadávateľ Spustenie funkcie zrušenia úlohy 1. Vyhľadanie a zobrazenie karty úlohy 2. Vyplnenie dôvodu zrušenia 3. Spustenie funkcie zrušenie aktívnej úlohy riešiteľom alebo zadávateľom 4. Úloha je v stave zrušená a čaká na schválenie zrušenia u zadávateľa 5. EXTEND: U.5 Schváľ úlohu Prípad použitia Popis U.5 Schváľ úlohu Zadávateľ schvaľuje ukončenú alebo zrušenú úlohu 36

39 Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Úloha je v stave ukončená alebo zrušená 1. Úloha má príznak schválená 2. Vrátená úloha do riešenia stav v riešení Zadávateľ Zmena stavu ukončenej úlohy 1. Zadávateľ zobrazí ukončenú alebo zrušenú úlohu 2. Skontroluje riešenie úlohy a rozhodne o schválení alebo vrátení a. AK schváli TAK Úloha nadobudne stav schválená b. AK neschváli TAK vyplní dôvod neschválenia do poznámky a vráti úlohu do riešenia stav v riešení Evidencia zákazníkov, dodávateľov a kontaktov V evidencii zákazníkov a dodávateľov budeme uchovávať kontaktné informácie. Systém umoţní k nim vytvárať kontakty, pričom ku kaţdému z nich môţe existovať i viacero kontaktov. Taktieţ jeden kontakt môţe byť priradený k viacerým zákazníkom ale i dodávateľom. V prvom prípade je potrebné umoţniť, aby jeden kontakt zastupoval viacerých zákazníkov, v druhom treba zjednodušiť prípad, kedy zákazník môţe vystupovať aj ako dodávateľ, preto sme sa rozhodli nedeliť kontakty na zákaznícke a dodávateľské. Evidencia zákazníkov a kontaktov: Z.1 Vytvor zákazníka Z.2 Vytvor kontakt Z.3 Nastav prepojenie zákazníka s kontaktom Z.4 Vytvor zákazníka z kontaktu Z.5 Vytvor kontakt zo zákazníka Z.6 Vyhľadaj zákazníka Z.7 Vytlač adresár zákazníkov Z.8 Vyhľadaj kontakt 37

40 Obrázok 5.6 Use Case Diagram: Evidencia zákazníkov Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Z.1 Vytvor zákazníka Pouţívateľ ţiada o vloţenie nového zákazníka Vytvorený nový zákazník v databáze Pouţívateľ Presunutie sa na nový záznam 1. Otvorenie karty zákazníka 2. Ţiadosť o vloţenie nového záznamu, alebo presunutie na nový záznam 3. Vyplnenie informácií o zákazníkovi 4. Kontrola vyplnenia povinných údajov 5. Vloţenie záznamu Prípad použitia Popis Stav systému po ukončení Aktéri Z.2 Vytvor kontakt Pouţívateľ ţiada o vloţenie nového kontaktu Vytvorený nový kontakt v databáze Pouţívateľ 38

41 Inicializácia prípadu Scenár Presunutie sa na nový záznam 1. Pouţívateľ sa nastaví na nový záznam 2. Vyplní údaje o novom kontakte 3. Pred vloţením sa overí vyplnenie povinných polí 4. Vloţenie záznamu s novým kontaktom Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Alternatívny scenár Z.3 Nastav prepojenie zákazníka s kontaktom Vytvorenie prepojenia medzi kontaktom a zákazníkom Existujúci kontakt a existujúci zákazník Vytvorenie prepojenia zákazník - kontakt pouţívateľ Ţiadosť o prepojenie zákazníka s kontaktom 1. Pouţívateľ vyhľadá kartu kontaktu, ktorého chce priradiť k zákazníkovi 2. Zobrazí záloţku prepojení s týmto kontaktom. Do poľa číslo zákazníka vloţí číslo existujúceho zákazníka alebo ho vyberie zo zoznamu 3. Po vloţení čísla zákazníka sa overí jeho existencia Priradenie bude moţné aj zo strany zákazníka Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Z.4 Vytvor zákazníka z kontaktu Pouţívateľ ţiada o vytvorenie zákazníka podľa údajov z kontaktu Existujúca karta kontaktu Vytvorená karta zákazníka podľa karty kontaktu Pouţívateľ Pouţívateľ spustí funkciu vytvorenia zákazníka z kontaktu Scenár 1. Z karty kontaktu pouţívateľ spustí vytvorenie zákazníka podľa informácií z karty kontaktu 2. Systém overí sa či neexistuje zákazník k tomuto kontaktu. 3. Kontrola či kontakt uţ nie je priradený k zákazníkovi. Pokiaľ áno akcia sa preruší 4. Po overení vytvorenie zákazníka s primárnym kontaktom, z ktorého sme use case spúšťali Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Z.5 Vytvor kontakt zo zákazníka Pouţívateľ ţiada o vytvorenie kontaktu podľa údajov zo zákazníka Existujúca karta zákazníka Vytvorená karta kontaktu podľa údajov z karty zákazníka Pouţívateľ Spustenie akcie vytvorenia z karty zákazníka 1. Z aktuálnej karty zákazníka pouţívateľ spustí funkciu 39

42 vytvorenie kontaktu pre zákazníka 2. Overenie či neexistuje kontakt s príznakom spoločnosť a reláciou na zákazníka, z ktorého bola funkcia spustená a. AK takýto kontakt existuje TAK sa akcia preruší 3. Vytvorenie kontaktu podľa údajov zo zákazníka s príznakom spoločnosť Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Z.6 Vyhľadaj zákazníka Pouţívateľ hľadá zákazníka podľa zadaných parametrov Zákazníci spĺňajúci kritéria hľadania sa zobrazili Pouţívateľ Ţiadosť na vyhľadanie zákazníka 1. Pouţívateľ zvolí vyhľadanie zákazníka 2. Pouţívateľ zadá kritéria podľa, ktorých sa bude vyhľadávať 3. Systém zobrazí záznamy zákazníkov vyhovujúcim kritériám Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Z.7 Vyhľadaj kontakt Pouţívateľ hľadá kontakt podľa zadaných parametrov Kontakty spĺňajúce kritéria sa zobrazili Pouţívateľ Ţiadosť o vyhľadanie kontaktu 1. Pouţívateľ zvolí vyhľadanie v kontaktoch 2. Pouţívateľ zadá kritéria podľa, ktorých sa bude vyhľadávať 3. Systém zobrazí záznamy kontaktov vyhovujúcim kritériám Evidencia dodávateľov: D.1 Vytvor dodávateľa D.2 Nastav prepojenie dodávateľa s kontaktom D.3 Vytvor dodávateľa z kontaktu D.4 Vytvor kontakt z dodávateľa D.5 Vyhľadaj dodávateľa Evidencia dodávateľov je riešená analogicky, ako v prípade zákazníkov a nevyţaduje si ďalšie objasnenie. 40

43 Obrázok 5.7 Use Case Diagram: Evidencia dodávateľov Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár D.1 Vytvor dodávateľa Pouţívateľ ţiada o vloţenie nového dodávateľa Vytvorený nový dodávateľ v databáze pouţívateľ Presunutie sa na nový záznam alebo voľba vytvorenia nového dodávateľa 1. Otvorenie karty dodávateľa 2. Ţiadosť o vloţenie nového záznamu alebo presunutie na nový záznam 3. Vyplnenie informácií o dodávateľovi 4. Kontrola vyplnenia povinných údajov 5. Vloţenie záznamu Prípad použitia Popis Predpoklady D.2 Nastav prepojenie dodávateľa s kontaktom Vytvorenie prepojenia medzi kontaktom a dodávateľom Existujúci kontakt a existujúci dodávateľ 41

44 Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Vytvorenie prepojenia dodávateľ - kontakt Pouţívateľ Z karty kontaktu alebo dodávateľa sa spustí voľba vytvorenia prepojenia kontaktu s dodávateľom 1. Pouţívateľ otvorí kartu prepojení 2. Pouţívateľ vyhľadá kontakt 3. Pouţívateľ vyhľadá zákazníka 4. Prepojenie nastaví zápisom identifikátorov tejto dvojice hodnôt do tabuľky prepojení Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár D.3 Vytvor dodávateľa z kontaktu Pouţívateľ ţiada o vytvorenie dodávateľa podľa údajov z kontaktu Existujúca karta kontaktu Vytvorená karta dodávateľa podľa karty kontaktu Pouţívateľ Pouţívateľ ţiada o vytvorenie dodávateľa z kontaktu 1. Z karty kontaktu pouţívateľ spustí vytvorenie dodávateľa podľa informácií z karty kontaktu 2. Overí sa či neexistuje dodávateľ k tomuto kontaktu, ak áno akcia sa preruší 3. Po overení vytvorenie dodávateľa s primárnym kontaktom, z ktorého sme use case spúšťali Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár D.4 Vytvor kontakt z dodávateľa Pouţívateľ ţiada o vytvorenie kontaktu podľa údajov z dodávateľa Existujúca karta dodávateľa Vytvorená karta kontaktu podľa údajov z karty dodávateľa Pouţívateľ Spustenie akcie vytvorenia kontaktu z karty dodávateľa 1. Z aktuálnej karty dodávateľa pouţívateľ spustí funkciu vytvorenie kontaktu pre dodávateľa 2. Overí sa existencia firemného kontaktu pre dodávateľa. a. AK takýto kontakt existuje TAK sa akcia preruší 3. Vytvorenie kontaktu podľa údajov z dodávateľa s príznakom spoločnosť Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár D.5 Vyhľadaj dodávateľa Pouţívateľ hľadá dodávateľa podľa zadaných kritérií Dodávatelia spĺňajúci kritéria hľadania sa zobrazili Pouţívateľ Ţiadosť na vyhľadanie dodávateľa 1. Pouţívateľ zvolí vyhľadanie dodávateľa 42

45 2. Pouţívateľ zadá kritéria podľa, ktorých sa bude vyhľadávať 3. Systém zobrazí záznamy dodávateľov vyhovujúcim kritériám Evidencia tovarov Táto oblasť systému slúţi iba na evidenciu tovaru, teda sa nebudeme zaoberať nákupom zásob, ich sledovaním a vydávaním zo skladu. Tovary v našom prípade budú vystupovať na faktúre, preto sme ich evidenciu do nášho systému zaradili. Budeme rozlišovať medzi tovarom a zákazkovým tovarom. Tieto dva typy tovarov budeme aj ukladať v dvoch rôznych tabuľkách. Zákazkový tovar je tovar vyrábaný na mieru pre konkrétneho zákazníka. Systém umoţní tvorbu setov. Set je tovar predávaný ako celok zloţený z viacerých rôznych tovarov. V evidencii tovarov sme identifikovali tieto prípady pouţitia: T.1 Nastav číselník merných jednotiek T.2 Pridaj tovar T.3 Pridaj zákazkový tovar T.4 Vytvor set T.5 Vyhľadaj tovar 43

46 Obrázok 5.8 Use Case Diagram: Evidencia tovarov Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár T.1 Nastav číselník merných jednotiek Pouţívateľ nastavuje merné jednotky Vloţená merná jednotka Pouţívateľ Presunutie na nový záznam v zozname merných jednotiek 1. Pouţívateľ otvorí zoznam merných jednotiek 2. Presunie sa na nový záznam a vloţí kód a názov mernej jednotky Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár T.2 Pridaj tovar Pridanie nového tovaru Vytvorená karta tovaru Pouţívateľ Ţiadosť o vytvorenie novej karty tovaru 1. Pouţívateľ sa presunie na nový záznam alebo spustí funkciu nový tovar, ktorá ho tam presunie 2. Vyplní údaje o tovare 3. Systém skontroluje vyplnenie povinných polí a vloţí záznam 44

47 Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár T.3 Pridaj zákazkový tovar Pouţívateľ potrebuje pridať zákazkový tovar Tovar je vytvorený podľa ţelania zákazníka a nenachádza sa v klasických tovarových kartách Vytvorená karta zákazkového tovaru Pouţívateľ Ţiadosť o vytvorenie novej karty zákazkového tovaru 1. Pouţívateľ sa presunie na nový záznam alebo spustí funkciu, ktorá ho tam presunie 2. Vyplní údaje o tovare: názov, doba záruky, id zákazníka a pod. 3. Vyplní riadky, na ktorých sa nachádza zoznam činností a tovarov, z ktorých je zloţený zákazkový tovar. 4. Vyplní počty a ceny na riadkoch 5. Systém automaticky preráta cenu na riadku 6. Na hlavičke karty sa automaticky prerátava a zobrazuje hodnota celého zákazkového tovaru Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár T.4 Vytvor set Pouţívateľ vytvára nový tovar ako set existujúcich tovarov Tovary musia existovať Vytvorený set tovarov ako samostatný produkt Pouţívateľ Pouţívateľ ţiada vytvorenie nového setu tovarov 1. Pouţívateľ sa nastaví na nový záznam na karte tovaru 2. Vyplní údaje o tovare 3. Pouţívateľ nastaví mernú jednotku pre tovar. a. EXTEND: ak merná jednotka neexistuje v systéme: T.1 Nastav číselník merných jednotiek 4. Pouţívateľ sa presunie na záloţku set na karte tovaru 5. Systém zobrazí zoznam tovarov kam pouţívateľ zapíše tovary a mnoţstvá, z ktorých sa set skladá EXTEND: ak ešte neexistuje tovar, ktorý má byť v sete: T.2 Pridaj tovar 6. Po vloţení zoznamu pouţívateľ zavrie okno setu Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár T.5 Vyhľadaj tovar Pouţívateľ hľadá tovar podľa zadaných kritérií Tovary spĺňajúce kritéria hľadania sa zobrazili Pouţívateľ Ţiadosť na vyhľadanie tovaru 1. Pouţívateľ zvolí vyhľadanie tovaru 2. Pouţívateľ zadá kritéria podľa, ktorých sa bude vyhľadávať 3. Systém zobrazí záznamy tovarov vyhovujúcim kritériám 45

48 5.2.6 Fakturácia Funkcionalita fakturácie slúţi na predaj fakturačných podkladov od obchodníka k fakturantovi, ktorý ich spracuje v primárnom účtovníckom systéme. V diagrame pouţitia vystupujú teda dvaja aktéri pouţívateľ (ten čo vytvára podklady, napr. obchodník) a fakturant, ktorý sa postará o ich spracovanie. Kaţdý aktér má jasne definované svoje prípady pouţitia. V tejto časti analýzy iba hľadáme činnosti a priraďujeme ich pouţívateľom aktérom, preto sa nebudeme venovať postupnosti činností (prípadov pouţitia), ktorá je inak v tomto prípade veľmi dôleţitá. Procesy rozoberieme detailne v kapitole 5.3 Procesy a ich diagramy. Fakturácia zahŕňa tieto prípady pouţitia: F.1 Vytvor faktúru F.2 Vydaj faktúru F.3 Zaúčtuj faktúru F.4 Oprav chybnú faktúru F.5 Vyhľadaj faktúru Obrázok 5.9 Use Case Diagram: Fakturácia Prípad použitia Popis Predpoklady F.1 Vytvor faktúru Pouţívateľ vytvára podklady pre faktúru Existencia zákazníka, pre ktorého sa vytvára faktúra. Existujúce tovary a činnosti, ktoré sa budú fakturovať 46

49 Stav systému po ukončení Aktéri Inicializácia prípadu Scenár Vytvorená faktúra Pouţívateľ Presunutie na nový záznam alebo ţiadosť na vytvorenie nového záznamu cez tlačidlo 1. Na karte otvorenej faktúry sa pouţívateľ presunie na nový záznam 2. Pouţívateľ vloţí údaje do hlavičky a riadkov faktúry 3. Uloţenie záznamu faktúry stav otvorená Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár F.2 Vydaj faktúru Pouţívateľ vydáva faktúru ( vydanie znamená predaj faktúry fakturantovi na spracovanie) Existencia otvorenej faktúry, ktorej stav budeme meniť Vydaná faktúra ako podklad pre fakturáciu pre ďalšie spracovanie pre fakturanta Pouţívateľ Spustenie funkcie vydaj faktúru 1. Vyhľadanie faktúry 2. Vydanie faktúry zmena stavu faktúry do stavu Vydaná 3. Kontrola vyplnenia povinných polí a. Ak nastane chyba vrátenie pouţívateľa na kartu faktúry b. Po doplnení údajov zmena stavu faktúry na vydaná Prípad použitia Popis Predpoklady Stav systému po ukončení Aktéri Inicializácia prípadu Scenár F.3 Zaúčtuj faktúru Fakturant účtuje vydanú faktúru Existencia vydanej faktúry Faktúra so stavom zaúčtovaná Fakturant Účtovanie faktúry 1. Fakturant zobrazí faktúry v stave vydaná a dohľadá faktúru 2. Fakturant prekontroluje vydanú faktúru, ktorú pripravil pouţívateľ(obchodník). 3. Fakturant spustí funkciu zaúčtuj 4. Systém skontroluje vyplnenie povinných polí 5. Systém zmení stav faktúry na zaúčtovaná 6. Fakturant zaúčtuje faktúru v primárnom účtovníckom systéme Prípad použitia Popis Predpoklady F.4 Oprav chybnú faktúru Oprava zaúčtovanej faktúry Existencia zaúčtovanej faktúry 47

50 Stav systému po ukončení Opravená zaúčtovaná faktúra Aktéri Fakturant Scenár 1. Fakturant vyhľadá a zobrazí zaúčtovanú faktúru INCLUDE:F.4 Vyhľadaj faktúru 2. Urobí na nej potrebné zmeny 3. Pri modifikácii záznamu systém skontroluje správnosť vyplnenia polí Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár F.5 Vyhľadaj faktúru Pouţívateľ hľadá faktúru podľa zadaných kritérií Faktúry spĺňajúce kritéria hľadania sa zobrazili Pouţívateľ, fakturant Ţiadosť na vyhľadanie faktúr 1. Pouţívateľ zvolí vyhľadanie v zaúčtovaných faktúrach 2. Pouţívateľ zadá kritéria podľa, ktorých sa bude vyhľadávať 3. Systém zobrazí zoznam faktúr vyhovujúcich kritériám Riadenie projektov Ako sme uţ spomínali projekt slúţi na vytvorenie prepojenia medzi zákazníkom, činnosťami, ktoré boli uskutočnené a faktúrami, pričom všetky uvedené objekty súviseli s jednou zákazkou. S projektom, ako objektom v databáze, nie je nutné vykonávať iné činnosti ako jeho zaloţenie a ukončenie. Riadenie projektov teda pozostáva z nasledovných prípadov pouţitia: P.1 Zaloţ projekt P.2 Ukonči projekt P.3 Vyhľadaj projekt Obrázok 5.10 Use Case Diagram: Riadenie projektov 48

51 Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár P.1 Založ projekt Pouţívateľ vytvára nový projekt v systéme Vytvorenie novej karty projektu Pouţívateľ Presunutie na nový záznam na karte projektu alebo voľba nový záznam 1. Otvorenie karty projektu 2. Vyplnenie údajov 3. Vyhľadanie Zákazníka, ku ktorému sa projekt vzťahuje INCLUDE: Z.6 Vyhľadaj zákazníka 4. Kontrola vyplnenia povinných polí: a. AK nie sú vyplnené polia, TAK hlásenie o tejto skutočnosti a návrat na záznam b. AK Ignorovanie hlásenia o nevyplnených poliach TAK prerušenie vkladania alebo zmeny záznamu. 5. Uloţenie záznamu Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár P.2 Ukonči projekt Pouţívateľ uzatvára projekt Projekt je označený ako ukončený Pouţívateľ Spustenie voľby Ukonči projekt na karte projektu 1. Otvorenie karty projektu 2. Spustenie voľby Ukonči projekt na karte projektu 3. Systém zmení stav projektu z otvorený na ukončený 4. Uloţenie záznamu Prípad použitia Popis Stav systému po ukončení Aktéri Inicializácia prípadu Scenár P.3 Vyhľadaj projekt Pouţívateľ hľadá projekt podľa zadaných kritérií Projekty spĺňajúce kritéria hľadania sa zobrazili Pouţívateľ Ţiadosť na vyhľadanie projektu 1. Pouţívateľ zvolí vyhľadanie projektu 2. Pouţívateľ zadá kritéria podľa, ktorých sa bude vyhľadávať 3. Systém zobrazí zoznam projektov vyhovujúcim kritériám Pri návrhu diagramov prípadov pouţitia sme pracovali v aplikácii Umbrello UML Modeler, čo je nástroj na tvorbu UML diagramov pre podporu vývoja aplikácií (Umbrello UML Modeller, dátum neznámy). 49

52 5.3 Analýza: Procesy a ich diagramy Pre znázornenie procesov v organizácii pouţijeme diagramy aktivít (activity diagram). Diagramy aktivít nám vo všeobecnosti znázorňujú následnosti činností. V našom prípade ich pouţijeme nadviazaním na existujúce prípady pouţitia. V prípadoch pouţitia sme identifikovali činnosti, ktoré je nutné vykonávať, ale táto technika neumoţňuje znázornenie ich následnosti. Činnosti, pri ktorých je nutné dodrţiavať postupnosť sú riešenie úlohy, proces fakturácie a zaznamenania komunikácie. Zaznamenávanie komunikácie tu pridávame len pre úplnosť, pretoţe sa jedná o proces jednoduchý a jeho pochopenie si v podstate nevyţaduje znázornenie diagramom Riešenie úlohy Diagram aktivity riešenia úlohy nám znázorňuje celý proces od vytvorenia (zadania) úlohy aţ po jej ukončenie. Zahájením aktivity je vytvorenie úlohy zadávateľom. Riešiteľ pracuje na riešení, pričom priebeţne zaznamenáva stav, v ktorom je úloha a kroky, ktoré uskutočnil pri jej riešení. Riešiteľ končí riešenie buď vyriešením úlohy, alebo poţiadaním o zrušenie v prípade, ţe dospeje k tomu, ţe úlohu nie je moţné vyriešiť podľa zadania. Zadávateľ potom rozhoduje, či záver vyplývajúci z riešenia úlohy je postačujúci a rozhodne o schválení riešenia, poprípade jej zrušenia alebo úlohu vráti opätovne na riešenie. Schválenie úlohy je ukončením aktivity. 50

53 Obrázok 5.11 Activity Diagram: Riešenie úlohy Fakturácia Fakturácia vykonaných činností a dodaného tovaru môţe prebiehať okrem súhrnnej faktúry za celý projekt aj čiastočne v priebehu projektu. Obchodník predáva potrebné podklady fakturantovi, ktorý na základe nich vystaví faktúru zákazníkovi. V navrhovanom systéme vytvorí obchodník faktúru, ktorá nadobudne stav otvorená. V tomto momente môţe obchodník robiť na nej akékoľvek zmeny a úpravy. Po tom ako má pripravené všetky podklady faktúru, tieto predá fakturantovi. Zmení stav faktúry na vydaná. Táto zmena stavu znamená predanie faktúry na spracovanie fakturantovi. Ten preberie vydanú faktúru, skontroluje ju a zúčtuje v primárnom účtovníckom systéme a následne zaúčtuje v našom systéme. Účtovanie v našom informačnom systéme znamená iba zmenu stavu faktúry na zaúčtovaná. Takto budeme označovať fakturantom spracované faktúry. 51

54 Obrázok 5.12 Activity Diagram: Faktúrácia Komunikácia Kaţdá komunikácia bude zaznamenávaná bez rozdielu či bola iniciovaná firmou alebo zákazníkom. Obrázok 5.13 Activity Daigram: Komunikácia 5.4 Návrh systému Dátový model V tomto momente uţ vieme, čo má systém vykonávať a ako to má vykonávať, ale nevieme, ako to budeme v systéme zaznamenávať. Pri návrhu štruktúry databázy budeme postupovať v dvoch krokoch. V logickom dátovom modely určíme objekty entity, ktoré budeme v databáze, vzťahy medzi nimi a ich atribúty. Tento model je všeobecný a nezávislý od konkrétneho databázového systému. Opisuje logiku uloţenia a prepojenia 52

55 objektov v databáze, ale nie ich konkrétnu štruktúru závislú od pouţitého dátového úloţiska. Uplatnením pravidiel databázového systému Access vytvoríme fyzický dátový model. Ten nám zobrazuje uţ konkrétnu podobu ukladania objektov v databáze Logický dátový model V logickom dátovom modeli pracujeme s entitami, atribútmi a vzťahmi (väzbami) medzi nimi. Ako prvé musíme určiť entity, ktoré predstavujú logické objekty v databáze a atribúty, ktoré vypovedajú o ich vlastnostiach. Na záver určíme vzájomné väzby entít. Z predchádzajúcej analýzy vyplýva, ţe našimi entitami budú: zákazník, dodávateľ, kontakt, pouţívateľ, úloha, projekt, faktúra, komunikácia, tovar, zákazkový tovar, činnosť a relácia kontaktu: - zákazník: Z názvu je zrejmé, ţe táto entita bude predstavovať zákazníkov spoločnosti. O zákazníkoch chceme ukladať informácie o názve spoločnosti, adrese, telefonických a elektronických kontaktoch. Okrem týchto údajov by sme chceli mať moţnosť zapisovať si poznámky týkajúce sa zákazníka. Ďalej je nutné zákazníka v databáze jednoznačne identifikovať, preto medzi atribúty pridáme ID ako jednoznačný identifikátor - primárny kľúč. Na základe poţiadaviek môţe entita zákazník vyzerať nasledovne: Zákazník ID zákazníka Názov Adresa Kontaktné údaje Poznámka Tabuľka 5-1 Logický model: entita zákazník Zatiaľ nechceme rozvádzať, ako budeme adresu fyzicky v databáze ukladať, pretoţe to je cieľom fyzického modelu. Logický model by nám mal skôr určiť, aké informácie budeme ukladať, nie ako ich budeme ukladať. - dodávateľ: Obdobne, ako v prípade entity zákazník, budeme aj v prípade dodávateľov zaznamenávať názov, adresu, kontaktné údaje, poznámku a k nim ešte pripojíme jednoznačný identifikátor: Dodávateľ ID dodávateľa Názov Adresa Kontaktné údaje Poznámka Tabuľka 5-2 Logický model: entita dodávateľ 53

56 - kontakt: Kontakt bude predstavovať entitu, v ktorej budeme uchovávať informácie o kontaktných osobách zákazníkov a dodávateľov. V kontaktoch budeme okrem nich uchovávať aj údaje o spoločnostiach, ktoré ešte nie sú zákazníkmi, popr. dodávateľmi. Právnickú osobu od fyzickej odlíšime pouţitím bivalentného atribútu spoločnosť. Samozrejme je nutné jednoznačne identifikovať kontakt v databáze, preto pridáme jednoznačný identifikátor ID. Kontakt ID kontaktu Názov (meno a priezvisko) Adresa Kontaktné údaje Poznámka Spoločnosť (áno/nie) Tabuľka 5-3 Logický model: entita kontakt - pouţívateľ: Entita pouţívateľ predstavuje pouţívateľa informačného systému. Okrem štandardných atribútov ako meno a priezvisko, adresa, kontaktné údaje, dátum narodenia a poznámka budeme mať v systéme uloţenú jeho fotografiu, dokumenty vzťahujúce sa k jeho osobe (napr. pracovná zmluva), heslo a bivalentné atribúty fakturant, administrátor a aktívny. V atribúte heslo bude zaznamenané jeho aktuálne heslo pre potreby overenia pouţívateľa pre prístup do aplikácie. Atribút fakturant hovorí o tom, či daný pouţívateľ je alebo nie je fakturantom. Analogicky administrátor vypovedá o tom, či sa jedná o administrátora, teda pouţívateľa so všetkými právami v aplikácii, ktoré ho oprávňujú robiť zmeny v jej nastavení a v nastavení pouţívateľov. Pouţívateľ ID pouţívateľa Meno Priezvisko Adresa Kontaktné údaje Dátum narodenia Poznámka Fotografia Dokumenty Názov prac. pozície Aktívny (áno/nie) Fakturant (áno/nie) Administrátor (áno/nie) Heslo Tabuľka 5-4 Logický model: entita pouţívateľ - úloha: Entita úloha obsahuje informácie kto zadal a kto rieši úlohu, jej aktuálny stav a percento dokončenia, stručný popis, celé znenie úlohy, poţadovaný dátum 54

57 ukončenia, reálny dátum ukončenia, dátum schválenia, prílohy a identifikátor projektu ku ktorému sa vzťahuje. Úloha ID úlohy Stav ID zadávateľa (pouţívateľa) ID riešiteľa (pouţívateľa) Percento dokončenia Stručný popis Znenie úlohy Dátum zadania úlohy Poţadovaný dátum ukončenia Reálny dátum ukončenia Dátum schválenia Priebeţné poznámky Prílohy ID projektu Tabuľka 5-5 Logický model: entita úloha - projekt: K projektu je priradený zákazník a kontaktná osoba zákazníka, ďalej budeme zaznamenávať stručný popis, dátum zaloţenia, reálneho začatia a ukončenia, poznámky, prílohy a bivalentný atribút, ktorý nám bude hovoriť, či sa jedná o aktívny projekt. Na jednoznačnú identifikáciu projektu pridáme atribút ID. Projekt ID projektu ID zákazníka ID primárneho kontaktu Dátum zaloţenia Dátum začatia Dátum ukončenia Popis Poznámka Prílohy Aktívny Tabuľka 5-6 Logický model: entita projekt - faktúra: Entita faktúra predstavuje faktúru, ktorá je vystavená zákazníkovi. Nakoľko náš systém faktúru pouţíva ako podklad pre fakturáciu (neriešime účtovanie) nebudeme v nej udrţiavať všetky informácie vyplývajúce z legislatívy. Pre nás sú podstatné informácie komu je faktúra vystavená, kto je kontaktnou osobou zákazníka,adresa a kontaktné údaje zákazníka, stav v akom sa nachádza faktúra, ku ktorému projektu sa vzťahuje, ktorý pouţívateľ ju vytvoril a ktorý 55

58 zaúčtoval a dátumy vytvorenia, predania fakturantovi a zaúčtovania. Entita faktúra bude teda vyzerať nasledovne: Faktúra ID faktúry ID kontaktu ID zákazníka Názov zákazníka Adresa zákazníka Kontaktné údaje zákazníka Stav (otvorená,vydaná,zaúčtovaná) Poznámka ID pouţívateľa vytvoril ID pouţívateľa zaúčtoval ID projektu Dátum vytvorenia Dátum vydania Dátum zaúčtovania Tabuľka 5-7 Logický model: entita faktúra - riadok faktúry: Ako ste si mohli všimnúť, faktúre v takomto stave stále niečo chýba. Sú to poloţky, ktoré sú fakturované. Z dôvodu, ţe týchto poloţiek vzťahujúcich sa k faktúre môţe byť viacej museli sme vytvoriť novú entitu riadok faktúry. Aby sme mohli riadok faktúry prepojiť s prislúchajúcou hlavičkou (entita faktúra) musíme pridať do entity jej identifikátor. Na jednoznačnú identifikáciu riadku faktúry v databáze tak budeme potrebovať dva atribúty identifikátor faktúry a identifikátor riadku faktúry. Ďalšie informácie, ktoré potrebujeme sú typ fakturovanej poloţky (tovar, zákazkový tovar, činnosť, poznámka, iné), jej identifikátor, mnoţstvo, mernú jednotku a cenu za mernú jednotku. Ešte sme sa rozhodli pridať atribút cena riadku. Cena riadku nemusí zodpovedať vzorcu mnoţstvo * cena za mernú jednotku, v prípade, ţe chceme uplatniť zľavu na celkovú sumu. Riadok faktúry ID faktúry ID riadku faktúry Typ ID typu Popis Mnoţstvo Merná jednotka Cena za mernú jednotku Cena riadku faktúry Tabuľka 5-8 Logický model: entita riadok faktúry 56

59 - komunikácia: Entita komunikácia bude obsahovať informácie o tom, akým spôsobom komunikácia prebiehala, kto a s kým komunikoval, kedy a ako dlho komunikácia prebiehala, k akému projektu a úlohe sa vzťahovala a nakoniec stručný popis komunikácie a dokumenty sa k nej vzťahujúce (napr. mailové prílohy, cenové ponuky a pod.). Budeme uchovávať aj informáciu, či sme iniciovali komunikáciu my alebo zákazník. Komunikácia ID komunikácie Spôsob komunikácie ID kontaktu ID zákazníka ID pouţívateľa Dátum a čas komunikácie Trvanie Stručný popis Poznámka Dokumenty Smer komunikácie ID úlohy ID projektu Tabuľka 5-9 Logický model: entita komunikácia - tovar: O tovare budeme uchovávať len základné informácie: jeho názov, popis, poznámku, identifikátor dodávateľa, označenie tovaru dodávateľom, nákupnú a predajnú cenu, mernú jednotku a prílohy (napr. pouţívateľský návod, špecifikácie a pod.) Tovar ID tovaru Názov Popis ID dodávateľa Základná merná jednotka Poznámka Prílohy Nákupná cena Predajná cena Číslo tovaru dodávateľa Tabuľka 5-10 Logický model: entita tovar - zákazkový tovar: Zákazkový tovar je analógiou tovaru. Oddelenie od entity tovaru nastalo z dôvodu prehľadnosti. Nechceli sme miešať štandardný tovar a tovar vyrábaný na mieru a predávaný konkrétnemu zákazníkovi. 57

60 Zákazkový tovar ID zákazkového tovaru Názov Popis ID dodávateľa Základná merná jednotka Poznámka Prílohy Nákupná cena Predajná cena Číslo tovaru dodávateľa Tabuľka 5-11 Logický model: entita zákazkový tovar - činnosť: Entita činnosť predstavuje fakturované úkony. Jej atribúty sú označenie činnosti, popis a merná jednotka. Činnosť ID činnosti Popis Základná merná jednotka Tabuľka 5-12 Logický model: entita činnosť - relácia kontaktu: Predstavuje prepojenie medzi entitou kontakt a dodávateľmi a zákazníkmi. Relácia kontaktu ID kontaktu Typ relácie (zákazník, dodávateľ) ID relácie (ID zákazníka, ID dodávateľa) Tabuľka 5-13 Logický model: entita relácia kontaktu Teraz, keď uţ máme zadefinované entity a atribúty, vytvoríme logický dátový model, v ktorom budú znázornené entity a ich vzájomné väzby. Primárne kľúče sme označili prefixom atribútu (PK) primary key, cudzie kľúče majú v atribúte prefix (FK) foreign key. Logický dátový model navrhovaného informačného systému je znázornený na obrázku Obrázok 5.14 Logický dátový model IS. 58

61 Obrázok 5.14 Logický dátový model IS 59

62 5.4.3 Fyzický dátový model Fyzický dátový model zavisí na konkrétnej databáze, ktorú pre svoju aplikáciu pouţijeme. Teda je na rozdiel od logického modelu platformovo závislý. Logický dátový model hovorí čo budeme uchovávať v databáze a fyzický ako to budeme uchovávať. Pri tvorbe fyzického dátového modelu budeme postupovať mapovaním logických entít do tabuliek a atribútov do stĺpcov resp.polí, ak pouţijeme terminológiu Accessu. Dátové typy polí (stĺpcov) budeme voliť uţ podľa zvolenej databázy MS Access MS Access 2007 podporuje 10 dátových typov (Viescas & Conrad, 2008): Text (Text): alfanumerické údaje do 255 znakov Memo (Memo): alfanumerické údaje do veľkosti aţ 1 gigabajt, ale ovládacie prvky tohto typu podporujú zobrazenie prvých znakov. Tento dátový typ podporuje aj formátovanie textu html Number (Číslo): číselné údaje. Veľkosť pola závisí na zvolenej veľkosti: Byte, Integer, Long Integer, Single, Double, Replication ID, Decimal (1,2,4,8 a 16 bajtov) Date/Time (Dátum/čas): na uchovávanie dátumov a časov Currency (Mena): peňaţné hodnoty uloţené s presnosťou na štyri desatinné miesta AutoNumber (Automatické číslo): generátor jedinečných celočíselných hodnôt (Long Integer) pre nové záznamy Yes/No (Áno/Nie): pre uchovávanie bivalentných údajov pravda/nepravda, áno/nie OLE Object (Objekt OLE): obrázky, grafy alebo iné OLE objekty z aplikácií fungujúcich pod Windows. Moţnosť uloţenia objektu s veľkosťou aţ 2 gigabajty Hyperlink (Hypertextový odkaz): adresa na dokument na počítači, lokálnej sieti alebo internete worl wide webe Attachment (Príloha): slúţi na ukladanie súborov rôznych typov do databázy. Do jedného poľa typu attachment je moţné uloţiť ľubovoľný počet súborov aţ do celkovej veľkosti 2 gigabajty. Mapovanie entity zákazník: 60

63 Obrázok 5.15 Mapovanie entity zákazník a jej atribútov do tabuľky Polia KodKrajiny a PSC majú reláciu do novovytvorenej tabuľky tblpsc. Z nej má moţnosť pouţívateľ vybrať uţ vloţené záznamy. Na základe zadaného kódu krajiny a PSČ sa automaticky v prípade existencie tejto kombinácie v tabuľke tblpsc dotiahne mesto. Toto je riešené ale uţ na úrovni formuláru. Mapovanie entity dodávateľ: Obrázok 5.16 Mapovanie entity dodávateľ a jej atribútov do tabuľky 61

64 Mapovanie entity kontakt: Obrázok 5.17 Mapovanie entity kontakt a jej atribútov do tabuľky Tu chceme upozorniť na mapovanie atribútu Názov (meno a priezvisko). Nakoľko sa v tejto tabuľke budú nachádzať kontakty na fyzické aj právnické osoby pouţijeme polia Názov a Názov 2 aj na ukladanie priezviska (Názov) a mena (Názov 2) a aj názvu spoločnosti. 62

65 Mapovanie entity pouţívateľ: Obrázok 5.18 Mapovanie entity pouţívateľ a jej atribútov do tabuľky V porovnaní s entitou Pouţívateľ sa nachádza v tabuľke pole ZmenaHesla, ktoré v nej nemá paralelu. Toto pole pouţíva administrátor a určuje, či je pouţívateľ pri ďalšom prihlásení do systému vyzvaný na zmenu hesla Mapovanie entity úloha: Obrázok 5.19 Mapovanie entity úloha a jej atribútov do tabuľky 63

66 Mapovanie entity projekt: Mapovanie entity faktúra: Obrázok 5.20 Mapovanie entity projekt a jej atribútov do tabuľky Obrázok 5.21 Mapovanie entity faktúra a jej atribútov do tabuľky Mapovanie entity riadok faktúry: Obrázok 5.22 Mapovanie entity riadok faktúry a jej atribútov do tabuľky 64

67 Mapovanie entity komunikácia: Obrázok 5.23 Mapovanie entity komunikácia a jej atribútov do tabuľky Mapovanie entity tovar: Obrázok 5.24 Mapovanie entity tovar a jej atribútov do tabuľky Mapovanie entity zákazkový tovar: Obrázok 5.25 Mapovanie entity zákazkový tovar a jej atribútov do tabuľky 65

68 Mapovanie entity činnosť: Obrázok 5.26 Mapovanie entity činnosť a jej atribútov do tabuľky Mapovanie entity relácia kontaktu: Obrázok 5.27 Mapovanie entity relácia kontaktu a jej atribútov do tabuľky Okrem uţ uvedených fyzických tabuliek sa v navrhovanom systéme nachádzajú aj ďalšie, ktoré priamo vyplynuli z normalizácie dátového modelu. Táto technika úpravy dátového modelu sa pouţíva z týchto dôvodov (Kanisová & Müller, 2006, s. 110): - identifikácia vzájomného vzťahu dát - zdruţenie dát do optimálnych skupín - vyriešenie nejednoznačnosti - umoţnenie dodatočného rozšírenia dátovej základne informačného systému - vytvorenie spoločnej bázy zdielaných dát - presná definícia dátových poloţiek - jednoduchá údrţba dát Z uvedených dôvodov pribudli do fyzického dátového modelu nasledovné tabuľky: tblkrajina: Tabuľka tblkrajina obsahuje kódy a názvy krajín, napr. SK Slovensko. Táto informácia sa pouţije pri zadávaní adries zákazníkov, dodávateľov a kontaktov pri zafiltrovaní poštových smerovacích čísel pre konkrétnu krajinu. Táto tabuľka pribudla z dôvodu zjednodušenia a urýchlenia zadávania vstupných informácií. Tabuľka 5-14 Tabuľka tblkrajina tblmernajednotka: Tabuľka tblmernajednotka obsahuje kódy a názvy merných jednotiek. Do tejto tabuľky si pouţívatelia zadajú kódy merných jednotiek pouţívaných pri tovaroch 66

69 a činnostiach. Existencia tejto tabuľky umoţní v systéme definovanie vlastných pouţívateľom definovaných merných jednotiek, napr. paleta, kartón,a pod. Tabuľka 5-15 Tabuľka tblmernajednotka tblpsc: Tabuľka tblpsc obsahuje informácie o poštových smerovacích číslach. Pole KodKrajiny je reláciou to tabuľky tblkrajina a slúţí na filtrovanie záznamov v nej pri zadávaní vstupných údajov pouţívateľom. Tabuľka 5-16 Tabuľka tblpsc tblset: Tabuľka tblset umoţňuje v systéme vytváranie tovarov zloţených z viacerých tovarov. Tabuľka 5-17 Tabuľka tblset tblspolocnost: Tabuľka tblspolocnosť obsahuje len jeden záznam. V ňom sa nachádzajú informácie o spoločnosti. Navrhovaný informačný systém v súčasnosti s touto tabuľkou nepracuje, ale predpokladáme, ţe nasledujúci vývoj si jej vytvorenie vyţiada, preto sme ju pridali uţ teraz. Tabuľka 5-18 Tabuľka tblspolocnost 67

70 tblsposobkomunikacie: Tabuľka tblsposobkomunikacie obsahuje pouţívateľsky definované spôsoby komunikácie, ktoré sa potom prideľujú zaznamenanej komunikácii. Tabuľka 5-19 Tabuľka tblsposobkomunikacie Stavové diagramy Stavové diagramy pouţijeme na znázornenie správania sa objektov, ktoré vyplynuli z logického modelu. V navrhovanom systéme existujú dva objekty, ktorých momentálny stav hrá kľúčovú úlohu. Na základe ich stavu potom dochádza k ich ďalšiemu spracovaniu konkrétnymi aktérmi. Jedná sa o úlohu a faktúru. Ich stav určuje, ktorý aktér s daným objektom aktuálne pracuje a ako s ním pracuje. Úloha Úloha nadobúda nasledujúce stavy: zadaná, v riešení, zrušená, ukončená a schválená. Z diagramu prípadu pouţitia (Obrázok 5.5 Use Case Diagram: Riadenie úloh) vyplýva, ţe s týmto objektom pracujú dvaja aktéri - zadávateľ a riešiteľ. Úloha vzniká jej zadaním zadávateľom, pričom pri svojom vzniku nadobudne stav zadaná. Z tohto stavu môţe prejsť do dvoch stavov : v riešení a zrušená. Zrušenie môţe iniciovať ako riešiteľ, pri neschopnosti úlohu vyriešiť, tak aj zadávateľ v prípade, ţe sa situácia zmenila a úloha uţ nie je aktuálna. Stav v riešení získava úloha v momente, keď sa s ňou začne riešiteľ zaoberať alebo inak povedané začne podnikať kroky k jej splneniu. Tieto kroky potom zaznamenáva do priebehu riešenia úlohy. Počas riešenia môţe dôjsť taktieţ k situácii, ţe úloha prestala byť aktuálna alebo sa nedá podľa zadania uskutočniť, vtedy dochádza taktieţ k nadobudnutiu stavu zrušená. Po úspešnom dokončení úlohy riešiteľ posunie stav úlohy z v riešení do stavu ukončená. Stavy ukončená a zrušená presúvajú ďalšie spracovanie úlohy na zadávateľa. Ten rozhoduje či zrušenie a ukončenie je opodstatnené, teda či úloha je naozaj vyriešená podľa zadania alebo sa naozaj dostupnými prostriedkami nedá uskutočniť. Pri kladnom rozhodnutí úloha prechádza do svojho posledného stavu schválená. V prípade nespokojnosti s postupom riešenia zadávateľ môţe vrátiť úlohu do pôsobnosti riešiteľa zmenou stavu na v riešení. 68

71 Obrázok 5.28 Stavový diagram: Riešenie úlohy Faktúra Faktúra môţe nadobúdať tri stavy: otvorená, vydaná a zaúčtovaná. Pri vytvorení faktúry pouţívateľom automaticky nadobudne stav otvorená. V tomto stave je moţné faktúru pouţívateľom neustále meniť a upravovať. Pouţívateľ potom posunie faktúru do stavu vydaná. Toto je moment, kedy uţ na nej nemôţe robiť úpravy a faktúra čaká na ďalšie spracovanie fakturantom. Ten môţe urobiť potrebné úpravy. Pokiaľ poţaduje urobenie opráv od pouţívateľa, ktorý vydal faktúru, tak ju vráti do stavu otvorená. Skontrolovanú a vydanú faktúru potom zaúčtuje, kedy faktúra nadobudne stav zaúčtovaná. Zaúčtovanie v sebe zahŕňa vytvorenie a zaúčtovanie faktúry podľa vzoru z nášho systému, v primárnej účtovníckej aplikácii. Z nej potom zoberieme aktuálne číslo faktúry a zapíšeme ho do našej,stále vydanej, faktúry. Aţ teraz fakturant zaúčtuje faktúru v našom systéme. 69

72 Obrázok 5.29 Stavový diagram: Fakturácia 5.5 Realizácia IS Cieľom nášho snaţenia bolo vytvorenie pouţívateľsky jednoduchej aplikácie, ktorá by spĺňala poţiadavky zákazníka. To, či sme pochopili správne procesy v organizácii ukáţe test zákazníka na vytvorenom prototype. Okrem správnosti analýzy vplýva na pouţiteľnosť systému aj rozhranie, s ktorým prebiehala komunikácia medzi pouţívateľom a systémom. Grafické pouţívateľské rozhranie sme navrhli s ohľadom na rýchlosť vyhľadania a uskutočnenia operácií pouţívateľom. Po prihlásení pouţívateľa do systému (pozri Príloha E: Prihlásenie pouţívateľov) sa otvorí pracovná plocha (Obrázok 5.30 Grafické rozhranie IS), ktorá zobrazuje aktívne úlohy a faktúry, pri ktorých sa vyţaduje akcia zo strany prihláseného pouţívateľa. Takýmto spôsobom sme chceli čo najjednoduchšie a čo najrýchlejšie sprostredkovať pouţívateľovi najdôleţitejšie informácie, ktoré potrebuje pri svojej práci. Na pravú stranu pracovnej plochy sme pridali rýchly prístup, v ktorom sa nachádzajú, podľa našich predpokladov, pouţívateľom najčastejšie pouţívané funkčnosti systému. Opäť sme sa snaţili pouţívateľa odbremeniť od prehľadávania menu a urýchliť tak prístup k funkčnostiam, v čo moţno najmenšom počte krokov. Na pravej strane sa nachádza Hlavné menu (oblasť 1 v Obrázok 5.30 Grafické rozhranie IS), ktoré sme implementovali pomocou navigačnej tably (navigation pane), ktorá bola do programu Access pridaná práve aktuálnou verziou Navigačnú tabľu moţno podľa potreby skrývať a tým zväčšovať pracovnú plochu. Tento nový ovládací 70

73 prvok ma viacero výhod. Najdôleţitejšia je jednoduchá správa odkazov na funkčnosti systému a ich organizovanie do logických skupín. Pridaním tably vzniká jednotná a pouţívateľovi známa forma ovládania naprieč viacerými aplikáciami navigačnú tablu môţeme vidieť aj v poštovom klientovi Outlook Prototyp informačného systému obsahuje formuláre dvoch typov: zoznam a detail. Detail zobrazuje vţdy iba jeden záznam z tabuľky a obsahuje viacej informácií ako zoznam, ktorý zobrazuje viacero záznamov z tabuľky podľa zvoleného filtra. Formulár typu detail je zobrazený v prílohe C, formulár typu zoznam je v prílohe D. V aplikácii sme zatiaľ nevytvorili tlačové zostavy. Tieto neboli predmetom našej analýzy a ich špecifikácia príde na rad po overení správnosti prototypu zo strany pouţívateľov. V aplikácií pouţívame jednotný vzhľad pre spúšťače funkcií a otváranie formulárov. V aplikácii teda nenájdete klasické tlačidlá (button), ktoré sa pouţívajú v desktopových aplikáciách. Všetko, na čo môţe pouţívateľ v aplikácii kliknúť, je riešené formou hypertextového odkazu. Výnimku tvorí len tlačidlo obnovenia zobrazenia (oblasť 8 v Obrázok 5.30 Grafické rozhranie IS) a navigačná tabla, ale tam nie je nutné zvýrazňovať kliknuteľné oblasti, pretoţe sú nimi všetky v nej obsiahnuté odkazy a skôr by týmto formátom došlo k zníţeniu prehľadnosti. K zvýšeniu pouţiteľnosti prostredia poslúţi aj otváranie formulárov pomocou hypertextových odkazov priamo z polí formulára, ktoré majú reláciu na ostatné entity. Opäť nemusíme vyhľadávať informácie o entite z hlavného menu ale jedným kliknutím sa nám otvorí jej formulár typu detail. 71

74 Obrázok 5.30 Grafické rozhranie IS 72

75 5.6 Testovanie Testovanie aplikácie prebiehalo v dvoch rovinách: z pohľadu programátora a z pohľadu analytika. Programátor testuje počas vývoja funkčnosti za pomoci kompilátora aplikácie syntaktickú správnosť zápisu kódu. Inak povedané kompilátor overí či zapísaný kód spĺňa pravidlá programovacieho jazyka. Takéto testovanie neodhalí ale logickú správnosť vytvorenej funkčnosti, preto nasleduje testovanie logickej správnosti funkčnosti, ktorá overí či program sa správa tak, ako sa od neho očakáva. Správnosť správania sa systému overíme porovnaním s analýzou s predchádzajúcich krokov. Proces testovania na strane programátora pri vývoji nových funkčností systému je v drvivej väčšine opakujúci sa, pretoţe nie je príliš časté, najmä pri komplexnejších úpravách, vytvoriť kód naslepo bez čiastkového overovania hneď správne. V podstate postupujeme v menších krokoch, ktoré sa testujú a opravujú a na tieto kúsky sa nabaľuje ďalší vývoj. Je oveľa jednoduchšie nájsť chybu v menších prírastkoch kódu a opraviť ju, ako naprogramovať celú komplexnú funkčnosť a aţ následne overovať jej správnosť. Iteratívny vývoj a testovanie nám zaručí,ţe v nasledujúcom kroku staviame na správnych základoch. Takéto testovanie je súčasťou implementácie, pretoţe ho uskutočňuje programátor, napriek tomu sme chceli popísať spôsob programátorskej činnosti, ktorý v seba zahŕňa do určitej miery aj testovanie. Testovanie aplikácie programátorom sa obmedzuje výlučne na aktuálne vyvíjanú funkčnosť systému. Môţe ísť napríklad o vytvorenie formuláru typu detail pre niektorú entitu, funkčnosť vydania faktúry, pridávania pouţívateľa, otvorenie prehľadu pouţívateľov a podobne. Takéto overenie nie je dostatočné, pretoţe nedochádza k testu spolupráce a náväzností jednotlivých modulov systému. Analytické testovanie overí, či aplikácia dodrţiava návrh systému z komplexného pohľadu dochádza k testovaniu správania sa systému v interakcii s pouţívateľom na základe definovaných prípadov pouţitia, či entity nadobúdajú stavy v postupnosti definovanej v stavových diagramoch a nakoniec, či aplikácia dodrţiava následnosť činností, ktoré prebiehajú v našej organizácii, ktoré sú definované v diagramoch aktivít. Práve v tejto fáze testovania sme odhalili aj v našom projekte chybu v procese schvaľovania faktúry, kedy vydanie faktúry nespôsobilo jej predanie fakturantovi a tým neumoţnilo jej zaúčtovanie. V týchto prípadoch sa musíme vrátiť do fázy implementácie. 73

76 5.7 Zavedenie do produkcie V našom prípade sa jedná o najjednoduchší stav, ktorý mohol nastať, pretoţe spoločnosť momentálne nevyuţíva ţiaden IS, ktorý by bol v konflikte s našim systémom a nemusíme riešiť ich vzájomnú spoluprácu. Prenos faktúr medzi našim systémom a stávajúcim účtovníckym softvérom nebudeme riešiť, pretoţe sme to nepovaţovali v momentálnej situácii a mnoţstve spracovávaných faktúr za podstatné. Aţ budúcnosť ukáţe, či túto funkčnosť bude riešiť a či to bude moţné vyriešiť, pretoţe sme neskúmali moţnosti importu externých dát do tohto softvéru. Oveľa dôleţitejším faktorom je rozhodnutie o spôsobe akým bude fungovať vyvinutý systém z technologického pohľadu. V našom prípade ide o voľbu spôsobu ukladania dát a spôsobe fungovania aplikačnej vrstvy systému. Access je definovaný ako desktopový databázový program, ale napriek tomu poskytuje moţnosti implementácie aj vo viacpouţívateľskom prostredí formou klient/server a to nehovoriac o nových moţnostiach web database, ktoré so sebou prináša verzia Nemyslíme si, ţe Access ako taký je najvhodnejším programom pre implementáciu veľkých podnikových riešení, ale pre projekt v našom rozsahu je ideálnym nástrojom. Pre naše potreby sme sa rozhodli riešiť uloţenie dát vo forme súboru na serveri. Toto rozhodnutie má svoje obmedzenia na rozdiel od ukladania dát na SQL Serveri. Konkrétne sa jedná o dátové obmedzenie veľkosti súboru na 2GB dát. V prípade, ţe dosiahneme toto obmedzenie máme moţnosť migrácie dát na SQL server. Toto riešenie si vyţaduje aj pravidelné sledovanie narastania veľkosti súboru a vytvorenie časového odhadu kedy toto obmedzenie bude dosiahnuté, aby sme dokázali zabezpečiť plynulí prechod na SQL Server a predišli tak výpadku. Naše riešenie by asi veľmi technologicky neobstálo v prípade nasadenia do silného konkurenčného prostredia viacerých pouţívateľov neustále pripojených do databázy, ale to sme ani nechceli. Všetko sme navrhovali tak, aby bolo postačujúce aktuálnemu stavu a mali zároveň moţnosť v prípade potreby upraviť systém tak, aby dokázal rásť s poţiadavkami, ktoré môţu byť v budúcnosti na neho kladené. Stav informačného systému, ktorý je priloţený k diplomovej práci je vhodný na otestovanie jeho funkčností v prípade jedného pouţívateľa s nainštalovaným Accessom. Pri nasadení do produkcie je ale nutné, aby došlo k rozdeleniu jedného súboru na dva: dátový a aplikačný, čím v podstate vytvoríme jednoduchú aplikáciu na báze klient/server. Hlavní výhodou tohoto rezdělení je databáze oproti jednoduchému sdílení jedné desktopové databáze je to, ţe aplikace potřebuje získat ze sítě pouze data z tabulek. Kaţdý 74

77 uţivatel bude mít lokální kopii dotazů, formulářů, sestav, maker a modulů. Takto bude moci Access běţící na pracovní stanici tyto části z lokálního disku rychle načíst a poskytnout aplikaci. (Viescas & Conrad, 2008, str. 1170) K rozdeleniu databázy môţeme vyuţiť funkciu Database Splitter (v českej verzii programu Rozdělit databázi ). Otvorí sa sprievodca, ktorý nás prevedie procesom rozdelenia desktopovej databázy na dátovú a aplikačnú časť. Průvodce vyexportuje všechny tabulky do nové čistě datové databáze, smaţe tyto tabulky v původní databázi a v téţe databázi vztvoří propojení k přesunutým tabulkám. (Viescas & Conrad, 2008, str. 1172). Vytvorený systém nie je moţné spúšťať bez toho, aby na danom počítači nebol nainštalovaný Access, čo môţe predstavovať zvýšené náklady na obstaranie systému. Nie kaţdý pouţívateľ ale potrebuje funkcie, ktoré sú poskytované prostredníctvom spúšťania aplikácie v prostredí Access. Chceme upozorniť aj na variantu kedy je moţné spúšťať databázové aplikácie Access aj bez jeho prítomnosti na počítači tzv. runtime mód. V tomto prípade, ale pouţívateľovi nebudú poskytnuté všetky moţnosti, ktoré mu poskytuje plnohodnotný reţim. Príklad aplikácie spustenej v tomto reţime je znázornený v prílohe E. Z pohľadu pouţívateľa sa jedná o (Viescas & Conrad, 2008, s. 1177): - nedá sa pouţiť navigačná tabla - pouţívateľ nemá moţnosť zadávať vlastné dotazy a otvárať tabuľky - nie je moţné vyuţiť panel nástrojov programu Access a funkcie musia byť implementované priamo vo formulároch Z programátorského hľadiska musí tieţ dôjsť k výrazným zmenám aplikácie. Nakoľko nie je moţné vyuţiť navigačnú tablu, musí byť navigácia v aplikácii urobená prostredníctvom formulárov. Zvýšený dôraz musíme klásť aj na ošetrovanie a odchytávanie chýb aplikácie, pretoţe kaţdá chyba končí ukončením aplikácie (tamţe). 5.8 Údrţba O kaţdý informačný systém je potrebná sa starať aby bolo moţné zabezpečiť jeho bezproblémový chod. Musíme vykonávať pravidelne zálohy databázy, aby sme v prípade poruchy diskového zariadenia neprišli o údaje a optimalizovať spôsob uloţenia dát v databáze, aby nedochádzalo k degradácii výkonu spracovávania dotazov s narastajúcim objemom dát. Zálohu databázy, v našom prípade, uskutočníme prekopírovaním dátového 75

78 súboru na iné zariadenie, ktoré bezpečne uloţíme. Musíme zabezpečiť, aby k databáze nebol pripojení ţiaden pouţívateľ. Ideálny čas pre robenie zálohy je mimo produkčného času, spravidla sa tak deje v noci. Tento proces je moţné samozrejme automatizovať a existuje plno nástrojov i voľne dostupných, ktoré nám túto sluţbu dokáţu poskytnúť aj s pokročilými nastaveniami. Pravidelná údrţba spočíva v spúšťaní funkcie Compact & Repair Database. Pri spustení tejto funkcie dochádza spravidla k zmenšeniu dátového súboru, pretoţe dochádza k (Microsoft Corporation, 2010): - mazaniu dočasných a skrytých objektov, ktoré sa Access pri svojej činnosti vytvára a nie vţdy dôjde k ich vymazaniu - pokiaľ dochádza k mazaniu objektov a dát ostáva uvoľnené miesto na disku vyhradené stále databáze. V tomto prípade sa nevyuţité miesto uvoľní pre systém. Pri tejto funkcii nedochádza k zmenšeniu databázové súboru kompresiou dát, len sa uvoľní nevyuţívaný priestor na disku. 76

79 6 Záver Nasadením systému do produkcie nič nekončí. Pokiaľ má byť tento systém prínosom, musíme klásť jeho údrţbe a technologickým zmenám rovnakú pozornosť, ako ktorémukoľvek inému výrobnému prostriedku, na ktorom závisí chod spoločnosti. Softvérové vybavenie spoločnosti nemôţe byť posudzované oddelene od ostatných výrobných prostriedkov niečo, čo stojí mimo. Preto navrhujeme chápanie softvérového vybavenia ako jedného elementu z výrobných prostriedkov, rovnocenným k strojom a zariadeniam. Hoci práve jeho nehmotná podstata zohráva hlavnú úlohu v jeho oddelenom posudzovaní. K inováciám navrhujeme pristupovať na základe reálnej potreby vyplývajúcej zo zmeny vo výrobných procesoch a meniť len to, čo je naozaj nevyhnutné a priamo súvisí so zmenami v riadení a organizovaní spoločnosti. Inak by sa jednalo o plytvanie finančných a výrobných prostriedkov. Prehnané zavádzanie systému bez dôkladnej analýzy môţe dospieť k záveru, ţe pracovníci s ním pracujúci sa stanú jeho otrokmi. Teda namiesto získania času zrýchlením procesov, procesy spomalíme. Je určite dôleţité vedieť sledovať procesy v organizácií, ale treba si uvedomiť, ţe informácie o nich sa musia do systému zadať a nie vţdy sa to dá uskutočniť automatizovane. Prílišná detailnosť, teda sledovanie veľkého mnoţstva, často aj zbytočných atribútov zamestnáva pracovníkov. Pri hľadaní slabých miest v procesoch treba informačný systém zaradiť do skúmaných oblastí, môţno práve on je prostriedkom zlepšenia alebo príčinou chýb. Informačné systémy spravidla opisujú modelujú procesy v organizácii, dovoľujú sledovanie ich stavu na základe vstupných údajov. Čo ak, ale tento model nie je navrhnutý správne? Práve v tomto vidíme dôleţitosť posudzovania IS ako jedného z výrobných prostriedkov a neseparovať ho zo skúmanej mnoţiny moţných príčin. 77

80 VÝVOJ A IMPLEMENTÁCIA INFORMAČNÉHO SYSTÉMU V KONKRÉTNEJ ORGANIZÁCII Ja, Branislav Helcz, týmto prehlasujem, ţe som jediným a výlučným autorom tohto diela, a ţe všetky podporné zdroje iných autorov sú v diele označené. Zároveň oprávňujem kniţnicu Vysokej školy manaţmentu v Trenčíne, aby dielo Vývoj a implementácia informačného systému v konkrétnej organizácii zaarchivovala a sprístupnila v tlačenej forme na prezenčné štúdium v oboch pobočkách. Pre digitálnu formu diela udeľujem súhlas s publikovaním na internete neudeľujem súhlas s publikovaním na internete (podpis) (dátum) 78

81 Zoznam obrázkov Obrázok 3.1 Sekvenčný fázový model (Zdroj: Sokolowsky, 2002) Obrázok 4.1 Ţivotný cyklus: Proces implementácie informačného systému Obrázok 4.2 Príklad diagramu prípadu pouţitia Obrázok 5.1 Pohľad navrhovaného systému na činnosť spoločnosti Obrázok 5.2 Oblasti systému Obrázok 5.3 Use Case Diagram: Nastavenie systému Obrázok 5.4 Use Case Diagram: Evidencia komunikácie Obrázok 5.5 Use Case Diagram: Riadenie úloh Obrázok 5.6 Use Case Diagram: Evidencia zákazníkov Obrázok 5.7 Use Case Diagram: Evidencia dodávateľov Obrázok 5.8 Use Case Diagram: Evidencia tovarov Obrázok 5.9 Use Case Diagram: Fakturácia Obrázok 5.10 Use Case Diagram: Riadenie projektov Obrázok 5.11 Activity Diagram: Riešenie úlohy Obrázok 5.12 Activity Diagram: Faktúrácia Obrázok 5.13 Activity Daigram: Komunikácia Obrázok 5.14 Logický dátový model IS Obrázok 5.15 Mapovanie entity zákazník a jej atribútov do tabuľky Obrázok 5.16 Mapovanie entity dodávateľ a jej atribútov do tabuľky Obrázok 5.17 Mapovanie entity kontakt a jej atribútov do tabuľky Obrázok 5.18 Mapovanie entity pouţívateľ a jej atribútov do tabuľky Obrázok 5.19 Mapovanie entity úloha a jej atribútov do tabuľky Obrázok 5.20 Mapovanie entity projekt a jej atribútov do tabuľky Obrázok 5.21 Mapovanie entity faktúra a jej atribútov do tabuľky Obrázok 5.22 Mapovanie entity riadok faktúry a jej atribútov do tabuľky Obrázok 5.23 Mapovanie entity komunikácia a jej atribútov do tabuľky Obrázok 5.24 Mapovanie entity tovar a jej atribútov do tabuľky Obrázok 5.25 Mapovanie entity zákazkový tovar a jej atribútov do tabuľky Obrázok 5.26 Mapovanie entity činnosť a jej atribútov do tabuľky Obrázok 5.27 Mapovanie entity relácia kontaktu a jej atribútov do tabuľky Obrázok 5.28 Stavový diagram: Riešenie úlohy Obrázok 5.29 Stavový diagram: Fakturácia

82 Obrázok 5.30 Grafické rozhranie IS

83 Zoznam tabuliek Tabuľka 4-1 Poţiadavky podľa Wiegersa Tabuľka 4-2 Šablóna pre zápis scenárov Tabuľka 5-1 Logický model: entita zákazník Tabuľka 5-2 Logický model: entita dodávateľ Tabuľka 5-3 Logický model: entita kontakt Tabuľka 5-4 Logický model: entita pouţívateľ Tabuľka 5-5 Logický model: entita úloha Tabuľka 5-6 Logický model: entita projekt Tabuľka 5-7 Logický model: entita faktúra Tabuľka 5-8 Logický model: entita riadok faktúry Tabuľka 5-9 Logický model: entita komunikácia Tabuľka 5-10 Logický model: entita tovar Tabuľka 5-11 Logický model: entita zákazkový tovar Tabuľka 5-12 Logický model: entita činnosť Tabuľka 5-13 Logický model: entita relácia kontaktu Tabuľka 5-14 Tabuľka tblkrajina Tabuľka 5-15 Tabuľka tblmernajednotka Tabuľka 5-16 Tabuľka tblpsc Tabuľka 5-17 Tabuľka tblset Tabuľka 5-18 Tabuľka tblspolocnost Tabuľka 5-19 Tabuľka tblsposobkomunikacie

84 Zoznam bibliografických odkazov Arlow, J., & Neustadt, I. (2007). UML2 a unifikovaný proces vývoje aplikací (2. vyd.). Brno: Computer Press,a.s. Basl, J., & Blaţíček, R. (2008). Podnikové informační systémy (2. vyd.). Praha: Grada Publishing,a.s. Buchalcevová, A. (2005). Metodiky vývoje a údržby informačních systémů. Praha: Grada Publishing, a.s. erpwire.com. (dátum neznámy). ERPwire.com. Retrieved február 2, 2009, from ERP Implementation Guideline: Held, B. (2006). Access VBA - Velká kniha řešení (1. vyd.). Brno: Computer Press,a.s. Hernandez, M. J. (2006). Návrh databází (1. vyd.). (J. Bouda, Prekl.) Praha: Grada Publishing, a.s. Hobart, J. (1. október 1995). Classic System Solutions, INC. Cit. 4. február Dostupné na Internete: Principles of Good GUI Design: Kanisová, H., & Müller, M. (2006). UML srozumitelně (2. vyd.). Brno: Computer Press,a.s. Krug, S. (2006). Web design: Nenuťte uživatele přemýšlet (2. vyd.). Brno: Computer Press, a.s. Microsoft. (4. február 2010). Changes in Access Cit. 1. marec Dostupné na Internete: TechNet: Microsoft Corporation. (2010). Help prevent and correct database file problems by using Compact and Repair. Cit. 7. marec Dostupné na Internete: Microsoft Office Online: Sokolowsky, P. (2002). Informační požadavky moderního podniku. Praha: Univerzita Karlova v Praze - Nakladatelství Karolinum. Sommerville, I., & Sawyer, P. (2008). In K. E. Wiegers, Požadavky na software (s. 29). Brno: Computer Press, a.s. 82

85 Stormware software development. (2007). Ekonomický a informačný systém POHODA. Cit február 11. Dostupné na Internete: Stormware software development: TRILAB, s.r.o. (január 2009). O firme. Cit. 25. január Dostupné na Internete: Trilab: Umbrello UML Modeller. (dátum neznámy). Main. Cit. 5. január Dostupné na Internete: Umbrello UML Modeler: Viescas, J., & Conrad, J. (2008). Mistrovství v Microsoft Office Access 2007 (1. vyd.). Brno: Computer Press,a.s. Wiegers, K. E. (2008). Požadavky na software (1. vyd.). Brno: Computer Press, a.s. 83

86 Prílohy 1. PRÍLOHA A: Relačný model informačného systému 2. PRÍLOHA B: Prototyp informačného systému na CD 3. PRÍLOHA C: Formulár typu detail: Úloha - detail 4. PRÍLOHA D: Formulár typu zoznam: Zoznam úloh 5. PRÍLOHA E: Runtime mód 84

87 PRÍLOHA A: Relačný model informačného systému 85

88 PRÍLOHA B: Prototyp informačného systému na CD 86

89 PRÍLOHA C: Formulár typu detail: Úloha - detail 87

90 PRÍLOHA D: Formulár typu zoznam: Zoznam úloh 88

91 PRÍLOHA E: Runtime mód 89