„A szoftver a közigazgatásban támogatja, esetleg végrehajtja az ügyviteli folyamatokat, felügyeli az adatáramlást és tárolást, jelentéseket, elemzéseket készít stb. A közigazgatás működésének kereteit jogszabályok határozzák meg, a feladatokat ellátó hivatalok a munkát ezen keretek között végezhetik. Sok olyan feladat van, amelynek ellátásáért egy adott hivatal a felelős: a közigazgatási feladatok tipikusan ilyenek. Ebben az esetben ez a hivatal az adott feladatot támogató szoftver egyetlen potenciális vevője az adott jogrend területi hatálya alatt, azaz egy adott országban. A szoftver máshol nem felel meg a jogszabályoknak, az adott országban pedig nincs más, aki a feladatot ellátja vagy elláthatja. Ezért sok közigazgatási feladatot támogató szoftvernek csak egyetlen potenciális felhasználója van: az a hivatal, amelynek a megrendelésére kifejlesztették. Másnak gyakorlatilag nem lehet eladni. A rendszer belső logikáját a fejlesztő nem a jogszabályokból származtatja, ezt a feladatot többnyire a megrendelő szakemberei végzik. Így a végtermék belső működési logikája közös szellemi erőfeszítés eredménye: az ügyviteli elemek „szerzője” a megrendelő szerepben lévő hivatal, a technológiai elemeké pedig a szállítói szerepben dolgozó fejlesztő.
Milyen a kész termék, mely elemeiben ölt testet a kész alkotás? Elsősorban a használatra kész, azaz futtatható szoftverben. Ez a „dolog” azonban nem nevezhető terméknek! Belső logikája többnyire rejtett, csak működésének eredménye, azaz a megvalósított működés látható. Használatához szükséges a felhasználói kézikönyv, amelyben a használat módja, a kivételes esetek kezelése és —szerencsés esetben— a szoftver adminisztrációjának, különösen a jogosultságok kezelésének és a mentések végrehajtásának a leírása szerepel. Ez a két termék-elem mindenképpen szükséges a használathoz, ezért ezeket a szállító kénytelen átadni az ügyfélnek. Ez a teljesítés minimuma, és nem működés-kritikus, könnyen más termékre cserélhető programok – pl. szövegszerkesztők esetén – ez elegendő is. A szoftverrendszerek fejlesztése során azonban más dokumentáció is készül. A rendszer architektúráját, programozási rétegeit, adatbázisát és telepítését leíró dokumentáció sokszor marad a fejlesztőnél. Történik ez annak ellenére, hogy az abban reprezentált tudás közvetlenül a megrendelő szakembereitől származik, ők adták át írásban a feladat meghatározásakor a szállítónak, ők a jog szerinti szerzők. A központi, országos hatáskörű közigazgatási szervek esetén sokszor ugyanezek a szakemberek írták a vonatkozó jogszabályokat is. A programozók által írt forráskód, amely a szoftver ember számára értelmezhető reprezentációja, általában a szállítónál marad.
A fenti gyakorlat miért előnyös a szállítónak? A nagy, nemzetközi jelenléttel bíró cégek a keletkező dokumentációt tudásbázisuk növelése céljából feldolgozzák, tárolják, elemzik. Ha titoktartásra kötelezettek, akkor —reményeink szerint— anonim feldolgozást követően teszik ezt. Ezzel javítják saját készségeiket, hogy ha a világban bárhol hasonló feladattal találkoznak, a lehető legrövidebb idő alatt, a legjobb színvonalon szolgálják ki ügyfelüket. Ez komoly versenyelőny az ilyen tudásbázissal nem rendelkező, helyi versenytársakkal szemben. A forráskód hiányában pedig, az ügyfél nem képes a szoftver módosítására: az igények vagy a körülmények (pl. jogszabály) változása esetén a szoftver követését vagy az eredeti szállítótól rendeli meg, vagy újra íratja azt mással. Előbbi esetben a beszerzéskor a versenyeztetés elmarad, hiszen csak egy szállító képes a módosítást leprogramozni: az, aki a forráskóddal és a fejlesztési dokumentációval rendelkezik.
A vevő szerepkörben lévő hivatal ilyenkor meglehetősen kiszolgáltatott helyzetben van. Vagy elfogadja a módosításra verseny nélkül kialkudott árat, vagy elölről kezdi a fejlesztést. Ez utóbbi esetben fel tudja használni a korábban készített feladat-meghatározást, amelyen átvezeti a kívánt módosításokat. Itt azonban előkerül egy újabb probléma. A korábbi fejlesztés során a felek a rendszer több tucat, esetleg több száz pontján realizáltak olyan körülményeket, amelyek miatt az eredeti specifikációtól eltérő fejlesztési irány mellett döntöttek. Ezek lehetnek specifikációs hibák, a logikátlan ügyvitel javítása, a korábbi papír alapú folyamatok mechanikus másolásából származó problémák stb. E változások szakszerű dokumentálását többnyire a szállító végzi el, de ez sokszor meg sem jelenik a felhasználói dokumentációban, mert csak belső folyamatokat érint. Ha közben ráadásul évek teltek el, a vevőnek szinte elölről kell kezdeni a teljes fejlesztési projektet. A programok belső működésével kapcsolatos információhiány, és a módosítási, hibajavítási képesség hiánya biztonsági, sőt nemzetbiztonsági kérdéseket is felvet.
Ezt felismerve a közigazgatásban egyre gyakoribb, hogy a fejlesztés eredményeként előállt fejlesztési dokumentációt és a forráskódot a vevő a teljesítés feltételeként elkéri. Ez a gyakorlatban azt jelenti, hogy az átadás – átvételi folyamatban a vevő megkapja ezeket a termékelemeket. Az átadás-átvétel a komplex fejlesztések esetén egy bonyolult, időben elhúzódó folyamat. A készre jelentett terméket a szállító telepíti, a vevő teszteli. Ennek eredményeként a vevő jelent pl. 3 kritikus, 5 magas prioritású, 10 közepes prioritású és 50 alacsony prioritású hibát. A szállító a kritikus hibákat – amelyek kijavítása nélkül használhatatlan a rendszer – kijavítja. Ugyanígy tesz az alacsony prioritású hibák közül a könnyen javítható „kozmetikai” (pl. rossz sorrendben vannak egy űrlapon az adatbeviteli mezők, fel van cserélve két gomb) problémákkal, esetleg még egy-két magas prioritású hibával. A határidővel küzdő ügyfél morogva, de átveszi a terméket forráskódostól, dokumentációstól azzal, hogy a többi hibát is javítják. Ezt a szállító megígéri, és időközönként telepít is egy új verziót az élesben használt (produktív) rendszerre, néha ad valami módosított dokumentációt és forráskódot. Ez többnyire addig tart, amíg mindkét fél ki nem fárad, vagy új projekt nem indul a témában. A kérdés, hogy ez utóbbi esetben milyen fejlesztési dokumentációja és forráskódja van az ügyfélnek? Kijelenthető, hogy az átadott forráskódokból az ügyfél akkor sem képes futtatható fordítást készíteni, ha egyetlen sort sem változtatott az eredeti rendszeren. Ennek nem az az oka, hogy a szállító becsapja az ügyfelet. Sokkal inkább az, hogy egyikük sem foglalkozik a kismillió al-verzió telepítése után ezekkel a kérdésekkel. Maga a forráskód sem feltétlenül konzisztens, hiszen ma már több fejlesztési környezetben fejlesztik a különböző alkalmazásrétegeket. A kliens html5, css és JavaScript. A szerver oldalon futhat Java servlet, C#, PHP, valamilyen adatbányászati elemző, és természetesen adatbáziskezelő, számtalan szkripttel teletömve. Az elemzések eredményeként előállt táblázatban vagy szöveges dokumentációban is lehetnek beágyazott modulban tárolt programok, amelyek az automatikus formázást végzik. Ennek létéről sokszor csak az a programozó tud, aki a sablont tervezte. Ráadásul az egymással is függőségi viszonyban lévő rendszerek fordítási paraméterei és szkriptjei önmagukban is bonyolult programnak számítanak, amelynek hiányában az összes többi forráskód birtokában sem állítható elő a működő rendszer. A forráskód ma már a fejlesztőnél sem egy jól meghatározott helyen lévő szövegfájlok gyűjteménye. A nemzetközi üzleti környezetben alkalmazott „source code escrow” szolgáltatások éppen ezért a védelem és biztonság hamis érzetét keltik azokban, akik ezt igénybe veszik.
Akkor nincs megoldás? Megoldás természetesen van, mert a szállító rendelkezik azzal az informatikai fejlesztési környezettel, amely a produktív rendszerbe telepített terméket előállította, a telepítést elvégezte. A legbiztosabb tehát, ha ezt a környezetet állítjuk elő a vevőnél, vagy az ő érdekében eljáró helyen. A vevő jellemzően nem rendelkezik olyan informatikai tudással, szervezettel, amely egy ilyen fejlesztési környezetet kezelni tudna. Ugyanakkor létezik olyan szervezet, amely a Kormány központi szervei számára informatikai szolgáltatásokat nyújt: a Nemzeti Infokommunikációs Szolgáltató Zrt. Ha a NISZ felmérné, hogy ügyfelei – a központi közigazgatási szervezetek – milyen fejlesztési platformokat használnak, akkor kiválaszthatná azokat, amelyek az igények minél nagyobb hányadát lefedik, jövőbe mutató technológiára épülnek, és a következő szolgáltatást nyújthatnák. A kormányzati közigazgatási szervezetek fejlesztéseiket a kiválasztott fejlesztési platformokon rendelik meg. Ettől csak indokolt esetben térhetnek el, pl. ha kifutó rendszeren kell kisebb módosítást végrehajtani, vagy olyan speciális fejlesztésre van szükségük, amelyet a NISZ által kiválasztott platformokon nem lehet elvégezni. A hivatalok egyedi fejlesztési projektjeiket továbbra is önállóan hajtják végre, de az éles produktív rendszerekre csak a NISZ végezhet telepítést úgy, hogy a futtatási környezet fordítását maga végzi. Ezzel garantálható, hogy egy, az Állam felügyeletébe tartozó szervezet rendelkezik a forráskódokkal és mindazon információval, amely a futtatható rendszer forráskódokból történő előállításához és telepítéséhez szükséges. A fejlesztési szállítási szerződéseket úgy kell megkötni, hogy a NISZ a vevő képviseletében járjon el, pontosan leírva közreműködésének célját, és azt, hogy a forráskódokat és a dokumentációt kizárólag az ügyfél érdekkörében, az általa megkötött szerződés keretei közt használhatja fel. Mivel a NISZ nem szereplő a versenypiacon, az érintett szállítók versenytársaként nem lép fel, így a szállítói ellenérvek kénytelenek az eddig etikátlanul megszerzett információs pozíció közvetlen védelmére szorítkozni, amely erkölcsileg nehezen tartható.”
Forrás:
A közigazgatási szervek részére fejlesztett egyedi szoftverek forráskódjáról; Vágujhelyi Ferenc; Nemzeti Hírközlési és Informatikai Tanács; 2016. augusztus 23.
