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.
Tak więc moim zdaniem zarządzanie wiedzą to nie tylko jej gromadzenie i udostępnianie, ale przede wszystkim selekcja! Nasz mózg robi dokładnie to samo: zapomina o wszystkim co nie jest bezpośrednio używane do bieżącego życia i przeżycia.
Na pewno nie jest to miejsce na streszczanie takich konferencji ale w jednej z prezentacji pojawiło się ważne stwierdzenie: retencja danych (gromadzenie ich, tu w kontekście wiedzy należy rozumieć: celowo, wybiórczo i w kontrolowany sposób). Jest to moim zdaniem druga najważniejsza cecha systemów zarządzania wiedzą (pierwszą była powiązana z tym pojęciem selekcja danych).
Coraz częściej spotykam się w ?prasie internetowej? czyli w blogach i komentarzach na temat ich wartości z przypadkami manipulowania ich treścią. Dotyczy to z jednej strony koniunkturalnej zmiany treści wpisów czy wręcz usuwania chwilowo niewygodnych (szczególnie dotyczy to blogów polityków ale nie tylko) a z drugiej ustalania autorstwa treści gdzie w zasadzie łatwo to określić po pierwszeństwie publikacji (na szczęście manipulowanie datami wpisów jest już dość trudne).
Na niwie własnego biznesu jak i takich jak powyższe wydarzeń mam wrażenie ( i "przepowiadam" :)), że doczekamy czasów gdy wiarygodność operatora ISP np. blogu będzie polegała na tym, że:
- każdy wpis będzie opatrzony prawdziwą datą i czasem (niemodyfikowalnym przez autora blogu)
- wpisy będą wersjonowane a usunięcie będzie możliwe wyłącznie przez administratora (np. na wniosek) a nie przez autora wpisu.
Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że "z kompletu" przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ... ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża).
Z danymi jest troszkę tak jak z pieniędzmi i ludźmi: samo posiadanie pieniędzy z nikogo jeszcze nie uczyniło wielkiego człowieka co nie zmiania faktu że wielu stale i za wszelką cenę próbuje tylko mieć dużo pieniędzy. Posiadanie dużej ilości danych (w hurtowni) nie czyni z nich ani wiedzy ani narzędzia wspomagającego podejmowanie decyzji.
(more…)
Ciekawe jest to, że dostawcy i wykonawcy oprogramowania często zawyżają wartość swoich usług w zasadzie na życzenie zamawiających. Robią nie ze złej woli, robią to bo zamawiający niejako sami o to proszą. Dyskutuję przy okazji projektów z wieloma programistami, projektantami, wdrożeniowcami i prawie wszyscy mówią jedno: to zamawiający ma określić swoje wymagania, jeśli określi jej zbyt ogólnikowo musimy w ofercie założyć margines bezpieczeństwa kosztów na wszelkie zmiany i uściślenia jakie klient najprawdopodobniej wniesie podczas realizacji tak słabo udokumentowanego projektu. Korekty będą na pewno bo na podstawie “jednej strony” opisu wymagań nie da się stworzyć miarodajnego projektu, twórca oprogramowania będzie więc gdybał na koszt zamawiającego. To z tego powodu, moim zdaniem, popularne są metody odkrywania wymagań poprzez kolejne prototypy. Programista sam nie określi wymagań ale będzie żądał pieniędzy za te prototypy no bo przecież nie będzie dopłacał do swoich usług.
(more…)
