Eksperyment 4-P. Implementacja relacji pomiędzy agentami oraz zarządzania

Kolejny eksperyment przeprowadzony w celu weryfikacji predykcyjnej modelu szczegółowego a2M dotyczył sprawdzenia możliwości tworzenia relacji pomiędzy agentami oraz zarządzania przepływem komunikatów między agentami. Wszystkie warunki środowiska przeprowadzenia eksperymentu pozostały bez zmian (ta sama osoba implementująca, ten sam sposób komunikacji, przesłanie specyfikacji przed implementacją. Na rysunku 6.8 przedstawiono założenia dla eksperymentu 4-P.

Tabela 6.8 Założenia do badania 4-P

Kod eksperymentu 4-P

Cel

Celem eksperymentu jest implementacja przepływów informacji (zleceń) pomiędzy agentami. Podczas eksperymentu należy wykazać możliwości implementacji podstawowych relacji hierarchicznych pomiędzy agentami oraz możliwości definiowania komunikatów dla poszczególnych agentów. Poddano także ocenie możliwość odwzorowania w wybranym narzędziu elementów rozproszonego środowiska (zgodnie z podejściem agentowym).

Środowisko badania

IBM Rational Team Concert, narzędzie do kompleksowej realizacji projektów informatycznych, wspomagające procesy zarządcze i wytwórcze.

Implementacja: mgr inż. Paweł Madej, specjalista RTC w UCK Gdańsk Poziomy modelu

Początek realizacji: Styczeń 2012 wykonano Termin

zakończenia:

Luty 2012 wykonano Źródło: opracowanie własne

Opis eksperymentu

Eksperyment 4-P dotyczył badania możliwości implementacji modelu szczegółowego a2M w narzędziu wspomagającym zarządzanie projektami informatycznymi (definiowania relacji pomiędzy agentami). Celem eksperymentu było sprawdzenie, czy w RTC możliwe jest określenie hierarchicznych zależności pomiędzy agentami. Kolejnym etapem eksperymentu było określenie możliwości przesyłania zleceń pomiędzy agentami (wysyłania komunikatów, w zależności od których agent podejmuje określoną akcję).

Podobnie jak w przypadku pierwszego eksperymentu, przygotowano specyfikację dotyczącą poziomu zarządzania, którą przekazano specjaliście do narzędzia RTC w celu określenia możliwości implementacji. Obejmowała ona: strukturę projektu, wysyłanie komunikatów przez agenty, badanie niezależności działania agentów, dobieranie i uruchamianie agentów w zależności od potrzeb oraz możliwość weryfikowania poziomu dojrzałości (implementacja proponowanego w pracy instrumentu pomiarowego do pomiaru dojrzałości).

Definiowanie struktury (hierarchii)

Podczas implementacji hierarchii pomiędzy agentami zauważono pewne problemy natury technicznej RTC. Narzędzie to nie umożliwia bowiem graficznego modelowania zależności pomiędzy obiektami (tym samym agentami). Umożliwia jednak tworzenie kategorii dla poszczególnych obiektów (w tym wypadku agentów). Uznano zatem, że rozwiązaniem problemu dotyczącego definiowania relacji hierarchicznych między agentami, jest ujęcie ich w określonej kategorii. Oznacza to konieczność definiowania kategorii dla jednego agenta (np. AGENT MENEDŻER). Następnie definiuje się kolejną kategorię dla agenta niższego szczebla (np. AGENT LIDER ZESPOŁU).

Takie zastosowanie narzędzia RTC ma jednak swoje minusy, wymaga bowiem nałożenia na wszystkie istniejące elementy dodatkowej kategorii, co niekoniecznie może być zrozumiałe dla przykładowego kierownika projektu, który będzie wybierał szablon modelu szczegółowego a2M do zarządzania swoim projektem. Dlatego też dla prezentacji zależności między agentami zaproponowano dwa warianty.

 Wariant pierwszy oznaczał poszukiwanie takich funkcjonalności w samym narzędziu RTC, które pozwolą na tworzenie zależności hierarchicznych między poszczególnymi agentami.

 Wariant drugi oznaczał konieczność rozbudowy narzędzia RTC o odpowiednią wstyczkę (ang.

plug-in).

Realizując wariant pierwszy zdecydowano się uwzględnić hierarchie agentów poprzez definiowanie niestandardowych atrybutów dla poszczególnych zadań wykonywanych przez agenty oraz definiując ich dodatkowe atrybuty w ramach uprzednio zdefiniowanych cech. Na rysunku 6.6 zaprezentowano odzwierciedlenie relacji pomiędzy przykładowymi agentami projektu.

Rys. 6.6 Odzwierciedlenie relacji pomiędzy przykładowymi agentami Źródło: opracowanie własne

Wariant drugi związany z budową plug-inu nie został ostatecznie wdrożony. Stworzono jednak koncepcję wykorzystania wtyczek z innego narzędzia z rodziny Rational. Okazało się bowiem, że w narzędziu Rational Method Composer - RMC (narzędzie do planowania projektów informatycznych) istnieje szereg komponentów pozwalających na tworzenie relacji hierarchicznych. Ponadto narzędzie RMC posiada wbudowany edytor graficzny w którym można tworzyć relacje pomiędzy obiektami na zasadzie przeciągnij i upuść (ang. drug-and-drop).

Wysyłanie komunikatów przez agenty

Kolejnym procesem weryfikacji modelu szczegółowego a2M (w ramach eksperymentu 4-P) było sprawdzenie na ile opracowany model po procesach implementacji umożliwia organizowanie przepływów informacji między agentami. Zgodnie z przyjętym podejściem agentowym, każdy agent reaguje na określony komunikat i wykonuje swoje zadanie (zgodnie ze zdefiniowanym dla niego zachowaniem). Należało więc sprawdzić czy przyjęty w modelu przepływ komunikatów jest możliwy do implementacji.

Pierwsza analiza wskazywała na konieczność definiowania parametrów komunikatów na poziomie serwera JTS (ang. Jazz Team Serwer), który zapewnia obsługę większości procesów realizowanych w narzędziu RTC. Na poziomie serwera można bowiem skonfigurować przepływy informacyjne pomiędzy poszczególnymi uczestnikami projektu. W odniesieniu do modelu szczegółowego a2M, można na poziomie serwera ustawić parametry przepływu informacji pomiędzy agentami. Każdy agent mający wykonać zadanie otrzyma wiadomość na adres e-mail. Można takie komunikaty przesyłać również za pośrednictwem RTC. Osoba pracująca jako np. AGENT KOORDYNATOR po zalogowaniu do RTC może sprawdzić jakie komunikaty otrzymała (np.

wykonaj zadanie X).

Ostatnim badanym procesem było zarządzanie przepływem zleceń (czyli komunikatów). Zgodnie z przyjętą hierarchią agentów, zlecenia może dokonywać określony agent innym, określonym uprzednio agentom. Postanowiono zatem stosując się do tego założenia, poddać implementacji ograniczenia w przepływie komunikatów. Na rysunku 6.7 przedstawiono mechanizm przesyłania komunikatów między agentami za pośrednictwem RTC.

Rys. 6.7 Mechanizm przesyłania komunikatów między agentami za pośrednictwem RTC Źródło: opracowanie własne

Na rys. 6.7 przedstawiono sposób, w jaki kierownik projektu korzystając z narzędzia RTC może określać sposób przepływu komunikatów poprzez wybranie kanału (poczta elektroniczna, komunikacja wewnątrz RTC). Może również parametryzować te komunikaty nadając im określoną rangę. Na poziomie serwera możliwe jest również określenie atrybutów komunikatów, dzięki czemu nie każdy agent może dokonać zlecenia. Można zatem zarządzać przepływem komunikatów zgodnie z założeniami przyjętymi w modelu szczegółowym a2M.

Niezależność działania agentów

Kolejnym procesem weryfikacji modelu szczegółowego a2M jest sprawdzenie działania agentów w środowisku rozproszonym. Większość prowadzonych badań (rozdział V) wykazało, że w przeważającej większości projektów, uczestnicy projektów pracowali w środowisku rozproszonym.

Jest to typowe zjawisko funkcjonowania zespołu dostawy. Postanowiono poddać weryfikacji, czy środowisko RTC stwarza warunki do implementacji środowiska rozproszonego.

Analiza modelu a2M i jego implementacji w RTC wykazała, że po zdefiniowaniu agentów i określeniu ich atrybutów, agenci mogą pracować w dowolnym miejscu pod warunkiem posiadania dostępu do Internetu. Za pomocą repozytorium projektowego wbudowanego w Jazz Team Serwer każdy agent może wykonywać swoje zadania zdalnie, a efekty pracy umieszczać w repozytorium.

Agenty mogą również integrować/dzielić swoją pracę lub pracować sekwencyjnie, gdyż RTC zapewnia także kontrolę wersji poprzez moduł zarządzania zmianami i konfiguracją. Komunikacja pomiędzy agentami oraz wbudowane w RTC opcje kontroli postępów pozwalają monitorować AGENTOWI MENEDŻEROWI działania wszystkich agentów bez konieczności spotykania się z nimi.

Dobieranie i uruchamianie agentów w zależności od potrzeb

W ramach eksperymentu 4-P model szczegółowy a2M poddany był ocenie możliwości implementacji zmiany struktury zespołu projektowego (dodawania i uruchamiania agentów). Uznano za konieczne sprawdzenie na ile narzędzie, w którym poddania jest implementacji ta funkcjonalność modelu wspomaga dobieranie i uruchamianie agentów w zależności od potrzeb.

Założono zgodnie z podejściem agendowym, że poziom zarządzania modelu szczegółowego a2M w warstwie funkcjonalności prezentuje zasady doboru i uruchomienia agentów w zależności od potrzeb. Obserwacje poczynione podczas weryfikacji predykcyjnej pozwalały zauważyć, że w projekcie informatycznym zapotrzebowanie na określone działania agentów nie zawsze mają charakter ciągły. Oznacza to zatem tyle, że w określonej sytuacji uruchamiany jest odpowiedni agent, który wykonuje swoje zadanie. Zgodnie więc z podanym założeniem sprawdzono jak można poddać implementacji to zdarzenie w RTC. Istnieje możliwość uruchamiania agentów poprzez zmianę statusu przydzielonego zadania. Na rysunku 6.8 przedstawiono ten sposób uaktywnienia agenta do wykonania określonego zadania

Rys. 6.8 Sposób uaktywnienia agenta do wykonania zadania Źródło: opracowanie własne

Czy możliwe jest weryfikowanie dojrzałości? (implementacja instrumentu pomiarowego)

Ostatni z procesów eksperymentu 4-P dotyczył możliwości adaptacji poszczególnych elementów struktury projektowej w zależności od wartości zmiennych decyzyjnych (dojrzałość zespołu, dojrzałość klienta, entropia projektu). W tym celu postanowiono zbadać czy narzędzie RTC jest w stanie umożliwić dokonywanie pomiarów wartości tych zmiennych. Zgodnie z przyjętym

założeniem modelu szczegółowego a2M, kierownik projektu dobiera dobre praktyki zarządzania projektami w zależności od zmierzonych poziomów dojrzałości klienta i zespołu, oraz w zależności od zmierzonej entropii projektu.

Ponieważ takie podejście do pomiaru tych zmiennych nie jest typowym podejściem spotykanym np. w metodach zarządzania projektami informatycznymi, w RTC nie przewidziano odpowiednich funkcjonalności umożliwiających takie analizy. Uznano jednak, że pomiar ten jest na tyle ważny, że należy poddany implementacji w RTC model szczegółowy a2M i rozszerzyć o odpowiednie instrumenty pomiarowe. Na wstępie sprawdzono możliwości rozbudowywania RTC o odpowiednie kwestionariusze ankietowe. Na rysunku 6.8 przedstawiono metodę tworzenia formularzy w RTC

Rys. 6.9 Metoda tworzenia formularzy w RTC Źródło: opracowanie własne

W ramach eksperymentu 4-P na podstawie wstępnej analizy stwierdzono możliwość implementacji instrumentów pomiarowych w modelu szczegółowym a2M w RTC. Narzędzie to umożliwia bowiem nadawanie elementom pracy parametrów (w tym pól do wpisywania informacji czy też pól wyboru). Uznano więc, że atrybuty elementu pracy będą wystarczające do zdefiniowania instrumentów pomiarowych zmiennych decyzyjnych jako dedykowane formularze.

Potraktowanie instrumentu pomiarowego, jako element pracy ma też uzasadnienie z punktu widzenia zarządzania projektem zgodnie z założeniami modelu szczegółowego a2M. Zakłada się bowiem, że każdy uczestnik projektu wypełnia odpowiedni kwestionariusz, który jest później analizowany przez kierownika projektu. Stąd też każdemu agentowi uczestniczącemu w projekcie można przydzielić zadanie związane z wypełnieniem takiego formularza. Dzięki takiemu podejściu możliwy będzie pomiar poziomów dojrzałości wartości poszczególnych zmiennych decyzyjnych.

Sprawdzenie możliwości rozbudowy RTC o instrumenty pomiaru zmiennych nowego trójkąta ograniczeń było niezbędne z punktu widzenia planowania kolejnego eksperymentu.

Wnioski

Przeprowadzony eksperyment pozwolił na ocenę możliwości implementacji poziomu zarządzania i warstwy przetwarzania oraz funkcjonalności modelu szczegółowego a2M. Wnioski z badania 3-P przedstawiono w tabeli 6.9

Przeprowadzony eksperyment dotyczył implementacji poziomu zarządzania modelu szczegółowego a2M. Wykazał, że narzędzie wspomagające zarządzanie projektami informatycznymi umożliwia implementację modelu. Warto dodać, że sprawdzono nie tylko możliwość definiowania komunikatów między agentami, ale również możliwość dobierania i uruchamiania agentów do realizacji poszczególnych zadań.

Największym problemem implementacyjnym była wizualizacja zależności hierarchicznych.

Prezentacja graficzna tych relacji w formie ogólnie dostępnej dla wszystkich uczestników (widocznej) dostarcza wielu problemów i wymaga dodawania do RTC dodatkowych elementów (wtyczek).

Ważnym osiągnięciem eksperymentu było sprawdzenie możliwości implementowania instrumentów do pomiaru zmiennych decyzyjnych wchodzących w skład nowego trójkąta ograniczeń.

Umożliwienie budowania takich instrumentów pozwala w następnym eksperymencie przeprowadzenie pełnego eksperymentu, w którym umożliwione zostaje przedłożenie uczestnikom odpowiednich formularzy badających poziom zmiennych decyzyjnych.

Zauważono również, że niezbędne jest przygotowanie procedur korzystania z modelu szczegółowego a2M poddanego implementacji w RTC dla kierowników, którzy nie znają założeń tego modelu.

6.1.6 Eksperyment 5-P. Implementacja dobrych praktyk modelu szczegółowego a2M