Narzędzie do rejestracji zmian i problemów w projekcie

Komentarze

Transkrypt

Narzędzie do rejestracji zmian i problemów w projekcie
Politechnika Gdańska
Wydział Elektroniki,
Telekomunikacji i
Informatyki
Katedra InŜynierii Oprogramowania
Rodzaj studiów:
Kierunek:
Specjalność:
Magisterskie
Informatyka
InŜynieria Systemów i Baz Danych
Dyplomant:
Nr albumu:
Marcin Kałkus
88967/ETI
PRACA DYPLOMOWA
Promotor pracy:
dr inŜ. Stanisław Szejko
Narzędzie do rejestracji zmian i problemów w projekcie
informatycznym
Streszczenie:
Głównym celem pracy było zaproponowanie wzorca procesu zarządzania problemami
w projektach informatycznych i jego praktyczna implementacja w postaci narzędzia
wspomagającego ten proces. W ramach pracy zdefiniowano pojęcia związane z procesem,
zidentyfikowano źródła problemów oraz przeanalizowano ich cykl Ŝycia. W wyniku
analizy powstał model problemu, który posłuŜył jako wzorzec przy konstrukcji narzędzia.
Zarządzanie problemami zostało takŜe opisane w szerszym kontekście jako element
składowy procesu zarządzania konfiguracją oraz zaprezentowano wybrane rozwiązania
i narzędzia obecnie dostępne na rynku. W ramach pracy powstał rozproszony system
wspomagający wybrane aspekty zarządzania problemami, który wspiera pracę grupową
i nie wymaga centralnego pojemnika danych. Aplikacja BAGGU została wytworzona
w technologii Microsoft .NET, integruje się z wybranymi narzędziami do kontroli wersji
oraz wykorzystuje pliki XML do implementacji warstwy danych.
Gdańsk 2006
Podziękowania:
Chciałbym podziękować Promotorowi
za owocną współpracę i ogromną pomoc,
oraz Bliskim za wsparcie.
2
Spis treści
1.
2.
Wstęp ...................................................................................................................................................... 6
1.1
Wprowadzenie ................................................................................................................................ 6
1.2
Zawartość pracy ............................................................................................................................. 8
Źródła problemów w projekcie informatycznym.............................................................................. 11
2.1
Wprowadzenie .............................................................................................................................. 11
2.2
Rodzaje problemów ...................................................................................................................... 13
2.3
Defekty.......................................................................................................................................... 14
2.3.1
Terminologia ........................................................................................................................... 14
2.3.2
Przyczyny powstawania defektów........................................................................................... 17
2.3.3
Rodzaje defektów .................................................................................................................... 18
2.3.4
Metody ograniczania wpływu defektów.................................................................................. 24
2.3.5
Postępowanie z defektami ....................................................................................................... 26
2.4
Zmiany.......................................................................................................................................... 26
2.4.1
Źródła zmian............................................................................................................................ 28
2.4.2
Rodzaje zmian ......................................................................................................................... 29
2.4.3
Wpływ zmian na projekt.......................................................................................................... 31
2.4.4
Proces zarządzania zmianami .................................................................................................. 32
2.5
3.
Koszty defektów i zmian ............................................................................................................... 33
Cykl Ŝycia problemu w projekcie informatycznym .......................................................................... 35
3.1
Wprowadzenie .............................................................................................................................. 35
3.2
Cykl Ŝycie problemu ..................................................................................................................... 35
3.2.1
Zgłoszenie problemu ............................................................................................................... 36
3.2.2
Obsługa problemu.................................................................................................................... 39
3.2.3
Rozwiązanie problemu ............................................................................................................ 44
3.3
Diagram stanu problemu.............................................................................................................. 45
3.3.1
MoŜliwe stany problemu ......................................................................................................... 46
3.3.2
MoŜliwe rozwiązania problemu .............................................................................................. 51
4.
3.4
Role w procesie obsługi problemów............................................................................................. 54
3.5
Podsumowanie ............................................................................................................................. 56
Model problemu ................................................................................................................................... 57
4.1
Wprowadzenie .............................................................................................................................. 57
4.2
Scenariusz zgłaszania problemu................................................................................................... 57
4.3
Podstawowe atrybuty problemu ................................................................................................... 59
4.3.1
Identyfikator problemu ............................................................................................................ 61
4.3.2
Ogólny opis problemu ............................................................................................................. 62
4.3.3
Metryka problemu ................................................................................................................... 62
4.3.4
Szczegółowy opis problemu .................................................................................................... 62
4.3.5
Priorytet problemu................................................................................................................... 64
4.3.6
Stan problemu.......................................................................................................................... 66
4.3.7
Przydział odpowiedzialności ................................................................................................... 67
4.4
Historia problemu ........................................................................................................................ 67
4.4.1
Modyfikacje atrybutów............................................................................................................ 67
3
4.4.2
4.4.3
Rozszerzenia opisu problemu .................................................................................................. 67
Uwagi i komentarze................................................................................................................. 68
4.5
Dodatkowe informacje o problemie ............................................................................................. 68
4.5.1
Identyfikator produktu ............................................................................................................. 69
4.5.2
Wersja produktu ...................................................................................................................... 69
4.5.3
Słowa kluczowe....................................................................................................................... 69
4.5.4
Dokuczliwość problemu .......................................................................................................... 70
4.5.5
Charakter problemu ................................................................................................................. 71
4.5.6
Powtarzalność.......................................................................................................................... 71
4.5.7
Widzialność ............................................................................................................................. 72
4.5.8
Składnik produktu.................................................................................................................... 72
4.5.9
Załączniki ................................................................................................................................ 73
4.5.10
Pole duplikatu ..................................................................................................................... 74
4.6
Model problemu ........................................................................................................................... 74
4.7
Dynamika modelu problemu......................................................................................................... 78
4.7.1
Diagram aktywności procesu obsługi problemu...................................................................... 78
4.7.2
Diagram stanów problemu....................................................................................................... 79
4.8
5.
Podsumowanie ............................................................................................................................. 79
Zarządzanie problemami w projekcie informatycznym................................................................... 80
5.1
Wprowadzenie .............................................................................................................................. 80
5.2
Ogólny opis procesu..................................................................................................................... 80
5.3
Konfiguracja projektu .................................................................................................................. 82
5.4
Zarządzanie konfiguracją............................................................................................................. 82
5.4.1
Zarządzanie konfiguracją systemu........................................................................................... 83
5.4.2
Zarządzanie problemami ......................................................................................................... 84
5.4.3
Śledzenie postępu prac ............................................................................................................ 84
5.5
Aspekty zarządzania konfiguracją ................................................................................................ 85
5.5.1
Zarządzanie wymaganiami ...................................................................................................... 85
5.5.2
Zarządzanie incydentem .......................................................................................................... 86
5.5.3
Zarządzanie problemem........................................................................................................... 87
5.5.4
Zarządzanie wersją .................................................................................................................. 89
5.6
Zarządzanie konfiguracją w najpopularniejszych metodykach .................................................... 90
5.6.1
Rational Unified Process ......................................................................................................... 90
5.6.2
PRINCE2................................................................................................................................. 92
6.
5.7
Proces zarządzania konfiguracją w kontekście ............................................................................ 94
5.8
Podsumowanie ............................................................................................................................. 95
Przegląd rozwiązań dostępnych na rynku ......................................................................................... 96
6.1
Wprowadzenie .............................................................................................................................. 96
6.2
Narzędzia do ewidencji i śledzenia problemów............................................................................ 96
6.2.1
Model narzędzia ...................................................................................................................... 98
6.2.2
Przykładowe narzędzia .......................................................................................................... 101
6.3
Narzędzia do kontroli wersji ...................................................................................................... 106
6.3.1
Model narzędzia .................................................................................................................... 106
6.3.2
Przykładowe narzędzia .......................................................................................................... 109
6.3.3
Zestawienie cech.................................................................................................................... 112
6.4
7.
Podsumowanie ........................................................................................................................... 113
Narzędzie wspomagające proces zarządzania problemami ........................................................... 115
4
7.1
Wprowadzenie ............................................................................................................................ 115
7.2
Specyfikacja wymagań ............................................................................................................... 116
7.2.1
Cele biznesowe ...................................................................................................................... 117
7.2.2
Zakres problemu .................................................................................................................... 117
7.2.3
Udziałowcy............................................................................................................................ 118
7.2.4
Zdarzenia biznesowe i biznesowe przypadki uŜycia ............................................................. 120
7.2.5
Wymagania wobec systemu .................................................................................................. 120
7.3
Analiza wymagań i ograniczeń oraz dyskusja rozwiązań........................................................... 122
7.3.1
Bezpieczeństwo ..................................................................................................................... 122
7.3.2
Warstwa danych .................................................................................................................... 126
7.4
Model logiczny systemu.............................................................................................................. 127
7.4.1
Wizja architektoniczna .......................................................................................................... 128
7.4.2
Zakres systemu ...................................................................................................................... 130
7.4.3
Aktorzy i przypadki uŜycia.................................................................................................... 130
7.5
Projekt narzędzia........................................................................................................................ 132
7.5.1
Decyzje projektowe ............................................................................................................... 132
7.5.2
Technologia ........................................................................................................................... 132
7.5.3
Środowisko wytwórcze.......................................................................................................... 132
7.5.4
Środowisko docelowe............................................................................................................ 133
7.5.5
Projekt systemu i klas ............................................................................................................ 133
7.5.6
Dynamika systemu ................................................................................................................ 140
7.5.7
Projekt warstwy danych......................................................................................................... 141
7.5.8
Projekt interfejsu uŜytkownika .............................................................................................. 142
7.6
Opis implementacji..................................................................................................................... 144
7.6.1
Instalacja narzędzia................................................................................................................ 144
7.6.2
Usuwanie narzędzia............................................................................................................... 145
7.6.3
Pierwsze uruchomienie aplikacji ........................................................................................... 145
7.6.4
Tworzenie nowego projektu .................................................................................................. 146
7.6.5
Dołączanie do istniejącego projektu ...................................................................................... 148
7.6.6
Rezygnacja z uczestnictwa w projekcie................................................................................. 149
7.6.7
Ustalanie ról w obrębie projektu............................................................................................ 149
7.6.8
Przeglądanie listy problemów................................................................................................ 150
7.6.9
Rejestracja problemów .......................................................................................................... 151
7.6.10
Podgląd problemów .......................................................................................................... 152
7.7
Testowanie narzędzia ................................................................................................................. 154
7.7.1
Testy funkcjonalne ................................................................................................................ 155
7.7.2
Testy akceptacyjne ................................................................................................................ 156
7.7.3
Wyniki ................................................................................................................................... 158
7.8
Wnioski ....................................................................................................................................... 158
8.
Podsumowanie.................................................................................................................................... 160
9.
Bibliografia ......................................................................................................................................... 163
9.1
KsiąŜki ........................................................................................................................................ 163
9.2
Artykuły ...................................................................................................................................... 163
9.3
Materiały wykładowe ................................................................................................................. 163
9.4
Strony Web ................................................................................................................................. 164
9.5
Dokumentacja techniczna........................................................................................................... 164
9.6
Załączniki ................................................................................................................................... 164
5
1.
Wstęp
„Intellectuals solve problems, geniuses prevent them”
Albert Einstein
1.1
Wprowadzenie
W obecnych czasach obserwuje się gwałtowny wzrost rozmiarów i stopnia
złoŜoności wytwarzanego oprogramowania. Projekty informatyczne, bez względu na
segment rynku, w którym operują, stają się coraz bardziej skomplikowane, pochłaniają
ogromne budŜety i trwają coraz dłuŜej. Z drugiej strony nie mniejszym zmianom podlega
rynek odbiorców oprogramowania, w którym klienci systemów informatycznych stają się
coraz bardziej świadomi swoich potrzeb i stawiają przed dostarczanymi im produktami
coraz wyŜsze wymagania zarówno pod względem funkcjonalności jak i jakości.
Rezultatem tych wszystkich zjawisk zachodzących na rynku informatycznym jest wzrost
złoŜoności procesów zarządzania przedsięwzięciami wytwarzania oprogramowania.
InŜynieria oprogramowania przeistoczyła się w dyscyplinę wymagającą współdziałanie
zespołów złoŜonych niekiedy z bardzo wielu osób.
Nowoczesne projekty informatyczne bezwzględnie wymagają efektywnej i dobrze
skoordynowanej współpracy zespołu specjalistów, zarówno w kwestii konstrukcji
oprogramowania jak równieŜ zarządzania samym przedsięwzięciem. Zarządzanie
projektem informatycznym to niezwykle złoŜona dziedzina wiedzy, łącząca w sobie
zagadnienia z zarządzania zasobami ludzkimi, organizacji i planowania, szacowania
zasobów, przydzielania odpowiedzialności itp. Jak kaŜde inne przedsięwzięcie, moŜe ono
napotkać na wiele problemów w trakcie swojego trwania. Radzenie sobie z tymi
przeciwnościami jest jednym z kluczowych aspektów zarządzania współczesnym
projektem informatycznym.
Niniejsza praca dyplomowa jest poświęcona w głównej mierze procesowi
zarządzania problemami w projektach informatycznych. Jest to niezwykle waŜny element
współczesnego procesu wytwórczego, który wdroŜony w sposób właściwy, w wielkim
stopniu ułatwia i usprawnia pracę całego zespołu, co w konsekwencji prowadzi do
powstawania oprogramowania lepszej jakości. Jak wiadomo w kaŜdej fazie projektu
informatycznego pojawiają się problemy zgłaszane zarówno przez odbiorcę produktu jak
6
równieŜ samych jego twórców. Efektywne gromadzenie i zarządzanie tego typu danymi
juŜ w niewielkich projektach moŜe być zadaniem nietrywialnym.
Rozwiązanie tak skomplikowanego zagadnienia przy rozmiarach współczesnych
projektów niewątpliwie wymaga wsparcia narzędziowego. Dostępne na rynku rozwiązania
bazują na centralnie umieszczonej bazie danych problemów, do której dostęp uzyskuje się
przez interfejs WWW albo dedykowane oprogramowanie klienckie. Narzędzia tego typu
sprawdzają się jedynie w wypadku duŜych zespołów projektowych. W dobie Internetu
oprogramowanie często tworzone jest przez mniejsze zespoły pracujące w warunkach
rozproszonych przy braku dostępu do centralnej infrastruktury technicznej. Konieczne
staje się znalezienie alternatywy dla wyŜej wymienionych rozwiązań, która oferowałaby
podobne moŜliwości przy jednoczesnej rezygnacji z centralnego pojemnika danych na
rzecz lokalnie przechowywanych kopii danych i mechanizmów ich synchronizacji przy
pomocy ogólnodostępnego medium, np. poczty elektronicznej. Stąd inspiracja do napisania
pracy, która oprócz solidnej podstawy teoretycznej, stanowiłaby praktyczne wykorzystanie
wiedzy z tego zakresu w postaci dedykowanego narzędzia ukierunkowanego na spełnienie
wyŜej opisanych wymagań.
Zasadniczym
celem
pracy
jest
zatem
opracowanie
prototypu
narzędzia
wspomagającego zarządzanie problemami w projekcie informatycznym, które wspiera
pracę grupową, ale nie wymaga centralnego serwera do przechowywania bazy danych
o problemach. Aby cel ten osiągnąć konieczne było takŜe przeprowadzenie analizy całego
procesu zarządzania problemami od momentu ujawnienia, poprzez ich rejestrację, obsługę
i ostateczne rozwiązanie. Celem teoretycznej części pracy jest analiza procesu zbierania,
zarządzania i radzenia sobie z problemami w projektach informatycznych. Pierwsza część
pracy stanowi syntezę wiedzy ksiąŜkowej oraz praktycznej na ten temat. Bezpośrednim
wynikiem analizy jest opis cyklu Ŝycia problemu oraz jego bardziej formalny model. Stąd
drugim celem pracy i zarazem przykładem zastosowania opracowanego modelu problemu
był prototyp narzędzia opracowywany w ramach części praktycznej pracy dyplomowej.
Powstałe oprogramowanie w załoŜeniu miało posiadać niezbędny zakres funkcjonalności
umoŜliwiający sprawne zarządzanie problemami w rozproszonym projekcie. Funkcjonalna
kompletność, zgodność z dobrze opracowany modelem problemu, wspieranie pracy
grupowej, integracja z narzędziami do wersjonowania kodu oraz niezaleŜność od
centralnego pojemnika danych to główne upatrywane zalety narzędzia, które miało
7
powstać. Główną motywacją do jego opracowania było i nadal pozostaje przeświadczenie
o tym, Ŝe powstały system będzie mógł być wykorzystany w przyszłych projektach,
zarówno tych prowadzonych na uczelni jak i komercyjnych. Zamykający część teoretyczną
przegląd rynku pod kątem oprogramowania wspomagającego proces zarządzania
problemami moŜe być takŜe przydatny przy selekcji narzędzi w rzeczywistych projektach.
1.2
Zawartość pracy
Jak wspomniano wyŜej praca zasadniczo dzieli się na dwie części. W rozdziałach
2-6 znajduje się teoretyczne wprowadzenie do tematyki zarządzania problemami
w projektach informatycznych. Celem pierwszej części dyplomu jest usystematyzowanie
wiedzy na temat tego procesu oraz stworzenie modelu słuŜącego do budowy narzędzia.
Reszta pracy koncentruje się na jej praktycznej części i zawiera kompletny opis procesu
analizy, projektowania oraz implementacji aplikacji.
Praca rozpoczyna się rozdziałem pod tytułem „Źródła problemów w projekcie
informatycznym”, który stanowi niejako wprowadzenie do poruszanej tematyki.
W rozdziale tym pojawiają się definicje defektu i zmiany oraz wprowadzana jest
klasyfikacja problemów i ich potencjalnych źródeł. Głównym celem tej części pracy było
wyodrębnienie rodzajów problemów i sklasyfikowanie ich zarówno pod względem
pochodzenia, wagi, czasu występowania, jak równieŜ ich kosztu i wpływu na proces
wytwórczy. Zaprezentowana terminologia i klasyfikacja problemów posłuŜyła jako
odniesienie przy budowie formalnego opisu problemu w dalszej części pracy. Jednocześnie
uznanie problemu jako pojęcie nadrzędne w stosunku do defektu i zmiany przyczyniło się
do powstania niekonsekwencji tytułu dyplomu w odniesieniu do zaproponowanej
terminologii. Treść pracy odzwierciedla jednak przyjęty w Rozdziale 2 podział problemów
na defekty i zmiany, a pozostawienie tytułu w pierwotnej postaci było podyktowane
głównie wymogami formalnymi.
W kolejnym rozdziale zatytułowanym „Cykl Ŝycia problemu w projekcie
informatycznym” znajduje się kompletny opis cyklu Ŝycia problemu w projekcie
informatycznym począwszy od zgłoszenia, poprzez jego przepływ przez organizację i na
ostatecznym rozwiązaniu kończąc. Zasadniczym celem rozdziału jest opisanie sposobu
przepływu informacji na temat problemu w firmie wytwarzającej oprogramowanie, ze
szczególnym uwzględnieniem ról i odpowiedzialności poszczególnych członków zespołu
8
projektowego. Przeprowadzenie dynamicznej analizy problemu było konieczne przed
przystąpieniem do budowy formalnego modelu problemu.
Rozdział „Model problemu” stanowi jeden z najistotniejszych punktów pracy. Na
bazie analizy przeprowadzonej w poprzednich dwóch rozdziałach został stworzony
abstrakcyjny model problemu oraz jego zachowania. W rozdziale tym zaproponowałem
formalny opis struktury problemu, obejmujący wszystkie jego najwaŜniejsze aspekty, wraz
z niezbędnymi atrybutami koniecznymi do jego skutecznego śledzenia, zarządzania
i rozwiązywania. Efektem końcowym rozwaŜań jest kompletny model problemu wyraŜony
w języku UML, który posłuŜył jako podstawa przy konstrukcji narzędzia w części
praktycznej pracy.
Kolejny
rozdział
zatytułowany
„Zarządzanie
problemami
w
projekcie
informatycznym” jest miejscem, w którym proces zarządzania problemami podlega
analizie w nieco szerszym kontekście. W rozdziale tym zaprezentowane są poszczególne
aspekty bardziej ogólnego procesu zwanego zarządzaniem konfiguracją. Rozdział zamyka
ogólny opis najpopularniejszych metodyk wytwarzania oprogramowania w kontekście
stosowanych w nich metod zarządzania zmianami i defektami.
Część teoretyczną pracy zamyka rozdział zatytułowany „Przegląd rozwiązań
dostępnych na rynku”. Jest on całkowicie poświęcony przeglądowi technologii i narzędzi
dostępnych obecnie na rynku i obejmuje najpopularniejsze komercyjne i darmowe
narzędzia do wersjonowania kodu oraz do śledzenia zmian i defektów. Opis konkretnych
aplikacji poprzedzony jest ogólnym spojrzeniem na cechy, jakimi odznaczają się narzędzia
reprezentujące poszczególne segmenty tego rynku.
Dalsza część pracy w całości poświęcona została części praktycznej dyplomu.
Stanowi ona streszczenie i komentarz do dokumentów projektowych będących
załącznikami do pracy. Zawiera identyfikację wymagań nałoŜonych na aplikację wraz
z opisem dziedziny problemowej, udziałowców oraz biznesowych przypadków uŜycia
systemu. Dalsza część poświęcona jest aspektom projektowym i składa się z opisu
najciekawszych problemów i ich proponowanych rozwiązań. Końcowe efekty pracy nad
systemem przedstawione zostały w postaci opisu implementacji oraz wniosków z jego
testowego wdroŜenia. WdroŜenie to jest o tyle ciekawe, iŜ dotyczy samego projektu mojej
pracy dyplomowej, w którym to narzędzie było wykorzystywane od momentu uzyskania
przez nie niezbędnego minimum funkcjonalności.
9
Pracę ostatecznie zamyka „Podsumowanie”, którego głównym zadaniem jest
wyjaśnienie wszystkich ciekawych kwestii i trudności, jakie napotkałem w trakcie
zgłębiania wiedzy na temat zarządzania problemami w projekcie informatycznym oraz
konstrukcji narzędzia, które ma ten proces wspomagać.
W załącznikach pracy umieszczone zostały dokumenty projektowe powstałe
w trakcie realizacji systemu wspomagającego proces zarządzania problemami –
specyfikację wymagań systemowych oraz projekt systemu.
10
2.
Źródła problemów w projekcie informatycznym
„Life is about change whether good or bad, and being able to adjust accordingly”
Okechukwu Keke
2.1
Wprowadzenie
Projekt
informatyczny,
rozumiany
jako
zespół
skoordynowanych
zadań
prowadzących do realizacji wyznaczonego celu, moŜe dotyczyć kaŜdej dziedziny Ŝycia.
Wytwarzanie oprogramowania jest dziedziną nauki próbującą zamknąć w ramach definicji
pewne zjawiska zastane, występujące w świecie fizycznym, ale niedostatecznie
sformalizowane. Oprogramowanie jest przede wszystkim tworem myśli. Z jednej strony
jego twórcy nie są ograniczeni technicznymi aspektami procesu tworzenia, z drugiej
jednak strony są naraŜeni na błędy wynikające z faktu pracy tylko i wyłącznie z myślą
ludzką i jej zapisem formalnym. Ta nieograniczona swoboda tworzenia jest jednocześnie
źródłem największych problemów przy realizacji przedsięwzięć informatycznych.
Niniejszy rozdział zawiera opis źródeł problemów w projekcie informatycznym,
podejmuje próbę ich klasyfikacji zarówno pod względem pochodzenia, wagi jak równieŜ
czasu występowania.
W kontekście projektu informatycznego radzenie sobie z problemami stanowi jeden
z elementów składowych szerszego procesu zwanego zarządzaniem konfiguracją. Proces
ten w ogólności zajmuje się kontrolą wszystkich produktów projektu. Konfiguracja to
zbiór logicznie powiązanych produktów, które muszą być traktowane i zarządzane jako
złoŜona całość uwzględniająca zaleŜności pomiędzy wersjami części składowych i ich
statusami [wwwWIKI]. Wszelkie informacje na temat problemów pojawiających się
w trakcie projektu, bez względu na ich charakter i przyczyny powstawania, stanowią jeden
z wielu zasobów projektu i tym samym muszą podlegać sprawnemu procesowi rejestracji
i zarządzania. Obok problemów procesowi temu podlega szereg innych aspektów projektu.
PoniŜej znajduje się lista zarządzanych aspektów wraz z wyjaśnieniem ich znaczenia
w kontekście procesu zarządzania konfiguracją:
•
incydenty – niepoŜądane zdarzenia zaobserwowane podczas pracy systemu
•
problemy – zidentyfikowane, znane i opisane zagadnienia dotyczące projektu,
które uznane są jako zagroŜenia dla jego dalszego przebiegu, przyczyną problemów
mogą być defekty, a ich rozwiązaniem zmiany
11
•
defekty - niepoprawne konstrukcje znajdujące się w dowolnym elemencie systemu
informatycznego, które mogą prowadzić do niewłaściwego jego działania
•
zmiany – formalnie zgłoszone i udokumentowane modyfikacje wprowadzane do
pierwotnych załoŜeń i konstrukcji systemu, naleŜy tutaj wyraźnie zaznaczyć, Ŝe
prośba o zmianę (problem) nie jest toŜsama z jej fizycznym wprowadzeniem do
systemu (zmiana).
•
wersje – kolejne wydania systemu, zawierające jasno sprecyzowane wersje swoich
elementów składowych (komponentów, modułów, dokumentacji)
•
wymagania – niejawne oraz jawnie sprecyzowane i udokumentowane oczekiwania
odbiorcy systemu wobec mającego powstać oprogramowania [IEEE 1233]
Rysunek 2-1 przedstawia schemat zaleŜności pomiędzy wymienionymi elementami
oraz umieszcza je w odpowiednich obszarach procesu zarządzania konfiguracją. Jak widać
kaŜdemu kluczowemu aspektowi poświęcony jest oddzielny podproces. Jednym z tych
podprocesów jest zarządzanie problemami, które stanowi główny obiekt zainteresowań
w
ą
no
tw
or
zy
naprawa
wymaga
pr
m zyc
oŜ z
e yn
by ą
ć
niniejszej pracy dyplomowej.
Rysunek 2-1 Podprocesy zarządzania konfiguracji (źródło własne)
Warto w tym momencie zaznaczyć, Ŝe róŜnica pomiędzy prośbą o zmianę
(ang. change request) a faktyczną zmianą wprowadzoną do systemu (ang. change,
modification) powoduje, Ŝe ta pierwsza być moŜe powinna zostać umiejscowiona na styku
obszarów zarządzania problemami i zmianami. Jednocześnie, poniewaŜ praca koncentruje
się na obszarze zarządzania problemami, dla potrzeb przejrzystości dalszych rozwaŜań pod
pojęciem zmiany będzie rozumiana prośba o jej wprowadzenie (ang. change request).
12
Wszystkie opisane wyŜej aspekty zarządzania konfiguracją będą szerzej opisane
w Rozdziale 5 – „Zarządzanie problemami w projekcie informatycznym”. W dalszej części
tego rozdziału główny nacisk kładziony jest na opis rodzajów defektów oprogramowania
oraz przyczyn wprowadzania zmian do systemów informatycznych.
2.2
Rodzaje problemów
Projekt informatyczny jak kaŜde inne planowane i zarządzane przedsięwzięcie
moŜe napotkać na szereg róŜnego rodzaju problemów w trakcie swego trwania. Zakres
moŜliwości w tej materii jest praktycznie nieograniczony i moŜe obejmować problemy
natury czysto technicznej, organizacyjnej, a nawet psychologicznej. Ze względu na opisaną
róŜnorodność aspektów konieczne jest jasne określenie, jakiego rodzaju problemy będą
przedmiotem dalszej analizy.
Projektanci
oraz
programiści
popełniają
często
pomyłki
wynikające
z niepoprawnego pojmowania wymagań oraz ich realizacji. KaŜdy zaszyty w produkcie
defekt ma ogromny wpływ na koszt i postrzeganą jakość systemów informatycznych.
Drugą waŜną cechą kaŜdego przedsięwzięcia informatycznego jest jego płynność. Praktyka
pokazuje jak trudne jest formalne opisanie procesów zachodzących w świecie fizycznym.
Osiągnięcie w pełni kompletnego opisu dziedziny biznesowej systemu informatycznego za
pierwszym podejściem wydaje się wręcz niemoŜliwe. Tym samym kaŜdy projekt
informatyczny skazany jest na napotkanie zmian w trakcie procesu jego realizacji. Zmiany
mogą generować kolejne defekty, z kolei defekty obnaŜają potrzebę kolejnych zmian.
Wydaje się, Ŝe opisane wyŜej problemy stanowią główne zagroŜenie dla
powodzenia współczesnych projektów informatycznych. Defekty i zmiany mają wymiar
nie tylko techniczny, ale takŜe dotykają aspektów zarządzania i organizacji samego
projektu, a niejednokrotnie mają namacalny wpływ na cały proces wytwórczy
w organizacji. Taka złoŜoność obu rodzajów problemów wydaje się być wystarczającym
uzasadnieniem do ich dalszej analizy, co jest celem mojej pracy dyplomowej.
Przyjęcie jako przedmiot rozwaŜań właśnie defektów oraz zmian wiąŜe się nie
tylko z zawęŜeniem zakresu rozpatrywanych problemów, ale równieŜ definiuje obszar
samej analizy. Opisywane w dalszej części pracy problemy będą dotykały projektów
informatycznych oraz przede wszystkim wytwarzanych w ich trakcie produktów. Pod
pojęciem produktu zazwyczaj rozumie się system informatyczny, czyli oprogramowanie,
13
którego głównym zadaniem i zarazem sensem istnienia jest wspieranie konkretnych
procesów biznesowych odbiorcy. Pojęcia systemu oraz oprogramowania będą przeze mnie
uŜywane zamiennie, jednak zawszę będą oznaczały produkt stricte informatyczny,
z celowym pominięciem technicznych aspektów związanych np. z infrastrukturą sprzętową
środowiska, w jakim dany system funkcjonuje. Takie podejście pozwoli na
skoncentrowanie uwagi na problemach istotnych z punktu widzenia zarządzania cyklem
wytwórczym i jednoczesne odrzucenie zagadnień wynikających z fizycznych ograniczeń
i cech sprzętu. Warto zaznaczyć, Ŝe wytworami projektu informatycznego mogą być takŜe
inne artefakty i składniki powstające w trakcie jego trwania takie jak dokumenty
projektowe czy inne produkty i półprodukty kolejnych faz cyklu wytwórczego. Problem
defektów oraz zmian dotyka nie tylko wynikowego systemu informatycznego, ale takŜe
wszystkich innych rezultatów pracy zespołu projektowego, dlatego teŜ pojęcie produktu
naleŜy zawsze rozpatrywać w nieco szerszym kontekście i nie zawęŜać go jedynie do
docelowego systemu.
2.3
Defekty
Defekty są niestety nieodłącznym elementem oprogramowania komputerowego
i wydają się nieuniknione. Ich efektywne eliminowanie leŜy w interesie zarówno
uŜytkowników, jak i producentów aplikacji. Stosuje się rozmaite techniki wykrywania
i eliminowania defektów oraz wprowadza się nowe metodologie, które mają na celu
zmniejszanie
prawdopodobieństwa
popełnienia
błędu
w
procesie
wytwórczym.
Największym problemem inŜynierii oprogramowania pozostaje fakt, iŜ róŜnego rodzaju
metody, z testowaniem na czele, mogą wykazać jedynie istnienie defektów, nigdy zaś ich
brak.
2.3.1
Terminologia
Najprostsza
definicja
defektu
mówi
o
niepoprawnej
konstrukcji
w oprogramowaniu, która moŜe doprowadzić do niewłaściwego jego działania.
Konsekwencją defektu jest błędne wykonanie programu. Jest to jednak definicja bardzo
wąska, która nie obejmuje całości procesów zachodzących w cyklu wytwórczym
oprogramowania. Pojęcie defektu jest często niesłusznie uŜywane zamiennie z innymi
pojęciami typu błąd czy awaria. PoniŜej przytaczam definicje tych pojęć powiązanych
z tematyką niezawodności i bezpieczeństwa systemów informatycznych [GORBZI2005]:
14
•
Awaria (ang. failure) – awaria występuje w momencie, gdy efekty działania
systemu odbiegają od tych zdefiniowanych w jego specyfikacji i oprogramowanie
przestaje realizować usługi oczekiwane przez uŜytkowników.
•
Błąd (ang. error) – błąd to fragment lub stan systemu, który moŜe prowadzić do
powstania awarii, innymi słowy awarie występują, dlatego Ŝe oprogramowanie jest
błędne (ang. erroneous). Błąd jest niepoprawnym stanem systemu, którego nie
spodziewali się jego projektanci.
•
Defekt (ang. fault) – przyczyną błędu jest defekt (sprzętu lub oprogramowania),
zaszyty na stałe lub chwilowo w systemie. Defekt jest zatem niepoprawną
konstrukcją znajdującą się w oprogramowaniu, która moŜe
prowadzić do
niewłaściwego jego działania, czyli wystąpienia błędu.
•
Pomyłka (ang. mistake) – pomyłka jest przyczyną powstania defektu, z kolei
źródłem pomyłek jest człowiek.
Stosując wyŜej zdefiniowane pojęcia moŜna precyzyjnie prześledzić proces
powstawania negatywnych skutków defektów oprogramowania. Przykładowy scenariusz
moŜe wyglądać następująco:
•
twórcy oprogramowania zdarza się pomyłka w trakcie konstrukcji systemu
•
pomyłka powoduje wprowadzenie defektu do oprogramowania
•
defekt staje się przyczyną błędu
•
aktywacja błędu w trakcie działania systemu prowadzi do jego awarii
Proces ten został schematycznie przedstawiony na Rysunku 2-2. Jak widać pomyłki
i wynikające z nich defekty powstają zasadniczo na etapie wytwarzania systemu
informatycznego, podczas gdy ich aktywacja w postaci błędów i awarii następuje juŜ
w trakcie jego działania. Warto zaznaczyć, Ŝe przyczyną zaszycia defektu w kodzie
oprogramowania jest zazwyczaj pomyłka człowieka – programisty, który źle
zaimplementuje daną funkcjonalność lub analityka, który dostarczy nieprawidłowy projekt
lub specyfikację systemu.
15
Rysunek 2-2 Defekt jako źródło awarii systemu (źródło własne)
Z punktu widzenia procesu zarządzania problemami w projekcie informatycznym
najwaŜniejszym pojęciem jest oczywiście defekt, gdyŜ jest on z załoŜenia przyczyną
pojawiającego się problemu. Awaria i prowadzący do niej błąd stanowią jedynie
konsekwencje zaistnienia defektu w oprogramowaniu. Kolejną bardzo waŜną cechą
wszelkich defektów oprogramowania jest to, Ŝe są one w nim zaszyte od samego początku
i nigdy nie powstają samoistnie w wyniku fizycznego zuŜycia produktu [GORBZI2005].
Terminologia związana z defektami i ich skutkami nie jest do końca
uporządkowana. Oprócz wyŜej opisanych definicji występuje duŜa liczba określeń
i zwrotów, które często mają podobne lub wręcz identyczne znaczenia, jednak sposób ich
interpretacji i wzajemnej hierarchii bywa odmienny w zaleŜności od stosującej
je organizacji. Bardzo powszechnym tego przykładem jest utoŜsamianie błędu z defektem
i stosowanie tych pojęć zamiennie. Błąd często promowany jest takŜe do pojęcia
nadrzędnego, które zbiorowo obejmuje zarówno defekty jak i awarie. Kolejnym często
spotykanym pojęciem są tak zwane anomalie, które zwykle oznaczają klasę błędów, które
samodzielnie nie powodują awarii, niemniej jednak mogą doprowadzić do awarii
pośrednio. W tym sensie anomalia jest odchyleniem stanu systemu od normalnej pracy, co
niekoniecznie musi być przyczyną jego nieprawidłowego działania. Bardzo powszechnym
określeniem, zwłaszcza wśród programistów, jest pojęcie „pluskwy” (ang. bug), które
najczęściej oznacza wadę występującą bezpośrednio w kodzie źródłowym, co oznacza, iŜ
jest to defekt implementacji. W praktyce znacznie częściej spotyka się anglojęzyczny
odpowiednik tego pojęcia, gdyŜ słowo „pluskwa” zasadniczo nie przyjęło się w polskiej
16
terminologii [WISZ2006]. Podobnym potocznym określeniem, które zyskało popularność
takŜe wśród uŜytkowników, jest tak zwane zawieszenie się lub załamanie (ang. crash).
Formalnie moŜna to pojęcie traktować jako szczególny typ awarii, przy której system
całkowicie przestaje funkcjonować.
Taka wieloznaczność i mnogość terminologii związanej z tematyką defektów moŜe
utrudniać tworzenie jednoznacznego i precyzyjnego opisu zachowania problemów
w projekcie informatycznym. Na potrzeby mojej pracy dyplomowej postaram się
rygorystycznie trzymać pierwotnie zaprezentowanej i popartej przykładem hierarchii pojęć
zawierającej defekt, błąd oraz awarię.
2.3.2
Przyczyny powstawania defektów
Aby skutecznie gromadzić informacje na temat defektów oprogramowania, naleŜy
w pierwszej kolejności zrozumieć powody ich powstawania. Najogólniej rzecz ujmując
przyczyną
wszelkiego
rodzaju
defektów
i
uchybień
w
procesie
wytwarzania
oprogramowania są pomyłki w tłumaczeniu informacji. Proces budowy oprogramowania,
bez względu na przyjęty cykl wytwórczy, moŜna bowiem opisać jako zdefiniowany ciąg
czynności poczynając od sformułowania problemu, poprzez jego analizę, projekt i kończąc
na szczegółowej implementacji rozwiązującej dane zagadnienie. Budowa oprogramowania
jest, więc dokonaniem pewnej liczby przekładów informacji, tłumaczących kolejne
postacie problemu na róŜne rozwiązania pośrednie, aŜ do otrzymania szczegółowego ciągu
rozkazów
maszynowych.
Defekty
oprogramowania
powstają
właśnie
wtedy,
gdy tłumaczenie jednej reprezentacji zadania na inną, bardziej szczegółową, jest niewierne
lub niedokładne.
Warto zaznaczyć, Ŝe zarówno sam proces wytwarzania oprogramowania jak i jego
końcowe produkty są na tyle specyficzne, Ŝe nie podlegają regułom tradycyjnie rozumianej
inŜynierii. NajwaŜniejszą cechą odróŜniającą oprogramowanie od innych produktów jest
fakt, iŜ jego niezawodność nie ulega pogorszeniu na skutek eksploatacji. Krzywa
awaryjności produktów informatycznych została zaprezentowana na Rysunku 2-3.
17
INTENSYWNOŚĆ
AWARII SYSTEMU
(ang. failure rate)
BŁĄD
KRZYWA
RZECZYWISTA
KRZYWA
IDEALNA
CZAS
Rysunek 2-3 Krzywa awaryjności oprogramowania (R.Pressman, 2003)
W odróŜnieniu od np. sprzętu, oprogramowanie nie „starzeje się” i nie jest podatne
na awarie spowodowane stopniowym zuŜyciem się jego elementów składowych.
Wydawałoby się, Ŝe oprogramowanie, na skutek ciągłego wykrywania i usuwania
defektów, staje się bardziej niezawodne, im dłuŜej jest eksploatowane, co pokazuje krzywa
idealna na wykresie. Niestety praktyka pokazuje, iŜ wszelkie zmiany i poprawki
wprowadzane do oprogramowania w trakcie jego cyklu Ŝycia przyczyniają się takŜe do
gwałtownego wzrostu awaryjności, poprzez wprowadzanie do produktu nowych defektów
w miejsce tych naprawianych. NaleŜy mieć ten specyficzny fakt na uwadze przy analizie
przyczyn powstawania defektów w oprogramowaniu.
2.3.3
Rodzaje defektów
Defekty występujące w systemach informatycznych moŜna klasyfikować na róŜne
sposoby - pod względem momentu ich występowania w cyklu wytwarzania, uciąŜliwości,
priorytetu rozwiązania, wpływu na działanie systemu oraz szeregu innych cech. PoniŜej
znajduje się charakterystyka najczęściej stosowanych podziałów.
Pod pojęciem klasyczny cykl Ŝycia systemu rozumie się całość działań
prowadzonych od ujawnienia potrzeby budowy systemu, poprzez analizę stawianych
wymagań, projektowanie i implementację oprogramowania, testowanie, jego pielęgnację,
do zakończenia wykorzystania oprogramowania [SZEJIW2003]. Wszystkie znane
i stosowane obecnie standardy wytwarzania oprogramowania czerpią załoŜenia z tej
definicji. Na kaŜdym etapie rozwoju oprogramowania pojawiają się róŜnego rodzaju
18
defekty. Przyjmując przytaczany model klasyczny jako odniesienie moŜna zatem wyróŜnić
następujące klasy defektów, jakie pojawiają się w trakcie wytwarzania oprogramowania:
•
defekty produktów i półproduktów
o fazy specyfikacji wymagań
o modelu i projektu systemu
o kodowania (implementacji)
o fazy testowania
o dokumentacji
o procesu zarządzania projektem
PowyŜsza klasyfikacja jest najbardziej ogólna ze wszystkich tutaj prezentowanych,
kaŜda kolejna stanowi jedynie jej uszczegółowienie na konkretnym poziomie. Rysunek 2-4
przedstawia bardziej praktyczne podejście do kategoryzacji defektów oprogramowania.
Obrazuje on procentowy podział najczęstszych lokalizacji wykrywanych defektów.
Wyraźnie widać, Ŝe zdecydowana większość defektów ma swoje źródła w specyfikacji
wymagań oraz projekcie systemu. Defekty natury technicznej powstające na dalszych
etapach cyklu wytwórczego mają relatywnie mniejszy udział procentowy.
Rysunek 2-4 Procentowy udział defektów (Sheldon, IEEE Software, July 1992)
Defekty, bez względu na moment ich powstania w cyklu wytwórczym, odznaczają
się róŜnym stopniem waŜności. Systemy informatyczne praktycznie nigdy nie będą
pozbawione defektów, a jednocześnie kaŜdy projekt to przedsięwzięcie ograniczone
fizycznymi warunkami takimi jak czas realizacji czy budŜet. Wszystko to powoduje, Ŝe
przy identyfikacji defektów konieczne jest ich odpowiednie stopniowanie. Biorąc pod
uwagę priorytet przy ich analizie i usuwaniu, defekty moŜna podzielić na:
19
•
defekty krytyczne
•
defekty niekrytyczne
W fazie specyfikacji wymagań oraz projektu, powyŜszy podział nie moŜe być
stosowany, gdyŜ praktycznie kaŜde zagadnienie uznane za defekt powinno być
sklasyfikowane jako krytyczne dla dalszego powodzenia projektu.
Obok stopnia uciąŜliwości defektu jedną z najwaŜniejszych cech jest sposób jego
aktywacji i rodzaj negatywnego wpływu na działanie całego systemu. Defekty
oprogramowania występują w bardzo róŜnych miejscach i często błędy wynikające z ich
istnienia aktywują się wysoce niedeterministycznie. Istotna z punktu klasyfikacji jest takŜe
częstotliwość występowania defektów oraz konsekwencje ich aktywacji. PoniŜej znajduje
się podział uwzględniający powyŜsze aspekty:
•
defekty losowe (zmienne, trudne do określenia warunki aktywacji)
•
defekty stabilne (stałe warunki aktywacji)
•
defekty narastające (defekty, których istnienie rodzi zagroŜenie wystąpienia
kolejnych problemów)
Kolejną cechą jest natura samego defektu. Działanie oprogramowania niezgodne
z oczekiwaniami moŜe się przejawiać zarówno w postaci niepoprawnych wyników jak
i źle oddanej funkcjonalności, co powoduje kolejny podział na defekty funkcjonalne oraz
defekty obliczeniowe. Defekty natury funkcjonalnej są silnie powiązane z postrzeganą
subiektywnie przez uŜytkowników ergonomią interfejsu uŜytkownika. Znaczna część
problemów zgłaszanych przez końcowych odbiorców oprogramowania dotyka właśnie tej
sfery, choć ich przyczyna niekoniecznie musi tkwić w samej warstwie prezentacji systemu.
Niemniej jednak, przy zbieraniu informacji o defektach naleŜy koniecznie sklasyfikować
dane zagadnienie jako defekty uciąŜliwe oraz defekty kosmetyczne.
Zaprezentowane klasyfikacje stanowią moją subiektywną interpretację cech
defektów i stanowią jedynie przykład róŜnorodności problemów, z jakimi spotykamy się
w trakcie cyklu wytwórczego oprogramowania. KaŜdy projekt moŜe odznaczać się
indywidualną specyfiką i na jego potrzeby mogą być tworzone zupełnie odmienne
hierarchie zagadnień. W dalszej części rozdziału koncentrować się będę na pierwszym,
najbardziej ogólnym, podziale defektów według momentu ich powstawania. Pozostałe
20
klasyfikacje, choć przydatne z punktu widzenia praktycznego, nie wymagają dalszych
szczegółowych wyjaśnień.
2.3.3.1 Defekty produktów fazy specyfikacji wymagań
Proces powstawania oprogramowania zazwyczaj rozpoczyna się od stworzenia
ogólnego opisu problemu oraz zarysu poŜądanego rozwiązania. Zarys ten ma zazwyczaj
postać zestawienia wymagań uŜytkownika ze wstępną koncepcją ich spełnienia. Niekiedy
spis wymagań tworzy sam uŜytkownik, czasami zaś producent oprogramowania na
podstawie wywiadów z uŜytkownikiem, badań jego potrzeb, swoich wyobraŜeń
o potrzebach uŜytkownika itd. W kaŜdym z wymienionych przypadków istnieją bardzo
duŜe szanse popełnienia pomyłki. UŜytkownik moŜe być niezdolny do adekwatnego
opisania swych wymagań lub jego potrzeby mogą być fałszywie zinterpretowane
w procesie identyfikacji. Najczęstszym przypadkiem jest jednak sytuacja, w której nie
wszystkie potrzeby są odpowiednio rozpoznane i udokumentowane. Rysunek 2-5 obrazuje
to zjawisko:
Rysunek 2-5 Wymagania w zakresie systemu (J.Górski - InŜynieria Wymagań - wykład)
Jak widać dla zidentyfikowanego zakresu systemu w praktyce znaczna część
wymagań zostaje pominięta lub niekompletnie sprecyzowana. Kolejną duŜą grupą są
wymagania źle zidentyfikowane, które wymagają bezwzględnej korekty. Spora liczba
zidentyfikowanych wymagań zostaje wyspecyfikowana poprawnie poza granicami
systemu – tego typu pomyłki zwiększają nie tylko koszt i długość trwania projektu, ale
mogą równieŜ stanowić źródło defektów we fragmentach systemu, z którymi mają punkty
wspólne. Problem wadliwej specyfikacji wymagań wydaje się nieunikniony bez względu
21
na charakter projektu. Jest to o tyle niebezpieczne, Ŝe wszelkie pomyłki popełnione na tym
etapie są szalenie kosztowne i są źródłem powstawania kolejnych pomyłek w następnych
fazach procesu.
2.3.3.2 Defekty modelu i projektu systemu
Drugi etap, analiza i projektowanie systemu, polega na przetłumaczeniu zebranych
potrzeb uŜytkownika na zbiór rozwiązań dla budowanego systemu. Pracę nad
oprogramowaniem rozpoczyna się od szczegółowej analizy problemu, który ma ono
rozwiązywać. W przypadku systemów budowanych na zamówienie wymaga to moŜliwie
wiernego odwzorowania procesów zachodzących w danej organizacji. Największy
problem polega na tym, Ŝe nie wszystkie z działających procesów biznesowych są w pełni
poznane i dają się w dostatecznie formalny sposób opisać. KaŜda z osób zaangaŜowanych
w rozwój projektu informatycznego w pewnym sensie tworzy własną interpretację zastanej
rzeczywistości. Klient stara się przedstawić problem analitykowi, ten z kolei przekazuje
zinterpretowaną przez siebie wizję projektantowi, który na podstawie analizy rozpocznie
prace nad techniczną specyfikacją systemu i poszczególnych rozwiązań. W rezultacie
programista często otrzymuje wielokrotnie przeistoczony obraz rzeczywistego procesu
biznesowego i staje przed koniecznością implementacji problemu, który, co najgorsze,
będzie takŜe rozumiał na własny sposób.
Fałszywa interpretacja wymagań, przeoczenie koniecznych do podjęcia decyzji lub
załoŜeń niewystępujących jawnie wśród wymagań uŜytkownika powodują wprowadzenie
defektów do powstającego produktu. Zasadniczym celem tego etapu jest przekształcenie
załoŜeń w specyfikacje techniczne, będące precyzyjnym opisem zachowania całości
systemu. Z uwagi na największą liczbę dokonywanych w tym etapie tłumaczeń jest on
bardzo podatny na pomyłki w procesie budowy oprogramowania. Pomyłki, które moŜna tu
popełnić, są niewątpliwie groźne i są silnie uzaleŜnione nie tylko od precyzji specyfikacji
wymagań na system, ale takŜe od umiejętności projektantów. Po raz kolejny w procesie
generacji defektów oprogramowania swój znaczący udział ma zatem czynnik ludzki.
Ponadto, poniewaŜ z etapu na etap cyklu wytwarzania mamy do czynienia z coraz większą
ilością
przetwarzanej
informacji,
szansa
wprowadzenia
defektów
do
projektu
i oprogramowania jest w tym kroku bardzo duŜa.
22
2.3.3.3 Defekty kodowania (implementacji)
Kolejnym etapem konstrukcyjnym w fazie wytwórczej systemu jest kodowanie
(implementacja) oprogramowania, a więc przełoŜenie specyfikacji oprogramowania na
język programowania. Na tym etapie popełnia się z reguły wiele pomyłek, jednak znacząca
ich ilość ma charakter pomyłki programisty. Zazwyczaj, choć niestety nie zawsze, są to
defekty, których wykrycie i poprawienie jest relatywnie łatwe, a w przypadku defektów
natury „ortograficznej” wykonywane jest to automatycznie przez narzędzia. Nie naleŜy
jednak zapomnieć o fakcie, iŜ niedostatecznie szczegółowy i kompletny projekt systemu
moŜe być przyczyną powaŜnych defektów. Programista, któremu projekt pozostawia zbyt
duŜą dowolność w zakresie implementacji złoŜonych algorytmów jest potencjalnym
źródłem wielu, trudnych do późniejszego wykrycia, defektów.
W procesie implementacji występuje teŜ drugi rodzaj tłumaczenia - translacja
programu w języku źródłowym na wykonywalny przez maszynę kod docelowy. Tej
translacji dokonuje kompilator i moŜe się oczywiście zdarzyć, Ŝe zawiera on defekt
powodujący błędną translację programu. Tego typu defekty musimy jednak traktować jako
zjawiska będące zazwyczaj poza naszą kontrolą.
2.3.3.4 Defekty fazy testowania
Przy okazji wytwarzania systemu powstaje takŜe szereg innych produktów, które
równieŜ naraŜone są na pomyłki. Przykładami mogą być źle zaprojektowane plany testów,
czy nieprawidłowo przeprowadzone i udokumentowane testy. Pod pojęciem defektów fazy
testowania kryją się wszelkie defekty, które pozostają nie wykryte w produkcie na skutek
niedoskonałości lub niekompletności procesu testowania. Dotyczy to zarówno testowania
jednostkowego wykonywanego w trakcie prac implementacyjnych jak i późniejszych
testów integracyjnych i systemowych. Warto zaznaczyć, iŜ pojęcie defektu testowania
odnosi się tylko do przyczyn jego pozostania w produkcie, gdyŜ zasadniczo ich źródłami
nadal pozostają czynniki ludzkie i defekty zaszczepione w poprzednich fazach. WaŜne jest
jednak to, Ŝe przyczyną propagacji defektów są często źle zaprojektowane plany testów
oprogramowania lub w skrajnych przypadkach ich kompletny brak. Kompleksowe
testowanie kodu źródłowego powstającego w fazie implementacji moŜe przyczynić się do
identyfikacji i eliminacji wielu defektów.
23
2.3.3.5 Defekty dokumentacji
Jako wynik przedsięwzięcia programistycznego uzyskujemy program wraz z jego
dokumentacją – projektową oraz uŜytkową. Ten drugi składnik moŜe takŜe zawierać
szereg defektów. O oczywistych problemach wynikających z wadliwej dokumentacji
projektowej była mowa wyŜej. Osobną kwestią jest jakość i kompletność dokumentacji
uŜytkowej oprogramowania. Dokumentacja ta ma wpływ nie tyle na samą niezawodność
oprogramowania, a bardziej na jego postrzeganą jakość. JeŜeli instrukcja zawiera błąd
merytoryczny, innymi słowy nie opisuje wiernie zachowania systemu, uŜytkownik po jej
przeczytaniu uŜyje oprogramowania i stwierdzi, Ŝe oprogramowanie zawiera defekt.
NaleŜy przy tym pamiętać, Ŝe nawet jeŜeli oprogramowanie i jego dokumentacja są
zgodne, to w programie nadal mogą i z pewnością występują defekty. PowyŜszy problem
dotyka takŜe słowników danych i pojęć, których błędna lub niekompletna zawartość takŜe
traktowana jest jako defekt dokumentacji.
2.3.3.6 Defekty produktów procesu zarządzania projektem
Projekt informatyczny jako przedsięwzięcie niezwykle złoŜone wymaga sprawnego
zarządzania. Produkty tego procesu nie dotyczą bezpośrednio wytwarzanego produktu,
jednak mają zasadniczy wpływ na kształt samego procesu wytwórczego. Defekty zaszyte
w planach projektu, harmonogramach, przydziale zasobów, oszacowaniu kosztów czy
raportach ze spotkań mogą prowadzić w skrajnym przypadku do niepowodzenia projektu
lub co najmniej do powstawania kolejnych defektów w pozostałej dokumentacji systemu.
Dokumentacja związana z zarządzaniem projektem powinna być traktowana na równi
z innymi produktami procesu wytwórczego, a tym samym naleŜy dąŜyć do minimalizacji
występujących w niej defektów.
2.3.4
Metody ograniczania wpływu defektów
W ogólności wszelkie podejścia w dziedzinie niezawodności systemów
informatycznych moŜna podzielić na cztery grupy [SKOCZ1996]:
•
unikanie - stosowanie zasad i technik zmniejszających liczbę pomyłek
prowadzących do defektów w docelowym produkcie.
•
wykrywanie - polega na zastosowaniu takich konstrukcji w systemie, które starają
się wykrywać obecność błędów.
•
poprawianie - tworzenie w produkcie środków usuwających negatywne efekty
wynikające z defektów.
24
•
tolerowanie - zdolność systemu do działania w obecności defektów.
Jak w wielu innych dziedzinach, najlepszym sposobem radzenia sobie
z problemami jest ich unikanie, co w tym kontekście oznacza wykrywanie i eliminowanie
pojawiających się defektów zanim przeistoczą się one w źródła powaŜnych problemów.
Niestety, ze względu na silny wpływ czynnika ludzkiego w całym procesie inŜynierii
oprogramowania, nie istnieje w pełni skuteczna metoda unikania defektów. Jedynym
dostępnym środkiem w takiej sytuacji staje się próba rozbudowy procesu wytwórczego
o dobrze zdefiniowane i sprawdzone praktyki. W takim ujęciu techniki unikania defektów
są to metody, zasady i praktyki projektowania i wytwarzania, które mają na celu
zapobieganie pomyłkom wprowadzającym defekty w oprogramowaniu. Większość z nich
jest ukierunkowana na zapobieganie powstawania defektów w trakcie opisywanego
wcześniej procesu tłumaczenia informacji. Praktyka pokazuje, Ŝe liczbę pomyłek w tym
procesie moŜna redukować poprzez:
•
zmniejszenie złoŜoności problemu
•
ulepszanie przekazu informacji
•
natychmiastowe wykrywanie i usuwanie skutków pomyłek
Zmniejszenie złoŜoności problemu moŜna uzyskać dzięki jego dekompozycji na
szereg mniejszych podproblemów. Podejście takie, przynajmniej teoretycznie, stwarza
nadzieję na popełnienie mniejszej ilości pomyłek przy kolejnych jego translacjach.
MoŜemy starać się ten cel osiągnąć takŜe kładąc większy nacisk na kontrolę jakości
powstających
produktów,
czemu
słuŜą
wszelkie
techniki
wspierania
kontroli
i sprawozdawczości w projekcie takie jak inspekcje, przeglądy, czy audyty. Dobre efekty
w tej materii moŜna uzyskać zwiększając udział klienta w procesie wytwórczym np.
poprzez umieszczenie zespołu projektowego w środowisku pracy odbiorcy systemu.
Podejście takie stwarza lepsze warunki komunikacji na linii klient-dostawca i zapewnia
większą widzialność stanu projektu na zewnątrz, co bezpośrednio przekłada się na
skuteczność wychwytywania defektów zanim staną się one groźne dla dalszego przebiegu
przedsięwzięcia. Wreszcie bardzo waŜne jest to, aby zamiast odkładać kontrolę jakości
produktów danej fazy na jej koniec (tradycyjne podejście typu produkt-test), starać się
czynić to na bieŜąco, juŜ w momencie ich tworzenia.
Warto w tym momencie zaznaczyć, Ŝe wszelkie próby unikania defektów mają
bardzo silny związek z ogólnie pojętym zarządzaniem jakością w projekcie. Jakość
25
kontroluje się poprzez niezaleŜne sprawdzenie zgodności produktu i procesu z przyjętymi
wymaganiami – zarówno na sam produkt jak i na sposób jego realizacji. Szczegółowe
planowanie zarządzania jakością jest standardową czynnością we współczesnych
projektach informatycznych i jako jeden z wielu czynników moŜe przyczynić się do
skuteczniejszego unikania defektów.
2.3.5
Postępowanie z defektami
Z faktem obecności defektów w produktach informatycznych nie moŜna
dyskutować, moŜna jedynie starać się wprowadzać do procesu wytwórczego takie
mechanizmy, które pozwolą efektywnie radzić sobie z ich wykrywaniem i usuwaniem.
W ogólności proces zarządzania defektami moŜna przedstawić jako cyklicznie powtarzane
testowanie i naprawianie produktu. Rysunek 2-6 przedstawia etapy postępowania
z defektami:
Rysunek 2-6 Ogólny proces postępowania z defektami (źródło własne)
PowyŜszy schemat ma jedynie ogólny charakter i nie porusza takich aspektów jak
planowanie testów, dokumentowania przypadków błędnego działania systemu (awarii) czy
wreszcie dystrybucji i wdraŜania poprawionych wersji systemu. Zagadnieniami tymi
zajmuje się m.in. proces zwany zarządzaniem konfiguracją, którego szerszy opis znajduje
się w Rozdziale 5 – „Zarządzanie problemami w projekcie informatycznym”.
2.4
Zmiany
Nie lubimy zmian - to dość znana ludzka cecha. Intuicyjnie wiemy, Ŝe kaŜda
zmiana pociąga za sobą jakiś wysiłek lub trudności do pokonania. W inŜynierii
oprogramowania zmiany są nieuniknione, a ich potrzeba moŜe się ujawnić w kaŜdym
momencie trwania procesu wytwórczego. Im późniejsze jej wystąpienie tym większy
wpływ ma ona na całość przedsięwzięcia, dlatego planując realizację systemu
informatycznego musimy się liczyć z moŜliwością całkowitego zachwiania równowagi
projektu od momentu jego wstępnej analizy, a na wdroŜeniu i pielęgnacji kończąc.
Wszelkie prośby o zmiany, obok defektów, stanowią jedno z głównych źródeł problemów
w projekcie informatycznym.
26
Pielęgnacja
oprogramowania
jest
jednym
z
najwaŜniejszych
i
zarazem
najtrudniejszych zagadnień inŜynierii oprogramowania. Opieka nad oprogramowaniem
wiąŜe się zazwyczaj z koniecznością modyfikacji wszystkich produktów wcześniejszego
projektu informatycznego, począwszy od kodu źródłowego, a na specyfikacji wymagań
kończąc. Systemy informatyczne muszą ulegać modyfikacjom z rozmaitych przyczyn,
z których najbardziej trywialnymi jest konieczność usuwania wykrytych defektów i chęć
dostosowania ich do wciąŜ zmieniających się potrzeb uŜytkowników. Z drugiej strony,
wprowadzanie jakichkolwiek modyfikacji jest bardzo niebezpieczne, gdyŜ obarczone jest
sporym ryzykiem wprowadzenia nowych defektów i aktywacji tych dotychczas nie
wykrytych.
Zmiany moŜna nie tylko rozpatrywać w kontekście produktu, ale takŜe
z perspektywy organizacji samego projektu informatycznego. Rozmaite czynniki i warunki
narzucane przez środowisko zewnętrzne, w którym obraca się przedsięwzięcie mogą
powodować szereg problemów, u których podstaw leŜy szeroko pojęta konieczność
wprowadzania zmian. Czas realizacji projektów planowany jest zazwyczaj na okres
liczony w miesiącach, czasami nawet w latach. Biorąc pod uwagę tę skalę czasową
praktycznie moŜemy być pewni, Ŝe w trakcie trwania projektu wystąpią istotne zmiany
w samym przedsiębiorstwie lub w jego otoczeniu i nie będą one bez wpływu na toczący się
projekt informatyczny.
Zmiany w projekcie oraz naciski na ich wprowadzenie, będą zawsze, naleŜy
jedynie umieć odpowiednio wcześnie je dostrzec i właściwie z nimi postępować. Warto
w tym miejscu po raz kolejny rozróŜnić dwa pojęcia związane z problemem zmian
w projekcie, a dokładniej, nie naleŜy mylić prośby o zmianę z właściwym procesem
wprowadzania jej w Ŝycie. Analiza i odpowiednia klasyfikacja pojawiających się
potrzeb/próśb zmian stanowi podstawę sprawnej pielęgnacji oprogramowania. Nie kaŜda
potrzeba zmiany znajduje realne uzasadnienie do jej wprowadzenia, z kolei te uznane
i przyjęte do realizacji odznaczają się zazwyczaj róŜnym stopniem pilności i krytyczności
dla projektu. Jak juŜ zostało wcześniej zasygnalizowane, w dalszej części pracy pojęcie
zmiany będzie rozumiane jako potrzeba i prośba o jej wprowadzenie.
27
2.4.1
Źródła zmian
MoŜna powiedzieć, Ŝe źródeł zmian jest tak duŜo, jak duŜa jest liczba osób
zaangaŜowanych w przedsięwzięcie informatyczne. Na domiar złego są one równie
nieprzewidywalne. NaleŜy takŜe zwrócić uwagę na fakt, iŜ zrealizowanie jednej
zaplanowanej zmiany lub poprawienie znanego defektu, moŜe pociągnąć za sobą
konieczność wprowadzenia kolejnych zmian. Szczególnie istotne z punktu widzenia
projektu są wszelkie zmiany wymagań. MoŜna wyróŜnić wiele powodów, dla których
moŜe nastąpić zmiana (ewolucja) wymagań, przy czym część z nich wynika z faktu, Ŝe
analiza duŜego projektu moŜe trwać nawet kilka lat i w tym czasie zmieniają się pewne
warunki:
•
mogą ulec zmianie warunki zewnętrzne, np. zmiana legislacyjna w państwie
•
mogą ulec zmianie warunki wewnętrzne, np. zmieniła się polityka jakości firmy,
lub teŜ firma właśnie taką politykę wdroŜyła
•
w czasie tworzenie systemu, pogłębia się zrozumienie wymagań klienta
•
zmieniły się osoby decydujące po stronie klienta, zatem mogła teŜ ulec zmianie
wizja systemu
•
klient stwierdził błąd we wcześniejszych wymaganiach, który musi być naprawiony
•
zmieniło się otoczenie systemu lub oprogramowanie stowarzyszone
•
zmienił się sprzęt
Pomijając kwestię potrzeb zmian generowanych przez wykrywane defekty,
z punktu widzenia projektu informatycznego źródła zmian mogą być zarówno zewnętrzne
jak i wewnętrzne. PoniŜej znajduje się bardziej szczegółowa ich charakterystyka.
2.4.1.1 Źródła zewnętrzne
Najprostszym i zarazem najczęstszym źródłem zmian zewnętrznych jest sam klient,
który zgłasza nowe wymagania lub modyfikuje jedno z wcześniej zidentyfikowanych.
Tego typu prośby są zazwyczaj najbardziej brzemienne w skutkach i mogą prowadzić do
daleko idących zmian zarówno w powstającym produkcie jak i samym projekcie.
Znakomita większość tego typu potrzeb zmiany wynika z niepowodzenia w opanowaniu
oczekiwań odbiorcy produktu, a więc jest efektem defektów i niekompletności pierwotnej
specyfikacji wymagań. W miarę rozwoju przedsięwzięcia klient nabywa umiejętność coraz
28
lepszego wyraŜania swoich wymagań i lepiej poznaje związane z przedsięwzięciem
technologie.
Wśród źródeł zewnętrznych warto zwrócić uwagę takŜe na szeroko pojętą sytuację
rynkową, a więc działania konkurencji, działania partnerów, oczekiwania klientów, trendy
i mody. Kolejnym zewnętrznym źródłem zmian jest sytuacja polityczno-prawna
– przykładem moŜe tu być wprowadzenie obowiązku stosowania kas fiskalnych, ustawa
o ochronie danych osobowych czy teŜ zmiana przepisów ZUS. Nie bez znaczenia,
zwłaszcza w projektach związanych z informatyzacją, jest bardzo szybki rozwój
technologii. MoŜe on powodować konieczność zmian wymagań sprzętowych, rozwiązań
telekomunikacyjnych czy narzędzi programistycznych w trakcie trwania projektu.
Kolejnym źródłem zmian mogą być podwykonawcy, zwłaszcza ci nierzetelni.
2.4.1.2 Źródła wewnętrzne
Zmiany wprowadzane w toczącym się projekcie mogą mieć źródła tkwiące
wewnątrz samego projektu – na przykład konieczność wprowadzenia korekt z uwagi na
zbyt późne odkrycie defektów w przyjętym rozwiązaniu czy niewłaściwe oszacowanie
pracochłonności lub brak zasobów. Ponadto w miarę rozwoju projektu, zespół go
realizujący coraz lepiej poznaje dziedzinę problemową i uzbrojony w większą wiedzę na
temat funkcjonowania środowiska klienta ma nowe i ulepszone pomysły, które moŜe
chcieć zaprezentować klientowi. Potrzeba zmiany wywodzi się w takim przypadku
bezpośrednio od wykonawcy i jest motywowana chęcią dąŜenia do usprawnienia
wytwarzanego produktu, a co za tym idzie takŜe poziomem zadowolenia klienta. Przy
okazji wewnętrznych źródeł zmian warto takŜe wspomnieć o zmianach własnościowych
czy o róŜnego rodzaju decyzjach na szczeblu kierowniczym odnoszących się do całej
organizacji wytwarzającej system. Przykładem takiej decyzji moŜe być wymuszenie
zmiany stosowanych narzędzi wytwórczych, albo przejście na inną niŜ dotychczas
technologię.
2.4.2
Rodzaje zmian
Konserwacja oprogramowania polega na wprowadzeniu do niego modyfikacji.
Dobrze jest, jeśli kaŜda taka zmiana wiąŜe się takŜe z powrotem do wcześniejszych faz
analizy i projektowania, na których rezultaty wpływa przeprowadzana zmiana
w oprogramowaniu. Jednak nie wszystkie zmiany w oprogramowaniu odznaczają się tym
samym stopniem trudności ich wprowadzania. Z pielęgnacją oprogramowania związane są
29
cztery tradycyjnie wyróŜniane kategorie czynności [SZEJ2002] oraz powiązane z nimi
klasy wprowadzanych w oprogramowaniu modyfikacji:
•
pielęgnacja naprawcza (ang. corrective maintenance) - modyfikacje naprawiające
•
adaptacja (ang. adaptive maintenance) - modyfikacje dostosowujące
•
ulepszanie (ang. perfective maintenance) - modyfikacje udoskonalające
•
utrzymanie zapobiegawcze (ang. preventive maintenance) – modyfikacje
prewencyjne.
WyróŜnione typy zmian róŜnią się głównie ze względu na powody i cel ich
wystąpienia. Charakter analizowanej prośby o zmianę ma bardzo często decydujący wpływ
na decyzję o jej odrzuceniu lub przyjęciu i ewentualnym przydzieleniu priorytetu. PoniŜej
znajduje się bardziej szczegółowa charakterystyka wymienionych wyŜej rodzajów zmian.
2.4.2.1 Modyfikacje naprawiające
Polegają na usuwaniu z oprogramowania defektów wprowadzonych w fazach
wymagań, analizy, projektowania i implementacji. Są to zmiany mające na celu usunięcie
ujawniających się defektów, które prowadzą do pojawiania się błędów i awarii
w rozwijanym systemie. Potrzeba wprowadzenia zmiany poprawiającej zazwyczaj wynika
z wykrycia defektu, dlatego teŜ są to najczęściej zmiany, których nie moŜna unikać i wręcz
naleŜy nadawać im wysoki priorytet realizacji.
2.4.2.2 Modyfikacje udoskonalające i prewencyjne
Polegają na poprawie jakości oprogramowania i dotyczą takich jego aspektów jak
wydajność czy ergonomia interfejsu uŜytkownika. Często zmiany tego typu zmierzają do
skompensowania problemów wynikających ze współdziałania systemu z jego otoczeniem
programowym lub sprzętowym. W przypadku zmian o charakterze ulepszającym moŜemy
mieć do czynienia z modyfikacjami o charakterze udoskonalenia konkretnego aspektu
działania systemu lub o charakterze prewencyjnym. W pierwszym wypadku potrzeba
zmiany jest zazwyczaj reakcją na konkretny problem taki jak np. wydajność. Z kolei
zmiana o charakterze prewencyjnym ukierunkowana jest na nadanie oprogramowaniu
nowej cechy, której potrzeba nie koniecznie została jeszcze dostrzeŜona lub, której
implementacja nie była wcześniej uwaŜana za priorytetową. Przykładami ruchów
prewencyjnych są wszelkiego rodzaju ulepszenia bezpieczeństwa i niezawodności
systemu.
30
Wszystkie
prośby
opisywanego
tutaj
typu
muszą
być
skonfrontowane
z wymaganiami jakościowymi nałoŜonymi na produkt. Jeśli, przykładowo, jednym
z kluczowych aspektów tworzonego systemu jest wydajność to wszelkie potrzeby
dotykające tej materii muszą być rozpatrywane z odpowiednio wysokim priorytetem.
Z drugiej strony, prośby mające charakter ewidentnych „Ŝyczeń”, które nie przekładają się
bezpośrednio na osiągnięcie celów biznesowych stawianych systemowi powinny być
potraktowane z adekwatnie mniejszym stopniem zaangaŜowania.
2.4.2.3 Modyfikacje dostosowujące
Modyfikacje dostosowujące polegają na dostosowaniu oprogramowania do zmian
zachodzących w wymaganiach uŜytkownika lub w środowisku komputerowym,
zmierzające do dostosowania systemu do zmieniających się uwarunkowań biznesowych,
otoczenia lub zmian specyfikacji. Zasadniczo, obok zmian wymuszonych wykryciem
defektów, jest to najliczniejsza i zarazem najbardziej skomplikowana grupa modyfikacji.
Obejmuje ona zagadnienia wynikające ze zmiany wymagań uŜytkowników, zmian
przepisów prawnych dotyczących dziedziny problemu, wszelkich zmian organizacyjnych
po stronie klienta, czy wreszcie zmian sprzętu i oprogramowania systemowego.
Modyfikacje dostosowujące muszą być szczegółowo przeanalizowane pod kątem juŜ
zatwierdzonych i zmieniających się wymagań oraz przede wszystkim z uwzględnieniem
zakresu systemu zawartego w kontrakcie wiąŜącym dostawcę z klientem.
2.4.3
Wpływ zmian na projekt
Zmiany pojawiają się we wszystkich fazach cyklu Ŝycia oprogramowania, zarówno
w trakcie jego wytwarzania, jak i późniejszej jego eksploatacji. Bez wątpienia wszystkie
zmiany modyfikują ustalony plan działania. Wiele z nich, na przykład niewielkie
opóźnienia podwykonawców, o ile nie dotyczą ścieŜki krytycznej projektu, nie powodują
większych konsekwencji dla projektu poza modyfikacją cząstkowych terminów
w harmonogramie. DuŜo bardziej niebezpieczne są zmiany mające wpływ na podstawowe
atrybuty projektu – na jego zakres, termin oraz koszty. NaleŜy pamiętać, Ŝe zmiana
jednego z tych atrybutów zazwyczaj powoduje zmianę pozostałych.
Zmiany terminów, zwłaszcza ich skrócenie, mogą być efektem nacisków rynku lub
nowych właścicieli – ich konsekwencją jest na ogół wzrost kosztów projektu. Równie duŜy
wpływ na projekt moŜe mieć narzucone z zewnątrz odsunięcie terminów – tutaj skutki są
mniej przewidywalne. MoŜe to powodować przedwczesne „odpręŜenie”, utratę tempa
31
i spowolnienie prac, a w efekcie niedotrzymanie nowych terminów lub w skrajnym
przypadku utratę osób będących siłą napędową projektu, osób, które zaangaŜowały się
w projekt identyfikując swoje cele osobiste z celami projektu – w tym przypadku
drastyczne odsunięcie terminów moŜe zostać potraktowane jako uniemoŜliwienie realizacji
własnych celów.
Zmiany budŜetu projektu, zwłaszcza cięcia, skutkują zmniejszeniem zakresu
projektu lub wydłuŜeniem czasu jego realizacji, w efekcie, czego często cele projektu nie
są realizowane w akceptowalnym czasie lub wręcz wcale.
Zmian nie moŜna ignorować ani odmawiać ich wprowadzenia, gdyŜ w takim
wypadku docelowy produkt nie będzie spełniał rzeczywistych potrzeb, a jedynie
realizował potrzeby historyczne, dziś juŜ nieaktualne. Z drugiej strony bezkrytyczne
wprowadzanie wszystkich zmian moŜe spowodować wymknięcie się projektu spod
kontroli, przekroczenie budŜetu i terminów czy wręcz jego fiasko. Jedynym rozsądnym
rozwiązaniem jest właściwe zarządzanie zmianami. O konieczności zarządzania zmianami
naleŜy pamiętać od samego początku projektu gdyŜ to zadanie, tak jak kaŜde inne,
wymaga czasu i odpowiednich zasobów.
2.4.4
Proces zarządzania zmianami
Istotny proces w ewolucji oprogramowania, który występuje takŜe przy
wytwarzaniu oprogramowania od początku, to proces kontroli i zarządzania zmianami
[SZEJ2002]. Jest on jednym z wielu elementów procesu zwanego zarządzaniem
konfiguracją. Zasadniczo rozpoczyna się w momencie zaistnienia potrzeby wprowadzenia
zmiany. Pierwszym krokiem jest jej wieloaspektowa analiza. NaleŜy tu dokładnie
przeanalizować czy i dlaczego dana zmiana powinna być wprowadzona. Konieczne jest
tutaj ocenienie, jaki wpływ będzie miała ta propozycja na projekt, czyli czy jest zgodna
z jego celami i jak zmieni ona podstawowe atrybuty - zakres, termin i koszty. NaleŜy
równieŜ przeprowadzić analizę ryzyka w związku z wprowadzanymi zmianami, gdzie
szczególną uwagę naleŜy poświęcić kosztom jej zaniechania. Rysunek 2-7 przedstawia
kolejne kroki procesu zarządzania zmianami.
32
Rysunek 2-7 Proces zarządzania zmianami (M.Piechówka, 2002)
W efekcie procesu decyzyjnego moŜe nastąpić odrzucenie zmiany, odłoŜenie do
powtórnego rozpatrzenia w terminie późniejszym lub jej akceptacja. W przypadku
akceptacji zmiany naleŜy uaktualnić wszelkie plany i harmonogramy. NiezaleŜnie od
rodzaju podjętej decyzji, informacja o niej wraz z uzasadnieniem powinna być
rozpowszechniona wśród wszystkich podmiotów zaangaŜowanych w projekt. Oczywistym
jest,
Ŝe
wszystkie
wymienione
wcześniej
kroki
powinny
być
szczegółowo
dokumentowane.
Opisany wyŜej schemat postępowania pozwala w sposób formalny wprowadzić
zmianę do projektu i od tej pory dalsze czynności wykonywane są juŜ w ramach
standardowego procesu zarządzania projektem. Temat tutaj poruszany będzie przedmiotem
dalszej analizy w Rozdziale 5 – „Zarządzanie problemami w projekcie informatycznym”.
2.5
Koszty defektów i zmian
Praktyka pokazuje, Ŝe naleŜy starać się wykrywać i rozwiązywać problemy
najwcześniej jak tylko moŜna. Najlepszym przykładem potwierdzającym to stwierdzenie
jest gwałtowny wzrost kosztu usunięcia defektu zaszytego w specyfikacji wymagań
w miarę przechodzenia do kolejnych faz wytwarzania systemu. Szacuje się, Ŝe w takim
przypadku koszt usunięcia defektu wprowadzonego do produktu we wczesnych etapach
jego konstrukcji, rośnie w stosunku 1 do 10 do 100 w trakcie całego cyklu Ŝycia
oprogramowania. Przyjmując koszt usunięcia tego defektu w fazie analizy i projektowania
jako jedna jednostka, koszt usunięcia tego samego problemu w fazie implementacji
i testowania oprogramowania to juŜ 10 jednostek. JeŜeli defekt zostanie zidentyfikowany
dopiero w trakcie eksploatacji systemu, moŜemy się spodziewać, Ŝe realizacja tego
33
przedsięwzięcia będzie się wiązała ze sto razy większym kosztem niŜ we wstępnych fazach
produkcji oprogramowania. ZaleŜność ta staje się logiczna biorąc pod uwagę fakt, Ŝe
modyfikacja oprogramowania na tym etapie zazwyczaj wiąŜe się z przeprojektowaniem,
dodatkową implementacją i wreszcie ponownym wdroŜeniem nowej wersji systemu.
Opisane wyŜej zaleŜności, w odniesieniu do defektów specyfikacji wymagań przedstawia
wykres 2-8:
Rysunek 2-8 Koszty defektów specyfikacji wymagań (J.Górski - InŜynieria Wymagań - wykład)
Jak juŜ wspomniano wcześniej, defekty wczesnych faz projektu, a w szczególności
fazy specyfikacji wymagań, stają się przyczyną konieczności wprowadzania daleko
idących zmian do produktu w dalszych etapach jego produkcji. Defekty wykryte w fazie
projektowania moŜna łatwo naprawić zmieniając kilka linijek tekstu lub modyfikując
odpowiednie diagramy. Koszt usuwania tych samych defektów po implementacji
oprogramowania jest dramatycznie wyŜszy, zarówno w wymiarze nakładów jak
i czasowym.
34
3.
Cykl Ŝycia problemu w projekcie informatycznym
„Ideas may also grow out of the problem itself, which in turn becomes part of the solution"
Paul Rand
3.1
Wprowadzenie
W poprzednim rozdziale wprowadzone zostały niezbędne pojęcia związane
z problemami w projektach informatycznych. Przedstawiony został ogólny podział na
defekty i zmiany oraz ich bardziej szczegółowa klasyfikacja ze względu na rozmaite
kryteria. Wszystkie kwestie dotąd poruszane dotyczyły jednak statycznego opisu problemu
i nie uwzględniały jego obsługi w czasie. Celem niniejszego rozdziału jest
zidentyfikowanie i opisanie cyklu Ŝycia problemu w projekcie informatycznym.
Najogólniej rzecz biorąc, proces ten moŜna rozbić na fazę zaistnienia (zgłoszenia,
wykrycia) problemu, jego długi i Ŝmudny przepływ przez organizację aŜ do ostatecznego
rozwiązania (poprawienie defektu, wprowadzenie zmiany). Rozdział koncentruje się po
kolei na kaŜdym kroku, starając się moŜliwie formalnie go opisać. Przeprowadzenie
analizy pod tym kątem wydaje się konieczne do opracowania narzędzia mającego
wspomagać zarządzanie problemami w projekcie informatycznym.
Wszystkie zaprezentowane poniŜej pojęcia oraz zaleŜności pomiędzy nimi
powstały na bazie literatury poruszającej problem zarządzania zmianą w projektach
informatycznych ([BAY2001], [GOR2000], [CADL2000], [LEST2000], [SZEJ2002]) oraz
własnych przemyśleń wynikających z ich lektury. Przy konstrukcji modelu cyklu Ŝycia
niezwykle cennym źródłem informacji była dokumentacja istniejących na rynku narzędzi
takich jak Bugzilla ([BUG2005]) oraz Mantis Bug Tracker ([MAN2005]). Zaproponowany
graf stanów problemu stanowi syntezę praktycznych rozwiązań prezentowanych przez
wymienione narzędzia oraz wiedzy wydobytej ze źródeł ksiąŜkowych i własnych
doświadczeń. Na koniec warto zaznaczyć, iŜ powstanie powyŜszego opisu cyklu Ŝycia
problemu było konieczne, przed podjęciem próby skonstruowania formalnego modelu
problemu, co jest przedmiotem rozdziału 4 – „Model problemu”.
3.2
Cykl Ŝycie problemu
Bez względu na indywidualny charakter kaŜdego zagadnienia, jakie pojawia się
w trakcie trwania projektu informatycznego, zasadniczo przepływ konkretnego problemu
moŜna podzielić na 4 ogólne kroki:
35
1. Zaistnienie problemu jest powiązane z jego fizycznym wystąpieniem, np.
w momencie wykrycia defektu lub pojawieniem się potrzeby zmiany. W kroku
tym problem ujawnia się i rodzi się potrzeba jego dalszej obsługi.
ZGŁOSZENIE
2. Zgłoszenie problemu ma na celu jego formalne zaistnienie w projekcie. Na
etapie tym tworzony jest ślad jego zaistnienia, formułowany jest jego opis oraz
przeprowadzana jest jego wstępna klasyfikacja.
OBSŁUGA
3. Pod pojęciem obsługi problemu kryje się cały proces przepływu zagadnienia
przez organizację. Faza ta obejmuje identyfikację, klasyfikację,
uszczegółowianie opisu, zmiany odpowiedzialności itd.
ROZWIĄZANIE
4. Proces obsługi problemu powinien prowadzić do jego ostatecznego
rozwiązania. Rozwiązanie moŜe przyjmować róŜne postacie i nie koniecznie
musi się wiązać z wprowadzaniem zmian do powstającego produktu.
5. Bez względu na sposób rozwiązania problemu, koniec jego istnienia
oznacza finalizację jego obsługi. Ślad o wystąpieniu danego zagadnienia
pozostaje jednak w dokumentacji projektowej powstałej w krokach 2-4.
Rysunek 3-1 Ogólny cykl Ŝycia problemu (źródło własne)
PowyŜszy model cyklu Ŝycia problemu jest na tyle ogólny, iŜ obejmuje zarówno
przypadek wykrycia i obsługi defektu oprogramowania, jak równieŜ proces zgłaszania
i wprowadzania zmian do produktu. Jednocześnie, jest on zbyt ogólny, aby zobrazować
szczegółowo, co naprawdę dzieje się z problemem w trakcie jego Ŝycia w projekcie.
Praktyka pokazuje, iŜ przepływ zagadnienia przez projekt często nie jest liniowy, tak jak to
pokazano na diagramie. Przedmiotem dalszej części tego rozdziału jest bardziej
szczegółowy opis kaŜdego z wymienionych wyŜej kroków.
3.2.1
Zgłoszenie problemu
3.2.1.1 Źródła wykrywanych problemów
Projekty informatyczne zawsze obracają się w obrębie pewnej, ściśle określonej
dziedziny problemowej, która wnosi do niego własny zestaw wymagań oraz zbiór
udziałowców. Bez względu na to, czy mamy do czynienia z defektem czy potrzebą
zmiany, źródła tego typu zagadnień pozostają relatywnie określone i zdefiniowane
w ramach konkretnego projektu. Najczęściej spotykanymi źródłami problemów, których
opinii i uwag nie naleŜy lekcewaŜyć, są następujące grupy udziałowców, obecne niemalŜe
w kaŜdym projekcie informatycznym:
36
•
Przedstawiciele klienta
•
Dział wspomagania klienta
(Technical support)
•
Kierownik projektu
•
Testerzy
•
Personel ds. zapewniania jakości
•
•
Dział sprzedaŜy i marketingu
Programiści (Developers)
•
•
Strateg biznesowy
Testerzy wdroŜeń testowych
•
…
•
Końcowi uŜytkownicy systemu
(End Users)
Oczywiście, podana wyŜej lista nie jest kompletna ani słuszna dla kaŜdego
projektu. Generalną zasadą jest to, iŜ kaŜdy uczestnik projektu, który potrafi stwierdzić, Ŝe
działa on niezgodnie z załoŜeniami moŜe być źródłem zgłoszenia problemu. Z jednej
strony, im bardziej system poddawany jest konstruktywnej krytyce, tym większe są jego
szanse na osiągnięcie zadowalającego poziomu jakości w oczach jego odbiorców.
Z drugiej jednak naleŜy pamiętać, iŜ nadmiar krytyki, zwłaszcza tej pochodzącej od mało
istotnych lub wręcz niepotrzebnie zaangaŜowanych udziałowców, moŜe wprowadzić duŜy
szum informacyjny do projektu.
Zbyt duŜa liczba niepotrzebnych lub mało konstruktywnych uwag i sugestii od
niekompetentnych źródeł moŜe spowodować marnotrawienie zasobów projektu przy
realizacji mniej istotnych funkcjonalności kosztem zadań o znacznie wyŜszym priorytecie.
Wszystko to powoduje, iŜ proces zgłaszania problemów w projekcie informatycznym nie
moŜe pozostawać bez nadzoru ani kontroli. Kluczem jest tutaj staranne dobranie źródeł
oraz racjonalna dystrybucja uprawnień w zakresie zgłaszania i zatwierdzania problemów.
3.2.1.2 Moment rejestracji zgłoszenia
Równie waŜnym aspektem problemu, co jego źródło, jest moment jego zgłoszenia.
Kiedy powinno się zgłaszać problem? Oczywiście bezpośrednio po momencie jego
wykrycia! Wprowadzenie jakiegokolwiek opóźnienia względem chwili wystąpienia
problemu moŜe powodować utratę cennych informacji na jego temat lub wręcz całkowite
zagubienie śladu o jego wystąpieniu. Rejestracja problemu równocześnie z jego
wykryciem zwiększa ponadto stopień kompletności opisu zarówno przyczyn jak
i zaobserwowanych skutków. Szybko zarejestrowany problem staje się równieŜ szybko
upublicznionym zagadnieniem, nad którego rozwiązaniem moŜe zacząć pracować cały
zespół projektowy. Dzięki natychmiastowej rejestracji problemu unikniemy takŜe
niepoŜądanego efektu gubienia i przeinaczenia danych w miarę upływu czasu spotykanego
37
przy nieformalnych metodach przechowywania i przekazywania informacji (pamięć
ludzka, luźne notatki). Z drugiej strony pojawia się bardzo istotny pytanie – czy zgłoszenie
problemu musi być jednoznaczne z jego formalną rejestracją? Wspomniany wyŜej problem
nadmiaru źródeł zgłoszeń moŜe stanowić powaŜne spowolnienie procesu wytwórczego.
Ponadto naleŜy pamiętać, iŜ jakość oraz liczba napływających zgłoszeń jest silnie
uzaleŜniona od liczby i kompetencji osób, które tego typu zgłoszenia mają prawo
rejestrować.
3.2.1.3 Opis problemu
Aby proces rejestracji problemu był skuteczny musi on być wsparty odpowiednio
sformalizowanym i spójnym modelem opisu samego problemu oraz okoliczności jego
wystąpienia. Na tym etapie istotne mogą się okazać wszelkie informacje nie tylko na
temat, czego dotyczy problem i jak go powtórzyć, aby zademonstrować niepoŜądane
efekty, ale takŜe czas i miejsce jego wystąpienia. WaŜne jest takŜe to, aby toŜsamość
osoby zgłaszającej nie pozostawała nieznana. Wszystko to powoduje, Ŝe z jednej strony
osoba zgłaszająca zagadnienie musi mieć do dyspozycji elastyczny sposób wyraŜenia
istoty problemu, z drugiej zaś wyprodukowane przez nią zgłoszenie musi posiadać cechy
umoŜliwiające jego sprawną klasyfikację, zarządzanie i obsługę. Na etapie rejestracji
problemu intencją osoby zgłaszającej powinno być stworzenie moŜliwie kompletnego
opisu, na bazie którego moŜliwa będzie jego wstępna kategoryzacja (np. defekty interfejsu
powinny po decyzji o ich rozpatrzeniu wędrować do odpowiedniego działu) i nadanie
priorytetu. Od informacji dostarczonej przez zgłaszającego w duŜej mierze zaleŜy dalsza
obsługa danego problemu. Zagadnienie modelu problemu będzie szerzej opisane
w Rozdziale 4, w którym to nastąpi przejście od ogólnego opisu struktury zgłoszenia do
całkowicie sformalizowanego jego modelu obiektowego w notacji UML.
3.2.1.4 Inne aspekty
Wszystkie wyŜej wymienione aspekty w duŜej mierze zaleŜą od nawyków,
przyjętych praktyk i kultury pracy wypracowanej w projekcie i samej organizacji. Nie bez
znaczenia pozostają tutaj takie czynniki jak zastosowane wsparcie narzędziowe oraz
ustanowione reguły dostępu do niego. W przypadku małych projektów, być moŜe
wystarczającym medium komunikacji w tej materii jest pamięć ludzka albo tablica
karteczek z opisanymi problemami. W miarę wzrostu złoŜoności przedsięwzięcia, sprawny
proces zarządzania problemami wymaga rozwiązań bardziej wyrafinowanych. Bez
38
względu na metodę przechowywania i propagacji zagadnień istotne jest jawne
zdefiniowanie zakresu tego procesu. Przykładowo, jak juŜ wspomniano wyŜej, decyzja
o aktywnym włączeniu klienta do procesu rejestracji problemów moŜe spowodować lepszą
wykrywalność problemów, a jednocześnie moŜe narazić projekt na narastające nakłady
nieuzasadnionej pracy.
Zagadnienie zgłaszania problemów często dotyka takŜe sfery psychologicznej.
Udziałowcy reprezentujący stronę klienta zazwyczaj nie mają skrupułów przy zgłaszaniu
defektów. Źródła wewnętrzne projektu, zwłaszcza sami programiści, miewają opory przed
ujawnianiem wykrytych przez siebie defektów w obawie przed automatycznym
przypisaniem do nich odpowiedzialności i przymusem jednoczesnego zaproponowania
rozwiązania. Sprawnie organizowany proces zbierania zgłoszeń o problemach w projekcie
musi koniecznie zapewniać potwierdzoną praktycznie niezaleŜność źródła problemu
od jego obsługi i rozwiązania.
3.2.2
Obsługa problemu
Formalnie zarejestrowany i moŜliwie kompletnie opisany problem rozpoczyna swój
właściwy cykl Ŝycia w obrębie projektu. WaŜnym aspektem całego procesu jest to, Ŝe
faktycznej obsłudze podlega nie tyle sam problem, co zbiór informacji zgromadzony na
jego temat. DostrzeŜony defekt lub potrzeba zmiany pozostaje niezmieniony od momentu
zaistnienia, modyfikacjom ulega jedynie jego opis, priorytet oraz decyzje podejmowane
w trakcie jego rozwiązywania. Zatem pod pojęciem obsługi rozumiany jest cały szereg
transformacji, jakim moŜe podlegać informacja o problemie, do których naleŜą:
•
wstępna ocena
•
analiza i zrozumienie istoty problemu
•
uszczegółowienie opisu
•
opracowanie planu działań
o decyzje
o przypisanie zasobów
o przydzielenie odpowiedzialności
o ustalenia priorytetu
•
rozwiązanie
Wszystkie wyŜej wymienione operacje mają na celu uzyskanie jak najbardziej
szczegółowej postaci opisu danego zagadnienia, które w efekcie ma prowadzić do
39
znalezienia optymalnego i moŜliwie szybkiego rozwiązania. Ostatni punkt, mianowicie
samo rozwiązanie danego problemu, okazuje się być na tyle istotny i specyficzny, iŜ został
opisany szerzej w odrębnej części rozdziału.
3.2.2.1
Wstępna ocena
Sprawny proces obsługi problemu powinien zawsze rozpoczynać się odpowiednią
weryfikacją słuszności samego zgłoszenia. Bez względu na dobór źródeł zawsze
napotkamy zgłoszenia niekompletne, niesłuszne i takie, które są efektem pomyłki lub
niewiedzy zgłaszającego. Jawne określenie źródła zgłoszenia jest szczególnie istotne w tej
fazie jego obsługi. Oczywisty jest fakt, iŜ problemy sygnalizowane przez programistów
z zespołu projektowego powinny być oceniane innym zestawem kryteriów niŜ
te pochodzące od końcowych uŜytkowników, czy w ogólności osób niebędących
bezpośrednio zaangaŜowanych w wytwarzanie oprogramowania. Bez względu na
pochodzenie problemu, musi on zostać wstępnie oceniony, najlepiej przez osobę niebędącą
autorem zgłoszenia (w przypadku, gdy zgłaszającym jest klient albo uŜytkownik jest to
wymóg wręcz konieczny). W praktyce rola oceniającego zgłoszenia zazwyczaj przypada,
w zaleŜności od rozmiaru projektu, kierownikowi projektu lub danego zespołu albo
specjalnie do tego celu oddelegowanej osobie. Generalną zasadą jest jednak, iŜ weryfikacja
zawsze odbywa się po stronie wykonawcy.
Zasadniczo krok ten ma na celu wyeliminowanie wszelkich problemów, których
dalsza egzystencja w projekcie jest w rzeczywistości nieuzasadniona oraz przyspieszenie
obsługi tych, których rozwiązanie nie wymaga przejścia całej skomplikowanej procedury
(np.
poprawki,
które
moŜna naprawić niewielkim
nakładem
pracy w trybie
natychmiastowym). Efektem pełnej wstępnej oceny danego zgłoszenie powinna być
jednoznaczna odpowiedź na następujące pytania:
•
Czy opisany problem rzeczywiście ma miejsce w systemie?
•
Czy opis problemu zawiera dostateczną ilość informacji do procesu jego obsługi?
•
Czy opisany problem mieści się w zakresie projektu?
Najprostsze do rozpatrzenia są oczywiście problemy, dla których uzyskujemy
skrajne odpowiedzi na powyŜsze pytania. Twierdząca odpowiedź na wszystkie wyŜej
postawione pytania oznacza, iŜ zgłoszony problem musi zostać uwzględniony w projekcie
i naleŜy bezwzględnie rozpocząć dalszy proces jego obsługi. Podobnie, w sytuacji, gdy na
40
większość pytań otrzymujemy negatywną odpowiedź zgłoszenie moŜe zostać uznane za
niewaŜne i zupełnie odrzucone. W przypadku braku części odpowiedzi decyzja o dalszym
losie danego zgłoszenia leŜy całkowicie w gestii osoby oceniającej. MoŜna w takiej
sytuacji przyjąć dwie drogi – odrzucić zgłoszenie wraz z powiadomieniem autora lub
przepuścić dany problem w nadziei, iŜ dalszy proces jego obsługi zaowocuje dalszym
skonkretyzowaniem i pojawieniem się stosownego rozwiązania. Pierwsze podejście nie
wyklucza ponownego zgłoszenia danego problemu, drugi zaś rodzi moŜliwość
późniejszego odrzucenia.
Opisany wyŜej proces wstępnej oceny problemu w ogólności powinien być
uruchamiany zawsze na wstępie jego obsługi. Praktyka pokazuje jednak, iŜ ocena nie moŜe
być uznana za krok jednorazowy, którego efekty są aktualne do końca cyklu Ŝycia
problemu. Dzieje się tak, poniewaŜ pomimo swojej pozornej prostoty rzetelna odpowiedź
na postawione pytania nie zawsze jest moŜliwa. Przykładowo w przypadku defektów,
stwierdzenie czy dany problem rzeczywiście istnieje wymaga od osoby oceniającej
wykonania kroków do powtórzenia problemu w systemie. Co jeśli taki opis nie został
dostarczony przez autora zgłoszenia albo opisany scenariusz nie doprowadził do opisanego
efektu? Czy zgłoszenie takie powinno zostać odrzucone, gdy nie mamy pewności czy
zostanie ono ponownie zarejestrowane z bardziej szczegółowym opisem? Z drugiej strony
przepuszczanie wszelkich zarejestrowanych problemów moŜe prowadzić do kuriozalnych
sytuacji, w których zespół projektowy rozwiązuje problemy, których istnienie nigdy nie
zostało do końca potwierdzone. Wszystko to po raz kolejny podkreśla istotę trafnego
doboru źródeł zgłoszeń oraz stosowania rozwagi przy procesie ich dalszej obsługi. Ocena
problemów powinna być zatem krokiem wykonywanym cyklicznie przy kaŜdej
aktualizacji informacji na temat danego zagadnienia.
Na koniec warto zaznaczyć, iŜ etap oceny jest szczególnie waŜny w przypadku
zgłoszeń zawierających prośby o zmianę. Potwierdzenie obecności defektu w zazwyczaj
jest relatywnie łatwe, w porównaniu do uzasadnienia konieczności wprowadzenia
postulowanej zmiany. Proces oceny tego typu próśb musi, zatem podlegać znacznie
surowszej kontroli juŜ na wstępie obsługi. Kwestią tą zajmuje się proces zarządzania
zmianami w projekcie informatycznym, o którym szerzej będzie mowa w Rozdziale
5 – „Zarządzanie problemami w projekcie informatycznym”.
41
3.2.2.2 Analiza zgłoszenia
Po zakończeniu etapu wstępnej oceny słuszności zgłoszenia i jego przepuszczeniu
do dalszej obsługi konieczne jest przeprowadzenie bardziej szczegółowej analizy. Na tym
etapie wiadomo juŜ, Ŝe zgłoszony problem stanowi realne zagroŜenie dla projektu, jednak
nieznany jest jeszcze stopień ani zakres jego negatywnego wpływu. Pierwszym celem
analizy jest próba oszacowania krytyczności problemu na podstawie dostarczonych
informacji oraz usystematyzowanie juŜ zgromadzonych danych na jego temat. Bardzo
często autor zgłoszenia dostarcza jedynie sygnał o fakcie istnienia konkretnego
rzeczywistego problemu, co moŜe okazać się niewystarczające w procesie jego dalszej
obsługi. Zgłoszenie po przejściu procesu analizy powinno nieść ze sobą więcej informacji.
W trakcie etapu analizy zgłoszenie powinno zostać pozbawione wszelkich nieścisłości oraz
błędów merytorycznych, których źródłem moŜe być niewiedza lub pomyłka zgłaszającego
(np. błędnie określony moduł systemu, w którym wykryto defekt). Wreszcie analiza
zgłoszenia moŜe skutkować nie tylko dodatkowymi informacjami na temat przyczyn
problemu, ale takŜe konkretnym zarysem lub nawet kompletną wizją rozwiązania.
Zasadniczo efektem procesu analizy zgłoszenia powinny być podstawy merytoryczne do
uszczegółowienie jego opisu.
3.2.2.3 Uszczegółowienie opisu
Opis problemu wstępnie ocenionego i przekazanego do dalszej obsługi nie moŜe
być zamknięty. Pomimo wszelkich starań autora zgłoszenia, zbiór informacji na temat
konkretnego problemu moŜe nie być, i z pewnością nie będzie, kompletny. Naturalną
koleją rzeczy jest zatem aktualizacja danych przy kaŜdym kroku obsługi zagadnienia.
KaŜda forma analizy problemu moŜe zaowocować dodatkowymi informacjami na jego
temat. KaŜda osoba mająca jakiś wpływ na stan danego problemu, a więc kierownicy
zespołów, testerzy, programiści, powinni mieć moŜliwość wzbogacenia jego opisu.
Kolejne weryfikacje problemu dają nam szersze spektrum danych na temat istoty
problemu, podobnie jak kolejne próby jego rozwiązania, nawet te nieudane. Nie bez
znaczenia, szczególnie w przypadku problemów złoŜonych i trudnych do powtórzenia, są
dalsze informacje od autora zgłoszenia, do których dostęp uzyskujemy np. w wyniku
bezpośredniej rozmowy. Istotne jest gromadzenie informacji mających jakąkolwiek
wartość merytoryczną przy dalszej obsłudze danego problemu. Kolejną grupą informacji
dodawanej do opisu problemu jest sama historia jego obsługi. Problemy obarczone długą
42
historią zmian opisu, odpowiedzialności itp. powinny zwrócić uwagę kierownika projektu,
jako zadania o potencjalnie podwyŜszonym priorytecie, być moŜe wymagające większego
nakładu zasobów. Jak juŜ wspomniano wcześniej, do opisu tego i innych aspektów
problemu konieczna jest odpowiednia struktura, mogąca przechowywać informacje oraz
proces ich zmiany w czasie.
3.2.2.4 Przypisanie zasobów i odpowiedzialności
Mając dostatecznie dobrze zdefiniowany problem moŜna przystąpić do kroków
mających na celu jego rozwiązanie. Najbardziej podstawowym i zarazem oczywistym
krokiem wydaje się podjęcie decyzji w sprawie jego dalszej obsługi, a więc przyjęcie
określonego planu działania wraz z przypisaniem do rozwiązania danego problemu
odpowiednich ludzi i zasobów. Problem opatrzony najlepszym moŜliwym opisem
pozostanie problemem, dopóki ktoś nie zajmie się jego rozwiązaniem. Sprawne
i jednoznaczne przydzielanie odpowiedzialności jest konieczne w celu utrzymania
płynności pracy nad projektem. Nieład w tej materii moŜe prowadzić do sytuacji, w której
jedne problemy rozwiązywane są niezaleŜnie przez kilka róŜnych członków zespołu
projektowego, podczas gdy inne leŜą odłogiem. Kierownik projektu odpowiedzialny za
podział zadań nie moŜe dopuszczać do sytuacji niejednoznacznych, w których próby
rozwiązania konkretnych problemów nie wiąŜą się z faktycznym przydzieleniem
odpowiedzialności. Z jednej strony wymaga to wprowadzenie do projektu odpowiedniej
dyscypliny („jeśli podejmujesz się próbie rozwiązania problemu to musisz wziąć za niego
odpowiedzialność”), z drugiej zaś musi się to wiązać z rozsądnym podejściem w kwestii
rezygnacji i zrzeczenia się odpowiedzialności za dany problem w razie poraŜki. Brak tego
ostatniego moŜe budzić niechęć pracowników do podejmowania z własnej inicjatywy
działań
w
kierunku
poprawienia
znanych
problemów.
Oczywiście
przydział
odpowiedzialności za rozwiązanie moŜe równieŜ być stosowany przez kierownika do
odgórnego podziału pracy w zespole.
3.2.2.5 Ustalenie priorytetu
Realizacja przedsięwzięcia informatycznego jest źródłem potencjalnie bardzo duŜej
liczby problemów. Ich napływ w postaci ujawniających się defektów i ciągle zgłaszanych
propozycji w praktyce nigdy nie ma końca, gdyŜ zawsze znajdzie się aspekt produktu,
który albo nie działa zgodnie z oczekiwaniami albo w wyniku ewolucji punktu widzenia
klienta staje się niepotrzebny i niefunkcjonalny w swojej obecnej postaci. Z drugiej strony
43
kaŜdy projekt informatyczny tworzony jest w ramach określonych granic, najczęściej
wyznaczanych przez zasoby, budŜet oraz ścisły harmonogram. Tego typu realne
ograniczenia w konfrontacji z próbami rozwiązania nie zawsze realnych problemów mogą
doprowadzić do powaŜnej destabilizacji całego przedsięwzięcia. Kierownik projektu nie
moŜe doprowadzić do sytuacji, w której większość zasobów pochłaniana jest przez
zadania, których wykonanie ma małe lub znikome znaczenie przy osiąganiu globalnego
celu. Dlatego tak niezmiernie waŜnym aspektem zarządzania procesem obsługi problemów
jest ich odpowiednia kategoryzacja pod względem waŜności. Przypisanie priorytetu
problemowi jest, obok przydzielenia odpowiedzialności za niego, jednym z najbardziej
podstawowych i krytycznych kroków, jaki naleŜy podjąć przed rozpoczęciem procesu jego
obsługi. Zarządzanie problemami z wyraźnie zaznaczonym stopniem „krytyczności” dla
projektu z definicji staje się bardziej efektywne niŜ w przypadku braku tego typu
informacji. Oczywiście kwestia przyjętego systemu priorytetowania zadań jest ściśle
zaleŜna od charakteru projektu oraz wymagań klienta. Kolejną waŜną cechą priorytetu jest
często jego subiektywny charakter (uŜytkownik zgłaszający problem w oprogramowaniu,
którego uŜywa zawsze oceni jego waŜność wyŜej niŜ programista, który tego typu
problemów musi rozwiązać wiele) oraz płynność - w miarę rozwoju produktu zmienia się
hierarchia celów (np. we wczesnym etapie implementacji dominują kwestie związane
z niezawodnością i wydajnością, z kolei w miarę zbliŜania się daty wdroŜenia, odpowiedni
priorytet zyskują zadania związane z ergonomią i estetyką interfejsu uŜytkownika).
Podobnie jak kwestia przydziału odpowiedzialności i zasobów, zadanie określenia
priorytetu zazwyczaj spoczywa w gestii kierownika projektu lub zespołu. Sposób
klasyfikacji waŜności problemów będzie szczegółowo omawiany przy okazji konstrukcji
modelu problemu w następnym rozdziale.
3.2.3
Rozwiązanie problemu
Proces obsługi problemu intuicyjnie powinien kończyć się jego rozwiązaniem. Przy
definiowaniu pojęcia rozwiązania problemu w przypadku projektów informatycznych
naleŜy niestety na wstępie odrzucić pozytywne nacechowanie tego słowa. Sposób
rozwiązania konkretnego problemu niekoniecznie musi się bowiem wiązać z osiągnięciem
celów zasugerowanych przez zgłoszenie – wykryty defekt nie musi zostać w pełni
usunięty, a prośba zmiany moŜe zostać całkowicie odrzucona. W związku z powyŜszym
w dalszej części mojej pracy w pojęciu rozwiązania problemu większy nacisk będzie
44
kładziony na końcowy stan, w jakim się znajduje dane zgłoszenie, a nie faktycznie
wykonane czynności zaradcze. Przykładowo pod pojęciem problemu „naprawionego”
naleŜy rozumieć problem, który został uznany za rzeczywisty i usunięty z produktu, z kolei
problem „odrzucony” to taki, wobec którego w wyniku konkretnej decyzji nie zostaną
podjęte Ŝadne dalsze kroki. W obu przypadkach rozwiązaniem problemu jest konkretny
stan zgłoszenia, ale tylko w przypadku problemu „naprawionego” moŜna mówić
o jakichkolwiek wykonanych czynnościach naprawczych.
Rysunek 3-2 MoŜliwe rozwiązania problemu (źródło własne)
Definiując rozwiązanie problemu mamy do dyspozycji cały wachlarz moŜliwości,
od rozwiązań poŜądanych o nacechowaniu pozytywnym (naprawienie defektu,
uwzględnienie zmiany), aŜ po rozwiązania nieosiągające sugerowanego efektu o wybitnie
negatywnym wydźwięku (odrzucenie zmiany, niemoŜność naprawy defektu). Rysunek 3-2
przedstawia schematycznie wymienione moŜliwości, a dyskusję poszczególnych
rozwiązań problemów zawiera punkt 3.3.2.
3.3
Diagram stanu problemu
Proces
przepływu
konkretnego
zagadnienia
przez
projekt
moŜe
zostać
zamodelowany w postaci diagramu stanów. Jak wiadomo diagram taki określa ciąg stanów
45
przyjmowanych przez konkretny obiekt w odpowiedzi na zdarzenia. W naszym przypadku,
stanami problemu są kolejne etapy jego obsługi (opisane w punkcie 3.2), z kolei
zdarzeniami inicjującymi poszczególne przejścia są czynności podejmowane w trakcie tej
obsługi. Znając moŜliwe przejścia pomiędzy konkretnymi stanami moŜna podjąć próbę
skonstruowania grafu obrazującego proces obsługi problemu w projekcie informatycznym.
Diagram na Rysunku 3-3 stanowi próbę wizualizacji takiej maszyny stanów.
3.3.1
MoŜliwe stany problemu
Zaprezentowany graf stanów stanowi rozszerzenie opisanego na początku tego
rozdziału ogólnego cyklu Ŝycia problemu. PoniŜej znajduje się lista stanów, przez jakie
przechodzi problem, wraz z szczegółowym opisem kaŜdego z nich oraz przykładami
praktycznymi.
3.3.1.1 Problem niepotwierdzony
KaŜdy pojawiający się problem rozpoczyna, jawnie lub niejawnie, swój cykl Ŝycia
od tego statusu. Problem niepotwierdzony jest zagadnieniem, które zostało zarejestrowane,
ale jeszcze nie zostało poddane procesom weryfikacyjnym. W praktyce oznaczać to moŜe,
Ŝe np. defekt został niedawno dodany do rejestru problemów przez uŜytkownika
oprogramowania, jednak jego faktyczne istnienie nie zostało potwierdzone przez
reprezentanta wykonawcy. Problem taki pozostaje niepotwierdzony do momentu, gdy
osoba
do
tego
upowaŜniona
podejmie
decyzję
o
dalszym
losie
zgłoszenia.
Niepotwierdzony problem moŜe zostać od razu rozwiązany z negatywnym skutkiem
(odrzucony lub uznany za nieprawidłowy np. w przypadku stwierdzenia pomyłki
zgłaszającego). Zdecydowanie częstszym przypadkiem jest jednak sytuacja, gdy zostaje on
zweryfikowany i dodany do puli problemów otwartych (patrz 3.3.1.3) w celu dalszej
obsługi. W szczególnym przypadku problem moŜe zostać zweryfikowany i rozwiązany
(patrz 3.3.1.6) pozytywnie w jednym kroku np. gdy osoba weryfikująca jest w stanie sama
szybko wprowadzić odpowiednią poprawkę do produktu.
3.3.1.2 Problem oceniany
Pod pojęciem oceny mieści się cały proces wstępnej analizy zgłoszenia obejmujący
jego zrozumienie, wstępną ocenę oraz potwierdzenie autentyczności, czyli stwierdzenie
czy zgłoszenie opisuje rzeczywisty problem. Zgłoszenie będące w tym stanie naleŜy
rozumieć jako zidentyfikowane przez osobę odpowiedzialną za jego weryfikację, ale
jeszcze niedopuszczone do dalszej obsługi.
46
ja
ac ci
ik ś
yf no ia
er w an
W ra iąz
p
po ozw
r
Rysunek 3-3 - Diagram stanów problemu (źródło własne)
47
Dla autora zgłoszenia jest to sygnał, Ŝe problem został zauwaŜony i przechodzi
proces oceny. Warto wspomnieć, Ŝe czas przebywania danego zgłoszenia w tym stanie
moŜe być cenną wskazówką przy późniejszym przydzielaniu do niego ludzi, zasobów oraz
priorytetu.
3.3.1.3 Problem otwarty
Problem, który pomyślnie przeszedł proces weryfikacyjny staje się problemem
otwartym. W praktyce oznacza to, iŜ zgłoszone zagadnienie zostało uznane przez
kompetentne osoby za problem faktycznie wymagający dalszej obsługi. Podział zagadnień
na te jeszcze „niepotwierdzone” oraz potwierdzone-otwarte w skuteczny sposób pozwala
kontrolować jakość informacji gromadzonych w rejestrze problemów projektu. Zespół
projektowy koncentruje się tylko i wyłącznie na drugiej grupie, czyli zagadnieniach
i defektach, które takiej uwagi rzeczywiście wymagają. Problem, który przeszedł etap
wstępnej weryfikacji i został uznany za otwarty powinien juŜ do końca swojego cyklu
Ŝycia podlegać regułom obiegu problemu w organizacji. Oznacza to przede wszystkim to,
Ŝe w przeciwieństwie do problemów niepotwierdzonych, kaŜda decyzja w jego sprawie
powinna pozostawiać ślad w dokumentacji problemu. Warto zaznaczyć, iŜ problemy
zgłaszane przez osoby odpowiednio upowaŜnione w projekcie (np. programistów,
testerów) mogą ze względu na kompetencje tych osób, automatycznie przechodzić proces
weryfikacji w momencie zgłoszenia, tym samym stając się otwartymi od początku swojego
cyklu Ŝycia. Jedynym moŜliwym dalszym krokiem dla problemu otwartego jest
przypisanie mu odpowiedzialności (patrz 3.3.1.4).
3.3.1.4 Problem przypisany
Zgłoszenie osiąga ten stan, gdy zostanie przypisane do konkretnej osoby.
W momencie przypisania, odpowiedzialność za dalszy postęp w obsłudze danego
problemu spada na tę osobę. Tym samym problem otwarty, któremu został przydzielony
„opiekun” w pewnym zakresie przestaje być problemem ogólnie dostępnym. Oczywiście
nadal pozostaje on widoczny dla pozostałych członków zespołu, sygnalizowany zostaje
jedynie fakt, iŜ rozwiązaniem konkretnego zagadnienia od tego momentu zajmuje się
konkretna osoba. Istotne jest to, Ŝe przypisanie odpowiedzialności nie ma charakteru
trwałej decyzji i moŜe ulec wielokrotnej zmianie w trakcie cyklu Ŝycia danego problemu.
Problemy mogą być przypisywane odgórnie (np. kierownik projektu rozdziela zadania) lub
dobrowolnie (członek zespołu podejmuje się rozwiązania z własnej woli). W szczególnych
48
przypadkach moŜe równieŜ zaistnieć automatyczny przydział problemów na bazie ich
wstępnej klasyfikacji (np. wszystkie problemy w warstwie danych systemu przydzielamy
liderowi zespołu od bazy danych). Bez względu na rodzaj i motywacje przydziału
odpowiedzialności jest to mechanizm konieczny do zachowania porządku w rejestrze
problemów. Przypisanie odpowiedzialności jest takŜe ostatnim „biurokratycznym”
krokiem w procesie obsługi zagadnienia – wszelkie kolejne kroki mają na celu juŜ
faktyczne rozwiązanie zagadnienia. Problem przypisany moŜe zostać rozwiązany (patrz
3.3.1.6), przypisany innej osobie lub w razie rezygnacji obecnego „opiekuna” moŜe
powrócić do puli problemów otwartych.
3.3.1.5 Prace w toku
Stan ten jawnie określa, Ŝe prace nad rozwiązaniem danego problemu są juŜ
rozpoczęte. Jest to sygnał dla innych uczestników procesu zarządzania problemami,
a w szczególności dla warstwy kierowniczej tego przedsięwzięcia, Ŝe zgłoszenie przeszło
juŜ odpowiedni proces decyzyjny oraz, Ŝe osoba za nie odpowiedzialna podjęła juŜ kroki
zmierzające do osiągnięcia rozwiązania. Warto jednak zauwaŜyć, Ŝe sam stan nie
precyzuje, na jakim etapie zaawansowania są owe prace. Jest to specyficzny stan
problemu, który moŜe zostać nadany tylko i wyłącznie przez osobę, do której aktualnie jest
przypisany problem. Oczywiste jest takŜe, Ŝe prace raz rozpoczęte mogą zostać przerwane
albo doprowadzić do konkretnego rozwiązania danego problemu.
3.3.1.6 Problem rozwiązany
Uzyskanie przez problem statusu rozwiązanego oznacza, iŜ zapadła konkretna
decyzja w jego sprawie oraz zostały podjęte ewentualne kroki wprowadzające ją w Ŝycie
(np. usunięcie defektu z testowej wersji systemu). Rozwiązanie problemu moŜe oznaczać
usunięcie defektu lub wprowadzenie poŜądanej zmiany i udostępnienie efektów pracy do
weryfikacji (np. poprzez przekazanie nowej wersji systemu do testowania). NaleŜy jednak
pamiętać, Ŝe rozwiązaniem problemu moŜe być takŜe jego odrzucenie. Biorąc pod uwagę
mnogość moŜliwych rozwiązań (patrz punkt 3.3.2), decyzja rozwiązująca dane zagadnienie
nie jest kwestią trywialną i wiąŜe się z dodatkowym uszczegółowieniem stanu problemu.
Samo stwierdzenie, Ŝe problem osiągnął opisywany stan nie mówi nam nic o charakterze
ani jakości rozwiązania. Bez względu na charakter decyzji, od tego momentu rozwiązanie
(oraz ewentualne efekty jego wprowadzenia do produktu) oczekuje na weryfikację przez
49
osoby do tego upowaŜnione. Dopóki proponowane rozwiązanie zagadnienia nie zostanie
zweryfikowane problem moŜe zostać powtórnie otworzony w celu alternatywnej obsługi.
3.3.1.7 Problem weryfikowany
W rzeczywistości stan ten oznacza, Ŝe nie sam problem jest weryfikowany, ale jego
zaproponowane i ewentualnie wprowadzone w Ŝycie rozwiązanie. Zgłoszenie będące
w tym stanie niesie ze sobą informację przede wszystkim dla osoby odpowiedzialnej za
dane rozwiązanie. Jest to sygnał, iŜ dostarczone rozwiązanie (lub decyzja o jego braku) jest
w trakcie uzyskiwania akceptacji i tym samym nie powinno ulegać dalszym
modyfikacjom. Jest to zatem stan przejściowy, którego jedynym logicznym następstwem
jest zaakceptowanie rozwiązania (patrz 3.3.1.8) lub ponowne otwarcie danego problemu,
czyli innymi słowy odrzucenie dostarczonego rozwiązania (lub jego braku).
3.3.1.8 Problem zweryfikowany
Problem zweryfikowany to taki, którego rozwiązanie zostało zaakceptowane przez
odpowiednio do tego upowaŜnione osoby w projekcie. Oznacza to, iŜ osoby te zapoznały
się z zaproponowanym i wprowadzonym w Ŝycie rozwiązaniem problemu i uznały, iŜ jest
ono wystarczające w kontekście opisu problemu. Zagadnienie pozostaje w tym stanie do
czasu jego ostatecznego zamknięcia, które następuje dopiero w momencie wprowadzenia
rozwiązania do oficjalnej wersji produktu (np. w chwili wydania kolejnej wersji
oprogramowania lub wypuszczenia uaktualnienia do oficjalnej wersji systemu).
3.3.1.9 Problem ponownie otwarty
Problem ponownie otwarty, to taki, dla którego zostało juŜ zaproponowane
i niekiedy takŜe wprowadzone w Ŝycie konkretne rozwiązanie, jednak w skutek jego
weryfikacji zostało one uznane za niepoprawne lub niewystarczające. Przykładowo
problem, który został w pierwszym obiegu obsługi „rozwiązany” przez uznanie go za
niemoŜliwy do powtórzenia, moŜe zostać powtórnie otwarty, w momencie dostarczenia
większej ilości informacji na jego temat. Problemy ponownie otwarte powracają do puli
zagadnień otwartych. Pod względem dalszej obsługi nie róŜnią się niczym od tych
pierwszych, jednak informacja o ich powrocie do obiegu musi zostać zachowana, stąd
wyodrębnienie oddzielnego stanu. Warto w tym miejscu zaznaczyć, iŜ pojedynczy problem
moŜe teoretycznie ulec wielokrotnemu cyklowi rozwiązania i ponownego otwarcia.
50
3.3.1.10 Problem zamknięty
Stan ostateczny i docelowy, do którego powinien dąŜyć kaŜdy zarejestrowany
problem w trakcie swojego cyklu Ŝycia w projekcie. Bez względu na wynikowe
rozwiązanie, problem zamknięty to taki, którego rozwiązanie zostało uznane za słuszne
i poprawne oraz, którego efekty zostały wprowadzone do oficjalnej wersji produktu (tylko
w przypadku rozwiązań „pozytywnych”). Zasadniczo problemy o statusie zamkniętym
zostają wyeliminowane z dalszego obiegu informacji w rejestrze zagadnień. Czasem
zdarza się konieczność ich ponownego otwarcia (np. w sytuacji, gdy pozornie
zlikwidowany defekt ujawni się ponownie), dlatego teŜ w Ŝadnym wypadku nie naleŜy
eliminować z rejestru śladu o ich wystąpieniu, ani historii ich obsługi.
3.3.1.11 Problem archiwalny
Zamknięte problemy mogą podlegać archiwizacji w celu zasilania ogólno pojętej
bazy wiedzy organizacji. Jak w kaŜdej innej dziedzinie Ŝycia, przeszłe doświadczenia
mogą stanowić podstawę podejmowania szybszych i trafniejszych decyzji w przyszłości.
Celem archiwizacji zgłoszeń jest z jednej strony gromadzenie wiedzy dla przyszłych
projektów, a z drugiej strony uporządkowanie bazy zgłoszeń poprzez oddzielenie
zagadnień definitywnie zamkniętych od tych, które mogę jeszcze ulec ponownemu
otwarciu. W ogólności moŜna jednak przyjąć załoŜenie, Ŝe zgłoszenia powinny podlegać
archiwacji dopiero po zamknięciu danego projektu.
3.3.2
MoŜliwe rozwiązania problemu
Jak juŜ wspomniano wcześniej, rozwiązanie problemu w projekcie informatycznym
moŜe przyjmować szereg róŜnych postaci. PoniŜej znajduje się szersze spojrzenie na ten
temat, w którym zaproponowanych zostało 6 klas rozwiązań. KaŜda z nich została
opatrzona stosownym opisem oraz przykładami ich występowania w rzeczywistych
projektach.
3.3.2.1 Problem naprawiony
Jedyne
rozwiązanie
o
stricte
pozytywnym
znaczeniu.
Problem
opisany
w zgłoszeniu został w rozumieniu autora rozwiązania całkowicie wyeliminowany.
W praktyce moŜe oznaczać to, Ŝe defekt został usunięty w nowej wersji produktu albo do
jego nowej wersji zostało wprowadzone ulepszenie, o które prosił zgłaszający. Problem
naprawiony musi jeszcze zostać zweryfikowany pod kątem jakości samego rozwiązania
i ewentualnie zamknięty po scaleniu rozwiązania z oficjalną wersją produktu.
51
3.3.2.2 Duplikat
Zgłoszony problem został zidentyfikowany jako duplikat juŜ istniejącego, jeszcze
nie rozwiązanego, problemu. W praktyce moŜe oznaczać to, iŜ kolejny uŜytkownik
systemu zgłasza wystąpienie znanego juŜ defektu lub opisany problem stanowi fragment
innego zagadnienia (podproblem). Napływ wielu identycznych lub podobnie brzmiących
zgłoszeń jest typowy w momencie aktywacji szczególnie uciąŜliwego defektu
w ogólnodostępnym i wdroŜonym systemie. Oznaczenie problemu jako duplikat wymaga
skojarzenia go z oryginalnym zgłoszeniem, dlatego informacja o duplikacie powinna
zostać umieszczona jako komentarz do prawidłowego zgłoszenia. Oczywiście w momencie
rozwiązania
pierwszego,
oryginalnego,
problemu
wszystkie
jego
duplikaty
(takŜe podproblemy) powinny zostać opatrzone odpowiednią informacją.
3.3.2.3 Problem nierozwiązywalny
Problem opisany w zgłoszeniu nigdy nie zostanie rozwiązany, przynajmniej nie
w kontekście posiadanego aktualnie opisu. Przyczyny takiego stanu rzeczy mogą być
rozmaite, jednak ich cechą wspólną jest to, iŜ są one niezaleŜne od wykonawcy. Tego typu
decyzja musi zawsze być poparta odpowiednią argumentacją. Najczęściej problemy
zyskują status nierozwiązywalnych wskutek ograniczeń technicznych narzuconych przez
technologię wytwarzania systemu (np. klient prosi o menu kontekstowe dostępne pod
prawym przyciskiem myszy w systemie opartym na technologii WWW). Warto zaznaczyć,
Ŝe zgłoszenia defektów zazwyczaj z oczywistych względów nie mogą zostać uznane za
nierozwiązywalne, co praktycznie rezerwuje ten status tylko dla potrzeb zmian.
3.3.2.4 Problem odrzucony
Rozwiązanie w praktyce zarezerwowane dla Ŝądań zmian przez klienta rzadko,
kiedy stosowane w przypadku zgłoszeń o wystąpieniu błędu. W praktyce oznacza ono, iŜ
problem poruszony w zgłoszeniu został uznany za nierealny lub niewykonalny w obecnie
zdefiniowanych ramach projektu. Zgłoszenie tego typu najczęściej dotyczy usprawnień
systemu, których wykonanie nie jest przewidziane w ramach projektu lub, których
wprowadzenie mogłoby zachwiać budŜetem i harmonogramem przedsięwzięcia.
Zgłoszenia tego typu najczęściej juŜ na etapie wstępnej weryfikacji i klasyfikacji
otrzymują bardzo niski priorytet. Odrzucone problemy mogą następnie zostać zamknięte
i zapomniane lub w razie wyraźnego nacisku klienta oczekiwać na podniesienie ich
52
priorytetu. Odrzucenie problemu róŜni się od uznania go za nierozwiązywalny tym, iŜ jest
efektem świadomej decyzji wykonawcy, a nie skutkiem np. ograniczeń technicznych.
3.3.2.5 Problem niekompletny
W wyniku procesu obsługi problemu, osoba za niego odpowiedzialna stwierdza, Ŝe
obecny stan wiedzy na jego temat jest niewystarczający do osiągnięcia zadowalającego
rozwiązania. W praktyce tego typu sytuacja dotyczy najczęściej defektów i oznacza, Ŝe na
podstawie opisu problemu nie jest moŜliwe odtworzenie skutków opisanych w zgłoszeniu.
Ten status rozwiązania przypisywany jest zgłoszonym defektom, gdy próby powtórzenia
błędu zakończyły się fiaskiem, a kod źródłowy nie pozwala znaleźć powodu, dla którego,
zostało zaobserwowane dane zachowanie systemu. W sytuacji takiej jedną z moŜliwości
jest to, Ŝe zgłoszenie jest pomyłką, dotyczy faktycznie nieistniejącego problemu
i niesłusznie przeszło proces weryfikacji. Mniej optymistyczna wersja zakłada, Ŝe problem
naprawdę tkwi w systemie, jednak jego wykrycie ani tym bardziej usunięcie jest
niemoŜliwe w chwili obecnej. Najczęściej spotykaną reakcją na tego typu zgłoszenia jest
ich zamknięcie, w przekonaniu, Ŝe jeśli problem rzeczywiście istnieje to prędzej czy
później i tak wróci do rejestru w postaci kolejnego, moŜliwie bardziej szczegółowego
zgłoszenia. Drugim wyjściem jest „zamroŜenie” zgłoszenia na etapie weryfikacji
rozwiązania i jeśli w późniejszym okresie pojawią się dodatkowe informacje, zmiana stanu
i powrót do jego dalszej obsługi.
3.3.2.6 Problem nieprawidłowy
Pomimo istnienia procesu wstępnej weryfikacji kaŜdego zgłoszenia, często
dochodzi do sytuacji, kiedy do właściwego obiegu problemów przedostają się zgłoszenia
sformułowane nieprawidłowo lub dotyczące kwestii niezwiązanych z realizowanym
projektem. W praktyce są to zgłoszenia będące często efektem niewiedzy uŜytkowników
i błędnego uŜycia systemu. Wychwytywanie tego typu problemów i ocena ich rozwiązań
w postaci etykiety „nieprawidłowy” jest procesem czasochłonnym, dlatego tym bardziej
warto tego typu przypadki rejestrować, w celu późniejszego przedstawienia klientowi
bilansu nakładów pracy.
53
3.4
Role w procesie obsługi problemów
W trakcie całego procesu obsługi pojedyncze zgłoszenia zmieniają swój stan pod
wpływem decyzji konkretnych osób zaangaŜowanych w projekt. Przy definiowaniu cyklu
Ŝycia problemu nie moŜna pomijać ról, jakie pełnią te osoby, ani zakresu podejmowanych
przez nie decyzji. Na potrzeby analizy tego aspektu procesu obsługi problemów moŜna
zdefiniować następujące 4 grupy osób bezpośrednio zaangaŜowanych w proces wytwórczy
oprogramowania:
•
klient – w ogólności odbiorca produktu lub udziałowiec, pod pojęciem klienta
naleŜy takŜe rozumieć docelowego uŜytkownika systemu
•
kierownik – przedstawiciel kierownictwa projektu po stronie dostawcy
oprogramowania, osoba odpowiedzialna za przebieg i organizację projektu,
w przypadku mniejszych projektów zazwyczaj jest to kierownik projektu, z kolei
dla większych przedsięwzięć moŜe to być osoba oddelegowana do zarządzania
zmianą albo kierownik ds. jakości
•
wykonawca – osoba bezpośrednio odpowiedzialna za produkcję oprogramowania,
do tej grupy zaliczają się zarówno analitycy, projektanci jak i programiści
•
tester
–
osoba
odpowiedzialna
za
weryfikację
poprawności
działania
oprogramowania, moŜe to być zarówno przedstawiciel dostawcy oprogramowania
jak i klienta, którego zadaniem jest sprawdzenie jakości dostarczanego produktu
PowyŜsza klasyfikacja jest oczywiście bardzo ogólna i ma za zadanie jedynie
nakreślenie róŜnych stron zaangaŜowanych bezpośrednio w proces obsługi problemów
w projekcie informatycznym. Wszystkie wymienione grupy stanowią udziałowców
projektu, których punkty widzenia naleŜy uwzględnić. NaleŜy jednak zaznaczyć, Ŝe
pojedyncza osoba moŜe reprezentować kilka spośród wymienionych ról (np. wykonawca
moŜe być takŜe testerem, podobnie jak klient). Istnienie takich powiązań pomiędzy rolami
nie zmienia jednak faktu, iŜ kaŜda z nich musi być rozpatrzona oddzielnie, jako
autonomiczna jednostka mająca swój udział i zakres kompetencji w procesie obsługi
problemów. Rysunek 3-4 przedstawia umiejscowienie wyŜej zdefiniowanych ról na
wcześniej zaproponowanym diagramie stanów problemu. Diagram ten definiuje, jakie
przejścia pomiędzy stanami mogą być efektem decyzji i działań poszczególnych ról
zaangaŜowanych w projekt.
54
KLIENT
WYKONAWCA
TESTER
KIEROWNIK
KIEROWNIK
NIEPOTWIERDZONY
TESTER
KIEROWNIK
TESTER
OCENIANY
KIEROWNIK
TESTER
OTWARTY
KIEROWNIK
KIEROWNIK
KIEROWNIK
WYKONAWCA
WYKONAWCA
TESTER
KIEROWNIK
PRZYPISANY
WYKONAWCA
WYKONAWCA
PRACE W TOKU
WYKONAWCA
WYKONAWCA
KIEROWNIK
WYKONAWCA
ROZWIĄZANY
TESTER
WYKONAWCA
KLIENT
TESTER
TESTER
WERYFIKOWANY
KLIENT
KLIENT
KLIENT
KIEROWNIK
TESTER
PONOWNIE OTWARTY
KIEROWNIK
ZWERYFIKOWANY
KLIENT
KIEROWNIK
KIEROWNIK
KLIENT
TESTER
ZAMKNIĘTY
KIEROWNIK
ARCHIWALNY
Rysunek 3-4 Role w procesie obsługi problemu (źródło własne)
55
3.5
Podsumowanie
Celem niniejszego rozdziału było zaprezentowanie w sposób moŜliwie zwięzły
i formalny cyklu Ŝycia problemu. W celu osiągnięcia wystarczającego poziomu ogólności,
tymczasowo w trakcie rozwaŜań porzucony został zaprezentowany w Rozdziale 2 podział
problemów na defekty oraz zmiany – problemy traktowane są tutaj jako jednakowe
zagadnienia, gdyŜ zasadniczo ich cykl Ŝycia przebiega bardzo podobnie. Wszystkie podjęte
tutaj kroki mają na celu przygotowanie gruntu pod budowę modelu problemu, którego
przedmiotem jest Rozdział 4 – „Model problemu”.
56
4.
Model problemu
„The mere formulation of a problem is far more essential than its solution”
Albert Einstein
4.1
Wprowadzenie
Nawet najlepiej napisany program nie jest wolny od defektów. Celem procesu
testowania jest ich zdiagnozowanie i poinformowanie autorów systemu o ich zaistnieniu.
Defektu nie wystarczy jednak po prostu zasygnalizować, trzeba to jeszcze zrobić
efektywnie. MoŜna zaryzykować stwierdzenie, Ŝe kaŜdy projekt informatyczny napotka na
swojej drodze, co najmniej jedno złe i niekompletne zgłoszenie defektu. Zmorą kaŜdego
przedsięwzięcia informatycznego są zgłoszenia, które:
•
nic nie mówią lub nie mają sensu
•
nie zawierają wystarczających informacji lub zawierają błędne informacje
•
okazują się być pomyłkami uŜytkownika lub błędami innych programów
Aby uniknąć tego typu nieporozumień i maksymalnie usprawnić proces
zarządzania problemami w projekcie, konieczne staje się sprecyzowanie, co składa się na
dobre zgłoszenie problemu. Celem niniejszego rozdziału jest identyfikacja kluczowych
informacji, jakie powinny się pojawić w rejestrze zgłoszeń wraz z pojawieniem się
problemu oraz zaproponowanie struktury danych, która takie informacje jest w stanie
przenosić, przy jednoczesnym uwzględnieniu cyklu Ŝycia problemu zaprezentowanego
w Rozdziale 3.
Zaproponowana struktura opisu problemu stanowi syntezę praktycznych rozwiązań
zastosowanych w narzędziach takich jak Bugzilla ([BUG2005]), Mantis Bug Tracker
([MAN2005]) oraz wiedzy wydobytej ze źródeł ksiąŜkowych. Zaprezentowane w rozdziale
zagadnienia i pojęcia oparte są w znacznym stopniu na przytaczanej juŜ wcześniej
literaturze poruszającej problem zarządzania zmianą w projektach informatycznych
([BAY2001], [GOR2000], [CADL2000], [LEST2000], [SZEJ2002]).
4.2
Scenariusz zgłaszania problemu
Problemy są zgłaszane z jednej bardzo prostego powodu - poniewaŜ chcemy, aby
ich rozwiązanie zostało uwzględnione w procesie wytwórczym, a ich negatywne skutki
zniwelowane, jeśli nie całkowicie to przynajmniej do akceptowalnego poziomu. Wykryty
57
problem moŜe mieć rozmaite przyczyny – mógł powstać z winy programisty, jak równieŜ
moŜe wynikać z niewiedzy zgłaszającego. Istotą dobrze zgłoszonego problemu nie jest
jednak wskazanie winowajcy, a dostarczenie maksimum informacji potrzebnych
w procesie jego obsługi. Najgorsze z moŜliwych zgłoszenia ograniczają się do
lakonicznego stwierdzenia: ,,to nie działa”. Tego typu zgłoszenia mogą jedynie
sygnalizować obecność usterki czy potrzeby zmiany, ale na pewno prędzej czy później
wrócą do osoby zgłaszającej z dopiskiem „proszę doprecyzować”. Jedną z najlepszych
metod zgłaszania defektów jest osobiste pokazanie ich programiście, jednak często jest to
niemoŜliwe ze względu na rozproszenie zespołów wytwórczych. Wówczas nie pozostaje
nic innego, jak opisanie czynności prowadzących do błędnego zachowania aplikacji, krok
po kroku.
Pierwszym etapem na drodze precyzowania problemu jest określenie czy
raportujemy wystąpienie błędu, problem związany z infrastrukturą systemu, czy teŜ
postulujemy rozszerzenie oprogramowania, a więc dodanie nowej cechy, która rozszerza
jego funkcjonalność lub jakość. Od tego zaleŜy nie tylko priorytet zgłoszenia, ale równieŜ
sama struktura jego opisu. Oczywiste jest, Ŝe usterki usuwane są w pierwszej kolejności,
a potem moŜe znajdzie się czas na realizację ulepszeń. W tym miejscu, niejako mimo woli,
wyłania się problem kategoryzacji problemów, o którym szerzej będzie mowa w dalszej
części rozdziału.
Przechodząc do opisu problemu naleŜy rozpocząć od ogólnego opisu jego istoty.
Następnie przystępujemy do odtwarzania sytuacji, gdzie następuje drobiazgowy opis
wykonanych czynności. Precyzja w tym miejscu jest niezmiernie waŜna, poniewaŜ często
nawet drobna zmiana w scenariuszu, prowadzi do odmiennych rezultatów. Dla programisty
niezwykle istotny jest precyzyjny opis, poniewaŜ dostarcza on więcej danych niŜ czasem
wydaje się uŜytkownikom. Dokładny opis błędu słuŜy równieŜ samym testerom, którym
często zdarza się powracać do własnych zgłoszeń po upływie czasu. W takich sytuacjach
niejednokrotnie trudno jest zrozumieć sens wypowiedzi, która w momencie tworzenia
wydawała się oczywista. Nie bez znaczenia są tutaj takŜe osoby, które w przyszłości
z jakiś przyczyn muszą przejąć efekty prac poprzedniego zespołu.
Na proces testowania i opisu problemów ma równieŜ wpływ specyfika samego
produktu, jego środowisko oraz kontekst uŜycia. Przykładowo, jeśli testowaniu podlegają
systemy
wielodostępne,
w
których
poszczególni
uŜytkownicy
posiadają
róŜne
58
uprawnienia, istotne jest równieŜ zaznaczenie, dla jakiego zestawu uprawnień wystąpił
błąd. W przypadku systemów internetowych, waŜny jest system operacyjny, na którym
przeprowadzamy testy, jak równieŜ przeglądarka internetowa oraz jej wersja.
4.3
Podstawowe atrybuty problemu
Aby uniknąć chaosu i sprawnie ewidencjonować pojawiające się w projekcie
problemy, osoby uŜytkujące system (uŜytkownicy, testerzy) powinni dokumentować
napotkane problemy powstałe podczas działania oprogramowania w specjalnie do tego
przeznaczonej strukturze danych. Po przeanalizowaniu wyŜej opisanego scenariusza oraz
mając na uwadze cykl Ŝycia problemu zaprezentowany w poprzednim rozdziale moŜna
przystąpić do definiowania tego typu struktury.
Generalną zasadą powinno być, iŜ na kaŜdy napotkany problem powinno przypadać
osobne zgłoszenie. Przez analogię do tradycyjnych archiwów, rejestr problemów
w projekcie informatycznym moŜe być traktowany jako swego rodzaju archiwum
dokumentów, w którym kaŜde zgłoszenie posiada własną „teczkę”. Zbiory takiego
archiwum muszą być w jakiś sposób uporządkowane, aby umoŜliwić ich odszukiwanie
według zadanych kryteriów. PoŜądaną cechą archiwum jest to, aby kaŜdy dokument w nim
zawarty miał podobną, standardową strukturę. Oczywiście realizacja rejestru problemów
w postaci papierowej moŜe spełnić swoje zadanie jedynie w przypadku bardzo małych
projektów. W przypadku przedsięwzięć o większej skali konieczne jest wprowadzenie
wsparcia informatycznego w postaci dedykowanego narzędzia, w którym miejsce
papierowych dokumentów zastępują dane gromadzone w odpowiednich strukturach,
a proces ich wypełniania odbywa się za pomocą formularzy, którego przykładową postać
przedstawia Rysunek 4-1.
Zaprezentowany formularz stanowi jedynie propozycję i zawiera tylko podstawowy
zakres informacji, jaki wydaje się konieczny do sprawnego gromadzenia danych na temat
problemu. Warto w tym miejscu zaznaczyć, Ŝe przedstawiony zakres informacji
o problemie obejmuje jedynie dane konieczne do jego identyfikacji i moŜliwie pełnego
opisu, a jego zasadniczym zadaniem jest umoŜliwienie uŜytkownikowi systemu (klientowi,
kierownikowi, testerowi, czy wykonawcy) zarejestrowanie w bazie zgłoszeń zaistnienia
konkretnego problemu. Formularz nie zawiera informacji na temat autora ani czasu
zgłoszenia, gdyŜ są to informacje, które mogą zostać dopisane do problemu automatycznie
np. na podstawie danych aktualnego uŜytkownika systemu. Formularz nie obejmuje takŜe
59
cech problemu, które są konieczne w procesie jego dalszej obsługi takich jak informacje
o przydzielonej odpowiedzialności, statusie rozwiązania czy przyznanych zasobach.
MoŜliwość dodanie do zgłoszenia tego typu danych oraz uściślenia juŜ zgromadzonych
pojawia się w dalszych krokach jego obsługi.
Formularz problemu widziany przez osoby zajmujące się nim juŜ po jego
zgłoszeniu i wstępnej ocenie (kierownicy, wykonawcy) ma w znaczącym stopniu
rozszerzoną strukturę, co przedstawia Rysunek 4-2. Podobnie jak w poprzednim wypadku,
zaprezentowany formularz stanowi jedynie wzorzec, na bazie którego moŜna wyciągnąć
ogólne wnioski na temat rodzaju i zakresu informacji koniecznych do gromadzenia w
procesie obsługi problemów. W dalszej części rozdziału znajduje się bardziej szczegółowy
opis poszczególnych elementów zaprezentowanej struktury zgłoszenia wzbogacony o
dodatkowe pola, których znaczenie i przydatność jest silnie uzaleŜniona od specyfiki
konkretnego projektu informatycznego.
PROBLEM
Rodzaj DEFEKT
Ogólny opis Problem z….
Istota Problem polega na...
problemu
ŚcieŜka do Problem występuje, gdy...
powtórzenia
Efekty Problem skutkuje...
wystąpienia
Propozycja System powinien...
rozwiązania
Dodatkowe Problem...
informacje
Rysunek 4-1 Formularz zgłoszenia problemu (źródło własne)
60
Rysunek 4-2 Formularz dalszej obsługi zgłoszenia (źródło własne)
4.3.1
Identyfikator problemu
KaŜde zgłoszenie pojawiające się w projekcie musi być w łatwy sposób
identyfikowalne. MoŜna to uzyskać poprzez kolejne numerowanie zgłaszanych
problemów. W praktyce pole identyfikatora zawiera zazwyczaj liczbę lub standardowo
generowany ciąg znaków, który stanowi swego rodzaju numer seryjny zgłoszenia. W celu
uniknięcia niejednoznaczności oczywiste jest, iŜ identyfikator problemu powinien być
niepowtarzalny, jeśli nie w całej organizacji, to przynajmniej w obrębie aktualnego
projektu.
61
4.3.2
Ogólny opis problemu
Identyfikator liczbowy problemu jest praktyczny przy ewidencji zgłoszeń, lecz jest
juŜ niewystarczający, gdy przychodzi do ich identyfikacji przez ludzi. Osoby korzystające
z systemu ewidencji zgłoszeń muszą mieć sposób na szybkie rozpoznawanie konkretnych
problemów. Rolę takiego wzbogaconego identyfikatora moŜe pełnić pole ogólnego opisu
problemu. Powinno ono być wypełniane w chwili zgłoszenia i przechowywać krótką
informację o charakterze problemu. Opis powinien w moŜliwie zwięzły sposób, w postaci
jednego zdania, określać przyczyny problemu, jego skutki lub oddawać jak najdokładniej,
choć w skrócie, jego istotę. RozwaŜmy edytor tekstu zawieszający się za kaŜdym razem,
gdy uŜytkownik próbuje pogrubić zaznaczony tekst. Złym opisem tego błędu jest zdanie
„Program zawiesza się”, a lepszym - „Program zawiesza się przy próbie pogrubienia
zaznaczonego tekstu". Pole ogólnego opisu słuŜy przede wszystkim człowiekowi, jednak
w niektórych sytuacjach moŜe być takŜe wykorzystywane przy zaawansowanym
wyszukiwaniu zgłoszonych zagadnień.
4.3.3
Metryka problemu
KaŜde zgłoszenie powinno być opatrzone podstawowymi informacjami na temat
jego zaistnienia w rejestrze. Metryka pojedynczego zgłoszenia musi zawierać, co najmniej
pole wskazujące na jego autora, datę pierwszej rejestracji oraz informacje o dacie i autorze
ostatniej modyfikacji zgłoszenia. Są to informacje, bez których niemoŜliwe stałoby się
efektywne zarządzanie rejestrem zgłoszeń.
4.3.4
Szczegółowy opis problemu
Szczegółowy opis zgłoszonego problemu powinien przede wszystkim zawierać
odpowiedzi na następujące pytania:
•
Na czym polega istota problemu?
•
Jakie są skutki wystąpienia problemu?
•
Jaka sekwencja zdarzeń prowadzi do wystąpienia opisywanego problemu?
•
Czy istnieje sposób uniknięcia (ominięcia) wystąpienia problemu?
•
Co mogłoby rozwiązać dany problem?
MoŜliwie kompletne i wyczerpujące odpowiedzi na powyŜsze pytania pozwolą na
szybką i sprawną identyfikację, odnalezienie oraz rozwiązanie zgłaszanego problemu.
62
Ze względu na róŜnorodny charakter pytań warto pole szczegółowego opisu problemu
rozdzielić na następujące sekcje i rozpatrywać je oddzielnie jako częściowo niezaleŜne.
4.3.4.1 Istota problemu
Pole w naturalny sposób rozszerzające ogólny opis problemu. To tutaj powinien
znajdować się szczegółowy opis zaistniałego problemu albo wyjaśnienie potrzeby
wprowadzenia zmiany do oprogramowania. W przypadku prostych zgłoszeń pole to moŜe
zawierać zdublowany opis ogólny. Przy większych, bardziej skomplikowanych
problemach, sekcja ta posłuŜy jako miejsce do dodatkowego definiowania istoty problemu.
4.3.4.2 ŚcieŜka do powtórzenia problemu
Ten fragment opisu problemu dotyczy w zasadzie głownie defektów. Osoba
zgłaszająca problem powinna w miarę moŜliwości określić minimalny zestaw czynności
potrzebny do powtórnego uzyskania opisywanego efektu. Jest to informacja niezbędna
w procesie wykrywania i usuwania defektów, poniewaŜ błąd, którego nie umiemy
powtórzyć, jest bardzo trudny do zlikwidowania. Niestety, w praktyce zgłoszenia
problemów często pozbawione są dostatecznie precyzyjnego opisu ścieŜki do ich
powtórzenia. Ten fragment opisu problemu powinien zawierać dokładną kolejność kroków
zaczynając od początku, aby odtworzyć dany problem. Opis i dane do niego dostarczone
powinny być w całości wystarczające, aby odtworzyć problem. JeŜeli aktywacja danego
defektu wymaga konkretnej sekwencji zdarzeń, naleŜy je wyszczególnić. Przy opisie
kroków naleŜy starać się minimalizować objętość dokumentacji dotyczącej danego
problemu, jednakŜe nie jest to absolutnie konieczne. JeŜeli problem jest odtwarzalny musi
istnieć na to odpowiedni sposób.
4.3.4.3 Efekty wystąpienia problemu
Kompletny opis słowny problemu musi takŜe precyzować dokładny efekt jego
wystąpienia. W ogólności chodzi tutaj o opis wyniku operacji, przy której wystąpił dany
problem, przy czym nie wystarczy stwierdzenie typu "to nie wyszło" lub „program zwrócił
błędne dane”. Jest to miejsce w opisie problemu, gdzie uŜytkownik zgłaszający problem
powinien umieszczać wszelkie napotkane komunikaty o błędach - nawet te, których
znaczenia sam nie rozumie. JeŜeli w momencie aktywacji defektu w zachowaniu systemu
brak jest wyraźnych oznak błędu naleŜy takŜe zaznaczyć ten fakt, gdyŜ pozostawienie
pustego pola moŜe zostać źle zinterpretowane jako brak informacji o efektach problemu.
Zawartość tego pola jest kluczowa przy późniejszych próbach powtórzenia problemu –
63
napotkanie tych samych symptomów oznacza, iŜ osoba odpowiedzialna za rozwiązanie
danego zagadnienia dobrze zrozumiała zgłoszenie i rzeczywiście zajmuje się właściwym
problemem. Przy wypełnianiu tej sekcji zgłoszenia najprościej po prostu przepisywać lub
kopiować treści komunikatów wyświetlanych przez oprogramowanie. Pewnego rodzaju
rozszerzeniem pola efektów wystąpienia problemu jest mechanizm załączników, który
umoŜliwia np. dodanie do zgłoszenia zrzutu ekranu systemu tuŜ po wystąpieniu problemu.
Załączniki, jako osobne pole w rekordzie problemu, są opisane w dalszej części tego
rozdziału.
4.3.4.4 Propozycja rozwiązania
Często zdarza się sytuacja, w której uŜytkownik zgłaszający problem ma w głowie
gotowe rozwiązanie lub przynajmniej jego zarys. Oczywiście zazwyczaj nie chodzi tutaj
o wskazanie konkretnego miejsca w kodzie, gdzie leŜy problem. Sekcja proponowanego
rozwiązania daje zgłaszającemu moŜliwość wyraŜenia swojej opinii na temat zaistniałego
problemu i zasugerowanie wykonawcy rozwiązania.
4.3.4.5 Dodatkowe informacje
W ostatniej sekcji opisu problemu powinny się znaleźć wszelkie informacje, które
nie mieszczą się w definicji poprzednich sekcji, a które osoba zgłaszająca pragnie
przekazać wykonawcy. Pole to moŜna traktować jako swego rodzaju jednorazowy
komentarz do opisu problemu. Nie naleŜy mylić tej sekcji z polem uwag opisywanym
w dalszej części rozdziału – informacje tutaj zawarte są ściśle powiązane z opisem istoty
problemu.
4.3.5
Priorytet problemu
Priorytet problemu jest rozumiany jako stopień jego waŜności w projekcie
w stosunku do innych zgłoszonych problemów. Priorytet ma zasadniczo dwa wymiary.
Pierwszym z nich jest krytyczność, a więc na ile problem jest istotny dla powodzenia
projektu i funkcjonowania całego systemu. Drugim aspektem zawartym w priorytecie jest
pilność, czyli maksymalny zadowalający czas usunięcia problemu. Pole priorytetu
zgłoszenia jest takŜe ściśle powiązane z polem dokuczliwości. Priorytet zgłoszenia określa
bezpośrednio tryb pracy nad usunięciem defektu lub wprowadzeniem zmiany. W chwili
zgłaszania pole to pozostaje puste i jest wypełniane dopiero przy okazji analizy zgłoszenia
i przydzielenia mu konkretnych zasobów. Wartość tego pola zazwyczaj nie jest stała
i moŜe zmieniać się wraz z upływem czasu. Ustalenie priorytetu narzuca pewne
64
wymagania, co do tempa prowadzonych prac, wymuszając na przykład poprawienie
danego błędu juŜ w następnej udostępnionej klientom wersji produktu.
Warto w tym momencie zaznaczyć, iŜ priorytet problemu moŜe się odnosić
zarówno do produktu (systemu) jak i procesu jego wytwarzania (projektu). Krytyczność
rozwiązania danego problemu moŜe mieć diametralnie inny stopień w zaleŜności od
kontekstu. Przykładowo, usprawnienie działania pewnego aspektu interfejsu uŜytkownika
moŜe mieć wysoki priorytet, biorąc pod uwagę chęć poprawienia ergonomii i wydajności
pracy z systemem. Ten sam problem w odniesieniu do celów i harmonogramu projektu
moŜe mieć priorytet zdecydowanie niŜszy przy uwzględnieniu innych zadań oczekujących
na realizację. Opisana tutaj relatywność priorytetu moŜe sugerować wprowadzenie do
opisu problemu dwóch oddzielnych pól, odnoszących się odpowiednio do priorytetu
względem produktu i projektu.
Niezmiernie istotne jest, aby określenie „problem o najwyŜszym priorytecie” dla
wszystkich zainteresowanych stron oznaczało to samo. KaŜdy zespół wypracowuje własną
skalę oceny zgłoszeń, jednak ogólnie moŜna przyjąć, Ŝe najwyŜszą kategorię uzyskują
problemy krytyczne, które uniemoŜliwiają działanie systemu, a następnie krytyczne
nieblokujące, przy których dalsza praca jest niemoŜliwa. Następne w kolejności
to zgłoszenia o wysokiej kategorii, potem średniej, a w końcu niskiej.
PoniŜej znajduje się najczęściej spotykana hierarchia priorytetów przydzielanych
zgłoszeniom, warto jednak zaznaczyć, iŜ konkretne projekty mogą wymagać
specyficznego i całkiem odmiennego podejścia do tematu przydzielania waŜności
zgłoszeń.
4.3.5.1 NajwyŜszy
Problem dotyczy defektu lub zmiany, która jest kluczowa dla powodzenia
przedsięwzięcia. Zaniedbanie zgłoszenia moŜe bezpośrednio wpłynąć na niezadowolenie
klienta, jakość produktu, na wielkość sprzedaŜy i na wyniki firmy lub w skrajnym
przypadku na całkowite niepowodzenie projektu. Problem o takim priorytecie naleŜy
bezwzględnie natychmiast przeanalizować i rozwiązać. W przypadku zgłoszenia defektu
oznacza to, iŜ w następnej wersji produktu zgłoszony defekt nie moŜe wystąpić i naleŜy
powstrzymać jej wypuszczenie do chwili usunięcia błędu. W szczególnych sytuacjach
moŜna takŜe rozwaŜyć przygotowanie specjalnej wersji produktu zawierającej poprawkę
usuwającą defekt.
65
4.3.5.2 Wysoki
Zgłoszenie o wysokim priorytecie jest bardzo waŜne w kontekście powodzenia
przedsięwzięcia i produktu. NaleŜy go jak najszybciej przeanalizować i rozwiązać.
W przypadku defektów, poza zupełnie wyjątkowymi sytuacjami, w następnej oficjalnej
wersji produktu wypuszczonej na rynek lub udostępnionej klientowi nie moŜe wystąpić
opisywany błąd. NaleŜy ponadto rozwaŜyć wydanie „łaty” poprawiającej defekt w obecnej
wersji produktu.
4.3.5.3 Średni
Problem istotny dla powodzenia przedsięwzięcia jednak juŜ nie tak krytyczny jak
dwa powyŜsze przypadki. W harmonogramie prac nad produktem naleŜy uwzględnić
próbę rozwiązania zgłoszonego problemu. Jeśli nie w najbliŜszej, to w kolejnej wersji
produktu defekt powinien być usunięty, a postulowana zmiana wprowadzona. W praktyce
średni priorytet oznacza, iŜ problem naleŜy rozpatrzyć i zaproponować konkretne
rozwiązanie w przeciągu 4 miesięcy od zgłoszenia.
4.3.5.4 Niski
Najogólniej rzecz ujmując są to problemy, które naleŜy prędzej czy później
rozwiązać. Defekty o takim priorytecie zazwyczaj odznaczają się znikomą uciąŜliwością,
co jednak nie zmienia faktu, iŜ naleŜy je w końcu usunąć z produktu. W przypadku zmian,
te o niskim priorytecie to takie, na które nie ma specjalnego wskazania w specyfikacji
wymagań i których realizacja moŜe zostać odłoŜona na późniejszy termin. W Ŝadnym
wypadku nie naleŜy jednak niskiego priorytetu problemu interpretować jako przyzwolenie
na jego całkowite zignorowanie. Problemy takie w praktyce naleŜy usuwać w przeciągu
6 miesięcy od zgłoszenia.
4.3.6
Stan problemu
WaŜne, aby w dowolnym momencie procesu obsługi, moŜna było jednoznacznie
stwierdzić, na jakim etapie znajduje się zgłoszenie. Przedmiotem poprzedniego rozdziału
była szczegółowa analiza cyklu Ŝycia kaŜdego zgłoszenia defektu i prośby o zmianę
w projekcie. Omawiane tutaj pole stanowi bezpośrednią konsekwencję wprowadzenia
pojęcia stanu zgłoszenia. Jego wartość oznacza aktualny stan zgłoszenia - stopień
zaawansowania naprawy defektu lub wprowadzenia zmiany. Dziedzina moŜliwych
66
wartości pola moŜe odpowiadać najwaŜniejszym etapom procesu rozwiązywania
problemów zaproponowanym w poprzednim rozdziale.
4.3.7
Przydział odpowiedzialności
Przydatność tego rodzaju pól zaleŜy od sposobu prowadzenia prac projektowych
i programistycznych w firmie. SłuŜą one do określenia osób lub zespołów obarczanych
odpowiedzialnością za pewne czynności związane z obsługą błędu. Odpowiednie uŜycie
tych pól moŜe ułatwić zarządzanie procesem usuwania błędu. Standardowo pola
przydziału
określają
osoby
odpowiedzialne
za
kontakty
z
klientami,
prace
programistyczne, sporządzenie dokumentacji i przeprowadzanie testów.
4.4
Historia problemu
Jak pokazano w poprzednim rozdziale dotyczącym cyklu Ŝycia problemu, przebieg
jego obsługi jest procesem ciągłym i bardzo często czasochłonnym. W trakcie całego
procesu definicja i opis problemu ulega rozmaitym przekształceniom – opisy są
aktualizowane i zmieniane są atrybuty zgłoszenia. Struktura danych opisująca zgłoszenie
nie moŜe pozostawać obojętna na ten fakt, dlatego tak istotne jest zidentyfikowanie jej
zmiennych aspektów i zaproponowanie efektywnej metody przechowywania informacji na
temat zachodzących zmian.
4.4.1
Modyfikacje atrybutów
Najbardziej oczywistym aspektem podlegającym modyfikacjom w opisie problemu
są jego podstawowe atrybuty takie jak stan, przydział odpowiedzialności czy priorytet.
W zasadzie jakakolwiek zmiana któregokolwiek z opisywanych w tym rozdziale atrybutów
nominalnych powinna się wiązać z zapisem w historii danego zgłoszenia. Informacja taka
moŜe się okazać przydatna przy dalszej analizie problemu albo przy rozliczaniu prac nad
danym zgłoszeniem. Pojedynczy wpis do historii problemu powinien zawierać informacje
na temat czasu modyfikacji, nowej wartości atrybutu oraz osoby, która jest jej autorem.
W praktyce przydatny moŜe się okazać takŜe komentarz do modyfikacji, np. wyjaśniający
przyczynę obniŜenia priorytetu problemu. Oczywistym jest fakt, iŜ pojedyncze zgłoszenie
moŜe posiadać nieskończenie wiele wpisów w swojej historii.
4.4.2
Rozszerzenia opisu problemu
W trakcie procesu obsługi bardziej skomplikowanych zgłoszeń ich opis moŜe
ulegać wielokrotnym zmianom i aktualizacjom. Choć w danym momencie główny opis
67
problemu
powinien
stanowić
jednolitą
całość,
czasem
moŜe
być
wskazane
przechowywanie informacji na temat, kto i kiedy zmodyfikował treść opisu, a czasem
nawet poprzednie jego wersje.
4.4.3
Uwagi i komentarze
Praktyka bardzo często pokazuje, Ŝe nawet najbardziej elastyczna struktura danych
w pewnym momencie moŜe się okazać niewystarczająca do opisu szczególnych sytuacji.
Pole uwag i komentarzy stanowi najmniej sformalizowany element struktury danych
opisującej problem i moŜe posłuŜyć jako miejsce, w którym gromadzone są wszelkie
informacje, których znaczenie nie mieści się w ramach pozostałych pól. Komentarz do
problemu moŜe zawierać informacje nie dotykające bezpośrednio sedna problemu,
a jednocześnie będące przydatne w procesie jego obsługi. Istotne jest to, iŜ pojedyncze
zgłoszenie moŜe być opatrzone wieloma komentarzami, z których kaŜdy moŜe mieć
innego autora. Przykładami komentarzy mogą być całkowicie nieformalne stwierdzenia
takie jak np. „Zajmę się tym w przyszłym tygodniu” albo „Proszę o podanie więcej
szczegółów na temat…”. Ciąg takich uwag moŜe w pewnym momencie przyjąć formę
dyskusji między zgłaszającym i programistą usuwającym usterkę. Jak widać pole uwag
daje sporą dozę dowolności przy jego wykorzystaniu, co niestety rodzi niebezpieczeństwo
jego naduŜycia. NaleŜy bezwzględnie unikać sytuacji, w których pole komentarza jest
wykorzystywane do przechowywania informacji, które ewidentnie powinny się znaleźć
w innych częściach zgłoszenia.
4.5
Dodatkowe informacje o problemie
Poza omówionymi podstawowymi informacjami zgłoszenie moŜe zawierać
dodatkowe dane przydatne w jego katalogowaniu i odszukiwaniu. NaleŜy jednak pamiętać,
Ŝe rozszerzanie dowolnej struktury danych zwiększa złoŜoność procesu obsługi takich
danych. W omawianym przypadku ewidencji zgłoszeń powoduje takŜe powstanie
dodatkowych zaleŜności między systemem ewidencjonowania zgłoszeń a całością procesu
produkcji oprogramowania. Im ściślejszy ten związek tym mniejsza jest uniwersalność
struktury danych. PoniŜej znajduje się lista cech zgłoszenia, które mogą stanowić
dodatkowy zestaw informacji przydatnych w szczególnych przypadkach procesu ich
obsługi.
68
4.5.1
Identyfikator produktu
W przypadku, gdy przedmiotem projektu jest realizacja więcej niŜ jednego systemu
przydatne moŜe okazać się oznakowanie kaŜdego zgłoszenia identyfikatorem produktu,
którego się tyczy. Takie podejście jest zdecydowanie bardziej praktyczne, niŜ
umieszczanie takiej informacji bezpośrednio w opisie problemu. Ogólnie rzecz biorąc jest
to zatem pole identyfikujące produkt, w którym zauwaŜono defekt lub, w którym
konieczne jest wprowadzenie zmiany. Pole to jest zazwyczaj wypełniane w chwili
zgłoszenia problemu, choć nie jest to reguła – moŜe się np. zdarzyć, iŜ uŜytkownik nie do
końca zdaje sobie sprawę, z jakiego produktu korzysta. Wartość ta nie pozostaje takŜe
stała, moŜe się zdarzyć, iŜ zgłoszonemu problemowi zostanie omyłkowo przypisany
niewłaściwy produkt. Dobrze, gdy w polu tym znajduje się zrozumiały i unikalny kod
określający konkretny produkt. Stosowane tutaj oraz w podrozdziale 4.5 pojęcie produktu
moŜe odnosić się zarówno do finalnego rezultatu projektu informatycznego (systemu,
modułu, dokumentacji) jak równieŜ do poszczególnych półproduktów i składników
powstających w całym cyklu wytwórczym (produktów kolejnych faz projektu). Sposób,
zakres oraz stopień szczegółowości przy identyfikowaniu produktów jest ściśle
uzaleŜniony od potrzeb i specyfiki konkretnego projektu.
4.5.2
Wersja produktu
Pole wersji produktu stanowi naturalne rozszerzenie poprzedniego pola.
W przypadku złoŜonych projektów wytwarzających wiele wersji oprogramowania
konieczna moŜe okazać się identyfikacja wersji danego produktu, w której został
zauwaŜony defekt. Pole wersji, podobnie jak identyfikator produktu, jest wypełniane
w chwili zgłoszenia i podlega tym samym zasadom. Pole powinno przechowywać
informacje pozwalające jednoznacznie zidentyfikować odpowiednią wersję produktu.
4.5.3
Słowa kluczowe
W przypadku, gdy zaleŜy nam na skutecznym odszukiwaniu zgłoszeń zasadne
moŜe okazać się wprowadzenie dodatkowych ustrukturalizowanych atrybutów do rekordu
problemu. Przykładem takiego pola jest zbiór słów kluczowych. W polu tym,
wypełnianym przez osobę zgłaszającą problem, naleŜy umieścić jedno lub kilka słów
kluczowych charakteryzujących zagadnienie z jej punktu widzenia. Zestaw moŜliwych do
uŜycia
słów
kluczowych
musi
być
stały
w
obrębie
projektu
lub
produktu
i powinien zawierać pojedyncze słowa lub krótkie wyraŜenia. W przypadku zgłoszeń
69
defektów słowa kluczowe powinny opisywać błąd z punktu widzenia zgłaszającego, a więc
naleŜy je dobierać na podstawie wiedzy moŜliwej do uzyskania podczas uŜytkowania
systemu, a nie opartej na doświadczeniu nabytym przy jego tworzeniu. JeŜeli na przykład
produktem jest telefon, to słowami kluczowymi, znanymi uŜytkownikowi, są sygnał,
wybieranie numeru, klawiatura, zakończenie rozmowy itp. Jeśli uŜytkownik napotyka
problem przy wybieraniu numerów zawierających cyfrę 6, odpowiednimi słowami
kluczowymi są wybieranie numeru, klawiatura. Pole słów kluczowych silnie zaleŜy od
kontekstu zgłoszenia, poniewaŜ róŜne produkty będą udostępniały róŜne zestawy
dozwolonych wartości. W praktyce pole tego typu umoŜliwia segregację zgłoszeń na
kategorie, co w efekcie pomaga w określaniu fragmentów produktu, które nie sprawiają
problemów uŜytkownikom, oraz tych, które wymagają jeszcze dopracowania.
4.5.4
Dokuczliwość problemu
Dokuczliwość jest cechą praktycznie zarezerwowaną dla defektów. Pole
dokuczliwości uŜywa ustalonego zbioru wartości, które określają jego wpływ na działanie
oprogramowania oraz na pracę i sposób oceny produktu przez jego uŜytkowników.
Dokuczliwość problemu jest w znacznym stopniu cechą subiektywną i jest określana przez
osobę zgłaszającą defekt, choć warto zaznaczyć, iŜ jej wartość moŜe ulegać zmianom
w dalszym procesie obsługi zgłoszenia (np. w wyniku wstępnej oceny zgłoszenia). Zbiór
moŜliwych poziomów dokuczliwości moŜe zaleŜeć od potrzeb, ale w praktyce powinien
być taki sam dla wszystkich produktów opracowywanych w organizacji. WaŜne jest, aby
definicje poszczególnych poziomów były znane i zrozumiałe zarówno dla wytwórców
oprogramowania jak i osób zgłaszających defekty. PoniŜsza tabela zawiera przykładową
propozycję hierarchii dokuczliwości, wraz z opisem znaczenia poszczególnych stopni
[BAY2001]:
Dokuczliwość Opis
SKRAJNA
DUśA
ŚREDNIA
MAŁA
Oprogramowania nie da się uŜywać, przez co uŜytkownik nie moŜe wykonywać
nawet swoich podstawowych zadań.
Nie działa pewna istotna część produktu, jednak uŜytkownik nadal moŜe
wykonywać pewien podzbiór swoich zadań
Pewien fragment produktu nie działa, ale uŜytkownik moŜe wykonać większość
operacji. Mogą istnieć pewne skomplikowane i niewygodne metody obejścia
błędu. Niedziałające część oprogramowania jest opisana w jego specyfikacji.
UŜytkownik moŜe wykonać większość operacji, a nie działa jedynie niewielki
fragment produktu, nieopisany w specyfikacji.
NajwyŜszym poziomem dokuczliwości moŜna oznaczyć błąd, który powoduje
zawieszenie programu natychmiast po jego uruchomieniu. W edytorze tekstu błędem
70
o duŜej dokuczliwości jest niemoŜność uŜywania stylów tekstu. Średnio dokuczliwym
błędem jest brak moŜliwości ustalania szerokości marginesów, natomiast błąd polegający
na tym, Ŝe nie moŜna pogrubić tekstu, korzystając z menu programu, ale udaje się to zrobić
przy uŜyciu skrótów dostępnych na klawiaturze, ma niski poziom dokuczliwości.
4.5.5
Charakter problemu
Jak zaznaczono wyŜej, dokuczliwość problemu odnosi się właściwie tylko
i wyłącznie do defektów oprogramowania i precyzuje jedynie poziom jego wpływu na
działanie produktu. W przypadku, gdy zaleŜy nam na bardziej szczegółowym
klasyfikowaniu problemów, a rejestr zgłoszeń ma zawierać zarówno raporty o defektach
jak i propozycje zmian, zasadne moŜe okazać się wprowadzenie dodatkowego pola
opisującego zgłoszenie pod względem jego charakteru. Takie rozszerzenie struktury
danych wpłynie pozytywnie na moŜliwość wyszukiwania i kategoryzowania problemów
pod kątem ich faktycznego znaczenia. PoniŜej znajduje się przykładowy podział zgłoszeń
według ich charakteru [MAN2005]:
Charakter
Opis
PROPOZYCJA Zgłoszenie jawnie sklasyfikowane jako powaŜna propozycja zmiany
Zgłoszenie dotyczy problemu, którego waga jest znikomo mała. W praktyce
BŁAHY
zgłoszenia tego typu mają bardzo niski priorytet, a w aspekcie dokuczliwości
mieszczą się nawet poniŜej poziomu „MAŁA”.
Zgłoszenie dotyczy problemu nie odnoszącego się do funkcjonalności systemu
TEKST
– zazwyczaj oznacza to błąd merytoryczny w tekście wyświetlanym przez
system albo literówkę w interfejsie lub dokumentacji.
POPRAWKA UŜytkownik moŜe wykonać większość operacji, a nie działa jedynie niewielki
fragment produktu, nieopisany w specyfikacji.
Zgłoszenie dotyczy problemu, którego waga jest mało istotna, ale nie
DROBNY
pomijalna.
Zgłoszenie dotyczy problemu, którego waga jest bardzo istotna.
WAśNY
Zgłoszenie dotyczy problemu, który spowodował upadek systemu.
UPADEK
Zgłoszenie dotyczy problemu, który spowodował zablokowanie pewnej
BLOKADA
funkcjonalności systemu.
4.5.6
Powtarzalność
Pole w pewnym sensie nadmiarowe, gdyŜ informacja o powtarzalności powinna
być zaszyta juŜ w samym opisie problemu. Wprowadzenie tego typu dodatkowego
klasyfikatora zagadnień ma na celu dalsze usprawnienie kategoryzowania zgłoszeń i moŜe
okazać się pomocne przy określaniu priorytetów - osoba oceniająca zgłoszenie nie musi
analizować opisu, aby określić pewne aspekty zgłoszenia. PoniŜej znajduje się
przykładowy podział zgłoszeń według ich powtarzalności [MAN2005]:
71
Powtarzalność
Opis
Problem występuje zawsze, gdy powtórzy się kroki zawarte w opisie
problemu
Problem występuje prawie zawsze, gdy powtórzy się kroki zawarte w opisie
CZASAMI
problemu. Opis problemu moŜe, ale nie musi, zawierać informacje na temat
dodatkowych warunków, jakie muszą być spełnione, aby problem wystąpił.
Problem występuje, ale zgłaszający nie jest w stanie precyzyjnie określić
LOSOWO
dokładnych przyczyn jego powstawania. Opis takiego problemu, moŜe być
z tego powodu pozbawiony szczegółowego opisu dojścia do wystąpienia
problemu.
Problem został zauwaŜony, jednak z jakiegoś powodu nie została podjęta
NIE
PRÓBOWANO Ŝadna próba jego powtórzenia. Opis takiego problemu, moŜe być z tego
powodu pozbawiony szczegółowego opisu dojścia do wystąpienia problemu.
Problem został zauwaŜony, jednak wszystkie podjęte próby jego
NIE DO
POWTÓRZENIA powtórzenia zakończyły się poraŜką. Problemy tego typu mogą posiadać
szczegółowy opis, który jednak w warunkach testowych moŜe nie prowadzić
do jego powtórzenia.
ZAWSZE
4.5.7
Widzialność
W przypadku, gdy do rejestru problemów mają dostęp zarówno wykonawcy,
uŜytkownicy jak i przedstawiciele klienta zasadne moŜe być wprowadzenie dodatkowego
mechanizmu filtrującego zgłoszenia. Zdarzają się sytuacje, gdy wykonawcy zaleŜy, aby
pewne aspekty działania oprogramowania albo bardziej krytyczne defekty wykryte przez
samych programistów nie były widoczne poza zespołem projektowym. Rozszerzenie
struktury danych problemu o pole typu widzialność całkowicie rozwiązuje ten problem.
W najprostszym scenariuszu wystarczy pole o binarnej wartości, choć nie wyklucza się
bardziej złoŜonego klasyfikowania problemów niŜ zaprezentowane poniŜej:
Widzialność
PRYWATNE
PUBLICZNE
4.5.8
Opis
Zgłoszenie widziane tylko przez członków zespołu projektowego wykonawcy.
Zgłoszenie widziane przez wszystkie osoby mające dostęp do rejestru
problemów.
Składnik produktu
KaŜdy produkt informatyczny moŜe zostać podzielony na składniki w sposób
odzwierciedlający strukturę jego implementacji. Struktura takiego podziału przypomina
zazwyczaj drzewo, którego korzeniem jest cały produkt, a na kolejnych poziomach
znajdują się poszczególne jego moduły i komponenty. Pole składnika produktu jest
w pewnym sensie podobne do pola słów kluczowych. RóŜnica polega na punkcie widzenia
- jest dla programisty tym, czym pole słów kluczowych dla uŜytkownika. Informacja
niesiona łącznie przez oba te pola umoŜliwia precyzyjne określenie miejsca występowania
problemu, a takŜe podział zgłoszeń na kategorie z punktu widzenia zarówno uŜytkownika
72
jak i programisty. Pole składnika moŜe pozostać niewypełnione, aŜ do chwili ukończenia
procesu rozpoznania przyczyn problemu. WaŜne, aby w pojedynczym zgłoszeniu moŜna
było określić tylko jeden odpowiadający mu składnik produktu. Pole składnika produktu
zaleŜy od kontekstu z tych samych powodów, co pole słów kluczowych, a zbiór
moŜliwych do wybrania składników zaleŜy oczywiście od konkretnego produktu i potrzeb
projektu. Dziedziną tego pola moŜe być zarówno szczegółowa lista modułów
i komponentów produktu, jak równieŜ ogólny podział systemu na np. „warstwę danych”,
„logikę” oraz „interfejs uŜytkownika”. Choć pole składnika zasadniczo odnosi się do
produktów stricte informatycznych (systemu, modułu), moŜe ono zostać takŜe
zaadaptowane
na
potrzeby
opisu
innego
rodzaju
produktów
i
półproduktów
poszczególnych faz cyklu wytwórczego (np. do określania konkretnych fragmentów
dokumentów projektowych).
4.5.9
Załączniki
W procesie opisu problemu niezwykle pomocne bywa załączenie zrzutów ekranów.
Często w przypadku niemoŜności odtworzenia błędu jest to jedyny dowód na to, Ŝe miał
on jednak miejsce, a przyczyna, Ŝe nie jesteśmy go w stanie powtórzyć tkwi
w specyficznych okolicznościach jego zaistnienia. Bardzo często programista jest w stanie
z samego zrzutu ekranu odczytać te okoliczności. Aby osoba zgłaszająca problem miała
moŜliwość przekazania wykonawcy tego typu informacje dodatkowe, struktura danych
przechowująca informacje o problemie musi umoŜliwiać dołączanie do niej zewnętrznych
danych w postaci załączników. Najogólniej rzecz ujmując załącznik to zewnętrzny plik
związany z rekordem lub będący jego elementem. Zawartość takiego pliku moŜe zaleŜeć
od właściwości produktu, w którym wystąpił problem oraz od rodzaju zgłoszonego
defektu. Struktura danych powinna być na tyle elastyczna, aby pozwalać na umieszczenie
więcej niŜ jednego załącznika w rekordzie problemu.
Zrzuty ekranu stanowią tylko jeden z moŜliwych rodzajów załączników, choć
praktyka pokazuje, iŜ są ich najczęściej spotykaną formą. Niektóre produkty wymagają
uŜycia załączników częściej niŜ inne. Przykładowo, w opisie defektów występujących
w kompilatorach lub programach łączących często jest przydatne dołączenie plików
źródłowych, przy przetwarzaniu, których wystąpił błąd. RównieŜ w produktach sieciowych
często uŜywa się załączników zawierających diagramy obrazujące powstałe problemy.
73
W takich sytuacjach umoŜliwienie tworzenia załączników do rekordów problemów moŜe
znacznie usprawnić proces ich usuwania.
4.5.10 Pole duplikatu
Pole duplikatu w opisie problemu słuŜy do wskazania innego zgłoszenia, o którym
wiadomo, Ŝe w istocie zawiera informacje o tym samym lub bardzo podobnym
zagadnieniu. Pole to zawiera zazwyczaj identyfikator drugiego zgłoszenia. W celu
maksymalnego uproszczenia procesu katalogowania i wyszukiwania zgłoszeń naleŜy
unikać sytuacji, w której wiele zgłoszeń opisuje ten sam problem, w przeciwnym, bowiem
razie łatwo stracić kontrolę nad wszystkimi powiązanymi zagadnieniami. Podwójne
zgłoszenia powinny być jak najszybciej łączone w jedno, a odpowiedzialność za
wykonanie połączenia spoczywa na osobie, która pierwsza zauwaŜy, Ŝe dwa zgłoszenia
opisują ten sam problem. Wszelkie duplikaty powinny być zlikwidowane, zanim prace nad
zgłoszeniem ulegną zakończeniu.
4.6
Model problemu
PowyŜszy opis stanowi zakres informacji, jaki moŜe nieść ze sobą pojedynczy
problem w projekcie informatycznym. Przedstawiona struktura, choć zawiera szczegółowy
opis kaŜdego elementu składowego, nie stanowi formalnego modelu problemu, którego
powstanie było głównym celem niniejszego rozdziału. Korzystając z niego moŜna jednak
przystąpić do budowy takiego modelu. Rysunek 4-3 przedstawia statyczną strukturę
problemu z wykorzystaniem notacji UML 2.0 w zakresie modelowania klas oraz związków
zachodzących pomiędzy nimi. Wybór notacji podyktowany był chęcią uzyskania jak
największej czytelności i przejrzystości przy jednoczesnej zgodności ze standardami.
Diagram klas stanowi bezpośrednie przełoŜenie opisanej wyŜej struktury problemu.
Jak widać w proponowanym modelu została wprowadzona hierarchia dziedziczenia, aby
zobrazować część wspólną oraz róŜnice pomiędzy zgłoszeniami defektów i propozycji
zmian. Ponadto diagram zawiera wszystkie zidentyfikowane elementy takie jak definicja
problemu (defektu i zmiany), jego historię, dodatkowe informacji itp. W modelu problemu
został wykorzystany wzorzec projektowy „Stan” (ang. State) [GAMM1995] do
zamodelowania stanu problemu oraz jego rozwiązania. Podejście takie daje moŜliwość
odrębnego definiowania zachowania i właściwości problemu w kaŜdym ze stanów oraz
umoŜliwia ewentualne rozszerzenie modelu o nowe stany i rozwiązania w przyszłości.
74
Rysunek 4-3 Diagram klas modelu problemu
Charakterystyka poszczególnych elementów modelu znajduje się poniŜej. Opis
poszczególnych klas, oprócz wyjaśnienia ich znaczenia, zawiera ogólną charakterystykę
atrybutów oraz związków zachodzących pomiędzy obiektami. W zaprezentowanym
modelu celowo pominięto bardziej szczegółowe aspekty takie jak definicje metod, gdyŜ
w zamierzeniu ma to być model moŜliwie prosty i niezaleŜny od konkretnej implementacji,
odnoszący się przede wszystkim do statycznych aspektów modelu problemu.
75
Klasa
Opis klasy
Atrybuty
Związki
Klasa
Opis klasy
Atrybuty
Związki
Klasa
Opis klasy
Atrybuty
Związki
Problem
Klasa abstrakcyjna, której instancje reprezentują pojedyncze problemy pojawiające się
w trakcie projektu informatycznego. Instancja Problemu moŜe być albo Defektem albo
Zmianą.
• Identyfikator – unikalny identyfikator problemu
• dataZgłoszenia – data pojawienia się zgłoszenia problemu
• autor – imię i nazwisko osoby zgłaszającej problem
• priorytet – aktualna wartość priorytetu problemu
• osobaPrzypisana – imię i nazwisko osoby aktualnie odpowiedzialnej za rozwiązanie
problemu
• produkt – nazwa produktu, którego dotyczy problem
• wersjaProduktu – numer wersji produktu, której dotyczy problem
• składnikProduktu – nazwa części produktu, której dotyczy problem
• słowaKluczowe – lista słów kluczowych charakteryzujących problem
• widzialność – określa czy informacja o problemie jest publiczna czy prywatna
• tytuł - krótki opis charakteryzujący istotę problemu
• opis – rozszerzony opis problemu
• dodatkoweInformacje – dodatkowe informacje na temat problemu
• Problem zgłoszony przez Członek zespołu projektowego – związek 1-1 określający,
kto jest autorem zgłoszenia problemu, pojedynczy problem moŜe mieć tylko jednego
autora
• Problem przypisany do Członek zespołu projektowego – związek 1-1 reprezentujący
aktualnie przypisaną odpowiedzialność za rozwiązanie problemu, do pojenczego
problemu w danym momencie moŜe być przypisana tylko jedna osoba
• Problem posiada listę modyfikacji Modyfikacja – silna agregacja 0-* reprezentująca
historię zmian pojedynczego problemu
• Problem posiada załączniki Załącznik – silna agregacja 0-* reprezentująca zbiór
załączników dodanych do pojedynczego problemu
• Problem posiada komentarze Komentarz - silna agregacja 0-* reprezentująca zbiór
komentarzy dodanych do pojedynczego problemu
• Problem jest w stanie Stan – słaba agregacja 1 – 1 określająca stan, w jakim znajduje
się aktualnie dany problem
• Problem posiada rozwiązanie Rozwiazanie – słaba agregacja 1 – 1 określająca
rozwiązanie, jakie przypisano danemu problemowi
• Problem stanowi klasę bazową dla klas Defekt oraz Zmiana
Defekt
Klasa potomna dziedzicząca po klasie Problem. Instancje tej klasy reprezentują zgłoszenia o
defektach i zawierają informacje na ich temat.
• powtarzalność – określa jaka jest częstotliwość aktywacji defektu w produkcie
• sposóbPowtórzenia – opis kroków koniecznych do powtórzenia aktywacji defektu
• dokuczliwość – określa stopień dokuczliwości istnienia danego defektu w produkcie
• efektyWystąpienia – opis efektów aktywacji defektu
• propozycjaRozwiązania – opis propozycji rozwiązania problemu
• Defekt dziedziczy po klasie Problem
Zmiana
Klasa potomna dziedzicząca po klasie Problem. Instancje tej klasy reprezentują prośby o
zmiany i zawierają informacje na ich temat.
• propozycjaZamiany – szczegółowy opis proponowanej zmiany w produkcie
• Zmiana dziedziczy po klasie Problem
76
Klasa
Opis klasy
Atrybuty
Związki
Klasa
Opis klasy
Atrybuty
Związki
Klasa
Opis klasy
Atrybuty
Związki
Klasa
Opis klasy
Związki
Klasa
Opis klasy
Związki
Komentarz
Instancje tej klasy reprezentują pojedyncze komentarze do konkretnych problemów.
• data – data dodania komentarza do problemu
• autor – imię i nazwisko osoby dodającej komentarz
• tresc – treść komentarza
• Komentarz dodany przez Członek zespołu projektowego – związek 1-1 określający,
kto jest autorem komentarza do problemu, pojedynczy komentarz moŜe mieć tylko
jednego autora
• Problem posiada komentarze Komentarz - silna agregacja 0-* reprezentująca zbiór
komentarzy dodanych do pojedynczego problemu
Modyfikacja
Instancje tej klasy reprezentują pojedyncze modyfikacje wprowadzane do opisu konkretnego
problemu. Zbiór instancji dotyczących pojedynczego problemu stanowi kompletny zapis
historii danego problemu.
• data – data wprowadzenia modyfikacji
• rodzaj – dokładny opis co uległo zmianie ze wskazaniem nowej i starej wartości
• autor – imię i nazwisko osoby wprowadzającej modyfikację
• Modyfikacja dokonana przez Członek zespołu projektowego – związek 1-1
określający, kto jest autorem modyfikacji do opisu problemu, pojedyncza modyfikacja
ma tylko jednego autora
• Problem posiada listę modyfikacji Modyfikacja – silna agregacja 0-* reprezentująca
historię zmian pojedynczego problemu
Załącznik
Instancje tej klasy reprezentują pojedyncze załączniki dołączane do konkretnych
problemów.
• data – data dodania załącznika do problemu
• autor – imię i nazwisko osoby dodającej załącznik
• nazwa – nazwa załącznika
• opis – szerszy opis zawartości załącznika
• plik – właściwy plik załącznika
• Załącznik załączony przez Członek zespołu projektowego – związek 1-1 określający,
kto jest autorem załącznika do problemu, pojedynczy załączniks moŜe mieć tylko
jednego autora
• Problem posiada załączniki Załącznik – silna agregacja 0-* reprezentująca zbiór
załącznikó dodanych do pojedynczego problemu
Stan
Klasa abstrakcyjna, której instancje reprezentują indywidualne stany, w jakich moŜe znaleźć
się pojedynczy problem w trakcie swojego cyklu Ŝycia.
• Problem jest w stanie Stan – słaba agregacja 1 – 1 określająca stan, w jakim znajduje
się aktualnie dany problem
• Stan stanowi klasę bazową dla klas reprezentujących konkretne stany
Rozwiązanie
Klasa abstrakcyjna, której instancje reprezentują konkretne rozwiązania pojedynczego
problemu w trakcie swojego cyklu Ŝycia.
• Problem posiada rozwiązanie Rozwiązanie – słaba agregacja 1 – 1 określająca
rozwiązanie, jakie przypisano danemu problemowi
• Rozwiązanie stanowi klasę bazową dla klas reprezentujących konkretne rozwiązania
77
4.7
Dynamika modelu problemu
WaŜnym elementem modelu problemu jest takŜe jego zachowanie w czasie.
Identyfikacja cyklu Ŝycia problemu w projekcie informatycznym była przedmiotem
rozwaŜań w Rozdziale 3 – „Cykl Ŝycia problemu w projekcie informatycznym”, gdzie na
bazie analizy scenariusza obiegu zgłoszenia powstał ogólny opis stanów, w jakich moŜe
się znaleźć pojedyncze zgłoszenie. Standard UML oferuje notacje do modelowania
zachowania zarówno procesów jak i obiektów w nich biorących udział. Notacje te,
w postaci diagramów aktywności oraz stanów, zostały uŜyte do zamodelowania procesu
obsługi problemów.
4.7.1
Diagram aktywności procesu obsługi problemu
Rysunek 4-4 Diagram aktywności procesu obsługi problemu
78
4.7.2
Diagram stanów problemu
Ogólny diagram stanów problemu został zawarty w Rozdziale 3 przy okazji opisu
cyklu Ŝycia problemu w projekcie informatycznym (Rysunki 3-3 oraz 3-4). W kontekście
zaproponowanego modelu, diagram stanów odnosi się do klasy Problem oraz jej klas
potomnych.
4.8
Podsumowanie
Celem tego rozdziału było przede wszystkim stworzenie formalnego modelu
problemu. Przy okazji charakterystyki elementów opisu problemu pokazano jak waŜna jest
precyzja przy gromadzeniu informacji na temat problemów w projekcie informatycznym.
Przeprowadzona analiza, wymienione atrybuty oraz pola opisowe zgłoszenia i wreszcie
zaproponowany model problemu w notacji UML mogą stanowić solidną podstawę do
opracowania rzeczywistej struktury danych w narzędziu będącym celem praktycznej części
pracy dyplomowej.
79
5.
Zarządzanie problemami w projekcie informatycznym
„The greatest challenge to any thinker is stating the problem in a way that will allow a solution"
Bertrand Russel
5.1
Wprowadzenie
Dotychczas treść mojej pracy koncentrowała się głownie na pojęciu problemu, jego
atrybutach i cyklu Ŝycia. W Rozdziale 2 wprowadzone zostało pojęcie zarządzania
problemami, jako działania będącego integralną częścią zarządzania projektem
informatycznym. Wspomniałem wtedy, iŜ zarządzanie problemami stanowi fragment
większego przedsięwzięcia zwanego zarządzaniem konfiguracją projektu informatycznego.
Celem niniejszego rozdziału jest ogólne przedstawienie tego procesu jako całości.
Poruszenie tego zagadnienia, chociaŜ w sposób ogólny, wydaje się konieczne, gdyŜ
obsługa problemów w projekcie informatycznym nie jest procesem autonomicznym i nie
moŜe być rozpatrywana w oderwaniu od pozostałych zagadnień zarządzania konfiguracją.
Znacząca część niniejszego opracowania tematyki związanej z zarządzaniem
konfiguracją została oparta na publikacjach ITIL (Information Technology Infrastructure
Library) [ITILSRV2000]. Metodyka ta zawiera wytyczne dotyczące organizacji procesów
tworzenia i dostarczania usług IT i jest zbiorem reguł opartych na najlepszych praktykach
wypracowanych przez ekspertów, konsultantów, dostawców rozwiązań IT oraz końcowych
uŜytkowników teleinformatyki. Obecnie pracami nad rozwojem standardu kieruje Office
of Government Commerce (OGC), które jest równieŜ twórcą innych znanych światowych
standardów, do których naleŜą m.in.: metodyka zarządzania projektami PRINCE2
(Projects in Controlled Environments version 2), metodyka analizy, specyfikacji
i projektowania systemów informatycznych SSADM (Structured Systems Analysis and
Design Method) oraz metodyka analizy ryzyka i zarządzania nim CRAMM (CCTA Risk
Analysis & Management Method).
5.2
Ogólny opis procesu
Zarządzanie konfiguracją (ang. Software Configuration Management) stanowi
jeden z aspektów projektów informatycznych, którego głównym celem jest wsparcie
prowadzenia projektu, wspomaganie równoczesnej pracy wielu ludzi oraz kontroli
dokonywanych zmian w sytuacji, gdy cel lub wymagania na oprogramowanie są
niestabilne, produkt jest wytwarzany w wielu wersjach lub dla wielu docelowych platform
80
[SZEJ2002]. Termin ten oznacza takŜe właściwą koordynację pracy zespołu poprzez
utrzymywanie sprawnej komunikacji między jego członkami oraz przechowywanie
i ochronę wspólnych zasobów oraz kontrolowanie spójności wersji produktów projektu.
Zarządzanie konfiguracją jest dziedziną inŜynierii oprogramowania, której
znaczenie gwałtownie rośnie wraz ze stopniem złoŜoności systemów informatycznych.
Swoim zakresem obejmuje w całości cykl Ŝycia projektu, a szczególnego znaczenia
nabiera w trakcie jego dalszego rozwoju. Planowanie i kontrola zmian to tylko niektóre
z kluczowych funkcji, jakie pełni w nowoczesnym projekcie informatycznym. Jej
znaczenie jest, więc powaŜne, nie tylko dla zespołów projektowych po stronie wykonawcy,
ale przede wszystkim po stronie klienta.
Zarządzanie konfiguracją jest szczególnie ukierunkowane na wspomaganie
równoległej pracy wielu ludzi nad wspólnym projektem. Sam proces rozumiany jest jako
nadzór nad rozwojem wszelkich elementów składowych projektu i dotyczy wszystkich
produktów powstałych w procesie wytwórczym, zarówno na etapie jego wytwarzania, jak
i dalszej eksploatacji. Zarządzanie konfiguracją eliminuje następujące problemy:
•
niemoŜność odnalezienia aktualnej wersji zasobów projektu
•
powtórne pojawianie się juŜ usuniętych defektów
•
praca nad nieaktualnymi wersjami kodu źródłowego
•
testowanie niewłaściwej wersji systemu
•
zgubienie lub zniszczenie wprowadzonych zmian
•
niemoŜność ustalenia stopnia spełnienia wymagań na system
•
niespójność reprezentacji produktów projektu
NaleŜy pamiętać, Ŝe zasady zarządzania konfiguracją bardzo silnie zaleŜą od
specyfiki danego projektu, a sam plan zarządzania powinien być ustalony juŜ na początku
jego trwania. Za proces ten najczęściej odpowiada kierownik projektu, a do jego głównych
zadań
naleŜą
zapewnienie
zasobów
niezbędnych
dla
efektywnego
zarządzania
konfiguracją, określanie zasad i egzekwowanie ich stosowania oraz kontrola efektywności
stosowanych metod [KUCHZK2005].
81
5.3
Konfiguracja projektu
Przed przystąpieniem do opisu procesu naleŜy zdefiniować sam obiekt jego
zainteresowań. Konfiguracja to zbiór logicznie powiązanych produktów, które muszą być
traktowane i zarządzane jako złoŜona całość uwzględniająca zaleŜności pomiędzy
wersjami części składowych i ich statusami [wwwWIKI]. Elementem konfiguracji moŜe
być dowolny składnik oprogramowania lub otaczającej go infrastruktury, który decyzją
zarządzających projektem jest kontrolowany przez proces zarządzania konfiguracją.
Źródłem wszelkich danych o elementach konfiguracji jest baza danych zarządzania
konfiguracją (ang. Configuration Management Data Base) stanowiąca repozytorium
informacji o wszelkich elementach konfiguracji. Baza ta zawiera szczegóły dotyczące
elementów konfiguracji oraz wzajemnych powiązań pomiędzy nimi. WaŜnym pojęciem
jest takŜe konfiguracja podstawowa (ang. Configuration Baseline), czyli konfiguracja
produktu lub systemu określona w konkretnym momencie w czasie, która obejmuje
zarówno jego strukturę jak i zawartość. W trakcie trwania projektu, jego docelowy produkt
moŜe posiadać wiele, następujących po sobie konfiguracji bazowych.
Zarządzanie konfiguracją zapewnia spójność i porządek poprzez identyfikowanie,
kontrolę, utrzymanie i weryfikację wersji wszystkich elementów wchodzących w skład
projektu. Proces zarządzania konfiguracją musi zostać poprzedzony zdefiniowaniem
zestawu jednostek, które mają podlegać kontroli wersji. Mając zdefiniowany zestaw
elementów konfiguracji moŜna się zająć kontrolą statusu tych obiektów, zarządzaniem
zmianami w jednostkach i ich statusach oraz tworzeniem wersji bazowych (spójnych,
wyróŜnionych zestawów obiektów tworzących system) oraz wydań systemu (wersji
bazowych wypuszczanych poza zespół produkcyjny).
5.4
Zarządzanie konfiguracją
Zarządzanie konfiguracją jest procesem niezwykle złoŜonym i obejmuje swoim
zasięgiem wiele aspektów projektu. Zakres procesu zarządzania konfiguracją obejmuje
przede wszystkim planowanie i definiowanie organizacyjnych i technicznych aspektów
procesu wytwórczego, ze szczególnym uwzględnieniem długoterminowego charakteru
współczesnych projektów informatycznych. Sprawny proces zarządzania konfiguracją
w projekcie przyczynia się do zapewnienia spójności systemu oraz gwarantuje, Ŝe
wszystkie strony zaangaŜowane w cykl produkcyjny będą poinformowane o aktualnym
stanie wytwarzanego oprogramowania. Dostarczanie dokładnych informacji na temat
82
elementów konfiguracji i ich dokumentacji wspiera wszystkie inne procesy zarządzania
usługami i stanowi cenną pomoc w planowaniu czasowym i finansowym. Zasadniczo
moŜna rozbić cały proces zarządzania konfiguracją na trzy logiczne płaszczyzny, które
przedstawia schemat 5-1:
Rysunek 5-1 Trójwymiarowy aspekt zarządzania konfiguracją (źródło własne)
5.4.1
Zarządzanie konfiguracją systemu
Pierwszym wymiarem procesu jest samo zagadnienie zarządzania konfiguracjami,
które związane jest ściśle ze strukturą projektu, tworzonego systemu i wszystkiego, co go
otacza. Ten fragment procesu ma za zadanie kontrolę i zarządzanie wersjami
poszczególnych elementów projektu oraz przechowywanie historii zmian wersji jego
składników oraz zaleŜności pomiędzy nimi. Mają tutaj miejsce działania prowadzące do
identyfikacji, selekcji i oznakowania wszystkich elementów konfiguracji zgodnie
z przyjętym poziomem szczegółowości, zdefiniowanym i dopasowanym do aktualnych
potrzeb danego projektu. Istotna jest takŜe ciągła kontrola mająca na celu zapewnianie, iŜ
tylko
autoryzowane
i
identyfikowalne
elementy
konfiguracji
są
akceptowane
i rejestrowane w bazie danych zarządzania konfiguracją w całym cyklu ich Ŝycia.
W zaleŜności od poziomu szczegółowości i rozpatrywanego zakresu, proces zarządzania
konfiguracją systemu moŜna rozbić na szereg warstw, co obrazuje Rysunek 5-2:
83
Rysunek 5-2 Zakres zarządzania systemu (J.Górski, 2000)
Warto jednak zaznaczyć, Ŝe zarządzanie konfiguracją systemu nie jest
równoznaczne z zarządzaniem zasobami, gdyŜ jej zadaniem jest utrzymanie nie tylko
odpowiedniej informacji dotyczącej zasobów, ale równieŜ informacje o wzajemnych
powiązaniach pomiędzy poszczególnymi elementami.
5.4.2
Zarządzanie problemami
Drugą płaszczyzną jest zarządzanie problemami, czyli zgłoszeniami dotyczącymi
dostrzeŜonych błędów i konieczności zmian w systemie. Zgłoszenia rozumiane są tutaj
jako udokumentowane propozycje zmian poszczególnych elementów konfiguracji,
zarówno te podyktowane zmianami w projekcie jak równieŜ spowodowane wystąpieniem
awarii systemu. Propozycje mogą zostać zgłaszane z róŜnych powodów takich jak
wykrycie defektu, zmiana wymagań funkcjonalnych lub chęć polepszenia jakości
produktu. Rozpatrywanie kaŜdego zgłoszenia wykonywane jest według określonej
procedury, która była przedstawiona w Rozdziale 3 – „Cykl Ŝycia problemu w projekcie
informatycznym”. W wielkim skrócie procedura ta składa się z kilku etapów, które mogą
być porównane do stanów, w jakich moŜe znaleźć się automat skończony. W miarę jak
zgłoszenie zmienia swój stan, dodawane są do niego dodatkowe informacje, które
przybliŜają go do rozwiązania i zamknięcia.
5.4.3
Śledzenie postępu prac
Trzecią płaszczyznę procesu zarządzania konfiguracją stanowi ogólnie pojęta
kontrola nad stanem zaawansowania prac nad systemem, która obejmuje zarówno
planowanie zmian i rozwiązań problemów oraz egzekwowanie ustalonych załoŜeń.
84
Zawiera ona informacje o postępie wprowadzanych zmian do systemu, procencie defektów
w systemie oraz dotychczasowym zuŜyciu zasobów. Głównym zadaniem tej części
procesu
jest
raportowanie
statusu
oraz
rejestrowanie
wszystkich,
bieŜących
i historycznych, danych dotyczących kaŜdego elementu konfiguracji w jego cyklu Ŝycia.
Ocena stanu projektu ma na celu weryfikowanie fizycznego istnienia elementów
konfiguracji oraz sprawdzanie poprawności i aktualności danych w bazie wiedzy.
Obejmuje równieŜ procesy weryfikowania wersji i konfiguracji przed wprowadzeniem
zmian do środowiska docelowego tworzonego systemu [ITILSRV2000].
5.5
Aspekty zarządzania konfiguracją
Zarządzanie
konfiguracją
dotyczy
wszystkich
elementów
projektu
informatycznego, od dokumentacji po kod źródłowy oprogramowania, oraz zmian w nich
zachodzących. Zmiana jest podstawowym, choć niepoŜądanym, zjawiskiem zachodzącym
w projektach informatycznych. Zmiany są odpowiedzią na problemy (defekty i prośby
o zmiany), które pojawiają się w trakcie jego trwania i niekiedy prowadzą do duŜej ilości
modyfikacji. Stopień ich rozległości determinuje ilu elementów konfiguracji dotyczą. Ze
względu na duŜe zróŜnicowanie składników projektu, proces zarządzania szeroko pojętej
konfiguracji moŜna rozbić na szereg podprocesów, które wzajemnie się uzupełniają na
drodze do wspólnego celu. PoniŜej zostały opisane najwaŜniejsze aspekty tych procesów
oraz korzyści płynące z ich wprowadzenia do projektów.
5.5.1
Zarządzanie wymaganiami
Zarządzanie wymaganiami, często teŜ postrzegane jako wynikłe z ewolucji
wymagań, jest procesem mającym na celu kontrolę nad wszelkimi zmianami
w oczekiwaniach klienta. Pozorne jest przeświadczenie, Ŝe jeśli odbiorca systemu ma jasno
sprecyzowane potrzeby, to nie będą one ulegały zmianom w czasie. NaleŜy zwrócić uwagę
na fakt, Ŝe zmiany mogą następować zarówno w zakresie wymagań funkcjonalnych,
niefunkcjonalnych, jak równieŜ mogą generować zmianę w obu tych kategoriach.
Konsekwentnie, wymagania z punktu widzenia systemu moŜna podzielić na dwie poniŜsze
kategorie, przy czym oczywiście w tym wypadku interesująca jest głównie druga z nich:
•
Wymagania trwałe - zwykle naleŜą one do tzw. rdzenia systemu i są ściśle zaleŜne
od działalności firmy, jej charakteru oraz organizacji. Dla przykładu w szkole
zawsze będą istnieli uczniowie, nauczyciele i administracja.
85
•
Wymagania nietrwałe - są to wymagania zaleŜne od rozmaitych zewnętrznych
i wewnętrznych czynników lub teŜ od zarządzeń firmy, które często mogą zaleŜeć
od osób decydujących. Dla przykładu szkoły podlegają ministerstwu, które moŜe
zmienić zasady przekazywania mu raportów z działalności jednostek.
Głównym zadaniem zarządzania wymaganiami jest takie ich dokumentowanie
i kontrolowanie ich ewolucji, aby w dowolnym momencie trwania projektu była moŜliwa
jednoznaczna interpretacja wydobytych wymagań.
5.5.2
Zarządzanie incydentem
Źródłem wszelkich problemów oraz wynikających z nich zmian w projekcie są
bardzo często konkretne zdarzenia. Pod pojęciem incydentu rozumie się takie zdarzenie nie
będące częścią normalnego działania systemu, które powoduje, lub moŜe powodować
przerwę w dostarczaniu usługi lub obniŜenie jej jakości. Incydent moŜe być spowodowany
uszkodzeniem elementu infrastruktury lub niepoprawnym zachowaniem oprogramowania.
Jako, Ŝe tego typu zdarzenia stają się przyczyną konieczności wprowadzania zmian do
konfiguracji systemu, muszą ona takŜe podlegać odpowiedniej rejestracji i zarządzaniu.
Stąd wynika proces zarządzania incydentem, który odpowiada za przywracanie
normalnego działania systemu w moŜliwie najkrótszym czasie oraz odpowiednim
rejestrowaniu kroków podjętych w tym celu. Głównym zadaniem procesu jest zatem
minimalizacja zakłócenia procesu biznesowego wspieranego przez oprogramowanie,
w taki sposób, aby zapewnić osiągnięcie moŜliwie najwyŜszego poziomu dostępności oraz
utrzymanie gwarantowanego poziomu usługi. Do zasadniczego zakresu procesu naleŜą:
•
wykrywanie i rejestrowanie incydentów
•
klasyfikacja incydentów
•
badanie i diagnoza
•
rozwiązanie incydentów w oparciu o bazę wiedzy i przywrócenie normalnego
działania usługi
•
zamykanie incydentów
•
monitorowanie, śledzenie i komunikacja
Głównym celem i zarazem korzyścią wynikającą z zarządzania incydentem jest
minimalizowanie niekorzystnego wpływu niepoŜądanych zdarzeń na wspieraną dziedzinę
biznesową, poprzez ich szybkie rozwiązywanie. Sam proces daje takŜe lepsze śledzenie
86
wyników w odniesieniu do gwarancji zapisanych w umowach, poprawę wykorzystania
personelu i wzrost efektywności świadczenia usług. Sprawnie realizowane zarządzanie
incydentami moŜe prowadzić do całkowitego wyeliminowanie incydentów zgubionych,
nigdzie nie zarejestrowanych i nierozwiązanych oraz zapewnianie dokładniejszych
informacji o elementach konfiguracji poprzez ich ciągła weryfikację prowadzoną podczas
rejestracji kolejnych incydentów.
Warto jednak wspomnieć, Ŝe zasadniczo zarządzanie incydentem obejmuje swym
zakresem rozwiązywanie jedynie standardowych i dobrze zdefiniowanych zgłoszeń, które
mają gotowe, standardowe rozwiązania. PowaŜniejsze problemy zazwyczaj rozpoczynają
swój cykl Ŝycia od konkretnego incydentu, jednak w ich przypadku poszukiwaniem
rozwiązań zajmuje się opisany dalej proces zarządzania problemem.
5.5.3
Zarządzanie problemem
5.5.3.1 Zarządzanie defektami
Zarządzanie defektami to proces, który odpowiada za znalezienie przyczyny
niestandardowego incydentu i znalezienie sposobu na przywrócenie poprawnego działania
systemu lub usługi. Proces ten w załoŜeniu minimalizuje niekorzystne konsekwencje
występowania defektów w systemie i jego infrastrukturze. Do głównych jego celów naleŜy
zapewnianie szybkiego i efektywnego rozwiązywania problemów wynikających z istnienia
defektów poprzez zwiększanie produktywności personelu wspierającego oraz dostarczenie
odpowiedniej informacji zarządczej na temat efektywności radzenia sobie z tego typu
problemami w skali pojedynczego projektu jak równieŜ całej organizacji. Cele te osiąga się
poprzez następujący zakres działań:
•
rejestracja i kontrola obiegu informacji o defektach
•
korelacja priorytetów rozwiązywania problemów z potrzebami biznesowymi
•
identyfikowanie oraz usuwanie defektów
•
minimalizowanie występowania tych samych incydentów w przyszłości poprzez
gromadzenie informacji o rozwiązanych problemach
Z procesem zarządzania defektami wiąŜą się dwa kluczowe pojęcia. Pierwszym
z nich jest kontrola problemu, czyli wszelkie aktywności koncentrujące się na
przekształcaniu ogólnie sformułowanych problemów w dobrze udokumentowane defekty.
Uzyskujemy to poprzez odpowiednią identyfikację, rejestrację i opis zgłaszanych
87
problemów. Kolejnym krokiem jest kontrola defektu, która obejmuje działania
koncentrujące się na rozwiązywaniu znanych defektów.
Wprowadzając zarządzanie defektami do projektu uzyskujemy przede wszystkim
poprawianie jakości naszego systemu poprzez stopniowe zmniejszanie liczby incydentów w pierwszej kolejności tych o duŜym wpływie na proces biznesowy wspierany przez
oprogramowanie oraz systematycznie powtarzających się. Stosując sprawne zarządzanie
defektami z czasem uzyskujemy stałe, systemowe rozwiązania, które eliminują ponowne
pojawianie się incydentów danego typu. Nieocenioną korzyścią jest takŜe stałe zasilanie
bazy wiedzy informacjami o problemach i ich rozwiązaniach.
5.5.3.2 Zarządzanie zmianą
Tak jak incydenty identyfikują problemy, tak te stają się przyczyną konieczności
wprowadzania zmian do projektu i realizowanego oprogramowania. Proces zarządzania
zmianą ma na celu zapewnienie, Ŝe dla wszystkich zmian zostały przyjęte i są uŜywane
standardowe metody, procesy i procedury w celu zapewnienia skuteczności i efektywności
ich wprowadzania. Proces ten zapewnia równowagę pomiędzy pojawiającymi się
potrzebami zmian i ryzykiem ich negatywnego wpływu na prowadzony projekt. Proces
zarządzania zmianą jest odpowiedzialny za kontrolowanie zmian wszystkich elementów
konfiguracji w Ŝyjącym systemie oraz otaczającym go środowisku i obejmuje następujące
działania:
•
inicjowanie zmian
•
rejestrowanie wniosków o zmianę
•
szacowanie wpływu, kosztu, korzyści i ryzyka proponowanych zmian
•
zarządzanie i koordynacja budowy, testów i implementacji zmian
•
monitorowanie i raportowanie implementacji zmiany
Zmiana moŜe być standardowa i stanowić zaakceptowane wcześniej rozwiązanie
zidentyfikowanego i relatywnie prostego problemu lub zestawu nowych wymagań. Jest to
podstawowy rodzaj zmiany, której realizacja przeprowadzana jest najczęściej w formie
oddzielnego projektu lub kolejnej iteracji w rozwoju tworzonego oprogramowania. Istnieją
takŜe zmiany o zwiększonym priorytecie. Pilna zmiana umoŜliwia szybkie przejście przez
proces normalnej zmiany z pominięciem lub uproszczeniem niektórych etapów
(np. testów), przy załoŜonym ryzyku. Tego typu model postępowania stosowany jest
88
zazwyczaj jedynie w sytuacjach awaryjnych, gdzie czas implementacji zmiany jest
krytyczny dla dalszego działania systemu.
Bezsprzeczną korzyścią wynikająca z procesu zarządzania zmianą jest lepsze
dopasowanie systemu i usług do aktualnych potrzeb biznesowych odbiorcy projektu.
Poprzez dobrze zdefiniowany, sformalizowany i odpowiednio prowadzony proces
zyskujemy zmniejszenie niekorzystnego wpływu zmiany na projekt oraz lepsze
oszacowanie kosztów propozycji zmian przed ich wprowadzeniem. Zyskujemy ponadto
polepszenie zarządzania problemem i dostępnością usług poprzez wykorzystanie
informacji zarządczych
związanych ze zmianą oraz podniesienie efektywności
pracowników poprzez zmniejszenie liczby problemów powstających w wyniku błędnych
zmian, a tym samym uzyskujemy zwiększenie moŜliwości obsłuŜenia duŜej ilości zmian.
5.5.4
Zarządzanie wersją
Zarządzanie wersją to całościowe spojrzenie na zmianę oraz zapewnienie, Ŝe
wszystkie aspekty wersji, zarówno techniczne, jak i nietechniczne zostały poprawnie
i łącznie rozpatrzone. Proces ten ma zastosowanie dla duŜych i krytycznych wymian
sprzętu, wprowadzania nowych wersji oprogramowania oraz wiązania i grupowania
zestawów zmian. Zarządzanie wersją jest ściśle związane z procesami zarządzania
konfiguracjami oraz zarządzania zmianą. Procesy te korzystają z tych samych baz wiedzy
zawierających informacje o elementach konfiguracji. Zarządzanie wersją obejmuje
następujące odpowiedzialności:
•
planowanie i nadzorowanie pomyślnych wdroŜeń nowych oraz zmienionych wersji
oprogramowania, jak równieŜ związanego z tym sprzętu i dokumentacji
•
współpraca pomiędzy procesami zarządzania wersją, a zarządzania zmianą, w celu
uzgodnienia właściwej zawartości oraz planu wdroŜenia dla wersji
•
zapewnienie, Ŝe wszystkie elementy, które zostały wdroŜone lub zmienione są
bezpieczne i moŜliwe do śledzenia poprzez bazę wiedzy
•
zarządzanie oczekiwaniami klientów i uŜytkowników dotyczących wersji i procesu
wdroŜenia.
W procesie zarządzania wersją często spotyka się pojęcie biblioteki stosowanego
oprogramowania. Jest to miejsce przechowywania głównych kopii kolejnych wydań
wszystkich kontrolowanych w organizacji wersji oprogramowania. Opis jego zawartości
powinien znajdować się w bazie wiedzy projektu. Kolejnym waŜnym pojęciem jest
89
zarządzanie budową, które oznacza proces grupowania i konfigurowania komponentów
sprzętu i oprogramowania składających się na kolejne wydawane wersje systemu.
Poszczególne wydania oprogramowania powinny podlegać testom i akceptacji
uŜytkowników przed ich wydaniem. W celu zapewnienia maksymalnego bezpieczeństwa
często tworzy się plany wycofań, konieczne na wypadek całkowitych lub częściowych
niepowodzeń we wdroŜeniu wersji. Testy planów wycofań powinny stanowić część
procesu testowania wersji.
W zestawieniu z zarządzaniem zmianą i testowaniem, zarządzanie wersją moŜe
dostarczyć znaczną poprawę jakości usług, jako wynik wyŜszego wskaźnika sukcesu we
wdraŜaniu nowych wersji systemu i minimalizacji zakłóceń w obszarze biznesu.
Bezpośrednimi
korzyściami
są
takŜe
pewność,
Ŝe
uŜywany
sprzęt
i oprogramowanie jest znanej jakości, redukcja moŜliwości uŜycia złego lub
nieautoryzowanego oprogramowania oraz polepszenie wykorzystania zasobów.
5.6
Zarządzanie konfiguracją w najpopularniejszych metodykach
W pierwszej części niniejszego rozdziału został przedstawiony ogólny zarys
procesu zarządzania konfiguracją. O wadze tego aspektu prowadzenia projektów
informatycznych niech świadczy fakt jego istotnej roli w najpopularniejszych standardach
i metodologiach wytwórczych obecnie promowanych na rynku. PoniŜej zostały
uwypuklone cechy wybranych dwu metodyk w kontekście radzenia sobie z opisanymi
wyŜej problemami zarządzania konfiguracją.
5.6.1
Rational Unified Process
Rational Software Corporation, jedna ze znaczących firm produkujących narzędzia
do wspomagania modelowania i implementacji systemów opracowała zalecenia dotyczące
efektywnego rozwijania oprogramowania. Rational Unified Process (RUP) [RUP1998]
kładzie nacisk na iteracyjny (przyrostowy) model rozwoju oprogramowania w połączeniu
z konsekwentnym zarządzaniem wymaganiami. Standard promuje wykorzystywanie
architektur opartych na komponentach i modelowanie wizualne. WaŜnym aspektem RUP
jest ciągła weryfikacja jakości oprogramowania i kontrola zmian w oprogramowaniu.
Metodyka ta jest takŜe wspierana bogatą ofertą oprogramowania firmy Rational, które
w praktyczny sposób implementuje załoŜenia i praktyki definiowane przez standard.
90
Najogólniej rzecz ujmując, w procesie wytwarzania systemu według firmy Rational
wyróŜnia się dwa wymiary cyklu tworzenia aplikacji:
•
Czasowy (poziomy), który reprezentuje dynamiczne aspekty organizacji procesu
tworzenia oprogramowania w czasie. W wymiarze tym są cztery główne fazy:
wstępna, opracowania, implementacji i przekazania. Koniec kaŜdego etapu jest
wyznaczany przez „kamień milowy” (ang. milestone), czyli punkt kontrolny,
w którym sprawdza się, czy są juŜ zrealizowane określone zadania.
•
Statyczny (pionowy), który opisuje, co ma być wytwarzane, przez kogo, kiedy
i w jaki sposób. W opisie tym znajdują się takie pojęcia jak pracownicy
(ang. workers), czyli osoby lub grupy osób, które mają określone zadania
i odpowiedzialność w zespole, działania (ang. activities), czyli konkretne prace
i zadania do wykonania dla określonych pracowników, produkty (ang. artifacts)
czyli materialne efekty działań oraz przepływy (ang. workflows), które opisują
kolejność następowania działań, w wyniku których powstają wyraźnie określone
rezultaty (produkty).
Z punktu widzenia zarządzania konfiguracją interesujące jest przede wszystkim
ostatnie pojęcie wymiaru statycznego. Przepływy opisują kolejność następowania działań,
w wyniku, których powstają określone rezultaty, czyli produkty. KaŜdy przepływ
charakteryzuje interakcję między pracownikami, sposób i wymierne wyniki ich
współpracy. Standard definiuje szereg przepływów takich jak modelowanie biznesowe,
określenie wymagań, analiza i projektowanie, czy implementacja. Oprócz wymienionych
typowo inŜynierskich przepływów zdefiniowano takŜe przepływy wspomagające, wśród
których znajduje się ogólno pojęte zarządzanie projektem oraz zarządzanie konfiguracją
i zmianami (ang. configuration & change management). Ostatni, najbardziej interesujący
z punktu widzenia mojej pracy, przepływ opisuje sposób kontroli wszystkich wyników
prac (dokumentów, modeli, kodu, struktur danych) oraz zarządzanie zmianami
dokonywanymi równolegle, wersjami i powiadomieniami.
W trakcie procesu projektowego, a szczególnie procesu opartego o podejście
iteracyjne, wiele produktów podlega modyfikacji. RUP wspomaga zarządzanie zmianami
dzięki umoŜliwieniu śledzenia zmian w wymaganiach, projekcie implementacji i samej
implementacji. Istnieją zdefiniowane działania (wraz z odpowiednimi artefaktami)
umoŜliwiające śledzenie defektów, nieporozumień czy uzgodnień. U podstaw tego
91
fragmentu RUP leŜy załoŜenie, iŜ zbiory artefaktów oprogramowania tworzą komponenty.
Kierownicy projektów tworzą projekty i przydzielają do nich zespoły w celu pracy nad
komponentami. Programiści pracują nad przydzielonymi im zadaniami, defektami
i prośbami o zmiany. Wszelkie wygenerowane zmiany w elementach konfiguracji (pliki
źródłowe, dokumentacja) są następnie logicznie grupowane w zbiory zmian (ang. change
sets), które po ukończeniu prac przekazywane są do obszaru integracji (ang. project
integration area). Na bazie zestawów zmian tworzone i testowane są nowe wersje bazowe
komponentów, które docelowo integrowane są z wdroŜonym systemem.
W praktyce do zarządzania konfiguracją i kontroli zmian w RUP stosowane są dwa
produkty firmy Rational – ClearCase oraz ClearQuest. Pierwszy z nich to rozbudowany
system do zarządzania konfiguracją, drugi zaś wspomaga proces zarządzania problemami
w projektach. Współpraca obu systemów moŜliwa jest dzięki UCM (ang. Unified Change
Management), który stanowi nakładkę na ClearCase, która integruje oba systemy tak, aby
zmiany wprowadzane do konfiguracji były odzwierciedlane w postaci zmian stanu
zarejestrowanych w ClearQuest problemów. UCM ma za zadanie zespalać działania
mające na celu planowanie i zarządzanie konfiguracją przy jednoczesnym propagowaniu
informacji o postępach prac.
5.6.2
PRINCE2
Standard pochodzi od stworzonej przez angielską firmę Simpact Systems Ltd.
metody zarządzania projektami PROMPT II. Metoda została zaadaptowana przez agencję
rządu Wielkiej Brytanii, zajmującą się projektami teleinformatycznymi. Ostatnia wersja
standardu, PRINCE2 (Projects in Controlled Environments version 2), była najpierw
standardem dla projektów realizowanych przez administrację rządową, jednak obecnie jest
stosowana takŜe przez wiele czołowych firm światowych takich, jak np. Hewlett Packard.
Podstawą PRINCE2 [wwwPRINCE2] jest osiem procesów, które w mniejszym lub
większym stopniu powinny wystąpić w czasie realizacji kaŜdego projektu (przygotowanie
załoŜeń projektu, inicjowanie projektu, strategiczne zarządzanie projektem, sterowanie
etapem, zarządzanie wytwarzaniem produktu, zarządzanie zakresem etapu oraz zamykanie
projektu). Procesy te są ze sobą powiązane i zwykle występują przemiennie w kolejności
wynikającej ze złoŜoności projektu oraz fazy i stanu jego realizacji. Ponadto metodyka
uwypukla istnienie ośmiu komponentów, wśród których wymieniane jest takŜe zarządzanie
konfiguracją produktów oraz sterowanie zmianą.
92
Zarządzanie konfiguracją według PRINCE2 zajmuje się kontrolowaniem
wszystkich produktów projektu i składa się z 5 elementów:
•
Planowanie (Planning)
•
Identyfikacja (Identification)
•
Sterowanie (Control)
•
Charakteryzowanie statusu (Status accounting)
•
Weryfikacja (Verification)
W PRINCE2 wszystkie prośby o zmianę są traktowane jako zagadnienia
projektowe:
•
wnioski o zmianę (request for change) - dotyczące zmiany w wymaganiach albo
produkcie.
•
odstępstwo (off specification) – rejestrowane, kiedy produkt nie spełnia wymagań.
•
sugestie (suggestions)
•
zapytania (queries)
•
zagadnienia ogólne (general issues)
Obsługa wszystkich zagadnień projektowych jest w gestii Kierownika Projektu. Ich
zgłoszenia muszą być udokumentowane w rejestrze zagadnień (Issue Log). Wnioski
o zmianę muszą być zaakceptowane przez Rada Projektu lub Komitet ds. zmian (Change
Authority). Przed akceptacją zmiany musi być wykonana analiza wpływu zmiany.
Odstępstwa (off specification) mogą być załatwiane w ramach działań korygujących przez
Kierownika Projektu o ile nie wykraczają one poza określone dla projektu granice
tolerancji. Rada Projektu moŜe zaakceptować odstępstwa bez uruchamiania działań
korygujących definiując je jako ustępstwo [wwwWIKI].
Metodyka PRINCE2 wprowadza jednolity system dokumentacji projektów oparty
na teczkach (ang. folder). Składają się na niego teczka projektu, teczki poszczególnych
etapów, teczka jakości oraz teczka merytoryczna. KaŜda z nich ma określoną zawartość,
przy czym w kontekście zarządzania konfiguracją największe znaczenie mają dwie
ostatnie. Teczka jakości obok innych elementów zawiera charakterystyki produktów oraz
rejestr problemów realizacyjnych. Teczka merytoryczna z kolei zawiera wszelkie elementy
konfiguracji, rejestr konfiguracji oraz opis lokalizacji elementów i charakterystykę
poprawek specyfikacji wprowadzonych w trakcie projektu. Dzięki takiemu podziałowi
informacje dotyczące róŜnych projektów są spójne. O ile przy realizacji jednego projektu
93
moŜe to nie mieć znaczenia, to juŜ przy realizacji kilku projektów, wprowadzenie
jednolitego systemu dokumentacji oraz określonych wymagań informacyjnych jest jednym
z najwaŜniejszych elementów skutecznego zarządzania projektami.
Warto teŜ zwrócić uwagę na jedno szczególne wymaganie, mianowicie metodyka
PRINCE2 wymaga, aby przed zamknięciem kaŜdego projektu jego realizatorzy opisali
popełnione błędy oraz sposoby rozwiązania występujących problemów. Nikt nie jest
nieomylny, ale prawdziwym błędem jest powtarzanie pomyłek popełnionych wcześniej.
Metodyka zarządzania projektami gwarantuje, Ŝe Ŝadna nauczka z przeszłości nie pójdzie
w zapomnienie.
5.7
Proces zarządzania konfiguracją w kontekście
Celem niniejszego rozdziału jest zaprezentowanie szerokiego spektrum aspektów,
które mieszczą się pod pojęciem procesu zarządzania konfiguracją. Jak widać jest to
zagadnienie złoŜone, obejmujące wiele podprocesów, które korzystając ze wspólnej bazy
wiedzy nawzajem się uzupełniają i wspierają. Rysunek 5-3 stara się zobrazować zaleŜności
zachodzące pomiędzy nimi. Strzałki łączące poszczególne elementy diagramu reprezentują
kierunek przepływu i wykorzystania produktów przynaleŜnych do konkretnych
podprocesów.
Rysunek 5-3 ZaleŜności pomiędzy procesami zarządzania konfiguracją (źródło własne)
Zaznaczony przerywaną linią obszar rysunku określa zakres, jaki w załoŜeniu
obejmuje moja praca dyplomowa. Całościowe, bardziej szczegółowe rozpatrzenie procesu
94
zarządzania konfiguracją wykracza poza jej ramy, zarówno w kontekście części
teoretycznej jak i praktycznej. Poprzednie rozdziały koncentrowały się na zagadnieniach
związanych z definiowaniem, gromadzeniem i dalszą obsługą informacji o defektach
i potrzebach zmian. Zagadnienia te mieszczą się w ramach zarządzania problemami oraz
zmianą i to właśnie na tych aspektach zarządzania konfiguracją będzie się koncentrowała
część praktyczna mojej pracy, której głównym celem jest wytworzenia narzędzia
wspierającego opisywane procesy.
5.8
Podsumowanie
Szerokie pole zarządzania konfiguracją sprawia, ze dotyka ona róŜnych dziedzin
nie koniecznie związanych bezpośrednio z informatyką takich, jak ekonomia czy
zarządzanie. W niniejszym rozdziale moim celem było ogólne przybliŜenie tylko
niektórych jego aspektów. Proces ten jest bez wątpienia jednym z kluczowych zagadnień
inŜynierii oprogramowania. Projekty informatyczne, których celem jest dostarczenie
klientowi
oprogramowania
komputerowego
spełniającego
jego
wymagania,
są
przedsięwzięciami niezmiernie złoŜonymi. Zarządzanie konfiguracją oprogramowania
pozwala nam zapewnić kompletność, dostępność i identyfikowalność wytwarzanych
produktów informatycznych i poszczególnych ich elementów.
95
6.
Przegląd rozwiązań dostępnych na rynku
„When the only tool you own is a hammer, every problem begins to resemble a nail.”
Abraham Maslow
6.1
Wprowadzenie
Jak zostało to opisane w poprzednim rozdziale, proces zarządzania konfiguracją
składa się z wielu oddzielnych i wzajemnie uzupełniających się aspektów. Tematyka mojej
pracy bezpośrednio dotyka w głównej mierze śledzenia problemów oraz pośrednio takŜe
zagadnień związanych z kontrolą wersji. Niniejszy rozdział poświęcony będzie
przeglądowi technologii i narzędzi dostępnych obecnie na rynku, wspomagających te dwie
istotne dziedziny zarządzania konfiguracją. Biorąc pod uwagę zakres pracy dyplomowej
oraz cele jej części praktycznej, analizie podlegać będą aplikacje naleŜące do
następujących dwóch grup:
•
narzędzia do rejestracji i śledzenia problemów (ang. issue tracking systems)
•
narzędzia do kontroli wersji (ang. version control systems)
Omawiając poszczególne grupy aplikacji starałem się wyodrębnić z nich
charakterystyczne cechy w celu stworzenia ogólnego modelu tego typu narzędzi. Takie
podejście ma na celu przygotowanie podstaw do stworzenia funkcjonalnej specyfikacji
wymagań na oprogramowanie mające powstać w części praktycznej mojej pracy
dyplomowej.
Ponadto
opis
został
wzbogacony
krótką
charakterystyką
kilku
najpopularniejszych komercyjnych i darmowych systemów kontroli wersji kodu oraz
śledzenia zmian i defektów. Charakterystyki narzędzi oparte są w głównej mierze na
dokumentacji dostarczanej przez producentów oraz, w niektórych przypadkach, na
własnym praktycznym doświadczeniu zdobytym podczas pracy z nimi w trakcie
rozmaitych projektów akademickich i komercyjnych.
6.2
Narzędzia do ewidencji i śledzenia problemów
Praktyka współczesnych projektów informatycznych pokazuje, Ŝe do ewidencji
defektów i propozycji zmian nie naleŜy podchodzić lekkomyślnie. NierozwaŜne jest
stosowanie karteczek, archiwum emaili, jednego wielkiego dokumentu w edytorze tekstu,
list „to do”, ani tym bardziej pamięci pojedynczych członków zespołu projektowego.
96
Powszechnie znaną prawdą jest fakt, Ŝe lista problemów pojawiających się w trakcie
trwania projektu, jakkolwiek byłaby przechowywana, powinna mieć następujące cechy:
•
gwarantować, Ŝe Ŝadna informacja nie zginie
•
być dostępna dla odpowiednio uprawnionych osób, a nie tylko dla pojedynczego
członka zespołu
•
pozwalać na oznaczanie rzeczy poprawionych w sposób inny niŜ ich skasowanie
•
umoŜliwiać natychmiastowe odnalezienie listy problemów, które ma rozwiązać
konkretna osoba oraz listy problemów dotyczących konkretnego projektu czy
produktu
Odpowiedzią na powyŜej postawiony problem jest zintegrowany system obsługi
problemów, który minimalizuje straty czasu, zwiększa produktywność zespołu oraz
w ogólniejszej perspektywie takŜe satysfakcję klientów. Narzędzia tego typu mogą takŜe
posłuŜyć przy sprawdzaniu poprawności wytwarzanego oprogramowania oraz określeniu
zdolności zespołów do usuwania zgłaszanych problemów. System taki moŜe znacząco
podnieść produktywność pracowników poprzez wprowadzenie udokumentowanego planu
zadań. Zasadniczo narzędzia, o których mowa mają następujące podstawowe
zastosowania:
•
w trakcie trwania projektu - rejestracja rzeczy, które mniej lub bardziej warto
zrobić, ale nie ma na to na razie czasu - warto jednak, by gdzieś ten pomysł został
zapisany
•
przy zamykaniu projektu - usprawnienie przebiegu informacji o błędach
wykrywanych w trakcie testów i zapewnienie, Ŝe Ŝaden wykryty błąd nie zostanie
zapomniany i Ŝe kaŜdy trafi do właściwej osoby
•
w trakcie i po wdroŜeniu - ułatwienie osobom świadczącym wsparcie techniczne
rejestrowania zgłaszanych przez klientów problemów i wymaganych zmian - wraz
z automatycznym powiadamianiem o nich odpowiedzialnych za poszczególne
komponenty
Narzędzia takie posiadają równieŜ moŜliwość szerokiego analizowania sposobu
obsługi problemów w projekcie, co daje kierownikom narzędzie pozwalające na badanie
wydajności zespołów. Przy okazji korzystania z tego typu wsparcia budujemy bazę
informacji do wykorzystania w przyszłych przedsięwzięciach oraz mamy moŜliwość
generowania raportów na temat przebiegu aktualnego projektu.
97
Bardzo istotnym aspektem tej grupy narzędzi jest realizowany przez nie model
problemu oraz sposób jego obiegu w trakcie całego cyklu Ŝycia zgłoszenia. Zazwyczaj
narzędzia do śledzenia defektów i zmian stanowią implementację konkretnego cyklu Ŝycia
zgłoszenia opartego o stany. Zbiór takich stanów jest często z góry ustalony i nie moŜe
podlegać zmianom. NaleŜy pamiętać o tym, Ŝe model oferowany przez dane narzędzie
w znaczący sposób narzuca sposób obsługi problemów w organizacji. Dobór
odpowiedniego narzędzia do śledzenia zagadnień nie tylko usprawnia sam proces
zarządzania problemami, ale takŜe ma wpływ na jego kształt i zakres.
Wbudowane w tego typu systemy moŜliwości przydzielania zagadnień konkretnym
członkom zespołu dają kierownikom projektów narzędzie do efektywnej dystrybucji pracy
nad realizowanym systemem. Zgromadzone w bazie zagadnień dane pozwalają efektywnie
rozplanować harmonogram usuwania wykrytych defektów i ewentualnego wprowadzania
zmian. Ponadto, pod warunkiem rzetelnego uzupełniania danych, zakres wiedzy
o poszczególnych problemach umoŜliwia realną ocenę stanu projektu w dowolnym
momencie jego trwania.
6.2.1
Model narzędzia
Większość
obecnych
na
rynku
narzędzi
do
gromadzenia
informacji
o problemach operuje w modelu otwartym, polegającym na tym, Ŝe do bazy danych
z problemami mają dostęp zarówno członkowie zespołu projektowego jak równieŜ
specjalnie do tego uprawnieni przedstawiciele klienta/odbiorcy produktu. Ze względu na
całkowitą jawność danych, otwarty system zarządzania problemami ma szereg zalet, ale
równieŜ wady. Przede wszystkim umoŜliwia producentom pozostawanie w kontakcie
z klientami i sprzedawcami oraz efektywne powiadamianie o problemach. System taki
pomaga zredukować koszty dzięki wprowadzeniu ścisłego podziału zadań. Klienci mogą
bezpośrednio wprowadzać opisy problemów a takŜe obserwować, co się z nimi dzieje
i w szczególności być powiadamiani o rozwiązaniu lub odrzuceniu problemu. Z drugiej
strony relatywna powszechność dostępu do bazy danych zagadnień w tym modelu, moŜe
znacznie zwiększyć ryzyko powstania chaosu informacyjnego i stawia dodatkowe
zagroŜenia w odniesieniu do poufności danych.
6.2.1.1 Architektura
Zasadniczym celem omawianego procesu jest kontrola nad zgłaszanymi
problemami oraz propozycjami zmian w projekcie. Ze względu na specyfikę warunków
98
pracy współczesnych projektów informatycznych często konieczne staje się zastosowanie
metody kontaktu z klientem, która gwarantowałaby zadowalający poziom komunikacji
przy moŜliwie minimalnej potrzebie bezpośrednich spotkań. W ogólności działanie
otwartego systemu wspomagania zarządzaniem problemami opiera się na Rysunku 6-1:
Rysunek 6-1 Model systemu do gromadzenia zgłoszeń (źródło własne)
Systemy tego typu oparte są zazwyczaj na architekturze typu klient-serwer, gdzie
strona klienta najczęściej jest reprezentowana przez zwykłą przeglądarkę internetową
(system realizowane w technologii WWW). Aplikacje do rejestracji zgłoszeń mają dosyć
proste i "lekkie" interfejsy. Wprowadzenie informacji o nowym problemie, a takŜe
modyfikacja stanu, treści lub atrybutów istniejącego zagadnienia odbywa się poprzez
wypełnienie odpowiedniego formularza na stronie WWW. O istotnych zmianach stanu
problemu są dodatkowo powiadamiani, najczęściej pocztą elektroniczną, osoby aktualnie
przypisane i monitorujące dane zagadnienie oraz autor zgłoszenia. Dodatkową
funkcjonalnością tego typu narzędzi są wszelkie moŜliwości raportujące oraz
wyszukiwawcze. Podstawą jest tutaj moŜliwość wyszukiwania zgłoszeń według
rozmaitych kryteriów (np. wszystkie aktywne zgłoszenia, za które jest odpowiedzialny X,
wszystkie aktywne zgłoszenia dotyczące modułu Y, wszystkie problemy rozwiązane
w ostatnim tygodniu) oraz wszelkiego rodzaju statystyki (np. liczby zgłoszonych
i usuniętych błędów w poszczególnych modułach itp.).
99
6.2.1.2 Kontrola dostępu
Jeśli uŜywamy aplikacji w ramach duŜej organizacji, a tym bardziej, gdy
udostępniamy ją klientom lub uŜytkownikom w Internecie, potrzebny staje się odpowiedni
model uprawnień. Obejmuje on niezaleŜnie uprawnienia do dostępu do poszczególnych
modułów i projektów oraz klasyfikowanie błędów na wewnętrzne i publicznie dostępne.
Pierwsza sprawa jest dosyć oczywista i sprawia, Ŝe w ramach jednej bazy wiedzy moŜemy
przechowywać informacje o problemach w kilku niezaleŜnych projektach. Druga kwestia
jest nieco subtelniejsza - niekiedy wykorzystując publicznie dostępną aplikację chcemy
niektóre błędy ukryć przed klientami (np. obserwacje na temat nieeleganckich rozwiązań
w kodzie, sprawy bardzo techniczne). W tym wypadku zazwyczaj wystarczy klasyfikacja
błędów na "ogólnie dostępne" i "wewnętrzne". Taki model uprawnień musi jednak być
ortogonalny do modelu uprawnień związanego z podziałem na projekty i moduły.
6.2.1.3 Sposób działania
Osoby posiadające konto w systemie mają moŜliwość zgłaszania problemów (uwag
i propozycji zmian) dotyczących dowolnego projektu, do którego mają uprawnienia.
Informacje na temat problemów i propozycji zmian gromadzone są przez narzędzie
w postaci tzw. zagadnień w centralnej bazie danych. KaŜde takie zagadnienie posiada
autora (osoba zgłaszająca dany problem/propozycję) oraz szereg szczegółowych informacji
dotyczących samego zagadnienia. Po zarejestrowaniu w bazie danych wszystkie osoby
będące przypisane do projektu (zarówno wykonawcy jak i klienci) mogą śledzić postęp
w jego rozwiązywaniu. W wielkim skrócie praca z narzędziem przebiega według
następującego schematu:
•
dowolna osoba posiadająca odpowiednie uprawnienia wprowadza informację
o defekcie lub o prośbie o zmianę
•
problem jest wstępnie analizowany przez odpowiednią osobę (najczęściej przez
kierownika projektu) i przypisywany jest konkretnej osobie do rozwiązania, przy
czym niektóre narzędzia oferują automatyczne przypisywanie odpowiedzialności
w oparciu o podane w zgłoszeniu informacje (projekt, moduł)
•
odpowiedzialna osoba akceptuje zgłoszenie albo stwierdza, Ŝe właściwym
odpowiedzialnym jest kto inny i przypisuje problem jemu, moŜe się teŜ zdarzyć, Ŝe
dane zagadnienie jest kolejnym objawem jakiegoś wcześniej zarejestrowanego
problemu
100
•
toczą się prace związane z obsługą problemu, w trakcie których mogą być do niego
dołączane
kolejne
informacje,
moŜe
on
być
"przypisywany"
kolejnym
odpowiedzialnym itp.
•
ostatecznie, odpowiedzialny kończy pracę nad zgłoszeniem na jeden z kilku
sposobów - oznaczając Ŝe problem został poprawiony, stwierdzając, Ŝe poprawiony
z jakichś przyczyn nie będzie albo uznając, Ŝe zgłoszenie było niepoprawne
•
jeśli defekt usunięto lub wprowadzono zmianę do systemu, autor zgłoszenia albo
inna odpowiednio uprawiona osoba weryfikuje, czy zagadnienie faktycznie zostało
rozwiązane prawidłowo i ponownie go aktywuje albo oznacza Ŝe rozwiązanie
zostało zweryfikowane
•
po ostatecznym rozwiązaniu problemu (np. po opublikowaniu albo instalacji
u klienta nowej wersji modułu) zgłoszenie jest zamykane
6.2.1.4 Struktura danych
Nie mniej istotnym aspektem narzędzi do gromadzenia problemów jest sam sposób
ich opisu. Oprócz opisu defektu lub propozycji zmiany, jego aktualnego stanu i przypisanej
odpowiedzialności oraz daty wprowadzenia, definiowane są jeszcze rozmaite dodatkowe
atrybuty. Zestaw pól i atrybutów jest specyficzny dla danego narzędzia. Do
najwaŜniejszych i najczęściej spotykanych pól naleŜą rodzaj problemu (np. błąd krytyczny,
uniemoŜliwiający
działanie
systemu/programu,
błąd
powaŜny,
niezbyt
istotny,
wartościowy luźny pomysł), waga, czyli de facto informacja jak szybko musi to zostać
poprawione (natychmiast, jak najszybciej, w normalnym trybie, w dowolnej przyszłości),
numer wersji programu, w którym wykryto defekt, platforma, czy środowisko systemowe.
PowyŜsza lista często jest adaptowana do potrzeb danej organizacji i niektóre narzędzia
wspomagają moŜliwość dowolnego rozszerzania standardowo zaproponowanego modelu
problemu. Często spotykanym rozwiązaniem jest takŜe moŜliwość dołączania do kaŜdego
zgłoszenia plików w postaci załączników.
6.2.2
Przykładowe narzędzia
Istnieje bardzo obszerny zestaw komercyjnych produktów do rejestracji
i monitorowania błędów. W szczególności większość producentów komercyjnych oferuje
rozwiązania mniej lub bardziej zintegrowane z ich narzędziem do kontroli wersji.
Integracja oznacza zazwyczaj ułatwianie wiązania konkretnych wersji kodu z usuwaniem
konkretnych problemów. Narzędzia tego typu mają jednak pewne powaŜne wady,
101
z których największą jest wysoka cena. Często tego typu oprogramowanie jest płatne „od
stanowiska”, co przy tego typu narzędziach, gdzie zaleŜy nam, by mógł je uŜywać kaŜdy
pracownik i jak najwięcej klientów, moŜe prowadzić do naprawdę powaŜnych wydatków.
Ponadto komercyjne narzędzia trudno przerabiać, a chęć modyfikacji, chociaŜby modelu
problemu, w tego typu zastosowaniach pojawia się często ze względu na daleko idące
specyficzne
cechy
kaŜdego
przedsięwzięcia
informatycznego.
Alternatywą
dla
komercyjnych produktów jest uŜycie pakietu rozprowadzanego na zasadach Open-Source,
tym bardziej, Ŝe istnieją relatywnie rozbudowane i wyrafinowane rozwiązania tego typu.
W dalszej części rozdziału pragnę przedstawić krótko dwa najpopularniejszych z nich.
6.2.2.1 Bugzilla
Bugzilla jest dedykowanym systemem zarządzania problemami. Napisana w Perlu,
została stworzona inicjalnie na potrzeby projektu Mozilla, ale obecnie uŜywana juŜ takŜe
w wielu innych projektach i organizacjach. Bugzilla jest obecnie uznawana za standardowy
system zarządzania problemami, do którego porównuje się wszystkie inne produkty tego
typu. W tym momencie, Bugzilla jest uŜywana w bardzo wielu firmach do pomocy przy
rozwoju ich własnych aplikacji. System umoŜliwia pracę z wieloma projektami
równocześnie
i
implementuje
cykl
Ŝycia
zgłoszeń
bardzo
podobny do
tego
zaprezentowanego w Rozdziale 3. Mechanizmy bezpieczeństwa systemu oparte są na
kontach uŜytkowników, dla których indywidualnie ustalane są uprawnienia i zakres
obowiązków w kaŜdym projekcie. Struktura opisu problemu jest bardzo rozbudowana
i zawiera praktycznie wszystkie atrybuty wymienione w Rozdziale 4 oraz parę
dodatkowych. Brak moŜliwości konfiguracji tej struktury bez ingerencji w kod źródłowy
oraz jej nadmierne skomplikowanie przez wielu uŜytkowników uwaŜane jest za wadę tego
narzędzia. Bugzilla cechuje się bardzo prostym i surowym interfejsem uŜytkownika, ale
jest bardzo stabilną aplikacją i oferuje wiele zaawansowanych i ciekawych funkcji, między
innymi:
•
zintegrowany, oparty na produktach schemat bezpieczeństwa
•
zaleŜności między zgłoszeniami i moŜliwość tworzenia z nich grafów
•
zaawansowane funkcje związane z raportowaniem błędów
•
szybki, stabilny system RDBMS (MySQL)
•
ogromne moŜliwości konfiguracji
•
bardzo wygodny i naturalny system rozwiązywania błędów
•
API do e-mail, XML, konsoli i HTTP
102
•
moŜliwa integracja z aplikacjami do konroli wersji, takimi jak Perforce czy CVS
(przez interfejs e-mail Bugzilli oraz skrypty zapisu/odczytu)
•
czytelny przeglądarkowy interfejs uŜytkownika
•
model przywilejów i uprawnień pozwalający na ustalanie komu co wolno widzieć
i co zmieniać
•
łatwość modyfikowania i uzupełniania - wynikająca zarówno z przechowywania
informacji
w
relacyjnej
bazie
danych
o
czytelnej
strukturze,
jak
z zaimplementowania programu w Perlu
•
moŜliwość "głosowania", który błąd powinien być usunięty jako pierwszy (kaŜdy
uŜytkownik ma do dyspozycji kilka głosów i przypisuje je najbardziej dotkliwym
dlań błędom)
Rysunek 6-2 Formularz zgłoszenia w systemie Bugzilla (projekt Mozilla/Firefox)
Bugzilla moŜe być łatwo dostosowana do róŜnych potrzeb. Aktualni uŜytkownicy
adaptują Bugzillę do wsparcia zadań w dziale IT, rozdziału zadań w Administracji,
projektowania, zarządzania problemami w projekcie (zarówno przed jak i po produkcji),
oraz obsługi problemów sprzętowych tak jak Redhat czy Linux-Mandrake. W połączeniu
103
z takimi narzędziami jak CVS Bugzilla staje się potęŜnym, łatwym w obsłudze
rozwiązaniem do zarządzania konfiguracją.
Więcej informacji na temat samego narzędzia, jego najświeŜsze wersje oraz
obszerną dokumentację uŜytkową moŜna znaleźć na stronie projektu pod adresem
http://www.bugzilla.org.
6.2.2.2 Mantis Bug Tracker
Młodszym bratem Bugzilli jest narzędzie o nazwie Mantis Bug Tracker. Jest to
system wspomagający zarządzanie zgłoszeniami opierający się na technologii języka
skryptowego PHP. Podobnie jak Bugzilla jest to system wykonany w technologii WWW,
który wspiera prowadzenie wielu projektów jednocześnie. System implementuje
kompletny cykl Ŝycia problemu od jego początkowego zgłoszenia, poprzez obsługę,
rozwiązanie oraz ostateczne zamknięcie, przy czym model jest na stałe zaszyty w logice
aplikacji i system nie przewiduje wprowadzania do niego własnych stanów. Struktura
opisu problemu jest bardzo rozbudowana i obejmuje wszystkie najczęściej spotykane
atrybuty
zgłoszenia
(opis
szczegółowy,
dodatkowe
informacje,
powtarzalność,
uciąŜliwość, słowa kluczowe, wersja produktu itp.). Zakres gromadzonych danych moŜna
w łatwy sposób rozszerzyć o dodatkowe pola słownikowe z poziomu panelu
administracyjnego konkretnego projektu. Mantis rejestruje pełną historię zmian kaŜdego
zgłoszenia oraz umoŜliwia dodawanie do nich komentarzy oraz załączników. Zakres
funkcjonalności udostępnianej poszczególnym uŜytkownikom systemu jest ustalany na
podstawie przydzielonych im uprawnień, zarówno w odniesieniu do całego systemu jak
i poszczególnych projektów, których uŜytkownik jest uczestnikiem. System udostępnia
ponadto wiele opcji związanych z wyszukiwaniem, zarządzaniem i raportowaniem
problemów. Dodatkowo system moŜna skonfigurować tak, aby wybrane przez nas
zdarzenia były automatycznie rozsyłane za pośrednictwem poczty elektronicznej do
wszystkich zainteresowanych. Podsumowując, system Mantis jest bardzo elastycznym
i rozbudowanym narzędziem, posiadającym wiele przydanych funkcji i cech takich jak:
•
łatwość instalacji i konfiguracji
•
moŜliwość działania w dowolnym środowisku (zarówno Windows jak i Linux)
•
współpraca z większością najpopularniejszych systemów RDBMS (MySQL,
PostreSQL)
•
elastyczny system uprawnień oparty na role
104
•
rozbudowane systemy wyszukiwawcze i raportujące
•
moŜliwość rozszerzania struktury opisu problemu bez ingerencji w kod źródłowy
•
przyjazny interfejs uŜytkownika oparty na formularzach WWW i technologii Ajax
•
rozsyłanie powiadomień mailowych przy kaŜdej zmianie stanu zagadnienia
•
dodawanie komentarzy i załączników do zagadnień
•
dostępność polskiej wersji językowej
Rysunek 6-3 Formularz zgłoszenia błędu w systemie Mantis
System jest stale rozwijany przez społeczność Open-Source i rokuje spore nadzieje
na przyszłość. Jednocześnie otwartość kodu źródłowego oraz zastosowanie popularnej
technologii PHP czyni go łatwym do modyfikacji. System Mantis sprawdził się
w zastosowaniach praktycznych. Osobiście miałem okazję z niego korzystać w trakcie
projektów realizowanych w trakcie studiów oraz przy przedsięwzięciach komercyjnych.
W obu przypadkach narzędzie spełniło swoje zadanie i w widoczny sposób przyczyniło się
do polepszenia efektywności pracy całego zespołu projektowego.
105
Więcej informacji na temat samego narzędzia, jego najświeŜsze wersje oraz
obszerną dokumentację uŜytkową moŜna znaleźć na stronie projektu pod adresem
http://www.mantisbt.org/.
6.3
Narzędzia do kontroli wersji
Praktyka współczesnych projektów informatycznych dobitnie pokazuje, Ŝe
tworzenie oprogramowania bez wykorzystania systemu zarządzania wersjami jest bardzo
trudne, jeśli nie niemoŜliwe. Coraz częściej spotykane rozproszone środowisko wytwórcze,
sprawia, Ŝe bezwzględnie musi istnieć repozytorium, w którym zawsze znajduje się pełny
i aktualny zbiór zasobów projektu, obejmujący wszystko od kodu źródłowego tworzonych
systemów i na wszelkiego rodzaju dokumentacji kończąc. W przypadku złoŜonych
projektów musi być moŜliwe dokładne odtworzenie stanu i zakresu zasobów, z których
zbudowano dystrybucję systemu aktualnie działającego u klientów. Wreszcie, musi być
dostępna historia zmian, zarówno w formie opisów podawanych przez wprowadzających
modyfikacje, jak i bezpośredniego porównania poszczególnych zasobów. WyŜej
wymienione potrzeby ujawniają się nawet w projektach realizowanych przez pojedyncze
osoby na przestrzeni kilku miesięcy. Gdy nad przedsięwzięciem informatycznym pracuje
kilkunastoosobowy zespół, a projekt trwa wiele miesięcy, brak zarządzania wersjami daje
praktyczną pewność ogromnych problemów.
Kontrola wersji (ang. version control) to w ogólności zarządzanie róŜnymi
odmianami konkretnego produktu programistycznego. Proces ten powinien odwzorować
zaleŜność pomiędzy poszczególnymi wersjami produktu, zarządzać częściami wspólnymi
dla wielu wersji, umoŜliwić równoległą pracę wielu uczestników projektu tworzących
nowe wersje. Kontrolę wersji uwaŜa się za powaŜny problem technologiczny, którego
rozwiązaniem są narzędzia opisane w dalszej części tego rozdziału.
6.3.1
Model narzędzia
Zasadniczym celem procesu zarządzania konfiguracją jest ukierunkowanie na
wspomaganie równoległej pracy wielu uczestników projektu oraz nadzór nad rozwojem
wszelkich elementów składowych projektu informatycznego powstałych zarówno na etapie
wytwarzania jak i jego późniejszej eksploatacji. Szczególnie waŜnym jest utrzymywanie
kontroli
nad
wersjami
poszczególnych
składników
oprogramowania
będącymi
w środowisku wytwórczym i docelowym.
106
6.3.1.1 Podstawowe pojęcia
We wszystkich dostępnych na rynku systemach kontroli wersji uŜywa się zestawu
podstawowych pojęć związanych z opisywanym procesem. PoniŜsze pojęcia stanowią
jednocześnie zbiór podstawowych funkcjonalności, jakie musi oferować narzędzie do
kontroli wersji:
•
Artifact (produkt) – dowolny składnik projektu informatycznego np. kod
źródłowy, rysunek lub dokument
•
Repository (repozytorium) – miejsce przechowywania zasobów w systemie
kontroli wersji, niekoniecznie baza danych, często pewna specyficzna struktura
katalogów z opisami.
•
Kopia robocza – miejsce, w którym znajdują się kopie lokalne pobranych
z repozytorium zasobów, nad którymi pracuje konkretny uczestnik projektu,
najczęściej jest to katalog na lokalnym komputerze wykonawcy
•
Get (pobranie) – pobranie aktualnych wersji wszystkich lub wybranych zasobów
z repozytorium, w domyśle jest to pobranie bez intencji ich zmiany
•
Check-out (wybranie) – pobranie zasobów z serwera z zamiarem ich modyfikacji,
w niektórych narzędziach wiąŜe się z nałoŜeniem blokady na dany zasób
•
Check-in (wstawienie) – po zakończeniu prac nad lokalnymi zasobami następuje
proces zwrócenia ich nowych wersji do repozytorium, tak, aby kaŜdy mógł je
pobrać w najnowszej wersji, w przypadku stosowania blokad, zasoby są po tym
procesie zwalniane
•
Lock (blokada) – zablokowanie innym uŜytkownikom moŜliwości wybrania
konkretnego zasobu (check-out)
•
Label (etykieta) – oznaczenie nazwą grupy zasobów w celu łatwiejszej ich
identyfikacji
•
Branch (gałąź) – stworzenie alternatywnej linii wersjonowania, co pozwala na
rozwój tego samego zasobu w róŜnych kierunkach, np.: wprowadzanie poprawek
do starej wersji i dodawanie funkcji do nowej wersji.
•
Merging (połączenie) – łączenie dwóch wersji konkretnego zasobu w jeden, moŜe
się odnosić do dwóch sytuacji: łączenia gałęzi i rozwiązywania konfliktów
w systemach bez blokad
Warto jednak zaznaczyć, Ŝe nie wszystkie narzędzia dostępne na rynku
wykorzystują mechanizmy blokady. Blokada jest sposobem na uniknięcie sytuacji,
107
w której dwie osoby zmieniają ten sam plik. JeŜeli operacja Check-out zakłada blokadę na
zmianę pliku to nikt inny nie moŜe go wybrać ani wstawić (Check-in) jego nowej wersji.
Podejście takie praktycznie uniemoŜliwia zaistnienie konfliktu, jednak powaŜnie ogranicza
moŜliwość współbieŜnej pracy nad zasobami. W praktyce narzędzia często oferują
rozwiązanie pośrednie, stosując blokady tylko na plikach binarnych, pomijając przy tym
zasoby tekstowe, które znacznie łatwiej poddać procesowi scalania w przypadku
napotkania konfliktu.
6.3.1.2 Sposób działania
Korzystając z powyŜszej terminologii pracę z systemem kontroli wersji moŜna
opisać przez stały ciąg działań. Na początku tworzone jest repozytorium projektu, do
którego dodawane są wszystkie związane z projektem zasoby. W trakcie projektu kaŜda
zainteresowana strona (programista, tester) pobiera (Get) całość zasobów projektu
z repozytorium do swojego lokalnego katalogu roboczego. Osoba pragnąca wprowadzić
modyfikacje do zasobów wybiera (Check-out) zasoby mające podlegać edycji i dokonuje
modyfikacji wybranych zasobów. Po zakończeniu pracy nad konkretnymi zasobami są one
wstawiane (Check-in) z powrotem do repozytorium. JeŜeli w trakcie tej ostatniej operacji
okaŜe się, Ŝe ktoś inny modyfikował zasób, który wstawiamy to konieczne staje się
przeprowadzenie procesu połączenia (Merge) obu wersji zasobu. Uproszczony model
pracy z systemem kontroli wersji przedstawia Rysunek 6-4.
Rysunek 6-4 Model narzędzia do kontroli wersji (źródło własne)
Warto zaznaczyć, Ŝe nawet najbardziej rozbudowany system do kontroli wersji nie
rozwiązuje wszystkich problemów w zespole programistycznym. Jest on tak naprawdę
108
częścią większej całości, mianowicie systemu zarządzania zmianą. DuŜe komercyjne
systemy zarządzania zmianą pozwalają na łączenie zmian w kodzie z Ŝądaniami zmiany
i śledzeniem błędów. Takie podejście pozwala na dokładniejsze zarządzanie projektem
i pracą nad produktem. Samo podejście do projektu przez pryzmat Ŝądań zmiany i próśb
o funkcjonalność porządkuje pracę, która musi być wykonana i pozwala na jej właściwą
organizację.
6.3.2
Przykładowe narzędzia
Rynek narzędzi do zarządzania wersjami, czy teŜ zarządzania konfiguracją, co
oprócz zarządzania wersjami obejmuje procedury budowy kodu, rejestracji błędów,
powiadamiania o zmianach itp., jest bardzo bogaty. Są to jednak w większości przypadków
produkty dosyć prymitywne (CVS, RCS, SCCS, SourceSafe, PVCS), bądź drogie
(Perforce, StarTeam, Razor) albo bardzo drogie (ClearCase, Continouous). W dalszej
części rozdziału pragnę przedstawić krótką charakterystykę dwóch narzędzi tego typu.
6.3.2.1 CVS
CVS to prawdopodobnie najbardziej rozpowszechniony system zarządzania
wersjami plików. Narzędzie moŜe pracować zarówno jako serwer jak i na pojedynczej
maszynie. Narzędzie w swojej rdzennej postaci posiada jedynie interfejs tekstowy – dostęp
do wszelkiej funkcjonalności uzyskujemy poprzez zestaw komend wywoływanych w linii
poleceń. CVS jest wykorzystywany przez większość projektów Open-Source, gdzie
z jednego repozytorium korzystają nieraz setki programistów rozproszonych po całym
świecie. CVS działa na bardzo szerokim zestawie platform sprzętowych i systemowych.
Intensywne jego uŜywanie w wielu projektach owocuje takŜe pojawianiem się wielu
aplikacji wspomagających.
CVS działa bez stałego podłączenia do repozytorium, które wymagane jest jedynie
w trakcie aktualizowania kopii roboczej i zatwierdzania zmian. Repozytorium CVS to
zbiór, rozłoŜonych w odpowiednich katalogach, archiwów (jedno archiwum na jeden
wersjonowany plik). Jeśli któryś z tych plików ulegnie uszkodzeniu, wszystkie pozostałe
nadal pozostają w pełni dostępne. Jeśli chcemy podzielić repozytorium na dwa, zmienić
jego strukturę albo przenieść całość lub część na inną maszynę, wystarczy odpowiednio
skopiować strukturę plików i katalogów.
CVS nie blokuje plików. Jeśli modyfikowany zasób od momentu ostatniego
pobrania został zmodyfikowany przez kogoś innego, CVS uniemoŜliwia zatwierdzenie
109
zmian wymagając w zamian aktualizacji lokalnej kopii. Jeśli zmiany dotyczyły róŜnych
miejsc pliku wbudowane w narzędzie mechanizmy łączą zmiany w jedną spójną wersję
zasobu. W przypadku bardziej złoŜonego konfliktu CVS generuje raport rozbieŜności
i wymaga od programisty ich samodzielnego rozwiązania.
NajpowaŜniejszą wadą CVS jest brak moŜliwości ingerencji w strukturę katalogów
z jednoczesnym zachowaniem wersji zasobów oraz brak moŜliwości zmiany ich nazw.
Kolejną istotną wadą jest takŜe konieczność sztywnego zaprojektowania struktury
katalogów, poniewaŜ nie podlegają one procesowi wersjonowania. Ponadto brak transakcji
przy wstawianiu plików moŜe w szczególnych sytuacjach prowadzić do powaŜnych
problemów. Ciekawą zaletą, ale równieŜ wadą, jest przechowywanie przez CVS
kompletnych plików w ich kolejnych wersjach. Zaletą, bo łatwo naprawić repozytorium
w przypadku awarii, wadą, gdyŜ trzymanie w ten sposób duŜego projektu moŜe owocować
duŜym apetytem systemu na przestrzeń dyskową.
Pomimo duŜych moŜliwości CVS nie jest systemem zarządzania konfiguracją,
a jedynie dobrym systemem zarządzania wersjami. Nie obsługuje rejestracji błędów
i wiązania ich z poprawkami. Nie implementuje procedur kompilacji i tworzenia
dystrybucji. Nie daje moŜliwości określania stanu poszczególnych modułów ani nie
definiuje i nie wymusza Ŝadnego standardowego procesu rozwijania kodu. CVS jest
dostępny na róŜne platformy. Istnieje wiele graficznych interfejsów ułatwiających pracę
z CVS, takich jak WinCVS albo TortoiseCVS dla platformy Windows.
Więcej informacji na temat samego narzędzia, jego najświeŜsze wersje oraz
obszerną dokumentację uŜytkową moŜna znaleźć na stronie projektu pod adresem
http://www.nongnu.org/cvs/.
Relatywnie nowym, takŜe darmowym, systemem, który powstał głownie z myślą
o naprawieniu problemów występujących w CVS jest Subversion (znany takŜe pod nazwą
SVN). Jest on alternatywą bezpieczną (o bezpieczeństwo dba moduł SSL serwera Apache)
i pozbawioną braków swego poprzednika, takich jak brak kontroli wersji struktury
katalogów. Narzędzie jest wciąŜ rozwijane i sprawdziło się w praktyce podczas realizacji
projektu grupowego w roku akademickim 2005/06 w Katedrze InŜynierii Systemów i Baz
Danych. Podobnie jak w przypadku CVS, na rynku dostępnych jest wiele aplikacji
wspomagających, jak chociaŜby graficzny interfejs TortoiseSVN. Więcej informacji na
110
temat tego narzędzia, jego najświeŜsze wersje oraz obszerną dokumentację uŜytkową
moŜna znaleźć na stronie projektu pod adresem http://subversion.tigris.org/.
6.3.2.2 Reliable Software Code CoOp
Na tle innych aplikacji, bardzo ciekawą alternatywą jest komercyjne narzędzie
Reliable Software o nazwie Code CoOp. Jest to program o idei zgodnej
z narzędziami pokroju CVS, z jedną zasadniczą róŜnicą, polegającą na kompletnym braku
centralnego serwera (repozytorium) do przechowywania wersji zasobów. Zawartość
repozytorium projektu jest replikowana na wszystkich maszynach biorących udział
w projekcie. Wymiana plików odbywa się za pomocą poczty elektronicznej lub poprzez
współdzielone katalogi w sieci LAN. KaŜda zatwierdzona zmiana w kodzie źródłowym
jest rozsyłana do wszystkich uczestników projektu. Aplikacja działa jedynie w środowisku
Windows i integruje się ze środowiskami programistycznymi (m.in. Visual Studio
2003/05) poprzez interfejs MS SCC API.
Rysunek 6-5 Główne okno systemu Code CoOp
Więcej informacji na temat narzędzia oraz wersje demonstracyjne wraz
z obszerną dokumentacją uŜytkową moŜna znaleźć na stronie producenta pod adresem
http://www.relisoft.com/co_op/.
111
6.3.3
Zestawienie cech
PoniŜsza tabelka zawiera rozbudowane porównanie bardzo licznej grupy narzędzi
do kontroli wersji kodu, wśród których znajdują się takŜe opisywane wyŜej systemy.
Porównanie zostało opracowane na podstawie materiałów udostępnianych przez firmę
Reliable Software [wwwRELI]. Jaśniej zacieniowane pola oznaczają tylko częściowe
posiadanie danej cechy przez narzędzie.
Wspomaganie cyklu Ŝycia
Zarządzanie wydaniami
Wsparcie procesu wytwórczego
Zastosowanie w korporacjach
Wbudowane śledzenie błędów
Współdzielenie plików
Powrót w dowolnym momencie
Praca w trybie off-line
Scalanie
Działanie oparte o zmianę
Atomowe zatwierdzanie zmian
Wieloplatformowość
Raportowanie
Powiadamianie poprzez e-mail
Rozgałęzianie
Zmiana nazwy / przenoszenie
Kompresja / delty
Rozproszenie pracy
Integracja z narzędziami IDE
Integracja z SCC API
Do $200 za licencję
CVS
Subversion
QVCS-Pro
QVCS Ent.
Code Co-op
W przedziale $200 - $500 za licencję
CS-RCS Pro
Vault
CS-RCS Browser
Team Coherence Pro
Visual SourceSafe
W przedziale $500 - $1000 za licencję
Evolution
SurroundSCM
Team Coherence Ent
Firefly
Borland Starteam
Perforce
SpectrumSCM
Accurev Pro
Ponad $1000 za licencję
Razor
Borland Starteam Ent
Bitkeeper
Accurev Enterprise
Serena Changeman Pro
Wyjaśnienie poszczególnych cech:
•
Integracja z SCC API – narzędzie jest oferuje interfejs kompatybilny ze standardem MS SCC API
•
Integracja z narzędziami IDE – narzędzie integruje się z innymi środowiskami wytwórczymi nie wspierającymi MS SCC API
(np. Borland Delhi)
•
Rozproszenie pracy – narzędzie wspiera pracę w warunkach rozproszonych
•
Kompresja / delty – narzędzie kompresuje pliki przy ich dystrybucji, przesyłane są jedynie fragmenty zmienione (nie całe wersje
plików)
•
Zmiana nazwy / przenoszenie - narzędzie umoŜliwia zmianę nazw plików i ich przenoszenie w strukturze katalogów
112
•
Rozgałęzianie – narzędzie umoŜliwia tworzenie niezaleŜnych ścieŜek rozwoju plików
•
Powiadamianie poprzez e-mail – narzędzie powiadamia wszystkich zainteresowanych o zmianach dokonanych na plikach
•
Raportowanie – narzędzie generuje raporty na temat stanu projektu
•
Wieloplatformowość – narzedzie dostępne na wielu platformach (Windows, Linux)
•
Atomowe zatwierdzanie zmian – kaŜda zmiana wykonywana jest jako atomowa transakcja
•
Działanie oparte o zmianę – narzędzie pozwala na zatwierdzenie wielu zmian w jednej operacji typu check-
•
Scalanie – narzędzie posiada wbudowane mechanizmy scalania
•
Praca w trybie offl-ine – narzędzie umoŜliwia pracę nad plikami bez połączenia z repozytorium
•
Powrót w dowolnym momencie – narzędzie umoŜliwia cofnięcie zmian w dowolnym momencie
•
Współdzielenie plików – narzędzie umoŜliwia współdzielenie plików pomiędzy projektami
•
Wbudowane śledzenie błędów – narzędzie posiada wbudowaną funkcjonalność zarzadzania problemami
•
Zastosowanie w korporacjach – narzędzie przystosowane do pracy w bardzo duŜych zespołach
•
Wsparcie procesu wytwórczego – narzedzie wspomaga process wytwórczy i pozwala go modyfikować
•
Zarządzanie wydaniami – narzędzie wspomaga process budowania i wydawania wersji oprogramowania
•
Wspomaganie cyklu Ŝycia – narzędzie znajduje zastosowanie w całym procesie wytwórczym
Rozkład cech poszczególnych produktów wyraźnie dzieli porównywane systemy
na te tańsze, ale oferujące mniejszą funkcjonalność oraz te zdecydowanie droŜsze, które
w zamian za wysoką cenę idą bardziej w kierunku zintegrowanych systemów zarządzania
konfiguracją.
6.4
Podsumowanie
Na rynku istnieje wiele aplikacji wspomagających zarządzanie bazą problemów,
jednak nawet w przypadku ich stosowania istotne jest wypracowanie własnych standardów
pomocnych przy kategoryzacji pojawiających się defektów i propozycji zmian. Podczas
standaryzacji niezbędna jest współpraca testerów z programistami, a niejednokrotnie
równieŜ z analitykami. Niemniej jednak doświadczenia współczesnych projektów
informatycznych wskazują, Ŝe juŜ samo uŜycie rejestru problemów:
•
wspomaga i formalizuje komunikację
•
umoŜliwia wyznaczenie zakresu zmian w elementach konfiguracji
•
wspomaga zarządzanie projektem informatycznym przez delegację zadań,
planowanie ich rozpoczęcia oraz planowanie i sprawdzanie pracochłonności
•
wspiera proces zbierania pomiarów (liczba problemów, pracochłonność)
•
umoŜliwia ocenę bieŜącego stanu projektu (np. liczba problemów zgłoszonych
róŜnica pomiędzy liczbą zgłoszonych a zamkniętych)
113
•
pozwala na poprawę technologii przez analizę większej liczby problemów
i zdefiniowanie mechanizmów mających na celu niedopuszczenie do powstawania
tych samych problemów w przyszłości
Pośrednim celem powyŜszego rozdziału było takŜe ukazanie zaleŜności pomiędzy
procesem zarządzania problemami i kontrolą wersji zasobów projektu. Jak wiadomo, baza
wiedzy o problemach stanowi integralny element konfiguracji projektu i powinna podlegać
tym samym zasadom wersjonowania co kod źródłowy czy dokumentacja. Celowi temu
posłuŜyło przedstawienie idei działania narzędzi do kontroli wersji. Przedmiotem
praktycznej części mojej pracy będzie m.in. wykorzystanie moŜliwości, jakie dają dwa
z opisywanych tutaj narzędzi do kontroli wersji przy realizacji rozproszonego narzędzia do
gromadzenia danych o problemach.
114
7.
Narzędzie wspomagające proces zarządzania problemami
“For every complex problem there is a solution that is simple, neat, and wrong”.
H. L. Mencken
7.1
Wprowadzenie
Jednym z głównych celów mojej pracy dyplomowej jest wytworzenie narzędzia
wspomagającego proces zarządzania problemami w projektach informatycznych. Zebrane
i opracowane w poprzednich rozdziałach podstawy teoretyczne miały w załoŜeniu nie
tylko prezentować wartość badawczą, ale takŜe być po części podporządkowane temu
celowi. Zaproponowany ogólny model problemu w połączeniu z obserwacjami
wynikającymi z analizy narzędzi tego typu miał pozwolić na budowę systemu, który
będzie funkcjonalnie kompletny i jednocześnie znajdzie zastosowanie przy wspomaganiu
procesu zarządzania problemami w rzeczywistych projektach. Głównym celem przy
projektowaniu narzędzia była chęć pokazania praktycznej wartości wiedzy zgromadzonej
i usystematyzowanej w części teoretycznej mojej pracy dyplomowej. Powstały system jest
konkretną
implementacją
ściśle
określonego
podzbioru
pojęć
i
koncepcji
zaprezentowanych w Rozdziałach 2-5 oraz czerpie bardzo wiele z doświadczeń
i praktycznych rozwiązań oferowanych przez systemy juŜ dostępne na rynku.
Przy formułowaniu tematu pracy dyplomowej przyjąłem dodatkowe dwa
wymagania odnośnie rozproszonego modelu pracy systemu oraz jego niezaleŜności od
centralnego pojemnika danych. W moim odczuciu były to podstawowe cechy, które
powinno posiadać narzędzie wyróŜniające się na tle rozwiązań obecnie dostępnych na
rynku. W dobie wszechobecnego Internetu moŜliwość pracy grupowej w warunkach
rozproszonych wydawała się oczywista, z kolei zdecentralizowanie warstwy danych miało
w załoŜeniu sprzyjać podtrzymaniu takiego modelu pracy takŜe przy braku niezbędnej
infrastruktury technicznej, czy teŜ stałego dostępu do zasobów sieci. Ze względu na własne
doświadczenia druga z wymienionych cech była przeze mnie traktowana priorytetowo.
W trakcie pracy nad rozmaitymi projektami akademickimi i komercyjnymi osobiście
odczułem brak odpowiedniego wsparcia narzędziowego dla małych i średnich zespołów
projektowych nie mających dostępu do centralnego serwera przechowującego bazę danych
o problemach.
115
Chęć spełnienia wyŜej postawionych załoŜeń stała się jednocześnie przyczyną
poruszenia w praktycznej części mojej pracy wielu zagadnień specyficznych dla
oprogramowania o architekturze rozproszonej. Postawione wymagania były źródłem
konkretnych decyzji projektowych, z których najwaŜniejszą była integracja warstwy
danych opracowywanego systemu z narzędziami do kontroli wersji. MoŜliwości, jakie dają
tego typu narzędzia okazały się odpowiedzią na problemy związane z rozproszeniem
i replikacją zdecentralizowanej bazy danych i jednocześnie nakreśliły ogólną koncepcję
logiki działania systemu. Wykorzystanie plików XML jako pojemnik danych było logiczną
konsekwencją decyzji o integracji z narzędziami do kontroli wersji ze względu na ich
najlepszą współpracę z plikami tekstowymi. Nie bez znaczenia miał teŜ fakt, Ŝe format ten
stał się w ostatnich latach niepisanym standardem zapisu i przekazu ustrukturalizownaych
danych w formie tekstowej, zwłaszcza w Internecie. Obie decyzje projektowe zostały
podjęte we wczesnych etapach nakreślania wizji mającego powstać systemu, a ich
konsekwencje pojawiają się zarówno w specyfikacji wymagań jak i projekcie narzędzia.
Niniejszy rozdział jest głownie poświęcony technicznym aspektom pracy
dyplomowej.
Moim
celem
jest
zaprezentowanie
rozwiązania
ze
szczególnym
uwzględnieniem wpływu wyŜej opisanych decyzji projektowych na kształt i sposób
działania powstałego narzędzia. Rozdział zawiera wiele technicznych szczegółów
realizowanego systemu jednak nie naleŜy traktować go jako kompletny projekt systemu.
Rozdział zawiera przedstawienie ciekawszych aspektów realizowanego projektu,
konkretnych problemów technicznych oraz ich rozwiązań. Efekty prac nad systemem
zostały opisane na końcu niniejszego rozdziału w postaci instrukcji obsługi narzędzia,
opisu procedury jego testowania oraz wniosków z jego stosowania w rzeczywistym
projekcie.
7.2
Specyfikacja wymagań
Celem tego podpunktu jest przedstawienie zawartości specyfikacji wymagań
systemowych, której kompletna wersja znajduje się w Załączniku „BAGGU –
Specyfikacja Wymagań Systemowych”. Pełny dokument rozpoczyna się określeniem
rozpatrywanego problemu, w ramach którego definiowane są główne cele i zakres
projektowanego systemu oraz identyfikowani są wszyscy jego udziałowcy. W dalszej
części dziedzina problemowa podlega bardziej szczegółowej analizie mającej na celu
wyznaczenie granic systemu, wyspecyfikowanie zdarzeń biznesowych oraz umieszczenie
116
systemu w szerszym kontekście. Specyfikację zamyka opis przypadków uŜycia oraz zbiór
ostatecznie wyspecyfikowanych wymagań wobec mającego powstać narzędzia.
7.2.1
Cele biznesowe
Przed przystąpieniem do analizy dziedziny problemowej zazwyczaj ustalane są
konkretne cele, których spełnienie będzie wyznacznikiem sukcesu danego przedsięwzięcia.
W przypadku projektu realizowanego w ramach praktycznej części mojej pracy
dyplomowej ostatecznie uznałem następujące cele za nadrzędne:
1. Systematyzacja i wspomaganie procesu zarządzania problemami w projektach
informatycznych
2. UniezaleŜnienie procesu zarządzania problemami od konkretnego projektu
3. Odwzorowanie modelu problemu w postaci narzędzia
4. Usprawnienie procesu zarządzania problemami
5. UmoŜliwienie prowadzenia procesu zarządzania problemami w zespołach
rozproszonych
6. Wykorzystanie moŜliwości narzędzi do kontroli wersji
7. UniezaleŜnienie rejestru problemów od centralnego pojemnika danych
8. Wykonanie pracy dyplomowej
KaŜdy z wymienionych wyŜej celów został w Załączniku „BAGGU – Specyfikacja
Wymagań Systemowych” opisany pod kątem efektów biznesowych, jakie przyniesie ich
osiągnięcie. Ponadto, z kaŜdym celem zostały powiązane konkretne kryteria akceptacji,
które pozwolą ocenić ich faktyczne osiągnięcie na koniec projektu.
7.2.2
Zakres problemu
Proces
zarządzania
problemami
w
projektach
informatycznych
nie
jest
zagadnieniem trywialnym. Oprócz oczywistych aspektów takich jak ujawnianie się
problemów i propozycji zmian w cyklu Ŝycia oprogramowania oraz ich wpływu na projekt
jako całość, pojawia się takŜe cały szereg innych kwestii o niepomijalnym znaczeniu.
Projektowane oprogramowania powinno w załoŜeniu pokrywać jak najszerszy, zgodny
z wymaganiami, zakres całego procesu. Diagram kontekstu na Rysunku 7-1 stara się
w poglądowy sposób umiejscowić dziedzinę problemową wraz ze stowarzyszonymi z nią
systemami:
117
Rysunek 7-1 Diagram kontekstu problemu
Zarządzanie problemami nie moŜe być rozpatrywane w oderwaniu od innych
procesów zachodzących w projekcie informatycznym. Obsługa i rozwiązywanie
problemów ma bezpośredni wpływ na harmonogram i budŜet (zasoby) projektu.
Identyfikowane defekty i zmiany prowadzą do modyfikacji zarówno w końcowym
systemie jak i wszelkich produktach pośrednich oraz niekiedy wymuszają przedłuŜenie lub
ponowne przebycie wybranych faz projektu (np. testowanie). Jednocześnie wszelkie
działania objęte procesem zarządzania problemami muszą być zbieŜne z potrzebami
klienta i udziałowców systemu oraz być w zgodzie z zawartym kontraktem, uwzględniać
zakres projektu oraz moŜliwości zespołu projektowego.
7.2.3
Udziałowcy
Określając zbiór udziałowców przyszłego systemu musimy spojrzeć na dziedzinę
problemową z punktu widzenia oprogramowania, które w określonym zakresie ma się
wkomponować w jej działanie. Zasadniczo z procesem zarządzania problemami mają do
czynienia trzy grupy udziałowców. Pierwszą z nich są klienci oraz uŜytkownicy
powstającego produktu. Drugą grupę tworzą aktywni uczestnicy projektu, czyli
kierownicy projektu, analitycy, programiści, testerzy oraz przedstawiciele klienta.
Ostatnią grupę stanowią udziałowcy nieoŜywieni, ale mający decydujący wpływ na
przebieg projektu, a zwłaszcza na aspekty związane z zarządzaniem problemami. Do tej
grupy naleŜy oczywiście sam produkt, formalne uzgodnienie jego zakresu w postaci
kontraktu oraz wszelkie narzędzia wspomagające dane przedsięwzięcie informatyczne
118
po stronie wykonawcy. Wszystkie wymienione grupy stanowią udziałowców systemu,
których indywidualne punkty widzenia naleŜy uwzględnić przy specyfikowaniu wymagań.
NaleŜy jednak zaznaczyć, Ŝe ze względu na specyfikę dziedziny problemowej pojedyncza
osoba moŜe reprezentować kilku udziałowców (np. programista moŜe być takŜe
testerem, a klient moŜe być jednocześnie uŜytkownikiem). Istnienie takich powiązań
pomiędzy udziałowcami nie zmienia jednak faktu, iŜ kaŜdy z nich musi być rozpatrzony
oddzielnie, jako autonomiczna jednostka mająca swój pogląd na system. Schemat na
Rysunku 7-2 przedstawia umiejscowienie udziałowców względem granicy problemu oraz
wzajemne interakcje pomiędzy nimi. Zewnętrzny okrąg symbolizuje granicę projektu,
z kolei wewnętrzny definiuje granicę mającego powstać systemu.
Rysunek 7-2 Umiejscowienie udziałowców względem granicy projektu i systemu
Dokument specyfikacji wymagań zawiera kompletny opis punktów widzenia
kaŜdego zidentyfikowanego udziałowca. Jak widać na Rysunku 7-2 do grupy udziałowców
znajdujących się bezpośrednio w obrębię granic systemu naleŜą Kierownik projektu,
Analityk, Programista, Tester oraz Przedstawiciel Klienta (w dalszej części projektu
119
nazywany po prostu Klientem). Wymienieni udziałowcy tworzą rdzeń zespołu
projektowego wytwarzającego system i to właśnie dla tej grupy osób kierowane jest
mające powstać narzędzie. W dalszej części specyfikacji wymagań udziałowcy ci będą
nazywani ogólnie członkami zespołu. Uogólnienie takie ma na celu zwiększenie
przejrzystości modelu biznesowego omawianej dziedziny przy jednoczesnym oderwaniu
jej od problemu nadawania i egzekwowania uprawnień oraz zakresu odpowiedzialności
w ramach projektu informatycznego.
7.2.4
Zdarzenia biznesowe i biznesowe przypadki uŜycia
Kolejnym etapem, po określeniu bezpośrednich udziałowców systemu, było
zamodelowanie dziedziny problemowej za pomocą opisu zdarzeń biznesowych, jakie mają
w niej miejsce. W wyniku takiej analizy zidentyfikowałem i opisałem 8 zdarzeń
biznesowych, które zachodzą na granicy rozpatrywanego obszaru problemowego:
1. Członek zespołu rozpoczyna nowy projekt
2. Członek zespołu dołącza do projektu
3. Członek zespołu rezygnuje z uczestnictwa w projekcie
4. Kierownik projektu ustala role w projekcie
5. Członek zespołu zgłasza problem
6. Członek zespołu uzupełnia informacje o problemie
7. Członek zespołu zmienia stan problemu
8. Członek zespołu zmienia odpowiedzialność za problem
Zidentyfikowane zdarzenia posłuŜyły do zamodelowania wywoływanych przez nie
biznesowych
przypadków
uŜycia.
KaŜdy
biznesowy
przypadek
uŜycia
został
w Specyfikacji Wymagań Systemowych słownie opisany i zobrazowany za pomocą
diagramu DFD (Data Flow Diagram), na którym jawnie zaznaczono granicę systemu.
Umieszczenie systemu w kontekście pozwoliło na szczegółowe wyspecyfikowanie
przypadków uŜycia systemu, które zostały później szczegółowo opisane w projekcie
systemu.
7.2.5
Wymagania wobec systemu
W ostatniej części dokumentu specyfikacji wymagań w wyniku szczegółowej
analizy projektowanemu systemowi postawione zostało 20 konkretnych wymagań.
Wymagania zostały podzielone na dwie grupy – wymagania funkcjonalne oraz
niefunkcjonalne. KaŜde z nich zostało dokładnie opisane, wraz z określeniem kryterium
120
akceptacji oraz źródłem jego pochodzenia. PoniŜsze załoŜenia zostały zidentyfikowane
jako nadrzędne w stosunku do pozostałych wymagań:
•
System musi wspierać pracę grupową
•
System musi umoŜliwiać pracę w warunkach rozproszonych
•
System musi być niezaleŜny od centralnego pojemnika danych
•
Warstwa danych systemu winna być oparta o pliki XML
Jest to zestaw wymagań wynikających bezpośrednio z celów postawionych na
początku mojej pracy dyplomowej. Kolejne wymagania odnoszą się juŜ bezpośrednio do
funkcjonalności systemu i przyczyniły się do zamodelowania konkretnych przypadków
uŜycia systemu. Nadrzędnym wymaganiem w tym wypadku jest konieczność zapewnienia
kompletności funkcjonalnej systemu. Wyrazem tego załoŜenia jest następujące
wymaganie:
Identyfikator:
Tytuł:
Opis:
F1
1
Zaakceptowany
Priorytet:
Status:
System powinien zapewnić moŜliwość wspomagania procesu zarządzania problemami
Wymaganie wywodzi się bezpośrednio z celów biznesowych systemu. Wytworzenie i wdroŜenie
systemu ma na celu wspomaganie procesu zarządzania problemami przez gromadzenie danych na
temat projektów i napotkanych w ich trakcie problemów. System musi udostępniać funkcjonalność
w zakresie dodawania, edycji oraz usuwania danych istotnych z punktu widzenia tego procesu.
Kryterium akceptacji
Pomyślne przejście testów walidacyjnych odnoszących się do kompletności funkcjonalnej systemu
w myśl wymagań specyfikujących zakres funkcjonalności.
Powiązania z celami biznesowymi
Wymaganie to jest kluczowe do wypełnienia wszystkich celów biznesowych systemu.
Źródło:
Powiązane
wymagania:
Powiązanie z przypadkami uŜycia systemu
Wymaganie powiązane jest z przypadkiem uŜycia „Przeglądanie listy projektów”
Klient
Wymaganie jest nadrzędne w stosunku do F2 – F9, które szczegółowo definiują zakres
funkcjonalności systemu w dziedzinie wspomagania procesu zarządzania problemami.
Przy specyfikowaniu wymagań niefunkcjonalnych pomocny okazał się typ
systemu, jaki ma powstać. Nie ma to być system bankowy, w którym dane muszą być
w sposób szczególny chronione, a ich wymiana odbywać się w sposób zapewniający
stuprocentową poufność i integralność. Nie jest to równieŜ system czasu rzeczywistego
o twardych wymaganiach czasowych. Reakcja systemu na odpowiednie Ŝądanie powinna
się mieścić w czasie typowym dla tego typu aplikacji, ale nie jest to kryterium
o najwyŜszym priorytecie.
121
Dodatkowo na realizację projektu zostały nałoŜone 3 ograniczenia dotyczące
terminu realizacji, liczebności zespołu oraz dostępności wykorzystywanych narzędzi
wytwórczych.
7.3
Analiza wymagań i ograniczeń oraz dyskusja rozwiązań
Pierwsza część projektu systemu koncentruje się na analizie wymagań
zgromadzonych w specyfikacji oraz na opisie rozwiązań i kompromisów, jakie musiały
zostać podjęte na drodze do ich spełnienia. Ten fragment projektu systemu dotyczy
głownie zakresu danych gromadzonych przez system oraz szeroko pojętych aspektów
związanych z bezpieczeństwem. Te dwa zagadnienia okazały się szczególnie waŜne
w kontekście rozproszonego modelu projektowanego systemu, dlatego teŜ zostały one tutaj
przytoczone w całości.
7.3.1
Bezpieczeństwo
Ze względu na charakter projektowanego narzędzia pod pojęciem bezpieczeństwa
(ang. security) rozumiana jest zdolność systemu do zachowywania integralności
gromadzonych danych oraz zapobieganie nieupowaŜnionemu dostępowi do nich. PoniŜej
zostały opisane rozwiązania przyjęte w zakresie tak rozumianego bezpieczeństwa.
W przypadku aplikacji takich jak system BAGGU mniejsze znaczenie mają aspekty
bezpieczeństwa odnoszące się do wpływu oprogramowania na jego środowisko
zewnętrzne (ang. safety).
7.3.1.1 Autoryzacja i uwierzytelnianie
Przyjęty w załoŜeniach rozproszony model danych czyni kwestię kontroli dostępu
i uwierzytelniania uŜytkowników niezwykle trudną w porównaniu do systemów
scentralizowanych. Brak centralnego pojemnika danych utrudnia lub wręcz uniemoŜliwia
zastosowanie autoryzacji uŜytkowników bazującej na zestawieniu osoby uŜytkownika
(np. login, numer identyfikacyjny) i danych umoŜliwiających potwierdzenie jego
toŜsamości (np. poprzez hasło). W tradycyjnym podejściu dane umoŜliwiające pomyślną
identyfikację oraz autoryzację uŜytkownika przechowywane są w neutralnym miejscu
(bazie danych, serwerze aplikacji), co daje względną pewność o ich bezpieczeństwie
i poprawności. W modelu rozproszonym toŜsamość uŜytkownika oraz związane z nią
uprawnienia muszą być przechowywane lokalnie, co stwarza bardzo powaŜne wątpliwości,
122
co do ich autentyczności. Problem ten dotyczy zresztą wszystkich danych współdzielonych
i dystrybuowanych przez system (dane projektu, dane o problemach).
W związku z wyŜej opisanymi trudnościami konieczne jest opracowanie
mechanizmu, który stanowiłby kompromis pomiędzy potrzebami bezpieczeństwa aplikacji
i wykonalnością techniczną zastosowanego modelu danych. Wyjściem z sytuacji okazuje
się wykorzystanie mechanizmów uwierzytelniania oferowanych przez system operacyjny,
w którym będzie pracowało narzędzie BAGGU. Wbudowane w system Windows
mechanizmy identyfikacji i uwierzytelniania wydają się środkiem wystarczającym do
skutecznej identyfikacji uŜytkownika narzędzia. KaŜdy uŜytkownik systemu operacyjnego
posiada osobiste konto identyfikowane poprzez unikalną nazwę (NAZWA_KOMUPTERA
\ nazwa_uŜytkownika). W momencie uruchomienia aplikacji na lokalnej maszynie, system
BAGGU przejmuje toŜsamość zalogowanego uŜytkownika i posługując się jego loginem
podpisuje wszystkie dodawane i modyfikowane dane, co obrazuje Rysunek 7-3.
Rysunek 7-3 Model uwierzytelniania uŜytkowników oparty o konta
Jak widać powyŜsze rozwiązanie sprawdza się takŜe w przypadku, gdy z narzędzia
korzystają osoby na pojedynczym komputerze (pod warunkiem posiadania przez nich
oddzielnych kont w systemie). Warto jednak zaznaczyć, Ŝe zaprezentowany mechanizm
rozwiązuje jedynie problem identyfikacji toŜsamości uŜytkownika. Problem nadawania
i egzekwowania uprawnień musi zostać rozwiązany w logice systemu.
Opisane wyŜej rozwiązanie posiada jedną zasadniczą wadę, mianowicie utrudnia
identyfikację uŜytkownika pracującego na więcej niŜ jednej stacji roboczej. Zgodnie
z załoŜeniami uŜytkownik uruchamia aplikację na konkretnym komputerze posiadając
własne konto w systemie operacyjnym. W przypadku, gdy osoba ta posiada konta na wielu
maszynach, system BAGGU traktuje kaŜde konto jako oddzielnych uŜytkowników
systemu (ze względu na inną nazwę komputera i bardzo często takŜe odmienną nazwę
123
samego konta). Nie ma idealnego rozwiązanie powyŜszego problemu, istnieją jednak
następujące moŜliwości:
•
Osłabienie warunku identyczności kont stosowanym przez system. W takim
przypadku, logika aplikacji powinna utoŜsamiać ze sobą konta o tej samej nazwie bez
wymogu identyczności nazwy komputera (konta COMP1 / Adam byłoby toŜsame
z kontem COMP2 / Adam itd.). Jest to jednak rozwiązanie kompromisowe, które
narzucałoby konieczność identycznego nazywania kont uŜytkowników na kaŜdej stacji
roboczej
•
Wykorzystanie Active Directory w serwerowych systemach Windows. Technologia ta
umoŜliwia centralnie przechowywanie kont uŜytkowników lokalnej sieci. UŜytkownik
logując się na dowolnej stacji roboczej zawsze uzyskuje dostęp do zasobów
systemowych za pośrednictwem tego samego konta, które jest uwierzytelniane
i pobierane z serwera.
7.3.1.2 Integralność danych
Drugim,
obok
mechanizmu
uwierzytelniania
uŜytkowników,
wymogiem
stawianym bezpiecznym aplikacjom jest skuteczne zapobieganie naruszania integralności
danych gromadzonych przez system. Projektowane narzędzie ze względu na zastosowanie
plików XML jako nośników danych staje się wyjątkowo podatne na nieupowaŜnione lub
przypadkowe modyfikacje struktur danych. Jawność plików XML stwarza moŜliwość
niekontrolowanej ich edycji bez pośrednictwa narzędzia, co z kolei moŜe prowadzić do
uszkodzenia lub sfałszowania zgromadzonych danych. Biorąc pod uwagę specyfikę
projektowanego narzędzia i jego architektury, głównymi zagroŜeniami dla integralności
danych gromadzonych przez system są:
•
system kontroli wersji – w momencie jednoczesnej modyfikacji pojedynczego
pliku przez więcej niŜ jednego uŜytkownika moŜe nastąpić konflikt. Narzędzia do
kontroli wersji (patrz rozdział 5) często posiadają wbudowane mechanizmy
automatycznego rozwiązywania takich sytuacji poprzez scalanie modyfikacji
dokonanych przez kaŜdą ze stron. Mechanizmy te jednak nie wnikają w treść
scalanych plików, co przy zastosowaniu języka XML moŜe prowadzić do
nieumyślnego naruszenia poprawności struktury pliku. Jako Ŝe projektowane
narzędzie nie ma wpływu na decyzje ani mechanizmy stosowane przez
124
współpracujący system kontroli wersji, naleŜy brać pod uwagę opisaną tutaj
moŜliwość naruszenia poprawności danych.
•
niekontrolowana edycja plików – jawność plików XML oraz ich tekstowy format
w znaczącym stopniu naraŜa dane gromadzone w ten sposób na nieupowaŜnioną
manipulację. Projektowane narzędzie musi być świadome tego, Ŝe dane
odczytywane z tak łatwo dostępnego źródła mogą być celowo zmodyfikowane.
Oczywisty staje się fakt, iŜ logika systemu musi starać się być odporna na tego typu
zagroŜenia. Warto jednak zaznaczyć, Ŝe o ile pierwszy problem moŜna uznać za bardzo
istotny, o tyle próby nieautoryzowanej manipulacji danymi w docelowym środowisku
pracy narzędzia wydają się być mało prawdopodobne. Wydaje się, Ŝe członkowie zespołu
projektowego, a więc uŜytkownicy narzędzia, realizując wspólne przedsięwzięcie, nie
powinni mieć ani potrzeby ani motywacji do naruszania wiarygodności i fałszowania
danych gromadzonych w systemie.
Rozwiązanie przedstawionych wyŜej problemów nie jest kwestią trywialną.
Jednym
z
moŜliwych
podejść
jest
zastosowanie
mechanizmów
potwierdzania
autentyczności danych gromadzonych w plikach w oparciu o sumy kontrolne. Rozwiązanie
to moŜe opierać się na nadawaniu elementom danych w pliku (całemu plikowi lub
pojedynczym węzłom XML) specjalnego atrybutu zwanego sumą kontrolną. Wartość
sumy kontrolnej jest wynikiem działania funkcji, której sposób działania jest zaszyty
wewnątrz aplikacji. Funkcja ta w jedynie sobie znany sposób generuje sumę kontrolną
w oparciu o szereg czynników (m.in. takich jak wartość danych, data modyfikacji pliku
itp.). KaŜda zmiana danych dokonywana przez system powinna wiązać się z aktualizacją
sumy kontrolnej zmienianego fragmentu pliku. W ten sposób, przy ponownym odczycie
pliku przez system, wbudowane mechanizmy kontroli będą w stanie stwierdzić, czy dana
informacja jest poprawna czy teŜ nie. Weryfikacja danych odbywa się poprzez ponowne
obliczenie sumy kontrolnej dla odczytanych danych (stosując tę samą funkcję)
i konfrontację jej wartości z tą odczytaną z pliku. W momencie napotkania rozbieŜności,
system moŜe mieć wątpliwości, co do autentyczności i poprawności odczytanych danych.
Oczywiście wszelkie modyfikacje danych wykonywane poza aplikacją skutkują brakiem
aktualizacji sumy kontrolnej. Aby mechanizm ten był skuteczny, funkcja generująca sumy
kontrolne musi być na tyle złoŜona, aby generowane przez nią wartości nie były
przewidywalne i moŜliwe do odgadnięcia na podstawie powtarzanej obserwacji danych.
125
Problem ten wykracza znacząco poza ramy niniejszej pracy dyplomowej, jednak
wprowadzenie opisywanych mechanizmów, chociaŜ w uproszczonej formie, do
projektowanego narzędzia umoŜliwiłoby logice aplikacji wykrywanie i reagowanie na
nieprawidłowości w odczytywanych danych.
7.3.2
Warstwa danych
Jak wiadomo warstwa danych zapewnia trwałość danych dla systemu.
W zaleŜności od charakteru konkretnej aplikacji trwałość ta moŜe być realizowana przez
relacyjną bazę danych, system katalogowy, system plików, czy obiektową bazę danych.
U podstaw załoŜeń projektowanego narzędzia leŜało załoŜenie, Ŝe system BAGGU nie
będzie wymagał scentralizowanego pojemnika danych do przechowywania informacji
o problemach w projekcie informatycznym. ZałoŜenie to zmniejsza moŜliwość
zastosowania wszelkich rozwiązań opartych o tradycyjne, scentralizowane serwery baz
danych. Owszem, moŜliwe byłoby zastosowanie technologii rozproszonych baz danych
z zaawansowanymi mechanizmami replikacji, jednak biorąc pod uwagę stopień
skomplikowania i rozmiar gromadzonych w przypadku systemu BAGGU danych,
rozwiązanie takie wydaje się nadmiarowe i zbyt skomplikowane w stosunku do potrzeb.
Ponadto wprowadzenie dodatkowego wymogu uruchamiania lokalnej instancji serwera
bazy danych na kaŜdej maszynie uczestnika projektu kłóci się z załoŜeniem o maksymalnej
prostocie obsługi i instalacji systemu. Podsumowując, zaproponowane rozwiązanie
bazujące na lokalnie replikowanych przez system kontroli wersji plikach XML zapewnia
decentralizację warstwy danych, ale jednocześnie stwarza szereg utrudnień, których
dokładny opis znajduje się poniŜej.
W załoŜeniu system BAGGU ma za zadanie gromadzić dane na temat problemów
pojawiających się w trakcie projektu informatycznego. Zgodnie z wcześniejszymi
rozwaŜaniami w Rozdziale 4 do takich danych naleŜą niewątpliwie zgłoszenia o błędach
(defekty) oraz propozycje zmian. NaleŜy jednak pamiętać, Ŝe aby skutecznie wspomagać
proces zarządzania problemami konieczne jest takŜe przechowywanie informacji na temat
samego procesu i jego organizacji. Ponadto, przy rozproszonym modelu danych konieczne
staje się określenie, które dane są współdzielone przez wszystkich uczestników projektu,
a które słuŜą jedynie do wspomagania procesu replikacji na lokalnych maszynach.
Wszystkie wymienione wyŜej aspekty przedstawione są na Rysunku 7-4.
126
Rysunek 7-4 Ogólna koncepcja zakresu gromadzonych danych
Jak
widać
kompletna
baza
danych
pojedynczego
projektu
składa
się
z następujących elementów:
•
Dane projektu – wszelkie informacje nie będące opisem problemów, ale
konieczne w procesie zarządzania problemami w projekcie. Do takich informacji
naleŜy np. nazwa projektu, skład zespołu projektowego oraz zakres ich ról i podział
obowiązków.
Do
danych
projektu
naleŜą
takŜe
wszelkie
informacje
o uprawnieniach poszczególnych uŜytkowników systemu. Z oczywistych
względów opisane tutaj dane są współdzielone przez wszystkich uczestników
i konieczna jest ich replikacja.
•
Defekty i Zmiany – wszystkie informacje na temat konkretnych problemów
(zgłoszeń), podobnie jak dane projektu muszą ulegać dystrybucji.
•
Konfiguracja projektu – dane specyficzne dla rozproszonego modelu danych,
w którym konieczne jest przechowywanie indywidualnych ustawień dla
konkretnego, lokalnego środowiska uczestnika projektu. Najlepszym przykładem
takich danych jest informacja o lokalizacji lokalnej kopii repozytorium (lokalny
katalog roboczy) czy informacje na temat skąd i w jaki sposób pozyskiwać dane
(ustawienia narzędzia do wersjonowania kodu). Ze względu na indywidualny
i wybitnie lokalny charakter tych danych nie mogą one podlegać tym samym
zasadom przechowywania i dystrybucji, co dane projektu i problemy, nie mniej
jednak stanowią one integralną część bazy danych projektu.
7.4
Model logiczny systemu
Na realizowany system został nałoŜony konkretny zestaw wymagań, który ma
bezpośredni wpływ na decyzje podjęte w procesie jego analizy i projektowania. Jedną
z najwaŜniejszych decyzji na tym etapie było zdefiniowanie ogólnej architektury
127
oprogramowania, której celem jest wskazanie logicznej struktury i wzajemnej zaleŜności
składników wchodzących w skład realizowanego systemu. PoniŜej została opisana ogólna
koncepcja działania systemu wraz z opisem najwaŜniejszych jej składników.
7.4.1
Wizja architektoniczna
Zasadniczo system BAGGU jest narzędziem realizowanym w architekturze
trójwarstwowej, przy czym warstwa danych reprezentowana jest przez system plików
XML. Diagram 7-5 przedstawia ogólne załoŜenia architektoniczne systemu:
BAGGU
Warstwa
prezentacji
sytemu
zostanie
zrealizowana
jako
aplikacja okienkowa pracująca pod
kontrolą systemu operacyjnego
Windows.
Logika
biznesowa
systemu
zrealizowana będzie w technologii
obiektowej, a jej szerszy opis
znajduje się w punkcie 4.
Warstwa danych oparta jest o pliki XML i będzie współdzielona
z narzędziami typu source-control. Rolą systemu będzie
tworzenie, modyfikowanie i dbanie o integralność danych
zawartych w plikach, z kolei zadanie ich replikacji i dystrybucji
zostanie przekazane na narzędzie do wersjonowania kodu.
Rysunek 7-5 Ogólna architektura systemu
Jednym z podstawowych celów powstającego systemu jest umoŜliwienie pracy
grupowej przy jednoczesnym uniezaleŜnieniu się od centralnego serwera aplikacji i bazy
danych. Aby sprostać tego typu wymaganiom system BAGGU musi oferować skuteczne
metody replikacji lokalnie gromadzonych danych. Rolę pojemnika danych aplikacji będą
pełniły pliki XML. Kwestia ich dystrybucji w środowisku rozproszonym rozwiązywana
jest poprzez wykorzystanie przez system BAGGU narzędzi typu source-control
oferujących zewnętrzny interfejs (linia poleceń, zewnętrzna biblioteka DLL). Schemat na
Rysunku 7-6 przedstawia ogólną koncepcję współdziałania systemu z tego typu
narzędziami:
128
Nad kontrolą wersji i dystrybucją plików z danymi pomiędzy uczestnikami projektu czuwa narzędzie typu
source-control. Warstwa danych systemu BAGGU komunikuje się z nim za pośrednictwem dobrze
zdefiniowanego intefejsu. KaŜde odwołanie do danych poprzedzone jest wydobyciem z repozytorium
najnowszej ich wersji (check-out), z kolei kaŜda modyfikacja wiąŜe się z ich aktualizacją w repozytorium
i propagacją wśród uczestników projektu (check-in). Problem dystrybucji danych i rozwiązywania
konfliktów (relatywnie prosty ze względu na strukturalność plików XML) rozwiązywany jest całkowicie
przez wybrane narzędzie do wersjonowania kodu.
Wszelkie dane gromadzone przez
BAGGU przechowywane są jako
pliki XML o zdefiniowanej
strukturze.
PoniewaŜ proces dystrybucji
i replikacji danych o problemach
kontrolowany
jest
przez
zewnętrzne narzędzie, z punktu
widzenia BAGGU nie jest istotne
czy praca odbywa się lokalnie czy
w warunkach rozproszonych.
W
szczególnym
przypadku
moŜliwy jest nawet scenariusz
jedno- stanowiskowy, w którym
warstwa danych nie korzysta
z
Ŝadnego
narzędzia
do
wersjonowania kodu i dane
stanowisko pełni rolę jedynego
repozytorium danych.
Rysunek 7-6 Sposób współpracy narzędzia z systemem kontroli wersji
Na rynku istnieje obecnie bardzo wiele narzędzi typu source-control, do których
funkcjonalności moŜna uzyskać dostęp za pośrednictwem dobrze zdefiniowanych
interfejsów zewnętrznych. Przyjęcie powyŜszego rozwiązania uniezaleŜnia warstwę
danych systemu BAGGU od kontekstu uŜycia. W zaleŜności od wybranego narzędzia do
wersjonowania kodu, moŜliwa jest praca zarówno w scenariuszu scentralizowanym
(z centralnym repozytorium kodu - CVS) jak i rozproszonym (Reliable Software Code
CoOp – synchronizacja kodu za pomocą e-mail). Zaprezentowana architektura systemu
spełnia podstawowe wymagania postawione narzędziu przy jednoczesnym zwiększeniu
jego uniwersalności. Ponadto ze względu na prostą i dobrze zdefiniowaną strukturę zapisu
danych w formacie XML, wszystkie obecne na rynku narzędzia słuŜące do wersjonowania
kodu nie powinny mieć problemów z ich obsługą. Pliki XML są zwykłymi plikami
tekstowymi, co dodatkowo przy ich strukturalności czyni ich dystrybucję i ewentualne
scalanie przy konfliktach (merging) operacją relatywnie prostą.
Warto w tym momencie wspomnieć o nowatorstwie proponowanego rozwiązania.
W chwili pisania pracy dyplomowej nie są mi znane systemy wspomagające proces
129
zarządzania problemami, które jako pojemnik danych wykorzystywałyby lokalnie
replikowane pliki XML. W zdecydowanej większości (patrz Rozdział 6 – „Przegląd
rozwiązań dostępnych na rynku”) są to systemy oparte o centralny serwer bazy danych.
Tym samym zastosowane w dyplomie podejście ma wybitnie prototypowy charakter
i naleŜy brać ten fakt pod uwagę przy definiowaniu zakresu funkcjonalności systemu.
7.4.2
Zakres systemu
Ustalenie granic projektowanego systemu było przedmiotem analizy wymagań.
W kontekście procesu zarządzania problemami w projekcie informatycznym granica ta
przebiega na styku zespołu projektowego i klienta. W celu maksymalnego ukierunkowania
powstającego oprogramowania na potrzeby zespołu projektowego, klient został włączony
bezpośrednio do zespołu projektowego. W wyniku tej decyzji projektowej klient staje się
aktorem bezpośrednio inicjującym przypadki uŜycia aplikacji.
7.4.3
Aktorzy i przypadki uŜycia
Z opisu problemu oraz konkretnych decyzji projektowych wynika istnienie
następujących aktorów mających swój bezpośredni lub pośredni udział w trakcie
funkcjonowania projektowanego systemu:
Project member (członek zespołu) – osoba będąca aktywnie zaangaŜowana
w proces zarządzania problemami w projekcie informatycznym. Członkiem zespołu jest klient,
kierownik projektu, wykonawca oraz tester. Członek zespołu (w zaleŜności od ról pełnionych
w projekcie) rejestruje problemy w bazie problemów, uzupełnia dane na ich temat oraz podejmuje
decyzje o ich dalszej obsłudze w trakcie całego cyklu Ŝycia problemu w projekcie. Pojedyncza
osoba moŜe być członkiem zespołu w wielu, równolegle prowadzonych projektach.
Client (klient) – w ogólności osoba rozumiana jako odbiorca systemu, pod pojęciem klienta
w kontekście projektu informatycznego rozumie się wszystkie osoby mające styczność z produktem,
a więc osoby, które mogą być źródłem problemów w trakcie projektu (uŜytkownicy, zleceniodawcy,
sponsorzy). Klient zgłasza napotkane problemy do bazy zagadnień i moŜe śledzić proces ich
obsługi. Na końcu cyklu Ŝycia problemu klient moŜe zweryfikować i zaakceptować rozwiązanie
problemów, które zgłosił.
Project manager (kierownik projektu) – osoba zarządzająca projektem, posiada wszystkie
moŜliwości członka zespołu poszerzone o moŜliwość zarządzania uprawnieniami pozostałych
członków zespołu. Kierownik moŜe bez ograniczeń modyfikować dane i status problemów. KaŜdy
projekt posiada co najmniej jednego kierownika projektu. Osoba rozpoczynająca nowy projekt staje
się automatycznie jego kierownikiem.
Developer (wykonawca) – w ogólności osoba opracowująca i wdraŜająca rozwiązania zgłaszanych
problemów (analityk, projektant, programista). Wykonawca ma moŜliwość zgłaszania problemów
oraz zmiany danych i statusu przypisanych do siebie problemów oraz podejmowania się rozwiązania
jeszcze nie przypisanych problemów.
Tester – osoba badająca jakość wytwarzanego oprogramowania i weryfikująca rozwiązania znanych
problemów. Tester ma moŜliwość zgłaszania nowych i zmiany danych juŜ istniejących problemów.
Tester moŜe równieŜ weryfikować i zamykać rozwiązane problemy.
130
Z kolei funkcjonalna specyfikacja wymagań na projektowany system wymaga
zaimplementowania w nim następujących przypadków uŜycia:
Rysunek 7-4 Diagram przypadków uŜycia
Inicjatorem wszystkich przypadków uŜycia systemu jest Project member (Członek
zespołu). Rdzeń funkcjonalności systemu stanowią przypadki uŜycia „Przeglądanie listy
projektów”, „Przeglądanie listy problemów” oraz „Podgląd problemu”, które grupują
logicznie operacje dokonywane na projektach i problemach w nich rejestrowanych.
Przypadki te są rozszerzane przez szczegółowe przypadki uŜycia dotyczące konkretnych
aspektów procesu zarządzania problemami w projektach informatycznych. Szczegółowy
opis kaŜdego przypadku uŜycia i jego przebiegu został zawarty w Załączniku „ BAGGU –
Model i Projekt Systemu” w punkcie 3.4.
131
7.5
Projekt narzędzia
7.5.1
Decyzje projektowe
Biorąc pod uwagę wymagania stawiane systemowi oraz specyfikę projektu
prowadzonego na potrzeby praktycznej części pracy dyplomowej zostały podjęte
następujące wstępne decyzje projektowe:
•
Rolę pojemnika danych będą pełniły pliki XML o logicznej strukturze
odzwierciedlającej relacyjną bazę danych o problemach
•
Wprowadzenie zabezpieczeń integralności danych omawianych w punkcie 3.3.2
zostanie pominięte, jako funkcjonalność, która nie jest kluczowa dla osiągnięcia
głównych
celów
części
praktycznej
dyplomu.
Problem
zostaje
jednak
zasygnalizowany i wymieniony jako funkcjonalność wysoce poŜądana w kolejnych
wersjach systemu.
•
Realizowany system będzie ukierunkowany na umoŜliwienie współpracy
z moŜliwie jak najszerszym zbiorem narzędzie kontroli wersji, nie mniej jednak
ograniczenia nałoŜone na proces implementacji wymuszają podjęcie konkretnych
decyzji co do poŜądanego zakresu kompatybilności. W opracowywanym w ramach
pracy dyplomowej prototypie narzędzia główny nacisk będzie kładziony na
wykorzystanie następujących narzędzi:
o Reliable Software Code CoOp
o CVS
Są to przykłady narzędzi pracujących w dwóch odmiennych modelach danych –
scentralizowanym i zdecentralizowanym – co daje moŜliwość zaprezentowania
działania realizowanego systemu w róŜnych środowiskach.
7.5.2
Technologia
Projektowany system będzie aplikacją „okienkową”, typu stand-alone, działającą
pod kontrolą systemu operacyjnego Windows. Narzędzie zostanie wykonane na bazie
platformy technologicznej Microsoft .NET (Windows Forms) w wersji 2.0. Językiem
programowania uŜytym do implementacji systemu będzie C#, równieŜ w wersji 2.0.
7.5.3
Środowisko wytwórcze
W
trakcie
realizacji
systemu
wykorzystywane
będą
następujące
środki
implementacyjne i narzędziowe:
132
• system operacyjny:
Windows XP Professional SP 2
• oprogramowanie:
pakiet Microsoft Office 2003
• narzędzie UML:
JUDE Community 2.4.x
• platforma technologiczna:
Microsoft .NET 2.0 (2005)
• narzędzie wytwórcze:
Microsoft Visual Studio 2005
• język programowania:
C# 2.0
• wersjonowanie kodu:
Reliable Software Code CoOp 4.x
Biorąc
pod
uwagę
charakter
projektu
środowisko
wytwórcze
zostało
w całości skompletowane z darmowych, lub udostępnianych na licencji akademickiej,
narzędzi i technologii. Jedynie w przypadku narzędzia Reliable Software Code CoOp uŜyta
zostanie kopia oprogramowania na posiadanej przeze mnie prywatnej licencji komercyjnej.
7.5.4
Środowisko docelowe
Docelowym środowiskiem działania systemu będzie dowolna maszyna klasy PC
o architekturze zgodnej z x86 pracująca pod kontrolą systemu operacyjnego Windows XP.
Ze względu na zastosowaną technologię wytwórczą, w docelowym systemie operacyjnym
konieczna jest obecność Microsoft .NET Framework w wersji 2.0 lub nowszej. Spełnienie
wyŜej wymienionych załoŜeń pozwoli na uruchomienie systemu i pracę z lokalnymi
danymi. W przypadku pracy z projektami rozproszonymi konieczne jest zainstalowanie
dodatkowego oprogramowania, zaleŜnego od wykorzystywanego narzędzia do kontroli
wersji:
•
Reliable Software Code CoOp 4.x – narzędzie to musi zostać zainstalowane wraz
z rozszerzeniem Command-Line Interface. Aplikacja ta w przypadku projektów
rozproszonych wymaga takŜe klienta poczty zgodnego ze standardem MAPI
•
CVS – konieczne jest istnienie serwera z zainstalowanym repozytorium CVS,
z kolei na maszynie klienta musi zostać zainstalowany dowolny klient CVS (np.
WinCVS lub TortoiseCVS)
7.5.5
Projekt systemu i klas
7.5.5.1 Model projektu
Jedną z kluczowych funkcjonalności realizowanego systemu ma być moŜliwość
kierowania procesem zarządzania problemami w projekcie informatycznym. Logika
narzędzia musi zatem zawierać wszelkie aspekty z tym związane, ze szczególnym
133
uwzględnieniem wcześniej podjętych decyzji odnośnie zakresu gromadzonych danych oraz
sposobu ich przechowywania. Przy projektowaniu tej części logiki biznesowej nie bez
znaczenia pozostaje takŜe aspekt współpracy narzędzia z systemami kontroli wersji.
Struktura logiczna projektów obsługiwanych przez system musi uwzględniać wszystkie te
czynniki przy jednoczesnym zapewnieniu dostatecznego stopnia rozszerzalności modelu
w przyszłości.
Na
potrzeby
realizacji
prototypu
narzędzia
podjęta
została
decyzja
o zaimplementowaniu w nim trzech rodzajów projektów, przy czym przez rodzaj projektu
naleŜy w tym momencie rozumieć sposób obsługi warstwy danych. Są to:
•
projekt lokalny (local project) – Lokalny projekt to taki, w którym wszelkie dane
gromadzone są na lokalnej maszynie i nie podlegają dalszej dystrybucji. Jest to
najprostszy przypadek, kiedy całość danych projektu przechowywana jest
w jednym miejscu. Ten typ projektu nie wyklucza jednak uczestnictwa w nim
więcej niŜ jednego uŜytkownika pracującego na lokalnej maszynie (po warunkiem
posiadania przez nich oddzielnych kont uŜytkownika). Cechą charakterystyczną
tego typu projektu jest zupełny brak współpracy z jakimkolwiek systemem kontroli
wersji
•
projekt Code CoOp (Code CoOp project) – Projekt, w którym systemem kontroli
wersji uŜywanym przy replikacji i dystrybucji danych jest narzędzie Reliable
Software Code CoOp. Baza danych systemu BAGGU dołącza się do juŜ
istniejącego lub nowego projektu w tym narzędziu i za jego pomocą wszelkie dane
rozsyłane są wśród uczestników za pośrednictwem poczty elektronicznej lub
poprzez foldery współdzielone w sieci lokalnej
•
projekt CVS (CVS project) – Projekt, w którym systemem kontroli wersji
uŜywanym przy replikacji i dystrybucji danych jest darmowe narzędzie CVS. Baza
danych systemu BAGGU dołącza się do juŜ istniejącego lub nowego repozytorium
na wskazanym serwerze CVS. Dane projektu są na stałe przechowywane na
serwerze, a ich lokalna kopia jest tworzona na czas pracy z aplikacją. W momencie
jakichkolwiek modyfikacji zmiany przesyłane są z powrotem na serwer, skąd
pozostali uczestnicy mogą pobierać najświeŜsze wersje danych
Zgodnie z załoŜeniami przedsięwzięcia realizowane narzędzie musi zostać
zaprojektowane w sposób, który umoŜliwi jego ewentualną rozbudowę o moŜliwość
134
współpracy z innymi dostępnymi na rynku rozwiązaniami typu source-control. Wymóg ten
został spełniony poprzez wprowadzenie do logiki biznesowej abstrakcyjnej klasy bazowej
Projekt, która w załoŜeniu reprezentuje dowolny rodzaj projektu. Konkretne,
implementowane przez narzędzie, projekty reprezentowane są w tym modelu przez klasy
dziedziczące, odpowiednio LocalProject, CodeCoOpProject oraz CVSProject. Nazwy
i funkcjonalność zaimplementowanych projektów odzwierciedlają wykorzystywane przez
nie technologie, gdyŜ kaŜda z tych klas posiada rozwiązania specyficzne dla siebie
załoŜenia
i
sposób
działania.
W
przyszłości
moŜna
rozszerzyć
system
np.
o moŜliwość współpracy z serwerami FTP jako repozytorium danych o problemach.
W takiej sytuacji konieczne byłoby zaimplementowanie kolejnej klasy (FTPProject), która
implementowałaby zachowanie projektu z zastosowaniem serwera plików. Podsumowując,
całość logiki systemu zawsze operuje na abstrakcyjnym projekcie bazowym, nie wnikając
w szczegóły implementacyjne poszczególnych klas potomnych. W klasach dziedziczących
znajdują się konkretne rozwiązanie techniczne specyficzne dla danego typu projektu.
Przy okazji definiowania zakresu danych zaprezentowanego w punkcie 8.4
pojedynczy projekt został podzielony na dwie zaleŜne od siebie części – fragment
współdzielony (dane projektu) oraz fragment lokalny (konfiguracja). Podział ten został
przeniesiony do modelu logicznego systemu w postaci zaleŜności dwóch klas – omawianej
wcześniej klasy Project oraz klasy ProjectCofig, która reprezentuje lokalną część
konfiguracyjną pojedynczego projektu. Podobnie jak klasa reprezentująca dane projektu,
klasa ProjectConfig równieŜ stanowi abstrakcyjną klasę bazową dla klas potomnych
reprezentujących poszczególne rodzaje projektów. Związek typu 1-1 pomiędzy tymi
klasami odwzorowuje, fakt, iŜ kaŜdy projekt musi posiadać konfigurację, z kolei
pojedyncza konfiguracja zawsze dotyczy konkretnego projektu. Model projektu w logice
biznesowej systemu BAGGU został zaprezentowany na Rysunku 7-8.
Oprócz opisywanych wyŜej klas Project oraz ProjectConfig na diagramie zostały
zawarte klasy reprezentujące członków danego projektu (ProjectMember) oraz problemy
w nim zarejestrowane (Problem – opisana szerzej w punkcie 8.7.2). Obie te klasy
z oczywistych względów są połączone z projektem poprzez silną agregację. Kolejnym
waŜnym elementem tej części modelu systemu jest klasa kontenerowa ProjectContainer,
której głównym zadaniem jest przechowywanie i reprezentowanie zbioru projektów oraz
udostępnianie warstwie interfejsu uŜytkownika mechanizmów do ich zarządzania.
135
Rysunek 7-5 Szczegółowy diagram klas przedstawiający model projektu w narzędziu BAGGU
136
7.5.5.2 Model problemu
Jednym z zasadniczych celów praktycznej części mojej pracy dyplomowej jest
zastosowanie opracowanego w Rozdziałach 3 oraz 4 modelu problemu w konkretnej
implementacji. Zasadniczo model problemu w systemie BAGGU nie odbiega znacząco od
rozwiązań przedstawianych wcześniej w części teoretycznej mojej pracy. Jedyne
modyfikacje
dotyczą
zawęŜenia
zakresu
atrybutów
problemu
oraz
rezygnacja
z mechanizmów powiązywania załączników.
Trzonem modelu pozostała abstrakcyjna klasa bazowa Problem, po której
dziedziczą klasy reprezentujące defekty (Bug) oraz prośby o zmianę (ChangeRequest).
Podejście takie umoŜliwia logice biznesowej jednakowe traktowanie problemów przy
jednoczesnym uwzględnieniu ich indywidualnego charakteru (np. przy wyświetlaniu).
Cykl Ŝycia problemu został zamodelowany przy pomocy klasy reprezentującej stan. Klasa
State stanowi abstrakcyjną klasę bazową dla klas reprezentujących konkretne stany,
w jakich moŜe się znaleźć problem. KaŜdy obiekt dziedziczący po klasie State posiada
jednoznaczną nazwę oraz zbiór stanów, które mogą po nim następować (atrybut
possibleTransitions). Pojedyncza instancja klasy Problem w danym momencie powiązana
jest z konkretną instancją klasy State, co jednoznacznie determinuje jej aktualny stan oraz
moŜliwe dalsze kroki w cyklu Ŝycia. Opisywane tutaj rozwiązanie wykorzystuje często
stosowany wzorzec projekty State [GAMM1995]. Rozwiązanie konkretnego problemu
zostało zamodelowane analogicznie do stanu poprzez klasę abstrakcyjna Resolution oraz
jej klasy potomne reprezentujące moŜliwe rozwiązania problemu. Diagram klas modelu
problemu został zaprezentowany na Rysunku 7-9.
Pozostałe elementy diagramu reprezentują odpowiednio komentarze do problemu
(Comment) oraz historię jego modyfikacji (History). Oba elementy powiązane są
z problemem poprzez silną agregację, gdyŜ razem stanowią integralną całość informacji na
temat problemu.
137
Rysunek 7-6 Szczegółowy diagram klas przedstawiający modelu problemu w narzędziu BAGGU
7.5.5.3 Model warstwy danych
Pojemnikiem danych dla systemu są pliki XML. Zgodnie z załoŜeniami
projektowymi warstwy danych, w modelu biznesowym systemu moŜna wyróŜnić trzy
klasy, które reprezentują obiekty trwałe, tzn. takie których wartości muszą zostać
zachowane po zakończeniu pracy aplikacji. Są to odpowiednio dane projektu (klasa
Project), konfiguracja projektu (klasa ProjectConfig) oraz dane problemów (klasa
Problem).
138
W celu maksymalnej unifikacji sposobu zapisu danych do plików XML do modelu
systemu została wprowadzona abstrakcyjna klasa XMLFile, której głównym zadaniem jest
reprezentowanie dowolnego pliku XML oraz definiowanie zakresu operacji moŜliwych do
wykonania na tym pliku. Klasa ta posiada pojedynczy atrybut określający fizyczne
połoŜenie danego pliku na dysku (atrybut filePath) oraz definiuje 4 abstrakcyjne metody
słuŜące do manipulowania na danych XML. Są to odpowiednio:
•
read (odczyt) – metoda ma na celu otworzenie pliku wskazywanego przez atrybut
filePath, parsowanie jego zawartości oraz odczyt wartości danych i ich zapisanie do
atrybutów obiektu
•
write (zapisz) – metoda ma na celu zapisanie aktualnych wartości obiektu do pliku
XML wskazanego przez atrybut filePath.
•
verify (weryfikuj) – metoda ma na celu sprawdzenie poprawności struktury pliku XML
Klasa XMLFile jest abstrakcyjną klasą bazową dla wszystkich wymienionych
wyŜej klas trwałych. Klasy dziedziczące po niej muszą implementować wszystkie
4 metody w sposób, który odzwierciedla strukturę i zawartość informacyjną
poszczególnych obiektów. Dzięki zastosowaniu takiej konstrukcji instancje klas trwałych
potrafią utrwalić się za pomocą specyficznych dla siebie plików XML, a logika biznesowa
nie musi wnikać w szczegóły tej operacji. Na poniŜszym diagramie został przedstawiony
fragment diagramu klas odpowiedzialny za opisaną wyŜej warstwę danych systemu.
Rysunek 7-7 Szczegółowy diagram klas przedstawiający model warstwy danych w narzędziu BAGGU
139
7.5.6
Dynamika systemu
Implementacja narzędzia BAGGU, bazującego na modelu problemu stworzonym
w Rozdziale 4, wymagała takŜe opracowania modelu dynamicznego dla systemu. Bardzo
istotnym zagadnieniem przy projektowaniu dynamiki systemu było przeistoczenie
zaproponowanego cyklu Ŝycia problemu na konkretny model dynamiczny zaprezentowanej
wcześniej klasy Problem. Diagram na Rysunku 7-11 przedstawia moŜliwe stany instancji
klasy Problem oraz zakres moŜliwych przejść pomiędzy poszczególnymi stanami.
Wszystkie przejścia zaznaczone na diagramie oznaczają zmianę stanu problemu, przy
czym przejście pomiędzy stanami jest moŜliwe tylko w wypadku, gdy członek zespołu
inicjujący zmianę pełni w zespole projektowym odpowiednią rolę. Warunek ten został
wyraŜony poprzez podanie w nawiasach kwadratowych zbioru ról, które danej zmiany
mogą dokonać. Na diagramie zastosowano następujące oznaczenia:
•
PM – Project Manager (kierownik projektu)
•
D – Developer (wykonawca)
•
D przypisany – Developer (wykonawca), do którego jest przypisany problem
•
T – Tester
•
C – Client (klient)
Diagram stanów klasy Problem stanowi syntezę wcześniej prezentowanych
diagramów w Rozdziale 3 (Rysunki 3-3 oraz 3-4) wyraŜoną w języku UML. Jedynym
odstępstwem od modelu teoretycznego jest brak stanu „archiwalny”, spowodowany
faktem, Ŝe narzędzie BAGGU w wersji implementowanej w ramach dyplomu nie
przewiduje funkcjonalności związanej z archiwizowaniem zgłoszeń.
Projekt aplikacji zawiera takŜe diagramy sekwencji obrazujące najwaŜniejsze
przypadki uŜycia realizowane przez system (punkt 3.7 w Załączniku „BAGGU – Model
i Projekt Systemu”).
140
Rysunek 7-8 Diagram stanu klasy Problem
7.5.7
Projekt warstwy danych
Opisany w modelu systemu zakres gromadzonych danych posłuŜył do opracowania
konkretnego rozwiązania, którego główne załoŜenia przedstawia Rysunek 7-12. Struktura
plików dla pojedynczego projektu w systemie BAGGU została zasadniczo rozbita na dwa
części:
•
katalog projektów (project directory) – lokalny katalog, w którym zainstalowana
jest aplikacja BAGGU
•
katalog roboczy projektu (project root directory) – lokalizacja lokalnej kopii
repozytorium projektu w systemie kontroli wersji
W katalogu projektów przechowywane są pliki konfiguracyjne wszystkich
projektów, do których naleŜy uŜytkownik lokalnej maszyny. KaŜdy taki plik
konfiguracyjny wskazuje na miejsce, w którym znajdują się zasoby kontrolowane przez
141
system kontroli wersji. We wskazywanym katalogu obok innych plików projektu (kodu
źródłowego, dokumentacji itp.) tworzony jest dedykowany podkatalog (\baggu), w którym
system BAGGU przechowuje dane na temat projektu oraz zgromadzone problemy. W ten
sposób baza danych systemu BAGGU staje się integralną częścią repozytorium projektu
informatycznego i moŜe podlegać mechanizmom kontroli wersji wybranego narzędzia
typu source-control.
Rysunek 7-12 Struktura plików pojedynczego projektu w systemie BAGGU
7.5.8
Projekt interfejsu uŜytkownika
Centralnym elementem aplikacji będzie okno główne zawierające następujące
elementy:
•
panel sterowania – za jego pomocą uŜytkownik uzyska dostęp do wszelkiej
funkcjonalności aplikacji takiej jak tworzenie i dołączanie do projektów,
dodawanie problemów, zmiana konfiguracji itp. Panel sterowania będzie
zrealizowany zarówno w postaci standardowego menu u góry okna jak
i dedykowanego zbioru przycisków (ang. toolbar)
•
lista wyboru projektu – za jej pomocą uŜytkownik będzie miał moŜliwość
przełączania się pomiędzy wszystkimi projektami, do których naleŜy.
•
wyszukiwarka problemów – będzie to zestaw pól umoŜliwiających filtrację
problemów wyświetlanych w liście problemów. Wyszukiwarka będzie obejmowała
zakres najczęściej uŜywanych kryteriów wyszukiwawczych takich jak ID
problemu, stan czy teŜ osoba przypisana do problemu.
142
•
lista problemów – będzie to tabelka, w której wyświetlane będą wszystkie
problemy zarejestrowane w aktualnie wybranym przez uŜytkownika projekcie.
Tabelka będzie zbudowana z kilku kolumn zawierających najistotniejsze
informacje o problemach (ID, stan, tytuł). Tabelkę będzie moŜna dowolnie
sortować względem kaŜdej z kolumn. Mechanizm filtracji w wyszukiwarce
problemów będzie odpowiednio zawęŜał listę wyświetlanych problemów
w zaleŜności od kryteriów podanych przez uŜytkownika. Wybór konkretnego
wiersza
tabelki
spowoduje
otwarcie
oddzielnego
okna
z
informacjami
szczegółowymi na temat wybranego problemu)
PowyŜszy opis dotyczy jedynie ogólnych załoŜeń dotyczących funkcjonalności
głównego okna aplikacji. Rysunek 7-13 przedstawia zestaw formatek implementowanych
przez warstwę prezentacji systemu. Zaprezentowany diagram obrazuje takŜe ścieŜki, jakie
są konieczne do przejścia, aby dojść do konkretnej formatki.
Rysunek 7-13 Schemat formatek systemu
Interfejs uŜytkownika został opracowany w całości w języku angielskim ze
względu
na
potencjalne
zastosowanie
narzędzia
w
projektach
komercyjnych
i prowadzonych na uczelni. Zastosowanie języka angielskiego w warstwie prezentacji
zwiększyło uniwersalność systemu i poszerzy zakres jego potencjalnych odbiorców.
143
7.6
Opis implementacji
Zaprezentowana w poprzednich punktach specyfikacja wymagań, analiza dziedziny
problemowej i ostateczny projekt techniczny stanowiły podstawę do implementacji
narzędzia
mającego
wspomagać
proces
zarządzania
problemami
w
projekcie
informatycznym. Część praktyczna mojej pracy dyplomowej była realizowana w formie
projektu. Przedsięwzięcie to obejmowało większość czynności wykonywanych w ramach
rzeczywistych projektów informatycznych, w tym takŜe proces zarządzania problemami.
W trakcie trwania całego projektu wszelkie napotkane problemy były skrupulatnie
rejestrowane. Na początku projektu, ze względu na brak stosownego narzędzia problemy
zapisywane były w pliku programu Microsoft Excel. Od momentu osiągnięcia przez
aplikację minimalnego zakresu funkcjonalności zgromadzone zagadnienia zostały
przeniesione do bazy danych systemu BAGGU. Testowa wersja aplikacji została
zainstalowana na komputerze uŜywanym w trakcie implementacji. PoniŜej znajduje się
krótka charakterystyka powstałego oprogramowania w formie uproszczonej instrukcji jego
instalacji oraz obsługi.
7.6.1
Instalacja narzędzia
System BAGGU dostarczany jest w postaci pojedynczego pliku instalacyjnego po
uruchomieniu, którego na ekranie pojawi się standardowy kreator, który prowadzi
uŜytkownika przez kolejne kroki procesu instalacji. Instalację systemu moŜna dokonywać
tylko na koncie uŜytkownika z uprawnieniami administratora na lokalnym komputerze
i tylko na komputerach pracujących pod kontrolą systemu operacyjnego Windows 2000
lub XP. Do poprawnego działania aplikacji wymagane jest takŜe wcześniejsze
zainstalowanie Microsoft .NET Framework w wersji 2.0 lub nowszej, o czym uprzedzi
instalator w stosownym momencie. Ponadto, aby korzystać z integracji systemu BAGGU
z CVS lub Code CoOp konieczne jest oddzielne zainstalowanie tych aplikacji na lokalnym
komputerze. Przed zainstalowaniem niniejszej aplikacji zaleca się usunięcie wszystkich
zainstalowanych juŜ wersji BAGGU (patrz punkt 7.6.2). Instalacja rozpoczyna się
automatycznie po uruchomieniu pliku Setup.exe.
144
7-14 Ekran kreatora instalacji systemu
Cały proces instalacji jest bardzo prosty i w zasadzie sprowadza się do wyboru
docelowej lokalizacji aplikacji na dysku. Po zakończeniu instalacji na pulpicie oraz
w menu Start pojawią się skróty pozwalające uruchomić aplikację.
7.6.2
Usuwanie narzędzia
W procesie instalacji system BAGGU automatycznie rejestruje się w systemie
Windows jako zainstalowana aplikacja. Jej usunięcie z systemu sprowadza się do
uruchomienia narzędzia Dodaj/Usuń programy (ang. Add/Remove Programs) dostępnego
z poziomu Panelu Srerowania (ang. Conrol Panel). Wybranie BAGGU z listy
zainstalowanych aplikacji i nakazanie jego odinstalowanie spowoduje całkowite usunięcie
aplikacji z systemu.
7.6.3
Pierwsze uruchomienie aplikacji
Po uruchomieniu aplikacji na ekranie pojawi się główne okno systemu BAGGU.
Opis jego najwaŜniejszych funkcji został zawarty na Rysunku 7-15. Warto zaznaczyć, Ŝe
przy pierwszym uruchomieniu systemu, zalogowany uŜytkownik nie jest jeszcze
członkiem Ŝadnego projektu.
145
Za pomocą menu górnego uzyskujemy dostęp do wszystkich
najwaŜniejszych funkcji systemu. Menu podzielone jest tematycznie na
grupy funkcji dotyczących programu, projektu, problemów oraz pomocy.
Za pomocą listy projektów uzyskujemy
dostęp do wszystkich projektów, w których
członkiem jest zalogowany uŜytkownik.
Za pomocą rozmaitych filtrów
moŜliwe jest zawęŜenie listy
wyświetlanych problemów.
Główny obszar okna jest przeznaczony
na listę problemów zarejestrowanych w
aktualnie wybranym projekcie.
7-15 Główne okno systemu
7.6.4
Tworzenie nowego projektu
W systemie utworzony został projekt lokalny o nazwie BAGGU i od tej pory
wszelkie problemy były rejestrowane za pomocą narzędzia. Rozpoczęcie nowego projektu
w systemie BAGGU odbywa się poprzez wybór odpowiedniej opcji z menu Project/Create
new project (Rysunek 7-16). Wybór konkretnej opcji jest uzaleŜniony od rodzaju projektu,
jaki chcemy utworzyć.
7-16 Menu tworzenia nowego projektu
7.6.4.1 Tworzenie projektu lokalnego
Przy tworzeniu projektu lokalnego, konieczne jest jedynie określenie jego nazwy
oraz wskazanie miejsca na dysku, gdzie będą przechowywane dane problemów.
Lokalizacja projektu (ang. Root directory) moŜe być dowolnym katalogiem na dysku
lokalnym lub współdzielonym katalogiem w sieci lokalnej (LAN).
146
7-17 Okno tworzenia nowego projektu lokalnego
7.6.4.2 Tworzenie projektu CVS
Przy tworzeniu projektu typu CVS, oprócz określenia jego nazwy i wskazania
miejsca na dysku konieczne jest takŜe podanie parametrów umoŜliwiających dostęp do
repozytorium CVS – danych połączenia oraz lokalizacji zainstalowanego klienta CVS.
Warto zaznaczyć, Ŝe tworzenie nowego projektu BAGGU w repozytorium CVS tak
naprawdę oznacza dołączanie plików BAGGU do juŜ istniejącego projektu CVS. Przed
przystąpieniem do tworzenia nowego projektu BAGGU w repozytorium CVS musi juŜ
istnieć odpowiednio skonfigurowany projekt.
Konieczne jest
określenie miejsca,
gdzie zainstalowany
jest klient CVS (np.
Tortoise CVS,
WinCVS) na
lokalnej maszynie
Parametry dostępowe do
repozytorium CVS
obejmują informacje o
sposobie autoryzacji,
adresie serwera, nazwie
uŜytkownika oraz
lokalizacji repozytorium
na serwerze
Przycisk Test
umoŜliwia sprawdzenie
poprawności podanych
parametrów
dostępowych do
repozytorium CVS
7-18 Okno tworzenia nowego projektu CVS
7.6.4.3 Tworzenie projektu Code CoOp
Podobnie jak w przypadku projektów CVS, przy tworzeniu projektu typu Code
CoOp, oprócz określenia jego nazwy i wskazania miejsca na dysku konieczne jest takŜe
podanie parametrów umoŜliwiających dostęp do projektu Code CoOp. Warto zaznaczyć,
147
Ŝe tworzenie nowego projektu BAGGU w systemie Code CoOp tak naprawdę oznacza
dołączanie plików BAGGU do juŜ istniejącego projektu Code CoOp. Przed przystąpieniem
do tworzenia nowego projektu BAGGU w aplikacji Code CoOp musi juŜ istnieć
odpowiednio skonfigurowany projekt.
Konieczne jest
określenie miejsca,
gdzie zainstalowany
jest Code CoOp na
lokalnej maszynie
7-19 Okno tworzenia nowego projektu Code CoOp
7.6.5
Dołączanie do istniejącego projektu
Dołączanie do juŜ istniejącego projektu odbywa się poprzez wybór odpowiedniej
opcji z menu Project/Join existing project (Rysunek 7-20). Wybór konkretnej opcji jest
uzaleŜniony od rodzaju projektu, do jakiego chcemy dołączyć.
7-20 Menu dołączania do istniejącego projektu
Zasadniczo dołączanie do istniejącego projektu odbywa się analogicznie do
tworzenia nowego projektu. Bez względu na rodzaj projektu, system poprosi o wskazanie
miejsca lokalizacji pliku projektu, do którego chcemy dołączyć. Plik projektu jest plikiem
XML o nazwie NAZWA_PROJEKTU.xml i jest zawsze umieszczonym w katalogu /baggu
w miejscu lokalizacji projektu, do którego dołączamy. Pozostałe parametry podawane przy
dołączaniu do projektu są analogiczne do tych opisywanych przy okazji tworzenia
projektów.
148
7.6.6
Rezygnacja z uczestnictwa w projekcie
Rezygnacja z uczestnictwa w projekcie w systemie BAGGU odbywa się poprzez
wybór opcji Project/Defect from project (Rysunek 7-21). Wybór tej opcji spowoduje
usunięcie zalogowanego uŜytkownika z listy członków aktualnie wybranego projektu
i usunięcie z dysku lokalnego wszystkich danych projektu.
7-21 Menu rezygnacji z udziału w projekcie
Opcja rezygnacji z udziału w projekcie jest dostępna tylko w przypadku, gdy
wybrany jest jakiś projekt. W przypadku, gdy zalogowany uŜytkownik jest ostatnim
członkiem projektu, system zapyta czy cały projekt ma zostać zakończony i permanentnie
usunięty.
7.6.7
Ustalanie ról w obrębie projektu
Ustalanie ról w obrębie projektu w systemie BAGGU jest dostępne tylko dla
uŜytkowników posiadających rolę Kierownika Projektu (Project Manager) w konkretnym
projekcie. Przejście do formularza zarządzania projektem odbywa się poprzez wybór opcji
Project/Project members (Rysunek 7-22).
7-22 Menu ustalania ról w projekcie
Wybór tej opcji spowoduje wyświetlenie okna z listą aktualnych członków projektu
wraz z ich zakresem ról. Za pomocą tego okna (Rysunek 7-23) Kierownik Projektu
dokonuje przydziału ról w obrębie projektu.
149
Wybór ról w obrębie projektu
odbywa się poprzez ich
zaznaczenie w wierszu danego
uŜytkownika. System dba o to aby
w danym projekcie był zawsze co
najmniej jeden kierownik.
7-23 Okno ustalania ról w projekcie
7.6.8
Przeglądanie listy problemów
Wybór konkretnego projektu z listy projektów spowoduje odświeŜenie okna
głównego systemu. Na liście problemów pokaŜą się wszystkie problemy zarejestrowane
w ramach tego projektu, a mechanizmy filtracji zostaną uaktywnione i uzupełnione
zgodnie z aktualnym stanem projektu. Z poziomu okna głównego uŜytkownik ma dostęp
do kompletu informacji i funkcjonalności odnośnie aktualnie wybranego projektu, co
zostało przedstawione i opisane na Rysunku 7-24. Od momentu wybrania konkretnego
projektu, wszystkie operacje wykonywane w systemie odnoszą się do wybranego projektu.
Aktualnie wybrany projekt moŜna
w kaŜdej chwili zmienić wybierając go
z listy projektów
Lista problemów zawiera
wszystkie zarejestrowane
w projekcie problemy.
Kolorystyka wierszy zaleŜna
jest od aktualnego stanu
danego problemu
7-24 Główne okno systemu po wyborze konkretnego projektu
150
7.6.9
Rejestracja problemów
W celu maksymalnego wykorzystania moŜliwości narzędzia, w projekcie
wprowadziłem rygorystycznie przestrzegane wymaganie rejestracji kaŜdego, nawet
najmniej istotnego, napotkanego problemu. Do bazy danych projektu dodawane były
zarówno ujawniające się defekty, jak i pomysły na usprawnienie narzędzia i rozszerzenie
jego funkcjonalności. W efekcie, w krótkim czasie rejestr problemów projektu szybko
wypełniony został opisami sukcesywnie usuwanych defektów oraz sporą ilością propozycji
na usprawnienie narzędzia w jego przyszłych wersjach.
Przez rejestrację problemów rozumiane jest dodawanie defektów oraz próśb
o zmiany do bazy danych konkretnego projektu. Dodawanie problemów w systemie
BAGGU odbywa się na dwa sposoby – poprzez menu Problem albo przyciski w pasku
narzędzi (patrz Rysunek 7-25). Wybór konkretnej opcji jest uzaleŜniony od rodzaju
problemu, który chcemy zarejestrować.
7-25 Sposoby rejestrowania problemów
7.6.9.1 Rejestracja defektu
Rejestracja defektu odbywa się poprzez wybranie opcji Problem/Report a Bug
z menu głównego albo naciśnięcie przycisku
w pasku narzędzi aplikacji. Po wybraniu
tej opcji na ekranie pojawi się formularz zgłaszania defektu, którego opis znajduje się na
Rysunku 7-26.
7.6.9.2 Rejestracja prośby o zmianę
Rejestracja prośby o zmianę odbywa się poprzez wybranie opcji Problem/Add
change request z menu głównego albo naciśnięcie przycisku
w pasku narzędzi
aplikacji. Po wybraniu tej opcji na ekranie pojawi się formularz zgłaszania prośby
o zmianę, którego opis znajduje się na Rysunku 7-27.
151
Podświetlone pola
wskazują pola,
których wypełnienie
jest wymagane do
rejestracji defektu
Przycisk Add bug staje
się dostępny dopiero w
momencie uzupełnienia
wszystkich wymaganych
pól opisu defektu
7-26 Formularz rejestracji defektu
Podświetlone pola
wskazują pola,
których wypełnienie
jest wymagane do
rejestracji prośby o
zmianę
Przycisk Add change request
staje się dostępny dopiero w
momencie uzupełnienia
wszystkich wymaganych pól
opisu prośby o zmianę
7-27 Formularz zgłaszania prośby o zmianę
7.6.10 Podgląd problemów
Dwukrotne kliknięcie (ang. double click) na wybranym wierszu listy problemów
spowoduje ukazanie się okna podglądu danego problemu. Okno podglądu składa się
zasadniczo z 4 elementów, do których dostęp uzyskuje się za pomocą zakładek
umieszczonych na górze okna, co przedstawia Rysunek 7-28. Warto w tym momencie
152
zaznaczyć, Ŝe wszelkie zmiany dokonywane na problemie, są fizycznie zapisywane
dopiero po zamknięciu okna podglądu.
Zakładka Status zawiera informacje na temat aktualnego
stanu problemu oraz mechanizmy do jego kontrolowania
Zakładka Comments zawiera
wszystkie komentarze dodane do
problemu oraz formularz dodawania
nowych komentarzy
Zakładka Details zawiera
wszystkie informacje o
problemie podane w trakcie
jego rejestracji
Zakładka History zawiera
informacje na temat historii
zmian danego problemu
7-28 Zakładki w podglądzie problemu
7.6.10.1 Zakładka danych problemu
Zakładka Details zawiera wszystkie informacje o problemie podane w trakcie jego
rejestracji i jest analogiczna do formularzy wyświetlanych przy dodawaniu problemów do
projektu. W zaleŜności od rodzaju problemu, wyświetlany jest tutaj formularz defektu albo
formularz prośby o zmianę.
7.6.10.2 Zakładka statusu problemu
Zakładka Status zawiera informacje na temat aktualnego stanu problemu oraz
mechanizmy do jego kontrolowania. Bez względu na rodzaj problemu składa się z dwóch
części – panelu aktualnego stanu problemu oraz mechanizmu modyfikacji stanu problemu,
co zostało przedstawione na Rysunku 7-29.
Aktualne wartości
atrybutów
determinujących stan
problemu
wyświetlane są w
górnej części zakładki
i nie podlegają
bezpośredniej edycji
Zmiana statusu
problemu odbywa się
za pośrednictwem
mechanizmów w
dolnej części
zakładki. Za ich
pośrednictwem
moŜliwa jest zmiana
priorytetu, stanu,
przypisania oraz
rozwiązania problemu
Wartości moŜliwych
zmian statusu
problemu są
uzaleŜnione od jego
aktualnego stanu i są
zgodne z cyklem
Ŝycia problemu
implementowanym
przez narzędzie
7-29 Zakładka statusu problemu
153
7.6.10.3 Zakładka komentarzy problemu
Zakładka Comments zawiera wszystkie komentarze dodane do problemu oraz
formularz dodawania nowych komentarzy, co zostało przedstawione na Rysunku 7-30.
Lista komentarzy zawiera wszystkie dotychczas
dodane do problemu komentarze. Listę moŜna
dowolnie sortować i przeglądać
Dodanie nowego komentarza odbywa się
poprzez wypełnienie pola treści oraz
naciśnięcie przycisku Add comment
7-30 Zakładka komentarzy problemu
7.6.10.4 Zakładka historii problemu
Zakładka History zawiera informacje na temat historii zmian danego problemu.
Wszelkie modyfikacje dokonywane na problemie rejestrowane są w postaci zdarzeń
w jego historii. Na tej zakładce uŜytkownik moŜe dowolnie przeglądać przebieg zmian
danego problemu. Wpisy w historii problemu nie podlegają ręcznej edycji.
7.7
Testowanie narzędzia
Testowanie to sprawdzanie zgodności systemu ze specyfikacją na podstawie jego
działania. Jest to najczęściej stosowana technika zapewnienia jakości. Proces testowania
moŜe przyjmować róŜne formy od niskopoziomowego testowania jednostkowego (ang.
unit test) elementów systemu, aŜ po złoŜone testy mające na celu badanie funkcjonalnej
kompletności oraz przydatności oprogramowania dla jego przyszłych uŜytkowników.
W trakcie procesu wytwórczego systemu BAGGU główny nacisk kładziony był na
poprawne odwzorowanie teoretycznego modelu problemu oraz obudowanie go
154
funkcjonalnym narzędziem wspomagającym proces ich zarządzania w projekcie
informatycznym. Proces testowania narzędzia był takŜe podporządkowany tym celom
i koncentrował się głownie na testach funkcjonalnych oraz akceptacyjnych.
7.7.1
Testy funkcjonalne
Testy funkcjonalne stanowią podklasę testów walidacyjnych, których celem jest
sprawdzenie, czy system udostępnia wszystkie funkcje zamodelowane przez przypadki
uŜycia oraz zweryfikowanie poprawności ich realizacji. Do przeprowadzenia testów tego
typu formułuje się tzw. przypadki testowe, które precyzyjnie definiują, która
funkcjonalność systemu podlega badaniu oraz spodziewane wyniki testu. Wszelkie
odstępstwa pomiędzy efektem poŜądanym opisanym w przypadku testowym, a efektem
rzeczywistym uzyskanym podczas testu uznawane są za defekty.
W przypadku systemu BAGGU testy funkcjonalne polegały na badaniu
poprawności działania wszystkich funkcji udostępnianych przez narzędzie i obejmowały
wszelkie operacje dokonywane na projektach, ich uczestnikach oraz rejestrowanych
problemach. KaŜda elementarna funkcjonalność opisana przez przypadki uŜycia została
uruchomiona
i
zbadana
w
odniesieniu
do
wszystkich
rodzajów
projektów
implementowanych w narzędziu (projekty lokalne, CVS oraz Code CoOp). Przykładowo,
dla przypadku uŜycia „Rozpoczęcie nowego projektu”, narzędzie zostało przetestowane
pod
kątem
moŜliwości
poprawnego
zainicjowania
trzech
rodzajów
projektów.
Przeprowadzone testy funkcjonalne pokrywały w całości wyspecyfikowany zakres
funkcjonalności narzędzia.
Testy funkcjonalne były szczególnie waŜne w przypadku projektów integrujących
się z narzędziami do kontroli wersji. Przypadki testowe badające poprawność elementów
systemu uzaleŜnionych od zewnętrznych aplikacji (CVS,Code CoOp) musiały być poparte
dodatkowymi testami systemowymi badającymi pracę narzędzia z systemem operacyjnym,
plikami XML oraz przede wszystkim pracę w warunkach rozproszonych z uŜyciem wyŜej
wymienionych aplikacji. Do celów testów zostało uruchomione specjalne środowisko
składające się z dwóch komputerów połączonych z Internetem. Na obu maszynach
zainstalowano system BAGGU wraz z identycznym zestawem aplikacji i narzędzi
wspomagających (Code CoOp, TortoiseCVS). W przypadku projektów CVS konieczne
było ponadto utworzenie testowego repozytorium na zdalnym serwerze CVS. Testy
polegały na badaniu funkcjonalności narzędzia (tworzenie projektów, dodawanie
155
i modyfikacja problemów itd.) w przypadku pracy z projektami CVS oraz CodeCoOp.
W trakcie testów badana była zarówno poprawność komunikacji pomiędzy systemem
BAGGU a interfejsami zewnętrznymi narzędzi, jak równieŜ efekty dokonywanej przez nie
replikacji i synchronizacji plików XML.
7.7.2
Testy akceptacyjne
Zadaniem testów akceptacyjnych jest udowodnienie, Ŝe system osiągnął
postawione przed nim cele oraz spełnia wszystkie jawnie wyspecyfikowane wymagania.
Testy te pozwalają odpowiedzieć na pytanie: „Czy system jest przydatny i czy spełnia
swoje zadania?”. Plan testów akceptacyjnych przyjmuje zazwyczaj postać scenariusza,
który opisuje kroki wykonywane w systemie na drodze do osiągnięcia wybranego celu.
Pozytywny wynik testu akceptacyjnego oznacza, Ŝe badany system pozwala osiągnąć
załoŜone cele w myśl zdefiniowanych dla tych celów kryteriów akceptacyjnych.
W przypadku systemu BAGGU konieczne było opracowanie scenariuszy
testowych, które w sposób kompleksowy demonstrują i jednocześnie weryfikują
moŜliwości narzędzia w zakresie zarządzania problemami w projekcie informatycznym.
Przytaczany w kolejnych punktach scenariusz stanowi przykład i obejmuje wszystkie
czynności, które są wykonywane rutynowo podczas typowego obiegu problemu
w projekcie oraz takie, które są wykonywane tylko co pewien okres czasu (np. zakładanie
nowego projektu i dodawanie do niego członków). Scenariusz został sformułowany
w sposób ogólny i moŜe być stosowany do testowania wszystkich rodzajów projektów
implementowanych przez narzędzie BAGGU (projekt lokalny, CVS oraz Code CoOp).
7.7.2.1 Warunki wstępne
Zaproponowany w punkcie 7.7.2.2 scenariusz testowy został przygotowany do
uruchomienia na pojedynczej maszynie, na której zostało wcześniej zainstalowany komplet
oprogramowania niezbędnego do przeprowadzenia testów (patrz punkt 7.6.1 – Instalacja
narzędzia). Przed przystąpieniem do realizacji testów akceptacyjnych konieczne jest takŜe
stworzenie w systemie Windows XP czterech kont uŜytkowników z prawami
administracyjnymi o nazwach odpowiednio: Client, Project Manager, Developer oraz
Tester. W trakcie scenariusza narzędzie BAGGU jest zawsze uruchamiane z uŜyciem
funkcji systemu Windows XP „Uruchom jako…” (ang. „Run as…”), która umoŜliwia
wykonywanie danej aplikacji z uprawnieniami i „toŜsamością” konkretnego uŜytkownika
bez konieczności wielokrotnego logowania się w systemie.
156
7.7.2.2 Scenariusz testowy
Celem scenariusza testowego jest rozpoczęcie nowego projektu, przypisanie do
niego 4 członków oraz prześledzenie typowego obiegu pojedynczego problemu
w projekcie. Scenariusz przewiduje następujący ciąg kroków:
1) Project Manager uruchamia narzędzie i tworzy w nim nowy projekt o nazwie TEST.
2) Client uruchamia narzędzie i dołącza do projektu TEST jako klient.
3) Developer uruchamia narzędzie i dołącza do projektu TEST jako wykonawca.
4) Tester uruchamia narzędzie i dołącza do projektu TEST jako tester.
5) Client zgłasza nowy problem (defekt lub prośbę o zmianę) w projekcie TEST
wypełniając formularz zgłoszenia przykładowymi danymi.
6) Tester wchodzi w podgląd problemu dodanego przez klienta w kroku 5. Tester dodaje
do problemu komentarz o dowolnej treści. Tester zmienia stan problemu na OPEN
(otwarty).
7) Project Manager wchodzi w podgląd problemu dodanego przez klienta w kroku 5.
Project Manager dodaje do problemu komentarz o dowolnej treści. Project Manager
zmienia priorytet problemu na HIGH (wysoki). Project Manager przypisuje problem do
uŜytkownika Developer.
8) Developer wchodzi w podgląd problemu dodanego przez klienta w kroku 5. Developer
dodaje do problemu komentarz o dowolnej treści. Developer zmienia stan problemu na
WORK IN PROGRESS (prace w toku). Developer rozwiązuje problem ustawiając
rozwiązanie na FIXED (naprawiony).
9) Tester wchodzi w podgląd problemu dodanego przez klienta w kroku 5. Tester zmienia
stan problemu na VERIFIED (zweryfikowany).
10) Client wchodzi w podgląd problemu dodanego przez siebie w kroku 5. Client zmienia
stan problemu na CLOSED (zamknięty).
Spodziewany wynikiem scenariusza jest istnienie projektu o nazwie TEST, do
którego przypisanych jest 4 członków oraz w którym zarejestrowany jest pojedynczy
problem dodany przez klienta w punkcie 5. Zarejestrowany problem powinien na
zakończenie scenariusza znajdować się w stanie CLOSED (zamknięty), a z podglądu jego
historii powinna być moŜliwość prześledzenia przebiegu kroków 5-10.
157
7.7.3
Wyniki
Wielokrotnie powtarzane testy funkcjonalne poszczególnych elementów narzędzia
pozwoliły wykryć defekty zaszyte w kodzie źródłowym systemu. Po ich wyeliminowaniu
moŜna było przystąpić do testów akceptacyjnych, które zostały przeprowadzane według
kilku ustalonych scenariuszy. Pozytywnie zakończone testy akceptacyjne stały się
podstawą do uznania wytworzonego systemu za spełniający wymagania i cele określone
w specyfikacji wymagań.
7.8
Wnioski
Narzędzie okazało się nieocenioną pomocą przy planowaniu i organizacji pracy nad
systemem. Informacja o pojawiających się w znacznej ilości błędach, zwłaszcza
w początkowych etapach implementacji narzędzia, mogłaby zostać zagubiona, gdyby nie
ich skrupulatna rejestracja. Defekty jednej części systemu często ujawniały się
w momencie realizacji i testowania zupełnie innego fragmentu funkcjonalności.
Rejestracja nieoczekiwanie występujących błędów pozwalała koncentrować się na
aktualnie realizowanym zadaniu, bez obawy o zagubienie informacji o ich wystąpieniu.
Przekonałem się, Ŝe wprowadzenie do procesu wytwórczego sprawnej obsługi problemów
pozwala w szybkim czasie wyrobić nawyk podejścia zadaniowego do projektu.
Implementacja systemu przeplatała się w moim wypadku z innymi czynnościami
takimi jak pisanie i poprawa pracy dyplomowej, obowiązkami osobistymi, zawodowymi
i związanymi ze studiami. W trakcie projektu często zdarzało się, Ŝe okres od ujawnienia
się defektu do rozpoczęcia pracy nad jego rozwiązaniem był relatywnie długi. W takiej
sytuacji nieocenione okazywały się wszelkie informacje zapisywane w bazie problemów
w momencie ich rejestracji. Praktyka pokazała, jak istotny jest dobry opis istoty błędu oraz
ścieŜki do jego powtórzenia. Zaimplementowana w narzędziu struktura danych, choć
zawęŜona w stosunku do modelu problemu przedstawionego w Rozdziale 4, okazała się
nadzwyczaj efektywna w całym procesie.
Ze względu na specyfikę projektu pełniłem w nim rolę zarówno osoby zgłaszającej
problemy (klient, tester), jak równieŜ wykonawcy (programista) i kierownika projektu.
Narzędzie implementuje podział na role w projekcie informatycznym a sposób obsługi
problemów i ich cyklu Ŝycia odzwierciedlał załoŜenia przedstawione w części teoretycznej
mojej pracy dyplomowej. Obsługa problemu zawsze zaczynała się od jego rejestracji
w systemie. Później następował etap decyzyjny, w którym przydzielano do problemu
158
odpowiedni priorytet oraz osobę odpowiedzialną za jego rozwiązanie. Po etapie
opracowywania rozwiązania następowała jego weryfikacja i ostateczne zamknięcie
problemu lub jego ponowne otwarcie. Oczywiście trudno w przypadku jednoosobowego
projektu mówić o pełnym wykorzystaniu moŜliwości, jakie daje dobrze zdefiniowany cykl
Ŝycia problemu, nie mniej jednak praktyka pokazała, Ŝe przyjęty model i schemat przejść
pomiędzy stanami okazał się trafny.
W moim odczuciu zastosowanie narzędzia w projekcie w znacznym stopniu
przyczyniło się do poprawienia efektywności radzenia sobie z problemami. Rejestrowanie
na bieŜąco ujawniających się defektów spowodowało, Ŝe odkrywane, często przypadkowo,
błędy systemu nie miały prawa pozostawać nierozwiązane. Szybka rejestracja kaŜdego
błędu pozwalała uniknąć sytuacji, w której informacja o błędzie i ścieŜka do jego
powtórzenia została zagubiona. Z drugiej strony, dodawanie do rejestru problemów opisów
nowych funkcjonalności (próśb o zmianę) pozwoli w przyszłości sukcesywnie
uszczegóławiać i wprowadzać w Ŝycie wszelkie pomysły pojawiające się w trakcie
uŜytkowania systemu.
NaleŜy zwrócić uwagę na dobry wpływ narzędzia juŜ w przypadku projektu o tak
małych rozmiarach jak moja praca dyplomowa. Przypuszczalnie, w przypadku projektów
o większej złoŜoności i bardziej licznym zespole korzyści z jego zastosowania będą
jeszcze
bardziej
odczuwalne.
Rozproszone
warunki
pracy,
moŜliwość
stałego
monitorowania stanu realizacji zadań oraz jasny podział pracy to tylko nieliczne
z
upatrywanych
zalet
stosowania
systemu
BAGGU
w
dowolnym
projekcie
informatycznym.
159
8.
Podsumowanie
“A single quote of wisdom, is the summary of a lifetime of experiences”.
Unknown author
Generalnym wnioskiem płynącym z pracy jest to, Ŝe proces zarządzania
problemami jest jednym z bezwzględnie potrzebnych elementów procesu wytwarzania
oprogramowania. Jednym z najbardziej podstawowych sposobów na usprawnienie
komunikacji i pracy zespołu jest wprowadzenie do projektu formalnego procesu śledzenia
defektów oraz zmian. Jest rzeczą oczywistą, Ŝe oprogramowanie w czasie swojego cyklu
Ŝycia, począwszy od wczesnej fazy projektowania, poprzez etap budowania systemu, aŜ do
wdroŜenia kolejnych jego wersji u klienta będzie się zmieniało. Zmiany te mogą wynikać
z pojawiających się nowych wymagań lub modyfikacji tych, które były juŜ uwzględnione,
albo być wymuszone przez wykrycie defektów. Kluczową sprawą jest takie zarządzanie
problemami, które zagwarantuje, Ŝe zgłoszony defekt, czy nowe wymaganie, nie zostanie
pominięte ani zagubione. KaŜdy zarejestrowany problem powinien być przydzielony
odpowiednim osobom, które albo zajmą się poprawieniem defektów, albo, zanim problem
zostanie przekazany programistom, ocenią jak bardzo kosztowne będzie wprowadzenie
Ŝądanych zmian. Brak jasnych reguł w tej materii jest duŜym i kosztownym błędem
spowodowanym
zarządzania
najczęściej
problemami
krótkowzrocznością
musi
być
procesem
kierowników
formalnym
ze
projektów.
wszystkimi
Proces
tego
konsekwencjami:
•
Proces musi być wykonywany systematycznie zgodnie z ustalonymi procedurami
według zdefiniowanego wcześniej modelu.
•
Dane gromadzone w procesie muszą być trwale archiwizowane w celu ich stałej
dostępności i późniejszej analizy.
•
Proces musi podlegać stałej optymalizacji i dostosowywaniu do specyfiki
konkretnych projektów.
•
Wszyscy członkowie zespołu projektowego, w tym takŜe przedstawiciele klienta,
muszą być świadomi roli procesu oraz reguł ustalonych w jego ramach.
Kwestia dobrego zarządzania całym procesem jest sprawą kluczową, gdyŜ
niespełnienie powyŜszych wymagań moŜe spowodować, Ŝe zamiast usprawnić
komunikację w zespole przyczyni się do jej drastycznego pogorszenia i stanie się źródłem
160
dodatkowego zamieszania i kosztów, nad
którymi
trudno będzie zapanować.
Wprowadzenie procedur zarządzania problemami w projekcie owocuje wzrostem
produktywności zespołu. KaŜdy wie, czym powinien się zająć, co więcej, moŜna rozłoŜyć
równomiernie obciąŜenie pracą, gdyŜ wiadomo, kto ma ile przydzielonych zadań.
Z drugiej strony klient jest zadowolony, poniewaŜ istnieje dobrze zdefiniowany sposób
zgłaszania błędów i próśb o uzupełnienie produktu o nową funkcjonalność. W kaŜdym
momencie trwania projektu wiadomo, kto na danym etapie prac zajmuje się określonym
zgłoszeniem. Warto zwrócić uwagę, Ŝe proces zarządzania problemami opłaca się wdraŜać
nie tylko w przypadku duŜych projektów, w których bierze udział kilkadziesiąt-kilkaset
osób. Efektywne zarządzanie problemami przynosi naprawdę znaczące korzyści równieŜ
w przypadku niezbyt duŜego projektu, w który zaangaŜowanych jest kilku programistów,
szczególnie, gdy pracują oni w warunkach rozproszonych.
Z pomocą przychodzą systemy wspomagające i wspierające zarządzanie
problemami. Warto pamiętać, iŜ w obecnych czasach uŜycie odpowiednich narzędzi, nie
jest juŜ tylko usprawnieniem procesu wytwórczego, ale staje się wręcz konieczne dla ich
powodzenia. W idealnej sytuacji narzędzie do śledzenia defektów i zmian jest
zintegrowane z narzędziem kontroli wersji – pozwala to połączyć występujący defekt lub
prośbę o dodanie funkcjonalności z kolejnymi wersjami konkretnych artefaktów (np. kodu
źródłowego) i pozwala tworzyć wersje produktu, które są zdefiniowane przez określoną
funkcjonalność. Większość duŜych i kosztownych komercyjnych systemów idzie właśnie
w takim kierunku. Z drugiej strony istnieje duŜy segment rynku, często darmowych,
rozwiązań
ukierunkowanych
ściśle
na
zarządzanie
problemami.
Większość
z przedstawionych w pracy systemów jest ciągle rozwijanych, a poszerzanie ich
funkcjonalności podyktowane jest specyfiką oraz stale zwiększającymi się potrzebami
współczesnych projektów informatycznych.
W ramach niniejszej pracy podjęto próbę stworzenia takiego systemu. Aby nie
powielać schematów z powszechnie dostępnych narzędzi, zrealizowany system został
opracowany w modelu rozproszonym. Pozbawienie go centralnego repozytorium samo
w sobie zdeterminowało jego prototypowy i eksperymentalny charakter. Niemniej jednak
solidne podstawy teoretyczne w postaci formalnego modelu problemu opracowanego
w części teoretycznej pracy przyczyniły się do powstania wartościowego i w pełni
161
funkcjonalnego, w myśl wyspecyfikowanych wymagań, produktu. NajwaŜniejsze jego
zalety to:
•
UmoŜliwienie pracy w przypadku rozproszenia uczestników projektu.
•
Udostępnienie
kierownikom
zespołów
silnego
narzędzia
wspomagającego
planowanie i zarządzanie zasobami projektu.
•
Udostępnienie informacji o problemach i usprawnienie komunikacji wewnątrz
zespołu.
•
Wyraźny, bardziej klarowny, podział zadań, dzięki czemu uczestnicy projektu
lepiej wiedzą jaki jest ich zakres obowiązków i czego się od nich oczekuje.
•
Sformalizowanie
procesu
zarządzania
problemami
przyczynia
się
do
efektywniejszego wykorzystania zasobów i do ściślejszego przestrzegania
terminów realizacji zadań.
•
Mały rozmiar rozwiązania i stopień jego skomplikowania wiąŜe się z łatwą
instalacją, konfiguracją i wdroŜeniem w środowisku projektu.
Zalety te czynią z systemu silne narzędzie, które moŜe być wykorzystywane przy
okazji wielu małych i średnich projektów, zarówno komercyjnych jak i akademickich.
Stworzony w ramach pracy system nie rozwiązuje jednak zarządzania problemami
w sposób kompleksowy, głównie ze względu na kilka uproszczeń w stosunku do
opracowanego w części teoretycznej modelu problemu. Brakuje w nim niektórych
atrybutów
opisu
problemu,
rozbudowanych
mechanizmów
bezpieczeństwa
oraz
dedykowanego modułu słuŜącego do analizy i archiwizacji gromadzonych danych. Nie
mniej jednak otwartość systemu, przy jego dobrze udokumentowanym projekcie, sprawia,
iŜ nic nie stoi na przeszkodzie rozszerzania systemu o dodatkowe moduły
i funkcjonalność. W mojej subiektywnej ocenie system moŜe z powodzeniem stać się
integralną częścią wsparcia narzędziowego w dowolnym projekcie.
Podsumowując, naleŜy podkreślić, iŜ pierwotnie ustalone cele niniejszej pracy
dyplomowej zostały osiągnięte. Część teoretyczna porządkuje w jednolitą całość wiedzę
związaną z procesem zarządzania problemami, a powstałe narzędzie pokazuje jej
praktyczne wykorzystanie.
162
9.
Bibliografia
9.1
KsiąŜki
[BAY2001]
[CADL2000]
[GAMM1995]
[GOR2000]
[ITILSRV2000]
[LEST2000]
[RUP1998]
[SZEJ2002]
[WISZ2006]
9.2
Artykuły
[ADAM1999]
[SKOCZ1996]
[TATH1999]
9.3
Michael E. Bays - Metodyka wprowadzania oprogramowania na
rynek
Cadle J. & Yeates.D - Zarządzanie procesem tworzenia systemów
informacyjnych
Gamma E. & Helm R. &Johnson R. & Vlissides J. - Design
Patterns: Elements of Reusable Object-Oriented Software. AddisonWesly 1995
Górski J.: InŜynieria oprogramowania w projekcie informatycznym.
MIKOM 2000
Service Suport Service Desk and the Process of Incydent
Management, Problem Management, Configuration Management,
Change Management and Release Management ISBN 0 11 330015 8
Lester A.: Project Planning and Control
RATIONAL SOFTWARE CORP., Rational Unified Process. Best
Practices for Software Development Teams, White Paper, Rational
Software Corporation 1998.
Szejko S. (red) „Metody wytwarzania oprogramowania”, MIKOM
2002
Wiszniewski B., Bereza-Jarociński B. „Teoria i praktyka testowania
programów”, PWN 2006
Adamczyk A. – „Sposoby zarządzania przepływem uwag w
rozproszonych zespołach projektowych”, V Konferencja Polish
Oracle User Group (PLOUG) Zakopane Październik 1999
Skoczylas G. – „Programowanie defensywne”, PC Kurier 08/1996
http://www.pckurier.pl/archiwum/art0.asp?ID=571
Tatham S. – „Jak efektywnie zgłaszać błędy”, 1999
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Materiały wykładowe
[SZEJIW2003]
[GORBZI2005]
[KUCHZK2005]
Szejko S. & Goczyła K.: Materiały do wykładów z przedmiotu
„InŜynieria oprogramowania”, PG ETI 2003
Górski J.: Materiały do wykładów z przedmiotu „Bezpieczeństwo
Zastosowań Informatyki”, PG ETI 2005
Kucharski M.: Materiały do wykładów z przedmiotu „Zarządzanie
konfiguracją. Zarządzanie zmianą”, PG ETI 2005
163
9.4
Strony Web
[wwwQOUTES]
[wwwPRINCE2]
[wwwOGC]
[wwwITLIFE]
[wwwRELI]
[wwwWIKI]
9.5
Dokumentacja techniczna
[BUGZ2005]
[MAN2005]
9.6
[SWS]
[MPS]
http://www.coolquotescollection.com
http://www.ogc.gov.uk/prince2/
http://www.ogc.gov.uk/index.asp?id=2261
http://www.itlife.pl
http://www.relisoft.com
http://pl.wikipedia.org
dokumentacja Bugzilla
dokumentacja Mantis Bug Tracker
Załączniki
Specyfikacja Wymagań Systemowych
Model i Projekt Systemu
164

Podobne dokumenty