Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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:

Podobne prezentacje


Prezentacja na temat: "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:"— Zapis prezentacji:

1 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 Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

2 E. Stemposz. Rational Unified Process, Wykład 8, Slajd 2 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.

3 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. Efekty: Cele: Uzyskanie wizji nowej organizacji docelowej i w oparciu o nią zdefiniowanie procesów, ról i odpowiedzialności w organizacji.

4 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.

5 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 softwareu, 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.

6 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-biznesu - modelowanie biznesowe zajmuje tu centralne miejsce w procesach realizacji projektów.

7 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.

8 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.

9 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.

10 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

11 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

12 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.

13 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.

14 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:

15 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]

16 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.

17 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

18 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

19 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

20 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

21 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 KontoKredyt

22 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

23 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.

24 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.


Pobierz ppt "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:"

Podobne prezentacje


Reklamy Google