Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Dzisiaj miała miejsce premiera pakietu Visual Paradigm. Poza wieloma nowymi udogodnieniami potężny pakiet nowości w obszarze pracy grupowej i zarządzania projektami. Wsparcie na PMI, zarządzanie cyklem życia projektu WBS czyli Work Breakdown Structure jako diagram i lista Dodatkowy generator sprawozdań postępów w projekcie Poszerzone zarządzanie repozytorium dokumentów Poszerzone wsparcie dla TOGAF Integracja WBS z wykresami PERT Narzędzia dla JIT (Just in Time) Szablony dla PMBOK Poszerzone wsparcie dla metodyk zwinnych i SCRUM w obszarze historii użytkownika (user story) Gantt - nowy wykres zintegrowany z pozostałymi. Nowa opcja: modelowanie z użyciem WWW,…
Tym razem kilka komentarzy do rekomendacji PZP. Najpierw to: Art. 29 ust. 1 ustawy PZP nakłada na zamawiającego obowiązek opisania przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty. Zapis ten służy realizacji ustawowych zasad uczciwej konkurencji a co za tym idzie zasady równego dostępu do zamówienia, wyrażonych art. 7 ust. 1 ustawy Pzp. (Źródło: Urząd Zamówień Publicznych - Opinia dotycząca opisu przedmiotu zamówienia). Spotykam się z tezami, że nie można używać notacji UML, BPMN…
Moja publikacja w COMPUTERWORLD, podsumowanie: Każda firma, szukając sposobu na uzyskanie przewagi rynkowej, stara się pewne obszary operacyjne budować według własnej strategii. To m.in. powoduje, że każde wdrożenie jest inne i nie ma jednej słusznej architektury IT. Podstawą jest możliwość wdrażania tych podsystemów w dowolnie wybranej kolejności. Co ciekawe, najmniej problemów w firmach sprawia księgowość kontowa, zaś wdrożenie monolitycznego ERP wymaga jej wymiany na nową już na samym początku. Zapraszam do lektury całości: System monolityczny czy rozwiązania komponentowe - Computerworld - Wiadomości IT, biznes IT, praca w IT,
Wprowadzenie bardzo często mozna spotkać opisu typu: MVC architecture. AngularJS divides your web app into three distinct parts — Model (data), View (the UI layer), and Controller (business logic). The three units can be developed in parallel and separately tested. As a result, the code becomes easier to understand, maintain, and extend. (https://www.altexsoft.com/blog/the-good-and-the-bad-of-angular-development/) Niestety jest to powielanie podejścia z czasów lat 90-tych i JavaEE/SE. Patrząc na te trzy pojęcia View to owszem "widoki" czyli GUI, nieporozumienia dotyczą Model'u i Controler'a. Poniżej obecne źródło (jedno z wielu) tego nieporozumienia: Model to…
Powszechnym błędem jest więc "zamawianie" oprogramowania metodą specyfikowania wymagań, jako wielu przypadkowo, lub nawet systematycznie, opisanych reakcji na bodźce, bez zrozumienia mechanizmu ich powstawania. Implementacja tak opisanych wymagań bardzo często jest realizowana jako bardzo rozbudowany system pokazujący co sekundę kolejny obraz tarczy zegara zamiast implementacji prostego mechanizmu zmieniającego położenie wskazówek na nieruchomej tarczy zegara. Większość znanego mi oprogramowania jest bardziej złożona niż mogła by być...
Skutek jest taki, że dostawca oprogramowania na podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i by nie płacić za swoje własne know-how "włożone" w toku wdrożenia, do wdrażanego oprogramowania. Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury.
Na wstępnie należy się czytelnikowi pewne wyjaśnienie: kim jest prawnik? Słownik języka polskiego podaje: prawo 1. ?ogół przepisów i norm prawnych regulujących stosunki między ludźmi danej społeczności? 2. ?norma prawna? 3. ?nauka o prawie, studia nad prawodawstwem? 4. ?uprawnienia przysługujące komuś zgodnie z obowiązującymi przepisami? 5. ?zasada rządząca procesami przyrodniczymi i społecznymi, stanowiąca cel badań naukowych? 6. ?kierunek studiów związanych z nauką o prawie, z prawoznawstwem? Pojęcie "prawnik" jest używane generalnie w dwóch znaczeniach: (1) osoba znająca prawo w rozumieniu przepisów i norm prawnych np. danego kraju oraz (2) osoba zajmująca sie nauką jaką jest prawo, studiami…
Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: "nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale". To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa... a nie raz z jego łamaniem. Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji.…
Dwa lata temu pisałem o mikroserwisach: Obecnie mamy już dość dobrze wypracowane wzorce projektowe ale nadal jest problem ze zrozumieniem ?kiedy i jak?. Ładnie to opisał swego czasu E.Evans przy okazji wzorca DDD, Tu poprzestanę jedynie na pojęciu bounded context czyli ?granica kontekstu?. Granica ta ma podwójne znaczenie: kontekst nadaje (zmienia) znaczenia w modelu pojęciowym (bałwan w kontekście zimy to co innego niż bałwan w kontekście członków zespołu projektowego) oraz kontekst (bardzo często) wyznacza zakres projektu (inne aspekty wzorca DDD tu pominę). Pierwsza uwaga: kontekst dziedzinowy (pojęciowy) jest ważniejszy (powinien…
Jako partner merytoryczny Raportu zapraszam do lektury... PERSPEKTYWY ERP 2017Wzorem ubiegłego roku oddajemy do Państwa dyspozycji materiał stanowiący podsumowanie działań kluczowych dostawców rozwiązań wspomagających zarządzanie przedsiębiorstwem w 2016 r. oraz prezentację kierunków rozwoju oferowanych systemów ERP w roku bieżącym. Mamy nadzieję, iż zaprezentowane wypowiedzi będą dodatkowym argumentem przy wyborze partnera w działaniach zmierzających do optymalizacji i podniesienia efektywności posiadanych zasobów IT w roku 2017. Źródło: PERSPEKTYWY 2017 - ERP-view.pl - ERP, CRM, MRP, Business Intelligence, MRP
