Nieco ponad rok temu opisywałem sytuację, w której pewien doświadczony analityk narzekał, że pracownicy jego klientów nie potrafią mu powiedzieć czego chcą i jak ma działać ich przyszły system. Odpowiedź moja jest w takich sytuacjach zawsze taka sama: ...analiza nie polega na słuchaniu! (wyobrażacie sobie leczenie, w którym diagnozy stawiają pacjenci?). Nie raz tu pisałem i kolejny raz powtórzę:Analiza oparta na zeznaniach i życzeniach jej [firmy zamawiającego] pracowników jest bardzo narażona na fiasko, gdyż subiektywna wiedza pracowników oraz ich spekulacje, mogą nie mieć wiele wspólnego z rzeczywistością lub pożądanym stanem…
Kim więc jest dobry analityk?
Jest to projektant, który potrafi analizowaną organizację "rozłożyć na elementy składowe". Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie "rysunek". Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia.
Analiza Biznesowa to rozłożenie analizowanego "przedmiotu" na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania.
Poziomy szczegółowości wymagań to:
cele biznesowe (produkty procesów biznesowych)
opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania)
opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)
Po kolei:
obserwacje to analiza tego co i jak się w firmie dzieje (analiza dokumentów i wywiady)
budowanie hipotezy to tworzenie modelu procesowego tej firmy i modelu jej dziedziny
eksperymenty to testowanie modeli poprzez sprawdzanie czy model procesu da jako produkt taki sam dokument jak te w praktyce
przyjęcie lub odrzucenie hipotezy oraz jej powtarzanie to iteracyjne testowanie i ulepszanie modelu (jeśli był wadliwy)
