Ce probleme legale sunt legate de serverul și infrastructura de dezvoltare a sistemului?

Sistemele IT utilizate în companii sunt, într-un anumit sens, create prin elaborarea de specificații și documente de proiectare și prin scrierea codului sursă care corespunde acestor conținuturi. Cu toate acestea, sistemul funcționează efectiv nu doar prin aceste aspecte soft, ci și prin prezența unui computer fizic, adică a infrastructurii. În acest articol, vom discuta problemele legale strâns legate de domeniul infrastructurii în proiectele de dezvoltare a sistemelor.

Ce înseamnă infrastructura în sistemul IT

Inginerii care dezvoltă sisteme sunt cunoscuți sub numele de ingineri de sistem (SE). Proiectele de dezvoltare încep cu procesele de amonte, cum ar fi crearea de specificații și documente de proiectare, și continuă cu implementarea programului și efectuarea testelor. În sens larg, un inginer de sistem (SE) poate fi descris ca un tehnician care se ocupă de toate aceste sarcini necesare. Cu toate acestea, în funcție de companie sau locul de muncă, numele pot fi diferențiate mai detaliat în funcție de sarcinile și domeniile de responsabilitate. Termenul de inginer de infrastructură se referă la tehnicienii care se ocupă în special de pregătirea mediului de funcționare al computerelor fizice în cadrul activităților de dezvoltare și operare a sistemelor IT. Sistemele IT utilizate în companii și locuri de muncă sunt, într-un anumit sens, construcții abstracte formate din combinații de coduri sursă. Cu toate acestea, pentru ca aceste sisteme să își îndeplinească rolul așteptat, este esențială construirea mediului înconjurător al infrastructurii, inclusiv servere și rețele. Dezvoltarea sistemelor avansează pe două roți: implementarea codului sursă al programului și pregătirea mediului înconjurător al infrastructurii care susține acest mediu de funcționare. Se consideră că această perspectivă este importantă pentru prevenirea apariției unor probleme neprevăzute.

Scenarii concrete în care problemele de infrastructură pot duce la eșecul unui proiect

În proiectele de dezvoltare a sistemelor, este posibil să se concentreze doar pe programe abstracte și pe designul codului sursă, neglijând perspectiva infrastructurii. Cu toate acestea, dacă cele două aspecte nu sunt sincronizate, acest lucru poate duce la riscul de eșec al proiectului.

Cum pot duce greșelile de dimensionare a serverului la conflicte

De exemplu, se poate întâmpla ca, după finalizarea implementării și testării programului, să se descopere că performanța serverului este insuficientă și că sistemul nu este practic. De asemenea, anticiparea nivelului de încărcare pe care sistemul îl poate suporta în faza de operare și realizarea unei infrastructuri adecvate pentru dimensiunea sistemului este cunoscută sub numele de “dimensionare”. Există cazuri în care greșelile de dimensionare a serverului au dus la probleme, care s-au întâmplat de fapt în trecut. (Deși s-a rezolvat prin mediere, puteți lua ca referință acest caz cunoscut.) De asemenea, despre metoda de rezolvare a conflictelor dintre părțile implicate prin “mediere”, explicăm în detaliu în articolul de mai jos.

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

Faptul că conflictul s-a rezolvat prin mediere înseamnă, simplu spus, că disputa s-a încheiat prin “discuții” între părțile implicate. Prin urmare, spre deosebire de cazul în care o hotărâre este pronunțată de un tribunal, conținutul medierii nu este acumulat ca precedent, fiind de obicei specific fiecărui caz.

Esența cazului este domeniul de responsabilitate al furnizorului pentru specificațiile neclare

Totuși, esența acestor conflicte poate fi considerată “până unde ar trebui să își asume responsabilitatea furnizorul pentru elementele care nu sunt explicit specificate”. Având în vedere acest punct, puteți obține multe indicii din conținutul articolului de mai jos.

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

În articolul de mai sus, explicăm până unde furnizorul poate exercita discreția și asuma responsabilitatea pentru implementare, în cazul elementelor care nu sunt menționate în specificații. Aici, explicăm că povestea diferă semnificativ între elementele “vizuale” care pot fi ușor vizualizate în documente precum documentul de definire a cerințelor sau documentul de design de bază (domeniul așa-numitului “front-end”) și “logica” precum migrarea datelor (domeniul așa-numitului “back-end”, “baza de date”). Adică, se poate presupune că există o tendință ca problemele de specificații care pot fi ușor verificate de către comandantul/utilizatorul (care de obicei nu are cunoștințe de specialitate despre proiectele de dezvoltare a sistemelor) să fie atribuite comandantului/utilizatorului. Pe de altă parte, se poate presupune că există o tendință ca problemele “logice” să fie atribuite furnizorului. Având în vedere aceste puncte, se poate presupune că problemele de dimensionare a serverului sunt într-un domeniu care este greu de recunoscut problema decât dacă este un expert în tehnologie, și deci este un domeniu care este probabil să fie atribuit furnizorului. Prin urmare, dacă acest punct va fi disputat în instanță, se poate presupune că, în absența unor circumstanțe active pentru a exonera responsabilitatea furnizorului, va fi probabil ca o decizie nefavorabilă să fie luată împotriva furnizorului.

Măsuri pentru prevenirea problemelor cauzate de erorile de dimensionare a serverului

Pentru a preveni problemele menționate anterior, este important să aliniați implementarea programului și descrierea codului sursă cu pregătirea mediului de infrastructură. Măsurile concrete care pot fi luate includ următoarele:

Clarificarea responsabilităților legate de dimensionarea serverului în contract

Nu numai în astfel de cazuri, dar multe dintre conflictele legate de proiectele de dezvoltare a sistemelor provin din faptul că împărțirea rolurilor nu este clară între furnizorul specializat în dezvoltarea sistemelor și utilizatorul care cunoaște situația internă a companiei. Desigur, este esențială o colaborare strânsă între cele două părți pentru o derulare fără probleme a proiectului, dar este de dorit să clarificați cât mai mult posibil împărțirea rolurilor și domeniul de responsabilitate în contract înainte de a începe.

Concretizarea cerințelor de dezvoltare și gestionarea completă a modificărilor

De asemenea, dacă cerințele funcționale care trebuie realizate sunt vagi, riscul de a intra într-un conflict crește. Acest lucru implică atât clarificarea specificațiilor în faza de definire a cerințelor inițiale, cât și gestionarea modificărilor în timpul proiectului. Cum să răspundeți la modificările specificațiilor în timpul proiectului este explicat în detaliu în articolul de mai jos.

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

Selectarea modelului de dezvoltare potrivit naturii proiectului

De asemenea, în strânsă legătură cu cele două puncte de mai sus, este important să alegeți modelul de dezvoltare potrivit pentru natura și dimensiunea proiectului de dezvoltare a sistemului. În general, pentru dezvoltarea sistemelor de o anumită dimensiune, unde dimensionarea serverului poate deveni importantă, se consideră că beneficiile adoptării modelului waterfall, care este potrivit pentru clarificarea specificațiilor și a domeniului de responsabilitate, cresc. În ceea ce privește alegerea modelului de dezvoltare potrivit în funcție de natura proiectului, acesta este explicat în detaliu în articolul de mai jos.

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

Rezumat

Problemele care apar în cadrul proiectelor de dezvoltare a sistemelor, începând cu pregătirea mediului de infrastructură, sunt puncte care pot fi ușor trecute cu vederea. Se consideră că nu este o sarcină ușoară pentru cei care nu sunt experți în tehnologie să acorde atenție și problemelor de infrastructură. Cu toate acestea, măsurile de prevenire a acestor probleme pot fi considerate o extensie a măsurilor de bază, cum ar fi “clarificarea specificațiilor / gestionarea riguroasă a modificărilor”, “clarificarea rolurilor / domeniului de responsabilitate” și “selectarea modelului de dezvoltare în funcție de dimensiunea și bugetul proiectului”. Un punct pe care cei implicați în afacerile juridice corporative ar trebui să îl înțeleagă în primul rând este că bazele prevenirii problemelor juridice pot fi suficient de aplicate și în cazul problemelor de infrastructură. De asemenea, pentru inginerii din domeniul IT, este important să înțeleagă că problemele de infrastructură pot deveni un risc grav de eșec al proiectului și să gestioneze eficient activitatea.