PolskoJaposka Wysza Szkoa Technik Komputerowych Warszawa Studia Podyplomowe

Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa 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 E. Stemposz. Rational Unified Process, Wykład 8, Slajd 1 wrzesień 2002

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 2 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). Cele: § 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. Efekty: § 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 3 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 4 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 5 wrzesień 2002

Modelowanie biznesowe - czy warto ? (3) ü 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-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: § C 2 B (Customer to Business): aplikacje wspomagające współpracę klienta z firmą, np. zakupy przez Internet. § B 2 B (Business to Business): automatyzacja współpracy między firmami, np. automatyzacja łańcucha dostaw. § B 2 C (Business to Customer): dostarczanie informacji do klienta (klient jest tu stroną bierną), np. rozsyłanie biuletynów informacyjnych. § C 2 C (Customer to Customer): automatyzacja wymiany informacji między klientami, z niewielkim wsparciem ze strony providera, np. aukcje internetowe. E. Stemposz. Rational Unified Process, Wykład 8, Slajd 6 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 7 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 8 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 9 wrzesień 2002

Pracownicy i artefakty (1) Słownik biznesowy Reguły biznesowe Oszacowanie organizacji docelowej Wizja biznesu Biznesowy model przypadków użycia Biznesowy model obiektowy Dokument architektury biznesowej Uzupełniająca specyfikacja biznesu Analityk procesów biznesowych E. Stemposz. Rational Unified Process, Wykład 8, Slajd 10 wrzesień 2002

Pracownicy i artefakty (2) Biznesowy przypadek użycia Aktor biznesowy Jednostka organizacyjna Encja biznesowa Realizacja biznesowego przypadku użycia Projektant biznesowy E. Stemposz. Rational Unified Process, Wykład 8, Slajd 11 Pracownik biznesowy wrzesień 2002

Pracownicy i artefakty (2) Pracownicy zaangażowani w modelowanie biznesowe Najważniejsi to: analityk procesów biznesowych i projektant biznesowy. § 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). E. Stemposz. Rational Unified Process, Wykład 8, Slajd 12 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 13 wrzesień 2002

Pracownicy i artefakty (4) Inne artefakty: § 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. § 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. § 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. E. Stemposz. Rational Unified Process, Wykład 8, Slajd 14 wrzesień 2002

Przepływ prac (1) [Początek opracowywania] Szacuj statusu organizacji [Inne rodzaje modelowania] [Pełne modelowanie biznesowe] Opisz aktualny biznes Identyfikuj procesy biznesowe Badaj możliwości automatyzacji procesów [Tylko modelowanie dziedziny] Ulepsz (refine) procesy biznesowe Możliwych jest kilka ścieżek w zależności od celu modelowania biznesowego. Projektuj realizację procesów biznesowych Modeluj dziedzinę Ulepsz role i odpowiedzialności E. Stemposz. Rational Unified Process, Wykład 8, Slajd 15 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 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 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 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 16 wrzesień 2002

Od modelu biznesowego do systemu (1) Modelowanie biznesowe Biznesowy model przypadków użycia Model projektowy Biznesowy model obiektowy Model implementacji Model testowy Modelowanie systemu E. Stemposz. Rational Unified Process, Wykład 8, Slajd 17 wrzesień 2002

Od modelu biznesowego do systemu (2) Transakcja pieniężna Biznesowy model przypadków użycia Klient : Urzędnik : Specjalista d. s. kredytów Biznesowy model obiektowy : Profil klienta : Konto Transakcja pieniężna 1 [System] Model przypadków użycia Urzędnik E. Stemposz. Rational Unified Process, Wykład 8, Slajd 18 : Kredyt Transakcja pieniężna 2 Specjalista d. s. kredytów 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. Transakcja pieniężna Biznesowy model przypadków użycia Klient : Urzędnik : Specjalista d. s. kredytów Biznesowy model obiektowy : Profil klienta E. Stemposz. Rational Unified Process, Wykład 8, Slajd 19 : Konto : Kredyt wrzesień 2002

Od modelu biznesowego do systemu (4) : Klient : Urzędnik : Specjalista d. s. kredytów Biznesowy model obiektowy : Profil klienta : Konto : Kredyt Krok 1 Transakcja pieniężna 1 [System] Model przypadków użycia Transakcja pieniężna 2 Specjalista d. s. kredytów Urzędnik Krok 2 Transakcja pieniężna 1 [System] Model przypadków użycia E. Stemposz. Rational Unified Process, Wykład 8, Slajd 20 Klient Transakcja pieniężna 2 Specjalista d. s. kredytów 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. : Klient : Urzędnik : Specjalista d. s. kredytów Biznesowy model obiektowy : Profil klienta Model analityczny Profil klienta E. Stemposz. Rational Unified Process, Wykład 8, Slajd 21 : Konto : Kredyt 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 E. Stemposz. Rational Unified Process, Wykład 8, Slajd 22 : Urzędnik : Automatyczny Urzędnik : Specjalista d. s. kredytów : Automatyczny specjalista d. s. kredytów : Specjalista d. s. kredytów wrzesień 2002

Inne źródła wymagań na system Inne - nie ujęte w modelu biznesowym - źródła informacji wspomagające pozyskiwanie wymagań na projektowany system : § użytkownicy, nie reprezentowani w modelu biznesowym, np. administrator systemu, § 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 23 wrzesień 2002

Wsparcie narzędziowe; Podsumowanie Narzędzia, wspierające proces modelowania biznesowego, dostarczane przez RUP: ü 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. ü Rational Requisite. Pro: 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 So. Da: 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. E. Stemposz. Rational Unified Process, Wykład 8, Slajd 24 wrzesień 2002