Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być).

Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często 😉 ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność.

Wprowadzenie

Ludzie i ich praca to informacje i ich wymiana. Komputer i oprogramowanie to mechanizm przetwarzania danych reprezentujących te informacje. Projektowanie oprogramowania polega na zrozumieniu i opisaniu tego mechanizmu, tego jakie to dane i jak są (analiza) lub powinny być (projektowanie) przetwarzane. Aby to zrobić analizujemy dokumenty, nie robimy wywiadów.

Jeżeli ktoś tego nie potrafi i nie rozumie, zaczyna organizować wywiady i kodować to, co ludzie postrzegają ze swojej perspektywy. Tak powstaje najgorsze oprogramowanie.

Można to zobrazować jak poniżej:

Dlatego do opracowania projektu przyszłego ‘systemu informatycznego’ należy najpierw zrozumieć ‘system informacyjny’ firmy (organizacji, branży). W tym momencie możesz kontynuować lekturę tego wątku w artykule System informacyjny a informatyczny.

Poniżej po lewej udokumentowany efekt obserwacji z Ziemi, oprogramowanie powstające na bazie wywiadów i obserwacji ma potem podobna strukturę. Po prawej stronie, efekt zrozumienia obserwacji: model, którego wykorzystanie do napisania oprogramowania zaowocuje oprogramowaniem o znacznie mniejszej złożoności i jednocześnie lepsze, bo wierniej odwzorowujące “sytuację biznesową”: powstanie szybciej, będzie tańsze w wytworzeniu i w późniejszym utrzymaniu i rozwoju.

Dlatego napisałem też artykuł: User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji! Poniżej po lewej oprogramowanie, które powstało jako efekt implementacji kolejnych wywiadów z użytkownikami (user story), po prawej efekt przemyślanego projektowania.

Dalsza część artykułu to opis tego czym są metody i teorie naukowe. Czytelników, których metodologiczne detale nie interesują zachęcam do lektury wyżej cytowanych artykułów.

Twierdzenie naukowe

Poniżej definicja tego czym jest twierdzenie naukowe:

Twierdzenie naukowe ? zdanie oznajmiające spełniające następujące warunki :

1. można wobec niego sformułować kryteria pozwalające na eksperymentalne, obserwacyjne lub logiczne ich obalenie (falsyfikowalne według zasad Karla R. Poppera),
2. istnieją reguły jego odczytania, które ograniczają do skończoności liczbę ich interpretacji (kryterium precyzji Józefa Bocheńskiego),
3. odnosi się do empirycznie doświadczalnej lub logicznie definiowanej rzeczywistości (tzw. widły Hume?a),
4. jest elementem zbioru twierdzeń paradygmatu wyjaśniającego rzeczywistość i pozwalającego na przewidywanie jej przyszłych stanów (koncepcja nauki normalnej T. S. Kuhna),
5. twierdzenie będące najprostszym z możliwych opisów świata (tzw. Brzytwa Ockhama).

Graficznie sam proces odkrycia naukowego można pokazać tak :

Celowo cytuję tu literaturę z obszaru inżynierii oprogramowania, by pokazać, że nie jestem odosobniony w tym podejściu. Dla porządku podaje także definicje pojęcia model:

model: system założeń, pojęć i zależności między nimi pozwalający opisać (modelować) w przybliżony sposób jakiś aspekt rzeczywistości

Więcej o modelach w nauce: .

Inżynieria oprogramowania

Jeżeli uznamy, że wynik zarówno analizy jak i projektowania, to także modele (przyjmujemy metodę pracy opartą na tworzeniu modeli: MDD/MDA czyli “model driven development”, MDA czyli “model driven architecture”, itp.), to w związku z tym

model, jako wynik analizy, można potraktować jako twierdzenie naukowe opisujące badaną (analizowaną) organizację, jest on zarazem wymaganiem wobec oprogramowania (ma zostać zaimplementowany).

Wyjaśnienie: odniosę się do powyższej definicji twierdzenia naukowego (zgodnie z powyższym pod pojęciem model rozumiemy komplet dokumentacji zawierającej modele, powstałej jako produkt analizy):

1. kryterium falsyfikacji: dopiero wskazanie w badanej organizacji faktu, którego nie opisuje opracowany model, pozwala uznać model (wynik analizy) za zły,
2. istnieją reguły jego (modelu) odczytania, czyli do stworzenia modelu użyto sformalizowanych notacji i systemów pojęciowych (np. BPMN, UML, BMM, SBVR itp),
3. model powstał na bazie, i odnosi się wyłącznie do, zebranych w toku analizy faktów (w szczególności dokumentów, które powstają w toku pracy analizowanej organizacji – dokumenty opisują fakty np. faktura to opis faktu dokonania sprzedaży),
4. model pozwala na przewidywanie tego co zajdzie w odpowiedzi na określone bodźce (paradygmat procesowy opisujący zachowania i paradygmat obiektowy opisujący struktury), mając model procesów biznesowych można przewidzieć produkt procesu, mając model aplikacji można przewidzieć produkt każdego przypadku użycia,
5. opracowany model jest najprostszy (minimalny) z możliwych, czyli nie da się już z niego usunąć nic bez spowodowania jego zniszczenia (uczynienia nieprawdziwym).

Tu, dla dopełnienia,  warto dodać powszechnie uznawaną w świecie nauki definicję prawdy (A.Tarski): twierdzenie prawdziwe to twierdzenie korespondujące z faktami.

Tak więc mamy to co chcemy czyli kryterium odbioru dokumentacji analitycznej i projektowej: nie jest to liczba stron a “to, że mówi prawdę”. 

Z drugiej strony, niestety nie istnieje możliwość wykazania poprawności dokumentacji powstałej w wyniku ankiet, wywiadów czy burzy mózgów spisanej językiem naturalnym … .

Tę “ciężką artylerię”, jak ta tu opisana, wytaczamy głównie dla projektów ryzykownych i kosztownych… 😉 oraz wszędzie tam gdzie ważna jest ochrona know-how.

Dodatek

(dwa dni po publikacji)

Właśnie podesłano mi link do ciekawego tekstu:

One of the most important elements of every Business Analyst?s toolkit is process modeling, which is also significant activity for Business Process Management professionals. For BPM market B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszystkie wypowiedzi one “kręcą się” wokół dokumentowania, prezentacji w celu zatwierdzenia lub zgłaszania uwag oraz niektórzy wskazują na możliwość “rysowania zamiast kodowania w celu wykonania”, albo przeoczyłem albo nikt nie zwrócił uwagi na bardzo – mim zdaniem ważny element – tworzenie modelu organizacji czyli tworzenie hipotezy “tak działacie” jako organizacja.

Problem w tym, że chyba większość “użytkowników” tej (BPMN) – i nie tylko – notacji, stosuje indukcyjne metody uwiarygadniania tych modeli, rozumianych raczej jako schematy blokowe. Podejście bazujące na “dowodzie z ilości” (indukcja): model procesów jest dobry bo bardzo dużo osób (osób akceptujących, recenzentów) tak uznało, jest chyba najgorsze.

To błąd logiczny: nie da się wykazać poprawności metodą indukcyjną. Model owszem powinien być jako diagram zrozumiały dla czytelnika, to nie ulega wątpliwości, jednak jego testy powinny polegać na wskazywaniu (szukaniu) ewentualnych faktów typu “a tu mówi nieprawdę”. Innymi słowy model procesu nie jest “dobry” (odzwierciedla prawdziwy mechanizm działania organizacji) dlatego, że wszyscy go zaakceptowali, jest dobry dlatego, że nikt nie znalazł (nie wskazał) jego wady (nie podważono go).

Projektów zakończonych klęską, w których “wszyscy zaakceptowali dokumentację” znamy chyba wszyscy masę….

Tak więc analityk, który podchodzi systemowo do analizy powinien tworzyć hipotezy “tak to działa” i nie dowodzić ich poprawności, a czekać na wskazanie wad. Notacje (BPMN, UML, BMM, …) oraz modele tworzone z ich pomocą, są doskonałym narzędziem do dokumentowania tych teorii.

Na zakończenie polecam to 🙂

Źródła