Warunki licencji powinny uwzględniać nasze potrzeby również w przyszłości. Źle określona licencja może być powodem dużych kosztów w przyszłości, gdy np. dostawca nie zgodzi się na rozpowszechnienie programu w innej siedzibie firmy, nawet jeśli nie przekroczymy ustalonej liczby użytkowników.

Nic nie trwa wiecznie

W licencji należy również określić warunki zakończenia korzystania z programu. Nie można dopuścić ograniczeń do korzystania z danych zapisanych przez program, którego już nie używamy. Często może to wymagać dostępu konkurencyjnego dostawcy do sekretów handlowych (firmowe struktury danych lub formaty plików) producenta pierwotnego produktu. Sprawa wcale nie jest łatwa do rozwiązania.

Modyfikacje

Dzisiaj program jest na szczycie osiągnięć techniki informatycznej, jutro to starocie nie nadające się do użytku. Nie należy zamawiać programu, nie zastanowiwszy się uprzednio, jaki będzie jego rozwój: poprawianie błędów, modyfikacje i uaktualnienia. Należy to ustalić już teraz, nie zaś zastanawiać się, co z tym zrobić za rok, gdy pojawią się problemy.

Trzeba znać odpowiedzi na następujące pytania: Czy dostawca programu opracowuje specjalnie dla nas? Czy sprzedaje ten sam lub podobny program innym? Czy określił politykę rozwoju produktu?

Jeżeli program jest opracowany wyłącznie na nasze zamówienie, należy liczyć się z koniecznością finansowania dalszego rozwoju, ale warto zastrzec, że dostawca nie zostawi nas samych w trudnej sytuacji, bo woli zajmować się czym innym.

Jeżeli program jest sprzedawany szerzej, niech producent zapewnia jego rozwój. Trzeba jednak upewnić się, czy kolejne modyfikacje trafią do nas za darmo lub po najkorzystniejszej cenie (nie wyższej niż dla najbardziej uprzywilejowanego klienta).

W umowie warto również określić postępowanie z modyfikacjami dokonywanymi lokalnie. Na ile mamy prawo je czynić, czy musimy je udostępniać producentowi, kto ma do nich prawo (wyłączne, niewyłączne, jakim kosztem), czy możemy je rozpowszechniać szerzej i na jakich warunkach, czy producent jest zobowiązany wprowadzać je w kolejnych wersjach programu itp.

Ważny problem dotyczy zgodności kolejnych wersji programu. Jeżeli okaże się, że nasze modyfikacje nie działają w kolejnej wersji programu (która jest nam potrzebna z innych względów), trzeba liczyć się z kosztami wnoszenia tych modyfikacji do nowej wersji. Jeśli nie zamierzamy używać nowej wersji, to jak długo dostawca gotów jest wspierać dawną wersję programu, do której wprowadziliśmy nasze modyfikacje? Nie należy zgadzać się na wsparcie tylko ostatniej wersji program, gdyż wiąże nas to z dostawcą w bardzo niekorzystny sposób: musimy kupować kolejne wersje lub zaprzestać korzystania z pomocy technicznej.

Co program ma robić

To jest chyba najtrudniejsza część kontraktu projektu wykonywanego na zamówienie. Nikt przy zdrowych zmysłach nie zgodzi się na budowę domu dla rodziny, nie widząc projektu. Tymczasem w działalności informatycznej jest to praktyka codzienna.

W możliwie precyzyjnym opisie funkcji programu trzeba zawrzeć wiele właściwości, o których zarówno zamawiający, jak i wykonawca mają małe rozeznanie.

Jedna z metod radzenia sobie z problemem polega na zapisaniu ogólnych warunków do rozwiązania i zachęceniu kilku dostawców oprogramowania do złożenia oferty technicznej. Nikt nie lubi, gdy usiłuje się wykorzystać jego wiedzę, ale ta metoda pozwoli na dokładniejsze określenie warunków i lepszą pozycję przetargową w dalszych negocjacjach.

Trudności pojawią się również przy próbie zapisania wymagań: użytkownik woli zapisywać co program ma robić, dostawca zaś - odwoływać się do opublikowanej specyfikacji produktu. Warto również określić kilka wymagań, od których użytkownik nie odstąpi pod żadnym pozorem, i wprowadzić je explicite do umowy.

Wydajność

Największe kłopoty w dobrym zapisaniu kontraktu pojawiają się w chwili, gdy próbujemy porównać miary ilościowe do właściwości jakościowych. Problemy z oprogramowaniem rzadko są proste: nie działający program występuje równie rzadko, jak nie dający się włączyć komputer.

Klienci mają na ogół problemy znacznie trudniejsze do określenia ilościowego. "Program działa zbyt wolno, za często trzeba restartować komputer, niszczy bazę danych, nie działa zgodnie z moimi oczekiwaniami itp."

Z takimi problemami częściowo można sobie poradzić, precyzując warunki wstępnego testowania produktu przez użytkownika, podania, co można zmieniać i w jakim zakresie, na ile można wymagać zmiany kontraktowych wymagań użytkowych i ile to będzie trwało i kosztowało. Dostawca często zasłania się tezą: "Program działa zgodnie z wymaganiami zawartymi w kontrakcie". I to jest prawda, tyle że nie w sposób antycypowany przez użytkownika.

Nie ma prostych rozwiązań problemu. Natomiast jeśli w kontrakcie nie sprecyzuje się dokładnego scenariusza wstępnego testowania produktu i warunków akceptacji, nie należy spodziewać się, że dostawca dobrowolnie zechce zmieniać problem z uwagi na widzimisię użytkowników.

Trudne jest testowanie czasu odpowiedzi programu. Nie zawsze wystarczy określenie czasu trwania przejścia do następnego ekranu po zaakceptowaniu poprzedniego. Często bowiem testy prowadzi się na nierealistycznej bazie danych, przejście zaś na warunki realne zmienia warunki działania i czas odpowiedzi.

Jeżeli program nie spełnia jednego lub więcej warunków zawartych w kontrakcie, nie wystarczy zawrzeć w nim zastrzeżenia, że dostawca ma program poprawić. Trzeba dokładnie sprecyzować, w jakim terminie, określić sposób podawania informacji o postępie prac w tym zakresie oraz powiedzieć co zrobić, jeśli dostawcy nie uda się poprawić programu.

Gwarancje

Po zaakceptowaniu oprogramowania, okaże się, że pojawiły się błędy nie wykryte w procesie testowania. Mogą to być błędy poważne, wymagające natychmiastowej reakcji dostawcy i ewentualnej pracy jego programistów bez przerwy, aż do usunięcia usterki, lub niedociągnięcia i błędy drobne (zamiast spcyfikowanej odpowiedzi w ciągu 1 s, program odpowiada w 1,5 s), nie wymagające natychmiastowego angażowania poważnych sił i środków. Ale też nie powinno się ich lekceważyć.

Wszystkie te problemy powinny być rozważone w ramach gwarancji programu i usuwane zgodnie z wcześniej ustalonymi procedurami w sposób dostosowany do powagi sytuacji.

Gwarancja powinna również obejmować błędy, które mogą ujawnić się w najmniej spodziewanych momentach: bilans roczny nie da się policzyć lub liczy się źle, program nie radzi sobie z rokiem 2000 i inne. Te sytuacje nigdy nie zostały przetestowane, termin gwarancji już minął, co robić?

Nie można gwarancji przedłużać w nieskończoność, natomiast można stawiać rozsądne wymagania dotyczące takich przypadków w kontrakcie na obsługę posprzedażną i konserwację oprogramowania.

Kod źródłowy

Dyskusje na temat kodu źródłowego zawsze powodują spore trudności. Jak ważny jest dostęp do kodu źródłowego, najlepiej widać na przykładzie problemów z rokiem 2000. Te firmy, które mają kod źródłowy swoich programów, mają szansę przynajmniej określić zagrożenia i ewentualnie je usunąć. Inne są skazane na zakup nowego oprogramowania.

Kod źródłowy pozwala na modyfikację oprogramowania do zmieniających się warunków działalności, pomaga nam również w razie zmiany profilu działalności dostawcy lub bankructwa. Niestety, na ogół dostawca uważa kod źródłowy za tajemnicę handlową i nie godzi się na dostarczenie go w żadnej postaci.

W Polsce mieliśmy już przykłady procesów sądowych o niezgodne z umową wykorzystanie kodu źródłowego do stworzenia konkurencyjnego produktu, nic więc dziwnego, że każda firma stara się chronić kod źródłowy programów.

W takim przypadku jedynym rozwiązaniem jest zdeponowanie kodu źródłowego u niezależnej firmy (notariusz?), która zapewni przechowywanie kodu do czasu wygaśnięcia umowy, a udostępni go nabywcy programu we wcześniej sprecyzowanych okolicznościach.

Płatności

Interesy dostawcy i nabywcy oprogramowania są sprzeczne. Dostawca chciałby otrzymać jak największą część umówionej kwoty możliwie wcześnie, nabywca uważa odroczone płatności za dobry sposób wpływu na dostawcę w celu zmuszenia go do szybszej pracy lub poprawienia błędów. Tylko rozsądny kompromis może zapewnić harmonijną współpracę dostawcy i nabywcy.