Eksperyment 3-P. Implementacja poziomu definiowania modelu szczegółowego

szczegółowego a2M. Uznano za konieczne sprawdzenie w jaki sposób można dokonać transformacji elementów struktury projektowej do postaci agentów opisywanych zestawem cech i zachowań.

Eksperyment przeprowadzono w ramach funkcjonowania Uniwersyteckiego Centrum Kompetencyjnego Technologii Rational powołanego przy współpracy Zakładu Zarządzania Technologiami Informatycznymi Politechniki Gdańskiej z firmą IBM. Do implementacji przystąpiono na przełomie stycznia i lutego 2012 roku. W tabeli 6.6 przedstawiono założenia do przeprowadzania badania.

Tabela 6.6 Założenia do badania 3-P

Kod eksperymentu 3-P

Cel Celem eksperymentu jest sprawdzenie możliwości implementacji poziomu definiowania modelu szczegółowego a2M.

Ś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

Opis eksperymentu

Przygotowaną specyfikację modelu szczegółowego a2M przekazano osobie odpowiedzialnej za implementację. W przekazanej dokumentacji zawarto opis poziomu definiowania modelu.

Oczekiwano implementacji w narzędziu RTC poziomu definiowania modelu szczegółowego a2M (definiowania agentów poprzez nadanie im nazw oraz przypisanie cech i zachowań). Oczekiwano również zbudowania (w oparciu o narzędzie) interfejsu pozwalającego kierownikowi projektu dowolny dobór agentów (elementy struktury projektowej) oraz modyfikowanie ich cech i zachowań.

Ograniczeniem implementacyjnym okazało się, środowisko RTC z uwagi na własny interfejs graficzny w ramach, którego można rozbudowywać tylko podstawowe jego funkcjonalności. Efekty implementacji przedstawiono na rysunkach (6.1-6.5). Każdy z etapów implementacji został szczegółowo opisany.

Należy jednocześnie nadmienić, że realizacja tego eksperymentu odbywała się z zastosowaniem podejścia agentowego (praca w rozproszonym środowisku, reagowanie na określone komunikaty osoby zlecającej wykonanie implementacji). Przebieg eksperymentu miał także charakter iteracyjny.

W ramach iteracji implementowano kolejne warstwy modelu szczegółowego a2M.

Podstawowym procesem, który należało wykonać podczas implementacji modelu szczegółowego a2M w narzędziu RTC to przygotowanie obszaru roboczego, w którym możliwe jest zaimplementowanie modelu. Konieczne było przygotowanie dedykowanego szablonu procesu.

Szablony procesu w RTC stanowią obszary robocze, w których kierownik projektu może definiować elementy struktury projektu. Takie podejście wydaje się jak najbardziej zasadne dla modelu szczegółowego a2M. Dzięki temu kierownik korzystający z narzędzia otrzymuje możliwość wyboru modelu szczegółowego a2M jako alternatywy względem wbudowanych w RTC szablonów procesów zgodnych z metodami zarządzania projektami (np. SCRUM). Na tej podstawie przygotowano szablon dla modelu szczegółowego a2M stanowiący środowisko do późniejszego definiowania agentów.

Wynik implementacji szablonu modelu szczegółowego a2M przedstawiono na rys. 6.1

Rys. 6.1 Zdefiniowanie obszaru roboczego dla modelu szczegółowego a2M Źródło: opracowanie własne

Po implementacji szablonu uzyskano środowisko do definiowania wszystkich pozostałych elementów struktury projektowej. Postanowiono dodatkowo sprawdzić możliwość implementacji zarówno członków zespołu jak również zasobów wiedzy (modele ocenowe albo dobre praktyki).

Możliwość definiowania struktury projektowej

Po zdefiniowaniu obszaru roboczego przystąpiono do pierwszego kroku związanego z badaniem zasadności predykcyjnej modelu. Postanowiono sprawdzić możliwość implementowania struktury projektowej z wykorzystaniem narzędzia RTC. Uznano za konieczne sprawdzenie możliwości definiowania takich elementów struktury jak: członkowie zespołu, eksperci, klient, dobre praktyki zarządzania projektami informatycznymi.

Okazało się, że środowisko implementacji modelu szczegółowego a2M jakim jest RTC posiada wbudowane funkcjonalności umożliwiające definiowanie ról projektowych. Uznano zatem, że zgodnie z założeniami dla najniższej warstwy modelu szczegółowego a2M konieczne jest umożliwienie kierownikowi projektu definiowanie poszczególnych elementów struktury projektowej w taki sposób, w jaki definiuje się role w metodach zarządzania projektami informatycznymi.

Implementacja tej funkcjonalności wykazała, że zdefiniowanie składników (elementów) struktury projektowej dokonuje się w RTC na zasadzie wyboru ról projektowych. Kierownik projektu, który dokonuje wyboru roli może nadawać nazwy zgodne ze swoimi założeniami oraz może określać liczebność poszczególnych elementów struktury projektowej. Na rysunku 6.2 przedstawiono możliwości definiowania elementów struktury projektu wg założeń modelu szczegółowego a2M.

Rys. 6.2 Definiowanie elementów struktury projektu wg założeń modelu szczegółowego a2M Źródło: opracowanie własne

Poddano także analizie możliwości implementacji modelu szczegółowego a2M poza strukturą szablonów. Efekt takiej implementacji postanowiono zaprezentować w kolejnym etapie eksperymentu, gdy sprawdzona zostanie możliwość stosowania podejścia agentowego podczas implementacji modelu w RTC. Jednocześnie podczas implementacji struktury projektu zauważono problem z możliwościami definiowania dobrych praktyk. Definiowanie dobrych praktyk nie może być realizowane w RTC na tej samej zasadzie w jaki definiuje się role projektowe.

Możliwość implementacji dobrych praktyk

Okazało się, że tworząc własny szablon do zarządzania projektami informatycznymi, narzędzie RTC nie posiada predefiniowanych dobrych praktyk zarządzania projektami. Istnieją co prawda szablony procesów dla projektów realizowanych według konkretnej metody zarządzania projektami (np. szablon do SCRUM albo RUP). Jednak w tych szablonach dobre praktyki dostępne są pośrednio, tzn. wynikają z działań prowadzonych w ramach wybranego szablonu. Np. wybierając szablon SCRUM kierownik projektu może planować sprint, może definiować rejestr produktu lub rejestr sprintu (nazwane w RTC dziennikami). Uznano jednak, że skoro dobre praktyki implementuje się na końcu (wprowadzane na poziomie adaptacji) kierownicy projektów powinni jedynie mieć świadomość konieczności stosowania dobrych praktyk i ich znaczenia dla powodzenia projektu.

Przyjęto definiowanie dobrych praktyk jako określonych jednostek pracy (ang. work items) traktując te dobre praktyki jako źródło wiedzy dla kierownika projektu. Takie podejście wynikało z konieczności zapewnienia przejrzystości interfejsu w szablonie modelu szczegółowego a2M.

Zaimplementowanie dobrych praktyk w obszarze ról, powodowałoby ich nieczytelność z punktu widzenia użytkownika. Zaimplementowanie ich w narzędziu jako jednostki pracy nie zmieniło agentowego charakteru dobrych praktyk. Przypisanie ich do konkretnego agenta w narzędziu RTC pozwala danemu agentowi zapoznać się z nimi w celu poszerzenia wiedzy. Na rysunku 6.3 przedstawiono sposób implementacji dobrych praktyk w modelu szczegółowego a2M.

Rys. 6.3 Implementacja dobrych praktyk w modelu szczegółowego a2M Źródło: opracowanie własne

Jak wynika z rysunku 6.3, w szablonie procesu dedykowanym dla modelu szczegółowego a2M, przyporządkowano kierownikowi projektu przykładowe dobre praktyki. Kierownik projektu powinien zapoznać się z nimi a następnie podejmować decyzje odnośnie wybrania tylko tych, które są niezbędne dla realizacji danego projektu.

Możliwość uwzględnienia eksperta (sposób komunikacji z ekspertem)

Realizując niniejszy eksperyment brano pod uwagę również możliwości uwzględniania ekspertów. Niewątpliwie ekspert jest jednym z podstawowych elementów struktury projektowej, ale na podstawie eksperymentów przeprowadzonych podczas badania zasadności replikatywnej, zaobserwowano duże zróżnicowanie dziedzin w ramach, których kierownicy poszukują ekspertów.

Wcześniejsze analizy wyraźnie pokazały, że zapotrzebowanie na eksperta może dotyczyć obszarów niekonieczne związanych z zarządzaniem projektami informatycznymi. Może istnieć zapotrzebowanie na ekspertów z innych dziedzin jak prawo, administracja, albo zupełnie odległej dziedziny (np.

medycyna, gdy projekt realizowany jest dla branży medycznej). Pojawiło się więc pytanie w jaki sposób kierownik może określić tematy, w których ekspert może wspomagać jego projekt.

Drugim pytaniem, które pojawiło się podczas eksperymentu 3-P było to jak włączać eksperta do projektu, skoro zapotrzebowanie na eksperta może wystąpić w dowolnym momencie trwania projektu.

Kierownik projektu nie może bowiem przewidzieć zapotrzebowania na wszystkich ekspertów na początku trwania projektu. Pierwszy z problemów związanych z definiowaniem eksperta w projekcie informatycznym udało się rozwiązać w narzędziu RTC korzystając z dodatkowych pół uszczegóławiających każdy z definiowanych elementów struktury projektowej. Na rysunku 6.4 przedstawiono sposób definiowania atrybutów elementu struktury projektowej (eksperta).

Rys. 6.4 Definiowanie atrybutów elementu struktury projektowej (eksperta) Źródło: opracowanie własne

Następnie postanowiono rozwiązać kolejny problem, związany z korzystaniem z narzędzia RTC jako środowiska wspierającego zarządzanie projektem wg modelu szczegółowego a2M. Należało bowiem wykluczyć konieczność instalacji środowiska RTC u eksperta (który może przebywać w dowolnym miejscu na świecie) oraz wykluczyć konieczność szkolenia eksperta z obsługi RTC.

Uznano więc, że uczestnictwo eksperta w projekcie informatycznym zarządzanym wg modelu szczegółowego a2M a wspieranym przez środowisko RTC należy wspomagać z poziomu cienkiego klienta (opcji dostępnej w RTC za pośrednictwem serwera JTS- Jazz Team Serwer). Rozwiązanie takie umożliwia korzystanie z określonych funkcjonalności RTC z poziomu przeglądarki internetowej.

Możliwość definiowania agentów (zastosowania podejścia agentowego)

Kolejnym etapem eksperymentu było badanie możliwości implementacji elementów struktury projektu w oparciu o agenty (podejście agentowe) w RTC. Implementacja podejścia agentowego jest kluczowa z punktu widzenia dalszych działań. Zgodnie bowiem z przyjętym podejściem agentowym, każdy uczestnik projektu oraz każda dobra praktyka powinna być definiowana jako niezależny agent, który w efekcie działań i decyzji kierownika projektu wkomponowany jest w strukturę projektu.

Dlatego też na początku sprawdzono na ile definiowanie poszczególnych elementów struktury projektowej pozwala na zachowanie odrębności, autonomii i niezależności działania poszczególnych agentów. Obecnie przystąpiono do sprawdzenia czy definiując poszczególne elementy struktury projektowej (jak członkowie zespołu, ekspert czy też dobre praktyki) możliwe jest ich definiowanie z punktu widzenia typowych atrybutów agenta przyjętych w modelu szczegółowym a2M. Atrybuty agenta określane w modelu szczegółowego a2M dotyczą dwóch aspektów – cech oraz zachowań. Na rysunku 6.5 przestawiono metodę definiowania agentów w RTC (cechy i zachowania).

Rys. 6.5 Definiowanie agentów w RTC (cechy i zachowania) Źródło: opracowanie własne

Każdemu agentowi można przypisać takie cechy, które określają jego kompetencje oraz parametry komunikacyjne (adres e-mail, telefon). Podczas implementacji natrafiono jednak na problemy ze zdefiniowaniem zachowań. Podczas korzystania z RTC stwierdzono, że zachowań nie można zdefiniować w tym samym widoku, w którym definiuje się cechy. Przyjęto więc, że zachowania agenta (stanowiące zgodnie z definicją agentów, stany jakie może przyjmować agent w określonych momentach projektu informatycznego) należy definiować w formie możliwych do wykonania jednostek pracy. Takie podejście wydaje się zgodne z założeniami podejścia agentowego.

Po pierwsze pozwala przypisać niezależne zachowania każdemu agentowi, po drugie pozwala parametryzować te zachowania (kiedy dany agent będzie uruchomiony). Dodatkowo narzędzie RTC pozwala przypisać określonym jednostkom pracy, a tym samym zachowaniom agentów, określony status (np. w trakcie, zakończono) co uznano za dodatkową możliwość implementacji.

Wnioski

Przeprowadzony eksperyment pozwolił na ocenę możliwości implementacji poziomów i warstw modelu szczegółowego a2M. Wnioski z badania 3-P przedstawiono w tabeli 6.7

Tabela 6.7 Wnioski z badania 3-P

Kod eksperymentu: 3-P

Realizacja celu badania

Cel badania osiągnięty

Zidentyfikowane poziomy modelu szczegółowego a2M

Definiowania Istnieją procesy

adaptacji

struktur agentowych Zidentyfikowane

warstwy modelu szczegółowego a2M

wiedzy przetwarzania funkcjonalności

Istnieją procesy adaptacji

struktur agentowych Źródło: opracowanie własne

Przeprowadzony eksperyment pozwolił na wykazanie na ile opracowana koncepcja modelu szczegółowego a2M daje się zastosować w określonym środowisku do zarządzania projektami informatycznymi. Podczas eksperymentu wykazano, że korzystając z tego narzędzia, możliwe jest zaimplementowanie zarówno podstawowych elementów struktury projektowej jak klient czy zespół.

Wykazano również, że możliwe jest przekształcenie podstawowych elementów do postaci agentów, zgodnie z obecnym w modelu podejściem agentowym. Zauważono ponadto, że możliwe jest implementowanie podstawowych parametrów (atrybutów) poszczególnych agentów, czyli ich cech i zachowań.

Dodatkowym spostrzeżeniem było to, że podczas definiowania zachowań zaobserwowano również możliwość określania statusu zachowań poszczególnych agentów (w trakcie realizacji, zakończono itp.), co miało być jednym z elementów kolejnego eksperymentu, gdzie planowano zbadanie możliwości kontrolowania przepływu zleceń między agentami. Ponadto przeprowadzony eksperyment pozwolił na stwierdzenie, że specyfikacja modelu szczegółowego a2M opracowana w niniejszej rozprawie jest wystarczająco czytelna do tego, aby zaimplementować model w przykładowym narzędziu wspomagającym zarządzanie projektami informatycznymi.

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