Care sunt punctele esențiale de verificat în contractele pentru dezvoltarea de sisteme de tip contractant?

Ministerul Economiei, Comerțului și Industriei din Japonia (Japanese Ministry of Economy, Trade and Industry) a prezentat clauze model pentru contractele de dezvoltare a sistemelor IT în “Ghidul pentru îmbunătățirea fiabilității sistemelor de informații” (Japanese “Guidelines for Improving the Reliability of Information Systems”). Odată cu răspândirea internetului, impactul social al întreruperii sau scăderii funcționalității serviciilor și operațiunilor datorate defecțiunilor sistemelor de informații devine din ce în ce mai grav. În timp ce îmbunătățirea fiabilității și securității sistemelor este o problemă urgentă, tipul de contract pentru dezvoltarea sistemelor IT tinde să fie neclar în ceea ce privește conținutul tranzacției. Prin urmare, aceste clauze vizează clarificarea și vizualizarea rolurilor și responsabilităților. În acest articol, vom explica punctele de verificat în contractele de dezvoltare a sistemelor IT, citând clauzele din contractul model al Ministerului Economiei, Comerțului și Industriei.

Dezvoltarea sistemelor și contractele de prestări servicii

Ce este un contract de prestări servicii

Contractul de prestări servicii este definit în Codul Civil Japonez (Codul Civil Japonez) astfel:

Articolul 632
Contractul de prestări servicii ia naștere atunci când una dintre părți promite să finalizeze o anumită muncă, iar cealaltă parte promite să plătească pentru rezultatul acestei munci.

În cadrul unui contract de prestări servicii, este necesar ca “să se promită finalizarea unei munci”. De exemplu, dacă obiectivul contractului este de a crea un anumit sistem până la o anumită dată, obligația furnizorului este de “a finaliza sistemul până la data stabilită”. Dacă nu reușește să finalizeze sistemul până la data promisă, poate fi considerat responsabil pentru neexecutarea obligațiilor datorate întârzierii. Cu toate acestea, dacă sistemul este finalizat și livrat până la data stabilită și ulterior se constată deficiențe, obligația furnizorului a fost deja îndeplinită, astfel încât neexecutarea obligațiilor nu este o problemă, iar problema devine una de răspundere pentru vicii. În dezvoltarea sistemelor, detaliile despre când se consideră că “munca a fost finalizată” sunt explicate în detaliu în articolul de mai jos.

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

Diferențele față de contractul de mandat

În cadrul unui contract de prestări servicii, furnizorul are obligația de a finaliza munca, astfel că, dacă produsul livrat are vicii, acesta va fi responsabil pentru garanția viciilor. În contrast, în cadrul unui contract de mandat, nu există o obligație de a finaliza munca, astfel că nu există o responsabilitate pentru garanția viciilor, așa cum există în cazul contractului de prestări servicii. Cu toate acestea, în procesul de gestionare a afacerilor, dacă se recunoaște o obligație de diligență, poate exista o responsabilitate separată pentru neexecutarea obligațiilor, cum ar fi despăgubirile. Detalii despre ce fel de responsabilitate poate deveni o problemă în contractele de dezvoltare a sistemelor sunt explicate în detaliu în articolul de mai jos.

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

Modelul de clauze contractuale și punctele de verificare

Servicii de asistență pentru crearea definițiilor de cerințe

Definirea cerințelor este procesul de a compila specificațiile solicitate de sistemul pe care utilizatorul încearcă să îl construiască. În etapa de definire a cerințelor, se examinează direcția construcției sistemului și se decide ce tip de sistem să se construiască. Deoarece rezultatele nu pot fi prevăzute în mod concret, contractul model al Ministerului Economiei, Comerțului și Industriei Japoneze (Japanese Ministry of Economy, Trade and Industry) prevede acesta ca un mandat quasi. Detalii suplimentare sunt explicate în articolul de mai jos.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

Crearea Documentelor de Proiectare Externă

(Implementarea activității de creare a documentului de proiectare externă)
Articolul ○: Părțile vor încheia un contract individual conform articolului ○, iar Partea B va realiza activitatea de creare a documentului de proiectare externă pentru software-ul în cauză, bazându-se pe documentul de definire a cerințelor stabilite conform articolului ○.

2. În timpul implementării activității de creare a documentului de proiectare externă, Partea B poate solicita cooperarea Partei A, iar Partea A va răspunde în mod corespunzător la această solicitare în timp util.

Crearea documentului de proiectare externă este o activitate care stabilește utilizarea componentelor legate de interfață, cum ar fi ecranele și rapoartele. Documentul de proiectare externă trebuie să conțină, în principiu, toate informațiile necesare pentru ca furnizorul să poată dezvolta programul. Documentul de proiectare externă include detalii despre utilizarea formatului, dar partea care poate modifica specificațiile cerute este partea care stabilește conținutul activității, adică utilizatorul. Cu toate acestea, dacă documentul de definire a cerințelor, care este rezultatul fazei anterioare a activității de creare a documentului de proiectare externă, definește clar cerințele utilizatorului și conținutul muncii pe care furnizorul trebuie să o finalizeze, atunci contractul poate fi încheiat într-o formă în care furnizorul este partea principală în crearea documentului de proiectare externă.

Paragraful 1 stabilește că furnizorul este partea principală în realizarea activității, deoarece acest proces este de tip contract. Cu toate acestea, chiar și în cazul unui contract, proiectarea externă implică în mare măsură stabilirea conținutului activității utilizatorului, deci este necesară implicarea activă a utilizatorului. Prin urmare, paragraful 2 clarifică faptul că examinarea specificațiilor sistemului este o activitate comună între furnizor și utilizator, stipulând că furnizorul poate solicita cooperarea utilizatorului pentru examinarea și stabilirea specificațiilor sistemului, iar utilizatorul trebuie să răspundă în mod corespunzător la această solicitare în timp util.

(Încheierea unui contract individual referitor la crearea de documente de proiectare externă)
Articolul ○: Părțile A și B vor stabili condițiile tranzacției menționate în paragraful ○ al articolului ○, prin discuții, și vor încheia un contract individual referitor la crearea de documente de proiectare externă.

În ceea ce privește domeniul de aplicare și altele asemenea ale creării de documente de proiectare externă, acestea vor fi stabilite într-un contract individual, în conformitate cu condițiile tranzacției stabilite în clauza anterioară.

(Comitetul de Discuții pentru Proiectarea Externă)
Articolul ○: Părțile convin că, pentru a clarifica sau a confirma aspectele necesare pentru crearea documentului de proiectare externă, Comitetul de Discuții pentru Proiectarea Externă (denumit în continuare în acest paragraf “Comitetul de Discuții”) va fi organizat la o frecvență considerată necesară, iar Partea A va participa la acesta.

2. De asemenea, Partea A poate organiza Comitetul de Discuții atunci când consideră necesar pentru crearea documentului de proiectare externă, iar Partea B va participa la acesta.

3. În cazul în care, în urma discuțiilor din cadrul Comitetului de Discuții, Partea A intenționează să modifice conținutul documentului de definire a cerințelor și este necesar să modifice condițiile contractului individual, cum ar fi perioada de lucru sau taxa de delegare, aceasta se va face conform procedurilor stabilite în Articolul 33 (Modificarea conținutului acestui contract și al contractului individual).

Pentru a stabili interfețele, cum ar fi ecranele și formularele, în documentul de proiectare externă, este esențială colaborarea între utilizator și furnizor. Deoarece acest proces este de tip contract, paragraful 1 prevede că furnizorul va organiza Comitetul de Discuții, iar utilizatorul va participa la acesta. Clarificarea sau confirmarea aspectelor necesare pentru crearea documentului de proiectare externă se va face în cadrul Comitetului de Discuții, iar furnizorul și utilizatorul vor fi obligați de rezultatele discuțiilor din cadrul Comitetului.

Paragraful 2 prevede că utilizatorul poate organiza Comitetul de Discuții atunci când este necesar pentru realizarea activităților de creare a documentului de proiectare externă. Paragraful 3 prevede că, în cazul în care, în urma discuțiilor, utilizatorul intenționează să modifice conținutul documentului de definire a cerințelor, ceea ce ar putea afecta perioada de lucru sau taxa de delegare specificată în contractul individual, se va conforma cu metoda de modificare a conținutului acestui contract și al contractului individual, stabilită într-un alt articol.

(Predarea documentației de proiectare externă)
Articolul ○: Până la data specificată în contractul individual, Partea B va livra Partei A documentația de proiectare externă și cererea de acceptare a documentației de proiectare externă (care servește și ca document de livrare).

Având în vedere că acest proces este de tip contract, furnizorul va livra documentația de proiectare externă, printre altele, ca rezultat al muncii sale.

(Aprobarea și finalizarea documentului de proiectare externă)
Articolul ○ stipulează că părțile A vor verifica în perioada stabilită în contractul individual (denumită în continuare “perioada de verificare a documentului de proiectare externă”) dacă documentul de proiectare externă este conform cu documentul de definiție a cerințelor confirmat conform articolului ○ și cu deciziile luate în cadrul comitetului de discuții privind proiectarea externă, precum și dacă nu există erori logice. În semn de aprobare a conformității și a absenței erorilor logice, responsabilii ambelor părți vor semna și ștampila documentul de aprobare a proiectării externe. Cu toate acestea, dacă în urma verificării se descoperă că documentul de proiectare externă nu este conform cu documentul de definiție a cerințelor sau cu deciziile luate în cadrul comitetului de discuții privind proiectarea externă, sau dacă se descoperă erori logice, partea B va crea o versiune revizuită în termenul stabilit prin discuții și o va prezenta părții A, care va efectua din nou procedurile de verificare și aprobare menționate mai sus.

2. Dacă partea A nu ridică obiecții în scris și cu motive concrete în timpul perioadei de verificare a documentului de proiectare externă, se consideră că partea A a aprobat documentul de proiectare externă la expirarea perioadei de verificare.

3. Documentul de proiectare externă este considerat finalizat prin aprobarea părții A conform celor două paragrafe anterioare.

În etapa de proiectare externă, se stabilesc cerințele necesare pentru crearea documentului de proiectare internă ulterior, dar dacă stabilirea cerințelor rămâne ambiguă, există riscul de a apărea probleme în dezvoltarea ulterioară. Acest articol prevede procedura de verificare a documentului de proiectare externă de către utilizator și de finalizare a acestuia prin aprobarea utilizatorului.

Paragraful 1 stipulează că utilizatorul va verifica dacă documentul de proiectare externă este conform cu documentul de definiție a cerințelor confirmat într-un alt articol și cu rezultatele discuțiilor din cadrul comitetului de discuții privind proiectarea externă, precum și dacă nu există erori logice. În timpul verificării pentru aprobarea documentului de proiectare externă, se poate decide că este necesară o revizuire, iar nota de subsol a acestui paragraf prevede procedura în acest caz.
Paragraful 2 prevede că, chiar dacă semnarea și ștampilarea aprobării nu sunt finalizate, dacă utilizatorul nu ridică obiecții într-o anumită perioadă de timp, se consideră că aprobarea a fost acordată de către utilizator. Intrarea în proiectarea internă cu statutul de aprobare al utilizatorului rămânând ambiguu poate provoca probleme ulterior, astfel încât acest paragraf intenționează să prevină astfel de probleme.

Și paragraful 3 stipulează că documentul de proiectare externă este finalizat prin aprobarea utilizatorului.

(Răspundere pentru garanția defectelor)
Articolul ○ După confirmarea articolului anterior, în cazul în care se descoperă o neconcordanță sau o eroare logică (denumită în continuare “defect” în acest articol) în documentul de proiectare externă cu documentul de definire a cerințelor și cu deciziile luate în cadrul reuniunii de discuții privind proiectarea externă conform articolului ○, Partea A poate solicita Partei B să corecteze defectul respectiv, iar Partea B trebuie să corecteze defectul respectiv. Cu toate acestea, Partea B va avea responsabilitatea de a face această corecție numai dacă solicitarea este făcută de Partea A în termen de ○ luni de la confirmarea articolului anterior.

2. Indiferent de paragraful anterior, dacă defectul este minor și necesită costuri excesive pentru corectarea documentului de proiectare externă, Partea B nu va avea responsabilitatea de a face corecția specificată în paragraful anterior.

3. Dispozițiile paragrafului 1 nu se aplică atunci când defectul a apărut din cauza documentelor furnizate de Partea A sau a instrucțiunilor date de aceasta. Cu toate acestea, acest lucru nu se aplică dacă Partea B nu a informat, deși știa că documentele sau instrucțiunile erau inadecvate.

Acest articol stabilește răspunderea pentru garanția defectelor în legătură cu documentul de proiectare externă. Perioada de garanție pentru defecte va fi stabilită prin discuții între părți, luând în considerare dimensiunea sistemului de informații și contravaloarea acestuia, și va fi stabilită o perioadă considerată rezonabilă.

Paragraful 1 definește ca defecte neconcordanța sau eroarea logică între documentul de proiectare externă și documentul de definire a cerințelor și deciziile luate în cadrul reuniunii de discuții privind proiectarea externă.

Paragraful 2 protejează furnizorul, stipulând că, chiar dacă defectul este minor, nu este rezonabil să se solicite furnizorului să corecteze produsul fără costuri, dacă aceasta necesită costuri excesive, în conformitate cu prevederile articolului 634 alineatul (1) din Codul Civil.

Paragraful 3, în conformitate cu prevederile articolului 636 din Codul Civil, stipulează că, dacă defectul este cauzat de instrucțiunile sau documentele furnizate de utilizator, furnizorul nu poate evita răspunderea de garanție, dacă nu indică faptul că documentele sau instrucțiunile utilizatorului sunt inadecvate, deși le cunoaște.

De asemenea, deoarece răspunderea pentru garanția defectelor este o dispoziție opțională, dacă nu se stabilește o astfel de dispoziție, se va aplica principiul general al Codului Civil. Răspunderea pentru garanția defectelor este puternic influențată de amendamentul Codului Civil care a intrat în vigoare în aprilie 2020 (anul 2 al erei Reiwa), astfel că după intrarea în vigoare a amendamentului Codului Civil, modul de abordare va fi diferit de cel anterior. Detalii sunt explicate în articolul de mai jos.

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

Servicii de dezvoltare software

(Implementarea activității de dezvoltare a software-ului)
Articolul 0: Părțile vor încheia un contract individual conform articolului 25 și vor efectua activități de dezvoltare a software-ului, de la proiectare internă până la testarea sistemului, în baza specificațiilor sistemului stabilite în secțiunile anterioare.

2. În timpul implementării activității de dezvoltare a software-ului, partea B poate solicita cooperarea părții A, iar partea A va răspunde în mod corespunzător la această solicitare în timp util.

În articolele următoare, se stabilesc clauzele pentru cazul în care dezvoltarea software-ului este realizată de către furnizor sub formă de contract. În etapa de proiectare internă a sistemului, este obișnuit ca obiectul de dezvoltare și specificațiile să fie definite până la etapele anterioare, astfel încât contractul model al Ministerului Economiei, Comerțului și Industriei (METI) din Japonia este stabilit sub formă de contract.

(Încheierea unui contract individual referitor la dezvoltarea de software)
Articolul X: Părțile A și B vor stabili termenii tranzacției menționați în Articolul X, Paragraful X, prin discuții referitoare la dezvoltarea de software și vor încheia un contract individual pentru dezvoltarea de software.

În ceea ce privește domeniul dezvoltării de software, se va stabili un contract individual în conformitate cu termenii tranzacției stabiliți anterior.

(Livrarea produselor)
Articolul X. Partea B va livra Partei A produsele specificate în contractul individual, împreună cu cererea de acceptare (care servește și ca document de livrare), până la data stabilită în contractul individual.
2. Partea A, în cazul unei livrări, va efectua inspecția în conformitate cu specificațiile de inspecție ale articolului următor, conform prevederilor articolului X (Acceptarea software-ului în cauză).
3. Partea B poate solicita Partei A cooperarea necesară în timpul livrării produselor, iar Partea A va răspunde prompt la această solicitare.
4. Riscul de pierdere sau deteriorare a produselor este suportat de Partea B înainte de livrare și de Partea A după livrare.

Deoarece acest proiect este de tip contract, software-ul finalizat și alte produse vor fi livrate ca rezultate care vor fi supuse inspecției. Primul paragraf stabilește că produsele vor fi livrate împreună cu cererea de acceptare (care servește și ca document de livrare).

Al doilea paragraf stabilește implementarea inspecției de către utilizator.
Al treilea paragraf stabilește obligația de cooperare a utilizatorului în cazul livrării la locația stabilită în contractul individual, deoarece pot exista cazuri în care este necesară cooperarea utilizatorului (de exemplu, când produsele sunt livrate la biroul utilizatorului sau când sunt livrate într-o stare funcțională în mediul de operare real al utilizatorului).
Al patrulea paragraf este o clauză privind riscul de pierdere sau deteriorare a produselor, împărțind momentul transferului de risc în funcție de transferul controlului fizic.

(Acceptarea software-ului în cauză)
Articolul X Cu privire la software-ul în cauză, dintre produsele livrate, părțile trebuie să îl inspecteze în conformitate cu specificațiile de inspecție ale articolului anterior, în perioada stabilită în contractul individual (denumită în continuare “perioada de inspecție”), și să verifice dacă software-ul corespunde cu specificațiile sistemului.

2. Dacă software-ul în cauză este conform cu inspecția menționată anterior, partea A va semna și ștampila un certificat de acceptare și îl va înmâna părții B. De asemenea, dacă software-ul nu trece de inspecția menționată anterior, partea A va înmâna părții B un document care explică în mod explicit motivele pentru care a fost respins, solicitând corecții sau completări. Dacă motivele de respingere sunt acceptate, partea B va corecta software-ul fără costuri suplimentare și îl va livra părții A în termenul stabilit prin consultări, iar partea A va efectua din nou inspecția specificată în paragraful anterior, în măsura necesară.

3. Chiar dacă nu se emite un certificat de acceptare, dacă partea A nu prezintă obiecții în scris cu motive concrete în perioada de inspecție, software-ul în cauză va fi considerat ca fiind acceptat conform inspecției specificate în acest articol.

4. Acceptarea software-ului în cauză se va considera finalizată odată cu acceptarea inspecției specificate în acest articol.

Având în vedere că acest proces este de tip contract, acest articol stabilește procedura de acceptare a software-ului livrat.

Paragraful 1 prevede că software-ul în cauză trebuie inspectat în conformitate cu specificațiile de inspecție în perioada de inspecție și verificat dacă corespunde cu specificațiile sistemului.
Paragraful 2 obligă furnizorul să corecteze software-ul dacă se constată că acesta nu corespunde specificațiilor sistemului și să livreze versiunea corectată utilizatorului.
Paragraful 3 previne amânarea acceptării din cauza circumstanțelor utilizatorului prin stabilirea unei prevederi privind acceptarea implicită.
Paragraful 4 precizează că acceptarea software-ului în cauză se finalizează odată cu acceptarea inspecției.

(Răspundere pentru garanția defectelor)
Articolul X După finalizarea inspecției menționate în articolul anterior, dacă se descoperă o neconformitate (inclusiv bug-uri, denumite în continuare în acest articol ca “defecte”) cu specificațiile sistemului pentru produsele livrate, Partea A poate solicita Partei B să corecteze defectul respectiv, iar Partea B va corecta defectul respectiv. Cu toate acestea, Partea B va fi responsabilă pentru corectarea acestui defect numai dacă este solicitată de Partea A în termen de X luni de la finalizarea inspecției menționate în articolul anterior.
2. Indiferent de paragraful anterior, dacă defectul este minor și corectarea produsului necesită costuri excesive, Partea B nu va fi responsabilă pentru corectarea defectului conform paragrafului anterior.
3. Dispozițiile paragrafului 1 nu se aplică atunci când defectul a apărut din cauza documentelor furnizate de Partea A sau a instrucțiunilor date de aceasta. Cu toate acestea, aceasta nu se aplică dacă Partea B nu a informat că documentele sau instrucțiunile sunt inadecvate, deși le cunoștea.

Acest articol stabilește răspunderea pentru garanția defectelor în legătură cu produsele livrate, deoarece acest proiect este pe bază de contract. Este dificil în practică să se determine granița dintre răspunderea pentru neexecutarea obligațiilor în cazul în care performanța nu a fost realizată (lucrarea nu este finalizată) și răspunderea pentru garanția defectelor după ce performanța a fost în principiu finalizată (lucrarea este finalizată). Există un precedent judiciar (Hotărârea Tribunalului Districtual Tokyo, 22 aprilie 2002 (anul 14 al erei Heisei)) care stabilește că dacă un sistem este considerat finalizat sau nu în dezvoltarea sistemului ar trebui să se bazeze pe faptul că lucrarea a fost finalizată până la ultima etapă planificată în contractul inițial. Dacă se descoperă un defect după finalizarea și inspecția software-ului până la ultima etapă planificată, în principiu se va aplica răspunderea pentru garanția defectelor.

Paragraful 1 definește “neconformitatea cu specificațiile sistemului” ca un defect în cadrul dezvoltării software-ului. Pentru deficiențele funcționale care apar în etapa de proiectare externă, responsabilitatea este determinată nu de acest articol, ci de dispozițiile privind răspunderea pentru garanția defectelor în etapa de proiectare externă. Perioada de garanție a defectelor este stabilită în funcție de dimensiunea sistemului informatic și de contraprestație, prin negocieri între părți, pentru o perioadă considerată rezonabilă.

Paragraful 2 prevede că, chiar dacă defectul este minor, dacă corectarea produsului necesită costuri excesive, este dur să se solicite furnizorului să corecteze gratuit, astfel încât se stabilește o dispoziție similară cu cea a articolului 634 alineatul (1) din Codul civil.

Paragraful 3, similar cu articolul 636 din Codul civil, prevede că dacă defectul este cauzat de instrucțiunile sau documentele furnizate de utilizator, furnizorul nu este responsabil, dar dacă furnizorul știe că documentele sau instrucțiunile utilizatorului sunt inadecvate și nu le indică, nu poate scăpa de responsabilitate.

Pentru a afla în ce situații se recunoaște existența unui defect și ce implică responsabilitatea în cazul în care un defect este recunoscut, consultați articolul de mai jos pentru o explicație detaliată.

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

Servicii de pregătire și tranziție pentru operarea software-ului

În etapa de acceptare și implementare a sistemului, este obișnuit ca utilizatorul să acționeze în mod proactiv. În contractul model al Ministerului Economiei, Comerțului și Industriei Japoneze (METI), se prevede că utilizatorul este principalul actor, iar furnizorul îl sprijină în acest sens, sub forma unui mandat parțial.

Stabilirea naturii contractului

Pentru a determina natura unui contract, trebuie să examinăm întregul contract și să ne întrebăm dacă scopul acestuia este de a “furniza un produs finit” sau dacă este ca furnizorul să “îndeplinească sarcinile într-un mod rezonabil”. Un indiciu general poate fi dacă conținutul produsului final este definit într-o oarecare măsură și dacă proiectul a progresat în direcția acestuia. Detalii despre aspectele specifice pe care trebuie să le luăm în considerare sunt explicate în detaliu în articolul de mai jos.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]