Dwa lata temu pisałem o budowaniu słowników pojęć jako kluczowymi elemencie każdego dokumentu analitycznego. (trójkąt semiotyczny) Tak więc podejmując się analizy, warto robić to ?dobrze?, można to nazwać metodą naukową i nie będzie w tym przesady. Reguły biznesowe, rygory ich tworzenia, słownik pojęć, model pojęciowy, to wszystko służy poprawie jakości wyników analizy, dokumentacji, późniejszego projektu. Specyfikacja SBVR bardzo w tym pomaga. (o formalizacji modeli)Jeżeli mieliście kiedyś problem z projektem, to jest bardzo prawdopodobne, że jedną z kluczowych tego przyczyn był zły (lub jego brak) model pojęciowy.Analitycy! Studiujcie logikę. Źródło: ?1?…
Pięć lat temu napisałem: Przyjmując, że dany system pojęciowy jest kompletny (pozwala na zapisanie każdej informacji z danej dziedziny), analiza polega tu na rozłożeniu tekstu (danych) pozyskanych np. z wywiadów czy dokumentów, na skończoną liczbę pojęć i związków pomiędzy nimi. W efekcie uzyskujemy np. diagram procesu BPMN (jeżeli celem był model procesu biznesowego) lub diagram klas UML (jeżeli celem była np. analiza pojęciowa, obiektowa czy zbudowanie taksonomii). [...] Więcej innym razem (Źródło: Epistemologia ? Jak Pomaga W Analizie | | Jarosław Żeliński IT-Consulting) ... i obiecałem ciąg dalszy ;). Zgodnie z powyższym…
O analizie pojęciowej pisałem nie raz, chyba pierwszy raz w krótkim artykule Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych. Niestety nadal problemem większości dokumentów, takich jak analizy i specyfikacje, jest ich niespójność i niejednoznaczność. W niedawnym artykule SBVR czyli reguły biznesowe i słownik pisałem o diagramie faktów, o regułach i o słowniku pojęć, dzisiaj co nieco o pojęciach (tych ze słownika pojęć ;)). Ostatnia wersja specyfikacji SBVR v.1.3. z maja tego roku, zawiera rozszerzony rozdział: 8 Linguistic Foundations, 8.1 Things, Meanings, and Expressions, 8.1.1 Semiotic/Semantic Triangle in SBVR Terms rozpoczynający się tak: This sub…
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
W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną). Innymi słowy: jeżeli jakieś ziarno węgla jest kostką to na pewno nie jest ani groszkiem, ani orzechem ani miałem.
A co jeżeli jednak wynik analizy jest opisem w języku naturalnym lub zestawem diagramów łamiących zasady notacji? Wtedy tak naprawdę analitykami są programiści, bo oni i tak muszą to zamienić na kod w języku programowania, którego używają. Czy to dobry pomysł? Pozostawię odpowiedź czytelnikowi...
