analiza - IT-Consulting Jarosław Żeliński

Początek dobry a potem coraz gorzej czyli MVP

Post author:Jarosław Żeliński
Post published:2 kwietnia 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:4 komentarze
Post last modified:2 kwietnia 2024

Wprowadzenie Od kilku już lat jestem, jako ekspert, angażowany jako rzeczoznawca do sporządzania opinii na zlecenie sądów (opinia biegłego) lub jednej ze stron sporu (opinia prywatna). Są to spory dotyczące nieudanych dostaw i wdrożeń oprogramowania, nie tylko ERP, bardzo często także dedykowanego. Po tych latach wyłania się pewien wspólny mianownik, łączący te porażki scenariusz: firma dostaje ofertę na dostarczenie i wdrożenie oprogramowania, ma miejsce prezentacja pomysłu, jakieś makiety, jakaś działająca funkcjonalność, przedmiotem oferty jest prezentowane istniejące oprogramowanie z obietnicą jego dostosowania (kastomizacji), lub oferta wykonania dedykowanego oprogramowania, projekt przyjmuje formę…

Czytaj dalej

Czym jest dług informacyjny

Post author:Jarosław Żeliński
Post published:7 listopada 2023
Post category:Analizy biznesowa i projektowanie oprogramowania Organizacja jako system czyli co CxO powinien wiedzieć
Post comments:0 Komentarzy
Post last modified:13 stycznia 2024

Dług informacyjny jest znacznie groźniejszy niż dług technologiczny. Same zaległości technologiczne jako takie można usunąć bez dużego ryzyka: jest to po prostu upgrade już posiadanej infrastruktury. Dług informacyjny jest znacznie bardziej niebezpieczny, bo to całkowity brak wiedzy o tym jak to zrobić bezpiecznie i co w ogóle zrobić (upgrade czy jednak wymiana systemu na nowy inny). Dług informacyjny to nie tylko nieudokumentowany system. To nieudokumentowane procesy biznesowe, procedury, reguły biznesowe, to zasoby wiedzy o organizacji jedynie w „głowach pracowników”, te zaś są najczęściej niespójne, niekompletne i bardzo często sprzeczne.

Czytaj dalej

Regulamin Usługi jako potrzeby czyli prawnik jako analityk

Post author:Jarosław Żeliński
Post published:27 marca 2023
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:15 grudnia 2023

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 dalej

Ontologia – zastosowanie w inżynierii oprogramowania

Post author:Jarosław Żeliński
Post published:22 września 2022
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:4 komentarze
Post last modified:30 października 2023

Ontologia jako narzędzie tworzenia "modeli świata", jest bardzo dobrym narzędziem do projektowania danych, zorganizowanych - w łatwe do zarządzania w bazach NoSQL - dokumenty. Wstęp Niedawno napisałem: Czy opracowanie ontologii jest łatwe? Nie, nie jest. Czy zła ontologia szkodzi? Tak, potrafi doprowadzić do fiaska projektu informatycznego. źr.;: Ontologia czyli jak się to robi Po co to wszystko? Obecnie często mówimy o Big Data, czyli o masowo gromadzonych danych. Ich gromadzenie wymaga opracowania struktury ich gromadzenia i zarządzania nimi, bez tego powstanie "stos nieskatalogowanych dokumentów". Proces gromadzenia danych jest stratny, więc…

Czytaj dalej

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

Post author:Jarosław Żeliński
Post published:17 listopada 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:6 grudnia 2021

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 dalej

Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Post author:Jarosław Żeliński
Post published:9 lutego 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:3 lipca 2021

Tym razem o czymś co potrafi zabić ;) czyli czym jest dokument oraz fakt i obiekt. Czym się różni zakup kilku produktów, w tym samym sklepie, w np. godzinnych odstępach czasu, od zakupu wszystkich razem? Poza formą udokumentowania, niczym: w sklepie to samo i tyle samo zeszło ze stanu magazynu, a my wydaliśmy w obu przypadkach tyle samo pieniędzy (o promocjach później)! W pierwszym przypadku mamy kilka faktów zakupu, w drugim, jeden, ale zawsze tyle samo obiektów (produkt). Faktura (paragon) to dokument opisjący fakt, przedmiot sprzedaży jest obiektem. Tu obiektem…

Czytaj dalej

Model referencyjny systemu ERPII czyli co?

Post author:Jarosław Żeliński
Post published:6 stycznia 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:31 stycznia 2021

Generalnie modele referencyjne mają i dobrą i złą sławę. Nie są to wzorce projektowe, czyli dobre praktyki w postaci uniwersalnych abstrakcyjnych meta-modeli, są to najczęściej narzucane gotowe architektury, pozostaje pytanie: kto narzuca?. Procesy referencyjne krytykowałem nie raz (Procesy referencyjne czyli kto żyw niech ucieka), referencyjny model ERP oznaczałby, że istnieje jakaś jedynie słuszna architektura systemu ERPII. I właśnie dostawcy wielu systemów ERPII (szczególnie ci duzi, których produkty mają wiele lat) promują model oparty o jedną wspólną relacyjną bazę danych, wokół której są osadzone dziedzinowe moduły, nazywają taki model modelem referencyjnym.…

Czytaj dalej

Przyczyny nieplanowanych kosztów wdrożeń

Post author:Jarosław Żeliński
Post published:9 grudnia 2020
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:10 grudnia 2020

Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy . Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a…

Czytaj dalej

Pandemia COVID – model dedukcyjny

Post author:Jarosław Żeliński
Post published:2 kwietnia 2020
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:15 komentarzy
Post last modified:19 grudnia 2021

(opracowanie: kwiecień 2020 - blog, aktualizacja: grudzień 2020 - Academia.edu) Opracowanie stanowi próbę zbudowania modelu wyjaśniającego aktualną sytuację wywołaną pandemią koronawirusa. Tworząc model autor oparł się na idealizacji mechanizmu rozchodzenia sie choroby. Autor całkowicie zarzucił metody statystyczne prognozowania jako nieskuteczne, w takich przypadkach, co pokazały juz pierwsze miesiące od pojawienia sie wirusa, a potem po pierwszej publikacji tego tekstu w kwietniu 2020. Zdaniem autora opisana w tym opracowaniu droga daje znacznie większe szanse na wyjaśnienia aktualnej sytuacji niż budowanie tak zwanych modeli statystycznych. Już na obecnym etapie model wyjaśnia brak…

Czytaj dalej

(źr. Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978-3-319-39417-6, str. 405)

Od zapytania do realizacji zamówienia czyli jak to się robi z BPMN

Post author:Jarosław Żeliński
Post published:11 lutego 2019
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:8 komentarzy
Post last modified:15 czerwca 2021

Wprowadzenie Ostatnio pojawiła się w prasie i mediach internetowych dyskusja na temat tego czym jest faktura, niestety bardzo wiele z tych opinii jest pozbawiona podstaw merytorycznych i prawnych, są niejednokrotnie po prostu nieprawdziwe. Biorąc pod uwagę fakt, że wiele tych opinii to opinie wygłaszane przez przedsiębiorców, wyłania się smutny obraz jakości informacji zbieranej metodą wywiadów w toku analiz biznesowych. Studiowanie literatury, cudzych opracowań w roli audytora, analiza pytań i uwag moich klientów to ogromne doświadczenie. Rok temu w artykule Mit o notacji BPMN pisałem o szkodliwości nadmiaru szczegółów na modelach. To…

Czytaj dalej

Mało który deweloper używa UMLa zgodnie ze specyfikacją…

Post author:Jarosław Żeliński
Post published:20 listopada 2017
Post category:Analizy biznesowa i projektowanie oprogramowania Załącznik video
Post comments:2 komentarze
Post last modified:13 stycznia 2024

Od czasu do czasu wpadają mi do skrzynki email „niuslettery”, które gdzieś tam czasem zamawiam, głównie z powodów poznawczych. Oto jeden z nich…

Nie jest tajemnicą, że na rynku mamy różne metody pracy i wszystkie mają swoich zwolenników i przeciwników czy może raczej krytyków. Tym razem przedmiotem „badania” był sposób opisania problemu i wnioski jakie autor wyciągnął.

(więcej…)

Czytaj dalej

Model czy abstrakcja

Post author:Jarosław Żeliński
Post published:22 września 2017
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:13 komentarzy
Post last modified:16 lipca 2020

[zaktualizowany [last-modified]] Niedawno pisałem na temat "modelu systemu" i "modelu dziedziny systemu". Oba te pojęcia są sobie bliskie, pierwsze jest bardzo ogólne, dotyczy systemu zawężonego do jego dziedzinowej specyfiki. Model dziedziny systemu to także, w inżynierii oprogramowania, nazwa konkretnego komponentu, nazywanego Model, w architekturze opartej na wzoru MVC. Swego czasu pisałem, że (Czym jest a czym nie jest model dziedziny...): Pojęcie system oznacza albo detaliczną strukturę określonej rzeczywistości albo abstrakcję ją reprezentującą (model systemu). Jest to standardowe tłumaczenie tego pojęcia w literaturze z zakresu teorii systemów a także właśnie inżynierii…

Czytaj dalej