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.
MDA Development Sequence (źr. Business Process Trend Newsletter, Maj 2004 nr. 5)
Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że "nie święci garnki lepią") dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi "projektowania" czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.
Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:
Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: "wiedza organizacji" tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).
Według Forrester zmieniający się porządek zapotrzebowania na specjalistów IT wynika głównie z trzech rzeczy: Coraz większa popularność różnych technologii i rozwiązań jak np. SaaS (Software -as-a-service) bądź Business Intelligence, które…
Ponad 80% projektów programistycznych ma przekroczone termin i budżet. Największą trudnością w tych projektach okazało się jasne zrozumienie tego, czego tak naprawdę klient potrzebuje, oraz udokumentowanie jego wymagań. Do przechowywania wymagań użyty był głównie word i excel oraz email. Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. ( 2011 State of Requirements Management Report.)
Jak widać brzmi znajomo z dwóch powodów: problemy znane każdemu i powody niestety także. Ciśnie mi się na usta "a nie mówiłem"...
Czyli jednak wiemy że problemem projektów z zakresu inżynierii oprogramowania są zbyt proste metody i narzędzia zarządzania wymaganiami (pakiet biurowy), które w większości są stosowane. Wiemy, że modelowanie jest najskuteczniejsza metodą analizy i projektowania a mimo to nie stosuje się tych metod szukając stale "drogi na skróty".
Dlaczego dostawcy oprogramowania nie stosują metod powszechnie jednak uznawanych za skuteczne?
Jak widać, można wskazać wiele korzyści z CC. Przede wszystkim model opłaty może być za gotowość, za realne wykorzystanie lub na innej zasadzie. Nie ma tu mowy o licencjach, jest mowa o wykonanej pracy.
Problemem jest tu ocena czy danej firmie w ogóle CC pomoże, a jeśli tak to gdzie. Decydowanie się na CC nie powinno być efektem zauroczenia treścią np. takiej jak ta konferencji. Nie powinno być też emocjonalną decyzją po wysłuchaniu wizji dostawców takich usług.
Skoro CC to jednak architektura, proponuję kolejność następującą:
analiza biznesowa (cel projektu),
analiza wymagań,
projekt architektury systemu,
decyzja, które komponenty system możliwe są do kupienia, a które należy potraktować jako zasób zewnętrzny (cudzy).
Osobiście nie polecam podejścia polegającego na znalezieniu "fajnego" komponentu i zastanawianiu się gdzie go u siebie upchać. To często spotykany przypadek, w którym "coś nam sprzedano". Polecam rzetelne, pragmatyczne spojrzenie biznesowe, kończące się tym, że znajdziemy i kupimy od kogoś coś, co jest nam potrzebne i przyniesie korzyści, także finansowe.
A co mówią statystyki?
Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com).
Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych... Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających "kastomizacji" bo to (nowe funkcjonalności systemu) także projekt dedykowany.
