1

Analiza systemowa jako metoda analizy i projektowania

"Jeżeli mam godzinę na rozwiązanie problemu, 55 minut myślę o problemie a 5 minut o jego rozwiązaniu" (Albert Einstein)

  • Produkt: zobiektywizowane i sformalizowane opracowanie wykonane otwartymi, nie chronionymi patentami, metodami poddającymi sie audytom.
  • Korzyść: brak metodycznego uzależnienia od autora opracowania, możliwość przekazania kontynuacji pracy innej osobie.
  • Koszt szkoleń i konsultacji: szkolenia zamknięte dla zespołów z jednej firmy: 5 tys. netto jeden dzień. Konsultacji dotyczących metod i notacji udzielam bezpłatnie pod treścią opublikowanych artykułów na blogu (więcej na stronie Szkolenia).

Wprowadzenie

Bardzo popularną metodą prowadzenia analiz są spotkania, wywiady i warsztaty. Czy to skuteczne? Wywiady i warsztaty z pracownikami badanej organizacji dadzą informacje o tym, jak oni sobie wyobrażają to co robią. Wynikiem analizy są spisane wyobrażenia, nie raz bardzo dalekie od rzeczywistości. Na tej podstawie nie da się zaprojektować i wdrożyć adekwatnego do potrzeb organizacji systemu. Jak inaczej? Oprzeć się na faktach (dowodach). To analiza dokumentów, a nie rozmowy, da obraz tego jak organizacja działa na prawdę. Dlatego w toku analizy stosuję metody oparte na faktach i modele opracowane naukowymi metodami .

Możesz od razu czytać dalej, ale możesz też najpierw zapoznać się z opisem: Projekt aplikacji – przykład, a potem czytać dalej ten artykuł, by dowiedzieć się dlaczego ten projekt tak wygląda. Możesz też doczytać ten artykuł do końca a potem zapoznać się z tym przykładem.

Orientacja na fakty

Dokumenty operacyjny to pisma klientów, oferty, faktury, zamówienia, umowy, zarządzenia. Ich uzupełnieniem są obowiązujące akty prawne dotyczące realizowanej analizy. Razem stanowią sobą tak zwane artefakty (artifact-centric paradigm, ). Zawierają one efekty pracy ludzi, informacje jakich potrzebują i te jakie tworzą, wszelkie istotne regulacje. To są fakty z życia organizacji. Badanie dokumentów, czyli nośników informacji, to najskuteczniejsza obecnie metoda analizy . Praca w oparciu o takie dokumenty pozwala także na przeprowadzenie projektu analitycznego w 100% zdalnie.

Przekaż mi dokumenty operacyjne, a ja oddam ci dokument opisujący to, jak na prawdę działa Twoja organizacja

"Każda firma, niezależnie od tego, jakie fizyczne towary lub usługi wytwarza, opiera się na dokumentacji handlowej. Musi ona zapisywać szczegóły tego, co wytwarza w postaci konkretnych informacji. Artefakty biznesowe są mechanizmem zapisu tych informacji w jednostkach, które są konkretne, identyfikowalne, samoopisujące się i niepodzielne."

https://ieeexplore.ieee.org/abstract/document/5386806

"W ciągu ostatnich kilku lat, coraz większe wymagania stawiane są efektywnym podejściom do projektowania, modelowania i wdrażania międzyorganizacyjnych procesów biznesowych. W procesie współpracy ponad granicami organizacyjnymi, organizacje nadal pozostają autonomiczne, co oznacza, że każda z nich może dowolnie modyfikować swoje wewnętrzne operacje, aby osiągnąć swoje prywatne cele, jednocześnie spełniając wzajemne cele swoich partnerów. Ostatnio udowodniono, że modelowanie procesów skoncentrowane na artefaktach zapewnia większą elastyczność w modelowaniu i realizacji procesów niż tradycyjne metody modelowania skoncentrowane na działaniach."

https://www.sciencedirect.com/science/article/abs/pii/S0306437914001264

Dlatego od wielu lat z powodzeniem stosuję metody prowadzenia audytu i analizy oparte na dowodach (artifact-centric paradigm, evidence-based analysis), są to także w inżynierii oprogramowania, metody opierające się przede wszystkim na faktach, wywiady są jedynie ewentualnym uzupełnieniem .

Od wielu lat, z powodzeniem, analizy i projektowanie realizuję zdalnie, dając jako produkt w pełni obiektywny obraz badanej organizacji.

Idealizacja jako metoda projektowania

Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm. (Craver & Tabery, 2019)

Nadal bardzo często spotykam się z oczekiwaniem tworzenia modeli as-is i to-be. Ma to pomóc podjąć decyzję o planowanych zmianach. Tworzenie dwóch modeli to dodatkowa praca i czas. Detaliczna analiza stanu obecnego, tylko po to by zdecydować czego zaniechać to dodatkowa praca, zaś decydowanie "dzisiaj" o tym czego nie chcemy "jutro", jest przysłowiowym "wróżeniem z fusów". To typowe, od lat krytykowane, podejście zwane "water-fall".

Modele

"Podstawowym celem modelowania jest danie sobie okazji do myślenia przed podjęciem działania" (Scott Ambler)

Analiza i projektowanie oparte na idealizacji nie wymaga modeli as-is

Czasy obecne to zmiany na rynku zachodzące w skali miesiąca a nie dekady. Oznacza to, że analiza, bez względu na wielkość projektu, powinna trwać co najwyżej kwartał a dalszy ciąg projektu to cykl życia systemu zamiast wymagań. Rozwiązaniem problemu ograniczonego czasu jest skupienie się na audycie organizacji, którego celem jest opracowanie jej idealizacji czyli wizji przyszłego jej idealnego funkcjonowania. W efekcie mamy ściśle wyznaczony kierunek rozwoju i wdrażania nowych technologii, np. informatycznych, i nie tracimy czasu na dokumentowanie tego co zostanie odrzucone. Dokumentujemy na bieżąco tylko co co przybliża nas do celu .

Notacje jako metody analizy i dokumentowania

"Do korekty możesz użyć gumki na etapie modelowania, lub młota kowalskiego na etapie budowania". Frank Lloyd Wright (parafraza)

Wykorzystuję wyłącznie otwarte standardy i notacje oraz metody nie wymagające opłat licencyjnych. Dzięki czemu dokumenty, które przekazuję jako produkty swojej pracy, są w 100% możliwe do dalszego, samodzielnego użytku.

Dość powszechne w firmach, używanie licencjonowanych lub opatentowanych metod pracy i narzędzi powoduje, że beneficjent takiej usługi staje się niewolnikiem usługodawcy. Jeżeli metody pracy są dodatkowo utrzymywane w tajemnicy jako tajemnica usługodawcy, nie jest możliwe sprawdzenie czy usługa została wykonana należycie.

W artykule Metoda naukowa w analizie biznesowej w 2011 roku opisałem czym jest metoda naukowa. Poniżej usystematyzowany opis sposobu prowadzenia audytów i analiz uzupełniony literaturą źródłową.

Fundamentem metod jakie stosuję są modele: proste i skomentowane, sformalizowane schematy blokowe, zrozumiałe dla adresata. W efekcie analiza i komunikacja polega na: pozyskiwaniu materiałów o organizacji analizowanej, tworzeniu modeli opisujących tę organizację, oraz recenzowaniu ich przez osoby z analizowanej organizacji. Jest to skuteczna metoda analizy i modelowania działania organizacji .

[Jeżeli interesuje Cię mniej techniczny a bardziej biznesowy opis, przejdź teraz na stronę: Analiza, wymagania i usprawnianie organizacji.]

Struktura produktu analizy systemowej

Celem analiz systemowych nie jest tworzenie ogromnej i kosztownej dokumentacji, jest nim tworzenie modeli i opracowanie rekomendacji w postaci możliwie zwięzłego opracowania.

Analiza organizacji nie powinna się opierać na subiektywnych relacjach jej pracowników, powinny być oparte w 100% na faktach. Relacje mogą być ich uzupełnieniem . Dlatego stosuję metody analizy bazujące całkowicie na dostarczanych dokumentach i autoryzowanych opisach, wywiady są jedynie uzupełnieniem tak pozyskanej wiedzy. Cała analiza oparta jest na kolekcjonowaniu faktów (prawo, regulaminy wewnętrzne, dokumenty operacyjne i ich szablony, wyniki audytów technicznych i ekspertyz, przekazywane przez zamawiającego w formie pisemnej). . Tak prowadzona analiza i jej efekty, są w maksymalnie możliwym stopniu obiektywne i wolne od subiektywnych ocen pracowników organizacji analizowanej.

Podstawowe pytania w analizie systemowej to: "jak jest i dlaczego jest tak jak jest" oraz "jak powinno być i co należy uczynić, aby było tak jak być powinno" , modelowanie zaś to narzędzie a nie cel .

Dlatego analizy, które realizuję składają się z etapu badania i modelowania organizacji oraz analizy tych modeli i opracowania rekomendacji. Jedną z możliwych rekomendacji może być opis rekomendowanego rozwiązania np. w postaci wymagań na oprogramowanie.

Proces analizy systemowej
Proces analizy systemowej: analiza sytuacji, sformułowanie problemu, badanie, opracowanie modeli, interpretacja i testy modeli, powtórzenie procedury lub publikacja wyników. ,

Model pojęciowy jako narzędzie

Pierwszym i kluczowym etapem pracy jest analiza pojęciowa dziedziny problemu. Tworzenie modeli pojęciowych jest podstawowym etapem badania spójności treści i wyników każdej analizy i opisu rozwiązania. Model pojęciowy (przestrzeń pojęciowa, ang. namespace) to słownik kluczowych pojęć badanej dziedziny oraz wrażona graficznie ich struktura, obrazująca związki między tymi pojęciami: taksonomia i związki syntaktyczne, pozwalająca zagwarantować spójność i niesprzeczność nazewnictwa zastosowanego w toku analizy i dokumentowania jej wyników. . Proces analizy pojęciowej opisuje . poniższy diagram :

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011
M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011

Określenie problemu

Pierwszym etapem jest sformułowanie problemu badawczego czyli określenie przyczyny i celu prowadzenia analizy. W sformalizowanej formie, także graficznej efekty tego etapu są dokumentowane jako Model Motywacji Biznesowej . Kluczowymi elementami tego modelu są wizja i misja firmy oraz strategia i cele biznesowe wyrażone określoną wartością i jej miarą.

Model organizacji

Jakiekolwiek rekomendacje, jeżeli mają być świadome i poparte dowodem ich poprawności, muszą być poprzedzone zrozumieniem i udokumentowaniem mechanizmu działania organizacji.

Do opisu mechanizmu działania organizacji stosujemy sformalizowane modele wyrażone jako Architektura Biznesowa (modele procesów biznesowych, reguły biznesowe, modele infrastruktury IT i mapowanie procesów na oprogramowanie, struktury dokumentów w procesach). .

Model procesów biznesowych pokazuje, jakie zadania są wykonywane w ramach procesów i w jakiej kolejności, oraz produkty tych zadań. Zawiera informacje na temat ich wykonawców, dokumentów wykorzystywanych i tworzonych w ramach procesu, ich treści, zasobów niezbędnych do realizacji procesu (w tym systemów IT), może zawierać opisy wskaźników KPI (Key Performance Indicators) . (opis tego etapu w dokumencie Analiza i opracowanie architektury biznesowej).

Wszystkie elementy modelu organizacji powstają i są kontrolowane, jednocześnie, gdyż zbierane materiały źródłowe rzadko kiedy są uporządkowane. Kolejne, iteracyjnie uzgadniane, wersje prowadzą do powstania ostatecznego Raportu z Analizy zawierającego opis organizacji od ogółu do szczegółu j.w. oraz wymagania na rekomendowane rozwiązanie.

Rekomendowane rozwiązanie

Na bazie powstałej Architektury Biznesowej, opracowywane są rekomendacje do zmian wyrażone jako projekt rozwiązania, stanowią wymagania dla dostawcy rozwiązania (patrz opis: Wymagania na oprogramowanie). .

Realizacja

Po zawarciu umowy z dostawcą rozwiązania, wspieram organizację prowadząc nadzór autorski, który polega na bieżącym aktualizowaniu dokumentacji opisującej model organizacji i rozwiązania. W dniu zakończenia wdrożenia stanowi on aktualną dokumentację uzyskanego efektu.

Dlaczego metoda naukowa?

Celem nauki jest obserwacja faktów i zrozumienie mechanizmu ich powstawania, celem inżynierii jest tworzenie konstrukcji wykorzystujących odkryte mechanizmy

Opisany powyżej proces to klasyczna analiza systemowa . Jest to zastosowanie zasad nauki do projektów biznesowych.

Analiza systemowa to proces naukowy, oparty na analizie faktów, stosowany w projektach o podwyższonym ryzyku (a projekty informatyczne do takich należą,  ponad 70% tych projektów to niestety projekty nieudane). Podejście systemowe wymusza systematyczną i logiczną analizę realizowanych przez przedsiębiorstwo działań, stosując oparte na modelach podejście, pozwala zrozumieć stan obecny i jego przyczyny. Dzięki temu wyniki analiz systemowych są obiektywne.

Nauka to nie tylko, encyklopedyczne gromadzenie wiedzy, to metodyczne badania dziedziny, będącej przedmiotem zainteresowania. 

Nauka nie polega bowiem na gromadzeniu informacji, choćby ciekawych i pożytecznych, ale na rozwiązywaniu zagadnień .

Bardzo wiele książek zaliczanych do opracowań naukowych, powołuje się w pierwszych rozdziałach na znaczenia pojęć, gdzie zwraca się uwagę na to, że nauka to badania dążące do odkrywania prawa zaś inżynieria to tworzenie (rozwiązań) na bazie wiedzy o tych prawach

W toku pracy badawczej określane są warianty (scenariusze) rozwiązania problemu. Aby wskazać (zarekomendować) wybrany wariant, opracowywany jest model organizacji (model jest testowany na zgodność z faktami). Na bazie modelu prowadzone są analizy wariantów, na bazie wyników tych analiz powstają rekomendacje. Mogą nimi być: zalecenia reorganizacji, zalecenia wdrożenia nowych technologii, wymagania na rekomendowane rozwiązanie informatyczne, itp. Wynik analizy ma postać opracowania  naukowego: streszczenie, wprowadzenie (opis problemu), użyte metody, opis rezultatów, opis procesu ich powstawania, bibliografia.

(więcej o metodzie naukowej z artykule: Metoda naukowa w analizie biznesowej)

Orientacja na modele: MBSE

Proces analizy i modelowania jest znacznie mniej kosztowny, w porównaniu z metodami opartymi na "praktyce", czyli prototypowaniu decyzji we własnej organizacji.

(źr. )

Projektowanie to proces prowadzący od sformułowania problemu do powstania wdrożenia rozwiązania:

Orientacja na modele (Model Driven Engineering, ) pozwala zarządzać złożonością projektów, panować nad ich zakresem, a kolejne fazy, będąc wynikiem śladowania czyli wywodzenia jednym modeli z drugich (transformacje) pozwalają stale testować poprawność koncepcji całego rozwiązania i projektu .

Standardowo stosuję notacje BMM, BPMN, SBVR i UML . Kluczowy etap to opracowanie przestrzeni pojęciowej (namespace) czyli dziedzinowego słownika pojęć. Na jego podstawie tworzony jest profil pojęciowy dla wszystkich schematów blokowych. Następnie tworzone sa modele opisujące działanie analizowanego i projektowanego systemu - wyrażone jako schematy blokowe i scenariusze testujące opracowane modele.

Istotnym elementem modelowanych organizacji są dokumenty: ich struktury i zawartość oraz reguły kontroli poprawności (system informacyjny organizacji). Obecnie są one z zasady są modelowane jako struktury XML.

Większość organizacji to złożone systemy ludzi i informacji mające stałe interakcje z otoczeniem. Są to więc także bardzo złożone modele (wiele elementów i wiele połączeń między nimi). Budowanie wielkich i szczegółowych schematów blokowych jest nieefektywne komunikacyjnie: ich zrozumienie jest trudne a dla większości ludzi po protu niemożliwe. Dlatego dokumentacje systemu opracowuje się jako zestaw wielu relatywnie prostych diagramów, stanowiących tak zwane perspektywy, czyli proste opisy ukierunkowane na jeden określony kontekst:

Poniżej prosty diagram, który obrazuje opisane podejście jako całość:

Można to podsumować tak:

Analiza systemowa organizacji to proces prowadzący do zrozumienia tego jak działa analizowana organizacja. Powstały w toku tej analizy model opisujący tę organizację, to teoria wyjaśniająca zachowanie się organizacji i to jak ona na prawdę funkcjonuje. Mając taki model można przewidywać skutki planowanych zmian.

Na zakończenie...

(źr. Martin Fowler, Analysis Patterns, 1997)

Możesz teraz zapoznać się z opisem: Projekt aplikacji – przykład.

    Zapytanie Ofertowe

    Chcę być informowany o nowościach na stronie firmy IT-Consulting.pl

    Źródła


    Ackoff, R. L. (1999). Ackoff’s best: his classic writings on management. Wiley.
    Ackoff, R. L. (1967). Management misinformation systems. Management Science, 14(4), B–147.
    Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
    Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: creating an organization’s future. Wharton School Pub.
    Arlow, J., & Neustadt, I. (2004). Enterprise patterns and MDA: building better software with archetype patterns and UML. Addison-Wesley.
    Bertalanffy, L. van. (2003). General system theory: foundations, development, applications (Rev. ed., 14. paperback print). Braziller.
    Borshchev, A., & Filippov, A. (2004). From system dynamics and discrete event to practical agent based modeling: reasons, techniques, tools. Proceedings of the 22nd International Conference of the System Dynamics Society, 22.
    Bridgeland, D. M., & Zahavi, R. (2009). Business modeling: a practical guide to realizing business value. Morgan Kaufmann/Elsevier.
    Bronk, A. (2006). Metoda naukowa. Nauka, 47–64.
    Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://plato.stanford.edu/entries/science-mechanisms/
    Dyba, T., Kitchenham, B. A., & Jorgensen, M. (2005). Evidence-based software engineering for practitioners. IEEE Software, 22(1), 58–65. https://doi.org/10.1109/MS.2005.6
    Forward, A., & Lethbridge, T. C. (2008). A taxonomy of software types to facilitate search and evidence-based software engineering. Proceedings of the 2008 Conference of the Center for Advanced Studies on Collaborative Research Meeting of Minds - CASCON ’08, 179. https://doi.org/10.1145/1463788.1463807
    Fowler, M. (1997). Analysis patterns: reusable object models. Addison Wesley.
    Hamdani, A., & Abdelli, A. (2019). Towards modelling and analyzing timed workflow systems with complex synchronizations. Journal of King Saud University - Computer and Information Sciences, S131915781930182X. https://doi.org/10.1016/j.jksuci.2019.08.007
    Kamiński, S. (1919-1986). (1981). Pojęcie nauki i klasyfikacja nauk / Stanisław Kamiński. Oddział Zbiorów Cyfrowych. https://dlibra.kul.pl/dlibra/publication/33792/edition/31624
    Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based software engineering and systematic reviews. CRC Press.
    Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
    Koźmiński, A. K. (1979). Decyzje: analyza systemowa organizacji. Pánstwowe Wydawn. Naukowe.
    Kreuter, T., Scavarda, L. F., Thomé, A. M. T., Hellingrath, B., & Seeling, M. X. (2021). Empirical and theoretical perspectives in sales and operations planning. Review of Managerial Science. https://doi.org/10.1007/s11846-021-00455-y
    Nigam, A., & Caswell, N. S. (2003). Business artifacts: An approach to operational specification. IBM Systems Journal, 42(3), 428–445. https://doi.org/10.1147/sj.423.0428
    OMG.org. (2014, January). Business Process Model and Notation (BPMN). https://www.omg.org/spec/BPMN/
    OMG.org. (2015, April). Business Motivation Model (BMM). https://www.omg.org/spec/BMM/
    OMG.org. (2017, December). Unified Modeling Language (UML) [OMG.org]. UML. https://www.omg.org/spec/UML/
    OMG.org. (2014, June 18). Model Driven Architecture (MDA). https://www.omg.org/mda/
    Paul, D. (2013). Business analysis.
    Popper, K. R. (2002). Logika odkrycia naukowego (U. Niklas, Trans.). Fundacja Aletheia.
    Reynolds, C. (2010). Introduction to business architecture. Course Technology PTR.
    Ross, R. G. (2013). Business rule concepts: getting to the point of knowledge (4th Ed). Business Rule Solutions.
    Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323–330. https://doi.org/10.5220/0007978003230330
    Sienkiewicz, P. (1994). Analiza systemowa: podstawy i zastosowania. Wydaw. Bellona.
    Sobczak, A. (2009). Wstęp do Architektury Korporacyjnej (B. Szafrański, Ed.). Wojskowa Akademia Techniczna.
    Thalheim, B. (2019). Models for Communication, Understanding, Search, and Analysis. Data Analytics and Management in Data Intensive Domains: ХХI In-Ternational Conference DAМDID/RCDL’2019 (October 15–18, 2019, Kazan, Russia): Conference Proceedings. Edited Bу Alexander Elizarov, Boris Novikov, Sergey Stupnikov.–Kazan: Kazan Federal University, 2019.–496 р., 19.
    Thalheim, B. (2011). The science of conceptual modelling. International Conference on Database and Expert Systems Applications, 12–26.
    Thalheim, B. (n.d.). Models, To Model, and Modelling - Towards a Theory of Models, especially Conceptual Models and Modelling - Second Collection of Recent Papers (2015-2017). Retrieved February 25, 2020, from https://www.academia.edu/34982400/Models_To_Model_and_Modelling_-_Towards_a_Theory_of_Models_especially_Conceptual_Models_and_Modelling_-_Second_Collection_of_Recent_Papers_2015-2017
    van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23-24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-19680-5
    Yongchareon, S., liu, C., Yu, J., & Zhao, X. (2015). A view framework for modeling and change validation of artifact-centric inter-organizational business processes. Information Systems, 47, 51–81. https://doi.org/10.1016/j.is.2014.07.004
    Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78–89). IGI Global. https://www.igi-global.com/book/applications-approaches-object-oriented-software/235699

    Aktualizacja: lip 4, 2022 @ 12:35