MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska
|
|
- Błażej Tomaszewski
- 8 lat temu
- Przeglądów:
Transkrypt
1 MiASI Modele, perspektywy, diagramy UML Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 grudnia 2009
2 Spis treści 1 Modele, perspektywy, diagramy Czym jest model? Do czego potrzebne są modele? Cel i grupa docelowa projektu Proces analizy Diagramy 2 UML
3 Czym jest model? Modele są budowane w celu lepszego zobrazowania istniejących lub przyszłych systemów. Model nigdy nie będzie w pełni odpowiadał rzeczywistości. Modelowanie jest nierozerwalnie związane z uwypuklaniem pewnych cech i pomijaniem innych. Nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróżnić a co pominąć.
4 Czym jest model? Modele są budowane w celu lepszego zobrazowania istniejących lub przyszłych systemów. Model nigdy nie będzie w pełni odpowiadał rzeczywistości. Modelowanie jest nierozerwalnie związane z uwypuklaniem pewnych cech i pomijaniem innych. Nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróżnić a co pominąć.
5 Czym jest model? Modele są budowane w celu lepszego zobrazowania istniejących lub przyszłych systemów. Model nigdy nie będzie w pełni odpowiadał rzeczywistości. Modelowanie jest nierozerwalnie związane z uwypuklaniem pewnych cech i pomijaniem innych. Nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróżnić a co pominąć.
6 Czym jest model? Modele są budowane w celu lepszego zobrazowania istniejących lub przyszłych systemów. Model nigdy nie będzie w pełni odpowiadał rzeczywistości. Modelowanie jest nierozerwalnie związane z uwypuklaniem pewnych cech i pomijaniem innych. Nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróżnić a co pominąć.
7 Czym jest model? Modele są budowane w celu lepszego zobrazowania istniejących lub przyszłych systemów. Model nigdy nie będzie w pełni odpowiadał rzeczywistości. Modelowanie jest nierozerwalnie związane z uwypuklaniem pewnych cech i pomijaniem innych. Nie ma uniwersalnej odpowiedzi na pytanie o to, co wyróżnić a co pominąć.
8 Czym jest model? Czym jest model? Odpowiedź zależy od tego Po co model jest tworzony? Kto ma być jego odbiorcą?
9 Czym jest model? Czym jest model? Odpowiedź zależy od tego Po co model jest tworzony? Kto ma być jego odbiorcą?
10 Czym jest model? Czym jest model? Odpowiedź zależy od tego Po co model jest tworzony? Kto ma być jego odbiorcą?
11 Czym jest model? Pomijanie szczegółów Przyjrzyjmy się szczegółom w następujących modelach Mapa. Plan komunikacji miejskiej (tramwaje, autobusy, metro... ). Schemat organizacji jednostki UŁ.
12 Czym jest model? Pomijanie szczegółów Przyjrzyjmy się szczegółom w następujących modelach Mapa. Plan komunikacji miejskiej (tramwaje, autobusy, metro... ). Schemat organizacji jednostki UŁ.
13 Czym jest model? Pomijanie szczegółów Przyjrzyjmy się szczegółom w następujących modelach Mapa. Plan komunikacji miejskiej (tramwaje, autobusy, metro... ). Schemat organizacji jednostki UŁ.
14 Czym jest model? Pomijanie szczegółów Przyjrzyjmy się szczegółom w następujących modelach Mapa. Plan komunikacji miejskiej (tramwaje, autobusy, metro... ). Schemat organizacji jednostki UŁ.
15 Do czego potrzebne są modele? Model systemu realizuje następujące funkcje Opisuje model komunikacji i powiązania między elementami systemu. Zobrazowanie przebiegu wszystkich procesów z punktu widzenia klientów, specjalistów i użytkowników. Weryfikacja faktów pod kątem kompletności spójności i poprawności.
16 Do czego potrzebne są modele? Model systemu realizuje następujące funkcje Opisuje model komunikacji i powiązania między elementami systemu. Zobrazowanie przebiegu wszystkich procesów z punktu widzenia klientów, specjalistów i użytkowników. Weryfikacja faktów pod kątem kompletności spójności i poprawności.
17 Do czego potrzebne są modele? Model systemu realizuje następujące funkcje Opisuje model komunikacji i powiązania między elementami systemu. Zobrazowanie przebiegu wszystkich procesów z punktu widzenia klientów, specjalistów i użytkowników. Weryfikacja faktów pod kątem kompletności spójności i poprawności.
18 Do czego potrzebne są modele? Model systemu realizuje następujące funkcje Opisuje model komunikacji i powiązania między elementami systemu. Zobrazowanie przebiegu wszystkich procesów z punktu widzenia klientów, specjalistów i użytkowników. Weryfikacja faktów pod kątem kompletności spójności i poprawności.
19 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
20 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
21 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
22 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
23 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
24 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
25 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
26 Cel i grupa docelowa projektu Aby zdefiniować grupę docelową, szukamy odpowiedzi na następujące pytania. Jakiego poziomu zaawansowania biznesowego należy oczekiwać od odbiorców? Jaki poziom szczegółowości jest potrzebny odbiorcom? Ile czasu może grupa docelowa poświęcić na analizę i interpretację modelu? Język definiowania modelu ogólnie występująca terminologia (mniejsza precyzja, ale większe grono odbiorców); terminologia specjalistyczna (duża precyzja, ale znacząco zawężony krąg odbiorców); przykład: butelkę z kodą można oznaczyć za pomocą falek, napisu WODA lub pisząc H 20.
27 Proces analizy Proces analizy składa się z faz Pozyskiwania informacji od dostawców wiedzy. Reprezentowania (specyfikowanie). Weryfikacji.
28 Proces analizy Proces analizy składa się z faz Pozyskiwania informacji od dostawców wiedzy. Reprezentowania (specyfikowanie). Weryfikacji.
29 Proces analizy Proces analizy składa się z faz Pozyskiwania informacji od dostawców wiedzy. Reprezentowania (specyfikowanie). Weryfikacji.
30 Proces analizy Proces analizy składa się z faz Pozyskiwania informacji od dostawców wiedzy. Reprezentowania (specyfikowanie). Weryfikacji.
31 Proces analizy Dostawcy wiedzy Jako dostwcy wiedzy mogą służyć uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.
32 Proces analizy Dostawcy wiedzy Jako dostwcy wiedzy mogą służyć uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.
33 Proces analizy Dostawcy wiedzy Jako dostwcy wiedzy mogą służyć uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.
34 Proces analizy Dostawcy wiedzy Jako dostwcy wiedzy mogą służyć uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.
35 Proces analizy Dostawcy wiedzy Jako dostwcy wiedzy mogą służyć uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.
36 Proces analizy Dostawcy wiedzy Jako dostwcy wiedzy mogą służyć uczestnicy i kontrolerzy procesów biznesowych; użytkownicy systemów informatycznych o funkcjonalności zbliżonej do modelowanego systemu lub związanej z nim; klienci; eksperci w analizowanej dziedzinie; niezależni obserwatorzy.
37 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
38 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
39 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
40 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
41 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
42 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
43 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
44 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
45 Proces analizy Techniki W procesie analizy i poznawania procesów biznesowych pomocne bywają następujące techniki obserwacja pracowników przy pracy; branie udziału w analizowanych procesach bizensowych; przyjęcie roli uczestnika zewnętrznego, np.klienta; ankiety i przeprowadzanie wywiadów; organizowanie burz muzgów z udziałem wszystkich zaangażowanych grup; prowadzenie dyskusji z ekspertami; analiza istniejących formularzy, dokumentacji, specyfikacji i narzędzi pracy; opisywanie struktury organizacyjnej i zasad przepływu informacji.
46 Diagramy w roli perspektyw Diagramy
47 UML UML
MiASI. 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ółowoModele komunikacji naukowej. Dr hab. Marek Nahotko
Modele komunikacji naukowej Dr hab. Marek Nahotko 1 MODELE I MODELOWANIE Model Model jest uproszczoną reprezentacją systemu, w czasie i przestrzeni, stworzoną w zamiarze zrozumienia zachowania systemu
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ół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ółowoDiagramy przypadków użycia. WYKŁAD Piotr Ciskowski
Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej
Bardziej szczegółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoJę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 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoCzęść I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA
CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia
Bardziej szczegółowoKluczowe zasoby do realizacji e-usługi Warszawa, 16 października 2012. Maciej Nikiel
2012 Zasoby wiedzy w e-projekcie. Technologie informatyczne, oprogramowanie - zdefiniowanie potrzeb, identyfikacja źródeł pozyskania. Preferencje odnośnie technologii informatycznych. Maciej Nikiel Kluczowe
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ółowoDiagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Bardziej szczegół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ółowoModelowanie 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ół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ółowoInż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ółowoModel referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami
Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary
Bardziej szczegółowoModel przestrzenny Diagramu Obiegu Dokumentów. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Model przestrzenny Diagramu Obiegu Dokumentów Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Sposoby weryfikacji architektury oprogramowania: - badanie prototypu
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ół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ółowoKomputerowe 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ółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
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ółowoModelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig
Modelowanie Obiektowe Wykład 1: Wprowadzenie do Modelowania i języka UML Anna Kulig Wprowadzenie do modelowania Zasady Pojęcia Wprowadzenie do języka UML Plan wykładu Model jest uproszczeniem rzeczywistości.
Bardziej szczegółowoJarosław Żeliński analityk biznesowy, projektant systemów
Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia
Bardziej szczegółowoWymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.
Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji. Wymiar pionowy: oś czasu przedstawiajaca ułożone chronologicznie komunikaty Podstawowe notacje graficzne Konceptualny
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoOpis wymagań i program szkoleń dla użytkowników i administratorów
Załącznik nr 3 do OPZ Opis wymagań i program szkoleń dla użytkowników i administratorów Spis treści Wprowadzenie...2 1. Typ i zakres szkoleń...2 2. Grupy użytkowników...2 3. Warunki ogólne szkoleń...3
Bardziej szczegółowoThe Binder Consulting
The Binder Consulting Contents Indywidualne szkolenia specjalistyczne...3 Konsultacje dla tworzenia rozwiazan mobilnych... 3 Dedykowane rozwiazania informatyczne... 3 Konsultacje i wdrożenie mechanizmów
Bardziej szczegółowoDiagramy przypadków użycia
Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy
Bardziej szczegółowoCel 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ół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ółowoMODELOWANIE PRZEPŁYWU DANYCH
MODELOWANIE PRZEPŁYWU DANYCH 1. Diagram przepływu danych (DFD) 2. Weryfikacja modelu strukturalnego za pomocą DFD Modelowanie SI - GHJ 1 Definicja i struktura DFD Model części organizacji rozważany z punktu
Bardziej szczegółowoJęzyk UML. dr inż. Piotr Szwed C3, pok
Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Przypadki użycia Przypadki użycia: Definicja Przypadek użycia to specyfikacja ciągów akcji i ich wariantów,
Bardziej szczegółowoZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn.
Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego ZAPYTANIE OFERTOWE nr /UE/204 z dnia 7.0.204 r. w związku z realizacją projektu pn. Wdrożenie
Bardziej szczegółowoNarzędzia Informatyki w biznesie
Narzędzia Informatyki w biznesie Przedstawiony program specjalności obejmuje obszary wiedzy informatycznej (wraz z stosowanymi w nich technikami i narzędziami), które wydają się być najistotniejsze w kontekście
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ółowoPROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>
Załącznik nr 4.5 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA numer wersji
Bardziej szczegółowoPrzepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)
Przepływy danych Oracle Designer: Modelowanie przepływów danych Cele: zobrazowanie funkcji zachodzących w organizacji, identyfikacja szczegółowych informacji, przetwarzanych przez funkcje, pokazanie wymiany
Bardziej szczegółowoSpis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...
Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...
Bardziej szczegółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Bardziej szczegółowoAgenda. O firmie. Wstęp Ksavi. Opis funkcjonalności systemu Ksavi Auditor. Podsumowanie
Agenda O firmie Wstęp Ksavi Opis funkcjonalności systemu Ksavi Auditor Podsumowanie O firmie Na rynku od 2001 roku 60 zatrudnionych pracowników Dogłębna znajomość branży Projekty informatyczne dla największych
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ółowoArchitektura oprogramowania w praktyce. Wydanie II.
Architektura oprogramowania w praktyce. Wydanie II. Autorzy: Len Bass, Paul Clements, Rick Kazman Twórz doskonałe projekty architektoniczne oprogramowania! Czym charakteryzuje się dobra architektura 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ółowoZajęcia laboratoryjne z przedmiotu IOP
Zajęcia laboratoryjne z przedmiotu IOP Warszawa, październik 2013 dr inż. Marcin Szlenk dr inż. Andrzej Zalewski 1. Cel zajęć... 1 2. Model analityczny... 1 3. Organizacja prac... 2 3.1. Zespoły... 2 3.2.
Bardziej szczegółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoInżynieria oprogramowania - opis przedmiotu
Inżynieria oprogramowania - opis przedmiotu Informacje ogólne Nazwa przedmiotu Inżynieria oprogramowania Kod przedmiotu 11.3-WK-IiED-IO-W-S14_pNadGenRB066 Wydział Kierunek Wydział Matematyki, Informatyki
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegół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ółowoMINIMALNY ZAKRES DIAGNOZY POTRZEB ROZWOJOWYCH PRZEDSIĘBIORSTWA
Strona 1 Załącznik nr 1 do Regulaminu MINIMALNY ZAKRES DIAGNOZY POTRZEB ROZWOJOWYCH PRZEDSIĘBIORSTWA Warunkiem udzielenia wsparcia ukierunkowanego na wzrost kompetencji kadry menadżerskiej lub osób przewidzianych
Bardziej szczegółowoZAPYTANIE OFERTOWE. Szczegółowy opis przedmiotu zapytania znajduje się w Specyfikacji, załączonej do niniejszego zapytania.
Toruń, dnia 12.09.2014r. COPYCOM Sp. z o.o. ul. Żółkiewskiego 37/41 87-100 Toruń ZAPYTANIE OFERTOWE Firma COPYCOM Sp. z o.o. zwraca się z prośbą o przedstawienie oferty cenowej na zakup poniższych elementów
Bardziej szczegółowoAPIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.
APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI. dr inż. Grażyna Hołodnik-Janczura W8/K4 ZDARZENIA BIZNESOWE W otoczeniu badanego zakresu
Bardziej szczegółowoZałącznik nr 4 do uchwały nr 117 Senatu UMK z dnia 30 października 2012 r.
Załącznik nr 4 do uchwały nr 117 Senatu UMK z dnia 30 października 2012 r. E f e k t y k s z t a ł c e n i a d l a k i e r u n k u i i c h r e l a c j e z e f e k t a m i k s z t a ł c e n i a d l a o
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ółowoZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI
ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI XVIII Forum Teleinformatyki mgr inż. Michał BIJATA, doktorant, Wydział Cybernetyki WAT Michal.Bijata@WAT.edu.pl, Michal@Bijata.com 28 września 2012 AGENDA Architektura
Bardziej szczegółowoWdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00
Regulamin usługi Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Projekt realizowany jest w ramach Działania 5.2 Wsparcie
Bardziej szczegółowoZAPROSZENIE DO ZŁOŻENIA OFERTY CENOWEJ NA ANALIZĘ PRZYGOTOWAWCZĄ
Warszawa, 5.01.2015 ZAPROSZENIE DO ZŁOŻENIA OFERTY CENOWEJ NA ANALIZĘ PRZYGOTOWAWCZĄ 1. Nazwa i adres zamawiającego: PROGUEST CONSULTING SP. Z O. O. ul. Powstańców 24N lok. 3 05-091 Ząbki Firma PROGUEST
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoSzczegółowy harmonogram rzeczowy realizacji prac systemu B2B
Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B NAZWA ZADANIA ZADANIE CZĄSTKOWE TECHNOLOGIA ILOŚĆ OSÓB ILOŚĆ GODZIN TERMIN REALIZACJI 1 2 4 5 6 7 Zadanie 1 - wersji alfa 1 systemu B2B 3 723
Bardziej szczegółowoKARTA MODUŁU KSZTAŁCENIA
KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator
Bardziej szczegółowoWARTOŚCIOWANIE I OPISY STANOWISK PRACY
I miejsce w rankingu firm szkoleniowych wg Gazety Finansowej 26-27 lutego, Warszawa Warszawa WARTOŚCIOWANIE I OPISY Klasyfikacja metod wartościowania pracy wskazanie na wady i zalety Konstrukcja opisu
Bardziej szczegółowoJak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012
Analityk systemów informatycznych to zawód cieszący się w ostatnich latach rosnącą popularnością. Młodych ludzi zachęcają liczne oferty pracy, perspektywa wysokich zarobków i możliwość podnoszenia kwalifikacji.
Bardziej szczegółowoUchwała nr 85/2017 z dnia 30 maja 2017 r. Senatu Uniwersytetu Medycznego w Łodzi
Uchwała nr 85/2017 z dnia 30 maja 2017 r. Senatu Uniwersytetu Medycznego w Łodzi w sprawie potwierdzenia utworzenia na Wydziale Nauk Biomedycznych i Kształcenia Podyplomowego Uniwersytetu Medycznego w
Bardziej szczegółowoKarta monitorowania wzmacniania umiejętności i kompetencji Praktycznych w obszarze zarządzanie zasobami ludzkimi
KZ_U01 Obserwacji, KZ_U01 Dokonywania interpretacji i wyjaśniania obserwacji zjawisk i zjawisk społecznych oraz procesów w zakresie wzajemnych relacji między zarządzania personelem zjawiskami społecznymi
Bardziej szczegółowoSCENARIUSZ LEKCJI. TEMAT LEKCJI: Zastosowanie średnich w statystyce i matematyce. Podstawowe pojęcia statystyczne. Streszczenie.
SCENARIUSZ LEKCJI OPRACOWANY W RAMACH PROJEKTU: INFORMATYKA MÓJ SPOSÓB NA POZNANIE I OPISANIE ŚWIATA. PROGRAM NAUCZANIA INFORMATYKI Z ELEMENTAMI PRZEDMIOTÓW MATEMATYCZNO-PRZYRODNICZYCH Autorzy scenariusza:
Bardziej szczegółowoOpis przedmiotu zapytania znajduje się w Specyfikacji, załączonej do niniejszego zapytania.
Skierniewice, dnia 04.02.104 Zapytanie ofertowe I. DANE ZAMAWIAJĄCEGO: Mariusz Ciucias COPY SERWIS ul. Jagiellońska 15 96-100 Skierniewice II. ZAPYTANIE OFERTOWE W związku z realizacją projektu pt. Wdrożenie
Bardziej szczegółowoProjekt: 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ółowoZARZĄDZANIE PROCESAMI I PROJEKTAMI. Zakres projektu. dr inż. ADAM KOLIŃSKI ZARZĄDZANIE PROCESAMI I PROJEKTAMI. Zakres projektu. dr inż.
1 ZARZĄDZANIE PROCESAMI I PROJEKTAMI 2 ZAKRES PROJEKTU 1. Ogólna specyfika procesów zachodzących w przedsiębiorstwie 2. Opracowanie ogólnego schematu procesów zachodzących w przedsiębiorstwie za pomocą
Bardziej szczegółowoPełnomocnik i Audytor SZJ w Przemyśle Motoryzacyjnym wg ISO/TS 16949:2009
Pełnomocnik i Audytor SZJ w Przemyśle Motoryzacyjnym wg ISO/TS 16949:2009 Przedmiot szkolenia: Przedmiotem szkolenia jest zapoznanie przyszłych Audytorów i Pełnomocników z metodami audytowania, wdrażania,
Bardziej szczegółowoProjekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej
Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej FiM Consulting Sp. z o.o. Szymczaka 5, 01-227 Warszawa Tel.: +48 22 862 90 70 www.fim.pl Spis treści
Bardziej szczegółowoSkuteczny nadzór nad zgodnością
Skuteczny nadzór nad zgodnością Trudno panować nad standardem? 2 Definiowanie i zapewnienie zgodności to wyzwanie stojące przed każdą dużą organizacją posiadającą wiele oddziałów, czy oferującą zaawansowane
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ółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoModelowanie testów. czyli po co testerowi znajomość UML
Modelowanie testów czyli po co testerowi znajomość UML Paweł Dudzik październik 2015 Naturalny opis świata Powstaje pytanie, jak opisać ten świat, aby opis był jak najbardziej zbliżony do rzeczywistości,
Bardziej szczegółowoZałącznik nr 2 : Procedury dokonywania ewaluacji i monitoringu wdrażania LSR i funkcjonowania LGD KOLD.
Załącznik nr 2 : Procedury dokonywania i monitoringu wdrażania LSR i funkcjonowania LGD KOLD. 1. Opis elementów funkcjonowania LGD, które będą podlegać - wraz z opisem procedury: sposobami działania, odpowiedzialnością
Bardziej szczegółowoWymiarowanie oprogramowania z perspektywy podwykonawcy
Wymiarowanie oprogramowania z perspektywy podwykonawcy O czym opowiem Doświadczenia małej firmy pracującej w modelu podwykonawczym opartym o rozliczenia bazujące na rozmiarze funkcjonalnym oprogramowania
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Diagramy przypadków użycia Diagramy przypadków użycia jako narzędzie modelowania wymagań Nazwa diagramu
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoGeneracja Y o mediach społecznościowych w miejscu pracy
Generacja Y o mediach społecznościowych w miejscu pracy Raport z badania Szymon Góralski Wrocław, 2013 ul. Więzienna 21c/8, 50-118 Wrocław, tel. 71 343 70 15, fax: 71 343 70 13, e-mail: biuro@rrcc.pl,
Bardziej szczegółowoZakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
Bardziej szczegółowoDropbox a RODO Zgodność Wdrażanie RODO
Dropbox a RODO Zgodność Wdrażanie RODO Droga Dropbox do wdrożenia zasad RODO 2 Wstęp Ogólne rozporządzenie o ochronie danych osobowych (RODO) to rozporządzenie Unii Europejskiej, które ustanawia nowe przepisy
Bardziej szczegółowoModelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014
Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80
Bardziej szczegółowoZARZĄDZANIE PROCESAMI LOGISTYCZNYMI W PRZEDSIĘBIORSTWIE
1.1.1 Zarządzanie procesami logistycznymi w przedsiębiorstwie I. OGÓLNE INFORMACJE PODSTAWOWE O PRZEDMIOCIE ZARZĄDZANIE PROCESAMI LOGISTYCZNYMI W PRZEDSIĘBIORSTWIE Nazwa jednostki organizacyjnej prowadzącej
Bardziej szczegółowoStrategiczna Karta Wyników
Strategiczna Karta Wyników 1 Strategiczna Karta Wyników zwana również metodą BSC - Balanced Scorecard to koncepcja monitorowania strategii w długoterminowej perspektywie. Wykorzystuje spójny system finansowych
Bardziej szczegółowoSystemy ekspertowe : program PCShell
Instytut Informatyki Uniwersytetu Śląskiego lab 1 Opis sytemu ekspertowego Metody wnioskowania System PcShell Projekt System ekspertowy - system ekspertowy to system komputerowy zawierający w sobie wyspecjalizowaną
Bardziej szczegółowoEfekty uczenia się na kierunku. Logistyka (studia pierwszego stopnia o profilu praktycznym)
Efekty uczenia się na kierunku Załącznik nr 2 do uchwały nr 412 Senatu Uniwersytetu Zielonogórskiego z dnia 29 maja 2019 r. Logistyka (studia pierwszego stopnia o profilu praktycznym) Tabela 1. Kierunkowe
Bardziej szczegółowoProjekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy
Projekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy współfinansowany ze środków Mechanizmu Finansowego Europejskiego Obszaru Gospodarczego. Marek
Bardziej szczegółowoSZKOLENIA CATIA ZAINWESTUJ W PROFESJONALNE KSZTAŁCENIE SWOJEJ KADRY!
SZKOLENIA CATIA ZAINWESTUJ W PROFESJONALNE KSZTAŁCENIE SWOJEJ KADRY! Serdecznie zapraszamy na cykl szkoleń CATIA V5 oraz 3DEXPERIENCE z możliwością dofinansowania nawet do 80%. Poniżej publikujemy przykładowe
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoOtwarte protokoły wymiany informacji w systemach ITS
Otwarte protokoły wymiany informacji w systemach ITS Grzegorz Kawka PHU TELSAT Sesja nr 4: Interoperacyjność systemów ITS cz. I Podstawą działania systemów ITS jest wymiana informacji pomiędzy poszczególnymi
Bardziej szczegółowoUniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013
SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu
Bardziej szczegółowoProwadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska. Miedzeszyn, wrzesień 2010
Jak nie stracić efektów synergii usługi systemów krajowych i globalnych Prowadzący: Bartosz Górczyński, CTPartners S.A, itsmf Polska Miedzeszyn, wrzesień 2010 Bartosz Górczyński Prezes Zarządu CTPartners
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ółowoRELACYJNE BAZY DANYCH
RELACYJNE BAZY DANYCH Aleksander Łuczyk Bielsko-Biała, 15 kwiecień 2015 r. Ludzie używają baz danych każdego dnia. Książka telefoniczna, zbiór wizytówek przypiętych nad biurkiem, encyklopedia czy chociażby
Bardziej szczegółowoWprowadzenie do geoinformatyki - podstawowe pojęcia Wydział Geodezji i Kartografii Politechnika Warszawska
Wprowadzenie do geoinformatyki - podstawowe pojęcia Wydział Geodezji i Kartografii Politechnika Warszawska Pomocnicze materiały dydaktyczne Geomatyka Geomatyka matematyka Ziemi oryg. Geomatics, the mathematics
Bardziej szczegółowoBazy danych 2. dr inż. Tadeusz Jeleniewski
Wykład 4 Projektowanie bazy danych i procesów aplikacji Modelowanie reguł przetwarzania Środowisko przykładowego programu do modelowania reguł przetwarzania Reguły poprawności 2018-02-23 Bazy danych 2
Bardziej szczegółowoKonfiguracja modelowania w procesie wytwarzania oprogramowania
Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na
Bardziej szczegół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ółowo