1. Ireneusz A. TARNOWSKI
Streszczenie
Praca przedstawia model zarządzania projektem programistycznym
opartym o rozproszony zespół programistów/osób uczestniczących w pro-
jekcie. Zaproponowany model został zaimplementowany tworząc uniwer-
salną platformę pracy dla wszystkich jednostek zaangażowanych w pro-
jekt (klient, kierownik projektu, programiści, testerzy). Szczególny nacisk
został położony na aspekty bezpieczeństwa modelu, jak również aplikacji.
Bezpieczeństwo zostało przeanalizowane i wdrożone w dwóch znacze-
niach: tajności danych oraz niezawodności aplikacji. Platforma znalazła
zastosowanie w firmach outsourcing’owych, które korzystając z sieci
komputerowej jako kanału komunikacyjnego, jednocześnie pracują nad
wieloma projektami, we współpracy z rozproszonymi grupami pracowni-
ków.
1. Wprowadzenie
Tempo zmian technologicznych oraz właściwe zarządzanie kosztami w firmach spo-
wodowały zwiększone zapotrzebowanie na outsourcing komputerowy. Outsourcing
komputerowy jest realizacją wyspecjalizowanych zadań informatycznych przez ze-
wnętrzne podmioty. Zlecanie poszczególnych zadań zewnętrznym jednostkom gwa-
rantuje: odpowiedni poziom usług informatycznych (firmy outsourcing’owe specjali-
zują się we właściwych sobie dziedzinach, szkolą oraz rozwijają wraz z rozwojem
technologii), ograniczenie działu IT wewnątrz firmy, a przez to zmniejszenie kosztów
oraz jasne sprecyzowanie zadań, terminów i odpowiedzialności za zadania IT w fir-
mie. Firma outsourcingowa musi być przygotowana na wielość problemów w trakcie
realizacji projektu oraz na zmiany uwarunkowań ich realizacji. Dynamika współcze-
snych projektów programistycznych wymusza zmianę tradycyjnego podejścia do za-
gadnienia zarządzania projektem programistycznym. Zaproponowany model oraz
aplikacja, stanowiące rozwiązanie problemu, realizuje wszystkie zadania stawiane
zarządzaniu wieloma projektami programistycznymi, w sytuacji zwiększonego ryzyka
zmian.
2. Rozproszony projekt programistyczny
W tradycyjnym podejściu do realizacji projektu programistycznego korzysta się ze
sprawdzonych modeli, tj.: kaskadowego czy spiralnego. Oba modele zakładają znajo-
mość założeń projektowych, harmonogramu realizacji projektu, niezbędnych zasobów
[1]. Współcześnie małe i średnie projekty realizowane są w sposób bardzo szybki.
Wymusza to oszczędności czasowe. Dla projektów o niezbyt ściśle określonych zało-
żeniach projektowych, lub też o dużym ryzyku zmian założeń, najlepszym okazuje się
model określany jako programowanie ekstremalne (ang. Extreme Programming, XP)

2. 2 I.A. Tarnowski
[2, 3, 4]. Dla tego modelu szybki i dokładny przepływ informacji ma kluczowe zna-
czenie dla powodzenia całego przedsięwzięcia. Zaprezentowany poniżej model oraz
aplikacja, stanowiąca implementację modelu, ma za zadanie wspomóc wymianę in-
formacji w projekcie programistycznym, w szczególności w projektach XP.
2.1. Rozproszenie projektu
Szybkość łączy oraz powszechna dostępność sieci komputerowej sprawia, że coraz
więcej projektów jest realizowanych przez rozproszone grupy. Powstaje coraz więcej
firm komputerowych, których znajdują klientów, natomiast prowadzenie projektu
zlecają osobom, często oddalonym o kilka tysięcy kilometrów.
Rys. 2. Rozproszony projekt programistyczny
Osoby prowadzące projekt korzystają z usług grup programistów, również rozproszo-
nych. W ten sposób wszystkie jednostki, które uczestniczą w projekcie są ze sobą
powiązane jedynie siecią komputerową. Schemat projektu rozproszonego, w którym
każda jednostka pracująca przy projekcie znajduje się w innym miejscu, przedstawia
rys. 1. Dla powodzenia tak realizowanego projektu zasadnicze znaczenie ma komuni-
kacja między jednostkami.
2.2. Model
Realizację takiego projektu można przestawić za pomocą modelu opartego o przepływ
informacji. Takie rozwiązanie sprzyja zastosowaniu elementów programowania eks-
tremalnego [1]. Podstawowym elementem modelu jest jednostka projektowa oraz
zadania w obrębie projektu. Zadanie jako jednostka jest przydzielana do osoby
uczestniczącej w projekcie. Osoba (jako kolejny element modelu) ma przydzieloną
funkcję (rolę), której to roli odpowiada poziom uprawnień związanych z istnieniem
w modelu (realizacja zadań, możliwości komunikacja z odpowiednimi osobami). Ce-
chą modelu jest odseparowanie funkcjonalne jednostek modelu (projekty, zadania,
osoby). Jednostki modelu są ze sobą powiązane poprzez informacje przepływające

3. Bezpieczne zarządzanie rozproszonym projektem programistycznym... 3
między nimi. Przepływ informacji jest realizowany poprzez funkcje danych jednostek
– funkcje tworzą stałe powiązania jednostek modelu (przepływ informacji został opi-
sany w rozdziale 3 oraz przedstawiony na rys. 2). Daje to dużą elastyczność stosowa-
nia modelu w realizacji projektu, gdzie łatwo można zrezygnować z funkcji, bądź
dodać nową funkcję. Odseparowanie elementów modelu i powiązanie ich jedynie
przepływem informacji umożliwia zastosowanie go w omawianym przypadku pro-
gramowania rozproszonego. Opisany w skrócie model może zostać sformalizowany
oraz łatwo przeniesiony do opisu w postaci notacji UML. W ten sposób z modelu
formalnego może powstać platforma zadaniowa (rozdział 3).
2.3. Standardy pracy
Dla poprawnej pracy rozproszonego zespołu programistów celowe staje się określenie
standardów pracy w zespole. Standardy obejmują:
• standardy kodowania (opis sposobu tworzenia kodu, struktura kodu, przepływ da-
nych oraz sterowania, komentarze, podział na obiekty, użyte biblioteki, sposoby
dołączania obcych obiektów, kodów),
• standardy dokumentacji (opis sposobu tworzenia dokumentacji projektowej),
• standardy nazewnictwa (określa nazwy projektów, plików, drzewo katalogowe
projektu),
• standardy obsługi błędów,
• standardy zachowania bezpieczeństwa w komunikacji,
Przestrzeganie standardów przez wszystkich uczestników daje możliwość szybkiej
zmiany lub uzupełnienia uczestników projektu bez tracenia czasu na wdrożenie no-
wych osób w projekt. Dodatkowo daje możliwość korzystania z wcześniej już zreali-
zowanych projektów, bibliotek, czy fragmentów kodów. Znajomość standardów ko-
dowania oraz jednolitość dokumentacji ułatwia również testowanie aplikacji przez
testerów oraz szybką reakcję na zaistniałe błędy [5].
3. Zadaniowa platforma zarządzania projektem
Platforma zadaniowa stanowi właściwe środowisko zarządzania rozproszonym projek-
tem. Umożliwia ona pracę z wieloma projektami oraz osobami (klientami, programi-
stami, testerami). Każdy projekt ma opisane swoje cechy, tj. harmonogram, budżet,
osoby przyporządkowane do projektu.

4. 4 I.A. Tarnowski
projekt opis
harmonogram
budżet
osoby
PLATFORMA ZADANIOWA
osoba funkcja
uprawnienia
opis
czynności
administrator
kierownik projektu
wykonawcy (programista)
tester
klient
raport
opis
odbiorca
nadawca
zadanie
priorytet
status
opis
odbiorca
nadawca
notatka opis
nadawca
pliki opis
uprawnienia
projekt 2
projekt n
Rys. 2. Model platformy zadaniowej
Dostęp do tych informacji jest uzależniony od uprawnień danej osoby w projekcie.
Uprawnienia te są opisane w cechach osoby, jako jej funkcja. Osoba z funkcją kie-
rownika projektu przydziela zadania, przydziela prawa do zasobów, kontroluje czas
realizacji zadań zgodnie z harmonogramem. Natomiast pozostałe osoby mogą rapor-
tować oraz tworzyć notatki. Raporty dostępne są wybranym osobom, natomiast notat-
ki stanowią medium wymiany informacji między wszystkimi uczestnikami projektu
(są ogólnodostępne). Rola osób testujących ogranicza się do pracy z projektem, nato-
miast platforma zadaniowa jest przez nie używana do tworzenia raportów błędów
(rozwijają wątki raportujące, z których korzysta kierownik projektu oraz programiści).
Tego typu zadania oraz rozwiązania zostały opisane w [5, 6]. Klient ma wgląd w pro-
jekt oraz jego rozwój, nie ma natomiast uprawnień do wglądu w szczegółowe infor-
macje, jednak może tworzyć raporty i zadania. Ścisła współpraca z klientem leży
w założeniach programowania ekstremalnego [2, 4].

5. Bezpieczne zarządzanie rozproszonym projektem programistycznym... 5
Platforma daje możliwość elastycznej zmiany ról, cech projektu (terminy, budżet) oraz
kontroli terminowości realizacji. Pozwala na wygodne przekazywanie informacji
o różnych znaczeniach i kategoriach (zadania, raporty, notatki) przez osoby pracujące
nad projektem. Ponadto podstawowymi zadaniami platformy jest kontrola uprawnień
dostępu do informacji przez poszczególne osoby oraz prawidłowość przepływu
wszelkich informacji.
4. Implementacja
Opisany model oraz realizująca go platforma zadaniowa została zaimplementowana
jako środowisko pracy grupowej. Aplikacja działa w oparciu o model klient-serwer.
Serwer usługi (właściwą platformę pracy) stanowi aplikacja „zainstalowana” na ser-
werze WWW (Apacze 2.0.55 wraz z modułem PHP 5.1.2) połączonym z bazą danych
(MySQL 5.0.18). Oparcie rozwiązania o interfejs WWW, umożliwia korzystanie
z usługi z dowolnego komputera wyposażonego w przeglądarkę internetową, podłą-
czonego do sieci komputerowej (internetu), przez co aplikacja staje się uniwersalna
oraz ogólnie dostępna dla pracującego zespołu (niezależnie od platformy systemowej).
Zasadniczą częścią usługi po stronie serwera stanowi baza danych, która zawiera
wszystkie informacje dotyczące:
• realizowanych projektów (budżet, harmonogram, powiązania),
• osób związanych z działalnością firmy (mających dostęp do platformy),
• zadań,
• raportów (błędów, notatek),
• udostępnianych zasobów (plików),
• uprawnień do poszczególnych elementów (projektów, zadań, zasobów, możliwo-
ści zarządzania).
Baza danych została zaprojektowana z uniknięciem redundancji danych, z zachowa-
niem zasad normalizacji do postaci normalnych [7].
Aplikacja została oparta o język PHP. By zachować wysoką jakość aplikacji oraz po-
prawność technologiczną zastosowano model-widok-kontroler (ang. Model-View-
Controller, MVC). W ten sposób oddzielono istniejące w aplikacji warstwy abstrakcji:
interfejs użytkownika, dane, ścieżki przepływu danych oraz przepływu sterowania.
Aby w miarę dokładnie oddać model wraz z zależnościami funkcjonalnymi zastoso-
wano mechanizmy programowania obiektowego. Komunikację z bazą danych zapew-
niono poprzez wykorzystanie bibliotek obiektów PEAR: DB oraz DataObject [8].
W ten sposób odseparowano logicznie aplikację, dane oraz bazę danych. Zgodnie
z modelem opisanym w podrozdziale 2.2, poszczególne elementy znalazły odzwier-
ciedlenie w obiektach programistycznych. I tak zostały wyróżnione obiekty:
• obiekt projekt (dziedziczy po obiekcie strona),
• obiekt osoba (dziedziczy po obiekcie strona),
• obiekt zadanie (dziedziczy po obiekcie projekt),
• obiekt raport (dziedziczy po obiekcie projekt),

6. 6 I.A. Tarnowski
• obiekt notatka (dziedziczy po obiekcie projekt),
• obiekt plik (dziedziczy po obiekcie projekt),
• obiekt dana (obiekt związany z obsługą dostępu do bazy danych),
• obiekt strona (realizuje powiązanie między interfejsem użytkownika, a pozosta-
łymi obiektami).
Element widoku (interfejs użytkownika) został zrealizowany w oparciu o szablony
SMARTY. Umożliwia to łatwą modyfikację w ramach danego interfejsu lub przysto-
sowanie go do innego widoku, czy też do zastosowań w innej firmie.
4.1. Funkcje aplikacji
Operacje jakie udostępnia aplikacja są uzależnione od funkcji osoby korzystającej
z aplikacji. Administrator zarządza użytkownikami (nadaje im funkcje i prawa, two-
rzy rozliczenia za projekty i zadania, kontroluje właściwy przepływ danych, tworzy
kopie zapasowe, archiwizuje projekty). Największe uprawnienia w zakresie projektu
ma kierownik projektu: tworzy on nowy projekt, dodaje uczestników projektu (in-
formacje o programistach, testerach, klientach, innych kierownikach projektu), przy-
dziela zadania w ramach projektu, kontroluje czas realizacji zadań oraz dostęp do za-
sobów, tworzy oraz czyta raporty i notatki. Kolejnym uczestnikiem w hierarchii jest
programista (developer), który jest odpowiedzialny za faktyczną realizację projektu.
W zakresie platformy zadaniowej otrzymuje on informacje o jego zadaniach oraz o u-
dostępnionych mu zasobach. Po wykonaniu zadania zmienia on cechy zadania (status,
priorytet), może on tworzyć oraz czytać raporty i notatki. Rola testerów oraz klienta
w aplikacji została sprowadzona do raportowania błędów oraz tworzenia notatek. Ra-
portowanie (m.in. błędów) zostało zrealizowane zgodnie z zasadami opisanymi
w [5, 6].
Niektóre zdarzenia (tj. przydzielenie zadania, zmiana statusu/priorytetu zadania, raport
błędu, przedzielenie do projektu), mające miejsce w aplikacji, są połączone z automa-
tycznym wysłaniem informacji (mail) do właściwego adresata.
Osoby zarejestrowane w bazie danych pełnią z góry określoną funkcję. Można zmie-
nić funkcje danej osoby, jednak jednej osobie nie można udostępnić wielu funkcji
jednocześnie. Wiąże się to bezpośrednio z modelem opartym na hierarchii funkcji
i powiązanymi z nimi zadaniami, niemniej każda osoba może uczestniczyć jednocze-
śnie w wielu projektach.
5. Bezpieczeństwo aplikacji
Biorąc pod uwagę potencjalne zagrożenia jakie są związane z działaniem sieci kompu-
terowej aplikacja została napisana w możliwie bezpieczny sposób. Bezpieczeństwo
rozumiane jest w dwóch znaczeniach:
1. zapewnienia tajności danych, tak by nieuprawnione osoby nie miały dostępu do
danych,

7. Bezpieczne zarządzanie rozproszonym projektem programistycznym... 7
2. niezawodności aplikacji (oraz bazy danych), tak by usługa świadczona była
w sposób ciągły.
Pierwszy aspekt został zrealizowany na kilku poziomach. Na poziomie aplikacji
wprowadzona została autoryzacja i kontrola uprawnień do wykonywania danej czyn-
ności (tj. dodanie zadania, czytanie zadania, dodanie notatki, dodanie użytkownika,
dostęp do szczegółowych informacji). Te funkcje są realizowane w zakresie odpo-
wiednich klas obiektów. Zgodnie z zasadami bezpiecznego tworzenia aplikacji wyko-
rzystano takie mechanizmy zwiększania bezpieczeństwa aplikacji, jak: mechanizm
sesji, kodowanie haseł na poziomie aplikacji, jak również na poziomie bazy danych,
weryfikacja i kontrola informacji przekazywanych z formularzy do aplikacji. Unie-
możliwiono ataki typu SQL injection, PHP injection oraz XSS (ang. Cross Site
Scripting) poprzez kontrolę wszystkich zmiennych wewnątrz aplikacji.
Kolejnym poziomem bezpieczeństwa jest poziom protokołu przesyłającego dane. Ze
względu na ważność przesyłanych danych dla korzystającej z zaprojektowanej plat-
formy firmy (wszystkie szczegóły projektu, budżet, harmonogram, dane klientów,
programistów), zastosowano protokół HTTPS do przesyłania danych. Protokół ten
zapewnia szyfrowanie połączenia, uniemożliwiając przechwycenie informacji poprzez
podsłuchiwanie (ang. sniffing) [9, 10]. Dodatkowo aplikacja regularnie wykonuje ko-
pię danych (posiada również budowaną funkcję związaną z wykonaniem kopii, jak
również z odtworzeniem stanu danych) oraz rejestruje wszystkie zdarzenia (logowanie
użytkownika, dodanie zdarzenia, zmiana statusu, priorytetu, odczyt, zapis danych)
w pliku dziennika zdarzeń (logi aplikacji). Kopie bezpieczeństwa oraz dzienne pliki
rejestrów zdarzeń mogą być przechowywane na zdalnym serwerze (przy wykorzysta-
niu oprogramowania secure copy - scp).
Niezawodność dostępu do danych została zwiększona poprzez replikację bazy danych
na fizycznie oddzielnym serwerze bazy danych. Zastosowanie replikacji powoduje
rozłożenie obciążenia serwera bazy danych na dwa fizycznie serwery oraz wyelimi-
nowanie braku dostępu do bazy danych w przypadku awarii sieci komputerowej w ra-
mach jednej bazy danych. Aplikacja sprawdza szybkość połączenia z bazami danych
i jest w stanie korzystać z wybranej bazy danych. W sytuacji wyłączenia jednej z baz,
aplikacja korzysta z drugiej. Synchronizacja danych między bazami jest zrealizowana
na poziomie konfiguracji bazy danych (jak mechanizm replikacji).
Bezpieczeństwo pracy w zasadniczej części jest uzależnione od stosowania się do
standardów pracy opisanych w punkcie w podrozdziale 2.3 (szczególnie w części do-
tyczącej zasad zachowania bezpieczeństwa w komunikacji). Jest to związane z faktem,
że człowiek jest także elementem systemu informatycznego, a bezpieczeństwo całego
systemu zależy od bezpieczeństwa wszystkich składowych elementów.
6. Podsumowanie
W pracy zaproponowano model oraz opis implementacji platformy zadaniowej znaj-
dującej zastosowanie w firmach outsourcing’owych działających w sposób rozproszo-
ny z wykorzystaniem sieci komputerowej do komunikacji. Opisana platforma ma za
zadnie przyspieszyć, usprawnić oraz ujednolicić wymianę informacji wewnątrz firmy

8. 8 I.A. Tarnowski
w ramach realizowanego projektu. Wdrożenie opisanego rozwiązania znacząco
wspomogło kierowanie wieloma rozproszonymi projektami w firmie outsour-
cing’owej oraz przyspieszyło realizację projektów (w pełni wdrożono zasady progra-
mowania ekstremalnego). Potwierdziło to poprawność zaproponowanego modelu.
Dalszy Rozwój modelu, platformy oraz aplikacji może być związany z umożliwie-
niem dokonywania rozliczeń finansowych w ramach realizacji projektu. W obecnym
momencie zagadnienia finansowe stanowią jedynie informację dodatkową wewnątrz
projektu.
LITERATURA
1. Pressma R.S.: Inżynieria oprogramowania, praktyczne podejście do inżynierii oprogramowa-
nia. Wydawnictwo Naukowo-Techniczne, Warszawa 2005.
2. Beck K.: Extreme Programming Explained: Embrace Change. Addison-Wesley, Boston,
2004.
3. Strige, W.: Reports from the field - using extreme programming and other experiences. Soft-
ware, IEEE, Volume 18, Issue 6, Nov.-Dec. 2001, pp: 17-18.
4. Scott W.: Extreme programming turning the world upside down. Computing & Control Engi-
neering Journal, Volume 14, Issue 3, June-July 2003, pp:18-23.
5. Hieatt E.; Mee R.: Going faster: testing the Web application. Software, IEEE, Vol-
ume 19, Issue 2, March-April 2002, pp: 60-65.
6. Tarnowski I.: System zgłaszania błędów. Software Developer’s Journal, nr 10 (130), paź-
dziernik, 2005, s. 40-44.
7. Elmasri R., Navathe S.B.: Wprowadzenie do systemów baz danych. Wydawnictwo Helion,
Gliwice 2005.
8. Lecky-Thompson E., Eide-Goodman H., Nowicki S.D., Cove A..: PHP5. Zaawansowane
programowanie. Wydawnictwo Helion, Gliwice 2005.
9. IEEE Std 2001-1999, IEEE recommended practice for internet practices - Web page engineer-
ing - intranet/extranet applications, 18 Mar 1999.
10. IEEE Std 2001-2002 (Revision of IEEE Std 2001-1999), IEEE Recommended Practice for the
Internet - Web Site Engineering, Web Site Management, and Web Site Life Cycle, 2003.