Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 4 Zrozumienie stron zainteresowanych
|
|
- Julian Marszałek
- 8 lat temu
- Przeglądów:
Transkrypt
1 Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 4 Zrozumienie stron zainteresowanych Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)
2 Cele Identyfikacja źródeł żądań stron zainteresowanych Opis artefaktu żądań strony zainteresowanej Techniki pozyskiwania żądań stron zainteresowanych: Burza mózgów Identyfikacja wymagań ze specyfikacji opracowanej przez klienta 2
3 W którym miejscu dyscypliny Wymagania jesteśmy? 3
4 Czynności i artefakty (1) 4
5 Czynności i artefakty (2) W procesie RUP bieżącym celem jest pozyskanie (wydobycie) informacji o stron zainteresowanych projektu Informacje te można postrzegać jako listę życzeń używaną jako podstawowe dane do definiowania przypadków użycia i dokumentacji uzupełniającej Ta część workflow odbywa się głównie podczas faz rozpoczęcia (inception) i opracowania (elaboration) 5
6 Czynności i artefakty (3) Niemniej jednak, żądania stron zainteresowanych powinny być gromadzone przez cały czas trwania projektu poprzez przeglądy żądań zmian w procesie CRM (Change Request Management) Należy być świadomym nadchodzących żądań stron w całym cyklu życia projektu, abyśmy przez cały czas mieli pewność, że realizujemy ich rzeczywiste potrzeby 6
7 Czynności i artefakty (4) Kluczową aktywnością jest pozyskiwanie żądań stron i określanie żądanych cech systemu Podstawowe rezultaty są zbiorem spriorytetyzowanych potrzeb i cech stron zainteresowanych, a także przypisane im atrybuty Te rezultaty umieszcza się w dokumencie wizji Ponadto, w tym workflow dyskutuje się system pod kątem przypadków użycia i aktorów Kolejnym istotnym produktem jest zaktualizowany słownik ułatwiający komunikację w ramach zespołu 7
8 Jakie są źródła wymagań? (1) Partnerzy Klienci Specyfikacja wymagań Modele biznesowe Plany biznesowe Cele osobiste Analitycy Użytkownicy Wstępne żądania Raporty błędów Żądania zmian Dziedzina problemowa Wizyty u klienta Eksperci dziedziny Analitycy przemysłowi 8 Informacje o konkurencji
9 Jakie są źródła wymagań? (2) Należy odnaleźć żądania od wszystkich zainteresowanych stron i okreslić, w jaki sposób i czego dotyczą Pomimo, że rolą odpowiedzialną za zbieranie tych informacji jest analityk systemowy, wielu innych ludzi ma w tym udział: marketingowcy, użytkownicy, klienci każdy kto jest stroną zainteresowaną projektu 9
10 Jakie są źródła wymagań? (3) Inne przykłady zewnętrznych źródeł wymagań: Statement of work (SOW, plan pracy) Oferta przetargowa (request for proposal, RFP) Stwierdzenie misji (mission statement) Stwierdzenie problemu (problem statement) Reguły biznesowe Akty prawne i rozporządzenia Systemy spadkowe Modele biznesowe Sesji i warsztaty pozyskiwania wymagań... 10
11 Jak wygląda proces? (1) Wymagania ad hoc od klienta przekazane zespołowi Klient Specyfikacja wymagań Zespół projektowy Odrzucenie przez klienta Poprawiona wersja Ponowne odrzucenie przez klienta Kolejna poprawiona wersja Akceptacja przez klienta 11
12 Jak wygląda proces? (2) Tradycyjne podejście do opracowywania specyfikacji wymagań kładzie nacisk na sukces w pierwszym podejściu... W nowoczesnych technikach produkcji oprogramowania mamy świadomość, że specyfikacja będzie przez cały czas (w pewnym sensie) błędna: I prawie zawsze ponosi porażkę z podstawowych przyczyn Przez cały czas trwania projektu staramy się odnaleźć najlepsze sposoby obniżenia ryzyka w miarę postępów prac Pomiędzy klientem (w właściwie - stronami), a nami powinna przez cały czas odbywać się dyskusja do czasu osiągnięcia zgody dotyczącej wymagań 12
13 Jak wygląda proces? (3) Niektórzy każde odrzucenie naszych propozycji postrzegają jako porażkę w specyfikowaniu wymagań Należy do tego podejść w inny sposób: każde odrzucenie to nowe informacje, które zdobywamy Kiedy klient mowi, że coś mu się nie podoba, daje nam ważne informacje dotyczące tego, co chce mieć w zamian Proces odrzucania pomaga klientowi skupić się na rzeczach istotnych dla jego organizacji 13
14 Jakie problemy możemy napotkać? Strony zainteresowane: Nie wiedzą, czego naprawdę chcą Nie potrafią wyrazić, czego chcą Myślą, że wiedzą czego chcą, ale nie widzą tego w dostarczonym produkcie Analitycy Mają z góry założone prawidłowe (i jedyne słuszne) rozwiązanie Myślą, że rozumieją problemy użytkowników lepiej niż użytkownicy Każdy... widzi rzeczy ze swojego punktu widzenia wierzy, że wszyscy inni mają jakieś motywacje polityczne 14
15 Wyrażanie potrzeb stron zainteresowanych (1) O, taki dinks by się przydał Widziałem w telewizji... Właśnie takie jak to, ale inne... Dobrze by było... I żeby tło było różowe...zgodny ze standardem CSQ-234/4 System musi... Chcę, żeby... ` 15
16 Wyrażanie potrzeb stron zainteresowanych (2) Cechą ludzkiej natury jest przechodzenie do trybu rozwiązania Dzieje się tak, ponieważ podczas wydobywanie potrzeb od stron zainteresowanych, zazwyczaj otrzymujemy je wyrażone jako cechy zamiast określenia, czego potrzebują od rozwiązania w celu rozwiązania problemu biznesowego 16
17 Wyrażanie potrzeb stron zainteresowanych (3) Co należy zrobić z potrzebami wyrażonymi jako cechy? Powiedzieć klientowi: wstrzymaj się, dojdziemy do tego później? Otóż na tym etapie wszystkie żądania klientów powinny zostać odnotowane W odpowiednim czasie należy je zwalidować pod kątem utrzymania ważności i utworzyć z nich wymagania cech Opis nowej cechy może być identyczny z tekstem żądania strony 17
18 Wyrażanie potrzeb stron zainteresowanych (4) Żeby zrozumieć potrzebę kryjącą się za żądaniem wyrażonym jako cecha, należy przeprowadzić rodzaj analizy problemu, na przykład: System śledzenia usterek powinien zapewnić raport trendu statusu projektu Potrzeba została wyrażona jako cecha Żeby zrozumieć potrzebę wyrażoną jako cechę, zapytajmy dlaczego? Odpowiedź mogłaby brzmieć: potrzebujemy dowiedzieć się, czy usterki nie pojawiają się szybciej niż są usuwane To jest rzeczywista potrzeba pod-problem, który będziemy rozwiązywać 18
19 Wyrażanie potrzeb stron zainteresowanych (5) Bez względu na wszystko, należy odnotować każde żądanie (cechę czy potrzebę) i przeprowadzić je przez standardowy proces akceptacji zanim zostanie włączone do systemu Żądania stron wyrażone jako cechy wymagają trochę więcej analizy, żeby sprawdzić czy pozostają ważne i czy są zgodne z celami biznesowymi systemu 19
20 Artefakt żądań stron zainteresowanych (1) Wymagania stron zainteresowanych Dokument wizji Model przyp. użycia Specyfikacja projektowa Specyfikacja uzupełniająca Specyfikacja dokumentacji użytkownika 20
21 Artefakt żądań stron zainteresowanych (2) Właścicielem są strony zainteresowane Zawiera wszystkie żądania stron zainteresowanych Skonsolidowany z wielu źródeł: Maile, nieformalne rozmowy, specyfikacja wymagań klienta, notatki, arkusze, itp. Duża trudność w zarządzaniu (istnieją wyspecjalizowane narzędzia/bazy danych, np. RequisitePro) Używany przez zespół projektowy w celu wydobycia cech i wymagań oprogramowania Może zawierać odniesienie do dowolnych typów źródeł zewnętrznych 21
22 Techniki pozyskiwania żądań stron zainteresowanych (1) Przeglądy specyfikacji wymagań klienta Warsztaty wymagań Warsztaty przypadków użycia Burze mózgów i redukowanie pomysłów Wywiady Kwestionariusze Odgrywanie ról Prototypy Storyboards... 22
23 Techniki pozyskiwania żądań stron zainteresowanych (2) Takie techniki są użyteczne dla gromadzenia informacji o potrzebach stron, przydają się z równie dobrym skutkiem przy pozyskiwaniu wymagań cech lub szczegółowych wymagań oprogramowania Wiele technik może być używanych jednocześnie (np. podczas warsztatów, kiedy wszyscy są zebrani, można przeprowadzić burzę mózgów lub można wykonać szkice przyszłego systemu) 23
24 Przeglądy specyfikacji wymagań klienta (1) Czasami zespoły projektowe otrzymują dokumenty wymagań bezpośrednio od klienta, zwłaszcza w przypadku kontraktowania prac W takim przypadku, przeglądy specyfikacji klienta są bardzo istotne przy wyznaczaniu tego, co naszym zdaniem ma zostać określone jako wymaganie Zidentyfikowane wymagania muszą być następnie zweryfikowane zwrotnie przez klienta. Należy określić i rozwiązać wszelkie problemy 24
25 Przeglądy specyfikacji wymagań klienta (2) Pamiętajmy, kto napisał specyfikację i z czyjej perspektywy problem został opisany Wstępne i przeglądowe sekcje specyfikacji są ważne dla ogólnego zrozumienia dokumentu. Te sekcje raczej nie powinny zawierać wymagań, ale mogą się tam znaleźć jakie zagubione egzemplarze 25
26 Przeglądy specyfikacji wymagań klienta (3) Zidentyfikuj wymagania Rozpoznaj i oznacz: Zachowania aplikacji Atrybuty behawioralne Problemy i założenia Pytaj klienta 26
27 Burze mózgów (1) Reguły burzy mózgów: Jasno określcie cele sesji Wytwórzcie tyle pomysłów, ile jest tylko możliwe Pozwólcie szaleć wyobraźni Nie pozwalajcie na krytykę ani debaty (mogą powstrzymać ludzi od wyrażania swoich pomysłów) Łączcie i mieszajcie pomysły (inspiracja pomysłami innych) 27
28 Burze mózgów (2) Technika proces czterostopniowy Wyburzujcie cechy, które nowy system ma realizować. Naklejcie wszystkie na ścianie (sticky notes) Sklasyfikujcie naklejki: Ten proces musi zostać przeprowadzony bez rozmów Poproście każdego, żeby pogrupował naklejki względem cechy, które opisują Można w tym momencie dodać dodatkowe naklejki, jednak nadal nikt nie może się odzywać poza animatorem Powinniśmy uzyskać w ten sposób ok % poprawnej klasyfikacji 28
29 Burze mózgów (3) Technika proces czterostopniowy (c.d.) Nazwijcie cechy: Animator odczytuje na głos naklejki z każdej grupy i pomaga grupie nazwać cechę Porządkujmy naklejki, przenośmy je do odpowiednich grup, usuwajmy zbędne Powinniśmy być w stanie poprawnie dokończyć klasyfikację otrzymując kilkanaście grup Spriorytetyzujcie cechy: Bezwzględnie istotne jest, żeby zrozumieć i odnaleźć kluczowe cechy, które system ma wspierać Można posłużyć się jakimś sposobem głosowania 29
30 Burze mózgów (4) Zalety Użyteczne w każdej sytuacji i w każdym czasie Dobre dla grup Dobre dla wysokopoziomowych pojęć i założeń Dogodne do automatyzacji Wady Podatne na zjawiska związane z grupą Niesystematyczne (w klasycznym rozumieniu) 30 Takeda et al. 1993
31 Redukowanie pomysłów (1)...tnij i organizuj 31
32 Redukowanie pomysłów (2)...tnij i organizuj Diagramy afiniczne (diagramy powinowactwa, pokrewieństwa): 32
33 Redukowanie pomysłów (3)...tnij i organizuj Diagramy afiniczne (c.d.): 33 Zarządzanie jakością, pod red. W. Ładońskiego i K. Szołtysek, Wydawnictwo Uniwersytetu Ekonomicznego, Wrocław 2008
34 Redukowanie pomysłów (4)...tnij i organizuj Diagramy afiniczne (c.d.): Są używane do porządkowania efektów burzy mózgów Proces ma charakter twórczy, mniej logiczny Najpierw bez rozmów i konsultacji Potem dyskusja, nazywanie grup i korekty klasyfikacji: Często jedna z naklejek stanowi nazwę grupy 34
35 Redukowanie pomysłów (5)...priorytetyzowanie Priorytetyzowanie może odbyć się dopiero kiedy wszystkie pomysły są uporządkowane i pogrupowane Głosowanie: Kumulacyjne - kupowanie pomysłów (problem jedna osoba przeznacza wszystkie swoje głosy na drugorzędny i niepopularny pomysł) Głosy pojedyncze Etykietowanie, np. krytyczny, ważny, użyteczny z odpowiednimi wagami Stosowanie kryteriów Ważonych Nieważonych 35
36 Kryteria wyboru techniki pozyskiwania wymagań Przeznaczenie wymagań Typy wiedzy Różne metody pozyskują różne typy wiedzy (zachowanie, procesy i dane) Wewnętrzne filtrowanie wiedzy Specyfikacje projektu i implementacji Wybór gotowych pakietów (off-the-shelf) Formalna umowa nabycia systemu Niektóre rodzaje wiedzy można łatwo wydobyć z pamięci, w przeciwieństwie do innych Kontekst pozyskiwania Środowisko może mieć istotny wpływ na techniki pozyskiwania 36 Maiden N.A.M. & Rugg G., 1996
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ółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Znajdowanie przypadków użycia
Bardziej szczegółowoAnalityk 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ółowoProjektowanie BAZY DANYCH
Projektowanie BAZY DANYCH Podstawowe pojęcia Encją jest każdy przedmiot, zjawisko, stan lub pojęcie, czyli każdy obiekt, który potrafimy odróżnić od innych obiektów ( np. pies, rower,upał). Encje podobne
Bardziej szczegółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Bardziej szczegółowoWstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań
Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec
Bardziej szczegółowoWszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.
Wszystkie problemy leżą w testach O czym będziemy rozmawiać Coś nie wyszło Jak wygląda proces wytwórczy Każdy widzi to inaczej Jakie wnioski wyciągamy z testów Analiza problemów Możliwe rozwiązania O czym
Bardziej szczegółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
Bardziej szczegółowoJarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming
Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
Bardziej szczegółowoRozpoczęcie, inicjacja (ang. inception
Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl
Bardziej szczegółowoREQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie
Bardziej szczegółowoCzy 99% działań bez braków to dobry wynik?
Zarządzanie jakością działań zespołu projektowego ROZWAŻANIA WSTĘPNE Czy 99% działań bez braków to dobry wynik? 99% braków 2 katastrofy lotnicze dziennie w Polsce 150 000 wypłat zagubionych przy każdej
Bardziej szczegółowoRaport oceny kompetencji
Symulacje oceniające kompetencje Raport oceny kompetencji Rut Paweł 08-01-2015 Kompetencje sprzedażowe dla efactor Sp. z o.o. Dane osobowe Rut Paweł CEO pawel.rut@efactor.pl more-than-manager.com 2 z 13
Bardziej szczegółowoUPEDU: Rozpoznanie wymagań (ang. requirements discipline)
Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 5: UPEDU: Rozpoznanie wymagań (ang. requirements discipline) Na podstawie podręcznika:
Bardziej szczegółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements
Bardziej szczegółowoAnaliza biznesowa a metody agile owe
Analiza biznesowa a metody agile owe P6S_WG01 ma wiedzę w zakresie metodyk zwinnych P6S_WG02 ma wiedzę w zakresie zwinnego gromadzenia i zarządzania wymaganiami P6S_WG03 zna i rozumie proces wytwarzania
Bardziej szczegółowoKarta 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ółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoJarosław Żeliński analityk biznesowy, projektant systemów
Trendy w architekturze oprogramowania zarządzającego procesami biznesowymi i przepływem pracy - dedykowane czy standardowe? Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku
Bardziej szczegółowoRozdział 5: Zarządzanie testowaniem. Pytanie 1
Pytanie 1 Dlaczego niezależne testowanie jest ważne: A) Niezależne testowanie jest w zasadzie tańsze niż testowanie własnej pracy B) Niezależne testowanie jest bardziej efektywne w znajdywaniu defektów
Bardziej szczegółowoProgramowanie zespołowe
Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 3 Analiza problemu
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 3 Analiza problemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)
Bardziej szczegółowoPLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA
Bardziej szczegółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoZarządzanie Projektami zgodnie z PRINCE2
Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoZarządzanie projektami. Wykład 3 Wyznaczanie zakresu projektu Planowanie projektu
Zarządzanie projektami Wykład 3 Wyznaczanie zakresu projektu Planowanie projektu Wyznaczanie zakresu projektu COS i POS Conditions of Satisfaction (COS) Warunki satysfakcji Sformalizowana wymiana zdań
Bardziej szczegółowoHumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji
HumanTechnology Projektowanie interakcji czyli łatanie dziury w procesie produkcji Czym jest projektowanie interakcji? Projektowanie interakcji, czyli współdziałania człowieka z komputerem, wykorzystuje
Bardziej szczegółowoProjektowanie oprogramowania
Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z
Bardziej szczegółowoZarządzanie inicjatywami i wymaganiami w projektach IT
Zarządzanie inicjatywami i wymaganiami w projektach IT Spotkanie 2 Zbigniew Misiak zbigniew.misiak@gmail.com Czym się będziemy zajmować? Co już było: 1. Zarządzanie wymaganiami 2. Przegląd oprogramowania
Bardziej szczegółowoInżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot
Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie
Bardziej szczegółowoKnowledge Management jak zdiagnozować czego właściwie potrzebuje nasza firma? Mariusz Sumiński
Knowledge Management jak zdiagnozować czego właściwie potrzebuje nasza firma? Mariusz Sumiński Zarządzanie Wiedzą, czyli? Competetive Strategy Rewards and benefits Communities of practice Yellow Pages
Bardziej szczegółowoInżynieria Programowania Inżynieria wymagań
Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 11 marca 2017 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5 Plan wykładu
Bardziej szczegółowoAL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2
AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2 1. Definicja projektu: cechy projektu, przyczyny porażek projektów, czynniki sukcesu projektów, cele projektu, produkty projektu, cykl życia
Bardziej szczegółowoProgram Coachingu dla młodych osób
Program Coachingu dla młodych osób "Dziecku nie wlewaj wiedzy, ale zainspiruj je do działania " Przed rozpoczęciem modułu I wysyłamy do uczestników zajęć kwestionariusz 360 Moduł 1: Samoznanie jako część
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoAcceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki
Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja
Bardziej szczegółowoInżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie
Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków
Bardziej szczegółowoEMPIRYZMSCRUM DOŚWIADCZENIE + PODEJMOWANIE DECYZJI = WIEDZA
SCRUM ramy postępowania (ang. framework), dzięki którym ludzie mogą adaptacyjnie rozwiązywać złożone problemy tak, by w produktywny i kreatywny sposób wytwarzać produkty o najwyższej możliwej wartości
Bardziej szczegółowoPLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji
Bardziej szczegółowoINSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH
Załącznik Nr 3 do Zarządzenia Nr 52/2014 Rektora UMCS INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Spis treści Słownik pojęć... 1 Wprowadzenie... 2 Kroki zarządzania ryzykiem
Bardziej szczegółowoInnowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski
2011 Innowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski Projekt Projekt - to zbiór aktywności charakteryzujący się następującymi cechami: są ze sobą powiązane w złożony sposób, zmierzają do
Bardziej szczegółowoWprowadzenie do Behaviordriven
Wprowadzenie do Behaviordriven development Jakub Kosiński Email: ja@ghandal.net Czym jest BDD? praktyka, powstała na podstawie TDD, wykorzystywana w zwinnych metodykach stworzona przez Dana Northa w 2003
Bardziej szczegółowoKonkurs edukacyjny Bezpiecznie Tu i Tam
Lekcja 1. Jak wyrażać emocje w sieci? 19 września Dzień emotikona Tematyka lekcji: Internet jest cudownym wynalazkiem. Wykorzystujemy go w zabawie, nauce, kontaktowaniu się z koleżankami i kolegami. Musimy
Bardziej szczegółowoOmówienie założeń procesu Design Thinking i przeprowadzenie wstępnego warsztatu. Mariusz Muraszko i Mateusz Ojdowski Logisfera Nova
Dzień 1 PONIEDZIAŁEK 1.09.2014 8:00-10:00 Wprowadzenie do UX Otwarcie szkoły letniej wraz z wprowadzeniem do User Experience, przedstawienie struktury UX, narzędzi używanych przez specjalistów i dobrych
Bardziej szczegółowoPYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Bardziej szczegółowoOcenianie kształtujące
1 Ocenianie kształtujące 2 Ocenianie kształtujące w nowej podstawie programowej 3 Rozporządzenie o ocenianiu Ocenianie wewnątrzszkolne ma na celu: 1) Informowanie ucznia o poziomie jego osiągnięć edukacyjnych
Bardziej szczegółowoProjektowanie interakcji
Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director
Bardziej szczegółowoMiędzynarodowa Rada Inżynierii Wymagań. The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS.
Międzynarodowa Rada Inżynierii Wymagań The International Requirements Engineering Board (IREB e.v.) Szkolenia IREB w CTS www.cts.com.pl MISJA IREB Misją IREB jest udoskonalenie praktyki inżynierii wymagań
Bardziej szczegółowoSkuteczne Techniki Sprzedaży
Skuteczne Techniki Sprzedaży warsztaty w budowaniu długofalowych relacji z klientami Korzyści z udziału w naszym szkoleniu: wzrost sprzedaży w firmie, dzięki wykorzystaniu skutecznych technik sprzedaży,
Bardziej szczegółowoCo umieścić na stronie www, by klienci zostawiali nam swoje adresy email i numery telefonów
Co umieścić na stronie www, by klienci zostawiali nam swoje adresy email i numery telefonów 5 krytycznych punktów strony www, w których klient decyduje: zostawiam im swój email i numer telefonu, lub zamykam
Bardziej szczegółowoJak powstaje model biznesowy? Co to jest? Modelowanie biznesowe. Model biznesowy. Jak powstaje model biznesowy? Jak firma generuje przychody?
Modelowanie biznesowe Wprowadzenie (część 1) Co to jest? Każdy model jest błędny. Niektóre modele są użyteczne. George E. P. Box Jak firma generuje przychody? Model biznesowy Sposób generowania przychodów
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoUSTALENIE SYSTEMU WYNAGRODZEŃ
USTALENIE SYSTEMU WYNAGRODZEŃ Administracja systemu wynagrodzeń jest ważnym elementem prowadzenia biznesu. Gdy mamy działający formalny system płac, pomaga to w kontrolowaniu kosztów personelu, podnosi
Bardziej szczegółowoProgram szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0)
Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Informacje: Nazwa: Wprowadzenie do Domain Driven Design dla biznesu (część 0) Kod: Kategoria: Grupa docelowa: Czas trwania:
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoZarządzanie testowaniem wspierane narzędziem HP Quality Center
Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe
Bardziej szczegółowoBadanie nauczania filozofii w gimnazjach i szkołach ponadgimnazjalnych
Badanie nauczania filozofii w gimnazjach i szkołach ponadgimnazjalnych Scenariusz wywiadu pogłębionego z Nauczycielem Filozofii Scenariusz wywiadu pogłębionego z nauczycielem filozofii Dzień Dobry, Nazywam
Bardziej szczegółowoPolityka Prywatności PHU Tota Serwis Sebastian Wijas Data ostatniej aktualizacji: 8 maja 2018 roku
Polityka Prywatności PHU Tota Serwis Sebastian Wijas Data ostatniej aktualizacji: 8 maja 2018 roku Omówienie: 1. Ten dokument wyjaśnia, jakie informacje są zbierane w związku ze świadczeniem usług posłannictwa
Bardziej szczegółowoOd pomysłu do podpisania umowy. Izabela Adamska
Od pomysłu do podpisania umowy Izabela Adamska Restauracja Czy jest równowaga pomiędzy tym ile klient zapłaci, a tym co otrzyma w zamian? =? Sprawdźmy czy to jest proste? Wymagania telefonu komórkowego:
Bardziej szczegółowoWprowadzenie dosystemów informacyjnych
Wprowadzenie dosystemów informacyjnych Projektowanie antropocentryczne i PMBoK Podejście antropocentryczne do analizy i projektowania systemów informacyjnych UEK w Krakowie Ryszard Tadeusiewicz 1 Właściwe
Bardziej szczegółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoWarsztaty PRZEDSTAWICIEL HANDLOWY. Oferta
Warsztaty PRZEDSTAWICIEL HANDLOWY Oferta e-mail: biuro@garg.pl, www.garg.pl 1. Informacje podstawowe o szkoleniu Szkolenie skierowane jest do aktywnych osób, które chcą podnieść swoje kwalifikacje, a tym
Bardziej szczegółowoJacek Bajorek Instytut Zarządzana Bezpieczeństwem Informacji
Jacek Bajorek Instytut Zarządzana Bezpieczeństwem Informacji Outsourcing, czyli skrót angielskich wyrazów outsideresource-ing oznacza nie mniej, nie więcej, jak wykorzystywanie zasobów z zewnątrz. Coraz
Bardziej szczegółowoPolityka Prywatności TARTEL Sp. z o.o. Data ostatniej aktualizacji: 8 maja 2018 roku
Polityka Prywatności TARTEL Sp. z o.o. Data ostatniej aktualizacji: 8 maja 2018 roku Omówienie: 1. Ten dokument wyjaśnia, jakie informacje są zbierane w związku ze świadczeniem usług telekomunikacyjnych
Bardziej szczegółowoProcesowa 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ółowoNarzędzia informatyczne wspierające przedsięwzięcia e-commerce
Narzędzia informatyczne wspierające przedsięwzięcia e-commerce Zarządzanie projektami e-commerce, Meblini.pl, UE we Wrocławiu Wrocław, 11-03-2018 1. Cykl życia projektu 2. Pomysł / Planowanie 3. Analiza
Bardziej szczegółowoWymagania na oceny gimnazjum
Wymagania na oceny gimnazjum Zanim zaczniemy oceniać ucznia, należy zapoznać go z kryteriami oceniania. Na początku roku szkolnego nauczyciel informuje uczniów o wymaganiach i kryteriach oceniania. Uczeń
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoMODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś
OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie
Bardziej szczegółowoAkademia Młodego Ekonomisty
Akademia Młodego Ekonomisty Kreatywność, czyli jak być twórczym na co dzień Beata Skowrońska Uniwersytet w Białymstoku 13 marca 2014 r. Co to jest? kreatywność, kreatywne myślenie proces umysłowy pociągający
Bardziej szczegółowoJarosław Żeliński analityk biznesowy, projektant systemów
Elektroniczne zarządzanie informacją i obiegiem dokumentów kluczowe czynniki sukcesu projektu Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku w branży IT i zarządzania jako
Bardziej szczegółowoWDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE
OFERTA WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE W TWORZENIU MODELU AS-IS /Jest to przykład (wzór) oferty treść jest wypełniana na podstawie nie zobowiązujących rozmów i spotkań z Klientem, pracownikami
Bardziej szczegółowoOferta szkoleniowa z języka angielskiego. English Vibe
Oferta szkoleniowa z języka angielskiego English Vibe Jest to inicjatywa powstała w 2009r. Zajmujemy się organizacją i realizacją szkoleń z języka angielskiego dla firm oraz dla klientów indywidualnych.
Bardziej szczegółowoDyskusja. Zarządzanie wiedzą. Wykład Techniki prowadzenia dyskusji. Joanna Kołodziejczyk. 01 kwiecień 2011
Zarządzanie wiedzą Wykład Techniki prowadzenia dyskusji Joanna Kołodziejczyk 01 kwiecień 2011 Plan wykładu 1 Brainstorims Myślenie twórcze Narzędzia: Burza mózgów: to lista wszystkich pomysłów wysuniętych
Bardziej szczegółowoJak uczyć się na błędach? Łukasz Malina WEBCON
Jak uczyć się na błędach? Łukasz Malina WEBCON Dla kogo jest ta prezentacja? Klientów tuż przed decyzją wdrożeniową. Obecnych klientów. Obecnych klientów budujących silne kompetencje. Partnerów WEBCON.
Bardziej szczegółowoKARTA PRZEDMIOTU. Projekt zespołowy D1_10
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Projekt zespołowy D1_10 Nazwa przedmiotu (j. ang.): Team Project Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia:
Bardziej szczegółowoSKĄD MAMY TWOJE DANE OSOBOWE?
ZASADY PRZETWARZANIA DANYCH OSOBOWYCH W ZWIĄZKU Z PROWADZENIEM BIEŻĄCEJ KORESPONDENCJI ELEKTRONICZNEJ PRZEZ OKRĘGOWĄ KOMISJĘ EGZAMINACYJNĄ WE WROCŁAWIU ul. Zielińskiego 57, 53-533 Wrocław Poniżej przedstawiamy
Bardziej szczegółowoMiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska
MiASI Modelowanie systemów biznesowych Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 stycznia 2010 Spis treści 1 Czym jest system biznesowy? Po co model bizensowy? Czym
Bardziej szczegółowoJak skutecznie podnieść sprzedaż w 97 dni? WARSZTATY
Edycja 2015 Jak skutecznie podnieść sprzedaż w 97 dni? WARSZTATY Grant z Programu Rozwoju Sprzedaży Projekt i realizacja dr Mariusz Salamon 1 Czy w 97 dni da się naprawdę znacząco zwiększyć sprzedaż? Tak,
Bardziej szczegółowoKARTA PRZEDMIOTU. Systemy czasu rzeczywistego: D1_9
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom : Profil : Forma studiów: Obszar : Dziedzina:
Bardziej szczegółowoSYSTEMY INFORMATYCZNE ćwiczenia praktyczne
SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego
Bardziej szczegółowoMetodyka Sure Step. Agenda:
Metodyka Sure Step Agenda: 1. Wstęp 2. Czym jest Microsoft Dynamics Sure Step? 3. Zespół wdrożeniowy 4. Etapy wdrożenia 5. Przebieg wdrożenia typu Standard 6. Diagnoza 1 Wstęp 1. Plan wdrożenia 2. Zarządzanie
Bardziej szczegółowoWprowadzenie w tematykę zarządzania projektami/przedsięwzięciami
Wprowadzenie w tematykę zarządzania projektami/przedsięwzięciami punkt 2 planu zajęć dr inż. Agata Klaus-Rosińska 1 DEFINICJA PROJEKTU Zbiór działań podejmowanych dla zrealizowania określonego celu i uzyskania
Bardziej szczegółowoPRINCE2 Foundation - szkolenie z egzaminem certyfikacyjnym
Kod szkolenia: Tytuł szkolenia: H6C24S PRINCE2 Foundation - szkolenie z egzaminem certyfikacyjnym Dni: 3 Opis: Metodyka PRINCE2 jest akceptowana na poziomie międzynarodowym i uznana za wiodące podejście
Bardziej szczegółowoOBSŁUGA KLIENTA. - program szkolenia. Opracował: Łukasz Gorzym. Przygotowana w ramach MSUES. Kraków, 11 września 2014
OBSŁUGA KLIENTA - program szkolenia Przygotowana w ramach MSUES Opracował: Łukasz Gorzym Kraków, 11 września 2014 1 CELE SZKOLENIA Na poziomie wiedzy uczestnicy: poznają wdrażane do sieci standardy obsługi
Bardziej szczegółowoInformacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów
Eksploracja danych Piotr Lipiński Informacje ogólne Informacje i materiały dotyczące wykładu będą publikowane na stronie internetowej wykładowcy, m.in. prezentacje z wykładów UWAGA: prezentacja to nie
Bardziej szczegółowoCOLLABORATIVE & PROACTIVE SOLUTIONS
COLLABORATIVE & PROACTIVE SOLUTIONS ROZWIĄZANIA WYNIKAJĄCE ZE WSPÓŁPRACY I DZIAŁANIA Ross W. Greene Prezentacja przygotowana przez Aleksandrę Bagińską Ross Greene Profesor Wydziału Psychiatrii w Harvard
Bardziej szczegółowoSCENARIUSZ GRY NR 5. DLA OSÓB W WIEKU 16+
SCENARIUSZ GRY NR 5. DLA OSÓB W WIEKU 16+ Gra symulacyjna nr 5: AUTOPREZENTACJA pt. Moja kariera zawodowa Cel gry: obserwacja i rozpoznanie świadomości obrazu samego siebie (autorefleksji), a także przedstawiania
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Inżyniera wymagań Wymagania w projektowaniu systemów informatycznych Istnieją różne definicje wymagań dla
Bardziej szczegółowoZASADY PRZETWARZANIA DANYCH OSOBOWYCH W ZWIĄZKU Z PROWADZENIEM BIEŻĄCEJ KORESPONDENCJI ELEKTRONICZNEJ W "PPSKIZ TRANSMEBLE POZNAŃ" sp. z o.o.
ZASADY PRZETWARZANIA DANYCH OSOBOWYCH W ZWIĄZKU Z PROWADZENIEM BIEŻĄCEJ KORESPONDENCJI ELEKTRONICZNEJ W "PPSKIZ TRANSMEBLE POZNAŃ" sp. z o.o. Poniżej przedstawiamy informacje o tym w jaki sposób, w jakich
Bardziej szczegółowoInżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.
Inżynieria Programowania Zarządzanie projektem Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 3 października 2013 Plan wykładu 1. Wstęp 2. Czynności zarządzania 3.
Bardziej szczegółowoKARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Projekt zespołowy D1_10
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia: Profil kształcenia: Forma studiów:
Bardziej szczegółowoWywiady z pracownikami Poczty Polskiej w Kleczewie
Wywiady z pracownikami Poczty Polskiej w Kleczewie Dnia 22 października 2014 roku przeprowadziliśmy wywiad z naczelnik poczty w Kleczewie, panią Kulpińską, która pracuje na tym stanowisku ponad 30 lat.
Bardziej szczegółowolub CORE Consulting, ul. Z. Krasińskiego 16, Poznań.
ZASADY PRZETWARZANIA DANYCH OSOBOWYCH W ZWIĄZKU Z PROWADZENIE BIEŻĄCEJ KORESPONDENCJI ELEKTRONICZNEJ PRZEZ LICEUM OGÓLNOKSZTAŁCĄCE NR VIII IM. BOLESŁAWA KRZYWOUSTEGO WE WROCŁAWIU, UL. ZAPOROSKA 71. Poniżej
Bardziej szczegółowoOCENA 360. Diagnoza kompetencji zawodowych. Considero Consulting 663 965 960 consulting@considero.pl. www.considero.pl. Warszawa luty 2013
OCENA 360 Considero Consulting 663 965 960 consulting@considero.pl www.considero.pl Warszawa luty 2013 Diagnoza kompetencji zawodowych czym jest ocena 360 Ocena 360 to metoda uzyskiwania informacji o pracowniku
Bardziej szczegółowoWstęp do zarządzania projektami
Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.
Bardziej szczegółowo