Funkční specifikace projektu. Online centrála ČJF

Příloha č.2 k výběrovému řízení projektu “Online centrála ČJF”

Funkční specifikace projektu

Online centrála ČJF

Obsah dokumentu:

1. Účel projektu a zúčastněné osoby ................................................................................ 3

1.1. Účel produktu .................................................................................................................................. 3 1.2. Stávající a nové řešení ...................................................................................................................... 3 1.3. Dodavatel, zákazník ......................................................................................................................... 3 1.4. Uživatelé produktu ........................................................................................................................... 3

2. Projektová omezení a předpoklady ............................................................................... 3

2.1. Omezení v oblasti řešení .................................................................................................................. 3 2.2. Partnerské aplikace .......................................................................................................................... 4 2.3. Etapy projektu a předpokládané časování ........................................................................................ 4 2.3.1 I. etapa -‐ Analýza ................................................................................................................................. 4 2.3.2 II. etapa -‐ Implementace ..................................................................................................................... 5 2.4. Jmenné konvence a definice ............................................................................................................. 5 2.5. Relevantní skutečnosti a předpoklady .............................................................................................. 6

3. Funkční požadavky a moduly ........................................................................................ 7

3.1. Rozsah prací ..................................................................................................................................... 7 3.1.1 I. etapa -‐ Analýza ................................................................................................................................. 7 3.1.2 II. etapa -‐ Implementace ..................................................................................................................... 7 3.2. Moduly produktu ............................................................................................................................. 7 3.2.1 Jádro aplikace ..................................................................................................................................... 7 3.2.1.1 Databázové struktury ...................................................................................................................... 7 3.2.1.2 Úvodní obrazovka a přihlášení do administrace .............................................................................. 7 3.2.1.3 Nastavení a definice číselníků .......................................................................................................... 7 3.2.2 Správa členů pro sekretariát ............................................................................................................... 8 3.2.2.1 Oblasti .............................................................................................................................................. 8 3.2.2.2 Subjekty ........................................................................................................................................... 8 3.2.2.3 Osoby ............................................................................................................................................... 9 3.2.2.4 Koně ................................................................................................................................................. 9 3.2.2.5 Vzdělávání ........................................................................................................................................ 9 3.2.3 Soutěže a výsledky ............................................................................................................................ 10 3.2.5 Účetnictví a online platby ................................................................................................................. 11 3.2.6 Tiskové sestavy ................................................................................................................................. 11

Stránka 1 z 16


4. Nefunkční požadavky .................................................................................................... 12

4.1. Požadavky na vzhled a dojem ......................................................................................................... 12 4.2. Požadavky na uživatelnost ............................................................................................................. 12 4.3. Požadavky na výkon ....................................................................................................................... 12 4.4. Požadavky na provoz ...................................................................................................................... 12 4.5. Požadavky na bezpečnost ............................................................................................................... 12 4.6. Požadavky na neprodukční prostředí a release management ......................................................... 13 4.7. Právní požadavky ........................................................................................................................... 13 4.8. Dokumentace ................................................................................................................................. 13 4.8.1 Uživatelská ........................................................................................................................................ 13 4.8.2 Administrátorská .............................................................................................................................. 14 4.8.3 Dokumentace v kódu ........................................................................................................................ 14

5. Projektové otázky .......................................................................................................... 14

5.1. Otevřené otázky ............................................................................................................................. 14 5.2. Použitá standardní řešení ............................................................................................................... 15 5.3. Nové problémy .............................................................................................................................. 15 5.4. Přepnutí systému ........................................................................................................................... 15 5.5. Rizika ............................................................................................................................................. 15 5.6. Náklady a plnění ............................................................................................................................ 15 5.7. Školení uživatelů ............................................................................................................................ 16 5.8. Další požadavky na další rozvoj produktu, který není součástí stanoveného rozsahu prací ............. 16

Stránka 2 z 16


1. Účel produktu a zúčastněné osoby 1.1. Účel produktu Účelem produktu je vytvořit nové jádro softwarového zázemí pro Českou jezdeckou federaci (ČJF), tedy sportovní svaz zastřešující jezdecký sport a jezdectví obecně. Výsledný produkt by měl pokrýt základní potřeby administrace členské základny, sportovních licencí, koní, klubů, soutěží a uchovávání výsledků.

1.2. Stávající a nové řešení V současné chvíli existuje produkt s názvem Centrála ČJF pocházející z let 2001-‐2003, který sice funkčně pokrývá většinu požadovaných oblastí, ale je technologicky značně zastaralý (FOXPRO 1999) a není možné jej již dále funkčně ani provozně rozvíjet. Stávající produkt má velmi omezené komunikační kanály pro integraci s dalšími produkty a online světem a navíc jej lze instalovat již pouze na nepodporované operační systémy, čímž se celé řešení stává zranitelné a náchylné k neoprávněným manipulacím s daty. Nové řešení by nemělo pouze slepě zkopírovat funkčnosti řešení stávajícího do nových technologií, ale i pomoci změnit stávající procesy uvnitř organizace a především by mělo s určitým vizionářským pohledem umožnit další rozvoj s ohledem na rozvoj technologií.

1.3. Dodavatel, zákazník Zákazníkem je v tomto případě sportovní svaz Česká jezdecká federace (dále jen ČJF), která zajistí součinnost od volených zástupců či zaměstnanců pro zpracovatele analýzy i vlastní implementace, testování a pilotního provozu. Zúčastněnými osobami (Stakeholders) za zákazníka bude jako vlastník produktu (Product Owner) IT Komise ČJF a dále VV ČJF, Sekretariát ČJF a vybraní uživatelé systému (sekretář, klub). Dodavatel bude vybrán na základě vypsaného výběrového řízení. V jednom spojeném výběrovém řízení budou poptávány dvě samostatné nabídky – první na analýzu a druhá na implementaci. Zákazník si ponechává právo vybrat pro každou fázi jiného dodavatele.

1.4. Uživatelé produktu Uživateli produktu budou • Zaměstnanci sekretariátu ČJF -‐ plný přístup k funkcionalitám aplikace, možnost korekce / úpravy zadaných dat, v některých krocích schválení (validace) kroků od jiných uživatelů • Oblastní sekretáři -‐ přístup k editaci údajů koní, klubů, jezdců a členů, prodlužování sportovních licencí a členských poplatků všech členů, generování plateb, veškeré read/only operace • Zástupci klubů -‐ přístup k prodlužování licencí klubů, koní a jezdců, správa členů pro svůj vlastní klub, generování předpisů plateb, online platby • Pořadatelé závodů, zpracovatelé výsledků -‐ přístup do sekce závodů s možností načítání údajů o jezdcích, koních a klubech, odesílání výsledků • Veřejnost -‐ přístup k údajům centrály přes dynamický obsah webových stránek (členové, kariéry, výsledky, funkcionáři…), žádosti o registraci klubu

2. Projektová omezení a předpoklady 2.1. Omezení v oblasti řešení Aplikace by měla být postavena jako webová aplikace s tzv. tenkým uživatelským rozhraním v běžném internetovém prohlížeči. Musí podporovat všechny běžné internetové prohlížeče (Safari, Chrome, Firefox, Opera, Internet Explorer => 10), včetně mobilních platforem.

Stránka 3 z 16


V použitých technologiích je v této fázi nechána volba na budoucího dodavatele. Upřednostňujeme však, aby aplikace byla multiplatformní tedy serverová část mohla být instalována na platformách Windows i Unix a běžela na standardně poskytovaném hostingu. V případě použití hotových frameworků je nutné používat pouze open-‐source řešení, ke kterým existuje dostatečná vývojářská dokumentace tak, aby další rozvoj aplikace mohl realizovat někdo jiný, než dodavatel řešení. Veškeré zdrojové kódy musí být v majetku ČJF. Přenosy dat mezi serverem a klientem by měly být ve standardním formátu JSON. Veškerá vystavená rozhraní pro aplikace třetích stran by měla být REST API ve formátu JSON s výjimkou rozhraní aplikací mimo ČJF, kde jsme povinni dodržet formát poskytovatele služby. Samotná API musí být zabezpečena tak, aby jich využívání mohlo být regulováno smluvním vztahem mezi uživatelem a ČJF. Ke všem API musí existovat veřejně dostupná dokumentace včetně návodu na implementaci obsahující popis samotného rozhraní, business pravidla, validační pravidla a další informace nutné k implementaci systému využívajícího API.

2.2. Partnerské aplikace V aplikaci musí být zajištěna komunikace se systémy: Gallop -‐ software pro zpracování výsledků soutěží dodaný firmou ACE Design, s.r.o. -‐ bude nutné jednat s ACE Design, aby komunikaci s centrálou uzpůsobila novým API Online přihlašovací systém -‐ software dodaný firmou ACE Design, s.r.o. sloužící k online přihlašování na závody ČJF -‐ bude nutné jednat s ACE Design, aby komunikaci s centrálou uzpůsobila novým API WEB ČJF -‐ dynamický obsah webu ČJF by měl být plněn z databáze nové centrály -‐ bude nutné jednat s ACE Design, aby komunikaci s centrálou uzpůsobila novým API Koduk -‐ software dodaný firmou ACE Design, s.r.o. sloužící k odesílání kumulovaných výsledků koní na UEK a přípravě tištěné podoby ročenky “Přehled o sportovních koních”. Tato aplikace by měla být plně nahrazena a její funkčnost implementována v tomto projektu. Ekonomický software Pohoda -‐ software, na kterém vede ČJF své účetnictví -‐ API Pohody jsou popsány dodavatelem a je nutné se na ně napojit UEK -‐ software pro evidenci koní -‐ aplikace mimo kontrolu ČJF, zatím DOS s problematickým přístupem k datům, UEK vyvíjí nové řešení, nutné se s ním synchronizovat JockeyClub ČR -‐ zatím nejsou známy možnosti získávání dat o koních z této databáze Mobilní aplikace -‐ zatím neexistují, ale systém musí počítat s tím, že některé z modulů přístupné klubům či jezdcům budou v budoucnu přístupné prostřednictvím mobilních aplikací a je zde třeba nechat otevřenou cestu Brána pro Online platby -‐ součástí celého řešení by měla být i možnost přímé platby členských příspěvků, licencí a dalších služeb pomocí platební brány (platební karty, online bankovní platby, PayU, PayPal apod…) Rejstříky (ARES, DPH…) -‐ kontroly správnosti údajů u subjektů (plátců) ČUS, ČOV -‐ dokládání registr. členů, nutno zanalyzovat možnost komunikace a synchronizace členů

2.3. Etapy projektu a předpokládané časování 2.3.1 I. etapa -‐ Analýza Analýza by měla začít bezprostředně po výběru dodavatele a předpokládané dodání, včetně vyjasnění většiny otevřených otázek kolem procesů a funkčností by neměla přesáhnout 2 měsíce. Analýza by měla být výchozím dokumentem pro dodavatele implementace a měla by být v takové

Stránka 4 z 16


kvalitě, aby následnou implementaci mohl realizovat jiný dodavatel, než ten, který vypracoval analýzu. 2.3.2 II. etapa -‐ Implementace Implementační etapa bude rozdělena do těchto fází: • Preimplementační fáze -‐ výstup: detailní technická specifikace dodávaného řešení -‐ vyjasnění technologií, výběr konkrétních umístění produktu, programovacích jazyků, frameworků, databází a zabezpečení. Vše je nutné řešit a konzultovat se zástupcem objednatele. • Implementační fáze -‐ výstup: samotný produkt připravený pro akceptaci. Dodávka bude probíhat po etapách, po jednotlivých funkčních celcích (modulech) s průběžným předáváním a funkční ukázkou na neprodukčním prostředí. Termíny pro jednotlivé etapy budou stanoveny na základě analýzy. • Akceptační fáze -‐ výstup: funkční aplikace připravena pro pilotní provoz včetně předávky zdrojových kódů a dokumentace v dohodnutém rozsahu. Akceptační fáze by neměla trvat déle než jeden měsíc a předpokládaný počátek je 2. polovina 2016. Akceptační fáze bude ukončena na základě předem stanovených akceptačních kritérií, mj. aplikace musí být bez blokujících a kritických chyb. • Pilotní provoz -‐ výstup: funkční, uživatelsky otestovaná aplikace připravená pro plný provoz. Pro objednatele je velmi důležité, aby aplikace byla schopna vstoupit do plného provozu počátkem registračního období pro rok 2017, tedy nejpozději k 1.1.2017.

2.4. Jmenné konvence a definice Česká jezdecká federace (ČJF) -‐ Národní federace, resp. sportovní svaz, zastřešující jezdecký sport v České republice. Právní forma spolek (dříve občanské sdružení). Člen Mezinárodní jezdecké federace (FEI), Českého olympijského výboru (ČOV) a České Unie sportu (ČUS). Ústřední evidence koní (UEK) -‐ organizace pověřená státem, která ze zákona vede evidenci o všech koních na území České republiky, vyjma plemene Anglický plnokrevník. Jockey Club ČR -‐ organizace pověřená státem, která ze zákona vede evidenci koní plemene Anglický plnokrevník. Generální sekretář ČJF (GS) -‐ zaměstnanec ČJF, hlavní kontaktní osoba pro veřejnost na centrále ČJF. Sekretariát ČJF -‐ zaměstnanci na centrále ČJF, podřízení GS. Prezident ČJF -‐ statutární orgán ČJF, jenž řídí činnost spolku a jedná jeho jménem. Volená funkce. Výkonný výbor ČJF (VV) -‐ pětičlenné nejužší vedení ČJF, volené funkce. Oblast -‐ regionální zastoupení ČJF (celkem 12 oblastí) s vlastními pravomocemi a rozpočtem. Oblastní výbor -‐ volení zástupci zastupující konkrétní oblast. Oblastní sekretář -‐ zaměstnanec ČJF, liniově podléhající Generálnímu sekretáři, hlavní kontaktní osoba na oblasti zajišťující základní servis pro členy, jezdce a kluby (subjekty). Registrovaný subjekt (klub) -‐ právnická či fyzická osoba s právní subjektivitou přímo registrovaná pod ČJF v určité oblasti. Člen ČJF -‐ jakákoli fyzická či právnická osoba, která prostřednictvím Registrovaného subjektu zaplatí členský příspěvek ČJF. Fyzická osoba nepodnikající (bez právní subjektivity) nemůže být členem ČJF na přímo, pouze prostřednictvím Registrovaného subjektu. Jezdecká licence -‐ doklad opravňující člena ČJF startovat v soutěžích na Oficiálních závodech. Licence koně -‐ doklad opravňující přihlásit koně v soutěžích na Oficiálních závodech. ZZVJ -‐ zkoušky základního výcviku jezdce -‐ zkouška na jejímž základě je vydána Jezdecká licence. První úroveň vzdělání. Jezdec -‐ člen ČJF, který složil ZZVJ a vlastní jezdeckou licenci.

Stránka 5 z 16


Hobby jezdec -‐ člen ČJF bez platné jezdecké licence pro příslušný rok účastnící se hobby soutěží Oficiální závody -‐ závody řádně schválené ČJF z nichž se evidují a publikují výsledky jezdců a koní. Hobby soutěž / závody -‐ soutěž / závody, na kterých mohou startovat jezdci a koně bez licencí. Z takových závodů / soutěží se neshromažďují informace o výsledcích. Hobby soutěže je možné vypsat i v rámci Oficiálních závodů. Je však nutné evidovat starty Hobby jezdců v takových soutěžích (tzv. Aktivní člen) z důvodů dotací. Hobby soutěže slouží především jako příprava začínajících jezdců k ZZVJ a mladých koní v začátku jejich sportovní kariéry. Funkcionář -‐ člen ČJF s příslušným vzděláním opravňujícím jej vystupovat na závodech v roli rozhodčího, stavitele tratí/parkurů, komisaře závodů. Refreshment -‐ pravidelné kontinuální vzdělávání pro funkcionáře, instruktory a trenéry bez něhož nemohou vykonávat svou funkci. Instruktor (dříve cvičitel) / Trenér -‐ člen ČJF s příslušným vzděláním opravňujícím jej trénovat jezdce a koně. Instruktor je prvním stupněm tohoto vzdělání, trenér je vyšším stupněm. Zkušební komisař -‐ člen ČJF s příslušným vzděláním vybraný VV ČJF k vykonávání role zkoušejícího v systému vzdělávání ČJF. Galops** -‐ víceúrovňový vzdělávací systém přebraný z Francouzské národní federace (zatím neimplementovaný, je s ním třeba do budoucna počítat, měl by nahradit současné ZZVJ). Kategorizace jezdců -‐ systém výkonnostních kategorií jezdců opravňující jezdce startovat v určité obtížnosti soutěží dle dosažené kategorie. Pro přestup a sestup jsou definována kritéria (zatím neimplementovaný, je s ním třeba do budoucna počítat).

2.5. Relevantní skutečnosti a předpoklady S ohledem na vývoj chování uživatelů internetu se dá předpokládat, že v budoucnu budou mobilní zařízení zaujímat stále vyšší podíl na přístupech k informacím a obsluze internetových aplikací. Je tedy nutné, aby část aplikace určená pro subjekty a veřejnost, byla dobře obslužitelná přes mobilní zařízení. Zájem veřejnosti o jezdecký sport každým rokem roste a díky skutečnosti, že se začíná dlouhodobě dařit i českým jezdcům na mezinárodní scéně a jezdectví proniká do médií, dá se předpokládat stále větší nárůst zájmu o tento sport. Tedy více jezdců, koní a především soutěží. S tím je třeba počítat při návrhu aplikace. Velká část financování provozu ČJF je z dotací. Pro získání dotací musí svaz předkládat požadovaná data, např. o počtu aktivních členů, tedy členů, kteří se účastní jezdeckých závodů. Doposud ČJF sbírala data pouze o členech (jezdcích) s jezdeckou licencí účastnících se oficiálních závodů. Nicméně značná část členské základny se účastní hobby závodů a nově bude nutné umět doložit počty jejich počty. Proto by nový systém měl umožnit evidenci kdy byl který člen účastníkem hobby závodů, nadále nebudeme z hobby závodů zpracovávat výsledky, jde pouze o evidenci samotné účasti. Nyní je v ČJF značná roztříštěnost používaného software, který spolu buď vůbec nekomunikuje, nebo jen velmi obtížně a složitě. Jedna z takových externích aplikací je aplikace Koduk, jejíž funkcionalitu by bylo vhodné zakomponovat jako jeden z výstupů Online centrály. V datovém modelu je v každém případě třeba počítat s tím, že data exportovaná programem Koduk (tedy do UEK a pro sportovní ročenku) je třeba řídit pomocí různých příznaků. Vzhledem k narůstajícímu množství jezdců, je dlouhodobě neudržitelné neschválení tzv. Kategorizace jezdců, která již byla pro některé disciplíny navržena. Systém musí být na tuto skutečnost připraven.

Stránka 6 z 16


3. Funkční požadavky a moduly 3.1. Rozsah prací Chyby a změnové požadavky budou řízeny pomocí bug-‐trackingového nástroje (např. JIRA). Tento nástroj zřídí dodavatel a objednatel dostane smlouvou definovaný počet přístupů. 3.1.1 I. etapa -‐ Analýza Po obsahové stránce musí analýza obsahovat jednak popis tzv. “případů užití” resp. “Use Cases", doménový a datový model na úrovni sloupců v tabulkách, návrh rolí a číselníků, návrh tiskových sestav a vstupně výstupních rozhraní pro komunikaci s okolními systémy. Součástí této fáze by měla být i detailní dopadová analýza na všechny partnerské aplikace. 3.1.2 II. etapa -‐ Implementace Dodávka samotné aplikace musí probíhat přírůstkově po funkčních celcích (níže po modulech). Předávka každého modulu bude provedena formou instalace dodávky do neprodukčního (akceptačního) prostředí a funkčnost bude předvedena formou „dema“ pro zástupce objednatele. Objednatel do stanoveného termínu provede akceptační testy částečné dodávky. Součástí každé dodávky musí být i uživatelská dokumentace. Následně proběhne částečná akceptace dodávky a bude vystaven akceptační protokol s připomínkami a výhradami, které bude nutné odstranit do následující dodávky.

3.2. Moduly produktu 3.2.1 Jádro aplikace První část dodávky by měla obsahovat kompletní jádro samotné aplikace se základními funkčnostmi administrace celé aplikace. Součástí úvodní dodávky je i představení celého designu (GUI) a způsobu a principů ovládání aplikace, návrh přepínání mezi moduly a jejich provázanosti. Tato fáze je důležitá, neboť zde dojde k vyjasnění mnoha otázek, předejde se tak případným nedorozuměním a předpokládá se, že z této fáze vzejde řada zásadních připomínek či změn k zapracování. Měl by zde být zafixován standard ovládání a designu. 3.2.1.1 Databázové struktury Úvodní dodávka by měla obsahovat převedení datového modelu do podoby databázových tabulek, včetně indexů, cizích klíčů a podobně a to pro všechny následující etapy. Je pochopitelné, že během implementace může dojít k drobným změnám, které vyplynou až z implementace konkrétního modulu samotného. 3.2.1.2 Úvodní obrazovka a přihlášení do administrace V této fázi se předpokládá, že bude navržena úvodní uživatelská obrazovka se základním rozložením ovládacích prvků, návrhem přepínání mezi moduly, návrh vazeb mezi moduly a především by měla být hotova celá administrátorská část aplikace s možností přepnout uživatele s příslušným oprávněním do role “správce” (na základě extra ověření po standardním přihlášení). 3.2.1.3 Nastavení a definice číselníků Součástí administrátorské části aplikace musí být plná správa číselníků. V této fázi by měly být již definovány základní číselníky pro další etapy, jejich rozsah však nemusí být úplný, některé z číselníků mohou vznikat až během implementace každého z modulů. Musí zde však být patrné, jak se s číselníky pracuje. Číselníky musí být přehledně rozřazené a

Stránka 7 z 16


filtrovatelné dle modulu, pro který jsou určeny, jeden číselník může být relevantní pro více modulů. 3.2.1.4 Správa oprávnění, rolí a uživatelů Správa uživatelů, definice rolí a základních oprávnění je též součást dodávky jádra aplikace. Detailní sada oprávnění ještě nemusí být plně definována, musí být ale definována alespoň na úrovni přístupu k jednotlivým modulům aplikace. Stejně jako u číselníků musí i u rolí existovat možnost filtrace oprávnění dle modulů. Musí existovat oprávnění pro čtení, editaci a pořízení nového záznamu a pro prodloužení členství a licence, pro přístup k záznamům spravovaného subjektu, oblasti. Každé roli by mělo jít přiřadit libovolné množství oprávnění a každému uživateli libovolné množství rolí i samostatných oprávnění. Dále je třeba navrhnout strukturu udělování rolí (některé role budou oprávněny udělovat role podřízené -‐ např. “Správce oblasti” může udělit roli “Zástupce oblasti” a “Správce subjektu” / “Zástupce subjektu” apod.) 3.2.2 Správa členů pro sekretariát Druhá část dodávky by měla obsahovat kompletní modul sloužící ke správě členů, subjektů, koní a sportovních licencí na sekretariátu ČJF na centrále i na oblastech. Měly by být kompletně vytvořeny a naplněny číselníky a také připravena všechna oprávnění a role pro tento modul. Musí být připravena záložka se seznamem akcí vzniklých ze správy subjektů (viz kapitola 3.2.4) k ruční kontrole s možností opravy, vrácení k opravě na subjekt a akceptování úpravy. Úprava bude platná až v momentě akceptace oblastí. 3.2.2.1 Oblasti ČJF je správně rozdělena do geografických oblastí, každý subjekt musí náležet k nějaké oblasti. Pro potřeby tohoto programu by oblastí se zvláštním statusem měla být i centrála ČJF. Každé oblasti musí být přiřazena jedna osoba s rolí “oblastní sekretář” a libovolný počet osob s rolí “zástupce oblasti”. Správu oblastí může obsluhovat pouze administrátor a osoby s rolí “Generální sekretář” a “zástupce GS”. Jako další oblasti se zvláštním statusem budou cizí státy. 3.2.2.2 Subjekty Fyzická osoba může být členem ČJF pouze prostřednictvím registrovaného subjektu s vlastní právní subjektivitou (PO, FOP, Spolek). Každý subjekt musí náležet do nějaké oblasti. Při vytváření a úpravě údajů subjektu je bude třeba porovnávat s rejstříky (možnost předvyplňování a kontextové nápovědy). Zřízení subjektu a editaci základních údajů (Název, IČ, sídlo…) budou smět provádět pouze role zastupující centrálu a oblast. Ostatní údaje budou zpřístupněny i roli zastupující daný subjekt. Subjekty hradí vlastní roční členské příspěvky (včasné a opožděné), poplatky za zřízení. Dále by měla existovat možnost z oblasti či centrály předepsat pokutu či jiný poplatek za speciální službu a při nedodržení splatnosti pozastavit subjektu (a všem jeho členům) členství a možnost přihlašování na závody. Při neuhrazení poplatku za členství subjektu po skončení registračního období bude automaticky vygenerován poplatek za nové členství a do doby jeho úhrady bude subjektu i všem jeho členům pozastaveno členství a nebudou se smět hlásit na závody, školení a další aktivity v rámci ČJF, funkcionáři nebudou smět vykonávat své funkce.

Stránka 8 z 16


3.2.2.3 Osoby V sekci Osoby bude možnost zadávat a upravovat osoby a jejich vztah k ČJF v podobě rolí. Každá osoba může mít jednu či více rolí (které následně budou upravovat oprávnění v dalších částech systému). Základní automaticky nastavená role je “kontakt”. Některé role se nastaví nebo odeberou automaticky v návaznosti na další akce či zaplacení některé “služby či produktu“ (člen, jezdec, majitel koně…), jiné bude možné zadávat manuálně. Musí existovat kontroly na duplicitní záznamy, v případě nálezu shody bude uživateli nabídnut výběr shodujících se záznamů. Osoby budou smět kompletně spravovat i vytvářet zástupci centrály, zástupci oblastí i zástupci subjektů a budou jim moci přidělovat i příslušná podřízená oprávnění. Osoby vzniklé v rámci administrace subjektu budou smět být pouze “člen”, “majitel koně” a automaticky jim vznikne vazba na subjekt. Každá osoba v roli “člen” musí mít vazbu na subjekt (bez vazby na subjekt nebude možné vygenerovat členský příspěvek). Změna vazby na subjekt (přestup) bude přístupná pouze zástupcům centrály a oblasti, do které subjekt náleží. Měl by existovat číselník typů členství (základní, čestné, dítě…) s různou cenou. Měla by existovat možnost z oblasti či centrály pozastavit členství, udělit stopku účasti na závodech (vazba např. na disciplinární tresty, stopka po pádu a nutnost doložit lékařské uschopnění apod.). Takové akce by měly zůstat u osob archivovány. Stejně tak by měly jít vygenerovat pokuty a další poplatky. Veškeré úhrady příspěvků i speciálních poplatků a pokut půjdou přes ekonomiku subjektu. 3.2.2.4 Koně V sekci Koně bude možnost zadávat a upravovat údaje o koních. Koně budou smět kompletně zadávat a upravovat zástupci subjektů, oblastí a centrály. Údaje o koních by se měly validovat (předvyplňovat, kontextová nápověda) dle databáze UEK, případně Jockey klubu. V centrále by mělo být uloženo pouze minimální množství údajů potřebných k práci v rámci ČJF. U pony se bude evidovat poslední naměřená výška a datum posledního měření. Pony bez platného přeměření nebude možné vystavit licenci. Každý kůň musí mít vazbu na subjekt. Změnu subjektu u koně může provést původní subjekt nebo zástupce oblasti, do které původní subjekt náleží. Každý kůň musí mít vazbu na osobu, které pak vznikne role “majitel koně”. Nově budou v evidenci i koně, kterým nebude vystavena licence a účastní se jen hobby závodů. Subjekt bude povinen takového koně zařadit do evidence před jeho první účastí na hobby závodech. Tento krok je nutný kvůli vazbě na Online přihlašovací systém. Musí existovat kontroly na duplicitní záznamy, v případě nálezu shody bude uživateli nabídnut výběr shodujících se záznamů. 3.2.2.5 Vzdělávání U každé osoby je třeba evidovat její vzdělání ve vztahu k ČJF. Vzdělání je koncipováno dvouúrovňově. Na první úrovni člen skládá zkoušku a tím získává příslušnou kvalifikaci (jezdec, cvičitel, trenér, rozhodčí, stavitel, apod.). Většinu z těchto kvalifikací lze dále nepovinně rozšiřovat absolvováním dostatečné praxe či dodatečnými zkouškami (národní rozhodčí, FEI stavitel, do budoucna jezdec s 2. Galops**) a zároveň je pro výkon některých funkcí nutné pravidelné doškolování a refreshment. Bez těchto povinných školení bude funkce pozastavena a všichni funkcionáři by měli být s dostatečným předstihem upozorňováni, že v daném období musí školení absolvovat.

Stránka 9 z 16


Systém by měl umožňovat na úrovni oblasti i zadávat příslušná školení, rozesílat dotčeným pozvánky a umožňovat přihlašování a hrazení poplatků se školením a zkouškami související. Seznamy funkcionářů se splněnou kompletní kvalifikací by měly být přístupné na webu ČJF. Do programu zpracování výsledků by mělo být umožněno zadávat pouze funkcionáře s příslušnou kvalifikací. Správu vzdělávání bude možné provádět pouze jako zástupce oblasti či centrály. (** v případě implementace vzdělávání Galops** nejspíš i na úrovni subjektu). 3.2.3 Soutěže a výsledky Tento modul je určen k evidenci účasti jezdců a koní na závodech a soutěžích a v případě oficiálních soutěží k evidenci výsledků. Musí existovat popsané rozhraní pro načtení a validaci potřebných dat do programů na zpracování výsledků (jezdci, koně, funkcionáři, závody) a stejně tak musí být popsané rozhraní pro odeslání výsledků z těchto programů. Při definici datové věty je třeba zvážit, zda neudělat toto rozhraní 1:1 tak, jak je na portálu fei.org, aby bylo kompatibilní i s programy, na kterých se zpracovávají mezinárodní závody. Veškeré odesílání výsledků by mělo probíhat zcela automaticky, ale k jejich definitivnímu potvrzení (a uveřejnění) by mělo dojít až na základě potvrzení uživatelem na centrále ČJF, která by měla mít možnost manuálního zásahu do výsledků. Dále je třeba mít možnost některá data uložit, avšak nezapočítávat do žebříčků či do ročenky sportovních koní. Musí existovat možnost vytvoření národního závodu z jiné země a ručního zadání výsledků českých jezdců na těchto závodech. Během analýzy se musí zjistit, zda je možné z fei.org importovat data o českých jezdcích účastnících se mezinárodních závodů. Po validaci na centrále musí být výsledky dostupné na webu ČJF a zároveň musí být k dispozici po dotazu na kariéry jezdce či koně, případně ve sportovních žebříčcích (není předmětem této dodávky). S ohledem na chystanou kategorizaci by tento modul měl umět evidovat kritéria jednotlivých disciplín na přestupy/sestupy mezi kategoriemi, v případě sčítání bodů by měl u jezdců zobrazovat jejich bodové konto či chybějící kritéria pro přestup do jiné kategorie. U hobby soutěží by měl systém pouze evidovat starty jezdců a koní v soutěžích, ale bez výsledků. 3.2.4 Správa členů, koní a licencí pro subjekty Jednou z nosných myšlenek Online centrály je přenést největší část pracnosti se správou členů, licencí a koní na zástupce registrovaných subjektů. Každý subjekt si bude smět definovat libovolné množství uživatelů zastupujících subjekt (přístup do administrace subjektu). Subjekt bude smět upravovat své vlastní kontaktní údaje a kompletní agendu svých členů a koní pod ním registrovaných. U každého člena uvidí jeho vzdělání a bude jej smět přihlásit na vypsané kurzy. Na vrub subjektu budou i generovány veškeré poplatky, které bude možné online zaplatit. Budou

Stránka 10 z 16


existovat přehledy předpisů a plateb, stejně tak u osob i koní bude vidět co za kterou osobu bylo placeno či je předepsáno k platbě. Vzhledem k předpokladu chybovosti vstupů od uživatelů budou všechny osoby a koně změněné či vzniklé správou v subjektu validovány zástupcem oblasti (kontrola 4 očí, zástupci oblasti budou mít záložku s frontou změn k potvrzení) a změny vstoupí v platnost až v momentě potvrzení zástupcem oblasti. Nepředpokládá se, že by do správy členů měli přístup členové, správa by měla zůstat pouze na zástupcích klubů, nicméně stále musí existovat možnost, jak za subjekty příslušné akce vykoná zástupce oblasti či centrály (do budoucna nejspíš za poplatek). 3.2.5 Účetnictví a online platby Modul Účetnictví by měl splňovat potřeby oblastí, které by jeho prostřednictvím účtovaly a vydávaly účetní doklady jak za peníze vydané (nákupy kancelářských potřeb, platby školitelům…), tak za platby přijaté v hotovosti na oblastech. Díky online platbám a správě licencí a členů přímo v subjektech by měla na oblastech odpadnout velká část agendy spojená s registracemi a tato část účtování bude z velké části přenesena na subjekty samotné. (kromě případů, kdy si tuto činnost subjekt nechá provést na oblasti -‐ do budoucna za poplatek) Do modulu Účetnictví, resp. do části pro správu členů a koní, budou mít přístup zástupci subjektů. Uvidí předpisy povinných plateb (členství subjektu, pokuty apod.) i předpisy volitelných plateb (platby za členy, licence a koně), ze kterých si vyberou, které budou v danou chvíli uhrazeny (dokud za člena není zaplacen příspěvek, pozastavuje se členství v ČJF; dokud není zaplacena licence, není možné startovat na závodech…) Z modulu bude možné vybrané platby přímo uhradit (platební kartou, PayPal, PayU či jinou podobou službou), případně vytisknout zálohovou fakturu a uhradit bankovním převodem. Po potvrzení úhrady budou připraveny k vytištění i daňové doklady. Modul by měl být provázán s účetnictvím (konkrétní vazby budou upřesněny v analýze) a v případě úhrad bankovním převodem bude automaticky kontrolovat úhrady podle výpisu z účtu. Stejně tak bude schopen exportovat do účetnictví Pohoda účetní věty. Na počátku registračního období budou pro všechny subjekty předgenerovány předpisy plateb dle stavu k poslednímu dni předchozího registračního období. Jednotlivým subjektům by měl mít zástupce oblasti či centrály možnost vygenerovat speciální předpis (pokuta, dluh, jiný poplatek…) a též poplatky za školení či kurzy. 3.2.6 Tiskové sestavy Předmětem analýzy musí být i diskuse s představiteli ČJF na úrovni centrály i oblastí a se sekretáři nad potřebou tiskových sestav a jedním z výstupů musí být i sada tiskových sestav z jednotlivých modulů. (seznamy členů, aktivních členů, koní v soutěžích, seznamy filtrované dle věku, dle počtu startů.. a další i s ohledem na vstupy do dotačních programů MŠMT, ČUS a ČOV)

Stránka 11 z 16


4. Nefunkční požadavky 4.1. Požadavky na vzhled a dojem Aplikace by měla mít naprosto intuitivní ovládání, které samo o sobě napoví “co dělat a kde hledat” a aplikace by měla uživatele sama navádět k dalším krokům k dokončení konkrétního případu užití. Ovládání a jednotlivé funkční komponenty (tlačítka, textová pole, přehledy…) by neměly vybočovat ze zaběhnutých standardů a zvyklostí a aplikace by měla nabízet v co největším možném množství předvyplňování (kontextové výběry z možností) textových polí daty, která má k dispozici. Jednotlivé formuláře by měly co nejlépe využívat celou plochu obrazovky a nabízet možnosti pro používání bez nutnosti překlikávání mimo základní obrazovku. Aplikace (zejména část určená subjektům a veřejnosti) by měla být provozovatelná i na mobilních zařízeních, design psaný ideálně způsobem “mobile-‐first” a dle šíře zobrazovací plochy dynamicky uzpůsobovat rozložení jednotlivých elementů.

4.2. Požadavky na snadnost používání Uživateli větší části aplikace budou zaškolení zaměstnanci ČJF, kteří zároveň budou v rolích supervizorů, kdy některé akce uživatelů s nižším oprávněním budou muset validovat a schválit. Větší část uživatelů však budou lidé s různou počítačovou gramotností a vybaveností a je nutné, aby se bez nutnosti složitého školení s aplikací naučili rychle pracovat a aby chybovost dat v jejich vstupech byla co nejnižší. Aplikace by měla validovat vstupní data a v případě chyby uživateli jednoznačně říci, v čem chyba spočívá a intuitivně jej navést k opravě.

4.3. Požadavky na výkon Odezvy jednotlivých formulářů musí být v reálném čase bez dlouhých prodlev. V současné chvíli má ČJF cca 30tis kontaktů v databázi členů a 17tis koní včetně historických dat, dále pak množství dat souvisejících se soutěžemi. Při výběru technologie s ohledem na výkon je třeba počítat s nárůstem členské základny i koní a to až na desetinásobek v následujících deseti letech. Přenosy dat mezi serverem a klientem je nutné optimalizovat na minimum s ohledem na právě zobrazený formulář, aby aplikace mohla být provozována i na pomalejším internetovém připojení a na starších počítačích.

4.4. Požadavky na provoz Aplikace musí být schopna provozu u běžných poskytovatelů hostingu. Běžný provoz aplikace by neměl vyžadovat žádné zásahy přímo do databáze mimo GUI aplikace a to ani pro změny v číselnících, skupinách uživatelů či práv ani pro opravy dat zadaných uživateli.

4.5. Požadavky na bezpečnost Vzhledem ke skutečnosti, že budou přenášena citlivá data (rodná čísla apod.), musí aplikace splňovat standardy dané zákonem na ochranu osobních údajů. Komunikace mezi klientem a serverem by měla být šifrovaná (https). Vlastní vstup do uživatelské části aplikace bude přes jméno a heslo a uživatel bude mít přístup pouze do oblastí daných jeho rolí. Hesla nesmí být uchovávána v databázi v žádné rozšifrovatelné podobě (pouze hash hesla).

Stránka 12 z 16


Na úrovni databáze musí mít aplikace pouze role nezbytně nutné ke svému provozu (select, insert, update) na konkrétní příslušné tabulky dle role přihlášeného uživatele. Správcovské role i další přístupy přímo do produkční databáze mohou mít pouze osoby určené VV ČJF za podmínek daných VV ČJF. Data by se v databázích neměla mazat, jejich smazání by mělo být zabezpečeno pouze příznakem. Veškeré změny dat musí být auditovány (čas, uživatel, činnost). Rozhraní aplikace pro aplikace třetích stran musí být zabezpečena tak, aby jejich využívání mohlo být regulováno smluvním vztahem mezi uživatelem a ČJF. Naprostá většina business logiky by měla být na serverové části aplikace, nikoli v klientovi. Validace klientem zadaných dat musí probíhat jak na straně klienta, tak i na straně serveru tak, aby nebylo možné GUI validace obejít a serveru podstrčit jiná data, než ta z GUI. Aplikace musí být odolná proti všem známým útokům jako jsou “Injection”, “Cross-‐site-‐scripting” apod. (minimálně na vše z OWASP TOP 10).

4.6. Požadavky na neprodukční prostředí a release management Veškerý vývoj aplikace musí probíhat ve vývojovém prostředí u dodavatele. Po dokončení vývoje dohodnutého funkčního bloku dojde k nasazení na neprodukční prostředí s předem domluvenou konfigurací, které připraví a dá k dispozici objednatel. Neprodukční prostředí by mělo 1:1 odpovídat nastavením prostředí produkčnímu avšak nemusí splňovat tak vysoké nároky na výkon a datové toky. Na předprodukčním prostředí dojde také k plnému otestování datové migrace z původního systému. Po akceptaci díla jako celku, těsně před zahájením pilotního provozu dojde k instalaci celé aplikace do produkčního prostředí a migraci plných dat z původního systému. Součástí každého předání do předprodukčního prostředí musí být DA -‐ “Delivery Advice”, neboli předávací protokol obsahující plné Relase Notes změn oproti předchozí verzi s odkazy na čísla chyb či požadavků v bug-‐trackingovém nástroji. Číslo instalované verze by mělo být jednoduše zjistitelné přímo z aplikace po přihlášení jakéhokoli uživatele. Po akceptaci a otestování v předprodukčním prostředí teprve může dojít k nasazení nové verze na prostředí produkční.

4.7. Právní požadavky Veškeré zdrojové kódy, včetně použitých frameworků a dalších součástí musí přejít dnem zaplacení poslední faktury do plného majetku objednatele včetně práva na úpravy v produktu po skončení záruční doby. Bez výhradního a písemného souhlasu VV ČJF nesmí být v produktu použita žádná část, která vyžaduje speciální licencování, nebo by z její použití plynuly pro objednatele jakékoli povinnosti. Aplikace musí splňovat veškeré podmínky plynoucí ze zákona na ochranu a zpracování osobních údajů.

4.8. Dokumentace 4.8.1 Uživatelská Uživatelská dokumentace by měla velmi stručně ale jednoznačně popisovat jednotlivé případy užití z pohledu běžného uživatele včetně návodu na řešení známých problémů a možných

Stránka 13 z 16


uživatelských chyb. Členění dokumentace by mělo být po jednotlivých modulech a bude tak nedílnou součástí dodávky modulu do akceptačního řízení. U případů užití určeným pro subjekty a veřejnost by měla být součástí dokumentace instruktážní videa. Dokumentace bude dodána v elektronické podobě. 4.8.2 Administrátorská Administrátorská dokumentace k aplikaci musí obsahovat všechny údaje nutné k řádné instalaci aplikace na nové prostředí. Tedy požadavky na verze potřebných systémů v prostředí hostingu, nastavení systémových proměnných, způsob instalace a úvodní nastavení. Musí též obsahovat návod, jak již běžící aplikaci migrovat do jiného prostředí. 4.8.3 Dokumentace v kódu Veškerý dodávaný zdrojový kód musí být řádně programátorsky okomentován dle standardů daného programovacího jazyka tak, aby se v něm rychleji mohl zorientovat programátor nepodílející se na dodávce.

5. Projektové otázky 5.1. Otevřené otázky 1. Nebude ze zákona nutné, aby každý nový člen podepisoval souhlas se zpracováním osobních údajů? Jak toto zajistit, v případě, že je bude administrovat subjekt? 2. Jakým způsobem řešit přestupy? Bude si moci “nový” klub člověka stáhnout? 3. Přestupní řád obecně -‐ neomezit přestupy pouze na období registrace + např. měsíc srpen? chtít za přestupy mimo reg. období poplatek? -‐ omezení cílených přestupů pouze za účelem MČR, původní klub by se měl o přestupu dozvědět. Dále by klub měl mít možnost pozastavení členství nebo vyloučení pro vážná porušení. 4. Bude ČJF dále vydávat papírové licenční známky? 5. Budeme chtít, aby centrála komunikovala s FEI a jinými federacemi? (výsledky, přihlášky, evidence FEI čísel a pasů, jezdci) 6. Migrace dat -‐ v jakém rozsahu budeme chtít migrovat současná data? Např. migrace neúplných dat -‐ např. cizinci bez země apod. 7. Rodná čísla u cizinců a započítávání do statistik. 8. Práce s cizinci jezdci a jejich koňmi obecně, nedomyšlený proces, specifika. 9. Výkazy o členech do ČUS. 10. Budeme chtít v systému počítat i s přípravou na kategorizaci koní a subjektů (pořadatelů)? 11. Bude se řešit hlídání neoprávněných startů (mimo disciplínu, mimo kategorii)? 12. Měl by systém automaticky hlídat kritéria splnění přestupu / sestupu v kategoriích pro systém kategorizace jezdců? 13. Měl by systém umět výpočty žebříčků (za oblasti, za disciplíny, za kategorie)? 14. UEK -‐ evidence majitelů koní -‐ třeba probrat s UEK. 15. Přechody subjektů k jiné oblasti. 16. Kam přijdou peníze z online plateb -‐ centrála nebo účet dle oblasti, jak následně přerozdělit? 17. Online výsledky – zvážit možnost této funkcionality v rámci analýzy, úzká vazba na Gallop 18. Zvážit možnost zobrazování informací o subjektech a jezdcích (vazba na web?) 19. Evidence a hlídání kvalifikací na výkonnostní odznaky, na MČR dle zadaných parametrů? 20. Evidecnce pádů (dvojice, jezdec, rotační pády)

Stránka 14 z 16


5.2. Použitá standardní řešení Použití frameworků, komponent a dalších standardizovaných částí v dodávce je čistě na úsudku dodavatele. Je však třeba brát zřetel na úvodní požadavek, že celé dílo včetně kompletních zdrojových kódů musí dnem akceptace a proplacení závěrečné faktury přejít plně do majetku objednatele, včetně práva na úpravy jakékoli části aplikace (pochopitelně po skončení záruky). Též žádná část dodávky a kódu nesmí být vázána žádnou speciální licencí, z níž by pro objednatele plynuly nějaké finanční či autorské nároky třetích stran. Výjimku z tohoto požadavku může udělit pouze VV ČJF svým usnesením.

5.3. Nové problémy Počítačová gramotnost uživatelů -‐ některé skupiny uživatelů budou produkt hůře přijímat a dá se očekávat, že v počátku bude nutná velká dávka trpělivosti při vysvětlování a poskytování součinnosti. Kompatibilita se staršími prohlížeči -‐ počítačové vybavení některých subjektů je velmi zastaralé (Windows XP a klidně i starší) a schopnost přesvědčit uživatele na výměnu ve chvíli “když ono to pořád funguje” vyžaduje velké úsilí. Nutnost zásahu do dalších aplikací -‐ změny v centrále ČJF automaticky vyvolají nutnost úpravy dalšího software, zejména výsledkového sw Gallop, Online přihlašovacího systému a WEBu ČJF. Tyto změny zcela jistě přinesou zvýšení nákladů tohoto projektu. Změny v zaběhlých procesech uvnitř ČJF -‐ změny v centrále ČJF musí jít ruku v ruce i se změnou některých, léta zaběhlých, procesů. Bude chvíli trvat, než si vše sedne a lidé si zvyknou. Reakce na legislativní změny -‐ pokud nebude nový produkt podporován na základě servisní smlouvy, může se zpomalit proces mandatorních dodávek a updatů.

5.4. Přepnutí systému Součástí navrhovaného řešení musí být i analýza (a následný návrh řešení) migrace dat uložených v současném řešení do nových struktur. Je třeba zachovat plnou historii včetně zobrazování historických, veřejně přístupných dat na webu ČJF. Rozsah migrovaných dat je otevřenou otázkou a měla by být řešena během analýzy. K přelití dat do neprodukčního prostředí musí dojít již před začátkem akceptační fáze, aby kontrola dat a jejich kvality mohla být součástí akceptace. V té době však budou data ještě pořizována do starého systému a bude třeba udělat nové nalití na počátku fáze pilotního provozu, kde již dojde k migraci dat i na produkčním prostředí. V průběhu pilotního provozu by již neměl být původní systém používán.

5.5. Rizika Pomalá součinnost zúčastněných osob -‐ kromě zaměstnanců ČJF jsou zúčastněnými osobami projektu volení zástupci, kteří za svou práci neberou žádnou finanční odměnu a činnost pro ČJF dělají ve svém volném čase. Z toho vyplývá i fakt, že nemohou činnostem (ani tomuto projektu) dávat takovou prioritu a pozornost. Nepřijetí projektu ze strany uživatelů -‐ nezanedbatelné procento budoucích uživatelů patří do generace či skupiny obyvatel, která běžně s počítačem nepracuje, případně učení se nových věcí pro ně představuje značné úsilí. Musí tedy stále existovat možnost, aby pro ně běžnou administraci členů a licencí mohl někdo udělat (včetně platby v hotovosti), například oblastní sekretář. Bohužel do této skupiny patří i část hlavních uživatelů -‐ oblastních sekretářů, kde bude nutné kvalitní školení s individuálním přístupem.

5.6. Náklady a plnění Cenová nabídka na fázi analýzy bude jedním z klíčových faktorů výběrového řízení.

Stránka 15 z 16


Předpokládané náklady na jednotlivé moduly v etapě implementace a další dodávky včetně dokumentace budou stanoveny na základě etapy Analýza, avšak cenová nabídka bude jedním z klíčových faktorů výběrového řízení. Produkt by měl být dodán formou “Fix-‐Time—Fix-‐Price” na klíč. Změnové požadavky v průběhu implementační fáze budou řízeny standardním procesem a budou schvalovány jednotlivě. Zálohové faktury budou propláceny na základě dodávky jednotlivého funkčního celku (modulu) po jeho předvedení na tzv. Demu a jeho částečné akceptaci. Maximální částka proplacená na základě zálohových faktur může být ve výši 80% celkových nákladů, zbývajících 20% bude uhrazeno po finální akceptaci díla.

5.7. Školení uživatelů V průběhu akceptační fáze bude nutné zajistit školení klíčových uživatelů (GS, Sekretariát ČJF, VV, Oblastní sekretáři). Takové školení proběhne v sídle ČJF v Praze. Dále by měla následovat série školení pro zástupce subjektů, které budou plánovány v součinnosti s vedením jednotlivých Oblastí v místech která budou geograficky výhodná pro danou oblast.

5.8. Požadavky na další rozvoj produktu, který není součástí stanoveného rozsahu prací Minimálně jedenkrát za rok bude nutné provést v aplikaci úpravy vyplývající z legislativních změn (úpravy národních / mezinárodních pravidel, změny v účetnictví) a změn v rozhraních partnerských aplikací. Tyto změny lze řešit jako samostatné změnové požadavky, případně formou servisní smlouvy na údržbu SW s jeho dodavatelem. Taková servisní smlouva může a nemusí být součástí nabídky pro výběrové řízení.

Stránka 16 z 16

Funkční specifikace projektu. Online centrála ČJF

Recommend Documents