1. Wstęp Kamil DOWGIELEWICZ, Cezary ORŁOWSKI Wydział Elektroniki i Informatyki, Politechnika Koszalińska E mail: kamil.dowgielewicz@tu.koszalin.pl, cor@zie.pg.gda.pl Koncepcja modelu referencyjnego dla rozwoju technologii Open Source testowania oprogramowania Celem pracy jest prezentacja koncepcji modelu referencyjnego dla rozwoju technologii testowania oprogramowania. Modele referencyjne i ich znaczenie dla rozwoju technologii informatycznych są szczegółowo omawiane w standardach informatycznych TOGAF i ITIL [2,3,5]. Brak jest jednak prac poświęconych szczegółowemu omówieniu wykorzystania modeli referencyjnych. Prezentowana praca stanowiąca podsumowanie pierwszego etapu badań autorów ma na celu wykazanie na ile modele referencyjne są istotne dla rozwoju technologii testowania oprogramowania. Autorzy pracy podzielili ją na trzy główne części. W pierwszej przedstawiono problematykę rozwoju technologii Open_Source dla wskazania środowiska wykorzystania modeli referencyjnych. Omówiono koncepcje doboru technologii wspomagających testowanie oprogramowania dla wykazania zarówno przydatności technologii Open Source jak też znaczenia modelu referencyjnego dla ich rozbudowy (dostosowania dla potrzeb organizacji). Część druga w całości jest poświęcona konceptowi modelu referencyjnego obejmującego trzy jego kluczowe elementy: przesłanki struktury bazy wiedzy, koncepcję zmiennych modelu oraz zasadę jego działania. Część trzecia wskazuje na kierunki dalszych badań autorów koncentrujących się nad budową modelu referencyjnego. Wykazanie przydatności zastosowania modelu referencyjnego dla technologii Open Source wymaga omówienia głównych problemów ich rozwoju. Obecnie dostępne narzędzia Open Source posiadają różne funkcjonalności, m.in. możliwości tworzenia specyfikacji projektu, układania wymagań, zapewniają implementację z kodem aplikacji. Umożliwiają także komunikacje między poszczególnymi członkami zespołu projektowego, wspierają podział członków zespołu ze względu na pełnione role i wykonywane zadania, zapewniają też planowanie prac oraz umożliwiają przetestowanie produktu przed wdrożeniem oraz wiele, wiele innych. Jedne z narzędzi ograniczają się do kilku podstawowych funkcjonalności inne zaś posiadają ich znacznie więcej. Analiza historii ich rozwoju i bieżącego stanu wskazuje, że podstawowym problemem narzędzi Open Source jest konieczność wyboru pomiędzy złożonością i zaawansowaniem danego rozwiązania, a jego ograniczonym zakresem i łatwością obsługi. Ponieważ determinantem doboru danej technologii potrzebnej do wytwarza-
30 Kamil Dowgielewicz, Cezary Orłowski nie oprogramowania są wymagania klienta zaawansowane narzędzia z założenia są bardziej użyteczne, ze względu na szeroki wachlarz oferowanych funkcjonalności. Jest to istotne ze względu na trudności w przewidzeniu, która z funkcjonalności będzie niezbędna do wyprodukowania oprogramowania. Z drugiej strony zaawansowane technologie są trudne do opanowania i niewykorzystywane w całości. Zatem nasuwa się pytanie czy lepiej posiadać produkt lekki, tani i prosty w obsłudze, czy potężny, drogi (pod względem potrzebnej infrastruktury i kosztów wyszkolenia personelu) oraz trudny w obsłudze, ale za to bogaty we wszystkie potrzebne funkcjonalności? Doświadczenie autorów pokazuje, że lepiej jest posiadać produkt lekki, ale umożliwiający rozbudowywanie o kolejne, potrzebne funkcjonalności, w miarę zmieniających się wymagań klientów. Jednak przy większych projektach istnieje ryzyko, że wymagania stawiane przez klienta spowodują nadmierną rozbudowę i skomplikowanie wykorzystywanego oprogramowania, co wiąże się ze zbyt dużymi kosztami (związanymi z pracochłonnością i wydłużenia czasu realizacji). W takich sytuacjach, mimo wszystko tańszym rozwiązaniem jest zakup większego narzędzia i przeszkoleniem zespołu z zakresu jego obsługi. By ograniczyć niepotrzebnie koszta należałoby przewidzieć, które funkcjonalności będą niezbędne do wytworzenia danego projektu i wówczas podjąć decyzję, które z rozwiązań jest bardziej opłacalne. Obecnie małe i średnie firmy zajmujące się wytwarzaniem oprogramowania mają duży problem z przewidzeniem, które z funkcjonalności będą niezbędne do spełnienia danych wymagań stawianych przez klienta. Należałoby więc opracować metodę, która wskazywałaby firmom, cele rozwoju wykorzystywanej technologii Open Source. W artykule autorzy przedstawili sposób opracowania tej metody. 2. Koncept modelu referencyjnego Proces doboru odpowiedniego narzędzi wspomagającego wytwarzanie oprogramowania jest kwestią niezwykle istotną dla sprawnego działania firmy programistycznej. Nasuwa się więc pytanie: Jak dobrać optymalne narzędzie do wytwarzania oprogramowania? Pod pojęciem optymalnego narzędzia należy rozumieć taki produkt który będzie spełniał wszystkie wymagania stawiane przez wytwarzane oprogramowanie i klienta, tani (najlepiej darmowy), łatwy w obsłudze, a przede wszystkim taki, który będzie zapewniał możliwość rozbudowy jego funkcjonalności. Problem doboru optymalnego narzędzia dotyka w szczególność małych i średnich firm, które dysponują ograniczonymi środkami finansowymi na zakup drogich i zaawansowanych narzędzi wspomagających proces wytwarzania oprogramowania. W większości przypadków firmy te wykorzystują narzędzia Open Source. Charakteryzują się one przede wszystkim łatwością obsługi. Ponadto są darmowe oraz zapewniają podstawowe funkcjonalności potrzebne w procesie wytwarzania oprogramowania. Dobór przez firmę narzędzi wspomagających proces wytwarzania oprogramowania musi być przemyślany i zaplanowany długoterminowo. Niewłaściwe ich dobranie może pociągnąć za sobą: skutki finansowe, wytwarzanie nisko jakościowego oprogramowania oraz wydłużenie czasu wytwarzania produktu, co w efekcie przekłada się na niezadowolenie klienta.
Koncepcja modelu referencyjnego dla rozwoju technologii Open Source 31 Doświadczenie autorów pokazuje, że firma programistyczna musi być przygotowana na możliwość tworzenia różnego typu oprogramowania w zależności od wymagań klienta. Problem pojawia się, gdy wymagania stawiane przez klienta nie mogą być spełnione przez aktualnie wykorzystywane narzędzie Open Source. W takim przypadku pozostaje możliwość zmiany istniejących narzędzia na inne lub rozbudowa obecnie stosowanego o kolejne funkcjonalności. Zakup nowych narzędzi jest stosunkowo kłopotliwy i mało opłacalny. Wiąże się to z rosnącymi kosztami, potrzebą wyszkolenia personelu lub zmianą przyjętych i sprawdzonych procedur panujących w firmie. Alternatywą jest rozbudowa aktualnie stosowanego narzędzia, co w większości przypadków jest bardziej opłacalne. Jeżeli jednak wymagania stawiane przez klienta (lub wytwarzane oprogramowanie) będą wymagały dołączenia zbyt wielu nowych funkcjonaności (co wiąże się ze wzrostem kosztów finansowych jak i wydłużeniem czasu realizacji projektu), może okazać się, że rozbudowa stosowanych narzędzi będzie mniej opłacalna niż zakup nowych. Baza wiedzy RQM i narzędzie Open Source Dane wejściowe Narzędzie Open Source Moduł jakościowego opisu parametrów Komparator Maszyna wnioskująca Decyzja Wynik Baza reguł Rys. 1. Koncepcja modelu referencyjnego Fig. 1. The concept of the model reference Oba podejścia mają swoje wady i zalety. Niewątpliwie najlepszym rozwiązaniem byłaby zastosowanie zaawansowanego narzędzia, które umożliwiałoby wykorzystanie tylko niektórych funkcjonalności i w razie potrzeby ewentualne dołączenie kolejnych. Dlatego potrzebna jest odpowiednia procedura, która umożliwiałaby wskazanie niezbędnych funkcjonalności do wytworzenia oprogramowania w danej firmie. Procedura ta polegałaby na dokładnej analizie dostępnych zasobów, parametrów i środków, a następnie analizie bazy reguł, odzwierciedlającej wiedzę eksperta, która to pozwoli maszynie wnioskującej na obiektywne dobranie potrzebnych funkcjonalności. Efektem zastosowania tej procedury byłoby wskazanie gotowego na-
32 Kamil Dowgielewicz, Cezary Orłowski rzędzia lub planu rozbudowy obecnie stosowanego. Omawianą procedurę obrazuje model referencyjny, który przedstawia rysunek 1 przedstawia koncepcję opisywanego modelu. Model referencyjny opisuje procedurę mającą na celu wskazanie optymalnego narzędzia do wytwarzania programowania. Model składa się z pięciu podstawowych elementów. Pierwszym etapem procedury jest zdefiniowanie parametrów wejściowych (Dane wejściowe, Obecnie stosowane narzędzie Open Source), które następnie poddawane są opisowi jakościowemu (Moduł jakościowego opisu parametrów) na podstawie wcześniej zdefiniowanej bazie wiedzy (Baza wiedzy, RQM i narzędzie Open Source). Tak opisane dane wysyłane są do maszyny wnioskującej, która korzystając z bazy reguł wnioskuje o spełnieniu danych wymagań. Wynikiem tego procesu jest wskazanie optymalnego narzędzia do wytwarzania oprogramowania. 2.1. Przesłanki struktury baz wiedzy modelu referencyjnego Model doboru narzędzia Open Source, (rys. 1) składa się między innymi z procesów porównywania badanego narzędzia, a dokładniej jego funkcjonalności, jako parametru wejściowego, z bazą wiedzy składającej się z elementów wzorcowych. Należy odpowiedzieć na pytanie: czym są elementy wzorcowe i jak należy je definiować? Jeżeli przyjmiemy że efektem działania modelu jest wskazanie optymalnego zbioru funkcjonalności, a co za tym idzie dostępnych narzędzi posiadających te funkcjonalności, elementem wzorcowym powinno być narzędzie posiadające wszystkie dostępne funkcjonalność niezbędne w procesie wytwarzania oprogramowania. Należy zatem zapytać ile oraz jakie to będą elementy? W tym wypadku odpowiedź jest oczywista. Nie ma takiego zamkniętego zbioru funkcjonalności, który mógłby stanowić zamkniętą bazę wiedzy dla badanego modelu. Model referencyjny będzie posiadał ograniczenia, które wynikają z ograniczeń jego zmiennych elementów. Jednym z takich ograniczeń jest niemożność zdefiniowania zamkniętego zbioru funkcjonalności, składających się na bazę wiedzy. Wynika to z faktu, że funkcjonalności wykorzystywane przez narzędzia w procesie wytwarzania oprogramowania mogą się zmieniać. Tworzenie nowych metodologii wytwarzania oprogramowania, powstawanie nowych technologii, zmieniające się wymagania klienta i rynku powodują, że baza wiedzy w modelu powinna mieć możliwość modyfikacji. Baza wiedzy powinna zawierać wszystkie funkcjonalności zawarte w dostępnych narzędziach wspomagających proces wytwarzania oprogramowania. Ponieważ wyodrębnienie tychże funkcjonalności byłoby zadaniem żmudnym i długotrwałym, należałoby oprzeć bazę wiedzy na najbardziej zaawansowanym narzędziu, które przyjęlibyśmy jako aplikację wzorcową. Obecnie kryteria te spełnia. IBM Rational Quality Manager (RQM). RQM jest jednym z modułów platformy Jazz.net służących do testowania oprogramowania. Zapewnia integrację i przepływ informacji pomiędzy użytkownikami pracującymi nad danym projektem. Jedną z głównych funkcjonalności RQM jest usprawnienie procesów dostarczania oprogramowania i śledzenia cyklu życia w procesie programowania i produkcji. Ponadto technologia ta umożliwia modernizację istniejącego kodu. RQM zapewnia bezpieczeństwo informacji zgodne ze standardami bezpieczeństwa serwisu WWW. Dzię-
Koncepcja modelu referencyjnego dla rozwoju technologii Open Source 33 ki zastosowaniu modułów, RQM pozwala na wykorzystanie go również w małych i średnich przedsiębiorstwach. RQM współpracuje z najpopularniejszymi systemami operacyjnymi. Instalacja RQM jest stosunkowo prosta, dzięki wykorzystaniu interaktywnego instalatora. W RQM do dyspozycji użytkowników są trzy główne produkty: Requirement Manager, Quality Manager oraz Configuration and Change Manager. Na potrzeby niniejszej pracy autorzy wykorzystali RQM jako źródło bazy wiedzy dla modelu referencyjnego. Schemat platformy Jazz.net z wyszczególnieniem RQM i jego funkcjonalności przedstawia rysunek 2. Dekompozycja wzorcowej platform Jazz.net pozwala na ukazanie poszczególnych modułów z których się składa. Jednym z nich jest RQM, którego elementami składowymi są wyodrębnione na schemacie funkcjonalności. Są to m.in. planowanie, procesy produkcyjne, testowanie itp. Rys. 2. Dekompozycja wzorcowej platformy Jazz.net Fig. 2. Decomposition of the standard Jazz.net platform Dysponując aplikacją wzorcową, czyli najbardziej zaawansowanym narzędziem wspomagającym proces programowania, którym obecnie jest RQM, należy z niej wyodrębnić wszystkie funkcjonalności. Nasuwa się tu kolejne pytanie: do jakiego stopnia należy dzielić aplikację wzorcową na moduły i funkcjonalności? Co będzie stanowiło funkcjonalność atomową przyjętą jako podstawową i niepodzielną? Chcąc odpowiedzieć na te pytania należy oprzeć się na wiedzy eksperta, posiadającego doświadczenie w dziedzinie wytwarzania oprogramowania. Na podstawie jego wiedzy
34 Kamil Dowgielewicz, Cezary Orłowski powinno określić się funkcjonalności atomowe, które dzielą ogólne funkcjonalności na mniejsze, dokładniejsze, bardziej szczegółowe, co pozwoli na optymalne dopasowanie narzędzia do wymagań stawianych przez klientów. Obecnie na potrzeby budowy modelu autorzy uzupełnili bazę wiedzy ogólnymi funkcjonalnościami, które są wykorzystywane w procesie wytwarzania oprogramowania. Możemy do nich zaliczyć: przegląd statusu projektu jego zadań, automatyzacja testów, tworzenie harmonogramów, planów testowania, itp. Baza wiedzy oprócz funkcjonalności pochodzących z aplikacji wzorcowej powinna zawierać zbiór dostępnych na rynku aplikacji Open Source. Pozwoli to na ukazanie, która z nich zawiera niezbędne funkcjonalności i sprosta stawianym wymaganiom. Uzupełnieniem bazy wiedzy w.w. elementami może być opcjonalne, jeżeli efektem działania modelu ma być zbiór funkcjonalności bez wskazywania narzędzi ich zawierających. Można tak zrobić, gdy naszym celem jest wyznaczenie kierunku rozbudowy aktualnie stosowanego narzędzia, a nie wskazanie gotowych narzędzi posiadających wszystkie funkcjonalności niezbędne do spełnienia wyznaczonych wymagań, wówczas zbiór aplikacji Open Source może zostać pominięty. Na etapie koncepcji projektu pominięto sposób opisu jakościowego zarówno narzędzia wzorcowego jak i danych wejściowych. Opis jakościowy elementów bazy wiedzy i danych wejściowych będzie dalszym celem badań. 2.2. Koncepcja parametrów wejściowych i wyjściowych modelu referencyjnego Podstawą sprawnego działania modelu jest zdefiniowanie jego parametrów wejściowych i wyjściowych. Posiadając wiedzę na temat tych parametrów można definiować proces doboru funkcjonalności (narzędzi). Najważniejszym parametrem wejściowym dla modelu referencyjnego będzie obecnie stosowane narzędzie (lub zbiór narzędzi) typu Open Source, które mają zostać poddane procesowi analizy i ewentualnemu rozwojowi. Jak zatem model referencyjny ma wskazać kierunek modyfikacji wykorzystywanego przez firmę narzędzia Open Source? Powraca wspomniany wcześniej opis jakościowy funkcjonalności atomowych. Aby możliwe było poddanie narzędzia analizie, należy wyodrębnić funkcjonalności atomowe i poddać je analizie jakościowej. Funkcjonalności stosowanego narzędzia muszą być porównane z funkcjonalnościami atomowymi pochodzącymi z bazy wiedzy. Proces jakościowego opisu funkcjonalności i wymagań musi opierać się na rozmywaniu wartości i przypisywaniu poszczególnym funkcjonalnością wag (zbioru wag), która będzie jednoznacznie oceniała daną funkcjonalność w stosunku do funkcjonalności atomowych. Dzięki takiemu podejściu możliwa stanie się ocena w jakim stopniu funkcjonalność z narzędzia wejściowego odpowiada funkcjonalność z bazy wiedzy. Pozostałe dane wejściowe jak np. stawiane wygania, muszą zostać poddane analogicznemu procesowi opisu jakościowego w stosunku co do elementów z bazy wiedzy, aby możliwe stało się ich dalsze wykorzystanie.
Koncepcja modelu referencyjnego dla rozwoju technologii Open Source 35 Wstępna koncepcja modelu nie precyzuje ostatecznie wszystkich parametrów wejściowych. Można jedynie określić te niezbędne. Należą do nich: wymagania stawiane wytwarzanemu oprogramowaniu (wymagania funkcjonalne), dostępne zasoby ludzkie i finansowe firmy wytwarzającej oprogramowanie, zasoby sprzętowe (laboratorium), kryteria jakościowe, wykorzystywana metodologia i inne. Parametrem wyjściowym modelu będzie zbiór funkcjonalności, spełniający podane wymagania. Zbiór ten można w analogiczny sposób poddać ponownie procesowi opisanemu w modelu referencyjnym, a efektem wówczas będzie lista posortowanych narzędzi Open Source, posiadających funkcjonalności, które stanowią wynik poprzedniego procesu. 2.3. Zasada działania modelu referencyjnego Zasada działania modelu referencyjnego opiera się na analizie i porównywaniu danych wejściowych, danych z bazy wiedzy, regułach zawartych w bazie reguł i maszynie wnioskującej. Maszyna wnioskująca operuje na danych, które zostały wcześniej poddane opisowi jakościowemu, w czasie którego określono w jakim stopniu dana funkcjonalność odpowiada parametrowi z bazy wiedzy. Element wnioskujący porównuje i zwraca wartości, które odpowiadają danym zawartych w bazie wiedzy i odpowiednim regułom z bazy reguł. Reguły porównują dane wejściowe z danymi z bazy wiedzy. Wspomniany opis jakościowy pozwala na przyporządkowanie danym wejściowym funkcji przynależności w stosunku do danych z bazy wiedzy. Wynik działania maszyny wnioskującej jest porównywany z oczekiwanym rezultatem. Jeżeli wynik działania iteracji nie spełnia oczekiwań, rozpoczyna się kolejna iteracja, która ostatecznie kończy się wskazaniem zbioru funkcjonalności spełniających dane wymagania, bądź zbiorem narzedzi Open Source oferujących dane funkcjonalności. Przedstawiony proces działania modelu jest na tym etapie badań stosunkowo uproszczony i stanowi koncepcję dalszych prac rozwojowych. 3. Kierunki dalszych badań Przedstawiona koncepcja modelu referencyjnego zawiera elementy takie jak opis jakościowy, komparator, baza reguł, algorytm decyzyjny, które będą rozwijane w dalszej kolejności. Pierwszy etap badań opisuje samą koncepcję działania modelu oraz podstawową strukturę. Kolejnym etapem badań nad modelem referencyjnym będzie zdefiniowanie danych wejściowych. Możliwe to będzie dzięki wiedzy eksperta i zdobytym doświadczeniu w dziedzinie wytwarzania i testowania aplikacji. Opisana w rozdziale 3 koncepcja bazy wiedzy musi zostać rozszerzona o sposób implementacji takiej wiedzy przy wykorzystaniu dostępnych technologii. Autorzy przewidują stworzenie bazy wiedzy na podstawie dostępnych narzędzi oraz dzięki wiedzy eksperckiej. Najistotniejszym elementem kolejnego etapu będzie wstępne opracowanie metody opisu jakościowego wszystkich parametrów modelu, a w szczególności bazy wiedzy i parametrów wejściowych. Opis jakościowy musi być ściśle powiązany z elementami bazy wiedzy, a zatem możliwy do modyfikacji. Autorzy muszą przeanalizować meto-
36 Kamil Dowgielewicz, Cezary Orłowski dy opisu jakościowego narzędzia, a w szczególności ich elementów składowych (funkcjonaliści). Można zauważyć, że opracowanie metody opisu jakościowego będzie bardzo zbliżone, a nawet będzie w ścisłym powiązaniu z modelem kosztowym opisu oprogramowania. Autorzy chcą stworzyć moduł opisu jakościowego modelu referencyjnego wspomagającego wybór narzedzia do wytwarzania oprogramowania. Moduł modelu referencyjnego może posłużyć również w innym kierunku badania procesów wytwarzania oprogramowania, jakim jest szacowanie kosztów budowy aplikacji. Proces szacowania kosztów wytwarzania oprogramowania jest tematem otwartym w dziedzinie IT. Dalszym celem prac nad modelem referencyjnym będzie zdefiniowanie i opracowanie bazy reguł. Baza reguł będzie musiała być modyfikowalna. W związku z przyjętą koncepcją działania modelu referencyjnego, autorzy przewidują zastosowanie technologii ekspertowej przy tworzeniu bazy reguł. Koncepcja modelu przedstawia wykorzystanie sprzężenia zwrotnego podczas kolejnej iteracji działania modelu. Oczywistym jest, że uzyskane parametry na wyjściu będą znacząco wpływały na bazę reguł i stąd potrzeba możliwości modyfikacji używanych reguł. System ekspertowy umożliwia dobieranie zestawu reguł opracowanych na podstawie wiedzy eksperta do zmieniających się danych. Prace badawcze nad modelem muszą uwzględniać również analizę dostępnych technologii, w których może być wykonany model lub przetestowana procedura działania modelu. Zastosowanie odpowiedniej technologii będzie miało znaczenie priorytetowe. Należy przy tym pamiętać, że model ma przede wszystkim odzwierciedlać procedurę doboru narzędzi wspomagających proces wytwarzania oprogramowania. Zatem autorzy muszą uwzględnić możliwość zbudowania działającego modelu w różnych technologiach. Autorzy rozpoznali z problemem modernizacji Open Source w stosunku zmieniających się wymagań. Zapoznali się z strukturą narzędzia RQM oraz opracowali koncepcję bazy wiedzy opartej na tym narzędziu. Wynikiem analizy optymalnego procesu rozwoju narzędzi Open Source jest powstanie przedstawionego w artykule modelu. 4. Wnioski W artykule przedstawiono koncepcję modelu referencyjnego wspomagającego rozwój narzędzi Open Source wykorzystywanych przy proces wytwarzania, a w szczególności testowania oprogramowania. Na wstępie omówiono problematykę rozwoju narzędzi Open Source. Następnie przedstawiono koncepcję doboru funkcjonalności (narzędzi) do aktualnych wymogów klienta oraz koncepcję modelu referencyjnego. W kolejnym rozdziale przedstawiono jeden z głównych elementów modelu referencyjnego jakim jest baza wiedzy, która opiera się na komercyjnym i zaawansowanym rozwiązaniu IBM Rational Quality Manager. W dalszej części artykułu omówiono parametry wejściowe i wyjściowe modelu oraz ich wpływ na działanie modelu. Następnie przedstawiono proces działania modelu. Dalsza część artykułu opisuje kierunek dalszych prac badawczych nad modelem referencyjnym.
Koncepcja modelu referencyjnego dla rozwoju technologii Open Source 37 Podczas prowadzenia badań pojawiały się następujące uwagi i spostrzeżenia: Korzystna dla budowy modelu staje się znajomość prostych technologii do wytwarzania, a w szczególności testowania aplikacji i możliwości przełożenia ich funkcjonalności na złożone środowisko RQM. Opracowanie modelu działania RQM może okazać się kluczowe dla budowy generycznego modelu usługowego środowiska do testowania aplikacji. Może to jednak mieć miejsce tylko w przypadku próby integracji znanych środowisk, innych istniejących, a opisywanych w literaturze. Najistotniejsza dla budowy modelu jest przede wszystkim dogłębna analiza RQM. Literatura 1. Bell M.: Introduction to Service-Oriented Modeling. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons, 2008. 2. Hochstein A.: ITIL as common practice reference model for IT service management: formal assessment and implications for practice, e-technology, e-commerce and e- Service, 2005. EEE '05. Proceedings. The 2005 IEEE International Conference on, April 2005. 3. Scholer, S.: CobiT and the Sarbanes-Oxley Act: The SOX Guide for SAP Operations, SAP PRESS/GALILEO PRESS, 2007. 4. Myers G.J.: The Art of Software Testing, 2nd ed., John Wiley & Sons Inc., New York 2004. 5. Raynard B.: TOGAF The Open Group Architecture Framework 100 Success Secrets - 100 Most Asked Questions: The Missing TOGAF Guide on How to Achieve and Then Sustain Superior Enterprise Architecture Execution, Emereo Publishing, 2008. Streszczenie Artykuł przedstawia koncepcję modelu referencyjnego wspomagającego rozwój narzędzi Open Source wykorzystywanych w procesie wytwarzania oprogramowania. Struktura modelu opiera się na narzędziu IBM Rational Quality Manaer, które jest aktualnie najbardziej zaawansowanym narzędziem wspomagającym proces wytwarzania, a w szczególności testowania aplikacji. W artykule zaprezentowano opis narzędzia wzorcowego, który stanowi bazę wiedzy dla maszyny wnioskującej modelu oraz opisano proces doboru wymaganych funkcjonalności, w stosunku do wykorzystywanej aplikacji Open Source oraz wymagań klienta, co w efekcie przekształca się na rozbudowę istniejących rozwiązań lub wybór nowych narzędzi.
38 Kamil Dowgielewicz, Cezary Orłowski The concept of reference model supporting Open Source development tools based on IBM Rational Quality Manager Summary This paper presents the concept of the reference model supporting expansion of open source tools used in the software development process. The structure of the model is based on the IBM Rational Quality Manager tool, which is currently the most advanced tool supporting the production, especially application testing. Description of the pattern model was presented in the article. It determines knowledge base for the inference machine and describes the process of selecting the required functionality for Open Source software application and customer requirements, which in turn is converted to the expansion of existing solutions or selection of new tools.