Modelowanie scenariuszy negocjacyjnych w celu zwi kszenia skuteczno±ci realizacji przedsi wzi zespoªowych

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

Download "Modelowanie scenariuszy negocjacyjnych w celu zwi kszenia skuteczno±ci realizacji przedsi wzi zespoªowych"

Transkrypt

1 Politechnika Gda«ska Wydziaª Elektroniki, Telekomunikacji i Informatyki Katedra Architektury Systemów Komputerowych Rozprawa doktorska Modelowanie scenariuszy negocjacyjnych w celu zwi kszenia skuteczno±ci realizacji przedsi wzi zespoªowych Michaª Piotrowski Promotor: prof. dr hab. in». Henryk Krawczyk Gda«sk 2008

2 Spis tre±ci 1 Wprowadzenie Problematyka i tezy pracy Najwa»niejsze poj cia Wykaz najwa»niejszych oznacze«i skrótów Wªasno±ci i strategie przetwarzania zespoªowego rodowiska e-negocjacyjne Taksonomia e-negocjacji Scenariusze przetwarzania zespoªowego J zyki opisu scenariuszy przetwarzania zespoªowego J zyki opisu orkiestracji J zyki opisu choreograi Analiza procesu negocjacji Teoria gier a negocjacje Obliczeniowy model negocjacji Pomiary jako±ciowe System wspomagaj cy ocen jako±ci negocjacji Model eksperymentów negocjacyjnych Architektura systemu GAJA Procedury badania jako±ci negocjacji Wyniki eksperymentów

3 SPIS TRE CI 2 4 Negocjacje elektroniczne i ich symulacje Modelowanie negocjacji rodowisko po±rednicz ce Wzorce eksperymentów Algorytmy symulacyjne Symulacja jednozagadnieniowych ta«ców negocjacyjnych Symulacja negocjacji wielozagadnieniowych Eksperymenty negocjacyjne z udziaªem ludzi i algorytmu komputerowego Porównanie wyników eksperymentów Wnioski ko«cowe Wyniki a tezy pracy Mo»liwo±ci rozwoju ±rodowiska po±rednicz cego i tendencje generalizuj ce Spis rysunków 122 Spis tabel 124 Bibliograa 125

4 Rozdziaª 1 Wprowadzenie Rozwi zywanie zªo»onych problemów prowadzi do powstawania zespoªów ludzkich, gdzie ka»dy czªonek zespoªu wnosiª swoje unikalne umiej tno±ci. Wraz z rozpowszechnieniem si internetu praca zespoªowa zostaªa przeniesiona cz ±ciowo do ±rodowiska wirtualnego a jej uczestnikami, poza lud¹mi, staªy si systemy komputerowe. Zaistniaªa potrzeba utworzenia odpowiednich rozproszonych ±rodowisk informatycznych umo»liwiaj cych efektywn wspóªprac wielu osób pracuj cych nad wspólnym projektem. Od pocz tku istnienia rozproszonych, internetowych przedsi wzi zespo- ªowych zacz to tworzy ±rodowiska wspomagaj ce prac zespoªow w internecie. Wi kszo± pocz tkowych rozwi za«byªa ukierunkowana na pojedyncze elementy pracy zespoªowej, np. udost pnianie dokumentów. Z czasem proponowane ±rodowiska dostosowywano do wspomagania pracy nad konkretnym typem przedsi wzi. Jednak do dzi± brakuje w peªni uniwersalnych rozwi - za«, które pozwalaªyby na du» elastyczno± zarz dzania i sterowania przedsi wzi ciami zespoªowymi i wykorzystanie zasad wspóªpracy zapisanych w postaci formalnego scenariusza: choreograi i orkiestracji. We wszystkich przedsi wzi ciach mo»emy wyró»ni kilka wspólnych elementów. Jednym z nich s negocjacje. W przypadku projektu informatycznego na etapie okre±lania specykacji wymaga«i tworzenia projektu mamy do czynienia mi dzy innymi z negocjowaniem wizji tworzonego produktu z 3

5 1.1. PROBLEMATYKA I TEZY PRACY 4 jego przyszªym klientem. W najbardziej klasycznym modelu wytwarzania oprogramowania, modelu kaskadowym, takie negocjacje s przeprowadzane gªównie w pocz tkowych etapach projektu oraz na sam koniec projektu, przy jego wdra»aniu. W nowocze±niejszych modelach wytwarzania oprogramowania, jak np. modelu przyrostowym czy iteracyjnym, te negocjacje s przeprowadzane regularnie. Wiadomym jest te»,»e obrany model wytwarzania oprogramowania wpªywa na wynik ko«cowy przedsi wzi cia. Wybór modelu wytwarzania oprogramowania w zespole te» dokonuje si w drodze negocjacji. Mo»na wi c zasugerowa,»e algorytm przeprowadzania negocjacji ma wpªyw na wynik przedsi wzi cia. Brakuje jednak narz dzi, które pozwoliªyby na spójne i formalne wyra»enie takiego algorytmu i byªyby w stanie równie» na tym etapie wesprze przeprowadzanie przedsi wzi rozproszonych. Ze wzgl du na istotn rol negocjacji w przedsi wzi ciach zespoªowych znaczenie negocjacji odbywaj cych si przez internet ro±nie od wielu lat i wiele o±rodków prowadzi aktualnie aktywne badania nad e-negocjacjami [40, 51]. 1.1 Problematyka i tezy pracy W niniejszej pracy gªównymi celami bada«byªy analiza jako±ciowa negocjacji, b d cych wa»nym aspektem przetwarzania zespoªowego, oraz analiza mo»liwo±ci zapisu scenariuszy negocjacyjnych w postaci formalnego j zyka WS-CDL. W ramach pracy przeprowadzono eksperymenty maj ce na celu zbadanie wpªywu scenariuszy na wynik negocjacji przeprowadzanych w internecie. W eksperymentach negocjacyjnych brali udziaª ludzie oraz agenty software'owe symuluj c heterogeniczne ±rodowisko wirtualne spotykane w Internecie. W ramach pracy dowodzi si nast puj cych tez: 1. Okre±lone parametry jako±ciowe dobrze opisuj przebieg i wyniki wykonania ró»nych scenariuszy realizacji przedsi wzi. 2. Negocjacje s podstaw realizacji przedsi wzi i mog by wyra»one

6 1.2. NAJWA NIEJSZE POJ CIA 5 za pomoc standardu opisu choreograi Web Services Choreography Description Language (WS-CDL). 3. Istnieje mo»liwo± doboru scenariuszy realizacji przedsi wzi cia jak i platform po±rednicz cych zapewniaj cych wzrost skuteczno±ci realizacji przedsi wzi. 1.2 Najwa»niejsze poj cia W zwi zku z podj t w pracy tematyk nale»y zdeniowa i u±ci±li szereg poj zwi zanych z przetwarzaniem zespoªowym w Internecie. Najwa»niejsze u»ywane poj cia i oznaczenia zostaªy dla porz dku przytoczone w tym podrozdziale. Przetwarzanie zespoªowe deniuje si jako zgodne rozwi zywanie pewnego problemu przez zespóª ludzi lub komputerów, w którym ka»da z uczestnicz cych jednostek wnosi do zespoªu inne umiej tno±ci lub zasoby. Integraln cz ±ci przetwarzania zespoªowego s negocjacje, rozumiane jako proces, w którym przynajmniej dwie strony dyskutuj pewne zagadnienia w celu znalezienia najlepszego rozwi zania pojawiaj cego si problemu. W negocjacjach mo»na stosowa ró»ne style negocjacji. Typowo wyró»- nia si pi podstawowych stylów negocjacji [44], jednak w literaturze stosuje si ró»ne nazewnictwo dla podstawowych stylów negocjacji [60, 51, 61]. W tej pracy poszczególne style negocjacji okre±la si nast puj cymi nazwami: rywalizacyjny polega na próbie przeforsowania swojej pozycji i swoich» da«, bez zwracania uwagi na potrzeby partnera; rywalizacyjno-kooperacyjny poª czenie stylów: kooperacyjnego i rywalizacyjnego; kooperacyjny (integratywny) polega na próbie stosowania obiektywnej argumentacji w celu osi gni cia satysfakcjonuj cego porozumienia dla obydwu stron;

7 1.2. NAJWA NIEJSZE POJ CIA 6 dostosowuj co-kooperacyjny poª czenie stylów: kooperacyjnego i dostosowuj cego si ; dostosowuj cy si polega na ci gªym ust powaniu partnerowi w celu unikni cia koniktu. Negocjacje, które odbywaj si przy pomocy cyfrowych mediów elektronicznych nazywa si e-negocjacjami. W ±rodowiskach naukowych zajmuj cych si biznesem i informatyk bardzo cz sto poj cie usªugi jest rozumiane w ró»ny sposób [6]. W biznesie poprzez usªugi rozumie si akty prawne, procesy lub dziaªania o charakterze niezycznym, tj. nie b d cych przedmiotem czy dobrem. We wspóªczesnej informatyce usªugi rozumiane s najcz ±ciej jako aplikacje udost pniaj ce swoj funkcjonalno± przez internet, najcz ±ciej implementowane w postaci usªug sieciowych. Dodatkowo termin e-usªuga najcz ±ciej jest interpretowany jako usªuga maj ca znaczenie biznesowe. W tej pracy termin usªuga jest u»ywany w znaczeniu procesu lub dziaªania o charakterze niezycznym udost pnianego osobom trzecim do u»ytkowania. Do okre±lania usªug w znaczeniu informatycznym, w szczególno±ci w znaczeniu tzw. web services [16, 30], w tej pracy stosowany jest termin usªuga sieciowa. Przez scenariusz przetwarzania zespoªowego okre±la si kolejno± dziaªa«jakie musz by wykonane w celu realizacji pewnego, okre±lonego przedsi wzi cia. Takimi dziaªaniami mog by : przesªanie wiadomo±ci (komunikatu), wykonanie pewnej usªugi lub, w przypadku przedsi wzi elektronicznych, wykonanie okre±lonego zestawu usªug sieciowych. Scenariusze przetwarzania zespoªowego nie musz by opisywane sekwencyjnie. Mog zawiera rozgaª zienia warunkowe i p tle. Scenariusze negocjacyjne opisuj wyª cznie negocjacje jako cz ± wi kszego przedsi wzi cia zespoªowego lub jako autonomiczn encj. W pracy, zamiennie do poj cia scenariusz negocjacyjny, stosuje si te» okre±lenie protokóª negocjacyjny, które mo»na spotka w literaturze, a który jest w wi kszo±ci przypadków deniowane podobnie.

8 1.2. NAJWA NIEJSZE POJ CIA 7 Uczestnikami rozproszonych przedsi wzi zespoªowych, w tym negocjacji mog by zarówno ludzie jak i systemy lub programy komputerowe. Dlatego w literaturze dotycz cej e-negocjacji poj cie agent stosuje si zarówno do uczestników programowych (software'owych) jak i uczestników b d cych lud¹mi. Z tego powodu, je±li w pracy jest stosowana odmiana sªowa agent: agenci to oznacza to zarówno autonomiczne programy komputerowe jak i ludzi, a je±li jest stosowana forma agenty to dotyczy ona wyª cznie programów komputerowych, które mog ale nie musz by mobilne. Negocjatorzy w trakcie negocjacji omawiaj okre±lony zestaw zagadnie«negocjacyjnych. S one okre±lane niezale»nie dla ka»dych negocjacji i s powi zane bezpo±rednio z obiektem negocjacji. W przypadku negocjacji handlowych zagadnieniami negocjacji mog by takie elementy kontraktu jak cena czy termin dostawy. W trakcie negocjacji negocjatorzy wymieniaj si» daniami, prezentuj c w ten sposób swoje stanowisko. Jedna wymiana informacji dotycz cych swojego stanowiska w negocjacjach lub zmian tego stanowiska jest nazywana krokiem negocjacji. W ramach pracy wykonano wiele eksperymentów negocjacyjnych rozumianych jako przeprowadzenie w kontrolowanym ±rodowisku negocjacji z udziaªem ludzi. Do eksperymentu negocjacyjnego zaliczono: przeprowadzenie negocjacji na okre±lony temat oraz wypeªnienie ankiet subiektywnej oceny przebiegu i wyników negocjacji przez uczestników negocjacji. Ka»dy taki eksperyment negocjacyjny byª pó¹niej analizowany i oceniany przy pomocy systemu komputerowego Wykaz najwa»niejszych oznacze«i skrótów Poni»ej umieszczony jest wykaz najwa»niejszych i najcz ±ciej stosowanych w pracy oznacze«i skrótów. Najwa»niejsze oznaczenia: P zbiór negocjatorów;

9 1.2. NAJWA NIEJSZE POJ CIA 8 I liczba negocjatorów, maª liter i oznaczany jest numer negocjatora; G zbiór zagadnie«negocjacji; J liczba zagadnie«negocjacji, maª liter j oznaczany jest numer zagadnienia negocjacji; D historia negocjacji w postaci zbioru listy» da«podawanych w kolejnych krokach negocjacji; K liczba kroków negocjacji, maª liter k oznaczany jest numer kroku negocjacji; v i k,j warto±» dania i-tego negocjatora podana w k-tym kroku negocjacji i dotycz ca j-tego zagadnienia negocjacji; min i j i max i j warto±ci okre±laj ce przedziaª akceptowalnych warto±ci dla j- tego zagadnienia negocjacji dla i-tego negocjatora; bv j warto± reprezentuj ca ±rodek przedziaªu zgodno±ci akceptowalnych warto±ci j-tego zagadnienia negocjacji dla pary negocjatorów, traktowana jako najlepszy wynik negocjacji z punktu widzenia obydwu negocjatorów; sk bv,j skuteczno± negocjacji okre±lana wzgl dem warto±ci bv j z punktu widzenia jednego, j-tego zagadnienia negocjacji; w i j waga j-tego zagadnienia negocjacji dla i-tego negocjatora; sk bv ±rednia wa»ona skuteczno± negocjacji okre±lana wzgl dem warto±ci bv j dla wszystkich zagadnie«negocjacji ª cznie; ef efektywno± negocjacji; st styl negocjacji; p(v) prawdopodobie«stwo wylosowania okre±lonej warto±ci» dania dla danego zagadnienia negocjacji (stosowane w algorytmie negocjuj cym);

10 1.2. NAJWA NIEJSZE POJ CIA 9 K symbol oznaczaj cy kupuj cego w negocjacjach handlowych; S symbol oznaczaj cy sprzedaj cego w negocjacjach handlowych; Najwa»niejsze skróty: SOA Service Oriented Architecture architektura zorientowana na usªugi, oparta na standardach zwi zanych z usªugami sieciowymi (web services); WS-CDL Web Services Choreography Description Language standard opisu choreograi zaproponowany przez World Wide Web Consortium; BPEL Web Services Business Process Execution Language standard opisu orkiestracji zaproponowany przez organizacj OASIS; UML Unied Modeling Language ustandaryzowany j zyk modelowania stosowany w in»ynierii oprogramowania zaproponowany przez organizacj Object Management Group;

11 Rozdziaª 2 Wªasno±ci i strategie przetwarzania zespoªowego Negocjacje s cz ±ci wielu przedsi wzi zespoªowych, zarówno tych które odbywaj si w ±wiecie rzeczywistym jak i tych realizowanych w caªo±ci lub cz ±ciowo w Internecie. E-negocjacje deniuje si jako proces negocjacji, który jest realizowany przy pomocy mediów elektronicznych wykorzystuj cych cyfrowe kanaªy do transmisji informacji [35]. Istnieje wiele koncepcji klasy- kacji systemów e-negocjacyjnych w zale»no±ci od zasi gu systemu, zakresu jego dziaªania, wykorzystywanych mediów elektronicznych itd. Te aspekty, jak i rola systemu e-negocjacyjnego w wi kszych przedsi wzi ciach zespoªowych, wpªywaj na metodologi ich wytwarzania [93, 85]. Powtarzaj cym si problemem w takich systemach jest ich maªa elastyczno±. Dlatego proponuje si u»ywanie ró»nych j zyków opisu przetwarzania zespoªowego, w tym negocjacji, do podwy»szenia jako±ci systemów komputerowych wspieraj cych prac zespoªow. Do opisu scenariuszy przetwarzania zespoªowego mo»na u»y jednego z j zyków opisu choreograi lub orkiestracji. Ka»dy z nich ma inny zakres przydatno±ci i ka»dy uwzgl dnia inny poziom abstrakcji opisywanego scenariusza, dlatego wa»ne jest, by dobra odpowiedni j zyk do konkretnych zastosowa«. 10

12 2.1. RODOWISKA E-NEGOCJACYJNE rodowiska e-negocjacyjne Jednym z podstawowych zada«systemów e-negocjacyjnych jest zapewnienie elektronicznego medium komunikacyjnego. Do systemów zapewniaj cych elektroniczne medium do negocjacji zaliczamy zarówno systemy, które umo»- liwiaj podstawowe mechanizmy komunikacji pomi dzy negocjatorami ( , czat) [73], jak i bardziej zªo»one systemy b d ce multimedialnymi platformami komunikacyjnymi, czy tzw. e-rynkami (np. serwisy aukcyjne i in.) Systemy e-negocjacyjne mo»na podzieli na lokalne i internetowe [36]. W±ród lokalnych systemów wspomagaj cych negocjacje wyró»niamy systemy wspieraj ce proces przeprowadzania negocjacji, systemy wspomagaj ce procesy podejmowania decyzji, systemy z baz wiedzy i systemy agentowe. Do internetowych systemów wspieraj cych negocjacje i e-biznes dodatkowo zaliczamy systemy komunikacyjne, wirtualne tablice ofert i e-rynki [37]. Dodatkowo systemy e-negocjacyjne mo»na podzieli na: systemy wspomagaj ce proces przygotowywania si do negocjacji, w tym systemy wspomagaj ce planowanie i systemy szacuj ce wyniki kilku alternatywnych dróg post powania; systemy wspomagaj ce proces negocjacji, w tym systemy wspomagaj - ce proces podejmowania decyzji w trakcie trwania negocjacji i systemy zarz dzaj ce procesem negocjacji. Interfejs u»ytkownika systemu e-negocjacyjnego mo»e by w peªni sformalizowany, caªkowicie dowolny lub mieszany. W peªni sformalizowany pozwala wyª cznie podawa oferty w postaci danych w formacie ustalonym przez system. Interfejs dowolny pozwala na negocjowanie w j zyku naturalnym (np. za pomoc czatu) [39]. Systemy wspomagaj ce e-negocjacje mog dziaªa w kilku podstawowych konguracjach [34]: 1. Negocjatorzy korzystaj z jednego systemu wspieraj cego negocjacje,

13 2.1. RODOWISKA E-NEGOCJACYJNE 12 który korzysta z systemu danych domenowych (dane opisuj ce problemy negocjacyjne itp.); 2. Ka»dy negocjator korzysta ze swojego systemu wspieraj cego negocjacje, co pozwala na to, by ka»dy uczestnik negocjacji mógª dostarcza dodatkowe dane do systemu, które s znane tylko lokalnie; 3. Ka»dy negocjator korzysta ze swojego systemu wspieraj cego negocjacje, ale systemy poszczególnych uczestników s poª czone przez dodatkowy, globalny system wspieraj cy i zarz dzaj cy negocjacjami. Metodologia negocjacji opisuje metody, procedury i techniki gromadzenia i analizowania informacji u»ywanych podczas negocjacji, proces komunikacji, wymian ofert i czynione ust pstwa oraz wynik negocjacji w postaci kontraktu lub jego braku. Wa»ne jest, by metodologia negocjacji u»ywana w systemie e-negocjacyjnym odpowiadaªa umiej tno±ciom i potrzebom negocjatorów [41]. Przy tworzeniu wirtualnych ±rodowisk nale»y zwróci uwag na trzy podstawowe aspekty: form, funkcj i zachowanie (sposób dziaªania) [81]. Forma okre±la struktur wirtualnego ±wiata, funkcja okre±la obiekty i ich dziaªanie a zachowanie deniuje zmiany w funkcjonowaniu obiektów w czasie, czyli scenariusze ich zachowa«. Dotyczy to nie tylko systemów e-negocjacyjnych, ale równie» szerszej klasy systemów, w których w interakcje wchodzi wielu u»ytkowników. Przy tworzeniu systemów e-negocjacyjnych nale»y uwzgl dni dwie kategorie modeli: dotycz cy problemów negocjacyjnych oraz dotycz cy procesów negocjacyjnych. Modele dotycz ce problemów negocjacyjnych dotycz sposobu opisu zagadnie«negocjacji oraz wiedzy powi zanej z problemem i ±rodowiskiem negocjacji. Modele dotycz ce procesów negocjacyjnych zajmuj si opisywaniem zasad przeprowadzania negocjacji i realizacji kontraktów. W obydwu przypadkach nale»y uwzgl dni kilka podstawowych elementów, które przedstawione s w tabeli 2.1. Nale»y zwróci uwag na to,»e cho wiele elementów modeli problemu

14 2.1. RODOWISKA E-NEGOCJACYJNE 13 Tabela 2.1: Punkty widzenia negocjacji Elementy Punkty widzenia modelu modelu Problem negocjacyjny Proces negocjacyjny Uczestnicy decydent, zleceniodawca, negocjatorzy, zleceniodawcy agent agenci, strony trzecie Charakterystyki Preferencje, stosunek do ryzyka, pozycja, styl, kultura, niezale»no±, typ negocjatorów (ludzie czy agenty) Role Analiza, wybór, ocena, doradztwo Teorie Modele problemów Problem i modele ust pstw Frameworki Modele wyborów Modele argumentacji Modele Modele ekspertowe Modele ekspertów negocjacyjnego i procesu negocjacyjnego jest wspólna, to wyst puj pomi dzy nimi konkretne ró»nice. Wpªywa to bezpo±rednio na proces tworzenia systemów e-negocjacyjnych, które najcz ±ciej musz uwzgl dni obydwa modele. Przykªadowo, w modelowaniu problemu negocjacyjnego uczestnicy s rozumiani jako strony negocjacji, które mog by równie» instytucjami itp. W przypadku modelu procesów negocjacyjnych uczestnicy to agenci (reprezentanci poszczególnych stron), którzy bior udziaª w negocjacjach. Poza uwzgl dnieniem modelu ±wiata i procesów zwi zanych z negocjacjami, które chcemy przenie± do ±rodowiska elektronicznego, nale»y rozwa»y stosowalno± ró»nych mediów komunikacyjnych. W systemach e-negocjacyjnych denicj medium komunikacyjnego stosuje si do caªo±ci systemu informatycznego, który zapewnia mo»liwo± komunikacji pomi dzy agentami rozumianymi zarówno jako ludzi, jak i specjalizowane programy komputerowe [56, 57]. Podsumowuj c, media elektroniczne modeluje si jako zbiór nast puj - cych elementów: logik reprezentuje informacje: zarówno fakty jak i procedury przechowywane w sposób formalny, który pozwala je wykorzysta do automatycznego wnioskowania;

15 2.1. RODOWISKA E-NEGOCJACYJNE 14 Tabela 2.2: Wpªyw sytuacji na potrzeby negocjacyjne Sytuacja pewna niepewna nieanalizowalna peªne medium peªne medium komunikacyjne, komunikacyjne, maªo informacji du»o informacji analizowalna ograniczone medium ograniczone medium komunikacyjne, komunikacyjne, maªo informacji du»o informacji agentów czyli encje, które posiadaj mo»liwo± przetwarzania i przechowywania informacji oraz reagowania na zdarzenia. Agentem mo»e by zarówno czªowiek jak i specjalizowany program komputerowy; kanaªy umo»liwiaj komunikacj pomi dzy agentami; organizacj zbiór ról i protokoªów oraz ich dozwolone kombinacje; elementy ±wiata jakie elementy ±wiata rzeczywistego dane medium reprezentuje. Za form komunikacji odpowiadaj kanaªy komunikacyjne, które mo»na podzieli pod wzgl dem ekspresywno±ci ±rodków przekazu na trzy podstawowe kategorie: tekstowe, gªosowe i wideo [17]. Zale»nie od problemu potrzebne s kanaªy o ró»nych poziomach ekspresywno±ci ±rodków przekazu. Mo»emy wyró»ni cztery kategorie sytuacji przedstawione w tabeli 2.2. Sytuacja, w której dane s nieanalizowalne oznacza,»e dane potrzebne do rozwi zania problemu s niestandardowe (nieustandaryzowane) lub bardziej osobistej natury, wi c nie jest znany algorytm, który pozwoliªby na automatyczn lub póªautomatyczn analiz tych danych. Sytuacja niepewno±ci oznacza tak sytuacj, w której organizacja nie posiada peªnej informacji, niezb dnej do ci gªego dziaªania i wspóªdziaªania ze swoim ±rodowiskiem, co mo»e by wynikiem nowej sytuacji i zwi zanego z tym braku do±wiadczenia, zmieniaj cego si ±rodowiska itp. Badania pokazuj,»e im bardziej niestandardowa sytu-

16 2.1. RODOWISKA E-NEGOCJACYJNE 15 acja jest brana pod uwag, tym wi ksza ekspresywno± ±rodków przekazu jest potrzebne. Z eksperymentów przeprowadzonych przez Y. Yuan [103] wynika,»e kana- ªy komunikacyjne o wi kszej ekspresywno±ci przekazu daj wra»enie lepszej efektywno±ci negocjacji. Jednak warunkiem pozytywnego wra»enia zwi zanego z korzystaniem z tych mediów jest odpowiednio szeroki kanaª komunikacyjny, który nie b dzie wprowadzaª zakªóce«takich jak przerywany d¹wi k, skacz cy obraz itp. Mo»na te» zaobserwowa,»e peªniejszy kanaª komunikacyjny nie musi wpªywa w znacz cy sposób na skuteczno± negocjacji, np. dodanie opcji u»ywania gªosu w trakcie negocjacji jest odbierane pozytywnie, ale dodanie do tego obrazu video ju» jest odbierane negatywnie (bardzo cz sto kr puje i rozprasza negocjatorów) Taksonomia e-negocjacji Do klasykowania e-negocjacji i systemów e-negocjacyjnych mo»na zastosowa taksonomi montrealsk [93]. W tej taksonomii zakªada si,»e e- negocjacje przebiegaj pomi dzy co najmniej dwoma agentami rozumianymi zarówno jako ludzie, organizacje, jak i autonomiczne programy. Taksonomia montrealska uwzgl dnia sytuacje, w których proces negocjacji jest ograniczony co najmniej jednym warunkiem, który wpªywa na proces podejmowania decyzji i jest narzucony przez elektroniczne medium wykorzystywane w negocjacjach. Wyklucza to systemy e-negocjacyjne, które zapewniaj jedynie kanaªy komunikacyjne do zdalnych negocjacji, czyli np. negocjacje ludzi przez czat nie podlegaj klasykacji przy pomocy tej taksonomii. Taksonomia montrealska wykorzystuje poj cia z referencyjnego modelu mediów dla elektronicznych rynków (MRM) [85], który identykuje mi dzy innymi podstawowe fazy interakcji w e-negocjacjach: 1. zbieranie informacji o produktach i graczach na elektronicznym rynku; 2. wyra»anie swoich intencji w postaci ofert kupna, sprzeda»y itp.;

17 2.1. RODOWISKA E-NEGOCJACYJNE doj±cie do porozumienia, czyli jednoznaczne zidentykowanie warunków kontraktu i jego podpisanie; 4. realizacj kontraktu. Z punktu widzenia e-negocjacji najwa»niejsze s etapy 2 i 3, które mog nast powa po sobie wielokrotnie, dopóki nie dojdzie do zawarcia porozumienia. W tych fazach wa»n rol odgrywa scenariusz negocjacji rozumiany jako zestaw reguª, do których musz stosowa si agenci (e-negocjatorzy). Taksonomia montrealska wyró»nia dwa ortogonalne podziaªy kryteriów klasykacji e-negocjacji: zewn trzne i wewn trzne; sprecyzowane i wywiedzione ze ±rodowiska e-negocjacji. Kryteria zewn trzne wynikaj ze ±wiata rzeczywistego, którego fragment jest modelowany medium elektronicznym. Kryteria wewn trzne wynikaj z architektury systemu e-negocjacyjnego i ogranicze«jakie ten system zakªada. Wiele kryteriów zaproponowanych w taksonomii montrealskiej dotyczy przede wszystkim e-rynków, ale wi kszo± z nich ma zastosowania do dowolnych systemów e-negocjacyjnych. Ze wzgl du na uwzgl dnienie e-rynków, zakªada si,»e medium elektroniczne do negocjacji mo»e pozwala na jednoczesne wspóªdziaªanie wielu konkuruj cych ze sob stron, co implikuje stosowanie algorytmów doboru i klasykacji dost pnych ofert. Tabela 2.3 przedstawia kryteria zewn trzne sprecyzowane zaproponowane w taksonomii montrealskiej. Podzielone s one na dwie kategorie: kryteria zwi zane z domen biznesow i kryteria zwi zane z modelem biznesowym. Kryteria zwi zane z domen biznesow okre±laj co jest reprezentowane przez negocjuj cych agentów, czy s to rmy czy pojedyncze osoby itp. Model biznesowy okre±la w jakiej formie oferowane s usªugi b d¹ produkty, co ma wpªyw m.in. na to, czy strategie negocjacji nale»y wybiera pod k tem wielorazowych kontaktów czy tylko jednorazowych. Wszystkie te kryteria s jednoznacznie okre±lone i skªadaj si na denicj problemu negocjacyjnego.

18 2.1. RODOWISKA E-NEGOCJACYJNE 17 Tabela 2.3: Taksonomia montrealska: kryteria zewn trzne sprecyzowane Domena biznesowa Okre±la relacje mi dzyagentowe, np. czy agenci reprezentuj pojedyncze osoby czy organizacje, czy reprezentowane jednostki dzia- ªaj w imieniu organizacji publicznych, rm itp. Model biznesowy Okre±la czy negocjowane dobra b d¹ usªugi maj charakter ci gªy, abonamentowy, lub s to jednorazowe zobowi zania. Tabela 2.4: Taksonomia montrealska: kryteria zewn trzne wywiedzione Domena biznesowa Zagadnienia zwi zane z kultur spoªeczn obowi zuj c na danym e-rynku, zasady etyczne itp. Model biznesowy Misja negocjatorów, cele strategiczne, ¹ródªa zysku itp. W tabeli 2.4 znajduj si dodatkowe kryteria, które wynikaj z ró»norodnych warunków ±wiata rzeczywistego. W±ród nich nale»y zwróci uwag na takie aspekty, jak kultura biznesowa panuj ca w danym kraju, zagadnienia prawne itp. Dodatkowo znaczenie ma równie» dªugoterminowy cel biznesowy negocjatorów. Wszystkie te aspekty maj wpªyw na to, w jaki sposób powinien zosta skonstruowany system e-negocjacyjny. Tabela 2.5 przedstawia kryteria wewn trzne sprecyzowane, czyli wynikaj ce bezpo±rednio z medium e-negocjacyjnego. Mo»na je podzieli na szereg kategorii zwi zanych z: rolami, czyli w jaki sposób strony negocjacji s reprezentowane w systemie; zasadami negocjacji, które decyduj o dost pnych aktywno±ciach w czasie negocjacji;

19 2.1. RODOWISKA E-NEGOCJACYJNE 18 sposobem specykacji ofert i ich strukturze; sposobem prezentacji ofert uczestnikom e-negocjacji; sposobem analizy ofert jaki wykonuj agenci lub system e-negocjacyjny, je±li peªni rol mediatora; sposobem doboru ofert w przypadkach, gdy system e-negocjacyjny reprezentuje e-rynek z wieloma niezale»nymi uczestnikami, którzy nie s a priori poª czeni w pary. Dotyczy to przede wszystkim wszelkich systemów aukcyjnych, gdzie najcz ±ciej medium negocjacyjne dokonuje wst pnej klasykacji ofert; sposobem alokacji ofert, czyli czy pod wzgl dem dost pno±ci i atrakcyjno±ci ofert mo»liwe jest zró»nicowanie agentów w systemie e-negocjacyjnym; dost pno±ci informacji w systemie; strategi dotycz ca kontroli zachowania agentów. Tabela 2.5: Taksonomia montrealska: kryteria wewn trzne sprecyzowane Role Uczestnicy Liczba i typ uczestników. Czy wszyscy uczestnicy s negocjatorami, czy który± z uczestników peªni rol mediatora. Agenci Ilu agentów przypada na ka»d ze stron negocjacji. Dost pno± Czy ka»dy agent mo»e wzi udziaª w negocjacjach, lub czy dost p do negocjacji jest ograniczony. Identykacja Czy agenci s anonimowi, czy mo»na ich jednoznacznie zidentykowa. Wspóªpraca Czy dozwolona jest wspóªpraca pomi dzy agentami, lub czy agenci mog tylko ze sob konkurowa.

20 2.1. RODOWISKA E-NEGOCJACYJNE 19 Wariacje Rundy Etapy Wspóªbie»no± Zagadnienia negocjacji Warto±ci zagadnie«negocjacji Elastyczno± ofert Struktura ofert Zasady ogólne procesu negocjacji Czy zasady rz dz ce procesem negocjacji s staªe, czy mog si zmienia w trakcie negocjacji. Je±li mog si zmienia, to jaki jest zakres dozwolonych zmian. Ile razy mo»e by powtarzany proces negocjacji w celu osi gni cia pojedynczego porozumienia Je±li zasady negocjacji s niezmienne, to mamy do czynienia z negocjacjami jednoetapowymi. Je±li zasady negocjacji mog si zmienia, to przyjmuje si,»e ka»da zmiana zasad jest pocz tkiem nowego etapu. Czy jeden agent mo»e bra udziaª w wielu negocjacjach jednocze±nie. Specykacja ofert Ile jest zagadnie«negocjacji i czy ich liczba jest staªa. Czy warto± zagadnie«negocjacji okre±la pojedyncza warto± czy przedziaª warto±ci. Czy agenci mog informowa o zakresie warto±ci danego zagadnienia negocjacji, którym s zainteresowani. Czy struktura kolejnych ofert jest: niezmienna; podlega wcze±niej zdeniowanym zmianom; jest dynamiczna. Zale»no± pomi dzy ofertami Czy ka»da oferta skªadana przez agenta jest niezale»na od jego poprzednich ofert, lub czy istnieje pomi dzy nimi zale»no±. Czy oferty mog by skªadane równolegle, czy musz by skªadane sekwencyjnie.

21 2.1. RODOWISKA E-NEGOCJACYJNE 20 Obiekty negocjacji Strony negocjacji Pozycja agentów Aktywno± Kierunek skªadania ofert Negocjacjom mo»e podlega pojedynczy obiekt lub zestaw obiektów (np. pakiet usªug). Przedstawianie ofert Które strony negocjacji maj mo»liwo± przedstawiania ofert: tylko wyznaczone czy wszystkie. Ile ról (pozycji) mog agenci realizowa jednocze±nie. Czy aktywno± agentów jest w jaki± sposób ograniczona (np. okre±lony przedziaª czasowy, w którym mo»na skªada oferty). Okre±la, czy oferty przedstawia: sprzedaj cy (kierunek normalny); kupuj cy (kierunek odwrotny); ró»nie, zale»nie od fazy negocjacji (kierunek nieokre±lony). Warto± Próg Harmonogram Analiza ofert Okre±la kierunek zmiany warto±ci ofert: rosn cy, malej cy lub niezdeniowany. Przez warto± ofert rozumie si pewn funkcj oceniaj ca warto± oferty na podstawie wszystkich atrybutów oferty. Czy istniej progi akceptacji ofert i je±li istniej, to czy okre±laj one minimaln, czy maksymaln warto± oferty. Dobór ofert Dobór ofert mo»e odbywa si w staªych przedziaªach czasowych lub mo»e by wywoªywany zdarzeniami, lub odbywa si nieustannie (w sposób ci gªy).

22 2.1. RODOWISKA E-NEGOCJACYJNE 21 Sortowanie ofert Ocena ofert Dobór ofert Dystrybucja ofert Prowizja Konguracja Zaanga»owanie Sortowanie ofert mo»e uwzgl dnia ograniczenia na oferty zasugerowane przez ka»dego z agentów osobno lub traktowa wszystkich agentów w taki sam sposób. Dobór akceptowalnego zbioru ofert mo»e by równie» wykonywany a priori i wtedy faza sortowania ofert si nie odbywa. Oferty s szeregowane wg oceny ich akceptowalno±ci lub s listowane w dowolnej kolejno±ci (brak oceny ofert). Decyzja o doborze ofert jest wykonywana przez system e-negocjacyjny na podstawie okre±lonych reguª lub agenci decyduj o doborze ofert. Przez dobór ofert rozumie si takie ª czenie ofert w pary, by zaspokoi potrzeby uczestników e-rynku w jak najszerszym zakresie. Alokacja ofert Ka»dy z oferuj cych mo»e otrzyma inn cen lub cena jest taka sama dla wszystkich. Czy cena zaproponowana przez agenta, którego oferta zostaªa oceniona jako najlepsza jest wi» ca, czy mo-»e ulec modykacjom po zako«czeniu procesu doboru ofert. Czy agenci dokonuj wyboru ofert samodzielnie czy przez mediatora. Akceptacja ofert Czy akceptacja ofert jest wi» ca i musi si zako«czy kontraktem.

23 2.1. RODOWISKA E-NEGOCJACYJNE 22 Komunikacja Informacja Komunikacja pomi dzy agentami mo»e by : ograniczona wyª cznie do informacji o ofertach; mo»e zawiera oferty z komentarzami; pozbawiona ogranicze«. Historia transakcji Historia negocjacji Widoczno± negocjacji ladowo± Zawarto± informacyjna ofert Koordynacja Czy historia kontraktów b d cych wynikiem wcze- ±niejszych negocjacji jest dost pna dla agentów. Czy historia przebiegu bie» cych negocjacji jest dost pna dla agentów. Czy status procesu negocjacji jest znany wszystkim, czy tylko agentom bior cym udziaª w danych negocjacjach. Czy pochodzenie dost pnych informacji mo»na powi - za z konkretnym agentem (agent mo»e nadal zachowa anonimowo± ). Czy caªo± ofert jest dost pna czy tylko wybrane elementy ofert s widoczne. Informacje mog by ujawniane i aktualizowane: w okre±lonych odst pach czasu; w wyniku wyst pienia okre±lonych zdarze«; natychmiastowo. Opªaty Strategia Czy agenci s opªacani za reprezentowanie klientów i jakie s zasady pobierania tych opªat.

24 2.2. SCENARIUSZE PRZETWARZANIA ZESPOŠOWEGO 23 Arbitracja Jakie s zasady dotycz ce kontroli przestrzegania scenariusza i zasad negocjacji: karanie za naruszenie scenariusza lub zasad; nagrody za przestrzeganie scenariusza i zasad; odrzucanie akcji niezgodnych ze scenariuszem negocjacji. Ranking Czy agenci s oceniani i podlegaj rankingowi. Tabela 2.6 przedstawia kryteria wewn trzne wywiedzione, które okre±laj cechy wynikaj ce nie z projektu systemu e-negocjacyjnego, ale ze sposobu dziaªania algorytmów zastosowanych w systemie e-negocjacyjnym. Dotyczy to m. in. stosowanych algorytmów doboru ofert, algorytmów agentów programowych itd. 2.2 Scenariusze przetwarzania zespoªowego Wspóªcze±nie realizacja ró»norakich przedsi wzi ludzkich wymaga pracy w zespole. Przyjmuje si,»e zespóª tworzy grupa ludzi, na ogóª niewielka, posiadaj ca komplementarne umiej tno±ci potrzebne do realizacji pewnego okre±lonego celu (przedsi wzi cia). Wa»nym zagadnieniem jest, w jaki sposób organizowa zespoªy ludzkie, by uzyska najlepsze wyniki ich dziaªa«. Wiadomo,»e na wynik pracy zespoªu wpªywa wiele czynników: s to nie tylko aspekty psychologiczne, ale przede wszystkim aspekty organizacyjne. Zastosowanie odpowiedniego scenariusza pracy zespoªowej (przetwarzania zespoªowego) mo»e mie decyduj ce znaczenie w osi gni ciu sukcesu. Przy realizacji zada«zespoªowych wprowadza si procedury dotycz ce raportowania, rozwi zywania koniktów, oceny post pów, szeregowania zada«i in. Te procedury s form scenariuszy, które dotycz sytuacji maj cych

25 2.2. SCENARIUSZE PRZETWARZANIA ZESPOŠOWEGO 24 Tabela 2.6: Taksonomia montrealska: kryteria wewn trzne wywiedzione Optymalno± Pareto Czy d»y si do optymalno±ci wyników w znaczeniu pareto-optymalno±ci. Wynik negocjacji jest pareto-optymalny je±li nie istnieje»aden inny wynik, który nie spowoduje pogorszenia warunków kontraktu dla dowolnego z agentów. Maksymalizacja Czy wyniki negocjacji maksymalizuj sum funkcji wyniku negocjacji wyniku negocjacji wszystkich negocjatorów. Sprawiedliwo± Czy wynik negocjacji nie daje wi kszych korzy±ci jednemu z agentów kosztem innych. Zbie»no± Czy proces negocjacji jest zbie»ny i jak szybko. Stabilno± Czy wynik negocjacji osi gni ty w ±rodowisku e- negocjacyjnym jest tak samo dobry jak wynik negocjacji mo»liwy do osi gni cia poza tym ±rodowiskiem. Prawdziwo± zachowa«czy agenci wyra»aj wyª cznie prawd o swoich preferencjach i potrzebach. Natura zysków Czy negocjacje przeprowadzane w ±rodowisku e- negocjacyjnym s gr o sumie zerowej, czy reprezentuj sytuacj wygrany wygrany (win win).

26 2.2. SCENARIUSZE PRZETWARZANIA ZESPOŠOWEGO 25 Rysunek 2.1: Elementy dziaªalno±ci zespoªu du»e znaczenie w przedsi wzi ciu zespoªowym. W systemach informatycznych przetwarzanie zespoªowe to przetwarzanie rozproszone, do którego wª czone jest uwzgl dnianie ludzkich decyzji w trakcie trwania procesu przetwarzania. Rysunek 2.1 przedstawia podstawowe elementy dziaªalno±ci zespoªu. Scenariusze przetwarzania zespoªowego powstaj jako wynik ustalenia zasad kooperacji czªonków zespoªu i pozwalaj koordynowa ich prac. Gªównym narz dziem koordynacji jest komunikacja, czyli przekazywanie informacji zarówno dotycz cych samego zadania, jak i informacji potrzebnych do synchronizacji dziaªa«czªonków grupy [48, 66]. Dodatkowo deniuje si poj cie wirtualnych zespoªów jako zdolno± uczestników przedsi wzi cia, znajduj cych si w odlegªych geogracznie lokacjach, do wspóªpracy z wykorzystaniem systemów komputerowych zapewniaj cych ±rodki komunikacji i koordynacji dziaªa«[71]. Wspóªprac deniuje si jako proces w którym, dwoje lub wi cej osób wchodz mi dzy sob w interakcj w celu uzyskania lepszego zrozumienia pewnego problemu [86], d» c do jego rozwi zania.

27 2.2. SCENARIUSZE PRZETWARZANIA ZESPOŠOWEGO 26 Scenariusze przetwarzania zespoªowego cz sto przyjmuj form workow lub serviceow, w których bazowym modelem wspóªpracy jest model peer to peer. Przedstawione dalej j zyki opisu scenariuszy przetwarzania zespoªowego bazuj na tym modelu wspóªpracy i skupiaj si przede wszystkim na aspektach koordynacyjnych i komunikacyjnych przetwarzania zespoªowego. Spo±ród aspektów koordynacyjnych s to: kolejno± i warunki przesyªania komunikatów, obsªuga zdarze«i sytuacji wyj tkowych oraz aspekty synchronizacyjne. Aspekty komunikacyjne to j zyki przetwarzania zespoªowego, które pozwalaj deniowa form i sposób dostarczania informacji. Podobnie jest w systemach e-negocjacyjnych, gdzie aspektem ograniczaj cym wi kszo± systemów jest protokóª negocjacyjny, czyli scenariusz negocjacji, który zazwyczaj jest ustalony a priori w danym systemie wspomagaj cym negocjacje. Jednak ka»da klasa problemów, które rozwi zuje si wykorzystuj c negocjacje, mo»e wymaga innego scenariusza w celu optymalnego rozwi zania problemu [38]. Protokóª negocjacyjny peªni bardzo wa»n rol w systemach e-negocjacyjnych, poniewa» od niego zale»y mo»liwo± wykorzystania okre±lonych strategii negocjacyjnych. Sam protokóª za± zale»ny jest od przyj tego modelu negocjacji. Mo»na zatem stwierdzi,»e po» danymi cechami systemów wspieraj cych negocjacje s [102]: 1. Mo»liwo± konstrukcji ró»nych scenariuszy lub protokoªów negocjacyjnych. 2. Mo»liwo± specykacji ró»nego typu problemów negocjacyjnych. 3. Tworzenie i wykorzystywanie biblioteki przypadków negocjacyjnych. Do modelowania procesów kolaboracyjnych w grupach mo»na zastosowa protokóª spoªeczny [74, 41, 102]. W tym podej±ciu grupy przechodz pomi dzy stanami, gdy jeden z uczestników o odpowiedniej roli wykona okre±lone dziaªanie. Ka»da grupa posiada funkcj φ, która okre±la, jak bardzo poszczególne przej±cia pomi dzy stanami s po» dane. Takimi stanami mog by np. oczekiwanie na propozycj, oczekiwanie na odpowied¹ itp. Funkcja

28 2.2. SCENARIUSZE PRZETWARZANIA ZESPOŠOWEGO 27 φ dla przej±cia ze stanu oczekiwanie na odpowied¹ do stanu otrzymano odpowied¹ mo»e wynosi 1 a ze stanu oczekiwanie na odpowied¹ do stanu brak odpowiedzi mo»e wynosi 0,2 co oznacza,»e preferowane jest pierwsze przej±cie. Z punktu widzenia negocjatorów najwa»niejszymi elementami systemu e-negocjacyjnego s dost pne aktywno±ci [39]. Aktywno±ci mog by szeregowane tworz c scenariusze negocjacyjne. Aktywno±ci mog by reprezentowane przez komponenty programowe, zapewniaj ce mo»liwo± ich realizacji. Mo»na w ten sposób zamodelowa dowolny scenariusz, który b dzie wykonywany przez odpowiednie sekwencje komponentów. Idealnie nadaje si do tego architektura zorientowana na usªugi (Service Oriented Architecture SOA) [90]. Komponenty programowe reprezentuj ce aktywno±ci mog by oferowane w postaci usªug sieciowych [13]. SOA ma na celu przede wszystkim wykorzystanie istniej cych rozwi za«biznesowych dodaj c elastyczno± wymagan przy adopcji rozwi - za«informatycznych do nowych potrzeb [47]. Proponuje si nawet stworzenie uniwersalnych zestawów usªug sieciowych do negocjacji [14]. W konstrukcji platform e-negocjacyjnych wyró»nia si dwa typy modeli: model procesów i protokóª [42, 45]. Model procesów sªu»y opisaniu faz negocjacji i przypisywaniu zdeniowanych aktywno±ci do okre±lonych faz negocjacji. Przez protokóª negocjacyjny rozumie si model, który zarz dza procesami negocjacyjnymi, mo»liwo±ciami komunikacyjnymi zapewnianymi przez system e-negocjacyjny i nakªada ograniczenia dotycz ce mo»liwych aktywno±ci negocjatorów. Protokoªy negocjacyjne mo»na podzieli na kilka podstawowych typów [38]: uwzgl dniaj c stabilno± reguª: zamkni te wszystkie reguªy s ustalane a priori i nie mo»na ich zmienia w trakcie negocjacji; otwarte reguªy mog by dodawane w trakcie negocjacji; uwzgl dniaj c stosunki pomi dzy uczestnikami negocjacji:

29 2.2. SCENARIUSZE PRZETWARZANIA ZESPOŠOWEGO 28 prywatne steruje aktywno±ciami uczestników i deniuje mo»liwe akcje; publiczne deniuje zasady komunikacji pomi dzy uczestnikami; uwzgl dniaj c elastyczno± protokoªu: ogólne mo»liwe do zastosowania dla wielu typów negocjacji; specjalizowane nadaj ce si do zastosowania do jednego lub niewielu typów negocjacji. Ka»dy protokóª e-negocjacyjny powinien by skonstruowany w taki sposób, by speªniaª nast puj ce postulaty [38]: spójno± wej±ciowa wszystkie dost pne informacje s uwzgl dniane; przezroczysto± uczestnicy s w stanie zrozumie zasady dziaªania systemu e-negocjacyjnego; wyja±nialno± ka»da decyzja dotycz ca wyboru konkretnej aktywno±ci jest logicznie uzasadniona; celowo± cel ka»dej aktywno±ci jest jednoznacznie okre±lony; zbie»no± mo»liwe jest osi gni cie zako«czenia negocjacji; adekwatno± interakcje pomi dzy u»ytkownikami a systemem wspomagania negocjacji s wystarczaj ce do osi gni cia celu negocjacji. Mo»liwo± obsªugi wi cej ni» jednego scenariusza negocjacyjnego jest cz sto wymienian cech, jak powinny posiada platformy negocjacyjne [39, 10]. Media elektroniczne, rozumiane jako systemy e-negocjacyjne, powinny odpowiada za przebieg procesów negocjacyjnych, staj c si ±rodowiskiem po±rednicz cym i zarz dzaj cym choreogra negocjacji [5]. Do zarz dzania przebiegiem negocjacji proponuje si wysokopoziomowy j zyk orkiestracji b d¹ choreograi.

30 2.3. J ZYKI OPISU SCENARIUSZY J zyki opisu scenariuszy przetwarzania zespoªowego Problem kierowania wspóªprac wyst puje nie tylko w przypadku pracy grup ludzkich, ale równie» kiedy rozwa»amy wspóªprac systemów komputerowych. Systemy komputerowe reprezentuj ludzi i ich dziaªania w ±wiecie wirtualnym. Aktualnym problemem jest takie sterowanie wspóªprac pomi dzy systemami, by mo»liwe byªo wykonanie zªo»onych zada«, w których bierze udziaª wiele systemów oraz ludzi [9]. Dodatkowo ci gªym problemem jest mo»liwo± ªatwej reorganizacji procesów biznesowych tak, aby lepiej pasowaªy do potrzeb klientów w ci gle rozwijaj cych i zmieniaj cych si ±rodowiskach elektronicznych [72]. Dlatego tak wa»ne jest istnienie i akceptacja j zyków reprezentacji usªug biznesowych i procesów biznesowych zarówno lokalnych jak i globalnych. W celu umo»liwienia projektowania i opisywania scenariuszy wspóªpracy pomi dzy systemami powstaªo wiele j zyków. Ze wzgl du na punkt widzenia przyj ty przy opisywaniu zasad wspóªpracy, j zyki wyra»aj ce scenariusze przetwarzania zespoªowego mo»na podzieli na dwie grupy [70]: j zyki opisu orkiestracji opisuj scenariusz wspóªpracy z lokalnego punktu widzenia, czyli scenariusz dziaªania konkretnej usªugi uwzgl dniaj cy interakcje z innymi usªugami, czyli komunikacj z innymi uczestnikami przetwarzania zespoªowego. Ta forma opisu scenariusza jest wygodna do wykonania (implementacji) przez stron opisan w scenariuszu; j zyki opisu choreograi opisuj scenariusz wspóªpracy widziany z globalnego punktu widzenia, czyli przede wszystkim zasady, wg których strony wymieniaj informacje mi dzy sob. Zakªada si,»e algorytm post powania (rozumowania) stron bior cych udziaª w scenariuszu nie ma znaczenia. Znaczenie ma wyª cznie protokóª wymiany informacji potrzebny do realizacji pewnego przedsi wzi cia, czyli kontrakt opisu-

31 2.3. J ZYKI OPISU SCENARIUSZY j cy zasady wspóªpracy. Stosuj c formalny sposób zapisu mo»na dowie± spójno±ci pomi dzy zapisem reprezentuj cym choreogra a odpowiadaj cymi mu zapisami orkiestracji. Dowodzi to te»,»e ka»dy zapis choreograi mo»na przetªumaczy na odpowiadaj ce mu zapisy w pewnym j zyku orkiestracji. W [15] zaproponowano matematyczny model zapisu orkiestracji i choreograi i stwierdzono,»e przy pomocy tego zapisu mo»na zamodelowa scenariusze wyra»one w j zykach WS-CDL i BPEL. Zespoªy ludzkie pracuj ce w internecie korzystaj z systemów komputerowych. W przypadku zespoªów rozproszonych globalnie, systemy komputerowe s gªównym ±rodkiem komunikacji, a tym samym porozumiewanie si wewn trz zespoªowe jest uzale»nione od mo»liwo±ci systemów i protokoªów z jakich korzystaj. Powoduje to,»e wspóªpraca ludzi korzystaj cych z systemów komputerowych w celu komunikowania si, jest ograniczona do scenariuszy przewidzianych przez twórców tych systemów. Stworzenie systemu, który potraªby tak modykowa swoje dziaªanie, by uwzgl dni scenariusze post powania uªatwiaj ce danemu zespoªowi prac, nie jest proste. Pojawienie si formalnych, komputerowych j zyków opisu scenariuszy oraz szeroka akceptacja architektury SOA pozwalaj na realizacj tego typu aplikacji. Do wyra»ania protokoªów biznesowych bardzo dobrze nadaje si grupa specykacji opartych na usªugach sieciowych (w tym BPEL, WS-CDL) [67]. Planuj c zasady kooperacji ludzi na ogóª nie my±li si o ich implementacji w konkretnym systemie komputerowym. Realizacja tych zasad w postaci systemu komputerowego zachodzi pó¹niej, tym samym aby przeniesienie scenariusza pracy zespoªowej lub negocjacji ze ±rodowiska naturalnego do internetowego byªo jak najprostsze, wybrany j zyk opisu scenariuszy powinien mie mo»liwo± opisywania scenariuszy na ró»nym poziomie abstrakcji J zyki opisu orkiestracji Aktualnie rozwijane j zyki opisu orkiestracji s blisko zwi zane z systemami do automatyzacji procesów biznesowych (workow management systems)

32 2.3. J ZYKI OPISU SCENARIUSZY [63]. Spo±ród komputerowych j zyków opisu orkiestracji najszerzej przyj tym jest Web Services Bussiness Process Execution Language, w skrócie zwany BPEL [65]. Aktualnie istnieje wiele implementacji ±rodowisk pozwalaj cych na wykonywanie scenariuszy procesów biznesowych zapisanych w tym j zyku, a on sam jest aktywnie rozwijany. Business Process Execution Language BPEL jest j zykiem orkiestracji opieraj cym si na standardach powi zanych z usªugami sieciowymi. Jest aktywnie rozwijany w ramach organizacji OASIS, która w kwietniu 2007 roku wydaªa wersj 2.0 standardu. J zyk ten zmieniaª swoj nazw i jego aktualna peªna nazwa to: Web Services Business Process Execution Language (WS-BPEL). Ta nazwa zostaªa ustalona, by byªa zgodna z innymi standardami zaproponowanymi m.in. przez W3C. Standard ten jest równie» znany pod nazw Business Process Execution Language for Web Services (BPEL4WS). J zyk BPEL powstaª jako poª czenie wcze±niejszych pomysªów w postaci j zyków XLANG i Web Service Flow Language (WSFL) [8]. Podobnie jak inne j zyki opisu orkiestracji i choreograi, BPEL pozwala tworzy opisy scenariuszy zarówno na abstrakcyjnym poziomie, jak i na poziomie konkretnym, pozwalaj cym na wykonanie scenariusza przez systemy komputerowe. Na model j zyka BPEL skªadaj si [31]: partnerzy, którzy okre±laj jakie usªugi (mo»liwo±ci) musi speªnia partner biznesowy potrzebny do realizacji pewnego zadania. Partnerów reprezentuj w architekturze SOA usªugi sieciowe; funkcje i wyra»enia niezb dne do zapisu scenariusza i sterowania przebiegiem wykonania orkiestracji; zmienne i podstawowe operacje na zmiennych; zale»no±ci pomi dzy wymienianymi informacjami, które s u»ywane do powi zania informacji przekazywanych w kolejnych wywoªaniach bezstanowych usªug sieciowych;

33 2.3. J ZYKI OPISU SCENARIUSZY aktywno±ci, do których zalicza si : wywoªywanie usªug sieciowych; oferowanie usªug sieciowych (oczekiwanie na» dania partnera); generowanie wyj tków; oczekiwanie; czynno±ci puste; struktury kontrolne dotycz ce kolejno±ci wywoªywania aktywno±ci (warunki, p tle itp.); asynchroniczna obsªuga zdarze«; mo»liwo± obsªugi wyj tków i deniowania instrukcji sªu» cych do ko«- czenia (nalizowania) sekcji scenariusza; mo»liwo± transformacji wymienianych informacji przy pomocy j zyka XSLT (od wersji WS-BPEL 2.0). Stan realizacji scenariusza orkiestracji jest zale»ny od stanu zadeklarowanych zmiennych. Cz stymi przypadkami s sytuacje, w których to ludzie inicjuj procesy biznesowe lub wpªywaj na ich przebieg przez implementacj okre±lonych aktywno±ci, a bazowa propozycja j zyka BPEL zakªada,»e realizatorami wszystkich akcji oraz partnerami opisanymi w scenariuszu s systemy komputerowe. eby znie± to ograniczenie powstaªa dodatkowa specykacja: WS-BPEL Extension for People (BPEL4People) [2]. Tworz c zapis orkiestracji pewnego przedsi wzi cia nale»y uwzgl dni to,»e zadania, które maj zrealizowa ludzie jako cz ± scenariusza, musz by interpretowalne przez system komputerowy, by mógª przedstawi odpowiednie informacje czªowiekowi i zebra dane podane przez czªowieka. Dodatkowo system komputerowy musi zawiera mechanizmy pozwalaj ce okre±li stan realizacji zadania ludzkiego.

34 2.3. J ZYKI OPISU SCENARIUSZY Sposób deklarowania zada«dla ludzi opisuje specykacja Web Services Human Task (WS-HumanTask) [1]. Opis ka»dego zadania zawiera dane potrzebne do prezentacji zadania czªowiekowi, dane kontekstowe (priorytet, stan zadania itd.), dane operacyjne (wej±cie i wyj±cie zadania) oraz mo»e zawiera zaª czniki. Istnieje mo»liwo± zadeklarowania,»e ludzkie zadanie mo»e zosta pomini te w danym scenariuszu. Przypisywanie zada«do konkretnych osób mo»e odbywa si przez mechanizm ról i grup lub przez okre±lenie id konkretnej osoby. I mimo,»e te dwie specykacje maj pewne braki w dziedzinie specykacji formatu zasobów przydatnych do przetwarzania zada«[84] to ±rodowiska realizacji orkiestracji rozszerzone o implementacj tej specykacji pozwalaj na ªatwe ª czenie ludzkich i wirtualnych uczestników przedsi wzi cia w jednym scenariuszu [96]. J zyk BPEL, uªatwia integracj ró»nych scenariuszy negocjacji w systemach e-negocjacyjnych opartych na architekturze SOA. Do modelowania scenariuszy mo»na u»y diagramów stanów [10], które mo»na potem jednoznacznie przetªumaczy na elementy j zyka BPEL. Mimo to, jest to ci gle po±rednia metoda modelowania scenariuszy negocjacyjnych. J zyk BPEL jest j zykiem, który nie pozwala na obserwacj z globalnego punktu widzenia. Dodatkowo diagramy stanów s kolejnym po±rednim j zykiem modelowania, który nie byª projektowany do modelowania scenariuszy wspóªpracy. Innym problemem jest notacja graczna diagramów stanów, która nie zawsze musi by czytelna i jasna dla nie informatyka. BPEL jest jednym z bardziej ekspresyjnych j zyków w porównaniu z innymi j zykami do modelowania procesów biznesowych, a w szczególno±ci tych, które s u»ywane w systemach zarz dzania przepªywami pracy [101]. Typowe j zyki u»ywane w tych systemach dostarczaj obsªug mniej ni» poªowy najcz ±ciej u»ywanych wzorców przepªywów pracy [95]. Poza tym dost pne s dedykowane narz dzia pozwalaj ce na modelowanie scenariuszy bezpo±rednio w j zyku BPEL jak np. ±rodowisko NetBeans [59, 87] czy Eclipse [54]. Trwaj te» prace nad edytorami, które uwzgl dniaj

35 2.3. J ZYKI OPISU SCENARIUSZY rozszerzenia BPEL dla zada«ludzkich [94]. Kolejn zalet tego j zyka jest jego stosunkowo szeroka akceptacja i to,»e prowadzono ju» wiele bada«zwi zanych z wykorzystaniem i wdra»aniem scenariuszy biznesowych zapisanych w j zyku biznesowym. Badania te uwzgl dniaj równie» takie aspekty jak formalne i w peªni automatyczne sprawdzenie, czy wspóªdziaªaj ce procesy BPEL b d prawidªowo si wykonywa [58, 65, 62, 12] J zyki opisu choreograi Spo±ród aktualnie istniej cych j zyków opisu choreograi dwoma najbardziej znanymi s ebxml oraz WS-CDL. Pierwszy z nich powstaª w celu uªatwienia tworzenia systemów B2B i skupia si na poj ciach transakcji biznesowych oraz ±rodkach potrzebnych do ich realizacji. Drugi z tych j zyków jest uzupeªnieniem specykacji dotycz cych usªug sieciowych o mo»liwo± zapisywania choreograi. Zostaª zdeniowany jako ogólny sposób zapisu scenariuszy ª - cz cych usªugi sieciowe o dowolnym przeznaczeniu. ebxml J zyk ebxml skªada si z gªównej specykacji j zyka [20] oraz specykacji pomocniczych, które opisuj m.in. sposób wymiany komunikatów mi dzy uczestnikami scenariusza [23, 100], rejestr udost pnianych usªug [27, 28, 26, 22] oraz specykacje j zyka opisuj cego warunki kolaboracji uczestników procesów biznesowych [99]. Specykacja procesów biznesowych ebxml (ebxml Business Process Specication, w skrócie ebbp) zakªada,»e uczestników scenariusza wspóªpracy b d reprezentowa systemy komputerowe. Na model j zyka ebbp skªadaj si role (okre±laj ce uczestników wspóªpracy), które wspóªpracuj mi dzy sob wymieniaj c dokumenty biznesowe zgodnie ze zdeniowanym scenariuszem transakcji biznesowych [20]. Transakcja biznesowa reprezentuje niepodzielny etap realizacji scenariusza wspóªpracy realizowany przez dwie role. Polega on na wymianie informacji (dokumentów biznesowych) zgodnie z jednym z 6 podstawowych wzorców:

36 2.3. J ZYKI OPISU SCENARIUSZY transakcja komercyjna u»ywana w celu utworzenia formalnego zobowi zania pomi dzy stronami. Zakªada ona,»e istniej ju» wcze±niej zdeniowane warunki realizacji tego zobowi zania, np.: sprzedaj cy zobowi zuje si dostarczy produkt w okre±lone miejsce, w okre±lonym terminie, po dokonaniu zapªaty przez kupuj cego; powiadomienie formalna wymiana informacji u»ywana w sytuacjach wyj tkowych; dystrybucja informacji nieformalna wymiana informacji, np. przesªanie nowej oferty handlowej; schemat:» danie odpowied¹ wymiana informacji pomi dzy uczestnikami, której wynikiem nie jest»adne formalne zobowi zanie; schemat:» danie potwierdzenie pro±ba o potwierdzenie, czy wcze- ±niej podane informacje s nadal aktualne, której wynikiem nie jest»adne formalne zobowi zanie; odpowied¹ na zapytanie najbardziej nieformalna dost pna forma wymiany informacji zakªadaj ca,»e wykonanie aktywno±ci bez»adnych konsekwencji dalszej wymiany informacji takich jak np. zarezerwowanie produktu w magazynie itp. Przepªyw dokumentów wynikaj cy ze zdeniowanych transakcji biznesowych jest ukªadany w scenariusz (choreogra ) potrzebny do realizacji okre- ±lonego przedsi wzi cia. Choreograa w dokumencie ebbp umo»liwia deniowanie warunków wymiany informacji, synchronizacj realizacji scenariuszy itp. Specykacja ebxml zawiera dodatkowe dokumenty standaryzuj ce sposób reprezentacji dokumentów, sposób ogªaszania usªug biznesowych i sposób zapewniania wiarygodno±ci przekazywanych dokumentów. Zbiór tych specy- kacji skupia si przede wszystkim na transakcjach biznesowych i przedsi wzi ciach, które tego wymagaj. Proces dochodzenia do porozumienia czy tworzenia kontraktów jest marginalizowany.

37 2.3. J ZYKI OPISU SCENARIUSZY Web Services Choreography Description Language W trakcie prac nad systemami tworzonymi zgodnie z architektur SOA zauwa»ono brak ±rodków umo»liwiaj cych opisywanie zªo»onej interakcji pomi dzy usªugami sieciowymi. Firmy dostarczaj ce rozwi zania SOA rozpocz ªy prace nad zdeniowaniem j zyka opisu choreograi. Jednymi z pierwszych kompletnych propozycji takiego j zyka byªy Web Service Choreography Interface [4] oraz Web Services Conversation Language [7]. Te specykacje staªy si baz, na której podstawie rozpocz to prace nad rozwijan przez World Wide Web Consortium specykacj Web Services Choreography Description Language ([32], [75]). J zyk Web Services Choreography Description Language (WS-CDL) skupia si na opisywaniu interakcji pomi dzy stronami (usªugami sieciowymi). Specykacja zakªada model wspóªpracy równy z równym (peer-to-peer). Mo»- liwe jest stosowanie instrukcji steruj cych przepªywem sterowania takich jak bloki warunkowe, p tle, mo»liwo± wykonywania ±cie»ek choreograi równolegle itd. WS-CDL uwzgl dnia wyst powanie i obsªug wyj tków. Sterowanie przebiegiem choreograi uzale»nione jest od przekazywanych danych (scenariusze sterowane informacj ). Wa»nym elementem specykacji j zyka WS-CDL jest mo»liwo± zdeniowania opisu choreograi na jednym z trzech poziomów abstrakcji: abstrakcyjny deniuje typy wymienianych informacji oraz sekwencje i warunki wymiany informacji; przeno±ny nadzbiór choreograi abstrakcyjnej, który dodatkowo de- niuje zyczn struktur informacji (ª cznie z interfejsami usªug sieciowych), sposób zabezpieczania komunikacji, warunki wymiany informacji w postaci wyra»e«j zyka XPath nawi zuj cych do wymienianych informacji; konkretny nadzbiór choreograi przeno±nej, który dodatkowo deniuje adresy w postaci URL usªug sieciowych, certykaty itp.

38 2.3. J ZYKI OPISU SCENARIUSZY Mo»liwo± modelowania przetwarzania zespoªowego na ró»nych poziomach abstrakcji pozwala na wygodne przeniesienie scenariuszy ze ±rodowiska naturalnego do ±rodowiska opartego na architekturze SOA. Model j zyka WS-CDL zawiera: role, które okre±laj sposób zachowania uczestników scenariusza (np. sprzedaj cy); uczestników, którzy realizuj zbiory ról; zwi zki u»ywane do ª czenia uczestników, którzy wspóªpracuj ze sob w danym scenariuszu (wymieniaj si informacjami); typy informacji, które okre±laj jakie wiadomo±ci s przekazywane mi dzy uczestnikami choreograi; zmienne, które reprezentuj informacje przekazywane przez uczestników scenariusza. Stan przebiegu choreograi oraz warunki wykonywania poszczególnych ±cie»ek choreograi s wyznaczane na podstawie zawarto±ci zmiennych; tokeny, które sªu» do lokalizowania konkretnych informacji w przekazywanych wiadomo±ciach; kanaªy, które sªu» do okre±lania adresatów przekazywanych wiadomo- ±ci; choreograe, które deniuj zasady wspóªpracy mi dzy uczestnikami, skªadaj ce si z: jednostek roboczych, które reprezentuj etapy realizacji scenariusza; interakcji b d cych podstawowym blokiem deniowania choreogra- i, których wynikiem jest wymiana informacji przez uczestników i synchronizacja zmiennych;

39 2.3. J ZYKI OPISU SCENARIUSZY czynno±ci prostych, takich jak przypisanie warto±ci zmiennym; struktur steruj cych wykonaniem choreograi, które pozwalaj okre±li, czy elementy scenariusza maj zosta wykonane szeregowo, równolegle czy warunkowo; opis semantyczny elementów choreograi, który mo»e by komentarzem czytelnym dla czªowieka lub dla maszyny. Ka»dy z opisanych elementów modelu j zyka WS-CDL mo»e zosta wyra-»ony w postaci artefaktów zwi zanych z usªugami sieciowymi. Odpowiedniki poszczególnych elementów modelu j zyka WS-CDL w architekturze SOA przedstawia tabela 2.7 Proponuje si te»,»e przydaªaby si ustandaryzowana, graczna notacja choreograi powi zana z tym j zykiem [18].

40 2.3. J ZYKI OPISU SCENARIUSZY Tabela 2.7: Reprezentacja elementów modelu j zyka WS-CDL w architekturze SOA Element modelu j zyka WS-CDL Element implementacji SOA rola zbiór interfejsów sieciowych (WSDL) uczestnik grupa interfejsów, któr musi implementowa uczestnik choreograi zwi zki pary ról, które wspóªpracuj ze sob w ramach choreograi typy informacji struktury danych opisane j zykiem XML Schema zmienne zmienne zawieraj ce istotne dla wykonania choreograi dane tokeny wska¹niki na istotne fragmenty wiadomo±ci i zmiennych (skróty do fragmentów danych) w postaci wyra»e«xpath kanaªy zyczne adresy usªug sieciowych bior cych udziaª w choreograi choreograe protokoªy wspóªpracy stron bior - cych udziaª w choreograi, w celu osi gni cia okre±lonego celu (kod ¹ródªowy, BPEL itp.)

41 Rozdziaª 3 Analiza procesu negocjacji Istniej ró»ne metody opisu i analizy procesów negocjacyjnych oraz ich wyników. Jednym z klasycznych podej± jest teoria gier. Niestety, z punktu widzenia przydatno±ci w implementacjach systemów e-negocjacyjnych, ±ci±le teoretyczne, matematyczne opisy nie zawsze s adekwatne. Z tego powodu zaproponowano obliczeniowy model negocjacji opisany dalej w tym rozdziale. Pozwala on na stworzenie praktycznych procedur oceny przebiegu negocjacji oraz ich wyników. W celu analizy procesów negocjacyjnych praktycznie niezb dne jest wspomo»enie si systemem informatycznych. W ramach pracy stworzono taki system, GAJA, który wspomaga badanie procesów negocjacyjnych i ich ocen jako±ciow [52, 79]. Opisano zastosowany model eksperymentów negocjacyjnych i procedury ich wykonywania oraz przedstawiono przykªadowe wyniki eksperymentów negocjacyjnych z udziaªem ludzi razem z dokªadnym opisem sposobu ich oceny i metod wyznaczania miar jako±ciowych. 3.1 Teoria gier a negocjacje Jednym z gªównym aspektów teorii gier jest konikt, wynikaj cy z tego,»e gry z denicji tworz sytuacje koniktowe [68]. Post powanie graczy wpªywa na innych graczy i najcz ±ciej post powanie prowadz ce do najlepszego wy- 40

42 3.1. TEORIA GIER A NEGOCJACJE 41 niku gry dla jednego z graczy powoduje gorszy wynik dla drugiego z graczy. Negocjacje, jako proces rozwi zywania sytuacji koniktowych, s jednym z obszarów zainteresowa«teorii gier. Teoria gier dostarcza wiele narz dzi modelowania negocjacji. Jednym z nich s gry ekstensywne z peªn informacj. Gra ekstensywna modeluje sekwencyjne procesy decyzyjne w sytuacji strategicznej [68, 53]. Modele ekstensywnych gier z peªn informacj umo»liwiaj wyra»enie przypadków, w których w ka»dym momencie, w którym gracz podejmuje decyzj, zna on wszystkie wydarzenia zwi zane z gr, jakie wyst piªy wcze±niej. Na ekstensywn gr z peªn informacj skªadaj si nast puj ce elementy: zbiór graczy P; zbiór ci gów D, które mog by zarówno sko«czone jak i niesko«czone. Ci gi nale» ce do D s nazywane histori a jej elementy s akcjami, które podejmuj gracze. Zbiór D musi posiada nast puj ce wªasno±ci: pusta sekwencja D; je±li (a k ) k=1,...,k D i L < K to (a k ) k=1,...,l D. K mo»e by niesko«czone; je±li niesko«czona sekwencja (a k ) k=1 speªnia (a k ) k=1,...,l D dla ka»dego dodatniego L wtedy (a k ) k=1 D Histori (a k ) k=1,...,k D nazywa si ko«cow, je±li jest niesko«czona lub je±li nie istnieje a K+1 takie,»e (a k ) k=1,...,k+1 D. Zbiór ko«cowych historii oznaczany jest Z; funkcja S, która przypisuje ka»dej nieko«cowej historii element zbioru P. S jest funkcj gracza, gdzie S(d) okre±la który z graczy b dzie podejmowaª akcj po historii d; relacja preferencji i na Z jest okre±lona dla ka»dego gracza i P. W grze ekstensywnej zakªada si,»e gracze podejmuj decyzje dotycz ce wyboru strategii swojego post powania nie tylko na pocz tku gry, ale równie»

43 3.1. TEORIA GIER A NEGOCJACJE 42 w jej trakcie. Wyklucza to wykorzystywanie równowagi Nasha dla caªej gry, która wymaga by gracze wybierali swoj strategi tylko raz, na pocz tku gry. Równowaga Nasha to taki prol strategii, który gwarantuje,»e wybrana przez gracza strategia jest optymaln dla znanej i ustalonej strategii wybranej przez jego przeciwników. Przyjmuje si,»e strategie wybrane tak, by byªy zgodne z równowag Nasha, b d najlepszym sposobem post powania graczy. Mimo»e nie istnieje równowaga Nasha dla caªo±ci gry ekstensywnej, to mo»emy zdeniowa równowag dla podgier. W grze ekstensywnej Γ = P, D, S, ( i ) podgra, która nast puje po historii d jest gr ekstensywn Γ(d) = P, D d, S d, ( i d ), gdzie D d jest zbiorem ci gów d akcji, dla których (d, d ) D. S d deniuje si jako S d (d ) = S(d, d ) dla ka»dego d D d oraz d i d d wtedy i tylko wtedy gdy (d, d ) i (d, d ). Równowaga dla tak zdeniowanej podgry oznacza,»e po danej historii d gracze b d wybierali optymaln strategi. Model negocjacji oparty na ekstensywnej grze [83] uwzgl dnia takie aspekty negocjatorów jak niecierpliwo± czy stosunek do ryzyka. Zakªada si,»e dwóch negocjatorów mo»e doj± do porozumienia wtedy, gdy istnieje wynik negocjacji nale» cy do zbioru X. W przypadku, gdy nie dojdzie do porozumienia, nast pi pewne ustalone zdarzenie D. Zakªada si,»e zdarzenie D oznacza sytuacj, w której»adna ze stron nie jest zadowolona z wyniku negocjacji (np. zerwanie negocjacji). Protokóª negocjacji jest ustalony z góry i polega na naprzemiennym przedstawianiu swoich ofert. P = {1, 2} reprezentuje zbiór dwóch negocjatorów (graczy). Niech X b dzie zbiorem mo»liwych porozumie«. Dodatkowo, zbiór historii D jest zbiorem wszystkich sekwencji postaci (x 0, R, x 1, R,..., x n, A), gdzie n N, x s X dla ka»dego s, A oznacza akceptacj oferty a R odrzucenie oferty. Przyjmuje si,»e N jest zbiorem liczb naturalnych. Do zbioru D nale»y te» reprezentuj cy histori pocz tkow. Do zbioru historii nale» zarówno historie ko«cz ce si porozumieniem jak i te, w których do porozumienia nie doszªo. Mo»na wyró»ni historie niesko«czone, sko«czone i ko«cowe.

44 3.1. TEORIA GIER A NEGOCJACJE 43 Aby opis gry reprezentuj cej negocjacje byª kompletny, nale»y zdeniowa relacj preferencji. Przyj to,»e graczy interesuje tylko wynik negocjacji (czy doszªo do porozumienia i na jakich warunkach) oraz w jakim czasie doszªo do porozumienia. Historia negocjacji, czyli kolejno± i posta propozycji prowadz cych do porozumienia nie ma znaczenia dla graczy o ile prowadz one do tego samego wyniku. Dla zdeniowania relacji preferencji, zbiór D jest dzielony na partycje takie,»e dla ka»dego x X i n N, x t = x jest cz ±ci partycji oznaczonej (x, n). Relacja preferencji jest zatem zdeniowana na zbiorze (X N) {D} elementów partycji i musi speªnia nast puj ce warunki: doj±cie do porozumienia jest lepsze ni» brak porozumienia: (x, n) i D dla ka»dego (x, n) X N; czas jest cenny, czyli (x, n) i (x, n + 1) dla ka»dego n N z ostr preferencj je»eli (x, 0) i D; preferencje s stacjonarne: (x, n) i (y, n + 1) wtedy i tylko wtedy, gdy (x, 0) i (y, 1) oraz (x, n) i (y, n) wtedy i tylko wtedy gdy (x, 0) i (y, 0); preferencje s ci gªe: je±li x n X i y n Y dla ka»dego n, {x n } jest zbie»ny do x X, {y n } jest zbie»ne do y Y i (x n, n) i (y n, s) dla ka»dego n wtedy (x, n) i (y, s). Z tych zaªo»e«wynika,»e dla ka»dego δ (0, 1) istnieje ci gªa funkcja u i : X R taka,»e relacja preferencji i jest reprezentowana w X Y funkcj δ n u i (x) w takim znaczeniu,»e (x, n) i (y, s) wtedy i tylko wtedy, gdy δ n u i (x) δ s u i (y). Tak zdeniowana ekstensywna gra P, D, S, ( i ) jest nazywana gr negocjacyjn z naprzemiennymi ofertami X, ( i ). Zbiór równowag Nasha dla takiej gry jest bardzo du»y, zatem trudno jest na podstawie tego modelu wyznaczy optymaln strategi dla caªo±ci gry czy dowolnych, rzeczywistych negocjacji.

45 3.1. TEORIA GIER A NEGOCJACJE 44 Przedstawiony powy»ej podstawowy model negocjacji w teorii gier stanowi baz do modelowania ró»nych scenariuszy negocjacji, przy czym modykacje tego scenariusza wpªywaj w znacz cy sposób na wªasno±ci zdeniowanej gry. Model negocjacji przy pomocy gry ekstensywnej przyjmuje dodatkowo warunek,»e negocjatorzy post puj zawsze racjonalnie. Taki warunek zakªada wi kszo± modeli wynikaj cych z teorii gier. Dodatkowo powy»szy model zakªada,»e negocjatorzy maj peªn wiedz dotycz c zarówno przebiegu negocjacji, jak i dost pnych strategii. W rzeczywisto±ci takie zaªo»enia s niepraktyczne, poniewa» prawie nigdy negocjatorzy nie maj dost pu do peªnej wiedzy ani nie s w stanie na bie» co analizowa dost pnych strategii, zdeniowanych zgodnie z powy»szym modelem. W przypadku sytuacji, w których gracze nie posiadaj peªnej informacji, do modelowania mo»na u»y gier Bayesowskich. W grze Bayesowskiej wyró»niamy [68]: Ω sko«czony zbiór stanów, czasem okre±lany jako ±rodowisko gry lub natura; P sko«czony zbiór graczy. Dla ka»dego gracza i P deniuje si : zbiór dost pnych akcji A; sko«czony zbiór sygnaªów R i, które mo»e obserwowa gracz i oraz funkcj sygnaªu gracza i τ i : Ω R i ; miar prawdopodobie«stwa p i na Ω (pierwotne przekonania gracza i), dla której p i (τ 1 i (r i )) > 0 dla ka»dego r i R i ; relacj preferencji i okre±lon na zbiorze miar prawdopodobie«stw A Ω, gdzie A = j P A j. W grach Bayesowskich gracze spodziewaj si okre±lonych akcji wykonywanych przez innych graczy w zale»no±ci od stanu ±rodowiska. Dodatkowo gracze zakªadaj,»e zarówno oni, jak i inni gracze mog posiada bª dn informacj dotycz c tego, w jakim stanie ±rodowiska (sytuacji) si aktualnie znajduj. Je±li negocjacje zostan zdeniowane przy pomocy gry bay-

46 3.1. TEORIA GIER A NEGOCJACJE 45 esowskiej, to sygnaªami mog by mi dzy innymi oferty prezentowane przez negocjatorów. W grach bayesowskich równowaga Nasha, przy doborze najlepszych akcji, uwzgl dnia sygnaªy, jakie otrzymuje gracz i to, jaki stan ±rodowiska gracz dedukuje na podstawie tych sygnaªów. Modele zaproponowane w teorii gier bardzo dobrze nadaj si do modelowania negocjacji z punktu widzenia szukania optymalnego wyniku albo w celu wspomagania podejmowania decyzji. Uwzgl dniaj c dost pn wiedz o ±rodowisku negocjacji i samych procesach negocjacji mo»liwe jest oszacowanie, które decyzje negocjatorów dadz najlepsze efekty [11]. Jednak teoria gier nakªada du»o ogranicze«na analizowane negocjacje, a analizowanie i porównywanie ró»nych scenariuszy mo»e by czasochªonne i wymagaj ce obliczeniowo, z czego najwi kszym problemem jest dobranie odpowiedniej funkcji preferencji. Kolejnym problemem jest to,»e taki formalny, matematyczny model nie jest ªatwo przetªumaczy na algorytm komputerowy zachowuj c peªn elastyczno± scenariuszy uwzgl dniaj c pozornie nieracjonalne ludzkie zachowania. Racjonalno± negocjatorów trudno oceni, poniewa» to, co mo»e wydawa si nieracjonaln decyzj z punktu wiedzenia pareto-optymalno±ci, mo»e by racjonaln decyzj z globalnego punktu widzenia lub mo»e by wynikiem dodatkowej wiedzy, któr posiadaj negocjatorzy, a która nie zostaªa uwzgl dniona w modelu negocjacji [43]. Modeluj c negocjacje jako gr ekstensywn z góry zakªada si, jakie s warunki negocjacji i jakie s mo»liwe drogi post powania negocjatorów. Niestety trudno to odnie± do jednostkowych, rzeczywistych sytuacji, poniewa» teoretyczne zaªo»enia nie zawsze musz korespondowa z wiedz negocjatorów. Dodatkowo, przy analizie gier ekstensywnych nie uwzgl dnia si mo»liwo±ci zmiany zasad negocjacji, która jest mo»liwa w ±wiecie rzeczywistym. W teorii gier istnieje wyra¹ny podziaª na gry kooperatywne i niekooperatywne. W rzeczywistych negocjacjach ten podziaª jest bardziej pªynny i mo»na go powi za ze stylem negocjacji. Oznacza to,»e taka sama sytuacja negocjacyjna mo»e by bli»sza grze kooperacyjnej dla jednej pary negocjato-

47 3.2. OBLICZENIOWY MODEL NEGOCJACJI 46 rów, za± dla innej mo»e by bli»sza grze koniktowej. W teorii gier istnieje rozwini cie wy»ej przedstawionych modeli o sytuacje, w których uczestnicy gry spodziewaj si dalszych interakcji mi dzy sob w przyszªo±ci i dostosowuj swoje strategie w taki sposób, by zmaksymalizowa swoj wygran (zyski) w perspektywie dªugoterminowe [68]. Mo»liwe jest równie» tzw. implementacyjne podej±cie do rozwi zania problemów postawionych w grze, w którym ustala si oczekiwany wynik a potem szuka modelu gry i najlepszej strategii by ten wynik osi gn. Inne elementy negocjacji, które nie s zbyt dobrze reprezentowane w teorii gier to procesy komunikacyjne: scenariusze komunikacji, wpªyw u»ytego medium itd. [33] S to elementy, które w znacz cy sposób wpªywaj na wynik i sposób prowadzenia negocjacji. 3.2 Obliczeniowy model negocjacji Du»a cz ± przeprowadzonych eksperymentów negocjacyjnych skupiªa si na podstawowym przypadku negocjacji: negocjacjach handlowych. Nie mniej zastosowana metodologia ma znaczenie uniwersalne i mo»e by wykorzystana równie» w innych przypadkach. By obiektywnie oceni skuteczno± tego typu negocjacji, przyj to matematyczny model negocjacji, który deniuje parametry i wspóªczynniki wykorzystywane przy opisywaniu warunków pocz tkowych negocjacji, ich przebiegu oraz wyników. Zdeniowane parametry s wykorzystywane równie» w ocenie jako±ci negocjacji oraz w algorytmach symuluj cych wybrane scenariusze negocjacji. W ogólnym przypadku negocjacje mo»na opisa nast puj cym zbiorem parametrów: N = {O, P, G, D, C, E} (3.1) gdzie O jest przedmiotem negocjacji. Przedmiot negocjacji jest znany wszystkim uczestnikom negocjacji. P oznacza zbiór uczestników negocjacji: P = {P 1, P 2,..., P i,..., P I }; I 2, (3.2)

48 3.2. OBLICZENIOWY MODEL NEGOCJACJI 47 a I jest liczb negocjatorów. Aby negocjacje mogªy si odby, musi wzi w nich udziaª co najmniej dwóch uczestników. Uczestnikiem negocjacji (stron w negocjacjach) mo»e by czªowiek, grupa ludzi, agent lub program komputerowy. Jest to odpowiednik zbioru graczy w teorii gier. W trakcie negocjacji omawiane s zagadnienia negocjacyjne. Powi zane one s z celami, które chc osi gn negocjatorzy. Przez G = {g 1, g 2,..., g j,..., g J } (3.3) oznaczamy zbiór zagadnie«negocjacji, którymi mog by np. cena, termin wykonania usªugi itp. J jest liczb zagadnie«negocjacji uwzgl dnianych przez wszystkich negocjatorów. Ka»dy z uczestników wi»e z zagadnieniami negocjacji pewne cele, które chce osi gn, np. okre±lony przedziaª cenowy, który go interesuje, przedziaª czasowy realizacji przedsi wzi cia itd. D oznacza zbiór» da«przedstawianych przez negocjatorów w kolejnych krokach negocjacji: D = {D 1, D 2,..., D k,..., D K } (3.4) daniem nazywamy przedstawienie konkretnej warto±ci dotycz cej wybranego zagadnienia negocjacji, przy czym k oznacza krok negocjacji, za± K jest liczb wszystkich kroków negocjacji. Krokiem negocjacji nazywamy zbiór» - da«przedstawionych przez jednego uczestnika w jego jednej wypowiedzi. W ka»dym kroku znane s aktualne» dania wszystkich negocjatorów, które okre±laj stan negocjacji. Dodatkowo wyró»ni mo»na te» dania, których warto±ci ulegªy zmianie wzgl dem poprzedniego kroku negocjacji. D k = {V 1 k, V 2 k,..., V i k,..., V I k, P i k} (3.5) gdzie, Vk i to aktualny na pocz tku kroku k stan» da«i-tego negocjatora a Pk i to nowe propozycje i-tego negocjatora w k-tym kroku. Z denicji kroku wynika,»e tylko jeden uczestnik mo»e zmodykowa swoje» dania w jednym kroku. Vk i = {vk,1, i..., vk,j, i..., vk,j} i (3.6)

49 3.2. OBLICZENIOWY MODEL NEGOCJACJI 48 gdzie, v i k,j oznacza warto±» dania dotycz cego j-tego zagadnienia negocjacji dla i-tego negocjatora na pocz tku k-tego kroku. P i k = {p i k,1,..., p i k,j,..., p i k,j} (3.7) gdzie, p i k,j oznacza zaproponowan w k-tym kroku przez i-tego negocjatora warto± dla j-tego zagadnienia. W danym kroku negocjator nie musi proponowa nowych warto±ci» da«dla wszystkich zagadnie«. Bardzo cz sto zmiana dotyczy tylko jednego z zagadnie«. Zbiór D odpowiada historii w teorii gier z t ró»nic,»e w teorii gier historia zawiera wszystkie znacz ce akcje graczy (negocjatorów) a w tej denicji uwzgl dniane s jedynie zmiany warto±ci» da«negocjatorów. Wprowadza to rozró»nienie na akcje, które ªatwo mo»na zanalizowa automatycznie (uwzgl dniane w zbiorze D) i takie, które wymagaj analizy eksperta lub bardzo zªo»onego algorytmu komputerowego (nie uwzgl dniane w zbiorze D). Do zªo»onych akcji zalicza si takie posuni cia negocjatorów jak przyjazne gesty, zach caj ce wypowiedzi, gro¹by itp. Wpªywaj one bezpo±rednio na przebieg negocjacji ale nie s ªatwo analizowalne przez komputer. Je±li negocjacje zostan zako«czone porozumieniem, to w ostatnim kroku s przedstawiane ko«cowe warunki kontraktu (wynik negocjacji): C = D K (3.8) Wtedy: v 1 K,j = v 2 K,j =... = v i K,j = v I K,j = v K,j, (3.9) dla wszystkich i, których dany warunek kontraktu dotyczy. Kontrakt odpowiada ostatniemu elementowi sko«czonej, ko«cowej historii w teorii gier. Ostatnim z elementów okre±laj cych negocjacje jest ±rodowisko, w którym si one odbywaj oznaczone przez E. Mo»e to by ±rodowisko naturalne, w którym negocjatorzy dyskutuj bezpo±rednio lub ±rodowisko wirtualne, gdzie medium komunikacyjnym mo»e by czat. Zachowuj c spójno± z powy»szymi denicjami, w dalszej cz ±ci pracy b dzie stosowana nast puj ca konwencja stosowania indeksów:

50 3.2. OBLICZENIOWY MODEL NEGOCJACJI 49 i oznacza numer negocjatora a I liczb negocjuj cych stron; j oznacza numer zagadnienia negocjacji a J liczb zagadnie«podlegaj cych negocjacjom; k oznacza numer kroku procesu negocjacyjnego a K liczb kroków rozpatrywanych negocjacji. Ka»dy negocjator jest ograniczony pewnymi warunkami pocz tkowymi, które wpªywaj na warto±ci prezentowanych przez niego» da«. Zatem: i,j min i j,max i j mini j v i k,j max i j, k = 1, 2,..., K, (3.10) czyli ka»dy z negocjatorów formuªuje warto±ci» da«dla danego zagadnienia negocjacji w pewnym, okre±lonym przedziale zawartym mi dzy min i j, max i j, zwanym cz sto przedziaªem zgodno±ci [61]. Przedziaª ten jest znany przez negocjatora i ale nie musi by znany przez pozostaªych negocjatorów. Dodatkowo dla ka»dego negocjatora i zagadnienia negocjacji zdeniowano wspóªczynnik kierunku korzy±ci, który okre±la kierunek zmian warto±ci» da«, który b dzie korzystniejszy dla danego negocjatora (i) i zagadnienia negocjacji (j). Ten wspóªczynnik jest oznaczony jako r i j. Mo»e on przyjmowa warto±ci ze zbioru { 1, +1}, które oznaczaj odpowiednio,»e mniejsza warto±» dania tego zagadnienia negocjacji jest korzystniejsza dla danego negocjatora lub»e wi ksza warto±» dania tego zagadnienia negocjacji jest korzystniejsza dla danego negocjatora. Zbiór G oraz warto±ci min i j, max i j i r i j s skonkretyzowanym, liczbowym wyra»eniem preferencji negocjatora o znaczeniu analogicznym do relacji preferencji w teorii gier. W typowej sytuacji negocjacji handlowych, w których bierze udziaª dwóch negocjatorów (I = 2) parametry r i j dla pary negocjatorów maj przeciwne znaki oraz zachodzi zale»no± min 1 j min 2 j max 1 j max 2 j (3.11) Dla przypadku 3.11 jest mo»liwe, by strony negocjacji doszªy do porozumienia. Przykªadem takiej sytuacji s negocjacje handlowe, gdzie zagadnieniem

51 3.2. OBLICZENIOWY MODEL NEGOCJACJI 50 Rysunek 3.1: Warunki pocz tkowe negocjacji dla I = 2 i j-tego zagadnienia negocjacji Rysunek 3.2: Wspóªczynniki 1 i 2 dla I = 2 i danego j negocjacji jest cena, wtedy kupuj cy chce uzyska jak najmniejsz cen a sprzedaj cy jak najwi ksz (por. rysunek 3.1). Je±li nie jest speªniona nierówno± 3.11, uzyskanie konsensusu w wyniku negocjacji mo»e okaza si niemo»liwe z uwagi na brak warto±ci j-tego zagadnienia satysfakcjonuj cych dla negocjatorów. To zaªo»enie prowadzi to do zdeniowania wspóªczynnika: 1 i j = max i j min i j, i = 1, 2,..., I, j = 1, 2,..., J (3.12) który okre±la szeroko± przedziaªu akceptowalno±ci warto±ci» da«dla i-tego negocjatora przy uwzgl dnieniu j-tego zagadnienia negocjacji.

52 3.2. OBLICZENIOWY MODEL NEGOCJACJI 51 2 i 1,i 2 j Szeroko± przedziaªu mo»liwych warto±ci v i K,j deniujemy jako: 2 i 1,i 2 j = max i 1 j min i 2 j, (3.13) okre±la wielko± przedziaªu, w którym mog znale¹ si ko«cowe warunki kontraktu dla j-tego zagadnienia negocjacji. Warto± 1,i 2 2 j > 0 i jest warunkiem koniecznym, by negocjacje zostaªy zako«czone sukcesem. Dla I = 2 wzór ten przyjmuje posta : 2 1,2 j = max 1 j min 2 j (3.14) Wspóªczynniki 1 i 2 dla I = 2 i przy danym j ilustruje rysunek 3.2. Znajomo± przedziaªów min i j, max i j dla ka»dego i i j pozwala na teoretyczne oszacowanie optymalnego wyniku negocjacji dla znanych zagadnie«negocjacji. Przyj to,»e dla I = 2 b dzie on równy: bv j = max1 j + min 2 j (3.15) 2 co odpowiada warto±ci ±redniej przedziaªu min 2 j, max 1 j. Warto± bv j jest wykorzystywana do obiektywnej oceny skuteczno±ci negocjacji (podrozdziaª 3.5). Kolejnym wspóªczynnikiem wykorzystywanym do obiektywnej oceny skuteczno±ci negocjacji jest: mvj i = mini j + max i j, (3.16) 2 Uwzgl dnia on skuteczno± negocjacji obserwowan z punktu widzenia negocjatora. Z eksperymentów wynika,»e uczestnicy nie oczekuj uzyskania w procesie negocjacji warto±ci min i j dla rj i = 1 lub max i j dla rj i = +1, tylko warto±ci bliskiej mvj. i Rozwini ciem tych koncepcji jest okre±lenie ±redniej dla obu negocjatorów: mv i 1,i 2 j = mvi 1 j + mv i 2 j, (3.17) 2 który dla I = 2 jest równy: mv 1,2 j = mv1 j + mv 2 j 2. (3.18)

53 3.2. OBLICZENIOWY MODEL NEGOCJACJI 52 Rysunek 3.3: Parametry bv j, mv i j i mv i 1,i 2 j dla I = 2 Odlegªo± pomi dzy mvj i dla danej pary uczestników oraz zagadnienia j oznaczamy jako: i 1,i 2 3 j = mv i 1 j mv i 2 j (3.19) Wszystkie wspóªczynniki bv i mv s bezpo±rednio zwi zane ze skuteczno±ci negocjacji i mog sªu»y do jej oceny. Uwzgl dniaj one zarówno globalny punkt widzenia (bv) jak i punkty widzenia negocjatorów (mv). Rysunek 3.3 ilustruje poªo»enie wspóªczynników bv j, mvj i i mv i 1,i 2 j na osi warto±ci» da«wybranego zagadnienia negocjacji dla I = 2. Taniec negocjacyjny przedstawia zmiany w propozycjach skªadanych przez negocjatorów. Jest gracznym wyra»eniem przebiegu negocjacji i jest najprostsz wersj scenariusza negocjacyjnego. Rysunek 3.4 przedstawia przykªad ta«ca negocjacji. Jedna o± reprezentuje warto±ci propozycji jakie skªadaª pierwszy negocjator a druga o± reprezentuje warto±ci propozycji jakie skªadaª drugi negocjator. Na wykresie punktami oznacza si skªadane propozycje, które mo»na potem poª czy w celu zwizualizowania przebiegu negocjacji oraz kolejno±ci i wielko±ci zmian propozycji negocjatorów. i W celu opisania ta«ców negocjacyjnych zdeniowano wspóªczynnik 4 k,j, który okre±la, o ile zmieniªa si proponowana przez i-tego negocjatora warto± j-tego zagadnienia negocjacji w k-tym kroku. Dodatnia warto± 4 k,j i oznacza,»e negocjator i w kroku k zaproponowaª warto± parametru j mniej

54 3.3. POMIARY JAKO CIOWE 53 Rysunek 3.4: Przykªad ta«ca negocjacyjnego i korzystn dla siebie. Je±li warto± 4 k,j < 0 to znaczy,»e negocjator i w kroku k zaproponowaª warto± zagadnienia negocjacji j bardziej korzystn i dla siebie. Warto± 4 k,j wynosi: 4 i k,j = v i k 1,j v i k,j dla r i j = +1 vk,j i vk 1,j i dla r i j = 1 (3.20) Zaproponowany obliczeniowy model negocjacji w porównaniu do teorii gier ogranicza zbiór analizowanych i uwzgl dnianych aspektów negocjacji do tych, które mo»na ªatwo automatycznie przeanalizowa przy pomocy komputera. Takie rozró»nienie jest praktyczne w przypadku, gdy istnieje potrzeba oceny du»ego zbioru negocjacji, co byªo cz ±ci bada«opisanych w tej pracy. 3.3 Pomiary jako±ciowe Osoby korzystaj ce z pewnego produktu lub usªugi oczekuj,»e dany produkt b d¹ usªuga zapewni im odpowiedni satysfakcj. Wi»e si to z po-

55 3.3. POMIARY JAKO CIOWE 54 j ciem jako±ci, na któr skªadaj si takie charakterystyki produktu, usªugi lub procesu, które wpªywaj na mo»liwo± zaspokojenia zdeniowanych lub wywiedzionych potrzeb i oczekiwa«, czyli satysfakcj u»ytkownika 1. Rozpatruj c proces negocjacji lub pracy zespoªowej z punktu widzenia jako±ci, mo»emy okre±li szereg atrybutów i charakterystyk zarówno samego procesu jak i jego wyniku. Wpªywaj one bezpo±rednio lub po±rednio na satysfakcj uczestników zespoªowych przedsi wzi ludzkich. Negocjacje to proces, w którym co najmniej dwie strony dyskutuj pewne okre±lone zagadnienia, np. ch zakupu/sprzeda»y pewnego produktu b d¹ sposób realizacji przedsi wzi cia, który b dzie najlepszym rozwi zaniem pewnego problemu. Strony bior ce udziaª w negocjacjach przedstawiaj swoje argumenty w celu uzyskania konsensusu niezb dnego do realizacji tego przedsi wzi cia. W negocjacjach wa»ny jest nie tylko ko«cowy wynik, ale równie» wiele aspektów zwi zanych z przebiegiem negocjacji, jak na przykªad czas trwania negocjacji, styl negocjacji itd. Jako± negocjacji mo»na ocenia obiektywnie, opieraj c si na pewnym modelu negocjacji, jak i subiektywnie z punktu widzenia zewn trznego obserwatora, jak i z punktu widzenia uczestników negocjacji. Prowadzi to do zawarcia w zbiorze charakterystyk jako±ci zarówno miar obiektywnych jak i subiektywnych [49]. W celu sformalizowania procesu oceny jako±ci negocjacji posªu»ono si drzewem jako±ci. Rysunek 3.5 przedstawia zdeniowane atrybuty jako±ci negocjacji oraz wybrane charakterystyki jako±ciowe. Wszystkie charakterystyki subiektywne ocenia si przy pomocy odpowiednio przygotowanych ankiet, które wypeªniaj uczestnicy negocjacji lub eksperci oceniaj cy przebieg negocjacji. Atrybuty obiektywne s oceniane na podstawie miar wywodz cych si z przyj tego modelu negocjacji w sposób zautomatyzowany. Przypisanie wag gaª ziom drzewa oceny jako±ci negocjacji zale»y od typu eksperymentu negocjacyjnego i aspektów negocjacji, które w danym badaniu maj najwi ksze znaczenie. 1 za The American Society for Quality (ASQ),

56 3.3. POMIARY JAKO CIOWE 55 Rysunek 3.5: Atrybuty i wybrane charakterystyki jako±ciowe negocjacji Jako podstawowe atrybuty jako±ci negocjacji przyj to: skuteczno± rozumiana jako odlegªo± osi gni tego wyniku negocjacji od wyniku oczekiwanego. Wynik oczekiwany jest wyznaczany na podstawie przyj tego modelu negocjacji (podrozdziaª 3.2) lub mo»e by oszacowany przez eksperta b d¹ uczestnika negocjacji; efektywno± rozumiana jako czas trwania negocjacji szacowana na podstawie liczby kroków procesu negocjacji (liczby interakcji); styl negocjacji jeden z podstawowych stylów negocjacji: rywalizacyjny, kooperacyjny (integratywne negocjacje) lub dostosowuj cy si. Styl rywalizacyjny polega na tym,»e negocjator próbuje uzyska przewag kosztem partnera. W przypadku stylu dostosowuj cego si, negocjator rezygnuje ze swoich» da«by unikn koniktu. Styl kooperacyjny polega na tym,»e partnerzy wspóªpracuj ze sob w celu uzyskania wyniku negocjacji, który b dzie satysfakcjonuj cy dla ka»dej ze stron. Preferowanym stylem negocjacji jest styl kooperacyjny [24]. Styl negocjacji mo»e oceni ekspert analizuj c przebieg negocjacji lub mo»na go okre±li na podstawie ta«ca negocjacji;

57 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI motywacja rozumiana jako stopie«zaanga»owania si uczestnika w negocjacjach, który jest oceniany przez eksperta. W przypadku bada«opartych na eksperymentach negocjacyjnych, nale»y wykluczy z analizy wszystkie eksperymenty, w których którakolwiek ze stron wykazywaªa si nisk motywacj, np. zgadzaj c si na wszystkie propozycje strony przeciwnej. Szczegóªowe denicje miar zale» od przeprowadzanych eksperymentów negocjacyjnych i s opisane w podrozdziale System wspomagaj cy ocen jako±ci negocjacji Negocjacje s zªo»onym procesem i wiarygodna ocena ich jako±ci na podstawie bie» cych obserwacji nie jest mo»liwa, poniewa» istnieje potrzeba oceny wielu aspektów negocjacji. Tradycyjne metody ankietowania nie sprawdzaj si, poniewa» u»ytkownicy systemów e-negocjacyjnych w wi kszo±ci przypadków nie potra prawidªowo rozdzieli poszczególnych aspektów negocjacji w kontek±cie badanego systemu e-negocjacyjnego i scenariusza przez niego oferowanego [92], dlatego tworzenie i u»ywanie dedykowanych narz dzi do badania negocjacji jest niezb dne. W celu przeprowadzania eksperymentów negocjacyjnych stworzono internetowy system GAJA wspomagaj cy wykonywanie eksperymentów oraz ocen jako±ci negocjacji [77, 80]. System GAJA umo»liwia: deniowanie eksperymentów negocjacyjnych w celu ich wielokrotnego wykonywania; rejestrowanie procesu negocjacji; przeprowadzanie wymaganych ankiet i testów do oceny negocjacji; prezentacj i analiz zebranych danych.

58 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Model eksperymentów negocjacyjnych W celu oceny jako±ci eksperymentów negocjacyjnych ustalono powtarzaln procedur przygotowywania eksperymentów negocjacyjnych i ich realizacji. Zdeniowano model eksperymentów negocjacyjnych, który zostaª nast pnie zaimplementowany w systemie GAJA [52]. Rysunek 3.6 przedstawia najwa»- niejsze elementy przyj tego modelu. Attributes Operations Attributes <<entity>> Attributes Operations Operations Attributes Operations Rysunek 3.6: Model eksperymentów negocjacyjnych przyj ty w systemie GA- JA Przedsi wzi cie Przedsi wzi cie jest szablonem dla wykonywanych eksperymentów. Przedsi wzi cie deniuje nast puj ce elementy: nazwa identykuje szablon eksperymentu; typ okre±la typ przedsi wzi cia negocjacyjnego, np.: negocjacje handlowe, praca zespoªu informatycznego itp. Typ przedsi wzi cia decydu-

59 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI je o przebiegu eksperymentów negocjacyjnych i o tym, jakie dane b d zbierane w trakcie trwania eksperymentów; opis i cel okre±laj warunki pocz tkowe, ograniczenia ±rodowiskowe negocjacji oraz cele jakie powinny zosta osi gni te jako wynik negocjacji. Ka»de przedsi wzi cie mo»e mie wiele wersji oznaczonych dodatkowymi atrybutami, takimi jak np. okre±lenie, która strona ma przewag w negocjacjach handlowych. Te atrybuty sªu» do dodatkowego kategoryzowania i grupowania przedsi wzi. Rola Z ka»dym przedsi wzi ciem s powi zane dwie lub wi cej ról. Rola okre±la zadania negocjatora i precyzuje jego priorytety oraz cele. Przedsi wzi cie razem z okre±lonymi rolami tworzy kompletny opis warunków potrzebnych do wykonania eksperymentu negocjacyjnego przez uczestników eksperymentów negocjacyjnych. Uczestnik Jednoznacznie identykowalny u»ytkownik systemu GAJA, który mo»e bra udziaª w eksperymentach negocjacyjnych lub je ocenia, je»eli posiada uprawnienia eksperta. Grupa Grupa uczestników, którzy maj przydzielone role okre±lone w pewnym przedsi wzi ciu i bior cych razem udziaª w jednym eksperymencie negocjacyjnym. Grupa zawiera tylu uczestników, ile jest zdeniowanych ról w danym przedsi wzi ciu.

60 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Eksperyment Pojedyncze wykonanie przedsi wzi cia negocjacyjnego. Wykonuje go grupa uczestników zgodnie z opisem zdeniowanym w przedsi wzi ciu. Eksperyment pozwala w sposób powtarzalny przeanalizowa przebieg negocjacji o okre±lonych warunkach pocz tkowych i z okre±lonymi zadaniami dla negocjatorów. Ka»dy eksperyment mo»e mie indywidualnie deniowany kanaª komunikacji (czat, kontakt bezpo±redni). Tabela 3.1: Dane zbierane podczas wykonywania eksperymentów negocjacyjnych Kategoria danych Ogólne informacje o eksperymencie Przebieg negocjacji Wynik negocjacji (i dane powi zane z wynikami) Subiektywna ocena negocjacji Zbierane dane Opis przedsi wzi cia Uczestnicy eksperymentu Data wykonania eksperymentu Czas trwania negocjacji Zapis czatu lub zapis video Dokªadne wyniki negocjacji Oczekiwania negocjatorów Waga negocjowanych aspektów Ankieta oceny negocjacji wypeªniona przez uczestników Ankieta oceny negocjacji wypeªniona przez eksperta Ankieta oceny uczestników wypeªniona przez eksperta Z ka»dym eksperymentem powi zane s dane, które zostaªy zebrane w trakcie i po eksperymencie negocjacyjnym. Tabela 3.1 zawiera list najwa»- niejszych danych wykorzystywanych do identykacji eksperymentów i oceny jako±ci negocjacji.

61 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Architektura systemu GAJA System GAJA jest moduªowym systemem internetowym o standardowej trójwarstwowej architekturze (warstwa dost pu do danych, warstwa logiki biznesowej i warstwa prezentacji) [21, 79]. Interfejs u»ytkownika jest dost pny przez przegl dark WWW. Wygl d interfejsu i dost p do moduªów i funkcji systemu zale»y od uprawnie«u»ytkownika. W systemie dost pne s trzy klasy u»ytkowników: uczestnicy eksperymentów osoby, które zostaªy zarejestrowane w systemie i mog bra udziaª w eksperymentach negocjacyjnych. Ten typ u»ytkowników ma dost p wyª cznie do swoich zada«i swoich wyników; eksperci maj mo»liwo± tworzenia nowych przedsi wzi, tworzenia grup uczestników oraz eksperymentów negocjacyjnych i ogl dania wszystkich zebranych danych; administratorzy maj dost p do wszystkich funkcji systemu, w tym mo»liwo± przydzielania uprawnie«do poszczególnych moduªów. Administratorzy mog te» dodawa i uruchamia nowe moduªy systemu GAJA. Architektura systemu opiera si na wzorcu Model-Widok-Kontroler (Model- View-Controller) [89, 97] (rysunek 3.7). Moduª kontrolera odpowiada za: kontrol uprawnie«; dost p do moduªów funkcjonalnych systemu; reaguje na zdarzenia generowane przez u»ytkownika prezentuj c odpowiedni widok. W systemie rozró»nia si trzy gªówne zestawy funkcjonalno±ci za które odpowiadaj trzy kategorie komponentów biznesowych i moduªów interfejsu u»ytkownika (rysunki 3.7 i 3.8):

62 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Rysunek 3.7: Ogólna architektura systemu GAJA Rysunek 3.8: Moduªowa struktura systemu GAJA

63 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI deniuj ce pozwalaj na deniowanie przedsi wzi, ról oraz ankiet wykorzystywanych do subiektywnej oceny jako±ci negocjacji; wykonawcze odpowiadaj za sterowanie przebiegiem eksperymentów negocjacyjnych, wy±wietlanie polece«i informacji uczestnikom eksperymentów oraz zbieranie wprowadzanych przez uczestników danych; analityczne prezentuj zebrane dane w postaci ró»norodnych zestawie«oraz pozwalaj na eksport danych do narz dzi statystycznych Procedury badania jako±ci negocjacji W celu zapewnienia powtarzalno±ci wykonania eksperymentów negocjacyjnych zdeniowano odpowiednie procedury przygotowywania i wykonywania eksperymentów. Procedury przygotowania przedsi wzi, wykonania eksperymentów i analizy zebranych danych s zale»ne od typu przedsi wzi cia. System wspomagaj cy badanie negocjacji przygotowano do tego, by umo»- liwiaª deniowanie przedsi wzi bez udziaªu programisty w mo»liwie wielu przypadkach. Dodatkowo architektura systemu minimalizuje nakªad pracy programistycznej potrzebnej do przygotowania nowych typów przedsi wzi [50]. Procedura deniowania przedsi wzi Przed umo»liwieniem wykonania eksperymentów nale»y najpierw zdeniowa przedsi wzi cia, czyli szablony, wg których b d wykonywane eksperymenty. Procedura ich deniowania jest nast puj ca: 1. Przygotowanie ankiet dla uczestników i ekspertów. Ankiety sªu» do zbierania informacji o uczestnikach, które s przydatne do oceny jako- ±ci negocjacji. Oddzielna grupa ankiet sªu»y do zbierania danych szacuj cych subiektywn ocen jako±ci negocjacji. 2. Przygotowanie tabel albo list z zagadnieniami negocjacji.

64 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Przygotowanie ogólnego opisu zadania negocjacyjnego, zawieraj cego informacje okre±laj ce warunki pocz tkowe oraz cele negocjacji. 4. Przygotowanie listy ról oraz opisów ról. Opis roli zawiera szczegóªowe informacje dotycz ce zada«przydzielanych uczestnikom eksperymentów negocjacyjnych. 5. Przypisanie ankiet oceniaj cych negocjacje do ról. W przypadku przedsi wzi badaj cych negocjacje handlowe mo»liwe jest przygotowanie kilku wersji opisów przedsi wzi cia i ról uzale»nionych od pozycji negocjatorów (równowaga, przewaga kupuj cego, przewaga sprzedaj - cego). Mo»liwe jest tworzenie przedsi wzi wieloetapowych, które b d wykonywane jako oddzielne eksperymenty. W tym celu deniuje si zale»no±ci mi dzy przedsi wzi ciami. Procedura wykonywania eksperymentów negocjacyjnych Ka»dy eksperyment negocjacyjny jest wykonywany wg ±ci±le okre±lonej procedury. Zale»nie od typu przedsi wzi cia jest ona nieznacznie modykowana a skªada si z nast puj cych kroków: 1. Rejestracja uczestnika w systemie: 1.1. Uczestnik wypeªnia formularz osobowy, który jest wykorzystywany m.in. do identykacji uczestników (unikalna nazwa u»ytkownika) i okre±lenia do±wiadczenia negocjacyjnego uczestników Opcjonalnie uczestnik wypeªnia ankiety personalne, które s standardowymi ankietami psychologicznymi umo»liwiaj cymi okre±lenie cech osobowych czªowieka. 2. Przypisanie zarejestrowanym uczestnikom ról w eksperymentach negocjacyjnych przez eksperta. Jednocze±nie ekspert decyduje, jaki kanaª komunikacyjny b dzie u»ywany w trakcie negocjacji (czat lub rozmowa bezpo±rednia).

65 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Zdeniowana grupa uczestników rozpoczyna wykonywanie eksperymentu negocjacyjnego. Eksperyment skªada si z wielu kroków, które wszyscy uczestnicy wykonuj jednocze±nie, czekaj c na partnerów przed przej±ciem do nast pnego etapu: 3.1. Uczestnik eksperymentu zapoznaje si z zadaniem negocjacyjnym i swoj rol Uczestnik eksperymentu deklaruje swoje oczekiwania dotycz ce wyniku negocjacji oraz okre±la wagi dla zagadnie«negocjacji. (Ten krok dotyczy negocjacji handlowych.) 3.3. Uczestnik negocjuje, wykorzystuj c wybrany przez eksperta kanaª komunikacyjny Uczestnik wprowadza wynegocjowane warto±ci zagadnie«negocjacji (wyniki negocjacji) do systemu Uczestnik wypeªnia ankiet subiektywnej oceny jako±ci negocjacji. 4. Wst pna analiza przeprowadzonego eksperymentu przez eksperta: 4.1. Ekspert mo»e skontrolowa poprawno± danych wprowadzonych przez uczestników. Przeprowadzone eksperymenty dowiodªy,»e ten etap jest niezb dny by skorygowa drobne pomyªki uczestników, takie jak np. u»ycie zªej jednostki przy wpisywaniu wyników negocjacji Ekspert wypeªnia ankiety subiektywnej oceny negocjacji oraz zachowania si negocjatorów Opcjonalnie ekspert mo»e oznaczy zdarzenia negocjacyjne, które wyst piªy w trakcie negocjacji. Do zdarze«negocjacyjnych zaliczane s m.in.: rozpocz cie kolejnych faz negocjacji, podanie nowych» da«przez negocjatorów, wykonanie okre±lonych gestów przez negocjatorów itp.

66 3.4. SYSTEM WSPOMAGAJ CY OCEN JAKO CI Procedura tworzenia nowych typów przedsi wzi Ze wzgl du na to,»e ró»ne typy przedsi wzi mog wymaga wprowadzania innych typów danych oraz wymaga zmodykowania przebiegu eksperymentu negocjacyjnego (podrozdziaª 3.4.3, punkt 3) do tworzenia nowych typów przedsi wzi wymagana jest pomoc programisty. Architektura systemu GA- JA implikuje nast puj c procedur tworzenia nowych typów przedsi wzi : 1. Stworzenie obiektów reprezentuj cych (nowe) typy danych wykorzystywane do reprezentacji zagadnie«negocjacji. 2. Stworzenie trzech rodzajów komponentów do obsªugi zdeniowanych typów danych: deniuj cych s wykorzystywane przez eksperta do deniowania nowych przedsi wzi, np. dla negocjacji handlowych ekspert deniuje list zagadnie«negocjacji (cena, gwarancja itp.), wzgl dem której uczestnicy eksperymentów wypeªniaj formularze oczekiwa«i wyników negocjacji; wy±wietlaj cych sªu» do przedstawiania uczestnikom eksperymentów zagadnie«negocjacji wraz z odpowiednim opisem; zbieraj cych dane tworz formularze sªu» ce do wpisywania wyników negocjacji zwi zanych z zagadnieniami negocjacji itd. Te komponenty s tworzone jako obiekty i metody realizuj ce API zde- niowane w systemie GAJA. 3. Skomponowanie z utworzonych komponentów kolejnych etapów przebiegu eksperymentu negocjacyjnego. Etap w systemie GAJA odpowiada dynamicznej stronie WWW pozwalaj cej na realizacj pewnej cz ±ci eksperymentu negocjacyjnego. Istnieje mo»liwo± dziedziczenia etapów eksperymentu z wcze±niej zdeniowanych typów przedsi wzi. Opisane procedury przygotowywania i realizacji eksperymentów negocjacyjnych gwarantuj powtarzalno± wykonywanych eksperymentów, jednocze-

67 3.5. WYNIKI EKSPERYMENTÓW 66 ±nie zapewniaj c wystarczaj c elastyczno±, niezb dn do wybrania najlepszego scenariusza realizacji eksperymentów negocjacyjnych. 3.5 Wyniki eksperymentów W ramach bada«przeprowadzono ponad 350 eksperymentów negocjacyjnych. Wi kszo± eksperymentów dotyczyªa negocjacji handlowych (300 eksperymentów). 50 eksperymentów badaªo scenariusze pracy zespoªu programistów nad wybranymi aspektami wytwarzania aplikacji internetowej. W ramach bada«rozpatrzono ró»ne przypadki warunków pocz tkowych negocjacji. Eksperymenty badaj ce negocjacje handlowe opieraªy si na przedsi wzi ciu, które zostaªo zdeniowane dla dwóch osób. Jeden z uczestników eksperymentu reprezentowaª wªa±ciciela gabinetu medycznego chc cego zakupi aparat USG a drugi reprezentowaª rm oferuj c takie aparaty. Negocjacjom podlegaªy nast puj ce zagadnienia: cena aparatu, termin dostawy, termin pªatno±ci, okres trwania gwarancji, cena szkolenia lekarzy w zakresie obsªugi nowego aparatu [49, 50]. Uczestnikami eksperymentów byªy osoby studiuj ce na studiach dziennych i na studiach zaocznych kilku wydziaªów Politechniki Gda«skiej. W wi kszo±ci eksperymentów kanaªem komunikacyjnym byª czat (250 eksperymentów). W 50 eksperymentach uczestnicy negocjowali w ±rodowisku naturalnym (w cztery oczy), a przebieg negocjacji byª rejestrowany kamer wideo. W przypadku negocjacji z wykorzystaniem czatu, przebieg negocjacji zostaª zarejestrowany w formie dziennika (historii) czatu. Przygotowano kilka zestawów przedsi wzi ró»ni cych si warunkami pocz tkowymi: warto±ciami min i j i max i j dla ceny oraz dost pno±ci alternatywnej oferty. Warunki pocz tkowe dla pozostaªych aspektów negocjacyjnych nie byªy modykowane. Tabela 3.2 przedstawia zestawienie przypadków, które zostaªy rozpatrzone w eksperymentach negocjacyjnych. Kolumny min Kupujacy/Sprzedajacy Cena i max Kupujacy/Sprzedajacy Cena oznaczaj granice akceptowalnych warto±ci ceny aparatu medycznego podlegaj cego negocjacjom, wyra-

68 3.5. WYNIKI EKSPERYMENTÓW 67 Tabela 3.2: Rozpatrywane przypadki negocjacji handlowych»one w tysi cach Euro. Te ograniczenia wynikaj z opisów przedstawionych uczestnikom eksperymentów. Kolumna alternatywna oferta informuje, czy w danej wersji eksperymentu z tre±ci zadania wynikaªa dost pno± alternatywnej oferty odpowiednio dla kupuj cego i sprzedaj cego. Ocena jako±ci negocjacji Jako± negocjacji jest oceniana zgodnie z atrybutami jako±ci zaproponowanymi w podrozdziale 3.3. Do peªnej oceny procesu negocjacyjnego niezb dne jest dobranie zarówno miar obiektywnych jak i wykorzystanie subiektywnych ocen ekspertów [98]. W celu zebrania warto±ci subiektywnych miar jako±ci negocjacji uczestnicy eksperymentów, po zako«czeniu negocjacji, wypeªniaj przygotowan przez psychologa ankiet zawieraj c pytania dotycz ce ka»dego z badanych aspektów negocjacji. Ankiety zawieraj pytania postaci: Czy jeste± zadowolony z przebiegu negocjacji? itp. Na ka»de pytanie uczestnik mo»e udzieli jednej z odpowiedzi od Tak przez Trudno powiedzie do Nie (9 mo»liwych odpowiedzi). Ka»da z odpowiedzi jest punktowana w zakresie od 1 do 9 punktów, przy czym 9 punktów oznacza odpowied¹, która najbardziej pozytywnie wpªywa na aspekt jako±ci negocjacji, którego dotyczy pytanie. Š czna warto± miary jako±ci jest wyznaczana jako ±rednia warto± punktowa wszystkich odpowiedzi dotycz cych pyta«reprezentuj cych dany atrybut jako±ciowy.

69 3.5. WYNIKI EKSPERYMENTÓW 68 Podobne ankiety wypeªnia ekspert, który analizuje wyniki negocjacji oraz zapis przebiegu negocjacji. Ekspert wypeªnia jedn ankiet oceniaj c proces negocjacji jako caªo± oraz po jednej ankiecie dla ka»dego negocjatora, która ocenia jako± negocjowania danego uczestnika eksperymentu (obrany przez niego scenariusz negocjacji). Wyniki wszystkich ankiet s nast pnie sumowane w ª czn subiektywn ocen jako±ci negocjacji q form. Spo±ród obiektywnych miar jako±ci wykorzystano miary dotycz ce skuteczno±ci negocjacji, efektywno±ci i stylu negocjacji. U»ywanie warto±ci ±redniej dla min i max jest jedn z przyj tych miar u»ywanych w ocenie negocjacji [98]. Zgodnie z zaproponowanym modelem negocjacji skuteczno± mo»na rozpatrywa wzgl dem wspóªczynników: bv j, mv 1,2 j i mv i j zgodnie z nast puj cymi wzorami: 1 v K,j bv j i 0,5 1,i 2 dla v K,j min i 2 j, max i 1 j sk bv,j = 2 j 0 dla v K,j / min i 2 j, max i 1 j 1 v K,j mv 1,2 j 1,2 0,5 sk mv,j = 3 dla v K,j mvj 1, mvj 2 j 0 dla v K,j / mvj 1, mvj 2 v K,j < mvj i i rj i = 1 1 dla v K,j > mvj i i rj i = +1 sat mv,j = 1 v K,j mvj i v K,j mvj, i max i j i rj i = 1 i 0,5 1 dla j v K,j min i j, mvj i i rj i = +1 v K,j > max i j i rj i = 1 0 dla v K,j < min i j i rj i = +1 (3.21) (3.22) (3.23) Uzyskane warto±ci s w skali 0 do 1, gdzie 1 oznacza najlepszy wynik. Poza tym niniejsze wzory s liniowo powi zane z warunkami pocz tkowymi negocjacji, dlatego w celu oceny skuteczno±ci negocjacji nale»y wybra tylko jeden z nich. W opisywanych eksperymentach zdecydowano si u»y warto±ci sk bv,j, przedstawiaj cej najkorzystniejszy wynik z punktu widzenia wszystkich uczestników przedsi wzi cia.

70 3.5. WYNIKI EKSPERYMENTÓW 69 Tabela 3.3: Wagi dla skªadników skuteczno±ci dla poszczególnych zagadnie«w negocjacjach handlowych Waga Cena 0,41 Termin pªatno±ci 0,19 Termin dostawy 0,16 Gwarancja 0,14 Cena szkolenia 0,10 Skuteczno± jest liczona dla ka»dego z zagadnie«negocjacji osobno. Š czna skuteczno± jest ±redni wa»on skuteczno±ci ka»dego z zagadnie«negocjacji. Wagi okre±lono jako ±redni wag dla poszczególnych zagadnie«okre±lon przez uczestników eksperymentów. Tabela 3.3 przedstawia warto±ci wag dla negocjowanych zagadnie«w realizowanych eksperymentach negocjacyjnych. Wagi zostaªy ustalone na podstawie pierwszego etapu eksperymentów negocjacyjnych. Ka»dy z uczestników eksperymentu wypeªniaª formularz, w którym przypisywaª wagi poszczególnym zagadnieniom negocjacji. Nast pnie wyznaczono ±redni wag dla ka»dego z zagadnie«. Efektywno± negocjacji jest obliczana jako liczba interakcji negocjatorów, gdzie interakcja odpowiada denicji kroku negocjacji w zaproponowanym modelu negocjacji. Zakªada si,»e mniejsza liczba kroków oznacza lepsz efektywno± negocjatorów. Zastosowanie takiego podej±cia uniezale»nia miar efektywno±ci od kanaªu komunikacyjnego, który w istotny sposób wpªywa na takie parametry jak czas trwania negocjacji (badania wykazaªy,»e negocjacje na czacie trwaj przeci tnie trzy razy dªu»ej ni» negocjacje, które odbywaªy si w cztery oczy).

71 3.5. WYNIKI EKSPERYMENTÓW 70 Efektywno± jest obliczana jako: 1 dla K < ef min ( ) ef = 1 K ef min ef max ef min dla K efmin, ef max, (3.24) 0 dla K > ef max gdzie ef min to minimalna liczba interakcji zaobserwowana dla eksperymentów negocjacyjnych o najlepszej skuteczno±ci a ef max to zaobserwowana maksymalna liczba interakcji. Styl negocjacji mo»na oceni na podstawie analizy ta«ca negocjacji. Zakªadamy,»e optymalnym stylem jest styl kooperacyjny, poniewa» prowadzi on do wyniku satysfakcjonuj cego wszystkie zainteresowane strony. Charakterystyczn cech ta«ca negocjacji zaobserwowanego podczas negocjacji, w których stosowano styl kooperacyjny jest to,»e obserwuje si zale»no± pomi dzy zmianami propozycji stron negocjacji. Negocjatorzy reaguj na ust pstwa partnera w ten sposób,»e oferuj ze swojej strony ust pstwa o podobnym zakresie. Dodatkowo w tym stylu pocz tkowo obserwuje si du»e ust pstwa a potem coraz mniejsze. W stylu dostosowuj cym si obserwuje si podobne ust pstwa przez caªy czas negocjacji, a gdy jedna ze stron stosuje styl rywalizacyjny, mo»na zaobserwowa maªe ust pstwa na pocz tku a du»e pod koniec negocjacji [60]. Zaobserwowano te»,»e negocjatorzy stosuj cy strategie niekooperacyjne przedstawiaj wi cej propozycji i czuj mniejsz kontrol nad procesem negocjacji a ci, którzy stosuj strategi kooperacyjn przedstawiaj mniej propozycji i wysyªaj wi cej komunikatów bez propozycji i czuj si bardziej zadowoleni z procesu negocjacji [55]. Przy ocenie jako±ci stylu negocjacji porównywane s zakresy ust pstw w kolejnych krokach przy zaªo»eniu,»e od negocjatorów oczekuje si ust pstw na poziomie 90% ust pstwa partnera w poprzednim kroku. Miara jako±ci

72 3.5. WYNIKI EKSPERYMENTÓW 71 stylu negocjacji jest obliczana wg nast puj cego wzoru: st = K st k k=3 K 2 0 dla stn k ( ; 0) (2; ) stn k dla stn 0,9 k 0; 0, 9 st k = 1 dla stn k (0, 9; 1, 1) 2 stn k 0,9 dla stn k 1, 1; 2 stn k = J j=1 J j=1 4 i 1 j,k 1 i 1 j 4 i 2 j,k 1 1 i 1 j = J j=1 J j=1 4 i 1 j,k (3.25) (3.26) 4 i 2 j,k 1 (3.27) W obliczeniu st pomini to pierwsze dwa kroki negocjacji, które zawieraj inicjalne propozycje negocjatorów. Przy obliczaniu st k przyj to,»e w kroku k- tym i k 1 negocjatorzy skªadali swoje propozycje naprzemiennie. Dodatkowo przyj to,»e w kroku k-tym i 1 negocjator skªada propozycj a procentow zmian warto±ci propozycji w k 1 kroku oceniamy z jego punktu widzenia. Motywacj ocenia ekspert na podstawie analizy przebiegu negocjacji. Je±li ekspert uzna,»e negocjacje zostaªy ¹le przeprowadzone, to dany eksperyment nie bierze udziaªu w dalszych badaniach. Tabela 3.4 prezentuje przykªadowe wyniki eksperymentów zwi zanych z negocjacjami handlowymi. W tabeli znajduj si nast puj ce informacje: metadane identykuj ce eksperyment i uczestników, ocena subiektywna, która jest ró»na dla ka»dego z uczestników oraz obiektywna ocena jako±ci obliczona zgodnie z wcze±niej opisanymi wzorami. Jak mo»na zauwa»y, skuteczno± jest obliczana dla ka»dego z zagadnie«negocjacji osobno i potem zsumowana, uwzgl dniaj c wag poszczególnych atrybutów negocjacyjnych. Efektywno± jest oceniona maksymalnie, poniewa» ta para bardzo szybko doszªa do porozumienia.

73 3.5. WYNIKI EKSPERYMENTÓW 72 Tabela 3.4: Przykªadowe wyniki eksperymentów

74 Rozdziaª 4 Negocjacje elektroniczne i ich symulacje Wykorzystuj c metodologi oceny procesów negocjacyjnych i ich wyników, oraz narz dzia uªatwiaj ce obserwacj i pó¹niejsz analiz negocjacji, mo»liwe jest zamodelowanie procesów negocjacyjnych w postaci scenariuszy negocjacyjnych. Do tego celu najlepiej nadaje si iteracyjny proces modelowania scenariuszy, poniewa» pozwala na udoskonalanie tworzonych scenariuszy negocjacyjnych. Zaproponowany proces modelowania wykorzystuje graczn notacj diagramów sekwencji UML oraz formalny zapis scenariusza negocjacji w postaci dokumentów WS-CDL, które uªatwiaj wdra»anie modykacji scenariuszy. W celu uruchamiania i testowania scenariuszy negocjacyjnych mo»na zastosowa specjalne ±rodowisko po±rednicz ce albo zastosowa tradycyjne metody integracji i wdra»ania zamodelowanych procesów i algorytmów. W ramach pracy wykonano badania modeluj ce i testuj ce podstawowe scenariusze negocjacyjne. W tym celu dokonano analizy wcze±niej przeprowadzonych eksperymentów negocjacyjnych z udziaªem ludzi i stworzono algorytm komputerowy symuluj cy zachowania ludzi niezb dne do negocjacji. Nast pnie zintegrowano ten algorytm z dwoma propozycjami scenariuszy negocjacyjnych i wykonano eksperymenty, w których ludzie mieli mo»liwo± 73

75 4.1. MODELOWANIE NEGOCJACJI 74 negocjowania z algorytmem komputerowym. Wyniki tych eksperymentów porównano z wynikami eksperymentów negocjacyjnych, w których brali udziaª wyª cznie ludzie. Porównano te» wyniki eksperymentów z udziaªem ludzi negocjuj cych z systemem komputerowym wykonanych zgodnie z ró»nymi scenariuszami negocjacyjnymi. Zaobserwowano znacz ce ró»nice w ogólnej efektywno±ci negocjacji oraz satysfakcji ludzi w zale»no±ci od zastosowanego scenariusza negocjacyjnego. Zaproponowano te» dalsze kierunki ulepszania zastosowanych scenariuszy negocjacyjnych. 4.1 Modelowanie negocjacji Przyj to,»e obserwator negocjacji analizuje je z globalnego punktu widzenia. W takim przypadku widoczne s tylko zewn trzne manifestacje zachowa«negocjatorów oraz wymieniane przez nich informacje. Nie s znane algorytmy, wg których negocjatorzy podejmuj decyzje. Implikuje to u»ycie j zyka opisu choreograi w celu modelowania scenariuszy negocjacyjnych. Opisany w podrozdziale j zyk WS-CDL pozwala na przedstawienie scenariusza na ró»nych poziomach abstrakcji i tym samym dobrze nadaje si do modelowania negocjacji opartego na obserwacjach. Do modelowania scenariuszy negocjacyjnych zaproponowano proces iteracyjny [78] bazuj cy na iteracyjnych metodach wytwarzania oprogramowania [91, 29]. Ka»da iteracja powinna si skªada z nast puj cych kroków: 1. Obserwacja zachowania negocjatorów (w pierwszej iteracji) lub obserwacja skuteczno±ci realizacji zaproponowanego scenariusza (kolejne iteracje) ko«cz ca si ocen jako±ci scenariusza negocjacyjnego. Propozycja systemu komputerowego uªatwiaj cego obserwacj i analiz procesu negocjacji zostaªa opisana w podrozdziale Przygotowanie (poprawianie) modelu scenariusza w wybranym j zyku modelowania interakcji. Mo»na do tego wykorzysta m.in. diagramy sekwencji UML [3] lub innego j zyka modelowania dostarczanego przez dost pne narz dzia.

76 4.1. MODELOWANIE NEGOCJACJI Przygotowanie zapisu scenariusza w j zyku WS-CDL na poziomie abstrakcyjnym lub przeno±nym (podrozdziaª 2.3.2). 4. Implementacja scenariusza w postaci aplikacji lub uruchomienie go w dedykowanym ±rodowisku po±rednicz cym. Przygotowanie modelu scenariusza w postaci diagramu sekwencji j zyka UML Do modelowania procesów biznesowych, przed przetªumaczeniem ich na j zyk wykonywalny taki jak BPEL, cz sto u»ywane s diagramy stanów [82] lub jedna z form diagramów interakcji [46, 18]. Proponowana procedura wykorzystuje diagramy sekwencji UML w celu modelowania scenariuszy negocjacyjnych, które nast pnie mo»na jednoznacznie przetªumaczy na zapis w j zyku XML [10]. Zapis choreograi opiera si na procesie przekazywania komunikatów, które mog zosta przedstawione jako woªania metod. Ka»dy z uczestników jest przedstawiony jako obiekt ze swoj lini»ycia. Zale»nie od tego, czy po danym komunikacie powinna nast pi odpowied¹ czy te» nie, na diagramie sekwencji u»ywa si synchronicznych lub asynchronicznych wywoªa«metod. Dodatkowo na takim diagramie powinny zosta oznaczone wszystkie sytuacje, dla których fragmenty sekwencji s wykonywane warunkowo lub w p tli. Na tym etapie modelowania nale»y te» wst pnie opracowa typy przekazywanych informacji, które b d wyra»one jako typy argumentów metod oraz typy zwracanych informacji. Rysunek 4.1 przedstawia przykªad diagramu sekwencji dla podstawowego przypadku negocjacji handlowych, w którym bierze udziaª dwóch uczestników: kupuj cy (K) i sprzedaj cy (S). Jedyne wiadomo±ci, które mi dzy sob wymieniaj, to aktualne propozycje» da«. Negocjatorzy wymieniaj si propozycjami» da«w dowolnej kolejno±ci i robi to tak dªugo, dopóki nie dojdzie do porozumienia. Liczba i typ negocjowanych zagadnie«wynika z rozpatrywanego zadania negocjacyjnego.

77 4.1. MODELOWANIE NEGOCJACJI 76 loop alt Rysunek 4.1: Diagram sekwencji UML dla najprostszej sytuacji negocjacji handlowych Tworzenie zapisu scenariusza w j zyku WS-CDL Po zamodelowaniu scenariusza w postaci diagramu UML nale»y go zapisa w j zyku WS-CDL. Na dzie«dzisiejszy nie istniej»adne graczne edytory pozwalaj ce na bezpo±rednie modelowanie scenariuszy w j zyku WS-CDL i wspieraj ce specykacj j zyka w stopniu wystarczaj cym. Mo»na jedynie wspiera si istniej cymi edytorami XML i XML Schema 1. Tworzenie dokumentu WS-CDL skªada si z nast puj cych etapów: 1. Zdeniowanie typów informacji u»ywanych w scenariuszu z wykorzystaniem j zyka XML Schema. 2. Zdeniowanie ról, uczestników i zwi zków. Je±li tworzymy dokument na przeno±nym poziomie abstrakcji, to ka»d z ról nale»y powi za z od- 1 W czasie pisania tej pracy kilka projektów maj cych na celu stworzenie ±rodowisk wspomagaj cych tworzenie choreograi w j zyku WS-CDL byªo w trakcie realizacji. Najbardziej zaawansowanym ±rodowiskiem tego typu jest ±rodowisko udost pniane w projekcie Pi4SOA ( [25]

78 4.1. MODELOWANIE NEGOCJACJI 77 powiednimi interfejsami usªug sieciowych. Implikuje to,»e odpowiednie usªugi musz ju» istnie lub musz zosta zaprojektowane. 3. Zdeniowanie kanaªów wymiany informacji, które okre±laj w jaki sposób lokalizowa uczestnika b d cego adresatem wiadomo±ci. 4. Zdeniowanie wszystkich choreograi wykorzystywanych w scenariuszu. Ka»dy dokument WS-CDL musi zawiera jedn choreogra gªówn. Do tego mog zosta zdeniowane choreograe dodatkowe, które mog zosta wykorzystane jako cz ± choreograi gªównej, do obsªugi sytuacji wyj tkowych itd. Ka»da choreograa zawiera: (a) deklaracje zwi zków bior cych udziaª w choreograi (co najmniej jeden zwi zek); (b) deklaracje wykorzystywanych zmiennych, w tym tzw. zmienne kanaªowe, które przechowuj adresy usªug sieciowych; (c) zawsze jedn aktywno±, gdzie aktywno±ci mo»e by : jednostka robocza, która reprezentuje etapy w realizacji scenariusza i umo»liwia warunkowe lub wielokrotne wykonywanie fragmentów choreograi; struktura grupuj ca wiele aktywno±ci w sekwencje lub równolegle wykonywane akcje; interakcja czyli wymiana informacji pomi dzy uczestnikami choreograi (przybiera posta woªa«usªug sieciowych); operacja na zmiennych; (d) opcjonalny blok obsªugi sytuacji wyj tkowych; (e) opcjonalny blok nalizacji scenariusza. Listing 4.1 pokazuje fragment dokumentu WS-CDL, który odpowiada wcze±niej zamodelowanemu scenariuszowi negocjacji w postaci diagramu UML. Fragmenty scenariuszy w j zyku WS-CDL mo»na grupowa w jednostki robocze, których wykonanie mo»e by opcjonalne lub wielokrotne. W przykªadzie na listingu 4.1, w atrybucie repeat (linia 4) zamieszczone jest wyra»enie

79 4.1. MODELOWANIE NEGOCJACJI 78 XPath sprawdzaj ce czy kupuj cy i sprzedaj cy przystali na proponowane warunki. Jednostka robocza z atrybutem repeat wykona si przynajmniej raz i b dzie si tak dªugo wykonywaªa dopóki wyra»enie zawarte w tym atrybucie b dzie prawd. Nast pnie w liniach 649 s zawarte dwie interakcje: sprzedaj cy przedstawia swoje» dania kupuj cemu i kupuj cy przedstawia swoje» dania sprzedaj cemu. Znacznik <choice> oznacza,»e tylko jedna z nich b dzie wykonana. Przy pomocy jednostek roboczych istnieje mo»liwo± zdeniowania warunków, która z akcji zawartych pomi dzy znacznikami <choice> zostanie wykonana. Mo»na jednak zaªo»y,»e sposób podj cia tej decyzji nie ma znaczenia z punktu widzenia danego scenariusza i nie deniowa warunków wyboru (tak jest w podanym przykªadzie). Wtedy zakªada si,»e dokonanie wyboru ±cie»ki post powania nale»y do uczestników. Je±li dokument WS-CDL zostaª stworzony na przeno±nym lub konkretnym poziomie abstrakcji to interakcje s w rzeczywisto±ci wywoªaniami usªug sieciowych. Nazwa wywoªywanej funkcji zawarta jest w atrybucie operation. Atrybut channelvariable okre±la po±rednio adres wywoªywanej usªugi a znacznik <participate> sªu»y do okre±lenia mi dzy którymi uczestnikami choreograi b d wymieniane informacje w danej interakcji. Ka»da interakcja mo»e zawiera wiele znaczników <exchange>, które okre±laj jakie informacje s przekazywane przy wywoªywaniu danej funkcji. Atrybut action informuje o kierunku przekazywania informacji, czyli czy dana informacja jest przesyªana jako cz ±» dania czy cz ± odpowiedzi. Tym samym zmienne podane w znacznikach <send> i <receive> musz by dost pne dla uczestnika zgodnego z kierunkiem wymiany informacji. Mo»liwe jest ustalenie maksymalnego czasu oczekiwania wykonywania danej interakcji co pozwala na obsªu»enie takich sytuacji wyj tkowych, w których jedna ze stron ulegªa awarii i nie dziaªa zgodnie ze zdeniowan choreogra. Podsumowuj c, ten reprezentacyjny fragment dokumentu WS-CDL dowodzi,»e przy pomocy tego j zyka mo»na zamodelowa praktycznie dowolny przebieg interakcji pomi dzy uczestnikami scenariusza.

80 4.1. MODELOWANIE NEGOCJACJI 79 Listing 4.1: Przebieg choreograi 1 <choreography name=" Negocjacje " root=" true "> <workunit name=" PrzekazywaniePropozycji " 4 r e p e a t=" not ( c d l : g e t V a r i a b l e ( ' KupujacyZgoda ' ), ' ', ' ' ) or \ 5 not ( c d l : g e t V a r i a b l e ( ' SprzedajacyZgoda ', ' ', ' ' ) ) "> 6 <c h o i c e> 7 <i n t e r a c t i o n name=" propozycjedlakupujacego " 8 channelvariable=" tns:sprzedajacydokupujacego " 9 o p e r a t i o n=" przedstawpropozycje "> 10 <p a r t i c i p a t e fromroletyperef=" t n s : R o l a S p r z e d a j a c y " 11 toroletyperef=" tns:rolakupujacy " 12 r e l a t i o n s h i p T y p e=" tns:sprzedajacykupujacy " /> 13 <exchange a c t i o n=" r e q u e s t " 14 name=" przeslijpropozycjekupujacemu " 15 informationtype=" t n s : l i s t a P r o p o z y c j i "> 16 <send 17 v a r i a b l e= 18 " c d l : g e t V a r i a b l e ( ' PropozycjeSprzedajacego ', ' ', ' ' ) " /> 19 <r e c e i v e 20 v a r i a b l e= 21 " c d l : g e t V a r i a b l e ( ' PropozycjeSprzedajacego ', ' ', ' ' ) " /> 22 </ exchange> 23 <exchange a c t i o n=" respond " 24 name=" czypropozycjezaakceptowano " 25 informationtype=" t n s : b o o l e a n "> 26 <send 27 v a r i a b l e= 28 " c d l : g e t V a r i a b l e ( ' KupujacyZgoda ', ' ', ' ' ) " /> 29 <r e c e i v e 30 v a r i a b l e= 31 " c d l : g e t V a r i a b l e ( ' KupujacyZgoda ', ' ', ' ' ) " /> 32 </ exchange> 33 </ i n t e r a c t i o n> 34 <i n t e r a c t i o n name=" propozycjedlasprzedajacego " 35 channelvariable=" tns:kupujacydosprzedajcego " 36 o p e r a t i o n=" przedstawpropozycje "> 37 <p a r t i c i p a t e fromroletyperef=" tns:rolakupujacy "

81 4.1. MODELOWANIE NEGOCJACJI toroletyperef=" t n s : R o l a S p r z e d a j a c y " 39 r e l a t i o n s h i p T y p e=" tns:sprzedajacykupujacy " /> 40 <exchange a c t i o n=" r e q u e s t " 41 name=" p r z e s l i j P r o p o z y c j e S p r z e d a j a c e m u " 42 informationtype=" t n s : l i s t a P r o p o z y c j i "> 43 <send 44 v a r i a b l e= 45 " c d l : g e t V a r i a b l e ( ' PropozycjeKupujacego ', ' ', ' ' ) " /> 46 <r e c e i v e 47 v a r i a b l e= 48 " c d l : g e t V a r i a b l e ( ' PropozycjeKupujacego ', ' ', ' ' ) " /> 49 </ exchange> 50 <exchange a c t i o n=" respond " 51 name=" czypropozycjezaakceptowano " 52 informationtype=" t n s : b o o l e a n "> 53 <send 54 v a r i a b l e= 55 " c d l : g e t V a r i a b l e ( ' SprzedajacyZgoda ', ' ', ' ' ) " /> 56 <r e c e i v e 57 v a r i a b l e= 58 " c d l : g e t V a r i a b l e ( ' SprzedajacyZgoda ', ' ', ' ' ) " /> 59 </ exchange> 60 </ i n t e r a c t i o n> 61 </ c h o i c e> 62 </ workunit> 63 </ choreography> Wdro»enie scenariusza Scenariusz zapisany w j zyku WS-CDL mo»na wdro»y na jeden ze sposobów: tradycyjna integracja programi±ci koduj przebieg scenariusza w aplikacji; wdro»enie scenariusza w dedykowanym ±rodowisku wykonawczym; metoda mieszana do wdro»enia scenariusza jest wykorzystane odpowiednie ±rodowisko po±rednicz ce, lecz we wdro»eniu potrzebny jest

82 4.1. MODELOWANIE NEGOCJACJI 81 udziaª programisty. Pierwsza z wymienionych metod jest maªo praktyczna, poniewa» poddaje w w tpliwo± potrzeb zapisu scenariusza w postaci dokumentu WS-CDL. Programi±ci mog zaimplementowa scenariusz zamodelowany w postaci diagramów UML i towarzysz cej im dokumentacji. Jest to te» najbardziej pracochªonna i najmniej elastyczna metoda. Ka»d zmian w scenariuszu trzeba r cznie wprowadzi do kodu aplikacji, co nie zawsze mo»e by ªatwe. Wdro»enie scenariusza w dedykowanym ±rodowisku wykonawczym jest najprostsz i najszybsz metod testowania i uruchomienia choreograi. Zakªada ona istnienie usªug sieciowych reprezentuj cych uczestników scenariusza oraz»e tworzone scenariusze sªu» przede wszystkim do integracji istniej cych usªug. Na dzie«dzisiejszy nie istniej ±rodowiska pozwalaj ce na w peªni automatyczne wdra»anie choreograi w j zyku WS-CDL. Trzecia z zaproponowanych metod zakªada,»e modelowana choreograa dotyczy nowych usªug, które niekoniecznie mog by udost pnione w formie usªug sieciowych. W tym przypadku na podstawie choreograi mog zosta automatycznie wygenerowane scenariusze lokalne (scenariusze widziane z punktu widzenia ka»dej ze stron). Wygenerowany zapis mo»e zosta utworzony w dowolnym j zyku, np. BPEL, Java itd. [63] Ze wzgl du na to,»e choreograa nie uwzgl dnia logiki dziaªania ka»dej ze stron, programista b dzie musiaª uzupeªni wygenerowane szablony o logik przetwarzania danych wymienianych mi dzy uczestnikami. Tak wygenerowany szablon b dzie musiaª korzysta z biblioteki oraz ±rodowiska po±rednicz cego wspomagaj cego wykonanie choreograi WS-CDL. Zalet tego podej±cia jest du»a elastyczno± wykorzystania scenariuszy. Zakªadaj c wykorzystanie j zyka BPEL, wraz z istniej cymi narz dziami i ±rodowiskami wykonawczymi tego j zyka, otrzymujemy mo»liwo± automatyzacji wi kszo±ci zada«zwi zanych z wdra»aniem choreograi. Jednocze±nie zachowujemy du» elastyczno±, poniewa» mo»emy dowolnie modykowa logik dziaªania stron, nie ograniczaj c si jedynie do modykowania dziaªania wywoªywanych usªug sieciowych, ale mamy równie» mo»liwo± wpªywania na to, co si dzieje pomi dzy kolejnymi wymianami

83 4.2. RODOWISKO PO REDNICZ CE 82 informacji zdeniowanymi w choreograi. W przypadku wykonywania scenariuszy negocjacyjnych zapisanych w j zyku WS-CDL stronami negocjacji mog by zarówno algorytmy komputerowe jak i ludzie korzystaj cy z komputerowego interfejsu u»ytkownika, gdzie moduª kontrolera wykorzystuje choreogra do wyboru widoku prezentowanego u»ytkownikowi (architektura aplikacji oparta o wzorzec MVC). Wykonywanie wdro»onych scenariuszy obserwuje si i ocenia w celu ich dalszego doskonalenia w kolejnych iteracjach opisanego procesu modelowania scenariuszy negocjacyjnych. 4.2 rodowisko po±rednicz ce W celu wykorzystania scenariuszy zapisanych w j zyku WS-CDL niezb dny jest interpreter tego j zyka oraz odpowiednie ±rodowisko wykonawcze. Aby zapewni elastyczno± wykorzystanych scenariuszy zaproponowano rozwi - zanie, w którym interpreter scenariusza generuje szablon kodu ¹ródªowego dla ka»dej ze stron bior cych udziaª w choreograi. Kod ¹ródªowy jest tworzony w j zyku Java i musi by uruchamiany w odpowiednim ±rodowisku wykonawczym. Rysunek 4.2 przedstawia proponowan architektur ±rodowiska po±rednicz cego umo»liwiaj cego uruchomienie choreograi zapisanej w j zyku WS- CDL. Przyj to,»e do utworzenia ±rodowiska po±rednicz cego zostanie wykorzystana platforma Java Enterprise Edition (JEE), poniewa» udost pnia ona biblioteki wspieraj ce standardy, na których opiera si j zyk WS-CDL: XML, XML Schema, Web Services [88, 69, 76]. Gªównym elementem tworz cym ±rodowisko po±rednicz ce dla j zyka WS- CDL jest biblioteka wspieraj ca konstrukcje j zyka WS-CDL. Implementuje ona obsªug nast puj cych aspektów obsªugi standardu WS-CDL: walidacja dokumentu WS-CDL; obsªuga funkcji zdeniowanych w specykacji j zyka WS-CDL;

84 4.2. RODOWISKO PO REDNICZ CE 83 Rysunek 4.2: Architektura ±rodowiska po±rednicz cego interpretuj cego choreograe WS-CDL obsªuga synchronizacji i sterowanie przebiegiem choreograi. Na tej bibliotece opiera si generator szablonów dla logiki biznesowej uczestnika choreograi. Wygenerowany szablon jest zestawem interfejsów i klas Javy, które zawieraj mi dzy innymi: klasy implementuj ce zadeklarowane w choreograi typy informacji; zmienne zadeklarowane w choreograi; szablony metod wymaganych przez role, które speªnia dany uczestnik; szablony metod, które s wykonywane przed i po ka»dej aktywno±ci zapisanej w choreograi programista mo»e je zaimplementowa w celu uzupeªnienia logiki biznesowej danego uczestnika choreograi; gªówn metod obsªuguj c przebieg choreograi i odpowiadaj c za wykonanie wszystkich aktywno±ci zapisanych w dokumencie WS-CDL (w szczególno±ci wywoªywanie metod usªug sieciowych w ramach interakcji).

85 4.2. RODOWISKO PO REDNICZ CE 84 Rysunek 4.3: Diagram klas generowanych na podstawie dokumentu WS-CDL Wygenerowane klasy s serializowalne, co pozwala na wstrzymanie wykonywania choreograi na dowolnie dªugi czas i jej wznowienie w pó¹niejszym czasie. Jest to niezb dne, poniewa» realizacja scenariusza mo»e by rozci - gni ta w czasie i trwa nawet wiele dni, co jest bardzo dªugim czasem z punktu widzenia typowych systemów komputerowych. Rysunek 4.3 przedstawia diagram klas, które s generowane z dokumentu WS-CDL. Klasa reprezentuj ca uczestnika implementuje interfejsy odpowiednich ról i wykorzystuje zdeniowane typy informacji. Szablon zawiera te» puste metody, które s wykonywane w istotnych momentach wykonywania choreograi. Na diagramie te metody maj przyrostek _1, który w rzeczywisto±ci jest zamieniany na pobran z dokumentu WS-CDL nazw odpowiedniej jednostki roboczej lub interakcji. Programista powinien utworzy klas dziedzicz c po klasie szablonu i w razie potrzeby nadpisa metody zwi zane z logik biznesow strony (metody oznaczone na rysunku 4.3 jako chronione: #).

86 4.2. RODOWISKO PO REDNICZ CE 85 Rysunek 4.4: Wzorzec MVC rozszerzony o obsªug choreograi Taka architektura generowanego kodu pozwala zmodykowa scenariusz zapisany w postaci dokumentu WS-CDL, nast pnie ponownie wygenerowa szablony, jednocze±nie umo»liwiaj c pozostawienie bez zmian implementacji logiki uczestnika choreograi zwi zanej z okre±lonymi interakcjami i jednostkami roboczymi. Obliczenia i akcje zwi zane z logik uczestnika choreograi mo»e wykonywa zarówno program komputerowy jak i czªowiek, któremu zostanie udost pniony odpowiedni interfejs u»ytkownika. Rysunek 4.4 przedstawia modykacj wzorca Model Widok Kontroler (MVC), która uwzgl dnia wykorzystanie choreograi w celu kierowania interakcjami u»ytkownika z systemem komputerowym. W tym celu model zostaª uzupeªniony o dane, które s potrzebne do okre±lenia stanu realizacji choreograi. Standardowo model zawiera wyª cznie dane, które s potrzebne do realizacji zada«u»ytkownika systemu. Rozszerzeniu musi ulec równie» kontroler. Musi on reagowa nie tylko na dziaªania u»ytkownika systemu, ale równie» na zdarzenia generowane przez pozostaªych uczestników choreograi. Dodatkowo wybór widoku, jaki zostanie zaprezentowany u»ytkownikowi systemu, zale»y nie tylko od akcji tego u»ytkownika ale równie» od stanu realizacji choreograi, st d kontroler

87 4.3. WZORCE EKSPERYMENTÓW 86 musi mie mo»liwo± odpytywania modelu o stan choreograi. Mo»liwo± sterowania interfejsem u»ytkownika przy pomocy choreograi pozwala sterowa scenariuszem pracy u»ytkownika. Dodatkowo, je±li dany system komputerowy jest wykorzystywany przez wielu u»ytkowników w celu realizacji zada«zespoªowych, to mo»liwa jest implementacja ró»nych scenariuszy pracy zespoªowej przy pomocy j zyka WS-CDL i zaproponowanego ±rodowiska po±rednicz cego i architektury interfejsu u»ytkownika. U»ytkownicy systemu napisanego zgodnie z proponowan w tym rozdziale architektur nie s zmuszeni wyª cznie do stosowania scenariuszy wspóªpracy zaproponowanych przez programist, ale mog je modykowa przez modykacj odpowiednich dokumentów WS-CDL. Jest to architektura zbli»ona do architektury systemów automatyzuj cych procesy biznesowe (Workow). Zmieniony jest punkt widzenia procesu na globalny, co pozwala na prostsz integracj ró»nych systemów i umo»liwia ªatw zmian uczestników scenariusza na innych. Mo»liwa jest równie» ªatwa zmiana jednego z uczestników na program komputerowy (np. agenta) lub odwrotnie. 4.3 Wzorce eksperymentów Pierwszym celem eksperymentów byªo porównanie jako±ci negocjacji, które odbywaªy si pomi dzy lud¹mi bez narzuconego scenariusza z jako±ci negocjacji, które odbywaªy si pomi dzy lud¹mi a algorytmem komputerowym, zgodnie z wcze±niej ustalonym scenariuszem. Drugim celem byªo okre±lenie czy dobór scenariusza ma istotny wpªyw na jako± negocjacji. W tym celu opracowany zostaª wzorzec eksperymentów obejmuj cy badanie negocjacji, gdzie negocjatorami s : wyª cznie ludzie; ludzie i algorytmy komputerowe. Wzorzec eksperymentów (rysunek 4.5) zostaª przygotowany w taki sposób,

88 4.3. WZORCE EKSPERYMENTÓW 87 by zapewni kontrolowane ±rodowisko e-negocjacyjne gwarantuj ce porównywalno± wykonywanych eksperymentów. Ka»de wykonanie eksperymentu negocjacyjnego skªadaªo si z 5 etapów: 1. Wypeªnienie ankiet osobowych przez uczestników eksperymentów. 2. Przeprowadzenie negocjacji handlowych przez uczestników eksperymentów z wykorzystaniem czatu jako kanaªu negocjacyjnego. 3. Wypeªnienie ankiet oceniaj cych eksperyment przez uczestników eksperymentu i przez ekspertów. 4. Przeprowadzenie negocjacji handlowych w parach, ª cz cych ludzi z algorytmem komputerowym. Zadanie negocjacyjne pozostaje takie samo, jak w przypadku negocjacji pomi dzy lud¹mi. 5. Wypeªnienie ankiet oceniaj cych eksperyment. Aby oceni adekwatno± przygotowanych algorytmów negocjuj cych przeprowadzono najpierw testy symulacyjne opisane w podrozdziale 4.4. Ze wzgl du na to,»eby mo»liwe byªo bezpo±rednie porównanie wyników eksperymentów, w przypadku negocjacji z algorytmem komputerowym zadanie postawione przed negocjatorami byªo identyczne z tym, które musieli wykona negocjuj c z innymi lud¹mi. Dodatkowo algorytm komputerowy miaª ustawiane ró»ne poziomy ulegªo±ci by zasymulowa ró»ne osobowo±ci negocjatorów (patrz podrozdziaª 4.4.2). Procedury przygotowywania eksperymentów negocjacyjnych oraz procedury oceny jako±ci przebiegu i wyników negocjacji zostaªy opisane w podrozdziaªach 3.3, i 3.5. Wyniki pierwszych trzech etapów eksperymentów zostaªy wykorzystane dodatkowo do bada«osobowo±ciowych i sytuacyjnych uwarunkowa«skuteczno±ci negocjacji [51].

89 4.3. WZORCE EKSPERYMENTÓW 88 Rysunek 4.5: Wzorzec eksperymentów

90 4.4. ALGORYTMY SYMULACYJNE 89 Rysunek 4.6: Algorytm symulacji ta«ców negocjacyjnych 4.4 Algorytmy symulacyjne Symulacja jednozagadnieniowych ta«ców negocjacyjnych Na podstawie obserwacji ta«ca negocjacji opracowano algorytm zachowania si negocjatorów, wg którego mo»na symulowa ró»ne zachowania negocjatorów. Taniec negocjacyjny dotyczy jednego zagadnienia negocjacji. Najprostszy algorytm symuluj cy taniec negocjacyjny przedstawiony jest na rysunku 4.6. Zaªo»ono,»e symulowane s dwie strony negocjacji, które przedstawiaj swoje propozycje na zmian. Dla ka»dej ze stron ustalone jest jedno zagadnienie negocjacyjne oraz min i j i max i j adekwatnie do przyj tego modelu. Symulacja nie uwzgl dnia historii interakcji pomi dzy stronami, tzn.»e parametry losowania kolejnych» da«zale» wyª cznie od aktualnych warto±ci» da«i warunków brzegowych. Warto±ci propozycji s losowane zgodnie z rozkªadem Gaussa. Dla pierw-

91 4.4. ALGORYTMY SYMULACYJNE 90 Rysunek 4.7: Obszar, w którym jest losowana warto± w pierwszym kroku symulacji ta«ca negocjacji szego losowania parametry rozkªadu prawdopodobie«stwa s nast puj ce. min i µ i j dla r i = 1 1,j = max i j dla r i = +1 (4.1) 3σ i 1,j = max i j min i j (4.2) Najwi ksze prawdopodobie«stwo ma wylosowanie warto±ci min i j, ale mo»liwe jest wylosowanie dowolnej warto±ci z przedziaªu warto±ci akceptowalnych. Dla r i = 1 parametry pierwszego losowania ilustruje rysunek 4.7, gdzie p(v) oznacza prawdopodobie«stwo wylosowania danej warto±ci zagadnienia negocjacyjnego. Kolejne losowania (k > 1) s realizowane zgodnie z nast puj cymi parametrami: µ i k,j = vk 1,j i (4.3) min((max i 3σk,j i j vk 1,j), i v i 1 k 1,j v i 2 k 1,j ) dla r i = 1 = (4.4) min((vk 1,j i min i j), v i 1 k 1,j v i 2 k 1,j ) dla r i = +1 Dodatkowo na losowane warto±ci naªo»one s nast puj ce warunki: p i k,j min i j, max i j (4.5) p i k,j p i k 2,j dla r i = 1 (4.6) p i k,j p i k 2,j dla r i = +1 (4.7)

92 4.4. ALGORYTMY SYMULACYJNE 91 Rysunek 4.8: Obszary, w których jest losowana warto± w dalszych krokach symulacji ta«ca negocjacji Je±li wylosowana warto± nie speªnia jednego z warunków , to jest losowana nast pna warto± tak dªugo, dopóki te warunki nie zostan speªnione. Oznacza to,»e losowana warto± propozycji zawsze b dzie si mie±ciªa w przedziale akceptowalnych warto±ci j-tego zagadnienia dla i-tej strony oraz»e kolejne propozycje b d bli»ej warto±ci korzystniejszych dla partnera (rysunek 4.8). Wyniki eksperymentów symulacji jednozagadnieniowych Przeprowadzone symulacje wykazuj,»e powy»szy algorytm dobrze reprezentuje zachowanie si negocjatorów. Uzyskane wyniki s zbli»one do ta«ców negocjacji zebranych z eksperymentów z udziaªem ludzi. Dla przykªadu rysunek 4.9 przedstawia wykresy ta«ców negocjacyjnych uzyskanych na podstawie eksperymentu z udziaªem ludzi (wykres a) oraz przy pomocy algorytmu symulacyjnego (wykres b). Na wykresie osie przedstawiaj warto±ci propozycji ceny kupna aparatu medycznego (podrozdziaª 3.5). O± oznaczon liter K dotyczy kupuj cego a o± oznaczona liter S dotyczy sprzedaj cego. Szarym prostok tem oznaczono obszar mo»liwych propozycji. Kolorowa linia reprezentuje taniec negocjacyjny, czyli propozycje i kontrpropozycje warto±ci ceny przedstawione przez negocjatorów lub zasymulowane. Pierwsza propozycja oznaczona jest liter P. Wynik negocjacji oznaczony jest liter K. Kolor linii oznacza kto przedstawiª now propozycj : kupuj cy niebieska linia;

93 4.4. ALGORYTMY SYMULACYJNE 92 Rysunek 4.9: Wykresy ta«ca negocjacyjnego uzyskane z eksperymentów negocjacyjnych (a) i symulacji (b)

94 4.4. ALGORYTMY SYMULACYJNE 93 Rysunek 4.10: Wynik symulacji ta«ca negocjacyjnego, w której pomini to warunki sprzedaj cy czerwona linia. Eksperymenty wykazaªy ponadto,»e pomini cie w symulacji warunków powoduje,»e uzyskane ta«ce negocjacyjne s chaotyczne i nienaturalne. Przykªad takiej symulacji jest zaprezentowany na rysunku Symulacja negocjacji wielozagadnieniowych Na podstawie wcze±niej zaprezentowanego algorytmu symulacji ta«ca negocjacyjnego, stworzono algorytm symulacji uwzgl dniaj cy wi cej ni» jedno zagadnienie negocjacji. Algorytm uwzgl dnia przypadki, gdzie liczba nego-

95 4.4. ALGORYTMY SYMULACYJNE 94 cjatorów wynosi 2 (N = 2). Liczba zagadnie«negocjacji, które podlegaj negocjacjom mo»e by dowolna (J 1). W symulacji przyj to,»e dana strona symulacji zna wyª cznie swoje warunki pocz tkowe oraz histori propozycji zªo»onych przez siebie i partnera. Algorytm symulacji uwzgl dnia warunki pocz tkowe modelu negocjacyjnego opisanego w podrozdziale 3.2, czyli min i j, max i j, r i j. Dodatkowo uwzgl dnione s nast puj ce parametry negocjacji: w i j δ j waga parametru, okre±laj ca jak du»e znaczenie ma j-te zagadnienie negocjacji dla i-tego negocjatora; okre±la z jak dokªadno±ci generowane s kolejne» dania zwi zane z j-tym zagadnieniem negocjacji, np. termin dostawy okre±lany jest w caªych dniach a nie w cz ±ciach dnia, wi c δ termin dostawy = 1 a np. cena w 0,1 tys. euro, wi c δ cena = 0, 1; mc j okre±la sugerowan, minimaln warto± zmiany j-tego zagadnienia negocjacji, np. mo»emy zaªo»y,»e dopiero zmiana terminu dostawy o tydzie«ma znaczenie dla przeprowadzanych negocjacji. Algorytm umo»liwia by zarówno jeden jak i obydwu uczestników negocjacji byªo symulowanych i pozwala na ustalenie stopnia ugodowo±ci symulowanego negocjatora (a). Algorytm uwzgl dnia» dania, dla których P i k = 1, czyli w jednym kroku proponowana jest tylko jedna zmiana warto±ci zagadnienia negocjacyjnego. W symulacji przyj to,»e algorytm dziaªa wg podstawowego, ogólnego scenariusza negocjacji, gdzie uczestnicy na zmian przekazuj sobie» dania (porównaj rysunek 4.1). W implementacji algorytmu przyj to,»e partner b dzie stosowaª kooperacyjny styl negocjacji. W implementacji algorytmu ka»dy symulowany uczestnik jest reprezentowany jako obiekt z ustalonymi, wy»ej wymienionymi parametrami, który posiada metod respond(), która generuje kolejn warto±» dania na podstawie dotychczasowego przebiegu negocjacji. Algorytm skªada si z trzech kroków, powtarzanych tak dªugo, a» negocjacje nie zostan zako«czone:

96 4.4. ALGORYTMY SYMULACYJNE Wyznacz ch zmiany swoich» da«. 2. Wybierz parametr podlegaj cy negocjacjom, który zostanie zmodykowany w tym kroku. 3. Wygeneruj now warto± tego parametru. Zaªo»ono,»e i = 1 oznacza symulowanego negocjatora a i = 2 jego partnera. Krok 1. W tym kroku wyznaczany jest wspóªczynnik okre±laj cy ch zmiany swoich» da«, oznaczony dalej jako pc. Wspóªczynnik ten wpªywa na wygenerowanie nowego» dania. W przypadku, gdy symulowany negocjator nie ma punktu odniesienia w postaci sekwencji» da«swojego partnera, to ten wspóªczynnik jest równy jego ugodowo±ci (pc = a). Jest to sytuacja, gdy znane s wyª cznie pocz tkowe propozycje partnera. Je±li wirtualny uczestnik ma punkt odniesienia w postaci historii zmian» da«swojego partnera, to wspóªczynnik pc jest uzale»niony od tego, w jakim stopniu partner modykowaª swoje» dania, wg poni»szego wzoru (patrz te» rysunek 4.11): pc = v2 k 2,j vk 1,j 2 1 wj 1 (4.8) 1 j W tym przypadku j jest numerem zagadnienia negocjacji, które ostatnio zmodykowaª partner. Podsumowuj c: w tym kroku algorytm stara si okre±li w jakim stopniu partner ust puje i chce kompromisu. Krok 2. W tym kroku wybierane jest zagadnienie negocjacji, dla którego modykowana jest warto±» dania. Zagadnienie negocjacji jest wybierane wyª cznie spo±ród tych, co do których nie istnieje zgoda pomi dzy negocjatorami. Prawdopodobie«stwo wyboru danego zagadnienia negocjacji jest wprost proporcjonalne do jego wagi (wj), 1 czyli algorytm zajmuje si cz ±ciej tymi zagadnieniami, które s wa»niejsze. Waga zagadnienia, które ostatnio byªo dyskutowane przez partnera jest zwi kszana, po to by zmniejszy prawdopodobie«stwo zbyt cz stej zmiany negocjowanego zagadnienia negocjacji.

97 4.4. ALGORYTMY SYMULACYJNE 96 Rysunek 4.11: Parametry uwzgl dniane w obliczaniu wspóªczynnika wpªywaj cego na generowanie nowego» dania Krok 3. W tym kroku obliczana jest nowa warto±» dania. Zale»nie od sytuacji negocjacyjnej do obliczenia warto±ci» dania dla wybranego zagadnienia wybierany jest jeden z trzech algorytmów: a) w przypadku, gdy wirtualny uczestnik podaje po raz pierwszy» danie dotycz ce wybranego zagadnienia, jest ono losowane zgodnie z rozkªadem normalnym z parametrami: µ = min 1 j dla r 1 j = +1 max 1 j dla r 1 j = 1 ; (4.9) 3σ = a 1 1 j, (4.10) gdzie j oznacza wylosowane w poprzednim kroku algorytmu zagadnienie negocjacji. Warto±ci nie mieszcz ce si w zakresie min 1 j, max 1 j s odrzucane (rys. 4.12). Na rysunkach p(v) oznacza prawdopodobie«stwo wylosowania warto±ci v danego zagadnienia negocjacji; b) w przypadku gdy ró»nica mi dzy» daniami symulowanego negocjatora i jego partnera jest wi ksza ni» przyj ta precyzja dla danego zagadnienia negocjacji ( v 1 k 1,j v 2 k 1,j > δ j ) to nowe» danie dotycz ce wybranego

98 4.4. ALGORYTMY SYMULACYJNE 97 Rysunek 4.12: Obszar, w którym jest losowana warto± wybranego zagadnienia negocjacji (krok 3a) Rysunek 4.13: Obszar, w którym jest losowana warto± wybranego zagadnienia negocjacji (krok 3b) parametru jest losowane zgodnie z rozkªadem normalnym z nast puj cymi parametrami: vk 1,j 1 rc dla rj 1 = +1 µ =, gdzie (4.11) vk 1,j 1 + rc dla rj 1 = 1 pc(vk 1,j 1 min1 j ) dla r wj rc = 1 j 1 = +1 pc(max 1 j v1 k 1,j ) dla rj 1 = 1 ; (4.12) w 1 j 3σ = max(3mc j, rc), (4.13) gdzie j oznacza wylosowane w poprzednim kroku algorytmu zagadnienie negocjacji a v 1 k 1,j oznacza poprzednio podan warto±» dania dla j- tego zagadnienia negocjacji przez wirtualnego negocjatora. Dodatkowo na losowane warto±ci naªo»one jest nast puj ce ograniczenie (rys. 4.13): max(min 1 j, v 2 k 1,j), min(max 1 j, v 1 k 1,j), dla r 1 j = +1 (4.14)

99 4.4. ALGORYTMY SYMULACYJNE 98 Rysunek 4.14: Generowanie nowej warto±ci wybranego celu negocjacji (krok 3c) lub max(min 1 j, v 1 k 1,j), min(max 1 j, v 2 k 1,j), dla r 1 j = 1 (4.15) Je±li po okre±lonej liczbie prób nie udaje si wylosowa warto±ci znajduj cej si w powy»szych granicach, to algorytm mo»e zerwa negocjacje; c) w przypadku, gdy ró»nica pomi dzy» daniami symulowanego negocjatora i jego partnera jest mniejsza lub równa przyj tej precyzji ( v 1 k 1,j v 2 k 1,j δ j ) dla danego zagadnienia negocjacji, to wirtualny negocjator przystaje na ostatni propozycj partnera dotycz c danego zagadnienia negocjacji (rys. 4.14). Wyniki eksperymentów symulacji wielozagadnieniowych Rysunek 4.15 oraz tabela 4.1 przedstawiaj przykªad ta«ca negocjacyjnego wygenerowanego wy»ej opisanym algorytmem. W tej symulacji zarówno sprzedaj cy jak i kupuj cy byli wirtualnymi uczestnikami. Warunki pocz tkowe dla negocjacji byªy ustalone zgodnie z zestawem danych nr 4 z tabeli 3.2. Negocjacjom podlegaªo pi zagadnie«: cena aparatu medycznego, termin dostawy, termin pªatno±ci, cena szkolenia i gwarancja. Tabela 4.1 przedstawia warto±ci» da«w kolejnych krokach negocjacji. Kursyw oznaczono» danie, które w danym kroku ulegªo zmianie. Puste

100 4.4. ALGORYTMY SYMULACYJNE 99 Rysunek 4.15: Przykªad dziaªania algorytmu symulacji wieloparametrowej pole oznacza,»e dany negocjator jeszcze nie podaª»adnego» dania dotycz cego danego zagadnienia. Rysunek 4.15 przedstawia te same wyniki w formie gracznej. Trójk tami s oznaczone propozycje skªadane przez kupuj cego a koªami propozycje skªadane przez sprzedaj cego. Jak mo»na zaobserwowa na tym rysunku, symulowani negocjatorzy rozpocz li negocjacje od przedstawienia sobie» da«cenowych, nast pnie przeszli do negocjowania pozostaªych zagadnie«. Na rysunku wida,»e istniej zale»no±ci pomi dzy kolejnymi ust pstwami negocjuj cych. Negocjacje zako«czone s ostatecznym ustaleniem ceny negocjowanego sprz tu medycznego.

101 4.4. ALGORYTMY SYMULACYJNE 100 Kupuj cy Sprzedaj cy Krok Cena Cena szkolenia Gwarancja Termin dostawy Termin pªatno±ci Cena Cena szkolenia Gwarancja Termin dostawy Termin pªatno±ci Tabela 4.1: Tabela przedstawiaj ca warto±ci» da«w kolejnych krokach symulowanego ta«ca negocjacji

102 4.5. EKSPERYMENTY NEGOCJACYJNE Eksperymenty negocjacyjne z udziaªem ludzi i algorytmu komputerowego Wykorzystuj c scenariusz negocjacyjny oraz algorytm przedstawiony w poprzednim rozdziale, który potra odpowiada na propozycje negocjacyjne, mo»liwe jest przeprowadzenie eksperymentów, w których jedn ze stron negocjacji s ludzie a drug algorytm komputerowy. Nast pnie mo»na porówna wyniki eksperymentów z wykorzystaniem algorytmu z wynikami uzyskanymi z udziaªem samych ludzi bez narzuconego scenariusza negocjacyjnego. W eksperymencie przyj to nast puj ce zaªo»enia: jako warunki pocz tkowe wybrano zagadnienia negocjacyjne opisane w podrozdziale 3.5 w wersji nr 4 z tabeli 3.2. W pierwszym wykonaniu eksperymentu aplikacja, która sªu»y jako interfejs pomi dzy lud¹mi a komputerem, pozwalaªa na negocjacje zgodne ze scenariuszem zaproponowanym w podrozdziale 4.1, rysunek 4.1. Uczestnicy wiedzieli,»e negocjuj z komputerem. Eksperyment pokazaª,»e a» 25% negocjacji zostaªo zerwanych. Ci sami uczestnicy, w eksperymentach negocjacyjnych z udziaªem wyª cznie ludzi, zerwali tylko 7,37% negocjacji. W negocjacjach z komputerem negocjacje zrywano ponad trzy razy cz ±ciej ni» w przypadku negocjacji przeprowadzanych mi dzy lud¹mi. Informacje zebrane od uczestników po zako«czeniu eksperymentu sugeruj,»e wysoki odsetek zerwanych negocjacji wynika z niedoskonaªo±ci zastosowanego scenariusza negocjacji, który okazaª si zbyt prosty. Uczestnicy eksperymentu nie wiedzieli, jak bardzo agresywnie mog negocjowa, poniewa» komputer zrywaª negocjacje bez uprzedniego ostrze-»enia, w przypadku gdy algorytm uznawaª przedstawiane propozycje za nieakceptowalne. Tym samym cz sto stosowana technika testowania partnera negocjacyjnego nie zdawaªa egzaminu i prowadziªa do zerwania negocjacji przez komputer. W celu poprawy wyników negocjacji niezb dnym staªo si zmodykowanie scenariusza negocjacji. Rysunek 4.16 przedstawia ulepszon wersj sce-

103 4.5. EKSPERYMENTY NEGOCJACYJNE Rysunek 4.16: Udoskonalony scenariusz dla eksperymentów negocjacyjnych z komputerem

104 4.5. EKSPERYMENTY NEGOCJACYJNE nariusza w postaci diagramu sekwencji. W nowej wersji scenariusz umo»liwia nie tylko przedstawianie sobie nawzajem propozycji, ale dodatkowo pozwala ostrzega partnera, je±li jego propozycje s nieakceptowalne (ostrze»enie przed zerwaniem negocjacji) oraz oczekiwa na dalsze propozycje partnera bez podawania nowych ze swojej strony. Dodatkowo zerwanie negocjacji przestaªo by traktowane jako sytuacja wyj tkowa, ale jako jeden z mo»liwych wyników negocjacji. W proponowanym scenariuszu ka»dy z uczestników mo»e w ka»dym momencie wysªa ka»dy z dost pnych komunikatów (wewn trzne bloki alt). Nie jest narzucony równie» obowi zek by komunikaty uczestników pojawiaªy si naprzemiennie (zewn trzny blok alt). Scenariusz dobiega ko«ca, gdy zostaj ustalone warunki kontraktu (strony zgadzaj si na swoje» dania) lub która± ze stron zerwie negocjacje (zewn trzna p tla). Dziaªanie zintegrowanego z drugim scenariuszem algorytmu komputerowego przedstawiono na rysunku Centralnym elementem zintegrowanego algorytmu jest w zeª decyzyjny, który uwzgl dnia zaªo»enia przyj tego scenariusza negocjacji. Zale»nie od tego, czy partner przesªaª wiadomo± z ofert czy nie, podejmowana jest odpowiednia akcja spo±ród nast puj cych: przedstawienie oferty partnerowi je±li trzeba przedstawi pocz tkowe» dania lub podj to decyzj o modykacji» da«algorytmu. Decyzja o modykacji» da«algorytmu mo»e zosta podj ta zarówno, gdy partner zmodykowaª swoje» dania, jak i wtedy, gdy partner nie chce ust pi w swoich» daniach i je podtrzymuje; decyzja o oczekiwaniu na propozycj partnera je±li podj to decyzj by nie zmienia aktualnej oferty algorytmu; przeanalizowanie oferty partnera je±li partner przedstawiª swoj pocz tkow ofert lub modykacj swoich» da«; zatwierdzenie kontraktu je±li wszystkie» dania algorytmu s zgodne z» daniami partnera.

105 4.5. EKSPERYMENTY NEGOCJACYJNE Rysunek 4.17: Diagram aktywno±ci UML algorytmu negocjuj cego zintegrowanego ze scenariuszem negocjacji

106 4.5. EKSPERYMENTY NEGOCJACYJNE Proces analizy oferty mo»e zako«czy si : akceptacj» dania partnera; decyzj o modykacji» da«algorytmu; decyzj,»e historia ofert partnera jest nieakceptowalna i wysªaniu ostrze-»enia,»e je±li partner nie zmieni swojego zachowania to zostan zerwane negocjacje; decyzj o zerwaniu negocjacji, je±li mimo ostrze»e«partner próbuje przeforsowa nieakceptowalne propozycje. Proces zmiany» da«rozpoczyna si od decyzji, czy zmieni temat negocjacji na inne zagadnienie negocjacji. Je±li zostanie podj ta taka decyzja to partner jest o tym informowany. Zawsze jest prezentowana nowa warto±» da«dotycz ca aktualnie dyskutowanego zagadnienia negocjacji. W przypadku prezentowania partnerowi komunikatów nie dotycz cych warto±ci zagadnie«negocjacji mo»liwe jest korzystanie ze sªownika wyra»e«kontekstowych. Pozwala to na bardziej naturalne prezentowanie pewnych kwestii czªowiekowi, poniewa» komunikat powtarzany za ka»dym razem w identycznej formie wygl da sztucznie i mo»e irytowa ludzi. Wybór komunikatu spo±ród wielu dost pnych o synonimicznym znaczeniu zwi ksza przyjazno± komunikacji algorytmu komputerowego z czªowiekiem. W przeprowadzonych eksperymentach wprowadzono do sªownika zestaw kilku wypowiedzi informuj cych o ch ci zmiany tematu dyskusji na inne zagadnienie negocjacyjne, poniewa» to byª najcz ±ciej powtarzaj cy si komunikat nieliczbowy. Tabela 4.2 przedstawia list akcji i reakcji, jakie mog wyst pi w negocjacjach. W kolumnach s wymienione mo»liwe akcje, a w wierszach reakcje na poszczególne akcje. Symbolami + i o s oznaczone reakcje, które mog wyst pi a symbolem - s oznaczone reakcje, które nie powinny wyst pi. Zaproponowany algorytm negocjuj cy ma zaimplementowany zbiór reakcji oznaczony symbolem +. Z tego wynika m. in.,»e na» danie lub odpowied¹

107 4.5. EKSPERYMENTY NEGOCJACYJNE Tabela 4.2: Tabela akcji i reakcji dost pnych w trakcie negocjacji Akcje Reakcje» danie/ czekanie ostrze»enie kontrakt zerwanie odpowied¹ negocjacji» danie/ + + o - - odpowied¹ czekanie o + o - - ostrze»enie + o o - - kontrakt zerwanie + o o - + negocjacji partnera algorytm zawsze w jaki± sposób odpowiada, a na ostrze»enie udzielone przez partnera algorytm nie potra reagowa itd. W tym przypadku przyj to,»e partnerem algorytmu jest czªowiek. System GAJA zintegrowany z opisanymi tu scenariuszami negocjacji oraz algorytmem negocjuj cym tworzy ±rodowisko po±rednicz ce, które pozwala na analizowanie i przeprowadzanie negocjacji niezale»nie od domeny biznesowej i przyj tego modelu biznesowego. Tabele 4.3 i 4.4 okre±laj powsta- ªy system GAJA w kontek±cie taksonomii montrealskiej (por. podrozdziaª 2.1.1). Tabela 4.3: Kryteria wewn trzne sprecyzowane taksonomii montrealskiej w odniesieniu do systemu GAJA Uczestnicy Agenci dowolna liczba,»aden nie jest mediatorem. 1 agent przypada na 1 stron negocjacji.

108 4.5. EKSPERYMENTY NEGOCJACYJNE Dost pno± Identykacja Wspóªpraca Wariacje Rundy Etapy Wspóªbie»no± Zagadnienia negocjacji Warto±ci zagadnie«negocjacji Elastyczno± ofert Struktura ofert Zale»no±ci pomi dzy ofertami Obiekty negocjacji ograniczona do zarejestrowanych u»ytkowników, negocjatorzy wyznaczani przez eksperta. mo»na jednoznacznie zidentykowa agentów. nie dotyczy, system GAJA nie peªni roli e-rynku. niedozwolone. 1 runda. 1 etap. niedozwolona. ró»na ilo±, staªa dla jednych negocjacji. jedna warto±. dozwolona. gdy agentami s tylko ludzie jest dynamiczna, gdy jednym z agentów jest algorytm komputerowy struktura ofert jest niezmienna. oferty s powi zane ze sob i s skªadane sekwencyjnie. dowolne. Strony negocjacji ka»da mo»e przedstawia oferty. Pozycja agentów 1 pozycja. Aktywno± ograniczenia czasowe i nakªadane przez medium komunikacyjne. Kierunek skªadania ofert dowolny. Warto± kierunek zdeniowany.

109 4.5. EKSPERYMENTY NEGOCJACYJNE Próg istniej obustronne progi akceptacji ofert. Harmonogram Sortowanie ofert Ocena ofert ci gªe skªadanie ofert. nie dotyczy, system nie zapewnia narz dzi rekomendacji ofert. nie dotyczy, system nie zapewnia narz dzi rekomendacji ofert. Dobór ofert nie dotyczy, system nie peªni roli e- rynku. Dystrybucja ofert ceny mog by zró»nicowane. Prowizja nie dotyczy, system nie peªni roli e- rynku. Konguracja agenci samodzielnie decyduj si na skorzystanie z konkretnej oferty. Zaanga»owanie Komunikacja Historia transakcji Historii negocjacji Widoczno± negocjacji ladowo± Zawarto± informacyjna ofert Koordynacja akceptacja ofert jest wi» ca. je±li agentami s wyª cznie ludzie komunikacja jest pozbawiona ogranicze«, je±li jednym z agentów jest algorytm komputerowy to komunikacja jest ograniczona do ofert. niedost pna dla agentów. dost pna dla agentów. tylko dla negocjuj cych agentów. agent mo»e by anonimowy dla innych negocjatorów (stosowanie pseudonimów). caªo± oferty widoczna. informacje ujawniane s natychmiastowo.

110 4.5. EKSPERYMENTY NEGOCJACYJNE Opªaty nie dotyczy, system nie peªni roli e- rynku. Arbitracja odrzucanie akcji niezgodnych ze scenariuszem. Ranking agenci s oceniani, do wgl du eksperta analizuj cego negocjacje. Tabela 4.4: Kryteria wewn trzne wywiedzione taksonomii montrealskiej w odniesieniu do systemu GAJA Optymalno± pareto tak. Maksymalizacja wyniku negocjacji tak. Sprawiedliwo± nie dotyczy, system nie peªni roli e- rynku. Zbie»no± proces negocjacji zawsze zbie»ny. Stabilno± tak. Prawdziwo± zachowa«zale»y od agentów. Natura zysków zale»nie od zadania negocjacyjnego Porównanie wyników eksperymentów Po przeprowadzeniu eksperymentów z ró»nymi scenariuszami negocjacyjnymi mo»na zaobserwowa znaczn popraw wyników negocjacji w przypadku drugiego scenariusza negocjacji (rysunek 4.18). Jak wida, liczba zerwanych negocjacji spadªa do poziomu 16,33% wzgl dem 25%, po wykorzystaniu drugiej wersji scenariusza negocjacyjnego. Mimo to, ci gle jest to znacznie wi cej ni» w przypadku negocjacji pomi dzy lud¹mi.

111 4.5. EKSPERYMENTY NEGOCJACYJNE Rysunek 4.18: Porównanie ilo±ci zerwanych negocjacji w eksperymentach negocjacyjnych Rysunek 4.19 przedstawia procentowy rozkªad wyników negocjacji dla eksperymentów negocjacyjnych z udziaªem ludzi i dla negocjacji z komputerem, dla obydwu przetestowanych scenariuszy negocjacyjnych. Ka»dy zestaw sªupków przedstawia ile procent eksperymentów negocjacyjnych uzyska- ªo skuteczno± z oznaczonego zakresu warto±ci skuteczno±ci (por. podrozdziaª 3.5). Dodatkowo rysunek 4.20 przedstawia porównanie ±rednich skuteczno±ci negocjacji w badanych eksperymentach. Analizuj c te dane mo»na wywnioskowa,»e najwi ksza ró»nica w wynikach negocjacji jest w ilo±ci zerwanych negocjacji. rednia skuteczno± negocjacji jest podobna we wszystkich przypadkach negocjacyjnych. Podobnie mo»na zauwa»y,»e najwi cej jest wyników negocjacji o skuteczno±ci w przedziale 0,40,6 a nast pnie 0,20,4. Uwag zwraca fakt,»e negocjacje z algorytmem komputerowym wykorzystuj ce 1. scenariusz maj najwi kszy procentowy udziaª wyników skuteczno±ci w przedziale 0,60,8. Jest tak, poniewa» w tym przypadku negocjatorzy nie mieli mo»liwo±ci testowania swojego partnera i próbowania przeforsowania swojej pozycji, a próba negocjo-

MiASI. Modelowanie analityczne. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

MiASI. Modelowanie analityczne. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska MiASI Modelowanie analityczne Piotr Fulma«ski Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska 18 stycznia 2010 Spis tre±ci 1 Czym jest modelowanie analityczne? 2 Podstawowe kategorie poj ciowe

Bardziej szczegółowo

Propozycja integracji elementów ±wiata gry przy u»yciu drzew zachowa«

Propozycja integracji elementów ±wiata gry przy u»yciu drzew zachowa« Praca cz ±ciowo sponsorowana przez Ministerstwo Nauki i Szkolnictwa Wy»szego, grant nr N N519 172337, Integracyjna metoda wytwarzania aplikacji rozproszonych o wysokich wymaganiach wiarygodno±ciowych.

Bardziej szczegółowo

EDUKARIS - O±rodek Ksztaªcenia

EDUKARIS - O±rodek Ksztaªcenia - O±rodek Ksztaªcenia Zabrania si kopiowania i rozpowszechniania niniejszego regulaminu przez inne podmioty oraz wykorzystywania go w dziaªalno±ci innych podmiotów. Autor regulaminu zastrzega do niego

Bardziej szczegółowo

Politechnika Warszawska Wydział Matematyki i Nauk Informacyjnych ul. Koszykowa 75, 00-662 Warszawa

Politechnika Warszawska Wydział Matematyki i Nauk Informacyjnych ul. Koszykowa 75, 00-662 Warszawa Zamawiający: Wydział Matematyki i Nauk Informacyjnych Politechniki Warszawskiej 00-662 Warszawa, ul. Koszykowa 75 Przedmiot zamówienia: Produkcja Interaktywnej gry matematycznej Nr postępowania: WMiNI-39/44/AM/13

Bardziej szczegółowo

MiASI. Modelowanie systemów informatycznych. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

MiASI. Modelowanie systemów informatycznych. Piotr Fulma«ski. 18 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska MiASI Modelowanie systemów informatycznych Piotr Fulma«ski Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska 18 stycznia 2010 Spis tre±ci 1 Analiza systemu informatycznego Poziomy analizy 2

Bardziej szczegółowo

JAO - J zyki, Automaty i Obliczenia - Wykªad 1. JAO - J zyki, Automaty i Obliczenia - Wykªad 1

JAO - J zyki, Automaty i Obliczenia - Wykªad 1. JAO - J zyki, Automaty i Obliczenia - Wykªad 1 J zyki formalne i operacje na j zykach J zyki formalne s abstrakcyjnie zbiorami sªów nad alfabetem sko«czonym Σ. J zyk formalny L to opis pewnego problemu decyzyjnego: sªowa to kody instancji (wej±cia)

Bardziej szczegółowo

KLASYCZNE ZDANIA KATEGORYCZNE. ogólne - orzekaj co± o wszystkich desygnatach podmiotu szczegóªowe - orzekaj co± o niektórych desygnatach podmiotu

KLASYCZNE ZDANIA KATEGORYCZNE. ogólne - orzekaj co± o wszystkich desygnatach podmiotu szczegóªowe - orzekaj co± o niektórych desygnatach podmiotu ➏ Filozoa z elementami logiki Na podstawie wykªadów dra Mariusza Urba«skiego Sylogistyka Przypomnij sobie: stosunki mi dzy zakresami nazw KLASYCZNE ZDANIA KATEGORYCZNE Trzy znaczenia sªowa jest trzy rodzaje

Bardziej szczegółowo

Baza danych - Access. 2 Budowa bazy danych

Baza danych - Access. 2 Budowa bazy danych Baza danych - Access 1 Baza danych Jest to zbiór danych zapisanych zgodnie z okre±lonymi reguªami. W w»szym znaczeniu obejmuje dane cyfrowe gromadzone zgodnie z zasadami przyj tymi dla danego programu

Bardziej szczegółowo

MiASI. Modelowanie integracji systemów. Piotr Fulma«ski. 26 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

MiASI. Modelowanie integracji systemów. Piotr Fulma«ski. 26 stycznia Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska MiASI Modelowanie integracji systemów Piotr Fulma«ski Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska 26 stycznia 2010 Spis tre±ci 1 Czym jest integracja systemów informatycznych? 2 Integracja

Bardziej szczegółowo

Zarządzanie projektami. wykład 1 dr inż. Agata Klaus-Rosińska

Zarządzanie projektami. wykład 1 dr inż. Agata Klaus-Rosińska Zarządzanie projektami wykład 1 dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania konkretnego, wymiernego rezultatu produkt projektu

Bardziej szczegółowo

przewidywania zapotrzebowania na moc elektryczn

przewidywania zapotrzebowania na moc elektryczn do Wykorzystanie do na moc elektryczn Instytut Techniki Cieplnej Politechnika Warszawska Slide 1 of 20 do Coraz bardziej popularne staj si zagadnienia zwi zane z prac ¹ródªa energii elektrycznej (i cieplnej)

Bardziej szczegółowo

Przypomnienie najważniejszych pojęć z baz danych. Co to jest baza danych?

Przypomnienie najważniejszych pojęć z baz danych. Co to jest baza danych? Przypomnienie najważniejszych pojęć z baz danych. Co to jest baza danych? 1 Podstawowe pojęcia: 2 3 4 5 Dana (ang.data) najmniejsza, elementarna jednostka informacji o obiekcie będąca przedmiotem przetwarzania

Bardziej szczegółowo

Android. Podstawy tworzenia aplikacji. Piotr Fulma«ski. March 4, 2015

Android. Podstawy tworzenia aplikacji. Piotr Fulma«ski. March 4, 2015 Android Podstawy tworzenia aplikacji Piotr Fulma«ski Instytut Nauk Ekonomicznych i Informatyki, Pa«stwowa Wy»sza Szkoªa Zawodowa w Pªocku, Polska March 4, 2015 Table of contents Framework Jednym z najwarto±ciowszych

Bardziej szczegółowo

Harmonogramowanie projektów Zarządzanie czasem

Harmonogramowanie projektów Zarządzanie czasem Harmonogramowanie projektów Zarządzanie czasem Zarządzanie czasem TOMASZ ŁUKASZEWSKI INSTYTUT INFORMATYKI W ZARZĄDZANIU Zarządzanie czasem w projekcie /49 Czas w zarządzaniu projektami 1. Pojęcie zarządzania

Bardziej szczegółowo

Listy i operacje pytania

Listy i operacje pytania Listy i operacje pytania Iwona Polak iwona.polak@us.edu.pl Uniwersytet l ski Instytut Informatyki pa¹dziernika 07 Który atrybut NIE wyst puje jako atrybut elementów listy? klucz elementu (key) wska¹nik

Bardziej szczegółowo

Wzorce projektowe kreacyjne

Wzorce projektowe kreacyjne Wzorce projektowe kreacyjne Krzysztof Ciebiera 14 pa¹dziernika 2005 1 1 Wst p 1.1 Podstawy Opis Ogólny Podstawowe informacje Wzorce kreacyjne sªu» do uabstrakcyjniania procesu tworzenia obiektów. Znaczenie

Bardziej szczegółowo

Rzut oka na zagadnienia zwi zane z projektowaniem list rozkazów

Rzut oka na zagadnienia zwi zane z projektowaniem list rozkazów Rzut oka na zagadnienia zwi zane z projektowaniem list rozkazów 1 Wst p Przypomnijmy,»e komputer skªada si z procesora, pami ci, systemu wej±cia-wyj±cia oraz po- ª cze«mi dzy nimi. W procesorze mo»emy

Bardziej szczegółowo

Podstawy modelowania w j zyku UML

Podstawy modelowania w j zyku UML Podstawy modelowania w j zyku UML dr hab. Bo»ena Wo¹na-Szcze±niak Akademia im. Jan Dªugosza bwozna@gmail.com Wykªad 8 Diagram pakietów I Diagram pakietów (ang. package diagram) jest diagramem strukturalnym,

Bardziej szczegółowo

i, lub, nie Cegieªki buduj ce wspóªczesne procesory. Piotr Fulma«ski 5 kwietnia 2017

i, lub, nie Cegieªki buduj ce wspóªczesne procesory. Piotr Fulma«ski 5 kwietnia 2017 i, lub, nie Cegieªki buduj ce wspóªczesne procesory. Piotr Fulma«ski Uniwersytet Šódzki, Wydziaª Matematyki i Informatyki UŠ piotr@fulmanski.pl http://fulmanski.pl/zajecia/prezentacje/festiwalnauki2017/festiwal_wmii_2017_

Bardziej szczegółowo

Zobacz to na własne oczy. Przyszłość już tu jest dzięki rozwiązaniu Cisco TelePresence.

Zobacz to na własne oczy. Przyszłość już tu jest dzięki rozwiązaniu Cisco TelePresence. Informacje dla kadry zarządzającej Zobacz to na własne oczy. Przyszłość już tu jest dzięki rozwiązaniu Cisco TelePresence. 2010 Cisco i/lub firmy powiązane. Wszelkie prawa zastrzeżone. Ten dokument zawiera

Bardziej szczegółowo

Metody numeryczne i statystyka dla in»ynierów

Metody numeryczne i statystyka dla in»ynierów Kierunek: Automatyka i Robotyka, II rok Wprowadzenie PWSZ Gªogów, 2009 Plan wykªadów Wprowadzenie, podanie zagadnie«, poj cie metody numerycznej i algorytmu numerycznego, obszar zainteresowa«i stosowalno±ci

Bardziej szczegółowo

Podstawa programowa kształcenia ogólnego informatyki w gimnazjum

Podstawa programowa kształcenia ogólnego informatyki w gimnazjum 1 Podstawa programowa kształcenia ogólnego informatyki w gimnazjum Obowiązująca podstawa programowa nauczania informatyki w gimnazjum, w odniesieniu do propozycji realizacji tych zagadnień w podręcznikach

Bardziej szczegółowo

Zmiany w Podstawie programowej przedmiotów informatycznych

Zmiany w Podstawie programowej przedmiotów informatycznych Spotkania Koordynatorów ds. Innowacji w Edukacji, 8 kwietnia 2016, MEN Zmiany w Podstawie programowej przedmiotów informatycznych dr Anna Beata Kwiatkowska Rada ds. Informatyzacji Edukacji Motto dla działań

Bardziej szczegółowo

Regulamin Usªugi VPS

Regulamin Usªugi VPS Regulamin Usªugi VPS 1 (Poj cia) Poj cia u»ywane w niniejszym Regulaminie maj znaczenia jak okre±lone w Ÿ1 Regulaminu Ogólnego Usªug Auth.pl Sp. z o.o. oraz dodatkowo jak ni»ej: Wirtualny Serwer Prywatny

Bardziej szczegółowo

Rozdziaª I. Postanowienia wst pne

Rozdziaª I. Postanowienia wst pne REGULAMIN RADY RODZICÓW PA STWOWEJ SZKOŠY MUZYCZNEJ I ST. NR 4 IM. KAROLA KURPI«SKIEGO Rozdziaª I. Postanowienia wst pne Ÿ1 Podstaw prawn niniejszego Regulaminu Rady Rodziców, zwanego dalej Regulaminem

Bardziej szczegółowo

Projekt konceptualny z Baz Danych "Centralny system zarz dzania salami na AGH"

Projekt konceptualny z Baz Danych Centralny system zarz dzania salami na AGH Projekt konceptualny z Baz Danych "Centralny system zarz dzania salami na AGH" Autorzy: Adrian Stanula Grzegorz Stopa Mariusz Sasko Data: 14 XI 2008 rok Spis tre±ci 1 Sformuªowanie zadania projektowego.

Bardziej szczegółowo

ARCHITEKTURA INSTYTUCJI JAKO NARZĘDZIE UŁATWIAJĄCE ZARZĄDZANIE DANYMI

ARCHITEKTURA INSTYTUCJI JAKO NARZĘDZIE UŁATWIAJĄCE ZARZĄDZANIE DANYMI ARCHITEKTURA INSTYTUCJI JAKO NARZĘDZIE UŁATWIAJĄCE ZARZĄDZANIE DANYMI XVIII posiedzenie Rady Infrastruktury Informacji Przestrzennej ZARZĄDZANIE DANYMI PRZESTRZENNYMI UKIERUNKOWANE NA UŻYTKOWNIKA agenda

Bardziej szczegółowo

REGULAMIN KONTROLI ZARZĄDCZEJ W MIEJSKO-GMINNYM OŚRODKU POMOCY SPOŁECZNEJ W TOLKMICKU. Postanowienia ogólne

REGULAMIN KONTROLI ZARZĄDCZEJ W MIEJSKO-GMINNYM OŚRODKU POMOCY SPOŁECZNEJ W TOLKMICKU. Postanowienia ogólne Załącznik Nr 1 do Zarządzenie Nr4/2011 Kierownika Miejsko-Gminnego Ośrodka Pomocy Społecznej w Tolkmicku z dnia 20 maja 2011r. REGULAMIN KONTROLI ZARZĄDCZEJ W MIEJSKO-GMINNYM OŚRODKU POMOCY SPOŁECZNEJ

Bardziej szczegółowo

epuap Ogólna instrukcja organizacyjna kroków dla realizacji integracji

epuap Ogólna instrukcja organizacyjna kroków dla realizacji integracji epuap Ogólna instrukcja organizacyjna kroków dla realizacji integracji Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Bardziej szczegółowo

Regulamin ustalania wysoko±ci, przyznawania i wypªacania stypendium za wyniki w nauce dla doktorantów MIMUW v4.3

Regulamin ustalania wysoko±ci, przyznawania i wypªacania stypendium za wyniki w nauce dla doktorantów MIMUW v4.3 Regulamin ustalania wysoko±ci, przyznawania i wypªacania stypendium za wyniki w nauce dla doktorantów MIMUW v4.3 1 grudnia 2007 Komentarze s pisane kursyw. 1. Doktoranci s dzieleni na kategorie pod wzgl

Bardziej szczegółowo

Platforma do obsługi zdalnej edukacji

Platforma do obsługi zdalnej edukacji Andrzej Krzyżak. Platforma do obsługi zdalnej edukacji Projekt platformy e-learningowej wykonanej w ramach pracy magisterskiej obejmował stworzenie w pełni funkcjonalnego, a zarazem prostego i intuicyjnego

Bardziej szczegółowo

Podstawy modelowania w j zyku UML

Podstawy modelowania w j zyku UML Podstawy modelowania w j zyku UML dr hab. Bo»ena Wo¹na-Szcze±niak Akademia im. Jan Dªugosza bwozna@gmail.com Wykªad 2 Zwi zki mi dzy klasami Asocjacja (ang. Associations) Uogólnienie, dziedziczenie (ang.

Bardziej szczegółowo

Strategia rozwoju kariery zawodowej - Twój scenariusz (program nagrania).

Strategia rozwoju kariery zawodowej - Twój scenariusz (program nagrania). Strategia rozwoju kariery zawodowej - Twój scenariusz (program nagrania). W momencie gdy jesteś studentem lub świeżym absolwentem to znajdujesz się w dobrym momencie, aby rozpocząć planowanie swojej ścieżki

Bardziej szczegółowo

Edycja geometrii w Solid Edge ST

Edycja geometrii w Solid Edge ST Edycja geometrii w Solid Edge ST Artykuł pt.: " Czym jest Technologia Synchroniczna a czym nie jest?" zwracał kilkukrotnie uwagę na fakt, że nie należy mylić pojęć modelowania bezpośredniego i edycji bezpośredniej.

Bardziej szczegółowo

UCHWAŁA NR IV/20/2015 RADY GMINY PRZELEWICE. z dnia 24 lutego 2015 r.

UCHWAŁA NR IV/20/2015 RADY GMINY PRZELEWICE. z dnia 24 lutego 2015 r. UCHWAŁA NR IV/20/2015 RADY GMINY PRZELEWICE z dnia 24 lutego 2015 r. w sprawie zasad i standardów wzajemnego informowania się jednostek samorządu terytorialnego i organizacji pozarządowych o planach, zamierzeniach

Bardziej szczegółowo

PROCEDURA OCENY RYZYKA ZAWODOWEGO. w Urzędzie Gminy Mściwojów

PROCEDURA OCENY RYZYKA ZAWODOWEGO. w Urzędzie Gminy Mściwojów I. Postanowienia ogólne 1.Cel PROCEDURA OCENY RYZYKA ZAWODOWEGO w Urzędzie Gminy Mściwojów Przeprowadzenie oceny ryzyka zawodowego ma na celu: Załącznik A Zarządzenia oceny ryzyka zawodowego monitorowanie

Bardziej szczegółowo

Kontrakt Terytorialny

Kontrakt Terytorialny Kontrakt Terytorialny Monika Piotrowska Departament Koordynacji i WdraŜania Programów Regionalnych Ministerstwo Rozwoju Regionalnego Warszawa, 26 pażdziernika 2012 r. HISTORIA Kontrakty wojewódzkie 2001

Bardziej szczegółowo

Numer obszaru: 8 E-learning w szkole - wykorzystanie platform edukacyjnych w pracy szkoły

Numer obszaru: 8 E-learning w szkole - wykorzystanie platform edukacyjnych w pracy szkoły Numer obszaru: 8 E-learning w szkole - wykorzystanie platform edukacyjnych w pracy szkoły Temat szkolenia: Zastosowania e-learningu na przykładzie platformy Moodle w nauczaniu różnych przedmiotów SZCZEGÓŁOWY

Bardziej szczegółowo

Lab. 02: Algorytm Schrage

Lab. 02: Algorytm Schrage Lab. 02: Algorytm Schrage Andrzej Gnatowski 5 kwietnia 2015 1 Opis zadania Celem zadania laboratoryjnego jest zapoznanie si z jednym z przybli»onych algorytmów sªu» cych do szukania rozwi za«znanego z

Bardziej szczegółowo

Lista kontrolna osiągania interoperacyjności przez system teleinformatyczny regulowany przez projekt dokumentu rządowego

Lista kontrolna osiągania interoperacyjności przez system teleinformatyczny regulowany przez projekt dokumentu rządowego Lista kontrolna osiągania interoperacyjności przez system teleinformatyczny regulowany przez projekt dokumentu rządowego Tytuł dokumentu: projekt rozporządzenia Ministra Spraw Wewnętrznych i Administracji

Bardziej szczegółowo

Spis treści 1. Wstęp 2. Projektowanie systemów informatycznych

Spis treści 1. Wstęp 2. Projektowanie systemów informatycznych Spis treści 1. Wstęp... 9 1.1. Inżynieria oprogramowania jako proces... 10 1.1.1. Algorytm... 11 1.2. Programowanie w językach wysokiego poziomu... 11 1.3. Obiektowe podejście do programowania... 12 1.3.1.

Bardziej szczegółowo

Projekt edukacyjny z informatyki

Projekt edukacyjny z informatyki Zespół Szkół w Ostrowie Projekt edukacyjny z informatyki Marek Zawadzki 2011-11-01 PROJEKT EDUKACYJNY Z INFORMATYKI Temat: Moja szkoła kalendarz oraz prezentacja lub plakat lub ulotka informacyjna. Opiekun:

Bardziej szczegółowo

Metody numeryczne. Wst p do metod numerycznych. Dawid Rasaªa. January 9, 2012. Dawid Rasaªa Metody numeryczne 1 / 9

Metody numeryczne. Wst p do metod numerycznych. Dawid Rasaªa. January 9, 2012. Dawid Rasaªa Metody numeryczne 1 / 9 Metody numeryczne Wst p do metod numerycznych Dawid Rasaªa January 9, 2012 Dawid Rasaªa Metody numeryczne 1 / 9 Metody numeryczne Czym s metody numeryczne? Istota metod numerycznych Metody numeryczne s

Bardziej szczegółowo

PRZEDMIOTOWY SYSTEM OCENIANIA Z ZAJĘĆ KOMPUTEROWYCH

PRZEDMIOTOWY SYSTEM OCENIANIA Z ZAJĘĆ KOMPUTEROWYCH PRZEDMIOTOWY SYSTEM OCENIANIA Z ZAJĘĆ KOMPUTEROWYCH Przedmiotowy system oceniania został skonstruowany w oparciu o następujące dokumenty: 1. ROZPORZĄDZENIE MINISTRA EDUKACJI NARODOWEJ z dnia 30 kwietnia

Bardziej szczegółowo

REGULAMIN REALIZACJI PROJEKTÓW EDUKACYJNYCH W GIMNAZJUM W MIEJSKIEJ GÓRCE. Ustalenia ogólne

REGULAMIN REALIZACJI PROJEKTÓW EDUKACYJNYCH W GIMNAZJUM W MIEJSKIEJ GÓRCE. Ustalenia ogólne REGULAMIN REALIZACJI PROJEKTÓW EDUKACYJNYCH W GIMNAZJUM W MIEJSKIEJ GÓRCE Ustalenia ogólne 1. Uczniowie gimnazjum realizują projekty edukacyjne na podstawie Rozporządzenia Ministra Edukacji Narodowej 10

Bardziej szczegółowo

POLITECHNIKA WROCŠAWSKA WYDZIAŠ ELEKTRONIKI PRACA DYPLOMOWA MAGISTERSKA

POLITECHNIKA WROCŠAWSKA WYDZIAŠ ELEKTRONIKI PRACA DYPLOMOWA MAGISTERSKA POLITECHNIKA WROCŠAWSKA WYDZIAŠ ELEKTRONIKI Kierunek: Specjalno± : Automatyka i Robotyka (AIR) Robotyka (ARR) PRACA DYPLOMOWA MAGISTERSKA Podatny manipulator planarny - budowa i sterowanie Vulnerable planar

Bardziej szczegółowo

PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO

PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO Załącznik Nr 3 do Zarządzenia Nr 59/2012 Starosty Lipnowskiego z dnia 31 grudnia 2012 r. PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO PROWADZONEGO W STAROSTWIE POWIATOWYM W LIPNIE I JEDNOSTKACH

Bardziej szczegółowo

Zagadnienia programowania obiektowego

Zagadnienia programowania obiektowego Janusz Jabªonowski, Andrzej Szaªas Instytut Informatyki MIMUW Janusz Jabªonowski,, Andrzej Szaªas Slajd 1 z 10 Tematyka seminarium Szeroko poj ta tematyka projektowania i programowania obiektowego. Gªówny

Bardziej szczegółowo

Lekcja 9 - LICZBY LOSOWE, ZMIENNE

Lekcja 9 - LICZBY LOSOWE, ZMIENNE Lekcja 9 - LICZBY LOSOWE, ZMIENNE I STAŠE 1 Liczby losowe Czasami spotkamy si z tak sytuacj,»e b dziemy potrzebowa by program za nas wylosowaª jak ± liczb. U»yjemy do tego polecenia: - liczba losowa Sprawd¹my

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA DO ZAPYTANIA KE1/POIG 8.2/13

OPIS PRZEDMIOTU ZAMÓWIENIA DO ZAPYTANIA KE1/POIG 8.2/13 Zapytanie ofertowe - Działanie PO IG 8.2 Warszawa, dnia 13.12.2013 r. OPIS PRZEDMIOTU ZAMÓWIENIA DO ZAPYTANIA KE1/POIG 8.2/13 ISTOTNE INFORMACJE O PROJEKCIE: Celem projektu "Wdrożenie zintegrowanego systemu

Bardziej szczegółowo

Matematyka wykªad 1. Macierze (1) Andrzej Torój. 17 wrze±nia 2011. Wy»sza Szkoªa Zarz dzania i Prawa im. H. Chodkowskiej

Matematyka wykªad 1. Macierze (1) Andrzej Torój. 17 wrze±nia 2011. Wy»sza Szkoªa Zarz dzania i Prawa im. H. Chodkowskiej Matematyka wykªad 1 Macierze (1) Andrzej Torój Wy»sza Szkoªa Zarz dzania i Prawa im. H. Chodkowskiej 17 wrze±nia 2011 Plan wykªadu 1 2 3 4 5 Plan prezentacji 1 2 3 4 5 Kontakt moja strona internetowa:

Bardziej szczegółowo

Program działania. Zespołu Samokształceniowego nauczycieli bibliotekarzy

Program działania. Zespołu Samokształceniowego nauczycieli bibliotekarzy Program działania Zespołu Samokształceniowego nauczycieli bibliotekarzy pracujących w dzielnicy Warszawa Praga Południe na rok szkolny: 2006/2007, 2007/2008, 2008/2009 oprac. Bożena Dawidowska-Langer Pedagogiczna

Bardziej szczegółowo

1 Klasy. 1.1 Denicja klasy. 1.2 Skªadniki klasy.

1 Klasy. 1.1 Denicja klasy. 1.2 Skªadniki klasy. 1 Klasy. Klasa to inaczej mówi c typ który podobnie jak struktura skªada si z ró»nych typów danych. Tworz c klas programista tworzy nowy typ danych, który mo»e by modelem rzeczywistego obiektu. 1.1 Denicja

Bardziej szczegółowo

Numer obszaru: 13. Jak pracować z uczniem uzdolnionym informatycznie? Od grafiki i multimediów do poważnych algorytmów w środowisku Logomocja-Imagine

Numer obszaru: 13. Jak pracować z uczniem uzdolnionym informatycznie? Od grafiki i multimediów do poważnych algorytmów w środowisku Logomocja-Imagine Numer obszaru: 13 Jak pracować z uczniem uzdolnionym informatycznie? Temat szkolenia Od grafiki i multimediów do poważnych algorytmów w środowisku Logomocja-Imagine Symbol szkolenia: PUZIMG SZCZEGÓŁOWY

Bardziej szczegółowo

Ekonometria. wiczenia 13 Metoda ±cie»ki krytycznej. Andrzej Torój. Instytut Ekonometrii Zakªad Ekonometrii Stosowanej

Ekonometria. wiczenia 13 Metoda ±cie»ki krytycznej. Andrzej Torój. Instytut Ekonometrii Zakªad Ekonometrii Stosowanej wiczenia 13 Metoda ±cie»ki krytycznej Instytut Ekonometrii Zakªad Ekonometrii Stosowanej Plan wicze«1 Przykªad: ubieranie choinki 2 3 Programowanie liniowe w analizie czasowej i czasowo-kosztowej projektu

Bardziej szczegółowo

Aplikacje bazodanowe. Laboratorium 1. Dawid Poªap Aplikacje bazodanowe - laboratorium 1 Luty, 22, / 37

Aplikacje bazodanowe. Laboratorium 1. Dawid Poªap Aplikacje bazodanowe - laboratorium 1 Luty, 22, / 37 Aplikacje bazodanowe Laboratorium 1 Dawid Poªap Aplikacje bazodanowe - laboratorium 1 Luty, 22, 2017 1 / 37 Plan 1 Informacje wst pne 2 Przygotowanie ±rodowiska do pracy 3 Poj cie bazy danych 4 Relacyjne

Bardziej szczegółowo

System zarządzania bazą danych (SZBD) Proces przechodzenia od świata rzeczywistego do jego informacyjnej reprezentacji w komputerze nazywać będziemy

System zarządzania bazą danych (SZBD) Proces przechodzenia od świata rzeczywistego do jego informacyjnej reprezentacji w komputerze nazywać będziemy System zarządzania bazą danych (SZBD) Proces przechodzenia od świata rzeczywistego do jego informacyjnej reprezentacji w komputerze nazywać będziemy modelowaniem, a pewien dobrze zdefiniowany sposób jego

Bardziej szczegółowo

Oświadczenie Spółki BRASTER S.A. w przedmiocie przestrzegania przez Spółkę. Dobrych Praktyk Spółek Notowanych na NewConnect

Oświadczenie Spółki BRASTER S.A. w przedmiocie przestrzegania przez Spółkę. Dobrych Praktyk Spółek Notowanych na NewConnect Oświadczenie Spółki BRASTER S.A. w przedmiocie przestrzegania przez Spółkę Dobrych Praktyk Spółek Notowanych na NewConnect PKT DOBRA PRAKTYKA OŚWIADCZENIE O STOSOWANIU DOBREJ PRAKTYKI /NIE/NIEDOTYCZY 1.

Bardziej szczegółowo

Dobre praktyki w zakresie zarządzania ładem architektury korporacyjnej

Dobre praktyki w zakresie zarządzania ładem architektury korporacyjnej Dobre praktyki w zakresie zarządzania ładem architektury korporacyjnej Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH Gospodarczej SGH

Bardziej szczegółowo

PROCEDURY UDZIELANIA ZAMÓWIEŃ PUBLICZNYCH w Powiatowym Urzędzie Pracy w Pile

PROCEDURY UDZIELANIA ZAMÓWIEŃ PUBLICZNYCH w Powiatowym Urzędzie Pracy w Pile Załącznik do Zarządzenia Dyrektora Powiatowego Urzędu Pracy nr 8.2015 z dnia 09.03.2015r. PROCEDURY UDZIELANIA ZAMÓWIEŃ PUBLICZNYCH w Powiatowym Urzędzie Pracy w Pile I. Procedury udzielania zamówień publicznych

Bardziej szczegółowo

Program szkoleniowy Efektywni50+ Moduł III Standardy wymiany danych

Program szkoleniowy Efektywni50+ Moduł III Standardy wymiany danych Program szkoleniowy Efektywni50+ Moduł III 1 Wprowadzenie do zagadnienia wymiany dokumentów. Lekcja rozpoczynająca moduł poświęcony standardom wymiany danych. Wprowadzenie do zagadnień wymiany danych w

Bardziej szczegółowo

4. Zarządzenie wchodzi w życie z dniem podpisania. 26.04.2016 Ewa Budziach. Strona 1 z 9. (data i podpis Dyrektora Szkoły)

4. Zarządzenie wchodzi w życie z dniem podpisania. 26.04.2016 Ewa Budziach. Strona 1 z 9. (data i podpis Dyrektora Szkoły) ZARZĄDZENIE NR 2/2016 Dyrektora I Liceum Ogólnokształcącego im. M. Skłodowskiej- Curie w Szczecinie z dnia 26 kwietnia 2016 r. w sprawie regulaminu udzielania zamówień publicznych, których wartość nie

Bardziej szczegółowo

ANALIZA NUMERYCZNA. Grzegorz Szkibiel. Wiosna 2014/15

ANALIZA NUMERYCZNA. Grzegorz Szkibiel. Wiosna 2014/15 ANALIZA NUMERYCZNA Grzegorz Szkibiel Wiosna 2014/15 Spis tre±ci 1 Metoda Eulera 3 1.1 zagadnienia brzegowe....................... 3 1.2 Zastosowanie ró»niczki...................... 4 1.3 Output do pliku

Bardziej szczegółowo

Lublin, 19.07.2013. Zapytanie ofertowe

Lublin, 19.07.2013. Zapytanie ofertowe Lublin, 19.07.2013 Zapytanie ofertowe na wyłonienie wykonawcy/dostawcy 1. Wartości niematerialne i prawne a) System zarządzania magazynem WMS Asseco SAFO, 2. usług informatycznych i technicznych związanych

Bardziej szczegółowo

Oświadczenie w zakresie stosowanie Dobrych Praktyk Spółek Notowanych na NewConnect DOBRA PRAKTYKA WYJAŚNIENIE

Oświadczenie w zakresie stosowanie Dobrych Praktyk Spółek Notowanych na NewConnect DOBRA PRAKTYKA WYJAŚNIENIE Oświadczenie w zakresie stosowanie Dobrych Praktyk Spółek Notowanych na NewConnect DOBRA PRAKTYKA 1. Spółka powinna prowadzić przejrzystą i efektywną politykę informacyjną, zarówno z wykorzystaniem tradycyjnych

Bardziej szczegółowo

Wzorce projektowe strukturalne cz. 1

Wzorce projektowe strukturalne cz. 1 Wzorce projektowe strukturalne cz. 1 Krzysztof Ciebiera 19 pa¹dziernika 2005 1 1 Wst p 1.1 Podstawowe wzorce Podstawowe wzorce Podstawowe informacje Singleton gwarantuje,»e klasa ma jeden egzemplarz. Adapter

Bardziej szczegółowo

Generalny Dyrektor Ochrony rodowiska. Art.32 ust. 1. Art. 35 ust. 5. Art. 38. Art. 26. Art 27 ust. 3. Art. 27a

Generalny Dyrektor Ochrony rodowiska. Art.32 ust. 1. Art. 35 ust. 5. Art. 38. Art. 26. Art 27 ust. 3. Art. 27a Najwa niejsze kompetencje organów, które odpowiadaj za powo anie i funkcjonowanie sieci obszarów Natura 2000 w Polsce oraz ustalaj ce te kompetencje artyku y ustawy o ochronie przyrody Organ Generalny

Bardziej szczegółowo

SPIS TRE CI. Gospodarka inwestycyjna STRONA

SPIS TRE CI. Gospodarka inwestycyjna STRONA FABRYKA MASZYN SPO YWCZYCH SPOMASZ PLESZEW S.A. PROCES: UTRZYMANIE RUCHU Gospodarka inwestycyjna K-1.00.00 Wydanie 4 Strona 2 Stron 7 SPIS TRE CI 1. Cel procedury... 2. Powi zania.... Zakres stosowania...

Bardziej szczegółowo

KRYTERIA DOSTĘPU. Działanie 2.1,,E-usługi dla Mazowsza (typ projektu: e-administracja, e-zdrowie)

KRYTERIA DOSTĘPU. Działanie 2.1,,E-usługi dla Mazowsza (typ projektu: e-administracja, e-zdrowie) Załącznik nr 1 do Uchwały nr / II / 2015 Komitetu Monitorującego Regionalny Program Operacyjny Województwa Mazowieckiego na lata 201-2020 KRYTERIA DOSTĘPU Działanie 2.1,,E-usługi dla Mazowsza (typ projektu:

Bardziej szczegółowo

Część II.A. Informacje o studiach podyplomowych ANALIZA DANYCH METODY, NARZĘDZIA, PRAKTYKA (nazwa studiów podyplomowych)

Część II.A. Informacje o studiach podyplomowych ANALIZA DANYCH METODY, NARZĘDZIA, PRAKTYKA (nazwa studiów podyplomowych) Część II.A. Informacje o studiach podyplomowych ANALIZA DANYCH METODY, NARZĘDZIA, PRAKTYKA (nazwa studiów podyplomowych) 1. Ogólna charakterystyka studiów podyplomowych 1.1 Ogólne cele kształcenia oraz

Bardziej szczegółowo

Robotyka mobilna. Architektury sterowania w robotyce. Dariusz Pazderski 1. 2 pa¹dziernika 2015. Wykªady z robotyki mobilnej studia niestacjonarne

Robotyka mobilna. Architektury sterowania w robotyce. Dariusz Pazderski 1. 2 pa¹dziernika 2015. Wykªady z robotyki mobilnej studia niestacjonarne Robotyka mobilna Architektury sterowania w robotyce Dariusz Pazderski 1 1 Katedra Sterowania i In»ynierii Systemów, Politechnika Pozna«ska 2 pa¹dziernika 2015 Wprowadzenie Paradygmaty sterowania w robotyce

Bardziej szczegółowo

WZÓR UMOWY DLA PRZETARGU NIEOGRANICZONEGO na realizację szkoleń w ramach projektu Patrz przed siebie, mierz wysoko UMOWA NR.

WZÓR UMOWY DLA PRZETARGU NIEOGRANICZONEGO na realizację szkoleń w ramach projektu Patrz przed siebie, mierz wysoko UMOWA NR. Załącznik nr 6 do SIWZ WZÓR UMOWY DLA PRZETARGU NIEOGRANICZONEGO na realizację szkoleń w ramach projektu Patrz przed siebie, mierz wysoko UMOWA NR. Zawarta w dniu..... roku w. POMIĘDZY:. reprezentowaną

Bardziej szczegółowo

Praca Dyplomowa Magisterska

Praca Dyplomowa Magisterska Internetowa Platform Edukacyjna w Technologii ZOPE Autor: Promotor: Dr in». Adam Doma«ski Politechnika l ska Wydziaª Automatyki, Elektroniki i Informatyki Kierunek Informatyka 22 wrze±nia 2009 Dlaczego

Bardziej szczegółowo

Bash i algorytmy. Elwira Wachowicz. 20 lutego

Bash i algorytmy. Elwira Wachowicz. 20 lutego Bash i algorytmy Elwira Wachowicz elwira@ifd.uni.wroc.pl 20 lutego 2012 Elwira Wachowicz (elwira@ifd.uni.wroc.pl) Bash i algorytmy 20 lutego 2012 1 / 16 Inne przydatne polecenia Polecenie Dziaªanie Przykªad

Bardziej szczegółowo

Dlaczego kompetencje?

Dlaczego kompetencje? Dlaczego kompetencje? Kompetencje to słowo, które słyszymy dziś bardzo często, zarówno w kontekście konieczności wykształcania ich u uczniów, jak i w odniesieniu do naszego osobistego rozwoju zawodowego.

Bardziej szczegółowo

1 Metody iteracyjne rozwi zywania równania f(x)=0

1 Metody iteracyjne rozwi zywania równania f(x)=0 1 Metody iteracyjne rozwi zywania równania f()=0 1.1 Metoda bisekcji Zaªó»my,»e funkcja f jest ci gªa w [a 0, b 0 ]. Pierwiastek jest w przedziale [a 0, b 0 ] gdy f(a 0 )f(b 0 ) < 0. (1) Ustalmy f(a 0

Bardziej szczegółowo

WEBML I UML JAKO NARZĘDZIA PROJEKTOWANIA APLIKACJI INTERNETOWYCH

WEBML I UML JAKO NARZĘDZIA PROJEKTOWANIA APLIKACJI INTERNETOWYCH śyła Kamil 1 WebML, UML, MDE, aplikacje internetowe WEBML I UML JAKO NARZĘDZIA PROJEKTOWANIA APLIKACJI INTERNETOWYCH Niniejszy artykuł przedstawia najbardziej znaczące róŝnice pomiędzy notacją WebML oraz

Bardziej szczegółowo

Podstawy Informatyki i Technologii Informacyjnej

Podstawy Informatyki i Technologii Informacyjnej Automatyka i Robotyka, Rok I Wprowadzenie do systemów operacyjnych PWSZ Gªogów, 2009 Denicja System operacyjny (ang. OS, Operating System) oprogramowanie zarz dzaj ce sprz tem komputerowym, tworz ce ±rodowisko

Bardziej szczegółowo

PROGRAM NR 2(4)/T/2014 WSPIERANIE AKTYWNOŚCI MIĘDZYNARODOWEJ

PROGRAM NR 2(4)/T/2014 WSPIERANIE AKTYWNOŚCI MIĘDZYNARODOWEJ PROGRAM NR 2(4)/T/2014 WSPIERANIE AKTYWNOŚCI MIĘDZYNARODOWEJ IMiT 2014 1 1. CELE PROGRAMU Program ma na celu podnoszenie kwalifikacji zawodowych artystów tańca oraz doskonalenie kadry pedagogicznej i badawczo-naukowej

Bardziej szczegółowo

Jak usprawnić procesy controllingowe w Firmie? Jak nadać im szerszy kontekst? Nowe zastosowania naszych rozwiązań na przykładach.

Jak usprawnić procesy controllingowe w Firmie? Jak nadać im szerszy kontekst? Nowe zastosowania naszych rozwiązań na przykładach. Jak usprawnić procesy controllingowe w Firmie? Jak nadać im szerszy kontekst? Nowe zastosowania naszych rozwiązań na przykładach. 1 PROJEKTY KOSZTOWE 2 PROJEKTY PRZYCHODOWE 3 PODZIAŁ PROJEKTÓW ZE WZGLĘDU

Bardziej szczegółowo

Lekcja 8 - ANIMACJA. 1 Polecenia. 2 Typy animacji. 3 Pierwsza animacja - Mrugaj ca twarz

Lekcja 8 - ANIMACJA. 1 Polecenia. 2 Typy animacji. 3 Pierwsza animacja - Mrugaj ca twarz Lekcja 8 - ANIMACJA 1 Polecenia Za pomoc Baltiego mo»emy tworzy animacj, tzn. sprawia by obraz na ekranie wygl daª jakby si poruszaª. Do animowania przedmiotów i tworzenia animacji posªu» nam polecenia

Bardziej szczegółowo

Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego. Specyfikacja warunków zamówienia

Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego. Specyfikacja warunków zamówienia Załącznik nr 1 Specyfikacja warunków zamówienia Przedmiot zamówienia Wynajem sali szkoleniowej dla uczestników szkoleń w ramach projektu Nowa rola współfinansowanego przez Unię Europejską i Budżet Państwa

Bardziej szczegółowo

Projektowanie bazy danych

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

Bardziej szczegółowo

Zarz dzanie rm. Zasada 7: interaktywna komunikacja. Piotr Fulma«ski. April 22, 2015

Zarz dzanie rm. Zasada 7: interaktywna komunikacja. Piotr Fulma«ski. April 22, 2015 Zarz dzanie rm Zasada 7: interaktywna komunikacja Piotr Fulma«ski Instytut Nauk Ekonomicznych i Informatyki, Pa«stwowa Wy»sza Szkoªa Zawodowa w Pªocku, Polska April 22, 2015 Table of contents Nowoczesna

Bardziej szczegółowo

Excel w logistyce - czyli jak skrócić czas przygotowywania danych i podnieść efektywność analiz logistycznych

Excel w logistyce - czyli jak skrócić czas przygotowywania danych i podnieść efektywność analiz logistycznych Excel w logistyce - czyli jak skrócić czas przygotowywania danych i podnieść efektywność analiz logistycznych Terminy szkolenia 25-26 sierpień 2016r., Gdańsk - Mercure Gdańsk Posejdon**** 20-21 październik

Bardziej szczegółowo

Regulamin rekrutacji do Gimnazjum w Chwaliszewie na rok szkolny 2016/2017

Regulamin rekrutacji do Gimnazjum w Chwaliszewie na rok szkolny 2016/2017 Regulamin rekrutacji do Gimnazjum w Chwaliszewie na rok szkolny 2016/2017 Podstawa prawna: 1. Ustawy z dnia 7 września 1991 r. o systemie oświaty (Dz.U. z 2015 r. poz. 2156 z późn zm.) 2. Rozporządzenie

Bardziej szczegółowo

ZARZ DZANIE ZESPO EM P DR PIOTR PILCH

ZARZ DZANIE ZESPO EM P DR PIOTR PILCH ZARZ DZANIE ZESPO EM P DR PIOTR PILCH Aktywno ci Przeci tni mened erowie Mened erowie odnosz cy sukcesy Mened erowie efektywni Tradycyjne zarz dzanie 32% 13% 19% Komunikowanie si 29% 28% 44% Zarz dzanie

Bardziej szczegółowo

Nazwa kierunku Gospodarka przestrzenna

Nazwa kierunku Gospodarka przestrzenna Nazwa kierunku Gospodarka przestrzenna Tryb studiów stacjonarne Profil studiów ogólnoakademicki Wydział Wydział Nauk o Ziemi Opis kierunku Studia drugiego stopnia na kierunku Gospodarka przestrzenna trwają

Bardziej szczegółowo

PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO

PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO Załącznik nr 4 do Zarządzenia Nr 103/2012 Burmistrza Miasta i Gminy Skawina z dnia 19 czerwca 2012 r. PROGRAM ZAPEWNIENIA I POPRAWY JAKOŚCI AUDYTU WEWNĘTRZNEGO MÓDL SIĘ TAK, JAKBY WSZYSTKO ZALEśAŁO OD

Bardziej szczegółowo

TAK/NIE/NIE DOTYCZY TAK TAK TAK TAK

TAK/NIE/NIE DOTYCZY TAK TAK TAK TAK LP. ZASADA // DOTYCZY KOMENTARZ 1. Spółka powinna prowadzić przejrzystą i efektywną politykę informacyjną, zarówno z wykorzystaniem tradycyjnych metod, jak i z użyciem nowoczesnych technologii oraz najnowszych

Bardziej szczegółowo

SVN - wprowadzenie. 1 Wprowadzenie do SVN. 2 U»ywanie SVN. Adam Krechowicz. 16 lutego Podstawowe funkcje. 2.1 Windows

SVN - wprowadzenie. 1 Wprowadzenie do SVN. 2 U»ywanie SVN. Adam Krechowicz. 16 lutego Podstawowe funkcje. 2.1 Windows SVN - wprowadzenie Adam Krechowicz 16 lutego 2013 1 Wprowadzenie do SVN SVN SubVersion jest systemem kontroli wersji pozwalaj cym wielu u»ytkownikom na swobodne wspóªdzielenie tych samych plików. Pozwala

Bardziej szczegółowo

Wst p do informatyki. Systemy liczbowe. Piotr Fulma«ski. 21 pa¹dziernika 2010. Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska

Wst p do informatyki. Systemy liczbowe. Piotr Fulma«ski. 21 pa¹dziernika 2010. Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska Wst p do informatyki Systemy liczbowe Piotr Fulma«ski Wydziaª Matematyki i Informatyki, Uniwersytet Šódzki, Polska 21 pa¹dziernika 2010 Spis tre±ci 1 Liczby i ich systemy 2 Rodzaje systemów liczbowych

Bardziej szczegółowo

RAPORT Z EWALUACJI WEWNĘTRZNEJ. Młodzieżowego Domu Kultury w Puławach W ROKU SZKOLNYM 2014/2015. Zarządzanie placówką służy jej rozwojowi.

RAPORT Z EWALUACJI WEWNĘTRZNEJ. Młodzieżowego Domu Kultury w Puławach W ROKU SZKOLNYM 2014/2015. Zarządzanie placówką służy jej rozwojowi. RAPORT Z EWALUACJI WEWNĘTRZNEJ Młodzieżowego Domu Kultury w Puławach W ROKU SZKOLNYM 2014/2015 Zarządzanie placówką służy jej rozwojowi. CEL EWALUACJI: PRZEDMIOT EWALUACJI: Skład zespołu: Anna Bachanek

Bardziej szczegółowo

OBIEKTYWNO SUBIEKTYWNO

OBIEKTYWNO SUBIEKTYWNO DOSKONALENIE UMIEJ TNO CI OCENIANIA I EWALUACJI U NAUCZYCIELI IDENTYFIKACJA ORAZ OCENA DO WIADCZENIA NABYTEGO JAKO CZ PREZENTACJI OCENY UMIEJ TNO CI ZAWODOWYCH SEMINARIUMIUM 2: JAK OCENIAMY: OCENIANIE

Bardziej szczegółowo

Odpowiedzi na pytania zadane do zapytania ofertowego nr EFS/2012/05/01

Odpowiedzi na pytania zadane do zapytania ofertowego nr EFS/2012/05/01 Odpowiedzi na pytania zadane do zapytania ofertowego nr EFS/2012/05/01 1 Pytanie nr 1: Czy oferta powinna zawierać informację o ewentualnych podwykonawcach usług czy też obowiązek uzyskania od Państwa

Bardziej szczegółowo

Lista standardów w układzie modułowym

Lista standardów w układzie modułowym Załącznik nr 1. Lista standardów w układzie modułowym Lista standardów w układzie modułowym Standardy są pogrupowane w sześć tematycznych modułów: 1. Identyfikacja i Analiza Potrzeb Szkoleniowych (IATN).

Bardziej szczegółowo

Strukturalne metodyki projektowania systemûw informatycznych

Strukturalne metodyki projektowania systemûw informatycznych Strukturalne metodyki projektowania systemûw informatycznych Kalendarium 1976 ó Chen P. (Entity Relationship Model ñ ERD ) 1978 ó DeMarco T. 1979 ó Yourdon E., Constantine L. 1983 ó Jackson M. 1989 ñ Yourdon

Bardziej szczegółowo

Uniwersalna architektura dla Laboratorium Wirtualnego. Grant badawczy KBN

Uniwersalna architektura dla Laboratorium Wirtualnego. Grant badawczy KBN Uniwersalna architektura dla Laboratorium Wirtualnego Grant badawczy KBN Agenda Wstęp Założenia Funkcjonalność Cele badawcze i utylitarne Urządzenia w projekcie Proponowany zakres współpracy Podsumowanie

Bardziej szczegółowo