Sposoby zarządzania przepływem uwag w rozproszonych

V Konferencja PLOUG
Zakopane
Październik 1999
Sposoby zarządzania przepływem uwag w rozproszonych
zespołach projektowych
Andrzej Adamczyk
[email protected]
Instytut Technik Telekomunikacyjnych i Informatycznych, Poznań
Autor
Absolwent Francusko-Polskej Wyższej Szkoły Nowych Technik Informatyczno-Komunikacyjnych w Poznaniu.
Od trzech lat techniczny kierownik projektów w zespole Systemów Informatycznych i Multimediów, Instytutu
Technik Telekomunikacyjnych i Informatycznych w Poznaniu.
Streszczenie
Nie ulega wątpliwości, iż komunikacja w zespole projektowym powinna być jednoznaczna, spójna i skuteczna.
Jej skuteczność jest jednym z czynników, który wydatnie wpływa na organizację pracy zespołu projektowego,
a przez to pozwala zwiększyć rentowność całego projektu. W dzisiejszych czasach wypracowane zostały nowe
metody zarządzania zasobami ludzkimi. Metody te zmierzają generalnie do rozproszenia zespołu projektowego,
czy to w przestrzeni (teleworking), czy w sensie przydzielenia poszczególnych pracowników do projektów.
Referat dokonuje przeglądu metod testowania systemów informatycznych i zarządzania uwagami ze
szczególnym uwzględnieniem projektów, w których zasoby ludzkie są rozproszone. Stanowi on efekt analizy
kilkuletniej działalności ITTI związanej z wykonywaniem i wdrażaniem systemów opartych na bazach danych.
1. Wstęp
Wykorzystanie nowoczesnych technik zarządzania projektami pozwala na odejście od koncepcji "linii
produkcyjnej" na korzyść zintegrowania zasobów przedsiębiorstwa w celu osiągnięcia określonych celów.
Kluczem do sukcesu są ludzie. Należy dążyć do tego, żeby nie tylko pozyskać najlepszych pracowników, ale
również żeby najlepiej wykorzystać ich umiejętności i możliwości. Nowoczesne metody oparte na
sterowaniu procesami pozwalają na efektywne zarządzanie zasobami ludzkimi w projektach.
Dlaczego nie wystarczą nam te metody? Owszem wystarczą, ale w małej skali. Zespół Systemów
Informatycznych ITTI od początku swego istnienia wykonywał wiele projektów informatycznych
równocześnie (w tym samym czasie), ale w miarę jak wielkość projektów zarówno mierzona ceną, jak i
zakresem funkcjonalnym produktów, zaczęła rosnąć pojawiła się idea stworzenia środowiska do zarządzania
projektami. Z powodu ograniczonych możliwości inwestycyjnych chcemy zacząć od pewnych fragmentów,
które naszym zdaniem najbardziej wydłużają czas wykonywania projektu, czyli od systemu wspomagającego
weryfikację tworzonego oprogramowania. Wierzymy, że zaimplementowanie nowoczesnego środowiska
narzędzi do zarządzania projektami ułatwi prowadzenie wielu projektów w tym samym czasie i umożliwi
lepszą kontrolę zachodzących w projekcie procesów.
Naszym zdaniem główny nacisk należy położyć na komunikację w zespole projektowym, która
powinna być jednoznaczna, spójna i skuteczna. Warunek jednoznaczności gwarantuje, że adresat przesyłanej
informacji zrozumie ją dokładnie według intencji jej nadawcy. Spójność oznacza, że w komunikacji
pomiędzy członkami zespołu projektowego nie będą krążyły informacje sprzeczne ze sobą. Skuteczność
komunikacji jest jednym z czynników, który wydatnie wpływa na organizację pracy zespołu projektowego, a
przez to pozwala zwiększyć rentowność całego projektu. Ma to szczególne znaczenie w przypadku
rozproszenia fizycznego analityków, programistów, testerów i innych pracowników zespołu projektowego.
Trzeba zaznaczyć, że idee zamieszczone w niniejszym referacie opierają się na informacjach
praktycznych, jakie zdobył Zespół Systemów Informatycznych ITTI w czasie realizacji kilku dużych i
średnich projektów informatycznych. Projekty te zorientowane były na systemy bazodanowe i internetowe.
Również klienci, na zamówienie których systemy informatyczne były wykonywane różnili się dość znacznie
od siebie. Były to przedsiębiorstwa od dużych operatorów telekomunikacyjnych do małych firm, od spółek
skarbu państwa do firm typowo komercyjnych. Dlatego można śmiało uważać, że zdobyte doświadczenie
wystarcza do sformułowania opisanych w referacie wniosków.
W Internecie dostępna jest prezentacja związana z niniejszym referatem [1].
2. Terminologia
„Język najlepiej znany wszystkim programistom to przekleństwa”
postulat Troutmana
Aby precyzyjnie opisać problem należy zacząć od zdefiniowania pewnych pojęć i określenia modelu
generycznego środowiska projektowego. W tym celu zacznijmy od definicji terminu projektu
2
informatycznego. Projektem informatycznym będziemy nazywać zespół zadań do wykonania,
zmierzających do wspólnego, jasno określonego celu, którym jest usługa bądź produkt informatyczny.
Załóżmy, że produktem projektu informatycznego jest pewien system czyli zestaw współpracującego
ze sobą sprzętu i oprogramowania spełniający kryteria postawione w specyfikacji. W skrócie systemem
będziemy nazywali również samo oprogramowanie wchodzące w jego skład. System ten składa się z
modułów, które są takimi częściami systemu, do których możemy odnosić się jako do oddzielnych
elementów oprogramowania ze względu na ich funkcjonalności, jak i architekturę systemu. Moduł jest też na
tyle małą częścią oprogramowania, że do jego stworzenia lub testowania wystarczy jedna osoba w zespole
projektowym. Wiadomo, że w rzeczywistym projekcie informatycznym takich elementów nie sposób
wyróżnić. Moduły są dość ściśle powiązane funkcjonalnie, co utrudnia ich wykonywanie i testowanie w
oderwaniu od systemu. Nie jest to jednak niemożliwe do wykonania w przybliżeniu. Na przykład w
przypadku wykonywania aplikacji z wykorzystaniem narzędzi Oracle Developer/2000 modułami mogą być
poszczególne formularze i raporty.
Natomiast uwagami nazywać będziemy jakąkolwiek informację pochodzącą od osoby testującej
moduły lub samego użytkownika na temat ich funkcjonowania. Jak się można domyślić główną część uwag
stanowią zgłoszenia wadliwego funkcjonowania testowanego modułu, ale uwagą może też być zapytanie
skierowane do wykonawcy lub – w ramach zespołu projektowego po stronie wykonawcy – do programisty,
na które nie można znaleźć odpowiedzi w dokumentacji. Jeżeli uwaga należy do tej pierwszej, najbardziej
licznej kategorii jej konsekwencją jest wykonanie zmiany w module.
3. Kontrola zmian
„Każda dostatecznie zaawansowana technologia niczym nie różni się od magii”
trzecie prawo Clarke'a
Aby zmiany były dokonywane w zgodzie ze sztuką inżynierii oprogramowania oraz aby nie
doprowadzić do zagubienia się w „gąszczu” zmian, których liczba w dużym projekcie łatwo może sięgnąć
kilkunastu tysięcy, należy stosować opracowane już dawno metody. Wśród tych metod wyróżniamy
procedury służące do kontroli zmian (ang. Change Control), które wchodzą w skład nowoczesnych metod
zarządzania konfiguracją oprogramowania tzw. SCM (ang. Software Configuration Management) [2].
Opisane w referacie metody są w pełni zgodne z normami IEEE dotyczącymi zarządzania konfiguracją
oprogramowania [3-5] oraz ze wskazówkami TickIt opartymi na normie ISO 9001 [6].
Wyróżniamy trzy typy zmian ze względu na powód a zarazem cel ich wystąpienia:
•
zmiany mające na celu usunięcie występowania błędów w rozwijanym systemie,
•
zmiany zmierzające do skompensowania problemów wynikających ze współdziałania systemu z
jego otoczeniem programowym lub/i sprzętowym,
•
zmiany zmierzające do dostosowania systemu do zmieniających się uwarunkowań biznesowych lub
zmian specyfikacji.
3
Schemat na Rys 1 przedstawia proces kontroli zmian.
1. Rozpoznanie potrzeby zmiany
2. Żądanie zmiany przez użytkownika
lub inną osobę testującą
(wygenerowanie uwagi)
3. Ocena zmiany przez programistę
4. Sporządzenie raportu o zmianie
5. Podjęcie decyzji o wprowadzeniu
lub odrzuceniu żądania zmiany
6a. Ustawienie żądania w kolejce w celu wykonania zmiany
6b. Odmowa żądania zmiany
7a. Przydzielenie osób obsługujących zmianę
7b. Poinformowanie użytkownika
8a. Sprawdzenie możliwości dokonania zmiany (dostęp i synchronizacja zmian)
i zablokowanie zmienianego modułu
9a. Dokonanie zmiany
10a. Przegląd zmiany
11a. Odblokowanie zmienianego modułu
12a. Ustalenie planu testowania zmiany
13a. Testowanie
14a. Wprowadzenie zmiany do nowej wersji oprogramowania
15a. Dostarczenie nowej wersji
Rys 1: Proces kontroli zmiany
Procedura kontroli zmian łączy w sobie metody postępowania w przypadku wystąpienia potrzeby
dokonania zmian w oprogramowaniu, z oprogramowaniem narzędziowym pozwalającym na automatyczną
kontrolę tych zmian.
Do kontroli wersji oprogramowania zostało już wyprodukowanych wiele systemów, do których należą
m.in.:
•
TLIB Version Control firmy Burton Systems Software,
4
•
CS-RCS firmy ComponentSoftware,
•
Diamond CM firmy Diamonnd Optimum Systems, Inc.,
•
PVCS firmy Intersolv,
•
MKS Source Integrity Professional Edition firmy Mortice Kern Systems, Inc.,
•
Perforce firmy Perforce Software Inc.,
•
GP-Version firmy Quality Software Components Ltd.,
•
Code Co-op firmy Reliable Software,
•
StarTeam firmy StarBase Corp.,
•
ViCiouS Pro firmy SureHand Software.
Programy te potrafią poradzić sobie z kontrolą współdzielenia poszczególnych modułów oraz pomagają
wykonywać podstawową dokumentację na temat dokonywanych zmian nawet gdy programiści nie
komunikują się ze sobą w sposób bezpośredni. Nadają się zatem do zastosowań również w przypadku
projektów w rozproszonym zespole projektowym. Jednak kontrola wersji to nie wszystko. Obejmuje ona
tylko obszar procesu kontroli zmian od 8a do 11a. Pozostaje bardzo uciążliwa i mozolna praca polegająca na
zbieraniu uwag (żądań zmian) i ich obróbce. Zautomatyzowanie tej właśnie pracy jest bardzo ważne, gdyż
pozwala zaoszczędzić dużą ilość czasu związanego z zarządzaniem projektem oraz pozwala na generowanie
dokładnych i miarodajnych raportów dotyczących uwag, a to z kolei ułatwia ocenę pracy programistów oraz
pozwala wskazać etapy projektu, gdzie doszło do zaniedbań.
Istnieje tylko jeden produkt, który spełnia wymagania systemu do zarządzania uwagami w
rozproszonym zespole projektowym. Jest to system firmy Lotus o nazwie ProjecTrak – Software Project
Management Suite. Na wzór innych produktów tej firmy jest to system ten posiada przyjazny interfejs
użytkownika i bogaty zestaw funkcji. Jest to jednak aplikacja, którą trzeba zainstalować na komputerze
każdego członka zespołu. Naszym zdaniem (szczególnie jeżeli mamy do czynienia z programistami z
zewnątrz firmy-wykonawcy) znacznie wygodniejsza do tego celu byłaby technologia WWW. Wykorzystanie
ogólnie dostępnych przeglądarek internetowych, jako interfejsu systemu uwalnia nas od konieczności
instalacji systemu oraz ułatwia administrację i zachowanie spójności danych, gdyż wszelkie informacje,
którymi posługiwałby się taki system mogłyby być umieszczone na centralnym serwerze firmy.
W dalszej części referatu zostanie określony model środowiska projektowego i zanalizowane założenia
według których można by zrealizować taki internetowy system wspomagający kontrolę zmian w
oprogramowaniu i zarządzanie uwagami, przystosowany do warunków pracy w rozproszonym zespole
projektowym.
5
4. Środowisko projektu
„Złożony problem, zrozumiany i podzielony na mniejsze problemy, nie jest już problemem – to
koszmar”
jedno z praw Murphy'iego
W rozdziale tym zostanie pokrótce omówiony model typowego środowiska projektu w sensie
organizacyjnym, z jakim spotykał się Zespół Systemów Informatycznych ITTI w czasie realizacji projektów
informatycznych. Opis ten również stanowi pewne założenie potrzebne dla dalszych rozważań.
Zakładamy, że istnieją tylko dwie strony zaangażowane w projekt: klient i wykonawca. Zaniedbujemy
tu przypadki, kiedy projekt (jego przebieg lub produkty) jest oceniany przez trzecią instytucje lub
użytkownikiem końcowym nie jest klient projektu. W pierwszym przypadku taki audyt projektu może być
traktowany, jako oddzielny projekt, gdyż jego cele są z gruntu różne od celów głównego projektu, a jak
wiadomo projekt to zbiór zadań do wykonania zmierzających do określonego celu. Drugi przypadek
natomiast nie zmienia warunków rozważań.
Po obu stronach wyznaczeni zostają kierownicy administracyjni projektu i ewentualnie ich zastępcy,
którzy reprezentują interesy stron oraz wyznaczają ich oficjalne stanowisko w różnych sytuacjach oraz
kierownicy
techniczni
odpowiedzialni
za
organizowanie
środowiska
projektu,
harmonogramu,
infrastruktury technicznej, zasobów, itp. Z reguły zarówno po stronie klienta, jak i wykonawcy kierownikiem
administracyjnym nie jest oficjalny reprezentant firmy, którym może być dyrektor czy prezes. Taka osoba,
którą w skrócie nazwiemy decydentem podpisuje umowę oraz wszelkie aneksy, których potrzeba
zatwierdzenia przez obie strony zaistnieje w czasie projektu. Decydent również powinien być informowany o
projekcie, oczywiście na innym poziomie szczegółowości niż kierownicy projektu. Wyżej wymienione osoby
wyczerpują listę aktorów w projekcie występujących symetrycznie zarówno po stronie klienta, jak i po
stronie wykonawcy.
Jeżeli chodzi o pozostałe role członków zespołu projektowego po stronie wykonawcy to weźmiemy pod
uwagę programistów, z których każdy jest odpowiedzialny za powierzony mu moduł oprogramowania oraz
testerów modułów (dla przejrzystości pomijamy analityków i innych pracowników, którzy są znacznie
rzadziej zaangażowani w procesy kontroli zmian oprogramowania). Po stronie klienta zaś można wyróżnić
również testerów otrzymanego oprogramowania oraz końcowych użytkowników systemu, którzy również
mogą być aktywnym źródłem uwag.
Z powyższego wynika, że testowanie oprogramowania odbywa się jakoby w dwóch etapach: u
wykonawcy przed przekazaniem produktu oraz u klienta po jego przekazaniu. Testowania te noszą nazwę
odpowiednio: testowania alfa i testowania beta. Tak też oznaczone są produkty (moduły), które w danej
chwili podlegają danemu testowaniu. Rys 2 zawiera diagram stanów przedstawiający proces implementacji i
testowania modułów.
6
rozwijanie
testowanie
testowanie
α
β
OK
Rys 2: Proces implementacji i testowania oprogramowania
O ile testowanie alfa ma na celu przede wszystkim podwyższenie jakości produktu, o tyle testowanie
beta spełnia dodatkowo funkcje weryfikacji i walidacji dostarczonych produktów wykonywane przez klienta.
Testowanie beta może angażować osoby wyznaczone do testowania modułów po stronie klienta, ale może
być rozszerzone o testowanie przez końcowych użytkowników systemu. Testowanie przez użytkowników
systemu pozwala wykryć błędy nie tylko merytoryczne, ale i niedogodności ergonomiczne, których nie
spostrzeżono, ani na etapie pisania dokumentacji projektowej, ani na etapie wykonania ewentualnego
prototypu systemu. Taki typ testowania nazywa się testowaniem użyteczności systemu (ang. usability
testing). Po przejściu obu etapów testowania z pozytywnym rezultatem można uznać, że dany produkt jest
gotowy do wdrożenia.
Skoro wymieniliśmy już funkcje osób zaangażowanych w projekt po obu stronach zdefiniujmy teraz
typowe procesy komunikacyjne pomiędzy nimi, aby mieć pełny obraz przepływu informacji. Obraz ten jest
niezbędny do zaprojektowania w przyszłości systemu zarządzania uwagami. Omówimy po kolei wszystkich
uczestników projektu i sposób w jaki kontaktują się oni z pozostałymi pracownikami.
Zacznijmy od administracyjnego kierownika projektu. Jego schemat komunikacyjny jest dość prosty.
Przedstawia go Rys 3.
Techniczny
Kierownik Projektu
Administracyjny
Kierownik
Projektu
Techniczny
Kierownik Projektu
Rys 3: Interakcja prowadzona przez Administracyjnego Kierownika Projektu
Jest on informowany przez technicznego kierownika projektu o postępach w wykonaniu
poszczególnych zadań projektu. W przypadku omawianego etapu testowania oprogramowania otrzymywać
on powinien od niego informacje syntetyczne na temat uwag testerów i samego klienta na temat
poszczególnych modułów. Informacja taka może się składać z liczby zgłoszonych uwag dotyczących
poszczególnych modułów w kontekście ich typu i charakteru. Kierownik administracyjny powinien być też
informowany o uwagach, których interpretacja lub wykonanie wykracza poza kompetencje kierownika
technicznego. W takich sytuacjach kierownik administracyjny powinien podejmować określone decyzje w
celu zapewnienia optymalnego przebiegu etapu testowania. Zatem informacja zwrotna może być kierowana
do kierownika technicznego w postaci odpowiedzi na przesłane uwagi, bądź poleceń do wykonania.
7
Zaniedbujemy tu obustronny kontakt pomiędzy administracyjnymi kierownikami projektu po stronie
wykonawcy i klienta oraz informacje przesyłane decydentom obu firm.
Kolejną omawianą funkcją niech będzie rola kierownika technicznego. Jak to zostało zasygnalizowane
powyżej, informuje on kierownika administracyjnego o przebiegu testowania oraz przesyła mu
kontrowersyjne uwagi otrzymując w zamian polecenia do wykonania. Dodatkowo kontaktuje się z osobami
testującymi moduły. Przesyłają one informacje o tym, że dany moduł przeszedł pozytywnie testy alfa. Jeżeli
z jakiegoś względu moduł, który przeszedł ten etap testów wymaga według kierownika technicznego
naprawy, on sam generuje uwagę, która powinna trafić do programisty wraz z poleceniem wykonania zmiany
oraz do testera danego modułu, aby był on poinformowany o podjętej decyzji. Schemat przepływu informacji
w przypadku roli kierownika technicznego projektu przedstawia Rys 4.
Administracyjny
Kierownik Projektu
Techniczny
Kierownik
Projektu
Administracyjny
Kierownik Projektu
Tester
Tester
Programista
Rys 4: Interakcja prowadzona przez Technicznego Kierownika Projektu
Jeżeli chodzi o osoby testujące moduły po stronie wykonawcy to ich model komunikacyjny można
opisać schematem pokazanym na Rys 5.
Techniczny
Kierownik Projektu
Tester
Programista
Techniczny
Kierownik Projektu
Programista
Rys 5: Interakcja prowadzona przez osobę testującą system
Tester modułów otrzymuje informacje od kierownika technicznego projektu o jego decyzjach
dotyczących przejścia pomiędzy fazą testowania alfa i beta. Przesyła mu natomiast informacje o pomyślnym
zakończeniu fazy testowania alfa. Tester kontaktuje się też z programistą, od którego otrzymuje wykonane
moduły do testowania, natomiast przekazuje swoje uwagi na temat testowanych modułów, w przypadku,
kiedy sytuacja tego wymaga.
Ostatnią osobą w projekcie po stronie wykonawcy, którą tutaj omówimy jest programista. Kontaktuje
się on z kierownikiem technicznym – podobnie jak ma to miejsce w przypadku testera – otrzymując
polecenia wykonania zadań (uwagi kierownika technicznego). Również tester przekazuje programiście uwagi
na temat testowanych modułów, jeżeli te moduły wymagają dokonania zmian. Programista natomiast po
wykonaniu zmiany w module, którego dotyczy otrzymana uwaga przekazuje go do testowania testerowi.
8
Techniczny
Kierownik Projektu
Programista
Tester
Tester
Rys 6: Interakcje prowadzone przez Programistę
Podsumowując, źródłem uwag po stronie wykonawcy jest przede wszystkim tester, ale również
techniczny kierownik projektu. Nie ulega też wątpliwości, że należy udostępnić też kierownikowi
technicznemu możliwość wysłania zapytania do wybranego programisty w celu otrzymania potrzebnych
informacji do podjęcia decyzji o tym czy dana uwaga powinna zostać uwzględniona w trakcie realizacji
zmian. Programista jest w stanie odpowiedzieć jaka jest wykonalność danego zadania (ang. feasibility) oraz
jakie zasoby muszą być w to wykonanie zaangażowane. Są to informacje różne od uwag, wiec należy je
rozdzielnie potraktować przy projektowaniu systemu.
Schemat przedstawiający przepływ informacji pomiędzy poszczególnymi osobami zaangażowanymi w
projekt po obu stronach został przedstawiony na Rys 7.
WYKONAWCA
KLIENT
AKP
AKP
Decydent
Decydent
TKP
TKP
T1
T2
...
Tn
T1
T2
...
Tk
P1
P2
...
Pm
U1
U2
...
Ul
AKP
TKP
T
P
- administracyjny kierownik projektu
- techniczny kierownik projektu
- tester systemu
- programista
AKP
TKP
T
U
- administracyjny kierownik projektu
- techniczny kierownik projektu
- tester systemu
- użytkownik systemu
Rys 7: Przepływ informacji pomiędzy uczestnikami projektu informatycznego
Nie będziemy omawiać przepływu informacji po stronie klienta, gdyż jest ona do pewnego stopnia
analogiczna, jak w przypadku wykonawcy. Jedyną różnicą jest to, że brak w niej programistów, a wszystkie
uwagi są kierowane nie w dół schematu, ale w górę oraz „paczkowane” przez technicznego kierownika
projektu po stronie klienta i wysyłane do wykonawcy. Natomiast tak jak już zostało to opisane, testowaniem
9
dostarczonego oprogramowania w fazie beta zajmują się testerzy oraz użytkownicy po stronie klienta
(najlepiej w sposób sekwencyjny w czasie).
Ponadto zakładamy, że każdemu modułowi jesteśmy w stanie przypisać jednego programistę i jedną
osobę testującą, które będą się nim zajmowały przez cały okres projektu.
W powyższym rysunku uwzględniono także decydentów, którzy powinni otrzymywać okresowe raporty
od kierowników administracyjnych oraz – stosowanie do podejmowanych decyzji – wydawać im polecenia
natury bardziej strategicznej dla projektu.
5. Przykład obsługi uwagi pochodzącej od klienta
Aby lepiej zrozumieć procesy zachodzące w celu obsługi uwagi prześledźmy je na przykładzie.
Omawiany przykład dotyczy uwag, których źródło znajduje się po stronie klienta. Oto przykładowy
scenariusz obsługi uwagi, który wynika z najnowszych procedur przyjętych przez Zespół Systemów
Informatycznych ITTI i stosowanych w ostatnim projekcie:
Programista
Tester
Kierownik
Techniczny
Klient
Zgłoszenie uwagi przez klienta
Polecenie wykonania zmiany
Przekazanie do
testowania
Odrzucenie
poprawki
Przekazanie do
testowania
Akceptacja poprawki
Dostawa poprawionego modułu
Rys 8: Przykładowy scenariusz obsługi uwagi od klienta
Klient zgłasza uwagę – informacja ta wędruje do kierownika technicznego. Kierownik techniczny
nadaje uwadze unikalny identyfikator składający się z konkatenacji symbolu modułu, którego uwaga dotyczy
(lub innych identyfikatorów np. w przypadku uwag ogólnych, lub uwag do danych) i unikalnego numeru
uwagi. Następnie klasyfikuje uwagę wg priorytetu (ważności nie uwzględnienia uwagi dla działania systemu)
oraz wg zgodności z dokumentacją projektową. Załóżmy, że w danym przypadku kierownik techniczny
stwierdza zasadność uwagi oraz to, że aby uwaga została obsłużona należy dokonać zmiany w module,
którego uwaga dotyczy. Wysyła więc do polecenie dokonania odpowiedniej zmiany do programisty.
10
Programista po wykonaniu zmiany przesyła moduł do testowania. Osoba testująca oczywiście musi
mieć wgląd w treść uwagi oraz historię z nią związaną. Wiedząc zatem jaka funkcjonalność ma być
otrzymana na skutek zmiany modułu stwierdza, że programista nie spełnił wszystkich wymagań zawartych w
uwadze lub poleceniu kierownika technicznego. Odsyła zatem uwagę z dołączonym swoim komentarzem na
temat tego, co nie zostało wykonane lub zostało wykonane niewłaściwie. Programista poprawia moduł po raz
drugi i odsyła testerowi. Tester sprawdza moduł i akceptuje wykonaną zmianę. Przesyła informacje do
kierownika technicznego. Kierownik techniczny ma możliwość wglądu w poprawiony moduł, ale może się
oprzeć również na opinii osoby testującej (np. w przypadku, kiedy zmian jest bardzo dużo). Kierownik
techniczny odsyła poprawiony moduł do klienta oraz informuje go w postaci protokołu do uwag o tym czy
uwaga została uwzględniona, czy odrzucona lub też ewentualnie w jaki sposób została uwzględniona, jeżeli
sama treść uwagi tego nie precyzuje.
Tak może wyglądać obsługa uwagi zgłoszonej przez klienta. Oczywiście moduł nie jest fizycznie
przesyłany pomiędzy aktorami scenariusza. Klient nie musi wysyłać modułu co do którego uwagę zgłasza,
gdyż powinna być zapewniona identyczność pomiędzy produktami przekazanymi klientowi i zawartością
repozytorium modułów u wykonawcy. Wystarczy zatem, gdy prześle jednoznaczny identyfikator modułu.
Dalsze operacje na modułach takie jak dokonywanie zmiany, testowanie itp. mogą odbywać się na module
udostępnionym na dysku sieciowym wszystkim członkom zespołu projektowego. Należy tylko pamiętać, aby
numer wersji modułu po dokonaniu zmiany został odpowiednio zwiększony. Konieczne jest natomiast
wysłanie modułu poprawionego do klienta wraz z protokołem do uwag.
Trzeba zaznaczyć, że istnieją sytuacje kiedy kierownik techniczny ma problem w sklasyfikowaniu
uwagi. Wtedy potrzebuje on konsultacji z programistą, kierownikiem administracyjnym lub samym klientem.
Niektóre etapy procedury obsługi uwagi wymagają nawet rozwiązania problemów na szerokim forum,
zwołuje się wtedy zebranie w celu przedyskutowania możliwości uwzględnienia danej uwagi. W naszym
przykładzie opisaliśmy scenariusz obsługi uwagi prostej do sklasyfikowania.
11
6. Architektura systemu
„Nie rób nic na siłę, weź większy młotek”
prawo siły Anthony'ego
Po
ustaleniu
orientacyjnego
schematu
przepływu informacji w środowisku projektowym
można
zastanowić
się
nad
rozwiązaniami
technicznymi oraz architekturą systemu, która
najlepiej
sprosta
przedstawionym
KLIENT
wcześniej
KLIENT
założeniom. Należy jednak pamiętać, że system
powinien działać w sieci rozległej, a więc
najlepszym
rozwiązaniem
jest
KLIENT
zastosowanie
INTERNET
architektury przystosowanej do Internetu, czyli
trójwarstwowej. Zatem nasz system składałby się
na pewno z serwera bazy danych przechowującego
wszystkie
informacje
członkami
zespołu
przekazywane
projektowego
pomiędzy
oraz
inne
informacje potrzebne mu do funkcjonowania.
SERWER APLIKACJI
Kolejna warstwa to serwer aplikacyjny, na przykład
serwer internetowy HTTP. Po stronie klienta
najlepszym
rozwiązaniem
jest
zastosowanie
przeglądarki internetowej. Architekturę takiego
SERWER
BAZY
DANYCH
systemu przedstawia schemat na Rys 9.
Rys 9: Architektura trójwarstwowa
Nie jest naszym zamiarem podanie konkretnej technologii, czy produktu z użyciem których system taki
należy wykonać. Natomiast istotną uwagą jest wybór Internetu, jako platformy rozwojowej, która pozwala na
swobodny dostęp do systemu. Kolejnym etapem byłoby opracowanie interfejsu dla poszczególnych
użytkowników takiego systemu.
7. Podsumowanie
„Nic nie wygląda z bliska tak dobrze, jak wyglądało z daleka”
prawo obserwacji
Reasumując, rozważania nasze pozwoliły określić schemat przepływu informacji (m.in. uwag) w
modelowym środowisku projektowym oraz określić architekturę informatyczną, która najbardziej pasuje do
założeń systemu działającego w rozproszonym zespole projektowym. Wyniki tych rozważań mogą stanowić
12
początek dokumentacji projektowej sporządzonej na potrzeby wykonania takiego systemu. Nie sposób
wyliczyć korzyści zastosowania takiego systemu w praktyce:
•
zbieranie uwag od klienta jest realizowane w sposób automatyczny (oszczędność czasu),
•
uwagi klienta są od razu pozyskiwane w formie zgodnej z pewnym standardem (nie trzeba ich
przetwarzać),
•
uwagi są przechowywane centralnie i w każdym momencie można na ich temat wygenerować
raport (ściślejsza kontrola zmian i trafniejsze podejmowanie decyzji przez kierowników
projektów),
•
system odciąża programistów i testerów od konieczności śledzenia, które uwagi ich dotyczą, a
które nie, gdyż odpowiednia uwaga dociera do wyznaczonej osoby automatycznie.
Trzeba zaznaczyć, że opisany powyższymi założeniami system może być łatwo zastosowany do
kontroli zmian na poziomie specyfikacji wymagań użytkownika po zastąpieniu na schemacie (Rys 7)
programistów przez analityków lub inżynierów wymagań.
Mam nadzieję, że informacje zawarte w referacie będą zachętą do myślenia na temat zagadnień kontroli
zmian i zarządzania uwagami w firmach, które jeszcze nie wdrożyły żadnych metod związanych z tym
zagadnieniem, natomiast w tych firmach, które już pewne metody stosują będzie on głosem polemicznym.
Referencje
[1] Prezentacja do referatu: http://multimedserver.itti.com.pl/oracle/ploug99/prezAA.ppt,
[2] Roger S. Pressman, “Software Engineering, A Practitioner's Approach”, McGraw-Hill Companies, Inc.,
1997
[3] ANSI/IEEE Std. No. 828-1998 “IEEE Standard for Software Configuration Management Plans”,
[4] ANSI/IEEE Std. No. 1042-1987 “IEEE Guide to Software Configuration Management (ANSI)”,
[5] ANSI/IEEE Std. No. 1028-1997 “IEEE Standard for Software Reviews”
[6] TickIt Program, “A Guide to Software Quality System Construction and Certification using ISO
9001:1994”, British Standards Institution, 1998 (http://www.tickit.org)
13