ZARZĄDZANIE WIEDZĄ I TECHNOLOGIAMI INFORMATYCZNYMI Pod redakcją C. Orłowskiego, Z. Kowalczuka, E. Szczerbickiego 2009 PWNT Gdańsk ROZDZIAŁ 5 Cytowanie niniejszej pracy: Czarnecki A.: Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego. [W:] Orłowski C., Kowalczuk Z., Szczerbicki E. (red.): Zarządzanie wiedzą i technologiami informatycznymi, Pomorskie Wydawnictwo Naukowo-Techniczne, Gdańsk 2009, s. 179 188 5.WYKORZYSTANIE ONTOLOGII PRZY OCENIE ZŁOŻONOŚCI PROJEKTU INFORMATYCZNEGO Adam CZARNECKI 1. Wprowadzenie W Zakładzie Zarządzania Technologiami Informatycznymi na Wydziale Zarządzania i Ekonomii Politechniki Gdańskiej opracowywany jest system do oceny technologii informatycznych. Ma on korzystać z narzędzi sztucznej inteligencji, takich jak systemy ekspertowe oraz sztuczne sieci neuronowe, a także z ontologii. Elementy te spinać ma architektura agentowa. Celem działania proponowanego systemu ma być z jednej strony gromadzenie wiedzy o technologiach informatycznych, zdobywanej głównie od ekspertów, a z drugiej udostępnianie tej wiedzy osobom zainteresowanym danymi technologiami, głównie na potrzeby doboru właściwych metod zarządzania przedsięwzięciami informatycznymi i usług oferowanych przez wspierające je narzędzia. Rozwiązanie, częściowo zaimplementowane w środowisku testowym VBA (ang. Visual Basic for Applications), zostało wstępnie zweryfikowane dla danych z systemu technicznego [2][8][9]. W tym rozdziale zamieszczono opis wykorzystania ontologii dla dziedziny oceny złożoności projektu informatycznego jako kolejnego przypadku służącego weryfikacji całego modelu. W rozdziale mimo świadomości co do różnic znaczeń zamiennie stosowane są pojęcia przedsięwzięcie i projekt z uwagi na to, że w przywoływanej literaturze słowa te traktowane bywają często jako synonimy. 2. Schemat funkcjonowania systemu W toku prac nad systemem opracowano schemat jego funkcjonowania z perspektywy przepływu danych między aktorami i modułami (rys. 1) [2, s. 204]. Ogólnie, sesja użytkownika zainteresowanego uzyskaniem wiedzy z systemu (klienta) polega na wprowadzaniu zapytania, przy czym agent pośredniczący odpowiada za interfejs użytkownika, a zadaniem ontologii jest zapewnienie poprawności zapytania (kroki 1 5 na rys. 1). Zapytanie trafia do agenta menedżera (6), który decyduje o miejscu wysłania zapytania. W przypadku przeszukania baz wiedzy komunikat trafia do agenta szukającego (7). Agent ten wybiera Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, e-mail: adam.czarnecki@zie.pg.gda.pl.
180 A. Czarnecki wyspecjalizowany program, który poszukiwać będzie odpowiedzi czy to w bazie reguł, faktów obiektywnych, czy bazie faktów subiektywnych (8 9). Wynik poszukiwań przekazywany jest poprzez agenty do użytkownika (10 16). W trakcie tych działań następuje sprawdzenie formalnej poprawności uzyskanej odpowiedzi przez ontologię. Rys. 1. Proponowany schemat przepływu danych w systemie wspomagania decyzji.
5. Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego 181 Powyższy opis celowo pomija użycie bardziej złożonego modelu ocenowego oraz sesję eksperta z systemem. Są to osobne zagadnienia, na których rozwinięcie nie ma w tym rozdziale miejsca. 3. Domena ontologii Docelowo system ma być wykorzystywany jako pomoc dla menedżera przedsięwzięcia informatycznego przy doborze narzędzi wspomagających zarządzanie [7]. Będzie on zasilany wiedzą na temat dojrzałości zespołu wytwórczego (opartej na modelu CMMI), dojrzałości klienta (jego odpowiedniości i dopasowaniu) oraz złożoności projektu. Przy tym za przykład projektu posłuży proces wytwarzania architektury korporacyjnej według standardu TOGAF (ang. The Open Group Architecture Framework) [4]. Na potrzeby opisywanej w niniejszym rozdziale weryfikacji modelu systemu, w tym mającej się w nim znaleźć ontologii, zdecydowano się ograniczyć zakres systemu jedynie do czynności związanych z szacowaniem złożoności projektu, traktując na razie ten parametr jako wynik oszacowań wartości zmiennych takich jak obszary wytwarzania i zarządzania projektem, stan przygotowania dokumentacji projektu oraz fazy wytwarzania architektury korporacyjnej. Identyfikacja tych zmiennych dokonana została przez eksperta [7]. 3.1 Złożoność projektu Złożoność projektu można mierzyć w oparciu o jedną z ilościowych technik szacowania wielkości przedsięwzięcia informatycznego z grupy metod dekompozycyjnych lub empirycznych [3, s. 115 124]. W podejściu zaprezentowanym w [7] jako złożoność projektu rozumie się miarę osiągnięcia pewnych formalnych etapów wpływających na jakość wytwarzanego oprogramowania. Do opisania gradacji złożoności projektu przyjęto podział stosowany w modelu COCOMO [6, s. 41]: przedsięwzięcia organiczne (ang. organic projects), w których uczestniczy stosunkowo mały zespół, dziedzina jest dość dobrze znana, podobnie jak metody i narzędzia, przedsięwzięcia półoderwane (ang. semi-detached projects), w których członkowie zespołu różnią się doświadczeniem, a dziedzina oraz metody i narzędzia nie są do końca rozpoznane, przedsięwzięcia osadzone (ang. embedded projects), które polegają na wytworzeniu systemów o bardzo złożonych wymaganiach, gdzie zespół w większości nie ma doświadczenia w wytwarzaniu podobnego oprogramowania, a tym samym dziedzina problemu oraz możliwe do zastosowania metody i narzędzia nie są zbytnio poznane. Te trzy kategorie przedsięwzięć określają zbiór wartości, jakie może przyjąć parametr nazwany złożonością projektu. Model COCOMO zawiera sposoby szacowania nakładów pracy, czasu oraz liczby osób potrzebnych przy realizacji przedsięwzięcia w oparciu o liczbę instrukcji w wykorzystanym kodzie źródłowym (KDSI, ang. thousand of delivered source code instructions). Jakkolwiek jest to miara obiektywna, to jednak dla różnych zespołów obserwowane są znaczące różnice w wydajności przy tej samej objętości kodu [6, s. 44]. Dopiero dostrojenie algorytmu COCOMO do konkretnej organizacji pozwala na w miarę rzetelne szacowanie potrzebnych nakładów. W kolejnych punktach zaprezentowano inne parametry, które według [7] mogą posłużyć do pomiaru złożoności projektu. 3.2 Obszary wytwarzania i zarządzania Przedstawiając typy przedsięwzięć według modelu COCOMO scharakteryzowano je między innymi pod kątem umiejętności wykorzystywania metod i narzędzi, czyli stosowania określonej
182 A. Czarnecki technologii. Poszerzając zakres know-how o dobre praktyki i procesy oraz przyjmując, że realizacja przedsięwzięcia informatycznego to biegnące równolegle czynności wytwarzania oprogramowania oraz zarządzania tym przedsięwzięciem, możemy wyróżnić następujące obszary: technologie wytwarzania, dobre praktyki wytwarzania, procesy wytwarzania, dobre praktyki w zarządzaniu, procesy zarządzania, technologie zarządzania. Według [7] takie ułożenie pokazuje, że ceteris paribus w przypadku stosowania jedynie technologii wytwarzania złożoność projektu bliższa jest kategorii osadzonej, natomiast sięgnięcie po technologie zarządzania ma wskazywać na przedsięwzięcie organiczne. Można dyskutować, czy takie podejście, gdzie pokazana kolejność jednocześnie oznacza przechodzenie od przedsięwzięć osadzonych, poprzez półoderwane do organicznych jest zawsze uzasadniona. Dla uproszczenia rozpatrywanego modelu przyjmuje się jednak taką właśnie sekwencję. 3.3 Dokumentacja Kolejną zmienną wpływającą na ocenę złożoności projektu jest stan przygotowania dokumentacji. Świadczy on zarówno o zaawansowaniu projektu, jak też pośrednio o jakości zarządzania. Dokumenty dzieli się często na dwie kategorie [6, s. 247 251][10, s. 370 375]: zarządcze (procesu), specjalistyczne (techniczne). Taki podział można spotkać między innymi w metodyce PRINCE 2, gdzie dodatkowo w dokumentacji zarządczej wyróżnia się teczkę projektu, teczkę jakości oraz teczkę dla każdego z etapów, a w ramach każdej z teczek określone klasy dokumentów. W proponowanym w niniejszym rozdziale podejściu kluczem do wydzielenia typów dokumentacji są fazy realizacji przedsięwzięcia zgodnie z modelem zaproponowanym w [7]. Będzie to zatem w kolejności: dokumentacja wstępna, dokumentacja wejściowa, dokumentacja weryfikacji, dokumentacja przekazania. Chcąc scharakteryzować wpływ tej zmiennej na złożoność projektu, należy przyjąć, że wraz z przechodzeniem do dokumentów specyficznych dla kolejnych faz projektu złożoność projektu maleje, tj. zmienia się od osadzonego do organicznego. Zasadne jest pytanie, co w przypadku, gdy powstały dokumenty przekazania, a brakuje dokumentacji wstępnej. Tu także stosujemy na razie uproszczenie, że przedsięwzięcie realizowane jest zgodnie z opisaną sekwencją wytwarzania dokumentacji i niemożliwe jest pominięcie żadnego etapu. 3.4 Architektura korporacyjna Trzecią zmienną wpływającą na ocenę złożoności projektu jest, według eksperta [7], etap tworzenia architektury korporacyjnej, utożsamiany z realizacją przedsięwzięcia informatycznego. W proponowanym modelu przyjęto podejście zgodne z metodą ramową TOGAF wspomagającą projektowanie, budowanie i ocenę architektury organizacyjnej. Oznacza to, że przy realizacji
5. Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego 183 przedsięwzięcia wyróżnia się następujące po sobie kolejno fazy konstruowania architektury korporacyjnej. Są to: wizja architektury (ang. architecture vision) służy określeniu zakresu przedsięwzięcia, odpowiada zarządczej funkcji planowania, architektura biznesowa (ang. business architecture) tu tworzona jest ogólna koncepcja mającego powstać systemu informatycznego, architektura systemów informatycznych (ang. applications architecture) na tym etapie tworzony jest logiczny model systemu, architektura technologii (ang. technology architecture) produktem tej fazy jest model obrazujący, jak wyglądać będzie fizyczna realizacja architektury w systemie. Oddziaływanie tej zmiennej na wynikową złożoność projektu jest następujący: na im wcześniejszej fazie znajduje się wytwarzanie architektury korporacyjnej, tym bliżej projektowi do kategorii przedsięwzięć osadzonych. Osiągnięcie etapu architektury technologii zbliża projekt do przedsięwzięć organicznych. Wsparciem dla metody TOFAG przy opisywaniu domeny wytwarzania architektury korporacyjnej może być siatka Zachmana [5], która m.in. dzieli fazy na piony związane z danymi, funkcjami systemu, połączeniami, zespołem, czasem i motywami działań. Podobnie jak przy wcześniej opisanych zmiennych, tu także zakłada się pewne uproszczenie dziedziny. Pomija się choćby obszar repozytorium gromadzącego wzorce architektur (ang. The Architecture Continuum): generycznych, wspólnych systemów, przemysłu i przedsiębiorstwa. 3.5 Postać macierzowa złożoności projektu Po ogólnym scharakteryzowaniu dziedziny, jaką jest złożoność przedsięwzięcia informatycznego, w tym decydujących o jej wartościach zmiennych, można przedstawić złożoność projektu jako wektor opisany macierzą: gdzie: ZPt oznacza złożoność projektu w chwili t, ot stan obszarów wytwarzania i zarządzania w chwili t, dt stan dokumentacji w chwili t, at stan wytworzenia architektury korporacyjnej w chwili t. ot ZP t d t, (1) a t Ponieważ ocena złożoności projektu ma się odbywać w oparciu o przetwarzanie rozmyte w regułowym systemie ekspertowym, dla każdej zmiennej przyjmuje się poza wartościami lingwistycznymi zbiór wartości ostrych. W uproszczonym modelu będzie miał on charakter binarny, oznaczający na przykład, że w obszarze wytwarzania stosuje się dobre praktyki lub też nie. W przyszłości, w bardziej złożonej postaci, dany będzie zakres [0..100] obrazujący stopień spełnienia oczekiwań wobec stanu najbardziej pożądanego ze względu na możliwość osiągnięcia złożoności projektu na poziomie organicznym. Mierząc stany dla czasu t = 1, a następnie t = 2 (przy czym te liczby traktujemy jako chronologiczne indeksy, a nie jako równe interwały czasowe), możemy uzyskać wektor zmiany złożoności projektu:
184 A. Czarnecki o1,2 ZP 1,2 d1,2. (2) a 1,2 Oczekuje się, że proces realizacji przedsięwzięcia będzie prowadził do zmniejszenia jego złożoności, tj. odnotowywane będą dodatnie przyrosty wartości stanów dla każdej ze zmiennych. 4. Przypadki użycia ontologii Niezależnie od wybranej domeny, zakładane najważniejsze przypadki użycia ontologii w opisanym na początku systemie pozostają takie same. System Klient Zadaj pytanie kompetencyjne Zwróć odpowiedź <<include>> <<include>> Ontologia Zweryfikuj poprawność Inżynier wiedzy <<include>> Wprowadź wiedzę Ekspert Rys. 2. Przypadki użycia ontologii w systemie. Jak pokazano na diagramie przypadków użycia ontologii (rys. 2), jej funkcjonalność nie jest bezpośrednio udostępniana użytkownikowi. Nie jest to konieczne, albowiem ontologia stanowi element wewnętrznego mechanizmu kontroli poprawności danych, informacji czy wiedzy, jakie do systemu dopływają i jakie z niego są przekazywane na zewnątrz. Ontologia jest używana przez agenty na etapie: 1. wprowadzania zapytania przez użytkownika, 2. zwracania użytkownikowi odpowiedzi na zadane pytanie, 3. zasilania systemu wiedzą przez eksperta lub inżyniera wiedzy. Wymienione przypadki użycia ontologii mogą zostać rozszerzone w sytuacji rozbudowy systemu o mechanizmy przetwarzania wstępnego (pre-processing na rys. 1) oraz wprzęgnięcia do metod wnioskowania obok systemu ekspertowego sztucznych sieci neuronowych. Aby zweryfikować, na ile podane wyżej przypadki użycia wyczerpują konieczność i możliwości zastosowania ontologii w systemie, uzasadnione są eksperymenty ukazujące sesje
5. Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego 185 z systemem użytkownika, który wciela się w poszczególne role. Opis przykładowych eksperymentów Czytelnik znajdzie w [1] i [2]. 5. Struktura ontologii Ze względu na zakres obejmowanych pojęć wyróżnia się dwa główne typy ontologii: ogólną (ang. upper ontology, top-level ontology lub foundation ontology) i dziedzinową (ang. domain ontology). W opisywanym w niniejszym rozdziale przypadku wykorzystania ontologii w systemie do oceny technologii informatycznych mamy do czynienia z tym drugim typem. Dziedziną całego systemu, jak wcześniej wspomniano, są technologie informatyczne, ze szczególnym uwzględnieniem parametrów decydujących o doborze metod i narzędzi zarządzania przedsięwzięciami z zakresu IT. Na potrzeby obecnej fazy badań założono też, że z całego tego obszaru wiedzy wydzielony zostanie fragment poświęcony ocenie złożoności projektu. Toteż opracowana dla celu weryfikacji modelu struktura ontologii skupi się na kategoryzacji i hierarchizacji pojęć związanych ze złożonością projektu, obszarami wytwarzania i zarządzania, dokumentacją oraz architekturą korporacyjną w zakresie, jaki konieczny jest do funkcjonowania całego systemu agentowego. 5.1 Opis semantyczny zmiennych Taksonomię pojęć przedstawiono na rys. 3. Jak widać, zawiera ona wszystkie pojęcia scharakteryzowane wcześniej w punkcie poświęconym domenie ontologii. Rys. 3. Taksonomia pojęć w ontologii. W centrum znajduje się klasa systemowa owl:thing charakterystyczna dla ontologii tworzonych w języku OWL (ang. Web Ontology Language). Linie określają relację klasapodklasa. Łączą one konkretne zmienne ze szczegółowymi pojęciami wiązanymi ze zbiorem wartości tych zmiennych. Ponieważ jednak zdecydowano się trzy główne zmienne umieścić na tym samym poziomie hierarchii, co parametr od nich zależny, stworzona została dodatkowa relacja nazwana jest_zmienną_dla. Skierowana jest ona od pojęć Obszar, Dokumentacja oraz Architektura_korporacyjna ku klasie Złożoność_projektu. Relację tę przedstawiono wyraźnie na rys. 4. Semantyka wskazująca na to, które pojęcia się wejściowe, a które wyjściowe dla modelu oceny złożoności projektu jest kluczowa, albowiem wartości zmiennych opisanych przez te
186 A. Czarnecki pojęcia wykorzystywane są w głównych modułach wnioskujących, czyli systemie ekspertowym i sztucznej sieci neuronowej, a także w przetwarzaniu wstępnym, gdzie dane mogą trafić do narzędzia analiz statystycznych. Rys. 4. Relacja wskazująca na zmienne parametru złożoności projektu. Rys. 5. Semantyka zmiennej dotyczącej obszarów wytwarzania i zarządzania. Dodatkową semantykę zastosowano dla zmiennej dotyczącej obszarów wytwarzania i zarządzania. Jako że zarówno dla wytwarzania, jak i zarządzania wyróżnia się bardziej szczegółowe podobszary, to jest: technologie, dobre praktyki i procesy, to te trzy pojęcia zdefiniowano tylko raz jako równorzędne wytwarzaniu i zarządzaniu podklasy zmiennej Obszar. Następnie zaś utworzono własność o nazwie stosuje_się_przy, którą połączono wszystkie trzy
5. Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego 187 podobszary z każdym z dwóch obszarów głównych. Uznano też, że przydatne będzie utworzenie własności odwrotnej nazwanej wykorzystuje. Te zależności semantyczne pokazano na rys. 5. 5.2 Wartości zmiennych i ograniczenia Środowiskiem weryfikacji wykorzystania ontologii poprzedzającym badania nad złożonością projektu był system techniczny do pomiaru i predykcji stężeń substancji BTEX w atmosferze. Wprowadzane wówczas do systemu dane chemiczne i meteorologiczne były wartościami liczbowymi rzeczywistymi o charakterze ciągłym, mieszczącymi się w pewnych przedziałach wynikających czy to z definicji mierzonej wielkości (wartości procentowe stężeń mogły przyjmować jedynie wartości od 0 do 100), czy z długoterminowej obserwacji (np. nie zanotowano nigdy temperatury powietrza 40 C). Dla zmiennych opisujących złożoność projektu należy także zastanowić się nad charakterem mierzonych wartości. Docelowo każdy z wymiarów branych pod uwagę przy ocenie złożoności projektu w tym sama wartość ostra opisująca tę złożoność ma być oceniany w skali procentowej wskazującej na spełnienie wymagań. Zbiór wartości stanowiłyby więc liczby rzeczywiste z przedziału [0..100]. Być może dla wybranych zmiennych dolna granica przedziału zostałaby podniesiona, np. do wartości 5, choćby dlatego, że trudno wyobrazić sobie realizację przedsięwzięcia informatycznego, w którym technologie wytwarzania ocenione są na 0%. Wartości liczbowe zmiennych stanowiłyby wejście do rozmytego systemu ekspertowego, gdzie ulegałyby fuzyfikacji, natomiast zbiór wartości funkcji opisującej złożoność projektu wykorzystywany byłby podczas wyostrzania wyniku działania tego systemu. Skoro mowa jest o procentowym stopniu spełnienia jakiegoś wymagania, rodzi się pytanie o model ocenowy, który pozwoliłby na przyporządkowanie określonemu stanowi zmiennej wartości liczbowej. Na obecnym etapie badań zespołu taki model nie powstał, stąd na razie zastosowano kolejne uproszczenie funkcjonowania systemu, gdzie każda ze zmiennych przyjmuje jedynie wartości binarne: 0 lub 1 na oznaczenie spełnienia danego parametru. W trakcie badań zwrócono również uwagę na pewne współzależności pomiędzy zmiennymi. Przykładowo, wydaje się, że stosowanie określonych procedur zarządzania wpływa na czynności dokumentowania projektu. Dodatkowo, postęp przedsięwzięcia objawiający się przechodzeniem do kolejnych faz tworzenia architektury korporacyjnej też powinien powodować przyrosty w kolejnych klasach dokumentacji. Takie relacje pomiędzy zmiennymi mogą powodować trudności w uzyskaniu dokładnego modelu. Potrzeba jednak pewnej ilości danych na temat zrealizowanych przedsięwzięć, by móc ocenić wpływ wskazanego tu zjawiska. 5.3 Słownik Weryfikując założenia systemu dla wspominanych już danych technicznych, stworzono w ontologii słownik, który przekładał czytelne dla użytkownika korzystającego z systemu pojęcia związane z wyszukiwaniem danych na operatory matematyczne specyficzne dla składni języka w module realizującym przeszukiwanie [2, s. 207]. Celem tej ontologii było więc usprawnienie interakcji człowieka z komputerem (HCI, ang. Human-Computer Interaction). Na bieżącym etapie prac nad systemem do oceny złożoności projektu nie zidentyfikowano jeszcze obszarów, które należałoby wspomagać w podobny sposób. Warto jednak pamiętać o takiej możliwości, tym bardziej, że pokazuje ona rolę ontologii nie tylko na styku dwóch agentów programowych, ale także w obszarze HCI. 6. Podsumowanie W rozdziale zaprezentowano możliwości wykorzystania ontologii do oceny złożoności projektu informatycznego. Opis oparto na koncepcji opracowanej wcześniej dla szeroko rozumianej oceny
188 A. Czarnecki technologii informatycznych i zweryfikowanej dla danych z technicznego systemu pomiaru zanieczyszczeń. Liczne odniesienia do chemicznego systemu technicznego, jak i wskazywane w całym rozdziale ograniczenia nakładane na zakres i dogłębność rozpatrywania dziedziny złożoności projektów informatycznych w systemie społeczno-technicznym pokazują, że ten drugi typ systemu trudniej zamodelować. Nie jest to wniosek zaskakujący, jednak trudno go pominąć jako jeden z efektów prowadzonych badań. Dalsze prace nad tworzeniem ontologii powinny iść równolegle z rozwijaniem zagadnienia pomiaru zmiennych wykorzystywanych do oceny złożoności projektu. Chodzi tu zarówno o uszczegółowienie sposobu przyznawania rang procentowych stopniom spełnienia wymagań, jak i analizie zależności zmiennych i ewentualnych konsekwencji z takich zależności wynikających. Należy się też zastanowić nad tym, czy nie należy poszerzyć zastosowania ontologii w systemie na przykład na procesy wstępnego przetwarzania danych lub nie należy wydzielić osobnego modułu funkcjonalnego odpowiedzialnego za budowę zaufania do danych, którego ontologia będzie jedną z części składowych, jak ma to miejsce w koncepcji sieci semantycznych na potrzeby WWW. Gdy opisane wyżej kwestie zostaną rozstrzygnięte, nadejdzie czas na implementację całości systemu, co oznaczać będzie konieczność doboru odpowiednich technologii. Być może warto będzie potraktować to jako kolejne przedsięwzięcie informatyczne stanowiące studium przypadku mogące zasilić bazę wiedzy opisanego w rozdziale systemu. Bibliografia [1] Czarnecki A.: Model zarządzania ontologiami w środowisku oceny technologii informatycznych. Orłowski C., Kowalczuk Z., Szczerbicki E. (red.): Zarządzanie wiedzą i technologiami informatycznymi, ss. 413 422. Pomorskie Wydawnictwo Naukowo- Techniczne, Gdańsk 2008. [2] Czarnecki A., Orłowski C.: System do prognozowania zanieczyszczeń środowiskiem weryfikacji ontologii. Knosala R. (red.): Komputerowo Zintegrowane Zarządzanie, Tom 1, ss. 203 212. Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole 2009. [3] Flasiński M.: Zarządzanie projektami informatycznymi. Wydawnictwo Naukowe PWN, Warszawa 2006. [4] http: The Open Group Architecture Framework. http://www.togaf.info/, (10.03.2009). [5] http: The Zachman Framework. http://www.zachmaninternational.com/index.php/thezachman-framework, (10.03.2009). [6] Jaszkiewicz A.: Inżynieria oprogramowania. Helion, Gliwice 1997. [7] Orłowski C.: Semantyczna specyfikacja procesów ADM dla potrzeb doboru metod zarządzania przedsięwzięciami (książka w przygotowaniu). [8] Orłowski C., Ziółkowski A.: Weryfikacja agentów systemu agentowego do oceny technologii informatycznych. Knosala R. (red.): Komputerowo Zintegrowane Zarządzanie, Tom 2, ss. 263 273. Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole 2009. [9] Sitek T., Orłowski C.: Weryfikacja struktur baz wiedzy systemu agentowego do oceny technologii informatycznych. Knosala R. (red.): Komputerowo Zintegrowane Zarządzanie, Tom 2, ss. 399 408. Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, Opole 2009. [10] Waćkowski K., Chmielewski J.M.: Wspomaganie zarządzania projektami informatycznymi. Poradnik dla menedżerów. Helion, Gliwice 2007.
5. Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego 189 {Odrębna strona streszczeń i adresów} Zarządzanie wiedzą i technologiami informatycznymi A. Czarnecki* *Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, adam.czarnecki@zie.pg.gda.pl Rozdział 5. Wykorzystanie ontologii przy ocenie złożoności projektu informatycznego. Rozdział dotyczy systemu do oceny technologii informatycznych. System ten ma korzystać z narzędzi sztucznej inteligencji, takich jak systemy ekspertowe oraz sztuczne sieci neuronowe, a także z ontologii. Elementy te spinać ma architektura agentowa. Celem działania proponowanego systemu ma być z jednej strony gromadzenie wiedzy o technologiach informatycznych, zdobywanej głównie od ekspertów, a z drugiej udostępnianie tej wiedzy osobom zainteresowanym danymi technologiami, głównie na potrzeby doboru właściwych metod zarządzania przedsięwzięciami informatycznymi i usług oferowanych przez wspierające je narzędzia. Rozwiązanie zostało wstępnie zweryfikowane dla danych z systemu technicznego. W rozdziale zamieszczono opis wykorzystania ontologii we wspomnianym systemie dla dziedziny oceny złożoności projektu informatycznego jako kolejnego przypadku służącego weryfikacji całego modelu. Information Technology and Knowledge Management A. Czarnecki* *Gdańsk University of Technology, Faculty of Management and Economics, Department of Information Technology Management, adam.czarnecki@zie.pg.gda.pl Chapter 5. Ontology utilization for IT project complexity assessment. The chapter regards the multi-agent system for the IT assessment that encompasses AI tools such as expert systems and artificial neural networks. The text deals however with other prominent part of the system an ontology. The description deals with issue of assessing the complexity of the IT project as the outcome of parameters such as development and management areas, documentation and phases of the corporate architecture development. The goal of the research is to verify the model of ontology management.