Część 3

1. Część 3 OiZPI Przypadki użycia Obiektowy model organizacji w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów informatycznych A.Kobieliński: Inżynieria Oprogramowania I.Sommerville: Software Engineering Guides

2. Przypadek użycia – opis zbioru ciągów akcji i ich wariantów wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi rezultatu. Przypadek użycia opisuje co robi system ale nie określa jak to robi. Aktor – spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia. Aktorem może być dowolny byt zewnętrzny, także systemy i urządzenia Przypadki użycia i aktorzy

3. laborant Notacja Przypadek użycia: Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. badanie składu Aktor: Powinien mieć unikalną nazwę. Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem. Relacja zależności : o stereotypach«include» lub «extend»: Pokazuje związek zachodzący między dwoma przypadkami użycia. «include» Źródło: K.Subieta wykł.

4. Budowa modelu przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystywaniem projektowanego systemu, Aktor - “przyszły użytkownik systemu”. Aktor to osoba, ale także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. I odwrotnie, jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor “strażnik budynku”. Czy system może być aktorem sam dla siebie ? Nie - aktor to przecież, zgodnie z definicją, byt z otoczenia systemu. Aktor jest pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą danych wyprodukowanych przez przypadki użycia. Aktor Źródło: K.Subieta wykł.

5. Dla przypadków użycia podaje się dokładną specyfikację Specyfikuje się czynność lub ciąg czynności Specyfikacja może mieć różną formę ( np. tekst ustrukturalizowany) Można wyspecyfikować również scenariusz Przypadek użycia Źródło: K.Subieta wykł.

6. klient Przykład diagramu przypadków użycia przykład: Automat do sprzedaży papierosów uzupełnienie towaru zakup paczki papierosów operacja pieniężna operator sporządzenie raportu wnętrze systemu granica systemu kontroler otoczenie systemu Źródło: K.Subieta wykł.

7. Relacja uogólnienia - aktorzy operator systemu hutnik księgowy laborant Mistrz dziedziczy dostęp do przypadków użycia wyspecyfikowanych dla każdego hutnika, oraz ma dostęp do przypadków związanych z jego własnym, specyficznym sposobem wykorzystywania systemu. Kierownik rafinerii nie jest mistrzem ponieważ nie występuje w przypadkach użycia w których mistrz jest aktorem kierownik rafinerii mistrz próbkarz

8. Relacja uogólnienia – przypadki użycia • Przypadki użycia można uporządkować przez zdefiniowanie uogólnień • uogólnienie oznacza, że przypadek użycia – potomek, dziedziczy całe zachowanie i znaczenie po przypadku – przodku • Potomek może dodać do odziedziczonego zachowania dodać nowe elementy, albo – jeśli to konieczne – całkowicie je zmienić

9. Zależności - przypadki użycia • Zależność – dla przypadków użycia znaczenie zależy od stereotypu • Stereotypy – określa przebieg • <<include>> - przebieg podstawowy • <<extend>> - przebieg opcjonalny przebieg podstawowy (sekwencyjny): p1 zawsze włącza (używa) p2. «include» p1 p2 przebieg opcjonalny (alternatywny): p1 jest czasami rozszerzane o p2 (inaczej: p2 czasami rozszerza p1). «extend» p1 p2 Źródło: K.Subieta wykł.

10. Zależności - przypadki użycia przykład: Logowanie użytkownika do systemu Źródło: K.Subieta wykł.

11. Konstrukcja modelu Użytkownik Aktor Przypadek użycia Restart systemu Jan Kowalski Administrator systemu Wejście z kartą Adam Malina Pracownik Osoba informowana Poinformowanie Gość Konkretny klient Wypłata z konta Klient Źródło: K.Subieta wykł.

12. Konstrukcja modelu • Konstrukcja modelu opiera się na kilku krokach • Wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje zasadę: “nie opisuj przypadków użycia w sposób, który nie jest łatwo zrozumiały dla użytkownika”. Sporządzenie słownika pojęć Dokument: Słownik pojęć Określenie aktorów Określenie przypadków użycia Dokument: Opis aktorów Tworzenie opisu każdego przypadku użycia, podział na nazwane części, znalezienie wspólnych części w różnych przypadkach użycia Diagram przypadków użycia plus dokument opisu przypadków użycia Źródło: K.Subieta wykł.

13. Słownik dotyczy dziedziny problemowej. Tworzenie go polega na wyłowieniu wszystkich terminów z wymagań użytkownika. Terminy mogą odnosić się do aktorów, przypadków użycia, obiektów, operacji, zdarzeń, itp. Terminy w słowniku powinny być zdefiniowane w sposób precyzyjny i jednoznaczny. Posługiwanie się terminami ze słownika powinny być regułą przy opisie każdego kolejnego problemu, sytuacji czy modelu. Sporządzanie słownika pojęć Źródło: K.Subieta wykł.

14. Warsztaty przypadków użycia (wersja uproszczona Use-Case Workshop) • Warsztaty przypadków użycia to spotkanie osób uczestniczących w projekcie mające na celu opracowanie modelu biznesowego opisanego notacją diagramów przypadków użycia. • Opisany przebieg warsztatu jest nieco uproszczony w stosunku do wytycznych opisanych w Rational Unified Process ™. • Uproszczenia wynikają z ograniczeń dotyczących wyposażenia i czasu jakim dysponują studenci na ćwiczeniach. • W tej uproszczonej wersji do realizacji warsztatu konieczne są: • co najmniej kilka kartek formatu A4, • kilkanaście formatu A5 (lub również A4), • pisaki w dwóch kolorach (np. niebieski, i czerwony), • bardzo pomoże duży stół lub tablica do rozłożenia lub rozwieszenia kartek, • ponadto konieczne jest posiadania dokumentu wymagań i słownika. Źródło: K.Subieta wykł.

15. cz. I warsztatów – identyfikacja aktorów • Na środku jednej z kartek formatu A4 należy narysować kształt przypominający chmurkę (korzystamy teraz z niebieskiego pisaka). • Teraz należy zastanowić się jakie osoby (lub jakiego rodzaju użytkownicy) będą korzystały z systemu - to Aktorzy. • Interesują nas tylko te osoby, które pracują bezpośrednio przy komputerze. • Staramy się określić rolę takiej osoby (np. Magazynier, Administrator, Księgowy, Sprzedawca, itp.). • Należy zwrócić uwagę na to, aby zbytnio nie generalizować i nie wskazywać aktorów typu „Użytkownik Systemu”. • Dla każdego aktora rysujemy postać „chłopka” (stick man) na kartce z narysowaną „chmurką” i opisać ją nazwą określającą rolę. Źródło: K.Subieta wykł.

16. cz. II warsztatów – identyfikacja przypadków użycia • Teraz wyciągamy nową kartkę formatu A4 i przerysowujemy na nią aktorów jednego po drugim zastanawiając się za każdym razem gdy na kartce pojawia się nowy aktor, jakie czynności w systemie będzie on realizować. • Dla każdej czynności dorysowujemy na kartce przypadek użycia. • Nazywamy go skrótem myślowym dobrze określającym ową czynność. Źródło: K.Subieta wykł.

17. cz. III warsztatów – opis przypadków użycia • Bierzemy mniejsze kartki. • Przenosimy na nie każdy przypadek użycia wraz z aktorem, który go realizuje (jeden przypadek użycia na jednej kartce). • Opisujemy w trzech zadaniach czynność realizowaną w ramach danego przypadku użycia. • Możemy też wypisać kolejne kroki wykonywane w ramach realizacji określonej funkcji. Źródło: K.Subieta wykł.

18. cz. IV warsztatów – przypadki użycia i wymagania • Teraz musimy skonfrontować ze sobą dwie wizje systemu: tę zarysowaną w dokumencie wymagań oraz tę, którą opracowano w ramach warsztatu przypadków użycia. • Do każdej z kartek zawierających opis przypadku użycia dopisujemy czerwonym pisakiem numer wymagania (numery wymagań) najniższego poziomu, które jest odpowiedzialne za realizację danej czynności. Źródło: K.Subieta wykł.

19. Model organizacji (business model) • Model obiektowy organizacji (business object model) – model organizacji, model działania organizacji, w której w przyszłości będzie realizowany projekt informatyczny • Synonimy ang. business model, model biznesowy, model procesów biznesowych • Model integruje cztery aspekty • Pracowników organizacji (business workers) • Byty występujące w organizacji (Business entities) • Przypadki użycia (Business use-cases) • Realizacje przypadków użycia (Business usce-cse realizations)

20. Cele modelowania • Zrozumienie struktury i działania organizacji, której będzie tworzony system informatyczny • Zrozumienie obecnych problemów organizacji i wskazanie potencjalnych usprawnień • Upewnienie się, że klienci, użytkownicy i twórcy oprogramowania w sposób jednakowy postrzegają organizację i jej problemy • Umożliwienie „wyprowadzenia” wymagań względem systemu (model jako źródło dla dyscypliny formułowania wymagań)

21. Narzędzia typu e-biznes • W szczególności modelowanie organizacji zaleca się, jeśli elementem organizacji jest tzw. e-biznes (znowu – „nie jako modne słówko”, buzzword) • Klasyfikacja narzędzi e-biznes • C2B; ang. Customer to business; aplikacje wspomagające na zakup towarów i usług za pośrednictwem sieci Internet • B2B; ang. Business to business; oprogramowanie służące do automatyzacji wymiany danych w ramach łańcucha dostaw pomiędzy dwoma firmami (organizacjami); • B2C; Business to customer; pasywne oprogramowanie dostarczające informacji klientom (np. newsletter, RSS) • C2C; ang. Customer to customer; oprogramowanie pozwalające wymieniać się informacjami. Zachodzi z pewną pomocą dostawcy usługi/oprogramowania. (np. aukcje)

22. Motywacje • Oprogramowanie nie jest już jedynie dodatkiem do zasadniczego zestawu narzędzi działania organizacji, jest zasadniczym narzędziem • Oprogramowanie musi zatem pasować do organizacji i być przydatne , na pewno - nie może pozostawać kosztownym „wodotryskiem” • Oprogramowanie musi efektywnie wpływać na sposób prowadzenia działalności (nie chodzi jedynie o automatyzację pracy)

23. Wskazywane scenariusze • „Organisation Chart” (schemat organizacji); • tworzony jest prosty, podstawowy model organizacji i zachodzących w niej procesów. • jest elementem projektu informatycznego • „Domain Modeling” (modelowanie dziedziny); • tworzony jest dla systemów, w których nadrzędnym celem jest kontrolowanie i prezentacja informacji w obrębie jednej dziedziny przedmiotowej • Jest elementem projektu informatycznego • „One Business, Many Systems” (jedna organizacja, wiele systemów); • tworzony jest w celu opracowania jednego (spójnego) modelu stanowiącego bazę dla kilku projektów informatycznych lub dla jednego ale obszernego systemu • Jest autonomicznym projektem

24. Wskazywane scenariusze • „Generic Business Model” (model typowej organizacji); • tworzony jest w celu opracowania jednego (spójnego) modelu typowej organizacji w celu ujednolicenia wymagań dla systemów przeznaczonych do użytku w wielu organizacjach podobnego typu • jest elementem projektu informatycznego • ułatwia selekcję wymagań względem priorytetu • „New Business” (nowy pomysł na działalność); • tworzony jest dla systemów, w których docelowym polem działania będzie zupełnie nowa (nowatorska) działalność • jest autonomicznym projektem • „Revamp” (zmiana struktury i funkcjonowania organizacji); • tworzony jest w przypadku, w którym organizacja pragnie diametralnie zmienić sposób funkcjonowania (BPR – business process reengineering) • jest autonomicznym projektem

25. Pracownicy organizacji • Pracownik organizacji (business worker) reprezentuje rolę lub zestaw ról jaką może pełnić jakaś osoba (jakieś osoby) w modelowanej organizacji • Pracownik organizacji reprezentowany jest w modelu przez klasę o stereotypie <<business worker>> • Dla stereotypu tego przewidziano określony w metodyce RUP ™ symbol.

26. Byty organizacji • Byt organizacji (business entity) reprezentuje dowolną rzecz jaką "zajmują" się pracownicy organizacji • Bytem może być dowolny zasób, zdarzenie lub byt pojęciowy występujący w organizacji • Byt organizacji reprezentowany jest w modelu przez klasę o stereotypie <<business entity>> • Dla stereotypu tego przewidziano określony w metodyce RUP ™ symbol.

27. Realizacje przypadków użycia • Realizacja przypadku użycia opisuje sposób współdziałania pracowników i bytów organizacji • W metodyce RUP ™ realizację przypadku użycia przedstawia się w postaci trzech rodzajów diagramów języka UML • Diagramu klas • Diagramu czynności • Diagramu przebiegu • Odpowiedni element języka UML - przypadek użycia o stereotypie <<use-case realization>> • Dla stereotypu tego przewidziano określony w metodyce RUP ™ symbol

28. Konstrukcja modelu (identyfikacja bytów, podejście uproszczone) • Model organizacji - duża zawartość informacji • W uproszczonym podejściu warto zastosować metodykę identyfikacji bytów • Cel identyfikacji bytów – określenie zbioru bytów, które w dalszym procesie analizy staną się: • Klasami • Klasami aktywnymi • Zbiorami danych

29. Identyfikacja (podejście uproszczone) • Przebieg procesu identyfikacji bytów może być następujący: • Przygotować roboczy wydruk słownika projektu • Utworzyć nowy diagramu klas • Nanieść na diagram klasy reprezentujące aktorów z diagramu Przypadków Użycia i ustaw ich stereotyp na <<Business Worker>> • Dla każdego z aktorów ustalić, jakimi "rzeczami" może się on zajmować w organizacji

30. Identyfikacja (podejście uproszczone) • Przebieg procesu identyfikacji bytów c.d.: • Wprowadzić na diagram klasy odpowiadające tym rzeczom i połączyć je z klasą reprezentującą pracownika relacją zależności • Można sprawdzić, czy ta "rzecz" jest opisana w słowniku projektu, jeśli tak, to na roboczym wydruku skreśl ów termin, • Jeśli już wydaje się, że opisano wszystkie rzeczy, sprawdzić, czy w słowniku projektu są jeszcze jakieś terminy (rzeczowniki), dla których nie ma żadnych klas • Jeśli takie terminy istnieją to wprowadzić je na diagram klas i połączyć z określoną klasą reprezentującą pracownika • Nadać klasom podstawowe atrybuty (takie, które nasuwają się od razu)

31. Przykładowy diagram klas

32. Przykład - opis dziedziny problemowej • Pokazuje przejście od modelu organizacji do modelu analitycznego • Pewna firma świadczy usługi w zakresie outsourcingu IT. • Podpisuje umowy z klientami, którzy posiadają bardziej rozbudowaną infrastrukturę informatyczną. • Realizacja umowy polega na: • usuwaniu awarii sprzętu i oprogramowania, • pracach prewencyjnych, • pracach rozwojowych.

33. Opis dziedziny problemowej • Obsługę konkretnego klienta zwykło się nazywać “Projektem”. • Projekt to zazwyczaj obsługa infrastruktury w siedzibie klienta, ale także w innych lokalizacjach, tj. innych miejscach prowadzenia działalności przez klienta. • Projekty obsługiwane są rotacyjnie, tzn. pracownicy firmy usługodawcy zgodnie z opracowanym harmonogramem odwiedzają określone lokalizacje. • Niekiedy wizyta ma charakter całodziennego dyżuru. • Dyżury są zakontraktowane w umowach. Na przykład z klientem X obowiązuje umowa, w której wskazano, że pracownik firmy usługodawcy będzie dostępny w siedzibie klienta X dwa dni robocze w tygodniu od 8:00 do16:00.

34. Opis dziedziny problemowej – scena 1 Jest nowy temat. Prezes firmy X skarży się na niską wydajność przyłącza sieci Internet. Zobacz mają tam jakieś stare urządzenia. To nie jest zatem tylko kwestia przyłącza. Trzeba zmodernizować cały węzeł sieciowy. Pytanie, czy mają na to pieniądze. Jest kasa. Możemy kupić zabawek za 10 tysięcy, a koszt miesięczny abonamentu nie może przekroczyć 300 zł. Zajmijcie się tym z chłopakami, musimy się wyrobić do końca miesiąca. Ty zrób specyfikację zakupów i wyznacz zadania dla chłopaków.

35. Opis dziedziny problemowej – scena 2 Na prośbę Starego zrobiłem specyfikację do zakupów dla X S.A. Zabawki sieciowe przyjdą jutro (szafka i switch, WiFi). Trzeba je poskładać i zamontować. Po jutrze przyjdzie software do QoSa, zainstaluj go. Potem załatw z TPSA podniesienie łącza do DSL 2. O.K. zrobię to. Będę potrzebował jakichś trzech dniówek. Zamelduj mi potem w mailu ile godzin Ci to zajęło. Ostatnio wydaje mi się, że trzeba będzie z nimi porozmawiać o tym, żeby wykupili jeszcze jeden dzień. Napisz dokładnie co robiłeś – muszę mieć jakieś argumenty.

36. Opis dziedziny problemowej scena 3 Faktycznie – tandeta. Jak to mogło do tej pory działać?!! Samo rozplątanie tych kabli to robota na parę ładnych godzin.

37. Co będziemy modelować – zakres modeli? System ITCMMS Zarządzanie pracą Modelowanie organizacji Realizacja przypadków użycia organizacji Obsługa tematów Nowy temat Model przypadków użycia systemowych Rejestracja tematu Realizacja przypadków użycia systemowych

38. Co będziemy modelować – zakres modeli?

39. Spotkanie z klientem Tego nie było w scenkach, ale była o tym mowa – tu musi zadziałać nasza wyobraźnia! 1. Zgłoszenie problemu 2. Pojawienie się nowego wątku 3. Odnotowanie wątku np. w notesie sponsora 1. Analiza problemu 2. Zlecenie obsługi wątku 1. Analiza problemu 2. Wyznaczenie zadań 3. Zlecenie realizacji zadań 1. Wykonanie czynności w ramach realizacji zadania 2. Odnotowanie czasu pracy Prześledźmy proces biznesowy (proces organizacyjny)

40. Model organizacji – od czego zacząć • Rookie: To jest trochę skomplikowane, co powinniśmy zrobić, żeby sobie wszystko poukładać w głowie? • Guru: Trzeba postępować metodycznie krok po kroku, i w danym momencie koncentrować się tylko na danym zadaniu. • R: Jakie zadania musimy zrealizować w pierwszej kolejności. • G: Najlepiej zacząć od sporządzenia słownika pojęć (RUP – Capturing common business vocabulary). • R: Jak to zrobimy ?

41. Model organizacji – od czego zacząć • G. Zbierzemy nasze materiały i wynotujemy wszystkie pojęcia, które wydadzą się nam istotne. • R: Skąd będziemy wiedzieć co jest istotne, a co nie? • G: Na to niestety nie mam gotowego przepisu, trzeba „mieć nosa”, to przychodzi z czasem. Na początku można przyjąć zasadę: „od przybytku głowa nie boli” i jeśli mamy wątpliwość co do istotności danego terminu – odnotować go. • R: Jakim narzędziem się posłużymy? • G: Wystarczy edytor MS Word, dla większych projektów lepiej posłużyć się elementem narzędzia CASE np. Rational Requisite Pro™.

42. Poszukiwanie pojęć • Pewna firma świadczy usługi w zakresie outsourcingu IT. • Podpisuje umowy z klientami, którzy posiadają bardziej rozbudowaną infrastrukturę informatyczną. • Realizacja umowy polega na: • usuwaniu awariisprzętu i oprogramowania, • pracach prewencyjnych, • pracach rozwojowych.

43. Poszukiwanie pojęć • Obsługę konkretnego klienta zwykło się nazywać “Projektem”. • Projekt to zazwyczaj obsługa infrastruktury w siedzibie klienta, ale także w innych lokalizacjach, tj. innych miejscach prowadzenia działalności przez klienta. • Projekty obsługiwane są rotacyjnie, tzn. pracownicyfirmy usługodawcy zgodnie z opracowanym harmonogramem odwiedzają określone lokalizacje. • Niekiedy wizyta ma charakter całodziennego dyżuru. • Dyżury są zakontraktowane w umowach. Na przykład z klientem X obowiązuje umowa, w której wskazano, że pracownik firmy usługodawcy będzie dostępny w siedzibie klienta X dwa dni robocze w tygodniu od 8:00 do16:00.

44. Spotkanie z klientem Tego nie było w scenkach, ale była o tym mowa – tu musi zadziałać nasza wyobraźnia! 1. Zgłoszenie problemu 2. Pojawienie się nowego wątku 3. Odnotowanie wątku np. w notesiesponsora 1. Analiza problemu 2. Zlecenie obsługi wątku koordynatorowi 1. Analiza problemu 2. Wyznaczenie zadań 3. Zlecenie realizacji zadań 1. Wykonanie czynności w ramach realizacji zadania 2. Odnot. czasu pracy Poszukiwanie pojęć

45. Poszukiwanie pojęć – słownik organizacji Firma usługodawcy Firma świadcząca usługi outsourcingowe. Klient (firma usługobiorcy) Klient firmy usługodawcy korzystający z usług outsourcingu. Pracownik Osoba zatrudniona w firmie usługodawcy na podstawie umowy o pracę, umowy cywilno-prawnej, kontraktu menadżerskiego. Projekt Współpraca firmy usługodawcy z klientem w zakresie outsourcingu IT. Koordynator Pracownik odpowiedzialny z koordynację działań związanych z określonym projektem lub projektami. Sponsor Członek zarządu firmy usługodawcy wspierający działania określonych projektów. Siedziba Siedziba firmy klienta podana jako siedziba w dokumentach rejestrowych. Infrastruktura informatyczna Pozostające pod opieką firmy usługodawcy elementy infrastruktury. Element infrastruktury Serwer, stacja robocza, terminal, urządzenie sieciowe, urządzenie zewnętrzne, oprogramowanie. Lokalizacja Miejsce prowadzenia działalności przez klienta, w którym mogą byś świadczone usługi związane z prowadzeniem projektu. Serwer Komputer pełniący rolę dostawcy usług dla innych komputerów. Stacja robocza Komputer klienta (zlokalizowany na biurku użytkownika). Wątek (temat) Obszerny tematycznie zakres działań związanych z realizacją określonego celu, np: - Wdrożenie nowego systemu ERP - Bieżące utrzymanie ruchu IT - Budowa sieci korporacyjnej Zadanie Zadanie wyznaczone pracownikowi w ramach działań związanych z danym wątkiem, np. w ramach wątku „Wdrożenie systemu ERP”: - Instalacja serwera bazy danych MS SQL Serwer - Opracowanie podziału bazy indeksów materiałowych - Konfiguracja algorytmów płacowych dla umów o pracę w systemie 6 godzinowym - Instalacja czytnika kart RCP Czynność Efektywne przepracowanie określonego czasu przez pracownika w ramach realizacji określonego zadania, np. w ramach zadania „Instalacja czytnika kart RCP”: - Montaż czytnika na ścianie w budynku portierni, Kowalski Jan, 2006-11-02, 2 godziny - Rozprowadzenie instalacji elektrycznej i logicznej czytników, Kowalski Jan, 2006-11-03, 4 godziny - Podłączenie czytnika do stacji roboczej, testy, Kowalski Jan, 2006-11-05, 4 godziny Zgłoszenie problemu Poinformowanie sponsora o poważnym problemie przez klienta. Odnotowanie wątku Utrwalenie informacji o problemie zgłoszonym przez klienta Zlecenie obsługi wątku Skierowanie do koordynatora prośby o zajęcie się danym wątkiem (tematem) Zlecenie zadania Skierowanie do koordynatora polecenia wykonania określonego zadania i nadzorowanie jego wykonania. Wykonanie czynności Wykonanie czynności przez pracownika na podstawie polecenia koordynatora lub z własnej inicjatywy. Odnotowanie czasu pracy Zapisanie liczby godzin poświęconych na realizacje zadania Wyznaczenie zadania Wydzielenie zadania w ramach wątku

46. Poszukujemy aktorów • R: Och! Dużo tego, w dodatku strasznie wymieszane. • G: Tak zgadzam się, gdyby pojęć było więcej musielibyśmy pogrupować je np. osobno przedmioty, osobno osoby, osobno czynności. • R: Co teraz zrobimy? • G. Wyłowimy ze słownika pojęcia, które oznaczają osoby. • R: Po co? • G: Znajdziemy „kandydatów” na aktorów. • G: Potem wyłowimy pojęcia oznaczające jakieś czynności. • R: Po co? • G: Znajdziemy „kandydatów” na przypadki użycia.

47. Poszukiwanie aktorów Firma usługodawcy Firma świadcząca usługi outsourcingowe. Klient (firma usługobiorcy) Klient firmy usługodawcy korzystający z usług outsourcingu. Pracownik Osoba zatrudniona w firmie usługodawcy na podstawie umowy o pracę, umowy cywilno-prawnej, kontraktumenadżerskiego. Projekt Współpraca firmy usługodawcy z klientem w zakresie outsourcingu IT. Koordynator Pracownik odpowiedzialny z koordynację działań związanych z określonym projektem lub projektami. Sponsor Członek zarządu firmy usługodawcy wspierający działania określonych projektów. Siedziba Siedziba firmy klienta podana jako siedziba w dokumentach rejestrowych. Infrastruktura informatyczna Pozostające pod opieką firmy usługodawcy elementy infrastruktury. Element infrastruktury Serwer, stacja robocza, terminal, urządzenie sieciowe, urządzenie zewnętrzne, oprogramowanie. Lokalizacja Miejsce prowadzenia działalności przez klienta, w którym mogą byś świadczone usługi związane z prowadzeniem projektu. Serwer Komputer pełniący rolę dostawcy usług dla innych komputerów. Stacja robocza Komputer klienta (zlokalizowany na biurku użytkownika). Wątek (temat) Obszerny tematycznie zakres działań związanych z realizacją określonego celu, np: - Wdrożenie nowego systemu ERP - Bieżące utrzymanie ruchu IT - Budowa sieci korporacyjnej Zadanie Zadanie wyznaczone pracownikowi w ramach działań związanych z danym wątkiem, np. w ramach wątku „Wdrożenie systemu ERP”: - Instalacja serwera bazy danych MS SQL Serwer - Opracowanie podziału bazy indeksów materiałowych - Konfiguracja algorytmów płacowych dla umów o pracę w systemie 6 godzinowym - Instalacja czytnika kart RCP Czynność Efektywne przepracowanie określonego czasu przez pracownika w ramach realizacji określonego zadania, np. w ramach zadania „Instalacja czytnika kart RCP”: - Montaż czytnika na ścianie w budynku portierni, Kowalski Jan, 2006-11-02, 2 godziny - Rozprowadzenie instalacji elektrycznej i logicznej czytników, Kowalski Jan, 2006-11-03, 4 godziny - Podłączenie czytnika do stacji roboczej, testy, Kowalski Jan, 2006-11-05, 4 godziny Zgłoszenie problemu Poinformowanie sponsora o poważnym problemie przez klienta. Odnotowanie wątku Utrwalenie informacji o problemie zgłoszonym przez klienta Zlecenie obsługi wątku Skierowanie do koordynatora prośby o zajęcie się danym wątkiem (tematem) Zlecenie zadania Skierowanie do koordynatora polecenia wykonania określonego zadania i nadzorowanie jego wykonania. Wykonanie czynności Wykonanie czynności przez pracownika na podstawie polecenia koordynatora lub z własnej inicjatywy. Odnotowanie czasu pracy Zapisanie liczby godzin poświęconych na realizacje zadania Wyznaczenie zadania Wydzielenie zadania w ramach wątku

48. Model organizacji – diagram przypadków użycia – aktorzy • G: Czy można jeszcze coś do tego dodać? • R: Jakieś dodatkowe informacje? • G: Właśnie! Można uporządkować klasyfikatory i wprowadzić uogólnienia. • R: A właśnie! Przecież sponsor i koordynator to też pracownicy. To się na pewno przyda.

49. Poszukiwanie aktorów i przypadków użycia Firma usługodawcy Firma świadcząca usługi outsourcingowe. Klient (firma usługobiorcy) Klient firmy usługodawcy korzystający z usług outsourcingu. Pracownik Osoba zatrudniona w firmie usługodawcy na podstawie umowy o pracę, umowy cywilno-prawnej, kontraktu menadżerskiego. Projekt Współpraca firmy usługodawcy z klientem w zakresie outsourcingu IT. Koordynator Pracownik odpowiedzialny z koordynację działań związanych z określonym projektem lub projektami. Sponsor Członek zarządu firmy usługodawcy wspierający działania określonych projektów. Siedziba Siedziba firmy klienta podana jako siedziba w dokumentach rejestrowych. Infrastruktura informatyczna Pozostające pod opieką firmy usługodawcy elementy infrastruktury. Element infrastruktury Serwer, stacja robocza, terminal, urządzenie sieciowe, urządzenie zewnętrzne, oprogramowanie. Lokalizacja Miejsce prowadzenia działalności przez klienta, w którym mogą byś świadczone usługi związane z prowadzeniem projektu. Serwer Komputer pełniący rolę dostawcy usług dla innych komputerów. Stacja robocza Komputer klienta (zlokalizowany na biurku użytkownika). Wątek (temat) Obszerny tematycznie zakres działań związanych z realizacją określonego celu, np: - Wdrożenie nowego systemu ERP - Bieżące utrzymanie ruchu IT - Budowa sieci korporacyjnej Zadanie Zadanie wyznaczone pracownikowi w ramach działań związanych z danym wątkiem, np. w ramach wątku „Wdrożenie systemu ERP”: - Instalacja serwera bazy danych MS SQL Serwer - Opracowanie podziału bazy indeksów materiałowych - Konfiguracja algorytmów płacowych dla umów o pracę w systemie 6 godzinowym - Instalacja czytnika kart RCP Czynność Efektywne przepracowanie określonego czasu przez pracownika w ramach realizacji określonego zadania, np. w ramach zadania „Instalacja czytnika kart RCP”: - Montaż czytnika na ścianie w budynku portierni, Kowalski Jan, 2006-11-02, 2 godziny - Rozprowadzenie instalacji elektrycznej i logicznej czytników, Kowalski Jan, 2006-11-03, 4 godziny - Podłączenie czytnika do stacji roboczej, testy, Kowalski Jan, 2006-11-05, 4 godziny Zgłoszenie problemu Poinformowanie sponsora o poważnym problemie przez klienta. Odnotowanie wątku Utrwalenie informacji o problemie zgłoszonym przez klienta Zlecenie obsługi wątku Skierowanie do koordynatora prośby o zajęcie się danym wątkiem (tematem) Zlecenie zadania Skierowanie do koordynatora polecenia wykonania określonego zadania i nadzorowanie jego wykonania. Wykonanie czynności Wykonanie czynności przez pracownika na podstawie polecenia koordynatora lub z własnej inicjatywy. Odnotowanie czasu pracy Zapisanie liczby godzin poświęconych na realizacje zadania Wyznaczenie zadania Wydzielenie zadania w ramach wątku

50. Model organizacji – diagram przypadków użycia