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.
Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!
Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.
Tak więc warto zawsze rozważać udział fazy analizy i planowania w całości projektu, mieć świadomość konsekwencji tej decyzji oraz w szczególności, planując budżet oraz czas na analizę i projektowanie, przyjąć, że dokumentacja analityczno- projektowa jest objętościowo najszczuplejszym "artefaktem" w całym projekcie (największym artefaktem jest kod) mimo, że nie najtańszym.Na koniec przytoczę słowa jednego z moich klientów, dobrze doświadczonego kierownika projektów: każda oszczędzona godzina analityka projektanta, to dodatkowy tydzień pracy zespołu programistów.
W kontekście poziomów modelowania polecam książkę How Works Get Done , którą właśnie kończę czytać. Bardzo dobre kompendium wiedzy o modelowaniu procesów w kontekście tytułowego "jak ta praca jest wykonywana". Nie będę tu pisał streszczenia ;). Książkę gorąco polecam, jest napisana pragmatycznie przez praktyka, który jednak zaznacza, że skuteczne modelowanie, analiza, usprawnianie procesów i firm wymaga pełnego zrozumienia działania tych firm, zrozumienia wzajemnego wpływu ludzi, zasobów, mechanizmów, celów na produkty procesów, podkreśla także znaczenie i wskazuje korzyści z formalnego podejścia to analizy i modelowania (z naciskiem na słowo modelowanie a…
Moim zdaniem ten kto wymyślił ocenę pracy policji poprzez licznie ilości wystawionych mandatów (albo gorzej - ich wartość!) jest w moich oczach kompletnym ignorantem nierozumiejącym opisanego zjawiska. Wytłumaczeniem może być chęć pozyskania zwiększonych środków z mandatów, ale to jest nic innego jak działania na szkodę społeczności, którą się reprezentuje!
Cel samorządów, z tego co można wyczytać, to zapobieżenie wyrzucania śmieci np. do lasów przez naszych kochanych uczciwych obywateli, gdyż do tej pory obywatel płacił za śmieci, które od niego odebrano. Wystarczyło "zutylizować" śmieci na własną rękę i były oszczędności. Drugi powód to ekologia, czyli maksymalizowanie odzysku (tak zwany [[recycling]]). Czy aby na pewno?
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości "map procesów", które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia. [...] jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
otwartość oprogramowania (kodu) czyni go bardziej wiarygodnym, otwartość kodu skłania jego twórców do podnoszenie jego jakości (wstyd zabrania partaniny ;)), to czy jest darmowy czy nie, zależy wyłącznie od modelu biznesowego sprzedaży: twórca sam ustala czy zarabia na licencjonowaniu kodu czy na swojej wiedzy i pracy, "zamykanie kodu", to kwestia subiektywnego uznania twórcy kodu, czy stanowi on (treść) chronione know-how (jego przewagę konkurencyjną) czy nie... ale warto dodać, że przewaga stojąca na takiej tajemnicy ma jednak gliniane nogi (jak każda przewaga bazująca w 100% na tajemnicy).
W dużym skrócie: nie warto dublować kompetencji bo to nomen omen powielanie ich kosztów. Jeżeli firma ma wdrożone procedury kontrolingowe, to naturalnym jest przekazanie danych (produktu) modelowania i optymalizacji procesów, zamiast wzajemne konkurowanie, tym bardziej, że dane z kontrolingu zawsze - jak sądzę - zostaną uznane za bardziej wiarygodne . Bardzo dobrym "narzędziem" łączącym kontroling, modelowanie procesów i zasoby (nie tylko IT) jest architektura korporacyjna, ale to materiał na kolejny artykuł ;).
Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.
Niezwykle rzadko to robię, ale bywa: tylko cytat i zachęta do lektory całości :) Agile Manifesto Individuals and interactions over processes and tools. Dobry analityk posiada zestaw narzędzi, z kórych może wybierać te, które najlepiej będą pasować do projektu i klienta, nie jest niewolnikiem procesów, których nie potrafi dopasować. Working software over comprehensive documentation. Dobry analityk tworzy dokumentację i modele, które służą projektowi, nie są bezmyślmym wypełanianiem nadmiarowych szablonów. Customer collaboration over contract negotiation. Tu wiele zależy od dostępności klienta i przyjętego modelu współpracy. Im większe stawki i klienci, tym…
Przy piątku naszło mnie na zestawienie pewnych treści (cytaty). Podczas codziennej "prasówki" wpadłem na artykuł "Najczęściej popełniane błędy podczas wdrożenia ERP", oto cytat pierwszy: - Największym błędem popełnianym przy wdrożeniach jest nieznajomość potrzeb firmy i niewłaściwe rozplanowanie etapów i zakresu wdrożenia... (Najczęściej popełniane błędy podczas wdrożenia ERP.). W projektach IT mamy jednak najczęściej tylko dwie strony: inwestor (nabywca oprogramowania) oraz wykonawca (dostawca oprogramowania i wdrożeniowiec, z reguły wystawia także kierownika projektu). Raport z 2011 roku na temat przyczyn niepowodzeń można podsumować tak: Ponad 80% projektów programistycznych ma przekroczone termin i budżet.…
