Ce măsuri se iau în cazul în care se descoperă defecțiuni ale sistemului după acceptare?

Dezvoltarea de sisteme, în termeni generali, presupune implementarea programului în conformitate cu cerințele stabilite în faza de definire a cerințelor, iar în final, atât utilizatorul cât și furnizorul verifică dacă produsul final corespunde specificațiilor. Procesul se încheie odată cu acceptarea în urma testării.

Însă, în realitate, este foarte posibil ca bug-uri sau defecțiuni care nu au fost detectate în timpul testării sau la acceptare să apară în fazele ulterioare de operare. Dacă ați acceptat deja livrarea, ce puteți solicita din punct de vedere legal?

Nu este surprinzător că bug-urile persistă chiar și după acceptarea și testarea finală

Din punct de vedere tehnic, nu este deloc neobișnuit ca diverse bug-uri și defecțiuni să apară după finalizarea diferitelor etape de testare ale furnizorului și după acceptarea de către utilizator. În mod normal, ceea ce utilizatorul face în etapa de acceptare se concentrează pe verificarea intrărilor și ieșirilor care pot fi confirmate de pe ecran. Cu toate acestea, sistemele IT au adesea o structură complexă și detaliată în baza de date din spate și în părțile programului care controlează diverse calcule și controale, care depășește aspectul vizibil pe ecran care poate fi confirmat de către utilizator. Prin urmare, există o limită în ceea ce poate fi investigat din verificarea intrărilor și ieșirilor pe ecran din perspectiva utilizatorului. Prin urmare, nu este realist să verificăm exhaustiv toate posibilitățile de defecțiuni care pot apărea în faza de operare ulterioară în timpul verificării.

Aceeași situație se aplică și când privim din perspectiva furnizorului care se ocupă de dezvoltare. De exemplu, ‘etapa de testare’ este pentru a verifica dacă există bug-uri sau defecțiuni în conținutul programului implementat. Cu toate acestea, nu este neapărat așa că toate posibilitățile de bug-uri și defecțiuni pot fi verificate în etapa de testare. Chiar și după ce sistemul dezvoltat a început să fie utilizat în mod activ în afaceri, este necesară o abilitate tehnică excelentă pentru a crea un sistem care continuă să funcționeze fără probleme în timp ce operațiuni neașteptate de către furnizor sunt efectuate, sau când o cantitate mare de date începe să fie înregistrată, sau când mai mulți utilizatori încep să acceseze simultan.

Ar trebui să înțelegem mai întâi că nu este realist să descoperim toate bug-urile și defecțiunile în etapele de acceptare și testare, și că pot apărea diverse probleme după ce începem să folosim sistemul IT.

De obicei, datoria în sine este considerată îndeplinită

Deci, cum ar trebui să abordăm aceste probleme atunci când apar în realitate? Vom organiza în conformitate cu ordinea legală.

În primul rând, dacă au apărut diverse bug-uri sau probleme, chiar și după fapt, utilizatorii vor dori probabil să urmărească o anumită responsabilitate față de furnizorul căruia i-au încredințat până acum activitatea. Cu toate acestea, de obicei, dacă livrarea a fost deja finalizată și a trecut de acceptare, este adesea dificil să urmărești responsabilitatea pe baza neîndeplinirii obligațiilor.

În primul rând, dacă nu există nicio înțelegere specială, reglementările privind implementarea programului în contractele de dezvoltare a sistemelor se aplică în conformitate cu prevederile contractului civil. Detalii despre ce este un contract civil sunt explicate în detaliu în articolul de mai jos.

https://monolith.law/corporate/system-development-contact-agreement[ja]

Și în contractul civil, “finalizarea lucrării” este o cerință pentru îndeplinirea obligațiilor. Ce înseamnă exact “finalizarea lucrării” este explicat în detaliu în articolul de mai jos.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Aici, explicăm că “finalizarea lucrării” în contractul civil, în contextul dezvoltării de sisteme, înseamnă finalizarea întregului proces de dezvoltare, conform precedentelor judiciare. Și explicăm că problemele, cum ar fi bug-urile și defecțiunile care apar după finalizarea întregului proces de dezvoltare, sunt o problemă de răspundere pentru garanția defectelor în contractul civil.

Pentru a rezuma, dacă ați acceptat deja livrarea și ați finalizat până la acceptare, presupunem că obligația în sine a fost deja îndeplinită, iar problema ulterioară a garanției de calitate, adică dacă se poate urmări răspunderea pentru garanția defectelor, este de obicei cazul.

Calea de urmărire a responsabilității bazate pe răspunderea pentru garanția defectelor

Deci, în cazul în care solicitați un răspuns de la vânzător pe baza răspunderii pentru garanția defectelor, ce ar trebui să luați în considerare și în ce ordine? Să verificăm mai jos.

În primul rând, verificați gradul de gravitate și seriozitate a bug-urilor și a defecțiunilor

Când bug-urile și defecțiunile sunt descoperite ulterior și se solicită o anumită garanție pe motiv că acestea sunt “defecte” în sensul legal, gravitatea bug-urilor și a defecțiunilor devine o problemă. Problema defectelor legale este, în primul rând,

1. Chiar dacă este un bug sau o defecțiune, este doar o problemă minoră și nu poate fi considerată o “defecțiune” în sensul legal
2. Se încadrează în “defecțiunea” legală, dar realizarea obiectivului contractului este posibilă
3. Se încadrează în “defecțiunea” legală și realizarea obiectivului contractului nu este posibilă

Acestea se împart în trei modele. Ceea ce distinge posibilitatea de a urmări responsabilitatea pe baza răspunderii pentru garanția defectelor este linia dintre 1 și 2, iar ceea ce distinge posibilitatea de a rezilia contractul pe baza răspunderii pentru garanția defectelor este linia dintre 2 și 3.

Articolul 634

1. Când există defecte în obiectul muncii, comandantul poate solicita executantului să repare defectele într-o perioadă rezonabilă. Cu toate acestea, acest lucru nu se aplică în cazul în care defectul nu este important și repararea acestuia necesită costuri excesive.

2. Comandantul poate solicita despăgubiri în locul sau împreună cu repararea defectelor. În acest caz, se aplică prevederile articolului 533

Articolul 635

Când există defecte în obiectul muncii și din acest motiv nu se poate atinge obiectivul contractului, comandantul poate rezilia contractul. Cu toate acestea, acest lucru nu se aplică la clădiri sau alte lucrări de teren.

De asemenea, am explicat în detaliu despre această distincție graduală a “defectelor” în articolul de mai jos.

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

În continuare, clarificați ce ar trebui să solicitați de la vânzător

În plus, trebuie să clarificați ce ar trebui să solicitați de la partea adversă. Dacă doriți să reziliați contractul, nu este suficient să dovediți doar că este un defect, trebuie să fie ceva care “nu poate atinge obiectivul contractului”. În evaluarea “obiectivului” menționat aici, procesele verbale ale întâlnirilor care au avut loc la începutul proiectului de dezvoltare a sistemului și elementele înscrise în specificații sunt considerate indicii importante. Deoarece este posibil ca bug-urile și defecțiunile să fie descoperite ulterior, chiar și după acceptarea finală, este necesar să păstrați cu strictețe toate documentele chiar și după finalizarea proiectului de dezvoltare.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

În plus față de reziliere, ceea ce se poate solicita ca conținut al răspunderii pentru garanția defectelor include solicitarea de despăgubiri și solicitarea de reparare a defectelor.

Alte aspecte de luat în considerare

Atenție la modul în care se desfășoară actele juridice, cum ar fi rezilierea contractelor

Dacă, în contextul răspunderii pentru vicii ascunse, decideți să reziliați contractul, ar trebui să vă familiarizați și cu modul în care se desfășoară procedurile juridice necesare pentru reziliere. Efectele rezilierii contractului, modul corect de exprimare a intenției, și cum să trimiteți notificări pentru a evita probleme ulterioare sunt detaliate în articolul de mai jos.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Este preferabil să se rezolve problemele prin negocieri, nu prin litigii

De asemenea, aceste discuții juridice nu sunt relevante doar în cazul în care se ajunge la tribunal. Rezolvarea litigiilor prin instanță poate fi foarte costisitoare pentru ambele părți. În schimb, aceste cunoștințe juridice pot fi foarte utile chiar și în etapa de negociere, înainte de a ajunge la tribunal. Semnificația acestor cunoștințe juridice în negocierile care nu implică instanța este explicată în detaliu în articolul de mai jos.

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

Ar trebui să distingem între bug-uri și defecțiuni, și lipsa de funcționalitate

Discuțiile vor fi diferite dacă există bug-uri sau defecțiuni în funcțiile sau specificațiile implementate, sau dacă pur și simplu lipsesc funcțiile necesare. Dacă funcțiile necesare nu sunt complet implementate, este posibil ca “finalizarea muncii” în contractul de prestări servicii să nu fie recunoscută, și astfel să nu se recunoască îndeplinirea obligațiilor.

De asemenea, chiar dacă funcțiile sau specificațiile necesare nu sunt implementate, dacă utilizatorul nu a furnizat informațiile adecvate în etapa de definire a cerințelor, este posibil ca aceasta să fie considerată o parte inadecvată a conținutului contractului.

Rezumat

Problemele care apar în cursul unui proiect pot fi descoperite fie în timpul desfășurării acestuia, fie în etapele de operare, după finalizare. Caracteristica unui proiect de dezvoltare a sistemelor, care nu ne permite să ne relaxăm chiar și după finalizarea tuturor etapelor, pare să fie simbolizată de sistemul de “răspundere pentru defecte”. Se consideră important să se asigure o gestionare riguroasă a documentelor, luând în considerare și perioada de după finalizarea proiectului de dezvoltare a sistemelor, precum și să se înțeleagă acest flux continuu de evenimente.