Czym są problemy prawne związane z serwerem i infrastrukturą w rozwoju systemów?

Systemy IT stosowane w firmach są tworzone w pewnym sensie poprzez tworzenie specyfikacji i dokumentacji projektowej, a następnie pisząc kod źródłowy zgodny z ich treścią. Jednak systemy te nie funkcjonują wyłącznie na podstawie tych miękkich aspektów – wymagają również fizycznego komputera, czyli infrastruktury. W tym artykule omówimy kwestie prawne ściśle związane z obszarem infrastruktury w projektach rozwoju systemów.

Co to jest infrastruktura w systemach IT?

Inżynierowie zajmujący się tworzeniem systemów nazywani są inżynierami systemów (SE). Projekt rozwojowy zaczyna się od procesów wstępnych, takich jak tworzenie specyfikacji i dokumentacji projektowej, a następnie przechodzi do implementacji programu i przeprowadzania testów. To jest ogólny przebieg. Można powiedzieć, że inżynier systemowy (SE) w szerokim sensie jest technikiem, który zajmuje się wszystkimi tymi zadaniami, ale w zależności od firmy lub miejsca pracy, nazwy mogą być dalej różnicowane w zależności od zakresu obowiązków i obszarów. Termin “inżynier infrastruktury” odnosi się do techników, którzy są odpowiedzialni za utrzymanie fizycznego środowiska pracy komputera, szczególnie w kontekście zadań związanych z rozwojem i operacją systemów IT. Systemy IT używane w firmach i miejscach pracy są w pewnym sensie abstrakcyjnymi konstrukcjami tworzonymi z kombinacji kodu źródłowego. Jednak, aby system mógł spełniać swoją pierwotną rolę, niezbędne jest budowanie środowiska wokół infrastruktury, takiej jak serwery i sieci. Praktyka rozwoju systemów jest prowadzona na dwa sposoby: implementacja kodu źródłowego programu i utrzymanie środowiska wokół infrastruktury, która wspiera jego działanie. Ten punkt widzenia jest uważany za ważny również w celu zapobiegania nieprzewidzianym problemom.

Konkretne sytuacje, w których problemy z infrastrukturą mogą doprowadzić do katastrofy projektu

W rzeczywistości może zdarzyć się, że w projekcie rozwoju systemu skupiamy się tylko na abstrakcyjnym programowaniu i projektowaniu kodu źródłowego, pomijając perspektywę utrzymania infrastruktury. Jednak sytuacja, w której obie strony nie są zsynchronizowane, może stanowić ryzyko katastrofy projektu.

Jak błędy w rozmiarach serwera mogą prowadzić do konfliktów

Na przykład, po zakończeniu implementacji i testowania programu, może okazać się, że wydajność serwera jest niewystarczająca i system nie jest w stanie sprostać praktycznym wymaganiom. Proces przewidywania obciążenia, które system może napotkać podczas operacji, i dostosowywania infrastruktury do skali systemu nazywany jest “sizing”. Istnieją przypadki, w których błędy w rozmiarach serwera prowadziły do problemów, które faktycznie miały miejsce w przeszłości. (Chociaż ostatecznie zostały rozwiązane za pomocą ugody, można odnieść się do tego przypadku jako do znanego przykładu.) Szczegółowe wyjaśnienie metody rozwiązania konfliktów za pomocą “ugody” można znaleźć w poniższym artykule.

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

Fakt, że konflikt został rozwiązany za pomocą ugody, oznacza w skrócie, że konflikt został rozwiązany przez “rozmowy” między obiema stronami. W przeciwieństwie do przypadków, w których wyrok jest wydawany przez sąd, treść ugody nie jest gromadzona jako precedens, ale zazwyczaj ma silny charakter indywidualny.

Podstawa sprawy to zakres obowiązków dostawcy wobec niejasnych specyfikacji

Jednak istotą takich konfliktów może być pytanie, “do jakiego stopnia dostawca powinien ponosić odpowiedzialność za kwestie, które nie są wyraźnie określone w specyfikacjach”. Biorąc pod uwagę ten punkt, można uzyskać wiele wskazówek z treści poniższego artykułu.

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

W powyższym artykule wyjaśniamy, do jakiego stopnia dostawca powinien wykorzystać swój urok i podjąć obowiązek implementacji, nawet jeśli nie jest to zapisane w specyfikacjach. Tutaj wyjaśniamy, że historia jest bardzo różna między “stroną ekranu” (tzw. “frontend”), która jest łatwo widoczna w dokumentach definicji wymagań i podstawowych dokumentach projektowych, a “stroną logiki” (tzw. “backend”, “baza danych”) takich jak migracja danych. Innymi słowy, można przypuszczać, że “strona ekranu”, której problemy ze specyfikacjami są łatwo zauważalne nawet dla zamawiających/użytkowników, którzy zazwyczaj nie mają specjalistycznej wiedzy na temat projektów rozwoju systemów, ma tendencję do bycia obarczaną odpowiedzialnością przez zamawiających/użytkowników. Z drugiej strony, problemy “strony logiki” mają tendencję do bycia obarczane odpowiedzialnością przez dostawców. Biorąc pod uwagę te punkty, można przypuszczać, że problemy z rozmiarami serwera są obszarem, który jest trudny do zrozumienia bez specjalistycznej wiedzy technicznej, i że jest to obszar, który ma tendencję do bycia obarczanym odpowiedzialnością przez dostawców. Dlatego, jeśli sprawa ta zostanie rzeczywiście rozstrzygnięta w sądzie, można przewidzieć, że bez aktywnych okoliczności zwalniających dostawcę z odpowiedzialności, wyrok będzie zazwyczaj niekorzystny dla dostawcy.

Środki zapobiegające problemom wynikającym z błędów w doborze rozmiaru serwera

Aby zapobiec problemom, jakie zostały wcześniej omówione, ważne jest, aby zadbać o zgodność działań związanych z implementacją programu i zapisem kodu źródłowego z przygotowaniem środowiska infrastruktury. Konkretne środki, które można podjąć, to:

Określenie odpowiedzialności za dobór rozmiaru serwera w umowie

Nie tylko w przypadku takich sytuacji, wiele konfliktów związanych z projektami rozwoju systemów wynika z niejasności w podziale ról między specjalistami od rozwoju systemów, a użytkownikami zorientowanymi w sytuacji wewnętrznej firmy. Choć nie trzeba mówić, że ścisła współpraca między obiema stronami jest niezbędna dla płynnego przebiegu projektu, zaleca się, aby jak najbardziej jasno określić podział ról i zakres odpowiedzialności w umowach itp. przed rozpoczęciem projektu.

Pełne konkretne wymagania rozwoju i zarządzanie zmianami

Ponadto, jeśli wymagania funkcjonalne, które należy zrealizować, są niejasne, ryzyko skomplikowania takich sporów wzrasta. To obejmuje zarówno jasne określenie specyfikacji w fazie definicji wymagań na początku, jak i zarządzanie zmianami w trakcie projektu. Szczegółowe wyjaśnienia na temat tego, jak radzić sobie ze zmianami specyfikacji w trakcie projektu, można znaleźć w poniższym artykule.

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

Wybór modelu rozwoju dostosowanego do charakteru projektu

Ponadto, co jest ściśle związane z dwoma powyższymi środkami, ważne jest, aby wybrać odpowiedni model rozwoju dla projektu rozwoju systemów, biorąc pod uwagę jego charakter i skalę. Ogólnie rzecz biorąc, jeśli chodzi o rozwój systemów o pewnej skali, gdzie dobór rozmiaru serwera może być ważny, korzyści z zastosowania modelu kaskadowego, który jest odpowiedni do jasnego określenia specyfikacji i zakresu odpowiedzialności, zwiększają się. Szczegółowe wyjaśnienia na temat wyboru odpowiedniego modelu rozwoju, biorąc pod uwagę charakter projektu, można znaleźć w poniższym artykule.

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

Podsumowanie

Problemy związane z infrastrukturą, które mogą powstać podczas przygotowywania środowiska dla projektu rozwoju systemu, są często punktem, który łatwo przeoczyć. Uważa się, że monitorowanie problemów związanych z infrastrukturą może być nie lada wyzwaniem dla osób niebędących ekspertami technicznymi. Jednakże, środki zapobiegawcze dla takich problemów mogą być uważane za rozszerzenie podstawowych działań, takich jak “jasne określenie specyfikacji/zarządzanie zmianami”, “jasne określenie ról/zakresu odpowiedzialności”, “wybór modelu rozwoju dostosowanego do skali i budżetu projektu”. Punktem, który osoby zajmujące się prawem korporacyjnym powinny zrozumieć na początku, jest to, że podstawy prawne zapobiegania problemom z infrastrukturą mogą być w pełni rozwinięte. Ponadto, dla inżynierów IT, zrozumienie, że problemy z infrastrukturą mogą stanowić poważne ryzyko dla projektu, i efektywne zarządzanie pracą jest uważane za kluczowe.