Odpov di na dotazy uchaze e k ve ejné zakázce. 29/2014-53-28 SSZ Datový katalog 1. Up es ující dotaz k odpov di Zadavatele k d íve položenému dotazu: V rámci kap. 2.2.8 Požadované sou innosti Zadávací dokumentace je uvedeno: B hem dodávky aplika ního programového vybavení musí Zhotovitel na m sí ní bázi reportovat využití interních zdroj Objednatele (a vypo ítávat již použité a ješt dostupné interní kapacity Objednatele pro dodávku aplika ního programového vybavení). edchozí dotaz: Prosíme o up esn ní p edstavy Zadavatele, zda budou tyto reporty podléhat schválení ze strany zástupc SSZ a jak budou p ípadn ešeny rozpory v po tech spot ebovaných D? Jaký bude další postup v okamžiku, kdy bude po et p edjednaných interních kapacit SSZ vy erpán? Odpov SSZ: Na základ uzavíraných díl ích smluv je pevn definováno množství kapacit D). Po et interních kapacit Zhotovitele je pevn dán Díl í smlouvou. Up es ující dotaz: Odpov SSZ sm uje k definici (evidenci) kapacit Zhotovitele, zde je nám to jasné. Dle výše citovaného požadavku v Zadávací dokumentu to však vnímáme jako evidenci poskytnutých kapacit v rámci sou innosti ze strany SSZ takže náš dotaz se týká ešení p ípadných rozpor v evidenci t chto lov kodn nap. zhotovitel v reportu uvede, že za daný m síc bylo dle jeho názoru poskytnuto 5 D sou innosti ze strany pracovník SSZ, garant projektu ze strany SSZ bude tento po et rozporovat s tím, že dle evidence SSZ byla poskytnuta sou innost ve v tším rozsahu. Jak bude tento rozpor ešen? Jak se bude postupovat v p ípad, že po et p edjednaných D na poskytnutou sou innost ze strany SSZ bude vy erpán? V p ípad, že dojde k rozporu po tu D interních zdroj objednatele z pohledu Zhotovitele a Objednatele, bude tento rozpor ešen prost ednictvím jednání zú astn ných stran. Zhotovitel musí respektovat interní kapacity Objednatele, Objednatelem schválené, vycházející z definovaných požadavk na sou innost Objednatele. 2. Up es ující dotaz k odpov di Zadavatele k d íve položenému dotazu: V rámci kap. 3.1 Požadavky na aplika ní podporu Zadávací dokumentace je uvedeno: Zhotovitel zodpovídá za aktualizaci automatizovaných test edchozí dotaz : Požaduje SSZ v rámci VZ dodání nástroje, v n mž by si mohla provád t v p ípad pot eby nezávisle tyto automatizované testy? Pokud ano, je ze strany SSZ n jaký nástroj preferován? Odpov SSZ: SSZ požaduje dodání nástroje, ale konkrétní nástroj není preferován. Up es ující dotaz: Je ze strany SSZ požadováno dodání licence tohoto nástroje (tzn. SSZ se stane vlastníkem tohoto nástroje) nebo je p ípustná varianta ešení, kdy Zhotovitel zajistí SSZ p ístup do svého prost edí, v n mž bude zajiš ovat provoz a údržbu nástroje pro automatizované testování a SSZ si bude moci tímto zp sobem spoušt t p íslušné testy vzdálen? Požadavkem Objednatele je dodání nástroje pro automatizované testování tak, aby SSZ byla jeho vlastníkem a mohla jej provozovat bez omezení v prost edí SSZ.
3. dotaz: Je požadován export dat z Datového katalogu ve strukturované form definované vyhláškou. 469/2006 Sb.? VYHLÁŠKA.469/2006 Sb. o form a technických náležitostech p edávání údaj do informa ního systému o datových prvcích a o postupech Ministerstva informatiky a jiných orgán ve ejné správy p i vedení, zápisu a vyhlašování datových prvk v informa ním systému o datových prvcích (vyhláška o informa ním systému o datových prvcích) ur uje formu podn tu na zápis nebo zm nu datového prvku a údaj o íselnících p i p edávání do informa ního systému o datových prvcích a postupy orgán ve ejné správy p i zápisu datových prvk do informa ního systému o datových prvcích. Neur uje strukturu datových katalog vedených orgány ve ejné správy. Zadavatel proto požaduje možnost exportovat data na základ uživatelem zadaného rozsahu datových prvk a jejich atribut. 4. dotaz: Dle bodu 6.2. Zadávací dokumentace (ZD) má být sou ástí závazného azení dokument nabídky i Krycí list nabídky. Vzor Krycího listu však není sou ástí ZD. Má uchaze použít n jaký vlastní vzor Krycího listu nebo bude vydán dodatek ZD se závazným vzorem Krycího listu? Závazný vzor krycího listu zadavatelem nestanoví. Uchaze tedy zpracuje krycí list sám s tím, že krycí list musí obsahovat minimáln údaje uvedené v l. 6.1.3 zadávací dokumentace. 5. dotaz: V rámci P ílohy. 1 k Rámcové smlouv, kap. 2.2.4 Vývoj, implementace a testování požaduje Zadavatel v rámci testovací fáze zajistit mimo jiné Technické testy (penetra ní/výkonnostní). Dotaz: Prosíme o up esn ní p edstavy Zadavatele o zp sobu provedení pr kazných penetra ních test u aplikace, která je provozována pouze uvnit IIS SSZ. Hlavním cílem penetra ních test je vyhodnocení front-endové aplikace z pohledu spolehlivosti, zajišt ní integrity, jednozna né autentizace a autorizace prost ednictvím systému AAA Portál a rnosti dat. Penetra ní testy aplikace p edstavují nástroj na ov ení míry odolnosti v i napadení ze strany uživatel (z lokální sít SSZ). Penetra ní testy budou vycházet z relevantních ástí uznávaných metodik (nap. OWASP, OSSTMM apod.) a z relevantních ástí uznávaných norem nap. Common Criteria ( SN ISO/IEC 15408-1 až 3). Výstupem z penetra ních test bude protokol s vyhodnocením míry rizika u zjišt ných zranitelností, nejlépe za použití koeficientu DREAD (DAMAGE + REPRODUCABILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY), kdy koeficient je vy íslen jako pr r z p ti kritérií hodnocených na stupnici od 0 do 10, vyšší hodnocení znamená vyšší riziko. 6. dotaz: Disponuje zadavatel pro pot eby školení vhodnou školící místností, kterou bude možno pro školení uživatel využít? Pokud ano jaká je kapacita využitelné školící místnosti?
SSZ disponuje školícími místnostmi, kapacita je až 120 míst. 7. dotaz: Je možné pro vývoj aplikace použít na aplika ních serverech verzi.net Framewoku 4.5.2? Pro vývoj je nutno dodržet platné standardy SSZ. 8. dotaz: Datový katalog P íloha.1 k Rámcové smlouv, Specifikace p edm tu pln ní a technické požadavky, kap. 2.2.6 Školení Zhotovitel musí v rámci školení pro nov zavád nou aplikaci zabezpe it vyškolení všech pracovník, kte í budou pracovat s nov dodávanou aplikací. Dotaz: Na základ p edchozího dodate ného dotazu Objednatel up esnil, že p edpokládá 300 uživatel, kte í budou pracovat s nov dodávanou aplikací. Prosíme o up esn ní, jakou formu školení Zadavatel o ekává (prezen ní, u pracovních stanic), zda p edpokládá školení v prostorách SSZ (pokud ano, prosíme o sd lení kapacitních možností daných prostor pro odhad po tu pot ebných školení), pokud SSZ o ekává zajišt ní prostor ze strany Zhotovitele, prosíme o up esn ní, zda je požadováno i zajišt ní ob erstvení pro ú astníky školení. Navržení formy školení je v režii Zhotovitele. Je možné využít i prostory SSZ, které mají kapacity až 120 míst. 9. dotaz: Datový katalog P íloha.1 k Rámcové smlouv, Specifikace p edm tu pln ní a technické požadavky, kap. 2.2.5 Migrace dat, kap. 2.2.8 Požadované sou innosti Dotaz: Jelikož data evidovaná prost ednictvím stávajícího nástroje nepat í do kategorie osobních ani citlivých dat, prosíme o up esn ní, s ohledem na požadovaný Podrobný návrh migra ní strategie a definování požadovaných sou inností, jestli SSZ p edpokládá, že všechny kroky spojené s migrací/konsolidací dat prob hnou v prost edí SSZ nebo jestli je možné navrhnout i postup vedoucí k pot eb nižší pot ebné sou innosti ze strany SSZ, kdy bude proveden export dat ze stávajícího nástroje, konsolidaci a išt ní dat provede Dodavatel ve svém prost edí a p ipraví je tak až pro finální migraci do cílové aplikace, která pak op t prob hne v prost edí SSZ. Celý postup mimo prost edí SSZ by byl ze strany Zhotovitele zdokumentován a p íslušn odreportován. Ano, ur ité kroky je možné provést v prost edí dodavatele. 10. dotaz: Datový katalog Funk ní specifikace, kap. 3.2 Z d vodu automatizování inností a vytvo ení reálného obrazu stavu položek v systémech SSZ v Datovém katalogu bude vytvo en pravidelný kontrolní mechanismus pro sledování zm n ve strukturách databází, které probíhají v souvisejících systémech SSZ (postupn u t ch systém, u kterých jsou evidovány položky v Datovém katalogu). Dotaz: Prosíme o potvrzení, zda v rámci dodání nového aplika ního vybavení Datový katalog edpokládá SSZ vytvo ení pravidelného kontrolního mechanismu pro sledování zm n ve strukturách databází u systém, které jsou již nyní v Datovém katalogu evidovány (KE, VZT, Info DB) a pro další
systémy pak bude ešeno následn po jejich zmapování a zavedení do Datového katalogu v rámci následného rozvoje systému? Požadujeme navržení obecného kontrolního mechanismu, který bude moci SSZ po zmapování dalších systém intern používat. Kontrolní mechanismus na KE, VZT a InfoDB vytvo í dodavatel již v rámci projektu. 11. dotaz: V zadávací dokumentaci v dokumentu 29 ZD.docx je v kapitole 9.4.5 uvedeno: Získané body u p íslušného subkritéria budou porovnány s bodovým hodnocením ostatních uchaze, jejichž nabídka bude hodnocena, a to podle vzorce: V p edchozí kapitole 9.4.4 je uvedeno, jak bude komise p azovat body jednotlivým nabídkám. Hodnocení je obodováno adou 0, 1, 2, 3, 5. Teoreticky se tedy m že stát, že p i vyhodnocení vzorcem m že dojít k d lení nulou, jestliže žádná nabídka nezíská u n kterého subkritéria žádný bod. Opravdu zadavatel chce použít íselnou adu hodnocení 0, 1, 2, 3, 5 a zmín ný vzorec (bez n jaké podmínky zabra ující d lení nulou)? Zadavatel up es uje, že v p ípad, kdy všechny nabídky v rámci konkrétního subkritéria získají 0 bod, pak bude všem nabídkám v p íslušném subkritériu p id leno shodn 0 bod. 12. dotaz: V dokumentu Ramcova_smlouva_Datovy_katalog.docx je v odstavci 10.6 napsáno: Sou ástí pln ní Zhotovitele dle Díl ích smluv/díl ích objednávek je p edání školící uživatelské, instala ní, administrátorské a vývojové dokumentace (v etn p edání zdrojových kód ) k výsledk m edm tu pln ní Objednateli. Nemá být správn " školící, uživatelské, "? Je poptávaná školící uživatelská dokumentace (jedna zahrnující oba ú ely), nebo mají být výrazy školící a uživatelská odd leny árkou a dokumentace pro školení m že být odlišná od uživatelské p íru ky? Ano, jedná se skute o školící a uživatelkou p íru ku. Úvod k dotaz m. 13 až. 16 V dokumentu Datovy_katalog_funkcni_specifikace.doc je v kapitole 3.1 na stran 7 uvedeno: Atribut TypVazbyNaEtalon vyjad uje, zda reálná datová položka subsystém IIS SSZ odpovídá položce subsystému Etalon. Pro vyjád ení jejich shody je definováno p t r zných druh vazeb: Ideální obsah i definice položky se pln shodují. Hybridní obsah položky se neshoduje, více položek se obsahov rovná jedné položce. Systémová systémové položky, kde se obsahy ani definice neshodují. Specifická obsah se shoduje, ale definice položky je výrazn odlišná. Fiktivní obsah nebo definice položky se tém shodují s rozdílem.
Sou asný datový katalog umož uje uživateli vybrat konkrétní typ vazby na etalon z d vodu možnosti hodnocení významové stránky datové položky. Vazby slouží pro uživatele jako indikace k další analýze, zda není vhodné u init zm ny. Podotýkáme, že z popisu vyplývá že se jedná o sledovanou vlastnost údaje, kterou uživatel na základ svého rozhodnutí podle stanovené metodiky zadává ru výb rem z íselníku. 13. dotaz: Vazba Hybridní obsah položky se neshoduje, více položek se obsahov rovná jedné položce. První ást v ty je jasná, obsah položky se neshoduje s etalonem. Druhá ást v ty není jasná více položek se obsahov rovná jedné položce. Mohl by zadavatel up esnit, jaké položky jsou ozna eny jako hybridní? Jedná se o položky, které po významové stránce obsahují ást z položky, se kterou jsou provázány. Nap íklad se m že jednat o reálnou položku, která obsahuje íslo domu (tedy íslo orienta ní a íslo popisné) v jednom údaji. Opa je možné, že etalonová položka významov obsahuje více položek ze systém. 14. dotaz: Vazba Systémová - systémové položky, kde se obsahy ani definice neshodují. Jde o systémové položky tabulek? Je v po ádku, že se neshodují ani obsah ani definice? Mají být evidovány datovým katalogem? Nejedná se o systémové položky tabulek. Vazba se využívá pro prvky, které využívá pouze n který ze subsystém (uživatel s nimi v t chto subsystémech m že pracovat), a p esto není žádoucí, aby tvo ily novou položku Etalonu. Typickým p íkladem jsou ID záznam, podle kterých se vyhledává. 15. dotaz: Vazba Specifická obsah se shoduje, ale definice položky je výrazn odlišná. Myslí se tím, že business význam položky se shoduje, ale položka se od etalonu liší (typem, délkou atd.)? Ano. Definice se liší v p evážné ásti atribut 16. dotaz: Vazba Fiktivní - obsah nebo definice položky se tém shodují s rozdílem. Obsah nebo definice položky se tém shodují s rozdílem - rozdílem eho, jakým rozdílem? A pro "tém "? Mohl by zadavatel up esnit, jaké položky jsou ozna eny jako fiktivní? Položky se od sebe liší jedním nebo dv ma vybranými atributy. 17. dotaz: V dokumentu Datovy_katalog_funkcni_specifikace.doc je v kapitole 3.1 na stran 6 uvedeno: P i p echodu ze stavu Produk ní do stavu Ukon ená se m ní verze zp t na stejnou verzi, ze které byla položka p epnuta do stavu Produk ní. Pro se vrací verze položky p i p echodu ze stavu "Produk ní" do "Ukon ená"? Má uchaze i kv li této vlastnosti navrhnout jiný zp sob verzování položek viz Je nutné vyhodnotit a p ípadn navrhnout korekce sou asného verzování datových položek, které se odvíjí od jejich stav.?
Ano, p edpokládáme vyhodnocení a p ípadné navržení korekce sou asného verzování datových položek. Sou asné dvouúrov ové verzování takto umož ovalo na první pohled pomocí verze odlišit položky v produkci, které jako jediné kon ily 0. 18. dotaz: že zadavatel potvrdit záv r, vyplývající z popisu v kapitole 3.1 dokumentu Datovy_katalog_funkcni_specifikace.doc, že položky je možno m nit (editovat) pouze ve stavu Koncept, pokud je pot ebná zm na položky v jiném stavu, je nutné založit nový koncept se stejnými atributy IDPolozky, Subsystem a DruhPolozky, ale s další verzí, v n mž se zm ny provedou a projdou schvalováním? Ano 19. dotaz: V dokumentu Datovy_katalog_funkcni_specifikace.doc je v kapitole 3.7.2 napsáno: "Kontrola vypln ní všech povinných atribut a zárove kontrola vypln ní nepovinných atribut, pokud byly uživatelem vybrány k jednotlivým položkám" Jsou atributy povinné, které musí být vypln ny, a atributy nepovinné, které být vypln ny mohou, ale nemusí. Nechápeme, co se myslí kontrolou vypln ní nepovinných atribut, pokud byly uživatelem vybrány k jednotlivým položkám. Myslí se tím, že když uživatel vyplní nepovinný atribut, zkontroluje se jeho typ a další vlastnosti (aby vkládané datum bylo opravdu datum aj.)? Pokud to není takto myšleno, prosíme o up esn ní, co bylo touto v tou mín no. Ano, p íslušné ustanovení zadávací dokumentace je mín no tak, jak tazatel uvedl v p edposlední v svého dotazu. 20. dotaz: V dokumentu Datovy_katalog_funkcni_specifikace.doc je v kapitole 3.8 napsáno: Po et veškerých zm n položek v Datovém katalogu v etn procentuálního vyjád ení a možnosti omezení metriky na subsystém v rozd lení na: Po et nov zavedených položek Po et zm ných položek s vytvo ením nové verze konceptu Po et zrušených položek ze stavu Koncept Položky ze stavu Koncept se mažou, nadále v databázi neexistují (alespo podle funk ní specifikace). esto je po et zrušených položek ze stavu koncept požadován v metrice. Mají se tyto údaje získávat z logu? Ano, informace lze získávat z logu.
21. dotaz: V dokumentu Priloha c 1 k RS_Specifikace_predmetu_plneni_technicke_pozadavky.docx je kapitola 2.2.1 Popis návrhu ešení. Ve všech ostatních kapitolách, které budou hodnoceny (2.2.2, 2.2.3 až 2.2.8 a 3.1.3 a 3.2.2), je uveden ráme ek s popisem, co Zhotovitel v rámci dané kapitoly popíše i s ur ením, kde tak má u init (doplní Zhotovitel). V kapitola 2.2.1 tento ráme ek a toto vymezení CHYBÍ. Kam má zhotovitel zapsat popis návrhu ešení, když byl odpov dích na dotazy uchaze e v souboru 259312121_0_29 Odpov di na dotazy 8.pdf v odpov di na dotaz íslo 2 instruován takto: Zhotovitel dopl uje v míst, kde je k tomu vyzván nebo tam, kde je to graficky znázorn no. Formát dopln ní je v plné diskreci zhotovitele. Sporujeme, že v kapitole 2.2.1 takové místo není ani graficky znázorn no, ani v ní není výzva na dopln ní. P itom je kapitola 2.2.1 jedna z hodnocených kapitol pro posouzení úrovn a kvality nabízeného pln ní dle požadavk zadavatele a bez této kapitoly nebude nabídka úplná. Doplní / opraví zadavatel kapitolu 2.2.1 v p íloze. 1, aby bylo možno splnit jeho požadavky tak, jak požaduje? K dotazu uchaze e zadavatel uvádí, že návrh ešení dle kapitoly 2.2.1. P ílohy. 1 zadávací dokumentace umístí za text v kapitole 2.2.1 P ílohy. 1 zadávací dokumentace (resp. p ílohy. 1 návrhu Rámcové smlouvy). 22. dotaz: Uchaze i z poskytnuté Zadávací dokumentaci není z ejmý rozdíl mezi Obecným datovým typem, Jednoduchou položkou, Složenou položkou a íselníkem. Žádáme tedy o vysv tlení rozdíl ideáln na konkrétním p ípad. Popis je uveden ve viz Funk ní specifikaci. Pro vysv tlení uvádíme i p íklady : Obecný datový typ nenese žádný v cný význam, ale nese pouze základní informace o vlastnostech (typ, délka, kontrolní test, kontrola na íselník, povolené znaky, zp sob zobrazení (nap. dt_textcz) Jednoduchá položka odpovídá datovému prvku daného subsystému, jedná se o konkrétní datový prvek jehož vlastnosti jsou odvozeny od p azeného ODT s možností jejich úpravy nebo dopln ní (nap. íslo popisné trvalé adresy žadatele) Složená položka datový prvek tvo ený nejmén dv ma položkami, nap. Celé jméno (skládá se z titul ed, jméno, p íjmení, titul za ) nebo Adresa (skládá se z n kolika položek v etn ísla domu dále složeného z ísla orienta ního a ísla popisného) íselník slouží ke standardní kontrole údaje proti vý tu hodnot (nap. íselník stát ). Každý záznam hodnoty íselník m že obsahovat více sloupc (nejen kód a význam ale nap. ZkratkaStátuNa2Znaky, ZkratkaStátuNa3Znaky, eský název, anglický název, plný název, zkrácený název apod.) 23. dotaz: V odpov dích na Dotaz. 5 Dodate ných informací. 7 Zadavatel uvedl, že po et uživatel nep esáhne 300. Chápe Uchaze správn, že je t eba licen pokrýt všech 300 uživatel? Pokud ne, žádáme o up esn ní po tu uživatel, kte í mají být licen pokryti. Zp sob licencování navrhne uchaze v nabídce p i zohledn ní p edpokládaného po tu uživatel 24. dotaz: Žádáme Zadavatele o uvedení po uživatel dle jednotlivých rolí, které jsou uvedeny v kapitole 3.4 Funk ní specifikace ( tená, P isp vovatel, Správce, Audit, Administrátor).
Po et uživatel v jednotlivých rolích se bude m nit v pr hu provozování systému a v souvislosti s množstvím evidovaných údaj. V sou asné dob nelze odhadnout jejich po ty v jednotlivých rolích. 25. dotaz: Je sou ástí dodávky Datového katalogu, pokrytí integrace všech aktuálních 21 subsystém? Ne, požadujeme navržení obecného kontrolního mechanismu, který bude moci SSZ po zmapování dalších systém intern používat. Kontrolní mechanismus na KE, VZT a InfoDB vytvo í dodavatel již v rámci projektu. 26. dotaz: Chápe Uchaze správn, že Zadavatel p edpokládá, že komunikace/integrace Datového katalogu a subsystém bude provedena na úrovni databáze nebo formou webových služeb nebo bude provedena integrace p es stávající integra ní platformu MS BizTalk? Pokud ano, která z t chto integrací je požadována? Pokud ne, žádáme o up esn ní, jak je požadováno provedení komunikace/integrace? V této fázi Zadavatel nepreferuje žádné z uvedených ešení. Povinností uchaze e je ídit se platnými standardy SSZ. 27 dotaz: Je sou ástí p edm tu pln ní této ve ejné zakázky i dodávka nového systému Etalon? Pokud ne, žádáme o up esn ní, jakým zp sobem je možné provést integraci na existující systém Etalon databázová úrove, webová služba, integrace prost ednictvím BizTalk nebo jiný zp sob. NE, Etalon je pouze ozna ení skupiny vzor pro navrhování údaj datové základny, který bude vytvá en p ímo v aplikaci. 28 dotaz: Uchaze se domnívá vzhledem k odpov di na Dotaz. 1 Dodate ných informací. 7, že verze a typy databází uvedené v poskytnutých standardech neodpovídají aktuálnímu stavu a sou asn tak soudí i vzhledem k tomu, že samotný aktuální Datový katalog je ešen prost ednictvím MS Excel/Access, což vede k úvaze, že existuje další neprázdná množina systém, které nemají datový základ dle poskytnutých standard. Je úvaha Uchaze e správná? Pokud ano, žádáme o up esn ní jednotlivých typ využívaných datových úložiš v etn jejich verzí pro všechny subsystémy, se kterými bude Datový katalog integrován (viz požadavky v kapitole 3.2 Funk ní specifikace). Nyní je aktuální verze Oracle Database 10g Enterprise Edition 10.2.0. 64bit, Oracle 11 Oracle Database 11g Enterprise Edition 11.2.0. 64bit. Do budoucna je po ítáno s Oracle 12c
Vzhledem k tomu, že Zadavatel provedl úpravu v p íloze. 1 k rámcové smlouv a to v bod 2.2.8, zasílá upravený dokument uchaze m a posunuje lh ty takto: Lh ta pro podání nabídek: 13. 4. 2015 do 12:00 hodin Otevírání obálek s nabídkami: 13. 4. 2015 od 12:00 hodin Bc. Ludmila Hnutová odd lení centrálního zadávání ve ejných zakázek SSZ 6. 3. 2015