Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: wiedza ogólna bezpłatnie na blogu, mój czas dedykowany dla Twojej Firmy tu:
Dokumenty, które tworzę, maja strukturę typowej pracy naukowej, czyli składają się z następujących części:
Wprowadzenie: jak wygląda sytuacja, co jest problemem do rozwiązania (np. w danej organizacji), jak go stwierdzono, jakie fakty świadczą o tym, jaki jest cel.
Opis użytych metod.
Opis działania badanej organizacji, rekomendacje.
Opis rekomendowanego rozwiązania: projekt zmian organizacyjnych, opis (projekt) rekomendowanego oprogramowania, itp.
Opis dalszych prac i podsumowanie.
Rejestr wszelkich wyjaśnień udzielonych w kwestii treści dokumentu i jego rozszerzeń.
Zainteresowanych szczegółami zapraszam do dalszej lektury tego artykułu.
Krótko o metodzie naukowej
Dużo piszę na blogu o analizie wymagań opartej na modelach i analizie systemowej, jako podstawie metodyki prowadzenia analiz. Są to ogólnie tak zwane metody naukowe . Cechy tego podejścia:
Idealny, praktyczny model metody naukowej
Tradycyjnie, niezależnie od rozmaitych kwestii filozoficznych i społecznych, zazwyczaj przyjmuje się, że na metodę naukową składa się następujący zbiór czynności ?*?:
Obserwacje wstępne
Budowanie hipotezy
Wykonywanie rzetelnych eksperymentów weryfikujących hipotezę lub rzetelne zbieranie danych historycznych mających potwierdzić teorię lub jej zaprzeczyć
Przyjęcie lub odrzucenie hipotezy w oparciu o zebrane dane.
Powtarzanie procedury – czyli stała weryfikacja starych i budowanie nowych hipotez w momencie gdy stare przestają się sprawdzać.
Ponadto, wyniki badań naukowych poddane muszą być krytyce innych naukowców.
Jednym z podstawowych narzędzi metod naukowych, jest tak zwana idealizacja:
Idealizacyjna Koncepcja Nauki Punktem wyjścia idealizacyjnej koncepcji nauki było spostrzeżenie (1968, ss.80n., 1970a, 1971a […]), że wbrew indukcjonizmowi, nauki empiryczne nie uogólniają faktów empirycznych w prawa ? prawa mówią o gazach (rynkach, prawodawcach, itd.) doskonałych a fakty notorycznie wydarzają się gazom (rynkom, prawodawcom, itd.) dalekim od doskonałości, bo ?realnie istniejącym?. .
Idealizacja polega rozpoczynaniu wyjaśniania dokonanych obserwacji z użyciem minimalnego modelu. Model tej jest testowany kolejnymi faktami i rozszerzany jest o ile wymaga tego wyjaśnienie kolejnych faktów. Po kilku takich iteracjach model poddawany jest krytyce innych obserwatorów, może być dalej poprawiany lub uznany za poprawny (niepodważony). Na tym etapie uznajemy, że tak powstały model wyjaśnia obserwowane fakty: jest naukową teorią wyjaśniającą (metodologia nauk). Idealizacja, jako narzędzie, znalazła także zastosowanie na polu analiz biznesowych .
A co na naszym analitycznym podwórku?
Pojęcie model pojawia się w projektach analitycznych niemalże w 100% przypadków. Potocznie mówi się, że powstają modele procesów biznesowych, modele przypadków użycia, modele dziedziny systemu i wiele innych. Warto jednak wiedzieć, że co prawda modelem bywa nawet pojedynczy diagram (schemat blokowy), jednak jeżeli mówimy o modelu działania jakiejś organizacji (urząd, przedsiębiorstwo, inne) to jest on raczej bardziej złożony i przedstawiany jest na wielu różnych diagramach. Często stosowane jest pojęcie perspektywy modelowania, co znaczy, że tworzymy kontekstowy opis działania. Tak kontrastowość polega na pomijaniu jednych aspektów mechanizmu działania organizacji na korzyść innych.
Jeżeli opisujemy organizację z perspektywy kolejności realizowanych zadań i ich produktów abstrahując całkowicie od tego jakich narzędzi używają wykonawcy tych czynności, tworzymy model procesów biznesowych. Model taki pokazuje jakie zadania, i w jakim celu, są realizowane. Z tego powodu jest uzupełniany modelem reguł biznesowych (logika realizacji procesów) i modelem pojęciowym (jednoznaczność), tłumaczącym znaczenia pojęć użytych w tych modelach. Skoro są ludzie i używają narzędzi do pracy, pojawia się także potrzeba opisania tych narzędzi. Powodem jest zrozumienie tego jak działają i jak pomagają ludziom w realizacji ich zadań, część z nich służy do automatyzowania pewnych prac. Jednym z takich narzędzi jest oprogramowanie (aplikacja) a ich opis to albo dokumentacja aplikacji istniejącej, albo projekt planowanej do wykonania i dostarczenia.
Tu pojawia się zadanie: zrozumieć jak działa organizacja i zaprojektować narzędzie, które będzie pomagało w zadaniach jakie ona realizuje. Rzecz w tym, że oprogramowanie jako narzędzie nie jest zamawiane jako „coś czego wymaga organizacja” a jako „coś co wesprze jej działanie”, narzędzie stanowiące „rozwiązanie” problemu jaki chce rozwiązać zamawiający.
Gdzie tu miejsce na naukowe metody? Mamy dwa zadania do wykonania:
opracować model działania organizacji czyli opracować teorią wyjaśniającą to, co się w niej dzieje,
opracować projekt rozwiązania czyli zbudować mechanizm działania narzędzia, które umieszczone w tej organizacji, rozwiąże problem opisany przez zamawiającego; to narzędzie może być zrealizowane jako oprogramowanie.
Potocznie pierwszy etap nazywany jest Analizą biznesową drugi to Projektowanie logiki oprogramowania. Przyjmując, że stosujemy naukowe podejście, najpierw tworzymy model organizacji a potem model logiki potrzebnego jej oprogramowania (teorie mówiące, że tak to działa), testujemy je i uznajemy za poprawne, jeżeli nie udało ich podważyć. Na tym blogu znajdzie opis takiego procesu pod nazwą MDA. Jednak jeżeli naukowo to opieramy się wyłącznie na faktach (czyli nie prowadzimy wywiadów a analizujemy dokumenty).
Po kolei:
obserwacje to analiza tego co i jak się w firmie dzieje (analiza faktów czyli dokumentów, wywiady tylko w ostateczności),
budowanie hipotezy to tworzenie modelu logiki działania (procesowego, obiektowego) tej firmy,
eksperymenty to testowanie modeli poprzez sprawdzanie czy są jakieś fakty w organizacji, których nie potrafimy wyjaśnić naszym modelem,
przyjęcie lub odrzucenie i „naprawa” hipotezy czyli ulepszanie modelu (jeśli był wadliwy).
Moje projekty to nic innego jak konkretne powstałe specyfikacje wymagań na oprogramowanie stanowiące sobą tak na prawdę modele mechanizmu działania. Spełnienie wymagań to zgodność zachowania oprogramowania z opisanym (wymaganym) mechanizmem, zgodność tę sprawdzamy testami.
Na koniec o tym czym jest hipoteza:
Hipoteza – osąd, teoria, która nie znalazła jeszcze potwierdzenia w faktach, lub w przypadku hipotez matematycznych nie została jeszcze poprawnie udowodniona. Stawianie i testowanie hipotez to jeden z podstawowych procesów twórczego myślenia oraz fundamentalny element procesu tworzenia nauki.
(źr. cytatów Metoda naukowa).
Tak więc, skoro oprogramowanie w swej centralnej części zawiera Model (patrz wzorzec MVC) logiki biznesowej, to znaczy, że należy najpierw (1) zrozumieć jak działa ta organizacja i udokumentować jej model działania, (2) podjąć decyzję który obszar działania organizacji ma być wspierany nowym oprogramowaniem, i która część jej modelu działania ma być zaimplementowana w oprogramowaniu, (3) wykonać implementację.
User Story to co najwyżej materiał badawczy a Przypadki użycia to zakres projektu. Kluczem jest zrozumienie mechanizmu działania, tak jak prawa fizyki są tym co tłumaczy działanie nawet prostego młotka…
Jeżeli ktoś uważa, że zapis z obserwacji zachowania się organizacji może stanowić wymaganie dla inżyniera, to tak jak by uznał, że zapis obserwacji zachowania się samochodu i jego kierowcy może stanowić wystarczający materiał do wyprodukowania skrzyni biegów…
Teorie, które nie mogą być przetestowane, bo np. to co opisują nie jest obserwowalne, nie kwalifikują się jako teorie naukowe. Przykłady:
Księżyc zasiedlają Małe Zielone, których ani nie można zobaczyć, ani złapać ? ŹLE
Na Księżycu nie ma Małych Zielonych ? DOBRZE, łapiąc jednego można sfalsyfikować hipotezę
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: creating an organization’s future. Wharton School Pub.
Popper, K. R. (2002). Logika odkrycia naukowego (U. Niklas, Trans.). Fundacja Aletheia.
Subbotin A.L. (1970). Idealization as a Method of Scientific Knowledge. In Tavanec P.V. (eds) Problems of the Logic of Scientific Knowledge. Synthese Library.
Wheeler, B. (2018). Idealization and the Laws of Nature. Springer.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based software engineering and systematic reviews. CRC Press.
Nola, I. R., & Sankey, H. (n.d.). HARD PROBLEMS IN THE PHILOSOPHY OF SCIENCE: IDEALIZATION AND COMMENSURABILITY. 20.
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
polecam krótką prezentację: metoda naukowa