docNarzędzie do rejestracji zmian i problemów w projekcie
download 
Reklamacja 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
