Inżynieria sys­te­mów opar­ta na mode­lach (MBSE) jest sfor­ma­li­zo­wa­ną meto­do­lo­gią, któ­ra jest uży­wa­na do wspie­ra­nia wyma­gań, pro­jek­to­wa­nia, ana­li­zy, wery­fi­ka­cji i wali­da­cji zwią­za­nych z roz­wo­jem zło­żo­nych sys­te­mów. W prze­ci­wień­stwie do inży­nie­rii skon­cen­tro­wa­nej na doku­men­tach, MBSE sta­wia mode­le w cen­trum pro­jek­to­wa­nia sys­te­mu. Zwiększone przy­ję­cie śro­do­wisk mode­lo­wa­nia cyfro­we­go w cią­gu ostat­nich kil­ku lat dopro­wa­dzi­ło do zwięk­szo­ne­go przy­ję­cia MBSE. W stycz­niu 2020 roku NASA odno­to­wa­ła ten trend, infor­mu­jąc, że MBSE jest coraz czę­ściej przyj­mo­wa­ne zarów­no przez prze­mysł, jak i rząd jako spo­sób na śle­dze­nie zło­żo­no­ści sys­te­mu.” W tym wpi­sie na blo­gu przed­sta­wiam krót­kie wpro­wa­dze­nie do MBSE.

Początek dobry a potem coraz gorzej czyli MVP

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 dalejPoczątek dobry a potem coraz gorzej czyli MVP
Model systemu służy do określenia składników systemu.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: the systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Czy drzewo kompozycji i dziedziczenie to na pewno jest model aplikacji? Czy model pojęciowy jest modelem systemu? Nie.

Wprowadzenie Wśród wielu stron WWW jest także ta: Modeling Languages (źródło poniżej). Tym razem autorka w tekście "On comparing modelling languages", porównuje kilka wybranych, jak je nazwała, "języków modelowania". Autorka nazywa modelem urządzenia diagramy map myśli i modele pojęciowe, co jest moim zdaniem złym podejściem. Teza, że ontologia to projekt oprogramowania też nie wytrzymuje prostych testów. Modelowanie Najpierw sprawdźmy co oznaczają w literaturze pojęcia model i modelowanie: modelować coś, aby stworzyć kopię lub opis działania, sytuacji itp., aby móc je przeanalizować przed przystąpieniem do prawdziwego działania. https://www.oxfordlearnersdictionaries.com/definition/english/model_2?q=modeling W poprzednim artykule…

Czytaj dalejCzy drzewo kompozycji i dziedziczenie to na pewno jest model aplikacji? Czy model pojęciowy jest modelem systemu? Nie.

Mechanizm działania vs model systemu vs diagram

Wprowadzenie Najczęściej w toku analiz posługujemy się pojęciem model, rzadziej mechanizm. Rzecz w tym, że pojęcie mechanizm pojawia się gdy chcemy coś wyjaśnić, np. "mechanizm generowania upustu na fakturze". Ale tu uwaga! Model (schematy blokowe, wzory itp.) to dokumentacja, opis chroniony prawem autorskim. Mechanizm to to, co zrozumieliśmy czytając te dokumentację (model), bo mechanizm to chronione know-how. Treść wniosku do Urzędu Patentowego to model (opis), ale to co patentujemy to wymyślony/opracowany mechanizm. Mechanizm a model Mechanizm i model w nauce to bliskie sobie pojęcia, np. tak opisywane: Modelowanie polega na…

Czytaj dalejMechanizm działania vs model systemu vs diagram

Ile scenariuszy ma Use Case i dlaczego nie jeden?

Wprowadzenie Bardzo często na szkoleniach, a także na zajęciach laboratoryjnych z przedmiotu Inżynieria oprogramowania, jestem pytany o przypadki użycia i ich scenariusze. Szczególnie często pada pytanie czy przypadek użycie reprezentuje tylko jeden scenariusz. Przypadki użycia w UML to "dzieło" Ivara Jacobsona . Pierwotnie było to narzędzie do opisu zewnętrznych cech (zachowań) systemu, rozumianych jako jego oczekiwane zachowania, czyli wymagania wobec systemu. Był to tak zwany "opis czarnej skrzynki". Problemem było to, że "czarna skrzynka" mówi CO ale nie mówi JAK. Jacobson opisywał przypadki użycia z pomocą warunków (stanów początkowego i…

Czytaj dalejIle scenariuszy ma Use Case i dlaczego nie jeden?

Wzorzec MVC – dyskusja c.d.

Wprowadzenie Wzorzec ten budzi wiele kontrowersji co do tego czym są te trzy komponenty. Popatrzmy do anglojęzycznej WIKI: Model - Centralny komponent wzorca. Jest to dynamiczna struktura danych aplikacji, niezależna od interfejsu użytkownika. Bezpośrednio zarządza danymi, logiką i regułami aplikacji. W Smalltalk-80, model jest całkowicie pozostawiony programiście. W WebObjects, Rails i Django, model zazwyczaj reprezentuje tabelę w bazie danych aplikacji. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Jest to dominująca definicja w literaturze, zaś spory o to czym jest Model w architekturze MVC jak widać mają jedno główne źródło: jakiego frameworka używa osoba wchodząca w takie…

Czytaj dalejWzorzec MVC – dyskusja c.d.

Prawo autorskie a produkty AI

Lawinowo pojawiają się pomysły prawnego regulowania AI, a nawet upodmiotowienia AI (patrz: Sztuczna inteligencja jest sztuczna, co jest już moim zdaniem kuriozalne). Ale po kolei. Prawo autorskie W ustawie z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych czytamy: Przedmiot prawa autorskiego Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór). 2. W szczególności przedmiotem prawa autorskiego są utwory: 1) wyrażone słowem, symbolami matematycznymi, znakami graficznymi (literackie, publicystyczne, naukowe, kartograficzne…

Czytaj dalejPrawo autorskie a produkty AI

Przed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników

Wprowadzenie W roku 2017 komentowałem dokument, który Ministerstwo Cyfryzacji opublikowało (Opublikowano: 22.11.2017), zatytułowany "Wzorcowe klauzule w umowach IT". Czytam tam między innymi: Klauzule zostały opracowane na zlecenie Ministra Cyfryzacji przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT. (źr. https://www.gov.pl/cyfryzacja/wzorcowe-klauzule-w-umowach-it) Moje uwagi umieściłem we wpisie: Wzorcowe klauzule w umowach IT. Gorąco polecam przeczytanie, opisałem tam kwestie słownika w Umowie, który jest kluczem dla brzmienia Umowy i jej późniejszej interpretacji. Te klauzule nadal są oficjalne…

Czytaj dalejPrzed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników

Analityk czyli kto?

Ten artykuł to zanonimizowana korespondencja, na często pojawiający sie temat: zakres pracy analityka. O co chodzi Dzień dobry, piszę z prośbą/pytaniem czy byłby Pan w stanie polecić książkę albo inny zasób z ćwiczeniami UML oraz BPMN? Jest z tym problem bo jest mało literatury i często są to płatne publikacje naukowe. Powód jest dość prozaiczny: 1. komercyjne projektty są chronione tajemnica przedsiębiorstwa, 2. napisanie takich ćwiczeń i przykładów jest pracochłonne i mało kto to robi. Mogę polecić swoją książkę i mojego bloga ;), na blogu pod wpisami zawsze podaje wykorzystaną…

Czytaj dalejAnalityk czyli kto?

Utwór vs. projekt a własność intelektualna w inżynierii

Wprowadzenie Niedawno miała miejsce kolejna moja dyskusja na LinkedIn, która pokazała że prawo własności intelektualnej jest bardzo trudne do przyswojenia, głównie dlatego że – z uwagi na swoją „niematerialność” – wymyka się intuicyjnej i materialnej manierze postrzegania świata przez człowieka. Na to nakłada się przeświadczenie koderów, że z zasady są samodzielnymi twórcami, i niestety wielu prawników także tak uważa. Rzecz w tym, że koder zawsze jest twórcą, ale nie zawsze jest projektantem. Gdy koder nie jest projektantem, jego utwory (kod źródłowy) to utwory zależne od utworów pierwotnych, jakimi są projekty techniczne wyrażone np. z pomocą…

Czytaj dalejUtwór vs. projekt a własność intelektualna w inżynierii

Czym jest dług informacyjny

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 dalejCzym jest dług informacyjny

Czym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Wstęp

Siedem lat temu (2015) arty­kuł o wyma­ga­niach i śla­do­wa­niu koń­czy­łem słowami: 

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce ??wyma­gań? to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu? Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać ??czer­wo­ne­go kolo­ru? nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Source: Dlaczego śla­do­wa­nie wyma­gań jest istot­ne w pro­jek­cie? – Jarosław Żeliński IT-Consulting

Nadal poja­wia­ją się publi­ka­cje o wyma­ga­niach, zarzą­dza­niu nimi i reali­zo­wa­niu ich. Na ryn­ku są dostęp­ne apli­ka­cje pozwa­la­ją­ce je kolek­cjo­no­wać i zarzą­dzać taką kolek­cją. I sta­le mamy do czy­nie­nia z ich – wyma­gań – nie­jed­no­znacz­no­ścią . Okazuje się, że ich zna­cze­nie sta­je sie klu­czo­we dla pro­jek­tów, tak­że z per­spek­ty­wy pra­wa (PZP i zde­fi­nio­wa­ne w zale­ce­niach UZP poję­cie potrze­ba). Tym razem sku­pię się na poję­ciach «wyma­ga­nie» i «potrze­ba» w odnie­sie­niu do pro­jek­tu rozwiązania.

(wię­cej…)

Czytaj dalejCzym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Koniec treści

Nie ma więcej stron do załadowania