OCENA METOD TWORZENIA ONTOLOGII W KONTEKSĆIE SZACOWANIA KOSZTÓW WDROŻENIA SYSTEMÓW ERP

PRZEMYSŁAW PLECKA przemek.plecka@gmail.com KRZYSZTOF BZDYRA krzysztof.bzdyra@tu.koszalin.pl Katedra Podstaw Informatyki i Zarządzania Politechnika Koszalińska OCENA METOD TWORZENIA ONTOLOGII W KONTEKSĆIE SZACOWANIA KOSZTÓW WDROŻENIA SYSTEMÓW ERP Streszczenie: W trakcie procesów sprzedaży systemów ERP okazuje się, że zbiór standardowej funkcjonalności musi być rozszerzony lub zmieniony (zmodyfikowany) zgodnie z wymaganiami klienta. Dostawcy stoją zatem przed problemem określenia kosztów dodatkowych prac. Jedna z metod szacowania kosztów oparta jest o ontologiczny model wiedzy o systemie informatycznym, kosztach wdrożenia i wymaganiach klienta. w artykule dokonano przeglądu znanych metod budowy ontologii w rezultacie zaproponowano wykorzystanie wybranych fragmentów metod na poszczególnych etapach tworzenia ontologii kosztów wdrożenia. 1. Wstęp Pierwsze systemy informatyczne klasy ERP (ang. Enterprise Resource Planning) dostępne były jedynie dla bardzo dużych przedsiębiorstw. Barierą w ich upowszechnianiu były wysokie koszty wdrożenia i utrzymania spowodowane tym, że producenci oprogramowania pierwsze systemy tworzyli na zamówienie konkretnych klientów. Zbierając doświadczenie ze współpracy z wieloma klientami, producenci wyodrębnili zbiór funkcjonalności, który powtarzał się najczęściej i utworzyli z niego wersję standardową swojego produktu. Koszty wytworzenia, wdrożenia i utrzymania zostały zmniejszone, do tego stopnia, że obecnie nawet średniej wielkości przedsiębiorstwa mogą sobie pozwolić na takie syste-

102 Przemysław Plecka, Krzysztof Bzdyra my [1]. Standaryzacja wiąże się jednak z tym, że istnieją grupy procesów w przedsiębiorstwie, którym nie odpowiada żadna funkcjonalność w standardowym systemie ERP. W odpowiedzi na takie wymaganie dostawcy rozszerzyli swoje oferty o przystosowanie (ang. customization) rozwiązań do specyficznych potrzeb użytkowników [2]. W efekcie, dla systemów wielodziedzinowych takich, jak ERP, trudno mówić o jednym standardowym rozwiązaniu. Mimo, że wejściowy system ERP jest standardowy (taki sam dla danego dostawcy), to po przystosowaniu i wdrożeniu, każde rozwiązanie końcowe jest inne, tak jak każde przedsiębiorstwo jest inne w zakresie organizacji procesów w nim zachodzących. Konieczność częstych zmian oprogramowania wymusza konieczność trafnej wyceny tychże zamian. Warto zauważyć, że po podpisaniu kontraktu przez dostawcę i klienta koszty prac, które nie zostaną wykazane w SLA (ang. Service Level Agreement) obciążą dostawcę obniżając rentowność przedsięwzięcia. Z drugiej natomiast strony zbyt wysoka wycena, która w założeniu ma pokryć wszelkie nieprzewidywane koszty, obniża konkurencyjność dostawcy. Znanych jest wiele metod pozwalających na wycenę przedsięwzięcia IT (ang. Information Technology) [3]. Stosowanie tych metod jest ograniczone ze względu na informacje o wymaganiach klienta, którymi dysponuje dostawca w poszczególnych fazach cyklu przygotowawczego (opisane w publikacjach Plecka i Bzdyra np. [4]). Właśnie ze względu na te uwarunkowania, metody szacowania kosztów można podzielić na: grupa 1 - metody wykorzystywane na etapie rozmów handlowych, kiedy dostawcy posiadają niepełne informacje, co do wymagań klienta, np.: indywidualna ocena eksperta, ocena grupy ekspertów, grupa 2 - metody wykorzystywane na etapie analizy wdrożeniowej, kiedy dostawcy posiadają pełną informację na temat wymagań klienta, np.: Analiza Punktów Funkcyjnych (ISO/IEC 20926:2009), Analiza Pełnych Punktów Funkcyjnych COSMIC (ISO/IEC 19761:2011), itp., grupa 3 - metody wykorzystywane na etapie projektu, kiedy oprócz wymagań klienta znane są składowe projektu, takie jak encje z relacjami, obiekty z metodami, interfejsy, itp., np.: metoda COCOMO. Mając na uwadze proces negocjacji kontraktu, dostawcom zależy na jak najdokładniejszej wycenie kosztów metodami z grupy 1. Aby pozyskać odpowiednie informacje do szacowanie, niektórzy autorzy (np. Plecka i Bzdyra [5]) proponują rozwiązania oparte na ontologii, rozumianej zarówno, jako baza wiedzy o SI (System Informatyczny), jak również o samym procesie wdrożenia (w tym działań związanych z modyfikacjami). Mimo, że rozwiązanie takie pozbawione jest ograniczeń, jakie posiadają inne metody wymiarowania, to popu-

Ocena metod tworzenia ontologii 103 larność jego jest znikoma. Przyczyn należy upatrywać w trudnościach przy tworzenia i konserwacji ontologii, chociaż w literaturze opisano szereg metod budowaniu ontologii [6, 7]. Celem niniejszej pracy jest przedstawienie sposobów budowania modeli ontologicznych oraz ich ocena w kontekście późniejszego wykorzystania w procesie szacowania oprogramowania. w rozważanym przypadku poszukiwana jest odpowiedź na pytanie, która z istniejących metod jest odpowiednia dla procesu tworzenia i utrzymywania bazy wiedzy o kosztach wdrożenia mając na uwadze koszty dostawcy systemu ERP. W pierwszym rozdziale scharakteryzowano proces budowania ontologii kosztów wdrożenia, określono jego specyficzne elementy i etapy tworzenia. Następnie zweryfikowano przydatność znanych metod uwzględniając warunki określone w poprzednim rozdziale i zaproponowano wykorzystanie rozwiązania składające się z fragmentów znanych metod. Takie podejście zilustrowano na przykładzie budowania ontologii kosztów systemu informatycznego i kosztów jego wdrożenia. w ostatnim rozdziale wskazano kierunki dalszych badań. 2. Ontologia - reprezentacja wiedzy o wymaganiach Skoro, jak wspomniano we wstępie, podstawą metod szacujących są dane o przedsiębiorstwie, to rozwiązaniem problemu dokładniejszego szacowania kosztów wdrożenia może być wspólna baza wiedzy o SI i przedsiębiorstwie, która będzie obejmowała: statyczny model oprogramowania (dane i ich relacje, np. w powiązane z kodem UML), dynamiczne modele obsługiwanych przez oprogramowanie procesów (np.: w powiązaniu z kodem BPEL), doświadczenia z wcześniejszych wdrożeń zapisane w dokumentacjach projektów (umowy, aneksy do umów, SLA, raporty, protokoły odbioru, inne dokumenty handlowe), historyczne informacje o poniesionych kosztach zmian w projektach (dokumenty finansowe, kadrowe, płacowe). Naturalnym wydaje się, zorganizowanie powyższych danych w struktury ontologii i na tej podstawie dokonywanie szacowań. Wykorzystanie ontologii do implementacji systemów informatycznych można coraz częściej znaleźć w literaturze [8]. Z powodu kompletności i spójności, zapis informacji w onto-

104 Przemysław Plecka, Krzysztof Bzdyra logii jest pełniejszy, niż w pozostałych sformalizowanych postaciach. Rozwiązania takie, pozbawione jest ograniczeń, jakie posiadają inne metody wymiarowania z grupy 1 - niepełne informacje o wymaganiach klienta. Przyczyny trudności w wykorzystaniu metody upatrywać należy w heterogeniczności informacji. Oznacza to, że przy budowaniu modelu ontologicznego należy korzystać z wielu źródeł informacji i wiedzy wielu specjalistów. Dodatkowo, każde kolejne wdrożenie systemu ERP będzie powodowało zmiany w modelu ontologicznym - zarówno w strukturze jak i w wartościach atrybutów opisujących elementy struktury. Budowanie modelu ontologicznego kosztów systemu ERP i jego wdrożenia, podzielne jest na pewne etapy, co wynika z charakterystyki procesu tworzenia. Zestawienie etapów przedstawiono w tabeli 1. Tab. 1. Etapy budowy ontologii kosztów wdrożenia Etap Zakres Komentarz 1.a 1.b Model statyczny systemu Model dynamiczny procesów 2 Model kosztów 3 Modyfikacja modeli o wymagania klienta Zawiera informacje o strukturach danych (tabele, pola) w ujęciu hierarchicznym. Pozwala w trakcie szacowania zmian odnieść się do mapy procesów biznesowych klienta. Nadanie wartości atrybutom kosztów na podstawie wcześniej zrealizowanych projektów. Zmiany modelu statycznego i dynamicznego związane z różnicami między oprogramowaniem standardowym a wymaganiami klienta. Należy zwrócić uwagę, że ontologia kosztów wdrożenia powstaje między innymi z gotowego systemu informatycznego. Proces konceptualizacji wiedzy nie będzie w tym wypadku występował. Koncepty zostały już utworzone w trakcie projektowania oprogramowania. Można natomiast wykorzystać struktury danych, na przykład diagramy ERD lub diagram klas w UML do automatycznego zasilenia ontologii - etap 1.a. I dalej, dołączyć procesy w postaci relacji między bytami(konceptami) - etap 1.b. W przypadku dostawców, którzy wykorzystują ontologię na etapie projektowania systemów informatycznych, wystarczy jedynie uaktualnić taką ontologię do postaci zgodnej z systemem gotowym. W jednym i drugim przypadku należy ręcznie zredukować znaczna część elementów ontologii nieistotnych z powodu szacowani kosztów wdrożenia. Kolejną cechą charakterystyczną jest określona i zamknięta lista atrybutów bytów i relacji, która wynika z ograniczonej liczby pytań, na które można odpowiedzieć wykorzystując wiedzę zawartą

Ocena metod tworzenia ontologii 105 w ontologii. Przykładem może być pytanie o koszt dodania struktur danych lub procesów. W konceptach lub relacjach musi wystąpić atrybut: koszt_dodania. Wszystkie koncepty i relacje, których dotyczy proces szacowania muszą mieć taką samą, kompletną listę atrybutów z przypisanymi do nich wartościami - etap 2. Ponieważ wymagania klienta ujawnianie są w trakcie sesji analitycznych z klientem, istotnym jest, aby uzupełnianie ontologie o tą wiedzę odbywało się równolegle z jej pozyskiwaniem - etap 3, co implikuje uproszczeniem procedur na tym etapie. Etapy tworzenia ontologii kosztów wdrożenia przedstawiono na rysunku 1. Rys. 1. Etapy budowania ontologii kosztów wdrożenia W związku powyższą specyfikacją budowania ontologii, można wyróżnić następujące kryteria oceny metod: dla etapu 1a: o K1 łatwość przenoszenia modeli opisanych diagramami (UML, ERD. itp.), dla etapu 1b: o K2 łatwość przenoszenia modeli opisanych diagramami i łączenia do istniejących obiektów (np.: z BPMN /BPEL ), dla etapu 2: o K3 możliwość automatyzacji zasilania wiedzą o kosztach, o K4 jednakowe atrybuty dla wszystkich elementów ontologii,

106 Przemysław Plecka, Krzysztof Bzdyra dla etapu 3: o K5 uproszczona procedura modyfikacji ontologii umożliwiająca realizacje etapu przez pracowników z podstawową wiedzą o ontologii, o K6 WSParcie informatyczne procesu pielęgnacji bazy wiedzy. 3. Sformułowanie problemu Dane jest przedsiębiorstwo wdrażające system informatyczny klasy ERP, który dostawca musi zmodyfikować uwzględniając zmiany wynikających ze specyficznej wymagań. Dostawca SI dysponuje modelami struktury SI, modelami procesów biznesowych, które są wspierane przez SI oraz danymi histerycznymi z wcześniejszych wdrożeń zapisanymi we własnych systemach wspomagających zarzadzanie projektami, kadrami, finansami itp. W celu usprawnienia procesu wyceny należy zbudować ontologię wzorcową i ontologię wymagań klienta. Poszukiwana jest odpowiedź na pytanie, które z pośród dostępnych metod budowania ontologii pozwalają realizować proces budowy bazy wiedzy w możliwie krótkim czasie i jednocześnie charakteryzują prostotą użycia. 4. Wybrane metody budowy ontologii W rozdziale zaprezentowano wybrane metody budowy ontologii w zakresie istotnym do budowania ontologii kosztów wdrożenia. Pełny opis metod zawarty jest w źródłach przytoczonych przy każdej metodzie lub literaturze przeglądowej na przykład Fernandez-Lopez [9] lub Gliński [10]. Niniejszy rozdział nie wyczerpuje listy znanych metod budowy ontologii. 4.1. Metoda CYC Metoda stworzona przez firmę Microelectronics and Computer Technology Corporation przy okazji tworzenia od 1984 roku bazy wiedzy Cyc [11]. Ontologia zbudowana była z ponad 1 mln twierdzeń w celu pozyskiwania wiedzy zdroworozsądkowej. Dotychczas metoda ta została zastosowana do zbudowania wyłącznie bazy wiedzy Cyc, jednakże sam Cyc posiada różne

Ocena metod tworzenia ontologii 107 mikro teorie w celu pozyskania wiedzy z różnych dziedzin i z różnych punktów widzenia, np. teorię mechaniki, teorie pogody w zimie, teorie dokonywania zakupów samochodów. Różne teorie przyjmują różne założenia i uproszczenie odnośnie modelowanego świata. Cechy wspólne poszukiwanej metody i metody CYC są nastepujące: wiedza zdroworozsądkowa, jako źródło informacji, ręczne kodowanie tej wiedzy, uproszczone procesy zasilania wiedzą i aktualizacji. 4.2. Metoda Uscholda i Kinga M. Uschold i M. King, a później razem z M. Grünigerem [12] przedstawili wytyczne do budowy ontologii zorientowanej na wiedzę o przedsiębiorstwach. Identyfikacja celu i zasięgu polega na udzieleniu odpowiedzi na pytania: dlaczego jest budowana dana ontologia, kto i w jaki sposób będzie z niej korzystał, jakie terminy będą odpowiednie. w metodzie, według Fernandeza-Lopeza [9] brakuje procesu konceptualizacji przed procesem implementacji samej ontologii. Ta cecha upodabnia metodę do budowania ontologii kosztów wdrożenia, gdzie konceptualizacja została wykonana wcześniej, na etapie tworzenie systemu informatycznego. Mając na uwadze budowę ontologii kosztów wdrożenia SI, interesujące są procesy określenia celu i zakresu, aczkolwiek dla danego SI będą stałe bez względu na kolejne wdrożenia. Pozyskanie wiedzy i kodowanie oraz ewolucja określone przez Uscholda i Kinga będą miały miejsce również w procesie budowania ontologii kosztów. 4.3. Metoda Grϋningera i Foxa Metoda powstała poprzez wykorzystanie doświadczenia M.Grϋningera i M.Foxa [13] przy budowie ontologii TOVE, będącej podstawą programową umożliwiającą użytkownikom budowanie szerokiej gamy projektów w branży IT, tzw. środowisko Enterprise Design and Engineering. w trakcie budowania ontologii kosztów wdrożenia istotne jest proponowane przez Grϋningera i Foxa: utworzenie scenariuszy motywacyjnych, które pozwolą na opisanie zbioru wymagań weryfikujących ontologię względem aplikacji wykorzystującej ją, opracowanie nieformalnych pytań, na podstawie których można w końcowy etapu budowy zweryfikować kompletność ontologii.

108 Przemysław Plecka, Krzysztof Bzdyra Pozostałe elementy metody Gruningera i Foxa nie będą miały zastosowania z tego powodu, że źródło pozyskanej wiedzy do ontologii jest wysoko sformalizowane w postaci systemu informatycznego. 4.4. KACTUS Metoda opracowana przez Amaya Bernarca w ramach projektu Kactus [6], którego celem było zbadanie wykorzystania wiedzy o złożonych systemach informacyjnych oraz rola ontologii w tychże. Ontologia w tym przypadku reprezentuje wiedzę wymaganą dla danego systemu informatycznego. Procesy sugerowane w tej metodzie w części odpowiadają budowaniu ontologii kosztów wdrożenia: 1. projekt wstępny - chociaż wymagane jest, aby prezentował on docelowy poziomie szczegółowości, 2. udoskonalanie ontologii. Mimo, że obszar zastosowania tej metody jest bardzo bliski wymiarowaniu oprogramowania, to opis metody jest na tyle ogólny, że daje możliwość indywidualnej interpretacji zgodnej lub niezgodnej z intencją autora. 4.5. Methontologia Metoda rozwinięta przez grupę uczonych z Uniwersidad Politecnica de Madrid (m.in. M.Fernandes-Lopez i A.Gomez-Perez) [14] na podstawie standardu rozwoju oprogramowania IEEE [15] oraz metodologii inżynierii wiedzy [16]. Część etapów metody związana z konceptualizacją odbywa się na etapie tworzenia oprogramowania. Do celów tworzenia ontologii kosztów wdrożenia, wykorzystać można jedynie etap rozwoju i pielęgnacji prototypów oraz wybrane zadania (podetapy) występujące we wcześniejszych etapach: 1. szczegółowe definiowanie ad hoc relacji binarnych 2. szczegółowe definiowanie atrybutów instancji, 3. szczegółowe definiowanie atrybutów klas, 4. szczegółowe definiowanie stałych, 5. definiowanie instancji (wystąpień). Niektóre z zadań można potraktować w sposób uproszczone ze względu na specyfikę ontologii, np. istnieje a priori ściśle określona, ograniczona lista atrybutów jednakowych dla klas, instancji i relacji.

4.6. SENSUS Ocena metod tworzenia ontologii 109 SENSUS jest metodą budowy szkieletu ontologii domenowej, poprzez łączenie terminów specyficznych dla danej domeny w celu stworzenia większej ontologii oraz wyodrębnianiu z większej tych terminów, które nie są relewantne dla tworzonej. Nazwa pochodzi o nazwy ontologii na podstawie, której metoda została utworzona [17]. Podejście przyjmowane przez metodę SENSUS promuje dzielenie się wiedzą, gdyż zakłada przyjęcie tej samej ontologii bazowej dla wszystkich nowotworzonych ontologii domenowych. z tego powodu, metoda ta nie będzie miała zastosowania przy budowaniu ontologii kosztów wdrożenia, mimo, że interesującą jej cechą jest prostota procesów tworzenia ontologii. 4.7. ON-TO-KNOWLEDGE Metoda ta powstała przy okazji projektu o tej samej nazwie realizowanego przez Y.Sure a, S.Staaba, R.Studera [18], którego celem było ułatwienie zarządzania wiedzą w dużych rozproszonych organizacjach. Odwołuje się do metod związanych z zarządzaniem wiedzą, dlatego też ontologie powstałe przy jej użyciu silnie zależne są od ich przyszłego zastosowania. Dla procesu budowy ontologii kosztów wdrożenia szczególnie istotne są trzy końcowe procesy występujące w tej metodzie: 1. udoskonalenie celem jest wytworzenie dojrzałej ukierunkowanej na aplikacje ontologii według specyfikacji podanej w procesie początkowym, składa się z dwóch podprocesów: o pozyskiwania wiedzy przez ekspertów dziedzinowych - procesu iteracyjnego stosowanego przez wielu ekspertów, wypełniają (uszczegóławiają) oni wersję szkieletową ontologii w określonych zakresach ich wiedzy, o formalizacji procesu zapisu wiedzy w konkretnym języku ontologii wybranym ze względu na konkretne wymagania względem ontologii, 2. ewaluacja proces powtarzany w wielokrotnych cyklach pozwala na ciągłe udoskonalenia ontologii, jednocześnie weryfikuje i ocenia ontologie bazową poprzez podprocesy: o sprawdzania wymagań oraz pytań kompetencyjnych, o testowania ontologii w środowisku aplikacji docelowej, 3. pielęgnacja systemu określa kto będzie odpowiedzialny i w jaki sposób zapewni administrowanie ontologią, w tym aktualizację wiedzy w niej zawartej

110 4.8. Wyniki analizy Przemysław Plecka, Krzysztof Bzdyra Przedstawiona wcześniej analiza pozwala wykonać mapę użyteczności metod w etapach tworzenia ontologii kosztów wdrożenia z uwzględnieniem kryteriów od K1 do K6. Mapę pokazano w tabeli 2, wykorzystano oznaczenia: wartość 0 brak spełnienia kryterium, znak ~ (tylda) częściowe spełnienie kryterium, wartość 1 spełnienie danego kryterium. Z przedstawionej mapy, wynika, że najlepszym rozwiązaniem może być stosowanie metody hybrydowej, łączącej na różnych etapach procesu budowania ontologii procesy z wybranych metod. Tab. 2. Mapa metod budowania ontologii Nr etapu Kryterium CYC Unschold i King Grϋninger i Fox Kaktus Methontologia SENSUS On-to-knowlage 1.a K1 0 0 1 0 0 0 0 1.b K2 0 0 1 0 0 0 0 2 3 K3 0 0 1 0 0 0 0 K4 ~ ~ 1 0 1 0 0 K5 1 ~ 0 ~ 0 ~ 1 K6 0 0 0 1 ~ 0 1 5. Przykład zastosowania Weryfikację oceny przedstawionej w poprzednim rozdziale przeprowadzono na przykładzie budowy ontologii wykorzystywanej do szacowania kosztów zmian SI w średnim przedsiębiorstwie produkcyjnym z branży wyrobów dla przemysłu okrętowego. Dostawca najpierw zbudował ontologię referencyjna a następ-

Ocena metod tworzenia ontologii 111 nie na jej podstawie ontologie uwzględniająca wymagania klienta. Poprzez porównania obu modeli wyznaczył różnice w kosztach wdrożenia SI. Proces identyfikacji celu i zakresu (metoda Uscholda i Kinga, Grϋningera i Foxa), określenia aplikacji i kontekstu (KAKTUS), czy też identyfikacja procesu budowy (Methontologia) nie musiał być w tym przypadku realizowany, gdyż źródłem wiedzy był gotowy system informatyczny. To on wyznaczył zakres i kontekst tworzonej ontologii. Nie było też potrzeby tworzenia terminologii (metoda Grϋningera i Foxa, SENSUS) ani konceptualizacji (Methontologia) - zaczerpnięto je bezpośrednio z systemu informatycznego. 5.1. Model statyczny system (etap 1.a) Wykonano wersję wstępna ontologii (projekt wstępny w metodzie KAKTUS, prototyp w Methontologi), który zawierał jedynie wiedzę pobraną z SI (koncepty - odpowiadające danym, relacje odpowiadające procesom). Wykorzystano do tego celu diagramy klas w UML, chociaż został przeniesiony do ontologii z dużym uproszczeniem. Fragment ontologii zawierający model statyczny przedstawiono na Rysunku 2. Rys. 2. Fragment modelu statycznego (przygotowano w Protégé) [19] 5.2. Model dynamiczny system (etap 1b) Następnie do konceptów dodano relacje odpowiadające za procesy przetwarzające dane. Dostawca posiadał cześć opisów procesów za pomocą diagramu przepadków użycia (ang. use case diagram), a cześć zgodnie z BPMN. Dane nie zostały przeniesione automatycznie (jak w metodzie KAKTUS) z powody braku dostępnych narzędzi do automatyzacji tego procesu. Fragment ontologii zawierający model statyczny i model dynamiczny przedstawiono na rysunku 3.

112 Przemysław Plecka, Krzysztof Bzdyra Rys. 3. Fragment modelu statycznego i dynamicznego (przygotowano w Protégé) [19] 5.3. Model kosztów Następnie określono wspólne atrybuty dla wszystkich obiektów występujących w ontologii (metoda Grϋningera i Foxa, Methontologia). Atrybutom (np. koszt utworzenia, koszt parametryzacji) przypisano wartości na podstawie wiedzy pozyskanej od ekspertów lub z dokumentacji zrealizowanych wdrożeń. Proces ten odbywał się podobnie, jak proces ręcznego kodowania wiedzy w metodzie CYC lub Uscholda i Kinga. Zbudowana w ten sposób ontologia zawierała informacje o systemie ERP dostawcy (o danych i procesach realizowanych przez SI) oraz o kosztach wdrożenia poszczególnych elementów ontologii (konceptów i relacji). Może być użyta wielokrotnie w takiej samej wersji lub po kolejnych konserwacjach (udoskonalanie w metodzie KAKTUS, udoskonalenie i ewaluacja w metodzie ON-TO-KNOWLAGE, utrzymanie w Methontologii). Wiedz zawarta w tej ontologii może być podstawą do odpowiedzi na pytania związane z kosztami wdrożenia (np. koszt utworzenia, koszt parametryzacji). Do zapisania doświadczenia dostawcy z wcześniejszych wdrożeń wykorzystane są właściwości (atrybuty) obiektów w ontologii (klas, wystąpień, relacji). Można zapisać w nich metryki służące do późniejszego wymiarowania kosztów. Na przykład, niech w ontologii SI w części logistycznej, występuje klasa Wydanie_zewnętrzne, która posiada przypisaną atrybut Parametryzacja o wartości 3h oraz Koszt_dodania o wartości 12h. Fragment ontologii zawierający model statyczny i model dynamiczny oraz atrybuty z przykładowymi wartościami przedstawiono na Rysunku 4.

Ocena metod tworzenia ontologii 113 Rys. 4. Fragment modelu statycznego i dynamicznego wraz z atrybutami (przygotowano w Protégé) [19] 5.4. Modyfikacja modeli o wymagania klienta W kolejnym etapie, dostawca zmodyfikował ontologię dostosowując ją do wymagań klienta (użytkownika SI). W trakcie rozmów handlowych dostawca pozyskał informacje, że klient wystawia nie tylko dokument WZ (wydanie zewnętrzne), ale dodatkowo dla odbiorców zagranicznych list przewozowy (ang. Delivery Letter UE), to w ontologii zostanie dodana klasa List_przewozowy i wystąpienie Delivery_Letter_UE, które odziedziczy atrybut z klasy nadrzędnej. w procesie szacowania wdrożenia oznaczać to będzie, że czas potrzebny na odpowiednią modyfikację oprogramowania wyniesie 12 godzin, a parametryzacja utworzonego w ten sposób raportu (wydruku List_przewozowy) kolejne 3 godziny. Celowym jest automatyczne dziedziczenie metryk do klas potomnych na etapie dodawania elementów ontologii, jednak dopuszczalne jest późniejsze modyfikowanie ich wartości na podstawie, np. Indywidualnej Oceny Eksperta. Fragment ontologii z dodatkową częścią wynikającą z wymagań klienta przedstawiono na rysunku 5. Procesy budowania ontologii na tym etapie można porównać z ewaluacją w metodzie Uscholda i Kinga czy ON-TO-KNOWLEDGE, udoskonaleniem w metodzie KAKTUS lub dodawaniem ścieżek relewantnych w metodzie SEN- SUS, najbardziej jest jednak zbliżony do ręcznego kodowania w metodzie CYC.

114 Przemysław Plecka, Krzysztof Bzdyra Rys. 5. Fragment ontologii z dodatkową częścią wynikającą z wymagań klienta (przygotowano w Protégé) [19] 5.5. Przetwarzanie modelu w celu estymacji kosztów Następnie, wyznaczona zostaje różnicy między zmienioną ontologią powstała na ostatnim etapie a referencyjną. Ze zbioru różnic a w szczególności z wartości atrybutów konceptów i relacji dostawca wnioskuje o dodatkowym koszcie wdrożenia. Szczegółowy opis metody przedstawiony jest w literaturze [5]. 6. Wnioski W praktyce może być to kłopotliwe i nie będzie rozwiązywało problemu, gdyż przedsiębiorstwa IT, pod wpływem presji czasu nadal będą szacować projekty tradycyjnymi metodami niż inwestować w specjalistów od baz wiedzy. Interesującym rozwiązaniem mogą być prace prowadzone nad zastosowaniem algorytmów sztucznej inteligencji do drążenia danych zawartych w systemach transakcyjnych przedsiębiorstwa (data mining) i automatycznego tworzenia baz wiedzy [20]. Literatura 1. M. Burns, How to select and implement an ERP System, 2005. [Online]. Available: http://www.180systems.com/erpwhitepaper.pdf. 2. M. Kotarba, Problemy występujące podczas modyfikacji standardowego systemu ERP i sposoby ich pokonania na przykładzie wdrożenia systemu

Ocena metod tworzenia ontologii 115 Oracle JD Edwords Enterprice One w przedsiębiorstwie z branży spożywczej, w Systemy Wspomagania Organizacji 2007, Katowice, 2007. 3. S. McConell, Software Estimation: Demystifying the Blac Art., Microsoft Press, 2006. 4. P. Plecka i K. Bzdyra, Algorithm of Selecting Cost Estimation Methods for ERP Software Implementation, w Foundations of Management - International Journal, Warszawa, 2013. 5. P. Plecka i K. Bzdyra, Wykorzystanie ontoligii w wymiarowaniu projektów informatycznych., w XVII Konferencja Innowacje w Zarządzaniu i Inżynierii Produkcji, Zakopane, luty 2014. 6. M. Fernandez Lopez i A. Gomez Perez, Overview and analysis of methodology for building ontologies, The Knowledge Engineering Review, tom 17, nr 2, pp. 129-156, 2002. 7. W. Górka, Narzędzia do budowy ontologii i narzędzia wnioskujące, 2012. 8. A. Czarnecki i C. Orłowski, Możliwości zastosowania ontologii do oceny technologii informatycznych, w Komputerowo zintegrowane zarządzanie. tom 2 pod red. Ryszarda Knosali, Opole, Oficyna Wydawnicza Polskiego Towarzystwa Zarządzania Produkcją, 2007, pp. 143-152. 9. M. Fernandez Lopez, Overview of Methodologies for Building Ontologies, w IJCAI-99 Workshop on Ontologies and Problem Solving Methods KRR5, Stockholm, Sweden, 1999. 10. W. Gliński, Wybrane metodologie i metody budowania ontologii, w B. Sosińska-Kalata, E. Chuchro, W. Daszewski, Informacja w sieci. Problemy. Metody. Technologie., Warszawa, Stowarzyszenie Bibliotekarzy Polskich, 2006, pp. 157-207. 11. CYCORP. Home of Smart Solutions., Cycorp, [Online]. Available: www.cycorp.com. [Data uzyskania dostępu: 01 3 2014]. 12. M. Uschold i M. Gruninger, Ontologies, Principles Methods and Applications., The Knowledge Engineering Review, Cambridge University Press, tom 11, nr 02, pp. 93-136, 1996. 13. M. Gruninger i M. S. Fox, Methodology for the design and evaluation of ontologies, w Workshop on Basic Ontological Issues in Knowledge Sharing, International Joint Conference on Artificial Intelligence 1995, Montreal, Quebec, Canada, 1995. 14. M. Fernandez Lopez, A. Gomez Perez i N. Juristo, METHONTOLOGY: From Ontological Art Towards Ontological Engineering, AAAI Technical Report SS-97-06, 1997. 15. 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.

116 Przemysław Plecka, Krzysztof Bzdyra 16. A. Gomez Perez, M. Fernandez Lopez i O. Corcho, Ontological Engineering: with examples from the areas of Knowledge Management, e- Commerce and the Semantic Web., Springer, 2010. 17. E. Hovy, Ontologies (SENSUS) and Lexicons, [Online]. Available: http://www.isi.edu/natural-language/projects/ontologies.html. [Data uzyskania dostępu: 01 03 2014]. 18. Y. Sure, S. Staab i R. Studer, On-To-Knowledge Methodology (OTKM), International Handbooks on Information Systems, pp. 117-132, 2004. 19. Welcome to protégé, Stanford Center for Biomedical Informatics Research, Stanford University School of Medicine, [Online]. Available: http://protege.stanford.edu/. [Data uzyskania dostępu: 16 11 2013]. 20. M. Relich, Knowledge acquisition for new product development with the use of an ERP database., w Federated Conference on Computer Science and Information Systems, Kraków, 2013.