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
ewag@ipipan.waw.pl
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.