Minitendr č. 57 v rámci VZ Sdílený informační systém TA ČR - etapa 2 (bez obnovení soutěže) - podruhé

Předmět zakázky

Název provozní potřeby Minitendr č. 57 Cíle minitendru: 1. Existuje byznysová služba „Správa hodnotitelů”, která svým rozsahem funkcionalit podporuje evidenci hodnotitelů, jejich zasmluvnění a objednávání činností a vykazování činností hodnotitelů. 2. Přírůstek Správy hodnotitelů MVP leden 2023 svými funkcionalitami podporuje agendu správy resortních potřeb a je nasazen v produkčním prostředí. 3. Byznysová služba „Správa hodnotitelů” splňuje funkční požadavky popsané v analytické zprávě, produktovém backlogu a dále respektuje požadavky na UI dle předaného prototypu vytvořeného v SW Figma. 4. Byznysová služba „Správa hodnotitelů” je rozdělena na soubor menších služeb či vyvinuta tak, aby v principu umožňovala budoucí rozdělení na samostatné mikroslužby bez většího úsilí/kompletního přepracování služby. 5. Existuje Bitbucket repozitář se zdrojovými kódy a dokumentací byznysové služby „Správa hodnotitelů”. Ops tým TA ČR je schopen vlastními silami službu nasadit do testovacího/produkčního prostředí GCP. 6. Existuje popis specifických datových entit (slovník pojmů a jednotlivé datové položky v datovém slovníku) souvisejících s byznys službou „Správa hodnotitelů” k doplnění do datového katalogu spravovaného TA ČR. Povinné otázky Požadavky a otázky, které dodavatel odpoví již ve svém návrhu řešení: 1. Popište konceptuální rámec řešení byznysové služby „Správa hodnotitelů”, který bude zasazen do výše uvedených položek: potřebnost (B2), nejistota (B3), cíle minitendru (B4), analytické zprávy a produktového backlogu MT057. Účastník rámcové dohody není ve svém návrhu řešení omezen, může navrhnout programování „na klíč”, využití open source projektů, případnou kombinaci obou přístupů. Zadavatel z opatrnosti připomíná, že z rámcové dohody nelze pořizovat „krabicové” SW zatížené licenčními a maintenance poplatky. 2. Rozdělili byste řešení byznysové služby „Správa hodnotitelů” na více menších samostatných mikroslužeb? Pokud ano, jakým způsobem a podle jakého klíče? (odpověď bude vycházet z předchozího bodu). 3. Jsou všechny požadavky uvedené v analytické zprávě a produktovém backlogu srozumitelné? Pokud ne, definujte negativní vymezení (Analytická zpráva s produktovým backlogem budou připojeny k dílčí smlouvě jako závazné přílohy definující rozsah řešení miniprojektu). 4. Zadavatel umožní tři dílčí fakturace za dodávku byznysové služby správy hodnotitelů dle požadavků uvedených v B9 specifikace zadání minitendru. Ve svém návrhu řešení rámcově popište jakými funkcionalitami budou jednotlivé přírůstky disponovat (definice „kdy je hotovo”). Otázky, na které dodavatel odpoví v průběhu řešení: 1. Jaká konkrétní doporučení směřující k rozvoji níže uvedených položek navrhujete: a. pravidel architektury, b. pravidel platformy, c. pravidel vývoje, d. pravidel vedení dokumentace, e. procesům a kultuře Dev/Ops v rámci společného fungování, f. existujících průřezových či byznysových služeb SISTA. Minimální výstupy ● Byznysová služba „Správa hodnotitelů” splňující požadavky analytické zprávy a produktového backlogu MT057. MVP „Správa hodnotitelů” verze leden 2023 podporuje výkon agend spojených s resortními potřebami. ● Zdrojové kódy byznysové služby „Správa hodnotitelů” v repozitáři Bitbucket dle pravidel vývoje. ● Dokumentace byznysové služby „Správa hodnotitelů” v repozitáři Bitbucket dle pravidel vedení dokumentace. ● Doplnění specifických datových entit (slovník pojmů a jednotlivé datové položky do datového slovníku) souvisejících s byznys službou „Správa hodnotitelů” do datového katalogu dle pravidel vývoje. ● Podklady scrumových událostí (revize a retrospektivy sprint ) ve formě prezentací a dokumentů dle šablon v projektové knihovně. ● Závěrečná prezentace byznysové služby „Správa hodnotitelů” pro ostatní účastníky rámcové dohody formou praktické ukázky funkcionalit a dokumentace. ● Konzultace nad otázkami a koncepty řešení v rozsahu dle B12. Výkazy konzultací budou předmětem akceptačního řízení. Poznámka: ● Ostatní výstupy minitendru budou respektovat principy popsané v kapitole „3.3. SW nástroje a formáty souborů” dokumentu „Základní principy a procesy řízení projektu”. ● Nejvhodnější formu každého výstupu řešení minitendru určí vlastník produktu po dohodě s řešitelem minitendru. Primárním formátem dokumentů je AsciiDoc.