Brzytwa Ockhama (nazywana także zasadą ekonomii lub zasadą ekonomii myślenia) ? zasada, zgodnie z którą w wyjaśnianiu zjawisk należy dążyć do prostoty, wybierając takie wyjaśnienia, które opierają się na jak najmniejszej liczbie założeń i pojęć. Tradycyjnie wiązana jest z nazwiskiem Williama Ockham
Od czasu do czasu spotykam się w projektach z pojęciem "cynefin". Najpierw typowy opis z jakim można się zetknąć w sieci: Cynefin jest swoistą teorią, którą można wykorzystać do opisu działania skomplikowanych systemów takich jak różnego rodzaju przedsięwzięcia czy nawet relacje i problemy międzynarodowe. Jako model tłumaczy i próbuje pomóc w wyborze strategii działania, wskazując jednocześnie wzorce postępowania, które powinny być zdecydowanie inne w zależności od tego w jakiej sytuacji się znajduje się firma. W praktyce można korzystać z Cynefin jako narzędzia wspierającego zarządzanie projektem, zespołem lub nawet organizacją. Od…
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.
Dzisiaj co nieco o filozofii i przypadkach użycia. Dzielenie przypadków użycia na "rodzaje" zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojęcie: "przypadek użycia systemu", gdzie systemem jest coś (przedmiot opisu), czyli "analizowany/modelowany system" (patrząc na system w rozumieniu teorii systemów, tu zwracam uwagę na fakt, że UML to nie tylko IT). Wobec tego skoro system (wymiennie "przedmiot zainteresowania", "przedmiot analizy"), zanim będzie rozpatrywany, musi być określony (granice systemu, który jest częścią "nad" (super) systemu, a składa się z podsystemów, polecam Sienkiewicz, Teoria Systemów), otrzymamy prostą rzecz: przypadek…
osobiście i bardzo subiektywnie uważam, że nawet jeśli dowolną kupę mało spójnego tekstu rozłożymy na wiersze i kolumny dowolnej ilości tabel (to się czasem nazywa czasem nadawaniem tekstowi struktury) to taki tekst nadal będzie mało spójny. Przypadki użycia jako tabelaryczna forma zapisu "user story" lub wymagań funkcjonalnych, nie uzyskają spójności poprzez sam fakt ich stabelaryzowania. Przypadki użycia zaś jako efekt analizy całości zachowań i świadomego wyboru części z nich to jest dopiero spójny i kompletny opis wymagań. Bo jak to ktoś powiedział: kompletna lista najładniejszych kobiet w danym mieście to nie lista spotkanych ładnych w ostatnim miesiącu a lista wybranych spośród wszystkich w tym mieście. Taka lista ma sens bo nie grozi nam to, ze następnego dnia w tym mieście spotkamy inna ładniejszą.
Jeżeli ktoś Ci przyniesie specyfikację przypadków użycia do systemu i nie będzie potrafił jednoznacznie odpowiedzieć na pytanie dlaczego jest ich akurat tyle a nie np. jeden mniej lub dwa więcej albo dlaczego akurat te a nie inne, to najprawdopodobniej znaczy to, że podczas wdrożenia na pewno "spotkasz kilka innych ładniejszych kobiet".
Dlatego hurtownie danych i tak zwane systemy Business Inteligence, wszelkie systemy wspomagania decyzji, to albo analiza historii albo prognozowanie oparte na modelach. Owszem analiza historii to także analiza korelacji ale to inny temat :). W kwestii marketingu lepiej jest, moim zdaniem, opracować model zjawiska, jednak do tego nie potrzebne są duże ilości danych a jedynie minimalny [[zestaw danych reprezentatywnych]] i to się nazywa zasadą ekonomii myślenia. Wielką zaś sztuką projektowania hurtowni danych dla systemów BI, nie jest samo gromadzenie danych a właśnie ich odsiewanie, dlatego systemy analityczne integrowane z systemami CRM bywają czasem bardziej szkodliwe niż pomocne.
Te i podobne "zasady" to w moich oczach jakieś oczywistości. Jednak czy złe? Hm.... czasami mam wrażenie, że wielu ludzi faktycznie powinno nawet te oczywistości poznać, z drugiej jednak strony zachodzi ryzyko, że ktoś uwierzy że proste stosowanie ich obligatoryjnie prowadzi do prostych sukcesów a to już jest ślepa uliczka. Ludzie często szukają "złotego środka" na wszystko, tak zwanej "[[srebrnej kuli]]". Nie prostych recept, gdyby istniały nie było by problemów. Każdy problem (wyzwanie) to indywidualny problem w unikalnym środowisku. Jeżeli ktoś daje wiarę w to, że istnieje jakaś recepta na ich rozwiązywanie ...
