Internetowy system doboru członków do zespołów ROZDZIAŁ 11 INTERNETOWY system Doboru Członków zespołu 11.1. Tworzenie i budowa webowych systemów RIA Jednym z rezultatów prac badawczych prezentowanych w niniejszej książce było oprogramowanie wspomagające proces doboru składu zespołu projektowego nazwane TeamCreator. Kluczową kwestią podczas projektowania software u był wybór formy jego działania oraz dobranie odpowiedniej do tego technologii. Ze względu na charakter oprogramowania, które musiało być udostępnione w Internecie, analiza technologiczna została ograniczona do technologii umożliwiających budowę serwisów internetowych, pomijając aplikacje desktopowe. Najprostszym i historycznie pierwszym rozwiązaniem budowy internetowych systemów klient-serwer jest zastosowanie cienkiego klienta, który odpowiada jedynie za prezentacje danych, a wszystkie operacje są wykonywane przez serwer. Jednakże obecnie tworzenie warstwy klienta w oparciu czysty HTML dopuszczalne jest jedynie dla małych serwisów, kosztem ich niskiej ergonomii. Dlatego też zdecydowano o budowie systemu TeamCreator w formie bogatej aplikacji internetowej RIA (ang. Rich Internet Applications). Oprócz większego komfortu pracy, gdyż obsługa aplikacji nie wymaga nieustannej komunikacji z serwerem i przeładowywania stron, graficzny interfejs użytkownika GUI (ang. Graphical User Interface) dostępny w RIA przypomina bardziej aplikacje desktopowe, niż ubogie formularze internetowe. Obserwowalny rozwój technologii RIA nie oznacza jedynie zwiększania się ich przewagi nad klasycznymi serwisami internetowymi z cienkim klientem, ale przejawia się także w formie oprogramowania udostępnionego w postaci RIA zamiast w formie aplikacji desktopowych. Wynika to z podstawowych zalet RIA, którymi są: prostota instalacji lub często całkowity brak kroków instalacyjnych; bezpieczeństwo dla użytkowników, ze względu na centralizacje serwis jest mniej podatny na zagrożenia; dostępność dla użytkowników na dowolnej maszynie, przy braku konieczności instalowania oprogramowania jak i przechowywaniu danych na serwerze serwisu użytkownicy mogą korzystać z niego na różnych komputerach; niezależność od platformy sprzętowej czy systemu operacyjnego, jedyne wymogi mogą dotyczyć dostępności określonych pluginów pozwalających na transformację uniwersalnego kodu na kod natywny maszyny; możliwości centralnej aktualizacji, wprowadzone zmiany są od razu dostępne dla użytkowników serwisu. Jednakże wybór takiej formy oprogramowania wymaga zrozumienia pewnych ograniczeń RIA przed podjęciem decyzji o tworzeniu oprogramowania, są nimi: Pietruszkiewicz W. 2009, Internetowy system doboru członków zespołu [w:] Olejniczak 141 W. (red.), Zespół Kultura Projekt, Wydawnictwo ZPSB, Szczecin, s.141-150.
Wiesław Pietruszkiewicz wymaganie dodatkowego oprogramowania (pluginów); mniejsza szybkość kodu, który jest dopiero interpretowany i zamieniany na kod natywny na maszynie klienta; ograniczenia bezpieczeństwa, całkowicie zabezpieczające dostęp do krytycznych zasobów komputera lub wymagające konfiguracji dostępu co wpływa na możliwości aplikacji; uzależnienie niezawodności i szybkości działania od jakości i przepustowości łączy. Istnieje kilkanaście technologii tworzenia GUI dla aplikacji RIA, najpopularniejsze z nich zostały zebrane i scharakteryzowane w tabeli 11.1. 11.2. Technologia OpenLaszlo Po analizie technologicznej dostępnych możliwości, do budowy systemu TeamCreator została wybrana technologia OpenLaszlo rozwijana przez Laszlo Systems. Pierwotnie nazwana Laszlo Presentation Server, technologia ta została wypuszczona w 2004 r. jako rozwiązanie Open Source wraz ze zmienioną nazwą OpenLaszlo. Wybór tej technologii spośród innych (tabela 11.1) podyktowany został następującymi względami: otwartość rozwiązania, możliwość uruchomienia RIA na różnych platformach i systemach, wsparcie dla prototypowania szkieletu aplikacji, atrakcyjna forma wizualna, duże możliwości, praktycznie brak konieczności instalowania dodatkowego oprogramowania na komputerze klienta (wymagany jest Flash lub JavaScript). Uproszczony schemat architektury OpenLaszlo został zaprezentowany na rysunku 11.1. Rysunek 11.1. Architektura aplikacji RIA wykonanych w technologii OpenLaszlo 142 źródło: opracowanie własne
Internetowy system doboru członków do zespołów Technologia Opis AJAX Flex OpenLaszlo JavaFX * Flash Silverlight Java HTML ** Tabela 11.1. Dostępne technologie tworzenia GUI dla RIA Technologia będąca połączeniem dostępnych wcześniej rozwiązań technologicznych, między innymi XHTML i CSS w warstwie prezentacyjnej, XML i XSLT w wymianie danych oraz JavaScript jako języka programowania. Wady: duża liczba niekompatybilnych bibliotek, niska szybkość tworzenia, zależy od obsługi JavaScript. Zalety: nie wymaga dodatkowych pluginów. Kod Flex składa się z języka MXML (opisuje GUI) oraz ActionScript, które transformowane są do postaci skryptów Flash. Wady: rozwiązanie zamknięte, jedyne narzędzie RAD oferowane przez samego producenta technologii. Zalety: bazuje na Flash u dostępnym na większości komputerów. Kod LZX, będący połączeniem XML i ECMAScript, jest konwertowany przez serwlet do postaci Flash lub AJAX. Wady: brak zaawansowanych narzędzi RAD, technologia rozwijana. Zalety: rozwiązanie otwarte, szybkość prototypowania, możliwość tworzenia aplikacji docelowo opartych na Flash jak i AJAX, bazuje na Flash lub JavaScript dostępnych na większości komputerów. Język skryptowy pozwalający na zastosowanie komponentów Swing w aplikacjach RIA. Wady: nowa i mało popularna technologia. Zalety: dostępność darmowych narzędzi RAD, bazuje na przetestowanej technologii Java. Technologia pierwotnie stworzona do animacji, obecnie posiada możliwość tworzenia GUI. Wady: rozwiązanie zamknięte, wolny proces tworzenia GUI, technologia ukierunkowana na wsparcie grafiki nie programowania. Zalety: dojrzałość, popularność. Pozwala na uruchomienie w przeglądarce dowolnego kodu wspieranego przez.net. Wady: rozwiązanie zamknięte, wymaga specjalnego pluginu, ograniczona dostępność na różnych platformach. Zalety: możliwość wykorzystania narzędzi i języków wspieranych przez.net. Pierwszy w pełni przenaszalny język programowania, w przypadku RIA stosowane są aplety, będące aplikacjami Java osadzonymi w przeglądarce o ograniczonych możliwościach (względy bezpieczeństwa). Wady: wymaga wirtualnej maszyny Java (Java Virtual Machine), utrudnione prototypowanie. Zalety: dobrze udokumentowane rozwiązanie, duże możliwości, popularność. Kod HTML wykorzystywany jedynie do stworzenia podstawowych elementów GUI. Przetwarzanie wymaga ciągłego przeładowywania stron. Wady: niska szybkość tworzenia aplikacji, powolność działania, duży przesył danych, obciążenie serwera, niska ergonomia użytkowania. Zalety: brak wymogów dotyczących zainstalowania dodatkowych pluginów, niskie obciążenie maszyny klienta. Twórca - (Adobe, 2009a) (Laszlo Systems, 2009) (Sun Microsystems, 2009a) (Adobe, 2009b) (Microsoft, 2009) (Sun Microsystems, 2009b) * Technologia JavaFX pierwotnie nie była brana pod uwagę jako technologia tworzenia systemu TeamCreator, gdyż jej publiczna wersja 1.0 została wprowadzona przez firmę Sun w grudniu 2008, tj. w końcowych etapach tworzenia systemu TeamCreator. W niniejszym zestawieniu została jednak umieszczona ze względu na jej potencjał. ** Sam HTML nie jest technologią tworzenia RIA, tylko punktem odniesienia jako pierwotne rozwiązanie budowy serwisów internetowych, gdzie warstwa klienta służy jedynie do przekazywania danych przetwarzanych całkowicie przez serwer. źródło: opracowanie własne - 143
Wiesław Pietruszkiewicz Technologia przewiduje dwie możliwości udostępniania aplikacji RIA: J2EE deployment i SOLO deployment. Pierwszy w wariantów wymaga kontenera aplikacji webowych na serwerze produkcyjnym, gdzie zapytania odnoszące się do aplikacji OpenLaszlo są przetwarzane na bieżąco przez serwer J2EE. W tym przypadku możliwe jest korzystanie w pełni z usług udostępnianych przez serwer J2EE między innymi obsługi SOAP. W drugim wariancie SOLO deployment aplikacja OpenLaszlo może zostać skompilowana przez developera do postaci SWF lub AJAX i umieszczona na serwerze HTTP. Ten wariant jest prostszy do zastosowania na większości serwerów WWW, przy czym przy braku konieczności zastosowania specjalnych możliwości kontenerów aplikacji, funkcjonalność aplikacji dla docelowego użytkownika jest nie do odróżnienia w obydwu wariantach. Od strony programistycznej tworzenie aplikacji OpenLaszlo opiera się na wykorzystaniu języka LZX, będącego połączeniem XML (w części odnoszącej się do GUI) przypominającego języki XUL/XAML oraz ECMAScript (JavaScript lub ActionScript) do tworzenia kodu programu. Dzięki temu język LZX pozwala na szybkie tworzenie szkieletu aplikacji. Mankamentem tej technologii jest brak rozwiniętych narzędzi RAD wspomagających rozwój aplikacji po utworzeniu szkieletu. Jednakże atrakcyjna forma wizualna, łatwość uruchomienia przez docelowego użytkownika (niezbędne oprogramowanie jest dostępne na większości komputerów podłączonych do internetu) powoduje wzrost popularności tej technologii, która przy wsparciu społeczności developerów zyskuje na możliwościach. Przykładowy kod programu, wyświetlający element ComboBox został zamieszczony poniżej (fragment pochodzi z przykładów udostępnionych przez Laszlo Systems):... <view name= stylechooser layout= axis:x; spacing:4 > <text>style:</text> <combobox width= 120 editable= false > <method event= onselect > var colorchoice = this.gettext(); c a n v a s [ c o l o r c h o i c e + c o l o r s ]. setattribute( isdefault, true); </method> <textlistitem text= silver /> <textlistitem text= green /> <textlistitem text= blue selected= true /> <textlistitem text= gold /> <textlistitem text= white /> <textlistitem text= purple /> </combobox> </view>... Po kompilacji do postaci AJAX wygląd przykładowych komponentów budowy GUI został zamieszczony na rysunku 11.2: 144
Internetowy system doboru członków do zespołów Rysunek 11.2. Wygląd komponentów GUI w technologii OpenLaszlo (wariant AJAX) źródło: (OpenLaszlo, 2009) Przy czym w wariancie kompilacji LZX do postaci Flash (historycznie będącej pierwszym formatem dostępnym w OpenLaszlo) wygląd komponentów jest identyczny. 11.3. Architektura systemu TeamCreator Patrząc od strony technicznej na system TeamCreator, jego działanie wymaga udostępnienia dwóch serwerów serwera HTTP (obecnie Apache) oraz serwera bazodanowego (obecnie MySQL). Przy czym możliwe jest zastosowanie innych wersji serwerów, takich jak IIS dla HTTP, czy PostgresSQL dla baz danych. Struktura wdrożeniowa systemu znajduje się na rysunku 11.3. Dla klienta bezpośrednio dostępne są trzy pliki: index.php zawierający osadzony klip Flash team.swf, będący częścią GUI systemu TeamCreator oraz plik interface.php służący jako interfejs komunikacyjny z serwerową częścią systemu. Rdzeń serwerowej części systemu znajduje się w pliku system.php, natomiast komunikacja z serwerem baz danych odbywa się poprzez interfejs DB Pear. Struktura składnicy danych opiera się na tabelach o strukturze i połączeniach logicznych, które zostały przedstawione na rysunku 11.4. System TeamCreator został rozdzielony na osiem modułów (rysunek 11.5), które zajmowały się obsługą spójnych logicznie zadań i funkcji systemu, takich jak testy czy kompetencje. Z punktu widzenia klienta rozdział na moduły nie jest widoczny, nie zwiększa także ilości plików jakie muszą zostać pobrane, aby TeamCreator mógł funkcjonować. Natomiast podział na moduły był istotny z punktu widzenia rozwoju aplikacji, dając szansę na rozbicie jej na mniejsze jednostki, co usprawniło proces tworzenia, testowania oraz wprowadziło lepszą organizację kodu. 145
Wiesław Pietruszkiewicz Rysunek 11.3. Diagram wdrożeniowy systemu TeamCreator <<serwer HTTP>> <<klient>> team.swf Przegladarka WWW TCP/IP index.php definitions.php interface.php system.php <<serwer MySQL>> Ethernet DB Baza www_team źródło: opracowanie własne Rysunek 11.4. Diagram klas dla systemu TeamCreator udzialy +udzial_id +zespol_id +rola dotyczy zespoly +zespol_id +organizacja +nazwa +klucz +rodzaj +liczebnosc +selekcja +liczebnosc_min +liczebnosc_max +kandydaci +kierownik_id posiada wyniki +zespol_id +data +typ +wynik dotyczą dotyczy uzytkownicy +identyfikator +imie +nazwisko +pesel +ulica +kod +miasto +panstwo +telefon +email +obywatelstwo +data_urodzenia +plec +mbtiw +mbtif +olimpm +olimpz +mb +amb +status +aktywnosc dotyczy oceny +ocena_id +zespol_id +oceniajacy_id +oceniany_id +typ +data +ocena przydpisane do hasla +haslo należące zdefiniowane przez wykonane przez posiadane przez wymogi +nazwa +klucz +liczba +edukacja +szkolenia +publikacje +zatrudnienie +granty +kompetencje +nagrody +uwagi określane przez testy +test_id +typ +rezultat +odpowiedzi +data określane przez mozliwosci +edukacja +szkolenia +publikacje +zatrudnienie +granty +kompetencje +nagrody +uwagi kompetencje +kompetencja_id +grupa_id +nazwa +opis +status grupy +grupa_id +nazwa +rodzaj +status źródło: opracowanie własne 146
Internetowy system doboru członków do zespołów Przypadki użycia zgrupowane w modułach odpowiadają podstawowej funkcjonalności systemu, która obejmowała: wykonywanie przez użytkowników testów takich jak test profilu osobowości, roli w zespole, ambicji czy kultury organizacyjnej; zbieranie informacji o kompetencjach posiadanych przez użytkowników; zbieranie informacji o wymogach projektów; dokonywanie oceny kontrolnej zespołów; dobór członków zespołu na podstawie analizy wymogów projektu badawczego; zarządzanie systemem przez administratora; generacja raportów. Rysunek 11.5. Diagram komponentów dla systemu TeamCreator Aplikacja klienta modul 'skills' modul 'users' modul 'teams' modul 'projects' modul 'help' modul 'tests' modul 'menu' modul 'datasets' źródło: opracowanie własne Wybór modelu cyklu życia został przeprowadzony tak, aby wybrane rozwiązanie w jak najlepszym stopniu spełniało kluczowe wymagania: wysokiej elastyczności, niskich kosztów wprowadzania zmian w oprogramowaniu, ograniczenia nadmiernego planowania w przypadku funkcji wymagających wcześniejszego przebadania, częstej weryfikacji funkcjonalności oprogramowania. Stąd, ze względu na naukowy charakter oprogramowania, gdzie rdzeń systemu mający za zadanie dobór członków zespołów badawczych stanowił przedmiot zaawansowanych badań naukowych, do wytworzenia systemu został wybrany model cyklu życia systemu z prototypowaniem. 147
Wiesław Pietruszkiewicz 11.4. Funkcjonowanie systemu TeamCreator Prezentowany system TeamCreator zawiera implementację modelu prezentowanego w rozdziale 10 oraz rozszerzającej funkcjonalności dodatkowej, której zadaniem jest zbieranie informacji niezbędnych do działania modelu oraz późniejsza prezentacja wyników pracy systemu. Dostęp do systemu TeamCreator możliwy jest poprzez dowolną przeglądarkę internetową wyposażoną w plugin Flash. Użycie systemu TeamCreator nie jest zależne od platformy sprzętowej, systemu operacyjnego jak i użytej przeglądarki internetowej (testy obejmowały przeglądarki FireFox, Internet Explorer, Opera i Safari). Wygląd systemu działającego w przeglądarce FireFox 3 znajduje się na rysunku 11.6. Zastosowanie komponentów odpowiadających komponentom stosowanym w aplikacjach desktopowych pozwoliło na stworzenie systemu internetowego, w którym wygoda pracy nie ustępuje pracy z tradycyjnymi aplikacjami. Przykładowy stan systemu w trakcie wypełniania kilku z dostępnych testów w systemie TeamCreator znajduje się na rysunku 11.7. Rysunek 11.6. Wygląd systemu TeamCreator źródło: (TeamCreator, 2009) 148
Internetowy system doboru członków do zespołów Rysunek 11.7. Wygląd przykładowych testów dostępnych w systemie TeamCreator źródło: (TeamCreator, 2009) Ze względu na wielodostęp do systemu niezbędne stało się wprowadzenie kont użytkowników oraz funkcji administratora wraz z udostępnionymi funkcjami do zarządzania systemem (rysunek 11.8.). Rysunek 11.8. Administracja systemem TeamCreator źródło: (TeamCreator, 2009) 149
Wiesław Pietruszkiewicz W czasie tworzenia systemu TeamCreator zostały zaobserwowane pewne mankamenty zastosowanej technologii przykładowo pojawiające się błędy języka LZX (które są likwidowane wraz z wypuszczaniem kolejnych wersji technologii) czy spadek wydajności aplikacji wraz ze wzrostem jej złożoności (wspólna cecha aplikacji RIA, jako języków interpretowalnych). Mimo tych uwag funkcjonalność, atrakcyjność wizualna oraz ukierunkowanie na łatwość pracy dewelopera zadecydowały finalnie o zachowaniu pierwotnie pozytywnej oceny technologii OpenLaszlo. Nie bez znaczenia jest także otwarty charakter technologii, która dzięki wsparciu licznej grupy developerów zyskuje na możliwościach, a proces likwidacji zaobserwowanych błędów jest szybszy niż w przypadku rozwiązań zamkniętych. 11.5. Użyteczność systemu TeamCreator Prezentowany system TeamCreator, zawierający implementację prezentowanej w rozdziale 10 metody komponowania zespołów w projektach badawczych, pozwala użytkownikom na efektywne dobranie składu nowo tworzonych zespołów projektowych oraz na kontrolę zespołów istniejących. Z punktu widzenia samych użytkowników, nie koniecznie będących kierownikami projektów, zaimplementowane w systemie mechanizmy umożliwiają określenie wielu czynników istotnych z punktu widzenia ich funkcjonowania jako członków zespołów, takich jak: profil osobowości, preferowana kultura organizacyjna, rola w zespole czy ambicja. Dzięki temu zarówno zarządzanie zespołem przez kierownika, jak i funkcjonowanie w nim jego członków staje się łatwiejsze, gdyż dysponują oni informacjami pozwalającymi im lepiej zrozumieć współdziałanie całego zespołu. 150