“Nic nie jest tak praktyczne jak dobra teoria.” (KURT LEWIN)

Struktura analizy

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:

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:

1. opracować model działania organizacji czyli opracować teorią wyjaśniającą to, co się w niej dzieje,
2. 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ę

Polecam także źródłowy wykład: metoda naukowa.

(źr. http://www.home.umk.pl/~mwojc/wyklady_Teren/metoda%20naukowa.pdf)

Podsumowanie

Analizując firmę niczego nie tworzymy. Analizując firmę zbieramy dane by zrozumieć i udokumentować mechanizm jej działania. To jest analiza. Dokument, który powstaje jako wynik analizy to nie jest dzieło czy utwór, to jest opis, to jest know-how tej firmy. Wyzwaniem jest zrozumieć całość i udokumentować w sposób jednoznaczny, tak by opis tłumaczył to co obserwujemy: dlatego to co powstaje to model działania organizacji. Model wyrażamy w sformalizowanej graficznej postaci, bo inna jest niejednoznaczna i nietestowalna. To udokumentowane know-how firmy.

Czym są wymagania na oprogramowanie? Wymagania na oprogramowanie to wybrany fragment tego modelu, przeznaczony do odtworzenia z pomocą komputera. Może to być wyłącznie przetwarzanie danych i sterowanie, bo komputer niczego więcej nie jest w stanie zrobić. Ten dokument to Twoje prawa do oprogramowania.

Wykonany kod źródłowy (maszynowy) dla komputera to jedynie procedury wyrażone w wybranym języku programowania, odwzorowujące ten model. To Twój kod. Jako ludzie używamy komputera.

Jeżeli jakiś obszar firmy, mechanizm jego działania, jest zdeterminowany prawem, normą, czy uznanymi dobrymi praktykami, można w nim zastosować standardowe rozwiązania, jeśli takie znajdziemy.

Całość należy zintegrować, utrzymywać i rozwijać.

Żródła