Laboratorium z zarządzania procesami biznesowymi

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

Download "Laboratorium z zarządzania procesami biznesowymi"

Transkrypt

1 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Laboratorium z zarządzania procesami biznesowymi dr Andrzej Sobczak

2 Agenda spotkania Sprawdzamy pracę domową Jak zastosować podejście procesowe przy wdraŝaniu IT Dwa słowa nt.: czym jest UML czym jest RUP UML w modelowaniu biznesowym Zamiast podsumowania... 2

3 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Sprawdzamy pracę domową

4 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Jak zastosować podejście procesowe przy wdraŝaniu IT

5 Jak zastosować procesy biznesowe przy wdraŝaniu IT Analiza kontekstu biznesowego Analiza istniejących procesów Klasyfikacja procesów Opis procesów Identyfikacja usprawnień Opracowanie specyfikacji wymagań dla rozwiązań IT Model wymagań biznesowych Wybór kierunku rozwoju IT System z z półkip ki Implemen- tacja 5

6 Analiza kontekstu biznesowego Obszar biznesu Na czym firma chce budować wartość, co ma decydować o jej przewadze konkurencyjnej? - cena - oferta produktowa - jakość obsługi W jakim zakresie firma ma być pionierem a w jakim naśladowcą? W jakim zakresie poszczególne obszary działalności powinny być zróŝnicowane ze względu na produkty? Czy obsługa i wymiana informacji z klientami, dostawcami ma dokonywać się w sposób elektroniczny? Jaki stopień dynamiki oraz zakres zmian przewidywany jest w poszczególnych obszarach? Obszar IT Jakie są priorytety wdroŝenia rozwiązań w poszczególnych procesach? W jakim zakresie zastosowanie rozwiązań IT powinno mieć standardowy (rozwiązanie z półki ), a w jakim unikatowy ( skrojony na miarę ) charakter? Jaki zakres rozwiązań IT powinien być wspólny, a jaki zróŝnicowany na produkty? Jakie są wymagane standardy bezpieczeństwa oraz standardy wymiany danych z otoczeniem? Jaki jest wymagany zakres elastyczności systemu na zmiany? 6

7 Klasyfikacja procesów Podejście do klasyfikacji procesów: Top down wstępna klasyfikacja, przed rozpoczęciem opracowania map procesów Bottom up klasyfikacja procesów po dokonaniu analizy powiązań pomiędzy działaniami Określenie zdarzeń/podmiotów inicjujących procesy oraz końcowych rezultatów/odbiorców produktów PrzełoŜenie zdarzeń/rezultatów na procesy - łączenie działań wg ciągów przyczynowo-skutkowych Zachowanie rozłączności procesów Określenie priorytetów procesów Dostosowanie poziomu szczegółowości opisu procesów do ich priorytetów oraz wymaganego poziomu standaryzacji Przyjęcie kilku wzorcowych (2-3) jednostek organizacyjnych dla opracowania modelu 7

8 Opis procesów Wykorzystanie umownej notacji dla przedstawienia: zdarzeń inicjujących proces rezultatów procesu działań (zróŝnicowanych na manualne oraz zautomatyzowane: dialogowe, wsadowe) przebiegu procesu (z wyodrębnionym elektronicznym przepływem danych) z uwzględnieniem wyjątków oraz alternatywnych ścieŝek Rozszerzenie opisu działań o następujące elementy: wymagane kontrole powiązania z dokumentacją wykorzystywaną w procesie powiązania z jednostkami organizacyjnymi, w których działania są realizowane powiązania z aktualnie wykorzystywanymi systemami informatycznymi Określenie parametrów procesów: czas realizacji koszt realizacji liczba zaangaŝowanych etatów częstotliwość zdarzeń w procesach liczba jednostek obsługiwanych w procesach liczba błędów występujących w procesach 8

9 Identyfikacja usprawnień Ocena jakości procesów biznesowych Określenie przyczyn, dla których procesy biznesowe nie dostarczają oczekiwanych rezultatów Identyfikacja słabych punktów w procesach wynikających z braku bądź nieefektywności rozwiązań IT Określenie usprawnień, których wdroŝenie jest moŝliwe dzięki rozwiązaniom IT Wyodrębnienie w modelu procesów wszystkich działań, które: są obecnie zautomatyzowane, jednakŝe wymagają uzupełnienia bądź migracji do nowego rozwiązania powinny zostać zautomatyzowane: przekształcenie danych w działaniach moŝna opisać algorytmem działania są kluczowe dla realizacji procesu (efektywność, jakość, ryzyko operacyjne) działania są realizowane często i/lub są złoŝone są stabilne ze względu na zmiany Określenie przebiegu procesów po wdroŝeniu usprawnień Oszacowanie korzyści/oszczędności wynikające z wdroŝenia rozwiązań IT Określenie priorytetów dla wdroŝenia rozwiązań IT w róŝnych obszarach realizacji procesów 9

10 Opracowanie specyfikacji wymagań Model wymagań biznesowych System z półki Implementacja Proces wyboru i dostosowania oprogramowania Model obiektów Model procesów Model koncepcyjny Projekt bazy Model techniczny Projekt modułów 10

11 Modelowanie biznesowe Ułatwienie zrozumienia struktury i dynamiki organizacji, w której oprogramowanie ma być wdraŝane (tzw. organizacji docelowej ). Ułatwienie zrozumienia aktualnych problemów organizacji w celu zidentyfikowania miejsc dla potencjalnych ulepszeń. Uzyskanie pewności, Ŝe wszyscy uczestnicy projektu (klienci, uŝytkownicy i członkowie zespołu projektowego) postrzegają docelową organizację w jednakowy sposób (jej strukturę, dynamikę i problemy). Ma to znaczenie, gdy trzeba zbudować system na zamówienie konkretnego klienta, ponadto wspierający prace w organizacji, gdzie procesy biznesowe są złoŝone. Właściwa realizacja projektu wymaga tu pełnej świadomości skutków automatyzacji prac. 11

12 Model wymagań biznesowych Model procesów biznesowych uwzględniający usprawnienia Opisuje sposób wykorzystania systemów informatycznych z punktu widzenia uŝytkownika: przeznaczenie systemu zakres działań realizowanych przez system opis interakcji z uŝytkownikami, innymi systemami, podmiotami zewnętrznymi Jest uzupełniony o oczekiwane wartości mierników efektywnościowych Określa wymagania funkcjonalne oraz informacyjne wynikające z potrzeby: modyfikacji istniejących systemów wdroŝenia nowych systemów Określa wymagania w zakresie integracji systemów: dostęp do wspólnych baz danych zbudowanie interfejsów wymiany danych 12

13 Wybór kierunku rozwoju systemu IT proces system Czy dostosować system do procesu czy proces do systemu? Czy procesy, czy rozwiązania technologiczne stanowią o przewadze konkurencyjnej? Jaki jest stopień dopasowania pomiędzy rozwaŝanym rozwiązaniem IT oraz istniejącymi potrzebami biznesowymi? Koszt? Czas trwania wdroŝenia? Zakres zmian w procesach, systemach IT? Ryzyko niepowodzenia wdroŝenia? Jak rozwiązanie wpływa na relacje z otoczeniem? 13

14 Budować czy kupić? System implementowany od początku Proces stanowi o przewadze konkurencyjnej W procesach o specyfice, dla której brak wsparcia w systemach z półki Nakłady dostosowania systemu z półki przewyŝszają nakłady implementacji systemu od początku Wymaga bardzo szczegółowej specyfikacji wymagań uŝytkowników Wysokie ryzyko niepowodzenia wdroŝenia? System z półki Proces standardowy DuŜa presja czasu na wdroŝenie Systemy IT posiadają wystarczający zakres parametryzacji w ramach istniejącej funkcjonalności Wysoki poziom niezawodności MoŜliwość rozbudowy oraz integracji w istniejącym środowisku informatycznym Oddalenie się od osiągnięcia głównych czynników stanowiących o przewadze konkurencyjnej Opór przed wdroŝeniem zmian do procesów Trudności w integracji w istniejącej infrastrukturze technologicznej Niewykorzystanie pełnej funkcjonalności standardowego oprogramowania 14

15 System z półki Analiza luk pomiędzy wymaganiami biznesowymi a istniejącą funkcjonalnością systemu Określenie moŝliwości parametryzacji systemu lub określenie zakresu zmian wymaganych w procesach Przygotowanie szczegółowej specyfikacji w zakresie uzupełnienia luki pomiędzy istniejącą, a wymaganą funkcjonalnością systemów Analiza nakładającej się funkcjonalności pomiędzy róŝnymi aplikacjami Określenie moŝliwości integracji aplikacji z innymi systemami Specyfikacja wymaganych interfejsów pomiędzy systemami 15

16 Implementacja Model obiektów obejmuje: wyodrębnione obiekty biznesowe, które są przedmiotem działań realizowanych w procesie atrybuty opisujące poszczególne obiekty Model procesów obejmuje: zdarzenia, które inicjują proces sekwencje działań wykonywanych przez poszczególne jednostki organizacyjne zakres informacji powiązania z obiektami - wykorzystywanych (będących na wejściu/wyjściu) w procesie oraz jego poszczególnych działań operacje na obiektach: utworzenie, odczyt, modyfikacja, usunięcie reguły i/lub warunki wykonania operacji na obiektach zdefiniowane za pomocą sformalizowanych algorytmów reguły kontroli danych interakcje w procesie z uŝytkownikami z innymi procesami Wymagania pozafunkcjonalne: Wydajność Bezpieczeństwo Rozszerzalność Otwartość 16

17 Problemy z procesami Stworzone przez zamkniętą w przedsiębiorstwie grupę ludzi Nierealistyczne podejście Niska świadomość pracowników Lęk przed poraŝką Mnogość notacji 17

18 Dwa słowa nt.: - czym jest UML - czym jest RUP Katedra Informatyki Gospodarczej Szkoła Główna Handlowa

19 Cele stworzenia UML Wizualny język modelowania do budowy i wymiany modeli. Silny mechanizm rozbudowy. Wykorzystywany przy tworzeniu systemów informatycznych NiezaleŜny od języków programowania i procesów tworzenia. Wspomaga wysoko-poziomowe rozwiązania. 19

20 Początki UML (1a) Na przełomie lat 80-tych i 90-tych pojawiło się ponad 50 róŝnorodnych metodyk obiektowych m.in. Booch, OMT, OOSE/Objectory, Fusion, Coad/Yourdon. Poszczególni twórcy próbowali wykazać wyŝszość własnego rozwiązania nad pozostałymi, co niekorzystnie wpływało na przemysłowe próby zastosowania technologii obiektowych. KaŜda metodologia miała własną notację, otrzymywała wsparcie ze strony róŝnych narzędzi programistycznych, obejmowała róŝny zakres projektowania systemu informatycznego. 20

21 Początki UML (5) UML OMT SA/RT ERD JSD SADT Merise DFD DFD etc. 21

22 UML wprowadza zestaw standardowych diagramów Use Use Case Case Diagrams Use Use Case Case Diagrams Activity Activity Diagrams Diagrams Use Use Case Case Diagrams Use Use Case Diagrams Use Use Case Case Diagrams Diagrams State Diagrams State State Diagrams Class Class Diagrams Diagrams State Diagrams State State Diagrams Object Object Diagrams Diagrams Scenario Diagrams Scenario Scenario Diagrams Sequence Sequence Diagrams Diagrams Model State Diagrams State Diagrams State State Diagrams Diagrams Scenario Diagrams Scenario Collaboration Scenario Diagrams Diagrams Diagrams Deployment Diagram Diagram Component Component Diagrams Component Diagrams Component Diagrams Diagrams Component Diagrams Diagrams 22

23 Czym jest RUP (Rational Unified Process) RUP jest procesem (wytwórczym) inŝynierii oprogramowania, którego celem jest zapewnienie produkcji wysokiej jakości oprogramowania z przewidywalnym budŝetem i harmonogramem, które spełni oczekiwania uŝytkowników końcowych. RUP reprezentuje dyscyplinarne podejście przypisujące zadania i obowiązki wewnątrz zespołu. RUP jest konfigurowalnym procesem, poniewaŝŝaden pojedynczy proces nie jest odpowiedni do wytworzenia kaŝdej aplikacji. W ten sposób istnieje moŝliwość dostosowania procesu do rozmaitych sytuacji. RUP jest produktem rozwijanym i utrzymywanym przez firmę IBM opartym na doświadczeniu w pracy z wieloma klientami firmy. RUP jest przewodnikiem jak skutecznie uŝywać UML a. 23

24 RUP - Rational Unified Process Oś pionowa reprezentuje statyczne aspekty (zawartość) procesu; opisuje proces pod względem działań, artefaktów, pracowników (ang. workers) oraz przepływu zadań (ang. workflow). Inicjacja - Rozwijanie Konstruowanie -WdroŜenie Przekazanie Oś pozioma reprezentuje czas i przedstawia dynamiczne aspekty procesu uŝywając pojęć: cykli, faz, iteracji oraz kamieni milowych (ang. milestones). Proces tworzenia oprogramowania podzielony jest na cykle, gdzie kaŝdy cykl reprezentuje tworzenie nowej generacji (wydania) produktu. 24

25 Iteracje w RUP KaŜda faza RUP moŝe zostać podzielona na iteracje. Iteracja jest kompletną pętlą tworzenia pewnej części finalnego produktu, który przyrasta inkrementalnie z jednej iteracji na drugą tworząc ostatecznie końcowy system. Korzyści podejścia iteracyjnego: łatwiejsze zaŝegnanie elementów ryzyka, większa zarządzalność zmianami, moŝliwość nauki zespołu projektowego w trakcie projektu, lepsza całkowita jakość, 25

26 Fazy Ŝycia w RUP a diagramy UML Zamiast skupiać się na produkcji duŝej ilości papierowych dokumentów RUP kładzie większy nacisk na tworzenie semantycznie bardziej treściwych modeli. 26

27 Składniki RUP (1) Role i ich aktywności 27

28 Składniki RUP (2) Artefakty Szablony 28

29 Składniki RUP (4) Koncepcje (metody postępowania) Przepływy pracy ( krok po kroku ) 29

30 Przepływ pracy: inŝynieria wymagań Develop Vision Manage Dependencies Elicit Stakeholder Needs Find Actors and Use Cases Capture a Common Vocabulary Structure the Use-Case Model Requirements Reviewer Use-Case Specifier Detail a Use Case Review Requirements User-Interface Designer User-Interface Modeling User-Interface Prototyping Architect Prioritize Use Cases 30

31 Przepływ pracy: analiza i projektowanie Architectural Analysis Architect Architectural Design Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer Designer Use-Case Analysis SubsystemDesign Use-Case Design Review the Design Design Reviewer Class Design Database Designer Database Design 31

32 Przepływ pracy: implementacja Architect Structure the Implementation Model System Integrator Plan System Integration Integrate System Implementer Plan Subsystem Integration Implement Classes Perform Unit Test Integrate Subsystem Fix a Defect Code Reviewer Review Code 32

33 Przepływ pracy: testy Test Designer PlanTest Design Test ImplementTest Evaluate Test Integration Tester Execute Integration Test System Tester Execute System Test Performance Tester Execute Performance Test Designer Design Test Classes and Packages Implementer Implement Test Components and Subsystems 33

34 Składniki RUP (5) Produkty informatyczne 34

35 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa UML w modelowaniu biznesowym

36 ZałoŜenia Struktura organizacji nie jest wystarczająca do zrozumienia jak funkcjonują jej procesy biznesowe. Niezbędne jest tu dynamiczne spojrzenie na biznes. Modelowanie biznesu umoŝliwia zlokalizowanie problemów lub zidentyfikowanie moŝliwości wprowadzenia ulepszeń do procesów zachodzących w organizacji. 36

37 Modelowanie biznesowe (1) Cele modelowania od strony organizacji: Zrozumienie bieŝących problemów danej organizacji i identyfikacja moŝliwości ulepszenia zachodzących procesów biznesowych. Ocena wpływu zmian organizacyjnych. Zapewnienie, Ŝe klienci, końcowi uŝytkownicy i inni jednakowo rozumieją organizację pod kątem zachodzących w niej procesów biznesowych. Wskazanie wymagań na utworzenie oprogramowania niezbędnego dla wsparcia procesów biznesowych danej organizacji. 37

38 Modelowanie biznesowe (2) Cele modelowania od strony systemu informatycznego: Czy wszystkie wymagania (systemowe przypadki uŝycia) dla budowanego systemu informatycznego zostały zidentyfikowane? Jak pracownicy organizacji realizują procesy biznesowe organizacji przed wprowadzeniem systemu informatycznego? Jaką wartość wniesie system do biznesu? Jak będzie wyglądał biznes, gdy system informatyczny będzie go wspierał? 38

39 Proces modelowania biznesowego 39

40 Notacja UML w modelowaniu biznesowym UŜycie jednakowej notacji oraz narzędzi do modelowania biznesu oraz systemu umoŝliwia analitykom biznesowym oraz analitykom systemowym lepsze przedstawienie swoich potrzeb, co stanowi klucz do budowy systemu, który rozwiązuje problemy klientów. 40

41 Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼- ü ¼³Á À» äã»çñ Ù. È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù. 1: Doc view request ( ) 1: Doc view request ( ) 9: sortbyname ( ) 2: fetchdoc( ) L 3: create ( ) 6: filldocument ( ) 9: sortbyname ( ) 2: fetchdoc( ) 7: readfile ( ) 5: readdoc ( ) 4: create ( ) 8: fillfile ( ) 5: readdoc ( ) 7: readfile ( ) 4: create ( ) 8: fillfile ( ) 3: create ( ) 6: filldocument ( ) FileMgr fetchdoc( ) sortbyname( ) rep Repository (from Persistence) name : char * = 0 readdoc( ) readfile( ) UI DocumentApp Persistence FileList add( ) delete( ) File read( ) DocumentList add( ) delete( ) flist 1 GrpFile read( ) open( ) create( ) fillfile( ) Document name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) global MFC RogueWave read() fill the code.. Openning Reading add file [ numberoffile==max ] / flag OFF close file Closing close file add file Writing ºÐ»ê È æàç Çϵå þ¾î¹ ³ Æ À ÎÀÇ Á º ½Ã½ºÅÛ á ðµ - À µµ ì 95 : Å óàì¾ðæ - À µµ ì NT: ÀÀ ë¼-¹ö - À нº Ó½Å: ÀÀ ë ¼-¹ö ¹ µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö - IBM ÞÀÎÇÁ ¹ÀÓ: µ ÀÌÅ ¼-¹ö, Åë½Å ¼-¹ö Window95 ¹ ¼- ü Å óàì¾ðæ.exe Windows NT Windows NT ¹ ¼- ü Áø.EXE Windows95 IBM Mainf rame µ ÀÌÅ º À̽º¼-¹ö Solaris ÀÀ ë¼-¹ö.exe Windows95 ¹ ¼- ü ¾ÖÇà Alpha UNIX UML jak to działa? BOM, Business Use-Case Diagram, Class Diagram Use-Case Diagram Actor A Use Case 1 Actor B State Diagram Ekspert dziedzinowy Use Case 2 Use Case 3 <<entity>> Customer name addr receive() withdraw() fetch() send() Class Deployment Diagram Repository DocumentList user :»ç ëàú mainwnd : MainWnd filemgr : FileMgr gfile : GrpFile Package Diagram FileManager GraphicFile File Document FileList repository : Repository mainwnd filemgr : document : gfile repository user FileMgr Document document : Document Collaboration Diagram Component Diagram Forward Engineering(Code Generation) and Reverse Engineering Sequence Diagram SYSTEM 41

42 UML jak to działa? Pierwszym krokiem w modelowaniu biznesu jest zdefiniowanie interakcji pomiędzy jednostkami na zewnątrz biznesu (dostawcy, klienci partnerzy, inne wydziały, itd.) a procesami biznesowymi organizacji. Interakcja jest dokumentowana w Diagramach Biznesowych Przypadków UŜycia. Diagramy wizualnie przedstawiają interakcję pomiędzy głównymi usługami które organizacja dostarcza a tymi, dla których usługi są dostarczane (Business Actors). 42

43 Business Use Case Model Model Biznesowych przypadków uŝycia The processes of a business are defined as a number of different business use cases, each of which represents a specific workflow in the business. A business use case defines what should happen in the business when it is performed. Określa jak przedsiębiorstwo reaguje na klienta lub zdarzenie UŜywany do identyfikacji aktorów i procesów biznesowych Zewnętrzne spojrzenie na planowane procesy biznesowe 43

44 Business Use Case Model Biznesowych przypadków uŝycia Aktor (na zewnątrz organizacji) Proces biznesowy 44

45 Model Biznesowych przypadków uŝycia - dekompozycja 45

46 Business Object Model A Business Object Model defines the business use cases from the business workers internal viewpoint. The model defines how people who work in the business, and the things they handle and use Składniki BOM: Business workers pracownik biznesowy Business entities 46

47 Business Object Model Business workers reprezentuje stanowisko powołane w organizacji Business entities reprezentuje obiekty, które pracownik biznesowy wykorzystuje, produkuje, bada, kontroluje; ma charakter statyczny 47

48 Business Object Model - przykład Produkt Sprzedawca Kontroler Wyciąg z operacji Paragon Karta przewozowa 48

49 Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Dziękuję za uwagę

UML w Visual Studio. Michał Ciećwierz

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

Bardziej szczegółowo

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

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

UPEDU: Analiza i projektowanie (ang. analysis and design discipline)

UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Wydział Informatyki PB Analogia do powstawania kryształu Inżynieria oprogramowania II Wykład 7: UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Marek Krętowski e-mail: mkret@wi.pb.edu.pl

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

Całościowe spojrzenie na organizację

Całościowe spojrzenie na organizację Procesy biznesowe Całościowe spojrzenie na organizację Strategia Wyniki Strategia Wyniki Uwarunkowania prawne Potrzeby klientów Uwarunkowania rynkowe Oczekiwania udziałowców Uwarunkowania prawne Potrzeby

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

Rozpoczęcie, inicjacja (ang. inception

Rozpoczęcie, inicjacja (ang. inception Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl

Bardziej szczegół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

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie oprogramowania w środowisku IBM Rational Software Architect Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze

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

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

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

Dr Katarzyna Grzesiak-Koped

Dr Katarzyna Grzesiak-Koped Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd

Bardziej szczegółowo

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011

Projekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011 Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo

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

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS

AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS AN EVOLUTION PROCESS FOR SERVICE- ORIENTED SYSTEMS Andrzej Zalewski, Marcin Szlenk, Szymon Kijas a.zalewski@elka.pw.edu.pl s.kijas@elka.pw.edu.pl Praca naukowa finansowana ze środków budżetowych na naukę

Bardziej szczegółowo

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań Albert Ambroziewicz, Michał Śmiałek Politechnika Warszawska KKIO 0, SCR 0 27-29.09.200 Treść prezentacji Wprowadzenie powtarzalność rozwiązań w IO Koncepcja

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

Język UML w modelowaniu systemów informatycznych

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

Bardziej szczegółowo

WOJSKOWA AKADEMIA TECHNICZNA

WOJSKOWA AKADEMIA TECHNICZNA WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

MODELOWANIE OBIEKTOWE

MODELOWANIE OBIEKTOWE (Wykład na podstawie literatury: M.Śmiałek Zrozumieć UML 2.0, Helion 2005) UML Unified Modeling Language (język do specyfikowania, wizualizowania, konstruowania i dokumentacji tzw. artefactów oraz czynności

Bardziej szczegółowo

Podstawy modelowania biznesowego w inżynierii oprogramowania

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

Bardziej szczegółowo

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

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Testy poziom po poziomie

Testy poziom po poziomie poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.

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

Konfiguracja modelowania w procesie wytwarzania oprogramowania

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

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

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

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

Michał Adamczyk. Język UML

Michał Adamczyk. Język UML Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy

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

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

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

Bardziej szczegółowo

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011

Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF. Tomasz Turski 26.05.2011 Projekt architektury systemów informatycznych Uniwersytetu Warszawskiego w oparciu o metodykę TOGAF Tomasz Turski 26.05.2011 Plan prezentacji Architektura korporacyjna Frameworki Pryncypia Metodyka TOGAF

Bardziej szczegółowo

bo od managera wymaga się perfekcji

bo od managera wymaga się perfekcji bo od managera wymaga się perfekcji MODELOWANIE PROCESÓW Charakterystyka modułu Modelowanie Procesów Biznesowych (BPM) Modelowanie procesów biznesowych stanowi fundament wdroŝenia systemu zarządzania jakością

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

MODELOWANIE SYSTEMU OCENY WARUNKÓW PRACY OPERATORÓW STEROWNI

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

Bardziej szczegółowo

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

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegółowo

Tworzenie modelu konceptualnego systemu informatycznego część 1

Tworzenie modelu konceptualnego systemu informatycznego część 1 Tworzenie modelu konceptualnego systemu informatycznego część 1 1. Elementy diagramów przypadków użycia (usecases) 2. Wytyczne tworzenia diagramów przypadków użycia (use-cases) (wg Booch G., Rumbaugh J.,

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

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

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Inżynieria oprogramowania

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

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA

INŻYNIERIA OPROGRAMOWANIA INSTYTUT INFORMATYKI STOSOWANEJ 2013 INŻYNIERIA OPROGRAMOWANIA Inżynieria Oprogramowania Proces ukierunkowany na wytworzenie oprogramowania Jak? Kto? Kiedy? Co? W jaki sposób? Metodyka Zespół Narzędzia

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

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

Projekt systemu informatycznego

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

Bardziej szczegółowo

Tworzenie przypadków testowych

Tworzenie przypadków testowych Tworzenie przypadków testowych Prowadząca: Katarzyna Pietrzyk Agenda 1. Wprowadzenie 2. Wymagania 3. Przypadek testowy Definicja Schemat Cechy dobrego przypadku testowego 4. Techniki projektowania Czarnej

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 1 Wprowadzenie do narzędzia CASE

Bardziej szczegółowo

Prowadzący Andrzej Kurek

Prowadzący Andrzej Kurek Prowadzący Andrzej Kurek Centrala Rzeszów Oddziały Lublin, Katowice Zatrudnienie ponad 70 osób SprzedaŜ wdroŝenia oprogramowań firmy Comarch Dopasowania branŝowe Wiedza i doświadczenie Pełna obsługa: Analiza

Bardziej szczegółowo

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.

Bardziej szczegółowo

Języki i metodyka oprogramowania

Języki i metodyka oprogramowania Języki i metodyka oprogramowania Automatyka i Robotyka sem.2 (część I) Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Literatura A. Januszkiewicz. Inżynieria oprogramowania. Helion 1997. W. Dąbrowski,

Bardziej szczegółowo

Identyfikacja i modelowanie struktur i procesów biologicznych

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

Bardziej szczegółowo

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

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)

Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES) KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu w języku angielskim Modeling and Analysis of Information Systems Obowiązuje od roku akademickiego

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20 Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:

Bardziej szczegółowo

Architektura 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 Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

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

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

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

Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq

Skuteczna Strategia CRM - wyzwanie dla organizacji. Artur Kowalski Prometriq Skuteczna Strategia CRM - wyzwanie dla organizacji Artur Kowalski Prometriq Wrocław, 19-11-2009 Jest tylko jedna strategia sukcesu Polega ona na precyzyjnym zdefiniowaniu docelowego odbiorcy i zaoferowaniu

Bardziej szczegółowo

Zalety projektowania obiektowego

Zalety projektowania obiektowego Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy

Bardziej szczegółowo

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny mgr inż. Kajetan Kurus 15 kwietnia 2014 1 Dostępne techniki programowania Tworząc program należy

Bardziej szczegółowo

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE]

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] Parę słów o mnie 2 Nauczyciel akademicki od 2000 roku Od 2002 współpracuję z firmami jako programista i projektant aplikacji Od 2006 roku właściciel firmy

Bardziej szczegółowo

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski INŻYNIERIA OPROGRAMOWANIA wykład 6A: ANALIZA i PROJEKTOWANIE wg RUP dr inż. Leszek Grocholski ( na podstawie książek o RUP ) Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski OBIEKTOWE

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML

Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML VIII Konferencja PLOUG Koœcielisko PaŸdziernik 2002 Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML Piotr Wilk Premium Technology Sp. z o.o. PWilk@PremiumTechnology.pl Modelowanie

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

Bardziej szczegółowo

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)

Bardziej szczegółowo

Laboratorium z zarządzania procesami biznesowymi

Laboratorium z zarządzania procesami biznesowymi Katedra Informatyki Gospodarczej Szkoła Główna Handlowa Laboratorium z zarządzania procesami biznesowymi dr Andrzej Sobczak Agenda spotkania Kwestie organizacyjne Organizacja zajęć Zaliczenie Programy

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

Sybase Professional Services

Sybase Professional Services Sybase Professional Services Zarządzanie Portfelem Aplikacji Marek Ryński Sybase Polska Dyrektor Zarządzający, DRB Legionowo, 09.2008 W gąszczu IT czyli za co ja mam płacić? (problem) Złożoność technologii

Bardziej szczegółowo

Kontrola spójności modeli UML za pomocą modelu. Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Kontrola spójności modeli UML za pomocą modelu. Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Kontrola spójności modeli UML za pomocą modelu przestrzennego DOD Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Obecne metody kontroli spójności modeli

Bardziej szczegółowo

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

Od ERP do ERP czasu rzeczywistego

Od ERP do ERP czasu rzeczywistego Przemysław Polak Od ERP do ERP czasu rzeczywistego SYSTEMY INFORMATYCZNE WSPOMAGAJĄCE ZARZĄDZANIE PRODUKCJĄ Wrocław, 19 listopada 2009 r. Kierunki rozwoju systemów informatycznych zarządzania rozszerzenie

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

STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe

STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe STUDIA STACJONARNE 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

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

Bardziej szczegółowo

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV

Metodyka wdrożenia. Bartosz Szczęch. bartosz.szczech@it.integro.pl. Starszy Konsultant MS Dynamics NAV Metodyka wdrożenia Bartosz Szczęch Starszy Konsultant MS Dynamics NAV bartosz.szczech@it.integro.pl Wyróżniamy następujące etapy wdrożenia rozwiązania ERP: Analiza Projekt Budowa Uruchomienie Działanie

Bardziej szczegółowo

Aurea BPM Dokumenty pod kontrolą

Aurea BPM Dokumenty pod kontrolą Aurea BPM Dokumenty pod kontrolą 1 Aurea BPM unikalna platforma o wyróżniających cechach Quality Software Solutions Aurea BPM Aurea BPM system informatyczny wspomagający zarządzanie procesami biznesowymi

Bardziej szczegółowo

Zarządzanie procesami w Ministerstwie Gospodarki. 6 listopada 2012 r.

Zarządzanie procesami w Ministerstwie Gospodarki. 6 listopada 2012 r. Zarządzanie procesami w Ministerstwie Gospodarki 6 listopada 2012 r. 2 Historia podejścia procesowego w MG Od 2007 roku w Ministerstwie Gospodarki stosuje się Wspólną Metodę Oceny Projekty doskonalące

Bardziej szczegółowo

UPEDU: Testowanie (ang. Testing discipline)

UPEDU: Testowanie (ang. Testing discipline) Wydział Informatyki PB Wprowadzenie Inżynieria oprogramowania II Marek Krętowski e-mail: mkret@wi.pb.edu.pl http://aragorn.pb.bialystok.pl/~mkret Wykład 9: UPEDU: Testowanie (ang. Testing discipline) Dwa

Bardziej szczegółowo

PROCESOWE MODELE STEROWANIA PRZEPŁYWAMI MATRIAŁOWYMI W PRZEDSIĘBIORSTWACH

PROCESOWE MODELE STEROWANIA PRZEPŁYWAMI MATRIAŁOWYMI W PRZEDSIĘBIORSTWACH PROCESOWE MODELE STEROWANIA PRZEPŁYWAMI MATRIAŁOWYMI W PRZEDSIĘBIORSTWACH Streszczenie Stefan Senczyna Politechnika Śląska sencz@polsl.gliwice.pl Zastosowanie modeli procesowych systemu informacyjnego,

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

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo