Architektura informacji, system informacyjny a system informatyczny w organizacji

"Jeśli myślisz, że dobra architektura jest droga, spróbuj złej" Wstęp W roku 2008 pisałem (Forbs): W wie­lu fir­mach decy­zja o wdro­że­niu sys­te­mu infor­ma­tycz­ne­go bar­dzo czę­sto nie jest poprze­dzo­na żad­ny­mi przy­go­to­wa­nia­mi w rodza­ju oce­ny struk­tu­ry orga­ni­za­cji, jej zdol­no­ści do zmian czy też upo­rząd­ko­wa­niem obie­gu infor­ma­cji. Częstym grze­chem jest pró­ba ?wtło­cze­nia? w sys­tem infor­ma­tycz­ny ?sta­re­go? porząd­ku. Drugi grzech to brak opi­sa­ne­go sys­te­mu infor­ma­cyj­ne­go. W efek­cie nastę­pu­je zde­rze­nie rygo­rów papie­ro­we­go obie­gu infor­ma­cji z obie­giem danych w sys­te­mie infor­ma­tycz­nym. Rezygnacja z wie­lu czyn­no­ści (np. sta­wia­nie pie­czą­tek i pod­pi­sów) lub zamia­ny ich na inne sta­je się klu­czo­wym, bro­nio­nym jak nie­pod­le­gło­ści przez wie­lu kie­row­ni­ków…

Czytaj dalejArchitektura informacji, system informacyjny a system informatyczny w organizacji

Regulamin Usługi jako potrzeby czyli prawnik jako analityk

Why is this happening? The methods of project execution by most IT vendors haven't changed in 30 years: talks, interviews, coding, expensive tools (C++, Java). We've known for 20 years that writing a program in C++/Java is twice as much work compared to an identical result achieved with scripting languages (Prechelt, 2003; 2000). The continuing popularity of C++/Java has its origin: most of the large systems in the fin/tech industry were created in the 1990s, and they are not being upgraded and only added functionality despite the fact that it is no secret how to migrate to newer technologies and architectures (Laigner, Kalinowski, Diniz, Barros, Cassino, Lemos, Arruda, Lifschitz & Zhou, 2020). The reasons are quite mundane: as long as there is demand, technology suppliers have no interest in upgrading their products and are selling a permanent technological debt (Rosoff, 2011).

Czytaj dalejRegulamin Usługi jako potrzeby czyli prawnik jako analityk
Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn: "People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!" ["Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!".] (https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/) Świat od dekad boryka…

Czytaj dalejWymagania biznesowe – jak zbierać i dokumentować

Diagram Przypadków Użycia UML

Wprowadzenie Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji ? podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…

Czytaj dalejDiagram Przypadków Użycia UML

Projektowanie i dokumentowanie architektury oprogramowania – trzy książki

Architektura Projekty informatyczne się rozrastają, cała branża ewoluuje. Ostatnie 20 lat doświadczeń pokazało, że owszem sztuką jest stworzyć i wdrożyć oprogramowanie, ale jeszcze większą sztuką jest je konserwować, zmieniać i rozwijać. Wiele firm boryka się z powtarzanymi długotrwałymi i kosztownymi "analizami przedwdrożeniowymi" poprzedzającymi każdy kolejny projekt wdrażania zmian. To skutek braku aktualnej dokumentacji posiadanego systemu. To jak planowanie nowej budowy w mieście nie mając aktualnych planów urbanistycznych tego miasta: każdy nowy projekt to ponowne dokumentowanie stanu obecnego, tylko dlatego, że ktoś nie udokumentował zmian wprowadzonych ostatnim razem (być może poprzednio…

Czytaj dalejProjektowanie i dokumentowanie architektury oprogramowania – trzy książki

Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem rozwiązań.

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się cechą każ­de­go sys­te­mu informatycznego. 

Wyjątkowo na począt­ku (poni­żej) umiesz­czam cały ten cie­ka­wy refe­rat, moż­na bo pomi­nąć i czy­tać dalej, jed­nak jeże­li ktoś chce poznać prze­wi­dy­wa­nia z roku 2016 i ma czas, pole­cam (teraz lub później):

The Future of Software Engineering ? Mary Poppendieck ? GOTO 2016

Obecnie klu­czo­wym pyta­niem jest: Jak zin­te­gro­wać, a nie: Czy zintegrować. 

Pogodzenie się z tym, że świat sys­te­mó ERP już nigdy nie będzie tak pro­sty jak w cza­sach main­fra­me­’ów, czy­li jed­nej cen­tral­nej apli­ka­cji, jest nieuniknione. 

Czym jest obec­nie inte­gra­cja? To wymia­na danych a nie ich współ­dzie­le­nie: dane z urzę­dem wymie­nia­my, dane z kon­tra­hen­tem wymie­nia­my, nie współ­dzie­li­my żad­nych danych z tymi pod­mio­ta­mi, każ­dy ma swo­je wła­sne, bez­piecz­ne bazy danych, i to wszyst­ko ład­nie dzia­ła! Idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych w cza­sach obec­nych jest uto­pią. Taką samą jak hipo­te­tycz­na cen­tral­na baza danych dla wszyst­kich skle­pów inter­ne­to­wych, firm kurier­skich i ban­ków, a one są jed­nak zin­te­gro­wa­ne: one wymie­nia­ją dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czy­li Planowanie Zasobów Przedsiębiorstwa. To sys­tem wyko­rzy­sty­wa­ny przez fir­my do zarzą­dza­nia i inte­gro­wa­nia waż­nych ele­men­tów ich dzia­łal­no­ści. Ale kto powie­dział, że to ma być mono­lit od jed­ne­go producenta? 

Nadal spo­ty­kam pejo­ra­tyw­ne okre­śle­nia sys­tem poin­te­gro­wa­ny” jako kry­ty­kę budo­wy sys­te­mu ERP z kom­po­nen­tów i inte­gra­cji jako wymia­ny danych. Autor tego okre­śle­nia naj­praw­do­po­dob­niej nadal żyje w świe­cie mainframe. 

Chociaż dostaw­cy sys­te­mów ERP ofe­ru­ją apli­ka­cje dla przed­się­biorstw i twier­dzą, że ich zin­te­gro­wa­ny sys­tem jest naj­lep­szym roz­wią­za­niem, wszyst­kie modu­ły w jed­nym sys­te­mie ERP rzad­ko kie­dy są naj­lep­sze z najlepszych.

https://​www​.gart​ner​.com/​e​n​/​i​n​f​o​r​m​a​t​i​o​n​-​t​e​c​h​n​o​l​o​g​y​/​g​l​o​s​s​a​r​y​/​b​e​s​t​-​o​f​-​b​r​eed
(wię­cej…)

Czytaj dalejIntegracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Transformacja Cyfrowa a dziedzictwo IT

Wstęp

Transformacja cyfro­wa, jest przez dostaw­ców tech­no­lo­gii infor­ma­tycz­nych, naj­czę­ściej defi­nio­wa­na jako inte­gra­cja tech­no­lo­gii cyfro­wej z dzia­łal­no­ścią fir­my. Poniżej wybra­ne defi­ni­cje, któ­re naj­czę­ściej znaj­du­je­my w sieci:

Transformacja cyfro­wa defi­niu­je się jako inte­gra­cję tech­no­lo­gii cyfro­wej ze wszyst­ki­mi obsza­ra­mi funk­cjo­no­wa­nia fir­my. Dzięki niej moż­li­we jest wyko­rzy­sta­nie gro­ma­dzo­nych danych do two­rze­nia inno­wa­cyj­nych usług i posze­rze­nia dotych­cza­so­wej oferty.

Cyfrowa trans­for­ma­cja to nic inne­go jak inte­gra­cja tech­no­lo­gii cyfro­wej we wszyst­kich obsza­rach dzia­łal­no­ści fir­my oraz zmia­na spo­so­bu, w jaki dzia­łasz i zapew­niasz klien­tom war­tość. To tak­że zmia­na kul­tu­ro­wa, któ­ra wyma­ga od orga­ni­za­cji cią­głe­go rzu­ca­nia sobie wyzwań, eks­pe­ry­men­to­wa­nia, ale rów­nież godze­nia się z poraż­ką. Transformacja cyfro­wa jest pro­ce­sem nie­unik­nio­nym, nie­za­leż­nie od roz­mia­ru przedsiębiorstwa.

Transformacja cyfro­wa odno­si się do pro­ce­sów i stra­te­gii wyko­rzy­sta­nia tech­no­lo­gii cyfro­wej do rady­kal­nej zmia­ny spo­so­bów, w jakie przed­się­bior­stwa pro­wa­dzą dzia­łal­ność i obsłu­gu­ją klien­tów. Termin ten stał się w epo­ce cyfry­za­cji wszech­obec­ny. Spowodowane jest to tym, że każ­da orga­ni­za­cja ? nie­za­leż­nie od jej roz­mia­ru i bran­ży ? coraz bar­dziej opie­ra się na danych i tech­no­lo­gii, aby zwięk­szać wydaj­ność swo­jej dzia­łal­no­ści i zapew­niać war­tość swo­im klientom.

Ogólne idee wie­dzy jako fun­da­men­tu nowej gospo­dar­ki i infor­ma­cji jako naj­waż­niej­sze­go zaso­bu wypeł­nia­ją się tre­ścią i rodzą nowe poję­cia: smart devi­ces i weare­ables, Big Data, mobil­ność, chmu­ra obli­cze­nio­wa, plat­for­my spo­łecz­no­ścio­we, bio- i nano­tech­no­lo­gie, Internet of Things, ener­gia odna­wial­na czy sha­re economy?

Dominuje inte­gra­cja tech­no­lo­gii cyfro­wej z dzia­łal­no­ścią fir­my”. Osobiście jestem zwo­len­ni­kiem tezy, że nie tyle fir­my co gene­ral­nie czło­wie­ka. Czym jest tu sama inte­gra­cja tech­no­lo­gii z dzia­łal­no­ścią czło­wie­ka? Maszyny nie myślą, jed­nak prze­twa­rza­ją dane. Człowiek nada­je zna­cze­nie danym, potra­fi je tak­że prze­kształ­cać. Cyfrowa trans­for­ma­cja to pro­ces prze­no­sze­nia prze­twa­rza­nia danych z czło­wie­ka na maszy­ny: to już nie my ludzie wyszu­ku­je­my doku­men­ty w archi­wach, robi to elek­tro­nicz­ne archi­wum, nie my ludzie obsłu­gu­je­my klien­tów za ladą, coraz czę­ściej robi to Internetowy Sklep. Cyfrowa trans­for­ma­cja to wła­śnie pro­ces prze­no­sze­nia czę­ści pra­cy z czło­wie­ka na maszyny. 

Aby trans­for­ma­cja cyfro­wa była w ogó­le moż­li­wa, musi­my prze­nieść te dane (tre­ści, infor­ma­cje) z papie­ru do kom­pu­te­ra”, w spo­sób nie­nisz­czą­cy obec­nych moż­li­wo­ści i pozwa­la­ją­cy na two­rze­nie nowych. 

Trzeba też zni­we­lo­wać posia­da­ny dług tech­no­lo­gicz­ny. Dług tech­no­lo­gicz­ny to posia­da­ne dzie­dzic­two, to zapóź­nie­nie, to pozo­sta­wa­nie w tyle za trwa­ją­cym postę­pem tech­no­lo­gicz­nym. Dług taki ma bar­dzo wie­le firm. Co z nim zro­bić i jak z nie­go wyjść?

(wię­cej…)

Czytaj dalejTransformacja Cyfrowa a dziedzictwo IT

Odpowiedzialność administratora systemu

Wstęp

pra­wie 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 aspek­ty. 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 pra­wem?. 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 wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów, a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z tych obo­wiąz­ków jest egze­kwo­wa­nie usta­lo­nych zasad. Dzisiaj o tym, że zbie­ra­nie pod­pi­sów pod oświad­cze­nia­mi” to nie jest bezpieczeństwo. 

(wię­cej…)

Czytaj dalejOdpowiedzialność administratora systemu

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użytkownika. 

Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

(wię­cej…)

Czytaj dalejKastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Opracowanie analizy potrzeb i wymagań w zamówieniach publicznych

Niedawno ukazały się Wskazówki dla Zamawiających... (streszczenie i dokument do pobrania poniżej). Rada Zamówień Publicznych, doceniając wagę analizy potrzeb i wymagań, o której mowa w art. 83 ustawy z dnia 11 września 2019 r. (Dz.U. z  2019 r. poz. 2019 ze zm.),  dla przygotowania i przeprowadzenia procesu zakupowego udzielenia zamówień klasycznych o wartościach równych i przekraczających progi unijne zgodnie z celami nowej ustawy, jakimi są w szczególności podniesienie efektywności oraz konkurencyjności udzielanych zamówień, a także otwarcie na nowe propozycje rynkowe, przygotowała wskazówki interpretacyjne nowego przepisu, mając nadzieję, iż okażą się one przydatne…

Czytaj dalejOpracowanie analizy potrzeb i wymagań w zamówieniach publicznych

Krótka historia pewnego wymagania

Wprowadzenie Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: "projektowanie to waterfall". Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję "Dokumenty analizy biznesowej" albo "Dokumenty wymagań" zawierające setki pozycji o treści "system powinien...", nie raz wykonane przez krytyków "water fall", którzy reprezentując developera deklarującego metody "agile", "zabezpieczają się" przez odpowiedzialnością za zakres projektu. Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków "user story" ani detaliczna…

Czytaj dalejKrótka historia pewnego wymagania

Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten arty­kuł to uzu­peł­nie­nie opi­su: Dokument jako wyma­ga­nie.

Często jestem i ja pyta­ny o to Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?” Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. Zauważyli to tak­że inni:

A Mock-up is a sli­gh­tly glo­ri­fied pic­tu­re, so you will be answe­ring with at least 1001 words ! 

Bardzo czę­sto widu­ję wyma­ga­nia spi­sy­wa­ne jako tak zwa­na lista funk­cji lub funk­cjo­nal­no­ści. Pojęcia te mają takie defi­ni­cje w języ­ku polskim: 

funk­cja ?zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz?, ?moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez urzą­dze­nie lub pro­gram komputerowy?

Funkcjonalność jest defi­nio­wa­na jako funk­cja cze­goś w jakimś systemie. 

(wię­cej…)

Czytaj dalejStruktury formularzy jako forma wyrażania wymagań

Koniec treści

Nie ma więcej stron do załadowania