Slovník pojmů eGovernmentu
Speciální | A | Á | B | C | Č | D | Ď | E | É | Ě | F | G | H | CH | I | Í | J | K | L | M | N | Ň | O | Ó | P | Q | R | Ř | S | Š | T | Ť | U | Ú | Ů | V | W | X | Y | Ý | Z | Ž | VŠE
P |
|---|
PRINCE2 (Projects IN Controlled Environments 2)Metodika je široce používaná ve veřejném sektoru v Evropě, včetně České republiky. Staví na myšlence projektů rozdělených do etap s jasným rozhodovacím bodem mezi nimi. Definuje role jako je projektový manažer, zadavatel, uživatel a dodavatel a jejich odpovědnosti. Součástí PRINCE2 je sada řídicích dokumentů, které pomáhají sledovat cíle, rizika, náklady a přínosy projektu. Ve veřejné správě se PRINCE2 používá zejména u větších ICT a organizačních projektů s více zúčastněnými stranami. Výhodou je strukturovaný přístup a důraz na business case – zdůvodnění, proč projekt dává smysl. Nevýhodou může být, pokud se metodika aplikuje příliš rigidně a vznikne přehnaná administrativní zátěž. V praxi je efektivní kombinovat PRINCE2 s agilními principy a přizpůsobit rozsah dokumentace velikosti projektu.
| |
PUE (efektivita využití energie)PUE blížící se 1 znamená efektivní provoz s nízkými režijními ztrátami. Zlepšení přináší moderní chlazení, zónování a rekuperace tepla. Veřejný sektor může PUE používat v KPI pro udržitelnost a výběr dodavatelů. Pozor na srovnatelnost – PUE se mění se zatížením a klimatem. Doplnění o uhlíkovou stopu dává úplnější obrázek dopadu. Investice do efektivity musí být vyváženy spolehlivostí a redundancí. Transparentní reportování zvyšuje důvěru a motivaci k optimalizaci. Chybí-li sledování PUE rostou náklady i environmentální zátěž. | |
PaaS (platforma jako služba)PaaS poskytuje běhová prostředí, databáze a integrační služby, takže týmy řeší hlavně kód a konfiguraci. Škáluje automaticky a zkracuje čas od vývoje k nasazení díky integrovanému CI/CD. Bezpečnost a aktualizace rámců zajišťuje poskytovatel, ale odpovědnost za konfiguraci a data má zákazník. Dobře se hodí pro standardní webové a API služby, méně pro extrémně specifické middleware. Náklady přechází do OPEX a Je nezbytné hlídat spotřebu a limity plánů. řídicí rámec vyžaduje katalog povolených služeb, tagging a politiky přístupu. Exit strategie (portabilita) brání uzamčení u dodavatele. Chybí-li standardizace pravděpodobně vznikne „zoo“ různých PaaSů v jedné organizaci. | |
Penetrační testyCílem je bezpečně odhalit slabiny dřív než útočník a ověřit účinnost kontrol. Testy pokrývají aplikace, infrastrukturu, API i sociální inženýrství podle předem daného rozsahu. Podstatné v praxi je povolení, časové okno a pravidla, aby nedošlo k ohrožení produkce. Výstupem je report s důkazy, dopady a prioritami nápravy, který musí někdo vlastnit. Retesty ověřují, že opravy skutečně fungují a nezavedly nové chyby. Pen_test je doplněk, ne náhrada bezpečného vývoje, code review a automatizovaných skenů. Ve veřejné správě se hlídá auditní stopa, klasifikace dat a oznamování incidentů. Špatně řízený test končí falešným pocitem bezpečí.
| |
Pečetění dokumentůElektronická pečeť se liší od elektronického podpisu tím, že je vázaná na právnickou osobu nebo orgán veřejné moci, nikoli na konkrétní fyzickou osobu. Používá se například pro hromadné výstupy ze systémů, potvrzení, výpisy nebo automaticky generované dokumenty. Pečeť zajišťuje, že příjemce může ověřit, že dokument skutečně pochází z daného úřadu a nebyl po vystavení změněn. V eGovernmentu je pečetění dokumentů důležité pro důvěryhodnost automatizovaných služeb bez nutnosti ručního podepisování. Technické řešení musí podporovat správu kvalifikovaných certifikátů a bezpečné úložiště klíčů. Proces pečetění by měl být integrován přímo do informačního systému, aby nevznikaly ruční „obchvaty“. Bez dobré správy pečetí hrozí buď zneužití, nebo nefunkčnost ověřování na straně příjemců. V praxi je důležité nastavit i organizační pravidla – kdo pečeti spravuje, kdo schvaluje jejich použití a jak se eviduje pečetěná korespondence.
| |
Phase A – Vize architekturyFáze A definuje, proč se transformace dělá, koho se týká a jaký přínos přinese. Vzniká „vision“ s vysokou úrovní cílové architektury a business case. Identifikují se stakeholdery, rizika a principy, které projekt musí respektovat. Klíčová jsou kritéria úspěchu a metriky, aby šlo později měřit přínosy. Fáze stanoví rozsah a hranice programu a navrhuje přístup k řízení změny. Schvaluje se mandát pokračovat do podrobného rozpracování. Artefakty jsou stručné a srozumitelné pro vedení. Chybí-li silné vize se další fáze roztříští do dílčích iniciativ bez dopadu. | |
Phase B – Business architekturaPopisuje, jak má organizace fungovat, aby naplnila vizi a cíle. Mapuje schopnosti (capabilities), procesy, role, pravidla a metriky. Identifikuje mezery mezi „as-is“ a „to-be“ a navrhuje scénáře změn. Důraz je na hodnotu pro uživatele a sladění s legislativou a politikami. Artefakty jsou například capability mapy, procesní modely a business katalogy. Výstupy slouží jako vstup pro informační a technologickou architekturu. řídicí rámec zajišťuje, že business rozhodnutí řídí technologie, ne naopak. Chybí-li jasné business vrstvy hrozí technicky skvělé, ale zbytečné řešení.
| |
Phase C – Architektura ISDefinuje strukturu aplikací, jejich rozhraní a datové entity potřebné k podpoře businessu. Vznikají aplikační katalogy, integrační mapy a logické datové modely. Řeší se sémantika, kvalita dat a zásady sdílení („jednou a dost“). Důležitá je interoperabilita a oddělení zodpovědnosti mezi systémy. Identifikují se konsolidace, vypínání duplicit a kandidáti na sdílené služby. Bezpečnost a ochrana soukromí se navrhují jako součást modelu, ne dodatečně. Artefakty musí být propojené na business schopnosti a metriky. Špatná datová vrstva rozbije i perfektní aplikace.
| |
Phase D – Technologická architekturaVytváří referenční architektury pro sítě, výpočet, úložiště, identitu a provozní nástroje. Definuje standardy, cloud/on-prem strategie a nefunkční parametry (SLO, bezpečnost). Mapuje závislosti, kapacitní plány a požadavky na dostupnost a DR. Zohledňuje správu konfigurací, automatizaci a observabilitu. Vyhodnocuje varianty podle nákladů, výkonu a rizik. Artefakty se váží na aplikační a datové potřeby, aby se předešlo „overengineeringu“. Chybí-li jasných standardů roste technická rozmanitost a náklady. | |