Red Flags: Zavedenie služieb Platform as a Service

mv
redflags

#1

Názov: Zavedenie služieb Platform as a Service

Garant: Ministerstvo vnútra SR

Stručný opis: Projekt má zaviesť moderné procesy a nástroje pre zrýchlenie nasadzovania aplikácii v prostredí cloudu a poskytnúť niektoré nové služby.

Náklady na projekt: 39 372 460 EUR (celkové náklady na vlastníctvo zo štúdie)

Aktuálny stav projektu: Prebehlo verejné pripomienkovanie, čaká sa na schválenie štúdie.


Zhrnutie hodnotenia Red Flags: Projekt ide v súlade s cieľmi strategických priorít a je dôležitým krokom k zrýchleniu nasadzovania aplikácii, racionalizácii využívania licencovaného softvéru a údržby dôležitých. Chýba alternatíva pre využitie verejného cloudu, ktorá je bežne využívaná v zahraničí. Nákladové položky obsahujú odhady prácnosti na vývoj, ktoré nie sú podložené dostupnými zdrojmi a naopak obsahujú licencie a moduly, ktoré sú duplicitné k iným centrálnym projektom.

Odporúčanie Slovensko.Digital: Do štúdie je potrebné doplniť uveriteľné a overiteľné odhady nákladov jednotlivých častí indikatívneho rozpočtu a popísať tieto časti aj v samotnej štúdii. Štúdiu by bolo vhodné rozšíriť aj o zváženie alternatívy využívania hybridného cloudu. Duplicitné moduly k iným centrálnym projektom odporúčame úplne odstrániť z projektu. Sme presvedčení, že na úrovni štúdie nie je možné schváliť konkrétny zoznam produktov, ktoré budú zaradené do PaaS, ale po jej schválení je potrebné ďalej participatívnym spôsobom pracovať na príprave katalógu PaaS služieb.

:triangular_flag_on_post: HODNOTENIE RED FLAGS

I. Prípravná fáza

Reforma VS (nehodnotené)

Reformný zámer sa nerobil.


Merateľné ciele (KPI) :star::grey_star::grey_star::grey_star:

Merateľné ukazovatele projektu sa sústredia najmä na šetrenie v oblasti nákupu licencií centrálne. Ak má byť ambíciou presúvať informačné systémy do PaaS prostredia, bolo by vhodné zaradiť nielen KPI na využívanie služieb cez PaaS, ale aj percento aplikácii, ktoré nevyužívajú služby mimo PaaS. Jednou z kľúčových prekážok pri nasadzovaní aplikácii v prostredí eGovernmentu je neflexibilita a zdĺhavé procesy. Nezaradenie KPI na sledovanie tohto kľúčového cieľa (aj keď ťažšie merateľného) považujeme za chybu. Zo štúdie nie je jasné, ako bola odhadnutá výška “potenciálnych KPI”, ani potrebné aktivity smerujúce k ich naplneniu.

Podľa štúdie uskutočniteľnosti:
Merateľný ukazovateľ OPII: Dodatočný počet inštitúcií štátnej správy zapojených do eGovernment cloudu
Ďalšie potenciálne navrhované biznis KPI stanovené na základe reálnych možností a predpokladaného potenciálu projektu sú:

  • aspoň 60% projektov OPII bude využívať softvérové licencie poskytované cez PaaS,
  • úspora z centrálneho nákupu SW licencií - 5%,
  • úspora počtu licencií z dôvodu vyššej efektívnosti a zavedenia SAM procesov 6%,
  • aspoň 40% projektov OPII bude využívať služby cloud natívnej platformy PaaS alebo jednotný devops,
  • zefektívnenie vývoja a nasadenia zmien pri využívaní služieb CI/CD – projekty využívajúce tieto služby nebudú potrebovať prostredia a tímy na vykonávanie devops operácii, pričom odhad úspor vo je výške 5% (tento odhad nie je možné zaradiť medzi merateľné ukazovatele z dôvodu, že nie je možné ho jednoducho zmerať, je tu však uvedený z dôvodu logickej príslušnosti)

Postup dosiahnutia cieľov (nie je zatiaľ vyhodnotený)


Súlad s KRIS (nie je zatiaľ vyhodnotený)


Biznis prínos :star::star::star::grey_star:

Tento projekt zapadá do dlhodobých cieľov eGovernmentu ako celku. Vychádza zo strategických priorít avšak sústreďuje sa príliš na šetrenie z centrálneho nákupu licencii. Väčším biznis prínosom by bolo zváženie využitia služieb hybridného cloudu.


Príspevok v informatizácii :star::star::star::grey_star:

Projekt je v súlade NKIVS a strategickými dokumentami. Je dôležitým krokom pre zjednodušenie nasadzovania aplikácii a racionalizáciu využívania licencovaného softvéru.


Štúdia uskutočniteľnosti :star::star::star::grey_star:

Štúdia uskutočniteľnosti obsahuje nedostatky hlavne časti nákladov, ktorá obsahuje odhady nepodložené výpočtami alebo zdrojmi potrebných človekodní. Základné zadanie projektu je zo štúdie zrejmé, no obsahuje aj niektoré moduly, ktorých funkcionalita je popísaná príliš všeobecne a vágne. Naopak duplicitne pôsobia niektoré licencie a komponenty, ktoré sú navrhované ako centrálne v iných projektoch.


Alternatívy :star::star::grey_star::grey_star:

Alternatívy riešenia sú zvolené vhodne a realisticky, avšak obmedzenosť štúdie len na “privátny cloud” resp. on-premise riešenie obmedzuje alternatívy zásadným spôsobom. Využitie hybridného/verejného cloudu by vyriešilo mnohé riziká, ktoré sú spojené s uvedenými alternatívami (napr. skúsenosti s administráciou, ladením a prevádzkov služieb, ktoré bude potrebné podporovať). Kladne hodnotíme zaradenie slobodného softvéru do multikriteriálnej analýzy ako aj navrhnuté produkty OpenShift a Cloud Foundry.


Kalkulácia efektívnosti :star::grey_star::grey_star::grey_star:

Väčšina nákladových položiek v časti vývoj aplikácie nie je podložená zdrojmi, čísla nepôsobia uveriteľne a obsahujú licencie na produkty, ktoré nikde v štúdii nie sú uvedené.
Sme presvedčení, že na úrovni štúdie nie je možné schváliť konkrétny zoznam produktov, ktoré budú zaradené do PaaS, ale po jej schválení je potrebné ďalej participatívnym spôsobom pracovať na príprave katalógu PaaS služieb.


Participácia na príprave projektu :star::star::grey_star::grey_star:

Štúdia uskutočniteľnosti bola zverejňovaná pred schvaľovaním,vykonané bolo aj jej verejné pripomienkovanie. Väčšina jednoduchých pripomienok bola zapracovaná, no pripomienky zásadnejšieho charakteru nie.


Diskusie k projektu na platforme:


:file_folder: Dokumenty


:clock2: Aktivity

V tomto projekte už prebehli nasledovné dôležité aktivity / míľniky:


Harmonogram OPII projektov na 2018
#2

Tu su predbezne pripomienky SD k aktualnej verzii studie.
PaaS - pripomienky S.D 26.2.docx (14.7 KB)


#3

Z CBA by ma naozaj zaujimalo odkial su tieto cisla.

Devops nastroje 2M eur (co to je? a co to robi?), PaaS automation 2M eur (co to je?), IaaS upravy 1M eur (co tam treba upravit?), komponenty 1m eur (co to je?), Testovanie za milion eur.

Nech sa na mna nikto nehneva, ale tento projekt je “nainstalujme a prevadzkujme CloudFoundry alebo OpenShift + dorobme do toho (urcite ako opensource) nejaku podporu pre sluzby co my potrebujeme” nie? Kde tam niekto vidi 9,7 miliona eur na vyvoj?

cc @metjush @panda


#4

CloudFoundry/Openshift je iba jeden z modulov. Zrejme ma najviac funkcnosti, ale financne nie je najvacsi (vdaka tomu ze to je standardny soft).
Tie cisla v CBA su expertne odhady kolko ludi bude potrebnych na vytvorenie funkcionality. Je to jednoduchy sucin FTE, casu trvania aktivity a ceny clovekodna.
Co sa tyka otazok, ze co su tie komponenty, tak je to popisane v SU. Ak nieco nie je dostatocne popisane, treba napisat konkretne, ze ktory modul.


#5

Kde je prosim popisana ta funkcionalita na zaklade ktorej to expert odhadol? A mam na mysli uplne vsetky moduly z CBA, lebo v studii sa mi zda, ze som nic take velmi nevidel.


#6

OT: Kym my tu rozbehame devops, tak komercia bude daleko za horami dolami.


#7

Ta funkcionalita je popisana v casti popis buduceho stavu - architektura. Kazda cast tam ma nejaky odsek. Niektore standardne funkcionality su popisane iba strucne, ale mal by si tam vsetko najst.
Co sa tyka testovania, to tam popisane nie je, ty sice pises ze testovanie za milion, co znie zle, ale ked das do rozpoctu 4 testerov na dobu trvania projektov, tak to to proste tak vychadza. A 4 testeri si vobec nemyslim ze je prehnany pocet.


#8

Skusim este raz, ale opakujem to ako verklik pri kazdom jednom projekte. V tych castiach su napisane nejake velmi ramcove veci, potom v tejto tabulke je ako prvy riadok analyza. Tam by som este chapal, ze sa napise odhad. Ale ako prosim pekne moze niekto odhadnut z neexistujucej analyzy, kolko bude trvat navrh a PoC? Potom z neexistujuceho navrhu a PoC (ktory ma overit co? asi nejaku neistotu) rovno odhadne cas na implementaciu finalneho riesenia?

Naozaj mi niekto vysvetlite ako sa toto da spravit a ako to ten expert urobi?


#9

Ale ako prosim pekne moze niekto odhadnut z neexistujucej analyzy, kolko bude trvat navrh a PoC?

Kedze je to nevyhnutnost na zostavenie rozpoctu, tak sa to musis odhadnut. Alternativa je ist cestou oddelenia navrhu a implementacie (ako pri ISV).
V tomto pripade to bolo odhadnute tak, ze kolko ludi asi budem potrebovat na aku dlhu dobu na implementaciu pozadovanej funkcionality. Je asi jasne, ze to je predpovedanie buducnosti a urcite je menej presne ako keby si to predpovedal az po analyze, ale take su sucasne pravidla.

Potom z neexistujuceho navrhu a PoC (ktory ma overit co? asi nejaku neistotu) rovno odhadne cas na implementaciu finalneho riesenia?<

PoC tu je mysleny v zmysle prototyp pre zakaznika v zmysle agilneho vyvoja. To by bol zrejme lepsi vyraz.


#10

Pozadovanej funkcionality, ktora sa zadefinuje v analyze. Cize ta ktora dnes neexistuje?

No toto mi znie, ze uplne vsetko ide po starom, len sa tam vlozil jeden milnik kde sa ukaze nieco zakaznikovi na zaciatku. V zmysle agilneho vyvoja to vobec nie je. Toto je proste fixed price contract.


#11

(Aby bolo jasne, ja neocakavam, ze sa toto podari nejako opravit. Toto je systemova chyba napriec uplne vsetkymi projektami.)


#12

No toto mi znie, ze uplne vsetko ide po starom, len sa tam vlozil jeden milnik kde sa ukaze nieco zakaznikovi na zaciatku. V zmysle agilneho vyvoja to vobec nie je. Toto je proste fixed price contract.

Tak agile contract to urcite nie je, ale zase aj ked to je fixed contract, tak sa moze dodavat waterfallovo, t.j. pocka sa kym je vsetko hotove a potom sa iba testuje, alebo sa moze zakaznikom ukazovat pravidelne napr. v 2tyzdnovych intervaloch (a z toho mozno tvorit dokumentaciu a DFS). To sa uz na agile podla mna celkom podoba a toto sa da dosiahnut (ak sa chce na oboch stranach, inak to dopadne ako waterfall).


#13

Ano to by bolo fajn, ale podla planu v studii to takto velmi nevyzera.


#14

Tak ale to z takehoto high level planu neuvidis…
Ja mam zase nazor, ze takymto planom by to slo, DFS sa vzdy prekryva s tym “PoC/prototypom” prave preto, aby nebol odsuhlasovany iba dokument, ale aj nieco naprogramovane. Az ked zakaznik vidi co zhruba dostane, potom zacne implementacia - a tu mozu byt uz sprinty (alebo waterfall ak sa nepodari).
(je pravda, ze podla toho co pisem by mozno malo byt DFS natiahnute na celu dobu trvania projektu, ale nie je to tak, z dovodov co si pisal vyssie - aby to sadlo na projektove metodiky. Zaroven aj dodavatel potrebuje podla mna mat nieco zaplatene v priebehu projektu, ak by vsetky milniky koncili na konci, tak by to cele musel uverovat).


#15

#16

http://www.informatizacia.sk/aktuality/26875c

@panda prečo je z tohto odrazu len nejaké testovacie prostredie?


#17

Fatal error - komunikacny odbor vypublikoval blbost.
Tu je to opravene v texte
https://www.vicepremier.gov.sk/index.php/informatizacia-vyhlasujeme-vyzvanie-na-projekt-jednotnej-testovacej-platformy/index.html
Ale URL zrejme generovali z perexu skor, takze “testovacia platforma” je stale tam.
Sorry