Textová podoba smlouvy Smlouva č. 19967319: Na základě SMLOUVY NA PROVOZ A ROZVOJ APLIKACE INTERNÍ AKTY ŘÍZENÍ

                        MZE-15241/2022-12121

mze000022933064

 


Požadavek na změnu (RfC)[endnoteRef:1] – Z33790[endnoteRef:2] [1:  Formulář RfC je tvořen třemi částmi, A - Věcné zadání, B – Nabídka řešení, C - Potvrzení realizace požadavku. První část (Věcné zadání) je předložena poskytovateli/dodavateli jako pobídka k předložení nabídky řešení. Druhou část, tj. část B použije dodavatel řešení k vypracování nabídky, kterou předloží MZe. Třetí část (Potvrzení realizace požadavku) se po vyplnění přiloží k první a druhé části a předloží se ke schválení osobám uvedeným v části C RfC. Poskytovateli/dodavateli se poté vyplněný formulář RfC předkládá v příloze objednávky na realizaci změnového požadavku. Pouze tato podepsaná objednávka je pokynem pro dodavatele/poskytovatele k realizaci změny.]  [2:  Hlavní identifikátor změnového požadavku přidělený v ServiceDesku MZe při jeho registraci.] 

a – věcné zadání
1 Základní informace

	ID PK MZe[endnoteRef:3]: [3:  ID PK MZe – pomocný identifikátor požadavku přidělený v pomocné evidenci projektové kanceláře MZe] 

	003

	Název změny[endnoteRef:4]: [4:  Předmět změny – stručná informace, název požadavku] 

	Publikování agend: dynamické přiřazení a zrušení přiřazení předpisu; odchod zaměstnance ze SM; rozšíření oprávnění OSAdmin

	Datum předložení požadavku:
	1.4.2021	Požadované datum nasazení:
	31.5.2022


	Kategorie změny[endnoteRef:5]: [5:  Kategorie změny – kategorie urgentní se využije v naléhavých případech, kdy je třeba vyřešit nedostupnost zásadní funkcionality systému vzhledem ke zpracování agendy, pro jejíž podporu systém slouží.] 

	Normální  ☒     Urgentní  ☐
	Priorita[endnoteRef:6]: [6:  Priorita – vyjadřuje důležitost zapracování požadavku. Vyplní se v případě volby kategorie „Normální změna“.] 

	Vysoká  ☐  Střední  ☐   Nízká ☒

	Oblast:
	Aplikace  ☐       
	Zkratka[endnoteRef:7]:  [7:  Zkratka – zkratka aplikace (viz „kód služby“ v katalogu služeb)] 

	

	
	
	Typ požadavku: 
	Legislativní[endnoteRef:8] ☐   Zlepšení ☒   Bezpečnost ☐ [8:  Typem požadavku „legislativní“ je myšlen požadavek, který vyplývá ze změny právního předpisu, příp. z nového právního předpisu.] 


	
	Infrastruktura  ☐
	Typ požadavku:
	Nová komponenta ☐   Upgrade ☐  Bezpečnost  ☐  Zlepšení  ☐  Obnova  ☐

	Role
	Jméno 
	Organizace /útvar
	Telefon
	E-mail

	
	
	
	
	

	Žadatel:
	Zdeněk Kadlec
	11000
	221814562
	zdenek.kadlec@mze.cz

	Metodický garant:
	Zdeněk Kadlec
	11000
	221814562
	zdenek.kadlec@mze.cz

	Věcný garant:
	Zdeněk Kadlec
	11000
	221814562
	zdenek.kadlec@mze.cz

	Koordinátor změny:
	Monika Jindrová
	12121
	
	monika.jindrova@mze.cz

	Poskytovatel/Dodavatel:
	xxx
	AddSign s.r.o.
	xxx
	xxx


	Smlouva č.[endnoteRef:9]: [9:  Smlouva č. – uvede se, pokud existuje smlouva, v rámci níž se požadavky předkládají, totéž platí pro KL (katalogový list).] 

	56-2021-11150 (S2021-0004)
	KL:
	HR-001

2 Stručný popis a odůvodnění požadavku
2.1 Popis požadavku
Rozšíření aplikace o dynamické přiřazení a zrušení přiřazení předpisu, odchod zaměstnance ze SM a oprávnění pro OSAdmin
2.2 Odůvodnění požadované změny (změny právních předpisů, přínosy)
Přidělování až na úroveň jednotlivých uživatelů je potřeba rozšířit o provozem identifikované funkcionality:
2.2.1 Dynamické přiřazení a zrušení přiřazení předpisu – změna seznamu uživatelem (aktuální verze vychází analogicky ze změny závaznosti dodatkem / novelou – cílem je dynamická změna přiřazení bez aktualizace předpisu) 
2.2.2 Odchod zaměstnance ze SM – úprava importu dat z OS 
2.2.3 Rozšíření oprávnění OSAdmin o možnost definování nových „Agend“ a přiřazování rolí „Vydavatel“ a „Gestor“ k nim

2.3 Rizika nerealizace
Publikování agend (IAŘ či jiné dokumenty podle distribučních seznamů) nebude být moci nasazeno do produkčního prostředí.

3 Podrobný popis požadavku

3.1 Dynamické přiřazení a zrušení přiřazení předpisu – změna seznamu uživatelem (aktuální verze vychází analogicky ze změny závaznosti dodatkem / novelou – cílem je dynamická změna přiřazení bez aktualizace předpisu)  
3.1.1 Přidání SM do distribučního seznamu – automatické doplnění přiřazení a povinnosti seznamovat se s předpisem zaměstnanci zařazeném na SM;  
3.1.2 Odebrání SM ze seznamu – automatické odebrání přiřazení stávající verze předpisu;
3.1.3 Platí pro všechny předpisy, kde byl seznam použit.
3.1.4 Vytvoření náhledu souvisejících změn – seznam dotčených předpisů – před dokončením operace.
 
3.2 Odchod zaměstnance ze SM – úprava importu dat z OS 
3.2.1 Notifikovat obě role (gestor a vydavatel) o této skutečnosti;
3.2.2 Umožnit náhled na související změny v distribučních seznamech a umožnit zachování (návrat přiřazení na SM); 
3.2.3 Rozšíření logování o související stavy aplikace a rozhodnutí uživatelů v příslušných rolích.

3.3 Rozšíření oprávnění pro OSadmin[footnoteRef:1] [1:  doposud má přiřazenu „Správu nově vzniklých útvarů“ a „Mazání zaniklých útvarů s konfigurací přiřazení“] 

3.3.1 Doplnit oprávnění pro OSadmin definovat nové Agendy;
3.3.2 Doplnit oprávnění pro OSadmin přiřazovat k Agendám role Vydavatel a Gestor.


4 Dopady na IS MZe
(V případě předpokládaných či možných dopadů změny na infrastrukturu nebo na bezpečnost je třeba si vyžádat stanovisko relevantních specialistů, tj. provozního, bezpečnostního garanta, příp. architekta.).

4.1 Na provoz a infrastrukturu
Bez dopadu

4.2 Na bezpečnost
Bez dopadu

4.3 Na součinnost s dalšími systémy
Nepožadována

4.4 Požadavky na součinnost AgriBus
(Pokud existují požadavky na součinnost Agribus, uveďte specifikaci služby ve formě strukturovaného požadavku (request) a odpovědi (response) s vyznačenou změnou.)
Nepožadována

4.5 Požadavek na podporu provozu naimplementované změny
(Uveďte, zda zařadit změnu do stávající provozní smlouvy, konkrétní požadavky na požadované služby, SLA.)
Součástí smlouvy

4.6 Požadavek na úpravu dohledového nástroje
(Uveďte, zda a jakým způsobem je požadována úprava dohledových nástrojů.)
Nepožadováno

5 Požadavek na dokumentaci[endnoteRef:10] [10:  Vyplní Koordinátor změny. Uvedený seznam dokumentace je pouze příkladem.] 

	ID
	Dokument
	Formát výstupu (ano/ne)
	Garant[endnoteRef:11] [11:  Garant odpovídá za správnost a úplnost dodané dokumentace a zajišťuje její akceptaci. Např. Provozní dokumentaci posuzuje Oddělení kybernetické bezpečnosti (OKB) a Oddělení provozu a podpory technologíí (OPPT).] 


	
	
	el. úložiště
	papír
	CD
	

	1. 
	Analýza navrhnutého řešení
	Ne
	
	
	

	2. 
	Dokumentace dle specifikace Závazná metodika návrhu a dokumentace architektury MZe[endnoteRef:12] [12:  Rozsah požadované dokumentace uveďte do tabulky.] 

	Ne
	
	
	

	3. 
	Testovací scénář, protokol o otestování
	Ano
	
	
	Zdeněk Kadlec

	4. 
	Uživatelská příručka
	Ano
	
	
	Zdeněk Kadlec

	5. 
	Provozně technická dokumentace (systémová a bezpečnostní dokumentace)
	Ano
	
	
	OKB, OPPT[endnoteRef:13] [13:  OKB – Oddělení kybernetické bezpečnosti, OPPT – Oddělení provozu a podpory technologií] 


	6. 
	Zdrojový kód a měněné konfigurační soubory
	Ano
	
	
	Vladimír Velas

	7. 
	Webové služby + konzumentské testy
	Ne
	
	
	

	8. 
	Dohledové scénáře (úprava stávajících/nové scénáře)[endnoteRef:14] [14:  Požadováno, pokud Dodavatel potvrdí dopad na dohledové scénáře/nástroje.] 

	Ne
	
	
	


V připojeném souboru je uveden rozsah vybrané technické dokumentace – otevřete dvojklikem:   xxx 
Dohledové scénáře jsou požadovány, pokud Dodavatel potvrdí dopad na dohledové scénáře/nástroj. 
U dokumentů, které již existují, se má za to, že je požadována jejich aktualizace. Pokud se požaduje zpracování nového dokumentu namísto aktualizace stávajícího, uveďte toto explicitně za názvem daného dokumentu, např. „Uživatelská příručka – nový“.
Provozně-technická dokumentace bude zpracována dle vzorového dokumentu, který je připojen – otevřete dvojklikem:     xxx  
        

6 Akceptační kritéria
Plnění v rámci požadavku na změnu bude akceptováno, jestliže budou akceptovány dokumenty uvedené v tabulce výše v bodu 5, budou předloženy podepsané protokoly o uživatelském testování a splněna případná další kritéria uvedená v tomto bodu. 

7 Základní milníky

	Milník
	Termín

	Zahájení plnění - Objednávka
	T1

	Zahájení testování
	T2 = T1 + 30

	Dokončení plnění, nasazení na produkci a akceptace
	T3 = T2 + 30


8 Přílohy
1.
2.

9 Podpisová doložka
	Za resort MZe:
	Jméno:
	Podpis:

	Metodický garant[endnoteRef:15] [15:  Pokud není určen metodický garant, podepíše věcné zadání věcný garant.] 

	Zdeněk Kadlec
	

	Koordinátor změny:
	Monika Jindrová
	


			

 Stupeň důvěrnosti: Veřejné v2.2	             	Strana 4 z 4	
B – nabídkA řešení k požadavku Z33790

	ID PK MZe[endnoteRef:16]: [16:  ID PK MZe – pomocný identifikátor požadavku přidělený v pomocné evidenci projektové kanceláře MZe] 

	003

1. Návrh konceptu technického řešení  
Bude realizována požadovaná změna dle požadavku uvedeného v části A v rozsahu:

Dynamické přiřazení a zrušení přiřazení předpisu – změna seznamu uživatelem (aktuální verze vychází analogicky ze změny závaznosti dodatkem / novelou – cílem je dynamická změna přiřazení bez aktualizace předpisu)  
Přidání SM do distribučního seznamu – automatické doplnění přiřazení a povinnosti seznamovat se s předpisem zaměstnanci zařazeném na SM;  
Odebrání SM ze seznamu – automatické odebrání přiřazení stávající verze předpisu;
Platí pro všechny předpisy, kde byl seznam použit.
Vytvoření náhledu souvisejících změn – seznam dotčených předpisů – před dokončením operace.

Odchod zaměstnance ze SM – úprava importu dat z OS 
Notifikovat obě role (gestor a vydavatel) o této skutečnosti;
Umožnit náhled na související změny v distribučních seznamech a umožnit zachování (návrat přiřazení na SM); 
Rozšíření logování o související stavy aplikace a rozhodnutí uživatelů v příslušných rolích.

Rozšíření oprávnění pro OSadmin[footnoteRef:2] [2:  doposud má přiřazenu „Správu nově vzniklých útvarů“ a „Mazání zaniklých útvarů s konfigurací přiřazení“] 

Doplnit oprávnění pro OSadmin definovat nové Agendy;
Doplnit oprávnění pro OSadmin přiřazovat k Agendám role Vydavatel a Gestor.

Nové role budou přebírány (případně synchronizovány) z (s) LDAP.

1. Uživatelské a licenční zajištění pro Objednatele
V souladu s podmínkami smlouvy č. 56-2021-11150.
1. Dopady do systémů MZe

2. Na provoz a infrastrukturu
(Pozn.: V případě, že má změna dopady na síťovou infrastrukturu, doplňte tabulku v připojeném souboru - otevřete dvojklikem.) xxx    
Nepředpokládají se.
2. Na bezpečnost
Návrh řešení musí být v souladu se všemi požadavky v aktuální verzi Směrnice systémové bezpečnosti MZe. Upřesnění požadavků směrnice ve vztahu k tomuto RfC:
	Č.
	Oblast požadavku[endnoteRef:17] [17:  Jednotlivé oblasti – položky v tabulce korespondují s kapitolami Standardu systémové bezpečnosti.] 

	Předpokládaný dopad a navrhované opatření/změny

	1. 
	Řízení přístupu 3.1.1. – 3.1.6.[footnoteRef:3] [3:  Uveďte, zda vznikají servisní účty a budou řízené PIMem nebo v něm budou jen evidované.] 

	Bez dopadu

	2. 
	Dohledatelnost provedených změn v datech 3.1.7.
	Bez dopadu

	3. 
	Centrální logování událostí v systému 3.1.7.[footnoteRef:4] [4:  Uveďte, zda a jakým způsobem se mění/vytváří napojení na SIEM.] 

	Bez dopadu

	4. 
	Šifrování 3.1.8., Certifikační autority a PKI 3.1.9.
	Bez dopadu

	5. 
	Integrita – constraints, cizí klíče apod. 3.2.
	Bez dopadu

	6. 
	Integrita – platnost dat 3.2.
	Bez dopadu

	7. 
	Integrita - kontrola na vstupní data formulářů 3.2.
	Bez dopadu

	8. 
	Ošetření výjimek běhu, chyby a hlášení 3.4.3.
	Bez dopadu

	9. 
	Práce s pamětí 3.4.4.
	Bez dopadu

	10. 
	Řízení - konfigurace změn 3.4.5.[footnoteRef:5] [5:  Uveďte, zda má RfC vliv na napojení na Management zranitelností (Vulnerability scanner).] 

	Bez dopadu

	11. 
	Ochrana systému 3.4.7.
	Bez dopadu

	12. 
	Testování systému 3.4.9.
	Bez dopadu

	13. 
	Externí komunikace 3.4.11.
	Bez dopadu

2. Na součinnost s dalšími systémy

2. Na součinnost AgriBus

2. Na dohledové nástroje/scénáře[endnoteRef:18] [18:  Pokud z vyhodnocení dopadů vyplyne potřeba upravit dohledové scénáře nebo zpracování nového scénáře, pak se má za to, že položka seznamu „Požadavek na dokumentaci“ v b. 5 části A RfC „Dohledové scénáře (úprava stávajících/nové scénáře)“ je vyžadována a bude součástí akceptačního řízení, nebude-li v části C RfC v bodu 1 „Specifikace plnění“ stanoveno jinak.] 


2. Ostatní dopady
(Pozn.: Pokud má požadavek dopady do dalších požadavků MZe, uveďte je také v tomto bodu.)

1. Požadavky na součinnost Objednatele a třetích stran
	MZe / Třetí strana
	Popis požadavku na součinnost

	
	

	
	


(Pozn.: K popisu požadavku uveďte etapu, kdy bude součinnost vyžadována.)

1. Harmonogram plnění[endnoteRef:19] [19:  Uvede se datum zahájení a ukončení realizace, příp. další etapy.] 

	Popis etapy
	Termín

	Nasazení testovací verze + testovací scénáře + uživatelská dokumentace
	25 dnů od objednání

	Uživatelské testování MZe
	5 dnů od nasazení na testovací prostředí

	Nasazení produkční verze 
	5 dnů od ukončení testování

1. Pracnost a cenová nabídka navrhovaného řešení
včetně vymezení počtu člověkodnů nebo jejich částí, které na provedení poptávaného plnění budou spotřebovány
	Oblast / role[endnoteRef:20] [20:  Role se vyplní pouze v relevantních případech, např. u požadavku na infrastrukturu.] 

	Popis
	Pracnost v MD/MJ
	v Kč bez DPH
	v Kč s DPH

	
	
	
	
	

	Analýza
	Interní analýza a návrh realizace požadavku
	1 MD
	10 500,00
	12 705,00

	Vývoj
	Realizace požadovaných změn
	10 MD
	105 000,00
	127 050,00

	Testování
	Interní testování
	1,5 MD
	15 750,00
	19 057,50

	Dokumentace
	Vypracování testovacích scénářů a doplnění uživatelské dokumentace
	1 MD
	10 500,00
	12 705,00

	Administrativa
	Administrativní zajištění požadavku
	0,5 MD
	5 250,00
	6 352,50

	Celkem:
	14 MD
	147 000,00
	177 870,00

(Pozn.: MD – člověkoden, MJ – měrná jednotka, např. počet kusů)


Případné další informace.

1. Přílohy
	ID
	Název přílohy
	Formát 
(CD, listinná forma)

	
	
	

	
	
	


1. Podpisová doložka
	Název Dodavatele
	Jméno oprávněné osoby[endnoteRef:21] [21:  Oprávněná osoba – smluvně určená osoba oprávněná k předkládání požadavku na předložení nabídky.] 

	Podpis

	AddSign s.r.o.
	xxx
	


Stupeň důvěrnosti: Veřejné v2.2		Strana 3 z 3	
C – Schválení realizace požadavku Z33790

	ID PK MZe[endnoteRef:22]: [22:  ID PK MZe – pomocný identifikátor požadavku přidělený v pomocné evidenci projektové kanceláře MZe] 

	003

1. Specifikace plnění
Požadované plnění je specifikováno v části A a B tohoto RfC. 
Dle části B bod 3.2 jsou pro realizaci příslušných bezpečnostních opatření požadovány následující změny[footnoteRef:6]: [6:  Potvrzení realizace příslušných opatření/změn vyznačí posuzovatel za Oddělení kybernetické bezpečnosti.] 

	Č.
	Oblast požadavku
	Realizovat
(ano ☒ / ne ☐)
	Upřesnění požadavku

	1. 
	Řízení přístupu 3.1.1. – 3.1.6.
	☐	

	2. 
	Dohledatelnost provedených změn v datech 3.1.7.
	☐	

	3. 
	Centrální logování událostí v systému 3.1.7.
	☐	

	4. 
	Šifrování 3.1.8., Certifikační autority a PKI 3.1.9.
	☐	

	5. 
	 Integrita – constraints, cizí klíče apod. 3.2.
	☐	

	6. 
	Integrita – platnost dat  3.2.
	☐	

	7. 
	Integrita - kontrola na vstupní data formulářů 3.2.
	☐	

	8. 
	Ošetření výjimek běhu, chyby a hlášení 3.4.3.
	☐	

	9. 
	Práce s pamětí 3.4.4.
	☐	

	10. 
	Řízení - konfigurace změn 3.4.5.
	☐	

	11. 
	Ochrana systému 3.4.7.
	☐	

	12. 
	Testování systému 3.4.9.
	☐	

	13. 
	Externí komunikace 3.4.11.
	☐	

1. Uživatelské a licenční zajištění pro Objednatele (je-li relevantní):
1. Požadavek na součinnost
	Útvar / Dodavatel
	Popis požadavku na součinnost
	Odpovědná osoba

	Gestor
	Součinnost při testování
	Zdeněk Kadlec


(V případě, že má změnový požadavek dopad na napojení na SIEM, PIM nebo Management zranitelnosti dle bodu 1, uveďte také požadovanou součinnost Oddělení kybernetické bezpečnosti.)

1. Harmonogram realizace[endnoteRef:23] [23:  Uvede se datum zahájení a ukončení realizace, příp. další etapy.] 

	Popis etapy
	Termín

	Nasazení testovací verze + testovací scénáře + uživatelská dokumentace
	25 dnů od objednání

	Uživatelské testování MZe
	5 dnů od nasazení na testovací prostředí

	Nasazení produkční verze 
	5 dnů od ukončení testování


1. Pracnost a cenová nabídka navrhovaného řešení
včetně vymezení počtu člověkodnů nebo jejich částí, které na provedení poptávaného plnění budou spotřebovány
	Oblast / role[endnoteRef:24] [24:  Role se vyplní pouze v relevantních případech, např. u požadavku na infrastrukturu.] 

	Popis
	Pracnost v MD/MJ
	v Kč bez DPH:
	v Kč s DPH:

	
	
	
	
	

	Analýza
	Interní analýza a návrh realizace požadavku
	1 MD
	10 500,00
	12 705,00

	Vývoj
	Realizace požadovaných změn
	10 MD
	105 000,00
	127 050,00

	Testování
	Interní testování
	1,5 MD
	15 750,00
	19 057,50

	Dokumentace
	Vypracování testovacích scénářů a doplnění uživatelské dokumentace
	1 MD
	10 500,00
	12 705,00

	Administrativa
	Administrativní zajištění požadavku
	0,5 MD
	5 250,00
	6 352,50

	Celkem:
	14 MD
	147 000,00
	177 870,00

(Pozn.: MD – člověkoden, MJ – měrná jednotka, např. počet kusů)


1. Posouzení
Bezpečnostní garant, provozní garant a architekt potvrzují svým podpisem za oblast, kterou garantují, správnost specifikace plnění dle bodu 1 a její soulad s předpisy a standardy MZe a doporučují změnu k realizaci. 
	Role
	Jméno
	Podpis/Mail[endnoteRef:25] [25:  Doplní se podpis nebo se uvede odkaz na mailovou zprávu, v které bylo posouzení doručeno.] 


	Bezpečnostní garant
	Karel Štefl
	

	Provozní garant
	Ivo Jančík
	

	Architekt
	----------
	


(Pozn.: RfC se zpravidla předkládá k posouzení Bezpečnostnímu garantovi, Provoznímu garantovi, Architektovi, a to podle předpokládaných dopadů změnového požadavku na bezpečnost, provoz, příp. architekturu. Koordinátor změny rozhodne, od koho vyžádat posouzení dle konkrétního případu změnového požadavku.)

1. Schválení
Svým podpisem potvrzuje požadavek na realizaci změny:
	Role
	Jméno
	Podpis

	Žadatel
	Zdeněk Kadlec
	

	Věcný garant
	Zdeněk Kadlec
	

	Koordinátor změny
	Monika Jindrová
	

	Oprávněná osoba dle smlouvy
	Vladimír Velas
	


(Pozn.: Oprávněná osoba se uvede v případě, že je uvedena ve smlouvě.)

Vysvětlivky

MZE-15241/2022-12121	5