Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

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

(więcej…)

Czytaj dalejKastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Dokumenty w Krajowym Systemie e-Faktur i nie tylko te dokumenty, e-podpis

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)

(więcej…)

Czytaj dalejDokumenty w Krajowym Systemie e-Faktur i nie tylko te dokumenty, e-podpis

I jak to wszyst­kim poka­zać żeby było czytelne?

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…

(więcej…)

Czytaj dalejI jak to wszyst­kim poka­zać żeby było czytelne?

Koniec treści

Nie ma więcej stron do załadowania