Jarosław Żeliński analityk biznesowy Prezentacja prowadzonej działalności, sposobu prowadzenia procesu analizy i projektowania oraz zasad współpracy

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

Download "Jarosław Żeliński analityk biznesowy Prezentacja prowadzonej działalności, sposobu prowadzenia procesu analizy i projektowania oraz zasad współpracy"

Transkrypt

1 Jarosław Żeliński analityk biznesowy Prezentacja prowadzonej działalności, sposobu prowadzenia procesu analizy i projektowania oraz zasad współpracy

2 Od 1991 roku w branży IT i zarządzania Od 1998 roku jako niezależny analityk, projektant i firma IT-Consulting.pl Dziesiątki publikacji w prasie branżowej i gospodarczej Członek Stowarzyszenia Doradców Gospodarczych Wykładowca Katedry Systemów Informacyjnych Wydziału Przedsiębiorczości Akademii Morskiej w Gdyni Kilkudziesięciu odbiorców usług doradczych, małe, średnie i duże firmy zarówno informatyczne jak i ich klienci oraz administracja publiczna. Poświadczenie bezpieczeństwa wydane przez ABW Publikacje między innymi w 2

3 RYNEK klienci IT-Consulting Jarosław Żeliński Działalność na rynku niezależnych usług eksperckich Zarządzanie firmą, świadczenie usług eksperckich, opracowywanie i prowadzenie szkoleń Strona WWW z ofertą Realizacja bieżących projektów Działalność publicystyczna, badawcza, dydaktyczna Stałe studia literatury i prace badawcze, udział w konferencjach i seminariach Eseje o rynku IT e-learning Autorskie publikacje, referaty na konferencjach Szkolenia i konsultacje 3

4 Aby zminimalizować ryzyko projektu Zamawiający powinien w specyfikacji wymagań dokładnie określić czego potrzebuje, dostawca na tej podstawie dopiero określi co musi dostarczyć i jakim kosztem jest w stanie tego dokonać. Ale jak opisać to czego naprawdę potrzebujemy? Inżynieria oprogramowania to tworzenie i dostarczanie oprogramowania spełniającego oczekiwania, w tym także wdrożenie gotowego oprogramowania jeśli spełnia te oczekiwania. Pierwszym podstawowym problemem do rozwiązania nie jest jednak spisanie tych oczekiwań w postaci specyfikacji wymagań, bo to jest drugi krok, a odkrycie jak naprawdę pracujemy oraz w czym i jak oprogramowanie ma nam pomagać bo z tego będzie wynikało to czego oczekujemy. 4

5 Idealny proces wytwórczy: 1. klient (zamawiający) dobrze opisał swoje oczekiwania i podał wszystkie istotne informacje 2. developer dobrze wszystko zrozumiał i określił budżet, termin i zakres projektu 3. developer od razu napisał dobry kod - dobre oprogramowanie Ale jak wiemy: 1. jeżeli jest ryzyko, że klient w sposób niekompletny opisze swoje oczekiwania należy wykonać analizę biznesową i ją udokumentować (powstaje model firmy klienta, który on zatwierdza) 2. jeżeli jest ryzyko, że developer nie zrozumie biznesu należy przetworzyć model biznesowy i cele biznesowe klienta na wymagania na oprogramowanie w postaci przypadków użycia i modelu dziedziny 3. jeżeli jest ryzyko, że developer nie napisze od razu dobrego oprogramowania należy stworzyć koncepcję architektury, opisać sekwencje realizacji przypadków użycia przez obiekty modelu dziedziny i komponenty, jak obiekty modelu dziedziny zrealizują interfejsy komponentów. Koncepcyjny model nowego oprogramowania to jedyny i najlepszy zarazem sposób zweryfikowania czy ono zadziała jeszcze przez rozpoczęciem implementacji. Ten etap stanowi także weryfikacje kompletności projektu. To autor analizy biznesowej wie najlepiej jak pracuje organizacja i to on posiada wiedzę by te działania odwzorować za pomocą oprogramowania dlatego dobrze jest, szczególnie w przypadku systemów dedykowanych, gdy analityk przekaże wymagania w postaci koncepcji nowego systemu a nie tylko jego opisu, bo to materiał, który rozumieją programiści wykonawcy. 5

6 6

7 Kosztowna pętla odkrywania wymagań Analiza wymagań Projektowanie Wykonanie Wdrożenie 3% 27% 55% 15% Specyfikacja wymagań Analiza Realizacja Użytkowanie 10-20% 13% 20-40% 5% Nowa wersja systemu (ewolucja) 30-50% oszczędzonego czasu i środków budżetowych, w tym czasie developer realizuje kolejny projekt zarabia. źr. IBM Praktyka pokazuje, że czas i środki poświęcone na analizę i projektowanie skracają proces implementacji. Głównym źródłem oszczędności jest wypracowany na początku i przetestowany model systemu dzięki czemu praktycznie unikamy pętli odkrywania nowych wymagań, nowych faktów już na etapie implementacji. Nie występują więc najbardziej kosztowne poprawki systemu w tym poprawki modelu danych. W dobrze prowadzonym projekcie analiza jest powtarzana tylko w celu wytworzenia nowej wersji systemu. Korzyści odnoszą tu i klient i wykonawca: System jest tańszy i dostarczony w krótszym czasie - korzysta klient Dotrzymane zakładane termin i pracochłonność to zachowanie pierwotnej planowanej marży korzysta wykonawca, w kontraktach fixed-price każde opóźnienie to utrata zysku Ryzyko porażki projektu sprowadzone do minimum korzystają wszyscy

8 Analizy i specyfikacje zorientowane na modele

9 My Inne podmioty systemu Przedmiot wspólnego zainteresowania Relacje i zależności w systemie 9

10 Elementy naszego wnętrza Procesy i reguły biznesowe 10

11 To chcemy otrzymać Produkt, który jest nam potrzebny: nasze oprogramowanie To są nasze prawdziwe wymagania Informacje o tym co przetwarzamy Informacje o tym jak to robimy 11

12 Opracowanie modelu biznesowego i kontekst projektu Cel biznesowy Opracowanie mapy kluczowych procesów biznesowych Model funkcjonowania firmy Opracowanie wewnętrznych scenariuszy procesów biznesowych i modelu danych Opisy przepływu pracy, model informacyjny Opracowanie specyfikacji wymagań, listy reguł biznesowych Wymagania na oprogramowanie i ograniczenia, Opracowanie scenariuszy przypadków użycia i GUI dla projektów dedykowanych Model przypadków użycia 12

13 1. Analiza biznesowa 1.1. opis celu projektu, lista ograniczeń 1.2. opis działalności zamawiającego 1.3. model kontekstowy - model biznesowy zamawiającego 1.4. model procesów biznesowych na poziomie "value chain" 1.5. modele procesów biznesowych objętych zakresem projektu 2. Specyfikacja wymagań 2.1. specyfikacje funkcjonalności (opcjonalnie przypadków użycia wraz z ekranami i scenariuszami) i interfejsów 2.2. model dziedziny wraz z opisem atrybutów i metod (model danych i reguł biznesowych) 2.3. ograniczenia (wymagania niefunkcjonalne) 2.4. raporty (specyfikacja raportów i ich treści) 2.5. dane o liczbie generowanych operacji w systemie w jednostkach czasu oraz liczba użytkowników i ról w systemie (jeśli nie podano w ograniczeniach) 2.7. koncepcja architektury, integracja z otoczeniem 13

14 Zbieranie danych Analiza i modelowanie Specyfikowanie Wzory dokumentów Mapy procesów biznesowych Lista przypadków użycia Struktura organizacyjna Model architektury systemu Lista ograniczeń Lista interfejsów Wzory raportów Model dziedziny Model danych Opracowanie własne, Jarosław Żeliński 14

15 Analiza dokumentacji Analiza celu biznesowego Modele (hipoteza) Cel projektu Wywiad (testowanie hipotezy) Raport Korekta modeli Specyfikacja wymagań tak Modele (hipoteza) Analiza zakresu projektu Modele nie Kolejny wywiad? Opracowanie własne, Jarosław Żeliński 15

16 Specyfikacja wymagań na oprogramowanie Model procesów Modelowanie i optymalizacja Specyfikacja procesów i kluczowych mierników jakości Specyfikacja kosztów działań Opracowany w toku analizy model procesów biznesowych może posłużyć jako uniwersalne narzędzie do innych analiz i projektów Struktura organizacyjna zasobów ludzkich 16

17 Poza funkcjonalne cechy systemu Przedmiot analizy biznesowej wymagań: istota modelowanej firmy Dziedzina systemu Gotowy system lub szkielet oprogramowania Pisanie od zera tej części systemu nie jest potrzebne. Ekrany są budowane na podstawie Modelu, sterowanie (Controller) jest gotowe. 18

18 Czas trwania Opracowanie własne, Jarosław Żeliński 19

19 Wymaga wysokich kwalifikacji po stronie analityka ale nie wymaga żadnego doświadczenia analitycznego po stronie zamawiającego (zamawiający jest jedynie odpytywany). Wymaga ścisłej współpracy i pełnej dyspozycyjności zamawiającego jednak zajmuje bardzo mało czasu zamawiającemu (zamawiający musi być dyspozycyjny ale nie musi sam niczego wypracowywać nie traci czasu nie licząc bardzo krótkich wywiadów i kolekcjonowania własnych dokumentów ) Dokumenty wymagają wiedzy od wykonawcy oprogramowania (notacja i metodyka obiektowa) jednak zamawiający zatwierdza wyłącznie zrozumiały dla niego opis własnej organizacji i specyfikację przypadków użycia. Projekty analityczne tego rodzaju trwają od kilku dni do kilku miesięcy, pracochłonność analizy wymagań, zawierającej analizę biznesową poprzedzającą specyfikowanie tych wymagań, zależy od bardzo wielu czynników, kluczowe to: Skala projektu (jaki obszar organizacji obejmuje) Ryzyko jakie projekt niesie dla organizacji (jaki cel biznesowy realizujemy i jakie są potencjalne skutki niepowodzenia) Stopień innowacyjności projektu (ile problemów zostało już rozwiązanych i rozwiązania te są dostępne na rynku a ile należy rozwiązać w trakcie projektu) Analiza może trwać dowolnie krótko lub długo, metoda od ogółu do szczegółu gwarantuje nam, że można przerwać pracę w dowolnym momencie i zawsze otrzymamy kompletny raport, co najwyżej jego wyniki będą mniej lub bardziej ryzykowne. Oznacza to, że zamawiający zawsze może świadomie określić budżet na analizę. Kluczową zaletą opisanej tu metody prowadzenia projektu z zakresu inżynierii oprogramowania jest bardzo małe ryzyko popełnienia błędu w specyfikowaniu wymagań a te błędy są w 100% przypadków podawane jako przyczyna porażek tego typu projektów. 22

20 Szanowny Panie, [ ] Jestem specjalistą w zakresie HR i poszukuję wspólnego języka z programistami tworzącymi czasami dla mnie oprogramowanie. Potwierdzam Pana zdanie - metody opisowe i zorientowane na przypadki użycia metody nie są skuteczne a nawet powiem bezużyteczne gdyż programiści nie czytają ich do końca. Proszę o pomoc i z góry dziękuję. 23

21 Jestem pod wielkim wrażeniem Pana artykułów, tym bardziej, że na przykładzie własnej firmy miałem okazję doświadczyć problemów wdrożeniowych, których przyczyny i skutki Pan opisuje. Niestety mimo najwyższej staranności i zaangażowania z naszej strony jeden z GoldPartnerów i jednocześnie laureat nagrody partnera roku firmy Microsoft zdołał "modelowo położyć na łopatki" nasz projekt. W związku z tym pewnie będę miał przyjemność popracować z Panem. Jak się domyślam, prawdopodobnie w ten właśnie sposób trafia do Pana większość klientów. 24

22 No naprawdę świetny dokument. Zajrzałem do tego pdf-a [przykładowa analiza*] i muszę powiedzieć że treść i forma super, gratuluję. Gdyby każdy projekt w IT był robiony na podstawie takiej specyfikacji to może inaczej wyglądałyby proporcje projektów zakończonych do porzuconych. *Opinia o dokumencie wymagań wykonanego opisaną metodą. 25

23 Co do Pańskiej analizy dla Vectry. Ja otrzymałem jedynie diagramy UML procesu windykacji. Stanowiły one punkt wyjścia do wdrożenia systemu Siebel jako systemu informatycznego wspomagającego ten proces. Przygotowane diagramy pozwoliły w jednoznaczny sposób nakreślić warunki brzegowe przygotowanej oferty. W czasie późniejszych prac stanowiły punkt odniesienia poszczególnych podprocesów w procesie windykacji. Przygotowana przez Pana analiza w bardzo dokładny sposób odzwierciedlała rzeczywistość biznesową działu windykacji Vectry. Wola Info SA, Kierownik Projektu Siebel CRM dla Vectra SA 26

24 "Współpraca z Jarkiem Żelińskim pokazała nam, że nasi programiści nie powinni jeździć do klienta bo tego nie lubią. Jarek opracował bardzo dobrą dokumentacje systemu, namówił klienta do rezygnacji z kosztownych a mało przydatnych funkcji, które niepotrzebnie podnosiły pracochłonność a projekt przewidywał wprowadzanie zmian w przyszłości minimalnym kosztem, zrezygnowaliśmy z zatrudniania etatowego analityka gdyż wolimy mieć bardzo dobrego analityka i zawierać z nim umowy tylko do realizacji projektów." 27

25 gwarancja Jako analityk zawieram umowy na analizę zarówno z kupującymi oprogramowanie jak i z jego dostawcami. W moim modelu biznesowym koszty poniższych trzech kompetencji (analiza, zarządzanie projektem, wdrożenie) występują zawsze, mogą być różnie rozłożone pomiędzy strony dostawca-wykonawca oprogramowania. Koszt analizy (IT-CONSULTING) Nadzór autorski Koszt zarządzania projektem Koszt dostarczenia i wdrożenia oprogramowania (dostawca oprogramowania) 28

26 PERSPEKTYWA OBSERWATORA Z ZIEMI (SYSTEM GEOCENTRYCZNY) ODKRYTA PRAWDA (SYSTEM HELIOCENTRYCZNY) Prawdę odkrył i udokumentował Kopernik, człowiek który nie szukał poklasku ani u zwykłych ludzi patrzących z wiarą w niebo, ani u tych, w których interesie było, by Ci ludzie wierzyli, że Ziemia to centrum ich świata. Ta prawda w efekcie wszystkim dobrze służy mimo początkowego oporu. Praktyka pokazuje, że systemy obserwowane z ich wnętrza wydają się bardzo skomplikowane i tak też są opisywane przez zwykłych ludzi. W rzeczywistości większość systemów jest znacznie prostsza jednak odkrycie tego wymaga spojrzenia z zewnątrz i uznania, że jesteśmy częścią czegoś większego a nie jego centralnym punktem. Dlatego warto zawsze wykonać pełną analizę a nie tylko zapisać to co widzą obserwatorzy. Rzemieślnicy produkujący przed Kopernikiem skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem tego modelu i swoich skomplikowanych przyrządów 29

27 Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle problemami złośliwymi (Rittel i Webber, 1973). Problem złośliwy to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

28 Jeśli tak, to zapraszam na dalszą prezentację lub spotkanie 32

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosł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ółowo

Zarządzanie informacją i automatyzacja procesów biznesowych trendy i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów

Zarządzanie informacją i automatyzacja procesów biznesowych trendy i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów Zarządzanie informacją i automatyzacja procesów biznesowych trendy i kierunki rozwoju Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Treść referatu będzie dotyczyła wyjaśnienia

Bardziej szczegółowo

BPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów

BPM vs. Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów BPM vs. Content Management Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Celem prezentacji jest zwrócenie uwagi na istotne różnice pomiędzy tym co nazywamy: zarzadzaniem dokumentami,

Bardziej szczegółowo

Automatyzacja procesów biznesowych jak to zrobić dobrze? Jarosław Żeliński analityk biznesowy, projektant systemów

Automatyzacja procesów biznesowych jak to zrobić dobrze? Jarosław Żeliński analityk biznesowy, projektant systemów Automatyzacja procesów biznesowych jak to zrobić dobrze? Jarosław Żeliński analityk biznesowy, projektant systemów Agenda kiedy można mówić o automatyzacji procesu kiedy jednak jest to tylko wsparcie procesu

Bardziej szczegółowo

Kierunki rozwoju systemów obiegu dokumentów: Enterprise Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów

Kierunki rozwoju systemów obiegu dokumentów: Enterprise Content Management. Jarosław Żeliński analityk biznesowy, projektant systemów Kierunki rozwoju systemów obiegu dokumentów: Enterprise Content Management Jarosław Żeliński analityk biznesowy, projektant systemów Cel prezentacji Coraz częściej można się spotkać w firmach z potrzebą

Bardziej szczegółowo

Case studies - doświadczenia, dobre praktyki. Jarosław Żeliński analityk biznesowy, projektant systemów

Case studies - doświadczenia, dobre praktyki. Jarosław Żeliński analityk biznesowy, projektant systemów Case studies - doświadczenia, dobre praktyki Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań Od 1998 2004 doradca

Bardziej szczegółowo

"Dziedzinowe obszary systemów: separacja dziedzinowa czyli Bounded Context" Jarosław Żeliński analityk biznesowy, projektant systemów

Dziedzinowe obszary systemów: separacja dziedzinowa czyli Bounded Context Jarosław Żeliński analityk biznesowy, projektant systemów "Dziedzinowe obszary systemów: separacja dziedzinowa czyli Bounded Context" Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku w branży IT i zarządzania jako analityk projektant

Bardziej szczegółowo

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Czy chmura może być bezpiecznym backupem? Ryzyka systemowe i prawne. Jarosław Żeliński analityk biznesowy, projektant systemów Agenda Definicja usługi backup i cloud computing Architektura systemu z backupem

Bardziej szczegółowo

Jak metody i narzędzia BPM - w tym BPMN - mogą służyć analitykom? Jarosław Żeliński analityk biznesowy, projektant systemów

Jak metody i narzędzia BPM - w tym BPMN - mogą służyć analitykom? Jarosław Żeliński analityk biznesowy, projektant systemów Jak metody i narzędzia BPM - w tym BPMN - mogą służyć analitykom? Jarosław Żeliński analityk biznesowy, projektant systemów O mnie Od 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań

Bardziej szczegółowo

Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów

Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju. Jarosław Żeliński analityk biznesowy, projektant systemów Nowości oraz trendy w obszarze BPM nurty i kierunki rozwoju Jarosław Żeliński analityk biznesowy, projektant systemów O mnie qod 1991 roku w branży IT i zarządzania jako analityk projektant rozwiązań qod

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

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

Bardziej szczegółowo

Projektowanie interakcji

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

Zasady organizacji projektów informatycznych

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

Bardziej szczegółowo

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji

HumanTechnology. 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ół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

Wykład 1 Inżynieria Oprogramowania

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów

Bardziej szczegółowo

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

WDROŻ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ółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarzą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ółowo

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

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

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

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ółfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka Warszawa dnia 25 lutego 2013 r. Szanowni Państwo,, z siedzibą w Warszawie przy ul. Wolność 3A, zwraca się z prośbą o przedstawienie oferty cenowej na usługę analizy przedwdrożeniowej i wdrożenia dla aplikacji

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona

Bardziej szczegółowo

Doradztwo i analiza Paperless

Doradztwo i analiza Paperless Doradztwo i analiza Paperless Jak efektywnie przeprowadzić projekt optymalizacyjny? Pomożemy Ci odpowiedzieć na to pytanie. Od czego zacząć usprawnienia?, W jakim zakresie jesteśmy w stanie zoptymalizować

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres 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ółowo

Wprowadzenie do systemów informacyjnych

Wprowadzenie do systemów informacyjnych Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj

Bardziej szczegółowo

Kompleksowe rozwiązanie dla organizacji,

Kompleksowe rozwiązanie dla organizacji, Kompleksowe rozwiązanie dla organizacji, W KTÓRYCH REALIZOWANE SĄ PRZEDSIĘWZIĘCIA PROJEKTOWE 0 801 2727 24 (22 654 09 35) Kompleksowe wsparcie realizacji projektu Czy w Twojej organizacji realizowane są

Bardziej szczegółowo

Departament Zakupów Centralnych ul. Żaryna 2A, 02-593 Warszawa tel. (22) 598 12 80 DZC/AS/708/12. Warszawa, dn. 27 listopada 2012 r.

Departament Zakupów Centralnych ul. Żaryna 2A, 02-593 Warszawa tel. (22) 598 12 80 DZC/AS/708/12. Warszawa, dn. 27 listopada 2012 r. Departament Zakupów Centralnych ul. Żaryna 2A, 02-593 Warszawa tel. (22) 598 12 80 DZC/AS/708/12 Warszawa, dn. 27 listopada 2012 r. Do wszystkich firm zainteresowanych złożeniem oferty dla Banku Dotyczy:

Bardziej szczegółowo

System CRM jako wsparcie procesów sprzedaży i serwisu w przedsiębiorstwach z branży produkcyjnej

System CRM jako wsparcie procesów sprzedaży i serwisu w przedsiębiorstwach z branży produkcyjnej System CRM jako wsparcie procesów sprzedaży i serwisu w przedsiębiorstwach z branży produkcyjnej 19 listopada 2009 Targi PROTECH 09 Michał Rok Professional Services Manager, update CRM Sp. z o.o. widok

Bardziej szczegółowo

ŚCIEŻKI KARIER ZAWODOWYCH ABSOLWENTÓW WYDZIAŁU MATEMATYKI I INFORMATYKI UMK

ŚCIEŻKI KARIER ZAWODOWYCH ABSOLWENTÓW WYDZIAŁU MATEMATYKI I INFORMATYKI UMK Kompetencje Dla Przyszłości rozwój potencjału zawodowego studentów i absolwentów UMK projekt realizowany w ramach Poddziałania 4.1.1 Programu Operacyjnego Kapitał Ludzki AGNIESZKA SZYMAOSKA ŚCIEŻKI KARIER

Bardziej szczegółowo

INFORMACJE O FIRMIE IT EXCELLENCE

INFORMACJE O FIRMIE IT EXCELLENCE INFORMACJE O FIRMIE IT EXCELLENCE IT EXCELLENCE SP. Z O.O. IT Excellence Sp. z o.o. jest firmą specjalizującą się we wdrażaniu oraz sprzedaży systemów ERP wspomagających zarządzanie. Głównym celem naszej

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

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

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...

Spis 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ółowo

Mapowanie wybranych procesów obsługi klienta w sektorze. Dzień 1.

Mapowanie wybranych procesów obsługi klienta w sektorze. Dzień 1. Mapowanie wybranych procesów obsługi klienta w sektorze publicznym Dzień 1. Cele warsztatów Główne cele naszego warsztatu to: przygotowanie do samodzielnego mapowania procesów utrwalenie techniki mapowania

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

Diagramy przypadków użycia

Diagramy 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ół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

Oprogramowanie, usługi i infrastruktura ICT w małych i średnich firmach w Polsce 2015. Na podstawie badania 800 firm z sektora MŚP

Oprogramowanie, usługi i infrastruktura ICT w małych i średnich firmach w Polsce 2015. Na podstawie badania 800 firm z sektora MŚP Oprogramowanie, usługi i infrastruktura ICT w małych i średnich firmach w Polsce 2015 2 Język: polski, angielski Data publikacji: IV kwartał 2015 Format: pdf Cena od: 2400 Możesz mieć wpływ na zawartość

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

OGŁOSZENIE DODATKOWYCH INFORMACJI, INFORMACJE O NIEKOMPLETNEJ PROCEDURZE LUB SPROSTOWANIE

OGŁOSZENIE DODATKOWYCH INFORMACJI, INFORMACJE O NIEKOMPLETNEJ PROCEDURZE LUB SPROSTOWANIE 1/ 11 ENOTICES_CPIMSWiA 25/06/2010- ID:2010-081521 Formularz standardowy 14 PL Publikacja Suplementu do Dziennika Urzędowego Unii Europejskiej 2, rue Mercier, L-2985 Luksemburg Faks (352) 29 29-42670 E-mail:

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego Fundusze Europejskie dla rozwoju regionu łódzkiego

Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego Fundusze Europejskie dla rozwoju regionu łódzkiego Łódź, dn. 10.10.2014 r. OGŁOSZENIE O ZAMÓWIENIU nr 2/3.3/081 (POWYŻEJ 14 tys. EURO) 1. Zamawiający Firma i adres: PL Europa S.A. NIP: 725-195-02-28 Regon: 100381252 2. Tryb udzielenia zamówienia Zgodnie

Bardziej szczegółowo

Załącznik Nr 1. Istotne warunki zamówienia do przetargu nieograniczonego na wykonanie pakietu usług programistycznych

Załącznik Nr 1. Istotne warunki zamówienia do przetargu nieograniczonego na wykonanie pakietu usług programistycznych Załącznik Nr 1 Do pisma IMP PAN l.dz. ZDN/1234/2007 z 2007-06-19 o ogłoszeniu przetargu nieograniczonego na pakiet usług programistycznych, których wartość nie przekracza progu, od którego obowiązuje prawo

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

Bardziej szczegółowo

JAK TO DOBRZE ZROBIĆ 5-06-2013

JAK TO DOBRZE ZROBIĆ 5-06-2013 WDROŻENIA ROZWIĄZAŃ PROCESOWYCH: JAK TO DOBRZE ZROBIĆ 5-06-2013 Syndatis 2013 PLAN PREZENTACJI Trochę o Syndatis. Intensywność występujących zagrożeń w projekcie Wdrożenie rozwiązań procesowych - to nie

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

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

Bardziej szczegółowo

Ryzyko to nasza działalność. www.riskexperts.at

Ryzyko to nasza działalność. www.riskexperts.at Ryzyko to nasza działalność 1 Bezpieczeństwo to podstawowy wymóg Bezpieczeństwo nie może być traktowane jako oddzielne wymaganie, jednakże zrozumienie potencjalnego ryzyka stanowi podstawę do zapewnienie

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Projekt Kwalifikacja jakości w Uniwersytecie Nr POKL.04.01.01-00-155/11. ZAPROSZENIE DO SKŁADANIA OFERT nr 4/ZSO/KJU/2014

Projekt Kwalifikacja jakości w Uniwersytecie Nr POKL.04.01.01-00-155/11. ZAPROSZENIE DO SKŁADANIA OFERT nr 4/ZSO/KJU/2014 Warszawa, 18.03.2014 r. ZAPROSZENIE DO SKŁADANIA OFERT nr 4/ZSO/KJU/2014 na usługę doradczą w zakresie modelowania wybranych procesów w uczelni wraz z rekomendacją dla operacyjnej warstwy procesów biznesowych

Bardziej szczegółowo

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10.

Czynniki wpływające na porażkę projektu. 1. Niekompletne wymagania 13.1% 2. Brak zaangażowania użytkowników 12.4% 3. Brak zasobów 10. Bez celu ani rusz Karolina Zmitrowicz Niepowodzenia projektów informatycznych to nieustannie wdzięczny temat pojawia się na konferencjach, szkoleniach, w prasie i innych publikacjach. Badaniem przyczyn

Bardziej szczegółowo

Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!!

Bardziej szczegółowo

Dane Klienta: PHP Maritex. ul. Rdestowa 53D. 81-577Gdynia. www.maritex.com.pl

Dane Klienta: PHP Maritex. ul. Rdestowa 53D. 81-577Gdynia. www.maritex.com.pl Dane Klienta: PHP Maritex ul. Rdestowa 53D 81-577Gdynia www.maritex.com.pl Firma P.H.P. Maritex została założona w 1987 roku i jest obecnie jedną z największych, dynamicznie rozwijających się hurtowni

Bardziej szczegółowo

Procedury Plan komunikacji w projektach

Procedury Plan komunikacji w projektach Procedury Plan komunikacji w projektach IT-Consulting Jarosław Żeliński Jarosław Żeliński IT-Consulting procedury Projekt : IT-Consulting procedury Autor : Firma : Opis: Jarosław Żeliński IT-Consulting

Bardziej szczegółowo

Państwowa Wyższa Szkoła Zawodowa w Ciechanowie INFORMATYKA

Państwowa Wyższa Szkoła Zawodowa w Ciechanowie INFORMATYKA Państwowa Wyższa Szkoła Zawodowa w Ciechanowie INFORMATYKA Zapotrzebowanie na informatyków rośnie szybciej niż liczba absolwentów IT jest jedną z najszybciej rozwijających się branż w Polsce. Perspektywy

Bardziej szczegółowo

Oprogramowanie, usługi i infrastruktura ICT w dużych firmach w Polsce 2015. Na podstawie badania 420 firm

Oprogramowanie, usługi i infrastruktura ICT w dużych firmach w Polsce 2015. Na podstawie badania 420 firm Oprogramowanie, usługi i infrastruktura ICT w dużych firmach w Polsce 2015 2 Język: polski, angielski Data publikacji: maj 2015 Format: pdf Cena od: 3000 Sprawdź w raporcie Jakie są najpopularniejsze modele

Bardziej szczegółowo

DESIGNER APPLICATION. powered by

DESIGNER APPLICATION. powered by DESIGNER APPLICATION powered by O FIRMIE HiddenData specjalizuje się w technologii dystrybucji treści video w Internecie oraz w budowie złożonych, funkcjonalnych aplikacji internetowych i mobilnych. Budujemy

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Zarządzanie Zapasami System informatyczny do monitorowania i planowania zapasów. Dawid Doliński

Zarządzanie Zapasami System informatyczny do monitorowania i planowania zapasów. Dawid Doliński Zarządzanie Zapasami System informatyczny do monitorowania i planowania zapasów Dawid Doliński Dlaczego MonZa? Korzyści z wdrożenia» zmniejszenie wartości zapasów o 40 %*» podniesienie poziomu obsługi

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami

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

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu

Bardziej szczegółowo

CRM w logistyce. Justyna Jakubowska. CRM7 Specjalista Marketingu

CRM w logistyce. Justyna Jakubowska. CRM7 Specjalista Marketingu CRM w logistyce Justyna Jakubowska CRM7 Specjalista Marketingu CRM w logistyce Prezentacja firm more7 Polska dostawca systemu CRM Autor i producent systemu do zarządzania relacjami z klientem CRM7; Integrator

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

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

Bardziej szczegółowo

Miary jakości w Call Center

Miary jakości w Call Center OFERTA SZKOLENIOWA Miary jakości w Call Center TELEAKADEMIA to profesjonalne centrum szkoleniowe mające swoją siedzibę w Pomorskim Parku Naukowo-Technologicznym w Gdyni. TELEAKADEMIA realizuje szkolenia

Bardziej szczegółowo

Architektura korporacyjna jako narzędzie koordynacji wdrażania przetwarzania w chmurze

Architektura korporacyjna jako narzędzie koordynacji wdrażania przetwarzania w chmurze Architektura korporacyjna jako narzędzie koordynacji wdrażania przetwarzania w chmurze Prof. SGH, dr hab. Andrzej Sobczak, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej SGH

Bardziej szczegółowo

Od wstępnej koncepcji do biznesplanu. Blok 3

Od wstępnej koncepcji do biznesplanu. Blok 3 Od wstępnej koncepcji do biznesplanu Blok 3 1 Od wstępnej koncepcji do biznes planu Agenda - zakres pojęcia biznes plan Definicje - co to jest biznes plan Funkcje - zastosowania i odbiorcy biznes planu

Bardziej szczegółowo

StatSoft profesjonalny partner w zakresie analizy danych

StatSoft profesjonalny partner w zakresie analizy danych Analiza danych Data mining Sterowanie jakością Analityka przez Internet StatSoft profesjonalny partner w zakresie analizy danych StatSoft Polska Sp. z o.o. StatSoft Polska Sp. z o.o. ul. Kraszewskiego

Bardziej szczegółowo

Znakowanie, zarządzanie i dystrybucja produktów w oparciu o standardy GS1

Znakowanie, zarządzanie i dystrybucja produktów w oparciu o standardy GS1 Znakowanie, zarządzanie i dystrybucja produktów w oparciu o standardy GS1 Szkolenia obejmuje przegląd najważniejszych i najczęściej stosowanych standardów GS1 wraz z praktycznymi informacjami na temat

Bardziej szczegółowo

Prezentacja firmy Royal Solutions Sp. z o.o.

Prezentacja firmy Royal Solutions Sp. z o.o. Prezentacja firmy Royal Solutions Sp. z o.o. Zawartość prezentacji Misja Doświadczenie Konsultanci Technologie Podejście do Klienta Proces realizacji projektów Badania dojrzałości projektowej Projekty

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

Projektowanie systemów informatycznych. wykład 6

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

Bardziej szczegółowo

Inżynieria Oprogramowania. Robert Szmurło

Inżynieria Oprogramowania. Robert Szmurło Robert Szmurło 1 Złożoność inżynierii oprogramowania Programowanie komputerowy jest zdecydowanie najbardziej skomplikowanym zadaniem intelektualnym podejmowanym przez człowieka. Kiedykolwiek. Gerald M.

Bardziej szczegółowo

Program Poprawy Efektywności Zakupów. Jak kupować, aby poprawiać rentowność?

Program Poprawy Efektywności Zakupów. Jak kupować, aby poprawiać rentowność? Program Poprawy Efektywności Zakupów Jak kupować, aby poprawiać rentowność? Oferta Zakupy Celem każdej firmy jest zdobycie dominującej pozycji na rynku, która przekłada się na poziom obrotów i zysków firmy.

Bardziej szczegółowo

Rynek IT w Polsce 2015. Prognozy rozwoju na lata 2015-2020

Rynek IT w Polsce 2015. Prognozy rozwoju na lata 2015-2020 2 Język: polski, angielski Data publikacji: sierpień 2015 Format: pdf Cena od: 2000 Sprawdź w raporcie Jaka jest wartość rynku IT w Polsce? Jakie są prognozy dla rynku IT w Polsce do roku 2020? Jaka jest

Bardziej szczegółowo

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Wstę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ółowo

STRATEGIA zamówień publicznych w przedsięwzięciach informatycznych MF

STRATEGIA zamówień publicznych w przedsięwzięciach informatycznych MF Warszawa, 10 grudnia 2014 r. STRATEGIA zamówień publicznych Robert Kietliński Zastępca Dyrektora Departament Informatyzacji Usług Publicznych Z czym mamy do czynienia? Skala informatycznych zamówień w

Bardziej szczegółowo

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

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

Bardziej szczegółowo

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna

Bardziej szczegółowo

Wdrożenie technologii procesowej IBM BPM w EFL

Wdrożenie technologii procesowej IBM BPM w EFL Wdrożenie technologii procesowej IBM BPM w EFL Marcin Naliwajko Z-ca dyrektora Departamentu Technologii Dominik Lisowski Starszy Architekt Systemów IT Grupy EFL WebSphere Message Broker 2008 r. Wdrożenie

Bardziej szczegółowo

ZAMÓWIENIA GIS BY CTI. Opis programu

ZAMÓWIENIA GIS BY CTI. Opis programu ZAMÓWIENIA GIS BY CTI Opis programu 1. Opis programu GIS to System Informacji Geograficznej służący do wprowadzania, gromadzenia, przetwarzania oraz wizualizacji danych geograficznych. Program został stworzony

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Zastosowanie sztucznych sieci neuronowych w prognozowaniu szeregów czasowych (prezentacja 2)

Zastosowanie sztucznych sieci neuronowych w prognozowaniu szeregów czasowych (prezentacja 2) Zastosowanie sztucznych sieci neuronowych w prognozowaniu szeregów czasowych (prezentacja 2) Ewa Wołoszko Praca pisana pod kierunkiem Pani dr hab. Małgorzaty Doman Plan tego wystąpienia Teoria Narzędzia

Bardziej szczegółowo

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania Literatura Marek Kisiel-Dorohinicki doroh@agh.edu.pl Brett D. McLaughlin, Gary Pollice, David West Head First Object-Oriented Analysis and Design Martin Fowler UML Distilled ( UML w kropelce ) Grady Booch,

Bardziej szczegółowo