METODYKA DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW

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

Download "METODYKA DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW"

Transkrypt

1 METODYKA DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW Wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Celem analizy jest zidentyfikowanie w naszym otoczeniu tych prostych elementarnych rzeczy i zrozumienie ich wzajemnego na siebie wpływu. Pamiętajmy, że jedna z najtrudniejszych gier na świecie szachy to tylko kilkanaście figur i skończony zbiór reguł ich przemieszczania. Nawet największa organizacja to tylko skończona liczba ról i reguł postępowania. (żr. Jarosław Żeliński, referat na konferencji). Ideałem są, w moich oczach, rozwiązania, które dostarczone w krótkim terminie, doskonale wspierają realizację strategii organizacji. Moim zdaniem dobry analityk to taki, który przy minimalnych wymaganych nakładach pracy, potrafi odkryć i opisać mechanizm (model) działania organizacji oraz opracować dla niej możliwie najlepsze rozwiązanie w postaci opisu wymagań na to, co i jak dostawca tego rozwiązania ma wdrożyć. Dobra analiza biznesowa do dokument stanowiący sam dla siebie dowód swojej poprawności"

2 Treść opracowania stanowi także opis zakresu szkoleń i warsztatów praktycznych prowadzonych przez autora. Niniejszy dokument stanowi w całości opracowanie własne firmy Jarosław Żeliński IT-Consulting zwanej dalej Analitykiem. Wszystkie opisane narzędzia i metody są publicznymi standardami (źr. Celem stworzenia tego dokumentu jest zapoznanie Partnerów i Zleceniodawców, a także innych zainteresowanych, z metodą pracy i produktami Analityka oraz standardami jakich używa. Wersja: :56:00 Strona 2

3 O AUTORZE Jarosław Żeliński, ekspert niezależny. Ukończył Wydział Elektroniki Wojskowej Akademii Technicznej. Od 1991 roku pracuje w branży IT uczestnicząc w projektach z zakresu analiz systemowych, doradztwa organizacyjnego a także wdrożeń systemów IT. Od 1998 roku prowadzi niezależną działalność doradczą, publikuje eseje, autorskie prace analityczne i opracowania branżowe w prasie specjalistycznej i gospodarczej oraz w uruchomionym w tym samym roku własnym portalu Od roku 2003 Członek Stowarzyszenia Doradców Gospodarczych. W latach współpracownik, wykładowca Katedry Systemów Informacyjnych na Wydziale Przedsiębiorczości i Towaroznawstwa Akademii Morskiej w Gdyni. W latach roku także na Politechnice Warszawskiej. Od roku 2014 jest wykładowcą w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk. Członek International Institute of Business Analysis oraz INCOSE. Jako analityk, w swojej karierze, pomagał wielu firmom od małych do dużych, w tym także spółkom giełdowym, bankom i urzędom centralnym. Dla utrzymania wysokiej jakości efektów pracy stosuje sprawdzone na rynku, oparte na standardach i najlepszych praktykach, metody analizy, w 100% zgodne ze uznanymi na świecie standardami Object Management Group. Jako narzędzie pracy wykorzystuje profesjonalne oprogramowanie CASE 1 wspomagające dokumentowanie wyników analiz i projektów a także sam proces analizy. Modelowanie przedsiębiorstwa stwarza dobrą możliwość analizy oraz kształtowania procesów działania. Dzięki temu można uniknąć problemów przy wprowadzaniu zmian. (Hubert H. Zimmermann). Analiza i projektowanie systemów (ang. systems analysis and design). Podstawową rolą analityka systemów jest zrozumienie i opisanie badanego stanu rzeczy. Rolą analityka, w odpowiedzi na postawiony problem, jest wskazanie możliwych rozwiązań oraz ich przewidywanych skutków. Jeżeli rozwiązaniem problemu jest wprowadzenie zmian w systemie, rolą analityka jest ich zaprojektowanie. Dlatego analityk systemowy to także projektant systemów. 1 CASE (Computer-Aided Software Engineering, Computer-Aided Systems Engineering) - oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania. Funkcje CASE-a to analiza, projektowanie i programowanie. Narzędzia CASE automatyzują metody projektowania, dokumentacji oraz tworzenia struktury kodu programu w wybranym języku programowania, najczęściej w programowaniu obiektowym. Typowymi narzędziami CASE są: narzędzia do modelowania w języku UML i podobnych, narzędzia do zarządzania konfiguracją zawierające system kontroli wersji, narzędzia do refactoringu (źr. WIKI). Wersja: :56:00 Strona 3

4 ZAWARTOŚĆ O autorze... 3 Jak czytać ten dokument... 6 Wartość dodana opisanej metodyki... 7 Wprowadzenie... 9 Jakie modele powstają w projekcie... 9 Proces wyboru i wdrożenia oprogramowania Analiza biznesowa Nadzór autorski nad realizacją Product Owner Obszary dziedzinowe metodyki Komunikacja Analiza i modelowanie biznesowe Wymagania Projektowanie Implementacja, testowanie, utrzymanie i rozwój Uwagi dotyczące wyboru gotowych systemów klasy ERP Komunikacja i metoda pozyskiwania danych źródłowych Analiza biznesowa Analiza kontekstu Motywacja biznesowa Wartość dodana Analiza i formalizacja struktury organizacyjnej Wartość dodana Analiza i specyfikacja reguł biznesowych i biznesowego słownika pojęć Wartość dodana Wersja: :56:00 Strona 4

5 Analiza i modelowanie procesów biznesowych Wartość dodana Metoda specyfikowania wymagań Model kontekstowy Wymagania na oprogramowanie Wymagania dziedzinowe system pojęć Wartość dodana Systemy dedykowane oraz brakujące funkcjonalności Przypadki użycia jako metoda określania wymagań funkcjonalnych (usługi aplikacji) Metoda specyfikowania logiki biznesowej - model Dziedziny systemu Abstrakcja dziedziny systemu - model BCE Model sekwencji test logiki biznesowej systemu Szczegółowy model czyli gdzie i jakie dane Inne produkty analizy i projektowania Wymagania w stosunku do Zamawiającego Biuro projektu Tryb zgłaszania uwag do treści dokumentów Wymagania w stosunku do dostawcy oprogramowania Wymagania na zawartość oferty wykonawcy Wykorzystane standardy i dobre praktyki Literatura Wersja: :56:00 Strona 5

6 JAK CZYTAĆ TEN DOKUMENT Niniejsze opracowanie adresowane jest do podmiotów zawierających umowy z Analitykiem, a także dla każdego, kto chce poznać dominujące na świecie standardy, dobre praktyki i standardy de facto, będące metodami pracy firmy Jarosław Żeliński IT-Consulting. Wkładem własnym autora jest opisana w tym dokumencie pragmatyka i konwencja modelowania dokumentowania oraz systemy pojęciowe uzupełniające standardowe notacje (tak zwane profile). Dla sponsorów projektu i kadr zarządczych przeznaczone jest Wprowadzenie. Opisuje ono tok przebiegu projektu, jego cele i korzyści. Uczestnicy biznesowi projektu (zespół projektowy ekspertów dziedzinowych Zamawiającego), dla zrozumienia jego przebiegu, powinni zapoznać się z treścią kolejnego rozdziału: Analiza Biznesowa. Uczestnicy projektu i osoby zainteresowane metodą i produktem specyfikowania wymagań (np. Opis Przedmiotu Zamówienia) powinny poznać także rozdział Analiza Wymagań. Osoby zainteresowane opisem metody specyfikowania i projektowania oprogramowania (systemów dedykowanych) powinny zapoznać się z rozdziałem Systemy dedykowane i brakujące funkcjonalności. Każdy powinien przeczytać sekcję: wymagania w stosunku do Zamawiającego i do Dostawcy oprogramowania umieszczoną na końcu dokumentu. UWAGA! W przypadku zawarcia umowy z Analitykiem, niniejszy dokument stanowi element formalnej oferty, na podstawie której doszło do zawarcia umowy. Zamawiający w umowie deklaruje, że zapoznał się z treścią tego dokumentu, i że akceptuje metody pracy Analityka w nim opisane. Dokument ten może stanowić załącznik do takiej umowy. Wersja: :56:00 Strona 6

7 WARTOŚĆ DODANA OPISANEJ METODYKI Opisany tu sposób przeprowadzenia analizy i specyfikowania wymagań pozwala: 1. Przeprowadzić audyt zarządzania i funkcjonowania organizacji, wskazać miejsca ryzykowne dla jej działania i możliwe do usprawnienia, 2. Zapanować wprowadzenie zmian i przeprowadzenie reorganizacji, 3. Przeprowadzić testy potencjalnych skutków wdrożenia zmian, już na etapie analizy, 4. Zapisać (udokumentować) logikę biznesową funkcjonowania organizacji w sposób pozwalający na jej ochronę prawną (prawo autorskie i tajemnica przedsiębiorstwa patrz nagłówek tego dokumentu), tak by prawa do opisanej logiki (i ona sama) pozostały przy Zamawiającym, 5. Opisać przedmiot zamówienia (np. usługi związane z reorganizacja, wymagania na oprogramowanie) jako Dzieło, czyli mierzalny produkt w umowie cywilnoprawnej z dostawcą usług lub wykonawcą oprogramowania, zminimalizować ryzyko zmian zakresu w trakcie trwania projektu. Dokumentacja wykonana według niniejszego opisu daje możliwości zaplanowana zakresu projektu (opis dzieła w umowie o dzieło) czyli podstawowego elementu zarządzania projektami biznesowymi. Po zakończeniu projektu lub w przypadku zaistnienia sporu z dostawcą, daje możliwość stwierdzenia, czy dostawca dostarczył to, do czego się zobowiązał. Wszystkie wykorzystane techniki i narzędzia (notacje, standardy) są wolne od opłat licencyjnych (nie dotyczy to opłat za szkolenia i podręczniki). Wersja: :56:00 Strona 7

8 PROSTOTA JEST SZCZYTEM WYRAFINOWANIA (LEONARDO DA VINCI) NIE NALEŻY MNOŻYĆ BYTÓW PONAD MIARĘ (DAWID OCKHAM) Wersja: :56:00 Strona 8

9 WPROWADZENIE Przedwczesny wybór rozwiązania praktycznie zawsze prowadzi do działania jak wdrożyć to rozwiązanie zamiast jak ulepszyć działanie firmy, gdyż każde rozwiązanie (w szczególności oprogramowanie) ma swoje specyficzne ograniczenia. Brak zaś śledzenia ustaleń i zmian w zakresie wymagań prowadzi do wielokrotnego ich powielania i utraty panowania nad tym zakresem. Opisana tu metodyka to efekt zdobywanych od 1991 roku doświadczeń, prowadzonych badań, studiów literaturowych, prac badawczych i udziału w wielu projektach. Metodyka ta bazuje na klasycznej analizie systemowej i stanowi podejście do analizy i projektowania zorientowane na tworzenie modeli i ich testowanie. Jest zgodna z zaleceniami międzynarodowych organizacji standaryzujących i naukowymi metodami prowadzenia badań, także zaleceniami firm badawczych i uznanych autorytetów 2. Jest nastawiona na wykonywanie wyłącznie tych prac, które przyczyniają się do rozwiązania konkretnego problemu w konkretnej sytuacji. Prace analityczne prowadzone są metoda top-down (od ogółu do szczegółu) a prace projektowe metodą iteracyjno-przyrostową. JAKIE MODELE POWSTAJĄ W PROJEKCIE Dzięki orientacji na modele oraz przyrostowe metody analizy i projektowania, opisana tu metodyka unika wad tak zwanych metodyk ciężkich, wymagających znacznych nakładów pracy na dokumenty nie wnoszące w danym projekcie wartości (sztywny proces projektowy). Dobór treści dokumentów jest każdorazowo ustalany. Powstają wyłącznie te dokumenty (analizy i modele), które w danym przypadku prowadzą do obniżenia ryzyka projektu i dokumentują oczekiwane efekty. Podstawową cechą projektu prowadzonego zgodnie z zaleceniami IIBA (International Institute of Business Analysis 3 ) jest tak zwane śladowanie, to jest wywodzenie każdego elementu modelu z jego nadrzędnego uogólnienia (każdy kolejny etap analizy i projektowania to uszczegółowienie wyników poprzedniego etapu). Pozwala to na stałą kontrolę celu i zakresu projektu oraz biznesowe uzasadnienie każdego jego elementu. Orientacja na procesy biznesowe, jako metoda analizy a także zarządzania organizacjami i ich opisu, stanowi kontynuację śladowania: procesy biznesowe wynikają ze strategii, wymagania na oprogramowanie wynikają z procesów (lub ich scenariuszy). Jako pierwsze powstają produkty analizy systemowej (opisuje mechanizm działa organizacji) organizacji, na jej podstawie mogą powstać rekomendacje zmian oraz sugerowane rozwiązanie do wdrożenia, jeżeli tym rozwiązaniem jest oprogramowanie, powstaje model tego oprogramowania. Jeżeli ma to być oprogramowanie gotowe, specyfikowane są wyłącznie usługi jakich oczekujemy od tego oprogramowania. 2 Lista standardów na końcu dokumentu. 3 Wersja: :56:00 Strona 9

10 W przypadku braku na rynku wymaganego oprogramowania, projektowana jest jego struktura i mechanizm działania (logika biznesowa). PROCES WYBORU I WDROŻENIA OPROGRAMOWANIA Kluczową rolą analityka biznesowego jest minimalizacja ryzyka porażki projektu. Najczęściej podawanymi przyczynami porażek wdrożeń są: źle określone wymagania, opór pracowników przed zmianami i przedwczesny wybór dostawcy rozwiązania. Dlatego sprawdzona praktyka to następujący proces: (źr. opracowanie własne autora) ANALIZA BIZNESOWA W pierwszym etapie projektu analizowane są: strategia firmy, struktura działań, przepływ informacji oraz zasoby organizacji. Produktem są modele opisujące funkcjonowanie organizacji. Na bazie wyników analizy rekomendowane mogą być: zmiany organizacyjne, wdrożenie nowych metod zarządzania i norm postępowania, wdrożenie narzędzi wspomagających zarządzanie, w szczególności oprogramowanie. Kolejny etap to zaplanowanie i przygotowanie ewentualnych zmian organizacyjnych. Po zakończeniu tego etapu zbierane są wymagania biznesowe. Na ich podstawie powstaje specyfikacja wymagań na rozwiązanie. Specyfikacja ta służy jako materiał do przeprowadzenia wyboru rozwiązania i jego dostawcy (konkurs ofert, przetarg). Rozwiązanie i jego dostawca jest wybierane dopiero na tym etapie. Po dokonaniu wyboru rozwiązania, jego dostawca musi opracować Koncepcję wdrożenia, która jest dokumentem opisującym (deklaracja) jakie działania i prace wykona dostawca, żeby spełnić wymagania. To jest moment weryfikacji i ostatecznej wyceny projektu wdrożeniowego. Od momentu zaakceptowania koncepcji wdrożenia, prowadzone jest wdrożenie. Na tym etapie Analityk nadzoruje zgodność prac Dostawcy z wymaganiami i zarządza zmianami w dokumentacji modelu biznesowego i specyfikacji wymagań (oraz projektu dla rozwiązań dedykowanych). W zależności od wielkości i specyfiki projektu, ostatnie trzy etapy (Opracowanie wymagań, koncepcji wdrożenia i wdrożenie), mogą być prowadzone metodą iteracyjno-przyrostową zorientowaną na usługi i komponenty systemu. Wersja: :56:00 Strona 10

11 Projekt wdrożenia nowego oprogramowania to określenie tego, do czego zostanie ono użyte i jak ma to użycie wyglądać. Specyfikowane są usługi, które oprogramowanie ma świadczyć (jego przypadki użycia) oraz jakość tych usług (jakość i ograniczenia: wymagania poza-funkcjonalne). Jeżeli audyt wykaże, że istnieją obszary niestandardowe w organizacji, dla tych obszarów prowadzi się szczegółową analizę, gdyż tam najprawdopodobniej (w przypadku projektów związanych z wyborem oprogramowania) będzie tworzone i wdrażane rozwiązanie dedykowane. NADZÓR AUTORSKI NAD REALIZACJĄ PRODUCT OWNER Po wyborze dostawcy, Analityk (autor projektu) nadzoruje zgodność dostarczonego produktu ze specyfikacją (nadzór autorski). Komunikacja w projekcie, w warstwie formalnej, bazuje na przekazywaniu dokumentacji i na notatkach projektowych. Poniżej scenariusze dla dwóch kluczowych zdarzeń: Wymagana dodatkowa wiedza o Zamawiającym u Dostawcy oraz Incydent u Zamawiającego. Rozwinięte zwinne metodyki zarządzania projektami, związanymi z dostarczaniem produktów takich jak oprogramowanie, przewidują rolę osoby pośredniczącej w komunikacji pomiędzy Zamawiającym a Wykonawcą (Dostawcą). Rola ta najczęściej nosi nazwę Product Owner (lub Client Proxy). Rolę tę pełni osoba mająca wiedzę o Zamawiającym, z reguły jest to Analityk Biznesowy, autor analizy i dokumentacji wymagań, który w toku projektu ją aktualizuje i zarządza jej zmianą. Wersja: :56:00 Strona 11

12 OBSZARY DZIEDZINOWE METODYKI KOMUNIKACJA Komunikacja to kluczowy element w każdym projekcie, w projektach związanych z analizą i projektowaniem szczególnie, gdyż wszelkie niejednoznaczności w treści powstających dokumentów niszczą efekty tego typu projektów, prowadzą do nieporozumień a w efekcie mogą doprowadzić nawet do krachu projektu. Komunikacja to także ustalenie ról w projekcie i ich rygorystyczne przestrzeganie gdyż rozmyta odpowiedzialność także prowadzi do nieporozumień. Dlatego w toku projektu obowiązuje ustalony plan i metody komunikacji. ANALIZA I MODELOWANIE BIZNESOWE Pierwszy etap analizy to udokumentowanie strategii firmy, jej architektury, celu biznesowego, metod realizacji celu (taktyka). Tu powstaje ogólny model biznesowy firmy. Kluczowymi źródłami informacji są sponsor projektu i zarząd organizacji (jeżeli nie jest sponsorem). Drugi etap to modelowanie procesów biznesowych. Podstawową metodą pracy na tym etapie jest audyt dokumentów operacyjnych oraz uzupełniające wywiady z kadrą kierowniczą. Produktem tego etapu jest model biznesowy zawierający opis celu biznesowego projektu, strukturę organizacji, model procesów biznesowych, słowniki pojęć i reguł biznesowych, odwołania do dokumentów operacyjnych takich jak procedury, zarządzenia, zakresy obowiązków, wzory dokumentów. Na tym etapie może być konieczny opis powiązań procesów biznesowych z posiadaną infrastrukturą IT. Metodyka ta bazuje na trójwarstwowym modelu organizacji: (źr. Wersja: :56:00 Strona 12

13 W warstwie najwyższej, strategicznej, definiowany jest model biznesowy i strategia jego realizacji. Z nich wynika ogólna architektura procesów, mierniki efektywności, polityki i reguły biznesowe. Odpowiada na pytanie Co jest naszym celem? Kolejna warstwa to procesy biznesowe oraz wewnętrzne ustalenia reguły biznesowe: model wewnętrznego łańcucha wartości. Model procesów odpowiada na pytanie Co i w jakim celu należy zrobić? Warstwa najniższa. Postać wewnętrzna procesów biznesowych to skutek istnienia ograniczeń i wymagań, którymi są model biznesowy i strategia jego realizacji oraz ograniczenia narzucane przez prawo, posiadane zasoby (w tym ludzi i ich umiejętności). Ta warstwa to warstwa wykonawcza. Opisuje szczegóły realizacji procesów: jakich kompetencji, umiejętności, procedur i narzędzi wymaga realizacja procesów i jakimi dysponujemy. Odpowiada na pytanie Jak realizujemy procesy biznesowe, jak (i czym) należy to zrobić? Optymalizacja procesów to podnoszenie ich efektywności, w tym jakości ich produktów. Formalizacja to element porządkowania (spisywanie procedur i wymaganych umiejętności ich wykonawców) warstwy wykonawczej. WYMAGANIA Specyfikowanie wymagań to proces analizy i specyfikowania oczekiwanych cech rozwiązani postawionego problemu. Specyfikacja wymagań (także na oprogramowanie) jest rekomendacją, będąca produktem analizy biznesowej i celu projektu. Wymagania to specyfikacja cech jakimi powinien się charakteryzować produkt np. oprogramowanie (ale także nowy np. zestaw zarządzeń wewnętrznych). Wymagania są uzupełniane ograniczeniami (czyli np. oczekiwaną jakością procesów w organizacji lub niedoborem kadr w projektach z poza IT). Wymagania są mapowane (śladowanie wstecz) na cele biznesowe w celu ich weryfikacji (uzasadnienie biznesowe każdego wymagania). PROJEKTOWANIE Jeżeli analiza (lub jej fragment) dotyczy dedykowanego systemu informacyjnego (może to być część większej całości), jest opracowywany tak zwany projekt (model) architektury wysokiego poziomu (bardzo ogólny projekt systemu) oraz specyfikacje (projekty) tych elementów systemu (oprogramowania), które muszą zostać opracowane i wykonane jako oprogramowanie dedykowane (brak produktów na rynku spełniających wymagania). W ramach tego etapu powstają szczegółowe opisy logiki biznesowej jaka, w ramach realizacji wymagań, ma zostać odwzorowana w oprogramowaniu (systemie IT). Jeżeli jest to projekt organizacyjny, produktem projektowania może być np. specyfikacja reguł biznesowych jako materiał wejściowy do weryfikacji zarządzeń wewnętrznych i procedur i potem projekty tych procedur i zarządzeń. Wersja: :56:00 Strona 13

14 IMPLEMENTACJA, TESTOWANIE, UTRZYMANIE I ROZWÓJ Te fazy, to dalszy ciąg cyklu życia produktu jakim jest nowy system. Na tym etapie rola autora dokumentacji z roli Analityka Biznesowego (projektanta systemu) przechodzi do roli Właściciela (tego) Produktu (Product Owner wg. metodyki SCRUM zarządzania projektami). Polega ona na prowadzeniu nadzoru autorskiego i zarządzanie zmianą w dokumentacji opisującej produkt. Jest to etap wdrożenia rozwiązania i jego utrzymania realizowany przez dostawcę rozwiązania lub samodzielnie. Poniższy schemat obrazuje rolę Właściciela Produktu w projekcie, który pośredniczy w komunikacji pomiędzy dostawcą rozwiązania (po lewej) a jego odbiorcą (po prawej). UWAGI DOTYCZĄCE WYBORU GOTOWYCH SYSTEMÓW KLASY ERP Systemy klasy ERP to szeroka gama oprogramowania wspomagającego zarządzanie przedsiębiorstwami i organizacjami. Skrót ERP oznacza Enterprise Resource Management (Zarządzanie Zasobami Organizacji). Systemy tego typu wywodzą się ewolucyjnie z systemów MRP (ang. Material Requirement Planning, Planowanie Potrzeb Materiałowych) i MRP II (ang. Manufacturing Resource Planning, Planowanie Zasobów Produkcyjnych). Od kilku lat obecne jest na rynku pojęcie ERP II. Podstawową cechą odróżniającą systemy ERP II od poprzedników jest to, że oprócz funkcjonalności umożliwiającej planowanie zasobów rzeczowych i finansowych przedsiębiorstwa, zawierają oprogramowanie pozwalające na zarządzanie kontaktami z klientem (tzw. CRM - Customer Relationship Management), prowadzenia kontrolingu, mają funkcjonalności zaawansowanego raportowania (podsystem wspomagania podejmowania decyzji, Business Intelligence). Cechą tych systemów, obecnie już wymaganą, jest także możliwość korzystania z nich poprzez sieć WWW. UWAGA! Nie jest jednak konieczne by cały ten zestaw funkcjonalności stanowił jeden pakiet oprogramowania od jednego producenta! Jak widać są to bardzo złożone systemy. Lista detaliczna cech takiego pakietu ERP II może obejmować nawet ponad 6 tys. pozycji! Planowanie ich całościowego wdrożenia a wcześniej specyfikowanie wymagań, wybór konkretnego produktu i jego dostawcy, nie może więc być typowym procesem specyfikowania wymagań funkcjonalnych: nikt nie jest w stanie skutecznie zarządzać taką liczbą wymagań w jednym projekcie! Wersja: :56:00 Strona 14

15 W ramach zakresu systemów ERP II pojawiają się też moduły bilingowe, call center, workflow, business inteligence (system wspomagania podejmowania decyzji). Opisana tu metodyka, bazuje na uznaniu, że standardowe obszary działania, powinny być obsługiwane standardowymi narzędziami (spełniającymi pewne normy, standardy, zgodne z ustalonymi przepisami prawa). Ich definiowanie nie polega na specyfikowaniu wszystkich ich cech, których są setki, a powoływaniem się na te normy i przepisy, z którymi produkty te (oprogramowanie) muszą być zgodne. Wymagania takie wystarczy uzupełnić o kluczowe parametry naszych procesów i cechy dokumentów (najwyżej kilkadziesiąt!) oraz testy (procedury testowe) czy konkretne oprogramowanie je spełnia. Wystarczające powinno być opisanie procesów jakie mają być wspierane tym oprogramowaniem (Co chcemy uzyskać a nie Jak). Projekty, których celem jest wdrożenie gotowego standardowego oprogramowania, w opisanej tu metodyce, są prowadzone w sposób pozwalający na jak najszybsze zdefiniowanie obszaru stanowiącego kluczowy obszar przewagi konkurencyjnej beneficjenta wdrożenia, stanowiący specyfikę danej organizacji, to co odróżnia ją od reszty (praktyka pokazuje, że jest to kilka do kilkunastu procent działań). To założenie pozwala prowadzić projekt w następujący sposób: 1. analiza biznesowa, 2. analiza przewagi konkurencyjnej, 3. wyłonienie obszaru budującego przewagę na rynku, 4. zdefiniowanie wymagań na tak określony obszar, 5. wskazanie standardów, które opisują pozostałe działania w organizacji. Najlepsze praktyki wdrożeń dużych i złożonych systemów, zalecają traktowanie ich modułów jako zespołu odrębnych dziedzinowo podsystemów, wdrażanych niezależnie (nawet jako osobne produkty pochodzące od różnych producentów). Obecny poziom standaryzacji oprogramowania pozwala na relatywnie łatwą integrację produktów różnych dostawców. Praktyka pokazuje także, że wybór i wdrożenie kilku dobrze dobranych podsystemów osobno, jest tańsze niż wybór jednego uniwersalnego i dostosowywanie go do swoich potrzeb (tak zwana kastomizacja). Takie też podejście jest tu rekomendowane. Wersja: :56:00 Strona 15

16 KOMUNIKACJA I METODA POZYSKIWANIA DANYCH ŹRÓDŁOWYCH Zarzadzanie projektem ma dwa aspekty: 1. Stawianie zadań. 2. Przekazywanie informacji. Pierwszy to oczekiwania wobec dostawcy informacji, drugi to zagwarantowanie pewności przekazania i spójności tych informacji. Wymiana informacji pomiędzy stronami (analityk, organizacja analizowana, dostawca rozwiązania) wymaga więc nadzoru a nie raz poufności (która na tym etapie prac staje się już standardem). Wiele lat doświadczeń doprowadziło do uznania, że obiektywne informacje o sposobie pracy organizacji niosą dokumenty jakie w niej powstają w myśl zasady: jeżeli coś jest na prawdę istotne, to jest to dokumentowane. Wywiady są prowadzone wyłącznie w celu wyjaśniania braków, nie stanową podstawowego narzędzia pozyskiwania informacji o analizowanej organizacji. Praktyka pokazuje, że jest to metoda pewniejsza i mniej kosztowna, a dająca znacznie wyższej jakości produkt. Podobne postępowania zalecane jest w metodach prowadzenia analiz opisywanych przez organizację IIBA. Metoda ta pozwala na systematyczny przegląd pracy organizacji, jej modelowanie w takt postępu analizy dokumentów, pozwala na identyfikowanie wszelkich niejednoznaczności i luk w wiedzy o działaniach organizacji. Pozwala szybko zidentyfikować metody pracy zwyczajowe, nieformalne i podjąć decyzje o ich formalizacji lub odrzuceniu. Analiza odbywa się metodą od ogółu do szczegółu, zbierane i analizowane są kolejne dokumenty operacyjne, powstają wstępne modele które są konsultowane z dostawcami tych danych, nanoszone są ewentualne korekty, i proces powtarza się aż do uzyskania opisu organizacji w ustalona wcześniej dokładnością (wynikającą z celu projektu). Poniższy diagram obrazuje proces prowadzenia analizy ta metodą: Wersja: :56:00 Strona 16

17 Komunikacja w tak prowadzonym projekcie to stała współpraca pomiędzy analitykiem a ekspertami dziedzinowymi klienta. Analityk inicjuje kolejne etapy projektu, informując określonych ekspertów dziedzinowych analizowanej organizacji, jakich danych potrzebuje. Eksperci Ci udzielają informacji (przekazują dokumenty) oraz jako recenzenci powstających kolejnych elementów dokumentacji, przekazują swoje uwagi (zapisy są zgodne lub niezgodne z prawdą, brakuje jeszcze.. itp.). Metodą komunikacji jest elektroniczna wymiana informacji i dokumentów, w sposób pozwalający śledzić cały proces i zagwarantować jego poufność: (w ramach prowadzenia projektu dostarczam wszelkie narzędzia do zdalnej pracy). Wersja: :56:00 Strona 17

18 ANALIZA BIZNESOWA Etap Analizy Biznesowej obejmuje weryfikację (audyt) posiadanych informacji na temat celu biznesowego, metod jego mierzenia, etapów osiągania celu a także inwentaryzację kluczowych zasobów do jego realizacji i strategii. Może zawierać analizę ryzyk, analizę SWOT oraz innych parametrów mogących mieć wpływ na realizację projektu. Etap ten stanowi inwentaryzację wiedzy o organizacji i otoczeniu projektu. ANALIZA KONTEKSTU MOTYWACJA BIZNESOWA Podstawą (szkieletem) analizy biznesowej jest tak zwany Model Motywacji Biznesowej (ang BMM, Business Motivation Model, spec. Model BMM ujmuje kontekst projektu biznesowo w różnych wymiarach, w celu uzasadnienia dlaczego Zarząd organizacji chce coś robić, do czego dąży, jak zamierza to osiągnąć oraz jak oceni rezultaty. Główne elementy modelu BMM: Stan końcowy - Cele: Co (w odróżnieniu od jak) organizacja chce osiągnąć, Metody - Środki : Jak i z pomocą czego organizacja zamierza osiągnąć swoje cele, o Strategia osiągnięcia celu: jak planujemy osiągnąć cel, o Taktyka: co będziemy w związku z tym robić. Organizacja: Reguły biznesowe oraz Polityki, są to części modelu biznesowego Organizacji, zawierają wewnętrzne zasady funkcjonowania, Czynniki wpływu, Ograniczenia: mają wpływ na organizacje i sposób jaki osiąga ona swoje cele albo korzysta ze swoich środków, Ocena sytuacji, ryzyka, oczekiwane zyski itp.: w jaki sposób Ograniczenia wpływają na sposób w jaki organizacja z pomocą posiadanych środki osiąga cele, Podstawowym celem opracowania tego modelu jest usystematyzowanie posiadanej projektu, jego środowisku i jej ewentualne uzupełnienie. wiedzy o celu Ustalenia te pomagają uniknąć problemów podczas ustalania priorytetów dla poszczególnych wymagań oraz zabezpieczają przez brakiem możliwości stwierdzenia czy wdrożenie odniosło zamierzony skutek. W trakcie całej analizy biznesowej na etapie specyfikowania wymagań powinny być te wymagania weryfikowane, czy przyczyniają się do osiągnięcia celu projektu. Brak jasno zdefiniowanego celu oraz powiązanych z nim elementów takich jak czynniki wpływu, działania pozwalające na osiągnięcie celu, procesy biznesowe realizujące strategie osiągania celu, prowadzi do sytuacji, w której nie ma możliwości sprawdzenia czy dane wymaganie przyczynia się do osiągnięcia celu projektu. Brak kryterium oceny prowadzi do zjawiska zwanego puchnięciem zakresu projektu: pojawiają się nowe oczekiwania i nie ma narzędzia do ich akceptacji lub odrzucania. Przykładowy model motywacji wyrażony graficzne wygląda jak poniżej: Wersja: :56:00 Strona 18

19 Uzupełnieniem, wsparciem tego modelu jest biznesowy słownik pojęć i reguł biznesowych (spec. WARTOŚĆ DODANA Audyt wiedzy o celu i środowisku projektu pozwala zweryfikować to, czy posiadane są niezbędne dane do zrozumienia i oceny zasadności biznesowej projektu i jego ryzyka. Daje podstawowe dane do ewentualnej oceny jego rentowności. Jasno określony i mierzalny cel projektu to jedyne narzędzie oceny czy zgłaszane np. przez pracowników wymagania służą osiągnięciu celu czy nie, i jakim kosztem. ANALIZA I FORMALIZACJA STRUKTURY ORGANIZACYJNEJ Jednym z najczęściej zaniedbywanych obszarów organizacji podczas analiz jest struktura organizacyjna. Sformalizowana struktura organizacyjna porządkuje wiedze o: 1. Powiązaniach pomiędzy komórkami organizacyjnymi, 2. Rolach (kompetencje i umiejętności) pracowników, 3. Podległości pracowników (zakresy uprawnień). Model struktury organizacyjnej to hierarchiczna struktura obrazująca poszczególne komórki organizacyjne, podległość osób oraz ich przynależność do komórek organizacyjnych. Cechą poprawnie sformalizowanego Wersja: :56:00 Strona 19

20 modelu struktury organizacyjnej jest jego drzewiasta 4, hierarchiczna struktura. Spotykane przypadki osób mających poszerzone kompetencje (osoby pełniące kilka ról) należy obrazować podając niezależnie dane tej osoby przy kilku rolach. Tworząc strukturę (jej model) organizacyjną stosowane są następujące pojęcia: 1. Organizacja - nazwana grupa ludzi mających ustaloną strukturę i działających razem, aby osiągnąć wspólne cele (podmiot gospodarczy, urząd, itp.). 2. Jednostka (komórka) organizacyjna jedno- lub wieloosobowy zespół (organ) powołany do wykonywania określonych zadań, mający ustalone miejsce w strukturze organizacyjnej. 3. Stanowisko miejsce w hierarchii organizacji lub komórki organizacyjnej. 4. Osoba pracujący na rzecz organizacji człowiek. 5. Rola zakres obowiązków i kompetencji. Przykład modelu struktury (diagram) organizacyjnej zawierającej zarówno podległość komórek jak i ról: Z uwagi na czytelność oraz specyfikę wielu firm, w praktyce często rozdziela się diagramy modelujące strukturę komórek organizacyjnych i modelujące przynależność do nich pracowników. 4 Drzewo oznacza w teorii grafów graf, który jest acykliczny i spójny. Mówiąc językiem obrazowym, z każdego wierzchołka drzewa można dotrzeć do każdego innego wierzchołka (spójność) i tylko jednym sposobem (acykliczność, czyli brak możliwości chodzenia w "kółko"). Wersja: :56:00 Strona 20

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

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

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

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

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

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

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

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

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

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

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

Procedury Plan komunikacji w projektach

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

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

Bardziej szczegółowo

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

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

Dobór systemów klasy ERP

Dobór systemów klasy ERP klasy ERP - z uwzględnieniem wymagań normy ISO 9001 Prezentacja w Klubie Menedżera Jakości, 19 marzec 2008 Zagadnienia ogólne związane z doborem systemu klasy ERP Podstawowe podziały klasyfikujące systemy

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej

Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej FiM Consulting Sp. z o.o. Szymczaka 5, 01-227 Warszawa Tel.: +48 22 862 90 70 www.fim.pl Spis treści

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

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

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

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Opis Progress Project zaprasza do zapoznania się z programem szkolenia organizowanego przez partnera szkoleniowego,

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

Organizacyjny aspekt projektu

Organizacyjny aspekt projektu Organizacyjny aspekt projektu Zarządzanie funkcjonalne Zarządzanie między funkcjonalne Osiąganie celów poprzez kierowanie bieżącymi działaniami Odpowiedzialność spoczywa na kierownikach funkcyjnych Efektywność

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

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

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

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

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE OFERTA WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE W TWORZENIU MODELU AS-IS /Jest to przykład (wzór) oferty treść jest wypełniana na podstawie nie zobowiązujących rozmów i spotkań z Klientem, pracownikami

Bardziej szczegółowo

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

Kompleksowe rozwiązanie dla organizacji,

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

Bardziej szczegółowo

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

BOC dla KJUF Podsumowanie warsztatów 17-18 listopada 2011

BOC dla KJUF Podsumowanie warsztatów 17-18 listopada 2011 BOC dla KJUF Podsumowanie warsztatów 17-18 listopada 2011 Grupa BOC Profil firmy BOC Założona w 1995 roku Wywodzi się z grupy BPMS Uniwersytetu Wiedeńskiego Obecnie ponad 150 pracowników w 7 krajach europejskich

Bardziej szczegółowo

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

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

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

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

Szkolenie 1. Zarządzanie projektami

Szkolenie 1. Zarządzanie projektami UNIWERSYTET MARII CURIE-SKŁODOWSKIEJ W LUBLINIE Projekt Nowoczesny model zarządzania w UMCS umowa nr UDA-POKL.04.01.01-00-036/11-00 Pl. Marii Curie-Skłodowskiej 5, 20-031 Lublin, www.nowoczesny.umcs.lublin.pl

Bardziej szczegółowo

10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy

10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy 10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy 10.1. Co to są dokumenty i zapisy w systemie zarządzania bezpieczeństwem i higieną pracy? W każdym systemie zarządzania dokumentacja

Bardziej szczegółowo

Projekt: Szansa drzemie w zmianie nowoczesne ZZL

Projekt: Szansa drzemie w zmianie nowoczesne ZZL Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego Projekt: Szansa drzemie w zmianie nowoczesne ZZL Opis szkoleń planowanych do realizacji w ramach projektu

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

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

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

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

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA

OPIS PRZEDMIOTU ZAMÓWIENIA Załącznik nr 1 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Tytuł zamówienia: Organizacja szkoleń specjalistycznych i kursów doszkalających na potrzeby realizacji projektu Wzmocnienie potencjału dydaktycznego UWM

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

CRM. Relacje z klientami.

CRM. Relacje z klientami. CRM. Relacje z klientami. Autor: Jill Dyche Książka przeznaczona jest dla wielu czytelników -- od menedżerów do użytkowników Część 1. skierowana jest do kadry zarządzającej, menedżerów projektów oraz ludzi

Bardziej szczegółowo

Zwrot z inwestycji w IT: prawda czy mity

Zwrot z inwestycji w IT: prawda czy mity Zwrot z inwestycji w IT: prawda czy mity Inwestycje w technologie IT 1 muszą podlegać takim samym regułom oceny, jak wszystkie inne: muszą mieć ekonomiczne uzasadnienie. Stanowią one koszty i jako takie

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego. 1. Cel szkolenia 1. Cel szkolenia m szkolenia jest nauczenie uczestników stosowania standardu PRINCE2 do Zarządzania Projektami Informatycznymi. Metodyka PRINCE2 jest jednym z najbardziej znanych na świecie standardów

Bardziej szczegółowo

AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2

AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2 AL 1302 ZARZĄDZANIE PROJEKTAMI W OPARCIU O METODYKĘ PRINCE2 1. Definicja projektu: cechy projektu, przyczyny porażek projektów, czynniki sukcesu projektów, cele projektu, produkty projektu, cykl życia

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH

INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Załącznik Nr 3 do Zarządzenia Nr 52/2014 Rektora UMCS INSTRUKCJA ZARZĄDZANIA RYZYKIEM W PROJEKTACH I PROGRAMACH STRATEGICZNYCH Spis treści Słownik pojęć... 1 Wprowadzenie... 2 Kroki zarządzania ryzykiem

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

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

Bardziej szczegółowo

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

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

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

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

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 pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy

Projekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy Projekt pn Wdrożenie metodyk zarządzania usługami IT, projektami i programami w Urzędzie Miasta Bydgoszczy współfinansowany ze środków Mechanizmu Finansowego Europejskiego Obszaru Gospodarczego. Marek

Bardziej szczegółowo

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology

Bardziej szczegółowo

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających

Bardziej szczegółowo

Monitoring procesów z wykorzystaniem systemu ADONIS

Monitoring procesów z wykorzystaniem systemu ADONIS Monitoring procesów z wykorzystaniem systemu ADONIS 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

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

Pracownia Inżynierii Procesowej

Pracownia Inżynierii Procesowej Pracownia Inżynierii Procesowej Aktualizacja oferty styczeń 2016 WŁAŚCICIEL mgr inż. Alicja Wróbel Absolwent Politechniki Opolskiej, Wydziału Zarzadzania i Inżynierii Produkcji Rysunek techniczny 2D 3D

Bardziej szczegółowo

Zastosowania aplikacji B2B dostępnych na rynku zalety aplikacji online

Zastosowania aplikacji B2B dostępnych na rynku zalety aplikacji online 2012 Zastosowania aplikacji B2B dostępnych na rynku zalety aplikacji online Sławomir Frąckowiak Wdrożenie systemu B2B Lublin, 25 października 2012 Aplikacje B2B do czego? Realizacja najważniejszych procesów

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Dopasowanie IT/biznes

Dopasowanie IT/biznes Dopasowanie IT/biznes Dlaczego trzeba mówić o dopasowaniu IT-biznes HARVARD BUSINESS REVIEW, 2008-11-01 Dlaczego trzeba mówić o dopasowaniu IT-biznes http://ceo.cxo.pl/artykuly/51237_2/zarzadzanie.it.a.wzrost.wartosci.html

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

ZINTEGROWANE PROJEKTOWANIE SYSTEMÓW LOGISTYCZNYCH

ZINTEGROWANE PROJEKTOWANIE SYSTEMÓW LOGISTYCZNYCH ZINTEGROWANE PROJEKTOWANIE SYSTEMÓW LOGISTYCZNYCH Prezentacja europejskich doświadczeń Grupy Miebach Logistik Sukcesywne wdrażanie kompleksowych rozwiązań Pod pojęciem zintegrowanego projektowania kryją

Bardziej szczegółowo

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji 2012 Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji Niniejszy przewodnik dostarcza praktycznych informacji związanych z wdrożeniem metodyki zarządzania ryzykiem w obszarze bezpieczeństwa

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

Bardziej szczegółowo

Praktyczne zarządzanie projektami według metodyki PRINCE2

Praktyczne zarządzanie projektami według metodyki PRINCE2 Praktyczne zarządzanie projektami według metodyki PRINCE2 PRINCE2 jest zarejestrowanym znakiem handlowym AXELOS Limited. Przeznaczenie szkolenia: Dwudniowe intensywne szkolenie jest przeznaczone dla firm

Bardziej szczegółowo

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

ZAPYTANIE OFERTOWE NR 3/2014. z dnia 1/07/2014r. w związku z realizacją projektu pt.:

ZAPYTANIE OFERTOWE NR 3/2014. z dnia 1/07/2014r. w związku z realizacją projektu pt.: ZAPYTANIE OFERTOWE NR 3/2014 z dnia 1/07/2014r. w związku z realizacją projektu pt.: Optymalizacja powiązań biznesowych między firmą VARIOSTEEL Sp. z. o.o. i partnerami poprzez system informatyczny B2B

Bardziej szczegółowo

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

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

Bardziej szczegółowo

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

Systemy ERP. dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/

Systemy ERP. dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Systemy ERP dr inż. Andrzej Macioł http://amber.zarz.agh.edu.pl/amaciol/ Źródło: Materiały promocyjne firmy BaaN Inventory Control Jako pierwsze pojawiły się systemy IC (Inventory Control) - systemy zarządzania

Bardziej szczegółowo

PRINCE2. Metodyka zarządzania projektami. Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak

PRINCE2. Metodyka zarządzania projektami. Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak PRINCE2 Metodyka zarządzania projektami Na podstawie prezentacji R. Radzik, J. Binkiewicz, K. Kasprzak Metodyka PRINCE2 PRINCE2 Project IN Controlled Environments v.2 Określa: Co należy zrobić Dlaczego

Bardziej szczegółowo