O metodike Red Flags


#1

Slovensko.Digital realizuje projekt Red Flags s podporou Fondu pre transparentné Slovensko v Nadácii Pontis a Veľvyslanectva USA na Slovensku. Prinášame základné informácie o projekte a prvú možnosť zapojiť sa:

Hlavným cieľom projektu Red Flags
je rozšírenie systematickej kontroly IT projektov verejnej správy a vytváranie tlaku na ich kvalitu cez verejnú kontrolu projektov, ktoré vykazujú vysokú mieru rizika alebo nedostatkov.

V štátnej správe na Slovensku vzniká množstvo projektov, ktoré core team Slovensko.Digital nie je schopný analyticky pokryť. Rozhodli sme sa naše vedomosti o kľúčových problémových aspektoch projektov rozšíriť širšej IT komunite a zverejniť ich pre širokú verejnosť.

V rámci projektu Red Flags vytvoríme univerzálny model,
na základe ktorého bude možné kriticky vyhodnotiť projekty v štátnom IT. Tento model bude voľne dostupný pre IT komunitu i širokú verejnosť. S jeho pomocou bude môcť ktokoľvek identifikovať problémové časti IT projektov a pomáhať tak efektívnejšie bojovať proti korupcii na Slovensku. Keďže tento model chceme pripravovať v spolupráci s odbornou komunitou, prinášame jeho prvý draft na verejné komentovanie:

Draft modelu Red Flags

Okrem modelu, všetky informácie o projektoch a hodnotenia otázok budeme udržiavať v jednoducho použiteľnej a prehľadnej forme dostupnej online.

Akékoľvek ďalšie otázky a komentáre k projektu, či draftu modelu radi zodpovieme v tom vlákne.


O kategórii Red Flags: Projekty
Ako hodnotíme
Štúdie uskutočniteľnosti projektov
Často kladené otázky
Red Flags: Zvyšovanie úžitkovej hodnoty digitálnych služieb pre občanov, podnikateľov a inštitúcie verejnej správy
Red Flags: Zavedenie služieb Platform as a Service
#2

Zatiaľ len zbežný pohľad, ale zarazilo ma, že legislatíva sa spomína až vo fáze realizácie a aj to len či bola zmena legislatívy navrhnutá, a pod. Modelový príklad, kedy to môže byť už neskoro, resp. nerealizovateľné - niekto príde a návrhom projektu, ktorý síce vyzerá zaujímavo/užitočne, ale je v príkrom rozpore s niektorými ustanoveniami celoeurópsky platnej legislatívy (pre ilustráciu navrhujem uvažovať ochranu osobných údajov, konkrétne už dosť spomínané GDPR, teda General Data Protection Regulation). Zmena takej legislatívy čisto kvôli jednému takému projektu je utópia, resp. keby aj bola šanca, zmena EU legislatívy trvá roky!


#3

Za mna nateraz tieto veci:

  1. z coho konkretne vyplyva Princip default open source? Mozem poprosit linku/odkaz, kde sa tento princip popisuje?

  2. v ramci pripravnej fazy projektov (teraz to plati vseobecne, nielen pre tento vas projekt) by malo byt zo strany navrhovatela projektu deklarovane, ci ma odborne kapacity na projekt inhouse a ktore aktivity projektu bude tymito kapacitami zabezpecovat, napr. ci bude nejaky modul vyvijat sam, alebo ci bude projektove riadenie realizovat inhouse kapacitami alebo si nakontrahuje dalsi externy subjekt. Po par projektoch a organizaciach, co som videl, tak toto zacina byt klucovy element uspechu a udrzatelnosti projektu.

  3. v ramci pripravy (opat plati vseobecne, nielen pre tento vas projekt) by mala byt zadefinovana strategia:
    rozdelenia obstaravania jednotlivych casti projektu - casto sa obstaravaju niektore aktivity ako sucast diela a pritom by mohli byt obstarane samostatne a teda aj realizovane v inom case - napr. UX
    naslednosti realizacie jednotlivych casti/aktivit projektu - napr. niektore aktivity nema vyznam riesit hned od zaciatku projektu, napr. BI alebo nieco podobne, nakolko v rannych fazach projektu sa vela toho moze menit a to moze mat negativne dopady a navysovanie pracnosti na BI

  4. riadok Autorske prava - asi tym myslite majetkove prava. Autorske prava sa nedaju preniest na osobu, ktora kupuje dielo, ale majetkove ano. Nasledne kupujuci s dielom moze nakladat tak, ako sa dohodol s autorom.

  5. zmysluplne nadimenzovany HW - no HW by sa mal kupovat ako posledny v ramci celeho projektu, pripadne agilne podla rastujecej funkcionality IS a nie niekde na zaciatku. Vtedy sa neda urobit ziadna normalna estimacia HW.


#4

@janhargas @Lubor viete mi poradit s otazkou vyssie? dik


#5

Myslim ze primarne z tohto: https://www.gov.uk/service-manual/technology/working-with-open-standards

You must use open standards when designing and building your service unless you’ve been granted an exemption.

Using open standards means you can:

  • share data between services and systems more easily
  • avoid getting ‘locked in’ to a specific piece of technology or supplier
  • reuse software components built by others, including open source components
  • reduce the overall cost of your digital service
  • change your service’s design over time more easily

Meeting the Digital Service Standard
To pass point 9 (use open standards and common platforms), you must:

  • avoid contracts that lock you into proprietary software
  • connect your service to other government platforms and systems to make the user’s experience consistent
  • reuse solutions from other government services that can meet the same user need

Suvisiace - pre inhouse vyvoj (tam je to logicke) - https://www.gov.uk/service-manual/service-standard/make-all-new-source-code-open


#6

v NKIVS alebo niecom podobnom nie je takyto princip definovany? Lebo s uradnikmi v SR pohne len dokument/pokyn zo SR a nie manual z UK


#7

…este by bolo dobre mat moznost zadefinovat, kto sa realne podielal na realizacii projektu…ktore firmy boli, ci uz priznani alebo nepriznani subdodavatelia…ciel je odclenit zrno od pliev a hladat korelacie medzi lepsi projektami a subjektami, ktore ich dodavali a potom sa pytat, ze preco taketo firmy nedostavaju prilezitosti byt priamymi dodavatelmi/clenmi konzorcii…


#8

Zdravím,
niekoľko vecí, lebo zrejme sa jedná o starší dokument (koncept) a neviem nakoľko autor prešiel na novú terminológiu

  • terminologia (treba zosúladiť s aktuálnym stavom, nie sú napr. eGOV služby ale KS, AS, IS… a pod), v rámci štúdie nie je predmet štúdie, sú tam iné kapitoly,

Teraz trošku ku metodike písania toho modelu:

  • Celkove tie body idú tak hore-dole, možno by bolo dobré metodiky pre každú oblasť napísať, alebo z akých metodík sa vychádza pri posudzovaní tej ktorej oblasti (aby bol jasný aj prijímateľovi čo má splniť, aby bol ready) - v podstate každá s tých vecí vychádza z nejakých legislatív asi štandardov, zahraničie a pod…
  • fázy projektu sú v zmysle PRINCE alebo Výnosu - inicializačná, prípravná… atď ak chcete riešiť iné členenie, potom OK ale treba asi napísať ako postupovať a ako tú etapu identifikovať v projekte (lebo ju nemusí mať :slight_smile:
  • pre každé hodnotenie by sa mal stanoviť cieľ (napr. produkt, aktivita a pod) a kritériá kvality pre každý ciel alebo to čo hodnotníme
  • všetky ciele by mali mať jasnú hierarchiu, t.j. aby relevantné kritériá a ciele na seba nadväzovali
  • chýbajú stanovené tolerancie, t.j. kedy je to už stop a kedy ešte ready (t.j. čo ak, čo potom?) čo tak korekcie a opravné postupy …

ku konkrétnym veciam asi, ked to bude konzistentnejšie :slight_smile:


#9

V rámci projektu Red Flags pripravujeme workshopy v Žiline, Košiciach a Bratislave. Predbežné eventy (na save the date) tu:

Žilina
Košice
Bratislava

Čoskoro doplníme aj podrobnosti ohľadom obsahu a presnejšieho miesta aktivity v daných mestách. Akékoľvek nápady, čo by na nich nemalo chýbať, vítame. Pridajte sa prosím na tieto eventy, prípadne o nich povedzte kamošom, ktorých by to zaujímalo.


#10

A post was merged into an existing topic: O kategórii Red Flags


#11

Mame novinku! Ako sa da zapojit do hodnotenia red flags


#12

Ahojte, pozeral som si teraz draft s kritériami.
Veľmi som zvedavý, na diskusiu v časti realizácia. Sú tam kritériá projektová dokumentácia, harmonogram projektu, analytická dokumentácia … a potom samozrejme agile :). Pričom niektoré z týchto vecí sa ťažko zosúlaďujú, často idú proti sebe (agile chce len minimum dokumentácie, tu sú jej venované aspoň dve kritériá a pôsobia mierne vodopádovo; harmonogram/miľníky/kontroly/plnenie opäť ťažšie uchopiteľné v agile prístupe). Nevravím, že zle a že sa nedá, len že som zvedavý, ako sa podarí tieto komplikované, protichodné a užitočné veci skĺbiť. Teším sa na tú diskusiu. Možno by nebolo zlé osloviť aj slovenskú agile komunitu a pokúsiť sa ju zapojiť (podobne ako napr. UX) aj do riešenia slovenského eGov.


#13

zdravim vsetkych, mne v hodnoteni redflags chyba hodnotenie bezpecnostnych aspektov projektov. ci uz v zadani projektu (napr. poziadavky z legislativy a pod), alebo potom aj v ramci projektu (napr. rizikova analyza, vyhodnotenie bezp. dopadov na ine systemy a pod) plus urcite este niekolko dalsich veci. nepremysla sa nad niecim takym?


#14

To je dobrá otázka. Našim cieľom nie je totiž pokryť “všetko” čo sa projektov týka, ale špeciálne veci ktoré sú rizikové, v čom doterajšie projekty mali zlé/slabé výsledky, alebo čo môže indikovať problém do budúcnosti.
Aké teda boli “red flags” v bezpečnosti doterajších projektov?


#15

Neexistencia poziadavky na spracovanie bezpecnostneho projektu v zadani, nedefinovanie bezpecnostnych poziadaviek v zadani, neuvadzanie legislativnych predpisov suvisiacich s infosec v zadani, ktore maju dopad na predmet projektu , napriklad :slight_smile:


#16

Daj prosím konkrétny príklad kde to takto bolo a viedlo to k zlému výsledku, nejako si neviem spomenúť (a zvonka to nevidno).


#17

Myslim ze priklady uvadzat netreba. :slight_smile: ty aj ja dobre vieme, ze ked sa v projektoch nezadefinuju bezpecnostne poziadavky, vznika big security problem. A este som zabudol na chybajuce bezpecnostne testy…


#18

IvanK to dobre zhrnul. podla mna bezpecnost nieje “vsetko”. netreba ist hlboko, ale imho by mal existovat jeden - dva redflagy, ktore by ukazovali, ako vyrazne v projekte na bezpecnost mysleli. Podstatna by asi bola existencia niecoho ako rizikovka, aby bolo jasne co treba v projekte pokryt. A existuje cast projektov s vyraznym bezpecnostnym aspektom - u tych by mohli byt dalsie dodatocne redflags.
Ako priklad mozes brat hoci aj aktualnu kauzu eID - je evidentne, ze ani v takto dolezitom a bezpecnostne citlivom projekte nebolo myslene na incident response, alebo IR plan nieje dodrziavany. aspon to tak zvonka vyzera.
Robim bezpecnost aj v statnych projektoch a nepamatam, ze by boli niekde v zadani projektu realne pouzitelne security poziadavky.
Bezp. testy sa uz aspon vo forme externych blackbox pentestov musia robit (csirt), ale nic viac pokial viem nieje.


#19

Najvacsi problem s bezpecnostou v statnej sprave je implementacia procesnych opatreni. Aj ked dodavel nachysta policy, postupy, procedury usije to na mieru potrebam konkretneho ministerstva, tak nema to kto robit. Vsetci maju zufaly personalny podstav, za tie ich prachy nikto kvalifikovaneho bezpecaka robit nepojde. Iste, toto nema s redflags projektu nic spolocne. Ale treba si to uvedomit. Mozno cesta vedie cez specializovane SLA na security. MSS. Ked sa schvali kybersec zakon, budu musiet vybudovat vpa-cky. Som fakt zvedavy kto to zvladne.


#20

Len malu poznamku. Ak mas ludi, rozpocet a volu agile nemusi ist proti poziadavkam na dokumentaciu. Len si treba uvedomit, ze sa vodopadovo na dokuemntaciu necaka. Veci sa dohodnu na workshope/telcu… a vyvojar ich hned implementuje a analytik paralelne zakresluje, popisuje. castokrat je softverova cast skor ako UML/dolkumentacna. ak vsak najdes dobru techniku (toolbox a postupy) ako tu analyzu vyuzit na tvorbu priruciek, helpov, skoliacich materialov … tak si vyhral … inak bude dokuentacia furt pozadu … avsak je si treba uvedomit ze RELEASE bez dokumentacie neodovzdas (pokial nefejkujes). Takze v sprinte musi byt vzdy aj cas na dokumentaciu ak teda chcem dodrzat pravidlo ze na konci sprintu musi byt chodivy a odovzdatelny release.