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

Wielkość: px
Rozpocząć pokaz od strony:

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

Transkrypt

1 PRZEMYSŁAW PLECKA KRZYSZTOF BZDYRA 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-

2 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-

3 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-

4 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ą

5 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,

6 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 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

7 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 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 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.

8 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 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 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.

9 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 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

10 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 K b K K K4 ~ ~ K5 1 ~ 0 ~ 0 ~ 1 K ~ 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-

11 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 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.

12 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.

13 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.

14 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, [Online]. Available: 2. M. Kotarba, Problemy występujące podczas modyfikacji standardowego systemu ERP i sposoby ich pokonania na przykładzie wdrożenia systemu

15 Ocena metod tworzenia ontologii 115 Oracle JD Edwords Enterprice One w przedsiębiorstwie z branży spożywczej, w Systemy Wspomagania Organizacji 2007, Katowice, S. McConell, Software Estimation: Demystifying the Blac Art., Microsoft Press, P. Plecka i K. Bzdyra, Algorithm of Selecting Cost Estimation Methods for ERP Software Implementation, w Foundations of Management - International Journal, Warszawa, 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 M. Fernandez Lopez i A. Gomez Perez, Overview and analysis of methodology for building ontologies, The Knowledge Engineering Review, tom 17, nr 2, pp , W. Górka, Narzędzia do budowy ontologii i narzędzia wnioskujące, 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 M. Fernandez Lopez, Overview of Methodologies for Building Ontologies, w IJCAI-99 Workshop on Ontologies and Problem Solving Methods KRR5, Stockholm, Sweden, 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 CYCORP. Home of Smart Solutions., Cycorp, [Online]. Available: [Data uzyskania dostępu: ]. 12. M. Uschold i M. Gruninger, Ontologies, Principles Methods and Applications., The Knowledge Engineering Review, Cambridge University Press, tom 11, nr 02, pp , 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, M. Fernandez Lopez, A. Gomez Perez i N. Juristo, METHONTOLOGY: From Ontological Art Towards Ontological Engineering, AAAI Technical Report SS-97-06, IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990.

16 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, E. Hovy, Ontologies (SENSUS) and Lexicons, [Online]. Available: [Data uzyskania dostępu: ]. 18. Y. Sure, S. Staab i R. Studer, On-To-Knowledge Methodology (OTKM), International Handbooks on Information Systems, pp , Welcome to protégé, Stanford Center for Biomedical Informatics Research, Stanford University School of Medicine, [Online]. Available: [Data uzyskania dostępu: ]. 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.

WYKORZYSTANIE ONTOLOGII W WYMIAROWANIU PROJEKTÓW INFORMATYCZNYCH

WYKORZYSTANIE ONTOLOGII W WYMIAROWANIU PROJEKTÓW INFORMATYCZNYCH WYKORZYSTANIE ONTOLOGII W WYMIAROWANIU PROJEKTÓW INFORMATYCZNYCH Przemysław PLECKA, Krzysztof BZDYRA Streszczenie: W trakcie procesów sprzedaży systemów ERP okazuje się, że zbiór standardowej funkcjonalności

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje

Bardziej szczegółowo

Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej

Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej FiM Consulting Sp. z o.o. Szymczaka 5, 01-227 Warszawa Tel.: +48 22 862 90 70 www.fim.pl Spis treści

Bardziej szczegółowo

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM SZKOŁA GŁÓWNA HANDLOWA w Warszawie STUDIUM MAGISTERSKIE Kierunek: Metody ilościowe w ekonomii i systemy informacyjne Karol Walędzik Nr albumu: 26353 Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem

Bardziej szczegółowo

Case Study. Rozwiązania dla branży metalowej

Case Study. Rozwiązania dla branży metalowej Case Study Rozwiązania dla branży metalowej Charakterystyka klienta Firma produkująca wyroby ze stali czarnej, aluminium, stali nierdzewnej oraz elementy konstrukcji i konstrukcje metalowe. W palecie rozwiązań

Bardziej szczegółowo

Projektowanie bazy danych przykład

Projektowanie bazy danych przykład Projektowanie bazy danych przykład Pierwszą fazą tworzenia projektu bazy danych jest postawienie definicji celu, założeń wstępnych i określenie podstawowych funkcji aplikacji. Każda baza danych jest projektowana

Bardziej szczegółowo

Mateusz Kurleto NEOTERIC. Analiza projektu B2B Kielce, 18 października 2012

Mateusz Kurleto NEOTERIC. Analiza projektu B2B Kielce, 18 października 2012 2012 Pierwsze przymiarki do zakresu informatyzacji (rodzaj oprogramowania: pudełkowe, SaaS, Iaas, CC, PaaS. Zalety i wady: dostępność, koszty, narzędzia, ludzie, utrzymanie, bezpieczeństwo, aspekty prawne)

Bardziej szczegółowo

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa

Budowa systemu wspomagającego podejmowanie decyzji. Metodyka projektowo wdrożeniowa Budowa systemu wspomagającego podejmowanie decyzji Metodyka projektowo wdrożeniowa Agenda Systemy wspomagające decyzje Business Intelligence (BI) Rodzaje systemów BI Korzyści z wdrożeń BI Zagrożenia dla

Bardziej szczegółowo

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań 2012 Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań Mateusz Kurleto NEOTERIC Wdrożenie systemu B2B Lublin, 25 października 2012 Mateusz Kurleto Od 2005 r. właściciel NEOTERIC,

Bardziej szczegółowo

Od ERP do ERP czasu rzeczywistego

Od ERP do ERP czasu rzeczywistego Przemysław Polak Od ERP do ERP czasu rzeczywistego SYSTEMY INFORMATYCZNE WSPOMAGAJĄCE ZARZĄDZANIE PRODUKCJĄ Wrocław, 19 listopada 2009 r. Kierunki rozwoju systemów informatycznych zarządzania rozszerzenie

Bardziej szczegółowo

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

Ontologie, czyli o inteligentnych danych

Ontologie, czyli o inteligentnych danych 1 Ontologie, czyli o inteligentnych danych Bożena Deka Andrzej Tolarczyk PLAN 2 1. Korzenie filozoficzne 2. Ontologia w informatyce Ontologie a bazy danych Sieć Semantyczna Inteligentne dane 3. Zastosowania

Bardziej szczegółowo

Case Study. aplikacji Microsoft Dynamics CRM 4.0. Wdrożenie w firmie Finder S.A.

Case Study. aplikacji Microsoft Dynamics CRM 4.0. Wdrożenie w firmie Finder S.A. Case Study aplikacji Microsoft Dynamics CRM 4.0 Wdrożenie w firmie Finder S.A. PRZEDSTAWIENIE FIRMY Finder jest operatorem systemu lokalizacji i monitoringu, wspomagającego zarządzanie pracownikami w terenie

Bardziej szczegółowo

STUDIA I MONOGRAFIE NR

STUDIA I MONOGRAFIE NR STUDIA I MONOGRAFIE NR 21 WYBRANE ZAGADNIENIA INŻYNIERII WIEDZY Redakcja naukowa: Andrzej Cader Jacek M. Żurada Krzysztof Przybyszewski Łódź 2008 3 SPIS TREŚCI WPROWADZENIE 7 SYSTEMY AGENTOWE W E-LEARNINGU

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Karta przedmiotu studiów podyplomowych

Karta przedmiotu studiów podyplomowych Karta przedmiotu studiów podyplomowych Nazwa studiów podyplomowych Nazwa obszaru kształcenia, w zakresie którego są prowadzone studia podyplomowe Nazwa kierunku studiów, z którym jest związany zakres studiów

Bardziej szczegółowo

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

Bardziej szczegółowo

Wstęp... 9. Część I. Podstawy teoretyczne zintegrowanych systemów zarządzania

Wstęp... 9. Część I. Podstawy teoretyczne zintegrowanych systemów zarządzania Wstęp... 9 Część I. Podstawy teoretyczne zintegrowanych systemów zarządzania 1. Systemy informatyczne zarządzania... 13 1.1. System informacyjny, system informatyczny, system informatyczny zarządzania...

Bardziej szczegółowo

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia 2009. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego

Bardziej szczegółowo

Piotr Krząkała. Dyrektor Handlowy ds. Kluczowych Klientów

Piotr Krząkała. Dyrektor Handlowy ds. Kluczowych Klientów Piotr Krząkała Dyrektor Handlowy ds. Kluczowych Klientów Strategia firmy Każda organizacja działająca we współczesnym biznesie powinna posiadać określoną strategię działania i na tej bazie budować system

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq

Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq Skuteczna Strategia CRM - wyzwanie dla organizacji Artur Kowalski Prometriq Wrocław, 19-11-2009 Jest tylko jedna strategia sukcesu Polega ona na precyzyjnym zdefiniowaniu docelowego odbiorcy i zaoferowaniu

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM.

MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM. PRACA DYPLOMOWA WYŻSZE STUDIA ZAWODOWE MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM. Marcin Brudka 3901 Promotor: Prof. dr hab. inż. Piotr

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa

Bardziej szczegółowo

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

Informatyzacja przedsiębiorstw

Informatyzacja przedsiębiorstw Informatyzacja przedsiębiorstw Bartosz Szczęch IT.integro Informatyzacja przedsiębiorstw Informatyzacja przedsiębiorstw jest zbiorem działań zmierzających do realizacji specjalizowanych systemów informatycznych

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Tematy prac magisterskich Rok akademicki 2013/2014

Tematy prac magisterskich Rok akademicki 2013/2014 Dr hab. inż. Jan Werewka, prof. n. AGH Wydział EAIiIB AGH E-mail: werewka@agh.edu.pl www: http://home.agh.edu.pl/werewka Tematy prac magisterskich Rok akademicki 2013/2014 Temat 1 Architektura przedsięwzięcia

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie

Bardziej szczegółowo

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r.

Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Załącznik nr 1. Specyfikacja techniczna portalu internetowego Łódź, 15.10.2012 r. Stworzenie platformy internetowej na potrzeby projektu. 1 Wykonanie portalu internetowego na potrzeby e-usługi, obejmującego

Bardziej szczegółowo

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A. Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration

Bardziej szczegółowo

Systemy ERP. dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/

Systemy ERP. dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Systemy ERP dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Źródło: Materiały promocyjne firmy BaaN Inventory Control Jako pierwsze pojawiły się systemy IC (Inventory Control) - systemy zarządzania

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn.

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn. Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego ZAPYTANIE OFERTOWE nr /UE/204 z dnia 7.0.204 r. w związku z realizacją projektu pn. Wdrożenie

Bardziej szczegółowo

Arkadiusz Rajs Agnieszka Goździewska-Nowicka Agnieszka Banaszak-Piechowska Mariusz Aleksiewicz. Nałęczów, 20lutego 2014

Arkadiusz Rajs Agnieszka Goździewska-Nowicka Agnieszka Banaszak-Piechowska Mariusz Aleksiewicz. Nałęczów, 20lutego 2014 Arkadiusz Rajs Agnieszka Goździewska-Nowicka Agnieszka Banaszak-Piechowska Mariusz Aleksiewicz Nałęczów, 20lutego 2014 Wstęp Zarządzanie to, przyjmując ogólną interpretację, kompleks działań służących

Bardziej szczegółowo

Projektowanie Modeli Usług dla rozwiązań typu SOA

Projektowanie Modeli Usług dla rozwiązań typu SOA Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom

Bardziej szczegółowo

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008

Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Koncepcja systemu zarządzania jakością w dużym projekcie informatycznym zgodnie z normą ISO/IEC 9001:2008 Autor: Kinga Lewandowska Promotor: dr inż. Szymon Supernak Zakres pracy CZĘŚĆ TEORETYCZNA Przegląd

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

Narzędzia CASE dla.net. Łukasz Popiel Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

Bardziej szczegółowo

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki:

Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście. Rozdział pochodzi z książki: Rozdział pochodzi z książki: Zarządzanie projektami badawczo-rozwojowymi. Tytuł rozdziału 6: Komputerowe wspomaganie zarządzania projektami innowacyjnymi realizowanymi w oparciu o podejście adaptacyjne

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa pliku Tom 6 Opis oprogramowania, Część 2 Generator danych

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską z Programu Operacyjnego Innowacyjna Gospodarka na lata 2007-2013 ZAMAWIAJĄCY:

Projekt współfinansowany przez Unię Europejską z Programu Operacyjnego Innowacyjna Gospodarka na lata 2007-2013 ZAMAWIAJĄCY: ZAMAWIAJĄCY: realizując zamówienie w ramach projektu dofinansowanego z Programu Operacyjnego Innowacyjna Gospodarka Działania 1.4-4.1 Badanie i rozwój nowoczesnych technologii Inwestycje w innowacyjne

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

Proces technologiczny. 1. Zastosowanie cech technologicznych w systemach CAPP

Proces technologiczny. 1. Zastosowanie cech technologicznych w systemach CAPP Pobożniak Janusz, Dr inż. Politechnika Krakowska, Wydział Mechaniczny e-mail: pobozniak@mech.pk.edu.pl Pozyskiwanie danych niegeometrycznych na użytek projektowania procesów technologicznych obróbki za

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania

Bardziej szczegółowo

WYBRANE METODOLOGIE I METODY BUDOWANIA ONTOLOGII

WYBRANE METODOLOGIE I METODY BUDOWANIA ONTOLOGII metody ontologii, ontologie, reprezentacja wiedzy, inżyniera wiedzy, SENSUS, Cyc, Kactus, Methontologia, SENSUS, On-To-Knowledge. WIESŁAW GLIŃSKI Instytut Informacji Naukowej i Studiów Bibliologicznych,

Bardziej szczegółowo

Virtual Grid Resource Management System with Virtualization Technology

Virtual Grid Resource Management System with Virtualization Technology Virtual Grid Resource Management System with Virtualization Technology System zarządzania zasobami wirtualnego Gridu z wykorzystaniem technik wirtualizacji Joanna Kosińska Jacek Kosiński Krzysztof Zieliński

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Język UML w modelowaniu systemów informatycznych Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

1. Wybór systemu ERP. 2. Wzajemne relacje systemów ERP i BPMS.

1. Wybór systemu ERP. 2. Wzajemne relacje systemów ERP i BPMS. Agenda 1. Wybór systemu ERP. 2. Wzajemne relacje systemów ERP i BPMS. 1 dr inż. Marek Szelągowski AFiB Vistula marek.szelagowski@dbpm.pl Naszą misją jest: Wspieranie naszych klientów w wypracowywaniu usprawnień

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Cykle życia systemu informatycznego

Cykle życia systemu informatycznego Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: Systemy ekspertowe w zarządzaniu firmą Expert systems in enterprise management Kierunek: Zarządzanie i Inżynieria Produkcji Rodzaj przedmiotu: Rodzaj zajęć: Wyk. Ćwicz. Lab. Sem. Proj.

Bardziej szczegółowo

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI ZARZĄDZANIE I INŻYNIERIA PRODUKCJI STUDIA PIERWSZEGO STOPNIA PROFIL OGÓLNOAKADEMICKI Załącznik nr 2 Odniesienie efektów kierunkowych do efektów obszarowych i odwrotnie Załącznik nr 2a - Tabela odniesienia

Bardziej szczegółowo

Dopasowanie IT/biznes

Dopasowanie IT/biznes Dopasowanie IT/biznes Dlaczego trzeba mówić o dopasowaniu IT-biznes HARVARD BUSINESS REVIEW, 2008-11-01 Dlaczego trzeba mówić o dopasowaniu IT-biznes http://ceo.cxo.pl/artykuly/51237_2/zarzadzanie.it.a.wzrost.wartosci.html

Bardziej szczegółowo

Konfiguracja modelowania w procesie wytwarzania oprogramowania

Konfiguracja modelowania w procesie wytwarzania oprogramowania Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na

Bardziej szczegółowo

Sposób oceny polityki eksploatacyjnej w przedsiębiorstwach branży spożywczej

Sposób oceny polityki eksploatacyjnej w przedsiębiorstwach branży spożywczej Politechnika Śląska Wydział Organizacji i Zarządzania Instytut Inżynierii Produkcji Sposób oceny polityki eksploatacyjnej w przedsiębiorstwach branży spożywczej Dr inż. Andrzej Loska VII Konferencja Utrzymanie

Bardziej szczegółowo

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Automatyzacja Procesów Biznesowych. Systemy Informacyjne Przedsiębiorstw

Automatyzacja Procesów Biznesowych. Systemy Informacyjne Przedsiębiorstw Automatyzacja Procesów Biznesowych Systemy Informacyjne Przedsiębiorstw Rodzaje przedsiębiorstw Produkcyjne największe zapotrzebowanie na kapitał, największe ryzyko Handlowe kapitał obrotowy, średnie ryzyko

Bardziej szczegółowo

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi

Bardziej szczegółowo

System informacji edukacyjnej regionu kujawsko-pomorskiego

System informacji edukacyjnej regionu kujawsko-pomorskiego X Konferencja PLOUG Kościelisko Październik 2004 System informacji edukacyjnej regionu kujawsko-pomorskiego Izabela Rojek-Mikołajczak Krzysztof Tyburek Akademia Bydgoska, Instytut Mechaniki Środowiska

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering) Wykład 1

Inżynieria oprogramowania (Software Engineering) Wykład 1 Inżynieria oprogramowania (Software Engineering) Wykład 1 Wprowadzenie do inżynierii oprogramowania Zarządzanie przedmiotem Wydział: WEiI Katedra: KIK Web site: http://moskit.weii.tu.koszalin.pl/~swalover/

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

Dobór systemów klasy ERP

Dobór systemów klasy ERP klasy ERP - z uwzględnieniem wymagań normy ISO 9001 Prezentacja w Klubie Menedżera Jakości, 19 marzec 2008 Zagadnienia ogólne związane z doborem systemu klasy ERP Podstawowe podziały klasyfikujące systemy

Bardziej szczegółowo

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Zalew danych skąd się biorą dane? są generowane przez banki, ubezpieczalnie, sieci handlowe, dane eksperymentalne, Web, tekst, e_handel

Zalew danych skąd się biorą dane? są generowane przez banki, ubezpieczalnie, sieci handlowe, dane eksperymentalne, Web, tekst, e_handel według przewidywań internetowego magazynu ZDNET News z 8 lutego 2001 roku eksploracja danych (ang. data mining ) będzie jednym z najbardziej rewolucyjnych osiągnięć następnej dekady. Rzeczywiście MIT Technology

Bardziej szczegółowo

Wprowadzenie do zarządzania procesami biznesowymi

Wprowadzenie do zarządzania procesami biznesowymi Wprowadzenie do zarządzania procesami biznesowymi Definicja procesu Proces jest jednostką pracy obejmującą wiele czynności, wykonywanych w ogólności przez różnych wykonawców i w sposób współbieżny. Proces

Bardziej szczegółowo

Projektowanie baz danych za pomocą narzędzi CASE

Projektowanie baz danych za pomocą narzędzi CASE Projektowanie baz danych za pomocą narzędzi CASE Metody tworzenia systemów informatycznych w tym, także rozbudowanych baz danych są komputerowo wspomagane przez narzędzia CASE (ang. Computer Aided Software

Bardziej szczegółowo

Prowadzący Andrzej Kurek

Prowadzący Andrzej Kurek Prowadzący Andrzej Kurek Centrala Rzeszów Oddziały Lublin, Katowice Zatrudnienie ponad 70 osób SprzedaŜ wdroŝenia oprogramowań firmy Comarch Dopasowania branŝowe Wiedza i doświadczenie Pełna obsługa: Analiza

Bardziej szczegółowo

Plan zarządzania projektem

Plan zarządzania projektem Plan zarządzania projektem Opracował: Zatwierdził: Podpis: Podpis: Spis treści: 1. Wst p... 2 1.1 Cel... 2 1.2 Zakres... 2 1.3 Przeznaczenie dokumentu... 2 1.4 Organizacja dokumentu... 2 1.5 Dokumenty

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo