Despre problemele legale asociate cu baza de date a sistemului IT

Când vine vorba de înțelegerea problemelor legale legate de sistemele IT, este necesară o cunoaștere sistematică a legii, dar în același timp, este important să înțelegem și componentele sistemului IT. În acest articol, vom organiza modul în care sistemul IT este compus din diferite piese și cum funcționează aceste piese împreună, și vom discuta problemele legale care sunt strâns legate de bazele de date, care sunt adesea greu de observat din perspectiva utilizatorului.

Sistemele IT sunt compuse din “interfață” și “logică”

Ce înseamnă “interfață” într-un sistem IT

Când încercăm să înțelegem structura unui sistem IT, cel mai vizibil aspect este interfața. Într-adevăr, în procesul tipic de dezvoltare a sistemelor, după definirea cerințelor, cum ar fi identificarea funcțiilor, urmează de obicei “designul interfeței” și organizarea “tranzacțiilor între ecrane”. Aceste aspecte vizibile ale interfeței sunt domenii care sunt evident vizibile pentru utilizatorii care comandă dezvoltarea sistemului și, de asemenea, sunt domenii în care comunicarea între utilizatori și furnizori este cel mai probabil să fie intensă. În articolul de mai jos, explicăm “obligația de cooperare” pe care utilizatorul o are față de furnizor în toate etapele dezvoltării sistemului, pentru a atinge obiectivele proiectului.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Acest articol explică în principal necesitatea cooperării cu furnizorul în fazele precum designul de bază (adică interfața), ca parte a obligației de cooperare pe care utilizatorul o are în dezvoltarea sistemului.

“Interfața” într-un sistem IT este de obicei descrisă conform regulilor limbajelor de programare precum HTML sau CSS. Discuțiile despre “interfața” sistemului IT sunt adesea denumite “front-end”, “UI (User Interface)” etc., dar principalul punct de discuție este “ușurința de utilizare” și “vizibilitatea” din perspectiva utilizatorului.

Ce înseamnă “logică” într-un sistem IT

Însă, dacă un sistem IT este bazat doar pe “interfață”, atunci este doar un “ecran” care nu poate avea niciun “mișcare” sau “schimbare”. Chiar dacă primirea intrărilor de la utilizatori și afișarea ieșirilor se face pe “ecran”, acest proces implică “procesarea calculului”.

Aceste calcule și controale complexe sunt efectuate de componente care nu sunt vizibile utilizatorului, adică “partea din spate a sistemului”. Procesarea, cum ar fi căutarea datelor de pe ecran, modificarea datelor, adăugarea sau ștergerea, este posibilă doar datorită bazei de date construite în prealabil. Procesarea diverselor informații din baza de date este de obicei realizată în limbajul de programare numit SQL.

Crearea unui traseu de la declanșarea unui buton plasat pe ecran până la executarea instrucțiunii SQL necesare, este ceea ce finalizează imaginea de ansamblu a unui sistem cu mișcare și schimbare.

De notat că discuțiile legate de construirea diverselor logici care nu sunt vizibile de pe “ecran” sunt adesea numite “back-end”.

Discutarea sistemului doar din perspectiva “aspectului” vizual poate deveni un risc

Explicațiile de până acum formează baza structurii unui sistem IT (presupunând că acesta funcționează pe web). Înțelegerea acestor aspecte are o importanță majoră în discuțiile juridice, prevenirea conflictelor în proiecte, gestionarea crizelor și altele. Concret, se poate presupune că apar neînțelegeri în comunicare între utilizatorii care se concentrează doar pe “aspectul” vizual al ecranului și furnizorii care gestionează multe sarcini importante în partea “logică”, care nu este vizibilă.

Diferențele de interese între utilizatori și furnizori pot reprezenta un risc

De exemplu, utilizatorii care discută despre un sistem IT concentrându-se pe “interfața” tind să fie indiferenți față de complexitatea structurii interne. Din acest motiv, adesea nu înțeleg cât de mult poate influența un proces aparent simplu, cum ar fi “adaugarea unei funcții minore” sau “o mică modificare a specificațiilor”. De exemplu, în articolul de mai jos, explicăm problemele legale care pot apărea frecvent atunci când se renunță la un sistem existent în cadrul unui proiect de dezvoltare a unui nou sistem.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Aici, explicăm că adesea apar probleme în timpul transferului de date de la sistemul vechi la cel nou. Adică, complexitatea mecanismelor interne de calcul și control, care nu poate fi imaginată din aspectul exterior, poate deveni o sursă neașteptată de probleme pentru utilizatori. De asemenea, dacă nu înțeleg “sentimentele furnizorului care creează sistemul”, este posibil să apară situații în care modificările ulterioare sunt implementate treptat.

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

În cazurile în care sunt impuse modificări ulterioare ale specificațiilor sau adăugarea de funcții, problema dacă este posibilă o creștere ulterioară a recompensei poate deveni uneori o problemă serioasă.

https://monolith.law/corporate/increase-of-estimate[ja]

Riscul indiferenței utilizatorilor față de “logica” din spate

De asemenea, uneori, aspectele care nu pot fi observate de utilizatori pot deveni incidente majore atunci când apar probleme. Iată câteva exemple de acest gen.

Riscul apariției de probleme în ceea ce privește întreținerea și securitatea

Acesta include situații în care nu se pot implementa funcții suplimentare, funcționarea devine treptat mai lentă în timpul utilizării și ajunge să nu mai funcționeze deloc.

De asemenea, există metode de atac de securitate, numite “injecții SQL”, care exploatează deficiențele codului implementat pe partea de interfață, pentru a extrage informații personale și confidențiale care nu ar trebui să fie afișate pe ecran. Detalii despre cazurile care au devenit dispute grave ca urmare a acestui lucru pot fi găsite în articolul de mai jos.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

Deși tema principală a acestui articol este riscul asociat cu utilizarea framework-urilor și a bibliotecilor, cazurile de judecată prezentate implică atacuri asupra vulnerabilităților folosind injecții SQL.

Riscul ca guvernanța să nu se extindă la munca operatorilor de sistem

Indiferența utilizatorilor sistemelor IT față de “logica” din spate poate duce la dificultăți în extinderea guvernanței la munca operatorilor de sistem. În legătură cu acest subiect, articolul de mai jos explică importanța muncii care implică baze de date, sub tema “pierderea de date datorată neglijenței operatorului”.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Riscul ca logica să fie greșită, chiar dacă funcționează corect la suprafață

Faptul că discuția despre sistem nu se limitează la “ecran” înseamnă că, chiar dacă un sistem pare să funcționeze corect la suprafață, “logica” reală poate fi greșită. Acest lucru poate deveni evident în mod neașteptat în timpul operațiunilor neregulate, cum ar fi “o dată la șase luni” sau “o dată pe an”, chiar dacă nu a fost evident în operațiunile de bază zilnice.

În astfel de cazuri, din punct de vedere legal, problema este una de răspundere pentru defecte, nu de neexecutare a obligațiilor, în cazul “unui sistem care a fost livrat o dată și care a dezvăluit deficiențe ulterior”.

https://monolith.law/corporate/defect-warranty-liability[ja]

Ca măsură de răspuns în cazul în care se descoperă un defect după acceptare, detaliile procesului sunt explicate în detaliu în articolul de mai jos.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Rezumat

Înțelegerea sistematică a dezvoltării de sisteme și a dreptului

Problemele legale legate de dezvoltarea sistemelor presupun, ca premisă pentru identificarea problemelor legale, să înțelegem care componentă a sistemului IT a generat problema. Atât din punct de vedere legal, cât și din punct de vedere al sistemului IT, în conflictele care apar în proiectele de dezvoltare a sistemelor, este esențial să nu pierdem din vedere imaginea de ansamblu și să ne concentrăm pe colaborarea între diferite industrii.