Producent oprogramowania na zamówienie - kod i licencja dla klienta

W projekcie na zamówienie klient płaci za dwie rzeczy jednocześnie: za program i za prawo do jego używania oraz zmiany. Pierwsza wynika z wyceny, druga z umowy, i to druga bywa źródłem sporów po latach. Producent oprogramowania na zamówienie i klient powinni więc opisać nie tylko funkcje, lecz także to, co klient otrzyma do ręki.

Strona omawia relację producent-klient od strony technicznej. Zaczyna od zakresu dostawy, przechodzi do kodu i licencji komponentów, a kończy na wydaniach i dokumentacji. Nie jest poradą prawną. Zapisy o prawach do programu potwierdza prawnik, a tutaj znajduje się lista pytań, które warto mu przynieść.

Producent oprogramowania na zamówienie i zakres dostawy

Pojęcie „dostarczone oprogramowanie” obejmuje kilka odrębnych rzeczy, a każda z nich ma inne skutki dla klienta. Program w wersji skompilowanej pozwala pracować, ale nie pozwala niczego zmienić. Kod źródłowy pozwala rozwijać aplikację, ale wymaga środowiska i wiedzy, by go zbudować.

Ta tabela jest szkieletem rozmowy z wykonawcą jeszcze przed wyceną. Odpowiedzi zmieniają koszt: przygotowanie dokumentacji do przekazania i uporządkowanie repozytorium to praca, którą trzeba w ofercie zobaczyć. Kryteria porównywania ofert opisuje artykuł o dostawcy oprogramowania na zamówienie.

Prawa do kodu i licencja - pytania techniczne

W wielu projektach prawa do kodu zostają przy producencie, a klient otrzymuje licencję. W innych przechodzą na klienta razem z kodem. Który wariant obowiązuje, wynika wyłącznie z umowy, a każdy z nich ma inne konsekwencje techniczne.

Ten sam podział omawia strona o licencji i gwarancji producenta programów, gdzie licencja jest opisana jako prawo do korzystania, a nie własność kodu. Warunki takie jak dostęp do nowych wydań i zasady przenoszenia licencji na inną firmę wpływają na koszty w kolejnych latach.

Reguła: zakres praw do kodu ustala się przed pierwszą fakturą, a nie przy rozstaniu z wykonawcą. Zapis potwierdza prawnik, a strona techniczna dostarcza mu listę artefaktów, których zapis dotyczy.

Kiedy klient potrzebuje kodu

Nie każdy klient musi otrzymać kod źródłowy, a nie każdy powinien się go wyrzekać. Jeśli aplikacja obsługuje proces, bez którego firma staje, dostęp do kodu jest formą ubezpieczenia: gdy producent zniknie z rynku albo przestanie odpowiadać, dalszy rozwój da się zlecić komuś innemu. Jeśli aplikacja jest narzędziem pomocniczym i łatwo ją zastąpić, licencja z aktualizacjami zwykle wystarcza. Odpowiedź zależy od tego, ile kosztowałby przestój i ile zmiana dostawcy, a nie od zasady ogólnej.

Komponenty osób trzecich i ich licencje

Oprogramowanie na zamówienie składa się w dużej części z cudzych komponentów: bibliotek NuGet po stronie serwera i bibliotek JavaScript w przeglądarce. Każda ma własną licencję, a producent nie może przekazać klientowi więcej praw, niż sam ma do tych komponentów.

Wykaz komponentów jest więc częścią dostawy. W projekcie na platformie .NET wygenerowanie go zajmuje jedno polecenie, które wypisuje pakiety bezpośrednie i tranzytywne, czyli zaciągane przez inne pakiety.

dotnet list package --include-transitive

Do wykazu dołącza się identyfikator licencji każdego komponentu. Powszechnym sposobem zapisu są identyfikatory z listy SPDX, dostępnej na stronie SPDX License List, na przykład MIT albo Apache-2.0. Niektóre licencje nakładają obowiązki przy dystrybucji programu, więc wykaz jest potrzebny, gdy klient chce udostępniać aplikację poza własną organizacją. Interpretację licencji pozostawia się prawnikowi.

Wydania w relacji producent-klient

Wydaniem nazywa się wersję programu z numerem i opisem zmian, przekazaną klientowi do użycia. Numeracja ułatwia rozmowę: zgłoszenie dotyczy wersji 2.4.1, a nie „tej sprzed miesiąca”. Powszechnie stosowany schemat, opisany w specyfikacji wersjonowania semantycznego, dzieli numer na trzy liczby oddzielone kropkami.

Numer wersji zapisuje się w jednym miejscu, z którego korzysta budowanie aplikacji. W projekcie .NET jest to zwykle plik projektu, a numer trafia do plików wykonywalnych i do stopki programu.

<PropertyGroup>
  <Version>2.4.1</Version>
</PropertyGroup>

Każdemu wydaniu towarzyszy notatka: lista usterek usuniętych i funkcji dodanych, uwagi o migracji bazy oraz informacja o sposobie wycofania. Szczegółowo różnice między wersją a wydaniem opisuje artykuł o wersjach i wydaniach producenta oprogramowania. Proces wytwórczy, z którego takie wydania wychodzą, przedstawia tekst o tworzeniu aplikacji biznesowych z testami i wersjami.

Notatka do wydania

Notatka do wydania pełni funkcję kwitu: klient widzi, co zmieniono, i wie, czego się spodziewać po aktualizacji. Poniżej przykład w formie zwykłego tekstu, z wymyślonymi pozycjami.

Wydanie 2.5.0
Nowe:      filtr statusu na liście dokumentów
Poprawione: zwolnienie rezerwacji po edycji zamówienia
Baza:      dodano indeks na dbo.Dokument(DataUtworzenia)
Migracja:  skrypt 2.5.0.sql, czas wykonania zależny od rozmiaru tabeli
Wycofanie: przywrócenie kopii bazy i pakietu 2.4.1

Klient odczytuje z niej trzy rzeczy naraz: co zyskuje, jakie ryzyko bierze na siebie i jak się cofnąć. Bez pola „Wycofanie” notatka jest reklamą, a nie dokumentem technicznym.

Wydanie wymaga jeszcze decyzji, kto je instaluje i kiedy. Producent może wdrażać je w oknie serwisowym uzgodnionym z klientem albo przekazywać pakiet, który klient uruchamia samodzielnie według instrukcji. Pierwszy wariant ogranicza liczbę pomyłek, drugi daje klientowi kontrolę nad terminem. Niezależnie od wyboru instalacja poprawek na środowisku testowym poprzedza wdrożenie na produkcji, a różnicę między środowiskami zapisuje się w notatce.

Dokumentacja przekazywana klientowi

Dokumentacja jest dostawą tak samo jak kod i ma własne kryterium odbioru: kompetentna osoba spoza zespołu producenta potrafi na jej podstawie uruchomić aplikację i zdiagnozować typową usterkę. Dokument, którego nikt poza autorem nie umie użyć, kryterium nie spełnia.

• Opis architektury - warstwy aplikacji, sposób komunikacji z bazą i z innymi systemami.
• Instrukcja instalacji - wymagania środowiska, kolejność uruchamiania usług i parametry konfiguracji.
• Opis bazy danych - tabele i kolumny wraz z relacjami oraz procedury składowane z opisem ich przeznaczenia.
• Instrukcja obsługi błędów - typowe komunikaty, miejsce ich wpisów w dzienniku i pierwsze działania diagnostyczne.

Opis bazy nie musi powstawać ręcznie od zera. Widoki systemowe SQL Server pozwalają wygenerować szkielet dokumentu, który producent uzupełnia opisem znaczenia pól. Kolumny opisuje widok INFORMATION_SCHEMA.COLUMNS, a zapytanie poniżej wypisuje z niego tabele z typami danych.

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'dbo'
ORDER BY TABLE_NAME, ORDINAL_POSITION;

Przekazanie repozytorium i dostępów

Przekazanie repozytorium jest zdarzeniem, które warto zaplanować jak wdrożenie. Producent przygotowuje kompletną kopię, klient sprawdza ją na własnym komputerze, a dopiero potem strony podpisują protokół. Kompletność sprawdza się bez zaufania do deklaracji: kopia ma się otworzyć, wersje wydań mają być w niej widoczne, a aplikacja ma się zbudować na czystym środowisku.

Format paczki nie ma znaczenia, o ile zawiera całą historię. Polecenia poniżej tworzą pojedynczy plik ze wszystkimi gałęziami i znacznikami, a następnie sprawdzają jego spójność. Klient może go przechować w archiwum, nawet bez dostępu do serwera producenta.

git bundle create projekt.bundle --all
git bundle verify projekt.bundle

Osobną listę stanowią dostępy. Konta administracyjne, na przykład serwera lub domeny, rejestruje się na klienta, a nie na pracownika producenta, bo po jego odejściu firma traci kontrolę nad zasobami. Hasła i klucze przekazuje się innym kanałem niż dokumentację, a producent po przekazaniu zmienia te, którymi sam się posługiwał. Sposób pracy wykonawcy z gałęziami i przeglądem kodu opisano w artykule o firmie programistycznej od strony warsztatu, a wdrożenie i odbiór po migracji danych w tekście o wdrożeniu oprogramowania.

Dane klienta i kopie bazy

Kod jest własnością umowną, a dane biznesowe w bazie należą do klienta niezależnie od modelu licencji. Przy zakończeniu współpracy klient powinien móc je odzyskać w formie, którą da się odczytać bez narzędzi producenta. Przekazanie samego pliku kopii ma sens tylko wtedy, gdy wiadomo, na jakiej wersji SQL Server go odtworzyć.

Kopię bazy wykonuje polecenie BACKUP DATABASE, opisane w dokumentacji Microsoft. Plik kopii przekazuje się razem z informacją o wersji serwera i o sortowaniu bazy, bo od nich zależy, gdzie da się go odtworzyć.

BACKUP DATABASE Aplikacja
TO DISK = N'D:\kopie\Aplikacja_przekazanie.bak'
WITH COMPRESSION, CHECKSUM, INIT;

RESTORE VERIFYONLY
FROM DISK = N'D:\kopie\Aplikacja_przekazanie.bak'
WITH CHECKSUM;

Druga instrukcja sprawdza czytelność pliku, ale nie zastępuje próbnego odtworzenia. Prawdziwym testem jest przywrócenie kopii na czystym serwerze klienta i uruchomienie na niej aplikacji. Okresy przechowywania danych po zakończeniu współpracy oraz ich usunięcie z systemów producenta zapisuje się w umowie i omawia z prawnikiem.

Zakończenie współpracy i przekazanie wiedzy

Klient, który zamierza zmienić wykonawcę, potrzebuje więcej niż plików. Nowy zespół musi zrozumieć decyzje projektowe, które nie mieszczą się w kodzie, więc plan wyjścia obejmuje okres przejściowy, w którym dotychczasowy producent odpowiada na pytania i uczestniczy w warsztatach.

• Warsztaty architektury - omówienie architektury z zaznaczeniem miejsc, które generują większość zgłoszeń.
• Przegląd backlogu - lista zmian zaplanowanych oraz wykonanych częściowo, z uzasadnieniem odrzuceń.
• Odtworzenie środowiska - nowy zespół uruchamia aplikację i bazę według dokumentacji, zgłaszając luki.
• Okres wsparcia po zmianie - uzgodniony czas, w którym poprzedni producent odpowiada na pytania techniczne.

Plan wyjścia jest dokumentem o charakterze ubezpieczeniowym: rzadko z niego korzystają obie strony, ale jego brak kosztuje najwięcej wtedy, gdy relacja się kończy. Kryteria oceny wykonawcy, wśród nich referencje z zakończonych współprac, przedstawia artykuł o dostawcy oprogramowania na zamówienie.

Relacja po odbiorze i wsparcie

Po odbiorze producent i klient wchodzą w drugą fazę relacji. Gwarancja obejmuje usterki wykonanej pracy przez czas określony w umowie, umowa serwisowa reguluje dłuższe wsparcie, a rozwój aplikacji wycenia się osobno. Rozdzielenie tych zakresów zapobiega sporom o to, kto płaci za poprawkę.

Klient, który otrzymał kod, ma wybór: kontynuować z producentem albo zlecić prace komuś innemu. Ten drugi scenariusz działa tylko wtedy, gdy dostawa była kompletna, o czym mówi poprzednia sekcja. Zakres utrzymania aplikacji webowej po wdrożeniu przedstawia artykuł o utrzymaniu dedykowanych aplikacji webowych, a rachunek kosztów w kolejnych latach pokazuje tekst o tworzeniu programów dla firm i ich utrzymaniu.

Ogólne omówienie modelu współpracy z wykonawcą znajduje się w artykule o oprogramowaniu na zamówienie, a różnice między rodzajami wykonawców w tekście o tym, czym jest software house. Oferta programowania na zamówienie SoftwareStudio dostępna jest na stronie usług producenta.