Právní problémy spojené se serverem a infrastrukturou pro vývoj systémů

IT systémy používané v podnicích jsou v jistém smyslu vytvářeny tím, že se vytvářejí specifikační a designové dokumenty a píší se zdrojové kódy odpovídající jejich obsahu. Nicméně, systém skutečně funguje až tehdy, když existuje fyzický počítač, tedy infrastruktura, nejen tento měkký aspekt. V tomto článku se budeme zabývat právními problémy, které úzce souvisí s oblastí infrastruktury v projektech vývoje systémů.

Co je infrastruktura v IT systémech

Inženýři, kteří se zabývají vývojem systémů, se nazývají systémoví inženýři (SE). Vývojový projekt začíná výchozími procesy, jako je vytváření specifikací a návrhových dokumentů, a pokračuje implementací programu a jeho testováním. To je základní postup. Systémový inženýr (SE) v širokém slova smyslu může být technik, který zastává všechny tyto úkoly, ale v závislosti na společnosti nebo pracovišti mohou být názvy dále rozlišovány podle konkrétních úkolů nebo oblastí. Pojem infrastrukturní inženýr odkazuje na technika, který se zabývá fyzickým prostředím počítače, zejména v rámci úkolů spojených s vývojem a provozem IT systémů. IT systémy používané ve společnostech a na pracovištích jsou v jistém smyslu abstraktní konstrukce tvořené kombinací zdrojových kódů. Avšak, aby tento systém plnil svou původní roli, jak se očekává, je nezbytné vybudovat infrastrukturu, včetně serverů a sítí. Praktický vývoj systémů postupuje na základě dvou pilířů: implementace programu a zdrojového kódu a příprava infrastruktury, která podporuje jeho provozní prostředí. Tento pohled je považován za důležitý také pro prevenci neočekávaných problémů.

Konkrétní situace, kdy problémy s infrastrukturou způsobují selhání projektu

Ve skutečnosti se může stát, že se v projektu vývoje systému soustředíte pouze na abstraktní programování a návrh v zdrojovém kódu a zanedbáte pohled na údržbu infrastruktury. Nicméně, pokud tyto dvě strany nejdou ruku v ruce, může to vést k riziku “hoření” projektu.

Jaké případy sporů může způsobit chyba v rozměrování serveru?

Například, po dokončení implementace a testování programu se může ukázat, že výkonnost serveru není dostatečná a systém není schopen vydržet praktické použití. Toto předvídání zátěže, která může být na systém v provozní fázi aplikována, a údržba infrastruktury odpovídající velikosti systému se nazývá “sizing”. Případy, kdy chyba v rozměrování serveru vede k problémům, se v minulosti skutečně staly. (Ačkoli byly nakonec vyřešeny smírně, můžete se odkazovat na tento případ jako na známý příklad.) Podrobnosti o řešení sporů mezi oběma stranami prostřednictvím “smíru” jsou podrobně vysvětleny v následujícím článku.

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

Fakt, že spor byl vyřešen smírem, jednoduše řečeno znamená, že spor byl ukončen “diskusí” mezi oběma stranami. Proto, na rozdíl od případu, kdy byl vynesen rozsudek soudem, obsah smíru není akumulován jako precedens a obvykle má silný individuální charakter.

Podstata případu je rozsah povinnosti dodavatele vůči nejasným specifikacím

Avšak, podstata těchto sporů může být také považována za otázku, “do jaké míry by měl dodavatel nést odpovědnost za věci, které nejsou explicitně uvedeny ve specifikacích”. S ohledem na tento bod můžete získat mnoho nápadů z obsahu následujícího článku.

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

V článku výše je vysvětleno, do jaké míry by měl dodavatel vykonávat své pravomoci a nést povinnost implementace pro věci, které nejsou uvedeny ve specifikacích. Zde je vysvětleno, že příběh se velmi liší mezi “stranou obrazovky”, která je snadno vizualizovatelná v dokumentech jako jsou požadavky na definici a základní návrhové dokumenty (oblast, která patří do takzvaného “frontendu”), a “stranou logiky”, jako je přenos dat (oblast, která patří do takzvaného “backendu” nebo “databáze”). Jinými slovy, je pravděpodobné, že oblast “strany obrazovky”, kde je možné snadno identifikovat problémy ve specifikacích i pro objednatele/uživatele (kteří obvykle nemají odborné znalosti o vývoji systémů), bude snadněji přičítána objednateli/uživateli. Na druhou stranu, je pravděpodobné, že problémy na “straně logiky” budou snadněji přičítány dodavateli. S ohledem na tyto body je pravděpodobné, že problémy s rozměrováním serveru, které jsou oblastí, kde je obtížné identifikovat problémy bez odborných znalostí technologie, budou snadněji přičítány dodavateli. Proto, pokud by se tato otázka měla stát předmětem plnohodnotného soudního sporu, lze očekávat, že pokud nebude existovat žádný aktivní důvod pro osvobození od odpovědnosti na straně dodavatele, rozhodnutí bude často nevýhodné pro dodavatele.

Opatření k předcházení problémům způsobeným chybami v serverovém rozměrování

Abychom předešli výše uvedeným problémům, je důležité sladit kroky při implementaci programu a popisu zdrojového kódu s přípravou infrastruktury. Konkrétní opatření mohou zahrnovat následující:

Jasně stanovit odpovědnost za rozměrování serveru v smlouvě

Nejen v těchto případech, ale většina sporů týkajících se vývojových projektů systému často pramení z nejasnosti v rozdělení rolí mezi odborníky na vývoj systémů a uživatele, kteří jsou obeznámeni s interními záležitostmi společnosti. Je samozřejmě nezbytné, aby obě strany úzce spolupracovaly pro hladký průběh projektu, ale je také vhodné co nejvíce jasně stanovit rozdělení rolí a odpovědnosti v smlouvě předem.

Úplně provést konkrétní požadavky na vývoj a řízení změn

Navíc, pokud jsou funkční požadavky, které by měly být realizovány, nejasné, riziko komplikovaných sporů se zvyšuje. To zahrnuje jak zjasnění specifikací v počáteční fázi definování požadavků, tak řízení změn během projektu. Jak by mělo být reagováno na změny specifikací během projektu, je podrobně vysvětleno v následujícím článku.

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

Vybrat vývojový model odpovídající povaze projektu

Navíc, což je hluboce spojeno s oběma výše uvedenými opatřeními, je důležité vybrat vhodný vývojový model pro projekt vývoje systému v závislosti na jeho povaze a velikosti. Obecně platí, že pokud jde o vývoj systému o určité velikosti, kde by mohlo být rozměrování serveru důležité, výhody použití vodopádového modelu, který je vhodný pro zjasnění specifikací a rozsahu odpovědnosti, se zvyšují. Podrobný výklad o výběru vhodného vývojového modelu v závislosti na povaze projektu je uveden v následujícím článku.

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

Shrnutí

Pro hladký průběh projektů vývoje systémů mohou být problémy, které vznikají při přípravě infrastruktury, snadno přehlédnuty. Očekává se, že sledování problémů kolem infrastruktury není malou zátěží pro nikoho jiného než odborníky na technologii. Nicméně, preventivní opatření proti těmto problémům mohou být považována za rozšíření základních opatření, jako je “jasné vymezení specifikací / důkladná správa změn”, “jasné vymezení rolí / odpovědnosti” a “výběr vývojového modelu odpovídajícího rozsahu a rozpočtu projektu”. První věc, kterou by měli lidé pracující v oblasti firemního práva pochopit, je, že základy preventivního práva mohou být plně aplikovány i na problémy s infrastrukturou. Navíc, pokud jste IT technik, je důležité pochopit, že problémy s infrastrukturou mohou představovat vážné riziko pro projekt a je důležité řídit práci hladce.