Autor prezentuje podejście, które nazywam podejściem "opartym na danych". Co mam na myśli? Otóż podejście to zakłada, że istotą "systemu" jakim jest organizacja są gromadzona i zarządzane dane (wiedza). Inne podejście, nazwę je operacyjne (lub procesowe), zakłada że istotą organizacje jest odgrywanie określonej roli na rynku (dostawca produktów, usługodawca, itp.). Innymi słowy istotne jest to co potrafię zaoferować a nie to jakimi danymi dysponuję.
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju "ale ja chcę zobaczyć to wszystko na jednym diagramie" pchamy projekt w kierunku "utraty panowania nad złożonością"... To prosta droga do klęski projektu.
Analizy biznesowe wymagają oderwania się od technokracji, nie ma czegoś takiego jak dziesiątki przypadków użycia dla jednej faktury, nie ma systemowych przypadków użycia (nawet w specyfikacji UML ich nie znajdziecie), są kompletne (dające jako efekt przydatne produkty) usługi aplikacyjne i korzystający z tych usług aktorzy, w tym inne aplikacje lub komponenty. Dokumentacje zawierające setki przypadków użycia to nieporozumienie, technokratyczni zabójcy projektów. Warto się zastanowić zanim powierzycie analizę i projekt logiki systemu technokratycznemu developerowi...
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.
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…
PwC przedstawiła wyniki badań statystycznych i sugestie przyczyn prezentowane przez dystrybutorów, innymi słowy zadała wiele pytań i uporządkowała odpowiedzi na nie. Znamienne jest także to, że Raport ?Analiza wpływu zjawiska piractwa treści wideo na gospodarkę w Polsce? przygotowany przez PwC przygotowano na zlecenie Stowarzyszenia Dystrybutorów Programów Telewizyjnych "Sygnał". Nie mam podstaw do oskarżania PwC o stronniczość, ale na pytanie: czy Stowarzyszenie promowało by raport uderzający w ich interesy, sami Państwo musicie sobie odpowiedzieć, ja jestem wyłącznie niezależnym analitykiem :) i na tym się skupię.
Wakacje to czas na spokojniejsze lektury i badania (które zresztą zajmują mi niemało czasu). Swego czasu pisałem o problemach jakie tworzą niejednoznaczne w swej treści dokumenty (usunąć niejednoznaczność). Zawsze powtarzam na szkoleniach, że dokumenty tworzone przez analityka to nie tylko "jego raport", te dokumenty to "wiedza przekazana" np. developerom, a wcześniej sponsorowi projektu (ma np. potwierdzić zgodność modelu organizacji z nią samą). Raporty z analiz to nie tylko modele ale także komunikacja, to nośniki przekazujące wiedzę adresatom tych dokumentów. Dokumenty, modele, specyfikacje, to nic innego jak przekaz (komunikacja), a ten…
Z racji tego, że nie wyobrażam sobie dobrego analityka nie posługującego się sprawnie logiką (także formalną, bo czymże są notacje jak nie formalnymi systemami pojęciowymi) polecam np. tę książkę. Tadeusz Kotarbiński, Kurs logiki dla prawników. Ja mam wydanie PWN z 1963 roku ale logika się nie starzeje a autor zacny. Co prawda podtytuł zawiera "dla prawników", jednak książka nie jest "prawnicza" a o logice. Nie będę się rozpisywał, sami przeczytajcie wprowadzenie a dowiecie się - zrozumiecie - dlatego wiele specyfikacji wymagań i projektów to dokumenty nieprzydatne
pytanie o diagram klas jako reprezentacja [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca) mówiących o modelowaniu danych diagramami klas notacji UML. Do modelowania danych używamy notacji ERD (ang. [[Entity Relationship Diagram]], diagram związków encji).
Z cyklu mity OpenSource: Kwietniowa awaria OpenSSL, w wyniku której serwery dosłownie ?krwawiły? poufnymi danymi (stąd w języku angielskim błąd ten nazwano ?heartbleed?), jest niezaprzeczalnym dowodem na to, że otwarte kody źródłowe nie są ani analizowane ani testowane mimo wielu możliwości weryfikacji otwartego oprogramowania w celach bezpieczeństwa. Dlaczego open source nie jest tak bezpieczny, jak powinien? - Computerworld.
