Język UML jest notacją, o której wiele mówi się, ale jej zakres używania nie jest oczywisty. Diagramów jest zwyczajnie zbyt wiele. Oczywiste jest to, że mimo bogactwa notacji, w projektach nie stosuje się ich wszystkich. Stosując zasadę, że modelujemy tylko istotne rzeczy, sam też tak nie robię. Do modelowania wspomnianych istotnych rzeczy dobieram odpowiednie diagramy. …
W wielu firmach toczy się dyskusja o sformalizowaniu procesu wytwórczego oprogramowania. Spontaniczne tworzenie diagramów, tysiące historyjek rozrzucone po Jira, setki stron w Confluence tworzone przez szeroko rozumianych analityków i projektantów nie buduje wartości dokumentacji. Wartość powstaje, gdy cały zespół dokłada diagram do diagramu jak cegiełka do cegiełki. Dodawane modele procesów biznesowych lub diagramy BPMN uzupełniają …
Wybór narzędzia wspomagającego modelowanie i analizę Czytaj dalej »
W wielu firmach, z którymi mam przyjemność współpracować jest stosowana nierozłączna para: JIRA i Confluence. JIRA odpowiada za zarządzania zadaniami a Confluence jest swoistym repozytorium treści. Narzędzia te zostały niejako wtłoczone w proces wytwarzania oprogramowania. Korzystają z niego programiści, testerzy, a także analitycy i architekci. W wielu firmach pojawia się też i narzędzie do modelowania. …
Subiektywne porównanie narzędzi do modelowania procesów biznesowych Czytaj dalej »
W ostatnim wpisie opisałem co myślę o roli analityka w podejściu zwinnym. Drugą rolą, o której chciałbym wspomnieć jest rola architekta. Rola ta określona jest w klasycznym podejściu do wytwarzania oprogramowania. Natomiast w zwinnym podejściu o architekturze i architektach nie wspomina się zbyt wiele. Jedynie w założeniach manifestu programowania zwinnego pojawia się (podkreślenia moje): Najlepsze …
Rola analityka i znaczenie analizy w wielu organizacjach umacnia się a w innych zanika. Dość często tam, gdzie pojawia się zwinne podejście rola analityka jest trudna do zdefiniowania. W manifeście programowania zwinnego (http://agilemanifesto.org/iso/pl/manifesto.html) można przeczytać: W wyniku naszej pracy, zaczęliśmy bardziej cenić: Ludzi i interakcje od procesów i narzędzi Działające oprogramowanie od szczegółowej dokumentacji Współpracę …
Nie da się ukryć, że praca na Enterprise Architect to czasem niemałe wyzwanie. Zwłaszcza publikacja diagramów sprawia spory problem. Nie bez przyczyny też opublikowałem specjalne kurs, który mówi o tym, jak raportować z Enterprise Architect. Myślę, że powoli ta sytuacja zmienia się na lepsze. Już ponad rok temu Sparx Systems wypuścił na rynek rozwiązanie, które …
Enterprise Architect Pro Cloud Server – modelowanie w chmurze Czytaj dalej »
Modelowanie procesów biznesowych jest dziś stosunkowo powszechne. W wielu organizacjach robi się to nawet w dwóch miejscach :-). W komórce odpowiedzialnej za usprawnianie lub nadzór nad procesami i w IT, gdzie wytwarza się oprogramowanie. Powszechnie stosowanym językiem opisu jest notacja BPMN. Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania zostało, w moim odczuciu, usankcjonowane w Rational …
Modelowanie procesów biznesowych w procesie wytwórczym oprogramowania Czytaj dalej »
Dzisiejszy wpis poświęcony jest Software & Systems Process Engineering Meta-Model Specification (SPEM). Co to jest SPEM? SPEM to zaproponowany przez OMG (ang. Object Management Group), który został pomyślany jako spójny zestaw pojęć do opisu procesu inżynierii oprogramowania. Co oferuje SPEM? Cytując artykuł “SPEM/UML w specyfikacji procesów zarządzania projektem” (Iwona Dubielewicz, Jerzy Sas, e-Informatica Software Engineering …
W dniach 7-8 maja prowadziłem w Warszawie szkolenie z projektowania systemów informatycznych. Nikt z uczestników szkolenia nie miał wątpliwości, że modele w UML są przydatne a jednocześnie metodyki z nurtu Agile odrzucają modelowanie. Oczekiwania wobec szkolenia krążyły wobec tematów co i jak dokumentować w UML? Jak obszerną dokumentację wykonywać? Jak połączyć modelowanie w UML z …
Projektowanie systemów informatycznych w ujęciu Agile Czytaj dalej »
Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne dla specyfikowania systemów, ale nie pozwalają w pełni opisać wymagań. Przypadki użycia stanowią swoiste agregaty dla wymagań, pozwalają dokonać pewnej dekompozycji wymagań na poszczególne funkcje systemu. Niestety ich rola …
