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.
Wprowadzenie Temat wynagrodzeń i ich wysokości regularnie wraca do debaty publicznej. Dyskutowane są w przestrzeni publicznej wysokości wynagrodzeń, podatków, ustawowe wynagrodzenia minimalne itp. W artykule tym starałem się pokazać systemowe, oparte na faktach i dostępnych badaniach, podejście do tego tematu. Starałem się podać możliwe wyjaśnienie tego jakie to powinny być (mogły by być) kwoty, i dodać od siebie głos do tej debaty publicznej. Metoda W analizie tej bazuję tu na pojęciu wykonalności i idealizacji jako metody . W artykule na temat studium wykonalności pisałem: Studium wykonalności to analiza możliwości wykonania czegoś.…
Obydwa te, spotykane często w prasie, skróty mają wiele wspólnego: oznaczają aplikacje zarządzające obiegiem informacji i jej magazynowaniem (ECM - Electronic Content Management czyli zarządzanie treścią w postaci elektronicznej oraz EOD - Elektroniczny Obieg Dokumentów). Cechą zawartą "nie wprost" w tych nazwach jest zarządzanie także składowaniem i przepływem tej informacji. Osiem lat temu pisałem o kwestiach pojęciowych (czym jest wiedza, jej przetwarzanie, czym są dane): Problematyka informacji w firmach, jej kolekcjonowania i przetwarzania jest częstym tematem artykułów w prasie specjalistycznej jak i opisem zakresów projektów IT. Termin ten jest jednak…
Kolejna książka, tym razem coś w rodzaju podręcznika, zbioru metod. Jest to praca zbiorowa. Polecam wszystkim osobom, których rolą jest między innymi dokumentowanie architektury systemów IT. Wiele przykładów opartych o UML, SysML oraz planowany do upowszechnienia AADL (Architecture Analysis and Design Language). Ten ostatni jest w sferze planów, zobaczymy… (więcej…)
Narzędzie, którego używam od 2005 roku (rezygnując wtedy z MS Visio bo toporny i wyrzucając demo EA SPARX bo toporny i niezgodny z UML), staje się coraz lepsze. To co powoduje, że nadal nie planuję zmieniać narzędzia to mega ergonomia pracy, 100% zgodności ze specyfikacjami OMG, a przede wszystkim serwer pracy grupowej VPository, co razem daje mega platformę analityczno-komunikacyjną dla analityka i klienta.
W nowej wersji:
(więcej…)
Tym razem recenzje dwóch książek w jednym wpisie:
- Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
- Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens
Pierwsza wydana w 2005 roku, druga 2013 r. Pierwsza metodę ICONIX opisuje na przykładach, w kontekście zwinnych metod, proces projektowania i tworzenia oprogramowania bazujący na modelach. Są to:
- Model przypadków użycia specyfikujący wymagane zachowania aplikacji.
- Dziedzinowy model pojęciowy
- Model dziedziny (architektura).
- “Robustness diagram” abstrakcyjny model zachowania bazujący na jednoznacznych tylko biznesowych pojęciach (diagram komunikacji).
- Diagram sekwencji obrazujący zachowania się elementów architektury systemu w toku realizacji scenariuszy przypadków użycia.
(więcej…)
Łamanie reguł może doprowadzić do upadku firmy, łamanie prawa i konstytucji do upadku całych państw. Historia zna oba te przypadki.
Niemalże w każdym projekcie spotykam się z dokumentami w różnych formach. Bardzo często spotykam się także z problemami związanymi z ich użyciem w “realu” i ich reprezentacją zarówno w dokumentacji papierowej jak i elektronicznej. Samo pojęcie “dokument” potrafi być trudne do jednoznacznej interpretacji. Najpierw jednak proszę przeczytać ten niedługi artykuł na temat problemów z fotokopią Dowodu Osobistego (można przeczytać na koniec, po przeczytaniu tego wpisu).
Jeśli sądy uznają za zgodne z prawem wykonywanie kserokopii dokumentów tożsamości, to być może należałoby zmienić przepisy ? to odpowiedź Generalnego Inspektora Ochrony Danych Osobowych (GIODO) na praktykę stosowaną przez dużą część przedsiębiorców zawierających umowy z konsumentami. (Źródło: GIODO ukróci kserowanie dowodów osobistych. Trzeba zmienić przepisy – Prawo i wymiar sprawiedliwości – GazetaPrawna.pl – wiadomości, notowania, kursy, praca, emerytury, podatki –)
(więcej…)
Tak więc czytając czyjekolwiek opracowania, w szczególności analizy biznesowe i modele systemów, sprawdzajcie, czy ktoś nie umieścił tam analitycznych krasnoludków, kosmitów, dżinów itp. Takie byty na diagramach jak "aktor czas" czy "systemowy przypadek użycia", świadczą wyłącznie o tym, że autor po prostu nie poradził sobie z analizą, nie do końca odkrył istotę tego co analizował i opisał, nie zrozumiał tego co modeluje. Dodawanie nowych bytów do notacji jak najbardziej jest możliwe, ale po pierwsze należy to robić poprawienie ale potrzeba taka jest bardzo rzadka. W obszarze analizy i modelowania obecna postać BPMN wystarczy aż nadto, do modelowanie oprogramowania zorientowanego obiektowo UML tym bardziej wystarczy. Takie upstrzone "wynalazkami" dokumenty być może są atrakcyjne ale kompletnie nieprzydatne.
Od czasu do czasu spotykam się z analizami wymagań, powstałymi w dość spektakularny sposób. Jest to metoda zbierania wymagań "na procesy referencyjne" i nadal niestety ma wzięcie. Głównym powodem jest to, że nie wymaga żadnych umiejętności, może to zrobić każdy. W ostatnim roku spotkałem się z wynikami tego podejścia trzy razy. Wszystkie trzy spalone niestety... Dlaczego? Jednym z chyba najbardziej znanych zestawów procesów referencyjnych jest APQC. Tak piszą jego promotorzy o nim: APQC's Process Classification Framework?(PCF) is the most used process framework in the world. It creates a common language…
Wprowadzenie Bardzo często spotykam się z metodami wymiarowania oprogramowania, czyli mówiąc ludzkim językiem: oceny pracochłonności jego wytworzenia. Typowym argumentem za stosowaniem tych metod jest potrzeba planowania. Nie raz spotykam się z porównaniami do pomiaru powierzchni np. w budownictwie (cytat celowo ze strony stosownego stowarzyszenia): Wymiarowanie oprogramowania, ma podobne znaczenie, co wymiarowanie w innych dziedzinach inżynierii. Określa wielkość, pozwala na porównywanie różnych przedsięwzięć, szacowanie kosztów wytwarzania i lepsze planowanie. Punkty funkcyjne ? najbardziej popularna i promowana przez specjalistów jednostka wielkości oprogramowania, to przykładowo odpowiednik metrów kwadratowych w budownictwie. Wyobraźmy sobie tę…
Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania. Stosowane są trzy metody (grupy metod) specyfikowania wymagań: Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody). Specyfikowanie tak zwanej "czarnej skrzynki" (przypadki użycia). Specyfikowanie tak zwanej "białe skrzynki" (przypadki użycia + model dziedziny systemu). Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i…
W toku niejednej analizy można spotkać się z sytuacją gdy standardowe podejście polegające na badaniu dokumentów i analizie zstępującej (od ogółu do szczegółu, ang. top-down) może być trudne lub wręcz nie możliwe. Dotyczy to analizy systemów słabo udokumentowanych lub wręcz nieudokumentowanych, gdzie jedyne dostępne dane to obserwacja lub relacja obserwatora (uczestnika, itp. czyli relacja z drugiej ręki). Jest to sytuacja podobna to serii (pakietu) zebranych "user story" (w nomenklaturze metodyk zwinnych historyjki użytkownika), nieformalnych relacji. Jak ugryźć taką sytuację? Z pomocą przychodzi pojęcie specyfikacji instancji w UML, zapewne brzmi to…
