Opis orga­ni­za­cji to dość trud­na pro­fe­sja. Wymaga z jed­nej stro­ny doświad­cze­nia ana­li­tycz­ne­go a dru­giej wie­dzy z zakre­su zarzą­dza­nia i mar­ke­tin­gu. Model orga­ni­za­cji to nie jest bowiem tyl­ko jej wewnętrz­ny prze­pływ pra­cy. To tak­że wymia­na infor­ma­cji z jej oto­cze­niem oraz cała har­mo­nia zaso­bów jakie orga­ni­za­cja anga­żu­je do tych dzia­łań. Dobry model powi­nien poka­zać wszyst­kie te aspek­ty orga­ni­za­cji i związ­ki mię­dzy nimi. Jak nie trud­no sie domy­śleć, robie­nie tego (two­rze­nie dia­gra­mów) ręcz­nie ​„na pie­cho­tę” jest pra­cą wykra­cza­ją­cą poza moż­li­wo­ści poje­dyn­cze­go czło­wie­ka. Dla zespo­łu ręcz­na pra­ca była by bene­dyk­tyń­skim wyzwa­niem. Dlatego war­to korzy­stać z narzę­dzi wspo­ma­ga­ją­cych tego rodza­ju pra­ce. Tym razem w nume­rze coś dla ana­li­ty­ków i nie tyl­ko. Pakiet iGrafx w wer­sji testowej.

Wskazywać korzy­ści z uży­wa­nia nota­cji UML w pra­cach pro­jek­to­wych nad sys­te­ma­mi IT chy­ba nie trze­ba jed­nak zazna­czę tyl­ko, że moim zda­niem pro­jek­tant i ana­li­tyk ma dzi­siaj dwa wyj­ścia: zapew­nić by pro­jekt był jed­no­znacz­ny i spój­ny oraz czy­tel­ny dla zespo­łu archi­tek­tów sys­te­mów i pro­gra­mi­stów albo powi­nien prze­stać być ana­li­ty­kiem i projektantem.

Dziś wybra­łem dwa artykuły

Narzędzia iGrafx (wersja ewaluacyjna)

Modelowanie pro­ce­sów biz­ne­so­wych to czę­sto pro­jek­ty zwią­za­ne głów­nie albo tyl­ko z reor­ga­ni­za­cja fir­my. W takich przy­pad­kach peł­ny opis fir­my powi­nien obej­mo­wać nie tyl­ko dia­gra­my pro­ce­sów ale tak­że sche­ma­ty orga­ni­za­cyj­ne, struk­tu­rę komó­rek orga­ni­za­cyj­nych, zaso­by infor­ma­tycz­ne inne. Programy kla­sy CASE (Computer Aided System Engineering), pomi­mo, że zawie­ra­ją coraz czę­ściej narzę­dzia do mode­lo­wa­nia pro­ce­sów, nada­ją się dosko­na­le do doku­men­to­wa­nia ana­liz pro­jek­tów, któ­rych celem jest powsta­nie lub wybór opro­gra­mo­wa­nia jed­nak nie speł­nia­ją wie­lu wyma­gań w pro­jek­tach któ­rych celem jest reor­ga­ni­za­cja, zarzą­dza­nie jako­ścią czy wdra­ża­nie metod con­tro­lin­gu. Pakietem, któ­ry nie jest narzę­dziem CASE ale jest bar­dzo dobrym narzę­dziem wspie­ra­ją­cym sze­ro­ko rozu­mia­ne Zarządzanie Zorientowane na Procesy (BPM, ang. Business Process Management) jest wła­śnie iGrafx.

Pakiet zawie­ra mię­dzy inny­mi 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 inter­fa­ce
iGrafx? Process Converter
iGrafx? IDEF0?
iGrafx? Viewer
iGrafx? Viewer Plus

Pakiet ten moż­na pole­cić każ­de­mu kto zaj­mu­je się doku­men­to­wa­niem i ana­li­zą wszel­kich aspek­tów orga­ni­za­cji zwią­za­nych z pro­ce­sa­mi biz­ne­so­wy­mi. Wersja testo­wa to spo­sób by spraw­dzić to przed ewen­tu­al­nym zakupem.

UML – modelowanie dynamicznych aspektów oprogramowania

Niewątpliwie UML (według mnie) to nota­cja nie dla biz­ne­su. Jednak ana­li­tyk, pro­jek­tant i archi­tekt sys­te­mo­wy to wła­ści­we oso­by. Niekończące się dywa­ga­cje kto jakiej nota­cji powi­nien uży­wać i do cze­go pro­wa­dzą tly­ko do aka­de­mic­kich dys­ku­sji i do kło­po­tów komu­ni­ka­cyj­nych tam, gdzie nie­wła­ści­wym języ­kiem prze­ma­wia sie do nie­wła­ści­wych ludzi. Moim zda­niem komu­ni­ka­cja powin­na wyglą­dać tak:

[BUSINESS] « — BPMN— [ANALITYK] —UML — » [PROJEKTANT-PROGRAMISTA]

W środ­ku mamy ana­li­ty­ka, któ­ry nie jest ani pre­ze­sem ani pro­gra­mi­stą ale za to zna biz­nes i zna sys­te­my. Do każ­de­go zwra­ca się w jego języ­ku. Ale… tu ma być tym razem o UML.

Prezentacja wyma­gań na sys­tem do trud­ne zaję­cie. Praktyka poka­zu­je, ze im wię­cej zwy­kłe­go tek­stu tym wię­cej pro­ble­mów pod­czas two­rze­nia sys­te­mu. Dlaczego? Bo tekst (pro­za ;)) nie jst jed­no­znacz­ny, jest podat­ny na inter­pre­ta­cję czy­tel­ni­ka. Diagramy cechu­je jed­no­znacz­ność i prak­tycz­nie brak moż­li­wo­ści inter­pre­ta­cji innej niż jed­na, ta jaką miał na myśli autor. Wyobraźmy sobie zresz­tą jak wyglą­da­ły­by nasze domy, gdy­by jedy­nym ele­men­tem doku­men­ta­cji archi­tek­to­nicz­nej był słow­ny opis architekta.

Artykuł opi­su­je dru­gi, po przy­pad­kach uży­cia i mode­lu dzie­dzi­ny sys­te­mu, aspekt opi­su wyma­gań: zacho­wa­nia sys­te­mu. Nie jest to pro­ste bio­rąc pod uwa­gę róż­no­rod­ność pro­ble­mów: obiek­ty sta­no­we (np. doku­men­ty, ludzie), współ­bież­ność i trans­ak­cyj­ność i wie­le innych. Opisanie tek­stem w spo­sób jed­no­znacz­ny tych ele­men­tów wyma­gań jest prak­tycz­nie nie moż­li­we. Za pomo­cą dia­gra­mów: sekwen­cji, komu­ni­ka­cji, aktyw­no­ści, maszy­ny sta­nów, czy prze­bie­gów cza­so­wych moż­li­we jest prze­ka­za­nie opi­su budo­wy sys­te­mu np. pro­gra­mi­stom będąc nie­mal­że pew­nym, że napi­szą kod taki jaki chciał pro­jek­tant mimo, tego, że nie będzie go w tym pro­ce­sie kodowania.

Artykuł pole­cam każ­de­mu kto ma ambi­cje lub potrze­bę pozna­nia nota­cji UML.