Opis organizacji to dość trudna profesja. Wymaga z jednej strony doświadczenia analitycznego a drugiej wiedzy z zakresu zarządzania i marketingu. Model organizacji to nie jest bowiem tylko jej wewnętrzny przepływ pracy. To także wymiana informacji z jej otoczeniem oraz cała harmonia zasobów jakie organizacja angażuje do tych działań. Dobry model powinien pokazać wszystkie te aspekty organizacji i związki między nimi. Jak nie trudno sie domyśleć, robienie tego (tworzenie diagramów) ręcznie “na piechotę” jest pracą wykraczającą poza możliwości pojedynczego człowieka. Dla zespołu ręczna praca była by benedyktyńskim wyzwaniem. Dlatego warto korzystać z narzędzi wspomagających tego rodzaju prace. Tym razem w numerze coś dla analityków i nie tylko. Pakiet iGrafx w wersji testowej.
Wskazywać korzyści z używania notacji UML w pracach projektowych nad systemami IT chyba nie trzeba jednak zaznaczę tylko, że moim zdaniem projektant i analityk ma dzisiaj dwa wyjścia: zapewnić by projekt był jednoznaczny i spójny oraz czytelny dla zespołu architektów systemów i programistów albo powinien przestać być analitykiem i projektantem.
Dziś wybrałem dwa artykuły
Narzędzia iGrafx (wersja ewaluacyjna)
Modelowanie procesów biznesowych to często projekty związane głównie albo tylko z reorganizacja firmy. W takich przypadkach pełny opis firmy powinien obejmować nie tylko diagramy procesów ale także schematy organizacyjne, strukturę komórek organizacyjnych, zasoby informatyczne inne. Programy klasy CASE (Computer Aided System Engineering), pomimo, że zawierają coraz częściej narzędzia do modelowania procesów, nadają się doskonale do dokumentowania analiz projektów, których celem jest powstanie lub wybór oprogramowania jednak nie spełniają wielu wymagań w projektach których celem jest reorganizacja, zarządzanie jakością czy wdrażanie metod controlingu. Pakietem, który nie jest narzędziem CASE ale jest bardzo dobrym narzędziem wspierającym szeroko rozumiane Zarządzanie Zorientowane na Procesy (BPM, ang. Business Process Management) jest właśnie iGrafx.
Pakiet zawiera między innymi moduły:
iGrafx? FlowCharter?
iGrafx? Process?
iGrafx? Process? for Six Sigma
iGrafx? Enterprise Modeler?
iGrafx? Process Central?
iGrafx? Small Busienss Edition (5x FlowCharter + Process Central dla 5 użytk.)
iGrafx? Enterprise Central?
iGrafx? BPEL interface
iGrafx? Process Converter
iGrafx? IDEF0?
iGrafx? Viewer
iGrafx? Viewer Plus
Pakiet ten można polecić każdemu kto zajmuje się dokumentowaniem i analizą wszelkich aspektów organizacji związanych z procesami biznesowymi. Wersja testowa to sposób by sprawdzić to przed ewentualnym zakupem.
UML – modelowanie dynamicznych aspektów oprogramowania
Niewątpliwie UML (według mnie) to notacja nie dla biznesu. Jednak analityk, projektant i architekt systemowy to właściwe osoby. Niekończące się dywagacje kto jakiej notacji powinien używać i do czego prowadzą tlyko do akademickich dyskusji i do kłopotów komunikacyjnych tam, gdzie niewłaściwym językiem przemawia sie do niewłaściwych ludzi. Moim zdaniem komunikacja powinna wyglądać tak:
[BUSINESS] <<—BPMN— [ANALITYK] —UML—>> [PROJEKTANT-PROGRAMISTA]
W środku mamy analityka, który nie jest ani prezesem ani programistą ale za to zna biznes i zna systemy. Do każdego zwraca się w jego języku. Ale… tu ma być tym razem o UML.
Prezentacja wymagań na system do trudne zajęcie. Praktyka pokazuje, ze im więcej zwykłego tekstu tym więcej problemów podczas tworzenia systemu. Dlaczego? Bo tekst (proza ;)) nie jst jednoznaczny, jest podatny na interpretację czytelnika. Diagramy cechuje jednoznaczność i praktycznie brak możliwości interpretacji innej niż jedna, ta jaką miał na myśli autor. Wyobraźmy sobie zresztą jak wyglądałyby nasze domy, gdyby jedynym elementem dokumentacji architektonicznej był słowny opis architekta.
Artykuł opisuje drugi, po przypadkach użycia i modelu dziedziny systemu, aspekt opisu wymagań: zachowania systemu. Nie jest to proste biorąc pod uwagę różnorodność problemów: obiekty stanowe (np. dokumenty, ludzie), współbieżność i transakcyjność i wiele innych. Opisanie tekstem w sposób jednoznaczny tych elementów wymagań jest praktycznie nie możliwe. Za pomocą diagramów: sekwencji, komunikacji, aktywności, maszyny stanów, czy przebiegów czasowych możliwe jest przekazanie opisu budowy systemu np. programistom będąc niemalże pewnym, że napiszą kod taki jaki chciał projektant mimo, tego, że nie będzie go w tym procesie kodowania.
Artykuł polecam każdemu kto ma ambicje lub potrzebę poznania notacji UML.
