pobierz plik referatu

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 8
w
Organizacja przepływu informacji w dużym
projekcie informatycznym
w
1 Wstęp
da
.b
w
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 RPG1 Rektorat.
1
RPG – Rektorat Project Group
BWZ – Biuro Współpracy z Zagranicą
3
FK – Finanse-księgowość
2
pl
s.
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, BWZ2, Wydawnictwo. Dużym wyzwaniem będzie dla nas przeprowadzenie
części projektu związanego z działem FK3, łą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
Marcin Lizis
Uniwersytet Łódzki, Filia w Tomaszowie Mazowieckim, Instytut Studiów Informatycznych,
ul. Konstytucji 3-go Maja 65/67, 97-200 Tomaszów Mazowiecki, Polska
email: [email protected]
Marta Grzanek, Sebastian Wojczyk
Uniwersytet Łódzki, Wydział Matematyki, KAMiTS, ul. Banacha 22, 90-238 Łódź, Polska
email: {marta, wojczyk}@math.uni.lodz.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
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.
w
2 Obieg informacji
w
2.1 Struktura organizacyjna
da
.b
w
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.
pl
s.
100
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Organizacja przepływu informacji w dużym projekcie informatycznym
w
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.
w
2.2 Realizacja zadań
da
.b
w
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 1.3.98,
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.
pl
s.
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
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
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.
w
3 Narzędzia informatyczne
3.1 FlySpray
da
.b
w
w
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.
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ą:
−
−
−
pl
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
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Organizacja przepływu informacji w dużym projekcie informatycznym
−
w
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 Svn4
da
.b
w
w
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.
pl
s.
4
Subversion – system kontroli wersji
103
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
M. Lizis, M. Grzanek, S. Wojczyk
w
da
.b
w
w
Rys 1. Uproszczona architektura repozytorium svn.
3.3 Panel logów zmian
pl
s.
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
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Organizacja przepływu informacji w dużym projekcie informatycznym
w
w
w
Rys 2. Schemat bazy danych
da
.b
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).
pl
s.
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
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
M. Lizis, M. Grzanek, S. Wojczyk
sprawdzić kiedy pojawiła się dana funkcjonalność oraz czy zgłoszone zmiany zostały już
wprowadzone.
4 Podsumowanie
w
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.
1.
2.
3.
4.
da
.b
w
w
Literatura
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 2005.
http://flyspray.org/
http://www.postgresql.org/
http://subversion.tigris.org/
pl
s.
106
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008