Projekt Spaghetti. Wykorzystanie podejścia obiektowego w zarządzaniu projektami. Katedra Badań Operacyjnych

Transkrypt

1 Projekt Spaghetti Wykorzystanie podejścia obiektowego w zarządzaniu projektami Łukasz Tync kontakt@lukasztync.com Katedra Badań Operacyjnych Uniwersytet Ekonomiczny w Katowicach

2 Agenda Wprowadzenie Heterogeniczne środowisko projektowe (przykład) Podejście obiektowe (obiekt, klasa) Projekt jako sieć obiektów (czynności, zasoby, logika biznesowa) Kontekst, Referencja, Interfejs specyficzne obiekty Wzorce projektowe Podsumowanie Pytania / Dyskusja

3 Projekt Za normą DIN można w uproszczeniu zdefiniować zasady dotyczące projektu: 1. Zlecenie ma formę pisemną 2. Projekt ma wytyczone cele 3. Projekt jest odgraniczony od innych przedsięwzięć 4. Odpowiedzialność ponosi zleceniodawca 5. Oficjalnie wyznaczono kierownika projektu 6. Zagwarantowano udział wszystkich zainteresowanych osób 7. Zatwierdzono plan ramowy

4 Przykład MIĘDZYNARODOWA ORGANIZACJA PROSTY PROJEKT PROSTY PROJEKT PROSTY PROJEKT PROSTY PROJEKT INNY PROSTY PROJEKT

5 Środowisko projektowe dzisiaj globalizacja procesów gospodarczych duża ilość zależności / powiązań pomiędzy projektami rozproszone zespoły projektowe (lokalizacja, organizacja, kompetencje, kultura, strefy czasowe, rotacja ) różnorodność wykorzystywanych metodyk rosnąca dynamika zmian organizacje wirtualne

6 Konflikt??? ELASTYCZNOŚĆ SZYBKOŚĆ REAKCJI WIRTUALNOŚĆ ROZBUDOWANE PROCEDURY STANDARYZACJA STRUKTURA SZTYWNE METODYKI

7 Rozwiązanie narzędzia (?) możliwie dokładne modelowanie rzeczywistych powiązań w projekcie odwzorowanie powiązań projektu z otoczeniem i innymi projektami wykorzystanie różnych metodyk zarządzania projektami wszystkie obszary PM łatwa integracja narzędzi łączenie środowisk projektowych ad hoc

8 Spaghetti Code Niejasny podział odpowiedzialności Struktura trudna do analizy, modyfikacji i rozbudowy Zmiana musi być wprowadzana w wielu miejscach programu Poprawienie jednego błędu powoduje ryzyko powstania kolejnego w trudno identyfikowalnych miejscach

9 Programowanie Obiektowe Programowanie obiektowe ( ang. Object Oriented Programming OOP) to proces pisania programu, bazujący na dobrze zdefiniowanych modelach projektowych. Modele te stanowią graficzne ilustracje, które reprezentują różne aspekty obiektów, z których pochodzą ich funkcje, oraz właściwości i ich wzajemne oddziaływania. jedną z ważniejszych przesłanek przemawiających za stosowaniem programowania obiektowego, jest możliwość zapanowania nad chaosem, towarzyszącym nieodłącznie tworzeniu aplikacji,...

10 Stawiam tezę, że przeniesienie podejścia obiektowego na grunt zarządzania projektami może pomóc utworzyć swoisty szkielet, metametodologię elastyczne narzędzie pozwalające w sposób kompleksowy kontrolować projekty całych grup organizacji.

11 Założenia Metametodologia / Szkielet umożliwiający łatwą integrację istniejących metodyk i narzędzi PM Wspomagana przez system informatyczny Uniwersalna Ustrukturalizowana ale elastyczna

12 Wielowymiarowa sieć obiektów zamiast odseparowanych od siebie projektów. Coraz trudniej jest traktować projekt jako byt odizolowany od swojego otoczenia. Różna natura powiązań - projekty współdzielą zasoby, następują jedne po drugich, bądź zawierają się w sobie. Zmiany w jednym z nich mogą nieść ryzyko również dla pozostałych.

13 Struktura sieci projektów ORGANIZACJA Programy A B D E Projekty A.1. A.2. C E.1. A.3. E.2. Etapy C.1. C.3. C.2. C.4.

14 Budowa obiektowa i komunikacja między obiektami model zbudowany z luźno powiązanych obiektów (projekty, zasoby, logika i reguły biznesowe) obiekty mogą wchodzić ze sobą w interakcje komunikować się ze sobą autonomiczność obiektów w określonym zakresie Wydzielony obszar odpowiedzialności obiekty mogą być składane z mniejszych obiektów (kompozycja), bądź tworzone na wzór innych, przejmując większość ich cech, jednakże możliwe jest ich rozbudowanie o nowe cechy, bądź zachowania (dziedziczenie).

15 Klasy Wzorzec, na podstawie którego budowane są obiekty. Repozytorium klas powinno być wspólne dla całego środowiska projektowego / organizacji. W ramach określonego obszaru możliwe jest budowanie własnych klas, ale powinna zostać zachowana zgodność z globalnym repozytorium.

16 Kompozycja i dziedziczenie Kompozycja - tworzenie złożonych obiektów, czy całych systemów poprzez składanie ich z prostszych, istniejących już obiektów jak z klocków Dziedziczenie - możliwość oparcia nowo tworzonej klasy na już istniejącej. W efekcie czego, nowopowstała klasa będzie posiadała w większości te same atrybuty, co klasa matka, przy czym zostanie rozbudowana o dodatkowe atrybuty bądź zachowania.

17 Obiekty Odwzorowują rzeczywistość (np. obiekt faktura) Atrybuty (np. numer, data wystawienia) Metody (np. utwórz, drukuj, zamknij, ) Składają się z innych obiektów (nagłówek, linie, ) Mogą dziedziczyć po innym obiekcie (obiekt faktura korygująca ma te same atrybuty jak zwykła faktura plus numer faktury korygowanej).

18 Otoczenie obiektu Warstwowa struktura obiektu WARSTWA INTERFEJSU / KOMUNIKACJI CE PRO DURY WARSTWA REALIZACJI

19 Komunikacja poprzez interfejsy PROJEKT PERT PROJEKT CPM INTERFEJS PERT A = Z+0,1*B M = Z+0,6*B B = Z+B 2 3 INTERFEJS CPM M = Z+0,8*B Łańcuch Krytyczny: Z1 Z2 Z3 Z B

20 Klasa Context Klasa Context tworzy pewien wydzielony obszar, grupując czynności projektu na tym samym poziomie szczegółowości, tworzące spójną całość. W ramach takiego obszaru działają również przypisane do niego obiekty klasy Manager. Obiekty tej klasy realizują dziedzinowy podział odpowiedzialności (poszczególne obszary PM).

21 Klasa Context Manager Area (active) Activity Area - Gant Chart (passive) Local Object Repository (logic) Inherited Object Repository (logic)

22 Object Repository - Dziedziczenie Manager Area X A B Activity Area - Gant Chart A B Local Object Repository Inherited Object Repository A B

23 Reference i Interface Reference - pusty obiekt, zawierający jedynie wskazanie (referencję) do rzeczywistej instancji obiektu, do którego inne obiekty mogą się odwoływać w sposób identyczny jak do rzeczywistej instancji. Interface - definiuje on sposób komunikacji obiektu, którego jest częścią, poprzez zdefiniowanie zestawu niezbędnych metod. W ramach jednego obiektu może być zaimplementowane wiele interfejsów, które mogą być dowolnie wykorzystywane przez odwołujące się do nich obiekty.

24 Klasa Activity Obiekty klasy Activity odpowiadają poszczególnym zadaniom, bądź projektom. Każda czynność składa się między innymi z obiektu Context, zawierający z kolei czynności podrzędne (bardziej szczegółowe). Powstaje hierarchiczna struktura obiekt reprezentujący cały projekt zawiera wewnątrz wszystkie podprojekty, a te z kolei zawierają poszczególne zadania.

25 Klasa Resource Obiekty klasy Resource reprezentują poszczególne zasoby niezbędne do realizacji projektu. Podobnie jak w przypadku, czynności, i tutaj pojawiają się parametry oraz wewnętrzny obiekt klasy context, zawierające odniesienia (refference) do wszystkich zadań, do których dany zasób jest przyporządkowany. Dodatkowo mogą tutaj się również pojawić indywidualne czynności, które zasób musi wykonać, a które nie są częścią jakiegokolwiek innego projektu. Jeżeli odwzorujemy te zadania również na wykresie Ganta, uzyskamy indywidualny harmonogram zadań danego zasobu.

26 Klasy Activity i Resource Projekt A Czynność A.1. Czynność A.2 Czynność A.3, Czynność A.4. Projekt B Czynność B.1. Czynność B.2. Czynność B.3. Zasób X Referencja do Czynności A.1. Referencja do czynności B.2. Czynność X.1.

27 Klasa Manager Obiekty klasy Manager odpowiadają za kontrolę poszczególnych obszarów zarządzania projektem. Na obiektach tej klasy opiera się wertykalny podział odpowiedzialności. Poszczególne obiekty, w ramach danego kontekstu, będą odpowiadać za określony obszar zarządzania projektem Proponuje się, by tylko te obiekty mogły się komunikować z obiektami spoza kontekstu, w którym się znajdują

28 Podział odpowiedzialności ORGANIZACJA Program A Projekt A.1. Projekt A.2. MANAGERY Etap A.1.1. Etap A.1.2. Etap A.2.1. Program B Projekt B.1. Budget Resources Observer Planer Risk

29 Propozycje managerów Budget Manager koszty (budżet) Resource Manager zasoby ludzkie, zamówienia Quality Manager jakość Risk Manager ryzyko Observer komunikacja Knowledge Manager

30 Resource Manager Manager Area (active) Inherited Object Repository (logic) Local Object Repository (logic) Activity Area - Gant Chart (passive)

31 Budowa modelu abstrakcyjnego - kroki Zaczynając od poziomu całej organizacji 1. Tworzymy Context, będący kontenerem dla wszystkich projektów i programów prowadzonych przez tę organizację. 2. Utworzenie Object Repository dla tego contextu. 3. Zdefiniowanie managerów dla danego contextu, przypisanie im zakresów odpowiedzialności i sparametryzowanie. 4. Wstawienie głównych projektów organizacji jako czynności w activity area, co równocześnie stworzy oddzielny context dla każdego projektu. 5. Jeżeli to konieczne, można rozbudować context każdej z czynności o nowe klasy, tworząc local repository. Rekurencyjne powtarzanie wszystkich kroków od ogółu do szczegółu.

32 Wzorce Projektowe Koncepcja przeniesiona z architektury, z tzw. Języka Wzorców, zakładała definiowanie wzorca, który zawierał opis konkretnego, często spotykanego problemu, wraz z jego rozwiązaniem. Wzorce definiowane są na poziomie abstrakcji, co pozwala na ich implementację przy rozwiązywaniu wielu rzeczywistych, często różnorodnych problemów.

33 Wzorce Projektowe Obserwator obserwuje obiekty za które jest odpowiedzialny i informuje o zmianach wszystkie zainteresowane obiekty. Adapter dostosowuje istniejący interfejs jednego obiektu do obiektu z niego korzystającego. Fabryka abstrakcyjna dostarcza interfejs do tworzenia całych rodzin spokrewnionych lub zależnych od siebie obiektów bez konieczności określania ich klas rzeczywistych knowledge manager

34 Obserwator Z1 Z2 Z1 Z2 Z1 Z2

35 Zastosowanie w analizie ryzyka sygnały wczesnego ostrzegania rozbudowany zestaw reguł identyfikacji ryzyk (różne poziomy wrażliwości ) Przejrzyście zagregowana informacja na poszczególnych poziomach zarządzania Analiza sieci powiązań i identyfikacja powiązań ryzykownych (metody socjometryczne? ) Identyfikowanie ryzykownych wzorców

36 Wzorzec Proxy Mechanizmy kontroli dostępu do poszczególnych kontekstów Tzw. pośrednik wirtualny: Wstępne planowanie Zasoby zbiorowe

37 Wzorzec Fasada Wzorzec fasada zapewnia jeden, zunifikowany interfejs dla całego zestawu interfejsów określonego podsystemu. Fasada tworzy nowy interfejs wysokiego poziomu, który powoduje, że korzystanie z całego podsystemu staje się zdecydowanie łatwiejsze

38 Podsumowanie Korzyści? ustrukturalizowanie całego środowiska projektowego jasne reguły łączenia różnych metodyk (na różnych poziomach organizacji lub dla różnych obszarów PM) możliwość rozbudowy o własne narzędzia oraz łączenie ich z istniejącymi procedurami poprawa komunikacji (zwłaszcza pomiędzy projektami) możliwość identyfikacji i kontroli również nieoczywistych powiązań pomiędzy projektami ucząca się struktura możliwość integracji z otoczeniem zewnętrznym możliwość automatyzacji powtarzalnych procedur

39 Dalsze kroki rozwoju Analiza literatury (do tej pory znaleziono niewiele informacji na temat wykorzystania podejścia obiektowego w PM) Dokładny opis managerów odpowiedzialnych za poszczególne obszary zarządzania projektami zgodnie z PMBOK. Projekt systemu informatycznego wspierającego prezentowane podejście.

40

41 DZIĘKUJĘ ZA UWAGĘ Łukasz Tync