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ę

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UNOWOCZEŚNIENIE PROGRAMÓW KSZTAŁCENIA

UNOWOCZEŚNIENIE PROGRAMÓW KSZTAŁCENIA Zeszyty Naukowe Wydziału Informatycznych Technik Zarządzania Wyższej Szkoły Informatyki Stosowanej i Zarządzania Współczesne Problemy Zarządzania Nr 1/2010 UNOWOCZEŚNIENIE PROGRAMÓW KSZTAŁCENIA Notatka

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

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

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 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

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

Kiedy IT staje się biznesem - opcja for Service Provider platformy Tivoli's Process Automation Engine

Kiedy IT staje się biznesem - opcja for Service Provider platformy Tivoli's Process Automation Engine Kiedy IT staje się biznesem - opcja for Service Provider platformy Tivoli's Process Automation Engine Gerard Lipiec 2010 IBM Corporation Agenda Perspektywa biznesowa Usługi IT Model biznesowy Service Provider

Bardziej szczegółowo

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?

JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.

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

15. Funkcje i procedury składowane PL/SQL

15. Funkcje i procedury składowane PL/SQL 15. Funkcje i procedury składowane PLSQL 15.1. SQL i PLSQL (Structured Query Language - SQL) Język zapytań strukturalnych SQL jest zbiorem poleceń, za pomocą których programy i uŝytkownicy uzyskują dostęp

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

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

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania dr inż. Marcin Szlenk Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Wprowadzenie O mnie dr inż. Marcin

Bardziej szczegółowo

Diagramy czynności Na podstawie UML 2.0 Tutorial

Diagramy czynności Na podstawie UML 2.0 Tutorial Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/

Bardziej szczegółowo

Autor Jerzy Roszkowski. Management Systems Consulting. Data utworzenia 2011.01.26 Data modyfikacji 2011.01.26 Wersja 4.0

Autor Jerzy Roszkowski. Management Systems Consulting. Data utworzenia 2011.01.26 Data modyfikacji 2011.01.26 Wersja 4.0 Katalog szkoleń 2011 Akademia InŜynierii Oprogramowania MCS - Dr Jerzy Roszkowski Autor Jerzy Roszkowski Management Systems Consulting Data utworzenia 2011.01.26 Data modyfikacji 2011.01.26 Wersja 4.0

Bardziej szczegółowo

Przedstawienie działań IT MF

Przedstawienie działań IT MF Przedstawienie działań IT MF Paweł Oracz Ministerstwa Finansów Maciej Puto Ministerstwa Finansów Radom, dn. 2 kwietnia 2009 r. Agenda spotkania Przedstawienie struktury IT resortu i roli poszczególnych

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

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA

KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA KOMPUTEROWE WSPOMAGANIE ZARZĄDZANIA Wykład 12 Narzędzia CASE Dr inż. Mariusz Makuchowski Narzędzia CASE Obecnie proces tworzenia oprogramowania musi spełniać szereg wymagań, w szczególności dotyczy to:

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

Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect

Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect Karolina Zmitrowicz Zarządzanie wymaganiami w projekcie może być trudne i czasochłonne, może być chaotyczne jeśli brak odpowiedniego

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

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 2: MODELE PROCESU WYTWARZANIA OPROGRAMOWANIA dr inż. Leszek Grocholski ( na podstawie wykładów prof. K. Subiety, Instytut Informatyki PAN ) Zakład Języków Programowania

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

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

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

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 9 Strukturyzacja modelu przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements

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

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

Kontraktor - Analityk Biznesowy

Kontraktor - Analityk Biznesowy Kontraktor - Analityk Biznesowy Imię i nazwisko: Antal International_JC Lokalizacja: Warszawa Dostępność: 1 miesiąc Godzinowy koszt współpracy: 110 PLN + VAT Znajomość języków obcych: Angielski - Bardzo

Bardziej szczegółowo

Overlord - Software Development Plan

Overlord - Software Development Plan Overlord - Software Development Plan Jakub Gołębiowski Adam Kawa Piotr Krewski Tomasz Weksej 5 czerwca 2006 Spis treści 0.1 Cel.......................................... 4 0.2 Zakres........................................

Bardziej szczegółowo

Inżynieria oprogramowania Wprowadzenie. WYKŁAD Piotr Ciskowski

Inżynieria oprogramowania Wprowadzenie. WYKŁAD Piotr Ciskowski Inżynieria oprogramowania Wprowadzenie WYKŁAD Piotr Ciskowski Creating a software system what the customer ordered what the analyst understood what the project described what the programmers developed

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

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

Projektowanie baz danych za pomocą narzędzi CASE

Projektowanie baz danych za pomocą narzędzi CASE Projektowanie baz danych za pomocą narzędzi CASE Metody tworzenia systemów informatycznych w tym, także rozbudowanych baz danych są komputerowo wspomagane przez narzędzia CASE (ang. Computer Aided Software

Bardziej szczegółowo

Wykaz osób, które będą uczestniczyć w wykonywaniu zamówienia

Wykaz osób, które będą uczestniczyć w wykonywaniu zamówienia (Pieczątka Wykonawcy) Wykaz osób, które będą uczestniczyć w wykonywaniu zamówienia Lp. Imię i nazwisko* Rola wskazanej osoby Minimalne wymagania dla każdej z osób Czy wskazana osoba spełnia podane wymaganie?

Bardziej szczegółowo

Podstawy języka UML UML

Podstawy języka UML UML Podstawy języka UML UML Plan prezentacji Wprowadzenie do modelowania Wprowadzenie do języka UML Diagram klas Diagram pakietów Diagram przypadków użycia Diagram czynności Terminologia Terminologia Aplikacja

Bardziej szczegółowo

STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA

STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA Tomasz SOBESTIAŃCZYK ZESZYTY NAUKOWE WYDZIAŁU NAUK EKONOMICZNYCH STANDARD UML 2.3 W ZARZĄDZANIU WYTWARZANIEM OPROGRAMOWANIA Zarys treści: W pracy podjęto próbę przedstawienie UML 2.3 jako metody w zarządzaniu

Bardziej szczegółowo

Spis treści. Rozdział 3. Słownik danych (Data Dictionary)...n.. 65 Formalizm notacji słownika danych...u...65

Spis treści. Rozdział 3. Słownik danych (Data Dictionary)...n.. 65 Formalizm notacji słownika danych...u...65 Spis treści Wprowadzenie...n... 7 Rozdział 1. Ogólne metody analizy systemowej...n. 9 Rozkład funkcjonalny...u...u.10 Model funkcjonalny metoda przepływu danych...u...11 Modelowanie informacji (danych)...u...11

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

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

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

Najpierw lepiej, później taniej Strategia osiągania unikalnej wartości dla klienta wspierana rozwiązaniami IBM. Autorzy: IBPM S.A.

Najpierw lepiej, później taniej Strategia osiągania unikalnej wartości dla klienta wspierana rozwiązaniami IBM. Autorzy: IBPM S.A. Najpierw lepiej, później taniej Strategia osiągania unikalnej wartości dla klienta wspierana rozwiązaniami IBM Autorzy: IBPM S.A. 3 zasady dobrego zarządzania Wprowadzenie 1 Najpierw lepiej potem taniej

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

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r. ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego

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

Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane

Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane Nazwa modułu: Metodyki projektowania i modelowania systemów I Rok akademicki: 2012/2013 Kod: IET-2-211-SW-s Punkty ECTS: 3 Wydział: Informatyki, Elektroniki i Telekomunikacji Kierunek: Elektronika i Telekomunikacja

Bardziej szczegółowo

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu. AGH, EAIE, Informatyka Winda - tutorial Systemy czasu rzeczywistego Mirosław Jedynak, Adam Łączyński Spis treści 1 Wstęp... 2 2 Przypadki użycia (Use Case)... 2 3 Diagramy modelu (Object Model Diagram)...

Bardziej szczegółowo

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00

Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Regulamin usługi Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Projekt realizowany jest w ramach Działania 5.2 Wsparcie

Bardziej szczegółowo

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

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

Bardziej szczegółowo

2011-11-04. Instalacja SQL Server Konfiguracja SQL Server Logowanie - opcje SQL Server Management Studio. Microsoft Access Oracle Sybase DB2 MySQL

2011-11-04. Instalacja SQL Server Konfiguracja SQL Server Logowanie - opcje SQL Server Management Studio. Microsoft Access Oracle Sybase DB2 MySQL Instalacja, konfiguracja Dr inŝ. Dziwiński Piotr Katedra InŜynierii Komputerowej Kontakt: piotr.dziwinski@kik.pcz.pl 2 Instalacja SQL Server Konfiguracja SQL Server Logowanie - opcje SQL Server Management

Bardziej szczegółowo

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL Projektowanie Systemów Komputerowych Laboratoria/Projekty Krzysztof Regulski AGH, WIMiIP DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL 1) Zastosowanie Jedną ze stosowanych metodologii prowadzenia projektów

Bardziej szczegółowo

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank. Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.pl Obsługa wniosków kredytowych Potrzeba elastyczności

Bardziej szczegółowo

Netkata. PROCES projektowy Interfejsu Użytkownika. Spis treści. Netkata Interactive

Netkata. PROCES projektowy Interfejsu Użytkownika. Spis treści. Netkata Interactive Netkata PROCES projektowy Interfejsu Użytkownika Spis treści Projekt efektywnego UI... 2 1. Analiza biznesowa... 3 2. Analiza funkcjonalna... 3 3. Architektura informacji... 4 4. Interaktywne makiety...

Bardziej szczegółowo

Podejście zwinne do zarządzania projektami

Podejście zwinne do zarządzania projektami Podejście zwinne do zarządzania projektami na przykładach projektów wytwarzania oprogramowania Wojciech Czujowski, Łukasz Sienkiewicz Tieto Poland Agenda CZĘŚĆ I-sza: Kilka słów o Tieto SCRUM w organizacji

Bardziej szczegółowo

Wprowadzenie do UML, przykład użycia kolizja

Wprowadzenie do UML, przykład użycia kolizja Bogdan Kreczmer bogdan.kreczmer@pwr.wroc.pl Zakład Podstaw Cybernetyki i Robotyki Instytut Informatyki, Automatyki i Robotyki Politechnika Wrocławska Kurs: Copyright c 2012 Bogdan Kreczmer Niniejszy dokument

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

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie Wykład 2 MIS-1-505-n Inżynieria Marzec 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 2.1 Agenda 1 2 3 4 5 6 2.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo