Projekt Spaghetti

Wykorzystanie podejścia obiektowego w zarządzaniu projektami

Łukasz Tync Katedra Badań Operacyjnych

kontakt@lukasztync.com Uniwersytet Ekonomiczny w Katowicach

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

Projekt

Za normą DIN 69901 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

MIĘDZYNARODOWA ORGANIZACJA

Przykład

PROSTY PROJEKT PROSTY PROJEKT PROSTY PROJEKT PROSTY PROJEKT

Ś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

ROZBUDOWANE PROCEDURY STANDARYZACJA STRUKTURA SZTYWNE METODYKI ELASTYCZNOŚĆ SZYBKOŚĆ REAKCJI „WIRTUALNOŚĆ”

Konflikt ???

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

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

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

Stawiam tezę, że przeniesienie podejścia

obiektowego na grunt zarządzania projektami może pomóc utworzyć swoisty szkielet,

meta-metodologię – elastyczne narzędzie pozwalające w sposób kompleksowy

Założenia

• Metametodologia / Szkielet umożliwiający łatwą integrację istniejących metodyk i

narzędzi PM

• Wspomagana przez system informatyczny • Uniwersalna

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

Struktura sieci projektów

ORGANIZACJA A B C D E A.1. A.2. A.3. E.1. E.2. C.1. C.2. C.3. C.4. Programy Projekty Etapy

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

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

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.

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

Warstwowa struktura obiektu

WARSTWA REALIZACJI

WARSTWA INTERFEJSU / KOMUNIKACJI

DURY CE

PRO

PROJEKT PERT _{PROJEKT CPM} INTERFEJS PERT Łańcuch Krytyczny: INTERFEJS CPM Z1 Z2 Z3 ∑ Z B M =∑Z+0,8*B A =∑Z+0,1*B M =∑Z+0,6*B B =∑Z+B 1 2 3 4 1 4 3 2

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

Klasa Context

Manager Area (active)

Activity Area - Gant Chart (passive) In he ri ted Object R ep osit or y (logic ) Loc al Object R ep osit or y (logic )

Object Repository - Dziedziczenie

Manager Area

Activity Area - Gant Chart

In he ri ted Object R ep osit or y Loc al Objec t R ep osit or y A B B A X A _B

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.

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.

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.

Klasy Activity i Resource

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

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ą

Podział odpowiedzialności

ORGANIZACJA Program A Projekt A.1. Projekt A.2. Etap A.1.1. Etap A.1.2. Etap A.2.1. Program B Projekt B.1. MANAGERY Risk Planer Observer Resources Budget

Propozycje managerów

• Budget Manager – koszty (budżet) • Resource Manager – zasoby ludzkie,

zamówienia

• Quality Manager – jakość • Risk Manager – ryzyko

• Observer – komunikacja • Knowledge Manager

Resource Manager

Manager Area (active)

Activity Area - Gant Chart (passive)

In he ri ted Object R ep osit or y ( logic ) Loc al Object R ep osit or y (logic )

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.

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.

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

Obserwator

Z1 Z2 Z1 Z2

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 ? )

Wzorzec Proxy

• Mechanizmy kontroli dostępu do poszczególnych kontekstów

• Tzw. pośrednik wirtualny:

– Wstępne planowanie – Zasoby „zbiorowe”

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

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

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

DZIĘKUJĘ ZA UWAGĘ

Łukasz Tync