Můžu si jakožto vývojář s 20+ lety praxe dovolit kritizovat tu Bartošovu zpraseninu? Nebo taky patřím do skupiny, se kterou se roztrhl pytel?

Mluvil jsem s pár lidmi z oboru stavebnictví a dověděl jsem se, jak ten systém skvěle nefunguje. A nebyly to báby před důchodem, které se už nechtějí nic učit.

Zajímalo by mě, kdo psal analýzy, kdo je oponoval, kdy probíhal testovací provoz, kdo schvaloval UAT skripty. Protože ten kočkopes je špatný už od začátku.

Předpokládám, že nejste jeden z těch, kteří by z pohledu na UI tvrdili, že „kostra” programu je špatně (ať už se kostrou myslí cokoli) a je třeba to celé zahodit a napsat znovu?

Právě proto, že vývoj softwaru znáte, byste si takové tvrzení nejspíš nedovolil vypustit z úst bez pohledu na dokumentaci, analýzy, kód ... na rozdíl od samozvaných expertů na vše.

..... aplikační logiku i uživatelské rozhraní, a následně to také celé naprogramovat a otestovat.

Tolik z textu pana Jako tecnik u tehdejších sálových počítačů řady EC...made in CCCP kopie to řady IBM tuším 360 si pamatuji, že každý nový program, výrob pivovarů ... vyskladnění šroubků , pracovní lístky..děrné štítky....Tak tehdejší programátoři programy tzv odlaďovaly . . .A troufám si tvrdit, že to bylo neskonale jednodušší, než stvořit SW stavební řízení bez zkoušení , odladění v souběhu se starým systemem...Je to diletantismus ... v mých očích. Jojo, tehdejší počtače, kde procesor byl ve dvou almarách se dali opravit... a uměli vytisknout kondiciogramy

Nechci šířit fámy, ale počítač Apolla měl RAMku

Počítač Apolla 11 měl ve své době neuvěřitelných 32 768 bitů paměti RAM, zatímco dnešní iPhony mají 4 GB RAM, tedy 34 359 738 368 bitů.

Ve vší úctě, pamatujete jistě hodně, ale je třeba udržet myšlenku...

Pan Josef Kočíšek asi míchá dohromady celkem dost věcí, když samotnou architekturu informačního systému hodnotí na 90 % až téměř 100 % hodnoty celého produktu.

Možná trochu zastaralý, ale dosud často používaný vývojový proces, zvaný „Vodopádový model”, definuje vývoj softwarového produktu v šesti krocích, které se mohou v menší míře překrývat, ale každý krok je nutné mít už z větší části dokončený, aby další krok mohl započít:

1. Definice požadavků. Ty může definovat buďto zákazník sám, nebo mu s jejich sesbíráním může pomoct konzultant firmy, která bude produkt vyvíjet. Někdy poté nedojde k podepsání smlouvy a práce konzultanta je zákazníkem nezaplacená.

2. Analýza požadavků a definice uživatelských scénářů, různých modelů a schémat dat, procesů a byznysových pravidel. Tady už je poměrně jasné, co se od toho chce, ale ještě není jasné, jak bude vypadat samotný produkt.

3. Návrh softwaru. Zde je nemalou součástí právě zmíněná architektura, byť spousta lidí sem zahrnuje i tu část, kterou dělá sám programátor předtím, než začne fyzicky psát kód, a kde se zabývá návrhem jednotlivých menších celků.

4. Samotný vývoj softwaru, včetně vývojářského testování, všemožných integrací a psaní automatických testů.

5. Testování, tzn. systematické hledání defektů a jejich oprava.

6. Operativa, tzn. nasazení u zákazníka, pomoc s migrací dat, údržba, jakákoli další podpora.

Agilní metodika tyto kroky provádí víc paralelně: Jednotlivé kroky se provádějí pro menší funkční celky a tím je možné projít všech šest kroků třeba za dva týdny, od požadavku až po nasazení u zákazníka. Taky je zde typicky přímější zpětná vazba, kdy se zástupce zákazníka dívá na vyvíjený produkt ještě před jeho vydáním a má prostor usměrnit vývoj správným směrem.

Dovolím si tedy tvrdit, že hodnota architektury v rámci celého softwarového projektu bude nanejvýš někde kolem 20 %, a to si myslím, že jsem ještě příliš štědrý. Ovšem určitě stojí za zmínku, že selhání v předchozích krocích ovlivní kroky následující.

JO jo vodopád

Včil je moderní agilní přístup

Tož nějak začnem a agilně to doděláme, skvělý příklad

V IT dělám 30 let. A s klidným srdcem vám oznamuji že pokud bych odevzdal projekt který ani po měsíci nefunguje tak nejenže bych nedostal smluvenou částku ale navíc bych zaplatil velice tučné penále. Ergo pokud bych odváděl stejnou práci jako lidé co mají na svědomí digitalizaci stavebního řízení byl bych bezdomovec bez peněz a na dlažbě.

Ten projekt je obrovský a nikdo nečekal že to bude bez chyb. Jenže ten projekt nemohl ani náhodou jet dle běžných pravidel co se týká testování. Pustit totálně děravou verzi do ostrého provozu mohl jen zoufalec.

Viděl jsem i reálné projekty mimo státní správu, které byly při vydání naprosto rozbité. Například ... Windows 10?

Nepopírám, že to, co se stalo, je průšvih. Jen je směšné, že se k otázkám "opravitelnosti" softwarového programu vyjadřují lidé, kteří nejen neviděli zdrojové kódy a dokumentaci, ale nemají ani žádné vzdělání či pracovní zkušenosti z oboru IT.

Ten přístup „zahodit a začít znovu” je dost vlastní juniorním programátorům, kteří by to stejně nenaprogramovali lépe. Samozřejmě ale, jsou systémy, které už jsou tak zastaralé a neopravitelné, že tam jiná možnost není.

Tady ovšem bude dost možná lepší (pokud není vše počínaje datovou strukturou uchopené úplně špatně) vyřešit nejvíce palčivé problémy a pak agilní metodikou přidávat dodatečnou funkcionalitu, která usnadní úředníkům jejich práci.

IT odborník sice nejsem, ale za prvé dovoluji si poznamenat, že na takovém projektu je objem IT práce jen část, možná polovina, možná i jenom pětina veškeré práce.

A z konkrétních problémů, které prosákly na veřejnost je jednoznačně vidět, že plán toho projektu , vstupní analýzy projektu a obecně přípravné analýzy a práce, než se projekt začne byly hrubě podceněny nebo možná úplně opominuty.

Vypadá to, jako by Bartoš do projektu skočil bez přípravy a spoléhal jenom na agilitu jednotlivých ajťáků ze svého týmu. Že pod obrovským tlakem po ukončení starého systému a na zprovoznění nového ze sebe "vytlačí" nějak udělané funkční řešení podobným způsobem, jako byl udělán ten eshop.

Tak ano, 90% hodnoty práce takřka každého projektu je návrh postupu, "architektura". A třeba v legislativě se to limitně blíží 100%.

1) Aktuální stavební zákon má více než 330 paragrafů a přes 60 000 slov (včetně příloh). Zákon obsahuje popis postupů, termíny a nutné přijaté a vydané dokumenty a jejich obsah. Toto je potřeba přenést do informačního systému 1:1, jinak vzniká problém. Zákon je složitý a většina jeho uživatelů tomu nerozumí.

2) Zatímco občanské právo říká, že co není zakázáno je dovoleno, systém správního práva jasně říká, že úředník může udělat pouze to, co je v předpise povoleno nebo nařízeno a nesmí se odchýlit, i kdyby to dávalo smysl. Informační systém, který nebude kopírovat zákon, je, řekněme, problematický.

3) Prosadit změnu informačního systému je velmi obtížný úkol kdekoliv. Natož v systému státní správy, kde se, co si budeme povídat, neshlukují ty nejostřejší tužky v penálu. Čest budiž vzdána výjimkám!

4) Mr. Bartoš měl toto vědět. Mělo mu být jasné, že na převod 330 paragrafů do kódu a např. na propojení všech úřadů okolo má zoufale málo času. A naposledy - v okamžiku, kdy mu dodavatele shodil ÚHOS, bylo jasné, že je to celé mimo. Bylo to v květnu 2024 a ještě to šlo zastavit.

5) Někteří říkají - aspoň to zkusil. Ale to je blbost, to nemohlo vyjít. Pýcha zvítězila. Od začátku to byla Mission Impossible.

RIP

Ne že by ti, co do něj dneska šijou, byli lepší.

Přitom se dá celý stavební zákon shrnout do tří bodů:

Máš pozemek?

Neleží na území NP nebo CHKO?

Tak jdi stavět m

Ten linknutý pořad (reportéři čt) značně vysvětluje mnohé, ale zdaleka ne vše. Bylo by potřebné vytáhnout ještě více historie. Třeba boj o zrušené IT standardy, který státní správu posunul do role vydíraného uživatele. Celá kauza má k férovosti daleko. Naštěstí ale zesměšňuje vládu natolik, že její narativ již nebude nikdy přesvědčivý a pravdivý ani být nemůže, protože narativ je jen příběh a často podsunutý).

Ach ty narativy.

Jak zde sdílel Josef Leitner z pořadu Reportéři ČT:

https://www.ceskatelevize.cz/porady/1142743803-rep.../

Zajímavý pohled na věc, možná to s tím selháním ze strany MMR a Bartoše nebylo tak žhavé a hrály nemalou roli klacky házené pod nohy velkými hráči na trhu, kteří z drahých zakázek profitují.

Takže byl někdo z Bartošova týmu "ovlivněn", aby se projekt nezdařil?

Pracoval jste někdy na nějakém větším IT projektu?

Ode mne se obávat nemusíte, protože dobře vím, že co Čech to odborník na všechno. V naší kotlince platí přímá úměra: čím méně věci rozumím, tím více radím ostatním. Z praxe znám, jak se lidé brání novým věcem a jak je těžké je přimět k tomu, aby přijali nový počítačový program nebo systém za svůj. To platí bez rozdílu pro soukromý i státní sektor. V případě Bartoše je humorné, že někteří ví o IT jen to, že zmíněný Pirát nosí dredy a tím jejich IT znalost definitivně končí. Neobjednají si domů ani zubní pastu z e-shopu a na klávesnici ťukají dvěma prsty, zato dokáží moudře přemítat o architektuře programu. Do hlavy však dostali nalejvárnu od rozvášněných politiků prostřednictvím médií a tak ví. Oni ví přesně stav věci. Dokonce lépe než uživatelé na stavebních úřadech a ještě lépe než tvůrce programu. Děkuji za článek a přeji hezký den

https://www.ceskatelevize.cz/porady/1142743803-rep.../