Wakacje sprzyjają filozofii. Tym razem kontynuacja opisanej tu niedawno książki Kotarbińskiego: Kurs logiki. Logika bardzo pomaga w analizie. Prawie trzy lata temu pisałem o Trzech zasadach logiki, jedna z nich  jest kluczem w analizie, to zasada wyłączonego środka. Brzmi ona:

jeżeli p to nie q

Można ją wyrazić prościej słowami: jeżeli coś jest czymś, to nie jest niczym innym.  Czemu jest tak ważna? Zobaczmy najpierw znaczenie słowa analiza (źr. sł. j.polskiego PWN, pominąłem chemiczne, trzecie znaczenie):

analiza 1. ?rozpatrywanie jakiegoś problemu, zjawiska z różnych stron w celu jego zrozumienia lub wyjaśnienia; też: wyjaśnienie lub opis, będące wynikiem takiego rozpatrywania? 2. ?metoda badawcza polegająca na wyodrębnieniu z danej całości jej elementów i badaniu każdego z osobna?

Analizując organizacje, w celu zrozumienia mechanizmu ich działania, tworząc raporty z takich analiz,  jesteśmy analitykiem w pierwszym znaczeniu tego słowa. Słownik cytowany powyżej mówi (pominąłem znaczenia z innych dziedzin):

model ?konstrukcja, schemat lub opis ukazujący działanie, budowę, cechy, zależności jakiegoś zjawiska lub obiektu?

Innymi słowy model to pewne uproszczenie rzeczywistości. Tworząc model analizowanej organizacji, tworzymy (dokumentujemy) opis jej działania. Wygodną metodą opisywania mechanizmu działania np. organizacji, jest jej model w postaci schematu opisującego zależności pomiędzy poszczególnymi jej elementami. Sformalizowane schematy tworzymy z pomocą notacji czyli sformalizowanych graficznych (schematy blokowe) języków opisu. Notacje takie nie raz tu opisywałem, są to stosowane w analizie biznesowej i projektowaniu, między innymi UML, BMM, BPMN, SysML, SBVR.

Do czego nam wspomniana na początku zasada wyłączonego środka? Przypomnę, że analiza to (drugie powyższe znaczenie) metoda badawcza polegająca na wyodrębnieniu z danej całości jej elementów i badaniu każdego z osobna.  Do prowadzenia analizy (wyodrębnianie elementów) stosujemy właśnie zasadę wyłączonego środka: jeżeli jakiś element organizacji jest czymś (i będzie reprezentowany na schemacie z pomocą określonego elementu notacji), to nie jest niczym innym. Otóż w toku analizy biznesowej opisujemy organizację z pomocą skończonej ilości elementów. W przypadku opisu organizacji za pomocą procesów biznesowych (proces biznesowy) sprowadzamy całą wiedzę o niej do prostej definicji procesu biznesowego. Jeżeli uznamy, że proces biznesowy to (w uproszczeniu) aktywność tworząca produkt, to znaczy, że aktywność nie tworząca produktu z zasady (zasada wyłączonego środka) nie jest procesem.  Takie podejście pozwala w toku analizy wykonać poprawny procesowy model organizacji ale też zapanować nad szczegółowością analizy i jej produktów.

Znowu sł. j. polskiego:

wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?

Analogicznie więc tworzymy obiektowe modele organizacji (model dziedziny jako wymagana logika działania), modele (specyfikacje) wymagań biznesowych (to czego oczekują interesariusze). Jeżeli wymaganie to cecha rozwiązania decydująca o jego przydatności, to znaczy, że wszystko to (opis), co nie decyduje o tej przydatności (nie jest warunkiem przydatności), nie jest wymaganiem. Podobnie postępujemy modelując rozwiązanie z pomocą tak zwanych przypadków użycia.

Celem tego – opartego na logice – podejścia jest usuwanie nadmiarowości i utrzymywanie zarazem kompletności i niesprzeczności dokumentu (w tym modelu).

W toku analiz wymagań często stosowane są metody polegające na wypytywaniu przyszłych użytkowników o wymagania. Jest to kompletnie nieprzydatne. Ludzie w potocznym języku nie stosują rygorystycznie logiki (:)), mają naturalną skłonność do zajmowania się nieistotnymi szczegółami i do pomijania ważnych a oczywistych rzeczy, o czym wiadomo od dawna (Kotarbiński, Logika):

Tak więc analityk, dla czystości analizy, powinien usuwać wszelką nadmiarowość, wprowadzającą zamieszanie, zaciemniającą obraz badanej sytuacji.

Często jednak widzimy, że rozwiązanie samo w sobie jest złożone, jak tu postąpić? Pogodzić się z tym, że nie jesteśmy w stanie rozsądnie opisać zbyt dużej złożoności, więc należy zmienić podejście: uprościć opis systemu do poziomu wystarczającego do naszego celu (wybór rozwiązania) i opisać go, ale nie, znanymi nam (oczekiwanymi) jego cechami (a mogą być ich tysiące), a skupić się na cechach istotnych i chcianych oraz niechcianych:

Np. cały złożony moduł finansowo-księgowy oprogramowania można opisać: “aplikacja nie może być niezgodna z obowiązującym prawem” i ewentualnie dodać jedynie to, jakie operacje planujemy wykonywać. Nie ma tu sensu opisywanie w szczegółach jak będą wykonywane. Inna metodą “walki” ze złożonością jest podział problemu na mniejsze (dekompozycja systemu).

Obecne oprogramowanie wspomagające zarządzanie jest bardzo złożone. Tak więc należy bezwzględnie odróżnić projektowanie takiego oprogramowanie (tysiące cech rozbudowanych systemów ERP, implementowanych wiele lat) od opisu potrzebnego rozwiązania, które planujemy kupić na rynku w postaci gotowej aplikacji.

Przeciętny samochód to ok. 10 tys. detali lub więcej. Samych jego cech i elementów, których potencjalnie możemy użyć jest tyle, że instrukcja obsługi samochodu osobowego to co najmniej książka średniej grubości. Mimo to dokonujmy wyboru nowego samochodu na podstawie kilku pożądanych cech i kilku niechcianych (np. między innymi chcemy by miał silnik benzynowy i nie chcemy by zużywał dużo paliwa).

Tak więc analiza, której wyniki mają np. skutecznie pomagać w wyborze nawet złożonych aplikacji, to nie wielkie i szczegółowe opisy, bo i tak mało kto (ktokolwiek?) je czyta. Skuteczne są opisy dość “skąpe”, ale “wystarczająco szczegółowe” by z małym ryzykiem wybrać spełniający wymagania i przydatny produkt. Są to opisy kompletne, niesprzeczne i spójne, ale ich stworzenie wymaga pełnego zrozumienia mechanizmu działania analizowanej organizacji. A zrozumienie to poprawny, przetestowany model (mechanizm) jej funkcjonowania.