- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (79)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Právní aspekty agilního vývoje softwaru
Rozhodování českých soudů ve sporech souvisejících s vývojem či implementací softwaru je zdlouhavé a komplikované. Větinou se jedná o spory závislé na výsledcích znaleckých posudků, bohuel znalců v této oblasti není dostatek, a navíc ne vichni jsou schopni formulovat své závěry tak, aby byly dostatečně srozumitelné pro soud. Nadto jsou závěry často ne zcela jasné, resp. mnohdy znalec dojde k závěrům, e dokumentace, která mu byla předloena, nemůe jednoznačně prokázat, která ze stran je na vině neúspěného projektu.

Z toho důvodu klientům doporučujeme v případě takového sporu vyvinout maximální úsilí k narovnání vztahů mezi zhotovitelem a objednatelem softwaru. K narovnání vztahů můe přispět jak mediátor (strany si jej mohou zvolit samy, případně jej můe jmenovat soud), tak rozumný právní zástupce. Z naí zkuenosti ti advokáti, kteří se v oblasti práva ICT pohybují pravidelně, mají větí snahu hledat kompromisní řeení.
Zajímavým aktuálním rozhodnutím je rozhodnutí Okresního soudu v Opavě sp. zn. 138 C 31/2018-208. Jedná se vak o rozhodnutí soudu nií instance, nikoli soudu vyího, které by mělo irí váhu. Rozhodnutí poutá pozornost zejména tím, e se soud zabýval agilním vývojem softwaru.
Obecně je agilní vývoj sloitějí na přípravu smluvní dokumentace, jeliko se na vývoji podílí několik stran ivelně a je třeba podchytit primárně jejich odpovědnost a zdokumentovat dodávky kódu. Současně vdy doporučujeme ve smlouvě zakotvit monost ukončení prací a smluvního vztahu v případě, e se ukáe, e spolupráce nefunguje. Toto ukončení musí být přitom vyváené, tedy aby objednatel měl dostatečnou časovou flexibilitu a zhotovitel měl monost převést vývojáře na jiný projekt.
V diskutovaném rozhodnutí soud posuzoval situaci, kdy zhotovitel softwaru poadoval po objednateli zaplacení částky, kterou objednatel s ohledem na kvalitu dodání rozporoval. Soud vycházel primárně ze znaleckého posudku, podle kterého byla cena dodaného díla zhruba třetinová oproti poadované. Nicméně znalec konstatoval, e vyuitelnost softwaru byla pro objednatele v zásadě nulová.
Soud v tomto případě alobu zcela zamítl, a to zejména z následujících důvodů:
- Nenalezl záznam o funkčním programu jako celku, který by byl převzat objednatelem, přičem z neúplných částí zdrojových kódů je patrno, e byly rozpracovány dvě části budoucího programu (login a user). Toto vak nelze povaovat za program, u kterého by bylo mono stanovit trní cenu.
- V daném případě smlouva ukládá zhotoviteli povinnost upozornit na zadání, která nejsou v souladu s navrhovaným technickým řeením (nebylo přitom prokázáno, e by tak alobkyně jako zhotovitel učinila).
- Plnění dodané na podkladě objednávky rámcové netvoří ucelený program ani jeho části, které by mohly být uplatněny na trhu. Z tohoto důvodu nelze stanovit jeho adekvátní trní cenu, resp. jeho trní cena je v dodané podobě nulová.
- Rozsah alobkyní (jako zhotovitelem) vykázaných prací podle odevzdaného zdrojového kódu a jeho funkčnosti je výrazně nadhodnocený (minimálně 3x), zadávané sluby byly sice zhotovitelem průběně plněny, ale nedostatečné zadání a prakticky chybějící technická a datová analýza vyvíjeného programu vedly k větímu objemu práce, ne by bylo potřeba v případě systematicky zadaného projektu.
- Vzhledem k absenci dokumentace, popisu datového modelu a celkové specifikace vyvíjeného programu by naprogramované zdrojové kódy mohl k dalímu vývoji efektivně vyuít pouze zhotovitel. Pro třetí stranu je vyuitelnost naprogramovaného zdrojového kódu prakticky nulová.
Soud současně konstatoval, e jednotlivé sprinty byly dílčími smlouvami o dílo. To je přitom klíčové, protoe pokud se strany nedohodnou jinak, pak nárok na zaplacení vzniká předáním. V tomto případě byla tedy situace jednoduchá fakturace za sprinty mohla probíhat a po jejich převzetí a odsouhlasení objednatelem. A k tomu nedolo.
Soud tímto rozhodnutím připomněl, e při vývoji softwaru se nesmí zapomínat na jasné vymezení předávání dílčích částí díla. Současně je nutné zajistit, aby toto odpovídalo realitě. V praxi se často setkáváme s tím, e právníci ve shodě se smluvními stranami sice definují konkrétní postup, ale realita mezi stranami funguje jinak. Pak můe nastat situace, e zhotovitel sice něco dodá, ale z pohledu smlouvy nevznikne na zaplacení nárok.
![]() |
Zdeněk Kučera Autor článku je partner a head of TMT v mezinárodní právní kanceláři Dentons s více ne 15 lety zkueností v oblasti práva ICT, obchodního práva a řeení sporů. Mezi jeho klienty patří globální korporace působící v IT a e-commerce, finanční instituce a společnosti z komunikačního, mediálního a obranného průmyslu. |

Formulář pro přidání akce


















