Przypadki użycia nie znają swoich realizacji…

Tak wiec pisząc "Krowa z silnikiem odrzutowym, jelita na czerwono, jądrowymi kopytami, wyprawiona na buty skóra, zniszczyła metro, wypadek samochodowy, przelatując nad Warszawą, liczba płyt chodnikowych to 1347, a następnie wylądowała w Elektrociepłowni Żerań, załadunek węgla w południe wykonany przez Kowalskiego, i pożywiła się węglem popijając wodę z Wisły" to poprawne gramatycznie, bezbłędnie napisane zdanie w języku polskim, ale nikt nie ma chyba wątpliwości, że kompletnie pozbawione sensu. Tak samo można poprawnie, zgodnie z zasadami notacji, narysować diagram UML ...

Czytaj dalejPrzypadki użycia nie znają swoich realizacji…

Architektura korporacyjna w roku 2015 ? prognoza

Regularnie czytam blog Andrzeja Sobczaka, profesora SGH. Czasami bywa, że mam odmienne zdanie niż tam prezentowane, i tym razem też tak jest. Ostatni wpis na tym blogu zawiera siedmiopunktową prognozę na rok 2015. W zasadzie trudno w tych prognozach odmówić racji autorowi jednak dwa punkty, moim zdaniem, warte się komentarza. 2. W tym roku nie doczekamy się jeszcze wdrożenia w polskim przedsiębiorstwie pełnej koncepcji architektury korporacyjnej Na pytanie ?ile organizacji w Polsce wdrożyło? kompleksowo koncepcję architektury korporacyjnej [w tym w domenie architektury biznesowej] ? ciągle odpowiadam: zero (jeżeli się mylę ? proszę…

Czytaj dalejArchitektura korporacyjna w roku 2015 ? prognoza

Architektura oprogramowania i UML dla programistów

Gorąco polecam programistom, by w ogóle zaczęli korzystać z UML a analitykom, by wyleczyli się z wielu mitów o UML rozpowszechnianych niestety na wielu, nie zawsze tanich, szkoleniach i w wielu kiepskich "poradnikach UML" (pisanych nie raz nawet przez uczelnianych doktorów i nie tylko)..... Może wtedy przestaną tworzyć nieprzydatne developerom dokumentacje.

Czytaj dalejArchitektura oprogramowania i UML dla programistów
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Reguły – jakie nie powinny być…

Kolejny artykuł z gatunku "przemyślenia i rady na koniec roku" :) Często spotykam się traktowaniem reguł biznesowych jak jakiegoś piątego koła u wozu (o ile w ogóle się ktoś nimi zajmuje w projekcie).  Pół roku temu pisałem, że reguły biznesowe to, jeżeli  stają się wymaganiem, stanowią kluczowy element realizowanej logiki biznesowej: Sprawdzoną metodą skutecznego (spójność, kompletność, niesprzeczność) zapisywania wymagań dziedzinowych (w tym ?walidacje?) jest wydzielenie w dokumentacji: słownika pojęć słownika reguł biznesowych specyfikacji tablic decyzyjnych jako uzupełnienia reguł biznesowych. (Gdzie są te cholerne szczegóły). Jest jednak drugi, nie mniej ważny, element każdego…

Czytaj dalejReguły – jakie nie powinny być…

Visual Paradigm 12.0

Dzisiaj niespodzianka pod choinkę :) czyli VP wersja 12.00. Zaczynam prace a tu taki email: Dear Jarek Zelinski,We are thrilled to introduce to you the brand new Visual Paradigm - Visual Paradigm 12.0 with a new user interface and suite of new tools which improves your modeling efficiency. One of the highlighted improvements is the increase in diagram editing space, which means you have more room for editing your design and can be more focused on modeling. Click here to watch the introduction video of the Sleek UI, the official…

Czytaj dalejVisual Paradigm 12.0

Warsztaty analityczne – czyli malowanie trawy

Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć, bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.

Czytaj dalejWarsztaty analityczne – czyli malowanie trawy

Zrozumieć BPMN. Modelowanie procesów biznesowych

Na pytania dotyczące notacji BPMN i źródeł informacji odpowiadałem, że jedynym wyjściem na początek jest oryginalna specyfikacja, dawałem od razu wskazówki, które treści można pominąć, bez uszczerbku dla poznania samej notacji jako takiej. Nie mniej jednak specyfikacja ta, to  kilkaset stron trudnego, naukowego tekstu, do zrozumienia którego wymaga się jednak biegłej znajomości i czytania modeli pojęciowych  (diagramy klas notacji UML), co jest cechą wszystkich specyfikacji z OMG.org. Na szczęście pojawiła się książka Szymona Drejewicza. Nie jest to książka o analizie i modelowaniu procesów biznesowych, jest to  książka o notacji, w…

Czytaj dalejZrozumieć BPMN. Modelowanie procesów biznesowych

Business Analyst’s Mentor Book

Książka Business Analyst?s Mentor Book mile mnie zaskoczyła. Dość często  spotykam się z polecaniem książki Business Analysis, którą ja niestety raczej odradzam z uwagi na bardzo mechaniczne, uproszczone porady a nie raz wręcz fałszywe. Ta książka zaś, dla odmiany, nie skupia się na narzędziach (to nie jest lista porad w rodzaju  "w celu ... zrób to ... używając tego...) bo nie da się żadnej analizy sprowadzić do procedury. Ta książka to praktyczne, rzetelne rady i dobre praktyki. Autorzy zwracają uwag na to, że analiza i projektowanie (no bo czym są rekomendacje…

Czytaj dalejBusiness Analyst’s Mentor Book

Diagram prawdę Ci powie

Dzisiaj będzie bardzo krótki wpis, którym niemalże w całości będzie cytat z artykułu pewnego programisty. Każdy analityk i projektant powinien  przeczytać cały artykuł (nie jest długi) i koniecznie komentarze pod nim. Jeden komentarz zacytuje bo jest znamienny, choćby dlatego, że moje doświadczenia są dokładnie takie same: Co Ty człowieku, życia nie znasz? Przecież w realu jakbyś poszedł do takiego i podzielił się takimi uwagami  to foch na pare tygodni co najmniej gwarantowany. Kiedyś miałem podobną sytuację (a raczej serię sytuacji, ale dotyczących rzeczy o mniejszej skali) to efekt był taki,…

Czytaj dalejDiagram prawdę Ci powie

CRM w EXTREM

Tym razem małe "case study". Poniżej opis , tak wygląda większość mich projektów. Najczęściej mam kontakt z firmami, które przekonały się, że zawarcie umowy od razu na analizę wymagań i realizację projektu bez projektowania, i to w dodatku jako  umowę T&M (czas i materiał) rodzi problemy. Prezes EXTREM, lubi zadawać wiele pytań, miał doświadczenie z poprzedniego wdrożenia (w zasadzie nie doprowadzonego nigdy do końca): Firma EXTREM w 2013 roku rozpoczęła proces wyszukiwania na rynku oprogramowania CRM i jego dostawcy. W toku prowadzanych prezentacji okazało się, że oferty różnią się od…

Czytaj dalejCRM w EXTREM

10 lat czyli historia uczy, że prawie nie uczy….

Równo 10 lat temu (wtedy to na full time stałem się niezależną jednoosobową firma analityczną) napisałem: Decyzja o wdrożeniu jakiegokolwiek systemu informatycznego wspierającego działalność firmy wymaga oceny zasadności takiego projektu oraz wskazaniu obszarów działalności firmy, które zyskają na takim wdrożeniu. Bardzo często popełnianym błędem jest rozpoczęcie rozważań dotyczących potrzeby i możliwości wdrożenia konkretnej aplikacji. Jest to dość typowe działania inicjowane najczęściej złożeniem oferty przez dostawcę aplikacji a nie raz także znalezieniem reklamy danego produktu obiecującej poprawę funkcjonowania firmy w wyniku li tylko wdrożenia oferowanego rozwiązania. Dlaczego to jest błąd? Odpowiedź…

Czytaj dalej10 lat czyli historia uczy, że prawie nie uczy….

Proces a zdolność do wytworzenia

Dbałość o jednoznaczność i spójność dokumentacji to kluczowa cecha analityka, pisałem o tym między innymi w artykule o tępieniu niejednoznaczności. Uznawanie, że to nie ważne, dopuszczanie do nieprecyzyjnych definicji, uznawanie pewnych pojęcia za bliskoznaczne czy wręcz synonimy, prowadzi do nie tylko do emocji w rozmowach ale to nieprzydatności tworzonych dokumentów.

Czytaj dalejProces a zdolność do wytworzenia

Koniec treści

Nie ma więcej stron do załadowania