Odpovědi na otázky šéfredaktora serveru Česká škola a vyjádření k některým článkům na tomto serveru

Transkript

1 Odpovědi na otázky šéfredaktora serveru Česká škola a vyjádření k některým článkům na tomto serveru Vzhledem k faktu, že odpovědi na některé otázky (zejména detailní technologické) nebyly v době ukončení pilotního ověření zcela jasné nebo definitivní, publikace odpovědí na otázky zaslané šéfredaktorem serveru Česká škola panem Janem Wagnerem v prosinci 2011 byly pozdrženy do vyjasnění dotčených témat pro připravovanou 1. celoplošnou generální zkoušku ověřování výsledků žáků na úrovni 5. a 9. ročníků základních škol, a to především z důvodu, jak pan šéfredaktor zachází s oficiálními informacemi České školní inspekce (dále ČŠI ), kdy jsou různá data vztahující se např. pouze k pilotnímu ověřování prezentována jako finální řešení, vytržena z kontextu, popř. jsou již publikovaná data ČŠI účelově dezinterpretována v rozporu s jejich jasným významem. I proto jsou součástí tohoto dokumentu nejen odpovědi na otázky šéfredaktora serveru Česká škola, ale také vyjádření k některým článkům tohoto serveru. Otázky šéfredaktora serveru Česká škola a odpovědi ČŠI 1. V materiálu "Otázky a odpovědi k realizaci testování" uvádíte, že na tvorbu testů budou vypsána výběrová řízení. Kdy to bude a jaký bude objem těchto zakázek? Půjde o testy jen na pilotáž testování? Původně měl být vývoj testů garantován ze strany MŠMT. Aktuálně budou tyto činnosti v gesci ČŠI, která povede externí tým expertů pro tvorbu testů a zajistí také oponenturu těchto výstupů v řadách odborné veřejnosti (oborové kapacity, mimo jiných i tvůrci a garanti standardů, jazykové instituty a další). Náklady na vývoj testů pro 1. celoplošnou generální zkoušku by neměly přesáhnout 400 tis. Kč. Se stejným režimem se nyní počítá i do dalších běhů testování. 2. V materiálu "Otázky a odpovědi k realizaci testování" uvádíte, že ve webovém klientovi není možné realizovat bezpečné certifikované testování, přestože v tomto prostředí se běžně realizuje například elektronické bankovnictví nebo transakční systém státní správy. Jaké speciální funkce, které lehký klient neumožňuje, certifikované testování vyžaduje a proč? Pro jaké další zpracování je taková bezpečnost nutná? Citované vyjádření se netýká technologických možností zabezpečení komunikace, jak pan šéfredaktor mylně předpokládá ve své otázce. Jde o obecné globální zabezpečení celého procesu z pohledu logistiky. Zvolená architektura systému nejlepším možným způsobem řeší problémy výpadků připojení k internetu, při kterém v použitém řešení nedochází k absolutně žádnému omezení provozu. Těžko si lze představit, že při takovém výpadku celá škola přeruší testovací proces a vrátí se k němu někdy později, až se připojení obnoví. Proces testování je pro školu mimořádnou aktivitou,

2 která vyžaduje zásahy do běžného režimu a je nepřípustné tyto akce realizovat opakovaně. Tlustý klient dále poskytuje vyšší úroveň zabezpečení, a to možnosti logování nežádoucí činnosti během testování (užívání internetových prohlížečů a jiných aplikací) nebo dokáže tuto činnosti dočasně blokovat, ať již na úrovni samotného spuštění, nebo komunikace takových aplikací. Tím, že v průběhu realizace testů komunikuje s centrálním systémem minimálně, snižuje provozní nároky na připojení a celé ICT prostředí školy a dále eliminuje problémy spojené s nekompatibilitou systémů a heterogenním prostředím v jednotlivých školách (různé verze operačních systémů, internetových prohlížečů, jejich modulů, aktualizací a jejich stavu souvisejícím s mírou správy těchto komponent). S existencí tenkého klienta se počítá pro rok 2013 a souvisí s vývojem dalších modulů systému (především domácí a školní testování). Jeho použití v rovině certifikovaného testování bude však velmi omezené pouze pro speciální případy zařízení a operačních systémů, pro které je neefektivní tvořit speciální verzi tlustého klienta a tuto verzi dále spravovat a aktualizovat. Pokud jsou zmiňovány bankovní systémy, doporučujeme porovnat architekturu těchto systémů a nákladnost jejich základního provozu s vytvořeným řešením testování pro odpovídající počet uživatelů, které pan šéfredaktor kritizuje. V případě zmiňovaných transakčních systémů státní správy je třeba si uvědomit, že se jedná o zcela odlišné (z pohledu zpracovávané problematiky) systémy, které vzhledem ke svému určení nevyžadují takovou míru interakce, jakou vyžaduje proces certifikovaného testování. Nutno přiznat, že volbu použité architektury nezpochybnil žádný z přizvaných expertů v oblasti projekce a vývoje složitých a rozsáhlých informačních systémů. 3. V materiálu "Otázky a odpovědi k realizaci testování" uvádíte, že pro volbu řešení pomocí tlustého klienta byla použita podrobná ICT analýza, můžete nám ji poskytnout? Detailní analýza s návrhem řešení byla realizována společností Deloitte na základě smlouvy uzavřené mezi touto společností a MŠMT. Při rozhodování o architektuře systému byly použity mimo jiné i výstupy šetření ČŠI zabývající se kvalitou ICT podmínek v základních školách. V neposlední řadě byla zmíněná architektura použita také díky dlouholetým zkušenostem ČŠI a jejími systémy. Tato volba pro systém certifikovaného testování se ukázala jako správná již v pilotním ověření. Samostatná tematická zpráva a výroční zprávy ČŠI jsou veřejně dostupné na webu ČŠI.

3 4. Kdy budou k dispozici verze testovací aplikace pro jiné operační systémy než MS Windows? Verze pro operační systémy Linux by měla být k dispozici již pro 1. celoplošnou generální zkoušku v roce Verze pro další zařízení bude připravena pro plošné testování v roce Při pilotním testu 13. a se na počítače musely instalovat knihovny.net. Jaká verze.net je pro aplikaci požadována? Jak bude řešena aplikace pro jiné operační systémy než MS Windows? Aplikace vyžaduje knihovny NET Framework verze 2.0, což je ve světě operačních systémů Windows dnes již standardní prvek výbavy požadovaný řadou běžných aplikací. Volba konkrétní technologie dalších verzí pro jiné operační systémy je prozatím ve fázi návrhu dodavatele řešení a s ČŠI bude dále konzultována, následně odsouhlasena. Paušální tvrzení, že se tento balíček musel instalovat, je nekorektní. Tento balíček se instaloval pouze tam, kde doposud instalován nebyl. Jednalo se o zhruba polovinu použitých počítačů, což mimochodem demonstruje velmi nízkou úroveň používané techniky a její správy, protože jak již bylo zmíněno, knihovny NET Framework jsou využívány řadou jiných aplikací a na počítačích se standardním využitím jsou běžnou součástí. 6. Jaká byla skutečná velikost dat zadání testových úloh při pilotním testování 13. a ? Otázka není jasně formulována a není zřejmé, zda je myšlena velikost dat pro všechny školy nebo pro všechny žáky dané školy, apod. Pro 1. celoplošnou generální zkoušku bude velikost dávky testů všech předmětů pro všechny žáky školy průměrné velikosti (dvě třídy 5. ročníku a dvě třídy 9. ročníku) přibližně 5 MB. 7. Bude při dalším testování možná instalace testovací aplikace na servery? Na servery bylo možné instalovat verzi aplikace určenou již pro pilotní ověření. Takový krok by však byl značně nelogický, protože testovací aplikace je určena přímo pro koncové uživatele, kteří v této aplikaci absolvují samotné testy, což je v rozporu s běžným využitím prostředků označených jako server. Pokud byla otázkou myšlena možnost centrální distribuce a instalace aplikace, ta je rovněž možná již od počátku její existence. Aplikace je distribuována pomocí standardního MSI balíčku, který je možno instalovat vzdáleně a automatizovaně

4 v těch prostředích, která disponují mechanismem pro tyto procesy, popř. je spravuje osoba znalá. Pokud byla otázkou myšlena úplně jiná funkčnost nebo vlastnost, není to z otázky zřejmé. 8. Proč nebyla pro testování využita varianta cloud computingu, tedy pronájmu kapacit jen na dobu testování, která by byla zřejmě levnější než použití vlastního HW? Bude v rámci NIQES realizován nákup HW, pokud ano, o jaký půjde a v jakém finančním objemu? Jedná se o nepravdivé tvrzení. Dle vyjádření dodavatele systému, varianta cloud computingu byla využita. Je nutné si také uvědomit, že volba provedení hostingu serverové části systému je plně v kompetenci dodavatele řešení. ČŠI jako zadavatel definuje pouze povinné provozní limity a volba způsobu jejich dodržení souvisí s celou řadou dalších parametrů, které dodavatel při realizaci projektu musí dodržet. Proklamace o levnějším pronájmu proti vlastní infrastruktuře je navíc nejspíše lichá. Proměnlivý pronájem kapacit nebude dále pro potřeby systému vhodný, protože dále vznikající moduly systému (především domácí a školní testování a e-learning) budou provozovány celoročně a nikoliv jen nárazově ve větších vlnách jako se může i tak mylně jevit u modulu pro certifikované testování (zatím ověřování výsledků žáků na úrovni 5. a 9. ročníků). Dokonce ani využití tohoto modulu totiž nebude nárazové, protože modul bude v souladu se záměrem projektu NIQES sloužit i pro testování v jiných ročnících jako jeden z nástrojů komplexního hodnocení škol ze strany ČŠI. Dále je třeba uvědomit si, že využití systému nevzrůstá pouze při realizaci testování samotného, ale již při jeho přípravě (registrace škol, import seznamu žáků), ale i po něm (generování výsledků a tvorba výstupů na úrovni žáka, školy a agregovaných kompletních výsledků). Zvýšená zátěž v souvislosti s plošným testováním je tak minimálně čtyři měsíce. Při nástupu tohoto masivního využití systému komplexně je již velmi sporné, jak dopadne finanční porovnání variant technologického řešení. Po dobu projektu je ale toto kompletně kryto v rámci zakázky vývoje systému a volba finální podoby bude aktuální až po ukončení projektu, přičemž míra náročnosti provozu po ukončení projektu byla jedním z hodnotících kritérií. Není tedy pravdou, že k nákladům veřejné zakázky je třeba připočítat další náklady 6 mil. Kč, jak mylně pan šéfredaktor uvádí na serveru Česká škola. Toto jsou avizované roční náklady na provoz systému po ukončení projektu, přičemž jsou odhadem vycházejícím z analýzy finanční náročnosti provozu systému ve variantě hostingu ve vlastním prostředí ČŠI. Tato varianta nepředpokládá zvýšení běžných rozpočtů provozních ani investičních, tzn. náklady budou kryty mimo jiné z rezerv, které vzniknou důsledkem existence takového systému. Pokud se po ukončení projektu ukáže efektivnější využití hostingu,

5 resp. cloud computingu, jistě k němu bude ze strany ČŠI přistoupeno, protože ušetřené prostředky můžou být použity v rámci jiných činností ČŠI. Vývoj systému je ze strany ČŠI koordinován tak, aby žádná z variant nebyla znemožněna. 9. Hrozilo by skutečně, že bude testováno současně až uživatelů, jak uvádíte? Jaký jste předpokládali datový tok při testování s využitím lehkého klienta? Při odhadu kapacitních parametrů byla skutečně použita tato dimenze. To je plně v souladu s početností populačních ročníků a záměru využití systému v nejkritičtější možné variantě. Zohledněna je i ideální situace adekvátní vybavenosti škol, ke které, doufejme, v budoucnosti dojde. Znovu je třeba si uvědomit, že formulace parametrů provozu se vztahuje k systému jako celku, tzn. i dalších modulů systému, jejichž provoz je třeba umožnit i v průběhu nebo přípravě vlny certifikovaného plošného testování. Datový tok při využití lehkého klienta není zásadní proměnou při úvahách o architektuře systému. Platí ovšem, že koncentrovaný nárok na datové toky při použití tenkého klienta jsou výrazně vyšší než při rozložení přenosové zátěže pomocí logistického modelu, který je umožněn klientem tlustým. Daleko důležitějším atributem jsou však požadavky na strojový výkon pro obsluhu tenkých klientů, které jsou neporovnatelně vyšší a v takto robustním systému by nebylo možné (finančně z hlediska provozu) efektivně zajišťovat běh takového množství klientů nehledě na výrazně sníženou bezpečnost celého testování. Při použití webových technologií v takto ryze interaktivním módu, který by aplikace testování vyžadovala, není zásadním limitem objem přenášených dat. Odpovědi na výše uvedené dotazy jsou z velké části obsaženy ve veřejně dostupných zdrojích ČŠI týkající se klíčové aktivity č. 4 projektu NIQES. Jedná se zejména o projektovou dokumentaci NIQES, zadávací dokumentaci veřejné zakázky pro dodavatele řešení a soubor otázek a odpovědí. Neregistrujeme ani účast nikoho z redakce na žádné z veřejných prezentací systémů nebo tiskových konferencí ČŠI, kde byla veškeré problematika důkladně prezentována. Zejména při realizaci pilotního šetření byly přítomny osoby, které zajišťovaly po celý den konzultace z oblasti technologické (vývojový tým), tvorby testů a jejich hodnocení. Dále je velmi nekorektní zpochybňovat výhledové plnění parametrů požadovaných veřejně přístupnou zadávací dokumentací systému pro další fáze vývoje. Tyto požadavky jsou dále součástí smlouvy o dílo s dodavatelem řešení, čímž spolu s koordinací vývoje je zajištěno jejich plnění. Každá vlastnost systému nebo jeho architektury je průběžně odsouhlasena případně ještě rozšířena a zakotvena v rámci akceptačních procesů, které jsou ze smlouvy nastaveny. To se týká systému komplexně až na úroveň detailu datových modelů, návrhů uživatelského rozhraní, procesního modelu.

6 ČŠI se důrazně ohrazuje proti některým dalším článkům a tvrzením redakce serveru Česká škola, a to zejména: 1. Zpochybnění výběrového řízení na dodavatele systému a služeb (tvrzení o cinknutém výběrové řízení, zabránění přístupu uchazečů do soutěže, apod.) Výběrové řízení bylo vyhlášeno v souladu s platnou legislativou. Kvalifikační kritéria a hodnotící parametry byly stanoveny transparentně v souladu s předmětem plnění, kterým je vývoj, provoz a správa informačního systému po dobu projektu, tedy ryze ICT služby. Splnění kvalifikačních podmínek spočívalo především v referenci alespoň dvou zakázek obdobného předmětu a rozsahu (i ceny) a jedné menší. Útoky na to, že nastavením podmínek byly omezeny firmy, které mají dlouhodobé zkušenosti se školstvím (příklad firmy Scio), jsou irelevantní. Zřejmě se nejedná o firmu, jejímž předmětem činnosti je vývoj informačních systémů. Předmětem zakázky navíc není vývoj testů a ani organizace a zajištění procesu testování, nýbrž v tomto smyslu jen provoz systému (čili znovu IT služba). Pro dodavatele systému není žádná znalost prostředí školy nezbytná, protože předmět plnění je důsledně zadán seznamem komponent, vlastností a funkčností (cca 70 stran technické části zadávací dokumentace, která je veřejně dostupná). Opírá se také o odbornou analýzu firmy Deloitte zadanou MŠMT v roce Celý vývoj je po celou dobu realizace řízen ze strany ČŠI, jejíž zkušenosti z prostředí škol a celého systému jsou nezpochybnitelné. V rámci důkladné analýzy jsou návrhy konfrontovány s názory ředitelů škol a pedagogy. Do předmětného výběrového řízení bylo podáno 6 nabídek, přičemž je zřejmé, že kvalifikační kritéria byla splnitelná pro řadu dalších společnosti segmentu trhu ICT. Po celou dobu průběhu konání výběrového řízení ani po jeho uzavření nebyla přijata jediná námitka proti diskriminaci uchazečů pro podání nabídky. 2. Lživá tvrzení o ceně systému certifikovaného testování a konstrukce ceny testu v článku Jan Wagner: Plošné testování ministra Dobeše jako tunel Jak již bylo dříve uvedeno a publikováno na webu ČŠI a NIQES v dokumentu Otázky a odpovědi, cena části systému, který se zabývá certifikovaným testováním je cca 50 mil. Kč bez DPH, nikoliv 110 mil. Kč s DPH, jak je v článku uvedeno, už vůbec ne 300 mil. Kč, jak se uvádí v dalších článcích zveřejněných na serveru. Dále pak zcela chybný je výpočet nákladů na provozování systému. Jak již rovněž bylo jasně publikováno, cena provozu systému je sice cca 6 mil. Kč, ale až po ukončení projektu, tzn. od poloviny roku 2014 dále. Jakkoliv je celý výpočet nesmyslný, tak v jeho kontextu by pak byla cena testu ne šéfredaktorem udávaných 72 Kč ale pouze 27 Kč (po dobu trvání projektu), respektive 12 Kč (po ukončení projektu).

7 Tento výpočet je však zcela nesmyslný, protože modul certifikovaného testování bude užíván i pro výběrová šetření ze strany ČŠI (tak, jak je publikováno již v popisu projektu), tzn. nejedná se pouze o testování 3 předmětů v pátých a devátých ročnících celkem, ale zjišťování výsledků i v dalších předmětech a ročnících. 3. Srovnání a tvrzení ekvivalence výstupů aktivity 4 projektu ČŠI NIQES (národní zjišťování výsledků) a projektu Eskalátor (Scio) v podobě rovnocenného informačního systému pro testování Cílem projektu NIQES a části jeho výstupu v podobě informačního systému pro zjišťování výsledků je dle již publikované projektové dokumentace zcela něco jiného. Výsledky národních a dalších šetření výsledků vzdělávání jsou propojeny s daty získanými za pomoci výstupů dalších klíčových aktivit projektu (netestovatelené indikátory hodnocení kvality škol a školní vzdělávací programy) a spolu doplňují metriku inspekčního hodnocení kvality vzdělávání, což ze zákona náleží pouze ČŠI a již z projektové dokumentace projektu Eskalátor je zjevné, že nemá tyto ambice. Z technologického hlediska je zde také velmi propastný rozdíl patrný ze zadávací dokumentace výběrového řízení na vývoj a provoz tohoto systému v širokém spektru požadovaných funkčností a komponent, které jsou důkladně popsány nejen ve zmíněné zadávací dokumentaci, ale také v analýze Deloitte, která byla jedním ze základních vstupů při tvorbě. Při již probíhajícím vývoji byl navíc ze strany dodavatele plně nasazen více než dvacetičlenný tým analytiků, programátorů, systémových administrátorů a testerů, protože všechna požadovaná plnění v definovaném harmonogramu to vyžadují. Tomu ostatně odpovídá i hodnota zakázky, která byla navíc vzhledem k předpokladu vysoutěžena s menší cenou. Zmíněné personální zapojení je také neporovnatelné s 2,5 úvazkem programátorů a správců ICT avizovaných v projektové dokumentaci projektu Eskalátor. Systém projektu NIQES dále nepočítá s jakoukoliv realizací testů na papír. Toho bylo pro srovnání dopadu obou forem na výsledky použito jen při pilotním ověření. 4. Napadání výstupů pilotního ověření a jiných parametrů procesů avizovaných pro tuto zkoušku Je velmi nekorektní porovnávat tyto výstupy a vlastnosti vůči jiným cílům, než pro ně bylo jasně deklarováno. To se týká technických vlastností systému, logistických procesů i obsahové náplně testů a tomu odpovídajících výstupů hodnocení. ČŠI důsledně informuje o těchto faktech vždy v rámci kontextu. Pro hodnocení parametrů a výstupů pilotního ověření bylo cílem ověřit pouze obecnou možnost el. testování včetně základních prvků vyvíjeného systému. Vývoj aplikace a příprava celého procesu trvala pouze 2 měsíce a je zjevné, že i vzhledem

8 k tomuto pro takto složité procesy nelítostnému limitu celé pilotní ověření dopadlo nadmíru úspěšně a potvrdilo další směřování projektu.