A rendszerszoftver-fejlesztés szerver- és infrastruktúrájával kapcsolatos jogi kérdések

A vállalatok által használt IT rendszerek bizonyos értelemben a specifikációk és tervek elkészítésével, valamint a tartalmuknak megfelelő forráskód leírásával jönnek létre. Azonban nem csak ezek a lágy aspektusok számítanak, hanem a fizikai számítógépek, azaz az infrastruktúra is, amely nélkül a rendszer nem működhet valóban. Ebben a cikkben a rendszerfejlesztési projektekben az infrastruktúrával mélyen összefüggő jogi kérdéseket fogjuk megvitatni.

Az infrastruktúra az IT rendszerekben

A rendszerfejlesztő mérnököket rendszertervező mérnököknek (SE) nevezzük. A fejlesztési projektek általában a specifikációs és tervezési dokumentumok létrehozásával kezdődnek, majd a program implementálásával és tesztelésével folytatódnak. Általános értelemben a rendszertervező mérnök (SE) az a szakember, aki mindezeket a feladatokat ellátja, de a vállalatok és munkahelyek esetében előfordulhat, hogy a feladatok és területek szerint további megkülönböztetéseket alkalmaznak a megnevezésekben. Az infrastruktúra mérnök elnevezést azokra a szakemberekre használják, akik az IT rendszerek fejlesztésével és üzemeltetésével foglalkoznak, különösen azokra, akik a fizikai számítógépes működési környezetet alakítják ki. A vállalatok és munkahelyek által használt IT rendszerek bizonyos értelemben absztrakt építmények, amelyek forráskódok kombinációjából állnak. Azonban ahhoz, hogy ezek a rendszerek a tőlük elvárt szerepet betöltsék, elengedhetetlen a szerverek, hálózatok és egyéb infrastruktúra környezetének kialakítása. A rendszerfejlesztés gyakorlati munkája a program forráskódjának implementálása és az azt támogató infrastruktúra környezetének kialakítása révén halad előre. Ez a szempont fontos lehet a váratlan problémák megelőzése érdekében is.

Az infrastruktúra problémái hogyan okozhatnak tüzet a projektekben?

A rendszerfejlesztési projektekben előfordulhat, hogy túlságosan koncentrálunk az absztrakt programokra és a forráskód tervezésére, és figyelmen kívül hagyjuk az infrastruktúra karbantartását. Azonban, ha a két fél nem tud együttműködni, az a projekt ‘égésének’ kockázatát is növelheti.

Milyen esetekben okozhat vitát a szerver méretezésének hibája?

Például, ha a program implementálása és tesztelése után kiderül, hogy a szerver feldolgozási képessége nem elegendő, és a rendszer nem képes megfelelni a gyakorlati követelményeknek. Ezt a folyamatot, amikor előre becsüljük, mennyi terhelést kell a rendszernek kezelnie az üzemeltetési szakaszban, és az infrastruktúrát a rendszer méretéhez igazítjuk, ‘méretezésnek’ hívjuk. A szerver méretezésének hibái miatt kialakult problémák már korábban is előfordultak. (Bár végül egyezséggel rendezték a vitát, a híres esetek közül ezt az esetet hozhatjuk fel példának.) A felek közötti viták ‘egyezség’ általi rendezéséről a következő cikkben található részletes magyarázat.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Az, hogy a vita egyezséggel zárult, egyszerűen azt jelenti, hogy a felek ‘megbeszélése’ révén sikerült megoldani a vitát. Tehát, ellentétben a bírósági ítélettel, az egyezség tartalma nem kerül rögzítésre mint bírósági precedens, és általában egyedi jellegű.

Az eset lényege a szolgáltató felelősségének határai a nem egyértelmű specifikációkra vonatkozóan

Az ilyen viták lényege gyakran az, hogy ‘mennyire felelős a szolgáltató azokért a kérdésekért, amelyek nincsenek explicit módon meghatározva a specifikációban’. Ezt figyelembe véve, a következő cikkben sok hasznos tanácsot találhatunk.

https://monolith.law/corporate/system-development-specs-function[ja]

A fenti cikkben azt magyarázzuk el, hogy a specifikációban nem szereplő kérdések közül melyek azok, amelyekért a szolgáltató felelős, és milyen mértékben. Itt megmagyarázzuk, hogy a ‘képernyő oldali’ kérdések (az úgynevezett ‘frontend’ terület), amelyek könnyen láthatóak a követelmények meghatározása vagy az alapvető tervezési dokumentumok alapján, és a ‘logikai oldali’ kérdések (az úgynevezett ‘backend’, ‘adatbázis’ terület), mint például az adatmigráció, nagyon különbözőek. Más szóval, a ‘képernyő oldali’ kérdések, amelyeket a (általában nem rendelkeznek szakértői ismeretekkel a rendszerfejlesztési projektekben) megrendelők/felhasználók könnyen ellenőrizhetnek a specifikációk alapján, hajlamosak a megrendelők/felhasználók felelősségére hárulni. Ezzel szemben a ‘logikai oldali’ kérdések hajlamosak a szolgáltató felelősségére hárulni. Ezt figyelembe véve, a szerver méretezési problémák általában olyan területeken fordulnak elő, ahol a problémák nehezen észlelhetők, hacsak nem vagyunk szakértők, így ezek a problémák hajlamosak a szolgáltató felelősségére hárulni. Tehát, ha ebben a kérdésben ténylegesen perre kerülne sor, hacsak nincs valamilyen aktív ok, amely mentesíti a szolgáltatót a felelősség alól, várható, hogy a szolgáltató számára hátrányos döntés születik.

Intézkedések a szerver méretezési hibákból adódó problémák megelőzésére

A korábban említett problémák megelőzése érdekében fontos, hogy összehangoljuk a program implementációját, a forráskód írását és az infrastruktúra környezetének előkészítését. A lehetséges intézkedések között a következők szerepelnek:

A szerver méretezéséért való felelősség tisztázása a szerződésben

Nem csak ezekben az esetekben, de a rendszerfejlesztési projektekkel kapcsolatos viták nagy része abból adódik, hogy a rendszerfejlesztési szakértők és a belső ügyekben jártas felhasználók között nem egyértelmű a feladatmegosztás. Mindkét fél szoros együttműködése elengedhetetlen a projekt zökkenőmentes lebonyolításához, de ebben az esetben is fontos, hogy a feladatmegosztást és a felelősségi köröket előzetesen a szerződésben lehetőleg tisztázzuk.

A fejlesztési követelmények konkretizálása, a változáskezelés teljes körű végrehajtása

Továbbá, ha a megvalósítandó funkcionális követelmények homályosak, a viták összekuszálódásának veszélye növekszik. Ez a kezdeti követelménydefiníciós fázisban a specifikációk tisztázását, és a projekt közbeni változáskezelést jelenti. A projekt közbeni specifikációváltozások kezeléséről a következő cikkben adunk részletes magyarázatot.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja][ja]

A projekt jellegének megfelelő fejlesztési modell kiválasztása

Továbbá, ami szorosan kapcsolódik a fent említett két intézkedéshez, a rendszerfejlesztési projektek esetében fontos, hogy a projekt jellegének és méretének megfelelően válasszuk ki a megfelelő fejlesztési modellt. Általánosságban elmondható, hogy ha a szerver méretezése fontos lehet, mint egy bizonyos méretű rendszer fejlesztésénél, akkor előnyös lehet a specifikációk és a felelősségi körök tisztázására alkalmas vízesés modell alkalmazása. A projekt jellegének figyelembevételével a megfelelő fejlesztési modell kiválasztásáról a következő cikkben adunk részletes magyarázatot.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Összefoglalás

A rendszerfejlesztési projektek zökkenőmentes előrehaladása érdekében az infrastruktúrával kapcsolatos környezeti előkészületekből eredő problémák könnyen a figyelmen kívül hagyott pontok közé tartoznak. Az infrastruktúrával kapcsolatos problémákra való odafigyelés nem csak a technológiai szakemberek számára jelenthet jelentős terhet. Azonban ezeknek a problémáknak a megelőzési stratégiái, mint például a “specifikációk tisztázása / változáskezelés alapos végrehajtása”, a “szerepek / felelősségi körök tisztázása”, és a “projekt méretéhez és költségvetéséhez igazodó fejlesztési modell kiválasztása”, alapvető intézkedések kiterjesztéseként is értelmezhetők. Az üzleti jogban dolgozó személyek számára elsődleges fontosságú megérteni, hogy az infrastruktúrával kapcsolatos problémákra is alkalmazhatók a megelőző jogi alapelvek. Ezenkívül, ha valaki IT szakember, fontos megértenie, hogy az infrastruktúrával kapcsolatos problémák komoly kockázatot jelenthetnek a projekt súlyos kudarcához, és fontos, hogy zökkenőmentesen irányítsa a gyakorlati munkát.