Marsz ku klęsce – Poradnik dla projektanta systemów

Lektura na Nowy Rok... Co prawda wydana w 2007 roku, ale właśnie sobie o niej przypomniałem.. Ta książka Yourdona leży u mnie na półce niemalże od dnia jej wydania, gdy ją przypadkiem upolowałem, zaraz po jej ukazaniu się w księgarniach. Napisanie o niej odkładam od lat, bo praktycznie nie ma tam obrazków UML, opisów wzorców itp.. Od jej przeczytania mówię sobie: jutro o niej napiszę... i to trwało do tego momentu. To książka w całości napisana prozą, bez obrazków, w której autor dzieli sie swoimi przemyśleniami na temat architektury systemów,…

Czytaj dalejMarsz ku klęsce – Poradnik dla projektanta systemów

Ochrona programów komputerowych w prawie własności intelektualnej

Wprowadzenie Na stronie PARP od pewnego czasu jest dostępny tekst pod powyższym tytułem: Ochrona programów komputerowych w prawie własności intelektualnej . Autor zaczyna od słów: Wraz ze wzrostem znaczenia programów komputerowych w obrocie gospodarczym, rośnie także potrzeba ich należytej ochrony przed naruszeniami. Jej obecny kształt w polskim prawie jest rezultatem długoletnich prac, zarówno na szczeblu międzynarodowym, jak i krajowym. Opracowanie jest godne uwagi gdyż rzeczowo opisuje stan prawny rynku oprogramowania w obszarze wartości intelektualnych. Z uwagi na to, że autor dokonał analizy z perspektywy prawnej, postanowiłem na przykładach praktycznych pokazać…

Czytaj dalejOchrona programów komputerowych w prawie własności intelektualnej

Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

Wstęp Od lat spotykam się w literaturze z zakresu zarządzania, z krytyką poczty elektronicznej jako narzędziem zarządzania czymkolwiek (patrz: Sabotaż...2013). Poczta elektroniczna (podobnie jak pakiety biurowe w ogóle) jest typowym przykładem maksymy: ułatwienie nie zawsze jest ulepszeniem. W kliencie poczty elektronicznej zarówno treść jak i sposób adresowania (co i do kogo, kopia, itp.) nie podlega żadnej standaryzacji ani restrykcji (poczta elektroniczna często służy do wyprowadzania danych z firmy). Jak dodać do tego fakt, że załączniki są niewidoczne w narzędziach do lokalnego wyszukiwania, że mamy na serwerach filtry antyspamowe których reguły…

Czytaj dalejDlaczego nie używam poczty elektronicznej do komunikacji w projektach
Read more about the article Kiedy maszyna stanowa a kiedy jednak status?
Autorstwa Clemens PFEIFFER - Praca własna: CANON PowerShot G7, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=1441506

Kiedy maszyna stanowa a kiedy jednak status?

Różnica między stanem a statusem obiektu

Wstęp

Od czasu do czasu wpadają mi maile z pytaniami jak to:

Chcę zamodelować dynamiczne zachowanie / stany smartfona (np. wyłączenie smartfona, inicjalizacja, tryb czuwania, użycie) w diagramie maszyny stanów SysML. Dla stanu użytkowania istnieją również podstany takie jak dzwonienie, latarka lub robienie zdjęć. Nie jestem pewien czy powinienem modelować te podstany, a jeśli tak, to jak mogę je modelować (szczególnie biorąc pod uwagę fakt, że każdy z tych podstanów może zmieniać się w inny, jak również mogą one działać równolegle).
Moim zdaniem są różne opcje:
1.) Po prostu uwzględnić je jako aktywność w użyciu stanu
2.) Wymodelować je w oddzielnym diagramie maszyny stanów
3.) Modelować je w oddzielnym diagramie aktywności (czy mozna użyć diagramu aktywności zamiast diagramu maszyny stanowej?)

Takie i podobne pytania pojawiają się w mailach do mnie często, ale zanim na nie odpowiem tu, opiszę czym jest model (diagram) maszyny stanowej. Pokażę także dlaczego, np. próby wdrażania obiegów dokumentów na bazie wzorca “maszyny stanowej” sprawiają ogromne kłopoty, lub po prostu się nie udają.

Na początek to, co znajdziemy np. w Longman English Dictionary:

status: a situation at a particular time, especially in an argument, discussion etc. (sytuacja w określonym czasie, zwłaszcza w kłótni, dyskusji itp.)
state: the physical or mental condition that someone or something is in (stan fizyczny lub psychiczny, w jakim znajduje się ktoś lub coś)

źr.: Longman English Dictionary https://www.ldoceonline.com/

Tak więc generalnie status to ogląd obiektu z zewnątrz, stan to cecha obiektu. Innymi słowy moja choroba to mój stan, ale moja niezdolność do pracy to aktualny mój status (wynika on nie z choroby, a z ustalenia, że chorzy nie pracują, to nie to samo). Zapraszam do lektury.

(więcej…)

Czytaj dalejKiedy maszyna stanowa a kiedy jednak status?

Transformacja Cyfrowa a dziedzictwo IT

Wstęp

Transformacja cyfrowa, jest przez dostawców technologii informatycznych, najczęściej definiowana jako integracja technologii cyfrowej z działalnością firmy. Poniżej wybrane definicje, które najczęściej znajdujemy w sieci:

Transformacja cyfrowa definiuje się jako integrację technologii cyfrowej ze wszystkimi obszarami funkcjonowania firmy. Dzięki niej możliwe jest wykorzystanie gromadzonych danych do tworzenia innowacyjnych usług i poszerzenia dotychczasowej oferty.

Cyfrowa transformacja to nic innego jak integracja technologii cyfrowej we wszystkich obszarach działalności firmy oraz zmiana sposobu, w jaki działasz i zapewniasz klientom wartość. To także zmiana kulturowa, która wymaga od organizacji ciągłego rzucania sobie wyzwań, eksperymentowania, ale również godzenia się z porażką. Transformacja cyfrowa jest procesem nieuniknionym, niezależnie od rozmiaru przedsiębiorstwa.

Transformacja cyfrowa odnosi się do procesów i strategii wykorzystania technologii cyfrowej do radykalnej zmiany sposobów, w jakie przedsiębiorstwa prowadzą działalność i obsługują klientów. Termin ten stał się w epoce cyfryzacji wszechobecny. Spowodowane jest to tym, że każda organizacja ? niezależnie od jej rozmiaru i branży ? coraz bardziej opiera się na danych i technologii, aby zwiększać wydajność swojej działalności i zapewniać wartość swoim klientom.

Ogólne idee wiedzy jako fundamentu nowej gospodarki i informacji jako najważniejszego zasobu wypełniają się treścią i rodzą nowe pojęcia: smart devices i weareables, Big Data, mobilność, chmura obliczeniowa, platformy społecznościowe, bio- i nanotechnologie, Internet of Things, energia odnawialna czy share economy?

Dominuje “integracja technologii cyfrowej z działalnością firmy”. Osobiście jestem zwolennikiem tezy, że nie tyle firmy co generalnie człowieka. Czym jest tu sama integracja technologii z działalnością człowieka? Maszyny nie myślą, jednak przetwarzają dane. Człowiek nadaje znaczenie danym, potrafi je także przekształcać. Cyfrowa transformacja to proces przenoszenia przetwarzania danych z człowieka na maszyny: to już nie my ludzie wyszukujemy dokumenty w archiwach, robi to elektroniczne archiwum, nie my ludzie obsługujemy klientów za ladą, coraz częściej robi to Internetowy Sklep. Cyfrowa transformacja to właśnie proces przenoszenia części pracy z człowieka na maszyny.

Aby transformacja cyfrowa była w ogóle możliwa, musimy przenieść te dane (treści, informacje) z papieru “do komputera”, w sposób nieniszczący obecnych możliwości i pozwalający na tworzenie nowych.

Trzeba też zniwelować posiadany dług technologiczny. Dług technologiczny to posiadane dziedzictwo, to zapóźnienie, to pozostawanie w tyle za trwającym postępem technologicznym. Dług taki ma bardzo wiele firm. Co z nim zrobić i jak z niego wyjść?

(więcej…)

Czytaj dalejTransformacja Cyfrowa a dziedzictwo IT

Opis wymagań z użyciem Gherkin – czyli dużo korniszonów…

Wstęp

Zostałem niedawno zapytany czy pomogę bo “mamy już ponad 150 przypadków użycia w dokumentacji…”. Myślę sobie, to niemożliwe, nie ma tak wielkich systemów (wycena okazała się w efekcie pięciokrotnie zawyżona tylko dlatego, że użyto metody zorientowanej na “user story”).

(więcej…)

Czytaj dalejOpis wymagań z użyciem Gherkin – czyli dużo korniszonów…

Odpowiedzialność projektanta systemu

Wstęp

prawie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w doku­men­ta­cji wyma­gań. Jakim wyma­ga­niem jest zgod­ność z obo­wią­zu­ją­cym pra­wem? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspekty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może  wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z prawem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?.  Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?.  (źr.: Prawo a wymagania … )

Dzisiaj czytam:

To administrator odpowiada za zabezpieczenia systemów, a więc także za to, że pracownik zdołał skopiować dane osobowe na zewnętrzny nośnik. […] W ocenie WSA w toku postępowania PUODO prawidłowo ustalił, iż w SGGW dopuszczono się licznych uchybień, w szczególności nie przeprowadzono właściwej analizy ryzyka i oceny zagrożeń już na etapie projektowania systemów (privacy by design) oraz nie wdrożono odpowiednich środków zapewniających bezpieczeństwo danych, w tym przed możliwością wyeksportowania danych z systemu na zewnątrz.(źr.: Odpowiedzialność administratora za naruszenie zasady privacy by design)

Rzecz w tym, że administrator, w rozumieniu prawa, to także podmiot zlecający powstanie oprogramowania, które go wspiera w realizacji jego obowiązków, a jednym z tych obowiązków jest egzekwowanie ustalonych zasad. Dzisiaj o tym, że zbieranie “podpisów pod oświadczeniami” to nie jest bezpieczeństwo.

(więcej…)

Czytaj dalejOdpowiedzialność projektanta systemu

Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Wprowadzenie

W artykule o aplikacjach webowych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wzajemna nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług aplikacyjnych. (źr.: Aplikacje webowe i mikroserwisy czyli architektura systemów webowych).

Przy innej okazji pisałem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzorce projektowe )

Szkolenia dla analityków poprzedzam ankietami przed szkoleniowymi, jak do tej pory żadna nie zawierała pytań o wzorce projektowe: ani tego że są używane ani tego, że są celem szkolenia, niemalże każdy deklaruje albo, że używa UML lub, że chce zacząć używać UML, nawet gdy są to programiści. Zauważyłem, że wzorce projektowe w świadomości analizy biznesowej i projektowania (OOAD) “nie istnieją”. Wśród programistów, jeżeli jest spotykana, to wiedza o wzorcach przydatnych w tworzeniu bibliotek i narzędzi, często też powielane są wyuczone stare i złe praktyki programistyczne rodem z lat 60-tych (np. praktyki SmallTalk, patrz dalej).

Z drugiej strony od wielu lat znane są techniki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), które w różnych formach, ale jednak wskazują, że najskuteczniejsza forma wyrażania wymagań wobec rozwiązania to projekt architektury i logiki dziedzinowej (model) działania aplikacji . O projektowaniu poprzedzającym implementację pisze sie od dość dawna, metody obiektowe i dobre praktyki znane są od lat .

Autorzy BABoK praktycznie od początku istnienia tego wydawnictwa, zwracają uwagę na tak zwaną “białą skrzynkę”, czyli wymagania wyrażone w postaci wewnętrznej struktury produktu, wskazując, że to znacznie skuteczniejsza metoda definiowania wymagań wobec rozwiązania, niż tak zwana “czarna skrzynka”, czyli tradycyjne, i jednak mniej skuteczne, wymagania wyrażone tylko jako cechy funkcjonalne i poza-funkcjonalne. Pamiętajmy, że adresatem wymagań jest zawsze dostawca produktu!

(więcej…)

Czytaj dalejArchitektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

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?

Emocjonujące bramki czyli dogmaty vs. logika

W toku szkoleń, a także audytów, powstają nie raz spory o interpretacje znaczenia symboli notacji: ich semantyki i syntaktyki (co oznaczają i jak je można łączyć z innymi). Dzisiaj o dość częstym sporze czyli bramki OR (inclusive) i XOR (exclusive) w notacji BPMN oraz o tym, że z 380 stron specyfikacji BPMN, w modelach analitycznych stosujemy tylko niecałe 40 stron rozdziału 7., pozostałe rozdziały służą wyłącznie lepszemu zrozumieniu teorii i modelom wykonywalnym. Czyli dlaczego w analizach stosujemy kilka, a nie kilkadziesiąt symboli notacji BPMN.

(więcej…)

Czytaj dalejEmocjonujące bramki czyli dogmaty vs. logika

Koniec treści

Nie ma więcej stron do załadowania