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 adresowana do kadr zarządczych, cały artykuł (obie części) do osób zajmujących się projektowaniem rozwiązań.

Wstęp

Mamy ogólnoświatową sieć Internet, aplikacje lokalne i w chmurze, aplikacje naszych kontrahentów i aplikacje centralnych urzędów. Wszystkie one współpracują i wymieniają dane, czyli są zintegrowane. Dlatego integracja stała się cechą każdego systemu informatycznego.

Wyjątkowo na początku (poniżej) umieszczam cały ten ciekawy referat, można bo pominąć i czytać dalej, jednak jeżeli ktoś chce poznać przewidywania z roku 2016 i ma czas, polecam (teraz lub później):

The Future of Software Engineering ? Mary Poppendieck ? GOTO 2016

Obecnie kluczowym pytaniem jest: Jak zintegrować, a nie: Czy zintegrować.

Pogodzenie się z tym, że świat systemó ERP już nigdy nie będzie tak prosty jak w czasach mainframe’ów, czyli jednej centralnej aplikacji, jest nieuniknione.

Czym jest obecnie integracja? To wymiana danych a nie ich współdzielenie: dane z urzędem wymieniamy, dane z kontrahentem wymieniamy, nie współdzielimy żadnych danych z tymi podmiotami, każdy ma swoje własne, bezpieczne bazy danych, i to wszystko ładnie działa! Idea zbudowania wszystkich funkcjonalności jako zintegrowanej aplikacji na jednej współdzielonej bazie danych w czasach obecnych jest utopią. Taką samą jak hipotetyczna centralna baza danych dla wszystkich sklepów internetowych, firm kurierskich i banków, a one są jednak zintegrowane: one wymieniają dane a nie współdzielą!

ERP to (ang.) Enterprise Resource Planning czyli Planowanie Zasobów Przedsiębiorstwa. To system wykorzystywany przez firmy do zarządzania i integrowania ważnych elementów ich działalności. Ale kto powiedział, że to ma być monolit od jednego producenta?

Nadal spotykam pejoratywne określenia “system pointegrowany” jako krytykę budowy systemu ERP z komponentów i integracji jako wymiany danych. Autor tego określenia najprawdopodobniej nadal żyje w świecie mainframe.

Chociaż dostawcy systemów ERP oferują aplikacje dla przedsiębiorstw i twierdzą, że ich zintegrowany system jest najlepszym rozwiązaniem, wszystkie moduły w jednym systemie ERP rzadko kiedy są najlepsze z najlepszych.

https://www.gartner.com/en/information-technology/glossary/best-of-breed
(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 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

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

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

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 artykuł to uzupełnienie opisu: Dokument jako wymaganie.

Często jestem i ja pytany o to “Jak wyjaśnić złożone rozwiązanie techniczne interesariuszom nietechnicznym?” Jak wielu mi podobnych odpowiadam: rozmawiaj dokumentami. Sponsor projektu, przyszli użytkownicy, postrzegają swoją pracę poprzez dokumenty: ich treść i układ. Zauważyli to także inni:

A Mock-up is a slightly glorified picture, so you will be answering with at least 1001 words !

Bardzo często widuję wymagania spisywane jako tak zwana lista funkcji lub funkcjonalności. Pojęcia te mają takie definicje w języku polskim:

funkcja ?zadanie, które spełnia lub ma spełnić jakaś osoba lub rzecz?, ?możliwość wykonania określonej operacji przez urządzenie lub program komputerowy?

Funkcjonalność jest definiowana jako funkcja czegoś w jakimś systemie.

(więcej…)

Czytaj dalejStruktury formularzy jako forma wyrażania wymagań

Koniec treści

Nie ma więcej stron do załadowania