Nieco zaawansowane techniki analizy i modelowania

W dwóch ubiegłorocznych artykułach pisałem o modelach pojęciowych oraz o związkach w UML. Opisałem je od strony notacyjnej. Dzisiaj o ich zastosowaniu.  Generalnie zagadnienia modeli pojęciowych, abstrakcji i metamodeli oraz związków między nimi są dość trudne (wbrew pozorom, większość ludzi ma problem z abstrakcyjnym myśleniem), jako narzędzia są bardzo przydatne w analizie i projektowaniu. Rzecz w tym, że systemy analizowane istnieją, co znaczy ni mniej ni więcej tylko to, że "są dobre bo są i działają".  Gorzej jest gdy system, nie raz nietrywialny, jest na etapie projektowania. Wtedy o tym jest "dobry"…

Czytaj dalejNieco zaawansowane techniki analizy i modelowania

Przypadki użycia czy model procesu, czego używać?

Dość często spotykam sie z tezami, że użycie przypadków użycia nie wymaga modelowania procesów i odwrotnie, albo że są to "narzędzia" oferujące podobne lub takie same korzyści, np. tak jak tu: So, as you can see we used different techniques and basically the result is the same. It was not really important what techniques were used unless solution design is complete. It?s just a matter of a habit so if you?re more comfortable with use cases then stick to them or if you?re more familiar with process maps then draw…

Czytaj dalejPrzypadki użycia czy model procesu, czego używać?

Odsprzedaż sofware czyli czy można odzobaczyć to co się zobaczyło

Tym razem o logice egzekwowania prawa autorskiego. W artykule o analizie systemowej obszaru praw autorskich prezentowałem między innymi poniższy diagram:

Posłużę sie nim teraz, przy okazji analizy tego czym jest oprogramowanie. 

Materialną postać, gdzie wartość ma egzemplarz, ma dzieło takie jak np. rzeźba. Tu pojęcie reprodukcji (kopii oryginału) ma sens.  Jednak oprogramowanie, podobnie jak muzyka, proza, poezja, fotografia, jest dziełem niematerialnym. To, że jego egzemplarze  są “materializowane” na nośniku oznacza jedynie to, że zostało to dzieło utrwalone. (więcej…)

Czytaj dalejOdsprzedaż sofware czyli czy można odzobaczyć to co się zobaczyło

OMG’s MetaObject Facility

Końcówka roku, wręcz ostatni jego dzień 😉 …

Mając przed oczami kolejny projekt badawczy, kolejny raz gapię się na strony OMG i mała refleksja: porządki dobiegają końca. W artykule o UML v.2.5.  wspominałem, że zrezygnowano w końcu z pojęcia “agregacji” (zwanej czasami “słabą kompozycją”), odchodzi się od całkowicie zbędnych związków “extend” i “include” w przypadkach użycia (konstrukcje te nadal pozostają w specyfikacji z uwagi na kompatybilność wstecz narzędzi CASE i dokumentów jakie w nich są nadal tworzone lub archiwizowane). Paradoksalnie specyfikacja UML jest upraszczana (stale tkwi w niej echo pierwotnego zlepku kilku notacji z lat 99-tych).  Oczyma wyobraźni widzę jak ktoś, w toku prac nad UML, stale wymachuje “brzytwą Ockhama”… 

(więcej…)

Czytaj dalejOMG’s MetaObject Facility

Visual Paradigm 14.0 czyli efektywniejszy analityk

19 Grudnia opublikowano nową wersję pakietu Visual Paradigm: 14.0, w stosunku do poprzednie (13.2) wiele ulepszeń i kilka nowych “zabawek”. Nie będę opisywał wszystkich (szczegóły na stronie producenta, link na końcu artykułu). 

Na początek ważna uwaga i wyjaśnienie: korzystanie z narzędzi CASE z równoległym tworzeniem dokumentów “na boku”, z użyciem pakietów biurowych jest kompletnie pozbawionym sensu podejściem: tracimy 3/4 wartości tych narzędzi, jaką jest generowanie ad-hoc wysokiej jakości, spójnej, kompletnej i niesprzecznej dokumentacji. Modele tworzymy z kilku powodów: zapisujemy wyniki analizy, projektujemy rozwiązania, testujemy je, ale przede wszystkim przekazujemy tę wiedzę, czyli tworzymy dokumenty opisujące efekty naszej pracy. Główną pracą jaką wykonuje analityk jest analiza i projektowanie. Jeżeli więc tworzenie dokumentów zajmuje mu więcej niż umowne 20%, staje się po prostu nieefektywny czyli bardzo kosztowny. Często spotykam się z sytuacją gdy tak na prawdę 90% czasu analizy zajmuje spotykanie się i mozolne tworzenie dokumentów, 10% to faktyczna analityczna i twórcza praca. To mega marnotrawstwo (lub  kompletny brak szacunku dla zamawiającego). Dlatego generowanie wysokiej jakości merytorycznej dokumentacji (a nie tylko ślicznie sformatowanej) jest kluczowym elementem dobrego pakietu CASE (poza oczywiście zestawem notacji i ich zgodnością ze standardami). Tu tylko wspomnę, że od wielu lat nie używam edytorów tekstów do tworzenia produktów swojej pracy (w tym obszarze).  (więcej…)

Czytaj dalejVisual Paradigm 14.0 czyli efektywniejszy analityk

Ściąganie plików okiem prawnika – procesowy.pl

Prawo autorskie jest trudne głównie z tego powodu, że pojęcia takie jak utwór czy egzemplarz utworu, potrafią sprawić niemały kłopot nawet prawnikom. Pewien portal opublikował krótki wpis, tu jeden jego istotny fragment: Plik czy program? Podział może nie do końca zgodny z zasadami logiki (bo każdy program jest plikiem), jednak na potrzeby niniejszego wpisu pozwoliłem sobie  podzielić to co najczęściej ściągają internauci na dwie osobne kategorie: pliki (mp3, filmy itp.) oraz programy (w tym gry). Podział ten ma bowiem kolosalne znaczenie dla późniejszego ustalenia ewentualnej odpowiedzialności karnej.  [...] to co…

Czytaj dalejŚciąganie plików okiem prawnika – procesowy.pl

Analiza biznesowa. Praktyczne modelowanie organizacji

Analityk jest w projekcie informatycznym jak architekt w projekcie budowlanym. W obszarze analiz biznesowych wykształciły się standardy: należą do nich definicje kluczowych pojęć opisujących procesy biznesowe oraz notacje  stosowane do dokumentowania wyników tych analiz. Stosowanie własnych nietypowych metod, niestandardowych definicji pojęć i niestandardowych systemów notacyjnych, w obecnych czasach, prowadzi do sytuacji, w której inna firma (np. dostawca oprogramowania) ma problem ze zrozumieniem tego co otrzyma, to zaś skutkuje wieloma nieporozumieniami, a najczęściej prowadzi zarzucenia korzystania z takich dokumentów. Książka powstała dla wszystkich zlecających analizy i wykonujących je. Opisuje metody prowadzenia…

Czytaj dalejAnaliza biznesowa. Praktyczne modelowanie organizacji
Read more about the article Związki w UML czyli abstrakcja vs rzeczywistość
#1 - a 3d render series showing change and motion

Związki w UML czyli abstrakcja vs rzeczywistość

Wstęp Tym razem o kilku powszechnie popełnianych błędach w korzystaniu z UML. Chodzi o pojęcia abstrakcji, metamodeli i zależności oraz o związki między elementami na diagramach. Kluczową, moim zdaniem, przyczyną tworzenia "złych" modeli obiektowych jest używanie notacji UML do tworzenia modeli strukturalnych, nie mających z obiektowym paradygmatem nic wspólnego. Druga to niezrozumienie pojęcia paradygmatu obiektowego. Ogromna ilość diagramów wykonanych z  użyciem symboli notacji UML, z UML i paradygmatem obiektowym ma niewiele wspólnego. Najpierw kilka definicji i pojęć. Paradygmat programowania (ang. programming paradigm) ? wzorzec programowania komputerów przedkładany w danym okresie…

Czytaj dalejZwiązki w UML czyli abstrakcja vs rzeczywistość

Metareguły i zasady budowy cyfrowych usług publicznych

Kolejne projekty IT zaliczają kolejne wpadki i wśród przyczyn prawie zawsze pojawia się utrata panowania nad złożonością projektu. Jednym z kluczowych elementów analizy, także systemowej, jest redukowanie złożoności. Robi się to budując modele i metamodele analizowanej rzeczywistości, a na wstępnych etapach projektowania abstrahuje się od szczegółów. Jak? Operując właśnie modelami i metamodelami. Od dawna noszę się z zamiarem napisania czegoś o zarządzaniu złożonością i spójnością dokumentów. W końcu "nawinął" się dokument, na którym moim zdaniem warto "poćwiczyć". Jest to ciekawy dokument zatytułowany: Metareguły i zasady budowy cyfrowych usług publicznych We wstępie poznajemy cel i…

Czytaj dalejMetareguły i zasady budowy cyfrowych usług publicznych

User Story c.d.

Wokół metod zwinnych narasta wiele mitów, szczególnie tych o skuteczności w dużych projektach.  Dzisiaj kolejne kilka słów o popularnym narzędziu jakim jest tak zwane "user story" czyli historyjka użytkownika, o ich ewolucji i o tym, że mogą być przydatne i kiedy. Co prawda, jako źródło informacji wolę dokumenty, ale bywa, że tym źródłem informacji są jednak użytkownicy, bo dotyczy to projektowania np. nowych portali biznesowych. Tu niestety nie ma ani ustaw z wzorami dokumentów ani "dotychczasowego papierowego obiegu dokumentów".  Bardzo podobnie wyglądają start-up'y w obszarze operacyjnym. Podobnie wygląda analiza i…

Czytaj dalejUser Story c.d.

Prawo autorskie i prawa pokrewne

Każdy analityk to nie tylko pisarz ;), to także, a nawet przede wszystkim, projektant. To także ktoś, kto dba o prawa (powinien!) swoich klientów. Dlatego gorąco polecam każdemu, kto w projektach tworzy dokumenty, lub jest odpowiedzialny za ich tworzenie, tę lekturę. W szczególności rozdziały I do V, opisujące istotę praw autorskich i pokrewnych, prawa pokrewne i ochronę baz danych. Często słyszę, że to domena prawników, otóż nie. Domeną prawnika jest pilnowanie zgodności dokumentów z szeroko-pojętym prawem cywilnym (autorskim owszem także), ocena ryzyka podpisania danej umowy itp. Jednak niestety prawnicy (z…

Czytaj dalejPrawo autorskie i prawa pokrewne

CMMN czyli Case Management Model and Notation

  O notacji tej mówi się od kilku już lat. Początkowo spotkać można było opinie, że będzie częścią BPMN, a także że będzie jej konkurencją itp..  Pojawiały się nawet tezy (wróżby lub groźby ;) ), że będzie to dobre narzędzie do "rozrysowywania" złożonych przepływów w procesach (nadzieja dla zwolenników algorytmizacji firm...). Jednak nie. Walka z "kilerem" projektów, jakim jest "utrata panowania nad złożonością diagramów", z tworzeniem monstrualnych diagramów ocierających się o próby algorytmizowania organizacji trwa. Niedawno napisałem: Modele analityczne, jak sama nazwa wskazuje, to modele których celem jest stworzenie abstrakcji,…

Czytaj dalejCMMN czyli Case Management Model and Notation

Koniec treści

Nie ma więcej stron do załadowania