+48 71 346 70 70 wroclaw@bramorski.pl

Blog

Umowy w branży IT. Postanowienia o charakterze technicznym

23 maj 2015
Maciej Szermach
Blog, Umowy

Umowy w branży IT. Postanowienia o charakterze technicznym

Umowy dotyczące oprogramowania dotyczą obszaru o niezwykle wysokim stopniu specjalizacji; bardzo istotną częścią takiego dokumentu będą więc zapisy o charakterze technicznym, dotyczące nie tylko sporządzenia przez przyjmującego zamówienie dokumentacji technicznej i instrukcji obsługi oprogramowania, lecz także języka programowania, serwera czy udostępnienia kodów źródłowych. Będą to więc takie kwestie, jak np. jaka wersja danego języka będzie zastosowana, jakie ma być docelowe środowisko uruchomieniowe (systemy operacyjne, obsługiwane wersje przeglądarek, potrzebne biblioteki itp.), w jakiej formie mają zostać udostępnione kody źródłowe, czy kod ma być komentowany, czy udostępnione będą także biblioteki nabyte przez wykonawcę od podmiotów trzecich (np. zdjęcia, kontrolki), jak wygląda kwestia aktualizacji danego oprogramowania.

Dodatkowo, warto w umowie wskazać, jakie będą możliwości edycji kodu przez zamawiającego, tzn. czy kod będzie otwarty w pełni czy nie. Gdy zamawiający nie będzie mieć pełnego dostępu do kodu, powstanie prawdopodobnie w pewnym momencie konieczność zwracania się z kolejnymi zleceniami, modyfikującymi pierwotne oprogramowanie, do wykonawcy, czyli w pewnym sensie uzależnienia się od niego, co jest nie tylko niewygodne, ale także podnosi koszty całego wdrożenia. Przy umownych zapisach o kodzie warto także zwrócić uwagę na to, aby wykonawca dołączył do oprogramowania dokumentację techniczną kodu; zamawiający, dla wygody późniejszej pracy z programem, powinien zadbać o to, aby dostarczony mu kod był skomentowany według przyjętych branżowych standardów, np. dla aplikacji w Java przy zastosowaniu Javadoc.

Strony powinny także pamiętać o uregulowaniu kwestii obsługi posprzedażowej („pielęgnacja oprogramowania”) – na jakich zasadach ma się ona odbywać, m.in. za jakim wynagrodzeniem, przez jak długi okres czasu, jaki ma być czas reakcji. Aby uniknąć wątpliwości, w umowie warto wskazać, jakie zgłoszenia podlegać będą pod gwarancję, a jakie powinny być komunikowane właśnie w ramach software maintenance. Za zgłoszenia uznane jako błąd (umowa powinna także zdefiniować, co jest błędem), np. uniemożliwiające wykonanie kluczowych przypadków użycia (tzw. błędy krytyczne) zamawiający nie powinien być obciążany dodatkowymi kosztami, zaś takie czynności, jak np. monitoring czy uruchamianie dodatkowych funkcji mogą już stanowić przedmiot umowy maintenance’owej.

W niniejszym artykule nie sposób wymienić wszystkich obligatoryjnych i fakultatywnych postanowień umowy na oprogramowanie. Wskazano więc jedynie na najważniejsze z nich. W takiej umowie strony powinny także określić m.in. metodykę wytwarzania oprogramowania, harmonogram dostarczania oprogramowania, kryteria akceptacji dla poszczególnych faz produktów, stanowiących wykonanie dzieła, zasady testowania oprogramowania i przyjęte rozwiązania testowe (np. dla testów jednostkowych może to być JUnit dla aplikacji Java), a także zagadnienia związane z kontrolą wersji i kontrolą zmian, szczegółowe kwestie dotyczące budżetu projektu.

Na zakończenie, tytułem podsumowania, warto natomiast raz jeszcze podkreślić korzyści związane ze stosowaniem pisemnych umów w branży IT w ramach negocjacji dotyczących np. omawianego w tej pracy oprogramowania.

Chodzi tu nie tyle o niedopuszczalność ustaleń ustnych czy nieważność uzgodnień wynikających z korespondencji e-mailowej (choć już np. umowa przenosząca prawa autorskie musi być zawarta w formie pisemnej pod rygorem nieważności), co o znaczną przewagę takich pisemnych umów przy kwestiach dowodowych, a dzięki temu – także ułatwienie w rozwiązywaniu ewentualnych sporów. Aby tak się jednak stało, umowa na oprogramowanie powinna być stosunkowo obszerna i szczegółowa – tak, by zmniejszyć ryzyko ewentualnych niejasności interpretacyjnych w przyszłości.

W celu zapewnienia większej przejrzystości warto zastanowić się nad umieszczeniem stricte technicznych zapisów w załącznikach. Znajdą się tu przykładowo: specyfikacja techniczna oprogramowania ze zdefiniowaniem jego docelowej funkcjonalności, zasady zarządzania ryzykiem, szczegółowe kwestie związane z zasadami budżetowania oraz miarami jakości (np. wzory jakości), szczegółowe zdefiniowanie przebiegu i efektów faz projektowych, analiza przedwdrożeniowa.

Niezwykle ważne jest wreszcie, aby całość procesu negocjacyjnego dotyczącego danej umowy odbywała się przy udziale prawnika. Zawiłość przepisów prawnych może być bowiem dla stron tak możliwością, jak i zagrożeniem. Celem takiej weryfikacji umowy przez profesjonalistę jest zatem zapewnienie stronom maksimum prawnego bezpieczeństwa.

poprzednie wpisy z serii Umowy w branży IT:

Autorem artykułu jest Aleksandra Surowiecka, aplikant radcowski

Menu