UML – Page 25 – JZ IT Consulting Ltd

Struktura organizacyjna jako system

Post author:Jaroslaw Zelinski
Post published:11 August 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.

Bezpieczny jak email czyli wcale

Post author:Jaroslaw Zelinski
Post published:9 August 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Korzystanie z własnego repozytorium daje ochronę bo: my nim administrujemy, w przeciwieństwie do sieci Internet, nie da się go "podsłuchiwać", i co najważniejsze: dokumenty są w sposób jednolity skatalogowane, wersjonowane itp. Jeżeli jedyne miejsce z dokumentami, ich wersjami itp, to nasze skrzynki pocztowe, to znaczy, że nikt nie ma wiarygodnej, kompletnej wiedzy o projekcie.

Słownik pojęć biznesowych czyli po co nam przestrzeń nazw

Post author:Jaroslaw Zelinski
Post published:8 August 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

I tu dochodzimy do sedna: aby stworzyć profil notacji - co czasami bywa niezbędne dla jakości analizy - należy zbudować słownik pojęć z dziedziny analizowanego problemu. Bez takiego słownika analiza może być niewykonywalna, albo jej jakość będzie bardzo niska - czytaj użycie jej wyników będzie bardzo ryzykowne.

c.d. nt. Architektury Korporacyjnej

Post author:Jaroslaw Zelinski
Post published:6 August 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Po co dokumentować (modelować) AK? Przede wszystkim po to by zrozumieć jak działa organizacja, a potem by móc świadomie, znając ryzyko, podejmować decyzje o wprowadzaniu zmian do niej. [...] Czy to musi być jakiś standard np. TOGAF? Nie jestem przekonany. ArchiMate (notacja zalecana w TOGAF) to nic innego jak system pojęciowy. Czy mamy wybór? Oczywiście, że mamy. Od dawna OMG dostarcza sprawdzone i otwarte standardy notacyjne.

Krótka lista pięciu rzeczy, które nie są regułami biznesowymi

Post author:Jaroslaw Zelinski
Post published:31 July 2013
Post category:Analizy biznesowa i projektowanie oprogramowania

Od samego początku analizy i projektowania logiki systemu należy skupić się na tym "co i po co" a nie "jak". Zajmowanie się pytaniami "jak" (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości, nadmiarowych, szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy - mając szkielet całego projektu - wiemy które mają jakiekolwiek znaczenie.