Jarosław Żeliński Date. (2021). Metody kastomizacji oprogramowania standardowego – aspekty ekonomiczne: Recenzja. https://doi.org/10.13140/RG.2.2.22292.01927
Wstęp
Publikacja Jędrzeja Wieczorkowskiego (dalej: recenzowane opracowanie) o poniższym tytule ukazała się w 2015 roku:
Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kastomizacji oprogramowania standardowego: aspekty ekonomiczne.
Autor recenzowanego tekstu odnosi sie do skutków ekonomicznych, pomija jednak całkowicie skutki prawne kastomizacji kodu oprogramowania, które mają wpływ na koszty i ochronę wartości intelektualnych. Autor pisze we wstępie:
Celem niniejszego opracowania jest analiza możliwych metod kastomizacji systemów informatycznych zarządzania przeprowadzona z ekonomicznego punktu widzenia, w tym w szczególności opłacalności stosowania oprogramowania standardowego i wykorzystania poszczególnych metod jego adaptacji. […] Kastomizację systemu informatycznego ogólnie należy rozumieć jako jego adaptację do potrzeb konkretnego podmiotu. M. Flasiński określił kastomizację, jako ?konfigurację systemu, osadzenie w systemie za pomocą prac programistycznych dodatkowych funkcjonalności oraz modyfikację istniejących funkcjonalności systemu?
Dostarczanie oprogramowania i jego wdrażanie, wiąże się jego ewentualnym dostosowaniem do potrzeb użytkownika. Autor powyższego opracowania, stosując nieprecyzyjne definicje pojęć, wprowadza czytelnika w błąd, opisując przyczyny i konsekwencje związane z szeroko pojętym dostosowaniem oprogramowania do potrzeb użytkownika.
Niestety z tego dokumentu korzysta wielu prawników, nazywając go nie raz nawet “wykładnią”.
Architektura oprogramowania i definiowanie jego funkcjonalności
Podstawowym elementem opisującym oprogramowanie są usługi jakie ono świadczy użytkownikowi. Standardem opisu systemów, także informatycznych, jest obecnie system pojęciowy i notacja UML . Usługi aplikacji definiujemy tu jako oczekiwany i trwały efekt (produkt) jaki uzyskuje aktor (użytkownik) z pomocą aplikacji (jej usług). Uzyskanym trwałym efektem jest tu zarówno uzyskany np. nowy dokument, jak i uzyskana zmiana zachowania samej aplikacji. Co do zasady usługa aplikacji to jej funkcjonalność, a więc coś co ona potrafi, bo została w tym celu stworzona.
Jeżeli oprogramowanie nie oferuje określonej wymaganej funkcjonalności (nie spełnia wymagań), wymagana jest ingerencja w jego konstrukcję czyli kod.
Powyższy diagram obrazuje związek aplikacji (definiowana jest jako komputerowy program użytkowy) z jej kodem (diagram przypadków użycia, związki notacji UML napisano z dużej litery):
- wymagane usługi aplikacji oferuje aplikacja (System, po lewej): Korzystanie z aktualnej logiki aplikacji oraz Ustawienia logiki działania aplikacji: jej parametryzacji, to Typy Usług aplikacji.
- Aplikacja (kod) Realizuje funkcjonalności wyspecyfikowane po lewej jako “Aplikacja”,
- Aplikacja (kod) wykonuje się w Środowisku aplikacji: biblioteki programistyczne (framework),
- źródłem Środowiska i Komponentu aplikacyjnego standardowego (kod) jest producent oprogramowania standardowego,
- źródłem Komponentu aplikacyjnego dedykowanego (kod) jest Developer, (komponenty te współpracują: są zintegrowane),
- wdrożenie, wymagające zmiany logiki działania aplikacji, osiągane metodą zwaną parametryzacją (konfiguracją), to co do zasady korzystanie z aplikacji, nie wymaga więc ingerencji w jej kod, gdyż parametryzacja to także usługa oferowana użytkownikowi przez aplikację (zmiana wartości określonych zmiennych/parametrów),
- wymagane, dodatkowe usługi aplikacji, niedostępne w jej standardowej wersji, realizuje komponent dedykowany (czyli rozszerzenie), wytworzony w środowisku macierzystej aplikacji,
- zmiana zachowania aplikacji standardowej, niedostępna z poziomu usług aplikacji, wymaga więc albo jej rozszerzenia, albo jej kastomizacji (czyli ingerencji w jej macierzysty kod).
Taksonomia pojęcia Zmiana zachowania oprogramowania
Pojęcie ‘dostosowanie’ w języku polskim jest definiowane jako: “zmienić coś tak, by pasowało do czegoś”. W inżynierii oprogramowania operujemy pojęciem wymaganie: “warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać”. Tak więc dostosowanie oznacza tu doprowadzenie do tego, by oprogramowanie spełniało ‘wymagania’. Jeżeli oprogramowanie standardowe nie spełnia wymagań to znaczy, że trzeba je dostosować, czyli zmienić jego zachowanie (o ile się na to godzimy).
Powyższy diagram obrazuje taksonomię pojęcia “zmiana zachowania oprogramowania”. Do pojęć słownikowych: ‘parametryzacja’ i ‘rozbudowa’, dodano w tej taksonomii pojęcie zdefiniowane przez autora recenzowanego opracowania: ‘kastomizacja’, tak by spełniało zasady logiki definiowania pojęć: definicje pojęć muszą się wzajemnie wykluczać . Generalizacja musi więc stanowić uogólnienie pojęć stanowiących jej specjalizację (typy). Innymi słowy: parametryzacja, rozbudowa i kastomizacja, to specjalne, i wykluczające się zarazem wzajemnie, typy (metody) zmiany zachowania oprogramowania.
Szczególnie niebezpieczna jest kastomizacja, która oznacza ingerencję w kod aplikacji:
Kastomizacja ERP: to zmiany, które firmy wprowadzają do swoich systemów ERP, aby spełnić krytyczne wymagania biznesowe. Zmiany te zazwyczaj obejmują edycję kodu źródłowego oprogramowania w celu uzyskania funkcjonalności, których nie zawierają funkcje natywne.
https://softwareconnect.com/learn/erp-configuration-vs-customization/
Poniżej ilustracja pokazująca ww. definicje:
Recenzowane opracowanie
Autor recenzowanego opracowanie klasyfikuje systemy (aplikacje):
?? powielarne zamknięte ? opracowane na anonimowy rynek, mające niewielkie możliwości dostosowania do specyficznych potrzeb biznesowych poszczególnych odbiorców;
?? dedykowane ? opracowane od podstaw ?na miarę? dla konkretnego odbiorcy;
?? wykorzystujące model rozwoju oprogramowania wielokrotnego użycia (ang. reusable) ? przy ich tworzeniu wykorzystuje się biblioteki zawierające gotowe elementy oprogramowania, zazwyczaj nazywane komponentami;
?? standardowe parametryzowalne ? opracowane na anonimowy rynek, które w ramach dostosowania do potrzeb odbiorcy wymagają w szerokim zakresie ustawienia parametrów eksploatacyjnych, czyli kastomizacji.
Powyższa klasyfikacja stoi w całkowitej sprzeczności z metodami zmiany zachowania oprogramowania, w szczególności z wcześniej przytaczaną przez autora definicją kastomizacji (ingerencja w kod), czym autor sam łamie własną definicję pojęcia ‘parametryzacja’, przecząc podanej przez siebie definicji “kastomizacja’. Dodać warto, że biblioteki (frameworki) to gotowe funkcje, z których tworzy się komponenty, nie jest prawdą, że biblioteki to komponenty aplikacyjne (funkcje biblioteczne same z siebie nie oferują funkcjonalności aplikacji, komponenty tak).
Teza autora recenzowanego opracowania:
O typowej kastomizacji stosowanej w szerokim zakresie można więc mówić w przypadku standardowych systemów parametryzowalnych, określanych także jako systemy wyposażone w możliwość technologicznej kastomizacji.
stanowi sobą pozbawiony logiki zlepek: “parametryzacja to kastomizacja”. W konsekwencji uznałem, że kolejny rozdział recenzowanego opracowania: “Ekonomiczne aspekty kastomizacji oprogramowania”, pozostawię bez komentarza, gdyż skoro użyte definicje są niespójne i sprzeczne, wnioskowanie na ich podstawie z zasady jest niewłaściwe. Stosowane przez autora w dalszej części opracowania “intuicyjne” wnioskowanie, jest moim zdaniem całkowicie nieuprawnioną i nienaukową, metodą wyjaśniania.
Prawo autorskie a architektura kodu aplikacji
Ustawa o prawie autorskim , nie wprost, posługuje sie pojęciem zachowania integralności utworu, oznaczającym brak jakiejkolwiek ingerencji w jego postać. W konsekwencji oznacza to, że kastomizacja, jako ingerencja w kod programu, stanowi naruszenie integralności utworu, jakim jest ten kod.
Na diagramie Oprogramowanie i jego implementacja pokazano architekturę aplikacji w sposób pozwalający zidentyfikować jej elementy z perspektywy integralności utworu, jakim jest kod programu. Diagram Taksonomia pojęcia “zmiana zachowania oprogramowania”, pokazuje możliwe metody zmiany zachowania aplikacji.
Uznając fakt, że kastomizacja narusza integralność utworu, i fakt, że może ona być legalnie niemożliwa z uwagi na ochronę prawno-autorską, zmiana zachowania oprogramowania, bez naruszenia integralności kodu, jest możliwa wyłącznie poprzez parametryzację lub rozbudowę. Rozbudowa aplikacji to dodanie nowego kodu, bez ingerencji w już istniejący: powstaje nowy utwór. Z perspektywy inżynierii oprogramowania, powstaje nowy komponent aplikacji, jako nowy utwór, integrowany z istniejącym już kodem, bez ingerencji w niego. Nowy komponent może powstać w środowisku programistycznym dostarczonym (licencjonowanym) przez dostawcę oprogramowania standardowego, co bardzo ułatwia ich integrację. Postępowanie takie jest zalecane przez producentów oprogramowania standardowego, w przypadku, gdy wymagane jest jasne wskazanie praw autorskich i odpowiedzialności za funkcjonowanie aplikacji: separacja oryginalnego kodu dostawcy, od kodu powstałego w celu zmiany zachowania pozwala zagwarantować podział na kod licencjonowany od producenta aplikacji i dedykowany, dostarczony (często wraz z prawem majątkowym) przez wdrażającego aplikację developera.
Podsumowanie
Wdrażanie oprogramowania standardowego: gotowego, oferowanego na rynku dla szerokiego grona odbiorców, wiąże się koniecznością zachowania odpowiedzialności dostawców i ochrony ich autorskich praw osobistych i majątkowych. To także zachowanie bezpieczeństwa nabywców oprogramowania, gdyż jego dostawca ponosi odpowiedzialność za jego jakość, jednak tylko pod warunkiem zachowania integralności utworu jaki dostarczył. Kastomizacja standardowego oprogramowania, jako ingerencja w jego kod, narusza tę integralność, co zdejmuje odpowiedzialność z pierwotnego jego autora (pomijam tu kwestie tego, czy autor/dostawca wyraża na to zgodę i na jakich warunkach).
W efekcie można stwierdzić:
- wdrożenie oprogramowania powinno polegać na parametryzacji oprogramowania,
- jeżeli zmiana funkcjonalności nie jest możliwa metodą parametryzacji, powinna polegać na rozbudowie o nowe komponenty (dedykowane lub kupione na rynku),
- kastomizacja standardowego oprogramowania prowadzi do zwolnienia jego autorów/producenta, z odpowiedzialności za jego jakość, a także prowadzi do sytuacji, w której instalacja nowej wersji standardowego oprogramowania (upgrade) zniszczy wprowadzone zmiany, dlatego w projektach należy przestrzegać opisanej wyżej separacji i korzystać z rękojmi dla kodu dedykowanego (zapisy o rezygnacji z rękojmi, forsowane przez wielu dostawców oprogramowania są więc i nieuprawnione i nieuczciwe).
W perspektywy kosztów prowadzi to do sytuacji, w której nabywca oprogramowania, po jego kastomizacji, bierze na siebie 100% kosztów dalszego utrzymania i rozwoju, co jest nieekonomiczne, bo celem korzystania z oprogramowania standardowego jest obniżenie tych kosztów (efekt skali: producent rozkłada koszty utrzymania i rozwoju oprogramowania na wszystkich swoich klientów). W przypadku rozbudowy, mamy do czynienia z samodzielnym, relatywnie niewielkim, nowym elementem (komponent) aplikacji, który z reguły stanowi (jego logika) know-how firmy, do którego firma (nabywca) posiada, w prawidłowo skonstruowanej umowie, prawa majątkowe.
Recenzowane opracowanie jest często przytaczane jako uzasadnienie treści umów proponowanych przez dostawców oprogramowania, jako “wykładnia”. Uważam, że umowy te są bardzo niekorzystne dla nabywców oprogramowania, gdyż nie tylko przerzucają na nabywców oprogramowania wszelkie ryzyka wynikające z jakości tego oprogramowania, ale także powodują, że know-how zawarte w kastomizowanym kodzie, staje się własnością dostawcy takiego oprogramowania, gdyż nie istnieje granica pomiędzy kodem dostawcy a kodem powstałym na zamówienie nabywcy.
Bezpieczna dla nabywcy umowa na dostawę oprogramowania powinna zawierać:
- koszt licencji na kod standardowy i koszty jego parametryzacji (usługa ekspercka dostawcy),
- zakres i koszt rozbudowy (rozszerzenie) kodu standardowego o nowe komponenty (na podstawie dostarczonego projektu technicznego),
- przeniesienie na nabywcę autorskich praw majątkowych do powstałego kodu stanowiącego rozbudowę (utwór zależny projektu technicznego) dostarczonej aplikacji (kodu standardowego).
Dodatek
Inżynieria oprogramowania, jak każda inżynieria, cechuje się wieloma dobrymi praktykami. Należą do nich wzorce architektoniczne i zasady tworzenia dobrej architektury . Jaka to jest ta “dobra architektura”? W inżynierii dobra architektura systemu to taka, która prowadzi do konstrukcji łatwych (czyli tanich) w utrzymaniu i rozwoju (serwisowalność). W wieloletnim cyklu życia produktu jego zaprojektowanie i wytworzenie stanowi najkrótszy okres. Kolejne lata to utrzymanie i rozwój. Do tego drugiego zmuszają nas zmieniające się świat i nasze potrzeby.
Jedną z podstawowych zasad dobrej architektury jest zasada Open Closed Principle. Sprowadza się ona do tezy: oprogramowanie powinno być zamknięte na zmiany i otwarte na rozszerzenia. Oznacza to, że rozwój, szczególnie ten w toku wdrażania, gdy uzupełniamy standardowe oprogramowanie o brakujące a wymagane funkcjonalności, powinien polegać na dodawaniu rozszerzeń, a nie na modyfikowaniu już istniejących elementów (kodu). Dlatego znakomita większość znanych mi, liczących się na międzynarodowym rynku, dostawców np. Systemów ERP, zaleca proste postępowanie:
- analiza gap-fit (analiza luki) czyli określenie, których wymagań użytkownika nie spełnia standardowa wersja oprogramowania,
- podjęcie decyzji, które brakujące funkcjonalności zostaną dodane, czyli określenie zakresu projektu (ma to wpływ na koszt i harmonogram),
- wykonanie brakujących modułów (rozszerzenia) i ich integracja z dostarczonym oprogramowaniem standardowym,
- aby to ułatwić, dostawcy standardowego oprogramowania dostarczają (licencjonują) także środowisko programistyczne i integracyjne (biblioteki programistyczne: frameworki).
Dzięki temu zyskujemy także z perspektywy prawnej: separujemy utwory mające różnych autorów i właścicieli. Na oprogramowanie standardowe dostajemy licencję, dedykowane rozszerzenia przechodzą (powinny) na kupującego wraz z prawem majątkowym. Produkty te mają, każdy swój, odrębne cykle życia. Zyskujemy także to, że upgrade (unowocześnienie dokonane przez dostawcę oprogramowania standardowego) nie nadpisze (nie zniszczy) kodu realizującego nasze dedykowane funkcjonalności, bo ten jest odrębnym kodem (komponentem).
[Niniejsze opracowanie doręczono autorowi recenzowanego dokumentu, żadna postawiona tu teza nie została zakwestionowana].
