Organizacja przepływu informacji w dużym projekcie informatycznym

Transkrypt

1 Rozdział 8 Organizacja przepływu informacji w dużym projekcie informatycznym Streszczenie. Obieg informacji w dużych systemach informatycznych jest jednym z ważniejszych czynników wpływających na powodzenie przedsięwzięcia. Właściwa organizacja przepływu danych jest szczególnie istotna w fazie wdrażania oraz rozwijania już istniejących systemów. W poniższym rozdziale opisane zostały mechanizmy działające od kilku lat na Uniwersytecie Łódzkim. Są one stosowane w ramach tworzonego kompleksowego systemu informatycznego RPG 1 Rektorat. 1 Wstęp W rozdziale tym zaprezentujemy rozwiązania, które są skutecznie stosowane w systemie informatycznym RPG Rektorat. Grupa RPG powstała w 2003 roku na Uniwersytecie Łódzkim. Jej zadaniem jest stworzenie kompleksowego systemu informatycznego obsługującego wszystkie działania administracyjne związane z zarządzaniem państwową szkołą wyższą. Do chwili obecnej wdrożone zostały działy: Kadry, Płace, Rachunki, ZUS, Rekrutacja (łącznie z e-rekrutacją), KIOD (rozliczanie nadgodzin nauczycieli akademickich) i wiele mniejszych. Aktualnie trwają prace nad częścią związaną z działami: Socjalny, BWZ 2, Wydawnictwo. Dużym wyzwaniem będzie dla nas przeprowadzenie części projektu związanego z działem FK 3, łącznie ze stworzeniem mechanizmów dla potrzeb rachunkowości zarządczej. W ciągu tych kilku lat naszej pracy i niezliczonej liczby zagadnień, które musieliśmy poddać wnikliwej analizie, zaprojektować i zaimplementować stworzyliśmy rozwiązania, których zadaniem jest ułatwienie pracy nam oraz osobom z nami współpracującym. Obecnie, w prace nad rozwojem oraz bieżącym utrzymaniem systemu zaangażowanych jest 28 osób. W większości są to osoby ściśle związane z informatyką. W opisywanym 1 RPG Rektorat Project Group 2 BWZ Biuro Współpracy z Zagranicą 3 FK Finanse-księgowość Marcin Lizis Uniwersytet Łódzki, Filia w Tomaszowie Mazowieckim, Instytut Studiów Informatycznych, ul. Konstytucji 3-go Maja 65/67, Tomaszów Mazowiecki, Polska marcinl@math.uni.lodz.pl Marta Grzanek, Sebastian Wojczyk Uniwersytet Łódzki, Wydział Matematyki, KAMiTS, ul. Banacha 22, Łódź, Polska {marta, wojczyk}@math.uni.lodz.pl

2 M. Lizis, M. Grzanek, S. Wojczyk projekcie, głównym źródłem informacji na temat specyfiki pracy określonego działu są osoby, które od wielu lat w tym dziale pracują. Dzięki takiej organizacji oprócz wiedzy na temat konkretnych przepisów, uzyskujemy również sugestie dotyczące ergonomii tworzonej aplikacji. Należy wspomnieć, że system RPG Rektorat ma obecnie ponad 100 czynnych użytkowników. Przy takiej ilości osób pracujących jako użytkownicy systemu i jako informatycy konieczne stało się opracowanie mechanizmów wymiany informacji między nimi i odpowiedniej reakcji na określone sygnały. 2 Obieg informacji 2.1 Struktura organizacyjna Przy wspomnianej wyżej liczbie osób związanych bezpośrednio z funkcjonowaniem systemu koniecznym okazało się zdefiniowanie hierarchii pracowników w poszczególnych działach. W każdym dziale znajduje się jedna lub kilka osób upoważnionych do przekazywania sugestii projektowych. Ilość osób wytypowanych zależy od ich kompetencji. Jeżeli mamy do czynienia z działem, nad którym merytorycznie panuje jedna osoba to jest ona jednocześnie najlepszym i w praktyce jedynym źródłem informacji na temat funkcjonowania tej jednostki. W przypadku większych jednostek konieczne jest wybranie kilku osób posiadających szczegółową wiedzę na temat różnych zagadnień, tak aby ich łączny zasób informacji ogarniał cały dział. W tym miejscu należy zauważyć, że zadaniem tych wybranych pracowników jest zgłaszanie wszelkich próśb o zmiany w aplikacji. Mogą one wynikać ze zmian przepisów, mogą być próbą optymalizacji pracy pracowników, czy wreszcie mogą być następstwem odkrycia błędów w aplikacji. Ostatni typ zgłoszenia nie musi być zgłaszany przez osoby wytypowane. Informacje o błędach mogą być przekazywane również przez osoby, które się bezpośrednio zetknęły z niewłaściwym, ich zdaniem, funkcjonowaniem systemu. Pracownikom grupy RPG również zostały przydzielone odpowiednie funkcje w zależności od znajomości systemu, umiejętności, predyspozycji. W omawianym zagadnieniu najistotniejsze są funkcje: pracownik help desk, kierownik merytoryczny, programista. Pracownik help desk jest osobą odpowiedzialną za kontakt z użytkownikiem systemu, przyjmowanie zgłoszeń o błędach aplikacji, wstępna weryfikacja zgłoszeń, przyporządkowanie problemu do odpowiedniego modułu, tabel bazodanowych, itp. oraz przekazanie informacji o zgłoszeniu do kierownika merytorycznego odpowiedzialnego za konkretny dział. Kierownik merytoryczny posiada wiedzę na temat założeń projektowych działu oraz ich realizacji. W związku z tym, przez niego przechodzą wszystkie zgłoszenia z odpowiedniej jednostki. Zarówno zgłoszenia dotyczące błędów, jak i te o zmianach. Jako osoba posiadająca całościową wiedzę, na temat określonej jednostki decyduje on jaki będzie dalszy los zgłoszenia, w jaki sposób zostanie ono obsłużone, przez kogo i w jakim czasie. Następnie nadzoruje prace nad realizacją zadania. W sytuacji, gdy kierownik merytoryczny znajduje się na urlopie lub zwolnieniu lekarskim wtedy jego obowiązki są wypełniane przez pracownika jego zespołu, który posiada największą wiedzę i doświadczenie związane z danym modułem. 100

3 Organizacja przepływu informacji w dużym projekcie informatycznym Należy tu zwrócić uwagę na dwie drogi przypływu informacji od użytkowników do kierownika merytorycznego. W przypadku zgłoszeń związanych z błędami, przechodzą one przez help desk. Wszelkie nowości i optymalizacje są bezpośrednio omawiane między wyznaczonymi użytkownikami a kierownikiem merytorycznym. W części bazodanowej na system Rektorat składa się ponad 300 tabel, nie licząc tabel z danymi historycznymi, widoków itp. Co za tym idzie każdy programista zajmuje się implementacją mechanizmów z określonego obszaru. Nie koniecznie chodzi tu o jeden dział, raczej o ideę. System Rektorat posiada centralną bazę danych, w związku z tym te same informacje są wykorzystywane w różny sposób w różnych modułach systemu, które są następnie używane przez pracowników wielu jednostek organizacyjnych. 2.2 Realizacja zadań Po przyjęciu zgłoszenia i podziale pracy dla poszczególnych programistów, kolejnym etapem jest realizacja zlecenia. Na tym etapie każda zmiana w aplikacji jest zapisywana w systemie kontroli wersji. Wszystkie te zmiany oczywiście muszą być opatrzone odpowiednim komentarzem. Realizacja zgłoszenia nie oznacza jeszcze, że zmieniona aplikacja trafi na serwery produkcyjne. System składa się z wielu połączonych ze sobą komponentów. Każdy komponent jest testowany przez programistę, który go tworzy lub zmienia wykorzystując przypadki testowe zgłoszone przez użytkowników i pracowników help desk. Następnie trafia on na serwer testowy, gdzie sprawdzane są części aplikacji wykorzystujące ten komponent przez użytkowników systemu. Przyjęliśmy następujące założenia dotyczące tworzenia i przekazywania aplikacji do użytkownika końcowego: na serwery produkcyjne trafia przetestowana aplikacja, wszelkie niewielkie uaktualnienia aplikacji oraz zmiany związane z poprawą błędów trafiają raz dziennie do wersji testowej aplikacji, do wersji testowej mają dostęp wszyscy użytkownicy systemu z takimi samymi uprawnieniami do danych jak w wersji produkcyjnej, wszelkie zmiany danych w wersji testowej służą tylko i wyłącznie do przetestowania mechanizmów, w związku z czym baza testowa jest tworzona codziennie i zawiera aktualne dane z części produkcyjnej, proces przenoszenia wersji testowej na produkcyjną odbywa się raz w tygodniu i wiąże się z uaktualnieniem bazy systemowej oraz części aplikacyjnej, każda tak stworzona wersja posiada swój unikalny numer (aktualna wersja produkcyjna ma numer , gdzie pierwszy człon odpowiada za zmiany technologiczne mające wpływ na przebudowę całego systemu, drugi człon odpowiada za istotne zmiany w silniku aplikacyjnym (RPG silnik) i trzeci człon identyfikuje cotygodniowe uaktualnienie wersji systemowej), duże zmiany w aplikacji są zapisywane w oddzielnej gałęzi systemu kontroli wersji. Spowodowane jest to dłuższym czasem realizacji całego zgłoszenia. W związku z tym aplikacja testowa zawierająca powyższe zmiany jest umieszczona pod innym, z góry ustalonym adresem intranetowym. W zależności od wielkości realizowanego zlecenia różny jest sposób informowania użytkownika końcowego o dostępności rozwiązania. Jeżeli mamy do czynienia z dużą zmianą to kierownik merytoryczny organizuje pracę dla programistów, na bieżąco informuje pracowników zainteresowanej jednostki organizacyjnej o postępach prac i koordynuje proces testowania aplikacji. Mniejsze zmiany, bezpośrednio po ich realizacji trafiają do wersji testowej, gdzie do końca tygodnia są sprawdzane i ewentualnie dalej 101

4 M. Lizis, M. Grzanek, S. Wojczyk zmieniane. Wszelkie zmiany umieszczone na wersji testowej są zaopatrzone w odpowiedni komentarz programisty, opisujący zmiany, które zostały poczynione. Następnie na podstawie komentarzy tworzone jest zestawienie zmian, które pojawiły się w odpowiedniej wersji. Polega to na moderacji komentarzy stworzonych przez programistów. Tak stworzony log zmian zostaje automatycznie umieszczony w portalu informacyjnym systemu. 3 Narzędzia informatyczne Cały opisany wyżej proces przekazywania informacji między pracownikami i twórcami systemu jest wspomagany przez odpowiednie oprogramowanie. Wybór wykorzystywanych aplikacji poprzedzony był wnikliwym testowaniem rozwiązań dostępnych na rynku. Poza opisanymi niżej systemami FlySpray i svn używaliśmy również innych narzędzi do raportowania błędów Bugzilla i kontroli wersji csv. Wybrane jednak zostały te aplikacje, które były zgodne z naszymi wymaganiami i dodatkowo były pozytywnie odbierane przez większość pracowników naszego zespołu. 3.1 FlySpray Proces realizacji wszystkich zmian w systemie RPG Rektorat rozpoczyna się od zdefiniowania konkretnej czynności, która ma zostać wykonana aby osiągnąć odpowiedni efekt. Wszystkie zadania są ewidencjonowane w systemie FlySpray. Autorzy aplikacji stworzyli ją z myślą o ułatwieniu obsługi zgłoszeń o błędach w aplikacji. W naszym projekcie jest ona również stosowana do nadzorowania działań związanych z wprowadzaniem nowości i zmian do systemu. Każde zadanie wprowadzone do aplikacji posiada szereg atrybutów, które jeżeli są odpowiednio wykorzystywane mogą znacznie ułatwić pracę. Z punktu widzenia nadzoru nad obiegiem informacji najistotniejszymi atrybutami są: tytuł zgłoszenia, treść zgłoszenia zawiera szczegółowe informacje o zadaniu, łącznie z danymi zgłaszającego użytkownika systemu, dokładnym opisem oczekiwanego działania, oraz w przypadku błędów konkretne informacje o sytuacji kiedy błąd się pojawił, czyli w kontekście którego pracownika/których pracowników była wykonana akcja i jakie wartości były wprowadzone w poszczególne pola opcji, ważność, priorytet pola pomagają zdefiniować kolejność wykonywania poszczególnych zleceń, identyfikator osoby, do której zostało przydzielone zadanie na początku każde zadanie jest przydzielone do kierownika merytorycznego, on podejmuje decyzję komu należy powierzyć realizację zgłoszenia i odpowiednio zmienia wartość tego pola, procent postępu pole szczególnie istotne dla celów informacyjnych. Osoba realizująca zadanie uaktualnia pole po każdym etapie realizacji, dzięki czemu kierownik jest w stanie poinformować osoby zainteresowane z odpowiedniego działu o przewidywanym czasie realizacji zlecenia, 102

5 Organizacja przepływu informacji w dużym projekcie informatycznym zgłoszenia powiązane przy większych zgłoszeniach, szczególnie zawierających definicje zmian i nowości pojawia się konieczność podziału zadania na kilka mniejszych, które często są zależne od siebie. Najprostszym przykładem jest zdefiniowania zadania związanego z modyfikacją bazy danych, po zakończeniu którego można przystąpić do tworzenia części aplikacyjnej obsługującej wprowadzone zmiany. Poza umieszczonymi wyżej atrybutami używamy również kilku mniej istotnych atrybutów, które nie mają tak dużego znaczenia. 3.2 Svn 4 Po odpowiednim zdefiniowaniu zgłoszenia i przydzieleniu go do konkretnego programisty zaczyna się proces implementacji. Wszystkie zmiany wykonane w bazie i aplikacji trafiają do globalnego repozytorium svn. W repozytorium przechowujemy wersję produkcyjną, wersje testowe oraz wszystkie wersje archiwalne. Zgodnie z naszą polityką bezpieczeństwa jesteśmy w stanie odtworzyć stan systemu z dowolnego dnia od początku działania systemu, nawet w przypadku całkowitego zniszczenia serwerów produkcyjnych. W takiej sytuacji musielibyśmy mieć trzy wzajemnie ze sobą powiązane części: skrypty tworzące w pełni funkcjonalną bazę danych, pliki RPG silnika oraz aplikacji systemowej, dane z interesującego nas dnia. Dane z aplikacji systemowej są archiwizowane raz dziennie i trafiają w bezpieczne miejsce. Dwie pierwsze pozycje są umieszczone w repozytorium svn, które jest podzielone na dwie główne gałęzie: produkcyjną i testową. W gałęzi produkcyjnej znajdują się wszystkie wersje od początku działania systemu. W gałęzi testowej znajduje się przynajmniej jedna wersja testowa. Jeżeli w danej chwili jest realizowane większe zgłoszenie, to ma ono swoją odrębną wersję testową. Wszystkie tak opisane wersje składają się z części bazodanowej i aplikacyjnej. Część związana z bazą danych zawiera wszystkie skrypty potrzebne do stworzenia bazy od podstaw. Zawiera ona skrypt zarządzający, który w odpowiedniej kolejności uruchamia odpowiednie części procedury inicjalizującej. Tworzone są po kolej tabele, sekwencje, klucze główne, obce, indeksy, widoki, wyzwalacze itd. Część aplikacyjna systemu opiera się na technologii www, w związku z czym nie wymaga ona przeprowadzania skomplikowanej procedury inicjującej. 4 Subversion system kontroli wersji 103

6 M. Lizis, M. Grzanek, S. Wojczyk Rys 1. Uproszczona architektura repozytorium svn. 3.3 Panel logów zmian Kolejnym etapem związanym z realizacją zadania jest poinformowanie użytkowników systemu o wprowadzeniu określonej funkcjonalności w konkretnej wersji. Informacje o wszystkich zmianach są tworzone na podstawie opisów dołączanych do plików podczas umieszczania ich w repozytorium. Przed publikacją opisów w portalu informacyjnym opisy muszą zostać zmoderowane. Dzieje się tak dlatego, że komentarze trafiające do svn mają charakter czysto techniczny. W tym celu stworzony został panel, dzięki któremu można w prosty sposób zdefiniować opisy w formie akceptowalnej przez użytkowników na podstawie technicznych komentarzy. Poza tym, należy zwrócić uwagę, że komentarze pochodzące z svn są przyporządkowane do plików, w których były poczynione zmiany. W związku z tym osoba moderująca opis musi jeszcze umieścić informację o tym, która opcja systemu została zmieniona. Do realizacji powyższego zadania stworzyliśmy bazę danych oraz aplikację www, dzięki której możliwe jest edytowanie opisów. 104

7 Organizacja przepływu informacji w dużym projekcie informatycznym Rys 2. Schemat bazy danych Powyższa baza jest uaktualniana automatycznie. Trafiają do niej opisy svn łącznie z informacjami o tym kto, kiedy i w jakim pliku wykonał zmiany (tabele: sciezka, svn, repozytorium). Do panelu administracyjnego logami mają dostęp wszyscy programiści. Korzystanie z serwisu jest możliwe po zalogowaniu się (tabela: uzytkownik). W zależności od uprawnień użytkownika ma on dostęp do określonego repozytorium svn (tabela: uzytkownik_repozytorium), np. uprawnienia do gałęzi systemowej i do rekrutacji zewnętrznej. Dane identyfikacyjne są wykorzystywane do odpowiedniej personalizacji prezentowanych treści. Najważniejszą funkcją panelu jest dostęp do narzędzia edycyjnego umożliwiającego tworzenie opisów (tabele: svn, svn_www). Programiści mają również możliwość przeglądania wszystkich swoich zmian umieszczonych w svn oraz opisów przez nich stworzonych. W prezentowanym rozwiązaniu istotna jest również funkcja administratora, który w momencie uaktualniania aplikacji systemowej definiuje również numer wersji aplikacji oraz daty początku i końca obowiązywania danej wersji (tabela: wersja). 3.4 Portal informacyjny Ostatnim etapem przepływu informacji jest portal intranetowy poświęcony tematyce systemu RPG Rektorat. Znajdują się tam podstawowe informacje o historii systemu, grupie RPG, jak również dostęp do dokumentacji systemu oraz pełen opis zmian w poszczególnych wersjach. Wszystkie zmiany tu zaprezentowane pochodzą z opisanej wyżej bazy danych. Są one podzielone na poszczególne wersje systemowe i dodatkowo do każdej wersji dodana jest data początku jej obowiązywania. Wszystkie opisy znajdujące się w określonej wersji są do niej przyporządkowane na podstawie daty dodania zmian do repozytorium svn. Natomiast opis jest widoczny w portalu dopiero po jego moderacji przez uprawnionego programistę. Najczęściej używaną funkcjonalnością portalu jest zestawienie zmian. Jest to szczególnie przydatne narzędzie dla użytkowników systemu, którzy w każdej chwili mogą 105

8 M. Lizis, M. Grzanek, S. Wojczyk sprawdzić kiedy pojawiła się dana funkcjonalność oraz czy zgłoszone zmiany zostały już wprowadzone. 4 Podsumowanie Opisany mechanizm obiegu informacji sprawdza się doskonale przy realizacji systemu RPG Rektorat. Jest on wykorzystywany w stosunkowo hermetycznym środowisku. Wprawdzie wszystkich osób związanych z systemem jest około 150, ale przy z góry zdefiniowanych obowiązkach każdej osoby nie pojawiły się problemy z funkcjonowaniem powyższych mechanizmów. W najbliższym czasie rozwiązania te będą testowane przy okazji realizacji projektu ściśle związanego z systemem RPG Rektorat. Każdy pracownik naszej uczelni będzie miał dostęp do swoich danych osobowych oraz finansowych przetwarzanych w systemie. Funkcjonalność ta będzie zrealizowana w formie portalu internetowego z dostępem do prywatnych danych po zalogowaniu. Po otwarciu dostępu do portalu każdy z ponad 4000 potencjalnych użytkowników będzie mógł zgłaszać swoje uwagi, znalezione błędy oraz pomysły na dodatkową funkcjonalność za pośrednictwem odpowiednio przygotowanej strony. Dalsza część obsługi zgłoszeń będzie realizowana z wykorzystaniem mechanizmów opisanych w tym rozdziale. Literatura 1. Lizis M., Wojczyk S.: Warstwa bazy danych w aplikacjach trójwarstwowych opartych na technologiach PHP i XML. Bazy Danych-modele, technologie, narzędzia t.2, Warszawa