Mendelova univerzita v Brně Provozně ekonomická fakulta Ústav informatiky Softwarová podpora pro certifikaci GLOBALG.A.P.

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Ústav informatiky Softwarová podpora pro certifikaci GLOBALG.A.P. Diplomová práce Vedoucí práce: Ing. František Dařena, Ph.D. Vypracoval: Bc. Vítězslav Baroš Brno 2010

2 PODĚKOVÁNÍ Na tomto místě bych chtěl poděkovat především vedoucímu mé diplomové práce Ing. Františku Dařenovi, PhD. za cenné rady a připomínky k této práci. Dále bych chtěl poděkovat paní Ing. Kateřině Růžičkové, v té době manažerce certifikace GlobalG.A.P. u České společnosti pro jakost, o.s., za cenné rady a podněty ohledně certifikace GlobalG.A.P.. A v neposlední řadě také mé rodině a partnerce za dlouhodobou podporu.

3 PROHLÁŠENÍ Prohlašuji, že jsem tuto diplomovou práci na téma Softwarová podpora pro certifikaci GLOBALG.A.P. vypracoval samostatně a použil jen pramenů, které cituji a uvádím v přiloženém seznamu literatury. V Brně dne. Podpis

4 Abstrakt Baroš V. Softwarová podpora pro certifikaci GlobalG.A.P.. Diplomová práce. Brno 2010 Diplomová práce se zabývá návrhem a implementací softwarové podpory pro certifikaci celosvětově uznávaného standardu GlobalG.A.P. Normy tohoto standardu se věnují správné zemědělské výrobní praxi. K návrhu software je použito objektového jazyka UML 2.0 a Case nástroje Enterprice architekt. K implementaci je použit programovací jazyk Java ve spojení s databázi MySQL. Klíčová slova Objektově orientovaný návrh, UML 2.0, CASE nástroje, Java, GlobalG.A.P., certifikace Abstract Baroš V. Software support for the certification GlobalG.A.P.. Diploma thesis. Brno Diploma thesis deals with design and implementation of software support for certification worldwide accepted standard GlobalG.A.P.. Standards of this standard are dedicated to good agricultural practices. The design is made by using object-oriented language UML 2.0 and CASE tools Enterprice Architect. The implementation uses the Java programming language in conjunction with a MySQL database. Key words Object-oriented systém design, UML 2.0, CASE tools, Java, GlobalG.A.P., Certification

5 Obsah SEZNAM OBRÁZKŮ ÚVOD CÍL PRÁCE TEORETICKÁ VÝCHODISKA PRÁCE Certifikace Certifikace zemědělství a potravinářství GlobalG.A.P Historie standartu GLOBALG.A.P Principy standardu GLOBALG.A.P Struktura standardu Základní dokumenty standardu Hodnocení požadavků Certifikace Národní technická pracovní skupina GLOBALG.A.P. v ČR Používané softwarové nástroje při certifikaci METODIKA ŘEŠENÍ Metodika tvorby specifikace požadavků na software Využité metody tvorby návrhu UML Datový model Využité programové vybavení Enterprise Architekt Programovací jazyk Java Netbeans IDE SQL MYSQL VÝSLEDKY Specifikace požadavků na software Účel softwaru Rozsah software Definice, zkratky a akronymy Profil uživatele Nefunkční požadavky Funkční požadavky ~ 1 ~

6 5.2 Analýza a návrh aplikace Diagram případů užití Diagram tříd Stavový Diagram Diagramy aktivit Sekvenční diagram Diagram nasazení Datový model Výsledná implementace DISKUZE ZÁVĚR LITERATURA PŘÍLOHY ~ 2 ~

7 Seznam obrázků Obr. č. 1: Graf počtu vydaných certifikátů v ČR Obr. č. 2: Porovnání procent podniků, jež vlastní certifikát GLOBALG.A.P. 20 Obr. č. 3: Poměr certifikačních společností působících na českém trhu Obr. č. 4: Aktér Obr. č. 5:Případ užití Obr. č. 6 Diagram případu užití Obr.č. 7:Diagram tříd Obr. č. 8: Stavový diagram objektu kontrola Obr. č. 9: Diagram aktivity Dokončit kontrolu Obr. č. 10:Diagram aktivity Zobrazit klienta Obr. č. 11: Diagram aktivity Pracovat na kontrole Obr. č. 12:Diagram přidání uživatele Obr. č. 13:Sekvenční diagram upravit data uživatele Obr. č. 14: Sekvenční diagram založení kontroly Obr. č. 15: Diagram nasazení Obr. č. 16: Datový model Obr. č. 17: Seznam uživatelů a detail vybraného uživatele Obr. č. 18: Detail klienta Obr. č. 19: Info ke kontrole Obr. č. 20: Otevřený checklist ~ 3 ~

8 1 Úvod 1 Úvod Stále rostoucí výměna zboží ve 20. Století a postupné globalizování světa vyvolává nutnost zavést sjednocující normy ve všech oblastech lidské činnosti, především v oblastech, jež jsou předmětem výměny zboží mezi různými regiony s různým historickým vývojem. A proto se postupně vyvinuly standardy jakosti ve všech oblastech lidské činnosti, aby byla jednoduše zjistitelná kvalita zboží a služeb. Ověřování plnění parametrů, jež jsou předmětem normování, je časově, materiálně a technicky náročný proces, při kterém by měla být jednoznačně prokázána shoda s předepsanými normami. K urychlení těchto povinných kontrol využívají organizace mnohé zlepšující postupy či nástroje ať povinné pro danou kontrolu, normu či certifikát, anebo časem prověřené postupy či prvky jednotlivými certifikujícími organizacemi zrychlující tento proces. Mezi tyto zrychlující prvky procesu certifikace se stále více začínají využívat informační technologie, zejména v posledních deseti letech. Nejdříve se používaly obecné textové editory k urychlení práce s textem, které dokázaly snížit spotřebu kancelářských potřeb na tvorbu dokumentů. Ovšem se stále vyšší náročnosti struktury a složitostí jednotlivých standardů a nároku na produktivitu práce vyvstává rostoucí potřeba sofistikovanějších nástrojů pro jednotlivé druhy norem. Vznikají tak stále nová a dokonalejší řešení softwarových nástrojů pro práci s nimi a následným udělováním certifikátů. A právě vytvořením takovéhoto specializovaného softwarového nástroje pro certifikaci celosvětově uznávaného zemědělského standardu GlobalG.A.P. se zabývá tato práce. ~ 4 ~

9 2 Cíl práce 2 Cíl práce Cílem této diplomové práce je navrhnout a zrealizovat softwarovou podporu k certifikaci standardu GlobalG.A.P. pro organizace provádějící kontrolu shody plnění kontrolních bodů předepsaných organizaci GlobalG.A.P u žadatele o certifikaci dle tohoto standardu, jež je nutným předpokladem pro udělení požadovaného certifikátu. Tento podpůrný software by měl být schopen přispět ke zvýšení produktivity práce a tím snížení nákladů a vylepšení ekonomických výsledků organizace provádějící certifikaci dle standardu GlobalG.A.P. Pro úspěšné splnění vytýčeného cíle této práce je nutné učinit několik kroků. Nejprve je nutné detailně nastudovat obecně problematiku certifikace, standardu GlobalG.A.P. a jeho postavení v České republice pro detailní pochopení principu standardu, přičemž bude i provedeno zhodnocení dosavadních softwarových nástrojů používaných k podpoře certifikace tohoto standardu. Tyto činnosti budou provedeny v kapitole teoretická východiska práce. Před zahájením práce na návrhu software bude v kapitole metodika řešení představena využitá metodika návrhu aplikace a použité programové vybavení při tvorbě návrhu a implementaci software. Samotná práce na vývoji aplikace bude zahájena nejdříve definováním požadavků na software, jež by měl ve výsledku splňovat. Podle sestavených požadavků a postupů navržených v metodice práce bude navržená celá aplikace. Po dokončení návrhu bude provedená implementace výsledného řešení, které bude představeno a popsáno především z uživatelského hlediska. Na závěr bude provedena diskuze, kde se zhodnotí výsledné řešení, proberou se nedostatky a možné další funkčnosti k doplnění. ~ 5 ~

10 3 Teoretická východiska práce 3 Teoretická východiska práce 3.1 Certifikace Certifikát je slovo latinského původu a znamená potvrzení, vysvědčení o určitých skutečnostech např. zkoušce, původu zboží, kvalifikaci či existenci závazků vůči třetí osobě. Tento termín dostal zejména s rozvojem průmyslové výroby zvláštní význam a je používán především tam, kde se vyskytuje možnost vzniku určitého nebezpečí nebo ohrožení zdraví. V tomto směru certifikace byla a je vždy účinným nástrojem těchto snah.[1] Certifikace je činnost nezávislého autorizovaného či akreditovaného orgánu, při které se vydáním certifikátu nebo certifikační značkou stvrzuje shoda vlastností výrobku, služby, postupu nebo činností tím souvisejících se stanovenou technickou normou nebo jiným určeným technickým normativním předpisem.[3] Smyslem certifikace je ověření shody certifikovaného objektu s příslušnými předpisy či normami tak, aby výsledky tohoto ověření mohly být uznané nejen tam, kde se ověření provedlo, ale i v dalších zemích, které uznaly principy certifikace.[4] Původně byla certifikace zaměřená jen na výrobek a jejich vlastnosti, pro které bylo u jakýchkoliv příčin potřebné vydat potvrzení o splnění požadovaných nebo předepsaných kriterií. Aby bylo možno takovéto potvrzení vydat, bylo třeba výrobek a jeho vlastnosti vyzkoušet a ověřit. Potřeba zkoušet výrobky si vyžádala určitou koordinaci a sjednocení postupů a tak vznikaly zkušební systémy na národní i mezinárodní úrovni. Pozornost věnována pouze výrobku se z pohledu současného vývoje výrobních a tržních vztahů jeví jako nedostatečná. Proto je věnována pozornost komplexnímu zajišťování jakosti jako součástí řízení celých organizací. [1] Cílem pro zavedení certifikačních systému bylo na mezinárodním poli především vytvořit předpoklady pro vznik vzájemné důvěry jako nezpochybnitelného základu vzájemného uznání zkoušek a zjištění. Na vnitrostátním poli zase zabezpečit veřejný zájem zabezpečení ochrany spotřebitele a jakosti na základě povinné certifikace parametrů spadajících do regulované oblasti a zajistit zprůhlednění a zjednodušení prokazování shody parametrů s právními předpisy, technickými normami a specifikacemi. Mezi podnikatelskou sférou je cílem zavedení systémů certifikací získat obchodní výhodu pro dodávané výrobky a služby.[6] V současné době se certifikace rozděluje na dva základní druhy: Certifikaci povinnou Certifikaci dobrovolnou Povinná certifikace má oporu v zákonech a jiných legislativních opatřeních, které ukládají povinnost a tedy i požadavek na certifikaci. Dobrovolná certifikace je ~ 6 ~

11 3 Teoretická východiska práce založena na smluvním vztahu mezi příslušným orgánem nebo organizací a zájemcem o certifikaci, tedy dobrovolném závazku plnit smluvené podmínky plynoucí z certifikace. V následujícím výkladu se budeme převážně věnovat certifikaci dobrovolné.[1] Cíle certifikace pro organizaci se dají rozdělit na externí a interní.[4] Externí cíle jsou především tyto: důkaz splnění požadavků kvality; transparentnost pro zákazníky; podpoření a zjednodušení obchodních procesů; budování účinnějších dodavatelsko odběratelských vztahů; upevnění a zlepšení image organizace; rozšíření potenciálního okruhu zákazníků; zlepšení konkurenčního postavení. Mezi interní cíle lze považovat tyto: optimalizace chodu organizace; dokumentace obchodních procesů; růst produktivity; motivace zaměstnanců; snižování nákladů; odstraňování slabých stránek organizace; rychlejší zaškolení nových zaměstnanců. Certifikace má pro organizaci i značný bezprostřední ekonomický význam: usnadňuje vstup na světový trh a zejména na tvořící se single market; umožňuje vyloučení duplicitního hodnocení v zemi vývozce a dovozce; je podkladem pro poskytnutí úvěrů a pojistných smluv; je zárukou pro kooperační partnery, že vadné dodávky nebudou komplikovat výrobu či poškozovat dobré jméno výrobce; pro výrobce je významná i v souvislosti s odpovědností za škody způsobené výrobkem. Ovšem značnou nevýhodou a často odrazujícím faktorem certifikace výroby či služeb je poměrně rozsáhlá byrokratizace a finanční náročnost. Navíc pouhý certifikát nezaručí firmě ekonomickou prosperitu. K tomu, aby se výše uvedené výhody opravdu uskutečnily, musí se firma s dodržováním kvality ztotožnit, přijmout to jako svou filosofii výroby a uplatňovat ji v každodenní praxi. ~ 7 ~

12 3 Teoretická východiska práce 3.2 Certifikace zemědělství a potravinářství Světový obchod vyžaduje stále větší záruky standardizovaného postupu tvorby zemědělské produkce, při kterém by byla zajištěna bezpečnost produktu, zahrnující samozřejmě i hygienickou nezávadnost a kvalitu. V dnešní době je stále více kladen důraz na podmínky, při kterých takový produkt vznikal a ne jen na konečnou podobu produktu. A tak vnikají ucelené systémy norem řízení jakosti po celou dobu výroby. Existuje mnoho certifikovatelných norem zabývajících se vznikem potravin. Skoro každý stát měl dříve vlastní normy kvality potravin, pomocí nichž dbal na kvalitu potravin na svém území, a tím i na zdraví občanů je konzumující. Postupně začaly státní normy nahrazovat soukromé, jež začaly zavádět obchodní řetězce pro své dodavatele především z marketingových důvodů. Některé standardy postupně ztrácejí důležitost a zanikají, jiné opět vznikají a prosazují se do popředí. V současnosti jsou podle časopisu Kvalita potravin [11] nejpoužívanějšími normami na našem území zabývající se kvalitou potravin a zemědělskou praxí tyto: ISO 9001 Obecná norma využívající se pro nastavení interních pravidel řízení organizace a zajištění dosahované kvality produktů ve všech odvětvích. HACCP CZ Česká norma na principu HACCP (Hazard Analysis and Critical Control Points, Certifikace systému kritických bodů) podle českého normativního dokumentu z Věštníku Ministerstva zemědělství ČR 1/2001. V současnosti již ztrácí na významu. Největším přínosem byla při vstupu do Evropské unie, kdy připravovala na zavedení evropských právních norem. ISO je norma určená pro certifikování systému řízení bezpečnosti potravin. Je založena na principech HACCP (Hazard Analysis and Critical Control Points) a je aplikovatelná pro všechny články potravinového řetězce od zemědělské prvovýroby, přes výrobce potravin, distributory a až po výrobce obalů a provozovatele veřejného stravování. BRC - Norma BRC (British Retail Consortium) je jedna z GFSI (Global Food Safety Initiative) schválených norem pro výrobce potravin a je celosvětově velmi rozšířená. Je standardně požadována při exportu potravin do Velké Británie a mnoha dalších území. IFS IFS (International Food Standard) je další z GFSI (Global Food Safety Initiative) schválených norem pro výrobce potravin a je také celosvětově rozšířená, v zásadě paralelní s normou BRC, ale spíše ~ 8 ~

13 3 Teoretická východiska práce užívaná pro kontinentální Evropu a i v České republice rozšířenější než BRC. GLOBALG.A.P. Je jedinou celosvětově uznávanou integrovanou normou zabývající se detailně správnou zemědělskou prvovýrobní praxí všech produktů až do odchodu produkce z farmy. V České republice je to poměrně mladá norma a prozatím nepříliš rozšířená oproti zahraničí a proto se u něj předpokládá vysoký potenciál růstu. [11] V české republice jsou jediným specializovaným alternativním standardem GLOBALG.A.P. správné zemědělské praxe prvovýroby pouze normy IFS a SISPO, které jsou ovšem omezeny jen na zeleninu a ovoce: IPZ Integrovaný systém produkce zeleniny (IPZ) je norma produkce zeleniny vysoké kvality, která dává přednost ekologicky přijatelným metodám a minimalizuje nežádoucí vstupy agrochemikálií s nežádoucími vedlejšími účinky. Řadí se mezi konvenční a organickou produkci plodin, prosazuje snížení rizika přehnojování půdy a racionálnější využívání živin.[13] SISPO - Směrnice pro integrované systémy pěstování ovoce (SISPO) je ekonomická produkce ovoce vysoké kvality při uplatnění ekologicky přijatelných metod pěstování a minimalizaci nežádoucích vedlejších účinků agrochemikálií při jejich používání. Klade důraz na zvýšení ochrany životního prostředí a lidského zdraví.[14] 3.3 GlobalG.A.P. GLOBALG.A.P. je soukromý projekt, jehož vlastníkem je společnost FoodPLUS GmbH, což je dceřiná společnost Evropského obchodního institutu v Kolíně nad Rýnem. Standard stanovuje dobrovolné standardy pro certifikaci zemědělských produktů po celém světě. Cílem je vytvořit jeden standard pro správnou zemědělskou praxi (GAP) s různými aplikacemi produktu schopné pokrýt celou světovou produkci zemědělství. Standard v sobě zahrnuje každoroční kontroly výrobců a další neohlášené inspekce a je proto výborným ukazatelem skutečného průběžného stavu. [7] Členy GLOBALG.A.P. jsou především maloobchodníci a podnikatele stravovacích služeb, výrobců či dodavatelů a přidružených členů ze vstupní strany zemědělství. Jejich dobrovolné členství přispívá k prosazování zásad správné zemědělské praxe po celém světě. GLOBALG.A.P. je pre-farm-gate standard, což znamená, že certifikát pokrývá proces certifikovaného výrobku od zemědělských vstupů jako krmivo nebo sazenice přes všechny zemědělské činnosti, dokud výrobek neopustí farmu. [7] ~ 9 ~

14 3 Teoretická východiska práce Je to také především business-to-business certifikát, což znamená, že je určen primárně pro vztahy mezi obchodníky a proto není přímo viditelný pro spotřebitele, ale především ukazatel kvality pro obchodní partnery. [7] GLOBALGAP mohou aplikovat podniky bez ohledu na jejich velikost a pro každého má svoje opodstatnění. V menších podnicích bývá často největším přínosem již jen zavedení naplnění zákonných požadavků a vyhnutí se tak případným sankcím za jejich porušení či nedodržení. U rostoucích podniků či družstev pak bývá největším přínosem celkové zefektivnění řízení podniku či zavedení systému řízení kvality.[2] Historie standartu GLOBALG.A.P. Standard GLOBALG.A.P. byl zahájen pod názvem EUREPGAP v roce 1997 jako iniciativa prodejců patřících do Euro-Retailer Produce Working Group (EUREP). Britští maloobchodníci ve spojení se supermarkety v kontinentální Evropě byli hnací silou zavedení standardu. Reagovali na rostoucí obavy spotřebitelů týkající se bezpečnosti výrobků, ochrany životního prostředí a pracovních podmínek a rozhodli se sjednotit své často velmi odlišné standardy. [7] Vypracování společných standardů certifikace bylo také v zájmu výrobců. Ti se smluvními vztahy s několika prodejci museli podstupovat několik auditů podle různých kritérií ročně, což bylo zbytečné a velmi neefektivní. V tomto smyslu EUREP začal pracovat na harmonizování norem a postupu pro vývoj správné zemědělské praxe (Good Agricultural Practices, GAP) v konvenčním zemědělství, včetně zdůrazněni významu integrovaného řízení výroby a zodpovědný přístup k sociální problematice zemědělství. [7] Během následujících deseti let stále více výrobců a prodejců po celém světě se připojilo k projektu sladit zemědělské standardy správné zemědělské praxe, tak jak to odpovídá rýsujícímu se obrazu globalizovaného obchodu. EUREPGAP začal získávat globální význam, již více než sto tisíc provedených auditů po celém světě, a začal se jevit jako přední mezinárodní standard správné zemědělské praxe. Protože standard dostával stále více globální význam, byl to přirozený vývoj, který vedl k tomu, že se rada EUREPGAPu rozhodla pro přejmenování standardu na lépe vystihující název GLOBALG.A.P.. Rozhodnutí bylo oznámeno v září 2007 na 8. světové konferenci v Bangkoku.[7] Principy standardu GLOBALG.A.P. Základy standardu GLOBALG.A.P. jsou založeny na následujících čtyřech principech: [5 ] 1) Bezpečnost potravin je založena na kritériích bezpečnosti potravin vycházejících z uplatňování obecných zásad systému kritických bodů HACCP. ~ 10 ~

15 3 Teoretická východiska práce 2) Ochrana životního prostředí je založeno na správné zemědělské praxi pro ochranu životního prostředí, která minimalizuje negativní dopady zemědělské produkce na životní prostředí. 3) Bezpečnost práce a péče o pracovníky stanovuje celkovou úroveň kritérií pro bezpečnost práce a ochranu zdraví v zemědělských podnicích, a také povědomí a odpovědnost v sociálních otázkách. Nenahrazuje však důkladné audity společenské odpovědnosti organizací. 4) Pohoda zvířat (welfare) se zohledňuje tam, kde se chovají zvířata, a stanovuje celkovou úroveň kritérií pro pohodu zvířat na farmách. [5 ] Standard se může integrovat s dalšími systémy řízení bezpečnosti a kvality a tvoří základ, na němž je možné dále stavět. V jednotlivých modulech, které se týkají správné zemědělské praxe např. pro pěstování ovoce a zeleniny nacházíme požadavky ve vztahu k systémům již v praxi zavedeným standardům jako IPZ (integrovaná produkce zeleniny) nebo SISPO (Směrnice pro integrované systémy pěstování ovoce). Oproti těmto ryze prvovýrobním zemědělským systémům, požadavky standardu GLOBALG.A.P. následují i v dalších krocích výroby jako je sklizeň, hygiena sklizně, manipulace s produkcí. Vše směřuje k zabezpečení zdravotní nezávadnosti celého řetězce produkce, čímž jsou plněny požadavky nařízení EK č. 178/2002 a č. 852/2004. [2] Zavedení standardu je také významným krokem pro splnění podmínek hospodaření v souladu s principy Cross Compliance. Cross-Compliance vyjadřují provázanost ohleduplného a šetrného hospodaření zemědělců vůči životnímu prostředí a zdraví. Zahrnují zákonné požadavky na hospodaření (statutory management requirements = SMR) a pravidla dobrých zemědělských a environmentálních podmínek (good agricultural and environmental conditions = GAEC) předepsané Evropskou unií. [2] Cross-Compliance se týkají především evropské předpisy Nařízení Rady (ES) č. 1782/2003, Nařízení Komise (ES) č. 796/2004 a Nařízení Rady (ES) č. 21/2004 v platném znění. Jednotlivé předpisy a zákonné požadavky jsou kontrolovány příslušnými kontrolními orgány České republiky.[2] Standard prochází pravidelnými 3-letými celkovými revizemi obsahu, kdy jsou zohledňovány nejnovější poznatky a trendy v zemědělské prvovýrobě a během cyklů i menšími úpravami. Zatím poslední verze standardu 3.0 Integrované zemědělské podniky GLOBALG.A.P. nabyla platnosti 1. března 2009 a jejím cílem je respektovat vývoj v zemědělství, jako primárním potravinářském sektoru, a více podpořit myšlenku trvale udržitelného hospodaření. V úvahu se proto bere životní prostředí a jeho případné poškozování, welfare zvířat, a také bezpečnost práce a pracovní podmínky ~ 11 ~

16 3 Teoretická východiska práce zemědělských pracovníků. [7, 2] V roce 2011 se předpokládá podle harmonogramu vydání nové verze normy Struktura standardu Jde o jednoduchý integrovaný standard založený na aplikaci normativních modulů podle jednotlivých skupin produktů. Základní rozdělení modulů je na rostlinnou výrobu, živočišnou výrobu a akvakulturu a ty se dále dělí podle zaměření, viz Tab. č. 1. Integrované zemědělské podniky (IFA) Základní požadavky pro všechny zemědělské podniky (AF) Základní požadavky pro rostlinnou výrobu Základní požadavky pro živočišnou výrobu Základní požadavky pro akvakulturu Ovoce a zelenina Skot a ovce Lososovité ryby Květiny a dřeviny Mléčný skot Krevety Polní plodiny Prasata Pangasius Zelená káva Drůbež/Krocani a krůty Tilapie Čaj Ostatní Ostatní Ostatní - - Tab. č. 1.:Struktura standardu GLOBALG.A.P. Například, chce-li zemědělec certifikovat brambory, které spadají do podoboru Ovoce a zelenina, musí splnit požadavky oboru Základní požadavky pro všechny zemědělské podniky, dále Základní požadavky pro rostlinnou výrobu a požadavky obsažené v podoboru Ovoce a zelenina. Pokud by chtěl certifikovat například kukuřici, musí podle předchozího postupu splnit stejné požadavky, ale místo podoboru Ovoce a zelenina plní podobor Polní plodiny. Obdobný model funguje u živočišné produkce a akvakultur.[2] Základní dokumenty standardu Nejzákladnější dokumenty standardu, které musí vzít zemědělec na vědomí a použít je při implementaci a aplikaci standardu, jsou: Všeobecné předpisy (General Regulation), které formulují obecná pravidla pro zacházení s normou a pro certifikaci systému; Kontrolní body a kritéria shody (Control Points and Compliance Criteria), které představují vlastní soubor požadavků standardu; Kontrolní listy (Checklists) pro jednotlivé moduly, pomocí nichž se kontrolují plnění požadavků standardu. ~ 12 ~

17 3 Teoretická východiska práce Obecné předpisy GLOBALG.A.P. Obecné předpisy GLOBALG.A.P. (General Regulation) stanovují pravidla pro provádění standardu. Tento dokument popisuje základní kroky a pokyny pro producenty a je rozdělen do následujících pěti částí: Část I - Obecné informace. Dokument obsahuje informace nezbytné pro všechny zainteresované strany, vysvětluje pojmy, popisuje proces certifikace, pravidla pro certifikaci, školení, apod. Doporučuje se, aby se producenti s touto částí seznámili, neboť i zde jsou požadavky, které musí producenti plnit. Část II - Pravidla pro certifikační orgány. Zde jsou obsaženy informace zejména pro certifikační a akreditační orgány. Část III - Certifikace výrobních skupin: Část vysvětluje pojmem výrobní skupina a uvádí, jak musí skupina fungovat. Obsahuje důležité informace pro všechny výrobní skupiny, certifikační a akreditační orgány. Část IV Benchmarking: Popisuje certifikaci podle schémat (standardů), které byly uznány jako rovnocenné ke standardu GLOBALG.A.P.. V současné době je tato varianta certifikace pro české producenty neaplikovatelná. Část V - Předpisy pro školení: Část je důležitá pro všechny členy, kteří mají zájem stát se schváleným školitelem GLOBALG.A.P Kontrolní body a kritéria shody GLOBALG.A.P. Kontrolní body a kritéria shody GLOBALG.A.P. (CPCC - Control Points and Compliance Criteria) jsou vlastní požadavky standardu. Zde jsou uvedeny v rámci jednotlivých modulů požadavky, které musí producent splnit. U každého požadavku jsou uvedena upřesnění požadavků pro jeho splnění. Dokument Kontrolní body a kritéria shody GLOBALG.A.P., který je někdy také nazýván jako checklist, neboli seznam kontrolních otázek, je rozdělen do samostatných kapitol podle výše uvedené tabulky č Kontrolní seznam Kontrolní seznam (Checklist) GLOBALG.A.P. je základním podkladem pro externí audity producenta, který musí producent nebo výrobní skupina používat pro splnění požadavků každoročního interního hodnocení. Jak je popsáno v Obecných předpisech GLOBALG.A.P., obsahují tyto checklisty kontrolní body, které musí producent či výrobní skupina splnit a jejichž plnění je prověřováno při certifikaci Hodnocení požadavků Standard GLOBALG.A.P. rozděluje požadavky do tří skupin podle významnosti, a to na požadavky označené jako Klíčové povinnosti (Major Musts), Povinnosti (Minor Musts) a Doporučení (Recommendations). ~ 13 ~

18 3 Teoretická východiska práce Na základě zjišťování reálného stavu na farmě je pak definován výsledek šetření. Možné odpovědi uváděné v checklistu jsou: ANO v případě naprosté shody s požadavkem; NE v případě, že požadavek je plněn částečně nebo není plněn vůbec; NEAPLIKOVATELNÉ (N/A) ("Not Applicable") v případě, že daný požadavek je v konkrétních podmínkách podniku irelevantní. Pokud je odpovědí ke konkrétnímu požadavku "neaplikovatelné" (N/A), musí být vždy uvedeno zdůvodnění. Odpověď N/A nemůže být uvedena u kontrolních bodů, kde je výslovně uvedeno, že tuto odpověď nelze u daného bodu použít tzn., že kontrolní bod nelze vyloučit z hodnocení. Všechny kontrolní body v checklistu musí být v rámci interní i externí inspekce prověřeny a jsou standardně aplikovatelné, není-li stanoveno jinak. Všechny klíčové povinnosti musí být okomentovány včetně doložení objektivních a ověřitelných důkazů. Také všechna neplnění kontrolních bodů musí být okomentovány včetně doložení důkazů o neplnění[2]. Může se stát, že některé požadavky jsou v souvislosti s níže uvedenými pravidly posuzovány přísněji a to zejména pokud jsou platné právní předpisy daného státu tzn. pro nás právní předpisy ČR a EU, přísnější než je definovaný požadavek GLOBALG.A.P., musí být předpisy respektovány. Shoda s legislativou je posuzována jako klíčová povinnost, a to bez ohledu na úroveň shody požadované standardem, tedy bez ohledu na to, je-li daný požadavek ve standardu označen jako povinnost nebo doporučení. Pokud neexistuje relevantní legislativa nebo nejsou-li požadavky předpisů tak přísné, představuje GLOBALG.A.P. minimální přijatelnou úroveň shody. Pro certifikaci podoboru Ovoce a zelenina platí, že jsou-li prováděny posklizňové úpravy mimo farmu v jiné balírně, jsou všechny povinnosti v rámci kapitoly posklizňová manipulace posuzovány jako klíčové. V případě, že v rámci skupiny fungují centrální místa pro nakládání s produkcí, všechny kontrolní body označené jako povinnost získávají statut klíčové povinnosti[2] Certifikace Jakýkoli producent, tj. fyzická nebo právnická osoba, která se zabývá produkcí v rámci oboru rostlinné produkce, živočišné produkce nebo akvakulturami a která má právní odpovědnost za produkty prodávané daným zemědělským subjektem může zažádat o certifikaci GLOBALG.A.P. prostřednictvím oprávněného certifikačního orgánu. Certifikovat lze jakýkoli produkt, rostlinný i živočišný, který je uveden na produkčním listě GLOBALG.A.P.. Předmětem certifikace je produkt, jedná se tedy o tzv. produktovou certifikaci. Je možné certifikovat pouze vlastní výsledný produkt. Při certifikaci se bere v úvahu celý průběh vzniku, podmínky, ošetření na poli, vlastní ~ 14 ~

19 3 Teoretická východiska práce sklizeň a posklizňové manipulace, což může zahrnovat např. třídění, mytí, zchlazení, krátkodobé i dlouhodobé skladování, posklizňové ošetření apod. [2]. Pod standardem GLOBALG.A.P. nelze certifikovat porážku a zpracování masa, balení a zpracování bez vlastní produkce, kdy je surovina jen nakupována. Certifikovat také nelze přepravu a distribuci. V těchto případech by měly navazovat jiné, vhodnější standardy jako jsou například HACCP, ISO 22000, BRC, IFS apod. Dále není možné certifikovat produkt, který je pěstován na neregistrovaném místě nebo certifikovat neregistrovaný produkt pocházející z registrovaného místa[2]. Z principu jsou 2 varianty certifikace, a to individuální a skupinová. 1. Individuální certifikace - o certifikaci GLOBALG.A.P. se uchází samostatný producent. Po obdržení certifikátu bude tento producent jeho jediným vlastníkem. 2. Skupinová certifikace - o skupinovou certifikaci GLOBALG.A.P. se uchází výrobní skupina (např. odbytové družstvo). Tato výrobní skupina bude od okamžiku certifikace držitelem certifikátu jako právnická osoba. Při této certifikaci musí být proveden také audit pro integrované zemědělské podniky (IFA), jež může provést pouze auditor. Producent smí žádat o certifikaci v rámci různých variant certifikace, ať individuální nebo skupinové pro jeden podobor, ale nesmí žádat o certifikaci jednoho produktu podle více variant certifikace. Producent nebo výrobní skupina jako objednavatel certifikace je povinen certifikovat veškerou produkci dané plodiny. V případě, že certifikovaný výrobce pěstuje např. zeleninu na třech od sebe oddělených polí, není možné certifikovat produkci např. pouze ze dvou polí. Dále je objednavatel oprávněn nechat si svoji produkci certifikovat více certifikačními společnostmi, a to za následujících podmínek: v případě, že si nechává certifikovat více než jeden produkt rámci více než jedné varianty certifikace; v případě, že je objednavatel člen více družstev, např. prodává skot pod jménem družstva A a současně drůbež pod hlavičkou družstva B; v případě, že žádá o certifikaci více oborů nebo podoborů Registrace Prvním krokem k certifikaci výroby je registrace producenta nebo výrobní skupiny. Ta probíhá za spoluúčasti vybraného certifikačního orgánu přes elektronickou databázi GLOBALG.A.P., ve které musí být zaznamenány všechny relevantní informace týkající se producentů, kteří žádají o certifikaci GLOBALG.A.P. včetně určení zvolené varianty ~ 15 ~

20 3 Teoretická východiska práce certifikace. Tyto informace organizace GLOBALG.A.P. zpracuje a přidělí registrované straně klientské číslo GLOBALG.A.P., tzv. GGN, které je používáno jako jediný identifikační údaj pro všechny činnosti v rámci GLOBALG.A.P.. Registrační informace zahrnují v prvé řadě obecné informace pro jednoznačnou identifikaci žadatele, úplnou adresu s kontakty a specifikaci modulů, které mají být zahrnuty do certifikace, o niž se žádá. Dále jsou požadované jasné označení a umístění každé obchodní značky, včetně produktů určených k certifikaci (zemědělských plodin, chovaných zvířat), pod kterými farmář nebo skupina farmářů prodává produkt, který se má certifikovat. Po žadateli je požadováno také podepsané prohlášení o závazku, že budou dodržovány požadavky stanovené v normě GLOBALG.A.P.. U modulu Ovoce a zelenina je třeba přidat prohlášení zahrnující každé vyjmutí zemědělské kultury či produktu z problematiky manipulace s plodinou. Toto prohlášení umožní, aby kontrolní body v tomto úseku označené jako Nelze N/A, tj. nelze vyloučit jako neaplikovatelný, mohly být hodnoceny jako neaplikovatelné. S tím souvisí i prohlášení o nakládání s produkty, které zahrnuje všechny registrované produkty, s uvedením, zda plodina necertifikovaná organizací GLOBALG.A.P. a také plodina certifikovaná organizací GLOBALG.A.P. vstupuje do posklizňových manipulací, není-li tato operace vyjmuta z certifikace. Dále se přidává prohlášení obsahující u každé zemědělské kultury či plodiny všechny země, v nichž farmář hodlá své plodiny prodávat. Popřípadě předcházející registrační číslo GLOBALG.A.P., pokud již byl producent registrován u jiného certifikačního orgánu.[8] Výše uvedené informace musí být shodné s informacemi, uvedenými v sublicenční a certifikační dohodě uzavřené mezi producentem a certifikačním orgánem. Pro schválení registrace musí producent: podepsat sublicenční a certifikační dohodu s certifikačním orgánem; mít přiděleno klientské číslo GLOBALG.A.P. - (GGN), případně i registrační číslo, které může přidělit certifikační orgán; odsouhlasit zaplacení registračního poplatku GLOBALG.A.P.. Informace o poplatcích se nacházejí v platném ceníku GLOBALG.A.P. a jsou k dispozici na internetových stránkách organizace GLOBALG.A.P.. Registrační proces musí být dokončen před zahájením certifikace Certifikace GLOBALG.A.P. Udělení certifikátu je podmíněno splněním všech příslušných požadavků dokumentu Obecné předpisy GLOBALG.A.P. a všech příslušných klíčových povinností ~ 16 ~

21 3 Teoretická východiska práce a povinností v rámci jednotlivých oborů a podoborů producentem zjištěných při certifikační inspekci. Inspekce nemůže proběhnout před provedením prvotní nebo opětovné registrace producenta certifikačním orgánem. Načasování se liší v závislosti na tom, jedná-li se o první nebo další inspekci a v závislosti na prověřovaném produktu[2]. Při certifikaci farmy, při první inspekci, podle normy v rostlinné výrobě je nutné, aby alespoň jedna plodina posuzované oblasti byla v době auditu na farmě přítomna, ať už na poli nebo ve skladu. Pro druhou kontrolu a následné kontroly platí, že musí být přítomna alespoň jedna zemědělská kultura či plodina registrovaného modulu Ovoce a zelenina, která se vyskytuje na výrobním místě, výskytem se rozumí ve skladu, nebo u plodiny, která ještě není připravena ke sklizni na poli, nebo v sadu, aby bylo jasně poznat, zda se s plodinou zachází v souladu s pravidly GLOBALG.A.P. [2]. Platnost certifikátu je ve většině případů 12 měsíců. Počáteční doba platnosti vyznačená na tištěném certifikátu je dnem, kdy certifikační orgán rozhodl o certifikaci po odstranění všech neshod. Certifikát nemůže být vydán na dobu kratší 12 měsíců. Je však možné za podmínek specifikovaných GLOBALG.A.P.em certifikát prodloužit. K prodloužení může dojít pouze v případě, že se producent nebo výrobní skupina znovu zaregistruje před vypršením platnosti certifikátu[2]. Při inspekci či certifikaci oboru živočišné produkce nebo akvakultury musí být zvířata z registrované živočišné produkce nebo vodního hospodářství přítomna na farmě. Pro živočišnou produkci dále platí, že při rozhodování o načasování inspekcí v dvouletém období se musí brát v úvahu přírodní podmínky, tam kde existuje stájový a venkovní chov, musí být každý z nich během této doby prověřen. Všechny certifikované produkty musí projít inspekcí ještě před vydáním certifikátu. Certifikační společnost může provést pro ověření splnění požadavků ohlášenou i neohlášenou návštěvu[2]. Inspekci certifikace podle tohoto standardu je oprávněný provádět pouze inspektor, pro individuální certifikaci, popř. auditor pro systémovou certifikaci skupin, tehdy, je-li držitelem certifikátu získaného u certifikační společnosti akreditované podle ISO Zde jsou definovány požadavky na jeho vzdělání a praxi, nutností je znalost odborného anglického jazyka pro danou oblast certifikace[2]. Po provedení inspekce seznámí inspektor producenta s nálezem a zaznamenanými odpověďmi. Tyto vyplněné checklisty musí certifikovaný podepsat, že souhlasí s výsledky inspekce, a ponechá si jednu kopii. Dále je vystaven protokol o neshodě, který je také podepsán jak inspektorem, tak certifikovaným[2]. ~ 17 ~

22 3 Teoretická východiska práce Udělení certifikátu Aby byly splněny požadavky standardu a bylo možné udělení certifikátu, je třeba, aby producent nebo výrobní skupina splnil všechny klíčové povinnosti na 100% a alespoň 95% všech aplikovatelných povinností. Plnění kontrolních bodů označených jako doporučení není povinné, pokud by ovšem nedocházelo k porušení národních právních předpisů. Po skončení auditu zasedne certifikační komise certifikačního orgánu, jež provádí inspekci či audit u producenta a vydá stanovisko, zda udělit certifikát. Výsledek je posléze i zaznamenána do centrální databáze GLOBALGAP, která je online dostupná na internetu. V této databází je možné si i ověřovat podle čísla GGN zda daný producent má platný certifikát a k jakému produktu se to vztahuje[2]. Pokud byly u auditu zjištěny nesplnění požadavků daných standardem, má certifikační orgán zajišťující v podniku proces certifikace k dispozici tři typy sankcí: varování (warning) žadatel má lhůtu 28 dní na odstranění neshody. Při nedodržení této lhůty je okamžitě aplikována následující sankce pozastavení ; pozastavení (suspension) zemědělec nesmí užívat značku, logo, licenci ani dosavadní certifikát, a to po stanovenou dobu. Toto platí až do okamžiku, kdy existuje písemný důkaz, že neshody, které vedly k této sankci, byly odstraněny. Pozastavení může trvat maximálně 6 měsíců, poté je aplikována poslední sankce zrušení; zrušení (cancellation) úplný zákaz použití veškerých značek, certifikátů nebo licencí spojených s GLOBALG.A.P.em. Producent může požádat o novou certifikaci až po dvanácti měsících Národní technická pracovní skupina Organizace GLOBALG.A.P. se snaží získat kvalifikované podněty od národních specialistů, v jejich vlastním jazyce s ohledem na specifické právní a strukturální podmínky v rámci různých oblastí zahrnutých do standardu. Založení národních technických pracovních skupin (dále NTWG) GLOBALG.A.P. v jednotlivých státech je důležitým krokem k dosažení tohoto cíle. Všechny výkladové směrnice, jež obsahují informace důležité pro zavádění standardu vytvořené NTWG jsou podrobeny schválení sekretariátu GLOBALG.A.P. předtím, než v dané zemi nabudou charakteru normativního dokumentu. Pro sekretariát GLOBALG.A.P. jsou NTWG přímým spojením a prvním kontaktním místem v dané zemi.[2] Všechny NTWG, tedy i ta česká, úzce spolupracují se sekretariátem organizace GLOBALG.A.P. a s jejími výbory. Podporují a pomáhají zavádět a neustále zlepšovat systém a standard na základě specifických potřeb dané oblasti. ~ 18 ~

23 3 Teoretická východiska práce Mezi hlavní úkoly NTWG patří:[10] zajišťování oficiálních překladů standardu do národního jazyka vytváření národních interpretačních směrnic provádění korektur překladů (terminologická, jazyková) udržování dokumentů v aktualizovaném stavu poskytování podpory organizaci GLOBALG.A.P. Česká Národní technická pracovní skupina vznikla v roce Jejími členy jsou zástupci vysokých škol (VŠCHT, ČZU), neziskových organizací (Česká společnost pro jakost, o.s.), certifikačních orgánů (CSQ-CERT) a nezávislých odborníků pro různé oblasti zemědělství, životního prostředí a bezpečnost práce. [10] GLOBALG.A.P. v ČR Počátek užívání GLOBALG.A.P. v České Republice se datuje k roku 2006, kdy vznikla Česká národní technická pracovní skupina, která je nutným předpokladem pro užívání standardu na území daného státu. Na podzim roku 2006 byly také uděleny první dva certifikáty společností EFSIS, která byla první certifikační agenturou, která udělila certifikát GLOBALG.A.P. na území České Republiky. V současné době je v České Republice standard zaváděn zejména v oblasti pěstování ovoce a zeleniny. Na tyto komodity byl soustředěn tlak obchodních řetězců, které standard více či méně striktně vyžadují, záleží na jednotlivých řetězcích, zda požadují certifikovanou produkci. Mezi prvními jej v České republice zavedla společnost MAKRO Cash & Carry ČR v roce 2007.[9] V oblasti živočišné produkce je zavádění požadavků GLOBALG.A.P. spíše v počátcích. Také v zahraničí jsou certifikáty udělovány v drtivé většině případů v oblasti rostlinné produkce, ale už i v této oblasti se najdou první vlaštovky, jako jsou produkce prasat, drůbeže, a tak i zkušenosti.[5] Od roku 2007 v České Republice začínají velké řetězce postupně požadovat tento certifikát pro své dodavatele, a to ať pro své přímé dodavatele, nebo i zprostředkovaně od dodavatelů potravin, kteří produkty zemědělské výroby nakupují jako suroviny, a proto lze předpokládat, že prozatím velmi nízké počty vydaných certifikátu vydaných u nás v příštích letech výrazně porostou. [12] Tato prognóza se postupně začíná naplňovat, je vidět vzrůstající celkový počet vydaných certifikátů v české republice na grafu v Obr. č. 1, jehož data jsou čerpány z časopisu Kvalita potravin č. 1/2010. ~ 19 ~

24 3 Teoretická východiska práce Obr. č. 1: Graf počtu vydaných certifikátů v ČR V grafu na Obr. č. 2, jehož data jsou čerpány z časopisu Kvalita potravin č. 1/2010, je vidět, že nejen absolutní počet, ale i relativní počet certifikátů vydaných v ČR na počet organizací podnikajících v zemědělství je velmi malý oproti ostatním zemím, což lze přisuzovat na vrub obchodníkům, kteří až do roku 2007 nevyžadovali tento certifikát při nákupu zemědělských komodit. Obr. č. 2:Graf porovnání procent podniků, jež vlastní certifikát GLOBALG.A.P. v jednotlivých zemích S nárůstem poptávky po certifikaci GLOBALG.A.P. roste samozřejmě i počet společností nabízejících tuto certifikaci u nás. V současné době tj. k se aktivně tímto standardem v České republice zaobírá 5 organizací, jež z toho ~ 20 ~

25 3 Teoretická východiska práce jen 3 mají českou akreditací. Společnost, která vydala nejvíce certifikátu GLOBALG.A.P. v ČR, je Česká společnost pro jakost - CSQ-CERT. Dalšími společnostmi s českou akreditaci jsou Bureau Veritas Certification Czech Republic s.r.o. a SAI Global Certification s.r.o.. Společnost LACON gmbh, jež má Rakouskou akreditaci vystavila v ČR 13 certifikátů a je tak druhou největší působící na českém trhu. [11] Obr. č. 3:Poměr certifikačních společností působících na českém trhu z hlediska vydaných certifikátů Používané softwarové nástroje při certifikaci V dnešním světě protkaném výpočetní technikou je používání softwarové podpory při jakékoli práci nezbytné k ulehčení zátěže pracovníka a tím i zvýšení jeho produktivity práce. Nejpoužívanější a také nejobecnější současné nástroje podpory by se daly považovat textové editory. Ty urychlí práci s textem, ale jsou dosti manuálně náročné a hlavně pracné. Jejich použití se mnoho neliší od ručně psaného textu, nedokážou mnoho automatizací s daty. Dalším běžně používaným nástrojem je tabulkový kalkulátor, pomocí něhož lze již mnoho věcí automatizovat, hlídat některé podmínky, postupovat podle šablony při vyplňování a navést či upozornit uživatele na skutečnosti, které musí ošetřit. Ovšem o výrazném přizpůsobení softwarových požadavkům kladených na opravdovou podporu certifikace standardu GLOBALGAP, která by byla nápomocná k výraznému urychlení práce, nelze mluvit. V současné době neexistuje na trhu sofistikovaný softwarový nástroj pro podporu certifikace standardu GLOBALG.A.P., který by byl určen výhradně na práci ~ 21 ~

26 3 Teoretická východiska práce s tímto standardem a využíval veškerých možných automatizací a specifik GLOBALG.A.P.. V praxi jsou Českou společnosti pro jakost používané nástroje k zefektivnění práce auditorů a inspektorů pouze univerzální programové vybavení jako je MS Word a MS Excel, v němž jsou vedeny seznamy otázek checklist. Ovšem tyto z podstaty univerzální nástroje nejsou schopny vyhovovat nárokům sofistikovanější podpory certifikace. Při práci s nimi nejsou při auditech systémově hlídaná omezení a nároky plynoucí ze specifikace standardu, což by měla splňovat nejzákladnější softwarová podpora a vše je závislé na pozornosti auditora. Využití výsledků a údajů o klientovi z minulých inspekcí je velice nesnadná a nepřehledná a samozřejmě nepoužitelné k aktuální prováděné inspekci. Všechna data musí být znova vložena. Všechny archivované záznamy o klientech a kontrolách jsou nyní vedeny v papírové podobě, či v elektronické formě ve formátu textových editorů, což ztěžuje vzájemnou komunikaci mezi auditory o klientech a využití těchto poznatků. Toto je v dnešní moderní době neudržitelný stav, jež udržuje neefektivnost při práci a nenabízí žádnou možnost růst produktivity práce auditorů. Vzhledem k tomu, že v současné době neexistuje na trhu použitelný nástroj na podporu certifikace standardu GlobaG.A.P., jež by splňoval nároky na něj kladené certifikujícími organizacemi bylo přistoupeno k vývoji nového software. ~ 22 ~

27 4 Metodika řešení 4 Metodika řešení Na samém začátku prací bylo nutné se v teoretických východiskách práce seznámit obecně s průběhem certifikací a detailně poznat samotný standard GlobalG.A.P.. Před začátkem vlastních analytických prací je nutné jasně definovat požadavky na funkčnost systému od zaměstnanců České společnosti pro jakost, pro něž bude primárně tato softwarová podpora certifikace GlobalG.A.P. tvořena. Metodika tvorby specifikací na software bude popsána v první podkapitole této kapitoly. Po jasném definování požadavků bude přistoupeno k návrhu software s využitím metod tvorby návrhu popsaných v druhé kapitole metodiky. Po úspěšně dokončeném návrhu bude přistoupeno k implementaci k implementaci software s využitím programového vybavení popsaného v poslední podkapitole metodiky. Postup nasazení do praxe, provoz a údržba již není součásti této práce. Na konci práce bude v diskuzi software zhodnocen a navrženy možné další doplnění funkčnosti. 4.1 Metodika tvorby specifikace požadavků na software Základ specifikace požadavků na software bude tvořen podle mezinárodního standardu ANSI/IEEE číslo 830, jež je k tomuto účelu přímo vytvořen. Je to úplný popis chování systému, jež má být vyvinut. V textu budou použity jen základy tohoto standardu, ze kterého budou vypuštěny irelevantní oddíly, jež by nemělo pro tento konkrétní software opodstatnění je uvádět. Ve specifikaci požadavků na software je nejprve popsán účel systému, jež říká, proč má být daná aplikace vytvořena a vymezuje zamýšlený okruh čtenářů dokumentu. Dále je definován rozsah systému, jež udává seznam softwarových systémů, které mají být vytvořeny, co se od nich má, případně nemá očekávat, a jak budou používány včetně jejich přínosů. Další části je nezbytný popis definic, zkratek a akronymů, což poskytuje definice termínů používaných při tvorbě specifikace, návrhu a implementace software, aby obsahu rozuměl neodborník z dané oblasti[26]. Popis systému bude zahájen uvedením profilů uživatelů. Zde budou popsány jednotlivé role a všeobecné charakteristiky budoucích uživatelů softwaru zahrnující jednak obyčejné uživatele pracující se software, tak i administrátory zabezpečující bezproblémový chod software. Následovat by měl výčet všech budoucích funkčních požadavků na software, jež zahrnuje jednoduchý popis požadovaných funkcí kladených na software. Detailněji tyto funkce jsou rozebrány pomocí analýzy případů užití při návrhu software. Další požadované vlastnosti systému budou rozebrány v části nefunkční požadavky na software, přičemž by se mělo v této části rozebrat mimo jiné dostupnost, bezpečnost, udržovatelnost či přenositelnost vyvíjeného software[26]. ~ 23 ~

28 4 Metodika řešení 4.2 Využité metody tvorby návrhu V této podkapitole budou uvedeny a přiblíženy všechny metody a diagramy použité při návrhu a modelovaní dané aplikace před zahájením implementace UML UML (Unified Modeling Language) je univerzální jazyk pro vizuální modelování systémů. 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ů.[15] Jazyk UML není vázán na žádnou specifickou metodiku nebo životní cyklus. Lze jej použít společně se všemi existujícími metodami a nenabízí žádný druh metodiky modelování, ale poskytuje pouze vizuální syntaxi, kterou můžeme využít při sestavování modelů.[15] Modelovací jazyk UML je souhrnem především grafických notaci k vyjádření analytických a návrhových modelů. UML je jazyk, který umožňuje modelovat jednoduché i složité aplikace pomoci stejné formální syntaxe. Tím umožňuje výsledky práce sdílet s ostatními návrháři. Vybrané modely jsou pochopitelné i pro zadavatele aplikace a umožni kvalitní vyjasnění požadavků uživatelů na vytvořený systém. Žádný diagram nezachycuje navrhovaný systém jako celek, ale soustředí se vždy pravě na jeden pohled na vyvíjený systém.[16] První verze jazyka UML byla představena v roce 1997, od té doby se stala průmyslovým standardem pro modelování systémů. V roce 2001 byla představena verze 2.0, v níž došlo k řadě významných změn. Patrně nejviditelnější změnou je uvedení nových typů diagramů. Diagramy objektů a seskupení se sice obecně používaly, ale nebyly oficiálním typem diagramu. Dále došlo ke změně názvu diagramů objektové spolupráce na komunikační diagramy. Aktuálně se používá nejnovější verze 2.1. [16] Jazyk UML byl navržen, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Diagramy vytvořené v jazyku UML jsou srozumitelné pro lidi, ale navíc je mohou snadno interpretovat i programy CASE (Computer-aid software engineering). Zmíněná koncepce vychází ze skutečnosti, že se rozsáhlé softwarové projekty bez podpory CASE nástrojů neobejdou.[15] Základ jazyka UML je tvořen ze 3 stavebních bloků: Předměty Vztahy Diagramy ~ 24 ~

29 4 Metodika řešení Předměty Předměty jsou samotné elementy modelu a dělíme je na : strukturní abstrakce, což jsou podstatná jména modelu UNL, jako jsou třídy, rozhraní, spolupráce, případ užití a další; chování, což jsou slovesa modelu UML, např. interakce, stav atd.; seskupení, což jsou balíčky používané k seskupení sémanticky souvisejících prvků modelu do soudržných jednotek; poznámky, anotace, které lze k modelu připojit s úmyslem zachytit informaci sestavenou jen k tomuto účelu.[17] Vztahy Vztahy si lze představit jako relace (vztahy) mezi dvěma předměty, jež umožňují zachytit významový vztah mezi nimi. Rozlišujeme vztahy: asociace, popisují spojení mezi objekty či třídami; závislost, je relace mezi dvěma elementy, v níž se změna jednoho elementu promítá do druhého elementu a čtyři nejčastěji používané typy jsou Užití, Abstrakce, Oprávnění a Vazba; zobecnění je relaci mezi obecnějším elementem a elementem přesněji specifikovaným, přičemž přesněji specifikovaný element obsahuje více informací a je zcela konzistentní s obecnějším elementem, který jej může nahradit; realizace je relace mezi klasifikátory, kde jeden klasifikátor určuje dohodu, jejíž uskutečnění zaručuje druhý klasifikátor; agregace je, když cílový prvek je součásti zdrojového prvku; kompozice je silnější forma agregace; ochranná nádoba, je když zdrojový prvek obsahuje cílový prvek Diagramy Diagramy jsou okna nebo pohledy na model nikoli samotný model. Jsou také prvořadým a základním mechanismem pro zadávání nových informací do exitujícího modelu, zároveň však, když se předměty odstraní z diagramu, v samotném modelu dále existují. [15] Celkem existuje 13 různých typů diagramu, které se dělí na diagramy modelující statickou strukturu systému a dynamickou strukturu systému. Statický model zachycuje předměty a strukturní relace mezi předměty a je vyjadřován těmito diagramy: ~ 25 ~

30 4 Metodika řešení Diagram tříd; Diagram nasazení; Diagram balíčku; Objektový diagram; Diagram komponent; Diagram složené struktury. Dynamický model naproti tomu zachycuje způsob, jimž na sebe jednotlivé předměty navzájem působí, aby bylo dosaženo požadovaného chování softwaru. Pro dynamický model jsou používány následující diagramy: Diagram případu užití; Diagram aktivit; Sekvenční diagram; Diagram komunikace; Diagram časování; Stručný diagram interakce; Diagram stavového automatu.[17] Neexistuje žádné pevně stanovené pořadí, v němž by se měly diagramy vytvářet. Přesto se obvykle začíná diagramem případu užití (USE CASE diagram), který definuje rozsah platnosti navrhovaného systému. Obvykle se pracuje často souběžně s několika různými diagramy zároveň, přičemž každý z nich vybrušujeme postupně, kdykoli je odhalen další detail navrhovaného softwarového systému. [15] V samotném návrhu software v této práci budou použity jen některé diagramy a to z důvodu rozsahu této práce. Tyto použité diagramy jsou popsány dále Diagram případů užití Diagram užití je jedním z nejdůležitějších a také nejčastěji používaným diagramem při návrhu systémů pomoci UML a slouží ke grafickému znázornění případů užití, jejich vzájemných vztahů a vazeb s uživateli z pohledu uživatele.[18] Případy užití zachycují přesně funkčnost, která bude modelovanou aplikací pokrytá a vymezují tak jednoznačně rozsah prací.[16] Modelování případů užití je doplňkovým způsobem získávání a dokumentování požadavků a skládá se zejména z nalezení hranic systému, vyhledání účastníků, nalezení případů užití a tvorbou scénářů.[15] Výstupem uvedených aktivit je model případu užití, obsahující čtyři komponenty: Hranice systému; Aktéři; ~ 26 ~

31 4 Metodika řešení Případy užití; Relace.[15] Hranice systému vyznačuje území nebo hranice modelovacího systému a určuje co je součástí systému a co naopak není. Hranici systému definuje ten, kdo systém používá, a to, co specifikuje přínos systému účastníkům.[15] Aktér specifikuje roli, ve které vystupuje určitá externí entita v rámci její komunikace se systémem. Aktér se nejčastěji zobrazuje v diagramech panáčkem, jak je vyobrazen na Obr. 4. Aktérem může být nejen uživatel pracující se systémem, ale také jiný externí systém nebo také čas, jako spouštěč událostí bez zásahu uživatele. Aktéři provádějí případy užití. V systému může jeden aktér provádět více případu užití a také obráceně jeden případ užití může být prováděn více aktéry. [16] EA 7.5 Unregistered Trial Version EA 7.5 Unregistered Trial Version Případ užití Aktor EA 7.5 Unregistered Trial Version Obr. č. 4: Aktér Obr. č. 5: Případ užití Případ užití je specifikace posloupností činnosti ve scénářích, včetně proměnných posloupností a chybových posloupností, které systém, podsystém nebo třída může vykonávat prostřednictvím interakce s vnějšími účastníky a platí pro ně, že jsou vždy iniciovány účastníkem a jsou napsány vždy z pohledu účastníka. Pro každý případ užití by měl být sestaven scénář průběhu daného případu užití. Případ užití se v UML 2 zobrazuje většinou obdélníkem jak je vidno na Obr. 5.[15] Vazby definují vztahy mezi jednotlivými prvky diagramu. Rozlišujeme tyto vazby: Relace <<include>> představuje vyčlenění společného chování ze dvou či více případů užití do samostatného případu užití, kdy základní případ užití není soběstačný; Generalizace případů užití umožňuje chování společné pro více případů užití převést do rodičovského případu užití; Relace <<extend>> přidává k základnímu případu užití nové, rozšiřující chování do základního případu užití, který je plně soběstačný.[16] Diagram tříd Diagram tříd zobrazuje statickou strukturu systému především vztahy mezi objektovými třídami navrhovaného systému. Struktura třídy je definovaná jeho atributy, operacemi a omezeními. Atributy třídy jsou informace, které o třídě ~ 27 ~

32 4 Metodika řešení uchováváme. Zdrojem pro atributy třídy jsou věcné znalosti o dané problematice a analýze podrobných požadavků uživatelů. Operace třídy jsou operace, které třída definuje, představují její chování, nebo také zprávy kterým třída rozumí.[16] Vztahy, které jednotlivé třídy navzájem pojí, jsou asociace, agregace, kompozice a specializace/generalizace. Podřízenost jednoho objektu vůči druhému je v analýze chápána dvojím způsobem, bud jako agregace nebo jako kompozice. V obou případech se jedna o vztah dvou objektů, z nichž podřízený objekt má svou objektovou referenci vloženou do prvního objektu. Asociace znázorňuje vztahy mezi jednou čí více třídami, které jsou abstrakcí množiny spojení mezi instancemi těchto tříd. Vazby typu agregace říká, že jedna třída je části druhé třídy. Generalizace je vztah mezi obecnou objektovou třídou a jejími konkrétními potomky Stavový diagram Stavové diagramy popisují všechny možné stavy, které může nabývat konkrétní objekt systému, neboli modelují chování objektu napříč všemi případy užití a zároveň znázorňují, jak se stavy objektů mění v závislosti na událostech, které se jej týkají.[16] Základem syntaxe jsou stavy objektů. Speciálními případy mezi stavy jsou počáteční a koncový stav diagramu. Dynamiku představují přechody mezi stavy a události, které vyvolávají přechody. Stav objektu můžeme charakterizovat tak, že se jedná o konkrétní situaci, která nastala za doby života objektu, během níž objekt vyhovuje nějaké podmínce, realizuje konkrétní operaci nebo třeba jen čeká ne příchod stimulu. Tímto stimulem bývá událost, ale může to být rovněž požadavek na operaci. Objekt v průběhu života mění svůj stav, který je dán hodnotami atributů objektu, aktuálními spojeními s ostatními objekty a právě prováděnou operací.[16] Diagram aktivit Diagramy aktivit jsou objektovou obdobou vývojových diagramů a modelují procesy jako kolekce aktivit jednotlivých kroků a přechody mezi nimi. Mají užití i u modelování business procesů a workflow jak u sekvenčních, tak paralelních chování. Diagramy mají dva zvláštní stavy: zahájení a ukončení. [16] Vzhledem k tomu, že diagramy aktivit jsou určeny zejména pro komunikaci s lidmi se znalostí struktury obchodních procesu, měla by složitost diagramů příliš vysoká a být dostatečně přehledné. [16] U diagramů aktivit pracujeme s těmito symboly: akce je jádrem a dále nedělitelnou a nepřerušitelnou jednotkou diagramu aktivit, a název je nejčastěji vyjadřován pomocí slovesné vazby (např. založit zákazníka); ~ 28 ~

33 4 Metodika řešení přechody mezi akcemi v diagramu nastávají automaticky po ukončení předchozí akce; hodnocení přechodů je vyjádření logické podmínky, která podmiňuje konkrétní přechod; větvení a spojení nebo též rozcestí je prvek, který umožňuje modelovat paralelní chování, tím že rozvětví přechod na několik paralelních vláken, které se později opět spojí ve spojení; plavecké dráhy umožňují rozlišit, kdo je konkrétně zodpovědný za konkrétní aktivitu, ovšem diagram se musí upravit do vertikálních pruhů vzájemně oddělených čarami.[16] Sekvenční diagram Sekvenční diagram je jeden z diagramů interakce, které se používají v UML k modelování libovolného typu interakce mezi instancemi klasifikátoru. Během realizace případů užití se pak používají k modelování interakcí mezi objekty realizujícími konkrétní případ užití nebo jeho části. [17] Sekvenční diagramy znázorňují interakce mezi čarami života jako časově uspořádanou posloupnost událostí. Tyto diagramy jsou nejbohatší a nejpružnější formou diagramů interakce. [17] Rozlišujeme dva druhy sekvenčních diagramu: instanční sekvenční diagram popisuje pouze jednu instanci use case; generický sekvenční diagram zachycuje všechny scénáře (instance) daného use case.[25] Diagram nasazení Diagram nasazení se používá k modelování typů hardwaru, softwaru a spojení, jež budou součástí konečného nasazeného systému. Diagram obsahuje komponenty, uzly a vztahy mezi jednotlivými uzly. Uzel reprezentuje typ hardwaru a je zobrazen jako krychle opatřena názvem fyzického hardwaru, který reprezentují a může to být bud procesor nebo zařízení. Procesor umí spouštět komponentu. Komponenta zastupuje typ software a navazuje se na jednotlivé uzly. Vztah mezi uzly musí udávat potřebné protokoly pro komunikaci mezi danými uzly na úrovní komponent. [15] Datový model Datový model bude znázorněn entitně-relačním diagramem (ERD), jež se používá pro abstraktní a konceptuální znázornění dat, jež jsou datovou základnou software. Entitně-relační diagram se skládá z entit, tributů, vazeb. ~ 29 ~

34 4 Metodika řešení Entita je v podstatě datový objekt, pod nímž si můžeme představit např. určitý typ dokumentů, který daná organizace používá (faktura, evidenční karta). Je to určité seskupení dat, které k sobě logicky náleží a které zkoumáme v rámci zadané analýzy. Entitu popisujeme podstatným jménem.[16] Atribut je položka určité entity a je určen svým formátem a velikostí. Vazba určuje vztahy mezi entitami a existují tři typy vazeb 1:1, 1:N a M:N u niž se určuje kardinalita. Vazba M:N musí být při sestavování modelu převedena na vazbu 1:N pomocí vazební entity.[16] Klíč je atribut u entit, který má významnější úlohu než ostatní atributy. Dobře navržené klíče v datové analýze jsou velmi důležité pro návrh databází. Správně identifikované klíče jsou jedním z faktorů rychlosti zpracování dat. Rozlišujeme tyto druhy klíčů: Primární klíč musí být jednoznačný, což znamená, že jednotlivý výskyt tohoto klíče se musí lišit od dalších výskytu tohoto klíče pro jednoznačnou identifikaci každého výskytu entity. Primární klíč se vybírá atribut číslo nebo krátký řetězec. Primární klíč může být tvořen i více atributy, v tom případě hovoříme o složeném klíči. Alternativní klíč může být jeden nebo více atributů, které jsou také jednoznačné, ale nebyly vybrány jako primární klíč. Cizí klíč je tvořen atributem, který se v jiné entitě vyskytuje jako primární klíč.[16] 4.3 Využité programové vybavení K návrhu a implementací vytvářeného software bude použito několik softwarových nástrojů, jejichž stručná charakteristika bude popsána dále v této podkapitole Enterprise Architekt Enterprise Architekt je objektově orientovaný CASE nastroj vyvíjen společností Sparx Systems, jež pokrývá všechny fáze tvorby objektově orientovaného návrhů aplikací. Podporuje grafický i textový návrh všemi 13 diagramy modelovacího jazyka UML 2.1, výrazně je podporována týmová práce na projektech, dovede generovat flexibilní a vysoce hodnocenou dokumentaci k projektům a také podporuje generování kostry zdrojového kódu pro mnoho populárních programovacích jazyků, včetně JAVA, C++, C#, Delphi, Python, PHP, či Visual Basic a dále vestavěný editor umožňuje zvýraznění syntaxe u zdrojového kódu podporovaných programovacích jazyků.[19] ~ 30 ~

35 4 Metodika řešení Programovací jazyk Java Java je objektově orientovaný programovací jazyk, který vyvinula firma Sun Microsystems a představila 23. května května 2007 Sun uvolnil zdrojové kódy Javy a Java je dále vyvíjena jako open source. Je jedním z nejpoužívanějších programovacích jazyků na světě. Díky své přenositelnosti je Java používána pro programy, které mají pracovat na různých systémech. Platforma Java se dělí na platfory: JavaCard jež je určená pro aplikace na čipových kartách; Java ME (Micro Edition) se využívá pro vývoj aplikací pro mobilní telefony a různá zabudovaná zařízení; Java SE (Standard Edition) je zaměřená na vývoj aplikací pro desktopové počítače; Java EE (Enterprise Edition) je určená pro distribuované systémy pracující na řadě spolupracujících počítačů rozprostřené po celém světě. Základní vlastností programovacího jazyku Java jsou: jednoduchý jeho syntaxe je zjednodušenou verzí syntaxe jazyka C a C++. objektově orientovaný s výjimkou osmi primitivních datových typů jsou všechny ostatní datové typy objektové; distribuovaný je navržen pro podporu aplikací v síti, když podporuje různé úrovně síťového spojení, práce se vzdálenými soubory, umožňuje vytvářet distribuované klientské aplikace a servery; interpretovaný místo skutečného strojového kódu se vytváří pouze tzv. mezikód. Tento formát je nezávislý na architektuře počítače nebo zařízení. Program pak může pracovat na libovolném počítači nebo zařízení, který má k dispozici interpret Javy, tzv. virtuální stroj Javy - Java Virtual Machine (JVM); robustní je určen pro psaní vysoce spolehlivého softwaru z tohoto důvodu neumožňuje některé programátorské konstrukce, které bývají častou příčinou chyb (např. správa paměti, příkaz goto, používání ukazatelů). Používá tzv. silnou typovou kontrolu veškeré používané proměnné musí mít definovaný svůj datový typ; Správa paměti je realizována pomocí automatického Garbage collectoru, který automaticky vyhledává již nepoužívané části paměti a uvolňuje je pro další použití; ~ 31 ~

36 4 Metodika řešení bezpečný má vlastnosti, které chrání počítač v síťovém prostředí, na kterém je program zpracováván, před nebezpečnými operacemi nebo napadením vlastního operačního systému nepřátelským kódem; nezávislý na architektuře vytvořená aplikace běží na libovolném operačním systému nebo libovolné architektuře. Ke spuštění programu je potřeba pouze to, aby byl na dané platformě instalován správný virtuální stroj. Podle konkrétní platformy se může přizpůsobit vzhled a chování aplikace; přenositelný vedle zmíněné nezávislosti na architektuře je jazyk nezávislý, i co se týká vlastností základních datových typů. Přenositelností se však myslí pouze přenášení v rámci jedné platformy Javy (např. J2SE). Při přenášení mezi platformami Javy je třeba dát pozor na to, že platforma určená pro jednodušší zařízení nemusí podporovat všechny funkce dostupné na platformě pro složitější zařízení a kromě toho může definovat některé vlastní třídy doplňující nějakou speciální funkčnost nebo nahrazující třídy vyšší platformy, které jsou pro nižší platformu příliš komplikované; výkonný přestože se jedná o jazyk interpretovaný, není ztráta výkonu významná, neboť překladače pracují v režimu právě včas a do strojového kódu se překládá jen ten kód, který je opravdu zapotřebí; víceúlohový podporuje zpracování vícevláknových aplikací; dynamický Java byla navržena pro nasazení ve vyvíjejícím se prostředí. Knihovna může být dynamicky za chodu rozšiřována o nové třídy a funkce, a to jak z externích zdrojů, tak vlastním programem.[23] Nevýhoda Javy proti programovacím jazykům, které provádějí tzv. statickou kompilaci (např. C++), je start programů psaných v Javě pomalejší, protože prostředí musí program nejprve přeložit a potom teprve spustit. Je však možnost využít mechanismů JIT a HotSpot, kdy se často prováděné nebo neefektivní části kódu přeloží do strojového kódu a program se zrychlí. Další nevýhodou projevující se hlavně u jednodušších programů je větší paměťová náročnost při běhu způsobená nutností mít v paměti celé běhové prostředí.[23] Netbeans IDE 6.5 NetBeans IDE je integrované vývojové prostředí pro Windows, Mac, Linux a Solaris. Projekt NetBeans se skládá z open-source IDE a aplikační platformy, která umožňuje vývojářům rychle vytvářet webovou, podnikovou, desktopovou a i aplikace pro mobilní zařízení. Kromě plné podpory všech platforem Java (Java SE, Java EE, Java ME, a JavaFX), je NetBeans IDE 6.5 ideální nástroj pro vývoj softwaru s PHP, Ajax a ~ 32 ~

37 4 Metodika řešení JavaScript, Groovy a Grails, Ruby a Ruby on Rails, a C / C++. Verze 6.5 poskytuje rozšířenou podporu webových rámců (Hibernate, Spring, JSF, JPA), aplikační server GlassFish, a databází.[20] SQL SQL (Structured Query Language) je neprocedurální jazyk určený pro správu dat v relačních systémech pro správu databází (RDBMS) založených na relační algebře. Prostřednictvím jazyka SQL může programátor, nebo správce databáze provádět modifikaci struktury databáze, měnit bezpečnostní nastavení systému, přidávat oprávnění uživatele pro přístup k databázím a tabulkám, získávat informace z databáze a aktualizovat obsah databáze.[22] Jazyk SQL byl vyvinut v laboratořích IBM v San Jose ke konci 70. let 20. století. Ale už v roce 1970 Edgar F. Codd položil základ relačním databázím v dokumentu A Relational Model of Data for Large Shared Data Banks kdy používá pro rozdělení dat do množin a odpovídajících společných podmnožin matematické principy relační algebry. [21] V dnešní době existuje mnoho implementací jazyka SQL, z nichž každá z nich má silné i slabé stránky použití v různých situacích. Nejoblíbenější a nejpoužívanější jsou tyto: Microsoft Access MySQL Oracle Microsoft Query[21] MYSQL MySQL je databázový systém, vytvořený švédskou firmou MySQL AB, nyní vlastněný společností Sun Microsystems, dceřinnou společností Oracle Corporation. Jeho hlavními autory jsou Michael Widenius a David Axmark.[24] MySQL je multiplatformní databáze. Komunikace s ní probíhá pomocí jazyka SQL. Podobně jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s některými rozšířeními. [24] Pro svou snadnou implementovatelnost, lze jej instalovat na Linux, MS Windows, ale i další operační systémy, výkon a především díky tomu, že se jedná o volně šiřitelný software, má vysoký podíl na v současné době používaných databázích. Velmi oblíbená a často nasazovaná je kombinace Linux, MySQL, PHP a Apache jako základní software webového serveru. [24] ~ 33 ~

38 4 Metodika řešení MySQL bylo od počátku optimalizováno především na rychlost, a to i za cenu některých zjednodušení: má jen jednoduché způsoby zálohování, a až donedávna nepodporovalo pohledy, triggery, a uložené procedury. Tyto vlastnosti jsou doplňovány teprve v posledních letech, kdy začaly nejčastějším uživatelům produktu již poněkud scházet.[24] ~ 34 ~

39 5 Výsledky 5 Výsledky Jak již bylo stanoveno dříve cílem práce je navrhnout a implementovat softwarovou podporu k certifikaci GlobalG.A.P. Cestu k tomuto cíli rozdělíme do tří etap. První bude obsahovat definování požadavků na software. Dalším etapou bude návrh příslušné softwarové podpory a v poslední etapě bude představena výsledná implementace. 5.1 Specifikace požadavků na software Před zahájením prací bylo nejprve nutné detailně nastudovat strukturu standardu GLOBALG.A.P. a samozřejmě také samotný proces certifikace a udělení certifikátu. Tyto informace jsou uvedeny v první kapitole této práce. Dále bylo důležité prodiskutovat se zástupcem firmy, pro niž je software vyvíjen, jaké budou od podpory očekávány za funkčnosti a sjednotit naše vize na uskutečnitelnost jednotlivých části software. Na základě těchto informací je zpracována specifikace požadavků na software v následující podobě Účel softwaru Software je vyvíjen pro Českou společnost pro jakost, jež má akreditaci mimo jiné i pro udělování certifikátů GLOBALG.A.P. v České Republice. Samotnému udělení certifikátu musí mimo jiné předcházet fyzická kontrola skutečností daných certifikátem u daného certifikovaného subjektu pověřeným auditorem. Výsledky kontroly se zaznamenávají do kontrolních checklistů. Manipulace se samotnými checklisty je dosti nepružná a nepřehledná, neboť jsou prozatím uváděný v excelovských sešitech. Vyhodnocení musí probíhat manuálně a je zde nezanedbatelná možnost špatného ohodnocení výsledků. Dále je potřeba při každé ukončené kontrole u daného subjektu vytisknout protokol o kontrole a protokol o neshodě s požadavky. Sestavení tohoto protokolu je nyní manuální záležitosti, kdy musí auditor pracně přepisovat dané kontrolní body s hodnocením a sestavovat výsledný dokument. Dále je nutné evidovat informace o klientech, provedených kontrolách a udělených certifikátech. Toto se děje nyní pouze v papírové podobě, což je velmi neefektivní a i ekonomicky nákladné. A tyto všechny nedostatky by měl odstranit vyvíjený software a tím výrazně zvýšit efektivitu práce auditorů Rozsah software Aplikace bude sloužit jako uživatelsky příznivá pomůcka pro certifikaci a to jak s použitím k rutinnímu vedení záznamů o klientech, kontrolách a udělených certifikátů, tak i k efektivnějšímu hodnocení jednotlivých kontrolních bodů, jejich vyhodnocení a následného tisku. ~ 35 ~

40 5 Výsledky Software bude tvořen desktopovou aplikací spolupracující s lokální databází, v níž budou uloženy lokální pracovní záznamy. Dále bude software schopen po připojení k síti komunikovat s centrálním úložištěm dat reprezentovaného databází na vzdáleném serveru Definice, zkratky a akronymy V této kapitole bude stručný popis pojmu týkajících se softwaru, jež se vyskytují v celém návrhu. Tato kapitola je důležitá proto, aby byl vždy jasný smysl použitého pojmu a nedocházelo k záměnám, či nepřesným pochopením významu. GLOBALG.A.P. je celosvětově uznávaný standard správné zemědělské praxe. Checklist je soubor kontrolních bodů rozdělených podle jednotlivých kategorií. Kontrolní bod je kontrolní otázka s předepsanou shodou, jež musí klient prokázat. Certifikát je potvrzení o shodě na správnou zemědělskou praxi se standardem GlobalG.A.P. Protokol o neshodě se sestavuje na konci každé kontroly, přičemž obsahem je především výčet kontrolních bodů, jež nejsou ve shodě s požadavky GlobalG.A.P. Auditor je oprávněná osoba provádějící kontrolu shody požadavků se skutečným stavem u certifikovaného subjektu. Administrativní pracovník je pracovník neprovádějící kontrolu, ale pracující s administrativou ohledně udělování certifikátů. Klient je zákazník společnosti jež žádá o udělení certifikátu GlobalG.A.P. a u nějž je prováděna kontrola Profil uživatele Aplikace je navrhována jako víceuživatelská. Uživatelé se dělí podle možností v systému na auditora a administrativního pracovníka. Auditor využívá především funkce týkající se provádění samotné kontroly a informace o klientech, nemá přístup ke správě uživatelů. Administrativní pracovník pracuje především s údaji o klientech, provedených kontrolách, udělených certifikátech a správou uživatelů, je omezen v prací se samotnou kontrolou, jež nemůže vykonávat Nefunkční požadavky Nejdůležitějším nefunkčním požadavkem je použitelnost softwaru na přenosných počítačích na místě, kde je vykonávaná kontrola u klienta, bez přístupu k internetu či jiného spojení s centrálním úložištěm dat. ~ 36 ~

41 5 Výsledky V organizaci může pracovat více auditorů na různých certifikacích, a proto další nefunkční požadavek je, aby software měl centrální úložiště dat pro vedení aktuálních údajů o klientech, kontrolách a udělených certifikátech. Software musí umět komunikovat s centrálním úložištěm dat. Práce s ní musí zahrnovat, jak přesun dat na server tak musí probíhat i stažení informací z centrální databáze na lokální počítač u uživatele. Nefunkční požadavek je také zavedení ochrany zneužití dat, s nimiž aplikace pracuje a zároveň byl jejich přístup umožněn pouze pro konkrétního uživatele, jež má oprávnění s nimi pracovat. Dále je důležité provádění pravidelných automatických záloh dat na centrálním úložišti pro případ poškození či ztráty dat Funkční požadavky Prvotním funkčním požadavkem je správa klientů. Uživateli musí být umožněno založit nového klienta, upravovat jejich data, popřípadě smazat již bývalé klienty. U každého klienta je potřeba evidovat název společnosti, IČO, číslo klienta, registrační číslo přidělené organizací GlobalG.A.P, dále kontaktní adresu s doplňkovými kontaktními údaji jako jsou telefonní číslo klienta a . Auditorovi bude umožněna možnost vkládání dalších informací ke klientovi v podobě poznámky v profilu klienta. Hlavní funkčností softwaru ovšem musí být podpora samotné certifikace, to znamená zobrazení jednotlivých checklistů, procházení kontrolních bodů, zobrazování hodnocení z minulé kontroly a umožnění vložení hodnocení a komentáře z minulé do aktuálně prováděné kontroly, zobrazení průběžného plnění podmínek, kontrola vyplnění všech bodů, popřípadě komentářů u odpovědí NO či N/A a konečné vyhodnocení splnění podmínek pro udělení certifikátu. Dále je nutné podporovat spravování nedokončené kontroly, tisknout dokumentaci jako přehled odpovědí, výsledek certifikace a protokol o neshodách. A také je potřeba prohlížet již uzavřené kontroly, ale již bez možnosti dodatečných změn. Doplňkovou funkčností musí být správa uživatelů, jež bude přístupná pouze pro administrativního pracovníka. Každý uživatel bude mít také možnost si změnit své přístupové heslo do systému. 5.2 Analýza a návrh aplikace Analýza a návrh softwaru vychází především ze zjištěných požadavků, jež byly definovány výše. Nejprve bude sestaven model případů užití, jež zobrazuje z pohledu uživatele celkové chování softwaru a vymezuje jeho hranice a reakce na vnější podněty. Následně bude sestaven diagram tříd a sekvenční diagram. Na závěr bude zpracován diagram nasazení, pro zobrazení předpokládané hardwarové architektury. ~ 37 ~

42 5 Výsledky Celý návrh je zpracován pomoci CASE nástroje Enterprise Architect, jež je popsán v metodice práce Diagram případů užití Podle specifikace požadavků na software, zejména funkčních požadavků, byl sestaven diagram případu užití. Jednotlivé případy užití jsou podrobně rozepsány, vysvětleny a u nejdůležitějších z nich jsou uvedeny hlavní a vedlejší scénáře v příloze. Před samotným popisem případů užití je ještě důležité se seznámit s hlavními prvky modelu, tedy aktory. V návrhu případu užití jsou zobrazeni dva primární aktoři Auditor a Administrativní pracovník a jeden generalizovaný aktor nazvaný uživatel, jež zobrazuje průnik společných případů užití pro oba primární aktory. Auditor je aktor, představující prvotně auditora vykonávajícího kontrolu u klienta, jež má v popisu práce veškerou činnost okolo udělování certifikátů. Může také vkládat nové klienty a jakkoli je upravovat a provádět správu kontrol. Administrativní pracovník je aktor, jež využívá systém především ke správě uživatelů, klientů a certifikátů. Nemá právo zakládat či jakkoli upravovat kontroly. Smí jen tisknout dokumentaci a procházet kontroly a hlavně definovat nové auditory. Z provedené analýzy případů užití vyplynuly následující případy užití s krátkým popisem: Vložit nového klienta musí být umožněno vyvolat uživatelem i bez jakékoli předchozí akce. Uživatel vloží všechny požadované údaje o klientovi, jaké jsou název společnosti, IČO, adresa, telefon, kontaktní osobu a kontaktní adresu, registrační číslo GlobalG.A.P., evidenční číslo klienta a poznámku ke klientovi. Všechny pole kromě poznámky musí být vyžadovány povinně a ve vyhovujícím formátu. Pokud bude špatně vyplněno, systém na to uživatele upozorní. Zobrazit detail klienta bude umožňovat zobrazit veškeré informace o evidované o klientovi a všechny kontroly u klienta provedené. Tomuto případu užití musí předcházet provedení případu užití Vyhledat klienta nebo Vybrat klienta ze seznamu. Výsledkem těchto případu užití bude ID klienta, jež bude použito k vyvolání dotazu zobrazení podrobnosti o klientovi. ~ 38 ~

43 5 Výsledky Obr. č. 4 Diagram případu užití Upravit data klienta je případ užití, v němž může uživatel upravit evidované informace o klientovi. Tomuto případu užití musí předcházet případ užití Zobrazit detail klienta, jež zobrazí informace o klientovi. Uživatel pak zvolí v detailu klienta volbu upravit klienta. Poté se zobrazí formulář jako při vkládání nového klienta, jen již předvyplněn doposud uloženými daty o klientovi. Opět bude ověřena formální platnost všech vkládaných dat, a případně proběhne upozornění uživatele. ~ 39 ~

44 5 Výsledky Zahájit novou kontrolu je případ užití auditora, jež se spustí použitím volby zahájit novou kontrolu v detailu klienta, u nějž chceme kontrolu provést. Zobrazí se panel se zaškrtávacími checkboxy v nichž uživatel vybere okruhy prováděné kontroly u klienta. Pro vygenerování sad checklistu zvolí uživatel volbu pokračovat. Systém založí checklisty a zobrazí je uživateli. Otevřít již zahájenou kontrolu se spustí tím, když uživatel vybere v detailu klienta kontrolu, kterou chce zobrazit. Systém načte detaily kontroly a zobrazí checklisty a nastaví již vyplněné data v kontrole. Načíst již uzavřenou kontrolu bezprostředně navazuje na případ užití Otevřít již zahájenou kontrolu tím, že pokud je kontrola již uzavřena nastaví editovatelnost checklistu na false. Tím, uživatel pozbude všechny funkce jako uložení, editace kromě tisku dokumentace. Zobrazit výsledky minulé kontroly je případ užití začínající zvolením volby Zobrazit minulost při vyplňování kontrolních bodů uživatelem. Systém zobrazí formulář, jehož obsahem je hodnocení a komentář tohoto bodu při poslední uzavřené kontrole. Vlož hodnocení z minulé kontroly navazuje na případ užití Zobrazit výsledky minule kontroly, a začíná, když uživatel zvolí volbu vlož. Systém nastaví pro daný kontrolní bod hodnocení a komentář ze zobrazeného formuláře do hodnocení a komentáře příslušného kontrolního bodu. Zobrazení plnění parametrů je rozšiřující případ užit, vždy když uživatel zobrazí kartu info u dané kontroly. Vypíše počty vyplnění jednotlivými hodnotami u každého typu kontrolního bodu podle důležitosti a dále procenta plnění jednotlivých kontrolních bodů. Dále vypíše počet kontrolních bodů, jež nejsou vyplněny, a počet bodů u nich je striktně požadován komentář a není zatím napsán. Zobrazit chybějící komentáře je případ užití, jež rozšiřuje případ užití pracovat na kontrole a začíná, pokud uživatel zvolí tlačítko zobraz u výpisu počtu chybějících komentářů. Systém zobrazí tabulku s výčtem bodů, u nichž není vyplněn řádně komentář a přitom je striktně požadován. Zobrazit nevyplněné body je případ užití, jež rozšiřuje případ užití pracovat na kontrole a začíná, pokud uživatel zvolí tlačítko zobraz u výpisu počtu zatím ~ 40 ~

45 5 Výsledky neohodnocených kontrolních bodů. Systém následně zobrazí tabulku s výčtem bodů, u nějž ještě nebyly ohodnoceny. Uložit kontrolu rozšiřující případ užití vyvolá uživatel, pokud zvolí uložit v panelu info u kontroly. Systém uloží aktuální stav všech checklistů. Dokončit kontrolu navazuje na případ užití pracovat na kontrole, kdy auditor zvolí volbu dokončit kontrolu. Systém ověří splnění všech formálních náležitostí, uloží kontrolní body, nastaví příznak zamknutí a uloží datum uzavření a uživatele, jež kontrolu uzavřel a výsledek kontroly. Pracovat na kontrole je případ užití znázorňující průběh samotné kontroly, kdy auditor si volí zobrazení jednotlivých checklistů a kapitol a do nich vpisuje samotné ohodnocení kontroly a komentář. Pokud auditor zvolí kartu info u kontroly aktivují se případ užití zobrazení splnění parametrů. Pokud zvolí při vyplňování kontrolních bodů volbu minulé hodnocení aktivuje se případ užití Vlož výsledky minulé kontroly. Tisk dokumentace kontroly je případ užití jež reprezentuje volbu tiskových sestav a následný povel tisk. Je vyvolaný volbou tlačítka tisk v panelu info v kontrole. Aktualizovat se serverem je případ užití, jež zajišťuje výměnu dat mezi aplikaci spuštěnou u uživatele s databází centrálního úložiště dat. Je vyvoláno z horního menu. Po spuštění se pokusí přihlásit k databázi. Po úspěšném přihlášení zjistí, zde jsou v aplikaci nové data od poslední aktualizace a případně je vloží do úložiště. Poté ověří, zda na serveru se vyskytují novější data než má v lokální databázi. Pokud ano přepíše data. Dále zjistí, zda se neměnil obsah standardu (zda nebyl aktualizován obsah checklistů) a případně jej změní i u sebe. Po úspěšném proběhnutí se zobrazí hláška o provedených akcích. Vložit nového uživatele je případ užití pouze pro administrativního pracovníka, jež může vložit nového uživatele systému a to jak auditora, tak dalšího administrativního uživatele. Tento případ užití je vyvolán volbou v menu Uživatel -> nový uživatel. Jsou potřebná vložit údaje jako jméno, příjmení, tituly, práva v systému a také prvotní heslo nového uživatele, který by si jej měl při prvním přihlášení změnit. Po úspěšném založení nového uživatele je zobrazena potvrzující hláška. ~ 41 ~

46 5 Výsledky Vypsat seznam uživatelů je dostupný pouze pro administrativního pracovníka a začíná volbou v menu Uživatel > Vypsat seznam. Z databáze je načten a zobrazen seznam uživatelů. Upravit uživatele je případ užití, jež navazuje na Vypsat seznam uživatelů tím, že si administrativní pracovník vybere v seznamu uživatelů uživatele, jemuž chce upravit data či jej deaktivovat a tím mu zamezit přístup k práci s aplikací. Po provedení změny je zobrazena potvrzující hláška. Změnit heslo je případ užití dostupný pro všechny uživatele, kde si mohou změnit své vlastní heslo a je spouštěn z menu Program -> změna hesla. K úspěšné změně musí zadat i současné heslo. Po provedení změny je zobrazena potvrzující hláška. Zobrazit informace o aplikaci je případ užití, kdy systém zobrazí uživateli informace o systému, jako např. verzi produktu, licenční číslo, délka licence, poslední aktualizaci a oprávněného vlastníka. Nejdůležitější hlavní a některé vedlejší scénáře případů užití jsou uvedeny v příloze práce Diagram tříd Diagram tříd zobrazuje statickou strukturu aplikace. Zahrnuje třídy a vztahy mezi nimi. Struktura tříd je tvořena atributy a operacemi. Při návrhu jednotlivých tříd bylo striktně dbáno na oddělení aplikační logiky software od prezentační. Struktura navrhované aplikace je zobrazena v diagramu tříd na Obr. 7. Operace třídy znázorňující metody třídy jsou zde pro přehlednější zobrazení uvedeny bez vstupních parametrů, neboť některé metody a zvláště konstruktory mají velké množství vstupních hodnot. V diagramu zde nejsou také uvedeny jednotlivé konstruktory třídy, neboť jejich název je vždy název třídy. Za každou metodou je zaznačen typ výstupní hodnoty metody. Aplikace Globalgap manager se skládá z 13 tříd, z toho jsou 4 boundery třídy. Jež slouží jako spojeni s databázi a grafické uživatelské rozhraní, které má za úkol jen zobrazovat atributy tříd ke komunikaci s uživatelem a umožnit mu zadávat hodnoty a ovládat běh aplikace. ~ 42 ~

47 5 Výsledky Obr. č. 5 Diagram tříd ~ 43 ~

48 5 Výsledky Hlavní třídou programu je třída GlobalgapManagerApp, jež reprezentuje běh programu. A uchovává informace kdo je k aplikaci přihlášen, a s čím v aplikaci pracuje, což pak slouží ke zpětné dohledatelnosti jednotlivých změn v datech aplikace. Tato třída inicializuje také komunikaci s databází pomocí boudery třídy Databaze, jež zajišťuje vytvoření spojení a komunikaci s databází. Pro komunikaci s centrálním úložištěm dat, se vytvoří také instance třídy Databaze jen s odlišnými parametry v konstruktoru třídy. Třída Uzivatel je určena pro reprezentaci uživatele, jež pracuje s aplikací. Její instance je vytvořena ihned při přihlášení uživatele, přičemž je ověřen jeho status. Heslo je standardně hashované pro větší bezpečnost komunikace. Tato instance provází uživatele celým během aplikace. Obsahuje, zda uživatel je aktivní, má přístup k programu, a zda je Auditor, či Administrativní pracovník. Třída Klient reprezentuje klienta se všemi jeho atributy, jež jsou požadovány pro archivaci v systému včetně seznamu všech již vykonaných kontrol. Třída Kontrola reprezentuje kontrolu vykonávanou u klienta, jejichž částmi jsou instance třída Checklist obsahuje informace definující daný checklisty z nichž se skládá kontrola. Zobrazením této třídy v grafickém uživatelském rozhraní je boudery třída ChecklistJP. Kapitola je třída obsahující doplňující informace jednotlivých kapitol daného checklistu a jednotlivé kontrolní body, jež jsou vyjádřeny třídou KontrolniBod. Kontrolní bod obsahuje text kontrolního bodu, kritérium shody, důležitost bodu, číslo bodu a minulý a aktuální výsledek vyjádřený instancemi třídy Vysledek. Třída Vysledek reprezentuje konkrétní hodnoty ohodnocení kontrolního bodu a to ohodnocením a komentářem. Dále je součásti třídy odkaz, ke které kontrole a kontrolnímu bodu se výsledek vztahuje. Tyto třídy jsou ke komunikaci s uživatelem reprezentovány třídou KapitolaJP. Třída Tisk představuje aktuální tiskovou sestavu a uchovává informace o průběhu tisku jednotlivých sekcí Stavový Diagram Stavový diagram popisuje dynamický model jednotlivých objektů. Na obrázku č. 6 je uveden stavový diagram objektu, jež nabývá nejvíce stavů a to objekt kontrola. Ostatní objekty jsou poměrně triviální a mohou nabývat většinou jeden či maximálně dva stavy. Objekt kontrola může nabývat 3 možné stavy: Založena kontrola Otevřená kontrola určená k vyplnění Hotová uzamčená kontrola ~ 44 ~

49 5 Výsledky Události, které způsobují přechod mezi jednotlivými stavy objektu, jsou operace třídy zobrazitkontrolu() a dokoncitkontrolu(aktuzivatel). Obr. č. 6: Stavový diagram objektu kontrola Diagramy aktivit Každý diagram aktivit se věnuje průběhu jednotlivých případu užití, u kterých znázorňuje postup jednotlivých akcí, jež se mohou vykonat při průběhu případu užití. V diagramu jsou znázorněny posloupnosti jednotlivých akcí a podmínky pro přechod mezi nimi. Na obrázku č. 9 je zobrazen nejsložitější a také nejpodstatnější úkon softwaru, jež je reprezentován případem užití Ukončit kontrolu. Samotnému případu užití Ukončit kontrolu musí předcházet mnoho dalších případu užití, jak je vidno v diagramu případu užití na obrázku č. 9. Prvotním impulzem k provedení tohoto případu užití je aktivita auditora, jež musí nejprve zobrazit detail klienta, u nějž chce provést kontrolu. Tato aktivita je rozebrána na obrázku č. 10. V detailu klienta auditor může zvolit buď založit novou kontrolu anebo otevřít již zahájenou kontrolu vybráním ze seznamu kontrol u klienta. ~ 45 ~

50 5 Výsledky Obr. č. 9: Diagram aktivity Dokončit kontrolu ~ 46 ~

51 5 Výsledky Pokud zvolí založit novou kontrolu, následuje akce založit novou kontrolu. Dále následuje akce zobrazit splnění parametru, jež nastaví v panelu Info informace o plnění formálních požadavků a procenta vyplnění a přichází se do aktivity pracovat na kontrole, která je dále rozebrána na obrázku č. 11. Pokud zvolí v detailu klienta volbu otevřít již zahájenou kontrolu, načte se již vytvořená kontrola z databáze. Pokud je kontrola již dokončena a uzavřena či uživatel nemá oprávnění auditora, který jediný smí upravovat parametry kontroly, zobrazí se uživateli kontrola pouze pro čtení, bez možnosti editace. Pokud není dokončena a uživatel je auditor, přejde se na podaktivitu pracovat na kontrole. Jakmile tato aktivita skončí, jsou ověřeny splněny formální požadavky na kontrolu, pokud nejsou splněny je uživatel zpět navracen na aktivitu pracovat na kontrole. Pokud jsou splněny, je provedena akce Uložit kontrolu, jež uloží získané výsledky do databáze. Poté je uživatel vyzván, aby potvrdil, zda chce kontrolu dokončit a zamknout ji. Po potvrzení kontrola nastaví příznak dokončena na true a akce je skončena. Obr. č. 10: Diagram aktivity Zobrazit klienta ~ 47 ~

52 5 Výsledky Diagram na obrázku č. 10 znázorňuje aktivitu zobrazit klienta, jež má zobrazit kartu klienta. Na začátku musí zvolit uživatel způsob, kterým vybere klienta, jehož detail chce zobrazit. Pokud zvolí vybrat klienta ze seznamu, bude vypsán seznam klientů, z něhož vybere uživatel jednoho, u nějž se zobrazí jeho informace v kartě klienta. Pokud uživatel zvolí vyhledat klienta aktivita pokračuje akcí vyhledat klienta, kdy uživatel zadá klíč podle nějž chce najít požadovaného klienta a následně je zobrazena jeho karta s detailem. Aktivita pracovat na kontrole, jež je zobrazena diagramem na obrázku č. 11 znázorňuje samotnou práci s kontrolou při vyplňování jednotlivých kontrolních bodu checklistů. Obr. 11: Diagram aktivity Pracovat na kontrole ~ 48 ~

53 5 Výsledky Sekvenční diagram Obecně sekvenční diagram zobrazuje v časové posloupnosti interakci objektů v jednotlivých případech užití. Z důvodu omezení rozsahu této práce jsou zde uvedeny jen tří sekvenční diagramy. V prvním z nich na obrázku č. 12 je zobrazena sekvence interakcí znázorňující Administrativního pracovníka při práci s uživateli. V modelu případu užití to je reprezen-továno případy užití Přidat uživatele a Upravit uživatele. Nejprve je znázorněna sekvence přidání uživatele, která začíná volbou administrativního pracovníka zobrazit form nového uživatele, poté vyplní daty uživatele formulář a odešle. Následně je založen nový objekt uživatel. Zde v diagramu v parametrech konstruktoru byly nahrazeny jednotlivé parametry souslovím data uživatele. Uživatel je nyní uložen do databáze metodou UlozUzivatele a následně je v GUI zobrazen seznam uživatelů Obr. č. 12: Sekvenční diagram přidání uživatele Druhý zde zobrazený případ užití týkající se operace s uživatelem je upravit data uživatele a je vyobrazen v diagramu na obrázku č. 13. Tato sekvence interakcí začíná pokynem Administrativního pracovníka k zobrazení seznamu uživatelů. GUI následně zobrazí seznam uživatelů. Administrativní pracovník vybere uživatele, jehož data chce upravit. GUI zavolá metodu uživatele vypispodrobnosti s parametrem ID uživatele, jež vrátí všechny parametry uživatele v polích řetězců a následně zobrazí uživatele. Administrativní pracovník upraví údaje uživatele a odešle. GUI zavolá metodu updatedata s parametry dat uživatele zde pro zjednodušení nazvanými jako data uživatele. Nové informace se vloží pomocí metody ulozupdate. A GUI následně zobrazí seznam uživatelů. ~ 49 ~

54 5 Výsledky Obr. č. 13: Sekvenční diagram upravit data uživatele Posledním zde vyobrazeným sekvenčním diagramem je na obrázku č. 14 diagram reprezentující poměrně netriviální případ užití Založit novou kontrolu. Sekvence tohoto případu užití začíná zobrazením seznamu klientů, z nichž auditor vybere jednoho z nich, s nímž chce dále pracovat. Následuje zobrazení detailu klienta, kde auditor zvolí Založit novou kontrolu. GUI zobrazí formulář volba obsahu kontroly, kde uživatel vybere checklisty, jež budou při kontrole u klienta hodnoceny. Systém založí kontrolu a její checklisty v cyklu dle jejich výběru. V každém checklistu budou založeny kapitoly a v každé kapitole i jednotlivé kontrolní body a jejich výsledky. Po fyzickém založení kontroly je vyžádán obsah kontroly v GUI a jsou založeny jednotlivé zobrazení checklistu a v nich opět založeny jednotlivé zobrazení kapitol s nastavením všech náležitostí. ~ 50 ~

55 5 Výsledky Obr. č. 14: Sekvenční diagram založení kontroly ~ 51 ~

56 5 Výsledky Diagram nasazení Diagram nasazení zobrazuje jak fyzický hardware, tak způsob nasazení samotného softwaru na užitý hardware, jež je potřebný pro správný běh aplikace Globalgap Manager. Diagram nasazení pro aplikaci Globalgap Manager je znázorněn na obrázku č. 15. Aplikace je složena ze dvou uzlů PC a Server. Nejpodstatnějším uzlem systému je uzel PC, na němž je spuštěn samotný softwarový klient Globalgap Manager. PC je lokální, ve své podstatě přenosný, počítač. Globalgap Manager potřebuje pro své nasazení komponentu Java Runtime Enviroment, což vyplývá ze zvoleného způsobu implementace v jazyku Java. Aby byla aplikace plně funkční a nezávislá na centrálním datovém úložišti a uspokojila tím nefunkční požadavek přenositelnosti a plné funkčnosti i bez možnosti připojení k centrálnímu datovému skladu při kontrole u klienta, musí být na lokálním PC také spuštěna databáze MySQL, která potřebuje ke svému běhu server, zde zvolený Apache. Globalgap manager je samostatně plně funkční software. Druhý uzel je vzdálený server sloužící jako centrální úložiště dat tvořeno serverem, se spuštěnou databázi MySQL. K tomuto zařízení se bude uživatel připojovat v době, kdy bude připojen ke stejné počítačové síti jako server, přes svého klienta, který bude zajišťovat výměnu dat a aktualizací s centrální databází pomocí šifrovaného protokolu HTTPS. Obr. č. 15: Diagram nasazení ~ 52 ~

57 5 Výsledky Datový model Datový model plně vychází z modelu tříd, přičemž se respektuje počet a struktura tříd v programu a počet jednotlivých entit. Z modelu tříd jsou převedeny jenom atributy bez funkčnosti, které nejsou v entitách reprezentovány. Do modelu jsou dále přidány některé sekundární klíče, jež jsou v modelu tříd reprezentovány jako seznam těchto tříd v protější třídě. V datovém modelu jsou jednoznačně pojmenovány názvem odkazované tabulky a příznakem na konci _ID a datovým typem BIGINT. Kvůli implementaci v relační databázi je tento model zde vyjádřen v entitněrelačním diagramu na Obr. č. 16. Obr. č. 16: Datový model ~ 53 ~

58 5 Výsledky 5.3 Výsledná implementace Vyvíjená aplikace, pracovně pojmenovaná Globalgap manager, je naimplementována v programovacím jazyce Java a datová základna byla definována pomoci SQL jazyku, na základě výsledků dosažených v návrhové části této práce. Jazyk Java byl zvolen pro jeho výhody, jež jsou uvedeny v metodice práce. Samotná implementace probíhala ve vývojovém prostředí Netbeans IDE 6.5, které bylo popsáno taktéž v metodice práce. Vzhled grafického uživatelského rozhraní byl navržen také v prostředí Netbeans IDE 6.5, přičemž byly respektovány požadavky zejména na přehlednost a jednoduchost ovládání a byly použity komponenty knihovny swing pro tvorbu grafického uživatelského rozhraní, která respektuje individuální nastavení operačního systému uživatele. Po spuštění aplikace se nejprve objeví dialogové okno pro přihlášení uživatele do systému. Po úspěšném přihlášení se uživateli zobrazí prázdné hlavní okno aplikace, v němž jsou v hlavní liště menu na hoře na výběr další akce ze skupin: aplikace, jež zahrnují informace o aplikaci, přihlášeném uživateli a možnost aktualizace či změna hesla pro uživatele; klient, v němž jsou možnosti správy klienta, jako vložit nového klienta, vypsat seznam evidovaných klientů, či vyhledat jednotlivé klienty; uživatel, je dostupný pouze pro uživatele s oprávněním administrativního pracovníka, v této skupině může oprávněny uživatel spravovat uživatele aplikace. Na obrázku č. 17 je ukázka zobrazení seznamů uživatelů a formuláře pro editaci údajů uživatele. Zobrazení informací o klientovi je ukázáno na obrázku č. 18. Jsou zde vidět veškeré uchovávané informace o klientovi i se seznam kontrol, jež byly v minulosti u klienta provedeny a jejichž obsah lze načíst kliknutím myši na danou kontrolu. Dále tato karta nabízí volbu upravit uživatele a zahájit novou kontrolu u klienta. Pokud uživatel zahájí novou kontrolu, zobrazí se volba checklistů, jež budou kontrolovány u klienta. A poté bude plně založena nová kontrola. Uživateli se zobrazí nejdříve souhrnný přehled v panelu Info o kontrole. Vzhled tohoto panelu je zobrazen na obrázku č. 19. Panel obsahuje souhrnné informace o dané kontrole, jako celkový počet dosud nevyplněných bodů, počet chybějících komentářů u hodnocení NO a N/A, procentní zastoupení jednotlivých kategorií hodnocení a zda jsou či nejsou splněny všechny formální náležitosti pro dokončení kontroly. Zároveň je zde k dispozici volba uložit, jež uloží rozpracovanou kontrolu, kterou je možné později ~ 54 ~

59 5 Výsledky znova načíst a pokračovat dále v kontrole. Je zde také volba pro dokončení kontroly, jež má za následek trvalé uzamčení kontroly. Taková kontrola není již dále upravovatelná a je případně zobrazena pouze pro čtení a tisk dokumentace. Dále je možné z této karty zobrazit seznam kontrolních bodů, jež nejsou dosud vyplněny či nemají vyplněny komentář, i když je striktně vyžadován. Tyto seznamy mohou zůstat otevřeny i při práci s vyplňováním checklistů, nejsou totiž závislé na hlavním okně. Obr. č. 17: Seznam uživatelů a detail vybraného uživatele ~ 55 ~

60 5 Výsledky Obr. č. 18: Detail klienta Obr. č. 19: Info ke kontrole Dále může uživatel volit mezi jednotlivými panely obsahu kontroly a vyplňovat kontrolní body, jak je vidět na obrázku č. 20. Pro zobrazení hodnocení u poslední kontroly provedené u klienta slouží volba ukaž minulé hodnocení u jednotlivých kontrolních bodů. Tyto hodnoty jsou zobrazeny v dialogovém okně a je možné jejich použití pro vyplnění kontrolního bodu. Nasazení software do provozu u certifikační organizace musí být provedeno zkušenějším IT technikem organizace, neboť instalace a korektní příprava dat vyžaduje ~ 56 ~

61 5 Výsledky vyšší než uživatelskou dovednost. Nejprve je nutné vytvořit databázi na serveru, importovat strukturu tabulek a předpřipravená data checklistů a založení hlavního administrativního pracovníka. Na uživatelském PC je nutné nainstalovat databázový server a vytvořit prázdnou databázi Globalgap. Je také potřebné nainstalovat JRE pokud jej uživatel na PC nemá. Pak již stačí spustit poprvé aplikaci na PC připojeném k centrálnímu úložišti dat reprezentovaného již nainstalovaným a spuštěným databázovým serverem. Aplikace si stáhne potřebné aktualizace a vytvoří strukturu tabulek a dat a již je umožněn běžný provoz aplikace. ~ 57 ~

62 5 Výsledky Obr. č. 20: Otevřený checklist ~ 58 ~