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 [zotpressInText item=”{5085975:ZYYTZS8M}”] 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?

[zotpressInText item=”{5085975:ZYYTZS8M}”]

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ą”.

Wstęp

Tym razem opisuję kwestie dokumentu, dokumentowej postaci czynności prawnej i faktur w wersji elektronicznej, których wystawianie jest jak najbardziej czynnością prawną, i o innowacji jaką Minister Finansów serwuje nam od nowego roku.

W 2018 roku opisywałem metody uwiarygodniania treści (dokumentów) podsumowując:

Tego typu meto­dy zabez­pie­cze­nia (tak zwa­ne sys­te­mo­we, w prze­ci­wień­stwie do tech­nicz­nych, jaką jest kwa­li­fi­ko­wa­ny pod­pis elek­tro­nicz­ny),  są opar­te na zało­że­niu, że sfał­szo­wa­nie tre­ści doku­men­tu jest nie­moż­li­we (lub jest wykry­wal­ne w 100%) przy zacho­wa­niu usta­lo­nej pro­ce­du­ry dorę­cze­nia doku­men­tu (patrz: Zasada Kerckhoffs?a). Wymagania nakła­da­ne for­mal­nie na pod­miot sta­no­wią­cy Trzecią stro­nę zaufa­nia (nota­riusz) powo­du­ją, że ryzy­ko nie­wy­kry­cia fał­szer­stwa jest bli­skie zeru. Opisane powy­żej meto­dy wymia­ny doku­men­tów nie wyma­ga­ją kosz­tow­ne­go i trud­ne­go w uży­ciu kwa­li­fi­ko­wa­ne­go pod­pi­su elek­tro­nicz­ne­go (źr.: Przesyłki sądowe dostarczane przez internet czyli e-dokumenty c.d.)

Generalnie chodziło o alternatywę dla e-podpisu, który nadal uważam za ślepą uliczkę. Od wielu lat, projektując systemy informatyczne, stosują zasadę mówiącą. że system informatyczny, jako rozwiązanie, nie powinien tworzyć nowych, sztucznych bytów informacyjnych, bo im więcej takich sztucznych (nie istniejących w rzeczywistości) bytów powstanie, tym bardziej system odstaje od realiów rzeczywistości, którą (podobno) ma wspierać. Praktyka pokazuje, że próby implementacji w systemach informacyjnych mechanizmów dalekich od realiów życia, kończy się ogromnym kosztem i często po prostu porażką.

Warto mieć świadomość, że strukturalne i stałe w czasie dane, stanowią mniej niż 20% procent wszystkich danych jakie człowiek tworzy, próby stosowania modelu relacyjnego i SQL do pozostałych ponad 80% danych (dokumentów) to droga do klęski. 

On top of this, there is simply much more unstructured data than structured. Unstructured data makes up 80% and more of enterprise data, and is growing at the rate of 55% and 65% per year. (źr.: Structured vs Unstructured Data 101: Top Guide | Datamation)

Wprowadzenie

Niedawno napisał do mnie czytelnik pod jednym z artykułów:

Załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data. Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kursy) Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY. SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego systemu. Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czytelne? (źr.: : Model pojęciowy, model danych, model dziedziny systemu)

Prawdę mówiąc, mniej więcej w takiej formie dostaje materiały od moich klientów.. ;). Co możemy zrobić? Pomyślałem, że dobry reprezentatywny przykład pomoże. Popatrzmy…

This study presents a method for the storage of data organized in digital documents, which is proven in practice. The discussed method does not bear any disadvantages of the relational model used for data organization, such as the loss of data context and complications evoked by the lack of data redundancy. The method presented here can be used for data organization into documents (digital and paper) as classified aggregates and for data classification. The study also describes a new metamodel for the data structure which assumes that documents, being data structures, form compact aggregates, classified as objects, or event descriptions, thus always assigning them a specific and unambiguous context. Furthermore, the study presents a design method for documents as context aggregates that allows leveling the disadvantages of the relational model and ensures efficient information management. The work also contains practical examples of the application of the described method.

Documents often contain a high volume of different data jointly forming multiple context datasets (aggregates). Application of relational model for the organization of such data leads to the generation of a comprehensive system of relational linked tables, while the removal of redundancies often results in the loss of content context of individual fields in the tables. This gives rise to a necessity to use the highly complex SQL queries so that these documents can be saved in and retrieved from this database. Thus, the database itself solely contains data deprived of the context present in tables, not the documents.

Many authors have pointed out the problem of complexity and the loss of uniform relational model context (Ślęzak et al., 2018). Those authors have suggested that contexts should be separated in large relational data models. However, recommendation of context separation (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), while maintaining the relational model, does not help to solve the issue completely (Awang et al., 2012, 2012, 2012).

Context change often alters the meaning of data (Danesi, 2004). Attempts made for maintaining the meaning of data frequently result in the formation of comprehensive relational data models, thus generating additional costs. Therefore, using one relational data model to save the contents of numerous different documents can make such a system an enormous and indivisible monolith, which is expensive to develop as well as maintain.

Read more…