Ta konferencja przekonała mnie, że w sumie to jestem zwinny, bo: moje umowy mają zakres i harmonogram, praca jest iteracyjna, całość bazuje na wizji, opisuję jak stwierdzimy, że wykonałem swoją prace... a specyfikacje wymagań jakie opracowuję, mają nie setki i tysiące pozycji, a góra kilkadziesiąt.
Swego czasu pisałem na temat granic systemu i o analizie systemowej (analiza systemowa). Rzecz w tym, że pojęcie "analiza systemowa" jest używane najczęściej (jak obserwuję, prawie zawsze) w znaczeniu analizy i projektowania oprogramowania (systemy IT) co jest błędem.Tak zwane "całościowe myślenie" (holistyczne) to uznanie, że system to nie tylko oprogramowanie. Literatura przedmiotu, praktyka moja i nie tylko, potwierdza jedno: wymagania biznesowe to całościowe spojrzenie na biznes i cele biznesowe, wymagania wobec oprogramowania to dopiero "wymagania wobec rozwiązania" (polecam [[BABoK]] z IIBA). Jakiś czas temu zamówiłem książkę Systems Thinking. Potwierdza, że…
Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.
