Z pamiętnika analityka

Dział "Z pamiętnika analityka" to zbiór artykułów opisujących nasze doświadczenia zawodowe. Opisujemy w nich ciekawe sytuacje z realnych projektów, w których braliśmy udział, pokazując, czego się nauczyliśmy.

Twórcy egzaminów OMG UML Certified Professional (OCUP) gruntownie zmienili kształt i zawartość tych egzaminów, nadając im nową nazwę OCUP 2. Wedle zapewnień autorów, nowe egzaminy koncentrują się przede wszystkim na umiejętności interpretacji i tworzenia modeli, a mniej na samym metamodelu UML i niuansach jego klas abstrakcyjnych. Czy tak jest rzeczywiście?

Dokumentacja analityczna zwykle podlega akceptacji i odbiorowi przez klienta. Po oficjalnej dostawie takiej dokumentacji klient ma oczywiście prawo zgłaszać do niej uwagi. Jak jednak sprawić, żeby przez coraz to nowe uwagi zgłaszane przez klienta do kolejnych wersji dokumentacji, jej odbiór nie przeciągał się w nieskończoność?

UML jest najpopularniejszym obecnie językiem służącym do graficznego modelowania różnych aspektów działania systemu informatycznego. Każda szanująca się firma szkoleniowa w branży IT ma w swojej ofercie kursy języka UML. Jak zatem powinno się uczyć języka UML, aby uczestnicy szkoleń odnieśli z nich największe korzyści? Wskazówki opisane w tym artykule opracowałem na bazie swojego doświadczenia jako wykładowcy oraz na podstawie opinii zebranych od uczestników szkoleń.

UML - graficzny język modelowania różnych aspektów działania systemu informatycznego - jest standardem bardzo rozbudowanym. W jego skład wchodzi 13 rodzajów diagramów. Każdy tzw. klasyfikator (klasa, relacja, przypadek użycia, czynność, ...) ma w UML-u kilkadziesiąt własności. Dokumentacja języka UML 2.1 liczy ponad 1000 stron. Czy aby tworzyć eleganckie i poprawne diagramy UML trzeba znać pełną notację tego języka?

Powszechna sytuacja: dostawca realizuje dla klienta system "szyty na miarę". Wyniki analizy dostarcza m. in. w postaci dlagramów np. w języku UML. Tymczasem przedstawiciele klienta to specjaliści biznesowi, a nie informatycy. Nie znają więc notacji UML. Jak sprawić, żeby zrozumieli model i zaczęli się z nim identyfikować? Pełniąc rolę głównego analityka w projekcie realizowanym dla instytucji ubezpieczeniowej, zastosowałem w tym celu ciekawą technikę.

Realizacja procesu biznesowego w organizacjach biurowych (w przeciwieństwie np. do fabryk) nieuchronnie wiąże się z przepływem dokumentów. Czy pojawienie się dokumentów wpływa na sposób, w jaki modelujemy procesy? Czy tworząc model procesu powinniśmy się w ogóle przejmować dokumentami? W projekcie prowadzonym dla jednej z instytucji rynku ubezpieczeniowego, w ramach którego kierowałem zespołem analityków tworzących model procesów biznesowych, znaleźliśmy bardzo ciekawą technikę modelowania procesów, w których pojawiają się dokumenty.