Dedykowane oprogramowanie na zamówienie - od specyfikacji do praw do kodu

Dedykowane oprogramowanie na zamówienie - co powstaje w projekcie

Zamawiający dedykowanego oprogramowania nie kupuje kopii programu, tylko wytworzenie systemu według własnych wymagań, zwykle od firmy typu software house. Powstają kod i schemat bazy danych, a obok nich dokumentacja oraz zestaw uzgodnień, które rozstrzygają, komu ten kod służy po odbiorze. Spory w projektach na zamówienie rzadko dotyczą samego programowania. Częściej dotyczą tego, co dokładnie zamówiono i co wolno zrobić z wynikiem pracy.

Ten artykuł porządkuje trzy elementy, które decydują o bezpieczeństwie takiego zamówienia. Pierwszy to analiza wymagań wraz ze specyfikacją, drugi to zapisy o prawach autorskich, trzeci to zasady przekazania kodu źródłowego. Wybór wykonawcy opisuje osobno tekst o kryteriach oceny dostawcy oprogramowania na zamówienie, a porównanie z gotowym systemem - tekst o oprogramowaniu dedykowanym i rozwiązaniach masowych. Ogólny przegląd tematu znajduje się na stronie oprogramowanie na zamówienie.

Artefakty projektu i ich właściciele

Każdy etap zostawia po sobie dokument albo plik. Tabela pokazuje, co powinno trafić do zamawiającego i po co.

Zamawiający, który odbiera tylko działający program, ma system, ale nie ma niczego, co pozwoliłoby go rozwijać poza pierwotnym wykonawcą. Dlatego pozostałe wiersze tabeli trzeba wpisać do umowy jako obowiązek przekazania, a nie liczyć na dobrą wolę po zakończeniu prac.

Analiza wymagań przed specyfikacją

Analiza wymagań, opisana szerzej w artykule o analizie przedwdrożeniowej, zaczyna się od opisu procesu tak, jak przebiega dzisiaj, z arkuszami kalkulacyjnymi i ręcznym przepisywaniem danych. Analityk rozmawia z osobami, które wykonują pracę, a nie tylko z osobą podpisującą zamówienie. Kierownik opisuje proces idealny, operator opisuje proces rzeczywisty, a system musi obsłużyć ten drugi.

Rodzaje wymagań

Wymagania dzielą się na cztery grupy, które trafiają do osobnych rozdziałów specyfikacji.

• Wymagania funkcjonalne - co system ma robić, na przykład rejestrować zamówienie i blokować zapis poniżej minimalnej ilości.
• Wymagania niefunkcjonalne - jak system ma działać, czyli czas odpowiedzi, liczba równoległych użytkowników i dostępność.
• Ograniczenia - warunki narzucone z zewnątrz, na przykład wersja SQL Server, wymagana przeglądarka lub polityka bezpieczeństwa.
• Integracje - systemy, z którymi wymiana danych jest obowiązkowa, wraz z kierunkiem i częstotliwością wymiany.

Pominięcie drugiej grupy jest najczęstszym błędem. Wymaganie typu „system ma być szybki” nie da się odebrać, dopóki nie zapisze się go jako liczby: czas odpowiedzi listy zamówień przy określonej liczbie rekordów i użytkowników.

Reguła: wymaganie bez kryterium akceptacji nie trafia do specyfikacji, bo nie da się stwierdzić, czy zostało spełnione.

Specyfikacja funkcjonalna i kryteria akceptacji

Specyfikacja funkcjonalna zamienia notatki z analizy w dokument, który obie strony podpisują, a etapy całego procesu opisuje tekst o dedykowanych aplikacjach dla firm na zamówienie. Opisuje aktorów systemu i przypadki użycia. Określa też statusy dokumentów oraz uprawnienia użytkowników. Dobra specyfikacja jest konkretna: programista i tester rozumieją ten sam zapis bez pytań. Jest też na tyle krótka, że zamawiający faktycznie ją przeczyta przed podpisem.

Kryterium akceptacji jako test

Najbezpieczniej formułować kryterium tak, aby dało się je zamienić w test automatyczny. Poniższy fragment jest przykładowy i pokazuje regułę „zamówienie poniżej minimum jest odrzucane” zapisaną w C#.

[Fact]
public void Zamowienie_ponizej_minimum_jest_odrzucone()
{
    var zamowienie = new Zamowienie(klientId: 17, wartosc: 80m);
    var wynik = new WalidatorZamowien(minimum: 100m).Sprawdz(zamowienie);

    Assert.False(wynik.Poprawne);
    Assert.Equal("MIN_WARTOSC", wynik.Kod);
}

Taki zapis nie zastępuje testów akceptacyjnych wykonywanych przez użytkowników, ale usuwa spór o interpretację. Zamawiający widzi, że reguła jest sprawdzana przy każdej zmianie kodu, a nie tylko raz przy odbiorze.

Zmiany zakresu w trakcie projektu

Specyfikacja nie zamraża projektu, tylko wyznacza punkt odniesienia dla zmian. Każda zmiana przechodzi tę samą ścieżkę: opis, ocena wpływu, decyzja zamawiającego. Przy iteracyjnym prowadzeniu prac ta ścieżka może być lżejsza, co opisuje tekst o zwinnym zarządzaniu projektami IT na zamówienie.

Prawa autorskie do oprogramowania na zamówienie

Program komputerowy jest utworem, a prawa autorskie powstają po stronie twórcy, czyli wykonawcy lub zatrudnionych przez niego programistów. Zapłata za projekt nie przenosi ich na zamawiającego automatycznie. Bez odpowiednich zapisów zamawiający ma system, ale wykonawca nadal decyduje o kopiowaniu programu i jego zmianach. Ten fragment opisuje mechanizm z perspektywy inżynierskiej i nie zastępuje porady prawnika, który zna aktualne brzmienie ustawy o prawie autorskim i prawach pokrewnych.

Przeniesienie praw czy licencja

Umowa może przenieść autorskie prawa majątkowe albo udzielić licencji. W obu przypadkach trzeba wymienić pola eksploatacji, czyli sposoby korzystania z programu, które zamawiający ma otrzymać. Ogólne sformułowanie „wszelkie prawa” bywa źródłem sporów, dlatego lista powinna nazywać konkretne czynności.

Kod wspólny dla wielu projektów wykonawcy, na przykład własne biblioteki, zwykle pozostaje jego własnością i trafia do zamawiającego na licencji. Zamawiający powinien znać granicę: które moduły powstały specjalnie dla niego, a które są wykonawcy i tylko w projekcie użyte.

Reguła: w umowie wskazuje się moment przejścia praw oraz pola eksploatacji, a prawa osobiste twórcy pozostają poza obrotem.

Kod źródłowy w umowie - przekazanie i depozyt

Prawa do kodu nie mają wartości bez samego kodu. Umowa powinna określać, w jakiej formie i kiedy wykonawca przekazuje kod źródłowy: po każdym etapie, po odbiorze końcowym czy dopiero na żądanie. Najprostszy wariant to repozytorium Git, do którego zamawiający ma dostęp do odczytu przez cały czas trwania projektu. Historia zmian pokazuje wtedy, kto i kiedy wprowadził każdą poprawkę.

Zawartość paczki z kodem źródłowym

Sam katalog z plikami C# nie wystarcza. Aby inny programista mógł zbudować i uruchomić system, potrzebuje kompletu artefaktów.

Najlepszym testem kompletności jest odbiór próbny: osoba spoza zespołu wykonawcy klonuje repozytorium na czystej maszynie i buduje wersję jednym poleceniem, na przykład dotnet build -c Release. Jeśli to się nie udaje, kod źródłowy nie jest jeszcze przekazany w sensie praktycznym, choćby pliki formalnie leżały w archiwum.

Depozyt kodu u strony trzeciej

Gdy wykonawca zachowuje prawa do kodu i udziela tylko licencji, zamawiający może wynegocjować depozyt kodu źródłowego. Kod składa się u niezależnej strony, a umowa wskazuje zdarzenia uprawniające do jego wydania, na przykład ustanie działalności wykonawcy albo zaprzestanie serwisu. Depozyt ma sens tylko wtedy, gdy przy każdym wydaniu wersji składa się także aktualną kopię, a nie wyłącznie pierwszą.

Komponenty zewnętrzne i licencje open source

Większość aplikacji zawiera biblioteki napisane przez osoby trzecie. Każda z nich ma własną licencję, która wpływa na to, co wolno zrobić z gotowym produktem. Licencje permisywne, takie jak MIT czy Apache 2.0, pozwalają na użycie w oprogramowaniu komercyjnym przy zachowaniu informacji o autorze. Licencje typu copyleft, na przykład GPL, mogą wymagać udostępnienia kodu własnego, jeśli komponent zostanie z nim połączony w określony sposób. Przegląd popularnych licencji prowadzi organizacja Open Source Initiative.

W praktyce wystarczy prosty załącznik do umowy: lista użytych komponentów z nazwą i wersją komponentu oraz typem licencji. Wykonawca zobowiązuje się nie używać komponentów, których licencja koliduje z przeniesieniem praw lub z modelem korzystania przez zamawiającego. Osobną kategorią są licencje na produkty platformowe, takie jak SQL Server czy system operacyjny. Nie należą do wykonawcy i zwykle kupuje je zamawiający, o czym umowa powinna wprost informować.

Uzgodnienia z zespołem programistów

Prawa autorskie powstają po stronie osób piszących kod. Jeśli wykonawca korzysta z podwykonawców lub programistów na umowach cywilnoprawnych, powinien mieć od nich przeniesienie praw, zanim przeniesie je dalej. Zamawiający może poprosić o oświadczenie, że wykonawca dysponuje prawami do całości przekazywanego kodu.

Dane i dostępy przy przekazaniu systemu

Kod jest tylko jedną częścią przekazania. Drugą są dane i dostępy, bo bez nich zamawiający nie uruchomi systemu samodzielnie. Dane biznesowe zgromadzone w bazie należą do zamawiającego niezależnie od tego, kto napisał program, i umowa powinna to stwierdzać wprost. Powinna też przewidywać eksport w formacie otwartym, na przykład pliku CSV albo kopii bazy SQL Server, wraz z opisem tabel.

Osobną sprawą są konta i sekrety, czyli hasła administracyjne serwera oraz klucze API integracji, a także certyfikaty i ciągi połączeń do bazy. W projektach na zamówienie zdarza się, że konto administracyjne środowiska produkcyjnego zostaje założone na osobę z zespołu wykonawcy. Po zakończeniu współpracy zamawiający traci wtedy kontrolę nad własnym systemem. Bezpieczniejszy układ zakłada konta założone na zamawiającego od początku, a uprawnienia wykonawcy nadawane na czas prac i cofane po ich zakończeniu.

Lista przekazania dostępów

• Konta administracyjne - założone na zamawiającego, z dostępem wykonawcy nadanym czasowo.
• Sekrety aplikacji - klucze API oraz certyfikaty zapisane w magazynie ustalonym z zamawiającym, a nie w kodzie.
• Środowiska - opis środowiska testowego i produkcyjnego wraz z adresami i wersjami platformy.
• Kopie zapasowe - harmonogram oraz miejsce przechowywania, a także sprawdzony sposób odtworzenia bazy.

Lista wygląda na organizacyjną, ale w praktyce rozstrzyga, czy zamówiony system da się utrzymać po zmianie wykonawcy. Odbiór końcowy powinien obejmować próbne odtworzenie bazy z kopii na osobnym serwerze.

Odbiór końcowy i rozwój po wdrożeniu

Odbiór końcowy potwierdza, że wszystkie kryteria akceptacji ze specyfikacji zostały spełnione, a paczka z kodem jest kompletna. Protokół odbioru zawiera listę uwag z terminami poprawek. Od tej daty zwykle liczy się okres gwarancji na błędy, więc data odbioru ma znaczenie także finansowe.

Po wdrożeniu system wymaga opieki. Obejmuje ona aktualizacje oraz kopie zapasowe, a także reakcję na zgłoszenia użytkowników. Zakres tej opieki i podział obowiązków między zamawiającego a wykonawcę opisuje tekst o oprogramowaniu na zamówienie a obsłudze IT. Zamawiający, który ma prawa do kodu, może powierzyć rozwój innemu podmiotowi, a wykonawca, który chce zachować klienta, konkuruje jakością usługi, a nie zamknięciem kodu.

Integracje z innymi systemami, na przykład z ERP, to zwykle najtrudniejsza część zmian po wdrożeniu, bo dotyczą kontraktu z drugą stroną. Mechanizmy wymiany danych opisuje artykuł o integracji WMS z ERP przez REST i kolejki. Raporty i wydruki tworzone jako pliki RDL zamawiający również powinien otrzymać jako pliki źródłowe, co omawia strona o SQL Report Builder. Zakres prac programistycznych po stronie SoftwareStudio opisuje oferta oprogramowania na zamówienie, a rozmowę o wycenie można rozpocząć pod numerem +48 533 322 626.