OPISYWANIE PROCESÓW BIZNESOWYCH Z WYKORZYSTANIEM PRZYPADKÓW U!YCIA *

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

Download "OPISYWANIE PROCESÓW BIZNESOWYCH Z WYKORZYSTANIEM PRZYPADKÓW U!YCIA *"

Transkrypt

1 Nowoczesne systemy informatyczne dla sektora MSP Jerzy NAWROCKI!ukasz OLEK Instytut Informatyki Politechniki Pozna"skiej OPISYWANIE PROCESÓW BIZNESOWYCH Z WYKORZYSTANIEM PRZYPADKÓW U!YCIA * Streszczenie. Przypadki u#ycia s$ wykorzystywane najcz%&ciej do opisu wymaga" funkcjonalnych systemów informatycznych. Eksperymenty przeprowadzone na Politechnice Pozna"skiej pokaza'y, i# mog$ by( one z powodzeniem wykorzystane do opisu procesów biznesowych jako alternatywa dla notacji graficznych. Przypadki u#ycia s$ pó'formalne: proces biznesowy jest wyra#ony jako sekwencja kroków, a ka#dy krok jest opisany w j%zyku naturalnym. Procesy biznesowe z regu'y trwaj$ d'u#ej ni# wykonywanie poszczególnych wymaga" funkcjonalnych. Pojawia si% wi%c potrzeba zmodyfikowania tego opisu tak, aby odpowiada' naturze takich procesów. W artykule dokonano omówienia bada" dotycz$cych zastosowania przypadków u#ycia do modelowania procesów biznesowych. Przedstawiono pewne rozszerzenia przypadków u#ycia, które zosta'y uznane za interesuj$ce podczas przygotowywania opisów procesów biznesowych. Rozszerzenia te pozwalaj$ wyrazi( metamorfoz% aktorów oraz pokaza( kroki, które musz$ by( wykonane przed g'ównym scenariuszem. 1. Wprowadzenie Istniej$ dwa najwa#niejsze podej&cia do opisywania procesów biznesowych: diagramy i tekst. Prawdopodobnie najbardziej popularny w obszarze opisywania modeli biznesowych jest j%zyk UML [13]. W roku 2004 zaproponowano kolejn$ notacj%, diagramy BPMN [3], które wydaj$ si% bardzo interesuj$ce i staj$ si% coraz bardziej popularne. Je&li chodzi o notacje tekstowe, to z punktu widzenia opisu procesów biznesowych, najwa#niejsze wydaj$ si% przypadki u#ycia. Koncepcj% przypadków u#ycia stworzy' Ivar Jacobson [8], który pocz$tkowo wykorzystywa' je do opisu systemów telekomunikacyjnych. Najpopularniejsz$ form$ opisu przypadków u#ycia jest sekwencja kroków wykonywanych * Praca wykonana w ramach grantu BW

2 2 Autor przez aktorów. Ka#dy krok jest wyra#ony w j%zyku naturalnym. Przypadki u#ycia zosta'y w'$czone do j%zyka UML (jako diagramy przypadków u#ycia) [6] oraz do Rational Unified Process [9]. Dzi%ki temu sta'y si% bardzo popularne. Technika ta zosta'a dopracowana przez Cockburna [4] oraz Adolpha, Bramblea i innych [1]. Cockburn, Adolph i Bramble zaproponowali wiele przydatnych wskazówek dotycz$cych pisania czytelnych przypadków u#ycia. Opis procesów biznesowych ma szczególne znaczenie w przypadku tworzenia systemów informatycznych dla skomplikowanych dziedzin biznesowych. W takiej sytuacji bardzo po#$dane jest przygotowanie dokumentu Koncepcja Dzia'ania (ang. Concept of Operations), który opisuje zastan$ sytuacj%, uzasadnienie potrzeby zmian oraz proponowany system [7]. Zastana sytuacja mo#e by( opisana przy u#yciu notacji tekstowej lub diagramowej. W celu sprawdzenia jako&ci, opis ten powinien by( zaprezentowany nie tylko informatykom, lecz równie# reprezentantom klienta i przysz'ym u#ytkownikom systemu. Tak wi%c wa#ne jest, aby notacja by'a czytelna dla szerokiego grona odbiorców. Na Politechnice Pozna"skiej przeprowadzili&my w 2005 roku eksperyment maj$cy na celu porównanie przypadków u#ycia z diagramami BPMN. Okaza'o si%, i# 'atwiej jest wyszukiwa( b'%dy w przypadkach u#ycia ni# w diagramach BPMN. Podczas przygotowywania procesów biznesowych za pomoc$ przypadków u#ycia zaobserwowali&my pewne wzorce opisowe, które mog$ by( u#yteczne z punktu widzenia opisów procesów biznesowych. Przypadki u#ycia prezentowane w literaturze s$ dedykowane do opisu interakcji cz'owieka z komputerem.. Ten poziom opisu dotyczy stosunkowo krótkich sesji trwaj$cych minuty lub godziny. Na poziomie procesów biznesowych przedzia'y czasowe mog$ trwa( nawet tygodnie lub lata. W rezultacie mo#na zaobserwowa( nowe zjawiska, nie wyst%puj$ce na poziomie interakcji cz'owiek-komputer, np. przekszta'canie jednego aktora w drugiego (metamorfoza aktora). Nast%pny rozdzia' zawiera krótkie wprowadzenie do przypadków u#ycia. Zaobserwowane zjawiska dotycz$ce aktorów s$ przedstawione w rozdziale 3. W trakcie pracy nad procesami biznesowymi bardzo wa#n$ spraw$ jest zrozumienie celu ka#dego procesu i jego kroków. W rozdziale 4 zaproponowali&my przypadek u#ycia z prologiem, w celu wyra#enia kroków, które s$ logicznie po'$czone z danym przypadkiem u#ycia, lecz musz$ by( wykonane przed jego g'ównym scenariuszem. Rozdzia' 5 omawia narz%dzie UC Workbench rozwijane na Politechnice Pozna"skiej, które s'u#y do wygodnego zarz$dzania przypadkami u#ycia.

3 Tytu' referatu 3 2. Przypadki u"ycia Przypadek u#ycia opisuje j%zykiem naturalnym interakcj% pomi%dzy aktorami. Najcz%&ciej jest to interakcja pomi%dzy systemem, a jego u#ytkownikami. Wtedy mamy do czynienia z opisywaniem wymaga" funkcjonalnych. W podobny sposób mo#emy zapisywa( procesy biznesowe. Przypadki u#ycia mog$ przyjmowa( ró#n$ form%. Najprostsza forma, to pojedyncze zdania opisuj$ce jedynie cel przypadku u#ycia. Z drugiej strony przypadek u#ycia mo#e by( w pe'ni ustrukturalizowany, opisuj$cy nie tylko zachowanie, lecz równie# zakres, warunki wst%pne, wyzwalacze, priorytety, czas odpowiedzi itp. (zobacz [1]). W kontek&cie procesów biznesowych nast%puj$ce informacje wydaj$ si% by( najwa#niejsze: - Nazwa przypadku u#ycia, okre&laj$ca cel biznesowy - Aktorzy bior$cy udzia' w przypadkach u#ycia (aktorem mo#e by( cz'owiek, urz$dzenie lub inny system) - G!ówny scenariusz opisuj$cy krok po kroku najcz%stsze zachowanie - Rozszerzenia dodaj$ce do kroków pewne zdarzenia, wraz z krokami alternatywnymi odpowiadaj$cymi tym zdarzeniom. Ta forma przypadków u#ycia wydaje si% by( najpowszechniejsza (por. [8,6,1,16]) Przyk'ad przypadku u#ycia jest zaprezentowany na rys. 1. Nazwa tego przypadku u#ycia brzmi: Zaliczanie semestru. Posiada on takich aktorów jak: Student i Dziekan (w rozdz. 3 omówimy ró#nice pomi%dzy aktorami g'ównymi i wspieraj$cymi). G'ówny scenariusz sk'ada si% z 5 kroków i towarzyszy mu jedno rozszerzenie. UC-1: Zaliczanie semestru G#ówny scenariusz 1. Student ucz%szcza na zaj%cia. 2. Dziekan wyznacza termin z'o#enia indeksów w Dziekanacie. 3. Student zalicza przedmioty i zdaje egzaminy. 4. Student odbywa praktyk% zawodow$. 5. Student oddaje indeks do Dziekanatu w terminie wyznaczonym przez Dziekanat. Rozszerzenia 4a. W danym semestrze nie ma praktyki zawodowej 4a1. Nast%puje przej&cie do kroku 5. Rysunek 1. Przypadek u#ycia opisuj$cy zaliczanie semestru przez studenta. Przypadek u#ycia sk'ada si% ze zbioru scenariuszy posiadaj$cych wspólny cel biznesowy. Ka#de rozszerzenie opisuje inny scenariusz. Przypadki u#ycia w formie przedstawionej na rys. 1 s$ pó'formalne. Maj$ posta( sekwencji kroków, dzi%ki czemu mo#na je automatycznie animowa( (zobacz [11,20]), lecz s$ wyra#one j%zykiem naturalnym, przez co staj$ si% bardziej zrozumia'e dla ludzi nie b%d$cych ekspertami w informatyce.

4 4 Autor Czytelnik mo#e si% zastanawia(, dlaczego przedstawia( procesy biznesowe za pomoc$ opisu tekstowego, zamiast zastosowa( notacje diagramowe, np. BPMN ([19,20]) lub UML ([23])? Z eksperymentów przeprowadzonych na Politechnice Pozna"skiej w 2005 roku wynika, i# przypadki u#ycia opisuj$ce procesy biznesowe s$ prostsze do zrozumienia ni# diagramy BPMN ([3]), tak wi%c ich zastosowanie wydaje si% by( uzasadnione. Przypadki u#ycia s$ czasem mylone z diagramami przypadków u#ycia w j%zyku UML (diagram pokazuje jedynie aktorów i nazwy przypadków u#ycia, lecz pomija g'ówny scenariusz i rozszerzenia) Dobre praktyki dotycz$ce przypadków u"ycia Pisanie dobrych przypadków u#ycia jest sztuk$ wymagaj$c$ do&wiadczenia. Mo#na jednak skorzysta( z dobrych zasad dot. przypadków u#ycia ([1]), aby ustrzec si% podstawowych b'%dów. Wybrane zasady zosta'y zamieszczone poni#ej. - Ma#yZespó#Autorów (ang. SmallWritingTeam). Wielko&( zespo'u pisz$cego przypadki u#ycia to najwa#niejszy czynnik wp'ywaj$cy na ich jako&(. W wi%kszo&ci sytuacji 2-3 osoby powinny by( wystarczaj$ce. - Udzia#Publiczno%ci (ang. ParticipatingAudience). Analitycy rzadko kiedy s$ ekspertami w dziedzinie, któr$ modeluj$. W zwi$zku z tym dobry model wymaga sprz%#enia zwrotnego ekspertów po stronie klienta. Takie osoby patrz$ na model z innej perspektywy i b%d$ w stanie znale)( wi%cej potencjalnych problemów. - Ró"neFormy (ang. MultipleForms). Przypadki u#ycia mog$ przyjmowa( ró#ne formy (patrz rozdz. 2). W zale#no&ci od potrzeby stopnia sformalizowania modelu mo#na wybra( zarys przypadku u#ycia, lub form% w pe'ni ustrukturalizowan$. - Szeroko%&PrzedG#'boko%ci$ i RozwójSpiralny (ang. BreadthBeforeDepth i SpiralDevelopment). Pozyskiwanie wymaga" jest procesem odkrywczym. Pisanie kompletnych przypadków u#ycia ju# na samym pocz$tku jest strat$ energii, gdy# jest du#e prawdopodobie"stwo i# takie przypadki u#ycia b%d$ si% cz%sto zmienia(. Zamiast tego nale#y zacz$( od pewnego tylko zarysu przypadku u#ycia i stopniowo dodawa( szczegó'ów, co pewien czas prosz$c klienta o sprz%#enie zwrotne. - Przegl$dDwupoziomowy (ang. TwoTierReview). Przegl$dy s$ konieczne do zapewnienia wysokiej jako&ci modelu. Model, stworzony przez analityków, musi by( przegl$dany przez szerokie grono recenzentów, zarówno po stronie dostawcy jak i klienta. W zwi$zku z tym warto przeprowadzi( przegl$dy dwupoziomowe. Pierwsze wewn%trzne, s$ przeprowadzane jedynie przez kilka osób, lecz powoduj$ znalezienie wi%kszo&ci defektów. Dzi%ki temu przegl$d zewn%trzny b%dzie si% odbywa' du#o sprawniej, gdy# wtedy recenzenci mog$ si% skupi( jedynie na istotnych b'%dach nie wykrytych wcze&niej.

5 Tytu' referatu 5 - FrazaCzasownikowaWNazwie (ang. VerbPhraseName). Nazwa przypadku u#ycia powinna w jak najlepszy sposób opisywa( jego tre&(. W zwi$zku z tym nie powinno si% stosowa( ogólnych, niewiele znacz$cych nazw (np. G'ówny przypadek u#ycia), lecz fraz% czasownikow$ (np. Przebieg projektu InMoST, Publikowanie artyku!ów) 3. Aktorzy Powszechnie wiadomo, w jaki sposób stosowa( przypadki u#ycia do opisu interakcji pomi%dzy cz'owiekiem a systemem (HCI, ang. Human-Computer Interaction) na poziomie funkcjonalnym (zobacz np. [4,1]). Jednak#e jest znaczna ró#nica pomi%dzy HCI, a modelami biznesowymi. Procesy HCI trwaj$ kilka minut (w niektórych sytuacjach kilka godzin), natomiast procesy biznesowe mog$ trwa( tygodnie, miesi$ce lub nawet lata (Cockburn nazywa poziom procesów biznesowych poziomem podsumowania [4]). W trakcie tworzenia przypadków u#ycia do opisu procesów biznesowych, zaobserwowali&my ró#nego rodzaju zjawiska dotycz$ce aktorów. Te zjawiska chcieli&my opisa( w bie#$cym rozdziale Aktorzy g#ówni i wspieraj$cy Przypadki u#ycia poziomu HCI zawieraj$ aktorów dwojakiego rodzaju: g'ównych i pobocznych. G'ówny aktora, to aktor który pragnie co& uzyska( od systemu w danym momencie [1]. Aktor poboczny to najcz%&ciej urz$dzenie lub system zewn%trzny (np. us'ugi WebServices). Podobne rozró#nienie mo#na zrobi( dla biznesowych przypadków u#ycia. U#yteczne okaza'o si% rozró#nienie na aktorów g'ównych i wspieraj$cych. Za'ó#my, i# pewna osoba my&li o zbudowaniu systemu informatycznego dla gabinetu dentystycznego. Analityk biznesowy zidentyfikowa' trzy role: dentysta, pacjent i sekretarka. Prawdziwa interakcja na poziomie biznesowym zachodzi pomi%dzy dentyst$, a pacjentem sekretarka ma rol% wspieraj$c$. Tak wi%c dentysta i pacjent byliby aktorami g'ównymi, natomiast sekretarka wspieraj$cym. Rozró#nienie pomi%dzy aktorami g'ównymi, a wspieraj$cymi pozwala 'atwiej zrozumie( i zamodelowa( procesy, zanim system komputerowy zostanie wyspecyfikowany i zaimplementowany. G'ówni aktorzy s$ niezast$pieni i nie mog$ by( usuni%ci po wprowadzeniu systemu informatycznego, natomiast rola aktorów wspieraj$cych nie jest wymagana i mo#e by( 'atwo zmieniona lub nawet wymieniona na now$ technologi%.

6 6 Autor 3.2. Aktorzy zbiorowi Na poziomie HCI wyst%puje tylko jedna osoba w danym momencie. W momencie specyfikowania modeli biznesowych, pojawiaj$ si% wiele sytuacji w których krok jest wykonywany przez grup% osób. Przyk'adowo na uniwersytecie wiele decyzji jest podejmowanych przez Rad% Wydzia'u Aktorzy tworzeni dynamicznie Na poziomie HCI aktorzy s$ statyczni. Aktor istnieje zanim dany przypadek u#ycia jest wywo'any i zostaje w systemie do ko"ca wykonywania tego przypadku u#ycia. Poziom biznesowy opisuje procesy, które trwaj$ du#o d'u#ej, zdarzaj$ si% wi%c przypadki u#ycia, w trakcie których powstaje nowy aktor. PRINCE2 to bardzo popularna metodyka zarz$dzania projektami [10]. Mapa procesów PRINCE2 jest przedstawiona na rys. 2. Rysunek 2. Mapa procesów dla metodyki PRINCE2 (zgodnie z [10]). Pierwszy problem jaki si% pojawia: w jaki sposób ten 2-wymiarowy opis przedstawi( za pomoc$ sekwencji kroków przypadków u#ycia. Nale#y pami%ta( i# modelowanie jest &ci&le zwi$zane z uogólnianiem. Sztuk$ jest pomijanie nieistotnych detali. W tym przypadku nale#y si% skupi( na sekwencji procesów SU + IP + (SB & CS) + CP. Wtedy odpowiadaj$cy przypadek u#ycia mo#e wygl$da( nast%puj$co: UC-1: Prowadzenie projektu wg metodyki PRINCE 2 G#ówny scenariusz 1. Rozpocz%cie projektu (SU). 2. Inicjacja projektu (IP). 3. Wykonywanie etapu. 4. Zamykanie projektu (CP) Rozszerzenia 3a. Jest potrzebny dodatkowy etap. 3a1. Krok 3 jest powtarzany. Rysunek 3. Przypadek u#ycia opisuj$cy zarz$dzanie projektem wg PRINCE2.

7 Tytu' referatu 7 Najwa#niejsza wada przypadku u#ycia z rys. 3. to fakt, i# nie specyfikuje on, kto powinien wykona( dany krok. Mo#na dopisa( Kto& na pocz$tku ka#dego kroku, lecz by'aby to tylko sztuczka syntaktyczna. Inna mo#liwo&( to dopisanie Zespo'u Zarz$dzania Projektem (PMT ang. Project Management Team). Lecz PMT jest tworzony podczas fazy Rozpocz%cia projektu (SU). Nie mo#e wykonywa( tego kroku, skoro jeszcze nie istnieje. Aby znale)( rozwi$zanie nale#y przyjrze( si% fazie SU. Pokazana jest ona na rys. 4. Rysunek 4. Rozpocz%cie projektu (SU) w PRINCE2. Skrót PM oznacza kierownika projektu (ang. Project Manager). Jednak#e, zwi%kszenie poziomu szczegó'owo&ci i opisywanie ka#dego z podprocesów jako krok (SU1,..., SU6, IP1,..., IP6 itd.) skutkowa'oby bardzo d'ugimi scenariuszami g'ównymi (zgodnie ze wzorcami przypadków u#ycia [1] g'ówny scenariusz powinien zawiera( od 3 do 9 kroków). Aby rozwi$za( ten problem mo#na wy'$czy( podprocesy SU1, SU2 i SU3 z procesu SU oraz umie&ci( je na wy#szym poziomie w przypadku u#ycia UC-1 (podprocesy SU2 i SU3 zosta'y po'$czone w jeden krok), tak jak pokazano to na rys. 5. UC-2: Prowadzenie projektu wg metodyki PRINCE 2 G#ówni aktorzy: Klient, Dostawca Aktorzy wspieraj$cy: Przew.Komitetu Steruj$cego, Kierownik Projektu, Zespó' Zarz$dzania G#ówny scenariusz 1. Klient i Dostawca powo'uj$ Przew. Komitetu Steruj$cego i Kierownika Projektu (SU1). 2. Przewodnicz$cy i Kierownik Projektu kompletuj$ Zespó' Zarz$dzania (SU2, SU3). 3. Zespó' Zarz$dzania kontynuuje rozpocz%cie projektu (SU4 SU6). 4. Zespó' Zarz$dzania inicjuje projekt (IP). 5. Zespó' Zarz$dzania kontroluje etap. 6. Zespó' Zarz$dzania zamyka projekt (CP). Rozszerzenia 5a. Jest potrzebny jeszcze jeden etap. 5a1. Krok 5 jest powtarzany. Rysunek 5. Poprawiona wersja przypadku u#ycia z rys. 3.

8 8 Autor 3.4. Metamorfoza aktorów Za'ó#my, i# budujemy system zarz$dzania informacj$ dla uniwersytetu. Jednym z g'ównych aktorów b%dzie osoba chc$ca uzyska( dyplom na uniwersytecie. Na pocz$tku osoba ta jest tylko kandydatem, nast%pnie jest ona przyj%ta a# w ko"cu staje si% studentem (po otrzymaniu indeksu i legitymacji studenckiej). Po zdaniu wszystkich egzaminów i obronieniu pracy dyplomowej staje si% absolwentem. Na Politechnice Pozna"skiej istniej$ równie# wolni s'uchacze. Taki s'uchacz mo#e sta( si% normalnym studentem od drugiego roku. Je#eli student nie wywi$#e si% ze swoich zobowi$za" mo#e zosta( skre&lony z listy studentów. Taka metamorfoza mo#e by( przedstawiona za pomoc$ automatu sko"czonego z rys. 6, natomiast rys. 7 przedstawia odpowiadaj$cy przypadek u#ycia. Rysunek 6. Automat sko"czony pokazuj$cy mo#liwe przekszta'cenia aktora. UC-3: Uzyskanie dyplomu G#ówni aktorzy: Aktorzy {Kandydat alias Przyj%ty alias Student alias Absolwent alias Wolny Student alias Usuni%ty} Wspieraj$cy aktorzy: Senat, Rektor, Komisja Rekrutacyjna, Uniwersytet G#ówny scenariusz 1. Senat okre&la regu'y dotycz$ce przyjmowania studentów. 2. Rektor powo'uje Komisj% Rekrutacyjn$. 3. Uniwersytet organizuje drzwi otwarte. 4. Kandydat sk'ada podanie. 5. Komisja Rekrutacyjna obwieszcza list% osób przyj%tych. Kandydat zostaje Przyj%ty. 6. Osoba Przyj%ta zaczyna studiowa(. Osoba przyj%ta staje si' Studentem. 7. Student ko"czy pomy&lnie semestry Student podchodzi do egzaminu dyplomowego. Student zostaje Absolwentem. 9. Absolwent otrzymuje dyplom. Rozszerzenia 5a. Kandydat nie mo#e by( przyj%ty z powodu ograniczonej liczby miejsc. 5a1. Kandydat studiuje jako Wolny Student. Powrót do kroku 8. Rysunek 7. Przypadek u#ycia z metamorfoz$ aktorów.

9 Tytu' referatu 9 4. Scenariusze z prologiem W modelowaniu biznesowym procesy s$ g'ówn$ cz%&ci$ opisu (pozosta'e elementy to aktorzy i obiekty informacyjne). Zrozumienie opisu biznesowego wymaga nie tylko zrozumienia w jaki sposób procesy s$ wykonywane, lecz równie# dlaczego. Adolph [1] pisze: system jest niew!a"ciwy je#eli nie dostarcza us!ug, które s$ warto"ciowe dla u#ytkowników. Parafrazuj$c to zdanie mo#na powiedzie(, #e procesy biznesowe s$ niew'a&ciwe, je#eli nie dostarczaj$ us'ug warto&ciowych dla g'ównych aktorów. Dobry sposób zapisu procesów biznesowych powinien wi%c wspiera( zrozumienie celu ka#dego procesu. Z tego punktu widzenia klasyczne przypadki u#ycia maj$ pewne s'abo&ci przedyskutowane poni#ej. Za'ó#my, #e chcemy kontynuowa( rozwój modelu biznesowego dla uniwersytetu, zarysowanego w roz. 3.4 (zobacz przypadek u#ycia UC-3). Za'ó#my, #e chcemy opisa( krok 8 (zaliczanie semestru). Opis móg'by zawiera( kroki z g'ównego scenariusza przypadku u#ycia UC-4 (rys. 8). Jednak#e ta sekwencja kroków nie pokazuje czynno&ci, jakie musz$ by( wykonane zanim student zaczyna semestr. Proponujemy rozszerzenie formy opisu przypadku u#ycia poprzez dodanie prologu. Prolog okre&la sekwencj% czynno&ci, jakie musz$ by( wykonane przed g'ównym scenariuszem (mo#na równie# pomy&le( o symetrycznym rozszerzeniu epilogu lecz do tej pory nie znale)li&my przyk'adu pokazuj$cego u#yteczno&( takiego rozszerzenia). Rysunek 8 opisuje zaliczenie semestru oraz, w formie prologu, wszystkie czynno&ci, jakie musz$ by( wcze&niej wykonane. UC-4: Zaliczanie semestru G#ówny aktor: Student lub Wolny S'uchacz Aktorzy wspieraj$cy: Rektor, Kierownik Jednostki, Rada Wydzia'u Prolog 1. Rada Wydzia'u uchwala program studiów. 2. Dziekan przydziela zaj%cia do zainteresowanych jednostek i ustala osoby odpowiedzialne za przedmiot. 3. Co najmniej tydzie" przed rozpocz%ciem semestru Dziekan og'asza szczegó'owy rozk'ad zaj%( G#ówny scenariusz 4. Student lub Wolny S'uchacz ucz%szcza na zaj%cia. 5. Dziekan ustala termin z'o#enia indeksów w dziekanacie. 6. Student lub Wolny S'uchacz zdaje egzaminy i zdobywa punkty. 7. Student lub Wolny S'uchacz odbywa praktyk% zawodow$. 8. Student lub Wolny S'uchacz sk'ada indeks w dziekanacie. Rozszerzenia 7a. Na danym semestrze nie ma obowi$zkowej praktyki zawodowej. 7a1. Przej&cie do kroku Rysunek 8. Przypadek u#ycia z prologiem.

10 10 Autor 5. UC Workbench UC Workbench to narz%dzie rozwijane od dwóch lat na Politechnice Pozna"skiej. Pocz$tkowo mia'o s'u#y( wspomaganiu pracy analityka podczas edycji wymaga" u#ytkownika, czyli pomaga( w edycji przypadków u#ycia, generowaniu prototypu funkcjonalnego, szacowaniu pracoch'onno&ci wymaga" [15]. Podczas edycji wymaga" analityk mo#e pod'$czy( pod poszczególne kroki przypadków u#ycia szkice ekranów aplikacji i na tej podstawie wygenerowa( makiet% wymaga". T$ sam$ funkcjonalno&( mo#na wykorzysta( podczas pracy nad biznesowymi przypadkami u#ycia. Tym razem zamiast szkiców projektów ekranów mo#emy do'$czy( diagramy (np. BPMN, UML) obrazuj$ce poszczególne procesy biznesowe (rys. 9). Rysunek 9. Makieta procesu biznesowego z odpowiadaj$cym diagramem BPMN. Dodatkowo UC Workbench umo#liwia wygenerowanie papierowej dokumentacji procesów biznesowych, na podstawie przypadków u#ycia. Taki dokument zawiera nast%puj$ce rozdzia'y: 1. Wprowadzenie 2. Aktorzy 3. Procesy biznesowe 4. Obiekty informacyjne G'ówn$ zalet$ takiego podej&cia jest wystarczy zmieni( jaki& przypadek u#ycia, a system automatycznie zmieni makiet% i dokument.

11 Tytu' referatu Podsumowanie Artyku' przedstawia pewne problemy zwi$zane z opisywaniem procesów biznesowych z wykorzystaniem przypadków u#ycia. Eksperymenty przeprowadzone na Politechnice Pozna"skiej pokaza'y, i# przypadki u#ycia s$ prostsze do zrozumienia ni# diagramy BPMN, wi%c ich wykorzystanie wydaje si% by( uzasadnione. Podczas przygotowywania modeli biznesowych zauwa#yli&my wiele zjawisk dotycz$cych aktorów. D'ugo&( trwania procesów biznesowych jest zdecydowanie wi%ksza od d'ugo&ci trwania sesji interakcji pomi%dzy cz'owiekiem a systemem (ang. HCI Human- Computer Interaction), dlatego mo#na zaobserwowa( np. aktorów tworzonych dynamicznie lub metamorfoz% aktorów (rozdz. 3). Kolejnym zaproponowanym rozszerzeniem jest prolog, który umo#liwia pokazanie kontekstu dla danego przypadku u#ycia. LITERATURA 1. Adolph S., Bramble P., Cockburn A., Pols A.: Patterns for Effective Use Cases. Addison- Wesley (2002) 2. Burns, A., Wellings, A. J.: HRT-HOOD: a structured design method for hard real-time systems, Real-Time Systems, Volume 6, Issue 1, p , January Business Process Modeling Notation Version 1.0, May 2004 (http://www.bpmn.org) 4. Cockburn A.: Writing Effective Use Cases. Addison-Wesley (2000) 5. Douglas C.: Introduction to Statistical Quality Control, Third Edition. Wiley & Sons (1997) 6. Fowler M., Scott K.: UML Distilled. Addison-Wesley (2000) 7. IEEE Guide for Information Technology System Definition Concept of Operations (ConOps) Document, IEEE Std , March Jacobson I., Christerson M., Jonsson P., Overgaard G.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading MA (1992) 9. Kruchten, P.: The Rational Unified Process: An Introduction (2nd Edition). Addison- Wesley (2000) 10. Managing Successful Projects with PRINCE2. The Stationery Office Books (2002) 11. Nawrocki J., Olek!.: A Tool for Use-Case Engineering. Extreme Programming and Agile Methodologies 2005, Lecture Notes in Computer Science 3556, OMG Unified Modeling Language Specification Version 1.5, March 2003 (http://www.omg.org/technology/documents/formal/uml.htm)

12 12 Autor 13. Penker M., Eriksson H. E.: Business Modeling With UML: Business Patterns at Work. Addison-Wesley (2000) 14. Reisig W.: Petri Nets, An Introduction. EATCS, Monographs on Theoretical Computer Science, W.Brauer, G. Rozenberg, A. Salomaa (Eds.), Springer Verlag, Berlin (1985) 15. Ribu K.: Estimating Object-Oriented Software Projects With Use Cases. Master of Science Thesis. University of Oslo (2001) 16. Schneider G., Winters J. P.: Applying Use Cases: A Practical Guide. Addison-Wesley (1998) 17. Harel D.: Statecharts: A visual formalism for complex systems. Weizmann Institute of Science, Dept. of Computer Science (1986) 18. White S.: BPMN and Business Process Management: Nawrocki J., Olek L.: Use Cases Engineering with UC Workbench. in Zielinski K., Szmuc T. (eds): Software Engineering: Evolution and Emerging Technologies, IOS Press 2005, Nawrocki J., N%dza T., Ochodek M., Olek!.: Describing Business Processes with Use Cases, 9th International Conference on Business Information Systems, Lecture Notes in Computer Science, in print. 22. Pilone D., Pitman N.: UML 2.0 in a Nutshell. O Reilly (2005).

Wykorzystanie przypadków użycia do opisywania procesów biznesowych

Wykorzystanie przypadków użycia do opisywania procesów biznesowych OPISYWANIE PROCESÓW BIZNESOWYCH PRZY POMOCY PRZYPADKÓW UŻYCIA 1 Wykorzystanie przypadków użycia do opisywania procesów biznesowych Łukasz Olek 1 Lukasz.Olek@cs.put.poznan.pl Streszczenie Procesy biznesowe

Bardziej szczegółowo

Planowanie adresacji IP dla przedsibiorstwa.

Planowanie adresacji IP dla przedsibiorstwa. Planowanie adresacji IP dla przedsibiorstwa. Wstp Przy podejciu do planowania adresacji IP moemy spotka si z 2 głównymi przypadkami: planowanie za pomoc adresów sieci prywatnej przypadek, w którym jeeli

Bardziej szczegółowo

Bazy danych Podstawy teoretyczne

Bazy danych Podstawy teoretyczne Pojcia podstawowe Baza Danych jest to zbiór danych o okrelonej strukturze zapisany w nieulotnej pamici, mogcy zaspokoi potrzeby wielu u!ytkowników korzystajcych z niego w sposóbs selektywny w dogodnym

Bardziej szczegółowo

ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI

ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI ZESZYTY NAUKOWE WYDZIAŁU ETI POLITECHNIKI GDAŃSKIEJ Nr 3 Seria: Technologie Informacyjne 2005 Instytut Informatyki, Politechnika Poznańska ANIMACJA PRZYPADKÓW UŻYCIA ZA POMOCĄ DIAGRAMÓW SEKWENCJI Streszczenie

Bardziej szczegółowo

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl

Dobre wdrożenia IT cz. I Business Case. www.leoconsulting.pl Dobre wdrożenia IT cz. I Business Case Wprowadzenie Czy wiesz: jak często po wdrożeniu oprogramowania okazuje się, że nie spełnia ono wielu wymagań? jak często decyzja o wdrożeniu systemu informatycznego

Bardziej szczegółowo

Regulamin wyjazdów studenckich na stypendia w ramach Programu Erasmus na Wydziale Pedagogiczno-Artystycznym UAM

Regulamin wyjazdów studenckich na stypendia w ramach Programu Erasmus na Wydziale Pedagogiczno-Artystycznym UAM Regulamin wyjazdów studenckich na stypendia w ramach Programu Erasmus na Wydziale Pedagogiczno-Artystycznym UAM Zasady ogólne 1. Stypendium Erasmus przyznawane jest w oparciu o umowy bilateralne podpisane

Bardziej szczegółowo

ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 6 Seria: Technologie Informacyjne 2008

ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 6 Seria: Technologie Informacyjne 2008 ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 6 Seria: Technologie Informacyjne 2008 Krzysztof Wyrzykowski 2,1, Piotr Kowalski 1 1 Premium Technology Sp. z o.o. Dzia+ In,ynierii Oprogramowania pkowalski@premiumtechnology.pl

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych

Bardziej szczegółowo

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2 Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy

Bardziej szczegółowo

Testy zgodnoci w diagnozowaniu systemów alarmowych

Testy zgodnoci w diagnozowaniu systemów alarmowych Testy zgodnoci w diagnozowaniu systemów alarmowych Ryszard SOBCZAK Politechnika Gdaska,Wydział Elektroniki, Telekomunikacji i Informatyki ul.g.narutowicza 11/12, 80-952 Gdask, e-mail:rsob@pg.gda.pl. Streszczenie:

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

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

Bardziej szczegółowo

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.

Bardziej szczegółowo

Podstawy modelowania biznesowego w inżynierii oprogramowania

Podstawy modelowania biznesowego w inżynierii oprogramowania Podstawy modelowania biznesowego w inżynierii oprogramowania 1. Rola modelowania biznesowego w inżynierii oprogramowania 2. Przegląd notacji (BPMN, UML w zast. biznesowym) 3. Powiązania modeli biznesowych

Bardziej szczegółowo

obsług dowolnego typu formularzy (np. formularzy ankietowych), pobieranie wzorców formularzy z serwera centralnego,

obsług dowolnego typu formularzy (np. formularzy ankietowych), pobieranie wzorców formularzy z serwera centralnego, Wstp GeForms to program przeznaczony na telefony komórkowe (tzw. midlet) z obsług Javy (J2ME) umoliwiajcy wprowadzanie danych według rónorodnych wzorców. Wzory formularzy s pobierane z serwera centralnego

Bardziej szczegółowo

SIEMENS GIGASET REPEATER

SIEMENS GIGASET REPEATER SIEMENS GIGASET REPEATER Wane wskazówki Wane wskazówki Wskazówki bezpieczestwa Gigaset repeater nie jest urzdzeniem wodoodpornym, nie naley wic umieszcza go w wilgotnych pomieszczeniach. Tylko dostarczony

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

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

Bardziej szczegółowo

tel. (+48 81) 538 47 21/22 fax (+48 81) 538 45 80 Wykład 30 21 Ćwiczenia Laboratorium 30 21 Projekt

tel. (+48 81) 538 47 21/22 fax (+48 81) 538 45 80 Wykład 30 21 Ćwiczenia Laboratorium 30 21 Projekt 0-618 Lublin tel. (+8 81) 58 7 1/ fax (+8 81) 58 5 80 Przedmiot: Rok: INF I Inżynieria Semestr: V Rodzaj zajęć i liczba godzin: Studia stacjonarne Studia niestacjonarne Wykład 0 1 Ćwiczenia Laboratorium

Bardziej szczegółowo

PROWIZJE Menad er Schematy rozliczeniowe

PROWIZJE Menad er Schematy rozliczeniowe W nowej wersji systemu pojawił si specjalny moduł dla menaderów przychodni. Na razie jest to rozwizanie pilotaowe i udostpniono w nim jedn funkcj, która zostanie przybliona w niniejszym biuletynie. Docelowo

Bardziej szczegółowo

UML cz. I. UML cz. I 1/1

UML cz. I. UML cz. I 1/1 UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę

Bardziej szczegółowo

Programowanie Obiektowe

Programowanie Obiektowe Programowanie Obiektowe dr in. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl WYKŁAD 1 Wstp, jzyki, obiektowo Cele wykładu Zaznajomienie słuchaczy z głównymi cechami obiektowoci Przedstawienie

Bardziej szczegółowo

Badania marketingowe w pigułce

Badania marketingowe w pigułce Jolanta Tkaczyk Badania marketingowe w pigułce Dlaczego klienci kupuj nasze produkty lub usługi? To pytanie spdza sen z powiek wikszoci menederom. Kady z nich byłby skłonny zapłaci due pienidze za konkretn

Bardziej szczegółowo

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI Inżynieria Rolnicza 7(105)/2008 MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI Agnieszka Buczaj Zakład Fizycznych Szkodliwości Zawodowych, Instytut Medycyny Wsi w Lublinie Halina Pawlak Katedra

Bardziej szczegółowo

Europejska karta jakości staży i praktyk

Europejska karta jakości staży i praktyk Europejska karta jakości staży i praktyk www.qualityinternships.eu Preambu!a Zwa!ywszy,!e:! dla m"odych ludzi wej#cie na rynek pracy po zako$czeniu edukacji staje si% coraz trudniejsze m"odzi ludzie s&

Bardziej szczegółowo

Instrukcja obsługi dodatku InsERT GT Smart Documents

Instrukcja obsługi dodatku InsERT GT Smart Documents Instrukcja obsługi dodatku InsERT GT Smart Documents InsERT, grudzie 2003 http://www.insert.com.pl/office2003 InsERT GT Smart Documents to przygotowany przez firm InsERT specjalny dodatek, umoliwiajcy

Bardziej szczegółowo

Norma IEEE 1058.1-1987 SPMP

Norma IEEE 1058.1-1987 SPMP Norma IEEE 1058.1-1987 SPMP Warszawa, 2004-05-09 IEEE - The Institute for Electrical and Electronics Engineering - Instytut inynierii elektrycznej i elektronicznej SPMP - Software Project Management Plan

Bardziej szczegółowo

Narzędzia CASE dla.net. Łukasz Popiel

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

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl

IO - inżynieria oprogramowania. dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl IO - inżynieria oprogramowania dr inż. M. Żabińska, e-mail: zabinska@agh.edu.pl Metody porządkowania wymagań funkcjonalnych Liczba wymagań funkcjonalnych może być bardzo duża; konieczne jest pewnego rodzaju

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2015/2016 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

Bardziej szczegółowo

Instrukcja dla pracowników Uniwersytetu Rzeszowskiego.

Instrukcja dla pracowników Uniwersytetu Rzeszowskiego. Dost p!do!infrastruktury!informatycznej. Instrukcja dla pracowników Uniwersytetu Rzeszowskiego. Wersja dokumentu: 1.0.0 Rzeszów: 23.10.2009 OPTeam S.A. 35-032 Rzeszów, ul. Lisa Kuli 3 INFORMACJA O NOWYCH

Bardziej szczegółowo

Modu 1 rodowisko programistyczne

Modu 1 rodowisko programistyczne MODU 1 RODOWISKO PROGRAMISTYCZNE 2 Modu 1 rodowisko programistyczne Zawarto jednostki Po zrealizowaniu jednostki bdziesz w stanie: uruchomi prost aplikacj z wykorzystaniem konsoli lub rodowiska programistycznego

Bardziej szczegółowo

Instrumenty rynku pracy dla osób poszukuj cych pracy, aktualnie podlegaj cych ubezpieczeniu spo ecznemu rolników w pe nym zakresie.

Instrumenty rynku pracy dla osób poszukuj cych pracy, aktualnie podlegaj cych ubezpieczeniu spo ecznemu rolników w pe nym zakresie. Instrumentyrynkupracydlaosóbposzukujcychpracy, aktualniepodlegajcychubezpieczeniuspoecznemurolnikówwpenymzakresie. Zdniem1lutego2009r.weszywycieprzepisyustawyzdnia19grudnia2008r. o zmianie ustawy o promocji

Bardziej szczegółowo

=@ /ABCDEFAG, ;@ 'BHIBGJAFIBCKJ,

=@ /ABCDEFAG, ;@ 'BHIBGJAFIBCKJ, =@ /ABCDEFAG, Do Horsens mo!na dosta" si# za pomoc$ publicznego transportu np. autobusem z Lublina przez %ód& lub samolotem. Do listopada 2013 roku istnia'o tanie po'$czenie lotnicze liniami Ryanair z

Bardziej szczegółowo

PREZENTACJA DZIAŁANIA KLASYCZNEGO ALGORYTMU GENETYCZNEGO

PREZENTACJA DZIAŁANIA KLASYCZNEGO ALGORYTMU GENETYCZNEGO Piotr Borowiec PREZENTACJA DZIAŁANIA KLASYCZNEGO ALGORYTMU GENETYCZNEGO Sporód wielu metod sztucznej inteligencji obliczeniowej algorytmy genetyczne doczekały si wielu implementacji. Mona je wykorzystywa

Bardziej szczegółowo

ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 4 Seria: Technologie Informacyjne 2006

ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 4 Seria: Technologie Informacyjne 2006 ZESZYTY NAUKOWE WYDZIAU ETI POLITECHNIKI GDASKIEJ Nr 4 Seria: Technologie Informacyjne 2006 Jacek Pruszyski 1, Krzysztof Wyrzykowski 2 Premium Technology Sp. z o.o., Dzia" In$ynierii Oprogramowania Politechnika

Bardziej szczegółowo

"Do aduj si do wiadczeniem Tieto"

Do aduj si do wiadczeniem Tieto Firma Tieto Poland przy wspópracy z Wydziaem Informatyki i Zarzdzania PWR ma przyjemno zaprosi studentów Politechniki Wrocawskiej na letni program praktyk 2011 "Doaduj si dowiadczeniem Tieto" Dla 5 najlepszych

Bardziej szczegółowo

Projekt okablowania strukturalnego dla I semestru Akademii CISCO we WSIZ Copernicus we Wrocławiu

Projekt okablowania strukturalnego dla I semestru Akademii CISCO we WSIZ Copernicus we Wrocławiu Przygotował: mgr in. Jarosław Szybiski Projekt okablowania strukturalnego dla I semestru Akademii CISCO we WSIZ Copernicus we Wrocławiu 1. Wstp Okablowanie strukturalne to pojcie, którym okrela si specyficzne

Bardziej szczegółowo

SUPLEMENT SM-BOSS WERSJA 6.15

SUPLEMENT SM-BOSS WERSJA 6.15 SUPLEMENT SM-BOSS WERSJA 6.15 Spis treci Wstp...2 Pierwsza czynno...3 Szybka zmiana stawek VAT, nazwy i PKWiU dla produktów...3 Zamiana PKWiU w tabeli PKWiU oraz w Kartotece Produktów...4 VAT na fakturach

Bardziej szczegółowo

w sprawie wprowadzenia procedury naboru pracowników na kierownicze stanowiska urzdnicze i stanowiska urzdnicze w Starostwie Powiatowym w Krasnymstawie

w sprawie wprowadzenia procedury naboru pracowników na kierownicze stanowiska urzdnicze i stanowiska urzdnicze w Starostwie Powiatowym w Krasnymstawie ZARZDZENIE Nr 13/2005 STAROSTY KRASNOSTAWSKIEGO z dnia 29 sierpnia 2005 roku w sprawie wprowadzenia procedury naboru pracowników na kierownicze stanowiska urzdnicze i stanowiska urzdnicze w Starostwie

Bardziej szczegółowo

WIADECTWO INNOWACYJNOCI PRODUKTU

WIADECTWO INNOWACYJNOCI PRODUKTU WIADECTWO INNOWACYJNOCI PRODUKTU I. ZAKRES wiadectwo innowacyjnoci produktu dla ASTEC Sp. z o.o. dotyczy prototypu produktu MDT (Magik Development Tools) w fazie studium wykonalnoci. ASTEC Sp. z o.o. ul.

Bardziej szczegółowo

Wstp. Odniesienie do podstawy programowej

Wstp. Odniesienie do podstawy programowej ! " 1 Wstp Praca dotyczy projektu midzyprzedmiotowego, jaki moe by zastosowany na etapie nauczania gimnazjum specjalnego. Powyszy projekt moe zosta przeprowadzony na zajciach z przedmiotów: informatyka

Bardziej szczegółowo

Pakiet informacyjny ECTS Mechanika i budowa maszyn

Pakiet informacyjny ECTS Mechanika i budowa maszyn Pakiet informacyjny ECTS Mechanika i budowa maszyn 4. REKRUTACJA NA STUDIA 4.1. Podstawy prawne rekrutacji STUDIA PIERWSZEGO STOPNIA Studia wojskowe: 1) Uchwaa nr 44/III/2009 Senatu WAT z dnia 23 kwietnia

Bardziej szczegółowo

System midzybankowej informacji gospodarczej Dokumenty Zastrzeone MIG DZ ver. 2.0. Aplikacja WWW ver. 2.1 Instrukcja Obsługi

System midzybankowej informacji gospodarczej Dokumenty Zastrzeone MIG DZ ver. 2.0. Aplikacja WWW ver. 2.1 Instrukcja Obsługi System midzybankowej informacji gospodarczej Dokumenty Zastrzeone MIG DZ ver. 2.0. Aplikacja WWW ver. 2.1 Instrukcja Obsługi 1.Wymagania techniczne 1.1. Wymagania sprztowe - minimalne : komputer PC Intel

Bardziej szczegółowo

ZASADY REKRUTACJI UCZNIÓW DO IM. MIKO AJA KOPERNIKA W NOWEM

ZASADY REKRUTACJI UCZNIÓW DO IM. MIKO AJA KOPERNIKA W NOWEM ZASADY REKRUTACJI UCZNIÓW DO LICEUM OGÓLNOKSZTACEGO IM. MIKOAJA KOPERNIKA W NOWEM I. Podstawa prawna. 1. Art. 9 ust. 2, art. 10 ust. 1 i ust. 9 ustawy z dnia 6 grudnia 2013 roku o zmianie ustawy o systemie

Bardziej szczegółowo

Wprowadzanie i zmiany faktur z zakupu, wydruk rejestru zakupu

Wprowadzanie i zmiany faktur z zakupu, wydruk rejestru zakupu Sterowanie procedurami programu "Rejestr zakupu" odbywa si poprzez wybór jednej z kilku proponowanych akurat na ekranie moliwoci. U dołu ekranu wypisywany jest komunikat bliej objaniajcy wybran aktualnie

Bardziej szczegółowo

Regulamin przyznawania pomocy materialnej studentom Politechniki Poznaskiej

Regulamin przyznawania pomocy materialnej studentom Politechniki Poznaskiej Załcznik do Zarzdzenia Nr 8 Rektora Politechniki Poznaskiej z dnia 14 marca 2005 r. (RO/III/8/2005) Regulamin przyznawania pomocy materialnej studentom Politechniki Poznaskiej 1 Podstaw prawn stanowi ustawa

Bardziej szczegółowo

MODELOWANIE I PROGRAMOWANIE PRACY

MODELOWANIE I PROGRAMOWANIE PRACY Tadeusz MIKULCZYSKI 1, Daniel NOWAK 2, Rafał WICŁAWEK 3 Instytut Technologii Maszyn i Automatyzacji Politechniki Wrocławskiej, Wrocław 1. Streszczenie. Zaprezentowano metod Grafpol modelowania dyskretnych

Bardziej szczegółowo

Inynieria Systemów Informacyjnych

Inynieria Systemów Informacyjnych pjanusz@intertele.pl Inynieria Systemów Informacyjnych 2004 Paweł Janusz 1. Wstp Technika oprogramowania, któr stosowano w pocztkach informatyki bardzo róniła si od tej, któr uytkownicy posługuj si obecnie.

Bardziej szczegółowo

Klonowanie MAC adresu oraz TTL

Klonowanie MAC adresu oraz TTL 1. Co to jest MAC adres? Klonowanie MAC adresu oraz TTL Adres MAC (Media Access Control) to unikalny adres (numer seryjny) kadego urzdzenia sieciowego (jak np. karta sieciowa). Kady MAC adres ma długo

Bardziej szczegółowo

Mechanizm Finansowy EOG oraz Norweski Mechanizm Finansowy 2004-2009 Fundusz kapitału pocztkowego. (ang. seed money)

Mechanizm Finansowy EOG oraz Norweski Mechanizm Finansowy 2004-2009 Fundusz kapitału pocztkowego. (ang. seed money) (ang. seed money) Mechanizm Finansowy EOG & Norweski Mechanizm Finansowy 2004-2009 Spis treci 1. INFORMACJE OGÓLNE 3 2. Czym jest fundusz kapitału pocztkowego?... 3 3. Wysoko dofinansowania i współfinansowanie...

Bardziej szczegółowo

Bazy danych. Plan wykáadu. Zale*noci funkcyjne. Wykáad 4: Relacyjny model danych - zale*noci funkcyjne. A B

Bazy danych. Plan wykáadu. Zale*noci funkcyjne. Wykáad 4: Relacyjny model danych - zale*noci funkcyjne. A B Plan wykáadu Bazy danych Wykáad 4: Relacyjny model danych - zale*noci funkcyjne. Maágorzata Krtowska Wydziaá Informatyki Politechnika Biaáostocka Deficja zale*noci funkcyjnych Klucze relacji Reguáy dotyczce

Bardziej szczegółowo

Program do konwersji obrazu na cig zero-jedynkowy

Program do konwersji obrazu na cig zero-jedynkowy Łukasz Wany Program do konwersji obrazu na cig zero-jedynkowy Wstp Budujc sie neuronow do kompresji znaków, na samym pocztku zmierzylimy si z problemem przygotowywania danych do nauki sieci. Przyjlimy,

Bardziej szczegółowo

CZY I JAK M IERZY? ROI Z KAPITA?U LUDZKIEGO?

CZY I JAK M IERZY? ROI Z KAPITA?U LUDZKIEGO? CZY I JAK M IERZY? ROI Z KAPITA?U LUDZKIEGO? KAPITA? LUDZKI A ROI Na pierwszy rzut oka mo?e si? wydawa?,?e kapita?ludzki??ywa tkanak firmy? i?cis?y, ekonomiczny wska?nik, jakim jest ROI nie przystaj? do

Bardziej szczegółowo

CYKL ZAJ POZNAJEMY POWER POINT

CYKL ZAJ POZNAJEMY POWER POINT CYKL ZAJ POZNAJEMY POWER POINT TEMAT: Pracujemy w programie Power Point. Czas (4 x 45 minut ) ZAKRES TRECI PROGRAMOWYCH: Bezpieczestwo, higiena i reguły pracy przy komputerze Sposoby porozumiewania si

Bardziej szczegółowo

Program SMS4 Monitor

Program SMS4 Monitor Program SMS4 Monitor INSTRUKCJA OBSŁUGI Wersja 1.0 Spis treci 1. Opis ogólny... 2 2. Instalacja i wymagania programu... 2 3. Ustawienia programu... 2 4. Opis wskaników w oknie aplikacji... 3 5. Opcje uruchomienia

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Feature Driven Development

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

Bardziej szczegółowo

Procedura rekrutacji pracowników do Starostwa Powiatowego w Kielcach

Procedura rekrutacji pracowników do Starostwa Powiatowego w Kielcach Zał. do Zarzdzenia Nr 58/05 Starosty Kieleckiego z dnia 30 grudnia 2005 r. w sprawie wprowadzenia procedury rekrutacji pracowników do Starostwa Powiatowego w Kielcach Procedura rekrutacji pracowników do

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Program kształcenia i plan studiów podyplomowych: Zarządzanie projektami

Program kształcenia i plan studiów podyplomowych: Zarządzanie projektami Program kształcenia i plan studiów podyplomowych: Zarządzanie projektami edycja 15 opracowany zgodnie z Zarządzeniami Wewnętrznymi PWr nr 1/2012 i 15/2012 organizowanego przez Wydział Informatyki i Zarządzania

Bardziej szczegółowo

Ateus - Helios. System domofonowy

Ateus - Helios. System domofonowy Ateus - Helios System domofonowy Klawiatura telefoniczna: Uywajc klawiatury mona wybra dowolny numer abonenta. Helios moe pracowa z wybieraniem DTMF lub impulsowym. Ograniczenia na dostp do sieci publicznej

Bardziej szczegółowo

ROZPORZDZENIE MINISTRA EDUKACJI NARODOWEJ I SPORTU 1)

ROZPORZDZENIE MINISTRA EDUKACJI NARODOWEJ I SPORTU 1) ROZPORZDZENIE MINISTRA EDUKACJI NARODOWEJ I SPORTU 1) z dnia 15 stycznia 2004 r. w sprawie szczegółowego trybu przeprowadzania czynnoci w przewodach doktorskim i habilitacyjnym oraz w postpowaniu o nadanie

Bardziej szczegółowo

Uogólnienie Diagram przypadków u ycia

Uogólnienie Diagram przypadków u ycia 1 Przypadki uycia Przypadki uycia opisuj funkcjonalno systemu widzian z zewntrz przez uytkownika; Definicja Przypadek uycia to opis zbioru cigów akcji i ich wariantów wykonywanych przez system w celu dostarczenia

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

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

Bardziej szczegółowo

KSZTAŁCENIE W ZAKRESIE TELEKOMUNIKACJI W POLITECHNICE ŁÓDZKIEJ

KSZTAŁCENIE W ZAKRESIE TELEKOMUNIKACJI W POLITECHNICE ŁÓDZKIEJ Sławomir Hausman Michał Strzelecki Instytut Elektroniki Politechniki Łódzkiej ul. Wólczaska 223, 90-924 Łód [shausman, mstrzel]@p.lodz.pl www.pwt.et.put.poznan.pl 2005 Poznańskie Warsztaty Telekomunikacyjne

Bardziej szczegółowo

Tworzenie bazy danych Biblioteka tworzenie tabel i powiza, manipulowanie danymi. Zadania do wykonani przed przystpieniem do pracy:

Tworzenie bazy danych Biblioteka tworzenie tabel i powiza, manipulowanie danymi. Zadania do wykonani przed przystpieniem do pracy: wiczenie 2 Tworzenie bazy danych Biblioteka tworzenie tabel i powiza, manipulowanie danymi. Cel wiczenia: Zapoznanie si ze sposobami konstruowania tabel, powiza pomidzy tabelami oraz metodami manipulowania

Bardziej szczegółowo

VPN Virtual Private Network. Uycie certyfikatów niekwalifikowanych w sieciach VPN. wersja 1.1 UNIZETO TECHNOLOGIES SA

VPN Virtual Private Network. Uycie certyfikatów niekwalifikowanych w sieciach VPN. wersja 1.1 UNIZETO TECHNOLOGIES SA VPN Virtual Private Network Uycie certyfikatów niekwalifikowanych w sieciach VPN wersja 1.1 Spis treci 1. CO TO JEST VPN I DO CZEGO SŁUY... 3 2. RODZAJE SIECI VPN... 3 3. ZALETY STOSOWANIA SIECI IPSEC

Bardziej szczegółowo

ARKUSZ EGZAMINACYJNY ETAP PRAKTYCZNY EGZAMINU POTWIERDZAJ CEGO KWALIFIKACJE ZAWODOWE CZERWIEC 2011

ARKUSZ EGZAMINACYJNY ETAP PRAKTYCZNY EGZAMINU POTWIERDZAJ CEGO KWALIFIKACJE ZAWODOWE CZERWIEC 2011 Zawód: technik informatyk Symbol cyfrowy zawodu: 312[01] Numer zadania: 3 Arkusz zawiera informacje prawnie chronione do momentu rozpoczcia egzaminu 312[01]-03-112 Czas trwania egzaminu: 240 minut ARKUSZ

Bardziej szczegółowo

EGZAMIN MATURALNY Z MATEMATYKI

EGZAMIN MATURALNY Z MATEMATYKI Miejsce na naklejk z kodem (Wpisuje zdajcy przed rozpoczciem pracy) KOD ZDAJCEGO MMA-PGP-0 EGZAMIN MATURALNY Z MATEMATYKI POZIOM PODSTAWOWY Czas pracy 0 minut ARKUSZ I MAJ ROK 00 Instrukcja dla zdajcego.

Bardziej szczegółowo

Identyfikacja i modelowanie struktur i procesów biologicznych

Identyfikacja i modelowanie struktur i procesów biologicznych Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie

Bardziej szczegółowo

72 Beata STACHOWIAK Uniwersytet Miko!aja Kopernika w Toruniu POTRZEBY EDUKACYJNE MIESZKA!CÓW WSI A RYNEK PRACY W SPO"ECZE!STWIE INFORMACYJNYM Pocz"tek XXI wieku dla Polski to czas budowania nowego spo!ecze#stwa,

Bardziej szczegółowo

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

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

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

Bardziej szczegółowo

KONCEPCJA ZASTOSOWANIA REGU DECYZYJNYCH W DOBORZE RODKÓW REDUKCJI RYZYKA ZAGRO E

KONCEPCJA ZASTOSOWANIA REGU DECYZYJNYCH W DOBORZE RODKÓW REDUKCJI RYZYKA ZAGRO E PRACE NAUKOWE POLITECHNIKI WARSZAWSKIEJ z. 96 Transport 2013 Adrian Gill Politechnika Poznaska, Instytut Silników Spalinowych i Transportu KONCEPCJA ZASTOSOWANIA REGU DECYZYJNYCH W DOBORZE RODKÓW REDUKCJI

Bardziej szczegółowo

WYMOGI I ZASADY PISANIA PRAC DYPLOMOWYCH (INYNIERSKICH I MAGISTERSKICH) NA WYDZIALE TECHNOLOGII DREWNA SGGW W WARSZAWIE

WYMOGI I ZASADY PISANIA PRAC DYPLOMOWYCH (INYNIERSKICH I MAGISTERSKICH) NA WYDZIALE TECHNOLOGII DREWNA SGGW W WARSZAWIE WYMOGI I ZASADY PISANIA PRAC DYPLOMOWYCH (INYNIERSKICH I MAGISTERSKICH) NA WYDZIALE TECHNOLOGII DREWNA SGGW W WARSZAWIE 1. Wymogi podstawowe Praca dyplomowa: - jest przygotowywana samodzielnie przez studenta,

Bardziej szczegółowo

ZASTOSOWANIE US UG SMS W TRANSPORCIE

ZASTOSOWANIE US UG SMS W TRANSPORCIE PRACE NAUKOWE POLITECHNIKI WARSZAWSKIEJ z. 92 Transport 2013 Zbigniew Kasprzyk, Mariusz Rychlicki Wydzia Transportu, Politechnika Warszawska ZASTOSOWANIE USUG SMS W TRANSPORCIE Rkopis dostarczono, kwiecie

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

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

Bardziej szczegółowo

Kurs Dydaktyk medialny

Kurs Dydaktyk medialny Kurs Dydaktyk medialny Jednym z najdynamiczniej rozwijajcych si zastosowa techniki informacyjnych jest wspomagane komputerowo nauczanie. Konieczno ustawicznego podnoszenia kwalifikacji zawodowych wymusza

Bardziej szczegółowo

Izolacja Anteny szerokopasmowe i wskopasmowe

Izolacja Anteny szerokopasmowe i wskopasmowe Izolacja Anteny szerokopasmowe i wskopasmowe W literaturze technicznej mona znale róne opinie, na temat okrelenia, kiedy antena moe zosta nazwana szerokopasmow. Niektórzy producenci nazywaj anten szerokopasmow

Bardziej szczegółowo

Metodyka dla projektu SYRIUSZ

Metodyka dla projektu SYRIUSZ Metodyka dla projektu SYRIUSZ Wprowadzenie Robert Ganowski Warszawa, 29 lipca 2003 r. Czym się zajmujemy? * Program Low Produkt Change programowy Essential (Uogólnienie, testowanie, Money dokumentacja,

Bardziej szczegółowo

Program Szkoły zdrowego umiechu pt. Klasa I c chce mie zdrowe zby.

Program Szkoły zdrowego umiechu pt. Klasa I c chce mie zdrowe zby. Program Szkoły zdrowego umiechu pt. Klasa I c chce mie zdrowe zby. miech to zdrowie. Jednak wiele osób wstydzi umiechn si tylko dlatego, e nie chce pokaza swoich zbów. Przyczyn takiego zachowania jest

Bardziej szczegółowo

DLA KOGO UMOWY ENTERPRISE?

DLA KOGO UMOWY ENTERPRISE? Kady z Uytkowników posiadajcy co najmniej pakiet B moe zamówi funkcj Umowy Enterprise. Koszt tej modyfikacji to 800 zł netto bez wzgldu na liczb stanowisk. I jak ju wielokrotnie ogłaszalimy, koszt wikszoci

Bardziej szczegółowo

Typy bazy danych Textract

Typy bazy danych Textract Typy bazy danych Typy bazy danych bazy tekstowe, Textract, http://www.textract.com - bazy tekstowe, np. archiwum gazety, dla setek gigabajtów, szybkie wyszukiwanie i indeksacja informacji bazy danych bez

Bardziej szczegółowo

Projekt systemu informatycznego

Projekt systemu informatycznego Projekt systemu informatycznego Kod przedmiotu: PSIo Rodzaj przedmiotu: specjalnościowy ; obieralny Wydział: Informatyki Kierunek: Informatyka Specjalność (specjalizacja): Inżynieria Systemów Informatycznych

Bardziej szczegółowo

Informacja i Promocja. Mechanizm Finansowy EOG Norweski Mechanizm Finansowy

Informacja i Promocja. Mechanizm Finansowy EOG Norweski Mechanizm Finansowy Informacja i Promocja Mechanizm Finansowy EOG Norweski Mechanizm Finansowy Spis treci 1. Wstp... 3 2. Ogólne działania informacyjno - promocyjne... 3 3. Działania informacyjno-promocyjne projektu... 4

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

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

Bardziej szczegółowo

Na jakie przedmioty bdzie uczszczał student pierwszego roku?

Na jakie przedmioty bdzie uczszczał student pierwszego roku? Na jakie przedmioty bdzie uczszczał student pierwszego roku? Student na I roku studiów realizuje 5 przedmiotów obowizkowych koczcych si egzaminem (w ramach kadego przedmiotu s nieobowizkowe wykłady i obowizkowe

Bardziej szczegółowo

WYBRANE METODY DOSKONALENIA SYSTEMÓW ZARZDZANIA. L. KRÓLAS 1, P. KRÓLAS 2 Orodek Kwalifikacji Jakoci Wyrobów SIMPTEST ul. Przemysłowa 34A 61-579 Pozna

WYBRANE METODY DOSKONALENIA SYSTEMÓW ZARZDZANIA. L. KRÓLAS 1, P. KRÓLAS 2 Orodek Kwalifikacji Jakoci Wyrobów SIMPTEST ul. Przemysłowa 34A 61-579 Pozna 22/21 ARCHIWUM ODLEWNICTWA Rok 2006, Rocznik 6, Nr 21(1/2) ARCHIVES OF FOUNDARY Year 2006, Volume 6, Nº 21 (1/2) PAN Katowice PL ISSN 1642-5308 WYBRANE METODY DOSKONALENIA SYSTEMÓW ZARZDZANIA L. KRÓLAS

Bardziej szczegółowo

Jestem w Londynie, rozmawiam i szkol w Szczecinie - grupowe rozmowy audio, wideo bez granic. Prowadz cy: Dominika K pska Kamil Pietrasik

Jestem w Londynie, rozmawiam i szkol w Szczecinie - grupowe rozmowy audio, wideo bez granic. Prowadz cy: Dominika K pska Kamil Pietrasik Jestem w Londynie, rozmawiam i szkol w Szczecinie - grupowe rozmowy audio, wideo bez granic Prowadzcy: Dominika Kpska Kamil Pietrasik Gliwice, 05.06.2012 Harmonogram webinarium 1. Telekonferencje HaloNet

Bardziej szczegółowo

Argumenty na poparcie idei wydzielenia OSD w formie tzw. małego OSD bez majtku.

Argumenty na poparcie idei wydzielenia OSD w formie tzw. małego OSD bez majtku. Warszawa, dnia 22 03 2007 Zrzeszenie Zwizków Zawodowych Energetyków Dotyczy: Informacja prawna dotyczca kwestii wydzielenia Operatora Systemu Dystrybucyjnego w energetyce Argumenty na poparcie idei wydzielenia

Bardziej szczegółowo

TEL-STER Sp. z o. o. ul. Obornicka 229 60-650 Pozna. InWin System Automatycznego Przekazu i Zarzdzania Danymi Inkasenckimi

TEL-STER Sp. z o. o. ul. Obornicka 229 60-650 Pozna. InWin System Automatycznego Przekazu i Zarzdzania Danymi Inkasenckimi TEL-STER Sp. z o. o. ul. Obornicka 229 60-650 Pozna tel. +48 (61) 6562105 fax +48 (61) 6562106 email: biuro@telwin.com.pl http: www.telwin.com.pl InWin System Automatycznego Przekazu i Zarzdzania Danymi

Bardziej szczegółowo

Studium przypadku Case Study CCNA2-ROUTING

Studium przypadku Case Study CCNA2-ROUTING Na podstawie oryginału CISCO, przygotował: mgr in. Jarosław Szybiski Studium przypadku Case Study CCNA2-ROUTING Ogólne załoenia dla projektu Przegld i cele Podczas tego wiczenia uczestnicy wykonaj zadanie

Bardziej szczegółowo

Rynek motoryzacyjny 2011 Europa vs Polska

Rynek motoryzacyjny 2011 Europa vs Polska Rynek motoryzacyjny 2011 Europa vs Polska Rynek cz!"ci motoryzacyjnych nierozerwalnie #$czy si! z parkiem samochodowym, dlatego te% podczas oceny wyników sprzeda%y samochodowych cz!"ci zamiennych nie mo%na

Bardziej szczegółowo

zdefiniowanie kilku grup dyskusyjnych, z których chcemy odbiera informacje, dodawanie, usuwanie lub edycj wczeniej zdefiniowanych grup dyskusyjnych,

zdefiniowanie kilku grup dyskusyjnych, z których chcemy odbiera informacje, dodawanie, usuwanie lub edycj wczeniej zdefiniowanych grup dyskusyjnych, Wstp W nowoczesnym wiecie coraz istotniejsz rol odgrywa informacja i łatwy dostp do niej. Nie dziwi wic fakt, i nowoczesne telefony komórkowe to nie tylko urzdzenia do prowadzenia rozmów telefonicznych,

Bardziej szczegółowo

1. Informacje ogólne.

1. Informacje ogólne. Polityka prywatności (Pliki Cookies) 1. Informacje ogólne. Lęborskie Centrum Kultury Fregata 1. Operatorem Serwisu www.lck-fregata.pl jest L?borskie Centrum Kultury "Fregata" z siedzib? w L?borku (84-300),

Bardziej szczegółowo