E. Stemposz. Rational Unified Process, Wykład 8, Slajd 1

wrzesień 2002

Studia Podyplomowe IT w Biznesie

Rational Unified Process

Wykład 8

Przepływ prac:

Modelowanie

biznesowe

Wykładowca:
dr inż. Ewa Stemposz

[e-mail]

Polsko-Japońska Wyższa

Szkoła

Technik Komputerowych

Warszawa

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 2

wrzesień 2002

Zagadnienia

Zagadnienia

Zagadnienia

Modelowanie biznesowe: cele i efekty
Modelowanie biznesowe - czy warto?
Rodzaje modelowania biznesowego
Notacja
Pracownicy i artefakty
Przepływ prac
Od modelu biznesowego do systemu
Inne źródła wymagań na system
Wsparcie narzędziowe
Podsumowanie

Prezentowany materiał został przygotowany w oparciu o publikację:
Philippe Kruchten, The Rational Unified Process An Introduction, Addison-
Wesley, 1999.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 3

wrzesień 2002

Modelowanie biznesowe: cele i

efekty

 Modelowanie biznesowe - pierwszy z głównych
przepływów

prac

-

powinno

poprzedzać

proces

specyfikowania wymagań na oprogramowanie (przepływ
prac: Wymagania).

 Ułatwienie zrozumienia struktury i dynamiki
organizacji, w której oprogramowanie ma być wdrażane
(tzw. “organizacji docelowej”).

 Ułatwienie zrozumienia aktualnych problemów
organizacji w celu zidentyfikowania miejsc dla
potencjalnych ulepszeń.
 Uzyskanie pewności, że wszyscy uczestnicy projektu
(klienci,

użytkownicy

i

członkowie

zespołu

projektowego) postrzegają docelową organizację w
jednakowy sposób (jej strukturę, dynamikę i problemy).
 Utworzenie bazy dla specyfikowania wymagań na
oprogramowanie.

Efekt
y:

Cele:

 Uzyskanie wizji “nowej organizacji docelowej” i w
oparciu

o

nią

zdefiniowanie

procesów,

ról

i

odpowiedzialności w organizacji.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 4

wrzesień 2002

Modelowanie biznesowe - czy

warto ? (1)

 Oprogramowanie musi być “intuicyjnie dopasowane do
miejsca”, w którym będzie wykorzystywane, bo stanowi
narzędzie codziennego użytku (zarówno w pracy, jak i w
domu).
Oprogramowanie przestało być gadżetem wytwarzanym
przez „czarodziei komputerowych” dla hobbystów.

 Dlatego, w proces tworzenia modelu biznesowego
powinien być wciągany każdy pracownik organizacji dla
której tworzone jest oprogramowanie: od członków zarządu i
marketingu po szeregowych pracowników włącznie.

 Wciąganie pracowników organizacji w proces tworzenia
modelu biznesowego, jest uważane obecnie za bardziej
efektywne podejście do specyfikowania wymagań na
oprogramowanie, niż korzystanie z porad ekspertów
dziedzinowych. Eksperci dziedzinowi mają wiedzę, ale brak
im władzy niezbędnej do wprowadzania zmian w
organizacji, zmian będących efektem automatyzowania jej
działalności.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 5

wrzesień 2002

Modelowanie biznesowe - czy

warto ? (2)

 Nie każde przedsięwzięcie, związane z produkowaniem
software’u,

wymaga

przeprowadzania

modelowania

biznesowego.

 Wydaje się, że warto przeprowadzać modelowanie
biznesowe w sytuacji, gdy więcej informacji musi być
obsługiwanych przez system, czyli np. gdy większa grupa
ludzi ma być bezpośrednimi użytkownikami danego systemu.

 Np. rozszerzenie istniejącego systemu o kilka
dodatkowych cech z reguły nie wymaga budowy modelu
biznesowego, ponieważ zasadnicze cele systemu nie
ulegają radykalnej zmianie.
 Sytuacja wygląda inaczej, gdy trzeba zbudować system
nie na półkę, ale na zamówienie konkretnego klienta,
ponadto wspierający prace w organizacji, gdzie procesy
biznesowe są złożone. Właściwa realizacja projektu
wymaga tu pełnej świadomości skutków automatyzacji
prac: innymi słowy trzeba dobrze zrozumieć, jak
automatyzacja wpłynie na zmianę reguł prowadzenia
biznesu.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 6

wrzesień 2002

Modelowanie biznesowe - czy

warto ? (3)

E-biznes - nowy buzz word - biznes związany z tworzeniem
aplikacji (zwanych czasami narzędziami biznesowymi)
wspomagających automatyzację procesów biznesowych.
Można wyróżnić tu:

 C2B (Customer to Business): aplikacje wspomagające
współpracę klienta z firmą, np. zakupy przez Internet.
 B2B (Business to Business): automatyzacja współpracy
między firmami, np. automatyzacja łańcucha dostaw.
 B2C (Business to Customer): dostarczanie informacji
do klienta (klient jest tu stroną bierną), np. rozsyłanie
biuletynów informacyjnych.
 C2C (Customer to Customer): automatyzacja wymiany
informacji między klientami, z niewielkim wsparciem ze
strony providera, np. aukcje internetowe.

 Potrzeba modelowania biznesowego jest wyraźnie
widoczna dla organizacji tworzących software dla e-biznes’u
- modelowanie biznesowe zajmuje tu centralne miejsce w
procesach realizacji projektów.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 7

wrzesień 2002

Rodzaje modelowania

biznesowego (1)

Inżynieria biznesowa może być realizowana mniejszym lub
większym wysiłkiem w zależności od konkretnego kontekstu i
potrzeb. Można tu wyróżnić sześć postawowych scenariuszy:

(1) Mapa organizacji: Można zbudować prostą mapę
organizacji i jej procesów, w celu osiągnięcia dobrego
zrozumienia wymagań na budowany system. W takim
wypadku

modelowanie

biznesowe

jest

częścią

realizowanego projektu i z reguły ma miejsce w fazie
początkowej.

(2) Modelowanie dziedziny: Jeśli głównym zadaniem
budowanego systemu jest prezentacja i zarządzanie
informacją

(np.

system

wspierający

zarządzanie

zamówieniami czy system bankowy), można zbudować
model informacji na poziomie biznesowym. Odpowiada to
modelowaniu dziedziny w inżynierii oprogramowania, z
reguły

wykonywanym

w

fazach

początkowej

i

opracowywania.

(3) Jeden biznes, wiele systemów: Jeśli budowany jest
duży system (rodzina aplikacji) można przeprowadzić
modelowanie

biznesowe,

którego

rezultaty

zostaną

wykorzystane w kilku projektach. Model biznesowy posłuży
do specyfikowania wymagań funkcjonalnych i architektury.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 8

wrzesień 2002

Rodzaje modelowania

biznesowego (2)

(4) Generyczny model biznesowy: Jeśli budowany jest
system, który będzie wykorzystywany przez kilka organizacji
(np. system wspierający sprzedaż czy rozliczenia rachunkowe)
może być użyteczne zbudowanie generycznego modelu
biznesowego. Pozwoli to na uszeregowanie organizacji w
zależności od

ich reguł biznesowych

(aby uniknąć

specyfikowania zbyt złożonych wymagań) lub pomoże
zrozumieć i zarządzać różnicami, jakie w tych regułach
występują, co z kolei powinno ułatwić przypisywanie
priorytetów wymaganiom na system.

(5) Nowy biznes: Jeśli organizacja decyduje się na
rozpoczęcie zupełnie nowej linii biznesu, dla której wsparcie
ma stanowić budowany system - modelowanie biznesowe jest
konieczne. Model biznesowy ma nie tylko wspomóc
specyfikowanie wymagań na system, ale też pozwolić na
oszacowanie wykonalności nowego przedsięwzięcia. W takim
wypadku modelowanie biznesowe jest z reguły przeprowadzane
w postaci oddzielnego projektu.

(6) Reorganizacja (reinżynieria procesów biznesowych):
Jeśli organizacja decyduje się na kompletną przebudowę
procesów, modelowanie biznesowe z reguły staje się zadaniem
dla co najmniej kilku projektów.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 9

wrzesień 2002

Notacja

 Techniki wykorzystywane w modelowaniu biznesowym są
podobne do technik inżynierii oprogramowania, a nawet
historycznie

rzecz

biorąc:

techniki,

które

zostały

wypracowane przez inżynierię oprogramowania stanowiły
inspirację dla rozwoju nowych dróg w wizualizowaniu
organizacji.

 Ponieważ modelowanie oparte o podejście obiektowe
stanowi podstawę rozwoju większości projektów związanych
z produkcją oprogramowania, wykorzystywanie podobnych
technik w modelowaniu biznesowym wydaje się być
naturalnym rozwiązaniem.

Notacja

 Użytkownicy biznesowi - zewnętrzni w stosunku do biznesu,
jak np. klienci, sprzedawcy czy partnerzy - są reprezentowani
przez aktorów biznesowych.

 Procesy biznesowe są reprezentowane przez biznesowe
przypadki użycia i biznesowe realizacje przypadków użycia.

 Pracownicy biznesowi reprezentują role, jakie ludzie
odgrywają wewnątrz organizacji.

 Encje biznesowe reprezentują artefakty, które organizacja
produkuje lub którymi zarządza.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 10

wrzesień 2002

Pracownicy i artefakty (1)

Analityk

procesów

biznesowych

Słownik

biznesowy

Oszacowanie

organizacji

docelowej

Wizja

biznesu

Reguły

biznesowe

Dokument

architektury

biznesowej

Biznesowy

model obiektowy

Uzupełniająca

specyfikacja

biznesu

Biznesowy

model

przypadków użycia

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 11

wrzesień 2002

Pracownicy i artefakty (2)

Projektant

biznesowy

Realizacja

biznesowego

przypadku użycia

Aktor

biznesowy

Biznesowy

przypadek użycia

Jednostka

organizacyjna

Encja

biznesowa

Pracownik

biznesowy

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 12

wrzesień 2002

Pracownicy i artefakty (2)

Pracownicy zaangażowani w modelowanie biznesowe

 Analityk procesów biznesowych: Rodzaj przewodnika i
koordynatora w procesie modelowania biznesowego - do jego
zadań należy ustanowienie wizji nowego biznesu, określenie
aktorów biznesowych, biznesowych przypadków użycia oraz
interakcji między nimi.

 Projektant biznesowy: Uszczegóławia specyfikację części
organizacji

przez

dostarczenie

opisu

relewantnych

biznesowych przypadków użycia. Określa pracowników
biznesowych i encje biznesowe niezbędne do realizacji
przypadków. Ponadto, definiuje odpowiedzialności, atrybuty,
operacje i zależności między pracownikami biznesowymi a
encjami biznesowymi.

 Inni pracownicy: np. dostarczający informacji czy
zaangażowani w przeglądy ( np. recenzent biznesowy).

Najważniejsi to: analityk procesów biznesowych i projektant biznesowy.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 13

wrzesień 2002

Pracownicy i artefakty (3)

Najważniejsze artefakty:

 Dokument wizji biznesu: specyfikuje cel prac związanych z
modelowaniem biznesowym.
 Biznesowy model przypadków użycia: specyfikuje
użytkowników biznesowych oraz funkcje (procesy) biznesowe,
w oparciu o które zostaną zidentyfikowani pracownicy
biznesowi i encje biznesowe.

 Biznesowy model obiektowy: model obiektowy
specyfikujący realizację biznesowych przypadków użycia w
terminach oddziaływania pracowników biznesowych na encje
biznesowe.

Biznesowy model obiektowy powstaje przy użyciu tych
samych technik modelowania, co model obiektowy systemu,
tyle że na wyższym poziomie abstrakcji. Np. klasa na
poziomie biznesowym reprezentuje odpowiedzialności nie w
systemie, ale w organizacji.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 14

wrzesień 2002

Pracownicy i artefakty (4)

 Jednostka organizacyjna: zgrupowanie pracowników i
encji biznesowych, w celu odzwierciedlenia struktury
organizacji

(np.

w

celu

uwidocznienia

istnienia

departamentów). Mechanizm grupowania pozwala ponadto
na zrównoleglenie struktury modelu przypadków użycia i
modelu projektowego.

 Uzupełniająca specyfikacja biznesu: zawiera definicje nie
ujęte ani w biznesowym modelu przypadków użycia ani w
biznesowym modelu obiektowym.

 Słownik biznesowy: zawiera definicje pojęć biznesowych.

 Oszacowanie docelowej organizacji: zawiera ocenę
aktualnego stanu organizacji.

 Reguły biznesowe: specyfikują reguły polityki prowadzonej
przez organizację i ograniczenia, które muszą być
wypełniane.

Inne artefakty:

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 15

wrzesień 2002

Przepływ prac (1)

Szacuj

statusu

organizacji

[Początek

opracowywania]

Opisz

aktualny

biznes

Identyfikuj

procesy

biznesowe

Ulepsz (refine)

procesy

biznesowe

Projektuj realizację

procesów biznesowych

Ulepsz role i

odpowiedzialności

Badaj możliwości

automatyzacji

procesów

Modeluj

dziedzinę

[Pełne modelowanie
biznesowe]

[Tylko
modelowanie
dziedziny]

Możliwych jest kilka
ścieżek w zależności od
celu

modelowania

biznesowego.

[Inne

rodzaje

modelowania]

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 16

wrzesień 2002

Przepływ prac (2)

 W pierwszej iteracji należy oszacować status organizacji
docelowej - tej, w której system ma być wdrażany. Główne
artefakty, które powinny tu powstać to: Oszacowanie
organizacji docelowej i Wizja biznesu.

 Bazując na rezultatach oszacowania, należy wybrać któryś
z omówionych wcześniej scenariuszy modelowania
biznesowego.

 Jeśli nie jest potrzebne przeprowadzenie “pełnego
modelowania biznesowego” wybiera się scenariusz 2-gi, tzw.
“Modelowanie dziedziny”. Model dziedzinowy jest traktowany
w RUP jako podzbiór obiektowego modelu biznesowego -
podzbiór zawierający wyłącznie encje biznesowe.

 Jeśli nie zachodzi potrzeba wprowadzania dużych zmian do
istniejących procesów biznesowych, wystarczy wybrać
scenariusz 1-szy, tzw. „Mapę organizacji” (skupienie uwagi na
wymaganiach na system, a nie na ulepszaniu procesów
biznesowych).

 Jeśli potrzeba ulepszyć procesy biznesowe lub
przeprowadzić reinżynierię procesów biznesowych należy
wybrać scenariusze 3-ci, 4-ty i 6-ty.

 Jeśli planowane jest rozpoczęcie nowego biznesu, należy
wybrać scenariusz 5-ty z ominięciem aktywności: Opisz
aktualny biznes.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 17

wrzesień 2002

Od modelu biznesowego do

systemu (1)

Biznesowy

model obiektowy

Biznesowy

model

przypadków użycia

Model przypadków

użycia

Model projektowy

Model

implementacji

Model testowy

Modelowanie
biznesowe

Modelowanie systemu

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 18

wrzesień 2002

Od modelu biznesowego do

systemu (2)

Transakcja

pieniężna 2

Specjalista

d.s. kredytów

[System]

Model przypadków użycia

Transakcja

pieniężna 1

Urzędnik

Klient

Biznesowy model

przypadków użycia

Transakcja

pieniężna

Biznesowy

model obiektowy

:Klient

:Specjalista

d.s. kredytów

:Profil klienta

:Konto

:Kredyt

:Urzędnik

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 19

wrzesień 2002

Od modelu biznesowego do

systemu (3)

Aktorów systemu, jak i systemowe przypadki użycia można
wyprowadzać

z

modelu

biznesowego.

Pracownikowi

biznesowemu przyporządkowywuje się relewantnego aktora w
systemie, a biznesowemu przypadkowi użycia, w którym
pracownik biznesowy uczestniczy - relewantny systemowy
przypadek użycia. Jeśli celem jest budowa systemu, który ma
całkowicie zautomatyzować procesy biznesowe (jak np. e-
biznes), proces przyporządkowywania przebiega inaczej.

Klient

Biznesowy model

przypadków użycia

Transakcja

pieniężna

Biznesowy

model obiektowy

:Klient

:Specjalista

d.s. kredytów

:Profil klienta

:Konto

:Kredyt

:Urzędnik

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 20

wrzesień 2002

Od modelu biznesowego do

systemu (4)

Transakcja

pieniężna 2

Specjalista

d.s. kredytów

[System]

Model przypadków użycia

Transakcja

pieniężna 1

Urzędnik

Biznesowy

model obiektowy

:Klient

:Specjalista

d.s. kredytów

:Profil klienta

:Konto

:Kredyt

:Urzędnik

Transakcja

pieniężna 2

Specjalista

d.s. kredytów

[System]

Model przypadków użycia

Transakcja

pieniężna 1

Klient

Krok 1

Krok 2

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 21

wrzesień 2002

Od modelu biznesowego do

systemu (5)

Odpowiedzialności związane z pracownikami biznesowymi
zostają przeniesione na aktorów systemowych. Encje
biznesowe - z kolei - są kandydatami na obiekty klas w
systemie.

Biznesowy

model obiektowy

:Klient

:Specjalista

d.s. kredytów

:Profil klienta

:Konto

:Kredyt

:Urzędnik

Model

analityczny

Profil

klienta

Konto

Kredyt

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 22

wrzesień 2002

Od modelu biznesowego do

systemu (6)

Automatyzacja procesów biznesowych może pociągać za sobą
zmianę modelu biznesowego: każdy pracownik biznesowy i
każda encja powinny być implementowane przez jeden rodzaj
zasobów.

Biznesowy

model obiektowy

:Klient

:Specjalista

d.s. kredytów

:Urzędnik

Biznesowy

model obiektowy

:Klient

:Specjalista

d.s. kredytów

:Automatyczny

Urzędnik

:Automatyczny

specjalista

d.s. kredytów

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 23

wrzesień 2002

Inne źródła wymagań na system

 użytkownicy, nie reprezentowani w modelu biznesowym,
np. administrator systemu,

Inne - nie ujęte w modelu biznesowym - źródła informacji
wspomagające pozyskiwanie wymagań na projektowany
system :

 strategie obowiązujące w biznesie poddawanym analizie,
związane np. z technologiami informacyjnymi, ponownym
użyciem, kompatybilnością i jakością,
 wszelkie rzeczy spadkowe,

 ograniczenia czasowe (w tym koordynacja z innymi
równolegle prowadzonymi projektami),
 aktualne trendy obowiązujące zarówno w dziedzinie
związanej z rozważanym biznesem, jak i w dziedzinie
związanej z technologiami informacyjnymi.

E. Stemposz. Rational Unified Process, Wykład 8, Slajd 24

wrzesień 2002

Wsparcie narzędziowe;

Podsumowanie

 Rational Rose: do wizualizacji opisanych wcześniej modeli
biznesowych; używane są te same pojęcia UML, które służą
do budowy modeli dla projektowanego systemu z nieco
innymi stereotypami.

Narzędzia, wspierające proces modelowania biznesowego,
dostarczane przez RUP:

 Rational RequisitePro: do zarządzania zależnościami
występującymi między elementami zawartymi zarówno w
tym samym modelu, jak i w różnych modelach.

 Rational SoDa: do generowania i zarządzania
dokumentacją

powstającą

w

trakcie

modelowania

biznesowego.

Modelowanie biznesowe jest szczególnie użyteczne przy budowie:

 systemów dedykowanych, np. dla jednej lub kilku
organizacji w pewnej dziedzinie: bankowość, ubezpieczenia,
itp.,
 rodziny aplikacji przeznaczonych na rynek, np.: systemy
do obsługi zamówień, systemy bilingowe, systemy do
kontroli ruchu powietrznego, itp.